Road-map

Блок 1: От старта работ до запуска Core (15 месяцев)

Info

Этот блок описывает последовательность работ, контрольные точки и результаты, которые за 15 месяцев приводят к запуску рабочего Core DARCA в EU-30 через партнерскую модель.

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

Цель, границы и Definition of Done

Фиксируем, что именно считается готовым ядром, что входит в 15 месяцев, и почему это важно для управляемого запуска.

Note

Мы считаем готовым не только код, но и полный контур дизайна, интеграций, документов, тестирования и операционной готовности к запуску 24-7.

Что означает “готовый Core к запуску” (по результатам M15):

  • Accounts and Ledger - единые счета и учет (fiat + crypto), история, доступный баланс, блокировки, idempotency
  • Internal transfers - мгновенные переводы внутри DARCA по телефону, email, ID, QR с проверкой получателя
  • External fiat rails - пополнение, вывод, внешние переводы и реквизиты для 30 стран ЕС на day 1
  • Crypto custody - депозиты и выводы, выбор сетей, адресная книга, проверки адресов и memo-tag, статусы подтверждений
  • Daily exchange - предпросмотр you send-you receive, котировки, исполнение, документы по обмену
  • Cards - пластик через партнера, lifecycle, операции, controls, уведомления, disputes, dual funding по возможностям партнера
  • Bill payments - оплата услуг и счетов (каталог, формы, квитанции, автоплатежи) через агрегатора
  • Operation dossier - единое “досье операции”: статусы, таймлайн, причины, next steps для всех типов операций
  • Documents and statements - чек по операции, выписки, экспорт (PDF, CSV), хранение и повторная генерация
  • Tax layer v1 - классификация, cost basis baseline, отчеты за период, годовой отчет, экспорт tax-ready данных
  • Support as product - in-app чат, кейсы, кнопки и deep-links, AI + оператор, действия по некритичным запросам
  • Risk and compliance decisioning - allow, step-up, hold, deny, журналы решений, санкции и AML hooks
  • Notifications - события, шаблоны, настройки, центр уведомлений
  • Ops readiness - мониторинг, SLO, алерты, runbooks, on-call, dry runs, go-live checklist

Что намеренно не входит в этот блок (и не нагружает 15 месяцев):

  • модуль Business (корпоративные роли, approvals, инвойсы, KYB как расширение)
  • модули RWA, P2P, Token Factory, Messenger как модуль, NFT, Mining и остальные “Modules”

Очередность и логика - почему именно так

Фиксируем архитектурные принципы, которые делают масштабирование EU-30 и запуск за 15 месяцев управляемыми.

Tip

Основа плана - platform-first: сначала единая модель операции, статусов, документов, риска и поддержки, затем интеграции и масштабирование на страны.

Ключевые принципы:

  • EU-30 это конфигурации, а не 30 отдельных продуктов
  • Operation dossier является центральным объектом UX, поддержки и доверия
  • интеграции нормализуются в одну state machine и один формат документов
  • документы и i18n запускаются в первые 4-6 недель, иначе масштабирование сорвется
  • последние 2 месяца - hardening и запуск, без расширения scope

Параллельные потоки работ

Разделяем программу на потоки, чтобы разработки кода, дизайна, документов и интеграций не блокировали друг друга.

Example

Внутри 15 месяцев мы работаем не “по очереди”, а в 6 параллельных потоках, которые сходятся в единые контрольные точки.

Поток A - Product, Design, Content:

  • design system, UX ключевых сценариев, дизайн карты, дизайн писем и уведомлений
  • сайт и личные кабинеты, help center, контент и копирайт
  • контент матрица, шаблоны рассылок и уведомлений

Поток B - Core Platform:

  • ledger и счета, оркестрация операций, статусы, досье
  • document engine, выписки, экспорт
  • лимиты, fees, overage, уведомления
  • tax layer v1

Поток C - EU Fiat Rails (EU-30):

  • provider matrix покрытия, интеграции пополнений, выводов, внешних переводов
  • нормализация статусов и ошибок провайдеров
  • country packs: реквизиты, форматы, fees, сроки, доступность функций

Поток D - Cards integration (пластик через партнера):

  • lifecycle карты, активация, controls, уведомления
  • операции карты как объекты Core (auth, capture, settlement)
  • disputes, документы, поддержка сценариев
  • dual funding по возможностям партнера

Поток E - Crypto + Exchange:

  • deposits, withdrawals, сети, адресная книга, политики на новые адреса
  • exchange: quoting, preview you send-you receive, исполнение, документы

Поток F - Risk, Support, QA, Sec, Ops:

  • risk decisioning (allow, step-up, hold, deny), policy rules, журналы решений
  • in-app support: кейсы, кнопки, deep-links, AI + оператор
  • тестирование (unit, integration, e2e), регрессии, multi-country QA
  • безопасность, pen-test, remediation
  • мониторинг, SLO, runbooks, on-call, dry runs

Этапы M1-M15 и результаты

Разбиваем 15 месяцев на 6 этапов так, чтобы рано получить end-to-end, успеть масштабировать EU-30 и заложить окно стабилизации.

Warning

Самый дорогой риск - “интеграционный ад” в конце. Поэтому end-to-end появляется уже на M5, а EU-30 и документы закрываются до начала hardening.

Этап 0 - Foundation (M1-M2)

Что делаем:

  • фиксируем scope Core v1 и критерии “готово к запуску”
  • утверждаем доменную модель: операция, статусы, досье, документы, риск, поддержка
  • выбираем провайдеров и получаем sandbox:
    • fiat rails EU-30 (provider matrix покрытия)
    • cards partner (пластик, процессинг, события)
    • custody, exchange, KYC-AML, sanctions
    • bill payments aggregator
  • запускаем document engine skeleton и data dictionary для подрядчиков документов
  • запускаем i18n pipeline: выгрузка всех строк, загрузка переводов, AI перевод + проф ревью
  • запускаем design system и hi-fi прототипы ключевых flows

Почему это первым:

  • без провайдеров и data contracts невозможно строить корректные статусы, документы и поддержку
  • без i18n и document engine масштабирование на EU-30 сорвется по срокам

Выходы этапа:

  • спецификации интеграций и sandbox доступы
  • state machine статусов v1
  • design system v1 и прототипы ключевых экранов
  • document engine v0 и data dictionary
  • i18n pipeline v0

Этап 1 - Build 1 и ранний end-to-end (M3-M5)

Что делаем:

  • ledger и счета, история, idempotency
  • internal transfers по телефону, email, ID, QR с подтверждением получателя
  • external fiat rails wave 1-3: пополнение, вывод, переводы, реквизиты
  • crypto custody v1: deposits, withdrawals, address book, валидации сетей
  • exchange v1: quoting, preview you send-you receive, execution
  • operation dossier v1: таймлайн, статусы, причины, next steps
  • документы v1: receipts, statements, экспорт (PDF, CSV)
  • support foundation: кейсы по операциям, кнопки и deep-links
  • risk decisioning v1 для ключевых операций

Почему это вторым:

  • ранний end-to-end показывает реальные ограничения провайдеров и корректирует модель статусов, документов и поддержки до масштабирования EU-30

Выходы этапа:

  • 4 end-to-end сценария в staging:
    • internal transfer
    • external fiat transfer
    • crypto withdrawal
    • exchange
  • документы и досье операции работают на всех типах операций v1

Этап 2 - Daily completeness (M6-M8)

