Лучший мобильный банкинг

Info

В этом файле мы описываем как именно мы решаем проблемы «слабый мобильный банкинг и устаревшие ИТ-системы»: архитектуру Core+Modules, модульную модель продукта, технологический стек, подход к real-time, безопасность, наблюдаемость и масштабирование.

1. Ключевые тезисы
2. Суть проблемы
3. Подход DARCA: платформенное ядро + подключаемые модули
4. Архитектура платформы (высокий уровень)
5. Core (общее ядро): что в нём и почему именно это
6. Modules (подключаемые расширения): что это такое “по-настоящему”
7. Механика “реального времени”: event-driven вместо batch
8. Durable workflows: как мы делаем “несрываемые” процессы
9. API-first и контрактность
10. Security-by-design (многоуровневая безопасность)
11. Reliability & Observability (стабильность как стандарт)
12. Технологический стек
13. UI/UX и команда
14. Итог: как это закрывает проблемы исследования

1. Ключевые тезисы

Основные концепции платформы: единое транзакционное ядро, подключаемые модули, real-time подход и встроенная безопасность.

Мы строим банковскую платформу нового поколения и решаем ограничения legacy-ИТ не «косметическими улучшениями», а архитектурой. В основе - единое транзакционное ядро (Core), которое отвечает за неизменяемые свойства системы (учёт, безопасность, доступ, аудит), и подключаемые функциональные модули (Modules), которые расширяют продукт без разрушения ядра.

Мы проектируем платформу как real-time систему: статусы операций, критичные сценарии и синхронизация каналов строятся на потоковой модели (events/workflows), а не на пакетных «окнах» обработки. Это позволяет сделать мобильный банкинг быстрым и предсказуемым: пользователь видит понятный статус, причину и следующий шаг, а не «ожидайте обработки».

Мы заранее закладываем, что функционала будет много, но он нужен разным пользователям по-разному. Поэтому наша продуктовая модель - модульная: пользователь или компания подключают только те модули, которые им действительно нужны (например, P2P, Earn/стейкинг, бизнес-лимиты и согласования, отчётность и интеграции). В результате приложение не превращается в перегруженный комбайн, а платформа может расти по функциям и рынкам без экспоненциального роста сложности интерфейса.

Мы строим систему так, чтобы быстро добавлять новое безопасно. Это достигается контрактностью (API-first + событийные контракты), управляемыми политиками доступа и изоляцией модулей по правам, метрикам и отказам. Безопасность и комплаенс встроены в основу: риск-движок (allow/step-up/hold/deny), неизменяемый аудит критичных действий, протокольные защиты от дублей и повторов, централизуемые правила лимитов и доступов.

2. Суть проблемы

Анализ того, почему мобильный банкинг слаб: проблемы UX, отсутствие real-time, нестабильность и архитектурные ограничения legacy-систем.

2.1. Что ломает мобильный банкинг

Warning

Мы видим, что “слабый мобильный банкинг” почти всегда состоит из нескольких одинаковых компонентов:

Плохой UX и перегруженность

Приложение пытается быть “всем для всех”: много лишних экранов, непоследовательная логика, слишком много шагов в базовых сценариях (перевод, обмен, управление лимитами). В результате пользователь тратит усилия на навигацию, а не на управление деньгами.
Отсутствие ощущения real-time

Пользователь не получает понятного статуса “что происходит прямо сейчас”: операции обновляются с задержкой, история подтягивается “волнами”, уведомления приходят поздно. Это воспринимается как нестабильность, даже если операция в итоге прошла.
Слабая производительность и нестабильность клиента

Лаги интерфейса, долгие загрузки, ошибки в критичных местах (логин, подтверждения, статусы операций) напрямую бьют по доверию. В исследовании отдельно подчеркивается, что слабые интерфейсы, ограниченный функционал и низкая производительность остаются типовой проблемой банковских приложений.
Функциональные разрывы между B2C и B2B

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

2.2. Что ломает IT

Danger

Проблема мобильного банкинга почти всегда является следствием того, как устроена IT-база банка.

Legacy core и монолитность - устаревшие core-системы сложно развивать: любое изменение затрагивает слишком много компонентов, тестирование дорогое, а риск регрессий высокий. В исследовании отдельно отмечено, что в банках до сих пор встречаются legacy-языки (например, COBOL) и наследуемые платформы, которые повышают хрупкость и усложняют развитие.
Batch processing вместо потоковой модели - многие процессы выполняются пакетно: обновления балансов, расчёты, сверки, статусы. Из-за этого пользовательский интерфейс часто отображает “не то, что сейчас”, а “то, что обновилось последним пакетом”. В исследовании прямо описывается зависимость legacy-банков от batch processing.
Разрозненные данные и слабая интеграционная модель - информация распылена по системам, нет единого источника истины и стандартного контрактного взаимодействия. В итоге внедрение новых функций (AI-персонализация, open banking/API, новые платежные сценарии) тормозится не “желанием”, а архитектурными ограничениями.
Высокая операционная стоимость изменений - большая часть ресурсов уходит на “поддерживать, чтобы не упало”, а не на развитие продукта - это типовая картина legacy-IT.
Повышенные риски отказов и безопасности - когда система сложная, связная, с накопленным техническим долгом, она хуже выдерживает нагрузку, хуже наблюдается и сложнее обновляется с точки зрения безопасности.

2.3. Почему “просто переписать core” не подходит

Мы считаем неправильным путь “переписать всё целиком”, потому что на практике это:

длительный проект с высокой стоимостью
повышенный риск нестабильности в процессе перехода
параллельное замедление продуктового развития (всё внимание уходит в migration)

