سماح، مراجعة، حظر: قرارات احتيال بلا صندوق أسود

تصل التذكرة إلى الدعم أولًا: عملية سحب معلّقة، وعميل يريد معرفة السبب. إذا أعادت واجهة الاحتيال الرقم 0.81 فقط، فلديك رقم لا يستطيع أحد شرحه في مكالمة أو شكوى أو تدقيق.

النتائج المفيدة ثلاث: ALLOW وREVIEW وBLOCK. وتعمل درجات المخاطر مع القواعد لترتيب الحالات دون أن تحل محل السياسة.

ضع السياسة في النتيجة

تعني ALLOW أن الحدث اجتاز القواعد والعتبات المحددة، فيواصل المنتج الإجراء دون ملاحظة حالة.

توجّه REVIEW الإشارات التي تحتاج إلى تحقق إضافي أو مراجعة بشرية، مثل جهاز جديد على حساب قليل النشاط أو نشاط قريب من العتبة أو تطابق محتمل مع قائمة.

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

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

لماذا تفشل درجات الصندوق الأسود في العمليات

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

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

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

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

اختبر القاعدة قبل تفعيلها

لا تشغّل BLOCK في اليوم الأول لقاعدة جديدة. شغّلها في وضع المراقبة، أو أعد REVIEW أولًا، ثم فعّلها. وهو النهج نفسه في وضع المراقبة مقابل التطبيق الفعلي في تجارب AML: راقب الحجم والتنبيهات الخاطئة، ثم غيّر تجربة العميل.

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

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

يجب أن تظهر النتائج الثلاث نفسها في المنتج ونظام الحالات ومراجعة المخاطر الأسبوعية. وإذا كانت الهندسة تتحدث بلغة الدرجات وفريق العمليات بلغة التعليق، فستقضي الحادثة التالية في التوفيق بين اللغتين. اربط ALLOW بإكمال الإجراء، وREVIEW بخطوة تحقق أو قائمة المراجعة، وBLOCK بالإيقاف التام، واكتب هذا الربط قبل أول حدث إنتاجي.

النتيجة هي السياسة، وكل ما عداها أدلة تدعمها.