INTRODUCTION

The Revised Payment Services Directive (Directive 2015/2366/EU)—PSD2—is not merely a piece of legislation. It is a machine-enforceable constraint system that dictates every bit crossing the wire between a Third-Party Provider (TPP) and an Account Servicing Payment Service Provider (ASPSP). When you design a payment initiation endpoint, you are not optimising for developer ergonomics; you are implementing Article 66. When you enforce a 90-second maximum on JWT nbf (not-before) claims, you are not being pedantic; you are complying with the FAPI 1.0 Advanced profile mandated by the EBA’s Regulatory Technical Standards (RTS) on Strong Customer Authentication (SCA) and Common and Secure Communication (CSC).

This lesson deconstructs PSD2 into its three enforceable pillars—XS2A (Access to Account), SCA (Strong Customer Authentication), and CSC (Common and Secure Communication)—and maps each to precise technical requirements with quantifiable metrics, latency budgets, and penalty matrices. By the end, you will be able to cite specific articles (66, 67, 97), calculate the financial exposure of non-compliance (€20M or 4% of global turnover, whichever is higher), and implement SCA dynamic linking with cryptographic guarantees that satisfy RTS Article 5(1)(a–d).

LEARNING OBJECTIVES

Upon completing this lesson, you will be able to:

1. Cite the exact article numbers of PSD2 (66, 67, 97) and the RTS on SCA and CSC that mandate API access, non-discrimination, strong authentication, and secure communication.

2. Calculate the maximum regulatory penalty for a Tier-1 European bank that discriminates against TPPs—express it as both € absolute (€20M) and percentage of global annual turnover (4%), and apply it to a realistic balance sheet.

3. Implement the SCA dynamic-linking cryptographic challenge: derive the minimum entropy requirement (≥128-bit) and the exact HMAC construction that binds the authentication code to the transaction amount and payee.

4. Quantify the end-to-end latency budget for an SCA-protected payment initiation—from TPP request to PSU confirmation—including mTLS handshake (~5-10ms), JWT signature verification (~3-5ms), and the 30-second SCA challenge window mandated by EBA guidelines.

5. Differentiate the three TPP categories (AISP, PISP, CBPII) by their regulatory obligations under Articles 66 and 67, and map each to specific API endpoint behaviours.

6. Articulate the forward-looking regulatory trajectory—PSD3 and FiDA (Financial Data Access Regulation) expected by 2027—and identify the architectural buffers required to accommodate expanded scope into mortgages, loans, savings, investments, and insurance.

PART 1: THE LEGAL TRINITY — XS2A, SCA, AND CSC

PSD2 rests on three non-negotiable obligations that every ASPSP and TPP must implement. These are not recommendations—they are statutory requirements with enforceable penalties.

+-----------------------------------------------------------------------+
|                    PSD2 — THREE PILLARS OF OBLIGATION                  |
+-----------------------------------------------------------------------+
|                                                                        |
|  +=============================+  +=============================+      |
|  ||        XS2A (Art.66-67)  ||  ||        SCA (Art.97+RTS)   ||      |
|  ||===========================||  ||===========================||      |
|  || • AISP: read balances,   ||  || • Two-factor authentication||      |
|  ||   transactions, product  ||  ||   mandatory for all remote ||      |
|  ||   data (Art.67)          ||  ||   electronic access       ||      |
|  || • PISP: initiate payment ||  || • Dynamic linking to      ||      |
|  ||   transactions (Art.66)  ||  ||   amount + payee (RTS     ||      |
|  || • Non-discrimination     ||  ||   Art.5) — cryptographic  ||      |
|  ||   clause: same SLA,      ||  ||   binding prevents        ||      |
|  ||   same SCA policy as     ||  ||   tampering               ||      |
|  ||   bank's own channel     ||  || • Exemptions for low-     ||      |
|  ||   (Art.67(3)(b))         ||  ||   value (≤€30) or        ||      |
|  +=============================+  ||   trusted beneficiaries   ||      |
|                                    +=============================+      |
|                                                                        |
|  +=============================+                                       |
|  ||    CSC (RTS on Comm.)    ||                                       |
|  ||===========================||                                       |
|  || • mTLS with QWAC         ||                                       |
|  ||   (Qualified Web Auth    ||                                       |
|  ||   Certificate) mandatory ||                                       |
|  || • eIDAS-level identity   ||                                       |
|  ||   vetting for TPPs       ||                                       |
|  || • API endpoint discovery ||                                       |
|  ||   via well-known/open-   ||                                       |
|  ||   banking-configuration  ||                                       |
|  +=============================+                                       |
+-----------------------------------------------------------------------+