Tip

Поэтому мы выбираем платформенную стратегию:

Строим устойчивое Core-ядро с неизменяемыми инвариантами (учёт, безопасность, доступ, аудит, маршрутизация операций), а рост функционала и быстрые эксперименты реализуем через подключаемые модули, которые можно выпускать и обновлять независимо, без разрушения ядра.

3. Подход DARCA: платформенное ядро + подключаемые модули

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

3.1. Основной принцип: Core + Modules

Info

Мы строим платформу по принципу “одно общее ядро + подключаемые модули”.

Два ключевых компонента:

Core (ядро) - это стабильная основа, которая обеспечивает неизменяемые свойства системы: корректный учёт активов, безопасность, контроль доступа, аудит, базовые платежные сценарии, единые статусы и телеметрию.
Modules (модули) - это расширения, которые добавляют новые продуктовые возможности и вертикали (P2P, Earn/стейкинг, RWA, бизнес-функции и т.д.) без того, чтобы “раскачивать” и усложнять ядро.

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

3.2. Зачем модульность продукту

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

Модульность даёт продукту:

Чистый и быстрый интерфейс - базовое приложение остаётся лёгким: кошелёк, балансы, переводы, история, безопасность, уведомления. Всё остальное подключается по необходимости.
Персонализация и рост без перегруза - набор модулей фактически становится “профилем продукта” для пользователя: физлицо подключает одно, бизнес - другое. UI расширяется ровно там, где это нужно.
Понятная монетизация - часть модулей может быть платной (подписка/тариф/комиссия), а базовый функционал - бесплатным или с минимальными затратами. Это удобно и для пользователя, и для бизнеса.

3.3. Зачем модульность разработке и операционной устойчивости

Модульность - это не только “про интерфейс”. Это способ сделать систему управляемой и устойчивой.

Независимые релизы - мы можем выпускать и обновлять модуль без необходимости трогать ядро и без глобального регресса по всей системе.
Изоляция рисков - если модуль деградирует (ошибка, нагрузка, нестабильность), ядро продолжает работать. Модуль можно отключить когорте пользователей или откатить версию, не ломая базовые операции.
Масштабирование команд и скорости - разные команды могут развивать разные модули параллельно, не блокируя друг друга и не создавая “очередь релизов”.
Быстрая интеграция новых технологий - новые технологии и направления (новые платежные рельсы, новые сети, новые AI-модели) проще добавлять как модуль или как изолированный компонент, чем переписывать core.

3.4. Future-proofing: мы учитываем, что технологии меняются быстро

Question

Как построить систему, которая сможет эволюционировать без накопления технического долга?

Мы исходим из реальности: технологии, платежные рельсы, требования комплаенса и пользовательские ожидания меняются быстро. Поэтому мы строим систему так, чтобы:

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

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

4. Архитектура платформы (высокий уровень)

Слои архитектуры: Experience Layer, Core Platform Layer, Modules Layer и Integration Layer, каждый с чёткой ролью и независимым развитием.

4.1. Слои архитектуры

Note

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

4.1.1. Experience Layer (клиентские приложения и интерфейсы)

Слой, который отвечает за пользовательский опыт и быстрые сценарии.

Mobile (iOS/Android) - основной продукт для B2C и часть сценариев B2B
Web / Business console - корпоративные сценарии: роли, лимиты, согласования, отчётность
Backoffice / Support tools - инструменты оператора, комплаенса и поддержки
Partner / Developer portals - документация и управление API/ключами (для интеграций)

Цель слоя: быстрый, понятный UX и единые паттерны работы со статусами операций, ошибками и безопасностью.

4.1.2. Core Platform Layer (платформенное ядро)

Слой неизменяемых инвариантов: то, что должно быть надёжным и одинаковым для всех модулей и всех пользователей.

Identity & Access (DARCA ID) - сессии, устройства, MFA/passkeys, роли
Ledger & Wallet Core - учёт активов и балансов, неизменяемая история
Payments Orchestrator - единая маршрутизация операций и статусов
Risk & Compliance Core - риск-решения, лимиты, политики, аудит
Notifications Core - уведомления и системные события
Observability & Audit Core - метрики, трассировка, логирование, аудит-трейл
Module Registry & Entitlements - включение/отключение модулей, версии, права, тарифы

Цель слоя: обеспечить, чтобы любой модуль работал “на стабильной платформе”, а не строил свой мини-банк внутри банка.

4.1.3. Modules Layer (подключаемые модули)

Слой продуктовых вертикалей, который быстро растёт и расширяется.

Модули для частных пользователей (P2P, Earn/стейкинг, инвестиционные сценарии)
Модули для бизнеса (ролевая модель, approvals, массовые выплаты, отчётность)
Модули по активам/сетям/рынкам (новые рельсы, новые сети, новые партнёры)

Цель слоя: быстро добавлять функциональность без риска для ядра, выпускать независимые релизы и масштабировать команды.

4.1.4. Integrations Layer (внешние системы и рельсы)

Слой интеграций, который подключает платформу к внешнему миру и партнёрам.

Fiat rails / partner banking - платёжные провайдеры, банки-партнёры, PSP
Blockchain gateways / nodes - подключение сетей, подтверждения, мониторинг
KYC/AML providers - проверки, санкционные списки, риск-сигналы
Enterprise integrations - ERP/CRM/бухгалтерия, платежные файлы, webhooks

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

4.1.5. Infrastructure Layer (надёжность, безопасность, масштабирование)

Слой, который обеспечивает отказоустойчивость и управляемость.

