[ compliance mapping ]
We sign the moment the payload is bound.
Dynamic linking gets a device-side witness.
Mapping the signed payload-assembly event to Article 5 (dynamic linking) and Article 4 (authentication code) of Commission Delegated Regulation (EU) 2018/389.
European banks, PISPs, acquirers working with European issuers, scheme architects.
PSD2 strong customer authentication is the operator's obligation. The operator's SCA infrastructure remains the load-bearing path through Article 4 and Article 5 of (EU) 2018/389 — knowledge, possession, inherence, authentication code, attempt caps, transport protection. We do not replace it.
Inside that obligation, one clause is uniquely device-side: dynamic linking. Article 5 binds the authentication code to the exact (amount, payee) the payer saw. The question: what was actually displayed and assembled at the confirmation moment?
The signed payload-assembly event answers that question with a cryptographic statement, anchored to a TEE-resident key, verifiable by the operator with no vendor in the path. That is the dynamic-linking moment. Article 5 leads on this page because it is the load-bearing PSD2 obligation EEI uniquely strengthens. Article 4 follows.
The signed payload-assembly event as device-side witness of dynamic linking.
Quoted text is verbatim from Article 5 of Commission Delegated Regulation (EU) 2018/389 (CELEX 32018R0389). Binding strength of the EEI-side contribution is annotated per row (TEE-bound where a TEE-resident key or Trusted UI is on the path; software-only attestation otherwise).
| Article 5 paragraph (verbatim) | Obligation in plain terms | EEI signed payload-assembly event |
|---|---|---|
| Article 5(1)(a) the payer is made aware of the amount of the payment transaction and of the payee; | Before authentication, the payer must be shown the amount and the payee. | The signed payload-assembly event records the surface state of the payment confirmation screen — overlay.detected, accessibility.active, code.integrity, runtime.environment — at the moment the payer is shown the amount and the payee. TEE-bound where the device exposes a Trusted UI primitive to the TRP; software-only attestation otherwise (with the signal class indicating which path was taken). |
| Article 5(1)(b) the authentication code generated is specific to the amount of the payment transaction and the payee agreed to by the payer when initiating the transaction; | The authentication code must be bound to this exact amount + this exact payee. | EEI does not generate the SCA authentication code itself — that is the operator's SCA infrastructure. The signed payload-assembly event sits adjacent: it carries a cryptographic hash of the (amount, payee) tuple as observed on the device at assembly time, signed by the device's in-TEE ZTBP keypair. TEE-bound. |
| Article 5(1)(c) the authentication code accepted by the payment service provider corresponds to the original specific amount of the payment transaction and to the identity of the payee agreed to by the payer; | What the PSP accepts must correspond to what the payer agreed to. | Independent verifier-side check: the operator verifies the signed payload-assembly event against the device's registered public key and compares the (amount, payee) hash in the signed event to the (amount, payee) tuple delivered with the authentication code. A mismatch is a device-side witness of substitution between the confirmation screen and the wire. Sovereign verification — no vendor in the path. |
| Article 5(1)(d) any change to the amount or the payee results in the invalidation of the authentication code generated. | Mutate the amount or payee and the code must be invalidated. | Out of scope for EEI as a primary obligation — invalidation of the authentication code is enforced by the operator's SCA infrastructure. The signed payload-assembly event strengthens the detection side: any drift between the signed (amount, payee) hash and the accepted code is independently observable to the verifier. |
| Article 5(2)(a) the amount of the transaction and the payee throughout all of the phases of the authentication; | Confidentiality, authenticity, integrity of (amount, payee) across every phase of the auth flow. | The signed payload-assembly event covers the device-side phase: assembly, display-to-payer, and binding to the authentication. Each Evidence Token entry is appended to the device-resident Local Evidence Ledger (append-only, hash-linked). The TRP observes the call path framework / libc / syscall during this window. TEE-bound for signing key custody; runtime observation is continuous. |
| Article 5(2)(b) the information displayed to the payer throughout all of the phases of the authentication including the generation, transmission and use of the authentication code. | What the payer sees, across every phase, must remain confidential, authentic and integrity-protected. | The signed payload-assembly event records surface-state signal classes — overlay.detected, accessibility.active — at confirmation time. An overlay or accessibility-service interposition that mutates what the payer sees becomes a signed, replayable observation, not a credibility judgment. TEE-bound where Trusted UI is available; software-only attestation otherwise. |
| Article 5(3)(a) in relation to a card-based payment transaction for which the payer has given consent to the exact amount of the funds to be blocked pursuant to Article 75(1) of that Directive, the authentication code shall be specific to the amount that the payer has given consent to be blocked and agreed to by the payer when initiating the transaction; | Card-based block-funds case: the auth code is specific to the consented blocked amount. | The signed payload-assembly event captures the consented blocked amount as displayed and agreed on the device. The (amount-to-block, payee) hash in the signed event is verifiable against what the operator's SCA infrastructure accepted — a device-side witness of consent integrity in the block-funds path. |
| Article 5(3)(b) in relation to payment transactions for which the payer has given consent to execute a batch of remote electronic payment transactions to one or several payees, the authentication code shall be specific to the total amount of the batch of payment transactions and to the specified payees. | Batch case: the auth code is specific to total batch amount + the specified payees. | The signed payload-assembly event in a batch context records the total batch amount and the ordered list of payees as displayed and agreed on the device. The hash carried in the signed event covers the full batch tuple, independently verifiable against what the operator's SCA infrastructure accepted. TEE-bound. |
Dynamic linking is the obligation a device-side witness uniquely strengthens.
Every Article 5 clause turns on the same fact: the payer confirmed an (amount, payee), and that pair must stay bound to the authentication code the PSP accepts. The operator's SCA handles the code; the device handles the display and assembly.
The signed payload-assembly event is the natural device-side witness. Emitted at assembly, anchored to a TEE-resident ZTBP keypair, it carries a hash of the displayed (amount, payee) plus surface-state and runtime signals. The operator verifies against the registered public key.
That is the witness layer's contribution to dynamic linking: not satisfying Article 5 alone — the operator's SCA infrastructure does — but making the device-side half of the obligation cryptographically observable rather than a credibility judgment.
Where the signed payload-assembly event reinforces Article 4 — and where it does not.
Quoted text is verbatim from Article 4 of (EU) 2018/389. EEI does not generate the authentication code — the operator's SCA infrastructure does. The rows below show where the signed payload-assembly event reinforces a code property or a session-protection clause, and where the clause is out of scope by construction.
| Article 4 paragraph (verbatim) | Obligation in plain terms | EEI signed payload-assembly event |
|---|---|---|
| Article 4(2)(a) no information on any of the elements referred to in paragraph 1 can be derived from the disclosure of the authentication code; | The auth code must not leak information about the underlying SCA elements. | The signed payload-assembly event does not carry any of the knowledge / possession / inherence elements themselves — only the assembled payload, the runtime trajectory, and signal classes. Disclosure of an Evidence Token therefore does not leak SCA elements. Indirect reinforcement. |
| Article 4(2)(b) it is not possible to generate a new authentication code based on the knowledge of any other authentication code previously generated; | Knowing one auth code must not let you generate the next one. | Each Evidence Token is independently signed by the in-TEE ZTBP keypair and carries a sequence number plus the prior-entry hash from the Local Evidence Ledger. Tokens are not derivable from each other; capture of one Evidence Token does not enable forging the next. Reinforcement, not substitution. |
| Article 4(2)(c) the authentication code cannot be forged. | The auth code must not be forgeable. | EEI does not protect the SCA authentication code itself — the operator's SCA infrastructure does. EEI strengthens the surrounding evidence: the signed payload-assembly event is anchored to a TEE-resident private key generated and registered via ZTBP, and is verified against the operator-stored public half with no vendor in the path. Forgery of the device-side event would require compromise of the TEE. |
| Article 4(3)(b) the number of failed authentication attempts that can take place consecutively, after which the actions referred to in Article 97(1) of Directive (EU) 2015/2366 shall be temporarily or permanently blocked, shall not exceed five within a given period of time; | Cap consecutive failed attempts at five within a defined window. | out of EEI scope Out of EEI scope. Attempt counting, temporary blocks and permanent blocks are governed by the operator's SCA infrastructure. The witness layer does not enforce attempt caps. |
| Article 4(3)(c) the communication sessions are protected against the capture of authentication data transmitted during the authentication and against manipulation by unauthorised parties in accordance with the requirements in Chapter V; | Communication sessions must be protected from capture and unauthorised manipulation. | EEI does not replace the Chapter V transport-protection requirements (TLS, channel integrity). It strengthens the device-side end of the session: the signed payload-assembly event makes any post-display manipulation of the (amount, payee) tuple observable to the verifier, independent of transport. Reinforcement. |
| Article 4(3)(d) the maximum time without activity by the payer after being authenticated for accessing its payment account online shall not exceed 5 minutes. | Five-minute inactivity timeout for authenticated online account access. | out of EEI scope Out of EEI scope. Session inactivity timeout is enforced by the operator's online-banking platform. The witness layer does not manage session lifecycle. |
| Article 4(4) Where the block referred to in paragraph 3(b) is temporary, the duration of that block and the number of retries shall be established based on the characteristics of the service provided to the payer and all the relevant risks involved, taking into account, at a minimum, the factors referred to in Article 2(2). The payer shall be alerted before the block is made permanent. Where the block has been made permanent, a secure procedure shall be established allowing the payer to regain use of the blocked electronic payment instruments. | Block management: duration, retries, alerts, unblock procedure. | out of EEI scope Out of EEI scope. Block lifecycle, payer alerting, and unblock procedures are governed by the operator's SCA infrastructure and customer-operations process. |
What EEI does not do for PSD2 SCA.
The witness layer strengthens evidential coverage of the dynamic-linking moment. The operator's SCA infrastructure remains the load-bearing path through Article 4 and Article 5.
- ·01
EEI is not an SCA factor
- EEI does not satisfy knowledge, possession, or inherence on its own. The two-or-more-elements requirement of Article 4(1) is satisfied by the operator's SCA infrastructure, not by the signed payload-assembly event.
- ·02
EEI does not replace possession-element verification
- Device binding via ZTBP is not the same as possession-element verification under Article 4(1). The operator's SCA stack continues to verify the possession factor; EEI signs the assembly context adjacent to that verification.
- ·03
EEI does not satisfy Article 4 or 5 alone
- No clause of Article 4 or Article 5 is satisfied by EEI in isolation. The signed payload-assembly event strengthens device-side evidential coverage of the dynamic-linking moment; the obligation remains the PSP's, fulfilled by the PSP's SCA infrastructure.
- ·04
EEI does not enforce attempt caps, timeouts, or block lifecycle
- Article 4(3)(b), 4(3)(d) and 4(4) — five-attempt cap, five-minute inactivity timeout, block management — are operator-side obligations. The witness layer does not manage session lifecycle.
Source attestation.
Article 4 and Article 5 are quoted verbatim from Commission Delegated Regulation (EU) 2018/389 (CELEX 32018R0389), EN edition published on EUR-Lex.
https://eur-lex.europa.eu/eli/reg_del/2018/389/oj/eng
The publication carries equal authority across all official EU languages; the EN edition is quoted here.
We sit with your SCA architects and map the dynamic-linking moment to signed device-side evidence.
Sixty minutes. Bring a recent Article 5 review and a sample authentication flow. We map the payload-assembly moment to the signed event; the rest of your SCA stack stays as you ship it today.
Request a PSD2 SCA mapping