Правила принятия решений и пороги
Каждая проверка порождает предупреждения, и вы решаете, что делает каждое предупреждение - пропустить, отправить на ревью или отклонить. Именно в этом соответствии и заключается ваша политика риска.
Каждый шаг сопоставляет свои предупреждения с действием: пропустить, отправить на ревью или отклонить. Шаг, настроенный на отклонение, останавливает воркфлоу - последующие шаги никогда не выполняются, и вы за них не платите. Поэтому порядок правил - это одновременно решение о риске и решение о стоимости.
#Где на самом деле принимаются решения
Легко думать о воркфлоу как о "наборе проверок, которые я запускаю". Проверки - это только половина дела. Вторая половина - и именно она определяет ваш процент одобрений - это то, что настроено делать с предупреждениями каждой проверки.
- У каждого узла функции свои пороги и своё решение.
- Проверка может быть обязательной или опциональной, и это само по себе решение о том, кто пройдёт дальше.
- Изменённое правило доходит до новых сессий после сохранения воркфлоу.
Для каждого шага каждое возможное предупреждение сопоставляется с одним из трёх действий:
| Действие | Эффект |
|---|---|
| Approve (или игнорировать) | Предупреждение фиксируется, но не меняет исход |
| Review | Сессия отправляется в In Review, чтобы человек принял решение |
| Decline | Сессия отклоняется, и воркфлоу останавливается |
Это соответствие и есть ваша политика, выраженная в конфигурации.
#Отклонение останавливает воркфлоу
Это поведение удивляет людей чаще всего, поэтому стоит сказать прямо: когда шаг отклоняет сессию, выполнение останавливается прямо там. Шаги после него никогда не выполняются.
Два следствия:
- В результате будут отсутствовать проверки, которые вы ожидали увидеть. Они не провалились - они просто не запустились. У сессии, отклонённой на верификации ID, не будет ни liveness, ни совпадения лиц, ни AML.
- Вы за них не платите. Оплата идёт за каждую завершённую функцию, поэтому шаг, который не выполнился, ничего не стоит.
#Использование порядка правил для управления стоимостью
Поскольку отклонение останавливает процесс, порядок шагов - это рычаг для управления расходами. Если поставить дешёвую проверку риска перед дорогим набором проверок, трафик, который всё равно не прошёл бы, отсеивается до того, как вы заплатите за дорогую часть.
Анализ устройства и IP за 0,03 $ перед полным потоком KYC - стандартный пример: он дёшево отсеивает трафик, который вы бы всё равно отклонили.
Компромисс - это пользовательский опыт и ложные срабатывания. Сигналы по устройству и IP - самые шумные проверки, которые предлагает Didit: корпоративные сети, carrier NAT и облачные браузеры ставят настоящих пользователей за общими адресами. Если завязать на них весь процесс, вы заблокируете реальных клиентов, поэтому направляйте такие случаи на review, а не на отклонение, пока не измерите собственный трафик.
#Правила, требующие суждения, а не автоматизации
Некоторые предупреждения однозначны и должны приводить к отклонению: неверная контрольная сумма MRZ, чип, чья подпись не выстраивается в цепочку до эмитента, лицо из вашего blocklist. Это нарушения целостности.
Другие почти всегда лучше отправлять на ревью:
- Частичные совпадения адреса при проверке подтверждения адреса - форматы отличаются от страны к стране.
- Частичные совпадения имени при проверке по базам данных - авторитетные источники записывают имена по-разному.
- Совпадения с низкой уверенностью в AML - распространённые имена постоянно их порождают.
- Пограничное совпадение лиц - см. пороги и оценки совпадения лиц.
- Флаг дублирующегося лица - что является мошенничеством для нового аккаунта и нормой для вернувшегося клиента.
А некоторые - это сбои удобства использования, заслуживающие повтора, а не вердикта: непрочитанный NFC-чип, размытый кадр, потерянный кадр камеры.
#Политики по возрасту
Минимальный и максимальный возраст настраиваются для каждого воркфлоу, и действие при нарушении вы выбираете сами. MINIMUM_AGE_NOT_MET может отклонять сразу, либо направлять на ревью, если ваша политика допускает исключение при наличии доказательств. Оба варианта законны; выбирайте осознанно.
#Собственные правила по извлечённым данным
Помимо сопоставления действий с предупреждениями, вы можете писать правила по данным, извлечённым на каком-то шаге - например, отклонять, если извлечённое поле принимает определённое значение. Учитывайте два момента:
- Правило может опираться только на данные, которые шаг действительно извлёк. Если OCR не извлёк поле, правилу нечего оценивать.
- Правило, которое отклоняет сессию, всё равно останавливает воркфлоу, с теми же последствиями, что описаны выше.
Если вы строите правило, которое опирается на защищённый признак, отнеситесь к этому как к юридическому вопросу для вашего отдела комплаенса, прежде чем считать это инженерной задачей.
#Тестируйте правила, а не только шаги
Шаги воркфлоу легко проверить на глаз. С правилами так не получится - единственный способ узнать, что предупреждение направляется туда, куда вы думаете, - это на самом деле вызвать это предупреждение.
Для этого и существует sandbox. Каждый сценарий принудительно вызывает одно конкретное предупреждение, поэтому вы можете сквозным образом подтвердить действие каждого правила: decline_document_expired, review_face_match_borderline, decline_aml_hit, review_poa_partial_match и так далее. См. тестирование в sandbox.
Тестируйте путь review так же тщательно, как и путь отклонения. Правило, направляющее на ревью, полезно только если кто-то реально работает с очередью, и единственный способ узнать, работает ли ваш процесс ревью, - это провести через него синтетическую сессию до того, как её будет ждать настоящий клиент.
#Изменения применяются к новым сессиям
Редактирование воркфлоу не меняет задним числом уже созданные сессии. Сессия несёт конфигурацию, с которой она была создана, поэтому после изменения правила тестируйте на новой сессии, а не перепроверяйте старую.