How to Start a Crypto Exchange: Technical & Legal Requirements

To start a crypto exchange you build two stacks at once: a legal stack (a licensed company, an AML and KYC programme, and client-asset custody) and a technical stack (a matching engine, hot and cold wallets, and a hardened security layer). There is no single global licence, so you choose a jurisdiction first and meet its rules.

That sentence hides a lot of work. A crypto exchange is a regulated financial business in every serious market, which means the software is only half the project. The other half is the authorisation, the compliance programme, and the way you safekeep customer assets. This guide walks both halves in parallel: it sets out the legal requirements anchored to four real regimes (EU MiCA, US FinCEN, Singapore MAS and UAE VARA), the technical requirements anchored to recognised standards and the one regulator that writes exchange technology into binding rules, and then a 10-step launch sequence that fuses the two. Throughout, vendor names are illustrative examples, not endorsements, and the money figures live on a separate cost page.

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

How to start a crypto exchange (the short answer)

Starting a crypto exchange means launching a regulated virtual-asset service provider that operates a trading platform. You pick a jurisdiction, incorporate a licensed legal person, run an AML and KYC programme, safekeep client crypto under custody rules, and build a resilient matching engine and wallet system. There is no single worldwide licence.

The work splits cleanly into a legal track and a technical track, and the two are interdependent: your licence dossier has to describe your technology, and your technology has to enforce your compliance rules. Get them out of sync and the application stalls. The rest of this page treats each track in depth, then ties them together as an ordered launch plan, and finally compares the four anchor regimes side by side so you can see where to file.

Legal stack vs technical stack at a glance

The legal stack is everything a regulator approves before you can trade: the corporate entity and its local substance, the licence or registration for your chosen jurisdiction, the written AML and KYC programme, and the custody and safekeeping arrangements for client assets. The technical stack is everything that has to run reliably once you trade: the matching engine and order book, the hot and cold wallet architecture with its key management, the KYC and Travel Rule integrations, market-surveillance tooling, and the security and resilience layer (penetration testing, ISO 27001, SOC 2). The hero image on this page splits exactly along that line: licence, AML and custody documents on one side, matching engine, wallets and a security shield on the other. If you are reading from the licensing pillar, start with crypto exchange licensing by regime for the wider context, then come back here for the build detail.

Do you need a licence to run a crypto exchange?

Yes. A crypto exchange is a regulated VASP, CASP, MSB or DPT-service provider depending on where it operates, and running one without authorisation is unlawful in every serious market. In the EU, crypto-asset services may only be provided by an authorised legal person under Regulation (EU) 2023/1114 (MiCA), Art. 59. In the US, an entity that accepts and transmits convertible virtual currency, or buys and sells it, is a money transmitter and a money-services business under FinCEN Guidance FIN-2019-G001. Singapore regulates the same activity as a digital-payment-token service under the MAS Payment Services Act 2019 framework, and Dubai treats it as a licensed Exchange Services activity under the VARA Virtual Assets and Related Activities Regulations 2023.

The practical takeaway is that "do I need a licence" is the wrong question. The right question is which licence, in which jurisdiction, and that is the decision Step 1 forces you to make.

CASP vs VASP vs MSB vs DPT service (terminology box)

These four acronyms describe the same exchange business under four legal labels. Readers conflate them constantly, so it pays to fix the vocabulary before going further:

• CASP (crypto-asset service provider): the EU label under MiCA. Operating a trading platform is one of the listed CASP services, authorised under Reg (EU) 2023/1114, Art. 59.
• VASP (virtual-asset service provider): the FATF term, used directly in UAE law. Dubai licenses an exchange as a VASP carrying on Exchange Services under the VARA 2023 Regulations.
• MSB (money-services business): the US framework. A convertible-virtual-currency exchanger is a money transmitter and therefore an MSB under FIN-2019-G001 and the Bank Secrecy Act.
• DPT service (digital-payment-token service): the Singapore label under the Payment Services Act 2019, regulated by MAS.

Same business, four statutes. For the EU label specifically, our guide to CASP authorisation under MiCA goes deeper into the application route.

Step 1 of the legal stack: choose your model and jurisdiction

The first decision is not legal at all, it is structural: what kind of exchange are you building? That choice determines which licence applies, so it has to come before incorporation, before capital, before any code. The four anchor regimes in this guide (EU MiCA, US FinCEN, Singapore MAS and UAE VARA) each treat an exchange slightly differently, and the model you pick interacts with each of them.

