A subset of EMV specifications

In General, the specifications are aimed at ensuring compatibility – the most important for the practice of payment systems properties of cards correctly served at different terminals and properties of terminals correctly serve different cards.

EMV specifications define a certain base on which each payment Association defines its chip products. The payment system specifications describe the basic rules for working with a product called a debit/credit chip card. This product is in the financial sense an ordinary Bank product-a card, in the technical sense, the magnetic technology has been replaced by a chip.
Visa offered its banks a subset of EMV specifications that contain some specificity, calling them VSDC (Visa Smart Debit Credit) specifications. A similar approach is used by Europay-MasterCard, which offered a “Lite” version of the m/Chip Lite specifications. The idea of payment systems is to gradually move towards full implementation of EMV specifications while simultaneously achieving an acceptable price for cards for issuers.
In addition to describing the properties of the main product, EMV specifications define application selection rules. Initially, the specifications were developed taking into account the possibility of issuers placing additional non-Bank applets on a single chip in addition to the payment application, which expand the functionality of cards. The card can host multiple applications, such as a debit and credit card and a wallet. In addition, “non-payment” applications are also allowed. Cards offered by manufacturers as early as the late 1990s and early 2000s made it possible to add other applications, such as loyalties, to the basic EMV application. The architecture of open platforms allows you to dynamically load additional applications while using the card. The client can not be limited to a specific set of applications, but download them as necessary.

This approach requires a lot of attention to the complexity and flexibility of the emission environment. The main role is given to the ability to dynamically manage parameters at the card, application, and even at the level of an individual client. All elements of the card and application management environment should be integrated with each other as much as possible to dynamically manage risk parameters based on solutions in a well-developed authorization system.

Especially interesting are the chips that use the principle of the so-called virtual machine to run applications developed on the basis of Java. The Java Card and Multos platforms implement the principle “developed once, works everywhere”, which distinguishes this principle from the development of customer-specific applications for a specific card from a specific manufacturer. Thus, the Issuer can choose from a variety of ready-made applications that its clients need and upload these applications to the card, without caring about the features of the card’s command system, rules for organizing its file system, etc.additional applications can be Downloaded while the client is using the card, for example, using a mobile phone equipped with the appropriate device.

Classification of products based on chip cards

Chip card products can be classified as follows:
debit/credit cards;
pre-authorized cards;
electronic cash.
Debit / credit chip cards are ordinary debit or credit cards that contain a chip. Unlike cards with a magnetic stripe, they have additional identification (authentication) data, configuration parameters that do not allow copying, which allows you to fundamentally improve security, virtually eliminating the possibility of card forgery, as well as the efficiency of the operation. But the principle of performing the operation remains the same: online or offline authorization.

Unlike debit / credit cards, other products – pre-authorized cards, e-wallets, and cards that sell electronic cash-involve storing the amount of money on the card, so they are called Stored Value cards.

Pre-authorized cards

Chip cards, which became widespread in the first half of the 90s in numerous banking projects, implemented the idea of pre-authorized cards. As the main

due to their technological advantages, they provided authorization in offline mode, which significantly reduced the requirements for the quality and sometimes availability of communications.
The idea of pre-authorized cards is as follows. The amount of money deposited by the customer to the Bank is reflected on the card account, as well as on the card as the balance of available funds. When making transactions (purchases or receiving cash), the balance sufficiency is checked, and in case of a positive result of the check, the balance on the card is reduced by the amount of the completed operation. Information about transactions is stored in payment terminals and transmitted as transaction files to the card accounting system*(53), where card accounts are maintained. The card accounting system, receiving transactions for each card, reflects the operations performed on card accounts, bringing into line the balances on Bank card accounts and balances stored on cards.

In addition to the offline mode of transactions, another absolute advantage of pre-authorized cards is their security. The card allows the operation only after it checks the pin. Depending on whether the information presented to it is correct (in encrypted form) PIN, the card will continue performing the operation or stop it. This means, in particular, that if the card is lost, the cardholder will not lose their funds, since the PIN code is known only to them. After a certain period of time has passed since the card was lost, the Bank that issued the card and maintains the card account may issue the cardholder the balance on the account or reissue the card.

A high degree of security allowed the use of pre-authorized cards for writing large amounts on them and using this type of card, in particular, in salary projects.

