Platformas arhitektūra

Viens kodols, daudz virsmu — kā platforma patiesībā darbojas.

Ceļojums pa platformu no virsgrāmatas uz augšu: konti, KYC, kartes un kripto, kas visi balstās uz vienu dubultā ieraksta kodolu; kā viens maksājums iet no izveides līdz saskaņošanai; un kur atrodas lietotņu slānis, operatoru konsole un regulētā robeža.

Sazinieties ar mums Skatīt produktus

Kodols

Viena virsgrāmata zem visa.

Platformas centrā ir vienota kontu virsgrāmata. Katrs konts — klienta maks, tirgotāja atlikums, komisijas konts, norēķinu konts — ir šīs virsgrāmatas mezgls, un katra vērtības kustība ir dubultā ieraksta grāmatojums: viens konts tiek debetēts, cits kreditēts, un abas puses vienmēr ir vienādas. Virsgrāmata ir tikai papildināma. Ieraksti nekad netiek laboti vai dzēsti; labojums ir jauns pretējs ieraksts, tāpēc pilnu vēsturi, kā atlikums sasniedzis pašreizējo vērtību, vienmēr var atjaunot. Konti, KYC statuss, izdotās kartes un kripto adreses ir piesaistīti vienam un tam pašam kontu modelim. Tāpēc kartes autorizācija, bankas pārskaitījums un ieskaitījums blokķēdē var tikt grāmatoti uz vienu atlikumu, un atsevišķas sistēmas nav jāsaista kopā ar saskaņošanas slāni.

01Dubultais ieraksts: katrs grāmatojums sabalansēts, debets vienāds ar kredītu
02Tikai papildināma: labojumi ir jauni ieraksti, nevis izmaiņas
03Viens kontu modelis fiat, kartēm un kripto
04KYC statuss ceļo kopā ar kontu, nevis atsevišķā tabulā

Maksājums no gala līdz galam

Viens maksājums, no izveides līdz saskaņošanai.

Maksājums nav viens izsaukums, bet īss dzīves cikls, un katrs posms ir stāvoklis, ko redz gan virsgrāmata, gan jūsu sistēmas. Katra stāvokļa izmaiņa izsūta webhook, un katrs rakstīšanas izsaukums ir idempotents — viena atslēga atkārtoti dod to pašu rezultātu, tāpēc atkārtots pieprasījums nekad netērē divreiz.

01
Izveide
Tiek atvērts nodoms: summa, valūta, iesaistītie konti. Vēl nekas nav pārvietots — virsgrāmata reģistrē gaidošu ierakstu.
02
Autorizācija
Kanāls pārbauda līdzekļus un risku un uzliek rezervējumu. Kartei tā ir autorizācija; pārskaitījumam debets tiek rezervēts.
03
Norakstīšana
Rezervētā summa tiek apstiprināta. Virsgrāmata grāmato dubultā ieraksta, kas faktiski pārvieto vērtību starp abiem kontiem.
04
Norēķini
Līdzekļi tiek izmaksāti caur pamatā esošo kanālu — karšu shēmu, banku vai blokķēdi — un norēķinu konti saskaņojas ar īstu naudu.
05
Saskaņošana
Platforma salīdzina savus grāmatojumus ar kanāla norēķinu pārskatu; viss, kas nesakrīt, tiek atzīmēts, nevis noslēpts.

Webhooks un idempotence ir katrā šīs plūsmas malā. Jūsu sistēmas uzzina, ka maksājums ir veikts, saņemot notikumu, nevis pārjautājot, un jebkurš pieprasījums, ko atkārtojat pēc noildzes, ar savu idempotences atslēgu dod to pašu rezultātu, tāpēc atkārtojums nekad netērē divreiz. Pakalpojums, kas izpilda autorizāciju un norakstīšanu, ir maksājumu vārteja.

Lietotņu slānis

Augšā whitelabel lietotnes, apakšā viena platforma.

Kodols piedāvā iespējas, bet lietotņu slānis pārvērš tās produktos. Katra klientu lietotne — tīmekļa un mobilā — ir whitelabel klients, kas rāda tos pašus kontus, maksājumus un kartes ar savu zīmolu. Tēmas veidošana balstās uz dizaina tokeniem: krāsas, tipogrāfija, rādiuss un atstarpes nāk no dizaina tokenu sistēmas (PDS), tāpēc operators visu virsmu pārveido, mainot tokenus, nevis veidojot lietotnes atzarojumu. Vienu platformu var virzīt ļoti dažādos virzienos — patērētāju neobanka, tirgotāju acquiring lietotne, karšu izdošanas programma, kripto on/off-ramp vai iekšējs operāciju rīks —, nekļūstot par piecpadsmit atsevišķiem produktiem. Tā ir viena platforma dažādos tērpos, katra konfigurēta, nevis uzbūvēta no jauna.

01Whitelabel tīmekļa un mobilie klienti uz kopīgiem API
02Tokenu vadīta tēmu veidošana (PDS): pārveido ar konfigurāciju, nevis atzarojumu
03Pieci piemēru virzieni — neobanka, acquiring, karšu izdošana, ramp, operācijas
04Jaunas virsmas tiek konfigurētas, nevis būvētas no jauna

