Open Banking and PSD2: Strong Customer Authentication (SCA) Implementation

The Mechanism of Trust: How SCA Actually Works Under PSD2

Strong Customer Authentication (SCA) is frequently mischaracterized as generic "multi-factor authentication," yet this label obscures the specific cryptographic and procedural mechanisms mandated by the Payment Services Directive 2 (PSD2). Under European Banking Authority (EBA) guidelines, SCA is not merely a login interface; it functions as a state machine that validates a transaction against three distinct criteria: independence of factors, cryptographic binding to the transaction amount and beneficiary, and dynamic linking. If a fintech application fails to implement the dynamic linking requirement, the transaction is technically non-compliant, regardless of the complexity of the password used.

Consider a scenario where a user, "Alice," initiates a payment of €500 to "Bob" via a third-party provider (TPP) application. The system must verify that Alice possesses two out of three factors: something she knows (a PIN) and something she has (a mobile device). These two factors must be cryptographically bound to the specific instruction to move €500 to Bob's IBAN. If the system authenticates Alice but allows the TPP to modify the beneficiary address before the bank processes the transfer, the SCA mechanism has failed. The authentication must remain valid only for that specific data set. This is why PSD2 mandates that the authentication event and the payment initiation event are tightly coupled in time and data structure.

The SCA Mechanism: Independence and Binding

The core of SCA lies in the "two out of three" factors: Knowledge (something the user knows), Possession (something the user has), and Inherence (something the user is). The EBA Guidelines explicitly require that these factors be independent. This means that compromising one factor must not compromise the others. For instance, knowing a password (Knowledge) should not reveal a fingerprint (Inherence), nor should a stolen mobile device (Possession) allow a user to bypass a PIN (Knowledge) without the biometric check.

It is crucial to distinguish between the three criteria for SCA compliance—Independence, Binding, and Dynamic Linking—and the three authentication factor categories. Compliance requires satisfying all three criteria, but the user authentication itself only requires two of the three factors. This distinction ensures that the authentication event cannot be replayed or manipulated by an attacker who has compromised a single vector. The mechanism relies on the cryptographic binding of the authentication data to the transaction details. The bank's backend must verify that the transaction_amount and beneficiary_id in the API payload match the exact data used to generate the SCA response. If a TPP initiates a payment for €500 to Bob, the SCA challenge presented to Alice must explicitly display "€500 to Bob." If the TPP then attempts to change the amount to €600 before sending the final payment instruction to the bank, the bank's validation logic must reject the transaction because the cryptographic signature or the transaction data hash no longer matches the authenticated payload.

This mechanism protects against man-in-the-middle attacks where a compromised TPP or network layer modifies the transaction parameters after the user has authenticated. Commission Delegated Regulation (EU) 2018/389 (RTS on SCA) explicitly states in Article 26 regarding dynamic linking requirements that the authentication process must ensure that the payment service provider cannot alter the payment details without invalidating the authentication. This is not a UI check; it is a backend validation rule enforced by the Account Servicing Payment Service Provider (ASPSP).

The OAuth2 Dance: Binding the Token to the Transaction

The primary vehicle for implementing SCA in Open Banking is the OAuth 2.0 protocol, specifically the Authorization Code Grant type with Proof Key for Code Exchange (PKCE). This flow ensures that even if an attacker intercepts the authorization code, they cannot exchange it for an access token without the original secret verifier generated by the client.

When Alice's TPP requests access to her account, the TPP generates a random code_verifier and derives a code_challenge. The bank's API receives this challenge. Upon successful SCA (e.g., Alice enters her PIN and scans her fingerprint), the bank issues an authorization code. The TPP then sends this code back along with the original code_verifier. The bank hashes the verifier and matches it against the challenge. If they match, the bank issues an access token. Crucially, this token is scoped to the specific consent Alice granted.

# Example: The PKCE Challenge-Response Flow
# 1. Client generates verifier
code_verifier = generate_random_string()
code_challenge = base64url_encode(sha256(code_verifier))
 
# 2. Authorization Request
GET /oauth2/v3/authorize?client_id=TPP_ID&redirect_uri=https://tpp.com/callback&response_type=code&scope=psp&code_challenge=code_challenge&code_challenge_method=S256
 
# 3. Post-SCA Token Exchange
POST /oauth2/v3/token
{
  "grant_type": "authorization_code",
  "code": "AUTH_CODE_RECEIVED",
  "client_id": "TPP_ID",
  "code_verifier": "code_verifier",
  "redirect_uri": "https://tpp.com/callback"
}

This mechanism prevents the "replay attack" where a malicious actor steals a session and reuses it. The token issued is ephemeral and bound to the specific consent scope. In the context of PSD2, the consent object itself becomes a critical artifact. It defines the accounts accessible and the duration of access. Once the consent expires, the token becomes useless, enforcing a strict lifecycle on data access that aligns with the "least privilege" principle.

Dynamic Linking and the Transaction Context

The most misunderstood aspect of SCA implementation is "dynamic linking." This requirement dictates that the authentication data used to verify the user must be included in the payment initiation request. The bank's backend must receive the exact same transaction details that were presented during the authentication step.

If the TPP then attempts to change the amount to €600 before sending the final payment instruction to the bank, the bank's validation logic must reject the transaction because the cryptographic signature or the transaction data hash no longer matches the authenticated payload. This is not a UI check; it is a backend validation rule. The bank must verify that the transaction_amount and beneficiary_id in the API payload match the data used to generate the SCA response.

