A deposit page loads, the client taps pay, and somewhere in the next 900 milliseconds the issuing bank has already decided whether this person will see a challenge screen. That decision is made on data the merchant sent, not on the card number. Understanding which fields matter is the difference between a checkout that converts and one that leaks clients to a competitor with the same licence and a better payment stack.
3-D Secure 2, the EMVCo specification usually written EMV 3DS, replaced the old redirect-and-password flow that everyone hated. The version most firms are running today is a later revision of that spec, and the mechanics are worth knowing in detail because the merchant controls more of the outcome than the sales deck from a processor usually admits.
What actually moves between the parties
When a payment starts, the merchant's 3DS server builds an authentication request and sends it to the directory server operated by the card scheme, which routes it to the issuer's access control server. That request carries far more than an amount. It includes the device fingerprint collected by a hidden iframe, the browser and screen characteristics, the IP address, the billing and shipping address, the cardholder email and phone, the account age on the merchant's side, how many transactions this account made in the last day and the last six months, and whether the card is being added to a stored profile.
The issuer scores all of it. If the risk score is low, it returns an authenticated result with no interaction at all, the frictionless flow. If the score is high or the issuer needs to satisfy a regulatory obligation, it returns a challenge, and the cardholder sees a push notification in their banking app or a one-time code. The authorisation message that follows then carries proof of authentication, which is what shifts fraud liability.
Half-populated 3DS requests are the most common self-inflicted wound in this business. If the integration sends only the amount, currency and card, the issuer has nothing to score with and defaults to a challenge, or simply declines. Data quality is the lever, and it is free.
Frictionless is earned, not requested
A merchant can signal a preference for no challenge, but the issuer decides. The signals that reliably push a transaction towards frictionless are consistency signals: the billing address matching what the bank has on file, an email domain and phone that the issuer has seen with this card before, a device that has transacted successfully at this merchant, and a merchant whose fraud rate is low enough that the acquirer can flag a transaction risk analysis exemption.
The opposite signals are equally clear. A new account created ten minutes ago, a card in one country, an IP in another and a phone number in a third, an amount at a round number well above the client's usual size. Every one of those is normal behaviour for a legitimate trader on holiday, and every one of them raises the challenge rate. This is why approval rate work starts with the onboarding form rather than the payment page.
Exemptions, and why trading rarely gets them
Under the European strong customer authentication rules, most remote card payments must be authenticated, with a defined set of exemptions. Low value payments below 30 euro can skip authentication until a counter of consecutive exempt transactions or cumulative value is reached. Transaction risk analysis allows a provider with a measured fraud rate under the regulatory thresholds to exempt larger amounts, with the ceiling rising as the fraud rate falls. Merchant-initiated transactions and beneficiaries the cardholder has whitelisted with their bank also fall outside.
| Flow | Cardholder sees | Fraud liability |
|---|---|---|
| Frictionless, authenticated | Nothing | Issuer |
| Challenge, passed | App push or one-time code | Issuer |
| Challenge, abandoned | Drop-off at the challenge screen | No payment |
| Exemption applied | Nothing | Merchant or acquirer |
The practical problem for brokers and prop firms is category coding. Funding a trading account is typically treated as a quasi-cash or securities purchase rather than ordinary retail, and issuers apply their strictest rules to those merchant category codes. Exemption flags sent by the acquirer are frequently overridden. Firms operating under a high-risk merchant account should model the challenge rate as close to universal for first deposits and design the checkout so a challenge does not feel like a failure.
Liability shift, and what it does not cover
A successful authentication moves fraud liability to the issuer for the relevant scheme reason codes. If the cardholder later claims they never made the payment, the merchant is usually protected. What survives is everything else: claims that the service was not provided, that the account was closed without a payout, that a subscription kept billing. Those are dispute categories the merchant must answer with evidence, and they are covered in our guide to how chargebacks work.
There is a second trap. Some firms interpret the liability shift as a reason to relax fraud screening. Schemes monitor fraud-to-sales ratios regardless of who paid, and a merchant whose ratio drifts into a monitoring programme faces fees, remediation deadlines and eventually termination by the acquirer. Authentication is a control, not an amnesty.
Building it so it does not cost you deposits
Three engineering decisions carry most of the weight. Collect and pass the full optional data set, including account age, prior transaction counts and a verified phone. Render the challenge inline in the deposit flow rather than in a popup that mobile browsers block, and keep the client on a page that shows the deposit continuing rather than a blank spinner. Retry intelligently on soft declines, with a different route where you run more than one acquirer, which is the entire argument for routing between processors.
Everything above assumes the firm can see its own numbers. Challenge rate, abandonment at the challenge screen and approval rate by issuer country belong on a dashboard in the back office, not in a monthly PDF from a processor. When a broker back office logs the authentication outcome alongside the authorisation result, the pattern behind a bad week is usually visible within an hour.
"Firms email me about their processor when the real problem is their own integration sending eight fields where the spec allows fifty. The bank is not being difficult. It is guessing, because you gave it nothing to work with."
— Roman Onta, Executive Director, SINGUARD
Key Takeaways
- The issuer decides frictionless or challenge from the data the merchant sends, so a sparse 3DS request costs approvals directly.
- Successful authentication shifts fraud-coded chargeback liability to the issuer, and leaves service disputes with the merchant.
- SCA exemptions exist, but quasi-cash and securities coding means trading deposits rarely benefit from them.
- Track challenge rate and challenge abandonment per issuer country, otherwise a routing problem looks like a market problem.
Frequently Asked Questions
What is the difference between 3DS1 and 3DS2?
3DS1 redirected every cardholder to a static password page. 3DS2 sends a rich set of device, session and order data to the issuer before the payment, so most authentications can be approved silently and only riskier ones get a challenge, usually a push or one-time code in the banking app.
Does 3-D Secure 2 stop chargebacks?
It shifts liability for fraud-coded chargebacks to the issuer when authentication succeeded, so those disputes usually cannot be charged back to the merchant. It does nothing for service or product disputes, which stay with the merchant and are argued on evidence.
Can broker deposits use SCA exemptions?
Rarely. Deposits into trading accounts are commonly coded as quasi-cash or securities purchases, and issuers treat those categories as high risk, so they tend to challenge regardless of the exemption flag the acquirer sends. Plan for a challenge on most first-time deposits.