Strong Customer Authentication (SCA)
SCA is the PSD2 requirement that electronic payments be authenticated with two of three independent factors — knowledge, possession, inherence — enforced through 3-D Secure on cards and natively in open banking flows.
What it means
Strong customer authentication is the PSD2 rule that electronic payments in the EU and UK must be verified with at least two of three independent factors: something the customer knows (a PIN or password), something they possess (a phone, a card), and something they are (a fingerprint or face). On cards it's enforced through 3-D Secure challenges; in open banking flows the customer authenticates inside their own banking app, so SCA is satisfied natively rather than added as an extra step.
Why it matters for operators
SCA is where deposit conversion dies or survives. Every added authentication step loses a share of depositors, so the acceptance rate an operator actually sees depends heavily on how the exemption regime is worked. PSD2 allows exemptions for low-value transactions, for transactions a bank's transaction risk analysis (TRA) scores as low risk, and for merchants a customer has whitelisted as a trusted beneficiary — but exemptions are requested by the acquirer and granted or refused by the issuer, and issuer behaviour toward gambling merchants is often conservative. Two operators with identical traffic can see materially different challenge rates depending on which acquirers they route through and how exemptions are flagged.
This is a core reason payment orchestration earns its keep in regulated European markets: routing low-risk traffic through exemption-eligible paths and choosing acquirers by observed challenge rates is measurable revenue, not plumbing. It also explains part of pay-by-bank's appeal — the SCA already happened in the bank app the player uses daily, so after first use the flow tends to convert well with no separate 3DS hurdle.
Example
An operator's card conversion drops several points after a major issuer tightens its 3DS challenge policy for gambling merchants. The orchestration layer responds by flagging low-value deposits for the low-value exemption and shifting eligible volume to an acquirer whose TRA profile earns more frictionless approvals — recovering most of the lost conversion without touching the cashier UI.