Strong Customer Authentication explained — for UK accountants in 2026.

The short answer

SCA is two-factor authentication for online and card-not-present payments — mandated under PSD2. The customer must prove identity using two of: something they know, something they have, something they are. Most online card transactions are subject to it by default; several exemptions exist (low-value, recurring, merchant-initiated, Trusted Beneficiary, Transaction Risk Analysis). Accountants get asked about SCA when client payments decline; understanding the exemptions and the issuer-versus-merchant distinction helps you give useful answers.

1. The three factors

SCA requires two of three independent authentication elements:

Any two of these in combination is “strong” authentication. In practice, the most common UK flow is banking-app push (have) + fingerprint or face (are) on a smartphone — one tap covers two factors.

2. What’s in scope, what isn’t

In scope by default:

• Online card payments (card-not-present).
• Online banking logins for accessing accounts.
• Setting up Open Banking access (AISP / PISP).
• Re-authentication for Open Banking on the 90-day cycle.
• Setting up new direct debits.

Out of scope:

• In-store contactless under £100 per transaction (cumulative limits apply).
• Mail-order and telephone-order (MOTO) transactions — no authentication channel.
• Anonymous payment instruments (prepaid cards in certain configurations).
• Corporate cards with specific commercial agreements (some are exempt depending on bilateral terms).
• Subsequent transactions in a recurring series after the first SCA-authenticated set-up.
• Merchant-initiated transactions where the customer has previously authorised the merchant to charge them.

3. The five merchant-side exemptions you should know

These aren’t the customer’s choice — they are flags the merchant’s payment service provider attaches to an authorisation request. The customer’s bank can accept the exemption or insist on SCA anyway.

1. Low-value transactions (LVT). Payments under €30 / £30 are exempt — up to 5 consecutive transactions or €100 / £100 cumulative since the last SCA. After that cap, the next transaction requires SCA, even if it’s small.
2. Trusted Beneficiary (TB). The customer adds a specific merchant to their bank’s trusted list (usually via their banking app). Future payments to that merchant are exempt from SCA at the issuer’s discretion. Good UX for repeat suppliers and subscriptions.
3. Recurring transactions. First in a series requires SCA. Subsequent same-amount payments to the same merchant within the series are exempt. The classic example: monthly Netflix subscription — you SCA once at signup, never again at the same amount.
4. Merchant-initiated transactions (MIT). Where the customer has previously authorised the merchant to initiate variable payments — utility companies, telcos, taxi-app post-ride fares. The initial authorisation requires SCA; the MITs that follow do not.
5. Transaction Risk Analysis (TRA). The payment service provider can exempt low-risk transactions based on its own fraud rate. Tied to fraud-rate bands — the lower the PSP’s fraud rate, the more transactions they can exempt. Generally only applies to transactions under €500 (€250 / €100 for higher fraud-rate bands).

4. Why an “exempt” transaction still declines

Three patterns dominate the “why did this fail” question:

• The issuer overrides the exemption. The exemption flag is a request; the customer’s bank ultimately decides whether to accept it. Many UK banks have conservative fraud models that ignore the merchant’s exemption flag for certain transaction profiles — particularly business cards, unusual geolocations, and merchants the customer hasn’t paid before.
• The merchant didn’t request the exemption. Exemptions have to be flagged on the authorisation request via the 3DS2 protocol. If the merchant’s checkout flow doesn’t flag the exemption, SCA applies even if the transaction qualifies.
• Separate fraud rule fires. Even when SCA passes (or is exempt), the bank’s independent fraud rules can decline the transaction. SCA isn’t the only check — it just covers authentication, not fraud-risk scoring.

5. The B2B context — why business cards decline more

Accountants who work with clients running e-commerce or who do a lot of B2B card payments will notice business cards decline more often than consumer cards. Three reasons:

• Business cards have higher transaction values and are more attractive to fraudsters. Banks compensate with more aggressive fraud-decline rates.
• Business cards are used across more geographies and merchants than consumer cards, generating more anomaly signals for the bank’s fraud engine to react to.
• Some business card agreements include commercial-card-specific SCA exemptions — but those exemptions only apply when the bank and the merchant’s acquirer both support them. Coverage is partial.

Practical advice for clients: if a specific business card persistently declines, talk to the bank’s commercial banking team about lifting the fraud rules or adding the merchants as Trusted Beneficiaries. If you’re the merchant, work with your payment processor on 3DS2 optimisation.

6. The FCA Payments Vision — where SCA is going

The FCA published the Payments Vision in late 2024. SCA-relevant signals:

• More emphasis on Transaction Risk Analysis as the primary fraud-detection mechanism, rather than blanket SCA challenges on every online transaction. The intent is reducing customer friction without weakening fraud protection.
• Longer-lived re-authentication windows for low-risk recurring payments. Today’s 90-day Open Banking re-auth cycle may extend to 180 days or longer for certain cases.
• Better customer experience on the SCA flow itself. In-app authentication via the bank’s mobile app is becoming the standard; out-of-band SMS (known to have SIM-swap fraud vulnerabilities) is being phased down.
• Authentication for new use cases — smart-data feeds beyond banking (energy, telecoms, transport) under the Data (Use and Access) Bill will introduce their own SCA-equivalent authentication patterns.

SCA isn’t going away. It’s being refined to put the right friction in the right place.

7. Practical advice for firms helping clients

Five questions to walk through when a client reports SCA- related problems:

1. Is the card UK-issued? Non-UK cards sometimes work poorly with UK SCA flows.
2. Is the cardholder receiving and acting on the challenge? SCA challenges often go to a phone the cardholder doesn’t have nearby, or to a banking app the cardholder doesn’t log into often.
3. Have they tried Trusted Beneficiary status? Adding repeat suppliers to the bank’s trusted list removes most future SCA challenges for those payments.
4. Is the bank’s fraud model triggering separately? If the issue is fraud-decline rather than SCA failure, switching to a different card or a different acquirer sometimes resolves it.
5. Is the merchant requesting exemptions correctly? If you’re the merchant client (e-commerce, subscription business), check with your payment processor whether their 3DS2 implementation requests appropriate exemptions on each transaction.

8. How SCA shows up in SmartBooks

Three places SCA appears in the SmartBooks workflow:

• Open Banking set-up. When a client connects a bank account via Yapily, the bank prompts an SCA challenge as part of the consent flow. SmartBooks doesn’t see the credentials — the SCA happens between the client and the bank.
• 90-day Open Banking re-authentication. Every 90 days, the client is prompted to re-authenticate access. This is a form of ongoing SCA. SmartBooks surfaces the renewal notice ahead of expiry to reduce feed-disruption surprise.
• Payment initiation via Adfin. When SmartBooks initiates a card payment or direct debit on the user’s instruction, Adfin handles the SCA flow with the customer’s card issuer. For recurring payments after the first, the recurring-transactions exemption typically applies.

In none of these does SmartBooks store SCA credentials or authentication tokens — those stay with the bank or the regulated payment service provider.

Related guides

• Open banking & PSD2 for UK accountants — SCA sits inside the broader PSD2 framework.
• APP fraud rules for UK accountants — what SCA doesn’t prevent.
• Trust & security — SmartBooks’ sub-processor list, including Adfin and Yapily.
• Privacy notice — how authentication data is handled (it isn’t stored).

FAQ

A note on advice

This guide is general operational guidance on Strong Customer Authentication for UK accountancy firms. It is not regulatory or technical advice for a specific case. SCA implementation specifics vary by issuer, acquirer and payment service provider; verify with the relevant parties for specific transaction flows. The FCA’s regulatory technical standards governing SCA are evolving through 2026–2028 under the Payments Vision — check current FCA publications for the latest position.