How EMV Actually Works

EMV is the reason chip cards changed card fraud economics. It did not make card fraud disappear. It changed which attacks were cheap, which attacks required issuer or terminal mistakes, and which evidence could be used to decide liability.

Before chip, many card-present transactions relied on magnetic stripe data. That data was mostly static. If an attacker copied it, they could often create a counterfeit stripe card. EMV moved card-present payments toward chips that participate in a transaction protocol, apply issuer-defined rules, and generate cryptographic evidence for each transaction.

This article explains how EMV actually works. We will cover application selection, APDU exchange, AIP and AFL, application records, offline data authentication, SDA, DDA, CDA, cardholder verification, terminal risk management, terminal action analysis, ARQC, TC, AAC, issuer scripts, online authorisation, fallback, contactless differences, and why chip cards shifted fraud from counterfeit card-present attacks toward weaker channels such as e-commerce and social engineering.

EMV Is a Protocol Between Card and Terminal

EMV is not only a chip on a card. It is a set of specifications for how a payment card and terminal interact.

The terminal needs to answer several questions:

• which payment application should run?
• what card data should be read?
• what checks does the card require?
• how should the cardholder be verified?
• is offline approval allowed?
• should the transaction go online to the issuer?
• what cryptographic proof did the card generate?
• did the issuer return scripts to update the card?

The card is not a passive storage device. It stores payment applications, risk parameters, keys, counters, records, and logic. The terminal drives the conversation by sending APDU commands. The card responds with data and cryptograms.

The issuer configures much of the card's behaviour during personalisation. The terminal configures its own risk and capability profile. The final transaction outcome is produced by the interaction between those configurations and the transaction context.

The Terminal Starts With Application Selection

An EMV card may contain multiple applications. The terminal must choose one.

Each application has an application identifier, or AID. The terminal maintains a list of supported AIDs. During application selection, the terminal and card build a candidate list and choose the application according to priority and rules.

For example, a card may support:

domestic debit application
international debit application
international credit application

The terminal may support some or all of them. The selected application can affect routing, fees, cardholder verification, and risk logic.

Application selection can be explicit or automatic. If more than one application is available and rules allow choice, the terminal may ask the customer to select debit or credit. In many retail flows, the terminal chooses based on priority configuration.

This step matters because everything later depends on the selected application's data and rules.

APDUs Carry the EMV Conversation

The terminal communicates with the chip using APDUs.

A simplified contact transaction starts like this:

SELECT application
GET PROCESSING OPTIONS
READ RECORD
READ RECORD
GENERATE AC

The card returns status words and data. A success response often ends in 9000. Other status words indicate conditions such as missing file, unsupported command, or conditions not satisfied.

EMV data is encoded in TLV form, tag-length-value. A terminal parses tags such as:

9F02 amount authorised
5F2A transaction currency code
95 terminal verification results
82 application interchange profile
94 application file locator
9F26 application cryptogram
9F10 issuer application data

The tag structure lets different cards and terminals exchange rich data without relying on one fixed flat record.

GET PROCESSING OPTIONS Returns AIP and AFL

After selecting the application, the terminal sends GET PROCESSING OPTIONS.

The card returns the application interchange profile, AIP, and application file locator, AFL.

The AIP tells the terminal which features the card application supports or expects, such as:

• offline data authentication support
• cardholder verification support
• terminal risk management relevance
• issuer authentication support
• combined DDA and application cryptogram support

The AFL tells the terminal which application records to read. It is effectively a map:

read these records from these files

The terminal then sends READ RECORD commands according to the AFL. Those records contain data needed for the transaction.

This design lets the card define which data is relevant for its application. The terminal does not blindly read a universal fixed layout.

Application Records Contain Card Data and Rules

The records read through the AFL may contain:

• PAN or tokenised equivalent
• expiry date
• application label
• cardholder verification method list
• application usage controls
• issuer public key certificate data
• card public key certificate data
• static data authentication tags
• issuer action codes
• application transaction counter
• offline limits or counters
• issuer application data

Some data is visible to the terminal. Some is used in cryptographic verification. Some is later included in issuer authorisation.

Application usage controls can restrict where and how the card application may be used. A card might allow domestic cash withdrawal but restrict certain international uses. The terminal checks those controls against transaction context.

The CVM list tells the terminal how to verify the cardholder. Issuer action codes tell terminal action analysis how to behave when certain risk bits are present.

The chip therefore carries a policy package, not only an account number.

Offline Data Authentication Detects Counterfeit Data

Offline data authentication lets the terminal verify that card data was signed by the issuer and, in stronger modes, that the chip can perform dynamic cryptographic operations.

There are three major concepts:

• SDA, static data authentication
• DDA, dynamic data authentication
• CDA, combined dynamic data authentication and application cryptogram

