Types of Crypto Licenses: Exchange, Custody, Broker, Payment and More

*By Magnus Müller · Reviewed by Magnus Müller · Last updated: 2026-06-14*

Founders searching for "types of crypto license" usually expect a short menu of products. The regulatory reality is different, and getting it right early saves months of misdirected effort. There is no single global crypto license. Every modern regime licenses by activity, and the categories the market calls "license types" are really regulated activities authorised one by one. This guide maps the six core types, exchange, custody, broker, payment, advisory and portfolio management, onto the framework definitions that actually govern them: MiCA in the EU, FATF as the global AML baseline, VARA in Dubai, and MAS in Singapore.

There is no single "crypto license." A crypto license is permission to perform a specific regulated activity, not one universal permit. MiCA defines ten distinct crypto-asset services (Art. 3(1)(16)); FATF defines five VASP activities; VARA seven; MAS seven payment services. A firm is authorised per activity, then layers AML on top.

Is there a single "crypto license"? (the per-activity model)

No. Every modern framework treats crypto regulation as a list of activities, and a firm is authorised for the specific activities it carries out. Under MiCA, a crypto-asset service provider (CASP) is "a legal person" authorised for one or more of ten crypto-asset services (MiCA Art. 3(1)(15) and 3(1)(16)). The same per-activity logic runs through the FATF VASP definition (five activities), through VARA's licensed activities (seven), and through the MAS Payment Services Act (seven payment services). The practical takeaway: you do not "buy a crypto license," you obtain authorisation for the regulated activities your business model performs, which is why the same firm can hold several at once. Our complete crypto licensing guide sets out the wider picture across jurisdictions.

"License type" vs "regulated activity" - the vocabulary bridge

The phrase "license type" is colloquial. Regulators speak of "regulated activities" or "authorised services." These two vocabularies describe the same thing, and the whole page rests on the bridge between them. When the market says "crypto exchange license," the regulator reads "operation of a trading platform" plus "exchange of crypto-assets for funds or for other crypto-assets." When the market says "crypto custody license," the regulator reads "custody and administration of crypto-assets on behalf of clients." Throughout this guide we use both terms deliberately: the market label first, then the cited regulated activity it maps to. Reading the page this way avoids the common error of assuming one license covers everything a business does. If your business performs more than one activity, you need authorisation for each, although most regimes grant them in a single authorisation.

The four anchor frameworks at a glance

Four frameworks anchor the mapping in this guide, each with a different role. MiCA (Regulation (EU) 2023/1114) is the EU's harmonised CASP regime, defining ten crypto-asset services (Source 1). FATF is the global AML baseline: its Recommendation 15 sets out five VASP activities that every jurisdiction layers under its own licensing rules (Source 2). VARA is Dubai's dedicated virtual-assets regulator, with seven licensed activities (Source 3). MAS is Singapore's central bank and regulator, whose Payment Services Act 2019 lists seven payment services including the digital payment token (DPT) service (Source 4). Read together they cover the EU, the global AML floor, the Middle East and Asia, which is why this taxonomy works for a multi-jurisdiction audience rather than one country.

The six core crypto license types at a glance

Reduced to their essentials, the activities defined across MiCA, FATF, VARA and MAS group into six core "license types" plus one important edge case (token issuance, which sits outside the service regime). The six core types are:

• Exchange: running a trading venue and/or buying and selling crypto against fiat or other crypto.
• Custody: safekeeping crypto, or the means of access (private keys), on behalf of clients.
• Broker / dealer: executing, placing, or receiving and transmitting client orders.
• Payment / transfer: moving crypto for clients, plus fiat-to-crypto payment, e-money and remittance rails.
• Advisory: giving personalised recommendations on crypto-asset transactions.
• Portfolio / asset management: managing client crypto portfolios on a discretionary mandate.

Each is defined below with its framework citations. The seventh activity, issuing or offering tokens (an ICO), is regulated separately and is not a crypto-asset service under MiCA, as the dedicated section explains. For a deeper treatment of how each activity maps to a viable business model, see licensing by activity and business model.

Quick comparison: what each type lets you do

