One of the least explored areas of EMV lays in initial stages of terminal to card communication. A card lodges a data message in its memory upon power up. Layout of this message conforms with ISO/IEC 7816 and can be retrieved by a card reader (sReaderState.cbAtr). The ATR message contains information on proposed card communication parameters, card’s manufacturer or issuer, application selection options, country code and more. The ATR functionality is fully documented in ISO/IEC 7816 and many more documents, however those documents focus on Smart Cards in general and not payment cards. Therefore the aim of this article is to explain ATR in relation to EMV/NFC technology.
In this article we will review the ATR data elements (DE), but focusing on DE importance in a payment transaction. ATR fields covered:
The initial byte TS is a mandatory bit communication synchronization pattern. ATR values for this byte should read 0x3F or 0x3B. Processing of this value is usually handled by the card reader’s driver. It’s also advisable to check this value as an initial sanity check for card being plugged in.
The format byte is another mandatory field providing a bitmap from which one implies the remaining ATR fields. The first (most significant) 4 bits refer to the presence of TA1, TB1, TC1 and TD1 characters. The least significant bits refers to the size of historical data in bytes allowing an additional 0 – 16 bytes of historical data to be added to the message.
These conditional bytes are referred to as the global interface bytes and define a card’s operational abilities. In brief these fields refer to:
Subsequent fields TAi+1, TBi+1, TCi+1 and TDi+1 are out of scope for this article.
Historical Bytes typically hold Information about the Card Issuer, Type of Card or Operating System Version and this is where it becomes complicated. These bytes can be lodged in a proprietary format of a card manufacturer/issuer, or can be formatted in “compact TLV”. Unlikely EMV TLV, compact TLV uses 4 most significant bits to tell a tag and 4 least significant bites for data length. However the first byte of historical data coded in compact TLV should always read 0x00 or 0x80.
Some known compact TLV tags:
Tag 0x1h: Country code in (ISO 3166-1)
Example: 0x12 0x00 0x36 -> Australia
Tag 0x2h: Issuer identification number (ISO 7812-1)
Tag 0x3h: Card service data byte
When a bit is set to 1 in the card service data byte one may use that service.
|8||Application selection: by full DF name|
|7||Application selection: by partial DF name|
|6||BER-TLV data objects available in EF.DIR|
|5||BER-TLV data objects available in EF.ATR|
|4||EF.DIR and EF.ATR access services: by READ BINARY command|
|3||EF.DIR and EF.ATR access services: by GET DATA command|
|2||EF.DIR and EF.ATR access services: by GET RECORD(s) command|
|1||EF.DIR and EF.ATR access services: RFU|
Example: 0x31 0xC0 ->
Tag 0x4h: Initial access data
Tag 0x5h: Card issuer data
Tag 0x6h: Pre-issuing data
Example: 0x64 0x19 0x16 0x01 0x02
Tag 0x7h: Card capabilities
When a bit is set to 1 the card has the specified capability selection mode:
|8||DF selection by full DF name|
|7||DF selection by partial DF name|
|6||DF selection by path|
|5||DF selection by file identifier|
|4||Implicit DF selection|
|3||Short EF identifier supported|
|2||Record number supported|
|1||Record identifier supported|
Example: 0x71 0xD6 ->
Tag 0x8h: Status indicator
Tag 0xEh: Application identifier
As demonstrated above, a good understanding of ATR is a very important part of EMV functionality. In particular the ATR’s historical data can provide a payment device with several important clues to a card’s processing (selection options and the way card’s service options can be retrieved). Please let us know if you can contribute with your knowledge to this article – our team of EMV experts is ready to update information as we endeavour to start a community repository of EMV expertise.
Further reading on this topic can be found in our knowledge base document: Complete list of known ATRs.