Contactless in 300ms: Kernels, the TTQ, and the Tap

💡 TL;DR (Too Long; Didn't Read)

The tap, in 90 seconds:

Contactless has a latency budget — the card is in the field for a few hundred milliseconds — so EMV contactless front-loads decisions the contact flow makes leisurely.

Selection is different: the reader sends PPSE (2PAY.SYS.DDF01), the card returns a list of combinations (AID + kernel), and the reader picks one and activates that kernel.

There are six scheme kernels (Kernel 2 Mastercard through Kernel 7 UnionPay), plus the new unified C-8 kernel consolidating them, each with its own flow. The AID is not enough; the kernel ID decides which rulebook runs.

The Terminal Transaction Qualifiers (tag 9F66, 4 bytes) are the reader announcing its capabilities and demands — online required, CVM required, on-device CVM allowed — and the card answers with the Card Transaction Qualifiers (9F6C).

Everything you learned about the contact flow still applies underneath; contactless is that flow with a stopwatch and a kernel in front of it.

In the first part of this series I traced a contact EMV transaction — the dip — because it is synchronous and unhurried: the card sits in the reader and the terminal takes its time. The tap is the same protocol under a stopwatch. A contactless card or phone is only coupled to the reader's field for a few hundred milliseconds, sometimes less, and in that window the whole authentication and decision dance has to complete or the cardholder has to tap again. Everything EMV contactless does that looks strange is a consequence of that budget. This is a guide to the fast path — how the reader selects a kernel, what the Terminal Transaction Qualifiers say, and why a tap sometimes still sends you online. It follows the EMVCo Contactless Specifications (Books A–D and the kernel books C-1 through C-8); I cite the structure, not the spec text.

Selection is a negotiation, not a lookup

A contact card is selected with the PSE or a straight AID SELECT. Contactless replaces that with the Proximity Payment System Environment: the reader selects 2PAY.SYS.DDF01 and the card returns a PPSE response listing its supported combinations. A combination is not just an AID — it is an AID paired with a kernel identifier and an application priority. The reader intersects the card's combinations with its own supported combinations, applies priority, and picks one. Only then does it SELECT the chosen AID and hand control to the matching kernel.

This matters because a single card can present, say, a Mastercard AID that runs under Kernel 2 and, on some products, more than one entry. The reader is choosing a rulebook, not just an application. Get the combination selection wrong — pick a kernel the reader implements poorly, or mis-rank priority — and you get taps that work on one terminal and fail on the next with the same card. Combination selection is where "it works on my reader" bugs are born.

The six kernels

Once a combination is chosen, the transaction runs the selected kernel's flow. The scheme kernels are, in the EMVCo numbering (Books C-2 through C-7; there is no scheme "Kernel 1" — that slot is the Entry Point):

Kernel 2 — Mastercard (PayPass / M/Chip). Its own EMV-mode flow with torn-transaction recovery and a distinctive data-exchange model.
Kernel 3 — Visa (payWave / qVSDC and MSD).
Kernel 4 — American Express (Expresspay).
Kernel 5 — JCB (J/Speedy).
Kernel 6 — Discover (D-PAS).
Kernel 7 — UnionPay (QuickPass).

And arriving now: Kernel C-8 — EMVCo's unified contactless kernel, a single rulebook intended to replace the per-scheme kernels and cut the testing and certification matrix that the six separate books created. The migration will be gradual; terminals will carry both for years. If you are tracking the current installed base you reason about Kernels 2–7; if you are planning new terminal software, C-8 is the consolidation you are designing toward.

They share EMV's vocabulary — AIP, AFL, GENERATE AC, cryptograms — but differ in the details that fit inside the tap budget: how many command round-trips they use, whether they read records before or after the cryptogram, how they signal online-vs-offline, and how they handle the two contactless modes. The two modes worth knowing: MSD (Magnetic-Stripe Data — a legacy mode that emulates track data over contactless, now largely retired) and the EMV mode (qVSDC for Visa, M/Chip for Mastercard) that produces a real cryptogram. New work is EMV-mode only; if you are still reasoning about MSD, you are maintaining the past.

The Terminal Transaction Qualifiers (tag 9F66)

The single most useful data object to be able to read on the contactless fast path is the Terminal Transaction Qualifiers, tag 9F66, four bytes. The reader ships it to the card (typically inside the GPO's PDOL data) to announce, up front, what kind of reader I am and what I will require. The card reads it and shapes its response — including whether it insists on going online.

Here is the map of the bits that actually drive behavior (EMVCo Book C-3 / Visa contactless):

Byte 1 is capabilities and demands. b8 MSD supported; b6 qVSDC supported; b5 EMV contact chip supported; b4 offline-only reader; b3 online PIN supported; b2 signature supported; b1 offline data authentication for online authorizations supported. Byte 2: b8 online cryptogram required (the reader wants an ARQC no matter what); b7 CVM required (this transaction is above the no-CVM limit and needs a cardholder verification); b6 offline PIN supported. Byte 3: b8 issuer update processing supported; b7 consumer device CVM (CDCVM) supported — the reader accepts that the phone verified the cardholder. Byte 4 is reserved in most profiles.

Read those bits and a tap stops being mysterious. A low-value tap at a reader whose TTQ has "CVM required" clear and "online cryptogram required" clear can be approved offline with no PIN — that is the sub-limit contactless experience. Push the amount over the reader's CVM limit and the reader sets CVM required (byte 2 b7); now the card must satisfy a cardholder verification, which on a phone means CDCVM and on a card usually means going online for online PIN. Set online cryptogram required (byte 2 b8) — as transit gates and high-value readers do — and every tap produces an ARQC. The TTQ is the reader's personality encoded in four bytes.

The Card Transaction Qualifiers (tag 9F6C)

The card answers with its own qualifiers where the kernel uses them — the Card Transaction Qualifiers, tag 9F6C (prominent in Visa qVSDC and Mastercard flows). The CTQ carries the card's side: whether online PIN is required, whether signature is required, whether CDCVM was performed, and whether to go online. The CDCVM bit is the important one for the modern experience: when you tap a phone that just checked your face or fingerprint, the wallet sets the CDCVM-performed indicator, and the reader — if its TTQ said it supports CDCVM — accepts that as the cardholder verification and does not prompt for anything. That handshake, TTQ "CDCVM supported" meeting CTQ "CDCVM performed," is why tapping a phone for a large amount just works while tapping a card for the same amount asks for a PIN.

On-device CVM and the death of the signature

The cardholder verification story on contactless is where the tap earns its convenience, and it is worth being precise about the three outcomes. No CVM: below the reader's CVM-required limit, the tap approves without verification — this is the tap-and-go path, bounded by per-transaction and cumulative limits the acquirer configures. CDCVM: on a consumer device, the device verifies the cardholder locally (biometric or device passcode) and asserts it in the CTQ; the reader trusts the assertion. Online PIN: on a card above the CVM limit, the reader collects the PIN, enciphers it, and sends it online for the issuer to verify — because a plain card has no way to do local biometric verification.

Signature, the fourth theoretical option, is effectively dead on contactless and dying everywhere; the CVM Lists that still carry it are legacy. If you are designing new acceptance, design for no-CVM below limit, CDCVM for devices, and online PIN as the card fallback — and treat signature as something you tolerate on old cards, not something you build toward.

The relay problem and relay resistance

The tap budget creates a specific attack surface: relay. Because the card only needs to be near a field, an attacker can put a reader near the victim's card and a card-emulator near a real terminal, relaying messages between them over a network, so the victim's card pays for the attacker's transaction from across the room. EMVCo's answer is the Relay Resistance Protocol (RRP): the kernel measures the round-trip time of a dedicated EXCHANGE RELAY RESISTANCE DATA command against timing bounds the card provides, and if the measured time exceeds the card's declared maximum — as a network relay inevitably does — the transaction is flagged or declined. Not every kernel and card pair supports RRP yet, but it is the structural fix, and if you work on reader firmware it is the timing budget you must not blow.

Battle scars

The AID is not the kernel. Two readers can select the same Mastercard AID and behave differently because they activated different kernel versions or configurations. When a card works at terminal A and fails at terminal B, compare the combination and kernel each selected, not just the AID. The PPSE exchange is the first thing to capture.

The TTQ is configuration, and wrong configuration is a fraud limit. A reader whose TTQ never sets "online cryptogram required" and never sets "CVM required" will approve everything offline with no verification — which is either exactly what a low-value unattended kiosk wants or a serious exposure on a high-value terminal. Treat the TTQ bytes as security policy and review them per deployment, not as a factory default you inherit.

CDCVM support is a two-sided handshake. A phone can perform CDCVM all it likes; if the reader's TTQ does not advertise CDCVM support, the reader ignores the CTQ assertion and falls back to online PIN or decline. "Why does my phone get prompted for PIN on this terminal?" almost always resolves to the reader not advertising CDCVM support, not the wallet failing to assert it.

Where this fits

Contactless is the contact flow you already know — selection, AIP/AFL, records, the cryptogram, the TVR decision — run under a latency budget with a kernel and the TTQ in front. The tags are the same tags; you can resolve 9F66 (TTQ) and 9F6C (CTQ) in the same EMV Tag Dictionary you have been using all along. The next tap you debug, capture the PPSE and read the qualifiers first; nine times in ten the answer is in those bytes.

What Actually Happens When You Dip a Chip: The EMV Transaction Flow End-to-End — the contact flow contactless compresses.
The TVR, the TSI, and How a Terminal Decides to Decline You — the decision engine a tap still runs.
PIX, BR Code, and the EMVCo MPM — the other tap-free contactless-adjacent rail.

Tools: decode the qualifiers on their tag pages — 9F66 (TTQ), 9F6C (CTQ), 82 (AIP) — in the EMV Tag Dictionary.

Filed under: EMV · Contactless · Payments · POS · Acquiring

This article was human-architected and synthesized with AI assistance under the Nexus (AI) persona.