The full cross-framework table, mapping each type to FATF, VARA and MAS as well as MiCA, appears further down as the centrepiece of this guide.

Crypto exchange license: trading platforms and exchange services

The crypto exchange license is the one founders ask about most, and it actually covers up to three distinct MiCA services. Under MiCA it spans "operation of a trading platform for crypto-assets" (Art. 3(1)(18)), "exchange of crypto-assets for funds" (Art. 3(1)(19)), and "exchange of crypto-assets for other crypto-assets" (Art. 3(1)(20)). In FATF terms it combines VASP activity (i), exchange between virtual assets and fiat, with activity (ii), exchange between forms of virtual asset (Source 2). VARA classifies it as "Exchange Services" (Source 3), and in Singapore an exchange falls under the MAS "DPT service" (Source 4). Operating a trading platform carries the highest prudential requirements among MiCA activities, although the exact figures live on the requirements page. For the full operational picture, see our exchange license in depth.

What it covers (operation vs dealing on own account)

There is a critical distinction inside the exchange category. Operating a trading platform (Art. 3(1)(18)) means running "one or more multilateral systems" that bring together multiple third-party buying and selling interests in crypto-assets, in effect, running a venue where others trade. Dealing on own account (Art. 3(1)(19) and (20)) is different: it means concluding purchase or sale contracts for crypto-assets against funds or other crypto-assets "by using proprietary capital," that is, buying and selling against your own balance sheet. A pure order-matching exchange needs the trading-platform authorisation; an OTC desk or brokerage that fills client trades from its own inventory needs the dealing services. Many businesses do both and therefore need all three. Confirm which combination applies before you scope your capital requirements.

Who needs an exchange license

You need an exchange authorisation if you operate an order book or matching engine for third parties, run a spot or instant-buy venue, or buy and sell crypto against your own capital as principal. This includes centralised exchanges, instant-conversion services, and brokerages that internalise flow. If you only route client orders to a third-party venue without taking the other side, you are likely a broker rather than an exchange. The boundary matters because the trading-platform service sits at the top of the MiCA prudential scale, so misclassifying an exchange as a lighter service is a common and costly mistake.

Crypto custody license: safekeeping and control of client assets

A crypto custody license authorises you to hold client crypto, or the keys that control it, on their behalf. Under MiCA this is "custody and administration of crypto-assets on behalf of clients" (Art. 3(1)(17)), defined as "safekeeping or controlling, on behalf of clients, of crypto-assets or of the means of access to such crypto-assets." It corresponds to FATF VASP activity (iv), safekeeping or administration of virtual assets or instruments enabling control over them (Source 2). VARA classifies it as "Custody Services" (Source 3). Custody is treated as one of the higher-obligation activities because client assets are directly at risk, which is reflected both in prudential expectations and in segregation rules.

What "control of the means of access" means (private keys)

The MiCA definition deliberately reaches beyond physically holding coins. "Control of the means of access" captures the firm that holds the private keys, seed phrases, or signing rights that move client crypto, even where the assets technically sit on-chain in the client's name. If your service can move a client's assets, or could unilaterally do so because you hold the keys, you are providing custody under MiCA Art. 3(1)(17). This is why non-custodial wallet software (where the user alone holds the keys) generally falls outside the custody service, while hosted wallets, exchange-held balances and managed key arrangements fall inside it. The test is control, not legal title.

The VARA standalone-entity rule

Dubai applies a notable structural rule that other frameworks do not. Custody is the only VARA activity that must be conducted through a segregated, standalone legal entity (Source 3). Where VARA otherwise lets a firm aggregate multiple activities under one licence, custody must be ring-fenced in its own company. The intent is to insulate client assets from the operational and credit risk of the firm's other lines of business. If your Dubai structure combines, say, exchange and custody, you cannot run both from a single entity: the custody arm needs its own VARA-licensed company. Build this into your group structure early, because retrofitting a standalone custodian after the fact is expensive.

Crypto broker / dealer license: execution, RTO and placement

