Cashless Nomad

Cashless Future: Building Reliable Payment Systems.

,

EMV Cryptograms Explained: ARQC, TC, and AAC Made Simple

ASSI Avatar
ASSI

I want to talk to you about something that confused me a lot back when I first started working with EMV transactions. If you are like me, when you hear the word cryptogram, it feels like something advanced or very deep. But once I actually saw how this is used in real payment flows, I realized it is not as complicated as it sounds.

So today I want to walk you through ARQC, TC, and AAC. These three cryptograms control the whole decision making inside an EMV transaction. If you understand these three, you can explain to anyone how a card decides if a transaction will continue online, approve offline, or get declined.

I will try to make this simple and personal, almost like we are sitting in a small meeting room or coffee shop and I am explaining based on real situations I handled in projects.

Let us start from the basics.

What is a Cryptogram in EMV

Before I dive into ARQC, TC, and AAC, let me explain cryptogram in the simplest way I can. A cryptogram is basically a small encrypted value generated by the card. This value contains information about the transaction and what the card thinks should happen next.

When you tap or insert a card, the terminal sends a set of data to the card, things like amount, terminal country, transaction date, unpredictable number, terminal capabilities, and so on. The card takes all this and generates a cryptogram.

Think of a cryptogram like the card saying: “I checked everything. Here is what I think. Please follow this.”

The terminal then reads the cryptogram type and continues the process. It feels almost like the card is the boss of the first half of the EMV flow.

And that is why understanding cryptograms is very important if you work with EMV.

Quick overview of the three cryptograms

Just to give you the high level picture.

ARQC means Authorization Request Cryptogram. When the card returns this, it is basically saying the terminal must go online and ask the issuer if the transaction is allowed.

TC means Transaction Certificate. When the card returns this, it is approving the transaction offline. This means the card is confident that the transaction is valid even without talking to the issuer.

AAC means Application Authentication Cryptogram. This means the card is declining the transaction.

One thing I learned early is that these three values control the whole flow. If you understand them, the entire EMV sequence becomes easier.

Now let us go deeper for each one.

ARQC: The card wants to go online

In my first real EMV project, ARQC was the one I needed to understand the most because most transactions in the real world are online. Even when offline approval is allowed, issuers still prefer online authorization for better risk checking.

So what exactly is ARQC?

When a card generates an ARQC, it means the card wants an online authorization. It tells the terminal to prepare an ISO message and send it to the acquirer or issuer.

Here is why ARQC happens:

  • Terminal online capability is available
  • Card or issuer requires online risk checking
  • Cardholder verification fails and needs online authentication
  • Amount is above the offline limit
  • Terminal risk management triggered something
  • Issuer script or previous transactions require online processing

Let me share a real situation from a project. We had a terminal that always returned ARQC even for small transactions. It turned out the terminal had a low offline transaction limit configured. So even a small purchase like 100 pesos caused online processing. That was a big learning for me that offline settings are very sensitive.

A sample representation of ARQC might look like this:

Plaintext
9F26: 98 3A 2D 11 7C 00 45 E8   ARQC

That value is computed using card keys, unpredictable number, transaction data, and more. You do not manually compute it. The card does it.

Once the terminal receives ARQC, it sends the ISO 8583 authorization request. The issuer then sends back an ARPC, which is the issuer response cryptogram. This confirms if the issuer accepts or declines the transaction.

What surprised me when I first saw it is that the card checks the ARPC too. If the ARPC is invalid, the card will decline. So both sides validate each other.

TC: Offline approval

This one is interesting. The Transaction Certificate means the card is approving the transaction offline. No need to go online.

I used to think only online approvals are safe. But EMV supports strong offline verification. Smart cards are powerful and they can check risk controls without internet connection.

Why does the card return TC?

  • Amount is small and under the offline approval limit
  • Card’s offline counters still allow approval
  • Terminal is offline but allowed to approve transactions
  • Issuer personalization supports offline approvals