Since 1993, more than a hundred projects based on chip cards have been implemented in Russia. Almost all of them supported the described mechanism of pre-authorized cards. The type of pre-authorized cards includes the most popular in Russia cards “Zolotaya Korona” and “sberkart”, as well as cards used in projects based on SmartPay and DUET (U. E. P. S) technologies. The details of the technology were different, but the main financial properties were exactly the same. As for the basic technological differences, the issue of authentication*(54) of the card deserves separate consideration.
in most projects, the payment terminal stored certain keys in the security module. It provided the card with a temporary (session) key to encrypt the exchange of information when performing operations with the card. The card formed the response using keys as stored ones
its secret zone, and the temporary key received from the terminal. The terminal decrypted the received response using the session key and compared it with the expected result. If the response received from the card matches the expected result, the card authentication was considered successful. The degree of security of such solutions was determined by the degree of security of terminals.

The project, whose technology became the basis for the Visa Horizon card (originally Visa COPAC), also became very popular. It used two cards for authentication: the customer and the seller, which exchanged encrypted data. Decryption of them inside the microprocessors allowed the cards to perform mutual verification. This interaction affected not only the authentication phase, but almost the entire operation. The payment terminal, which has two card readers, played the role of a transfer link between the two cards. From the point of view of security, this technology seems to be the most advanced, but during operation, there may be inconveniences associated with the constant need for the seller’s card to be present in the payment terminal. In the first implementations of this technology, it had another disadvantage: all transactions were placed on the merchant’s card, i.e. data on all transactions made on customers ‘ cards during the working day at this terminal, which limited the ability to use a single merchant’s card.

Assessing the practical experience of implementing smart projects, it should be noted that although reducing the card balance (the majority) are performed offline lending transaction cards, i.e., its replenishment by money, are still online. In many projects, devices that provide credit for balances stored on cards were the systems ‘ bottleneck. Salary projects were particularly affected by this: card balance replenishment operations were actually less than payment operations, but since lending operations were mass-scale (after payroll was credited to card accounts), they were a serious problem in a number of projects.


Chip cards that implement the e-wallet concept, as well as pre-authorized cards, also store the balance of available funds in the microprocessor. Before performing the operation, it is compared with the amount of the operation and, if the verification result is positive, it is reduced by the amount of the operation. In this case, the e-wallet and pre-authorized card are similar. Unlike e-wallet is that when you record the amount in the purse (usually happens in a Bank in the credit card) it is immediately debited from the card account of the card holder, whereas the cancellation amount from the account holder predvaritelnoe card is only available after obtaining a center calculation data of the transaction. In the case of an e-wallet, the amount debited from the card account is credited to a special consolidated account that reflects the total balance of all e – wallet cards (the so-called float account).

Information about completed transactions is saved in the terminal and transmitted to the card accounting system (possibly in a truncated form – only as the sum of all transactions). Further, the amount of transactions with wallet cards is debited from this consolidated account.
As a rule, an e – wallet card does not require entering a pin before performing an operation.

As with pre-authorized cards, the e-wallet operation is performed offline. Unlike pre-authorized cards, if the wallet card is lost, the amount recorded on it is lost for the cardholder (but not necessarily for the Bank). This is the similarity between an e – wallet card and a regular cash wallet.

The concept of e-wallets as a financial product implies a certain limit on the amount of funds stored in the wallet and its use for relatively small payments, which is typical for a normal wallet.

Payment associations Visa and MasterCard have made several attempts to implement e-wallets (Visa Cash, Proton, Geld Karte, etc.), but there were no generally accepted product solutions by the early 2000s.

Terminal commands

As for commands, the terminal sends the card a command consisting of a mandatory 4-byte header and a variable-length body. The command header includes: instruction class, instruction code, and 2 instruction parameters. The command body, if present, includes the length of the input string, the input string itself sent to the card, and the length of the output string expected from the card. The card returns a two-byte state word and, depending on the command received, a variable-length body.
The integrated Circuit Card Application Specification for Payment Systems is dedicated to the transaction execution process. Let’s look at the main steps of the transaction execution process.

First of all, the terminal selects the application. This action is prosaic, but it is a key point for ensuring application compatibility. The card with the application implemented on it must respond correctly to the application selection, and this will allow it to be considered compatible with the specifications.
After selecting the application, the terminal initializes the transaction, informing the card about the start of a new transaction and transmitting terminal information about it to the card. Then the terminal receives a profile and a pointer to file entries containing data from the card. The terminal then reads the specified linear file entries and extracts application data from them. Next, the terminal performs a number of actions in order to make a decision on this transaction: reject it in offline mode, continue execution in online mode, or accept it in offline mode. These actions are performed based on the requirements of the profile. Each of them can be considered as a check of some property, ending with the answer” Yes “or”no”.

