Key Accounts Authorization Interface

(1)

Key Accounts Authorization

Interface

American Express Payment Services L

imi

t

e

d

.

B+S Card Service GmbH

ConCardis

GmbH

Elavon Merchant Services

, Inc.

Version 2.23e / Date: 14.09.2010 / Status Issue

This specification is updated regularly! Please confirm with the issuer that this version is still up to date prior to any hard or software implementation based upon it!

Although this documentation was created with all conscientious care, the whole risk of consequences of use will be borne by the user himself. The authors exclude liability, guarantees, or any kind of responsibility for the use or the

consequences of use as far as correctness, exactness, reliability, actuality or others are concerned, unless other regulations will be set up separately.

(2)

0 Change

history

Date Version Status Comments Responsible

14.09.2010 2.23e Issue • Ch. 3.2 – BMP 39: new RC 85 for cashback, BMP 54: changed definition (modification to variable length field acc. ISO 8583), BMP 60: Contents explanation more precise, SF 35: added Note re. DCC, SF 40: added new value, new SF 43 added, SF 63: deleted obsolete info., BMP 63: new value 000003 • Appendix A: Ch. 19.- added Ch. 19.7 –

purchase with cashback, added Ch. 19.10 – reversal cashback

TAK Acquirer

03.07.2009 2.22e Issue • Ch. 3.2 BMP 54: correction to debit/credit indicator

TAK Acquirer 04.06.2009 2.21e Issue • Ch. 3.4 – Addition to BMP 22, Addition of

BMP 41, Changed format of BMP 49, Addition to format of BMP 52, Addition of Subfield 24 to BMP 55, Changed Fieldtype of BMPs 53 and 57.

• Ch. 4.1 – Addition of BMP 41, Changed Footnotes 9 and 11.

• Ch. 5 (App. A) – Changed receipt requirements.

TAK Acquirer

23.03.2009 2.2e Issue • Ch. 2.1.1 – Changed explanations of msg. types 0120, 0130 (for Maestro and V PAY?) • Ch. 3.1.3 – Added definition of character data • Ch. 3.2 – Addition value 09 (cashback) to

BMP 3, Addition of BMP 15, changed definition of BMP 38, addition of BMP 54, addition to BMP 55, BMP 60 SF 37 clarifications, addition to BMP 63 • Ch. 4.1 – Addition of BMPs 15 and 54 • Ch. 5 (App. A) – Changed receipt

requirements

TAK Acquirer

01.07.2008 2.1e Issue • Ch. 2.1.1 – added for explanations of msg.types 0120, 0130 (Maestro only) • Ch. 3.2 – description of BMPs 3, 22, 38, 61 -

changed

• Ch. 4.1 – two columns added for msg.types 0120, 0130

TAK Acquirer

01.03.2001 1.60e Issue • Ch. 3.2: References to 02xx transactions • Added RC91: Card issuer temporarily notremovedreachable N. Wolsey 25.10.2000 1.59e Issue • Ch. 3.2: BMP 42 defined as being mandatory _{• Ch 3 2: added sub-fields 30 (CVV2) 35}only for 01xx and 04xx messages_{(additional merchant data) and 36 (additional}_{cardholder data) to BMP 60} N. Wolsey 04.05.2000 1.58e Issue • Reference to supplier of ISO 8583 standard • BMP 43 added to summary of message fields• References to 02x messages removed (chapter(chapter 5 1)3) N. Wolsey 17.08.1999 1.57e Issue • More precise definition of BMP 60, SET sub-fields 43-46 (chapter 3.2) N. Wolsey 11.05.1999 1.56e Issue • Initial translation of Kaai_1.56d into English. N. Wolsey

(3)

1 General

1.1 Introduction

The interface introduced in this document describes the message types and formats which need to be sent and received by a key account host computer (terminal networks) in order to be able to communicate with the authorization centers of the credit card institutions (CCIs). The complete ISO 8583 standard can be obtained from Beuth Verlag GmbH, Burggrafenstr. 6, D-10787 Berlin (www.beuth.de).

The protocol described is based on the ISO 8583 norm (1987 version).

The interfaces supports multi transaction operation, i.e. the key account host can send a new message over the same interface (i.e. the same Datex-P channel) before receiving a reply to the previous message. Transactions cannot be booked over this interface and an extension to the interface to include the direct booking of transactions is ruled out, both now and in the future,. This means that the actual sales amounts authorized over this interface must be submitted for booking using an alternative method (e.g. file transfer in the standard format of the CCIs).

For additional information concerning the protocol, message types and the meaning of fields in more detail please consult the actual version of the GICC specification.

1.2 Card

Verification

Card verification is to be performed by the POS Terminal. This comprises: • Check of the Chip Card AID and Certificate

• Check of the integrity of Track 2, that has to be transmitted in its entirety

• Check of the validity of the card number (Luhn Check), configurable at initialization time • Check of the card's expiry date, mandatory in case of off-line transactions

(5)

1.3 Differences to existing terminal interfaces

There are a number of differences between this interface and other existing terminal interfaces to the authorization centers of the CCIs:

1) The terminal dataset for the aforementioned terminal interfaces (ACS, GICC, Makatel etc.) is maintained at the authorization centers of the CCIs. This means that it must be possible to uniquely identify any terminal which submits requests to a CCI authorization center – either directly (multi-host) or indirectly, via a network operator (e.g. single (multi-host) – by way of a terminal ID record in the database system of the respective CCI.

In this interface, the terminal dataset is not maintained by the CCIs. Consequently, the cash registers and terminals are not identifiable by the CCIs. For the sake of compatibility with existing interfaces, certain fields (such as the sequence generation number in bit map position (BMP) 57) have been defined as being optional. If they are sent in the request message, they will be returned in the response message but will not be subjected to any form of verification by the authorization center.

2) This interface can only be used for authorizing transactions, not for booking them.

3) The interface can process both signature-based and PIN-based transactions. If PIN-based transactions are submitted, they must contain the sequence number and generation number in BMP 57, analogously to the GICC interface. This data is required for calculating the message authentication code (MAC). Note that the sequence number referred to here is not related to the Transaction Sequence Counter or Application Transaction Counter for chip-card transactions. 4) The sequence number is an optional field in the protocol which is not checked formally by the

authorization center e.g. that it is "strictly monotonic increasing" etc. So long as it has a valid format, the same value will be returned in the response message.

5) The uniqueness of the transactions within the system must be guaranteed by the key account host: no two transactions may be sent on the same day having an identical combination of message type identifier (MTI), trace number and acquiring institution identification code.

6) Implementers should verify that their respective CCI(s) support(s) chip-card (EMV) functionality. 7) Implementers should verify that their respective CCI(s) support(s) PIN/MAC functionality.

(6)

2 Message

flow

The following messages are permitted over the interface between the operator host and the authorization centers of the CCIs.

2.1 Authorization

Message type Direction ISO 8583 type

Authorization request Authorization repeat request Authorization response

Key account host → AS Key account host → AS AS → key account host

0100 0101 0110 Notes:

The authorization request must be sent in real-time to the responsible authorization center (i.e. at the time of the sale). The trace number (BMP 11) and acquiring institution identification code (BMP 32) of a repeat request must be identical to those sent in the original transaction.

2.1.1 Authorization notification (Maestro and V PAY transactions only)

Message Type Direction ISO-8583 Type

Authorization Notification request Authorization Notification repeat request Authorization Notification reply

0120 0121 0130 Notes:

These messages are used to inform the authorization host that a transaction has been completed at the POS and thus the acquirer host should forward the message to the (issuer) network. A notification must be forwarded as soon as the device reports the completion of the delivery process. The notification shall include the final amount of the transaction being less than or equal to the initially authorized amount. BMP 25 must be identical to the one sent in the original message.

