Travel Rule API по FATF для VASP: комплаенс

​

Обзор

• Вы отправляете перевод с transaction_category: "travelRule".
• Didit перебирает каналы в порядке приоритета, чтобы связаться с поставщиком-контрагентом, проводит обмен через первый канал, по которому удаётся связаться с ним, и, если другая сторона возвращает имя получателя, сверяет его с тем, которое отправили вы.
• Только после того, как обмен перейдёт в статус COMPLETED, следует транслировать перевод ончейн.
• Затем вы передаёте в Didit хеш блокчейн-транзакции, чтобы закрыть обмен со статусом FINISHED.

​

Что выполняется при отправке перевода

1. Валидация и привязка субъекта. Payload проверяется. Если transaction_id уже использовался в вашем приложении, запрос отклоняется с кодом 400. Если два запроса с одинаковым идентификатором приходят одновременно, один из них получает 409. subject связывается с вашим профилем пользователя или компании через vendor_data, чтобы перевод отображался в этом профиле для мониторинга. Если vendor_data субъекта или контрагента находится в списке блокировки, запрос отклоняется с кодом 400, и транзакция не создаётся. Кошельки, банковские счета, IP-адреса и устройства из списка блокировки проверяются на шаге 6, где транзакция отклоняется уже после маршрутизации.
2. Обогащение данными об устройстве и сети. IP-адреса участников обогащаются геоданными. Контекст устройства (он передаётся автоматически при отправке через SDK) нормализуется и попадает в граф устройств. Это тот же граф, который наполняют сессии KYC, поэтому связь «по устройству» работает и при онбординге, и для транзакций.
3. Криптоскрининг. Для криптопереводов с включённым мониторингом соответствующий кошелёк (или ончейн-хеш) проверяется в аналитике блокчейна до того, как начнётся какой-либо обмен: риск санкций, близость к миксерам, украденные средства. См. Криптоскрининг и скрининг кошельков.
4. Перевод Travel Rule. Движок обмена проверяет порог и учитывает декларацию о некастодиальном кошельке, после чего сохраняет перевод. Статус будет NOT_APPLICABLE, если сумма ниже вашего порога; UNCONFIRMED_OWNERSHIP для заявленного некастодиального кошелька; COMPLETED, если второй кошелёк принадлежит вам и проверен. Во всех остальных случаях AWAITING_COUNTERPARTY, а канал на этом этапе ещё не выбран. Каждое изменение статуса ставит в очередь событие travel_rule.status.updated. Didit отправляет его после transaction.created (шаг 7).
5. Выпуск сессии подтверждения владения кошельком. Если переводу нужно подтверждение контроля над кошельком со стороны конечного пользователя и включён параметр auto_wallet_verification, создаётся сессия виджета подтверждения владения кошельком, которая возвращается в action_required.
6. Оценка правил. Выполняются все активные правила. Пакет правил EU TFR реагирует на статус перевода, заданный на шаге 4. Ваши пользовательские правила видят результаты скрининга шага 3. Правило может удержать транзакцию (IN_REVIEW), отклонить её или потребовать дополнительной верификации (AWAITING_USER).
7. Биллинг и уведомления. За исходящую транзакцию взимается плата по одной строке: линия Travel Rule, если она запустила обмен, и скрининг транзакций в остальных случаях. С входящего перевода плата не взимается, а за приложение в песочнице плата никогда не взимается. Ответ возвращается, после чего transaction.created отправляется на ваши адреса назначения webhook, а затем следуют события travel_rule.status.updated шага 4.
8. Маршрутизация, после ответа. Didit последовательно перебирает семь каналов в порядке приоритета. Если ни один из них не разрешает маршрут, атрибуция контрагента по аналитике блокчейна определяет контрагента, и каналы проверяются повторно один раз. Первый доступный канал ведёт обмен: перевод остаётся в AWAITING_COUNTERPARTY на этом канале, пока контрагент отвечает. Если найден контрагент INTERNAL, перевод сразу завершается (COMPLETED или COUNTERPARTY_MISMATCHED_DATA). Если ни один канал не достигает контрагента, статус становится COUNTERPARTY_VASP_NOT_FOUND. Каждое изменение запускает travel_rule.status.updated, а правила вычисляются заново при каждом изменении статуса или канала. Для перевода, который маршрутизация оставила в COUNTERPARTY_VASP_NOT_FOUND, сессия виджета подтверждения владения кошельком создаётся в этот момент (если включён auto_wallet_verification). Получить её можно из action_required транзакции с помощью Получить транзакцию.

​

Как каждый этап соответствует вашим обязательствам

​

Lifecycle

​

Доставка и повторные попытки

​

Устаревшие значения статусов

​

Настройка

curl -X GET https://verification.didit.me/v3/travel-rule/settings/ \
  -H "x-api-key: YOUR_API_KEY"

{
  "is_enabled": false,
  "jurisdiction": "EU",
  "name_matching_strictness": "DEFAULT",
  "confirmation_timeout_hours": 48,
  "timeout_outcome": "HOLD",
  "threshold_amount": "0.00",
  "inbound_auto_accept": true,
  "allow_self_declaration": true,
  "allow_screenshot_proof": true,
  "auto_wallet_verification": true,
  "vasp_attribution_enabled": true,
  "counterparty_screening_enabled": false,
  "sunrise_policy": "",
  "sunrise_jurisdictions": ["CO", "KH", "VN"],
  "non_responsive_policy": "",
  "legal_name": "",
  "lei": "",
  "compliance_email": "",
  "is_discoverable": true,
  "travel_address": "",
  "disabled_networks": [],
  "networks": {
    "gtr": { "rail": "GTR", "mode": "unavailable", "platform_available": false, "connected": false },
    "trust": { "rail": "TRUST", "mode": "unavailable", "platform_available": false, "connected": false },
    "verifyvasp": { "rail": "VERIFYVASP", "mode": "unavailable", "platform_available": false, "connected": false },
    "sygna": { "rail": "SYGNA", "mode": "unavailable", "platform_available": false, "connected": false }
  }
}

curl -X PUT https://verification.didit.me/v3/travel-rule/settings/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "is_enabled": true,
    "legal_name": "Origin CASP SL",
    "jurisdiction": "EU",
    "name_matching_strictness": "DEFAULT",
    "confirmation_timeout_hours": 48,
    "timeout_outcome": "HOLD",
    "is_discoverable": true
  }'

​

Строгость сопоставления имён

​

Режимы проверки владения

​

Передача данных

{
  "data_sharing_fields": {
    "individual": ["name", "wallet_address", "address", "date_of_birth"],
    "company": ["name", "wallet_address", "address"]
  }
}

• Физические лица могут передавать name, wallet_address, address, national_id, customer_identification, date_of_birth и place_of_birth. Компании передают первые пять.
• name и wallet_address передаются всегда.
• Тип субъекта, который вы никогда не выбирали, передаёт все поля. Пустой список тоже является выбором: он передаёт только имя и кошелёк.
• PUT объединяет настройки по типу субъекта, поэтому отправка individual не меняет сохранённый выбор для company.
• Выбор, который не может выполнить обязательства отправителя по вашей jurisdiction (режим EU TFR или FATF Recommendation 16), включая пустой список, отклоняется с 400. Ошибки приводятся в data_sharing_fields по типу субъекта.

​

Сопоставление по полям

{
  "matching_rules": {
    "individual": { "name": "DEFAULT", "date_of_birth": "STRICT", "address": "NONE", "account": "STRICT" },
    "company": { "name": "FUZZY", "address": "NONE", "account": "STRICT" }
  }
}

​

Пороги по юрисдикциям

​

Модель данных IVMS 101

• Латиница. IVMS 101 требует значения в латинице, поэтому транслитерируйте имена, написанные с использованием другой системы письма. Сопоставление имён в Didit сравнивает нормализованные наборы токенов, поэтому различия в порядке слов и регистре не приводят к сбою обмена, а разные системы письма на двух сторонах приводят к сбою обмена.
• Отправляйте проверенные данные. Если субъект, к которому относится vendor_data, является пользователем с одобренной верификацией KYC в Didit, Didit передаёт проверенную личность, а не значения, которые вы ввели: см. Проверенные данные и происхождение. Для любого другого субъекта Didit передаёт именно те originator_data, которые вы отправили, поэтому формируйте их из личности, которую вы проверили при онбординге, а не из непроверенного поля формы. Именно этого требует формулировка FATF «необходимая и точная информация об отправителе». На канале INTERNAL приложение получателя также получает subject, который вы отправили (имя, vendor_data, дату рождения, страну и адрес), как контрагента его входящей транзакции.