контейнеризация и оркестрация, автоскейлинг
наблюдаемость (метрики/трейсы/логи), алерты и SLO
хранение ключей/секретов, сетевые политики, mTLS
резервирование, бэкапы, DR-процедуры

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

4.2. Потоки данных и событий (как всё “дышит”)

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

Канал	Использование	Примеры
API-контракты (synchronous)	Где нужен немедленный ответ	логин, запрос баланса, создание операции, запрос статуса
События (asynchronous)	Где важны real-time обновления и слабая связность	изменение статуса операции, риск-решение, уведомления, аналитика, реакции модулей

Паттерн работы:

действие пользователя или системы создаёт команду (API вызов)
ядро/модуль фиксирует состояние в своих доменах
затем публикуется событие, которое получают другие сервисы и модули
клиент видит изменения через подписки/пуши/обновления статусов

Это даёт real-time ощущение и позволяет добавлять новые модули, которые просто подписываются на нужные события, не меняя ядро.

4.3. Контур real-time (что мы делаем принципиально иначе, чем legacy)

Example

В legacy-системах “всё сходится” в конце операционного дня или в пакетных окнах. Мы строим иначе:

Real-time статусы операций - статус меняется по событиям и виден пользователю сразу
Единая модель статусов - одинаковые статусы и объяснения в мобильном, вебе и поддержке
Событийная синхронизация каналов - нет рассинхронизации “мобильное показывает одно, оператор - другое”
Поток для аналитики и antifraud - антифрод/скоринг питается событиями, а не выгрузками

Это фундамент для сильного мобильного банкинга: UX становится быстрым не потому что “подкрутили интерфейс”, а потому что вся платформа работает в real-time логике.

5. Core (общее ядро): что в нём и почему именно это

Компоненты Core: Identity, Ledger, Payments, Risk, Notifications, Observability и Module Registry - каждый критичен для стабильности платформы.

5.1. Identity & Access (DARCA ID)

Это фундамент безопасности и управляемости. Мы не “добавляем безопасность потом”, мы строим её как базовый слой платформы.

Что входит:

DARCA ID - профиль пользователя/компании, статусы, уровни KYC, сегменты
Сессии и устройства - привязка устройств, контроль новых устройств, доверенные устройства
Подтверждения - MFA/2FA, биометрия, passkeys (где применимо), step-up
Роли и доступы - RBAC/ABAC, особенно важно для B2B (роли, полномочия, лимиты)
Аудит действий - кто/что/когда сделал (критично для комплаенса и расследований)

Почему это в Core: любой модуль должен опираться на единую модель доступа, подтверждений и рисков. Иначе платформа распадается на несогласованные мини-продукты.

5.2. Ledger & Wallet Core

Это “сердце” платформы: единая модель активов, балансов и истории. Без строгого учёта сильный мобильный банк невозможен.

Инварианты:

единая модель счетов/кошельков для разных валют и активов
строгая транзакционность: операция либо проводится полностью, либо не проводится
неизменяемая история операций как источник истины
идемпотентность на уровне операций (защита от повторного списания)

Почему это в Core: учёт и корректность балансов - базовый инвариант. Модули добавляют сценарии, но не меняют правила учета.

5.3. Payments Orchestrator + Internal Transfers

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

Что включает:

маршрутизация операций и единая state machine статусов
ретраи без дублей, идемпотентность, защита от повторов
единая модель комиссий/лимитов/правил на маршруте
внутренние мгновенные переводы без комиссий, в том числе по номеру телефона/контактам

Почему это в Core: платформа должна обеспечивать одинаковый “сквозной” контур операций и статусов для любых модулей. Иначе каждая функция будет “платежами по-своему”.

5.4. Risk & Compliance Core

Слой решений “можно / нужно подтвердить / удержать / нельзя” в реальном времени.

Что входит:

risk decisioning: allow / step-up / hold / deny
лимиты по операциям/контрагентам/странам/устройствам/ролям
комплаенс-контур (KYC/AML, санкционные проверки через провайдеров)
аудит “почему принято решение” (traceability)

Почему это в Core: риск и комплаенс - обязательная несущая конструкция платформы, а не функция “по желанию”.

5.5. Notifications & Messaging Core

Уведомления - часть UX и часть безопасности. Мы делаем это платформенным сервисом.

Что входит:

push/email/sms/мессенджеры/in-app
событийные триггеры (статусы операций, входы, смены устройства)
пользовательские настройки уведомлений и шаблоны

Почему это в Core: единая система уведомлений гарантирует одинаковую предсказуемость по всем модулям и каналам.

5.6. Observability & Audit Core

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

Что входит:

метрики/логи/трейсы end-to-end
SLO и алерты по критичным операциям и сервисам
неизменяемый audit-trail по критичным действиям и решениям

Почему это в Core: без наблюдаемости и аудита любая сложная система со временем превращается в “хаос ошибок”.

5.7. Module Registry & Entitlements

Это механизм, который превращает модульность в управляемую систему.

Что входит:

каталог модулей (id, версии, зависимости, совместимость)
eligibility (страна, KYC-уровень, риск-профиль, тариф)
entitlements (какие права выдаём при подключении и забираем при отключении)
rollout control (когорты, feature flags, мгновенное отключение/откат)

Почему это в Core: без реестра и entitlements “модульная платформа” не существует - останутся просто разрозненные фичи.

5.8. Base App Capabilities (Default Modules) - базовые функции приложения, включённые по умолчанию

Note

Важно разделять платформенное Core и базовые продуктовые функции, которые включены “из коробки”. Эти функции мы фиксируем как default modules: пользователь получает их сразу, но архитектурно они реализованы поверх Core и могут эволюционировать отдельно, не превращая ядро в монолит.

