> ## Documentation Index
> Fetch the complete documentation index at: https://docs.didit.me/llms.txt
> Use this file to discover all available pages before exploring further.

# إعدادات مراقبة المعاملات: الحدود وتهيئة المزوّد

> هيّئ حدود درجات KYT والعملة ومزوّدي تحليلات البلوكتشين والمعالجة في Didit. الخطط تشمل 1,000 معاملة شهرياً، ثم $0.001 لكل معاملة.

قم بتهيئة إعدادات مراقبة المعاملات على مستوى التطبيق من Business Console للتحكم في حدود الدرجات وتفضيلات المزوّدين.

## الإعدادات العامة

| الإعداد | الافتراضي | الوصف |
| - | - | - |
| **تم تفعيل المراقبة** | `true` | فعّل مراقبة المعاملات للتطبيق أو عطّلها. عند التعطيل، تُخزَّن المعاملات المُرسلة دون تقييمها وفق القواعد. |
| **العملة الافتراضية** | `USD` | العملة المستخدمة في مقارنات حدود القواعد وفي تحويل العملات. تُحوَّل جميع المبالغ إلى هذه العملة لضمان تقييم متسق. |

## حدود الدرجات

تحدد حدود الدرجات الكيفية التي تُربط بها درجة المخاطر التراكمية من [القواعد المطابقة](https://docs.didit.me/ar/transaction-monitoring/rules.md) بحالة المعاملة:

| الإعداد | الافتراضي | الوصف |
| - | - | - |
| **حد المراجعة** | 75 | المعاملات التي تبلغ درجتها هذه القيمة أو تتجاوزها تحصل على الحالة `IN_REVIEW` |
| **حد الرفض** | 500 | المعاملات التي تبلغ درجتها هذه القيمة أو تتجاوزها تحصل على الحالة `DECLINED`. القيمة الافتراضية والقيمة القصوى (`500`) لا ترفض المعاملة تلقائياً بناءً على الدرجة، لذا خفّضها إذا أردت الرفض بناءً على الدرجة. |

المعاملات التي تقل درجتها عن حد المراجعة تحصل تلقائياً على الحالة `APPROVED`. إذا كان لدى قاعدة إجراء صريح `change_status`، فإن تلك الحالة تتقدم على حدود الدرجات، و`DECLINED` تغلب دائماً.

> [!NOTE]
>
> خفض حد المراجعة يزيد عدد المعاملات المُعلَّمة لمراجعة المحللين. اضبطه بحسب طاقة فريقك ومستوى تحمّل المخاطر لديك.

## مراقبة العملات المشفرة

فعّل فحص [العملات المشفرة](https://docs.didit.me/ar/transaction-monitoring/aml-screening.md) التلقائي أو عطّله لمعاملات العملات المشفرة. عند التفعيل، يفحص Didit عناوين المحافظ وتجزئات المعاملات لدى مزودي تحليلات البلوكتشين لجميع المعاملات التي تحمل `currency_kind: "crypto"`. يتطلب فحص تجزئة المعاملة توفر التجزئة وعنوان المحفظة المرتبط بها معاً.

## تفضيلات المزوّد

اختر مزوّد تحليلات البلوكتشين المفضل لديك وهيّئه:

| المزوّد | التهيئة |
| - | - |
| **Merkle Science** | فعّله مع الأسعار المُدارة (وهو الخيار الافتراضي) أو اربط مفتاح API الخاص بك |
| **Crystal** | اربط مفتاح API الخاص بك من **Marketplace** في وحدة التحكم |
| **Chainalysis** | اربط مفتاح API الخاص بك من **Marketplace** في وحدة التحكم |
| **Elliptic** | اربط مفتاح API والسر الخاصين بك من **Marketplace** في وحدة التحكم |
| **TRM Labs** | اربط مفتاح API الخاص بك من **Marketplace** في وحدة التحكم |

عند ربط مفتاح المزوّد الخاص بك، تستخدم اتفاقيتك القائمة مع المزوّد، وتدفع رسوم البنية التحتية المعروضة لكل فحص عبر Didit.

تتوفر مراقبة شبكة Lightning فقط مع اتصال BYOK من Elliptic أو Chainalysis المُضاف عبر **Marketplace**.
إذا أُرسل `LIGHTNING` بينما مزوّد آخر نشط، أو قبل إضافة أيٍّ من الاتصالين المدعومين، يعيد طلب الفحص الاستجابة `400` مع إرشادات الإعداد في Marketplace.

## سير عمل المعالجة

**سير عمل المعالجة** (`remediation_workflow_id` في واجهة API للإعدادات) هو الإعداد الافتراضي على مستوى التطبيق لإجراءات [`AWAITING_USER`](https://docs.didit.me/ar/transaction-monitoring/rules#طلب-التحقق-من-المستخدم-awaiting_user) في القواعد التي لا تحدد سير عملها الخاص، وينطبق ذلك عملياً على القواعد المدمجة في المكتبة. القواعد المخصصة تحمل دائماً اختيارها الخاص، وهذا الاختيار يتقدم.
يقبل الحقل معرّف سير العمل (أو معرّف UUID لإصدار محدد) عند الكتابة، ويعيد دائماً معرّف سير العمل الثابت عند القراءة. تُنشأ الجلسات بأحدث إصدار منشور.
عندما تضع هذه القاعدة المعاملة في الحالة `AWAITING_USER`، ينشئ Didit جلسة التحقق المرتبطة باستخدام أول سير عمل يُعثر عليه وفق الترتيب التالي:

1. سير عمل المعالجة المُهيأ هنا.
2. سير عمل **المصادقة البيومترية** في تطبيقك، عندما يكون لدى الشخص وجه مرجعي مخزّن.
3. سير العمل الافتراضي لتطبيقك.

يُعاد عنوان URL الخاص بالجلسة ورمزها في الحقلين `action_required` و`remediation` في المعاملة، وفي كلا webhook الخاصين بالمعاملات، بحيث يمكنك توجيه المستخدم لإكمال التحقق المطلوب. عندما تصل الجلسة إلى قرار، تتبع حالة المعاملة هذا القرار تلقائياً (مقبولة أو مرفوضة أو قيد المراجعة) ويُطلق حدث `transaction.status.updated` عبر webhook.

يُعد سير عمل **المصادقة البيومترية** الخيار الموصى به هنا: يعيد المستخدم إثبات هويته بصورة سيلفي حية واحدة تُطابَق مع الوجه من تسجيله الأصلي. يتطلب ذلك أن يكون لدى الشخص وجه مرجعي مخزّن من عملية تحقق مقبولة. المستخدمون الذين لا يملكون ذلك يُطلب منهم إكمال سير العمل الافتراضي لتطبيقك بدلاً من ذلك، مع ملاحظة على المعاملة تسجّل هذا الاستبدال.

## مكان الإعداد

انتقل إلى **المعاملات** > **الإعدادات** في [Business Console](https://business.didit.me) لتهيئة هذه الخيارات. تسري الإعدادات فوراً على جميع المعاملات الجديدة.

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

> [card] [تقييم المخاطر](https://docs.didit.me/ar/transaction-monitoring/risk-scoring.md)
>
> كيف تُربط حدود الدرجات بالحالات.

> [card] [فحص العملات المشفرة](https://docs.didit.me/ar/transaction-monitoring/aml-screening.md)
>
> فحص المحافظ وتفاصيل المزوّدين.

> [card] [إثراء IP](https://docs.didit.me/ar/transaction-monitoring/ip-enrichment.md)
>
> بيانات IP المتاحة للقواعد.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.