​

Проверенные данные и происхождение

• отправитель исходящего перевода, который вы создаёте через POST /v3/transactions/;
• получатель входящего перевода, о котором вы сообщаете через POST /v3/transactions/, или через POST /v3/travel-rule/inbound/, если holder_vendor_data сопоставленного кошелька указывает на этого пользователя.

{
  "metadata": {
    "originator_provenance": { "name": "verified", "date_of_birth": "verified", "customer_identification": "caller" },
    "originator_verified_differences": {
      "name": { "caller": "Jane Doe", "verified": "Jane Elizabeth Doe" }
    }
  }
}

​

Отправка IVMS 101 напрямую

• блок originator и блок beneficiary, где originatorPersons или beneficiaryPersons содержат naturalPerson или legalPerson, а также accountNumber;
• те же блоки внутри объекта ivms101 (или IVMS101);
• одно лицо IVMS 101 или целый блок как originator_data или beneficiary_data.

{
  "travel_rule_details": {
    "status": "AWAITING_COUNTERPARTY",
    "beneficiary": {
      "beneficiaryPersons": [
        {
          "naturalPerson": {
            "name": { "nameIdentifier": [{ "primaryIdentifier": "Ruiz", "secondaryIdentifier": "Carlos", "nameIdentifierType": "LEGL" }] }
          }
        }
      ],
      "accountNumber": ["0xBeneficiaryWallet01"]
    }
  }
}

​

Обязательные данные по режимам

​

Travel Addresses

ta2ih1MicegQ3JqiKz9xT89KsSuwaDJYw8DgzmeSEp1h9tduJcNDZ5SgKLEHeyGMcS1s2HgbM6undFrMQknhM5aTXw3G9KBzi16hx

​

Тестирование без сетевых учётных данных

• Исходящие в песочнице: отправьте транзакцию travelRule из приложения песочницы. После проверок порога и некастодиального кошелька Didit Test VASP отвечает на неё внутри Didit по сценарию, который вы выберете по кошельку или имени получателя: принятие, отклонение, несовпадение имени, недоступен, таймаут или некастодиальный. Ни сеть, ни электронная почта, ни другой клиент Didit ничего не получают.
• Входящие в песочнице: попросите тестовый VASP отправить вам перевод с помощью Trigger Test VASP Inbound Transfer или зарегистрируйте его сами через Register Inbound Travel Rule Transfer. Проверьте неизвестный кошелёк, непроверенный кошелёк, несовпадение имени получателя и проверенный совпадающий кошелёк. Эти сценарии воспроизводят реальные решения по входящим переводам без обращения к сети.
• Два контролируемых продакшн-приложения: используйте канал INTERNAL между двумя вашими продакшн-приложениями (принимающее приложение доступно для поиска и подтверждает контроль над кошельком назначения подписанным сообщением или тестовым депозитом) либо контролируемого контрагента TRP, чтобы протестировать обмен между двумя сторонами без коммерческих сетевых учётных данных. Продакшн-приложения могут приводить к обычным списаниям и уведомлениям, поэтому используйте тестовые данные о личности и контрагентов, которых вы контролируете.

​

Отправка перевода

1. Если сумма ниже настроенного вами threshold_amount, перевод сразу переходит в NOT_APPLICABLE, и никакой обмен не выполняется.
2. Если платёжный метод контрагента указывает, что адрес назначения принадлежит некастодиальному кошельку (payment_method.method_type: "unhosted_wallet"), каналы не пробуются: перевод сразу переходит в UNCONFIRMED_OWNERSHIP, и виджет подтверждения владения кошельком создаётся автоматически (см. Объявленные некастодиальные кошельки).
3. В остальных случаях каналы запускаются в порядке приоритета, и первый канал, который может связаться с контрагентом, ведёт обмен:
   • INTERNAL – ровно один другой клиент Didit имеет подписанное сообщение или тестовый депозит как доказательство владения beneficiary_data.wallet_address, созданное после последней смены владельца кошелька. Ваше собственное приложение никогда не учитывается, а если ваш конечный пользователь выбрал участника сети Didit в виджете подтверждения владения кошельком, учитывается только доказательство этого участника. Приложение этого клиента работает в продакшн-среде (не в песочнице), имеет включённое Travel Rule и установленный is_discoverable, а также является тем VASP, которого вы указали при передаче counterparty_vasp_lei или counterparty_vasp_name. Кошелёк, который только заявлен самостоятельно, подтверждён скриншотом, не верифицирован или лишь указан в адресной книге, никогда не получает ничего через INTERNAL.
   • TRP – для актива перевода в сети перевода есть сопоставление Digital Token Identifier (см. Идентификаторы активов TRP), и в payload передан beneficiary_data.travel_address, либо в записи адресной книги получателя сохранён такой адрес, либо контрагент находится в справочнике (по counterparty_vasp_lei или counterparty_vasp_name) и имеет endpoint TRP.
   • GTR, TRUST, VERIFYVASP, SYGNA – вы подключили собственное членство в этой сети в разделе Marketplace, и контрагент определяется по идентификатору сети (явное поле или запись в справочнике, см. Поля определения контрагента). У Didit пока нет членства в платформе в этих сетях (компания проходит подключение как провайдер), поэтому disabled_networks на сегодня не меняет этот шаг.
   • EMAIL – передан beneficiary_data.counterparty_vasp_email, или counterparty_vasp_name соответствует записи в справочнике с контактной электронной почтой для комплаенса.
4. Если ни один канал не может определить контрагента, Didit запускает цепочку поиска контрагента. Если включён vasp_attribution_enabled, цепочка включает атрибуцию через блокчейн-аналитику: адрес назначения кошелька сопоставляется с VASP, которому принадлежит кошелёк, атрибутированное имя записывается в beneficiary_data.counterparty_vasp_name (если поле пустое) и в справочник, после чего каналы запускаются повторно один раз. Поэтому кошелёк, атрибутированный VASP, у записи которого в справочнике есть endpoint TRP, идентификатор сети или контактная электронная почта для комплаенса, маршрутизируется уже на этом втором проходе.
5. Если контрагент всё ещё не определён, перевод переходит в COUNTERPARTY_VASP_NOT_FOUND. Для исходящих переводов Didit автоматически создаёт виджет подтверждения владения кошельком (когда включён auto_wallet_verification), чтобы перевод всё же мог завершиться как перевод на некастодиальный кошелёк. Позже, когда будут более точные данные о контрагенте, вы можете повторно запустить маршрутизацию с action: "resend".

​

Идентификаторы активов TRP

​

Поиск контрагента

​

Поля определения контрагента

​

Типы цепочек

​

Переводы UTXO

• Отправитель: originator_data.wallet_address, если вы его передали, иначе адрес входа, который внёс наибольший вклад (source: largest_input).
• Получатель: указанный кошелёк, иначе единственный выход, который не возвращает сдачу на адрес входа (only_non_change_output), иначе один выход, сумма которого равна сумме перевода (amount_match).

curl -X POST https://verification.didit.me/v3/transactions/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "transaction_id": "btc-withdrawal-0042",
    "transaction_category": "travelRule",
    "transaction_details": {
      "direction": "outbound",
      "amount": "0.25",
      "currency": "BTC",
      "currency_kind": "crypto"
    },
    "subject": { "vendor_data": "user-042", "full_name": "Ana Diaz" },
    "counterparty": { "full_name": "Luis Perez" },
    "travel_rule_details": {
      "status": "AWAITING_COUNTERPARTY",
      "beneficiary_data": { "name": "Luis Perez", "counterparty_vasp_name": "Destination Exchange" },
      "utxo": {
        "inputs": [
          { "address": "bc1qsenderhotwallet01", "amount": "0.30" },
          { "address": "bc1qsendercoldwallet02", "amount": "0.05" }
        ],
        "outputs": [
          { "address": "bc1qbeneficiarydeposit01", "amount": "0.25" },
          { "address": "bc1qsenderhotwallet01", "amount": "0.0999" }
        ]
      }
    }
  }'

