Verification of the card holder

All the applications under consideration support cardholder verification in the same way: verification methods (CVM Code) and their application codes (Condition Code) are the same in all applications and comply with the EMV V. 4.2 standard.
Output. All the applications under consideration support cardholder verification in exactly the same way: the verification methods and their application codes are the same in all applications.
Card risk management procedures
The card’s risk management procedures are the main component of its functionality. When using online authorization, the EMV card performs risk management procedures twice — each time after the card receives the GENERATE AC command.
As a result of performing the risk management procedure in accordance with EMV specifications, the following questions are answered:
how should the transaction being processed be authorized (approved offline, rejected offline, or sent for online authorization);
whether the card needs to generate an application authorization referral to complete authorization through the procedure of contacting the Issuer for alternative authorization (by phone, telex, etc.).
whether to send the Issuer an advice message informing them of certain events related to card usage (PTL limit exceeded, Issuer authentication failed, transaction was rejected offline, etc.).
how the card’s risk management parameters (CVR, offline limits) are changed.
In addition, after completing the risk management procedures, the application prepares IAD data for the Issuer (Tag ‘ 9F10’), which can be used by the Issuer to make a decision on how to complete the transaction. This data is passed to the terminal in response to the first GENERATE AC command.
In the VIS specification, card risk management is performed using the ADA data objects (Application Decision Actions), internal application parameters (for example, Online Requested by Card Indicator), and CVR. This uses the “event-based” principle of making a decision by the card. In accordance with this principle, the ADA object (the size of the data field is 4 bytes) sets a set of special events that affect the decision of the card application, and for each such event determines the application’s decision about either how to complete the current transaction, how to process the next transaction, or whether to generate an advice message.
For illustration the ADA set contains the following rule: “If the Issuer’s authentication failed, the next transaction must be processed online.” If this rule is activated by the Issuer during card personalization (the corresponding bit in the ADA object is 1), it determines the next event. If the card authentication failed during the current operation, the card application must set the value of the Internal online Requested by Card Indicator to 1.
For CPA and M/Chip 4 applications, card risk management is performed using CIAC (Card Issuer Action Codes) and ADR (Application Decisive Results for the CPA application)/CVR (for M/Chip 4) data objects. CIAC objects have different formats in CPA and M/Chip 4 applications.however, they are used the same way technologically.
There are three objects-CIAC-Decline, CIAC-Online, and CIAC-Default. Each of the listed objects defines the same list of events that affect the card’s decision – making. If the value of a certain bit in CIAC is equal to 1, then if the corresponding ADR/CVR element is also equal to 1, depending on which CIAC object is being checked, the card:
rejects the transaction if verification is performed for the CIAC-Decline object;
performs the transaction online if the verification is performed for the CIAC-Online object;
rejects a transaction in offline mode if verification is performed for the CIAC-Default object.

Thus, the tabular method of making a decision on the value of ADR/CVR using CIAC objects has some redundancy, but it is more universal in terms of representing decision criteria. A similar tabular approach is used in all the applications under consideration to check the value of the TVR against the values of the TAC and IAC objects in the procedures for deciding how to continue processing the transaction by the terminal.
As for functionality, both approaches (tabular and event-based) are equivalent.
From the point of view of the criteria used for making a decision on the card, the EMV applications considered are also equivalent and allow you to respond to all the most important results of the card’s risk analysis. This applies to events such as exceeding the PTL limit, issue Authentication not performed, issue Authentication failed, issue Script Processing failed, Last online transaction not completed, Set go online next transaction, Offline Authentication failed at previous transaction, failed offline PIN verification, new card, and so on.
Note that all three EMV applications do not support the application authorization referral mode.
As for support for advice messages, the M/Chip and CPA applications do not support these messages, and the VSDC application requests the terminal (via Cryptogram Information Data, CID, Tag ‘9F27’) to send an advice message to the card Issuer in the following cases:
the transaction was rejected offline and the ADA object indicates the need to send an advice message;
the PTL limit (PIN Try Limit) was exceeded and the ADA object indicates the need to send an advice message;
the transaction was rejected because the Issuer authentication failed or the Issuer authentication failed, and the ADA object indicates the need to send an advice message.