Operācijas

Vadiet no konsoles, ar pamatojumu protokolā.

Aiz katras lietotnes ir operatoru konsole. Tur atbalsta aģents atrod kontu, riska analītiķis iesaldē karti, bet operāciju vadītājs atceļ grāmatojumu. Lasīšanas piekļuve ir plaša, privileģētas darbības — nē. Jebkurai darbībai, kas pārvieto naudu, maina limitus vai skar klienta līdzekļus, pirms izpildes jānorāda pamatojums, un tā ieraksta nemainīgu audita ierakstu: kas rīkojās, ar ko, kad un kāpēc. Piekļuve seko mazāko privilēģiju principam, tāpēc katrs operators redz un dara tikai to, ko atļauj viņa loma. Šis ir modelis Protocore Center, operatoru konsolē, un tāda pati pieeja ir iebūvēta katrā platformas sistēmā: jutīgas darbības ir apzinātas, piešķiramas konkrētai personai un pārskatāmas arī pēc fakta.

01Plaša lasīšana, ierobežota rakstīšana — privileģētas darbības ir izņēmums
02Pamatojums obligāts pirms jebkuras darbības ar līdzekļiem
03Nemainīgs audita pēdu žurnāls: kas, ko, kad, kāpēc
04Mazākās privilēģijas katrai operatora lomai

Kripto tilts

Kripto un fiat vienā virsgrāmatā.

Platformā kripto nav atsevišķs siloss; kripto adrese ir vienkārši vēl viens konts tajā pašā virsgrāmatā. On/off-ramp konvertē starp fiat un digitālajiem aktīviem pie malas: klients papildina atlikumu ar karti vai pārskaitījumu un saņem kripto, vai pārdod kripto un izņem līdzekļus uz bankas kontu. Vērtība blokķēdē var norēķināties līdz pat bankas kanālam: ienākošais maksājums blokķēdē tiek ieskaitīts kontā, konvertēts un izmaksāts uz IBAN, tāpēc saņēmējs redz parastu naudu parastā bankas kontā. Tā kā abi posmi tiek grāmatoti vienā dubultā ieraksta virsgrāmatā, kustība, kas sākas blokķēdē un beidzas ar bankas pārskaitījumu, ir viena saskaņota vēsture, nevis divas sistēmas, kas jāsaskaņo ar roku.

01Kripto adrese ir tāds pats konts kā jebkurš cits
02On/off-ramp: fiat un digitālie aktīvi tiek konvertēti pie malas
03Norēķini blokķēdē līdz pat izmaksai uz IBAN
04Viena saskaņota vēsture abos posmos

Izstrādes virsma

API, webhooks un sandbox, pret ko būvēt.

Visu, ko dara lietotnes, tās dara, izmantojot dokumentētu API — izveidot kontu, atvērt maksājumu, izdot karti, sākt ramp. Ilustratīvi izsaukumi izskatās šādi: POST /v1/wallets vai POST /v1/payments; forma ir REST ar idempotences atslēgu katram rakstīšanas izsaukumam. Stāvokļa izmaiņas tiek piegādātas kā webhooks, tāpēc jūsu sistēmas reaģē uz notikumiem, nevis tos pastāvīgi pārjautā. Izstrāde notiek pret sandbox tenantu — izolētu platformas kopiju ar testa kanāliem, kur var izpildīt pilnu plūsmu no izveides līdz saskaņošanai, nepārvietojot īstu naudu. Ko katrs produkts jums piedāvā un kādā līmenī, nosaka tā piekļuves josla; produktu lapās ir precīzi aprakstīts, ko iekļauj katra josla.

01Dokumentēta REST API, idempotenti rakstīšanas izsaukumi
02Webhooks katrai stāvokļa izmaiņai — notikumu vadīti, bez pārjautāšanas
03Sandbox tenants ar testa kanāliem, izolēts no produkcijas
04Apjomu un limitus nosaka katra produkta piekļuves joslas

Godīgā robeža

Protocore būvē programmatūru. Licence tur regulēto robežu.

Maksājumu produkts ir divas savienotas lietas: regulēta atļauja turēt un pārvietot naudu un programmatūra, kas to uzdod, reģistrē un saskaņo. Protocore būvē programmatūru. Regulētā darbība — klientu līdzekļu turēšana, kontu izsniegšana, naudas pārvietošana pa shēmu — ir operatora paša licences vai licencēta partnera pārziņā: bankas, EMI vai maksājumu iestādes. Platforma ir veidota, lai iekļautos jebkuros regulētajos kanālos, ko jūs atvedat, un lai kartes dati paliktu kanālā un nekad nenonāktu jūsu serveros; tā nav un neviena programmatūra nav šīs atļaujas aizstājēja. Kur iet regulētā robeža, jūs izlemjat kopā ar partneri, un arhitektūra ir veidota tā, lai tīri iederētos jebkurā tās pusē.