Three-D Secure and Strong Customer Authentication

47.0 What this chapter gives you#

1. You will be able to name the three domains, the component that sits in each — 3DS Server, Directory Server, Access Control Server — and say which one actually authenticates the cardholder.
2. You will be able to explain why the protocol is called three-domain rather than three-dimensional, and why the second wire exists at all.
3. You will be able to distinguish authentication from authorisation, and explain how a cardholder can pass one and be declined by the other ninety milliseconds later inside the same bank.
4. You will be able to read a transStatus value and say whether the exchange ended frictionless, went to challenge, or produced only evidence of an attempt.
5. You will be able to name the three artefacts an authentication produces — the authentication value, the e-commerce indicator and the directory transaction identifier — and say what happens when they do not reach the authorisation intact.
6. You will be able to state the counting rule of strong customer authentication and explain why a registered phone plus a fingerprint on it satisfies it while a passcode plus another passcode does not.
7. You will be able to explain dynamic linking and why changing the amount by a penny makes the approval worthless.
8. You will be able to list the exemptions with their figures as they stood in August 2026, and say which of them the United Kingdom has already diverged on or deleted.
9. You will be able to explain why an acquirer-claimed exemption and an issuer-granted one look identical to the shopper and carry opposite consequences when the money turns out to be stolen.
10. You will be able to run the merchant’s arithmetic — roughly eight abandoned sales per fraudulent transaction prevented on a £420 bicycle at twelve per cent margin — and say why it inverts completely on a £6 digital item.

The plain version#

Two strangers are trying to agree about a third person who is not in the room.

The shop does not know you. It knows a card number you typed in. Your bank knows you well, but has never heard of the shop and cannot reach you through its checkout page. There is no wire between them carrying a question like “is this really her?” The only wire carries money, and money messages are not conversations. They are one-line demands with one-word answers. So the industry built a second wire. Not for money. For a question.

Picture a market stall and a bank on opposite sides of a town, with a switchboard operator between them. The stallholder cannot ring the bank directly: he does not know which of the town’s forty banks issued your cheque book, and none of them would take his call anyway. What he can do is hand a sealed note to the switchboard, which reads the first few digits printed on your cheque, identifies the bank, and passes the note across. Your bank opens it, decides, and hands a stamped answer back the same way.

That is the shape of Three-D Secure. Three domains: the shop’s side, the bank’s side, and the switchboard in the middle belonging to neither. Hence three-domain, hence 3-D. It has nothing to do with three dimensions, and the number of people who assume otherwise is one of the small ongoing embarrassments of the payments industry.

Now, what is in the note?

Priya is buying a bicycle for £420 from a British website at ten past eight on a Thursday evening. When she clicks pay, the shop’s software quietly assembles a description of the moment. Not just the card number and the amount. The make and model of her phone, its screen size, its language setting, its time zone. Whether she is in the shop’s own app or in a browser, and which browser. The address she wants the bicycle delivered to, and whether it matches the address her card is registered to. Her email address. How many times she has bought from this shop before. Whether this is a one-off purchase or the first payment of a subscription.

All of that goes into the sealed note, and Priya’s bank now has something it never had in the old world: context. This is the same phone she used to buy petrol on Tuesday. This is her home broadband. This is her actual delivery address. The amount is large but not absurd for her. Nothing here looks wrong.

So the bank says yes. It stamps the note “authenticated”, hands it back, and Priya never sees a thing. The bicycle checkout carries on as though nothing happened. From her side the button just worked. This is the frictionless flow, and on a well-implemented system it is what happens to the large majority of purchases. The check happened. She simply was not asked to participate in it.

Now change one detail. Suppose the phone is one the bank has never seen, the delivery address is in a city Priya has never shopped in, and it is four in the morning. The bank does not feel comfortable. It cannot telephone her, but it can do something better: reach her through the banking app on the phone it does trust. Her checkout pauses, a panel appears, her banking app buzzes. It shows her the merchant’s name and the exact amount, £420, and asks her to approve with her fingerprint. She does. The app tells the bank, the bank tells the switchboard, the switchboard tells the shop, and the checkout resumes. That is the challenge flow. It cost her about eight seconds and it is the reason the whole system exists.

Here is the second half of the chapter, and it is a law rather than a piece of software.

In Europe and in the United Kingdom it is not optional for your bank to check that it is really you. There is a rule called strong customer authentication, and it is a counting rule. There are three kinds of evidence a bank can use: something you know, like a passcode; something you have, like a specific phone the bank has tied to your account; something you are, like a fingerprint or a face.

The bank must use at least two of the three, from different families, and they must be independent, meaning a thief who defeats one has not thereby defeated the other. A passcode plus a second passcode is not two things. A password plus a fingerprint is. A registered phone plus a fingerprint on that phone is, which is why almost every bank in Britain settled on exactly that: the phone proves possession, the fingerprint proves inherence, and the app shows you the amount and the payee so you know what you are approving.

