Block 1: From work start to Core launch (15 months)

Info

This block describes the sequence of activities, checkpoints, and outcomes that over 15 months lead to the launch of a fully operational Core of DARCA in EU-30 through the partner model.

mindmap
  root((Block 1 - Core build and launch))
    Goal
      EU Core launch via partners
      15 months end-to-end
    Principles
      End-to-end flows
      Statuses docs support by default
      Security and risk first
    Setup (M1-M2)
      Providers and sandboxes
      Architecture baseline
      Design system
      QA strategy
    Core rails (M3-M5)
      Ledger and accounts
      Internal transfers
      Fiat rails
      Crypto rails
      Exchange
      Operation dossier
      Documents
      Support with actions
    Daily banking (M6-M8)
      Cards and controls
      Bill payments
      Disputes
      Autopay
      Tax baseline
      Risk expansion
    EU-30 readiness (M9-M11)
      Country packs
      i18n pipeline
      Legal templates
      Statements v2
      Ops dashboards
      Help center
    Stabilization (M12-M13)
      Security tests
      Load and resilience
      Data correctness
      Feature freeze
    Launch (M14-M15)
      Dry runs
      Go-live
      Monitoring
      Hypercare

Goal, boundaries, and Definition of Done

We define what exactly is considered a ready Core, what is included in the 15 months, and why this is critical for a governed launch.

Note

We consider ready not only the code, but also the full perimeter of design, integrations, documents, testing, and operational readiness for a 24-7 launch.

What “Core ready for launch” means (by M15 outcome):

Accounts and Ledger - unified accounts and accounting (fiat + crypto), history, available balance, holds, idempotency
Internal transfers - instant transfers within DARCA via phone, email, ID, QR with recipient verification
External fiat rails - top-ups, withdrawals, external transfers, and payment details for 30 EU countries on day 1
Crypto custody - deposits and withdrawals, network selection, address book, address and memo-tag validation, confirmation statuses
Daily exchange - you send-you receive preview, quotes, execution, exchange documents
Cards - plastic cards via partner, lifecycle, transactions, controls, notifications, disputes, dual funding where supported by the partner
Bill payments - utility and invoice payments (catalog, forms, receipts, autopay) via aggregator
Operation dossier - unified “operation dossier”: statuses, timeline, reasons, next steps for all operation types
Documents and statements - operation receipts, statements, export (PDF, CSV), storage and regeneration
Tax layer v1 - classification, cost basis baseline, period reports, annual report, export of tax-ready data
Support as product - in-app chat, cases, buttons and deep-links, AI + human operator, actions for non-critical requests
Risk and compliance decisioning - allow, step-up, hold, deny, decision logs, sanctions and AML hooks
Notifications - events, templates, settings, notification center
Ops readiness - monitoring, SLO, alerts, runbooks, on-call, dry runs, go-live checklist

What is intentionally out of scope for this block (and does not load the 15 months):

Business module (corporate roles, approvals, invoices, KYB as an extension)
RWA modules, P2P, Token Factory, Messenger as a module, NFT, Mining and other “Modules”

Sequence and logic - why this approach

We define the architectural principles that make scaling to EU-30 and launch within 15 months governable.

Tip

The foundation of the plan is platform-first: first a unified model of operations, statuses, documents, risk, and support, then integrations and country scaling.

Key principles:

EU-30 is configurations, not 30 separate products
Operation dossier is the central object for UX, support, and trust
integrations are normalized into a single state machine and a unified document format
documents and i18n are launched within the first 4-6 weeks, otherwise scaling will fail
the last 2 months are for hardening and launch, with no scope expansion

Parallel workstreams

We split the program into workstreams so that code development, design, documentation, and integrations do not block each other.

Example

Within the 15 months we do not work “sequentially”, but in 6 parallel workstreams that converge at unified checkpoints.

Workstream A - Product, Design, Content:

design system, UX of key scenarios, card design, email and notification design
website and user dashboards, help center, content and copywriting
content matrix, messaging and notification templates

Workstream B - Core Platform:

ledger and accounts, operation orchestration, statuses, dossier
document engine, statements, export
limits, fees, overage, notifications
tax layer v1

Workstream C - EU Fiat Rails (EU-30):

provider coverage matrix, integrations for top-ups, withdrawals, external transfers
normalization of provider statuses and errors
country packs: payment details, formats, fees, timelines, feature availability

Workstream D - Cards integration (plastic via partner):

card lifecycle, activation, controls, notifications
card transactions as Core objects (auth, capture, settlement)
disputes, documents, support scenarios
dual funding where supported by the partner

Workstream E - Crypto + Exchange:

deposits, withdrawals, networks, address book, policies for new addresses
exchange: quoting, you send-you receive preview, execution, documents

Workstream F - Risk, Support, QA, Sec, Ops:

risk decisioning (allow, step-up, hold, deny), policy rules, decision logs
in-app support: cases, buttons, deep-links, AI + human operator
testing (unit, integration, e2e), regressions, multi-country QA
security, pen-test, remediation
monitoring, SLO, runbooks, on-call, dry runs

Stages M1-M15 and outcomes

We split the 15 months into 6 stages to achieve early end-to-end capability, complete EU-30 scaling, and secure a stabilization window.

Warning

The most expensive risk is “integration hell” at the end. Therefore end-to-end capability appears already by M5, and EU-30 coverage and documents are completed before hardening begins.

Stage 0 - Foundation (M1-M2)

What we do:

define Core v1 scope and “ready for launch” criteria
approve the domain model: operation, statuses, dossier, documents, risk, support
select providers and obtain sandbox access:
- fiat rails EU-30 (provider coverage matrix)
- cards partner (plastic, processing, events)
- custody, exchange, KYC-AML, sanctions
- bill payments aggregator
launch document engine skeleton and data dictionary for document vendors
launch i18n pipeline: export all strings, import translations, AI translation + professional review
launch design system and hi-fi prototypes of key flows

Why this comes first:

without providers and data contracts it is impossible to build correct statuses, documents, and support
without i18n and document engine scaling to EU-30 will fail on timelines

Stage outputs:

integration specifications and sandbox access
status state machine v1
design system v1 and prototypes of key screens
document engine v0 and data dictionary
i18n pipeline v0

Stage 1 - Build 1 and early end-to-end (M3-M5)

What we do:

ledger and accounts, history, idempotency
internal transfers via phone, email, ID, QR with recipient confirmation
external fiat rails wave 1-3: top-ups, withdrawals, transfers, payment details
crypto custody v1: deposits, withdrawals, address book, network validations
exchange v1: quoting, you send-you receive preview, execution
operation dossier v1: timeline, statuses, reasons, next steps
documents v1: receipts, statements, export (PDF, CSV)
support foundation: operation cases, buttons and deep-links
risk decisioning v1 for key operations

Why this comes second:

early end-to-end reveals real provider constraints and adjusts the model of statuses, documents, and support before EU-30 scaling

Stage outputs:

4 end-to-end scenarios in staging:
- internal transfer
- external fiat transfer
- crypto withdrawal
- exchange
documents and operation dossier working across all operation types v1

Stage 2 - Daily completeness (M6-M8)

What we do:

cards integration end-to-end:
- card lifecycle, delivery, activation
- card transactions (auth, capture, settlement) as Core objects
- controls: freeze, limits, geo, modes
- notifications for card events
disputes workflow v1 and dispute documents
bill payments v1:
- catalog, forms, receipts
- autopay v1
tax layer v1 start:
- event classification
- cost basis baseline
- period reports and export
external fiat rails: extend coverage to 70-80 percent of countries

Why here:

cards and bill payments create daily usage habit and cannot be postponed to the end
tax layer must be embedded before final hardening, otherwise there will be no time to validate data

Stage outputs:

cards and bill payments working end-to-end in staging
disputes accessible from operation view and support
tax v1 generating baseline reports and export

Stage 3 - EU-30 scaling and beta readiness (M9-M11)

What we do:

complete EU-30 coverage:
- provider matrix, fallback contours, status normalization
- country packs: payment details, formats, fees, timelines, texts
i18n pipeline production-grade:
- dictionary versioning, validations, fallback
- critical strings through dedicated review workflow
connect vendor-provided documents:
- legal and operational templates by country
- binding to document engine and operation data
prepare operations:
- monitoring, SLO, alerts, stuck queues
- support playbooks, escalation with providers
- dry-run scenarios for typical issues

Why before hardening:

EU-30 coverage and documents must be completed before “freeze”, otherwise the last months will be spent on catch-up integrations instead of stabilization

Stage outputs:

EU-30 fully operational in staging
localization of key flows completed
country-specific documents connected to engine
beta readiness: operations and support capable of handling the product

Stage 4 - Security, performance and feature freeze (M12-M13)

What we do:

conduct pen-test and remediation
run load testing, resilience validation and chaos scenarios
optimize retries, deduplication and stuck rate
improve clarity of reason messages and next steps for support
feature freeze at the end of M13

Why we allocate a dedicated window:

without a separate security and performance phase, launch will be accompanied by critical incidents and high manual case volume

Stage outputs:

completed and closed pen-test
passed load and resilience tests
feature freeze

Stage 5 - Hardening and launch (M14-M15)

What we do:

dry runs: go-live checklist, rollback procedures, degradation modes
on-call and incident framework: runbooks, escalation paths, SLA control
cohort-based launch:
- limited activations, monitoring, rapid fixes
- post-launch review and plan for the first weeks

Why launch is a separate phase:

launch is an operational program requiring discipline and incident readiness, not just code readiness

Stage outputs:

Core launched to production
stable quality and support metrics

Control gates and admission criteria

Gates fix the minimally required readiness before moving to the next stage and protect the final months from scope creep.

Question

If any gate is not closed, the project does not “accelerate”, but is reprioritized in order to preserve hardening and launch.

G1 (end of M2):

providers are selected, sandbox and data contracts are in place
status state machine v1 and error mapping
design system v1 and prototypes of key flows
document engine v0 and data dictionary for contractors
i18n pipeline v0

G2 (end of M5):

4 end-to-end scenarios in staging
operation dossier and documents v1 for all operation types
support actions v1 and risk decisioning v1

G3 (end of M8):

cards, disputes and bill payments end-to-end in staging
tax layer v1 has started and is integrated into documents and export
fiat rails coverage has reached 70-80 percent of countries

G4 (end of M11):

EU-30 coverage fully in staging
country packs and localizations of key flows are ready
country-specific documents are connected to the document engine
beta readiness: ops, monitoring, support playbooks

G5 (end of M13):

pen-test is closed, remediation is completed
load and resilience tests are passed
feature freeze

G6 (end of M15):

hardening is completed, go-live checklist is closed
launch is completed, quality control in production is enabled

Result after 15 months

At the output we obtain a Core that is ready for operation and scaling, not a “prototype that still needs to be refined”.

