Electronic card identifier - one more step for MIF compliance

Written by: Eric ten Voorde

May 24, 2016 - Honor all cards electronically

In July 2015, the European Parliament published a regulation for card-based payment transactions, which is also well known as the MIF (Multilateral interchange fee) regulation. The regulation covers any transaction taking place inside the European Economic Area (EEA) in case both the financial institution of the payer and the one of the payee are located in the EU/EEA. The interchange fee regulation is applicable to any card, mobile, phone, computer or other technological means that can be used to initiate a transaction.

As the name suggests, the most visible part of the regulation is the capping of interchange fees for different payment products (credit, debit, prepaid), which has come into force in December 2015. In June 2016, another important but less visible part of the MIF regulation is going to be effective. It is known as the ‘Honor all cards rule’, stated in Article 10 of the regulation.

Article 10 and in particular clause 5 allows merchants to NOT accept all cards. In other words, a merchant has the right to decide the card type that is to be accepted, depending on the interchange fees. To this end, the MIF regulation requires that at the moment of the transaction the payment card should clearly and electronically identify its type.

To comply with the EU regulation, the European Payment Council (EPC) – Card Working Group together with EMVCo defined a new data element: Application Selection Registered Proprietary Data (Tag 9F0A). This data element is intended to be used during Application Selection to identify the card type. This blog focuses on describing the impacts on different players within the payment ecosystem both from a business and technical perspectives.

Benefits for merchants

The new application selection registered proprietary data can potentially provide the merchants an opportunity to optimize the costs of accepting card payments. With the possibility to electronically identify the payment products at the moment of the payment transaction, merchants will have the opportunity to decide if payment from a certain card type is to be declined due to high interchange fee. This will prevent the merchant from accepting high interchange fee products without awareness. Depending on the actual needs, the checkout flow can be redesigned to leverage this data element. As examples, the following scenarios can happen depending on the implementation:

  • Merchant decides to continue with the transaction: when identifying a high interchange payment product (by reading the electronic identifier of the card) at the beginning of a transaction, the acceptance device would request the merchant decision. At this stage, the merchant can either choose to decline the transaction (due to high interchange fee of a specific product) or continue the transaction as business as usual.
  • Automatic transaction processing based on the pre-configuration of the merchant: Merchant can pre-configure the rules per card product (i.e. decline certain card product) or per payment scenario (i.e. decide if a certain product is accepted depending on the transaction amount/scenario). At the moment of the payment transaction, if certain card product or payment scenario is detected, the acceptance device will automatically decline the transaction.

Impacts to the EMV transaction flow

According to the requirement of EMVCo, the new application selection registered proprietary data is included in the issuer discretionary data, as a response to the Select Application command of EMV terminal kernel. The impacts to current EMV transaction flow due to the inclusion of this new data element are summarized as follow:

  • No impact on overall EMV flow: The idea of including the Application Selection Registered Proprietary Data in the issuer discretionary data is to facilitate the terminal to make decision on the transaction continuity at the very beginning of a transaction, namely the Application Selection process of an EMV transaction flow. Hence, the impact is on the exact process of Application Selection, instead of the overall EMV transaction flow (11 steps).
  • Application Selection process may be impacted: As the merchant may optionally choose to use this data to determine if the payment card is to be accepted, the exact application selection process may be impacted. The exact process is defined by the merchants or terminal vendors. Neither EMVCo nor EPC has requirement on it. In general, the following two are the most probable processes:
    • Manually determine if the card type is accepted: when the card respond to the terminal’s Select Application command, the terminal parses card response, identifies the card type and indicates it to the merchant. Then, the merchant would have the freedom to decide if the transaction with this card product will be proceeded or declined (i.e. by pressing a continue/terminate button). This method can only be applied to contact transactions, as it would significantly increase the time that the card has to remain in contact with the terminal.
    • Automatically determine if the card type is accepted: Merchant can pre-configure the terminal such that the acceptable card types are defined prior to the payment transaction. At the moment of the transaction, once the terminal identifies the card product (by reading the Application Selection Registered Proprietary Data) it can automatically continue or discontinue the transaction, based on the pre-configured data. This option is suitable for contactless transaction due to the limited tapping time of the contactless card. It is also good for contact transaction to reduce the overall transaction time.

Impacts to the ecosystem

