How to Architect a Regulated Crypto Platform: Operating Models for the EU (and Beyond)
- ASD Labs
- 13 minutes ago
- 34 min read
~45 min read – A founder‑ and C‑suite‑level guide to designing the operating model of a regulated crypto business – from licensing and partners to technical architecture, compliance build‑out, and how the whole system scales.
This guide takes the abstract "regulating crypto" debate and turns it into something founders and operators can actually draw: a regulated crypto operating model for exchanges, DeFi gateways, AI‑heavy platforms, and future wealth products.
If you need the full legal and policy backdrop – MiCA text, CASP licensing requirements, and EU crypto timelines – read this alongside your MiCA operational readiness checklist, EU CASP licensing guide, and EU crypto regulation & MiCA deadline overview. Those pieces explain what the rules say and what needs to be in place before you apply; this one focuses on how a regulated business should be architected so those rules don’t break you at scale.
Jump to:
TL;DR – What a "Regulated Crypto Operating Model" Actually Is
90-second summary
Architecture: Align four layers – strategy & licensing, entities & partners, product & tech, and controls – so everyone can see where value and risk live.
Execution: Build in three parallel swimlanes (product, entity/licensing, systems & controls) instead of treating compliance as a later project.
Journey: Move deliberately through six phases from idea → supervised business, wiring governance, evidence, and partners as you go.
Watchlist: Travel Rule in force since Dec 2024, MiCA stablecoin obligations applying since mid‑2024, the MiCA cut‑off in mid‑2026, plus PSD3, DAC8, AMLA, and ESMA guidance landing through 2025–2027.
Avoid: The classic anti-patterns – “fix it under MiCA later,” spreadsheet compliance, vendor Jenga, and ungoverned AI or entities.
If you’re searching for a crypto operating model, what you really care about is this: can we run a serious crypto business that a supervisor, a bank, and our own team will all trust – and can it scale beyond the first licence?
A regulated crypto operating model is simply the way your product, entities, systems, and controls fit together so that:
A supervisor can understand it and see where the risks live.
A banking partner can underwrite it without three extra committees.
Your own team can actually operate it day‑to‑day without heroics.
In practice, a solid operating model means you have:
A clear choice of licence and perimeter – which activities you do, where, and under which regime (MiCA CASP, EMI/PI, legacy VASP, DeFi wrapper, etc.).
A deliberate entity and partner map – who books what, who touches client assets, and who faces the regulator.
A coherent product and technical architecture – wallets, ledgers, and data flows you can explain on a single page.
Embedded compliance and risk systems – monitoring, reporting, governance, and evidence, not just spreadsheets taped on after the fact.
If, as you read this, you realise you don’t have that view yet, that’s what the rest of this guide is here to build with you.
Quick self‑check:
If a supervisor asked for a one‑page diagram of how your platform actually works tomorrow – where money comes in, where it sits, who controls it, and what monitors it – could you give them a version everyone internally would agree on?
Read this when you want to draw and explain how your regulated crypto business actually works. Then use the MiCA operational readiness checklist to test whether the governance, systems, and evidence behind that diagram are strong enough, and the EU CASP licensing guide when you’re ready to walk through the formal application process.
Who This Guide Is For (And What It Isn’t)
This is written for people who actually have to make a regulated crypto business work – not just talk about it.
If you’re a founder or C‑suite lead (CEO/COO/CCO/CTO) somewhere between idea on a deck and first MiCA / EMI / PI licence on the wall, you’re in the right place. Typical shapes we have in mind when writing:
A centralised exchange, brokerage, or wallet that wants to stop living as “just a VASP” and grow into a durable EU player.
A DeFi access or infra business acting as the on‑/off‑ramp or smart gateway into protocols.
An AI‑heavy crypto/fintech product – where models touch onboarding, monitoring, or decisioning, and regulation is starting to bite.
An early wealth or fund management flavour that expects a MiFID II / AIFMD coloured future even if you’re not there yet.
In other words: you already have or want real customers, real money flows, and real regulators or banking partners in the picture. You’re trying to design a crypto operating model you can explain with a straight face in the next licence meeting – and still recognise two years later when you’ve doubled the team and product surface.
If this sounds like you, read on:
You’re past “toy project” stage and feel the weight of licences, banks, and supervision.
You want a crypto operating model you can defend on a whiteboard, not just in a Notion doc.
You’d like a way to sequence the work so you don’t rebuild everything under a MiCA deadline.
Just as important is what this guide isn’t:
It’s not a clause‑by‑clause MiCA commentary or case‑law tracker – there are plenty of firms who do that well.
It’s not a legal checklist you can attach to an application and call it a day.
It’s not a generic “how blockchain works” explainer or Web3 hype piece.
Instead, this sits in between: it assumes you already take regulation seriously, and it helps you turn that into a concrete, explainable, operating model – the thing that links your licences, entities, products, data, and controls into one system.
How to use it:
Skim the whole framework once to get the mental model.
Then dip back into specific sections as you move from idea → project → business and from “we sort of know what we do” to “we can actually show how it all hangs together.”
What We Mean by “Regulated Product Architecture”
When we say “regulated product architecture,” we’re talking about the blueprint that keeps your strategy, licences, entities, product, and controls from drifting apart. It’s the operating logic of a regulated crypto platform: the way commercial intent, legal perimeter, technology, and compliance stack line up so you can move fast without blowing up the trust you need from supervisors and banking partners.
It’s helpful to picture this as four layers that sit on top of each other. They run vertically through the organisation, and when they line up, the business feels crisp; when they don’t, you spend your week firefighting.
The Four Layers of a Regulated Crypto Business
Layer 1 – Strategy & Licensing Path – This is the top‑level bet: who you serve, what journeys you enable, and which jurisdiction and licence make that legal (MiCA CASP, EMI/PI, legacy VASP, DeFi wrapper, hybrid structures). If this layer is fuzzy, everything below it inherits that fuzziness.
Layer 2 – Legal Entity & Partners – Once you know the licence path, you need entities and partners that can actually carry it. Where is the HQ? Which subsidiary books trading vs custody? Which banks, EMIs, custodians, KYC vendors, and AI tooling sit in the stack? This layer is where most “we’ll just bolt it on later” mistakes get made.
Layer 3 – Product & Technical Architecture – This is the machine people touch: wallets, order routing, internal ledgers, treasury, data flows, interfaces with DeFi or TradFi rails. It ties on‑chain components to off‑chain systems and decides how explainable (or not) you are when someone asks “where is the money right now?”
Layer 4 – Compliance & Operational Systems – Finally, the control plane: AML/CTF, transaction monitoring, sanctions, model governance, incident playbooks, reporting, audit trails. If Layers 1–3 are the engine, this is the instrumentation that proves you’re operating it responsibly.
Regulated product architecture is about designing these layers so they reinforce each other instead of fighting each other. A crisp Layer 1 decision makes your entity diagram cleaner, which makes your product architecture more defensible, which makes your compliance evidence easier to produce.
EU‑Centric, Globally Readable
Regulatory context, late 2025: MiCA is now in force in the EU (with CASP transitional regimes running into 2026), and the EU AI Act is in phased application with some obligations already live. This guide focuses on operating models rather than clause‑by‑clause law; check specific requirements and timelines with your legal and regulatory advisors.
Key dates to keep in your operating model conversations:
30 December 2024: The revised Transfer of Funds Regulation (Regulation (EU) 2023/1113) brought the Travel Rule into force for crypto transfers handled by CASPs and PSPs – by late 2025, originator/beneficiary data exchange is a baseline expectation.
30 June / 1 July 2024: MiCA’s asset‑referenced token and e‑money token chapters have applied since mid‑2024, so stablecoin issuers should already be living the reserves, governance, and disclosure discipline they were promising in decks.
1 July 2026: Last day existing EU CASPs can rely on national regimes unless their NCA cuts the transition short – several have already done it.
We work from an EU reality – MiCA timelines, EMI/PI playbooks, the EU AI Act, AML directives, Lithuanian / Irish / Spanish supervisors. But the patterns travel. If you’re building in the UK, Singapore, or the US, read “MiCA CASP” as “the licence you actually need,” and “EU AI Act” as “any regulation that will ask you how your models behave.” The operating‑model questions stay the same even if the acronyms change.
Hold this layered view in your head. In the next section we’ll switch from vertical layers to the three swimlanes you have to run in parallel (product, entity/licensing, systems & controls) to make the layers real week-by-week.
The Three Swimlanes – Idea → Project → Business
Those four layers give you a vertical stack. But execution never happens top‑to‑bottom in a neat line. In reality, the leadership team is always running three swimlanes in parallel – and the only way to move from idea → project → business without rework is to keep all three moving together. Kill one lane for a quarter and you buy yourself six months of delays later.
Think of it this way: every board meeting, every investor update, every regulator catch‑up should show progress across product, entity/licensing, and systems & controls. The detail changes as you mature, but the lanes stay the same.
Lane 1 – Product & Customers
This lane anchors everything else. It defines who you serve (retail, pros, B2B/B2B2C) and the core journeys you promise: deposit, trade, withdraw, stake, access DeFi, invest, automate treasury, etc. Without clarity here, your licence scope is guesswork and your architecture is noise.
Idea phase: Prove there’s a real customer problem, map the journeys, and document the non‑negotiables supervisors will care about (e.g., leverage, staking exposure, AI‑driven decisions).
Project phase: Turn those journeys into backlog and UX flows; decide what’s v1 vs deferred; pressure‑test pricing and liquidity assumptions against regulatory limits.
Business/live phase: Track product adoption, latency, fail states, and complaints. Feed real usage data back into the licence perimeter (“are we drifting?”) and partner contracts.
Lane 2 – Entity, Licensing & Strategic Partners
This is the legal and commercial skeleton: where you incorporate, which licences you pursue (MiCA CASP classes, EMI/PI, DeFi wrapper, MiFID add‑ons), and which partners fill the gaps (banks, custodians, EMIs, compliance vendors).
Idea phase: Set your home regulator shortlist, outline the licence path, and sketch booking models (what sits in‑house vs with partners). If you can’t explain who “touches” client assets, you’re not ready for the next lane.
Project phase: Engage advisors and regulators, prep pre‑application materials, lock draft SLAs with key partners, and design the entity chart so it matches the services you’re actually building.
Business/live phase: Finalise regulatory submissions, execute partner agreements, monitor their SLAs, and keep entity governance tight (board packs, committee cadences, capital and safeguarding calculations).
Lane 3 – Systems, Data & Controls
This lane is the glue that makes the other two credible. It covers wallets, ledgers, data models, monitoring, AI/analytics, incident playbooks, and evidence packs. Regulators don’t just want promises; they want to see the instrumentation.
Idea phase: Produce at least a napkin architecture showing wallet topology, data residency, and how you’ll separate client vs house funds. Define the telemetry you’ll need to prove compliance later.
Project phase: Build or procure the ledger/wallet stack, set up data schemas, and embed monitoring hooks (transaction monitoring, sanctions, model governance) while the product is still flexible.
Business/live phase: Operate the monitoring stack, tune thresholds, document incidents, and ensure every alert or AI decision ties back to a human owner. This is where a lot of “shadow AI” creeps in if you’re not deliberate.
If you need a concrete pattern for the monitoring side of this lane, our Crypto transaction monitoring three-layer approach walks through how to structure detection, investigation, and decision layers so your systems, data, and controls stay coherent.
Pull these three lanes together in a simple matrix: lanes as rows, stages (Idea / Prototype / Live / Scale) as columns. Fill in “what needs to be true” in each cell. That one pager becomes your steering wheel – and the checklist you bring into every investor, board, and regulator meeting.
With the lanes in view, it’s much easier to see why different business archetypes pull the lanes in different directions. That’s where we’re heading next.
Archetypes – Exchange, DeFi Access & Infrastructure, AI‑Heavy Platform, Wealth & Fund Management
Different business shapes stretch the swimlanes in different ways. You don’t need a bespoke framework for every founder conversation, but you do need to recognise the patterns. Here are the four archetypes we see most often and how their regulated crypto operating models tend to look.
Archetype 1 – Centralised Exchange / Brokerage / Wallet
Supervisors understand the model; if you can explain booking and custody clearly, you can move fast.
This is the classic MiCA CASP story: order book, brokerage, or wallet flows, usually with fiat onboarding/offboarding and a constant need for banking relationships. The operating model questions revolve around:
Product lane: Are you running an order book, brokerage, RFQ, or “simple swap” experience? Do you allow leverage or derivatives? What custody promises are you making to clients?
Entity/licence lane: Which MiCA CASP services sit in which entity? Do you layer EMI/PI permissions for fiat? Is custody carved out? How do you segregate client assets vs house in practice?
Systems/controls lane: How do wallets connect to internal ledgers? How real‑time is your reconciliation? What does transaction monitoring look like across fiat and crypto legs? Who signs off on incident response?
Typical pitfalls: running everything through a single VASP entity “for speed,” overrelying on one EMI partner, and bolting on compliance tooling after the fact. The upside is that supervisors understand this model – if you can explain your booking model and custody stack clearly, you can move fast.
Archetype 2 – DeFi Access & Infrastructure
You’re the gateway into protocols, not the protocol itself. Think staking-as-a-service, DeFi access points, liquidity routing, or infra for other fintechs – with supervisors watching closely while ESMA prepares its 2027 report on DeFi risks.
Product lane: You curate protocols, abstract complexity away, maybe provide hybrid UX (custodial + non-custodial). You need a clear view on what you are explicitly not promising: e.g., “we provide access to staking, we don’t guarantee yields.”
Entity/licence lane: Supervisors still want someone accountable. Are you a MiCA CASP providing crypto-to-crypto services? Do you wrap DeFi under a CASP or EMI umbrella? Is there a separate entity for on-chain interactions vs fiat rails? Assume NCAs will ask how you ring-fence DeFi exposure today, even before the EU decides whether to legislate further.
Systems/controls lane: You need a protocol due-diligence framework, automated risk scoring, and on-chain analytics that prove you’re not routing clients into sanctions/AML traps. Evidence packs must show how you monitor protocol changes and emergency exits, plus how you block or unwind access if a protocol falls foul of sanctions or consumer-protection thresholds.
Common failure modes: treating DeFi access as “pure software” (regulators don’t buy it), lacking a protocol risk committee, ignoring the booking implications when yields or tokens flow back into fiat accounts, or hand-waving away supervisory expectations because “MiCA doesn’t cover DeFi yet.”
Archetype 3 – AI‑Heavy Crypto / Fintech Product
Here the product is crypto-adjacent but the edge (and risk) is in AI-driven decisions: AI onboarding assistants, transaction monitoring copilots, model-driven risk scoring, AI-enabled support.
Product lane: You’re selling smarter onboarding/monitoring/UX, often overlayed on existing crypto services. You need to define which decisions AI makes vs which stay human, and how explainability works.
Entity/licence lane: You might straddle MiCA, EMI/PI, or even PSD2/MiFID obligations plus the EU AI Act, which is now in phased application. Where do the models “sit” legally? Which entity owns the data, and how do you share models across regulated entities? If a model falls into Annex III “high-risk” territory (e.g. creditworthiness, AML, or fraud), expect documentation, human oversight, and conformity assessments on top of financial rules.
Systems/controls lane: Model governance, data lineage, bias testing, access controls, human-in-the-loop processes, audit trails. When regulators ask “show me how this model was trained, tested, and monitored,” you need the binder ready – including model cards, validation reports, and AI Act risk-management evidence.
Most teams underestimate how fast the EU AI Act (and equivalent regimes) intersects with MiCA/EMI obligations. Shadow AI – models no one owns – is the recurrent anti-pattern here, and it is exactly what supervisors and the new AI Office will be probing from 2026 onwards.
Archetype 4 – Wealth & Fund Management
This is the “where we’re headed” archetype: discretionary/managed accounts, crypto wealth platforms, or hybrid funds layering crypto, stablecoins, and tokenised assets into a regulated wealth wrapper.
Product lane: Advisory vs discretionary mandates, portfolio construction, rebalancing, reporting. You need to explain how crypto exposures fit into broader wealth journeys.
Entity/licence lane: MiCA CASP may be necessary but not sufficient; you’re looking at MiFID, AIFMD, UCITS, or national wealth licences. Entity stacking matters (who’s the manager, who’s the distributor, who’s the custodian).
Systems/controls lane: Portfolio accounting meets crypto custody, tax reporting, suitability/appropriateness checks, ongoing KYC/AML for higher-touch clients.
Regulators will assume “wealth + crypto” means higher expectations around governance, capital, and reporting. Building the operating model early helps avoid the “we promised family-office grade service but built exchange-grade tech” mismatch.
These archetypes aren’t mutually exclusive; many teams blend them. The point is to recognise the pressure points each one introduces. In the next section we’ll zoom into the decisions every archetype has to make – the parts of the operating model you simply can’t outsource.
Designing the Operating Model – Decisions You Can’t Outsource
This is where the operating model stops being a nice diagram and turns into concrete, sometimes uncomfortable choices. Lawyers, advisors, and vendors can help you think – but they can’t decide, on your behalf, what you actually promise clients, where money really sits, or who owns which risk. Those are board‑ and founder‑level decisions.
You can outsource execution; you cannot outsource the logic of how your regulated crypto operating model works. Four areas matter more than anything else.
Scope of Services and Booking Model
In one line: decide exactly what you offer, who books what, and how revenue lines up with risk and capital.
The first non‑negotiable is deciding what you are really offering – and how that shows up in licences, entities, and balance sheets. Most messy operating models start with vague promises and fuzzy booking.
At a minimum, you should be able to answer, in one page:
Services in scope: Exactly which journeys a client can complete with you at launch – exchange, brokerage, staking access, custody, cards, treasury, wealth management, AI‑assisted onboarding, etc.
Negative space: What you explicitly do not do (no proprietary trading, no leverage, no advice, no yield guarantees, no self‑custody recovery, etc.). This is as important for supervisors and partners as what you do offer.
Who books what: For each flow – trade, deposit, withdrawal, staking, fee – which legal entity books the exposure and under which licence or registration. This is where Layer 1 (Strategy & Licensing) and Layer 2 (Entities & Partners) either line up or drift.
How revenue ties to risk: Where spread, commission, funding, or performance fees are recognised, and how that lines up with the risks and capital held in each entity.
Service | Entity that books it | Licence / Regime | Revenue vs risk owner |
Spot exchange (crypto ↔ crypto / fiat) | ASD Labs Markets UAB – in‑house MiCA CASP entity | MiCA CASP – exchange of crypto‑assets, execution of orders | Revenue: trading fees and spreads recognised in the CASP entity. Risk: market, operational, and conduct risk held in the CASP, backed by own funds. |
Staking access via custody partner | CustodyCo Ltd – third‑party custodian; ASD Labs Markets UAB intermediates client relationship | CustodyCo under local custody/registration; ASD Labs as MiCA CASP for crypto‑to‑crypto | Revenue: access / service fees shared between CustodyCo and ASD Labs. Risk: asset safekeeping and slashing risk at CustodyCo; conduct and disclosure risk at ASD Labs. |
EUR account & card programme | PayRails EU SA – EMI partner; client cash safeguarded at partner | EMI licence under PSD2/PSR; ASD Labs as programme partner | Revenue: interchange / card and FX fees shared under EMI programme agreement. Risk: safeguarding, fraud, and payment compliance risk at EMI; distribution and reputational risk at ASD Labs. |
Treasury & house liquidity management | ASD Labs Treasury Ltd – non‑client house entity | Local corporate / investment firm regime as applicable | Revenue: treasury P&L (FX, spreads, yield) in house entity. Risk: market and liquidity risk in house entity; must be ring‑fenced from client balances. |
If you can’t draw that map, you don’t have a crypto operating model yet – you have a marketing plan. Regulators, banks, and even sophisticated clients will eventually ask some version of:
“For this specific service, which entity is my counterparty, under what licence, and where does my money sit while I’m using you?”
Your answer needs to be the same in the product deck, the terms and conditions, the internal ledger, and the CASP/EMI/PI application.
For example: a retail exchange + staking access + cards set‑up might look like this on paper – a MiCA CASP entity booking trading and fee income, a specialist custody partner handling staking flows, and an EMI partner issuing cards and safeguarding fiat. The client contracts and booking model are explicit for each service, and everyone can see where risk and revenue actually sit.
Wallets, Ledgers, Accounts: Where the Money Really Lives
In one line: make it obvious where client money lives across wallets, ledgers, and bank accounts – and how you prove it every day.
Once you know who promises what to whom, the next decision is where the value actually lives in the stack. This is the part of the regulated crypto operating model that makes supervisors lean in and banking partners either relax or walk away.
A useful way to think about it is three layers:
On‑chain wallets – hot/warm/cold, client vs house, segregated vs omnibus, MPC vs HSM vs hardware. This is what blockchain explorers see.
Off‑chain ledgers – internal balance sheets and sub‑ledgers that represent client positions, P&L, and fees. This is what your finance and risk teams see.
Banking and payment accounts – safeguarded client fiat, operational accounts, settlement accounts with EMIs or banks. This is what traditional rails see.
Your operating model decisions here include:
How you segregate client vs house assets at the wallet and ledger level – not just in policy, but in actual address schemes and account structures.
How often and by whom reconciliations are run between these three layers, and what happens when something doesn’t match.
Which third parties (custodians, EMIs, banks, wallet providers) you rely on and what they can and cannot do with your clients’ assets.
How Travel Rule data capture and exchange (Regulation (EU) 2023/1113) is wired into those flows so that originator/beneficiary information follows the funds without manual patchwork.
A quick self‑check:
Can you point to a diagram that shows, for a single €10,000 deposit, exactly which wallets and accounts it touches from bank to protocol and back?
If a hot‑wallet provider or EMI went down for 48 hours tomorrow, do you know which clients and services are affected, and what your playbook is?
If the answer is “not really,” this is where to spend architecture time. The same regulators reading your MiCA application have also read too many enforcement files about sloppy wallet and ledger design. They will mentally benchmark you against those cases even if they don’t say it aloud.
Governance, People, and Decision‑Making
In one line: decide who can say yes or no to changes that move risk, money, or accountability.
An operating model is not just systems; it’s also who gets to say yes or no when something important changes. This is where many otherwise decent architectures fail MiCA‑grade scrutiny – the deeper questions supervisors now ask about governance, systems, and evidence. The structure exists on paper, but no‑one clearly owns key decisions.
Regulators are explicit about this. The FSB crypto-asset recommendations – especially Recommendation 4 – call for crypto providers to run a “comprehensive governance framework” with clear accountability, the EBA and ESMA internal-governance guidelines extend board duties and independent oversight to CASPs, and most NCAs apply a “four-eyes” principle that forces at least two fit-and-proper managers to jointly direct the business. The upcoming EU AML Authority (AMLA) will also have powers to hold individual board members responsible for AML programmes in significant cross-border groups.
In practice, you need to decide:
Who owns the operating model internally – usually a combination of CEO/COO and a strong CCO/MLRO, with clear remits for product and risk.
How the board and committees will actually engage with product, entity, and systems decisions (new services, new jurisdictions, new vendors, AI pilots) rather than just noting them.
How you evidence the “**four-eyes**” management principle and independent challenge – which senior managers jointly run the business, who chairs risk/audit committees, and how independent non-executives exercise oversight.
What is acceptable in terms of capacity and seniority for key function holders. A “0.1 FTE MLRO plus two overworked engineers” may get you incorporated, but it will not carry you through a serious CASP/EMI review.
Signals of a healthy governance operating model:
There is a simple governance map showing who decides what for each layer and lane – product, licensing/entity, systems & controls.
Major changes (new asset, new protocol, new card programme, new AI tooling) follow a documented approval path with risk and compliance input before, not after, launch.
The MLRO and risk/compliance leads have direct access to the board and enough time and staff to run their programmes, and their reports are formally minuted.
Independent directors or advisors provide documented challenge through risk, audit, or compliance committees, and you can show how their input closes the loop on key decisions.
Regulators are pragmatic about early‑stage resource constraints, but they have seen enough “letterbox entities” to be sceptical. If your operating model depends on people who don’t exist yet or can’t realistically do the job, that is a decision problem, not a hiring problem.
Partners and Vendors – Building a Stack, Not a Frankenstein
In one line: treat vendors as components in your architecture, not your architecture itself.
Almost every serious crypto operating model leans on partners: banks and EMIs, custody providers, KYC and monitoring vendors, on‑chain analytics, cloud and AI platforms. The decision you can’t outsource is how these pieces fit together as a system you can explain and control.
Useful questions when choosing and combining vendors:
Architecture fit: Does this vendor plug into your existing data model and workflows, or will it become a hard‑to‑untangle side system? How will events and decisions flow back into your core ledger and monitoring?
Transparency and explainability: Can you understand and document how the tool makes decisions (especially for AI‑enabled products), so you can defend it to supervisors and clients?
Jurisdiction and resilience: Where is the vendor regulated, where is data stored, and what is your plan if they have an outage or exit the market?
Exit paths: If you needed to migrate away in 12–18 months, what data would you get back, in what format, and how painful would that be?
Outsourcing registers: Under the EBA Outsourcing Guidelines and the Digital Operational Resilience Act (DORA), you need an up-to-date inventory of critical/important functions, exit strategies, and concentration-risk assessments that supervisors can inspect on request.
A simple way to force clarity is to build a build‑vs‑buy matrix for your operating model:
What do we absolutely own in‑house? (Core ledger, risk appetite, governance, key client relationships.)
What do we configure and orchestrate using vendors? (KYC stack, transaction monitoring, on‑chain analytics, parts of custody.)
What do we treat as utilities and consciously depend on? (Cloud, some payment rails.)
Write this down. Without it, you end up with vendor Jenga – ten tools piled on top of each other with no clear architecture – and you still own all the risk.
Taken together, these four decision areas form the backbone of your regulated crypto operating model. In the next section, we’ll look at how to sequence them over time – a six‑phase journey from idea to regulated business so you’re not trying to decide everything at once in a CASP deadline panic.
A Six‑Phase Journey – From Idea to Regulated Business
So far we’ve looked at your regulated crypto operating model as a static picture – layers, swimlanes, key decisions. Real teams don’t build that picture in one go; they move through a handful of predictable phases, making different kinds of progress in each lane.
Think of this as a journey map you can put on a wall for your founders, board, and early hires. The point is not to make every phase perfect before you move on. The point is to be honest about where you are, what should be true in each lane, and what you’re deferring on purpose rather than by accident.
Phase 0 – Sanity‑Check the Idea Against Regulation
Before you fall in love with the product deck, spend 2–3 weeks checking whether the idea is even buildable inside EU rules. This is where a lot of avoidable pain gets killed early.
In this phase, you want to:
Place the idea on the regulatory map: are you clearly in MiCA CASP territory, on an EMI/PI track, brushing up against MiFID/AIFMD, or trying to do something no supervisor will touch?
Sketch a first pass at licence scope – which services you’d need authorised for the journeys you have in mind.
Identify any hard red flags (e.g. uncollateralised retail leverage without a MiFID wrapper, business models that rely on magic AML exemptions).
Build a short list of candidate home states and supervisors you could credibly live with.
You’re not writing annexes yet. A few focused conversations using your EU crypto regulation overview and MiCA/EMI primers is enough. The goal is to avoid designing a beautiful operating model for something that will never get past a serious NCA.
If you’re here, focus on:
Getting one clear regulatory story for what you want to do.
Killing ideas that obviously won’t fly before you invest in product or entities.
Writing down the candidate home states and licence path in one short note.
If, in this phase, you realise you need the full picture of how a CASP licence works – services, home state, timelines, and supervisory expectations – this is where our EU CASP licensing guide takes over. Treat this article as the operating‑model lens, and the CASP guide as the legal and process lens you read alongside it.
Phase 1 – Concept & Customer Backlog (Idea → Project)
Once the idea passes the basic smell test, Phase 1 is about anchoring it in customer reality while keeping the other lanes moving just enough not to trap you later.
What “good enough” looks like here:
Lane 1 – Product & customers: You can name your core customer segments, the problems you solve for them, and the handful of journeys you’ll support in V1 (deposit, trade, stake, treasury, access DeFi, etc.).
Lane 2 – Entity & licensing: You have a strawman jurisdiction and licence path (e.g. “MiCA CASP in country X plus EMI partner in country Y”), with rough thoughts on which entities might do what.
Lane 3 – Systems & controls: You have at least a napkin architecture: boxes and arrows for wallets, ledgers, banking partners, data stores, and monitoring. It doesn’t need vendor names yet, just flows.
The main output from Phase 1 is a concept pack and backlog: a short document and a first cut of user stories that your future Strategy & Architecture Sprint can use as raw material.
If you’re here, focus on:
Being ruthless about which customer journeys are really V1.
Keeping a live list of regulatory assumptions you’ll test in the next phase.
Sketching at least a napkin architecture everyone on the leadership team recognises.
Phase 2 – Strategy & Architecture Sprint
Phase 2 is where you turn a promising concept into a deliberate operating model. This is typically a 3–6 week structured sprint that pulls leadership, product, compliance, and engineering into the same room (or at least the same Miro board).
By the end of this phase, you should have:
A target operating model across the four layers – strategy/licensing, entities & partners, product/tech, systems & controls – that you can draw on one or two pages.
Clear decisions on the non‑outsourcable choices from the previous section: scope of services, booking model, wallet and ledger patterns, governance design, and partner strategy.
A 90‑day executable roadmap that connects the picture to concrete work: what you build, what you buy, what you defer.
An initial view of risk and compliance posture: what policy and control stack you’ll need to be credible with banks and supervisors by the time you file.
This is also where a Strategy & Architecture Sprint offering fits naturally if you want external structure. But even if you run it entirely in‑house, treat Phase 2 as a distinct, named piece of work – not something you try to “squeeze in” between feature sprints.
If you’re here, focus on:
Coming out with a single, agreed operating model diagram – not three versions.
Forcing decisions on scope, booking, wallets, and governance instead of parking them.
Producing a realistic 90‑day plan you can actually resource.
Phase 3 – Build & Partner Lock‑In
With a target operating model and roadmap in hand, Phase 3 is where you turn boxes and arrows into running systems. The risk here is building fast but ignoring the operating model until a MiCA deadline looms. The healthier pattern is to wire the three lanes together as you go.
In practice:
Product & customers: You build the core journeys to a level where real users (or design partners) can run through them end‑to‑end.
Entity & licensing: You incorporate entities, advance early regulatory conversations, and negotiate heads of terms with key partners (EMIs, custodians, banks, KYC and monitoring vendors) in ways that match your booking model.
Systems & controls: You implement the first version of your wallet and ledger stack, KYC/AML and transaction monitoring, and basic governance artefacts (runbooks, reconciliations, incident channels) while the product is still flexible – including wiring Travel Rule messaging so crypto transfers are compliant with the regime that has applied since 30 December 2024.
Two practical rules of thumb for this phase:
If you can’t reconcile a day of activity across wallets, ledgers, and bank accounts before you go live, you’re not done yet.
If your monitoring and evidence plans are still PowerPoint bullets, you’re not done yet either, no matter how pretty the app looks.
Week to week, this often looks like a standing leadership review where product demos, entity/licensing progress, and systems/controls (reconciliations, alerts, incidents) are walked through together. If one lane is racing ahead while another is stuck, you stop and rebalance before the gap turns into a MiCA‑grade problem.
If you’re here, focus on:
Wiring wallets, ledgers, and banking so you can reconcile early and often.
Locking in partners on terms that match your booking and risk model.
Embedding at least a minimal monitoring and evidence loop before launch.
Phase 4 – Licensing & Readiness
Phase 4 is when you turn the operating model and the early build into something you can defend in front of a supervisor. For most teams this is the first time the whole story is written down end‑to‑end.
Here, you:
Freeze a version of the operating model that will go into your MiCA CASP / EMI / PI application – including services in scope, entity chart, booking model, and key systems.
Run a structured operational readiness check – using your MiCA operational readiness / compliance checklist – to see where governance, systems, controls, and evidence are weak before you file.
Fill priority gaps: missing policies and SOPs, under‑documented custody and segregation, weak incident and escalation flows, thin governance evidence.
Assemble your application and evidence packs: Program of Operations or equivalent, policy suite, architecture diagrams, board minutes, monitoring examples, outsourcing files.
If you’ve done the earlier phases well, this is mostly a hard but manageable documentation and tightening exercise. If you’ve skipped them, Phase 4 turns into a chaotic rewrite of your business under deadline pressure.
If you’re here, focus on:
Freezing a version of the operating model you’re willing to defend.
Closing the most material governance, control, and evidence gaps before filing.
Making sure your application story matches how the platform actually works.
Phase 5 – Scale & Iterate
Getting the first licence or going live is not the end of the journey; it’s the point where weaknesses in your operating model usually show up. Phase 5 is about scaling without losing the plot.
Concrete work here includes:
Tracking a small set of operating metrics across product, risk, and operations that actually tie back to your risk appetite and regulatory story (not vanity KPIs) – think STR throughput, alert investigation timelines, customer outcomes, and system resilience, not just revenue.
Knowing when to split entities or licences – for example, carving out custody, separating B2C from B2B, or adding a second MiCA/EMI hub as volumes and risk concentrations grow.
Re‑platforming or refactoring parts of the stack (wallets, ledgers, monitoring, AI tooling) in a controlled way rather than via emergency projects.
Tightening governance and committees as the organisation matures: clearer risk and product approval processes, more deliberate use of internal audit or external reviews.
Most “we’ll fix it under MiCA later” anti‑patterns come from trying to jump from Phase 1 or 2 straight to Phase 4 and 5. The phases don’t need to be perfectly sequential, but being explicit about where you are – and what you’re skipping – makes the risks a choice rather than a surprise.
If you’re here, focus on:
Defining a small set of operating metrics that really move with risk and customer outcomes.
Knowing when to split entities, licences, or platforms before they become single points of failure.
Refactoring parts of the stack in controlled, well‑governed projects, not emergencies.
Regulatory watchlist – 2025 to 2027
Operating models are never static. Even after MiCA and the EU AI Act go live, the rulebook stretches over the next 24–30 months. Keep these items on the radar while planning roadmaps and budgets:
MiCA Level 2 standards: ESMA and the EBA are finalising the MiCA technical standards on custody, complaints, white papers, and prudential reporting through 2025 via successive ESMA MiCA technical standards consultations. Expect tweaks to evidence packs as those RTS/ITS land.
National transitional regimes: NCAs can shorten or end the MiCA grace period at any time. Track your home state’s stance and whether passporting states expect new filings earlier than July 2026.
AMLA direct supervision: Regulation (EU) 2024/1620 establishing AMLA creates the EU Anti-Money Laundering Authority, which will directly supervise the riskiest cross-border CASPs from 2026. Design MI and governance assuming EU-level inspections, not just local ones.
PSD3 and the Payment Services Regulation: The upcoming PSD3/Payment Services Regulation package will harden IBAN/name-matching and anti-fraud obligations for payment flows. If your operating model includes fiat rails or cards, align crypto transfers and Travel Rule tooling with those expectations now..
DAC8 crypto tax reporting: DAC8 – Directive (EU) 2023/2226 – will require CASPs from 2026 to report customer holdings and transfers to tax authorities. Make sure your data model and client onboarding capture the identifiers DAC8 requires.
NFT classification guidance: Fractionalised or fungible NFTs may fall back into MiCA or securities rules once the Commission clarifies the test. Keep product taxonomies flexible.
Market integrity standards: ESMA is preparing detailed guidance for MiCA’s market abuse regime by end-2025. Trading venues and brokerages should level up surveillance before those expectations arrive.
Stablecoin intervention triggers: ECB and national central banks can intervene when significant ART/EMT thresholds are met. Treasury and liquidity teams need playbooks for issuance caps or reserve uplifts.
In the next section we’ll look at the common architecture anti‑patterns that show up when teams ignore this journey map – and how to avoid inheriting problems you’ll be unwinding for years.
Common Architecture Anti‑Patterns (And How to Avoid Them)
Even with a clear regulated crypto operating model and journey map, most teams will recognise themselves in at least one of the patterns below. That’s normal. The problem is not that these anti‑patterns appear; it’s that they sit in the background unchecked until a supervisor, bank, or investor forces a painful rewrite.
Use this section as a frank self‑diagnostic. If one of these sounds like you, don’t panic – we’ve added practical ways to course‑correct.
“We’ll Fix It Under MiCA Later” Architecture
You see this in decks that say “we’ll start as a simple VASP and upgrade later under MiCA/EMI/PI,” while the actual design bakes in assumptions that will never survive that upgrade. On paper it sounds agile. In practice it means you are building a house on the wrong foundations and promising to move it, fully furnished, in a storm.
Typical signs:
A single, over‑stretched VASP entity doing everything – exchange, custody, DeFi access, treasury – with no clear plan for how those services split when you need CASP/EMI/PI‑grade segregation.
Wallet and ledger structures that don’t distinguish house vs client assets, because “we’ll re‑platform the custody stack once we have more volume.”
Governance and key function holders who are explicitly hired as “VASP‑grade for now, we’ll build a proper team under MiCA” – i.e. just enough to scrape through a light‑touch registration, nowhere near enough for a full CASP review.
Regulators see the same movie. In its July 2023 MiCA preparatory statement, the EBA warned stablecoin issuers to “take timely preparatory actions” ahead of MiCA to avoid disruptive rebuilds – a polite way of saying the upgrade must start now, not the quarter before the licence deadline.
The fix is not to file for every licence on day one. The fix is to design from the end state backwards, even if you implement in stages:
Sketch the future CASP/EMI/PI architecture and entity stack you want three years from now, then consciously decide which layers you can safely defer.
Build wallet, ledger, and segregation logic as if you already had to evidence it to a CASP supervisor, even if today you only report as a VASP.
Treat early governance and key roles as seed versions of the future state, not disposable placeholders.
If you do this well, the MiCA “upgrade” will feel like turning up the resolution on a picture you already have – not drawing a new one from scratch while the business is running.
If this pattern feels uncomfortably familiar, it’s a good moment to run your MiCA operational readiness checklist against the current set‑up. If you can’t honestly tick most of the boxes on governance, systems, and evidence without major rebuilds, you’re already in “we’ll fix it later” territory.
Compliance as a Side Spreadsheet
Another familiar pattern: the legal and compliance work lives in neat folders and spreadsheets; the actual product and data flows live somewhere else entirely. Everyone insists they are “aligned,” yet whenever something breaks, no‑one can find evidence that the documented process was ever real.
Typical signs:
Policies and SOPs that read well but never mention your actual assets, channels, or vendors.
Controls that are “performed” by updating a spreadsheet once a quarter, with no link back to real system logs or events.
Staff who learn how things really work from Slack and tribal knowledge, not from the documents you send to advisors and supervisors.
To get out of “side spreadsheet” mode, you need to re‑anchor compliance in how the platform actually behaves:
For each major policy (onboarding, transaction monitoring, custody, incidents), map where in the stack the control lives: which system, which queue, which field, which log.
Turn key controls into data‑backed checks, not manual declarations – for example, sampling alerts or reconciliations directly from tools rather than from recollection.
Build a simple evidence catalogue: for every high‑impact control, know which report, dashboard, or export proves it’s happening.
The UK FCA’s Strategy 2025–2030 is blunt about the stakes: firms that rely on weak management information and manual processes “continue to drive consumer harm.” Supervisors across the EU share that view – if your data lives in ad-hoc spreadsheets, they will assume the control is failing.
Supervisors are increasingly fluent in systems and data. They will believe what your logs and dashboards show more than what your policy PDFs say. Your regulated crypto operating model needs both – but they have to match.
Vendor Jenga – Ten Tools, No Architecture
Crypto and fintech stacks lend themselves to impressive vendor diagrams: dozens of logos across KYC, monitoring, custody, analytics, AI, and cloud. The anti‑pattern is when those logos become the de facto “architecture,” with no clear sense of which system is the source of truth and how decisions move through the stack.
Typical signs:
You need three different dashboards open to explain a single client flow or incident.
No‑one can say with certainty which ledger or data store is authoritative for balances or risk decisions.
When a vendor changes pricing, terms, or features, the impact analysis is guesswork because there’s no central view of dependencies.
Avoiding vendor Jenga doesn’t mean going vendor‑free. It means treating vendors as components in your architecture, not the other way around:
Start from a simple architecture diagram that names one system of record for key concepts (clients, balances, transactions, alerts) and shows how other tools read from or write to it.
Design around a small number of event and data flows – for example, “client onboarded,” “transaction created,” “alert escalated” – and make sure vendors plug into those flows rather than inventing their own parallel ones.
Periodically run a vendor rationalisation review: which tools are critical, which overlap, which can be simplified or insourced as you mature.
If you can’t explain your stack on one page without listing brand names, you don’t have an operating model; you have a shopping list. Regulators and banks have learned to tell the difference.
DORA will make that judgment formal: you need to show concentration-risk assessments and exit strategies for critical ICT providers, and RegTech analyses such as Flagright on vendor sprawl show why – fintechs commonly juggle 20+ overlapping vendors, paying for unused features and introducing operational blind spots.
Shadow AI and Shadow Entities
Finally, the most contemporary anti‑pattern: decisions and structures that quietly appear in the shadows. Shadow AI is any model making meaningful decisions without clear ownership or governance. Shadow entities are legal structures or booking practices that no single person can fully explain.
Typical signs on the AI side:
Teams experimenting with LLMs or scoring models in production flows “just to help the analysts,” with no documentation of what the model does or which data it touches.
No central model inventory; no‑one can answer “how many models do we actually use in onboarding/monitoring/support?”
Alerts, approvals, or risk scores that are obviously influenced by AI, but the last human in the chain could not reconstruct why a decision was taken.
Under the EU AI Act, many of those models will be treated as high-risk systems, which makes the absence of documentation or human oversight a regulatory breach, not just an operational quirk.
On the entity side:
Balance sheet items or client flows that are “temporarily” booked in whichever group entity was easiest to set up.
Cross‑border arrangements that grew organically from commercial deals, not from a planned entity and licensing map.
No up‑to‑date diagram showing which entity is the client’s contractual counterparty for which service.
The cure is bringing both AI and entities back under the same governance and operating‑model lens as everything else:
Maintain a live model register: for each model, know its purpose, owner, data inputs, key risks, and how it is tested and monitored. Tie this into your EU AI Act and MiCA/EMI governance work.
Require any AI‑in‑the‑loop process to have a named human owner and a documented escalation path. If no one can sign their name under an AI‑driven decision, it shouldn’t be in production.
Consolidate your entity view: one diagram, reviewed at least annually, that shows which services, licences, and booking models belong where – and use it as a gatekeeper for new products and deals.
None of this is about killing experimentation or agility. It’s about making sure that when an NCA, bank, or investor asks “who is really in charge here?” you can point to a coherent answer rather than a collection of clever hacks.
How We Work With Teams on Regulated Product Architecture
If you’ve read this far, you probably recognise at least parts of your own platform in the layers, lanes, phases, and anti‑patterns. For some teams, this guide is enough to run an internal project. Others prefer a structured partner who has already lived through a few MiCA/CASP and EMI/PI journeys and can help make decisions faster.
We usually work with founders and leadership teams in two modes.
Strategy & Architecture Sprint – from idea → project
This is a focused, time‑boxed engagement for teams who are somewhere between “strong concept” and “serious build,” and want a crisp regulated crypto operating model before committing real money and reputation.
Over a few weeks, we work with your CEO/COO/CCO/CTO and key product and compliance leads to:
Turn your vision and back‑of‑deck ideas into a target operating model across the four layers: strategy/licensing, entities & partners, product/tech, and systems & controls.
Make the hard calls on scope of services, booking model, wallet and ledger patterns, governance shape, and partner strategy.
Map your concept into the three swimlanes and six phases, so you know what “good enough” looks like now vs what belongs in later phases.
Produce a concrete 90‑day execution plan you can plug into your roadmap and use with advisors, regulators, and banking partners.
You leave with a regulated crypto operating model you can draw on one page and defend in your next board, investor, or supervisor conversation – not just another memo.
Operational Architecture Build‑Out – from project → business
Once the operating model is defined, the real work is turning it into systems, data flows, controls, and evidence that survive contact with regulators and growth. That’s where the Operational Architecture Build‑Out comes in.
Here we work alongside your product, engineering, and compliance teams to:
Implement or refine the wallet, ledger, and banking architecture so fund segregation and reconciliation work in practice, not just in diagrams.
Design and embed the KYC/AML, transaction monitoring, sanctions, and model‑governance stack that matches your risk profile and supervisory expectations.
Build the governance, policy, and evidence backbone – the meeting rhythms, control registers, and documentation that sit behind your MiCA CASP / EMI / PI applications.
Translate all of this into the operating‑model narrative and artefacts you’ll need for applications, due diligence, and internal decision‑making.
Most of this work happens with your existing advisors and vendors in the loop; the goal is not to replace them, but to make sure everyone is building against the same regulated product architecture rather than their own local view.
If you’d like help applying this to your own platform, we’re happy to start with something small – a quick read of your current architecture, MiCA/EMI plans, or evidence pack – and tell you honestly whether a Strategy & Architecture Sprint or Operational Architecture Build‑Out would actually move the needle. If not, you still walk away with a clearer view of your regulated crypto operating model and the next few decisions to make.
FAQs: Regulated Crypto Operating Models
What is a “regulated crypto operating model” in simple terms?
A regulated crypto operating model is the way your products, legal entities, systems, and controls fit together so you can run a crypto business that regulators, banks, and your own team can trust. It links what you promise clients to how money, risk, and decisions actually move through wallets, ledgers, accounts, and governance.
Why does my crypto platform need a regulated operating model at all?
You need a regulated operating model because regulators do not just authorise activities; they authorise how you run them. A clear operating model shows who your clients contract with, where their money sits, how you monitor risk, and who decides what. Without that, licences, bank accounts, and scale usually stall or break under scrutiny.
What’s a simple example of a regulated crypto operating model for an EU exchange?
One common pattern is a MiCA CASP entity that runs exchange and brokerage services, supported by a separate custody provider and an EMI or bank for fiat rails. Client funds are segregated in specific wallets and safeguarded accounts, internal ledgers mirror those positions, and governance committees approve new assets, protocols, and vendors against a documented risk framework.
How do I document my regulated crypto operating model (for a deck or PDF)?
Start with a one‑page diagram that shows your four layers (strategy and licences, entities and partners, product and technical stack, compliance and operations). Then add a simple table for the three swimlanes – product, entity/licensing, and systems & controls – describing what must be true at idea, project, and live stages. That combination usually becomes the backbone of your “operating model” deck or PDF.
Does my crypto operating model need to change for different countries and licences?
The core logic of your crypto operating model should stay stable – how you separate client and house assets, how decisions are made, and how evidence is captured. What changes by country is which entity holds which licence, how services are booked, and which local rules you map onto the same architecture. Designing from a multi‑jurisdiction end‑state makes those adaptations much easier.
When should we design the operating model – before or after we apply for a MiCA, EMI, or PI licence?
You will get a better outcome if you design the operating model before you file. Supervisors expect your application to reflect a coherent view of services, entities, systems, and controls, not just a legal checklist. Treat the operating model as a Phase 2–3 deliverable (Strategy & Architecture Sprint plus early build), then use Phase 4 to refine and evidence it for the actual MiCA, EMI, or PI application.
Comments