Which rules govern CASP authentication and KYC? | Authologic Legal Briefing

Key takeaways

• A CASP's obligations on authentication cannot be read from one regulation. The regulatory status has to be established first, because MiCA, DORA and payment services rules each attach different duties.
• Under DORA a CASP is subject to authentication requirements as part of its ICT security and access-control framework, including the use of strong authentication mechanisms in specified access scenarios. That is however not automatically the same as strong customer authentication under PSD2.
• Payment rules apply only where the activity qualifies as a payment service, and a key issue is whether the relevant EMT-related activity itself qualifies as a payment service.
• Core KYC and AML obligations do not stem from MiCA. MiCA requires an applicant to submit mechanisms, policies and procedures for money laundering and terrorist financing risk, but the substantive duties sit elsewhere. CASPs within the AML/CFT scope are already subject to AML/CFT requirements under Directive (EU) 2015/849, as amended by Regulation (EU) 2023/1113, while the AMLR applies from 10 July 2027.
• The EUDI Wallet and electronic attestations of attributes will not replace sanctions and PEP screening, beneficial ownership determination, risk assessment or transaction monitoring.

Which regimes apply to a CASP, and what does each require?

Five regimes can apply at once, and they attach to different things: what the provider is, what it does, and how it identifies its customers.

The rest of this briefing takes them in turn.

What does MiCA require on authentication?

Less than the name suggests, and nothing on the mechanism itself.

According to the MiCA Regulation (Article 75(1)(d)), crypto-asset service providers providing custody and administration of crypto-assets on behalf of clients shall conclude an agreement with their clients to specify their duties and their responsibilities. Such an agreement shall include, among others, the means of communication between the crypto-asset service provider and the client, including the client's authentication system.

MiCA does not provide a definition of authentication. Authentication is referenced by, among others, the eIDAS Regulation, including the so-called eIDAS 2.0.

The practical consequence is that MiCA obliges a provider to describe its authentication system contractually, but does not set the standard that system has to meet. That standard comes from elsewhere.

What does DORA require, and is it the same as SCA?

DORA requires a strong authentication mechanism; it does not explicitly require Strong Customer Authentication (SCA). The use of "strong authentication methods" is also mentioned in RTS (EU) 2024/1774 to DORA, but it does not refer separately to CASPs in this regard. While the two concepts are not legally interchangeable, their technical implementations frequently overlap.

Under Article 2(1)(f), read together with Article 2(2), of DORA, an authorised CASP within DORA's scope constitutes a "financial entity". Consequently, pursuant to Article 9(4)(d) of DORA, it is required, inter alia, to implement policies and protocols for strong authentication mechanisms, based on relevant standards and dedicated control systems, and protection measures of cryptographic keys whereby data is encrypted based on results of approved data classification and ICT risk assessment processes.

A CASP falling under DORA must apply appropriate access control and authentication mechanisms, including strong authentication, as part of its ICT system security. However, this is not automatically the same as Strong Customer Authentication (SCA) required under PSD2, although the provisions of PSD2 and DORA contain cross-references.

The mechanisms applied under DORA may technically overlap with solutions used for SCA, but that overlap does not automatically imply compliance with all PSD2 requirements. Conversely, PSD2 mechanisms may satisfy the authentication requirements referred to in DORA, though this must be evaluated on a case-by-case basis.

When do payment rules apply to a CASP?

When the activity is a payment service, not when the business calls itself one.

To define a CASP's obligations regarding authentication, one must determine the cross-references between crypto-asset regulations and payment services regulations, depending on the actual scope of the CASP's activities. Put simply, the key factor is whether the CASP's activity involves tokens qualifying as electronic money (EMT) and whether the relevant activity qualifies as a payment service.

Depending on the precise service model, a CASP may require an appropriate payment authorisation, or a cooperation model with an authorised payment service provider, where the relevant activity qualifies as a payment service, including where it:

• executes an EMT transfer on behalf of a user,
• maintains an EMT wallet from which the user can send EMTs to or receive them from third parties,
• executes or handles an EMT transfer used to pay for goods or services,
• processes deposits, withdrawals, or transfers in fiat currencies.

