Regulatory Readiness
EU Regulatory Readiness
MiCA, DORA, the EU Travel Rule, AML obligations and payment-services requirements are implemented as platform modules, records and operating workflows rather than left in policy documents.
Management Perspective
One Rulebook. Many Home States.
MiCA, DORA and the EU AML framework create a common rulebook, yet the EU is not one uniform licensing market. The selected home Member State, its National Competent Authority, local banking access and supervisory expectations shape how an authorisation programme actually runs.
The MiCA transition has ended. New EU cryptoasset projects must be designed for an authorised CASP operating model from the beginning, which moves records, controls and resilience from a post-launch task to a design requirement.
Grumpio provides one technical product base and a country-specific regulatory implementation programme. Our EU implementation combines production-tested fintech software with a home-state-specific MiCA, payments, DORA and AML readiness programme, so management coordinates one delivery plan rather than a chain of suppliers.
MiCA and CASP Readiness
Readiness Across the Operating Model
Grumpio implements the technical and operating layers a CASP application and ongoing supervision depend on; governance, prudential and legal workstreams remain with the customer's advisers. Because new EU cryptoasset projects must operate as authorised CASPs from the beginning, these layers are engineered into the platform before launch rather than retrofitted. Scope is confirmed against the selected home state and the requested permissions.
Trading, wallet and ledger
Order execution, custody workflows and financial records are engineered as one auditable platform, structured around supervisory expectations.
Administration and permissions
Role-based access, segregation of duties and audit logging keep operational, financial and administrative actions separate and traceable.
Customer and asset records
Customer, order, transaction and asset data is produced by the system as reportable records rather than compiled manually.
AML, KYC and transfer controls
AML screening, KYC verification, wallet-risk checks and transfer controls are integrated into onboarding and operations through Legichain or the customer's providers.
Reporting and audit evidence
Reporting data, logs and operating records are designed so audit evidence is a by-product of daily operation, not a separate collection exercise.
Deployment and handover
EU-region deployment, documentation and a structured handover allow the customer's engineering team to operate and extend the platform.
For the CTO
DORA as the Operating Baseline
DORA has applied since January 2025 and is a current operating framework for CASPs, payment and e-money institutions. We build the platform and operating evidence required to embed DORA into the technology lifecycle rather than treating it as a separate policy exercise.
Review the engineering approach- ICT asset and service maps: services, dependencies and responsibilities are recorded and kept current.
- Incident workflows: detection, classification and reporting flows produce the records incident obligations require.
- Logging and observability: customer, administrator, financial and system events are centrally monitored and reportable for audit.
- Continuity and recovery: backup is designed together with restore testing, recovery objectives and alternative operating environments.
- Third-party and change control: provider inventories, registers of information, exit architecture and evidenced release pipelines are maintained as structured data.
Supervisory Architecture
Distributed Supervision, Defined Roles
EU supervision is distributed across European and national bodies rather than held by one central regulator. Authorisation applications are generally received and assessed by the National Competent Authority of the selected home Member State, which then supervises the authorised firm, while European authorities coordinate standards, registers and supervisory convergence. The table summarises high-level public roles; the exact structure is confirmed for the selected home state and activity model.
| Authority | High-Level Role |
|---|---|
| Home-state NCA | Receives and assesses authorisation applications and supervises the authorised firm |
| ESMA | Coordinates MiCA supervision and maintains the EU register; it does not authorise every CASP directly |
| EBA | Develops payment-services, e-money and related technical standards and guidance |
| AMLA | Coordinates EU-level AML/CFT work since the start of 2026; direct supervision of selected entities is expected from 2028 |
| Data-protection authorities | Enforce GDPR at Member State level, with the EDPB supporting consistent interpretation |
Most firms remain supervised by their national authorities. Framework status reviewed: 16 July 2026.
For the Compliance Leader
Transfers, Screening and Evidence
We turn regulatory requirements into operating workflows, permissions, records, alerts and controls rather than leaving them in policy documents. For an EU business, that covers the crypto Travel Rule, screening obligations and supervisory records.
Screening technology supports, and never replaces, the customer's MLRO, national AML policy and final regulated decisions. The incoming EU AML rulebook, applying in stages from mid-2027, is monitored so workflows can be adjusted.
- Travel Rule workflows: originator and beneficiary information, counterparty CASP data and self-hosted wallet declarations are captured, screened and recorded according to the operating model.
- Screening: person and company screening, PEP and sanctions, adverse media and multi-chain wallet risk run through Legichain AML screening or the customer's chosen providers.
- Identity verification: document, NFC and liveness-based KYC verification delivers automated onboarding decisions that the customer's own risk policy then acts on.
- Monitoring and evidence: periodic re-screening keeps customer and wallet risk current, and results are exportable as structured records for internal review and supervisory requests.
Payments and E-Money
PSD2 Today. PSD3 Ahead.
PSD2 and EMD2, with national implementation, strong customer authentication and DORA, remain the current framework for EU payment and e-money institutions, alongside the Instant Payments Regulation where it applies. PSD3 and the Payment Services Regulation are incoming but have not yet replaced that framework, so current projects are built on the rules in force and the transition is tracked through the agreed support model.
-
Home-state adaptation
The e-money platform is adapted to the customer's home-state licence, safeguarding model, payment rails and card-programme structure — the scope is described on the e-money platform software page.
-
Safeguarding and reconciliation
Ledger mapping, safeguarding-account records, reconciliation and exception workflows produce the records the firm's safeguarding model requires. Grumpio does not hold, safeguard or transmit customer funds.
-
Crypto cards and wallets
A crypto-card or wallet proposition can touch MiCA permissions, payment or e-money authorisation and card-scheme rules at once; the architecture is mapped across all of these layers rather than reduced to a single licence.
Data Architecture
GDPR and Data Residency
EU customer environments can be deployed on-premises or in dedicated EU-region infrastructure, with data flows and retention adapted to the home-state operating model. Data storage and deployment architecture can be configured around the customer's operating jurisdiction and institutional requirements.
Deployment location is one element of a wider data architecture: lawful basis, retention, minimisation, access control and breach records are addressed in the platform design, and transfers outside the EEA are assessed with appropriate safeguards. Hosting in one country does not by itself resolve every data-protection obligation.
Related Solutions
Readiness Progresses with the Product
EU readiness is not delivered as a report. It is engineered on the platform the business will operate, in the same project plan as deployment and integrations. The complete programme is described on the regulatory readiness page.
-
Crypto exchange software
Trading, wallets, ledger, Travel Rule support and back office engineered for an authorised CASP operating model.
-
E-money platform software
Accounts, double-entry ledger, safeguarding records, payments and back office adapted to the home-state licence.
-
AML screening software
Person and company screening, PEP and sanctions, adverse media and wallet risk with exportable evidence.
-
KYC verification software
Automated document, NFC and liveness verification integrated into EU onboarding journeys.
Delivery Process
From Home State to Evidence
Readiness is delivered as an engineering process with verifiable outputs, run in parallel with platform deployment rather than as a separate documentation exercise. We adapt a production-tested platform to the selected home state, permissions, suppliers, data model and supervisory expectations, so the sequence below is planned around the jurisdiction and the activity model.
-
Scope and home state
The activity model, requested services, target home Member State and existing systems are assessed together.
-
Requirement mapping
MiCA, DORA, Travel Rule, AML, payments and data requirements are mapped to platform modules, records, workflows and suppliers for the selected jurisdiction.
-
Implementation
Modules, permissions, integrations and records are configured on the platform; readiness work progresses in parallel with deployment and customisation.
-
Evidence and validation
Records, logs, reports and continuity outputs are tested to confirm that the system produces what supervision and audit expect.
-
Operation and updates
Incoming texts such as PSD3, the PSR and the EU AML package are monitored after go-live, and changes are applied through the agreed support model.
FAQ
Frequently Asked Questions
Authorisation is generally handled by the National Competent Authority of the selected home Member State, which receives the application and supervises the authorised firm. ESMA supports supervisory convergence and maintains the EU register, but it is not automatically the direct licensing authority for every CASP.
The MiCA transition has ended. New EU cryptoasset projects must be designed for an authorised CASP operating model from the beginning. In practice, trading, custody, records, AML/KYC and resilience controls are engineered into the platform before launch rather than retrofitted, and the implementation is adapted to the selected home state.
DORA has applied since January 2025 and is treated as the current operating framework rather than future legislation. ICT asset and service maps, incident workflows, centralised logging, backup and restore testing, third-party inventories and change controls are configured as part of the platform, so the operating evidence DORA expects is produced by the system itself.
EU customer environments can be deployed on-premises or in dedicated EU-region infrastructure, with data flows and retention adapted to the home-state operating model. Hosting location alone does not settle every data-protection question, so transfers, retention and access are assessed as part of the deployment design.
PSD2 and EMD2, together with national implementation, remain the current EU payments and e-money framework. PSD3 and the PSR are an incoming framework that had not been formally adopted at the last review date. Platforms are structured so the transition can be tracked and applied through the agreed support model.
No. Grumpio delivers the software, records, workflows and operating controls that an authorisation programme depends on, and coordinates with the customer's legal and compliance advisers. Legal opinions and the authorisation decision remain with the customer's counsel and the relevant national authority.
The equivalent programme for UK businesses is described on the UK regulatory readiness page.
Next Step
Plan the EU Readiness Programme
The first meeting reviews the activity model, candidate home states and current systems, then outlines how platform delivery and readiness work would run in one plan.