Building a crypto asset universe under MiCA

A brokerage decides to add another asset. From the customer's side, a new market appears in the interface. Inside the firm, the questions are wider: where will it trade, what liquidity can actually be reached, how will orders be executed, where will the position sit after settlement, what will Operations reconcile, and does the asset fit within the regulatory perimeter the firm and its providers currently operate?

The useful size of an asset universe is not the number of tickers in it. Two providers can advertise similar coverage of MiCA crypto assets and deliver very different propositions once a brokerage tries to trade, hold, and report on them at scale. Breadth matters commercially, and customers notice gaps. But breadth without the infrastructure around it is a catalogue, not a universe.

What it actually means to support an asset

"Supported" is doing a lot of work in most provider marketing, and it pays to break it apart before comparing anyone.

Market access is the first layer: can the provider reach the venues where the asset genuinely trades, rather than one listing of convenience? Liquidity is the second, and it is a different question: what depth is usable at the order sizes and frequency the brokerage's flow will produce, not what is visible on a screen?

Execution follows. A thin altcoin and a major pair should not be forced through the same route, so the question is which methods are available for taking each kind of order to market. At asset level the question is simply whether an appropriate route exists for the sizes involved.

Then the post-trade layers. Custody: can the asset be safeguarded after execution, in the same structure and with the same reconciliation as the rest of the book? Reporting: can the resulting activity and positions land in the brokerage's operational records without manual rebuilding? And finally the regulatory and operational layer: is the provider comfortable supporting this asset, for this service, within its current permissions and processes?

An asset is meaningfully part of the universe when all of that works, not when the ticker appears in a list. That definition changes how a brokerage reads every provider comparison that follows.

MiCA does not reduce asset selection to a ticker list

Plenty of firms search for "MiCA-approved coins" or "MiCA-compliant coins", and the phrase holds for exactly one corner of the market. Stablecoins are the corner: issuers of e-money tokens and asset-referenced tokens need authorisation, ESMA maintains a register, and a token whose issuer is not on it genuinely is non-compliant, which is why some large stablecoins have been delisted by EU venues. For everything else, from BTC and ETH to the long tail, no approved-token list exists. MiCA regulates the services around those assets: the white paper requirements attached to public offers and admission to trading, and the obligations on the CASP providing each service.

What a CASP can do with a given asset therefore depends on the category the asset falls into, the service being provided, the CASP's own authorisation and permissions, and the firm's review and operating processes. The same asset can be straightforward for one service and outside perimeter for another, at the same firm, on the same day.

For a brokerage building its universe, the practical consequence is that asset assessment is a firm-level exercise rather than a lookup. Compliance is not the department that says no at the end; it is one of four functions with a legitimate question about every addition. Trading asks whether it can be executed properly, Product asks whether customers want it, Operations asks whether it can be settled and reconciled, and Compliance asks whether it fits the permissions and obligations in play. A universe built by answering all four is slower to grow and much harder to break.

Headline asset count can hide important differences

Once "supported" has been broken into layers, the headline number becomes the least informative fact on a provider's page.

The questions that expose the differences: are all listed assets available for the same services, or is a subset tradable but not custodied, or custodied but only tradable high-touch? What execution methods exist per asset, and does the long tail get anything beyond a single route? Is the liquidity behind each listing appropriate for the flow the brokerage will actually send? Do some assets carry different availability, onboarding, or documentation requirements? And what happens when a client needs something outside the current universe?

A large number can be the honest surface of deep coverage, or a catalogue padded with listings that fail these questions. The only way to know is to ask them asset class by asset class, against the brokerage's own expected flow. A curated universe with clear answers is a stronger foundation than a longer list with unclear ones. And curated has a second half: what happens when something is missing, which gets its own section below.

Liquidity determines whether breadth is usable

An asset existing in a provider's catalogue says nothing about where its liquidity sits, how fragmented it is across venues, how much is realistically executable at a given size, or whether the route to it exists at the moment the order arrives. Crypto liquidity is uneven and moves, and the gap between visible depth and usable depth is widest exactly in the long-tail assets that differentiate a brokerage's coverage. There is a fuller discussion in why fragmented liquidity still matters, and it is worth reading before taking any coverage claim at face value.

One caution on the multi-venue point. Access to more venues gives an execution provider more potential sources of liquidity; it does not by itself produce better execution. The result still depends on routing, market conditions, the characteristics of the order, and the execution approach chosen. A brokerage evaluating coverage should ask where the provider can reach, and separately how it uses that reach.

Custody has to expand with the universe

Every asset a customer can buy is an asset somebody has to hold. Adding a market without confirming the safekeeping side leaves the brokerage discovering, post-launch, that positions in the new asset sit outside the structure the rest of the book uses, with their own reconciliation path and their own operational exceptions.

The check is short: is custody available for the asset, in the same segregation structure, with the same reconciliation and reporting as everything else, and with operational support when a movement fails? How those structures work in practice, from omnibus and dedicated arrangements to the daily reconciliation rhythm, is covered in the custody model that fits the working day. At universe-building level the principle is simply that trading support and safekeeping support are one decision, made together, per asset.

New assets need a process, not a promise

A static universe is a commercial problem, because a brokerage's customers will eventually want something that is not on the list. The opposite pitch, that anything can be added on request without qualification, should worry a buyer just as much, because it implies the provider is not assessing what it lists.

The procurement question that separates the two: what happens, concretely, when we request an asset that is not supported today? A credible answer describes an assessment covering regulatory suitability for the services involved, market availability, liquidity at the sizes required, custody, technical and operational support, and whether the addition makes commercial sense for both sides. A credible answer also sometimes ends in no, and a provider willing to say so is telling the brokerage something reassuring about everything already on its list.

The credible position, Aplo's included, is that coverage can be extended on request, subject to the relevant assessment. No provider should promise more than that, and a brokerage should be sceptical of any that does: an instant yes to every request is a universe nobody is checking.

More assets should not mean more venue infrastructure

There is a version of expansion where every new asset drags new plumbing behind it: another venue onboarding, another funding balance, another API integration, more monitoring, and one more source feeding the reconciliation. Run that way, product breadth and infrastructure breadth grow at the same rate, and the operational cost compounds quietly until someone counts the venue accounts. That cost has its own treatment in the hidden operational cost of managing multiple venues.

The alternative is consolidated access, where the provider maintains the venue connectivity and the brokerage faces one account, one API, one funding base, and one reconciliation relationship, whatever happens behind them. Aplo operates this model as the market counterparty, through its MiCA CASP authorisation from the AMF in France, with passporting requested across seven further EU markets. Authorisation details are the kind of thing a compliance team should verify on the registers rather than take from anyone's copy, this page included.

Product breadth and infrastructure breadth do not have to grow at the same rate. Getting that separation right is most of what makes an expanding universe sustainable.

How to evaluate coverage

Put the layers together and the evaluation writes itself. For each asset class that matters to the product roadmap, ask the provider: where can you reach it, what depth is usable at our sizes, which execution routes apply, can it be custodied and reconciled alongside the rest of our book, and which services is it available for under your permissions? Then ask the forward question: what is your process when we request something new, and when did that process last say no?

A provider with good answers to those questions is offering a universe. One with a big number and vague answers is offering a list, and the difference will surface in the first quarter of live flow.

Planning to expand your digital-asset offering? Speak with Aplo about the markets and asset coverage available through your existing relationship.