قواعد مراقبة أحداث يفهمها فريق الاحتيال

تبدأ قرارات الاحتيال القابلة للتفسير من الحدث الذي ترسله، لا من اللوحة التي تفتحها لاحقًا. لا يستطيع محرك القواعد إنتاج دليل مفيد إلا إذا حمل كل دخول ودفع وتسجيل وتحديث حساب معرفات ثابتة والبيانات التي تقرأها القاعدة فعلًا.

أرسل بيانات العميل والجهاز والجلسة مع كل حدث. تربط نيزا هذه المعرّفات بالقرار والقواعد المطابقة، ليجد الدعم والمحققون سبب المراجعة في السجل نفسه، وتجد الهندسة معرّف الحدث في كل تذكرة.

أرسل الحدث نفسه بالطريقة نفسها

استخدم قيم eventName ثابتة مثل user.login أو payment.completed. إذا استخدم مسار login واستخدم آخر user.login فستحتاج إلى قاعدتين للحدث نفسه. حدّد الأسماء ووثّقها وارفض البدائل.

أرسل سياق العميل والجهاز وIP والجلسة والمبلغ في أول استدعاء. لا تؤجل إثراء البيانات إلى ما بعد القرار إذا كان القرار يحتاجها الآن. يجب أن يكون customer.externalId هو المعرّف نفسه في جدول المستخدمين لديك، وأن تكون بصمة الجهاز هي المفتاح نفسه الذي ستضيفه إلى القوائم لاحقًا، وأن يكون معرّف الجلسة هو المعرّف الموجود أصلًا في تذكرة الدعم.

اجعل أسماء القواعد واضحة لأنها تظهر في سجل المراجعة: login_failures_same_fingerprint_10m يشرح النمط، أما rule_14 فلا يقول شيئًا.

احجز BLOCK للحالات عالية الثقة، واستخدم REVIEW للإشارات التي تحتاج إلى سياق بشري: جهاز جديد، أو تكرار قريب من العتبة، أو VPN على بصمة غير معروفة. يرتّب تقييم المخاطر هذه الحالات، وتحدد القواعد المسماة القرار. هذا ما يشرحه مقال سماح ومراجعة وحظر دون صندوق أسود.

{
  "eventName": "payment.completed",
  "customer": { "externalId": "user_123456" },
  "device": { "externalId": "device_abc123" },
  "ip": "203.0.113.42",
  "sessionId": "session_xyz789",
  "metadata": { "amount": 500, "currency": "SAR" }
}

يربط هذا المثال سياق العميل والجهاز والجلسة والمبلغ. يوضح دليل مراقبة الأحداث حقول الطلب وطريقة التعامل مع الرد.

اجعل القرار قابلًا للتدقيق

احفظ correlationIds.eventId بجانب معرف العملية في منتجك. هذا يعطي الدعم والمخاطر والهندسة مفتاحًا مشتركًا عندما يسأل العميل لماذا رُوجعت دفعة. ودون هذا المفتاح ستضطر إلى إعادة بناء الحدث من السجلات على أمل أن تتطابق الأوقات.

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

ابدأ القواعد الجديدة في وضع المراقبة أو REVIEW، وقِس حجم الحالات خلال أسبوع. الحملات وشبكات الجوال المشتركة وأجهزة العائلات ترفع الأرقام، فاضبط القاعدة قبل تفعيل BLOCK. ولصياغة قواعد العدّ راجع قواعد تكرار العمليات القابلة للتفسير.

حدث واحد، قرار واحد، مفتاح واحد

لا ترسل دفعة ثم تختلق حدثًا ثانيًا «حتى تنطبق القاعدة»، بل عدّل القاعدة. ولا تستخدم حدث الدخول لتغيير تفاصيل الصرف؛ فالإجراء مختلف، والمحلل يحتاج إلى أن يرى ذلك.

إذا كثرت التنبيهات في الأسبوع الأول فلا تستعجل إضافة إشارات جديدة، بل راجع الحدث الذي ترسله أصلًا. غياب customer.externalId وبصمة الجهاز ينتج قرارات أسوأ من أي إثراء تضيفه لاحقًا.

دقة نظام المراقبة من دقة بيانات الطلب. أرسل مفاتيح الربط، وسمِّ القواعد بوضوح، واحفظ معرّف الحدث، وعندها تصبح قائمة المراجعة مبنية على أدلة لا على تخمين.