The broker or dealer license bundles three intermediary activities that the market treats as one but MiCA defines separately. It combines "execution of orders for crypto-assets on behalf of clients" (Art. 3(1)(21)), "reception and transmission of orders for crypto-assets on behalf of clients" (Art. 3(1)(23)), and "placement of crypto-assets" (Art. 3(1)(22)). VARA captures the same cluster under "Broker-Dealer Services" (Source 3). FATF, by contrast, has no single "broker" activity; the broker function is split across its transfer, exchange and issuance activities (Source 2). These intermediary activities generally carry lighter prudential floors than running a venue or holding custody, although AML obligations still apply in full.

Execution vs reception-and-transmission vs placement

The three sub-activities are easy to confuse. Execution of orders (Art. 3(1)(21)) means concluding agreements to buy or sell crypto-assets on behalf of clients, that is, actually filling the trade. Reception and transmission of orders (Art. 3(1)(23)) is lighter: you take a client's order and pass it to another party to execute, without filling it yourself. Placement (Art. 3(1)(22)) is the marketing of crypto-assets to purchasers on behalf of, or for the account of, the offeror, which is closer to distribution than to trading. A business that only forwards orders needs the RTO authorisation; one that fills them needs execution; one that markets a new offering needs placement. Many brokers hold all three.

Why FATF has no single "broker" activity

The cross-framework asymmetry here trips up multi-jurisdiction founders. FATF's five VASP activities were drafted as an AML baseline, not as a commercial taxonomy, so they do not contain a discrete "broker" category. Instead, broker-like functions appear inside other FATF activities: transferring virtual assets falls under activity (iii); executing exchanges falls under (i) or (ii); placing a new offering falls under (v), participation in financial services related to an issuer's offer. The lesson is that an activity that is one neat "license type" in MiCA or VARA may be spread across several FATF activities for AML purposes. When you map a business across regimes, do not assume the categories line up one to one.

Crypto payment, e-money and transfer license

Crypto payments are where the frameworks diverge most, so "do I need a separate license for crypto payments?" rarely has a one-word answer. Under MiCA, the relevant service is "transfer services for crypto-assets on behalf of clients" (Art. 3(1)(26)), defined as transferring crypto-assets from one distributed-ledger address or account to another. This maps to FATF VASP activity (iii), transfer of virtual assets (Source 2). VARA addresses it through a "Payments and Remittances" function (Source 3). Singapore, however, splits payments across several distinct services under the Payment Services Act, so a crypto payments business there may need more than one authorisation.

Crypto transfer under MiCA vs payment services under MAS

The contrast is stark. MiCA has one transfer service (Art. 3(1)(26)) covering the movement of crypto-assets between addresses. Singapore's Payment Services Act instead defines seven payment services, of which several can apply to a crypto payments model: domestic money transfer, cross-border money transfer, e-money issuance, account issuance, merchant acquisition, the DPT service, and money-changing (MAS Guide, Para 2.3.1). A business moving crypto and offering fiat-to-crypto rails in Singapore may therefore need a DPT-service authorisation alongside money-transfer or e-money authorisations, whereas the equivalent EU business may sit under the single MiCA transfer service. This is exactly why the activity-based model matters: the same product wears different "license type" labels in different jurisdictions.

What "DPT service" means in Singapore

Under the MAS Payment Services Act, a DPT (digital payment token) service is "buying or selling DPT, or providing a platform to allow persons to exchange DPT in Singapore" (Source 4). In practice the DPT service is the authorisation a crypto exchange or trading platform needs in Singapore, and MAS expanded the regulated scope of DPT services in 2024 to capture further activities such as custody and transfer of DPTs. Confirm the current in-scope DPT activities against the latest MAS notice before scoping a Singapore application, because the perimeter has been widening.

Crypto advisory and portfolio-management licenses

These are the two types the old market taxonomy most often omitted, hence the "and More" in this guide's title. Both are explicit MiCA services. "Providing advice on crypto-assets" is defined at Art. 3(1)(24), and "providing portfolio management on crypto-assets" at Art. 3(1)(25). VARA mirrors them as "Advisory Services" and "Management and Investment Services" respectively (Source 3). Both generally sit toward the lighter end of the MiCA prudential scale relative to exchange or custody, because the firm is not typically holding or dealing in client assets, but AML obligations still apply. If your model is advice-led or discretionary-management-led, these are the authorisations to scope.

