A Didit troca dados da Regra de Viagem e verifica a carteira da contraparte na mesma chamada de transação /v3/. Payloads IVMS-101, $0.17 por transferência gerida, 500 verificações gratuitas todos os meses.
Robinhood Ventures
Confiado por mais de 2.000 organizações em todo o mundo.
O que a Regra de Viagem exige
Cada VASP regulada deve ambas as 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 envia-os como uma única chamada da API de Transações: $0.17 gerida, $0.04 com Bring Your Own Key no fornecedor da carteira. 500 verificações gratuitas todos os meses.
Escolha as verificações que pretende, ID, prova de vida, correspondência facial, sanções, morada, idade, telefone, e-mail, perguntas personalizadas. Arraste-as para um fluxo no dashboard, 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.
Integre nativamente com o nosso SDK Web, iOS, Android, React Native ou Flutter. Redirecione para uma página alojada. Ou simplesmente envie um link ao seu utilizador, por e-mail, SMS, WhatsApp, em qualquer lugar. Escolha o que melhor se adapta à sua stack.
A Didit gere a câmara, as indicações de iluminação, a transição móvel e a acessibilidade. Enquanto o utilizador está no fluxo, pontuamos mais de 200 sinais de fraude em tempo real e verificamos cada campo contra fontes de dados autorizadas. Resultado em menos de dois segundos.
Webhooks assinados em tempo real mantêm a sua base de dados sincronizada no momento em que um utilizador é aprovado, recusado ou enviado para revisão. Consulte a API sob demanda. Ou abra a consola para inspecionar cada sessão, cada sinal e gerir os casos à sua maneira.
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"
}'{ estado Aprovado · Em Revisão · Recusado }$ curl -X POST https://verification.didit.me/v3/transactions/ \
-H "x-api-key: $DIDIT_API_KEY" \
-d '{
"transaction_id": "tx-9001",
"transaction_details": { "direção": "SAÍDA", "tipo_de_moeda": "cripto" },
"assunto": { "nome_completo": "J. Pérez" },
"contraparte": { "nome_completo": "R. Beneficiário", "método_de_pagamento": { "id_da_conta": "bc1qa3…hk22" }}
}'{ estado APROVADO · EM_REVISÃO · RECUSADO · AGUARDANDO_UTILIZADOR }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 é necessário cartão de crédito.
Pague apenas pelo que usa. 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 regulados.
Comece grátis → pague apenas quando uma verificação for executada → desbloqueie o Enterprise para um contrato personalizado, SLA ou residência de dados.
A Didit é uma infraestrutura para identidade e fraude, a plataforma que gostaríamos que existisse quando estávamos a construir os nossos próprios produtos: aberta, flexível e amigável para programadores, para que funcione como uma parte real da sua stack, em vez de uma caixa preta que integra à volta.
Uma API abrange a verificação de pessoas (KYC, know your customer), a verificação de empresas (KYB, know your business), a triagem de carteiras de criptomoedas (KYT, know your transaction) e a monitorização de transações em tempo real, numa stack construída para ser:
A base subjacente: 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 da Didit aprende dinamicamente com cada sessão e melhora a cada dia.
A Travel Rule determina que, quando o valor se move entre dois prestadores de serviços regulados, certas informações do cliente, nome, número de conta, morada, devem acompanhar o próprio valor.
Começou nas finanças tradicionais (com o US Bank Secrecy Act de 1970), foi globalmente alargada pela Financial Action Task Force (FATF) em 2019 e agora aplica-se a cripto em todo o lado. O formato padrão do payload é 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 prestadores, garantindo que os dados de identidade acompanham o valor em cada etapa.
Todos os Prestadores de Serviços de Ativos Virtuais (VASP) ou Prestadores de Serviços de Criptoativos (CASP) regulados, exchanges, plataformas de on/off-ramp, carteiras de custódia, brokers, mesas OTC, instituições de pagamento que lidam com liquidação de cripto.
Jurisdições ativas:
A FATF realiza avaliações mútuas da implementação de cada país. Jurisdições não conformes arriscam a designação de lista cinzenta.
O processo completo geralmente demora menos de 30 segundos de ponta a ponta, pegar no documento de identificação, tirar a foto do documento, tirar a selfie, e está feito. É o mais rápido do mercado. Os prestadores de KYC legados geralmente demoram mais de 90 segundos para o mesmo processo.
No back-end, a Didit devolve o resultado em menos de dois segundos no p99, medido desde o momento em que o utilizador termina a selfie até ao momento em que o seu webhook é acionado. A captura móvel é otimizada para telemóveis e redes lentas: compressão progressiva de imagem, carregamento lazy do software development kit, e uma transição com um toque do desktop para o telemóvel via código QR, caso o utilizador comece na web.
O conjunto mínimo de dados da FATF é:
Os dados movem-se através de um protocolo Travel Rule entre os dois prestadores, não on-chain, nem no memo da transação. O mercado atual está fragmentado: os prestadores escolhem um ou mais entre TRP, Sumsub Travel Rule, Notabene, Veriscope, OpenVASP e Shyft. A linguagem partilhada é o IVMS-101, que todos os protocolos leem e escrevem.
O recetor da transferência verifica os dados antes de creditar a conta do beneficiário.
Cada sessão atinge um de sete estados claros, para que o seu código saiba sempre o que fazer:
Approved, todas as verificações passaram. Avance com o utilizador.Declined, uma ou mais verificações falharam. Pode permitir que o utilizador reenvie o passo específico que falhou (por exemplo, tirar a selfie novamente) sem ter de refazer todo o processo.In Review, sinalizado para revisão de conformidade. Abra o caso na consola, veja todos os sinais, decida aprovar ou recusar.In Progress, o utilizador está a meio do processo.Not Started, link enviado, o utilizador ainda não o abriu. Envie um lembrete se demorar muito.Abandoned, o utilizador abriu o link, mas não terminou a tempo. Reative ou expire.Expired, o link da sessão expirou. Crie uma nova sessão.*Um webhook assinado é acionado em cada mudança de estado*, para que a sua base de dados esteja sempre sincronizada. As sessões abandonadas e recusadas são gratuitas.
Os dados de produção são processados e armazenados na União Europeia por defeito, nos serviços da Amazon Web Services. Contratos empresariais podem solicitar regiões alternativas para jurisdições cujos reguladores o exijam.
Criptografia em todo o lado. AES-256 em repouso em todas as bases de dados, armazenamento de objetos e backups. Transport Layer Security 1.3 em trânsito em cada chamada de API, webhook e sessão da Consola de Negócios. Os dados biométricos são encriptados sob uma Customer Master Key separada.
A retenção é sua para controlar. A retenção padrão é indefinida (ilimitada), a menos que configure um período mais curto, entre 30 dias e 10 anos por aplicação, e pode eliminar qualquer sessão individual a qualquer momento a partir do dashboard ou da API.
Certificações: SOC 2 Tipo 1 (auditoria Tipo 2 em curso), ISO/IEC 27001:2022, iBeta Nível 1 PAD, e uma atestação pública do Tesoro / SEPBLAC / CNMV de Espanha de que a verificação remota de identidade da Didit é mais segura do que verificar alguém presencialmente. Relatório completo em /security-compliance.
A Didit é, por defeito, compatível com os reguladores relevantes 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 dashboard, mesma faturação, mesmo preço por sucesso para os três. Guia passo a passo em docs.didit.me/integration/integration-prompt.
Na vida real, raramente se produzem pacotes Travel Rule perfeitos, as contrapartes enviam dados parciais, os campos não correspondem ao nome do KYC, os formatos de endereço diferem. Dois caminhos:
DECLINED e o utilizador é solicitado a reenviarIN_REVIEW e um caso é aberto na Consola de Negócios com a diferença destacadaAWAITING_USER e a Didit cria automaticamente uma sessão de remediação, devolvendo um URL de verificação na respostaA sua equipa de conformidade avalia o caso, solicita mais dados se necessário e aprova ou rejeita a partir da Consola. Notas do revisor, decisão e carimbos de data/hora são registados para o pacote de auditoria.
Os dados da Travel Rule são recolhidos por transferência, não por relação, não há uma "atualização" de um pacote Travel Rule. Mas os utilizadores por trás das transferências devem ser monitorizados continuamente sob o pacote AML da UE e regimes equivalentes.
A Didit executa:
Todos os três alimentam a mesma interface de Gestão de Casos, para que um único revisor veja o panorama completo por utilizador.
A maioria dos reguladores exige pelo menos 5 anos de registos sobre cada transferência da Travel Rule e a identidade do utilizador subjacente, por vezes mais tempo se o seu supervisor o solicitar.
Modelo de retenção da Didit:
A Didit é a única plataforma KYC com uma atestação formal de um governo de um estado-membro da UE, o Tesouro, o Banco de Espanha e o SEPBLAC de Espanha atestaram conjuntamente o serviço como mais seguro do que a verificação presencial. O relatório é diretamente incluído no seu pacote de autorização CASP.
Uma API para KYC, KYB, Monitorização de Transações e Rastreio de Carteiras. Integre em 5 minutos.