تتبادل Didit بيانات قاعدة السفر وتفحص محفظة الطرف المقابل في نفس مكالمة معاملة /v3/. حمولات IVMS-101، 0.17 دولار لكل تحويل مُدار، 500 عملية تحقق مجانية كل شهر.
Robinhood Ventures
موثوق به من قبل أكثر من 2,000 مؤسسة حول العالم.
ما تفرضه قاعدة السفر
كل مزود خدمة أصول افتراضية (VASP) منظم ملزم بتوفير كلا الجزأين في كل تحويل, حزمة IVMS-101 لمزود خدمة الأصول الافتراضية المقابل، وفحص المخاطر على السلسلة لنفسه. تقدم Didit هذه كاستدعاء واحد لواجهة برمجة تطبيقات المعاملات: 0.17 دولار مُدار، 0.04 دولار مع استخدام مفتاحك الخاص (Bring Your Own Key) لمزود المحفظة. 500 عملية تحقق مجانية كل شهر.
اختر الفحوصات التي تريدها, الهوية، التحقق من الحياة، مطابقة الوجه، العقوبات، العنوان، العمر، الهاتف، البريد الإلكتروني، الأسئلة المخصصة. اسحبها إلى سير عمل في لوحة التحكم، أو انشر نفس سير العمل إلى واجهة برمجة التطبيقات الخاصة بنا. قم بالتفرع بناءً على الشروط، وقم بإجراء اختبارات A/B، لا يتطلب الأمر أي كود.
قم بالدمج بشكل أصلي باستخدام حزم SDK الخاصة بنا للويب، iOS، Android، React Native، أو Flutter. أعد التوجيه إلى صفحة مستضافة. أو ببساطة أرسل لمستخدمك رابطًا, عبر البريد الإلكتروني، الرسائل القصيرة، واتساب، أي مكان. اختر ما يناسب نظامك.
تستضيف Didit الكاميرا، إشارات الإضاءة، التسليم عبر الهاتف المحمول، وإمكانية الوصول. بينما يكون المستخدم في سير العمل، نقوم بتقييم أكثر من 200 إشارة احتيال في الوقت الفعلي والتحقق من كل حقل مقابل مصادر البيانات الموثوقة. النتيجة في أقل من ثانيتين.
تحافظ الـ webhooks الموقعة في الوقت الفعلي على مزامنة قاعدة بياناتك لحظة الموافقة على المستخدم، أو رفضه، أو إرساله للمراجعة. استعلم من واجهة برمجة التطبيقات عند الطلب. أو افتح وحدة التحكم لفحص كل جلسة، كل إشارة، وإدارة الحالات بطريقتك.
Didit · IVMS-101
Originator
Beneficiary
Didit · Per-region rules
Didit · TR interoperability
Didit · Unhosted wallet
Didit · Transactions API
Didit · Evidence pack
$ 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 is infrastructure for identity and fraud, the platform we wished existed when we were building products ourselves: open, flexible, and developer-friendly, so it works as a real part of your stack instead of a black box you integrate around.
One API covers verifying people (KYC, know your customer), verifying businesses (KYB, know your business), screening crypto wallets (KYT, know your transaction), and monitoring transactions in real time, on a stack built to be:
The footprint underneath: 14,000+ document types in 48+ languages, 1,000+ data sources, and 200+ fraud signals on every session. The Didit infrastructure dynamically learns from every session and gets better every day.
The Travel Rule says that when value moves between two regulated providers, certain pieces of customer information, name, account number, address, must travel alongside the value itself.
It started in traditional finance (the US Bank Secrecy Act of 1970), was extended globally by the Financial Action Task Force (FATF) in 2019, and now applies to crypto everywhere. The standard payload format is InterVASP Messaging Standard 101 (IVMS-101), a JSON schema every major Travel Rule protocol speaks.
The regulator's goal is simple: stop bad actors from laundering proceeds anonymously through chains of providers by ensuring identity data follows the value at every hop.
Every regulated Virtual Asset Service Provider (VASP) or Crypto-Asset Service Provider (CASP), exchanges, on/off-ramps, custodial wallets, brokers, OTC desks, payment institutions that touch crypto settlement.
Live jurisdictions:
FATF runs mutual evaluations of each country's implementation. Non-compliant jurisdictions risk grey-list designation.
The full flow normally takes under 30 seconds end-to-end, pick up the ID, snap the document, snap the selfie, done. That is the fastest in the market. Legacy KYC providers usually take more than 90 seconds for the same flow.
On the back end, Didit returns the result in under two seconds at p99, measured from the moment the user finishes the selfie to the moment your webhook fires. Mobile capture is tuned for slow phones and slow networks: progressive image compression, lazy software development kit load, and a one-tap hand-off from desktop to phone via QR code if the user starts on web.
The minimum FATF dataset is:
The data moves through a Travel Rule protocol between the two providers, not on-chain, not in the transaction memo. Today's market is fragmented: providers pick one or more of TRP, Sumsub Travel Rule, Notabene, Veriscope, OpenVASP, and Shyft. The shared language is IVMS-101, which every protocol reads and writes.
The receiver of the transfer verifies the data before crediting the beneficiary's account.
Every session lands on one of seven clear statuses, so your code always knows what to do:
Approved, every check passed. Move the user forward.Declined, one or more checks failed. You can allow the user to resubmit the specific failed step (for example, re-take the selfie) without re-running the whole flow.In Review, flagged for compliance review. Open the case in the console, see every signal, decide approve or decline.In Progress, user is mid-flow.Not Started, link sent, user has not opened it yet. Send a reminder if it sits too long.Abandoned, user opened the link but did not finish in time. Re-engage or expire.Expired, the session link aged out. Create a new session.A signed webhook fires on every status change, so your database always stays in sync. Abandoned and declined sessions are free.
Production data is processed and stored in the European Union by default, on Amazon Web Services. Enterprise contracts can request alternative regions for jurisdictions whose regulators require it.
Encryption everywhere. AES-256 at rest across every database, object store, and backup. Transport Layer Security 1.3 in transit on every API call, webhook, and Business Console session. Biometric data is encrypted under a separate Customer Master Key.
Retention is yours to control. Default retention is indefinite (unlimited) unless you configure shorter, between 30 days and 10 years per application, and you can delete any individual session at any time from the dashboard or the API.
Certifications: SOC 2 Type 1 (Type 2 audit in progress), ISO/IEC 27001:2022, iBeta Level 1 PAD, and a public attestation from Spain''s Tesoro / SEPBLAC / CNMV that Didit''s remote identity verification is safer than verifying someone in person. Full report at /security-compliance.
Didit ships compliant by default for the regulators that matter to identity infrastructure:
Detailed memo, every certificate, every regulator letter: /security-compliance.
Three integration paths, pick whichever fits your stack:
Same dashboard, same billing, same pay-per-success price for all three. Step-by-step guide at docs.didit.me/integration/integration-prompt.
Real life rarely produces clean Travel Rule packets, counterparties send partial data, fields don't match the KYC name, address formats differ. Two paths:
DECLINED and the user is prompted to resubmitIN_REVIEW and a case opens in the Business Console with the diff highlightedAWAITING_USER and Didit creates a remediation session automatically, returning a verification URL on the responseYour compliance team triages the case, requests more data if needed, and approves or rejects from inside the Console. Reviewer notes, decision, and timestamps are recorded for the audit pack.
Travel Rule data is collected per transfer, not per relationship, there is no "refresh" of a Travel Rule packet. But the users behind the transfers must be monitored continuously under the EU AML package and equivalent regimes.
Didit runs:
All three feed the same Case Management surface, so a single reviewer sees the full picture per user.
Most regulators require at least 5 years of records on every Travel Rule transfer and the underlying user identity, sometimes longer if your supervisor requests it.
Didit's retention model:
Didit is the only KYC provider with a formal EU member-state government attestation, Spain's Treasury, Banco de España, and SEPBLAC jointly attested the service as safer than in-person verification. The report files directly into your CASP authorisation pack.
واجهة برمجية واحدة لـ KYC و KYB ومراقبة المعاملات وفحص المحافظ. ادمجها في 5 دقائق.