Launching Your Own Crypto Exchange: White-Label Software, a Licensed Exchange Engine, or Your Own Build

A centralised crypto exchange holds its clients' coins and money. It matches their buy and sell orders in its own order book, the live list of orders waiting to trade. You can get the software in three ways. A provider can run its exchange software for you under your brand, which is called white-label. You can license an exchange engine and run it on servers you control. Or engineers can build the system to your design, and you can own the code. The choice depends mostly on who can run the system at any hour and how much of the exchange you need to control. On every route, the firm that holds the regulatory licence answers to its clients and its regulator.

What are the three ways to launch a crypto exchange?

• White-label exchange. A provider runs its exchange software on its own servers and shows it to your clients under your brand. It keeps the code, and it may run the wallets too.
• Licensed exchange engine. You pay a vendor for the right to use its software, and your team runs it on servers you control. The package includes the matching engine, the part that pairs buy and sell orders.
• Your own build. Your engineers, or a firm you hire, write the exchange to your design. You can own the code if the contract says so.

Two kinds of licence appear in this article. A software licence lets you use a vendor's code. A regulatory licence lets your company run an exchange. Paying for the first does not give you the second.

Which licence does a crypto exchange need?

In the EU, the licence comes from MiCA, Regulation (EU) 2023/1114 on markets in crypto-assets. It lists “operation of a trading platform for crypto-assets” as a crypto-asset service. A new firm needs authorisation as a crypto-asset service provider (CASP) before it offers that service in the EU.

A trading platform sits in the highest of the three capital classes in Annex IV of MiCA, with a minimum of EUR 150 000. The firm must keep a financial buffer, which MiCA calls prudential safeguards. The buffer must be at least that amount, or “one quarter of the fixed overheads of the preceding year” if that is higher. The firm also needs a registered office in an EU country where it provides at least part of its services. Its place of effective management, where the main decisions are made, must be in the EU, and at least one director must live in the EU.

The application must describe “the operating rules of the trading platform and of the procedure and system to detect market abuse”, so the plan for the software comes before the application. ESMA, the EU's markets authority, publishes a register of authorised CASPs where you can check a partner's claim to be authorised in the EU.

In Dubai, outside the Dubai International Financial Centre (DIFC), the Virtual Assets Regulatory Authority (VARA) lists “Exchange Services” among the activities it licenses. Its page says a firm “must apply for and receive a licence from VARA before it can begin operations in or from the Emirate of Dubai”.

Futures need their own licence check. MiFID II, the EU law for investment firms, lists futures among the financial instruments it covers. A futures module in a vendor's product does not include a licence to offer them, so ask a lawyer before you plan one.

All sources in this article were opened on 5 November 2026. For regulation, it quotes the EU and Dubai only. Confirm the rules with a lawyer in each market you plan to serve.

What must the exchange software do under MiCA?

Article 76 of MiCA sets duties for every CASP that runs a crypto trading platform, and many of them fall on the software. On any route, the software has to:

• Handle peak order volumes and keep trading orderly “under conditions of severe market stress”
• Reject orders “that exceed pre-determined volume and price thresholds or are clearly erroneous”
• Prevent or detect market abuse, so the firm can report cases to the regulator
• Publish the prices and amounts on offer in the book during trading hours, and the details of each trade “as close to real-time as is technically possible”
• Keep the data on every order for at least five years, or give the regulator access to the order book

ESMA has published a standard format for order book and record-keeping data in JSON, a common machine-readable file format. Its MiCA page says national authorities “expect to start requesting data in the new JSON file format within 6 months” of the format's publication on 28 November 2025. ESMA's surveillance system, MiDAS, uses that data to flag “potentially suspicious trading behaviour”. Ask any provider or builder to show these files coming out of their system.

Who holds client funds and keys on each route?

