MiCA systems for CASPs and token issuers

Turn approved MiCA obligations into software that can be tested

Q: Does Pharos provide MiCA legal advice or authorization?

No. Qualified counsel determines classification, scope and legal sufficiency. Pharos designs, builds, integrates and tests software that implements the approved position.

Q: Should a CASP build or buy MiCA software?

Integrate bounded specialist controls. Build when proprietary infrastructure, volume, multi-service workflows or evidence requirements make packaged software inadequate. Hybrid architectures are common.

Q: What makes a MiCA software control auditable?

It links source and applicability to behavior, ownership, evidence, failure handling, acceptance tests, retention and change triggers.

Pharos Production designs, builds and integrates controls, workflows, audit trails and evidence systems for EU crypto-asset operations. The engineering chain runs from source to obligation, risk, system behavior, evidence and acceptance test.

Request a technical scope review Inspect the control map

Original Pharos system map. Legal decisions stay outside the engineering boundary. Approved obligations become observable controls.

Decide what needs to be built before estimating it

For whom: EU exchanges, custodians, wallet providers, brokers, transfer providers, advisers, portfolio managers and ART or EMT issuers.
Typical modules: KYC and AML orchestration, Travel Rule, custody reconciliation, surveillance, complaints, reporting and DORA workflows.
Engineering output: Versioned controls with owners, normal and failure paths, retained evidence and acceptance tests.
Definition of done: A reviewer can reconstruct what happened, which rule applied and what proves the result.

Start with operating reality

The control set changes with the CASP service

MiCA compliance software is not one generic product. Counsel confirms applicability. Engineering translates that decision into requirements for the actual custody model, transaction flow, jurisdictions and production systems.

Custody and administration

Join client position registers, wallet access, approvals, segregation, statements, reconciliation and correction lineage. A current balance alone does not reproduce historical client entitlements.

Operation of a trading platform

Connect admission decisions, orders, trades, timestamps, rule versions, conflicts and market-abuse investigations through stable identifiers.

Exchange for funds

Retain the client instruction, quote methodology, price, screening result, settlement state, exception and final ledger entries.

Exchange for other crypto-assets

Trace pair selection, routing, execution, on-chain or off-chain settlement, transaction monitoring and reconciliation across both assets.

Execution of orders

Version the execution policy and preserve order receipt, routing decisions, venue or counterparty, fills, rejections and client communications.

Placing of crypto-assets

Record allocation logic, approvals, disclosures, conflicts, eligible recipients, communications and changes to the placing decision.

Reception and transmission of orders

Keep the original instruction, consent, validation, destination, transmission time, acknowledgment, rejection and retry path.

Advice on crypto-assets

Version the client profile, knowledge and experience inputs, objectives, risk tolerance, recommendation, warnings and conflicts.

Portfolio management

Bind the client mandate to suitability inputs, investment decisions, valuation, rebalancing, approvals, exceptions and reporting.

Transfer services

Preserve the transfer instruction, security checks, status, fees, counterparty data and failure handling while coordinating applicable TFR workflows.

Service labels follow the MiCA crypto-asset service taxonomy. Counsel must confirm which services and member-state conditions apply before the control set is fixed.

Regulatory perimeter

Do not attribute every crypto control to MiCA

A useful architecture keeps the source of each requirement visible. The same customer or transfer flow may implement obligations from MiCA, the Transfer of Funds Regulation, DORA and the EU anti-money-laundering framework.

MiCA: authorization and service conduct

MiCA defines the CASP services and service-specific duties. The software scope can include records, complaints, custody, orders, conflicts, surveillance and reporting, but the competent authority decides authorization.

TFR: crypto Travel Rule

Regulation (EU) 2023/1113 governs originator and beneficiary information for crypto-asset transfers. Build protocol exchange, validation, self-hosted-address handling and exception evidence without calling the Travel Rule a MiCA article.

DORA: operational resilience

DORA includes authorized CASPs and asset-referenced-token issuers in scope. Engineering work can cover ICT risk, incident evidence, resilience testing, recovery and third-party dependency records.

AML and CFT: customer and transaction risk

KYC, KYB, beneficial ownership, sanctions, PEP screening, enhanced due diligence and suspicious-activity workflows arise across the applicable AML and CFT framework, not from MiCA alone.

ART and EMT: issuer obligations

Counsel-confirmed token classification changes reserve, issuance, redemption, disclosure, white-paper and reporting workflows. An issuer system is not simply another CASP service module.

The central engineering artifact

One traceability chain for every control

A control record connects the primary source and bounded obligation to applicability, risk, required behavior, retained evidence, an accountable owner, a test and a review trigger.

Source and scopeRecord the authoritative text, version and counsel-approved applicability.
Risk and behaviorDescribe the failure to prevent and the required normal, exception and recovery paths.
Evidence and ownershipName the artifacts, fields, retention rule and accountable decision-maker.
Test and changeProve retrieval and replay, then define what reopens review.

Traceability chain linking a primary source to an obligation, control, system behavior, evidence artifact and acceptance test — Original Pharos obligation-to-evidence chain. It is an engineering method, not a legal interpretation.