SDA verifies signed static data. It protects against simple modification of card records, but a counterfeit card that copies valid static data can still be a problem if the terminal relies only on SDA.

DDA asks the card to sign unpredictable transaction data using a card private key. This proves the card has a private key corresponding to certified public key data, making simple cloning much harder.

CDA combines dynamic authentication with application cryptogram generation, binding card authentication more tightly to the transaction outcome.

Offline data authentication matters most when terminals approve offline or need counterfeit detection before going online. Even in online transactions, its results can feed terminal verification and issuer decisions.

The EMV Public Key Chain Starts With Scheme Keys

Offline data authentication relies on a certificate chain.

At a simplified level:

scheme public key
  verifies issuer public key certificate
issuer public key
  verifies card public key certificate or signed static data
card public key
  verifies dynamic card signature

The terminal stores scheme public keys. These keys expire and must be maintained. If terminal key tables are stale, legitimate cards may fail or weaker fallback may occur.

This is one reason terminal estate management matters. EMV security depends not only on card chips, but also on terminals having current public keys, correct kernel behaviour, and valid scheme configuration.

SDA Was an Improvement but Had Limits

SDA signs static application data. The terminal verifies that certain card data came from the issuer and was not modified.

The limitation is in the word static. If an attacker can copy the static data into a counterfeit chip-like device and the terminal does not require dynamic proof, SDA alone may not stop all counterfeit scenarios.

This is why DDA and CDA became important. They require the card to participate with fresh cryptographic output.

SDA still represented an improvement over magnetic stripe because card data could be authenticated against issuer signatures. But it was not the strongest possible model.

DDA Proves the Card Can Sign Fresh Data

DDA adds dynamic authentication.

The terminal sends unpredictable data. The card signs it using a private key stored in the chip. The terminal verifies the signature using the card public key certified by the issuer.

This means a cloned copy of static card records is not enough. The attacker would need the card private key, which should be protected inside the chip.

DDA helps detect counterfeit cards in offline-capable environments. It also improves issuer and terminal confidence that the transaction came from a genuine chip rather than copied records.

The terminal's random or unpredictable number quality matters. Weak unpredictability can undermine protocols that rely on freshness.

CDA Binds Authentication to the Transaction Cryptogram

CDA combines dynamic authentication with application cryptogram generation.

Instead of proving the card is genuine in one step and producing transaction outcome evidence in another independent step, CDA binds dynamic card authentication to the cryptogram process.

This helps protect against attacks that try to manipulate transaction flow or cryptogram outcome after authentication.

For practical purposes, CDA is a stronger offline authentication mode than SDA and DDA alone. Contactless profiles often rely on dynamic cryptographic behaviour suited to fast transactions.

The details are intricate, but the engineering lesson is simple: EMV evolved from static proof toward transaction-bound dynamic proof because static data alone is not enough for a hostile retail environment.

Cardholder Verification Uses a CVM List

The card contains a cardholder verification method list. The terminal evaluates it against its own capabilities and the transaction conditions.

CVM options can include:

• offline PIN
• online PIN
• signature
• no CVM
• fail CVM processing

The CVM list is ordered with conditions. A condition might apply only above a certain amount, at certain terminal types, or for cash transactions.

Example logic:

if unattended cash:
    online PIN required
if purchase under contactless limit:
    no CVM allowed
if terminal supports online PIN:
    online PIN
else:
    signature or decline depending on rules

The CVM result is recorded in terminal data and can affect authorisation and liability.

Mobile wallets add CDCVM, where the consumer device verifies the cardholder through device unlock, biometric, or wallet authentication. The terminal receives evidence that the device performed cardholder verification.

Terminal Verification Results Are a Compact Risk Record

The terminal verification results, TVR, is a set of bits describing checks and failures observed during the EMV transaction.

TVR can indicate issues such as:

• offline data authentication failed
• application expired
• requested service not allowed
• cardholder verification failed
• transaction exceeds floor limit
• random online selection triggered
• issuer authentication failed
• script processing failed

The TVR is used in terminal action analysis and often sent to the issuer. It condenses local terminal observations into a structured risk field.

This is one reason EMV authorisation messages are richer than magnetic-stripe messages. The issuer does not only see amount and merchant. It receives evidence about card-terminal processing.

Terminal Action Codes and Issuer Action Codes Decide Outcomes

Terminal action analysis uses several action code sets:

• terminal action codes
• issuer action codes
• default action codes

These are compared with terminal verification results to decide whether to decline, go online, or approve offline.

At a simplified level:

if severe risk bit matches denial rules:
    request decline cryptogram
else if risk bit matches online rules:
    request online cryptogram
else:
    request approval cryptogram

