Едно јадро, многу апликации: како работи whitelabel банкарска платформа

Whitelabel банкарска платформа е едно банкарско јадро со заменлив front end. Јадрото е делот што мора да биде точен: книга со двојно книжење, сметки на клиенти, KYC и onboarding, издавање и процесирање картички, крипто и стејблкоин канали и операторската конзола што стои зад сето тоа. Апликацијата е делот што го гледа клиентот — нејзиното име, боите, обликот на екраните, подмножеството функции што ги вклучува. Whitelabel значи дека едно јадро може да носи многу лица без да се гради одново под секое од нив. Едно јадро, многу апликации.

Кажано едноставно, тоа е тврдење за тоа каде стојат шевовите. Сè што допира пари е заедничко, ревидирано и усогласено еднаш; сè што го допира клиентот се конфигурира по tenant. Инженерството што е важно е да се чува таа линија чесна — front end-от слободно да се разликува, а јадрото врз кое стои никогаш да не се форкува. Ова е анализа на тоа како се влече таа линија и зошто влечењето со дизајн токени е подобро од влечење со форк.

Што никогаш не се менува: јадрото

Почнете со половината на која не ѝ е дозволено да биде креативна. Трансферот се книжи на ист начин без разлика дали апликацијата го нарекува испраќање, плаќање или исплата: два записа во книга со двојно книжење, и ништо никогаш не се брише — книгата само додава, па поврат е спротивен запис што упатува на оригиналот, а не бришење. Сметките, салдата и авторизациските блокади живеат тука. Така и KYC и onboarding, издавањето и порамнувањето на картички и крипто и стејблкоин каналите. Зад нив стои една операторска конзола во која секоја привилегирана акција бара причина и завршува во дневник за ревизија.

Од секое од овие постои точно едно, и во тоа е смислата. Порамнувањето, усогласувањето и compliance-от тешко се прават добро, а скапо е да се направат лошо, па се градат еднаш, а секоја апликација го наследува резултатот. Кога tenant ќе внесе клиент, KYC нивото што го одредува јадрото го следи тој клиент во конзолата без разлика чии екрани ги собрале документите. Јадрото не знае, ниту го интересира, како се вика апликацијата одозгора — гледа сметки и записи, не брендови.

Што се менува: дизајн јазик, информациска архитектура, избор на функции

Сè над јадрото е слободно да се движи, по три оски. Првата е дизајн јазикот: боја, типографија, радиус на аглите, размаци, движење — визуелната граматика на брендот. Втората е информациската архитектура: што е на почетниот екран, како се именуваат и редат тековите, која акција е на еден допир, а која на три. Третата е изборот на функции: кои модули воопшто се вклучени. Лесна апликација за трансфери и густа супер-апликација можат да работат на идентично јадро без да делат ниту еден екран.

Страницата на производот на /products/pay прикажува пет разработени насоки, и најдобро се читаат како примери од бесконечно многу, а не како мени од пет. Halcyon е чиста берза — воздржана, со малку површини, а тргувањето е во центарот. Lumen е супер-апликација во која парите се движат во самиот разговор, а плаќањата преку чет, претплатите и earn го делат почетниот екран. Fern започнува со трансфери — најпрво групни исплати и конверзија на валути по правила. Volt е build во темна тема, ориентиран кон стејблкоини, со распределба на плата и тимски картички. Meridian е повеќевалутен: EUR сметка покрај USDC, GBP салдо за патувања и BTC сметка во која пристигнуваат наградите од картичката. Пет бранда, пет информациски архитектури, пет мешавини на функции — една книга, еден KYC, еден процесор на картички под сите.

Ништо од тоа не значи дека производот е пет апликации. Петте се насоки што истиот pipeline може да ги земе; важниот број не е пет, туку онолку tenant-и колку што ќе вклучите. Секој е доказ дека front end-от може да се разликува до обликот на почетниот екран, додека јадрото под него не забележува.

Јадрото е делот што не смеете да го измислувате одново; апликацијата е делот што не смеете да го ограничувате. Whitelabel платформата е дисциплина да се одржат двете реченици вистинити истовремено.

Зошто тематизирањето на ниво на токени е подобро од форкување на кодот

Постојат два начина да се направи еден производ да изгледа како многу. Очигледниот е форк: копирај ја кодната база по клиент, рестилизирај ја, испорачај. Функционира точно едно издание. Потоа секоја поправка на грешка и секоја регулаторна промена мора да се примени N пати врз N копии што се разместуваат, копиите излегуваат од синхронизација, а безбедносната површина за која треба да расудувате се множи со бројот на клиенти. Форкот претвора еден систем што го разбирате во многу што не ги разбирате.

Тематизирањето со токени го превртува тоа. Има една кодна база. Брендот е збир од вредности — токени за боја, типографија, радиус и размаци; конфигурација на компоненти; сет на feature flag-ови — разрешени при build во брендирана апликација. Променете еден токен и секој екран што го чита се движи заедно, бидејќи ништо не ја хардкодира вредноста што треба да се влече од токен. Поправка на текот на трансфер излегува кај сите tenant-и одеднаш, бидејќи има само еден тек на трансфер за поправање. Брендовите се разликуваат по конфигурација, не по изворен код.

Каде стои дизајн системот

Токените не се лабава идеја; тие се испорачан артефакт. Protocore Design System — /products/pds — е 144 дизајн токени и 889 utility класи: речникот во кој е тематизирана секоја апликација. Тој е dark-first, управуван од токени и со радиус нула по default, а истиот сет токени се емитува за web, .NET и native, па боја дефинирана еднаш значи иста боја во React екран, десктоп конзола и native мобилен build. Брендот на tenant-от се изразува како override-и врз тој речник, затоа менувањето на изгледот на апликација е промена на конфигурација, а не препишување.

Тоа е и она што го прави front end-от навистина слободен, а не слободен само во рамки на шаблон. Бидејќи дизајн јазикот живее во токени и utility класи, а не во еднократни stylesheet-ови, дизајнерот може да го одведе tenant-от далеку од референтниот build — со своја палета, типографија, густина и ритам — без да го допре јадрото или да ја форкува апликацијата. Бојата оди длабоко, но сепак е само боја; системот под неа е заеднички.

Апликацијата е конфигурација, не build

Изборот на функции го следи истото правило. Секој модул — плаќања преку чет, earn, крипто, картички, претплати, тимски картички, препораки — е прекинувач што се вклучува по tenant, а flag може прво да се пушти кај дел од корисниците пред да оди широко. Операторите ги префрлаат од панел за конфигурација, а не со deploy. Значи разликата меѓу гола апликација за трансфери и целосна супер-апликација не се два проекти, туку две конфигурации на еден проект. Референтната апликација од која тргнува секој tenant е неутрален build со Protocore бренд и со целото мени присутно — секој whitelabel е тој build со override-нати токени и вклучени или исклучени модули.

Искрената граница

Механизмот „едно јадро, многу апликации“ се исплаќа само кога навистина имате многу апликации — или една апликација што мислите да ја рестилизирате, преуредите и преобликувате со време, без секој пат одново да ја градите банката. Ако испорачувате една фиксна апликација што никогаш нема да носи втор бренд, не ви треба whitelabel платформа; ви треба апликација. Своето место го заслужува во случајот за кој е направена: платформа што подига брендирани банкарски производи tenant по tenant, секој видливо свој, ниеден форк. Целата анализа — петте насоки, референтната апликација и операторската конзола зад нив — е на /products/pay, а дизајн системот под нив е на /products/pds.