The direction of our company

EMV project

It is no secret that when making a decision on the implementation of a particular card project, banks focus on such points as the need for large investments in the modernization of acquiring infrastructure, the total cost of migration, as well as the possible impact of this process on the current business. And the process of switching to EMV is the most illustrative example in this case. Any serious mistakes at the initial stage of the EMV project lead to the need for serious re-investment, which is confirmed by the experience of countries that first introduced chip cards a few years ago. At the same time, as the example of a number of participants in both the global card market shows, these mistakes can and should be avoided today. It is no coincidence that in this article we will touch on such cornerstones as planning an EMV project as a whole from the point of view of the Bank itself, and also step by step consider the implementation of an EMV card operation in a terminal device.

EMV migration

Despite the fact that at the moment many banks have already started the process of switching to EMV, and some of them have been issuing and acquiring microprocessor cards for quite a long time, the issue of EMV migration is still very relevant. First, from January 1, 2006 in the semea region (Visa International), the transfer of liability for fraudulent transactions (liability shift) came into force. As a result, if earlier for some banks the volume of disputable transactions that could be “repelled” using the new chargeback rules remained a certain blurred value, now it should acquire a fairly clear and real outline.

Secondly, international payment systems continue to encourage their participants to increase the pace of the EMV migration process by releasing more advanced and universal versions of their payment applications, expanding the functionality of card products, developing programs to encourage EMV migration, which together makes microprocessor cards an increasingly attractive payment tool for banks that pay attention to new technologies. Also, you should not discount the image component. By introducing new payment technologies, the Bank confirms its image as an innovative and technologically advanced credit and financial institution. As a result, banks, each of which is guided in these matters by their own internal arguments and motivations, increasingly decide to migrate to EMV cards, moving from a wait-and-see position, similar to Shakespeare’s famous dilemma “To be or not to be”, to a purely “Chernyshev” formulation of the question – “What to do?” Indeed, they inevitably face questions: what is the action plan for implementing EMV? What steps should I take? What functionality should I choose? The list of potential issues can include both technical and procedural aspects, as well as business development aspects. This article aims to answer some of these questions.

Project approach

First of all, I would like to note that regardless of the future functionality of microprocessor cards, the desire of management or business development plans, the transition to EMV is a complex and complex task. Its implementation will require financial investments, time and effort from the Bank. This project will affect not only the card Department, but also the management of the organization, the Bank’s lawyers, the branch network, information technology specialists, etc. That is why to solve this complex problem with maximum efficiency, you should use the project approach, which is practiced in the market mainly by consulting companies with many years of practical experience in the world, and some large banks (often with foreign roots). It should be noted that the project approach has recently become more common and popular in the implementation of large-scale business tasks. Many organizations declare that they have long adopted it and are successfully using it. However, the introduction of a fully-fledged project approach requires abundant experience in this mode (otherwise its implementation may cause the rejection of the existing structure of the organization), availability of libraries of reusable design documentation and the actual team of qualified “project-oriented” professionals who already have real experience of implementation of such projects.

The essence of the project approach is to formalize the task as much as possible and clearly form a working group to solve it. When the task is formalized, the working group or project team is assigned one or more goals that the Bank seeks to achieve during the implementation of the project. Achieving these goals will mean its successful completion. At the same time, the goals should be stated with maximum accuracy. For example, a successful formalization of the project task can be considered “the Release of the first 1000 EMV Cards by 01.02.07” or” Obtaining certification in the payment system for ATM Smsequiring by 20.05.06 and the subsequent transfer of the entire ATM network of the Bank to service EMV cards for 6 months”. If the project team is given an ambiguous goal (such as” Migrate to EMV as soon as possible”), then it is more than likely that the project will produce equally ambiguous results.

The project team is headed by the project Manager, who is responsible for coordinating the work on the project and for timely completion of tasks. Moreover, it is not necessary for the project Manager to be a ” luminary of the card business”, rather, he must have extensive skills in organizing business processes. In addition to the project Manager, the project team is recommended to include experts in various areas of retail banking, as well as a business analyst who will be responsible for specific tasks within the framework of working on the project. Work on the project should involve experts in the field of host systems, information security and cryptography, marketing, etc. As an example, the fact that, for example, the Visa International documentation lists about 10 functional roles (roles) that are recommended to be implemented within the project team. In order to organize the effective work of the project team, special attention should also be paid to the issues of data exchange and project supervision. First, team members must be in constant contact with each other. Of course, it is difficult to allocate Bank employees to work on a project (even on such an important one as EMV migration) on a permanent basis. Therefore, for effective exchange of information between the project participants should at least hold weekly meetings, which will be summed up the work on the project for the week, planned work for the future and discuss “hot” issues.

