3-D Secure proves the device passed a check. It does not prove you meant to buy.

EMV 3-D Secure moves fraud liability from the merchant to the issuer when authentication succeeds. What it authenticates is a risk score or a response on a channel the issuer controls, never a human bound to this amount and this merchant. Europe requires that binding by regulation. Almost nowhere else does, and agentic checkout is about to make the difference expensive.

Picture a dispute analyst at an issuer, working a queue. The case in front of her is unremarkable. A card not present purchase, 640 dollars, an electronics retailer, three weeks ago. The cardholder says they did not make it. The merchant has submitted its evidence and the merchant is not worried, because the transaction was authenticated through 3-D Secure and the liability sits with the issuer.

She opens the authentication record to see what actually happened. The record tells her the transaction was authenticated. It gives her a timestamp, a device identifier the issuer's access control server had seen before, an indication that a one time passcode was delivered by SMS, and a note that the code was entered correctly within the window. There is a cryptographic value attached to the message confirming that this authentication occurred and was not tampered with in transit.

Every field is present and correct, and not one of them answers her question. She wants to know whether the human who owns this card decided to spend 640 dollars at that retailer. What she has is proof that a code sent to a phone number was typed into a box.

She approves the chargeback, because that is what the evidence supports, and the issuer eats it. Somewhere in the same building, a product manager is being congratulated for reducing the challenge rate.

What does 3-D Secure actually do?

It is worth giving the protocol its due before criticising it, because it solved a real problem and it solved it well enough to become universal.

The three domains

The name describes the architecture. There are three domains: the acquirer domain, containing the merchant and its payment provider; the issuer domain, containing the bank that issued the card and its access control server; and the interoperability domain in the middle, run by the card network, which carries messages between the other two.

When a card not present purchase begins, the merchant's provider sends an authentication request into that middle layer, carrying a substantial amount of data about the transaction, the device and the session. The issuer's access control server receives it and decides what to do. It sends back a response. The merchant then submits the authorisation with the resulting authentication value attached.

The genuine achievement here is that a merchant and an issuer who have no relationship, in different countries, under different regulators, can conduct a real time authentication exchange in a few hundred milliseconds through a shared intermediary, at global scale, using a message format they both implement independently. That is not a small thing, and EMVCo deserves the credit for it.

The two flows

The issuer's access control server chooses between two paths.

In the first, it authenticates the transaction with no interaction at all. It looks at the transaction data, the device data, the history it holds for this cardholder, and its own risk models, and it concludes that intervention is unnecessary. The cardholder sees nothing. The specification's own name for this path describes an experience without friction, and the industry has spent a decade optimising toward it, for good commercial reasons.

In the second, it issues a challenge. Historically that meant a static password, which was abandoned for excellent reasons. Today it usually means a one time passcode delivered by SMS or email, or a push notification to the issuer's mobile application asking the cardholder to approve.

Why the liability shift is the engine

None of this would have achieved global adoption on security merit alone. It achieved it because of the commercial mechanism attached: when a transaction is successfully authenticated through 3-D Secure, liability for most subsequent fraud disputes moves from the merchant to the issuer.

Understand what that does to everybody's incentives, because it explains the entire shape of the system. The merchant wants the liability shift and does not want abandoned baskets, so it wants authentication that succeeds and never interrupts. The issuer accepts the liability and therefore wants accuracy, but it also competes on approval rates and customer experience, so it does not want to challenge either. The network wants volume. Nobody in the arrangement is paid to make the challenge stronger, and everybody is paid to make it rarer.

So the industry got what it optimised for. Challenge rates fell. Conversion improved. And the thing that survived at the end of that optimisation is a liability shift that increasingly rests on a probability rather than on a proof.

What does each 3-D Secure message actually prove?

Take the two paths separately, because they fail differently.

The path without a challenge proves that the issuer's risk engine, given the data available, assessed the transaction as acceptable. That is a well informed statistical judgment made by people who are good at their jobs. It is also, by construction, detection: a model estimating whether something is genuine from correlated signals. When the signals are produced by an adversary who controls the device, the session, or increasingly the software making the purchase, the model is reasoning about evidence the adversary supplied. This is the same structural position we describe as detection debt.

