6.7 Terminal risk management

Including the terminal risk management stage in the EMV ¢ transaction flow protects the issuer, acquirer, and payment system against fraud, through several security measures: floor limit checking, random transaction selection, and velocity checking.

The processing in this stage can be performed any time after the read application data stage and before issuing the first GENERATE AC command. The results of the terminal risk management are recorded in the fourth byte of the TVR register.

This stage is included in the EMV ¢ transaction flow only in case bit 4, "Terminal risk management is to be performed", in the first byte of the AIP is set to 1. Otherwise, the terminal skips the processing implied by any of the three aforementioned security mechanisms.

Regardless of the coding of the card's AIP, concerning support of terminal risk management, a terminal may support an exception file (black list) per application. When this file exists, the terminal verifies that the Application PAN and, optionally , the Application PAN Sequence Number of the card involved in the current transaction cannot be found in the exception file.

If a match is found in the exception file, the terminal shall set to 1 bit 5, "Card appears in exception file", in byte 1 of the TVR.

After completing the processing in the terminal risk management stage, the terminal sets to 1 bit 4, "Terminal risk management was performed", in byte 1 of the TSI register.

6.7.1 Terminal floor limit

An effective security measure against attempts to overspend is to check that the amount involved in a transaction does not exceed a floor limit established by the acquirer, referred to as the Terminal Floor Limit.

However, if the cardholder colludes with the shopkeeper , an amount over the floor limit needed to buy one expensive item can be split into two distinct amounts below the floor limit, which are authorized in two separate transactions with the same card at the same terminal. This kind of threat is called a split sale.

If the acquirer is willing to provide security protection against split sales, the terminal has to have enough storage space to accommodate a transaction log like that presented in Table 6.7.

Table 6.7: Transaction Log as a Security Protection Against Split Sales
	Application PAN	Amount, Authorized	Application PAN Sequence Number	Transaction Date
Transaction 1	PAN1	Amount 1	PAN Seq1	05/10/2001
Transaction 2

Transaction 1,000	PAN1	Amount 2	PAN Seq1	05/10/2001

The processing performed by the terminal for each new EMV ¢ transaction is described by the following actions.

Use the Application PAN and optionally the Application PAN Sequence Number of the card involved in the current transaction to search for an existing record in the transaction log.
If there is such a record, add the value of the Amount, Authorized field in the current transaction (Amount 2) with the Amount, Authorized field in the most recent transaction (Amount 1) with the same Application PAN/PAN sequence number. The cumulated value of the two transactions represents the total.

If the value of total is greater than or equal to the value field of the Terminal Floor Limit data object with tag 9F1B in the terminal, then set bit 8, "Transaction exceeds floor limit", in byte 4 of the TVR.

Record the new transaction (e.g., at index 1,000) within the transaction log and end the processing.
In case there is no such record in the transaction log, or the terminal does not keep a transaction log, the terminal checks whether the value of the Amount, Authorized in the current transaction is greater than or equal to the value field of the Terminal Floor Limit.

If this is true, the terminal sets bit 8, "Transaction exceeds floor limit", in byte 4 of the TVR.

6.7.2 Random transaction selection

This security mechanism ensures that low-value transactions, which are usually authorized off-line by the terminal, go from time to time to the issuer for on-line authorization. This security mechanism can be implemented in terminals that are not "off-line-only". This mechanism protects against threats that cannot be detected in an off-line environment. The terminal chooses which low-value transaction is recommended for on-line authorization according to a selection function.

In order to implement such a function, the terminal associates a random transaction number in the range of 1 to 99 to each new EMV ¢ transaction processed by the terminal.

A simple selection function can be implemented as a step function. To this end, the acquirer specifies a new parameter, in addition to the Terminal Floor Limit parameter, called the target percentage to be used for random selection, or simply the target percentage. This parameter is chosen in the range of 0 to 99. In its turn the selection function is implemented as follows :

For any transaction having the value of Amount, Authorized below the terminal flow limit and with a random transaction number smaller than or equal to the target percentage, the terminal selects the transaction for on-line authorization by the issuer.
For any transaction having the value of Amount, Authorized greater than or equal to the terminal flow limit, indifferent of the value of the random transaction number, the terminal selects the transaction for on-line authorization by the issuer.

The higher the value of the target percentage, the higher the probability that a small value transaction with Amount, Authorized below the Terminal Floor Limit is selected for on-line authorization.

A more fine- tuned decision about the random transaction selection can be obtained with a biased selection function, where the value of the target percentage parameter can be biased by the value of the transaction amount towards an increased transaction target percentage parameter. This selection function is graphically described in Figure 6.8. To implement it, the acquirer needs to specify two additional parameters:

Threshold value for biased random selection: This is a threshold amount, simply referred to as the threshold value, which can be zero or a positive number smaller than the Terminal Floor Limit. For any transaction amount bigger than this threshold, the biased selection mechanism becomes effective.
Maximum target percentage to be used for biased random selection: This parameter, simply referred to as the maximum target percentage isalso in the range of 0 to 99 but is at least as high as the target percentage. This parameter represents the desired percentage of transactions with Amount, Authorized just below the Terminal Floor Limit that will be selected by this selection algorithm.

