Terminal Risk Management

Tomcat

Professional
Messages
2,689
Reaction score
963
Points
113
Risk management procedures (Terminal Risk Management or TRM) performed by the terminal are an element of ensuring the security of transactions performed using a plastic card. TRM procedures are designed to force certain transactions to be processed in real time, and include three mechanisms to combat card fraud:
  • control of the size of operations performed on the card (Floor Limit Checking);
  • random selection of a transaction for its online authorization by the issuer (Random Transaction Selection);
  • checking the offline activity of using the card (Velocity Checking).
TRM procedures can be performed by the terminal at any time between the moment the process of reading the card data is completed and the terminal forms the first GENERATE AC command. TRM procedures must be performed when bit 4 of byte 1 of the AIP "Terminal risk management is to be supported" is equal to 1. Otherwise, according to EMV, the terminal should not perform TRM procedures. However, due to the fact that the servicing bank in MasterCard and VISA payment systems is responsible for transactions exceeding the International Floor Limit established for this merchant (the maximum transaction size at which the transaction can be processed offline), merchants must execute the TRM procedure regardless of the AIP value.

After executing the TRM procedures, bit 4 of byte 1 of TSI "Terminal risk management was performed" is set to 1.

Regardless of the value of bit 4 of byte 1, the AIP terminal performs a number of other checks (checking the exception file, establishing the fact that the card is new, etc.). The terminal can maintain an exception file (otherwise it is called a black list, black list, or stop list), consisting of Application PAN card numbers and, possibly, Application PAN Sequence Number, the use of which is prohibited by the issuers of these cards. If the terminal detects the Application PAN Sequence Number in the exception file, bit 5 of Byte 1 of TVR “Card appears in exception file” is set to 1.

In addition, regardless of the value of bit 4 of byte 1, the AIP terminal checks the equality of LATC = 0. The parameter LATC (Last Account Transaction Counter, Tag '9F13') is the number of the last online transaction. To get the current value of this parameter, the terminal must send a GET DATA command to the card with the parameters Pl = '9F'h and P2 =' 13'h.

If the equality LATC = 0 is fulfilled, bit 4 of byte 2 TVR "New Card" is set equal to 1.

The terminal also has the ability to forcibly force an operation to be performed in real time. For this, bit 4 of Byte 4 of TVR "Merchant forced transaction online" is set to 1.

4.8.1. Control of the size of transactions,

performed on the map (Floor Limit Checking)


This risk management procedure is designed to control the amount of funds that are spent on the card within a certain time (for example, per day or in one operation).

The terminal can keep a log file of transactions that stores information about the operations performed on the terminal. Each record that characterizes a certain transaction consists of at least the Application PAN card number, Application PAN Sequence Number, the transaction amount and the transaction date.

The number of transactions that the terminal can support in the log file is not regulated by the EMV specifications and is determined only by the capabilities of the terminal.

During the processing of the next transaction, the terminal selects records from the log file with the Application PAN and Application PAN Sequence Number values used in the operation in question. The selected records are used to summarize the fields corresponding to the transaction amount. The received amount is compared with the Terminal Floor Limit value set for this terminal by the servicing bank in accordance with the recommendations of the payment system. If the total received is greater than or equal to the Terminal Floor Limit, the terminal sets bit 8 of Byte 4 of TVR “Transaction exceeds floor limit” to 1.

If the terminal does not keep a log file, the size of the current transaction is compared with the Terminal Floor Limit value. If the transaction amount is greater than or equal to the Terminal Floor Limit, then the terminal sets bit 8 of byte 4 of TVR "Transaction exceeds floor limit" to 1.

Payment systems MasterCard and VISA establish control over the size of each transaction performed on the terminal. Payment systems determine the values of the limits for each type of merchant, called the International Floor Limit. These limits differ for transactions performed using magnetic stripe and chip. In the case when the transaction size exceeds the established limit, but the terminal processes the transaction in offline authorization mode, the service bank is responsible for possible fraud.

Serving banks can set on their terminals the values of the limits for offline operations (Terminal Floor Limit) below the corresponding values of the International Floor Limit.

4.8.2. Random selection of a transaction

In practice, small-value transactions are often performed in offline authorization mode. This mode of processing the transaction is less secure than online authorization of the transaction by the card issuer and may contribute to card fraud. For example, a stolen / lost / cloned card can be successfully used by fraudsters in offline mode, if the issuer did not manage to put such a card in the stop list and the transaction size is less than the Terminal Floor Limit value.

To avoid the case of performing all transactions for a small amount offline, a procedure is used to randomly select a transaction to perform its online authorization by the issuer. The procedure for randomly selecting a transaction is implemented for terminals like Offline terminal with online capabilities (for terminals like Online only it is meaningless, and for terminals like Offline only it is impossible).