Secondly, for effective work on the project, the working group members must clearly understand who is the “Customer of the project” (often the term “Customer” is used to refer to it, although the project terminology used by different companies may differ). It is this top Manager who will evaluate the success of work on the project, acting as an arbitrator in resolving disputes between team members. For obvious reasons, the ” customer” should be one of the Bank’s managers who has at least a clear understanding of the main aspects of the card business and retail banking. After formalizing the project goal, it is necessary to start developing a detailed project implementation plan, which should take into account the totality of internal Bank activities and interaction with external organizations and payment systems. As an example, to develop such a business plan you can use the certification plan is obtained from the office of the payment system. It necessarily reflects the main stages of the project from the point of view of the payment system and the dates of the tests. Although such a plan does not include a wide range of internal operations and activities that will be carried out by the Bank during the implementation of the project, it gives a fairly complete picture of the time frame of the project – from the moment it is opened in the payment system until the first EMV operation is confirmed or BIN is activated. In other words, the project plan of the payment system can serve as a convenient ” template” for creating your own unified project plan of the Bank.

Stage of the project

Ideally, the project plan should describe all the Bank’s activities for the implementation of the project, from the moment of formation of the working group to the closure of the project in connection with the achievement of the goal. Of course, in practice, at the planning stage, it is extremely difficult or even almost impossible to foresee the entire scope of project work. Therefore, it is absolutely acceptable to make adjustments to the already created project plan, add new stages of the project and change the insignificant deadlines for the implementation of individual tasks within it. However, such adjustments should necessarily be agreed with the “customer”.

The stages of implementation of the EMV project, of course, depend on its goals and the current readiness of the Bank to switch to EMV. Therefore, at the stage of preliminary project planning, it is recommended to analyze in detail the current state of the Bank’s processing system, its terminal fleet, etc. For example, it is likely that the functionality of the host software solution used by the Bank initially includes the possibility of partial or full support for working with EMV cards. In this case, it is necessary to analyze how the functionality of the host system corresponds to the goals of this project, and based on this, make appropriate measures to finalize or update the processing SOFTWARE in the plan. Similarly, when analyzing the current state of the POS terminal fleet, it should be taken into account that most modern terminal devices initially meet the requirements of EMVCo Level-1, which guarantees their technical readiness to accept EMV cards. In the case of devices installed several years ago, it is necessary to ask manufacturers about the timing and cost of completing the terminals with the necessary modules. However, any EMV project will have a set of common stages.

So, almost every issue project will include the following stages::

• preliminary works;
• formation of business requirements for the card product, on the basis of which the technical description is formed;
• selecting a card provider;
• managing cryptographic keys;
• development of the risk management policy of the card;
• choosing a personalisation office or preparing your own personalisation centre;
• preparation of the processing system;
• certification of cards in the payment system;
• marketing support;
• pilot project;
• completion of the project: reaching the planned volumes of EMV card issuance and gradual adaptation of the POS-terminal network. Preparing updates. What you need to consider after the project is closed (for example, regular key update procedures).

On the other hand, all acquiring projects also have common stages:

• preliminary works;
• formation of requirements;
• choosing a terminal software supplier and upgrading equipment;
• managing cryptographic keys;
• development of the terminal’s risk management policy;
• preparation of the processing system;
• certification in the payment system;
• marketing support – work with trade and service companies;
• training of employees of the Bank and trade and service enterprises;
• pilot project;

Acquiring projects are often considered relatively simpler than issuing projects. However, it is not always possible to agree with this. Especially in cases where the project goal includes the migration of the entire terminal network of the Bank to accept EMV cards. In addition, when implementing an acquiring project, payment systems require the Bank to pass a much wider list of certification tests compared to the issue project.

For example, when certifying for acquiring in Visa International, the Bank must pass end-to-end testing, which confirms the possibility of correctly sending chip transaction data from the Bank’s host to the Visa test environment, as well as ADVT testing (Acquirer Device Validation Tool), which confirms the ability of the terminal to work with various EMV card profiles. As for test capabilities, international payment systems are ready to provide banks with a large package of test tools, starting with test cards and ending with systems for preparing personalized data. And often, to get access to these resources, it is enough to send a corresponding request to the project Manager from the payment system. The main thing is not to “play around” with test tools and remember that working in “combat” mode in any case has its own characteristics that must be initially taken into account.