gantt
  title DARCA Core Roadmap - Full scope, 15 months to launch (start 2026-03-01)
  dateFormat  YYYY-MM-DD
  axisFormat  %b %Y

  section Foundation (M1-M2)
  Scope and domain model (Core DoD, statuses, dossier)        :f1, 2026-03-02, 2026-03-29
  Providers selection and sandbox (fiat, cards, crypto, exchange, KYC, bills) :f2, 2026-03-04, 2026-04-18
  Product architecture baseline (platform-first, contracts)    :f0, 2026-03-01, 2026-04-27
  Design system v1 (app, web, states, errors)                  :f3, 2026-03-12, 2026-05-02
  Core UX prototypes (onboarding, transfers, exchange, cards, bills, dossier) :f3a, 2026-03-16, 2026-05-01
  i18n pipeline v0 (export/import, AI translate, pro review)    :f4, 2026-03-17, 2026-04-28
  Document engine v0 and data dictionary                        :f5, 2026-03-19, 2026-05-03
  Risk and policy engine skeleton (allow/step-up/hold/deny)      :f6, 2026-03-23, 2026-05-04
  Notifications platform skeleton (event model, templates)       :f7, 2026-03-25, 2026-04-29
  Ops baseline (logging, metrics, tracing, alerting v0)          :f8, 2026-03-21, 2026-05-02
  Gate G1 (providers + sandbox + data contracts)                 :milestone, g1, 2026-05-04, 0d

  section Build 1 - Core rails and early E2E (M3-M5)
  Ledger and accounts (balances, holds, idempotency)            :b1, 2026-05-06, 2026-06-18
  Limits, fees, overage engine v1 (core tariff logic)           :b1a, 2026-05-19, 2026-08-03
  Internal transfers (phone, email, ID, QR)                      :b2, 2026-05-12, 2026-07-03
  External fiat rails wave 1-3 (top-up, withdraw, transfers)     :b3, 2026-05-17, 2026-08-04
  Crypto rails v1 (deposit, withdraw, address book, validation)  :b4, 2026-05-16, 2026-08-02
  Exchange v1 (preview you send/you receive, execution, docs)    :b5, 2026-06-18, 2026-08-01
  Operation dossier v1 (timeline, reasons, next steps)           :b6, 2026-05-23, 2026-08-02
  Documents v1 (receipts, statements, export)                    :b7, 2026-06-16, 2026-08-03
  Notifications v1 (core events, push/email/in-app basics)       :b7a, 2026-06-03, 2026-08-02
  Risk decisioning v1 (allow/step-up/hold/deny)                  :b8, 2026-06-05, 2026-08-04
  AML and sanctions hooks v1 (screening interfaces, audit logs)  :b8a, 2026-06-21, 2026-08-05
  Support foundation v1 (cases, buttons, deep-links)             :b9, 2026-06-06, 2026-08-01
  QA automation baseline (unit+integration+E2E framework)         :b10, 2026-05-21, 2026-08-04
  Gate G2 (4 core E2E scenarios in staging)                      :milestone, g2, 2026-08-06, 0d

  section Build 2 - Daily completeness (M6-M8)
  Cards integration E2E (lifecycle, tx mapping, notifications)   :c1, 2026-08-07, 2026-10-02
  Cards controls v1 (freeze, limits, geo, modes)                 :c2, 2026-08-19, 2026-10-01
  Disputes workflow v1 (chargebacks, evidence, statuses)         :c3, 2026-09-05, 2026-11-06
  Bill payments integration v1 (catalog, forms, receipts)        :c4, 2026-08-18, 2026-11-03
  Autopay v1 (schedules, rules, notifications)                   :c5, 2026-10-04, 2026-11-04
  Tax layer v1 start (classification, cost basis baseline, export) :c6, 2026-09-18, 2026-11-05
  External fiat rails scaling to 70-80% countries                :c7, 2026-08-06, 2026-11-02
  Risk policies expansion (new payees, velocity, geo, device)    :c8, 2026-08-22, 2026-11-06
  Support actions v2 (guided flows, docs requests, status actions) :c9, 2026-09-08, 2026-11-04
  Onboarding and lifecycle comms v1 (email/push templates, triggers) :c10, 2026-09-21, 2026-11-03
  Gate G3 (cards + bills + disputes E2E in staging)              :milestone, g3, 2026-11-07, 0d

  section Scaling - EU-30, i18n, documents, beta readiness (M9-M11)
  EU-30 coverage complete (provider matrix, gaps closed, normalization) :s1, 2026-11-08, 2027-01-19
  Country packs (formats, fees, availability, content)           :s2, 2026-11-10, 2027-02-03
  i18n production pipeline (versioning, QA, critical strings workflow) :s3, 2026-11-09, 2027-02-02
  Contractor legal templates (per-country) + engine binding      :s4, 2026-11-20, 2027-02-05
  Statements and documents v2 (country formats, reconciliation fields) :s4a, 2026-12-04, 2027-02-04
  Website v1 (marketing, compliance pages, status page)          :s5, 2026-11-18, 2027-02-01
  Personal cabinet v1 (profile, docs, statements, tickets)       :s6, 2026-12-06, 2027-02-06
  Help center v1 (knowledge base, flows, deep-links)             :s7, 2026-12-03, 2027-02-05
  Ops dashboards v1 (provider SLA, stuck rate, latency, success) :s8, 2026-12-07, 2027-02-06
  Support readiness (playbooks, escalation, QA of actions)       :s9, 2026-12-05, 2027-02-07
  Gate G4 (EU-30 staging complete + beta readiness)              :milestone, g4, 2027-02-07, 0d

  section Security, performance, feature freeze (M12-M13)
  Pen-test and remediation                                      :p1, 2027-02-09, 2027-03-22
  Load testing and resilience (retries, stuck rate, chaos)      :p2, 2027-02-18, 2027-04-06
  Data correctness hardening (docs, statements, tax v1)         :p3, 2027-02-21, 2027-04-07
  Risk and AML hardening (false positives, holds, case flow)    :p4, 2027-02-22, 2027-04-08
  Feature freeze                                                :milestone, g5, 2027-04-08, 0d

  section Hardening and Launch (M14-M15)
  Dry runs and go-live checklist (rollback, degraded modes)     :h1, 2027-04-10, 2027-05-06
  Production readiness (runbooks, on-call, incident drills)     :h1a, 2027-04-11, 2027-05-08
  Launch cohorts + monitoring (production ramp-up)              :h2, 2027-05-09, 2027-06-05
  Post-launch stabilization window (hotfix process, KPIs)        :h3, 2027-05-12, 2027-06-07
  Gate G6 (Core launch)                                         :milestone, g6, 2027-06-07, 0d

Tip

The outcome of the program is a working core of a daily bank, where every operation has statuses, documents, and support with actions, and EU-30 scaling is achieved through configuration rather than product rewrites.

At launch, the output is:

the product is ready for EU-30 users (partner mode), including cards, exchange, transfers, and bill payments
24-7 operational readiness: monitoring, SLO, support, runbooks, escalations
documentation perimeter: receipts, statements, tax v1, local templates and formats
the foundation for transition to Phase 2 (own licenses) without rewriting the Core

Block 2: Growth after launch, stabilization, and preparation for Phase 2 (9 months)

Info

The period 2027-06-07 → 2028-03-07 is the 9 months after Core launch, during which we do 3 things simultaneously: stabilize production, prepare the exit from partners, and open the UAE market through partners.

mindmap
  root((Block 2 - Post-launch stabilization))
    Period
      9 months after Core launch
    Goals
      Stable production Core
      EU transition readiness
      UAE live via partners
    Execution
      Three parallel tracks
        Stability
        EU own-license prep
        UAE partner launch
    Stability
      Incidents and bugs
      Core reliability
      Data correctness
      Support with actions
      Security tuning
    EU transition
      Compliance readiness
      Provider abstraction
      Migration and rollback
      Ops maturity
    UAE launch
      Partner setup
      Local compliance
      Controlled pilot
      Support readiness
    Timeline
      Months 1-3
        Incident focus
        Migration prep
        UAE partner selection
      Months 4-6
        Process normalization
        Migration build
        UAE pilot
      Months 7-9
        Phase 2 readiness
        EU exit readiness
        UAE stable ops
    Outcome
      Stable Core
      EU ready for own licenses
      UAE operating via partners

Context and objectives of the period

After launching the Core in partner mode, bugs and operational deviations are inevitable, therefore the next stage is designed as a transition program rather than as “finishing touches”.

Note

We assume in advance that after launch there will be a flow of bugs, incidents, discrepancies and support tickets. If a separate program is not allocated for this, the transition to Phase 2 will be disrupted due to constant “firefighting”.

This block completes the transition from the state where:

the Core is launched through partners and operates in EU-30 in partner mode

To the state where:

the Core is stable in production and scales without loss of quality
the team and processes are ready for the own-licensed mode in the EU
the UAE is launched through partners as a separate market track
migration away from partners is prepared with controlled risk and reversibility

Goals and success criteria after 9 months

We define what exactly must be ready and measurable so that Phase 2 starts as a controlled transition rather than as an adventure.

Tip

In this period, “success” is not growth at any cost, but stability and readiness: quality, controllability, provability, preparation for regulatory responsibility.

Goal C (Stability) - stabilize the product after launch:

stable operations across key flows (transfers, exchange, cards, bills, crypto withdrawals)
reduction in the share of “where is my money” tickets through improved statuses and operation dossier
regular releases without breaking critical scenarios

Goal A (EU Transition) - prepare the exit from partners and own licenses:

a ready compliance package and operational policies for the regulator
a ready operating model and responsibility distribution instead of the partner
Core readiness for own rails: orchestration, settlement, reconciliation, reporting

Goal B (UAE Launch) - open the UAE market through partners:

regional packaging (geo-fencing, local rules, KYC)
connected UAE partner stack and normalized statuses in the Core
operational readiness to support the UAE (support, playbooks, monitoring)

How we execute this block

To make the plan realistic, we run 3 parallel programs and allocate capacity for stabilization.

Warning

During these 9 months it is prohibited to “accelerate” at the expense of quality. Any new integration, migration, or release is allowed only if there is observability, tests, runbooks, and rollback.

Work organization:

Program C - Post-launch stability - runs throughout the entire period without interruption
Program A - EU transition to own licenses - we prepare the transition from partners to own licenses and operations
Program B - UAE launch via partners - parallel launch of the UAE through partners

Capacity allocation (principle, not a rigid number):

stabilization - permanently allocated capacity so that it does not “eat up” migration and licensing
EU transition - the main strategic stream of Phase 2
UAE launch - a separate track that must not break EU stability

Program C: Post-launch stability

Product stabilization after launch is a key condition for growth and transition to own licenses.

Example

Stabilization is not “bug fixing”, but the transition of the product into a mode of controlled operation, where issues are quickly detected, localized, resolved, and do not recur.

C1. Incident and bug management as a production process

What we do:

a unified triage backlog by classes P0-P3
hotfix policy: what can be fixed immediately and what goes into a scheduled release
mandatory RCA for P0-P1 and process correction, not only code fixes
escalation matrix with partners for each domain: fiat, cards, KYC, crypto, bills

