Как да проектираме KYC опашка за преглед, която расте

KYC опашката за преглед е back-office процесът, при който проверките на самоличност, които машината не е могла да приключи сама, се поставят пред човек. Повечето заявки трябва да минават автоматично, а опашката съществува за онези, които не минават. Цялата ѝ цел на проектиране е да остане малка — да съдържа истинска двусмисленост и нищо друго — защото опашка, която се пълни със случаи, които машината е трябвало да реши, не е контрол, а тесен кръст, който расте линейно с регистрациите. Ако опашката е правилна, back office расте с изключенията, а не с обема.

Това единствено свойство — малка по замисъл — определя всяко следващо решение. Започнете с разделението, което я поддържа такава.

Straight-through е целта, опашката е изключението

Straight-through processing (STP) означава, че заявката минава от край до край без човешко докосване: документите са прочетени, самоличността е съпоставена, проверката за санкции и PEP е чиста, liveness е преминат, решението е записано. Това трябва да е обичайният път, а делът на заявките, които го следват — STP rate — е единственото число, което показва дали опашката ще расте поносимо. Ако деветдесет и няколко процента минават автоматично, човешката опашка е управляема струйка; ако половината отпадат към преглед, наемате ревизори в крачка с растежа. Опашката не е мястото, където се случва KYC. Тя е мястото, където автоматизираният KYC признава, че не е сигурен. Вдигнете STP rate и всяко друго число се подобрява даром: по-малко случаи в опашката, по-кратко чакане, по-малко ревизори за наемане. Заслужава си да се атакува директно — по-добро заснемане на документи в клиента, по-ясни инструкции преди снимката, настроени прагове на съпоставяне, така че истинските клиенти да не отпадат заради свръхпредпазливо правило — защото всеки върнат процентен пункт е случай, който никога няма да стане нечий следобед.

Какво попада в опашката и защо

Случаите отпадат към преглед по конкретни, назовими причини, а причината е най-важният атрибут, който случаят носи. Снимката на документ е твърде размазана, за да се чете. Името в личната карта не съвпада с името в заявката. Проверка за санкции или PEP е върнала възможно съвпадение, което човек трябва да потвърди или отхвърли. Адресът не може да бъде потвърден от никой източник. Liveness проверката е неуспешна или същото лице или документ вече съществува в друга сметка. Всяка от тези причини е различен вид работа, която изисква различна преценка — а смесването им в една недиференцирана купчина е първата грешка на опашките за преглед. Освен това една и съща причина може да тежи съвсем различно: несъответствие в името може да е банално разминаване заради омъжено име или първият знак за открадната самоличност, а задачата на опашката е да го насочи към човек, който може да различи едното от другото, вместо да принуждава към прибързана присъда по случай, който заслужава внимателна.

Една опашка не стига: сегментирайте по причина

Единствена опашка принуждава всеки ревизор да е универсалист, а всеки случай да чака зад несвързани други. Сегментирането по причина решава и двете. Опашката за възможно съвпадение със санкции се обработва от хора, обучени в screening и произнасяне по случаите; опашката за качество на документи е бърза визуална проверка, която младши ревизор приключва за секунди; опашката за дублирани сметки е разследване на измама. Всеки сегмент получава собствено насочване, собствено изискуемо умение и собствена цел за ниво на услуга, защото размазана снимка трябва да се реши за минути, а истинско съвпадение със санкции заслужава внимателно и неподтиквано произнасяне. Сегментирането е това, което позволява на пропускателната способност и строгостта да съжителстват, вместо да се разменят.

Опашката за преглед не се мащабира с наемане на още проверяващи. Мащабира се, когато правилно решите кои случаи изобщо не са изисквали преглед — и когато гарантирате, че останалите пристигат вече подредени по причина.

Действия с изискуема причина и одит

