تكامل النظام المصرفي الأساسي مع goAML: خيارات API وSFTP وCSV

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

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

والخبر السار أن أساليب التكامل الثلاثة المتاحة — REST API، ونقل الملفات عبر SFTP، والاستيراد من ملفات CSV/Excel — تغطي الطيف الكامل من القدرات التقنية لدى المؤسسات المالية في شرق أفريقيا، من البنوك الرقمية النشأة ذات الأنظمة المصرفية الأساسية السحابية الأصل، إلى المؤسسات المجتمعية ذات المنصات القديمة والبنية التحتية المحدودة لتقنية المعلومات.

---

لماذا يهمّ التكامل للامتثال في goAML

GIGO: بيانات رديئة تدخل، وXML رديء يخرج

مخطط goAML XSD صارم. إذ يُتحقَّق من كل مستند XML مقدَّم وفق المخطط ووفق قواعد العمل الخاصة بكل بلد. فالمبلغ المخزَّن في النظام المصرفي الأساسي سلسلةً نصيةً بفاصل للآلاف («1,250,000») يجب تحويله إلى رقم عشري بخانتين عشريتين بالضبط («1250000.00»). والتاريخ المخزَّن بصيغة DD/MM/YYYY يجب أن يصبح YYYY-MM-DD. ونوع المعاملة المخزَّن رمزًا رقميًا («01» للإيداع النقدي) يجب ربطه بقيمة التعداد المقابلة («CASH_DEPOSIT») في goAML.

وإذا لم تجرِ هذه التحويلات تلقائيًا في طبقة تكامل حسنة التصميم، فلا بد من إجرائها يدويًا — والإعداد اليدوي للبيانات هو مصدر معظم أخطاء التقديم في goAML. فحتى مسؤولو الامتثال ذوو المهارة العالية يقعون في أخطاء النسخ عند تحويل البيانات يدويًا بين الصيغ تحت ضغط الوقت.

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

إعادة الإدخال اليدوي هي مصدر معظم أخطاء goAML

في البنوك التي تفتقر إلى تكامل آلي مع النظام المصرفي الأساسي، يسير العمل عادةً على النحو التالي: يستخرج فريق تقنية المعلومات تقريرًا بالمعاملات من النظام المصرفي الأساسي ويسلّمه في ملف Excel؛ فيُصدِّر محلل الامتثال البيانات ذات الصلة، ويطابق الحقول يدويًا مع بنية goAML XML، ويملأ نموذج goAML، ثم يقدّمه. وكل خطوة يدوية تفتح بابًا للأخطاء.

ومن أكثر الأخطاء الناتجة عن إعادة الإدخال اليدوي شيوعًا: قلب صيغة التاريخ (إدخال 6 مارس على أنه 3 يونيو)، وأخطاء موضع الفاصلة العشرية (إدخال 125,000 شلن كيني على أنه 12,500 أو 1,250,000 شلن كيني)، واقتطاع حقول الأسماء، وتبديل مواضع الأرقام في أرقام الحسابات، وعدم تطابق رموز العملات. وأي خطأ من هذه الأخطاء يؤدي إلى إخفاق ملف XML المقدَّم إما في التحقق من المخطط وإما في التحقق من قواعد العمل على بوابة وحدة المعلومات المالية (FIU).

التكامل يزيل طبقة النسخ البشري

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

---

أسلوب التكامل 1: REST API

آلية العمل

يتيح التكامل عبر REST API لمنصة مكافحة غسل الأموال طلب بيانات المعاملات من طبقة API في النظام المصرفي الأساسي وفق جدول زمني أو عند وقوع أحداث معينة. فتُجري المنصة المصادقة مع واجهة API للنظام المصرفي الأساسي، وتطلب المعاملات المطابقة لمعايير محددة (نطاق التاريخ، ونوع المعاملة، وحد المبلغ)، وتتلقى الاستجابة بصيغة JSON أو XML، ثم تطابق حقول الاستجابة مع نموذج البيانات الداخلي للمنصة.

ويدعم هذا الأسلوب الوصول إلى البيانات في الوقت الفعلي وشبه الفعلي على حد سواء. ففي توليد تنبيهات تقارير المعاملات المشبوهة (STR) — حين يلزم إظهار نمط معاملات مشبوه لمسؤول الامتثال بأسرع ما يمكن بعد وقوعه — يوفّر الاستطلاع الدوري لواجهة API في الوقت شبه الفعلي كل 15 إلى 60 دقيقة أحدث البيانات.

