Notatki z praktyki

Jak zaprojektować kolejkę przeglądu KYC, która się skaluje

Kolejka przeglądu KYC to workflow back office, w którym weryfikacje tożsamości, jakich maszyna nie zatwierdziła samodzielnie, trafiają przed oczy człowieka. Większość wniosków powinna przechodzić automatycznie; kolejka istnieje dla tych, które nie przechodzą. Jej cel projektowy to pozostać małą — mieścić prawdziwą niejednoznaczność i nic więcej — bo kolejka zapełniona sprawami, które maszyna powinna była rozstrzygnąć, nie jest kontrolą, tylko wąskim gardłem rosnącym liniowo wraz z rejestracjami. Dobrze zaprojektowana kolejka sprawia, że back office skaluje się z wyjątkami, a nie z wolumenem.

Ta jedna cecha — celowa małość — napędza każdą kolejną decyzję. Zacznij od podziału, który ją utrzymuje.

Celem jest straight-through, kolejka to wyjątek

Straight-through processing (STP) oznacza, że wniosek przechodzi od początku do końca bez udziału człowieka: dokumenty odczytane, tożsamość dopasowana, screening sankcji i PEP czysty, liveness zaliczony, decyzja zapisana. To powinna być ścieżka powszechna, a odsetek wniosków, które nią idą — wskaźnik STP — to jedyna liczba mówiąca, czy kolejka się skaluje. Jeśli ponad dziewięćdziesiąt kilka procent przechodzi automatycznie, ludzka kolejka to znośny strumyk; jeśli połowa wypada do przeglądu, zatrudniasz recenzentów równolegle ze wzrostem. Kolejka nie jest miejscem, gdzie dzieje się KYC. To miejsce, w którym zautomatyzowane KYC przyznaje, że nie jest pewne. Podnieś wskaźnik STP, a każda inna liczba poprawi się przy okazji: mniej spraw w kolejce, krótsze oczekiwanie, mniej recenzentów do zatrudnienia. Warto atakować go wprost — lepsze przechwytywanie dokumentów w kliencie, jaśniejsze instrukcje przed zrobieniem zdjęcia, progi dopasowania ustawione tak, by prawdziwi klienci nie odpadali przez zbyt ostrożną regułę — bo każdy odzyskany punkt procentowy to sprawa, która nigdy nie stanie się czyimś popołudniem.

Co trafia do kolejki i dlaczego

Sprawy wypadają do przeglądu z konkretnych, dających się nazwać powodów, a powód jest najważniejszym atrybutem sprawy. Zdjęcie dokumentu jest zbyt nieostre, by je odczytać. Imię i nazwisko na dowodzie nie zgadza się z tym we wniosku. Screening sankcji lub PEP zwrócił możliwe trafienie, które człowiek musi potwierdzić lub odrzucić. Adresu nie da się zweryfikować w żadnym źródle. Test liveness się nie powiódł albo ta sama twarz lub dokument istnieje już na innym koncie. Każdy z tych przypadków to inny rodzaj pracy wymagający innego osądu — a wrzucanie ich do jednego niezróżnicowanego stosu to pierwszy błąd kolejki przeglądu. Ten sam powód może mieć też bardzo różną wagę: niezgodność nazwiska może być zwykłą różnicą po zmianie nazwiska po ślubie albo pierwszym sygnałem skradzionej tożsamości, a zadaniem kolejki jest skierować ją do kogoś, kto potrafi to rozróżnić, zamiast wymuszać pochopny werdykt w sprawie zasługującej na staranność.

Jedna kolejka to za mało: segmentuj według powodu

Pojedyncza kolejka zmusza każdego recenzenta do bycia generalistą, a każdą sprawę do czekania za niepowiązanymi. Segmentacja według powodu naprawia oba problemy. Kolejkę możliwych trafień sankcyjnych obsługują ludzie przeszkoleni w screeningu i rozstrzyganiu; kolejka jakości dokumentów to szybka kontrola wzrokowa, którą młodszy recenzent załatwia w kilka sekund; kolejka zduplikowanych kont to śledztwo antyfraudowe. Każdy segment dostaje własny routing, własne wymagane umiejętności i własny cel SLA, bo nieostre zdjęcie należy rozwiązać w minuty, a prawdziwe trafienie sankcyjne zasługuje na staranne, niespieszne rozstrzygnięcie. Segmentacja pozwala współistnieć przepustowości i rygorowi, zamiast wymieniać jedno na drugie.

Kolejki weryfikacji nie skaluje się, zatrudniając kolejnych weryfikatorów. Skaluje się ją, trafnie rozstrzygając, które sprawy w ogóle nie wymagały weryfikacji — i dbając o to, by te, które jej wymagają, trafiały do kolejki już posortowane według powodu.
— Protocore · Inżynieria operacji

Działania z obowiązkowym powodem i audytem

