Një core, shumë aplikacione: si funksionon një platformë bankare whitelabel

Një platformë bankare whitelabel është një core bankar me front-end të zëvendësueshëm. Core-i është pjesa që duhet të jetë e saktë: libri kontabël me shënim të dyfishtë, llogaritë e klientëve, KYC dhe onboarding, lëshimi dhe përpunimi i kartave, rail-et e kriptos dhe stablecoin-eve, dhe konsola e operatorit që punon pas gjithë kësaj. Aplikacioni është pjesa që sheh klienti — emri, ngjyrat, forma e ekraneve, nëngrupi i veçorive që aktivizon. Whitelabel do të thotë që një core mund të veshë shumë fytyra pa u rindërtuar nën secilën. Një core, shumë aplikacione.

Thënë thjesht, kjo është një pretendim për vendin ku qëndrojnë tegelat. Gjithçka që prek paratë është e përbashkët, e audituar dhe e rakorduar një herë; gjithçka që prek klientin konfigurohet për çdo tenant. Inxhinieria që ka rëndësi është ta mbash këtë vijë të ndershme — ta lësh front-end-in të ndryshojë lirisht ndërsa core-i mbi të cilin qëndron nuk forkohet kurrë. Ky është një përshkrim i hollësishëm se si hiqet vija dhe pse heqja e saj me tokena dizajni e mund heqjen me fork.

Çfarë nuk ndryshon kurrë: core-i

Nisim me gjysmën që nuk ka të drejtë të jetë krijuese. Një transfertë regjistrohet njësoj, pavarësisht nëse aplikacioni e quan dërgim, pagesë apo pagesë grupi: dy shënime në një libër me shënim të dyfishtë, dhe asgjë nuk fshihet kurrë — libri vetëm shton, ndaj një rimbursim është një shënim kundërshtues që i referohet origjinalit, jo një fshirje. Llogaritë, bilancet dhe bllokimet e autorizimit jetojnë këtu. Po ashtu KYC dhe onboarding, lëshimi dhe shlyerja e kartave, si dhe rail-et e kriptos dhe stablecoin-eve. Pas tyre qëndron një konsolë operatori ku çdo veprim i privilegjuar kërkon arsye dhe ruhet në një regjistër auditimi.

Nga secila prej tyre ka saktësisht një, dhe kjo është pika. Shlyerja, rakordimi dhe pajtueshmëria janë të vështira për t'u bërë mirë dhe të shtrenjta për t'u bërë keq, prandaj i ndërton një herë dhe lë çdo aplikacion ta trashëgojë rezultatin. Kur një tenant regjistron një klient, niveli KYC që vendos core-i e ndjek klientin në konsolë, pavarësisht se ekranet e cilit aplikacion i kapën dokumentet. Core-i nuk e di dhe nuk i intereson si quhet aplikacioni sipër — ai sheh llogari dhe shënime, jo marka.

Çfarë ndryshon: gjuha e dizajnit, arkitektura e informacionit, përzierja e veçorive

Gjithçka mbi core-in është e lirë të lëvizë, sipas tre boshteve. I pari është gjuha e dizajnit: ngjyra, tipografia, rrezja e këndeve, hapësirat, lëvizja — gramatika vizuale e markës. I dyti është arkitektura e informacionit: çfarë qëndron në ekranin kryesor, si emërtohen dhe renditen rrjedhat, cili veprim është një prekje larg dhe cili tri. I treti është përzierja e veçorive: cilat module aktivizohen fare. Një aplikacion i hollë transfertash dhe një super-aplikacion i dendur mund të punojnë mbi të njëjtin core pa ndarë asnjë ekran.

Faqja e produktit te /products/pay përshkruan pesë drejtime të punuara, dhe lexohen më mirë si shembuj nga pafundësia sesa si menu me pesë zgjedhje. Halcyon është një exchange i pastër — i përmbajtur, me pak sipërfaqe, me tregtimin në plan të parë. Lumen është një super-aplikacion ku paratë lëvizin brenda bisedës, dhe pagesat në chat, abonimet dhe earn ndajnë ekranin kryesor. Fern prin me transferta — fillimisht pagesa grupi dhe konvertim FX me rregulla. Volt është një ndërtim stablecoin në temë të errët, me ndarës rrogash dhe karta ekipi. Meridian është shumëvalutor: një llogari EUR pranë USDC, një bilanc udhëtimi në GBP dhe një llogari BTC ku mbërrijnë shpërblimet e kartës. Pesë marka, pesë arkitektura informacioni, pesë përzierje veçorish — një libër kontabël, një KYC, një procesor kartash poshtë tyre.

Asnjëra nga këto nuk do të thotë se produkti është pesë aplikacione. Të pesë janë drejtime që mund t'i marrë i njëjti pipeline; numri që ka rëndësi nuk është pesë, por sa tenantë regjistroni. Secili është provë që front-end-i mund të ndryshojë deri te forma e ekranit kryesor, ndërsa core-i poshtë tij nuk e vëren kurrë.

