Pharos Production designs, builds and integrates MiCA compliance software for EU crypto-asset service providers and token issuers. We translate counsel-approved obligations into controls, workflows, audit trails, evidence artifacts and acceptance tests. The engineering chain is source to obligation to risk to system behavior to evidence to test. Pharos does not provide legal advice or promise authorization. We make the approved legal scope observable, testable and retrievable.
Start with a technical scope review: identify the in-scope CASP services, token types, systems of record, third-party dependencies and evidence gaps before estimating a build.
Request a MiCA software scope review | Review the canonical Pharos MiCA service
This page is a buyer-operable specification, not a generic capability catalog. It explains what a MiCA software project contains, when a custom build is justified, which artifacts should be delivered and how the work can be accepted.
Primary buyers
EU exchanges, custodians, wallet providers, brokers, transfer providers, advisers, portfolio managers and ART or EMT issuers.
Typical project types
MiCA readiness assessment, compliance architecture, KYC and AML orchestration, Travel Rule integration, custody reconciliation, market-abuse surveillance, complaints handling, evidence stores, regulatory reporting and DORA workflows.
Engineering boundary
Pharos implements the legal position confirmed by qualified counsel. We do not classify tokens, select an authorization class or guarantee a national competent authority decision.
Definition of done
Each control has an owner, normal path, failure path, evidence artifact, retention rule, acceptance test, change trigger and retrieval test.
Current Pharos evidence
Founded in 2013, 90+ engineers, 110+ applications delivered and 200+ clients. The canonical site reports a 5/5 Clutch rating from 101 verified reviews as of 2026. Verify current credentials during procurement.
Company facts and case counts were checked against the Pharos Production homepage and published case-study index on 13 August 2026.
Define the system: see the service-type scope, module catalog and reference architecture.
Choose build or buy: use the build, integrate or CASP-as-a-service decision rules.
Estimate the project: review software cost bands, timeline drivers and excluded costs.
Evaluate a supplier: use the partner checklist, deliverables and acceptance gates.
Validate evidence: open the Control Map, Architecture Worksheet, Implementation Notes and Methodology pages in this site.
MiCA compliance software is not one product. The control set changes with the crypto-asset services performed, the custody model, the token type, the national competent authority, the jurisdictions served and the systems already in production. Counsel determines applicability. Engineering then turns that decision into system requirements.
A trading venue needs more than customer onboarding. Its scope can include order and trade surveillance, listing and asset-review workflows, market-abuse case management, conflicts controls, transaction records, complaints, Travel Rule data exchange, regulatory exports and operational resilience. The technical design must reconcile the matching engine, client ledger, custody platform and market-data sources by stable identifiers. An alert that cannot be replayed against the rule version and source data used at decision time is weak evidence.
Custody projects center on client asset segregation, wallet ownership, key-control boundaries, transaction approval, internal-ledger reconciliation, incident evidence and withdrawal continuity. The key question is not whether a dashboard displays balances. It is whether a reviewer can connect a client entitlement to the internal ledger, on-chain wallet, approval chain and correction history for a historical point in time. A multisignature arrangement changes operational controls but does not answer the legal custody question on its own.
Order reception, transmission, execution and transfer services need traceable instructions, routing decisions, timestamps, status changes, counterparty data and exception handling. A transfer workflow may also need Travel Rule exchange under Regulation (EU) 2023/1113, counterparty VASP due diligence, unhosted-wallet handling and sanctions screening. These are linked workstreams, but they should not be collapsed into a misleading feature called "MiCA KYC."
Advice and portfolio-management controls can require client profiling, suitability inputs, recommendation records, conflict checks, approval rules, disclosures and evidence that the recommendation used the information available at that time. Version the questionnaire, policy and scoring logic. If the current policy overwrites the prior version, the system may be unable to reconstruct why a historical recommendation was made.
Issuer systems vary by counsel-confirmed token classification. Asset-referenced token and e-money token operations can involve reserve management, redemption, issuance and burn controls, disclosure workflows, white-paper versioning and ongoing reporting. Other crypto-assets may have different disclosure and marketing requirements. Pharos builds the software configured to the classification supplied by counsel. We do not make the ART, EMT, financial-instrument or other-crypto-asset determination.
MiCA sits beside other EU regimes. The Travel Rule comes from the Transfer of Funds Regulation. Customer due diligence and sanctions work sit within the AML framework. DORA adds ICT-risk and resilience obligations where it applies. A useful architecture keeps the legal anchors separate while allowing one operational process to reuse identity, cases, events, evidence and reporting.
We build risk-based onboarding and ongoing-review workflows around identity and business verification, beneficial owners, sanctions and PEP screening, risk scoring, document review, consent, analyst queues and evidence retention. The system can integrate specialist providers without making one vendor's response the whole control. It records the input, provider response, rule version, human decision, override reason and downstream account state.
Travel Rule software exchanges originator and beneficiary information under Regulation (EU) 2023/1113. A production design can normalize IVMS101-structured data across more than one network, verify counterparty coverage, apply data-minimization rules, handle unhosted wallets and preserve the reason for a release, hold or escalation. Protocol coverage is not universal, so the unavailable and uncovered-corridor paths belong in the specification.
We connect custody events, signed wallet-ownership proofs, client entitlements and the internal ledger. Periodic attestations are useful for external assurance, but a snapshot does not replace operational reconciliation. A stronger control detects drift, records its cause, opens an exception and preserves the correction chain. The acceptance test should cover normal settlement, late chain finality, reorganization, vendor outage, manual correction and a historical replay.
Surveillance can correlate order-book, trade, account, wallet and cross-venue signals for patterns such as wash trading, spoofing, layering or suspicious coordination. The system should version detection logic, preserve the triggering inputs and route alerts to human analysis. It must retain the analyst narrative, evidence, disposition, escalation and any suspicious transaction and order report workflow. We do not promise zero false positives.
A complaints module joins web, email, paper and support-channel submissions into one register with stable case IDs. It preserves the original complaint, language, acknowledgment, admissibility decision, ownership, investigation, communications, outcome and remediation. Management reports must reconcile to the underlying cases. A complaint recorded in an inbox but absent from the register is a control failure, even if the customer received a reply.
We design records around identity, time, state, rule version, actor, approval, source and correction lineage. Reports should be reproducible from retained events, not copied into spreadsheets that lose provenance. Export packages can include the source anchor, control version, population, sample, exceptions, approvals and retrieval log required for internal review, audit or supervisory response.
Where DORA applies, the same control fabric can support ICT-risk registers, third-party dependencies, incident classification, continuity scenarios, recovery evidence, remediation and management review. The software must distinguish a test plan from evidence that a test occurred. Start and recovery timestamps, data-integrity checks, communications, deviations and retest status belong in the retained record.
Issuer modules can support reserve data, mint and burn approvals, redemption, disclosure, white-paper versioning, complaints and reporting. The workflow and evidence depend on the token class and the issuer's legal structure. Significant-token supervision and local implementation details may add reporting or governance requirements. Keep those rules configurable rather than hard-coding a one-time interpretation.
Every control record should follow one traceability chain: primary source, bounded obligation, applicability, operational risk, required system behavior, evidence artifact, accountable owner, control test and review trigger. The examples below show the engineering translation. They are not legal interpretations.
Legal anchor: MiCA Article 71 and Delegated Regulation (EU) 2025/294. Operational risk: a complaint is lost, handled inconsistently or excluded from reporting. System behavior: register each channel, assign a stable case ID, enforce explicit states and retain communications. Evidence: original submission, acknowledgment, decision, owner, timestamps, measures taken and reporting inclusion. Test: reconstruct one historical case from intake through closure without relying on private messages.
Legal anchor: counsel-approved record-keeping scope and Delegated Regulation (EU) 2025/1140. Operational risk: a mutable row shows the latest value but erases what a report or decision used earlier. System behavior: append a correction event linked to the original with actor, time, reason and approval. Evidence: original event, correction, affected reports and reprocessing result. Test: reproduce the state before and after the correction.
Legal anchor: the approved MiCA continuity requirements, Delegated Regulation (EU) 2025/299 and DORA where applicable. Operational risk: a continuity exercise is marked complete although service restoration and data integrity were not tested. System behavior: define scenarios, expected sequence, RTO/RPO, evidence capture and remediation before the exercise. Evidence: approved scenario, participants, timestamps, data checks, communications and retest. Test: recover a representative service and reconcile post-recovery data.
Legal anchor: MiCA Article 92 and Delegated Regulation (EU) 2025/885. Operational risk: an alert is closed without reviewable human analysis, or a rule update makes it impossible to replay. System behavior: retain the rule or model version, triggering data, analyst actions, attachments, narrative and escalation. Evidence: alert package, disposition and quality review. Test: replay a historical case using the version active at detection time.
Legal anchor: the obligation implemented by the third-party check and the approved outsourcing or ICT-risk requirements. Operational risk: a timeout silently approves activity or blocks it with no reviewable trail. System behavior: set timeout, retry, circuit-breaker, degraded-service, manual-review and recovery rules. Evidence: request, provider response or timeout, fallback decision, reviewer, client impact and later reconciliation. Test: simulate an unavailable KYC, analytics, Travel Rule or custody provider before launch.
The architecture should separate policy, operational workflow and durable evidence. A point solution may cover one layer. The CASP still needs an end-to-end path that explains what happened, which rule applied, who decided and what record proves it.
Stores source identity, article, version, applicability, interpretation owner, operational risk, control ID, test and review trigger. This is the traceability root. It should reference counsel-approved scope rather than copying legal conclusions into code comments.
Maintains consistent identifiers for client, business, beneficial owner, account, wallet, asset, order, trade, transfer, complaint, alert and incident. Weak identity resolution causes evidence gaps even when each individual tool works correctly.
Normalizes provider APIs, internal systems and manual channels. It applies timeouts, retries, fallbacks, routing and data-minimization rules. Common integration categories include KYC/KYB, sanctions, on-chain analytics, Travel Rule networks, custody, case management, market data and regulatory reporting. Naming a product does not imply a partnership or legal endorsement.
Runs states, assignments, approvals, service levels, escalations and exception paths. Complaints, investigations, listing reviews, onboarding cases and incidents can share workflow primitives while retaining separate legal anchors and reporting requirements.
Versions policy rules, thresholds, scenarios and model releases. Every result should identify the rule set used. Human overrides require a reason, authority and secondary review where the control design calls for it.
Preserves events, decisions, documents, communications, approvals, configuration snapshots and corrections. Immutability does not mean errors cannot be corrected. It means the correction does not erase the prior content or the reason for change.
Produces management views, reconciliation, control-testing samples and regulator-ready exports from the same retained records. A report is stronger when each figure links back to the population and cases it summarizes.
Provides access control, encryption, secrets and key boundaries, audit logging, monitoring, backup, recovery, vulnerability management and incident evidence. The design should expose failure rather than convert it into a silent default.
Textual architecture mirror: primary sources and counsel-approved scope feed the control registry. Identity and integrations feed workflows. Workflows call rules and external services. Every decision writes an event and evidence artifact. Reporting reads the retained evidence. Security and resilience apply across every layer.
MiCA defines ten crypto-asset services. A single authorization can include several, so use a component map rather than buying a generic "MiCA platform." The exact control set remains subject to counsel and the national competent authority.
Core components: client entitlement ledger, wallet and key-control boundary, segregation, approvals, reconciliation, statements, incident evidence, complaints and continuity. Key acceptance question: can the team reconstruct a historical entitlement and every movement affecting it?
Core components: listing and asset review, order and trade capture, market-abuse surveillance, rule versioning, conflict controls, resilient operations, reporting and investigation cases. Key acceptance question: can an alert be replayed across the matching engine, market data and analyst decision?
Core components: pricing and execution records, client disclosures, settlement, transaction monitoring, sanctions and wallet screening, custody links, complaints and reporting. Key acceptance question: do the order, execution, ledger and settlement records reconcile under normal and failed settlement paths?
Core components: instruction capture, timestamps, routing policy, venue or counterparty decision, status model, communication, best-execution evidence where applicable, exceptions and record retention. Key acceptance question: can a reviewer follow the instruction from receipt to outcome and explain each routing change?
Core components: client profile, suitability inputs, conflicts, recommendation or mandate, approvals, disclosures, versioned policy, communications and review. Key acceptance question: can the historical recommendation be reconstructed with the client facts and rule version available at the time?
Core components: transfer instruction, beneficiary and originator data, Travel Rule exchange, counterparty VASP checks, unhosted-wallet handling, sanctions, approval, execution status and failure recovery. Key acceptance question: what happens when the counterparty protocol is unavailable or the data is incomplete?
A custom platform is not automatically the best answer. The correct decision depends on control ownership, integration depth, volume, time-to-market, evidence requirements and exit risk.
You operate proprietary custody, ledger, exchange or risk infrastructure.
Several CASP services share identities, cases, evidence and reporting.
Multi-jurisdiction operations require configurable workflows and exports.
Vendor per-seat or per-transaction economics become material at scale.
Your national competent authority or internal assurance model needs evidence that packaged tools cannot produce.
Data residency, privacy, latency or availability rules require control over architecture.
Identity verification, sanctions data, on-chain analytics, Travel Rule messaging and custody infrastructure often benefit from specialist providers. Keep the provider behind an orchestration boundary. Record inputs, outputs, versions, fallbacks and human decisions in your own evidence model. Avoid making a vendor dashboard the only place a control exists.
An early-stage product with a standard operating model may reach market faster through a licensed platform or a packaged RegTech stack. This can be the better choice when transaction volume is low, the custody model fits the provider and proprietary control behavior is not a product advantage. Confirm the legal and outsourcing implications with counsel.
Counsel-confirmed token and service scope.
A named business owner and engineering owner.
Current system and data-flow inventory.
Known vendors, manual processes and failure paths.
An evidence and retention model.
A budget that includes remediation after gaps are found.
Each stage produces a reviewable artifact and a stop-or-proceed decision. Delivery does not move forward because a workshop happened. It moves when the required output is complete enough for the next stage.
Inputs: counsel-approved service and token scope, jurisdictions, NCA, existing policies and systems. Output: source hierarchy, applicability register, assumptions and unresolved questions. Exit gate: every requirement entering engineering has a source and an accountable legal or compliance owner.
Inputs: approved obligations and current process. Output: obligation-to-risk-to-behavior-to-evidence records with owners, tests and change triggers. Exit gate: no high-priority control is represented only by a policy statement or vendor feature name.
Inputs: control map, system inventory, volumes, availability needs and vendor contracts. Output: system boundary, data flows, integration plan, threat model, build-vs-buy decisions and delivery backlog. Exit gate: each dependency has normal, timeout, unavailable, retry and recovery behavior.
Inputs: accepted architecture and backlog. Output: working controls, integration adapters, cases, reporting, event capture and automated tests. Exit gate: sprint demos show both the business path and the evidence written behind it. Compliance findings return to the backlog rather than waiting for final review.
Inputs: release candidate, test data and operating procedures. Output: traceability report, security tests, performance evidence, failure simulations, retrieval tests, runbooks, monitoring and rollback. Exit gate: an independent reviewer can replay representative controls without developer memory or private messages.
Inputs: live controls, source-change monitoring, incidents and test results. Output: patches, rule updates, periodic tests, exception reviews and change evidence. Exit gate: legal, service, vendor, model and incident changes trigger review through a visible workflow.
A serious proposal should name the artifacts, owners and acceptance method. "MiCA-ready platform" is not an acceptance criterion.
Scope pack: service types, token types, jurisdictions, NCA, legal anchors, assumptions, exclusions and unresolved questions.
Control register: obligation, risk, required behavior, owner, evidence, test, retention and review trigger.
Architecture pack: context diagram, data flows, trust boundaries, identity model, integrations, resilience and architectural decisions.
Delivery backlog: user and control stories, failure paths, acceptance criteria, dependencies and release sequence.
Working software: source code, configuration, infrastructure-as-code, migrations, integration adapters and deployment pipeline as agreed in contract.
Assurance evidence: unit, integration, performance, security, continuity, reconciliation and retrieval test results.
Operations pack: monitoring, alerts, runbooks, incident paths, backup, recovery, data retention and vendor-outage procedures.
Handover pack: source access, environments, secrets-transfer procedure, data export, open risks, support boundary and exit steps.
Definition of done: the control works on the normal path, exposes its failure path, writes evidence, preserves corrections, can be retrieved, has an owner and will be reviewed when its source or system changes.
"Approved" or "closed" is not enough. Retain the subject, input data, provider response, policy or model version, automated result, human analysis, override, approval, timestamp and related communications. The required fields differ by control, but the evidence must explain how the outcome was reached.
A correction should create a new event linked to the original. Record who changed what, when, why and which downstream reports or decisions were affected. A database row that only holds the latest value cannot answer a historical question reliably.
Set a realistic sample, maximum retrieval time, export format, reconciliation procedure and acceptable exceptions. Ask a reviewer who did not build the control to reconstruct the case. If success depends on a particular engineer remembering which table to query, retrieval is not ready.
Counts, rates and risk categories should reconcile to the underlying cases and events. Store the report definition and version. When a definition changes, preserve the prior result or document the restatement. This prevents a dashboard change from silently altering the historical compliance story.
Use role-based access, least privilege and explicit approval boundaries for high-risk actions. Separate configuration, operational decision and review where the control requires independent challenge. Administrator access should not become an invisible override path.
Classify personal, financial, transaction and wallet data. Encrypt it in transit and at rest, minimize Travel Rule payloads to the lawful purpose and define retention and deletion. Keep custody keys, application secrets and provider credentials inside documented trust boundaries with rotation and incident procedures.
Test provider timeout, partial response, duplicate event, out-of-order event, chain reorganization, stale market data, delayed settlement, unavailable case service, reporting failure and recovery from backup. A resilience plan becomes evidence only after the system is exercised and deviations are closed.
The canonical Pharos site documents delivery aligned with ISO/IEC 27001, SOC 2 and DORA-related requirements. Procurement teams should request the current certificate, report, scope and applicability rather than relying on a logo. Framework alignment does not by itself prove that a specific MiCA control is complete.
"MiCA license cost" mixes several budgets that should stay separate: NCA fees, required own funds, qualified legal work, compliance staffing, data and screening vendors, security assurance, infrastructure and custom software. Pharos prices software engineering only. Counsel and the relevant authority should confirm the authorization and capital budgets.
The canonical Pharos MiCA page reports an indicative range of about $60,000 for a focused module set to $500,000 and above for a full CASP or issuer control suite with custody integration and surveillance. This is a 2026 planning range, not a quote. The final estimate follows discovery and depends on the accepted scope.
The canonical page reports about 12 weeks for a focused MiCA compliance MVP covering onboarding, screening, transaction monitoring and reporting for in-scope services. Travel Rule or proof-of-reserves work can add roughly two to four weeks per module depending on providers and custody architecture. Data migration, multi-entity rollouts, market surveillance and enterprise assurance can extend the program.
Number and combination of in-scope CASP services.
ART, EMT or other issuer operations confirmed by counsel.
Existing platform quality, undocumented manual work and data migration.
Custody, ledger, exchange, market-data and Travel Rule integrations.
Transaction volume, latency, availability, retention and data-residency requirements.
Number of NCAs, entities, countries, languages and reporting variants.
Required security testing, external assurance and evidence depth.
Handover, support and change-management scope.
Unless a proposal states otherwise, software estimates do not include authorization fees, own funds, insurance, external legal advice, regulator charges, third-party subscription or transaction fees, independent audit fees, cloud consumption or internal compliance staff. Keeping exclusions visible prevents a software quote from being mistaken for the full cost of MiCA authorization.
The cases below are evidence of software delivery. They are not claims that Pharos grants authorization or that one client result will repeat in another environment. Review the full case, baseline and limitations before using a metric in procurement.
Ludera.io is a compliance orchestration layer for MiCA-era exchanges. It connects existing compliance, risk, security and market-intelligence tools, normalizes signals, creates cases and incidents, assigns ownership, runs escalation and preserves the audit trail behind decisions. Its value is operational: moving from disconnected alerts to one traceable process across detection, review, decision and reporting.
The Nextcheck case study reports 5,000+ document verifications per day and 99.8% OCR accuracy, with automated identity, biometric and risk workflows. It is relevant to the onboarding and evidence layer, not proof of a complete MiCA authorization stack.
The Kimlic case study documents a privacy-conscious digital identity and KYC platform for Web3 and FinTech. The published case index reports onboarding completion rising from 62% to 89% and monthly verification volume scaling from 20,000 to 140,000 flows. Applicability to a new project depends on its identity model, jurisdictions and current legal requirements.
As of the source check, the Pharos case index listed 18 published case studies across nine industry categories. The company reports 90+ engineers, 200+ clients across 28 industries and a 5/5 Clutch rating from 101 verified reviews in 2026. Some engagements remain under NDA. Request current references, certificates and case access during due diligence.
Ask for the service and token scope. A supplier should distinguish the ten CASP services, issuer work and the MiCA, TFR, AML, DORA and MiFID boundaries.
Inspect a control record. It should connect source, risk, behavior, evidence, owner, test and change trigger.
Review failure paths. Ask what happens when KYC, blockchain analytics, Travel Rule, custody or market-data providers fail.
Demand a retrieval demonstration. Choose a historical case and make the team reconstruct the decision without developer memory.
Check integration depth. A logo wall does not prove reconciliation, data minimization, fallback or evidence capture.
Validate security evidence. Request current certificate scope, assurance reports, threat model, test results and remediation status.
Define ownership and exit. Contract for source access, data export, documentation, infrastructure, secrets transfer, open risks and transition support.
Separate legal and engineering responsibility. The supplier should refuse to invent a token classification or guarantee regulator acceptance.
Disqualifiers: "fully compliant" without a named scope, authorization guarantees, hidden evidence inside a vendor dashboard, no correction lineage, no unavailable-state design, no retrieval test, unverified certification logos or a proposal that treats all CASP services as one identical control set.
MiCA compliance software is the set of systems that implement counsel-approved requirements for a CASP or crypto-asset issuer and produce evidence that the controls operated. Depending on scope, it can include complaints, records, custody reconciliation, market-abuse surveillance, onboarding, Travel Rule exchange, reporting, resilience and issuer workflows.
No. Pharos Production is a software engineering company. Qualified counsel determines token classification, service scope, authorization strategy and legal sufficiency. The national competent authority decides whether to authorize an applicant. Pharos builds, integrates and tests the systems that implement the approved position.
"MiCA KYC" is a useful search phrase but an imprecise legal label. CASP onboarding, customer due diligence, sanctions and AML monitoring sit across the EU AML framework and related rules, while the crypto Travel Rule comes from Regulation (EU) 2023/1113. MiCA adds conduct, governance and service-specific duties. The architecture can join the workflows without misattributing their sources.
An engineering readiness assessment compares counsel-approved obligations with current processes, systems, data, vendors, owners, evidence and tests. The output should identify build, integration, configuration and operating gaps. It should not claim to replace a legal gap analysis or predict the NCA decision.
Shared components can support several services, including identity, workflow, event capture, evidence, reporting and access control. The service-specific behaviors still differ. Custody reconciliation, trading surveillance, advice suitability and transfer messaging should not be forced into one generic workflow.
A passportable authorization can support cross-border services within the EU, but local operations, languages, NCA expectations and reporting configurations may still vary. Build entity, country, rule and report configuration explicitly. Do not hard-code one jurisdiction's interpretation as the universal model.
Buy or integrate when the process is standard and a specialist provider covers the control, evidence, residency and exit requirements. Build when proprietary custody, high volume, multi-service workflows, deep integrations or authority-specific evidence make a packaged control set inadequate. A hybrid architecture is common.
Pharos reports about 12 weeks for a focused MVP, with two to four additional weeks for some Travel Rule or proof-of-reserves modules. That range assumes defined scope and usable source systems. Migration, surveillance, complex custody, several entities or unresolved legal questions can extend delivery.
The current Pharos planning range is about $60,000 for focused modules to $500,000 and above for a full control suite with custody integration and surveillance. That is software only. NCA fees, own funds, counsel, vendor subscriptions, assurance and internal staffing are separate.
No responsible engineering supplier can guarantee a regulator's decision. Pharos can contract for defined software behavior, artifacts, tests and remediation. Legal sufficiency, authorization and ongoing supervisory acceptance remain with the client, counsel and competent authorities.
Ownership must be explicit in the executed agreement. The proposal should state source access, IP treatment, data ownership, environment access, evidence export, documentation, third-party licenses, transition assistance and post-termination retention. Do not infer these terms from a marketing page.
The architecture can connect identity, sanctions, on-chain analytics, Travel Rule, custody, market data and reporting providers selected for the client's jurisdiction and risk model. Product names should be treated as integration examples, not proof of partnership or regulatory approval. Provider due diligence remains part of the project.
The legal sources below anchor the engineering examples. Always verify consolidated text, amendments, technical standards, national implementation and counsel advice before relying on a control design.
Regulation (EU) 2023/1114, Markets in Crypto-Assets Regulation
Regulation (EU) 2023/1113, information accompanying transfers of funds and certain crypto-assets
Regulation (EU) 2022/2554, Digital Operational Resilience Act
Delegated Regulation (EU) 2025/299, continuity of CASP services
Delegated Regulation (EU) 2025/885, prevention and detection of market abuse
Editorial owner: Pharos Production. Engineering review: Dmytro Nasyrov, Founder and CTO. Last source check: 13 August 2026. Method: primary-source hierarchy, explicit separation of legal and engineering scope, evidence mapping and visible limitations.
Change triggers: MiCA or level-2 standard updates, ESMA or EBA guidance, NCA interpretation, new CASP service, token-classification change, material incident, failed control test, vendor change, architecture change or new evidence requirement.
This page is an engineering resource and a commercial description of software services. It is not legal advice, a conformity certificate or a promise of authorization.
Send the service types, token types, target jurisdictions, current architecture, key vendors, known evidence gaps and intended launch or authorization window. Pharos will use that input to determine whether the next step is a focused assessment, a module integration, an MVP, a broader control platform or a recommendation not to build.
Request a technical MiCA scope review
Prefer email? hello@pharosproduction.com. The canonical contact page lists the current response policy, offices, legal entities and privacy terms.
Pharos Production MiCA Engineering. Software controls and evidence, not legal advice. Source check: 13 August 2026.