EPC SCARLET: EUDI Wallet SCA Acceptance and the eIDAS 2 Clock

On 24 September 2026 the Board of the European Payments Council (EPC) approved the start of development of EPC SCARLET, the Strong Customer Authentication Acceptance Rulebook and Liability Framework for EUDIW Transactions. The EPC announced the decision on 19 October 2026. SCARLET is meant to give the 3,000+ payment service providers (PSPs) and the 27+ EU Digital Identity Wallet providers that the EPC expects to operate in the EU/EEA one set of business, contractual and technical rules for accepting wallets in strong customer authentication (SCA).

The planning problem is the gap between two calendars. The EPC intends to publish the SCARLET 1.0 rulebook in December 2027, after an open consultation scheduled for summer 2027, and the scheme will enter into effect only after an implementation period. The legal duty sits elsewhere. Article 5f(2) of Regulation (EU) No 910/2014, as amended by Regulation (EU) 2024/1183 (eIDAS 2), requires private relying parties that must use strong user authentication for online identification, including in banking and financial services, to also accept European Digital Identity Wallets at the user’s voluntary request no later than 36 months after the relevant implementing acts entered into force. By my count that period ends on 24 December 2027.

Related reading: PSD2 Reporting Requirements

SCARLET and eIDAS 2 key dates

The table separates enacted law, published specifications, EPC plans and my own date arithmetic. The three calculated rows are labelled as such.

Both eIDAS periods run from the entry into force of the implementing acts “referred to in Article 5a(23) and Article 5c(6)”. The four Article 5a(23) acts were amended in July 2026 by Implementing Regulation (EU) 2026/1731. Article 5f(2) says nothing about an amendment restarting the clock, and my working assumption is that the December 2024 start date stands. The EPC release says SCARLET 1.0 will also allow PSPs to comply with the European Digital Identity Framework regulatory deadline, but it does not state which date it reads that deadline as.

Where the acceptance duty comes from: Article 5f(2) of the amended eIDAS Regulation

Article 5f(2) has three conditions, and each one narrows the population. The relying party must be private. Union or national law must require it to use strong user authentication for online identification, or a contractual obligation must require it; the Article lists transport, energy, banking, financial services, social security, health, drinking water, postal services, digital infrastructure, education and telecommunications as areas where this arises. The acceptance obligation is triggered only on the voluntary request of the user. Recital 56 of Regulation (EU) 2024/1183 applies the same logic to banking and financial services, and recital 62 says secure electronic identification and attestations of attributes should help the financial sector meet strong customer authentication requirements for online identification when customers log into accounts or carry out payment transactions.

Micro and small enterprises, as defined in Article 2 of the Annex to Commission Recommendation 2003/361/EC, are carved out. The Commission’s SME guidance puts a micro enterprise at fewer than 10 staff with turnover or balance sheet total of EUR 2 million or less, and a small enterprise at fewer than 50 staff with turnover or balance sheet total of EUR 10 million or less. The same guidance warns that a firm belonging to a larger group may need to include group headcount, turnover or balance sheet data. A 40-person payment institution owned by a banking group can therefore fail the small-enterprise test once group figures are counted.

The verb matters too. Article 5f(2) requires in-scope parties to “also accept” wallets, and Article 5a(15) makes wallet use voluntary, with access to public and private services remaining possible through other existing identification and authentication means. Wallet acceptance is an addition to the SCA methods a PSP already runs. Nothing in Article 5f(2) depends on joining SCARLET either. An in-scope PSP carries the obligation whether or not it ever adheres to the scheme; SCARLET is a way of meeting it on terms shared with other PSPs and wallet providers.

Accepting wallets also brings relying-party obligations. Under Article 5b, a relying party that intends to use wallets registers in the Member State where it is established, declares its intended use and the data it will request, and may not ask users for more than it registered. Article 5b(9) makes the relying party responsible for carrying out the authentication and validation of the person identification data and attestations it requests from wallets.

What the EPC SCARLET scheme will contain

The EPC lists three building blocks. The first is a business and contractual framework that defines scheme actors, eligibility requirements, and the rights and obligations of participating legal entities. The second is a set of common functional and operational rules. The third is technical specifications that rely on the Commission’s Architecture and Reference Framework (ARF), the related technical specification TS12 and contributions from the Large-Scale Pilots.

