Brother
Professional
- Messages
- 2,590
- Reaction score
- 532
- Points
- 113
With this article devoted to a detailed analysis of the practical aspects of the implementation of an EMV project, the PLUS magazine opens a new section - Expert's View, which, we hope, will become a kind of open platform for the exchange of practical experience between our readers - representatives of the banking community, companies - vendors and payment system specialists. As you know, there is a wide range of practical aspects in the card business, for each of which many specialists can act as experts, telling their colleagues a lot of interesting things. At the same time, it is obvious that each bank, when faced with one or another of these practical issues, solves them in different ways. How to solve them correctly and effectively - this is what our new section is devoted to.
Why did we decide to start with the EMV migration aspects? It's no secret that when deciding on the implementation of a particular card project, banks focus on such issues 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 transition to EMV is in this case the most illustrative example. Any serious mistakes at the initial stage of an EMV project lead to the need for serious re-investments, which is confirmed by the experience of countries that first introduced chip cards a few years ago. At the same time, as evidenced by the example of a number of participants in both the world and the Russian card market, these mistakes can and should be avoided today.
The editorial board of the magazine "PLUS"
EMV migration: from Shakespeare to Chernyshevsky
Despite the fact that at the moment many Russian banks have already begun the process of transition to EMV, and some of them have been issuing and acquiring services for microprocessor cards for a long time, the issue of EMV migration is still very relevant ... First, since January 1, 2006. in the CEMEA region (Visa International), a liability shift has come into force. As a result, if earlier for some banks the volume of dispute transactions that could be “recaptured” using the new rules for conducting chargeback remained a certain blurred amount, now it should acquire a fairly clear and realistic outline.
Secondly, international payment systems continue to stimulate 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 more and more attractive. payment instrument for banks paying attention to new technologies. Also, one 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 organization. As a result, banks, each of which is guided in these matters by their own, internal reasons and motivations, increasingly decide to migrate to EMV cards, moving from a wait and see attitude, similar to the well-known Shakespearean dilemma "To be or not to be", to a purely "Chernyshev's" formulation of the question - "What is to be done?" Indeed, the questions inevitably arise before them: what is the action plan for the implementation of EMV? What steps should be taken? Which functionality should you choose? The list of potential questions can include both technical, procedural and business development aspects. This article is intended 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 wishes of the management or business development plans, the transition to EMV is a complex and difficult task. Its implementation will require financial investments from the bank, time and effort. 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 task with maximum efficiency, one should use the project approach, which is practiced in the Russian market, mainly by consulting companies with many years of practical experience in Russia, and by some large banks (often with foreign roots). It should be noted, that the project approach has recently become more and more common and popular in the implementation of large-scale business tasks. Many organizations declare that they have adopted it for a long time and are using it successfully. However, the introduction of a truly full-fledged project approach requires from the company a sufficiently rich experience of working in this mode (otherwise its implementation may cause rejection of the existing structure of the organization), the presence of a library of universal project documentation and a team of qualified "project-oriented" specialists who already have real implementation experience this kind of projects.
The essence of the project approach is the maximum formalization of the task and the clear formation of a working group for its solution. When formalizing a task, one or several goals are set before the working group or project team, which the bank seeks to achieve during the implementation of the project. The achievement of these goals will mean its successful completion. In this case, the goals should be set out with maximum accuracy. For example, “Issuance of the first 1000 EMV cards by 01.02.07” or “Obtaining certification in the payment system for ATM SMS acquiring by 20.05.06 and subsequent transfer of the entire ATM network of the bank to servicing EMV cards within 6 months” can be considered a successful formalization of the project's task. If, however, an ambiguous goal is set for the project team (such as: “Migrate to EMV as soon as possible”), then it is more than likely that
At the head of the project team is a project manager who is responsible for coordinating project work and completing tasks on time. 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, it is recommended that the project team include experts in various areas of the retail banking business, as well as a business analyst who will be responsible for specific tasks within the framework of the project. Specialists in the field of host system, information security and cryptography, marketing, etc. should also be involved in the work on the project. An example is the fact that, for example, the Visa International documentation lists about 10 functional roles, which are recommended to be implemented within the project team. To organize the effective work of the project team, special attention should also be paid to the issues of data exchange and supervision of work on the project. First, team members must be in constant contact with each other. Undoubtedly, the allocation of bank employees for permanent work on a project (even on such an important one as EMV migration) seems to be difficult. Therefore, for an effective exchange of information between the project participants, it is necessary at least to hold weekly meetings, at which the results of the work on the project for the week will be summed up, the work for the future will be planned and “hot” issues will be discussed. To organize the effective work of the project team, special attention should also be paid to the issues of data exchange and supervision of work on the project. First, team members must be in constant contact with each other. Undoubtedly, the allocation of bank employees for permanent work on a project (even on such an important one as EMV migration) seems to be difficult. Therefore, for an effective exchange of information between the project participants, it is necessary at least to hold weekly meetings, at which the results of the work on the project for the week will be summed up, the work for the future will be planned and “hot” issues will be discussed. To organize the effective work of the project team, special attention should also be paid to the issues of data exchange and supervision of work on the project. First, team members must be in constant contact with each other. Undoubtedly, the allocation of bank employees for permanent work on a project (even on such an important one as EMV migration) seems to be difficult. Therefore, for an effective exchange of information between the project participants, it is necessary at least to hold weekly meetings, at which the results of the work on the project for the week will be summed up, the work for the future will be planned and “hot” issues will be discussed. like EMV migration) seems difficult. Therefore, for an effective exchange of information between the project participants, it is necessary at least to hold weekly meetings, at which the results of the work on the project for the week will be summed up, the work for the future will be planned and “hot” issues will be discussed. like EMV migration) seems difficult. Therefore, for an effective exchange of information between the project participants, it is necessary at least to hold weekly meetings, at which the results of the work on the project for the week will be summed up, the work for the future will be planned and “hot” issues will be discussed.
Secondly, for effective work on a project, the team members must clearly understand who the “Customer of the project” is (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 the project, acting as an arbiter in resolving disputes between team members. For obvious reasons, the “customer” should be one of the bank's leaders who has at least a clear understanding of the main aspects of the card business and retail banking. After formalizing the goal of the project, you should begin to develop a detailed plan for the implementation of the project, in which it is necessary to take into account the totality of intrabank activities and interactions with external organizations and payment systems. As an example, to develop such a business plan, you can use a certification plan obtained from a payment system office. It necessarily reflects the main stages of the project in terms of the payment system and the date of the tests. Although such a plan does not include a wide range of internal operations and activities to be carried out by the bank during the project, it gives a fairly complete picture of the time frame of the project - from the moment it was opened in the payment system until the confirmation of the first EMV transaction or BIN activation. In other words,
Project stages
Ideally, the project plan should describe all the bank's activities in the implementation of the project, from the moment the working group is formed until the project is closed 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 design work. Therefore, it seems 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 its framework. However, such adjustments must be agreed with the “customer” without fail.
The stages of implementation of an 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 park, etc. For example, it is quite 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 to what extent the functionality of the host system corresponds to the goals of this project, and, based on this, introduce into the plan the appropriate measures for finalizing or updating the processing software. In the same way, when analyzing the current state of the POS-terminal park, one should take into account that the majority of modern terminal devices initially comply with the EMVCo Level-1 requirements, which guarantees their technical readiness to receive EMV cards. In the case of devices installed several years ago, it is necessary to ask the manufacturers about the timing and cost of completing the terminals with the necessary modules. However, any EMV project will have a set of common milestones.
So, almost every emission project will include the following stages:
• preliminary work;
• formation of business requirements for the card product, on the basis of which the technical description is formed;
• selection of a card provider;
• management of cryptographic keys;
• development of the card risk management policy;
• choosing a personalization bureau or preparing your own personalization center;
• 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 emission of EMV-cards and gradual adaptation of the POS-terminal network. Preparing updates. Things to consider after the project is closed (for example, regular key renewal procedures).
On the other hand, all acquiring projects also share common stages:
• preliminary work;
• formation of requirements;
• selection of a terminal software supplier and equipment modernization;
• management of cryptographic keys;
• development of the terminal risk management policy;
• preparation of the processing system;
• certification in the payment system;
• marketing support - work with trade and service enterprises;
• conducting training for employees of the bank and trade and service enterprises;
• pilot project;
• completion of the project: adaptation to the acceptance of EMV-cards of the required number of terminal devices or the entire acquiring network of the bank. It is also necessary to take into account the post-project stage - updating keys, procedures for working with new software, etc.
An acquiring project is often considered to be relatively simpler than an emission project. However, one cannot always agree with this. Especially in cases where the goal of the project 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 a bank to pass a much wider list of certification tests in comparison with an emission project.
So, for example, when certifying for acquiring at Visa International, the bank must pass end-to-end testing, which confirms the possibility of correct sending of 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 profiles of EMV-cards. With regard to test capabilities, international payment systems readily supply banks with a large package of test tools, from test cards to systems for preparing personalization data. Moreover, often in order to gain access to these resources, it is enough to send a corresponding request to the project manager from the side of the payment system. The main thing is not to play with test tools and remember that
Of course, the bank must separately undergo certification activities for ATM and merchant acquiring, as well as for Manual Cash operations (cash withdrawals at the cash desks of bank branches using a POS terminal). End-to-end testing can be carried out in 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 emission of EMV cards in the same payment system, the bank must conduct an analogue 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 payment office. systems where the correctness of card personalization is checked. It should be noted that at the same time, Russian banks participating in Visa International are in a clearly more advantageous position, since a team of specialists works in the Moscow office of the payment system, which independently certifies cards without involving a regional London office, which obviously saves time for the project.
The only really fundamental feature of the implementation of emission projects in comparison with acquiring is the need for a detailed study of key material management issues (key management). As part of the emission 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 loading the certificates of the payment system into the terminal and their subsequent renewal. Therefore, in terms of complexity and complexity, acquiring and issuance projects are relatively similar. Although today it is de facto customary to start migration to EMV with certification for acquiring smart cards.
As for the timing of the EMV project implementation, this indicator largely depends on the current state of the processing system and terminal network of the bank. For example, purchasing, installing, and testing a host system upgrade can take several months. The same can be said about the terminal software, although the bank can often get support from the manufacturer in this matter up to the preparation of the terminal platform for testing and loading test certificates of the payment system by the service department of the supplier company. However, there is a minimum time frame for the implementation of an EMV project, which is set by the time frame for passing the mandatory certification procedures of payment systems (we will return to this issue in more detail a little later). For example,
For a preliminary assessment of the project implementation period, it is again extremely useful to look at the certification plan of the payment system, which will clearly demonstrate the minimum terms of certification and the passage of certification procedures by the bank. Based on the practice and experience of Russian banks, the average project implementation period, including certification for the issue and acquiring of EMV cards in one payment system, is about 1.5 years. Effective planning and use of the services of outsourcing companies (third-party personalization and processing centers) can shorten this period, and vice versa.
Business requirements as a cornerstone
When formalizing requirements, it is important to maintain 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 on their conduct off-line or on-line, update offline counters, etc. This is also true for terminal equipment. Therefore, at the stage of forming the requirements, each of the business units of the bank must unambiguously determine what kind of card product it wants to see at the output. In the end, it is these specialists who will have to sell the created service, earn a profit and thereby recoup the costs of implementing this product. It will also be fair to note that business units rarely have a full 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 “cardholders” who, to one degree or another, have competence and knowledge in the field of EMV-cards functionality.
EMV transaction: 12 stages
So, having decided on the main aspects of planning an EMV project, let's move on to considering 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 with an EMV card in a POS terminal adapted to accept chip cards. This will allow, firstly, to get a more detailed understanding of the procedures and information exchange that occurs between the card, terminal equipment and the processing system, and secondly, to form the necessary basis for the subsequent analysis of perhaps the most complex aspect of EMV migration - construction of a key material management procedure. In addition, focusing on the technology of conducting transactions with chip cards as such makes it possible 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, it should not be forgotten 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. 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, it should not be forgotten 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. 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, it should not be forgotten 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 within the framework of this article, the available official EMVCo documents will be used, 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 chip cards Visa International and MasterCard International, which are collectively called 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 user of the card, the operation on it takes a matter of seconds (although, of course,
1. Application selection;
2. Initialization of application processing;
3. Reading application data;
4. Offline authentication;
5. Handling restrictions;
6. Verification of the cardholder;
7. Risk management on the side of the terminal;
8. Analysis of terminal actions;
9. Risk management on the side of the card;
10. Analysis of the actions of the card;
11. Online processing (this stage takes place only if the operation for some reason could not be carried out offline);
12. Completion of the operation. We will analyze each of the listed 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 on which the operation will be performed. In the terminal settings, there is a list of card applications with which it can work. In addition to the basic Visa International and MasterCard International applications - VSDC and M / Chip - it may also contain other applets, such as, for example, loyalty programs, bonus or identification applications. A special area of the memory card contains a list of all applications that are loaded on it.
It should be noted here that all EMV cards have a common information storage structure. For example, a list of applications should be stored in a specific area of the map file structure. This makes it possible to use the cards in any terminal that meets the EMV requirements. The so-called Application Identifier (AID) is used to select the application. Any application written to the memory of an EMV card must be assigned a specific ISO identification number. Even if a particular bank wants to release its own application, available only to its customers, it will still have to go through the procedure for obtaining an AID. AIDs are recorded in the card 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;
• Product Identifier Extension (PIX) code, which corresponds to the type of card product.
For example, Visa International cards are assigned 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 is checked in the memory of the card and in the memory of the device. This is how the application is selected for the operation.
If the card and the terminal contain several common applications (for example, VSDC and the Petrol Check loyalty application), the terminal will display a list of all common applications on the screen and prompt the cardholder to select the application through which the transaction will be processed (see Fig. 1). At the same time, when planning an EMV project, a bank specialist responsible for the development of a POS-terminal network should take into account that not all POS-terminals support the option of choosing an application. In this case, the application with the highest priority (Application Priority Indicator - API) will be selected for the operation, which is set by the issuer when personalizing the card. Typically, the issuer chooses the payment application, which is given the highest priority by default.
And finally, if the card and the terminal do not have common applications, then the operation will be automatically canceled by the terminal, and the card will be returned to the client.
2. Initializing application processing
At this stage, the terminal informs the card that it is ready to start a transaction. In response to this, the card must perform the following two operations.
• Checking the so-called geographic 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 their 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 certain transactions with it in this country (for example, allow 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 methods of risk management (refusal to authorize transactions initiated in a certain region of the world) when conducting offline transactions. 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 carry it out by using special settings when personalizing the card. 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 carry it out by using special settings when personalizing the card. 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 carry it out by using special settings when personalizing the card.
• The card sends the Application Interchange profile (AIP) to the terminal. This operation is required 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 into a TVL display (Tag, Value, Length). It should be noted that for all the seeming openness of data exchange between the card and the terminal, there is information that is never transmitted by the card to the terminal. First of all, this is the value of the PIN-code and secret keys recorded in a special area of the memory of the card's chip.
3. Reading application data
At this stage, the card transmits to the terminal the data necessary for the transaction (using the AIP data) and the information used during 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 dominate the global market, but more and more banks are starting 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 outdated models do not have. This is why the use of SDA is still mandatory for EMV card issuers. Thus, even if a bank intends to issue cards with safer DDA technology, it will also have to provide support for an SDA card. All of the above authentication methods work offline without contacting the host of the issuing bank or acquirer and are based on asymmetric key technology.
We will return in more detail to the features of SDA and DDA in a separate article in one of the next issues of the PLUS magazine, devoted to the management of key material. Now let's dwell on the consideration of the general aspects of the authentication procedure. Both SDA and DDA use the Payment System Certificate loaded into the terminal device (the so-called EMV library), as well as public cryptographic keys written to 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 make sure that the card belongs to a specific 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 for authentication throughout the card's life. In fact, SDA is not much different from the CVV (Card Verification Value) technology used on magnetic stripe cards. On the contrary, DDA cards generate a unique cryptographic value for each operation, use a 3DES key that is unique for each card, stored in a protected area of its memory.
Based on the results of the authentication, the terminal records its result (Terminal Verification Result - TVR) in a special report. Thus, failing offline authentication does not mean the end of the transaction. 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 occur online, then the meaning of offline authorization simply disappears.
5. Handling constraints
At this stage, the terminal carries out a series of checks on the card, confirming its suitability for the transaction. In particular, the terminal checks the validity period of the card, the ability to use the card for this type of operation, as well as the version of the application. To check the card expiration date, a special parameter stored in the card memory is used - Application Expiration Date. In some cases, the issuer can specify an additional parameter of the application life-time - Application Effective Date. The last parameter is optional and may differ from Application Expiration Date. For example, the issuer may provide its customer with the option to use the card during the period of its re-issue due to its expiration. In this case, the Application Effective Date period will be longer, than Application Expiration Date. The terminal also checks the version of the application. The memory of the card and each terminal contains the versions of the applications they support. The terminal compares the data about the application stored in the card memory with its own data. The results of the operations carried out at this stage are also recorded in the TVR report. As a result of Constraint Processing, the transaction cannot be canceled, even if, for example, the application has expired.
6. Cardholder verification
This stage is the usual stage of cardholder identification. Historically, the most popular and widespread are two methods of cardholder verification method (CVM) - verification of the signature on the card and on the terminal check, as well as entering the PIN code. In some countries, other CVM methods have become widespread, for example, offline PIN verification for transactions at POS terminals. Therefore, most EMV cards support several CVM methods, which means that the terminal and the card will have to choose the appropriate option again. The principle for selecting a CVM is similar to selecting an application. The EMV-card memory stores the CVM list specified by the card issuer at the stage of its personalization. This list is transmitted to the terminal at this stage of the operation. The terminal compares it to its list, specified 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 select the best option when several methods match in the card and terminal lists (see Fig. 2).
If, as a result of comparison of CVM lists, 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 cards with a magnetic stripe);
• 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 enciphered PIN. In this case, in order to verify the transmitted value of the PIN-code, the card must manipulate the encrypted data. If you delve deeper into the analysis of EMV specifications, you will find that in the CVM list you can also set the conditions under which the use of certain CVM methods becomes available (for example, the preferred entry of the PIN code for cash withdrawal operations), as well as set the terminal actions in the event 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 to set up offline customer verification.
7.Risk management on the terminal side
At this stage, the terminal carries out 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 it 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 rely on the fact that the transaction will be carried out without contacting the host of the issuing bank. The arbitrary nature of the choice of the operation for sending on-line does not allow fraudsters to prepare in advance for such a terminal decision.
• Checking the hot-list (the list of stolen or lost cards). This check is the same as for a magnetic stripe card transaction. During this check, the terminal checks the card number against the entries in the list of “problem” cards. Most terminals support work with several hotlists at the same time (for example, with bulletins 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 cannot be canceled due to the fact that for some reason it did not pass the check at this stage. The test results are recorded in TVR.
8. Analysis of terminal actions
At this stage, the terminal analyzes the results of the previous steps of the transaction recorded in TVR, as well as the parameters of the operation, set by the issuer in special fields of the chip memory, and by the acquirer in the terminal settings. Based on the results of the analysis, the terminal decides whether to carry out the operation in on-line mode, allow it to be carried out offline (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 to date. There is a special list in the memory of the terminal and the card, which contains possible actions for carrying out the operation, 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. Analyzing TVR and taking into account TAC and IAC, the terminal decides on the further fate of the transaction;
• then the terminal sends its decision to the card, requesting a special cryptogram from it. In other words, the terminal as if asks for the card: “I 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 present to the terminal “its vision” of the further operation of the operation.
Thus, the side of the acquiring bank, represented by the terminal, cannot “single-handedly” refuse to carry out the operation due to the fact that it does not meet the internal criteria of the terminal. This is the fundamental advantage and feature of EMV technology: all participants in the transaction have enough tools to analyze the riskiness of the operation offline. But neither 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 adversary's warnings.
9. Risk management on the side of the card
At this stage, the transaction is checked according to the risk management criteria on the side of the issuer. As a result, the issuer's card generates a response cryptogram to the terminal. There are several basic EMV operations that the card performs during this check:
• New Card Check. The issuer has the ability to set the parameters of the card's risk management in such a way that when carrying out the first operation in its life cycle, the card must necessarily contact the bank's host (i.e., carry out the operation in on-line mode). This allows the issuer to record the fact that the card holder has started using the card.
• Checking the history of transactions (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 impossibility of performing offline authentication).
• Checking counters. The card checks the status of various offline meters specified by the issuer. These counters may include: the allowable number of offline transactions, the maximum amount of offline transactions, the number of attempts to enter a PIN, etc.
10. Analysis of card actions
At this stage, the card completes the risk management procedures and generates a response cryptogram to the terminal. In other words, the card “expresses its opinion” about the offer of the terminal to conduct the operation online. There are three types of response cryptograms (according to the VIS specification):
• Transaction Certificat (TC) - off-line transactions. It is a settlement clearing message that can be used to carry out a chargeback. It contains all the main results of the offline transaction - TVR and Cardholder verification results (CVR). 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, TC provides the terminal with the final data on the operation for their further use in the analysis of disputed transactions.
• Application Authentication Cryptogram (AAC) - cancellation of the operation in offline mode. It is generated if the card “agrees” to cancel the operation or if the bank's host responds negatively. • Authorization request cryptogram (ARQC) - a request to conduct an online transaction. It is sent to the bank's host in the form of a standard authorization message (for example, for VisaNet - messages “0100” or “0200”). For ease of understanding, the dialogue between the card and the terminal can be represented in the following table (see Fig. 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 off-line, the transaction process automatically goes to the 12th stage,
11. Online processing
If the card and the terminal have come to a mutual decision to send the operation for processing to the processing of the issuing bank, then the card generates an ARQC cryptogram, and the terminal sends it in an authorization message along with the transaction data. At the moment, Visa International and MasterCard International have agreed to use a single format for sending chip data for processing. Transactional data specific to EMV is sent to the “3 bit map” of the standard authorization message (a special area of the message for authorizing the operation).
After receiving the cryptogram, the bank's host processes it using a special key set (MDK). Then the bank can carry out 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 by fraudsters (if you do not believe the various rumors and profanities that are periodically circulated in this regard). Thus, the host verifies the signature of the cryptogram with its master key and confirms its validity;
• check the results of offline operations (offline authentication, PIN verification, etc.);
• generate a host response cryptogram Authorization response cryptogram (ARPC), which will allow the card to verify the identity of the issuer and make sure that the authorization response came from the bank host;
• generate a script to update offline counters or to execute another command by the card - up to 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 required set of chip data.
12. 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 carried out offline, the card generates a TC cryptogram and sends it to the terminal. The terminal, in turn, sends a standard message to the acquiring bank's host. The operation is considered successful.
• If the transaction was canceled offline, then the data about it in the form of AAC is sent to the issuer.
• If the transaction was sent for online processing, then upon receipt of 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 the 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.
Read the sequel in one of the nearest rooms "PLUS". In the second part of the material “EMV-project: step-by-step”: issues of managing cryptographic keys in the issuing and acquiring EMV project; "Pitfalls" of the EMV project.
Why did we decide to start with the EMV migration aspects? It's no secret that when deciding on the implementation of a particular card project, banks focus on such issues 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 transition to EMV is in this case the most illustrative example. Any serious mistakes at the initial stage of an EMV project lead to the need for serious re-investments, which is confirmed by the experience of countries that first introduced chip cards a few years ago. At the same time, as evidenced by the example of a number of participants in both the world and the Russian card market, these mistakes can and should be avoided today.
The editorial board of the magazine "PLUS"
EMV migration: from Shakespeare to Chernyshevsky
Despite the fact that at the moment many Russian banks have already begun the process of transition to EMV, and some of them have been issuing and acquiring services for microprocessor cards for a long time, the issue of EMV migration is still very relevant ... First, since January 1, 2006. in the CEMEA region (Visa International), a liability shift has come into force. As a result, if earlier for some banks the volume of dispute transactions that could be “recaptured” using the new rules for conducting chargeback remained a certain blurred amount, now it should acquire a fairly clear and realistic outline.
Secondly, international payment systems continue to stimulate 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 more and more attractive. payment instrument for banks paying attention to new technologies. Also, one 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 organization. As a result, banks, each of which is guided in these matters by their own, internal reasons and motivations, increasingly decide to migrate to EMV cards, moving from a wait and see attitude, similar to the well-known Shakespearean dilemma "To be or not to be", to a purely "Chernyshev's" formulation of the question - "What is to be done?" Indeed, the questions inevitably arise before them: what is the action plan for the implementation of EMV? What steps should be taken? Which functionality should you choose? The list of potential questions can include both technical, procedural and business development aspects. This article is intended 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 wishes of the management or business development plans, the transition to EMV is a complex and difficult task. Its implementation will require financial investments from the bank, time and effort. 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 task with maximum efficiency, one should use the project approach, which is practiced in the Russian market, mainly by consulting companies with many years of practical experience in Russia, and by some large banks (often with foreign roots). It should be noted, that the project approach has recently become more and more common and popular in the implementation of large-scale business tasks. Many organizations declare that they have adopted it for a long time and are using it successfully. However, the introduction of a truly full-fledged project approach requires from the company a sufficiently rich experience of working in this mode (otherwise its implementation may cause rejection of the existing structure of the organization), the presence of a library of universal project documentation and a team of qualified "project-oriented" specialists who already have real implementation experience this kind of projects.
The essence of the project approach is the maximum formalization of the task and the clear formation of a working group for its solution. When formalizing a task, one or several goals are set before the working group or project team, which the bank seeks to achieve during the implementation of the project. The achievement of these goals will mean its successful completion. In this case, the goals should be set out with maximum accuracy. For example, “Issuance of the first 1000 EMV cards by 01.02.07” or “Obtaining certification in the payment system for ATM SMS acquiring by 20.05.06 and subsequent transfer of the entire ATM network of the bank to servicing EMV cards within 6 months” can be considered a successful formalization of the project's task. If, however, an ambiguous goal is set for the project team (such as: “Migrate to EMV as soon as possible”), then it is more than likely that
At the head of the project team is a project manager who is responsible for coordinating project work and completing tasks on time. 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, it is recommended that the project team include experts in various areas of the retail banking business, as well as a business analyst who will be responsible for specific tasks within the framework of the project. Specialists in the field of host system, information security and cryptography, marketing, etc. should also be involved in the work on the project. An example is the fact that, for example, the Visa International documentation lists about 10 functional roles, which are recommended to be implemented within the project team. To organize the effective work of the project team, special attention should also be paid to the issues of data exchange and supervision of work on the project. First, team members must be in constant contact with each other. Undoubtedly, the allocation of bank employees for permanent work on a project (even on such an important one as EMV migration) seems to be difficult. Therefore, for an effective exchange of information between the project participants, it is necessary at least to hold weekly meetings, at which the results of the work on the project for the week will be summed up, the work for the future will be planned and “hot” issues will be discussed. To organize the effective work of the project team, special attention should also be paid to the issues of data exchange and supervision of work on the project. First, team members must be in constant contact with each other. Undoubtedly, the allocation of bank employees for permanent work on a project (even on such an important one as EMV migration) seems to be difficult. Therefore, for an effective exchange of information between the project participants, it is necessary at least to hold weekly meetings, at which the results of the work on the project for the week will be summed up, the work for the future will be planned and “hot” issues will be discussed. To organize the effective work of the project team, special attention should also be paid to the issues of data exchange and supervision of work on the project. First, team members must be in constant contact with each other. Undoubtedly, the allocation of bank employees for permanent work on a project (even on such an important one as EMV migration) seems to be difficult. Therefore, for an effective exchange of information between the project participants, it is necessary at least to hold weekly meetings, at which the results of the work on the project for the week will be summed up, the work for the future will be planned and “hot” issues will be discussed. like EMV migration) seems difficult. Therefore, for an effective exchange of information between the project participants, it is necessary at least to hold weekly meetings, at which the results of the work on the project for the week will be summed up, the work for the future will be planned and “hot” issues will be discussed. like EMV migration) seems difficult. Therefore, for an effective exchange of information between the project participants, it is necessary at least to hold weekly meetings, at which the results of the work on the project for the week will be summed up, the work for the future will be planned and “hot” issues will be discussed.
Secondly, for effective work on a project, the team members must clearly understand who the “Customer of the project” is (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 the project, acting as an arbiter in resolving disputes between team members. For obvious reasons, the “customer” should be one of the bank's leaders who has at least a clear understanding of the main aspects of the card business and retail banking. After formalizing the goal of the project, you should begin to develop a detailed plan for the implementation of the project, in which it is necessary to take into account the totality of intrabank activities and interactions with external organizations and payment systems. As an example, to develop such a business plan, you can use a certification plan obtained from a payment system office. It necessarily reflects the main stages of the project in terms of the payment system and the date of the tests. Although such a plan does not include a wide range of internal operations and activities to be carried out by the bank during the project, it gives a fairly complete picture of the time frame of the project - from the moment it was opened in the payment system until the confirmation of the first EMV transaction or BIN activation. In other words,
Project stages
Ideally, the project plan should describe all the bank's activities in the implementation of the project, from the moment the working group is formed until the project is closed 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 design work. Therefore, it seems 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 its framework. However, such adjustments must be agreed with the “customer” without fail.
The stages of implementation of an 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 park, etc. For example, it is quite 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 to what extent the functionality of the host system corresponds to the goals of this project, and, based on this, introduce into the plan the appropriate measures for finalizing or updating the processing software. In the same way, when analyzing the current state of the POS-terminal park, one should take into account that the majority of modern terminal devices initially comply with the EMVCo Level-1 requirements, which guarantees their technical readiness to receive EMV cards. In the case of devices installed several years ago, it is necessary to ask the manufacturers about the timing and cost of completing the terminals with the necessary modules. However, any EMV project will have a set of common milestones.
So, almost every emission project will include the following stages:
• preliminary work;
• formation of business requirements for the card product, on the basis of which the technical description is formed;
• selection of a card provider;
• management of cryptographic keys;
• development of the card risk management policy;
• choosing a personalization bureau or preparing your own personalization center;
• 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 emission of EMV-cards and gradual adaptation of the POS-terminal network. Preparing updates. Things to consider after the project is closed (for example, regular key renewal procedures).
On the other hand, all acquiring projects also share common stages:
• preliminary work;
• formation of requirements;
• selection of a terminal software supplier and equipment modernization;
• management of cryptographic keys;
• development of the terminal risk management policy;
• preparation of the processing system;
• certification in the payment system;
• marketing support - work with trade and service enterprises;
• conducting training for employees of the bank and trade and service enterprises;
• pilot project;
• completion of the project: adaptation to the acceptance of EMV-cards of the required number of terminal devices or the entire acquiring network of the bank. It is also necessary to take into account the post-project stage - updating keys, procedures for working with new software, etc.
An acquiring project is often considered to be relatively simpler than an emission project. However, one cannot always agree with this. Especially in cases where the goal of the project 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 a bank to pass a much wider list of certification tests in comparison with an emission project.
So, for example, when certifying for acquiring at Visa International, the bank must pass end-to-end testing, which confirms the possibility of correct sending of 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 profiles of EMV-cards. With regard to test capabilities, international payment systems readily supply banks with a large package of test tools, from test cards to systems for preparing personalization data. Moreover, often in order to gain access to these resources, it is enough to send a corresponding request to the project manager from the side of the payment system. The main thing is not to play with test tools and remember that
Of course, the bank must separately undergo certification activities for ATM and merchant acquiring, as well as for Manual Cash operations (cash withdrawals at the cash desks of bank branches using a POS terminal). End-to-end testing can be carried out in 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 emission of EMV cards in the same payment system, the bank must conduct an analogue 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 payment office. systems where the correctness of card personalization is checked. It should be noted that at the same time, Russian banks participating in Visa International are in a clearly more advantageous position, since a team of specialists works in the Moscow office of the payment system, which independently certifies cards without involving a regional London office, which obviously saves time for the project.
The only really fundamental feature of the implementation of emission projects in comparison with acquiring is the need for a detailed study of key material management issues (key management). As part of the emission 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 loading the certificates of the payment system into the terminal and their subsequent renewal. Therefore, in terms of complexity and complexity, acquiring and issuance projects are relatively similar. Although today it is de facto customary to start migration to EMV with certification for acquiring smart cards.
As for the timing of the EMV project implementation, this indicator largely depends on the current state of the processing system and terminal network of the bank. For example, purchasing, installing, and testing a host system upgrade can take several months. The same can be said about the terminal software, although the bank can often get support from the manufacturer in this matter up to the preparation of the terminal platform for testing and loading test certificates of the payment system by the service department of the supplier company. However, there is a minimum time frame for the implementation of an EMV project, which is set by the time frame for passing the mandatory certification procedures of payment systems (we will return to this issue in more detail a little later). For example,
For a preliminary assessment of the project implementation period, it is again extremely useful to look at the certification plan of the payment system, which will clearly demonstrate the minimum terms of certification and the passage of certification procedures by the bank. Based on the practice and experience of Russian banks, the average project implementation period, including certification for the issue and acquiring of EMV cards in one payment system, is about 1.5 years. Effective planning and use of the services of outsourcing companies (third-party personalization and processing centers) can shorten this period, and vice versa.
Business requirements as a cornerstone
When formalizing requirements, it is important to maintain 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 on their conduct off-line or on-line, update offline counters, etc. This is also true for terminal equipment. Therefore, at the stage of forming the requirements, each of the business units of the bank must unambiguously determine what kind of card product it wants to see at the output. In the end, it is these specialists who will have to sell the created service, earn a profit and thereby recoup the costs of implementing this product. It will also be fair to note that business units rarely have a full 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 “cardholders” who, to one degree or another, have competence and knowledge in the field of EMV-cards functionality.
EMV transaction: 12 stages
So, having decided on the main aspects of planning an EMV project, let's move on to considering 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 with an EMV card in a POS terminal adapted to accept chip cards. This will allow, firstly, to get a more detailed understanding of the procedures and information exchange that occurs between the card, terminal equipment and the processing system, and secondly, to form the necessary basis for the subsequent analysis of perhaps the most complex aspect of EMV migration - construction of a key material management procedure. In addition, focusing on the technology of conducting transactions with chip cards as such makes it possible 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, it should not be forgotten 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. 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, it should not be forgotten 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. 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, it should not be forgotten 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 within the framework of this article, the available official EMVCo documents will be used, 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 chip cards Visa International and MasterCard International, which are collectively called 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 user of the card, the operation on it takes a matter of seconds (although, of course,
1. Application selection;
2. Initialization of application processing;
3. Reading application data;
4. Offline authentication;
5. Handling restrictions;
6. Verification of the cardholder;
7. Risk management on the side of the terminal;
8. Analysis of terminal actions;
9. Risk management on the side of the card;
10. Analysis of the actions of the card;
11. Online processing (this stage takes place only if the operation for some reason could not be carried out offline);
12. Completion of the operation. We will analyze each of the listed 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 on which the operation will be performed. In the terminal settings, there is a list of card applications with which it can work. In addition to the basic Visa International and MasterCard International applications - VSDC and M / Chip - it may also contain other applets, such as, for example, loyalty programs, bonus or identification applications. A special area of the memory card contains a list of all applications that are loaded on it.
It should be noted here that all EMV cards have a common information storage structure. For example, a list of applications should be stored in a specific area of the map file structure. This makes it possible to use the cards in any terminal that meets the EMV requirements. The so-called Application Identifier (AID) is used to select the application. Any application written to the memory of an EMV card must be assigned a specific ISO identification number. Even if a particular bank wants to release its own application, available only to its customers, it will still have to go through the procedure for obtaining an AID. AIDs are recorded in the card 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;
• Product Identifier Extension (PIX) code, which corresponds to the type of card product.
For example, Visa International cards are assigned 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 is checked in the memory of the card and in the memory of the device. This is how the application is selected for the operation.
If the card and the terminal contain several common applications (for example, VSDC and the Petrol Check loyalty application), the terminal will display a list of all common applications on the screen and prompt the cardholder to select the application through which the transaction will be processed (see Fig. 1). At the same time, when planning an EMV project, a bank specialist responsible for the development of a POS-terminal network should take into account that not all POS-terminals support the option of choosing an application. In this case, the application with the highest priority (Application Priority Indicator - API) will be selected for the operation, which is set by the issuer when personalizing the card. Typically, the issuer chooses the payment application, which is given the highest priority by default.
And finally, if the card and the terminal do not have common applications, then the operation will be automatically canceled by the terminal, and the card will be returned to the client.
2. Initializing application processing
At this stage, the terminal informs the card that it is ready to start a transaction. In response to this, the card must perform the following two operations.
• Checking the so-called geographic 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 their 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 certain transactions with it in this country (for example, allow 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 methods of risk management (refusal to authorize transactions initiated in a certain region of the world) when conducting offline transactions. 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 carry it out by using special settings when personalizing the card. 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 carry it out by using special settings when personalizing the card. 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 carry it out by using special settings when personalizing the card.
• The card sends the Application Interchange profile (AIP) to the terminal. This operation is required 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 into a TVL display (Tag, Value, Length). It should be noted that for all the seeming openness of data exchange between the card and the terminal, there is information that is never transmitted by the card to the terminal. First of all, this is the value of the PIN-code and secret keys recorded in a special area of the memory of the card's chip.
3. Reading application data
At this stage, the card transmits to the terminal the data necessary for the transaction (using the AIP data) and the information used during 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 dominate the global market, but more and more banks are starting 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 outdated models do not have. This is why the use of SDA is still mandatory for EMV card issuers. Thus, even if a bank intends to issue cards with safer DDA technology, it will also have to provide support for an SDA card. All of the above authentication methods work offline without contacting the host of the issuing bank or acquirer and are based on asymmetric key technology.
We will return in more detail to the features of SDA and DDA in a separate article in one of the next issues of the PLUS magazine, devoted to the management of key material. Now let's dwell on the consideration of the general aspects of the authentication procedure. Both SDA and DDA use the Payment System Certificate loaded into the terminal device (the so-called EMV library), as well as public cryptographic keys written to 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 make sure that the card belongs to a specific 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 for authentication throughout the card's life. In fact, SDA is not much different from the CVV (Card Verification Value) technology used on magnetic stripe cards. On the contrary, DDA cards generate a unique cryptographic value for each operation, use a 3DES key that is unique for each card, stored in a protected area of its memory.
Based on the results of the authentication, the terminal records its result (Terminal Verification Result - TVR) in a special report. Thus, failing offline authentication does not mean the end of the transaction. 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 occur online, then the meaning of offline authorization simply disappears.
5. Handling constraints
At this stage, the terminal carries out a series of checks on the card, confirming its suitability for the transaction. In particular, the terminal checks the validity period of the card, the ability to use the card for this type of operation, as well as the version of the application. To check the card expiration date, a special parameter stored in the card memory is used - Application Expiration Date. In some cases, the issuer can specify an additional parameter of the application life-time - Application Effective Date. The last parameter is optional and may differ from Application Expiration Date. For example, the issuer may provide its customer with the option to use the card during the period of its re-issue due to its expiration. In this case, the Application Effective Date period will be longer, than Application Expiration Date. The terminal also checks the version of the application. The memory of the card and each terminal contains the versions of the applications they support. The terminal compares the data about the application stored in the card memory with its own data. The results of the operations carried out at this stage are also recorded in the TVR report. As a result of Constraint Processing, the transaction cannot be canceled, even if, for example, the application has expired.
6. Cardholder verification
This stage is the usual stage of cardholder identification. Historically, the most popular and widespread are two methods of cardholder verification method (CVM) - verification of the signature on the card and on the terminal check, as well as entering the PIN code. In some countries, other CVM methods have become widespread, for example, offline PIN verification for transactions at POS terminals. Therefore, most EMV cards support several CVM methods, which means that the terminal and the card will have to choose the appropriate option again. The principle for selecting a CVM is similar to selecting an application. The EMV-card memory stores the CVM list specified by the card issuer at the stage of its personalization. This list is transmitted to the terminal at this stage of the operation. The terminal compares it to its list, specified 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 select the best option when several methods match in the card and terminal lists (see Fig. 2).
If, as a result of comparison of CVM lists, 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 cards with a magnetic stripe);
• 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 enciphered PIN. In this case, in order to verify the transmitted value of the PIN-code, the card must manipulate the encrypted data. If you delve deeper into the analysis of EMV specifications, you will find that in the CVM list you can also set the conditions under which the use of certain CVM methods becomes available (for example, the preferred entry of the PIN code for cash withdrawal operations), as well as set the terminal actions in the event 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 to set up offline customer verification.
7.Risk management on the terminal side
At this stage, the terminal carries out 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 it 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 rely on the fact that the transaction will be carried out without contacting the host of the issuing bank. The arbitrary nature of the choice of the operation for sending on-line does not allow fraudsters to prepare in advance for such a terminal decision.
• Checking the hot-list (the list of stolen or lost cards). This check is the same as for a magnetic stripe card transaction. During this check, the terminal checks the card number against the entries in the list of “problem” cards. Most terminals support work with several hotlists at the same time (for example, with bulletins 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 cannot be canceled due to the fact that for some reason it did not pass the check at this stage. The test results are recorded in TVR.
8. Analysis of terminal actions
At this stage, the terminal analyzes the results of the previous steps of the transaction recorded in TVR, as well as the parameters of the operation, set by the issuer in special fields of the chip memory, and by the acquirer in the terminal settings. Based on the results of the analysis, the terminal decides whether to carry out the operation in on-line mode, allow it to be carried out offline (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 to date. There is a special list in the memory of the terminal and the card, which contains possible actions for carrying out the operation, 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. Analyzing TVR and taking into account TAC and IAC, the terminal decides on the further fate of the transaction;
• then the terminal sends its decision to the card, requesting a special cryptogram from it. In other words, the terminal as if asks for the card: “I 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 present to the terminal “its vision” of the further operation of the operation.
Thus, the side of the acquiring bank, represented by the terminal, cannot “single-handedly” refuse to carry out the operation due to the fact that it does not meet the internal criteria of the terminal. This is the fundamental advantage and feature of EMV technology: all participants in the transaction have enough tools to analyze the riskiness of the operation offline. But neither 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 adversary's warnings.
9. Risk management on the side of the card
At this stage, the transaction is checked according to the risk management criteria on the side of the issuer. As a result, the issuer's card generates a response cryptogram to the terminal. There are several basic EMV operations that the card performs during this check:
• New Card Check. The issuer has the ability to set the parameters of the card's risk management in such a way that when carrying out the first operation in its life cycle, the card must necessarily contact the bank's host (i.e., carry out the operation in on-line mode). This allows the issuer to record the fact that the card holder has started using the card.
• Checking the history of transactions (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 impossibility of performing offline authentication).
• Checking counters. The card checks the status of various offline meters specified by the issuer. These counters may include: the allowable number of offline transactions, the maximum amount of offline transactions, the number of attempts to enter a PIN, etc.
10. Analysis of card actions
At this stage, the card completes the risk management procedures and generates a response cryptogram to the terminal. In other words, the card “expresses its opinion” about the offer of the terminal to conduct the operation online. There are three types of response cryptograms (according to the VIS specification):
• Transaction Certificat (TC) - off-line transactions. It is a settlement clearing message that can be used to carry out a chargeback. It contains all the main results of the offline transaction - TVR and Cardholder verification results (CVR). 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, TC provides the terminal with the final data on the operation for their further use in the analysis of disputed transactions.
• Application Authentication Cryptogram (AAC) - cancellation of the operation in offline mode. It is generated if the card “agrees” to cancel the operation or if the bank's host responds negatively. • Authorization request cryptogram (ARQC) - a request to conduct an online transaction. It is sent to the bank's host in the form of a standard authorization message (for example, for VisaNet - messages “0100” or “0200”). For ease of understanding, the dialogue between the card and the terminal can be represented in the following table (see Fig. 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 off-line, the transaction process automatically goes to the 12th stage,
11. Online processing
If the card and the terminal have come to a mutual decision to send the operation for processing to the processing of the issuing bank, then the card generates an ARQC cryptogram, and the terminal sends it in an authorization message along with the transaction data. At the moment, Visa International and MasterCard International have agreed to use a single format for sending chip data for processing. Transactional data specific to EMV is sent to the “3 bit map” of the standard authorization message (a special area of the message for authorizing the operation).
After receiving the cryptogram, the bank's host processes it using a special key set (MDK). Then the bank can carry out 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 by fraudsters (if you do not believe the various rumors and profanities that are periodically circulated in this regard). Thus, the host verifies the signature of the cryptogram with its master key and confirms its validity;
• check the results of offline operations (offline authentication, PIN verification, etc.);
• generate a host response cryptogram Authorization response cryptogram (ARPC), which will allow the card to verify the identity of the issuer and make sure that the authorization response came from the bank host;
• generate a script to update offline counters or to execute another command by the card - up to 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 required set of chip data.
12. 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 carried out offline, the card generates a TC cryptogram and sends it to the terminal. The terminal, in turn, sends a standard message to the acquiring bank's host. The operation is considered successful.
• If the transaction was canceled offline, then the data about it in the form of AAC is sent to the issuer.
• If the transaction was sent for online processing, then upon receipt of 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 the 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.
Read the sequel in one of the nearest rooms "PLUS". In the second part of the material “EMV-project: step-by-step”: issues of managing cryptographic keys in the issuing and acquiring EMV project; "Pitfalls" of the EMV project.