Każda decyzja weryfikatora — zatwierdzenie, odrzucenie, eskalacja, prośba o dodatkowe dokumenty — musi wymagać podania powodu i musi zostać zapisana. Nie jako dopisek w wolnym tekście, lecz jako ustrukturyzowany wybór, który wyjaśnia, dlaczego podjęto dane działanie, zapisany w chwili jego podjęcia. To nie biurokracja, tylko to, co pozwala obronić kolejkę. Gdy regulator, audytor albo kolejny weryfikator zapyta, dlaczego konto zatwierdzono mimo flagi, odpowiedzią jest weryfikator wskazany z imienia i nazwiska, znacznik czasu i podany powód — a nie wzruszenie ramion. Ścieżka audytu jest typu append-only, więc decyzji nie da się po cichu przepisać po fakcie; poprawki to nowe wpisy, a nie edycje starych. W naszym stosie ta kolejka i jej model audytu działają w Protocore Center (/products/center), konsoli operatora, w której każde uprzywilejowane działanie wymaga podania powodu i trafia do logu, którego nie da się po cichu zmienić.

Sprawy wymagające zasady czterech oczu

Niektóre decyzje mają zbyt duże konsekwencje, by podejmowała je jedna osoba. Zdjęcie flagi z prawdziwego trafienia sankcyjnego, zatwierdzenie profilu wysokiego ryzyka czy unieważnienie automatycznego odrzucenia powinno wymagać potwierdzenia przez drugiego weryfikatora — maker-checker, czyli zasada czterech oczu. Pierwszy weryfikator proponuje decyzję i podaje powód; drugi, mający do tego uprawnienia, potwierdza lub odrzuca i podaje własny. Oba działania są logowane. To nie brak zaufania do weryfikatorów, tylko świadomość, że najbardziej ryzykowne zatwierdzenia to właśnie te, w których pojedynczy błąd kosztuje najwięcej, a druga para oczu jest na niego najtańszym ubezpieczeniem. Projekt kolejki powinien kierować takie sprawy do dwuetapowej dyspozycji automatycznie, według powodu, zamiast liczyć na to, że weryfikatorzy sami o tym pamiętają. Dwa etapy warto jednak zarezerwować świadomie dla spraw o poważnych konsekwencjach; stosowanie ich do wszystkiego podwaja koszt całej kolejki i uczy weryfikatorów przybijać drugi podpis bez czytania, co po cichu niweczy sens jego istnienia.

Projektowanie pod wolumen: wiekowanie, priorytety, SLA

Kolejka, która tylko rośnie, to kolejka, która zawiodła. Wbuduj w nią presję, która utrzymuje ją w ruchu. Sprawy widocznie się starzeją, więc nic nie leży zapomniane; każdy segment ma cel poziomu usług, więc sprawa z nieczytelnym zdjęciem, przekraczająca swoje kilkuminutowe SLA, wyświetla się inaczej niż sprawa sankcyjna mieszcząca się w dłuższym. Priorytetyzacja to realny wybór: „najstarsze najpierw” jest uczciwe i proste, ale „najwyższe ryzyko najpierw” — z największą potencjalną ekspozycją na górze — często jest właściwą decyzją, z wiekiem sprawy jako kryterium rozstrzygającym, tak aby sprawy niskiego ryzyka nadal były załatwiane, a nie głodzone. Ekran weryfikatora powinien pokazywać następną sprawę, już skierowaną i uszeregowaną, a nie listę do wyboru — bo kolejka, w której ludzie przebierają, to kolejka, w której niewygodne sprawy nigdy nie zostają wybrane. Kolejka bez widocznego wiekowania gnije po cichu: trudne sprawy opadają na dno, a łatwe kręcą się na wierzchu, i jedyna metryka, która by to ujawniła — wiek najstarszej otwartej sprawy — to właśnie liczba, której nikt nie obserwuje, dopóki klient się nie poskarży.

Mierzenie kolejki

O tym, czy projekt działa, mówią cztery liczby. Wskaźnik STP pokazuje, ile spraw w ogóle nie wymagało człowieka; głębokość kolejki i jej trend mówią, czy nadążasz, czy zostajesz w tyle; czas do decyzji, śledzony per segment względem jego SLA, mówi, czy klienci nie czekają zbyt długo na onboarding; a wskaźnik ponownego otwarcia — decyzji później uchylonych — mówi, czy weryfikatorzy decydują poprawnie, czy tylko szybko. Obserwuj je razem, bo wzajemnie się równoważą: skracanie czasu do decyzji przy rosnącym wskaźniku ponownego otwarcia oznacza, że szybkość kupiono kosztem błędów. Zdrowa kolejka jest mała, płynna, rozstrzygana poprawnie i uczciwa wobec spraw, które nadal w niej czekają.

Back office, który ludzie sobie wyobrażają — sale pełne pracowników przepisujących wnioski — to efekt sytuacji, w której automatyzacja załatwia zbyt mało, a kolejka jest jednym niezróżnicowanym stosem. Back office, który się skaluje, jest odwrotnością: większość wniosków nigdy nie trafia do człowieka, te, które trafiają, przychodzą posortowane według powodu i priorytetu, każde działanie wnosi powód do logu append-only, a zasada czterech oczu chroni decyzje, które na to zasługują. Zbuduj kolejkę pod wyjątki, a pozostanie mała w miarę wzrostu. Zbuduj ją jako miejsce, w którym odbywa się KYC, a będzie rosła z każdą rejestracją, którą przyjmiesz.

Masz system do zbudowania?

Opisz nam problem. Wrócimy z architekturą i planem.