تبادل بيانات قاعدة السفر: TRISA و TRP و OpenVASP (AR)

إذا نظرنا إلى قاعدة السفر الخاصة بـ FATF من الناحية الميكانيكية، فهي مشكلة مراسلة. قبل تسوية تحويل العملات المشفرة، يجب على مزود خدمة الأصول الافتراضية (VASP) المُرسِل تسليم مزود خدمة الأصول الافتراضية المُستلِم حزمة منظمة تصف المنشئ والمستفيد — الاسم، المعرفات، المراجع المصرفية — ويجب على الطرف المستلم تأكيدها. تكمن المشكلة في عدم وجود مسار عالمي واحد لهذه المصافحة. بدلاً من ذلك، هناك بروتوكولات تشغيل تنافسية، ولا ينجح التحويل إلا عندما يستطيع كلا مزودي خدمات الأصول الافتراضية التحدث بأحدها.

يتولى Didit إجراء هذه المصافحة نيابة عنك. تم دمج تبادل بيانات قاعدة السفر في مراقبة المعاملات، ويتحدث المحرك البروتوكولات الثلاثة التي يستخدمها مزودو خدمات الأصول الافتراضية بالفعل في الإنتاج — TRISA و TRP و OpenVASP. ترسل التحويل مرة واحدة؛ يقوم المحرك بحل الطرف المقابل، ويختار بروتوكولًا يدعمه كلا الطرفين، ويتبادل حمولات المنشئ والمستفيد، ويتتبع الالتزام بحالة معينة. يشرح هذا الدليل البروتوكولات والحمولات وكيفية سير التبادل.

النقاط الرئيسية

• قاعدة السفر هي تبادل بيانات بين مزودي خدمات الأصول الافتراضية (VASP-to-VASP). يرسل المرسل معلومات المنشئ والمستفيد؛ ويجمعها المستلم ويؤكدها.
• ثلاثة بروتوكولات تحمل هذا التبادل — TRISA و TRP و OpenVASP — لكل منها نموذج ثقة ونقل مختلف. يدعم Didit الثلاثة جميعًا.
• الحمولة هي سجل المنشئ والمستفيد — الأطراف في التحويل، منظمة بحيث يقرأ كلا مزودي خدمات الأصول الافتراضية نفس الحقول.
• يدير Didit التبادل داخل مراقبة المعاملات، ويحل كل التزام إلى واحدة من ست حالات (UNKNOWN، COMPLIANT، PENDING_ACTION، PENDING_COUNTERPARTY، FAILED، EXEMPT).
• واجهة برمجة تطبيقات واحدة /v3/. يتم نشر تحويلات العملات المشفرة إلى POST https://verification.didit.me/v3/transactions/ مع currency_kind: "crypto"، ويتم تشغيل فحص المحفظة جنبًا إلى جنب بدءًا من 0.02 دولار (أحضر مفتاحك الخاص).

ما تفعله البروتوكولات

تحل البروتوكولات الثلاثة جميعًا نفس المشكلتين — كيف أجد مزود خدمة الأصول الافتراضية المقابل وأثق به؟ و كيف أرسل له بيانات العميل بشكل آمن؟ — لكنها تقدم مقايضات مختلفة.

• TRISA (بنية مشاركة معلومات قاعدة السفر) هو نموذج من نظير إلى نظير مبني على سلطة شهادات. يقوم مزودو خدمات الأصول الافتراضية بالتسجيل، وإثبات هويتهم، واستلام الشهادات، ثم تبادل البيانات مباشرة عبر قناة مشفرة. ترتكز الثقة على دليل الأعضاء المعتمدين.
• TRP (بروتوكول قاعدة السفر) هو مواصفات تعتمد على واجهة برمجة التطبيقات أولاً وتفضلها مجموعة من المؤسسات الأكبر. تحدد مصافحة REST خفيفة الوزن لإرسال حمولة المنشئ والمستفيد بين الأطراف المقابلة التي أقامت اتصالًا.
• OpenVASP هو معيار مفتوح يستخدم الإشارات على السلسلة وعلى مستوى المراسلة لإنشاء جلسة بين مزودي خدمات الأصول الافتراضية قبل التحويل، ثم يتبادل بيانات العميل خارج السلسلة.

يجب على مزود خدمة الأصول الافتراضية الذي يريد وصولًا واسعًا أن يدعم أكثر من بروتوكول واحد، لأن الأطراف المقابلة له لن تكون كلها على نفس البروتوكول. تشغيل التبادل داخل Didit يعني أنك لا تختار واحدًا وتأمل — فالمحرك يتفاوض على أي بروتوكول يدعمه الطرف المقابل.

لماذا يهم

