Why Most CASP License Applications Fail at the AML Section

Most CASP applications don't fail because MiCA is vague. They fail because MiCA is specific enough to expose when a firm has built a document set instead of an operating model.

Share
Why Most CASP License Applications Fail at the AML Section

The AML section of a CASP application fails when the firm submits policy language instead of an operating model. In May 2026, MiCA is explicit: applicants need governance, internal controls, AML risk procedures, reputable management, and an organisation that can actually run the service without exposing clients or the market to avoidable financial-crime risk.

Why do CASP licence applications fail at the AML section?
Because the applicant can describe controls but cannot evidence how those controls really work. Under MiCA, the file has to show AML and CFT risk management, governance, staffing, business continuity, and management suitability in a way that an NCA can test. The weak application reads like a manual. The strong one reads like an operating system.

There is no official ESMA table titled "Most CASP applications fail here."

But the AML section is where a large share of weak applications become obviously weak, because it forces the firm to answer harder questions than:

  • Do we have a policy?
  • Do we have an MLRO?
  • Do we screen sanctions lists?

The real questions are:

  • How is customer risk assessed in practice?
  • Who owns escalations?
  • How are alerts handled and closed?
  • What happens when a customer, wallet, or business counterparty becomes higher risk after onboarding?
  • How does the board know the controls are working?
  • What breaks if one reviewer, one vendor, or one outsourced function fails?

That is why the AML section matters so much.

It is where the regulator learns whether the company has built a real compliance operating model or only a document set.

Start with the actual MiCA standard

MiCA is clearer on this than many founders realise.

Article 62 says a CASP authorisation application has to include:

  • governance arrangements
  • proof of prudential safeguards
  • proof that management is of sufficiently good repute and has the right knowledge, skills, and experience
  • proof about qualifying shareholders
  • internal control mechanisms, policies, and procedures to identify, assess, and manage risks, including money-laundering and terrorist-financing risks
  • a business continuity plan
  • ICT and security documentation
  • client asset segregation procedures
  • complaints procedures

That is already far more than a narrow AML memo.

Then Article 63 raises the bar further. NCAs can consult AML authorities and financial intelligence units before granting or refusing authorisation. They must refuse authorisation where there are objective and demonstrable grounds that:

  • the management body exposes the applicant to a serious risk of money laundering or terrorist financing
  • management does not meet the Article 68 criteria
  • qualifying shareholders do not meet the good-repute criteria
  • the applicant fails, or is likely to fail, the requirements of Title V

Article 68 then adds governance substance:

  • management must be of sufficiently good repute
  • management and qualifying holders must not have relevant money-laundering or terrorist-financing convictions
  • the CASP must adopt effective policies and procedures to ensure MiCA compliance
  • the CASP must employ personnel with the right knowledge and expertise
  • the management body must periodically review whether those arrangements actually work

The core point is simple.

The AML section is not a side annex.

It is bound up with authorisation itself.

The 2026 timeline makes weak AML files more dangerous

This matters even more in 2026 because the transition window is nearly closed.

The key dates are:

  • 30 December 2024: MiCA started applying for CASPs
  • 17 April 2026: ESMA said the MiCA transitional period ends across the EU on 1 July 2026
  • 1 July 2026: any entity still providing crypto-asset services to EU clients without MiCA authorisation will be in breach of EU law and must stop

MiCA also defines the application timeline once the file is submitted:

  • NCA acknowledges receipt within 5 working days
  • NCA checks completeness within 25 working days
  • after a complete application, the NCA has 40 working days to assess and grant or refuse authorisation, subject to permitted information requests and suspensions

That means founders do not have room for a weak first pass.

An incomplete or operationally thin AML section is not just embarrassing. It can push the application into delay exactly when the business has the least time left to absorb it.

Why the AML section exposes so many weak applications

The reason is structural.

The AML section forces the applicant to show how the business behaves under stress, complexity, and ambiguity.

A lot of early-stage CASPs are still immature in one or more of those areas.

1. Policies exist, but workflows do not

This is the most common failure pattern.

The application includes:

  • an AML policy
  • a sanctions policy
  • a customer risk framework
  • a suspicious-activity escalation description

On paper, everything looks covered.

Then the NCA wants to know:

  • what the onboarding flow looks like for retail clients
  • how business customers are handled differently
  • when enhanced due diligence is triggered
  • how sanctions false positives are resolved
  • how transaction monitoring alerts are triaged
  • how cases move from analyst review to management decision
  • what evidence is retained

That is where a policy-only application breaks.

If the workflow is not mapped, owned, and measurable, the file reads as aspirational rather than operational.

Crypto firms often over-centralise AML in legal or compliance drafting.

But the real AML burden lives across operations:

  • onboarding design
  • KYC and KYB controls
  • sanctions screening
  • blockchain or transaction monitoring
  • alert handling
  • withdrawal controls
  • customer support escalations
  • reporting to authorities

If the application does not show how those pieces connect, the AML section feels artificial.

The regulator is not authorising a policy library.

It is authorising a live operating firm.

3. The management body is not visibly in control of AML risk

MiCA is clear that governance matters.

The AML section fails quickly when management looks detached from the operating model.

Warning signs include:

  • the board cannot explain the customer-risk model
  • AML ownership is vague across founders, MLRO, and operations
  • key controls are outsourced with weak internal oversight
  • the firm cannot explain what information management reviews regularly
  • there is no cadence for control testing or deficiency remediation

In practice, regulators want to see that AML is governable, not just delegated.

4. The file underestimates business continuity and operational resilience

Article 62 explicitly links internal controls with business continuity.

