MiCA CASP Compliance App: Build for EU Crypto Rules
AI Summary: A MiCA CASP compliance app must match its crypto-asset services to an authorised entity or other permitted regulatory route. EU teams need to connect onboarding, custody, asset segregation, transaction monitoring and Travel Rule workflows to that service scope. Product architecture should establish who holds the authorisation before treating a technology integration as market access. |
Since 1 July 2026 there is no grandfathering left for crypto businesses serving EU customers. The transitional period in Article 143 of the Markets in Crypto-Assets Regulation (MiCA) has ended, and ESMA has said that unauthorised providers must stop onboarding EU clients and wind down in an orderly way. If you are building a crypto app for Europe now, the question is no longer whether MiCA applies, but which crypto-asset services your app performs and who holds the authorisation for them.
This guide is for founders and product teams building an EU crypto app: a buy/sell app, a wallet with custody, a brokerage-style interface, or a crypto feature inside an existing fintech. It focuses on turning MiCA's Title V requirements for crypto-asset service providers (CASPs) into product scope, architecture and compliance features. It is not a multi-country exchange licence roundup; if you need to compare regimes across markets, start with our licensing overview below and our list of crypto app development companies in the US for the US side. For licences across markets, see our Fintech Licensing Requirements 2026 guide.
MiCA CASP compliance app: Is your app providing a crypto-asset service?
MiCA regulates specific crypto-asset services. Your first job is to map each feature in your app to those services, because the mapping drives the authorisation you need, the capital class and most of your compliance backlog. The legal text is Regulation (EU) 2023/1114 on EUR-Lex; ESMA's interactive single rulebook is easier to navigate article by article.
App feature | Likely MiCA crypto-asset service | Build implication |
Holding customer keys or balances on their behalf | Custody and administration of crypto-assets | Client-asset ledger, segregation, custody policy, statements |
Buy/sell crypto with euros or cards | Exchange of crypto-assets for funds | Pricing methodology, commercial policy, fiat safeguarding |
Swap one token for another | Exchange of crypto-assets for other crypto-assets | Same pricing and policy controls, liquidity routing |
Routing customer orders to venues | Execution of orders or reception and transmission of orders | Execution policy, order records, best-execution evidence |
Send and receive crypto for customers | Transfer services for crypto-assets | Travel Rule messaging, self-hosted wallet checks |
Order book matching between users | Operation of a trading platform | Operating rules, market abuse surveillance (highest class) |
Model portfolios or recommendations | Portfolio management or advice on crypto-assets | Suitability, staff knowledge and competence evidence |
Token launch distribution for issuers | Placing of crypto-assets | Issuer agreements, conflicts management |
Not every crypto product is a regulated service. Pure non-custodial wallet software, analytics or developer tooling may sit outside the CASP perimeter, but the line depends on facts like who controls keys and who executes orders. Get a legal opinion on your feature map before you freeze scope, and design the app so features can be switched on per jurisdiction and per permission.
Service classes and prudential safeguards
Annex IV of MiCA groups services into three classes for permanent minimum capital:
Class | Services included | Permanent minimum capital |
Class 1 | Execution of orders, placing, transfer services, reception and transmission of orders, advice, portfolio management | EUR 50,000 |
Class 2 | Any class 1 service plus custody and administration, exchange for funds and/or exchange for other crypto-assets | EUR 125,000 |
Class 3 | Any class 2 service plus operation of a trading platform | EUR 150,000 |
Under Article 67, the prudential safeguard is the higher of that Annex IV amount or one quarter of the previous year's fixed overheads, reviewed annually. New CASPs use projected overheads from their application. The safeguard can be own funds, an insurance policy or comparable guarantee, or a combination.
For product teams this matters in two ways. First, adding custody or fiat on-ramps moves you from class 1 to class 2, so scope creep has a capital cost. Second, the overhead-based calculation means your engineering and operations budget feeds directly into the capital you must hold. Finance and product should model both together.
Three routes: own CASP, Article 60 entity or partner CASP
Article 59 says nobody may provide crypto-asset services in the Union unless they are an authorised CASP or one of the financial entities allowed to provide them under Article 60. That gives most app builders three practical routes.
Route | Who holds the permission | What you need | Best for | Trade-offs |
Own CASP authorisation | Your EU entity | Application under Article 62, registered office in a Member State, effective management in the Union, at least one EU-resident director, prudential safeguards | Full control of product, pricing, custody and passporting | Long preparation; ongoing governance, audit and capital burden |
Article 60 notification | Your existing regulated firm (for example a credit institution, investment firm or EMI) | Notification to your competent authority with programme of operations, AML/CFT, ICT, segregation and custody documentation | Banks, brokers or EMIs adding crypto to an existing app | Only within the limits Article 60 sets for your entity type |
Partner with an authorised CASP | The partner CASP | Commercial and outsourcing agreements, clear split of regulated and unregulated activities, brand and UX ownership | Fintechs adding crypto features quickly | Partner concentration, change control, revenue share and data access sit with the CASP |
Authorised CASPs can provide services across the Union through establishment or the free provision of services, so one authorisation can support a multi-country app once passporting notifications are done. Partner arrangements need the same care we describe in our License-as-a-Service guide: your app must not drift into performing services that your agreement says the partner performs. Article 59(5) also prohibits non-CASPs from marketing themselves in a way that suggests they are a CASP, which affects your copy, onboarding screens and app-store listing.
Before signing with a partner, check it on ESMA's interim MiCA register and confirm which services and Member States its authorisation actually covers.
The authorisation clock and what the application asks for
Article 63 sets statutory clocks: written acknowledgement within 5 working days, a completeness check within 25 working days, and a reasoned decision within 40 working days of a complete application. The assessment can be suspended while the authority waits for additional information. In practice the long pole is producing an application that is complete and credible, not the statutory clock itself.
The application and the Article 60 notification list overlap heavily, and much of it is technical. Expect to produce a programme of operations, AML/CFT controls and risk assessment, business continuity, technical documentation of ICT systems and security arrangements with a non-technical description, the procedure for segregating client crypto-assets and funds, a custody policy where relevant, pricing methodology for exchange services, an execution policy, and how transfer services will work (Article 60 shows the full list). If the software does not exist yet, you are describing it in advance and the supervisor may hold you to it.
What MiCA turns into software
Programme of operations becomes a service catalogue
Build a permissions layer that knows which services are authorised, in which Member States, for which customer types. Every feature flag should reference that catalogue, so launching a new swap pair or a new country is a configuration change with an audit trail, not a code change nobody can explain to a supervisor.
Safekeeping becomes a client-asset ledger
Article 70 requires CASPs that hold client crypto-assets or funds to protect client ownership rights, prevent use of client assets for their own account, and place client funds (other than e-money tokens) with a credit institution or central bank in separately identifiable accounts. In product terms you need a double-entry ledger that separates client and house positions, ties each client balance to on-chain addresses and bank accounts, and reconciles both continuously.
Custody becomes a register of positions
For custody and administration, Article 75 requires a client agreement, a register of positions per client, a custody policy, regular statements and segregation of client holdings from your own, including identifiable addresses on the ledger. Decide early whether you will run omnibus or per-client wallets, how you split hot and cold storage, and how your key-management provider evidences segregation.
Conduct rules become UX and workflow
Disclosures, complaints handling, conflicts of interest, pricing methodology and execution policies all show up as screens, logs and admin tooling. Store which version of a disclosure or policy each customer saw, and when.
DORA becomes your ICT operating model
CASPs are in scope of the Digital Operational Resilience Act. Expect ICT risk management, incident classification and reporting, resilience testing and a register of third-party ICT providers. Your cloud, custody and KYC vendors all belong in that register.
Travel Rule: the feature most crypto apps underestimate
The EU Transfer of Funds Regulation, Regulation (EU) 2023/1113, requires originator and beneficiary information to accompany crypto-asset transfers between CASPs. The EBA's Travel Rule Guidelines explain how to detect missing information and handle self-hosted addresses.
What that means in the app:
Counterparty detection. Before sending, determine whether the destination is another CASP or a self-hosted address, using analytics, messaging-network identifiers or customer input.
Data exchange. Send and receive originator and beneficiary data through a Travel Rule messaging solution, and match inbound data before crediting funds.
Self-hosted wallets above EUR 1,000. For transfers over EUR 1,000 to or from a self-hosted address, you must assess whether the address is owned or controlled by your customer. The EBA guidelines describe methods such as a signed message or a small test transfer. Build those flows into withdrawal and deposit UX rather than bolting on email requests.
Hold, return or reject. Inbound transfers missing required data need a quarantine state, case management and a decision log.
Teams that already built crypto checkout flows, like those in our crypto payment gateway guide, usually need to add this layer before going live in the EU.
Reference architecture
Layer | Components | MiCA / TFR concern |
Channels | iOS, Android, web, partner APIs | Disclosures, marketing rules, per-country feature flags |
Identity | KYC/KYB, sanctions and PEP screening, risk scoring | AML/CFT programme, ongoing monitoring |
Ledger | Double-entry client and house ledger, fee engine | Segregation, register of positions, statements |
Custody | MPC or HSM key management, hot/warm/cold policies, address book | Custody policy, segregation on-chain, recovery |
Trading | Quote engine, liquidity connectors, order management | Pricing methodology, execution policy, order records |
Fiat | Bank accounts for client funds, SEPA, card acquiring | Client funds with credit institution, reconciliation |
Compliance | Blockchain analytics, Travel Rule messaging, transaction monitoring, case management | TFR, suspicious transaction reporting |
Operations | Back office, complaints, incident management, regulatory reporting | Conduct rules, DORA incidents |
Platform | Observability, immutable audit logs, BCP/DR | ICT documentation, resilience testing |
Key APIs and integrations
KYC and identity verification, plus sanctions, PEP and adverse-media screening
Blockchain analytics for wallet risk scoring and counterparty detection
Travel Rule messaging to exchange originator and beneficiary data with other CASPs
Custody or key-management provider, or your own MPC/HSM stack
Liquidity providers and venues for quotes and execution
EU banking partner for client fiat accounts, SEPA and card acquiring
Transaction monitoring and case management
Notification, document generation and e-signature for client agreements and statements
If you need a view of the crypto infrastructure vendor landscape, see our overview of providers used to build crypto banking and on-ramp solutions. Fiat-side wallet patterns overlap with our digital wallet app development guide.
Compliance features checklist
Jurisdiction-aware service catalogue and feature flags tied to your authorisation
Client-asset ledger with daily on-chain and bank reconciliation and break handling
Custody register of positions, periodic statements and segregation evidence
Travel Rule send/receive, self-hosted address proof flows and quarantine queue
Risk-based onboarding, ongoing monitoring and suspicious transaction reporting workflow
Pricing methodology and execution policy logged per order
Versioned disclosures, client agreements and consent records
Complaints handling with timestamps and outcomes
ICT incident classification, reporting workflow and third-party register
Orderly wind-down tooling: bulk transfer to another CASP or customer self-hosted wallets
The last item is not hypothetical. ESMA's statement on the end of the transitional period expects unauthorised providers to communicate clearly and help clients move assets. A credible exit capability is good engineering and good supervision evidence.
Cost and timeline drivers
Driver | Why it moves cost and time |
Service scope and class | Custody, exchange or a trading platform add capital, policies and engineering |
Route | Own authorisation means building the full control set; partner route shifts work to integration and contracts |
Custody model | Self-built MPC/HSM vs third-party custody changes security reviews and segregation evidence |
Number of Member States | Passporting, languages, local marketing rules, tax reporting |
Fiat rails | Banking partner onboarding and client-funds accounts are often the slowest dependency |
Travel Rule coverage | Counterparty networks, self-hosted wallet verification UX, exception handling |
Existing licences | Article 60 entities reuse governance and AML frameworks |
DORA readiness | Incident tooling, testing and vendor contracts |
We do not quote a single price or timeline for a MiCA app because these drivers vary so widely. A scoping exercise that maps features to services usually narrows the range quickly.
Build plan
Feature-to-service mapping with counsel; decide own authorisation, Article 60 notification or partner CASP.
Architecture and policy design together: ledger, custody, Travel Rule and ICT documentation written from the same source.
Core build: onboarding, ledger, custody integration, fiat rails, trading or swap flows.
Compliance layer: Travel Rule, monitoring, case management, reporting, complaints.
Evidence pack: technical documentation, test results, reconciliation reports and wind-down runbook for the application or partner due diligence.
Controlled launch in your home Member State, then passport.
FAQs
Do I need my own CASP authorisation to launch a crypto app in the EU?
Not always. You can partner with an authorised CASP that provides the regulated services while your app provides the interface, as long as the contractual and operational split is clear. Banks, investment firms and EMIs may be able to use the Article 60 notification route instead.
Which MiCA class applies to a crypto buy/sell app with custody?
Exchange of crypto-assets for funds and custody are class 2 services under Annex IV, and class 2 carries a permanent minimum capital of EUR 125,000. Prudential safeguards are the higher of that amount or one quarter of annual fixed overheads.
Does the Travel Rule apply to small transfers?
The TFR requires information to accompany crypto-asset transfers between CASPs. The EUR 1,000 threshold relates to assessing whether a self-hosted address is owned or controlled by your customer. Design for both.
Can a CASP authorised in one country serve the whole EU?
Yes. Authorised CASPs can provide services throughout the Union through establishment or the free provision of services, after the required notifications. Your app still needs per-country disclosures, marketing controls and language support.
Can we still rely on national registration?
No. The Article 143 transitional period ended on 1 July 2026 at the latest. Providers without MiCA authorisation must not onboard new EU clients.
Does MiCA cover stablecoin issuance?
MiCA has separate titles for asset-referenced tokens and e-money tokens. This guide covers CASP services; issuing a stablecoin is a different authorisation.
Build your MiCA crypto app with Fintegration
Fintegration builds regulated crypto and payments platforms: client-asset ledgers, custody integrations, Travel Rule flows, KYC/AML workflows and the evidence packs supervisors and partner CASPs ask for. We help you decide own authorisation vs partner before you write code that locks you in. Talk to our team to scope your MiCA crypto app.
For adjacent regulated products, see our crypto exchange licensing guide and UK/EU EMI-backed wallet guide.