One of the common mistakes I saw in projects is people thinking TC means the terminal must finalize the sale immediately. Actually the terminal still needs to consider its own risk management. Sometimes a terminal blocks offline approvals even though the card is ok.

A card generates a TC like this:

Plaintext
9F26: 3B 72 41 10 6F 22 18 A1   TC

Terminal receives the TC, wraps up the transaction, prints the receipt, and it is good.

One thing I always remind junior developers: TC is final. You cannot change a TC into ARQC. Once card approves, the terminal accepts.

AAC: Offline decline

AAC is the painful one. If you ever tested EMV certification, you probably saw AAC many times. AAC means the card is declining the transaction offline. The card is basically telling the terminal to stop. Do not go online. Do not ask the issuer. The card already decided no.

Reasons why the card generates AAC:

  • Offline data authentication failed
  • Cardholder verification failed
  • Offline counters exceeded
  • Risk management says this is risky
  • Card profile does not allow offline approval
  • Required data missing or incorrect

I remember during one of our L3 certifications, we kept getting AAC on a specific Amex test case. After spending hours, we found out the card did not accept our unpredictable number value because the format was wrong. The moment we fixed the unpredictable number generation, the card started returning ARQC instead.

AAC looks something like this:

Plaintext
9F26: 57 11 4F 01 90 65 C2 00   AAC

Once the terminal sees AAC, the transaction is declined and the flow stops.

How cryptograms flow in a real transaction

Let me summarize the flow in a simple way you can imagine.

  • Terminal sends GPO command to the card
  • Card returns AIP and AFL
  • Terminal reads the records
  • Terminal performs risk checks
  • Terminal sends GENERATE AC command
  • Card returns ARQC or TC or AAC

If ARQC

  • Terminal builds ISO message
  • Issuer responds with ARPC
  • Terminal sends GENERATE AC again with issuer data
  • Card returns TC or AAC
  • Transaction ends

If TC

  • Terminal approves offline

If AAC

  • Terminal declines offline

Once you see this structure, EMV starts to look logical.

A small coding example

This is optional but I want to include something simple in case you work with EMV parsing. Below is a very simple pseudo C sharp code for reading the cryptogram tag from EMV data.

C#
public string GetCryptogramType(byte[] TLVData)
{
    var tlv = ParseTlv(TLVData);
    var cryptogramType = tlv["9F27"];   // Cryptogram Information Data

    if(cryptogramType == "80") return "AAC";
    if(cryptogramType == "40") return "TC";
    if(cryptogramType == "80") return "ARQC";  // Example only

    return "Unknown";
}

This is only to give you an idea. You usually rely on EMV library for production systems, but understanding this helps a lot especially during debugging.

Why this matters in real projects

When you are debugging a transaction, the fastest way to know what happened is by looking at the cryptogram.

Example scenarios:

  • Terminal reports offline declined. Check if cryptogram was AAC
  • Issuer says card was approved but terminal declined. Check if card returned AAC before going online
  • Transaction took very long. Check if ARQC was returned and how long issuer responded

I use this technique every time I troubleshoot issues with acquirers and gateways.

Final words

I know cryptograms sound intimidating at first. The name alone looks heavy. But once you see how they move inside a transaction, it becomes very logical.

  • ARQC means go online
  • TC means approve offline
  • AAC means decline offline

If you remember that simple rule, you can analyze almost any EMV issue. I hope this post helped you understand cryptograms in a more personal and simple way. If you want me to write something similar about IAC, TVR, TSI, or offline data authentication, feel free to tell me.

References and suggested reading

These helped me a lot over the years.

  • EMV Book 2: Security and Key Management
  • EMV Book 3: Application Specification
  • EMVCo Website
  • Visa Integrated Circuit Card Specifications
  • Mastercard MChip Specifications
  • Amex AEIPS Specifications

More Articles & Posts