What this delivers:

less “chaos” and fewer urgent fixes
release predictability and resilience of key scenarios

C2. Observability and SLO for operations

What we do:

SLO for core operations: internal transfers, external fiat, exchange, card tx, bills, crypto withdrawals
dashboards for stuck rate, fail rate, latency by operations and by providers
end-to-end tracing by operation id and event correlation
dedicated dashboards for support: status, reason, next step

What this delivers:

fast detection of provider degradation or integration errors
reduction of “where is my money” tickets and faster, more accurate support response time

C3. Reconciliation and data correctness as the foundation of trust

What we do:

daily reconciliations against partner registries and the internal ledger
break management: discrepancy queue, root causes, ownership, auto-resolution where possible
strengthening idempotency, deduplication, and correct retries for external calls

What this delivers:

financial records match without manual investigations
readiness for the own-licensed mode where responsibility for discrepancies is not delegated to the partner

C4. Reducing support load through the product

What we do:

improve the Operation dossier: reasons and next steps for each status
support actions in chat: document request, status update, document regeneration, escalation
AI co-pilot for operators: suggested replies, auto-summaries, topic classification
QC loop: identification of frequent issues and adjustment of UX, content, and flows

What this delivers:

fewer tickets and higher FCR
support operates as part of the product, not as a “separate department”

Program A: EU transition to own licenses

Transition to own licenses is the transfer of responsibility and operational functions, not just obtaining a document from the regulator.

Note

The regulator evaluates the ability to manage risk, processes, data and the audit trail. Therefore, in this block we prepare operations and evidentiary readiness in parallel with development.

A1. Licensing and regulatory program

What we do:

define the target set of licenses for Phase 2 (PI-EMI and crypto regime where required)
select the home state and the passporting plan
form the calendar of deliverables and owners
maintain the outsourcing register and vendor risk framework

What this delivers:

a predictable Phase 2 trajectory and a clear understanding of requirements for processes and the system

A2. License-level policies and procedures

What we do:

AML-CTF program: EDD, PEP, SAR-STR, training, quality control
sanctions screening: rules, escalations, decision storage
safeguarding and funds flow maps (for EMI), segregation and balance control
incident reporting and risk management framework
GDPR package: DPIA, retention, DSAR, privacy by design
complaint handling: rules and communication templates

What this delivers:

readiness for audits and regulatory inspections
minimization of licensing rejection risk and reduction of operational incidents

A3. Target Operating Model and replacement of partner functions

What we do:

describe what the partner performs today and what DARCA will perform
form the TOM and RACI by processes
plan internal functions:
- compliance operations (alerts, cases, SAR)
- payments ops (investigations, returns, chargebacks)
- treasury ops (liquidity, settlement)
- reconciliation function (daily reconciliations and control)

What this delivers:

a clear transition plan and minimization of “grey areas of responsibility”

A4. Core readiness for own rails

What we do:

payments orchestration: routing, fallback, SLA policies, cost control
settlement and accounting model: end-of-day, refunds, reversals
reconciliation v2: matching rules, break queues, auto-resolution
regulatory-grade statements v2: mandatory fields, retention periods, immutable logs

What this delivers:

the Core is capable of operating on own rails without rewriting the architecture
control over unit economics and service quality appears

A5. Risk-AML stack v2 and case management

What we do:

refine requirements and select the vendor stack (KYC, screening, TM, blockchain analytics where needed)
build case management: evidence store, SLA, audit trail, roles and permissions
configure rule packs: velocity, new payees, geo, device, patterns
tune false positives and decision quality (without increasing manual workload)

What this delivers:

the ability to scale safely without uncontrolled holds and denies
licensable operational readiness of compliance

A6. Card program path and migration readiness

What we do:

select the target long-term model (sponsor BIN or issuer path)
unify dispute workflows and evidence storage under own case management
form the card migration plan by cohorts, with communications and control windows

What this delivers:

reduced dependence on partners and control over the most frequent “daily” product

A7. Data platform and regulatory reporting

What we do:

DWH-ETL layer for regulatory and management reporting
reports on AML, fraud, incidents, complaints
data retention and evidentiary readiness so that audits are fast and transparent

What this delivers:

readiness for reporting and inspections, reduction of compliance cost at scale

A8. Migration strategy partner → own

What we do:

domain-based migration: new users to own rails first, then existing cohorts
dual-run window and cross-check reconciliation
rollback plan and degraded modes
user communications: changes in details, terms and timelines

What this delivers:

a controlled transition without loss of trust and without a “point of no return” in case of issues

Program B: UAE launch via partners

Launching the UAE through partners allows opening a second jurisdiction faster and simultaneously validating Core portability.

Tip

In this block, the UAE serves as proof that the Core scales geographically through configurations and providers without losing the quality of statuses, documents, and support.

B1. UAE regional packaging

What we do:

geo-fencing: feature availability and product restrictions
local ToS-Privacy-fees and KYC requirements for residents and non-residents
sanctions and screening framework taking into account rail specifics and USD risks
localization, support channels, and communication rules

What this delivers:

launch in the UAE without legal and product “gaps”

B2. Selection and integration of UAE providers

What we do:

selection of UAE partners: fiat rails, cards, on-off ramp, KYC-AML, bills where applicable
integrations and normalization of statuses in the Core state machine
SLA and escalation with partners, transparent responsibility boundaries

What this delivers:

the UAE operates as part of the platform, not as a separate product

B3. UAE ops readiness

What we do:

playbooks for cases: disputes, investigations, KYC escalations
regional monitoring, dedicated dashboards and alerts
training of support and compliance teams for regional scenarios

What this delivers:

UAE operations without team overload and without quality degradation

B4. UAE go-to-market and growth

What we do:

ICP and positioning: individuals, freelancers, SMEs
referral mechanics and anti-fraud rules for referrals
lifecycle communications: onboarding, activation, retention
local partnerships and distribution channels

What this delivers:

the UAE launch becomes a managed funnel rather than a “release for the sake of release”

Internal breakdown of the 9 months by focus

To avoid overload, we shift the dominant focus across periods while keeping stability as a continuous stream.

Example

In the first 6-8 weeks stabilization is more intensive. After that stabilization remains constant, while the main share of effort moves to EU readiness and the UAE launch.

Period 1 (first 6-8 weeks):

Program C dominates: incidents, bugs, data correctness, ticket reduction
A1-A2 and B1 are launched as preparatory work without heavy migrations

Period 2 (next 3-4 months):

Program A grows: policies, TOM, orchestration, case management
Program B is actively progressing: UAE provider selection and integrations
Program C continues to reduce noise and strengthen quality

Period 3 (last 3 months):

closing Phase 2 readiness gates
finalization of the migration playbook, dual-run preparation
UAE go-live or expansion based on stack and ops readiness

Control checkpoints - readiness gates

Gates protect Phase 2 from emotionally driven transitions and make progress provable for the team and investors.

Warning

If a gate is not closed, we do not expand geography and do not accelerate migration - we eliminate the root causes, otherwise risk increases nonlinearly.

Gate S1 (stability baseline):

critical incidents are under control, a stable release process exists
observability covers key operations and providers
reconciliation and break management function without manual chaos

Gate A1 (license-ready pack):

policies and procedures are compiled and ready for regulatory submission
TOM and RACI are approved, process owners are defined

Gate A2 (own rails readiness):

orchestration, settlement, and reconciliation are ready in staging
regulatory statements and audit trail comply with requirements

Gate B1 (UAE stack ready):

UAE providers are selected, integrations are in staging, statuses are normalized
SLA and escalation procedures with partners are defined

Gate B2 (UAE go-live readiness):

support playbooks, monitoring, training, and operational procedures are ready
go-to-market is prepared, onboarding and communications are configured

Gate P2 (Phase 2 readiness):

migration strategy is approved (dual-run, rollback, cohorts)
Core quality allows responsibility transfer without service degradation
there is a partner exit transition plan with control windows and metrics

Outcome of Block 2

By the start of Phase 2 we arrive not with a “plan on paper”, but with a resilient platform ready for licensing, migration, and expansion into new jurisdictions.

gantt
  title DARCA Road-map - Block 2 (9 months): Stability + EU Transition + UAE Launch (with realistic offsets)
  dateFormat  YYYY-MM-DD
  axisFormat  %b %Y

  section Program C - Post-launch stability (always on)
  Hypercare window (P0/P1 triage, hotfix cadence, RCA)                      :c1, 2027-06-09, 2027-07-31
  Incident playbooks Top-20 + partner escalation matrix                     :c1a, 2027-06-14, 2027-08-11
  Observability pack v1 (SLO, alerts, traces, provider dashboards)          :c2, 2027-06-16, 2027-09-24
  Data correctness hardening (docs, statements, tax outputs)                :c2a, 2027-07-01, 2027-10-23
  Reconciliation hardening v1.5 (break mgmt, idempotency, retries)          :c3, 2027-06-23, 2027-10-17
  Support actions v1 (refresh status, resend docs, request info, escalate)  :c4, 2027-07-09, 2027-09-28
  Support load reduction (dossier reasons, next steps, KB loops)            :c4a, 2027-07-18, 2027-11-29
  AI co-pilot for support v1 (suggested replies, summaries)                 :c4b, 2027-08-06, 2027-12-04
  Support QC model v1 (topics, quality checks, product feedback loop)        :c4c, 2027-09-03, 2028-01-21
  Continuous security patching and assurance                                :c5, 2027-06-21, 2028-03-05
  Stability gate S1 (baseline reached)                                      :milestone, s1, 2027-08-04, 0d

  section Program A - EU transition to own licenses
  Licensing scope + home state decision + passporting plan                  :a1, 2027-06-15, 2027-07-26
  Outsourcing register + vendor risk baseline (EU)                           :a1a, 2027-06-28, 2027-08-08
  Compliance policy pack v1 (AML/CTF, sanctions, incidents, complaints)      :a2, 2027-06-27, 2027-09-12
  Safeguarding and funds flow maps (EMI-grade)                               :a2a, 2027-07-14, 2027-09-19
  GDPR pack (DPIA, retention, DSAR, privacy by design)                       :a2b, 2027-07-22, 2027-10-03
  Target Operating Model + RACI (partner -> own)                             :a3, 2027-07-12, 2027-10-02
  Hiring plan for own ops (MLRO, compliance ops, payments ops, treasury)     :a3a, 2027-08-04, 2027-10-07
  Own rails readiness v1 (payments orchestration build + fallback policies)  :a4, 2027-08-08, 2027-11-18
  Settlement and accounting model v1 (returns, reversals, EOD)               :a4a, 2027-08-21, 2027-12-02
  Reconciliation v2 build (matching rules, break queues, auto-resolve)       :a5, 2027-09-07, 2028-01-16
  Regulatory statements v2 (formats, audit fields, retention hooks)          :a5a, 2027-09-19, 2028-01-29
  Risk/AML stack v2 selection + implementation                               :a6, 2027-09-23, 2028-02-09
  Case management v1 (alerts, evidence store, SLA, audit trail)              :a6a, 2027-10-05, 2028-02-17
  False positive tuning loops (risk/AML quality, workload control)           :a6b, 2027-11-06, 2028-02-26
  Data platform v1 (DWH/ETL/BI)                                              :a7, 2027-10-11, 2028-02-22
  Regulatory reporting pack v1 (AML, incidents, complaints, ops)             :a7a, 2027-11-03, 2028-03-02
  Card program migration path (model, disputes, evidence, cohorts plan)      :a8, 2027-10-19, 2028-02-12
  Migration strategy v1 (dual-run, rollback, cohorts, comms)                 :a9, 2027-11-05, 2028-03-03
  Dual-run rehearsal (staging -> shadow -> controlled)                       :a9a, 2028-02-12, 2028-03-03
  Gate A1 (license-ready pack complete)                                      :milestone, ga1, 2027-10-09, 0d
  Gate A2 (own rails staging readiness)                                      :milestone, ga2, 2028-02-02, 0d

  section Program B - UAE launch via partners
  UAE packaging v1 (geo-fencing, ToS/Privacy, KYC rules, sanctions)          :b1, 2027-06-20, 2027-08-12
  UAE localization and support setup (channels, scripts, language)           :b1a, 2027-07-07, 2027-08-26
  UAE partner stack selection (fiat, cards, on-off ramp, KYC/AML)            :b2, 2027-07-16, 2027-09-14
  UAE integrations v1 + status normalization (staging)                       :b3, 2027-08-20, 2027-11-06
  UAE observability pack (SLO, provider dashboards, alerts)                  :b3a, 2027-09-06, 2027-11-18
  UAE ops readiness (playbooks, monitoring, training)                        :b4, 2027-09-12, 2027-12-13
  UAE go-to-market setup (ICP, referral rules, lifecycle comms)              :b5, 2027-09-28, 2027-12-27
  UAE limited launch (cohorts, monitoring, fixes)                            :b6, 2027-12-22, 2028-02-02
  UAE scale-up (channels, partner ops, reliability)                          :b7, 2028-01-19, 2028-03-02
  Gate B1 (UAE stack ready in staging)                                       :milestone, gb1, 2027-11-09, 0d
  Gate B2 (UAE go-live approved)                                             :milestone, gb2, 2027-12-20, 0d

  section Block 2 completion
  Gate P2 (Phase 2 readiness - partner exit plan approved)                   :milestone, gp2, 2028-03-07, 0d