Что делаем:

  • cards integration end-to-end:
    • lifecycle карты, доставка, активация
    • операции карты (auth, capture, settlement) как объекты Core
    • controls: freeze, лимиты, geo, режимы
    • уведомления по событиям карты
  • disputes workflow v1 и документы по спорам
  • bill payments v1:
    • каталог, формы, квитанции
    • автоплатежи v1
  • tax layer v1 старт:
    • классификация событий
    • cost basis baseline
    • отчеты за период и экспорт
  • external fiat rails: доведение покрытия до 70-80 процентов стран

Почему это здесь:

  • карты и bill payments создают ежедневную привычку, их нельзя откладывать на конец
  • tax layer должен встраиваться до финального hardening, иначе не будет времени на проверку данных

Выходы этапа:

  • карты и bill payments работают end-to-end в staging
  • disputes доступны из операции и из поддержки
  • tax v1 формирует базовые отчеты и экспорт

Этап 3 - EU-30 scaling и beta readiness (M9-M11)

Что делаем:

  • закрываем coverage EU-30 полностью:
    • provider matrix, резервные контуры, нормализация статусов
    • country packs: реквизиты, форматы, комиссии, сроки, тексты
  • i18n pipeline production-grade:
    • версия словаря, проверки, fallback
    • критичные строки через отдельный review workflow
  • подключаем документы от подрядчиков:
    • legal и операционные шаблоны по странам
    • привязка к document engine и данным операций
  • готовим эксплуатацию:
    • monitoring, SLO, алерты, stuck queues
    • support playbooks, escalation с провайдерами
    • dry-run сценарии типовых проблем

Почему это до hardening:

  • EU-30 и документы должны быть завершены до “заморозки”, иначе последние месяцы уйдут на догоняющую интеграцию вместо стабилизации

Выходы этапа:

  • EU-30 полностью работает в staging
  • локализации ключевых flows готовы
  • документы по странам подключены к engine
  • beta готовность: ops и поддержка способны сопровождать продукт

Этап 4 - Security, performance и feature freeze (M12-M13)

Что делаем:

  • pen-test и remediation
  • нагрузочные тесты, отказоустойчивость, chaos сценарии
  • оптимизация ретраев, дедупликации, stuck rate
  • улучшение сообщений причин и next steps для поддержки
  • feature freeze в конце M13

Почему выделяем окно:

  • без отдельного окна безопасности и производительности запуск будет сопровождаться критическими инцидентами и ручными кейсами

Выходы этапа:

  • закрытый pen-test
  • пройденные нагрузочные и отказоустойчивость
  • feature freeze

Этап 5 - Hardening и запуск (M14-M15)

Что делаем:

  • dry runs: go-live checklist, процедуры отката, режимы деградации
  • on-call и инцидент контур: runbooks, эскалации, SLA контроль
  • запуск по когортам:
    • ограниченные включения, мониторинг, быстрые фиксы
    • post-launch review и план первых недель

Почему запуск выделен отдельно:

  • запуск - это операционный проект, требующий дисциплины и готовности к инцидентам, а не только готовности кода

Выходы этапа:

  • запуск Core в прод
  • стабильные метрики качества и сопровождения

Контрольные точки и критерии допуска

Gates фиксируют минимально необходимую готовность перед переходом к следующему этапу и защищают последние месяцы от расползания scope.

Question

Если любой gate не закрыт, проект не “ускоряется”, а переприоритизируется, чтобы сохранить hardening и запуск.

G1 (конец M2):

  • провайдеры выбраны, есть sandbox и data contracts
  • state machine статусов v1 и mapping ошибок
  • design system v1 и прототипы ключевых flows
  • document engine v0 и data dictionary для подрядчиков
  • i18n pipeline v0

G2 (конец M5):

  • 4 end-to-end сценария в staging
  • досье операции и документы v1 на всех типах операций
  • support actions v1 и risk decisioning v1

G3 (конец M8):

  • карты, disputes и bill payments end-to-end в staging
  • tax layer v1 стартовал и интегрирован в документы и экспорт
  • покрытие fiat rails достигло 70-80 процентов стран

G4 (конец M11):

  • EU-30 coverage полностью в staging
  • country packs и локализации ключевых flows готовы
  • документы по странам подключены к document engine
  • beta readiness: ops, monitoring, support playbooks

G5 (конец M13):

  • pen-test закрыт, remediation выполнен
  • нагрузка и отказоустойчивость пройдены
  • feature freeze

G6 (конец M15):

  • hardening завершен, go-live checklist закрыт
  • запуск выполнен, контроль качества в проде включен

Результат 15 месяцев

На выходе мы получаем Core, готовый к эксплуатации и масштабированию, а не “прототип, который еще нужно доводить”.

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

Итог программы - рабочее ядро daily-банка, где каждая операция имеет статусы, документы и поддержку с действиями, а масштабирование EU-30 достигается конфигурацией, а не переписыванием продукта.

На выходе запуска:

  • продукт готов для пользователей EU-30 (partner mode), включая карты, обмен, переводы, оплату услуг
  • операционная готовность 24-7: мониторинг, SLO, поддержка, runbooks, эскалации
  • документальный контур: чеки, выписки, tax v1, локальные шаблоны и форматы
  • основа для перехода к фазе 2 (собственные лицензии) без переписывания Core

Блок 2: Рост после запуска, стабилизация и подготовка к Phase 2 (9 месяцев)

Info

Период 2027-06-07 → 2028-03-07 - это 9 месяцев после запуска Core, где мы одновременно делаем 3 вещи: стабилизируем прод, готовим уход от партнеров и открываем рынок ОАЭ через партнеров.

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

Контекст и задача периода

После запуска Core в partner mode неизбежны баги и операционные отклонения, поэтому следующий этап проектируется как программа перехода, а не как “доделки”.

Note

Мы заранее закладываем, что после запуска будет поток багов, инцидентов, расхождений и тикетов поддержки. Если не выделить под это отдельную программу, переход к Phase 2 сорвется из-за постоянного “пожаротушения”.

Этот блок закрывает переход от состояния:

  • Core запущен через партнеров и работает в EU-30 в partner mode

К состоянию:

  • Core стабилен в проде и масштабируется без потери качества
  • команда и процессы готовы к режиму own-licensed в ЕС
  • ОАЭ запущен через партнеров как отдельный рыночный трек
  • подготовлена миграция от партнеров с управляемым риском и обратимостью

Цели и критерии успеха через 9 месяцев

Формулируем, что именно должно быть готово и измеримо, чтобы Phase 2 началась как контролируемый переход, а не как авантюра.

Tip

В этом периоде “успех” - это не рост любой ценой, а устойчивость и readiness: качество, управляемость, доказуемость, подготовка к регуляторной ответственности.

Цель C (Stability) - стабилизировать продукт после запуска:

  • устойчивые операции по ключевым потокам (переводы, обмен, карты, bills, выводы crypto)
  • снижение доли тикетов “где деньги” через улучшение статусов и досье операции
  • регулярные релизы без поломки критичных сценариев

Цель A (EU Transition) - подготовить уход от партнеров и собственные лицензии:

  • готовый пакет комплаенса и операционных политик под регулятора
  • готовая операционная модель и распределение ответственности вместо партнера
  • готовность Core к собственным рельсам: оркестрация, settlement, reconciliation, reporting