The terminal then asks the card to generate an application cryptogram. The requested type and card's own rules determine the result.

This rule machinery lets issuers influence offline terminal decisions through card personalisation while terminals still enforce local acceptance policy.

Application Cryptograms Are Transaction Evidence

The card generates application cryptograms during GENERATE AC.

Important cryptogram types:

• ARQC, authorisation request cryptogram
• TC, transaction certificate
• AAC, application authentication cryptogram

An ARQC means the transaction should go online for issuer authorisation. The issuer validates the ARQC using keys associated with the card. It proves the chip participated in a transaction with specific data.

A TC indicates approval, often offline or final completion depending on flow. An AAC indicates decline.

The cryptogram covers transaction data such as amount, currency, terminal data, counters, and unpredictable number according to EMV rules. This makes replay and static cloning harder.

Magnetic stripe data could be copied and replayed more easily. EMV cryptograms make each transaction carry fresh card-generated evidence.

The Application Transaction Counter Helps Detect Replay and Cloning

EMV cards maintain an application transaction counter, ATC. It increments as the card generates cryptograms.

The issuer can monitor ATC values:

• expected increase over time
• duplicate ATC values
• gaps
• impossible sequences
• use across different geographies or channels

ATC is not a complete fraud solution by itself, but it gives the issuer a useful signal. If two transactions arrive with the same ATC from different merchants, something is wrong. If counters jump unexpectedly, the issuer may investigate.

The counter is one of the simple but important ways chip transactions produce better evidence than magnetic stripe transactions.

Online Authorisation Validates the ARQC

When the terminal sends an online authorisation request, the issuer receives EMV data. The issuer or issuer processor validates the ARQC using card keys and transaction data.

The issuer checks:

• cryptogram validity
• ATC plausibility
• card status
• account status
• available funds or credit
• fraud rules
• CVM result
• terminal country and merchant data
• fallback or entry mode

If approved, the issuer may return an authorisation response cryptogram, ARPC, and issuer authentication data. The card can verify issuer authentication, proving the response came from the issuer side.

The issuer may also send scripts to update card parameters.

This online step connects chip cryptography with account-level decisioning.

Issuer Scripts Let the Issuer Update the Card

Issuer scripts are commands sent through the terminal to the card after online authorisation.

They may:

• block the application
• update offline limits
• reset counters
• change risk parameters
• perform card management actions

The terminal passes scripts to the card. The card executes them if valid and returns results. Script processing results may be included in later data.

Issuer scripts are powerful because they let the issuer manage card state in the field. They are also sensitive because failed or malicious script handling could affect card usability or risk controls.

The terminal should not interpret scripts as merchant commands. It transports issuer-authenticated instructions to the card.

Offline Approval Is a Controlled Risk Decision

EMV supports offline approval where the terminal and card complete without issuer online authorisation.

Offline approval may occur when:

• amount is below floor limit
• card risk counters allow it
• terminal risk management permits it
• offline data authentication succeeds
• cardholder verification conditions are satisfied

The card may generate a TC. The transaction is later cleared to the issuer.

Offline approval improves availability, but it carries issuer risk. The issuer did not check live account status. A card could be over limit, blocked after last update, or involved in fraud.

Issuers manage this through card parameters:

• offline limits
• cumulative offline amount
• consecutive offline transaction count
• forced online after threshold
• script updates

Offline is therefore not blind trust. It is bounded risk.

Contactless EMV Is Faster and More Scheme-Specific

Contactless EMV uses NFC and optimised kernels. The goal is to complete card-terminal interaction quickly.

Contactless flows differ from contact flows in timing and scheme profiles. The terminal may not perform the same two-step online completion with the card after issuer response. Many contactless transactions are designed so the customer can remove the card quickly after the terminal has enough data.

Contactless still uses EMV concepts:

• application selection
• application data reading
• risk checks
• CVM decision
• cryptographic data
• online authorisation where required

But brand-specific kernels matter more. A terminal that supports several schemes may run several contactless kernels.

This is why contactless certification is its own discipline.

Fallback Is a Weakness Attackers Try to Exploit

If chip reading fails, a terminal may allow fallback to magnetic stripe. That can be legitimate when a card chip is damaged. It can also be abused.

Attackers may try to force fallback because magnetic stripe lacks EMV dynamic cryptograms. Issuers and acquirers therefore monitor fallback transactions carefully.

The authorisation message should indicate fallback entry mode. Issuers may decline suspicious fallback attempts, especially where chip acceptance is expected.

Fallback liability rules may also shift responsibility. If a merchant falls back incorrectly, the merchant or acquirer may bear fraud losses.

Fallback exists for continuity, not as a normal path.

EMV Changed Fraud Economics