The challenge path proves that somebody with access to a channel responded on it. An SMS code proves access to a phone number, which is a well documented weak binding given how port out and account takeover attacks work. An email code proves access to a mailbox. An in application push proves access to an unlocked phone with the issuer's application installed and a session in it.

Each of those is a possession or session check. None of them is a statement about this purchase. The push notification is the most instructive case, because it looks the most like consent and often is not: many issuer applications present a prompt that names the merchant and the amount, which is genuinely better, but the artifact that returns to the access control server is typically an assertion that the prompt was approved, not a signature computed over those specific values. The display and the proof are separate, and only the display shows the transaction.

That separation is exactly the failure we examined in a completely different domain in the article on blind signing. When the thing shown to the human and the thing cryptographically attested are not the same object, an attacker who controls the display controls the meaning of the approval.

Why is a one time passcode not proof of intent?

Because it can be relayed in real time by somebody who is not the cardholder, and because it carries no information about what it authorises.

Consider how the relay works. An attacker has the card details. They begin a purchase, which triggers a challenge, which sends a code to the genuine cardholder's phone. At the same moment the attacker, on the phone or in a chat, is speaking to that cardholder, presenting themselves as the bank's fraud team, and asking them to read out the code that is arriving right now to confirm that they are not the person making a suspicious transaction. The cardholder reads out the code. The purchase completes. The authentication record shows a successful challenge response.

Nothing in the protocol was broken. The code was genuine, was delivered to the correct number, and was entered within the window. What the protocol proved is exactly what it claims to prove, and what it claims to prove is not what the issuer needed to know.

Now note the second, quieter problem. The code is a number. It is not bound to 640 dollars, and it is not bound to that electronics retailer. The same six digits would have authenticated a different amount at a different merchant equally well. The cardholder, even a maximally careful one, has no way to inspect what they are approving, because the thing they are approving does not say.

This is not an argument that issuers are careless. It is an argument that a channel response and an authorisation are different objects, and the industry has been using one where it needs the other. Passkeys have exactly the same boundary at login, which we cover in passkeys prove the login, not the transaction.

What does Europe require that the rest of the world does not?

This is the most instructive part of the whole subject, because it demonstrates that the industry already knows how to do this properly and does it only where it is compelled to.

Under the European regulatory technical standards on strong customer authentication, made under the second Payment Services Directive, electronic remote payments must satisfy a requirement usually called dynamic linking. In substance it requires that the authentication code generated for a payment be specific to the amount and to the payee, that the payer be made aware of both at the time of authenticating, and that any change to either invalidate the code.

Read that again and notice how precisely it describes the gap this article is about. It is not a requirement to authenticate the person more strongly. It is a requirement that the authentication be about the transaction. The regulator identified that a strong authentication of a session is not a strong authorisation of a payment, and wrote the distinction into law.

The practical consequences inside Europe are visible in any compliant issuer application. The prompt has to show the amount and the payee. The cryptographic material has to be derived from them. Change the beneficiary after the fact and the authentication is void. Implementations vary in quality, and compliance is not the same as excellence, but the property is mandated rather than optional.

Outside that regulatory perimeter, the property is optional, and the incentives described earlier explain what happens to optional properties that cost conversion. This is the honest summary: the correct design exists, is well specified, is deployed at scale across an entire continent, and has not spread beyond the place where it is required by law.

Anybody arguing that binding authentication to transaction details is impractical at scale is arguing against an existing, functioning, continent sized counterexample.

What happens when an agent holds the card?

Everything above is a live problem today. The agent case makes it structural.

The card networks have built agent oriented payment programmes, and the emerging agent payment standards define signed statements of what a user authorised. These are serious pieces of infrastructure and we examine them properly in the article on agentic checkout mandates. The question here is narrower: what happens to 3-D Secure when the purchaser is software?