Of course, the Bank must separately pass certification measures for ATM and merchant acquiring, as well as for Manual Cash operations (cash withdrawal at the cash desks of Bank branches using a POS terminal). End-to-end testing can take place according to a simplified (confort) or complete scheme. The simplified scheme is relevant primarily for those cases when the Bank uses the services of a third-party processing center, which is already certified by the payment system for servicing EMV cards. At the same time, all these measures are designed to guarantee the Bank’s full readiness to service smart card products.

For comparison: when certifying for the issue of EMV cards in the same payment system, the Bank must conduct an analog of end-to-end testing, confirming the readiness of the Bank’s host to process authorization requests containing chip data, and send the EMV card for certification to the office of the payment system, where it checks the correctness of card personalization. It should be noted that at the same time, international banks participating in Visa International are obviously in a better position, since the Moscow office of the payment system has a team of specialists who independently certify cards without involving the regional London office, which obviously saves time for the project implementation.

The only really fundamental feature of the implementation of emission projects in comparison with acquiring projects is the need for detailed study of key material management issues (key management). As part of the issue project, the Bank has to independently issue a fairly large number of cryptographic keys, certify public keys in the payment system, etc. In the acquiring project, the Bank will only need to work out the issue of uploading payment system certificates to the terminal and then updating them. Therefore, from the point of view of difficulty and complexity of acquiring and issuing projects are relatively similar. Although today it is de facto accepted to start migration to EMV with certification for acquiring smart cards.

As for the timing of the implementation of the EMV Project, this indicator largely depends primarily on the current state of the processing system and the Bank’s terminal network. For example, purchasing, installing, and testing a host system update may take several months. The same can be said about the terminal SOFTWARE, although often the Bank can get support from the manufacturer in this matter up to the preparation of the terminal platform for testing and downloading test certificates of the payment system by the service Department of the supplier company. However, there are minimum time frames for the implementation of the EMV project, which are set by the terms of passing the mandatory certification procedures of payment systems (we will return to this issue in more detail later). For example, certification of public Issuer keys in Visa Certification Authority takes about 1.5 months.

For a preliminary assessment of the project implementation period, it is also extremely useful to look at the certification plan of the payment system, which will clearly demonstrate the minimum terms of certification and the Bank’s passing of certification procedures. Based on the practice and experience of banks, the average project implementation period, which includes certification for issuing and acquiring EMV cards in one payment system, is about 1.5 years. Effective planning and use of outsourcing companies ‘ services (third-party personalization and processing centers) can reduce this time, and Vice versa.

Business requirements as a cornerstone

When formalizing requirements, it is important to follow the order: business requirements are the basis for the technical description, and not Vice versa. It should be understood that the transition to EMV can significantly narrow or expand the functionality of cards as a payment instrument. For example, an EMV card can independently carry out risk monitoring of transactions, make a decision about their conduct in off-line or on-line, update offline counters, etc. This is also true for terminal equipment. Therefore, at the stage of requirements formation, each of the Bank’s business units must clearly determine which card product it wants to see at the output. In the end, these specialists will have to sell the created service, earn a profit and thereby pay for the cost of implementing this product. It is also fair to note that business representatives rarely have a complete understanding of the potential functionality of smart cards and their opportunities for business development. It is for the formation of requirements in the project team that it is necessary to include both representatives of business units and” card holders ” who to some extent have competence and knowledge in the field of EMV-card functionality.

EMV transaction: 12 stages

So, having decided on the main aspects of planning an EMV project, we will proceed to consider its technological components, starting with such a defining moment as the features of an EMV transaction. First of all, you should step-by-step consider the passage of a normal operation on an EMV card in a POS terminal adapted for receiving chip cards. This will allow, first, to get a more detailed idea of the procedures and information exchange that occurs between the card, terminal equipment and processing system, and secondly, to form the necessary basis for further analysis of perhaps the most complex aspect of EMV migration-building a key material management procedure. In addition, focusing on the technology of operations with chip cards as such allows us to clarify such an important issue as the potential of a smart card in terms of expanding its functionality compared to traditional cards using magnetic stripe technology. Speaking about the additional functionality of chip cards, in most cases they mean first of all various additional applications that can be placed in the memory of its microprocessor in addition to the main payment applet. However, we should not forget that thanks to the EMV standard itself, any EMV Card with minimal configurations initially has a wide functional potential, which is used during each operation.