The major EMV effect was reducing counterfeit card-present fraud where chip was properly deployed.

Magnetic stripe cloning was cheap because the data was static. EMV chip cloning is much harder because the chip generates transaction-specific cryptograms and protects private keys.

Fraud did not disappear. It moved.

Attackers shifted toward:

• card-not-present fraud
• phishing and social engineering
• account takeover
• merchant compromise
• fallback abuse
• lost and stolen card use
• relay attacks in some contactless contexts

Security improvements often shift attacker economics rather than eliminate attackers. EMV made one class of fraud more expensive and pushed criminals toward weaker channels.

This is why e-commerce authentication, tokenisation, fraud analytics, and customer education grew in importance after chip deployment.

EMV Does Not Prove the Customer Wanted the Transaction

EMV can prove a genuine chip participated and certain verification steps occurred. It does not always prove the legitimate customer intended the payment.

Examples:

• card stolen and PIN observed
• customer tricked into inserting card
• relay attack under certain conditions
• merchant misrepresented amount
• terminal compromise

The evidence is strong but specific. It says:

this card application generated this cryptographic result for this transaction data

It does not answer every fraud or dispute question by itself.

Dispute handling still considers merchant evidence, cardholder claim, authentication method, terminal data, and scheme rules.

EMV Data Quality Affects Authorisation Decisions

Issuers rely on EMV fields. If terminals send poor data, authorisation quality falls.

Problems include:

• missing unpredictable number
• wrong terminal capabilities
• incorrect CVM result
• bad entry mode
• malformed issuer application data
• stale terminal public keys
• incorrect country or currency
• broken fallback indicators

Acquirers and schemes monitor data quality. Bad terminals can create declines, liability exposure, or certification issues.

For engineers, the lesson is clear: payment data elements are not optional metadata. They drive cryptographic validation, risk scoring, fee qualification, and dispute outcomes.

A Full EMV Contact Transaction Walkthrough

Consider a €74 chip transaction at a bookshop in Athens.

The terminal selects an AID shared by card and terminal. It sends GET PROCESSING OPTIONS. The card returns AIP and AFL. The terminal reads the records listed by the AFL.

The terminal verifies offline data authentication. Suppose the card supports CDA and verification succeeds. The terminal checks processing restrictions and sees the application is valid for this transaction.

The terminal evaluates the CVM list. The amount requires online PIN. The customer enters PIN securely. The terminal records the CVM result.

Terminal risk management runs. The amount exceeds the terminal floor limit, so online authorisation is required. Terminal action analysis requests an ARQC.

The card increments ATC and generates ARQC over transaction data. The terminal sends authorisation through the acquirer and scheme to the issuer.

The issuer validates ARQC, checks PIN, funds, fraud, and card status, then approves. It returns issuer authentication data and possibly scripts.

The terminal completes the card interaction, displays approved, and prints receipt. Clearing and settlement happen later.

The visible act was chip and PIN. The actual process was a cryptographic protocol plus issuer decisioning.

A Failure Walkthrough: Offline Data Authentication Fails

Suppose a terminal cannot verify the card's offline data authentication.

Possible causes:

• counterfeit or altered card data
• expired or missing terminal public key
• damaged card data
• kernel parsing issue
• unsupported authentication method

The terminal sets TVR bits indicating failure. Terminal action analysis may decline or force online depending on rules.

If the terminal goes online, the issuer sees the EMV data and may decline based on risk. If the terminal is offline-only and rules require decline, the transaction should not proceed.

This example shows why terminal configuration and public key maintenance matter. A genuine card can fail if the terminal estate is stale. A counterfeit attempt can be stopped if the terminal enforces authentication results correctly.

A Failure Walkthrough: Issuer Script Fails

An issuer approves a transaction but sends a script to update card parameters. The terminal passes the script to the card. The card fails to execute it.

The purchase may still be approved depending on script criticality and rules, but the script result should be recorded. Later transactions may include script processing failure indicators.

Issuer script failure can matter if the issuer was trying to block an application, reset counters, or change risk limits. Operations may need to monitor repeated script failures for a terminal type or card population.

Again, EMV is not only the approval moment. It is a card lifecycle management channel.

Testing EMV Kernels Requires Trace-Level Evidence

EMV testing uses transaction traces, not only final approved or declined outcomes.

A useful trace shows:

• selected AID
• GPO response
• AIP and AFL
• records read
• offline authentication result
• CVM selected
• TVR and TSI values
• terminal action analysis result
• generated cryptogram type
• issuer response handling
• script processing result

Testing only "transaction approved" misses dangerous bugs. A terminal might approve with wrong CVM result, skip a risk bit, send malformed data, or mishandle issuer scripts while still appearing to work at the counter.

EMV certification exists because small protocol mistakes can have financial consequences.

