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
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:
| Requirement | Engineering Implication |
|---|---|
| Asset inventory of all ICT systems | Config management, CMDB, infrastructure-as-code registry |
| Threat and vulnerability assessment | Regular pen tests, CVE scanning (weekly minimum) |
| Business continuity plan (BCP) | Multi-region failover, defined RTO/RPO for each service |
| ICT incident classification system | Automated severity scoring, on-call runbooks |
| Recovery testing | Annual 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:
- Service unavailability exceeding 4 hours during business hours
- Data breach affecting more than 1,000 client accounts
- Successful external cyber attack on trading or custody infrastructure
- Loss of client asset data or transaction records
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:
- Hardware Security Modules (HSMs) for private key generation and storage (FIPS 140-2 Level 3 or equivalent)
- Multi-party computation (MPC) or multi-signature (multisig) schemes for transaction authorization
- Geographic separation of key shares (at least 2 EU jurisdictions for institutional custody)
- Documented key rotation schedules (annual minimum, or after any personnel change with key access)
- Offline ("cold") storage for at least 95% of client crypto-assets not needed for immediate settlement
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:
- No US-jurisdiction CDN with caching of trading data (CLOUD Act exposure). CloudFlare Enterprise with EU Data Localization Suite or EU-native alternatives (Fastly EU, OVHcloud CDN, Hetzner CDN) required.
- Transaction logs must reside in the EU — specifically in a jurisdiction from which your NCA can compel production without international legal assistance.
- Admin access to custody infrastructure must be authenticated via hardware tokens (FIDO2 or HSM-based certificates), not software TOTP.
Penetration Testing Requirements
DORA's resilience-testing standard requires:
| Test Type | Minimum Frequency | Scope |
|---|---|---|
| External pen test | Annual | All public-facing APIs, smart contract interfaces |
| Internal red team | Every 2 years | Custody infrastructure, key management |
| Smart contract audit | Before each contract deployment | All 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):
| Vendor | EU Data Processing | eIDAS Support | HQ |
|---|---|---|---|
| Veriff | Estonia | Yes (QES/QSig) | Tallinn, EE |
| Ondato | Lithuania | Yes | Vilnius, LT |
| IDnow | Germany | Yes (QES) | Munich, DE |
| Onfido (Entrust) | UK/EU | Partial | London (EU processing available) |
| Sumsub | Cyprus | Partial | Limassol, 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:
- Mixer/tumbler outputs (Tornado Cash, Wasabi Wallet coinjoins)
- Darknet market addresses
- Sanctioned addresses (OFAC SDN list, EU consolidated list)
- High-risk exchange addresses (FATF "red flag" indicators)
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):
| Jurisdiction | FIU | Submission Portal | Timeline |
|---|---|---|---|
| Germany | FIU (Zoll) | goAML Web | Within 3 working days |
| Netherlands | FIU-NL | Unusual Transactions Portal | Immediate (for red-flag criteria) |
| France | TRACFIN | SIRON | 30 calendar days |
| Ireland | FIU Ireland | goAML | 3 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):
| Protocol | Network | EU CASPs | Notes |
|---|---|---|---|
| TRISA (open) | Global | 150+ members | Open source, self-hostable |
| OpenVASP | Global | 80+ | Ethereum-native messaging |
| Sygna Bridge | Asia/EU | 60+ | Commercial, Chainalysis subsidiary |
| VerifyVASP | Global | 120+ | 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 Category | Retention Period | Storage Requirements |
|---|---|---|
| All transaction records | 5 years (10 for AML) | Immutable audit log, EU-only |
| KYC documents (identity proofs) | 5 years after relationship end | Encrypted, EU jurisdiction |
| Communications with clients | 5 years | Includes chat, email, API calls |
| Order book data | 2 years | Time-stamped, reproducible |
| Internal compliance decisions | 5 years | With evidence trail |
Technical storage architecture:
- Immutable log store: Apache Kafka with log compaction disabled (append-only) or AWS QLDB equivalent on EU-hosted infrastructure. Hetzner Object Storage + object lock is a cost-effective EU-native option.
- Encryption at rest: AES-256 minimum. Key management via HSM or EU-region managed KMS (Hetzner, OVHcloud, or on-prem).
- Access control: Role-based access with compliance officer override. All admin access logged with user, timestamp, and query.
- Backup and geo-redundancy: Two EU data centres minimum (different member states recommended for catastrophic event scenarios).
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
| Service | RTO | RPO | Notes |
|---|---|---|---|
| Client fund access (custody) | 4 hours | 0 (zero data loss) | Regulatory minimum |
| Trading platform | 2 hours | 5 minutes | Market integrity |
| KYC/compliance systems | 24 hours | 1 hour | AML obligations |
| Audit log access | 72 hours | 0 (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:
- Internal escalation matrix (who calls whom when custody is down at 3am)
- Client communication templates pre-approved by legal (cannot ad-hoc communicate about incidents involving client assets)
- NCA notification draft (24-hour window — pre-written templates dramatically reduce response time)
- 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
- Documented ICT risk management framework (DORA)
- HSM infrastructure for private key management (custody services)
- Multi-region failover tested (RTO ≤4h for custody)
- Automated incident detection with 24h NCA notification capability
- Pen test completed (external, within last 12 months)
- Smart contract audit completed (if applicable)
AML/KYC
- KYC vendor with EU data processing and eIDAS compatibility
- Liveness check at onboarding (ISO 30107-3 PAD Level 2)
- Sanctions screening live (EU consolidated list + OFAC)
- Transaction monitoring system deployed and tuned
- Blockchain analytics integration (for identifying mixer/sanctions exposure)
- SAR filing capability (FIU portal integration or compliant manual process)
Travel Rule
- TRISA/OpenVASP or commercial Travel Rule protocol implemented
- IVMS 101 payload generation and validation
- Counterparty CASP discovery and VASP registry lookup
- <€1,000 vs ≥€1,000 routing logic (Sunrise issue handling)
Record-Keeping
- Immutable audit log (5-year retention minimum)
- KYC document store (5 years, encrypted, EU jurisdiction)
- Order book / transaction archive (2-year minimum)
- BCP documented and tested (annual drill scheduled)
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
- ICT risk management for CASPs comes from DORA (with MiCA Art.67-68 governance obligations alongside): documented frameworks, 24h incident reporting, and annual testing are mandatory.
- HSMs for custody are not optional — software-only key storage will not survive NCA scrutiny.
- AML/KYC is a full engineering project, not a checkbox: EU-native KYC vendors, transaction monitoring pipelines, blockchain analytics, and SAR case management all require dedicated development work.
- The Travel Rule (Regulation EU 2023/1113, IVMS 101) requires inter-CASP communication infrastructure — TRISA is the open-source EU-native option.
- Record-keeping means immutable, auditable, encrypted, EU-only storage for 5-10 years. Design your data architecture for this from day one.
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.