Strong Customer Authentication is the most technically demanding requirement in PSD2. The regulation is clear on what must happen — two independent authentication factors from at least two of the three categories (knowledge, possession, inherence) — but the implementation is anything but uniform. This guide covers the exemptions that matter in production, the difference between redirect and decoupled flows, and the error patterns that catch teams out weeks before a go-live date.
What SCA actually requires
Article 4(30) of PSD2 defines strong customer authentication as a procedure based on the use of two or more elements that are independent, in that the breach of one does not compromise the reliability of the others. The three categories are:
- Knowledge — something only the user knows (password, PIN)
- Possession — something only the user possesses (mobile device, hardware token)
- Inherence — something the user is (fingerprint, face scan)
For AIS (Account Information Services), SCA must be applied at the initial consent authorisation, and then at 90-day intervals for recurring access under EBA RTS Article 10. For PIS (Payment Initiation Services), SCA applies to every individual payment initiation — there is no blanket exemption for repeat payees under PISP flows.
The UK position post-Brexit diverges on one meaningful point: the FCA extended the migration deadline for firms under the UK Open Banking Implementation Entity (OBIE) standard, and the UK has not adopted the EBA's Q&A interpretations verbatim. UK OBIE-compliant ASPSPs implement SCA via the consent authorisation redirect with an authentication mechanism of the ASPSP's choosing, whereas Berlin Group NextGenPSD2 implementations in the EU allow more variation in the handoff protocol.
The exemption landscape
Not every transaction requires full SCA. The EBA RTS on SCA and Common and Secure Open Standards of Communication defines several exemptions that Payment Service Providers can apply — subject to fraud rate thresholds. These are the ones that matter for fintech builders:
Low-value transactions (Article 16)
Contactless and remote electronic payments under €30 may be exempted, up to a cumulative €100 or 5 consecutive transactions since the last SCA application. In practice this exemption is used primarily by card issuers, not open banking PISP flows — but it is relevant context when comparing PIS to card rails.
Transaction Risk Analysis (TRA) (Article 18)
TRA exemptions allow SCA to be skipped where the PSP's real-time fraud scoring determines the transaction is low risk. The exemption thresholds are:
- Transactions up to €100 — available if the PSP's fraud rate for remote electronic card transactions is below 0.13%
- Transactions up to €250 — available below 0.06%
- Transactions up to €500 — available below 0.01%
For open banking PISP flows, the ASPSP applies SCA unless the PISP requests an exemption and the ASPSP accepts it. The ASPSP is never obliged to honour a TRA exemption request — it retains the right to step up. Your integration must handle the step-up redirect even when you believe a TRA exemption should apply.
Trusted beneficiaries (Article 13)
Once a user adds a payee to their trusted beneficiaries list (maintained by the ASPSP), subsequent payments to that payee may be exempted from SCA. Not all ASPSPs implement this; it is more common in German and Dutch bank implementations than in UK ones.
Corporate payments (Article 17)
Payments initiated using dedicated corporate cards or via dedicated corporate payment processes operated by large corporates may be exempted. In practice this means institutional treasury platforms, not typical fintech use cases.
Redirect vs decoupled authentication
This is where implementations diverge most significantly across ASPSPs.
Redirect flow
The default and most common approach. Your application redirects the PSU (Payment Service User) to the ASPSP's authentication UI, the PSU completes SCA there, and the ASPSP redirects back to your redirect_uri with an authorisation code. You exchange the code for an access token using the ASPSP's token endpoint.
The redirect flow has two implementation variants: same-device redirect (the PSU stays in the same browser session) and app-to-app (the PSU's browser deep-links into the bank's mobile app, which performs SCA, then returns to your app). UK banks with strong mobile apps — particularly those adhering to OBIE's App-to-App guidelines — prefer app-to-app because it avoids SMS OTP friction.
Engineering concern: redirect URIs must be pre-registered and exactly match what you send in the authorisation request. A trailing slash mismatch or a port number discrepancy in your redirect_uri will produce a 400 response from the ASPSP's authorisation endpoint with minimal error detail. Register every variant you intend to use during sandbox testing, not just production.
Decoupled flow
In a decoupled flow, the PSU authenticates on a separate device (typically their banking app on a mobile phone) while the initiation happens on a desktop or API call. The ASPSP returns a status endpoint you poll — or notifies you via webhook — once authentication is complete.
Decoupled flows are specified in Berlin Group NextGenPSD2 XS2A v1.3+ and are common in Nordic bank implementations (Norwegian BankID, Swedish BankID). UK OBIE does not formally specify a decoupled flow; UK banks use redirect with app-to-app as the equivalent.
The implementation pattern for decoupled flows involves:
- Sending the payment or consent initiation request with
"scaApproach": "DECOUPLED"in the header (Berlin Group) or the equivalent parameter for your ASPSP - Receiving a
scaStatusofreceivedorstarted - Polling the
scaStatusHrefURL at a reasonable interval (3–5 seconds) until status reachesfinalisedorfailed - Handling timeout gracefully — ASPSP session timeouts vary from 5 to 30 minutes
The 90-day re-authentication requirement
Under EBA RTS Article 10, ASPSPs may require PSUs to re-authenticate with SCA every 90 days for AIS access. "May require" became "will require" in practice — most UK and EU banks enforce the 90-day window strictly.
What this means for your integration:
- Store consent expiry timestamps and check them before making AIS calls
- Design a re-consent user journey — pushing users through the bank authorisation redirect again is friction; prepare your product team for the 90-day drop-off conversation
- Some ASPSPs return an HTTP 401 or a
TOKEN_INVALIDerror once the 90-day window passes; others return a specificCONSENT_EXPIREDerror. Your error handling must cover both patterns - The 90 days is measured from last successful SCA, not from consent creation — so a user who re-authenticates on day 87 resets the clock
UK OBIE extended the 90-day re-authentication requirement's strictness following industry feedback, allowing some "low friction" renewal mechanisms for accounts that have been in continuous active use. However, this is ASPSP-discretionary; you cannot rely on it in production code.
Common integration failure modes
Missing PKCE implementation
All UK OBIE-compliant ASPSP authorisation endpoints require PKCE (Proof Key for Code Exchange, RFC 7636) for public clients. If your authorisation requests don't include code_challenge and code_challenge_method=S256, you will receive a 400 error — often with a generic "invalid_request" message that does not name PKCE specifically. This is one of the most common sandbox-to-production failures.
JWS signing requirements on payment consents
PISP payment consent objects must be signed as JWS (JSON Web Signatures) using your eIDAS QWAC certificate (in the EU) or your FCA-issued certificate (in the UK). Unsigned payment consent requests will be rejected at the ASPSP's consent endpoint. Many teams discover this requirement late because sandbox environments sometimes accept unsigned requests for convenience.
State parameter not round-tripped
The state parameter in the OAuth 2.0 authorisation request must be verified when the ASPSP redirects back. Skipping this check is both a security issue (CSRF vulnerability) and a practical problem: some ASPSPs silently strip the state parameter in error conditions, producing a redirect to your URI with no state — which your application must handle as a failed authorisation, not a successful one.
Assuming a single SCA approach per bank
Many ASPSPs support multiple SCA approaches and will return a list in the response to your consent initiation request. Your code must inspect the returned scaApproaches array and select the most appropriate one for your flow — not hardcode "REDIRECT" regardless of what the bank returns.
Building on top of an aggregator's SCA layer
The alternative to implementing all of the above yourself is integrating through an aggregator that has already built the SCA orchestration layer across all ASPSPs in its network. The trade-off is straightforward: you sacrifice some control over the authentication UX in exchange for not having to maintain per-ASPSP SCA logic as banks upgrade their authentication implementations.
What you should verify before relying on an aggregator's SCA layer:
- Does it handle app-to-app redirects correctly on iOS and Android?
- Does it surface ASPSP-specific SCA error codes in a normalised form, or does it swallow them?
- Does it support your re-consent flow requirements at the 90-day boundary?
- Is the authorisation URL generation deterministic (important for signed consent objects)?
BankLyra is not a bank. We do not hold deposits, issue accounts, or provide payment accounts. We are a regulated AISP and PISP operating under FCA authorisation, and when you integrate through our API, the SCA orchestration — redirect generation, PKCE, JWS signing, ASPSP-specific flow selection — happens inside our infrastructure. Your application receives a single authorisation URL and then handles the callback.
