لم نكن نصطاد المحتالين، بل العملاء الشرفاء: قصة بناء نظام كشف احتيال لا يغضب المستخدمين

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

أطلقنا النظام… وبعد ساعة واحدة فقط، بدأت هواتف خدمة العملاء بالرنين بشكل هستيري. “بطاقتي رُفضت!”، “لماذا لا أستطيع الدفع؟”، “نظامكم سيء!”. يا جماعة، شو القصة؟ نظرت إلى لوحة التحكم، ورأيت أن “صقرنا” الذكي لا يصطاد المحتالين، بل كان يرفض معاملات عملاء شرفاء يحاولون شراء القهوة، أو دفع فاتورة الإنترنت، أو حتى شراء هدية لزوجاتهم. في تلك اللحظة، أدركت أننا ارتكبنا خطأً فادحاً: في سعينا المحموم نحو الأمان المطلق، أعلنا الحرب على أهم أصولنا: مستخدمينا الأوفياء. كانت لحظة صعبة، لكنها كانت بداية لأهم درس تعلمته في مسيرتي المهنية.

المعضلة الأزلية: الأمان أم تجربة المستخدم؟

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

تخيل الأمر كحارس أمن على باب متجر فاخر. إذا كان الحارس متشدداً جداً ويشك في كل شخص يدخل، فسينتهي به الأمر بطرد العملاء الحقيقيين. وإذا كان متساهلاً جداً، فسيدخل اللصوص ويسرقون المتجر. التحدي هو العثور على “الحارس الذكي” الذي يعرف متى يبتسم ويرحب، ومتى يرفع حاجبيه ويطرح سؤالاً.

لماذا تفشل الأنظمة التقليدية القائمة على القواعد؟

نظامنا الأول الذي سبب لنا تلك الكارثة كان يعتمد على قواعد ثابتة (Rule-based System). هذه هي الطريقة “القديمة” لكشف الاحتيال، وهي تعمل كالتالي:

IF (مبلغ المعاملة > 1000 دولار) AND (الدولة != دولة المستخدم المعتادة) AND (الوقت بين 1-4 صباحاً)
THEN
  BLOCK TRANSACTION

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

• صلبة وغير مرنة: الحياة ليست مجموعة من قواعد IF-ELSE، وسلوك المستخدمين ديناميكي ومتغير.
• تولد الكثير من “الإيجابيات الكاذبة” (False Positives): أي أنها تمنع الكثير من المعاملات الصحيحة، وهذا ما حصل معنا بالضبط.
• سهلة التحايل: المحتالون أذكياء، وبمجرد أن يكتشفوا قواعدك، سيبدأون في إجراء معاملات بقيمة 999 دولاراً بدلاً من 1000 دولار للتحايل على النظام.

المنقذ: تعلم الآلة، الحارس الذي يتعلم

بعد فشلنا الذريع، قررنا أن الوقت قد حان للتفكير بطريقة مختلفة. هنا دخل تعلم الآلة (Machine Learning) إلى الصورة. بدلاً من أن نُملي على النظام قواعد صارمة، قررنا أن نجعله يتعلم الأنماط بنفسه من خلال البيانات التاريخية.

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

أولاً: اجمع “مكوناتك” (البيانات)

جودة النموذج تعتمد بشكل كلي على جودة وتنوع البيانات التي تغذيه بها. بعض أهم البيانات التي نظرنا إليها:

• بيانات المعاملة: المبلغ، العملة، وقت المعاملة.
• بيانات المستخدم: تاريخ المستخدم مع المنصة، متوسط قيمة معاملاته، عدد المعاملات السابقة.
• بيانات الجهاز: نوع الجهاز (موبايل/لابتوب)، عنوان IP، بصمة المتصفح (Browser Fingerprint).
• بيانات سلوكية: سرعة ملء الحقول، هل تم نسخ ولصق رقم البطاقة؟

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

ثانياً: اختر “الوصفة” المناسبة (الخوارزمية)