{
  "chain_details": {
    "chain": "BTC",
    "shape": "utxo",
    "originator": { "address": "bc1qsenderhotwallet01", "memo": "", "source": "largest_input" },
    "beneficiary": { "address": "bc1qbeneficiarydeposit01", "memo": "", "source": "only_non_change_output" },
    "utxo": {
      "inputs": [
        { "address": "bc1qsenderhotwallet01", "amount": "0.300000000000000000" },
        { "address": "bc1qsendercoldwallet02", "amount": "0.050000000000000000" }
      ],
      "outputs": [
        { "address": "bc1qbeneficiarydeposit01", "amount": "0.250000000000000000" },
        { "address": "bc1qsenderhotwallet01", "amount": "0.099900000000000000" }
      ],
      "change_output_indexes": [1],
      "beneficiary_output_index": 0
    }
  }
}

​

Сети с memo и тегами

• Запись адресной книги с memo совпадает только с переводами, в которых указано это memo. Запись без memo совпадает со всем адресом. Перевод без memo никогда не попадает в запись, которая его имеет: на общем адресе депозит без тега никому не принадлежит.
• X-адрес XRP содержит тег внутри себя: Didit разделяет его на классический адрес и тег (source: x_address), поэтому кошелёк, зарегистрированный в любой из этих форм, сопоставляется с переводом в другой форме.
• Каждое memo на общем адресе является отдельным способом оплаты в транзакции.
• Что принимает каждая сеть: destination tag XRP - целое число от 0 до 4294967295 (допускается число в JSON); memo Stellar - текст до 28 байт, 64-битный идентификатор или 32-байтовый хеш в hex; EOS принимает до 256 байт, Cosmos до 256 символов, Hedera до 100 байт. memo в сети, которая его не поддерживает (Bitcoin, EVM-сети, Solana, Tron, Litecoin, Bitcoin Cash, Dogecoin, Lightning), возвращает 400.

​

Lightning

​

Обновление кошелька отправителя

curl -X PATCH "https://verification.didit.me/v3/transactions/$TRANSACTION_ID/travel-rule/" \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "action": "update_originator_wallet", "wallet_address": "bc1qsendercoldwallet02" }'

• Только для исходящих переводов, и никогда для переводов со статусом CANCELLED или EXPIRED (409).
• Если входы UTXO перевода известны, кошелёк должен быть одним из них (иначе 400). В сети с memo отправьте также memo.
• Изменяется только запись: контрагенту ничего не отправляется повторно, статус сохраняется. chain_details.originator становится новым кошельком с source: updated, в timeline фиксируются предыдущий и новый кошелёк, а встречная запись INTERNAL перевода обновляется так же.

​

Атрибуция в блокчейн-аналитике

1. Фиксирует атрибуцию в переводе: beneficiary_data.counterparty_vasp_name заполняется (если вы не передали его сами), а метаданные перевода содержат блок vasp_attribution с названием сущности и типом сущности, страной и source: "blockchain_analytics".
2. Добавляет организацию в справочник VASP (или сопоставляет с существующей записью), чтобы атрибуция оставалась стабильной между переводами.
3. Повторно запускает каналы один раз с атрибутированным названием. Запись справочника, уже содержащая endpoint TRP, сразу направляет перевод по маршруту, вместо того чтобы он попадал в COUNTERPARTY_VASP_NOT_FOUND.

curl -X POST https://verification.didit.me/v3/transactions/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "transaction_id": "trv-2026-07-05-001",
    "transaction_category": "travelRule",
    "transaction_details": {
      "direction": "outbound",
      "action_type": "transfer",
      "amount": "0.25",
      "currency": "ETH",
      "currency_kind": "crypto"
    },
    "subject": {
      "entity_type": "individual",
      "vendor_data": "user-042",
      "full_name": "Jane Doe"
    },
    "travel_rule_details": {
      "status": "AWAITING_COUNTERPARTY",
      "originator_data": {
        "first_name": "Jane",
        "last_name": "Doe",
        "date_of_birth": "1990-04-12",
        "residence_country": "ES",
        "customer_identification": "user-042",
        "wallet_address": "0x135908330861442a814796ae99feac507925782a"
      },
      "beneficiary_data": {
        "wallet_address": "0xede2d7e4f5b097e6391ab6bbcf2f47a53f4778cb",
        "name": "Ana Diaz",
        "counterparty_vasp_email": "compliance@bene-casp.example"
      }
    }
  }'

{
  "uuid": "22222222-3333-4444-5555-666666666666",
  "txn_id": "trv-2026-07-05-001",
  "transaction_type": "travelRule",
  "direction": "OUTBOUND",
  "status": "APPROVED",
  "amount": "0.25",
  "currency": "ETH",
  "currency_type": "crypto",
  "travel_rule": {
    "uuid": "33333333-4444-5555-6666-777777777777",
    "status": "AWAITING_COUNTERPARTY",
    "protocol": null,
    "required": true,
    "obligations_count": 0,
    "originator_data": {
      "first_name": "Jane",
      "last_name": "Doe",
      "date_of_birth": "1990-04-12",
      "residence_country": "ES",
      "customer_identification": "user-042",
      "wallet_address": "0x135908330861442a814796ae99feac507925782a"
    },
    "beneficiary_data": {
      "wallet_address": "0xede2d7e4f5b097e6391ab6bbcf2f47a53f4778cb",
      "name": "Ana Diaz",
      "counterparty_vasp_email": "compliance@bene-casp.example",
      "chain": "ETH"
    },
    "metadata": {
      "compliance_email_source": "caller_supplied"
    }
  },
  "action_required": null
}

• originator_data содержит то, что вы отправили, потому что у субъекта в примере нет одобренной верификации KYC; для проверенного пользователя Didit формирует его из проверенных данных (см. Проверенные данные и их происхождение). Канал EMAIL показывает получателю только те поля отправителя, которыми вы делитесь в data_sharing_fields.
• beneficiary_data.chain равен ETH, так как в запросе сеть не была указана и Didit определила её по валюте.
• status равен APPROVED, так как ни одно правило не повлияло на транзакцию; ваши собственные правила могут установить другой статус.
• Контакт комплаенса получает ссылку для получения, и перевод завершается, не проходит проверку совпадения имени или отклоняется, когда он отвечает, либо истекает, если он не отвечает (см. Получение через email).

curl -X PATCH https://verification.didit.me/v3/transactions/22222222-3333-4444-5555-666666666666/travel-rule/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"payment_txn_id": "0x5c504ed432cb51138bcf09aa5e8a410dd4a1e204ef84bfed1be16dfba1b22060"}'

curl -X PATCH https://verification.didit.me/v3/transactions/22222222-3333-4444-5555-666666666666/travel-rule/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"action": "resend"}'

​

Почему перевод застрял

• reason содержит машиночитаемую причину, "" для любого другого статуса.
• next_actions содержит список действий, которые продвигают перевод дальше, [] для любого другого статуса.
• delivery содержит самое новое сообщение, которое перевод должен отправить другой стороне: kind, status (QUEUED, SENDING, RETRYING, DELIVERED или FAILED), rail, attempts, last_error, next_attempt_at и delivered_at, либо null, если ему нечего было отправлять.
• discovery показывает, где Didit искал контрагента, по одной записи на каждый выполненный шаг: step, outcome (match, miss или skipped), reason, vasp, rail и at.

{
  "uuid": "33333333-4444-5555-6666-777777777777",
  "status": "COUNTERPARTY_VASP_NOT_REACHABLE",
  "protocol": "EMAIL",
  "direction": "OUTBOUND",
  "rail": "EMAIL",
  "counterparty_vasp": null,
  "delivery": {
    "kind": "SEND",
    "status": "FAILED",
    "rail": "EMAIL",
    "attempts": 1,
    "last_error": "email undeliverable",
    "next_attempt_at": null,
    "delivered_at": null
  },
  "reason": "email_undeliverable",
  "next_actions": [
    { "action": "update_compliance_email" },
    { "action": "resend" }
  ]
}

