Contact and frequently asked questions

On this page you will find information on how you can contact us and we have answered a number of frequently asked questions.

Contact

If you have any questions about our supervision of crypto products and services, please contact us at crypto@afm.nl.

You can also register for our newsletter with periodic crypto updates.

Frequently asked questions

General questions

Which regulator can you contact if you have any questions?

The AFM is the first point of contact for all matters related to CASP licensing and notifications (see Article 2, first paragraph, Decree on the Implementation of EU Financial Markets Regulations (BuEU) and Article 60 MiCAR and Article 63 MiCAR) and we will liaise with DNB where necessary, case-by-case. You can email us at crypto@afm.nl.

For questions on prudential requirements (see Article 67, Article 83 and Article 84 MiCAR) such as the capital requirements and the assessment of qualifying holdings, please contact DNB at crypto@dnb.nl and put crypto@afm.nl in CC.

How is the transitional period in Article 143-3 MiCAR implemented in The Netherlands and who can make use of this transitional period?

The applicable law for The Netherlands is based upon the Act implementing amendments to the Fourth Anti-Money Laundering Directive, which stipulates that crypto service providers (firms offering exchange of virtual currencies (crypto) for money and (vice versa)), and providers of custodian wallets for virtual currencies must request registration with De Nederlandsche Bank (DNB).

The Netherlands plans to limit the transitional period for those crypto-asset service providers (entities that are already registered by DNB) clause to 6 months. We support this. This entails that crypto-asset service providers that provided their services based on their DNB registration before 30 December 2024, may continue to do so until 30 June 2025. This follows from Article 143 paragraph 3 MiCAR: 'Crypto-asset service providers that provided their services in accordance with applicable law before 30 December 2024, may continue to do so until 1 July 2026 or until they are granted or refused an authorisation pursuant to Article 63, whichever is sooner.'

Please note that the transitional period does not apply for parties who do not have a DNB registration before 30 December 2024.

Therefore, the AFM and DNB advise enterprises that intend to provide crypto-asset services in the Netherlands to submit a license or notification request at the AFM, instead of applying for a registration at DNB. This approach is more efficient for all parties involved. If potential CASP’s submit a registration request at DNB after the middle of 2024, they risk having to pay costs with no guarantee of obtaining a registration in 2024 because of the lead time of the assessment. In that case the transitional period will also not apply.

Is there a light or alternative registration/licensing process for parties and if so, what conditions are attached to this? For example for parties that already have a DNB registration?

There is no simplified procedure conform Article 143 MiCAR in The Netherlands. For entities that are already registered in The Netherlands at DNB, under certain circumstances we can decide that a lighter MiCAR-assessment on specific components or topics could be performed in case elements have previously been assessed by DNB. For this purpose, we will receive the relevant information from DNB to minimise the need to re-assess similar information by us for a MiCAR license. This can for example be the case for the fit and proper testing of persons in charge of day-to-day operations and members of the supervisory board of CASP’s.

Please note that it is important that the license applicant indicates clearly in the fit and proper forms if the requested information or relevant information was provided to DNB in the past in the context of the application for registration under the Dutch Money Laundering and Terrorist Financing Prevention Act. Wecan then verify with DNB whether the information in question is indeed provided and assessed, in order to minimize the need for the same information to be reassessed by us as much as possible.

Will CASPs who also provide PSD2 payment services, in addition to their MiCAR license, also require a PSD2 license, when providing PSD2 payment services?

When a crypto-asset service provider (CASP) also provides PSD2 services, it must do so in accordance with PSD2 regulations. DNB is the primary supervisor of PSD2 and deals with PSD2 scope issues. Unless there is an exemption, a PSD2 license must be obtained from DNB.

An alternative option offered by Article 70 paragraph 4 MiCAR is to outsource the payment services to a third party that has a PSD2 authorisation. It requires a careful assessment of the services offered in order to be able to determine compliance with both the MiCAR regulation and any applicable payment service regulations.

Please also pay attention to recital 90 MiCAR: 'Some crypto-asset services, in particular providing custody and administration of crypto-assets on behalf of clients, the placing of crypto-assets, and transfer services for crypto-assets on behalf of clients, might overlap with payment services as defined in Directive (EU) 2015/2366.'