That last part is not decoration. The rule requires the code your phone produces to be welded to that specific amount and that specific merchant. Change the amount by a penny and the approval becomes worthless. This is called dynamic linking, and it exists so nobody can persuade you to approve one thing while a different thing is actually happening.

Now the awkward part, and the reason this chapter has a second half at all.

Checking is expensive. Not in money, in customers. Every time you interrupt a person in the middle of buying something, some of them stop buying. They lose the thread, the app does not open, the phone is upstairs, the passcode does not work, the panel looks like a scam. A rule that challenged everybody for everything would make online shopping meaningfully worse, and regulators knew it when they wrote it.

So the rule comes with holes deliberately cut in it. They are called exemptions, and each names a situation where the risk is low enough that the interruption is not worth it.

If the purchase is small, you can skip the check. In the United Kingdom, as the rules stand at the time of writing in August 2026, small means £25 or less, and only a few times in a row before the bank has to check you properly again. If you are paying the same amount to the same company every month, the bank checks you once at set-up and then leaves you alone. If you have told your bank a particular shop is one you trust, it can stop asking. And the largest hole of all: if the bank runs its own fraud analysis, decides this payment is genuinely low risk, and can prove its overall fraud losses are below a very low threshold, it may skip the check entirely, up to a value ceiling that rises the cleaner its record is.

That last one is worth pausing on, because it is a beautiful piece of regulatory design. It does not tell banks to be safe. It gives them a commercial reward — less friction, more completed sales, happier customers — that they only get to keep while their fraud numbers stay low. Let the fraud rate rise and the reward is taken away automatically.

Finally, the money. Why would a shop volunteer for any of this? Because of who pays when it goes wrong. As the previous chapter showed, when somebody uses a stolen card number online and the real cardholder complains, the default is that the shop loses the goods and the money. But if the shop asked for authentication, and the bank said yes, and the bank was wrong, then in most cases the loss belongs to the bank. The industry calls this the liability shift, and it is the entire commercial engine of 3-D Secure. The shop is not buying security. It is buying a receipt that says: your customer, your call, your loss.

So the shop is caught between two costs. Ask everybody and lose sales to friction. Ask nobody and eat the fraud. The whole of modern e-commerce payments is an argument about where between those two the answer sits, conducted transaction by transaction, in about four hundred milliseconds.

Where the plain version stops being true#

Authentication and authorisation are two different messages, on two different networks, with two different answers, and one does not imply the other. The plain version makes it sound like one continuous conversation. It is not. The 3-D Secure exchange happens first, over the internet, between the shop’s authentication provider and the bank’s authentication server, and it produces a verdict about identity. Only then does the shop send a completely separate authorisation request over the card network, which produces a verdict about money. A cardholder can pass authentication perfectly and be declined ninety milliseconds later for insufficient funds, for exceeding a velocity limit, or because the fraud engine on the authorisation side reached a different conclusion from the one on the authentication side. Those two systems inside the same issuer frequently disagree, because they are usually different products, sometimes from different vendors, sometimes bought a decade apart. Merchants who have never seen the inside of an issuer assume the bank is one mind. It is at least two, and they are not always on speaking terms.

3-D Secure is not strong customer authentication, and strong customer authentication does not require 3-D Secure. These are constantly conflated and they are different categories of thing. Strong customer authentication is a legal obligation on payment service providers, defined in regulation, that says how confident a firm must be about who it is dealing with. Three-D Secure is a messaging protocol published by EMVCo, a body owned by the card schemes, that carries data between merchants and issuers. The protocol is a delivery van; the regulation is the law about what may be in the van. The practical consequence is that 3-D Secure by itself authenticates nobody. The European Banking Authority made this explicit in its opinion of 21 June 2019: information transmitted using a communication protocol such as EMV 3-D Secure does not, on its own, constitute an inherence element, because the protocol carries no biometric measurement. What authenticates the cardholder is whatever the issuer’s access control server does behind the protocol — the push to the banking app, the biometric, the one-time passcode. The van is not the cargo. And in jurisdictions with no authentication law at all, most obviously the United States, 3-D Secure is used enthusiastically anyway, purely for the liability shift.

The liability shift is a private contract, it is narrower than merchants believe, and it sits alongside a statutory allocation that works differently. The shift is not in any statute. It lives in the card schemes’ operating rules, which are commercial documents between the schemes and their licensed members, revised at least annually, and which a merchant is bound by only indirectly through its acquirer’s contract. It covers fraud-type disputes. It does not cover a customer who says the bicycle never arrived, or arrived buckled, or that they cancelled the order, or that the subscription was misdescribed. Those are processing and consumer disputes and the merchant carries them regardless of how beautifully the transaction was authenticated. Running underneath all of this, and quite separate from it, is the statutory position. In the United Kingdom the Payment Services Regulations 2017 provide that where strong customer authentication is required but the payee or the payee’s payment service provider does not accept it, that party must compensate the payer’s payment service provider for the resulting loss. That is law, it runs between institutions rather than between a scheme and a merchant, and it does not care what the scheme rulebook says.