Что включаем по умолчанию (как базовый пакет приложения):

Моментальные транзакции внутри банка (без комиссий)
- мгновенные внутренние переводы
- переводы по номеру телефона/контактам
- моментальные уведомления о статусе
Обмен валют и криптовалют + уведомления о выгодном курсе
- мгновенный обмен внутри приложения
- алерты по курсу/цене
Резервирование средств (цель/срок) - “копилки/цели”
Оплата услуг и автоплатежи
- автооплата счетов
- автопереводы другим пользователям по расписанию
Отчёты и аналитика (включая “monthly wrapper” формат)
- расходы/категории/динамика
- отчёты за период и “упаковка месяца”
Предсказание нехватки средств (cashflow-сигналы и предупреждения)
Настраиваемые шаблоны интерфейса под цели пользователя (персонализация UX)
Хранение документов (Document Vault внутри приложения)
Моментальный чат на любой странице приложения (поддержка/консьерж/ассистент)
- быстрый доступ к техподдержке без выхода со сценария
- единый “точечный” вход в помощь и сопровождение

Почему это здесь (в разделе Core): эти возможности - базовый стандарт мобильного банка, который должен быть доступен большинству пользователей сразу. Но мы фиксируем их как “default modules”, чтобы сохранить ключевую идею: продукт расширяется модульно, а не превращается в монолит.

Всё, что не обязательно всем пользователям (геймификация, сторис, консьерж/AI-чат, рейтинги, карты и т.п.), мы выносим в раздел Modules как подключаемые расширения.

6. Modules (подключаемые расширения): что это такое “по-настоящему”

Модули как самодостаточные продуктовые блоки: финансовые, бизнес-функции, контент, поддержка и карты - каждый с независимыми релизами и изоляцией рисков.

6.1. Принцип: модуль - это продуктовый блок, который расширяет платформу, не ломая Core

Note

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

добавляет новые сценарии и интерфейс (UX/UI)
имеет свою бизнес-логику и сервисы
подключается к Core через контракты (API + события)
получает доступ к данным строго через entitlements и политики
имеет собственные метрики, SLO и возможность быстрого отключения

То есть модуль - это единица масштабирования одновременно:

Аспект	Значение
Продукта	новые вертикали и функции
Разработки	независимые релизы и обновления
Эксплуатации	изоляция деградаций и быстрый откат
Монетизации	тарифы/подписки/комиссии, где уместно

6.2. Категории модулей (как мы группируем расширения)

6.2.1. Financial Modules (финансовые сценарии)

P2P / Exchange - расширенные обменные сценарии, P2P-рынок, OTC-потоки
Earn / Staking - продукты доходности, staking/earn, условия и ограничения
Invest / Portfolio - портфель, цели, стратегии, риск-профиль (если включаем)
RWA / Tokenization - токенизация активов, выпуск/управление, витрина активов

6.2.2. Business Modules (B2B-контур)

Roles & Permissions for Teams - роли, подразделения, доступы
Approvals (Four-Eyes) - согласования платежей и операций
Limits & Policies - лимиты на уровне ролей/команд/контрагентов
Mass Payments / Payroll - массовые выплаты, зарплатные проекты
Invoices / Reconciliation - счета, сверки, выгрузки, отчёты
API / Webhooks - интеграции для бизнеса (ERP/CRM/бухгалтерия)

6.2.3. Engagement & Content Modules (контент и вовлечение)

Warning

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

Gamification - достижения, миссии, обучающие игры, “тамагочи/RPG”-механики
Stories / Feed - сторис и контентные блоки
Rating / Social - рейтинги и социальные механики

6.2.4. Support & Concierge Modules (расширенная поддержка)

Базовый чат мы держим в “default modules”, но расширенные сценарии - это модули:

Concierge - персональное сопровождение, премиальные сценарии
AI Assistant - помощник/нейросеть с контекстом, подсказками и сценариями

6.2.5. Cards & Payments Modules (карты и покупки)

Crypto card / spending - карта и покупки за криптовалюту

Tip

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

6.3. Как модуль подключается пользователем (Module Marketplace → entitlements → UI)

Подключение модуля - это управляемый процесс, а не “показали экран”.

Module Marketplace - пользователь видит описание, условия, ограничения, риски и требования (например, уровень KYC)
Eligibility check - перед включением мы проверяем:
- страна/регион
- уровень KYC/статус аккаунта
- риск-профиль и ограничения
- тариф/подписка (если применимо)
Consent / acceptance - если модуль требует согласий (например, условия продукта доходности), пользователь подтверждает
Entitlements выдаются Core-слоем - модуль получает права: какие API можно использовать, какие лимиты применимы, какие операции доступны
UI раскрывается только для активного модуля - добавляются экраны, маршруты, компоненты - пользователь видит только то, что включил
Событийная подписка - модуль подписывается на необходимые события (статусы, изменения баланса, риск-решения) и работает в real-time

6.4. Как модуль устроен технически (Module Package)

Каждый модуль имеет пакетную структуру и манифест:

module_id, version (SemVer)
required_core_version (совместимость)
permissions (доступ к доменам данных)
entitlements (какие права выдаём)
api_contracts (OpenAPI)
event_contracts (какие события публикует/читает)
policy_bundle (лимиты/правила/доступ)
observability (метрики, SLO, алерты)
kill_switch (мгновенное отключение, если нужно)

Это обеспечивает управляемость и быстрые независимые релизы.

6.5. Изоляция модулей: безопасность, стабильность, быстрый rollback

Чтобы модульность была безопасной и не превращалась в хаос:

Контрактная изоляция - модуль взаимодействует с Core через API и события, а не напрямую с “внутренностями” ядра
Policy-as-code и entitlements - модуль не может получить больше прав, чем разрешено политиками. Лимиты и доступы задаются декларативно
Операционная изоляция - у каждого модуля:
- собственные метрики и SLO
- собственные алерты
- возможность ограничения по когорте пользователей
- быстрый rollback или отключение

6.6. Почему модульность - это ключ к масштабированию продукта и IT

Модульная система решает сразу три класса проблем из исследования:

слабый UX → “показываем только нужное”, интерфейс не перегружается
устаревший монолитный IT-контур → новые функции живут независимо и не ломают core
низкая скорость внедрения инноваций → релизы и эксперименты возможны на уровне модуля, без остановки платформы

7. Механика “реального времени”: event-driven вместо batch

События как нервная система платформы: мгновенные статусы, полная трассируемость и согласованность всех каналов в реальном времени.

7.1. Событийная модель (events как “нервная система” платформы)

Мы строим платформу так, чтобы любое значимое действие фиксировалось не только как запись в базе, но и как событие, на которое могут реагировать другие компоненты и модули. Это основа real-time поведения и согласованности каналов.

Базовые категории событий:

Account & Identity events - вход/выход, новое устройство, смена настроек безопасности, изменение статуса KYC
Ledger events - изменение баланса, проводка, резервирование, списание/зачисление
Payment lifecycle events - операция создана → принята → проверка риска → отправлена → подтверждена → завершена/отклонена
Risk & compliance events - risk decision (allow/step-up/hold/deny), срабатывание правила, изменение лимита
Notification events - событие, которое должно отразиться в уведомлении/центре событий
Module events - события модулей (staking, P2P, RWA, B2B approvals и т.д.) поверх платформенных

Info

Почему это важно: в legacy-системах статус “живёт” внутри отдельных подсистем и обновляется пакетно. У нас статус - это последовательность событий, одинаково доступная мобильному приложению, вебу, поддержке и бэк-офису.

7.2. Зачем это mobile UX (реальный эффект для пользователя)

Event-driven модель напрямую превращается в сильный мобильный банкинг:

Мгновенные статусы операций - пользователь видит, что происходит: “создано → проверка → отправлено → подтверждено”. Это снимает тревожность и снижает нагрузку на поддержку
Понятная причина и следующий шаг - если операция удержана или требует подтверждения, событие несёт причину/класс причины (например, “нужно step-up подтверждение”) и UI показывает конкретное действие
Единая история и отсутствие рассинхронизации - история операций - одна и та же во всех каналах, потому что построена на одной событийной последовательности. Не возникает “в приложении одно, у оператора другое”
Реактивные уведомления - уведомления и центр событий становятся продолжением статусов: пользователь получает уведомление не “когда смогли”, а когда произошло событие

7.3. Зачем это business и compliance (прозрачность и управляемость)

Для бизнеса и комплаенса event-driven архитектура даёт то, что legacy обычно не умеет:

Полная трассируемость - мы можем восстановить цепочку: кто инициировал, какая проверка сработала, какое решение принял risk engine, на каком этапе операция задержалась
Меньше ручных расследований и “операционного админства” - проблемы становятся видимыми сразу: есть события, метрики по каждому этапу, алерты по деградации
Проще строить отчётность и мониторинг - отчёты и аналитика формируются на потоке событий, а не на выгрузках “в конце дня”. Это важно как для финансовой аналитики, так и для риск-мониторинга

7.4. Как это реализовано технически (без “магии”, но понятно)

Example

Чтобы событийная модель работала стабильно, мы закладываем:

единые контракты событий (схемы, версии, совместимость)
гарантированная доставка (at-least-once, с дедупликацией на стороне получателя)
упорядоченность в пределах потока (события одной операции/аккаунта идут в порядке)
версионирование событий (старые версии обрабатываются, новые поля игнорируются)
наблюдаемость потока (метрики задержек, потерь, обработки)

Это не “просто Kafka”, это управляемая событийная система, которая гарантирует согласованность и надёжность.

8. Durable workflows: как мы делаем “несрываемые” процессы

Долгоживущие рабочие процессы, которые выживают при сбоях: платежи, approvals, асинхронные операции с гарантированной доставкой.

Warning

В legacy-системах долгие операции часто “теряются” при сбоях. Мы строим durable workflows - процессы, которые выживают при отказах и гарантируют завершение.

Примеры:

Платежи - от создания до финального статуса, с ретраями и идемпотентностью
Approvals - согласования, которые ждут решения, но не “зависают”
Асинхронные операции - интеграции, которые работают в фоне, но видны пользователю
Риск-проверки - долгие проверки (KYC, AML), которые не блокируют интерфейс

Мы используем state machines + event sourcing, чтобы:

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

9. API-first и контрактность

Формализованные контракты API и событий: синхронные и асинхронные интерфейсы, версионирование, совместимость и партнёрские интеграции.

9.1. Почему API-first - это основа модульности

Info

API-first подход означает, что мы сначала определяем контракты, а потом реализуем. Это даёт:

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

В legacy-системах обычно наоборот: код пишется, а потом “как-то” интегрируется. Результат - хаос и высокая стоимость изменений.

9.2. Два типа контрактов

Мы закрепляем контрактность на двух уровнях:

9.2.1. API Contracts (синхронные)

Используются там, где нужен немедленный ответ:

логин/сессия
запрос баланса
создание операции
запрос статуса
управление модулями и настройками

9.2.2. Event Contracts (асинхронные)

Используются для real-time и слабой связности:

обновления статусов операций
риск-решения
уведомления
события модулей

Tip