The Transaction Status Information Complements TVR

The transaction status information, TSI, records which EMV functions were performed. While TVR records many risk results and failures, TSI says whether broad processing steps happened.

Examples include:

• offline data authentication performed
• cardholder verification performed
• card risk management performed
• issuer authentication performed
• terminal risk management performed
• script processing performed

TSI helps issuers and investigators understand the shape of the transaction. If a terminal claims a chip transaction but TSI indicates important steps were not performed, the issuer may treat it differently.

TVR and TSI together provide a compact trace:

TVR: what went wrong or what risk condition appeared
TSI: what processing functions were actually performed

This distinction is useful in disputes. A failed CVM bit means something different from CVM processing not being performed because no CVM was required.

The Unpredictable Number Must Be Unpredictable

EMV transactions include an unpredictable number generated by the terminal. It contributes freshness to cryptographic processing.

If the unpredictable number is predictable, repeated, or low quality, the security assumptions weaken. Historical EMV research and real attacks have shown that weak terminal random number generation can matter.

A good terminal should generate values that cannot be guessed easily by an attacker. It should not use:

• simple counters
• timestamps with low entropy
• repeated startup seeds
• merchant-configured constants

The issuer may not easily detect every weak terminal, but acquirers and certification testing should catch poor behaviour. Terminal unpredictability is one of those hidden details that customers never see but cryptographic protocols depend on.

Track Equivalent Data Exists for Compatibility

EMV cards often provide data elements that resemble magnetic stripe track data, but chip transactions add cryptographic evidence and entry-mode context.

A contact chip or contactless transaction may include track equivalent data used by legacy authorisation systems. The issuer must interpret it with EMV fields:

• entry mode
• cryptogram
• terminal capabilities
• TVR and TSI
• application transaction counter
• issuer application data

If a processor strips EMV data and treats the transaction like ordinary magnetic stripe, the issuer loses important risk evidence. This can also affect liability and approval decisions.

Many payment stacks evolved from magnetic stripe systems. EMV integration often meant carrying new chip fields through old message formats. That bridging is a source of subtle bugs.

Issuer Application Data Is Issuer-Specific Evidence

Issuer application data, often carried in tag 9F10, contains issuer-defined or scheme-profile-specific information. It can include cryptogram-related data, card verification results, counters, and risk indicators.

The terminal may pass it through without understanding every issuer-specific detail. The issuer or issuer processor interprets it.

This is common in payment systems. Not every participant understands every field semantically, but they must preserve it correctly.

If a gateway truncates or alters issuer application data, cryptogram validation or risk analysis may fail. If an issuer processor misinterprets profile-specific data, it may approve or decline incorrectly.

The lesson is that opaque fields are still critical. "We do not parse it" must not become "we can drop it".

EMV Personalisation Defines Card Behaviour Before Issuance

Many EMV behaviours are decided when the issuer personalises the card.

Personalisation writes:

• payment applications
• application priority
• certificates
• keys
• CVM list
• issuer action codes
• application usage controls
• offline limits
• counters or initial state
• risk parameters

A card issued to a student in Athens and a premium business card issued in Frankfurt may have different risk parameters even if both use the same scheme.

Personalisation errors can be expensive. A wrong CVM list can cause unnecessary declines. A wrong certificate can break offline authentication. A wrong application priority can route transactions differently from product design. A too-generous offline limit can increase fraud exposure.

Card issuance is therefore software deployment to millions of secure devices. Once cards are in wallets, changing behaviour may require issuer scripts, reissuance, or waiting for natural replacement.

EMV Uses Symmetric and Asymmetric Cryptography for Different Jobs

EMV uses asymmetric cryptography for public key certificate chains and offline data authentication. It uses symmetric keys for issuer cryptogram validation and related card-issuer secrets.

The broad split:

asymmetric: terminal verifies issuer and card public key evidence
symmetric: issuer validates transaction cryptograms generated from card keys

The terminal usually cannot validate an ARQC fully because that requires issuer-side symmetric keys. It passes the ARQC to the issuer. The issuer or processor validates it using keys derived or stored for that card.

This division keeps issuer secrets away from terminals. Terminals are widely deployed in hostile environments. Issuer symmetric keys belong in issuer processors and HSM-backed environments, not in merchant devices.

The terminal can verify public certificates. The issuer verifies card-specific transaction cryptograms.

HSMs Sit Behind Issuer Cryptogram Validation

Issuer processors often use hardware security modules, HSMs, for cryptographic operations such as:

• ARQC validation
• ARPC generation
• PIN verification
• key derivation
• secure key storage

When an EMV online authorisation arrives, the issuer processor may call an HSM to validate the cryptogram. The HSM checks that the ARQC is correct for the card and transaction data.

