Cum proiectezi o coadă de verificare KYC care scalează

O coadă de verificare KYC este fluxul de back office în care verificările de identitate pe care o mașină nu le-a putut soluționa singură sunt puse în fața unui om. Cele mai multe cereri ar trebui să treacă automat; coada există pentru cele care nu trec. Întregul ei scop de design este să rămână mică — să țină ambiguitate reală și nimic altceva — pentru că o coadă care se umple cu cazuri pe care o mașină ar fi trebuit să le decidă nu este un control, ci un blocaj care crește liniar cu numărul de înscrieri. Fă coada bine și un back office scalează cu excepțiile, nu cu volumul.

Această unică proprietate — mică în mod intenționat — conduce fiecare decizie care urmează. Pornește de la separarea care o ține așa.

Procesarea directă este scopul, coada este excepția

Procesarea directă (STP) înseamnă că o cerere se soluționează de la un cap la altul fără atingere umană: documentele citite, identitatea potrivită, ecranarea de sancțiuni și PEP curată, testul de vivacitate trecut, decizia înregistrată. Aceasta ar trebui să fie calea obișnuită, iar ponderea cererilor care o iau — rata STP — este singura cifră care îți spune dacă coada va scala. Dacă nouăzeci și ceva la sută se soluționează automat, coada umană ține un firicel gestionabil; dacă jumătate cad la verificare, angajezi verificatori în pas cu creșterea. Coada nu este locul unde se întâmplă KYC. Este locul unde KYC automat recunoaște că nu este sigur. Împinge rata STP în sus și fiecare altă cifră se îmbunătățește gratis: mai puține cazuri în coadă, așteptări mai scurte, mai puțini verificatori de angajat. Merită atacată direct — captură mai bună a documentelor pe client, instrucțiuni mai clare înainte de a face o poză, praguri de potrivire reglate ca un client real să nu fie respins de o regulă prea prudentă — pentru că fiecare punct procentual recuperat acolo este un caz care nu devine niciodată după-amiaza cuiva.

Ce ajunge în coadă și de ce

Cazurile cad la verificare din motive specifice, care pot fi numite, iar motivul este cel mai important atribut pe care îl poartă un caz. Fotografia unui document este prea neclară ca să fie citită. Numele de pe act nu se potrivește cu numele de pe cerere. O ecranare de sancțiuni sau PEP a returnat o posibilă potrivire care are nevoie de un om ca să o confirme sau să o respingă. O adresă nu poate fi verificată față de nicio sursă. Un test de vivacitate a eșuat sau aceeași față ori același document există deja pe alt cont. Fiecare dintre acestea este un fel diferit de muncă, cerând un fel diferit de judecată — iar grămădirea lor într-o singură movilă nediferențiată este prima greșeală pe care o face o coadă de verificare. Iar același motiv poate cântări foarte diferit: o nepotrivire de nume poate fi o banală discrepanță de nume de căsătorie sau primul semn al unei identități furate, iar treaba cozii este să o ruteze către cineva care poate face diferența, nu să forțeze un verdict pripit asupra unui caz care merită unul atent.

O singură coadă nu ajunge: segmentează după motiv

O singură coadă obligă fiecare verificator să fie generalist și fiecare caz să aștepte în spatele unora fără legătură. Segmentarea după motiv rezolvă ambele. O coadă de posibile potriviri de sancțiuni este lucrată de oameni instruiți pe ecranare și disponibilizare; o coadă de calitate a documentelor este o verificare vizuală rapidă pe care un verificator junior o soluționează în câteva secunde; o coadă de conturi duplicate este o investigație de fraudă. Fiecare segment primește rutarea lui, competența cerută și ținta lui de nivel de serviciu, pentru că o fotografie neclară ar trebui rezolvată în minute, în timp ce o potrivire reală de sancțiuni merită o disponibilizare atentă, negrăbită. Segmentarea este ceea ce permite ca debitul și rigoarea să coexiste în loc să se sacrifice reciproc.

O coadă de verificare nu scalează prin angajarea de verificatori. Scalează decidând corect care cazuri nu au avut niciodată nevoie de unul — și asigurând că cele care au ajung deja sortate după motiv.

— Protocore · Inginerie de operațiuni

Acțiuni cu motiv obligatoriu, auditate