Currently, the PSD2 Directive applies to CASP activities that qualify as payment services. According to the EBA's position (including Opinion EBA/OP/2026/01), the mere exchange of crypto-assets for funds or other crypto-assets does not, as a rule, constitute a payment service. However, executing EMT transfers on behalf of clients, including first-party pay-out transfers from custody wallets, may itself qualify as a payment service under PSD2, regardless of whether the wallet is formally classified as a payment account. Importantly, the fact that a transfer is made to the same client does not, in itself, take that transfer outside the scope of PSD2.

The EBA transition period for obtaining the required PSD2 authorisation ended on 2 March 2026. Following the expiry of the EBA's No-Action Letter transitional standstill on 2 March 2026, for CASPs performing EMT payment services, including CASPs permitted to continue operating under the transitional arrangements set out in EBA/OP/2026/01 while their PSD2 authorisation application is pending, PSD2 SCA rules are now fully enforceable for online wallet access, and transfer initiation.

SCA is generally based on at least two independent elements: a knowledge element (such as a password), a possession element (such as the user's device), or an inherence element (such as a biometric feature). For remote electronic payments, requirements regarding dynamic linking, which ties the approval to the specific amount and payee, also apply.

The agreed texts of PSD3 and the Payment Services Regulation are intended to separate trading and investing in electronic money tokens more precisely from using them for payments, but they are not yet in force. The legislative procedures remain ongoing.

What are a CASP's AML and KYC obligations?

For CASPs within the AML/CFT scope, the obliged-entity framework - and it does not come from MiCA.

CASPs within the AML/CFT scope are already subject to the AML/CFT framework established by Directive (EU) 2015/849, as amended by Regulation (EU) 2023/1113 and implemented in national law. The AMLR will apply from 10 July 2027 across the EU, without national transposition. From that date, the AMLR customer due diligence (CDD) framework will require, among other things, a CASP to:

• identify the customer and verify their identity;
• identify and verify the identity of any person acting on behalf of the customer and verify their authorisation;
• identify the beneficial owner and take reasonable measures to verify their identity;
• understand the purpose and intended nature of the business relationship;
• check whether the customer or beneficial owner is subject to targeted financial sanctions and determine the relevant PEP status;
• assess and manage customer ML/TF risk;
• monitor the business relationship and transactions.

Separately, Regulation (EU) 2023/1113 requires originator and beneficiary information to accompany crypto-asset transfers and provides specific requirements in relation to transfers to and from self-hosted addresses.

Core KYC and AML obligations do not stem directly from MiCA. However, MiCA requires an applicant seeking CASP authorisation to submit mechanisms, policies and procedures to identify, assess and manage money laundering and terrorist financing risks, under Article 62(2)(i) MiCA and Article 6 of Delegated Regulation 2025/305.

Bringing a CASP under payment regulations does not generally necessitate a second KYC process. It may, however, add requirements regarding SCA, payment security, fraud monitoring and liability for unauthorised transactions.

To test your own position across both the AMLR and eIDAS 2.0, see the SCA & AMLR Readiness Checklist. Which platforms cover these obligations, and how they differ on credential coverage, screening and source of funds, is set out in Best AML and KYC identity verification platforms.

For the wider customer due diligence framework and the verification pathways recognised under the AMLR, see How the EUDI Wallet changes KYC.

How does the EUDI Wallet fit into CASP onboarding and authentication?

As a recognised pathway, on two separate tracks that are easy to conflate.

Two dates, and they answer different questions. The EUDI Wallet is an electronic identification means at assurance level high, and from 10 July 2027, when the AMLR applies, it can serve as a recognised means of customer identity verification under Article 22(6)(b) AMLR. The CASP must nevertheless obtain any customer identification information required by Article 22 AMLR that is not contained in the PID or other credential presented through the Wallet. That follows from the AMLR, not from eIDAS.

The second date is 24 December 2027, and it concerns acceptance rather than identification: from then, providers within scope must be able to accept the Wallet where the law requires strong user authentication at the user's request.

Additionally, if a CASP is also subject to PSD2 or PSR and PSD3, as a rule, it will have to be prepared to support the EUDI Wallet upon client request as part of strong customer authentication processes from 24 December 2027. It will therefore be one among several, yet mandatory to support and provide, pathways for strong authentication. This requires readiness not only on a technical level, but also on a formal legal level, for example in customer-facing terms and conditions.

During onboarding, the EUDI Wallet may enable the user to present Person Identification Data, confirmation of age, country of residence, nationality, and other attributes verified by a designated issuer. This can reduce the submission of document scans, manual data re-entry, errors, and the risk of identity fraud.

The obligation itself, and its scope for private relying parties, is set out in How eIDAS 2.0 affects private relying parties and SCA.

What does the EUDI Wallet not do for a CASP?

Three things, and each of them is a common assumption.

A non-qualified electronic attestation of attributes can support the KYC process if the CASP deems the issuer, data source and verification method appropriate. Not every attestation will automatically suffice to fulfil statutory identity identification or verification obligations. The tiers of attestation, and what distinguishes them, are defined in What is inside the wallet.

The mere presentation of Person Identification Data (PID) or an attestation does not automatically constitute a compliant SCA process. Meeting SCA requirements depends on the overall technical solution, the authentication factors applied, and the transaction authorisation mechanism.

The EUDI Wallet and attestations will also not replace sanctions and PEP screening, beneficial ownership determination, risk assessment or transaction monitoring.

Authologic supports CASPs in using data and electronic attestations from the EUDI Wallet in KYC and user authentication processes, including strong customer authentication, while the remaining AML obligations and, where applicable, payment service requirements continue to be met alongside them. The infrastructure vocabulary behind that - routing, fallback, method coverage - is defined in the Identity Orchestration Glossary.

FAQ

Does MiCA require strong customer authentication?

No. MiCA requires providers of custody and administration of crypto-assets to specify the client's authentication system in the agreement with the client, under Article 75(1)(d). It does not define authentication and does not set the standard the system must meet.

Is DORA's strong authentication the same as SCA under PSD2?

Not automatically. DORA, read together with RTS 1774, requires strong authentication mechanisms or methods as part of ICT system security, under Article 9(4)(d). The mechanisms may technically overlap with those used for SCA, but that overlap does not automatically imply compliance with PSD2, and the reverse must be assessed case by case.

When is a CASP subject to PSD2?

When its activity qualifies as a payment service, typically around EMT transfers and custody pay-outs. The EBA transition period for obtaining the required PSD2 authorisation ended on 2 March 2026.

Does exchanging crypto-assets count as a payment service?

According to the EBA's approach, as a rule no. The mere exchange of crypto-assets for funds or other crypto-assets should not be considered a payment service, and mere custody of EMTs without the ability to send or receive them from third parties does not necessarily constitute maintaining a payment account. The whole service model still has to be assessed individually.

Do CASPs need a second KYC process under payment rules?

Generally no. Bringing a CASP under payment regulations does not necessitate a separate KYC process, but it may add requirements on SCA, payment security, fraud monitoring and liability for unauthorised transactions.

Can a CASP rely on the EUDI Wallet for KYC?

From 10 July 2027, the Wallet, as an eIDAS electronic identification means at assurance level high, can be used as a recognised means of identity verification under Article 22(6)(b) AMLR. It does not by itself replace the obligation to obtain all customer identification information required under the AMLR, nor the rest of the due diligence set: screening, beneficial ownership, risk assessment and monitoring remain separate obligations.

Does presenting the EUDI Wallet satisfy SCA?

No. The mere presentation of Person Identification Data (PID) or an electronic attestation of attributes does not automatically constitute a compliant SCA process. Compliance depends on the overall technical solution, the authentication factors applied and the transaction authorisation mechanism.

Changelog

• 1 September 2026 - Initial publication.

This briefing sets out general information on the legal framework as it stood in September 2026 and reflects the authors' reading of that framework. It does not constitute legal advice. The regulatory treatment of any particular CASP or service model should be assessed separately by reference to the services actually provided and the applicable legal and supervisory framework.