Цель B (UAE Launch) - открыть рынок ОАЭ через партнеров:

  • региональная упаковка (geo-fencing, локальные правила, KYC)
  • подключенный UAE стек партнеров и нормализованные статусы в Core
  • операционная готовность сопровождения ОАЭ (support, playbooks, monitoring)

Как мы выполняем этот блок

Чтобы план был реалистичным, мы ведем 3 параллельные программы и фиксируем емкость под стабилизацию.

Warning

В эти 9 месяцев запрещено “ускоряться” за счет качества. Любая новая интеграция, миграция или релиз допускается только при наличии наблюдаемости, тестов, runbooks и rollback.

Организация работ:

  • Программа C - Post-launch stability - идет весь период, без остановки
  • Программа A - EU transition to own licenses - готовим переход от партнеров к собственным лицензиям и операционке
  • Программа B - UAE launch via partners - параллельный запуск ОАЭ через партнеров

Распределение емкости (принцип, а не жесткая цифра):

  • стабилизация - постоянная выделенная емкость, чтобы не “съедать” миграцию и лицензирование
  • EU transition - основной стратегический поток Phase 2
  • UAE launch - отдельный трек, который не должен ломать стабильность EU

Программа C: Post-launch stability

Стабилизация продукта после запуска - ключевое условие роста и перехода на собственные лицензии.

Example

Стабилизация - это не “фикс багов”, а переход продукта в режим управляемой эксплуатации, где проблемы быстро детектируются, локализуются, устраняются и не повторяются.

C1. Управление инцидентами и багами как производственный процесс

Что делаем:

  • единый triage backlog по классам P0-P3
  • hotfix policy: что можно чинить сразу, что идет в плановый релиз
  • обязательные RCA по P0-P1 и коррекция процессов, а не только кода
  • escalation matrix с партнерами по каждому домену: fiat, cards, KYC, crypto, bills

Что это дает:

  • меньше “хаоса” и срочных правок
  • предсказуемость релизов и устойчивость ключевых сценариев

C2. Observability и SLO по операциям

Что делаем:

  • SLO по основным операциям: внутренние переводы, внешние фиатные, обмен, card tx, bills, вывод crypto
  • дашборды stuck rate, fail rate, latency по операциям и по провайдерам
  • трассировка end-to-end по operation id и корреляция событий
  • отдельные дашборды для поддержки: статус, причина, следующий шаг

Что это дает:

  • быстрый детект деградации провайдера или ошибки в интеграции
  • снижение тикетов “где деньги” и время ответа поддержки становится быстрее и точнее

C3. Reconciliation и корректность данных как основа доверия

Что делаем:

  • ежедневные сверки по реестрам партнеров и собственному ledger
  • break management: очередь расхождений, причины, ответственность, авто-резолв где возможно
  • усиление idempotency, дедупликации и корректных ретраев по внешним вызовам

Что это дает:

  • финансы сходятся без ручных расследований
  • готовность к режиму собственных лицензий, где ответственность за расхождения не делегируется партнеру

C4. Снижение нагрузки на поддержку через продукт

Что делаем:

  • улучшаем Operation dossier: reasons и next steps для каждого статуса
  • support actions в чате: запрос документов, обновление статуса, повторная генерация документа, эскалация
  • AI co-pilot для операторов: предлагаемые ответы, авто-саммари, классификация темы
  • QC контур: выявление частых проблем и корректировка UX, контента и флоу

Что это дает:

  • меньше тикетов и выше FCR
  • поддержка работает как часть продукта, а не как “отдельный отдел”

Программа A: EU transition to own licenses

Переход на собственные лицензии - это перенос ответственности и операционных функций, а не только получение бумаги от регулятора.

Note

Регулятор оценивает способность управлять риском, процессами, данными и аудит-трейлом. Поэтому в этом блоке мы готовим операционку и доказательность параллельно с разработкой.

A1. Лицензирование и регуляторная программа

Что делаем:

  • фиксируем целевой набор лицензий Phase 2 (PI-EMI и crypto режим по необходимости)
  • выбираем home state и план пасспортизации
  • формируем календарь deliverables и владельцев
  • ведем outsourcing register и vendor risk контур

Что это дает:

  • предсказуемую траекторию Phase 2 и понимание требований к процессам и системе

A2. Политики и процедуры уровня лицензии

Что делаем:

  • AML-CTF program: EDD, PEP, SAR-STR, обучение, контроль качества
  • санкционный скрининг: правила, эскалации, хранение решений
  • safeguarding и funds flow maps (для EMI), segregation и контроль остатков
  • incident reporting и risk management framework
  • GDPR пакет: DPIA, retention, DSAR, privacy by design
  • complaint handling: правила и шаблоны коммуникации

Что это дает:

  • готовность к аудитам и регуляторной проверке
  • минимизацию рисков отказа при лицензировании и снижению операционных инцидентов

A3. Target Operating Model и замена партнерских функций

Что делаем:

  • описываем, что сегодня выполняет партнер и что будет выполнять DARCA
  • формируем TOM и RACI по процессам
  • планируем внутренние функции:
    • compliance operations (alerts, cases, SAR)
    • payments ops (investigations, returns, chargebacks)
    • treasury ops (liquidity, settlement)
    • reconciliation function (ежедневные сверки и контроль)

Что это дает:

  • понятный план перехода и минимизация “серых зон ответственности”

A4. Готовность Core к собственным рельсам

Что делаем:

  • payments orchestration: routing, fallback, SLA политики, cost control
  • settlement и accounting модель: end-of-day, возвраты, reversals
  • reconciliation v2: правила matching, очереди break, авто-резолв
  • regulatory-grade statements v2: обязательные поля, сроки хранения, immutable logs

Что это дает:

  • Core способен работать на собственных рельсах без переписывания архитектуры
  • появляется контроль над экономикой и качеством сервиса

A5. Risk-AML stack v2 и case management

Что делаем:

  • уточняем требования и выбираем vendor stack (KYC, screening, TM, blockchain analytics где нужно)
  • строим case management: evidence store, SLA, audit trail, роли и права
  • настраиваем rule packs: velocity, new payees, geo, device, patterns
  • tuning false positives и качество решений (без роста ручной нагрузки)

Что это дает:

  • способность безопасно масштабироваться без неконтролируемых hold и deny
  • лицензируемая операционная готовность комплаенса

A6. Card program путь и готовность к миграции

Что делаем:

  • выбираем целевую модель на перспективу (sponsor BIN или issuer path)
  • унифицируем dispute workflows и evidence storage под свой case management
  • формируем план миграции карт по когортам, с коммуникациями и контрольными окнами

Что это дает:

  • снижение зависимости от партнеров и контроль над самым частым “ежедневным” продуктом

A7. Data platform и регуляторная отчетность

Что делаем:

  • DWH-ETL слой для регуляторных и управленческих отчетов
  • отчеты по AML, fraud, incidents, complaints
  • data retention и доказательность, чтобы аудит был быстрым и прозрачным

Что это дает:

  • готовность к отчетности и проверкам, снижение стоимости комплаенса на масштабе

A8. Стратегия миграции partner → own

Что делаем:

  • миграция по доменам: новые пользователи на own rails, затем existing cohorts
  • dual-run окно и cross-check reconciliation
  • rollback plan и degraded modes
  • коммуникации пользователям: изменения реквизитов, условий и сроков

Что это дает:

  • контролируемый переход без потери доверия и без “точки невозврата” в случае проблем

Программа B: UAE launch via partners

Запуск ОАЭ через партнеров позволяет открыть вторую юрисдикцию быстрее и параллельно подтверждать переносимость Core.

