Implementing PSD2 SCA: Cryptographic Intent Binding

The Cryptographic Binding of Intent: Implementing PSD2 SCA

Strong Customer Authentication (SCA) under the Revised Payment Services Directive (PSD2) is often misunderstood as a simple two-factor authentication (2FA) requirement. For fintech developers and compliance engineers, this simplification is dangerous. SCA is a regulatory mandate that enforces a specific cryptographic state: the binding of a user’s authenticated intent to a specific transaction context. Failure to implement this binding correctly does not just result in compliance fines; it creates a vulnerability where an attacker can intercept an authenticated session and alter transaction details—a technique known as a man-in-the-browser (MitB) attack.

This article dissects the technical mechanics of SCA, focusing on dynamic linking, exemption logic, and the architectural patterns required for compliant Open Banking integrations.

The Triad: Knowledge, Possession, Inherence

SCA requires the use of two or more independent elements from three distinct categories to verify the identity of the payer. Independence is critical: the security of one element must not be compromised if another is breached.

1. Knowledge: Something only the user knows (e.g., password, PIN, passphrase).
2. Possession: Something only the user possesses (e.g., mobile device, hardware token, smart card).
3. Inherence: Something the user is (e.g., fingerprint, facial recognition, voice pattern).

In a typical Open Banking flow, the Account Servicing Payment Service Provider (ASPSP—usually the bank) and the Third Party Provider (TPP—often the fintech app) coordinate this verification. The fintech app initiates the payment, but the actual authentication event occurs within the bank’s environment (either via redirect or embedded iframe).

The mechanism works as follows:

• The TPP sends a Payment Initiation request to the ASPSP.
• The ASPSP responds with an authentication code and a redirect URL (or embedded UI data).
• The user authenticates using their preferred method (e.g., biometric + PIN).
• The ASPSP generates an AuthenticationCode and returns it to the TPP.

This code is not a session token. It is a short-lived credential that proves the user has successfully passed the triad check. Crucially, this code is useless without the context of the transaction it was generated for. This leads to the second pillar of SCA compliance: dynamic linking.

Dynamic Linking: Binding the Result to the Context

Prior to PSD2, authentication was often channel-based but not transaction-specific. A user might authenticate to log into their banking app, and then later initiate a transfer without re-authenticating, or an attacker might steal the session cookie and alter the beneficiary account number.

PSD2 Regulatory Technical Standards (RTS) mandate dynamic linking for most payment transactions. This means the authentication result must be cryptographically bound to specific data fields of the payment instruction. If any of these fields change after authentication, the authentication is invalidated.

The key fields that must be linked are:

• The payment amount
• The beneficiary account (IBAN)

While some jurisdictions allow linking to additional fields (e.g., remittance information, date), the amount and beneficiary are the non-negotiable minimums.

Technical Implementation

When the TPP initiates a payment, it does not just send the IBAN and amount. It must prepare the data structure that will be displayed to the user and cryptographically signed by the ASPSP.

{
  "instructedAmount": {
    "amount": "100.00",
    "currency": "EUR"
  },
  "creditorAccount": {
    "iban": "DE89370400440532013000"
  },
  "endToEndId": "E2E-ID-EXAMPLE-123"
}

When the ASPSP processes this, it generates a digital signature or a secure hash that includes these values. The resulting AuthenticationCode returned to the TPP is valid only if the subsequent execution of the payment uses the exact same amount and beneficiary. If the TPP attempts to modify the beneficiary after receiving the code, the ASPSP’s backend will reject the payment because the cryptographic hash will not match the stored authenticated context.

This mechanism neutralizes man-in-the-browser (MitB) attacks where malware alters the recipient account number after the user has entered their PIN. The PIN authenticated the original IBAN, not the malicious one.

Exemption Handling: Logic Over Defaults

Exemptions are not loopholes; they are risk-based decisions. PSD2 allows ASPSPs to exempt certain transactions from SCA, but the TPP cannot simply decide to bypass authentication. The TPP must request an exemption, and the ASPSP must accept it based on its own risk engine.

Common exemptions include:

• Low-Value Payments: Transactions under €30, with a cumulative limit of €100 or 5 consecutive transactions since the last SCA event, as set by the RTS.
• Trusted Beneficiaries: Transfers to accounts previously verified by the user.
• Transaction Risk Analysis (TRA): The most complex and powerful exemption.

