Greenlighting Crypto in DIFC – The DFSA Authorisation Playbook

The Dubai International Financial Centre (DIFC) lets serious crypto businesses operate inside a securities-grade framework. To get through the door, however, you don’t start with token whitepapers – you start with the DFSA authorisation file. The backbone of that file is the DFSA’s Applying for Authorisation Notes (AFN), which set the mechanics for every licence application (crypto or not) and point you to the live Rulebook for the crypto-specific overlays.

Below is your practical, clause-linked playbook for assembling a crypto-ready application – what to file, how to evidence it, and where the crypto-specific gates sit in GEN 7.2 (who can be authorised for crypto services) and GEN 3A (recognition of Crypto Tokens).

1) Scope: what the AFN does – and what it doesn’t

The AFN explains which forms and supplements you must submit and the quality of evidence the DFSA expects: sufficient financial resources, appropriate personnel, and adequate systems/controls. The DFSA may request additional information and you use SUP 4 for later variations.

Think of AFN as the procedural chassis; the crypto-specific chassis is in GEN:

• GEN 7.2 (Authorisation): who may be authorised and the extra conditions for Financial Services relating to Crypto Tokens.
• GEN 3A (Recognised Crypto Tokens): how tokens become recognised (and when they can be refused or revoked).

2) Forms you’ll actually file (and who typically files them)

Almost every crypto applicant will file:

• AUT-CORE (Core Information) – mandatory if you are applying for any Financial Service(s).
• Sales & Trading Supplement – for brokers, exchanges/OTC, advisers, custodians: Dealing (Principal/Agent), Advising, Arranging Deals/Custody, Providing Custody, Advising/Arranging on Credit.
• Asset Management Supplement – where you Manage Assets (e.g., a manager investing into crypto exposures).

Some Financial Services require only AUT-CORE and the Regulatory Business Plan, but most crypto models map to Sales & Trading (and sometimes Asset Management as well).

3) GEN overlay: who can be authorised for crypto Financial Services?

AFN doesn’t decide who can do crypto; GEN 7.2 does. If your application relates to a Financial Service “relating to a Crypto Token”, you must be a DIFC body corporate, unless strict branch conditions are met (legacy authorised firm, not covering ATS/Clearing House/Custody/Principal Market Making; head office appropriately licensed and supervised in a Recognised Jurisdiction; capital for on-balance-sheet crypto, cyber insurance, and PII where advising).

Takeaway: If you are planning a branch as your crypto vehicle, check those GEN 7.2 carve-outs early – many crypto models will not fit and should be incorporated locally.

4) The Core Information form: governance, people, prudentials

The AUT-CORE is where you show the DFSA that your platform is real, resourced, and controllable.

4.1 General particulars

Declare your legal form (DIFC entity vs Branch), controllers, client classification approach, use of IT for trading, premises, and auditor (DFSA-registered for domestic firms).

4.2 Approved Individuals & governance

File AUT-IND1 for each Licensed Function (SEO, CO, Finance Officer, MLRO, etc.). The DFSA discourages the same individual from simultaneously holding business leadership and control roles (e.g., SEO + CO).

4.3 Prudential category and three-year projections

Provide quarterly financial projections for the first three years – balance sheet, P&L, cash flow – with a reconciliation of Capital Resources vs Capital Requirement by quarter, mapped to the PIB module. Accounting standards follow GEN 8.2 (IFRS/AAOIFI) unless a waiver applies.

Crypto lens: Model the cost of custody infrastructure, surveillance, on-chain analytics, and insurance into your projections – these are non-negotiables for a credible crypto programme.

5) The “compulsories”: documents that make or break a crypto file

5.1 Compliance Manual (CF32) – treat it as your operating system

The DFSA calls the Compliance Manual critical. It must set out oversight/reporting lines, client classification and marketing controls, segregation of Client Assets, breach escalation/notifications, outsourcing, complaints handling, conflicts, PA dealing, and training & competence.

Crypto specifics to embed under those headings:

• Wallet architecture (hot/warm/cold), key ceremonies, dual-control, and break-glass protocols.
• Reconciliation logic (on-chain vs books & records) and exception handling.
• Listings/token-admission filters tied to Recognised Crypto Tokens.
• Incident response for chain forks, reorgs, and airdrops.

5.2 Retail Endorsement – if you want retail, you must ask for it

The DFSA will grant a Retail Endorsement only if you can demonstrate compliant retail processes: client disclosures, suitability, fees/commissions, and segregation of Client Money/Investments; staff competence and complaints handling under GEN Ch. 9.

5.3 AML (CF33) – federal law + DFSA AML module

Evidence compliance with UAE federal AML law and UN sanctions, CDD/KYC (including UBOs), internal reporting to MLRO, STR filings to AMLSCU (copy to DFSA), annual AML review, record-keeping, PEP risk, and training. Map your on-chain analytics to EDD triggers and sanctions screening.

5.4 Compliance Monitoring (CF34) & Risk Policy (CF35)

Describe how compliance is monitored in business units, and set out risk identification, mitigation, and reporting – including crypto-specific operational, cyber, market-abuse, and concentration risks.

