> ## 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. # قواعد مراقبة المعاملات: السرعة والشروط > هيّئ قواعد مراقبة المعاملات في Didit بالشروط ونوافذ السرعة والإجراءات الآلية، من حزم جاهزة أو مخصصة. 1,000 شهرياً مجاناً، ثم $0.001 لكل استدعاء. تُقيَّم كل معاملة تُرسل إلى Didit مقابل جميع القواعد النشطة في تطبيقك. تحدد القواعد الشروط وفحوصات وتيرة المعاملات والإجراءات التي تحدد الحالة النهائية للمعاملة ودرجتها. يبدأ هذا الفصل من درس محرك قواعد الاحتيال في Didit Academy عند إنشاء قاعدة. يُنشئ درس محرك القواعد في Academy قاعدة أمام الكاميرا عند الدقيقة 7:54: المُشغِّل والشروط والإجراءات واحتساب الدرجات، ثم الاختبار الرجعي قبل النشر. [إنشاء قاعدة – Didit Academy](https://www.youtube.com/embed/Yhm63_n7HuU?start=474\&rel=0\&playsinline=1) > [!NOTE] > > يمكن إدارة القواعد من **وحدة تحكم الأعمال** ومن **Management API** ومن **Didit MCP**. استخدم وحدة التحكم عندما ينبغي لأحد أفراد فريق الامتثال لديك مراجعة كل تغيير؛ واستخدم الواجهة البرمجية أو MCP عندما تُنشأ القواعد وتُضبط برمجيًا، مثلًا عند نقل مجموعة قواعد من مزوّد آخر. راجع [مرجع API](https://docs.didit.me/ar/management-api/transactions/rules-list.md) و[دليل إدارة القواعد عبر API وMCP](https://docs.didit.me/ar/transaction-monitoring/rules-api.md). تُطبَّق القواعد على كل معاملة تُرسل عبر [`POST /v3/transactions/`](https://docs.didit.me/ar/management-api/transactions/create)، وتظهر النتيجة في المصفوفة `rule_runs[]` الخاصة بالمعاملة (انظر [مخطط الاستجابة](https://docs.didit.me/ar/transaction-monitoring/response-schema.md)). ## حزم القواعد المدمجة توفر Didit مكتبة قواعد مُعدّة مسبقًا تغطي الأنماط التنظيمية الشائعة. ثبّت الإعدادات المسبقة (أو الحزم بأكملها) التي تريدها من المكتبة: في وحدة التحكم، أو عبر [واجهة التثبيت البرمجية](https://docs.didit.me/ar/management-api/transactions/rules-install.md)، أو بأدوات MCP، واضبط وضع كل إعداد مسبق مثبّت. للاطلاع على الكتالوج الكامل لكل قاعدة مُعدّة مسبقًا مع الحدود والإجراءات، انظر [مكتبة القواعد](https://docs.didit.me/ar/transaction-monitoring/rules-library.md). | الحزمة | أمثلة | | - | - | | **مالية** | اكتشاف التجزئة (الوارد/الصادر)، والمعاملات الفردية الكبيرة التي تتجاوز حدود الإبلاغ | | **AML/CTF** | حدود الحجم التراكمي، وحركة سريعة للدخول والخروج، ومطابقة الطرف المقابل مع قوائم العقوبات، والكلمات المفتاحية المشبوهة في مرجع الدفع | | **اكتشاف الحالات الشاذة** | السرعة العالية للوارد والصادر، وإعادة تنشيط حساب خامل بعد 12+ شهرًا من عدم النشاط | | **FATF** | التعرض لولايات قضائية عالية المخاطر لدى الأطراف المقابلة وعناوين IP للأشخاص المعنيين | | **ذكاء الأجهزة** | تكرار استخدام حملة المكافآت من بصمة الجهاز نفسها، وبصمات أجهزة متعددة للشخص نفسه | | **منع الاحتيال** | تعدد الحسابات عبر بصمات أجهزة مشتركة بين أشخاص مختلفين | | **مراقبة العملات المشفّرة** | التعرض لخدمات الخلط أو الإخفاء، وعناوين محافظ عالية المخاطر (الويب المظلم، والخاضعة للعقوبات، والأموال المسروقة) | | **فحص العملات المشفّرة** | التعرض لمصدر الأموال عالي المخاطر (أكثر من 30%)، وأطراف مقابلة عدة ذات مخاطر، والرفض التلقائي لتمويل الإرهاب واستغلال الأطفال، وتعليق بانتظار الفحص، ووضع علامة على درجة مخاطر المحفظة المتوسطة | | **الألعاب المسؤولة** | موجات إيداع سريعة ضمن نوافذ زمنية قصيرة | | **التجارة الإلكترونية** | أنماط معاملات خاصة بالتجارة الإلكترونية | ## مصادر القواعد لكل قاعدة `source` يحدد من يديرها: | المصدر | الوصف | | - | - | | **Preset** | قواعد مثبّتة من المكتبة المدمجة في Didit. أنت تختار الإعدادات المسبقة (أو الحزم بأكملها) التي تثبّتها، وتتحكم في وضع كل إعداد مسبق مثبّت (`Active` و`Test` و`Disabled`). شروطها وعتباتها ثابتة، ويمكنك تجاوز إحداها عبر إنشاء قاعدة مخصصة، وتُزال بإلغاء التثبيت لا بالحذف. | | **Custom** | قواعد ينشئها فريقك من وحدة تحكم الأعمال. لديك تحكم كامل في القواعد المخصصة: إنشاؤها وتعديلها وحذفها حسب الحاجة. | ## تركيب القاعدة تتكون كل قاعدة مما يلي: | المكوّن | الوصف | | - | - | | **العنوان والوصف** | اسم واضح ومفهوم وشرح لما ترصده القاعدة | | **الفئة** | تجميع منطقي (على سبيل المثال `finance` و`aml_ctf` و`crypto_monitoring` و`device_intelligence`) | | **الوضع** | `Active` (التقييم المباشر)، أو `Disabled` (يتم تخطيها)، أو `Test` (تُقيَّم لكن نتائجها لا تؤثر في المعاملة) | | **وضع التقييم** | `All` (يجب أن تتطابق كل الشروط)، أو `Any` (يجب أن يتطابق شرط واحد على الأقل) | | **النطاق** | يحدد المعاملات التي تنطبق عليها القاعدة. المفاتيح: `transaction_types` و`directions` (`INBOUND`/`OUTBOUND`) و`action_types`. كونها فارغة أو غيابها يعني عدم وجود أي قيود | | **الشروط** | فحوصات على مستوى الحقول: تقارن حقول المعاملة بقيم باستخدام عوامل مثل `eq` و`lt` و`gte` و`in` و`contains_any` و`exists` | | **التجميع** | نوافذ وتيرة المعاملات: تجمع المعاملات السابقة خلال فترة زمنية (مثلًا العدد أو المجموع أو عدد القيم المميزة خلال ساعة واحدة أو 7 أيام أو 30 يومًا) | | **الإجراءات** | ما يحدث عند تطابق القاعدة (انظر أدناه) | ## الإجراءات عند مطابقة قاعدة لمعاملة، يتم تنفيذ إجراء واحد أو أكثر. يمكن أن تحتوي كل قاعدة على عدة إجراءات تُطبَّق معاً: | الإجراء | `type` | المفاتيح | الوصف | | - | - | - | - | | **إضافة نقاط** | `add_score` | `value` (عدد صحيح، ويمكن أن يكون سالباً) | إضافة نقاط إلى درجة المخاطر للمعاملة. يحدد مجموع النقاط عبر جميع القواعد المطابقة ما إذا كانت المعاملة تتجاوز حد المراجعة أو حد الرفض. | | **تغيير الحالة** | `change_status` | `value` (`APPROVED`\|`IN_REVIEW`\|`DECLINED`\|`AWAITING_USER`، والاسم البديل `status`)، `workflow_id` (والاسم البديل `remediation_workflow_id`) | تعيين حالة المعاملة مباشرةً بغض النظر عن الدرجة. `workflow_id` مطلوب عندما تكون `value` بقيمة `AWAITING_USER`، إذ يؤدي حذفه إلى إرجاع `400`. | | **إضافة علامات** | `add_tags` | إما `tag_uuid` أو `tag_name` (واحد منهما)، `tag_color` | وسم المعاملة لتصنيفها وتصفيتها. يُستخدم `tag_uuid` لوسم موجود، أو `tag_name` ينشأ عند أول استخدام (ويُخزَّن بالأحرف الكبيرة). يحدد `tag_color` اللون السداسي عشري للوسم الذي يُنشأ حديثاً. | | **إضافة ملاحظة** | `add_note` | `note` (والاسم البديل `value`) | إرفاق ملاحظة نصية آلية بالمعاملة لتزويد المحلل بالسياق. | | **إضافة إلى قائمة** | `add_to_list` | `list_id` | إضافة `vendor_data` الخاصة بالشخص المعني إلى قائمة حظر أو قائمة سماح أو قائمة مخصصة. | | **فتح حالة** | `open_case` | `blueprint` (معرّف UUID لنموذج الحالة، اختياري)، `grouping` (`by_applicant`\|`by_rule_and_applicant`)، `attach_matched_transaction` (قيمة منطقية) | فتح حالة تحقيق (أو الإضافة إلى حالة قائمة). لا يُطبَّق إلا أول إجراء `open_case` في القاعدة. | تجمع معظم القواعد الجاهزة بين **إضافة نقاط** و**تغيير الحالة**. فعلى سبيل المثال، تضيف قاعدة الطرف المقابل الخاضع للعقوبات 90 نقطة إلى الدرجة **و**ترفض المعاملة فوراً. ### طلب التحقق من المستخدم (`AWAITING_USER`) لا يقتصر إجراء **تغيير الحالة → `AWAITING_USER`** على تعيين الحالة فقط، بل تُنشئ Didit تلقائياً جلسة تحقق مستضافة للشخص المعني بالمعاملة (بنفس `vendor_data`) في اللحظة التي تُشغَّل فيها القاعدة. تُعاد الجلسة في الكتلة `action_required` الخاصة بالمعاملة (وفي الكائن `remediation`) في استجابة الإنشاء وفي كل قراءة لاحقة، وفي كلتا رسالتي webhook الخاصتين بالمعاملة، لذا يمكنك توجيه المستخدم فوراً. راجع [الإجراءات المطلوبة من المستخدم](https://docs.didit.me/ar/transaction-monitoring/sdk-transaction-submission.md#الإجراءات-المطلوبة-من-المستخدم). يجب أن تحدد القواعد المخصصة سير العمل في الإجراء نفسه (`workflow_id`)، إذ يتطلب ذلك كل من منشئ القواعد في وحدة التحكم وواجهة برمجة القواعد. أما القواعد الجاهزة من المكتبة فلا تتضمن سير عمل، ولذلك يُحدَّد سير عمل الجلسة وفق الترتيب التالي: 1. **سير عمل المعالجة** المُعدّ في [إعدادات المعاملات](https://docs.didit.me/ar/transaction-monitoring/settings.md#سير-عمل-المعالجة) الخاصة بك. 2. سير عمل **المصادقة البيومترية** في تطبيقك، عندما يكون لدى الشخص المعني وجه مرجعي مخزّن من عملية تحقق مقبولة. 3. سير العمل الافتراضي في تطبيقك. وهذا يعني أن قواعد `AWAITING_USER` الجاهزة تنتج دائماً جلسة قابلة للتنفيذ من دون أي إعداد إضافي: خطوة مصادقة بيومترية للمستخدمين الذين تحققت منهم سابقاً، أو تحقق كامل في الحالات الأخرى. تُستثنى معاملات Travel Rule من هذا البديل التلقائي، فانتظار `AWAITING_USER` فيها مخصص لإثبات ملكية المحفظة، وله [تدفقه الخاص](https://docs.didit.me/ar/transaction-monitoring/wallet-ownership-widget.md). إن الخيار الأقوى للمعاملات عالية المخاطر هو سير عمل **المصادقة البيومترية**. فبما أن الشخص المعني هو المستخدم الذي خضع سابقاً لإجراءات KYC، تعيد Didit استخدام الوجه المرجعي المُتحقَّق منه من عملية التسجيل (صورة السيلفي المقبولة لكشف الحيوية، أو صورة شريحة جواز السفر، أو صورة المستند الشخصية)، فيكفي أن يلتقط المستخدم صورة سيلفي حية واحدة، وتُجري Didit كشف الحيوية ومطابقة وجه واحد لواحد مع الهوية التي فُتح بها الحساب. تفشل جميعها عند هذه البوابة: بيانات الاعتماد المسروقة، ورموز OTP التي جرى الحصول عليها بالتصيد، وعمليات تبديل شرائح SIM. للاطلاع على الشرح الكامل، راجع [المصادقة البيومترية المعززة لعملية سحب بقيمة عالية](https://docs.didit.me/ar/transaction-monitoring/sdk-transaction-submission.md#مثال-التحقق-البيومتري-الإضافي-لسحب-عالي-القيمة). عندما تصل الجلسة إلى قرار، تتبع المعاملة هذا القرار تلقائياً، ويُطلق webhook الخاص بـ `transaction.status.updated`. تُقبل المعاملة عند قبول الجلسة (`decision_reason_code: user_action_approved`)، وتُرفض عند رفض الجلسة (`user_action_declined`)، وتُرسَل إلى `IN_REVIEW` عندما تنتهي الجلسة بحاجة إلى مراجعة (`user_action_in_review`). تبقى المعاملة في `AWAITING_USER` إذا انتهت صلاحية الجلسة أو تُركت دون إكمال. > [!NOTE] > > يمكن استخدام أي نوع من سير العمل ما عدا KYB كإجراء معالجة. > تتطلب أنواع سير العمل الخاصة بالمصادقة البيومترية (وسير العمل الذي تُجرى فيه مطابقة الوجه قبل التحقق من الهوية) وجهاً مرجعياً مخزّناً للشخص المعني: صورة سيلفي مقبولة لكشف الحيوية، أو صورة شريحة جواز السفر، أو صورة المستند الشخصية، أو وجه مُسجَّل يدوياً في الملف الشخصي. > إذا لم يوجد أي وجه مرجعي، يُطلب من المستخدم إكمال سير العمل الافتراضي في تطبيقك بدلاً من ذلك، وهو ما يسجّل وجهه أيضاً لاستخدامه في المرات القادمة، وتسجّل ملاحظة على المعاملة هذا الاستبدال. > لا يتم تخطي الجلسة إلا إذا لم يوجد أي سير عمل افتراضي مناسب، وعندها تُسجَّل ملاحظة توضح السبب. ## الدرجات عندما تطابق المعاملة قاعدة واحدة أو أكثر، تُجمع الدرجات: 1. تساهم كل مطابقة للقاعدة في **درجة المخاطر** الإجمالية للمعاملة عبر الإجراء `add_score`. 2. تحدد الدرجة النهائية حالة المعاملة استناداً إلى **حدود الدرجات** في تطبيقك. 3. إذا احتوت أي قاعدة على الإجراء `change_status`، فإن هذه الحالة تُطبَّق مباشرةً، وتكون الحالة `DECLINED` لها الأولوية دائماً. حدود الدرجات الافتراضية (قابلة للتعديل في وحدة التحكم): | الإعداد | القيمة الافتراضية | الوصف | | - | - | - | | **حد المراجعة** | 75 | الدرجات المساوية لهذه القيمة أو الأعلى منها تُفعّل الحالة `IN_REVIEW` | | **حد الرفض** | 500 | الدرجات المساوية لهذه القيمة أو الأعلى منها تُفعّل الحالة `DECLINED`. القيمة الافتراضية (`500`) لا ترفض المعاملة استناداً إلى الدرجة أبداً | ## إنشاء قواعد مخصصة يمكن إنشاء القواعد المخصصة من **وحدة تحكم الأعمال** (Business Console) أو عبر **Management API**، وهي متاحة أيضًا من [Didit MCP](https://docs.didit.me/ar/integration/mcp/tools.md) وأي مساعد ذكي متصل بـ MCP. > [tab] وحدة التحكم > > 1. انتقل إلى **المعاملات** > **القواعد** في وحدة التحكم > 2. انقر على **Create Rule** > 3. حدّد عنوان القاعدة ووصفها وفئتها > 4. اضبط **الوضع** (mode): `Active` لتشغيلها مباشرة، أو `Test` لتقييمها دون التأثير على المعاملات > 5. اختر **وضع التقييم** (evaluation mode): `All` (يجب أن تتطابق كل الشروط) أو `Any` (يكفي تطابق شرط واحد على الأقل) > 6. حدّد **النطاق** (scope): أنواع المعاملات أو اتجاهاتها التي تنطبق عليها القاعدة > 7. أضف **الشروط** (conditions): مقارنات الحقول، مثل حدود المبلغ ورموز الدول وفحوصات الخصائص المخصصة > 8. أضف **التجميع** (aggregation) اختياريًا: فحوصات السرعة عبر نافذة زمنية (العدد، والمجموع، وعدد القيم المميزة، والمزيد) > 9. حدّد إجراءً واحدًا أو أكثر: إضافة درجة، أو تغيير الحالة، أو إضافة وسوم، أو إضافة ملاحظات، أو الإضافة إلى قائمة، أو فتح حالة > 10. احفظ القاعدة وفعّلها > [tab] API > > استدعِ [`POST /v3/transactions/rules/`](https://docs.didit.me/ar/management-api/transactions/rules-create) مع الحقول نفسها: `title` و`category` و`mode` و`evaluation_mode` و`scope` و`conditions` و`aggregation` و`actions`. يوجد المرجع الكامل للحقول وعوامل التشغيل والإجراءات في هذه الصفحة، ويشرح [إدارة القواعد عبر API وMCP](https://docs.didit.me/ar/transaction-monitoring/rules-api.md) سير العمل الموصى به: الإنشاء ثم الاختبار الرجعي ثم التفعيل، بما في ذلك نقل مجموعة قواعد من ملف CSV مُصدَّر من مزود آخر. تسري القواعد في وضع `Active` فورًا على جميع المعاملات الجديدة. عناوين القواعد فريدة لكل تطبيق. ## الاختبار الرجعي قبل تفعيل القاعدة، يمكنك التحقق منها باستخدام البيانات التاريخية: * اضبط القاعدة على وضع **الاختبار**: تُقيَّم القاعدة على كل معاملة جديدة، لكن نتائجها لا تؤثر في حالة المعاملة أو درجتها. تتراكم إحصاءات التنفيذ (عدد المطابقات والكيانات المتأثرة) حتى تتمكن من تقييم الأثر قبل التشغيل الفعلي. * استخدم ميزة **الاختبار الرجعي** من وحدة التحكم، أو عبر [`POST /v3/transactions/rules/backtest/`](https://docs.didit.me/ar/management-api/transactions/rules-backtest)، لتقييم شروط القاعدة وتجميعها بأثر رجعي على المعاملات خلال فترة زمنية محددة. يعيد الاختبار الرجعي عدد المعاملات التي جرى تقييمها وعدد المعاملات المطابقة والكيانات المتأثرة، دون تعديل أي بيانات تاريخية. أرسل الحقول `conditions` و`aggregation` و`evaluation_mode` **و** `scope` نفسها الموجودة في القاعدة التي تنوي تفعيلها: فإذا أُغفل النطاق فلن يكون هناك أي قيد، وسيحسب الاختبار الرجعي المعاملات التي تتخطاها القاعدة المحفوظة. ## نوافذ السرعة (التجميع) تجمّع قواعد السرعة بيانات المعاملات التاريخية على مدى فترة زمنية، لاكتشاف أنماط لا تكشفها الفحوصات القائمة على معاملة واحدة: | المقياس | الوصف | | - | - | | `count` | عدد المعاملات المطابقة لعوامل التصفية داخل النافذة | | `sum` | مجموع حقل رقمي `field` (مثل `preferred_currency_amount`) داخل النافذة | | `max` / `min` / `avg` | أكبر قيمة أو أصغرها أو متوسطها لحقل رقمي `field` داخل النافذة | | `distinct_count` | عدد القيم الفريدة للحقل `field` (مثل بصمات الأجهزة المختلفة) داخل النافذة (`unique_count` اسم بديل مقبول) | يحدد كل تجميع ما يلي: * **نافذة زمنية**: `m` (دقائق)، أو `h` (ساعات)، أو `d` (أيام)، مثل `30m` و`6h` و`7d` و`30d`. تنبيه: `m` تعني **دقائق**، وليس أشهرًا. * **عوامل التصفية** لتضييق المعاملات التاريخية المُدرجة. مفاتيحها هي مسارات الحقول من [كتالوج الحقول](#كتالوج-الحقول)، والقيمة الخاصة `"__current__"` تُحل إلى قيمة الحقل نفسه في المعاملة الجاري تقييمها (مثلًا `"subject_vendor_data": "__current__"` يحصر النافذة في الجهة نفسها). وتعني قيمة القائمة المطابقة لأي عنصر فيها. لا تُقارن عوامل التصفية إلا بالمساواة أو العضوية **فقط**، فلا يوجد عامل `lt` أو `gte` للتصفية، لذلك لا يمكن التعبير عن نطاق مثل *المعاملات التي تقل عن 10,000* عبر عوامل التصفية. ضع النطاق على المقياس بدلًا من ذلك (`max` أقل من 10,000، أو `min` أكبر من 1,000)، وتذكّر أن الشرط يقيّد المعاملة الجاري تقييمها، وليس النافذة. * **عامل تشغيل وحدّ**: `eq` و`ne` و`gt` و`gte` و`lt` و`lte` مقابل `value`، مثل العدد >= 20. ### أمثلة على الأنماط | النمط | آلية العمل | | - | - | | **الهيكلة** | عدد المعاملات للجهة نفسها خلال 30 يومًا >= 20، مع أن يكون أكبر مبلغ `max` أقل من \$10,000 ضمن النافذة نفسها | | **السرعة العالية** | عدد المعاملات الواردة للجهة نفسها خلال 7 أيام >= 20 | | **الدخول والخروج السريعان** | المعاملة الجارية صادرة + عدد المعاملات الواردة للجهة نفسها خلال 6 ساعات >= 1 | | **تعدد الحسابات** | عدد القيم المميزة للجهات التي تشارك بصمة الجهاز نفسها خلال 7 أيام >= 3 | | **إعادة تنشيط الجهة غير النشطة** | عدد الأيام منذ المعاملة السابقة للجهة >= 365، مع أن يكون المبلغ >= \$1,000 | ## كتالوج الحقول تشير الشروط وفلاتر التجميع إلى حقول المعاملة عبر مسارها: | الحقل | الوصف | | - | - | | `amount`, `currency` | مبلغ المعاملة ورمز عملتها | | `preferred_currency_amount`, `default_currency_code` | المبلغ محوّلاً إلى العملة المفضلة لتطبيقك (ويعود إلى `amount_in_default_currency` عند عدم توفرها) | | `direction` | `INBOUND` أو `OUTBOUND` | | `action_type` | نوع الإجراء لديك، مثل `withdrawal` أو `deposit` أو `bet` | | `transaction_type` | `finance` أو `kyc` أو `travelRule` أو `userPlatformEvent` | | `payment_details` | مرجع الدفع كنص حر (الهدف الذي تُطبَّق عليه `contains_any` في قواعد الكلمات المفتاحية) | | `score`, `severity` | درجة المخاطر الحالية للمعاملة ومستوى خطورتها | | `subject_vendor_data`, `counterparty_vendor_data` | المعرفات التي تستخدمها لكل من الطرفين | | `subject_country`, `counterparty_country` | رموز دول الطرفين (تُقبل صيغتا ISO-2 وISO-3، وتُوحَّد قبل المقارنة) | | `subject_device_fingerprint`, `counterparty_device_fingerprint` | بصمة الجهاز أو معرّف الجهاز الدائم | | `subject_browser_family`, `subject_browser_version`, `subject_platform`, `subject_accept_language`, `subject_session_age_ms` | تفاصيل سياق الجهاز (الحقل `counterparty_browser_family` متاح أيضاً) | | `subject_ip_address`, `subject_ip_country`, `counterparty_ip_address`, `counterparty_ip_country` | سياق الشبكة | | `subject_payment_method_type`, `subject_payment_method_country`, `subject_payment_method_fingerprint`, `subject_payment_method_account_id` | وسيلة الدفع من جهة الطرف الأول (توجد الحقول الأربعة نفسها بالبادئة `counterparty_payment_method_*`) | | `travel_rule_status`, `travel_rule_required`, `travel_rule_obligations_count` | حالة فحص Travel Rule | | `counterparty_dd_status`, `counterparty_risk_level`, `counterparty_jurisdiction`, `counterparty_responsiveness` | ما تعرفه عن الـVASP الطرف المقابل الذي وصل إليه تبادل Travel Rule: قرارك بشأنه (`APPROVED` أو `RESTRICTED` أو `BLOCKED`)، ومستوى مخاطره (`LOW` أو `MEDIUM` أو `HIGH`؛ ويكون `HIGH` طالما فحص الطرف المقابل لديك عليه علامة تنبيه)، ودولته، ومدى استجابته (`RESPONSIVE` أو `UNRESPONSIVE` أو `UNKNOWN`). انظر [العناية الواجبة بالطرف المقابل في Travel Rule](https://docs.didit.me/ar/transaction-monitoring/travel-rule.md#حقول-القواعد-والإعدادات-المسبقة) | | `subject_days_since_previous_transaction` | عدد الأيام منذ المعاملة السابقة لهذا الطرف من النوع نفسه (قواعد الخمول) | | `tags` | أسماء الوسوم المرتبطة بالمعاملة | | `custom_values.` | أي مفتاح أرسلته في `custom_properties` عند إنشاء المعاملة | ## عوامل مقارنة الشروط تدعم القواعد عوامل المقارنة التالية في الشروط: | العامل | الوصف | مثال | | - | - | - | | `eq` / `ne` | يساوي / لا يساوي | `direction eq "OUTBOUND"` | | `gt` / `gte` / `lt` / `lte` | مقارنات رقمية وتاريخية؛ لا تتطابق أبدًا عندما يكون أحد الطرفين مفقودًا | `preferred_currency_amount gte 25000` | | `in` / `not_in` | العضوية في قائمة (تُقبل أيضًا قيمة مفردة واحدة) | `counterparty_country in ["IRN", "PRK", "SYR"]` | | `contains` / `not_contains` | جزء من نص داخل قيمة نصية، دون التمييز بين الأحرف الكبيرة والصغيرة | `payment_details contains "refund"` | | `contains_any` | أي عنصر من قائمة نصوص يظهر كجزء من الحقل، دون التمييز بين الأحرف الكبيرة والصغيرة | `payment_details contains_any ["terror", "weapon"]` | | `regex` | نمط القيمة يطابق الحقل | `subject_vendor_data regex "^guest-"` | | `fuzzy_match` | تشابه نصي تقريبي؛ يتطلب حدّ `score` من 0 إلى 100 في الشرط | `counterparty_name fuzzy_match "Acme Corp"` مع `score: 85` | | `exists` / `is_not_empty` / `is_not_null` | الحقل موجود (أسماء بديلة؛ تُتجاهل القيمة `value`) | `subject_device_fingerprint exists` | | `not_exists` / `is_empty` / `is_null` | الحقل غير موجود أو فارغ (أسماء بديلة؛ تُتجاهل القيمة `value`) | `subject_ip_address is_empty` | تحتاج كل عوامل التشغيل الأخرى إلى قيمة `value` غير فارغة، وتُرجع واجهة API استجابة `400` عند غيابها. تقبل `contains` و`not_contains` و`regex` نصًا واحدًا فقط، وليس قائمة أو كائنًا؛ أما `contains_any` فتقبل قائمة من النصوص. ### أنواع قيم الشروط تغيّر الخاصية الاختيارية `value_type` في الشرط طريقة تفسير `value`: | `value_type` | المعنى | | - | - | | `list` | `value` هي معرّف UUID لقائمة؛ تصبح إدخالات قائمة الحظر أو السماح أو القائمة المخصصة قيمة المقارنة، فيمكن للقاعدة أن تطابق "الطرف المقابل الموجود في قائمة المراقبة المخصصة الخاصة بي". | | `field` | `value` هي مسار حقل آخر؛ يقارن الشرط بين حقلين في المعاملة، مثل `subject_payment_method_account_id ne counterparty_payment_method_account_id`. | | `relative_date` | `value` تاريخ نسبي، مثل `{"direction": "past", "unit": "days", "amount": 30}`، وذلك لحقول التاريخ مثل `txn_date`. | ### الشروط المجمّعة تُجمع قائمة الشروط المسطحة وفق `evaluation_mode` الخاص بالقاعدة (`ALL`/`ANY`). وللمنطق المختلط، أعطِ الشروط `group_index`: الشروط التي تشترك في الفهرس نفسه تكوّن مجموعة، و`group_logic` (`AND`/`OR`، والافتراضي `AND`) يجمع الشروط داخل المجموعة، و`groups_logic` في الشرط الأول (`AND`/`OR`، والافتراضي `OR`) يجمع نتائج المجموعات. عندما يحمل أي شرط `group_index`، يحل التقييم المجمّع محل `evaluation_mode`. ### الإشارة إلى الخصائص المخصصة يُخزَّن كل مفتاح يُرسل في الكائن `custom_properties` في [`POST /v3/transactions/`](https://docs.didit.me/ar/transaction-monitoring/transactions) على المعاملة ضمن `custom_values`، ويمكن استخدامه في الشروط بمسار الحقل `custom_values.`. فمثلًا، معاملة تُرسل مع `"custom_properties": {"channel": "mobile_app"}` تطابق الشرط `custom_values.channel eq "mobile_app"`. تعمل جميع العوامل أعلاه مع الخصائص المخصصة، ويمكن مقارنتها بحقول أخرى أو استخدامها في مرشحات معدل التكرار. في منشئ القواعد في Console، تظهر المفاتيح التي رُصدت في المعاملات المستلمة مؤخرًا تلقائيًا في محدد حقول الشرط ضمن **الخصائص المخصصة**. ويمكنك أيضًا الإشارة إلى مفتاح قبل أن تحمله أي معاملة: اختر **أدخل خاصية مخصصة** في المجموعة نفسها، واكتب المفتاح تمامًا كما يرسله التكامل لديك (المفاتيح حساسة لحالة الأحرف). تُقيَّم القاعدة على أنها غير متطابقة ببساطة إلى أن تصل المعاملات التي تحمل ذلك المفتاح. ## الرفض التلقائي عبر قائمة الحظر قبل تقييم أي قاعدة، يتحقق Didit من كيانات المعاملة مقابل قوائم الحظر الخاصة بتطبيقك. إذا عُثر على **أي** تطابق، تُرفض المعاملة **فورًا**، ولا تُقيَّم القواعد. تُفحص الكيانات التالية: | الكيان | نوع قائمة الحظر | ما الذي يُفحص | | - | - | - | | **المستخدم (مقدم الطلب)** | قائمة حظر المستخدمين | معرّف `vendor_data` الخاص بمقدم الطلب | | **الشركة** | قائمة حظر الشركات | معرّف `vendor_data` الخاص بالشركة | | **عنوان المحفظة** | قائمة حظر عناوين المحافظ | `account_id` لطرق دفع المحافظ الرقمية للعملات المشفرة | | **الحساب المصرفي** | قائمة حظر الحسابات المصرفية | `account_id` لطرق دفع التحويلات المصرفية | | **عنوان IP** | قائمة حظر عناوين IP | عنوان IP من سياق جهاز الطرف (تدعم نطاقات CIDR) | | **بصمة الجهاز** | قائمة حظر بصمات الأجهزة | بصمة الجهاز أو معرّف الجهاز الدائم | عند حدوث تطابق في قائمة الحظر: * تُضبط حالة المعاملة على `DECLINED` * يُضبط سبب القرار على `blocklisted` * يُنشأ سجل نشاط لأغراض تتبع التدقيق > [!NOTE] > > تُجرى فحوصات قوائم الحظر قبل تقييم القواعد. ستُرفض دائمًا أي كيان مدرج في قائمة الحظر، بصرف النظر عن إعداد القواعد أو حدود الدرجات. ## فحص المعاملات يتكامل Didit مع مزودي تحليلات AML وتحليلات البلوكتشين الخارجيين لإثراء المعاملات بمعلومات المخاطر. عند إرسال معاملة، يمكن للنظام: * **فحص الأطراف المقابلة** مقابل قواعد بيانات العقوبات وقوائم المراقبة العالمية * **تقييم عناوين المحافظ** (للمعاملات المشفرة) مقابل بيانات استخبارات البلوكتشين، بما في ذلك التعرض للخلاطات، والارتباط بكيانات خاضعة للعقوبات، والتفاعل مع الخدمات عالية المخاطر * **التحقق من حالة AML لمقدم الطلب** بمقارنة المستخدم المرتبط بالمعاملة مع أحدث نتائج فحص AML لديه تُرفق نتائج الفحص بالمعاملة، وتدخل في احتساب الدرجات في محرك القواعد. وإذا تطابق طرف مقابل أو محفظة مع قائمة العقوبات، تقوم القاعدة المقابلة تلقائيًا بوضع علامة على المعاملة أو رفضها. ## الخطوات التالية > [card] [إرسال المعاملات](https://docs.didit.me/ar/transaction-monitoring/transactions.md) > > كيفية تنظيم المعاملات لتقييمها وفق القواعد. > [card] [فحص العملات الرقمية](https://docs.didit.me/ar/transaction-monitoring/aml-screening.md) > > نتائج فحص العملات الرقمية وكيفية استخدام القواعد المحددة مسبقاً لها. > [card] [الإعدادات](https://docs.didit.me/ar/transaction-monitoring/settings.md) > > اضبط حدود الدرجات وسير عمل المعالجة. > [card] [مرجع API](https://docs.didit.me/ar/management-api/transactions/create.md) > > endpoint لإنشاء المعاملة في API. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.