قواعد مراقبة المعاملات: السرعة والشروط

تُقيَّم كل معاملة تُرسل إلى Didit مقابل جميع القواعد النشطة في تطبيقك. تحدد القواعد الشروط وفحوصات وتيرة المعاملات والإجراءات التي تحدد الحالة النهائية للمعاملة ودرجتها. يبدأ هذا الفصل من درس محرك قواعد الاحتيال في Didit Academy عند إنشاء قاعدة. يُنشئ درس محرك القواعد في Academy قاعدة أمام الكاميرا عند الدقيقة 7:54: المُشغِّل والشروط والإجراءات واحتساب الدرجات، ثم الاختبار الرجعي قبل النشر.

​

حزم القواعد المدمجة

توفر Didit مكتبة قواعد مُعدّة مسبقًا تغطي الأنماط التنظيمية الشائعة. ثبّت الإعدادات المسبقة (أو الحزم بأكملها) التي تريدها من المكتبة: في وحدة التحكم، أو عبر واجهة التثبيت البرمجية، أو بأدوات MCP، واضبط وضع كل إعداد مسبق مثبّت. للاطلاع على الكتالوج الكامل لكل قاعدة مُعدّة مسبقًا مع الحدود والإجراءات، انظر مكتبة القواعد.

​

مصادر القواعد

لكل قاعدة source يحدد من يديرها:

​

تركيب القاعدة

تتكون كل قاعدة مما يلي:

​

الإجراءات

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

​

طلب التحقق من المستخدم (AWAITING_USER)

لا يقتصر إجراء تغيير الحالة → AWAITING_USER على تعيين الحالة فقط، بل تُنشئ Didit تلقائياً جلسة تحقق مستضافة للشخص المعني بالمعاملة (بنفس vendor_data) في اللحظة التي تُشغَّل فيها القاعدة. تُعاد الجلسة في الكتلة action_required الخاصة بالمعاملة (وفي الكائن remediation) في استجابة الإنشاء وفي كل قراءة لاحقة، وفي كلتا رسالتي webhook الخاصتين بالمعاملة، لذا يمكنك توجيه المستخدم فوراً. راجع الإجراءات المطلوبة من المستخدم. يجب أن تحدد القواعد المخصصة سير العمل في الإجراء نفسه (workflow_id)، إذ يتطلب ذلك كل من منشئ القواعد في وحدة التحكم وواجهة برمجة القواعد. أما القواعد الجاهزة من المكتبة فلا تتضمن سير عمل، ولذلك يُحدَّد سير عمل الجلسة وفق الترتيب التالي:

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

وهذا يعني أن قواعد AWAITING_USER الجاهزة تنتج دائماً جلسة قابلة للتنفيذ من دون أي إعداد إضافي: خطوة مصادقة بيومترية للمستخدمين الذين تحققت منهم سابقاً، أو تحقق كامل في الحالات الأخرى. تُستثنى معاملات Travel Rule من هذا البديل التلقائي، فانتظار AWAITING_USER فيها مخصص لإثبات ملكية المحفظة، وله تدفقه الخاص. إن الخيار الأقوى للمعاملات عالية المخاطر هو سير عمل المصادقة البيومترية. فبما أن الشخص المعني هو المستخدم الذي خضع سابقاً لإجراءات KYC، تعيد Didit استخدام الوجه المرجعي المُتحقَّق منه من عملية التسجيل (صورة السيلفي المقبولة لكشف الحيوية، أو صورة شريحة جواز السفر، أو صورة المستند الشخصية)، فيكفي أن يلتقط المستخدم صورة سيلفي حية واحدة، وتُجري Didit كشف الحيوية ومطابقة وجه واحد لواحد مع الهوية التي فُتح بها الحساب. تفشل جميعها عند هذه البوابة: بيانات الاعتماد المسروقة، ورموز OTP التي جرى الحصول عليها بالتصيد، وعمليات تبديل شرائح SIM. للاطلاع على الشرح الكامل، راجع المصادقة البيومترية المعززة لعملية سحب بقيمة عالية. عندما تصل الجلسة إلى قرار، تتبع المعاملة هذا القرار تلقائياً، ويُطلق webhook الخاص بـ transaction.status.updated. تُقبل المعاملة عند قبول الجلسة (decision_reason_code: user_action_approved)، وتُرفض عند رفض الجلسة (user_action_declined)، وتُرسَل إلى IN_REVIEW عندما تنتهي الجلسة بحاجة إلى مراجعة (user_action_in_review). تبقى المعاملة في AWAITING_USER إذا انتهت صلاحية الجلسة أو تُركت دون إكمال.

​

الدرجات

عندما تطابق المعاملة قاعدة واحدة أو أكثر، تُجمع الدرجات:

1. تساهم كل مطابقة للقاعدة في درجة المخاطر الإجمالية للمعاملة عبر الإجراء add_score.
2. تحدد الدرجة النهائية حالة المعاملة استناداً إلى حدود الدرجات في تطبيقك.
3. إذا احتوت أي قاعدة على الإجراء change_status، فإن هذه الحالة تُطبَّق مباشرةً، وتكون الحالة DECLINED لها الأولوية دائماً.