Tip

ОАЭ в этом блоке - это проверка, что Core масштабируется географически через конфигурации и провайдеров, не теряя качество статусов, документов и поддержки.

B1. Региональная упаковка ОАЭ

Что делаем:

  • geo-fencing: доступность функций и ограничения по продуктам
  • локальные ToS-Privacy-fees и KYC требования резиденты-нерезиденты
  • санкционный и screening контур с учетом специфики рельсов и USD рисков
  • локализация, каналы поддержки и правила коммуникаций

Что это дает:

  • запуск в ОАЭ без юридических и продуктовых “дыр”

B2. Выбор и подключение UAE провайдеров

Что делаем:

  • выбор партнеров ОАЭ: fiat rails, cards, on-off ramp, KYC-AML, bills где применимо
  • интеграции и нормализация статусов в state machine Core
  • SLA и escalation с партнерами, прозрачная зона ответственности

Что это дает:

  • UAE работает как часть платформы, а не как отдельный продукт

B3. UAE ops readiness

Что делаем:

  • playbooks по кейсам: disputes, investigations, KYC escalations
  • мониторинг по региону, отдельные дашборды и алерты
  • обучение поддержки и комплаенса под региональные сценарии

Что это дает:

  • сопровождение ОАЭ без перегруза команды и без просадки качества

B4. Go-to-market ОАЭ и рост

Что делаем:

  • ICP и позиционирование: individuals, freelancers, SMEs
  • referral механики и антифрод правила рефералки
  • lifecycle коммуникации: onboarding, activation, retention
  • локальные партнерства и каналы дистрибуции

Что это дает:

  • запуск ОАЭ превращается в управляемую воронку, а не в “релиз ради релиза”

Внутренняя разбивка 9 месяцев по фокусу

Чтобы избежать перегруза, мы меняем доминирующий фокус по периодам, сохраняя стабильность как постоянный поток.

Example

В первые 6-8 недель стабилизация более интенсивна. Далее стабилизация остается постоянной, а основная масса усилий уходит в EU readiness и UAE запуск.

Период 1 (первые 6-8 недель):

  • доминирует Program C: инциденты, баги, корректность данных, снижение тикетов
  • запускаются A1-A2 и B1 как подготовительные работы без тяжелых миграций

Период 2 (следующие 3-4 месяца):

  • растет Program A: policies, TOM, orchestration, case management
  • активно идет Program B: выбор провайдеров и интеграции ОАЭ
  • Program C продолжает снижать шум и укреплять качество

Период 3 (последние 3 месяца):

  • закрытие readiness gates Phase 2
  • финализация migration playbook, dual-run подготовка
  • UAE go-live или расширение на основе готовности стека и ops

Контрольные точки - readiness gates

Gates защищают Phase 2 от перехода “на эмоциях” и делают прогресс доказуемым для команды и инвесторов.

Warning

Если gate не закрыт, мы не расширяем географию и не ускоряем миграцию - мы устраняем причины, иначе риск возрастает нелинейно.

Gate S1 (stability baseline):

  • критические инциденты под контролем, есть устойчивый релизный процесс
  • observability покрывает ключевые операции и провайдеров
  • reconciliation и break management работают без ручного хаоса

Gate A1 (license-ready pack):

  • политики и процедуры собраны и готовы к регуляторной подаче
  • TOM и RACI утверждены, владельцы процессов определены

Gate A2 (own rails readiness):

  • orchestration, settlement и reconciliation готовы в staging
  • regulatory statements и audit trail соответствуют требованиям

Gate B1 (UAE stack ready):

  • UAE провайдеры выбраны, интеграции в staging, статусы нормализованы
  • SLA и escalation с партнерами определены

Gate B2 (UAE go-live readiness):

  • support playbooks, monitoring, обучение и операционные процедуры готовы
  • go-to-market готов, onboarding и коммуникации настроены

Gate P2 (Phase 2 readiness):

  • миграционная стратегия утверждена (dual-run, rollback, cohorts)
  • качество Core позволяет перенос ответственности без деградации сервиса
  • есть план перехода от партнеров с контрольными окнами и метриками

Результат блока 2

К началу Phase 2 мы приходим не с “планом на бумаге”, а с устойчивой платформой, готовой к лицензированию, миграции и расширению юрисдикций.

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

Главный результат - готовность уйти от партнеров без переписывания Core и без потери качества, параллельно закрепившись на рынке ОАЭ и снизив операционный шум после запуска.

Блок 3: Фаза 2 (13 месяцев) + Фаза 3 (15 месяцев)

Info

Блок 3 - это блок исполнения: в ЕС мы выходим в прод на собственных лицензиях и полностью уходим от партнеров, в ОАЭ стартуем через партнеров, а затем получаем лицензию только на Ядро и переводим ОАЭ на собственную работу по Core. Модули в полном объеме запускаем в ЕС, а в ОАЭ в рамках блока 3 запускаем только модули без лицензирования. RWA исключен из блока 3 и перенесен в блок 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

Объем блока 3 и конечные результаты

Блок 3 объединяет Фазу 2 и Фазу 3 в одну управляемую программу, где готовность из блока 2 превращается в реальный прод, миграции и масштабирование модулей.

Блок 3 длится 28 месяцев и включает Фазу 2 (13 месяцев) и Фазу 3 (15 месяцев). В отличие от блока 2, где мы доводили систему до состояния готовности, здесь мы выполняем то, что обычно является самым рискованным этапом для финтеха - реальный выход в прод, миграции на собственные рельсы, нормализацию операционных процессов и дальнейшее расширение функциональности через модули, не разрушая стабильность Ядра.

Важно зафиксировать принцип блока 3: сначала мы подтверждаем устойчивость и финансовую корректность в бою, и только затем масштабируем продукт. Это снижает стоимость эксплуатации, уменьшает нагрузку на поддержку и предотвращает регуляторные риски, которые появляются, когда система растет быстрее, чем ее операционная зрелость.

Конец Фазы 2 должен завершаться двумя независимыми, но одинаково важными итогами. В ЕС мы обязаны фактически выйти на собственные лицензии, пройти миграцию и закрыть партнерскую зависимость по согласованному периметру так, чтобы не осталось скрытых связей в критических операциях. В ОАЭ мы обязаны запустить работу через партнеров и довести этот контур до стабильного режима, где статусы операций, документы, поддержка, разбор инцидентов и споров работают предсказуемо и масштабируемо. При этом модули в Фазе 2 остаются второстепенными: мы начинаем разработку, можем выпускать ограниченно и только если это не влияет на стабильность и миграции.

Конец Фазы 3 фиксирует другое разделение по регионам. В ЕС к концу Фазы 3 мы запускаем все модули блока 3, кроме RWA. В ОАЭ к концу Фазы 3 мы получаем лицензии только на Ядро, выполняем переход от партнеров на собственную работу по Core и запускаем только те модули, которые не расширяют лицензируемый периметр - то есть no-license модули. Все регуляторно чувствительные модули в рамках блока 3 остаются для ОАЭ вне обязательств.

Note

RWA (T-Bills, Metals, RWA sm, RWA Home) полностью исключен из блока 3 - ни разработка, ни запуск не выполняются в этом периоде. Этот контур переносится в блок 4 (Фаза 4).

Правила исполнения и почему порядок именно такой

Блок 3 управляется дисциплиной выката и постоянным потоком стабильности - это защищает Ядро во время миграций и выпусков модулей.

