Guide to CASP Internal Controls Under MiCA

A MiCA application rarely fails because the business model is unclear. More often, it stalls because the internal control framework does not match the scale, risk profile, and operational reality of the CASP. This guide to CASP internal controls under MiCA is written for founders and operators who need controls that satisfy the regulator without slowing the business to a halt.

MiCA is not asking for paper compliance. It expects authorised crypto-asset service providers to show clear governance, defensible decision-making, effective risk management, and day-to-day control over regulated activity. If your controls exist only in a policy folder, that gap will show up quickly in authorisation questions, banking reviews, and post-licensing supervision.

What MiCA expects from CASP internal controls

For most applicants, the core issue is not whether controls are required. It is whether those controls are proportionate, documented, and actually embedded in the business. MiCA works alongside existing EU expectations on governance, AML, outsourcing, ICT risk, complaints handling, and prudential discipline. That means your internal control environment needs to do more than recite legal wording. It needs to explain who is responsible, how risks are identified, what gets escalated, and how the board or management body can evidence oversight.

A practical guide to CASP internal controls under MiCA starts with this point: regulators assess substance. They will look at the management body, reporting lines, segregation of duties, conflicts controls, incident management, client asset handling, and record keeping as parts of one operating model. If one element is weak, the rest comes under pressure.

For early-stage CASPs, the challenge is proportionality. A smaller business is not expected to mirror a large financial institution. But it is expected to demonstrate control over key risks. Saying a team is lean does not excuse unclear accountability, missing second-line review, or founders approving their own exceptions without any audit trail.

Governance is the first control, not a box to tick

Governance is usually where authorisation quality becomes obvious. Regulators want to know who runs the business, who challenges decisions, and whether there is enough independence in control functions to prevent management from marking its own homework.

The management body should have defined responsibilities, regular reporting, and formal minutes that show active oversight. This matters in practice. If operational incidents, complaints, suspicious activity, outsourcing failures or liquidity pressure are not reaching senior management in a structured way, the regulator will assume the firm is reacting rather than controlling.

Segregation of duties is equally important. In many CASPs, especially founder-led ones, one person may be responsible for product, treasury, client onboarding and partner relationships. That may be commercially understandable at launch, but it creates obvious control weaknesses. The answer is not always hiring a large team immediately. Sometimes it means redesigning approvals, creating dual sign-off for higher-risk actions, or placing independent review with a suitably qualified compliance or risk function.

Conflicts of interest also need real treatment. Where the CASP offers proprietary trading, token-related services, custody, execution, or links to affiliated entities, the conflict analysis should be specific. Generic wording will not survive scrutiny if revenue incentives can affect client outcomes or asset handling decisions.

Risk management must reflect the actual business model

A CASP risk framework should not read like a generic financial services manual. It should reflect what the firm actually does. A custody-focused provider has a different control profile from a broker, exchange operator, transfer service provider, or adviser on crypto-assets.

At a minimum, the risk framework should identify operational, conduct, AML, market abuse, outsourcing, prudential, ICT, cyber, data protection, and reputational risks. More importantly, it should show how those risks are assessed and monitored. Risk registers are useful only if they connect to controls, owners, review frequency, thresholds, and escalation triggers.

This is where many firms underperform. They write broad risks but do not define control testing, reporting metrics, or remediation ownership. For example, if wallet access permissions are a key operational risk, the control set should cover user access management, approval hierarchy, logging, periodic review, and emergency response. If onboarding risk is material, the framework should specify enhanced due diligence triggers, customer risk scoring, sanctions screening governance, and case escalation.

There is also a strategic point here. Internal controls are not only about satisfying MiCA. They affect bankability, investor due diligence, payment provider access, and transaction readiness. Weak controls increase friction across the business, not only with the regulator.

AML, financial crime and MiCA controls must work together

Although MiCA is not an AML rulebook, no serious CASP can treat AML as a separate stream. Regulators and counterparties will expect the AML framework to align with the broader internal control model. If customer acceptance, transaction monitoring, suspicious activity reporting and sanctions compliance sit outside governance reporting, you create blind spots.

