تتبادل 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
المنشئ
المستفيد
Didit · قواعد خاصة بكل منطقة
Didit · قابلية التشغيل البيني TR
Didit · المحفظة غير المستضافة
Didit · واجهة برمجة تطبيقات المعاملات
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 هي بنية تحتية للهوية والاحتيال, المنصة التي تمنينا وجودها عندما كنا نبني منتجاتنا بأنفسنا: مفتوحة، مرنة، وصديقة للمطورين، لتعمل كجزء حقيقي من حزمتك التقنية بدلاً من صندوق أسود تدمجه حوله.
تغطي واجهة برمجة تطبيقات واحدة التحقق من الأشخاص (KYC، اعرف عميلك)، والتحقق من الشركات (KYB، اعرف عملك)، وفحص محافظ العملات المشفرة (KYT، اعرف معاملتك)، ومراقبة المعاملات في الوقت الفعلي, على بنية مصممة لتكون:
البصمة الأساسية: أكثر من 14,000 نوع مستند بأكثر من 48 لغة، أكثر من 1,000 مصدر بيانات، وأكثر من 200 إشارة احتيال في كل جلسة. تتعلم بنية Didit التحتية ديناميكيًا من كل جلسة وتتحسن كل يوم.
تنص قاعدة السفر (Travel Rule) على أنه عند انتقال القيمة بين مزودين منظمين، يجب أن تنتقل بعض أجزاء معلومات العميل, الاسم، رقم الحساب، العنوان, جنبًا إلى جنب مع القيمة نفسها.
بدأت هذه القاعدة في التمويل التقليدي (قانون السرية المصرفية الأمريكي لعام 1970)، وتم توسيعها عالميًا من قبل فرقة العمل المعنية بالإجراءات المالية (FATF) في عام 2019، وتطبق الآن على العملات المشفرة في كل مكان. تنسيق الحمولة القياسي هو معيار المراسلة InterVASP 101 (IVMS-101), وهو مخطط JSON تتحدث به جميع بروتوكولات Travel Rule الرئيسية.
هدف الجهة التنظيمية بسيط: منع الجهات الفاعلة السيئة من غسل العائدات بشكل مجهول عبر سلاسل من المزودين من خلال ضمان تتبع بيانات الهوية للقيمة في كل خطوة.
كل مزود خدمة أصول افتراضية (VASP) أو مزود خدمة أصول مشفرة (CASP) منظم, البورصات، منصات الإيداع/السحب، المحافظ الحاضنة، الوسطاء، مكاتب التداول خارج البورصة (OTC)، مؤسسات الدفع التي تتعامل مع تسوية العملات المشفرة.
الولايات القضائية التي تطبقها حاليًا:
تجري 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 في وضع السكون عبر كل قاعدة بيانات، ومخزن كائنات، ونسخة احتياطية. أمان طبقة النقل 1.3 أثناء النقل في كل استدعاء API، وويب هوك، وجلسة Business Console. يتم تشفير البيانات البيومترية بمفتاح رئيسي منفصل للعميل.
الاحتفاظ بالبيانات تحت سيطرتك. الاحتفاظ الافتراضي هو غير محدود (بلا حدود) ما لم تقم بتكوين مدة أقصر, تتراوح بين 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. ولكن المستخدمين وراء التحويلات يجب مراقبتهم باستمرار بموجب حزمة مكافحة غسل الأموال في الاتحاد الأوروبي والأنظمة المماثلة.
تقوم Didit بتشغيل:
تغذي جميع هذه العناصر نفس واجهة إدارة الحالات، بحيث يرى المراجع الواحد الصورة الكاملة لكل مستخدم.
تتطلب معظم الجهات التنظيمية ما لا يقل عن 5 سنوات من السجلات لكل تحويل بموجب Travel Rule وهوية المستخدم الأساسية، وأحيانًا أطول إذا طلب المشرف الخاص بك ذلك.
نموذج الاحتفاظ بالبيانات في Didit:
Didit هي منصة KYC الوحيدة التي لديها تصديق رسمي من حكومة دولة عضو في الاتحاد الأوروبي, حيث صدقت وزارة الخزانة الإسبانية، وبنك إسبانيا، و SEPBLAC بشكل مشترك على الخدمة بأنها أكثر أمانًا من التحقق الشخصي. يتم إيداع التقرير مباشرة في حزمة ترخيص CASP الخاصة بك.
واجهة برمجية واحدة لـ KYC و KYB ومراقبة المعاملات وفحص المحافظ. ادمجها في 5 دقائق.