> ## Content Index > Fetch the complete content index at: https://arabroot.io/llms.txt > Use this file to discover other available public pages before exploring further. # كشف الاحتيال Fraud Detection: قواعد أم تعلم آلة؟ - URL: https://arabroot.io/articles/كشف-الاحتيال-fraud-detection-قواعد-ام-تعلم-الة/ - Published: 2026-10-27T12:29:06.000Z - Updated: 2026-10-27T18:02:55.000Z - Description: قارنا القواعد بنموذجين لتعلم الآلة على بيانات دفع مولدة بنفس سعة المراجعة، ورأينا من يمسك الأنماط المعروفة ومن يتأخر عن النمط الجديد. - Author: فريق عرب رووت - Tags: الأدلة التقنية, التقنية المالية والمدفوعات لنفرض أن لديك شركة ناشئة تقدم محفظة دفع للمتاجر الإلكترونية الصغيرة، يدفع بها العملاء ويحولون الأموال لبعضهم. وفي ليلة خميس لاحظ مهندس المناوبة شيئاً غريباً: حساب واحد أجرى عشر عمليات دفع خلال دقائق، كل منها بين ريال وخمسة ريالات، لمتاجر مختلفة. وفي الصباح وصلت ثلاثة بلاغات من عملاء يقولون إن عمليات كبيرة خرجت من محافظهم من جهاز لا يعرفونه. وكتب الفريق في نفس الأسبوع ثلاث قواعد بسيطة: نبه إذا تجاوز المبلغ خمسة أضعاف متوسط العميل من جهاز جديد، ونبه إذا أجرى الحساب خمس عمليات أو أكثر في ساعة، ونبه إذا جاءت عملية كبيرة في منتصف الليل من جهاز جديد. ونجحت القواعد. وبعد شهر سأل مستثمر في اجتماع: «لماذا لا تستخدمون الذكاء الاصطناعي لكشف الاحتيال؟»، ولم يعرف أحد هل الإجابة «نعم» أم «لا». وهذا هو السؤال الذي سوف نتابعه في هذا المقال: متى تكفي القواعد Rules، ومتى يضيف تعلم الآلة Machine Learning شيئاً حقيقياً، وما الذي يخفيه كل منهما. ولن نجيب من الكلام العام، وإنما من مختبر بلغة Python على بيانات مولدة فيها أربعة أنماط من الاحتيال، أحدها يظهر فجأة في منتصف الفترة، ونقارن الطريقتين بنفس سعة المراجعة. سوف نناقش في هذا المقال: - ما هو الاحتيال في المدفوعات بأنواعه، وما الذي يطلبه إطار مكافحة الاحتيال من SAMA من أنظمة الكشف. - كيف يعمل نظام الكشف من الدفعة إلى القرار، ولماذا تعود الحقيقة متأخرة، وأين تضعه قبل الدفع أو بعده، وكيف تحسب الخصائص في الإنتاج. - القواعد: كيف تكتب، وما قوتها، وأين تفشل. - تعلم الآلة: الخصائص Features، والبيانات غير المتوازنة، ولماذا لا تكفي الدقة Accuracy مقياساً. - مختبر بنفس سعة المراجعة: من أمسك أكثر، ثم ماذا يحدث عندما يظهر نمط جديد، وعندما تزيد سعة المراجعة. - ماذا تقول للعميل، وما الذي تراقبه كل يوم، وكيف يجمع الفريق الطريقتين، وقائمة تحقق لنظام الكشف. ## ما الذي نحاول كشفه بالضبط؟ الاحتيال في المدفوعات ليس نوعاً واحداً، وإطار مكافحة الاحتيال الذي أصدره البنك المركزي السعودي SAMA يطلب في [ضابط الكشف 3.3.1](https://rulebook.sama.gov.sa/en/33-fraud-detection?ref=arabroot.io) أن تراقب المؤسسات منتجاتها وخدماتها لسلوك قد يدل على احتيال خارجي، ويسمي ثلاثة أنواع على الأقل: - **احتيال الطرف الأول First Party**: العميل نفسه يكذب في هويته أو معلوماته ليحتال بحسابه، مثل من يشتري ثم يدعي أنه لم يشتر. - **احتيال الطرف الثاني Second Party**: شخص يعطي معلوماته أو يسمح باستخدام هويته عمداً، مثل حسابات الوسطاء Mules التي تستقبل المال المسروق وتنقله. - **احتيال الطرف الثالث Third Party**: شخص غير مخول يحصل على بيانات العميل دون علمه ويستخدمها، مثل سرقة الحساب Account Takeover واختبار البطاقات المسروقة Card Testing. والتفريق مهم للمهندس، لأن كل نوع يترك أثراً مختلفاً في البيانات: سرقة الحساب تظهر كجهاز جديد ومبلغ غير معتاد، واختبار البطاقات يظهر كدفعات صغيرة كثيرة في وقت قصير، وحسابات الوسطاء تظهر كحركة تبدو طبيعية لعميل قديم، ولكنها تذهب إلى مستفيدين جدد كل يوم. وفي القصة كانت الدفعات الصغيرة الليلية اختبار بطاقات، والبلاغات الثلاثة سرقة حسابات. ولكي تعرف حجم المشكلة عالمياً، فأحدث تقرير مشترك من الهيئة المصرفية الأوروبية EBA والبنك المركزي الأوروبي ECB، المنشور في [1 أغسطس 2024](https://www.eba.europa.eu/publications-and-media/press-releases/eba-and-ecb-release-joint-report-payment-fraud?ref=arabroot.io)، قدر احتيال المدفوعات في المنطقة الاقتصادية الأوروبية بـ 4.3 مليار يورو في 2022، و2.0 مليار في النصف الأول من 2023، وأكد أن العمليات التي مرت بالمصادقة القوية للعميل SCA كانت نسب الاحتيال فيها أقل، وأن نسب احتيال البطاقات كانت أعلى بعشر مرات عندما يكون الطرف الآخر خارج المنطقة حيث لا تشترط هذه المصادقة. والدرس للمهندس أن الكشف ليس خط الدفاع الوحيد، فخطوة تحقق إضافية في المكان الصحيح تمنع جزءاً من الاحتيال قبل أن يحتاج أحد أن يكشفه، وقد شرحنا التحقق 3D Secure في مقال الدفع بالبطاقة. ## كيف يعمل نظام الكشف؟ سواء كانت قواعد أو نموذجاً، فالنظام نفسه له نفس الشكل كما في الصورة التالية: ![مسار الكشف من اليمين إلى اليسار: الدفعة بالمبلغ والجهاز والوقت، ثم الخصائص مثل المبلغ مقابل متوسط العميل وعدد العمليات في ساعة، ثم مساران: القواعد Rules تعطي نعم أو لا وسبباً مكتوباً، والنموذج Model يعطي درجة من 0 إلى 1، ثم القرار بالقبول أو المراجعة أو الرفض أو تحقق إضافي مثل OTP، ثم فريق المراجعة بسعة محدودة كل يوم، وسهم متقطع يعود إلى البداية: الوسوم Labels تعود متأخرة من نتيجة المراجعة وبلاغ العميل والاعتراض بعد أيام أو أسابيع، وفي الأسفل أن القواعد تكتب من فهم الفريق والنموذج يتعلم من الوسوم وكلاهما يحتاج مراجعة دورية كما تطلب الضوابط 3.5.4 و3.5.5 في إطار مكافحة الاحتيال من SAMA](https://arabroot.io/content/images/2026/10/fraud-detection-01-pipeline.webp) القواعد والنموذج يختلفان في المنتصف فقط، والبداية والنهاية واحدة - **الخصائص Features**: الدفعة وحدها لا تقول شيئاً، فمبلغ 2000 ريال طبيعي لعميل ومريب لآخر. لذلك يحسب النظام لكل دفعة أرقاماً من تاريخ العميل: نسبة المبلغ إلى متوسطه، وعدد عملياته في الساعة الأخيرة، وهل الجهاز جديد، وهل المستفيد جديد، وعمر الحساب. وهذه الخصائص تحتاج أن تحسب في أجزاء من الثانية أثناء الدفع، وهذا وحده عمل هندسي كبير. - **القرار ليس نعم أو لا**: بين القبول والرفض خيارات أخرى، مثل طلب تحقق إضافي برمز OTP، أو قبول الدفعة وإرسالها للمراجعة قبل التسوية، أو تأخير التحويل للمستفيد الجديد ساعات. وكل خيار له تكلفة على العميل الصادق. - **سعة المراجعة**: كل تنبيه يحتاج إنساناً يراجعه، والفريق في القصة شخصان يراجعان نحو سبعة تنبيهات في اليوم إلى جانب عملهما، وهذا رقم يحدد كل شيء بعده، لأن نظاماً يخرج مئة تنبيه في اليوم لفريق يراجع سبعة هو نظام لا يراجعه أحد. - **الوسوم تعود متأخرة**: الحقيقة، أي هل كانت الدفعة احتيالاً، لا تعرف لحظة الدفع، وإنما بعد أيام عندما يبلغ العميل، أو بعد أسابيع عندما يصل اعتراض Chargeback من البنك المصدر كما شرحنا في مقال الدفع بالبطاقة. وهذا التأخير هو ما سوف يظهر أثره بوضوح في المختبر. وإطار SAMA نفسه يطلب في [ضوابط تقنية مكافحة الاحتيال 3.5](https://rulebook.sama.gov.sa/en/35-counter-fraud-technology?ref=arabroot.io) أشياء تنطبق على الطريقتين: أن تكون البيانات التي يعتمد عليها الكشف في وقتها وكاملة ودقيقة، وأن يراقب أداء حلول الكشف ويختبر دورياً بالضبط والمعايرة، وأن تراجع السيناريوهات والمعايير دورياً بحسب ما يظهر من معلومات وتقييم المخاطر. أي أن السؤال الحقيقي ليس «قواعد أم نموذج»، وإنما كيف تقيس أي منهما وكيف تعرف متى توقف عن العمل. ## قبل الدفع أم بعده؟ مكان الكشف في المسار أول قرار هندسي في القصة لم يكن نوع الكشف، وإنما توقيته. فهناك مكانان يمكن أن يعمل فيهما: - **قبل الموافقة على الدفعة**: الكشف جزء من طلب الدفع نفسه، والعميل ينتظر الرد، فكل ملي ثانية في الكشف تضاف إلى زمن الدفع، وإذا تعطل نظام الكشف يجب أن تقرر مسبقاً هل تقبل الدفعات دونه أم ترفضها. وهنا تعمل القواعد السريعة ونموذج خفيف يحسب درجته من خصائص جاهزة. - **بعد الدفعة وقبل خروج المال**: الدفعة مقبولة، ولكن المال لم يخرج بعد من المنصة إلى المستفيد، فيوجد وقت لمراجعة أعمق، مثل تأخير التحويل لمستفيد جديد ساعات حتى يراجع. وهذا هو المكان الطبيعي لكشف حسابات الوسطاء، لأن الضرر يقع عند خروج المال لا عند دخوله. واختار الفريق في القصة الاثنين: قواعد اختبار البطاقات وسرقة الحساب قبل الموافقة لأن ضررهما فوري، والنموذج والقاعدة R4 قبل خروج المال، مع تأخير تحويل المستفيد الجديد الذي يتجاوز حداً معيناً حتى نهاية يوم العمل. وهذا التأخير قرار منتج يحتاج أن يشرح للعميل في التطبيق، لا قرار هندسي يخفى عنه. ## الخصائص في الإنتاج: الجزء الذي لا يظهر في المختبر في المختبر كانت الخصائص أعمدة جاهزة في ملف CSV، أما في الإنتاج فحساب «عدد العمليات في الساعة الأخيرة» لحظة الدفع مشكلة هندسية بحد ذاتها، وأغلب وقت الفريق في القصة ذهب إليها لا إلى النموذج: - **النوافذ المنزلقة Sliding Windows**: عدد العمليات في الساعة الأخيرة ومجموعها يتغير مع كل عملية، فيحفظ في مخزن سريع مثل Redis بمفتاح لكل حساب، ويحدث مع كل دفعة، وتنتهي القيم القديمة تلقائياً. وقد شرحنا هذا النوع من العدادات في [مقال تحديد معدل الطلبات](https://arabroot.io/articles/%D8%AA%D8%AD%D8%AF%D9%8A%D8%AF-%D9%85%D8%B9%D8%AF%D9%84-%D8%A7%D9%84%D8%B7%D9%84%D8%A8%D8%A7%D8%AA-rate-limiting-%D9%88%D8%AE%D9%88%D8%A7%D8%B1%D8%B2%D9%85%D9%8A%D8%A7%D8%AA%D9%87/). - **الدقة الزمنية Point-in-Time**: عند التدريب يجب أن تحسب كل خاصية كما كانت لحظة العملية، لا كما هي اليوم، فمتوسط إنفاق العميل اليوم يحتوي العمليات التي بعدها، واستخدامه في التدريب يعطي النموذج معلومة من المستقبل. والطريقة الآمنة أن تحفظ الخصائص التي حسبت لحظة الدفع مع كل عملية، وتتدرب عليها هي نفسها، بدل أن تعيد حسابها لاحقاً. - **الجهاز الجديد**: يبدو بسيطاً، ولكنه يحتاج تعريفاً ثابتاً للجهاز من معرف التطبيق أو بصمة المتصفح، وحذراً من أن تحديث نظام التشغيل قد يجعل جهازاً قديماً يبدو جديداً، فيرفع التنبيهات الخاطئة فجأة لكل العملاء في يوم واحد. - **البيانات الناقصة**: إذا تعطل مصدر خاصية، فالقيمة الافتراضية قرار، فصفر عمليات في الساعة يعني «آمن» للقاعدة R2، وهذا عكس ما تريده عند العطل. لذلك تسجل كل خاصية ناقصة، ويعامل غيابها كإشارة لا كصفر. وضابط SAMA 3.5.3 يطلب صراحة ضوابط تضمن أن البيانات التي يعتمد عليها الكشف في وقتها وكاملة ودقيقة، مثل تنبيهات جودة البيانات واختبارات التكامل والاختبارات الارتدادية عند التغيير، وهذا الجزء بالضبط هو ما يعنيه في الواقع. ## القواعد: لماذا يبدأ بها الجميع؟ القاعدة شرط يكتبه إنسان فهم نمطاً، مثل قواعد الفريق الثلاث في القصة، وقوتها في ثلاثة أشياء: تكتب في ساعة بعد أن يلاحظ أحد نمطاً جديداً، وتشرح نفسها، فعندما يسأل العميل لماذا أوقفت عمليته يقرأ الموظف السبب مباشرة، وتعمل من اليوم الأول دون أي بيانات تاريخية. وضعفها في ثلاثة أشياء أيضاً: لا ترى إلا ما فكر فيه كاتبها، وتتراكم مع الوقت حتى يصبح عندك مئات القواعد لا يعرف أحد لماذا كتب نصفها، وتعطي نعم أو لا، فلا تستطيع أن ترتب التنبيهات بحسب خطورتها عندما يزيد عددها على سعة المراجعة. وفي المختبر كتبنا قواعد الفريق كدالة واحدة، وكل قاعدة تعيد اسمها إذا تحققت، حتى يعرف المراجع أي قاعدة أطلقت التنبيه: ```python def rules(r, with_mule_rule=False): hits = [] if r["amount"] > 5 * r["user_avg"] and r["new_device"]: hits.append("R1") if r["tx_last_hour"] >= 5: hits.append("R2") if r["hour"] <= 5 and r["new_device"] and r["amount"] > 500: hits.append("R3") if with_mule_rule and r["new_payee"] and r["new_payees_today"] >= 1 and r["amount"] >= 300: hits.append("R4") return hits ``` والقاعدة الرابعة `R4` مطفأة في البداية، وسوف نحتاجها عندما يظهر النمط الجديد. ## تعلم الآلة: ما الذي يتعلمه النموذج فعلاً؟ النموذج لا يكتب شرطاً، وإنما يتعلم من أمثلة سابقة موسومة، أي عمليات نعرف أنها كانت احتيالاً أو لم تكن، كيف تختلف الخصائص بين النوعين، ثم يعطي لكل عملية جديدة درجة احتمال. وفي المختبر جربنا نموذجين من مكتبة scikit-learn بالإصدار 1.7.2: الانحدار اللوجستي Logistic Regression، وهو نموذج بسيط يعطي لكل خاصية وزناً، و[Gradient Boosting](https://scikit-learn.org/stable/modules/generated/sklearn.ensemble.HistGradientBoostingClassifier.html?ref=arabroot.io)، وهو مجموعة أشجار قرار تتعلم كل منها أخطاء التي قبلها، ويلتقط التفاعل بين الخصائص، مثل «جهاز جديد ومستفيد جديد معاً». ### لماذا لا تصلح الدقة Accuracy مقياساً؟ في بياناتنا كانت 0.29% فقط من العمليات احتيالاً، أي أن نموذجاً يقول «ليست احتيالاً» لكل عملية بلا استثناء تكون دقته 99.71%، ولا يمسك شيئاً. وهذه هي البيانات غير المتوازنة Imbalanced Data، وهي الحالة الطبيعية في الاحتيال. لذلك نقيس بمقياسين أدق، كما في [توثيق مقاييس التقييم](https://scikit-learn.org/stable/modules/model%5Fevaluation.html?ref=arabroot.io): - **الدقة Precision**: من كل التنبيهات، كم كان احتيالاً فعلاً؟ وهذا ما يشعر به فريق المراجعة، فالدقة المنخفضة تعني أن أغلب وقته يذهب على عملاء صادقين. - **الاستدعاء Recall**: من كل الاحتيال، كم أمسكنا؟ وهذا ما يشعر به العملاء الذين سرقت أموالهم. والاثنان يتعارضان، فكلما زادت التنبيهات زاد الاستدعاء وقلت الدقة. ولكي تكون المقارنة عادلة بين القواعد والنموذج، قسناهما بنفس عدد التنبيهات، أي بنفس سعة المراجعة، لا بعتبة Threshold افتراضية مثل 0.5 لا معنى لها في بيانات بهذا الاختلال. ## المختبر: بيانات مولدة بأربعة أنماط لا يجوز استخدام بيانات بطاقات أو حسابات حقيقية في مختبر، لذلك كتبنا سكربتاً يولد محفظة تجريبية بأربعة آلاف عميل خلال ستين يوماً، لكل عميل متوسط إنفاق خاص به، وبعضهم يتسوق ليلاً عادة، وكلها ببذرة ثابتة `random.seed(42)` حتى تعيد نفس الأرقام. وفي البيانات أربعة أنماط من الاحتيال، صممناها لتشبه الأنواع التي شرحناها: - **سرقة الحساب**: عمليتان يومياً بجهاز جديد ومستفيد جديد ومبلغ بين 6 و20 ضعف متوسط الضحية، غالباً في ساعات الليل. - **اختبار البطاقات**: كل يومين حساب يجري بين 6 و12 عملية صغيرة بين ريال وخمسة ريالات بجهاز جديد. - **الاحتيال الهادئ**: عمليتان يومياً بجهاز جديد، ولكن بمبلغ قريب من المعتاد وفي ساعات النهار، وهو أصعب نمط لأنه يشبه عميلاً غير هاتفه. - **حسابات الوسطاء**: نمط جديد يبدأ في اليوم 45 فقط، حسابات قديمة بأجهزتها المعروفة ترسل بين مرتين وأربع مرات يومياً مبالغ بين 300 و900 ريال إلى مستفيدين جدد. ```text 234082 transactions, 686 fraud (0.29%) by pattern: {'takeover': 120, 'card_testing': 272, 'quiet': 120, 'mule': 174} ``` وقسمنا الأيام بحسب الزمن لا عشوائياً، لأن النموذج في الواقع يتدرب على الماضي ويعمل على المستقبل: الأيام من 0 إلى 29 للتدريب، ومن 30 إلى 44 للاختبار بنفس الأنماط، ومن 45 إلى 59 لاختبار النمط الجديد. والتقسيم العشوائي يخلط عمليات اليوم نفسه بين التدريب والاختبار، فيعطي أرقاماً أجمل من الواقع. ### كيف ولدنا البيانات؟ المولد في المختبر خمسون سطراً، وأهم ما فيه أن كل نمط احتيال يكتب كدالة واضحة بخصائصه، فإذا أردت أن تجرب نمطاً آخر أضفت سطوراً قليلة. وهذا مثلاً نمط الوسطاء الذي يبدأ في اليوم 45: ```python if day >= 45: for u in random.sample(users, 4): for _ in range(random.randint(2, 4)): add(day, int(min(23, max(6, random.gauss(14, 3)))), u, random.uniform(300, 900), False, True, random.choice([1, 2, 3]), 1, "mule") ``` أربعة حسابات يومياً، كل منها بين مرتين وأربع، بأجهزة معروفة (`False`) ومستفيدين جدد (`True`)، في ساعات النهار. والعمليات الصادقة تولد لكل عميل يومياً بين صفر وثلاث عمليات، بمبلغ حول متوسطه، ونسبة صغيرة منها بجهاز جديد أو مستفيد جديد، لأن العملاء الصادقين يغيرون هواتفهم ويدفعون لأشخاص جدد أيضاً. وهذه النسبة الصغيرة هي ما يجعل الكشف صعباً أصلاً، فلو لم يغير أحد هاتفه لكفت قاعدة واحدة. ⚠️ انتبه إلى انحياز في هذا المختبر: من كتب القواعد هو نفسه من صمم مولد البيانات، فالقواعد تعرف الأنماط الثلاثة الأولى بالضبط، وهذا يعطيها أفضلية لا تجدها في الواقع، حيث لا يعرف أحد كل الأنماط. لذلك اقرأ الأرقام كمثال على سلوك الطريقتين، لا كحكم بأن إحداهما أفضل. ### النتيجة الأولى: نفس الأنماط ونفس سعة المراجعة أطلقت القواعد 104 تنبيهات في الأيام من 30 إلى 44، فأعطينا كل نموذج نفس العدد، أي أعلى 104 درجات، والمخرج سوف يكون كما يلي: ```text train days 0-29: 117251 tx, 254 fraud | test days 30-44: 58248 tx | drift days 45-59: 58583 tx == days 30-44 (same patterns as training) rules R1-R3 alerts 104 caught 99/129 precision 95.2% recall 76.7% | card_testing=69/69 quiet=0/30 takeover=30/30 logistic regression (top 104) alerts 104 caught 77/129 precision 74.0% recall 59.7% | card_testing=46/69 quiet=1/30 takeover=30/30 PR-AUC 0.762 gradient boosting (top 104) alerts 104 caught 91/129 precision 87.5% recall 70.5% | card_testing=69/69 quiet=2/30 takeover=20/30 PR-AUC 0.690 ``` ![أشرطة للأيام 30 إلى 44 بنفس 104 تنبيهات: القواعد R1-R3 أمسكت سرقة الحساب 30 من 30 واختبار البطاقات 69 من 69 والهادئ 0 من 30، أي 99 من 129، والانحدار اللوجستي 30 من 30 و46 من 69 و1 من 30، أي 77 من 129، وGradient Boosting 20 من 30 و69 من 69 و2 من 30، أي 91 من 129](https://arabroot.io/content/images/2026/10/fraud-detection-02-same-capacity.webp) القواعد التي تعرف الأنماط تفوز عليها، والنمط الهادئ لم يمسكه أحد في المخرج أعلاه لاحظ التالي: - **القواعد أمسكت أكثر**: 99 من 129 بدقة 95.2%، وكل اختبار البطاقات وكل سرقات الحساب. وهذا متوقع مع الانحياز الذي ذكرناه، ولكنه يقول شيئاً حقيقياً أيضاً: عندما تعرف النمط جيداً، فالقاعدة المكتوبة له صعب أن تهزم. - **النموذجان وزعا التنبيهات بشكل مختلف**: الانحدار اللوجستي أمسك سرقة الحساب كلها وفاته ثلث اختبار البطاقات، وGradient Boosting العكس تقريباً. والسبب أن كل نموذج يرتب العمليات بطريقته، وعندما يكون عدد التنبيهات محدوداً، فما يرفعه نموذج إلى أعلى القائمة يدفع غيره خارجها. - **الاحتيال الهادئ لم يمسكه أحد تقريباً**: صفر بالقواعد، وواحد واثنان بالنموذجين، من 30\. وهذا النمط لم يكتب له أحد قاعدة، والنموذجان لم يضعاه في أعلى 104. - **PR-AUC**: مساحة منحنى الدقة والاستدعاء، رقم يلخص جودة الترتيب كله لا عند عتبة واحدة، وكان أعلى للانحدار اللوجستي البسيط، 0.762 مقابل 0.690\. أي أن النموذج الأعقد ليس أفضل تلقائياً، خاصة مع إعداداته الافتراضية وعدد قليل من أمثلة الاحتيال. ### ماذا لو غير المحلل رقماً في القاعدة؟ القاعدة R1 تقول «خمسة أضعاف المتوسط»، فمن أين جاءت الخمسة؟ في القصة جاءت من شعور المهندس ليلة الخميس، وهذه هي الطريقة التي تكتب بها أغلب القواعد. فجربنا كل قاعدة وحدها بعدة أرقام على نفس الأيام من 30 إلى 44: ```text R1 alone, amount > 2x average alerts 192 caught 40/129 precision 20.8% recall 31.0% | card_testing=0/69 quiet=10/30 takeover=30/30 R1 alone, amount > 3x average alerts 74 caught 30/129 precision 40.5% recall 23.3% | card_testing=0/69 quiet=0/30 takeover=30/30 R1 alone, amount > 5x average alerts 34 caught 30/129 precision 88.2% recall 23.3% | card_testing=0/69 quiet=0/30 takeover=30/30 R1 alone, amount > 8x average alerts 27 caught 27/129 precision 100.0% recall 20.9% | card_testing=0/69 quiet=0/30 takeover=27/30 R1 alone, amount > 12x average alerts 19 caught 19/129 precision 100.0% recall 14.7% | card_testing=0/69 quiet=0/30 takeover=19/30 R2 alone, 3+ tx in the last hour alerts 69 caught 69/129 precision 100.0% recall 53.5% | card_testing=69/69 quiet=0/30 takeover=0/30 R2 alone, 5+ tx in the last hour alerts 69 caught 69/129 precision 100.0% recall 53.5% | card_testing=69/69 quiet=0/30 takeover=0/30 R2 alone, 8+ tx in the last hour alerts 45 caught 45/129 precision 100.0% recall 34.9% | card_testing=45/69 quiet=0/30 takeover=0/30 ``` في المخرج أعلاه لاحظ التالي: - **الرقم في القاعدة هو عتبة أيضاً**: نزول R1 من خمسة أضعاف إلى ثلاثة ضاعف التنبيهات من 34 إلى 74 دون أن يمسك احتيالاً إضافياً واحداً، ونزوله إلى ضعفين أمسك 10 من النمط الهادئ ولكن بدقة 20.8%. وصعوده إلى 8 أضعاف رفع الدقة إلى 100% وفوت ثلاث سرقات. أي أن القاعدة تواجه نفس المفاضلة بين الدقة والاستدعاء التي يواجهها النموذج، والفرق أن أحداً لا يقيسها غالباً. - **R2 مثالية في البيانات المولدة فقط**: دقة 100% عند ثلاث عمليات أو خمس، لأن المولد لم يعط أي عميل صادق أكثر من عمليتين في الساعة. وهذا لا يحدث في الواقع، فالعميل الذي يدفع لعدة متاجر في سوق إلكتروني، أو يعيد المحاولة بعد رفض، يتجاوز هذا الرقم. وهذا مثال آخر على أن البيانات المولدة تعلمك سلوك الطريقة، ولا تعطيك الرقم الذي تضعه في الإنتاج. والدرس الذي كتبه الفريق: كل رقم في كل قاعدة يختار بنفس طريقة اختيار عتبة النموذج، على بيانات حقيقية سابقة، مع الدقة والاستدعاء وعدد التنبيهات، ويكتب سبب اختياره بجانبه، حتى يعرف من يراجعه بعد سنة لماذا هو خمسة لا ثلاثة. ### ماذا لو زادت سعة المراجعة؟ القواعد تعطيك قائمة واحدة ثابتة، 104 تنبيهات، فإذا وظف الفريق مراجعاً ثالثاً فلا شيء يتغير. أما النموذج فيعطيك ترتيباً لكل العمليات، تقطعه حيث تسمح سعتك. فقسنا الاستدعاء عند 150 و250 و500 تنبيه: ```text logistic regression top 104 alerts 104 caught 77/129 precision 74.0% recall 59.7% | card_testing=46/69 quiet=1/30 takeover=30/30 logistic regression top 150 alerts 150 caught 89/129 precision 59.3% recall 69.0% | card_testing=54/69 quiet=5/30 takeover=30/30 logistic regression top 250 alerts 250 caught 110/129 precision 44.0% recall 85.3% | card_testing=65/69 quiet=15/30 takeover=30/30 logistic regression top 500 alerts 500 caught 123/129 precision 24.6% recall 95.3% | card_testing=69/69 quiet=24/30 takeover=30/30 gradient boosting top 104 alerts 104 caught 91/129 precision 87.5% recall 70.5% | card_testing=69/69 quiet=2/30 takeover=20/30 gradient boosting top 150 alerts 150 caught 95/129 precision 63.3% recall 73.6% | card_testing=69/69 quiet=4/30 takeover=22/30 gradient boosting top 250 alerts 253 caught 96/129 precision 37.9% recall 74.4% | card_testing=69/69 quiet=5/30 takeover=22/30 gradient boosting top 500 alerts 500 caught 103/129 precision 20.6% recall 79.8% | card_testing=69/69 quiet=12/30 takeover=22/30 days 30-44: legit with new device AND new payee: 108 of 58119; quiet fraud with both: 19 of 30 ``` ![منحنيان للاستدعاء Recall مقابل عدد التنبيهات في الأيام 30 إلى 44: الانحدار اللوجستي 59.7% عند 104 و69.0% عند 150 و85.3% عند 250 و95.3% عند 500، وGradient Boosting 70.5% و73.6% و74.4% و79.8%، والقواعد نقطة واحدة ثابتة عند 104 تنبيهات و76.7%](https://arabroot.io/content/images/2026/10/fraud-detection-04-capacity.webp) القواعد نقطة واحدة، والنموذج منحنى تختار عليه عند 500 تنبيه في 15 يوماً أمسك الانحدار اللوجستي 95.3% من الاحتيال، ومنه 24 من 30 من النمط الهادئ الذي لم تكتب له قاعدة، ولكن الدقة نزلت إلى 24.6%، أي ثلاثة تنبيهات خاطئة من كل أربعة. والسطر الأخير يشرح من أين جاء هذا: العملية بجهاز جديد ومستفيد جديد معاً نادرة جداً عند العملاء الصادقين، 108 من 58,119، وموجودة في 19 من 30 من الاحتيال الهادئ. وهذا تفاعل بين خاصيتين لم يكتب له أحد قاعدة، والنموذج وجده من الأمثلة. ولكن لاحظ أن Gradient Boosting بإعداداته الافتراضية لم يستفد من السعة الإضافية بنفس القدر، فاختيار النموذج وضبطه يحتاج قياساً على بياناتك، لا افتراضاً بأن الأعقد أفضل. والقرار هنا ليس تقنياً فقط: 500 تنبيه في 15 يوماً، أي نحو 33 في اليوم، لفريق يراجع سبعة يعني توظيفاً أو خطوة تحقق آلية بدل المراجعة البشرية، مثل طلب رمز OTP من العمليات ذات الدرجة المتوسطة، والرفض أو المراجعة للدرجة العالية فقط. وهذا ما يجعل النموذج مفيداً حتى عندما لا يتفوق على القواعد في أعلى القائمة. ### ماذا لو ظهر نمط جديد؟ في اليوم 45 يبدأ نمط الوسطاء، وهو لا يشبه شيئاً في بيانات التدريب: أجهزة معروفة، ومبالغ متوسطة، وساعات نهار. فطبقنا نفس القواعد ونفس النموذجين بنفس العتبات على الأيام من 45 إلى 59، ثم أضفنا القاعدة `R4` من اليوم 46، كأن محللاً لاحظ النمط في يومه الأول وكتب له قاعدة، ثم أعدنا تدريب Gradient Boosting مرتين مع افتراض أن الوسم يصل بعد سبعة أيام من العملية: ```text == days 45-59 (a new pattern, mule cash-out, starts on day 45) rules R1-R3 alerts 107 caught 99/303 precision 92.5% recall 32.7% | card_testing=69/69 mule=0/174 quiet=0/30 takeover=30/30 logistic regression (same threshold) alerts 148 caught 105/303 precision 70.9% recall 34.7% | card_testing=49/69 mule=25/174 quiet=1/30 takeover=30/30 gradient boosting (same threshold) alerts 113 caught 97/303 precision 85.8% recall 32.0% | card_testing=69/69 mule=0/174 quiet=1/30 takeover=27/30 rules R1-R4 (new rule on day 46) alerts 235 caught 205/287 precision 87.2% recall 71.4% | card_testing=69/69 mule=107/162 quiet=1/28 takeover=28/28 == retraining with delayed labels: fraud labels arrive 7 days late boosting retrained day 45 (labels<=38) alerts 110 caught 101/287 precision 91.8% recall 35.2% | card_testing=69/69 mule=9/162 quiet=4/28 takeover=19/28 boosting retrained day 52 (labels<=45) alerts 72 caught 67/142 precision 93.1% recall 47.2% | card_testing=30/30 mule=22/84 quiet=1/14 takeover=14/14 ``` ![أشرطة للأيام 45 إلى 59: القواعد R1-R3 أمسكت حسابات الوسطاء 0 من 174 والمجموع 99 من 303، والانحدار اللوجستي 25 من 174 والمجموع 105 من 303، وGradient Boosting 0 من 174 والمجموع 97 من 303، والقواعد مع R4 من اليوم 46 أمسكت 107 من 162 والمجموع 205 من 287، وإعادة التدريب يوم 52 أمسكت 22 من 84 والمجموع 67 من 142](https://arabroot.io/content/images/2026/10/fraud-detection-03-drift.webp) القاعدة المكتوبة في يوم سبقت النموذج الذي ينتظر وسومه في المخرج أعلاه لاحظ التالي: - **النمط الجديد غير مرئي**: القواعد الثلاث وGradient Boosting لم يمسكوا أي عملية وسيط من 174، والاستدعاء الكلي نزل من نحو 70% إلى نحو الثلث، دون أي رسالة خطأ. والانحدار اللوجستي أمسك 25 منها، لأنه أعطى وزناً للمستفيد الجديد يرفع أي عملية فيها مستفيدون جدد كثيرون، ولكنه أطلق 148 تنبيهاً بدل 104، أي أن عتبته نفسها صارت تعطي تنبيهات أكثر مع البيانات الجديدة. - **القاعدة الجديدة سريعة**: R4 المكتوبة في اليوم 46 أمسكت 107 من 162 عملية وسيط من ذلك اليوم، ورفعت الاستدعاء إلى 71.4%، ولكنها ضاعفت التنبيهات إلى 235، أي أنها تحتاج سعة مراجعة. - **إعادة التدريب بطيئة بسبب الوسوم**: النموذج المعاد تدريبه في اليوم 45 رأى الوسوم حتى اليوم 38 فقط، أي قبل أن يبدأ النمط، فأمسك 9 من 162 فقط. والمعاد تدريبه في اليوم 52 رأى أول ستة أيام من النمط، فأمسك 22 من 84 في الأيام الباقية. أي أن النموذج يتعلم النمط الجديد، ولكن بعد أن تصل وسومه، وهذا هو الثمن الذي تبينه الصورة التالية. ![خط زمني: اليوم 45 يبدأ النمط الجديد، واليوم 46 قاعدة R4 يكتبها محلل فتمسك 107 من 162، واليوم 52 وصلت أول وسوم النمط وأعيد تدريب النموذج فأمسك 22 من 84، واليوم 59 نهاية التجربة، وتحتها أن القاعدة تحتاج إنساناً لاحظ النمط والنموذج يحتاج أمثلة موسومة تأتي من الاعتراضات والبلاغات، فالنظام العملي يجمع الاثنين](https://arabroot.io/content/images/2026/10/fraud-detection-05-label-delay.webp) القاعدة تنتظر من يلاحظ، والنموذج ينتظر من يسم وتأخير سبعة أيام اختيار في المختبر، وفي الواقع قد يكون أطول بكثير، فالاعتراض على عملية بطاقة قد يصل بعد أسابيع بحسب قواعد الشبكة، والوسيط الذي يستقبل المال قد لا يكتشف أبداً إذا لم يبلغ الضحية. لذلك لا تعتمد في وسومك على الاعتراضات وحدها، وإنما أضف نتائج المراجعة اليدوية وبلاغات العملاء، فهي تصل أسرع. ### لماذا أمسك النموذج البسيط بعض الوسطاء وفاتت المعقد كلها؟ هذه النتيجة تبدو غريبة أول مرة، ولكنها تشرح الفرق بين النموذجين من الداخل. فالانحدار اللوجستي يعطي كل خاصية وزناً ثابتاً، ويجمع الأوزان مضروبة في القيم، فإذا تعلم أن المستفيد الجديد وعدد المستفيدين الجدد اليوم يرفعان الخطورة قليلاً، فإن عملية فيها الاثنان بقيم أعلى من المعتاد ترتفع درجتها، حتى لو لم ير هذا الشكل بالضبط من قبل. أي أنه يمد ما تعلمه إلى مناطق لم يرها، وهذا قد يكون صحيحاً كما حدث هنا، وقد يكون خاطئاً في حالات أخرى. أما Gradient Boosting فيقسم البيانات إلى مناطق بأسئلة متتالية مثل «هل عدد العمليات في الساعة أكبر من 4؟»، ويعطي كل منطقة درجة بحسب ما رآه فيها أثناء التدريب. والأرجح أن العملية الوسيطة تقع في منطقة كانت كلها عمليات صادقة في التدريب: جهاز معروف، وساعة نهار، ومبلغ عادي، وعدد عمليات قليل، فأخذت درجة منخفضة، لأن الأشجار لا تمد ما تعلمته خارج ما رأته. وهذا ليس عيباً في النموذج، وإنما طبيعته: هو أدق في الأنماط التي رآها، وأعمى عن التي لم يرها. ولذلك لا يكفي أن تقيس النموذج على فترة اختبار تشبه التدريب، كما في أرقام الأيام من 30 إلى 44، وإنما تسأل دائماً: ماذا يحدث له مع نمط لم يره؟ ### ماذا يرى النموذج؟ آخر سطر في المخرج يجيب عن سؤال يطرحه كل محلل: على أي خاصية يعتمد النموذج؟ واستخدمنا أهمية التبديل Permutation Importance، أي نخلط قيم خاصية واحدة عشوائياً ونقيس كم ينخفض الأداء، كما في [توثيقها](https://scikit-learn.org/stable/modules/permutation%5Fimportance.html?ref=arabroot.io): ```text == permutation importance (gradient boosting, days 30-44): tx_last_hour 0.502, new_payee 0.116, amount 0.052, user_avg 0.047, ratio 0.034 ``` النموذج يعتمد أولاً على عدد العمليات في الساعة، أي على نمط اختبار البطاقات، ثم على المستفيد الجديد، ثم على المبلغ. وهذا يشرح لماذا لم يرفع النمط الهادئ إلى أعلى القائمة، فهو لا يعتمد على الجهاز الجديد بقدر ما ظننا. وهذا النوع من الفحص ضروري قبل أن تضع أي نموذج في الإنتاج، والسبب أن النموذج الذي يعتمد على خاصية واحدة يسقط كله عندما يغير المحتالون تلك العادة، وهو أيضاً ما تحتاجه عندما تشرح لعميل أو مدقق لماذا أوقفت عمليته. ## ماذا تقول للعميل عندما توقف عمليته؟ العميل الصادق الذي أوقفت عمليته لا يهمه هل كان السبب قاعدة أو نموذجاً، وإنما ماذا يفعل الآن. لذلك كتب الفريق في القصة لكل قرار رسالة للعميل لا تكشف القاعدة نفسها، لأن كشفها يعلم المحتال كيف يتجنبها، وتعطيه خطوة واضحة: «أوقفنا هذه العملية للتحقق من أنك صاحب الحساب، أكد هويتك بالرمز المرسل إلى جوالك»، أو «سوف تصل الحوالة للمستفيد الجديد خلال يوم عمل». ولموظف الدعم شاشة مختلفة تعرض السبب كاملاً: اسم القاعدة، أو أهم الخصائص التي رفعت درجة النموذج، حتى يستطيع أن يقرر بسرعة إذا اتصل العميل. وهنا تظهر قيمة القاعدة التي تشرح نفسها، وقيمة فحص أهمية الخصائص في النموذج، فالنموذج الذي لا يستطيع أحد أن يشرح قراره يصعب الدفاع عنه أمام عميل أو مدقق. ## ما الذي تراقبه كل يوم؟ النمط الجديد في المختبر خفض الاستدعاء إلى الثلث دون أي خطأ، وفي الإنتاج لن تعرف الاستدعاء الحقيقي إلا بعد أن تصل الوسوم، أي بعد فوات الأوان. لذلك تحتاج أرقاماً تعرفها في نفس اليوم، تتغير قبل أن يتغير الاستدعاء: - **عدد التنبيهات من كل قاعدة ومن النموذج**: في المختبر قفزت تنبيهات الانحدار اللوجستي من 104 إلى 148 بنفس العتبة عندما ظهر النمط الجديد، وهذه القفزة نفسها كانت إشارة إلى أن شيئاً تغير. - **توزيع الخصائص**: نسبة العمليات بمستفيد جديد، ومتوسط المبالغ، ونسبة الأجهزة الجديدة، فأي تغير مفاجئ فيها إما نمط احتيال جديد، أو عطل في حساب الخاصية، أو تغيير في المنتج، والثلاثة تحتاج من ينظر. - **نتائج المراجعة اليومية**: نسبة التنبيهات التي ثبت أنها احتيال، وهي الدقة كما يعيشها الفريق، فإذا انخفضت فجأة فالمراجعون يضيعون وقتهم، وإذا ارتفعت فجأة فربما هجوم واسع. - **البلاغات التي لم يسبقها تنبيه**: كل بلاغ احتيال عن عملية لم يطلق عليها النظام أي تنبيه هو أهم سطر في اليوم، لأنه مثال مباشر على ما يفوتك. وهذه المراقبة نفسها هي ما يطلبه ضابط SAMA 3.5.4 عن مراقبة الأداء والاختبار الدوري بالضبط والمعايرة، فهي ليست عملاً إضافياً للالتزام، وإنما الطريقة الوحيدة لتعرف أن نظامك ما زال يعمل. ## كيف جمع الفريق الطريقتين؟ بعد المختبر لم يختر الفريق في القصة «قواعد» أو «تعلم آلة»، وإنما بنى طبقات، لكل منها وظيفة: 1. **قواعد صلبة للمعروف**: اختبار البطاقات وسرقة الحساب أنماط معروفة وواضحة، والقواعد أمسكتها كلها بدقة عالية، فتبقى قواعد بأسماء وأسباب، وتوقف العملية أو تطلب تحققاً إضافياً فوراً. 2. **نموذج للترتيب**: بعد القواعد، يرتب النموذج بقية العمليات، وأعلاها يذهب للمراجعة بقدر السعة المتاحة كل يوم، والطبقة الوسطى تطلب رمز OTP بدل المراجعة. وهذا يستفيد من قوة النموذج في التفاعلات التي لم يكتب لها أحد قاعدة، مثل الجهاز الجديد مع المستفيد الجديد. 3. **مراقبة للمجهول**: لوحة يومية لعدد التنبيهات من كل قاعدة ومن النموذج، ولنسبة المستفيدين الجدد والأجهزة الجديدة، فإذا تغير رقم فجأة كما حدث في اليوم 45 لاحظه أحد قبل أن تصل البلاغات. والمحلل الذي يلاحظ النمط يكتب له قاعدة مؤقتة في يومه، والنموذج يتعلمه في إعادة التدريب التالية بعد أن تصل وسومه. 4. **الوسوم من كل مصدر**: نتيجة كل مراجعة تحفظ كوسم، مع بلاغات العملاء والاعتراضات، لأن النموذج لا يتعلم إلا مما يوسم. وأي نموذج جديد أو إعادة تدريب لا تدخل الإنتاج مباشرة، وإنما تعمل أسبوعين في الظل Shadow Mode: تحسب درجتها لكل عملية وتحفظها، دون أن تؤثر في أي قرار، ثم يقارن الفريق تنبيهاتها بتنبيهات النظام الحالي وبما وصل من وسوم. والسبب أن النموذج الذي يبدو أفضل في الاختبار قد يطلق في الإنتاج تنبيهات أكثر من سعة المراجعة، كما رأينا في قفزة الانحدار اللوجستي من 104 إلى 148، وهذا يكتشف في الظل دون أن يدفع ثمنه عميل. وأضاف الفريق قاعدة على القواعد نفسها: كل قاعدة لها مالك وتاريخ مراجعة، وتحذف القاعدة التي لم تطلق تنبيهاً صحيحاً منذ ثلاثة أشهر، وهذا تطبيق مباشر لضابط SAMA 3.5.5 عن مراجعة السيناريوهات والمعايير دورياً، وإلا تراكمت القواعد حتى لا يفهمها أحد. ## تبني أم تستخدم ما عند مزود الدفع؟ قبل أن تبني أياً من هذا، اسأل مزود الدفع الذي تعمل معه عما يقدمه، فبعض المزودين يقدمون كشفاً جاهزاً يعمل على كل عملياتهم، مثل Radar في Stripe الذي يسمح كما في [توثيقه](https://docs.stripe.com/radar?ref=arabroot.io) بقوائم للعملاء الموثوقين وقواعد تحدد هل تقبل العملية أو ترفض أو ترسل للمراجعة أو يطلب لها تحقق 3DS. والميزة الكبيرة لمثل هذه الأدوات أنها ترى عمليات آلاف المتاجر، فتعرف البطاقة المسروقة قبل أن تصل إليك، وهذا ما لا يستطيع نموذج تتدرب عليه على بياناتك وحدها. ولكنها ترى عمليات البطاقات التي تمر بها فقط، أما التحويل بين المحافظ داخل منصتك، وهو مكان نمط الوسطاء في القصة، فلا يراه أحد غيرك. لذلك قسم الفريق العمل: كشف المزود لعمليات البطاقات عند الدخول، ونظامه هو للتحويلات الداخلية وخروج المال، وهذا ما جعل نظامه أصغر بكثير مما توقع. ## التكلفة: ليست كل الأخطاء متساوية المقاييس في المختبر تعامل كل الأخطاء بنفس الوزن، والواقع ليس كذلك. فالاحتيال الذي يفلت يكلف مبلغ العملية، وربما رسوم اعتراض، وثقة عميل. والتنبيه الخاطئ يكلف دقائق من وقت المراجع، والرفض الخاطئ لعملية صادقة يكلف عميلاً غاضباً قد لا يعود، وهذه التكلفة الأخيرة هي التي ينساها أغلب الفرق لأنها لا تظهر في أي تقرير. لذلك اختر العتبات بحساب بسيط مع فريق المنتج والمالية: كم يكلف المتوسط من كل نوع خطأ؟ ثم اختر العتبة التي تقلل المجموع، لا التي تعطي أجمل استدعاء. وفي القصة كان هذا الحساب هو ما جعل الفريق يطلب رمز OTP للدرجات المتوسطة بدل الرفض، لأن تكلفة خطوة إضافية على عميل صادق أقل كثيراً من تكلفة رفضه. ## أخطاء شائعة - **التقسيم العشوائي للبيانات**: يخلط الماضي بالمستقبل، فيعطي أرقاماً لن تراها في الإنتاج. قسم بحسب الزمن دائماً. - **الدقة Accuracy مقياساً**: مع 0.29% احتيال، نموذج لا يمسك شيئاً دقته 99.71%. - **عتبة 0.5**: لا معنى لها في بيانات بهذا الاختلال، والعتبة تختار من سعة المراجعة وتكلفة الأخطاء. - **خصائص من المستقبل**: خاصية مثل «تم الاعتراض على العملية» تجعل النموذج ممتازاً في الاختبار ولا يعمل في الإنتاج لأنها لا تعرف وقت الدفع، وهذا ما يسمى تسرب البيانات Data Leakage. - **نموذج بلا مراقبة**: النمط الجديد في المختبر خفض الاستدعاء إلى الثلث دون أي خطأ ظاهر، ولا يكشف ذلك إلا من يراقب الأرقام يومياً. - **قواعد بلا مالك**: مئات القواعد التي لا يعرف أحد لماذا كتبت، وتطلق تنبيهات لا يقرؤها أحد. ## قائمة تحقق لنظام الكشف | البند | كيف تتحقق منه | | ----------------------------------------- | -------------------------------------------- | | سعة المراجعة معروفة ومكتوبة | عدد التنبيهات اليومي لا يتجاوزها | | القياس بالدقة والاستدعاء لا بالدقة الكلية | تقرير أسبوعي بالرقمين لكل قاعدة وللنموذج | | التقسيم الزمني في التقييم | التدريب على الماضي والاختبار على ما بعده | | الوسوم تجمع من كل مصدر | المراجعة والبلاغات والاعتراضات في جدول واحد | | كل قاعدة لها مالك وتاريخ مراجعة | لا قاعدة بلا تنبيه صحيح منذ ثلاثة أشهر | | مراقبة يومية للتغير | تنبيه عند تغير مفاجئ في التنبيهات أو الخصائص | | القرار درجات لا نعم أو لا | قبول، وتحقق إضافي، ومراجعة، ورفض | | تفسير لكل تنبيه | اسم القاعدة، أو أهم الخصائص في درجة النموذج | | بيانات تجريبية فقط خارج الإنتاج | لا بيانات بطاقات أو عملاء حقيقيين في المختبر | ## الخلاصة وصلنا لنهاية الموضوع، وأهم ما فيه: - إطار مكافحة الاحتيال من SAMA يطلب مراقبة الاحتيال من الأطراف الثلاثة، ومراقبة أداء حلول الكشف ومراجعة سيناريوهاتها دورياً، سواء كانت قواعد أو نماذج. - في المختبر وبنفس 104 تنبيهات، أمسكت القواعد التي تعرف الأنماط 99 من 129، وGradient Boosting 91، والانحدار اللوجستي 77، مع انحياز لصالح القواعد لأن كاتبها صمم البيانات. - النموذج ترتيب تقطعه بحسب سعتك: عند 500 تنبيه أمسك الانحدار اللوجستي 95.3% ومعه 24 من 30 من النمط الهادئ الذي لم تكتب له قاعدة، بدقة 24.6%. - النمط الجديد في اليوم 45 لم يره أحد تقريباً، والقاعدة المكتوبة في يومه الأول أمسكت 107 من 162، والنموذج المعاد تدريبه انتظر وسومه فأمسك 22 من 84. - النظام العملي طبقات: قواعد للمعروف، ونموذج للترتيب، ومراقبة للمجهول، ووسوم من كل مصدر. والمقالات المرتبطة: [![](https://arabroot.io/content/images/2026/10/card-payment-flow-cover-cover.webp)دليلكيف يعمل الدفع بالبطاقة؟ التفويض Authorization والتسويةمن ضغطة «ادفع» إلى آخر اعتراض: التفويض و3D Secure والتحصيل والتسوية والاسترداد والاعتراض، مع مختبر لأحداث مزود الدفع ومطابقتها.](https://arabroot.io/articles/%D9%83%D9%8A%D9%81-%D8%AA%D8%B9%D9%85%D9%84-%D8%B9%D9%85%D9%84%D9%8A%D8%A9-%D8%A7%D9%84%D8%AF%D9%81%D8%B9-%D8%A8%D8%A7%D9%84%D8%A8%D8%B7%D8%A7%D9%82%D8%A9-%D8%A7%D9%84%D8%AA%D9%81%D9%88%D9%8A%D8%B6-%D9%88%D8%A7%D9%84%D8%AA%D8%B3%D9%88%D9%8A%D8%A9-%D9%88%D8%A7%D9%84%D8%A7%D8%B9%D8%AA%D8%B1%D8%A7%D8%B6/)[![](https://arabroot.io/content/images/2026/10/wallet-ledger-cover-cover.webp)دليلالمحفظة الرقمية من الداخل: دفتر القيد المزدوج Ledgerكيف تبني محفظة رقمية لا يضيع فيها ريال ولا يخصم مرتين، بالقيد المزدوج والمعاملات والمطابقة مع مزود الدفع.](https://arabroot.io/articles/%D9%83%D9%8A%D9%81-%D8%AA%D8%A8%D9%86%D9%8A-%D9%85%D8%AD%D9%81%D8%B8%D8%A9-%D8%B1%D9%82%D9%85%D9%8A%D8%A9-ledger/)[![](https://arabroot.io/content/images/2026/10/ledger-tools-cover-cover.webp)دليلدفتر الأستاذ للأموال Ledger: TigerBeetle وFormance وBlnkشغلنا TigerBeetle وFormance Ledger وBlnk بنفس سيناريو الحجز والتقسيم، ورأينا كيف تحمي كل أداة الرصيد ومتى يعرف تطبيقك النتيجة.](https://arabroot.io/articles/%D8%AF%D9%81%D8%AA%D8%B1-%D8%A7%D9%84%D8%A7%D8%B3%D8%AA%D8%A7%D8%B0-%D9%84%D9%84%D8%A7%D9%85%D9%88%D8%A7%D9%84-ledger-tigerbeetle-%D9%88-formance-%D9%88-blnk/)[![](https://arabroot.io/content/images/2026/10/saudi-payments-cover-cover.webp)دليلمنظومة المدفوعات في السعودية: سريع وSARIE ومدى وسدادالأنظمة الوطنية للمدفوعات في المملكة كما تصفها مصادر البنك المركزي، وما يعنيه كل نظام للمطور، مع تحليل تقارير نقاط البيع الأسبوعية.](https://arabroot.io/articles/%D9%85%D9%86%D8%B8%D9%88%D9%85%D8%A9-%D8%A7%D9%84%D9%85%D8%AF%D9%81%D9%88%D8%B9%D8%A7%D8%AA-%D9%81%D9%8A-%D8%A7%D9%84%D8%B3%D8%B9%D9%88%D8%AF%D9%8A%D8%A9-%D8%B3%D8%B1%D9%8A%D8%B9-%D9%88-sarie-%D9%88-%D9%85%D8%AF%D9%89-%D9%88-%D8%B3%D8%AF%D8%A7%D8%AF/) ## سجل التحديثات - أكتوبر 2026: كتابة المقال ومختبر على بيانات مولدة (Python 3.13.3 وscikit-learn 1.7.2 وNumPy 2.5.4)، مع ضوابط إطار مكافحة الاحتيال من SAMA (3.3.1 و3.5) وتقرير EBA وECB عن احتيال المدفوعات (1 أغسطس 2024) كما ظهرت في 27 أكتوبر 2026.