قاعدة السفر الخاصة بـ FATF، مدمجة في مراقبة المعاملات (AR)

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

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

يشرح هذا الدليل كيف يبدو ذلك، ولماذا تم بناؤه بهذه الطريقة، وكيفية دمجه.

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

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

ما تفعله قاعدة السفر

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

هذا التأكيد هو سير العمل الذي تنفذه Didit. عندما ترسل معاملة عملات مشفرة للمراقبة، يقوم المحرك بتحديد مزود خدمة الأصول الافتراضية المقابل، ويتبادل حمولات بيانات المنشئ والمستفيد عبر بروتوكول مدعوم، ويحل الالتزام إلى حالة يمكنك التصرف بناءً عليها. التحويل الذي يؤكده الطرف المقابل يصبح COMPLIANT؛ والتحويل الذي ينتظر الطرف الآخر يبقى في حالة PENDING_COUNTERPARTY؛ والتحويل الذي يقل عن الحد الأدنى أو خارج النطاق بطريقة أخرى يكون EXEMPT.

لماذا يهم الأمر

لم يعد تطبيق قاعدة السفر نظريًا. تتطلب لائحة الاتحاد الأوروبي لتحويل الأموال، وتطبيق المملكة المتحدة لها، وقائمة متزايدة من الأنظمة الوطنية الآن من مزودي خدمة الأصول الافتراضية إجراء تبادل البيانات، مع قيام المشرفين بفحصها بنشاط. تكلفة الخطأ هي مخاطر الترخيص، وليس مجرد غرامة.

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

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

يتم إنشاء معاملات العملات المشفرة مقابل واجهة برمجة التطبيقات الموحدة /v3/، وهي نفس نقطة النهاية التي تتعامل مع العملات الورقية. يؤدي تعيين 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_c41f08",
    "category": "travel_rule",
    "amount": 4200,
    "currency": "USDC",
    "currency_kind": "crypto",
    "direction": "OUTBOUND",
    "txn_date": "2026-05-21T11:05:00Z",
    "subject": {
      "vendor_data": "user_4521",
      "role": "ORIGINATOR",
      "entity_type": "INDIVIDUAL"
    },
    "counterparty": {
      "role": "BENEFICIARY",
      "entity_type": "INDIVIDUAL",
      "wallet_address": "0x9f2a...c81d"
    }
  }'

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

{
  "transaction_id": "txn_c41f08",
  "status": "IN_REVIEW",
  "travel_rule_status": "PENDING_COUNTERPARTY",
  "wallet_screening": {
    "risk_score": 18,
    "risk_level": "LOW"
  },
  "protocol": "TRISA"
}

حالات قاعدة السفر الست. كل التزام يتم حله إلى حالة واحدة فقط:

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

الفئة والقواعد. تحمل المعاملات category من travel_rule لتطبيق السياسة الصحيحة، وتشحن مكتبة القواعد قواعد قاعدة السفر المحددة مسبقًا التي تقوم بتشغيلها وتعديلها في وحدة التحكم بدلاً من البرمجة يدويًا.

فحص المحافظ جنبًا إلى جنب. نظرًا لأن currency_kind هو crypto، يمكن للمحرك تشغيل فحص المحافظ على السلسلة لعنوان الطرف المقابل في نفس الاستدعاء — التحقق من التعرض للكيانات المحظورة، والخلاطات، وأسواق الإنترنت المظلم، وبرامج الفدية، والأموال المسروقة. يبدأ فحص المحافظ من 0.02 دولار لكل فحص مع إحضار مفتاحك الخاص (Crystal أو Merkle Science).

محرك واحد، ثلاث وظائف على كل عملية تحويل

السبب في أن قاعدة السفر تعيش داخل مراقبة المعاملات هو أن تحويل العملات المشفرة يطلق ثلاثة التزامات في وقت واحد، وتتشارك نفس البيانات:

1. المراقبة — يتم تقييم التحويل مقابل حزم قواعد مراقبة وفحص العملات المشفرة للبحث عن الهيكلة والسرعة والأنماط الشاذة.
2. فحص المحافظ — يتم التحقق من عنوان الطرف المقابل على السلسلة للكشف عن مخاطر التعرض.
3. قاعدة السفر — يتم تبادل بيانات المنشئ والمستفيد مع مزود خدمة الأصول الافتراضية المقابل ويتم تتبع الالتزام إلى إحدى الحالات الست.

عند تشغيلها كأدوات ثلاث، تحتاج كل من هذه الوظائف إلى تكاملها الخاص، ونسختها الخاصة من التحويل، وتسويتها الخاصة. عند تشغيلها كمحرك واحد، تتشارك سجل المعاملات، وسجل التدقيق، ووحدة التحكم — ويمكن لالتزام قاعدة السفر الذي يحتاج إلى المزيد من بيانات العميل استخدام نفس حلقة المعالجة AWAITING_USER التي تستخدمها بقية المراقبة.

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

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

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

1. تشغيل حزم القواعد. في وحدة تحكم الأعمال، قم بتمكين مراقبة العملات المشفرة، وفحص العملات المشفرة، وقواعد قاعدة السفر المحددة مسبقًا، وضبط الحدود وفقًا لسياسة المخاطر الخاصة بك.
2. إرسال معاملات العملات المشفرة. POST /v3/transactions/ مع currency_kind: "crypto"، و direction، وتفاصيل المنشئ (subject) والمستفيد (counterparty)، وفئة travel_rule حيثما ينطبق ذلك.
3. قراءة الحالتين. التصرف بناءً على status المعاملة لحركة الأموال و travel_rule_status للالتزام — الاحتفاظ أو المعالجة حيثما تتطلب أي منهما إجراءً.
4. العمل على الباقي في وحدة التحكم. الالتزامات المعلقة والفاشلة، والتنبيهات، وسير عمل الحالة تعيش في نفس الواجهة مثل بقية مراقبتك.

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

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

هل قاعدة السفر منتج منفصل من Didit؟

لا. إنها مدمجة في مراقبة المعاملات. التحويلات المشفرة التي ترسلها بالفعل للمراقبة تحمل تبادل بيانات قاعدة السفر وتتبع الالتزامات في نفس السجل.

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

بروتوكولات التشغيل البيني الرئيسية — TRISA و TRP و OpenVASP — حتى تتمكن من تبادل بيانات المنشئ والمستفيد مع مزودي خدمة الأصول الافتراضية المقابلين عبر الأنظمة المختلفة.

ما هي حالات قاعدة السفر؟

ست حالات: UNKNOWN (غير معروف)، COMPLIANT (متوافق)، PENDING_ACTION (إجراء معلق)، PENDING_COUNTERPARTY (بانتظار الطرف المقابل)، FAILED (فشل)، و EXEMPT (معفى). تخبرك بالضبط أين يقف كل التزام.

كيف يتناسب فحص المحافظ؟

يمكن لمعاملات العملات المشفرة (currency_kind: "crypto") تشغيل فحص المحافظ على السلسلة تلقائيًا على عنوان الطرف المقابل، بدءًا من 0.02 دولار لكل فحص مع إحضار مفتاحك الخاص (Crystal أو Merkle Science).

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

في وحدة تحكم الأعمال. تشحن مكتبة القواعد قواعد قاعدة السفر المحددة مسبقًا التي تقوم بتشغيلها وتعديلها، وتحمل المعاملات تصنيف travel_rule لتطبيق السياسة الصحيحة في السياق.

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

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