Didit обменивается данными Travel Rule и проверяет кошелек контрагента в рамках одного вызова транзакции /v3/. IVMS-101, $0.17 за управляемый перевод, 500 бесплатных проверок каждый месяц.
Robinhood Ventures
Нам доверяют более 2000 организаций по всему миру.
Что требует Travel Rule
Каждый регулируемый VASP обязан предоставить обе части при каждом переводе, пакет IVMS-101 для VASP-контрагента и проверку ончейн-рисков для себя. Didit предоставляет их в рамках одного вызова Transactions API: $0.17 за управляемый перевод, $0.04 с Bring Your Own Key для провайдера кошелька. 500 бесплатных проверок каждый месяц.
Выберите нужные проверки, ID, liveness, сравнение лиц, санкции, адрес, возраст, телефон, email, пользовательские вопросы. Перетащите их в рабочий процесс на дашборде или отправьте тот же процесс через наш API. Разветвляйте по условиям, проводите A/B-тесты, код не требуется.
Встраивайте нативно с помощью наших SDK для Web, iOS, Android, React Native или Flutter. Перенаправляйте на размещенную страницу. Или просто отправьте пользователю ссылку, по email, SMS, WhatsApp, куда угодно. Выберите то, что подходит вашему стеку.
Didit обеспечивает работу камеры, подсказки по освещению, передачу данных с мобильных устройств и доступность. Пока пользователь проходит процесс, мы оцениваем более 200 сигналов мошенничества в реальном времени и проверяем каждое поле по авторитетным источникам данных. Результат менее чем за две секунды.
Подписанные вебхуки в реальном времени синхронизируют вашу базу данных в момент одобрения, отклонения или отправки пользователя на проверку. Запрашивайте API по требованию. Или откройте консоль, чтобы просмотреть каждую сессию, каждый сигнал и управлять кейсами по-своему.
Didit · IVMS-101
Инициатор
Бенефициар
Didit · Правила по регионам
Didit · Совместимость с TR
Didit · Некастодиальный кошелек
Didit · API транзакций
Didit · Пакет доказательств
$ curl -X POST https://verification.didit.me/v3/session/ \
-H "x-api-key: $DIDIT_API_KEY" \
-d '{
"workflow_id": "wf_casp_onboard",
"vendor_data": "user-42"
}'{ статус Одобрено · На рассмотрении · Отклонено }$ curl -X POST https://verification.didit.me/v3/transactions/ \
-H "x-api-key: $DIDIT_API_KEY" \
-d '{
"transaction_id": "tx-9001",
"transaction_details": { "direction": "OUTBOUND", "currency_kind": "crypto" },
"subject": { "full_name": "Х. Перес" },
"counterparty": { "full_name": "Р. Бенефициар", "payment_method": { "account_id": "bc1qa3…hk22" }}
}'{ статус ОДОБРЕНО · НА_ПРОВЕРКЕ · ОТКЛОНЕНО · ОЖИДАЕТ_ПОЛЬЗОВАТЕЛЯ }You are integrating Didit into a Virtual Asset Service Provider (VASP) / Crypto-Asset Service Provider (CASP) to satisfy the Travel Rule on every crypto transfer. Two obligations:
1. Verify the user (KYC) — identity, liveness, face match, device + IP, AML. The originator data on every outbound transfer comes from this verified profile.
2. Submit each transfer with originator + beneficiary fields (IVMS-101) AND screen the counterparty wallet — one /v3/transactions/ call.
Bundle pricing (verified live 2026-05-16):
- User Verification (KYC) bundle: $0.33 per user (Sessions API)
- Transactions API call: $0.02 base + $0.15 managed wallet screen = $0.17 per managed transfer
- With Bring Your Own Key (BYOK) on the wallet provider: $0.04 per transfer ($0.02 + $0.02)
- First 500 verifications free every month, forever
PRE-REQUISITES
- Production API key from https://business.didit.me (sandbox key in 60 seconds, no credit card).
- Webhook endpoint with HMAC SHA-256 verification of the X-Signature-V2 header.
HMAC-SHA256 verification MUST run against the raw body bytes (the raw payload as Didit sent it) BEFORE any JSON parsing — re-serialising the parsed body changes whitespace and key order, which invalidates the signature. - A workflow_id from the no-code Workflow Builder with ID Verification + Passive Liveness + Face Match 1:1 + Device & IP Analysis + AML Screening.
- Transaction Monitoring + Wallet Screening enabled in the Business Console (Transactions > Settings).
STEP 1 — Verify the user with the Sessions API (one-time onboarding)
POST https://verification.didit.me/v3/session/
Headers:
x-api-key: <your api key>
Content-Type: application/json
Body:
{
"workflow_id": "<wf id with KYC + AML modules>",
"vendor_data": "<your user id>",
"callback": "https://<your-app>/casp/onboard/callback",
"metadata": {
"purpose": "casp_onboarding"
}
}
Response: 201 Created with the hosted session URL. Sub-2-second median verdict on completion.
STEP 2 — Read the signed webhook on KYC completion
Status enum (exact case): Approved | Declined | In Review | Resubmitted | Expired | Not Finished | Kyc Expired | Abandoned.
Verify the X-Signature-V2 header BEFORE reading the body.
Capture the user's full name, date of birth, address, and any registered identity-document number from the decision payload. These fields populate the IVMS-101 originator block on every subsequent transfer.
STEP 3 — Submit every transfer with IVMS-101 + wallet screen in one call
POST https://verification.didit.me/v3/transactions/
Headers:
x-api-key: <your api key>
Content-Type: application/json
Body (required fields verified live 2026-05-16):
{
"transaction_id": "<your internal transfer reference>",
"transaction_category": "finance",
"include_crypto_screening": true,
"transaction_details": {
"direction": "OUTBOUND",
"amount": "0.45",
"currency": "ETH",
"currency_kind": "crypto",
"action_type": "transfer"
},
"subject": {
"entity_type": "individual",
"vendor_data": "<your user id>",
"full_name": "<originator name from KYC>",
"address": "<originator address from KYC>",
"dob": "<originator dob from KYC, YYYY-MM-DD>"
},
"counterparty": {
"entity_type": "individual",
"full_name": "<beneficiary name>",
"address": "<beneficiary address if known>",
"payment_method": {
"method_type": "crypto_wallet",
"account_id": "<counterparty wallet address>"
}
}
}
REQUIRED fields the API rejects if missing:
- subject.vendor_data + subject.full_name
- counterparty.full_name
- transaction_details.direction + currency + currency_kind + amount
- counterparty.payment_method.account_id (the wallet address)
Didit packages the subject + counterparty fields into an IVMS-101 payload, hands them off to the connected Travel Rule protocol (TRP / Sumsub TR / Notabene / Veriscope), runs Wallet Screening on the counterparty address server-side, and returns one verdict.
Response shape (excerpted from a real successful 201):
{
"uuid": "<server transaction uuid>",
"txn_id": "<your transaction_id echoed back>",
"status": "APPROVED",
"score": 0,
"severity": null,
"travel_rule": { "status": "EXCHANGED", "protocol": "<network>", "ivms_packet_id": "<id>" },
"props": {
"wallet_risk_score": 0,
"sanctions_hit": false,
"aml_provider": "<provider slug>",
"aml_screening_type": "WALLET_SCREENING",
"aml_screening_status": "COMPLETED"
},
"cost_breakdown": {
"total_price": 0.17,
"items": [
{ "usage_type": "transaction_aml_monitoring", "price": 0.15 },
{ "usage_type": "transaction_monitoring", "price": 0.02 }
]
}
}
Transaction status enum (exact case, UPPER_SNAKE_CASE): APPROVED | IN_REVIEW | DECLINED | AWAITING_USER.
Wallet-screen severity (UPPER): LOW | MEDIUM | HIGH | CRITICAL | UNKNOWN.
Branch logic:
APPROVED → release the crypto.
IN_REVIEW → hold the transfer, route to analyst queue.
DECLINED → refuse the transfer, log the IVMS attempt for the audit.
AWAITING_USER → redirect the user to the remediation URL on the response.
STEP 4 — Inbound transfers: ingest the counterparty's IVMS packet
When you RECEIVE a transfer from another VASP:
- The connected Travel Rule protocol delivers the originator IVMS data to you BEFORE the on-chain transfer settles.
- Submit it via the same POST /v3/transactions/ with direction: "INBOUND" and the originator fields on subject and your own beneficiary on counterparty.
- Wallet Screening runs on the originator wallet (subject.payment_method.account_id).
- Verdict drives whether to credit the user.
STEP 5 — Self-hosted (unhosted) wallet transfers
For transfers TO a self-hosted wallet (no counterparty VASP to exchange with):
- Collect the beneficiary identity from the user via a custom questionnaire ($0.10).
- Above local enhanced-due-diligence thresholds, prompt the user to sign a short message with the beneficiary wallet's private key as proof of control.
- Submit the transaction with the captured beneficiary fields + wallet address.
- Didit still runs Wallet Screening on the destination and stores the IVMS-format record for the audit.
STEP 6 — Continuous AML on the user is automatic
Every approved user is re-screened daily against 1,300+ sanctions, PEP, and adverse-media lists. There is NO separate endpoint to call. When a previously-clean user crosses an AML threshold, the session status updates and a signed webhook fires.
WEBHOOK EVENT NAMES
- Sessions: status changes flow through the standard session webhook.
- Transactions: transaction.created · transaction.updated · transaction.status.changed · transaction.alert.generated.
Verify X-Signature-V2 on every payload.
CONSTRAINTS
- Session statuses Title Case With Spaces; transaction statuses UPPER_SNAKE_CASE. Don't mix.
- EU Transfer of Funds Regulation has NO de minimis threshold for crypto — every transfer carries originator + beneficiary data.
- US Travel Rule kicks in at $3,000; UK at £1,000; Singapore at SGD 1,500; Switzerland at CHF 1,000. Apply per-workflow.
- Default record retention is 5 years post-transfer per most AML regimes; extensible per supervisor guidance.
- Wallet Screening MUST run BEFORE the crypto leaves — a post-transfer screen is useful for audit but useless for blocking.
Read the docs:
- https://docs.didit.me/transaction-monitoring/overview
- https://docs.didit.me/transaction-monitoring/transactions
- https://docs.didit.me/transaction-monitoring/aml-screening
- https://docs.didit.me/sessions-api/create-session
- https://docs.didit.me/integration/webhooks
Start free at https://business.didit.me — sandbox key in 60 seconds, 500 verifications free every month, no credit card.$0 / месяц. Кредитная карта не требуется.
Платите только за то, что используете. Более 25 модулей. Публичные цены за модуль, без минимальной ежемесячной платы.
Индивидуальные MSA и SLA. Для больших объемов и регулируемых программ.
Начните бесплатно → платите только за выполненные проверки → переходите на Enterprise для индивидуального контракта, SLA или размещения данных.
Didit, это инфраструктура для идентификации и борьбы с мошенничеством. Это платформа, которую мы сами хотели бы иметь, когда создавали продукты: открытая, гибкая и удобная для разработчиков, поэтому она становится полноценной частью вашего стека, а не "черным ящиком", который приходится обходить.
Единый API охватывает проверку людей (KYC, know your customer), проверку компаний (KYB, know your business), проверку криптокошельков (KYT, know your transaction) и мониторинг транзакций в реальном времени, на стеке, созданном для:
В основе: более 14 000 типов документов на 48+ языках, более 1000 источников данных и более 200 сигналов мошенничества для каждой сессии. Инфраструктура Didit динамически обучается на каждой сессии и становится лучше с каждым днем.
Согласно Travel Rule, при перемещении ценностей между двумя регулируемыми провайдерами определённые данные о клиенте, имя, номер счёта, адрес, должны передаваться вместе с самой ценностью.
Изначально это правило появилось в традиционных финансах (Закон США о банковской тайне 1970 года), в 2019 году оно было распространено на весь мир Целевой группой по финансовым мероприятиям (FATF) и теперь применяется к криптовалютам повсеместно. Стандартный формат данных, InterVASP Messaging Standard 101 (IVMS-101), JSON-схема, которую поддерживают все основные протоколы Travel Rule.
Цель регулятора проста: не дать злоумышленникам анонимно отмывать доходы через цепочки провайдеров, обеспечивая отслеживание данных о личности на каждом этапе.
Каждый регулируемый поставщик услуг виртуальных активов (VASP) или поставщик услуг криптоактивов (CASP), биржи, платформы ввода/вывода фиата, кастодиальные кошельки, брокеры, внебиржевые площадки, платёжные учреждения, работающие с крипторасчётами.
Действующие юрисдикции:
FATF проводит взаимные оценки реализации в каждой стране. Юрисдикции, не соблюдающие правила, рискуют попасть в серый список.
Полный процесс обычно занимает менее 30 секунд от начала до конца, взять документ, сфотографировать его, сделать селфи, готово. Это самый быстрый показатель на рынке. Устаревшие KYC-провайдеры обычно тратят более 90 секунд на тот же процесс.
На бэкенде Didit возвращает результат менее чем за две секунды (p99), от момента завершения селфи пользователем до срабатывания вашего вебхука. Мобильный захват оптимизирован для медленных телефонов и сетей: прогрессивное сжатие изображений, отложенная загрузка SDK и передача в одно касание с десктопа на телефон через QR-код, если пользователь начал работу в вебе.
Минимальный набор данных FATF:
Данные передаются через протокол Travel Rule между двумя провайдерами, не в блокчейне, не в примечании к транзакции. Сегодня рынок фрагментирован: провайдеры выбирают один или несколько протоколов из TRP, Sumsub Travel Rule, Notabene, Veriscope, OpenVASP и Shyft. Общий язык, IVMS-101, который читает и записывает каждый протокол.
Получатель перевода проверяет данные перед зачислением на счёт бенефициара.
Каждая сессия получает один из семи чётких статусов, поэтому ваш код всегда знает, что делать:
Approved, все проверки пройдены. Пользователь может продолжить.Declined, одна или несколько проверок не пройдены. Вы можете разрешить пользователю повторно отправить конкретный неудачный шаг (например, переделать селфи), не перезапуская весь процесс.In Review, помечено для проверки комплаенс-отделом. Откройте кейс в консоли, просмотрите все сигналы, примите решение об одобрении или отклонении.In Progress, пользователь находится в процессе.Not Started, ссылка отправлена, пользователь ещё не открыл её. Отправьте напоминание, если она долго остаётся без внимания.Abandoned, пользователь открыл ссылку, но не завершил процесс вовремя. Повторно вовлеките или аннулируйте.Expired, срок действия ссылки на сессию истёк. Создайте новую сессию.Подписанный вебхук срабатывает при каждом изменении статуса, поэтому ваша база данных всегда синхронизирована. Заброшенные и отклонённые сессии бесплатны.
Производственные данные по умолчанию обрабатываются и хранятся в Европейском Союзе на Amazon Web Services. Корпоративные контракты могут предусматривать альтернативные регионы для юрисдикций, регуляторы которых этого требуют.
Шифрование повсюду. AES-256 в состоянии покоя для каждой базы данных, объектного хранилища и резервной копии. Transport Layer Security 1.3 при передаче для каждого вызова API, вебхука и сессии Business Console. Биометрические данные шифруются отдельным Customer Master Key.
Срок хранения контролируете вы. По умолчанию срок хранения неограничен (бессрочно), если вы не настроите более короткий, от 30 дней до 10 лет для каждого приложения, и вы можете удалить любую отдельную сессию в любое время из дашборда или API.
Сертификаты: SOC 2 Type 1 (аудит Type 2 в процессе), ISO/IEC 27001:2022, iBeta Level 1 PAD и публичное подтверждение от Tesoro / SEPBLAC / CNMV Испании о том, что удалённая верификация личности Didit безопаснее, чем личная верификация. Полный отчёт по ссылке /security-compliance.
Didit по умолчанию соответствует требованиям регуляторов, важных для инфраструктуры идентификации:
Подробная записка, каждый сертификат, каждое письмо регулятора: /security-compliance.
Три пути интеграции, выберите тот, который подходит вашему стеку:
Одна и та же панель управления, одно и то же выставление счетов, одна и та же цена за успешную верификацию для всех трёх. Пошаговое руководство на docs.didit.me/integration/integration-prompt.
В реальной жизни редко встречаются идеальные пакеты Travel Rule, контрагенты отправляют неполные данные, поля не совпадают с именем KYC, форматы адресов различаются. Два пути:
DECLINED, и пользователю предлагается повторно отправить данныеIN_REVIEW, и в Business Console открывается кейс с выделенными различиямиAWAITING_USER, и Didit автоматически создаёт сессию исправления, возвращая URL для верификации в ответеВаша команда комплаенса рассматривает кейс, запрашивает дополнительные данные при необходимости и одобряет или отклоняет его из Консоли. Заметки рецензента, решение и временные метки записываются для аудиторского пакета.
Данные Travel Rule собираются для каждого перевода, а не для отношений, «обновления» пакета Travel Rule не существует. Но пользователи, стоящие за переводами, должны постоянно отслеживаться в соответствии с пакетом AML ЕС и аналогичными режимами.
Didit выполняет:
Все три функции поступают в единый интерфейс управления кейсами, поэтому один рецензент видит полную картину по каждому пользователю.
Большинство регуляторов требуют хранить не менее 5 лет записи о каждом переводе по Travel Rule и базовой идентификации пользователя, иногда дольше, если это запросит ваш надзорный орган.
Модель хранения Didit:
Didit, единственная KYC-платформа с официальным подтверждением от правительства страны-члена ЕС, Казначейство Испании, Banco de España и SEPBLAC совместно подтвердили, что услуга безопаснее, чем личная верификация. Отчёт напрямую включается в ваш пакет авторизации CASP.
Единый API для KYC, KYB, мониторинга транзакций и проверки кошельков. Интеграция за 5 минут.