Currently used for Maestro and V PAY transactions from unattended petrol terminals only!

2.2 Reversal

Reversal advice Repeat reversal advice Response to reversal advice

0420 0421 0430 Notes:

The key account host can send a direct reply to any terminal which sends it a reversal message (store and forward principle). Within 24 hours, the key account host must forward the reversal message to the authorization center responsible to enable the cardholder's available limit to be corrected. BMP 37 of the (repeat) reversal advice contains a reference to the transaction to be reversed. The acquiring institution identification code in the reversal transaction must be identical to the one sent in the original message.

In addition to this, an automatic, asynchronous reversal (MTI 0420) must be initiated under the following conditions:

In the case of a timeout if no response is received within an variable time period (maximum 1 minute) or

On receipt of a formally incorrect message; this includes messages with incorrect MAC and / or PAC values (when applicable) or

(7)

BMP 11 (the system trace audit number, STAN) of an automatic reversal contains the same value as BMP 11 of the original authorization.

Reversals and possible auto-reversals of chip-card-initiated transactions are permissible without the original card being present.

2.3 Line

diagnostic

Diagnostic request

Diagnostic response Key account host → AS _{AS → key account host}

0800 0810 Notes:

The line diagnostic is not related in any way to the card transactions (01xx or 04xx). It can be submitted at any time (e.g. when the POS device registers itself with the key account host).

If the line diagnostic is triggered in reaction to an incorrect or incomplete automatic reversal, the line diagnostic will be treated as a new transaction. Consequently, the message contains the same sequence number as the automatic reversal but the STAN will be incremented by one.

(8)

3 Message structure and contents

3.1 Data

format

The attributes and formats of the ISO 8583 message fields used in this specification have the following meaning: Attribute/ format Description N x b x a x an x ans x LL, (LLL) VAR y..x VAR z hh mm ss DD MM YY x numeric characters x bits x alphabetic characters

x alphabetic or numeric characters x alphabetic, numeric or special characters

2- (or 3-) digit length specification for the following field which has a variable field length

Field with variable length of type y, maximum x characters in length Field with variable length of type z (track 2 data:

BCD coded, left-justified, least significant half-byte padded with x'F', if necessary) Hour (2 numeric characters)

Minute (2 numeric characters) Second (2 numeric characters) Day (2 numeric characters) Month (2 numeric characters) Year (2 numeric characters)

Unless otherwise specified, all characters will be encoded in EBCDIC. The data types "an" and "ans" are always represented in EBCDIC.

3.1.1 Numeric data

Numeric characters are the characters '0' ,'1', .., '9'.

Numeric fields (type n x) with fixed field length are stored in packed (binary coded decimal - 2 BCD digits stored in each byte) format, right-justified with leading zeroes. The first digit is stored in the upper half-byte, the second digit in the lower half-byte.

Leading (non-relevant) zeroes are omitted in numeric fields with variable field length (with length prefix, type VAR n). Consequently, packing an odd number of digits will result in the right-hand half-byte of the least significant half-byte containing an undefined (irrelevant) value. In such cases, this half half-byte is to be filled with the hexadecimal value x'F'.

The highest value digit of a message field is always the first to appear in the message.

3.1.2 Alphabetic data

Alphabetic characters are the characters 'a', .., 'z', 'A', .., 'Z'.

Each character is represented in the message using corresponding its one-byte-long EBCDIC code. Should the length of the data be shorter than the length of the field, the data will be stored left-justified, padded with spaces.

(9)

3.1.3 Character Data

Character data:

Attribute Description

a ('a'..'z', 'A'..'Z')

an ('a'..'z', 'A'..'Z', '0'..'9')

ans ('a'..'z', 'A'..'Z', '0'..'9', hex 40 - hex FF)

or VARiable fields of these types are stored as EBCDIC characters. Each character requires one byte. All fixed length data elements (a, an, ans) are left justified with trailing blanks.

3.1.4 Binary data

Each byte of a binary data field may contain any desired bit combination (x'00', .., x'FF').

3.1.5 Track 2 data

Track 2 data (type z) are set in accordance with the message field description, below.

3.1.6 Monetary amounts

All monetary amounts (e.g. BMP 4) are represented as unsigned values. The two least significant (right-hand) digits in these fields are to be interpreted as the value after the decimal point.

3.1.7 Length specifications

Each digit of the length specifications "LL" and "LLL" of variable-length fields is represented using its corresponding EBCDIC code, one byte per digit, right-justified and with leading zeroes. All length specifications "LL" and "LLL" define the length of the respective data field in bytes; the calculation does not include the two / three bytes of the length specification, itself.

The fixed length specification of the ISO 8583 norm defines the number of data elements of the respective type contained in the field. A field defined as "b 64", for example, is 8 bytes long; one defined as "N 4" is two bytes long (BCD); and "ans 12" would be 12 bytes long (EBCDIC).

3.1.8 Message type identifiers

Chapter 3.2 defines the fields (BMPs) that are mandatory and optional in the various message types. Whenever the last two digits of a message type have been substituted with 'xx' (e.g. '04xx'), the description refers to a generic representation of the request message(s) and associated response message(s).

3.1.9 Message structure

Each message has the following structure: A header comprising:

– The message type identifier (4 numerics) and

– A bitmap (64 bits) whereby each bit signifies the presence (1) or absence (0) in the message of the data element associated with that particular bit followed by...

(10)

The application data comprising:

– The values of the fields specified in the bitmap in accordance with the data format descriptions listed below.

(11)

3.2 Field

description

BMP 2: Primary account number

Format: LLVARn..19

Mandatory for 01xx, 04xx

Contents: This field contains the PAN (card number.) of the card (field 2 of track 2).

BMP 3: Processing code

Format: N6

Contents: This field contains a code which describes the effect of a transaction on the cardholder's account. It is set in accordance with the ISO 8583 specification. The first two positions of this field may contain the values listed beneath; positions 3 - 6 are reserved:

00 = Authorization and notification (or reversals of authorization and notification)

09 = Authorization with cashback 20 = Refund (or reversal of a refund)

BMP 4: Transaction amount

Format: N 12

Contents: In an authorization request, this field contains the amount to be authorized. In a reversal (MTI 04xx), the transaction amount is identical to the transaction amount of the authorization to be reversed.

Note: Partial reversals are not permitted.

BMP 11: Trace number

Format: N 6

Mandatory

Contents: The trace number is generated by the key account host. It is incremented prior to each new transaction (although not necessarily strictly monotonically increasing). Together with the acquiring institution id. code (AID in BMP 32), it forms the system trace audit number (STAN). The key account host must ensure that the combination of trace number and AID is unique for each day (24 hour period). Repeat requests and replies will contain the same trace number and AID as the original request because all belong to the same logical transaction.

BMP 12: Time, local transaction

Format: N 6 (hhmmss) Mandatory

Contents: This field is set in all request messages and contains the current time at which the transaction was effected at the terminal. In the response messages, it contains the system time at the authorization center.

BMP 13: Date, local transaction

Format: N 4 (MMDD) Mandatory

Contents: This field is set in all request messages and contains the current date of the sending terminal. In the response messages, it contains the system date at the authorization center.

(12)

BMP 14: Card expiry date

Format: N 4 (YYMM)

Mandatory: 01xx, 04xx

Contents: This field contains the card expiry date (field 4 of the track 2 data).

BMP 15: Settlement date

Format: N 4 (MMDD)

Conditional: in responses to 01xx and 04xx requests if received from the issuer Contents: Date (month and day) that funds will be transferred between an acquirer (CCI)

