Очередь KYC-проверки, которая масштабируется

Очередь KYC-проверки — это бэк-офисный процесс, в котором проверки личности, которые машина не смогла закрыть сама, передаются человеку. Большинство заявок должны проходить автоматически; очередь существует для остальных. Главная цель её дизайна — оставаться небольшой: хранить только настоящую неоднозначность и ничего больше, ведь очередь, заполненная случаями, которые должна была решить машина, — не контроль, а бутылочное горлышко, растущее линейно вместе с регистрациями. Если сделать очередь правильно, бэк-офис масштабируется по числу исключений, а не по объёму.

Это единственное свойство — намеренная малость — определяет все последующие решения. Начнём с разделения, которое его сохраняет.

Цель — straight-through, очередь — исключение

Straight-through processing (STP) означает, что заявка проходит от начала до конца без участия человека: документы прочитаны, личность сопоставлена, проверка по санкциям и PEP чиста, liveness пройден, решение записано. Это должен быть основной путь, а доля заявок, идущих по нему, — STP rate — единственное число, которое показывает, будет ли очередь масштабироваться. Если автоматически проходит больше девяноста процентов, в человеческую очередь попадает терпимый ручеёк; если половина выпадает на проверку, вам придётся нанимать проверяющих вслед за ростом. Очередь — не то место, где происходит KYC. Это место, где автоматический KYC признаёт, что не уверен. Поднимите STP rate — и остальные показатели улучшатся сами: меньше кейсов в очереди, короче ожидание, меньше проверяющих в найме. Стоит работать над этим напрямую — лучше съёмка документов на клиенте, понятные инструкции до снимка, пороги сопоставления, настроенные так, чтобы настоящих клиентов не отсекало слишком осторожное правило, — ведь каждый возвращённый процентный пункт — это кейс, который никогда не отнимет у кого-то полдня.

Что попадает в очередь и почему

Кейсы выпадают на проверку по конкретным, называемым причинам, и причина — самый важный атрибут кейса. Фото документа слишком размыто, чтобы его прочитать. Имя в удостоверении не совпадает с именем в заявке. Проверка по санкциям или PEP выдала возможное совпадение, которое человек должен подтвердить или отклонить. Адрес не удаётся подтвердить ни по одному источнику. Проверка liveness не пройдена, или то же лицо либо документ уже есть в другом аккаунте. Каждая из этих причин — отдельный вид работы, требующий отдельного вида суждения, и сваливать их в одну неразличимую кучу — первая ошибка очереди проверки. К тому же одна и та же причина может иметь очень разный вес: несовпадение имени может оказаться обычным расхождением из-за фамилии после замужества, а может — первым признаком украденной личности, и задача очереди — направить кейс тому, кто отличит одно от другого, а не вынуждать к поспешному вердикту там, где нужна аккуратность.

Одной очереди мало: делите по причине

Одна очередь заставляет каждого проверяющего быть универсалом, а каждый кейс — ждать позади посторонних. Сегментация по причине решает обе проблемы. Очередь возможных совпадений по санкциям разбирают люди, обученные скринингу и вынесению решений; очередь качества документов — быстрая визуальная проверка, которую младший проверяющий закрывает за секунды; очередь дублей аккаунтов — это расследование мошенничества. У каждого сегмента своя маршрутизация, свой нужный навык и свой целевой SLA, ведь размытое фото должно решаться за минуты, а настоящее санкционное совпадение заслуживает тщательного, неспешного разбора. Именно сегментация позволяет сочетать пропускную способность и строгость, а не жертвовать одним ради другого.

Очередь проверки масштабируется не наймом ревьюеров. Она масштабируется за счёт того, что вы правильно определили, каким кейсам проверка вообще не нужна, — и за счёт того, что остальные приходят уже отсортированными по причине.

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

Каждое решение ревьюера — одобрить, отклонить, эскалировать, запросить дополнительные документы — должно требовать причину и фиксироваться. Не свободный комментарий для галочки, а структурированный выбор, который объясняет, почему действие совершено, и записывается в момент совершения. Это не бюрократия, а то, что делает очередь защищаемой. Когда регулятор, аудитор или другой ревьюер спрашивает, почему аккаунт одобрили несмотря на флаг, ответ — это конкретный ревьюер, время и указанная причина, а не пожатие плечами. Журнал аудита работает только на добавление, поэтому решение нельзя тихо переписать задним числом: исправления — это новые записи, а не правки поверх старых. В нашем стеке эта очередь и модель аудита живут в Protocore Center (/products/center) — консоли оператора, где каждое привилегированное действие требует причины и попадает в журнал, который нельзя изменить незаметно.

Кейсы для четырёх глаз

Некоторые решения слишком значимы для одного человека. Снятие подтверждённого срабатывания по санкциям, одобрение профиля высокого риска или отмена автоматического отказа должны требовать подтверждения второго ревьюера — maker-checker, или «четыре глаза». Первый ревьюер предлагает решение и указывает причину; второй, обладающий нужными полномочиями, подтверждает или отклоняет и указывает свою. Оба действия логируются. Это не недоверие к ревьюерам, а понимание того, что самые рискованные одобрения — как раз те, где одна ошибка обходится дороже всего, а второй взгляд — самая дешёвая страховка от неё. Очередь должна сама направлять такие кейсы на двухшаговое решение по причине, а не полагаться на память ревьюеров. Но приберегите двухшаговую схему для значимых кейсов: если применять её ко всему, стоимость всей очереди удваивается, а ревьюеры привыкают механически ставить вторую подпись, что тихо лишает её смысла.

Проектируем под объём: старение, приоритизация, SLA

Очередь, которая только растёт, — это провалившаяся очередь. Заложите в неё давление, которое не даёт ей стоять. Кейсы заметно стареют, поэтому ничто не лежит забытым; у каждого сегмента есть целевой SLA, поэтому кейс с размытым фото, нарушивший SLA в несколько минут, виден иначе, чем санкционный кейс в рамках своего, более долгого срока. Приоритизация — реальный выбор: «старые первыми» честно и просто, но «сначала риск», с наибольшей потенциальной экспозицией наверху, часто оказывается верным решением, а возраст служит дополнительным критерием, чтобы низкорисковые кейсы всё же закрывались, а не голодали. Экран ревьюера должен показывать следующий кейс, уже распределённый и приоритизированный, а не список для выбора, — ведь очередь, из которой выбирают, это очередь, где неудобные кейсы так и не выбирают. Очередь без видимого старения тихо гниёт: сложные кейсы оседают на дно, пока лёгкие крутятся сверху, а единственную метрику, которая это бы показала — возраст самого старого открытого кейса, — никто не смотрит, пока не пожалуется клиент.

Как измерять очередь

Работает ли дизайн, показывают четыре числа. Доля STP говорит, какая часть вообще не потребовала человека; глубина очереди и её тренд — успеваете вы или отстаёте; время до решения по каждому сегменту относительно его SLA — не слишком ли долго клиенты ждут онбординга; а доля пересмотров — решений, позже отменённых, — решают ли ревьюеры верно или просто быстро. Смотрите на них вместе, потому что они уравновешивают друг друга: если время до решения падает, а доля пересмотров растёт, вы купили скорость ценой ошибок. Здоровая очередь небольшая, движется, решает правильно и честна в отношении кейсов, которые ещё в ней открыты.

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