Usklađenost kao dio sustava, a ne kontrolna točka

U reguliranim industrijama usklađenost s propisima standardni je razlog zašto se ništa ne modernizira. Svaki prijedlog zapne kod pravnika, softver ostane star, a oko njega se gomilaju zaobilazna rješenja.

Kad smo za fintech startup radili KYB platformu — provjeru poslovnih kupaca prije odobrenja odgode plaćanja — naučili smo suprotno. UK GDPR, britanski propisi o sprječavanju pranja novca (MLR) i PSD2 traže puno, ali sve što traže negdje piše, mijenja se sporo i jednako vrijedi za svakog konkurenta. Zahtjev koji možete pročitati zapravo je specifikacija. Ostatak ovog teksta govori o tome što se dogodi kad ga tako i tretirate.

Odluka zbog koje platforma postoji

Svaki ekran u rješenju služi jednom pitanju: smije li ovaj kupac dobiti odgodu plaćanja? Da bismo na njega odgovorili, podaci se povlače iz poslovnih registara, kreditnih agencija, lista sankcija, provjere PDV broja i Open Bankinga. Pet izvora, a nijedna se dva ne slažu ni oko formata, ni oko brzine odgovora, ni oko toga koliko su često dostupna.

• Svaki izvor stoji iza adaptera koji vraća isti oblik podataka; kod koji računa ocjenu nikad ne vidi odgovor u formatu pojedinog pružatelja
• Svaka provjera je idempotentan korak u trajnom workflowu: istekne li vrijeme kod kreditne agencije, ponavlja se samo taj korak, a ne cijeli postupak od registra
• Ocjena je ponderirana, a uz rezultat se spremaju i težine, ulazni podaci i vrijeme dohvata — pa se odluka može objasniti i mjesecima kasnije, što MLR upravo i traži
• Ispad jednog pružatelja smanjuje pouzdanost ocjene, ali ne ruši platformu

Odluke koje su zbog propisa ispale bolje

Svaka od ovih odluka počela je kao obveza, a završila kao bolje rješenje od onoga koje bismo sami odabrali.

• Envelope encryption s ključem po klijentu ispod upravljanog glavnog ključa: brisanje po GDPR-u svodi se na uništavanje ključa, umjesto na traženje podataka po bazi i svim njezinim sigurnosnim kopijama
• Passkeyji i potpisane sesije bez stanja na serveru: nema lozinke koja može iscuriti, nema površine za phishing i nema tablice sesija koju treba sinkronizirati između instanci
• STRIDE analiza prijetnji prije prve linije koda: put prijave napadaču ne odaje ništa, pa ni vremenom odgovora
• Strog Content Security Policy od prvog dana; naknadno ga uvesti u rješenje puno inline skripti košta višestruko

Jedan klijent, jedna granica štete

Platforma je multi-tenant, a u fintechu je to prije svega pitanje usklađenosti, pa tek onda arhitekture sustava: curenje podataka između dva klijenta nije propust jednog računa, nego cijele tvrtke.

• Ograničenje na klijenta provodi se u podatkovnom sloju, a ne u svakom handleru posebno; upit bez klijenta greška je koju kod ne može ni izraziti
• Na svakom buildu vrti se skup testova koji namjerno pokušava čitati podatke tuđeg klijenta i mora pasti
• Ključ po klijentu znači da kompromitirani ključ pogađa jednog klijenta, a nikad sve korisnike

Jamstva idu u pipeline

SOC 2 Type 1 spremnost postala je izvediva tek kad smo jamstva izvukli iz dokumenata i prebacili u CI: integracijski testovi vrte se nad pravim branchevima baze, arhitektonska pravila provjeravaju se na svakom buildu, a cijelo se okruženje podiže iz koda — bez ručno složene infrastrukture i bez pohranjenih tajni. Revizoru koji može pročitati pipeline treba puno manje sastanaka.

Kontrola koju build može provjeriti preživi promjene u timu, pritisak rokova i petak popodne. Ona koja postoji samo u dokumentu ne preživi ništa od toga.

Ako vaš posao oko usklađenosti završava u PDF-u, napisali ste specifikaciju. Sad je treba i izgraditi.