Icc Personal

71
PERSONALIZATION DATA SPECIFICATIONS FOR DEBIT AND CREDIT ON CHIP © MasterCard International Incorporated August 1998

Transcript of Icc Personal

Page 1: Icc Personal

PERSONALIZATION DATASPECIFICATIONSFOR DEBIT AND CREDIT ON CHIP

© MasterCard International IncorporatedAugust 1998

Page 2: Icc Personal

Personalization Data Specification © 1998 MasterCard International IncorporatedAugust 1998

Notice: The information contained in this manual is proprietary andconfidential to MasterCard International Incorporated and itsmembers.

This material may not be duplicated, published, or disclosed, inwhole or in part, without the prior written permission ofMasterCard International Incorporated.

Trademarks: All products, names, and services are trademarks or registeredtrademarks of their respective companies.

Page 3: Icc Personal

Table of Contents

Personalization Data SpecificationsAugust 1998

i

ABBREVIATIONS AND NOTATIONS

Abbreviations ............................................................................. ivNotations ..................................................................................... v

SECTION 1 OBJECTIVE AND SCOPE

1.1 Purpose.............................................................................. 1-11.2 Objective and Scope .......................................................... 1-2

SECTION 2 REFERENCES

2.1 Related Information ........................................................... 2-1

SECTION 3 PERSONALIZATION DATA ELEMENTS

3.1 Organization ...................................................................... 3-13.2 Conventions ....................................................................... 3-13.3 Cardholder and Card Specific Data .................................... 3-3

3.3.1 Application Default Action........................................ 3-33.3.2 Application Effective Date ........................................ 3-43.3.3 Application Expiration Date ...................................... 3-43.3.4 Application Primary Account Number (PAN) ........... 3-53.3.5 Application PAN Sequence Number.......................... 3-53.3.6 Cardholder Name ...................................................... 3-53.3.7 Cardholder Name Extended....................................... 3-63.3.8 Data Authentication Code ......................................... 3-63.3.9 Language Preference ................................................. 3-73.3.10 Reference PIN......................................................... 3-73.3.11 SDA Tags for Signing ............................................. 3-83.3.12 Track 2 Discretionary Data...................................... 3-83.3.13 Track 2 Equivalent Data .......................................... 3-9

3.4 MCPA— Application Data ............................................... 3-103.4.1 Application Currency Code ..................................... 3-103.4.2 Application Currency Exponent .............................. 3-103.4.3 Application File Locator (AFL)............................... 3-113.4.4 Application Identifier (AID).................................... 3-123.4.5 Application Interchange Profile ............................... 3-133.4.6 Application Label .................................................... 3-14

Page 4: Icc Personal

Table of Contents

Personalization Data Specification © 1998 MasterCard International IncorporatedAugust 1998ii

3.4.7 Application Preferred Name .................................... 3-153.4.8 Application Priority Indicator.................................. 3-153.4.9 Application Reference Currency.............................. 3-163.4.10 Application Reference Currency Exponent ............ 3-163.4.11 Application Usage Control .................................... 3-173.4.12 Application Version Number ................................. 3-183.4.13 Issuer Country Code.............................................. 3-183.4.14 Processing Options Data Object List (PDOL)........ 3-193.4.15 Service Code ......................................................... 3-19

3.5 CVM/PIN Data................................................................ 3-203.5.1 Cardholder Verification Method (CVM) List........... 3-203.5.2 PIN Try Limit ......................................................... 3-21

3.6 Card Risk Management Data ........................................... 3-223.6.1 Card Risk Management Data Object List 1

(CDOL1) ....................................................................... 3-223.6.2 Card Risk Management Data Object List 2

(CDOL2) ....................................................................... 3-233.6.3 Issuer Action Code–Default..................................... 3-253.6.4 Issuer Action Code–Denial ...................................... 3-253.6.5 Issuer Action Code–Online...................................... 3-263.6.6 Lower Consecutive Offline Limit ............................ 3-263.6.7 Lower Cumulative Domestic Offline Transaction

Amount.......................................................................... 3-273.6.8 Maximum Domestic Offline Transaction

Amount.......................................................................... 3-273.6.9 Upper Consecutive Offline Limit............................. 3-283.6.10 Upper Cumulative Domestic Offline Transaction

Amount.......................................................................... 3-283.7 SDA-Related Data ........................................................... 3-29

3.7.1 Certification Authority Public Key Index ................ 3-293.8 DDA-Related Data........................................................... 3-30

3.8.1 Dynamic Data Authentication Data Object List(DDOL) ......................................................................... 3-30

3.8.2 Hash Algorithm Indicator........................................ 3-303.8.3 ICC Dynamic Data Length ...................................... 3-31

3.9 Additional Cryptographic Data (from Issuer) ................... 3-323.9.1 Cryptogram Version Number .................................. 3-323.9.2 Derivation Key Index .............................................. 3-323.9.3 Issuer Private Key ................................................... 3-333.9.4 Issuer Public Key Certificate ................................... 3-333.9.5 Issuer Public Key Exponent..................................... 3-343.9.6 Issuer Public Key Remainder .................................. 3-34

Page 5: Icc Personal

Table of Contents

Personalization Data SpecificationsAugust 1998

iii

3.9.7 Issuer Master Key for ICC CryptogramDEA Keys...................................................................... 3-34

3.9.8 Issuer Master Key for ICC MAC DEA Keys ........... 3-353.9.9 Issuer Master Key for ICC PIN DEA Keys.............. 3-35

3.10 Cryptographic/Internal Data ........................................... 3-363.10.1 Application Transaction Counter (ATC)................ 3-363.10.2 Cryptogram DEA Key ........................................... 3-373.10.3 ICC Asymmetric Secret Key Data ......................... 3-373.10.4 ICC Public Key Certificate .................................... 3-383.10.5 ICC Public Key Exponent ..................................... 3-383.10.6 ICC Public Key Remainder ................................... 3-383.10.7 Message Authentication Code (MAC)

DEA Key ....................................................................... 3-393.10.8 PIN DEA Key ....................................................... 3-393.10.9 Signed Static Application Data .............................. 3-403.10.10 Various Indicators/Counters ................................ 3-40

SECTION 4 EXAMPLE OF DATA STRUCTURE

4.1 Overview ........................................................................... 4-1

SECTION 5 PRIVATE CLASS TAGS

5.1 Overview ........................................................................... 5-1

GLOSSARY

Overview...................................................................... Glossary-1Terms ........................................................................... Glossary-1

Page 6: Icc Personal

Abbreviations and Notations

Personalization Data Specification © 1998 MasterCard International IncorporatedAugust 1998iv

ABBREVIATIONS USED IN THIS MANUAL

This manual uses the following abbreviations and notations. For definitions of these terms, referto the Glossary at the back of this document.

a Alphabetic character(s)AAC Application Authentication CryptogramAAR Application Authorization ReferralAC Application CryptogramADF Application Definition FileAFL Application File LocatorAID Application IdentifierAIP Application Interchange Profilean Alphanumeric character(s)ans Alphanumeric and special character(s)ARPC Authorization Response CryptogramARQC Authorization Request CryptogramATM Automated Teller Machineb Binary character(s)cn Compressed numeric character(s)CAM Card Authentication MethodCAT Cardholder Activated TerminalCDOL Card Risk Management Data Object ListCVC Card Validation CodeCVM Cardholder Verification MethodCVR Card Verification ResultsDDA Dynamic Data AuthenticationDDOL Dynamic Data Authentication Data Object ListDEA Data Encryption Algorithm (= DES)DES Data Encryption Standard (= DEA)EMV Europay, MasterCard, and VisaICC Integrated Circuit CardIEC International Electrotechnical CommissionISO International Organization for StandardizationLCOL Lower Consecutive Offline LimitLRC Longitudinal Redundancy CheckM MandatoryMAC Message Authentication CodeMCC Merchant Category CodeMCPA™ MasterCard Chip Payment Applicationn Numeric character(s), digitsNCA Length of the Certification Authority Public Key modulus

Page 7: Icc Personal

Abbreviations and Notations

Personalization Data SpecificationsAugust 1998

v

NI Length of the Issuer Public Key modulusNIC Length of the ICC Public Key modulusO OptionalPAN Primary Account NumberPIN Personal Identification NumberPOI Point of InteractionPSE Payment System EnvironmentR RecommendedRID Registered IdentifierRFU Reserved for Future UseSDA Static Data AuthenticationSFI Short File IdentifierSHA-1 Secure Hash Algorithm-1TC Transaction CertificateTLV Tag Length ValueUCOL Upper Consecutive Offline Limitvar. Variable

NOTATIONS

Values surrounded by single quotes are hexadecimal values. For example, a binary field that isone byte in length and has a value of zero would be represented as ‘00’.

Page 8: Icc Personal
Page 9: Icc Personal

Objective and Scope1.1 Purpose

Personalization Data SpecificationsAugust 1998

1-1

1.1 PURPOSE

This document is intended for issuers implementing the MasterCard Chip PaymentApplication (MCPA™ ). The MCPA enables card issuers to support MasterCard credit anddebit transactions, and Maestro® and Cirrus® debit transactions. MCPA is based on theEuropay, MasterCard, and Visa (EMV) specifications, which allows chip-based credit and debitcards issued under any of the three brands to be accepted by the same chip card terminalsworldwide, as magnetic-stripe cards are accepted on the same terminals.

The purpose of this document is to specify the data elements that need to be input to the firststage of the personalization process— the creation of an Application Load File (ALF).

+ Not all of these data elements will be input to the card. Some will be used togenerate card data.

MasterCard recommendations have been made wherever possible, to help guide issuers in theirselection. Issuers do not have to follow these recommendations if there are particular overridingreasons for alternatives.