Based on the analysis of the entire set of checks, the terminal will make a decision on how to perform the transaction. The described principle is the key point of the specifications. The decision on the method of performing the transaction, which is a search for a compromise between efficiency and cost (offline), on the one hand, and security (online), on the other hand, is made by the terminal (according to the settings of the acquirer) based on the instructions contained in the card profile (defined by the Issuer).
as the first” check ” of the card, the terminal authenticates it.
Authentication involves the use of public key cryptography and is based on the following idea. There is a trust center designated by payment associations (Certification Authority), which performs the signing of the Issuer’s public keys under conditions of the highest secrecy. Each terminal contains the corresponding public keys received from the trust center and allows you to recognize any true application on the card.

The specifications provide two authentication methods: static (the Issuer signs the same data) and dynamic (the card generates a signature of different data each time after the transaction is completed). In addition, it provides migration from one key to another and some specific decryption methods to others, although they have the same basis – the RSA algorithm.

After authentication, the terminal performs a number of checks to determine whether the application version number in the terminal matches the one on the card. It also checks restrictions on the geography recorded on the card, and the date (start) of the application and the expiration date of the card.
Then the cardholder is verified(46). The card may contain a CVM list(47) – a list of cardholder verification methods (rules). The terminal processes each rule in the order in which they appear in the list. Verification is completed when one of the methods is completed successfully or the list is exhausted. The processed rules are related to comparing the transaction amount with the values set as parameters. Depending on the result of this comparison, the terminal performs actions of the following type: “pin verification is performed by the card”; “encrypted PIN is checked online”; “pin verification is performed by card + signature” , etc. Offline pin verification is completed successfully only in one case – if the card returns a normal return code to the VERIFY command, which compares the pin entered by the cardholder and the pin stored on the card (strictly speaking, comparing PIN-related data, since it is assumed that the conversion of the entered pin is possible).

The terminal then performs so-called terminal risk management in order to protect the acquirer, Issuer, and payment system from fraud. It ensures that the Issuer authorizes high-value transactions and ensures that all cards are periodically connected online to protect against threats that may not be detected during offline processing. Terminal risk management includes:
checking the pre-authorized limit;
a random selection of transactions for online execution;
checking the frequency of online transactions.
Checking the limit is performed in almost the same way as when using magnetic cards. In addition to the limit value, the terminal stores the following parameters:
target percentage for random selection (0-99);
threshold for random selection (0 – preauthorization limit);
maximum target percentage (0-99).
The terminal calculates the so-called transaction percentage.
If the transaction amount is less than the threshold, its percentage is the same as the target. If the transaction amount is not less than the threshold, but less than the limit, its percentage is calculated using a random number.
The purpose of checking the frequency of online transactions is to allow the Issuer to set a limit on the number of consecutive offline transactions (Lower Consecutive Offline Limit). However, if the terminal is not able to perform transactions online, it is still possible to complete the transaction offline if the second limit*(48) is not reached. If the second limit is exceeded, a transaction that cannot be performed online is rejected by the Issuer. As soon as any online card transaction completes successfully, the offline transaction counter is reset.

Finally, the terminal performs an analysis of actions, making a decision on the choice of transaction mode: online/offline. This decision is made based on the analysis of all responses and the mask read in the profile. This ensures the influence of the Issuer (who wrote the mask on the card) on the decision-making and, consequently, on the risks when performing the transaction (something that previously depended entirely on the acquirer).

Further, if the terminal decides to perform a transaction in the offline mode, it asks a card counter transactions; if the decision on the transaction online, the terminal asks the card cryptogram is an authorization request.
This cryptogram is included in the authorization message and sent in accordance with the usual Protocol to the host computer. The latter can add to the transaction execution process a so – called script*(50), which in this case includes post-commands (sent by the acquirer or even the Issuer, if it participated in generating the response to the authorization request) – commands that are executed after all others before the transaction is completed directly.
It seems that the above brief description of the transaction execution process confirms the idea that the development of technology (in this case, the proposal in the specifications of a rather sophisticated transaction execution algorithm) is associated with finding the optimal balance between security and efficiency when choosing online/offline mode.