The EUDI Wallet can do more than identify a customer. With the EUDI Wallet payment specification, TS 12, a wallet can show the customer a transaction, authenticate them with two factors, and sign over exactly what they approved. DLBR EID verifies those presentations for banks, payment institutions and e-money issuers, so your team can add wallet-based SCA without building the protocol and trust checks yourself.
For the regulatory timeline, see EUDI Wallet acceptance for banks: what the December 2027 deadline requires.
How wallet-based SCA works
TS 12 splits the work between three parties:
- Your organisation issues an SCA attestation to the customer's wallet, bound to the customer and, where relevant, to an account or card.
- For each login or payment, you send a request with the transaction details. The wallet shows them to the customer, authenticates the customer, and returns a presentation signed with the wallet's key.
- The verifier checks the presentation, and you decide whether to authorise the login or payment.
DLBR EID does step 3. You keep the attestation, the customer relationship and the authorisation decision.
What DLBR EID verifies
The transaction the customer approved
A request carries one of four TS 12 transaction types: payment, login and risk, account access, or e-mandate. DLBR EID checks each payload against its schema before the request reaches the wallet, including payee, amount, currency, and recurring-payment details.
The wallet must sign a hash of the exact transaction data it was shown. DLBR EID recomputes that hash and rejects any mismatch, so a presentation cannot authorise a different amount or payee. This is the dynamic linking that remote payments require.
Two independent factors
The wallet states which factors it used, such as a PIN and a key held in the device's secure hardware. DLBR EID requires two factors from different categories (knowledge, possession, inherence), using only the methods TS 12 defines.
Each request can narrow this with a policy. For example, you can require a possession factor, limit possession to keys held in secure hardware, or refuse unspecified methods. A presentation that does not meet the policy fails with its own result code, so your team can tell a policy miss from a broken signature.
A single-use authentication code
Every TS 12 presentation carries a one-time authentication code. DLBR EID accepts each code once. A presentation that reuses a code from an earlier verification fails, and if the check cannot run, the verification fails instead of passing.
A trusted SCA attestation
DLBR EID only accepts SCA attestations whose issuer and credential type an operator has reviewed and pinned, together with the transaction types that credential may authorise. It does not fetch that metadata during a verification.
Evidence for audit and outsourcing
If DLBR EID verifies SCA elements on your behalf, expect your outsourcing agreement to cover audit rights and evidence. Each verified SCA presentation adds an entry to DLBR EID's hash-chained audit log with:
- the transaction types;
- the hashes of the transaction data the wallet signed;
- the authentication codes;
- the factors the wallet asserted.
The entry stores no amounts, payees or claim values. Anyone holding the original transaction data can recompute the hash and match it to the entry. The chain makes later changes to an entry detectable.
What stays with your organisation
- Issuing the SCA attestation and binding it to the customer, account or card.
- The authorisation decision. A verified presentation means the wallet's proof is valid. It is not a payment authorisation or settlement.
- Payment-network rules, such as supported currencies and amount precision.
- An alternative route for customers who do not use a wallet.
Wallet support today
TS 12 support in wallets is still emerging. Some wallet builds do not yet accept TS 12 transaction types and reject the request before the customer sees it. Test with the wallets your customers will use, and keep your existing SCA methods available while support grows.
FAQ
Does DLBR EID authorise payments?
No. DLBR EID verifies the wallet's presentation and the signed transaction binding. Your organisation decides whether to authorise the payment.
Can we restrict which authentication methods we accept?
Yes. Each request can require specific factor categories, limit each category to listed TS 12 methods, and refuse unspecified methods.
What happens if a wallet reuses an authentication code?
The verification fails with a result code that says the code was reused. The code is not accepted twice.
Do you store transaction details?
The audit log stores hashes of the transaction data, not amounts or payees. Verified results are held briefly so your service can collect them, as described in our privacy notice.
How can we try it?
DLBR EID is accepting private-pilot requests from banks, payment institutions and e-money issuers. Request pilot access with a short description of the journeys you want to cover.