Exemptions are requested by one party and granted by another, and the merchant is rarely the one who decides. The plain version implies a merchant can choose to skip the check. It cannot. A merchant, through its acquirer, can flag a transaction as one it believes qualifies for an exemption, and it can express a preference about whether it wants a challenge. The issuer decides. An issuer that disagrees will challenge anyway, or will decline the authorisation with a response code that means, in effect, go back and authenticate properly. Worse, the two sides can be applying different exemptions with different consequences: an exemption claimed by the acquirer generally leaves the fraud liability with the merchant, whereas the same transaction let through unchallenged on the issuer’s own risk analysis generally does not. Two transactions that look identical to the shopper, both frictionless, can therefore have opposite consequences if the money later turns out to be stolen. Merchants who optimise for “frictionless rate” without knowing which side granted the exemption are optimising a number that does not mean what they think it means.

The technical version#

The three domains and the components in them#

The three-domain model divides the world into the acquirer domain, the issuer domain, and the interoperability domain that connects them.

In the acquirer domain sits the 3DS Requestor, which is the merchant or whoever acts for it, and the 3DS Server, the component that actually speaks the protocol. Historically this was the Merchant Plug-In, and the abbreviation MPI survives in most gateway APIs. In app-based flows there is also a 3DS SDK embedded in the merchant’s mobile application, collecting device information natively rather than through a browser.

In the issuer domain sits the Access Control Server, universally the ACS. It holds the issuer’s authentication logic: its risk model, its decision about frictionless versus challenge, its challenge user interface, and its cryptographic signing. Most issuers do not build one. They buy or rent one from a specialist vendor, which is why the challenge screens of unrelated banks in the same country often look suspiciously alike.

In the interoperability domain sits the Directory Server, the DS, operated by the card scheme. It is the switchboard: it maintains the mapping from card ranges to participating issuers’ access control servers, enforces protocol version compatibility, applies the scheme’s own rules, and routes every message. Each scheme runs its own and brands the consumer-facing product separately — Visa Secure, Mastercard Identity Check, American Express SafeKey, Discover ProtectBuy, JCB J/Secure. The protocol underneath is EMVCo’s and common to all of them; the rules layered on top are each scheme’s own and are not. EMVCo operates none of this. It publishes the specification and runs the approval processes attesting that a given ACS, DS, 3DS Server or SDK conforms to it.

From 3DS1 to 3DS2, and the death of the redirect#

The first generation, formally 3-D Secure 1.0.2, was designed for a web that no longer exists. Its flow was a redirect. The merchant’s plug-in asked the directory whether the card was enrolled, using a verify enrolment request and response pair. If the answer was yes, the shopper’s browser was thrown out of the checkout onto a page hosted by the issuer, where they were asked for a static password. That page was frequently unstyled, frequently unbranded, and frequently arrived without warning. A meaningful proportion of issuers used activation during shopping, which meant a shopper who had never enrolled was asked to invent a password mid-purchase, on a page they had never seen, that looked exactly like the phishing attack it was training them to fall for. Abandonment was severe, mobile support was poor to non-existent, in-app purchases had no sensible flow at all, and the static password was a knowledge factor of low quality that could be captured and reused.

EMVCo’s replacement, EMV 3-D Secure, was published in its first form in 2016, with version 2.1.0 following in 2017 and version 2.2.0 in December 2018. Version 2.3 was published by EMVCo in October 2021, followed by 2.3.1.0 in 2022 and 2.3.1.1 in May 2023. At the time of writing in August 2026, a draft of version 2.4.0.0 had been published by EMVCo on 3 June 2026 with a public comment period closing on 1 July 2026, which means the next revision of the protocol is in flight as this book goes to press and any version-specific detail below should be checked against the current specification.

The first generation was retired on a scheme-by-scheme timetable rather than by EMVCo. Visa’s published notice, article AI10745 dated 4 February 2021, stated that effective 16 October 2021 it would discontinue support of the 3DS 1.0.2 Attempts Server for non-participating issuers, and that effective 15 October 2022 it would discontinue support of 3DS 1.0.2 and all related technology. Mastercard’s timetable ended in the same month. Industry documentation and gateway migration guidance consistently give 14 October 2022 as the date its support for 3DS 1.0.2 ceased, but Mastercard circulates its announcement bulletins to its customers rather than publishing them, so there is no public primary document to cite for it. For practical purposes, from late 2022 onwards, 3DS1 is gone.

The message flow in detail#

Every message in EMV 3DS is a JSON structure with a defined element set and a version number. The sequence, in the order a practitioner sees it in logs, runs as follows.

