PSD2 Strong Customer Authentication: A Security Engineer’s Technical Implementation Guide

With the ongoing transition toward RTS (Regulatory Technical Standards) under PSD2, the financial sector has shifted from legacy static credentials toward multi-factor, cryptographic verification. As security engineers, we must view Strong Customer Authentication (SCA) not merely as a regulatory checkbox, but as a critical defense layer against account takeover (ATO) and man-in-the-middle (MITM) attacks. The latest regulatory guidance emphasizes the dynamic linking requirement, which mandates that the authentication code be tied specifically to the transaction amount and the payee.

Implementing SCA requires a deep understanding of the cryptographic primitives involved. Unlike basic SMS-based two-factor authentication, which is increasingly susceptible to SIM-swapping, PSD2-compliant SCA relies on hardware-backed security or FIDO2-compliant protocols. This article explores the technical architecture required to satisfy the three pillars of SCA—knowledge, possession, and inherence—while maintaining the strict latency and availability requirements of modern payment systems.

The Three Pillars of SCA and Cryptographic Enforcement

PSD2 mandates that authentication must utilize at least two independent elements. From a systems perspective, these must be categorized as follows:

• Knowledge: Something only the user knows (e.g., password, PIN).
• Possession: Something only the user possesses (e.g., hardware token, smartphone with secure enclave).
• Inherence: Something the user is (e.g., biometric markers processed via FIDO/WebAuthn).

The security risk here lies in the independence of the elements. If a compromise of the backend database allows an attacker to retrieve both the knowledge factor and the token secret, the system is fundamentally flawed. We recommend using HMAC-based One-Time Passwords (HOTP) or Time-based One-Time Passwords (TOTP) only as a fallback, prioritizing Public Key Infrastructure (PKI) where the private key resides in a Trusted Execution Environment (TEE) on the user’s mobile device.

Implementing Dynamic Linking for Transaction Integrity

Dynamic linking is the most complex technical hurdle in PSD2 compliance. Article 5 of the RTS requires that for remote electronic payment transactions, the authentication code must be dynamically linked to the amount and the payee. If the amount or payee changes, the authentication code must be invalidated.

To implement this, your backend must generate a unique transaction challenge. This challenge, combined with the transaction metadata, is signed by the client’s private key. The process follows this flow:

// Simplified signing logic in a secure enclave
const transactionData = { amount: 100.00, currency: 'USD', payee: 'Merchant_ABC' };
const challenge = crypto.randomBytes(32);
const signature = secureEnclave.sign(JSON.stringify(transactionData) + challenge);

The server must verify this signature using the user’s registered public key, ensuring that the payload—the amount and payee—has not been tampered with during transit.

Handling SCA Exemptions and Risk-Based Authentication

Not every transaction requires full SCA. PSD2 allows for Transaction Risk Analysis (TRA) exemptions, which permit frictionless flows if the transaction is low-risk. However, as security engineers, we must define ‘risk’ through automated telemetry rather than static rules.

You should integrate an anomaly detection engine that monitors:

• Device Fingerprinting: Identifying if the device ID matches the user’s historical profile.
• Velocity Checks: Detecting rapid-fire transaction attempts.
• Geolocation Discrepancies: Identifying impossible travel between login sessions.

If the risk score exceeds a defined threshold, the system must trigger a ‘step-up’ authentication request, forcing the user to complete the full SCA flow.

Common Vulnerabilities in SCA Implementations

Many implementations fail because they treat the authentication as a stateless event. In reality, SCA must be treated as a stateful transaction lifecycle. Common pitfalls include:

• Replay Attacks: Failing to include a unique nonce in the authentication challenge, allowing an intercepted request to be re-executed.
• Weak Entropy in Challenges: Using predictable pseudo-random number generators (PRNG) for transaction challenges.
• Insecure Storage of Public Keys: Storing user public keys in a database without integrity protection, potentially allowing an attacker to swap a user’s public key with their own.

Ensure that all authentication headers are validated against the OWASP API Security Top 10, specifically focusing on BOLA (Broken Object Level Authorization) during the transaction initiation phase.

Monitoring and Observability for Compliance Audits

Compliance is continuous. You must maintain immutable audit logs of every authentication attempt, whether successful or failed. These logs are essential for demonstrating compliance to regulators during an audit.

Your logging infrastructure should include:

• Authentication Latency: Monitoring the time taken for biometric or hardware token verification.
• Failure Rate Metrics: High failure rates often indicate either a UX issue or a brute-force attack in progress.
• Cryptographic Algorithm Versioning: Tracking which users are using legacy vs. modern signing algorithms for future deprecation paths.

Use structured logging (JSON format) to ensure that logs can be ingested by SIEM systems for real-time threat detection.

Strong Customer Authentication is a rigorous standard that demands architectural discipline. By moving away from legacy SMS-based methods and embracing cryptographic signing and hardware-backed security, we align our systems with both regulatory requirements and modern threat models. The focus must always remain on the integrity of the transaction data and the secure management of keys within the user’s device.

As you scale your payment infrastructure, consider the implications of moving toward FIDO2/WebAuthn, which provides the highest level of assurance against phishing. Maintaining this level of security requires constant vigilance against evolving attack vectors and regular audits of your authentication lifecycle.