AWAITING_USER: Автоматическое устранение рисков для подозрительных транзакций (RU)

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

API мониторинга транзакций Didit имеет четвертый статус, созданный именно для этого пробела: AWAITING_USER. Вместо бинарного одобрения или отклонения, подозрительная транзакция может быть приостановлена, запросить конкретное действие от пользователя — повторную верификацию личности, предоставление подтверждения средств — и автоматически возобновиться в тот момент, когда он выполнит это действие. Трение возникает только там, где есть риск, и стоит оно столько же — $0.02 за транзакцию, как и все остальное.

В этом руководстве объясняется, как работает путь AWAITING_USER и как интегрировать его в ваш рабочий процесс.

Ключевые выводы

• AWAITING_USER — это один из четырех статусов транзакции — наряду с APPROVED, IN_REVIEW и DECLINED — поэтому устранение рисков является первоклассным результатом, а не обходным путем.
• Подозрительная транзакция приостанавливается вместо сбоя, запрашивает у пользователя дополнительное действие и автоматически возобновляется после выполнения действия.
• Дополнительным действием может быть повторная KYC, загрузка подтверждения средств или любой шаг верификации, запускаемый на унифицированном API /v3/.
• Веб-хуки управляют циклом — transaction.status.updated срабатывает, когда транзакция входит в статус AWAITING_USER и выходит из него.
• Тот же статус существует в управлении инцидентами, поэтому аналитик может перевести предупреждение в AWAITING_USER и позволить пользователю разрешить его.
• $0.02 за транзакцию, без минимумов. Повторная KYC или AML-проверка, запущенная во время устранения рисков, оплачивается по установленному тарифу.

Что делает AWAITING_USER

Когда срабатывает правило, система присваивает статус. Три из четырех знакомы: APPROVED пропускает транзакцию, IN_REVIEW открывает предупреждение для аналитика, а DECLINED блокирует ее. Четвертый, AWAITING_USER, делает нечто иное — он приостанавливает транзакцию и сигнализирует, что пользователь должен что-то сделать, прежде чем она будет разрешена.

Конкретно: перевод срабатывает на правило высокой стоимости или высокой скорости, система возвращает AWAITING_USER, ваше приложение предлагает пользователю выполнить запрошенный шаг (новую проверку на живость, загрузку документа, декларацию источника средств), и сессия верификации передает данные обратно на платформу. После выполнения шага транзакция переоценивается и переходит в статус APPROVED (или эскалируется, если новые доказательства ухудшают ситуацию). Аналитику не нужно за этим следить.

Почему это важно

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

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

Технические детали

Транзакция, которую система направляет на устранение рисков, возвращается со статусом AWAITING_USER и правилами, которые ее вызвали:

{
  "transaction_id": "txn_77c9e2",
  "status": "AWAITING_USER",
  "risk_score": 71,
  "triggered_rules": [
    { "name": "High-value transfer — first 30 days", "bundle": "AML/CTF", "action": "CHANGE_STATUS" }
  ],
  "required_action": "PROOF_OF_FUNDS",
  "alert_id": "alrt_5e3f10"
}

Вы реагируете, предлагая пользователю и запуская шаг верификации на унифицированном API /v3/. Когда шаг завершен, веб-хук сообщает вам, что транзакция продолжила движение:

# полезная нагрузка веб-хука: transaction.status.updated
{
  "event": "transaction.status.updated",
  "transaction_id": "txn_77c9e2",
  "previous_status": "AWAITING_USER",
  "status": "APPROVED"
}

Веб-хуки. Подпишитесь на transaction.created и transaction.status.updated. Событие обновления статуса срабатывает как при входе транзакции в статус AWAITING_USER, так и при выходе из него — так что ваш реестр и ваш пользовательский интерфейс остаются синхронизированными без опроса.

Цена. $0.02 за транзакцию. Сам шаг по устранению рисков оплачивается по собственному установленному тарифу: повторная KYC по тарифам верификации пользователя, AML-проверка подозрительной стороны по $0.20.