حدود الدرجات الافتراضية (قابلة للتعديل في وحدة التحكم):

​

إنشاء قواعد مخصصة

يمكن إنشاء القواعد المخصصة من وحدة تحكم الأعمال (Business Console) أو عبر Management API، وهي متاحة أيضًا من Didit MCP وأي مساعد ذكي متصل بـ MCP. تسري القواعد في وضع Active فورًا على جميع المعاملات الجديدة. عناوين القواعد فريدة لكل تطبيق.

​

الاختبار الرجعي

قبل تفعيل القاعدة، يمكنك التحقق منها باستخدام البيانات التاريخية:

• اضبط القاعدة على وضع الاختبار: تُقيَّم القاعدة على كل معاملة جديدة، لكن نتائجها لا تؤثر في حالة المعاملة أو درجتها. تتراكم إحصاءات التنفيذ (عدد المطابقات والكيانات المتأثرة) حتى تتمكن من تقييم الأثر قبل التشغيل الفعلي.
• استخدم ميزة الاختبار الرجعي من وحدة التحكم، أو عبر POST /v3/transactions/rules/backtest/، لتقييم شروط القاعدة وتجميعها بأثر رجعي على المعاملات خلال فترة زمنية محددة. يعيد الاختبار الرجعي عدد المعاملات التي جرى تقييمها وعدد المعاملات المطابقة والكيانات المتأثرة، دون تعديل أي بيانات تاريخية. أرسل الحقول conditions وaggregation وevaluation_mode و scope نفسها الموجودة في القاعدة التي تنوي تفعيلها: فإذا أُغفل النطاق فلن يكون هناك أي قيد، وسيحسب الاختبار الرجعي المعاملات التي تتخطاها القاعدة المحفوظة.

​

نوافذ السرعة (التجميع)

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

• نافذة زمنية: <N>m (دقائق)، أو <N>h (ساعات)، أو <N>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.

​

أمثلة على الأنماط

​

كتالوج الحقول

تشير الشروط وفلاتر التجميع إلى حقول المعاملة عبر مسارها:

​

عوامل مقارنة الشروط

تدعم القواعد عوامل المقارنة التالية في الشروط: تحتاج كل عوامل التشغيل الأخرى إلى قيمة value غير فارغة، وتُرجع واجهة API استجابة 400 عند غيابها. تقبل contains وnot_contains وregex نصًا واحدًا فقط، وليس قائمة أو كائنًا؛ أما contains_any فتقبل قائمة من النصوص.

​

أنواع قيم الشروط

تغيّر الخاصية الاختيارية value_type في الشرط طريقة تفسير value:

​

الشروط المجمّعة

تُجمع قائمة الشروط المسطحة وفق 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/ على المعاملة ضمن custom_values، ويمكن استخدامه في الشروط بمسار الحقل custom_values.<key>. فمثلًا، معاملة تُرسل مع "custom_properties": {"channel": "mobile_app"} تطابق الشرط custom_values.channel eq "mobile_app". تعمل جميع العوامل أعلاه مع الخصائص المخصصة، ويمكن مقارنتها بحقول أخرى أو استخدامها في مرشحات معدل التكرار. في منشئ القواعد في Console، تظهر المفاتيح التي رُصدت في المعاملات المستلمة مؤخرًا تلقائيًا في محدد حقول الشرط ضمن الخصائص المخصصة. ويمكنك أيضًا الإشارة إلى مفتاح قبل أن تحمله أي معاملة: اختر أدخل خاصية مخصصة في المجموعة نفسها، واكتب المفتاح تمامًا كما يرسله التكامل لديك (المفاتيح حساسة لحالة الأحرف). تُقيَّم القاعدة على أنها غير متطابقة ببساطة إلى أن تصل المعاملات التي تحمل ذلك المفتاح.

​

الرفض التلقائي عبر قائمة الحظر

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

• تُضبط حالة المعاملة على DECLINED
• يُضبط سبب القرار على blocklisted
• يُنشأ سجل نشاط لأغراض تتبع التدقيق

​

فحص المعاملات

يتكامل Didit مع مزودي تحليلات AML وتحليلات البلوكتشين الخارجيين لإثراء المعاملات بمعلومات المخاطر. عند إرسال معاملة، يمكن للنظام:

• فحص الأطراف المقابلة مقابل قواعد بيانات العقوبات وقوائم المراقبة العالمية
• تقييم عناوين المحافظ (للمعاملات المشفرة) مقابل بيانات استخبارات البلوكتشين، بما في ذلك التعرض للخلاطات، والارتباط بكيانات خاضعة للعقوبات، والتفاعل مع الخدمات عالية المخاطر
• التحقق من حالة AML لمقدم الطلب بمقارنة المستخدم المرتبط بالمعاملة مع أحدث نتائج فحص AML لديه

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

​

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