The 3DS Server may first send a Preparation Request, PReq, to the Directory Server, and receive a PRes. This is not part of any individual purchase; it retrieves the protocol versions supported for a card range and, importantly, the 3DS Method URL if the issuer’s ACS publishes one.

If a 3DS Method URL exists in a browser flow, the 3DS Server loads it in a hidden iframe before authentication begins, letting the ACS run its own device profiling directly against the browser and associate the result with a transaction identifier. The specification bounds how long the 3DS Server waits — ten seconds in the current versions — after which it proceeds regardless. In app flows the equivalent work is done by the 3DS SDK, which gathers operating-system-level device information and encrypts it so only the intended recipient can read it.

Then the substantive message. The 3DS Server sends an Authentication Request, AReq, to the Directory Server, which routes it to the ACS. This carries the context described in the plain version, organised into groups: cardholder data including billing and shipping address, email and telephone; account information such as how long the account has existed with the merchant and whether the card was added recently; purchase data including amount, currency, and whether it is a one-off, a recurring series or an instalment plan; merchant data including the merchant category code and country; browser or SDK device data; and indicators covering the merchant’s challenge preference, any exemption claimed, and whether the request is merchant-initiated.

The ACS replies with an Authentication Response, ARes, and the single most important field in it is transStatus.

A transStatus of Y or A ends the exchange there. That is the frictionless flow. Anything requiring cardholder interaction returns C, and the second phase begins.

In the challenge phase the 3DS Server or SDK exchanges Challenge Request and Challenge Response messages, CReq and CRes, with the ACS. In a browser this renders in an iframe using one of a fixed set of standard challenge window sizes, so the ACS knows in advance how much space it has. In an app the SDK renders the challenge natively using a small vocabulary of interface types — single select, multi select, text entry, out-of-band, and in later versions HTML — so it looks like part of the merchant’s own app rather than a web page bolted into it.

Out-of-band is the important one, and it is the pattern almost all European issuers use. The challenge screen does not ask for anything. It says: approve this in your banking app. The actual authentication happens on a separate channel, on a device the issuer already trusts, and version 2.3 added automated transitions between the merchant app and the banking app so the shopper need not navigate manually and come back. Decoupled authentication, added in version 2.2, goes further: authentication happens entirely outside the payment session, with no challenge screen at all.

When the challenge concludes, the ACS sends a Results Request, RReq, to the Directory Server, which forwards it to the 3DS Server, which acknowledges with an RRes. This is the authoritative result. A merchant that reads the outcome from the browser rather than from the RReq is trusting the client, which is a category of mistake that needs no further explanation.

Version 2.2 also introduced 3DS Requestor Initiated messages, 3RI, which allow an authentication with no cardholder session at all — for a recurring payment, a split shipment or an account verification.

What the authentication produces, and how it reaches the money#

Authentication produces three artefacts that must be carried into the authorisation message, and the carriage is where implementations go wrong.

The first is the authentication value: the Cardholder Authentication Verification Value, CAVV, in Visa’s vocabulary, or the Accountholder Authentication Value, AAV, in Mastercard’s. It is a cryptogram generated by the ACS which the issuer’s authorisation system can verify. It is the proof.

The second is the Electronic Commerce Indicator, ECI, a two-digit field that states what kind of authentication occurred. The schemes number them differently, which is a permanent source of confusion:

The third is the transaction identifier assigned by the Directory Server, dsTransID, which ties the authentication and the authorisation together for dispute purposes.

If these are absent, malformed, or attached to an authorisation whose amount does not match the amount authenticated, the merchant has paid the friction cost and received nothing for it. A substantial share of merchant complaints that the liability shift “did not work” resolve to exactly this.

Strong customer authentication as a legal instrument#

The obligation originates in Directive (EU) 2015/2366, the second Payment Services Directive, Article 97. The operative detail is in Commission Delegated Regulation (EU) 2018/389, the regulatory technical standards on strong customer authentication and common and secure open standards of communication, adopted on 27 November 2017. Article 38 of that regulation provided that it applied from 14 September 2019, save for certain interface documentation provisions which applied from 14 March 2019. That is the date every practitioner means when they say “SCA came in”.

In the United Kingdom the obligation is in regulation 100 of the Payment Services Regulations 2017, SI 2017/752, which requires strong customer authentication when a payer accesses a payment account online, initiates an electronic payment transaction, or carries out any action through a remote channel which may imply a risk of payment fraud or other abuse, and which additionally requires dynamic linking to a specific amount and payee for remote electronic payments. The detailed standards are the United Kingdom’s own version of the technical standards, made by the FCA and reproduced in the FCA Handbook; all UK figures in this chapter are taken from that instrument as it stood in August 2026.

The United Kingdom did not enforce the e-commerce element on the European timetable. The FCA agreed a phased implementation, extended it twice, and stated that the deadline for full compliance for e-commerce card transactions was 14 March 2022. That date, and not September 2019, is when British online checkouts changed.