When describing an EMV transaction, this article will use the available official documents of EMVCo, which can be found in detail on the website of this organization (www.emvco. com), as well as the corresponding open documentation of Visa International. It should be noted that the EMVCo documentation serves as a set of General guidelines and rules. On their basis, private rules were created in the field of visa International and MasterCard International chip cards, which bear the common names VIS (Visa Integrative Circuit Card) and M/Chip, respectively. This explains the fact that there are so few fundamental differences between the EMV rules of these international payment systems. So, despite the fact that for the card user, the operation on it takes a few seconds (although, of course, an observant user will easily notice an increase in the operation time by a couple of seconds in the case of using a smart card), a standard EMV transaction has the following 12 stages:

1. Application selection;

2. Initialization processing of the application;

3. Reading application data;

4. Offline authentication;

5. The constraint processing;

6. Checking the cardholder;

7. Risk management on the terminal side;

8. Action analysis terminal;

9. Risk management on the card side;

10. Analysis of card actions;

11. Processing in on-line mode (this stage takes place only if the operation for some reason could not be carried out in offline mode);

12. Completion of the operation. We will analyze each of these stages and consider in detail its most important points.

1. Application selection

As follows from the definition, at this stage, the card and the terminal (POS-terminal, ATM, payment and information terminal, etc.) jointly select the application for which the operation will be performed. In the terminal settings, there is a list of card applications that it can work with. In addition to the basic Visa International and MasterCard International applications – VSDC and M/Chip-it can also contain other applets, such as, for example, loyalty programs, bonus or identification applications. A special memory area of the card contains a list of all applications that are loaded on it.

It should be noted here that all EMV Cards have a common structure for storing information. For example, the list of applications should be stored in a specific area of the card file structure. This makes it possible to use the cards in any terminal that meets the requirements of EMV. To select an application, so – called application Identification codes (Application Identifier-AID) are used. Any application written to the memory of the EMV card must receive a special ISO identification number. Even if a particular Bank wants to release its own application that is only available to its customers, it will still have to go through the procedure of obtaining AID. AID is recorded in the card’s memory at the personalization stage and installed in POS terminals. AID consists of two elements:

* Registered application identifier (RID), which corresponds to a specific payment system or, for example, the issuing organization of the local application;

• The product identifier Extension (PIX) that corresponds to the card product type.

For example, Visa International cards are assigned the RID A000000003, as well as two PIX codes: – “2010 “ – for Visa Electron cards, and” 1010” – for all other card products of the payment system. Thus, the AID of the Visa Classic card will look like this: A0000000031010. When the EMV card is placed in the terminal, the AID in the card’s memory and in the device’s memory are compared. This is how the application is selected for the operation.

If the card and terminal contain a number of common applications (e.g. VSDC and loyalty app Petrol Check), the terminal displays on the screen a list of all shared applications and prompt the cardholder to select the application that will be a transaction (see Fig. 1). At the same time, when planning EMVпроекта specialist Bank, responsible for development of POS terminal network should take note that not all POS terminals support the option of selecting the app. In this case, the application with the highest priority Indicator (API) will be selected for the operation, which is set by the Issuer when the card is personalized. Usually, the Issuer chooses the payment application that is given the highest priority by default.

Finally, if the card and the terminal do not have common applications, the operation will be automatically canceled by the terminal, and the card will be returned to the client.

2. Initialization processing of the application

At this stage, the terminal informs the card that it is ready to start a transaction. In response, the card must perform the following two operations.

* Checking the so-called geographical restrictions on the operation. The card checks the region in which the operation takes place by requesting the appropriate data from the terminal (Terminal Country Code). Next, the card compares the received data with the information recorded in its memory (Card Country Code). This operation allows the Issuer to insure against the use of its cards in certain regions of the world (for example, with the highest rates of fraud). In addition, the Bank may restrict the use of the card issued by it within the international payment system only within the country (local card products), as, for example, in the case of some MasterCard Electronic cards, or restrict the conduct of certain operations on it in this country (for example, allow the card to carry out only cash withdrawal operations). Obviously, payment systems have implemented this operation in order to provide issuers with the opportunity to apply existing online risk management methods (refusal to authorize transactions initiated in a certain region of the world) when conducting offline operations. At this stage, the transaction can be canceled at the initiative of the card, if this type of operation is prohibited in this country of the world. This operation is optional, and the Issuer can refuse to perform it by using special settings when personalizing the card.