curl -X PATCH https://verification.didit.me/v3/transactions/22222222-3333-4444-5555-666666666666/travel-rule/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"action": "update_compliance_email", "compliance_email": "desk@bene-casp.example"}'

curl -X PATCH https://verification.didit.me/v3/transactions/22222222-3333-4444-5555-666666666666/travel-rule/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"action": "resend"}'

​

Объявленные некастодиальные кошельки

curl -X POST https://verification.didit.me/v3/transactions/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "transaction_id": "trv-2026-07-07-002",
    "transaction_category": "travelRule",
    "transaction_details": {
      "direction": "outbound",
      "action_type": "transfer",
      "amount": "0.25",
      "currency": "ETH",
      "currency_kind": "crypto"
    },
    "subject": {
      "entity_type": "individual",
      "vendor_data": "user-042",
      "full_name": "Jane Doe"
    },
    "counterparty": {
      "entity_type": "external",
      "full_name": "Jane Doe",
      "payment_method": {
        "method_type": "unhosted_wallet",
        "account_id": "0xd3b62acb76fb27a7f8961ec40fa11746b113aca9"
      }
    },
    "travel_rule_details": {
      "status": "AWAITING_COUNTERPARTY",
      "beneficiary_data": {
        "wallet_address": "0xd3b62acb76fb27a7f8961ec40fa11746b113aca9",
        "name": "Jane Doe"
      }
    }
  }'

• Ни один канал не используется: контрагента-VASP, с которым можно обменяться данными, нет, и перевод сразу создаётся в статусе UNCONFIRMED_OWNERSHIP.
• Если auto_wallet_verification включён (по умолчанию), Didit автоматически создаёт сессию виджета подтверждения владения кошельком, привязанную к транзакции, и возвращает её в блоке action_required транзакции; SDK запускают её автоматически при отправке на стороне клиента.
• Как только клиент подтверждает владение кошельком, перевод выполняет сверку имени получателя и переходит в COMPLETED (или в COUNTERPARTY_MISMATCHED_DATA, если сверка не прошла).

​

Получение

​

Подтверждение владения кошельком

• Входящий перевод сопоставляется с записью в адресной книге, владение которой ещё не подтверждено.
• Кошелёк контрагента заявлен как некастодиальный (counterparty.payment_method.method_type: "unhosted_wallet") при исходящем выводе средств или входящем зачислении. См. Заявленные некастодиальные кошельки.

curl -X POST https://verification.didit.me/v3/transactions/{transaction_uuid}/travel-rule/ownership/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"confirmed": true}'

• UNCONFIRMED_OWNERSHIP, в любом направлении.
• ON_HOLD для входящего перевода.
• UNCONFIRMED_OWNERSHIP, ON_HOLD или COUNTERPARTY_MISMATCHED_DATA для входящего перевода TRP, чтобы комплаенс-офицер мог вручную обработать запрос контрагента.

• confirmed: true помечает соответствующую запись в адресной книге как подтверждённую в отношении владения, затем проводит сверку имени с полем holder_name этой записи: COMPLETED, если проверка пройдена, и COUNTERPARTY_MISMATCHED_DATA, если нет. Соответствующая сторона перевода по каналу INTERNAL, если она есть, получает тот же результат. Для заявленного некастодиального кошелька confirmed: true фиксирует, что ваш клиент подтвердил, кто контролирует кошелёк контрагента, и завершает перевод (COMPLETED), исходящий или входящий. Входящий перевод, зачисление по которому уже произведено, сразу переходит в FINISHED.
• confirmed: false переводит обе стороны перевода в COUNTERPARTY_VASP_GENERAL_DECLINE.
• Соответствующая запись ищется в вашей адресной книге только по адресу кошелька, без учёта блокчейна. Подтверждение входящего перевода в ON_HOLD без соответствующей записи создаёт запись из beneficiary_data.wallet_address и помечает её как подтверждённую. Исключение составляет заявленный некастодиальный кошелёк: он регистрируется в адресной книге как подтверждённый по владению, как описано ниже. Во всех остальных случаях отсутствие записи возвращает 409 с {"detail": "wallet address entry no longer available"}. Такой же ответ возвращает и удалённая запись.

• confirmed: true требует платёжный адрес, который берётся из wallet_address в запросе, затем из найденной записи и, наконец, из beneficiary_data.wallet_address. Если ни один из трёх не задан, запрос возвращает 400 с {"wallet_address": ["wallet_address is required to approve."]}. Didit создаёт или подтверждает запись, отправляет контрагенту callback с решением по запросу, устанавливает ownership_confirmed и переводит перевод в COMPLETED.
• confirmed: false отправляет ответ об отказе и переводит перевод в COUNTERPARTY_VASP_GENERAL_DECLINE.
• Если callback endpoint контрагента недоступен, запрос возвращает 502, а перевод сохраняет текущий статус. При одобрении запись в адресной книге кошельков всё равно создаётся или помечается как подтверждённая.

{"confirmed": true, "wallet_address": "0xCounterpartyWallet01"}

• Сетевой перевод, на который уже ответили через его сеть (перевод VerifyVASP или перевод GTR либо Sygna Bridge, по которому уже принято решение), возвращает 409 (см. Переводы из сети).

​

Переводы из сети

• Маршрутизация. Сообщение попадает в ваше приложение, если в нём указан код участника вашего подключённого членства в этой сети. Сообщение, адресованное членству самого Didit, попадает к вам только в том случае, если вы являетесь единственным действующим клиентом Didit, подтвердившим контроль над кошельком получателя. Всё остальное отклоняется, поэтому ни один клиент никогда не получает перевод другого клиента.
• Решение. Didit создаёт входящий перевод в вашем приложении и принимает по нему решение так же, как по запросу TRP: сопоставление кошелька, владение, сверка имени и inbound_auto_accept.
• Однократность. Сети повторно отправляют сообщение, пока на него не ответят. Повтор получает тот же ответ, что и первая копия, и ничего не создаётся и не решается дважды.
• Ваша проверка по GTR и SYGNA. Решение по переводу, который ждёт вашего решения (UNCONFIRMED_OWNERSHIP, ON_HOLD или COUNTERPARTY_MISMATCHED_DATA), принимается с помощью POST .../travel-rule/ownership/: confirmed: true одобряет его (передайте wallet_address, если в переводе он не указан), а confirmed: false отклоняет. Didit отвечает сети после ответа endpoint, с теми же повторными попытками. Перевод, на который уже ответили, возвращает 409.
• Без отложенного ответа по VERIFYVASP. VerifyVASP получает ответ в момент запроса, поэтому перевод, которому потребовалась бы ваша проверка, сразу отклоняется и позже решить его нельзя (409).

​

Маскирование данных контрагента

{
  "data_masked": false,
  "data_unmasked": { "at": "2026-10-17T10:00:00Z", "reason": "wallet_proof", "actor": "" }
}

​

Обратная связь о расхождениях

{
  "status": "COUNTERPARTY_MISMATCHED_DATA",
  "mismatched_fields": ["date_of_birth"],
  "data_match": {
    "matched": false,
    "mismatched_fields": ["date_of_birth"],
    "fields": {
      "name": { "result": "matched", "strictness": "DEFAULT" },
      "date_of_birth": { "result": "mismatched", "strictness": "STRICT" },
      "address": { "result": "not_compared", "strictness": "NONE" },
      "account": { "result": "matched", "strictness": "STRICT" }
    }
  }
}

​

Оценка совпадения имён

{
  "name_match": {
    "score": 90,
    "matched": false,
    "method": "sequence_ratio",
    "strictness": "FUZZY",
    "compared_with": "wallet_holder",
    "transfer_name": "Ana Diaz",
    "compared_name": "Ana Diaz Garcia",
    "matched_names": ["Ana", "Diaz"],
    "mismatched_names": ["Garcia"]
  }
}