and an issuer (network). The authorization system provides this date.

BMP 22: POS entry mode

Format: N 3

Mandatory in 01xx and 042x

Contents: Two numerics indicate the method by which the primary account number was entered into the system and one numeric indicates EMV & PIN entry

capabilities for the card brand used. (see also GICC - BMP 55 - Special treatment of subfields 14, 23, 88 and 89).

If the transaction is marked in BMP 22 as ICC-based (05, 07) or mag. stripe read (02, 90, 91) all relevant data (BMP 55 or 35) must be delivered in the request msg.

Pos. 1, 2: 01 = Entry mode - manual

02 = Entry mode - magnetic stripe reader 03 = Entry mode - bar code

04 = Entry mode - optical character recognition (OCR) 05 = Entry mode - Integrated circuit card1

07 = Entry Mode - proximity payment using ICC data 80 = Entry mode - ICC fallback to magnetic stripe 81 = Entry mode - electronic commerce

90 = Entry mode - Complete contents of magnetic stripe, track 2 have been read and checked

91 = Entry Mode - proximity payment using magnetic stripe data Pos. 3: 1 = PIN entry capability

2 = No PIN entry capability 3 = EMV & PIN Entry capability 4 = EMV capability

BMP 23: Card Sequence Number

Field Type: N 3

Conditionally mandatory for 01xx and 04xx if a chip-card containing TAG 5F34 is present. Description: A number distinguishing between separate cards with the same primary

account number or primary account number extended. To be filled with TAG 5F34 from the ICC.

BMP 25: POS condition code

Format: N 2

Mandatory in 01xx and 042x

Contents: The field is set to provide additional information about the transaction:

(13)

00 = Normal representation (cardholder present) 08 = Mail-order or telephone order

27 = petrol pump – interactive

81 = indicates unattended terminals, fixed amount, interactive (for instance, automated dispensing machines)

82 = Asynchronous reversal

BMP 26: POS PIN capture code

Format: N 2

Optional: in 010x, 042x. Mandatory for PIN transactions

Contents: When the PIN has to be captured, this data field specifies the maximum number of PIN digits which can be entered at the end device. The value must lie in the range 4..12.

BMP 32: Acquiring institution identification code

Format: LLVAR n..11

Mandatory

Contents: A unique number assigned by each CCI for identifying the key account host. If necessary, a key account operator may request the respective CCI to assign it a number of AIDs (e.g. one AID per key account host).

This field is divided internally into two sections. The five right-most positions are administrated by the key account partner and will not to be evaluated by the credit-card institutions. The remaining left-most positions are of variable length (0..6 positions) and may be (but do not necessarily have to be) filled

and / or administrated by the CCI. The credit card institutions can define independently of one another which values (if at all) they wish to place in left-most positions of this field.

Administrated by CCI 0 .. 6 positions

Administrated by key account 5 positions

Note: The combination of the AID and trace number serve as the key for uniquely identifying any transaction within a specified period of time.

BMP 35: Track 2 data

Format: LLVARz..37

Optional in 010x,042x. Mandatory if the card data was captured using a magnetic stripe reader and in all transactions where chip-card is present.

Contents: Deviates from the ISO 8583 norm as follows: the track 2 data in this field is BCD coded and left-justified. In the case of an odd number of BCD digits, the least-significant half-byte is initialized with the hexadecimal value x'F'. If further bytes remain unused, these too are initialized with x'F'. The track 2 field separator is encoded with the value x'D'. Neither the track 2 start sentinel, nor the track 2 end sentinel of the track 2 data nor the longitudinal redundancy check (LRC) character is transmitted. In chip-card transactions, fill with track-2 equivalent data in TAG 57 from the ICC.

Note: This field is sent in asynchronous reversals.

BMP 37: Retrieval reference number

Format: an 12

(14)

Contents: The field is contained in a reversal request and contains the trace number of the authorization request which is to be reversed. The reference number has the following format:

000001nnnnnn

whereby nnnnnn = the trace number (BMP 11) of the transaction which is to be reversed. BMP 32 must contain the AID of the authorization request.

BMP 38: Authorization identification response

Format: ans 6

Mandatory in 0110, 0120and 0430

Contents: A unique number assigned by the authorization center. In the case of an authorization, this field contains the authorization number; otherwise it is initialized with "blanks" (x'40'). In the case of an authorization notification request, this field contains the value sent in the corresponding authorization response.

Note: The field is also filled for declined authorizations, so as to ensure a fixed-length message.

BMP 39: Response code

Format: an 2

Mandatory in all response messages

Contents: The following table provides a summary of all the response codes which may be returned. Their interpretation is analogous to that of ISO 8583, note 1.

Value Description

00 Authorization or successful completion of a transaction 02 Call AS number

03 Invalid merchant number 04 Retain card

05 Authorization declined 12 Invalid transaction 13 Invalid amount 14 Invalid card number 21 No action taken 30 Invalid format 33 Card expired

34 Suspicion of manipulation 40 Invalid function 43 Stolen card, pick up 55 Incorrect PIN

56 Card not in authorizer's database

57 The referencing transaction (e.g. reversal request) was not carried out with the card which was used for the original transaction.

62 Restricted card

64 The transaction amount of the referencing transaction differs from the transaction amount of the original transaction

75 PIN entered incorrectly too often 77 PIN entry necessary

78 Stop payment order (for forwarding the Visa response code "R0" of the Visa BASE I interface): the transaction was declined or returned because the cardholder requested that payment of a specific recurring or installment-payment transaction be stopped.

79 Revocation of authorization order (for forwarding the Visa response code "R1" of the Visa BASE I interface): the transaction was declined or returned because the cardholder requested that payment of all

(15)

recurring or installment-payment transactions for a specific merchant account be stopped.

81 Message flow error

82 Authorization center not available for 60 seconds 83 Authorization center not available for 300 seconds 85 Cash back declined – pls. retry purchase only 91 Card issuer temporarily not reachable

92 The card type is not processed by the authorization center 94 Data has been transmitted twice

96 Processing temporarily not possible

97 Security breach - MAC check indicates error condition 98 Date and time not plausible

99 Error in PAC encryption detected

Notes: a) Any other response codes (RCs) from the authorization centers must be declined by the key account host.

b) Should RC 82 or RC 83 be received, no requests should be sent to the authorization host for the specified period of time.

c) Should AC 98 be received, the key account partner should synchronize itself with the date and time in the response and the transaction should be repeated manually.

BMP 41: POS Terminal ID Code

Field Type: ans 8

Mandatory for all MasterCard products, all other cards as per agreement with CCI.

Description: This field consists of a unique logical number which identifies the POS Terminal in the POS network.

If the POS Terminal has been assigned a three digit ZKA- ID then the format of this field is this ID followed by a five digit serial number.

BMP 42: Card acceptor identification code

Format: ans 15

Mandatory field in 01xx and 04xx

Contents: The number of the contracted company, used for identifying the merchant.

BMP 43: Card acceptor name / location

Format: LLVARans..99 (fixed length 40 bytes, EBCDIC) Optional in 01xx and 04xx requests and repeat requests.

Contents: This field contains the name, city and country code of the merchant. It comprises three sub-fields:

Sub-field Position Type Description

1 1-25 ans 25 Card acceptor name 2 26-38 ans 13 City name

3 39-40 a2 Country code (ISO 3166)

BMP 49: Transaction currency code

Format: N 3

(16)

Contents: Local currency of the submitter or the source of the transaction, i.e. the currency in which the transaction is acquired.

BMP 52: PIN data (PAC)

Format: b 64

Conditionally mandatory field for PIN-transactions if online PIN is used. Contents: This field contains the encrypted PIN, used for identifying the cardholder. Description: A number assigned to a cardholder intended to uniquely identify that cardholder