بموجب التوصية 16 لـ FATF وتطبيقاتها الإقليمية — لائحة الاتحاد الأوروبي لتحويل الأموال على رأسها — أصبح تبادل بيانات المنشئ والمستفيد إلزاميًا فوق الحد الأدنى، ويقوم المشرفون بفحصه. لكن المتطلب مكتوب من حيث النتائج (يجب إرسال البيانات والاحتفاظ بها وتأكيدها)، وليس البروتوكولات. تجزئة البروتوكولات هي حقيقة هندسية ترثها، وليست قاعدة يمكنك تجاوزها بالقراءة.

هذا هو بالضبط السبب في أن دعم البروتوكول لا ينبغي أن يكون مشكلتك في البناء. إنشاء تسجيل TRISA، ونقطة نهاية TRP، وإشارات OpenVASP — والحفاظ على تحديثها جميعًا — هو تكلفة هندسية مستمرة لا علاقة لها بمنتجك. دمجها في نفس محرك المراقبة الذي يقوم بالفعل بتقييم التحويل يقلص هذه التكلفة في تكامل واحد.

التفاصيل الفنية

يتم إنشاء التحويل مقابل واجهة برمجة التطبيقات الموحدة /v3/. المنشئ هو subject، والمستفيد هو counterparty، و currency_kind: "crypto" يؤدي إلى تشغيل مسارات قاعدة السفر وفحص المحفظة.

curl -X POST https://verification.didit.me/v3/transactions/ \
  -H "x-api-key: $DIDIT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "transaction_id": "txn_7b9e22",
    "category": "travel_rule",
    "amount": 12500,
    "currency": "BTC",
    "currency_kind": "crypto",
    "direction": "OUTBOUND",
    "txn_date": "2026-05-21T12:14:00Z",
    "subject": {
      "vendor_data": "user_8830",
      "role": "ORIGINATOR",
      "entity_type": "INDIVIDUAL",
      "first_name": "Marta",
      "last_name": "Ferreira"
    },
    "counterparty": {
      "role": "BENEFICIARY",
      "entity_type": "INDIVIDUAL",
      "wallet_address": "bc1q...0a7k"
    }
  }'

يقوم المحرك بحل مزود خدمة الأصول الافتراضية المقابل، ويختار بروتوكولًا مدعومًا، ويتبادل الحمولة، ويعيد البروتوكول المستخدم بالإضافة إلى حالة قاعدة السفر:

{
  "transaction_id": "txn_7b9e22",
  "status": "APPROVED",
  "travel_rule_status": "COMPLIANT",
  "protocol": "TRP",
  "counterparty_vasp": "vasp_resolved",
  "wallet_screening": {
    "risk_score": 9,
    "risk_level": "LOW"
  }
}

حمولة المنشئ/المستفيد. يحمل كل تحويل الطرفين كسجلات منظمة — المنشئ (العميل المُرسِل) والمستفيد (العميل المُستلِم) — بحيث يقوم كلا مزودي خدمات الأصول الافتراضية بتعيين نفس الحقول بغض النظر عن البروتوكول. بيانات المنشئ هي بياناتك التي توفرها من KYC الذي تحتفظ به بالفعل؛ ويتم تأكيد جانب المستفيد من قبل الطرف المقابل أثناء التبادل.

الحالات الست. أي بروتوكول يحمل التبادل، يتم حل الالتزام إلى إحدى الحالات:

الحالة	المعنى
UNKNOWN	لم يتم تقييمه بعد، أو تعذر حل مزود خدمة الأصول الافتراضية المقابل.
COMPLIANT	تم تبادل البيانات وتأكيدها — تم الوفاء بالالتزام.
PENDING_ACTION	مطلوب شيء من جانبك للمتابعة.
PENDING_COUNTERPARTY	في انتظار رد مزود خدمة الأصول الافتراضية المقابل.
FAILED	لم يتمكن التبادل من الاكتمال — طرف مقابل غير قابل للوصول، بيانات مرفوضة، أو عدم تطابق البروتوكول.
EXEMPT	خارج النطاق — أقل من الحد الأدنى أو غير ملزم بأي شكل آخر.

فحص المحفظة جنبًا إلى جنب. يتم فحص عنوان الطرف المقابل على السلسلة في نفس المكالمة من 0.02 دولار لكل فحص مع مفتاحك الخاص (Crystal أو Merkle Science)، لذا فإن COMPLIANT على مستوى البروتوكول لا يخفي مخاطر على مستوى العنوان.

اختيار — وعدم اختيار — بروتوكول