The mechanics inside the regulation constrain what any authentication product may do. Article 4 requires that authentication produce a single-use authentication code, that no information about the underlying elements can be derived from it, that a failed attempt must not reveal which element was wrong, that consecutive failed attempts be limited to no more than five before the action is blocked, and that a session of online account access must not survive more than five minutes of inactivity. Article 5 sets out dynamic linking: the payer must be made aware of the amount and the payee, the code must be specific to both, and any change to either must invalidate it. Articles 6 to 8 govern the three categories of element and Article 9 requires their independence, including specific mitigations where a single multi-purpose device — that is, a phone — carries more than one element.

What counts as each element was clarified by the European Banking Authority in Opinion EBA-Op-2019-06 of 21 June 2019, which remains the reference document even where it is no longer formally binding. Its conclusions were unwelcome to parts of the industry. Card details printed on the card are neither a knowledge element nor evidence of possession. A one-time passcode is not a knowledge element, because it is not something the user knows in advance. An application installed on a device is not evidence of possession unless it has been bound to that device. A dynamic card security code does evidence possession, and an app or browser bound to a device through a security chip or a private key does too. On the inherence side, fingerprint, iris, face and hand geometry, voice, vein recognition, keystroke dynamics and the angle at which a device is held all qualify; information transmitted using EMV 3-D Secure does not.

The exemptions, with figures, dated#

Every figure below is stated as it stood at the time of writing in August 2026, and every one is capable of changing without the underlying mechanism changing at all.

Three of these deserve expansion.

The contactless exemption is the clearest illustration of why this volume of the book is the perishable one. The European figures of EUR 50 and EUR 150 are as they appear in Regulation (EU) 2018/389 at the time of writing. The United Kingdom diverged progressively, ending with limits of £100 for a single transaction and £300 cumulative, and then abolished the numbers entirely. By the Technical Standards (Strong Customer Authentication and Common and Secure Methods of Communication) (Amendment) Instrument 2025, FCA 2025/62, made under Handbook Notice 136 and announced by the FCA on 19 December 2025, Article 11 was rewritten with effect from 19 March 2026 to remove the monetary caps and replace them with a purely risk-based test: the exemption is available where the payer initiates a contactless transaction identified by the payment service provider as posing a low level of risk. The FCA’s announcement noted that most firms were expected to keep their existing limits for the foreseeable future, so the number a British shopper meets in a shop may not have moved even though the rule behind it has been deleted. Any reader consulting this chapter after 2026 should assume the position has moved again and check the FCA’s technical standards directly.

The recurring transactions exemption is narrower than the phrase suggests. Article 14 covers a series of transactions of the same amount to the same payee. A subscription that varies in amount — metered usage, a variable utility bill, a plan that changes tier — is not within it. Such payments are usually handled instead as merchant-initiated transactions, which are outside the scope of the obligation altogether rather than exempt from it, provided the mandate itself was established with strong customer authentication. The distinction between exempt and out of scope is not pedantry: exemptions are counted, monitored and can be withdrawn, whereas out-of-scope transactions are simply not the subject of the obligation.

The transaction risk analysis exemption is the commercially important one, and it is a bargain rather than a permission. Article 18 allows a provider to skip authentication on a remote electronic payment it has identified as low risk, but only where the value is at or below an exemption threshold value, and only where that provider’s own fraud rate for the relevant transaction type is at or below the reference rate for that band. The rate is calculated under Article 19 as the total value of unauthorised or fraudulent remote transactions divided by the total value of all remote transactions of that type, on a rolling quarterly basis of ninety days, measured across all of that provider’s traffic including transactions it authenticated properly.

The sterling figures come from the FCA’s instrument FCA 2020/70, which converted the euro amounts at a stated rate of £0.8876 to the euro, and they are corroborated by the FCA’s own notification form NOT004 in SUP 15 of the Handbook, which is laid out in the three bands of £440, £220 and £85.

The enforcement mechanism is automatic and is set out in Article 20. A provider whose monitored fraud rate exceeds the applicable reference rate must report that immediately to the competent authority — in the United Kingdom, using form NOT004 — with a description of how it intends to restore compliance. If the rate exceeds the reference rate for two consecutive quarters, the provider must immediately stop using the exemption in that threshold band, and may not resume until its calculated rate has been at or below the reference rate for a quarter, having notified the authority and evidenced the restoration first. Article 21 separately requires quarterly recording of transaction values, fraud values, resulting fraud rates, average values and the count and percentage of transactions under each exemption, broken down between remote and non-remote.

That is the whole design in one sentence: the reward for good fraud control is less friction, and it is withdrawn on a timetable the firm does not control.

Who claims an exemption and who grants it#

There are two independent routes and the distinction determines who carries the loss.

The issuer route is the ordinary one: the merchant sends an AReq, the ACS applies its own risk analysis, decides the transaction is low risk, and returns transStatus Y without a challenge. The issuer has exercised its own exemption, and for liability purposes the transaction is generally treated as authenticated.