Tip

The main outcome is readiness to exit partners without rewriting the Core and without loss of quality, while simultaneously establishing a position in the UAE market and reducing operational noise after launch.

Block 3: Phase 2 (13 months) + Phase 3 (15 months)

Info

Block 3 is the execution block: in the EU we go live on own licenses and fully exit partners, in the UAE we start through partners and then obtain a license only for the Core and transition the UAE to own operations on the Core. Modules are launched in full scope in the EU, while in the UAE within Block 3 we launch only modules without licensing. RWA is excluded from Block 3 and moved to Block 4.

mindmap
  root((Block 3 - Execution))
    Outcomes
      EU - own licenses live
      EU - full exit from partners
      UAE - launch via partners
      UAE - Core moved to own license
      Modules - EU full scope
      Modules - UAE non-licensed only
      RWA - excluded (Block 4)
    Phase 2 (13m)
      EU licensing go-live
        Regulatory approvals + audits
        Policies - AML/KYC - sanctions - SCA
        Reporting - tax - statements - evidence
      Partner exit program (EU)
        Data migration + ledger reconciliation
        Cutover - rollback plan
        PSP - cards - custody vendor switches
      UAE via partner
        Product launch - geo rules
        Local operations + support
        Risk tuning on real traffic
      Stability as a product
        Incident response + on-call
        Fraud/risk cases + playbooks
        Bug fixing - hardening - performance
    Phase 3 (15m)
      UAE Core own license
        Licensing package + build-out
        Move flows from partner to DARCA Core
        Compliance ops - MLRO - monitoring
      EU modules - release waves
        Wave 1
          Enhanced Security
          Cold Storage
          Piggy Bank
        Wave 2
          Messenger (E2EE + financial objects)
          Habit Tracker
          NFT (safe inbox)
        Wave 3
          My Games
          Mining
      UAE modules (allowed only)
        Enhanced Security
        Cold Storage
        Piggy Bank
        Habit Tracker
        Messenger (if allowed)
        NFT (if allowed)
    Programs
      Platform upgrades
        Security updates + device signals
        Observability + QA automation
        Docs - templates - localization ops
      Operations & growth
        Support - in-app actions + AI copilot
        Pricing - subscriptions + overage
        Metrics - activation - retention
    Gates
      EU - partner exit complete
      UAE - partner launch stable
      EU - module waves shipped
      UAE - Core own license live
      Block 4 readiness
        Audit evidence + scalable ops

Scope of Block 3 and final outcomes

Block 3 combines Phase 2 and Phase 3 into a single managed program, where readiness from Block 2 turns into real production, migrations, and module scaling.

Block 3 lasts 28 months and includes Phase 2 (13 months) and Phase 3 (15 months). Unlike Block 2, where we brought the system to a state of readiness, here we execute what is usually the most risky stage for fintech - real production rollout, migrations to own rails, normalization of operational processes, and further functional expansion through modules without breaking Core stability.

It is important to fix the principle of Block 3: first we confirm resilience and financial correctness in live operations, and only then scale the product. This reduces operating costs, lowers support load, and prevents regulatory risks that arise when the system grows faster than its operational maturity.

The end of Phase 2 must conclude with two independent but equally important outcomes. In the EU we must actually go live on own licenses, complete migration, and close partner dependency within the agreed perimeter so that no hidden links remain in critical operations. In the UAE we must launch operations through partners and bring this setup to a stable mode where operation statuses, documents, support, incident handling, and dispute resolution work predictably and at scale. At the same time, modules in Phase 2 remain secondary: we begin development, may release in a limited way, and only if this does not affect stability and migrations.

The end of Phase 3 establishes a different regional split. In the EU, by the end of Phase 3 we launch all modules of Block 3 except RWA. In the UAE, by the end of Phase 3 we obtain licenses only for the Core, complete the transition from partners to own Core operations, and launch only those modules that do not expand the licensed perimeter - that is no-license modules. All regulatory sensitive modules within Block 3 remain outside UAE obligations.

Note

RWA (T-Bills, Metals, RWA sm, RWA Home) is fully excluded from Block 3 - neither development nor launch is performed during this period. This scope is moved to Block 4 (Phase 4).

Execution rules and why the order is structured this way

Block 3 is governed by rollout discipline and a continuous stability stream - this protects the Core during migrations and module releases.

In Block 3 there is a fundamental conflict: migrations, new regions, and functional growth all happen simultaneously. If everything is accelerated at once, the Core begins to degrade, the number of stuck operations increases, support tickets grow, compliance checks become more complex, and operational debt accumulates. Therefore Block 3 is structured so that any change проходит only through controlled rollout discipline and so that the team always maintains a dedicated stream responsible for resilience and operations.

Each migration and each module release is executed via feature flags and regional switches, then through phased rollout to limited cohorts, and only after quality is confirmed is the rollout expanded further. An important principle is that any module is allowed into production only when it has monitoring, alerts, runbooks, and a rollback plan. A separate priority is also fixed: financial correctness and document correctness are more important than the speed of functional growth, because these factors determine user trust and the ability to meet regulatory requirements.

Warning

If reconciliation discipline and staged rollout are not maintained, any wave of modules turns into a sharp increase in operating costs and compliance risk rather than an acceleration of product growth.

Work programs of Block 3

We run Block 3 as a set of parallel programs with gates: the EU on own licenses, the UAE through partners, then Core licensing in the UAE, continuous stability, and module releases.

To avoid turning Block 3 into one endless backlog, we execute it as a set of programs, each with its own readiness criteria. The cross-cutting Stability and Operations program runs throughout all 28 months and covers incidents, money correctness, disputes, support, security, and audit evidence. In parallel, the EU program proceeds, where we execute the actual go-live on own licenses and complete the exit from partners, and the UAE program, which in Phase 2 is responsible for the partner-based launch, and in Phase 3 for obtaining a license only for the Core and executing the partner - own transition on the Core. A separate program is dedicated to module releases, which in Phase 2 is limited and possible only in the EU if capacity is available, and in Phase 3 becomes the main line of product development in the EU, while the UAE receives only no-license modules after stabilization of its own Core.

Example

This format allows migrations, regional launches, and functional growth to proceed simultaneously without breaking delivery predictability and without mixing critical operations with product expansion.

Phase 2 (13 months) - EU on own licenses and UAE launch via partners

Phase 2 is the transition to a live operating mode: own licenses and rails in the EU, a stable partner setup in the UAE, and operational maturity as a mandatory condition for scaling.

Phase 2 begins with two launches executed in a controlled manner through limited cohorts. In the EU we perform go-live on own licenses and start cohort-based migration, while simultaneously validating operation correctness through shadow checks, status control, document verification, and reconciliation. In the UAE we also start through partners with limited cohorts in order to validate support processes, statuses, documents, disputes, and investigations before transaction volumes become significant.

After the initial launches, Phase 2 moves into the ramp-up stage. In the EU we expand cohorts and migrate domains to own rails step by step - this reduces blast radius and enables fast rollback in case of degradation. At the same time we bring operational processes to production cadence: compliance ops, payments ops, treasury ops, investigations, refunds, reconciliations. In the UAE we establish a baseline of operations on the partner setup: clear operation statuses, correct documents, predictable support SLA, and stable provider monitoring.

Phase 2 concludes with the EU formally and operationally closing partner dependency within the agreed perimeter: unnecessary integrations are deactivated, hidden dependencies are eliminated, the partner exit complete criterion is fixed, and regular reporting and audit evidence are embedded into daily operations. In the UAE, by this point the partner-based launch must be stable: growth continues without an avalanche increase in support tickets and without accumulation of financial discrepancies.

Modules in Phase 2 are developed in parallel, but released very selectively and only in the EU, if this does not interfere with migrations and the UAE launch. As a minimum acceptable set of releases we consider Savings Jar, Habit Tracker, and Enhanced Security, because they strengthen retention and trust without expanding the licensed perimeter.

Tip

In Phase 2 we deliberately do not maximize functionality. We maximize controllability, money correctness, and support reliability - this is cheaper and faster than fixing these aspects after scaling.

Phase 3 (15 months) - full module rollout in the EU and Core licensing in the UAE

Phase 3 scales the product: in the EU all modules of Block 3 are launched, while in the UAE we obtain a license only for the Core and transition the Core to own operations.

Phase 3 runs through two major tracks that must not block each other. The first track is module releases in the EU in waves, in order to preserve Core stability and avoid overloading support. The second track is the UAE: obtaining a license only for the Core, preparing local operations for the Core, then performing a limited go-live on own Core and gradually transitioning from partners to own operations.