Control examples

Translate an obligation into behavior and a retrieval test

Representative engineering translations. Final applicability remains subject to qualified counsel.
Workstream	Operational failure	Behavior and evidence	Acceptance test
Complaints	A submission is lost or omitted from reporting.	Register every channel under a stable case ID and retain intake, acknowledgment, ownership, communications and outcome.	Reconstruct one historical case from intake through closure.
Record correction	A mutable row erases the state used by an earlier decision.	Append a correction linked to the original with actor, time, reason, approval and affected reports.	Reproduce system state immediately before and after correction.
Market abuse	An alert is closed without reviewable analysis.	Retain rule version, triggering inputs, analyst narrative, evidence, disposition and escalation.	Replay a historical case with the version active at detection.
Vendor outage	A timeout silently approves or blocks activity.	Specify timeout, retry, degraded-service, manual-review and recovery paths. Retain every fallback decision.	Simulate an unavailable provider before launch.

Reference architecture

Eight layers separate policy, workflow and durable evidence

A point solution may cover one layer. The CASP still needs an end-to-end explanation of what happened, which rule applied, who decided and where the proof can be retrieved.

1. Legal and control registry: Sources, applicability, risks, control IDs, tests and review triggers.
2. Policy and decision services: Versioned rules, approvals, overrides and exceptions.
3. Customer and counterparty: Identity, due diligence, sanctions and ongoing review.
4. Transaction and transfer: Workflow, Travel Rule exchange, screening, status and records.
5. Asset and custody: Entitlements, wallet boundaries, approvals and reconciliation.
6. Monitoring and resilience: Surveillance, incidents, continuity, recovery and vendor failure.
7. Evidence and assurance: Events, decisions, documents, tests, corrections and remediation.
8. Reporting and operations: Traceable exports, oversight, monitoring and service management.

Integration stack

Treat every provider as a bounded dependency

A vendor result becomes auditable only after the CASP records the request, response, policy version, fallback path and downstream decision. Categories below are architecture boundaries, not vendor partnerships or endorsements.

Identity, KYC and KYB

Normalize applicant, business, beneficial-owner and document outcomes behind an adapter. Preserve consent, input lineage, provider decision, manual review, retry and correction history.

Sanctions, PEP and blockchain analytics

Version screening policy and retain matched lists, wallet or transaction inputs, risk factors, analyst disposition and the reason for release, restriction or escalation.

Travel Rule messaging

Separate IVMS101 data mapping from protocol transport. Model counterparty discovery, incompatible networks, missing data, self-hosted addresses, timeouts and manual handling explicitly.

Custody, keys and ledger

Define the boundary among key management, wallet infrastructure, client entitlements and the internal ledger. Reconcile on-chain balances to books without treating a snapshot as complete proof.

Surveillance and case management

Join order, trade and transfer streams to rule versions, alert payloads, analyst queues, evidence, dispositions, escalations and reporting preparation.

Evidence, reporting and operations

Centralize immutable events, report transforms, export manifests, observability, incidents, recovery runs and vendor service evidence under consistent identifiers.

Architecture decision

Custom build, specialist integration or CASP-as-a-service?

The right path depends on control ownership, integration depth, volume, time to market, evidence requirements and exit risk. A hybrid design is often the practical result.

Decision map comparing custom build, specialist integration and CASP-as-a-service — Original Pharos decision map for choosing the delivery model.

Use the consequence of each condition to choose a delivery model.
Condition	Usually favors	Why it matters
Proprietary custody, ledger, exchange or risk infrastructure	Custom build	The control depends on internal state and failure behavior a generic tool cannot observe.
Bounded identity, screening, analytics or messaging	Specialist integration	A provider supplies the capability while orchestration retains evidence and fallback decisions.
Standard model, lower volume and urgent launch	CASP-as-a-service	Speed can outweigh differentiation if custody, evidence, residency and exit requirements fit.
Several CASP services share identities and reports	Hybrid platform	Shared primitives reduce duplication while service controls stay distinct.

Commercial planning

Use published Pharos ranges as inputs, not promises

The canonical Pharos MiCA service page currently publishes directional software-planning benchmarks. An executable estimate still depends on the approved service scope, existing systems, integrations, evidence depth, security work and acceptance gates.

Focused MiCA MVP

Pharos reports about 12 weeks as a planning benchmark for a focused MiCA MVP. Discovery must first prove that the selected controls, data and dependencies fit that boundary.

Module extension

Pharos reports that some Travel Rule or proof-of-reserves modules can add roughly 2 to 4 weeks. Protocol coverage, custody topology and failure paths determine whether that range applies.

Software budget envelope

Pharos publishes an indicative $60,000 to $500,000+ range for MiCA software. It is not a quote, market average or guarantee of scope, schedule, authorization or outcome.

Source: Pharos MiCA compliance software development, checked 13 August 2026. Unless an executed proposal states otherwise, software estimates exclude authority fees, required own funds, counsel, third-party subscriptions, assurance, cloud costs and internal staffing.

