Terepjegyzetek

KYC-felülvizsgálati sor tervezése, amely skálázható

A KYC-felülvizsgálati sor az a back office-munkafolyamat, ahol a gép által önállóan el nem döntött személyazonossági ellenőrzések emberhez kerülnek. A legtöbb kérelemnek automatikusan át kell mennie; a sor azokért van, amelyeknek nem. Teljes tervezési célja, hogy kicsi maradjon — hogy csak valódi bizonytalanságot tartalmazzon —, mert az a sor, amely olyan esetekkel telik meg, amelyeket egy gépnek kellett volna eldöntenie, nem kontroll, hanem szűk keresztmetszet, amely lineárisan nő a regisztrációkkal. Ha a sor jól működik, a back office a kivételekkel skálázódik, nem a volumennel.

Ez az egyetlen tulajdonság — szándékosan kicsi — határoz meg minden további döntést. Kezdjük azzal a szétválasztással, amely ezt biztosítja.

A straight-through a cél, a sor a kivétel

A straight-through processing (STP) azt jelenti, hogy a kérelem emberi beavatkozás nélkül, végig automatikusan lezárul: dokumentumok beolvasva, személyazonosság egyeztetve, szankciós és PEP-szűrés tiszta, liveness sikeres, döntés rögzítve. Ennek kell a gyakori útnak lennie, és az ezt az utat követő kérelmek aránya — az STP-arány — az az egyetlen szám, amely megmondja, skálázódik-e a sor. Ha kilencven-valahány százalék automatikusan átmegy, az emberi sorban kezelhető csorgás marad; ha a fele kiesik felülvizsgálatra, a növekedéssel párhuzamosan kell felülvizsgálókat felvenni. A sor nem az a hely, ahol a KYC történik. Ott ismeri be az automatizált KYC, hogy bizonytalan. Ha az STP-arányt feljebb viszik, minden más szám magától javul: kevesebb sorba állított eset, rövidebb várakozás, kevesebb felveendő felülvizsgáló. Érdemes közvetlenül támadni — jobb dokumentumrögzítés a kliensen, világosabb útmutatás a fotó készítése előtt, úgy hangolt egyezési küszöbök, hogy egy túl óvatos szabály ne dobja vissza a valódi ügyfeleket —, mert minden itt visszanyert százalékpont egy olyan eset, amelyből soha nem lesz valakinek a délutánja.

Mi kerül a sorba, és miért

Az esetek konkrét, megnevezhető okból esnek ki felülvizsgálatra, és az ok az eset legfontosabb attribútuma. A dokumentumfotó túl homályos az olvasáshoz. Az igazolványon szereplő név nem egyezik a kérelmen lévővel. Egy szankciós vagy PEP-szűrés lehetséges találatot adott, amelyet embernek kell megerősítenie vagy elvetnie. Egy cím egyetlen forrás alapján sem ellenőrizhető. A liveness-ellenőrzés elbukott, vagy ugyanez az arc vagy dokumentum már szerepel egy másik számlán. Ezek mind más jellegű munkát igényelnek, más fajta ítélőképességgel — és ha egyetlen megkülönböztetetlen kupacba dobjuk őket, az az első hiba, amit egy felülvizsgálati sor elkövet. Ugyanaz az ok pedig nagyon eltérő súlyú lehet: a néveltérés lehet jelentéktelen házassági névváltozás, de egy ellopott személyazonosság első jele is, a sor feladata pedig az, hogy olyanhoz irányítsa, aki meg tudja különböztetni, ahelyett hogy elhamarkodott ítéletet kényszerítene ki egy gondos döntést érdemlő esetre.

Egy sor nem elég: szegmentáljunk ok szerint

Az egyetlen sor minden felülvizsgálót generalistává kényszerít, és minden esetet összefüggéstelen esetek mögé állít várakozni. Az ok szerinti szegmentálás mindkettőt megoldja. A szankciós lehetséges egyezések sorát a szűrésre és az elbírálásra kiképzett emberek dolgozzák fel; a dokumentumminőségi sor gyors vizuális ellenőrzés, amelyet egy junior felülvizsgáló másodpercek alatt lezár; a duplikált számlák sora csalásvizsgálat. Minden szegmens saját útválasztást, saját szükséges szakértelmet és saját szolgáltatásiszint-célt kap, mert egy homályos fotót percek alatt meg kell oldani, míg egy valódi szankciós találat gondos, nem kapkodó elbírálást érdemel. A szegmentálás teszi lehetővé, hogy az áteresztőképesség és a szigor együtt éljen, ne egymás rovására.

Egy felülvizsgálati sor nem attól skálázódik, hogy több ellenőrt veszünk fel. Attól, hogy helyesen eldöntjük, mely esetekhez nem is kellett ellenőr – és hogy amelyekhez igen, azok már ok szerint rendezve érkeznek.
– Protocore · Üzemeltetési mérnökség

Indoklást igénylő, auditált műveletek

