كشف الاحتيال بالهويات المُصطنعة لحظة تقديم الطلب

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

هذا التأطير الجديد يغيّر ما تبنيه. التحقق من المستندات والبحث في قواعد البيانات يجيبان عن سؤال: هل البيانات صحيحة؟ أما كشف الهوية المصطنعة فعليه أن يجيب عن سؤال أصعب: هل يقف خلف هذا الطلب إنسان حقيقي واحد، وهل كان موجودًا بشكل متماسك لمدة أطول مما احتاجته عصابة الاحتيال؟ معظم الإشارة تكمن في هذا السؤال الثاني، ولا شيء منها تقريبًا يكمن في حقول الاستمارة.

لماذا تنجح القطع ولا ينجح الشخص

المنطق الاقتصادي بسيط. تُنمّي العصابة هوية مصطنعة لأشهر، وأحيانًا لسنوات. تفتح بطاقة مضمونة صغيرة، وتسدّد الدفعات، ويُبلَّغ عنها لمكاتب الائتمان، وتترك ملفًا رقيقًا لكن نظيفًا يتراكم. وبحلول وقت التقدّم لائتمان حقيقي، تبدو الهوية كعميل شاب منخفض المخاطر بتاريخ قصير. ثم تنفجر العصابة: تستنزف كل خط ائتماني لدى عدة جهات مُقرِضة خلال نافذة زمنية ضيّقة ثم تختفي. لا يتصل أي ضحية للاعتراض على شيء، ولهذا تُقرأ الخسارة على أنها احتيال طرف أول (first-party fraud) وكثيرًا ما تُصنَّف خطأً كخسارة ائتمانية عادية.

الدلائل بنيوية، وتجدها بالنظر عبر الطلبات لا داخل طلب واحد.

• سمات مشتركة بين أشخاص يُفترض أنهم منفصلون. رقم هاتف واحد، أو جهاز واحد، أو حساب مصرفي واحد مرتبط بهويات كثيرة. عنوان واحد يربط عنقودًا من الملفات الرقيقة فُتحت جميعها خلال أسابيع من بعضها.
• تاريخ يبدأ بشكل مفاجئ أكثر من اللازم. ملف ائتماني ذو أثر استفسارات جادّة (hard inquiries) لكن بلا ما قبله: لا أثر قديم لفواتير مرافق، ولا خط زمني للعناوين، ولا سجل توظيف يسبق أول بند في الملف.
• عدم تطابق في المعرّفات ينجح كل منها منفردًا. اسم ورقم هوية وطنية يُتحقَّق منهما كلٌّ على حدة، لكن تواريخ الإصدار والعمر والخط الزمني للعناوين لا تتلاءم معًا لتكوّن حياة واحدة معقولة.
• سرعة (velocity) لا يُنتجها متقدّم حقيقي. الهوية نفسها، أو تباديل طفيفة منها، تظهر عبر قمعك (funnel) وعبر بيانات الاتحاد (consortium data) خلال نافذة زمنية مضغوطة.

لا واحدة من هذه الإشارات حاسمة بمفردها. فالشخص الحقيقي قد ينتقل من منزله، ويبدّل هاتفه، ويحمل ملفًا رقيقًا. مهمة النموذج هي أن يوازن المجموعة مقابل ميزانية الإيجابيات الكاذبة (false-positive budget)، لأن كل هوية مصطنعة تُشير إليها تجلس بجوار متقدّم حقيقي ذي ملف رقيق كنت تفضّل الموافقة عليه.

طبقة البيانات التي يحتاجها هذا فعلاً

النموذج هو الجزء السهل. الجزء الصعب هو تجميع سمات تكون صحيحة لحظة اتخاذ القرار وتصف الهوية عبر دفترك كله، لا عبر استمارة واحدة. مشكلتان تهيمنان.

