{"id":21505,"date":"2025-11-25T23:29:20","date_gmt":"2025-11-25T22:29:20","guid":{"rendered":"https:\/\/www.in-diem.com\/common-mistakes-in-casp-applications-and-how-to-avoid-them\/"},"modified":"2026-08-12T14:38:48","modified_gmt":"2026-08-12T12:38:48","slug":"common-mistakes-in-casp-applications-and-how-to-avoid-them","status":"publish","type":"post","link":"https:\/\/www.in-diem.com\/en\/common-mistakes-in-casp-applications-and-how-to-avoid-them\/","title":{"rendered":"Common mistakes in CASP applications and how to avoid them"},"content":{"rendered":"
\n

IMPORTANT:<\/strong> This article was drafted in accordance with the regulatory and supervisory framework in effect at the time of its publication, specifically Regulation (EU) 2023\/1114\u2014MiCA\u2014and the criteria applicable to crypto-asset service providers under the CNMV. Given that CASP authorization requirements, application manuals, technical criteria, and requirements regarding governance, AML\/CFT, cybersecurity, and document review may be updated by the CNMV, ESMA, or other competent authorities, each application must be reviewed in accordance with current regulations and the applicant\u2019s actual business model. <\/em><\/p>\n\n

The entry into force of MiCA <\/a>has opened a completely new chapter for crypto-asset service providers (CASPs) in the European Union. In Spain, the CNMV has become the mandatory gateway for any project<\/strong> that wants to operate with legal certainty, attract institutional investment or scale its operations without regulatory uncertainty. <\/p>\n\n

The issue we see in some of the projects presented to us is that this increase in applications is not matched by the same level of quality in the files. In practice, we see a very clear pattern: most rejections and requests for corrections stem from entirely avoidable mistakes.<\/strong> <\/p>\n\n

This article is a practical guide\u2014without unnecessary technical jargon\u2014to understand where CASP files tend to fail, how to avoid those issues, and what the CNMV really expects from each project.<\/p>\n\n

IN DIEM Abogados<\/strong> provides the legal and regulatory perspective and Cryptoveritas 360<\/strong> <\/a>provides technical, cybersecurity, and blockchain auditing expertise.<\/p>\n\n

Why is it so easy to make mistakes in CASP applications?<\/strong><\/h2>\n\n

Those approaching MiCA for the first time often think it is a regulation focused solely on the legal side. But in reality, it is a legal + technical + operational<\/strong> model. <\/p>\n\n

The documents must fit together like a puzzle: AML manuals, governance, technology architectures, operational flows, custody policies, etc. Any inconsistency is quickly detected by the CNMV.<\/strong><\/p>\n\n

Many projects come from the startup environment, where speed takes precedence over documentation. This clashes head-on with the level of detail required by MiCA. <\/p>\n\n

MiCA requirements in Spain: the starting point where many mistakes begin<\/strong><\/h2>\n\n

Solvency and capital<\/strong><\/h3>\n\n

MiCA requires real solvency, not mere declarations. A custody service with millions under management cannot justify low capital without a robust risk analysis.One of the most serious mistakes: generic or copied manuals. The CNMV detects them immediately because they lack the necessary specificity. An AML manual must be a living document, reflecting the real risks of your business model, your clients and the blockchains you operate on. <\/p>\n\n

AML\/CFT manuals<\/strong><\/h3>\n\n

One of the most serious mistakes: generic or copied manuals. The CNMV detects them immediately because they lack the necessary specificity. An AML manual must be a living document, reflecting the real risks of your business model, your clients and the blockchains you operate on. <\/p>\n\n

Governance<\/strong><\/h3>\n\n

Clear roles, traceability and defined processes. Many projects fail due to \u201cnice but empty\u201d org charts, where no specific responsibilities are assigned and no effective chain of command for critical decision-making is demonstrated. <\/p>\n\n

Technology systems<\/strong><\/h3>\n\n

One of the most demanding requirements. The technical side is often described superficially, raising significant doubts about the security, resilience and real capacity of the infrastructure. The CNMV needs to understand not only what<\/em> you do, but how<\/em> you do it securely. <\/p>\n\n

IN DIEM + Cryptoveritas 360<\/strong> cross-check each document against the rest to avoid inconsistencies, the most common mistake.<\/p>\n\n

The 10 most common mistakes in CASP applications<\/strong><\/h2>\n\n

1. Vague or inconsistent business models.<\/h3>\n\n
    \n
  • The mistake:<\/strong> Describing the service in generic terms (“we are an exchange”) without detailing specific workflows, target customers, revenue sources or a realistic assessment of operational risks.<\/li>\n\n\n\n
  • CNMV example:<\/strong> A project presents itself as an NFT marketplace, but its AML documentation does not differentiate the risks between an artist minting a work and a collector trading high volumes. The CNMV perceives a lack of understanding of its own business. <\/li>\n\n\n\n
  • The solution:<\/strong> The business model must be a complete operational narrative. Include user flow diagrams (onboarding, trading, withdrawals), define your customer profiles (buyer personas) and present a SWOT analysis that supports your strategic and risk decisions. <\/li>\n<\/ul>\n\n

    2. Generic AML\/CFT plans copied from third parties.<\/h3>\n\n
      \n
    • The mistake:<\/strong> Using internet templates or documents from other companies without adapting them to the project\u2019s technological and operational reality. The CNMV looks for \u201ccopy and paste\u201d and penalises it. <\/li>\n\n\n\n
    • CNMV example:<\/strong> The AML manual mentions monitoring \u201ccash transactions\u201d or geographic risks in jurisdictions where you do not operate, when your platform is 100% digital and operates in the EU. This reveals a lack of customisation. <\/li>\n\n\n\n
    • The solution:<\/strong> Absolute customisation. Your AML manual must reflect your real risk assessment, mention the specific KYT tools you use (such as Chainalysis or Elliptic), the blockchain protocols you support, and the alert thresholds defined based on your activity. <\/li>\n<\/ul>\n\n

      3. Poorly defined governance or no clear accountable persons.<\/h3>\n\n
        \n
      • The mistake:<\/strong> \u201cDecorative\u201d org charts where it is not clear who has ultimate authority to make decisions in critical areas such as AML, technology or risk management.<\/li>\n\n\n\n
      • CNMV example:<\/strong> The \u201cCompliance Officer\u201d appears on the org chart, but their functions described in another document are ambiguous and they are not given veto power over the launch of new high-risk products. It is perceived as a token role. <\/li>\n\n\n\n
      • The solution:<\/strong> Assign a named individual to each role required by MiCA. Create responsibility matrices (RACI) and attach minutes of the first risk committee meetings to demonstrate that governance is active and not merely theoretical. <\/li>\n<\/ul>\n\n

        4. Misalignment between technical and legal documents.<\/h3>\n\n
          \n
        • The mistake:<\/strong> The technical description of systems (e.g., the ratio between cold and hot wallets) does not match the execution timelines or disaster recovery policies described in operational and legal manuals.<\/li>\n\n\n\n
        • CNMV example:<\/strong> The legal document promises 99.99% service availability (SLA), but the technical architecture describes maintenance windows without customer communication procedures or real redundancy. The inconsistency is glaring. <\/li>\n\n\n\n
        • The solution:<\/strong> Ongoing cross-review. A lawyer must understand the fundamentals of the technology described, and a technician must understand the legal requirements the architecture must meet. Every statement in one document must be coherently reflected in all the others. <\/li>\n<\/ul>\n\n

          5. Failure to justify technological requirements.<\/h3>\n\n
            \n
          • The mistake:<\/strong> Claiming compliance with cybersecurity standards without detailing how<\/em>. Vague phrases such as “we use encryption” or “we have a SOC” are insufficient and trigger immediate requests for clarification. <\/li>\n\n\n\n
          • CNMV example:<\/strong> “We have a SOC (Security Operations Center).” The CNMV will ask: Is it in-house or outsourced? What certifications does the team have? What are the response SLAs? Which events are specifically monitored? <\/li>\n\n\n\n
          • The solution:<\/strong> Technical specificity. Instead of “encryption”, specify “we use AES-256 for data at rest and TLS 1.3 for data in transit”. Attach team certifications, detailed architecture diagrams and documented security policies (patching, access, etc.). <\/li>\n<\/ul>\n\n

            6. Underestimating KYC and traceability.<\/h3>\n\n
              \n
            • The mistake:<\/strong> Implementing a basic KYC process that does not scale or does not allow full traceability of a customer\u2019s transactions over time, breaching the principle of ongoing “know your customer”.<\/li>\n\n\n\n
            • CNMV example:<\/strong> The system allows customer onboarding, but cannot automatically track and group all associated wallets or detect suspicious behaviour patterns based on transaction history.<\/li>\n\n\n\n
            • The solution:<\/strong> Integrate on-chain analytics and KYT tools by design. Demonstrate to the CNMV that your system can follow the trail of funds beyond a single transaction, linking addresses and detecting anomalous behaviour. <\/li>\n<\/ul>\n\n

              7. Not substantiating the management team\u2019s experience.<\/h3>\n\n
                \n
              • The mistake:<\/strong> Submitting generic CVs<\/em> without demonstrating how each executive\u2019s specific experience is relevant and adequate for the risks and complexity of a CASP.<\/li>\n\n\n\n
              • CNMV example:<\/strong> The CTO has extensive experience in traditional IT, but their CV does not show specific knowledge of blockchain cybersecurity, private key management or decentralised architectures.<\/li>\n\n\n\n
              • The solution:<\/strong> CVs must be explanatory. Do not just list experience\u2014explain how each previous role has prepared the executive to manage MiCA\u2019s specific risks. Specific training in blockchain and regulation is a key advantage. <\/li>\n<\/ul>\n\n

                8. Non-existent or vague continuity procedures.<\/h3>\n\n
                  \n
                • The mistake:<\/strong> Not having a business continuity plan (BCP), or having one that is merely a statement of intent, without concrete steps, assigned roles and communication plans for serious incidents.<\/li>\n\n\n\n
                • CNMV example:<\/strong> The BCP mentions “recovery at a secondary site” but does not specify the RTO (Recovery Time Objective) and RPO (Recovery Point Objective), nor does it detail how data consistency is ensured in a crisis scenario.<\/li>\n\n\n\n
                • The solution:<\/strong> Develop a detailed, realistic BCP. Include test scenarios, communication plans for customers and regulators, and specific technical procedures for system and data recovery. <\/li>\n<\/ul>\n\n

                  9. Superficial or not credible custody policies.<\/h3>\n\n
                    \n
                  • The mistake:<\/strong> Describing a custody system without providing technical evidence of its implementation, such as multi-party signature schemes, asset segregation or key recovery protocols.<\/li>\n\n\n\n
                  • CNMV example:<\/strong> A company claims to use “98% cold wallets” but does not describe the physical and logical procedure to access them, nor how it mitigates the risk of a single point of failure in that process.<\/li>\n\n\n\n
                  • The solution:<\/strong> Provide in-depth technical custody documentation. Key architecture diagrams, a description of the Hardware Security Modules (HSMs), and audited procedures for generating, storing and using private keys. <\/li>\n<\/ul>\n\n

                    10. Inconsistencies between annexes submitted to the CNMV.<\/h3>\n\n
                      \n
                    • The mistake:<\/strong> Data, figures or descriptions in one annex do not match those in another. For example, the share capital in one document differs from what is declared in another, or the list of supported protocols in the technical manual does not match the commercial one. <\/li>\n\n\n\n
                    • CNMV example:<\/strong> The financial annex shows capital of \u20ac150,000, while the descriptive report refers to \u20ac125,000. Or the marketing manual promotes support for a blockchain that does not appear in the technology risk assessment. <\/li>\n\n\n\n
                    • The solution:<\/strong> Carry out a final \u201chorizontal read\u201d of the entire file. Check that every data point, name, figure and description is consistent across the more than 20 documents that an application typically includes. This is one of the most critical tasks before submission. <\/li>\n<\/ul>\n\n

                      How can you avoid mistakes before submitting your application?<\/strong><\/h2>\n\n

                      The best strategy is to carry out a legal and technical pre-audit<\/strong> that reviews the entire file with the same approach the CNMV would take, but with a constructive, improvement-oriented mindset.<\/p>\n\n

                      Basic checklist<\/strong><\/h3>\n\n
                        \n
                      • Operational, understandable business model with detailed flows.<\/li>\n\n\n\n
                      • Risks identified, assessed and quantitatively justified.<\/li>\n\n\n\n
                      • AML manual 100% tailored to your service, technology and customers.<\/li>\n\n\n\n
                      • Technology described precisely, without vagueness.<\/li>\n\n\n\n
                      • Real cybersecurity measures, documented and justified.<\/li>\n\n\n\n
                      • Coherent governance, with accountable persons and defined processes.<\/li>\n\n\n\n
                      • Suitable, financially sound management team, with proven relevant experience.<\/li>\n\n\n\n
                      • All annexes aligned and free of internal contradictions.<\/li>\n<\/ul>\n\n

                        <\/p>\n\n

                        The importance of legal\u2013technical alignment: the decisive factor<\/strong><\/h2>\n\n

                        If the legal side says one thing and the technical side describes another, the CNMV will spot it within minutes. This disconnect is the main cause of requests for corrections and delays. MiCA regulation is, by its nature, an interdisciplinary framework that requires an equally integrated response. <\/p>\n\n

                        How IN DIEM + Cryptoveritas 360 address it<\/strong><\/h3>\n\n
                          \n
                        • Smart contract audit<\/strong> (where applicable) and review of blockchain architecture.<\/li>\n\n\n\n
                        • Comprehensive cybersecurity assessment<\/strong> of the infrastructure.<\/li>\n\n\n\n
                        • Technology risk analysis<\/strong> aligned with capital requirements.<\/li>\n\n\n\n
                        • Cross-review<\/strong> of all manuals (AML, Governance, Technology) to ensure consistency.<\/li>\n\n\n\n
                        • Full alignment<\/strong> between the business model, the underlying technology and AML\/CFT policies.<\/li>\n<\/ul>\n\n