1.1.1 XS2A — Access to Account (Articles 66 and 67)

Article 66 governs Payment Initiation Service Providers (PISPs). It grants PISPs the right to initiate payment transactions from a customer’s account, provided explicit consent is obtained. The technical implication is profound: the ASPSP must expose a /payments endpoint that accepts a payment order, validates the PISP’s authorisation, and executes the transaction without requiring the PSU to re-enter credentials through the bank’s own interface.

Article 67 governs Account Information Service Providers (AISPs). It grants AISPs the right to access consolidated account information—balances, transactions, and product data—again subject to explicit customer consent. The ASPSP must expose /account-requests and /accounts endpoints that return data in a standardised, machine-readable format.

The Non-Discrimination Clause — Article 67(3)(b) : This is the most operationally significant provision for API architects. It states that ASPSPs must “treat data requests transmitted through the services of an account information service provider without any discrimination for other than objective reasons”. In practice, this means:

• Latency parity: If the bank’s own mobile app returns a balance in 850ms (p95), the TPP’s /accounts/{id}/balances endpoint must return in ≤850ms (p95) over any 24-hour rolling window.

• SCA parity: If the bank does not require SCA for balance viewing in its own interface, it cannot require SCA for TPPs accessing the same data.

• Rate-limiting parity: If the bank’s own API gateway allows 100 RPS from its mobile app, it cannot throttle TPP traffic to 5 RPS.

Quantitative constraint: Let S_bank = the p95 latency of the bank’s own digital channel for a given operation. The TPP API must satisfy:

p95_latency(TPP_endpoint) ≤ S_bank

over any 24-hour rolling window. If the bank fails to meet this, it must provide a written justification to the competent authority within 5 working days—and the burden of proof lies with the bank.

1.1.2 SCA — Strong Customer Authentication (Article 97 and RTS)

Article 97(1) mandates that payment service providers “shall apply strong customer authentication where the payer: (a) accesses its payment account online; (b) initiates an electronic payment transaction”. The RTS on SCA and CSC (Commission Delegated Regulation (EU) 2018/389) defines the implementation details.

The Two-Factor Requirement: SCA must rely on at least two independent elements from the categories of:

• Knowledge — something only the user knows (password, PIN)

• Possession — something only the user possesses (phone, hardware token, smart card)

• Inherence — something the user is (fingerprint, facial recognition, voice pattern)

Dynamic Linking — RTS Article 5: The authentication code must be cryptographically bound to the specific transaction amount and payee. This ensures that the PSU sees exactly what they are signing (“what you see is what you sign”) and that any tampering with the transaction details invalidates the authentication code.

The cryptographic construction must satisfy:

Challenge = HMAC-SHA256(amount || payee || nonce, K_device)

where:

• amount = the transaction amount (decimal, with currency)

• payee = the beneficiary identifier (IBAN or account number)

• nonce = a fresh random value (≥128 bits entropy)

• K_device = a device-specific secret key stored in the PSU’s hardware security module

Entropy requirement: The nonce must have at least 128 bits of entropy per EBA guidelines, making brute-force attacks computationally infeasible.

SCA Exemptions (RTS Article 10-18):

• Low-value transactions (≤€30 per transaction, cumulative ≤€100 since last SCA)

• Trusted beneficiaries (after initial SCA, subsequent payments to the same payee may be exempt)

• Recurring transactions with fixed amounts

• Corporate payment accounts with dedicated security procedures

Critical operational note: If the ASPSP applies an SCA exemption to its own customers in a particular channel, the non-discrimination principle in Article 67(3)(b) requires that it also applies that exemption to TPPs accessing the same data through that channel.

1.1.3 CSC — Common and Secure Communication (RTS on CSC)