The inclusion of this new data element may cause different levels of impacts to different players in the payment ecosystem.

  • Issuer impacts: The new EU regulation will get effective on June. 2016. By that time issuers in EEA region are required to personalize this new data in all the newly issued cards. With this change, it also means that the newly issued cards with 9F0A tag needs to pass new personalization validation by the payment schemes.
  • Merchant/Acquirer/terminal vendor impacts: Neither EMVCo nor EPC mandates that the acceptance side (merchant, acquirer) should use this new data. Therefore, the acceptance side is optional to update the current infrastructure & configuration to take use of this new data.
    • If the decision is to use this data, the acceptance side needs to upgrade the current kernel to parse and interpret the new data element. Also a proprietary process of taking use of this data needs to be designed (i.e. manual selection vs. automatic selection for transaction continue). Note: At this moment, EMVCo does not specify any certification requirement for such upgrades yet.
    • If the decision is to not use the data, there is in principle no impact to the acceptance side. Reason is that the new data tag is included in the issuer discretionary data and a normal behavior of the EMV terminal kernel is to ignore this ‘unrecognizable data’ and continue the transaction process. However, to guarantee this behavior and thus good interoperability of the terminal, additional testing is recommended.
  • Scheme impacts: For payment schemes, there is no technical impact in terms of the network messages, as the new data is included in the issuer discretionary data. However, the payment schemes need to come up with mandates and testing & acceptance requirements for issuers in the EEA region to correctly personalize this data. On the acquiring side, schemes may need to specify additional testing requirements to guarantee the interoperability between the different types of cards (incl. EEA cards with 9F0A data and non-EEA cards without the 9F0A data) and terminals, including those that take use of this new tag and those not.

Application Selection Registered Proprietary Data

The value field of the Application Selection Registered Proprietary Data object (Tag 9F0A) follows the following format: T, L, ID1, L1, V1, ID2, L2, V2.

  • T is the tag of the data. In this case it is 9F0A
  • L is the overall length (1 byte) of the Application Selection Registered Proprietary Data
  • ID is a two byte Proprietary Application Product Identifier
  • L1 and L2 are the lengths of the value fields coded in one byte (0 to 255)
  • V1 and V2 are the value field

For EEA (European Economic Area) issued cards the ID is defined as ’00 01’. Usually the value field of each data ID has a variable length of 1 to 5 bytes. At this moment, the length of ID ’00 01’ is set as one byte. The format of the value field is binary, which is defined as:


IFR Product Type


Debit Product


Credit Product


Commercial Product


Pre-paid Product

All other values

Reserved for future use

Therefore, depending on the card type, the terminal can expect to receive one of the following data:

Card Product Type



‘9F 0A 04 00 01 01 01’


‘9F 0A 04 00 01 01 02’


‘9F 0A 04 00 01 01 03’


‘9F 0A 04 00 01 01 04’

Reserved for future

‘9F 0A 04 00 01 01 xx’

According to EPC and EMVCo requirements, for contact application, this data shall be present:

  • In the Directory Discretionary Data (tag ‘73’) within all ADF Directory Entries
  • And additionally in the FCI Issuer Directory Discretionary Data (tag ‘BF0C’) within the FCI of all ADFs

For contactless application, this data shall be present:

  • In all Directory Entries (tag ‘61’) within the FCI of the PPSE
  • And additionally in the FCI Issuer Directory Discretionary Data (tag ‘BF0C’) within the FCI of all ADFs


Different interchange fees associated with different payment card products may bring negative impact to merchants, especially if the merchant is unaware of the associated fee at the moment of accepting the payment transaction. The new EU regulation offers the merchants in EEA region the freedom to decide if a certain card product is to be accepted. To this end, a new EMV tag, Application Selection Registered Proprietary Data (Tag 9F0A) is introduced by EMVCo to facilitate the electronic identification of a card product.

The introduction of this new data element leads to potential impacts to different players in the payment ecosystem. This includes issuers, acquirers, test tool vendors as well as payment schemes. Therefore, all above parties in the EEA region should carefully assess the impacts and be prepared to comply with the new EU regulation with minimum efforts and at the same time guarantees the high level of interoperability performance. The regulation focuses on mandating the card issuers to provide card product information. As for merchants, the regulation gives a possibility to take use of the card product information. However, in case of small differences in interchange fees between different products in comparison to the efforts needed to update the terminal, merchant can choose to do nothing.



These are the personal opinions of UL’s employees and its guests and should not be misunderstood as representing the opinion of UL's clients, suppliers or other relations.