The document addresses generic data requirements which are independent of any particular cardsupplier or card operating system.

The primary audience for this document is:

• MasterCard issuers intending to issue MCPA cards.

• Personalization bureaus intending to provide facilities for MCPA applications.

• Owners and developers of card operating systems.

• Developers of MCPA Application Load File (ALF) generation systems.

Page 10: Icc Personal

Objective and Scope1.2 Objective and Scope

Personalization Data Specification © 1998 MasterCard International IncorporatedAugust 19981-2

1.2 OBJECTIVE AND SCOPE

Issuers use data elements described in this document as input into an MCPA Application LoadFile (ALF) generation system. This system formats the data and generates the necessarycryptographic keys and other internal data required by a particular card operating system. Theoutput of an ALF generation system is a file of MCPA application load data that can be handedto a personalization bureau to load these applications into a batch of cards.

The specific input record formats required by different ALF generations systems will vary.However, they should all accept the data elements as described in this document. Further dataelements may be required to satisfy the requirements of particular card operating systems. Theoutput ALF file and record formats also will vary according to the requirements of the cardoperating system.

The ALF generation system may be located at the issuer or at a (secure) third-party bureau. Inthe latter case the transfer of sensitive data (such as, Issuer Private Key, Issuer Master DEAKeys, and Reference PIN) between the issuer and the bureau must be addressed separately. Thesecurity procedures for the transmission of data elements are outside the scope of this document.

In addition to the data elements that must be supplied by the issuer, this document includes a listof data elements which are created by the ALF generation system.

This document identifies data elements that are proprietary to MasterCard International. Otherdata elements are defined in the EMV ’96 ICC Specifications for Payment Systems, 30 June1996.

Page 11: Icc Personal

References2.1 Related Information

Personalization Data SpecificationsAugust 1998

2-1

2.1 RELATED INFORMATION

The following documents and resources provide information related to the subjects discussed inthis manual.

EMV96ICC EMV ’96 ICC Specifications for Payment Systems, 31 May 1998

MCIMCR Minimum Card Requirements for Debit and Credit on Chip, Version1.0, 24 October 1997— Published by MasterCard International

ISO 639:1988 Codes for the representation of names and languages

ISO 3166:1993 Codes for the representation of names of countries

ISO 4217:1990 Codes for the representation of currencies and funds

ISO/IEC 7813:1990 Identification cards— Financial transaction cards

ISO/IEC 7816-5:1994 Identification cards— Integrated circuit(s) cards with contacts—Part 5: Numbering system and registration procedure for applicationidentifiers

Contact the ISO Web site at www.iso.ch for more information.

The MasterCard Chip Card Help Desk also provides issuers with technical support. Contact theCard Help Desk via e-mail at [email protected].

Page 12: Icc Personal
Page 13: Icc Personal

Personalization Data Elements3.1 Organization

Personalization Data SpecificationsAugust 1998

3-1

3.1 ORGANIZATION

The data elements are organized into the following functional groups to facilitate understandingand management:

• Cardholder/Card-specific Data• MCPA— Application Data• Cardholder Verification Method/Personal Identification Number (CVM/PIN) Data• Card Risk Management Data• Static Data Authentication (SDA)-related Data• DDA-related Data*• Cryptographic/internal Data (issuer supplied)• Cryptographic/internal Data (created by Application Load File (ALF) system)

* Not required if issuer chooses to implement Static Data Authentication.

3.2 CONVENTIONS

The following conventions are used:

Name: (M) = Mandatory, (R) = Recommended, (O) = Optional

Format: For the format codes, see the “Abbreviation and Notation” section at thebeginning of this manual. For definition of the format codes see the“Glossary” section at the end of this manual.

Tag: Tag from EMV96ICC

Length: Expressed in bytes

Value: The values of bytes are shown as four-bit nibbles(hexadecimal characters) within the range ‘0’–‘9’ and ‘A’–‘F’.

When the length defined for the data object (Length above) is greater than the length of theactual data (Format above), the following rules apply:

• A data element in format “n” is right justified and padded with leading hexadecimalzeros.

• A data element in format “cn” is left justified and padded with trailing ‘F’ characters.

Page 14: Icc Personal

Personalization Data Elements3.2 Conventions

Personalization Data Specification © 1998 MasterCard International IncorporatedAugust 19983-2

• A data element in format “an” is left-justified and padded with trailing hexadecimalzeros.

• A data element in format “ans” is left-justified and padded with trailing hexadecimalzeros.

• When a nibble (four bits) is stored in a byte, it is right-justified and padded with leadinghexadecimal zeros.

See EMV96ICC, Annex B for more information.

Page 15: Icc Personal

Personalization Data Elements3.3 Cardholder and Card Specific Data

Personalization Data SpecificationsAugust 1998

3-3

3.3 CARDHOLDER AND CARD SPECIFIC DATA

This section contains data elements that are intended to be specific to a particular card. In thepersonalization process, it may be possible to load these data elements in a final customizationstage.

The following personalization data elements are included in section 3.3. This is a default list.Issuers may decide to make other data elements card-specific:

Application Default Action Data Authentication CodeApplication Effective Date Language preferenceApplication Expiration Date Reference PINApplication PAN Static Data Authentication (SDA) Tag for SigningApplication PAN Sequence Number Track 2 Discretionary DataCardholder Name Track 2 Equivalent DataCardholder Name Extended

3.3.1 Application Default Action (R)

Format b

Tag ‘DF00’ (See table in section 5.)

Length 2

Value Byte 1:

bit 8: ‘1’= If issuer authentication fails, transmit next transactiononline

bit 7: ‘1’= If issuer authentication fails, decline transaction(recommended)

bit 6: ‘1’= If issuer authentication is mandatory and noAuthorization Response Cryptogram (ARPC) received,decline transaction (recommended)

bit 5: ‘0’= RFUbit 4: ‘0’= RFUbit 3: ‘0’= RFUbit 2: ‘0’= If new card, transmit transaction onlinebit 1: ‘1’= If new card, decline if unable to transmit transaction

online

Page 16: Icc Personal

Personalization Data Elements3.3 Cardholder and Card Specific Data

Personalization Data Specification © 1998 MasterCard International IncorporatedAugust 19983-4

Byte 2: = Non-Domestic Control Factor (see the ICC ApplicationSpecification manual, paragraph 6.1.4.1). This is thepower of two by which the LCOL and UCOL are reducedfor non-domestic transactions. Default value is zero—‘00000000’.

Example: If LCOL = 10, UCOL = 20 and Non Domestic Control =’00000002’, the LCOL and UCOL would be divided by 4 (22)and the resulting non-domestic LCOL would be 2 (truncatedfrom 2.5) and the UCOL would be 5.

Description Data element indicating action for the card to take for certain exceptionconditions.

3.3.2 Application Effective Date (O)

Format n 6 (YYMMDD)

Tag ‘5F25’

Length 3

Value Cardholder data— input by issuer

Description Date from which the card application may be used. If this is the PrimaryApplication, the date must be the same as the effective date in other mediaon the card–embossing and magnetic stripe.

3.3.3 Application Expiration Date (M)

Format n 6 (YYMMDD)

Tag ‘5F24’

Length 3

Value Cardholder data— input by issuer

Description Date after which the card application expires. If this is the PrimaryApplication, the date must be the same as the expiration date in othermedia on the card— embossing and magnetic stripe. The date also isincluded in Track 2 Equivalent Data (YYMM).

Page 17: Icc Personal

Personalization Data Elements3.3 Cardholder and Card Specific Data

Personalization Data SpecificationsAugust 1998

3-5

3.3.4 Application Primary Account Number (PAN) (M)

Format cn var.— up to 19

Tag ‘5A’

Length var.— up to 10

Value Cardholder data— input by issuer

Description Valid cardholder account number. Also included in Track 2 EquivalentData.

3.3.5 Application PAN Sequence Number (M*)

Format n 2

Tag ‘5F34’

Length 1

Value 1–9

Description Identifies and differentiates cards and cardholders that have the same PAN.

* This data element is mandatory when more than one cardholder has the same PAN.

3.3.6 Cardholder Name (M*)

Format ans 2–26

Tag ‘5F20’

Length 2–26

Value Cardholder data— input by issuer

Page 18: Icc Personal

Personalization Data Elements3.3 Cardholder and Card Specific Data

Personalization Data Specification © 1998 MasterCard International IncorporatedAugust 19983-6

Description Indicates cardholder name according to ISO 7813 (magnetic stripe—Track 1). Must be consistent with the name in other media on the card.

* This data element is mandatory when the cardholder name appears onthe magnetic stripe Track 1.

3.3.7 Cardholder Name Extended (O)

Format ans 27–45

Tag ‘9F0B’

Length 27–45

Value Cardholder data— input by issuer

Description Indicates whole cardholder name when greater than 26 characters,according to ISO 7813 (magnetic stripe— Track 1). Must be consistentwith the name in other media on the card.

3.3.8 Data Authentication Code (R*)

Format b

Tag ‘9F45’

Length 2

Value Issuer assigned value

Description Issuer-assigned value recommended for inclusion in Signed ApplicationData used to indicate that static offline data authentication was performed.

* The DAC is not put on the card, it is only included with the Public Key Certificate.

Page 19: Icc Personal

Personalization Data Elements3.3 Cardholder and Card Specific Data

Personalization Data SpecificationsAugust 1998

3-7

3.3.9 Language Preference (M)

Format an 2

Tag ‘5F2D’

Length 2–8

Value Cardholder data— input by issuer

Description One to four languages stored in order of preference. Language codes arespecified in ISO 639. For example, English = “en”.

