Перейти к основному содержимому
Didit привлёк $2 млн и присоединился к Y Combinator (W26)
Didit
В блог
Блог · 21 мая 2026 г.

6 статусов правила для переводов и проблема "восхода солнца" (RU)

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

Автор: DiditОбновлено
travel-rule-statuses-sunrise-issue.png

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

Didit предоставляет вам ровно шесть статусов. Поскольку поддержка Travel Rule встроена в систему мониторинга транзакций, каждое обязательство по каждому криптовалютному переводу разрешается в один из статусов: UNKNOWN, COMPLIANT, PENDING_ACTION, PENDING_COUNTERPARTY, FAILED или EXEMPT. Это руководство объясняет, что означает каждый статус, как действовать в каждом случае, и как эти статусы обеспечивают чистый способ решения самой сложной части соблюдения Travel Rule — проблемы «восхода солнца», когда правило действует в вашей юрисдикции, но не в юрисдикции контрагента.

Основные выводы

  • Шесть статусов, никакой двусмысленности. Каждое обязательство по Travel Rule имеет ровно один из статусов: UNKNOWN, COMPLIANT, PENDING_ACTION, PENDING_COUNTERPARTY, FAILED или EXEMPT.
  • Статус указывает, кто сейчас ждет решения — вы (PENDING_ACTION), контрагент (PENDING_COUNTERPARTY), или никто, потому что это сделано (COMPLIANT) или выходит за рамки (EXEMPT).
  • Проблема «восхода солнца» — это неравномерное глобальное принятие Travel Rule: некоторые юрисдикции его применяют, другие еще нет, что приводит к обмену данными с контрагентами, которые могут не иметь обязательства отвечать взаимностью.
  • Статусы обеспечивают чистую модель обработки проблемы «восхода солнца»: PENDING_COUNTERPARTY, FAILED и EXEMPT напрямую соответствуют случаям, которые возникают при работе с контрагентом, не принявшим правило.
  • Это работает внутри системы мониторинга транзакций по адресу POST https://verification.didit.me/v3/transactions/ с currency_kind: "crypto", с проверкой кошельков от $0.02 (с вашим собственным ключом).

Что означают шесть статусов

Каждый криптовалютный перевод, который несет обязательство по Travel Rule, получает статус travel_rule_status. Вот полный набор статусов и как действовать в каждом случае.

СтатусЗначениеЧто делать
UNKNOWNОбязательство еще не оценено, или VASP контрагента не может быть определен.Ждать разрешения; исследовать, если проблема сохраняется.
COMPLIANTДанные отправителя и получателя были обменены и подтверждены.Ничего — обязательство выполнено.
PENDING_ACTIONТребуется что-то с вашей стороны — отсутствующие данные отправителя или шаг подтверждения.Предоставить данные; рассмотреть возможность устранения AWAITING_USER, если это данные, предоставленные клиентом.
PENDING_COUNTERPARTYВы ждете ответа от VASP контрагента на обмен.Удерживать согласно политике; система отслеживает ожидание.
FAILEDОбмен не удалось завершить — недоступный контрагент, отклоненные данные или несоответствие протокола.Исследовать; решить, следует ли продолжать, блокировать или обрабатывать согласно вашей политике «восхода солнца».
EXEMPTПеревод выходит за рамки — ниже порогового значения, обработка самостоятельно размещенного кошелька или иным образом не подлежит обязательству.Продолжить; исключение записывается для аудиторского следа.

Ценность закрытого набора состоит в том, что политика становится выразимой. Вы можете сказать: «удерживать любой OUTBOUND криптовалютный перевод в статусе PENDING_COUNTERPARTY до N часов, затем эскалировать» или «автоматически продолжить при EXEMPT» — это правила, а не оценочные суждения.

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

Проверки Travel Rule не просто спрашивают, обменивались ли вы данными — они спрашивают, можете ли вы показать, для каждого перевода, каково было обязательство и почему вы продолжили или не продолжили. Шестиступенчатая модель — это аудиторский след: каждый перевод несет свой статус, причину и протокол, который осуществил (или не смог осуществить) обмен. Это разница между готовой к проверке записью и упражнением по реконструкции.

Это также важно с операционной точки зрения, потому что большинство переводов не являются COMPLIANT с первой попытки. Они находятся в состоянии PENDING_COUNTERPARTY, пока другой VASP отвечает, или попадают в состояние FAILED, потому что контрагент недоступен. Команда, которая не может четко видеть эти состояния, в конечном итоге либо блокирует хорошие переводы, либо позволяет обязательным переводам проскочить.

Проблема «восхода солнца»

