EMV

EUROPEAN COMMITTEE
FOR
BANKING STANDARDS
SIG 106-2
Version 2
STANDARD IMPLEMENTATION GUIDELINE:
CONSISTENT EUROPEAN
IMPLEMENTATION OF ISO 8583: 1993
Part 2: ICC Specific Issues
E C B S
Issued: March 1999
European Committee for Banking Standards. March 1999.
Avenue de Tervueren, 12, 1040, Brussels.
Not to be copied without attribution, and subject to the restriction
under the confidentiality clause below.
Comments or enquiries on the document may be addressed to the
Secretary General at the above address.
This Standard Implementation Guideline is Public and may be copied
or otherwise distributed provided the text is not used directly as a
source of profit.
ECBS SIG 106, March 1999
Consistent European Implementation of ISO 8583 : 1993
Part 2 V2: ICC Specific Issues
_________________________________________________________________________
__________________________________________________________________________________________
ECBS Avenue de Tervueren 12 B 1040 Brussels Tel: +32 2 733 35 33 Fax: +32 2 736 49 88
e-mail: ecbs@ecbs.org
Contents
1. PURPOSE AND JUSTIFICATION............................................................................................................. 1
2. SCOPE OF THE SIG................................................................................................................................... 2
2.1. THE RECOMMENDATIONS IN SIG PART 1 APPLY TO THE AREAS OF ICC APPLICATION. ..................................... 2
2.2. PRE-PAID CARDS AND NON-ACCOUNT BASED CARDS EXCLUDED. ..................................................................... 2
2.3. ICC TO ISSUER COMMUNICATION................................................................................................................. 2
2.4. 1987 AND 1993 VERSIONS OF ISO 8583. IMPLEMENTATIONS BY EPS-NET AND VISANET .............................. 2
3. REFERENCES............................................................................................................................................. 3
4. BACKGROUND TO THE DEVELOPMENT OF THE SIG..................................................................... 4
4.1. RELATIONSHIP WITH ISO AND OTHER PUBLISHED STANDARDS....................................................................... 4
4.2. EUROPAY, MASTERCARD, AND VISA (EMV) STANDARDS ACTIVITY.............................................................. 4
4.3. EPS-NET AND VISANET IMPLEMENTATIONS ................................................................................................. 4
4.4. PUBLIC DOMAIN STANDARDS ACTIVITY. ........................................................................................................ 5
4.5. ADOPTION OF ASN.1................................................................................................................................... 5
5. KEY PRINCIPLES ADOPTED IN THIS SIG............................................................................................ 6
5.1. HIERARCHY OF STANDARDS CONFORMANCE. ................................................................................................. 6
5.2. ICC IMPACT AFFECTS MORE THAN FIELDS IN ISO 8583 THAN FIELD 55. ......................................................... 6
5.3. NEED FOR GREATER PRECISION..................................................................................................................... 7
5.4. MINIMISE THE NEED FOR PRIVATE BIT CODE ASSIGNMENTS............................................................................. 7
6. STANDARD REQUIREMENTS LAID DOWN BY THIS ECBS SIG...................................................... 8
6.1. CODING OF ASN.1 DATA OBJECTS............................................................................................................... 8
6.2. TABLE OF DATA ELEMENTS. ........................................................................................................................ 8
APPENDIX....................................................................................................................................................... 9
TABLE 1: DATA ELEMENTS.................................................................................................................................. 9
TABLE 2: FIELD DESCRIPTIONS .......................................................................................................................... 13
_________________________________________________________________________
__________________________________________________________________________________________
1
1. PURPOSE AND JUSTIFICATION
This Part 2 SIG is designed to serve the same purpose as Part 1 (SIG 106: 1996), namely to provide
means for a consistent European implementation of ISO 8583: 1993 on essential matters of acquirer to
issuer communication not covered by the International Standard, or where the Standard is not clear. The
SIG is application independent. A consistent European implementation, however, will provide technical
support for a goal of interoperability between communicating parties, wherever commercial
interoperability is an application goal.
The SIG identifies implementation differences of individual card schemes. In designing the SIG,
particular attention has been paid not only to the standard specifications of EMV, but also to the EPS-
Net and VisaNet implementations. Implementation variations by these two card schemes are identified.
The rightmost two columns of Table 1 demonstrate the extent of the variation between the
implementations of the two card schemes, and the extent of the task presented to an individual financial
institution in trying to achieve interoperability between the two schemes. One of the objectives of this
SIG is to assess the possibility of eliminating at least some of these variations, and also to place some
restraint on what otherwise would appear to be a course of continuous divergence.
The decision of ISO/TC68/SC6 to initiate a revision of ISO 8583 was welcomed, and provides an
opportunity to include ICC data format specifications.
_________________________________________________________________________
__________________________________________________________________________________________
2
2. SCOPE OF THE SIG
2.1. The recommendations in SIG Part 1 apply to the areas of ICC application.
The recommendations in SIG Part 1 were specifically drawn up for the area of magnetic stripe
originated transactions. The recommendations in Part 1 are to be taken as equally applying to the
area of ICC originated transactions.
2.2. Pre-paid cards and non-account based cards excluded.
The ISO 8583 specifications, as well as those of EMV and Europay, describe solutions applicable
to account-based Debit (Pay Now) and Credit (Pay Later) card products. This SIG covers
precisely the same scope. Recent decisions by ECBS/TC1 have extended the scope of European
card standards activity to cover Pre-paid (Pay Before) Cards. Standard recommendations for the
use of ISO 8583 with the European Electronic Purse as specified in TCD 110, will be developed in
a Part 3 to this SIG. The scope of Parts 1 and 2 of this SIG excludes the pre-paid Card.
2.3. ICC to Issuer communication
ISO 8583's scope limits itself to acquirer to issuer communication. The main function of the data
elements being specified in bit 55 is not only to enhance the effective use of ICC data transmitted
between acquirer and issuer, but, at the same time, to support the communication of data between
other parties in the ICC/terminal to issuer chain. Hence, in dealing with the ICC, the scope of this
SIG is sometimes wider than the limited area of acquirer to issuer communication.
2.4. 1987 and 1993 versions of ISO 8583. Implementations by EPS-Net and
VisaNet
Both EPS-Net and VisaNet currently implement principally the 1987 version of 8583, with some
extensions to the 1993 version (e.g. Europay's implementation for clearing and for stop listing).
Since the 1993 version gave no guidance on how its newly assigned bit 55 should be used to
implement an ICC originated transaction, the card schemes had no real incentive to upgrade to the
1993 text. Implementing bit 55 while not upgrading from the 1987 version is a wholly practical
solution from the perspective of the individual card scheme, but does involve some interpretation of
the 1987 text, and this has led to inconsistent implementations. This SIG offers guidance to card
schemes and to individual ECBS member banks faced with these variations, on preferred means of
achieving a consistent implementation.
_________________________________________________________________________
__________________________________________________________________________________________
3
3. REFERENCES
1. ECBS SIG 106-1: January 1997 Consistent European Implementation of ISO 8583: 1993
Part 1: Magnetic Stripe Originated Transactions

2. ISO 7816-4 : 1995 Identification cards - Integrated circuit cards with contacts -
Part 4: Inter-industry commands for interchange
3. ISO 7816-6 : 1996 Identification cards - Integrated circuit cards with contacts -
Part 6: Inter-industry data elements
4. ISO 8583 : 1987 Bank card originated messages - Interchange message
specifications - Content for financial transactions
5. ISO 8583 : 1993 Financial transaction card originated messages - Interchange
message specifications
6. ISO 8825 : 1990 Information technology - Open systems interconnection -
Specification of basic encoding rules for abstract syntax
notation one (ASN.1)
7. CEN prENV1750
(decision awaited)
Machine readable cards, related device interfaces and
operations.
8. Europay, MasterCard, and Visa
(EMV): May 31 1998
Integrated Circuit Card Specification for Payment Systems
(Blue)
(EMV): May 31 1998
Integrated Circuit Card Terminal Specification for Payment
Systems (Red)

(EMV): May 31 1998
Integrated Circuit Card Application Specification for Payment
Systems (Green)
(EMV)
Errata to EMV Specifications
12. Visa : August 1996 Visa ICC Specification (VIS Version 1.3)
Part 2 - Chip Card Payment Service
13. VisaNet Processing Systems
December 1996
Chip Card Payment Service (CCPS).
V.I.P System BASE II System. Release 1.
14. Europay : March 1998 Authorisation System Release 98.2. Member Interface
Specifications.
15. Europay : March 1998 ECCSS Release 98.2
16. Europay : November 1996 Programme Chip - Pay Now and Pay Later. Functional
Architecture
Enquiries concerning the availability of Europay and EMV documentation should be made to:
Europay Documentation Centre
198A Chausse de Tervueren
1410, Waterloo, Belgium
Visa Information Centre
PO Box 253
London W8 5TE, UK
_________________________________________________________________________
__________________________________________________________________________________________
4
4. BACKGROUND TO THE DEVELOPMENT OF THE SIG
In preparing this Part 2 SIG, there are a number of background issues of which account should be taken
when considering the recommendations proposed.
4.1. Relationship with ISO and other published Standards
The purpose and justification of this SIG is described as "designed to serve the same purposes as Part 1".
Although the purposes may be identical, the issues covered by Part 2 are very dissimilar from those of
Part 1. Part 1, which deals with acquirer to issuer communication of magnetic stripe originated
transaction information, is able to refer to International Standard ISO 8583, the one and only relevant
standard. But with respect to ICC implementations of 8583, the situation is quite different. Firstly, ISO
8583 has no formal specification for the content of bit 55, unlike the detailed specifications for other bit
fields. Secondly, the card schemes, collectively as EMV, have agreed a range of card, terminal and
application standards for ICC data elements. Both Europay and Visa, as part of their EPS-Net and
VisaNet implementations, with their own published documentation for authorisation and clearing
specifications in ICC related messages, have extended these standards in different ways. This SIG,
therefore, proposes a European interpretation of these EMV, Europay and Visa standard specifications
rather than any specific interpretation of ISO 8583. Where there is a conflict of Standards, an ECBS
standards conformance hierarchy is adopted. (See 5.1)
4.2. Europay, MasterCard, and Visa (EMV) standards activity
EMV has developed and published three standard documents to support ICC implementation, namely
data element specifications for cards, terminals and applications (See 3: References: 8 - 11). The
professional quality of the approach adopted by the EMV standards teams has done much to facilitate the
consistent implementation of ICC originated applications, not only by these three major card schemes,
but by others. But EMV 96 does not cover message data/formats and is therefore not sufficient to meet
the objectives of this SIG.
4.3. EPS-Net and VisaNet implementations
Europay's own standards for authorisation and clearing specifications for ICC related transactions extend
the scope of the EMV standards. VisaNet's Chip Card Payment Service specifications are designed to
achieve the same objective. All are built upon the relevant parts of ISO 7816, with relevant data
elements derived from both the 1993 and the 1987 version of ISO 8583. We note, however, with some
concern, the entirely different approaches to implementation adopted by Visa on the one hand, and
Europay/MasterCard on the other. Visa caters for ICC applications by means of a third bit map;
Europay/MasterCard focus on single fields (such as bit 55), and within such fields create the necessary
sub-fields, formatted using the ASN.1 TLV mechanism (see 4.5 below). Our concern arises from the
incompatibility of these two approaches. Such divergence of approach, which represents a change of
approach from the earlier successful collaboration with the EMV specifications, would appear to benefit
no one. Now, before too much investment is at stake, would seem to be the moment to make some
attempt at co-ordination.
_________________________________________________________________________
__________________________________________________________________________________________
5
Our study of card scheme implementations has revealed further undesirable inconsistencies. The practice
of assigning newly specified fields, to 8583 bits reserved by ISO for private assignment, has been
adopted by all card schemes. There is no presently effective mechanism to co-ordinate the resolving of
common issues which require the assignment of bits to newly specified fields. We have also noted
variation in the data handling methods of the two schemes: Visa packs numeric data, while Europay
carries such data unpacked. Visa encodes characters in EBCDIC, while Europay adopts ASCII.
In considering the plans of Europay/MasterCard, our attention has been primarily concerned with
Europay, for we have been advised that MasterCard's support of ICC transactions in the MasterCard
Clearing System (INET) is not foreseen for 1997. We also understand that MasterCard will follow the
Europay format for bit 55.
4.4. Public domain standards activity.
ISO 8583 first assigned bit 55 for use with ICC based transactions with its 1993 version. But the 1993
version left the detailed specification of this bit field "to be defined". DIS 13489, which deals only with
bit 55, attempts to show how bit 55 may be structured in ASN.1 (ISO 8825) format, but the text gives no
details of necessary data elements, and has had some difficulties in obtaining final approval.
CEN/TC224 has also attempted to publish a related standard (prENV 1750) extending the principles of
ISO 8583 into the area of acceptor to acquirer messages, but, again, this standard has had difficulties in
obtaining final approval.
At its meeting in November 1997, ISO/TC68/SC6 initiated the five year review process for ISO 8583.
4.5. Adoption of ASN.1
ASN.1 data element structures are agreed by all parties as the most suitable for today's application
systems in the area of ICC/CAD. The relevant International Standard is ISO 8825, a sub-set of ASN.1,
which specifies a system of Basic Encoding Rules (BER). This is the Standard which is used by ISO
7816-6 to specify its IC card data elements. EMV proposes a method of coding required data elements,
following precisely the BER procedures laid down in ISO 8825, encoding data objects conventionally as
Tag, Length and Value (TLV). We have been pleased to note Europay's recent decision to encode the
sub-fields of bit 55 in accordance with the standards laid down by EMV and by ISO 8825.
This SIG also promotes the concept of a single preferred solution to the means whereby sub-fields of ISO
8583 fields are specified in ASN.1 terms. Such a solution will eliminate errors arising from conversions,
and will also support consistency with written forms.
_________________________________________________________________________
__________________________________________________________________________________________
6
5. KEY PRINCIPLES ADOPTED IN THIS SIG
5.1. Hierarchy of standards conformance.
In accordance with normal ECBS practice, a hierarchy of standards conformance is adopted, in
order that conflicts of standards may be resolved in a neutral and consistent fashion. The
hierarchy adopted by this SIG is as follows:
1. Published ISO Standards identified in this Report
2. Published EMV Specifications
The card schemes published network implementations rest upon these same foundations. The
diagram further shows the relationship between the EMV Specifications and this SIG, and how the
SIG may be adopted by the card schemes.
Diagrammatically this can be represented as:
Referenced published ISO Standards
EMV 96 ICC Specifications
Card Scheme A Card Scheme B
Card Scheme C
7816 8583
ECBS SIG 106 Part 2
The overall objective of the SIG is to publish a set of ECBS agreed standards over and above the
EMV 96 Specifications where none currently exist, and to support the present commercial card
scheme network implementations in achieving consistent solutions to common problems.
No general hierarchical conformance principles are applied in this SIG with respect to draft ISO
Standards, CEN Standards, or other standards adopted by national banking bodies, or by
independent card schemes.
5.2. ICC impact affects more than fields in ISO 8583 than Field 55.
Work involved in the preparation of the SIG has revealed the impact of the ICC on more fields
than Field 55. The scope of our recommendations goes some way beyond Field 55. It is desirable
that a single standard method of defining ISO 8583 bit fields (for all fields other than Field 55)
containing a variable number of sub-fields, be adopted. This is a subject which we would
recommend to ISO should be covered in a revised version of ISO 8583. The need for a European
recommendation on this subject then only arises if the subject is not adequately dealt with in the
revised ISO 8583. (We note that UK and France have developed their own individual standards
to handle such fields. While different approaches have been adopted, the solutions are
compatible, and differences can be bridged by a jointly developed standard.)
_________________________________________________________________________
__________________________________________________________________________________________
7
5.3. Need for greater precision.
In certain 8583 field specifications, the Standard itself is insufficiently precise for the use to which
the fields are being put in an ICC implementation, notably to enable the cryptogram to be checked.
It must therefore be recognised that some data fields in bit 55 may have to be repeated in other
fields in a transmitted message. In order to minimise the possibilities of error, ECBS solutions
should seek to ensure that data transmitted through one or more sectors in the transaction chain
between card and issuer, is handled transparently, with format conversions avoided wherever
possible.
5.4. Minimise the need for private bit code assignments.
In an attempt to minimise the need to assign fields to bits reserved by ISO for private use, proposals
for distinguishing true private fields from "misused" private fields i.e. fields where there is a
common shared card scheme interest, are incorporated in the SIG table.
_________________________________________________________________________
__________________________________________________________________________________________
8
6. STANDARD REQUIREMENTS LAID DOWN BY THIS ECBS SIG
6.1. Coding of ASN.1 Data Objects
TLV encoded data objects shall be encoded in accordance with the Basic Encoding Rules (BER) of
ISO 8825, and ISO 7816-6, as applied by EMV. A full description of the coding procedure is
given in EMV ICC Specification for Payment Systems: Annex C - Data Objects.
6.2. Table of Data Elements.
Data elements used for communication of ICC originated, or communicated data, shall be formatted
in accordance with the requirements of Tables 1 and 2 in the Appendix.
These Tables are derived from Annex B of the EMV Card specification, but with considerable
modifications (addition of new columns, deletion of some existing rows) to fit the scope of the
ECBS SIG. Condition code columns show in which message types the individual data elements
may be used, and the conditions of use. Table 2 provides specific field interpretations, along the
lines of those given in Part 1. The Table identifies the minimum data set (nine data elements)
required by EMV for bit field 55. An additional tenth mandatory data element (Transaction
Currency Code, Row 36), is specified by ECBS in this SIG.
The two rightmost columns in Table 1 show, in italics, present implementations by EPS-Net and
VisaNet (See 3: References: 11 - 15).
_________________________________________________________________________
__________________________________________________________________________________________
9
APPENDIX
Table 1: Data Elements
Defines those data elements used for ICC to issuer communication financial transaction interchange and
the recommended method of handling these data elements in ISO 8583 : 1993. The Table thus also defines
the nine minimum data elements as required by EMV.
Interpretation and Explanation of the Table
1. An empty cell in a Message Type column signifies that the data element is optional, or not relevant,
for that message type, in accordance with ISO 8583. Optionality is specified (Condition Code O) for bit
55 data elements only. For fields other than bit 55, where fields are used they shall be in accordance
with Part 1 of this SIG. Condition Codes are:
M Mandatory for ICC-read transactions
O Optional
C33 Mandatory for ICC-read transactions if provided by the card.
C34 Mandatory for ICC-read transactions (if the data is not provided by the card, the tag must be if
provided by the terminal).
2. Application Cryptogram (Row 4). The issuer must be given all the information necessary to
reconstruct the elements with the cryptogram. The sender of an 8583 message must ensure that relevant
data element content not known to the receiver, must be included somewhere in the message. The issuer
wishing to verify the cryptogram should be able to do so by selecting the relevant items that are available
in the appropriate message.
3. Data elements containing data to be used in the cryptogram, must be included in bit 55.
4. Current card scheme bit assignments (rightmost two columns). These two columns show variation
from ECBS SIG recommendation. Note that card schemes have implemented 1100 authorisation
messages with the 1987 version of ISO 8583, while Europay has implemented clearing messages with the
1993 version. Visa has developed its own third bit map. EMV mandatory data elements are printed in
bold.
5. Message types are MT 1100 : Authorisation Request
MT 1110 : Authorisation Request Response
MT 1120 : Authorisation Advice
MT 1200 : Financial Request
MT 1210 : Financial Request Response
MT 1220 : Financial Advice
MT 1240 : Financial Notification
6. Reversal messages associated with the above message types shall carry no new data beyond that
contained in the original message as identified by its STAN.
10
__________________________________________________________________________________________________________________________________________
Table 1: Data Elements
ECBS STANDARD
Message Type Usage (including
condition codes)
Current card schemebit
assignment
Row Tag EMV
Format
EMV Name Source
(EMV)
Desti-
nation
8583
(1993)
bit
1100
1200
Req
1110
1210
Resp
1120
1220
Advice
1240
Ntfcn
Euro-
pay
Visa
1. 9F01 n 6-11 Acquirer Identifier Terminal
(Acquirer)
Issuer 32 32
2. Numeric
= 9F02
b 6 (n 12) Amount, Authorised Terminal Issuer/
ICC
4 / 30
& 55
4 & 55 147
3. Numeric
= 9F03
b 6 (n 12) Amount, Other Terminal Issuer 54
& 55
C34 C34 C34 55 61
49
4. 9F26 b 8 Application Cryptogram ICC Issuer 55 M M M 55 136
5. 9F06 b.. -16 Application Identifier (AID) Terminal Issuer 55 O O O
6. This row deleted.
7. 82 b 2 Application Interchange
Profile
ICC Term
Issuer
55 M M M 55 138
8. 5A cn
var. up to 19
Application Primary Account
Number (PAN)
ICC Issuer 2 2
9. 5F34 n 2 Application PAN Sequence
Number
ICC Issuer 23 23
10. 9F36 b 2 Application Transaction
Counter (ATC)
ICC Issuer 55 M M M 55 137
11. 9F09 b 2 Application Version Number Terminal ICC/
Issuer
55 O O O 55
12. 89 an 6 Authorisation Code Issuer Terminal 38
13. 8A
2
an 2
1
Authorisation Response Code Issuer/
Terminal
Terminal 39
(n3)
139.2
14. 9F34 b 3 Cardholder Verification
Method (CVM) Results
Terminal Issuer 55 O O O 55 134.3
15. 9F27 b 1 Cryptogram Info Data ICC Issuer 55 M M M 55
11
__________________________________________________________________________________________________________________________________________
ECBS STANDARD
condition codes)
assignment
Row Tag EMV
Format
EMV Name Source
(EMV)
Desti-
nation
8583
(1993)
bit
1100
1200
Req
1110
1210
Resp
1120
1220
Advice
1240
Ntfcn
Euro-
pay
Visa
16. 9F1E b 8 (an 8) IFD Serial Number Terminal Acquirer 55 O O O 55
17. 9F10 b .. 32 Issuer Application Data ICC Issuer 55 C33 C33 C33 55 134/135
18. 91 b 8 - b ..16 Issuer Authentication Data Issuer ICC 55 O 139.1/.2
19. 5F28 n 3 Issuer Country Code ICC Terminal 20
20. 86 b .. 261 Issuer Script Command Issuer ICC 55 O O O
21. 9F18 b 4 Issuer Script Identifier Issuer ICC 55 O O O
22. 71 b ..127 Issuer Script Template 1 Issuer ICC 55 O 55 142
23. 72 b ..127 Issuer Script Template 2 Issuer ICC 55 O 55 142
24. 9F15 n 4 Merchant Category Code Terminal ICC/
Issuer
26 18
25. 9F16 ans 15 Merchant Identifier Terminal Issuer 42 42
26. 9F39 n 2 Point-of-Service (POS) Entry
Mode
Terminal Issuer 22 22
27. 5F30 n 3 Service Code ICC Issuer 40
28. 9F33 b 3 Terminal Capabilities Terminal ICC/
Issuer
55 O O O 55 60.2
130
29. 9F1A n 3 Terminal Country Code Terminal ICC/
Issuer
92 &
43
55 145
30. 9F1C an 8 Terminal Identification Terminal Issuer 41 133
31. 9F35 n 2 Terminal Type Terminal ICC/
Issuer
22 55
32. 95 b 5 Terml Verification Results Terminal Issuer 55 M M M 55 131
33. 9F1F ans Track 1 Discretionary Data ICC Issuer +
ICC
45
(T1
complete)