وفي مراقبة حد الإبلاغ عن المعاملات النقدية (CTR)، يتيح الاستيعاب عبر API الكشف عن كل معاملة على حدة في الوقت شبه الفعلي مقارنةً بالحد البالغ ما يعادل 15,000 دولار أمريكي، بحيث تُعرض المعاملات المستوفية للحد لإنشاء حالات CTR ضمن الموعد النهائي للتقديم، أي يوم الجمعة من الأسبوع نفسه.

الأنظمة المصرفية الأساسية التي توفّر REST API في شرق أفريقيا

يتضمن Temenos T24 R20 وما بعده مكوّن T24 API Server، الذي يعرض الاستعلامات (enquiries) المبنية على TAFJ بوصفها نقاط نهاية RESTful. ويتطلب استرجاع بيانات المعاملات تعريف استعلام في T24 يحدد الحقول ومعايير التصفية، ويُعرض عبر API Server. ويدعم T24 API Server المصادقة ببيانات اعتماد العميل (client credentials) في OAuth 2.0.

ويتضمن Infosys Finacle 10 و11 مكوّن Finacle Connect API Gateway، الذي يوفّر نقاط نهاية REST لبيانات الحسابات والعملاء والمعاملات. ويدعم إطار API في Finacle كلًا من الاستعلام المتزامن والإشعار غير المتزامن بأحداث المعاملات عبر webhook.

ويوفّر Oracle FlexCube (الإصدار FCUBS 12 وما بعده) طبقة خدمات RESTful عبر إطار الخدمات (Service Framework) الخاص به. وتتطلب خدمات REST في FlexCube إعدادات تنسيق الخدمات (service orchestration) المناسبة، وتدعم المصادقة برمز الحامل (bearer token) في OAuth 2.0.

أما Mambu فمبنيٌّ أصلًا على مبدأ API أولًا. إذ تعرض Mambu Core Banking Platform واجهة REST API شاملة دون الحاجة إلى أي إعدادات إضافية. وتتوفر بيانات المعاملات عبر نقاط النهاية الخاصة بالقروض (Loans) وحسابات الادخار (Savings) والحسابات الجارية (Current Account)، مع دعم واسع للتصفية وترقيم الصفحات (pagination).

المصادقة

تجري المصادقة في التكامل عبر API إما باستخدام تدفق بيانات اعتماد العميل (client credentials) في OAuth 2.0 (وهو الموصى به للتكامل بين الخوادم)، وإما بالمصادقة بمفتاح API. وتخزّن منصة مكافحة غسل الأموال بيانات الاعتماد في مخزن أسرار مشفّر، وتقدّمها مع كل طلب. وتجري جميع الاتصالات عبر API باستخدام HTTPS/TLS 1.2 أو أعلى.

حالات الاستخدام الموصى بها

التكامل عبر REST API هو الأسلوب المفضّل في الحالات التالية:

• توليد تنبيهات تقارير STR في الوقت الفعلي أو شبه الفعلي انطلاقًا من مراقبة المعاملات
• الكشف عن بلوغ حد الإبلاغ عن المعاملات النقدية (CTR) لكل معاملة على حدة مقارنةً بما يعادل 15,000 دولار أمريكي، مع تحويل العملات في الوقت الفعلي
• إثراء بيانات اعرف عميلك (KYC) للعملاء (تاريخ فتح الحساب، والمهنة المصرَّح بها، وتصنيف المخاطر)
• بيانات معاملات النقود المحمولة من Daraja API أو Airtel Money API

وصف بنية التكامل

تشغّل خدمة استيعاب البيانات في منصة مكافحة غسل الأموال مهمة مجدولة تستعلم من API النظام المصرفي الأساسي على فترات قابلة للضبط. فتُجري الخدمة المصادقة، وتطلب المعاملات منذ الطابع الزمني لآخر استطلاع ناجح، وتطابق حقول الاستجابة مع نموذج المعاملات الداخلي (مع توحيد صيغ التواريخ، وتنسيق المبالغ، وتحويل الرموز، ومطابقة الكيانات)، ثم تكتب السجلات الموحَّدة في مخزن المعاملات. وتُعاد محاولة استدعاءات API الفاشلة مع تراجع أُسّي (exponential backoff)، وتُسجَّل مع السياق الكامل للخطأ ليطّلع عليها فريق العمليات.

---

أسلوب التكامل 2: نقل الملفات عبر SFTP

آلية العمل

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

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

صيغ الملفات المدعومة

CSV (القيم المفصولة بفواصل) هي الصيغة الأكثر شيوعًا لمستخرجات T24 وFinacle. وتحدد عناوين الأعمدة في الصف الأول مطابقة الحقول. وتطابق إعدادات الاستيعاب في منصة مكافحة غسل الأموال أسماء أعمدة CSV مع حقول نموذج البيانات الداخلي، وتطبّق قواعد التحويل.