الأولى: تحليل الكيانات وربطها (entity resolution). لا يمكنك حساب كم هوية تشترك في جهاز واحد إن لم تستطع أن تحسم متى يكون صفّان لنفس الجهاز أو العنوان أو الحساب المصرفي. تبني عمليات التطبيع (normalisation) والمطابقة التقريبية (fuzzy matching) الرسمَ البياني المستقر للهوية الذي يقبع تحت كل سمة سرعة وسمة مشتركة. وحين يكون هذا الرسم ضعيفًا، تتحوّل أفضل إشاراتك إلى ضجيج. إنها المشكلة ذاتها في ربط الكيانات التي تظهر عبر تدفقات البيانات المالية، موجَّهة هذه المرة نحو المتقدّمين.

الثانية: صحة النقطة الزمنية (point-in-time correctness). تصل تسميات الاحتيال متأخرة. لا يُؤكَّد أن حسابًا ما مصطنع إلا بعد الانفجار (bust-out)، أحيانًا بعد ستة أشهر من فتح الحساب. وإذا دربت على سمات محسوبة اليوم وربطتها بطلب من الربيع الماضي، فأنت تسرّب معلومات المستقبل إلى الماضي. يجب إعادة بناء الرسم البياني الذي تستعلم عنه كما كان في لحظة ذلك القرار. تحتاج كل سمة في المخزن إلى ختم زمني «حتى تاريخه» (as-of timestamp)، ويجب أن يقرأ كل صف تدريبي الرسم البياني عند وقت طلبه هو. تجاهل ذلك، وستبدو مساحة AUC غير المباشرة (offline) ممتازة بينما لا يضبط نموذجك في الإنتاج شيئًا، لأنه كان يقرأ بهدوء صحيفة الغد.

بضعة مبادئ نتمسّك بها عند بناء خط المعالجة (pipeline):

• تتبّع النسب (lineage) لكل سمة، بحيث يمكن تفسير أي قرار سلبي وإعادة بناء أثره الرقابي. رفض الاحتيال يظل خاضعًا لتدقيق الإقراض العادل (fair lending)؛ فقرار الإجراء السلبي (adverse action) الذي لا تستطيع تفسيره هو قرار لا تستطيع الدفاع عنه بموجب قانون تكافؤ فرص الائتمان (ECOA) واللائحة B (Regulation B).
• سياسة تسميات صادقة. ميّز بين الهوية المصطنعة المؤكدة، وانفجار الطرف الأول المؤكد (first-party bust-out)، والشطب الائتماني العادي (charge-off). إن جمعتها معًا فأنت تدرّب النموذج على التنبؤ بمخاطر الائتمان بدل الاحتيال.
• مجموعات تقييم مبنيّة حول نافذة الانفجار، لا حول تقسيم عشوائي. التقسيم الزمني الذي يحجب أحدث الأفواج هو الاختبار الوحيد الذي يشبه الإنتاج.

التقييم لحظة الحجز، والمراقبة بعده

ينتهي بك الأمر بتشغيل نموذجين على مشكلة واحدة. يجلس نموذج التقييم لحظة تقديم الطلب داخل المعالجة الآلية المباشرة (straight-through processing) ويعمل تحت ميزانية زمن استجابة (latency) صارمة؛ وهو يعتمد على سمات الرسم البياني والسرعة الرخيصة الخدمة، إضافة إلى إشارات تاريخ الملف الرقيق (thin file) من مكتب الائتمان. يُحدَّد هدف دقّته بعدد المراجعات اليدوية التي يستطيع فريقك استيعابها، ولذلك تكون العتبة قرارًا تجاريًا بقدر ما هي قرار إحصائي.

أما النموذج الثاني فيراقب الحسابات المفتوحة بحثًا عن نمط الانفجار (bust-out): طفرات استخدام منسّقة، وسلوك سداد يتغيّر بالتزامن عبر عنقود من السمات المشتركة، وتعثّر في أول دفعة (first-payment default) متجمّع حسب الجهاز أو العنوان. هنا تُضبط الهويات المصطنعة التي عبرت من الباب الأمامي قبل أن تقع الخسارة. كما يولّد هذا النموذج التسميات التي تجعل نموذج الحجز أفضل في الربع المقبل، ولهذا يجب أن يتشاركا مخزن السمات (feature store) وطبقة الربط بدل أن يعيشا في مكدّسين منفصلين.

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