We begin Phase 3 with the launch of the Core licensing program in the UAE and the first wave of modules in the EU. Core licensing in the UAE requires a separate operating model and local procedures, therefore the compliance and ops framework specifically for the Core is prepared in parallel. In the EU at the same time we launch the first wave of modules that deliver clear user value and strengthen security and retention, while their release can be controlled through flags and cohorts.

Phase 3 then moves into the period of highest complexity. In the UAE we perform a limited go-live of own Core, run dual-run, migrate domains step by step, and always maintain a rollback plan. In the EU we launch subsequent waves of modules, including complex and regulatory sensitive ones, but only after passing gates for security, monitoring, runbooks, and support readiness. This ensures that Core quality is not compromised at the moment when functionality becomes significantly broader.

Phase 3 concludes with two independent facts. In the EU, by the end of the phase all modules of Block 3 except RWA are launched. In the UAE, by the end of the phase a license only for the Core is obtained and the partner - own transition on the Core is completed, after which we can launch only no-license modules without expanding the licensed perimeter.

Note

We deliberately limit the module perimeter in the UAE within Block 3 in order to first build a resilient Core on own licenses and avoid multiplying risk during migration.

Modules of Block 3 and EU - UAE release matrix

In the EU, by the end of Phase 3 the full set of modules (except RWA) is launched, while in the UAE only no-license modules are launched on top of own Core.

Block 3 includes all DARCA modules except RWA. The full list of modules in this block is: P2P, Token Factory, Staking, Cold Storage, Enhanced Security, Anti-crisis Safe, Messenger, NFT, Savings Jar, Habit Tracker, My Games, Mining, Business, Payments. RWA is fully moved to the next block.

In the EU, by the end of Phase 3 we commit to launching the entire set of these modules, because the EU is our region where the full product perimeter is established. In the UAE, by the end of Phase 3 we commit to launching own Core under license and limiting the module perimeter only to no-license modules in order not to expand the licensed scope and not to increase regulatory complexity during migration.

The minimum mandatory set of no-license modules for the UAE within Block 3 is Enhanced Security, Savings Jar, and Habit Tracker. Additionally, if operational readiness is confirmed and support is not overloaded, we may expand the no-license set with Messenger and My Games. Modules such as Cold Storage, NFT, and Anti-crisis Safe are allowed in the UAE only with separate sign-off and at high ops maturity, because they increase the risk perimeter and support load.

Warning

Regulatory sensitive modules - Staking, Token Factory, P2P, Business, Payments, Mining - within Block 3 are considered EU-only and are not part of the UAE launch obligations.

Module release waves in the EU during Phase 3

We release modules in waves to preserve Core stability and control operational risks.

In the EU, releases in Phase 3 are executed in waves. The first wave includes foundation no-license modules that deliver daily value and strengthen security and retention: Enhanced Security, Savings Jar, Habit Tracker, Anti-crisis Safe, Messenger, My Games. The second wave includes higher risk infrastructure user modules: Cold Storage and NFT, where requirements for security, monitoring, and support are the highest. The third wave includes regulatory sensitive modules that require the strictest gates and rollouts: Staking, Token Factory, P2P, Business, Payments, Mining.

Example

Each wave is a sequence of staged rollouts, not one large release. A module is allowed into production only when it has monitoring, alerts, runbooks, a rollback plan, and support readiness.

Stability and operational maturity as the foundation of scaling

The cross-cutting stability stream makes scaling controllable: incidents, reconciliations, disputes, support, and audit evidence become part of the product and processes.

In Block 3, the stability stream is not a supporting function. It is the mechanism that allows the product to evolve while preserving trust in the Core. Therefore, it includes a continuous incident management loop, monitoring across operations and providers, financial reconciliations and discrepancy handling, disputes and complaints processes with evidentiary support, support as part of the product with in-chat actions and an AI co-pilot, as well as regular security measures and audit readiness through proper evidence collection.

Tip

The earlier we turn operations into a system - statuses, operation dossier, documents, support actions, automation - the cheaper each subsequent module launch and each new regional rollout becomes.

Gates and control checkpoints

Gates turn the plan into a managed program: we expand cohorts and release modules only when stability, financial correctness, and ops readiness are confirmed.

Gates in Block 3 are not a formality. They are required to ensure that any expansion happens only after quality is validated in production. At the end of Phase 2, we confirm that the EU has completed go-live and migrations and has formally closed the partner exit, while the UAE has demonstrated a stable partner mode. Additionally, platform readiness for modules is confirmed - feature flags, regional switches, and staged rollout tooling. In Phase 3, we separately confirm obtaining the Core license in the UAE, limited go-live of the proprietary Core, completion of the partner - own transition for the Core, launch of the minimum set of no-license modules in the UAE, and release of the full module set in the EU.

Warning

If any gate is not confirmed, we do not expand cohorts and do not accelerate releases. We eliminate the root cause, because otherwise Block 3 turns into accumulated operational debt that destroys the economics of scale.

Outcome of Block 3

Block 3 completes the transition to sustainable scale: the EU becomes fully own-licensed and feature-complete (except RWA), the UAE obtains an own license for the Core and a safe set of no-license modules, and the operating system becomes mature for further expansion.

gantt
  title DARCA Road-map - Block 3 Timeline (Phase 2 + Phase 3, updated)
  dateFormat  YYYY-MM-DD
  axisFormat  %b %Y

  section Block 3 Frame
  Block 3 Start (after Block 2)                        :milestone, b3start, 2028-03-08, 1d
  Phase 2 (EU own-license + UAE partner)               :p2, 2028-03-08, 2029-04-19
  Phase 3 (EU all modules + UAE Core own-license)      :p3, 2029-04-20, 2030-08-02
  Block 3 End                                          :milestone, b3end, 2030-08-02, 1d

  section S3 - Stability and Operations (runs all Block 3)
  War-room setup + escalation matrix refresh           :s3a, 2028-03-11, 2028-04-10
  Go-live security hardening (early controls)          :s3a2, 2028-03-13, 2028-04-20
  Observability v2 (SLO, dashboards, tracing)          :s3b, 2028-03-19, 2028-06-06
  Provider health monitoring + degradation alerts      :s3b2, 2028-04-07, 2028-06-23
  Reconciliation v2 (breaks queue, SLA, owners)        :s3c, 2028-03-30, 2028-07-06
  Break management automation (top cases auto-resolve) :s3c2, 2028-05-03, 2028-08-18
  Disputes lifecycle + evidence store (prod-ready)     :s3d, 2028-04-16, 2028-08-02
  Chargeback economics + playbooks (cards)             :s3d2, 2028-05-26, 2028-08-28
  Complaints handling workflow + reporting             :s3d3, 2028-06-04, 2028-09-14
  Support actions in chat (ops buttons, deep-links)    :s3e, 2028-04-23, 2028-08-01
  Support QC loop (auto-summaries, root-cause tags)    :s3e2, 2028-06-18, 2028-10-08
  AI copilot for support (suggestions, summarization)  :s3f, 2028-06-10, 2028-09-20
  Knowledge base lifecycle + defect feedback loop      :s3f2, 2028-07-02, 2028-10-22
  Security cadence (VA, pen-test cycles)               :s3g, 2028-04-25, 2030-07-20
  Access reviews + key rotation cadence                :s3g2, 2028-05-12, 2030-07-26
  BCP/DR drills and incident exercises                 :s3h, 2028-08-06, 2030-07-29

  section EU3 - Phase 2 (EU own-license execution and partner exit)
  EU cutover rehearsal 1 (dry-run + rollback)          :eu21, 2028-03-22, 2028-04-05
  EU limited cohorts go-live (own license)             :eu22, 2028-04-07, 2028-04-29
  EU shadow checks (ledger, docs, statuses)            :eu23, 2028-04-11, 2028-05-23
  EU case management go-live (AML/sanctions queues)    :eu23b, 2028-04-26, 2028-06-18
  EU screening tuning (false positives, escalation SLA):eu23c, 2028-05-10, 2028-07-04
  EU statements + receipts prod hardening              :eu23d, 2028-05-14, 2028-07-19
  EU tax outputs pipeline (classification, exports)    :eu23e, 2028-06-01, 2028-08-12
  EU migration ramp wave 1 (domain-by-domain)          :eu24, 2028-05-04, 2028-07-10
  EU ops cadence live (compliance, payments, treasury) :eu25, 2028-05-12, 2028-08-21
  EU reconciliation hardening in prod                  :eu26, 2028-05-24, 2028-09-02
  EU regulatory reporting cadence live                 :eu26b, 2028-06-08, 2028-09-10
  EU audit evidence pack operationalized               :eu26c, 2028-06-19, 2028-09-24
  EU migration ramp wave 2 (wider cohorts)             :eu27, 2028-07-15, 2028-10-01
  EU historical data migration + verification          :eu27b, 2028-08-03, 2028-10-26
  EU retention/archiving policy enforcement            :eu27c, 2028-08-21, 2028-11-09
  EU partner dependency audit (hidden coupling)        :eu28, 2028-08-10, 2028-10-11
  EU provider SLA governance + failover rehearsal      :eu28b, 2028-09-03, 2028-11-21
  EU cutover rehearsal 2 (stress, rollback drills)     :eu29, 2028-09-18, 2028-10-03
  EU partner exit execution (core flows)               :eu210, 2028-10-06, 2028-12-18
  EU decommission partner integrations                 :eu211, 2028-12-06, 2029-01-23
  EU partner exit acceptance (formal gate)             :milestone, eu2gate, 2029-01-27, 1d
  EU post-exit hypercare and stabilization             :eu212, 2029-01-28, 2029-03-28

  section UAE3a - Phase 2 (UAE launch via partners and stabilize)
  UAE partner integration finalization                 :uae21, 2028-03-27, 2028-04-25
  UAE limited cohorts go-live (partner mode)           :uae22, 2028-04-27, 2028-05-18
  UAE ops baseline (statuses, docs, support)           :uae23, 2028-05-07, 2028-07-18
  UAE disputes lifecycle + partner SLA alignment       :uae24, 2028-05-27, 2028-08-09
  UAE investigations and holds playbooks               :uae24b, 2028-06-09, 2028-08-23
  UAE monitoring by providers + SLO                    :uae25, 2028-06-08, 2028-08-24
  UAE complaints handling baseline                     :uae25b, 2028-07-03, 2028-09-17
  UAE growth start (ICP, channels, lifecycle)          :uae26, 2028-07-03, 2028-12-14
  UAE partner mode stabilization gate                  :milestone, uae2gate, 2028-12-18, 1d
  UAE partner mode optimization (cost, routing)        :uae27, 2028-12-19, 2029-04-18

  section M3 - Phase 2 (modules dev + limited EU releases if safe)
  Module platform runtime controls (flags, region toggles, kill switch) :m2a, 2028-06-13, 2028-10-26
  Entitlements + subscription enforcement (modules)    :m2a2, 2028-07-05, 2028-11-28
  Billing events + module access controls              :m2a3, 2028-08-02, 2028-12-19
  Release governance toolkit (go/no-go, freeze rules)  :m2a4, 2028-08-23, 2028-11-09
  EU optional no-license module 1 (Piggy bank)         :m2b, 2028-10-31, 2028-12-06
  EU optional no-license module 2 (Habit tracker)      :m2c, 2028-11-19, 2029-01-12
  EU optional no-license module 3 (Enhanced Security)  :m2d, 2028-12-13, 2029-02-08
  Phase 3 readiness gate (platform + stability)        :milestone, m2gate, 2029-03-30, 1d

  section UAE3b - Phase 3 (UAE Core license and partner -> own Core migration)
  UAE Core licensing program start                     :uae31, 2029-04-23, 2029-05-10
  UAE policy pack + operating model for Core           :uae32, 2029-05-07, 2029-08-17
  UAE core rails build (settlement, recon, reporting)  :uae33, 2029-06-05, 2029-10-26
  UAE compliance ops tooling + case management         :uae34, 2029-06-24, 2029-10-13
  UAE provider governance + failover drills            :uae34b, 2029-07-18, 2029-10-30
  UAE Core license obtained                            :milestone, uae3lic, 2029-10-29, 1d
  UAE own Core limited cohorts go-live                 :uae35, 2029-11-05, 2029-12-02
  UAE dual-run + domain cutover (staged)               :uae36, 2029-11-24, 2030-02-02
  UAE historical data migration + verification          :uae36b, 2029-12-11, 2030-02-20
  UAE retention/archiving policy enforcement            :uae36c, 2029-12-28, 2030-03-06
  UAE partner exit for Core (execution)                :uae37, 2030-01-20, 2030-03-13
  UAE partner exit acceptance for Core                 :milestone, uae3gate, 2030-03-18, 1d
  UAE post-migration hypercare                         :uae38, 2030-03-19, 2030-04-25

  section EU Modules - Phase 3 (full portfolio in EU, RWA excluded)
  Wave governance + go/no-go gates (per wave)          :eugov, 2029-04-24, 2030-06-30
  Rollback drills per wave (tabletop + live rehearsal) :eugov2, 2029-05-12, 2030-06-18
  EU Wave 1 - foundation no-license modules            :euw1, 2029-04-26, 2029-09-19
  EU Wave 2 - high-risk user infra modules             :euw2, 2029-09-07, 2029-12-27
  EU Wave 3 - regulated-sensitive modules (non-RWA)    :euw3, 2029-11-14, 2030-06-26
  EU modules completion gate                           :milestone, eumdone, 2030-06-30, 1d
  EU module stabilization and optimization             :euw4, 2030-07-01, 2030-07-28

  section EU Wave 1 detail
  Enhanced Security (module rollout)                   :euw1a, 2029-04-30, 2029-06-11
  Piggy bank (module rollout)                          :euw1b, 2029-05-22, 2029-07-03
  Habit tracker (module rollout)                        :euw1c, 2029-06-06, 2029-07-18
  Anti-crisis Vault (module rollout)                    :euw1d, 2029-06-28, 2029-08-15
  Messenger (module rollout, E2EE objects)              :euw1e, 2029-07-23, 2029-09-11
  My Games (module rollout)                             :euw1f, 2029-08-07, 2029-09-17

  section EU Wave 2 detail
  Cold Storage (module rollout)                         :euw2a, 2029-09-10, 2029-11-12
  NFT (module rollout, anti-scam contour)               :euw2b, 2029-10-18, 2029-12-22

  section EU Wave 3 detail (non-RWA)
  Staking (module rollout)                              :euw3a, 2029-11-18, 2030-02-03
  Token Factory (module rollout)                        :euw3b, 2029-12-12, 2030-03-06
  P2P (module rollout)                                  :euw3c, 2030-01-10, 2030-03-28
  Business (module rollout)                              :euw3d, 2030-02-18, 2030-05-04
  Payments (module rollout)                              :euw3e, 2030-03-08, 2030-06-06
  Mining (module rollout)                                :euw3f, 2030-04-10, 2030-06-24

  section UAE no-license modules - Phase 3 (only after UAE Core stable)
  UAE Enhanced Security rollout                          :uaenm1, 2030-04-28, 2030-05-22
  UAE Piggy bank rollout                                 :uaenm2, 2030-05-07, 2030-06-04
  UAE Habit tracker rollout                               :uaenm3, 2030-05-26, 2030-06-21
  UAE optional Messenger rollout (if ops ready)          :uaenm4, 2030-06-15, 2030-07-10
  UAE optional My Games rollout (if ops ready)           :uaenm5, 2030-07-02, 2030-07-26

  section Gates and milestones
  Phase 2 - EU partner exit complete                     :milestone, g1, 2029-01-27, 1d
  Phase 2 - UAE stable partner mode                      :milestone, g2, 2028-12-18, 1d
  Phase 3 - UAE Core license obtained                    :milestone, g3, 2029-10-29, 1d
  Phase 3 - UAE partner exit for Core complete           :milestone, g4, 2030-03-18, 1d
  Phase 3 - EU all modules complete                      :milestone, g5, 2030-06-30, 1d
  Block 3 complete                                       :milestone, g6, 2030-08-02, 1d

