Kernel 2 vs Kernel 3: Mastercard and Visa Contactless Compared

Mastercard's Kernel 2 and Visa's Kernel 3 process most contactless card payments in the world. Both are EMV contactless kernels, both run under the same Entry Point, and both end with an approve, decline or online outcome. Under the hood, though, they take very different routes. Knowing those differences saves a lot of time when you integrate, certify or debug a reader.

The short version

How a Kernel 2 transaction runs

1. SELECT and GET PROCESSING OPTIONS. The card returns its AIP and AFL. No cryptogram yet.
2. Relay resistance, if both sides support it: the reader times an EXCHANGE RELAY RESISTANCE DATA command.
3. READ RECORD for every record in the AFL, including the certificates needed for CDA.
4. Processing restrictions, CVM selection and terminal risk management, much like a contact transaction. The kernel compares the amount with limits it holds in its own configuration (DF8123 to DF8126).
5. Terminal action analysis: the TVR is compared with the IACs and TACs to choose TC, ARQC or AAC. Kernel 3 has no equivalent step.
6. GENERATE AC, usually with a CDA signature request. The kernel checks the signature after the card has left the field.
7. Outcome: the kernel reports the result in the Outcome Parameter Set (DF8129), with a Data Record and Discretionary Data.

How a Kernel 3 transaction runs

1. Entry Point pre-processing. Before the card is even tapped, the reader compares the amount with its contactless limits and sets bits in the Terminal Transaction Qualifiers (9F66), such as "online cryptogram required" or "CVM required".
2. SELECT. The card asks for the TTQ and transaction data in its PDOL.
3. GET PROCESSING OPTIONS. This is where Kernel 3 differs most. The card makes its decision and generates the cryptogram right away, and returns it with the CID, ATC, Issuer Application Data and Card Transaction Qualifiers (9F6C).
4. READ RECORD for the remaining data, such as the PAN, expiry date and the data needed for fDDA.
5. Offline checks. For an offline approval, the reader verifies the fDDA signature and checks items such as expiry and exception files.
6. CVM. The reader combines its TTQ with the card's CTQ to decide between online PIN, signature, consumer device CVM or no CVM.
7. Outcome. Approve, decline or online, based mainly on the cryptogram type the card returned.

Because the cryptogram comes back so early, a Kernel 3 tap can be very short. The card only needs to stay in the field for SELECT, GPO and a few READ RECORD commands.

What this means for developers

Different places to look

In Kernel 2 logs, look at the GENERATE AC exchange for the cryptogram and at DF8129 and DF8115 for the outcome and errors. In Kernel 3 logs, the cryptogram is in the GPO response, and the TTQ and CTQ explain most CVM and online decisions.

The TVR: used by Kernel 2, not by Kernel 3

Kernel 2 builds a full TVR and uses it in terminal action analysis, with byte 5 bits 4 to 1 reporting relay resistance. Kernel 3 does not use the TVR at all: the card has already decided and returned its cryptogram in the GPO response, so there is no terminal action analysis. The reader's requirements are carried in the TTQ and the card's in the CTQ. If a Kernel 3 log shows a TVR, do not use it to explain the outcome.

Different configuration

A Kernel 2 reader needs a full kernel configuration: action codes, capabilities, limits with and without on-device CVM, timers and relay resistance settings. Kernel 3 relies more on the Entry Point configuration: reader limits per AID and kernel, and the TTQ value. Getting the TTQ wrong is one of the most common causes of failed Visa test cases.

Different CVM logic

Kernel 2 processes the card's CVM List like a contact transaction, with special handling for on-device CVM on phones and wearables. Kernel 3 has no CVM List processing for qVSDC; the CTQ tells the reader what the card requires, for example online PIN above a limit, or that the consumer device already verified the cardholder.

Common integration problems

• Kernel 2: the card is removed before GENERATE AC completes, which triggers torn transaction recovery; CDA signature failures from a wrong CA public key index; action codes that send every transaction online.
• Kernel 3: a TTQ that does not match the reader's real capabilities; limits set at the wrong level so the "CVM required" or "online cryptogram required" bits are wrong; fDDA failures on offline transactions from a missing or wrong CA public key.
• Both: sending field 55 tags that differ from the values given to the card, which makes the issuer's cryptogram check fail.

Frequently asked questions

Can one reader support both kernels?

Yes, and almost every contactless terminal does. The Entry Point selects the kernel from the AID and kernel identifier: 02 for Kernel 2 and 03 for Kernel 3.

What happened to mag-stripe mode and MSD?

Both kernels once supported a legacy mode that sent track data instead of an EMV cryptogram: mag-stripe mode for Kernel 2 and MSD for Visa. Both schemes have been retiring these modes in favour of the EMV paths, so check the current scheme requirements for your region.

Which kernel is faster?

Kernel 3 usually needs less time in the field because the cryptogram arrives in the GPO response. Kernel 2 does more work while the card is present, especially with relay resistance and CDA, but both are designed to finish within typical tap times.

Where does Kernel 8 fit?

Kernel 8 is EMVCo's common kernel, which any scheme can use. It runs next to Kernel 2 and Kernel 3 rather than replacing them right away. See EMV Kernel 8 Explained.