3.3.10 Reference PIN (O/M*)

Format cn 4–12

Tag ‘DF01’ (See table in section 5.)

Length 2–6 bytes

Value Cardholder data— input by issuer, encrypted in an 8-byte block

+ PIN stored in the card that is compared with the PIN,entered by the cardholder.

Description The recommended format of the plaintext data block is:

Length of PIN (4-12 digits) 1 byte (cn)PIN Data 7 bytes (cn, left-justified, ‘F’ filled)

The key used to encrypt the data block is required input to the ALFgeneration system, which uses a secure cryptographic device and secureloading procedures.

* This data element is optional for MasterCard (credit) and Cirrus (ATM) cards, butmandatory for Maestro (debit) card.

Page 20: Icc Personal

Personalization Data Elements3.3 Cardholder and Card Specific Data

Personalization Data Specification © 1998 MasterCard International IncorporatedAugust 19983-8

3.3.11 SDA Tags for Signing (M)

Format b

Tag ‘DF02’ (See table in section 5)

Length var.— up to 17 (recommended)

The following are the recommended tags:

Application Effective Date ‘5F25’Application Expiration Date ‘5F24’Application Identifier ‘4F’Application Interchange Profile ‘82’Application PAN ‘9F07’Application PAN Sequence Number ‘5A’Application Usage Control ‘5F34’Issuer Action Code-Default ‘9F0D’Issuer Action Code-Denial ‘9F0E’Issuer Action Code-Online ‘9F0F’

Value

Description The tags indicate the data to be signed for Static Data Authentication(SDA)— see MCIMCR, table 6-2. The data is signed using the IssuerPrivate Key, to produce the Signed Static Application Data (see 3.10.9).SDA is the EMV offline card authentication method (CAM) using staticdata— Offline Static CAM (see MCIMCR, section 6).

3.3.12 Track 2 Discretionary Data (O)

Format cn

Tag ‘9F20’

Length var.

Value Cardholder data— input by issuer

Description Discretionary Data from Track 2 of the magnetic stripe according toISO/IEC 7813. The value of CVC must be 000. This means that thediscretionary data will be different from that on the magnetic stripe.

Page 21: Icc Personal

Personalization Data Elements3.3 Cardholder and Card Specific Data

Personalization Data SpecificationsAugust 1998

3-9

+ Since Track 2 Equivalent Data is mandatory and this includes Track 2Discretionary Data, it is unlikely that this data element will be necessary.

3.3.13 Track 2 Equivalent Data (M)

Format cn var.— up to 37

Tag ‘57’

Length var.— up to 19

Value Cardholder data— input by issuer

Description Contains the data elements of track 2 of the magnetic stripe according tothe ISO.IEC 7813, excluding start sentinel, end sentinel, and longitudinalredundancy check (LRC).

The PAN, Expiration Date, Service Code, PVV shall be identical to thedata encoded on track 2 of the magnetic stripe. The value of CVC mustbe 000. This means that the discretionary data will be different from thaton the magnetic stripe.

+ CVC, a magnetic stripe security feature, serves littlepurpose for chip-based transactions, and may actuallycompromise magnetic stripe security when included inelectronic commerce transactions.

Page 22: Icc Personal

Personalization Data Elements3.4 MCPA— Application Data

Personalization Data Specification © 1998 MasterCard International IncorporatedAugust 19983-10

3.4 MCPA— APPLICATION DATA

This section contains the following personalization data elements:

Application Currency Code Application Reference CurrencyApplication Currency ExponentApplication File Locator (AFL)Application Identifier (AID)Application Interchange ProfileApplication LabelApplication Preferred NameApplication Priority Indicator

Application Reference Currency ExponentApplication Usage ControlApplication Version NumberIssuer Country CodeProcessing Options Data Object List (PDOL)Service Code

3.4.1 Application Currency Code (M*)

Format n 3

Tag ‘9F42’

Length 2

Value Cardholder data— input by issuer

Description Indicates the currency in which the account is managed, accordingto ISO 4217.

* Mandatory if issuer uses the recommended card risk management functions for MaximumDomestic Offline Transaction Amount or Cumulative Amount Check.

3.4.2 Application Currency Exponent (M*)

Format n 1

Tag ‘9F44’

Length 1

Value = 2 for decimal currencies

Description Indicates the implied position of the decimal point according to ISO 4217.

* Mandatory if issuer uses the card risk management functions for Maximum Domestic OfflineTransaction Amount or Cumulative Amount Check.

Page 23: Icc Personal

Personalization Data Elements3.4 MCPA— Application Data

Personalization Data SpecificationsAugust 1998

3-11

3.4.3 Application File Locator (AFL) (M)

Format b

Tag ‘94’

Length 8

Byte 1:

Bits 8–4: = SFI–Default value = ‘00001’Bits 3–1: = ‘000’

Byte 2: First record number to be read for that SFI (never equal tozero)

Byte 3: Last record number to be read for that SFI (shall be greaterthan or equal to value in Byte 2)

Byte 4: Number of consecutive records signed in SignedApplication Data, starting with record number in Byte 2.

+ Based on the recommended SDA tags forSigning (see 3.3.11), and a typical recordsize, this byte value should be ‘01’.

Value

Bytes 1–4 may be repeated for other files, or sequences ofrecords within a file.

Description Indicates the location (SFI, range of records) of the file area(s) related to agiven application.

Page 24: Icc Personal

Personalization Data Elements3.4 MCPA— Application Data

Personalization Data Specification © 1998 MasterCard International IncorporatedAugust 19983-12

3.4.4 Application Identifier (AID) (M)

Format b

Tag ‘4F’

Length 7— in this version of the specification.

+ Allow for maximum length of 16 bytes.

Value ‘A000000004xxxx’

Description Identifies the application as described in ISO 7816-5. The first five bytesare the MasterCard Registered Identifier (RID) = ‘A000000004’. Thenext two bytes (xxxx above) are the MasterCard applications identifier(PIX in ISO terms).

The following values are currently valid:

‘A0000000041010’ = MasterCard (credit) card

‘A0000000046000’ = Cirrus card

‘A0000000043060’ = Maestro (debit) card.

Page 25: Icc Personal

Personalization Data Elements3.4 MCPA— Application Data

Personalization Data SpecificationsAugust 1998

3-13

3.4.5 Application Interchange Profile (M)

Format b

Tag ‘82’

Length 2

The following values are mandatory (see MCIMCR, section 5.3):

Byte 1:

bit 8: ‘0’= Initiate (not supported)bit 7: ‘1’= Application authentication is supported (may be zero for

ATM-only cards)bit 6: ‘0’= RFUbit 5: ‘1’= Cardholder verification is supportedbit 4: ‘1’= Terminal risk management is to be performedbit 3: ‘0’ or ‘1’ = Issuer authentication is/is not supported. The

recommended value is ‘1’— supported.bit 2: ‘0’= RFUbit 1: ‘0’= RFU

Value

Byte 2: ‘00000000’— RFU

Description Indicates the capabilities of the card to support specific functions in theapplication.

Page 26: Icc Personal

Personalization Data Elements3.4 MCPA— Application Data

Personalization Data Specification © 1998 MasterCard International IncorporatedAugust 19983-14

3.4.6 Application Label (M)

Format an

Tag ‘50’

Length Up to 16

Value See table below

Description Description of the application specified by MasterCard, and resident in theterminal. The following labels are currently valid:

PIX Label*

‘1010’ MasterCard

‘6000’ Cirrus

‘3060’ Debit

* The labels can be expressed in upper and lower case letters.

Page 27: Icc Personal

Personalization Data Elements3.4 MCPA— Application Data

Personalization Data SpecificationsAugust 1998

3-15

3.4.7 Application Preferred Name (R)

Format ans

Tag ‘9F12’

Length Up to 16

Value See table below

Description Description of the application specified by the issuer and located in thecard. If present, this is the name to be displayed to the cardholder.

+ The issuer should use the same name as the ApplicationLabel wherever possible.

PIX Label*

‘1010’ MasterCard

‘6000’ Cirrus

‘3060’ Debit

* The labels can be expressed in upper and lower case letters.

3.4.8 Application Priority Indicator (R)

Format b

Tag ‘87’

Length 1

bit 8: ‘1’ = Application shall not be selected without cardholderconfirmation (recommended)

bits 7–5: ‘000’ = RFU

Value

bits 4–1: ‘0001’ = Priority of the application. Recommended value =‘0001’— highest priority.

Description Indicates the priority of a given application or group of applications in adirectory.

Page 28: Icc Personal

Personalization Data Elements3.4 MCPA— Application Data

Personalization Data Specification © 1998 MasterCard International IncorporatedAugust 19983-16

3.4.9 Application Reference Currency (O)

Format 3n per currency, up to 4 currencies

Tag ‘9F3B’

Length 2–8

Value Issuer assigns value

Description One to four currencies used between terminal and card when TransactionCurrency Code differs from Application Currency Code.

+ Reference currencies may not be supported interminals. MasterCard does not recommend relianceon reference currencies for card decision making.

3.4.10 Application Reference Currency Exponent (O*)

Format n per currency, up to 4 currencies

Tag ‘9F43’

Length 1–4

Value Issuer assigns value

Description Indicates position of decimal point for 1–4 Application ReferenceCurrencies (see 3.4.9).

* Mandatory if the issuer uses the Application Reference Currency (Tag ‘9F3B’).

Page 29: Icc Personal

Personalization Data Elements3.4 MCPA— Application Data

Personalization Data SpecificationsAugust 1998

3-17

3.4.11 Application Usage Control (M)

Format b

Tag ‘9F07’

Length 2