This mechanism protects against man-in-the-middle attacks where a compromised TPP or network layer modifies the transaction parameters after the user has authenticated. The EBA Regulatory Technical Standards (RTS) explicitly state that the authentication process must ensure that the payment service provider cannot alter the payment details without invalidating the authentication.

Transaction Risk Analysis: The Exemption Loophole

While SCA is mandatory, the regulations allow for exemptions if the transaction risk is deemed low. This is where Transaction Risk Analysis (TRA) comes into play. TRA is not a static rule; it is a real-time calculation performed by the Account Servicing Payment Service Provider (ASPSP).

The ASPSP evaluates multiple risk indicators: the location of the user, the frequency of transactions, the device fingerprint, and the historical behavior of the account holder. If the calculated risk score falls below a specific threshold, the ASPSP can signal the TPP to proceed without SCA. This is a critical mechanism for user experience but introduces a complex dependency.

For a fintech to implement TRA, it must pass specific data points to the bank during the payment initiation request. The bank then returns a response indicating whether SCA was exempted. If the bank does not return an explicit exemption, the TPP must enforce SCA. This creates a race condition in the API design: the TPP must wait for the bank's risk assessment before proceeding. If the bank's risk engine is slow or unavailable, the transaction fails.

Relying heavily on TRA exemptions is a strategic risk for fintechs. While it improves conversion rates, it shifts the liability for fraud entirely to the consumer or the TPP in certain jurisdictions if the exemption logic is flawed. A robust implementation treats TRA as a fallback, not the primary path.

Implementation Pitfalls: 3DS vs. Open Banking

A common error in Open Banking implementation is conflating 3D Secure (3DS) with Open Banking SCA. 3DS is designed for card-not-present e-commerce transactions where the card issuer verifies the cardholder. Open Banking SCA is designed for direct account-to-account transfers via APIs.

In a 3DS flow, the merchant redirects the user to the issuer's authentication page. In an Open Banking flow, the authentication happens within the TPP app or via the bank's API directly. The artifacts differ: 3DS uses a CVC and a one-time password (OTP) validated by the card scheme, while Open Banking SCA relies on the OAuth2 token and the specific consent grant.

Mixing these flows leads to compliance failures. If a fintech attempts to use 3DS to satisfy SCA requirements for a direct bank transfer, they are not meeting the PSD2 definition of SCA because the authentication is not linked to the specific payment instruction in the same way. The bank must validate the SCA result directly through the API, not through a redirect to a card scheme.

Furthermore, the handling of "white-listed" beneficiaries is a frequent point of confusion. PSD2 allows for an exemption if the beneficiary has been white-listed by the user. However, this exemption requires that the beneficiary was added via a secure channel and that the user explicitly authorized the addition. The mechanism here is the "add beneficiary" API call, which itself triggers an SCA event. Subsequent payments to that beneficiary may be exempt, but only if the initial SCA event was recorded and the beneficiary remains in the trusted list.

Common Pitfalls

• Improper Exemption Handling: Failing to strictly enforce SCA when the bank does not return an explicit TRA exemption, leading to non-compliant transactions.
• 3DS and SCA Confusion: Attempting to satisfy Open Banking SCA requirements using 3DS redirects, which do not provide the necessary cryptographic binding for account-to-account transfers.
• TRA Dependency Risks: Designing user flows that assume TRA exemptions will always succeed, causing transaction failures when the bank's risk engine is slow or denies the exemption.

Practical Takeaways

• SCA is a State Machine: View authentication not as a static login but as a state transition that must be validated against specific transaction data before settlement.
• Dynamic Linking is Non-Negotiable: The data authenticated by the user must be cryptographically bound to the final payment instruction; any modification invalidates the trust chain.
• TRA is a Fallback, Not a Default: Design your architecture to expect SCA enforcement by default, treating TRA exemptions as conditional optimizations rather than primary paths.

FAQ

Q: Can I use 3D Secure instead of Open Banking SCA? A: No. 3DS is for card payments, while Open Banking SCA is for direct API-based account transfers. They rely on different trust models and cryptographic bindings.

Q: When can a transaction be exempt from SCA? A: Only if the ASPSP performs a Transaction Risk Analysis (TRA) and explicitly signals an exemption, or if the beneficiary is white-listed following a secure enrollment process.

Q: What are the technical requirements for dynamic linking? A: The payment initiation request must include the exact transaction_amount and beneficiary_id that were presented during the SCA challenge, ensuring the cryptographic signature matches the payload.

Conclusion: Security as a Protocol, Not a Feature

Implementing SCA under PSD2 is not about adding a login screen; it is about restructuring the entire data flow of a payment transaction. The mechanism relies on the independence of factors, the cryptographic binding of the authentication to the specific transaction details, and the dynamic risk analysis performed by the bank.

For a fintech, this means the API contracts must be rigid. The payment_initiation request must include the exact data that was authenticated. The consent object must be the source of truth for data access. And the TRA response must be treated as a conditional gate, not a default state. Failure to adhere to these mechanisms does not just result in a poor user experience; it results in a regulatory violation that exposes the institution to significant liability. The security of Open Banking lies in the strict adherence to these protocol-level constraints, ensuring that the trust established at the moment of authentication travels with the transaction to the moment of settlement.