• score означает сходство полных имён от 0 до 100; если одно из имён пустое, значение равно 0. matched определяется результатом при уровне strictness, поэтому эти два значения могут расходиться: FUZZY решает на основании собственного коэффициента сходства 0.85.
• matched_names: слова имени перевода, найденные в другом имени. mismatched_names: слова, которые есть у одной стороны, но отсутствуют у другой.
• method принимает значения none, exact_token, token_subset, token_containment или sequence_ratio для NONE, STRICT, DEFAULT, CONTAINS и FUZZY соответственно.
• compared_with принимает значения wallet_holder (владелец, записанный для кошелька) или counterparty_vasp (имя, которое контрагент указал на странице ответа по email, или ответ Didit Test VASP).
• Исход перевода определяется data_match, который сравнивает все поля, поэтому перевод может иметь статус COUNTERPARTY_MISMATCHED_DATA, при этом name_match.matched равно true.
• name_match есть в объекте перевода, который возвращают эндпоинты Travel Rule, и во встроенном объекте travel_rule транзакции, и он равен null, пока имя не сравнивалось. Список переводов и webhook’и этот объект не содержат.
• Имена скрыты, пока стороны замаскированы, а также в копии обмена INTERNAL у другого клиента.

​

Сообщения и запросы документов

curl -X POST https://verification.didit.me/v3/transactions/{transaction_uuid}/travel-rule/messages/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"kind": "DOCUMENT_REQUEST", "body": "Please confirm the beneficiary date of birth.", "requested_documents": ["Proof of address"]}'

• kind принимает значения MESSAGE (по умолчанию) или DOCUMENT_REQUEST. Запрос документов требует хотя бы одну запись в requested_documents (до 10); сообщение требует body (до 5000 символов) или файл.
• reply_to указывает на более раннее сообщение того же перевода. Ответ другой стороны с документом выполняет запрос документов, на который он отвечает, и в нём устанавливается fulfilled_at. Ваш собственный ответ никогда не выполняет ваш запрос.
• Отправляйте multipart с files, чтобы прикрепить до 5 файлов размером до 10 МБ каждый в форматах PDF, PNG, JPEG или WebP. Didit проверяет содержимое каждого файла, а не только заявленный тип. При загрузке любого другого файла запрос возвращает 400 с ошибкой в поле files: «Attach PDF, PNG, JPEG or WebP files only.».
• Перевод вмещает до 100 сообщений, из них до 20 могут содержать вложения (до 5 файлов в каждом), с учётом обеих сторон. При превышении любого из этих лимитов запрос возвращает 400. Вложения в сообщениях не учитываются в документах самой транзакции.
• Сообщения работают по каналам INTERNAL и EMAIL. При INTERNAL другой клиент Didit видит сообщение на своей стороне пары. При EMAIL контрагенту отправляется email, и он отвечает на портале получения. Если уведомление по email не удалось отправить, сообщение всё равно сохраняется, а запрос возвращает 201.
• Запрос возвращает 409 с причиной в detail для перевода по TRP, GTR, TRUST, VerifyVASP или Sygna (эти протоколы не передают сообщения), для перевода без контрагента, для перевода INTERNAL, данные которого не совпали с владельцем кошелька (получатель ничего не получил), для перевода INTERNAL, где получатель ещё не доказал контроль над кошельком (с обеих сторон, пока он не докажет), для перевода EMAIL, у контрагента которого больше нет адреса email для комплаенса, и для перевода EMAIL, где ссылка на портал получения истекла или перевод закрыт.
• Webhook не срабатывает, когда контрагент отвечает. Читайте эндпоинт сообщений.
• Письмо контрагенту о новом сообщении отправляется на английском языке.

​

Адресная книга кошельков

curl -X POST https://verification.didit.me/v3/travel-rule/wallet-addresses/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "address": "0xede2d7e4f5b097e6391ab6bbcf2f47a53f4778cb",
    "chain": "ETH",
    "holder_name": "Ana Diaz",
    "holder_vendor_data": "user-042",
    "self_declared": true
  }'

​

Массовый импорт кошельков

curl -X POST https://verification.didit.me/v3/travel-rule/wallet-addresses/import/ \
  -H "x-api-key: YOUR_API_KEY" \
  -F "file=@wallets.csv;type=text/csv"

address,address_hash,chain,memo,holder_name,holder_vendor_data
0xBeneficiaryWallet01,,ethereum,,Ana Diaz,user-042
,4f7d2e1c9b8a7f6e5d4c3b2a1f0e9d8c7b6a5f4e3d2c1b0a9f8e7d6c5b4a3f2e,bitcoin,,,user-043
rExchangeSharedAddress01,,XRP,104729,Ana Diaz,user-042

​

Отправка по email контрагентам, которые недоступны

• На правильные адреса. Переданный вами counterparty_vasp_email – единственный получатель. Иначе Didit пишет на до трёх адресов: контакты контрагента, на которые ранее не приходили возвраты (сначала ваши, затем контакты платформы, затем те, что отвечали раньше), а затем email из записи реестра, если остался свободный слот. Каждый адрес получает своё письмо.
• От вашего имени. Письмо приходит с адреса Didit в виде «ваше юридическое название via Didit» на языке юрисдикции контрагента (английский, если она неизвестна). Ссылка открывает страницу ответа на этом языке. Копия вам не приходит: отслеживайте хронологию перевода.
• С напоминаниями. Пока контрагент не ответил, Didit напоминает ему за 72, 24 и 6 часов до срока, не раньше чем через 12 часов после запроса или последнего напоминания, и никогда не после срока.
• С обработкой возвратов. Возврат письма или жалоба на спам помечают контакт, до которого дошли, как недействительный, с указанием причины, и хронология перевода это фиксирует. Контакт платформы тогда недействителен для всех клиентов Didit, а собственный контакт вашего приложения – только для вашего приложения. Если Didit полностью прекращает отправку email на адрес (после постоянного возврата, жалобы на спам или отписки), каждый контакт по этому адресу помечается как недействительный (suppressed), и эти контакты снова становятся действительными, когда отправка на адрес возобновляется. Если не осталось адреса для отправки, перевод переходит в статус COUNTERPARTY_VASP_NOT_REACHABLE, а причина от почтового сервера получателя записывается в хронологию. Постоянный возврат или жалоба на спам на переданный вами counterparty_vasp_email приводят к этому сразу, поскольку это единственный получатель. Временный возврат (soft_bounce) на него или на собственный compliance email записи реестра оставляет запрос открытым для напоминаний.

curl https://verification.didit.me/v3/travel-rule/pickup/{token}/

{
  "reference": "33333333-4444-5555-6666-777777777777",
  "requested_at": "2026-07-05T10:00:00Z",
  "originator_vasp_name": "Origin CASP SL",
  "originator_vasp_lei": "529900EXAMPLEORIG001",
  "recipient_vasp_name": "Example Counterparty VASP",
  "language": "es",
  "amount": "0.250000000000000000",
  "currency": "ETH",
  "fiat_amount": "",
  "fiat_currency": "",
  "chain": "ETH",
  "beneficiary_wallet": "0xede2d7e4f5b097e6391ab6bbcf2f47a53f4778cb",
  "status": "AWAITING_COUNTERPARTY",
  "ivms_version": "ivms101.2023",
  "deadline_at": "2026-07-07T10:00:00Z",
  "reminders_sent": 0,
  "contact": "",
  "decline_reasons": ["data_mismatch", "not_our_customer", "wallet_not_hosted", "sanctions", "risk_appetite", "jurisdiction", "insufficient_data", "other"],
  "join_invitation": { "eligible": false, "url": "" },
  "originator_data": { "name": "Jane Doe", "wallet_address": "0x77ccff0cc624a53cd8b8d8703ced826710211ec7" },
  "beneficiary_data": { "name": "Ana Diaz", "wallet_address": "0xede2d7e4f5b097e6391ab6bbcf2f47a53f4778cb" },
  "ivms_request": {
    "originator": {
      "originatorPersons": [{ "naturalPerson": { "name": { "nameIdentifier": [{ "primaryIdentifier": "Doe", "secondaryIdentifier": "Jane", "nameIdentifierType": "LEGL" }] } } }],
      "accountNumber": ["0x77ccff0cc624a53cd8b8d8703ced826710211ec7"]
    },
    "beneficiary": {
      "beneficiaryPersons": [{ "naturalPerson": { "name": { "nameIdentifier": [{ "primaryIdentifier": "Diaz", "secondaryIdentifier": "Ana", "nameIdentifierType": "LEGL" }] } } }],
      "accountNumber": ["0xede2d7e4f5b097e6391ab6bbcf2f47a53f4778cb"]
    }
  },
  "data_masked": false
}

