KYC-tarkistusjono, joka skaalautuu

KYC-tarkistusjono on back office -työnkulku, jossa henkilöllisyystarkistukset, joita kone ei pystynyt ratkaisemaan itse, annetaan ihmisen arvioitavaksi. Useimpien hakemusten tulisi mennä läpi automaattisesti; jono on olemassa niitä varten, jotka eivät mene. Sen koko suunnittelutavoite on pysyä pienenä – sisältää aitoa epäselvyyttä eikä mitään muuta – koska jono, joka täyttyy tapauksista, jotka koneen olisi pitänyt ratkaista, ei ole kontrolli vaan pullonkaula, joka kasvaa lineaarisesti rekisteröitymisten mukana. Kun jono on kunnossa, back office skaalautuu poikkeusten, ei volyymin mukana.

Tämä yksi ominaisuus – tarkoituksellinen pienuus – ohjaa jokaista seuraavaa päätöstä. Aloitetaan jaosta, joka pitää jonon sellaisena.

Straight-through on tavoite, jono on poikkeus

Straight-through processing (STP) tarkoittaa, että hakemus etenee alusta loppuun ilman ihmisen kosketusta: asiakirjat luettu, henkilöllisyys täsmännyt, pakote- ja PEP-seulonta puhdas, liveness-tarkistus läpäisty, päätös kirjattu. Tämän pitäisi olla tavallinen reitti, ja sen kulkevien hakemusten osuus – STP-aste – on yksittäinen luku, joka kertoo, skaalautuuko jono. Jos yhdeksänkymmentä-jotain prosenttia selviää automaattisesti, ihmisten jonoon valuu hallittava määrä tapauksia; jos puolet putoaa tarkistukseen, palkkaat tarkistajia kasvun tahdissa. Jono ei ole paikka, jossa KYC tapahtuu. Se on paikka, jossa automaattinen KYC myöntää olevansa epävarma. Nosta STP-astetta, niin kaikki muut luvut paranevat ilmaiseksi: vähemmän jonotettuja tapauksia, lyhyemmät odotusajat, vähemmän palkattavia tarkistajia. Siihen kannattaa puuttua suoraan – parempi asiakirjakuvaus asiakasohjelmassa, selkeämmät ohjeet ennen kuvan ottamista, täsmäytyskynnykset viritetty niin, ettei ylivarovainen sääntö hylkää aitoja asiakkaita – koska jokainen siellä takaisin saatu prosenttiyksikkö on tapaus, josta ei koskaan tule jonkun iltapäivää.

Mitä jonoon päätyy ja miksi

Tapaukset putoavat tarkistukseen tietyistä, nimettävistä syistä, ja syy on tärkein tapauksen mukana kulkeva ominaisuus. Asiakirjakuva on liian sumea luettavaksi. Henkilökortin nimi ei vastaa hakemuksen nimeä. Pakote- tai PEP-seulonta antoi mahdollisen osuman, jonka ihmisen on vahvistettava tai hylättävä. Osoitetta ei voi vahvistaa mistään lähteestä. Liveness-tarkistus epäonnistui, tai sama kasvo tai asiakirja on jo toisella tilillä. Jokainen näistä on erilaista työtä, joka vaatii erilaista harkintaa – ja niiden niputtaminen yhteen erottelemattomaan kasaan on tarkistusjonon ensimmäinen virhe. Lisäksi sama syy voi painaa hyvin eri tavoin: nimen ero voi olla vaatimaton avioliiton jälkeinen sukunimen muutos tai ensimmäinen merkki varastetusta henkilöllisyydestä, ja jonon tehtävä on ohjata se jollekulle, joka erottaa nämä toisistaan, sen sijaan että huolellista käsittelyä ansaitsevalle tapaukselle pakotettaisiin pikainen ratkaisu.

Yksi jono ei riitä: segmentoi syyn mukaan

Yksittäinen jono pakottaa jokaisen tarkistajan olemaan yleisasiantuntija ja jokaisen tapauksen odottamaan toisiinsa liittymättömien takana. Syyn mukaan segmentointi korjaa molemmat. Pakotteiden mahdollisten osumien jonoa käsittelevät seulontaan ja ratkaisuun koulutetut ihmiset; asiakirjan laadun jono on nopea silmämääräinen tarkistus, jonka junioritarkistaja selvittää sekunneissa; päällekkäisten tilien jono on petostutkinta. Jokainen segmentti saa oman reitityksensä, oman osaamisvaatimuksensa ja oman palvelutasotavoitteensa, koska sumea kuva pitää ratkaista minuuteissa, kun taas aito pakoteosuma ansaitsee huolellisen, kiireettömän käsittelyn. Segmentointi mahdollistaa läpimenon ja tarkkuuden rinnakkaiselon sen sijaan, että ne vaihdettaisiin toisiinsa.

Tarkistusjono ei skaalaudu palkkaamalla lisää tarkistajia. Se skaalautuu päättämällä oikein, mitkä tapaukset eivät koskaan tarvinneet tarkistusta – ja huolehtimalla, että tarkistusta tarvitsevat saapuvat jo lajiteltuina syyn mukaan.

Perustelua vaativat, auditoidut toimet

