KYC-воронка: как повысить завершение проверки и долю одобрений без замедления решения

Как считать KYC-воронку

Прежде чем оптимизировать KYC-воронку, нужно убедиться, что все три ее ключевые метрики измеряются корректно и единообразно. Именно разночтения в определениях входа, выхода и способа расчета чаще всего искажают картину: команды сравнивают несопоставимые числа и принимают решения на основе неверных данных.

Что считать входом и выходом KYC-воронки

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

Выход воронки — момент, когда по заявке вынесено финальное решение: «одобрено», «отклонено» или «передано на ручную проверку». Ручная проверка при этом считается отдельным статусом, а не финальным решением — финальным оно станет только после того, как оператор завершит рассмотрение кейса. Если смешивать «передано оператору» с «одобрено», approval rate окажется завышенным, а реальное время до решения — недооцененным.

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

Как считать завершение проверки, долю одобрений и время до решения

Completion rate (завершение проверки) — доля пользователей, дошедших до финального шага и отправивших все необходимые данные, от числа тех, кто начал верификацию:

CR = (Количество завершенных заявок / Количество начатых) × 100 %

Показатель измеряет отсев внутри самого процесса — до того, как система начала проверку. Нормальный диапазон существенно варьируется в зависимости от сложности сценария и аудитории, однако как ориентир: процессы с одним типом документа и без дополнительных шагов достигают CR 85-95 %; многошаговые сценарии с биометрией, несколькими документами и дополнительными проверками — 60-80 %. Если CR устойчиво ниже ожидаемого диапазона, причина, как правило, кроется в UX, технических сбоях или избыточности сценария — а не в качестве алгоритмов проверки.

Approval rate (доля одобрений) считается от числа завершенных заявок, а не от всех начатых:

AR = (Количество одобренных / Количество завершенных заявок) × 100 %

Это принципиально: если включить в знаменатель незавершенные попытки, метрика смешает две разные проблемы — отсев на шагах сбора данных и качество самой проверки. Разделяя их, команда понимает, с чем именно работать: с UX и инструкциями (если низкий CR) или с порогами и алгоритмами (если низкий AR при высоком CR).

Time to decision (время до решения) — медианное и 95-й перцентиль времени от момента отправки пользователем финального пакета данных до получения им решения. Медиана показывает типичный опыт, p95 — «хвост», который чаще всего формируется очередями ручной проверки или тайм-аутами внешних проверок.

Все три метрики нужно отслеживать в разрезах: канал (web / мобильное приложение), тип документа, страна документа и сегмент риска. Сводный показатель скрывает локальные провалы: общий CR в 78 % может означать 92 % по российским паспортам и 40 % по иностранным — и это принципиально разные задачи для оптимизации.

Где KYC-воронка теряет пользователей и одобрения

Потери воронки не сосредоточены в одной точке: они распределены по трем принципиально разным этапам, каждый из которых требует отдельной диагностики, — до того как пользователь начал отправлять данные, в момент автоматической проверки документов и биометрии, а также на этапе риск-оценки и ручного разбора.

Потери до отправки документов и селфи

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

Главная причина раннего отказа — неготовность к процессу. По данным исследования Signicat, охватившего более 7 600 потребителей в 14 европейских странах, 38 % пользователей прерывали онбординг просто потому, что у них не оказалось нужных документов под рукой в момент прохождения. Еще 21 % указали, что процесс занял слишком много времени, и столько же — что объем запрашиваемых персональных данных показался им избыточным.

Толерантность пользователей к задержкам при этом снижается: если в 2020 году средний пользователь готов был ждать около 26 минут прежде, чем бросить заявку, то к 2024 году этот порог опустился до 18 минут 53 секунд. Ожидания формирует весь цифровой опыт, а не только KYC: чем быстрее работают другие сервисы, тем нетерпимее пользователь к медленному онбордингу.

Второй причиной раннего отказа служит непрозрачность старта. Если пользователь не видит заранее, что именно потребуется — какой тип документа, нужно ли делать селфи, сколько шагов впереди, — он оценивает неизвестность как высокую нагрузку и предпочитает выйти. Эти потери происходят до точки верификации и не фиксируются как технические отказы — они просто исчезают из воронки без следа.

Потери на этапе проверки документов и биометрии

Второй и технически наиболее изученный узел потерь — этап автоматической обработки загруженных данных. Здесь воронка теряет как пользователей (drop-off), так и одобрения (ложные отказы по вине системы, а не пользователя).