* The card sends the application Interchange profile (AIP) to the terminal. This operation is mandatory for all EMV applications. The card transmits to the terminal a set of specially structured information containing a description of the functionality of the card and the application that was selected for the operation. This data is formatted in the display of TVL (Tag, Value, Length). It should be noted that for all the apparent openness of data exchange between the card and the terminal, there is information that is never transmitted by the card to the terminal. This is primarily the value of the PIN code and secret keys recorded in a special memory area of the card chip.

3. Reading application data

At this stage, the card transmits to the terminal the data necessary for conducting the transaction (using AIP data), and the information used at the offline authentication stage.

4. Offline authentication

Based on the AIP, the terminal determines the types of offline authentication that the card supports. As you know, there are three types of offline authentication – static (Static Data Authentication – SDA), dynamic (Dynamic Data Authentication – DDA) and combined (Combined Data Authentication – CDA). Currently, SDA cards continue to prevail in the global market, but more and more banks are beginning to prefer DDA as a more secure authentication technology. In turn, CDA, which combines the properties of DDA and SDA, with all its advantages, is still an extremely rare authentication technology today. It should be noted that not all terminals support the use of DDA. This is due to the fact that cryptographic operations performed during the DDA procedure require additional processing capacities from the terminal, which are not available in outdated models. That is why the use of SDA is still mandatory for EMV card issuers. Thus, even if the Bank intends to issue cards with more secure DDA technology, it will also have to provide support for the SDA card. All of these authentication methods work offline without accessing the host of the issuing Bank or acquirer and are based on asymmetric key technology.

We will return to the features of SDA and DDA in more detail in a separate article in one of the next issues of the magazine “PLAS”, dedicated to the management of key material. Now we will focus on the General aspects of the authentication procedure. Both SDA and DDA use Certified public keys of the payment system (Payment System Certificate) loaded into the terminal device (the so-called EMV library), as well as public cryptographic keys recorded on the card (in the case of SDA) or generated by the card specifically for each operation (in the case of DDA). As a result of offline authentication, the acquirer must verify that the card belongs to a certain Issuer and that the data on the card has not been changed after its personalization. The disadvantage of SDA is that the card uses the same cryptographic value to perform authentication throughout the life of the card. In fact, SDA is not much different from the CVV (Card Verification Value) technology used on magnetic stripe cards. In contrast, DDA cards generate a unique cryptographic value for each operation, and use a unique 3DES key for each card, stored in a protected area of its memory.

Based on the results of authentication, the terminal records its result (Terminal Verification Result-TVR) in a special report. Thus, failure to complete offline authentication does not mean that the transaction is completed. It should also be noted that for terminals that maintain constant online communication with the Bank’s host (for example, ATM), offline authentication is not required. If authorization in any case will take place online, then the meaning of offline authorization simply disappears.

5. The constraint processing

At this stage, the terminal performs a series of checks of the card, confirming its suitability for performing the operation. In particular, the terminal checks the validity period of the card, the possibility of using the card to perform this type of operation, as well as the version of the application. To check the validity of the card, a special parameter stored in the card’s memory is used – the application expiration Date. In some cases, the Issuer can set an additional parameter for the application’s lifetime-Application Effective Date. The last parameter is optional and may differ from the Application Expiration Date. For example, the Issuer may provide its client with the opportunity to use the card during its reissue due to the expiration of its validity period. In this case, the Application Effective Date period will be longer than the Application Expiration Date. The terminal also checks the application version. The memory of the card and each terminal contains the versions of the applications they support. The terminal checks the data about the application recorded in the card’s memory with its own data. The results of operations performed at this stage are also recorded in the TVR report. Based on the results Of processing restrictions, the transaction cannot be canceled, even if, for example, the application has expired.

6. Checking the cardholder