at the point of service. The field contains the encrypted PIN. The PIN block is formatted in ISO-0 or ISO-1. The encryption is done with a sessions key and the Triple-DES in ECB mode (s. section 6, Appendix B: Cryptographic Functions).

ISO-0: The ISO-0 PIN block format is built by XOR of the PIN clear text field

and the account-number-field ANF. The PIN clear text field consists of the 16 nibbles.

C L P P P P P/F P/F P/F P/F P/F P/F P/F P/F F F

and

C: '0' check field for ISO-0 format L: Length of PIN (between 4 and 0x0C) P: Digit of PIN (1 nibble, BCD coded) F: Fixed hex value 0x0F

The value ANF is formatted as follows:

0 0 0 0 A1 A2 A3 A4 A5 A6 A7 A8 A9 A10 A11 A12 and:

0: Fill bits, fixed value zero A1..A12:

Content of the right most twelve digits of the PAN (primary account number) with exception of the check digit. In case of PAN-length is smaller than 12, the PAN is filled with zeroes (padded left justified). The permitted values for A1, …, A12 are in the range between 0 and 9.

ISO-1: The ISO-1 PIN block format is formatted as follows

C L P P P P P/Z P/Z P/Z P/Z P/Z P/Z P/Z P/Z Z Z

and:

C: '1' check field for ISO-1 format L: Length of PIN (between 4 and 0x0C) P: Digit of PIN (1 nibble, BCD coded)

Z: Random value ∈ {0, 1, 2, 3, .. , 0x0C, 0x0D, 0x0E, 0x0F}

BMP 53: Security Related Control Information

Field Type: N 16

Conditionallymandatory in messages where BMP 64 is present Description: This BMP provides security related information.

Pos. 1-2: Security-Format Code "01" Pos. 3-4: PIN Encryption Algorithm Identifier "00"

(17)

Pos. 5-6: PIN Block Format Code "00" no PIN

"10" ISO-0 PIN block "11" ISO-1 PIN block Pos. 7-8: PIN Key Index Number (n.a.) "00"

Pos. 9-10: MAC Generation Mode "02" (default), "03" Partial MAC (see section 6.3)

Pos. 11-16 : RfU "000000"

For "complete" MAC:

"0100000002000000"

Message contains BMP 64. No PIN (BMP 52) is present. MAC based on complete message.

"0100100002000000"

Message contains BMP 52 and BMP 64. PIN (BMP 52) is in ISO-0 format . MAC based on complete message.

"0100110002000000"

Message contains BMP 52 and BMP 64. PIN (BMP 52) is in ISO-1 format . MAC based on complete message.

If "complete" MAC is used in the request message it will as well be used in the response.

For partial MAC:

"0100000003000000"

Message contains BMP 64. No PIN (BMP 52) is present. MAC based on partial message.

"0100100003000000"

Message contains BMP 52 and BMP 64. PIN (BMP 52) is in ISO-0 format . MAC. based on partial message.

"0100110003000000"

Message contains BMP 52 and BMP 64. PIN (BMP 52) is in ISO-1 format . MAC. based on partial message.

If partial MAC is used in the request message it will as well be used in the response.

The use of partial MAC must be agreed with the individual credit card institution.

BMP 54: Additional amounts

Field Type: LLLVARans…120

The length must be an integral multiple of 20. The definition of BMP 54 as per KAAI 2.22e (fixed length 20 ans) shall not be implemented.

Mandatory: In all transactions where additional amounts are needed – see notes below. Description: This field provides information on up to 6 amount types and related account

data for which specific data elements have not been defined.

For each amount a set of sub-fields must be delivered. The specific use of each set is determined by the amount type.

Each amount rsp. amount type is specified by means of the following structure:

(18)

Sub-field Position Type Description 1 1-2 ans 2 Account type

The following values are defined:

“00” (xF0F0): default

2 3-4 ans 2 Amount type, describing the use of the amount detailed in the next sub-fields.

The following types are specified:

“40” (xF4F0): amount

cash back

“02” (xF0F2): available

balance

3 5-7 n 3 Currency code, containing the numeric ISO code for the currency used for the amount

4 8-8 ans 1 Debit / credit indicator, describing the impact of the transaction on the cardholder account The following values are defined:

“D” (xC4): debit

“C” (xC3): credit

5 9-20 n 12 Amount

Note 1: In case of an EMV chip based cash back transaction the cash back amount has to be submitted also in BMP 55 SF13.

Note 2: In case of a cash back transaction BMP 54 additional amounts is mandatory in the authorization request and it will be mirrored in the response.

Note 3: In case the available balance was provided in the authorization response of the issuer BMP 54 additional amounts is added to the response.

BMP 54: Amount other

Field Type: ans 20

Mandatory: In all transactions where additional amounts are needed, i.e. amount given to cardholder in cash (cashback)

Description: The field is divided into sub-fields which have a fixed length and represent the following data.

ans 2: account type (RFU, fixed value xF0F0) ans 2: amount type (value xF4F0 – cashback) n 3: ISO currency code