النصيحة العملية لمزود خدمة الأصول الافتراضية هي: لا تختار. يتوزع الأطراف المقابلة لك عبر TRISA و TRP و OpenVASP، والبروتوكول الذي يجعل تحويلًا معينًا COMPLIANT هو أي بروتوكول يدعمه هذا الطرف المقابل. نظرًا لأن Didit يتفاوض على البروتوكول لكل تحويل، فإن تكاملك هو نفسه بغض النظر — ترسل بيانات المنشئ والمستفيد مرة واحدة، ويتولى المحرك المصافحة. حالة FAILED مع عدم تطابق البروتوكول هي إشارة للتحقيق مع الطرف المقابل، وليست فجوة في نظامك.

حالات الاستخدام

• مزودو خدمات الأصول الافتراضية والبورصات — الوصول إلى الأطراف المقابلة عبر البروتوكولات الثلاثة من تكامل واحد، بدلاً من بناء وصيانة كل مسار.
• منصات الإيداع/السحب — تبادل بيانات المنشئ والمستفيد مع مزودي خدمات الأصول الافتراضية الوجهة أثناء فحص المحفظة المستلمة في نفس المكالمة.
• الحراس — التعامل مع عدد كبير من الأطراف المقابلة على بروتوكولات مختلطة بنموذج حالة واحد ومتسق.
• واجهات DeFi الأمامية — إجراء التبادل حيث يوجد مزود خدمة أصول افتراضية منظم في التدفق، والتحول إلى EXEMPT حيث لا ينطبق الالتزام حقًا.

كيفية التكامل مع Didit

1. تمكين قواعد قاعدة السفر. في Business Console، قم بتشغيل قواعد قاعدة السفر المحددة مسبقًا جنبًا إلى جنب مع مراقبة العملات المشفرة وفحص العملات المشفرة.
2. إرسال التحويل. POST /v3/transactions/ مع currency_kind: "crypto"، والمنشئ كـ subject، والمستفيد كـ counterparty، وفئة travel_rule.
3. قراءة البروتوكول والحالة. يخبرك الرد بالبروتوكول الذي حمل التبادل وحالة travel_rule_status الناتجة. اتخذ إجراءً بشأن الالتزامات PENDING_* و FAILED.
4. التعامل مع الاستثناءات في Console. عمليات التبادل المعلقة والفاشلة والتنبيهات وسير عمل الحالات موجودة في نفس الواجهة مثل مراقبتك.

كل هذا يتم تشغيله على واجهة برمجة التطبيقات الموحدة /v3/، لذا فإن العميل الذي قمت بإعداده باستخدام KYC، وفحصته باستخدام مكافحة غسيل الأموال، وتقدم له الآن تحويلًا هو نفس الهوية التي يتم تتبعها عبر المراقبة وفحص المحفظة وقاعدة السفر.

الأسئلة المتكررة

ما هي بروتوكولات قاعدة السفر التي يدعمها Didit؟

TRISA و TRP و OpenVASP — البروتوكولات الثلاثة التي يستخدمها مزودو خدمات الأصول الافتراضية في الإنتاج. يتفاوض المحرك على أي بروتوكول يدعمه طرف مقابل معين.

ما هي البيانات التي يتم تبادلها؟

سجلات المنشئ والمستفيد — الأطراف في التحويل — منظمة بحيث يقرأ كلا مزودي خدمات الأصول الافتراضية نفس الحقول. أنت تقدم المنشئ من KYC الحالي الخاص بك؛ ويؤكد الطرف المقابل جانب المستفيد.

هل يجب علي اختيار بروتوكول واحد؟

لا. اختيار واحد سيقطعك عن الأطراف المقابلة على البروتوكولات الأخرى. يختار Didit البروتوكول لكل تحويل بناءً على ما يدعمه الطرف المقابل.

ماذا يحدث إذا تعذر الوصول إلى الطرف المقابل؟

يتم حل الالتزام إلى FAILED (مع سبب مثل عدم تطابق البروتوكول أو طرف مقابل غير قابل للوصول) أو يبقى في PENDING_COUNTERPARTY بينما تنتظر — وكلاهما مرئي في Console.

هل هذا منتج منفصل عن مراقبة المعاملات؟

لا. تم دمج تبادل البيانات في مراقبة المعاملات، على نفس تحويل العملات المشفرة الذي ترسله بالفعل للمراقبة وفحص المحفظة.

هل أنت مستعد للبدء؟

اقرأ وثائق قاعدة السفر، واطلع على الصورة الكاملة على صفحة حل قاعدة السفر للعملات المشفرة و صفحة منتج مراقبة المعاملات، وتحقق من الأسعار الشفافة لكل مكالمة على صفحة الأسعار. عندما تكون مستعدًا، ابدأ مجانًا — 500 فحص KYC مجاني كل شهر، مع دمج تبادل بيانات قاعدة السفر في المراقبة.