MiCA makes crypto authorisation a product architecture decision

MiCA's service definitions include custody, operating a trading platform, exchanging crypto-assets, executing orders, advice and transfers on behalf of clients. Article 59 requires an appropriate authorisation route and provides that authorisations specify the services covered. Expanding a product from a simple interface into control of customer assets could therefore alter what the business needed permission to do. The screen's appearance was a poor guide to that boundary.

Asset classification mattered separately. MiCA excludes crypto-assets that qualify as financial instruments from its scope. It distinguishes e-money tokens referencing one official currency from asset-referenced tokens and other crypto-assets. A founder needed an account of the rights and services being offered before estimating a regulatory budget. Calling something a token did not establish that MiCA was the only relevant framework.

Article 70 requires providers holding customer crypto-assets, or the means of access to them, to safeguard customers' ownership rights, especially on insolvency, and prevent use of those assets for the provider's own account. It also establishes requirements for safeguarding customer funds, with specified exceptions for certain already regulated institutions. These are consequences for the ledger, access permissions and account arrangements, as well as for legal documents.

For a custody startup, an investor could ask whether the records would identify each customer's entitlement if the company stopped operating. The balance shown in an app needed to be supported by underlying records and account arrangements. Reconciliation, separation of company and customer resources, and recovery procedures therefore belonged in the core product from the outset. These obligations could not be deferred until the business had grown.

Article 73 allows operational functions to be outsourced while keeping the crypto-asset service provider fully responsible for its obligations. It requires retained expertise, access to relevant information and written agreements, alongside an outsourcing policy that includes contingency plans and exit strategies. The practical effect was to make supplier selection inseparable from the provider's ability to supervise and replace what it bought.

That created a demanding market for infrastructure vendors. A supplier managing keys or monitoring transactions could help a startup build more quickly, but customers would need evidence about its operation and ways to obtain their data. An API with weak records, opaque dependencies or no workable exit could obstruct the customer's authorisation case, regardless of its technical quality. Vendors could compete by making these obligations easier for customers to demonstrate.