The acquirer route runs the other way. The merchant, through its acquirer, marks the authorisation as exempt — commonly under transaction risk analysis, low value, or trusted beneficiary — and performs no authentication at all. This uses the acquirer’s fraud rate rather than the issuer’s and generally leaves fraud liability with the merchant. It is nonetheless widely used, because a merchant with excellent fraud performance may rationally prefer to keep both the liability and the conversion.

Either way the issuer has the final word, and its instrument is the soft decline: an authorisation response that does not mean “no” but “not like this”. Visa’s response code 1A, additional customer authentication required, is the one most often seen in Europe, and code 65, whose older meaning was exceeds withdrawal frequency limit, carries the equivalent sense on Mastercard. Both are recorded in that sense throughout the published response-code documentation of acquirers and gateways, Worldpay’s and Adyen’s among them; the schemes’ own authorisation specifications are not public documents, so the mapping cannot be cited to a primary source here. The correct merchant behaviour is to run a 3-D Secure authentication and retry, not to show the customer a failure. Merchants who did not implement that retry loop discovered in the spring of 2022 that they had built a checkout which declined a substantial share of perfectly good British customers and told them their cards had been refused.

Version 2.2 added the fields that make this expressible: an exemption indicator, a challenge indicator, and support for whitelisting so a cardholder can add a merchant to their trusted beneficiary list during the challenge itself. Delegated authentication, where an issuer contracts out the authentication act to a merchant, wallet or gateway meeting its standards, sits alongside rather than inside the protocol.

Liability, precisely#

The card schemes’ rules provide, in substance, that a merchant obtaining a fully authenticated result is protected against the fraud-type dispute categories: Visa dispute condition 10.4, other fraud, card-absent environment, and Mastercard reason code 4837, no cardholder authorisation, are the two a European merchant meets most often. Attempted authentication, ECI 06 or 01, may also carry protection, but the circumstances are scheme-specific and have narrowed over time. The authoritative statement in every case is the current edition of the relevant scheme’s rules, revised at least annually and reaching the merchant only through its acquirer’s contract. No book is a substitute for them, and this one is not.

What the shift does not do bears repeating. It does not apply to non-fraud dispute categories, nor where the authentication values were not correctly presented in authorisation, nor where the authenticated and authorised amounts differ. It does not protect against a first-party misuse claim dressed as a fraud claim, because at the level of the dispute message those look identical, as the previous chapter set out.

Underneath the scheme rules, the statutory allocation continues to operate. In the United Kingdom, regulation 75 of the Payment Services Regulations 2017 puts the burden of proving authentication and correct execution on the payment service provider and expressly provides that use of the instrument as recorded by the provider is not in itself necessarily sufficient. Regulation 76 requires refund of an unauthorised transaction by the end of the business day following the day the provider becomes aware of it. Regulation 77 sets the payer’s own liability at a maximum of £35 for losses arising from a lost, stolen or misappropriated instrument, disapplies even that where the provider failed to apply strong customer authentication as required, and provides that where the payee or the payee’s payment service provider does not accept strong customer authentication, that party must compensate the payer’s payment service provider for the resulting loss. All of these provisions are as they stood at the time of writing in August 2026.

The cost of friction, in numbers#

Vendor abandonment statistics vary wildly and are rarely reproducible. The supervisory data is better.

The European Banking Authority and the European Central Bank published the 2025 edition of their joint report on payment fraud on 15 December 2025, covering data to the end of 2024. It found that of electronically initiated card payments made with cards issued in the European Economic Area, around 64% of the total value was authenticated with strong customer authentication, while only about 40% of transactions by volume were, the rest travelling under exemptions. Contactless accounted for around 79% of the volume of non-SCA card payments. Within the EEA, the fraud rate on SCA-authenticated card payments was about 0.016% by value, roughly half the rate on non-authenticated ones. Card payment fraud was around seventeen times higher where the counterpart was outside the EEA, where strong customer authentication is not legally required and frequently not applied. Remote card payments carried a fraud rate about thirteen times that of non-remote payments by value, 0.091% against 0.007%. Card fraud on EEA-issued cards totalled EUR 1.329 billion in 2024, within total fraud of about EUR 4.2 billion across all instruments. All of these figures are as published in that report; the next edition will supersede them.

The British picture from UK Finance’s Annual Fraud Report 2026, published on 15 June 2026 and covering 2025, is that remote purchase card fraud losses rose 3% to £423.5 million across 3.2 million cases, an increase of 13% in case numbers, within total payment fraud of £1.28 billion. Unauthorised fraud losses overall fell 5% to £703.4 million. UK Finance specifically noted criminals compromising one-time passcodes in order to register digital wallets or make fraudulent transactions.