6) Your Regulatory Business Plan (RBP): tell the story like a regulated firm

The AFN expects a proportionate RBP (aim for ≤50 pages unless complexity justifies more) explaining strategy, governance, resources, controls, and financials.

For a crypto applicant, make sure the RBP clearly shows:

• Business model → permissions map (Dealing/Arranging, Providing/Arranging Custody, Operating an MTF/ATS, Managing Assets).
• Token universe and recognition status.
• Client-asset controls: wallet segregation, legal title vs control, and reconciliations.
• Market integrity: surveillance for spoofing/layering/wash trades; incident reporting.
• Operational resilience: BCDR for custody and trading; third-party wallet providers/outsourcing oversight.
• Retail vs Professional client pathways and gating.

Those themes reflect exactly what the AFN expects at a high level: how the business will be managed and controlled.

7) Tokens, tokens, tokens: the recognition gate (GEN 3A)

The AFN governs your licence; GEN 3A governs which tokens you can touch in regulated business.

• The DFSA may publish an Initial List of recognised tokens without application; beyond that, tokens are recognised on application, and the DFSA may refuse or revoke recognition (with publication) for reasons such as security incidents, AML concerns, or inadequacy of reserves (for fiat-referenced tokens).

Practical effect: Your file should include a token-admission policy that: (i) limits business to Recognised Crypto Tokens (plus any narrow custody carve-outs), (ii) sets fork/airdrop playbooks, and (iii) prevents “pre-marketing” of unrecognised tokens.

8) Presentation, language, fees, and etiquette

The AFN is strict about how you answer: respond fully, in English (or supply certified translations), avoid undefined acronyms, and read GEN Ch. 7 before completing forms. Provide the specified soft/hard copies and expect questions from DFSA during assessment. Fees follow the FER (Fees Module).

9) Build like this: a crypto-ready dossier in seven steps

1. Choose the right entity: If you’re doing crypto Financial Services, assume local incorporation unless you cleanly meet GEN 7.2 branch carve-outs. State your position explicitly in AUT-CORE.
   
2. Map your permissions: Align your business lines to Sales & Trading and/or Asset Management supplements; keep a register of activities you won’t perform (e.g., no principal market making if you’re a branch).
   
3. Hard-wire token recognition controls: In the Compliance Manual, ban onboarding/listing of unrecognised tokens except where the custody carve-out applies; add fork/airdrop SOPs. Cross-reference your token-admission policy in the RBP.
   
4. Engineer client-asset segregation: Describe wallet segregation, key management, reconciliations, and incident response in CF32; connect those controls to financial projections (CAPEX/OPEX) and insurance.
   
5. Retail? Earn it. If seeking Retail, submit a fully-formed Retail Endorsement case: suitability, disclosures, fees/inducements, complaint handling, and staff competence.
   
6. AML that actually uses your data. Tie on-chain analytics to CDD/EDD, sanctions, and STR decisioning; evidence MLRO oversight, annual AML review, training, and record-keeping as flagged in CF33.
   
7. Make the RBP read like operations, not aspiration. Use the AFN headings but write it like a runbook: who does what, with which systems, and what happens when it breaks. That’s what the DFSA will supervise the day after authorisation.

10) Five pitfalls that slow crypto applications (and how to sidestep them)

• Treating AFN as a template exercise. The AFN is not box-ticking; it’s where you prove resourcing, controls, and prudential fitness. Thin CF32/CF33s are the fastest way to generate DFSA questions.
  
• Assuming a branch will suffice. GEN 7.2 narrows branch options for crypto. If you’re anywhere near ATS, custody, or principal dealing, plan to incorporate.
  
• Forgetting the token gate. Your business can be perfect, but if your tokens aren’t recognised, you can’t use them in regulated business (save for narrow custody exceptions). Anchor a token-admission policy in your controls.
  
• Under-budgeting controls. Surveillance, reconciliations, analytics, and insurance belong in CF30 projections – show you’ve funded them.
  
• Retail ambitions without retail systems. If you want Retail, prove Retail – suitability, disclosures, complaints, and staff competence – or don’t ask yet.

11) Where AFN and GEN meet in your file

Two cross-references you should cite explicitly in covering letters and the RBP:

• AFN → GEN 7.2 (Authorisation): confirms you’ve read GEN 7.2 and, if applicable, why you satisfy the crypto-services entity conditions (body corporate vs branch tests).
  
• AFN → GEN 3A (Recognised Tokens): confirms your token-admission policy and how you will operate if a token’s recognition is refused/revoked (communications, delisting, and custody wind-down).

Authorisation in the DIFC is less about slides and more about systems. The AFN tells you how to file – the forms, the evidence packs, the shape of your RBP. GEN tells you who can do crypto Financial Services and which tokens qualify for regulated use. Put them together and you’ll submit a file that reads like a business you can actually run under DFSA supervision – because that’s exactly what you’re asking to do.

Disclaimer:

This is not legal advice. Application outcomes depend on your specific facts and the DFSA’s current Rulebook, forms, and guidance.

FAQ: DFSA Crypto Authorisation in DIFC