الملفات المفصولة بالخط العمودي شائعة في صادرات COB (إقفال يوم العمل) في T24، ولا سيما في تثبيتات T24 الأقدم. فاستخدام حرف الخط العمودي (|) فاصلًا يتجنب الالتباس مع الفواصل التي قد ترد في الحقول النصية مثل أوصاف المعاملات.

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

الجدولة والتوقيت

التكامل عبر SFTP دفعيٌّ بطبيعته. والجدول القياسي هو مستخرَج في نهاية اليوم يغطي جميع المعاملات منذ المستخرَج السابق. وفي مراقبة حد الإبلاغ عن المعاملات النقدية (CTR)، تكون المعالجة الدفعية في نهاية اليوم ممكنة لكنها تضيّق الهامش الزمني: فالموعد النهائي للتقديم يوم الجمعة من الأسبوع يعني أن معاملة يوم الاثنين يجب كشفها ومراجعتها واعتمادها وتقديمها خلال أربعة أيام عمل، ومعاملة يوم الخميس خلال يوم واحد. ويُعدّ SFTP في نهاية اليوم مقبولًا للمؤسسات ذات مسارات عمل الامتثال الناضجة، لكن تعدد المستخرَجات خلال اليوم — أو الانتقال إلى الاستيعاب عبر API — يقلل تقليلًا ملموسًا خطر تفويت المواعيد النهائية.

وبالنسبة إلى المؤسسات التي تحتاج إلى كشف بلوغ الحد خلال اليوم (لتحديد المعاملات النقدية البالغة ما يعادل 15,000 دولار أمريكي أو أكثر فور قيدها)، يمكن ضبط مستخرَج إضافي خلال اليوم، عادةً عند منتصف النهار. وتدعم بعض الأنظمة المصرفية الأساسية مستخرَجات تُطلَق على فترات قابلة للضبط خلال اليوم.

الأسلوب الأكثر انتشارًا في T24 وFinacle

الاستخراج عبر SFTP هو إلى حد بعيد أسلوب التكامل الأوسع انتشارًا في القطاع المصرفي في شرق أفريقيا. ومزاياه: البساطة، والشمول (إذ تدعمه جميع الأنظمة المصرفية الأساسية)، وانعدام الاعتماد على توافر طبقة API في النظام المصرفي الأساسي، ونضج الأدوات المتاحة لمراقبة SFTP ومعالجته.

والمؤسسات التي لا تملك وصولًا فوريًا إلى موارد إعداد T24 API Server، أو التي لم تحصل بعد على ترخيص Finacle Connect Gateway، يمكنها تنفيذ التكامل عبر SFTP بإعداد تقرير قياسي وبيانات اعتماد SFTP — وهي مهام تستطيع معظم فرق عمليات تقنية المعلومات إنجازها دون موارد تطوير متخصصة.

الأمان: بروتوكول SFTP، والمصادقة بالمفاتيح، والملفات المشفّرة

يوفّر SFTP (بروتوكول نقل الملفات عبر SSH) تشفيرًا قويًا على مستوى طبقة النقل، بخلاف بروتوكول FTP القديم الذي ينقل البيانات نصًا صريحًا. وتلغي المصادقة القائمة على مفاتيح SSH المخاطر الأمنية المرتبطة بكلمات المرور. وينبغي تشفير ملفات مستخرَجات المعاملات التي تحتوي على بيانات العملاء تشفيرًا إضافيًا أثناء التخزين باستخدام PGP أو AES-256 قبل إيداعها في خادم SFTP، على أن تفك منصة مكافحة غسل الأموال تشفيرها بعد التنزيل. ويضمن هذا الأمان متعدد الطبقات ألا تكون ملفات بيانات المعاملات قابلة للقراءة دون مفتاح فك التشفير، حتى لو اختُرقت بيانات اعتماد SFTP.

---

أسلوب التكامل 3: الاستيراد من ملفات CSV/Excel

حالة الاستخدام

يُوفَّر الاستيراد اليدوي من ملفات CSV/Excel أسلوبَ تكامل احتياطيًا للمؤسسات التي تفتقر إلى البنية التحتية أو موارد تقنية المعلومات اللازمة للتكامل الآلي عبر API أو SFTP. ويناسب ذلك بوجه خاص جمعيات SACCO (جمعيات الادخار والائتمان التعاونية) الأصغر، ومؤسسات التمويل الأصغر من الفئة 3، والبنوك المجتمعية التي قد لا يكون لديها موظفون مخصصون لعمليات تقنية المعلومات.

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

