Virtual assets and crypto in ADGM

This is the single most useful thing on the page, and a great deal of published material still gets it wrong.

Early virtual asset regimes created a bespoke category — a licence to "operate a crypto asset business" — treating the technology as the regulated thing. ADGM moved away from that. The applicable rules now sit in the respective underlying Regulated Activities[ADGM — Digital Assets].

The logic is sound. Holding someone else's Bitcoin is custody, and the risks are custody risks. Running an order book is operating a multilateral trading facility, and the risks are market-infrastructure risks. Regulating by activity rather than by asset class makes the rules match the risk.

So the first question is not "how do I get a crypto licence" but "which regulated activities am I carrying on?" — and the answer is frequently more than one. An exchange that also holds client assets is doing at least two, and pays for both.

Your permission is fenced to virtual assets

A firm approved to conduct a regulated activity in relation to virtual assets is granted a Financial Services Permission for that activity, and its activities are limited to virtual assets unless the FSRA has otherwise authorised it[FSRA — Virtual Asset Guidance].

The guidance gives the example directly: someone wishing to operate as a broker, dealer or custodian in the conventional space must apply for and receive the FSRA approvals applicable to conventional investments as well[FSRA — Virtual Asset Guidance]. Two sets of approvals, and two sets of fees.

This catches firms planning to bridge tokenised and traditional assets. The virtual asset permission does not carry across, and discovering that after authorisation means a second application.

Two structural points worth knowing early

• Fiat-referenced tokens are money services. Tokens whose value is fully backed by fiat are licensed and regulated as Providing Money Services[FSRA — Virtual Asset Guidance] — a different permission from the virtual asset framework, with its own rules.
• An MTF that wants to become a Recognised Investment Exchange must relinquish its FSP in order to obtain a Recognition Order with a stipulation allowing it to operate an MTF[FSRA — Virtual Asset Guidance]. That is a structural decision, not an upgrade path, and it belongs in the plan from the start.

If a provider offers you an "ADGM crypto licence" as an off-the-shelf product, they are describing a framework that no longer exists in that form.

COBS Rule 17.2.1 permits an Authorised Person to conduct a regulated activity in relation to Accepted Virtual Assets only[FSRA — Virtual Asset Guidance]. The FSRA holds a general power to determine which assets qualify, expressly in order to prevent higher-risk activity in illiquid or, in its word, immature virtual assets.

The point almost everyone gets wrong

An asset that meets the requirements is an Accepted Virtual Asset for that individual Authorised Person only — and the FSRA does not maintain a public list of Accepted Virtual Assets[FSRA — Virtual Asset Guidance].

So there is nothing to look up. You cannot check whether a token is "approved in ADGM", because approval is not a property of the token. It is a property of the pairing between that token and your firm's controls. The same asset can be accepted for one firm and refused to another whose monitoring of that particular ledger is not yet good enough — the guidance gives exactly that example, of an MTF told to delay trading until suitable controls exist[FSRA — Virtual Asset Guidance].

The seven factors

COBS Rule 17.2.2 sets out the factors the FSRA will consider. Factor (a) sits in 17.2.2(a); (b) to (g) in 17.2.2(b)[FSRA — Virtual Asset Guidance]:

1. Maturity — the sufficiency, depth and breadth of client demand, the proportion of the asset in free float, and the controls and processes to manage its volatility.
2. Security — whether the asset can withstand, adapt to, respond to and improve on its specific risks and vulnerabilities, including size, testing, maturity, and the ability to allow appropriate safeguarding of secure private keys.
3. Traceability and monitoring — whether you can demonstrate the origin and destination of the asset, whether it enables identification of counterparties to each transaction, and whether on-chain transactions can be adequately monitored.
4. Exchange connectivity — whether other exchanges support the asset, in which jurisdictions, and whether those exchanges are suitably regulated.
5. Type of distributed ledger — security or usability issues with the DLT, whether the asset leverages an existing DLT for network synergies, and whether a new DLT has been demonstrably stress tested.
6. Innovation and efficiency — whether the asset helps solve a fundamental problem, addresses an unmet market need, or creates value for network participants.
7. Practical application and functionality — whether it possesses real world, quantifiable functionality.