ans 1: debit / credit indicator (xC4=D [debit / cashback], xC3=C [credit / RFU) n 12: amount other (also to be sent in BMP 55 SF13 for chip tx.)

BMP 55: ICC data

Field Type: LLLVARb ...999

Mandatory: In all transactions where chip-card is present

(when ICC is read as well as in Fallback cases).

(19)

In all manual reversal requests when Issuer Script Results are present. In all reversal requests initiated by the chip card.

Description: This field can be used to transfer ICC-related data from a host to a terminal or vice versa. The field is divided into sub-fields. Every sub-field has the following structure:

Format: LLLxxy...y

LLL: length definition

xx: sub-field number

y...y: data (variable number of characters)

The length definition is of fixed length (3 bytes EBCDIC) and defines the total length of "sub-field number" with "data". The sub-field number is of fixed length (2 bytes EBCDIC) and defines the meaning of the data.

Definition of the values of the sub-field number: 01...50: reserved for ICC-related request data 51...99: reserved for ICC-related response data

It is possible that several sub-fields appear in field 55. Each subfield is mandatory if it is available.

Sub- field

EMV

Tag Field Name Field Type Source

1 9F26 Application Cryptogram b8 IC Card

2 9F27 Cryptogram Information Data b1 IC Card

3 9F10 Issuer Application Data (IAD) b0..32 IC Card

4 9F37 Unpredictable Number b4 Terminal

5 9F36 Application Trx. counter (ATC) b2 IC Card 6 95 Terminal Verification Results b5 Terminal

7 9A Transaction Date b3 Terminal

8 9C Transaction Type b1 Terminal

9 9F02 Transaction Amount b6 Terminal

10 5F2A Transaction Currency Code b2 Terminal

11 82 Application Interchange Profile b2 IC Card

12 9F1A Terminal Country Code b2 Terminal

13 9F03 Amount, Other b6 Terminal

14 9F33 Terminal Capabilities b3 Terminal

15 9F34 CVM results b3 Terminal

16 9F35 Terminal Type b1 Terminal

17 9F1E Interface Device (IFD) Serial No b8 Terminal

18 9F53 Transaction category Code b1 Terminal

19 84 Dedicated File Name b5..16 Terminal

20 9F09 Terminal application version no. b2 Terminal 21 9F41 Transaction Sequence Counter b4 Terminal

22 Issuer Script Results b1..21 IC Card

24 DF02 Error detection b15 Terminal

51 91 Issuer Authentication Data b8..16 Issuer Host 52 71 Issuer Script Template 1 b0..127 Issuer Host 53 72 Issuer Script Template 2 b0..255 Issuer Host 54 8A Issuer Authorization Response

Code

(20)

Sub-field 1: Application Cryptogram (TAG 9F26)

Field Type: b8

Description: Cryptogram returned from the ICC in response of the GENERATE AC command

Sub-field 2: Cryptogram Information Data (TAG 9F27)

Field Type: b1

Description: Indicates the type of cryptogram and the actions to be performed by the authorization system

Sub-field 3: Issuer Application Data (IAD) (TAG 9F10) Field Type: b0..32

Description: Contains proprietary application data for transmission to the issuer in all transaction messages.

Sub-field 4: Unpredictable Number (TAG 9F37)

Field Type: b4

Description: Value provided by the terminal to provide variability and uniqueness to the generation of the application

Sub-field 5: Application Transaction Counter (ATC) (TAG 9F36)

Field Type: b2

Description: Counter maintained by the application in the ICC, indicates the number of transactions processed by the card application

Sub-field 6: Terminal Verification Results (TAG 95)

Field Type: b5

Description: Result of the different verification operations performed by the authorization system.

Sub-field 7: Transaction Date (TAG 9A)

Field Type: b3 (YYMMDD)

Description: The local date that the transaction was authorized Sub-field 8: Transaction Type (TAG 9C)

Field Type: b1

Description: Indicates the type of financial transaction, representing the first two digits of ISO 8583:1987 Processing code Sub-field 9: Transaction Amount (TAG 9F02)

Field Type: b6

Description: Authorization amount of the transaction as provided by the terminal to the card.

Sub-field 10: Transaction Currency Code (TAG 5F2A)

Field Type: b2

Description: Indicates the currency code of the transaction according to ISO 4217

Sub-field 11: Application Interchange Profile (TAG 82)

Field Type: b2

Description: Indicates microcircuit application-specific functions (information supplied by the card).

Sub-field 12: Terminal Country Code (TAG 9F1A)

(21)

Description: Indicates the country of the terminal, represented according to ISO 3166

Sub-field 13: Amount, Other (TAG 9F03)

Field Type: b6

Description: Secondary Amount of the transaction (e.g. Cashback Amount) as provided by the terminal to the card Sub-field 14: Terminal Capabilities (TAG 9F33)

Field Type: b3

Description: Indicates the card data input, CVM, and security capabilities of the terminal

Sub-field 15: CVM Results (TAG 9F34)

Field Type: b3

Description: Result of Cardholder Verification Procedure Sub-field 16: Terminal Type (TAG 9F35)

Field Type: b1

Description: Indicates the environment of the terminal, its

communications capability, and its operational control. Sub-field 17: Interface Device (IFD) Serial Number (TAG 9F1E)

Field Type: b8

Description: Unique and permanent serial number assigned to the IFD by the manufacturer

Sub-field 18: Transaction category code (TAG 9F53) Field Type: b1 (ASCII Format)

Description: Describes the environment of the TRX. Derived from MCC.

Valid Values:

Hex ASCII Meaning

'43' 'C' Cash Disbursement '5A' 'Z' ATM Cash Disbursement '4F' 'O' College/School Expense

'48' 'H' Hotel, Motel and Cruise Ship Services '58' 'X' Transportation

'41' 'A' Automobile/Vehicle Rental

'46' 'F' Restaurant

'54' 'T' Mail, Telephone Order, Pre-authorized Order

'55' 'U' Unique Transaction '52' 'R' Retail, all other transactions Sub-field 19: Dedicated File Name (TAG 84)

Field Type: b5..16

Description: Contains the card application identification code for the card application from ISO 7816-5, selected by the terminal

Sub-field 20: Terminal application version no. (TAG 9F09)

Field Type: b2

Description: EMV Version of the Terminal SW Sub-field 21: Transaction sequence counter (TAG 9F41)

(22)

Field Type: b4

Description: Counter maintained by the terminal that is incremented by one for each transaction

This counter can be aligned with Bmp 11. If this option is used, TAG 9F41 has to be the concatenation of the Byte '00' and Bmp 11.

Sub-field 22: Issuer Script Results Field Type: b1..21

Description: Results of the Issuer Script Execution Sub-field 24: Error Detection (TAG DF02) Field Type: b15

Description: Documents the state of the chip processing in the card and in the terminal if the transaction is not successfully processed based on the EMV chip. In this case the transaction involving an EMV chip or hybrid card does not end with the calculation and the transfer of a TC in executing the second GENERATE AC

For definitions of the subfields, please see the current GICC specification.

The following fields are mandatory in all EMV responses when available: Sub-field 51: Issuer Authentication Data (TAG 91)

Field Type: b8..16

Description: Data transmitted to the card for the purposes of issuer authentication. In this version of the specification, the Issuer Authentication Data consists of the following data: • First 8 bytes = ARPC

• Last 2 bytes = ARPC Response Code Sub-field 52: Issuer Script Template 1 (TAG 71) Field Type: b0..127

Description: Contains issuer-specific data sent to the microcircuit prior to executing the second "Generate AC" command. Said data is commonly comprised of one or more "Issuer Script Command" items of information data items used on a unit basis in the Terminal-Card dialogue.

Sub-field 53: Issuer Script Template 2 (TAG 72) Field Type: b0..255

Description: Contains issuer-specific data sent to the microcircuit after executing the second "Generate AC" command. Said data is commonly comprised of one or more "Issuer Script Command" items of information data items used on a unit basis in the Terminal-Card dialogue.

Sub-field 54: Issuer Authorization Response Code (TAG 8A) Field Type: b2 (ASCII Format)

Description: If the Issuer Authorization Response Code present in a response Message this value has to be transmitted to the ICC during 2nd_{GENERATE AC if requested in the}

(23)

corresponding DOL.

If this value is not part of the response message the value of TAG 8A has to be derived from the content of Bmp 39.

Bmp 39

(EBCDIC) TAG 8A(ASCII) Description

'00' '00' Approved

'02' '01' Referral

Any other '05' Decline

Sub field 54 is introduced with KAAI message version '0001'.

BMP 57: Sequence generation number

Format: LLLVARans...999 (either 9 or 58 bytes, fixed)

Conditionallymandatory for messages containing BMP 64

Contents: This field is required for calculating the MAC and PAC for PIN-transactions. Description: The Generation Number is only used in the 58 byte format. It shall be set to "0"

(EBCDIC) in 9 byte format.

The Random Number Message Security specifies which random number is to be used to derive the session key for MAC generation / verification.

The Random Number PAC specifies which random number is to be used to derive the session key for PIN Block encryption / decryption. If the message contains no PAC but MAC is present the Random Number PAC has to be filled with binary zeroes.

The Network Operator Identification Number (Operator-ID) is used to generate the unique communication link key between acquirer and network operator. This key is derived from the master key MKACQ and the Operator-ID.

The Hardware Vendor Identification Number is used to generate the unique terminal key and identifies the hardware vendor of the used PED respectively HSM.

The Hardware Serial Number is used to generate the unique terminal key and identifies the used PED respectively HSM.

The Sequence number (EBCDIC) has no meaning in KAAI and shall be set to "00000000" (be 'F0F0F0F0F0F0F0F0' binary).

The following formats are possible: Format without encrypted PIN and MAC

Format: LLLssssssssz

LLL: Length specification "F0F0F9" ssssssss: Sequence- number (EBCDIC)

(24)

Format with encrypted PIN and MAC (network operator) Format:

LLLssssssssz[vmmmmmmmmmmmmmmmmppppppppppppppppiiiiiiiiiiiiiiii] LLL: Length specification "F0F5F8"

ssssssss: Sequence- number (EBCDIC) (shall be set to "00000000")

z: Generation- number (2 BCDs)

v: Version- number (2 BCDs)

m…m (16): Random Value for Message Security session key derivation (binary)

p…p (16): Random Value for PIN Block Encryption session key derivation (binary)

i…i (16): Network Operator Identification Number (Operator ID), left justified padded with '00' (binary)

Format with encrypted PIN and MAC (terminal) Format: LLLssssssssz[vmmmmmmmmmmmmmmmmppppppppppppppppiiiiiihhhhhh hhhh] LLL: Length specification "F0F5F8" ssssssss: Sequence- number z: Generation- number (2 BCDs) (shall be set to "00000000") v: Version- number (2 BCDs)

m…m (16): Random Value for Message Security session key derivation (binary)

p…p (16): Random Value for PIN Block Encryption session key derivation (binary)

i…i (6): Hardware Vendor Identification Number (Vendor-ID) (binary)

(25)

BMP 60: Additional data

Format: LLLVARans...999

Mandatory field in 01xx and 04xx requests and request repeats for electronic commerce transactions, else optional

repeat requests, if electronic commerce, otherwise optional

Contents: This field can be used to transfer additional data from a host to a terminal or vice versa. The field is divided into Subfields. Every Subfield has the following structure:

Format: LLLxxy...y

LLL: length definition

xx: Subfield number

y...y: data (variable number of characters)

The length definition is of fixed length (3 bytes EBCDIC) and defines the total length i.e. length of "Subfield number" plus length of "data". The Subfield number is of fixed length (2 bytes EBCDIC) and defines the meaning of the data.

Definition of the values of the Subfield number: 00...19: reserved for system use

20...79: reserved for standard use 80...99: reserved for private use

It is possible for several Subfields to appear in field 60, although each individual subfield may only occur once in a message.

This field can be used to transfer additional data from a key account host to an authorization host or vice versa. The field is divided into sub-fields. Every sub-field has the following structure:

Format: LLLxxy...y whereby: LLL: length definition xx: Number of sub-field y...y: Data

The length definition is of fixed length (3 bytes EBCDIC) and defines the total length of the sub-field, including the data. The sub-field number is also of fixed length (2 bytes EBCDIC) and indicates how the data is to be interpreted. The sub-field numbers have been broken down into the following categories:

00...19: Reserved for system use

20...79: Reserved for standard use by the CCIs 80...99: Reserved for private use

Note: It is possible for several sub-fields to appear in field 60, although each individual subfield may only occur once in a message.

(26)

Sub-field Description

30 CVV2 (alternatively known as CVC2) Format: Alphanumeric, length 3 or 4 bytes

This subfield is to be used pursuant to the rules of American Express (4 bytes), MasterCard and VISA (each 3 bytes) and in agreement with the acquirers in 01xx request messages (excluding refunds).

Contents: Position 1-3 rsp. 1-4: CVV2 value as imprinted on card (left justified, right padded with spaces)

Note: any form of storage of the CVC2 (CVV2) is expressly forbidden!

31 Address Verification Data, Request 2

Format: ans 49

Optional in 01xx request and repeat messages. This field is fixed length 49 bytes, EBCDIC.

Contents: This field contains address data of the cardholder. Format 1:

Pos. Type Description

1-9 an 9 This sub-field contains only the numerics of the postcode

10-49 ans 40 This sub-field contains up to 5 numerics from the cardholders billing address

Format 2:

Pos. Type Description

1-9 an 9 This subfield contains the complete postcode 10-49 ans 40 This subfield contains the cardholder billing

address

Examples of addresses in format 1 are shown in the following table.

Postal address Pos Value

Flat. 4a, 123 London Rd., London CH48 8AQ │ │ │ │ │ │ └──┴──►

└────┴─────────────────────────────► 1-9 _10-49 488^^^^^^_4123^^...^ 1 Elm Street, Valley Stream, NY 1151

│ │ │ └───────► └────────────────────────────────────────► 1-9 _10-49 1151^^^^^ 1^^...^ Spachbrücker Str. 21, 64354 Reinheim │ │ │ └────────────────► └─────────────────────► 1-9 10-49 64354^^^ ^ 21^^...^

The Ridings, Dean Ct., Guildford GU14 7SR │ │ └──┴──► 1-9 10-49 147^^^^^^ ^^...^ . . .

(27)

32 Address Verification Data, Response Format: ans 2

Optional in 01xx response messages. This field is fixed length 2 bytes, EBCDIC.

Contents: This field contains the AVS Result code

Pos Type Description

1 ans 1 Authorization Entity

2 = Response provided by Intermediate processor

5 = Response provided by issuer processor 2 an 1 AVS Result Code – additional codes in

agreement with the respective CCI N = No Match

The match is not exact because the post code and/or the addresses do not match. U = Unavailable

Address information is unavailable or the Issuer does not support AVS. Acquirer has representment rights.

F = Exact Match

The match is exact; both the address and the post code matches. No representment rights.

35 Additional merchant data (01xx requests only)

Variable length, maximum 30 characters, alphanumeric (merchant reference number or sequence generation number)

Note: for DCC tx. this field may contain 18 left-most bytes of the Rate- Request-Reference-ID from FCC’s Rate-Request response, if applicable. 36 Additional cardholder data (01xx requests only)

Variable length, maximum 30 characters, alphanumeric (cardholder reference).

(28)

37 Dynamic currency conversion data–- _{see also Note in SF 35}

Format: an 24

Optional in 01xx; 02xx and 04xx request and repeat messages. This field is fixed length 24 bytes, EBCDIC.

Contents: This field contains data related to dynamic currency conversion.

Pos Type Description

1 an1 DCC status

This subfield documents the eligibility of the transaction for DCC (according to the merchant setup) as well as the decision of the cardholder. E = DCC enabled but not used

U = DCC used

Else: = not DCC enabled

2 an 3 Currency code of merchant currency

This subfield specifies the transaction currency of the source location.

5 an 12 Transaction amount in merchant currency This subfield contains the transaction amount in the transaction currency of the source location. 17 an 8 DCC conversion rate

This subfield contains the conversion rate used to convert transaction amount in the merchant's currency to the transaction amount (BMP 4) in the cardholder’s currency.

The leftmost digit denotes the number of positions the decimal separator shall be shifted from right. The remaining digits are the actual rate without a decimal separator.

(29)

40 Electronic Commerce Indicator Format: an 2

Mandatory in 01xx and 04xx request and repeat request messages when POS Entry Mode (BMP 22) = '81x'. Optional in 01xx and 04xx response

messages.

Contents: the electronic commerce indicator qualifies the security level for an e-commerce transaction. Valid values are:

Valid values: 00 = Not applicable 07 = Channel encrypted 08 = No security

10 = Fully authenticated with Verified by Visa (applicable for Visa acceptance only)

11 = Fully authenticated with MasterCard Secure Code (applicable for MasterCard or Maestro acceptance acceptance only)

12 = The merchant offers Verified by Visa in production but the cardholder did not take advantage of it, or the attempt to use it failed (applicable for Visa acceptance only).

13 = MasterCard or Maestro acceptanceacceptance: the merchant offers MasterCard Secure Code in production but the cardholder did not take advantage of it

(applicable for MasterCard or Maestro acceptance acceptance only).

20 = MasterCard or Maestro acceptance: the merchant participates in the MasterCard or Maestro Advanced Registration Program (static AAV)

41 Indicator for recurring or installment payments. Valid values: Format: an2

Optional in 01xx and 04xx request and repeat request messages.This field is fixed length 2 bytes, EBCDIC.

Contents: This field specifies whether a transaction is part of a series of recurring transactions or part of a series of installment payments. In either case the indicated transaction might be the first or a subsequent transaction. In all cases, the initial transaction of such a series of transactions must also be identified as a recurring transaction or installment payment. Valid values are: 02 = Recurring payment (wiederkehrend)

03 = Installment payment (Ratenzahlung) 42 UAT Indicator

Format: an2

Optional in 01xx and 04xx request and repeat request messages.This field is fixed length 2 bytes, EBCDIC.

Contents: indicator for type of unattended terminal. Valid values: Valid values:

01 = Automated dispensing machine with PIN 02 = Self-service terminal

03 = Limited amount terminal 04 = in-flight commerce 10 = petrol-pump

Note: An unattended terminal may be indicated in BMP 25, in BMP 60, subfield 42, or in both locations.

(30)

43 Installment Payment data – in agreement with the respective acquirer only Format: an33

Optional in 01xx and 04xx request and request repeat messages.This field is fixed length 33 bytes, EBCDIC.

Contents: This field supports the transmission of installment payment data. The indicated transaction might be the first or a subsequent transaction. In all cases, the initial transaction of such a series of transactions must also be identified as an installment payment.

Pos Type Description

1 an12 Total Amount - field contains the

payments total. Zero-filled, right-justified.

2 an3 Currency Code - field contains the currency code of the payment submitted.

3 an3 Number of Installments - field

contains the number of installment payments that will occur.

Zero-filled, right-justified.

4 an12 Amount of each Installment - field contains the amount of each installment payment. Zero-filled, right-justified.

5 an3 Installment Payment Number

- field contains the installment payment number.

Zero-filled, right-justified.

6 an1 Frequency of Installments - field

contains the frequency of the installment payments. Valid values are:

B = Bi-weekly M = Monthly W = Weekly

50 Duplicate data: Data sent in a request from the key account computer must be returned in the response from the authorization system (e.g. data for the key account computer for routing the response message to the terminal which originally sent the request).

61 XID, applicable for Visa acceptance only:

Mandatory if available 100, 200 and 400 messages and optional in 110, 210, 220, 230 and 410 messages if:

BMP 22 (POS Entry Mode) = '81x'and BMP 60 (Additional Data), subfield 40 (Electronic Commerce Indicator) = '10' or '12'.

Contents: XID: fixed length, 20 bytes, binary.

(31)

62 CAVV (Cardholder Authentication Verification Value), applicable for Visa acceptance only.

Mandatory in 100 and 200 messages and optional in 110, 210, 220, 230, 400 and 410 messages if:

BMP 22 (POS Entry Mode) = '81x' and BMP 60 (Additional Data), subfield 40 (Electronic Commerce Indicator) = '10' or

Mandatory if available in 100, 200 and 400 messages and optional in 110, 210, 220, 230 and 410 messages if:

BMP 22 = '81x' and BMP 60, subfield 40 = '12' . Contents: CAVV: fixed length 20 bytes, binary.

63 UCAF (Universal Cardholder Authentication Field), applicable for Mastercard or Maestro acceptance only:

Mandatory in 100 and 200 messages and optional in 110, 210, 220, 230, 400 and 410 messages if:

BMP 22 (POS Entry Mode) = '81x' and BMP 60 (Additional Data), subfield 40 (Electronic Commerce Indicator) = '11'.

Mandatory if available in 100 and 200 messages and optional in 110, 210, 220, 230, 400 and 410 messages if:

BMP 22 = '81x' and BMP 60, subfield 40 = '13'.

Contents: UCAF: variable length, maximum 32 bytes, EBCDIC.

Transition period until April 2004: an empty UCAF field in 100, 200 and 400 messages will be interpreted to mean "the merchant offers UCAF in

production but the cardholder did not take advantage of it" if: BMP 22 = '81x' and BMP 60, subfield 40 = '11'.

BMP 61: Transaction stamp

Format: LLLVARans...999

Optional in 0110, 130, 0430

Contents: The authorization center may place a reference number in this field which must be repeated when the transaction is submitted for booking.

(32)

BMP 63: KAAI message format version number

Field type: N6

Conditionallymandatory in all requests and responses when version 2.00e (or higher) of KAAI is supported.

Description: This data element is needed when backward compatibility can not be assured. Especially this will be the case when new response data elements are introduced.

The KAAI message format version is related to the version of the KAAI Protocol. If certain functionality is linked to a specific KAAI message format version, this is indicated in the description of the message field. If a certain message format version is used, all features of this message format need to be supported. Message Format Version KAAI Version Enhancements '000000' or BMP 63 not present < 2.00e N.A.

'000001' >= 2.00e • New Subfield 54 in BMP 55

'000002' >= 2.20e • New BMPs 15 and 54 and

BMP 61 used

'000003' >= 2.23e • New format of BMP 54

(mandatory if used) and new response code 85 for cashback

BMP 64: Message authentication code - MAC

Format: b 64

Optional; mandatory in requests and request repeats: 010x if online-PIN is used. Optional in all other requests. Mandatory in responses where MAC was present in the request.

Contents: The message authentication code (MAC) serves as a cryptographic authentication and is always to be found in the last field of the message.

Description: The field is only in the message if there is no extended Bit Map. This field contains a Retail CBC-MAC generated according to the (Triple-)DES block-chaining algorithm with an initial null-vector (s. section 6.2.7). Used to validate the source and the text of the message between the sender and receiver. The last bit position within any bit map shall be reserved for the MAC field. If authentication is to be used in a message, the MAC field will be represented by the final bit in the final bit map of that message. The final bit of all previous bit maps shall contain zero. Only one MAC field per message shall be the last data element of the message.

(33)

4 Overview

4.1 Options for the individual record types

BMP 0100 0101 0110 0120 0121 0130 0420 0421 0430 0800 0810 Format Number of bytes

MTI M M M M M M M M N4 2 2 M M M M M M - - LLVARn..19 2+10 3 M M M M M M - - N6 3 4 M M M M M M - - N12 6 11 M M M M M M M M N6 3 12 M M M M M M M M N6 3 13 M M M M M M M M N4 2 14 M M M M M M - - N4 2 15(3)_{- C} _- _{C - C - -}_N4 ₂ 22 M - M - M - - - N3 2 23 (4) C C C C C C - - N3 2 25 M - M - M - - - N2 1 26 (5) _{C - - - C - - -}_N2 ₁ 32 M M M M M M M M LLVARn..11 2+6 35 O - O - O - - - LLVARz..37 2+19 37 - - - - M - - - an12 12 38 - M M M - M - - ans6 6 39 - M - M - M - M an2 2 416 _{C C C C C C - -}_ans8 ₈ 42 M M M M M M - - ans15 15 43 O O O O O O - - LLVARans..99 2+40 49 (7) _{C - C - C - - -}_N3 ₂ 52 (8) C - - - C - - - b64 8 53 (9) _{C C C C C C C C}_N16 ₈ 54(10)_{C C} _- _{- C C - -}_ans20 ₂₀ 55 (₁₁) _{C C C C C C - -}_{LLLVARb...999 3+266} 57 (12) _{C C C C C C O O}_{LLLVARans...999}₃₊₉ 60 O O O O O O O O LLLVARans...999 R 61 - O - O - O - - LLLVARans...999 T 63 C C C C C C C C N6 3 64 (13) _{C C C C C C O O}_b64 ₈ Key: M = Mandatory C = Conditionally mandatory O = Optional R = Routing information

T = Transaction stamp (reference number)

3 Conditionally mandatoryif sent by the issuer

4 Conditionally mandatory or mandatory if a chip card containing TAG 5F34 is present 5 Mandatory: if online PIN is entered

6_{Mandatory for all MasterCard products, all other cards as per agreement with CCI.}

7 Optional if key account partner only submits in a single currency, otherwise mandatory 8 Mandatory when Transactions: 010x and 040x contain PIN-Data

9 Mandatory in messages where BMP 64 is present 10 Mandatory in messages where BMP 03=09

11_{Mandatory when positions 1+2 of BMP 22 = '05' (EMV card present)}

12 Mandatory in messages where BMP 64 is present

(34)

Note: The key account host may deposit routing information in BMP 60; this must be returned unaltered in the reply from the authorization center. Due to the structure of BMP 60, the field size is in this case: 8 bytes + number of bytes of routing information.

(35)

5 Appendix A: Example POS Terminal Receipts

The receipts illustrated in this chapter contain certain texts (literals and variables) in German. English translations of these texts are provided in square parentheses ( '[...]' ) in the right-hand column.

For configuration of receipts on EMV devices, please see the current GICC specification. All receipts generated by an electronic POS device (attended or unattended) shall:

• Include only the last four digits of the PAN (replacing all preceding digits with fill characters that are neither blanks nor numeric characters, such as 'X', '*', or '#') on the cardholder receipt, • Exclude the card expiration date.

• Offer both options for the merchant receipt:

a) truncate the PAN as above and truncate the card expiration date as well. b) print the full PAN and the full card expiration date.