صيغة النموذج القياسي

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

التحقق من البيانات عند الاستيراد

يطبّق مسار الاستيراد عمليات التحقق نفسها من جودة البيانات التي تطبّقها مسارات الاستيعاب الآلية:

• التحقق من صيغة التاريخ وتوحيدها
• التحقق من صيغة المبلغ (رقمي، بخانتين عشريتين)
• كشف المعاملات المكررة (توسم المعاملات الموجودة أصلًا في النظام وتُتخطّى)
• فحص وجود الحقول الإلزامية
• التحقق من صيغة رقم الحساب
• فحص حقول هوية العميل

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

القيود

للاستيراد اليدوي من ملفات CSV/Excel قيدان مهمان مقارنةً بالتكامل الآلي:

الأول: أنه يُطلَق يدويًا. فعلى مسؤول الامتثال أن يتذكر إجراء الاستيراد وفق الجدول الصحيح. وتعني عمليات الاستيراد الفائتة وجود ثغرات في بيانات المعاملات التي تغذي مراقبة حد الإبلاغ وتصنيف المخاطر، مما قد يؤدي إلى تفويت تقارير CTR.

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

ولهذه الأسباب، ينبغي التعامل مع الاستيراد من ملفات CSV/Excel بوصفه أسلوبًا انتقاليًا ريثما يُنفَّذ التكامل الآلي، لا بوصفه بنية تكامل دائمة للمؤسسات ذات التزامات الإبلاغ الكبيرة.

---

تكامل بيانات النقود المحمولة

M-PESA Daraja API

توفّر Daraja API من M-PESA (منصة Safaricom لواجهات API المخصصة للمطورين) إمكانية الوصول إلى بيانات معاملات M-PESA للشركات المسجَّلة. وبالنسبة إلى البنوك التي لديها تكامل مع خدمتَي Pay Bill أو Buy Goods من M-PESA، توفّر واجهة Daraja C2B API (من العميل إلى الشركة) إشعارات بالمعاملات في الوقت الفعلي على شكل استدعاءات HTTP راجعة (callbacks) عندما يُجري العميل دفعة.

ولأغراض مراقبة حدود الإبلاغ في مكافحة غسل الأموال، فإن نقاط نهاية Daraja ذات الصلة هي:

• C2B API: تتلقى إشعارات في الوقت الفعلي بمدفوعات M-PESA إلى رقم Pay Bill الخاص بالبنك
• Account Balance API: تستعلم عن الرصيد الحالي لرمز Pay Bill مختصر (short code) محدد
• Transaction Status API: تستعلم عن حالة معاملة M-PESA محددة بواسطة معرّف المعاملة الفريد

وتستخدم Daraja API المصادقة بمفتاح المستهلك وسرّه (consumer key/secret) في OAuth 2.0. وتُسجِّل منصة مكافحة غسل الأموال نفسها عنوان URL لاستدعاءات C2B الراجعة لتلقي إشعارات الدفع في الوقت الفعلي، وتوحّد بيانات معاملات M-PESA (رقم MSISDN، والمبلغ، ومعرّف المعاملة، والطابع الزمني، ومرجع الحساب) وفق نموذج المعاملات الداخلي، وتُدرجها في مسار مراقبة حدود الإبلاغ نفسه الذي تمر به معاملات الفروع وأجهزة الصراف الآلي.

Airtel Money API

توفّر واجهة API من Airtel Money وظائف مماثلة لما يوفّره Daraja من M-PESA للبنوك التي لديها تكامل تجاري مع Airtel Money. فنموذج المصادقة ونمط الاستدعاءات الراجعة متشابهان، مع اصطلاحات تسمية للحقول خاصة بـ Airtel تتطلب مطابقتها مع نموذج البيانات الموحَّد في منصة مكافحة غسل الأموال.

T-Kash (من شركة Telkom Kenya)

توفّر T-Kash وصولًا إلى واجهات API للمطورين لأغراض التكامل التجاري، وإن كانت حصتها السوقية أصغر بكثير من حصة M-PESA. ويمكن للبنوك التي لديها حسابات تجارية في T-Kash دمج بيانات معاملات T-Kash عبر طبقة API التجارية الخاصة بها.

المراقبة عبر القنوات لكشف حالات CTR وSTR