Read factors 1, 6 and 7 together and the shape of the policy is obvious: a token with no float, no use and no users will not be accepted however well engineered it is. This is not a technical review. It is a judgement about whether the asset should be intermediated to clients at all.

What this means operationally

• You apply per asset, with evidence. An applicant must submit details of each proposed Accepted Virtual Asset, setting out separately for each one how it meets the tests[FSRA — Virtual Asset Guidance].
• Security needs third-party verification. The guidance requires Authorised Persons to undertake third party verification to demonstrate that proposed assets meet the security requirements[FSRA — Virtual Asset Guidance].
• Adding an asset later requires prior written approval. An Authorised Person wishing to use an asset beyond those approved at application must first seek the FSRA's approval before offering it to clients[FSRA — Virtual Asset Guidance]. An MTF must additionally notify the FSRA of any new asset proposed for admission to trading, under COBS Rule 17.7.4.

Plan your listings roadmap around that. In most jurisdictions adding a token is a product decision; here it is a regulatory application, and treating it as a sprint item is how firms end up offering something they were not permitted to offer.

This is the requirement that decides whether a business is viable here, and it is unusual enough to be worth stating precisely.

COBS Rule 17.3 requires an Authorised Person to hold regulatory capital consistently with MIR Rule 3.2.1 — the standard a Recognised Investment Exchange must meet[FSRA — Virtual Asset Guidance]. In general:

• Operating an MTF using virtual assets — 12 months' operational expenses
• All other virtual asset regulated activities — 6 months' operational expenses[FSRA — Virtual Asset Guidance]

Note what that is not. It is not a fixed base capital figure you can look up and plan against — it scales with your own cost base. A firm with a large engineering team and expensive infrastructure needs proportionately more capital than a lean one, which inverts the usual intuition that scale makes regulation easier to carry.

What counts as operational expenses

Per MIR Rule 3.2.1, broadly all overhead and non-discretionary costs incurred or forecast over a twelve-month period, with variable and exceptional items excluded[FSRA — Virtual Asset Guidance].

Technology costs are expressly included — IT servers and technology platforms, storage and use of IT equipment, and the technology services required for the overall operability of the platform. Development costs can be excluded, such as research and intellectual property patenting.

For a virtual asset business that distinction matters more than it first appears, because infrastructure is usually the largest line. Running your own nodes and matching engine is opex and therefore capitalised against; building a new protocol is development and is not.

It must be held in fiat

Regulatory capital must be in fiat form[FSRA — Virtual Asset Guidance].

A firm cannot capitalise itself in the assets it deals in. That is an obvious rule once stated and a genuinely expensive surprise for a treasury denominated in tokens — the capital has to be real money, sitting there, uncorrelated with the market you operate in. Which is, of course, precisely the point.

And the FSRA can require more

The FSRA applies proportionality in deciding whether an additional capital buffer must be held, based on the size, scope, complexity and nature of the firm's activities. An Authorised Person the FSRA considers high risk may attract higher capital requirements[FSRA — Virtual Asset Guidance].

So the six- and twelve-month figures are a floor and a starting point for a conversation, not a ceiling. Anyone modelling this should carry a contingency above the calculated number.

These are published, and almost never quoted. From the FSRA's virtual asset guidance[FSRA — Virtual Asset Guidance]:

The application fee is payable at the time of submission[FSRA — Virtual Asset Guidance] — before any decision, and it does not come back if the answer is no.

Note that the non-custody intermediary fee is charged irrespective of how many non-custody activities you propose to undertake[FSRA — Virtual Asset Guidance]. Adding dealing to advising costs nothing extra at this line. Adding custody doubles it.

The real number

Add the Registration Authority's Category A charge of USD 17,000 to register and USD 16,500 a year[ADGM RA — Schedule of Fees], and a straightforward non-custody virtual asset firm is looking at roughly USD 37,000 of government and regulator fees to apply, and USD 31,500 a year thereafter — before capital, before people, before premises.

An MTF with custody is USD 162,000 to apply and USD 91,500 a year. Those are the fees alone.