Самой уязвимой точкой на этом этапе оказывается переход от загрузки документа к биометрической проверке. Анализ поведенческой аналитики в одном из европейских цифровых банков выявил 45-процентный drop-off именно на этом переходе: пользователи не отказывались от открытия счета — они терпели неудачу при выполнении конкретного технического шага и не понимали, что делают не так.

Корень проблемы — отсроченная обратная связь. Если системе требуется несколько секунд или минут для обработки, а ответ приходит в виде обобщенной ошибки («документ не распознан»), пользователь не получает инструкции для исправления. Он делает повторную попытку наугад, получает тот же результат и уходит. Качество интерфейса в момент съемки — угол, освещение, расположение в кадре — напрямую влияет на то, попадет ли изображение в приемлемый диапазон для алгоритма.

Потери на риск-проверках и ручной проверке

Третий узел потерь менее очевиден, но системно значим — и он одновременно снижает и completion rate, и approval rate.

Первый источник потерь здесь — избыточные ложные срабатывания автоматических риск-фильтров. Исследования и отраслевые ревью, в том числе со ссылкой на аналитику Gartner, фиксируют, что в устаревших системах транзакционного мониторинга доля ложноположительных срабатываний может достигать 90-95 %. В контексте KYC это означает: значительная часть легитимных пользователей попадает под флаг из-за слишком жестких или неправильно откалиброванных правил — совпадение имени с санкционным списком, нетипичная география регистрации, редкий тип документа. Системы без сегментации по риску применяют одинаковые пороги ко всем: к клиенту из низкорисковой юрисдикции и к потенциально высокорисковому профилю, создавая лишнее трение там, где оно не нужно.

Второй источник потерь — очередь ручной проверки. Кейсы, не прошедшие автоматическое решение, направляются операторам. Если доля таких кейсов высока, а команда ограничена в ресурсах, время ожидания решения растет от часов до суток. По данным исследования Fenergo среди более чем 450 C-level руководителей банков, 77 % называют задержки обработки одним из ключевых факторов, приводящих к потере клиентов на этапе онбординга. Пользователь, завершивший все шаги верификации, но не получивший решения за разумное время, с высокой вероятностью уйдет — особенно если конкурирующий сервис готов принять его быстрее.

Как повысить завершение проверки

Completion rate — доля пользователей, дошедших до финального шага и отправивших полный пакет данных, от всех начавших верификацию. Этот показатель зависит не только от мотивации пользователя, но и от того, насколько сценарий проверки конструктивно устроен для завершения.

Сократить сценарий до минимально достаточного

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

Практический подход — прогрессивный KYC: на первом уровне запрашивается только то, что необходимо для решения о базовом доступе, и только при превышении риск-порога пользователь проходит расширенную проверку. Такая модель прямо закреплена в руководящих принципах FATF как допустимая при risk-based подходе — клиентам с низким профилем риска достаточно упрощенной процедуры.

Конкретно это означает: убрать из критического пути все, что не влияет на решение по конкретному сегменту пользователей. Если для оценки риска не требуется второй документ — не запрашивать его при регистрации. Если ввод данных вручную дублирует то, что AI-OCR извлекает из документа, — убрать ручной ввод. Если шаг подтверждения email не влияет ни на идентификацию, ни на комплаенс — перенести его за пределы KYC-воронки.

Проверять качество документов и селфи в момент съемки

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

Решение — перенести контроль качества на сторону клиента и выполнять его до отправки, а не после. В момент съемки SDK или веб-камерный виджет в реальном времени анализирует:

• размытость и резкость кадра;
• достаточность освещения и отсутствие засветки/теней;
• полноту захвата документа (все четыре угла в кадре);
• отсутствие бликов на ламинате или глянцевой поверхности;
• соответствие пропорций и контуров ожидаемому типу документа.

Аналогичная логика применяется к селфи: проверяются открытость лица, достаточность освещения, отсутствие тонированных очков, угол поворота головы.

Пользователь получает мгновенную подсказку — «поверните документ», «уберите блик», «поднесите ближе» — и делает повторный кадр до отправки. Это исключает цикл «отправить → подождать → получить ошибку» и напрямую увеличивает долю заявок, прошедших проверку с первой попытки. Валидация на стороне клиента не заменяет серверную, но отсекает явный брак еще до того, как он попадает в очередь на обработку.