This stage is the usual stage of identification of the cardholder. Historically, the two most popular and widespread methods of cardholder identification (Cardholder verification method – CVM) – verification of the signature on the card and on the terminal receipt, as well as entering a PIN code. In some countries, other CVM methods have become common, for example, checking the PIN code in offline mode when conducting operations in POS terminals. Therefore, most EMV cards support several CVM methods, which means that the terminal and the card will again have to choose the appropriate option. The principle of choosing a CVM is similar to choosing an application. The EMV card stores the CVM list specified by the card Issuer at the stage of its personalization. This list is passed to the terminal at this stage of the operation. The terminal compares it with its own list set by the acquirer, based on its own risk management policy. Also, the Issuer must set priorities for each CVM method, so that the terminal can automatically choose the best option if several methods match in the card and terminal lists (see figure 2).

If, as a result of comparing the CVM lists, the preference was given to checking the PIN code, the terminal will automatically prompt the cardholder to enter the PIN code. It should be noted that there are three types of PIN verification for EMV cards:

• in on-line mode (similar to magnetic stripe cards);

• in off-line mode, when the pin Code is stored on the card in an open (unencrypted) form – Offline plaintext PIN. In this case, after entering the PIN code, its value is transmitted to the card for comparison with the PIN value stored in the protected area of the card in unencrypted form;

• in off-line mode, when the pin Code is stored on the card in a closed (unencrypted) form – Offline encrypted PIN. In this case, the card must manipulate the encrypted data to verify the transmitted PIN value. If you go deeper into the analysis of the EMV specifications, you will find that the CVM list can also specify the conditions under which the use of certain CVM methods becomes available (for example, the preferred introduction of a PIN code for cash withdrawal operations), as well as specify the actions of the terminal in case of unsuccessful verification of the cardholder (the terminal may try to perform an operation with another CVM, etc.). in Other words, the Issuer and acquirer have more tools for setting up verification of the buyer’s identity in offline mode.

7. risk management on the terminal side

At this stage, the terminal performs an internal check of the transaction parameters, based on the risk management settings of the acquiring Bank. The terminal performs the following tests:

* The terminal can select a transaction to conduct online. In the settings of a terminal capable of accepting EMV cards, a random algorithm for selecting transactions for conducting them online can be set. As you might guess, this is an additional way to combat card fraudsters who expect that the operation will be carried out without contacting the host of the issuing Bank. The arbitrary nature of choosing an operation to send to on-line does not allow fraudsters to prepare in advance for such a decision of the terminal.

* Check the hot-list (list of stolen or lost cards). This check is similar to a similar step when performing an operation with a magnetic stripe card. During this check, the terminal checks the card number against the entries in the list of “problem” cards. Most terminals support working with several hotlists at the same time (for example, with newsletters of various payment systems).

* Check for exceeding the transaction limit. This operation is also similar to checking the floor-limit when using a “magnetic” card.

It is important to remember that the operation can not be canceled because it for some reason did not pass verification at this stage. The results of the checks are recorded in the TVR.

8. Action analysis terminal

At this stage, the terminal analyzes the results of the previous transaction steps recorded in the TVR, as well as the parameters of the operation set by the Issuer in the special fields of the chip memory, and the acquirer – in the terminal settings. Based on the results of the analysis, the terminal decides whether to perform the operation in on-line mode, allow it to be performed in offline mode (off-line) or reject (cancel) the operation (decline). In particular, at this stage, the terminal performs the following actions:

* analyzes the results of offline processing of transactions that have been made so far. In the memory of the terminal and the card, there is a special list in which possible actions for performing the operation are prescribed, based on the results recorded in the TVR. These lists are called Terminal Action Codes (TAC) and Issuer Action Codes (IAC) – for the terminal and for the card, respectively. By analyzing the TVR and taking into account the TAC and IAC, the terminal makes a decision about the future of the transaction;

* next, the terminal sends its decision to the card, requesting a special cryptogram from it. In other words, the terminal seems to ask the card: “I have analyzed the parameters of the operation and I think that we need to conduct it online. What’s your opinion?” In response to this request, the card must submit to the terminal “its vision” of the further operation.

Thus, the party of the acquiring Bank represented by the terminal cannot” single-handedly ” refuse to conduct the transaction due to the fact that it does not meet the internal criteria of the terminal. This is a fundamental advantage and feature of EMV technology: all participants in the transaction have enough tools to analyze the riskiness of the operation in offline mode. But no party can” single-handedly ” decide the fate of a transaction – reject it without taking into account the opinion of the other party, or, on the contrary, conduct it despite the warnings of the opponent.