Цикл устранения рисков, шаг за шагом

1. Срабатывание правила. Транзакция пересекает порог, который, согласно вашей политике, должен быть устранен, а не отклонен — например, первый перевод высокой стоимости с нового счета.
2. Пауза, а не сбой. Система возвращает AWAITING_USER вместо DECLINED с прикрепленным требуемым действием.
3. Запрос пользователю. Ваше приложение отображает дополнительный шаг — повторную проверку на живость, загрузку документа, декларацию источника средств — и запускает сессию верификации.
4. Пользователь выполняет. Пользователь завершает шаг в том же рабочем процессе, в котором он уже находился.
5. Автоматическое возобновление. Транзакция переоценивается с новыми доказательствами и переходит в статус APPROVED — или эскалируется до IN_REVIEW/DECLINED, если доказательства повышают риск. Веб-хук transaction.status.updated сообщает вашей серверной части о любом изменении.

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

Сценарии использования

• Финтех — первый перевод высокой стоимости со недавно зарегистрированного счета приостанавливается для подтверждения средств, а не блокирует клиента.
• Криптовалюты — исходящий перевод на кошелек с повышенным риском приостанавливается для декларации источника средств перед проведением.
• Кредитование — выплата, которая срабатывает на сигнал синтетической личности, приостанавливается для повторной проверки на живость KYC.
• Торговые площадки — выплата продавцу, которая срабатывает на правило скорости, приостанавливается для повторной верификации до выпуска средств.
• iGaming — всплеск скорости депозитов приостанавливается для дополнительной проверки, которая также служит точкой контакта для ответственной игры.

Как интегрироваться с Didit

1. Определите свою политику устранения рисков. В Бизнес-консоли установите, какие правила направляются в AWAITING_USER вместо DECLINED, и какое дополнительное действие запрашивает каждое из них.
2. Отправляйте транзакции. POST /v3/transactions/ по мере перемещения денег, со стабильным transaction_id и vendor_data, связывающими каждую с ее пользователем.
3. Обработайте паузу. Когда транзакция возвращает AWAITING_USER, предложите пользователю и запустите шаг верификации на API /v3/.
4. Слушайте возобновление. Реагируйте на transaction.status.updated, чтобы выпустить или удержать транзакцию после того, как пользователь завершит шаг.

Поскольку все это на унифицированном API /v3/, KYC для устранения рисков, который запускает подозрительная транзакция, является тем же KYC, который вы используете для регистрации пользователей — одна платформа идентификации и борьбы с мошенничеством, от начала до конца.

Часто задаваемые вопросы

Что такое AWAITING_USER?

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

Транзакция возобновляется сама по себе?

Да. После выполнения запрошенного шага транзакция переоценивается и автоматически переходит в статус APPROVED — или эскалируется, если новые доказательства повышают риск. Веб-хук transaction.status.updated срабатывает при изменении.

Каким может быть дополнительный шаг?

Любой шаг верификации на унифицированном API /v3/ — повторная проверка на живость KYC, повторная верификация документа, AML-проверка или загрузка подтверждения средств.

Нужно ли участие аналитика?

Нет. Цикл автоматического устранения рисков работает без аналитика. Но то же состояние AWAITING_USER существует в управлении инцидентами, поэтому аналитик также может отправить предупреждение обратно пользователю, когда он решит это сделать.

Сколько это стоит?

$0.02 за транзакцию. Шаг по устранению рисков оплачивается по своему тарифу — повторная KYC по тарифам верификации пользователя, AML-проверка по $0.20.

Готовы начать?

Прочитайте обзор мониторинга транзакций в документации, посмотрите, как он вписывается в остальную часть платформы на странице продукта «Мониторинг транзакций», и проверьте прозрачные цены за вызов на странице цен. Когда будете готовы, начните бесплатно — 500 бесплатных KYC-проверок каждый месяц и мониторинг транзакций по $0.02 за вызов.