A wallet can produce a valid cryptographic proof while a bank still needs answers: Which account does it relate to? What did the customer confirm? Does the evidence meet the bank's authentication policy? Who is responsible if something goes wrong?
EPC's SCARLET initiative brings those acceptance questions into focus. For teams building EUDI wallet integrations, the useful next step is to make those questions testable.
What EPC has announced
On 24 September 2026, the European Payments Council's Board approved the start of SCARLET: the Strong Customer Authentication Acceptance Rulebook and Liability Framework for EUDIW Transactions.
EPC plans business and contractual rules, common functional and operational rules, and technical specifications building on ARF, TS12 and large-scale pilot contributions. Development follows an invitation from the European Commission's DG CNECT and DG FISMA, with Commission and European Banking Authority collaboration and a multi-stakeholder group.
The announced plan is an open consultation in summer 2027 and publication of the first rulebook in December 2027. Version 1.0 will address the existing PSD2 framework; a subsequent version 1.1 will extend it to PSR. Scheme operation is envisaged after an implementation period.
These are development plans. The announcement does not supply a finished rulebook or certify a particular implementation. See the EPC SCARLET announcement.
Why acceptance needs more than a signature
Consider a customer confirming a EUR 25 payment to a merchant. The bank receives evidence with a valid signature. That is a necessary check, but it leaves several decisions unresolved.
The bank needs to associate the signing credential with the intended customer and funding source. It must establish that the confirmed amount and payee match the payment instruction. It must apply its authentication and risk policies, reject reused authorizations, and handle uncertain execution results without creating another payment.
Our view is that interoperability should be assessed across this entire decision chain. A successful presentation is useful evidence; its meaning depends on the context and the rules applied to it.
Four outcomes worth keeping separate
In our proposed experiment, we distinguish four outcomes:
- Proof verified: the native proof passed the applicable cryptographic, credential and transaction-binding checks.
- Authentication policy satisfied: the available evidence meets the bank's selected policy.
- Authorization accepted: the bank accepts the customer's authorization for the intended instruction.
- Payment executed: the payment system reports execution, with its source and status identified.
These distinctions matter when something fails. A valid proof can still lack required authentication evidence. An accepted authorization can be followed by a failed transfer. A timeout can leave execution uncertain. Software and operational teams need to preserve those differences rather than collapse them into one “success” response.
The beneficiary must remain the same
A customer-facing payee name does not, by itself, identify the account that will receive funds.
For a pilot, we propose an authenticated mapping between the confirmed payee, the expected merchant and the actual beneficiary. That mapping belongs to the authorization context and must remain fixed for that authorization. If an intermediary later changes the destination, the execution system must reject the substituted instruction.
This is an explicit requirement of our experiment, rather than a claim that every native proof already carries the beneficiary account identifier. The question for implementers is which signed fields and authenticated mappings establish the connection unambiguously.
Preserve the native evidence
Wallet mechanisms and browser authentication have different proof structures. Verification should respect those differences.
EWC RFC008 describes payment-data confirmation using OpenID4VP, a payment wallet attestation and transaction-data hashes in a key-binding JWT. It also requires matching payment details against intermediary-provided information in a three-party flow.
Secure Payment Confirmation provides a browser-mediated confirmation ceremony using WebAuthn. Its verification procedure checks the payment information and expected origins alongside the authentication assertion.
A common acceptance experiment can compare verification obligations across these paths without translating or re-signing their proofs. Each adapter should preserve the original artifacts and follow a pinned native profile. Matching outcome labels do not establish equal assurance.
SPC is a comparison mechanism in our experiment. Its inclusion does not imply coverage by SCARLET.
Our proposed contribution
DLBR has submitted an Interoperable Payment Authorization Evidence Profile proposal to the W3C EUDI-4-Payments community repository.
The proposed first experiment is deliberately small: one bank, one SPC implementation and one wallet team, using one immediate payment, one currency and one beneficiary. The same test matrix would cover amount and payee substitution, incorrect origins, expired challenges, missing authentication evidence, replay, and duplicate execution during retries or fallback.
The proposal also asks how evidence can remain verifiable after keys, metadata or policies change. That means retaining the applicable public verification material and original artifacts with controlled access, while excluding private keys and authentication secrets from the evidence archive.
We would like this work to provide implementation evidence and reusable acceptance tests that could inform SCARLET development. It is an independent discussion proposal, with no claim of EPC or W3C endorsement, an agreed pilot, or demonstrated production interoperability. Contractual eligibility and liability remain matters for applicable law, contracts and the selected scheme.
What teams can prepare now
Our recommendation is to document the acceptance decisions that an integration already makes: credential-to-account association, confirmed transaction matching, authentication evidence, beneficiary mapping and retry behaviour. Then identify which checks are covered by the selected native profile and which depend on bank or scheme rules.
That produces concrete questions for rulebook development and consultation. It also gives potential pilot partners something they can review and test together.
Banks, wallet teams and payment integrators can review the proposal and negative-test matrix. The question we want to explore is practical: can different native proofs support a clearly defined acceptance decision, with evidence that all responsible parties can verify?