Start with the path that has no challenge. The risk engine's inputs are device characteristics, behavioural signals, session history and merchant context. When an agent is transacting, those inputs describe the agent's runtime environment. They are perfectly real and they carry no information about a human, because no human was present. The model is not being deceived; it is being asked a question about a human in a situation where the human is absent from the data.

Now the challenge path. A challenge assumes somebody is there to be challenged. If the agent is completing a purchase while the user sleeps, which is the entire point of the product, then either the challenge fails and the purchase is declined, or the agent is somehow able to satisfy it, which means the challenge is satisfiable without a human and was therefore never proving one.

And then the dispute. The cardholder says they did not authorise the purchase. Perhaps they authorised a shopping task in general terms weeks earlier. Perhaps the agent misinterpreted. Perhaps somebody else prompted it. The merchant's evidence describes the agent's session, because the agent generated every signal it has. The issuer's evidence is a risk score computed over an agent's environment. Neither party holds an artifact showing what the human agreed to. We look at the merchant side of that problem in the article on dispute evidence and first party misuse.

This is why the gap stops being academic. Today it produces a moderate stream of losses that the system absorbs. Under agentic volume it produces disputes that no participant can settle with the evidence the protocol generates.

What would a signed challenge look like?

Composition rather than replacement. The access control server keeps its risk engine and keeps choosing which transactions to challenge. For the subset it chooses, the challenge produces a signature over the transaction rather than a code typed into a box.

The object being signed is the transaction itself, canonically serialised, and the cardholder's device renders those same bytes before signing them:

{
  "type": "card_purchase_authorization",
  "amount": "640.00",
  "currency": "USD",
  "merchant_name": "Northgate Electronics",
  "merchant_id": "mid_44192",
  "card_last4": "4417",
  "acs_transaction_id": "3ds_0f31c7a9",
  "timestamp": "2026-09-20T18:44:02Z"
}

The receipt that comes back is small, and its useful property is that it can be checked by somebody who trusts none of the parties:

verify(receipt, published_key) -> {
  valid:      true,
  signed_by:  "ed25519:44a1...9be2",
  payload:    sha256("...canonical bytes above..."),
  signed_at:  "2026-09-20T18:44:09Z"
}

Three properties follow, and they are the reason to bother.

The relay attack stops working, because there is nothing to read out. A signature is produced by a key on a device, and a cardholder cannot recite it down a phone line to a helpful stranger.

The approval becomes specific. The signature covers 640 dollars at that merchant. It cannot be replayed against a different amount or a different merchant, because those bytes are inside the hash.

And the artifact survives the transaction. A receipt that verifies offline against a published key is evidence for a dispute months later, checkable by the network or the merchant without calling the issuer and without anybody having to be trusted at verification time.

For the agent case, the human signs a scoped delegation once, naming a merchant category, a spending cap and an expiry, and the agent's purchase references it. The dispute then has an answer: either a delegation covering this purchase exists and the human signed it, or it does not.

What survives a dispute?

This is the practical comparison, and it is the table every issuer risk team should have on a wall.

The pattern in the right hand column is the point. Almost every current evidence type is a log written by a party with an interest in the outcome. A signature verifiable against a published key is not.

Honest limits

This needs adoption that a vendor cannot supply. Challenge methods are governed by network rules and implemented by access control server vendors and issuers. A merchant cannot adopt a signed challenge unilaterally, and neither can we. Manav has shipped no card network integration, and the card network step up adapter described here is roadmap rather than product. Presenting it otherwise would be exactly the kind of overclaiming this series criticises elsewhere.

It costs conversion where it is applied. Any challenge costs baskets. The argument is not that challenges are good, it is that a challenge which does not prove anything is the worst of both worlds: it costs the conversion and delivers no evidence. The target is fewer, stronger challenges, concentrated on high value and first time merchant transactions, with nothing below the threshold.

It does not adjudicate the human's judgment. A cardholder talked into signing a genuine authorisation has produced a genuine authorisation. This binds intent, not wisdom. It removes the class of disputes where nobody can say what was approved, and it does not remove the class where somebody was deceived into approving it.