Почему это важно: без контрактов событий event-driven архитектура превращается в “зоопарк”, где каждый публикует что хочет. Мы сразу фиксируем схемы, версии и совместимость событий.

9.3. Версионирование API и событий (как мы избегаем “ломающих релизов”)

Мы закладываем управляемую эволюцию:

SemVer-логика
- minor-изменения совместимы назад
- major-изменения - только через новую версию и миграционный период
Стратегия “расширяем, а не ломаем”
- добавляем новые поля, не удаляя старые
- ошибки и статусы имеют стабильные коды
Deprecation policy
- объявление депрекации
- период поддержки
- телеметрия использования старых версий
- плановое отключение только после миграции

9.4. Как это помогает модульности и скорости релизов

Контракты - это основа того, чтобы модули действительно могли быть независимыми:

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

В результате мы получаем то, чего почти нет в legacy:

быстрые релизы
предсказуемые интеграции
меньше регрессий
возможность роста экосистемы партнёров

9.5. Партнёрские интеграции и B2B API (как мы делаем это “правильно”)

Для бизнеса и партнёров мы строим интерфейсы так, чтобы они были:

понятны
безопасны
воспроизводимы

Что важно:

управление ключами/доступами через политики и роли
webhooks и события для real-time интеграции
ограничение прав на уровне entitlements
аудит всех действий интеграции

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

10. Security-by-design (многоуровневая безопасность)

Безопасность встроена в платформу: аутентификация, risk engine, policy-as-code, аудит и комплаенс как базовые инварианты.

10.1. Принцип: безопасность встроена в платформу, а не “прикручена потом”

Мы строим безопасность как набор базовых инвариантов Core. Это означает:

любой модуль работает только в рамках разрешений и политик
критичные операции всегда проходят через единый контур risk/безопасности
все действия и решения имеют трассировку и аудит

Именно так мы избегаем типичной legacy-проблемы, когда безопасность становится “пакетом правил поверх хаоса” и начинает мешать продукту вместо того, чтобы защищать его.

10.2. Аутентификация и доступ: сильная безопасность без трения

Наша цель - высокая безопасность при минимальном трении в UX.

10.2.1. Устройство и сессия как фактор доверия

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

10.2.2. Step-up подтверждения

Мы не заставляем пользователя подтверждать всё одинаково. Мы используем step-up:

обычные действия проходят быстро
подозрительные действия требуют усиленного подтверждения (MFA/passkeys/биометрия)

10.2.3. Passkeys / phishing-resistant подход

Там, где это применимо, мы используем passkeys-подход как устойчивый к фишингу способ аутентификации и подтверждений. Это даёт:

меньше рисков компрометации паролей
быстрее логин
выше доверие к продукту

10.3. Risk Engine: решения allow / step-up / hold / deny

Вместо статического “разрешить/запретить” мы строим risk decisioning, который работает в реальном времени и умеет управлять риском гибко.

10.3.1. Типы решений

allow - пропустить
step-up - требовать усиленное подтверждение
hold - удержать до проверки/доп.условий
deny - отклонить

10.3.2. Что учитываем в сигналах

новый девайс, география, скорость перемещения
поведенческие паттерны
аномалии суммы/частоты
контрагент/рельс/сеть
статус KYC и история

10.3.3. Почему это важно

Такой подход позволяет одновременно:

снижать фрод и потери
не ломать UX массовыми “лишними подтверждениями”
обеспечивать прозрачность для комплаенса

10.4. Политики как код (Policy-as-code): доступы и лимиты централизованно

Note

Одна из главных проблем legacy - правила “размазаны” по коду, что делает их:

неаудируемыми

сложными для изменения

непредсказуемыми

Мы переносим правила в декларативный слой (policy-as-code), чтобы:

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

Что задаём политиками:

доступ к доменам данных
лимиты по ролям, странам, KYC-уровням
условия на операции (например, step-up при определённых параметрах)
правила комплаенса и санкционные проверки

10.5. Неизменяемый аудит: полная трассировка критичных действий

Все критичные действия фиксируются в неизменяемом audit-trail:

кто (user/role/system)
что (действие, параметры)
когда (timestamp)
результат (успех/ошибка, решение risk engine)
почему (какие правила/политики применены)

Это даёт:

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

10.6. Интеграция с KYC/AML провайдерами

Мы интегрируем проверки как часть платформы:

проверки при регистрации и повышении уровня KYC
периодические переверки
санкционные списки и PEP-проверки
сигналы для risk engine

11. Reliability & Observability (стабильность как стандарт)

Наблюдаемость платформы: метрики, трейсы, логи, SLO, алерты и incident management как часть продукта.

11.1. Почему observability - это не “опциональная” часть

Example

В legacy-системах часто “что-то сломалось”, но никто не знает что и где. Мы строим observability как часть архитектуры:

метрики - что происходит в реальном времени
трейсы - как запрос проходит через систему
логи - детали для расследования
SLO - обещания пользователям и командам
алерты - уведомления о проблемах

Это даёт:

быстрое обнаружение проблем
быстрое восстановление
понимание причин
данные для улучшения

11.2. Метрики и SLO

Мы отслеживаем метрики по ключевым операциям:

Операция	Метрики	SLO
Логин	latency, success rate, errors	99.9% success, <500ms p99
Платёж	latency, success rate, fraud rate	99.95% success, <2s p99
Запрос баланса	latency, cache hit rate	99.99% success, <100ms p99
Риск-решение	latency, decision distribution	<100ms p99

Метрики публикуются в dashboard и используются для алертов.

11.3. Трейсинг и логирование

Каждый запрос имеет trace ID, который позволяет отследить его путь:

от клиента через API-gateway
через Core-сервисы
через модули
до внешних интеграций

Логи структурированы и содержат контекст (trace ID, user ID, operation ID), что упрощает поиск проблем.

11.4. Incident Management и On-call

Мы строим процесс:

Detection - алерт срабатывает при нарушении SLO
Escalation - уведомление on-call инженера
Investigation - быстрый поиск причины через метрики/трейсы/логи
Mitigation - быстрое восстановление (откат, отключение модуля, масштабирование)
Resolution - постоянное исправление
Postmortem - анализ и улучшения

12. Технологический стек

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

Info

Технологический стек - это не “мода”, это инструмент, который должен поддерживать архитектурные принципы:

контрактность (API-first)

event-driven обработку

масштабируемость и наблюдаемость

быстрые независимые релизы

Ключевые компоненты:

Языки: Go/Rust для Core (скорость, надёжность), TypeScript для модулей и UI (экосистема, скорость разработки)
Фреймворки: gRPC/HTTP для API, Kafka/RabbitMQ для событий
Базы данных: PostgreSQL для транзакционности и аудита, Redis для кэша и сессий
Оркестрация: Kubernetes для масштабирования и управления
Наблюдаемость: Prometheus/Grafana для метрик, Jaeger для трейсов, ELK для логов

13. UI/UX и команда

Дизайн-система, компонентный подход, метрики UX и организация команд для быстрого развития.

13.1. Дизайн-система как основа

Tip

Мы строим дизайн-систему, а не “макеты”:

единые компоненты (кнопки, формы, статусы, ошибки)
единые паттерны (как показываем операции, как объясняем ошибки, как подтверждаем действия)
единые принципы (скорость, прозрачность, контроль)

Это позволяет:

быстро добавлять новые экраны (компоненты уже есть)
обеспечивать консистентность (пользователь узнаёт интерфейс)
масштабировать команды (новые разработчики быстро включаются)

13.2. Метрики UX и фокус на результат

Мы не полагаемся на “нравится/не нравится”. Мы измеряем:

скорость сценариев - сколько времени занимает перевод, обмен, подключение модуля
drop-off - где пользователи бросают процесс
ошибки - какие ошибки встречаются и как часто
NPS/CSAT - удовлетворённость по ключевым операциям

Эти метрики питают наши решения о приоритизации и улучшениях.

Note

Почему это важно: в legacy-банках часто “красивый дизайн” не решает реальные проблемы. Мы фокусируемся на том, что действительно влияет на пользователей.

13.3. UX для B2C и B2B: разные продукты внутри одной платформы

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

13.3.1. B2C (физлица)

максимум скорости в ключевых сценариях: перевод, обмен, контроль безопасности
прозрачные статусы и понятные причины
персональная сборка модулей: пользователь сам включает то, что нужно (Earn, P2P, отчёты расширенные и т.д.)

13.3.2. B2B (компании)

роли и полномочия, лимиты по ролям/подразделениям
approvals (four-eyes), журналы действий, экспорт и отчётность
удобные массовые операции, интеграции, веб-панель управления
модульность на уровне компании: бизнес подключает только то, что соответствует его процессам

14. Как это закрывает проблемы исследования

Матрица решений: как каждый компонент платформы решает конкретные проблемы мобильного банкинга и legacy IT.

14.1. Матрица “проблема → механизм решения → где реализовано”

Проблема из исследования	Механизм решения	Где реализовано
Слабый UX, перегруженное приложение	Модульный UX: базовый интерфейс остаётся лёгким, расширения подключаются точечно	Experience Layer + Module Marketplace + Entitlements
Нет ощущения real-time, статусы “живут своей жизнью”	Event-driven статусы + единая state machine операций	Payments Orchestrator + Event Backbone
Долгие/ломающиеся процессы (KYC, выводы, согласования)	Durable workflows с сохранением состояния, ретраями и компенсациями	Workflow Engine + Core
Legacy core делает изменения дорогими и рискованными	Core + Modules: ядро стабильно, новое добавляется модулями по контрактам	Core Platform + Modules Layer
Интеграции каждый раз “уникальные”, ломаются при изменениях	API-first + контрактность (OpenAPI + event contracts), версионирование	API Layer + Contracts + CI/CD
Безопасность “догоняет продукт” и мешает UX	Security-by-design + step-up + risk decisioning	Identity & Access + Risk Core
Правила лимитов/доступов размазаны по коду	Policy-as-code: декларативные политики, единый контроль	Policy Engine + Entitlements
Слабая наблюдаемость: проблемы узнают от пользователей	Observability стандарт: traces/metrics/logs + SLO/alerts	Observability Core
Рост функций приводит к росту хаоса и стоимости поддержки	Изоляция модулей: SLO, kill-switch, canary, rollback	Module Ops + Feature Flags
Бизнесу неудобно: роли, согласования, контроль	B2B модули: roles, approvals, лимиты, массовые операции	Business Modules + Core

14.2. Что это даёт платформе (в терминах результата)

Скорость развития

Мы можем добавлять новые направления через модули, не переписывая ядро и не создавая “очередь релизов”
Надёжность и управляемость

Операции имеют прозрачный жизненный цикл, процессы устойчивы через workflows, а эксплуатация контролируется через наблюдаемость и SLO
Сильный мобильный продукт без перегруза

UI остаётся понятным, потому что функционал раскрывается через модульность - пользователь подключает нужное
Безопасность, которая не убивает UX

Risk engine и step-up подтверждения позволяют усиливать контроль только там, где это действительно нужно
Готовность к масштабированию

Слои архитектуры, контракты, изоляция модулей и cloud-native подход позволяют масштабировать нагрузку, команды и функционал предсказуемо

