Iz prakse

Kako dizajnirati KYC red za pregled koji se skalira

KYC red za pregled je back-office tok rada u kojem se provjere identiteta koje stroj nije mogao sam riješiti stavljaju pred čovjeka. Većina zahtjeva trebala bi proći automatski; red postoji za one koji ne prolaze. Cilj dizajna je da ostane malen — da drži stvarnu dvoznačnost i ništa drugo — jer red koji se puni slučajevima o kojima je stroj trebao odlučiti nije kontrola, nego usko grlo koje raste linearno s brojem registracija. Postavite red kako treba i back office raste s iznimkama, a ne s volumenom.

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

Straight-through je cilj, red je iznimka

Straight-through processing (STP) znači da se zahtjev rješava od početka do kraja bez ljudskog dodira: dokumenti pročitani, identitet usklađen, provjera sankcija i PEP-a čista, liveness prošao, odluka zabilježena. To treba biti uobičajeni put, a udio zahtjeva koji njime prolaze — 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 polovica ispadne na pregled, zapošljavate pregledavatelje u koraku s rastom. Red nije mjesto gdje se događa KYC. To je mjesto gdje automatizirani KYC priznaje da nije siguran. Podignite STP stopu i svi ostali brojevi se poboljšavaju sami od sebe: manje slučajeva u redu, kraća čekanja, manje pregledavatelja za zapošljavanje. Vrijedi se izravno pozabaviti time — boljim snimanjem dokumenata na klijentu, jasnijim uputama prije fotografiranja, pragovima podudaranja podešenima tako da se stvarni klijenti ne odbijaju prestrogim pravilom — jer je svaki vraćeni postotni bod slučaj koji nikad neće postati nečije poslijepodne.

Što završava u redu i zašto

Slučajevi ispadaju na pregled iz konkretnih razloga koji se mogu imenovati, a razlog je najvažnije obilježje koje slučaj nosi. Fotografija dokumenta preoštećena je da bi se pročitala. Ime na osobnoj ne odgovara imenu u zahtjevu. Provjera sankcija ili PEP-a vratila je mogući pogodak koji čovjek mora potvrditi ili odbaciti. Adresa se ne može potvrditi ni u jednom izvoru. Liveness provjera nije prošla, ili isto lice odnosno dokument već postoji na drugom računu. Svaki je od tih razloga drukčija vrsta posla koja traži drukčiju prosudbu — a trpati ih u jednu nediferenciranu hrpu prva je pogreška reda za pregled. Isti razlog može imati i vrlo različitu težinu: nepodudaranje imena može biti bezazlena razlika zbog prezimena po udaji ili prvi znak ukradenog identiteta, a zadatak reda je uputiti slučaj nekome tko zna razlikovati jedno od drugog, umjesto da se na slučaj koji zaslužuje pažnju na brzinu donese presuda.

Jedan red nije dovoljan: segmentirajte po razlogu

Jedan red tjera svakog pregledavatelja da bude generalist, a svaki slučaj da čeka iza nepovezanih. Segmentiranje po razlogu rješava oboje. Red mogućih podudaranja sa sankcijama rade ljudi obučeni za screening i donošenje odluka; red kvalitete dokumenata brza je vizualna provjera koju junior pregledavatelj riješi u nekoliko sekundi; red duplikata računa je istraga prijevare. Svaki segment dobiva vlastito usmjeravanje, vlastitu potrebnu vještinu i vlastiti cilj razine usluge, jer bi mutnu fotografiju trebalo riješiti za nekoliko minuta, dok pravi pogodak na sankcijskoj listi zaslužuje pažljivu, neurednu odluku bez žurbe. Segmentacija omogućuje da propusnost i temeljitost koegzistiraju umjesto da se međusobno žrtvuju.

Red za pregled ne skalira se zapošljavanjem analitičara. Skalira se tako da se ispravno odluči koji slučajevi uopće nisu trebali pregled — i da oni koji jesu stignu već razvrstani prema razlogu.
— Protocore · Operativni inženjering

Radnje s obveznim razlogom i revizijskim tragom