Versioning follows the legislation. SCARLET 1.0 covers wallet acceptance under PSD2 (Directive (EU) 2015/2366), the EBA’s regulatory technical standards on SCA (Commission Delegated Regulation (EU) 2018/389), applicable level 2 legislation and other regulatory guidance. SCARLET 1.1 will extend the framework to the forthcoming PSR, “in due time” for participant PSPs to comply with the PSR from 2028/29 onwards while preserving earlier investment.

The EPC took this on in response to an invitation from two Commission directorates-general, DG CNECT and DG FISMA. An EPC taskforce will develop it in close collaboration with the Commission and the EBA, and a multi-stakeholder group will bring in representatives of the wallet ecosystem. SCARLET will sit alongside the EPC’s other scheme rulebooks, such as its Verification of Payee scheme rulebook and the FRIDA fraud data-sharing scheme.

The word that deserves attention is “Liability” in the scheme’s name. EPC Director General Giorgio Andreoli describes the aim as common contractual, business and technical interoperability rules “with a clear allocation of responsibility”. TS12, the technical layer SCARLET builds on, contains no liability allocation at all. My reading is that the contractual split of responsibility between the PSP that relies on a wallet presentation and the wallet provider that produced it is the part of SCARLET no specification will supply.

A private scheme can allocate losses between its participants. The payer’s statutory position under Article 74(2) of PSD2 stays with the legislation: where the payer’s PSP does not require SCA, the payer bears no financial losses unless it acted fraudulently, and a payee or payee’s PSP that fails to accept SCA refunds the financial damage caused to the payer’s PSP.

How eIDAS strong user authentication differs from PSD2 SCA

The two regimes use different terms for overlapping ideas, and the overlap is where the Article 5f(2) acceptance duty meets PSD2. Article 3(51) of the amended eIDAS Regulation defines strong user authentication; Article 4(30) of PSD2 defines strong customer authentication. The SCA stack then adds requirements that the eIDAS definition does not carry.

The gap between the two definitions drew an early industry objection. In May 2025 the Dutch Payments Association (Betaalvereniging Nederland), working with an eIDAS 2.0 taskforce and INNOPAY, published a feasibility assessment arguing that SCA under PSD2 involves much more than two-factor authentication, and that it seemed impossible for PSPs to accept the wallet for two-factor authentication while fully complying with PSD2 and the RTS. That assessment predates TS12 version 1.0 by more than six months.

TS12 addresses that gap at the technical level. It carries transaction data in a payload validated against a schema, requires a Key Binding JWT that cryptographically binds the user’s action to the transaction, requires the wallet to list at least two of the three factor categories, and treats the verified token identifier as the authentication code PSD2 requires for electronic payments. What TS12 cannot do is discharge the PSP’s own assessment. The EBA’s June 2019 opinion on SCA elements accepts that an app or a key can evidence possession provided a device-binding process ensures a unique connection between the app or key and the device. Whether a particular wallet solution’s binding, its PIN or biometric unlock and its secure execution environment meet RTS Articles 6 to 9 is a question the PSP has to evidence for its own supervisor, wallet by wallet.

What TS12 settles, and what it leaves to a sector rulebook

TS12 version 1.0 was published on 5 December 2025 in the Commission’s EUDI Wallet standards repository, with an editorial update (version 1.0.1) on 30 January 2026. Its stated scope is the data structures and processing rules for SCA under PSD2 using wallets, as the minimum basic SCA flow every wallet solution must support. This version covers one credential format and one presentation protocol: SD-JWT VC and OpenID4VP.

It defines four transaction types: payment confirmation, login and confirmation of actions carrying a risk of fraud or abuse, payment account information access, and e-mandates. The actor model has build consequences for the roles a PSP performs. The attestation provider that issues the SCA attestation into the user’s wallet unit is usually the user’s own PSP, the account servicing PSP. The relying party that requests the presentation can be a PSP, a payee or merchant, or a PISP or AISP.

TS12’s reference model contemplates an account-servicing PSP issuing an SCA attestation into the customer’s wallet and a relying party verifying its subsequent presentation. A PSP implementing this model needs the corresponding issuance and verification capabilities for the roles it performs, whether directly or through an appropriate service arrangement. Article 5f(2) itself imposes wallet acceptance on qualifying private relying parties; it does not expressly require every account-servicing PSP to issue SCA attestations.

The specification leaves these matters outside its text, the first three expressly and liability by silence:

• registration, meaning the binding of a wallet unit to the payment account;
• the communication between a third party and the account servicing PSP in flows the third party requests;
• specific SCA attestation types and full attribute sets, which TS12 leaves to sector attestation rulebooks, while payment-network-specific support for optional transaction parameters remains the relying party’s responsibility;
• any allocation of liability.