Advisory: personalised recommendations

Crypto advisory authorisation covers giving "personalised recommendations to a client, either upon its request or at the initiative of the crypto-asset service provider," in respect of one or more transactions in crypto-assets (MiCA Art. 3(1)(24)). The key word is personalised: generic market commentary, research notes addressed to the public, or educational content do not typically constitute regulated advice. What triggers the authorisation is tailoring a recommendation to a specific client's circumstances. Firms that publish broad research can often stay outside the advisory perimeter, while those that tell an individual client what to buy or sell are providing the regulated service. The boundary is the personalisation, not the format.

Portfolio management: discretionary client mandates

Portfolio management authorisation covers "managing portfolios in accordance with mandates given by clients on a discretionary client-by-client basis" where those portfolios include crypto-assets (MiCA Art. 3(1)(25)). The defining feature is discretion: the firm makes buy and sell decisions for the client without seeking instruction on each trade, under a mandate the client has granted. This is distinct from advisory, where the client retains the decision, and from execution, where the firm merely fills client-initiated orders. If you run managed accounts or a discretionary crypto fund-of-one structure, this is your authorisation. The client-by-client wording also distinguishes it from collective investment schemes, which sit under separate fund regimes.

Is issuing a token (ICO) a license type?

No, and this is the single most common misconception in the "license types" space. Under MiCA, issuing or offering tokens to the public is governed by the issuer and offeror regime in Titles II to IV (covering asset-referenced tokens, e-money tokens, and other crypto-assets), which is entirely separate from the CASP service authorisation in Title V (MiCA Art. 3(1)). Issuance is not one of the ten crypto-asset services. FATF does treat issuance-related conduct under VASP activity (v), participation in or provision of financial services related to an issuer's offer or sale of a virtual asset (Source 2), and VARA licenses "VA Issuance (Category 1)" as a distinct activity (Source 3). So issuance is regulated, but in the EU it is a different regime, not a "license type" in the CASP sense.

Servicing tokens vs issuing them (two different regimes)

The clean way to hold this in your head: servicing tokens and issuing them are governed by separate regimes. Servicing (exchange, custody, broker, payment, advisory, portfolio management) is the CASP authorisation under MiCA Title V, built from the ten crypto-asset services. Issuing or offering a token to the public is the issuer/offeror obligation under MiCA Titles II to IV, with its own whitepaper and disclosure rules. A project that both issues a token and runs a platform for it therefore faces two distinct sets of obligations, not one combined "ICO license." Treating issuance as just another service type leads founders to under-scope their regulatory exposure. For the EU detail on how CASP authorisation works, see CASP services under MiCA.

Crypto license types mapped across MiCA, FATF, VARA and MAS

This is the heart of the guide: a single cited table mapping each market "license type" to its definition in all four anchor frameworks. No competitor offers a cross-framework table tied to primary sources, which is why this is the most citable asset on the page. Use it to see, at a glance, how one business model translates across the EU, the global AML floor, Dubai and Singapore.

Sources for every cell: MiCA Art. 3(1), FATF Recommendation 15, VARA licensed activities, and the MAS Payment Services Act guide.

MiCA's ten crypto-asset services (Art. 3(1)(17)-(26))

For EU founders, the ten MiCA services are the authoritative source list. They group into the six type buckets as follows (Source 1):

• (17) custody and administration of crypto-assets on behalf of clients - *Custody*
• (18) operation of a trading platform for crypto-assets - *Exchange*
• (19) exchange of crypto-assets for funds - *Exchange*
• (20) exchange of crypto-assets for other crypto-assets - *Exchange*
• (21) execution of orders for crypto-assets on behalf of clients - *Broker / dealer*
• (22) placement of crypto-assets - *Broker / dealer*
• (23) reception and transmission of orders for crypto-assets on behalf of clients - *Broker / dealer*
• (24) providing advice on crypto-assets - *Advisory*
• (25) providing portfolio management on crypto-assets - *Portfolio management*
• (26) providing transfer services for crypto-assets on behalf of clients - *Payment / transfer*