14.3. Почему этот подход future-proof (технологии меняются - платформа остаётся)

Question

Как построить систему, которая останется актуальной, когда меняются технологии, рынки и требования?

Мы исходим из того, что:

появляются новые рельсы, сети, провайдеры
меняются требования комплаенса
меняется поведение пользователей и ожидания от UX

Поэтому мы строим систему так, чтобы изменения происходили:

через контракты (API + события)
через модули (добавляем/заменяем функциональные блоки)
без разрушения Core (ядро остаётся стабильным)
с управляемыми релизами (canary, flags, rollback, SLO)

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

Заключение

Мы строим банковскую платформу нового поколения, которая решает проблемы слабого мобильного банкинга и устаревших ИТ-систем не “косметическими улучшениями”, а архитектурой.

Ключевые идеи:

Ядро + Модули - стабильная основа, которая не ломается при расширении
Real-time - события и потоки вместо пакетной обработки
Контрактность - API-first и управляемые интеграции
Безопасность встроена - не “прикручена потом”, а часть архитектуры
Наблюдаемость стандарт - видим проблемы, быстро восстанавливаемся
Масштабируемость - слои, контракты, изоляция позволяют расти предсказуемо

Результат - мобильный банк, который быстрый, надёжный, безопасный и готов к будущему.

Explorer

Лучший мобильный банкинг

Оглавление

1. Ключевые тезисы

2. Суть проблемы

2.1. Что ломает мобильный банкинг

2.2. Что ломает IT

2.3. Почему “просто переписать core” не подходит

3. Подход DARCA: платформенное ядро + подключаемые модули

3.1. Основной принцип: Core + Modules

3.2. Зачем модульность продукту

3.3. Зачем модульность разработке и операционной устойчивости

3.4. Future-proofing: мы учитываем, что технологии меняются быстро

4. Архитектура платформы (высокий уровень)

4.1. Слои архитектуры

4.1.1. Experience Layer (клиентские приложения и интерфейсы)

4.1.2. Core Platform Layer (платформенное ядро)

4.1.3. Modules Layer (подключаемые модули)

4.1.4. Integrations Layer (внешние системы и рельсы)

4.1.5. Infrastructure Layer (надёжность, безопасность, масштабирование)

4.2. Потоки данных и событий (как всё “дышит”)

4.3. Контур real-time (что мы делаем принципиально иначе, чем legacy)

5. Core (общее ядро): что в нём и почему именно это

5.1. Identity & Access (DARCA ID)

5.2. Ledger & Wallet Core

5.3. Payments Orchestrator + Internal Transfers

5.4. Risk & Compliance Core

5.5. Notifications & Messaging Core

5.6. Observability & Audit Core

5.7. Module Registry & Entitlements

5.8. Base App Capabilities (Default Modules) - базовые функции приложения, включённые по умолчанию

6. Modules (подключаемые расширения): что это такое “по-настоящему”

6.1. Принцип: модуль - это продуктовый блок, который расширяет платформу, не ломая Core

6.2. Категории модулей (как мы группируем расширения)

6.2.1. Financial Modules (финансовые сценарии)

6.2.2. Business Modules (B2B-контур)

6.2.3. Engagement & Content Modules (контент и вовлечение)

6.2.4. Support & Concierge Modules (расширенная поддержка)

6.2.5. Cards & Payments Modules (карты и покупки)

6.3. Как модуль подключается пользователем (Module Marketplace → entitlements → UI)

6.4. Как модуль устроен технически (Module Package)

6.5. Изоляция модулей: безопасность, стабильность, быстрый rollback

6.6. Почему модульность - это ключ к масштабированию продукта и IT

7. Механика “реального времени”: event-driven вместо batch

7.1. Событийная модель (events как “нервная система” платформы)

7.2. Зачем это mobile UX (реальный эффект для пользователя)

7.3. Зачем это business и compliance (прозрачность и управляемость)

7.4. Как это реализовано технически (без “магии”, но понятно)

8. Durable workflows: как мы делаем “несрываемые” процессы

9. API-first и контрактность

9.1. Почему API-first - это основа модульности

9.2. Два типа контрактов

9.2.1. API Contracts (синхронные)

9.2.2. Event Contracts (асинхронные)

9.3. Версионирование API и событий (как мы избегаем “ломающих релизов”)

9.4. Как это помогает модульности и скорости релизов

9.5. Партнёрские интеграции и B2B API (как мы делаем это “правильно”)

10. Security-by-design (многоуровневая безопасность)

10.1. Принцип: безопасность встроена в платформу, а не “прикручена потом”

10.2. Аутентификация и доступ: сильная безопасность без трения

10.3. Risk Engine: решения allow / step-up / hold / deny

10.4. Политики как код (Policy-as-code): доступы и лимиты централизованно

10.5. Неизменяемый аудит: полная трассировка критичных действий

10.6. Интеграция с KYC/AML провайдерами

11. Reliability & Observability (стабильность как стандарт)

11.1. Почему observability - это не “опциональная” часть

11.2. Метрики и SLO

11.3. Трейсинг и логирование

11.4. Incident Management и On-call

12. Технологический стек

13. UI/UX и команда

13.1. Дизайн-система как основа

13.2. Метрики UX и фокус на результат

13.3. UX для B2C и B2B: разные продукты внутри одной платформы

14. Как это закрывает проблемы исследования

14.1. Матрица “проблема → механизм решения → где реализовано”

14.2. Что это даёт платформе (в терминах результата)

14.3. Почему этот подход future-proof (технологии меняются - платформа остаётся)

Заключение

Table of Contents