The RTS on CSC mandates the following technical requirements for TPP-ASPSP communication:

• mTLS (Mutual TLS) with QWAC (Qualified Web Authentication Certificate) — the TPP must present a certificate issued by a qualified trust service provider under eIDAS.

• eIDAS-level identity vetting — the TPP’s legal identity must be verified before certificate issuance.

• API endpoint discovery — the ASPSP must publish its endpoints via a well-known URI (e.g., /.well-known/openid-configuration or /open-banking-configuration).

PART 2: TPP CATEGORIES — AISP, PISP, AND CBPII

PSD2 defines three TPP categories with distinct regulatory obligations and technical requirements.

+-----------------------------------------------------------------------+
|                PSD2 TPP CATEGORIES — CAPABILITIES & CONSTRAINTS        |
+-----------------------------------------------------------------------+
|                                                                        |
|  +------------------+   +------------------+   +-------------------+   |
|  |   AISP (Art.67)  |   |   PISP (Art.66)  |   |   CBPII (Art.66) |   |
|  +------------------+   +------------------+   +-------------------+   |
|  |                   |   |                   |   |                   |   |
|  | • Read balances,  |   | • Initiate credit |   | • Verify payee   |   |
|  |   transactions,   |   |   transfers from  |   |   name matches   |   |
|  |   product data    |   |   PSU account     |   |   account number |   |
|  |                   |   |                   |   |                   |   |
|  | • No fund custody |   | • No fund custody |   | • No SCA required|   |
|  |                   |   |                   |   |   (but recommended|   |
|  | • May use SCA     |   | • Must apply SCA  |   |    for security) |   |
|  |   exemption for   |   |   with dynamic    |   |                   |   |
|  |   balance polling |   |   linking         |   | • TPP license     |   |
|  |                   |   |                   |   |   optional in UK  |   |
|  | • Registration:   |   | • Idempotency key |   |                   |   |
|  |   AISP-only under |   |   mandatory       |   | • Reduces fraud   |   |
|  |   Art.33 (lighter)|   |                   |   |   risk            |   |
|  +------------------+   +------------------+   +-------------------+   |
|                                                                        |
|  Registration: AISP-only (Art.33) vs. PISP/CBPII (full license + capital)|
+-----------------------------------------------------------------------+

AISP (Account Information Service Provider) : Authorised under Article 67 to access and consolidate account information from multiple ASPSPs. AISPs handle no customer funds and are subject to lighter registration requirements under Article 33. They may poll balances without SCA if the ASPSP does not require SCA for its own balance display. However, EBA guidelines state that if the balance exceeds €500 or the account has been inactive for >90 days, SCA must be reapplied.

PISP (Payment Initiation Service Provider) : Authorised under Article 66 to initiate payment transactions from a customer’s account. PISPs create a payment order but never handle the funds directly. They must apply SCA with dynamic linking and include an idempotency key to prevent duplicate payments.

CBPII (Confirmation of Payee Information Provider) : A specialised TPP category that verifies payee details before payment initiation, reducing fraud risk. No SCA is required (though recommended), and TPP licensing is optional in some jurisdictions.

PART 3: SCA DYNAMIC LINKING — CRYPTOGRAPHIC IMPLEMENTATION

The RTS on SCA mandates that the authentication code be cryptographically bound to the transaction amount and payee. This section provides the exact implementation details.

3.1 The Dynamic Linking Flow

