التقارير الرقابيةRegulatory reporting

التقارير الرقابية ملفات ترسلها المؤسسة المرخّصة إلى جهتها الرقابية في مواعيد محدّدة، تصف فيها عملياتها وأرصدتها ومخاطرها بصيغة تحدّدها الجهة لا هي.

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

الفرق بين أن تعمل وأن تُثبت أنك عملت

ولنفترض أن ضابط الرقابة عندك يعمل بامتياز. فالنظام يفحص كل عميل جديد مقابل قوائم العقوبات، ولم تمرّ حالة واحدة دون فحص طوال العام. ثم يأتي المدقق ويسأل سؤالاً بسيطاً: أثبت لي ذلك.

وهنا تنهار كثير من الفرق. فالفحص جرى فعلاً، لكن سجلاته موزّعة بين قاعدة بيانات وبريد إلكتروني وملف على جهاز موظف غادر الشركة. والنتيجة أن الشركة أدّت الواجب وعجزت عن إثباته، وهي في نظر الرقيب كمن لم يؤدِّه.

ولهذا تُوجد فئة منتجات كاملة هدفها ليس تنفيذ الضابط، بل جمع ما يثبت أنه نُفِّذ.

حزمة الأدلة

ويُسمّى هذا المخرج «حزمة الأدلة» Evidence pack. وهي ليست لقطة شاشة، بل ملف مرتبط بفترة زمنية محددة يحتوي أربعة أشياء: ما هو الضابط، ومن يملكه، وماذا كانت نتيجته في تلك الفترة، وما الاستثناءات التي حدثت ومن وافق عليها.

والاستثناءات هي أهم جزء وأكثر ما يُحذف. فالمدقق لا يبحث عن كمال، بل يبحث عن وعي. فحزمة تقول «فشل الفحص التلقائي في ١٤ حالة، عولجت يدوياً خلال يومين، ووافق عليها مدير المخاطر» أقوى بكثير من حزمة تقول إن كل شيء كان أخضر طوال العام. لأن الثانية إمّا كاذبة وإمّا تعني أن أحداً لا ينظر.

الإقرار الرقابي

ويختلف عن الحزمة شيء اسمه «الإقرار الرقابي» Regulatory return. وهو أرقام دورية تطلبها الجهة الرقابية بصيغة محددة: أحجام العمليات، وعدد الشكاوى، والحوادث التشغيلية، وكفاية رأس المال حسب النشاط.

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

المطابقة قبل التقديم

وأخطر خطوة في هذا المسار هي المطابقة. فإذا قالت بوابة الدفع إن عدد العمليات هذا الشهر ٤١٠ آلاف، وقال السجلّ المحاسبي ٤٠٩ آلاف، فأنت أمام فجوة يجب تفسيرها قبل التقديم لا بعده.

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

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

كيف تُبنى الحزمة فعلاً

ولا تُجمع الحزمة بتصدير كل شيء، فذلك يغرق المدقق ولا يقنعه. بل تُبنى بـ«اختبار الضابط» Control testing، وهو أن تأخذ عيّنة وتثبت أن الضابط عمل عليها.

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

ويحتاج هذا شيئاً يسمّى «نَسَب البيانات» Data lineage، أي القدرة على تتبّع الرقم في التقرير رجوعاً إلى مصدره. فحين يسأل المدقق: من أين جاء رقم الشكاوى هذا؟ لا يكفي أن تقول من لوحة الجودة. بل يجب أن تصل من الرقم إلى الاستعلام إلى الجدول إلى النظام الذي كتب السطر أصلاً.

من يطلب هذا في السعودية

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

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

لا تخلط بين المراقبة والتقارير

وقد يبيعك مزوّد واحد الاثنين، لكنهما منتجان مختلفان. فالمراقبة تنتج تنبيهات يومية يعالجها محقق، ومقياس نجاحها زمن الاستجابة. والتقارير تجمع إثباتاً لفترة مغلقة، ومقياس نجاحها أن يمرّ التدقيق بلا أسئلة.

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