Set that list beside the EPC’s three building blocks and the fit is close. TS12 lets sector SCA attestation rulebooks specify attestation types, full attribute sets, extended metadata, transaction data and display rules, and other requirements such as policies for attestation providers or relying parties; scheme actors, eligibility and rights and obligations are what the EPC plans to define in SCARLET’s business and contractual framework.

Binding a wallet to the payment account under RTS Articles 24 to 27

Because TS12 puts registration out of scope, the enrolment ceremony is the PSP’s to design, and the RTS already regulates it. Article 24 requires PSPs to ensure that only the payment service user is associated, in a secure manner, with the personalised security credentials, authentication devices and software. Association has to happen in secure environments under the PSP’s responsibility, and where it is done through a remote channel it has to be performed using SCA. Article 25 governs secure delivery and activation, Article 26 renewal, and Article 27 destruction, deactivation and revocation, including revocation of the related records in the PSP’s own systems.

Article 24(2)(b) requires SCA when the payment service user’s identity is associated remotely with personalised security credentials or authentication devices or software. It does not prescribe which pre-existing authentication method must be used. PSPs must design compliant first-enrolment and recovery processes and preserve appropriate access for customers who choose not to use a wallet, consistently with the voluntary-use provisions of eIDAS.

Revocation runs in two directions. Under Article 5e of the amended eIDAS Regulation, a Member State that provided wallets must suspend their provision and use without undue delay if their security is breached or partly compromised in a way that affects reliability, inform the affected users, the single points of contact, relying parties and the Commission, and withdraw and revoke the wallets if the breach is not remedied within three months. A PSP accepting wallets needs a documented route from that notification to blocking the affected attestations and falling back to another SCA method.

PISPs, AISPs and the account servicing PSP’s interface

Article 30(2) of the RTS requires the access interface of an account servicing PSP to let AISPs and PISPs rely on all the authentication procedures it provides to its payment service users. My reading is that once an account servicing PSP offers wallet-based SCA to its own customers, third-party flows through its interface need to support that procedure as well. TS12 names PISPs and AISPs as possible relying parties, yet puts the communication between the third party and the account servicing PSP outside its scope. The EPC release does not say how SCARLET will treat third-party providers, which makes it a concrete point to raise when the scheme goes to consultation.

From PSD2 to the PSR: why SCARLET needs a version 1.1

SCARLET 1.0 is built on PSD2 because the PSR, the directly applicable half of the package covered in our PSD3 overview for payment and e-money institutions, is still unfinished. The European Parliament’s Legislative Train page, last updated on 20 September 2026, records the 27 November 2025 provisional agreement and ECON’s 5 May 2026 approval of the agreed text, and records no Official Journal publication. As at 20 October 2026, formal adoption of the PSR by Parliament and Council remains pending. A later legislative text than the Commission’s 2023 proposal (COM(2023) 367) is available: the Council’s final compromise text, document 8221/26 of 17 April 2026, contains negotiated provisions including Articles 87 to 89, but is not yet binding law.

Three provisions of that compromise text bear on wallet-based SCA. Article 89(3) envisages regular EBA reviews of the SCA regulatory technical standards, including developments relating to European Digital Identity Wallets. Article 88 provides for accessible SCA methods and more than one means of authentication. Its restriction on making SCA dependent on smartphone possession includes an exception where the payment service user has agreed to services provided exclusively through mobile applications. Article 87 envisages an outsourcing agreement where a technical service provider provides and verifies SCA elements for the payer’s PSP.

The Commission proposal’s express full-liability wording is absent from Article 87 of the Council’s April 2026 compromise. However, recital 119 of that compromise separately states that payer PSPs should retain full liability, under outsourcing agreements, for failures by operators of digital pass-through wallets to apply SCA. The recital is not itself an operative obligation and does not establish that every EUDI Wallet provider qualifies as a digital pass-through wallet operator. The final adopted provisions and the actual services performed will determine the applicable requirements.

Article 87 leaves an open classification question. A wallet provider that supplies and verifies an SCA element looks functionally close to the technical service provider that Article 87 describes, but neither the Commission proposal nor the Council compromise text mentions wallets in that Article. Under Article 87 of the April 2026 Council compromise, the outsourcing-agreement requirement would depend on whether a technical service provider actually provides and verifies SCA elements for the payer’s PSP. Its application to a wallet provider would therefore depend on the activities performed and the final adopted PSR wording, rather than on SCARLET’s classification alone.

Payment statistics and fraud data after wallet SCA