By the end of Block 3, DARCA in the EU operates under its own licenses and has a full functional module perimeter, except for RWA, which is moved to the next block. In the UAE, DARCA operates under its own licenses for the Core, completes the transition from partners to its own operational model for the Core, and launches only those modules that do not expand the licensed perimeter. At the same time, the organization establishes a mature operational foundation - reconciliations, disputes, support with in-product actions, automation, and audit evidence - so that further geographic expansion and the launch of Block 4 do not require rebuilding the foundation.

Block 4 - Phase 4 (24 months): full launch in the UAE, launch in the US under own licenses, RWA factory, readiness for global expansion

Info

Block 4 transforms DARCA from a strong product in the EU and a Core platform in the UAE into an international platform: the UAE obtains licenses for modules and the full portfolio, the US is launched immediately under own licenses, RWA is structured as a production program, and global launches via partners become a scalable process.

mindmap
  root((Block 4 - Phase 4 - 24 months))
    Outcomes
      UAE - full scope core and modules
      US - launch on own licenses
      RWA program launched
      Global expansion readiness
      Continuous hardening
    Workstreams
      UAE full scope
        Module licensing
        Ops and compliance scale
        Module rollout waves
      US own-license launch
        Licensing program - 12 months
        Build-out for US rules
        Launch and stabilization
      RWA program
        Legal structure and disclosures
        Partner network
        Object Vault and audit trail
        Pilot then scale
      Platform maintenance
        Core upgrades
        Security upgrades
        Risk and fraud upgrades
        Observability and SRE
      Global partner expansion
        Partner launch kits
        Localization pipeline
        Compliance readiness packs
    Sequencing
      Months 1-6
        US licensing kickoff
        UAE module licensing kickoff
        Core hardening cycle
        RWA design and partner sourcing
      Months 7-12
        US build-out and exams readiness
        UAE module readiness
        RWA MVP tech
      Months 13-18
        US launch prep and pilots
        UAE full scope go-live waves
        RWA pilot assets
      Months 19-24
        US launch and stabilization
        UAE full scope mature ops
        RWA scale-up
        Global expansion kits ready

Goals and target end state of Block 4

We define measurable outcomes: what exactly must be ready after 24 months and why this requires a dedicated phase.

Note

In Block 4, we do not simply “add countries”. We build a multi-jurisdictional operating system: licenses, processes, evidence base, release discipline, and only then scaling.

By the end of Block 4, we confirm four outcomes that must be achieved simultaneously.

First, the UAE moves from the mode of “Core under its own license + a limited set of modules” to the mode of “Core + the full module portfolio”. This means that licenses in the UAE expand the perimeter not only to the transactional core but also to module functionality, after which modules are launched in waves with mandatory stabilization after each wave, bringing operational quality to the EU level: reconciliation, disputes, reporting, audit evidence, and support with in-chat actions.

Second, the US is launched immediately under its own licenses, without a partner-based launch model. We set a realistic benchmark: obtaining the key licensing perimeter takes about 12 months. Therefore, Block 4 is structured so that by the time licenses are obtained, both the system and operations are “launch-ready”, and the US launch becomes the activation of a pre-prepared setup rather than the start of development.

Third, the RWA program is launched as a dedicated “factory”, not as a single module. The key focus here is not the UI or the smart contract, but the chain of documents, partners, tranches, evidence, and reporting. In Block 4, RWA is launched “where possible”: through geo-fencing, jurisdiction and asset-type restrictions, and strict compliance links..

Fourth, Block 4 concludes with readiness for large-scale global expansion via partners. Important: this expansion applies to regions outside the US, because in this strategy the US is own-only. By the end of the phase, we must have a “launch factory”: integration templates, SLA standards, monitoring, incident and support playbooks, partner requirements, and an exit plan.

Work architecture of Block 4 – programs and accountability

Phase 4 is executed not as a single task list but as a set of parallel programs, each with its own gates and critical risks.

Tip

To prevent Block 4 from turning into an overloaded roadmap, we define six programs: S4, O4, U4, R4, P4, G4.

We describe Block 4 as six programs because this structure makes it easier to control dependencies and avoid mixing licensing, product, and operational changes.

S4 – Stability and Security Updates – a continuous 24-month program. It includes security updates, defect fixes, provider migrations, failover drills, monitoring improvements, reduction of cost-to-serve, and mandatory stabilization windows after major releases.
O4 – UAE Full Licensing + Modules Rollout – obtaining UAE licenses for modules and rolling out the full module portfolio in the UAE in waves.
U4 – US Own Licensing + US Own Launch – US licensing (target timeline about 12 months) as the critical path, followed by a staged launch after licenses are obtained.
R4 – RWA Factory Program – a dedicated production line covering documentation, partners, processes, Object Vault, reporting, and risk controls.
P4 – Global Partner Expansion Factory – a scalable launch factory for global expansion via partners outside the US.
G4 – Governance and Compliance Platform – the multi-region control layer: policy engine, compliance adapters, entitlements, and release discipline.

For terms that matter to investors and regulators, we use concise references: Compliance, Governance, OFAC, Money_laundering, Real-world_asset.

Work sequencing over 24 months

We show what happens first, what runs in parallel, and what is only possible after licensing and stabilization.

Warning

In Block 4, the US is the critical path. Therefore, we start U4 in the first month and do not commit to a production launch until the license is obtained, but we make the system launch-ready in advance so as not to lose time after approval.

We divide the 24 months into three meaningful subperiods. These are not “steps” but a way to explain dependencies.

Subperiod A - M1-M8: launch long chains and build the foundation

At the start of the phase, we launch what cannot be “accelerated by development”: licensing and partner factories. At the same time, we strengthen system quality in the EU and UAE, because during the expansion phase quality cannot remain “as is”.