Implementation pathway

Six stages with explicit exit gates

01
Scope and sources
Exit: every requirement has a source and accountable legal or compliance owner.
02
Controls and evidence
Exit: no priority control exists only as a policy phrase or vendor feature.
03
Architecture and sourcing
Exit: every dependency has normal, timeout, retry, unavailable and recovery behavior.
04
Implementation
Exit: demos show the behavior and the evidence written behind it.
05
Production readiness
Exit: an independent reviewer can replay representative controls.
06
Operation and change
Exit: incidents, vendor changes and regulatory updates reopen visible review.

Acceptance

Specify artifacts, not "MiCA-ready"

Scope pack

Services, token types, jurisdictions, NCA, assumptions, exclusions and unresolved questions.

Control register

Obligation, risk, behavior, owner, evidence, test, retention and review trigger.

Architecture pack

Context, data flows, trust boundaries, identity, integrations, resilience and decisions.

Working software

Agreed source, configuration, migrations, adapters, infrastructure and delivery pipeline.

Assurance evidence

Integration, security, performance, continuity, reconciliation and retrieval results.

Operations and handover

Monitoring, runbooks, recovery, access, open risks, support and exit steps.

E-E-A-T and limits

Relevant Pharos delivery evidence, with attribution

These identity-platform cases are adjacent engineering evidence, not proof of MiCA authorization expertise and not promises of comparable outcomes.

Nextcheck identity platform

The published Pharos case reports capacity for more than 5,000 document verifications per day and 99.8% OCR accuracy.

Read the published case

Kimlic blockchain KYC

The published Pharos case reports onboarding completion increasing from 62% to 89% and monthly verification flows scaling from 20,000 to 140,000.

Read the published case

The case statements above were checked against the linked first-party pages on 13 August 2026. Case outcomes do not promise comparable results.

Primary-source discipline

Legal anchors for engineering analysis

Bind every control to the current consolidated text, Level 2 and Level 3 measures, ESMA or EBA guidance and the relevant NCA position. A page summary is not an operational legal source.

Entity glossary

Terms that change software scope

MiCA: Regulation (EU) 2023/1114, the EU framework for crypto-asset issuance and crypto-asset services.
CASP: A crypto-asset service provider authorized to perform one or more services defined by MiCA.
NCA: The national competent authority that handles authorization and supervision in the relevant member state.
TFR: Regulation (EU) 2023/1113, which extends transfer-information requirements to crypto-assets.
DORA: Regulation (EU) 2022/2554 on digital operational resilience for financial entities, including authorized CASPs.
ART: An asset-referenced token whose issuer workflows can include reserve, redemption, disclosure and reporting controls.
EMT: An e-money token referencing one official currency, with a distinct issuer and redemption model.
IVMS101: An interVASP data standard commonly used to structure originator and beneficiary information for Travel Rule exchange.
STOR: A suspicious transaction and order report supported by explainable detection, investigation and decision evidence.

Buyer questions

MiCA software FAQ

Answers stay inside the engineering boundary and do not replace legal analysis.

Does Pharos provide MiCA legal advice or authorization?

No. Qualified counsel determines classification, service scope, authorization strategy and legal sufficiency. The competent authority decides whether to authorize an applicant. Pharos builds and tests systems that implement the approved position.

Is KYC a single MiCA software requirement?

No. Customer due diligence, sanctions and AML monitoring sit across the AML framework, while the crypto Travel Rule comes from Regulation (EU) 2023/1113. The architecture can join these workflows without misattributing their legal sources.

Should a CASP build or buy MiCA software?

Integrate when a specialist provider covers a bounded control and acceptable evidence, residency and exit requirements. Build when proprietary infrastructure, volume, multi-service workflows or deep integrations make a packaged control set inadequate.

What makes a software control auditable?

It links source and applicability to system behavior, ownership, evidence, failure handling, acceptance tests, retention and change triggers. A reviewer must be able to retrieve and replay a historical case.

Can one platform cover all ten CASP services?

Shared identity, workflow, event, evidence, reporting and access-control components can support several services. Custody reconciliation, trading surveillance, advice suitability and transfer messaging still need distinct behavior.

Technical scoping

Bring the scope, architecture and evidence gaps

Share the service and token types, target jurisdictions, current systems, key vendors and launch window. The first decision may be an assessment, integration, custom build or a recommendation not to build.

Request a MiCA scope review Canonical Pharos MiCA service

Editorial owner: Pharos Production
Engineering review: Dmytro Nasyrov, Founder and CTO
Last source check: 13 August 2026
Review triggers: Source, service, classification, vendor, architecture, incident or failed-control change

Scope notice: This page is general technical information and a commercial description, not legal, regulatory, compliance, financial or authorization advice. Qualified counsel must determine classification, in-scope services, authorization route, jurisdiction-specific requirements and legal sufficiency. Pharos does not guarantee compliance, regulator acceptance, authorization, timelines or outcomes. Named vendors, if discussed during scoping, are integration examples rather than partnerships or endorsements.