curl -X POST https://verification.didit.me/v3/travel-rule/pickup/{token}/respond/ \
  -H "Content-Type: application/json" \
  -d '{"decision": "accept", "beneficiary_name": "Ana Diaz"}'

​

Непривязанные депозиты

curl "https://verification.didit.me/v3/travel-rule/unmatched/" \
  -H "x-api-key: YOUR_API_KEY"

curl -X POST "https://verification.didit.me/v3/travel-rule/unmatched/{transaction_uuid}/match/" \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"transaction_id": "<uuid of the received message transaction>"}'

​

Регистрация депозита задним числом

curl -X POST https://verification.didit.me/v3/travel-rule/inbound/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "chain": "eth",
    "txid": "0xf103cfc37f6d390b61827987b9dc631b5e1d2bfeb008a780c1e38047ae5d557b",
    "wallet_address": "0xede2d7e4f5b097e6391ab6bbcf2f47a53f4778cb",
    "amount": "500.00",
    "currency": "USDC",
    "originator_data": { "name": "Carlos Ruiz", "wallet_address": "0x77ccff0cc624a53cd8b8d8703ced826710211ec7" },
    "beneficiary_data": { "name": "Ana Diaz" },
    "originating_vasp": {
      "name": "Northwind Digital Assets Ltd",
      "lei": "5493001KJTIIGC8Y1R12",
      "travel_address": "tareGfwAzkySLkFzcqr7AKno3K4VsT3jayMwPvj3ovbFZHzpayHLmgCrAMoLqjfCYRPpvLqr9dSr2VVTFAncwChcMjL4AheNuHCJM8NRcUg"
    }
  }'

• Совпадающей записи нет -> ON_HOLD. Разрешите ситуацию через POST .../travel-rule/ownership/: confirmed: true добавляет кошелёк в адресную книгу как верифицированный и запускает сверку имени. При совпадении перевод переходит в COMPLETED, а затем в FINISHED.
• Запись есть, но владение не подтверждено -> UNCONFIRMED_OWNERSHIP.
• Имя получателя не совпадает с полем holder_name записи -> COUNTERPARTY_MISMATCHED_DATA.
• Запись верифицирована и имя совпадает -> COMPLETED, затем сразу FINISHED (депозит уже зачислен).

{
  "transaction_id": "44444444-5555-6666-7777-888888888888",
  "txn_id": "tr-in-0xf103cfc37f6d390b61827987b9dc631b5e1d2bfeb008a780c1e38047ae5d557b-6151d81b366e",
  "created": true,
  "travel_rule": {
    "uuid": "55555555-6666-7777-8888-999999999999",
    "status": "FINISHED",
    "direction": "INBOUND",
    "rail": null,
    "protocol": null,
    "ivms_version": "ivms101.2023",
    "required": true,
    "ownership_confirmed": true,
    "deadline_at": null,
    "timeline": [
      { "status": "COMPLETED", "at": "2026-07-06T10:15:02.114208+00:00", "detail": "matched verified wallet address book entry" },
      { "status": "FINISHED", "at": "2026-07-06T10:15:02.131544+00:00", "detail": "on-chain deposit already settled" }
    ],
    "counterparty_vasp": null,
    "originator_data": { "name": "Carlos Ruiz", "wallet_address": "0x77ccff0cc624a53cd8b8d8703ced826710211ec7" },
    "beneficiary_data": { "name": "Ana Diaz", "wallet_address": "0xede2d7e4f5b097e6391ab6bbcf2f47a53f4778cb", "chain": "eth" },
    "created_at": "2026-07-06T10:15:02.087412Z"
  }
}

​

Виджет подтверждения владения кошельком

​

Каталог

curl "https://verification.didit.me/v3/travel-rule/vasps/?search=counterparty" \
  -H "x-api-key: YOUR_API_KEY"

{
  "count": 1,
  "next": null,
  "previous": null,
  "results": [
    {
      "id": "0d6f3c2a-6a1e-4c55-9a39-1f2b0c7d8e91",
      "kind": "directory",
      "name": "Example Counterparty VASP",
      "lei": "529900EXAMPLECPTY001",
      "jurisdiction": "DE",
      "domains": ["counterparty.example"],
      "reachable": true,
      "aliases": [{ "name": "Example Counterparty", "kind": "trading_name" }],
      "networks": [
        {
          "network": "GTR",
          "code": "EXAMPLE01",
          "listed_name": "Example Counterparty VASP",
          "country": "DE",
          "verified_at": "2026-10-12T09:30:00Z",
          "last_seen_at": "2026-10-12T09:30:00Z",
          "source": "staff"
        }
      ],
      "routes": [
        { "rail": "GTR", "status": "unavailable", "reason": "no_membership", "via": "" },
        { "rail": "EMAIL", "status": "available", "reason": "", "via": "contact" }
      ],
      "umbrella": null,
      "entities": [],
      "contacts": [
        {
          "id": "6c1f9b8e-2d4a-4f7e-8b3c-5a9d0e1f2a3b",
          "email": "travelrule@counterparty.example",
          "name": "Travel Rule desk",
          "source": "staff",
          "scope": "platform",
          "verified_at": null
        }
      ],
      "dd_status": "NOT_STARTED",
      "dd_score": 62,
      "dd_score_breakdown": {
        "jurisdiction": { "points": 25.0, "max": 25, "reason": "jurisdiction_not_high_risk", "detail": "DEU is not on the high-risk jurisdiction list" },
        "verification": { "points": 3.8, "max": 15, "reason": "dd_status_not_started", "detail": "due diligence status NOT_STARTED" },
        "protocol": { "points": 6.0, "max": 15, "reason": "email_only", "detail": "reachable over the email fallback only" },
        "lei": { "points": 10.0, "max": 10, "reason": "lei_valid", "detail": "valid LEI on record" },
        "history": { "points": 5.0, "max": 10, "reason": "no_history", "detail": "no exchange history" },
        "essentials": { "points": 7.5, "max": 15, "reason": "no_essential_checks", "detail": "no decided essential check yet" },
        "responsiveness": { "points": 5.0, "max": 10, "reason": "responsiveness_unknown", "detail": "0 decided recent requests, too few to judge" }
      },
      "dd_assessed_at": "2026-10-12T09:30:00Z",
      "dd_score_semantic": "higher_is_safer",
      "risk_level": "MEDIUM",
      "responsiveness": { "status": "UNKNOWN", "answered": 0, "total": 0, "computed_at": "2026-10-12T09:30:00Z" },
      "essential_checks": {},
      "reachable_rails": ["GTR", "EMAIL"],
      "is_didit_customer": false,
      "decision": {
        "decision": "APPROVED",
        "reason": "Licensed in DE",
        "decided_by": "",
        "updated_at": "2026-10-14T10:05:00Z",
        "inherited_from": null
      },
      "entity_screening": {
        "id": "7a1d2c3b-4e5f-4a6b-8c7d-9e0f1a2b3c4d",
        "status": "Approved",
        "total_hits": 0,
        "score": null,
        "screened_at": "2026-10-14T09:58:00Z",
        "fresh": true,
        "flagged": false
      },
      "questionnaires": []
    }
  ]
}

​

Маршруты

• TRP, если у записи есть TRP endpoint, проверенный каталогом.
• GTR, TRUST, VERIFYVASP, SYGNA, если сеть указывает VASP под кодом. Маршрут имеет статус available только тогда, когда ваше приложение может отправлять через эту сеть сегодня (via: own_membership для вашего собственного подключённого участия, via: didit_membership для участия Didit). В остальных случаях маршрут имеет статус unavailable с reason: no_membership или reason: network_switched_off и никогда не показывается как способ связаться с VASP. Собственные участия Didit в сетях пока не работают, поэтому сегодня сетевой маршрут доступен только через участие, которое вы подключили в Marketplace.
• EMAIL, если для записи есть контакт комплаенса.
• INTERNAL для участника сети Didit.

​

Бренды и их юрлица

​

Контакты

curl -X POST https://verification.didit.me/v3/travel-rule/counterparty-contacts/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"counterparty": "0d6f3c2a-6a1e-4c55-9a39-1f2b0c7d8e91", "email": "compliance@counterparty.example", "name": "Compliance desk"}'