In U4 (US), we begin by defining the full licensing and operational perimeter for “all modules”. We establish the company structure, roles, procedures, and prepare the evidence base: policies, IT security evidence, BSA/AML processes, OFAC, SAR/CTR, recordkeeping, and audit. At this stage, we are not “waiting for the license” but building a “licensable organization and system”. By the end of the subperiod, the application package is submitted and the team operates in a “regulatory project” mode.

In O4 (UAE), we simultaneously launch licensing for modules. The key principle is that we do not try to enable the entire portfolio at once. Instead, we define activation waves and prepare the operating model and reporting in advance so that once licenses are granted, module launches are not blocked by internal unpreparedness.

In R4 (RWA), we design the factory: legal package, disclosures, partner chain (originators, SPV or escrow, valuation, insurance, audit, servicing), and the evidence framework through the Object Vault. We define that tokenization in our model grants rights to cash flows and transparent redemption terms rather than ownership rights, and we embed this as a standard in documentation and UX.

Within S4 and G4, we build the foundation for multi-region operations. This includes the policy engine (allow, step-up, hold, deny), compliance adapters for different regulatory perimeters, module access rights (entitlements), and release discipline (go or no-go decisions, rollback drills, kill switches). These elements are required not only for the US and UAE but also to ensure the EU continues to evolve without quality degradation.

The gate for Subperiod A means that US licensing is not merely “planned” but actively in progress, UAE licensing for modules has been launched, the RWA factory is defined at the level of documentation and partner chains, and S4 and G4 provide a controlled foundation for releases and restrictions.

Subperiod B - M9-M16: execution, first expansion launches, the US becomes launch-ready pending license

During the second subperiod, the main work of execution and launch preparation takes place. It is important here to advance the UAE and RWA simultaneously without losing momentum in the US track.

In U4 (US), we go through an active phase of regulatory questions, comments, and remediation. We bring compliance processes to a production level: case queues, SLA discipline, evidence management, and regular reporting. In parallel, we conduct rehearsals: incident drills, reporting drills, reconciliation drills. This means that once the license is granted, the launch does not start “from zero” but is activated on a prepared system.

In O4 (UAE), we begin enabling modules in waves as licenses are obtained. Each wave includes not only the release itself but also a stabilization window: defect resolution, monitoring tuning, bringing support to a stable case resolution pace, and reducing errors in operational processes.

In R4 (RWA), we launch pilots “where feasible”. This means selecting specific jurisdictions and asset types where approvals, partners, and compliance frameworks allow execution without compromise. A pilot includes the Object Vault, cash flow reporting, milestone and tranche rules, and predefined incident and default scenarios.

In P4 (Global), we test the launch factory in 1 to 2 pilot regions through partners (excluding the US). The objective is not revenue scale but validation that we can launch regions in a repeatable, fast, and controlled way without creating a manual project lasting 6 to 9 months.

Within S4, the flow of updates and fixes continues in both the EU and UAE: security improvements, reliability enhancements, provider changes, and support process optimization. This flow is intentionally not paused because real production expansion in the US and UAE inevitably generates new defects and requirements.

The gate for Subperiod B means that the UAE has progressed in module launches while maintaining stability, the RWA pilot has been confirmed end-to-end, the global launch factory has been validated through pilots, and the US is technically and operationally ready to launch once the license is granted.

Subperiod C - M17-M24: finalization - the US launches, the UAE obtains the full portfolio, RWA scales, global expansion is ready

The third subperiod includes the highest-risk events of the phase, which is why the plan deliberately incorporates stabilization windows and strict release discipline.

In U4 (US), the key milestone is license approval (target approximately 12 months from the start of the licensing process). After this, we perform a limited cohorts go-live, staged ramp-up, and module activation in waves until full configuration is achieved. Each wave is accompanied by stabilization, expanded monitoring, and confirmation of compliance operations readiness.

In O4 (UAE), we complete licensing for modules and enable the remaining portfolio elements. It is important to recognize that launching the “last modules” is always more complex than the first ones: more requirements, higher risks, and greater load on support and operations. Therefore, waves and gates are mandatory, and the final outcome is full-scope UAE functionality with demonstrable operational quality.

In R4 (RWA), we expand partnerships and the asset pipeline, establishing the factory as a repeatable process. RWA scales not through marketing but through standardized documentation, verifiable cash flow reporting, transparent buyback rules and stress event scenarios, and strict geo-fencing controls.

In P4 (Global), we finalize the assembly of “launch kit v2”. This is a set of repeatable components: integration templates, SLA and monitoring standards, incident procedures, support with actionable workflows, document and policy templates, partner risk assessment frameworks, and exit plans in case partner quality deteriorates. By the end of the subperiod, we are ready for parallel launches in multiple regions through partners.

Within S4, the third subperiod includes mandatory windows for defect remediation and security updates. We proactively acknowledge that after the US launch and UAE expansion, defects and incidents are inevitable and treat them as part of the production lifecycle rather than as deviations from the plan.

Where and how modules are launched in Block 4

We present a transparent picture: the EU continues to evolve, the UAE expands in waves after licensing, the US is activated after obtaining own licenses, and RWA develops as a separate program.

Example

The logic of enabling modules in new regions is based on risk and licensing: first no-license and low-risk modules, then high-risk user infrastructure modules, then regulated-sensitive modules, and only after operational maturity is confirmed.

EU - the module portfolio is already operational. In Block 4, continuous improvement is performed: security, reliability, UX optimization, cost-to-serve reduction, and increased transparency of documents and statuses.
UAE - the module portfolio is enabled in waves after licenses are obtained. Within each wave, priority is given to modules that deliver the highest user value and require minimal expansion of the licensed perimeter. Subsequently, higher-risk modules and modules requiring the strictest regulatory regime are introduced.
US - module launches begin only after obtaining own licenses and follow a staged rollout: first limited cohorts, then growth, and then full portfolio enablement in waves.
RWA - develops as a separate program and may be enabled asymmetrically across regions: earlier in some jurisdictions and later in others, depending on the legal framework and partner readiness.

Risk management and quality control

Block 4 includes significant regulatory and operational risks, therefore we define in advance how timelines, quality, and trust are controlled.

Danger

The main risk of Block 4 is not development speed but the gap between licenses, operations, and production quality. Therefore, S4 and G4 are mandatory programs rather than optional activities.

We define four control layers.

The first is control of US licensing: starting from the first month, ensuring the system and operations are “pending license” ready, with clear gates and no commitments to a production launch before approvals are granted. This prevents losing 6 to 9 months after licensing due to sudden preparation needs.

The second is control of quality degradation: S4 runs throughout all 24 months and includes stabilization windows after every major launch, security cycles, and mandatory drills. We pre-determine the capacity for fixing defects because in real banking environments bugs after go-live are inevitable.

The third is RWA control: RWA operates as a factory program with structured documentation, partner frameworks, and defined constraints. Piloting and geo-fencing replace a “universal launch”, and each step is supported by evidence-based artifacts and reporting..

The fourth is control of partner risks for global expansion: due diligence, SLA discipline, monitoring, and exit planning. The partner model must remain controllable; otherwise, it undermines trust and operational resilience.

What changes after Block 4

By the end of the phase, DARCA is prepared not for isolated launches but for repeatable scaling - with licenses, process factories, and quality control.

Question

After Block 4, DARCA becomes a platform capable of scaling without losing integrity: what exactly enables launching new regions faster and more safely than in the earlier phases?