9. Risk management on the card side

At this stage, the transaction is verified according to the risk management criteria on the Issuer’s side. As a result, the Issuer’s card forms a response cryptogram to the terminal. There are several basic operations for the EMV standard that the card performs during this check:

* Checking the newly issued card (New Card Check). The Issuer has the ability to set the risk management parameters of the card in such a way that when performing the first operation in its life cycle, the card must necessarily contact the Bank’s host (i.e., perform the operation in on-line mode). This allows the Issuer to record the fact that the cardholder has started using the card.

* Checking the transaction history (Previous Transaction Check). Using a special mechanism in the payment application, the card analyzes past transactions for any unusual situations (for example, an unsuccessful pin Code entry or the inability to perform offline authentication).

• Checking of counters (counters). The card checks the status of various offline counters set by the Issuer. These counters may include: the allowed number of offline operations, the maximum amount of offline operations, the number of attempts to enter a PIN code, and so on.

10. Analysis of card actions

At this stage, the card completes the risk management procedures and forms a response cryptogram to the terminal. In other words, the card “expresses its opinion” about the terminal’s offer to perform the operation online. There are three types of response cryptograms (according to the VIS specification):

* Transaction Certificate (TC) – performing the operation in off-line mode. It is a clearing message for settlement, which can be used for chargeback. It contains all the main results of the offline operation-TVR and the cardholder verification results (CVR) Report. TC is also generated by the card in response to a positive response from the Bank’s host when conducting an online transaction. In this case, the TC provides the terminal with the final data about the operation for further use in the analysis of disputed transactions.

* Application Authentication Cryptogram – AAC) – cancel the operation in offline mode. Is generated in the case of the “consent” card to cancel the transaction or in the event of a negative response to the host Bank. * Authorization request cryptogram – ARQC) – request for an online transaction. It is sent to the Bank’s host in the form of a standard authorization message (for example, for VisaNet-message “0100” or “0200”). For ease of understanding, the dialog between the card and the terminal can be presented in the following table (see figure 3). As a result of the formation of a particular cryptogram, the further fate of the operation is decided – it can be canceled, sent for authorization to the Bank’s host or carried out offline. In case of cancellation or confirmation in off-line, the transaction process automatically moves to the 12th stage, which we will consider in order of priority.

11. Processing in on-line mode

If the card and the terminal have come to a mutual decision to send the operation for processing to the issuing Bank’s processing, the card forms an ARQC cryptogram, and the terminal sends it in an authorization message along with the operation data. Currently, Visa International and MasterCard International have agreed to use a single format for sending chip data for processing. Transactional data specific to EMV is forwarded to the” 3 bit map” of the standard authorization message (a special message area for authorization of the operation).

After receiving the cryptogram, the Bank’s host processes it using a special set of keys (MDK). Then the Bank can perform several operations:

* confirm the correctness of the cryptogram, which guarantees protection against card forgery. The fact is that the key with which the card signs the cryptogram is located in a protected area of the chip, inaccessible to hacking scammers (if you do not believe the various rumors and profanations that are periodically spread in this regard). Thus, the host verifies the cryptogram signature with its master key and confirms its validity;

* check the results of an offline operation (offline authentication, PIN verification, etc.);

* generate a response cryptogram of the authorization response cryptogram (ARPC) host, which will allow the card to verify the identity of the Issuer and make sure that the authorization response came really from the Bank host;

* create a script to update offline counters or to execute another command by the card-up to the automatic blocking of the application. As a result of the analysis of the received data, the Issuer’s host generates a standard authorization response containing the necessary set of chip data.

12. The completion of the operation

This is the final stage of the transaction, which differs depending on what kind of joint decision the card and the terminal came to during the previous stages.

• If the operation was performed offline, the card generates a TC cryptogram and sends it to the terminal. The terminal, in turn, sends a standard message to the host of the acquiring Bank. The operation is considered successful.

• If the transaction was canceled offline, the data about it in the form of AAC is sent to the Issuer.

• If the transaction was sent for online processing, when receiving a response from the host of the issuing Bank, the terminal transmits the necessary data (ARPC or script) to the card. After that, the card confirms the correctness of ARPC using its cryptographic keys (UDK), processes the script command and generates the corresponding cryptogram-TC in case of a positive response from the host, and AAC – in case of a negative one. Accordingly, the transaction is considered successfully completed or canceled.