هناك العديد من خوارزميات تعلم الآلة التي يمكن استخدامها. بدأنا بخوارزمية بسيطة كـ Logistic Regression كخط أساس، ثم انتقلنا إلى نماذج أكثر تعقيداً مثل Random Forest و XGBoost لأنها أظهرت قدرة أفضل على التقاط العلاقات المعقدة في البيانات.

لتقريب الفكرة، هذا مثال بسيط جداً من الناحية المفاهيمية باستخدام مكتبة scikit-learn في بايثون:

# مثال توضيحي للمفهوم فقط
from sklearn.ensemble import RandomForestClassifier
from sklearn.model_selection import train_test_split

# X: هي مصفوفة تحتوي على كل ميزات المعاملة (المبلغ، وقت، تاريخ المستخدم...)
# y: هي النتيجة (0 = شرعية, 1 = احتيال)
X_train, X_test, y_train, y_test = train_test_split(X, y, test_size=0.2, stratify=y)

# نستخدم class_weight='balanced' لأن عدد المعاملات الاحتيالية عادة أقل بكثير
model = RandomForestClassifier(n_estimators=100, class_weight='balanced', n_jobs=-1)

# تدريب النموذج
model.fit(X_train, y_train)

# الآن يمكننا استخدام النموذج لتوقع درجة خطورة أي معاملة جديدة
# new_transaction = [150.5, 'USA', 'mobile', ...]
# risk_score = model.predict_proba(new_transaction)[0][1] # احتمالية كونها احتيال

السر الحقيقي: ليس مجرد “رفض” أو “قبول”

هنا كانت نقطة التحول الحقيقية في تفكيرنا. النموذج لا يعطينا قراراً بـ “نعم” أو “لا”. بل يعطينا “درجة خطورة” (Risk Score)، وهي احتمالية تتراوح بين 0% و 100% بأن تكون المعاملة احتيالية. وهذا هو السلاح السري!

بدلاً من الرفض المباشر، قمنا بتصميم ما أسميه “سلم الاحتكاك” (Friction Ladder).

سلم الاحتكاك: نهج متدرج وذكي

بناءً على درجة الخطورة، نقوم بأحد الإجراءات التالية:

1. مخاطرة منخفضة جداً (0-10%): مرر المعاملة فوراً. لا تزعج المستخدم. هذه هي غالبية المعاملات.
2. مخاطرة متوسطة (10-70%): هنا يكمن السحر. لا ترفض المعاملة! بدلاً من ذلك، أضف خطوة تحقق بسيطة. هذا ما نسميه “الاحتكاك الذكي” (Smart Friction).
   • أرسل رمزاً سرياً (OTP) إلى هاتف المستخدم المسجل.
   • اطلب منه إدخال رمز CVV الخاص بالبطاقة مرة أخرى.
   • استخدم تقنية 3D Secure.

   المستخدم الشرعي سيقوم بهذه الخطوة بسهولة وستمر معاملته، بينما المحتال الذي قد لا يملك وصولاً لهاتف الضحية سيفشل.

3. مخاطرة عالية (أعلى من 70%): هنا فقط نقوم بالرفض الصريح للمعاملة، وربما نضع علامة على الحساب لمراجعته يدوياً من قبل فريق مكافحة الاحتيال.

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

الحلقة المفرغة الإيجابية: التغذية الراجعة والتحسين المستمر

النظام لا يتوقف عن التعلم بعد إطلاقه. كل قرار يتخذه هو فرصة للتعلم.

• عندما نطلب من مستخدم التحقق بخطوة إضافية وينجح، هذه إشارة قوية أن توقعنا كان “إيجابياً كاذباً”. نقوم بتسجيل هذه المعلومة لتغذيتها للنموذج في دورة التدريب التالية.
• عندما تمر معاملة ثم يبلغ العميل لاحقاً أنها كانت احتيالية (Chargeback)، هذه “سلبية كاذبة” وهي معلومة ذهبية. نحللها ونغذيها للنموذج ليتعلم من خطئه.

هذه الدورة من العمل، القياس، والتعلم هي ما تجعل النظام “ذكياً” بحق، وتجعله يتطور ويصبح أقوى مع مرور الوقت.

الخلاصة: نصيحة من أخوكم أبو عمر

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

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

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