Coins in a crypto wallet move only when someone signs the transfer with the wallet's private keys, the secret codes that control it. MiCA treats “the safekeeping or controlling, on behalf of clients, of crypto-assets or of the means of access to such crypto-assets” as custody, a crypto-asset service that a firm must be authorised for.

• White-label: the provider may run the wallets, and then its staff or software control the keys. HollaEx, for example, lists an “Exchange wallet included” in its Enterprise Cloud plan and mentions “the option to integrate a custody solution of your choice”.
• Licensed engine: your team runs the wallets or connects a custody provider, and your firm answers to clients for the coins either way.
• Your own build: you choose the setup. For example, a custody provider holds most coins and your team runs hot wallets, the online wallets used for everyday withdrawals.

If a CASP that provides custody uses another firm for it, MiCA lets it use only firms “authorised in accordance with Article 59”. VARA's page says a custodian in Dubai “must be set up as a distinct legal entity with a standalone licence”. On every route, keep client money in euros or dollars in bank accounts in your company's name, separate from the company's own money. The article on client funds covers the wallets in detail.

How do we get liquidity on day one?

Liquidity means enough buy and sell orders in the book for a client to trade straight away at a price close to the market. A new exchange opens with an empty book. The spread is the gap between the highest price a buyer offers and the lowest price a seller asks. While orders are few, it is wide.

Exchanges fill the book in these ways:

• Market makers: trading firms that keep buy and sell orders in your book under an agreement that sets how close their prices must stay. They may be paid through lower trading fees, a fixed fee or both.
• A shared order book: some providers let several exchanges that run on their software trade in one book, so clients of different brands trade with each other.
• Liquidity links: prices from larger exchanges appear in your book, and when your client's order fills, someone places a matching trade on the larger exchange. Shift Markets mentions “aggregated orderbooks” in a post about its Market Maker tool, and HollaEx's pricing page lists “Liquidity included for the largest markets (Orderbooks)”.

Each method raises the same question: whose account takes the other side of your client's trade. In the EU, CASPs operating a trading platform “shall not deal on own account on the trading platform for crypto-assets they operate”. VARA's page says licensed firms “are prohibited from proprietary trading”, meaning trading with the firm's own money, under their licence. It adds that a separate company must be set up for such trading. If a provider offers a market-making bot, as HollaEx's pricing page lists for its Enterprise Cloud plan, ask whose money it trades.

Fake trading volume is a legal risk too. Under MiCA, market manipulation includes a trade or an order that “gives, or is likely to give, false or misleading signals as to the supply of, demand for, or price of, a crypto-asset”, unless it is placed for legitimate reasons. Trades placed only to make a new book look busy can send that kind of signal.

When is a white-label exchange the right start?

A white-label fits when most of these are true:

• You want to learn whether clients will trade with your brand before you spend on technology
• Nobody on your team can run exchange servers and wallets day and night
• The provider can show how its setup fits your licence, from where the servers run to who holds the keys

You give up control: the provider decides what changes and when, and your clients' orders and data pass through systems you do not run. Leaving later means moving every client account and every coin to a new system.

Under MiCA, handing operational functions to another firm is outsourcing, and CASPs that do it remain “fully responsible for discharging all of their obligations”. They need an outsourcing policy that covers “contingency plans and exit strategies”, and the written agreement must give them “the right to terminate”.

When does licensing an exchange engine make sense?

License an engine when:

• You have, or will hire, a team that can run servers day to day and install updates
• You want client data and wallet keys on servers you control
• The product does most of what you need, and the vendor will add the rest or let your team add it

Terms differ by vendor. Openware, for example, describes a “Lifetime software license” for its OpenDAX Aurora product, paid for once, and says the software “is deployed on your Cloud or Baremetal hosting”. It also lists “Access to Source Code”.

Running the software is then your job. Your team installs each update and answers alerts at night, for example when a blockchain node, the server that connects you to a blockchain, stops working. Access to source code under a licence also differs from owning it, so check what the licence lets you change.

When is building your own exchange worth it?

Build when at least one of these is true:

• The exchange is what you sell, and the products you tested cannot apply its order types or rules
• Fees that grow with your volume now cost more than a team running your own system would
• You need to own the code and every rule in it

A build takes longer to reach the first trade, and each new blockchain or coin adds code and testing after launch. You can build only the parts that set you apart and buy the rest, such as custody from an authorised provider.

The matching engine at the centre should give the same result each time it replays the same orders, so the book can be rebuilt after a crash. The article on matching engine design explains how, and the one for founders without a chief technology officer covers choosing a build partner.

What does each route cost?

Prices depend on the provider and the scope, so compare how each route is charged:

• White-label: a setup fee, then a monthly fee or a share of your revenue, or both. On 5 November 2026, HollaEx's pricing page listed “Low revenue sharing at 15%” for its Enterprise Cloud plan. The page did not say what it is a share of. Ask each provider what its share is based on.
• Licensed engine: a licence fee, paid once or on a schedule, plus support and updates if the licence does not include them. You also pay for your own servers and the staff who run them.
• Your own build: the team that builds it, then the people who run it, plus servers and outside security reviews. These include penetration tests, where testers try to break in the way an attacker would.
• Every route: legal work for the licence, the capital MiCA requires, compliance staff, services that check clients' identities and screen crypto addresses, market-maker agreements and a bank for client money.

A build costs most before launch, while a white-label spreads its cost over the years you use it.

What can we take with us if we leave?

Before you sign, write down what stays yours:

• Client data. If a provider processes your clients' personal data on your behalf, the GDPR, the EU's data protection law, calls it a processor. The contract must then say that, at your choice, it “deletes or returns all the personal data” when the service ends. If clients sign up under the provider's own terms, ask a lawyer whose clients they are.
• Records. MiCA requires records of “all crypto-asset services, activities, orders, and transactions”, kept for five years, or up to seven if the regulator asks before then. They must be given to clients on request. Ask for an export of the ledger with every order, trade, deposit and withdrawal, in a documented format, at any time.
• Coins. Agree in writing how client coins move to wallets you control, and who signs those transfers. Test the move once with a small amount.
• Brand and domain. They stay yours only if the domain and trademark are registered in your company's name. Do that before launch.
• Code. You own code only on a build, and only if the contract says so. With a licence, ask for source code escrow. A third party holds a copy of the code and releases it to you on events the contract names, such as the vendor going out of business.
• Exit terms. Get in writing how much notice each side gives and what help the provider owes you during the move.

What should we ask a firm that would build or run our exchange?

• Whose regulatory licence will our clients trade under, and which licences do you or your partners hold in the markets we plan to serve?
• Who holds the keys to client wallets, and in whose name are the wallets?
• Where does liquidity come from on day one, and whose account takes the other side of our clients' trades?
• How does the system reject orders above set price and size limits, and how does it flag possible market abuse?
• Can the system produce ESMA's order book and record-keeping files, and can we export five years of records at any time?
• Who answers when a wallet or a blockchain node stops working at night?
• Can you show this working in a system that runs today?

Where does amBrain fit?

amBrain publishes this blog. It describes part of its trading work in one line: “amBrain builds algorithmic trading infrastructure: order execution, market data and pre-trade risk controls.” Another line on amBrain's website reads: “Trading terminal development, order management systems, and FIX protocol exchange integration.”

amBrain has been building software since 2019. On how it works with clients, it says: “Three formats: full delivery, a dedicated team, or engineers embedded in your team.” Its line on ownership is “The client keeps full ownership of the product and the code, except our reusable components.” Ask for the list of those components by name before you sign.

This article is not a case study. It describes no client work and gives no amBrain prices or timelines. It quotes HollaEx, Openware and Shift Markets from their published pages to show how vendors describe their terms. It recommends none of them and claims no relationship between amBrain and any vendor or regulator it quotes.

It is not legal advice either. If amBrain is on your shortlist, ask it the same questions as any other firm.