Svaka odluka analitičara — odobriti, odbiti, eskalirati, zatražiti dodatne dokumente — mora imati razlog i mora biti zabilježena. Ne kao slobodan tekst naknadno, nego kao strukturiran odabir koji kaže zašto je radnja poduzeta, zabilježen u trenutku kad je poduzeta. To nije birokracija; time red postaje obranjiv. Kad regulator, revizor ili kasniji analitičar upita zašto je račun odobren unatoč oznaci, odgovor je imenovani analitičar, vremenska oznaka i naveden razlog — a ne slijeganje ramenima. Revizijski trag je samo za dodavanje (append-only), pa se odluka ne može tiho prepisati naknadno; ispravci su novi zapisi, a ne izmjene preko starih. U našem stacku taj red i njegov revizijski model žive u Protocore Center (/products/center), operatorskoj konzoli u kojoj svaka privilegirana radnja zahtijeva razlog i završava u logu koji se ne može neprimjetno mijenjati.

Slučajevi za četiri oka

Neke su odluke previše važne za jednu osobu. Brisanje stvarnog pogotka na sankcijskoj listi, odobravanje visokorizičnog profila ili poništavanje automatskog odbijanja trebali bi zahtijevati potvrdu drugog analitičara — maker-checker, odnosno četiri oka. Prvi analitičar predlaže i navodi razlog; drugi, s ovlasti za to, potvrđuje ili odbija i navodi svoj. Obje radnje se bilježe. To nije nepovjerenje prema analitičarima; to je spoznaja da su najrizičnija odobrenja upravo ona kod kojih je jedna pogreška najskuplja, a drugi par očiju najjeftinije je osiguranje od nje. Dizajn reda trebao bi takve slučajeve automatski, prema razlogu, usmjeravati u dvostupanjsku odluku, umjesto da se oslanja na to da će se analitičari sjetiti. Dvostupanjski postupak ipak namjerno čuvajte za slučajeve s teškim posljedicama; ako ga primijenite na sve, udvostručujete trošak cijelog reda i učite analitičare da druge potpise odobravaju bez čitanja, čime se tiho gubi smisao njegova postojanja.

Dizajn za volumen: starenje, prioritizacija, SLA

Red koji samo raste red je koji nije uspio. Ugradite pritisak koji ga drži u kretanju. Slučajevi vidljivo stare, pa ništa ne ostaje zaboravljeno; svaki segment ima ciljnu razinu usluge, pa slučaj s mutnom fotografijom koji probija SLA od nekoliko minuta izlazi na vidjelo drukčije nego sankcijski slučaj unutar svog duljeg roka. Prioritizacija je stvaran izbor: najstariji-prvi pošteno je i jednostavno, ali rizik-prvi — najveća potencijalna izloženost na vrhu — često je pravi potez, uz starenje kao dodatni kriterij da se i slučajevi niskog rizika ipak riješe, a ne izgladne. Ekran analitičara treba prikazati sljedeći slučaj, već usmjeren i prioritiziran, a ne popis iz kojeg se bira — jer red kroz koji ljudi prebiru red je u kojem se nezgodni slučajevi nikad ne odaberu. 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 nitko ne prati dok se klijent ne požali.

Mjerenje reda

Četiri broja govore radi li dizajn. STP stopa pokazuje koliko je slučajeva prošlo bez čovjeka; dubina reda i njezin 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 uključivanje; a stopa ponovnog otvaranja — odluke naknadno poništene — pokazuje odlučuju li analitičari ispravno ili samo brzo. Pratite ih zajedno jer se međusobno uravnotežuju: ako vrijeme do odluke pada dok stopa ponovnog otvaranja raste, brzinu ste kupili pogreškama. Zdrav red je malen, u pokretu, ispravno odlučen i iskren o slučajevima koji su u njemu još otvoreni.

Back office kakav ljudi zamišljaju — sobe pune zaposlenika koji utipkavaju zahtjeve — ono je što dobijete kad automatizacija rješava premalo, a red je jedna neraspoređena hrpa. Back office koji se skalira je obrnut: većina zahtjeva nikad ne dođe do čovjeka, oni koji dođu stižu razvrstani prema razlogu i prioritetu, svaka radnja u log samo za dodavanje unosi i razlog, a četiri oka čuvaju odluke koje to zaslužuju. Izgradite red za iznimke i ostat će malen dok rastete. Izgradite ga kao mjesto na kojem se događa KYC i rast će sa svakom registracijom koju primite.

Imate sustav za izgradnju?

Opišite nam problem. Vratit ćemo se s arhitekturom i planom.