Jokaisen tarkistajan päätöksen – hyväksyntä, hylkäys, eskalointi, lisädokumenttien pyyntö – on edellytettävä perustelua ja tallennuttava. Ei vapaamuotoisena jälkikirjauksena, vaan jäsenneltynä valintana, joka kertoo, miksi toimi tehtiin, ja joka tallentuu toimen hetkellä. Kyse ei ole byrokratiasta vaan siitä, mikä tekee jonosta puolustettavan. Kun viranomainen, tilintarkastaja tai myöhempi tarkistaja kysyy, miksi tili hyväksyttiin lipusta huolimatta, vastauksena on nimetty tarkistaja, aikaleima ja ilmoitettu syy – ei olankohautus. Auditointiloki on vain lisättävä (append-only), joten päätöstä ei voi hiljaa kirjoittaa uusiksi jälkikäteen; korjaukset ovat uusia merkintöjä, eivät vanhojen päälle tehtyjä muokkauksia. Meillä tämä jono ja sen auditointimalli ovat tuotteessa Protocore Center (/products/center), operaattorikonsolissa, jossa jokainen etuoikeutettu toimi vaatii perustelun ja päätyy lokiin, jota ei voi muuttaa huomaamatta.

Neljän silmän tapaukset

Jotkin päätökset ovat liian merkittäviä yhden ihmisen tehtäväksi. Aidon pakotetreffin kuittaaminen, korkean riskin profiilin hyväksyminen tai automaattisen hylkäyksen ohittaminen kannattaa vaatia vahvistettavaksi toisella tarkistajalla – maker-checker eli neljän silmän periaate. Ensimmäinen tarkistaja ehdottaa ja ilmoittaa syyn; toinen, jolla on siihen valtuudet, vahvistaa tai hylkää ja ilmoittaa omansa. Molemmat toimet kirjataan lokiin. Kyse ei ole epäluottamuksesta tarkistajia kohtaan, vaan siitä, että suurimman riskin hyväksynnöissä yksittäinen virhe on kalleimmillaan, ja toinen silmäpari on halvin vakuutus sitä vastaan. Jonon suunnittelun tulee ohjata nämä tapaukset kaksivaiheiseen käsittelyyn automaattisesti syyn perusteella, jotta se ei jää tarkistajien muistin varaan. Varaa kaksivaiheisuus kuitenkin harkiten merkittäville tapauksille: jos sitä sovelletaan kaikkeen, koko jonon kustannus kaksinkertaistuu ja tarkistajat oppivat leimaamaan toisen allekirjoituksen läpi, mikä hiljaa kumoaa koko idean.

Mitoitus volyymille: ikääntyminen, priorisointi, SLA:t

Jono, joka vain kasvaa, on epäonnistunut jono. Rakenna siihen paine, joka pitää sen liikkeessä. Tapaukset ikääntyvät näkyvästi, jotta mikään ei jää unohduksiin; jokaisella segmentillä on palvelutasotavoite, joten epäselvän kuvan tapaus, joka ylittää minuuttien SLA:nsa, nousee esiin eri tavalla kuin pakotetapaus pidemmän SLA:nsa sisällä. Priorisointi on todellinen valinta: vanhin ensin on reilu ja yksinkertainen, mutta riski edellä – suurin mahdollinen altistuminen kärjessä – on usein oikea ratkaisu, ja ikä ratkaisee tasatilanteet, jotta matalan riskin tapaukset silti etenevät eivätkä näänny. Tarkistajan näkymän tulee tarjota seuraava tapaus valmiiksi reititettynä ja priorisoituna, ei listaa, josta valita – koska jonosta valikoiva porukka jättää hankalat tapaukset aina poimimatta. Jono ilman näkyvää ikääntymistä mätänee hiljaa: vaikeat tapaukset vajoavat pohjalle ja helpot pyörivät päällä, ja juuri se mittari, joka olisi paljastanut tämän – vanhimman avoimen tapauksen ikä – on luku, jota kukaan ei seuraa ennen kuin asiakas valittaa.

Jonon mittaaminen

Neljä lukua kertoo, toimiiko suunnittelu. STP-aste kertoo, kuinka suuri osa ei koskaan tarvinnut ihmistä; jonon syvyys ja sen suunta kertovat, pysytäänkö vauhdissa vai jäädäänkö jälkeen; päätösaika segmenteittäin SLA:ta vasten kertoo, odottavatko asiakkaat liian kauan liittymistään; ja uudelleenavausaste – myöhemmin kumotut päätökset – kertoo, päättävätkö tarkistajat oikein vai vain nopeasti. Seuraa näitä yhdessä, koska ne vaihtavat paikkaa keskenään: jos päätösaika lyhenee uudelleenavausasteen noustessa, nopeus on ostettu virheillä. Terve jono on pieni, liikkuva, oikein päätetty ja rehellinen siinä yhä avoinna olevista tapauksista.

Back office, jonka ihmiset kuvittelevat – huoneellinen väkeä näppäilemässä hakemuksia läpi – syntyy, kun automaatio selvittää liian vähän ja jono on yksi eriytymätön kasa. Skaalautuva back office on päinvastainen: useimmat hakemukset eivät koskaan päädy ihmiselle, ne jotka päätyvät, saapuvat lajiteltuina syyn ja prioriteetin mukaan, jokainen toimi vie perustelunsa append-only-lokiin, ja neljän silmän periaate suojaa päätökset, jotka sitä ansaitsevat. Rakenna jono poikkeuksia varten, niin se pysyy pienenä kasvun mukana. Rakenna se paikaksi, jossa KYC tehdään, niin se kasvaa jokaisen ottamasi rekisteröitymisen mukana.