Value See table below

Byte Bit Meaning MasterCard Maestro Cirrus

1 8 Domestic cash transaction 1 0 or 1 0 or 1

7 International cash transaction 1* 1* 1*

6 Domestic goods 1 0 or 1 0 or 1

5 International goods 1* 1* 0

4 Domestic services 1 0 or 1 0 or 1

3 International services 1* 1* 0

2 ATM’s 1 0 or 1 1

1 Terminals other than ATM’s 1 1 0

2 8 Domestic cashback allowed 0 0 0

7 International cashback allowed 0 0 0

6 RFU 0 0 0

5 RFU 0 0 0

4 RFU 0 0 0

3 RFU 0 0 0

2 RFU 0 0 0

1 RFU 0 0 0

* May be 0 for domestic use only cards.

Description Indicates issuer-specified restrictions on the geographic usage and servicesallowed for the card application.

Page 30: Icc Personal

Personalization Data Elements3.4 MCPA— Application Data

Personalization Data Specification © 1998 MasterCard International IncorporatedAugust 19983-18

3.4.12 Application Version Number (M)

Format b

Tag ‘9F08’

Length 2

Value ‘0001’

Description Version number assigned by MasterCard for the application. The value‘0001’ is valid for 1998. Beginning in 1999, issuers should contact theChip Card Help Desk.

3.4.13 Issuer Country Code (M)

Format n 3

Tag ‘5F28’

Length 2

Value Issuer assigns value

Description Indicates the country of the issuer, represented according to ISO 3166.

Page 31: Icc Personal

Personalization Data Elements3.4 MCPA— Application Data

Personalization Data SpecificationsAugust 1998

3-19

3.4.14 Processing Options Data Object List (PDOL) (O)

Format an

Tag ‘9F38’

Length var.— example below is 14 bytes

The following list of values (tags and lengths) are an example (seeMCIMCR, Table 5-1):

‘9F3501’ Terminal Type‘9F3303’ Terminal Capabilities‘9F1502’ Merchant Category Code1 (MCC)‘9C01’ Transaction Type

Value

‘9F1A02’ Terminal Country Code

Description List of terminal resident data objects, (tag and length) needed by theIntegrated Circuit Card (ICC) in processing the GET PROCESSINGOPTIONS command.

3.4.15 Service Code (M)

Format n 3

Tag ‘5F30’

Length 2

Value Cardholder data— input by issuer

Description Service code as defined on Track 2 of the magnetic stripe according toISO/IEC 7813. Also included in Track 2 Equivalent Data.

1 EMV96ICC uses codes for this value from ISO 8583:1993.

Page 32: Icc Personal

Personalization Data Elements3.5 CVM/PIN Data

Personalization Data Specification © 1998 MasterCard International IncorporatedAugust 19983-20

3.5 CVM/PIN DATA

This section contains the following personalization data elements:

Cardholder Verification Method (CVM) List PIN Try Limit

3.5.1 Cardholder Verification Method (CVM) List (M)

Format b

Tag ‘8E’

Length var.— up to 32 (recommended)

Bytes 1–4: = ‘00000000’— Amount “X” (unsupported)

Bytes 5–8: = ‘00000000’— Amount “X” (unsupported)

Bytes 9–10: Card Verification Rules (see table below)

Byte 9 = CVM CodeByte 10 = CVM Condition Code

Value

MasterCard strongly recommends that issuers use the following values.

Cardholder Verification Rules for MasterCard® Cards:

CVM M/O Byte 9 Byte 10 Terminal Type

Offline PIN O ‘41’ ‘03’ ATM, Attended POI, CAT1

Signature M ‘5E’ ‘03’ Attended POI

Online PIN M ‘42’ ‘03’ ATM, CAT1

No CVM M ‘1F’ ‘03’ CAT2, CAT3

Page 33: Icc Personal

Personalization Data Elements3.5 CVM/PIN Data

Personalization Data SpecificationsAugust 1998

3-21

Cardholder Verification Rules for Maestro® Cards:

CVM M/O Byte 9 Byte 10 Terminal Type

Offline PIN* M ‘41’ ‘03’

Online PIN M ‘02’ ‘03’

ATM, Attended POI, CAT1,Bank Terminal

Signature O ‘30’ ‘03’ Attended POI

* Waiver for terminals in parts of Europe.

Cardholder Verification Rules for Cirrus® Cards:

CVM M/O Byte 9 Byte 10 Terminal Type

Offline PIN O ‘41’ ‘03’

Online PIN M ‘02’ ‘00’

ATM, Bank Terminal

Description Identifies a prioritized list of cardholder verification methods supported bythe card application.

3.5.2 PIN Try Limit (M*)

Format b

Tag ‘DF03’ (See table in section 5.)

Length 1

Value ‘03’— recommended value by MasterCard.

Description Allowed consecutive wrong PINs. The value of the PIN try limit also willbe used for the initial setting of the PIN Try Counter field (Tag: ‘9517’).

* Mandatory if the issuer supports offline PIN.

Page 34: Icc Personal

Personalization Data Elements3.6 Card Risk Management Data

Personalization Data Specification © 1998 MasterCard International IncorporatedAugust 19983-22

3.6 CARD RISK MANAGEMENT DATA

This section contains the following personalization data elements:

Card Risk Management Data Object List 1 (CDOL1)Card Risk Management Data Object List 2 (CDOL2)Issuer Action Code–DefaultIssuer Action Code–DenialIssuer Action Code–OnlineLower Conservative Office LimitLower Cumulative Domestic Offline Transaction Amount**Maximum Domestic Offline Transaction Amount**Upper Consecutive Offline Limit (UCOL)Upper Cumulative Domestic Offline Transaction Amount

** MasterCard Proprietary Data Element

3.6.1 Card Risk Management Data Object List 1 (CDOL1) (M*)

Format an

Tag ‘8C’

Length 38 bytes

Value MasterCard recommends the following data elements (tags and lengths).MasterCard derived this list from the list of ICC data elements which theacquirer must return to the issuer, minus the data elements output by theGENERATE AC command (Application Cryptogram, ATC, CryptogramInformation Data, Issuer Application Data):

Page 35: Icc Personal

Personalization Data Elements3.6 Card Risk Management Data

Personalization Data SpecificationsAugust 1998

3-23

Tag/Length Description Note(s)

‘9F0305’ Amount, Other 1

‘9F0206’ Amount, Transaction 1

‘8202’ Application Interchange Profile 1

‘9505’ Terminal Verification Results 1,2

‘9A03’ Transaction Date 1

‘9C01’ Transaction Type 1

‘9F3704’ Unpredictable Number 1

‘9F1A02’ Terminal Country Code 3

‘5F2A02’ Transaction Currency Code 3

+ 1: Data element listed as mandatory in both authorization and clearingmessages (see MCIMCR, section 11.6).

2: Terminal Verification Results is mandatory if Card VerificationResults (CVR) is implemented, in order to report the results of cardauthentication. CVR is a MasterCard proprietary data element usedin card risk management, and output from the card in the IssuerApplication Data.

3: Data element not listed as mandatory in MCIMCR, section 11.6. Thisis an error and an errata has been raised. The data element willeventually be mandatory.

Description List of data objects (tag and length) to be passed to the card applicationwith the first GENERATE AC command.

3.6.2 Card Risk Management Data Object List 2 (CDOL2) (M*)

Format an

Tag ‘8D’

Length 38 bytes

Page 36: Icc Personal

Personalization Data Elements3.6 Card Risk Management Data

Personalization Data Specification © 1998 MasterCard International IncorporatedAugust 19983-24

Value MasterCard recommends the following list of data elements (tags andlengths). This list is derived from the list of ICC data elements which theacquirer is obliged to return to the issuer, plus the Authorization ResponseCode, and minus the data elements output by the GENERATE ACcommand (Application Cryptogram, ATC, Cryptogram Information Data,Issuer Application Data):

Tag/Length Description Note(s)

‘8A02’ Authorization Response Code 4

‘9F0306’ Amount, Other 1

‘9F0206’ Amount, Transaction 1

‘8202’ Application Interchange Profile 1

‘9505’ Terminal Verification Results 1,2

‘9A03’ Transaction Date 1

‘9C01’ Transaction Type 1

‘9F3704’ Unpredictable Number 1

‘9F1A02’ Terminal Country Code 3

‘5F2A02’ Transaction Currency Code 3

+ 1: Data element listed as mandatory in both authorization and clearingmessages (see MCIMCR, section 11.6).

2: Terminal Verification Results is mandatory if Card VerificationResults (CVR) is implemented, in order to report the results of cardauthentication. CVR is a MasterCard proprietary data element usedin card risk management, and output from the card in the IssuerApplication Data.

3: Data element not listed as mandatory in MCIMCR, section 11.6. Thisis an error and an errata has been raised. The data element willeventually be mandatory.

4: Mandatory

Description List of data elements (tag and length) to be passed to the card applicationwith the second GENERATE AC command.

Page 37: Icc Personal

Personalization Data Elements3.6 Card Risk Management Data

Personalization Data SpecificationsAugust 1998

3-25

3.6.3 Issuer Action Code–Default (M)

Format b

Tag ‘9F0D’

Length 5

MasterCard recommends the following values (see MCIMCR,section 10.2):

Byte 1: ‘F8’Byte 2: ‘40’Byte 3: ‘64’Byte 4: ‘20’ for MasterCard; ‘A0’ for Maestro

Value

Byte 5: ‘00’

Description Specifies the issuer’s conditions that cause the transaction to be declined ifit might have been approved online, but the terminal is unable to processthe transaction online.

3.6.4 Issuer Action Code–Denial (M)

Format b