В блоке 3 есть базовый конфликт: одновременно идут миграции, новые регионы и рост функционала. Если пытаться ускорить все сразу, Ядро начинает деградировать, растет число зависших операций, увеличивается количество обращений в поддержку, усложняются проверки комплаенса и появляется накопленный операционный долг. Поэтому блок 3 устроен так, чтобы любые изменения проходили только через контролируемую дисциплину выката и чтобы у команды никогда не исчезал отдельный поток, который отвечает за устойчивость и операции.

Каждая миграция и каждый модульный релиз выполняются через feature flags и региональные переключатели, затем через поэтапный выкат на ограниченные когорты, и только после подтверждения качества расширяются дальше. Важный принцип: любой модуль допускается в прод только тогда, когда он имеет мониторинг, алерты, runbooks и план отката. И отдельно фиксируется приоритет: финансовая корректность и корректность документов важнее скорости функционального роста, потому что именно эти вещи определяют доверие пользователей и возможность выдерживать регуляторные требования.

Warning

Если не держать дисциплину reconciliation и staged rollout, любая волна модулей превращается в резкий рост операционных затрат и комплаенс риска, а не в ускорение роста продукта.

Программы работ блока 3

Мы ведем блок 3 как набор параллельных программ с гейтами: ЕС на своих лицензиях, ОАЭ через партнеров, затем лицензия Core в ОАЭ, постоянная стабильность и выпуск модулей.

Чтобы не превратить блок 3 в один бесконечный backlog, мы исполняем его как набор программ, каждая из которых имеет собственные критерии готовности. Сквозная программа Stability and Operations работает все 28 месяцев и закрывает инциденты, корректность денег, disputes, поддержку, безопасность и audit evidence. Параллельно идет программа ЕС, где мы выполняем фактический go-live на собственных лицензиях и завершение выхода от партнеров, и программа ОАЭ, которая в Фазе 2 отвечает за партнерский запуск, а в Фазе 3 за получение лицензии только на Ядро и переход partner - own по Core. Отдельной программой идет выпуск модулей, который в Фазе 2 ограничен и возможен только в ЕС при наличии емкости, а в Фазе 3 становится основной линией развития продукта в ЕС, при этом ОАЭ получает только no-license модули после стабилизации собственного Ядра.

Example

Такой формат позволяет одновременно вести миграции, региональные запуски и рост функционала, не разрушая предсказуемость поставки и не смешивая критичную эксплуатацию с продуктовым расширением.

Фаза 2 (13 месяцев) - ЕС на своих лицензиях и запуск ОАЭ через партнеров

Фаза 2 - это переход в боевой режим: собственные лицензии и рельсы в ЕС, стабильный партнерский контур в ОАЭ, и операционная зрелость как обязательное условие для масштабирования.

Фаза 2 начинается с двух запусков, которые мы делаем контролируемо через ограниченные когорты. В ЕС мы выполняем go-live на собственных лицензиях и запускаем миграцию по когортам, параллельно проверяя корректность операций через shadow-проверки, контроль статусов, документов и reconciliation. В ОАЭ мы стартуем через партнеров также ограниченными когортами, чтобы отработать поддержку, статусы, документы, disputes и расследования до того, как объем операций станет значимым.

После первых запусков Фаза 2 переходит в стадию наращивания. В ЕС мы расширяем когорты и переводим домены на собственные рельсы поэтапно - это снижает blast radius и позволяет быстро откатываться при деградации. Одновременно мы доводим операционные процессы до production cadence: compliance ops, payments ops, treasury ops, расследования, возвраты, сверки. В ОАЭ мы строим baseline эксплуатации на партнерском контуре: понятные статусы операций, корректные документы, предсказуемые SLA поддержки и устойчивый мониторинг по провайдерам.

Фаза 2 завершается тем, что в ЕС мы формально и фактически закрываем зависимость от партнеров по согласованному периметру: деактивируем ненужные интеграции, устраняем скрытые связки, фиксируем критерий partner exit complete и закрепляем регулярную отчетность и audit evidence как часть ежедневной операционки. В ОАЭ к этому моменту партнерский запуск должен быть стабилен: рост идет без лавинообразного роста обращений и без накопления финансовых расхождений.

Модули в Фазе 2 мы начинаем разрабатывать параллельно, но выпускаем очень ограниченно и только в ЕС, если это не мешает миграциям и запуску ОАЭ. В качестве допустимого минимума релизов мы рассматриваем Копилку, Трекер привычек и Повышенную безопасность, потому что они усиливают удержание и доверие, не расширяя лицензируемый периметр.

Tip

В Фазе 2 мы сознательно не максимизируем функциональность. Мы максимизируем управляемость, корректность денег и надежность поддержки - это дешевле и быстрее, чем исправлять эти вещи после масштабирования.

Фаза 3 (15 месяцев) - полный запуск модулей в ЕС и лицензия на Ядро в ОАЭ

Фаза 3 масштабирует продукт: в ЕС запускаются все модули блока 3, а в ОАЭ мы получаем лицензию только на Core и переводим Ядро на собственную работу.

Фаза 3 идет двумя крупными треками, которые не должны блокировать друг друга. Первый трек - это выпуск модулей в ЕС волнами, чтобы сохранить стабильность Ядра и не перегрузить поддержку. Второй трек - это ОАЭ: получение лицензии только на Ядро, подготовка локальной операционки под Core, затем ограниченный go-live на собственном Core и поэтапный переход от партнеров на свою работу.

Мы начинаем Фазу 3 с запуска программы лицензирования Core в ОАЭ и первой волны модулей в ЕС. Лицензирование Core в ОАЭ требует отдельной операционной модели и локальных процедур, поэтому параллельно готовится compliance и ops контур именно под Ядро. В ЕС в это время мы запускаем первую волну модулей, которые дают пользователю понятную ценность и усиливают безопасность и удержание, при этом их релиз можно контролировать через flags и когорты.

Затем Фаза 3 переходит в период максимальной сложности. В ОАЭ мы делаем ограниченный go-live собственного Core, ведем dual-run, переводим домены поэтапно и всегда держим план отката. В ЕС мы запускаем последующие волны модулей, включая сложные и регуляторно чувствительные, но делаем это только после прохождения гейтов безопасности, мониторинга, runbooks и готовности поддержки. Это позволяет не нарушать качество Ядра в тот момент, когда функциональность становится существенно шире.

Фаза 3 завершается двумя независимыми фактами. В ЕС к концу фазы запущены все модули блока 3, кроме RWA. В ОАЭ к концу фазы получена лицензия только на Ядро и завершен переход partner - own по Core, после чего мы можем запустить только no-license модули, не расширяя лицензируемый периметр.

Note

Мы сознательно ограничиваем модульный периметр ОАЭ в рамках блока 3, чтобы сначала построить устойчивое Ядро на собственных лицензиях и не умножать риск во время миграции.

Модули блока 3 и матрица релизов ЕС - ОАЭ

В ЕС к концу Фазы 3 запущен полный набор модулей (кроме RWA), в ОАЭ - только no-license модули поверх собственного Ядра.

В блок 3 входят все модули DARCA, кроме RWA. Полный список модулей этого блока: P2P, Token Factory, Staking, Cold Storage, Повышенная безопасность, Антикризисный сейф, Мессенджер, NFT, Копилка, Трекер привычек, Мои игры, Майнинг, Business, Payments. RWA полностью вынесен в следующий блок.