Figure 6.8: Biased selection function for on-line authorization.

The value of the transaction target percentage is computed for each new EMV ¢ transaction as a linear interpolation between the target percentage and the maximum target percentage, depending on the position of the Amount, Authorized between the threshold value and the Terminal Floor Limit.

Indeed, from Figure 6.8 one can see that from the equivalence of the triangles ABC and ADE , one can write the relation: CB/ED = BA/DA. Therefore CB = ED * (BA/DA). Considering that CB = Transaction Target Percentage ˆ’ Target Percentage, ED = Maximum Target Percentage ˆ’ Target Percentage, BA = Amount, Authorized ˆ’ Threshold Value, and DA = Terminal Floor Limit ˆ’ Threshold Value, then the transaction target percentage is computed as:

Transaction Target Percentage = Target Percentage + (Maximum Target Percentage ˆ’ Target Percentage) * [(Amount, Authorized ˆ’ Threshold Value)/(Terminal Floor Limit - Threshold Value)]

The biased selection function is implemented as follows:

For any transaction having the value of Amount, Authorized below the threshold value and with a random transaction number smaller than or equal to the target percentage the terminal selects the transaction for on-line authorization by the issuer.
For any transaction having the Amount, Authorized greater than or equal to the threshold value and smaller than the Terminal Floor Limit and with a random transaction number smaller than or equal to the computed transaction target percentage, the terminal selects the transaction for on-line authorization by the issuer.
For any transaction having the value of Amount, Authorized greater than or equal to the terminal flow limit, indifferent of the value of the random transaction number, the terminal selects the transaction for on-line authorization by the issuer.

If the terminal selects a typical off-line transaction for on-line authorization by the issuer through the (step or biased) selection function, the terminal sets bit 5, "Transaction selected randomly for on-line processing", in byte 4 of the TVR.

6.7.3 Velocity checking

This security mechanism requires that after a card performs a certain number of consecutive off-line transactions, the number of which is specified by the issuer in the parameter Lower Consecutive Off-line Limit (tag 9F14 in the ICC), the terminal at the point of service selects the current transaction for on-line authorization.

If for any reason the terminal is not able to go on-line for authorization, transactions may be still completed off-line until a second limit is reached ”a limit established by the issuer in the parameter Upper Consecutive Off-line Limit (tag 9F23 in the ICC) .

In case the number of consecutive off-line transactions is greater than this upper limit, the recommendation of the issuer might be to reject any transaction that cannot be completed on-line. Once a transaction has been completed on-line with a successful authentication of the issuer, the counting of the number of transactions processed off-line can restart, so that transactions can again be performed off-line until the Lower Consecutive Off-line Limit is reached again.

This measure impedes a cardholder from overspending by simply participating in a large number of low-value transactions concluded off-line.

In order to implement this security mechanism, the two parameters (Lower Consecutive Off-line Limit and Upper Consecutive Off-line Limit) have to be personalized in the card by the issuer. The card must also support the internal management of the following two data objects:

ATC: This is stored in the data object with tag 9F36. This transaction counter managed by each application is incremented every time the card application participates in a new EMV ¢ session.
Last on-line ATC Register: This is stored in the data object with tag 9F13 in the card. This register is set to the value of the ATC corresponding to the last transaction that was sent on-line for authorization.

The card has to implement the GET DATA command (see Table 6.4). Using this command, the terminal can retrieve both the ATC, in case the value of P1P2 in the C-APDU is set to 9F36, and the last on-line ATC Register in case the value of P1P2 in the C-APDU is set to 9F13. The terminal can compute the number of consecutive off-line transactions as the difference between the ATC and the last on-line ATC Register.

The terminal performs the velocity checking according to the following algorithm:

Retrieve from the EMV ¢ data objects heap the parameters Lower Consecutive Off-line Limit (tag 9F14) and Upper Consecutive Offline Limit (tag 9F23). If one of these data objects is not present, skip the processing below.
Issue the GET DATA command with P1P2 = 9F36 to retrieve the ATC from the card, and the GET DATA command with P1P2 = 9F13, to retrieve the last on-line ATC Register from the card.

If the status words SW1SW2 returned by any of the two commands are different than 9000, then make the following settings and finish the velocity checking:
- Set to 1 bit 7, "Lower Consecutive Off-line Limit exceeded", in byte 4 of the TVR.
- Set to 1 bit 6, "Upper Consecutive Off-line Limit exceeded", in byte 4 of the TVR.
- Set to 0 bit 4, "New card", in byte 2 of the TVR.
Compute the number of consecutive off-line transactions as the difference between the ATC and the last on-line ATC Register.
If the number of consecutive off-line transactions is greater than the Lower Consecutive Off-line Limit, then set to 1 bit 7, "Lower Consecutive Off-line Limit exceeded", in byte 4 of the TVR.
If the number of consecutive off-line transactions is greater than the upper consecutive off-line limit, then set to 1 bit 6, "Upper Consecutive Off-line Limit exceeded", in byte 4 of the TVR.
Check whether the last on-line ATC Register is zero. If this is the case, set to 1 bit 4, "New card", in byte 2 of the TVR.