In the M/Chip 4 and CPA specifications, the CID object data field takes the following values, depending only on the type of cryptogram generated by the card:
CID = ‘ 00’ if the cryptogram is AAC;
CID = ‘ 40’ if the cryptogram is TC;
CID = ‘ 80’, if the cryptogram is ARQC.

This confirms that the card does not support advice messages. Key checks performed by the card as part of the management procedures-
these risks are associated with the use of so-called offline card counters. Let’s look at these counters, their use, the ability to transfer them to the Issuer, and the procedure for resetting values.

Offline counters of the VSDC application. As described in the VSDC application, there are four counters and four corresponding limits, which are exceeded by the counters automatically requires an operation to be performed online. The counters are:
Sequential Transaction Counter (International) – a counter that increases by 1 when performing an offline operation whose transaction currency is not the application Currency. The counter increases regardless of whether the operation is completed successfully or rejected. If the counter exceeds the value of the Sequential Transaction Counter Limit (International), the card requires performing the operation in real time. This requirement is strictly defined in the VSDC application and does not require the use of the ADA mechanism to implement it. The parameter value is set to 0 after a successful online transaction has been completed (the transaction has completed TC)and the Issuer authentication has completed successfully.
Sequential Transaction Counter (International-Country) – a counter that increases by 1 when performing an offline operation for which the Issuer Country Code differs from the Terminal Country Code (i.e. the operation was performed in a different country). The value of this counter is usually less than the value of the Sequential Transaction Counter (International). The counter increases regardless of whether the operation is completed successfully or rejected. If the counter exceeds the value of the Sequential Transaction Counter Limit (International-Country), the card requires performing the operation in real time. This requirement is strictly defined in the VSDC application and does not require the use of the ADA mechanism to implement it. The parameter value is set to 0 after a successful online transaction has been completed (the transaction has completed TC)and the Issuer authentication has completed successfully. For the two transaction counters listed above, an additional Sequential Transaction Upper Limit International limit can be used. If this limit is exceeded by the Sequential Transaction Counter (International-Country) and/ or the Sequential Transaction Counter (International), the card must complete the operation by rejecting the transaction (requires AAC). This limit is used when a transaction must be executed online, but due to the fact that the terminal is offline or there is no connection with the Issuer’s host, it cannot be sent to the Issuer for authorization.
The cumulative Total Transaction Amount (Dual Currency) counter represents funds spent on offline approved transactions in which the transaction currency matches the application currency or the secondary currency. When a secondary currency is used in a transaction to increase the counter value, the transaction amount is converted to the application currency (the VIS specification uses the Currency Conversion Factor object to convert from Secondary Currency to the application Currency). If the parameter exceeds the cumulative Total Transaction Amount Limit, the card requires performing the operation in real time. This requirement is strictly defined in the VSDC application and does not require the use of the ADA mechanism to implement it. The parameter value is set to 0 after a successful online transaction has been completed (the transaction has completed TC)and the Issuer authentication has completed successfully.
The cumulative Total Transaction Amount counter represents funds spent on offline approved transactions in which the transaction currency is the same as the application currency. If the parameter exceeds the cumulative Total Transaction Amount Limit, the card requires performing the operation in real time. This requirement is strictly defined in the VSDC application and does not require the use of the ADA mechanism to implement it. The parameter value is set to 0 after a successful online transaction has been completed (the transaction has completed TC)and the Issuer authentication has completed successfully.

For the two cumulative counters listed above, an additional cumulative Transaction Upper Limit International can be used. If the Cumulative Total Transaction Amount (Dual Currency) counter and/or the Cumulative Total Transaction Amount counter exceed this limit, the card must complete the operation by rejecting the transaction (requires AAC). This limit is used when a transaction must be executed online, but due to the fact that the terminal is offline or there is no connection with the Issuer’s host, it cannot be sent to the Issuer for authorization.
The values of all the limits listed above can be obtained by the terminal using the GET DATA command and can be changed by the Issuer using the PUT DATA command when executing the Script Processing procedure.
In some VSDC implementations, offline limit values can be passed to the Issuer in the Issuer Discretionary Data section of the IAD object (in M/Chip 4 and CPA, counter values are passed to the payment system section, i.e. they are mandatory and can be encrypted). In General, support for transmitting offline counters to the Issuer is optional (Implementer-option). However, it is supported in VSDC 2.5 and 2.7 applets.
In addition, VSDC has an Available Offline Spending Amount data object (Tag ‘9F52’) that specifies the amount available for offline use. This object can be extracted by the terminal using the GET DATA command and displayed on the terminal screen or printed in the transaction receipt.
Offline counters of the m/Chip 4 application. in this application, offline counters are arranged much easier than in VSDC. There are two counters in total, and there are upper and lower limits for each of them.
Cumulative Amount is funds spent on successful offline operations performed in currencies that can be converted to the application currency using the Currency Conversion Table (Tag ‘D1’). The cumulative amount counter has two limits — the Upper Cumulative Offline Limit and the Lower Cumulative Offline Limit. These two limits can be used in different ways using the CIAC mechanism. The most common way to use them is as follows. If the limit is exceeded Lower Cumulative

