Jeden rdzeń, wiele aplikacji: jak działa platforma bankowa whitelabel

Platforma bankowa whitelabel to jeden rdzeń bankowy z wymienną warstwą frontendu. Rdzeń to część, która musi być poprawna: księga główna z zapisem podwójnym, konta klientów, KYC i onboarding, wydawanie i procesowanie kart, kanały krypto i stablecoinów oraz konsola operatora, która działa za tym wszystkim. Aplikacja to część, którą widzi klient — jej nazwa, kolory, kształt ekranów, podzbiór włączonych funkcji. Whitelabel oznacza, że jeden rdzeń może mieć wiele twarzy bez przebudowy pod każdą z nich. Jeden rdzeń, wiele aplikacji.

Mówiąc wprost, to twierdzenie o tym, gdzie przebiegają szwy. Wszystko, co dotyka pieniędzy, jest wspólne, audytowane i uzgadniane raz; wszystko, co dotyka klienta, jest konfigurowane per tenant. Liczy się utrzymanie tej granicy w uczciwy sposób — front może się dowolnie różnić, a rdzeń, na którym stoi, nigdy się nie rozgałęzia. Ten tekst to rozbiór tego, jak taką granicę się wyznacza i dlaczego tokeny designu sprawdzają się lepiej niż fork.

Co nigdy się nie zmienia: rdzeń

Zacznijmy od połowy, w której nie ma miejsca na kreatywność. Przelew księguje się tak samo, niezależnie od tego, czy aplikacja nazywa go wysyłką, płatnością czy wypłatą: dwa wpisy w księdze z zapisem podwójnym i nic nie jest nigdy usuwane — księga tylko dopisuje, więc zwrot to wpis korygujący odwołujący się do oryginału, a nie wymazanie. Tu żyją konta, salda i blokady autoryzacyjne. Podobnie KYC i onboarding, wydawanie kart i rozliczenia oraz kanały krypto i stablecoinów. Za nimi stoi jedna konsola operatora, w której każda uprzywilejowana akcja wymaga podania powodu i trafia do dziennika audytu.

Każdego z tych elementów jest dokładnie jeden i na tym polega sens. Rozliczenia, uzgadnianie i compliance trudno zrobić dobrze, a błędy są drogie, więc buduje się je raz i pozwala każdej aplikacji odziedziczyć wynik. Gdy tenant onboarduje klienta, poziom KYC ustalony przez rdzeń trafia za nim do konsoli, niezależnie od tego, ekrany której aplikacji zebrały dokumenty. Rdzeń nie wie, jak nazywa się aplikacja nad nim, i nie ma to dla niego znaczenia — widzi konta i wpisy, nie marki.

Co się zmienia: język designu, architektura informacji, zestaw funkcji

Wszystko powyżej rdzenia może się swobodnie zmieniać, w trzech wymiarach. Pierwszy to język designu: kolor, typografia, promień zaokrągleń, odstępy, ruch — wizualna gramatyka marki. Drugi to architektura informacji: co jest na ekranie głównym, jak nazwane i uporządkowane są przepływy, która akcja jest o jedno dotknięcie stąd, a która o trzy. Trzeci to zestaw funkcji: które moduły w ogóle są włączone. Lekka aplikacja do przelewów i gęsta super-aplikacja mogą działać na identycznym rdzeniu i nie mieć ani jednego wspólnego ekranu.

Strona produktu /products/pay pokazuje pięć gotowych kierunków i najlepiej czytać je jako przykłady z nieskończenie wielu, a nie menu z pięciu pozycji. Halcyon to czysta giełda — powściągliwa, z niewieloma ekranami, z transakcją na pierwszym planie. Lumen to super-aplikacja, w której pieniądze przepływają w rozmowie, a płatności w czacie, subskrypcje i earn dzielą ekran główny. Fern stawia na przelewy — najpierw wypłaty zbiorcze i konwersja FX oparta na regułach. Volt to ciemna konstrukcja oparta na stablecoinach z sorterem wypłaty i kartami zespołowymi. Meridian jest wielowalutowy: konto w EUR obok USDC, podróżne saldo w GBP i konto BTC, na które trafiają nagrody za kartę. Pięć marek, pięć architektur informacji, pięć zestawów funkcji — pod spodem jedna księga, jedno KYC, jeden procesor kart.

Nic z tego nie oznacza, że produkt to pięć aplikacji. Tych pięć to kierunki, w które może pójść ten sam potok; liczy się nie pięć, tylko tylu tenantów, ilu uda ci się wdrożyć. Każdy z nich dowodzi, że front może się różnić aż po kształt ekranu głównego, a rdzeń pod nim tego nawet nie zauważa.