Tag ‘9F0E’

Length 5

MasterCard recommends the following values (see MCIMCR,section 10.2):

Byte 1: ‘00’Byte 2: ‘10’Byte 3: ‘88’Byte 4: ‘00’

Value

Byte 5: ‘00’

Description Specifies the issuer’s conditions that cause the transaction to be declinedwithout attempting to go online.

Page 38: Icc Personal

Personalization Data Elements3.6 Card Risk Management Data

Personalization Data Specification © 1998 MasterCard International IncorporatedAugust 19983-26

3.6.5 Issuer Action Code–Online (M)

Format b

Tag ‘9F0F’

Length 5

MasterCard recommends the following values (see MCIMCR,section 10.2):

Byte 1: ‘F8’Byte 2: ‘E0’Byte 3: ‘64’Byte 4: ‘F8’

Value

Byte 5: ‘00’

Description Specifies the issuer’s conditions that cause a transaction to be transmittedonline.

3.6.6 Lower Consecutive Offline Limit (R)

Format b

Tag ‘9F14’

Length 1

Value Issuer assigns value

Description Issuer-specified data element indicating a preference for maximumnumber of consecutive offline transactions allowed for the cardapplication before the terminal goes online.

+ Terminal risk management and, possibly, card riskmanagement will use this data element.

Page 39: Icc Personal

Personalization Data Elements3.6 Card Risk Management Data

Personalization Data SpecificationsAugust 1998

3-27

3.6.7 Lower Cumulative Domestic Offline Transaction Amount (R)(MasterCard Proprietary Data Element)

Format b

Tag ‘9F50’

Length 6

Value Issuer assigns value

Description Issuer specified data element indicating a preference for the maximumcumulative offline transaction amount allowed for the card applicationbefore the terminal goes online.

3.6.8 Maximum Domestic Offline Transaction Amount (R)(MasterCard Proprietary Data Element)

Format b

Tag ‘9F51’

Length 6

Value Issuer assigns value

Description Issuer-specified data element indicating maximum offline transactionamount.

Page 40: Icc Personal

Personalization Data Elements3.6 Card Risk Management Data

Personalization Data Specification © 1998 MasterCard International IncorporatedAugust 19983-28

3.6.9 Upper Consecutive Offline Limit (UCOL) (R)

Format b

Tag ‘9F23’

Length 1

Value Issuer assigns value

Description Issuer specified data element indicating the required maximum numberof consecutive offline card transactions for this application allowed beforethe transaction goes online.

+ This data element will be used in terminal riskmanagement, and may also be used in card riskmanagement.

3.6.10 Upper Cumulative Domestic Offline Transaction Amount (R)(MasterCard Proprietary Data Element)

Format b

Tag ‘9F52’

Length 6

Value Issuer assigns value

Description Issuer specified data element indicating the required maximumcumulative offline amount allowed for the application before thetransaction goes online.

Page 41: Icc Personal

Personalization Data Elements3.7 SDA-Related Data

Personalization Data SpecificationsAugust 1998

3-29

3.7 SDA-RELATED DATA

This section contains information of the Certification Authority Public Key Index data element.

3.7.1 Certification Authority Public Key Index (M)

Format b

Tag ‘8F’

Length 1

Value ‘01’

Description Identifies the certification authority’s public key in conjunction with theRegistered Identifier (RID) for use in static and dynamic dataauthentication.

Page 42: Icc Personal

Personalization Data Elements3.8 DDA-Related Data

Personalization Data Specification © 1998 MasterCard International IncorporatedAugust 19983-30

3.8 DDA-RELATED DATA

This section includes the following personalization data elements:

Dynamic Data Authentication Data Object List (DDOL) ICC Dynamic Data LengthHash Algorithm Indicator

3.8.1 Dynamic Data Authentication Data Object List (DDOL) (M*)

Format an

Tag ‘9F49’

Length 11

MasterCard recommends the following values:

‘950206’ Amount Authorized‘9F1C08’ Terminal Identification‘9A03’ Transaction Date

Value

‘9F3704’ Unpredictable Number

Description List of data objects (tag and length) used for dynamic data authentication.

* Mandatory, if DDA supported.

3.8.2 Hash Algorithm Indicator (M*)

Format b

Tag ‘DF04’ (See table in section 5.)

Length 1

Value ‘01’ = SHA-1 algorithm

Description Algorithm used to compress data prior to signing for dynamic dataauthentication.

* Mandatory if DDA supported.

Page 43: Icc Personal

Personalization Data Elements3.8 DDA-Related Data

Personalization Data SpecificationsAugust 1998

3-31

3.8.3 ICC Dynamic Data Length (M*)

Format b

Tag ‘DF05’ (See table in section 5.)

Length 1

Value ‘08’— for version 1 of the MasterCard Debit and Credit Specification

Description Length of the ICC Dynamic Data generated/stored by the ICC.

* Mandatory, if DDA supported.

Page 44: Icc Personal

Personalization Data Elements3.9 Additional Cryptographic Data (From Issuer)

Personalization Data Specification © 1998 MasterCard International IncorporatedAugust 19983-32

3.9 ADDITIONAL CRYPTOGRAPHIC DATA (FROM ISSUER)

This section includes the following personalization data elements:

Cryptogram Version NumberDerivation Key IndexIssuer Private KeyIssuer Public Key Certificate,Issuer Public Key Exponent

Issuer Public Key RemainderIssuer Master Keys:

– for ICC Cryptogram DEA Keys– for ICC MAC DEA Keys– for ICC PIN DEA Keys

3.9.1 Cryptogram Version Number (M)

Format b

Tag ‘DF06’ (See table in section 5.)

Length 1

Value ‘01’

Description Data element indicating the version of the TC/AAC/ARQC algorithmused by the application that is transmitted in the Issuer Application Data.MasterCard assigns this value.

3.9.2 Derivation Key Index (M)

Format b

Tag ‘DF07’ (See table in section 5.)

Length 1

Value ‘01’ in 1998. Beginning in 1999, check with the Chip Card Help Desk.

Description Indicates derivation keys (Issuer Master Keys— see 3.9.7, 3.9.8, and 3.9.9)used to produce the various ICC DEA keys.

Page 45: Icc Personal

Personalization Data Elements3.9 Additional Cryptographic Data (From Issuer)

Personalization Data SpecificationsAugust 1998

3-33

3.9.3 Issuer Private Key (M)

Format b

Tag

Length NI (= 96 in version 1 of the MCPA specifications)

Value Issuer assigns value

Description Used to produce the Signed Static Application Data (see 3.10.9), and tosign the ICC Public Key Certificate (see 3.10.4).

+ The input of the Issuer Private Key requires it bedone using a secure cryptographic device and usingsecure procedures.

3.9.4 Issuer Public Key Certificate (M)

Format b

Tag ‘90’

Length NCA (= 128 in this version 1 of the MCPA specifications)

Value Issuer assigns value

Description Issuer’s public key certified by a certification authority for use in static ordynamic data authentication.

Page 46: Icc Personal

Personalization Data Elements3.9 Additional Cryptographic Data (From Issuer)

Personalization Data Specification © 1998 MasterCard International IncorporatedAugust 19983-34

3.9.5 Issuer Public Key Exponent (M)

Format b

Tag ‘9F32’

Length 1

Value Issuer assigns value

Description Exponent used to verify signed data.

3.9.6 Issuer Public Key Remainder (M)

Format b

Tag ‘92’

Length NI - NCA + 36 (= 4 in this version of the MasterCard Debit and CreditSpecification)

Value Issuer assigns value

Description Remaining digits of the issuer’s Public Key modulus.

3.9.7 Issuer Master Key for ICC Cryptogram DEA Keys (M)

Format b

Tag

Length 16

Value Issuer assigns value

Description A double-length master DEA key used to derive all ICC Cryptogram DEAkeys (see 3.10.2), using the Application PAN and its sequence number asdiversification data. The double-length key is required input to the ALFgeneration system, which uses a secure cryptographic device and secureloading procedures.

Page 47: Icc Personal

Personalization Data Elements3.9 Additional Cryptographic Data (From Issuer)

Personalization Data SpecificationsAugust 1998

3-35

3.9.8 Issuer Master Key for ICC MAC DEA Keys (M)

Format b

Tag

Length 16

Value Issuer assigns value

Description A double-length master DEA key used to derive all ICC MAC DEA keys(see 3.10.7), using the Application PAN and its sequence number asdiversification data. The double-length key is required input to the ALFgeneration system, which uses a secure cryptographic device and secureloading procedures.

3.9.9 Issuer Master Key for ICC PIN DEA Keys (M)

Format b

Tag

Length 16

Value Issuer assigns value

Description A double-length master DEA key used to derive all ICC PIN DEA keys(see 3.10.8), using the Application PAN and its sequence number asdiversification data. The double-length key is required input to the ALFgeneration system, which uses a secure cryptographic device and secureloading procedures.

Page 48: Icc Personal

Personalization Data Elements3.10 Cryptographic/Internal Data

Personalization Data Specification © 1998 MasterCard International IncorporatedAugust 19983-36

3.10 CRYPTOGRAPHIC/INTERNAL DATA

Since these data elements can be created by the ALF generation system the issuer does NOTnormally need to be input them. However, depending on the issuer’s system configurations andsecurity requirements, many of the fields may be generated prior to input to the ALF system.Such fields might include the diversified DEA keys (Cryptogram DEA Key, MAC DEA Key,PIN DEA Key), ICC Asymmetric Secret Key Data, ICC Public Key Certificate/Exponent/Remainder, Signed Static Authentication Data. In this case, the Issuer Private Key(see 3.9.3) and the Issuer Master DEA Keys (see 3.9.7, 3.9.8, and 3.9.9) are not required.