That last point matters for anyone designing controls, and it can be stated without giving anybody a manual. The weakest widely deployed possession factor is a one-time passcode delivered over a channel the customer can be talked into repeating aloud. The regulation’s own logic — dynamic linking, so the customer sees the amount and payee they are approving; independence, so compromising one element does not compromise another; device binding, so possession means a specific device rather than knowledge of a code — exists precisely because social engineering attacks the human rather than the cryptography. The defensive conclusions follow: prefer app-based approval bound to a registered device over a passcode sent as text; display amount and payee in the approval itself; treat enrolment of a new device or wallet as a high-risk event deserving its own authentication rather than an administrative step; and monitor for the pattern where authentication succeeds but the surrounding behaviour does not match the customer.

The commercial arithmetic merchants actually run compares two expected costs. Challenge a cohort and you lose some proportion of it to abandonment, immediately and certainly, at the full margin. Do not challenge and you keep those sales but carry the fraud on whatever fraction turns out to be stolen, plus dispute fees, plus the effect on the dispute ratio, which at sufficient volume attracts scheme monitoring programmes and their own charges. On a £420 bicycle at a 12% margin the merchant makes £50.40, while a single fraudulent transaction costs the £420, the goods and a dispute fee: the merchant can therefore afford to challenge and lose roughly eight sales for every fraudulent transaction prevented. On a £6 digital item at a 90% margin the arithmetic inverts completely, which is why the low-value exemption exists and why nobody is asked to fingerprint a newspaper subscription.

What is going to change, and when#

This is the chapter most likely to be wrong first, so it should say plainly where the ground is moving.

In the European Union, the second Payment Services Directive is being replaced by a package comprising a third directive, PSD3, and a directly applicable Payment Services Regulation. Parliament and Council reached provisional political agreement on 27 November 2025, COREPER endorsed the trilogue texts on 22 April 2026, and final compromise texts were published by the Council on 23 April 2026. At the time of writing in August 2026 the author has not verified formal adoption by both institutions or publication in the Official Journal, so the application date should be treated as unsettled. The authentication changes in the agreed texts include an explicit right of access to strong customer authentication for customers without smartphones, with disabilities or with low digital skills; clarified treatment of merchant-initiated transactions, requiring authentication at mandate set-up rather than on each subsequent payment; explicit classification of delegated authentication as outsourcing, with the delegating provider retaining liability; and new technical standards from the European Banking Authority governing exemptions and transaction risk analysis. Reports of the final text also indicate a redefinition permitting two elements from the same category in the specific case of inherence; verify that against the adopted text rather than against this paragraph.

In the United Kingdom, the technical standards themselves are on borrowed time. Legislation.gov.uk records the United Kingdom’s version of Regulation (EU) 2018/389 as subject to revocation by Schedule 1 Part 3 of the Financial Services and Markets Act 2023, listed as a change not yet applied as at 17 August 2026, with firm-facing requirements in assimilated law expected to move into FCA rules. When that happens the article numbers used throughout this chapter will cease to exist even where the substance survives. The contactless amendment of March 2026 previews the pattern: a numerical rule replaced by a risk-based standard, the supervisory burden shifting from compliance with a threshold to demonstrating the quality of a firm’s own monitoring.

And in the protocol, EMVCo’s draft version 2.4.0.0 was out for public comment until 1 July 2026. Version 2.3’s direction of travel — FIDO and WebAuthn data carried inside the authentication message, Secure Payment Confirmation, device binding, automated transitions to and from the banking app — points at where this ends: authentication that is cryptographic, bound to a device, invisible in the common case, and no longer recognisable to the customer as a separate step at all. The regulation will still be counting to two.

47.98 Common wrong ideas#

Wrong: A successful authentication means the payment will go through. Right: Authentication and authorisation are separate messages on separate networks with separate answers, and a cardholder can authenticate perfectly and be declined moments later for funds, velocity or a fraud engine that reached a different conclusion.

Wrong: Three-D Secure is strong customer authentication. Right: One is a messaging protocol published by EMVCo and the other is a legal obligation on payment service providers; the European Banking Authority stated in June 2019 that data carried over EMV 3-D Secure is not itself an inherence element, because the protocol carries no biometric measurement.

Wrong: The liability shift is law. Right: It lives in the card schemes’ operating rules, which are commercial documents revised at least annually and reaching a merchant only through its acquirer’s contract, while the statutory allocation runs underneath it and does not care what the rulebook says.

Wrong: The merchant can decide to skip the check. Right: A merchant can flag a transaction as one it believes qualifies and express a preference, but the issuer decides, and its instrument for disagreeing is the soft decline.

Wrong: A high frictionless rate is a good number on its own. Right: Two identical-looking frictionless transactions can carry opposite liability depending on whether the acquirer claimed the exemption or the issuer granted it, so the rate means nothing without that split.

Wrong: A soft decline means the card was refused and the customer should be told so. Right: Codes such as Visa’s 1A mean “not like this” rather than “no”, and the correct behaviour is to run an authentication and retry, which is precisely what merchants who lost good British customers in spring 2022 had failed to build.