That is important because AML controls are not credible if they disappear when something goes wrong.

A strong file should be able to answer:

  • what happens if screening or monitoring vendors fail
  • how alerts are handled if normal systems are unavailable
  • what fallback process exists for high-risk onboarding
  • who can freeze, escalate, or block activity during an outage
  • how backlog risk is managed if alert volume spikes

Weak applications often treat AML and continuity as separate chapters.

Under MiCA, they are part of the same control story.

5. KYB and counterparty risk are still underdeveloped

Many CASP applicants still think too much in retail KYC terms.

But once the business touches:

  • corporate clients
  • OTC counterparties
  • market makers
  • liquidity partners
  • payment providers
  • distributors

the AML section becomes materially harder.

The NCA will want to know how the firm verifies business customers, identifies beneficial owners, screens controllers, and monitors changes over time.

This is where retail-first applications often look incomplete.

6. The firm cannot evidence the alert-to-decision path

Most firms can describe detection.

Fewer can explain decisioning.

That is a problem because suspicious activity handling is where AML becomes real.

The application should make it easy to understand:

  • which scenarios generate alerts
  • how alerts are prioritised
  • what information investigators can see
  • how decisions are documented
  • what triggers a freeze, refusal, offboarding, or reporting escalation
  • who signs off at each level

If the application cannot answer those questions, the NCA has no reason to assume the controls will become clearer after authorisation.

A realistic CASP application failure

Imagine a founder-led CASP applying in May 2026.

The file looks polished:

  • good branding
  • strong legal memo
  • neat AML manual
  • named MLRO
  • vendor contracts in place

Then the NCA asks for three things:

  1. the real onboarding path for a higher-risk business client
  2. the sanctions false-positive handling workflow
  3. management reporting showing how alert quality and case closure are reviewed

The firm struggles.

Why?

Because the operating model is still mostly verbal:

  • onboarding differs by analyst rather than by designed workflow
  • sanctions matches are cleared in email
  • business customer checks are partly manual and partly vendor-driven
  • management sees anecdotal updates, not structured MI
  • there is no tested playbook for alert surges or vendor outages

At that point, the AML section has done its job.

It has exposed that the firm is not yet ready to operate compliantly at scale.

What a stronger AML section looks like

The strong AML section does not only describe obligations.

It demonstrates process.

Area What the NCA should be able to see
Governance clear ownership from board to MLRO to operations
Risk assessment customer, product, geography, channel, and counterparty logic
Onboarding KYC and KYB workflows, step-up triggers, EDD paths
Screening sanctions and PEP logic, false-positive handling, rescreening cadence
Monitoring alert scenarios, thresholds, prioritisation, escalation paths
Case management investigation steps, evidence capture, closure standards
Continuity fallback plans for outages, surges, and vendor failure
Oversight recurring management reporting, control testing, remediation loops

That is the difference between a file that reads operationally and one that reads aspirationally.

How VOVE ID helps applicants close the gap

VOVE ID helps crypto and fintech teams avoid the most common AML-application weakness: fragmentation.

The problem is rarely one missing policy.

It is that the business runs:

  • KYC in one tool
  • KYB in another
  • sanctions elsewhere
  • monitoring in a separate environment
  • case decisions in tickets, email, or spreadsheets

That fragmentation makes an application harder to defend because the operating model is harder to explain.

VOVE ID helps teams unify:

  • onboarding and identity verification
  • business verification and UBO workflows
  • sanctions and PEP checks
  • monitoring inputs
  • alert context
  • audit-friendly review records

That gives management and applicants a better supervisory story.

A practical checklist before you submit

Before filing a CASP application, ask:

  • Can we show the actual onboarding path for low-, medium-, and high-risk customers?
  • Can we explain exactly how a sanctions alert is reviewed and closed?
  • Do we have a real KYB and UBO workflow for business clients and counterparties?
  • Is AML ownership clear from board level to reviewer level?
  • Can management evidence periodic review of control effectiveness?
  • Do we have fallback procedures if screening, monitoring, or case tools fail?
  • Can we produce sample MI on alerts, investigations, turnaround time, and escalations?
  • If the NCA asks for a flow diagram and one sample case, can we deliver both immediately?

If the answer is no, the application likely needs more operating work before it needs more drafting.

Conclusion

Most CASP licence applications do not get into trouble at the AML section because MiCA is vague.

They get into trouble because MiCA is specific enough to force the real question:

does this firm have an AML operating model that can work in production?

Article 62 requires internal controls, risk procedures, governance, and continuity. Article 63 gives NCAs room to test that file and refuse authorisation where management or the firm creates serious AML or CFT risk. Article 68 makes governance effectiveness a live requirement, not a box-check.

By May 2026, the right move is not to make the AML annex longer.

It is to make the operating model real.


Need a cleaner KYC, KYB, and AML operating backbone before your CASP application goes in? Talk to the team.

FAQ

1. What does MiCA require in a CASP application's AML section?

MiCA requires internal control mechanisms, policies and procedures to identify, assess, and manage risks including money-laundering and terrorist-financing risks, plus governance, continuity, and management suitability evidence.

2. Can a strong policy document compensate for a weak workflow?

No. The policy matters, but the NCA is assessing whether the firm can operate compliantly in practice.

3. Why does management suitability matter so much?

Because MiCA links authorisation to governance. If management or qualifying holders create serious AML or CFT risk, the NCA can refuse authorisation.

4. What should applicants fix first?

Turn policy into process: onboarding flows, screening logic, monitoring escalation, case handling, continuity, and management reporting.