This section includes the following personalization data elements:

Application Transaction Counter (ATC)Cryptogram DEA Key *ICC Asymmetric Secret Key DataICC Public Key CertificateICC Public Key Exponent

ICC Public Key RemainderMessage Authentication Code (MAC) DEA Key *PIN DEA Key *Signed Static Application DataVarious indicators/counters

* If these data elements are input to the ALF generation system, they must be encrypted usinga Key Encryption Key (KEK). This KEK is also required input to the ALF generationsystem, which uses a secure cryptographic device and secure loading procedures.

3.10.1 Application Transaction Counter (ATC) (M)

Format b

Tag ‘9F36’

Length 2

Value ‘0000’

Description Transaction counter maintained by the application in the card. The ALFsystem should set this to zero (new card).

Page 49: Icc Personal

Personalization Data Elements3.10 Cryptographic/Internal Data

Personalization Data SpecificationsAugust 1998

3-37

3.10.2 Cryptogram DEA Key (M)

Format b

Tag ‘DF0B’ (See table in section 5.)

Length 16

Value Issuer assigns value

Description A double-length DEA key used for Application Cryptogram generationusing the GENERATE AC command to produce ARQC, AAC, AAR andTC cryptograms. The key also is used to verify incoming cryptograms(ARPC), using the EXTERNAL AUTHENTICATE command.

3.10.3 ICC Asymmetric Secret Key Data (M)

Format b

Tag ‘DF0C’ (See table in section 5.)

Length = 5NIC/2 (if Chinese Remainder Theorem is used)= 2 NIC (with standard exponentiation).

Where NIC is the length of the ICC Public Key modulus. NIC = 768, 896,or 1024 bits (96, 112, or 128 bytes) for 1998. Beginning in 1999, checkwith the Chip Card Help Desk.

Value Issuer assigns value

Description The data necessary to enable the application to sign critical data fordynamic data authentication in response to an INTERNALAUTHENTICATE command.

Page 50: Icc Personal

Personalization Data Elements3.10 Cryptographic/Internal Data

Personalization Data Specification © 1998 MasterCard International IncorporatedAugust 19983-38

3.10.4 ICC Public Key Certificate (M)

Format b

Tag ‘9F46’

Length NI

Value Issuer assigns value

Description ICC Public Key certified by the issuer using the Issuer Private Key.

3.10.5 ICC Public Key Exponent (M)

Format b

Tag ‘9F47’

Length 1

Value Issuer assigns value

Description Exponent used to verify the signed dynamic application data.

3.10.6 ICC Public Key Remainder (M)

Format b

Tag ‘9F48’

Length NIC – NI + 42

Value Issuer assigns value

Description Remaining digits of the ICC Public key modulus.

Page 51: Icc Personal

Personalization Data Elements3.10 Cryptographic/Internal Data

Personalization Data SpecificationsAugust 1998

3-39

3.10.7 Message Authentication Code (MAC) DEA Key (R)

Format b

Tag ‘DF0D’ (See table in section 5.)

Length 16

Value Issuer assigns value

Description A double-length DEA key used to support Secure Messaging for Integrityand Authentication in an Issuer Script message. The key is used to verifythe MAC in the script message.

3.10.8 PIN DEA Key (R)

Format b

Tag ‘DF0E’ (See table in section 5.)

Length 16

Value Issuer assigns value

Description A double-length DEA key used to support the confidentiality requirementin Secure Messaging for Issuer Script processing. The key is used todecipher the enciphered PIN data component in the PINCHANGE/UNBLOCK command message.

Page 52: Icc Personal

Personalization Data Elements3.10 Cryptographic/Internal Data

Personalization Data Specification © 1998 MasterCard International IncorporatedAugust 19983-40

3.10.9 Signed Static Application Data (M)

Format b

Tag ‘93’

Length 40–128 Bytes (= NI — length of the Issuer Public Key modulus)

Value Issuer assigns value

Description Digital signature on critical application parameters. The signature ischecked in static data authentication.

3.10.10 Various Indicators/Counters (M)

The following data elements need to be created in the ALF generation process. The formats andvalues of the data elements will depend on the particular card operating system.

• Application Status (unblocked/blocked/permanently blocked)

• PIN Lock Status

• PIN Installation Status

• PIN Retry Counter

• Personalization Date

Page 53: Icc Personal

Example of Data Structure4.1 Overview

Personalization Data SpecificationsAugust 1998

4-1

4.1 OVERVIEW

This section is intended for developers of chip card operating systems, Application Load File(ALF) systems, and card loading systems.

The data elements described in section 3 are input to the card personalization process. Thissection describes how the data elements output by the ALF system might be configured withinthe chip. The data structure in the chip will depend on the card operating system.

The following discussion provides an example of how the data can be structured. The MCPAapplication static data is divided into four areas:

Area 1: Application Control Data

This data consists of data elements that control the MCPA application program. This dataincludes the command table used to verify the commands, and control vectors pointing to codemodules. The data in this area does not need to be altered, either when the application data isconfigured, or at any subsequent time.

Area 2: Symmetric/Asymmetric Key Data

The MCPA application program uses key-related data to generate cryptograms. Thecryptograms are used by the:

• application to verify the input data

• issuer to verify the transaction data

• terminal to authenticate the application

Examples: Cryptogram DEA Key, MAC DEA Key, PIN DEA Key, ICC Asymmetric SecretKey Data, Hash Algorithm Indicator, ICC Dynamic Data Length.

Page 54: Icc Personal

Example of Data Structure4.1 Overview

Personalization Data Specification © 1998 MasterCard International IncorporatedAugust 19984-2

Area 3: Application Operational Data

These data elements indicate the status of the application, and define the operation of theapplication. The terminal accesses the data issuing GET DATA or GET PROCESSINGOPTIONS commands.

Examples: Application Status, PIN Lock Status, PIN Installed Status, AIP, AFL, ApplicationDefault Action, Lower/Upper Consecutive Offline Limits, and Lower/UpperCumulative Domestic Offline Transaction Amounts.

+ Area 3 also includes a Record Table used by the READ RECORD command toaccess data in Area 4. Each record in the table includes SFI, Record Number,and Address of Record Start, Length of Record. The entry for the PSE must usea separate SFI.

Area 4: Issuer Data

The issuer supplies this data, which is required by the application and the terminal. The variablelength data elements are stored in TLV format.

The Issuer Data is held in a single file with SFI = 1. The size of each record is variable, but islimited by the size of the chip card’s output buffer. The terminal accesses this data issuing aREAD RECORD command.

The initial record must contain the Track 2 Equivalent Data and the Cardholder Name. Therecord may contain other data elements. The second record contains the data elements that areused to check the SDA signature. The order of subsequent data elements/records is notsignificant.

Examples: Application PAN, Expiration Date, Application Version No., CDOL1, CDOL2,Data required for SDA or DDA, CVM List, Issuer Action Codes, ApplicationCurrency Code, Application Usage Control, Issuer Country Code etc.

The PSE Directory (DIR) File would include AID, Application Label, Application PreferredName, and Application Priority Indicator.

Page 55: Icc Personal

Private Class Tags5.1 Overview

Personalization Data SpecificationsAugust 1998

5-1

5.1 OVERVIEW

Most of the data elements described in section 3 have tags that have been allocated inEMV96ICC. These MCPA tags ensure interoperability of MCPA transactions, and are usedduring transactions.

The data elements not used during an EMV transaction do not have MCPA allocated tags.

Since many issuers will want to present the data in their personalization input files in Tag-Length-Value (TLV) format2, the following Private Class tags have been allocated. The use ofthese tags is optional. MasterCard included this list of tags to reduce the number of ad hoc andincompatible tag allocations by Issuers and Personalization bureaus.

Reference Description Tag

3.3.1 Application Default Action ‘DF00’

3.3.10 Reference PIN ‘DF01’

3.3.11 SDA Tags for Signing ‘DF02’

3.5.2 PIN Try Limit ‘DF03’

3.8.2 Hash Algorithm Indicator ‘DF04’

3.8.3 ICC Dynamic Data Length ‘DF05’

3.9.1 Cryptogram Version Number ‘DF06’

3.9.2 Derivation Key Index ‘DF07’

3.10.2 Cryptogram DEA Key ‘DF0B’

3.10.3 ICC Asymmetric Secret Key Data ‘DF0C’

3.10.7 MAC DEA Key ‘DF0D’

3.10.8 PIN DEA Key ‘DF0E’

2 For a description of TLV coding see EMV96ICC, Annex C— Data Objects

Page 56: Icc Personal
Page 57: Icc Personal

GlossaryOverview

Personalization Data SpecificationsAugust 1998

Glossary-1

OVERVIEW

This section defines various terms, concepts, acronyms, and abbreviations that are usedthroughout the Business Functional Requirements for Debit and Credit on Chip manual. Theseterms and definitions appear for convenience only and are not intended to serve, nor shouldserve, as definitions for any legal or technical purpose. MasterCard specifically reserves theright to add to, delete from, or otherwise change any term appearing herein and specificallycautions members and agents therefor not to rely upon any term appearing herein for any legal ortechnical purpose.

TERMS

AACSee application authentication cryptogram.

ACSee application cryptogram.

account numberA unique sequence of numbers assigned to a card account that identifies the issuer and type offinancial transaction card.

acquirerA member that maintains the merchant relationship and acquires the data relating to a transactionfrom the merchant or card acceptor.

ADFSee application definition file.

AFLSee application file locator.

AIDSee application identifier.

AIPSee application interchange profile.

applicationThe protocol between the card and the terminal and its related set of data.