المتطلب الحاسم في تكامل النقود المحمولة هو أن تُقيَّم معاملات M-PESA في مسار الكشف نفسه الذي تمر به المعاملات النقدية في الفروع، وعمليات السحب من أجهزة الصراف الآلي، وكل قناة أخرى تنقل أموال العملاء. فالمعاملات النقدية في الفروع وأجهزة الصراف الآلي تُختبر كلٌّ منها على حدة مقارنةً بحد الإبلاغ عن المعاملات النقدية (CTR) البالغ ما يعادل 15,000 دولار أمريكي؛ أما النقود المحمولة فطبّق عليها المعالجة التي أكدتها مع FRC، لأن أيًّا من POCAMLA ولوائح عام 2023 والتعميم رقم 4 لعام 2023 الصادر عن FRC لا يتناول هذه المسألة. وبالتوازي، يغذّي النشاطُ الذي يقل عن الحد عبر القنوات المختلفة مراقبةَ أنماط التجزئة التي تُفضي إلى حالات STR. ويتطلب كلا المسارين طبقة موحّدة لهوية العميل تربط رقم MSISDN الخاص بالعميل في M-PESA بمعرّف العميل ورقم حسابه في النظام المصرفي الأساسي.

ومطابقة الهوية هي العنصر الأصعب تقنيًا: فحساب العميل في M-PESA يُعرَّف برقم هاتفه المحمول، في حين يُعرَّف حسابه في النظام المصرفي الأساسي برقم الحساب ومعرّف العميل. وتحتفظ منصة مكافحة غسل الأموال بجدول إسناد ترافقي للعملاء يربط أرقام MSISDN بمعرّفات العملاء، ويُملأ من سجلات KYC لدى البنك. ويتيح هذا الإسناد الترافقي تحديد هوية العميل بصورة متسقة عبر جميع قنوات المعاملات.

---

مطابقة البيانات — من حقول النظام المصرفي الأساسي إلى مخطط goAML

يبيّن الجدول التالي مطابقة الحقول من المستخرَج القياسي للمعاملات في Temenos T24 إلى عناصر goAML XML، بما في ذلك التحويل المطلوب لكل حقل.

---

لا حاجة إلى أي تغييرات في نظامك المصرفي الأساسي

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

وقد صُمم تكامل منصة مكافحة غسل الأموال ليكون للقراءة فقط بالكامل. فالمنصة تستعلم عن بيانات المعاملات لكنها لا تكتب أبدًا في النظام المصرفي الأساسي. ولا يلزم أي إجراءات مخزنة (stored procedures) أو مشغّلات (triggers) أو تغييرات في مخطط قاعدة بيانات النظام المصرفي الأساسي. ولا تُثبَّت أي برامج وكيلة (agents) أو عمليات خلفية على خوادم النظام المصرفي الأساسي. فالتكامل تدفق للبيانات في اتجاه واحد: من النظام المصرفي الأساسي إلى منصة مكافحة غسل الأموال.

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

نهج محايد تجاه المورّدين

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

ويعني هذا النهج المحايد تجاه المورّدين أنه إذا غيّر البنك نظامه المصرفي الأساسي، تُحدَّث إعدادات التكامل في منصة مكافحة غسل الأموال بدلًا من إعادة بنائها من الصفر. وتظل وظيفة الامتثال عاملةً أثناء عمليات ترحيل النظام المصرفي الأساسي.

الجدول الزمني للتنفيذ

يُستكمل التكامل مع النظام المصرفي الأساسي عادةً في غضون 1 إلى 2 أسبوع، ضمن تنفيذ قياسي لمنصة مكافحة غسل الأموال يستغرق من 6 إلى 8 أسابيع. وتتطلب مرحلة ضبط التكامل مشاركة فريق تقنية المعلومات المسؤول عن النظام المصرفي الأساسي في البنك (لتأكيد أسماء الحقول وصيغها وترتيبات الوصول عبر SFTP أو API)، وتُستكمل عادةً خلال أيام قليلة من انطلاق المشروع. ويغطي باقي وقت التنفيذ الاختبارات، والتحقق من جودة البيانات، وتدريب فريق الامتثال، وإعداد بوابة وحدة المعلومات المالية.

---

اتخذ الخطوة التالية

تتضمن منصة goAML من Creodata لتقارير مكافحة غسل الأموال طبقة مرنة لاستيعاب البيانات تدعم REST API وSFTP والاستيراد من ملفات CSV/Excel لجميع الأنظمة المصرفية الأساسية الرئيسية في شرق أفريقيا. وقد أنجز فريق التكامل لدينا عمليات تكامل مع Temenos T24 وInfosys Finacle وOracle FlexCube وMambu، ومع إعدادات متعددة لـ M-PESA وAirtel Money — مع مكتبات موثَّقة لمطابقة الحقول لكلٍّ منها.

ناقش متطلبات تكامل نظامك المصرفي الأساسي مع فريقنا: اطلب عرضًا توضيحيًا عبر creodata.com/demo