Compliance
Info
This section defines the sequence of licensing and regional launches in a way that accelerates go-to-market while simultaneously reducing regulatory and operational risk.
Licensing Strategy and Sequencing
We accelerate launch through partners where it is safe, and transition to our own licenses where it brings control and scalability.
DARCA approaches licensing as a managed roadmap, not a set of disconnected applications. The logic is simple: first, a fast and controlled market entry; then the purchase of independence through proprietary licenses; then expansion through modules without a sudden jump in regulatory burden. This matters for a product that unifies fiat and crypto into one daily system and requires high transaction transparency at the level of statuses and documents.
We run two parallel tracks. The first is partner-led launch (agent/provider) to enter a priority market quickly and gather evidence of demand. The second is obtaining our own licenses to remove dependency on external providers, control economics, and accelerate product development. For us, the partner model is not a substitute for licensing, but a temporary accelerator that reduces unknowns at the start and provides a manageable regulatory perimeter.
Why we start with the Core. The Core is the most repeatable daily scenario, where habit and trust form fastest. At the same time, the Core creates the compliance skeleton: KYC, KYB, AML, the risk engine, transaction statuses and the operational case file, as well as support as part of the product. Modules increase regulatory complexity and cost, so their launch is deferred until the Core is stable and the next investment round can cover the growth of compliance load.
Note
We are not trying to “rewrite” a partner’s rails. DARCA’s differentiation is built on orchestration, transparent “you send / you receive” flows, statuses, and action-based support that reduces user errors and increases operational control.
Our roadmap consists of four phases, each purchasing the next level of control.
| Phase | What happens | Why we do it |
|---|---|---|
| 1 | EU: launch Core via an agent | Enter the market quickly, gather metrics, refine the risk layer and support, while preparing the package for proprietary licenses |
| 2 | EU: obtain proprietary Core licenses and migrate off the partner, while UAE: launch Core via partners | In the EU we buy independence and economics, in the UAE we open a second region quickly without a heavy initial burden |
| 3 | EU: license and launch modules, while UAE: obtain proprietary Core licenses | In the EU we expand to Core+Modules, in the UAE we repeat the independence path for the Core |
| 4 | UAE: license and launch modules, while US: prepare the full launch package | In the UAE we reach Core+Modules on our own base, and prepare the US as a separate market-entry program |
Phase 1 is the EU entry via an agent. The agent model allows us to launch the Core under the partner’s license and supervision on fiat rails, while preserving DARCA’s product layer: UX, statuses, “you send / you receive”, transfers by contacts, in-app support, and controlled logging. At this stage, we consciously accept that some procedures and limits for fiat operations are defined by the partner, but this reduces regulatory risk at the start and accelerates go-to-market. In parallel, we prepare the proprietary licensing package: compliance policies, AML/KYC procedures, the risk control model, reporting requirements, IT controls and we strengthen the team and supervisory processes.
Tip
Phase 1 exists to prove operational controllability in real usage and to prepare the transition into a proprietary regime without “restarting” the entire system.
Phase 2 is where one funding round closes two objectives at once. In the EU, we obtain proprietary licenses for the Core and execute a controlled migration off the partner perimeter with a period of dual running, reducing dependency and improving unit economics. In parallel, in the UAE we launch the Core via partners, securing position in the second priority market quickly without taking on the maximum regulatory burden at day one.
Phase 3 expands the EU through modules and transitions the UAE Core to proprietary licensing. In the EU, modules are introduced in order of regulatory complexity: first, those that strengthen trust and retention without requiring a standalone licensing perimeter (for example Enhanced Security, Messenger, Piggy Bank, Habit Tracker), followed by modules that expand the perimeter of payments and crypto services (for example Payments, P2P, Staking, Cold Vault). For the crypto layer in the EU, we align terminology with MiCA and treat the required status as CASP (Crypto-Asset Service Provider), rather than legacy local definitions. A separate branch is reserved for RWA, as its legal construction often triggers an investment regime and requires maximum rigor in classification, disclosures and full lifecycle control of the underlying assets.
Warning
RWA always runs as a separate track. Regulators assess the economic substance of rights, not the “token label”, so misclassification is more expensive than any speed gain.
Phase 4 covers UAE modules and US preparation. In the UAE, we license and launch modules on our own base, repeating the model proven in the EU. The US is treated as a separate market-entry program, and full package preparation begins only after compliance maturity, the risk engine, and the operating model are proven across the EU and UAE.
This sequencing matters because it turns licensing into a risk-reduction instrument. Partner-led launch provides speed and controllability at the start, proprietary licenses provide independence and scalability, and modules are added without a high-risk regulatory jump, preserving trust with users and regulatory resilience in every region.
Phase 1 - EU Core via Partner (Agent Model)
Info
In Phase 1, DARCA launches only the Core in the EU, operating inside the partner’s regulatory perimeter. We do not obtain proprietary licenses at this stage, but instead build the evidence base and readiness required for Phase 2 licensing.
The role of Phase 1 in the licensing strategy
Launching under a partner’s license is the fastest and safest market entry, reducing regulatory risk and building the foundation for proprietary licensing.
Phase 1 exists to legally launch the daily Core in the EU and prove that the product is operationally controllable on real flows. We deliberately choose a model where regulated services remain within the partner’s perimeter, while DARCA operates as an agent and product orchestrator. This provides speed of entry without compromising regulatory integrity.
In Phase 1, only the Core goes live in production. Modules are not launched. RWA is not launched and remains deferred to Phase 4.
Note
The “Core-only” constraint is not a reduction of ambition, but a way to keep the regulatory perimeter manageable and avoid expanding compliance requirements prematurely.
Phase 1 timeline and regulatory period structure
Phase 1 lasts 24 months and is divided into three regulatorily meaningful periods: model formalization, control stabilization, and scaling with evidence accumulation.
The total duration of Phase 1 is months 1–24. In the licensing file, we define this as a regulatory structure rather than a product development plan.
| Period | Months | Regulatory focus | What counts as the period outcome |
|---|---|---|---|
| Period 1 | 1–6 | Formalizing the agent model and service perimeter | Regulatorily correct service delivery scheme, approved limits, asset scope, SLA, and escalation paths |
| Period 2 | 7–12 | Limited-scope launch and stabilization of controls | Manageable KYC/AML processes, sanctions screening, disputes handling, support operations, validated transaction statuses |
| Period 3 | 13–24 | Scaling within the partner’s regulatory perimeter | Accumulated evidence pack and readiness to apply for proprietary Core licenses in Phase 2 |
Tip
The purpose of these periods is not “how much we can build,” but which regulatory conditions must be closed to make the transition into Phase 2 safe.
Phase 1 regulatory model
The partner is the license holder and regulatory owner, while DARCA operates as an agent with a first-layer product and operational perimeter.
In Phase 1, the guiding principle is single regulatory owner: all regulated services are delivered within the partner’s licensed perimeter and through its approved subcontractors. DARCA orchestrates UX, transaction statuses, support, and operational handling, but does not step outside the scope of the partner’s licenses.
The allocation of responsibilities is defined upfront and becomes the foundation for SLAs, escalation paths, access controls and compliance procedures:
- Partner: licensing, regulatory supervision, safeguarding of fiat funds, execution of fiat operations, card program, baseline AML and sanctions controls within its perimeter, regulatory reporting.
- DARCA: product front layer, transaction statuses, “operation dossier,” first-line support, document collection, escalations to the partner, risk orchestration within the partner’s rule framework.
Warning
If a service is not covered by the partner’s license or its approved perimeter, it must not go live in Phase 1, even if it is technically feasible.
Licenses and regulatory statuses covering Phase 1
In Phase 1 we rely on the partner’s licenses: PSD2 for fiat, a licensed card program perimeter, and MiCA CASP for crypto services.
In Phase 1, DARCA does not obtain its own licenses. Partner requirements are defined as “which regulatory perimeter must be in place” in order to fully cover the Core.
| Core perimeter | What the partner must hold | What this enables in the product |
|---|---|---|
| Fiat (accounts, transfers) | PSD2 PI or EMI | SEPA and local rails, safeguarding, SCA, statements, baseline reporting |
| Cards (issuance and servicing) | Licensed issuer + program manager + processing | Card issuance, authorizations, clearing, dispute and chargeback processes |
| Crypto (custody and exchange) | MiCA CASP within the partner’s perimeter | Custody, crypto-fiat and crypto-crypto exchange, receiving/transmitting crypto within regulated services |
| AML and sanctions | Horizontal partner-wide requirements and policies | Sanctions screening, monitoring, data requirements, record retention, escalation procedures |
Terminology is fixed explicitly: in the EU licensing context we use CASP under MiCA. The term “VASP” is acceptable only in an AML vocabulary context, but not as a “license” label.
Example
In Phase 1, DARCA may select infrastructure providers (custody, liquidity) based on quality and reliability, but legally they must sit inside the partner’s CASP perimeter as approved subcontractors.
Functional scope of Phase 1
Phase 1 ships the full Core into production: fiat, cards, crypto, and fast exchange. Modules and RWA are excluded.
Phase 1 delivers the Core as a daily banking perimeter. This matters because Core is what creates repeat usage and generates the first baseline evidence of demand and operational controllability.
Core functions available to users in the EU via the partner:
- Fiat perimeter: account, top-ups and withdrawals, SEPA and available local transfers, statements and documents, transparent operation statuses.
- Card perimeter: card issuance within the partner’s program, card management (limits, freeze/unfreeze, notifications), dispute and chargeback support under the partner’s procedures.
- Crypto perimeter: custody within the CASP perimeter, deposits and withdrawals, history, statuses, address/network validations, warnings.
- Exchange perimeter: fast crypto-fiat, fiat-crypto, and crypto-crypto exchange with “you send / you receive” preview before confirmation and transparent fees.
At the same time:
- Modules are not launched in Phase 1.
- RWA is not launched in Phase 1 and remains a Phase 4 item.
Question
Why is support included in the Phase 1 Core? Because support is part of the control framework: document collection, review assistance, dispute handling, and escalation directly impact compliance and risk management.
Custody in Phase 1 and our position on “our custodian”
DARCA does not act as an independent custody provider in the EU in Phase 1. Custody and exchange remain fully inside the partner’s CASP perimeter.
In Phase 1, DARCA does not open its own regulatory perimeter as a custody provider. This is critical for keeping the agent model clean and reducing licensing risk.
A formulation that is both honest and operationally practical:
- Custody and exchange are provided within the partner’s CASP perimeter.
- “Our custodian” may exist as a selected infrastructure provider, but legally only as a subcontractor of the partner, approved by the partner’s compliance and included in their outsourcing register.
- DARCA owns the product layer: UX, statuses, support, risk orchestration and operational quality, but does not take on the role of a licensed custody provider in the EU in Phase 1.
Danger
Introducing custody or exchange outside the partner’s CASP perimeter is not acceptable. It creates the risk of an uncovered regulated service and can jeopardize the entire licensing roadmap.
Preparation for Phase 2
In Phase 1 we build the compliance perimeter, governance structure, and evidence pack required to obtain DARCA’s own Core licenses in the EU in Phase 2.
Preparation for Phase 2 in the licensing file is described as “what must be ready for filing and supervision”, not as a product development plan.
What we deliver by the end of Phase 1:
- Compliance package for future EU Core licenses
- AML program: policies, risk assessment, monitoring, escalation procedures, record retention.
- Sanctions: processes, exception controls, evidence of adherence.
- Record keeping and audit trail: completeness of logs and reproducibility of decisions.
- Complaint handling: procedures, timelines, statistics, root causes, corrective actions.
- Governance and roles
- MLRO, compliance, DPO functions, three-lines-of-defense model, training, execution controls.
- Fit and proper preparation and documented accountability.
- Evidence pack from operating under the partner model
- Statistics on payments, cards, exchange, declines and disputed transactions.
- Compliance review metrics: volume, drivers, timelines, outcomes, share of manual review.
- Fraud and loss metrics, effectiveness of limits and holds.
- Support and escalation metrics, SLA adherence, and resolution quality.
- Readiness to migrate into our own regulatory regime
- Dual running as the baseline migration approach.
- Contractual and operational prerequisites to replace the regulatory owner without a “product restart”.
Tip
The purpose of preparation is to enter Phase 2 not with an idea, but with proof: procedures, logs, metrics and demonstrated operational control.
Readiness Gates for Transition to Phase 2
Transition to Phase 2 is permitted only when a defined set of conditions is met: Core reliability, controlled compliance and risk, stable operations, and sufficient market signal.
We use “gates” as safety conditions, not as marketing promises. Thresholds reflect readiness for independent regulatory supervision and license scaling.
| Readiness Group | Gate | Target Benchmark |
|---|---|---|
| Core Reliability | Core uptime | 99.7%+ |
| Core Reliability | Critical incidents | Within a stable corridor, with no systemic recurrence |
| Compliance | Compliance review SLA | Median resolution time remains controlled and does not degrade with growth |
| Compliance | Manual review share | Stable corridor with a downward trend as rules mature |
| Risk | Fraud and losses | Kept within acceptable bounds, with limits and holds functioning effectively |
| Operations | CSAT | 3.9+ / 5 |
| Operations | First response time | 2–3 minutes or better |
| Operations | First-contact resolution | Target benchmark 70%+ |
| Market Signal | DAU | 25,000+ |
| Market Signal | MAU | 70,000+ |
| Market Signal | Retention | D7 48%+, D30 32%+ |
| Market Signal | Monthly volume | 1M+ per month |
| Monetization | Willingness to pay | Subscription is functional and upgrade triggers are validated |
Note
The numbers are used as benchmarks of readiness.
The core purpose of gates is to prove that Core can scale without losing compliance control or operational stability.
Phase 1 Outcome
By the end of Phase 1, Core is operating in the EU within the partner perimeter, and DARCA is ready to transition to its own Core licenses in Phase 2.
Phase 1 is completed when Core is running stably in the EU under the partner’s licenses, and DARCA has demonstrated operational control over compliance, risk, and support on real transaction flows. At this point, we have a full evidence pack, established roles and procedures, and can safely move into Phase 2.
Phase 2 begins with obtaining DARCA’s own Core licenses in the EU, while simultaneously launching Core in the UAE through partners.
Phase 2 — EU Core under Own Licenses + UAE Core via Partners
Info
Phase 2 transitions DARCA from “operating under the partner’s licenses” into a self-owned regulatory perimeter for Core in the EU, without requiring a “second launch” of the product.
At the same time, the UAE is opening up through partners to ensure faster and safer scaling.
Role of Phase 2 in the Licensing Strategy
Phase 2 is required for DARCA to become the regulatory owner of Core in the EU, reduce dependency on the partner, and prepare for perimeter expansion in the next phase.
In Phase 1, we proved that Core can operate reliably on real transaction flows within the partner’s regulatory perimeter. Phase 2 converts this proof into a licensed platform under DARCA’s own supervision in the EU.
This is a critical step because it changes not the user-facing interface, but the distribution of responsibility and DARCA’s control over unit economics, risk and the pace of product evolution.
The parallel track of Phase 2 is the launch of Core in the UAE through partners. This allows DARCA to validate demand and operational execution in a second priority market without expanding its own regulatory perimeter too early.
Note
Phase 2 is not a second product launch. It is a regulatory owner transition in the EU, while preserving UX continuity, transaction history, documentation, and support processes.
Timeline of Phase 2 and Regulatory Structure
Phase 2 lasts 13 months and is split into regulatory stages: filing, supervisory process, migration, and stabilization.
The total duration of Phase 2 is months 25–36. In the licensing file, we define these stages as regulatory activities and control checkpoints, not as a development roadmap.
| Stage | Months | Regulatory Focus | Completion Criteria |
|---|---|---|---|
| Stage A | 25–28 | Preparation and filing for EU Core licenses | Applications submitted, governance approved, policies finalized, outsourcing mapped |
| Stage B | 29–34 | Supervisory process and closing requirements | Regulator requests closed, readiness confirmed, key controls agreed |
| Stage C | 35–37 | Migration to own regime and stabilization | Dual running completed, switch finalized, stability confirmed by metrics |
In parallel, Core is launched in the UAE through partners during Phase 2. In the text, this is described as “within Phase 2” without binding it to a specific month, since timing depends on partner perimeter readiness.
Tip
The stage structure demonstrates operational control for investors: first documents and controls, then licensing, then migration with measurable stability.
EU — Licenses Obtained for Core
For Core in the EU, three perimeters must be covered: fiat under PSD2, crypto under MiCA, and the card program via a licensed issuer.
In Phase 2, DARCA becomes the regulatory owner of the Core perimeter in the EU. This requires securing two primary licenses and structuring the card infrastructure correctly as outsourcing, not as a “third-party product.”
| Core Perimeter | Target Regime | What It Covers in Core | Model Commentary |
|---|---|---|---|
| Fiat | PSD2 EMI (or PI depending on the model) | Accounts, SEPA and local rails, safeguarding, SCA, statements and documentation | EMI typically aligns better with the daily-bank logic and simplifies product consistency |
| Crypto | MiCA CASP | Custody, crypto-fiat and crypto-crypto exchange, supporting crypto Core services | Terminology must remain CASP only; the licensed perimeter becomes fully internal |
| Cards | Licensed issuer + card program (BIN sponsor) + processing | Card issuance, authorizations, clearing, disputes/chargebacks | This is infrastructure governed under outsourcing, not a standalone “card license” |
EU passporting is treated as a strategic advantage: once licensed in the home state, expansion across other EU countries proceeds via notification rather than full relicensing in each jurisdiction.
Warning
The text must avoid wording like “card license.” The correct framing is a card program via a licensed issuer under outsourcing governance.
EU — Supervisory Readiness Package
The regulator evaluates not only the product, but the ability to manage risk: governance, AML, safeguarding, IT/security, and outsourcing.
Phase 2 assumes that DARCA can operate under direct supervision, not only as an “integration layer” inside a partner perimeter. Therefore, the licensing section must clearly state which maturity elements are mandatory.
- Governance and accountability
- Appointed roles: MLRO, compliance officer, DPO.
- Lines of defense model, internal controls and recurring reviews.
- Fit and proper package for key senior management.
- AML and sanctions
- Risk assessment, monitoring, escalation paths and reproducibility of decisions.
- Sanctions screening with fixed rules for match handling.
- Full audit trail for every critical decision (approve, hold, reject).
- Safeguarding and accounting
- Client funds safeguarding procedures, reconciliation and regulatory reporting.
- Control of statement accuracy and documents as a legally binding layer.
- IT/security and operational resilience
- Incident management and notification processes, access and action controls.
- Change management and full event logging.
- Outsourcing governance
- Vendor register: card issuer and processing, KYC providers, custody and liquidity, network monitoring.
- SLA governance, quality controls, audit rights and replacement procedures without stopping the product.
Example
Phase 1 generates evidence on real flows. Phase 2 converts it into supervisory readiness: documents, roles, procedures, outsourcing control and and evidence-based decisions.
Functional Scope of Core in Phase 2
The user experiences the same Core, but the regulatory perimeter is now owned by DARCA. Control over limits, pricing, and change velocity becomes stronger.
The key idea: Core does not change its meaning, it becomes independent from a regulatory standpoint.
Core in the EU in Phase 2 includes:
- Fiat: accounts, top-ups and withdrawals, SEPA and local transfers, statements and documents, transparent transaction statuses.
- Cards: card issuance and management, limits, notifications, disputes/chargebacks as a controlled process with clear statuses.
- Crypto: custody, deposits and withdrawals, history, statuses, address and network validation.
- Exchange: fast crypto-fiat, fiat-crypto, and crypto-crypto exchange with “you send / you receive” preview before confirmation.
What becomes stronger specifically because of own licenses:
- limits and pricing logic (subscriptions and overage) are managed without partner-mode constraints
- compliance review and risk decisions become faster and more controllable
- outsourcing for the crypto and card stack becomes architecture, not dependency
Question
Why is Core functionally similar to Phase 1? Because user value must remain continuous. In Phase 2, what changes is regulatory ownership and the level of control, not the interface for the sake of change.
EU Migration to Own Licenses
Migration is described as a change of regulatory owner with dual running and continuity control across history, documents, and dispute processes.
In the licensing file, migration is presented not as a “technical move,” but as a controlled regulatory operation, where continuity of legally significant layers is critical.
Core migration principles:
- Dual running: parallel operation of both perimeters during the switching period.
- Preserving KYC continuity: data, decisions, rationale and retention timelines must remain reproducible.
- Document continuity: statements, confirmations, and transaction history must stay available and correct.
- Continuity of card disputes/chargebacks: open disputes are not lost or “reset.”
- Continuity of crypto history: audit trail and transaction proofs remain fully reproducible.
Migration risk controls are defined as mandatory:
- reconciliation and status integrity checks
- reducing the share of stuck transactions during the transition window
- clear user communication to prevent panic and behavioral errors
Danger
The most dangerous migration scenario is the loss of evidence integrity: history, documents, and the rationale behind compliance decisions. This is why Phase 2 migration is treated as part of licensing, not as an afterthought.
UAE - Core via Partners in Phase 2
In the UAE during Phase 2, DARCA does not establish its own regulatory perimeter. We launch Core through licensed partners with strict SLA requirements and control compatibility.
The Core launch in the UAE in Phase 2 follows the same baseline logic as Phase 1 in the EU: the partner is the regulatory owner, while DARCA acts as the product orchestrator and first-line support layer.
Partner perimeter requirements to ensure Core is fully functional:
- Payments and cards: a licensed PSP/bank plus a card program, with SLA compatibility on transaction statuses and dispute processes.
- Crypto: a licensed custody and exchange provider under the chosen UAE regime, integrated into our status control and risk workflows.
- AML and sanctions: partner processes must remain compatible with our in-app support model and document collection flows.
DARCA’s role in the UAE:
- unified UX and transaction statuses
- first-line support, document intake, SLA-based escalations
- compliance with partner AML requirements, limits and segmentation rules
Tip
The UAE track in Phase 2 exists to accelerate scaling without expanding DARCA’s own regulatory perimeter, while building local evidence for the next phase.
Preparation for Phase 3
Phase 2 ends not only with migration, but with readiness to expand the perimeter: in the EU through a regulatory module roadmap, and in the UAE through a pre-pack for future Core licensing.
Preparation for Phase 3 within Phase 2 is captured in two parallel directions.
EU:
- building a regulatory expansion map: each next functional perimeter is allowed only once the regulatory scope is clearly covered and controls are defined
- documenting the “no grey zones” principle: if the regime is unclear, it does not go to production
UAE:
- accumulating a local evidence pack under the partner-led regime
- preparing the package for future own Core licenses (policies, governance, outsourcing, AML)
Note
Phase 3 must start not from “ideas”, but from ready foundations: a regulatory roadmap, controls, evidence, and stable post-migration metrics.
Readiness Metrics for Transition to Phase 3
Phase 2 gates confirm that Core remains stable after migration, compliance is manageable under supervision, support operates as part of control, and the second market track does not degrade quality.
All values below are documented as target readiness benchmarks, not as “guarantees.” The key requirement is unambiguous definitions so that metrics cannot be interpreted inconsistently.
Definitions:
- Stuck operation: an operation in pending/processing status with no ETA and no status change beyond the defined control window.
- Support P1/P2 cases: cases affecting funds or risk (payments, card, exchange, blocks, suspected fraud, compliance review).
| Group | Metric | Target Benchmark |
|---|---|---|
| EU Core Reliability | Core uptime after cutover | 99.8%+ |
| EU Core Reliability | Stuck operations | ≤ 0.10% of all operations |
| EU Core Reliability | System-caused failures | ≤ 0.20% of transactions |
| EU Compliance | Median compliance decision time (P1/P2) | ≤ 30 minutes to decision (approve/request docs/hold) |
| EU Compliance | Manual review rate | ≤ 3–5% with a downward trend |
| EU Risk | Fraud loss rate | ≤ 0.05–0.10% of turnover, no post-migration increase |
| EU Cards | Chargeback/dispute rate | Within program corridor, no spike after migration |
| EU Support | First human response 24/7 in-app (P1/P2) | Median ≤ 2–3 minutes |
| EU Support | FCR | ≥ 70% |
| EU Support | CSAT | ≥ 4.2/5 with no degradation |
| Outsourcing | Vendor SLA (issuer, custody, liquidity) | ≥ 95% compliance |
| EU Market Signal | MAU and turnover | Growth vs Phase 1, benchmark +30%+ |
| UAE Track | Core quality under partner regime | No critical compliance incidents, partner SLA does not degrade Core metrics |
Warning
The core purpose of these gates is to prove that moving to own licenses did not reduce quality, but instead improved controllability. Without meeting these gates, perimeter expansion in Phase 3 introduces unnecessary regulatory risk.
Phase 2 Outcome
Phase 2 is complete when EU Core operates under own licenses, migration stability is confirmed by metrics, and UAE Core remains stable in partner mode.
Phase 2 is considered completed when, in the EU, Core operates under DARCA’s own licenses (PSD2 regime for fiat and MiCA CASP status for crypto), while the card program is structured through a licensed issuer as part of a governed outsourcing framework. Migration is finalized without loss of history, documents or dispute processes, and post-cutover metrics confirm operational resilience.
In parallel, the UAE track validates Core functionality through partners and builds a local evidence base. Once the gates are met, Phase 3 can begin without expanding regulatory risk and without degrading Core quality.
Phase 3 - EU Core+Modules under own licenses + UAE Core moving toward own licenses
Info
Phase 3 expands DARCA’s regulatory perimeter in the EU from Core to Core+Modules under the “no grey zones” principle: a module enters production only after its regime, controls, outsourcing, and evidentiary requirements are fully closed. In parallel, UAE Core licensing begins, while the partner model remains in place until transition.
Phase 3 Role
Phase 3 turns DARCA into a supervised platform: perimeter expansion happens in waves and does not degrade Core, compliance, or support baseline metrics.
Phase 3 begins only after EU Core operates stably under DARCA’s own licenses and the Phase 2 transition period is closed with measurable metrics. This matters because expanding into modules does not simply “add licenses” but increases the number of scenarios, disputes, and risk typologies. Expanding without a mature Core creates regulatory and operational debt, which typically shows up as higher manual compliance workload, degraded support performance, and loss of decision traceability.
The parallel track of Phase 3 is the UAE. We start the process of obtaining our own Core licenses, while maintaining partner operations until the transition can be executed as a regulatory owner switch, not as a second product launch.
Note
The logic of Phase 3 is not speed at any cost, but controllability: each new perimeter adds value only if it does not break the base.
Phase 3 Timeline and Structure
Phase 3 lasts 12–18 months: first the regulatory design of modules and the regime map, then Wave 1, then Wave 2. The UAE track runs in parallel throughout the entire period.
We fix the range of 12–18 months because part of the work depends on supervisory procedures and approvals. The staged structure is necessary so that expansion is framed as a controlled regulatory operation, not as ad-hoc feature shipping.
| Stage | Period | Core idea | Stage outcome |
|---|---|---|---|
| A | first 3–4 months | Module license map, Core baseline metrics, control readiness | Map “module → regime → controls → outsourcing”, KPIs locked, UAE package prepared |
| B | next 6–8 months | Wave 1 modules, proof of controllability | Wave 1 in production, scenario growth without degradation of Core or support |
| C | next 3–6 months | Wave 2 modules, more complex cases | Wave 2 in production, disputes remain manageable, traceability preserved |
EU — Module Admission Principle
Each module is treated as an expansion of the licensed perimeter, not as a standalone feature. Launch is only possible once the regime, controls, record keeping, and outsourcing are fully closed.
In the EU, Phase 3 builds on the already established frameworks of PSD2 and MiCA CASP. The focus is therefore not on “a new license for every button,” but on the fact that each module introduces new transaction types and new user expectations, which in turn require additional rules, documentation and dispute-handling processes. This is exactly what the unified admission gate is designed to cover.
To avoid overloading the document with long module-by-module lists, we fix the admission rule as a short matrix that applies to every module.
| Admission block | What must be closed before launch |
|---|---|
| Legal regime | Applicable regime, country restrictions, risk and condition disclosures |
| Controls | Limits, holds, step-up verification, approvals, blocking and exception rules |
| AML and sanctions | Typologies, EDD triggers, reproducible decision rationales |
| Record keeping | Documents, retention periods, audit trail, dispute traceability |
| Outsourcing | Contractors, SLAs, audit rights, replacement procedure without downtime |
Warning
If even one admission block is not closed, the module does not go to production. This is the practical implementation of the no grey zones principle.
EU — Perimeter Expansion in Waves
Wave 1 strengthens daily usage and documentation with minimal regulatory risk. Wave 2 introduces more disputable scenarios and is launched only once controls and support maturity are proven.
Wave 1 is designed to deliver maximum product impact with the lowest legal complexity increase. The point is not the “feature list,” but the logic: we add scenarios that improve money management and operational status clarity, while simultaneously increasing the quality of evidence and traceability.
| Wave | Modules (perimeter) | Why this wave first | Main risk and how it is closed |
|---|---|---|---|
| Wave 1 | Business, Payments, Messenger, control enhancers (Enhanced Security, Anti-crisis Vault, Piggy Bank, Habit Tracker) | High retention and distribution effect without heavy legal qualification complexity | Risk of access control failures, disputes, and social engineering — closed through strong controls, audit trail and dispute playbooks |
| Wave 2 | P2P, Staking/Earn, Token Factory/NFT/My Games contours where financial scenarios apply | Adds higher-risk and more disputable scenarios only after Wave 1 maturity is proven | Risk of fraud, mis-selling, disputed yield accrual — closed via legal qualification, limits, disclosure, and complaint handling |
Wave 2 is not tied to a “mandatory date.” It is a readiness outcome: if Wave 1 increases manual compliance load or overloads support, Wave 2 does not launch until stabilization. Otherwise expansion turns into systemic instability.
Note
The document must clearly show that module sequencing is driven not by “speed at all costs,” but by dispute manageability, risk controls, and evidentiary traceability.
EU — Strengthening Horizontal Controls
As the perimeter expands, typologies and disputes increase, so Phase 3 strengthens AML, fraud controls, complaint handling, outsourcing governance, and the documentation layer.
Expanding into modules increases not only activity, but also the number of situations where users expect fast, unambiguous outcomes. Therefore, Phase 3 treats control strengthening as part of the licensed perimeter, not as “internal operations.”
We describe this as a unified control contour: new AML typologies, more fraud signals, a single case management layer, a module-based complaint catalogue, and the extension of the “operation dossier” to module-specific financial objects. This ensures that growth in scenarios does not push compliance into a manual mode, does not break support, and keeps disputable cases resolvable through rules and documented evidence.
Tip
Strengthening controls in Phase 3 directly improves unit economics: fewer losses and complaints, lower support load, higher trust, and increased AUM.
UAE — Start of Own Core Licensing
In the UAE, Phase 3 initiates DARCA’s own Core licensing, while keeping the partner model until the transition point. The switch is built as dual running with full continuity across documents and disputes.
The UAE track in Phase 3 is built around one principle: first accumulate evidence under the partner regime, then convert it into a licensing package, and only after that plan the move into an own regulatory perimeter. The key priority is not to interrupt the product or slow growth: until Core licenses are obtained, Core continues operating through partners.
In the licensing file, we describe the UAE package as a compact matrix, because it mirrors the essential supervisory readiness elements.
| Package block | Content |
|---|---|
| Governance | roles and accountability, fit and proper, internal control |
| AML & sanctions | monitoring rules, triggers, escalation flows, decision evidence |
| Outsourcing | cards, processing, custody, liquidity, KYC, SLA and audit rights |
| Resilience | incident management, access control, logs, operational stability |
| Continuity | transition plan as a change of regulatory owner (dual running, reconciliation, documents) |
Phase 3 Completion Gates
The gates confirm that perimeter expansion did not degrade Core performance, risk and compliance remain within corridor, support absorbs growth, and the UAE track is ready for transition.
Definitions:
- Stuck transaction: pending/processing without ETA and without status change beyond the control window.
- P1/P2 cases: incidents impacting funds and risk.
| Group | Metric | Gate |
|---|---|---|
| Core stability (EU) | Core uptime | >= 99.8% |
| Core stability (EU) | Stuck transactions | ⇐ 0.10% |
| Core stability (EU) | System-caused failures | ⇐ 0.20% |
| Risk and compliance (EU) | Manual review rate | Within Phase 2 corridor, no increase after modules |
| Risk and compliance (EU) | Fraud loss rate | Within Phase 2 corridor, no increase |
| Support (EU) | First human response (P1/P2) | Median ⇐ 2-3 minutes |
| Support (EU) | FCR and CSAT | FCR >= 70%, CSAT >= 4.2/5 |
| Modules (EU) | Module passport and disputes | Each module has a passport and playbooks, applied and audited |
| Outsourcing | SLA of key vendors | >= 95% |
| UAE readiness | Core licensing track | Progresses through stages without blocking gaps, requirements package closes |
| UAE readiness | Partner regime stability | No critical compliance incidents |
Warning
Phase 3 is not considered complete if perimeter expansion worsens Core baseline metrics or makes compliance manual by default.
Phase 3 Outcome
The EU operates as a supervised Core+Modules platform without Core degradation, while the UAE has an active track toward its own Core licenses and a ready transition model.
Phase 3 concludes with DARCA scaling in the EU as a true platform: modules are introduced in waves, each module passes regulatory admission, disputed cases are resolved through statuses, rules, and documented processes, and Core baseline metrics remain intact.
In parallel, the UAE has initiated its own Core licensing process and prepared a transition model to a proprietary regime as a change of regulatory owner, without a relaunch and without breaking the user experience.
Phase 4 — US as the Primary Launch + Large-Scale Country Expansion via Partners
Info
Phase 4 makes the United States the main next-step market: we close the regulatory perimeter and launch the product in the US in waves, with no grey zones. In parallel, we rapidly expand into new countries via partners, using a standardized country launch kit so geographic growth does not turn into operational chaos.
Role of Phase 4 in the Licensing Strategy
Phase 4 moves DARCA into global scaling mode: the US becomes the top priority for licensing and launch, while country expansion is enabled through a partner model standardized by controls and SLA.
Phase 4 begins only after the EU platform is operating as a supervised Core+Modules system, and we have proven that perimeter expansion can be executed without degrading Core, compliance, or support metrics. This is critical because the United States is the most demanding market in terms of regulatory structure and the cost of mistakes. DARCA cannot enter the US with a “we’ll add it later” mindset. The core principle of Phase 4 is therefore a wave-based launch, strictly tied to regulatory perimeter closure and measurable operational quality.
At the same time, Phase 4 changes the scale of geographic growth. While the US requires sequential regulatory coverage and controlled rollout, we do not freeze product and revenue expansion. Instead, we extend DARCA’s presence into additional countries through partners. This is not treated as a collection of one-off integrations, but as a repeatable launch process with a unified requirements set: due diligence, SLA, audit rights, AML compatibility, standardized dispute playbooks and a consistent support model.
Note
Phase 4 is not about “fast everywhere.” It is about running the complex US regulatory track while expanding geography through partners in a way that keeps the product unified and compliance fully manageable.
Timeline and Structure of Phase 4
Phase 4 lasts 18–24 months and is split into two synchronized tracks: the US rollout in regulatory waves and global expansion through a standardized country launch process.
Phase 4 is defined as a 18–24 month window because the United States requires sequential regulatory coverage and procedures can progress unevenly, while partner-based expansion depends on negotiations and provider readiness. The key point is not the exact month count, but that the phase is structured as a controlled and repeatable operating model.
| Track | Period | Focus | Completion Criteria |
|---|---|---|---|
| US – Wave 1 | first 4–6 months | basic regperimeter and limited go-live | product launched within the permitted scope, BSA/AML proven in real operations |
| US – Wave 2 | next 6–12 months | broader coverage and functional expansion within the chosen regime | coverage expanded, stability and compliance remain within corridor targets |
| US – Wave 3 | next 6–12 months | addition of complex contours only after legal qualification | no grey zones, contours admitted only through regulatory gating |
| Global Expansion | entire period | launch of new countries through partners via the country launch kit | country growth without degradation of SLA, support, or fraud metrics |
Tip
This structure demonstrates investor-level controllability: the US expands in waves, while countries scale through a repeatable process rather than one-off decisions.
US – Regulatory Approvals and Wave-Based Launch
In the US, we launch only within the scope where legal qualification is fully closed. Coverage and contours expand step by step, without mixing complex regimes into the initial go-live.
Warning
In the US, any “half-feature” quickly becomes a compliance risk. Phase 4 follows one rule: close the regime first, then launch functionality. Not the other way around.
Wave 1 – Baseline Regulatory Perimeter and Limited Go-Live
Wave 1 is designed so DARCA can operate legally in the US at a foundational scope, without creating dependence on manual compliance by default. The central idea is to launch Core and the key daily scenarios first, while locking in the mandatory US requirements for AML, sanctions and reporting.
In the licensing narrative, Wave 1 is described as closing the baseline obligations and building the operational compliance contour:
-
Registration and AML foundation
- FinCEN MSB registration, if money transmission or transfer/exchange falls under US interpretation
- a full BSA/AML program with real SAR/CTR processes, training, independent testing, and reproducible decisions
- OFAC sanctions controls as a mandatory layer of KYC and transaction monitoring
-
Banking rails and card infrastructure
- launch through a sponsor bank or BaaS model, where the bank owns the banking perimeter and DARCA owns product and compliance execution under contract
- card program via a licensed issuer and processing stack as infrastructure outsourcing, with clear dispute and fraud playbooks
-
Crypto contour in the US
- explicitly define what is included in Wave 1: custody, transfer, on/off-ramp, exchange
- choose a model that avoids grey zones across states and qualification boundaries, including reliance on custody or trading providers
For clarity, the licensing file should include a compact “Wave 1 closure matrix” rather than a long checklist.
| US Wave 1 Contour | Regulatory Closure | Mandatory Control Layer |
|---|---|---|
| MSB and AML | FinCEN MSB, BSA/AML processes | SAR/CTR procedures, OFAC, audit trail of decisions |
| Fiat rails | sponsor bank / BaaS regime | safeguarding within model, reconciliation, incident controls |
| Cards | issuer + processor + BIN sponsor | disputes, chargebacks, fraud playbooks, SLA |
| Crypto | selected permitted perimeter | monitoring, sanctions screening, policy engine |
Example
Wave 1 is the point where compliance is not “on paper” but in daily use: cases, decisions, grounds, statuses, and documents.
Wave 2 – Coverage Growth and Functional Expansion Within the Chosen Regime
Wave 2 increases US coverage and scale, but does so through controlled expansion across territories and functions. The main driver here is the state-by-state perimeter and constraints, enforced through geofencing and product-level rules.
In the licensing document, Wave 2 is described as coverage discipline:
- We expand coverage in packages, not one state at a time, so growth happens in waves without breaking operations.
- For states where the regime is not yet closed, we do not “leave access open.” We enforce a restricted perimeter: geofencing, disabled functions, and transparent user explanation.
- We explicitly lock that coverage expansion must not degrade Core metrics, otherwise growth creates systemic failures and disputes.
The key table for this section is the “coverage model,” making geographic control unambiguous.
| State Status | Function Availability | Control Principle |
|---|---|---|
| Full regime | Core in full scope, cards, exchange, permitted modules | state requirements closed, SLA and controls applied |
| Restricted regime | only partial functionality (e.g., no transfers or no certain modules) | geofencing + product rules to avoid regime breach |
| No regime | registration unavailable or product closed | hard block, no “grey users” |
Question
Why not “launch everywhere at once”? Because in the US that means either regime breach or default manual compliance. Both destroy scalability and create regulatory debt.
Wave 3 – Complex Contours and Products With Investment Qualification
Wave 3 is reserved for contours that in the US may fall under investment qualification or separate regulatory regimes. The core principle is fixed: we do not expand into these products until the correct regime is closed or a safe partner-based format is chosen.
This primarily includes yield products, certain forms of trading, and any contours that may be classified as securities or investment contracts. This also includes RWA. In the US, qualification depends on product structure, disclosures, and the rights granted to the user. Therefore, RWA in the US is only permitted after the correct regime is selected and the product model creates no grey zones.
Danger
RWA in the US does not launch “by default.” It launches only after legal qualification and regime selection, either through licensed partners or later when the own regulatory perimeter is ready. This is fundamental to risk reduction and trust preservation.
Large-Scale Country Expansion Through Partners
While the US proceeds in licensing waves, we expand geography through partners. Scaling is built on a standard: due diligence, SLA, AML compatibility, dispute playbooks, and a unified support model.
Note
Partner expansion in Phase 4 must not turn into “each country is a separate product.” Therefore, countries launch through one unified process and one consistent set of requirements.*
Country scaling in Phase 4 has a practical purpose: user base, volume, and revenue growth do not depend on a single market and do not freeze because of long US procedures. But this is only possible if partner expansion is standardized.
We note that DARCA retains the product, UX, operation statuses, documents, and support layer, while partners provide the licensed perimeter and infrastructure: fiat rails, cards, custody, acquiring where required. The key distinction is important: this is not a provider’s full white-label product, but a model where DARCA remains the product owner and partners are the regulatory rails.
The core element is the country launch kit. This is a repeatable package that allows launching countries in waves without breaking quality.
| Country launch kit | What it includes | Why it matters |
|---|---|---|
| Legal map | service qualification, restrictions, geofencing | prevent grey zones and accidental breaches |
| Partner due diligence | licenses, reputation, resilience, auditability | avoid dependency on weak providers |
| SLA and audit rights | SLA, audit rights, replacement plan B | maintain control and operational resilience |
| AML compatibility | partner requirements, typologies, escalations | avoid double standards and default manual compliance |
| Dispute playbooks | disputes, timelines, documents, statuses | disputes are resolved as part of the product |
| Data and privacy | DPA, storage, transfers, localization | meet local rules and reduce risk |
| Support model | DARCA first line, SLA-based escalations | support stays part of the product and control layer |
Country scaling in Phase 4 is described as “waves of countries,” prioritized where partner rails are faster and demand is highest. This keeps geography manageable: each country has a clear status, constraints, and quality KPIs, rather than just “we are present.”
Tip
Partner expansion increases resilience and negotiation power: volume and geography unlock better infrastructure terms, stronger SLA, and improved economics, while the product remains unified.
Unified Control Operating Model Across US and Country Expansion
Phase 4 requires a global operating model: a centralized risk framework with local market addenda, unified statuses, unified support, and unified evidentiary traceability.
Phase 4 increases both complexity and scale at the same time. To prevent this from becoming a source of errors, we lock in one principle: the product can only be global if compliance and risk operate under one unified model.
We run a centralized risk framework that defines the baseline rules for AML, sanctions, fraud, and dispute processes. Each market then adds a local addendum: reporting requirements, restrictions, retention timelines, and local specifics. The result is that we do not build “multiple banks,” we build one platform that can remain correct across different regulatory regimes.
Support is especially critical. In Phase 4, support stays on DARCA’s side as the first line and as part of the quality control layer. Escalations and actions requiring partner involvement run through SLA, while critical actions are always confirmed by the user inside the app. This maintains security and reduces the risk of social engineering and wrong actions.
Phase 4 Completion Gates
Phase 4 gates confirm: the US is launched and expanding without critical incidents, partner-led country expansion scales without quality degradation, and the global operating model keeps risk and support within a controlled corridor.
Definitions:
- P1/P2 cases: incidents impacting funds and risk (payments, cards, exchange, disputed operations, freezes, fraud, compliance review).
- “Critical incident”: an event requiring functional shutdown, regulator notifications or large-scale compensating measures.
| Group | Metric | Gate |
|---|---|---|
| US go-live | Launch within permitted perimeter | No critical compliance incidents, BSA/AML processes operate in real execution |
| US AML | Operational maturity | SAR/CTR and OFAC controls are reproducible, decisions have full audit trail |
| US Core | Reliability | Uptime, stuck operations, and system-caused failures remain in the mature Core corridor |
| US coverage | Coverage expansion | Coverage grows in waves, restrictions enforced via geofencing and product rules |
| Partner expansion | Number of countries | Country growth follows the country launch kit, without “one-off exceptions” |
| Partner expansion | SLA for critical partners | >= 95% compliance |
| Risk | Fraud loss rate | Maintained in a controlled corridor, no increase driven by geography |
| Support | First human response (P1/P2) | Median ⇐ 2–3 minutes |
| Support | FCR and CSAT | FCR >= 70%, CSAT >= 4.2/5 |
| Manageability | No “fire-source country” | Share of disputes and complaints by country remains within acceptable bounds |
Phase 4 Outcome
The US has become the primary next-step market and is launched without grey zones, while DARCA’s presence is scaled across countries through partners under a single standardized launch framework.
Phase 4 completes DARCA’s transition to global scale. In the US, the product is live within a fully closed regulatory perimeter, expansion proceeds in waves across coverage and functionality and complex contours are admitted only after legal qualification and the correct regulatory regime are in place. In parallel, international growth is delivered through partner-led expansion via a standardized country launch kit, where quality, safety and verifiability are not sacrificed for speed.
Controlled scaling without regulatory debt
We scale DARCA as a supervised platform: accelerating launches through partners where it is safe, moving to our own regimes where control and unit economics matter, and expanding the perimeter only through provable readiness.
This document defines a growth model where licensing is not a one-time “checkbox”, but a sequential expansion of the regulatory perimeter. The core principle remains unchanged: no grey zones - a function or market enters production only after the regime, controls, AML and sanctions, record keeping, and the outsourcing perimeter are fully closed. Transitions between phases are tied to gates and measurable indicators of reliability, risk, and service, so that growth does not push compliance into a manual mode and does not degrade Core quality.
Below is a high-level timeline showing the sequence of phases and the parallel nature of tracks: the EU as the baseline maturity perimeter, the UAE as the next expansion layer, the US as a separate entry program, and scaling across countries via partners as a continuous growth line.
gantt
title DARCA Compliance Roadmap (calendar aligned)
dateFormat YYYY-MM-DD
axisFormat %b %Y
section Phase 1 - EU Core via Agent (24 months)
P1 Period 1 (model and scope) :active, p1a, 2026-03-01, 2026-08-31
P1 Period 2 (limited go-live, controls) : p1b, 2026-09-01, 2027-02-28
P1 Period 3 (scale, evidence pack) : p1c, 2027-03-01, 2028-02-29
section Phase 2 - EU Own Core (12 months) + UAE Core via Partners
P2 Stage A (prepare and submit) : p2a, 2028-03-01, 2028-06-30
P2 Stage B (reg process and closure) : p2b, 2028-07-01, 2029-01-31
P2 Stage C (dual running, migration) : p2c, 2029-02-01, 2029-03-31
UAE Core via Partners (parallel) : uae_p, 2028-07-01, 2029-03-31
section Phase 3 - EU Core+Modules on own base (12-18 months) + UAE Own Core
P3 Stage A (module license map) : p3a, 2029-04-01, 2029-07-31
P3 Stage B (modules wave 1) : p3b, 2029-08-01, 2030-02-28
P3 Stage C (modules wave 2) : p3c, 2030-03-01, 2030-06-30
UAE Own Core licensing (parallel) : uae_o, 2029-04-01, 2030-06-30
section Phase 4 - US Go-live in waves (18-24 months) + Global Partner Expansion
US Wave 1 (base perimeter, go-live) : us1, 2030-07-01, 2030-12-31
US Wave 2 (coverage growth) : us2, 2031-01-01, 2031-09-30
US Wave 3 (complex contours) : us3, 2031-10-01, 2032-06-30
Global expansion via Partners (mass) :active, glb, 2030-07-01, 2032-06-30
Note
The timeline reflects the regulatory logic specifically. Launch and expansion happen in waves, and quality is maintained through gates: uptime, stuck cases, systemic errors, share of manual compliance, fraud losses, contractor SLAs, and support quality.
This approach makes scaling a repeatable process rather than a series of exceptions. Regulatory correctness acts as an accelerator here: it reduces the cost of mistakes, preserves trust, makes the infrastructure replaceable, and enables expansion of both product and geography without accumulating hidden constraints.