If a provider has quoted you a figure near the RA's USD 17,000 for a "crypto licence", they have quoted the company registration and left the regulator out.

ADGM's regulatory framework caters to business activities and product offerings in relation to Virtual Assets, Fiat-Referenced Tokens, Digital Securities, and Derivatives and Funds of digital assets[ADGM — Digital Assets].

The distinctions matter, because they route you to different rules:

• Virtual Assets — the Accepted Virtual Asset regime above.
• Fiat-Referenced Tokens — stablecoins, with their own framework.
• Digital Securities — tokenised instruments that are securities. If your token is a security, securities rules apply and the "crypto" framing is a distraction.
• Derivatives and Funds of digital assets.

Establishing which of these your product is should precede everything else, including choosing a structure.

We would rather tell you this than have you discover it after committing.

ADGM was an early mover on virtual assets, and the incumbents are real. The FSRA has supervised this space for years, the framework has been through multiple iterations, and the firms already authorised are substantial. This is not an emerging niche a well-prepared newcomer walks into.

The FSRA's own risk table sets out what it expects across five areas[FSRA — Virtual Asset Guidance], and reading it as a build list is more useful than reading it as regulation:

• AML/CFT and tax — the AML Rulebook applies in full, plus FATCA and Common Reporting Standard obligations.
• Consumer protection — all material risks of virtual assets generally, of your Accepted Virtual Assets, and of your own products must be disclosed, monitored and kept updated.
• Technology governance — systems and controls over wallets, private keys, the origin and destination of funds, security, and risk management and systems recovery.
• Exchange-type activities — for an MTF: market surveillance, fair and orderly trading, settlement, transaction recording, a rulebook, transparency and public disclosure mechanisms.
• Custody — Safe Custody and Client Money provisions under FSMR and COBS, frequent reconciliations and reporting, and internal controls to safeguard both assets and client fiat.

Note also COBS Rule 17.1.3, which reads Client Investments in GEN and Financial Instruments in the Code of Market Conduct as including virtual assets[FSRA — Virtual Asset Guidance]. The effect is that large parts of the conventional rulebook — market abuse, client classification, disclosure — apply to you as though you were dealing in securities. Firms that budget for a bespoke crypto regime and find the mainstream one underneath it are the ones that run over.

Realistically: a genuine compliance function rather than a policy pack, capital equal to six or twelve months of your cost base, systems the FSRA expects to see operating, and a timeline measured in months rather than the days ADGM quotes for company registration.

Authorisation and structure are different exercises, and it helps to keep them apart.

Most authorised firms are a private company limited by shares. For a protocol or foundation-style project, ADGM's DLT Foundation is a legal structure with its own personality tailored for blockchain foundations, DAOs and Web3 entities[ADGM RA — Schedule of Fees] — at USD 15,000 to register.

Registering a DLT Foundation does not authorise you to do anything regulated. If the project issues, trades, custodies or intermediates digital assets, the FSRA question stands regardless of the wrapper — and Category A applicants apply to the FSRA before the Registration Authority will consider incorporation[ADGM RA — Schedule of Fees].

Everything on this page is taken from the FSRA's own Guidance on the Regulation of Virtual Asset Activities in ADGM[FSRA — Virtual Asset Guidance], read directly rather than summarised from elsewhere. The operative rules sit in COBS Chapter 17, MIR, GEN, the AML Rulebook and the Code of Market Conduct, all published in ADGM's legislation portal[ADGM Legislation].

One caveat, stated plainly. The version of the guidance used here is VER05, dated 18 December 2023, and the FSRA has amended this framework repeatedly since it was introduced — including changes to how assets are accepted and to capital and fees for firms conducting these activities[ADGM — Digital Assets]. A later version may exist.

So treat the figures here as accurate to that version and worth re-checking against the current rulebook before you commit capital. That is true of any page on this subject; the difference is that this one tells you which version it read.

And engage the FSRA early. ADGM's own instruction to financial services applicants is to contact the regulator to start the process and arrange a meeting[FSRA], and on this framework in particular the pre-application conversation is where the scope of your permission actually gets settled.