Page 58: Icc Personal

GlossaryTerms

Personalization Data Specifications © 1998 MasterCard International IncorporatedAugust 1998Glossary-2

application authentication cryptogram (AAC)A value computed by the ICC for a declined transaction, not for online authorization.

application cryptogram (AC)A cryptogram returned by an IC card to a terminal in response to a GENERATE AC command.The GENERATE AC is issued by the terminal to request an IC card decision to either: accept,decline, or go online. This command also communicates terminal resident information to the ICcard, which is used in this decision process.

application currency codeIndicates the currency in which the account is managed according to ISO 4217.

application definition file (ADF)The ADF provides the entry point to one or more application elementary files (AEFs). The ADFidentifies an application and contains important data used by the terminal during the applicationselection process. The ADF tree structure:

• Enables the attachment of data files to an application.• Ensures the separation between applications.• Allows access to the logical structure of an application by ADF selection.

application effective dateThe date from which the application can be used.

application elementary file (AEF)Set of data units or records that share the same file identifier. It cannot be the parent of anotherfile. An AEF in the range1–10, contains one or more primitive Basic Encoding Rules— TagLength Value (BER-TLV) data objects grouped into constructed BER-TLV data objects(records).

application expiration dateThe date after which, the application expires. In other words, the last day on which theapplication may be used.

application file locator (AFL)The Application File Locator contains data associated with the selected application and identifiesthe files and records to be used for processing a transaction.

Page 59: Icc Personal

GlossaryTerms

Personalization Data SpecificationsAugust 1998

Glossary-3

application identifier (AID)A numbering system and registration procedure for identifying specific companies and theirchip-based products, as defined by ISO/IEC 7816-5. The Application Identifier is comprised oftwo components: the Registered Application Identifier or “RID” and the Proprietary ApplicationIdentifier Extension or PIX.

application interchange profile (AIP)Specifies the application functions that are supported by the IC card. The terminal attempts toexecute only those functions that the IC card supports.

application labelMnemonic associated with the AID according to ISO/IEC 7816-5. This field is up to 16characters in length. The application label allows for global interoperability, but the applicationpreferred name, if available, overrides the application label. See Application Preferred Name.

application preferred namePreferred mnemonic associated with the AID, as specified by the issuer. This field is up to 16characters in length. The application preferred name, if available, overrides the application label.See Application Label.

application reference currency1-4 currency codes to be used between the terminal and the ICC in cases where the terminalcurrency code is different from the application currency code. Each code is 3 digits inaccordance with ISO 4217.

application transaction counter (ATC)Counter maintained by the application in the ICC (incrementing the ATC is managed by theICC).

application version numberVersion number assigned by the payment system for the application.

ARPCSee authorization response cryptogram.

ARQCSee authorization request cryptogram.

ATCSee application transaction counter.

Page 60: Icc Personal

GlossaryTerms

Personalization Data Specifications © 1998 MasterCard International IncorporatedAugust 1998Glossary-4

ATMSee Automated Teller Machine.

authorizationApproval of a transaction by or on behalf of an issuer according to defined operationsregulations. The merchant receives, via telephone or authorization terminal, this approval toprocess the transaction.

authorization request cryptogram (ARQC)A value computed by the ICC for online application authentication.

authorization response cryptogram (ARPC)A value that defines the disposition of a message.

automated teller machine (ATM)An unattended, chip or magnetic stripe reading terminal that dispenses cash, accepts deposits andloan payments, and enables a bank customer to order transfers among accounts and makeaccount inquiries.

binary character(s) (b)A computer format that uses a series of bits to store numeric values in which all values fromhexadecimal ‘00’ to hexadecimal ‘FF’ are acceptable.

byteA single unit of information, such as a letter, number, or other character. A byte is made up ofeight bits. Through arrangement of the bits 0 and 1 values, the byte may express any of 256characters.

CAMSee card authentication method.

cardA rectangular plastic medium used to carry information relating to its issuer and user. A creditcard, charge card, bankcard, ATM/debit card, or the account associated with any such card that isissued by a licensee of the Associations. By incorporating multiple payment options on onecard, members can offer value-added services to their cardholders.

Page 61: Icc Personal

GlossaryTerms

Personalization Data SpecificationsAugust 1998

Glossary-5

card authentication method (CAM)The process to determine if a card is genuine.

In MasterCard Cash, offline authentication occurs when information is exchanged between theprocessor on the chip card and the POI terminal to determine card validity; online authenticationoccurs when information is exchanged between the processor on the chip card and the issuer'shost system.

card risk management data object list 1 (CDOL1)List of data objects (tag and length) to be passed to the ICC in the first generated applicationcryptogram command.

card risk management data object list 2 (CDOL2)List of data objects (tag and length) to be passed to the ICC in the second generated applicationcryptogram command.

card validation code (CVC)A two-part card security feature. CVC 1 is a 3-digit code encoded on track 1 and track 2 in threecontiguous positions in the "discretionary data" field of a magnetic stripe on a MasterCard card.CVC 2 differs from CVC1 and is indent printed into the secure signature panel on the card. TheCVC is intended to inhibit the alteration of card data and enhance the authentication of the card.

card verification results (CVR)Proprietary data element used by the card to store the results of card risk management. This datacan be communicated to the issuer.

cardholderThe authorized user of a card issued by a licensed member.

cardholder activated terminal (CAT)A customer-activated chip or magnetic stripe reading terminal, (usually unattended), thatdispenses a product or provides a service, and that is an Automated Dispensing Machine/Level 1,Self-Service Terminal/Level 2, Limited Amount Terminal/Level 3, or In-Flight CommerceTerminal/Level 4 in accordance with MasterCard rules.

cardholder verification method (CVM)A system and/or technology used to verify the authenticity of the cardholder (i.e., use of a PIN).

CATSee cardholder activated terminal.

Page 62: Icc Personal

GlossaryTerms

Personalization Data Specifications © 1998 MasterCard International IncorporatedAugust 1998Glossary-6

CDOL1See card risk management data object list 1.

CDOL2See card risk management data object list 2.

certificateA code usually generated via cryptography, which represents several pieces of information abouta transaction, such as the amount, card issuer number, terminal identifier, etc. The certificate,instead of the simple amount of the transaction, is transmitted from the card to the terminal,making it difficult for counterfeiters or unscrupulous merchants to defraud the system. If fraud issuspected in the system, the certificate provides the audit trail.

certification authorityTrusted third party that establishes a proof that links a public key and other relevant informationto its owner.

chipA small square of thin, semiconductor material that has been chemically processed to have aspecific set of electrical characteristics such as circuits, storage, and/or logic elements. Themicroprocessor chip has an operating memory, a programming memory, and a data memory thatallows internal processing to take place and provides additional storage capacity.

chip cardA plastic card into which one or more integrated circuits are inserted. The chip card conforms toall ISO standards.

CirrusCirrus System Incorporated, a wholly owned subsidiary of MasterCard InternationalIncorporated, operates the international ATM sharing association known as the "Cirrus® ATMNetwork."

clearingThe process of exchanging financial transaction details between an acquirer and an issuer tofacilitate posting of a cardholder's account and reconciliation of a customer's settlement position.

closed systemA card system, involving a single card issuer that can be used to access services or purchaseproducts at a single or multiple service providers. The opposite of an Open System.

Page 63: Icc Personal

GlossaryTerms

Personalization Data SpecificationsAugust 1998

Glossary-7

commandA message sent by the terminal to the ICC that initiates an action and solicits a response from theICC.

compressed numeric characters (cn)Numeric data that is left justified and padded with trailing ‘FF’ characters.

cnSee compressed numeric characters.

credit cardA plastic card bearing an account number assigned to a cardholder with a credit limit that can beused to purchase goods and services, and to obtain cash disbursements on credit, for which acardholder is subsequently billed by an issuer for repayment of the credit extended at once or onan installment basis.

cryptogramThe output from the process of transforming cleartext into ciphertext for security or privacy.

CVCSee card validation code.

CVMSee cardholder verification method.

CVVSee card verification value.

data encryption algorithm (DEA)A cryptographic algorithm adopted by the National Bureau of Standards for data security.Encryption scrambles PINs (personal identification numbers) and transaction data for safetransmission.

data encryption standard (DES)An encryption standard approved for secure messaging and is defined in ISO 8731-1, ISO 8372,and ISO/IEC 10116.

DDOLSee Dynamic Data Authentication Data Object List.

Page 64: Icc Personal

GlossaryTerms

Personalization Data Specifications © 1998 MasterCard International IncorporatedAugust 1998Glossary-8

debit cardA plastic card used to initiate a debit transaction. In general, these transactions are usedprimarily to purchase goods and services and to obtain cash, for which the cardholder's assetaccount is debited by the issuer.

DEASee data encryption algorithm.

DESSee data encryption standard.

digital signatureAn asymmetric cryptographic transformation of data that allows the recipient of the data to provethe origin and integrity of the data, and protect the sender and the recipient of the data againstforgery by third parties, and the sender against forgery by the recipient.

Dynamic Data Authentication Data Object List (DDOL)List of data objects (tag and length) to be passed to the ICC in the internal AuthenticateCommand.

embossingCharacters raised in relief from the front surface of a card.

EMVEuropay International S.A., MasterCard International Incorporated, and Visa InternationalService Association.

encryptionThe technique of modifying a known bit stream on a transmission line so that it appears to be arandom sequence of bits to an unauthorized observer. It often is done automatically in theterminal or computer before data is transmitted.

functionA process accomplished by one or more commands and resultant actions that are used to performall or part of a transaction.