On the terminal, this procedure is implemented as follows. For each application, the servicing bank, in addition to Terminal Floor Limit, defines the Target Percentage parameters (an integer that ranges from 0 to 99), Maximum Target Percentage (an integer that ranges from 0 to 99 and at the same time is not less than Target Percentage), Threshold Value (real number ranging from zero to Terminal Floor Limit).

For any transaction, the size of which is less than the Threshold Value, a random selection is made, regardless of the size of the transaction, and determines how the transaction is authorized. The terminal generates an integer random number in the range from 0 to 99. If this random number is less than or equal to the Target Percentage value, the transaction is performed in real time. Otherwise - offline.

For a transaction whose size is equal to or greater than the Threshold Value, but less than the Terminal Floor Limit, the transaction size is taken into account in such a way that the larger it is, the more likely the transaction will be processed in real time. For such transactions, the terminal must compare the generated random number with the Transaction Target Percentage value, which is calculated using the following formula:

Transaction Target Percentage -

Maximum Target Percentage

Target
j Interpolation Target

Percentage J Factor Percentage

Transaction Size - Threshold Value

Interpolation Factor = --------—----------------———-—

Terminal Floor Limit - Threshold Value


If the generated number is less than or equal to the Transaction Target Percentage, the transaction is executed in real time. Otherwise - offline.

The graph of the probability of choosing a transaction for online authorization depending on the amount of the transaction is shown in Fig. 4.3.

50.png

Limit

Rice. 4.3. Graph of the probability of choosing a transaction for online authorization

If the transaction is performed in real time according to the described procedure, then the terminal must set bit 5 in byte 4 of TVR "Transaction Selected randomly for online processing" equal to 1.

4.8.3. Checking offline activity of card use (Velocity Checking)

The procedure for verifying the offline activity of the card by the terminal is designed to combat possible fraudulent activities involving small amounts of money related to offline transactions.

If the card was used to perform a certain number of sequential offline operations, the value of which is determined by the issuer in the Lower Consecutive Offline Limit (Tag '9F14') parameter, then the terminal must conduct the next transaction on this card in real time, if, of course, the terminal is capable of performing a transaction in real time.

If the terminal for some reason cannot perform an operation in real time (for example, an Offline only terminal), then the next transaction, despite exceeding the Lower Consecutive Offline Limit, can still be performed offline until reaching the second one set by the issuer Upper Consecutive Offline Limit (Tag '9F23'). The value of this limit is not less than the value of the Lower Consecutive Offline Limit.

If the number of offline transactions exceeds the Upper Consecutive Offline Limit, then the terminal must either complete this transaction in real time, or reject it if it is unable to process the transaction online.

Once the transaction has been completed in real time, the card is again able to process subsequent transactions offline until the number of consecutive offline transactions exceeds the Lower Consecutive Offline Limit.

For the terminal to apply the above procedure, the Lower Consecutive Offline Limit and Upper Consecutive Offline Limit must be mapped to the map during the personalization process and referenced in AFL.

The procedure also uses the parameters previously encountered PBX card (Tag '9F36') and LATC (Last Online Application Transaction Counter, Tag '9F13') - LATC data element represents the number of the last onlay new transaction. To get the current values of these parameters, the terminal must send two GET DATA commands to the card with the P1P2 parameters in the C-APDU equal to '9F36'h (to get the ATC value) and' 9F13'h (to get the LATC value).

Then the terminal acts in accordance with the following algorithm.
  • 1. From the data objects read by the terminal, the values of the Lower Consecutive Offline Limit (Tag '9F14') and Upper Consecutive Offline Limit (Tag '9F23') are retrieved - If at least one of the specified objects is missing, the procedure for checking the offline activity of the card ends.
  • 2. The terminal sends two GET DATA commands to the card with the P1P2 parameters in the C-APDU equal to '9F36'h (to get the ATC value) and' 9F13'h (to get the LATC value). If the SW1SW2 value of at least one R-APDU response is not equal to '9000T1, the following settings are performed:
    • Bit 7 of Byte 4 TVR "Lower Consecutive Limit Exceeded" is set to 1;
    • Bit 6 of Byte 4 TVR "Upper Consecutive Limit Exceeded" is set to 1.
  • 3. If SW1SW2 in both R-APDU responses is' 9000'h, Z = ATC-LATC is computed, which is the number of consecutive offline transactions performed since the last online transaction, including the current transaction being processed.
  • 4. If Z> Lower Consecutive Limit, then bit 7 of Byte 4 of TVR "Lower Consecutive Limit Exceeded" is set to 1.
  • 5. If Z> Upper Consecutive Limit, then bit 6 of Byte 4 of TVR "Upper Consecutive Limit Exceeded" is set to 1.
  • 6. If LATC = 0, then bit 4 of Byte 2 TVR "New Card" is set to 1.
 
Top