MiCA for Crypto Brokers and Trading Desks: An Operating Guide

What this guide covers, and what it does not

A vendor cannot make a firm compliant.

Liquid Mercury, the Chicago-based institutional digital asset infrastructure provider, builds trading technology for brokers and desks. A vendor cannot make a firm compliant. The firm holds the authorisation and the obligations. What software can do is make the evidence easier to produce, and that is the angle of this guide. ESMA keeps the authoritative MiCA page, including technical standards, Q&A and registers. Go there for rules and dates, which change.

Where MiCA touches a desk, in one table

The table maps the desk's workflow to the question a supervisor is likely to ask. It lists what to check, not what the rule says.

Execution, best execution and order handling

When a desk executes on behalf of clients, the question moves from "did we get a good price" to "can we show how we decided". That means a written execution policy, factors that are weighed (price, costs, speed, likelihood of settlement and others the policy names), and records that show each order followed it.

What to check:

• Is your policy specific to your business? A copy of an exchange's policy is not one. It should say which venues and liquidity providers you use and why.
• Can you reconstruct a single order? From request to quote to acceptance to fill to settlement, with timestamps and the prices available at the time.
• Do you review execution quality periodically? A review that compares providers and venues is how a policy stays a policy.
• How do you handle a request for a quote? Whether a desk quotes as principal, or routes to a provider and passes the price through, affects what you owe the client. Which categories apply is a question for counsel. ESMA's pages on MiFID II and MiFIR show how a comparable regime treats execution.

Liquidity sourcing matters here, because the policy has to name the providers behind the quote. A desk with one provider has a narrow policy to defend. A desk with several has a comparison to run. See crypto liquidity provision for how providers are combined and compared.

Record keeping and reporting

Most trading-technology evidence problems are record problems. Quotes live in chat. Fills live in a venue's export. Settlement lives in a spreadsheet. A supervisor asking for the life of one trade receives four files that do not agree.

What to check:

• What must be recorded, at what level of detail, and for how long. ESMA's first MiCA technical standards and your national authority define this; ESMA also published guidance on transitional measures. Do not rely on a vendor's description.
• Whether records are tied together. The same trade should carry one identifier across quote, order, fill and settlement.
• Whether records can be changed. An audit trail should show who changed what and when, and not allow silent edits.
• Whether you can produce them quickly. A supervisor's request has a deadline. Test your own retrieval before they do.
• Whether reporting covers compliance, risk and performance from the same underlying data, so the numbers you give a supervisor match those the desk runs on.

Custody and client asset segregation

A broker that holds client assets has a duty to keep them separate from its own and to be able to prove it. For a desk the common failure is not a theft. It is an unreconciled ledger: client balances that cannot be matched to the underlying holdings at a given hour.

What to check:

• Where assets sit (your own wallets, a custodian, a venue) and what the contractual position is at each.
• How balances are reconciled, how often, and what happens with a break.
• Whether settlement instructions are controlled, so that no single person can move client assets.
• What your records show during a failure, such as a custodian outage or a provider default.

A ledger integrated with settlement, rather than separate from it, shortens the reconciliation loop. The custody guide covers the models.

Conflicts of interest

A desk that quotes clients as principal, hedges on its own account and earns a spread has an inherent conflict. MiCA expects that to be recognised and managed, not eliminated.

What to check:

• A written policy that identifies the conflicts specific to your model (principal quoting, internalisation, proprietary trading, affiliated liquidity providers).
• Controls that separate roles where needed, and record who approved any exception.
• Disclosure to clients of what the conflicts are and how they are managed.
• Evidence that the policy is applied: the audit trail of an override is the proof.

Market abuse monitoring

Surveillance used to be a bank problem. For a CASP it becomes an operating function: someone has to look at orders and trades for patterns such as wash trading, spoofing or trading ahead of clients, and decide what to escalate.

What to check:

• Scope. Which markets and which of your activities fall inside the regime, as distinct from those that do not.
• Data. Whether you hold the order, quote and trade data a monitoring process needs, in one place.
• Alerting and review. Who looks at what, how often, and what the escalation path is.
• Reporting. To whom, and how, you report suspicious activity under your authority's process.

Pre-trade limits are the cheapest surveillance there is. Per-order size, per-symbol caps, balance and credit checks and region restrictions stop a class of problems before they become alerts.

Consolidation pressure on smaller brokers

A pattern is visible in the market: smaller brokers, particularly in the Nordic region, are reviewing how many separate systems they run for quoting, execution, settlement and reporting. This is a market observation from conversations with brokers, not a published statistic. The logic is simple. Authorisation brings audit, reporting and safeguarding duties, and every additional system is another place those duties must be met and evidenced. Some firms respond by moving to fewer vendors, so that quotes, ledger, risk and reporting share one set of records.

It is not the right answer for every firm. A broker with a stack that already produces consistent records may do better connecting what it has. The practical test is whether the firm can show a supervisor the full life of a trade without stitching records together by hand.

Build vs buy under MiCA

The consequence of the above is that the build-or-buy decision changes character. Before authorisation, a custom stack was an engineering choice. Afterwards, it is a compliance choice too, because the firm must maintain, evidence and defend whatever it built.

• Build when your execution or pricing logic is your edge and you can fund a permanent team that includes the audit trail, reporting and change control, not only the quote screen.
• Buy when the platform is the means to serve clients, and you want records, ledger and risk controls to arrive as a package maintained by someone else. You still own the policy and the oversight of the vendor.
• Combine when parts of the stack are strategic and others are plumbing.

The cost comparison is in build vs buy a crypto OTC platform, and the sequence for a new desk is in how to start a crypto OTC desk. Market makers supplying liquidity to a regulated desk face their own questions, covered in how to become a market maker.

What a desk needs from its platform, and how Liquid Mercury's stack does it

Reduced to a checklist, a regulated desk needs from its trading platform:

1. A record of every quote, acceptance and settlement event, tied to a client and a time.
2. Risk limits applied before the trade, and again after it, with overrides recorded.
3. Client controls at onboarding, including restrictions by region and asset.
4. A ledger that reconciles with settlement.
5. Reporting for compliance, risk and performance from the same data.
6. Contract terms that give you access to your records and a way out.

Mercury OTC is Liquid Mercury's white-label electronic OTC platform. It offers RFQ, request for stream and streaming quotes around the clock, an integrated ledger and settlement process, pre-trade and post-trade risk controls, full audit trails and reporting tools. Its Risk Engine includes checks on available balance, available credit and region. Liquid Mercury describes compliance and audit trails as built in from the start.

K33, a broker regulated by the Norwegian Financial Supervisory Authority, runs on Mercury OTC. According to its live case study, OTC trading volume grew 5x. Read the case study for the company's own account of its results and context.

None of this makes a firm compliant by itself. It shortens the distance between the obligation and the evidence.