Do CASPs providing services in relation to crypto-asset derivatives need a MiFID II licence?

If a crypto-asset derivative qualifies as a financial instrument, it is likely that the CASP must have a MiFID II licence authorising the provision of services in relation to the derivative. The CASP must have a MiFID II licence if it provides an investment service or performs any investment activity.

A CASP with a MiFID II licence may, provided it has sent a notification, also provide equivalent crypto-asset services in accordance with Article 60 (3) of MiCAR. The following situations in any event involve the provision of an investment service for which it is necessary to have a MiFID II licence:

a. the reception and transmission of orders from clients in relation to financial instruments;
b. the execution of orders in relation to financial instruments on behalf of clients;
c. individual portfolio management; and
d. the provision of advice on financial instruments.

Do crypto-asset derivatives qualify as a financial instrument under MiFID II?

Derivative contracts and other derivatives of crypto assets may qualify as a financial instrument. The structure of the contract, whether as an option, future, swap, forward contract or any other type of contract, does not impact the qualification. The derivative contract may qualify as a financial instrument if this contract is settled:

• in cash;
• in asset-referenced tokens;
• in e-money tokens; or
• by physical delivery of the underlying asset.

The provision of investment services or performance of any investment activity in relation to financial instruments is only permitted with the necessary MiFID II licence. A CASP with a MiFID II licence may, provided it has sent a notification, also provide equivalent crypto-asset services in accordance with Article 60 (3) of MiCAR.

What is the approach of the AFM regarding substance and governance for CASPs applying for a license in The Netherlands?

Please note that this topic is currently being discussed at European level under coordination of the European Securities and Markets Authority (ESMA) to achieve further supervisory convergence by the National Competent Authorities (NCAs) such as the AFM. As a general principle, the AFM wants to avoid letterbox/empty entities as this hampers effective management of the activities of the CASP as well as effective supervision by the AFM. Until more specific requirements are available, the AFM adheres to the following ESMA-guidance.

ESMA issued on 31st of July 2024 an Opinion to support the convergent application of MiCA to address the risks presented by global crypto firms seeking authorisation under the Markets in Crypto Assets (MiCA) Regulation for part of their activities while keeping a substantial part of their group activities (intra-group execution venues) outside the European Union (EU) regulatory scope. ESMA recognizes risks associated with global crypto firms’ complex structures. The Opinion calls for a case-by-case assessment, outlining the specific requirements that should be met regarding substance, best execution, conflicts of interest, the obligation to act honestly, fairly, and professionally in the best interests of clients and the obligation relating to the custody and administration of crypto-assets on behalf of clients.

