الانتقال إلى المحتوى الرئيسي

متى تستخدمه

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

المتطلبات الأساسية

يجب إعداد مراقبة المعاملات للتطبيق مع إما مزوّد مُدار أو مفتاح مزوّد موجود. اضبط ذلك في المعاملات > الإعدادات > Provider Preferences في Business Console. إذا لم يكن هناك مزوّد مُعدّ، تُرجع نقطة النهاية 409 Conflict.

الطلب

POST https://verification.didit.me/v3/wallet-screening/ قم بالمصادقة باستخدام الرأس x-api-key.

تغطية الشبكات

يدعم الفحص المُدار شبكات Base (BASE) وOptimism (OP) وArbitrum One (ARB) لفحص المحفظة ولفحص تجزئة المعاملة على حد سواء. قد تختلف تغطية المزوّدين المتصلين؛ ويجب أن يدعم مزوّدك المختار وحسابك الشبكة أيضًا. تُفحص شبكات Celo (CELO) وMode (MODE) وPlume (PLUME) عبر حساب TRM Labs متصل (Marketplace، باستخدام مفتاحك الخاص)؛ لا يغطيها الفحص المُدار، وتُرجع 400. لا ترسل ETH لشبكة EVM أخرى: قد يكون للعنوان نفسه نشاط ومخاطر مختلفة على كل شبكة. مع الفحص المُدار، يُعد USDT وUSDC اسمين بديلين قديمين لـ Ethereum، وليسا بحثًا عبر كل الشبكات التي توجد فيها هذه الرموز. استخدم معرّف الشبكة (ETH أو TRX أو SOL أو MATIC أو BNB أو BASE أو OP أو ARB أو AVAX أو ADA أو XLM أو HBAR، أو مع TRM Labs ‏CELO أو MODE أو PLUME) للشبكة الفعلية للمحفظة. بالنسبة إلى الرموز في المعاملات المسجلة، أبقِ الرمز في transaction_details.currency وحدد الشبكة بشكل منفصل في transaction_details.crypto_params.crypto_chain. راجع اختيار الأصل والشبكة.
LIGHTNING متاح فقط عندما يكون لدى التطبيق مزوّد BYOK متصل من Elliptic أو Chainalysis في Marketplace داخل وحدة التحكم. ولا يتوفر مع Merkle Science المُدار، ولا مع Crystal أو TRM Labs. الطلبات التي لا يوجد فيها مزوّد متصل مدعوم تُرجع 400 ولا تُفحص ولا يُحتسب عليها رسوم.

الاستجابة

الاستجابة هي نتيجة الفحص الموحّدة، وشكلها مطابق لنتيجة المزوّد WALLET_SCREENING التي يُرجعها فحص المعاملات.
كيف يتم تحديد severity. يُحدَّد severity وفق نطاق risk_score الموحّد: 0-9 → UNKNOWN، و10-39 → LOW، و40-69 → MEDIUM، و70-89 → HIGH، و90-100 → CRITICAL. الفئة UNKNOWN هي أدنى نطاق، وليست حالة منفصلة تعني “لا توجد بيانات”: القيمة risk_score: 0 (وهي الحالة الشائعة للعنوان النظيف) تعني أن المزوّد لم يُرجع أي تقييم سلبي، بينما تمثل القيمة غير الصفرية ضمن النطاق 1-9 إشارة حقيقية لكنها أدنى من LOW. لذلك اقرأ risk_score نفسه، لا الفئة وحدها. وفي كل الأحوال، لا تعرض UNKNOWN على أنها نتيجة “خالية من المخاطر” أو “ناجحة”.لا يغيّر direction نموذج المخاطر. يُمرَّر الحقل الاختياري direction إلى المزوّد كسياق فقط. ولا يؤثر في risk_score أو severity أو في قوائم التفصيل المُرجَعة: تُرجَع القائمتان source_of_funds وdestination_of_funds دائماً بغض النظر عن ذلك. لذلك لا يستلزم تغيير direction أو حذفه إعادة فحص عنوان سبق فحصه.

عوامل المخاطر

يمثل risk_factors الإجابة المرتّبة عن سؤال “لماذا حصل هذا العنوان على هذه الدرجة”. يقيّم المزوّدون العنوان وفق نموذجهم الخاص، ويُرجعون حكماً فقط: تُرجع Merkle Science عدداً صحيحاً من 0-5، لذلك لا يكفي risk_score وحده لاتخاذ إجراء. يسمّي كل عنصر عاملاً واحداً مؤثراً، ويُرتَّب من عالي الخطورة إلى منخفضها، ثم حسب القيمة التي مرّت عبره.
الدرجة المرتفعة دون أي عامل is_high_risk نتيجة حقيقية ومهمة. فهي تعني أن المزوّد قيّم العنوان وفق نموذج التعرّض الخاص به دون أن يُبلغ عن تطابق مع العقوبات أو الشخص المعرّض سياسياً أو كيان منسوب، والعوامل المدرجة هي تدفقات الأموال التي تقف وراء هذه الدرجة. يوضح summary ذلك صراحةً، لذا تعامل مع هذه العناوين على أنها “راجع التدفقات”، لا على أنها تطابق مؤكد. يُقتصر risk_factors على أقوى خمسة عوامل مؤثرة، بينما تتضمن source_of_funds وdestination_of_funds التفصيل الكامل دائماً.risk_factors حقل على المستوى الأعلى، وليس حقلًا متداخلًا. النتائج التي فُحصت قبل وجود هذا الحقل لا تتضمن المفتاح إطلاقًا، لذا اقرأه على أنه قائمة فارغة بدلًا من افتراض أن التفسير فارغ.