В ЕС к концу Фазы 3 мы обязуемся запустить весь этот набор модулей, потому что ЕС является нашим регионом, где выстраивается полный продуктовый периметр. В ОАЭ к концу Фазы 3 мы обязуемся запустить собственное Ядро на лицензии и ограничить модульный периметр только no-license модулями, чтобы не расширять лицензируемый scope и не повышать регуляторную сложность в момент миграции.

Минимальный обязательный набор no-license модулей для ОАЭ в рамках блока 3 - это Повышенная безопасность, Копилка и Трекер привычек. Дополнительно, если операционная готовность подтверждена и поддержка не перегружена, мы можем расширить no-license набор за счет Мессенджера и Моих игр. Модули вроде Холодного хранения, NFT и Антикризисного сейфа допускаются в ОАЭ только при отдельном sign-off и при высокой зрелости ops, потому что они повышают риск-контур и нагрузку на поддержку.

Warning

Регуляторно чувствительные модули - Staking, Token Factory, P2P, Business, Payments, Майнинг - в рамках блока 3 считаются EU-only и не входят в обязательства запуска в ОАЭ.

Волны релизов модулей в ЕС в Фазе 3

Мы выпускаем модули волнами, чтобы сохранять стабильность Ядра и контролировать операционные риски.

В ЕС релизы в Фазе 3 выполняются волнами. Первая волна включает foundation no-license модули, которые дают ежедневную ценность и усиливают безопасность и удержание: Повышенная безопасность, Копилка, Трекер привычек, Антикризисный сейф, Мессенджер, Мои игры. Вторая волна включает более рискованные инфраструктурные пользовательские модули: Холодное хранение и NFT, где требования к безопасности, мониторингу и поддержке максимальные. Третья волна включает регуляторно чувствительные модули, которые требуют наиболее строгих гейтов и выкатов: Staking, Token Factory, P2P, Business, Payments, Майнинг.

Example

Каждая волна - это последовательность staged rollouts, а не один большой релиз. Модуль допускается в прод только тогда, когда у него есть мониторинг, алерты, runbooks, план отката и готовность поддержки.

Стабильность и операционная зрелость как основа масштабирования

Сквозной поток стабильности делает масштабирование контролируемым: инциденты, сверки, disputes, поддержка и audit evidence становятся частью продукта и процессов.

В блоке 3 поток стабильности не является вспомогательной функцией. Он является механизмом, который позволяет одновременно развивать продукт и сохранять доверие к Ядру. Поэтому он включает в себя непрерывный контур управления инцидентами, мониторинг по операциям и провайдерам, финансовые сверки и обработку расхождений, процессы disputes и complaints с доказательностью, поддержку как часть продукта с действиями в чате и AI-ко-пилотом, а также регулярные меры безопасности и готовность к аудитам через корректный сбор evidence.

Tip

Чем раньше мы превращаем эксплуатацию в систему - статусы, досье операции, документы, действия в поддержке, автоматизацию - тем дешевле становится запуск каждого следующего модуля и каждого следующего региона.

Гейты и контрольные точки

Гейты превращают план в управляемую программу: мы расширяем когорты и выпускаем модули только когда подтверждены стабильность, корректность денег и готовность ops.

Гейты в блоке 3 нужны не для формальности. Они нужны, чтобы любые расширения происходили только после подтверждения качества в проде. В конце Фазы 2 мы фиксируем, что ЕС прошел go-live и миграции и формально закрыл partner exit, а ОАЭ подтвердил стабильный партнерский режим. Дополнительно подтверждается готовность платформы модулей - feature flags, региональные переключатели и инструменты staged rollout. В Фазе 3 отдельно фиксируются получение лицензии Core в ОАЭ, ограниченный go-live собственного Core, завершение перехода partner - own по Core, запуск минимального набора no-license модулей в ОАЭ и выпуск полного набора модулей в ЕС.

Warning

Если любой из гейтов не подтвержден, мы не расширяем когорты и не ускоряем релизы. Мы устраняем причину, потому что иначе блок 3 превращается в накопление операционного долга, который разрушает экономику масштаба.

Итог блока 3

Блок 3 завершает переход к устойчивому масштабу: ЕС становится fully own-licensed и feature-complete (кроме RWA), ОАЭ получает own-license на Core и безопасный набор no-license модулей, а операционная система становится зрелой для следующего расширения.

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

К концу блока 3 в ЕС DARCA работает на собственных лицензиях и имеет полный функциональный периметр по модулям, кроме RWA, который вынесен в следующий блок. В ОАЭ DARCA работает на собственных лицензиях по Ядру, завершает переход от партнеров на свою операционку по Core и запускает только те модули, которые не расширяют лицензируемый периметр. Одновременно организация закрепляет зрелую операционную основу - сверки, disputes, поддержку с действиями, автоматизацию и audit evidence - так, чтобы дальнейшее расширение географий и запуск блока 4 не требовали перестраивать фундамент.

Блок 4 – Фаза 4 (24 месяца): полный запуск в ОАЭ, запуск в США на собственных лицензиях, фабрика RWA, готовность к глобальной экспансии

Info

Блок 4 превращает DARCA из сильного продукта в ЕС и Core в ОАЭ в международную платформу: ОАЭ получает лицензии под модули и полный портфель, США запускаются сразу на собственных лицензиях, RWA оформляется как производственная программа, а запуск по миру через партнеров становится масштабируемым процессом.

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

Цели и конечное состояние Блока 4

Фиксируем измеримые результаты: что именно должно быть готово через 24 месяца и почему это требует отдельной фазы.

Note

В Блоке 4 мы не “добавляем страны”, а строим мультиюрисдикционную операционную систему: лицензии, процессы, доказательная база, релизная дисциплина, и только потом масштабирование.

К концу Блока 4 мы фиксируем четыре результата, которые должны наступить одновременно.

Во-первых, ОАЭ переходят от режима “Core на своей лицензии + ограниченный набор модулей” к режиму “Core + весь портфель модулей”. Это означает, что лицензии в ОАЭ расширяют периметр не только на транзакционное ядро, но и на функциональность модулей, после чего мы запускаем модули волнами, с обязательной стабилизацией после каждой волны, и доводим качество эксплуатации до уровня ЕС: reconciliation, disputes, reporting, audit evidence, поддержка с действиями в чате.

Во-вторых, США запускаются сразу на своих лицензиях, без партнерской модели запуска. Мы закладываем реалистичный ориентир: получение ключевого лицензионного периметра занимает около 12 месяцев. Поэтому Блок 4 строится так, чтобы к моменту получения лицензий система и операционка были “launch-ready”, и запуск в США стал включением заранее подготовленного контура, а не стартом разработки.

В-третьих, запускается программа RWA как отдельная “фабрика”, а не как одиночный модуль. Здесь ключевое - не UI и не смарт-контракт, а цепочка документов, партнеров, траншей, доказательств и отчетности. RWA в Блоке 4 запускается “там где возможно”: через геофенсинг, ограничения по юрисдикциям и типам активов, и строгую связку с комплаенсом.

В-четвертых, мы заканчиваем Блок 4 готовностью к масштабной экспансии по миру через партнеров. Важно: эта экспансия относится к регионам за пределами США, потому что США в этой стратегии - own-only. К финалу фазы у нас должна быть “фабрика запусков”: шаблоны интеграций, стандарты SLA, мониторинг, плейбуки инцидентов и поддержки, требования к партнерам и exit plan.