For euro-area reporting agents, Regulation (EU) No 1409/2013 of the ECB on payments statistics (ECB/2013/43), as amended by Regulation (EU) 2020/2011 (ECB/2020/59), sets out the fraud-reporting requirements in Tables 5a and 5b. These distinguish SCA and non-SCA authentication, including the prescribed reasons for non-SCA, and provide loss breakdowns by liability bearer: the reporting PSP, its payment service user and others. Reporting agents without a relevant Article 4 derogation submit Table 5a semi-annually; those with the relevant derogation submit Table 5b annually with a half-yearly breakdown. PSPs in non-euro-area jurisdictions must check the reporting framework applicable through their national arrangements rather than assuming direct application of these ECB tables.

Tables 5a and 5b have no wallet-specific authentication category. A fraudulent payment authenticated through a wallet should be classified as authenticated via SCA only where the authentication actually satisfies PSD2 and the applicable SCA regulatory technical standards; otherwise the relevant non-SCA reporting classification applies. Losses must be attributed to the reporting PSP, its payment service user or others according to the party actually bearing the reportable loss. A prospective SCARLET contractual allocation does not automatically establish the “others” classification without assessing its actual financial effect.

Frequently Asked Questions

A customer asks to authenticate with a wallet in mid-2027, before the 36-month period ends. Does Article 5f(2) already apply?

Article 5f(2) sets acceptance “no later than” the end of the 36-month period, so before that date an in-scope PSP may accept wallets without yet being obliged to. Member States have to provide wallets earlier, under Article 5a(1), so such requests can arrive during 2027. A PSP that accepts early is still applying SCA under PSD2 and the RTS, and the same evidence on factors and dynamic linking applies.

Does SCARLET cover opening an account with the wallet?

The EPC’s announcement scopes SCARLET to SCA acceptance. Customer identification at onboarding is currently governed by the applicable national AML/CFT framework implementing existing EU requirements. Regulation (EU) 2024/1624 (AMLR) establishes the forthcoming directly applicable framework, including provisions concerning electronic identification, but generally applies only from 10 July 2027 under Article 90. Its future requirements should therefore be distinguished from the rules applicable to onboarding as at October 2026. Onboarding and SCA are separate legal routes, covered in our EU AML package guide.

Does a user’s request oblige us to accept a wallet provided by another Member State?

Article 5f deals with cross-border use of the wallets, and paragraph 2 refers to wallets “provided in accordance with this Regulation” without limiting them to the relying party’s own Member State. Under Article 5d, Member States notify the Commission of wallets that have been provided and certified, and the Commission publishes and maintains a list of certified wallets in the Official Journal. I read the duty as attaching to any wallet on that list, whichever Member State provided it, which puts a list-status check in the verification flow.

Should we wait for the SCARLET 1.0 rulebook before building?

The Article 5f(2) duty does not depend on the rulebook, and TS12 version 1.0 is already published. Relying-party registration under Article 5b is a legal requirement that sits outside the scheme. What the rulebook will add is the contractual, eligibility and liability layer, so architecture choices that would be expensive to reverse are worth testing against the consultation draft.

Does SCARLET apply outside the euro area?

The EPC frames the scheme for PSPs and wallet providers operating in the EU/EEA, and Article 5f(2) contains no currency condition. The release does not limit SCARLET to euro payments, and it does not say how the scheme will treat non-euro payment accounts.

Related Articles

• PSD2 Reporting Requirements: the fraud, incident and security reporting duties PSPs already carry under PSD2.
• EPC Verification of Payee 2.0 Scheme Rulebook: how the EPC’s next-generation VOP scheme standard affects EU PSPs.
• FRIDA Scheme Rulebook and Fraud Data Sharing: the EPC’s fraud information distribution arrangement and what participants sign up to.
• PSD3 for Luxembourg Payment Institutions and E-Money Institutions: what the PSD3 and PSR package changes for authorised payment and e-money firms.
• Digital Euro Rulebook and the ECB Expert Call for PSPs: a separate digital euro scheme rulebook that remains under development; any binding interaction with EUDI Wallet authentication has not yet been established.

Key Takeaways