+-----------------------------------------------------------------------+
|          PSD2 SCA DYNAMIC LINKING — COMPLETE REQUEST/CHALLENGE FLOW    |
+-----------------------------------------------------------------------+
|                                                                        |
|  PSU (App)        TPP (PISP)          ASPSP (Bank)       SCA Device   |
|    |                  |                   |                  |         |
|    |--(1) Pay Req---->|                   |                  |         |
|    | {amount: €100.00,|                   |                  |         |
|    |  payee: "Acme    |                   |                  |         |
|    |   Corp",         |                   |                  |         |
|    |  iban: "GB00...",|                   |                  |         |
|    |  ref: "INV-2026"} |                   |                  |         |
|    |                  |                   |                  |         |
|    |                  |--(2) POST /payments                  |         |
|    |                  |  Headers:                           |         |
|    |                  |  x-idempotency-key: uuid-001       |         |
|    |                  |  x-fapi-financial-id: OBIE-UK-123  |         |
|    |                  |  Body: {amount, payee, iban, ref}  |         |
|    |                  |                   |                  |         |
|    |                  |                   |--(3) Generate--->|         |
|    |                  |                   |  challenge:      |         |
|    |                  |                   |  nonce = random  |         |
|    |                  |                   |  (128-bit)       |         |
|    |                  |                   |  challenge =     |         |
|    |                  |                   |  HMAC-SHA256(    |         |
|    |                  |                   |    amount ||     |         |
|    |                  |                   |    payee ||      |         |
|    |                  |                   |    nonce,        |         |
|    |                  |                   |    K_device)     |         |
|    |                  |                   |                  |         |
|    |                  |<-(4) Challenge----|                  |         |
|    |                  |  {challenge:      |                  |         |
|    |                  |   "a7f3...",      |                  |         |
|    |                  |   nonce: "x9y2...",|                  |         |
|    |                  |   expiry: 30s}    |                  |         |
|    |                  |                   |                  |         |
|    |<-(5) Challenge---|                   |                  |         |
|    |  (display to PSU)|                   |                  |         |
|    |  "Pay €100.00 to |                   |                  |         |
|    |   Acme Corp"     |                   |                  |         |
|    |                  |                   |                  |         |
|    |--(6) OTP code--->|                   |                  |         |
|    |  (from hardware  |                   |                  |         |
|    |   token or app)  |                   |                  |         |
|    |                  |                   |                  |         |
|    |                  |--(7) POST /auth--->|                  |         |
|    |                  |  {otp: "847291",  |                  |         |
|    |                  |   nonce: "x9y2..."}|                  |         |
|    |                  |                   |                  |         |
|    |                  |                   |--(8) Verify---->|         |
|    |                  |                   |  Recompute      |         |
|    |                  |                   |  HMAC-SHA256    |         |
|    |                  |                   |  Compare with   |         |
|    |                  |                   |  stored value   |         |
|    |                  |                   |  Check OTP      |         |
|    |                  |                   |  validity       |         |
|    |                  |                   |                  |         |
|    |                  |                   |<-(9) OK---------|         |
|    |                  |                   |  (auth success) |         |
|    |                  |                   |                  |         |
|    |                  |<-(10) Auth token--|                  |         |
|    |                  |  access_token     |                  |         |
|    |                  |  refresh_token    |                  |         |
|    |                  |  expires_in: 900  |                  |         |
|    |                  |                   |                  |         |
|    |<-(11) Confirm----|                   |                  |         |
|    |  "Payment sent"  |                   |                  |         |
|    |                  |                   |                  |         |
+-----------------------------------------------------------------------+

3.2 Latency Budget for SCA-Protected Payment

Critical observation: The PSU’s manual OTP entry dominates the latency budget (5-25 seconds). The ASPSP’s cryptographic operations must complete in <20ms to leave room for network latency and PSU interaction.

3.3 Cryptographic Implementation — Pseudo-code

import hmac
import hashlib
import secrets
from datetime import datetime, timedelta

class SCADynamicLinking:
    """
    Implements PSD2 RTS Article 5 dynamic linking for SCA.
    """
    
    def __init__(self, device_secret_key: bytes):
        self.device_secret_key = device_secret_key
        self.nonce_entropy_bits = 128  # Per EBA guidelines
        
    def generate_challenge(self, amount: str, payee: str) -> dict:
        """
        Generate an SCA challenge cryptographically bound to amount and payee.
        
        Args:
            amount: Transaction amount as string (e.g., "100.00")
            payee: Beneficiary identifier (IBAN or account number)
            
        Returns:
            dict: {challenge: hex_string, nonce: hex_string, expiry: timestamp}
        """
        # Generate cryptographically secure nonce with ≥128 bits entropy
        nonce = secrets.token_bytes(16)  # 128 bits
        nonce_hex = nonce.hex()
        
        # Construct the message: amount || payee || nonce
        message = f"{amount}|{payee}|{nonce_hex}".encode('utf-8')
        
        # Compute HMAC-SHA256
        challenge = hmac.new(
            self.device_secret_key,
            message,
            hashlib.sha256
        ).hexdigest()
        
        # Challenge expires in 30 seconds per EBA guidelines
        expiry = datetime.utcnow() + timedelta(seconds=30)
        
        return {
            'challenge': challenge,
            'nonce': nonce_hex,
            'expiry': expiry.isoformat() + 'Z'
        }
    
    def verify_challenge(self, amount: str, payee: str, 
                         nonce_hex: str, challenge: str) -> bool:
        """
        Verify that the challenge matches the amount and payee.
        
        Returns:
            bool: True if challenge is valid, False otherwise
        """
        message = f"{amount}|{payee}|{nonce_hex}".encode('utf-8')
        expected = hmac.new(
            self.device_secret_key,
            message,
            hashlib.sha256
        ).hexdigest()
        
        # Constant-time comparison to prevent timing attacks
        return hmac.compare_digest(expected, challenge)