(As required in “PCI Data Security Standard”: mask account numbers when displayed.)

For electronic POS devices that do not currently truncate the PAN, compliance must occur immediately with both the PAN truncation and expiration date exclusion requirements. With respect to already deployed terminals currently producing receipts that properly reflect a truncated PAN only, the changes may be implemented no later than December 31, 2010.

(36)

5.1 Purchase and Refund Transactions

M U S T E R C A R D S E R V I C E

[A C M E C A R D S E R V I C E] Type: ans 16 Note: Optional / Publicity Text, Name of the Card Acquirer, Part of Initialization Data

VERTRAGS NR.: AAAAAAAAAAAAAAA [MERCHANT ID] Field: 42 Type: ans 15 Note: mandatory

TRANSAKTIONS NR.: NNNNNN [TRANSACTION NO.] Field: 11 Type: N 6 Note: Mandatory

VERTRAGSUNTERNEHMER GmbH [ACME DEPT. STORES PLC] 5 lines with 24 characters

Note: Mandatory

MUSTER ABTEILUNG [ACME DEPT.] 5 lines with 30 characters Note: Optional

BEISPIEL STRASSE 46-49 [46-49 MAIN STREET] Note: Merchant Name, Merchant

Address, other declarations, Part of Initialization Data

00000 MUSTERHAUSEN [NY 99999 ACMEVILLE]