Offline Limit, the card requests the execution of a transaction in real time. If the Upper Cumulative Offline Limit is exceeded and the terminal is offline or unable to process the transaction online, the card asks to reject the transaction.
If the transaction currency is not the application currency and is not in the Currency Conversion Table (‘D1’), then the successful offline transaction is applied to the second counter of the Sequential Offline Transaction Number. This counter has two limits — Upper Sequential Offline Limit and Lower Sequential Offline Limit. If the Lower Sequential Offline Limit is exceeded, the card requests that the transaction be completed in real time. If the Upper Sequential Offline Limit is exceeded and the terminal is offline or unable to process the transaction online, the card asks to reject the transaction.
Both offline counters can be passed to the Issuer in the IAD object. Whether offline counters are sent to IAD, as well as whether they need to be encrypted, is determined by the Issuer in the Application Control object.
The values of all offline limits can be obtained by the terminal using the GET DATA command and can be changed by the Issuer with the PUT DATA command when executing the Script Processing procedure.
In addition, the M/Chip 4 application has an Offline Balance data object (‘9F50’) that specifies the amount currently available for offline use. This object can be extracted by the terminal using the GET DATA command, if this is specified in the Application Control object, and displayed on the terminal screen or printed in the transaction receipt.
In addition to checking offline counters, the M/Chip 4 app also checks that the size of the transaction being processed does not exceed the Maximum Transaction Amount limit. In addition, in the M/Chip 4 application, it is possible to perform one additional Check Table check based on the data received by the card in the first GENERATE AC command. The verification result is recorded in the CVR.

The offline counters of the application of CPA. The CPA app supports a set of seven offline counters, depending on the selected profile:
two cumulative counters;
three transaction counters;
two cyclic cumulative counters,
and three counters independent of the card profile. These counters include Additional Counter, Additional Accumulator, and Additional Cyclic Accumulator.
Consider counters that depend on the card profile. Let’s start with transaction counters. For each counter, regardless of the selected application profile, conditions are defined for increasing the counter value by
These conditions include answers to questions about whether the value should be changed if:
online operation;
the operation is rejected in offline mode;
operation approved in offline mode;
the operation was attached to a cumulative counter;
the operation is not in-country.

Then, depending on the selected application profile, the following parameters are defined for each transaction counter:
upper and lower counter limits;
whether to use a counter for this profile;
whether to set the counter value to 0 after performing an online operation;
whether to send the counter value to the Issuer in IAD (in M/Chip 4, this is set via the Application Control object).
Let’s now consider regular (non-cyclic) cumulative counters. There are no more than two for each app. For each cumulative counter, the counter currency and conditions for increasing the counter value are defined, including answers to questions about whether the value should be changed if:
online operation;
the operation is approved offline.