The better approach is integration. Compliance reporting should feed management information on onboarding trends, high-risk clients, alerts, investigations, rejected business, and control breaches. Senior management should see where risk is rising, not just whether a policy exists.

This is also where outsourcing can create problems. Many CASPs rely on third-party KYC, blockchain analytics, screening tools, or transaction monitoring vendors. That is acceptable, but outsourced support does not transfer responsibility. The CASP still needs oversight, service level monitoring, fallback planning, and evidence that the provider is fit for purpose. If a key vendor fails, the regulator will look at your governance before it looks at the contract.

Record keeping, evidence and auditability

The firms that move through authorisation more efficiently are usually the ones that can evidence control performance, not just control design. In other words, they can show approvals, logs, reviews, meeting packs, breach registers, complaints records, incident reports, outsourcing assessments, and remediation tracking.

This matters because MiCA supervision will not stop at the application stage. Once authorised, the CASP will need to maintain records that support ongoing compliance and demonstrate that controls are operating as intended. Poor record discipline is one of the fastest ways to turn a manageable supervisory query into a broader review.

Auditability should be built in from the start. If an issue occurs, can you reconstruct who approved what, when it happened, which systems were affected, how clients were impacted, and what corrective action followed? If not, the internal control framework is incomplete.

Outsourcing and ICT controls are now front-line issues

Many CASPs are built on external infrastructure. Cloud environments, wallet technology, customer support, onboarding tools, screening engines and white-label components are common. That operating model can work, but only if outsourcing and ICT controls are treated as front-line risk areas.

The regulator will expect an outsourcing register, due diligence on critical providers, contractual protections, performance monitoring, concentration risk assessment, and exit planning. DORA may also become relevant depending on the entity and service profile, so firms should avoid designing a MiCA control framework in isolation from wider digital operational resilience expectations.

The trade-off is simple. Outsourcing can speed up market entry and reduce internal build costs, but it also increases dependency risk. If your business cannot continue key operations during a provider outage or termination event, your control framework needs strengthening before launch, not after.

Common mistakes in CASP internal controls under MiCA

The most frequent mistake is treating internal controls as a documentation task led only by legal or compliance. Authorisation-ready controls require input from operations, product, technology, finance, AML and senior management. If those teams are not aligned, the documents and the business will contradict each other.

Another common issue is overengineering. Some applicants submit frameworks that look impressive but cannot be operated by the actual team. Regulators are quick to spot this. A smaller, well-run control set is far better than a grand structure with no evidence behind it.

There is also the problem of borrowed templates. Templates can help with structure, but they often miss the details that matter most to a specific CASP, such as wallet governance, token admission criteria, client disclosure flows, safeguarding mechanics, or escalation pathways for market abuse concerns. Those are the areas where applications are tested.

Building a control framework that stands up in practice

The right starting point is a gap analysis against the planned service scope, jurisdictional expectations, operating model and resource plan. From there, the firm should map responsibilities, define governance committees and reporting, design risk and compliance monitoring, review outsourcing dependencies, and align policy wording with actual workflows.

This is not simply about getting authorised. A credible internal control framework reduces remediation cycles, shortens regulator back-and-forth, and helps avoid expensive rebuilds after submission. It also gives management a clearer view of where growth creates new risk, which becomes critical once transaction volumes, staffing and third-party dependencies increase.

For businesses pursuing authorisation on a fixed launch timeline, execution quality matters more than theoretical completeness. Controls should be proportionate, operational, and evidenced from day one. That is usually the difference between a framework that supports growth and one that delays it.

If you are preparing a MiCA application or reassessing an existing setup, the real question is not whether your policies look complete. It is whether your controls would still make sense under regulator challenge, banking due diligence, and a live operational incident at the same time. That is the standard worth building to. For tailored support on MiCA licensing and compliance execution, NUR Legal can help you find the best solution.