Custodial exchange, DEX, or broker/OTC

A custodial order-book exchange holds client assets and runs a matching engine: this is the classic exchange, and it triggers the fullest set of trading-platform, custody and market-integrity rules. A non-custodial or decentralised exchange (DEX) that never takes possession of client assets sits in a different, evolving regulatory position, though MAS has expanded its scope so that facilitating the exchange of digital-payment tokens can be caught even without taking possession, per the MAS framework. A broker or OTC desk that fills client orders against its own book is a different activity again. Decide which of these you are before you read the licence rules, because the answer changes which licence you need.

The four anchor regimes (EU MiCA, US FinCEN, Singapore MAS, UAE VARA)

We anchor this guide to four regimes because they cover the dominant routes and because each codifies the requirements in primary text you can cite. The EU offers MiCA, where a single CASP authorisation passports across all EU and EEA member states under Art. 65, which is the big structural advantage. The US requires federal MSB registration plus state-by-state money-transmitter licences, which is the most fragmented route. Singapore licenses a DPT service under MAS with a clear capital ladder. The UAE licenses Exchange Services under VARA, the only regulator that writes exchange technology into binding rule text, which is why it anchors the technical sections below. To weigh the trade-offs across more than these four, see our guide to compare crypto licensing jurisdictions.

Entity and licence: what the law requires

Across all four regimes you must operate through an authorised legal person, a company, never as an individual, with a registered office, local substance, and fit-and-proper management. The EU sets this out plainly: crypto-asset services may only be provided by a legal person with a registered office in a member state, at least one director resident in the EU, and effective management in the EU, under MiCA Art. 59. The authorisation dossier goes to a national competent authority under Art. 62, which first checks completeness and then the merits under Art. 63, and one approval then passports EU-wide under Art. 65.

Incorporation and local substance

The substance requirement differs by regime but never disappears. In the EU you need effective management and at least one EU-resident director under MiCA Art. 59. In Singapore, an SPI or MPI applicant must be a Singapore-incorporated company or a Singapore branch of a foreign corporation, with a permanent place of business and a qualifying executive director, per MAS. In the US you need a legal person registered federally as an MSB plus state money-transmitter licences, per FinCEN. In the UAE you operate as a VARA-licensed VASP under the 2023 Regulations. For the US side specifically, see US exchange requirements (MSB and state).

Minimum capital and own funds

Capital is regime-specific and changes over time, so treat these figures as current as of 2026 and verify them against the source before you file. In the EU, operating a trading platform is a Class 3 activity with a permanent minimum own-funds requirement of EUR 150,000, and own funds must be at least the higher of that minimum or one quarter of the prior year's fixed overheads, under MiCA Art. 67 and Annex IV. In Singapore, a Major Payment Institution needs base capital of at least S$250,000, while a Standard Payment Institution needs at least S$100,000, per the MAS Guide to the Payment Services Act 2019. VARA does not publish a single headline capital number for Exchange Services in the same way, so do not assume one. The full cost picture, including fees and build budget, sits on a dedicated page rather than here.

The licence application dossier

The dossier is where the legal and technical stacks meet on paper. Under MiCA Art. 62 the application must include a programme of operations, a description of governance and internal controls, the AML procedures, proof of own funds, descriptions of IT systems and security arrangements, the custody and segregation arrangements, and the identities of management and qualifying shareholders. Singapore adds a procedural gate: new DPT licence applications require an Independent External Auditor Assessment covering AML/CFT and consumer protection before MAS will grant the licence, per the MAS licensing framework. In other words, you cannot describe a compliance programme you have not built, which is why the technical work runs alongside the application rather than after it.

AML and KYC: the compliance programme every exchange must run

An AML and KYC programme is mandatory in every serious jurisdiction, because an exchange is an obliged entity for anti-money-laundering purposes everywhere it operates. The baseline structure is a written AML/CFT programme with a designated compliance officer, ongoing training, and independent review, the same money-services-business standard that applies to convertible-virtual-currency money transmitters under FIN-2019-G001 and the Bank Secrecy Act. On top of that you run customer due diligence, sanctions and PEP screening, transaction monitoring, suspicious-activity reporting, the Travel Rule, and market-abuse surveillance under MiCA Title VI, Arts. 86 to 92 and the VARA market-surveillance rules. For the full programme design, see our guide to AML and KYC requirements.