Az ellenőr minden döntéséhez – jóváhagyás, elutasítás, eszkaláció, további dokumentumok kérése – indoklás kell, és minden döntést rögzíteni kell. Nem utólag odabiggyesztett szabad szöveg, hanem strukturált választás, amely megmondja, miért történt a művelet, és a végrehajtás pillanatában kerül rögzítésre. Ez nem bürokrácia: ettől lesz a sor megvédhető. Amikor egy szabályozó, egy auditor vagy egy későbbi ellenőr azt kérdezi, miért hagytak jóvá egy számlát jelzés ellenére, a válasz egy megnevezett ellenőr, egy időbélyeg és egy rögzített indoklás – nem vállrándítás. Az audit napló csak hozzáfűzhető (append-only), így egy döntés utólag nem írható át észrevétlenül; a javítások új bejegyzések, nem a régiek felülírásai. Nálunk ez a sor és az audit modell a Protocore Centerben (/products/center) él, abban az operátori konzolban, ahol minden privilegizált művelethez indoklás kell, és olyan naplóba kerül, amelyet nem lehet észrevétlenül módosítani.

A négy szem elvű esetek

Egyes döntések túl nagy tétre mennek egyetlen embernek. Egy valódi szankciós találat feloldása, egy magas kockázatú profil jóváhagyása vagy egy automatikus elutasítás felülbírálása esetén egy második ellenőr megerősítését kell kérni – ez a maker-checker, vagyis a négy szem elv. Az első ellenőr javaslatot tesz és megindokolja; a második, megfelelő jogosultsággal, megerősíti vagy elutasítja, és ő is megindokolja. Mindkét művelet naplózásra kerül. Ez nem az ellenőrök iránti bizalmatlanság: abból indul ki, hogy a legkockázatosabb jóváhagyásoknál a legdrágább egyetlen hiba, a második szempár pedig a legolcsóbb biztosítás ellene. A sor kialakításának ezeket az eseteket ok alapján, automatikusan kell kétlépéses elbíráláshoz irányítania, ahelyett hogy az ellenőrök emlékezetére bízná. A kétlépéses eljárást azonban tudatosan csak a súlyos következményű esetekre tartsuk fenn; ha mindenre alkalmazzuk, megduplázza az egész sor költségét, és arra szoktatja az ellenőröket, hogy a második aláírást gondolkodás nélkül megadják, ami csendben értelmetlenné teszi az egészet.

Tervezés nagy volumenre: öregedés, priorizálás, SLA-k

Az a sor, amely csak nő, elbukott sor. Építsük bele azt a nyomást, amely mozgásban tartja. Az esetek láthatóan öregszenek, így semmi nem marad elfelejtve; minden szegmens saját szolgáltatásiszint-célt kap, így egy homályos fotós eset, amely a percekben mért SLA-ját sérti, másképp jelenik meg, mint egy szankciós eset a hosszabb határidején belül. A priorizálás valódi döntés: a legrégebbi elöl egyszerű és igazságos, de gyakran a kockázat szerinti sorrend – a legnagyobb potenciális kitettség legelöl – a helyes választás, az öregedéssel mint döntetlen-feloldóval, hogy az alacsony kockázatú esetek is elfogyjanak, ne éhezzenek ki. Az ellenőr képernyője a következő, már irányított és priorizált esetet mutassa, ne egy listát, amelyből válogathat – mert az a sor, amelyben az emberek válogatnak, olyan sor, ahol a kényelmetlen eseteket soha senki nem választja ki. A látható öregedés nélküli sor csendben rothad: a nehéz esetek alulra süllyednek, a könnyűek fent pörögnek, és az egyetlen mutató, amely ezt leleplezné – a legrégebbi nyitott eset kora – pont az a szám, amelyet addig senki nem néz, amíg egy ügyfél panaszkodni nem kezd.

A sor mérése

Négy szám mutatja meg, működik-e a kialakítás. Az STP-arány megmondja, mekkora hányadhoz nem kellett ember; a sor mélysége és trendje, hogy lépést tartotok-e vagy lemaradtok; a döntésig eltelt idő szegmensenként az SLA-hoz mérve, hogy az ügyfelek nem várnak-e túl sokat a regisztrációra; az újranyitási arány – a később felülbírált döntések – pedig, hogy az ellenőrök helyesen vagy csak gyorsan döntenek. Ezeket együtt kell nézni, mert egymás rovására mennek: ha a döntésig eltelt idő csökken, miközben az újranyitási arány nő, akkor a sebességet hibákkal vásároltátok meg. Az egészséges sor kicsi, mozog, helyesen dönt, és őszinte a benne még nyitott esetekről.

Az a back office, amelyet az emberek elképzelnek – termek tele munkatársakkal, akik egyenként gépelik át a jelentkezéseket –, akkor jön létre, ha az automatizálás túl keveset old meg, a sor pedig egyetlen megkülönböztetetlen halom. A skálázódó back office ennek a fordítottja: a legtöbb jelentkezés sosem jut emberhez, amelyek igen, azok ok és prioritás szerint rendezve érkeznek, minden művelet indoklást visz magával egy csak hozzáfűzhető naplóba, és a négy szem elv őrzi azokat a döntéseket, amelyek megkövetelik. A sort a kivételekre építsd, és kicsi marad a növekedéssel is. Ha viszont a KYC helyeként építed, minden új regisztrációval együtt nő.

Van egy megépítendő rendszere?

Írja le a problémát. Architektúrával és tervvel jelentkezünk.