Kako dizajnirati KYC red za pregled koji se skalira

KYC red za pregled je back-office tok rada u kojem se provjere identiteta koje mašina nije mogla sama riješiti stavljaju pred čovjeka. Većina prijava treba proći automatski; red postoji za one koje ne prođu. Cijeli cilj dizajna je da ostane mali — da drži stvarnu nejasnoću i ništa drugo — jer red koji se puni slučajevima o kojima je mašina trebala odlučiti nije kontrola, nego usko grlo koje raste linearno s brojem registracija. Ako red dobro postavite, back office se skalira s izuzecima, a ne s obimom.

To jedno svojstvo — namjerno mali red — određuje svaku sljedeću odluku. Počnite od podjele koja ga takvim održava.

Straight-through je cilj, red je izuzetak

Straight-through processing (STP) znači da se prijava rješava od početka do kraja bez ljudskog dodira: dokumenti pročitani, identitet uparen, provjera sankcija i PEP lista čista, liveness prošao, odluka zabilježena. To treba biti uobičajen put, a udio prijava koje njime prođu — STP stopa — jedini je broj koji govori hoće li se red skalirati. Ako se devedesetak posto riješi automatski, ljudski red je podnošljiv mlaz; ako polovina ispadne na pregled, zapošljavate pregledače u koraku s rastom. Red nije mjesto gdje se KYC odvija. To je mjesto gdje automatizirani KYC priznaje da nije siguran. Podignite STP stopu i svaki drugi broj se poboljša sam od sebe: manje slučajeva u redu, kraća čekanja, manje pregledača za zapošljavanje. Vrijedi je napasti direktno — bolje snimanje dokumenata u klijentu, jasnije upute prije slikanja, pragovi uparivanja podešeni tako da pravi korisnici ne ispadaju zbog previše oprezog pravila — jer je svaki vraćeni postotni poen slučaj koji nikada neće postati nečije poslijepodne.

Šta završava u redu i zašto

Slučajevi ispadaju na pregled iz konkretnih razloga koji se mogu imenovati, a razlog je najvažniji atribut koji slučaj nosi. Fotografija dokumenta je previše mutna za čitanje. Ime na ličnoj karti ne odgovara imenu u prijavi. Provjera sankcija ili PEP lista vratila je mogući pogodak koji čovjek treba potvrditi ili odbaciti. Adresa se ne može provjeriti ni u jednom izvoru. Liveness provjera nije prošla, ili isto lice ili dokument već postoji na drugom računu. Svako od toga je drugačija vrsta posla koja traži drugačiju vrstu procjene — a trpanje svega u jednu nediferenciranu hrpu prva je greška koju red za pregled pravi. Uz to, isti razlog može imati veoma različitu težinu: nepodudaranje imena može biti bezazlena razlika zbog promjene prezimena udajom ili prvi znak ukradenog identiteta, a posao reda je da ga usmjeri nekome ko zna razlikovati jedno od drugog, umjesto da prisili na brzu presudu slučaj koji zaslužuje pažljivu.

Jedan red nije dovoljan: segmentirajte po razlogu

Jedan red tjera svakog pregledača da bude generalist, a svaki slučaj da čeka iza nepovezanih. Segmentiranje po razlogu rješava oba problema. Red mogućih podudaranja sa sankcijama obrađuju ljudi obučeni za screening i dispoziciju; red kvalitete dokumenata je brza vizualna provjera koju junior pregledač riješi za nekoliko sekundi; red duplih računa je istraga prevare. Svaki segment dobija vlastito usmjeravanje, vlastitu potrebnu vještinu i vlastiti cilj nivoa usluge (SLA), jer mutnu fotografiju treba riješiti u minutama, dok pravi pogodak na sankcijama zaslužuje pažljivu, neurednu dispoziciju bez žurbe. Segmentacija je ono što omogućava da propusnost i rigoroznost koegzistiraju umjesto da se međusobno žrtvuju.

Red za pregled se ne skalira zapošljavanjem novih analitičara. Skalira se tako što se ispravno odluči koji slučajevi uopće nisu trebali u njega — i što oni koji jesu stignu već razvrstani po razlogu.

Radnje koje zahtijevaju razlog i bilježe se u reviziji

