Архитектура core banking для крипто-банка: модули, интеграции и паттерны

Архитектура core banking для крипто-банка отличается от классического банка двумя контурами: мультичейн-кошельки с кастоди и двойной учёт (фиат + криптоактивы в единой главной книге).Разбираем подробно: интеграция кастоди, платформа крипто банка. В статье разбираем модульную архитектуру, которую Konomic использует в проектах: ядро главной книги, платёжный слой, крипто-слой, кастоди и комплаенс, и объясняем, как модули интегрируются без переписывания системы.

Из каких модулей состоит core banking крипто-банка?

Минимальный набор модулей: ядро главной книги (accounts, balances, ledger), модуль платежей (SEPA, SEPA Instant, SWIFT), модуль карт, крипто-модуль (кошельки, обмен, ордера), кастоди-модуль (MPC, холодное хранение), модуль комплаенса (KYC/AML, мониторинг) и модуль отчётности. Каждый модуль — отдельный сервис со своим API.

Главное архитектурное решение — единая главная книга для фиата и крипто. Если вести два отдельных учёта (банковский и крипто), сверка станет кошмаром. Лучший паттерн — двухвалютные счета с поддержкой токенов как активов в той же книге.

Модули core banking крипто-банка

Как интегрировать кастоди с core banking?

Кастоди-слой работает как внешняя система: создаёт кошельки, подписывает транзакции, хранит ключи. Core banking не должен знать адреса и ключи — он общается с кастоди через API: создать депозитный адрес, получить баланс, инициировать вывод. Это разделение защищает от утечки ключей через банковские сервисы.

Паттерн double-entry для крипто: каждый депозит создаёт проводку «криптоактив клиента» и «обязательство перед клиентом». Вывод — обратную проводку. Сверка с блокчейном — периодическая, по хэшам транзакций. Так баланс в главной книге всегда соответствует фактическим активам на кошельках.

1. Кастоди-провайдер: Fireblocks, BitGo или self-hosted MPC
2. Интеграция по API: создание адресов, подпись, балансы
3. Сверка: блокчейн-сканы, сопоставление с проводками
4. Политика подтверждений: лимиты, мультиподпись, risk-engine
5. Аварийные процедуры: восстановление ключей, cold wallet

Какие паттерны проектирования подходят для крипто-банка?

Event-driven архитектура — базовый паттерн: каждое событие (пополнение, вывод, обмен) публикуется в шину и обрабатывается независимыми сервисами. Это позволяет добавлять модули (антифрод, отчётность, уведомления) без изменения ядра.

Saga-паттерн для распределённых транзакций: обмен фиат→крипто затрагивает два сервиса — если списание с фиатного счёта прошло, а крипто-вывод упал, saga откатывает первую операцию. Без saga в системе появятся «висячие» операции и расхождения балансов.

CQRS для чтения и записи: запись идёт в главную книгу, чтение — в оптимизированные проекции (выписки, отчёты). Нагрузка крипто-банка неравномерна — CQRS спасает при пиковых нагрузках торговых дней.

Как обеспечить отказоустойчивость по DORA?

DORA требует от крипто-банка управления ИТ-рисками, резервирования и планов восстановления. Архитектурно это значит: мультирегиональное развёртывание, репликация БД с RPO близким к нулю, автоматическое переключение (failover) и регулярные тесты восстановления.

Кастоди-слой должен иметь независимый контур: даже при полном отказе банковских сервисов вывод средств клиентов должен быть возможен через резервные процедуры. Документируйте RTO/RPO для каждого критичного сервиса и тестируйте их минимум раз в квартал — регулятор запросит эти документы при аудите.

Требования DORA к архитектуре

Какую главную книгу выбрать: готовую или собственную?

Готовые core banking системы (Mambu, Thought Machine Vault, SDK.finance) дают проверенные функции учёта и платежей, но крипто-модули в них отсутствуют или поверхностны. Собственная главная книга даёт полный контроль над крипто-учётом, но требует времени на разработку и тестирование.

Компромисс: готовое ядро для фиатных операций + собственный крипто-слой с двойным учётом поверх. Такой гибрид позволяет запуститься за 2–4 месяца и не переписывать ядро, когда крипто-функции усложняются. Konomic использует этот подход в большинстве проектов крипто-банков.

Как масштабировать платформу при росте клиентов?

Масштабирование начинается с изоляции сервисов: платёжный шлюз, блокчейн-индексатор и отчётность должны масштабироваться независимо. Блокчейн-индексация — отдельный сервис с очередью задач: при депозитах тысячи транзакций не должны блокировать главную книгу.

База данных: горизонтальное шардирование по клиентам или валютам с транзакционными границами в пределах шарда. Кэш для чтения балансов и выписок. Очереди (Kafka, RabbitMQ) для асинхронных операций. План роста закладывается до запуска, а не после — переделка ядра под нагрузку стоит дороже всего.

Частые вопросы

Что такое core banking для крипто-банка?

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

Какую главную книгу выбрать для крипто-банка?

Оптимально — гибрид: готовое ядро (Mambu, Thought Machine, SDK.finance) для фиата и собственный крипто-слой с двойным учётом. Полностью собственная книга оправдана при уникальных крипто-продуктах.

Как интегрировать кастоди с core banking?

Через API: создание адресов, подпись транзакций, балансы. Кастоди — внешний контур, банковские сервисы не должны иметь доступа к ключам. Сверка — по хэшам блокчейн-транзакций.

Что такое двойной учёт в крипто-банке?

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

Как выполнить требования DORA в архитектуре?

Мультирегиональное развёртывание, репликация БД, failover, управление вендорами с exit-планами и регулярные тесты восстановления. Документы RTO/RPO готовятся на этапе проектирования.

Сколько времени занимает разработка платформы крипто-банка?

Гибридная платформа с готовым ядром и кастоди-провайдером — 2–4 месяца до MVP. Полностью собственная платформа — от 12 месяцев. Срок зависит от набора продуктов и интеграций.

Источники и методология

Архитектурные паттерны основаны на опыте Konomic (гибридные платформы, event-driven, CQRS) и публичных материалах Mambu, Thought Machine, Fireblocks. Требования DORA — из регламента (EU) 2022/2554.

Автор: Дмитрий Орлов (CTO) — CTO, Konomic. 10+ лет в разработке: core banking, платёжные системы, блокчейн-архитектура, безопасность. Актуальность: 2026-08-20.

Explore: [Разработка платформ](https://konomic.com/) · [BaaS development](https://konomic.com/baas-development)