حين رُفض 40% من دفعة تقارير CTR لدى أحد البنوك: قصة تعافٍ مع goAML

سيناريو مركّب مستمد من عمليات نشر نموذجية في شرق أفريقيا. تفاصيل المؤسسة مُجهَّلة، والأرقام تمثيلية ولا تُنسب إلى عميل بعينه.

الشهر الذي توقفت فيه التقارير عن المرور

كان لدى مديرة الامتثال في بنك تجاري كيني من الفئة الثانية روتينٌ لا تحبه. ففي اليوم 3 من كل شهر، كان فريقها يصدّر المعاملات النقدية للشهر السابق من النظام المصرفي الأساسي إلى جدول بيانات، وينقّحها يدويًا، ويشغّل ماكرو يُنتج ملف goAML XML، ثم يرفع الملف إلى بوابة Financial Reporting Centre (FRC).

ثم يبدأ الانتظار.

في الشهر الجيد، كانت البوابة تقبل الدفعة وينتقل الفريق إلى مهامه الأخرى. وفي الشهر السيئ — وقد باتت الأشهر السيئة هي المعتاد — كانت البوابة تُعيد خطأ تحقق يشير إلى عنصر XSD لا يستطيع أحد في المبنى تفسيره. وفي أحد الأشهر، رُفض نحو 40% من الدفعة. وكان أمام الفريق أربعة أيام عمل لإعادة التقديم قبل انقضاء مهلة الإبلاغ، دون أي وسيلة موثوقة لمعرفة أيٍّ من السجلات، البالغة عدة آلاف، هو موضع الخطأ.

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

ما الذي كان يتعطل فعلًا

حين استعرضنا العملية مع الفريق خطوةً خطوة، تبيّن أن الإخفاقات تتجمع حول أربعة أسباب، لا يتعلق أيٌّ منها بالتقدير المهني في مسائل الامتثال:

• انحراف صامت عن المخطط. كان الماكرو قد كُتب وفق إصدار أقدم من goAML XSD. وحين انتقل المخطط إلى الإصدار v5.0.2، أصبحت عدة عناصر اختيارية إلزاميةً، وتغيّر أحد التعدادات. ولم يُعِد أحدٌ بناء الماكرو.
• حقول معرّفات بنص حر. كانت أنواع هويات العملاء تُدخَل في النظام المصرفي الأساسي بطرق غير متسقة — «National ID» و«NATIONAL_ID» و«ID Card» — وكانت طبقة المطابقة تمررها كما هي.
• منطق حدود الإبلاغ محصور في جدول بيانات. كان رصد المعاملات النقدية يعتمد على عامل تصفية يتولى محلل واحد صيانته. وكان تجميع معاملات العميل نفسه في اليوم نفسه يجري بالعين المجردة.
• لا فحص مسبق قبل الإرسال. لم يكن أحد يعلم أن الملف غير صالح إلا بعد أن تُبلغهم الجهة الرقابية بذلك.

والنقطة الأخيرة هي الأهم. فكل مشكلة أخرى كان يمكن تجاوزها لو اكتُشفت قبل التقديم. ولم يكن من الممكن تجاوز أيٍّ منها حين كانت حلقة الملاحظات تمر عبر بوابة FRC ومعها مهلة لا تتجاوز أربعة أيام.

ما الذي تغيّر

نشر البنك منصة تقارير goAML من Creodata في نسخة Azure مخصصة لعميل واحد (single-tenant)، إلى جانب منصته المصرفية الأساسية القائمة. وانتقلت ثلاثة أمور:

خرجت المطابقة من جداول البيانات. تتدفق بيانات المعاملات والعملاء عبر تكامل آمن، وتُطابَق تلقائيًا مع نموذج بيانات goAML. وتُوحَّد أنواع المعرّفات وفق تعدادات المخطط عند الاستيعاب، فلا تصل «ID Card» أبدًا إلى أداة إنشاء XML.

انتقل الرصد إلى داخل المنصة. تُهيَّأ حدود الإبلاغ عن المعاملات النقديةEN — بما فيها قواعد التجميع خلال اليوم الواحد — مرة واحدة، وتُطبَّق باتساق. وتظهر المعاملات التي تبلغ الحد تلقائيًا بدلًا من الاعتماد على عامل تصفية لدى أحد المحللين.

انتقل التحقق إلى ما قبل التقديم. يُتحقَّق من كل ملف يُنشأ وفق مخطط goAML XSD v5.0.2 الساري داخل المنصة. وتُوسَم السجلات التي تُخفق مع تحديد العنصر المعني والسجل المعني، بلغة يستطيع محلل الامتثال أن يتصرف بناءً عليها، قبل أيام من اقتراب الملف من الجهة الرقابية.

وعولج جانب تقارير STR على حدة. فتقارير المعاملات المشبوهة تُصاغ الآن في مساحة عمل مخصصة بدلًا من Word، بحيث يبقى السرد والمعاملات المرتبطة والكيانات الداعمة معًا، ويمكن إعادة تكوينها لاحقًا.

النتيجة

أُرسل أول تقديم فعلي بعد ستة أسابيع من انطلاق المشروع. وقُبل من المحاولة الأولى، وكذلك التقديمات التي تلته. ولم يعد اليوم 3 من الشهر حدثًا يُحسب له حساب.

وكان لأثرين جانبيين أهمية فاقت ما توقعه الفريق:

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

توقف فريق الامتثال عن إدخال البيانات. فالساعات التي كانت تُصرف سابقًا في مطابقة الملفات المُصدَّرة ذهبت إلى ما يُدفع للفريق أجره فعلًا — مراجعة التنبيهات وكتابة سرديات اشتباه يمكن الدفاع عنها. وفي شهر نموذجي، يعني ذلك أكثر من 80 ساعة تحوّلت من معالجة الصيغ إلى التحليل.

ما الذي سنقوله للبنك التالي

ثلاثة دروس من هذه التجربة قابلة للتعميم.

حالات الرفض عَرَض، لا المرض نفسه. تميل المؤسسات إلى الرد على الدفعة المرفوضة بإضافة مراجع. وهذا يزيد التكلفة ولا يلتقط سوى نصف الأخطاء ربما، لأن البشر لا يُحسنون رصد مخالفات XSD في ملفات XML. والحل الدائم هو آلة تفحص الملف وفق المخطط الذي تستخدمه الجهة الرقابية فعلًا.

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

البلد مهم. فكلٌّ من FRC في كينياEN، ووحدة FIU في تنزانياEN، وهيئة FIA في أوغنداEN، ومركز FIC في روانداEN، ومركز FIC في زامبياEN يضيف متطلبات محلية فوق الأساس المشترك لنظام goAML. والمنصة التي تتعامل مع «goAML» بوصفه هدفًا واحدًا ستُخفق عند أول حدود وطنية. وينبغي للمؤسسات العاملة في ولايات قضائية متعددة أن تختبر القواعد الخاصة بكل بلد صراحةً، لا أن تفترض إمكانية نقلها كما هي.

ويقدّم البنك في هذه القصة تقاريره الآن في ولايتين قضائيتين من نشر واحد. وما زالت مديرة الامتثال لا تحب اليوم 3 من الشهر، لكن لأسباب عادية.

للمزيد من القراءة: الدليل الشامل لتقارير goAML · هل رُفض تقديمك إلى goAML؟ كيف تشخّص الأخطاء الشائعة وتصلحها

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