• GET /v3/travel-rule/counterparty-contacts/ возвращает все контакты, на которые ваше приложение может отправлять письма, включая контакты платформы и контакты с ошибкой доставки, сначала новые. Разбивка на страницы выполняется через limit и offset. Фильтруйте через ?counterparty= и id записи каталога. Значение, которое не является UUID, возвращает 400.
• POST добавляет приватный контакт (counterparty, email, необязательный name) и возвращает 201. Добавление адреса, который у записи уже есть среди ваших контактов, возвращает этот контакт. Неизвестная запись возвращает 400 ("No directory entry with this id.").
• DELETE /v3/travel-rule/counterparty-contacts/{contact_uuid}/ удаляет один из ваших контактов (204). Контакты платформы удалить нельзя, для них возвращается 404.

​

Как записи попадают в каталог

• Промежуточный реестр ESMA провайдеров услуг, связанных с криптоактивами, в соответствии с MiCA, который читается раз в неделю: название каждого провайдера, LEI и государство-член происхождения.
• Публичный каталог TRISA, который читается раз в неделю: кто является каждым участником, его страна и его листинг в TRISA. Если листинг пропадает из каталога на три недели, он удаляется.
• Глобальный реестр LEI дополняет запись LEI, добавляя другие юридические названия и страну. Он находит LEI записи по точному юридическому названию в её стране.
• Атрибуция в блокчейн-аналитике добавляет или сопоставляет VASP, которому принадлежит адрес кошелька назначения, и сохраняет атрибутированное название как псевдоним.
• Сотрудники Didit курируют записи: идентификаторы маршрутизации и сетевые листинги, которые они проверили, контакты для комплаенса, псевдонимы, бренды и их юридические лица, объединённые дубликаты и скрытые записи.

​

Сеть Didit

• ваше приложение работает в продакшн-среде (не в песочнице), и Travel Rule включён;
• is_discoverable равно true, а legal_name заполнено;
• compliance_email заполнен и подтверждён: отправьте подтверждение запросом POST /v3/travel-rule/settings/compliance-email/confirmation/ и откройте ссылку из письма. При смене адреса нужно новое подтверждение;
• Didit не отметил приложение как тестовое, демонстрационное или внутреннее.

​

Идентификаторы маршрутизации

​

Проверка должной осмотрительности контрагента

• Общая оценка. Каждая запись справочника содержит оценку должной осмотрительности, уровень риска, статус отзывчивости и отчёт о базовых проверках. Didit вычисляет их на основе собственных данных платформы, поэтому все клиенты видят одни и те же значения.
• Ваши собственные записи. Ваше решение о VASP, ваш скрининг контрагента на санкции и негативные публикации в СМИ, а также анкеты должной осмотрительности, которыми вы обменялись с ним, принадлежат только вашему приложению. Другие клиенты их не видят, и они не меняют общую запись.

​

Оценка и уровень риска

​

Базовые проверки

​

Отзывчивость

{ "status": "UNRESPONSIVE", "answered": 0, "total": 6, "computed_at": "2026-10-12T09:30:00Z" }

• Учитываются: запросы, отправленные по сетевому каналу или каналу протокола, и запросы, отправленные по электронной почте на общий адрес, то есть на адрес комплаенса записи или на контакт платформы.
• Никогда не учитываются: запрос, отправленный на адрес электронной почты, который ввёл один клиент, или на личный контакт клиента. Такой обмен остаётся в истории переводов этого клиента и никогда не присваивает VASP метку для всех остальных.
• Ответ получен: COMPLETED, FINISHED, COUNTERPARTY_VASP_GENERAL_DECLINE или COUNTERPARTY_MISMATCHED_DATA. Отказ или несоответствие данных тоже считаются ответом: VASP вступил во взаимодействие.
• Ответа нет: EXPIRED.
• Ни то ни другое: любой другой статус. Запрос со статусом CANCELLED является действием самого отправителя, COUNTERPARTY_VASP_NOT_REACHABLE может быть сбоем на стороне отправителя, а запрос, который ещё выполняется, пока не имеет результата.

​

Ваше решение по контрагенту

curl -X PUT https://verification.didit.me/v3/travel-rule/vasps/0d6f3c2a-6a1e-4c55-9a39-1f2b0c7d8e91/decision/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"decision": "BLOCKED", "reason": "Unlicensed in its home jurisdiction"}'

{
  "decision": {
    "decision": "BLOCKED",
    "reason": "Unlicensed in its home jurisdiction",
    "decided_by": "",
    "updated_at": "2026-10-14T10:05:00Z",
    "inherited_from": null
  }
}

• Решение видно только в вашем приложении: другой клиент его не видит, и оно никогда не меняет общую запись.
• Само по себе решение ничего не меняет и никогда не влияет на маршрутизацию перевода. Оно попадает в ваши транзакции через поле правила counterparty_dd_status: установите пресеты или напишите собственное правило на его основе.
• Решение по бренду распространяется на каждую из его сущностей, у которой нет собственного решения, а в inherited_from сущность показывает бренд. Решение по сущности переопределяет решение по бренду для этой сущности.
• GET возвращает действующее решение или {"decision": null}. DELETE удаляет ваше собственное решение и возвращает то, что действует после этого: решение по бренду для сущности, а иначе null. Он отвечает 404, если у вашего приложения нет собственного решения по контрагенту.
• reason необязательно, до 255 символов, и каждый PUT заменяет его. decided_by указывает пользователя консоли, который принял или последним изменил решение; поле пустое, если решение принял API-ключ.

​

Скрининг контрагента

curl -X POST https://verification.didit.me/v3/travel-rule/vasps/0d6f3c2a-6a1e-4c55-9a39-1f2b0c7d8e91/screening/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"refresh": false}'

{
  "outcome": "screened",
  "screening": {
    "id": "7a1d2c3b-4e5f-4a6b-8c7d-9e0f1a2b3c4d",
    "status": "In Review",
    "total_hits": 2,
    "score": 85.0,
    "screened_at": "2026-10-14T09:58:00Z",
    "fresh": true,
    "flagged": true
  }
}

• Оплата. Каждый новый скрининг стоит цену Company AML Screening для вашей организации. GET /v3/travel-rule/vasps/{vasp_id}/screening/ возвращает эту price, fresh_days и то, включён ли скрининг (enabled), без оплаты. Скрининг моложе 30 дней считается актуальным: POST возвращает его снова с 200 и outcome: reused и ничего не списывает, если только вы не отправите refresh: true. Новый скрининг отвечает 201 с outcome: screened. Приложения в песочнице никогда не проверяются и не тарифицируются.
• Автоматический скрининг. Если скрининг включён, Didit также проверяет контрагента, которому направляется исходящий обмен, в момент начала обмена, до того как ваши правила оценят транзакцию, с тем же повторным использованием и оплатой. Отказ или сбой на этом этапе никогда не приводит к провалу перевода.
• Результат. status равен Approved, если возможные совпадения не требуют внимания, и In Review или Declined при возможном совпадении по санкциям или негативным публикациям в СМИ. flagged равен true, пока актуальный скрининг имеет статус In Review или Declined.
• Влияние. Пока ваш последний скрининг контрагента помечен и скрининг остаётся включённым, counterparty_risk_level в ваших правилах равен HIGH, поэтому пресет travel-rule-counterparty-high-risk, после установки, удерживает его переводы. Общий risk_level в справочнике не меняется.
• Конфиденциальность. Скрининг виден только в вашем приложении: другой клиент его не видит, и он никогда не меняет общую запись. Справочник показывает ваш последний скрининг как entity_screening.
• Отказы. 409, если скрининг выключен, для приложения в песочнице или пока уже выполняется скрининг того же контрагента. 403 с code: insufficient_credits, если баланса не хватает на цену. 502, если скрининг не удалось завершить. Ни один из этих ответов ничего не списывает.

​

Анкета комплексной проверки

curl -X POST https://verification.didit.me/v3/travel-rule/vasps/0d6f3c2a-6a1e-4c55-9a39-1f2b0c7d8e91/questionnaires/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"sent_to": "travelrule@counterparty.example"}'