Transaction Risk Analysis (TRA)

TRA allows the TPP to perform its own risk assessment before the authentication step. If the TPP’s risk engine determines the transaction is low-risk, it can request an exemption. The ASPSP then decides whether to accept this exemption.

The flow is asynchronous and requires careful state management:

1. TPP Initiates: Sends a Payment Initiation request with an exemptionType parameter (e.g., TRA).
2. ASPSP Responds:
   • Acceptance: The ASPSP returns a success response without requiring SCA. The payment proceeds.
   • Rejection: The ASPSP returns an error code (e.g., authentication_required) and forces the TPP to trigger the SCA flow.
   • Partial Acceptance: Rare, but may involve reduced friction.

Crucially, the TPP must handle the rejection gracefully. If the ASPSP rejects the TRA exemption, the TPP must immediately initiate the SCA flow. Failing to do so results in a failed payment and a poor user experience.

{
  "exemptionApplication": "TRA",
  "riskScore": 12,
  "merchantCategoryCode": "5411"
}

The riskScore and other metadata sent by the TPP help the ASPSP make its decision. However, the TPP must never assume the exemption will be granted. The architecture must support both paths: the "happy path" of immediate execution and the "friction path" of full SCA.

Compliance Strategies for Developers

Implementing SCA correctly requires more than just API calls. It demands a rigorous architectural approach to handle the complexities of asynchronous authentication and state management.

1. Idempotency is Non-Negotiable

Payment initiation APIs must be idempotent. Network timeouts are common during SCA redirects. If a TPP times out while waiting for the authentication code, it might retry the request. Without idempotency, this could result in duplicate payments. Always use unique endToEndId values and ensure the ASPSP can detect and reject duplicate requests.

2. Handle Redirects vs. Embedded UI

Open Banking APIs typically support two UI patterns:

• Redirect: The TPP redirects the user to the ASPSP’s website/app. This is simpler but provides less control over the UX.
• Embedded UI: The TPP displays the authentication interface within its own app using an iframe or webview. This requires more complex integration but offers a cohesive experience.

Regardless of the UI pattern, the TPP must not cache sensitive authentication data. The AuthenticationCode is transient and should be used immediately.

3. Monitor Exemption Rejection Rates

High rates of TRA exemption rejections indicate a problem with your risk model or the data you are sending. If your risk scores are consistently too optimistic, the ASPSP will reject your exemptions, forcing users into full SCA flows. This increases friction and abandonment. Work with your ASPSP partners to tune your risk parameters.

4. Security Best Practices

• Never store PINs or biometric data. These are handled exclusively by the ASPSP.
• Use HTTPS everywhere. All communication between TPP and ASPSP must be encrypted.
• Validate all responses. Do not trust the ASPSP’s response without verifying signatures or tokens where applicable.

Conclusion

PSD2’s SCA is a mechanism for cryptographic intent binding. It ensures that the person who authenticated is the same person who authorized the specific transaction details. For fintech developers, this means moving beyond simple form submissions to building systems that understand context, risk, and state. By implementing dynamic linking correctly, handling exemptions with resilient error handling, and prioritizing security, you not only comply with regulations but also build trust with users who are increasingly aware of payment fraud risks.

Current adoption trends show that while SCA compliance is now standard, the focus is shifting toward reducing friction through better TRA implementation and improved user interfaces.

FAQ

What happens if dynamic linking fails? If the transaction details (amount or beneficiary) do not match the values used to generate the authentication code, the ASPSP will reject the payment. The authentication is invalidated, and the user must re-authenticate with the correct details.

How do I handle TRA rejections? When an ASPSP rejects a Transaction Risk Analysis (TRA) exemption, you must immediately trigger the standard SCA flow (redirect or embedded UI). Do not attempt to process the payment without authentication. Ensure your API client handles the specific error codes returned by the ASPSP to route the user correctly.

Can I bypass SCA for recurring payments? Generally, no. PSD2 requires SCA for each payment initiation. However, some ASPSPs may allow a "standing consent" mechanism where the user authenticates once for a series of future payments, but this varies by jurisdiction and specific regulatory interpretation. Always check with your ASPSP.

Is biometric authentication sufficient for SCA? Biometrics alone are not sufficient. SCA requires two independent factors. A common pattern is using biometrics (Inherence) combined with a PIN or password (Knowledge), or biometrics combined with a push notification approval on a trusted device (Possession).