Didit tauscht Travel Rule-Daten aus und screent die Wallet der Gegenpartei mit demselben /v3/ Transaktionsaufruf. IVMS-101 Payloads, $0.17 pro verwalteter Überweisung, 500 Verifizierungen pro Monat kostenlos.
Robinhood Ventures
Über 2.000 Organisationen weltweit vertrauen uns.
Was die Travel Rule verlangt
Jeder regulierte VASP muss bei jeder Überweisung beide Hälften liefern, das IVMS-101-Paket für den Gegenpartei-VASP und den On-Chain-Risikoscreen für sich selbst. Didit liefert beides in einem einzigen Transactions API-Aufruf: $0.17 verwaltet, $0.04 mit Bring Your Own Key beim Wallet-Anbieter. 500 Verifizierungen pro Monat kostenlos.
Wähle die gewünschten Prüfungen aus, ID, Liveness, Face Match, Sanktionen, Adresse, Alter, Telefon, E-Mail, benutzerdefinierte Fragen. Ziehe sie im Dashboard in einen Flow oder poste denselben Flow an unsere API. Verzweige nach Bedingungen, führe A/B-Tests durch, kein Code erforderlich.
Bette nativ mit unserem Web-, iOS-, Android-, React Native- oder Flutter-SDK ein. Leite auf eine gehostete Seite weiter. Oder sende deinem Nutzer einfach einen Link, per E-Mail, SMS, WhatsApp, überall. Wähle, was zu deinem Stack passt.
Didit hostet die Kamera, die Beleuchtungshinweise, die mobile Übergabe und die Barrierefreiheit. Während der Nutzer im Flow ist, bewerten wir über 200 Betrugssignale in Echtzeit und verifizieren jedes Feld anhand autoritativer Datenquellen. Ergebnis in unter zwei Sekunden.
Echtzeit-signierte Webhooks halten deine Datenbank synchron, sobald ein Nutzer genehmigt, abgelehnt oder zur Überprüfung gesendet wird. Frage die API bei Bedarf ab. Oder öffne die Konsole, um jede Session, jedes Signal zu überprüfen und Fälle nach deinen Wünschen zu verwalten.
Didit · IVMS-101
Originator
Begünstigter
Didit · Regionale Regeln
Didit · TR Interoperabilität
Didit · Unhosted Wallet
Didit · Transaktions-API
Didit · Nachweispaket
$ 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 Genehmigt · In Prüfung · Abgelehnt }$ 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": "J. Pérez" },
"counterparty": { "full_name": "R. Beneficiary", "payment_method": { "account_id": "bc1qa3…hk22" }}
}'{ Status GENEHMIGT · IN_PRÜFUNG · ABGELEHNT · WARTET_AUF_NUTZER }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 / Monat. Keine Kreditkarte erforderlich.
Zahle nur, was du nutzt. Über 25 Module. Öffentliche Preise pro Modul, keine monatliche Mindestgebühr.
Individuelle MSA & SLA. Für große Volumina und regulierte Programme.
Kostenlos starten → nur zahlen, wenn eine Prüfung läuft → Enterprise für einen individuellen Vertrag, SLA oder Datenresidenz freischalten.
Didit ist die Infrastruktur für Identität und Betrug, die Plattform, die wir uns beim Entwickeln eigener Produkte gewünscht hätten: offen, flexibel und entwicklerfreundlich, damit sie sich nahtlos in deinen Stack einfügt, anstatt eine Blackbox zu sein, um die du herum integrieren musst.
Eine einzige API deckt die Verifizierung von Personen (KYC, Know Your Customer), Unternehmen (KYB, Know Your Business), das Screening von Krypto-Wallets (KYT, Know Your Transaction) und die Echtzeit-Überwachung von Transaktionen ab, auf einem Stack, der darauf ausgelegt ist:
Die zugrunde liegende Basis: über 14.000 Dokumenttypen in über 48 Sprachen, über 1.000 Datenquellen und über 200 Betrugssignale pro Session. Die Didit-Infrastruktur lernt dynamisch aus jeder Session und wird täglich besser.
Die Travel Rule besagt, dass bei Werttransfers zwischen zwei regulierten Anbietern bestimmte Kundeninformationen, Name, Kontonummer, Adresse, den Wert begleiten müssen.
Sie entstand im traditionellen Finanzwesen (US Bank Secrecy Act von 1970), wurde 2019 von der Financial Action Task Force (FATF) global erweitert und gilt nun überall für Krypto. Das Standard-Payload-Format ist InterVASP Messaging Standard 101 (IVMS-101), ein JSON-Schema, das jedes wichtige Travel Rule Protokoll spricht.
Das Ziel der Regulierungsbehörden ist einfach: Kriminelle daran hindern, Erlöse anonym über Anbieterketten zu waschen, indem sichergestellt wird, dass Identitätsdaten den Wert bei jedem Schritt begleiten.
Jeder regulierte Virtual Asset Service Provider (VASP) oder Crypto-Asset Service Provider (CASP), Börsen, On/Off-Ramps, Custodial Wallets, Broker, OTC-Desks, Zahlungsinstitute, die Krypto-Settlement berühren.
Aktive Jurisdiktionen:
Die FATF führt gegenseitige Bewertungen der Umsetzung in jedem Land durch. Nicht konforme Jurisdiktionen riskieren eine Grey-List-Einstufung.
Der gesamte Prozess dauert normalerweise unter 30 Sekunden von Anfang bis Ende, Ausweis nehmen, Dokument scannen, Selfie machen, fertig. Das ist der schnellste am Markt. Herkömmliche KYC-Anbieter benötigen für denselben Ablauf meist mehr als 90 Sekunden.
Im Backend liefert Didit das Ergebnis in unter zwei Sekunden bei p99, gemessen vom Abschluss des Selfies bis zum Auslösen deines Webhooks. Die mobile Erfassung ist für langsame Telefone und Netzwerke optimiert: progressive Bildkomprimierung, Lazy-Load des Software Development Kits und eine One-Tap-Übergabe vom Desktop zum Telefon via QR-Code, falls der Nutzer am Web startet.
Der minimale FATF-Datensatz umfasst:
Die Daten werden über ein Travel Rule Protokoll zwischen den beiden Anbietern übertragen, nicht On-Chain, nicht im Transaktionsmemo. Der heutige Markt ist fragmentiert: Anbieter wählen ein oder mehrere Protokolle wie TRP, Sumsub Travel Rule, Notabene, Veriscope, OpenVASP und Shyft. Die gemeinsame Sprache ist IVMS-101, die jedes Protokoll lesen und schreiben kann.
Der Empfänger des Transfers verifiziert die Daten, bevor er das Konto des Begünstigten gutschreibt.
Jede Sitzung landet in einem von sieben klaren Status, sodass dein Code immer weiß, was zu tun ist:
Approved, alle Prüfungen bestanden. Der Nutzer kann fortfahren.Declined, eine oder mehrere Prüfungen fehlgeschlagen. Du kannst dem Nutzer erlauben, den spezifischen fehlgeschlagenen Schritt erneut einzureichen (z.B. das Selfie neu aufzunehmen), ohne den gesamten Ablauf erneut durchzuführen.In Review, zur Compliance-Prüfung markiert. Öffne den Fall in der Konsole, sieh dir alle Signale an, entscheide über Genehmigung oder Ablehnung.In Progress, der Nutzer befindet sich mitten im Prozess.Not Started, Link gesendet, Nutzer hat ihn noch nicht geöffnet. Sende eine Erinnerung, wenn es zu lange dauert.Abandoned, Nutzer hat den Link geöffnet, aber nicht rechtzeitig abgeschlossen. Erneut ansprechen oder ablaufen lassen.Expired, der Sitzungslink ist abgelaufen. Erstelle eine neue Sitzung.Ein signierter Webhook wird bei jeder Statusänderung ausgelöst, sodass deine Datenbank immer synchron bleibt. Abgebrochene und abgelehnte Sitzungen sind kostenlos.
Produktionsdaten werden standardmäßig in der Europäischen Union verarbeitet und gespeichert, auf Amazon Web Services. Für Unternehmenskunden können alternative Regionen angefragt werden, wenn dies von den Regulierungsbehörden der jeweiligen Jurisdiktionen gefordert wird.
Verschlüsselung überall. AES-256 im Ruhezustand über jede Datenbank, jeden Objektspeicher und jedes Backup. Transport Layer Security 1.3 während der Übertragung bei jedem API-Aufruf, Webhook und jeder Business Console-Sitzung. Biometrische Daten werden unter einem separaten Customer Master Key verschlüsselt.
Die Aufbewahrung liegt in deiner Hand. Die Standardaufbewahrungsfrist ist unbegrenzt (unendlich), es sei denn, du konfigurierst eine kürzere, zwischen 30 Tagen und 10 Jahren pro Anwendung, und du kannst jede einzelne Sitzung jederzeit über das Dashboard oder die API löschen.
Zertifizierungen: SOC 2 Typ 1 (Typ 2 Audit läuft), ISO/IEC 27001:2022, iBeta Level 1 PAD und eine öffentliche Bestätigung des spanischen Tesoro / SEPBLAC / CNMV, dass Didits Fernidentitätsverifizierung sicherer ist als die persönliche Verifizierung. Vollständiger Bericht unter /security-compliance.
Didit ist standardmäßig konform für die Regulierungsbehörden, die für die Identitätsinfrastruktur relevant sind:
Detailliertes Memo, jedes Zertifikat, jedes Schreiben der Regulierungsbehörde: /security-compliance.
Drei Integrationspfade, wähle den, der zu deinem Stack passt:
Dasselbe Dashboard, dieselbe Abrechnung, derselbe Pay-per-Success-Preis für alle drei. Schritt-für-Schritt-Anleitung unter docs.didit.me/integration/integration-prompt.
Im echten Leben gibt es selten saubere Travel Rule Pakete, Gegenparteien senden Teildaten, Felder stimmen nicht mit dem KYC-Namen überein, Adressformate unterscheiden sich. Zwei Wege:
DECLINED zurückgegeben und der Nutzer wird aufgefordert, sie erneut einzureichenIN_REVIEW zurückgegeben und ein Fall wird in der Business Console mit hervorgehobener Differenz geöffnetAWAITING_USER zurückgegeben und Didit erstellt automatisch eine Remediation-Sitzung, die eine Verifizierungs-URL in der Antwort zurückgibtDein Compliance-Team prüft den Fall, fordert bei Bedarf weitere Daten an und genehmigt oder lehnt ihn innerhalb der Konsole ab. Prüfernotizen, Entscheidung und Zeitstempel werden für das Audit-Paket erfasst.
Travel Rule Daten werden pro Transfer gesammelt, nicht pro Beziehung, es gibt keine „Aktualisierung“ eines Travel Rule Pakets. Aber die Nutzer hinter den Transfers müssen gemäß dem EU-AML-Paket und ähnlichen Regelwerken kontinuierlich überwacht werden.
Didit führt durch:
Alle drei speisen dieselbe Case Management Oberfläche, sodass ein einziger Prüfer das vollständige Bild pro Nutzer sieht.
Die meisten Regulierungsbehörden verlangen mindestens 5 Jahre Aufzeichnungen über jeden Travel Rule Transfer und die zugrunde liegende Nutzeridentität, manchmal länger, wenn deine Aufsichtsbehörde dies anfordert.
Didits Aufbewahrungsmodell:
Didit ist die einzige KYC-Plattform mit einer formellen staatlichen Bestätigung eines EU-Mitgliedstaates, das spanische Finanzministerium, die Banco de España und SEPBLAC haben den Dienst gemeinsam als sicherer als die persönliche Verifizierung attestiert. Der Bericht fließt direkt in dein CASP-Autorisierungspaket ein.
Eine API für KYC, KYB, Transaktionsüberwachung und Wallet-Screening. In 5 Minuten integriert.