{
  "id": "3f9e8d7c-6b5a-4c3d-9e2f-1a0b9c8d7e6f",
  "status": "SENT",
  "form_version": "1",
  "sent_to": "travelrule@counterparty.example",
  "sent_at": "2026-10-14T10:00:00Z",
  "expires_at": "2026-11-13T10:00:00Z",
  "answered_at": null,
  "valid_until": null,
  "current": false,
  "answers": {}
}

• Куда отправляется. sent_to должен быть адресом комплаенса, записанным в системе: для записи справочника это адрес комплаенса или контакт, который ваше приложение видит в contacts; для участника сети Didit это его подтверждённая почта комплаенса. Если не указывать поле, используется адрес, на который уходит письмо Travel Rule контрагенту: сначала ваш собственный контакт, затем контакт платформы, затем адрес комплаенса записи. Didit никогда не отправляет анкету никуда больше и отвечает 400, если у контрагента нет адреса комплаенса в системе.
• Ответ. Ссылка открывает /v3/travel-rule/questionnaires/{token}/, страницу для представителя контрагента, которому не нужны аккаунт или API-ключ. Представитель отвечает на каждый вопрос, до 2 000 символов на каждый (N/A, если вопрос неприменим), и отправляет анкету один раз. Контрагент также может отправить {"answers": {"<question id>": "<answer>"}} на ту же ссылку. Ссылка, которая уже использована, заменена или просрочена, вместо этого показывает страницу истечения срока. Письмо и страница переведены; сами вопросы всегда на английском, поэтому их смысл не меняется между языками.
• Сроки. Контрагенту дается 30 дней на ответ (expires_at). Ответы остаются актуальными 365 дней (valid_until), и до этого момента current равно true. Неотвеченная анкета после срока и ответы после окончания срока действия получают статус EXPIRED.
• Одна открытая анкета на контрагента. Новая отправка заменяет вашу более раннюю неотвеченную анкету тому же контрагенту: она получает статус EXPIRED, а её ссылка перестаёт работать. На один адрес в минуту можно отправить одно письмо; более частая отправка возвращает 429.
• Чтение ответов. GET /v3/travel-rule/vasps/{vasp_id}/questionnaires/ возвращает ваши анкеты для контрагента, сначала самые новые, с answers, где ключом служит id вопроса, после ответа. Справочник показывает их как questionnaires. Они видны только в вашем приложении.

​

Переводы с одним контрагентом

​

Политики переходного периода и контрагентов, не отвечающих на запросы

curl -X PUT https://verification.didit.me/v3/travel-rule/settings/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"sunrise_policy": "PROCEED", "non_responsive_policy": "HOLD"}'

1. sunrise_policy, если она задана и юрисдикция контрагента входит в sunrise_jurisdictions.
2. non_responsive_policy, если она задана и контрагент имеет статус UNRESPONSIVE.
3. timeout_outcome во всех остальных случаях, включая перевод участнику сети Didit или контрагенту без записи в справочнике.

​

Поля правил и пресеты

​

Webhooks

{
  "event_id": "9c0c8b8a-1111-4222-9333-666666666666",
  "webhook_type": "travel_rule.status.updated",
  "timestamp": 1774970000,
  "created_at": 1774970000,
  "application_id": "11111111-2222-3333-4444-555555555555",
  "environment": "live",
  "transaction_id": "22222222-3333-4444-5555-666666666666",
  "txn_id": "trv-2026-07-05-001",
  "travel_rule_status": "COMPLETED",
  "rail": "INTERNAL",
  "direction": "OUTBOUND"
}

​

Цены

• Он применяется к исходящей транзакции travelRule в приложении с включённым Travel Rule, сумма которой равна или превышает ваш threshold_amount, поэтому Didit запускает для неё управляемый обмен. Перевод на некастодиальный кошелёк или на собственный верифицированный кошелёк пользователя также подпадает под это правило: доказательство владения и есть его обмен.
• Каждая другая исходящая транзакция, которая содержит данные Travel Rule, тарифицируется как стандартный Transaction Screening. Ваш тариф включает его до месячного лимита транзакций, а сверх лимита он стоит $0.001: это перевод ниже вашего порога, платёж Lightning, к которому Travel Rule не применяется, и перевод, зафиксированный в пассивном режиме, когда Travel Rule выключен. Транзакция тарифицируется по одной из двух строк, никогда по обеим.
• Входящие транзакции travelRule не несут сбора за Travel Rule или мониторинг: это входящая часть перевода, которую Didit создаёт в приложении получателя на канале INTERNAL, входящие запросы TRP и регистрации после депозита.
• Приложение, которое подключилось к Travel Rule бесплатно, не платит ни один из сборов за исходящие транзакции travelRule, пока не включит биллинг исходящих через POST /v3/travel-rule/workspace/billing/. Приём остаётся бесплатным.
• Приложения в песочнице никогда не тарифицируются.
• Сбор за Travel Rule по прайсу составляет $0.02, а Transaction Screening стоит $0.001 сверх вашего лимита. Каждая транзакция оплачивается по цене той строки, по которой она тарифицируется.
• Если крипто-AML или скрининг кошельков также выполняется для той же транзакции (например, входящий депозит с currency_kind: "crypto" и включённым мониторингом), он тарифицируется отдельно по стандартной ставке Wallet Verification & Screening. В сбор за Travel Rule он не входит.
• Скрининг контрагента включается по выбору и тарифицируется отдельно, по цене Company AML Screening за каждую проверку. Проверка, выполненная менее 30 дней назад, используется повторно без оплаты. Решения, анкеты и оценка должной осмотрительности в каталоге ничего не стоят.

​

Цены на атрибуцию

• Крипто-мониторинг уже проверил кошелёк в этой транзакции - сохранённый результат используется повторно. Один вызов аналитики и одно списание Wallet Verification & Screening (то, которое уже выполнил крипто-мониторинг). Атрибуция ничего не добавляет.
• Крипто-мониторинг не запускался - Didit делает необходимый вызов аналитики один раз и передаёт его полный результат дальше. Транзакция оплачивается по стандартной ставке Wallet Verification & Screening ($0.15 при аналитике, управляемой Didit) и получает полный вывод крипто-скрининга: оценку риска, категорию риска кошелька, снимок сети, а не только название VASP. Строка использования помечается триггером travel_rule_attribution, чтобы списание можно было объяснить.
• Собственный ключ аналитики - здесь применяется та же платформенная комиссия, что и для крипто-мониторинга с вашим ключом ($0.02 за вызов). Ваш провайдер выставляет счёт за базовый запрос напрямую вам.
• Неуспешные запросы никогда не тарифицируются. Повторные отправки переиспользуют записанную атрибуцию без нового вызова и списания, а приложения в песочнице никогда не тарифицируются.

​

Пакет правил EU TFR

​

Почему это работает лучше на одной платформе

• Проверенные данные уже у вас. Субъект каждого перевода связан через vendor_data с KYC-профилем, который Didit верифицировал при онбординге (OCR документа, проверка живости, сравнение лиц). Поэтому вы можете формировать originator_data из проверенных полей на той же платформе. Для пользователя с одобренной KYC-верификацией Didit передаёт проверенную идентичность, а не значения, которые вы ввели вручную (см. Проверенные данные и их происхождение).
• Биометрическая проверка для рискованных переводов. Правило может удерживать любой перевод на крупную сумму до тех пор, пока пользователь не пройдёт повторную биометрическую проверку по лицу, снятому при онбординге. Это самый надёжный ответ на захват учётной записи в момент вывода средств. См. пример с разбором.
• Один граф устройств. Переводы, отправленные через SDK, содержат те же данные об устройстве, что и KYC-сессии, поэтому правило «новое устройство + крупная сумма + первый получатель» пишется одним правилом, а не соединением таблиц в хранилище данных.
• Скрининг, правила, кейсы и обмен в одном месте. Скрининг кошелька, который определяет VASP контрагента, это тот же скрининг, который видят ваши правила и аналитики: одно списание, одна консоль, один журнал аудита.
• Опубликованные цены. $0.02 за исходящий обмен, без тарифов, зависящих от объёма, и без звонка в отдел продаж.

​

FAQ

​

Как работает обмен

​

Цены и лицензирование

​

Операции и данные

​

Дальнейшие шаги