GENERATE AC (command)The command, GENERATE AC, stands for “to generate an application cryptogram”. Thiscommand is issued by the terminal and used when exchanging risk management data betweenthe terminal and the IC card. The IC card’s response communicates to the terminal the IC carddecision to either: accept, decline, or go online.

Page 65: Icc Personal

GlossaryTerms

Personalization Data SpecificationsAugust 1998

Glossary-9

hybrid cardA card that contains both a magnetic stripe and a microprocessor chip.

ICCSee Integrated Circuit Card.

IECSee International Electrotechnical Commission

integrated circuit card (ICC)An International Organization for Standardization (ISO) standard card with an embeddedintegrated circuit chip containing memory and optional logic capability. Also called a smart cardor chip card.

interchangeThe exchange of transaction data between acquirers and issuers in accordance with MasterCardrules.

interchange feeA fee applied to an interchange transaction, applicable to the two members participating in thetransaction as issuer and acquirer.

International Electrotechnical Commission (IEC)Formerly known as the International Electromechanical Commission, this group works with theInternational Organization for Standardization (ISO) and covers the field of electrical andelectronic engineering, with all other subject areas being attributed to ISO. ISO collaboratesclosely with the IEC on all matters of electrotechnical standardization.

International Organization for Standardization (ISO)An international body that provides standards for financial transactions and telecommunicationmessages. ISO works in conjunction with the Consultive Committee for International Telephoneand Telegraph (CCITT) for standards that impact telecommunications. ISO supports specifictechnical committees and work groups to promulgate and maintain financial services industrystandards, such as bank identification numbers and merchant category codes.

interoperabilityWithin the product range of MasterCard International, the brand/product (i.e., MasterCardcredit, Maestro , Cirrus ) should have the same characteristics everywhere as perceived by thecardholder. The ability of computers, electronic products, and services from different vendors,manufacturers, associations, and organizations to effectively work together in an openenvironment. Also, compliant with the Joint Integrated Circuit Card and TerminalSpecifications For Payment Systems; also known as the EMV ‘96 Specifications.

Page 66: Icc Personal

GlossaryTerms

Personalization Data Specifications © 1998 MasterCard International IncorporatedAugust 1998Glossary-10

ISOSee International Organization for Standardization

issuerCardholder’s bank or non-bank which has issued a credit, charge, ATM and/or debit card to anindividual or cardholder, receives transaction information from MasterCard International,reflects transaction and outstanding balance information, and carries consumer loans in the formof bankcard accounts. The issuer is responsible for: resolving cardholder disputes, handlingcardholder information requests, and processing cardholder refunds, as warranted. The issuerselects the card risk management parameters and other cardholder specific data and personalizesthis on the chip card. The entity that issues the card, controls the allocation of the areas ofmemory to application providers and provides the cardholder information common to allapplications.

issuer country codeIndicates the country of the issuer according to ISO 3166.

keyA sequence of symbols that controls the operation of a cryptographic transformation.

language preferenceOne to four languages stored in order of preference, each represented by 2 alphabeticalcharacters according to ISO 639.

LCOLSee lower consecutive offline limit.

LRCSee longitudinal redundancy check.

longitudinal redundancy check (LRC)A character recorded on a magnetic track and used to check the integrity of data read from thetrack (defined in ISO 7811 for ISO standard identification cards).

lower consecutive offline limit (LCOL)Issuer-specified preference for the maximum number of consecutive offline transactions for agiven ICC application allowed in a terminal with online capability.

MACSee message authentication code.

Page 67: Icc Personal

GlossaryTerms

Personalization Data SpecificationsAugust 1998Glossary-11

magnetic stripeThe magnetically encoded stripe on the bankcard plastic that contains information pertinent tothe cardholder account. The physical and magnetic characteristics of the magnetic stripe arespecified in ISO Standards 7810, 7811, and 7813.

MasterCard Chip Payment Application (MCPA™ )

The payment application loaded on a chip card operating system that provides the capability toprocess MasterCard, Maestro, and Cirrus transactions.

MCCSee merchant category code.

MCPA™

See MasterCard Chip Payment Application.

merchantA retailer, or any other person, firm, or corporation that (pursuant to a merchant agreement)agrees to accept card products, when properly presented.

merchant category code (MCC)Four-digit classification codes used in authorization, clearing, and other transactions or reports toidentify the type of merchant.

messageA set of data elements used to exchange information between institutions (or their agents). Nocommunications (header, trailer, protocol, or character code) or security implications areassumed or identified.

message authentication code (MAC)A symmetric cryptographic transformation of data that protects the sender and the recipient ofthe data, against forgery by third parties.

offlineAn operating mode in which terminals or ATMs are not connected to a central computer source.Responses are governed by the parameters or guidelines set within the terminal or supportingdevice as defined by the issuer. The accessibility of information is not in a live environment,meaning that current active files are not being viewed during the time the transaction isconducted.

Page 68: Icc Personal

GlossaryTerms

Personalization Data Specifications © 1998 MasterCard International IncorporatedAugust 1998Glossary-12

onlineAn operating mode in which terminals or ATMs are connected to a central computer system andhave access to the database for authorization, inquiry, and file changes. Live files are accessedfor each transaction.

PANSee primary account number.

personal identification number (PIN)A four- to 12-character secret alphanumeric code that enables an issuer to positively authenticatethe cardholder for the purpose of approving an ATM or terminal transaction occurring at a point-of-interaction device.

personalizationPersonalization is the process whereby the issuer defines parameters that are programmed in thememory within the chip during card production to manage risk and tailor the product on anindividual or segmented cardholder basis. The POI terminal through a dialogue with the chipautomatically executes the issuer specified pre-programmed parameters set forth. Hence, thecard issuer can exercise control over their card.

PINSee Personal Identification Number.

PIN verificationA procedure that enables the issuer to validate the cardholder identity when making acomparison with the PIN and cardholder account number.

POISee point of interaction.

point of interaction (POI)The location at which a transaction occurs. Also referred to a point of sale (POS) or point ofservice.

primary account number (PAN)The number that is embossed, encoded, or both, on a MasterCard card that identifies the issuerand the particular cardholder account. The PAN consists of a major industry identifier, issueridentifier, individual account identifier, and check digit.

private keyIn public-key cryptography, the half of a public-key/private-key pair that is known only to theencoder that resides on the user's system.

Page 69: Icc Personal

GlossaryTerms

Personalization Data SpecificationsAugust 1998Glossary-13

processorAn organization that is connected with MasterCard International Incorporated and providesauthorization and/or clearing and settlement services on behalf of a member.

public keyIn public-key cryptography, the half of a public-key/private-key pair that is known to the publicand can be used to decrypt messages that were encoded by the corresponding private key.

public key certificateThe public key information of an entity signed by the Certification Authority and thereby cannotbe forged.

responseA message returned by the ICC to the terminal after the processing of a command messagereceived by the ICC.

registered identifier (RID)The first five bytes of the Application Identifier (AID) as assigned according to ISO/IEC 7816-5.This code identifies the specific company that provides the chip-based product. For MasterCard,the code is ‘A000000004’.

RIDSee registered identifier.

rulesRefers to the “international operating regulations” inclusive of standards set for the brandestablished by MasterCard International.

scriptA command or a string of commands transmitted by the issuer to the terminal for the purpose ofbeing sent serially to the ICC as commands.

SDASee static data authentication.

secret keyA key used with symmetric cryptographic techniques and usable only by a set of specifiedentities.

Page 70: Icc Personal

GlossaryTerms

Personalization Data Specifications © 1998 MasterCard International IncorporatedAugust 1998Glossary-14

secure hash algorithm-1 (SHA-1)A one-way cryptographic function which takes a message of less than 264 bits in length andproduces a 160-bit message digest. A message digest is a value generated for a message ordocument that is unique to that message, and is sometimes referred to as a fingerprint” of thatmessage or data. Once a message digest is computed, any subsequent change to the original datawill, with a very high probability, cause a change in the message digest, and the signature willfail to verify. This process is used by MasterCard to compress large data strings to a 20-bytelength which is used in a cryptographic process. The reduced data length relieves computationalrequirements for data encryption. SHA-1 provides greater security than the original Secure HashAlgorithm (SHA), which had security flaws.

service codeThe service code is a three digit value on the magnetic stripe (i.e., tracks 1 and 2) and chip of abankcard which gives instructions to the terminal about the conditions under which the card maybe used. Service codes are defined by ISO.

SFISee short file identifier.

SHA-1See secure hash algorithm-1.

short file identifier (SFI)A data object used as an abbreviated file identifier. It is a binary field with the three high orderbits set to zero.

static data authentication (SDA)Authentication of an IC card as a result of interaction between a hybrid card acceptance deviceand a chip card, without online contact to the issuer. The card is passive and the terminal isactive: the terminal verifies the card’s fixed cryptographic signature.

tag length value (TLV)Standardized structure defined by ISO to identify and define data within the IC Card where:

Tag: Data object identifierLength: Length expressed in bytesValue: Actual data identified by the tag

terminalA device that allows a user to send data to, receive data from, and invoke functions of a remotecomputer system.

Page 71: Icc Personal

GlossaryTerms

Personalization Data SpecificationsAugust 1998Glossary-15

terminal country codeIndicates the country of the terminal, represented according to ISO 3166

terminal verification resultsStatus of the different functions as seen from the terminal.

TLVSee tag length value.

transaction counterA transaction counter controls the number of transactions that can be processed offline before anonline request for authorization is initiated (often referred to as a “1 in N” parameter). This is anissuer-defined parameter.

UCOLSee upper consecutive offline limit.

upper consecutive offline limit (UCOL)Issuer-specified preference for the maximum number of consecutive offline transactions for agiven ICC application allowed in a terminal without online capability.