• Record 24 December 2027 as the working Article 5f(2) date, together with the assumption that the July 2026 amending regulation did not restart the clock, and revisit it if the Commission or the EPC states a different reading.
• Retain an appropriate non-wallet authentication route for customers who do not use the wallet, and confirm that remote enrolment and recovery comply with RTS Article 24(2)(b). That provision requires SCA for remote association but does not prescribe a particular existing method.
• Register each relying-party entity in its own Member State of establishment under Article 5b; on a plain reading, a group with PSPs in several Member States registers each one there.
• Add a liability-bearer field to fraud case records before the first wallet-authenticated payment goes live.
• Treat an Article 5e suspension notice as an incident trigger with a named owner, and test the switch from wallet SCA to the fallback method before go-live.
• Note 11 August 2028: the recitals of Implementing Regulation (EU) 2026/1731 say the requirement for wallet units to authenticate and validate relying-party registration certificates should apply only from that date.

Sources and References

• European Payments Council, news item: EPC launches SCARLET initiative to support consistent use of EU Digital Identity Wallets in payment authentication (19 October 2026)
• European Payments Council, press release EPC267-26 v1.0: SCARLET press release (PDF) (19 October 2026)
• Regulation (EU) 2024/1183 of 11 April 2024 amending Regulation (EU) No 910/2014 as regards establishing the European Digital Identity Framework: EUR-Lex
• Commission Implementing Regulation (EU) 2024/2977 on person identification data and electronic attestations of attributes issued to European Digital Identity Wallets: EUR-Lex
• Commission Implementing Regulation (EU) 2024/2979 on the integrity and core functionalities of European Digital Identity Wallets: EUR-Lex
• Commission Implementing Regulation (EU) 2024/2980 on notifications to the Commission concerning the European Digital Identity Wallet ecosystem: EUR-Lex
• Commission Implementing Regulation (EU) 2024/2981 on the certification of European Digital Identity Wallets: EUR-Lex
• Commission Implementing Regulation (EU) 2024/2982 on protocols and interfaces to be supported by the European Digital Identity Framework: EUR-Lex
• Commission Implementing Regulation (EU) 2026/1731 of 15 July 2026 amending Implementing Regulations (EU) 2024/2977, 2024/2979, 2024/2980 and 2024/2982: EUR-Lex
• Directive (EU) 2015/2366 on payment services in the internal market (PSD2): EUR-Lex
• Commission Delegated Regulation (EU) 2018/389, regulatory technical standards for strong customer authentication and common and secure open standards of communication: EUR-Lex
• EBA Opinion on the elements of strong customer authentication under PSD2 (EBA-Op-2019-06, 21 June 2019): EBA (PDF)
• European Commission, EUDI Wallet technical specification TS12, Specification of electronic payments Strong Customer Authentication (SCA) implementation with the wallet: EUDI Wallet standards repository
• Commission proposal for a Regulation on payment services in the internal market, COM(2023) 367: EUR-Lex
• Council of the EU, document 8221/26 (17 April 2026), final compromise text of the Payment Services Regulation, interinstitutional file 2023/0210 (COD): Consilium (PDF)
• European Parliament Legislative Train, Payment services regulation: European Parliament
• Council of the EU press release, Payment services: Council and Parliament agree to step up the fight against fraud and increase transparency (27 November 2025): Consilium
• Commission Recommendation 2003/361/EC concerning the definition of micro, small and medium-sized enterprises: EUR-Lex; Commission guidance: SME definition
• Regulation (EU) No 1409/2013 of the European Central Bank of 28 November 2013 on payments statistics (ECB/2013/43): EUR-Lex; amended by Regulation (EU) 2020/2011 of the European Central Bank (ECB/2020/59): EUR-Lex
• Regulation (EU) 2024/1624 on the prevention of the use of the financial system for the purposes of money laundering or terrorist financing (AMLR): EUR-Lex
• Betaalvereniging Nederland, EU digital identity wallet for payments: interpretation and feasibility assessment (21 May 2025): Betaalvereniging

Preparing for the EPC SCARLET consultation in summer 2027

The next fixed point on the EPC side is the open consultation on SCARLET 1.0 in summer 2027, and on the eIDAS side the Member State wallet deadline that by my count falls on 24 December 2026. Before the consultation opens, an in-scope PSP can have three artifacts ready: an Article 5f(2) scoping note per legal entity, including the group-level SME test; a mapping of TS12 to RTS Articles 4 to 9 and 24; and a list of the questions TS12 leaves open, starting with third-party provider flows and liability between PSP and wallet provider. Those are the points against which the SCARLET 1.0 consultation draft can be read when it is published in summer 2027.

Disclaimer: The information on RegReportingDesk.com is for educational and informational purposes only. It does not constitute legal, regulatory, tax, or compliance advice. Always consult your compliance officer, legal counsel, or the relevant supervisory authority for guidance specific to your institution.