تفصيل التعرّض

يصف كل إدخال في source_of_funds / destination_of_funds كيانًا واحدًا تبادل العنوان معه الأموال:

روابط الأطراف المقابلة

يسرد counterparty_connections الكيانات التي ينسب المزوّد إليها العنوان المفحوص. مع Merkle Science تأتي هذه الكيانات من وسوم المالك والمستخدم الخاصة بالعنوان نفسه، لذلك قد يظهر الكيان نفسه مرتين، ولا تتضمن تدفقات أموال: تكون received_usd وsent_usd وreceived_hops وsent_hops كلها null، وتكون percentage بقيمة 0.0. اقرأ تدفقات الأموال من source_of_funds وdestination_of_funds.
لا تعتمد على counterparty_connections[].risk_level أو counterparty_connections[].is_direct في التوجيه: مع Merkle Science، الحقل الأول يكرر تصنيف المخاطر الخاص بالعنوان (اقرأ risk_score)، والحقل الثاني قيمته دائمًا true. استخدم sanctions_hit وdominant_risk_category وrisk_factors[].is_high_risk للحكم، واستخدم exposure_type في source_of_funds / destination_of_funds لمعرفة ما إذا كان التعرّض مباشرًا.

مثال

الاستجابة الفعلية لعنوان مدرج في قائمة عقوبات OFAC، فُحص باستخدام Merkle Science. اختُصر raw_response فقط، واستُبدل report_signature:
توضح الأمثلة بنية الاستجابة، ولا تمثل حكمًا مضمونًا لعنوان حقيقي. تعتمد درجات المخاطر والتعرّض للعقوبات على الشبكة المختارة والمعلومات الاستخبارية الحالية وسياسة المخاطر المُعدّة. لا يعني إسناد منصة تبادل أن درجة المخاطر صفر: فقد تتعرّض محفظة منصة التبادل للعقوبات عبر تدفقات أموالها. قد يدل sanctions_hit: true على أن المحفظة نفسها خاضعة للعقوبات، أو فقط على أن أموالها تعرّضت للعقوبات، لذلك لا يعني وحده أن مالك المحفظة المفحوصة خاضع للعقوبات. عند تشغيل الفحص نفسه على معاملة مسجّلة، يمكن للقواعد أيضًا قراءة custom_values.wallet_sanctioned، وتكون قيمته true فقط عندما ينسب المزوّد المحفظة نفسها إلى كيان خاضع للعقوبات، وكذلك custom_values.aml_sanctions_exposure_pct. راجع حقول الفحص للقواعد. اقرأ risk_factors وsource_of_funds وdestination_of_funds للتمييز بين الإسناد والتعرّض. راجع فحص العملات المشفّرة والمحافظ للاطلاع على شرح خطوة بخطوة.

تقرير PDF

للحصول على تقرير PDF بعلامة Didit التجارية لنتيجة فحص، أعد إرسال نص الاستجابة كما هو تمامًا، بما فيه report_signature، إلى POST /v3/wallet-screening/pdf/. هذه العملية عديمة الحالة: لا يوجد استدعاء للمزوّد، ولا فوترة إضافية، ولا يُحفظ أي شيء. أي تعديل على حقل موقّع (risk_score وseverity وsanctions_hit وغيرها) قبل إعادة الإرسال يؤدي إلى 400.
راجع فحص المحفظة وتقرير PDF للاطلاع على المخطط الكامل للطلب والاستجابة وأشكال الأخطاء.

الفوترة

يُحتسب استخدام واحد لمراقبة AML مقابل كل فحص ناجح، وبالسعر نفسه المطبّق على فحص الكريبتو المرتبط بالمعاملات. راجع الأسعار لمعرفة أسعار المفاتيح المُدارة والمفاتيح المرتبطة. لا تُحتسب رسوم على التطبيقات في البيئة التجريبية. لا تُحتسب أبداً أخطاء التحقق (400) ولا أخطاء المزوّد غير المُهيَّأ (409).

الأخطاء

الخطوات التالية

مرجع API

المخطط الكامل للطلب والاستجابة لنقطة endpoint الخاصة بـ Screen Wallet.

Screen Wallet PDF

عرض نتيجة الفحص كملف PDF يحمل علامة Didit التجارية.

فحص الكريبتو والمحافظ

الفحص التلقائي أثناء إنشاء المعاملة، ونموذج النتيجة.
آخر تعديل في ٧ نوفمبر ٢٠٢٦