A Didit troca dados do Travel Rule e verifica a carteira da contraparte na mesma chamada de transação /v3/. Payloads IVMS-101, $0.17 por transferência gerenciada, 500 verificações gratuitas por mês.
Robinhood Ventures
Confiado por mais de 2.000 organizações em todo o mundo.
O que o Travel Rule exige
Toda VASP regulamentada deve as duas partes em cada transferência, o pacote IVMS-101 para a VASP da contraparte, a verificação de risco on-chain para si mesma. A Didit as envia como uma única chamada de API de Transações: $0.17 gerenciada, $0.04 com Bring Your Own Key no provedor de carteira. 500 verificações gratuitas por mês.
Escolha as verificações que você quer, ID, prova de vida, reconhecimento facial, sanções, endereço, idade, telefone, e-mail, perguntas personalizadas. Arraste-as para um fluxo no painel, ou publique o mesmo fluxo na nossa API. Crie ramificações com base em condições, execute testes A/B, sem necessidade de código.
Incorpore nativamente com nossos SDKs Web, iOS, Android, React Native ou Flutter. Redirecione para uma página hospedada. Ou simplesmente envie um link ao seu usuário, por e-mail, SMS, WhatsApp, onde quiser. Escolha o que melhor se adapta à sua stack.
A Didit hospeda a câmera, as dicas de iluminação, a transição para dispositivos móveis e a acessibilidade. Enquanto o usuário está no fluxo, pontuamos mais de 200 sinais de fraude em tempo real e verificamos cada campo contra fontes de dados oficiais. Resultado em menos de dois segundos.
Webhooks assinados em tempo real mantêm seu banco de dados sincronizado no momento em que um usuário é aprovado, recusado ou enviado para revisão. Consulte a API sob demanda. Ou abra o console para inspecionar cada sessão, cada sinal e gerenciar casos do seu jeito.
Didit · IVMS-101
Originador
Beneficiário
Didit · Regras por região
Didit · Interoperabilidade TR
Didit · Carteira não custodial
Didit · API de Transações
Didit · Pacote de evidências
$ 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"
}'{ status Aprovado · Em Análise · Recusado }$ curl -X POST https://verification.didit.me/v3/transactions/ \
-H "x-api-key: $DIDIT_API_KEY" \
-d '{
"transaction_id": "tx-9001",
"transaction_details": { "direction": "SAÍDA", "tipo_moeda": "cripto" },
"assunto": { "nome_completo": "J. Pérez" },
"contraparte": { "nome_completo": "R. Beneficiário", "metodo_pagamento": { "id_conta": "bc1qa3…hk22" }}
}'{ status APROVADO · EM_ANÁLISE · RECUSADO · AGUARDANDO_USUÁRIO }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 / mês. Não precisa de cartão de crédito.
Pague apenas pelo que usar. Mais de 25 módulos. Preços públicos por módulo, sem taxa mínima mensal.
MSA e SLA personalizados. Para grandes volumes e programas regulamentados.
Comece grátis → pague apenas quando uma verificação for executada → desbloqueie o Enterprise para um contrato personalizado, SLA ou residência de dados.
Didit é a infraestrutura para identidade e fraude, a plataforma que gostaríamos que existisse quando estávamos construindo nossos próprios produtos: aberta, flexível e amigável para desenvolvedores, para que funcione como uma parte real da sua stack, em vez de uma caixa preta que você integra por fora.
Uma única API cobre a verificação de pessoas (KYC, know your customer), verificação de empresas (KYB, know your business), triagem de carteiras de cripto (KYT, know your transaction) e monitoramento de transações em tempo real, em uma stack construída para ser:
A base por trás: mais de 14.000 tipos de documentos em mais de 48 idiomas, mais de 1.000 fontes de dados e mais de 200 sinais de fraude em cada sessão. A infraestrutura Didit aprende dinamicamente com cada sessão e melhora a cada dia.
A Travel Rule determina que, quando há movimentação de valor entre dois provedores regulados, certas informações do cliente, nome, número da conta, endereço, devem acompanhar o valor.
Ela começou no sistema financeiro tradicional (com o US Bank Secrecy Act de 1970), foi expandida globalmente pela Força-Tarefa de Ação Financeira (FATF) em 2019 e agora se aplica a criptoativos em todo o mundo. O formato padrão de dados é o InterVASP Messaging Standard 101 (IVMS-101), um esquema JSON que todos os principais protocolos da Travel Rule utilizam.
O objetivo do regulador é simples: impedir que criminosos lavem dinheiro anonimamente através de cadeias de provedores, garantindo que os dados de identidade sigam o valor em cada etapa.
Todo Provedor de Serviços de Ativos Virtuais (VASP) ou Provedor de Serviços de Criptoativos (CASP) regulado, exchanges, plataformas de on/off-ramp, carteiras de custódia, corretoras, mesas de OTC, instituições de pagamento que lidam com liquidação de criptoativos.
Jurisdições ativas:
A FATF realiza avaliações mútuas da implementação de cada país. Jurisdições não conformes correm o risco de serem designadas para a lista cinza.
O fluxo completo geralmente leva menos de 30 segundos do início ao fim, pegar o documento, tirar a foto, tirar a selfie, pronto. Essa é a velocidade mais rápida do mercado. Provedores de KYC legados geralmente levam mais de 90 segundos para o mesmo fluxo.
No back-end, o Didit retorna o resultado em menos de dois segundos no p99, medido do momento em que o usuário termina a selfie até o momento em que seu webhook é acionado. A captura móvel é otimizada para celulares e redes lentas: compressão progressiva de imagem, carregamento preguiçoso do SDK e uma transição com um toque do desktop para o celular via QR code, caso o usuário comece na web.
O conjunto mínimo de dados da FATF é:
Os dados se movem através de um protocolo da Travel Rule entre os dois provedores, não on-chain, não no memo da transação. O mercado atual é fragmentado: os provedores escolhem um ou mais entre TRP, Sumsub Travel Rule, Notabene, Veriscope, OpenVASP e Shyft. A linguagem comum é o IVMS-101, que todo protocolo lê e escreve.
O recebedor da transferência verifica os dados antes de creditar a conta do beneficiário.
Cada sessão chega a um de sete status claros, para que seu código sempre saiba o que fazer:
Approved, todas as verificações aprovadas. Avance o usuário.Declined, uma ou mais verificações falharam. Você pode permitir que o usuário reenvie a etapa específica que falhou (por exemplo, refazer a selfie) sem refazer todo o fluxo.In Review, sinalizado para revisão de conformidade. Abra o caso no console, veja todos os sinais, decida aprovar ou recusar.In Progress, usuário está no meio do fluxo.Not Started, link enviado, usuário ainda não abriu. Envie um lembrete se demorar muito.Abandoned, usuário abriu o link, mas não terminou a tempo. Reengaje ou expire.Expired, o link da sessão expirou. Crie uma nova sessão.Um webhook assinado é acionado a cada mudança de status, para que seu banco de dados esteja sempre sincronizado. Sessões abandonadas e recusadas são gratuitas.
Os dados de produção são processados e armazenados na União Europeia por padrão, na Amazon Web Services. Contratos empresariais podem solicitar regiões alternativas para jurisdições cujos reguladores o exijam.
Criptografia em todos os lugares. AES-256 em repouso em todos os bancos de dados, armazenamento de objetos e backups. Transport Layer Security 1.3 em trânsito em cada chamada de API, webhook e sessão do Business Console. Dados biométricos são criptografados sob uma Customer Master Key separada.
A retenção é sua para controlar. A retenção padrão é indefinida (ilimitada), a menos que você configure um período menor, entre 30 dias e 10 anos por aplicação, e você pode excluir qualquer sessão individual a qualquer momento pelo painel ou pela API.
Certificações: SOC 2 Tipo 1 (auditoria Tipo 2 em andamento), ISO/IEC 27001:2022, iBeta Level 1 PAD, e uma declaração pública do Tesoro / SEPBLAC / CNMV da Espanha de que a verificação remota de identidade da Didit é mais segura do que verificar alguém pessoalmente. Relatório completo em /security-compliance.
A Didit já vem em conformidade por padrão para os reguladores importantes para a infraestrutura de identidade:
Memorando detalhado, todos os certificados, todas as cartas regulatórias: /security-compliance.
Três caminhos de integração, escolha o que melhor se adapta à sua stack:
Mesmo painel, mesma cobrança, mesmo preço por sucesso para todos os três. Guia passo a passo em docs.didit.me/integration/integration-prompt.
Na vida real, raramente os pacotes da Travel Rule são perfeitos, contrapartes enviam dados parciais, campos não correspondem ao nome do KYC, formatos de endereço são diferentes. Dois caminhos:
DECLINED e o usuário é solicitado a reenviarIN_REVIEW e um caso é aberto no Business Console com a diferença destacadaAWAITING_USER e a Didit cria uma sessão de remediação automaticamente, retornando uma URL de verificação na respostaSua equipe de conformidade tria o caso, solicita mais dados se necessário e aprova ou rejeita de dentro do Console. Notas do revisor, decisão e carimbos de data/hora são registrados para o pacote de auditoria.
Os dados da Travel Rule são coletados por transferência, não por relacionamento, não há uma "atualização" de um pacote da Travel Rule. Mas os usuários por trás das transferências devem ser monitorados continuamente sob o pacote AML da UE e regimes equivalentes.
A Didit executa:
Todos os três alimentam a mesma interface de Gerenciamento de Casos, para que um único revisor veja o panorama completo por usuário.
A maioria dos reguladores exige pelo menos 5 anos de registros sobre cada transferência da Travel Rule e a identidade do usuário subjacente, às vezes mais, se seu supervisor solicitar.
Modelo de retenção da Didit:
A Didit é a única plataforma KYC com uma declaração formal de um governo membro da UE, o Tesouro da Espanha, o Banco de España e o SEPBLAC atestaram conjuntamente o serviço como mais seguro do que a verificação presencial. O relatório é arquivado diretamente em seu pacote de autorização CASP.
Uma API para KYC, KYB, Monitoramento de Transações e Análise de Carteiras. Integre em 5 minutos.