حالات قاعدة السفر الست ومسألة "شروق الشمس" (AR)

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

يمنحك Didit ست حالات بالضبط. نظرًا لأن دعم قاعدة السفر مدمج في مراقبة المعاملات، فإن كل التزام في كل تحويل للعملات المشفرة يحل إلى إحدى الحالات التالية: UNKNOWN، COMPLIANT، PENDING_ACTION، PENDING_COUNTERPARTY، FAILED، أو EXEMPT. يشرح هذا الدليل معنى كل حالة، وكيفية التصرف بناءً عليها، وكيف تمنحك هذه الحالات طريقة واضحة للتعامل مع الجزء الأكثر تعقيدًا في الامتثال لقاعدة السفر - وهي "مسألة شروق الشمس"، حيث تكون القاعدة سارية في ولايتك القضائية ولكن ليس في ولاية الطرف المقابل.

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

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

ماذا تعني الحالات الست

كل تحويل للعملات المشفرة يحمل التزامًا بقاعدة السفر يحصل على travel_rule_status. إليك المجموعة الكاملة وكيفية التصرف بناءً على كل منها.

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

قيمة المجموعة المغلقة هي أن السياسة تصبح قابلة للتعبير. يمكنك أن تقول "احتفظ بأي تحويل عملات مشفرة OUTBOUND في حالة PENDING_COUNTERPARTY لمدة تصل إلى N ساعة، ثم قم بالتصعيد" أو "المتابعة تلقائيًا في حالة EXEMPT" – قواعد، وليست قرارات تقديرية.

لماذا يهم هذا

لا تتساءل فحوصات قاعدة السفر فقط هل تبادلت البيانات – بل تسأل هل يمكنك إظهار، لكل تحويل، أين كان الالتزام ولماذا تابعت أو لم تتابع. نموذج الحالات الست هو مسار التدقيق: كل تحويل يحمل حالته، والسبب، والبروتوكول الذي أجرى (أو فشل في إجراء) التبادل. هذا هو الفرق بين سجل جاهز للمراجع وتمرين إعادة بناء.

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

مسألة شروق الشمس

أصعب حالة يمكن التفكير فيها هي FAILED أو PENDING_COUNTERPARTY مقابل طرف مقابل ليس لديه ببساطة أي التزام بقاعدة السفر - لأن ولايته القضائية لم تعتمدها. لقد وضعت FATF القاعدة؛ وتنفذها الولايات القضائية وفقًا لجداولها الزمنية الخاصة. والنتيجة هي تغطية عالمية غير متكافئة: قد تكون أنت ملزمًا تمامًا بينما الطرف المقابل، في ولاية قضائية غير متبنية، ليس ملزمًا بإرسال أو تأكيد أي شيء. هذه الفجوة هي مسألة شروق الشمس - لقد أشرقت الشمس على القاعدة في بعض الأماكن وليس في أماكن أخرى.

لا يمكن حل مشكلة "شروق الشمس" من قبل مزود خدمة أصول افتراضية (VASP) من جانب واحد؛ إنها وظيفة تنظيمية، وليست هندسية. ولكن يمكن التعامل معها، والحالات الست هي الطريقة:

• يظهر الطرف المقابل الذي لم يتبنى القاعدة ولا يستجيب على أنه PENDING_COUNTERPARTY ثم FAILED – وليس كفجوة صامتة.
• تحدد سياستك ما يعنيه FAILED بسبب عدم التبني: المتابعة مع تبرير موثق، أو التعليق، أو الحظر. الحالة تجعل هذا القرار صريحًا ومسجلاً.
• التحويلات التي تقع خارج النطاق حقًا يتم حلها إلى EXEMPT، لذلك لا تضيع وقت المحللين عليها.

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

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

يتم إرجاع الحالات في المعاملة التي تنشرها على واجهة برمجة التطبيقات الموحدة /v3/.

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_a17d63",
    "category": "travel_rule",
    "amount": 3100,
    "currency": "ETH",
    "currency_kind": "crypto",
    "direction": "OUTBOUND",
    "txn_date": "2026-05-21T13:40:00Z",
    "subject": { "vendor_data": "user_5567", "role": "ORIGINATOR", "entity_type": "INDIVIDUAL" },
    "counterparty": { "role": "BENEFICIARY", "entity_type": "INDIVIDUAL", "wallet_address": "0x4c1a...77fe" }
  }'

{
  "transaction_id": "txn_a17d63",
  "status": "IN_REVIEW",
  "travel_rule_status": "PENDING_COUNTERPARTY",
  "protocol": "OpenVASP",
  "wallet_screening": { "risk_score": 22, "risk_level": "LOW" }
}

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

كيف تدفع الحالات حلقة المعالجة

غالبًا ما تعني حالة PENDING_ACTION أن على العميل تقديم شيء ما - تأكيد مستفيد، أو تقديم تفاصيل المنشئ. وهنا تنطبق حلقة المعالجة AWAITING_USER التي يستخدمها بقية نظام مراقبة المعامالت مباشرة: بدلاً من الحظر الصارم، تتوقف المعاملة مؤقتًا، ويُطلب من المستخدم ما هو مفقود، وتستأنف تلقائيًا بمجرد إزالته. لا يحدث الاحتكاك إلا في التحويلات التي تحتاجه بالفعل، ويسجل الجدول الزمني للحالة كل خطوة لمسار التدقيق.

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

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

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

1. قم بتشغيل قواعد قاعدة السفر في وحدة التحكم التجارية جنبًا إلى جنب مع مراقبة العملات المشفرة وفحصها، واكتب سياستك بشأن "شروق الشمس" كقواعد ضد الحالات.
2. أرسل تحويلات العملات المشفرة باستخدام POST /v3/transactions/، currency_kind: "crypto"، والأطراف المنشئة/المستفيدة.
3. تفرّع على travel_rule_status — تابع في حالة COMPLIANT/EXEMPT، عالج في حالة PENDING_ACTION، احتفظ في حالة PENDING_COUNTERPARTY، تحقق في حالة FAILED.
4. تعامل مع الاستثناءات في وحدة التحكم، حيث يعيش الجدول الزمني للحالة وسير عمل الحالة مع بقية مراقبتك.

يعمل كل ذلك على واجهة برمجة التطبيقات الموحدة /v3/، لذا ترتبط الحالة في التحويل بنفس الهوية التي قمت بتسجيلها باستخدام KYC وفحصتها باستخدام AML.

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

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

UNKNOWN، COMPLIANT، PENDING_ACTION، PENDING_COUNTERPARTY، FAILED، و EXEMPT. كل travel_rule_status للتحويل هو واحد منها بالضبط.

ما هي مسألة شروق الشمس؟

التبني العالمي غير المتكافئ لقاعدة السفر - بعض الولايات القضائية تفرضها، والبعض الآخر لم يتبنها بعد. هذا يجعلك تتبادل البيانات مع أطراف مقابلة قد لا يكون لديها التزام بالمعاملة بالمثل.

كيف يتعامل Didit مع الأطراف المقابلة غير المتبنية؟

تظهر على أنها PENDING_COUNTERPARTY ثم FAILED بدلاً من فجوات صامتة. تحدد سياستك ما إذا كنت ستتابع أو تحتفظ أو تحظر - ويتم تسجيل القرار لمسار التدقيق.

ما الفرق بين PENDING_ACTION و PENDING_COUNTERPARTY؟

PENDING_ACTION يعني أن الكرة في ملعبك (بيانات مفقودة أو تأكيد). PENDING_COUNTERPARTY يعني أنك تنتظر مزود خدمة الأصول الافتراضية الآخر.

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

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

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

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