34. 9F20 cn Track 2 Discretionary Data ICC Issuer 35 135
35. 57 b ..19 Track 2 Equivalent Data ICC Issuer 35 35
12
__________________________________________________________________________________________________________________________________________
ECBS STANDARD
condition codes)
assignment
Row Tag EMV
Format
EMV Name Source
(EMV)
Desti-
nation
8583
(1993)
bit
1100
1200
Req
1110
1210
Resp
1120
1220
Advice
1240
Ntfcn
Euro-
pay
Visa
36. 5F2A
3
b 2 (n 3) Transaction Currency Code Terminal Issuer +
ICC
49 &
55
M M M 49 & 55 148
37. 9A b 3 (n 6)
YYMMDD
Transaction Date Terminal Issuer 12 &
55
M M M 13 146
38. 9B b 2 Transaction Status
Information
Terminal Issuer 22 Individual
byte (or
143)
39. 9F21 n 6 HHMMSS Transaction Time Terminal Issuer 12 12
40. 9C b 1 (n 2) Transaction Type Term ICC/
Issuer
3 & 55 M M M 55 144
41. 9F37 b 4 Unpredictable Number Terminal Issuer 55 M M M 55 132
42. '9F41' b 4 (n 8) Transaction Sequence Counter Terminal ICC/Issuer 55 O O O 55
43. '84' b ..16 Dedicated File Name ICC Issuer 55 O O O
Notes:

