EMV L2 (11) — Card Behavior Analysis

Card behavior analysis purpose: The IC card can perform its own risk management to prevent the issuer from being exposed to fraud or excessive credit risk. The detailed internal risk management performed by the IC card is determined by the issuer.

Card Behavior Analysis allows the issuer to carry out internal card risk management, such as frequency checking.

The risk management in this step includes:

• Checking the previous transaction behavior
• New card checking
• Frequency counter checking

When the card receives a request for an Application Cryptogram (AC) from the terminal, the card executes its internal risk management checks to decide whether to modify the transaction processing as determined by the terminal.

These checks may include:

• Incomplete previous online transactions
• Previous transaction issuer authentication failure or offline data authentication failure
• Exceeding the transaction count or amount limit, etc.

After completing these checks, the card uses application data and an application cryptogram generation key stored within the card to generate the Application Cryptogram. It then returns the cryptogram to the terminal. This step is executed inside the IC card.

Through risk management, the IC card can decide whether the transaction should be completed online, offline, require a referral, or be declined. The IC card may also send a notification message to the issuer.

The decision of whether the transaction is online or offline is determined in the card’s response to the GENERATE AC command sent by the terminal.

The ICC replies to the terminal’s GENERATE AC command with one of the following cryptogram types as a result of card risk management: AAC, TC, or ARQC.

• AAC (Application Authentication Cryptogram) — Transaction declined
• ARQC (Authorization Request Cryptogram) — Online authorization requested
• TC (Transaction Certificate) — Offline approved

The card’s risk management results determine whether the terminal should perform one of the following actions:

• Approve the offline transaction (only valid if the terminal initially decided that the transaction could be completed offline)
• Complete the transaction online;
• Request authorization referral
• Decline the transaction

The IC card notifies the terminal of its decision through the response to the GENERATE APPLICATION CRYPTOGRAM (GAC) command, returning TC, AAC, or ARQC.

After the Card Action Analysis function is completed, the terminal sets the Card Risk Management was performed bit in the TSI (Terminal Status Information) to 1.

Terminal GAC Requests

There are three types of requests:

• AAC (Application Authentication Cryptogram)
• ARQC (Authorization Request Cryptogram)
• TC (Transaction Certificate)

The GAC command is not TLV-encoded. The IC card defines the required data through CDOL (Card Risk Management Data Object List).

• CDOL (Card Risk Management Data Object List): The terminal uses current data (as specified in the CDOL by the IC card) to build the GAC command and send transaction data to the card for processing.
• TDOL (Transaction Certificate Data Object List): Used by the terminal to generate the TC hash value in response to the CDOL requirement.

If TDOL is used, the terminal should set the corresponding TVR bits.

For each GAC command, the terminal must ensure the TC hash value is up to date.

First GAC: Determines online/offline processing.

• TC → TC or ARQC or AAC
• ARQC → ARQC or AAC
• AAC → AAC

Second GAC: Requests TC.

• The IC card may return TC or AAC.
• If the terminal requests AAC, the IC card will return an AAC.

The IC card allows up to two GENERATE AC commands.

For any additional GAC requests beyond the second, the IC card returns SW1 SW2 = 6985 and no cryptogram.

Terminal Processing of Card Analysis Results

The terminal’s transaction assessment is not final — it must obtain the card’s evaluation through the GENERATE AC command.

The terminal requests the corresponding Application Cryptogram (AC) according to its own preliminary decision and provides the terminal data specified in CDOL1 to the card.

The card evaluates the transaction using the provided data and terminal decision, performs card verification, and returns the corresponding AC.

Depending on the cryptogram requested by the terminal, the card may return different processing results.

If CDOL1 includes a Transaction Certificate Data Object List (TDOL), the terminal must process the TDOL and calculate the hash result.

If the card does not contain TDOL data, the terminal uses a default empty TDOL for the calculation.

If the transaction requires Combined Dynamic Data Authentication (CDA) and the card decides to return TC or ARQC, the terminal must perform CDA verification after receiving the signed data from the GENERATE AC command.

Preceding Related Processing

Preceding processing includes:

• Reading application data: The terminal reads the Card Risk Management Data Object List 1 (CDOL1) from the card.
• Terminal Action Analysis: Based on the result of Terminal Action Analysis, the terminal requests the appropriate AC from the card and provides the terminal data specified in CDOL1.

Subsequent Related Processing

Subsequent processing includes:

• Online Processing: If the card returns ARQC, the terminal sends an online authorization message to the host, including the ARQC.
• Transaction Completion.

If online processing is required but the terminal cannot go online, it performs additional terminal and card processing.

The terminal uses the Issuer Action Code — Default (IAC-Default) and Terminal Action Code — Default (TAC-Default) to conduct additional analysis (similar to Terminal Action Analysis) to determine the type of cryptogram to request in the second GENERATE AC command (either AAC or TC).