Managing payment applications and their attributes is now a fundamental aspect of issuing EMV cards. A card is no longer just ‘a card’, but is a container for one or more payment applications, together with account and personal information, risk and other parameters, and security settings. With card and application lifecycle management, issuers can manage risk and maintain on-chip settings remotely.


Cardholder Credentials
The cardholder credentials make up what we know and have seen on payment cards since the first cards were printed in the 1950s:

  • Cardholder Name
  • Primary Account Number (PAN)
  • Expiry Date

Over time, security and appearance features were added to the cards: embossing, magnetic stripe, PIN, CVV2 to the signature field, holograms, and not least: microprocessors, aka chips.
In other words, today, the card becomes personalized using almost all of the above-mentioned technologies (i.e. using engraving, printing, or embossing) alongside with the PII (Personal Identifiable Information) of the cardholder, which in turn is used to encode the magnetic stripe on the back, calculate the CVV2 value, and personalize the data and cryptographic keys stored on the chip.

Risk Parameters
Traditionally, risk management could only take place at the point of authorization, i.e. checking parameters such as e.g. a) the size of transacted amount, b) the frequency with which amounts are requested, c) the merchant category, etc. However, with EMV and the introduction of chip, a number of those parameters have moved from the shoulders of the merchant or issuer's back-end to the issuer onto the chip itself, for example:

  • Cardholder Verification Method (aka CVM)
  • Offline limits
  • PIN Retries

Applications on the chip can be set up to accept, or even prefer various types of cardholder verification, i.e. none, signature only (to be validated by the merchant), online PIN, or even offline PIN. When dealing with offline transactions, the merchant does not have a direct connection to the network, which means that the merchant (often an automated kiosks) must transact according to limits available on the card. For example, the card may have been set up to accept up to 100$ in total transactions, over a maximum of 5 transactions while offline (until the card comes online again, at which point the counter should be updated automatically). In another example, the offline PIN may be set to, say 4 PIN retries before blocking. Any such paramters are controllable by the issuer, and the issuer requires a system to help take advantage of these both on a card product level, as well as on an authorization level.

Multiple Applications and the AID
Finally, a chip card will often contain many applications, and the card must be set up to negotiate which to use according to interface and preference of the issuers. Outside the United States, for instance, it is common to support a domestic payment scheme as well as an international payment scheme. In the US, for debit cards, it is common to support two variants - a common US Debit application, as well as an international debit application. Applications are typically set up and configured independently, and each is identified on the basis of an application identifier (aka AID).




Product Collaterals (pls ask)

Standards (Links)

Payment Schemes (Links)

Common Abbreviations