Customer due diligence and screening

Customer due diligence starts at onboarding: identify and verify each customer, assign a risk rating, and apply enhanced due diligence to higher-risk customers, with sanctions and PEP screening throughout. MiCA folds these AML procedures into the Art. 62 application dossier, and MAS requires the AML/CFT element to be tested in the Independent External Auditor Assessment for new DPT applications, per MAS. The regulator cares about the outcome (verified identity, screened against sanctions and PEP lists, risk-rated, with an audit trail), not which vendor you use to achieve it.

The Travel Rule for crypto transfers

The Travel Rule requires that crypto transfers carry originator and beneficiary data, and it applies under three overlapping regimes you should build to from day one. FATF Recommendation 16 sets the baseline with a de-minimis threshold of USD/EUR 1,000 and a defined data set, per FATF R.16. The EU goes further: under Regulation (EU) 2023/1113 (the Transfer of Funds Regulation) there is no de-minimis for crypto transfers (all amounts are in scope), with enhanced verification for self-hosted wallets above EUR 1,000, applying from 30 Dec 2024. The US sets a USD 3,000 threshold under 31 CFR 1010.410(f); a proposed USD 250 cross-border threshold has not been finalised, so do not treat it as in force. The common messaging standard for exchanging this data between providers is IVMS101. For the full picture, see crypto Travel Rule compliance.

Market surveillance and suspicious-activity reporting

An exchange has to watch its own market. Under MiCA Title VI you must detect and report suspected market abuse through suspicious-transaction-and-order reports. VARA's market-surveillance rule requires the exchange to share surveillance information with VARA and to report suspected market abuse, including positions, inventory, actions taken, and any limit or margin changes, per the VARA Exchange Services Rulebook. This is where the compliance programme and the trading technology connect: surveillance is a software capability that satisfies a legal duty.

Custody: how you must safekeep client crypto

Custody is the single most consequential legal obligation on an exchange, because it governs what happens to client assets if you fail. Under MiCA Art. 70 you must segregate clients' crypto-assets and funds from your own, never use them on your own account, place client funds with a credit institution or central bank, and protect ownership rights, particularly on insolvency. Art. 75 adds custody-specific duties: a written client agreement, a position register per client, a custody policy, and liability for the loss of client crypto-assets or means of access (including from ICT incidents) up to market value. The UAE layers concrete wallet-management rules on top, in the VARA Custody Services Rulebook.

Segregation and custody liability (MiCA Art. 70/75)

The MiCA custody rules are strict on purpose. Segregation under Art. 70 means client assets are ring-fenced from your balance sheet, so they are not exposed to your creditors if you become insolvent. No own-account use means you cannot lend, stake or rehypothecate client crypto without authority. And the liability rule in Art. 75 puts the loss on you, up to market value, if client assets or their access keys are lost, including through an ICT incident. That liability is why the wallet architecture below is a legal matter as much as a technical one.

Hot and cold wallets and key management (VARA)

VARA's Custody Rulebook turns custody into specific, citable engineering requirements through its VA Wallet Management rules, per the VARA Custody Services Rulebook:

• Risk-based hot-vs-cold decision: run a risk-based analysis to decide the storage method, including which assets sit in hot versus cold wallets.
• Secure key generation: use industry best standards to create the seed and the asymmetric private and public key pairs.
• Encryption and secure storage: apply industry best-practice encryption and secure device storage for clients' private keys when not in use.
• Backups: store all key and seed backups in a separate location from the primary, with matching encryption, and break mnemonic phrases into at least two parts.
• Multi-signature: consider multi-signature controls where appropriate; VARA may require them.
• Collusion mitigation: mitigate the risk of collusion between authorised signatories who can move, transfer or withdraw assets.

Note one thing VARA does not do: it sets no numeric cap on hot-wallet holdings. "Keep the majority of assets in cold storage" is common industry practice, not a quoted VARA figure, so do not present a percentage as a rule.

The technical stack: matching engine, wallets and APIs