A compromised device defeats it. If the phone holding the key is fully compromised, the signature it produces is as good as the attacker. Separating the display domain from the merchant and browser domain raises the bar considerably. It does not create an uncompromisable one.

Enrolment is a new moment to defend. Binding a cardholder to a key requires an enrolment, and that enrolment inherits whatever assurance produced it.

What to do this week

1. Pull twenty recent card not present disputes where 3-D Secure authentication succeeded and read what the authentication record actually contains. Most teams have never looked at the field level evidence they are relying on.
2. Separate your authenticated transactions into the two flows and measure the fraud rate of each independently. The blended number hides which mechanism is carrying the risk.
3. If you operate under the European standards, check what your challenge screen actually displays and what the cryptographic material is actually derived from. Compliance and correct implementation are different questions.
4. If you do not, write down what your challenge would prove if the cardholder were on the phone with an attacker at the moment it was issued.
5. Ask your access control server vendor whether their challenge method binds the authentication to the amount and merchant, and get the answer in writing.
6. Model your dispute volume under an assumption that some meaningful share of card not present purchases are initiated by agents within two years, and ask what evidence you would have for those.
7. Decide which transactions genuinely deserve a strong challenge. The answer is usually a small percentage, and the current spread of weak challenges across a larger percentage is worse on both axes.
8. Look at the signing documentation and the signing demo to see what a transaction bound signature costs a user in seconds, before the internal argument about friction begins.

Frequently asked questions

Does 3-D Secure prove the cardholder approved a purchase? No. In the path with no challenge it proves the issuer's risk model was comfortable with the transaction. In the challenge path it proves somebody responded on a channel the issuer controls, such as an SMS code or an application tap. Neither establishes that a specific human agreed to this amount at this merchant, which is the question a dispute actually turns on.

Who is liable when an AI agent buys something with my card under 3-D Secure? Today this is unresolved and it is the reason the gap matters. A successful authentication shifts liability to the issuer, but the evidence supporting that authentication describes an agent's environment rather than a human's decision. Until a human authorisation artifact exists, the dispute is settled by rules and commercial relationships rather than by evidence.

What is dynamic linking under PSD2? It is a requirement in the European regulatory technical standards on strong customer authentication that the authentication code for a remote payment be specific to the amount and payee, that the payer be shown both when authenticating, and that changing either invalidates the code. It is the one place where regulation forced authentication to be about the transaction rather than the session.

Why is a one time passcode weak if it is delivered correctly? Because it proves access to a channel and says nothing about what is being authorised. A live attacker can talk a cardholder into reading out a code that arrived legitimately, and the same digits would authenticate any amount at any merchant. The delivery was correct. The inference drawn from it is what fails.

Does a signed challenge replace 3-D Secure? No. It composes with it. The access control server keeps its risk engine and keeps deciding which transactions to challenge. For the subset it selects, the challenge produces a signature over the transaction rather than a code, and the resulting receipt is stored with the authentication record as dispute evidence.

What counts as compelling evidence in a card dispute? Networks maintain rules on the evidence a merchant can submit, and recent rule development has focused on establishing patterns of prior undisputed activity with the same cardholder. That is useful and it is still merchant generated history. An authorisation receipt signed by the cardholder's own device is a different category of evidence, because the disputing party did not write it.

Sources

1. EMVCo, EMV 3-D Secure specifications and technical documentation. emvco.com
2. European Banking Authority, regulatory technical standards on strong customer authentication and secure communication, including the dynamic linking requirement. eba.europa.eu
3. FBI Internet Crime Complaint Center, public service announcement of 25 November 2025 reporting more than 262 million dollars in account takeover losses across over 5,100 complaints since January 2025. ic3.gov
4. Visa, agentic commerce and payment security programme materials. usa.visa.com
5. Mastercard, agent payment programme announcements. mastercard.com/news
6. FIDO Alliance, work on agent payment protocols and authentication standards. fidoalliance.org
7. Nilson Report, the standard published source for global card fraud loss measurement by category. nilsonreport.com

A liability shift built on a risk score is not a proof. It is an agreement about who pays when nobody can tell what happened.