Одно ядро, много приложений: как работает whitelabel-платформа для банкинга

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

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

Что не меняется никогда: ядро

Начнём с половины, которой творчество запрещено. Перевод проводится одинаково, называет ли его приложение отправкой, платежом или выплатой: две записи в бухгалтерской книге с двойной записью, и ничто никогда не удаляется — книга только дописывается, поэтому возврат — это встречная запись со ссылкой на исходную, а не стирание. Здесь живут счета, балансы и холды авторизации. Так же как KYC и онбординг, выпуск и расчёты по картам, крипто- и стейблкоин-рельсы. За ними стоит единая консоль оператора, где каждое привилегированное действие требует указать причину и попадает в журнал аудита.

Каждого из этих компонентов ровно один, и в этом смысл. Расчёты, сверка и комплаенс сложно сделать правильно и дорого сделать неправильно, поэтому их строят один раз, а результат наследуют все приложения. Когда тенант онбордит клиента, уровень KYC, определённый ядром, следует за клиентом в консоль независимо от того, экраны какого приложения собрали документы. Ядру неважно, как называется приложение сверху: оно видит счета и проводки, а не бренды.

Что меняется: язык дизайна, информационная архитектура, набор функций

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

Страница продукта /products/pay разбирает пять готовых направлений, и лучше всего воспринимать их как примеры из бесконечного множества, а не как меню из пяти пунктов. Halcyon — чистая биржа: сдержанная, с минимумом экранов и сделкой в центре. Lumen — супераппе, где деньги движутся внутри разговора, а платежи в чате, подписки и доход делят главный экран. Fern начинает с переводов: сначала пакетные выплаты и FX-конвертация по правилам. Volt — тёмная сборка на стейблкоинах с сортировщиком зарплаты и командными картами. Meridian — мультивалютный: счёт в EUR рядом с USDC, GBP-баланс для поездок и BTC-счёт, куда приходят награды по картам. Пять брендов, пять информационных архитектур, пять наборов функций — а под ними одна книга, один KYC и один карточный процессинг.

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

Ядро — то, что нельзя изобретать заново; приложение — то, что нельзя ограничивать. Whitelabel-платформа — это дисциплина, при которой обе эти фразы остаются верными одновременно.

Почему тематизация на уровне токенов лучше форка кодовой базы

Есть два способа сделать из одного продукта много. Очевидный — форк: скопировать кодовую базу под каждого клиента, перерисовать, выпустить. Это работает ровно один релиз. Дальше каждое исправление бага и каждое регуляторное изменение приходится применять N раз к N расходящимся копиям, копии рассинхронизируются, а поверхность безопасности, которую нужно держать в голове, умножается на число клиентов. Форк превращает одну понятную вам систему во множество непонятных.

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

Где находится дизайн-система

Токены — не абстрактная идея, а поставляемый артефакт. Protocore Design System (/products/pds) — это 144 дизайн-токена и 889 утилитарных классов: словарь, на котором тематизируется каждое приложение. Она dark-first, построена на токенах и по умолчанию использует нулевой радиус, а один и тот же набор токенов выпускается для web, .NET и нативных платформ, поэтому цвет, заданный однажды, означает один и тот же цвет в React-экране, десктопной консоли и нативной мобильной сборке. Бренд тенанта выражается переопределениями этого словаря, поэтому смена оформления приложения — это изменение конфигурации, а не переписывание.

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

Приложение — это конфигурация, а не сборка

Набор функций подчиняется тому же правилу. Каждый модуль — платежи в чате, доход, крипто, карты, подписки, командные карты, рефералы — это переключатель, который включается для тенанта, а флаг можно сначала раскатить на часть пользователей и лишь потом на всех. Операторы переключают их из панели конфигурации, а не через деплой. Так что разница между минимальным приложением для переводов и полноценным супераппе — это не два проекта, а две конфигурации одного. Референсное приложение, от которого стартует каждый тенант, — нейтральная сборка с брендом Protocore и полным меню; каждый whitelabel — это эта сборка с переопределёнными токенами и включёнными или выключенными модулями.

Честная граница

Одно ядро, много приложений оправдывает сложность, только когда приложений действительно много — или когда есть одно приложение, которое вы собираетесь со временем перекрашивать, перестраивать и менять по составу, не пересобирая каждый раз банк. Если вы выпускаете одно фиксированное приложение, которое никогда не наденет второй бренд, whitelabel-платформа вам не нужна; вам нужно приложение. Она окупается в том случае, для которого создана: платформа, раз за разом запускающая брендированные банковские продукты для тенантов, каждый из которых заметно свой и ни один не является форком. Полный разбор — пять направлений, референсное приложение и консоль оператора за ними — на /products/pay, а дизайн-система под всем этим — на /products/pds.