Архитектура работ Блока 4 - программы и ответственность

Фаза 4 ведется не как один список задач, а как набор параллельных программ, каждая со своими гейтами и критическими рисками.

Tip

Чтобы Блок 4 не превратился в перегруженный roadmap, мы фиксируем 6 программ: S4, O4, U4, R4, P4, G4.

Блок 4 мы описываем как шесть программ, потому что так проще держать контроль над зависимостями и не смешивать лицензирование, продукт и операционные изменения.

  • S4 - Stability and Security Updates - непрерывная программа на 24 месяца. Она включает обновления безопасности, исправления дефектов, миграции провайдеров, failover drills, улучшение мониторинга, снижение cost-to-serve, и обязательные стабилизационные окна после крупных релизов.
  • O4 - UAE Full Licensing + Modules Rollout - лицензии ОАЭ под модули и запуск полного портфеля модулей в ОАЭ волнами.
  • U4 - US Own Licensing + US Own Launch - лицензирование США (ориентир 12 месяцев) как критический путь и staged launch после получения лицензий.
  • R4 - RWA Factory Program - отдельная производственная линия: документы, партнеры, процессы, Object Vault, отчетность и контроль рисков.
  • P4 - Global Partner Expansion Factory - фабрика запусков по миру через партнеров, кроме США.
  • G4 - Governance and Compliance Platform - слой управления многорегиональностью: policy engine, compliance adapters, entitlements, релизная дисциплина.

Для терминов, которые важны инвестору и регулятору, мы используем короткие ссылки: Compliance, Governance, OFAC, Money_laundering, Real-world_asset.

Очередность работ на 24 месяца

Показываем, что происходит сначала, что параллельно, а что возможно только после лицензий и стабилизации.

Warning

В Блоке 4 США - critical path. Поэтому мы начинаем U4 в первый месяц и не обещаем прод-запуск до получения лицензии, но делаем систему launch-ready заранее, чтобы не терять время после разрешения.

Мы делим 24 месяца на три смысловых подпериода. Это не “ступеньки”, а способ объяснить зависимости.

Подпериод A - M1-M8: запускаем длинные цепочки и собираем фундамент

В начале фазы мы запускаем то, что невозможно “ускорить разработкой”: лицензирование и партнерские фабрики. Одновременно мы усиливаем качество системы в ЕС и ОАЭ, потому что в фазе экспансии качество не может оставаться “как есть”.

В U4 (США) мы стартуем с определения полного лицензионного и операционного периметра под “все модули”. Мы фиксируем структуру компании, роли, процедуры, и готовим доказательную базу: policies, IT-security evidence, процессы BSA/AML, OFAC, SAR/CTR, recordkeeping и аудит. На этом этапе мы не “ждем лицензии”, а строим “лицензируемую организацию и систему”. К концу подпериода пакет подан, а команда работает в режиме “регуляторного проекта”.

В O4 (ОАЭ) мы параллельно запускаем лицензирование под модули. Ключевой принцип: мы не пытаемся включить весь портфель сразу, а описываем волны включения и заранее готовим operating model и отчетность, чтобы при получении лицензий запуск модулей не упирался в “не готово внутри”.

В R4 (RWA) мы проектируем фабрику: юридический пакет, disclosure, партнерскую цепочку (originators, SPV/escrow, оценка, страхование, аудит, сервисинг), и контур доказательств через Object Vault. Мы фиксируем, что токенизация в нашей модели дает право на денежные потоки и прозрачные условия выкупа, а не право собственности, и внедряем это как стандарт документации и UX.

В S4 и G4 мы формируем основу многорегиональности. Это включает policy engine (allow, step-up, hold, deny), compliance adapters для разных периметров, права доступа к модулям (entitlements), релизную дисциплину (go/no-go, rollback drills, kill switches). Эти вещи нужны не только для США и ОАЭ, но и для того, чтобы ЕС продолжал обновляться без деградации качества.

Гейт подпериода A означает: США в лицензировании не “планируется”, а идет, ОАЭ лицензирование под модули запущено, RWA фабрика оформлена на уровне документов и партнерских цепочек, а S4/G4 дают управляемую основу релизов и ограничений.

Подпериод B - M9-M16: исполняем, запускаем первые расширения, США становится launch-ready pending license

Во втором подпериоде происходит основная работа по исполнению и подготовке запусков. Здесь важно одновременно двигать ОАЭ и RWA и не терять темп США.

В U4 (США) мы проходим активную фазу вопросов, замечаний и remediation. Мы доводим процессы комплаенса до уровня производства: очереди кейсов, SLA, доказательная база, регулярные отчеты. Параллельно мы проводим rehearsals: incident drills, reporting drills, reconciliation drills. Это означает, что когда лицензия получена, запуск не начинается “с нуля”, а включается на подготовленной системе.

В O4 (ОАЭ) мы начинаем включать модули волнами по мере получения лицензий. Каждая волна включает не только релиз, но и стабилизационное окно: устранение дефектов, настройку мониторинга, доведение поддержки до стабильной скорости решения кейсов и снижение ошибок в операционных процессах.

В R4 (RWA) мы запускаем пилоты “там где возможно”. Это означает, что мы выбираем конкретные юрисдикции и типы активов, где разрешения, партнеры и комплаенс позволяют выполнить запуск без компромисса. Пилот включает Object Vault, отчетность по денежным потокам, правила milestones и траншей, и заранее зафиксированные сценарии инцидентов и дефолтов.

В P4 (Global) мы тестируем фабрику запусков на 1-2 пилотных регионах через партнеров (кроме США). Цель - не масштаб выручки, а подтверждение: мы можем запускать регионы повторяемо, быстро и контролируемо, не создавая ручной проект на 6-9 месяцев.

В S4 продолжается поток обновлений и исправлений в ЕС и ОАЭ: безопасность, надежность, провайдерные изменения, оптимизация процессов поддержки. Этот поток намеренно не “останавливается”, потому что по мере расширения в США и в ОАЭ реальный production неизбежно генерирует баги и новые требования.

Гейт подпериода B означает: ОАЭ продвинулся в запуске модулей и удерживает стабильность, RWA пилот подтвержден end-to-end, фабрика глобальных запусков доказана пилотами, а США технически и операционно готовы к запуску в момент получения лицензии.

Подпериод C - M17-M24: финализация - США запускается, ОАЭ получает полный портфель, RWA масштабируется, глобальная экспансия готова

Третий подпериод включает самые рискованные события фазы, поэтому план намеренно содержит стабилизационные окна и строгую релизную дисциплину.

В U4 (США) ключевое событие - получение лицензий (ориентир около 12 месяцев от старта лицензирования). После этого мы делаем limited cohorts go-live, staged ramp и включение модулей волнами до полной конфигурации. Каждая волна сопровождается стабилизацией, расширением мониторинга и подтверждением готовности комплаенс-операций.

В O4 (ОАЭ) мы завершаем лицензирование под модули и включаем оставшиеся элементы портфеля. Здесь важно, что запуск “последних модулей” всегда сложнее первых: больше требований, больше рисков, больше нагрузки на поддержку и operations. Поэтому волны и гейты обязательны, а финальный результат - full scope ОАЭ с доказуемым качеством эксплуатации.

В R4 (RWA) мы расширяем партнерства и пайплайн объектов и закрепляем фабрику как повторяемый процесс. RWA масштабируется не за счет маркетинга, а за счет стандартизации документов, верифицируемой отчетности по денежным потокам, прозрачных правил buyback и сценариев стресс-событий, и строгого геофенсинга.

