نظام مكافحة غسيل الأموال كان يطلق إنذارات على كل فنجان قهوة: كيف استخدمتُ نماذج الكشف عن الشذوذ (Anomaly Detection) للتركيز على المخاطر الحقيقية؟

حكاية فنجان القهوة الذي أرهق فريق الامتثال

يا جماعة الخير، السلام عليكم. معكم أخوكم أبو عمر.

قبل كم سنة، كنت أعمل كمستشار في شركة تكنولوجيا مالية (Fintech) ناشئة. كان عندهم منتج واعد، وفريق عمل “شعلة ونار”، لكنهم كانوا يواجهون مشكلة كادت أن تقضي على قسم الامتثال بالكامل. دخل عليّ ذات صباح رئيس قسم الامتثال، رجل فاضل اسمه أبو أحمد، وعلى وجهه كل علامات الإرهاق والتعب. وضع فنجان قهوته على مكتبي وقال بنبرة يائسة: “يا أبو عمر، الحقني! النظام تبعنا رح يجنّني، صاير زي الولد الصغير اللي بصيح على كل إشي. كل واحد فينا بشتري فنجان قهوة الصبح من الكافتيريا، بيوصلني إيميل إنذار بوجود نشاط مشبوه!”.

ضحكتُ وقلت له: “طوّل بالك يا أبو أحمد، خلينا نفهم شو القصة”. بعد قليل من البحث، اكتشفتُ أن نظام مكافحة غسيل الأموال (AML) عندهم كان بسيطًا جدًا، يعتمد على قواعد ثابتة (Rule-Based). إحدى هذه القواعد كانت: “أطلق إنذارًا إذا قام المستخدم بأكثر من 5 معاملات في يوم واحد”. موظف بسيط يشتري قهوة، ثم فطور، ثم يدفع لموقف السيارة، ثم يشتري علبة ماء، ثم وجبة غداء… وفجأة، يصبح “مشتبهًا به” في نظر النظام! كان فريق الامتثال يغرق يوميًا في مئات، بل آلاف الإنذارات الكاذبة، ويضيع وقته وجهده في مطاردة أشباح بينما قد تمر الذئاب الحقيقية دون أن يلاحظها أحد. هنا، أدركت أن الحل ليس في تعديل القواعد، بل في تغيير طريقة التفكير بأكملها.

لماذا تفشل الأنظمة التقليدية القائمة على القواعد (Rule-Based)؟

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

مشكلة “الإيجابيات الكاذبة” (False Positives)

كما رأينا في قصة فنجان القهوة، هذه الأنظمة تنتج كمية هائلة من الإنذارات غير الصحيحة. السبب هو أن القواعد بطبيعتها “جامدة”. قاعدة مثل “أي تحويل فوق 10,000 دولار هو مشبوه” قد تكون منطقية، لكنها تتجاهل السياق. ماذا لو كان هذا المبلغ هو دفعة إيجار سنوي لمحل تجاري؟ أو ثمن سيارة؟ النظام الغبي لا يفرق، والنتيجة هي إرهاق المحللين وتشتيت انتباههم عن الحالات التي تستحق المتابعة فعلاً.

الجمود في مواجهة التطور

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

تكلفة الصيانة العالية

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

الحل يكمن في “التفكير خارج الصندوق”: مدخل إلى كشف الشذوذ (Anomaly Detection)

بدلًا من أن نُملي على النظام قائمة طويلة من “الممنوعات”، ماذا لو علمناه ما هو السلوك “الطبيعي”، وتركناه هو يكتشف أي شيء “شاذ” أو “غريب”؟ هذا هو جوهر نماذج الكشف عن الشذوذ.

ما هو كشف الشذوذ؟

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

يعني بنعلّم النظام سلوك المستخدمين الطبيعي (الـ Baseline)، وأي إشي بصير خارج هذا النطاق، النظام لحاله بلقطه وبعطينا خبر.

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

رحلتنا العملية: بناء نظام كشف شذوذ من الصفر

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

المرحلة الأولى: فهم البيانات وجمعها (Data Gathering & Understanding)

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

  • بيانات المعاملات: المبلغ، الوقت، تاريخ، نوع المعاملة (شراء، تحويل، سحب).
  • بيانات المستخدم: تاريخ إنشاء الحساب، متوسط رصيده، عدد معاملاته التاريخية.
  • بيانات الطرف الآخر: معلومات عن المستقبِل أو المرسِل في المعاملة.
  • بيانات سلوكية: أوقات تسجيل الدخول، الأجهزة المستخدمة، الموقع الجغرافي التقريبي.