Wrong: A one-time passcode is something the customer knows, so it is a knowledge element. Right: The European Banking Authority’s opinion is that it is not, because it is not something the user knows in advance, and an app is not evidence of possession unless it has been bound to the device.

Wrong: The recurring exemption covers subscriptions. Right: Article 14 covers a series of the same amount to the same payee, so a metered or tier-changing subscription is handled as a merchant-initiated transaction, which is out of scope rather than exempt, and the difference matters because exemptions are counted, monitored and withdrawable.

Wrong: The authentication result can be read from the browser when the challenge finishes. Right: The authoritative result is the Results Request sent by the access control server through the directory to the 3DS Server; reading it from the client is trusting the client.

Wrong: Strong customer authentication arrived in British e-commerce in September 2019. Right: The Financial Conduct Authority granted successive forbearance and set full compliance for card-not-present e-commerce at 14 March 2022, and that is when British checkouts actually changed.

47.99 Chapter summary in 20 lines#

1. Three-D Secure exists because the money wire carries one-line demands and one-word answers, not questions about who is buying, so the industry built a second wire for the question.
2. The three domains are the acquirer’s, the issuer’s and the interoperability domain between them, and the name has nothing whatever to do with three dimensions.
3. The components are the 3DS Server acting for the merchant, the Access Control Server holding the issuer’s authentication logic, and the scheme’s Directory Server acting as switchboard.
4. The authentication request carries context — device, browser, addresses, account age, purchase type, merchant data — which is what allows an issuer to decide without asking the cardholder anything.
5. A frictionless flow is not the absence of a check; it is a check the cardholder was not asked to participate in, and on a good implementation it covers the large majority of purchases.
6. The challenge flow reaches the cardholder through a channel the issuer already trusts, and out-of-band approval in the banking app is the pattern almost all European issuers use.
7. Authentication and authorisation are two messages on two networks, and the two systems inside one issuer are frequently different products that do not always agree.
8. The field that matters is transStatus: Y or A ends the exchange, C begins the challenge, and the Results Request rather than the browser carries the authoritative outcome.
9. Authentication produces an authentication value, an e-commerce indicator and a directory transaction identifier, and a merchant that fails to carry all three into the authorisation has paid the friction and bought nothing.
10. Strong customer authentication is a legal obligation defined in regulation, while 3-D Secure is a delivery van; the van is not the cargo, and in jurisdictions with no authentication law the protocol is used anyway purely for the liability shift.
11. The rule is a counting rule: at least two elements from different families, independent of one another, which is why a registered phone plus a fingerprint on it became the British default.
12. Dynamic linking welds the resulting code to a specific amount and payee, so an approval obtained for one thing cannot pay for another.
13. Checking costs customers rather than money, so the regulation cuts deliberate holes in itself: low value, recurring, trusted beneficiaries, contactless, unattended terminals, corporate processes and transaction risk analysis.
14. Transaction risk analysis is a bargain rather than a permission, because the reward of less friction is withdrawn automatically once the firm’s own fraud rate exceeds the reference rate for two consecutive quarters.
15. The United Kingdom’s figures diverged and then partly vanished: £25 low value, sterling bands of £440, £220 and £85, and Article 11’s contactless caps deleted with effect from 19 March 2026 in favour of a risk-based test.
16. The merchant requests an exemption and the issuer grants it, and the issuer’s way of disagreeing is a soft decline that means “not like this” rather than “no”.
17. An acquirer-claimed exemption generally leaves fraud liability with the merchant while an issuer-granted one generally does not, so two identical frictionless transactions can end in opposite places.
18. The liability shift covers fraud dispute categories only, dies where the authentication values were mispresented or the amounts differ, and cannot separate a first-party misuse claim dressed as a fraud claim.
19. The supervisory data shows authentication working where it is applied and absent where it is not, with about 0.016 per cent fraud by value on authenticated card payments and roughly seventeen times more fraud where the counterpart sits outside the European Economic Area.
20. The direction of travel is cryptographic, device-bound authentication the customer stops noticing, with PSD3 and the migration of the United Kingdom’s technical standards into FCA rules about to renumber almost every citation in this chapter.

Sources: Regulation (EU) 2018/389 and Directive (EU) 2015/2366 via EUR-Lex and legislation.gov.uk; the FCA Handbook Technical Standards on Strong Customer Authentication, instruments FCA 2020/70 and FCA 2025/62, Handbook Notice 136, SUP 15, and FCA statements of 19 December 2025 and on the 14 March 2022 e-commerce deadline; the Payment Services Regulations 2017; EBA Opinion EBA-Op-2019-06; the joint EBA-ECB Report on Payment Fraud of 15 December 2025; UK Finance’s Annual Fraud Report 2026; EMVCo 3-D Secure materials; and Visa’s notice discontinuing 3-D Secure 1.0.2.