1
In Row 13 Visa is using the 2 character format from 8583: 1987. ECBS specifies the 3 character format of 1993. To convert see Annex B4 of 8583: 1993.

2
The Authorisation Response Code (tag 8A) is private to the issuer and its Card, and is thus not necessarily related to the Authorisation Response Code (bit 39 of
ISO:8583) exchanged between the Acquirer and the Issuer over the payment systems network.
3
ECBS mandates this tag in Bit field 55, over and above EMV specifications in order to keep trace of the original currency associated with the original amount.
Note to Table 1: Fields (with associated bit assignments) specified by Visa, but not defined by EMV, or this ECBS Standard.
Card Auth Reliability Ind 60.8
CCPS Transaction Indicator 60.7
Chip Condition Code 60.3
CVV Results Code 44.5
Issuer Script Results 143
13
___________________________________________________________________________
______________________________________________________________________________________________
Table 2: Field Descriptions
This Table is derived from EMV 96, ICC Specification for Payment Card Systems: Annex B, with additions as
necessary, marked in italics.
Row Name Description
1 Acquirer Identifier Uniquely identifies the acquirer within each payment
system
2 Amount, Authorised Authorised amount of the transaction (excluding
adjustments)
3 Amount, Other Secondary amount associated with the transaction
representing a cashback amount
4 Application Cryptogram Cryptogram returned by the ICC in response to the
GENERATE AC command i.e. TC, ARQC, AAC or
AAR, depending upon the type of data element.
5 and 6 Application Identifier (AID) Identifies the application as described in ISO/IEC 7816-
5
7 Application Interchange Profile Indicates the capabilities of the card to support specific
functions in the application
8 Application Primary Account
Number (PAN)
Valid cardholder account number
9 Application PAN Sequence Number Identifies and differentiates cards with the same PAN
10 Application Transaction Counter
(ATC)
Counter maintained by the application in the ICC
(incrementing the ATC is managed by the ICC)
11 Application Version Number Version number assigned by the payment system for the
application
12 Authorisation Code Value generated by the Issuer for an approved
transaction
13 Authorisation Response Code Code that defines the dispositon of a message
14 Cardholder Verification Method
(CVM) Results
Indicates the results of the last CVM performed
15 Cryptogram Information Data Indicates the type of cryptogram and the actions to be
performed by the Terminal
16 IFD Serial Number Unique and permanent serial number assigned to the
IFD by the manufacturer.
17 Issuer Application Data Contains proprietary application data for transmission to
the Issuer in an online transaction
18 Issuer Authentication Data Data sent to the ICC for online Issuer authentication
19 Issuer Country Code Indicates the country of the Issuer according to ISO 3166
20 Issuer Script Command Contains a command for transmission to the ICC
21 Issuer Script Identifier Identification of the Issuer Script
22 Issuer Script Template 1 Contains proprietary Issuer data for transmission to the
ICC before the second GENERATE AC command
23 Issuer Script Template 2 Contains proprietary Issuer data for transmission to the
ICC before the second GENERATE AC command
24 Merchant Category Code Classifies the type of business being done by the
merchant, represented according to ISO 8583:1993 for
Card Acceptor Business Code
25 Merchant Identifier When concatenated with the Acquirer Identifier,
uniquely identifies a given merchant
14
___________________________________________________________________________
______________________________________________________________________________________________
Row Name Description
26 Point-of-Service (POS) Entry Mode Indicates the method by which the PAN was entered,
according to the first two digits of the ISO 8583:1987
POS Entry Mode
27 Service Code Service code as defined on tracks 1 and 2
28 Terminal Capabilities Indicates the card data input, CVM, and security
capabilities of the Terminal
29 Terminal Country Code Indicates the country of the Terminal, represented
according to ISO 3166
30 Terminal Identification Designates the unique location of a Terminal at a
merchant
31 Terminal Type Indicates the environment of the Terminal, its
communications capability, and its operational control
32 Terminal Verification Results Status of the different functions as seen from the
Terminal
33 Track 1 Discretionary Data Discretionary part of track 1 according to ISO/IEC 7813
34 Track 2 Discretionary Data Discretionary part of track 2 according to ISO/IEC 7813
35 Track 2 Equivalent Data Contains the data elements of the track 2 according to
ISO/IEC 7813, excluding start sentinel, end sentinel, and
LRC
36 Transaction Currency Code Indicates the currency code of the transaction according
to ISO 4217
37 Transaction Date Local date that the transaction was authorised
38 Transaction Status Information Indicates the functions performed in a transaction
39 Transaction Time Local time that the transaction was authorised
40 Transaction Type Indicates the type of financial transaction, represented by
the first two digits of ISO 8583: 1987 Processing Code
41 Unpredictable Number Value to provide variability and uniqueness to the
generation of a cryptogram
42 Transaction Sequence Counter Counter maintained by the terminal that is incremented
by one for each transaction
43 Dedicated File Name Identifies the name of the DF as described in ISO/IEC
7816-4
ooOOoo

EMV

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

EMV

Cargado por

Copyright:

Formatos disponibles

EUROPEAN COMMITTEE

También podría gustarte