Token issuance sits outside this list, under the issuer/offeror regime in MiCA Titles II to IV, not as a service in Title V.

Can one entity hold several crypto license types?

Generally yes, and most real businesses do. MiCA lets a single CASP be authorised for multiple crypto-asset services within one authorisation, so an exchange that also custodies client assets and gives advice can hold all three under a single CASP license (MiCA Art. 3(1)). VARA similarly allows a firm to aggregate activities under one licence, with one structural exception: custody must be a segregated standalone legal entity (Source 3). The planning point is that adding activities adds obligations: each service you bolt on widens your AML scope and can lift your prudential requirements. Scope the full set of activities your model performs before you apply, so the authorisation covers you from day one.

How capital and AML obligations scale by activity

Two obligation layers move with the activities you choose. AML applies to every activity without exception: FATF Recommendation 15 makes AML and KYC the baseline for all VASP activities, so there is no "AML-light" crypto license (Source 2). Prudential (capital) requirements scale by activity under MiCA: operating a trading platform sits at the top, dealing on own account and custody sit higher, while execution, reception and transmission, transfer, advice and portfolio management carry lighter floors (Source 1). Exact EUR minimum-capital figures are set in MiCA Art. 67 and Annex IV and belong on the requirements page; we keep them off this taxonomy page until verified. The principle to take away: the heavier your activity (running a venue, holding assets), the heavier your capital.

Have questions about your specific situation? Book a free 15-minute discovery call with our licensed advisors, no commitment. Book a Call

How to choose the right crypto license type for your business

Choosing the right license type starts with one question: what does your business actually do for clients? Map each function you perform to its regulated activity, then add up the authorisations you need. Because most regimes grant several activities in one authorisation (with the VARA custody exception), the goal is to scope completely, not minimally, so you are not forced to reapply when you add a feature. Once you know your type, the next decision is jurisdiction, and that is where cost, timelines and substance requirements come in. To compare jurisdictions head to head, see how to compare licenses by country.

Match your activity to the authorisation

Use this decision list to translate your model into authorisations:

• Order-matching venue or instant-buy platform to *exchange* (trading-platform operation, MiCA Art. 3(1)(18)).
• Hosted wallet or asset safekeeping to *custody* (MiCA Art. 3(1)(17); VARA standalone entity).
• OTC desk or order-routing brokerage to *broker / dealer* (MiCA Art. 3(1)(21)-(23)).
• Crypto transfers or fiat-to-crypto rails to *payment / transfer* (MiCA Art. 3(1)(26); multiple MAS services in Singapore).
• Personalised investment recommendations to *advisory* (MiCA Art. 3(1)(24)).
• Discretionary managed accounts to *portfolio management* (MiCA Art. 3(1)(25)).

If you perform several of these, you typically need authorisation for each, usually within a single CASP authorisation under MiCA. For a model-by-model walkthrough, see licensing by activity and business model.

Where to get licensed once you know your type

Once your activity mix is settled, the choice of jurisdiction drives cost, speed and credibility. The EU offers MiCA passporting across the bloc; Dubai's VARA offers a dedicated virtual-assets regime; Singapore's MAS offers a respected payments framework; Switzerland offers Crypto Valley credibility under FINMA. Cost-sensitive founders often start by screening the most affordable licensing routes before narrowing down. From there, our complete crypto licensing guide walks through requirements, timelines and substance country by country. The sequence that works in practice: confirm your activity types first, then pick the jurisdiction whose regime and reputation fit your model and budget. For the wider catalogue, see all crypto licenses worldwide.

From our practice

In our advisory work in Zug, the most expensive errors we see are not in the application itself but in the scoping that precedes it. Founders frequently arrive describing themselves as needing "an exchange license," when the product also custodies client balances and forwards some orders to third-party venues, meaning three distinct activities are in play. Re-scoping after submission, or worse after authorisation, costs time and goodwill with the regulator. The discipline that consistently saves clients months is to write down every client-facing function first, map each to its regulated activity using the framework definitions above, and only then choose the jurisdiction. Activity scoping before jurisdiction selection, in that order, is the single most reliable way to avoid a stalled application.