BETREIBER-ID NNNNNNNNNNN [OPERATOR ID] Field 32: Acquiring Institution Identification Code Note: Mandatory (first 6 digits)

SERIEN NR.: NN NNN

*1 *2

NN *3

*1 Field: 3 Type: N 6 Note: Mandatory, digits 1 + 2 of field 3 *2 Field: 22 Type: N 3 Note: Mandatory

*3 Field: 25 Type: N 2 Note: Mandatory

MUSTER KARTE [ACME CARD] Type ans 16 Name of the processed card type

VERFALLDATUM: NN/NN [EXPIRY DATE] Field: 14 Type: N 4 Note: Mandatory -

MM/YY

N N N N N N N N N N N N N N N N Field: 2 Type: LLVARn..19 Note: Mandatory

Emil Mustermann [JO BLOGGS] Note: Name of Cardholder from Track 1 if

available.

BEZAHLUNG [PAYMENT] Note: Transaction Type x1

BETRAG: EUR NNNNNNNNN.NN [AMOUNT] *1 other currency code if send in Field: 49

*1 *2 *2 Field: 4 Type: N12 Note: Mandatory

GENEHMIGUNGS NR.: A A A A A A *1 [AUTHORISATION NO.] *1 Field: 38 Type: an 6 Note: Mandatory

