Як спроєктувати чергу KYC-перевірки, що масштабується

Черга KYC-перевірки — це бек-офісний процес, у якому перевірки особи, що їх машина не змогла закрити самостійно, потрапляють до людини. Більшість заявок мають проходити автоматично, а черга існує для тих, що не проходять. Головна мета її дизайну — залишатися малою й містити лише справжню неоднозначність. Адже черга, яка заповнюється випадками, що їх мала вирішити машина, — це не контроль, а вузьке місце, яке росте лінійно разом із реєстраціями. Налаштуйте чергу правильно, і бек-офіс масштабуватиметься за кількістю винятків, а не за обсягом.

Ця єдина властивість — навмисна малість — визначає всі подальші рішення. Почніть із поділу, який її зберігає.

Мета — наскрізна обробка, а черга — виняток

Наскрізна обробка (straight-through processing, STP) означає, що заявка проходить від початку до кінця без участі людини: документи зчитано, особу зіставлено, перевірку на санкції та PEP пройдено без збігів, liveness пройдено, рішення записано. Це має бути звичайним шляхом, а частка заявок, що ним проходять, — STP rate — єдиний показник, який показує, чи масштабуватиметься черга. Якщо автоматично проходить понад дев'яносто відсотків, людська черга лишається керованим струменем. Якщо половина випадає на перевірку, ви наймаєте перевіряльників услід за зростанням. Черга — це не місце, де відбувається KYC, а місце, де автоматизований KYC визнає, що не впевнений. Піднімайте STP rate, і решта показників покращиться сама: менше випадків у черзі, коротше очікування, менше людей для найму. Над цим варто працювати напряму: краще фотографувати документи на клієнті, давати зрозуміліші інструкції перед зйомкою, налаштовувати пороги зіставлення так, щоб справжніх клієнтів не відсікало надто обережне правило. Адже кожен повернений тут відсоток — це випадок, який ніколи не забере чийсь день.

Що потрапляє в чергу і чому

Випадки потрапляють на перевірку з конкретних, називних причин, і причина — найважливіший атрибут випадку. Фото документа надто розмите, щоб його прочитати. Ім'я в посвідченні не збігається з іменем у заявці. Перевірка на санкції чи PEP повернула можливий збіг, який людина має підтвердити або відхилити. Адресу неможливо перевірити за жодним джерелом. Liveness-перевірку не пройдено, або те саме обличчя чи документ уже є на іншому рахунку. Кожен із цих випадків — окремий вид роботи, що потребує окремого судження, а звалювати їх в одну неподілену купу — перша помилка черги перевірки. До того ж одна й та сама причина може мати дуже різну вагу: розбіжність у імені може бути звичайною зміною прізвища після шлюбу, а може бути першою ознакою викраденої особи. Завдання черги — передати такий випадок людині, яка здатна розрізнити ці ситуації, а не змушувати до поспішного вердикту там, де потрібен ретельний.

Однієї черги замало: сегментуйте за причиною

Єдина черга змушує кожного перевіряльника бути універсалом, а кожен випадок чекати позаду непов'язаних. Сегментація за причиною розв'язує обидві проблеми. Чергу можливих збігів із санкціями опрацьовують люди, навчені скринінгу й ухваленню рішень. Чергу якості документів закриває молодший перевіряльник за лічені секунди швидким візуальним оглядом. Чергу дублікатів рахунків — це вже антифрод-розслідування. Кожен сегмент має власну маршрутизацію, власні потрібні навички та власну ціль за рівнем сервісу: розмите фото слід вирішувати за хвилини, а справжній збіг із санкціями заслуговує на ретельне й неквапливе рішення. Сегментація дає змогу поєднати пропускну здатність і ретельність, а не жертвувати однією заради іншої.

Черга перевірки не масштабується наймом рев'юерів. Вона масштабується тим, що правильно визначає, яким кейсам рев'юер взагалі не потрібен, — і тим, що решта потрапляє до черги вже відсортованою за причинами.

Дії з обов'язковою причиною та аудитом