Возвращать пользователя в незавершенную проверку без повторного ввода

Часть пользователей прерывает KYC не потому, что не хочет ее завершить, — их отвлекли, пропало соединение, разрядилось устройство. Если при возврате система встречает их пустой формой с нуля, значительная доля таких пользователей не будет перепроходить уже пройденные шаги.

Механизм восстановления сессии решает эту проблему. Принцип: каждый завершенный шаг сохраняется на сервере немедленно, а не по факту финального сабмита. При возврате пользователь видит воронку ровно в том состоянии, на котором остановился: данные, которые он уже ввел, предзаполнены; документы, которые он уже загрузил, не нужно загружать повторно; шаги, которые он уже прошел, отмечены как завершенные.

Дополнительно работает триггерная реактивация: push-уведомление, SMS или email отправляются в течение нескольких часов после прерывания с прямой ссылкой, которая возвращает пользователя именно на незавершенный шаг, а не на главную страницу. Временно́е окно наиболее эффективно в первые 24 часа — чем дольше пауза, тем ниже вероятность возврата.

Для этого идентификатор сессии должен быть устойчивым — не привязанным к конкретному устройству или браузеру: пользователь, начавший проверку на телефоне и вернувшийся с десктопа, должен попадать в ту же точку.

Как увеличить долю одобрений

Завершение проверки и ее положительный исход — разные метрики с разными точками потерь. Пользователь может пройти все шаги, предоставить все данные и все равно получить отказ — не потому, что он мошенник, а потому что система настроена слишком жестко, не поддерживает его документ или не видит достаточно данных для положительного решения. Именно здесь теряется значительная часть approval rate.

Убрать ложные отказы на автоматической проверке

Ложноположительное срабатывание (false positive) — ситуация, когда автоматическая система отклоняет легитимного пользователя, ошибочно квалифицировав его заявку как подозрительную. Прямые потери очевидны: отказ реального клиента. Менее очевидны косвенные — репутационные издержки и рост нагрузки на операторов, которые вынуждены пересматривать кейсы, изначально не требовавшие ручной проверки.

Механика false positive неоднородна, и у каждого источника своя точка воздействия.

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

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

Отсутствие агрегированного скоринга. Если каждая проверка — документ, liveness, face matching, AML — принимает решение автономно, без агрегации контекста, итоговое решение складывается из логического AND нескольких жестких порогов. Любой из них может заблокировать легитимного пользователя. Агрегированный скоринг с весовыми коэффициентами по каждому сигналу работает точнее, чем последовательный набор бинарных фильтров.

Первый шаг к сокращению false positive — их количественная оценка: разбивка отказов по причинам, анализ доли тех, которые не подтверждены ни одним дополнительным сигналом фрода. Именно эта доля и является резервом для роста approval rate без ущерба для комплаенса.

Пересмотреть пороги и маршрутизацию по сегментам риска

Единый набор правил для всех пользователей — компромисс, который одновременно пропускает часть реального фрода и блокирует часть добросовестных заявок. Более точная модель предполагает сегментацию по риску и дифференцированную маршрутизацию.

По оценке McKinsey, высокорисковые клиенты, как правило, составляют менее 5 % от входящего потока. Это означает, что стандартный поток верификации, настроенный на противодействие высокому риску, избыточно нагружает проверками более 95 % пользователей. При этом, по данным за 2024 год, только около 29 % финансовых организаций используют тиринговую методологию — подход, при котором глубина проверки определяется профилем риска конкретного заявителя, а не применяется одинаково ко всем.

На входе в воронку каждый заявитель получает предварительный скоринг по доступным сигналам: гео-признаки, тип устройства, IP, телефонный номер, поведенческие паттерны сессии. Он не заменяет KYC-проверку, но разделяет поток на сегменты:

• Низкий риск — сокращенный набор проверок, автоматическое одобрение при прохождении базового порога, без ручного маршрута.
• Средний риск — стандартный сценарий: документ + liveness + face matching + автоматический AML-скрининг.
• Высокий риск — расширенный набор: дополнительные источники данных, усиленная проверка документа, маршрут на ручную верификацию.

Ключевой эффект этого подхода — пороги одобрения настраиваются отдельно под каждый сегмент. Для низкорискового потока можно мягче трактовать пограничные значения скорингов; для высокорискового — ужесточить. Это дает рост approval rate без снижения качества комплаенса, потому что строгость применяется там, где она нужна, а не везде одновременно.

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

