Строить или покупать: реальная стоимость кор-банкинга

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

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

Что на самом деле означает «кор-банкинг»

Большинство оценок «строить или покупать» рушится ещё до того, как записана первая цифра, потому что объём работ занижен. Банковское приложение, которое видят ваши клиенты, — это лишь видимая часть системы. Кор, готовый к продакшену, — это четыре продукта в одном:

• Транзакционное ядро: леджер с двойной записью, который остаётся сбалансированным под конкурентной нагрузкой, где каждый баланс выводится из леджера и ежедневно сверяется с каждым провайдером.
• Клиентский продукт: само банковское приложение, онбординг с уровнями KYC и KYB, мультивалютные счета, переводы, карты — и всё чаще криптокошельки с настоящей кастодиальной инфраструктурой ключей за ними.
• Второй продукт, который никто не закладывает в смету: операционный бэк-офис с очередями комплаенса, мониторингом транзакций, настройкой комиссий, отчётностью и гранулярными ролями сотрудников.
• Невидимый слой: append-only журнал аудита, двухфакторные сценарии за пределами логина, rate limiting, фингерпринтинг устройств и управление ключами, которое держит секреты вне кода и базы данных.

Путь разработки: что на самом деле входит в бюджет

Реалистичная собственная разработка требует сеньор-инженеров бэкенда с опытом финансовых систем, фронтенд-инженеров, DevOps и безопасности, QA и продуктовой координации, понимающей комплаенс. Команды, достигающие продакшен-качества, редко бывают меньше шести–десяти сеньоров — а дефицитный профиль, инженеры, уже эксплуатировавшие леджеры и кастоди в продакшене, — это ровно тот профиль, который труднее всего нанять и удержать.

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

И расходы не заканчиваются на запуске. Провайдеры меняют API, блокчейн-сети обновляются, регулирование движется, зависимости устаревают. Собственный кор — это не проект, который заканчивается; это постоянная команда, которую вы обязуетесь финансировать, пока существует продукт.

Издержки, которые никогда не попадают в таблицу

• Стоимость упущенных возможностей: каждый месяц, потраченный на леджер, — это месяц, когда продукта нет на рынке. Конкуренты, лицензировавшие свой кор, подключают клиентов и итерируют цены, пока вы всё ещё интегрируете провайдеров.
• Риск найма: план предполагает, что команда, начавшая разработку, её и закончит. Потерять одного из двух инженеров, понимающих леджер, в середине проекта — это сдвиг графика, измеряемый месяцами.
• Хвост корректности: леджер, корректный на 99%, — это не «почти готово», это генератор тикетов поддержки, расхождений сверки и регуляторных инцидентов. Последний 1% стоит дороже первых 99%.
• Безопасность как операционный процесс: пентесты, ротация ключей, реагирование на инциденты, мониторинг и алерты — регулярные расходы, существующие независимо от того, случается ли что-то плохое.
• Поддержание комплаенса: истечение срока документов KYC, меняющиеся правила по криптоактивам, новые обязательства по отчётности. Эта работа повторяется каждый год, и её нельзя отложить.
• Бэк-офис: при собственной разработке инструменты для сотрудников систематически остаются на потом, и операционная команда получает в наследство SQL-консоль. Любой регулятор или аудитор, увидевший это, заставит вас перестроить всё как следует.
• Локализация: выпуск на многих языках с настоящей поддержкой RTL стоит дёшево, если заложен с первого дня, и дорого, если прикручивать его к уже построенному продукту.

Путь покупки: за что вы платите и что остаётся вашим

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

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

Когда собственная разработка — правильное решение

«Строить или покупать» — не риторический вопрос с заранее известным ответом. Строить правильно, когда верно хотя бы одно из следующего:

• Инфраструктура и есть продукт: вы продаёте леджер, кастоди или саму способность banking-as-a-service, поэтому владение ими — это и есть бизнес.
• Ваша дифференциация живёт в требованиях, которые не покрывает ни один вендор, — не в функциях, которых вендору не хватает в этом квартале, а в возможностях, структурно лежащих вне того, что делают платформы.
• У вас уже есть сеньор-команда с продакшен-опытом кор-банкинга и запас средств, чтобы финансировать её годами без выручки.
• Регулятор или материнская компания ставит полный внутренний контроль над стеком условием, которое нельзя обсуждать.

Пять вопросов для решения

• Дифференциация: выберет ли вас клиент хоть раз потому, что ваш леджер написан своими руками? Если ваше преимущество — продукт, дистрибуция или цена, то кор — это сантехника: необходимая, но не та, которую вам стоит изобретать заново.
• Сроки: выдержит ли бизнес один–два года без выручки, пока строится кор, на рынке, который не ждёт?
• Команда: есть ли у вас — или можете ли вы реалистично нанять и удержать — инженеры, эксплуатировавшие в продакшене системы, которые двигают деньги?
• Стоимость за три года: сравнивайте стоимость разработки плюс постоянную команду поддержки против лицензии плюс активированных модулей на горизонте трёх лет — и никогда стоимость запуска против стоимости запуска.
• Выход: как выглядит уход на каждом пути? При собственной разработке риск — ключевые люди, уходящие вместе со знанием. С вендором требуйте выделенный инстанс, собственную базу данных и собственные ключи — тогда выход это миграция.

Где в этом решении находится Coreza

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

Версия этого кора работает в продакшене в регулируемом европейском финтехе с 2024 года, а новый инстанс разворачивается за недели: брендинг, модули, языки и сети — это конфигурация, а не инженерия. Если вы считаете цифры «строить или покупать», именно это сравнение мы и предлагаем сделать — стоимость за три года против стоимости за три года, со заполненной скрытой колонкой.