HSM latency becomes part of authorisation latency. At high volume, issuers need enough cryptographic capacity to handle peak card traffic. A slow HSM path can increase timeouts or force stand-in decisions.

This is another hidden systems link: chip-card cryptography affects infrastructure sizing.

Contactless Relay Attacks Exploit Distance Assumptions

Contactless cards use short-range NFC. Users assume short range means physical proximity to the merchant terminal. Relay attacks challenge that assumption by forwarding communication between a genuine card and a remote terminal.

In a relay attack, one device is near the victim's card and another is near the merchant terminal. Messages are relayed between them. The terminal may believe the card is present.

Defences include:

• transaction limits
• CDCVM for mobile wallets
• timing constraints
• risk analytics
• user awareness
• future distance-bounding techniques in some contexts

EMV cryptography proves the genuine card participated. It may not prove the card was physically next to the terminal in the intuitive sense if a relay is successful.

This shows the boundary of cryptographic evidence. It proves protocol participation, not every physical-world fact.

Contactless Limits Are Risk Controls

Contactless no-CVM limits allow fast low-value payments. In many European markets, no-CVM contactless has a threshold. Above it, PIN or CDCVM may be required.

Cards and issuers may also enforce cumulative counters:

• number of consecutive no-CVM taps
• cumulative no-CVM amount
• forced online after threshold
• PIN required after counter exceeded

These controls limit loss if a card is lost or stolen. A thief may make a few low-value purchases, but the card eventually requires stronger verification.

Terminals, cards, and issuers all need to handle limits consistently. If a terminal misconfigures limits, it may request no CVM when rules require verification. If issuer counters are not updated correctly, fraud exposure changes.

Contactless convenience rests on these controls.

EMV Fallback Data Should Be Treated With Suspicion

When a chip card transaction falls back to magnetic stripe, the issuer sees an entry mode indicating fallback or stripe use.

Issuers often treat fallback as higher risk because:

• chip could be deliberately bypassed
• counterfeit stripe data may be used
• terminal may be faulty
• merchant may be forcing fallback improperly

Issuer rules may decline fallback for certain cards, amounts, or countries. Acquirers may investigate merchants with high fallback rates.

The transaction may still be legitimate. A damaged chip exists. But fallback data should not be treated as ordinary stripe acceptance in a mature chip environment.

Fallback monitoring was a major part of EMV migration because fraudsters looked for weak terminals and fallback-friendly merchants.

EMV and 3-D Secure Solve Different Problems

EMV handles card-present chip transactions. 3-D Secure handles many card-not-present e-commerce authentication flows.

They are often confused because both relate to card security. They operate in different environments.

EMV evidence:

• chip or contactless credential participated
• terminal processed EMV data
• cryptogram generated
• cardholder verification method result available

3-D Secure evidence:

• online shopper authentication or risk assessment occurred
• issuer ACS participated
• challenge or frictionless result returned
• e-commerce liability treatment may be affected

When fraud shifted from counterfeit card-present to online channels, EMV alone could not solve it because the chip is absent from normal web checkout. That is why e-commerce security evolved separately.

Tokenisation and wallet cryptograms blur the boundary in mobile commerce, but the core distinction remains: EMV is the physical or proximity card protocol, while 3-D Secure is an e-commerce authentication protocol.

EMV Does Not Remove PCI Obligations

A merchant accepting EMV cards still has PCI responsibilities. EMV reduces counterfeit risk, but the merchant environment may still handle cardholder data.

Risks include:

• malware on integrated POS systems
• memory scraping before encryption
• poor network segmentation
• insecure logs
• full PAN storage
• exposed receipts
• compromised gateway credentials

Point-to-point encryption and tokenisation can reduce merchant PCI scope, but they do not make security irrelevant. A terminal may be secure while the surrounding POS environment is weak.

This matters because attackers moved toward merchant systems and online channels when chip cloning became harder. EMV changed the battlefield. It did not end card data security work.

Terminal and Card Risk Decisions Can Disagree

The terminal may request one cryptogram type. The card may return another based on its own rules.

For example, the terminal may request online authorisation, but the card may return AAC if internal card rules decide the transaction should decline. Or the terminal may request offline approval, but the card may force online because offline counters are exhausted.

This is important because both sides contribute policy:

• terminal has merchant and acquirer configuration
• card has issuer-personalised risk parameters

The outcome is negotiated through EMV rules, not dictated by one side alone.

If developers assume the terminal always controls the path, they misunderstand EMV. The card can refuse, force online, or produce a decline cryptogram.

EMV Trace Analysis Is a Skill

When transactions fail, engineers and certification teams inspect traces.

A trace may show:

SELECT AID succeeded
GPO returned AIP 3900, AFL 08010100
READ RECORD 1 SFI 1 succeeded
offline data authentication failed
CVM selected online PIN
TVR 8000048000
GENERATE AC returned ARQC
issuer response approved
second GENERATE AC returned TC

Interpreting that trace requires knowledge of tags, bitmaps, scheme profiles, and kernel rules. The final receipt may only say approved. The trace explains how approval happened.

Trace analysis is essential when:

• one card product fails on one terminal type
• contactless works but contact fails
• issuer declines due to cryptogram validation
• CVM prompts are unexpected
• public key expiry causes failures
• issuer scripts fail

Good payment engineering teams preserve trace-level evidence in test and controlled production diagnostics.

Migration to EMV Was Also an Operational Change

Moving from magnetic stripe to EMV required more than issuing chip cards.

The ecosystem had to upgrade:

• cards
• terminals
• acquirer hosts
• issuer processors
• certification labs
• merchant training
• dispute rules
• fallback monitoring
• fraud models

During migration, mixed environments created awkward behaviour. A chip card used at a non-chip terminal had different liability implications. A chip-capable terminal with old software could cause declines. Merchants needed to learn insertion, PIN prompts, and fallback rules.

This is a useful reminder for any payment security upgrade. The protocol can be strong, but the ecosystem determines real-world effect.

EMV Evidence Feeds Machine Learning, but Rules Still Matter

Issuers use EMV fields in fraud models.

Signals include:

• entry mode
• CVM result
• ATC behaviour
• terminal country
• merchant category
• fallback indicator
• contactless indicator
• token or wallet data
• TVR and TSI bits
• cryptogram validation result

Machine learning can identify unusual patterns, but hard rules remain important. Invalid cryptogram should not be treated as just another weak signal. Card blocked status should not be overridden because a model score is low.

The practical architecture combines:

• cryptographic validation
• deterministic product rules
• risk scoring
• velocity checks
• case management

EMV provides stronger input data for that stack.

EMV's Main Lesson for Engineers

The strongest lesson from EMV is that payment security improved when static credentials were replaced with transaction-specific evidence.

Magnetic stripe data answered:

Does this presented data look like card data?

EMV asks stronger questions:

Did a card application selected by the terminal participate?
Did it generate a cryptogram over this transaction?
Did terminal risk checks pass?
Was the cardholder verified according to applicable rules?
Can the issuer validate the cryptogram and account state?

The system is still imperfect, but the evidence is much richer.

This pattern appears elsewhere in security. Static secrets are easy to copy. Protocols that bind cryptographic proof to transaction context are harder to abuse.

EMV Data Is Encoded as TLV for Extensibility

EMV uses tag-length-value encoding so terminals and issuers can carry many data elements without one rigid record layout.

A TLV item has:

tag: identifies the data element
length: says how many bytes follow
value: contains the data

This makes EMV extensible. A terminal can parse known tags and pass through others. Scheme profiles can define specific tags. Issuer-specific data can travel inside defined structures.

The downside is parser complexity. Bugs can appear when:

• length fields are malformed
• nested templates are mishandled
• unknown tags are dropped incorrectly
• numeric formats are decoded wrongly
• binary data is logged as text

Payment systems often fail at boundaries where EMV TLV data is converted into ISO 8583 fields, JSON diagnostics, database columns, or logs. Developers need robust parsers and test vectors, not ad hoc string manipulation.

Amount Fields Must Be Bound Correctly

The application cryptogram is generated over transaction data that includes amount fields. This matters because the card should be proving participation in this specific transaction amount, not any amount.

Terminals distinguish fields such as:

• amount authorised
• amount other
• transaction currency
• transaction date
• terminal country

If the terminal displays €30 but generates cryptogram data for €300, the system has a serious integrity problem. Certification and kernel rules are designed to prevent this kind of mismatch.

Integrated POS systems add another boundary. The cash register sends an amount to the terminal. The terminal displays it and uses it in EMV processing. The receipt and host message should match.

Amount integrity is one of the reasons payment terminals are controlled devices. The customer must be able to trust that the amount approved is the amount processed.

EMV and Tokenised Wallets Share Ideas but Differ in Shape

Mobile wallet transactions often use network tokens and dynamic cryptograms. They are not identical to classic contact chip EMV, but they preserve the core security idea: do not expose a static card credential and bind transaction evidence to a controlled credential.

A wallet transaction may include:

• device account number or network token
• token requestor data
• dynamic cryptogram
• CDCVM result
• device risk signals

The terminal still sees a contactless payment. The issuer or token service can evaluate token state, device binding, and cryptographic data.

This improves security if the wallet provisioning process and device security are strong. It also creates new lifecycle states:

• token active
• token suspended
• device lost
• wallet removed
• token assurance low or high

