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

Whitelabel банкова платформа е едно банково ядро със заменяем front end. Ядрото е частта, която трябва да е вярна: книга с двойно записване, клиентски сметки, KYC и онбординг, издаване и обработка на карти, крипто и стейбълкойн релси и операторската конзола зад всичко това. Приложението е частта, която клиентът вижда — името му, цветовете, формата на екраните, подмножеството от включени функции. Whitelabel означава, че едно ядро може да носи много лица, без да се изгражда наново под всяко от тях. Едно ядро, много приложения.

Казано направо, това е твърдение къде минават шевовете. Всичко, което засяга пари, е споделено, одитирано и съгласувано веднъж; всичко, което засяга клиента, се конфигурира за всеки тенант. Инженерството, което има значение, е да пазите тази граница честна — front end-ът да се различава свободно, докато ядрото под него никога не се разклонява. Това е разбор как се прокарва границата и защо с дизайн токени се прокарва по-добре, отколкото с форк.

Какво никога не се променя: ядрото

Започнете с половината, на която не е позволено да бъде креативна. Преводът се осчетоводява по един и същи начин, независимо дали приложението го нарича изпращане, плащане или изплащане: два записа в книга с двойно записване и нищо не се изтрива — книгата само добавя, така че възстановяването на сума е насрещен запис, който сочи към оригинала, а не заличаване. Тук живеят сметките, салдата и блокираните суми при авторизация. Също така KYC и онбординг, издаване и сетълмент на карти, и крипто и стейбълкойн релсите. Зад тях стои една операторска конзола, в която всяко привилегировано действие изисква причина и попада в журнал за одит.

От всяко от тези неща има точно по едно и това е смисълът. Сетълментът, съгласуването и съответствието са трудни за правилно изпълнение и скъпи при грешка, затова ги изграждате веднъж и оставяте всяко приложение да наследи резултата. Когато тенант онбордва клиент, KYC нивото, определено от ядрото, го следва в конзолата, независимо чии екрани са събрали документите. Ядрото не знае и не го интересува как се казва приложението отгоре — вижда сметки и записи, не брандове.

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

Всичко над ядрото се движи свободно по три оси. Първата е дизайн езикът: цвят, типография, радиус на ъглите, разстояния, движение — визуалната граматика на марката. Втората е информационната архитектура: какво стои на началния екран, как се наименуват и подреждат потоците, кое действие е на един тап и кое на три. Третата е наборът от функции: кои модули изобщо са включени. Лек приложение за преводи и гъст super-app могат да работят върху идентично ядро, без да споделят нито един екран.

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

Нищо от това не значи, че продуктът е пет приложения. Петте са посоки, които същият конвейер може да поеме; важното число не е пет, а колкото тенанта онбордвате. Всяка е доказателство, че front end-ът може да се различава чак до формата на началния екран, а ядрото под него дори не забелязва.

Ядрото е частта, която не ви е позволено да преизобретявате; приложението е частта, която не ви е позволено да ограничавате. Whitelabel платформата е дисциплината да държите и двете изречения верни едновременно.

Защо тематизирането на ниво токени бие разклоняването на кода

Има два начина да направите един продукт да изглежда като много. Очевидният е форк: копирате кода за всеки клиент, рестилизирате го и го пускате. Работи точно за една версия. След това всяка поправка и всяка регулаторна промяна трябва да се прилага N пъти върху N разминаващи се копия, копията излизат от синхрон, а повърхността за сигурност, за която трябва да мислите, се умножава по броя клиенти. Форкът превръща една система, която разбирате, в много, които не разбирате.

Тематизирането на ниво токени обръща това. Има една кодова база. Марката е набор от стойности — токени за цвят, шрифт, радиус и разстояния; конфигурация на компонентите; набор от feature флагове — които се разрешават при билд в брандирано приложение. Променяте токен и всеки екран, който го чете, се променя заедно, защото нищо не е хардкоднало стойност, която трябва да идва от токен. Поправка в потока за преводи стига до всеки тенант едновременно, защото има само един поток за преводи за поправяне. Марките се различават в конфигурацията си, не в кода си.

Къде стои дизайн системата

Токените не са смътна идея; те са доставен артефакт. Protocore Design System — /products/pds — е 144 дизайн токена и 889 utility класа: речникът, на който е тематизирано всяко приложение. Тя е dark-first, управлявана от токени и с нулев радиус по подразбиране, а един и същ набор токени се излъчва за уеб, .NET и native, така че цвят, дефиниран веднъж, значи същия цвят в React екран, десктоп конзола и native мобилен билд. Марката на тенанта се изразява като презаписвания върху този речник, затова смяната на облика на приложението е промяна на конфигурация, а не пренаписване.

Това е и което прави front end-а наистина свободен, а не свободен в рамките на шаблон. Тъй като дизайн езикът живее в токени и utility класове, а не в еднократни стилови файлове, дизайнер може да отдалечи тенант много от референтния билд — собствена палитра, шрифт, плътност и ритъм — без да пипа ядрото и без да разклонява приложението. Боята стига дълбоко, но си остава само боя; инсталацията под нея е обща.

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

Наборът от функции следва същото правило. Всеки модул — чат плащания, спестявания, крипто, карти, абонаменти, екипни карти, препоръки — е превключвател за всеки тенант, а флагът може да се пусне първо за част от потребителите, преди да тръгне широко. Операторите ги превключват от конфигурационен панел, а не с деплой. Така разликата между оскъдно приложение за преводи и пълен super-app не е два проекта, а две конфигурации на един проект. Референтното приложение, от което тръгва всеки тенант, е неутрален билд с марка Protocore и цялото меню налице — всеки whitelabel е този билд с презаписани токени и включени или изключени модули.

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

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