INTRODUCTION

In Lessons 3.3 and 3.4, we established the static properties of consent—the lifecycle, the expiry calculus, and the client’s cryptographic identity (mTLS). However, consent is not a passive contract; it is an active, real‑time cryptographic handshake between the PSU and the ASPSP.

Under PSD2 RTS Article 5 (Strong Customer Authentication), the PSU’s authentication must be dynamically linked to the specific transaction details (amount, payee, and reference). This is not a legal suggestion; it is a cryptographic obligation. The ASPSP must present the transaction details to the PSU, and the PSU’s SCA code (generated by their hardware token or mobile app) must be a cryptographic hash of those exact details. If an attacker intercepts the channel and modifies the amount, the SCA challenge will fail, rendering the attack inert.

This lesson deconstructs the mathematics of dynamic linking. We derive the exact HMAC construction that binds the user’s consent to the transaction payload, analyze the minimal entropy requirement (≥ 128 bits per EBA guidelines), and model the PSU timeout distribution (exponential decay) to calculate the optimal session expiry window. Furthermore, we quantify the User Experience (UX) latency budget—distinguishing between machine‑to‑machine latency (≤ 200ms) and human‑interactive latency (3‑5 seconds)—to ensure the ASPSP meets both the EBA’s 30‑second SCA window and the commercial need to prevent checkout abandonment.

LEARNING OBJECTIVES

1. Define the Dynamic Linking Function—establishing the cryptographic construction Challenge = HMAC‑SHA256(Amount || Payee || Nonce, K_Device), and proving mathematically that this one‑way function guarantees non‑repudiation of the transaction intent.

2. Calculate the Minimum Challenge Entropy—proving that the ASPSP’s generated Nonce must have at least 128 bits of randomness (per EBA RTS), and deriving the probability of a successful brute‑force attack against the challenge code (≈ 1 / 2^128), which is computationally infeasible even when factoring in quantum computing (Grover’s algorithm reduces it to ~2^64, which is still borderline infeasible for current quantum processors).

3. Quantify the PSU Timeout Model—modeling the 30‑second SCA challenge window as a Poisson process with a hazard rate λ = 1/30, and deriving the probability that a PSU completes the SCA within a given time (P(T ≤ t) = 1 - e^(-t/30)).

4. Decompose the End‑to‑End Consent Latency—separating the Human Delay (SCA reading and OTP entry: mean 3s, p95 8s) from the System Delay (rendering the UI, generating the challenge, and validating the response: mean 50ms, p95 120ms), and proving that the system latency is negligible compared to human interaction.

5. Design the UI State Machine for Consent—formalizing the five states of the consent screen (LOADING, DISPLAY, AWAITING_SCA, PROCESSING, COMPLETE/FAILED) and mapping each to specific HTTP response codes and timeouts.

PART 1: THE DYNAMIC LINKING CRYPTOGRAPHIC CONSTRUCTION

1.1 The One‑Way Function Requirement

The SCA challenge must satisfy three cryptographic properties to be compliant with RTS Article 5:

1. Integrity: The challenge must prove that the PSU saw the exact transaction details.

2. Binding: The challenge must be unique to this specific transaction and cannot be replayed.

3. Verifiability: The ASPSP must be able to verify the challenge without storing the raw details.

The industry standard, mandated implicitly by the EBA’s recommended practices, is the use of a keyed‑hash message authentication code (HMAC) :

Challenge_Code = HMAC-SHA256( K_Device, Amount || Currency || Payee_ID || Reference || Nonce )

Where:

• K_Device is a symmetric secret embedded in the PSU’s hardware/software crypto module (never transmitted).

• Amount and Currency are the exact monetary values (e.g., "100.00" || "GBP").

• Payee_ID is the creditor’s IBAN or sort code.

• Nonce is a time‑varying random value generated by the ASPSP.

• || denotes concatenation.