Rdzenia nie wolno wymyślać na nowo; aplikacji nie wolno ograniczać. Platforma whitelabel to dyscyplina utrzymywania obu tych zdań jednocześnie prawdziwymi.

Dlaczego theming na poziomie tokenów bije forkowanie kodu

Są dwa sposoby, by jeden produkt wyglądał jak wiele. Oczywisty to fork: skopiować kod dla każdego klienta, zmienić wygląd, wypuścić. Działa przez dokładnie jedno wydanie. Potem każdą poprawkę błędu i każdą zmianę regulacyjną trzeba nanosić N razy na N rozjeżdżających się kopii, kopie tracą synchronizację, a powierzchnia bezpieczeństwa, którą trzeba ogarnąć, rośnie razy liczba klientów. Fork zamienia jeden system, który rozumiesz, w wiele takich, których nie rozumiesz.

Theming na poziomie tokenów odwraca ten układ. Jest jedna baza kodu. Marka to zestaw wartości — tokeny koloru, typografii, promienia i odstępów; konfiguracja komponentów; zestaw feature flag — rozwiązywany w czasie budowania do aplikacji z własną marką. Zmień token, a każdy ekran, który z niego korzysta, zmienia się razem z nim, bo żadna wartość, która powinna pochodzić z tokenu, nie jest zahardkodowana. Poprawka przepływu przelewu trafia do wszystkich tenantów naraz, bo jest tylko jeden przepływ przelewu do poprawienia. Marki różnią się konfiguracją, nie kodem źródłowym.

Gdzie w tym wszystkim jest system designu

Tokeny to nie luźny pomysł, tylko dostarczany artefakt. Protocore Design System — /products/pds — to 144 tokeny designu i 889 klas utility: słownik, w którym motywowana jest każda aplikacja. Jest dark-first, oparty na tokenach i domyślnie z zerowym promieniem zaokrągleń, a ten sam zestaw tokenów jest generowany dla weba, .NET i natywnych platform, więc kolor zdefiniowany raz jest tym samym kolorem na ekranie w React, w konsoli desktopowej i w natywnej aplikacji mobilnej. Marka tenanta to nadpisania względem tego słownika, dlatego zmiana skórki aplikacji to zmiana konfiguracji, a nie przepisywanie.

To także sprawia, że front jest naprawdę swobodny, a nie tylko swobodny w ramach szablonu. Ponieważ język designu żyje w tokenach i klasach utility, a nie w jednorazowych arkuszach stylów, projektant może odsunąć tenanta daleko od wersji referencyjnej — własna paleta, typografia, gęstość i rytm — bez dotykania rdzenia i bez forkowania aplikacji. Farba sięga głęboko, ale to wciąż tylko farba; instalacja pod nią jest wspólna.

Aplikacja to konfiguracja, nie build

Zestaw funkcji podlega tej samej zasadzie. Każdy moduł — płatności w czacie, earn, krypto, karty, subskrypcje, karty zespołowe, polecenia — to przełącznik ustawiany per tenant, a flagę można najpierw włączyć dla części użytkowników, zanim trafi do wszystkich. Operatorzy przełączają je w panelu konfiguracji, a nie przez deploy. Różnica między prostą aplikacją do przelewów a pełną super-aplikacją to więc nie dwa projekty, tylko dwie konfiguracje jednego projektu. Aplikacja referencyjna, od której startuje każdy tenant, to neutralny build z marką Protocore i całym menu funkcji — każdy whitelabel to ten build z nadpisanymi tokenami i włączonymi lub wyłączonymi modułami.

Uczciwa granica

Jeden rdzeń, wiele aplikacji wymaga całej tej maszynerii tylko wtedy, gdy naprawdę masz wiele aplikacji — albo jedną, którą zamierzasz z czasem zmieniać wizualnie, przestawiać i zawężać lub poszerzać bez przebudowy banku za każdym razem. Jeśli wypuszczasz jedną stałą aplikację, która nigdy nie przyjmie drugiej marki, nie potrzebujesz platformy whitelabel; potrzebujesz aplikacji. Zwraca się ona w przypadku, do którego została zbudowana: platforma uruchamia kolejne produkty bankowe z własną marką, tenant po tenancie, każdy wyraźnie swój i żaden nie jest forkiem. Pełny rozbiór — pięć kierunków, aplikacja referencyjna i konsola operatora za nimi — jest pod /products/pay, a system designu pod spodem pod /products/pds.