ESMA highlights that certain applications for authorisation as crypto-asset services providers anticipated under MiCA bear some similarities with some applications received by NCAs in the context of the United Kingdom (UK) decision (Brexit) to withdraw from the EU. Consequently, given the similar underlying issues and risks of supervisory arbitrage, the general principles developed by ESMA to support supervisory convergence in the context of the UK decision to withdraw from the EU should also be applied in the context of services and activities to which MiCA applies. ESMA advises therefore to the application of, mutatis mutandis, principles two to eight as laid down in her previous Brexit Opinion (Opinion on General principles to support supervisory convergence in the context of the United Kingdom withdrawing from the European Union, published in May 2017 (europa.eu) and also to be considered amongst the guiding principles for NCAs when assessing the authorisation of CASPs, along with the other elements in sections 4 to 8 of ESMA’s Opinion to support the convergent application of MiCA.

Asset segregation

What does the AFM expect from CASPs in the area of asset segregation?

Among other things, the AFM expects crypto-asset service providers (CASPs) to properly inform their clients on the ways in which the clients’ assets are segregated from the assets of the CASP. It should be clear to clients what rights they have, how crypto-assets and funds are held in custody and what happens to customers' crypto-assets and funds in case a CASP goes bankrupt.
Article 75 paragraph 7 MiCAR states that the clients’ crypto-assets should be held separately from the crypto-assets of the CASP. It is important that these assets are segregated both legally and operationally. This in any event means that the clients’ crypto-assets are held in custody via one or more separate wallets and the crypto-assets of the CASPs are held via one or more different wallets.
Customer deposits held in custody can also be held in so-called omnibus wallets. CASPs may not hold their own crypto-assets in an omnibus wallet that has customer deposits. It thus requires a comprehensive administrative system so as to always be able to track which crypto-assets belong to which client.

How must crypto-assets be legally segregated?

In terms of crypto-assets, there is no Dutch law based on which crypto-assets held in custody are segregated from CASPs’ assets, as there is for banks and investment firms under the Securities (Bank Giro Transactions) Act (Wet giraal effectenverkeer). To legally segregate clients’ assets from the crypto-assets of the CASP, CASPs often make use of a separate entity. Often, this is a foundation. This construction creates legal segregation. It is also done for other forms of financial services in the Netherlands.

Another option is to comply with the requirements of asset segregation under MiCAR under the law of another European Union Member State. Other Member States in the European Union allow for crypto-assets to be held in custody by CASPs without the need of a separate entity. If CASPs decide to make use of such arrangements, the AFM considers it important that the CASPs demonstrate that this construction is as a minimum equivalent to the protection clients have under Dutch law and that clients are clearly informed about the method of asset segregation and their rights in the event of loss of crypto-assets.

Under Dutch law, what is the practice of segregating crypto-assets and funds in a separate entity? (Third-Party Funds Foundation; stichting derdengelden)

The separate entity holds the crypto-assets and funds in custody on behalf of their clients. In this case, the clients have a claim against the separate entity, as a result of which the crypto-assets and funds do not form part of the CASP’s equity, not even if the CASP suffers bankruptcy. Thus, creditors of the CASP cannot claim any of the crypto-assets and funds of the clients of the CASP.
The AFM expects CASPs to be able to meet the legal and operational requirements of asset segregation imposed by MiCAR when incorporating a separate entity. In so doing, the AFM expects that such separate entities meet certain requirements. See question: What does the AFM expect from CASPs that incorporate a separate entity (Third-Party Funds Foundation) in order to meet MiCAR’s requirement of asset segregation?

What does the AFM expect from CASPs that incorporate a separate entity (Third-Party Funds Foundation) in order to meet MiCAR’s requirement of asset segregation?

The AFM expects CASPs to incorporate the separate entity with the aim of providing custody of the crypto-assets and funds of their clients and to keep these segregated from the CASP’s assets. The separate entity will be constructed so that only activities that contribute to this objective can be carried out. The agreements made between the separate entity and the CASP are recorded in a (custody) agreement. The AFM is of the opinion that if these and other requirements are being met, the entity serves as an extension of the CASP and a separate MiCAR licence may not be required. For the separate entity to qualify as an extension, it is important that all of the client’s crypto-assets and funds are segregated both legally and operationally and that the CASP bears ultimate responsibility and liability for custody and management.

Brought in detail, the AFM expects at least the following requirements to be met (not exhaustive):

The AFM expects the board of directors of the separate entity to be sufficiently reliable and to have the right knowledge and skills to carefully manage and hold clients’ crypto-assets and funds in accordance with MiCAR. These could be the executive directors of the CASP. Should this be the case, the AFM expects CASPs to take any potential conflicts of interest into consideration.
The AFM expects the entity to act solely in the interests of the clients for whom it provides custody of the crypto-assets and funds. In accordance with Article 75 paragraph 8 MiCAR, by having a separate entity as an extension, CASPs will be liable to their clients for the loss of any crypto-assets or of the means of access to the crypto-assets as a result of an incident that is attributable to them.
By having a separate entity as an extension of the CASP, the AFM expects CASPs to guarantee compliance with the obligations and any liability of the separate entity. The operational costs for the separate entity are borne by the CASP. In their business continuity plan, CASPs include the settlement procedure of the separate entity in case of the CASP’s bankruptcy. CASPs also ensure that the entity has sufficient capital to return the crypto-assets and funds to the clients.
The AFM expects for the separate entity to be included in the CASP’s risk and control procedures.

How must crypto-assets and funds be operationally segregated?

It is essential that the clients’ crypto-assets and funds are segregated from the CASP’s assets both legally and operationally. Below is a non-exhaustive list of requirements important to the AFM that must be complied with in order to refer to an operational segregation.

The AFM expects that the clients’ crypto-assets are held in custody via one or more separate wallets and that the crypto-assets of the CASPs are held via one or more different wallets.
The AFM expects CASPs to keep a register of positions, corresponding to each client’s rights to the crypto-assets at any given moment. This register of positions is frequently updated and at all times kept up to date. In accordance with Article 75 paragraph 4 MiCAR, any event likely to create or modify the rights of a client will immediately be recorded in the client’s register of positions.
In accordance with Article 75 paragraph 3 MiCAR, the AFM expects that establishing a custody policy will minimise the risk of loss of clients’ crypto-assets or the rights related to those crypto-assets or the means of access to the crypto-assets due to fraud, cyber threats or negligence.
The AFM expects that only the separate client asset segregation entity has control over (recovery of) the private keys of the wallets where client assets are held.

ICT Risk Management / DORA

What does the AFM expect from parties that apply for a MiCAR licence with regard to ICT Risk Management?

When it involves MiCAR licence applications, the AFM assesses different aspects in the area of ICT Risk Management. The AFM expects companies subject to its supervision to have implemented a strong and effective ICT Risk Management. To ensure this, the AFM requires companies to submit a number of documents. The documents which you need to submit are presented in the table below. Please note that this is a non-exhaustive list. Depending on the application or new insights, the AFM may request different or additional documents.

Subject	Mandatory documentation
Subject Subject Subject Subject Subject IT Risk Management/ IT Governance policies	Mandatory documentation Mandatory documentation Mandatory documentation Mandatory documentation Mandatory documentation ICT Risk management policy/incident management policy
Subject Subject Subject Subject Subject IT Risk Management/ IT Governance policies	Mandatory documentation Mandatory documentation Mandatory documentation Mandatory documentation Mandatory documentation Incident management plan
Subject Subject Subject Subject Subject IT Risk Management/ IT Governance policies	Mandatory documentation Mandatory documentation Mandatory documentation Mandatory documentation Mandatory documentation ICT asset management policy
Subject Subject Subject Subject Subject IT Risk Management/ IT Governance policies	Mandatory documentation Mandatory documentation Mandatory documentation Mandatory documentation Mandatory documentation ICT change management policy
Subject Subject Subject Subject Subject IT Risk Management/ IT Governance plans/procedures	Mandatory documentation Mandatory documentation Mandatory documentation Mandatory documentation Mandatory documentation ICT change management procedures
Subject Subject Subject Subject Subject IT Risk Management and IT Governance	Mandatory documentation Mandatory documentation Mandatory documentation Mandatory documentation Mandatory documentation IT landscape overview - technical description of IT infrastructure and ICT systems
Subject Subject Subject Subject Subject Information Security policies	Mandatory documentation Mandatory documentation Mandatory documentation Mandatory documentation Mandatory documentation Information security policy
Subject Subject Subject Subject Subject Information Security plans/procedures	Mandatory documentation Mandatory documentation Mandatory documentation Mandatory documentation Mandatory documentation Information security plan
Subject Subject Subject Subject Subject Information Security policies	Mandatory documentation Mandatory documentation Mandatory documentation Mandatory documentation Mandatory documentation Access control policy
Subject Subject Subject Subject Subject Information Security plans/procedures	Mandatory documentation Mandatory documentation Mandatory documentation Mandatory documentation Mandatory documentation Vulnerability and patch management procedures
Subject Subject Subject Subject Subject Information Security policies	Mandatory documentation Mandatory documentation Mandatory documentation Mandatory documentation Mandatory documentation Identity management policy
Subject Subject Subject Subject Subject Information Security plans/procedures	Mandatory documentation Mandatory documentation Mandatory documentation Mandatory documentation Mandatory documentation Identity management procedure
Subject Subject Subject Subject Subject Business Continuity and Disaster recovery Policy	Mandatory documentation Mandatory documentation Mandatory documentation Mandatory documentation Mandatory documentation Business continuity management and disaster recovery policy
Subject Subject Subject Subject Subject Business Continuity and Disaster recovery Policy	Mandatory documentation Mandatory documentation Mandatory documentation Mandatory documentation Mandatory documentation Backup and recovery policy
Subject Subject Subject Subject Subject Business Continuity and Disaster Recovery plans/procedures	Mandatory documentation Mandatory documentation Mandatory documentation Mandatory documentation Mandatory documentation Backup and recovery plan
Subject Subject Subject Subject Subject Business Continuity and Disaster Recovery plans/procedures	Mandatory documentation Mandatory documentation Mandatory documentation Mandatory documentation Mandatory documentation Business continuity management and disaster recovery plan
Subject Subject Subject Subject Subject Business Continuity and Disaster Recovery plans/procedures	Mandatory documentation Mandatory documentation Mandatory documentation Mandatory documentation Mandatory documentation Business impact-analysis and risk assessment
Subject Subject Subject Subject Subject Outsourcing policy	Mandatory documentation Mandatory documentation Mandatory documentation Mandatory documentation Mandatory documentation Outsourcing policy
Subject Subject Subject Subject Subject Outsourcing plans/procedures	Mandatory documentation Mandatory documentation Mandatory documentation Mandatory documentation Mandatory documentation Outsourcing arrangements - SLA's
Subject Subject Subject Subject Subject Outsourcing plans/procedures	Mandatory documentation Mandatory documentation Mandatory documentation Mandatory documentation Mandatory documentation Outsourcing register / Register of information
Subject Subject Subject Subject Subject Outsourcing plans/procedures	Mandatory documentation Mandatory documentation Mandatory documentation Mandatory documentation Mandatory documentation Exit strategies
Subject Subject Subject Subject Subject DORA compliance	Mandatory documentation Mandatory documentation Mandatory documentation Mandatory documentation Mandatory documentation Integral DORA roadmap

What does the AFM expect from parties that apply for a MiCAR licence before 17 January 2025 with regard to DORA-related ICT Risk Management?

• For different topics, MiCAR refers directly to DORA in terms of ICT Risk Management. The AFM expects parties that apply for a licence before 17 January 2025 to also comply with DORA with regard to these topics. Policies and procedures on these topics should be drafted and submitted as part of the licence application, including a comprehensive DORA roadmap showing that these are implemented before 17 January 2025.

• Even though your company need not yet comply with all other DORA requirements until 17 January 2025, it is important for both the AFM and your company to be DORA compliant in time. For this reason, we request you to enclose a comprehensive DORA roadmap with your licence application in which you provide insight into when your company will be taking steps to be DORA compliant on time. We expect this roadmap to clearly explain the time frame in which policies and procedures will be drawn up, finalised and implemented within the organisation, including any intermediate steps. These topics therefore do not require finalised policy lines and procedures at the time of the licence application.

• If the licence was applied for (briefly) before 17 January 2025, but will not be granted until after 17 January 2025, additional DORA-related (ICT) documents may have to be provided. Any additional documents may be expected during this transition period, which will be communicated by the AFM with the relevant party in due course.

• DORA also covers topics other than ICT Risk Management. Other DORA-related documents may be requested when deemed necessary.

What does the AFM expect from parties that apply for a MiCAR licence after 17 January 2025 with regard to DORA?

• The AFM expects all parties to be fully DORA compliant on time and no later than 17 January 2025. In addition to timely drafting policies and procedures, these policies and procedures must also be fully implemented within the organisation by 17 January 2025.

• Please keep in mind that DORA imposes more requirements on ICT Risk Management than included in the table above. Thus, after 17 January 2025, and in accordance with DORA, companies will have to submit more documents related to ICT Risk Management at the time of the licence application.

• DORA also covers topics other than ICT Risk Management. Other DORA-related documents may be requested when deemed necessary.

What does the AFM expect from parties in relation to Third-Party Risk Management under DORA?

We are getting signals from the market that market participants are already busy renegotiating agreements with third parties in order to be DORA compliant. The AFM stresses the parties' own responsibility to achieve compliance in a timely manner.