Кожне рішення рев'юера — схвалити, відхилити, ескалювати, запросити додаткові документи — має вимагати причину і фіксуватися. Не вільний текст «на потім», а структурований вибір, який пояснює, чому дію виконано, і записується в момент виконання. Це не бюрократія, а те, що робить чергу захищеною. Коли регулятор, аудитор або наступний рев'юер питає, чому акаунт схвалили попри позначку, відповідь — конкретний рев'юер, часова мітка і вказана причина, а не знизування плечима. Журнал аудиту працює лише на додавання (append-only), тому рішення не можна тихо переписати постфактум: виправлення — це нові записи, а не правки поверх старих. У нашому стеку ця черга та її модель аудиту живуть у Protocore Center (/products/center) — консолі оператора, де кожна привілейована дія потребує причини й потрапляє в журнал, який не можна непомітно змінити.

Випадки «чотирьох очей»

Деякі рішення надто відповідальні для однієї людини. Зняття справжнього збігу із санкційним списком, схвалення високоризикового профілю чи скасування автоматичної відмови мають потребувати підтвердження від другого рев'юера — maker-checker, або «чотири очі». Перший рев'юер пропонує рішення і вказує причину; другий, який має на це повноваження, підтверджує або відхиляє і вказує свою. Обидві дії журналюються. Це не недовіра до рев'юерів, а визнання того, що саме найризикованіші схвалення — це ті, де одна помилка коштує найдорожче, а другий погляд — найдешевша страховка від неї. Дизайн черги має спрямовувати такі випадки до дворокового розгляду автоматично, за причиною, а не покладатися на пам'ять рев'юерів. Але використовуйте двокроковість свідомо, лише для відповідальних кейсів: якщо застосувати її до всього, вартість усієї черги подвоїться, а рев'юери звикнуть формально ставити другий підпис, що тихо нівелює сенс його існування.

Проєктування під обсяг: старіння, пріоритезація, SLA

Черга, яка лише росте, — це черга, що провалилася. Закладайте в неї тиск, який підтримує рух. Кейси помітно «старіють», тож ніщо не лежить забутим; кожен сегмент має цільовий рівень сервісу, тому кейс із розмитим фото, що порушує свій SLA в кілька хвилин, виглядає інакше, ніж санкційний кейс у межах довшого. Пріоритезація — це реальний вибір: «найстаріший першим» — чесно й просто, але «найризикованіший першим», коли угорі найбільша потенційна експозиція, часто правильніший варіант, а вік кейсу слугує додатковим критерієм, щоб низькоризикові кейси все одно закривалися, а не голодували. Екран рев'юера має показувати наступний кейс, уже спрямований і пріоритезований, а не список для вибору — адже черга, з якої вибирають, — це черга, де незручні кейси ніхто не бере. Черга без видимого старіння тихо гниє: складні кейси тонуть на дні, а прості крутяться нагорі, і єдина метрика, що це викрила б, — вік найстарішого відкритого кейсу — це саме те число, за яким ніхто не стежить, доки не поскаржиться клієнт.

Вимірювання черги

Чотири числа показують, чи працює дизайн. STP rate каже, яка частка кейсів взагалі не потребувала людини; глибина черги та її тренд — чи ви встигаєте, чи відстаєте; time-to-decision за сегментами відносно їхнього SLA — чи клієнти надто довго чекають на онбординг; а reopen rate — частка рішень, які згодом скасували, — чи рев'юери ухвалюють рішення правильно, чи просто швидко. Дивіться на них разом, бо вони впливають одне на одне: якщо time-to-decision падає, а reopen rate росте, ви купили швидкість ціною помилок. Здорова черга — невелика, рухлива, з правильними рішеннями і чесна щодо кейсів, які в ній ще відкриті.

Бек-офіс, який уявляють собі люди, — зали співробітників, що вручну пророблюють заявки, — це те, що виходить, коли автоматизація закриває замало, а черга — одна недиференційована купа. Бек-офіс, що масштабується, — навпаки: більшість заявок взагалі не доходить до людини, ті, що доходять, приходять відсортованими за причиною та пріоритетом, кожна дія несе причину в журнал append-only, а «чотири очі» охороняють рішення, які цього варті. Будуйте чергу для винятків — і вона залишатиметься невеликою, поки ви ростете. Будуйте її як місце, де відбувається KYC, — і вона зростатиме з кожною реєстрацією.