Расширить покрытие документов и источников данных

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

Проблема покрытия документов. Если платформа поддерживает только паспорта и водительские удостоверения стандартных юрисдикций, пользователь с региональным национальным удостоверением, документом нестандартного формата или документом, выданным в стране с неустоявшейся шаблонной базой, получит технический отказ — не потому что он ненадежен, а потому что его документ неизвестен системе. Для платформ с международной или мультирегиональной аудиторией покрытие по типам документов — это напрямую конверсия: каждый неподдерживаемый формат означает гарантированный отказ для целого сегмента пользователей.

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

Как не замедлить время до решения

Time to decision — время от момента отправки данных пользователем до получения им ответа о статусе проверки — напрямую влияет на конверсию и пользовательский опыт. Задержка свыше 30 секунд на автоматической проверке заметно увеличивает отказы от ожидания; многочасовое ожидание при ручной проверке приводит к тому, что значительная доля пользователей не возвращается за результатом. Ускорение при этом строится на архитектурных и организационных решениях, а не на упрощении требований к проверке.

До решения выполнять только блокирующие проверки

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

Риск-ориентированный подход, закрепленный в Рекомендациях FATF и директивах ЕС по AML, прямо допускает принятие предварительного решения с последующим дополнительным контролем для клиентов с низким и средним уровнем риска. На практике это означает: пользователь получает доступ к базовым функциям сразу после прохождения ключевых шагов, а расширенные проверки завершаются в фоновом режиме. Если по итогам фонового контроля обнаруживается несоответствие — доступ ограничивается, решение пересматривается.

Выполнять независимые проверки параллельно

В последовательном KYC-пайплайне каждый шаг стартует только после завершения предыдущего. Если каждая из пяти проверок занимает в среднем 1-2 секунды, суммарное время легко превышает 8-10 секунд — и это без учета сетевых задержек и очередей. При параллельном выполнении независимых шагов общее время определяется самой долгой проверкой, а не их суммой.

Независимы по данным и могут запускаться одновременно следующие операции:

• скрининг по санкционным спискам и PEP — достаточно имени и даты рождения, извлеченных OCR, ожидать результата liveness не нужно;
• проверка телефона и email — запускаются сразу после сбора контактов, параллельно с обработкой документа;
• антифрод-сигналы устройства и поведения — собираются в реальном времени, не зависят от хода документарной проверки;
• база данных ранее отклоненных заявок — может проверяться по хешу документа немедленно после загрузки.

Для реализации параллельной маршрутизации достаточно перевести архитектуру пайплайна на событийную модель: каждый модуль подписывается на события готовности нужных ему данных, а не ждет завершения всего предыдущего шага. В SaaS-решениях этот паттерн реализуется на уровне оркестратора, в on-premises-конфигурациях — через брокер сообщений с явным графом зависимостей между шагами.

Ограничить долю ручной проверки и время ожидания

Ручная проверка остается самым непредсказуемым и масштабозависимым звеном в воронке. При росте объемов очередь перегружается первой: операторы работают с фиксированной производительностью, тогда как поток заявок может увеличиться кратно. Контролируемый time to decision возможен только тогда, когда доля ручной проверки удерживается в заранее определенных пределах.

Целевые ориентиры варьируются в зависимости от отрасли и требований регулятора, однако для зрелых автоматизированных KYC-систем типичный диапазон составляет 3-10 % от общего числа заявок. Если показатель выше — причина, как правило, в завышенных порогах уверенности, недостаточном покрытии типов документов или избыточно широких правилах эскалации.

Для удержания доли ручной проверки в норме применяют несколько подходов. Первый — градуированные пороги уверенности: заявки с высоким скором проходят автоматически, с низким — уходят на проверку, а промежуточный диапазон выделяется в отдельный сегмент с упрощенным интерфейсом ревью (оператор видит только причину сомнения, а не весь кейс с нуля). Второй — ограничение очереди по SLA: если заявка ожидает ручной проверки дольше установленного времени (например, 4 или 8 часов), запускается автоматическое действие — уведомление пользователя с объяснением статуса, эскалация внутри команды или, для сегментов с допустимым риском, временное частичное одобрение с последующим дорасследованием. Третий — регулярный аудит причин эскалации: если значительная доля «ручных» заявок завершается одобрением без существенных изменений, соответствующее правило маршрутизации следует пересмотреть.

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