Core-i është pjesa që nuk ke të drejtë ta rizbulosh; aplikacioni është pjesa që nuk ke të drejtë ta kufizosh. Një platformë whitelabel është disiplina e mbajtjes njëkohësisht të vërtetë të të dyja këtyre fjalive.

Pse tema në nivel tokeni e mund forkimin e kodit

Ka dy mënyra për ta bërë një produkt të duket si shumë. E dukshmja është forkimi: kopjon kodin për çdo klient, e ristilizon, e publikon. Funksionon për saktësisht një version. Pas tij, çdo korrigjim gabimi dhe çdo ndryshim rregullator duhet zbatuar N herë në N kopje që largohen nga njëra-tjetra, kopjet dalin nga sinkronizimi, dhe sipërfaqja e sigurisë që duhet të kontrollosh shumëzohet me numrin e klientëve. Forkimi e kthen një sistem që e kupton në shumë që nuk i kupton.

Tema në nivel tokeni e përmbys këtë. Ka një bazë kodi. Një markë është një bashkësi vlerash — tokena për ngjyrën, shkronjat, rrezen dhe hapësirat; një konfigurim komponentësh; një bashkësi feature flag-esh — të zgjidhura gjatë build-it në një aplikacion me markë. Ndryshon një token dhe çdo ekran që e lexon lëviz bashkë, sepse asgjë nuk e fut me dorë vlerën që duhet ta marrë nga një token. Një korrigjim i rrjedhës së transfertave arrin te çdo tenant njëherësh, sepse ka vetëm një rrjedhë transfertash për t'u korrigjuar. Markat ndryshojnë në konfigurim, jo në kod burimor.

Ku qëndron sistemi i dizajnit

Tokenat nuk janë një ide e shkëputur; janë një artefakt i publikuar. Protocore Design System — /products/pds — është 144 tokena dizajni dhe 889 klasa utility: fjalori në të cilin tematizohet çdo aplikacion. Është dark-first, i drejtuar nga tokenat dhe me rreze zero si parazgjedhje, dhe i njëjti set tokenash prodhohet për web, .NET dhe native, kështu që një ngjyrë e përcaktuar një herë do të thotë e njëjta ngjyrë në një ekran React, në një konsolë desktop dhe në një build native mobile. Marka e një tenanti shprehet si mbishkrime mbi atë fjalor, prandaj ndryshimi i pamjes së një aplikacioni është ndryshim konfigurimi dhe jo rishkrim.

Kjo është edhe ajo që e bën front-end-in vërtet të lirë dhe jo të lirë brenda një shablloni. Sepse gjuha e dizajnit jeton në tokena dhe klasa utility në vend të fletëstileve të veçanta, një dizajner mund ta largojë një tenant larg nga ndërtimi i referencës — me paletën, shkronjat, dendësinë dhe ritmin e vet — pa prekur core-in dhe pa forkuar aplikacionin. Bojatisja shkon thellë, por mbetet vetëm bojë; instalimet poshtë saj janë të përbashkëta.

Aplikacioni është konfigurim, jo build

Përzierja e veçorive ndjek të njëjtin rregull. Çdo modul — pagesat në chat, earn, kripto, kartat, abonimet, kartat e ekipit, referimet — është një çelës që ndizet për çdo tenant, dhe një flag mund të hapet fillimisht për një pjesë të përdoruesve para se të shkojë gjerësisht. Operatorët i ndërrojnë nga një panel konfigurimi, jo nga një deploy. Pra dallimi mes një aplikacioni të thjeshtë transfertash dhe një super-aplikacioni të plotë nuk janë dy projekte; janë dy konfigurime të një projekti. Aplikacioni i referencës nga i cili niset çdo tenant është një build neutral me markën Protocore, me gjithë menunë të pranishme — çdo whitelabel është ai build me tokena të mbishkruar dhe module të ndezura ose të fikura.

Kufiri i sinqertë

Një core, shumë aplikacione e vlen makinerinë vetëm kur ke vërtet shumë aplikacione — ose një aplikacion që synon ta ristilizosh, riorganizosh dhe rishtrosh me kalimin e kohës pa e rindërtuar bankën çdo herë. Nëse po publikon një aplikacion të vetëm e të fiksuar që nuk do të veshë kurrë markë të dytë, nuk të duhet një platformë whitelabel; të duhet një aplikacion. Ajo shpërblen aty ku u ndërtua: një platformë që ngre produkte bankare me markë tenant pas tenanti, secili dukshëm i veti, asnjëri fork. Përshkrimi i plotë — pesë drejtimet, aplikacioni i referencës dhe konsola e operatorit pas tyre — është te /products/pay, ndërsa sistemi i dizajnit poshtë tyre është te /products/pds.