Most "exchange tech stack" content online is vendor marketing, so this guide anchors the technical requirements to the one regulator that writes exchange technology into binding rules, VARA, and treats the rest as general engineering practice clearly marked as such. The diagram for this section lays out the components in order: a matching engine and order book at the core, hot and cold wallets with key management, a KYC vendor, Travel Rule tooling using IVMS101, market-surveillance tooling, and the ISO 27001 and SOC 2 security layer wrapped around all of it.

The matching engine and trading system (VARA III.C.1)

VARA's Exchange Services Rulebook imposes concrete duties on the trading system itself, which makes it a useful primary anchor for what a production matching engine must do, per the VARA Exchange Services Rulebook:

• The systems must be resilient and have sufficient capacity to ensure orderly trading under conditions of high uncertainty or extreme volatility.
• They must be able to reject orders that exceed pre-determined volume and price thresholds, or that are clearly erroneous.
• They must be fully tested to confirm the above.
• They must be subject to effective business-continuity arrangements, including back-up or disaster-recovery systems, facilities and sites.

Around that core, the build typically includes the order book and matching engine, low-latency order entry, a market-data feed, an admin and risk console, REST and WebSocket APIs, and a settlement and ledger layer. Those components are general practice rather than a regulator mandate, but the four VARA points above are binding rule text.

Wallets, key management and surveillance tooling

The wallet infrastructure follows the VARA key-management rules set out in the custody section above, applied as engineering controls: secure key generation, encrypted storage, separated and split backups, multi-signature where appropriate, and collusion controls between signatories, per the VARA Custody Services Rulebook. On top of the wallet layer you run market-surveillance tooling that satisfies the surveillance and reporting duties under the VARA Exchange Services Rulebook and MiCA Title VI, plus the REST and WebSocket APIs and the settlement and ledger that connect everything. The settlement, ledger and API design are general practice and should be marked as such, but the surveillance capability maps directly to a legal duty.

KYC and Travel Rule integrations

KYC and the Travel Rule are legal obligations usually met by integrating third-party tooling via API, and the regulator cares about the outcome, not the vendor. For identity verification and sanctions screening, exchanges commonly integrate a third-party provider (Sumsub, Jumio, Onfido and ComplyAdvantage are named here only as illustrative examples, not endorsements, and you should confirm their current offerings). For the Travel Rule, the data is exchanged between providers using the IVMS101 standard, often through a messaging network (Notabene, TRP and OpenVASP are illustrative examples only). What matters to MiCA, FinCEN and VARA is that identity is verified, screening is performed, and originator and beneficiary data travels with each in-scope transfer, per MiCA Art. 62 and FATF R.16.

Security, certifications and operational resilience

Security is both a regulatory outcome and a commercial gatekeeper: regulators require resilience, and banking partners require certifications before they will work with you. EU CASPs fall within DORA (Regulation (EU) 2022/2554), which has applied since 17 Jan 2025 and sets ICT risk management, incident reporting, resilience testing and third-party oversight duties. VARA reinforces this from the trading side with its "fully tested" requirement, per the VARA Exchange Services Rulebook. Layered on top are two voluntary standards that the market expects: ISO/IEC 27001 and SOC 2.

Penetration testing and DORA resilience

For EU CASPs, digital operational-resilience testing is a duty under DORA, alongside ICT risk management and incident reporting. VARA's "fully tested" rule for trading systems points the same way, per the VARA Exchange Services Rulebook. Independent penetration testing of the trading system, the wallet infrastructure and the public APIs is standard practice; treat any specific frequency (such as annual) as general practice unless a regime states otherwise. ICT incident reporting is required under DORA and ties back to the custodian's liability for losses from ICT incidents under MiCA Art. 75.

ISO 27001 and SOC 2 (voluntary, not a licence)

ISO/IEC 27001 and SOC 2 are security-assurance standards, not licences, and they are not a substitute for authorisation. ISO/IEC 27001 specifies the requirements for establishing, implementing, maintaining and continually improving an information security management system (ISMS); certification runs through a Stage 1 documentation and readiness audit and a Stage 2 compliance audit, with periodic re-assessment. SOC 2 is an AICPA assurance report on a service organisation's controls against the five Trust Services Criteria (Security, Availability, Processing Integrity, Confidentiality and Privacy), where a Type 1 report covers control design at a point in time and a Type 2 report covers operating effectiveness over a period. Neither replaces a licence, but banking partners, custodians and enterprise clients usually expect one or both before they engage.