المرحلة الثانية: هندسة الميزات (Feature Engineering)

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

  • معدل تكرار المعاملات: عدد معاملات المستخدم في آخر ساعة / 24 ساعة / 7 أيام.
  • الانحراف عن المتوسط: ما مدى اختلاف مبلغ المعاملة الحالية عن متوسط مبالغ معاملات المستخدم التاريخية؟
  • معاملات خارج النمط الزمني: هل يقوم المستخدم بمعاملات في أوقات غير معتادة له (مثلاً الساعة 3 فجراً)؟
  • ميزة “الجدة”: هل هذه أول معاملة للمستخدم مع هذا التاجر أو هذا الشخص؟
  • سرعة المعاملات: الزمن بالثواني بين هذه المعاملة والمعاملة السابقة.

هذه الميزات هي التي تعطي النموذج القدرة على فهم السياق، وهو ما كانت تفتقر إليه القواعد القديمة.

المرحلة الثالثة: اختيار النموذج وتدريبه (Model Selection & Training)

هناك العديد من الخوارزميات لكشف الشذوذ. بالنسبة لمشكلتنا، قررنا البدء بنموذج بسيط وقوي جدًا يسمى Isolation Forest (غابة العزل). سبب اختياري له هو أنه فعال حسابيًا ويفسر منطقه بسهولة نسبية.

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

مثال كود بسيط باستخدام Python

لتقريب الصورة، إليك مثال بسيط جدًا يوضح كيفية استخدام `IsolationForest` من مكتبة `scikit-learn` الشهيرة:


import pandas as pd
from sklearn.ensemble import IsolationForest

# 1. بيانات مثال (معاملات عادية ومعاملة شاذة)
# معظم المعاملات بين 10 و 100، لكن هناك معاملة بقيمة 5000
data = {
    'user_id': ['A', 'A', 'B', 'A', 'C', 'B', 'A'],
    'amount': [20.5, 15.0, 90.0, 5000.0, 30.0, 100.0, 25.0],
    'tx_per_hour': [1, 2, 1, 3, 1, 2, 4] # عدد المعاملات في آخر ساعة
}
df = pd.DataFrame(data)

# 2. اختيار الميزات التي سيدخلها النموذج
features = ['amount', 'tx_per_hour']
X = df[features]

# 3. بناء وتدريب النموذج
# contamination تعني النسبة المتوقعة من البيانات الشاذة
# يمكن ضبطها بناءً على معرفتك بالبيانات
model = IsolationForest(n_estimators=100, contamination=0.1, random_state=42)
model.fit(X)

# 4. التنبؤ بالحالات الشاذة
df['anomaly_score'] = model.decision_function(X) # درجة الشذوذ
df['is_anomaly'] = model.predict(X) # التنبؤ: 1 طبيعي، -1 شاذ

# طباعة النتائج
print(df)

# النتائج ستظهر أن المعاملة بقيمة 5000 حصلت على درجة شذوذ سالبة عالية وتم تصنيفها كـ -1
#        user_id  amount  tx_per_hour  anomaly_score  is_anomaly
# 0       A    20.5            1       0.170949           1
# 1       A    15.0            2       0.113745           1
# 2       B    90.0            1       0.124513           1
# 3       A  5000.0            3      -0.191191          -1  <-- حالة شاذة!
# 4       C    30.0            1       0.181829           1
# 5       B   100.0            2       0.069113           1
# 6       A    25.0            4       0.013531           1

المرحلة الرابعة: تفسير النتائج وضبط العتبة (Threshold Tuning)

النموذج لا يعطينا “نعم” أو “لا” بشكل مباشر، بل يعطي “درجة شذوذ” (Anomaly Score). كلما كانت الدرجة أقل (أكثر سلبية)، زاد احتمال كون المعاملة شاذة. مهمتنا الآن، بالتعاون مع فريق الامتثال، هي تحديد “عتبة” (Threshold) القرار.

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

النتائج على أرض الواقع: من ضجيج الإنذارات إلى التركيز الذكي

بعد أسابيع قليلة من تطبيق النظام الجديد، كانت النتائج مذهلة:

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

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

