Contact en veelgestelde vragen
Op deze pagina vindt u informatie over hoe u het best met ons in contact kunt komen en hebben we antwoord gegeven op enkele veelgestelde vragen.
Contact
Heeft u vragen over ons toezicht op cryptoproducten en dienstverlening? Neem dan contact op via crypto@afm.nl.
U kunt zich ook inschrijven voor onze nieuwsbrief met periodieke crypto-updates.
Veelgestelde vragen
Moeten CASPs die ook PSD2-betaaldiensten verlenen, naast een MiCAR vergunning, ook een PSD2-vergunning hebben?
Wanneer een aanbieder van cryptoactivadiensten (CASP) ook PSD2-diensten levert, moet men dit conform de PSD2-regelgeving doen. DNB is de primaire toezichthouder op PSD2 en gaat over PSD2-reikwijdte vraagstukken. Tenzij er sprake is van een uitzondering of vrijstelling, moet er een PSD2-vergunning bij DNB aangevraagd worden.
Een alternatieve mogelijkheid die art. 70 lid 4 MiCAR biedt, is om het verlenen van de betaaldiensten uit te besteden aan een derde partij die een PSD2-vergunning heeft. Het vereist een zorgvuldige beoordeling van de aangeboden diensten om te kunnen vaststellen dat er zowel voldaan wordt aan de MiCAR-regulering, als eventuele toepasselijke betaaldienstregelgeving. Zie ook overweging 90 MiCAR: 'Sommige cryptoactivadiensten, met name het bewaren en beheren van cryptoactiva namens cliënten, het plaatsen van cryptoactiva en cryptoactivaoverdrachtdiensten namens cliënten, kunnen overlappen met betalingsdiensten zoals gedefinieerd in Richtlijn (EU) 2015/2366.'
Hoe wordt de overgangsperiode in artikel 143-3 MiCAR in Nederland geïmplementeerd en wie kan gebruik maken van deze overgangsperiode?
Het huidige toepasselijk recht voor Nederland is gebaseerd op de Implementatiewet wijziging vierde anti-witwasrichtlijn, die bepaalt dat aanbieders van cryptodiensten (aanbieders van wisseldiensten voor virtuele valuta (crypto) en geld (en vice versa)) en aanbieders van bewaarportemonnees voor virtuele valuta, een registratie bij De Nederlandsche Bank (DNB) moeten aanvragen.
Nederland is van plan de overgangsperiode voor cryptodienstverleners die een registratie bij DNB hebben te beperken tot 6 maanden. De AFM ondersteunt dit plan. Dit houdt in dat aanbieders van cryptoactivadiensten die hun diensten op basis van hun DNB-registratie vóór 30 december 2024 hebben verleend, dit tot en met 30 juni 2025 mogen blijven doen. In het geval dat een vergunningsaanvraag wordt toegewezen of afgewezen voor 30 juni 2025, komt de voornoemde overgangsperiode ten einde op de datum van de toewijzing dan wel afwijzing. Dit volgt uit art. 143 lid 3 MiCAR: 'Aanbieders van cryptoactivadiensten die vóór 30 december 2024 hun diensten overeenkomstig het toepasselijke recht aanboden, mogen dit blijven doen tot 1 juli 2026, of totdat hun overeenkomstig artikel 63 een vergunning is
verleend of geweigerd, naargelang wat zich het eerst voordoet.'
Let op: de overgangsperiode geldt niet voor partijen die vóór 30 december 2024 geen DNB-registratie hebben.
Om die reden roepen wij partijen die in Nederland cryptodiensten willen gaan aanbieden op om zich bij de AFM te melden voor een MiCAR-vergunningaanvraag, en niet langer bij DNB voor een registratie-aanvraag. Zo wordt dubbel werk, en de daarbij komende kosten, voor alle betrokkenen voorkomen. Mochten partijen na medio 2024 toch nog een registratie aanvragen bij DNB, dan lopen zij (gelet op de doorlooptijden) het risico kosten te maken zonder dat dit leidt tot een registratie in 2024. Zoals hiervoor aangegeven geldt dan ook het overgangsrecht niet.
Is er een light of alternatief registratie/vergunningproces voor partijen en zo ja welke voorwaarden hangen hier dan aan? Bijvoorbeeld voor partijen die nu al een DNB-registratie hebben.
Er is geen vereenvoudigde procedure conform artikel 143 MiCAR in Nederland. Voor entiteiten die al in Nederland zijn geregistreerd bij DNB kan de AFM in sommige gevallen beslissen dat er een lichtere MiCAR-beoordeling op specifieke onderdelen of onderwerpen kan plaatsvinden indien elementen al door DNB zijn beoordeeld. Dit kan bijvoorbeeld het geval zijn voor de geschiktheids- en betrouwbaarheidstoetsing van personen die verantwoordelijk zijn voor de dagelijkse gang van zaken en leden van de raad van commissarissen van CASP’s.
Let op: het is belangrijk dat de aanvrager van de vergunning in de geschiktheids- en betrouwbaarheidsformulieren duidelijk aangeeft dat de opgevraagde informatie in het verleden bij DNB is aangeleverd in het kader van de aanvraag van de registratie op grond van de Wet ter voorkoming van witwassen en financieren van terrorisme (Wwft). De AFM kan dan bij DNB verifiëren of de betreffende informatie inderdaad reeds is aangeleverd en beoordeeld, om de noodzaak om dezelfde informatie opnieuw te laten beoordelen door de AFM zo klein mogelijk te maken.
Bij welke toezichthouder kunt u terecht voor vragen?
De AFM is het eerste aanspreekpunt voor alle zaken die te maken hebben met CASP-vergunningen en notificerende partijen (zie artikel 2 eerste lid Besluit uitvoering EU-verordeningen financiële markten (BuEU) en artikel 60 en artikel 63 MiCAR). Wij zullen waar nodig per geval contact onderhouden met DNB. U kunt ons mailen op crypto@afm.nl.
Voor vragen over prudentiële vereisten (zie artikel 67, artikel 83 en artikel 84 MiCAR), zoals de kapitaalvereisten en de beoordeling van gekwalificeerde deelnemingen, kunt u contact opnemen met DNB via crypto@dnb.nl en crypto@afm.nl in de CC invullen.
Wat verwacht de AFM op het gebied van vermogensscheiding van CASPs?
- De AFM verwacht onder andere van CASPs dat zij hun klanten goed informeren over de manier waarop het vermogen van de klant gescheiden wordt van het vermogen van de CASP. Het moet voor klanten duidelijk zijn welke rechten zij hebben, hoe cryptoactiva en geldmiddelen worden bewaard en wat er met de cryptoactiva en geldmiddelen van de klanten gebeurt in geval van faillissement van de CASP.
- Voor cryptoactiva van klanten stelt art. 75 lid 7 MiCAR dat deze afgezonderd dienen te worden van de cryptoactiva van de CASP. Het is van belang dat deze scheiding zowel juridisch als operationeel gebeurt. Dit betekent in ieder geval dat cryptoactiva van klanten via een (of meer) aparte wallet(s) worden aangehouden en eigen cryptoactiva van de CASP via een (of meer) andere wallet(s) aangehouden worden.
- Voor het aanhouden van klanttegoeden kan gebruik worden gemaakt van zogenoemde omnibus-wallets. In een omnibus-wallet met klanttegoeden mag geen eigen cryptoactiva van de CASP worden bewaard. Een sluitende administratie is hierbij noodzakelijk om altijd te kunnen nagaan welke cryptoactiva aan welke klant toebehoren.
Hoe moeten cryptoactiva juridisch gescheiden worden?
- Naar Nederlands recht bestaat er voor cryptoactiva geen wet op grond waarvan cryptoactiva gescheiden worden van het vermogen van de CASP, zoals dat onder de Wet giraal effectenverkeer voor banken en beleggingsondernemingen wél is vastgelegd. Om cryptoactiva van klanten juridisch te scheiden van de cryptoactiva van de CASP maken CASPs vaak gebruik van een aparte entiteit. Vaak is dit een stichting. Door deze constructie wordt de juridische scheiding gerealiseerd. Dit wordt in Nederland ook gebruikt bij andere vormen van financiële dienstverlening.
- Er zijn ook mogelijkheden om naar het recht van een andere Europese Unie lidstaat aan de eisen voor vermogensscheiding onder MiCAR te voldoen. In andere Europese Unie lidstaten kunnen cryptoactiva door de CASP bewaard worden zonder dat daar een aparte entiteit voor nodig is. Als CASPs een dergelijke regeling gebruiken dan vindt de AFM het belangrijk dat de CASP aantoont dat het beschermingsniveau van deze constructie minimaal gelijk is aan de bescherming die een klant heeft onder Nederlands recht, en dat klanten duidelijk worden geïnformeerd over de wijze van vermogensscheiding en over hun rechten in geval van verlies van de cryptoactiva.
Hoe werkt het naar Nederlands recht afscheiden van cryptoactiva en geldmiddelen in een aparte entiteit (stichting derdengelden)?
- De aparte entiteit bewaart namens klanten de cryptoactiva en geldmiddelen. De klanten hebben in dit geval een aanspraak op de aparte entiteit, waardoor ook tijdens een faillissement van de CASP de cryptoactiva en geldmiddelen niet tot het vermogen van de CASP behoren en zodoende kunnen schuldeisers van de CASP geen aanspraak maken op de cryptoactiva en geldmiddelen van klanten.
- De AFM verwacht dat een CASP met het oprichten van een aparte entiteit kan voldoen aan de juridische en operationele vermogensscheidingseisen gesteld in MiCAR. Hierbij verwacht de AFM dat een apart opgerichte entiteit aan bepaalde vereisten voldoet, zie vraag: Wat verwacht de AFM van CASPs die een aparte entiteit (stichting derdengelden) oprichten voor vermogensscheiding onder MiCAR?
Wat verwacht de AFM van CASPs die een aparte entiteit (stichting derdengelden) oprichten voor vermogensscheiding onder MiCAR?
De AFM verwacht dat de CASP de aparte entiteit opricht met als doelstelling het bewaren van de cryptoactiva en geldmiddelen van de klanten van de CASP en deze gescheiden te houden van het vermogen van de CASP. De aparte entiteit wordt zodanig ingericht dat enkel activiteiten kunnen worden verricht die bijdragen aan deze doelstelling. De AFM is van mening dat wanneer aan deze en andere vereisten wordt voldaan de entiteit fungeert als verlengstuk van de CASP en mogelijkerwijs geen aparte MiCAR vergunning nodig heeft. Om de aparte entiteit als verlengstuk te kunnen kwalificeren is het van belang dat alle cryptoactiva en geldmiddelen van klanten zowel juridisch als operationeel worden gescheiden en de CASP de uiteindelijke verantwoordelijkheid en aansprakelijkheid draagt voor de bewaring en beheer.
In meer detail, de AFM verwacht dat op zijn minst aan de volgende vereisten is voldaan (niet limitatief):
- De AFM verwacht dat het bestuur van de aparte entiteit voldoende betrouwbaar is en beschikt over de juiste kennis en kunde om de cryptoactiva en geldmiddelen van klanten zorgvuldig en conform MiCAR te beheren en bewaren. Dit kunnen de bestuurders van de CASP zijn. In een dergelijk geval verwacht de AFM dat de CASP rekening houdt met eventuele belangenconflicten die hieruit voort kunnen vloeien.
- De AFM verwacht dat de entiteit uitsluitend optreedt in het belang van de klanten voor wie de cryptoactiva en geldmiddelen worden bewaard. Met de aparte entiteit als verlengstuk van de CASP is conform art. 75 lid 8 MiCAR uiteindelijk de CASP richting de klanten aansprakelijk voor het verlies van cryptoactiva of van de toegangsmiddelen tot de cryptoactiva als gevolg van een aan hen toerekenbaar incident.
- Met de aparte entiteit als verlengstuk van de CASP verwacht de AFM dat de nakoming van de verplichtingen en eventuele aansprakelijkheid van de aparte entiteit wordt gegarandeerd door de CASP. De CASP neemt in haar business continuïteitsplan op hoe de aparte entiteit in geval van faillissement van de CASP wordt afgewikkeld, en zorgt ervoor dat de entiteit over voldoende kapitaal beschikt om de cryptoactiva en geldmiddelen aan de klanten terug te kunnen geven.
- De AFM verwacht dat de aparte entiteit wordt betrokken in de risico en controleprocedures van de CASP.
Hoe moeten cryptoactiva en geldmiddelen operationeel gescheiden worden?
Het is van belang dat cryptoactiva en geldmiddelen van de klanten zowel juridisch als operationeel zijn gescheiden van de cryptoactiva en geldmiddelen van de CASP. Hieronder zijn een aantal voor de AFM belangrijke vereisten (niet limitatief) opgesomd waar voor de operationele scheiding aan moet worden voldaan:
- De AFM verwacht dat cryptoactiva van klanten via een (of meer) aparte wallet(s) worden aangehouden en eigen cryptoactiva van de CASP via een (of meer) andere wallet(s) aangehouden worden.
- De AFM verwacht dat de CASP een positieregister bijhoudt, waaruit op elk moment blijkt welke klant welke aanspraak heeft op de cryptoactiva. Dit positieregister wordt frequent geüpdatet en altijd actueel gehouden. Conform art. 75 lid 4 MiCAR worden alle gebeurtenissen die de rechten van een klant kunnen doen ontstaan of wijzigen, onmiddellijk vastgelegd in het positieregister van de klant.
- De AFM verwacht conform art. 75 lid 3 MiCAR dat door middel van het opstellen van een bewaringsbeleid de risico’s op verlies van cryptoactiva door (bijvoorbeeld) fraude, cyberdreigingen of nalatigheid tot een minimum worden beperkt.
- De AFM verwacht dat enkel de aparte entiteit voor het afscheiden van het vermogen van de klanten de controle heeft over (herstel van) de private keys van de wallets waar klanttegoeden zijn ondergebracht.
Wat verwacht de AFM van partijen die een MICAR-vergunning aanvragen ten aanzien van ICT-risicobeheer?
Subject | Mandatory documentation |
|---|---|
Subject Subject Subject Subject IT Risk Management/ IT Governance policies | Mandatory documentation Mandatory documentation Mandatory documentation Mandatory documentation ICT Risk management policy/incident management policy |
Subject Subject Subject Subject IT Risk Management/ IT Governance policies | Mandatory documentation Mandatory documentation Mandatory documentation Mandatory documentation Incident management plan |
Subject Subject Subject Subject IT Risk Management/ IT Governance policies | Mandatory documentation Mandatory documentation Mandatory documentation Mandatory documentation ICT asset management policy |
Subject Subject Subject Subject IT Risk Management/ IT Governance policies | Mandatory documentation Mandatory documentation Mandatory documentation Mandatory documentation ICT change management policy |
Subject Subject Subject Subject IT Risk Management/ IT Governance plans/procedures | Mandatory documentation Mandatory documentation Mandatory documentation Mandatory documentation ICT change management procedures |
Subject Subject Subject Subject IT Risk Management and IT Governance | Mandatory documentation Mandatory documentation Mandatory documentation Mandatory documentation IT landscape overview - technical description of IT infrastructure and ICT systems |
Subject Subject Subject Subject Information Security policies | Mandatory documentation Mandatory documentation Mandatory documentation Mandatory documentation Information security policy |
Subject Subject Subject Subject Information Security plans/procedures | Mandatory documentation Mandatory documentation Mandatory documentation Mandatory documentation Information security plan |
Subject Subject Subject Subject Information Security policies | Mandatory documentation Mandatory documentation Mandatory documentation Mandatory documentation Access control policy |
Subject Subject Subject Subject Information Security plans/procedures | Mandatory documentation Mandatory documentation Mandatory documentation Mandatory documentation Vulnerability and patch management procedures |
Subject Subject Subject Subject Information Security policies | Mandatory documentation Mandatory documentation Mandatory documentation Mandatory documentation Identity management policy |
Subject Subject Subject Subject Information Security plans/procedures | Mandatory documentation Mandatory documentation Mandatory documentation Mandatory documentation Identity management procedure |
Subject Subject Subject Subject Business Continuity and Disaster recovery Policy | Mandatory documentation Mandatory documentation Mandatory documentation Mandatory documentation Business continuity management and disaster recovery policy |
Subject Subject Subject Subject Business Continuity and Disaster recovery Policy | Mandatory documentation Mandatory documentation Mandatory documentation Mandatory documentation Backup and recovery policy |
Subject Subject Subject Subject Business Continuity and Disaster Recovery plans/procedures | Mandatory documentation Mandatory documentation Mandatory documentation Mandatory documentation Backup and recovery plan |
Subject Subject Subject Subject Business Continuity and Disaster Recovery plans/procedures | Mandatory documentation Mandatory documentation Mandatory documentation Mandatory documentation Business continuity management and disaster recovery plan |
Subject Subject Subject Subject Business Continuity and Disaster Recovery plans/procedures | Mandatory documentation Mandatory documentation Mandatory documentation Mandatory documentation Business impact-analysis and risk assessment |
Subject Subject Subject Subject Outsourcing policy | Mandatory documentation Mandatory documentation Mandatory documentation Mandatory documentation Outsourcing policy |
Subject Subject Subject Subject Outsourcing plans/procedures | Mandatory documentation Mandatory documentation Mandatory documentation Mandatory documentation Outsourcing arrangements - SLA's |
Subject Subject Subject Subject Outsourcing plans/procedures | Mandatory documentation Mandatory documentation Mandatory documentation Mandatory documentation Outsourcing register / Register of information |
Subject Subject Subject Subject Outsourcing plans/procedures | Mandatory documentation Mandatory documentation Mandatory documentation Mandatory documentation Exit strategies |
Subject Subject Subject Subject DORA compliance | Mandatory documentation Mandatory documentation Mandatory documentation Mandatory documentation Integral DORA roadmap |
Wat verwacht de AFM van partijen ten aanzien van DORA ICT-risicobeheer bij MiCAR-vergunningaanvragen voor 17 januari 2025?
• Op verschillende punten verwijst MiCAR ten aanzien van ICT-risicobeheer rechtstreeks naar DORA. De AFM verwacht van partijen die voor 17 januari 2025 een vergunningaanvraag indienen dat zij op deze punten tevens voldoen aan de DORA-vereisten. Beleid en procedures ten aanzien van deze onderwerpen dienen opgesteld te zijn en aangeleverd als onderdeel van de vergunningaanvraag, inclusief een integrale DORA roadmap waaruit blijkt dat deze geïmplementeerd zijn voor 17 januari 2025.
• Hoewel uw onderneming zich tot 17 januari 2025 nog niet aan alle andere DORA-vereisten hoeft te voldoen, is het voor de AFM en voor uw onderneming van belang om tijdig volledig DORA-compliant te zijn. Hierom vragen wij u een integrale DORA-roadmap toe te voegen aan uw vergunningsaanvraag waarin u inzichtelijk maakt welke stappen uw onderneming wanneer zet om tijdig DORA-compliant te zijn. Wij verwachten dat deze roadmap duidelijk inzichtelijk maakt wanneer beleid en procedures (definitief) opgesteld worden en wanneer deze geïmplementeerd zijn binnen de organisatie, inclusief eventuele tussenstappen. Voor deze onderwerpen zijn definitieve beleidslijnen en procedures tijdens de vergunningaanvraag dus niet nodig.
• Is de vergunning (kort) voor 17 januari 2025 aangevraagd, maar wordt deze pas na 17 januari 2025 verleend, dan is het mogelijk dat er meer DORA gerelateerde (IT) documenten aangeleverd dienen te worden. In deze overgangsperiode kunnen aanvullende documenten worden verwacht die te zijner tijd door de AFM met de desbetreffende partij wordt gecommuniceerd.
• DORA ziet ook op andere onderwerpen dan enkel ICT-risicobeheer. Het is mogelijk dat andere DORA documentatie opgevraagd wordt wanneer dit nodig wordt geacht.
Wat verwacht AFM van partijen in het kader van ICT-risicobeheer ten aanzien van DORA na 17 januari 2025?
• De AFM verwacht van partijen dat zij tijdig (en uiterlijk 17 januari 2025) volledig DORA-compliant zijn. Naast het tijdig opstellen van beleid en procedures dienen deze ook op 17 januari 2025 volledig geïmplementeerd te zijn binnen de organisatie.
• Houd er rekening mee dat DORA meer eisen stelt aan ICT-risicobeheer dan in de tabel hierboven is opgenomen. Na 17 januari 2025 zullen er dus meer, conform DORA, ICT-risicobeheer documenten aangeleverd dienen te worden tijdens de vergunningaanvraag.
• DORA ziet ook op andere onderwerpen dan enkel ICT-risicobeheer. Het is mogelijk dat andere DORA documentatie opgevraagd wordt wanneer dit nodig wordt geacht.
Wat verwacht de AFM van partijen in het kader van beheer van ICT-risico van derde aanbieders onder DORA?
Uit de markt ontvangen wij signalen dat marktpartijen reeds druk bezig zijn met overeenkomsten opnieuw met derde partijen uit te onderhandelen om DORA-compliant te zijn. De AFM wijst hierbij op de eigen verantwoordelijkheid van partijen om hieraan tijdig te voldoen.