Then, depending on the selected application profile, the following parameters are defined for each cumulative counter:
upper and lower counter limits;
whether to use a counter for this profile;
whether to set the counter value to 0 after performing an online operation;
the need to send the counter value to the Issuer in the IAD object.
need to send the counter balance value to the terminal (the difference between the upper limit and the current counter value).
When using cyclic cumulative counters, regardless of the selected profile, the cycle type (daily, weekly, and monthly) is also determined, as well as the reference values of the date and day. When using cyclic counters, only one limit is applied, the excess of which is recorded in the CVR and ADR.
Note that when performing checks with cumulative counters, you can use up to 14 different currency conversion tables (for each counter, the table is defined at the level of the selected application profile). You must use currency conversion whenever the transaction currency does not match the currency of the counter, which does not depend on the application profile.
In the CPA application, as part of the card risk management procedures, in addition to checking offline counters, the following additional checks can be performed, depending on the selected profile:
checking that the size of the processed transaction does not exceed the Maximum Transaction Amount limit;
checks that the number of days since the last online transaction exceeds the Number of Offline Days limit;
two additional Check Table checks based on the data received in the first GENERATE AC command. The results of these checks are recorded in the ADR.
In conclusion, it should be noted that the implementation of a risk management card in the applications M/Chip 4 and the CPA mechanism is used the Additional Check Table.
In the CPA application, up to two additional checks are applied (two Additional Check Table data objects can be stored on the card). Only one Additional Check Table can be used in the M/Chip 4 application. The VSDC application does not use the additional verification mechanism at all.

Conclusion.

From the point of view of the card’s risk management procedure, the CPA application is by far the most functional. It uses ten different offline counters that allow the Issuer to monitor the offline activity of the card according to a variety of criteria. Out of ten counters, seven depend on the selected app profile. Limits for each of these counters are set at the app profile level. There is a flexible system for converting the transaction currency into the currencies of cumulative counters (a different currency for each counter). The values of the conversion table elements are also determined at the application profile level.
In addition to the limits on cumulative counters, the CPA application can support other limits:
maximum transaction size (your own at the app profile level);
the maximum number of days since the last online transaction (different for each profile);
three limits on the number of invalid cryptographic card checks

VLP limits.
In addition, the CPA application supports up to two additional checks of the Additional Check Table.
The M/Chip 4 app is inferior to the CPA in terms of the number of offline counters (only two for the entire app without the ability to select a profile) and the number of additional checks (no more than one). In addition, in M/Chip 4, the currency of the cumulative limit and maximum transaction size must match the currency of the application. However, the M/Chip 4 application still allows the card Issuer to reset offline limits using the CSU (Card Status Update) object.
VSDC uses 4 offline limits with a fixed mechanism for resetting their values. The app uses only two currencies that have a conversion rate set between them. In VSDC, no other limits (such as the maximum transaction size) or additional checks are supported. A distinctive feature of the VSDC application is its support for advice messages.

Despite the difference in the capabilities of the card’s risk management procedures for performing the main function — maintaining a balance between the client’s offline funds on the card and their funds on the main account — the applications considered are equivalent.

Authentication of the Issuer
Issuer authentication is performed by the card based on the value of the Issuer Authentication Data object received by it. If bit 3 of byte 1 of the AIP ” Issuer authentication is supported” = 0, the second GENERATE AC command is used to authenticate the Issuer by the terminal. M/Chip 4 and CPA use the GENERATE AC command, while VSDC uses EXTERNAL AUTHENTICATE.
The VSDC and M/Chip 4 applications use the first ARPC generation method: the arqc value is added modulo 2 with the value (ARD||‘00’||‘00’||‘00’||‘00’||‘00’||‘00’) and the resulting result is encrypted on the session key to generate a cryptogram. Here, the ARD (Authorization Response Data) is a 2-byte data element that is included as the 9 and 10 bytes of the Issuer Authentication Data element.
In VSDC, the ARD element is a normal authorization code. In M/Chip 4, this element is called ARPC Response Code, and in addition to informing the app about the authorization result, it allows the card Issuer to change the PTC value (PIN Try Counter), set the Go online on next transaction flag, and give the card instructions for resetting the app’s offline limits.
The CPA application uses Method 2 for generating ARPC. In this case, to get ARPC to the value Y=ARQC||Z||00000000, the ISO/IEC 9797-1 MAC calculation Algorithm 3 is applied (the MAC size is 4 bytes). The ARPC||z object is used as the Issuer Authentication Data. In this case, the z object is a 4-byte CSU (Card Status Update) object that, in addition to informing the application of the transaction authorization result by the Issuer, allows the Issuer to change the PTC value (PIN Try Counter), block the card, block the card application, set the Go online on next transaction flag, and give the card instructions for resetting the offline limits of the application.

Conclusion. M/Chip 4 applications and especially CPA allow you to reset the card application parameters (for example, offline counters) during the Issuer authentication process, thus providing an alternative mechanism for the Script Processing procedure. This property is very useful, but does not determine the functionality and security of the card.