В P4 (Global) мы завершаем сборку “launch kit v2”. Это набор повторяемых компонентов: интеграционные шаблоны, SLA и мониторинг, процедуры инцидентов, поддержка с действиями, шаблоны документов и политик, контур оценки риска партнера, и план выхода при ухудшении качества партнера. К финалу подпериода мы готовы к параллельным запускам в нескольких регионах через партнеров.

В S4 третий подпериод включает обязательные окна для устранения дефектов и обновлений безопасности. Мы заранее принимаем, что после запуска США и расширения ОАЭ баги и инциденты неизбежны, и рассматриваем их как часть производственного контура, а не как отклонение от плана.

Где и как запускаются модули в Блоке 4

Показываем прозрачную картину: ЕС обновляется, ОАЭ расширяется волнами после лицензий, США включается после получения собственных лицензий, RWA развивается как отдельная программа.

Example

Логика включения модулей в новых регионах основана на риске и лицензировании: сначала no-license и low-risk, затем high-risk user infra, затем regulated-sensitive, и только после подтверждения операционной зрелости.

  • ЕС - портфель модулей уже работает, в Блоке 4 идет непрерывное улучшение: безопасность, надежность, оптимизация UX, снижение cost-to-serve, повышение прозрачности документов и статусов.
  • ОАЭ - портфель модулей включается волнами после получения лицензий. Внутри волн приоритет получают модули, которые дают большую ценность пользователю и требуют минимального расширения лицензируемого периметра, затем подключаются модули повышенного риска и модули, требующие наиболее строгого регуляторного режима.
  • США - запуск модулей начинается только после получения собственных лицензий и стартует staged rollout: сначала limited cohorts, затем рост, затем полное включение портфеля по волнам.
  • RWA - развивается как отдельная программа и может включаться асимметрично по регионам: в одних юрисдикциях раньше, в других позже, в зависимости от правового режима и партнеров.

Управление рисками и контроль качества

Блок 4 включает высокие регуляторные и операционные риски, поэтому мы заранее показываем, как контролируем сроки, качество и доверие.

Danger

Главный риск Блока 4 - не скорость разработки, а разрыв между лицензиями, операционкой и качество продакшена. Поэтому S4 и G4 являются обязательными программами, а не опциями.

Мы закладываем четыре контура контроля.

Первый - контроль лицензирования США: старт с первого месяца, готовность системы и операционки “pending license”, ясные гейты, и отсутствие обещаний прод-запуска до получения разрешений. Это позволяет не терять 6-9 месяцев после лицензии на “внезапную подготовку”.

Второй - контроль деградации качества: S4 идет все 24 месяца и включает стабилизационные окна после каждого крупного запуска, циклы безопасности и обязательные drills. Мы заранее фиксируем capacity на исправление дефектов, потому что в реальном банкинге баги после go-live неизбежны.

Третий - контроль RWA: RWA идет как factory program с документами, партнерами и ограничениями. Пилотирование и геофенсинг заменяют “универсальный запуск”, и каждый шаг подтверждается доказательными артефактами и отчетностью.

Четвертый - контроль партнерских рисков для глобальной экспансии: due diligence, SLA, мониторинг, и exit plan. Партнерская модель должна быть управляемой, иначе она разрушает доверие и производственную устойчивость.

Что меняется после Блока 4

К финалу фазы DARCA готова не к единичным запускам, а к повторяемому масштабированию - с лицензиями, фабриками процессов и контролем качества.

Question

После Блока 4 DARCA становится платформой, которая умеет масштабироваться без потери целостности: что именно позволяет запускать новые регионы быстрее и безопаснее, чем в первых фазах?

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

К завершению Блока 4 DARCA выходит на уровень, где рост определяется не количеством ручной работы, а повторяемыми механизмами. В ОАЭ работает полный портфель модулей на лицензируемом периметре. В США продукт запущен на собственных лицензиях и развивается по волнам, с сохранением комплаенс и операционной дисциплины. RWA работает как фабрика с документами, партнерской цепочкой и доказательной прозрачностью. А глобальная экспансия через партнеров становится масштабируемой процедурой, где каждый новый регион подключается через стандартизированный launch kit, а качество поддерживается S4 и G4 как постоянными производственными программами.

Финишная рамка: управляемый рост без потери качества

Этот роудмап фиксирует не список фич, а операционную программу превращения DARCA в масштабируемую платформу - через контроль качества денег, управляемые переходы по регионам и заранее спроектированную модульность.

Info

Ценность плана в том, что он переводит развитие DARCA из режима “ускоряемся и надеемся” в режим контролируемого исполнения с понятными гейтами и критериями допуска.

Этот документ описывает последовательность работ, где качество и корректность финансовых операций являются ограничителем скорости, а не побочным эффектом. Логика построена вокруг простого принципа: расширение функционала и географии допустимо только после подтверждения стабильности в проде, корректности данных и готовности операций, поддержки и комплаенса.

В Блоке 1 зафиксировано создание полного ядра как единого контура фиат+крипто - с операционными статусами, досье операции и документами как обязательной частью продукта, а не как “позже добавим”. Результатом является production-ready Core, где интеграции, дизайн, коммуникации, процессы поддержки и качество (QA, нагрузка, безопасность) входят в объем работ наравне с кодом.

В Блоке 2 задана правильная реальность пост-запуска: ошибки, инциденты и хвосты интеграций неизбежны, поэтому они оформлены как отдельная программа стабилизации. Параллельно формируется готовность к выходу из партнерской зависимости и запускается ОАЭ через партнеров - без разрушения качества основного продукта. Это снижает риск того, что масштабирование станет накоплением неконтролируемого операционного долга.

Блок 3 объединяет выполнение Phase 2 и Phase 3 в одну траекторию: переход ЕС на собственные лицензии и уход от партнеров, параллельная работа в ОАЭ через партнеров с последующим переводом ядра на собственную лицензию. Модули выводятся волнами, при этом периметр ОАЭ в конце Phase 3 ограничен теми модулями, которые не требуют лицензирования, а RWA сознательно вынесен в следующий блок, чтобы не размывать критический путь.

Блок 4 завершает превращение DARCA в международную платформу: полный модульный периметр в ОАЭ на соответствующих лицензиях, запуск США сразу на own-license модели, запуск программы RWA factory как отдельной сложной производственной линии (документы, партнерства, операционные доказательства и риск-контуры), и подготовка к глобальной экспансии через партнеров по повторяемому “launch kit” подходу.

Warning

Масштабирование без гейтов и критериев допуска почти всегда приводит к росту “скрытого долга”: больше стран, модулей и интеграций - но меньше предсказуемости денег, статусов, документов и поддержки.

Ключевой результат этого плана - заранее встроенная управляемость:

  • Gates и “definition of done” привязывают релизы к измеримым условиям качества, а не к календарю
  • модульность Core+Modules позволяет наращивать продукт без распада UX и без переписывания ядра
  • зависимость от партнеров рассматривается как стадия, а не как постоянное состояние - с заранее описанным переходом и обратимостью
  • безопасность, риск и комплаенс встроены в дорожную карту как сквозной производственный контур

Tip

План остается гибким по тактике (какие именно провайдеры и в каких странах первыми), но жестким по методологии - рост допускается только при сохранении предсказуемости операций и корректности данных.

Backlinks