The Verification Proof: The PSU’s mobile device calculates this HMAC and returns it as the OTP. The ASPSP does not know K_Device (it is stored in the secure enclave of the PSU’s phone). Instead, the ASPSP stores a salt or a public seed associated with the device. When the OTP is returned, the ASPSP verifies the signature using the associated public key or, in symmetric models, a synchronized counter. In this model, the ASPSP recomputes the same HMAC on its side (it stores the symmetric key embedded in a secure HSM) and compares the two values. If the HMAC matches, the PSU must have successfully hashed the exact payload displayed on their screen.

1.2 Entropy and Quantum Resilience

The Nonce generated by the ASPSP must contain at least 128 bits of entropy. Why?
If an attacker intercepts the challenge request but does not know K_Device or the Nonce, they cannot predict the OTP. However, if the Nonce is predictable (e.g., a sequential counter), an attacker could replay a previous transaction.

Using the Shannon Entropy Formula: H = log2(N), where N is the size of the possible nonce space. For a 128‑bit nonce, H = 128. The brute‑force complexity is 2^128 attempts. Even with Grover’s quantum search algorithm, the complexity reduces to 2^64 operations. As of 2026, the largest quantum computers have ~1,000 logical qubits, incapable of executing 2^64 operations within a 30‑second SCA window. Therefore, 128 bits is secure against both classical and near‑term quantum attacks.

PART 2: THE SCA TIMEOUT — A Hazard Model of Human Behavior

2.1 The Regulatory 30‑Second Window

The EBA Guidelines on SCA state that the challenge must expire if not used within a reasonable time, typically capped at 30 seconds. The ASPSP generates a Nonce with an expiration timestamp T_exp = T_now + 30s.

The Exponential Decay Model:
The time taken for a PSU to read the screen, retrieve their hardware token, and type the OTP follows an exponential distribution with a mean (λ) of 5 seconds, but the regulator caps the maximum at 30 seconds.

The probability that a PSU completes the SCA within t seconds is given by the CDF:
P(T ≤ t) = 1 - e^(-t / μ), where μ = 5 seconds.

• At t = 5s: P = 1 - e^(-1) ≈ 63.2%. (63% of users finish in 5s).

• At t = 10s: P = 1 - e^(-2) ≈ 86.5%.

• At t = 30s: P = 1 - e^(-6) ≈ 99.75%.

Conclusion: By enforcing a 30‑second window, the ASPSP captures 99.75% of legitimate PSUs. The 0.25% of users who take longer must restart the process, ensuring that stale, high‑latency attempts are rejected for security reasons.

2.2 The System Latency vs. Human Latency

To meet the 30‑second window, the system (network + server) must be faster than the human by several orders of magnitude.

• System Link: Generating the HMAC (<1ms), rendering the UI (<50ms), and validating the response (<10ms).

• Human Link: Reading and typing.

The system contributes less than 1% of the total 30‑second budget. This asymmetry means that latency optimisation in the consent UI should focus on edge caching and bandwidth to ensure the UI loads instantly, not on cryptographic overhead.

PART 3: THE CONSENT UI STATE MACHINE

The ASPSP’s consent screen is a runtime resource that transitions through five explicit states. Each state maps to a specific HTTP interaction or user action.

Partition Tolerance: If the ASPSP’s UI service fails in state 1 or 2, the TPP’s request_uri expires (600s TTL). The TPP must handle a 400 error and restart the PAR push.

PART 4: THE UX LATENCY BUDGET (Human‑Centric SLA)

The p95 latency for the entire consent journey (from redirect to receiving the auth code) is approximately 8 seconds (dominated by the user typing). However, the ASPSP’s internal processing must be sub‑100ms to maintain the integrity of the 30‑second challenge.

Budget Allocation:

• Network (Geo‑DNS): 50ms (round trip).

• PAR Lookup: 15ms (Redis get).

• UI Render (SSR): 80ms (server‑side rendering of the React/Vue component).

• JS Boot (Client): 150ms (browser parse).

• SCA Validation: 20ms (HMAC verification).

• Token Issuance: 50ms (JWT generation + storage).

• Total System: ~365ms.

Remaining Budget: 29.6 seconds for the human. This provides a massive safety buffer, proving that system latency is never the bottleneck in consent granting.