🚨 الجزء الثالث: مفارقة الزمن المصرفي.. كيف تُخصم رسوم "بدل مسروق" لبطاقة لم تُسرق بعد؟!
في عالم قواعد البيانات المصرفية والتدقيق المحاسبي الصارم، يُعتبر "الطابع الزمني" (Timestamp) أمراً مقدساً لا يقبل التلاعب. كل عملية مالية ترتبط بتسلسل زمني منطقي (Time-Series Data) يستحيل كسره برمجياً إلا بتدخل بشري متعمد لتعديل السجلات بأثر رجعي.
بعد أن كشفنا في الجزء السابق عن اختفاء تواريخ 14 و 22 مايو من التقارير المرفوعة للبنك المركزي (ساما) باستخدام أوامر برمجية (NOT IN) لطمس الأدلة، نضع اليوم على طاولة الرقابة المالية دليلاً رقمياً ينسف ما تبقى من مصداقية لكشوفات هذا البنك.
⏱ التناقض الزمني المستحيل (The Timeline Paradox):
تُظهر الكشوفات الرسمية الصادرة من البنك —والمرفوعة رسمياً للبنك المركزي— أنه تم تقييد عملية مالية بقيمة (50.00 ريال + 7.50 ضريبة) تحت مسمى صريح: رسوم إصدار بطاقة بدل فاقد/مسروق (LOST STOLEN REP / REISSUE FEE)، وذلك في تاريخ 21 مايو 2025 على البطاقة المنتهية بـ (1233).
الكارثة المحاسبية والتقنية هنا تكمن في حقيقة أن عملية الاختراق والإبلاغ الفعلي لم تكتمل وتُسجل إلا في 22 مايو.
💻 التشريح البرمجي للكارثة:
الأنظمة البنكية المركزية (Core Banking) لا تعمل بالنيات، بل بتسلسل شرطي برمجي صارم (Conditional Logic). دورة حياة البطاقة المسروقة برمجياً تتم كالتالي:
إدخال بلاغ السرقة
(Insert Fraud_Report).إيقاف البطاقة
(Update Status = 'Blocked').إصدار البديل وخصم الرسوم
(Trigger Reissue_Fee).
لو قمنا بتشغيل استعلام تدقيق جنائي بسيط (Audit Query) على قاعدة بيانات البنك للبحث عن هذا التناقض، فسيكون الكود كالتالي:
-- استعلام التدقيق الجنائي لكشف التلاعب الزمني في القيود
SELECT
Card_Number,
Fraud_Report_Date,
Reissue_Fee_Date
FROM
Core_Banking_Transactions
WHERE
Transaction_Type = 'LOST STOLEN REP'
AND Reissue_Fee_Date < Fraud_Report_Date;
-- المنطق البرمجي السليم: يجب أن تكون النتيجة (0 سجلات).
-- الواقع الكارثي: النظام سيعرض بيانات بطاقتي كدليل إدانة صارخ!
أن يتم تنفيذ سطر الخصم Reissue_Fee_Date قبل سطر البلاغ Fraud_Report_Date بيوم كامل، فهذا يضع البنك أمام احتمالين أحلاهما مر:
الاحتمال الأول (انهيار النظام): أن النظام البنكي يعاني من خلل كارثي في خوارزميات القيود المحاسبية، مما يعني أن جميع العمليات المالية للعملاء تُقيد بتواريخ عشوائية، وهذا ينسف موثوقية البنك بالكامل.
الاحتمال الثاني (التلاعب اليدوي - Manual Override): وهو الأرجح؛ أن هناك تدخلاً يدوياً من موظفي البنك لمحاولة "ترقيع" السجلات وتسوية الحسابات بأثر رجعي لتبدو طبيعية أمام الرقابة، لكنهم سقطوا في فخ التواريخ ونسوا مطابقة يوم الخصم بيوم الإبلاغ.
هذا التخبط لا يمثل مجرد "خطأ نظام عابر"، بل هو خرق صريح وخطير للوائح الامتثال (Compliance)، وتلاعب مباشر في السجلات المالية المرفوعة للجهات الرقابية لتضليلها عن التسلسل الحقيقي للكارثة.
