Будувати чи купувати: реальна вартість системи core banking

Рано чи пізно кожен засновник фінтеху оцінює одне й те саме рішення: побудувати систему core banking власними силами чи ліцензувати готову й налаштувати її. Наївне порівняння — ліцензійна плата з одного боку, кілька зарплат розробників з іншого — майже завжди хибне, бо ці дві колонки містять різні речі.

Чесне порівняння — це сукупна вартість володіння протягом життя продукту: розробка, постійна підтримка, регулярна робота над безпекою та комплаєнсом і дохід, якого ви не отримуєте, поки будуєте. Ми створюємо програмне забезпечення core banking, тож у нас, очевидно, є позиція — але розрахунок нижче саме той, який ми хотіли б побачити, якби були покупцями.

Що насправді означає «система core banking»

Більшість оцінок «будувати чи купувати» помиляються ще до першої цифри, бо обсяг занижений. Банківський застосунок, який бачать ваші клієнти, — це видима частка системи. Ядро рівня продакшену — це чотири продукти в одному:

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

Шлях розробки: що насправді містить бюджет

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

Щодо строків, патерн стабільний: один-два роки, щоб дійти до того, що зріла платформа дає в перший день. Час іде не на екрани; він іде на коректність леджера під конкурентністю, на інтеграції провайдерів, кожна з яких приносить власні особливості sandbox і етапи сертифікації, на посилення безпеки та на довгий хвіст крайніх випадків, що проявляються лише з реальними клієнтами й реальними грошима.

І витрати не закінчуються запуском. Провайдери змінюють API, блокчейн-мережі оновлюються, регулювання рухається, залежності старіють. Внутрішнє ядро — не проєкт, що завершується; це постійна команда, яку ви зобов’язуєтеся фінансувати, доки існує продукт.

Витрати, які ніколи не потрапляють до таблиці

• Альтернативна вартість: кожен місяць, витрачений на розробку леджера, — це місяць, коли продукту немає на ринку. Конкуренти, що ліцензували своє ядро, залучають клієнтів та ітерують ціни, поки ви все ще інтегруєте провайдерів.
• Кадровий ризик: план розробки припускає, що команда, яка її починає, її й завершить. Втратити одного з двох інженерів, які розуміють леджер, посеред проєкту — це зсув графіка, що вимірюється місяцями.
• Хвіст коректності: леджер, коректний на 99%, — не «майже готовий»; це генератор тикетів підтримки, розривів у звірках і регуляторних інцидентів. Останній 1% коштує більше, ніж перші 99%.
• Безпека як операційна робота: пентести, ротація ключів, реагування на інциденти, моніторинг та алерти — регулярні витрати, що існують незалежно від того, чи щось пішло не так.
• Підтримання комплаєнсу: закінчення строку дії документів KYC, еволюція правил щодо криптоактивів, нові звітні зобов’язання. Ця робота повторюється щороку, і її неможливо відкласти.
• Бек-офіс: внутрішні розробки регулярно ставляться до інструментів персоналу як до другорядного, і операційна команда отримує у спадок SQL-консоль. Кожен регулятор чи аудитор, який це побачить, змусить вас перебудувати все як слід.
• Локалізація: постачання багатьма мовами зі справжньою підтримкою right-to-left коштує дешево, коли закладене з першого дня, і дорого, коли продукт уже побудований.

Шлях купівлі: за що ви платите і що залишається вашим

На стороні купівлі технологічна колонка явна: ліцензія або оренда платформи — серйозні вендори оцінюють модулі, мережі та мови окремо, тож рахунок відповідає тому, що ви реально активуєте, — плюс інфраструктура, на якій працює інстанс. Чого купівля не знімає: ваших регуляторних ліцензій чи партнерських домовленостей, ваших комерційних угод із провайдерами, вашого операційного персоналу, вашої дистрибуції. Ці витрати належать оператору на будь-якому шляху — купівля прибирає гору інженерії, а не бізнес.

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

Коли будувати власними силами — правильне рішення

«Будувати чи купувати» — не риторичне питання з наперед визначеною відповіддю. Будувати правильно, коли виконується хоча б одна з умов:

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

П’ять запитань для рішення

• Диференціація: чи обере вас колись клієнт тому, що ваш леджер саморобний? Якщо ваша перевага — продукт, дистрибуція чи ціна, ядро — це сантехніка: необхідна, але не та, яку вам варто винаходити заново.
• Строки: чи витримає бізнес один-два роки без доходу, поки будується ядро, на ринку, який не чекає?
• Команда: чи маєте ви — або чи реально наймете й утримаєте — інженерів, які вели в продакшені системи, що рухають гроші?
• Трирічна вартість: порівнюйте вартість розробки плюс постійну команду підтримки з ліцензією плюс активованими модулями на горизонті трьох років — ніколи вартість запуску з вартістю запуску.
• Вихід: як виглядає вихід на кожному шляху? Всередині ризик — ключові люди, що йдуть разом зі знаннями. У вендора вимагайте виділений інстанс, власну базу даних і власні ключі — тоді вихід є міграцією.

Де в цьому рішенні місце Coreza

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

Версія цього ядра працює в продакшені в регульованому європейському фінтеху з 2024 року, а новий інстанс розгортається за тижні: бренд, модулі, мови та мережі — це конфігурація, а не інженерія. Якщо ви саме рахуєте «будувати чи купувати», ось порівняння, яке ми запрошуємо зробити: трирічна вартість проти трирічної вартості, з заповненою прихованою колонкою.