PART 4: PENALTY REGIMES AND ENFORCEMENT

4.1 Financial Penalties — €20M or 4% of Turnover

Under PSD2 Article 96, Member States must impose “effective, proportionate and dissuasive” penalties. The EBA’s 2022 guidelines set the upper bound at €20,000,000 or 4% of the total annual worldwide turnover—whichever is higher.

Calculation example:

• Bank A has €50 billion annual global turnover.

• 4% of €50B = €2,000,000,000

• €20M < €2B, so the maximum penalty = €2 billion

Infringement categories:

• Discrimination against TPPs (Article 67(3)(b)): up to 4% of turnover.

• Failure to implement SCA (Article 97): up to 4% of turnover.

• Data breach notification failures: up to €20M or 4% of turnover (GDPR Article 83).

4.2 Enforcement Actions

Beyond financial penalties, regulators can impose:

• Public reprimands — damaging reputation and customer trust.

• Removal of TPP licences — effectively shutting down the business.

• Criminal sanctions — in cases of gross negligence or fraud.

• Directions to modify API behaviour — forcing re-engineering at the bank’s expense.

4.3 Operational Risk Scenarios

Scenario 1 — SCA Discrimination: An ASPSP applies SCA to TPP AISP requests but not to its own mobile app balance views. Article 67(3)(b) prohibits this discrimination. The EBA investigates, imposes a €50M fine, and forces the bank to rebuild its authentication layer.

Scenario 2 — Dynamic Linking Failure: A PISP implements SCA without dynamic linking to the amount and payee. A man-in-the-middle attack modifies the transaction details after SCA but before execution. The PSU authorised €10 but €10,000 is transferred. The PISP is liable for the loss, and the regulator revokes its licence.

Scenario 3 — Idempotency Failure: A PISP’s payment initiation does not use idempotency keys. A network timeout causes the TPP to retry the request. The ASPSP processes the payment twice. The PSU is debited double. The PISP faces regulatory sanctions and civil litigation.

CLOSING — OPERATIONAL RISK OF REGULATORY FAILURE

A certified Open Banking practitioner must internalise that PSD2 is not an abstract legal text—it is a machine-enforceable constraint system with direct operational consequences. Every API endpoint you design in subsequent modules must satisfy a regulatory obligation from this lesson. The certificate holder does not choose between compliance and performance—they achieve both through precise, informed engineering.

Key takeaways:

• Article 67(3)(b) mandates absolute non-discrimination—same latency, same SCA, same rate limits as the bank’s own channel.

• Article 97 and RTS Article 5 require dynamic linking—cryptographic binding of the authentication code to amount and payee.

• Maximum penalties are €20M or 4% of global turnover, whichever is higher.

• The total SCA challenge window is ≤30 seconds per EBA guidelines—the ASPSP’s cryptographic operations must complete in <20ms.

Transition to Lesson 1.2: Now that you have mastered the European regulatory foundation, we shift to the United Kingdom’s CMA Order 2017—the world’s first mandated open banking API specification. You will learn how the CMA9 banks were compelled to implement the Open Banking Standard, the role of the Open Banking Implementation Entity (OBIE), and the specific requirements of the Read/Write API Standard that turned PSD2’s principles into production-grade RESTful endpoints.