Professional Documents
Culture Documents
Data Specifications
Version 1.9 – June 2014
Notices
Following are policies pertaining to proprietary rights, trademarks, translations, and
details about the availability of additional information online.
Proprietary Rights
The information contained in this document is proprietary and confidential to
MasterCard International Incorporated, one or more of its affiliated entities
(collectively “MasterCard”), or both.
This material may not be duplicated, published, or disclosed, in whole or in part,
without the prior written permission of MasterCard.
Trademarks
Trademark notices and symbols used in this document reflect the registration status
of MasterCard trademarks in the United States. Please consult with the Customer
Operations Services team or the MasterCard Law Department for the registration
status of particular product, program, or service names outside the United States.
All third-party product and service names are trademarks or registered trademarks of
their respective owners.
Disclaimer
MasterCard makes no representations or warranties of any kind, express or implied,
with respect to the contents of this document. Without limitation, MasterCard
specifically disclaims all representations and warranties with respect to this
document and any intellectual property rights subsisting therein or any part thereof,
including but not limited to any and all implied warranties of title, non-infringement,
or suitability for any purpose (whether or not MasterCard has been advised, has
reason to know, or is otherwise in fact aware of any information). Without
limitation, MasterCard specifically disclaims all representations and warranties that
any practice or implementation of the document will not infringe any third party
patents, copyrights, trade secrets or other rights. Without limitation, MasterCard
specifically disclaims all representations and warranties in relation to the document,
including but not limited to any and all implied warranties of suitability for any
purpose (whether or not MasterCard has been advised, has reason to know, or is
otherwise in fact aware of any information) or achievement of any particular result.
Address
MasterCard Worldwide
Chaussée de Tervuren, 198A
B-1410 Waterloo
Belgium
E-mail: contactless@mastercard.com
Table of Contents
Table of Contents ...........................................................................................iii
Using this Manual ..........................................................................................vii
Scope ........................................................................................................................... vii
Audience ..................................................................................................................... vii
Related Publications................................................................................................... viii
Notational Conventions ............................................................................................. viii
Abbreviations ............................................................................................................... ix
Document Overview .................................................................................................... xi
Revision History ......................................................................................................... xii
Scope
This document defines a set of personalization profiles supporting the MasterCard and
Maestro products for the following contactless card applications:
PayPass – Mag Stripe
PayPass – M/Chip 4
PayPass – Flex
The personalization data given for the PayPass – M/Chip 4 application covers the different
available application versions (v1.0, v1.1a, v1.1b). However, it covers only the contactless
interface. The personalization data given for the PayPass – M/Chip Flex application does
not include data for the co-application on the card.
For information on the personalization data for the contact interface, refer to the M/Chip
Personalization Data Specifications and Profiles, as indicated in each chapter.
The personalization of mobile applications and M/Chip Advance applications is out of
scope.
The personalization of non-card form factors, such as stickers, key fobs, etc. must follow
these requirements, normally using an online-only profile.
A card compliant with the values in this document will be accepted by the Chip
Personalization Validation process. If a card is not compliant, MasterCard will evaluate the
adherence to brand rules and the impact on interoperability and if there is a potential risk,
the card may be rejected.
Audience
This document is intended for:
Issuers intending to issue contactless enabled cards or devices
Personalization bureaus intending to provide facilities for contactless applications
Developers of Application Load File generation systems
It is assumed that the audience already has an understanding of contactless chip card
technology.
Related Publications
The following publications contain information directly related to this document or are
referenced by it.
Reference Document
[PPMAG] PayPass – Mag Stripe Technical Specifications, Version 3.3 – December 2007
[PPMCFLEX] PayPass – M/Chip Flex Technical Specifications, Version 1.1 – October 2006
[PPMCHIP4] PayPass – M/Chip 4 Technical Specifications, Version 1.3.1 – September 2008
[MCHIP410] M/Chip 4 Card Application Specifications for Debit and Credit – October
2002
[MCHIP411] M/Chip 4 Version 1.1 Card Application Specifications for Debit and Credit –
October 2006
[MCHIPPDS] M/Chip Personalization Data Specifications and Profiles – December 2011
Notational Conventions
The following conventions are used throughout the document.
Notation Description
'0' to '9' and 'A' to 'F' Hexadecimal notation. Values expressed in hexadecimal form are
enclosed in single quotes (i.e. '_').
"abcd" an or ans string
[…] Optional part
xx Undefined value
Application Control[2][4] For multi-byte data objects, a byte index and a bit index are used
under brackets. This example references the fourth bit of the second
byte of the Application Control data object.
Abbreviations
Abbreviation Meaning
AC Application Cryptogram
AFL Application File Locator
AID Application Identifier
AIP Application Interchange Profile
ARQC Authorization Request Cryptogram
ASCII American Standard Code for Information Interchange
ATC Application Transaction Counter
ATM Automated Teller Machine
C Conditional
CAM Card Authentication Method
CAT3 Cardholder Activated Terminal Level 3
CCD Common Core Definition
CDA Combined DDA/AC Generation
CDOL Card Risk Management Data Object List
CFDC Consecutive Failed Derivation Counter
CIAC Card Issuer Action Code
CRM Card Risk Management
CVC Card Validation Code
CVM Cardholder Verification Method
DDA Dynamic Data Authentication
DES Data Encryption Standard
DGI Data Group Identifier
EMV Europay, MasterCard, VISA
EMV CSK EMV Common Session Key derivation
FCI File Control Information
HVT High Value Transactions (above CVM limit)
ICC Integrated Circuit Card
IEC International Electrotechnical Commission
ISO International Standards Organisation
IVCVC3 Initialization Vector for CVC3
KDCVC3 Key Derivation for CVC3
LVT Low Value Transactions (below CVM limit)
Abbreviation Meaning
M Mandatory
MAC Message Authentication Code
MKAC Master Key for Application Cryptogram Generation
MKIDN Master Key for ICC Dynamic Number Generation
NATCTRACK1 Track 1 Number of ATC Digits
Document Overview
This document is organized in five chapters. Each section provides the complete set of
personalization data to configure the indicated application according to either MasterCard or
Maestro product rules.
Chapter
1 Proximity Payment System Environment (PPSE)
2 MasterCard PayPass – Mag Stripe Personalization Data
3 MasterCard PayPass – M/Chip Flex Personalization Data
4 Maestro PayPass – M/Chip Flex Personalization Data
5 MasterCard PayPass – M/Chip 4 Personalization Data
6 Maestro PayPass – M/Chip 4 Personalization Data
7 MasterCard PayPass – M/Chip 4 Mag-stripe Only Personalization Data
Revision History
Version Description
V1.5 Various editorial corrections made.
Document restructured to present contactless data as generic or profile-
dependent.
Profile options (offline, standard, online) added to each chapter as appropriate.
Updated CIAC and selected IAC bit settings to be profile dependent.
In PayPass – M/Chip 4 offline profiles, different CRM settings for Maestro and
MasterCard to reflect issuer choices regarding use of shared limits.
Contact profiles aligned with new contact PDS.
Security counter limits adjusted.
Added recommendation to use CDA in MasterCard contactless profiles.
MasterCard profiles modified to include Debit MasterCard.
Added recommendation regarding use of PIX extensions.
Modified "PTL Exceeded" bit in CIACs and IACs.
V1.6 Various editorial corrections made
Updated contact profiles that may be used. No longer restriction on full grade
only for Maestro
Added warning to avoid signing too much extra data if alternative file structure
is used
Updated recommendation to “fail CVM processing” in CVM List if signature is
attempted and unsuccessful (in line with M/Chip Requirements).
Emphasized that cash back is optional for Debit MasterCard on the contactless
interface
Added note about sharing and/or padding of Additional Check Table
Added Application Control options and recommended values.
Discontinuation of support for SDA on MasterCard
New online-only profile for MasterCard (no CAM)
New CIAC options (PTL Exceeded, Go online) in Offline Profile
New CIAC options (PTL Exceeded, Go online) in Standard Profile
Table 5.18 and Table 6.17 – added note that ICC PIN Encipherment keys not
used by contactless interface.
Added option to issue M/Chip 4 cards with PTH set to '08'
V1.7 Various editorial corrections made
New section added for M/Chip 4, mag-stripe mode only
Structure of each chapter amended as "predefined file structure" no longer
recommended
SDA removed as option
Note added regarding allocation of Unique Identifier & Device Type (Third
Party Data)
Soft limit Maestro CVM options included
CVC1 on magstripe must not be repeated in CVC3 placeholders in Track 1
Data, Track 2 Data
IAC values for Maestro contactless in soft limit market must decline transaction
Version Description
if PIN not entered correctly
Added recommendation regarding CRM on CAT3 devices for online-only
MasterCard profiles
Notes added regarding use of PVV in online PIN change, and personalization of
track data
Modified statements regarding use of pre-defined AFL, for both MasterCard
and Maestro chapters
Added option in CVM List entry: if Online PIN fails then option to apply next
or fail CVM processing
Added recommendation regarding values of NATCTRACK1 and NATCTRACK2 in
mag-stripe data
V1.8 Clarification of document scope (re mobile and other non-card form factors)
Various editorial changes
Addition of new chapter describing PPSE (and re-numbering of subsequent
chapters)
Several modifications & clarifications to requirements regarding CVC3
dynamic data & configuration
Re-ordering of table notes throughout the document
Removed the notion of "recommended" values from table headings. All data
object values listed are expected to be found during CPV
Application Capabilities Information added (with associated note) to FCI
(BF0C) template in all chapters
US-specific requirements concerning Third Party Data added
Removed profile-specific settings for IAC in all chapters (concerning CDA
failure) and added a note regarding offline-oriented behavior
Add a note regarding requirements for offline CAM and online capability of the
card (with extra qualification for US region)
Added Track 2 Equivalent Data to the proposed pre-defined file structure
Chip CVC must always be different from the CVC in the magnetic strip – the
exception regarding OBS is removed
Clarified options available in the setting of Previous Transaction History
Application Currency Code made mandatory throughout
For Maestro profiles, requirement on IAC[3][4-5] changed to recommendation
Added note regarding alternative AFL to cope with faulty reader
implementations
Clarified the options available for CIAC[2][4] for PayPass – M/Chip 4 profiles
Added requirement regarding Issuer Code Table Index in FCI Template
V1.9 Various editorial corrections
Updated legal notices at beginning of document
Removed unnecessary references to "PayPass" where possible
Removed references to "hard limit" and "soft limit" markets for Maestro;
replaced "ceiling limit" with "CVM limit
Corrected references to Application Version Number ('9F6C')
Aligned references to "mag-stripe mode" and "EMV mode" with EMV
documentation
Version Description
Added Canada to Device Type requirement (previously only US Region)
Ch 2 App Selection; removed PDOL from list of possible data objects in FCI
Maestro profiles: support for Purchase with Cash Back is allowed
PayPass-M/Chip 4 chapters, App Selection: modified text to allow for separate
instances of AID for each interface
Chapter 7, App Selection: corrected the references to notes c & d
Added clarification of what a "dummy" record is where appropriate.
Maestro chapters: added statement about absence of mag-stripe data ('9F6B')
Kernel Identifier made optional in PPSE entry
Support for cash withdrawals at ATM becomes mandatory in Central & Eastern
Europe
The File Control Information Issuer Discretionary Data is a constructed data object of
which the value field is comprised of one or more Application Templates (tag '61') as
described in Table 1.2.
Each directory entry is the value field of an Application Template and contains the
information described in Table 1.3. The same data may appear in the FCI specific to the
selected ADF. The same value should be used in each occurrence for a given application.
Note b Some legacy contactless readers do not support partial AID matching so
applications that are personalized in the PPSE are recommended not to have PIX
extensions.
Note c See individual chapters for full details of Application Label values.
Table 1.4 describes the structure of the Application Priority Indicator. Issuers must set a
unique value for the Application Priority Indicator in each contactless application on the
card. The cardholder confirmation bit must not be set for contactless applications.
Note a Dependent on the implementation, data objects for application selection may
already be personalized during pre-personalization. In this case, the AID and
Application Label must be specified when ordering the contactless card or
device.
Note b Other optional data objects that may be present in the FCI (Application Priority
Indicator, Language Preference, Issuer Code Table Index, Application Preferred
Name and FCI Issuer Discretionary Data) are not used by the contactless mag-
stripe card or device.
Note a The PCVC3 and PUNATC bit maps must only have non-zero bits that refer to
available positions in the discretionary data field of the corresponding Track
Data.
The least significant bit of the bit maps must be set to zero.
Note b The number of non-zero bits in the PCVC bit maps must be greater than or equal
to 3.
Note c The number of non-zero bits in PUNATCTRACK1 minus the value of NATCTRACK1 :
must be greater than or equal to 2
should be greater than or equal to 3, and
must be less than or equal to 5.
It must be equal to the number of non-zero bits in PUNATCTRACK2 minus the
value of NATCTRACK2.
Note d The storage of the cardholder name in the Track 1 Data read via the contactless
interface is prohibited by MasterCard. It is therefore recommended to use a
space character followed by the surname separator (i.e. " /").
Note e The placeholders for the dynamic data in the discretionary data (i.e. at the
positions where the contactless reader stores the ATC, UN, CVC3 and nUN)
should be filled with zeroes (hexadecimal zeroes ('0') for Track 2 Data and ASCII
zeroes ('30') for Track 1 Data).
The least significant position of the discretionary data is used by the reader to
store nUN.
Note f If a PVV is encoded in the discretionary part of track 1 and track 2 on the
magnetic stripe and used for Online PIN verification, then this must also be
encoded in the Track 1 Data (tag '56') and Track 2 Data (tag '9F6B') read through
the contactless interface.
Note g If the issuer intends to make use of the on-behalf service for Dynamic CVC3
Validation, then the value of NATCTRACK1 and the value of NATCTRACK2 must be
greater than or equal to 3 for the CVC3 Validation in Stand-in Service, or
greater than or equal to 2 for the Dynamic CVC3 Pre-validation Service or the
Mapping Service (processing only option).
In both cases, a value of at least 4 for NATCTRACK1 and NATCTRACK2 is
recommended if sufficient space is available.
If the PAN Sequence Number is present in the discretionary data and if the PAN
Sequence Number is used for the derivation of KDCVC3, then the length of the
PAN Sequence Number must be maximum 1 significant digit.
Note h The values of Track 1 Data (tag '56') and Track 2 Data (tag '9F6B') read through
the contactless interface must not be identical to the corresponding value on
the magnetic stripe in order to prevent a counterfeit magnetic stripe being
created from data read from the contactless interface. The CVC1 found on the
magnetic stripe must not be repeated in Track 1 Data or Track 2 Data.
Note i Optional data object containing the Device Type and proprietary non-payment
information (e.g. loyalty information). If proprietary non-payment information is
included, then the value of the Unique Identifier sub-field that is part of the Third
Party Data must be allocated by MasterCard. It is recommended to always
include Third Party Data with the relevant Device Type, even when there is no
proprietary information. In the latter case the Unique Identifier can be set to all
zeroes.
In US and Canada regions inclusion of the Third Party Data, with Device Type, is
mandatory.
Note a It is strongly recommended to use for IVCVC3TRACK1 the two least significant
bytes of the result of a MAC over the Track 1 Data as stored in Record 1, SFI 1.
In the same way IVCVC3TRACK2 should be the two least significant bytes of the
result of a MAC calculated over the Track 2 Data as stored in Record 1, SFI 1.
If the issuer intends to make use of the on-behalf service for Dynamic CVC3
Validation, then for IVCVC3 generation the method recommended above must
be used, and the placeholders for the dynamic data in the discretionary data of
Track 1 Data and Track 2 Data (i.e. at the positions where the reader stores the
ATC, UN, CVC3 and nUN) must be filled with zeroes (hexadecimal zeroes ('0') for
Track 2 Data and ASCII zeroes ('30') for Track 1 Data).
Note b It is strongly recommended to use for IVCVC3 generation the ISO/IEC 9797-1
MAC algorithm 3 with DES block cipher and an initial vector of zero (8 bytes).
If the issuer intends to make use of the on-behalf service for Dynamic CVC3
Validation, then this algorithm must be used.
Note b Issuer Code Table Index is mandatory if Application Preferred Name is present.
Note c Optional data object containing the Device Type and proprietary non-payment
information (e.g. loyalty information). If proprietary non-payment information is
included, then the value of the Unique Identifier sub-field that is part of the Third
Party Data must be allocated by MasterCard. It is recommended to always
include Third Party Data with the relevant Device Type, even when there is no
proprietary information. In the latter case the Unique Identifier can be set to all
zeroes.
In US and Canada regions, inclusion of the Third Party Data, with Device Type,
is mandatory.
Note d Contains information to alert the terminal to functionality available on the card.
Note a The contents of the Track 2 Equivalent Data (Tag '57') must be consistent with
the PAN (Tag '5A') and Expiration Date (Tag '5F24') data objects.
Note b Although CDOL2 is not used during contactless transactions, CDOL2 must be
present because some legacy contactless readers check the presence of
CDOL2.
Note c The SDA Tag List data object is mandatory even if offline CAM is not supported
because some legacy contactless readers check the presence of SDA Tag List
even if offline data authentication is not performed.
Note d The Chip CVC in the Track 2 Equivalent Data must differ from the CVC1 in the
track 2 data on the magnetic stripe.
Note e If a PVV is encoded in the discretionary part of track 1 and track 2 on the
magnetic stripe and used for Online PIN verification, then this must also be
encoded in the Track 2 Equivalent Data (tag '57') read through the contactless
interface.
Table 3.3 lists the data objects that must not be included in the records referenced in the
AFL.
Note a Support for cash withdrawals at ATMs is mandatory for cards issued in Albania,
Austria, Bosnia, Bulgaria, Croatia, Czech Republic, Hungary, Israel, Macedonia,
Montenegro, Poland, Romania, Serbia, Slovakia, and Slovenia.
Note b Cash back is optional for Debit MasterCard applications on the contactless
interface. Cash back is optional for MasterCard credit applications issued in
Europe region.
Note c Cards that are part of a prepaid program may, with prior approval, restrict card
acceptance to certain environments or merchants. For such programs, the
Application Usage Control may be varied to restrict acceptance as appropriate.
Note a If a bit in the Issuer Action Code – Denial is set to 1, then the corresponding bits
in the Issuer Action Code – Online and Issuer Action Code – Default may be set
to 0.
Note b The corresponding bit is never set in the TVR in the contactless reader,
therefore the setting of this bit has no impact on the transaction.
Note c If offline-oriented behavior is required, then, where the option is given, the
'denial' bits should be set. The 'online' bit should not be set.
Support CDA, or
Cards that do not support offline CAM must be configured to be online only. Cards in
Europe or US Regions must support CDA.
Note a Support for CDA is mandated for MasterCard contactless cards unless
configured as online only.
Note b The ICC Public Key Remainder is present if NIC > (NI – 42).
Note c The Issuer Public Key Remainder is present if N I > (NCA – 36).
Note If present.
Note Cards issued in Europe must support CDA. Cards issued outside Europe are
recommended to support CDA, but may be configured as exclusively online and
support no offline CAM.
If the AFL has the value '08010100100101011801020020010200' then the data objects
must be included in the specified records shown in Table 3.11.
If the AFL has the value '080101001001010118010200' then the data objects must be
included in the specified records shown in Table 3.11 (excluding SFI 4). Such a card
would not support CDA so must be configured as online only. Suitable dummy records
must be included in Record 1, SFI 3 and Record 2, SFI 3 in line with the predefined AFL
value. A dummy record should contain:
at least one valid tag
data object of non-zero length
optionally, padding characters
If the data objects are not organized as shown in Table 3.11, then the above values must not
be used. However
the first four bytes must always be equal to '08010100' (see section 3.2.6).
it is recommended not to sign the last record referenced by the AFL, as some reader
implementations cannot process this correctly.
Note a As SDA is not supported a suitable dummy record must be included in Record
2, SFI 3.
must always be included in Record 1 of SFI 1. No other records that are read through the
contactless interface may be included in SFI 1. The first four bytes of the AFL must always
be equal to '08010100'.
Note a The PCVC3 and PUNATC bit maps must only have non-zero bits that refer to
available positions in the discretionary data field of the corresponding Track
Data.
The least significant bit of the bit map must be set to zero.
Note b The number of non-zero bits in the PCVC3 bit maps must be greater than or
equal to 3.
Note c The number of non-zero bits in PUNATCTRACK1 minus the value of NATCTRACK1 :
must be greater than or equal to 2
should be greater than or equal to 3, and
must be less than or equal to 5.
It must be equal to the number of non-zero bits in PUNATCTRACK2 minus the
value of NATCTRACK2.
Note d The storage of the cardholder name in the Track 1 Data read via the contactless
interface is prohibited by MasterCard. It is therefore recommended to use a
space character followed by the surname separator (i.e. " /").
Note e The placeholders for the dynamic data in the discretionary data (i.e. at the
positions where the contactless reader stores the ATC, UN, CVC3 and nUN)
should be filled with zeroes (hexadecimal zeroes ('0') for Track 2 Data and ASCII
zeroes ('30') for Track 1 Data).
The least significant position of the discretionary data is used by the reader to
store nUN.
Note f If the issuer intends to make use of the on-behalf service for Dynamic CVC3
Validation, then the value of NATCTRACK1 and the value of NATCTRACK2 must be
greater than or equal to 3 for the CVC3 Validation in Stand-in Service, or
greater than or equal to 2 for the Dynamic CVC3 Pre-validation Service or the
Mapping Service (processing only option).
In both cases, a value of at least 4 for NATCTRACK1 and NATCTRACK2 is
recommended.
If the PAN Sequence Number is present in the discretionary data and if the PAN
Sequence Number is used for the derivation of KDCVC3, then the length of the
PAN Sequence Number must be maximum 1 significant digit.
Note g If a PVV is encoded in the discretionary part of track 1 and track 2 on the
magnetic stripe and used for Online PIN verification, then this must also be
encoded in the Track 1 Data (tag '56') and Track 2 Data (tag '9F6B') read through
the contactless interface.
Note h The values of Track 1 Data (tag '56') and Track 2 Data (tag '9F6B') read through
the contactless interface must not be identical to the corresponding value on
the magnetic stripe in order to prevent a counterfeit magnetic stripe being
created from data read from the contactless interface. The CVC1 found on the
magnetic stripe must not be repeated in Track 1 Data or Track 2 Data.
Note a When the Cumulative Offline Transaction Amount exceeds the Lower
Cumulative Offline Transaction Amount or the Consecutive Offline Transactions
Number exceeds the Lower Consecutive Offline Limit, the PayPass – M/Chip
Flex application will modify bit 2 of the PayPass Options Indicator of
[PPMCFLEX] in order to force the co-application to go online at the next
transaction.
The issuer should therefore pay special attention to the values of these limits at
personalization.
Note b If currency conversion is not used, it is recommended that the currency code in
each entry in the Currency Conversion Table be set to the same value as the
CRM Currency Code.
3.2.9 Miscellaneous
Note a It is strongly recommended to use for IVCVC3 TRACK1 the two least significant
bytes of the result of a MAC over the Track 1 Data as stored in Record 1, SFI 1.
In the same way IVCVC3TRACK2 should be the two least significant bytes of the
result of a MAC calculated over the Track 2 Data as stored in Record 1, SFI 1.
If the issuer intends to make use of the on-behalf service for Dynamic CVC3
Validation, then for IVCVC3 generation the placeholders for the dynamic data in
the discretionary data of Track 1 Data and Track 2 Data (i.e. at the positions
where the contactless reader stores the ATC, UN, CVC3 and nUN) must be filled
with zeroes (hexadecimal zeroes for Track 2 Data and ASCII zeroes ('30') for
Track 1 Data).
Note b It is strongly recommended to use for IVCVC3 generation the ISO/IEC 9797-1
MAC algorithm 3 with DES block cipher and an initial vector of zero (8 bytes).
If the issuer intends to make use of the on-behalf service for Dynamic CVC3
Validation, then this algorithm must be used.
Note The transaction that causes one of the upper limits (Upper Cumulative Offline
Limit or Upper Consecutive Offline Limit) to be exceeded is not declined.
Issuers of the online-only profile that do not support CDA are recommended not to use the
predefined file structure as neither SFI 3 nor SFI 4 are required.
Issuers of the online-only profile should not set Application Control [1][7] "Skip CIAC-
default on CAT 3" in order to prevent offline transactions being approved by the card.
Note b Issuer Code Table Index is mandatory if Application Preferred Name is present.
Note c Optional data object containing the Device Type and proprietary non-payment
information (e.g. loyalty information). If proprietary non-payment information is
included, then the value of the Unique Identifier sub-field that is part of the Third
Party Data must be allocated by MasterCard. It is recommended to always
include Third Party Data with the relevant Device Type, even when there is no
proprietary information. In the latter case the Unique Identifier can be set to all
zeroes.
In US and Canada regions, inclusion of the Third Party Data, with Device Type,
is mandatory.
Note d Contains information to alert the terminal to functionality available on the card.
Note a The contents of the Track 2 Equivalent Data (Tag '57') must be consistent with
the PAN (Tag '5A') and Expiration Date (Tag '5F24') data objects.
Note b Although CDOL2 is not used during contactless transactions, CDOL2 must be
present because some legacy contactless readers check the presence of
CDOL2.
Note c The SDA Tag List data object is mandatory even if offline CAM is not supported
because some legacy contactless readers check the presence of SDA Tag List
even if offline data authentication is not performed.
Note d If present, the Chip CVC in the Track 2 Equivalent Data must differ from the
CVC1 in the track 2 data on the magnetic stripe.
Note e If a PVV is encoded in the discretionary part of track 1 and track 2 on the
magnetic stripe and used for Online PIN verification, then this must also be
encoded in the Track 2 Equivalent Data (tag '57') read through the contactless
interface.
Table 4.3 lists the data objects that must not be included in the records referenced in the
AFL.
Note a Support for cash withdrawals at ATMs is mandatory for cards issued in Albania,
Austria, Bosnia, Bulgaria, Croatia, Czech Republic, Hungary, Israel, Macedonia,
Montenegro, Poland, Romania, Serbia, Slovakia, and Slovenia.
Note b Cards that are part of a prepaid program may, with prior approval, restrict card
acceptance to certain environments or merchants. For such programs, the
Application Usage Control may be varied to restrict acceptance as appropriate.
Table 4.5 describes the personalization values for the Issuer Action Codes.
Note a If a bit in the Issuer Action Code – Denial is set to 1, then the corresponding bits
in the Issuer Action Code – Online and Issuer Action Code – Default may be set
to 0.
Note b The corresponding bit is never set in the TVR in the contactless reader,
therefore the setting of this bit has no impact on the transaction.
Note e If offline-oriented behavior is required, then, where the option is given, the
'denial' bits should be set. The 'online' bit should not be set.
In markets where transactions are permitted above the CVM limit, the CVM List must be as
shown in Table 4.6.
Note a The ICC Public Key Remainder is present if NIC > (NI – 42).
Note b The Issuer Public Key Remainder is present if N I > (NCA – 36).
Note If present.
If the AFL has the value '08010100100101011801020020010200' then the data objects
must be included in the specified records shown in Table 4.11.
If the data objects are not organized as shown in Table 4.11, then
the data objects must be organised such that the first four bytes of the AFL are different
from '08010100'.
it is recommended not to sign the last record referenced by the AFL, as some reader
implementations cannot process this correctly.
If dummy records are included in order to respect the predefined AFL value, then the
dummy records should contain:
at least one valid tag
data object of non-zero length
optionally, padding characters
Note As SDA is not supported a suitable dummy record must be included in Record
2, SFI 3.
Note a When the Cumulative Offline Transaction Amount exceeds the Lower
Cumulative Offline Transaction Amount or the Consecutive Offline Transactions
Number exceeds the Lower Consecutive Offline Limit, the PayPass – M/Chip
Flex application will modify bit 2 of the PayPass Options Indicator of
[PPMCFLEX] in order to force the co-application to go online at the next
transaction.
The issuer should therefore pay special attention to the values of these limits at
personalization.
Note b If currency conversion is not used, it is recommended that the currency code in
each entry in the Currency Conversion Table be set to the same value as the
CRM Currency Code.
4.2.9 Miscellaneous
Note The transaction that causes one of the upper limits (Upper Cumulative Offline
Limit or Upper Consecutive Offline Limit) to be exceeded is not declined.
Note The setting of the 'International Transaction' and 'Domestic Transaction' bits to
(0,1,0) results in online contactless transactions on online-capable terminals.
With this setting, the PayPass – M/Chip Flex application will always generate an
ARQC on an online-capable terminal in response to a GENERATE AC command
requesting either a TC or an ARQC.
Issuers of the online-only profile should not set Application Control [1][7] "Skip CIAC-
default on CAT 3" in order to prevent offline transactions being approved by the card.
Note This section does not contain a complete list of all data objects referenced in
the AFL (Contact).
Table 5.1 lists the data objects that do not have the same value for both interfaces. These
data objects cannot be included in records shared by both interfaces.
Note The values on the contact and contactless interfaces may be the same or may
be different.
Note b Issuer Code Table Index is mandatory if Application Preferred Name is present.
Note c Optional data object containing the Device Type and proprietary non-payment
information (e.g. loyalty information). If proprietary non-payment information is
included, then the value of the Unique Identifier sub-field that is part of the Third
Party Data must be allocated by MasterCard. It is recommended to always
include Third Party Data with the relevant Device Type, even when there is no
proprietary information. In the latter case the Unique Identifier can be set to all
zeroes.
In US and Canada regions, inclusion of the Third Party Data, with Device Type,
is mandatory.
Note d Contains information to alert the terminal to functionality available on the card.
Note a The contents of the Track 2 Equivalent Data (Tag '57') must be consistent with
the PAN (Tag '5A') and Expiration Date (Tag '5F24') data objects.
Note b Although CDOL2 is not used during contactless transactions, CDOL2 must be
present because some legacy contactless readers check the presence of
CDOL2.
Note c The SDA Tag List data object is mandatory even if offline CAM is not supported
because some legacy contactless readers check the presence of SDA Tag List
even if offline data authentication is not performed.
Note d The Chip CVC in the Track 2 Equivalent Data must differ from the CVC1 in the
track 2 data on the magnetic stripe.
Note e If a PVV is encoded in the discretionary part of track 1 and track 2 on the
magnetic stripe and used for Online PIN verification, then this must also be
encoded in the Track 2 Equivalent Data (tag '57') read through the contactless
interface.
Table 5.5 describes the personalization values of the Application Usage Control for the
contactless interface.
Note a Support for cash withdrawals at ATMs is mandatory for cards issued in Albania,
Austria, Bosnia, Bulgaria, Croatia, Czech Republic, Hungary, Israel, Macedonia,
Montenegro, Poland, Romania, Serbia, Slovakia, and Slovenia.
Note c Cards that are part of a prepaid program may, with prior approval, restrict card
acceptance to certain environments or merchants. For such programs, the
Application Usage Control may be varied to restrict acceptance as appropriate.
Table 5.6 describes the personalization values of the Issuer Action Codes for the contactless
interface.
Note a If a bit in the Issuer Action Code – Denial is set to 1, then the corresponding bits
in the Issuer Action Code – Online and Issuer Action Code – Default may be set
to 0.
Note b The corresponding bit is never set in the TVR in the contactless reader,
therefore the setting of this bit has no impact on the transaction.
Note c If offline-oriented behavior is required, then, where the option is given, the
'denial' bits should be set. The 'online' bit should not be set.
This section describes the personalization values of the CVM List for the contactless
interface.
Support CDA, or
Cards that do not support offline CAM must be configured to be online only. Cards in
Europe or US Regions must support CDA.
Note a Support for CDA is mandated for MasterCard contactless cards unless
configured as online only.
Note b The ICC Public Key Remainder is present if NIC > (NI – 42).
Note c The Issuer Public Key Remainder is present if N I > (NCA – 36).
Note If present.
Note Cards issued in Europe must support CDA. Cards issued outside Europe are
recommended to support CDA, but may be configured as exclusively online and
support no offline CAM.
If the AFL (PayPass) has the value '08010100100101011801020020010200' then the data
objects must be included in the specified records shown in Table 5.12.
If the AFL (PayPass) has the value '080101001001010118010200' then the data objects
must be included in the specified records shown in Table 5.12. (excluding SFI 4). Such a
card would not support CDA so must be configured as online only. Suitable dummy
records must be included in Record 1, SFI 3 and Record 2, SFI 3 in line with the predefined
AFL value. A dummy record should contain:
at least one valid tag
data object of non-zero length
optionally, padding characters
If the data objects are not organized as shown in Table 5.12, then the above values must not
be used. However
the first four bytes must always be equal to '08010100' (see section 5.2.6).
it is recommended not to sign the last record referenced by the AFL, as some reader
implementations cannot process this correctly.
Note a As SDA is not supported a suitable dummy record must be included in Record
2, SFI 3.
Note a The PCVC3 and PUNATC bit maps must only have non-zero bits that refer to
available positions in the discretionary data field of the corresponding Track
Data.
The least significant bit of the bit map must be set to zero.
Note b The number of non-zero bits in the PCVC3 bit maps must be greater than or
equal to 3.
Note c The number of non-zero bits in PUNATCTRACK1 minus the value of NATCTRACK1 :
must be greater than or equal to 2
should be greater than or equal to 3, and
must be less than or equal to 5.
It must be equal to the number of non-zero bits in PUNATCTRACK2 minus the
value of NATCTRACK2.
Note d The storage of the cardholder name in the Track 1 Data read via the contactless
interface is prohibited by MasterCard. It is therefore recommended to use a
space character followed by the surname separator (i.e. " /").
Note e The placeholders for the dynamic data in the discretionary data (i.e. at the
positions where the contactless reader stores the ATC, UN, CVC3 and nUN)
should be filled with zeroes (hexadecimal zeroes ('0') for Track 2 Data and ASCII
zeroes ('30') for Track 1 Data).
The least significant position of the discretionary data is used by the reader to
store nUN.
Note f If a PVV is encoded in the discretionary part of track 1 and track 2 on the
magnetic stripe and used for Online PIN verification, then this must also be
encoded in the Track 1 Data (tag '56') and Track 2 Data (tag '9F6B') read through
the contactless interface.
Note g If the issuer intends to make use of on-behalf service for Dynamic CVC3
Validation, then the value of NATCTRACK1 and the value of NATCTRACK2 must be
greater than or equal to 3 for the CVC3 Validation in Stand-in Service, or
greater than or equal to 2 for the Dynamic CVC3 Pre-validation Service or the
Mapping Service (processing only option).
In both cases, a value of at least 4 for NATCTRACK1 and NATCTRACK2 is
recommended.
If the PAN Sequence Number is present in the discretionary data and if the PAN
Sequence Number is used for the derivation of KD CVC3, then the length of the
PAN Sequence Number must be maximum 1 significant digit.
Note h The values of Track 1 Data (tag '56') and Track 2 Data (tag '9F6B') read through
the contactless interface must not be identical to the corresponding value on
the magnetic stripe in order to prevent a counterfeit magnetic stripe being
created from data read from the contactless interface. The CVC1 found on the
magnetic stripe must not be repeated in Track 1 Data or Track 2 Data.
Note a If currency conversion is not used, it is recommended that the currency code in
each entry in the Currency Conversion Table be set to the same value as the
CRM Currency Code.
Note b The Additional Check Table is shared with the contact interface.
Note a The definition of bit 2 of byte 1 of Application Control (PayPass) depends on the
version of the PayPass – M/Chip 4 application (v1.0, v1.1a, or v1.1b). Refer to
Table 5.16 for more information.
Note b The recommended value for the Application Control (PayPass) is '000040'.
5.2.9 Miscellaneous
Note a It is strongly recommended to use for IVCVC3 TRACK1 the two least significant
bytes of the result of a MAC over the Track 1 Data as stored in Record 1, SFI 1.
In the same way IVCVC3TRACK2 should be the two least significant bytes of the
result of a MAC calculated over the Track 2 Data as stored in Record 1, SFI 1.
If the issuer intends to make use of on-behalf service for Dynamic CVC3
Validation, then for IVCVC3 generation the placeholders for the dynamic data in
the discretionary data of Track 1 Data and Track 2 Data (i.e. at the positions
where the contactless reader stores the ATC, UN, CVC3 and nUN) must be filled
with zeroes (hexadecimal zeroes for Track 2 Data and ASCII zeroes ('30') for
Track 1 Data).
Note b It is strongly recommended to use for IVCVC3 generation the ISO/IEC 9797-1
MAC algorithm 3 with DES block cipher and an initial vector of zero (8 bytes).
If the issuer intends to make use of on-behalf service for Dynamic CVC3
Validation, then this algorithm must be used.
Note The personalization of the Previous Transaction History value to '08' is used to
manage new card behavior. Contactless transactions may be forced online or
declined (pending the completion of a contact transaction). The appropriate
value for CIAC 'Go Online On Next Transaction Was Set' (Byte 2, bit 4) must be
set.
Note The personalization of the Previous Transaction History value to '08' is used to
manage new card behavior. Contactless transactions may be forced online or
declined (pending the completion of a contact transaction). The appropriate
value for CIAC 'Go Online On Next Transaction Was Set' (Byte 2, bit 4) must be
set.
Note a The personalization of the Previous Transaction History value to '08' is used to
manage new card behavior. Contactless transactions may be forced online or
declined (pending the completion of a contact transaction). The appropriate
value for CIAC 'Go Online On Next Transaction Was Set' (Byte 2, bit 4) must be
set.
Note b If a magnetic stripe grade profile is used for the contact interface, then the AC
Session Key Counter Limit must be set to the same value as the Application
Transaction Counter Limit ('4E20').
Table 5.23—Data Objects with a Fixed Initial Value (M/Chip 4 Version 1.0)
Data Object Name Tag Value
Cumulative Offline Transaction Amount – '000000000000'
Consecutive Offline Transactions – '00'
Number
Script Counter '9F5F' '00'
Log of The Current Transaction x – '00…00'
(x=1...10 or more)
Application Transaction Counter '9F36' '0000'
Global MAC in Script Counter – '000000'
Bad Cryptogram Counter – '0000'
CFDC for Integrity Session Key – 0
CFDC for Confidentiality – 0
Session Key
CFDC for AC Session Key – 0
Table 5.24—Data Objects with a Fixed Initial Value (M/Chip 4 Version 1.1.a)
Data Object Name Tag Value
Cumulative Offline Transaction Amount – '000000000000'
Consecutive Offline Transactions Number – '00'
Script Counter '9F5F' '00'
Log of The Current Transaction x – '00…00'
(x=1...10 or more)
Application Transaction Counter '9F36' '0000'
Global MAC in Script Counter – '000000'
Table 5.25—Data Objects with a Fixed Initial Value (M/Chip 4 Version 1.1b)
Data Object Name Tag Value
Cumulative Offline Transaction Amount – '000000000000'
Consecutive Offline Transactions Number – '00'
Script Counter '9F5F' '00'
Log of The Current Transaction x – '00…00'
(x=1...10 or more)
Application Transaction Counter '9F36' '0000'
AC Session Key Counter – '0000'
SMI Session Key Counter – '0000'
Bad Cryptogram Counter – '0000'
Security Limits Status 'DF02" '00'
Note The transaction that causes one of the lower limits (Lower Cumulative Offline
Limit or Lower Consecutive Offline Limit) to be exceeded is not declined.
Issuers of the online-only profile that do not use CDA are recommended not to use the
predefined file structure as neither SFI 3 nor SFI 4 are required.
Issuers of the online-only profile should not set Application Control [1][7] "Skip CIAC-
default on CAT 3" in order to prevent offline transactions being approved by the card.
Note This section does not contain a complete list of all data objects referenced in
the AFL (Contact).
Table 6.1 lists the data objects that do not have the same value for both interfaces. These
data objects cannot be included in records shared by both interfaces.
Note The setting of the 'International Transaction' and 'Domestic Transaction' bits to
(0,1,1) results in online contact transactions. With this setting, the PayPass –
M/Chip 4 application will always generate an ARQC during a contact transaction
on an online-capable terminal, and will decline every contact transaction on an
offline-only terminal or when the terminal is unable to go online.
Note b Issuer Code Table Index is mandatory if Application Preferred Name is present.
Note c Optional data object containing the Device Type and proprietary non-payment
information (e.g. loyalty information). If proprietary non-payment information is
included, then the value of the Unique Identifier sub-field that is part of the Third
Party Data must be allocated by MasterCard. It is recommended to always
include Third Party Data with the relevant Device Type, even when there is no
proprietary information. In the latter case the Unique Identifier can be set to all
zeroes.
In US and Canada regions, inclusion of the Third Party Data, with Device Type,
is mandatory.
Note d Contains information to alert the terminal to functionality available on the card.
Note a The contents of the Track 2 Equivalent Data (Tag '57') must be consistent with
the PAN (Tag '5A') and Expiration Date (Tag '5F24') data objects.
Note b Although CDOL2 is not used during contactless transactions, CDOL2 must be
present because some legacy contactless readers check the presence of
CDOL2.
Note c The SDA Tag List data object is mandatory even if offline CAM is not supported
because some legacy contactless readers check the presence of SDA Tag List
even if offline data authentication is not performed.
Note d If present, the Chip CVC in the Track 2 Equivalent Data must differ from the
CVC1 in the track 2 data on the magnetic stripe.
Note e If a PVV is encoded in the discretionary part of track 1 and track 2 on the
magnetic stripe and used for Online PIN verification, then this must also be
encoded in the Track 2 Equivalent Data (tag '57') read through the contactless
interface.
Table 6.5 lists the data objects that must not be included in the records referenced in the
AFL (PayPass).
Table 6.6 describes the personalization values of the Application Usage Control.
Note a Support for cash withdrawals at ATMs is mandatory for cards issued in Albania,
Austria, Bosnia, Bulgaria, Croatia, Czech Republic, Hungary, Israel, Macedonia,
Montenegro, Poland, Romania, Serbia, Slovakia, and Slovenia.
Note b Cards that are part of a prepaid program may, with prior approval, restrict card
acceptance to certain environments or merchants. For such programs, the
Application Usage Control may be varied to restrict acceptance as appropriate.
Table 6.7 describes the personalization values of the Issuer Action Codes.
Note a If a bit in the Issuer Action Code – Denial is set to 1, then the corresponding bits
in the Issuer Action Code – Online and Issuer Action Code – Default may be set
to 0.
Note b The corresponding bit is never set in the TVR in the contactless reader,
therefore the setting of this bit has no impact on the transaction.
Note e If offline-oriented behavior is required, then, where the option is given, the
'denial' bits should be set. The 'online' bit should not be set.
In markets where transactions are not permitted above the CVM limit, the CVM List must
be as shown in Table 6.8.
Cards issued in these markets but that are likely to be used in markets where transactions
are permitted above the CVM limit may use the CVM List in Table 6.9.
In markets where transactions are permitted above the CVM limit, the CVM List must be as
shown in Table 6.9.
Note a The ICC Public Key Remainder is present if NIC > (NI – 42).
Note b The Issuer Public Key Remainder is present if N I > (NCA – 36).
Note If present.
If the AFL (PayPass) has the value '08010100100101011801020020010200' then the data
objects must be included in the specified records shown in Table 6.13.
If the data objects are not organized as shown in Table 6.13, then
the data objects must be organized such that the first four bytes of the AFL (PayPass)
are different from '08010100'.
it is recommended not to sign the last record referenced by the AFL (PayPass), as some
reader implementations cannot process this correctly.
If dummy records are included in order to respect the predefined AFL value, then the
dummy records should contain:
at least one valid tag
data object of non-zero length
optionally, padding characters
Note a If currency conversion is not used, it is recommended that the currency code in
each entry in the Currency Conversion Table be set to the same value as the
CRM Currency Code.
Note b The Additional Check Table is shared with the contact interface.
Note a The definition of bit 2 of byte 1 depends on the version of the PayPass –
M/Chip 4 application (v1.0, v1.1a, or v1.1b). Refer to Table 6.16 for more
information.
Note c The recommended value for the Application Control (PayPass) is '000080'.
6.2.9 Miscellaneous
Note The personalization of the Previous Transaction History value to '08' is used to
manage new card behavior. Contactless transactions may be forced online or
declined (pending the completion of a contact transaction). The appropriate
value for CIAC 'Go Online On Next Transaction Was Set' (Byte 2, bit 4) must be
set.
Note The personalization of the Previous Transaction History value to '08' is used to
manage new card behavior. Contactless transactions may be forced online or
declined (pending the completion of a contact transaction). The appropriate
value for CIAC 'Go Online On Next Transaction Was Set' (Byte 2, bit 4) must be
set.
Note The personalization of the Previous Transaction History value to '08' is used to
manage new card behavior. Transactions may be forced online or declined
(pending the completion of a contact transaction). The appropriate value for
CIAC 'Go Online On Next Transaction Was Set' (Byte 2, bit 4) must be set.
Table 6.23—Data Objects with a Fixed Initial Value (M/Chip 4 Version 1.0)
Data Object Name Tag Value
Cumulative Offline Transaction Amount – '000000000000'
Consecutive Offline Transactions Number – '00'
Script Counter '9F5F' '00'
Log of The Current Transaction x – '00…00'
(x=1...10 or more)
Application Transaction Counter '9F36' '0000'
Global MAC in Script Counter – '000000'
Bad Cryptogram Counter – '0000'
CFDC for Integrity Session Key – 0
CFDC for Confidentiality Session Key – 0
CFDC for AC Session Key – 0
Table 6.24—Data Objects with a Fixed Initial Value (M/Chip 4 Version 1.1.a)
Data Object Name Tag Value
Cumulative Offline Transaction Amount – '000000000000'
Consecutive Offline Transactions Number – '00'
Script Counter '9F5F' '00'
Log of The Current Transaction x – '00…00'
(x=1...10 or more)
Application Transaction Counter '9F36' '0000'
Global MAC in Script Counter – '000000'
Bad Cryptogram Counter – '0000'
Table 6.25—Data Objects with a Fixed Initial Value (M/Chip 4 Version 1.1b)
Data Object Name Tag Value
Cumulative Offline Transaction Amount – '000000000000'
Note The transaction that causes one of the upper limits (Upper Cumulative Offline
Limit or Upper Consecutive Offline Limit) to be exceeded is not declined.
Note The setting of the 'International Transaction' and 'Domestic Transaction' bits to
(0,1,0) results in online contactless transactions on online-capable terminals.
With this setting, the PayPass – M/Chip 4 application will always generate an
ARQC during a contactless transaction on an online-capable terminal.
Issuers of the online-only profile should not set Application Control [1][7] "Skip CIAC-
default on CAT 3" in order to prevent offline transactions being approved by the card.
Note b Issuer Code Table Index is mandatory if Application Preferred Name is present.
Note c Optional data object containing the Device Type and proprietary non-payment
information (e.g. loyalty information). If proprietary non-payment information is
included, then the value of the Unique Identifier sub-field that is part of the Third
Party Data must be allocated by MasterCard. It is recommended to always
include Third Party Data with the relevant Device Type, even when there is no
proprietary information. In the latter case the Unique Identifier can be set to all
zeroes.
In US and Canada rRegions, inclusion of the Third Party Data, with Device Type,
is mandatory.
Note d Contains information to alert the terminal to functionality available on the card.
Note a The PCVC3 and PUNATC bit maps must only have non-zero bits that refer to
available positions in the discretionary data field of the corresponding Track
Data.
The least significant bit of the bit map must be set to zero.
Note b The number of non-zero bits in the PCVC3 bit maps must be greater than or
equal to 3.
Note c The number of non-zero bits in PUNATCTRACK1 minus the value of NATCTRACK1 :
must be greater than or equal to 2
should be greater than or equal to 3, and
must be less than or equal to 5.
It must be equal to the number of non-zero bits in PUNATCTRACK2 minus the
value of NATCTRACK2.
Note d The storage of the cardholder name in the Track 1 Data read via the contactless
interface is prohibited by MasterCard. It is therefore recommended to use a
space character followed by the surname separator (i.e. " /").
Note e The placeholders for the dynamic data in the discretionary data (i.e. at the
positions where the contactless reader stores the ATC, UN, CVC3 and nUN)
should be filled with zeroes (hexadecimal zeroes ('0') for Track 2 Data and ASCII
zeroes ('30') for Track 1 Data).
The least significant position of the discretionary data is used by the reader to
store nUN.
Note f If a PVV is encoded in the discretionary part of track 1 and track 2 on the
magnetic stripe and used for Online PIN verification, then this must also be
encoded in the Track 1 Data (tag '56') and Track 2 Data (tag '9F6B') read through
the contactless interface.
Note g If the issuer intends to make use of the on-behalf service for Dynamic CVC3
Validation, then the value of NATCTRACK1 and the value of NATCTRACK2 must be
greater than or equal to 3 for the CVC3 Validation in Stand-in Service, or
greater than or equal to 2 for the Dynamic CVC3 Pre-validation Service or the
Mapping Service (processing only option).
In both cases, a value of at least 4 for NATCTRACK1 and NATCTRACK2 is
recommended.
If the PAN Sequence Number is present in the discretionary data and if the PAN
Sequence Number is used for the derivation of KD CVC3, then the length of the
PAN Sequence Number must be maximum 1 significant digit.
Note h The values of Track 1 Data (tag '56') and Track 2 Data (tag '9F6B') read through
the contactless interface must not be identical to the corresponding value on
the magnetic stripe in order to prevent a counterfeit magnetic stripe being
created from data read from the contactless interface. The CVC1 found on the
magnetic stripe must not be repeated in Track 1 Data or Track 2 Data.
Note a It is strongly recommended to use for IVCVC3 TRACK1 the two least significant
bytes of the result of a MAC over the Track 1 Data as stored in Record 1, SFI 1.
In the same way IVCVC3TRACK2 should be the two least significant bytes of the
result of a MAC calculated over the Track 2 Data as stored in Record 1, SFI 1.
If the issuer intends to make use of the on-behalf service for Dynamic CVC3
Validation, then for IVCVC3 generation the method recommended above must
be used, and the placeholders for the dynamic data in the discretionary data of
Track 1 Data and Track 2 Data (i.e. at the positions where the reader stores the
ATC, UN, CVC3 and nUN) must be filled with zeroes (hexadecimal zeroes ('0') for
Track 2 Data and ASCII zeroes ('30') for Track 1 Data).
Note b It is strongly recommended to use for IVCVC3 generation the ISO/IEC 9797-1
MAC algorithm 3 with DES block cipher and an initial vector of zero (8 bytes).
If the issuer intends to make use of the on-behalf service for Dynamic CVC3
Validation, then this algorithm must be used.
7.7 Miscellaneous
Table 7.7—Miscellaneous Persistent Data Objects
Data Object Name Tag Value
Key Derivation Index – Determined by issuer
Application Life Cycle Data '9F7E' Depending on the possible separation between
the loading of the application code and the
personalization data on the hardware, only part
of the Application Life Cycle Data may be
personalized.
Log Format '9F4F' The content of records in the Log of
Transactions
Static CVC3TRACK1 'DA' '0000'
Static CVC3TRACK2 'DB' '0000'
Table 7.11—Data Objects with a Fixed Initial Value (M/Chip 4 Version 1.0)
Table 7.12—Data Objects with a Fixed Initial Value (M/Chip 4 Version 1.1.a)
Data Object Name Tag Value
Cumulative Offline Transaction Amount – '000000000000'
Consecutive Offline Transactions Number – '00'
Script Counter '9F5F' '00'
Log of The Current Transaction x – '00…00'
(x=1...10 or more)
Application Transaction Counter '9F36' '0000'
Global MAC in Script Counter – '000000'
Bad Cryptogram Counter – '0000'
Table 7.13—Data Objects with a Fixed Initial Value (M/Chip 4 Version 1.1b)
Data Object Name Tag Value
Cumulative Offline Transaction Amount – '000000000000'
Consecutive Offline Transactions Number – '00'
Script Counter '9F5F' '00'
Log of The Current Transaction x – '00…00'
(x=1...10 or more)
Application Transaction Counter '9F36' '0000'
AC Session Key Counter – '0000'
SMI Session Key Counter – '0000'
Bad Cryptogram Counter – '0000'
Security Limits Status 'DF02" '00'