Всяко решение на проверяващия — одобрение, отказ, ескалиране, искане на допълнителни документи — трябва да изисква причина и да бъде записано. Не като свободен текст постфактум, а като структуриран избор, който показва защо е предприето действието и е записан в момента на предприемането му. Това не е бюрокрация, а именно онова, което прави опашката защитима. Когато регулатор, одитор или по-късен проверяващ попита защо дадена сметка е одобрена въпреки сигнал, отговорът е конкретен проверяващ, времеви печат и посочена причина — а не свиване на рамене. Одитната следа е само за добавяне, така че решение не може тихомълком да бъде пренаписано постфактум; корекциите са нови записи, а не редакции върху старите. В нашия стек тази опашка и нейният одитен модел живеят в Protocore Center (/products/center) — оператарската конзола, в която всяко привилегировано действие изисква причина и попада в журнал, който не може да бъде променен скришом.

Случаите с четири очи

Някои решения са твърде тежки за един човек. Изчистването на реално съвпадение със санкционен списък, одобряването на високорисков профил или отменянето на автоматичен отказ трябва да изискват потвърждение от втори проверяващ — maker-checker, или принцип на четирите очи. Първият проверяващ предлага и посочва причина; вторият, с необходимите права, потвърждава или отхвърля и също посочва своя. И двете действия се записват. Това не е недоверие към проверяващите, а признание, че при най-рискованите одобрения една грешка струва най-скъпо, а второто чифт очи е най-евтината застраховка срещу нея. Дизайнът на опашката трябва автоматично да насочва тези случаи към двустъпково решение според причината, вместо да разчита проверяващите да помнят. Запазете обаче двата стъпала съзнателно за тежките случаи; ако ги прилагате към всичко, удвоявате цената на цялата опашка и приучвате проверяващите да подписват механично втория подпис, което тихомълком обезсмисля самото му съществуване.

Проектиране за обем: застояване, приоритизиране, SLA

Опашка, която само расте, е провалена опашка. Заложете натиск, който я движи. Случаите остаряват видимо, така че нищо не стои забравено; всеки сегмент има целево ниво на обслужване, така че случай със замъглена снимка, нарушил SLA от няколко минути, изпъква по различен начин от санкционен случай в рамките на по-дългия си срок. Приоритизирането е реален избор: първо най-старите е честно и просто, но първо най-рисковите — с най-голяма потенциална експозиция отгоре — често е правилното решение, а застояването служи за допълнителен критерий, за да се изчистват и нискорисковите случаи, вместо да гладуват. Екранът на проверяващия трябва да показва следващия случай, вече насочен и приоритизиран, а не списък за избор — защото опашка, из която хората си избират, е опашка, в която неудобните случаи никога не бъдат избрани. Опашка без видимо застояване тихо гние: трудните случаи потъват на дъното, докато лесните се въртят отгоре, а единственият показател, който би го издал — възрастта на най-стария отворен случай — е точно числото, което никой не следи, докато клиент не се оплаче.

Измерване на опашката

Четири числа показват дали дизайнът работи. STP коефициентът казва колко случаи изобщо не са изисквали човек; дълбочината на опашката и тенденцията ѝ показват дали смогвате, или изоставате; времето до решение, следено по сегменти спрямо техния SLA, показва дали клиентите чакат твърде дълго да бъдат въведени; а процентът на повторно отваряне — решения, отменени по-късно — показва дали проверяващите решават правилно, или просто бързо. Следете ги заедно, защото се уравновесяват взаимно: ако времето до решение пада, докато процентът на повторно отваряне расте, значи сте купили скорост с грешки. Здравата опашка е малка, движи се, решава правилно и е честна за случаите, които още са отворени в нея.

Бек офисът, който хората си представят — стаи с персонал, който въвежда заявления — е това, което получавате, когато автоматизацията изчиства твърде малко и опашката е една неразграничена купчина. Бек офисът, който се мащабира, е обратното: повечето заявления никога не стигат до човек, тези, които стигат, пристигат подредени по причина и приоритет, всяко действие внася причина в журнал само за добавяне, а принципът на четирите очи пази решенията, които го заслужават. Изградете опашката за изключенията и тя остава малка, докато растете. Изградете я като мястото, където се случва KYC, и тя расте с всяка регистрация, която приемете.