Fiecare decizie pe care o ia un verificator — aprobare, respingere, escaladare, cerere de documente suplimentare — trebuie să ceară un motiv și trebuie înregistrată. Nu un text liber adăugat ulterior, ci o selecție structurată care spune de ce a fost luată acțiunea, capturată în momentul în care este luată. Nu este birocrație; este ceea ce face coada apărabilă. Când un reglementator, un auditor sau un verificator ulterior întreabă de ce un cont a fost aprobat în ciuda unei alerte, răspunsul este un verificator cu nume, un moment de timp și un motiv declarat — nu un ridicat din umeri. Traseul de audit este doar-adăugare, așa că o decizie nu poate fi rescrisă în liniște ulterior; corecțiile sunt înregistrări noi, nu editări peste cele vechi. În stiva noastră, această coadă și modelul ei de audit trăiesc în Protocore Center (/products/center), consola de operare unde fiecare acțiune privilegiată cere un motiv și aterizează într-un jurnal care nu poate fi alterat în tăcere.

Cazurile cu patru ochi

Unele decizii sunt prea grele pentru o singură persoană. Soluționarea unei potriviri reale de sancțiuni, aprobarea unui profil cu risc ridicat sau anularea unei respingeri automate ar trebui să ceară un al doilea verificator care să confirme — maker-checker, sau patru ochi. Primul verificator propune și declară un motiv; un al doilea, cu autoritatea de a o face, confirmă sau respinge și îl declară pe al lui. Ambele acțiuni sunt înregistrate. Nu este neîncredere în verificatori; este recunoașterea că aprobările cu cel mai mare risc sunt exact cele în care o singură greșeală costă cel mai mult, iar o a doua pereche de ochi este cea mai ieftină asigurare împotriva ei. Designul cozii ar trebui să ruteze aceste cazuri automat către o disponibilizare în doi pași, după motiv, nu să se bazeze pe verificatori să-și amintească. Rezervă însă pasul dublu în mod deliberat pentru cazurile cu miză; aplicarea lui la tot dublează costul întregii cozi și îi învață pe verificatori să pună ștampila pe a doua semnătură, ceea ce anulează în tăcere rostul de a o avea.

Proiectat pentru volum: îmbătrânire, prioritizare, SLA-uri

O coadă care doar crește este o coadă care a eșuat. Proiectează în ea presiunea care o menține în mișcare. Cazurile îmbătrânesc vizibil, ca nimic să nu stea uitat; fiecare segment poartă o țintă de nivel de serviciu, ca un caz de fotografie neclară care își încalcă SLA-ul de câteva minute să iasă la suprafață altfel decât un caz de sancțiuni aflat în SLA-ul lui mai lung. Prioritizarea este o alegere reală: cel-mai-vechi-întâi este corect și simplu, dar risc-întâi — cea mai mare expunere potențială în vârf — este adesea alegerea corectă, cu îmbătrânirea drept criteriu de departajare, ca și cazurile cu risc scăzut să se soluționeze, nu să moară de foame. Ecranul verificatorului ar trebui să prezinte următorul caz, deja rutat și prioritizat, nu o listă din care să alegi — pentru că o coadă din care oamenii culeg este o coadă în care cazurile incomode nu sunt niciodată culese. O coadă fără îmbătrânire vizibilă putrezește în tăcere: cazurile grele se scufundă la fund în timp ce cele ușoare se rotesc deasupra, iar singura cifră care ar fi expus-o — vârsta celui mai vechi caz deschis — este exact numărul pe care nu-l urmărește nimeni până când se plânge un client.

Măsurarea cozii

Patru cifre îți spun dacă designul funcționează. Rata STP spune cât nu a avut nevoie niciodată de un om; adâncimea cozii și tendința ei spun dacă ții pasul sau rămâi în urmă; timpul-până-la-decizie, urmărit pe segment față de SLA-ul lui, spune dacă clienții așteaptă prea mult ca să fie integrați; iar rata de redeschidere — decizii răsturnate ulterior — spune dacă verificatorii decid corect sau doar rapid. Urmărește-le împreună, pentru că se schimbă una pe cealaltă: să împingi timpul-până-la-decizie în jos în timp ce rata de redeschidere urcă înseamnă că ai cumpărat viteză cu greșeli. O coadă sănătoasă este mică, în mișcare, decisă corect și onestă cu privire la cazurile încă deschise în ea.

Back office-ul pe care și-l imaginează lumea — camere de oameni tastând prin cereri — este ce obții când automatizarea soluționează prea puțin, iar coada este o singură movilă nediferențiată. Back office-ul care scalează este inversul: cele mai multe cereri nu ajung niciodată la un om, cele care ajung sosesc sortate după motiv și prioritate, fiecare acțiune poartă un motiv într-un jurnal doar-adăugare, iar patru ochi păzesc deciziile care o merită. Construiește coada pentru excepții și rămâne mică pe măsură ce crești. Construiește-o ca locul unde se întâmplă KYC și crește cu fiecare înscriere pe care o accepți.