The 10-step launch sequence (legal plus technical)

This is the procedural spine of the whole project. It fuses the legal and technical tracks into one ordered plan, and each step cites the obligation that drives it. Treat it as a checklist you can hand to your board.

Steps 1 to 5: model, entity, capital, AML, custody

1. Decide the model and jurisdiction. A custodial order-book exchange, a non-custodial DEX, and a broker or OTC desk each map to a different licence; pick EU MiCA, UAE VARA, Singapore MAS, or US MSB plus state, per MiCA, FinCEN, MAS and VARA.
2. Incorporate the entity with the required local substance, directors and registered office, per MiCA Art. 59 and MAS.
3. Raise and prove capital: EU trading platform EUR 150,000 (Class 3, MiCA Art. 67); MAS MPI S$250,000 base capital (MAS Guide to the PSA 2019).
4. Build the AML and KYC programme: compliance officer, written programme, CDD and EDD, sanctions and PEP screening, transaction monitoring, SAR/STR, and the Travel Rule, per MiCA, FinCEN and FATF R.16.
5. Design custody: segregate client assets (MiCA Arts. 70 and 75) and build the hot and cold wallet architecture and key management per VARA.

Steps 6 to 10: build, security, licence, liquidity, go live

1. Build the technical platform: matching engine and order book, resilient and capacity-tested trading systems with erroneous-order rejection and BCP/DR, plus APIs and KYC and Travel Rule integrations, per VARA.
2. Harden security and get assurance: independent penetration testing and DORA resilience testing, pursue ISO/IEC 27001 and/or SOC 2, and set up ICT incident reporting per DORA.
3. Apply for the licence with the full dossier (programme of operations, governance, AML, own funds, IT and security, custody), per MiCA Art. 62 and the MAS DPT process plus its independent auditor assessment.
4. Arrange liquidity and banking: market-maker or aggregated-liquidity arrangements and fiat rails, observing VARA's fee-fairness rule, per the VARA Exchange Services Rulebook.
5. Go live and operate continuously: maintain own funds, governance, custody segregation, surveillance, the Travel Rule, DORA and ICT resilience, complaints and conflicts handling, and an orderly wind-down plan, per MiCA Arts. 67 to 74.

From our practice. In our work advising exchange founders out of Zug, the projects that stall are almost never the ones with a weak matching engine: they are the ones that treated the licence dossier as paperwork to bolt on at the end. The dossier describes your governance, your AML programme and your custody design, so those have to be built and documented while the engineering proceeds, not after. The teams that sequence the legal and technical tracks in parallel, exactly as the 10 steps above set out, are the ones that reach a complete, fileable application without a costly rebuild.

Crypto exchange licence requirements by jurisdiction (EU, US, Singapore, UAE)

The four anchor regimes line up cleanly when you put them side by side. The comparison below shows the licence label, the headline capital position and the AML basis for each, so you can see at a glance where the trade-offs sit. Use it to shortlist, then read the per-country guide before committing.

EU (MiCA CASP), US (FinCEN MSB), Singapore (MAS DPT), UAE (VARA)

The EU's passporting under Art. 65 is the structural prize: one authorisation, the whole single market. The US is the most fragmented, which is why the US exchange requirements (MSB and state) and the New York BitLicense deserve their own pages. For the two non-EU routes here, see Singapore MAS DPT licensing and the Dubai VARA crypto licence guide.

How much does it cost and how long does it take?

Two questions every founder asks early are how long licensing takes and how much the whole build costs. The honest answers are "it depends" and "more than the licence fee," and both deserve a straight explanation rather than a made-up number.

Why there is no fixed timeline

There is no fixed legal timeline to launch a licensed exchange. The duration depends on the regime and, above all, on how complete your application dossier is when you file: an incomplete dossier triggers the completeness check before the merits assessment under MiCA Art. 63, and any procedural gate such as the MAS Independent External Auditor Assessment adds time you cannot compress, per MAS. Treat any timeline figure you see as an estimate, not a promise.

Where the cost figures live

The full cost picture (licence and application fees, the capital you must hold, the technology build, and ongoing compliance costs) sits on a dedicated page so this guide stays focused on the "how." See how much it costs to start an exchange for the budget breakdown, and read it alongside the capital figures above so you separate the money you spend from the money you must hold.