Самый сложный для анализа статус — это FAILED или PENDING_COUNTERPARTY в отношении контрагента, который просто не имеет обязательства по Travel Rule, потому что его юрисдикция его не приняла. FATF установила правило; юрисдикции внедряют его по своим собственным графикам. Результатом является неравномерное глобальное покрытие: вы можете быть полностью обязаны, в то время как ваш контрагент, в юрисдикции, не принявшей правило, не обязан ничего отправлять или подтверждать. Этот пробел и есть проблема «восхода солнца» — солнце взошло над правилом в одних местах, но не в других.

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

  • Контрагент, не принявший правило и не отвечающий, отображается как PENDING_COUNTERPARTY, а затем как FAILED — а не как молчаливый пробел.
  • Ваша политика определяет, что означает FAILED из-за непринятия: продолжить с задокументированным обоснованием, удержать или заблокировать. Статус делает это решение явным и регистрируется.
  • Переводы, действительно выходящие за рамки, разрешаются в EXEMPT, поэтому вы не тратите время аналитиков на них.

Суть в том, что проблема «восхода солнца» становится документированным, управляемым политикой состоянием, а не неопределенным пограничным случаем. Когда юрисдикция контрагента примет правило, те же переводы начнут разрешаться в COMPLIANT без изменений в вашей интеграции.

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

Статусы возвращаются по транзакции, которую вы отправляете в унифицированный API /v3/.

curl -X POST https://verification.didit.me/v3/transactions/ \
  -H "x-api-key: $DIDIT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "transaction_id": "txn_a17d63",
    "category": "travel_rule",
    "amount": 3100,
    "currency": "ETH",
    "currency_kind": "crypto",
    "direction": "OUTBOUND",
    "txn_date": "2026-05-21T13:40:00Z",
    "subject": { "vendor_data": "user_5567", "role": "ORIGINATOR", "entity_type": "INDIVIDUAL" },
    "counterparty": { "role": "BENEFICIARY", "entity_type": "INDIVIDUAL", "wallet_address": "0x4c1a...77fe" }
  }'
{
  "transaction_id": "txn_a17d63",
  "status": "IN_REVIEW",
  "travel_rule_status": "PENDING_COUNTERPARTY",
  "protocol": "OpenVASP",
  "wallet_screening": { "risk_score": 22, "risk_level": "LOW" }
}

Цена. Поддержка Travel Rule включена в мониторинг транзакций. Проверка кошелька на блокчейне для адреса контрагента осуществляется параллельно от $0.02 за проверку с использованием собственного ключа (Crystal или Merkle Science).

Как статусы управляют циклом исправления

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

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

  • VASP и биржи — выражайте политики удержания и эскалации непосредственно против PENDING_COUNTERPARTY и FAILED, с автоматическим продолжением для EXEMPT.
  • Шлюзы ввода/вывода (On/off-ramps) — обрабатывайте большой объем контрагентов из разных юрисдикций, где проблема «восхода солнца» является ежедневной реальностью.
  • Кастодианы — ведите готовый к проверке, потранзакционный статус по множеству контрагентов и протоколов.
  • DeFi-фронтенды — полагайтесь на EXEMPT для переводов, действительно выходящих за рамки, и документируйте обоснование для остальных.

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

  1. Включите правила Travel Rule в Business Console наряду с мониторингом и скринингом криптовалют, и напишите свою политику «восхода солнца» как правила против статусов.
  2. Отправляйте криптовалютные переводы с POST /v3/transactions/, currency_kind: "crypto" и данными отправителя/получателя.
  3. Разветвляйте по travel_rule_status — продолжайте при COMPLIANT/EXEMPT, исправляйте при PENDING_ACTION, удерживайте при PENDING_COUNTERPARTY, исследуйте при FAILED.
  4. Обрабатывайте исключения в Console, где временная шкала статусов и рабочий процесс кейсов находятся вместе с остальным вашим мониторингом.

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

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

Какие есть шесть статусов Travel Rule?

UNKNOWN, COMPLIANT, PENDING_ACTION, PENDING_COUNTERPARTY, FAILED и EXEMPT. Статус travel_rule_status каждого перевода является ровно одним из них.

Что такое проблема «восхода солнца»?

Неравномерное глобальное принятие Travel Rule — некоторые юрисдикции его применяют, другие еще не приняли. Это приводит к обмену данными с контрагентами, которые могут не иметь обязательства отвечать взаимностью.

Как Didit обрабатывает контрагентов, не принявших правило?

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

В чем разница между PENDING_ACTION и PENDING_COUNTERPARTY?

PENDING_ACTION означает, что мяч на вашей стороне (отсутствующие данные или подтверждение). PENDING_COUNTERPARTY означает, что вы ждете ответа от другого VASP.

Является ли Travel Rule отдельным продуктом?

Нет. Он встроен в систему мониторинга транзакций, в тот же криптовалютный перевод, который вы уже отправляете для мониторинга и скрининга кошельков.

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

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

Инфраструктура для идентификации и борьбы с мошенничеством.

Единый API для KYC, KYB, мониторинга транзакций и проверки кошельков. Интеграция за 5 минут.

Попросите ИИ кратко изложить эту страницу
Статусы правила для переводов и проблема «восхода солнца» | Didit.