gantt
  title DARCA Road-map - Block 4 Timeline (Phase 4, 24 months)
  dateFormat  YYYY-MM-DD
  axisFormat  %b %Y

  section Block 4 Frame (aligned with Blocks 1-3)
  Block 4 Start                                            :milestone, b4start, 2030-07-09, 0d
  Phase 4 (24 months)                                      :b4, 2030-07-09, 2032-07-06
  Block 4 End                                              :milestone, b4end, 2032-07-06, 0d

  section S4 - Stability, Security, Updates (EU + UAE + Platform) - continuous
  Security updates cadence (patching, VA cycles)            :s4a, 2030-07-15, 2032-06-28
  Bugfix stream (Core + Modules, EU+UAE)                    :s4b, 2030-07-20, 2032-06-26
  EU regulatory change backlog (docs, reporting, limits)    :s4eu, 2030-08-06, 2032-06-14
  Observability upgrades (SLO, tracing, alerting)           :s4c, 2030-08-12, 2031-02-22
  Provider governance (SLA, incidents, failover drills)     :s4d, 2030-08-25, 2032-06-20
  Reconciliation hardening (multi-region ledger evidence)   :s4e, 2030-09-11, 2031-06-03
  Disputes and complaints ops hardening (multi-region)      :s4f, 2030-09-24, 2031-06-21
  DR drills and incident exercises (quarterly cycles)       :s4g, 2030-10-09, 2032-06-10

  section G4 - Governance and Compliance Platform (multi-region control)
  Policy engine v2 (allow, step-up, hold, deny)             :g4a, 2030-07-22, 2030-12-18
  Compliance adapters v2 (docs, limits, reporting)          :g4b, 2030-08-14, 2031-02-26
  Entitlements v2 (modules by region, access control)       :g4c, 2030-09-05, 2031-01-28
  Release governance v2 (go/no-go, rollback, kill switch)   :g4d, 2030-09-27, 2031-03-05
  Audit evidence automation (region evidence packs)         :g4e, 2030-10-16, 2031-05-02

  section U4 - USA Own Licensing (critical path, ~12 months)
  US scope mapping (modules -> licenses -> obligations)      :us1, 2030-07-18, 2030-10-06
  US key hires and fit/governance readiness                  :usHire, 2030-08-05, 2030-12-03
  US compliance program build (BSA/AML, OFAC, SAR/CTR)       :us3, 2030-08-21, 2031-02-28
  US recordkeeping and audit readiness foundation            :us4, 2030-09-15, 2031-03-18
  US policies and controls pack finalization                 :us5, 2030-10-11, 2030-12-20
  US license submission                                      :milestone, ussubmit, 2030-12-23, 0d
  Regulator Q&A and remediation loop 1                       :us6, 2030-12-27, 2031-05-09
  Regulator Q&A and remediation loop 2                       :us7, 2031-05-13, 2031-08-26
  US mock exam and final readiness pack                      :usExam, 2031-07-14, 2031-09-06
  US licenses granted                                        :milestone, uslic, 2031-09-09, 0d
  US compliance training and attestations (ongoing readiness):usTrain, 2030-11-06, 2032-06-02

  section U4 - USA Pre-launch and Launch (own-only, post-license)
  US pre-launch rehearsals (incident, reporting, recon)      :us9, 2031-03-10, 2031-09-01
  US go-live kit (runbooks, rollback, support readiness)     :us10, 2031-06-05, 2031-09-04
  US limited cohorts go-live (Core + baseline)               :us11, 2031-09-22, 2031-10-18
  US staged ramp wave 1                                      :us12, 2031-10-22, 2031-12-20
  US stabilization window 1                                  :us13, 2031-12-23, 2032-01-30
  US modules enablement wave 2                               :us14, 2032-02-03, 2032-03-29
  US stabilization window 2                                  :us15, 2032-04-01, 2032-04-29
  US modules enablement wave 3 (full portfolio target)       :us16, 2032-05-03, 2032-06-18
  US stabilization window 3                                  :us17, 2032-06-20, 2032-07-02
  US post-launch audit cycle planning (Year 1)               :usAudit1, 2031-10-10, 2032-02-06
  US all modules live                                        :milestone, usfull, 2032-07-04, 0d

  section O4 - UAE Licensing for Modules (full scope)
  UAE module scope mapping (modules -> licenses)             :uae1, 2030-07-24, 2030-10-15
  UAE operating model for expanded scope                     :uae2, 2030-08-19, 2030-12-22
  UAE compliance ops expansion (case mgmt, reporting)        :uae3, 2030-09-09, 2031-02-27
  UAE license pack preparation                               :uae4, 2030-10-28, 2031-01-29
  UAE licensing submission                                   :milestone, uaesub, 2031-02-03, 0d
  UAE regulator reviews and remediation                      :uae5, 2031-02-07, 2031-07-04
  UAE module-licenses granted (wave-ready)                   :milestone, uaelic1, 2031-07-08, 0d
  UAE remaining licenses for full portfolio                  :uae6, 2031-07-12, 2032-02-10
  UAE full licenses for modules granted                      :milestone, uaelic2, 2032-02-14, 0d

  section O4 - UAE Modules Rollout (waves with stabilization + ops/support scale)
  UAE support playbooks and in-chat actions expansion        :uaeSup, 2031-01-06, 2032-06-12
  UAE ops staffing and case management scale-up              :uaeOps, 2031-03-03, 2032-03-20
  UAE modules wave 1 (low-risk + no-license first)           :uae7, 2031-07-15, 2031-09-03
  UAE stabilization window A                                 :uae8, 2031-09-06, 2031-10-08
  UAE modules wave 2 (higher-risk user infra)                :uae9, 2031-10-12, 2031-12-18
  UAE stabilization window B                                 :uae10, 2031-12-22, 2032-01-23
  UAE modules wave 3 (regulated-sensitive after uaelic2)     :uae11, 2032-02-21, 2032-05-29
  UAE stabilization window C                                 :uae12, 2032-06-01, 2032-06-27
  UAE all modules live                                       :milestone, uaefull, 2032-06-30, 0d

  section R4 - RWA Factory Program (heavy process, geo-gated)
  RWA legal framework and disclosures pack                   :rwa1, 2030-07-29, 2030-12-23
  RWA partner sourcing (originators, SPV/escrow, audit)      :rwa2, 2030-08-18, 2031-03-14
  RWA operating model (milestones, tranches, buyback)        :rwa3, 2030-09-09, 2031-03-07
  Object Vault (docs, evidence, audit trail)                 :rwa4, 2030-10-02, 2031-04-11
  RWA risk policy (EDD, geofencing, limits)                  :rwa5, 2030-10-17, 2031-03-18
  RWA partner onboarding completed (pilot set)               :milestone, rwaOnb, 2031-03-21, 0d
  RWA jurisdiction approval gate 1 (pilot regions)           :milestone, rwaJ1, 2031-04-03, 0d
  RWA pilot launch (where possible)                          :rwa6, 2031-04-07, 2031-06-23
  RWA stabilization and reporting cadence                    :rwa7, 2031-06-26, 2031-09-01
  RWA jurisdiction approval gate 2 (scale regions)           :milestone, rwaJ2, 2031-09-08, 0d
  RWA scale wave 1 (more assets, stronger ops)               :rwa8, 2031-09-12, 2032-01-26
  RWA scale wave 2 (standardization, more jurisdictions)     :rwa9, 2032-01-31, 2032-06-08
  RWA program production-ready for expansion                 :milestone, rwagat2, 2032-06-13, 0d

  section P4 - Global Partner Expansion Factory (excluding USA)
  Partner risk scoring framework + exit playbook             :p4risk, 2030-10-21, 2031-02-07
  Partner launch kit v1 (contracts, SLA, monitoring)         :p41, 2030-12-02, 2031-04-22
  Compliance and policy adapters for partners                :p42, 2031-01-06, 2031-05-21
  Pilot region 1 launch via partner                          :p43, 2031-05-26, 2031-07-18
  Stabilization and learnings (pilot 1)                      :p44, 2031-07-21, 2031-08-25
  Pilot region 2 launch via partner                          :p45, 2031-08-29, 2031-10-23
  Stabilization and learnings (pilot 2)                      :p46, 2031-10-27, 2031-12-05
  Launch kit v2 (repeatable parallel launches)               :p47, 2031-12-09, 2032-04-28
  Global expansion readiness gate                            :milestone, p4gate, 2032-05-06, 0d
  Partner network scaling prep (multi-region pipeline)       :p48, 2032-05-10, 2032-06-30

  section Phase 4 Gates (foundation -> execution -> full readiness)
  Gate A (foundation ready)                                  :milestone, b4gateA, 2031-03-10, 0d
  Gate B (execution proven)                                  :milestone, b4gateB, 2031-11-26, 0d
  Gate C (final readiness)                                   :milestone, b4gateC, 2032-07-06, 0d

By the completion of Block 4, DARCA reaches a level where growth is driven not by the volume of manual work but by repeatable mechanisms. In the UAE, the full portfolio of modules operates within the licensed perimeter. In the US, the product is launched under own licenses and evolves in waves while maintaining compliance discipline and operational discipline. RWA functions as a factory with structured documentation, a partner chain, and evidentiary transparency. At the same time, global expansion through partners becomes a scalable procedure in which each new region is connected through a standardized launch kit, while quality is sustained by S4 and G4 as continuous production programs.

Final frame: controlled growth without quality loss

This roadmap defines not a list of features but an operational program for transforming DARCA into a scalable platform - through financial data quality control, managed regional transitions, and pre-designed modularity.

Info

The value of this plan lies in shifting DARCA’s development from a mode of “accelerate and hope” to a mode of controlled execution with clear gates and admission criteria.

This document describes a sequence of work in which the quality and correctness of financial operations act as a speed constraint rather than a side effect. The logic is built around a simple principle: functional and geographic expansion is allowed only after production stability, data accuracy, and operational, support, and compliance readiness have been confirmed.

Block 1 establishes the creation of a complete Core as a unified fiat plus crypto perimeter - with operational statuses, operation dossiers, and documents treated as mandatory parts of the product rather than “to be added later”. The result is a production-ready Core where integrations, design, communications, support processes, and quality measures (QA, load testing, security) are included in scope alongside code.

Block 2 defines the correct post-launch reality: defects, incidents, and integration tail issues are inevitable, therefore they are structured as a dedicated stabilization program. At the same time, readiness for partner exit is formed and the UAE is launched through partners without compromising the quality of the main product. This reduces the risk that scaling becomes an accumulation of uncontrolled operational debt.

Block 3 consolidates execution of Phase 2 and Phase 3 into a single trajectory: transition of the EU to own licenses and partner exit, alongside continued operations in the UAE through partners followed by migration of the Core to own licensing. Modules are released in waves, with the UAE perimeter at the end of Phase 3 limited to modules that do not require licensing, while RWA is deliberately moved to the next block in order not to dilute the critical path.

Block 4 completes the transformation of DARCA into an international platform: full module scope in the UAE under appropriate licenses, US launch immediately under the own-license model, initiation of the RWA factory program as a separate complex production line (documentation, partnerships, operational evidence, and risk controls), and preparation for global expansion through partners using a repeatable “launch kit” approach.

Warning

Scaling without gates and admission criteria almost always leads to growth of “hidden debt”: more countries, modules, and integrations but less predictability in money flows, statuses, documentation, and support.

The key outcome of this plan is built-in controllability:

Gates and “definition of done” link releases to measurable quality conditions rather than calendar dates
modular Core plus Modules architecture enables product expansion without UX fragmentation or Core rewrites
dependence on partners is treated as a phase rather than a permanent state, with predefined transition paths and reversibility
security, risk, and compliance are embedded in the roadmap as a continuous production discipline

Tip

The plan remains tactically flexible regarding specific providers and priority countries, but methodologically strict: growth is permitted only while maintaining operational predictability and data correctness.

Explorer

Road-map

Block 1: From work start to Core launch (15 months)

Goal, boundaries, and Definition of Done

Sequence and logic - why this approach

Parallel workstreams

Stages M1-M15 and outcomes

Stage 0 - Foundation (M1-M2)

Stage 1 - Build 1 and early end-to-end (M3-M5)

Stage 2 - Daily completeness (M6-M8)

Stage 3 - EU-30 scaling and beta readiness (M9-M11)

Stage 4 - Security, performance and feature freeze (M12-M13)

Stage 5 - Hardening and launch (M14-M15)

Control gates and admission criteria

Result after 15 months

Block 2: Growth after launch, stabilization, and preparation for Phase 2 (9 months)

Context and objectives of the period

Goals and success criteria after 9 months

How we execute this block

Program C: Post-launch stability

C1. Incident and bug management as a production process

C2. Observability and SLO for operations

C3. Reconciliation and data correctness as the foundation of trust

C4. Reducing support load through the product

Program A: EU transition to own licenses

A1. Licensing and regulatory program

A2. License-level policies and procedures

A3. Target Operating Model and replacement of partner functions

A4. Core readiness for own rails

A5. Risk-AML stack v2 and case management

A6. Card program path and migration readiness

A7. Data platform and regulatory reporting

A8. Migration strategy partner → own

Program B: UAE launch via partners

B1. UAE regional packaging

B2. Selection and integration of UAE providers

B3. UAE ops readiness

B4. UAE go-to-market and growth

Internal breakdown of the 9 months by focus

Control checkpoints - readiness gates

Outcome of Block 2

Block 3: Phase 2 (13 months) + Phase 3 (15 months)

Scope of Block 3 and final outcomes

Execution rules and why the order is structured this way

Work programs of Block 3

Phase 2 (13 months) - EU on own licenses and UAE launch via partners

Phase 3 (15 months) - full module rollout in the EU and Core licensing in the UAE

Modules of Block 3 and EU - UAE release matrix

Module release waves in the EU during Phase 3

Stability and operational maturity as the foundation of scaling

Gates and control checkpoints

Outcome of Block 3

Block 4 - Phase 4 (24 months): full launch in the UAE, launch in the US under own licenses, RWA factory, readiness for global expansion

Goals and target end state of Block 4

Work architecture of Block 4 – programs and accountability

Work sequencing over 24 months

Subperiod A - M1-M8: launch long chains and build the foundation

Subperiod B - M9-M16: execution, first expansion launches, the US becomes launch-ready pending license

Subperiod C - M17-M24: finalization - the US launches, the UAE obtains the full portfolio, RWA scales, global expansion is ready

Where and how modules are launched in Block 4

Risk management and quality control

What changes after Block 4

Final frame: controlled growth without quality loss

Table of Contents

Backlinks