نصائح من “أبو عمر” لرحلتك مع كشف الشذوذ

إذا كنت تفكر في تطبيق حل مشابه، اسمح لي أن أقدم لك بعض النصائح من خبرتي الشخصية:

  • ابدأ بسيطًا (Start Simple): لا تقفز مباشرة إلى نماذج الشبكات العصبية العميقة. خوارزميات مثل Isolation Forest أو Local Outlier Factor (LOF) هي نقاط بداية ممتازة وقوية.
  • هندسة الميزات هي مفتاح النجاح (Feature Engineering is Key): استثمر 80% من وقتك في فهم بياناتك وإنشاء ميزات ذكية. النموذج غبي، والميزات هي التي تجعله ذكيًا.
  • إشراك خبراء المجال (Involve Domain Experts): لا تعمل في معزل. اجلس مع فريق الامتثال، أو المالية، أو المنتج. أنا كمهندس بفهم بالكود، بس همه بفهموا بسلوك المجرمين وطبيعة العمل. هذا التعاون لا يقدر بثمن.
  • لا تثق بالنموذج ثقة عمياء (Don’t Trust the Model Blindly): النموذج هو أداة مساعدة، وليس بديلاً عن المحلل البشري. احتفظ دائمًا بعملية مراجعة بشرية (Human-in-the-loop) للتحقق من صحة قرارات النموذج.
  • المراقبة والتحسين المستمر (Monitor and Iterate): عالم الاحتيال يتغير، لذا يجب أن يتطور نموذجك معه. قم بإعادة تدريب النموذج بشكل دوري على البيانات الجديدة ليبقى فعالاً.

الخلاصة: الكود ليس سوى أداة، والفهم هو الأساس 💡

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

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

أبو عمر

سجل دخولك لعمل نقاش تفاعلي

كافة المحادثات خاصة ولا يتم عرضها على الموقع نهائياً

آراء من النقاشات

لا توجد آراء منشورة بعد. كن أول من يشارك رأيه!

آخر المدونات

التوسع والأداء العالي والأحمال

طلبات المستخدمين كانت تضيع أثناء الذروة: كيف أنقذتني طوابير الرسائل (Message Queues) من فقدان البيانات؟

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

21 مارس، 2026 قراءة المزيد
أتمتة العمليات

وظائف Cron كانت شبكة عنكبوت صامتة: كيف أنقذتني محركات تنسيق سير العمل من فوضى المهام المجدولة؟

أشارككم قصتي مع الفوضى التي سببتها مهام Cron المجدولة وكيف كانت بمثابة شبكة عنكبوت صامتة كادت أن تدمر أحد المشاريع. نستكشف معًا كيف أنقذتني أدوات...

19 مارس، 2026 قراءة المزيد
​معمارية البرمجيات

تغيير قاعدة البيانات كان يتطلب إعادة كتابة نصف التطبيق: كيف أنقذتني ‘المعمارية النظيفة’ (Clean Architecture) من هذا الكابوس؟

أشارككم قصة حقيقية من مسيرتي كمبرمج، حيث كاد قرار تغيير قاعدة البيانات أن يدمر مشروعًا بالكامل. سأشرح لكم كيف أنقذتني مبادئ "المعمارية النظيفة" (Clean Architecture)...

19 مارس، 2026 قراءة المزيد
تجربة المستخدم والابداع البصري

كل زر بلون مختلف وكل أيقونة بقصة: كيف أنقذني ‘نظام التصميم’ (Design System) من فوضى الواجهات؟

أشارككم قصة من قلب المعركة، كيف انتقلنا من فوضى الألوان والأزرار المتضاربة في مشاريعنا إلى التناغم والكفاءة. هذه المقالة هي دليلك العملي لفهم وبناء "نظام...

18 مارس، 2026 قراءة المزيد
الحوسبة السحابية

كل نقرة في لوحة التحكم كانت قنبلة موقوتة: كيف أنقذتني ‘البنية التحتية كشيفرة’ (IaC) من كارثة محققة؟

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

17 مارس، 2026 قراءة المزيد
التوظيف وبناء الهوية التقنية

مقابلاتي السلوكية كانت كارثة: كيف أنقذتني طريقة STAR من أسئلة ‘حدثنا عن موقف صعب…؟’

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

16 مارس، 2026 قراءة المزيد
البودكاست