NN/NN NN:NN *1 Field: 13 Type: N4 Note: Mandatory - DD/MM

*1 *2 *2 Field: 12 Type: N6 Note: Mandatory, the first 4 digits -

hh/mm BITTE BELEG AUFBEWAHREN UND DIE

KOPIE AN DEN KUNDEN AUSHÄNDIGEN

[PLEASE RETAIN RECEIPT AND HAND COPY TO CUSTOMER]

UNTERSCHRIFT: ____________________ NN/NN/NNNN

[SIGNATURE]

Date at terminal DD/MM/YYYY

(37)

5.2 Reversal, Purchase and Refund Transactions

M U S T E R C A R D S E R V I C E

[A C M E C A R D S E R V I C E] Type: ans 16 Note: Optional / Publicity Text, Name of the Card Acquirer, Part of Initialization Data

VERTRAGS NR.: AAAAAAAAAAAAAAA [MERCHANT ID] Field: 42 Type: ans 15 Note: Mandatory

TRANSAKTIONS NR.: NNNNNN [TRANSACTION NO.] Field: 11 Type: N 6 Note:

Mandatory

VERTRAGSUNTERNEHMER GmbH [ACME DEPT. STORES PLC] 5 lines with 24 characters

Note: Mandatory

MUSTER ABTEILUNG [ACME DEPT.] 5 lines with 30 characters Note: Mandatory

BEISPIEL STRASSE 46-49 [46-49 MAIN STREET] Note: Merchant Name, Merchant

Address, other declarations 00000 MUSTERHAUSEN

[NY 99999 ACMEVILLE] Part of Initialization Data

BETREIBER-ID NNNNNNNNNNN [OPERATOR ID] Field 32: Acquiring Institution

Identification Code Note: Mandatory (first 6 digits).

SERIEN NR.: NN NNN

*1 *2

NN *3

*1 Field: 3 Type: N 6 Note: first 2 digits mandatory *2 Field: 22 Type N 3 Note: Mandatory

*3 Field: 25 Type: N 2 Note: Mandatory

MUSTER KARTE [ACME CARD] Type ans 16 Note: Name of the processed

card type

VERFALLDATUM: NN/NN [EXPIRY DATE] Field: 14 Type: N 4 Note: Mandatory -

MM/YY

N N N N N N N N N N N N N N N N Field: 2 Type: LLVARn..19 Note: Mandatory ORIGINAL TRANSAKTIONS NR: NNNNNN [ORIGINAL TRANSACTION NO.] Note: Transaction

number of the original transaction to be reversed

STORNO - BEZAHLUNG [REVERSAL - PAYMENT] Note: Transaction Type (in Red

- Optional) x1

BETRAG: EUR NNNNNNNNN.NN [AMOUNT] *1 other currency code if send in Field: 49

*1 *2 *2 Field: 4 Type: N 12 Note: Mandatory

GENEHMIGUNGS NR.: A A A A A A *1 [AUTHORISATION NO.] *1 Field: 38 Type: an 6 Note: Mandatory

NN/NN NN:NN *1 Field: 13 Type: N4 Note: Mandatory - DD/MM

*1 *2 *2 Field: 12 Type: N6 Note: Mandatory, the first 4 digits

hh/mm BITTE BELEG AUFBEWAHREN UND DIE

KOPIE AN DEN KUNDEN AUSHÄNDIGEN

[PLEASE RETAIN RECEIPT AND HAND COPY TO CUSTOMER]

UNTERSCHRIFT: ____________________ NN/NN/NNNN

[SIGNATURE]

Date at terminal DD/MM/YYYY

x1: This could also be: STORNO-AUTORISIERUNG [AUTHORISATION REVERSAL], STORNO GUTSCHRIFT [REFUND REVERSAL]

Key Accounts Authorization Interface