PSD2 SCA challenge completion versus settlement message generation

1. What the RTS specifies

Commission Delegated Regulation (EU) 2018/389 (as amended) [1] — the Regulatory Technical Standards on Strong Customer Authentication that codify PSD2 Article 97 [3] — specifies SCA at two cryptographic boundaries.

Article 4 requires the authentication procedure to result in an authentication code with a defined set of properties: the code must be generated from at least two independent factors, must not be reusable, must not allow disclosure of the factors from the code, and must be designed such that it cannot be forged on the basis of any compromised single factor.

Article 5 requires the authentication code to be dynamically linked to a specific amount and a specific payee — and requires that any change in amount or payee invalidate the code. This is the regulatory basis for transaction-bound authentication codes in European retail payments.

These boundaries are precise. They cover the moment of code generation and the binding of the code to specified transaction attributes. They are extensively elaborated in the EBA Single Rulebook Q&A [2], which clarifies, among other things, that dynamic linking applies to the specific transaction the user authenticated, that re-use across distinct transactions is not permitted, and that the binding must be such that any tampering with amount or payee invalidates the authentication.

2. What the RTS does not specify

The RTS speaks about the authentication code and its binding. It does not speak about the runtime stretch between the moment the code is generated on the payment service user’s device and the moment the settlement message — typically an ISO 8583 authorisation request on the card rails, or an ISO 20022 credit-transfer message on SEPA Instant and adjacent rails — reaches the acquirer or clearing system.

That stretch contains operator-implementation detail:

• The authentication code is persisted in the application or intermediated by the payment service provider’s backend.
• The transaction message is assembled from the code, the payload values, and the operator-side metadata.
• The message is transmitted, sometimes after a short enrichment step in the operator’s anti-fraud or risk evaluation pipeline.

Each of these steps is operator-implementation, not RTS-regulated. Each can be done well or badly. None is signed by the SCA mechanism. The RTS does not require it to be: the regulation specifies the authentication boundary; what happens between the boundary and the message is the operator’s responsibility.

3. Where dynamic linking is satisfied — and where it is not

A common reading of RTS Article 5 treats dynamic linking as a property satisfied at the moment of code generation: the code is bound to amount and payee at that moment, and the binding cannot be undone without invalidating the code. This is correct. It is also a property at a single instant.

What dynamic linking does not assert is that the message delivered to the acquirer carries the same amount and payee that were bound to the code. Dynamic linking guarantees that if the acquirer-bound amount and payee differ from the bound values, the code will fail validation. It guarantees the property relationally. It does not, by itself, guarantee that the acquirer-bound amount and payee are the values the user actually saw and confirmed in the user-agent flow.

This is where the operational gap lives. A class of mobile-runtime attacks — overlay substitution, parameter tampering after user confirmation, accessibility-service-driven input synthesis — operates by altering the values the user sees, not by tampering with the authentication code itself. The code remains cryptographically valid; the values it is bound to are the values the attacker wanted bound. RTS Article 5 catches the attacker that breaks the binding. It is silent on the attacker that controls the values before the binding is formed.

4. What EEI adds at the operator boundary

Execution Evidence Infrastructure (EEI) — the device-identity infrastructure layer for banking and payments — does not replace SCA. SCA is a regulated authentication boundary; EEI is a runtime evidence layer. They sit at different points in the flow and answer different questions.

What EEI adds is a signed account of what happened on the device between the SCA completion moment and the settlement-message moment: the values rendered to the user, the consent acquired, the payload assembled, the network trajectory of the submission. The RTS does not require this — but operators that hold it can, in dispute, present a signed sequence showing that the values delivered to the acquirer are the values the device actually rendered and the user actually confirmed. That is the question the RTS does not answer because it is not the RTS’s question to answer. It is the operator’s, and EEI is the layer that lets the operator answer it cryptographically.

5. Cross-references

• Sibling articles in this theme: the-fido2-submission-gap, the-emv-execution-gap, the-behavioural-session-gap
• Architecture: /architecture/runtime-coherence, /architecture/sovereign-verification
• Glossary: /glossary — Evidence Token, Runtime Coherence

6. External references

[1] European Commission. Commission Delegated Regulation (EU) 2018/389 — Regulatory Technical Standards on Strong Customer Authentication and Common and Secure Open Standards of Communication, Articles 4 and 5. eur-lex.europa.eu/eli/reg_del/2018/389/oj. Cited 2025-10-22.

[2] European Banking Authority. Single Rulebook Q&A — Strong Customer Authentication. www.eba.europa.eu/single-rule-book-qa. Cited 2025-10-22.

[3] European Parliament and Council. Directive (EU) 2015/2366 on payment services in the internal market (PSD2). eur-lex.europa.eu/eli/dir/2015/2366/oj. Cited 2025-10-22.