2026-05-29·5 min read·sota.io Team

EU MiCA CASP Technical Requirements 2026: IT Systems, Cybersecurity and AML/KYC Integration for SaaS Developers

Post #1380 in the sota.io EU Cyber Compliance Series

EU MiCA CASP Technical Requirements 2026: IT Systems, Cybersecurity and AML/KYC

Getting CASP authorization (covered in post #1) is only the start. Once authorized, your platform must continuously satisfy MiCA's operational and technical obligations — a set of IT, cybersecurity, and AML/KYC requirements that directly determine your engineering architecture. This is post #2/5 in the EU-MICA-CASP-DEVELOPER-2026 series.

The June 30, 2026 grace period deadline is the forcing function. If you are building a crypto wallet, exchange, DeFi aggregator, or custodial service with EU users, these technical requirements are not optional — and they go far beyond GDPR. This guide translates MiCA's legal obligations into concrete engineering deliverables.


ICT Risk Management: DORA and MiCA Governance Obligations

MiCA requires all CASPs to maintain ICT systems that are appropriate for the scale, nature, and complexity of their services — these governance and operational obligations sit in MiCA Art.68 (Governance arrangements) and Art.67 (Prudential requirements). The detailed ICT operational-resilience standard for the financial sector, however, derives from DORA (Regulation EU 2022/2554), not from MiCA itself. CASPs fall within DORA's scope, so the specific ICT risk-management framework, incident-reporting, and resilience-testing requirements below come from DORA:

ICT Risk Management Framework (DORA)

Your CASP must maintain a documented ICT risk management framework covering:

RequirementEngineering Implication
Asset inventory of all ICT systemsConfig management, CMDB, infrastructure-as-code registry
Threat and vulnerability assessmentRegular pen tests, CVE scanning (weekly minimum)
Business continuity plan (BCP)Multi-region failover, defined RTO/RPO for each service
ICT incident classification systemAutomated severity scoring, on-call runbooks
Recovery testingAnnual disaster recovery drills (documented)

MiCA vs DORA: The CASP-specific governance and prudential obligations (board accountability, organisational arrangements, own funds) live in MiCA Art.67-68, while the detailed ICT operational-resilience standard comes from DORA. CASPs that also act as ICT service providers to other financial entities — for example, if you provide custody infrastructure to banks — face the full DORA framework directly. The audit trails must satisfy both supervisory frameworks separately.

Incident Reporting Timeline (DORA)

DORA mandates notification of your competent authority within 24 hours of detecting a major ICT incident. The definition of "major" includes:

Engineering requirement: You must have automated incident detection (not just user complaints) with alerting pipelines capable of triggering NCA notification workflows within the 24-hour window. This means:

Monitoring → Alert → On-call Triage → Severity Classification → 
Legal/Compliance Notified → NCA Draft → Submission within 24h

Build this runbook before you go live. NCAs will audit your incident response procedures during initial authorization and in spot inspections.

Cryptographic and Key Management Standards

For custodial CASPs, MiCA's technical standards require:

The EBA has signaled that custodial CASPs using pure software key storage will face authorization refusal or remediation requirements. HSM infrastructure is not optional for custody services.


Cybersecurity Architecture for MiCA-Compliant Platforms

CASP cybersecurity requirements derive from DORA's ICT risk-management standard and the related RTS on operational requirements. The framework mandates:

Network Segmentation

Internet
  └── WAF / DDoS mitigation (CloudFlare or EU equivalent)
        └── API Gateway (rate limiting, geo-blocking)
              ├── Public trading interface (DMZ)
              └── Internal custody infrastructure (air-gapped segment)
                    └── HSM cluster (isolated VLAN, HSM-only access)

Key design constraints for EU-hosted CASPs:

Penetration Testing Requirements

DORA's resilience-testing standard requires:

Test TypeMinimum FrequencyScope
External pen testAnnualAll public-facing APIs, smart contract interfaces
Internal red teamEvery 2 yearsCustody infrastructure, key management
Smart contract auditBefore each contract deploymentAll on-chain logic
Threat-led penetration testing (TLPT)Every 3 years (DORA-equivalent)Full infrastructure

Results must be provided to your NCA on request. Remediation of critical findings must occur before new services launch.


AML/KYC Technical Obligations: The AML Framework (AMLD/AMLR)

CASPs are obliged entities under the EU Anti-Money Laundering framework (5AMLD, as amended by 6AMLD, and the forthcoming AML Regulation / AMLR). These AML/KYC obligations derive from the AML framework itself — not from a MiCA article — and apply to CASPs as obliged entities alongside their MiCA authorization.

KYC Onboarding Architecture

Your KYC flow must satisfy both MiCA and AMLD requirements simultaneously:

User Registration
  ↓
Identity Verification (eIDAS-compliant or equivalent)
  ├── Liveness check (biometric, ISO 30107-3 PAD Level 2)
  ├── Document scan + NFC chip reading (for ePassport)
  └── Sanctions screening (OFAC, EU consolidated list, HMT)
  ↓
Risk Scoring (PEP check, adverse media, geographic risk)
  ↓
Account Activation
  ↓
Ongoing Monitoring (transaction patterns, balance changes)

EU-compliant KYC vendors (sovereign-hosting compatible):

VendorEU Data ProcessingeIDAS SupportHQ
VeriffEstoniaYes (QES/QSig)Tallinn, EE
OndatoLithuaniaYesVilnius, LT
IDnowGermanyYes (QES)Munich, DE
Onfido (Entrust)UK/EUPartialLondon (EU processing available)
SumsubCyprusPartialLimassol, CY

For EU-headquartered CASPs processing EU citizen data, US-based KYC vendors (Persona, Alloy, Stripe Identity) require careful DPA review — US CLOUD Act means FBI/NSA access possible to identity documents processed on US infrastructure.

Transaction Monitoring: AML Framework Requirements

The EU AML framework requires CASPs, as obliged entities, to monitor transactions on an ongoing basis for suspicious activity. The minimum technical architecture:

# Simplified transaction monitoring pseudocode
class TransactionMonitor:
    def assess(self, tx: Transaction) -> RiskScore:
        score = 0
        
        # Geographic risk
        if tx.counterparty_jurisdiction in HIGH_RISK_COUNTRIES:
            score += 40
        
        # Transaction velocity
        if self.get_24h_volume(tx.user_id) > THRESHOLD_EUR:
            score += 30
        
        # Behavioral anomaly
        if self.deviation_from_baseline(tx) > 3_sigma:
            score += 20
        
        # Mixer/tumbler interaction
        if self.blockchain_analysis.is_mixing_output(tx.input_address):
            score += 80  # Immediate SAR likely required
        
        return RiskScore(score, self.explain(score))

Blockchain analytics requirements: CASPs must use on-chain analytics to identify transactions involving:

EU-compliant blockchain analytics vendors: Chainalysis (US, CLOUD Act caveat), Elliptic (UK, EU DPA available), Crystal Blockchain (Estonia — EU-native), CipherTrace (US, Mastercard). For maximum EU sovereignty, Crystal Blockchain or self-hosted open-source tools (UTXO-graph analysis) are preferable.

Suspicious Activity Reporting (SARs): AML Framework

When transaction monitoring triggers a high-risk event, the EU AML framework requires CASPs to file a Suspicious Activity Report (SAR) with the national Financial Intelligence Unit (FIU):

JurisdictionFIUSubmission PortalTimeline
GermanyFIU (Zoll)goAML WebWithin 3 working days
NetherlandsFIU-NLUnusual Transactions PortalImmediate (for red-flag criteria)
FranceTRACFINSIRON30 calendar days
IrelandFIU IrelandgoAML3 working days

Engineering requirement: Your compliance platform must have a structured SAR case management system — not just a spreadsheet. Cases need audit trails, supporting evidence links (transaction hash, KYC documents, blockchain analytics report), and submission confirmation records.


The FATF Travel Rule: Regulation (EU) 2023/1113 and IVMS 101 Implementation

The Travel Rule (FATF Recommendation 16) requires CASPs to pass originator and beneficiary information alongside crypto-asset transfers above €1,000. The recast Transfer of Funds Regulation — Regulation (EU) 2023/1113 — implements this in EU law (MiCA itself contains no Travel Rule article).

Technical Architecture

Sending CASP                              Receiving CASP
    │                                          │
    ├── Pre-transaction:                        │
    │   Send IVMS 101 payload via              │
    │   Travel Rule protocol ────────────────► │
    │                                          ├── Validate:
    │                                          │   - Beneficiary address match
    │                                          │   - OFAC/EU sanctions screen
    │                                          │   - VASP registration check
    │                                          │
    ├── On confirmation:                        │
    │   Sign + transmit transaction ──────────►│
    │                                          └── Log + store 5 years
    └── Store originator data 5 years

IVMS 101 payload (minimum fields):

{
  "originator": {
    "naturalPerson": {
      "name": [{"nameIdentifier": [{"primaryIdentifier": "MÜLLER", "secondaryIdentifier": "ANNA"}]}],
      "dateAndPlaceOfBirth": {"dateOfBirth": "1985-07-12", "placeOfBirth": "Berlin"},
      "geographicAddress": [{"streetName": "Unter den Linden", "buildingNumber": "5", "postCode": "10117", "townName": "Berlin", "country": "DE"}]
    },
    "accountNumber": [{"accountNumber": "bc1qar0srrr7xfkvy5l643lydnw9re59gtzzwf5mdq"}]
  },
  "beneficiary": {
    "beneficiaryVASP": {"beneficiaryVASPIdentification": {"leiCode": "529900T8BM49AURSDO55"}},
    "accountNumber": [{"accountNumber": "3FZbgi29cpjq2GjdwV8eyHuJJnkLtktZc5"}]
  },
  "transferAmount": {"amount": "2500.00", "assetType": "ETH"}
}

Travel Rule protocol support (choose one):

ProtocolNetworkEU CASPsNotes
TRISA (open)Global150+ membersOpen source, self-hostable
OpenVASPGlobal80+Ethereum-native messaging
Sygna BridgeAsia/EU60+Commercial, Chainalysis subsidiary
VerifyVASPGlobal120+Commercial, KYC Bridge

For EU-native CASPs seeking maximum sovereignty, TRISA (Travel Rule Information Sharing Architecture) is open-source and can be self-hosted in the EU without dependency on US cloud infrastructure.


Record-Keeping Requirements

MiCA's record-keeping obligations and the EU AML framework together mandate retention of:

Data CategoryRetention PeriodStorage Requirements
All transaction records5 years (10 for AML)Immutable audit log, EU-only
KYC documents (identity proofs)5 years after relationship endEncrypted, EU jurisdiction
Communications with clients5 yearsIncludes chat, email, API calls
Order book data2 yearsTime-stamped, reproducible
Internal compliance decisions5 yearsWith evidence trail

Technical storage architecture:


Business Continuity and Operational Resilience

DORA requires CASPs to have a business continuity plan tested at least annually. The plan must cover:

Recovery Time and Point Objectives

ServiceRTORPONotes
Client fund access (custody)4 hours0 (zero data loss)Regulatory minimum
Trading platform2 hours5 minutesMarket integrity
KYC/compliance systems24 hours1 hourAML obligations
Audit log access72 hours0 (zero data loss)Legal requirement

Engineering recommendation: Deploy on at least two EU cloud regions with active-active or active-standby architecture. For custody specifically, the 4-hour RTO is extremely tight — test your failover quarterly, not just annually.

Incident Communication Plan

Your BCP must specify:

  1. Internal escalation matrix (who calls whom when custody is down at 3am)
  2. Client communication templates pre-approved by legal (cannot ad-hoc communicate about incidents involving client assets)
  3. NCA notification draft (24-hour window — pre-written templates dramatically reduce response time)
  4. Regulator contact list (NCA 24h emergency contact, FIU emergency line)

Checklist: Technical Compliance Before June 30, 2026

Before your CASP goes live or receives authorization approval:

ICT & Security

AML/KYC

Travel Rule

Record-Keeping


What Comes Next in This Series

Post #3/5 will cover MiCA client asset safeguarding: segregation requirements under Art.70, the prohibition on using client assets for proprietary trading, the DLT-based proof-of-reserves approach, and the insurance/guarantee requirements for custodial CASPs.

Posts #4 and #5 will address the passporting mechanism and cross-border operating rules, and the complete MiCA compliance timeline leading to the June 30, 2026 grace period expiry.


Key Takeaways

The June 30, 2026 deadline is not a suggestion. NCAs are already receiving and processing authorization applications — the technical due diligence review is thorough. Build the infrastructure now.


Part of the sota.io EU Compliance Series. Next: MiCA Client Asset Safeguarding 2026.

EU-Native Hosting

Ready to move to EU-sovereign infrastructure?

sota.io is a German-hosted PaaS — no CLOUD Act exposure, no US jurisdiction, full GDPR compliance by design. Deploy your first app in minutes.