Одне ядро, багато застосунків: як працює whitelabel-банківська платформа

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

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

Що не змінюється ніколи: ядро

Почнімо з половини, якій творчість заборонена. Переказ проводиться однаково, хоч би як застосунок його назвав — відправлення, платіж чи виплата: два записи в книзі з подвійним записом, і нічого ніколи не видаляється — книга лише доповнюється, тож повернення коштів є зустрічним записом із посиланням на початковий, а не стиранням. Тут живуть рахунки, баланси й авторизаційні холди. Так само KYC та онбординг, випуск і розрахунки за картками, крипто- та стейблкоїн-рейки. За ними стоїть одна операторська консоль, де кожна привілейована дія вимагає вказати причину й потрапляє в журнал аудиту.

Кожного з цих елементів рівно один, і в цьому сенс. Розрахунки, звірка й комплаєнс складні для правильної реалізації й дорогі у разі помилок, тож ви будуєте їх раз, а кожен застосунок успадковує результат. Коли тенант онбордить клієнта, рівень KYC, який визначило ядро, іде за цим клієнтом у консоль незалежно від того, екрани якого застосунку зібрали документи. Ядру байдуже, як називається застосунок поверх нього: воно бачить рахунки й записи, а не бренди.

Що змінюється: дизайн-мова, інформаційна архітектура, набір функцій

Усе над ядром можна вільно змінювати за трьома осями. Перша — дизайн-мова: колір, типографіка, радіус кутів, відступи, анімація — візуальна граматика бренду. Друга — інформаційна архітектура: що на головному екрані, як названо й упорядковано сценарії, яка дія за один дотик, а яка за три. Третя — набір функцій: які модулі взагалі ввімкнені. Мінімалістичний застосунок для переказів і щільний super-app можуть працювати на тому самому ядрі, не маючи жодного спільного екрана.

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

Це не означає, що продукт — це п'ять застосунків. П'ять — це напрями, якими може піти той самий конвеєр; важливе число не п'ять, а скільки тенантів ви підключите. Кожен з них доводить, що фронтенд може відрізнятися аж до форми головного екрана, а ядро під ним цього не помічає.

Ядро — те, що не можна вигадувати наново; застосунок — те, що не можна обмежувати. Whitelabel-платформа — це дисципліна, яка дозволяє обом цим твердженням залишатися правдивими одночасно.

Чому темізація на рівні токенів краща за форк кодової бази

Є два способи зробити з одного продукту багато. Очевидний — форк: скопіювати кодову базу для кожного клієнта, змінити стилі й випустити. Це працює рівно один реліз. Далі кожне виправлення помилки й кожну регуляторну зміну доводиться застосовувати N разів у N копіях, що розходяться; копії розсинхронізуються, а поверхня безпеки, яку треба враховувати, множиться на кількість клієнтів. Форк перетворює одну зрозумілу вам систему на багато незрозумілих.

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

Де розташована дизайн-система

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

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

Застосунок — це конфігурація, а не збірка

Набір функцій підпорядковується тому самому правилу. Кожен модуль — платежі в чаті, earn, крипто, картки, підписки, командні картки, реферали — це перемикач, який вмикається для кожного тенанта, а прапор можна спершу розгорнути на частину користувачів, перш ніж відкривати всім. Оператори перемикають їх у панелі конфігурації, а не через деплой. Тож різниця між простим застосунком для переказів і повноцінним super-app — це не два проєкти, а дві конфігурації одного проєкту. Еталонний застосунок, з якого починає кожен тенант, — нейтральна збірка під брендом Protocore з усім меню; кожен whitelabel — це ця збірка з перевизначеними токенами та ввімкненими чи вимкненими модулями.

Чесна межа

Одне ядро, багато застосунків виправдовує свою складність, лише коли застосунків справді багато — або коли є один, який ви збираєтеся з часом змінювати за виглядом, структурою й обсягом, не перебудовуючи щоразу банк. Якщо ви випускаєте один незмінний застосунок, що ніколи не отримає другого бренду, whitelabel-платформа вам не потрібна; вам потрібен застосунок. Свою цінність вона доводить у тому випадку, для якого її створили: платформа, що запускає брендовані банківські продукти тенант за тенантом, кожен — помітно свій, і жоден не є форком. Повний розбір — п'ять напрямів, еталонний застосунок і операторська консоль за ними — на /products/pay, а дизайн-система під усім цим — на /products/pds.