Svaka odluka analitičara — odobravanje, odbijanje, eskalacija, traženje dodatnih dokumenata — mora imati razlog i mora biti zabilježena. Ne kao slobodan tekst naknadno dopisan, nego kao strukturiran izbor koji kaže zašto je radnja poduzeta, zabilježen u trenutku kad je poduzeta. To nije birokratija; to je ono što red čini odbranjivim. Kad regulator, revizor ili kasniji analitičar pita zašto je račun odobren uprkos oznaci, odgovor je imenovani analitičar, vremenska oznaka i navedeni razlog — a ne slijeganje ramenima. Revizijski trag je samo za dodavanje (append-only), pa se odluka ne može neprimijetno prepraviti naknadno; ispravke su novi unosi, a ne izmjene starih. U našem stacku ovaj red i njegov model revizije žive u Protocore Center (/products/center), operatorskoj konzoli u kojoj svaka privilegovana radnja zahtijeva razlog i završava u logu koji se ne može neprimijetno izmijeniti.

Slučajevi za četiri oka

Neke odluke su preznačajne za jednu osobu. Brisanje stvarnog pogotka na listi sankcija, odobravanje visokorizičnog profila ili poništavanje automatskog odbijanja trebaju zahtijevati potvrdu drugog analitičara — maker-checker, odnosno princip četiri oka. Prvi analitičar predlaže i navodi razlog; drugi, s ovlaštenjem za to, potvrđuje ili odbija i navodi svoj. Obje radnje se bilježe. To nije nepovjerenje prema analitičarima; to je priznanje da su upravo najrizičnija odobrenja ona kod kojih je jedna greška najskuplja, a drugi par očiju je najjeftinije osiguranje od nje. Dizajn reda treba te slučajeve automatski usmjeravati na dvostepenu odluku, prema razlogu, umjesto da se oslanja na to da će ih analitičari zapamtiti. Dvostepeni postupak ipak namjerno čuvajte za značajne slučajeve; ako ga primijenite na sve, udvostručujete trošak cijelog reda i učite analitičare da drugi potpis odrađuju mehanički, čime se tiho gubi smisao njegovog postojanja.

Dizajn za velike količine: starenje, prioritizacija, SLA

Red koji samo raste je red koji je zakazao. Ugradite pritisak koji ga drži u kretanju. Slučajevi vidljivo stare, pa ništa ne ostane zaboravljeno; svaki segment ima ciljni nivo usluge, pa slučaj sa mutnom fotografijom koji probija svoj SLA od nekoliko minuta izlazi na površinu drugačije od slučaja sankcija unutar svog dužeg roka. Prioritizacija je stvarni izbor: najstariji-prvi je pošteno i jednostavno, ali prvo-rizik — najveća potencijalna izloženost na vrhu — često je ispravan potez, uz starenje kao kriterij za izjednačenje, tako da se i slučajevi niskog rizika riješe umjesto da zastanu. Ekran analitičara treba prikazati sljedeći slučaj, već usmjeren i prioritiziran, a ne listu iz koje se bira — jer red kroz koji ljudi biraju je red u kojem se nezgodni slučajevi nikad ne izaberu. Red bez vidljivog starenja tiho trune: teški slučajevi tonu na dno dok se laki vrte na vrhu, a jedina metrika koja bi to otkrila — starost najstarijeg otvorenog slučaja — upravo je broj koji niko ne prati dok se klijent ne požali.

Mjerenje reda

Četiri broja govore radi li dizajn. STP stopa pokazuje koliko slučajeva uopće nije trebalo čovjeka; dubina reda i njegov trend pokazuju stižete li ili zaostajete; vrijeme do odluke, praćeno po segmentu u odnosu na njegov SLA, pokazuje čekaju li klijenti predugo na registraciju; a stopa ponovnog otvaranja — odluke koje su kasnije poništene — pokazuje odlučuju li analitičari ispravno ili samo brzo. Pratite ih zajedno, jer se međusobno poništavaju: ako vrijeme do odluke pada dok stopa ponovnog otvaranja raste, brzinu ste kupili greškama. Zdrav red je mali, u kretanju, ispravno odlučen i iskren o slučajevima koji su u njemu još otvoreni.

Back office kakav ljudi zamišljaju — sobe pune osoblja koje unosi prijave — dobije se kad automatizacija riješi premalo, a red je jedna neizdiferencirana gomila. Back office koji se skalira je obrnut: većina prijava nikad ne stigne do čovjeka, one koje stignu dolaze razvrstane po razlogu i prioritetu, svaka radnja nosi razlog u append-only log, a četiri oka čuvaju odluke koje to zaslužuju. Izgradite red za izuzetke i ostat će mali dok rastete. Izgradite ga kao mjesto na kojem se događa KYC i rast će sa svakom registracijom koju primite.