EMV's broader lesson survives: transaction-specific cryptographic evidence is stronger than static credential presentation.

Offline Counters Are a Local Risk Ledger

Cards can track offline activity through counters and cumulative limits.

Examples:

• consecutive offline transaction count
• cumulative offline amount
• lower and upper consecutive offline limits
• issuer-defined risk thresholds

These counters help the card decide when to force online authorisation. If the card has approved several offline transactions, it may request online processing even for a small amount.

This is a local risk ledger inside the card. The issuer cannot see every offline transaction immediately, so the card enforces limits until it can reconnect through an online transaction and receive issuer updates.

If offline counters are too generous, lost or stolen card risk rises. If they are too strict, legitimate offline acceptance fails. Issuer personalisation sets the tradeoff.

Issuer Authentication Protects the Card From Fake Responses

When a transaction goes online, the issuer may send authentication data back to the card. The card verifies that the response came from a legitimate issuer-side system.

Without issuer authentication, a malicious terminal or intermediary might try to feed fake approvals or scripts to the card. EMV issuer authentication helps the card trust certain online response data.

If issuer authentication fails, the terminal and card record it in EMV results. Depending on rules, the transaction may decline or proceed with risk indicators.

Issuer authentication is easy to overlook because the customer only sees approved or declined. But it is part of the mutual trust model: the issuer validates the card's cryptogram, and the card can validate issuer response evidence.

Scheme Profiles Create Real Differences

People often say "EMV" as if every scheme and transaction type behaves the same. In practice, scheme profiles and kernels create differences.

Differences may appear in:

• contactless flow timing
• data elements required
• CVM handling
• mobile wallet treatment
• offline support
• issuer script behaviour
• limits
• certification tests

A terminal that supports several schemes must implement and certify the relevant kernels. A bug may affect one scheme's contactless flow but not another's contact chip flow.

This is why payment debugging often starts with:

scheme
application id
kernel id
contact or contactless
card product
terminal software version

Those details determine which rules applied.

EMV Evidence Can Be Lost in Poor Integrations

Even if the terminal performs EMV correctly, downstream systems must carry the evidence.

Common integration failures include:

• acquirer gateway drops optional EMV tags
• issuer processor cannot parse a new contactless profile
• POS logs mask useful reference fields
• clearing records omit entry mode detail
• dispute system cannot display TVR or CVM result

When evidence is lost, the issuer may make worse decisions or lose disputes. A valid chip transaction may look like a weaker transaction. A fallback transaction may not be flagged. A CDCVM result may not reach risk systems.

EMV is only as useful as the data path that preserves it.

EMV Does Not Replace Good Authorisation Policy

A valid chip cryptogram does not mean the issuer should always approve.

The issuer still needs to check:

• account balance or credit
• card block status
• fraud velocity
• merchant category risk
• country risk
• customer controls
• sanctions or compliance concerns where relevant
• unusual behaviour

EMV answers authenticity and transaction-evidence questions. Authorisation policy answers whether the issuer wants to allow the transaction now.

A stolen card with correct PIN can generate valid EMV data. A genuine card can be used at a risky merchant. A valid cryptogram can arrive for an amount that exceeds available funds. The issuer still has to decide.

This is why EMV is a security layer, not the entire payment decision.

EMV Failures Often Show Up as Generic Declines

Customers and merchants usually see only:

declined
try another card
chip error

Behind that message, many EMV-specific failures are possible:

• application selection failed
• offline data authentication failed
• card expired
• CVM failed
• PIN try limit exceeded
• ARQC validation failed
• issuer authentication failed
• script processing failed
• terminal public key missing
• unsupported AID

Support tools need more detail than the receipt. Otherwise merchants blame the card, issuers blame the terminal, and customers retry without understanding.

Good acquirer diagnostics expose kernel outcome codes, EMV tags, and host response data to trained support staff while still protecting sensitive information.

The Smallest Useful Mental Model

EMV is a transaction protocol that makes a chip card participate actively in payment decisions.

The key ideas are:

1. application selection chooses the payment application
2. AIP and AFL tell the terminal what checks and records matter
3. offline data authentication checks issuer-signed and sometimes dynamic card proof
4. CVM processing decides how the cardholder is verified
5. TVR records terminal-observed risk conditions
6. terminal and issuer action codes drive online, offline approval, or decline
7. ARQC, TC, and AAC are cryptographic transaction outcomes
8. issuer scripts let the issuer manage card state after authorisation

EMV did not make payments simple. It made card-present payments harder to counterfeit by replacing static stripe data with chip-controlled rules and transaction-specific cryptography. The fraud moved toward channels where the chip is absent, bypassed, or socially engineered around.

That is how EMV actually works.