Blog / Global Digital Vibes

ClefinCode - Core Banking ERP الجزء الثالث – العملاء، الإعداد، المخاطر والامتثال

يجب على منصات (Core Banking) الحديثة أن تدمج إدارة العملاء، والإعداد (Onboarding)، وإدارة المخاطر، والامتثال بشكل متكامل وسلس كقدرات أساسية.

October 15, 2025 · 59 min read

1. الموجز الاستراتيجي العام

يجب على منصات (Core Banking) الحديثة أن تدمج إدارة العملاء، والإعداد (Onboarding)، وإدارة المخاطر، والامتثال بسلاسة كقدرات أساسية، وليس كأفكار لاحقة. في عصر تتسم فيه اللوائح بالصرامة وجرائم التمويل بالتعقيد، أصبحت قدرة البنك على إدارة بيانات العملاء والمخاطر في الوقت الفعلي ميزة استراتيجية. تؤكد الأنظمة مثل (IFRS 9) و(Basel III/IV) هذا التحول: حيث نقل (IFRS 9) البنوك من نموذج الخسائر المتحققة التفاعلي إلى نموذج الخسارة الائتمانية المتوقعة (ECL) الاستشرافي، مما جعل المحاسبة تتماشى مع إدارة المخاطر الاستباقية [1]. وفي المقابل، تضمن معايير (Basel) أن تحتفظ البنوك برأسمال كافٍ مقابل المخاطر، مما يدفع المؤسسات إلى تضمين تقييم المخاطر ضمن عملياتها اليومية [1]. وباختصار، يعزز كلا الإطارين التنظيميين مرونة البنوك من خلال اشتراط وجود بيانات قوية حول التعرضات الائتمانية والمخاطر في جميع الأوقات، مما يجعل الامتثال وسيلة لتعزيز الاستقرار وليس مجرد التزام.

الامتثال المرتكز على العميل: وضع العميل في المركز لا يعني فقط إدارة علاقات أفضل عبر (CRM) – بل يعني جمع وإدارة رؤية شاملة بزاوية 360 درجة لهوية كل عميل، وعلاقاته، وملف المخاطر الخاص به. يُعدّ النمذجة الفعالة للعملاء أو الأطراف (الأفراد، الشركات، المالكين المستفيدين، الأطراف المرتبطة، إلخ) أمرًا أساسيًا. استراتيجيًا، يعني ذلك التعامل مع عمليات اعرف عميلك (KYC) والعناية الواجبة كأولوية قصوى. فالإخفاق في (KYC/AML) لا يؤدي فقط إلى غرامات ضخمة وأضرار سمعة، بل قد يشل البنك تمامًا إذا استغل المجرمون نقاط الضعف [2]. لذلك، يجب على الإدارة العليا اعتبار الاستثمارات في الامتثال (مثل أنظمة التحقق الآلي من (KYC)، وأنظمة فحص العقوبات، وتدريب الموظفين) بمثابة حماية لرخصة البنك في العمل. يضمن نظام العناية الواجبة بالعميل (CDD) المتكامل مع عملية الإعداد أن يتم التحقق من كل عميل جديد وتقييم مخاطره والموافقة عليه وفقًا للمعايير العالمية – من فحص العقوبات والأشخاص المعرضين سياسيًا (PEP) إلى الامتثال الضريبي مثل (FATCA/CRS). تضمن هذه العمليات نزاهة البنك وتمنعه من أن يكون قناة للأنشطة غير المشروعة [2].

تجربة الإعداد مقابل ضوابط المخاطر: غالبًا ما يُنظر إلى وجود تعارض بين تجربة إعداد عميل سلسة وبين ضوابط الامتثال الصارمة. ومع ذلك، يمكن مواءمة هذه الأهداف استراتيجيًا. من خلال الاستفادة من الأتمتة والذكاء الاصطناعي (مثل التعرف البصري على المستندات (OCR)، والتحقق البيومتري من الهوية، والإعداد الموجه عبر (chatbot))، يمكن للبنوك تحقيق إعداد مباشر وسريع (Straight-through onboarding) للعملاء منخفضي المخاطر، مع تحويل الحالات عالية المخاطر إلى مراجعة يدوية. يضمن هذا النهج القائم على المخاطر توجيه موارد العناية الواجبة نحو ما هو أكثر أهمية [3]. النتيجة النهائية هي إعداد أسرع للعملاء الموثوقين (مما يعزز رضا العملاء) مع فحص دقيق حيثما يلزم (لإرضاء الجهات التنظيمية). فعلى سبيل المثال، يمكن لبنك رقمي أن يسمح لعميل جديد بمسح بطاقة هويته وصورته الذاتية للتحقق الفوري من الهوية، مع مطابقة اسمه تلقائيًا مع قوائم العقوبات والأشخاص المعرضين سياسيًا (PEP)، وجمع إقرار (FATCA) الذاتي – كل ذلك خلال دقائق. وفقط إذا ظهرت مشاكل (مثل تطابق الاسم في قوائم العقوبات أو انتماء العميل لدولة عالية المخاطر) تُحال العملية إلى مسؤولي الامتثال لإجراء العناية الواجبة المعززة (EDD). هذا النوع من الإعداد المدعوم بالذكاء الاصطناعي والمستند إلى تصنيف المخاطر يحسن الكفاءة ويقلل من فرص الخطأ البشري أو الإغفال.

إدارة المخاطر كعملية مستمرة: قبول العميل وفتح الحسابات هو مجرد البداية – إدارة المخاطر هي دورة حياة مستمرة. من الناحية الاستراتيجية، تحتاج البنوك إلى مراقبة المخاطر الائتمانية ومخاطر الجرائم المالية بشكل مستمر طوال علاقة العميل مع البنك. وهذا يعني أنه يجب تتبع التعرضات الائتمانية وإعادة تقييمها دوريًا (للكشف عن مؤشرات التدهور أو مخاطر التركّز)، كما يجب فحص المعاملات في الوقت الفعلي لاكتشاف الأنماط المشبوهة. في تصميم أنظمة (Core Banking)، يجب أن تغذي أنظمة القيود والمعاملات محرك مخاطر مركزي يعيد حساب مقاييس مثل احتمال التعثر (PD)، والتغيرات في درجة الائتمان أو سلوك الحساب، ودرجات مخاطر (AML) مع وصول بيانات جديدة. تتطلب الأطر التنظيمية ذلك: إذ يُلزم (IFRS 9) بإعادة تصنيف التعرضات الائتمانية (من المرحلة 1 إلى 2 أو 3) إذا زادت المخاطر الائتمانية بشكل كبير، مما يستدعي تكوين مخصصات خسائر أكبر [4]. وبالمثل، تتطلب لوائح (AML) المراقبة المستمرة – فلا يمكن الاكتفاء بسياسة “اعرف عميلك مرة واحدة وانسَ الأمر”. يجب أن تضمن الخطط الاستراتيجية أن الأنظمة تُبلغ عن الأنشطة غير المعتادة (مثل تحويل كبير مفاجئ من عميل منخفض النشاط عادةً، أو عدة إيداعات صغيرة قد تشير إلى عملية هيكلة) للمراجعة في الوقت شبه الحقيقي [2]. من خلال دمج التنبيهات المعتمدة على الأحداث وإعادة تقييم المخاطر الدورية، يبقى البنك متقدمًا على المشكلات – حيث يحدد القروض المتعثرة مبكرًا (مما يحسن التحصيل ويقلل الخسائر) ويكتشف إشارات الاحتيال المالي قبل تفاقمها.

الامتثال كميزة تنافسية: رغم أن الامتثال يُنظر إليه غالبًا كمركز تكلفة، فإن الاستراتيجية الحديثة لأنظمة (Core Banking) تعتبره ميزة تنافسية. فالبنك المعروف بسرعة الإعداد الرقمي مع أمان قوي سيجذب العملاء الموثوقين ويعزز الثقة. وعلى العكس، فإن البنك الذي يفشل في الامتثال يواجه غرامات وأضرار سمعة تؤدي إلى خسارة العملاء. إن تنفيذ ضوابط قوية لأمن البيانات والخصوصية (التشفير، ضوابط الوصول، العمليات المتوافقة مع (GDPR) للموافقة والحذف) يحمي المعلومات الشخصية للعملاء ويعزز الثقة. تمنح قوانين خصوصية البيانات في جميع أنحاء العالم (مثل (GDPR) في الاتحاد الأوروبي) العملاء حقوقًا على بياناتهم – ويجب أن تكون البنوك جاهزة للاستجابة من خلال أنظمة لاسترجاع أو حذف بيانات العملاء عند الطلب (ضمن حدود الاحتفاظ القانونية) [4]. من الناحية الاستراتيجية، فإن التوافق مع المعايير مثل (ISO 27001) لأمن المعلومات و(SOC 2) للضوابط التشغيلية يبعث برسالة إلى الجهات التنظيمية والعملاء بأن البنك يلتزم بأعلى المعايير. يُعد نهج شركة (ClefinCode) في تقديم خدمات سحابية متوافقة مع (ISO 27001) و(SOC 2) مثالًا بارزًا: فهي تستفيد من استثمار البنية التحتية السحابية في الأمان لتلبية متطلبات الجهات التنظيمية ومتطلبات العناية الواجبة للمؤسسات العميلة المحتملة [5].

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

2. الهيكلية التفصيلية للتنفيذ

نموذج بيانات العميل/الطرف وإدارة العلاقات

يُعد نموذج بيانات العميل (الطرف) القوي حجر الأساس للامتثال وإدارة العملاء في نظام (Core Banking). بالاعتماد على النموذج المرجعي المقدم في الجزء الثاني، نقوم بتوسيع مفهوم “العميل” ليشمل خصائص وعلاقات أكثر عمقًا ضرورية للامتثال المصرفي. في التطبيق العملي، يمكن أن يكون العميل فردًا أو مؤسسة، ويُحدد النظام النوع وفقًا لذلك (على سبيل المثال: client_type = Individual or Corporate). يحتوي كل سجل عميل على معلومات (KYC) (تفاصيل الهوية، العناوين، بيانات الاتصال) وبيانات وصفية للمخاطر (درجة المخاطر، مستوى العناية الواجبة، إلخ). إلى جانب السمات الأساسية، يجب أن يمثل النظام العلاقات المعقدة: فمثلًا، قد يكون لدى العميل من نوع شركة عدة مالكين مستفيدين (أشخاص يمتلكون أو يتحكمون فعليًا بالكيان)، بالإضافة إلى مديرين ومفوضين بالتوقيع وشركات أم وأطراف مرتبطة أخرى. هذه العلاقات ضرورية لكل من الامتثال وتقييم المخاطر. على سبيل المثال، إذا كان أحد الأفراد يمتلك 30% من شركة ما، فإن ملف مخاطر هذا الفرد (إذا كان من الأشخاص المعرضين سياسيًا (PEP) أو مدرجًا في قائمة عقوبات) يمكن أن “يؤثر” على تصنيف مخاطر الشركة [3]. لذلك، يتضمن نموذج البيانات جدول ارتباط (مثل علاقة العميل أو الملكية) يمكنه ربط عميل بآخر مع تحديد نوع العلاقة وخصائصها (مثل نسبة الملكية، أو الدور مثل مدير، ضامن، زوج/زوجة، إلخ).

لتوضيح ذلك، انظر إلى مخطط العلاقات الكيانية أدناه. نميز بين (Person) و(Organization) كأنواع فرعية من (Client) لتوضيح روابط الملكية المستفيدة. يربط كيان Ownership الأفراد بالمؤسسات التي يمتلكونها، بينما يلتقط كيان Relationship الروابط الأخرى (مثل أن يكون شخص ضامنًا لقرض شخص آخر، أو أن يكون بين عميلين علاقة إحالة):


erDiagram
    Person ||--o{ Account : holds
    Organization ||--o{ Account : holds
    Person ||--o{ Ownership : "is beneficial owner of"
    Ownership ||--|| Organization : "belongs to"
    Person ||--o{ Relationship : "has relationship"
    Organization ||--o{ Relationship : "has relationship"

الشكل: نموذج بيانات الطرف المبسط. يمكن لكل شخص (Person) أو مؤسسة (Organization) (كلاهما عملاء) أن يمتلك عدة حسابات. تشير علاقة Ownership إلى أن شخصًا ما هو مالك مستفيد لمؤسسة (مع تفاصيل مثل نسبة الملكية المخزنة في سجل الملكية). يتيح الكيان العام Relationship تمثيل الروابط الأخرى (مثل علاقة بين شخصين أو بين شخص ومؤسسة بأدوار مثل ضامن، مدير، أو فرد من العائلة). يضمن هذا الهيكل المرن إمكانية تمثيل الشبكات والعلاقات المعقدة بين العملاء. وتزداد أهمية هذا المنظور الشبكي – حيث تستخدم الجهات التنظيمية والبنوك تحليلات الرسوم البيانية لاكتشاف العلاقات الخفية مثل الملكية الدائرية أو السيطرة المشتركة عبر العملاء [6][7]. من خلال تسجيل هذه الروابط في البيانات الأساسية، تمكّن منصتنا من إجراء تحليل موحد للمخاطر – مثل تجميع التعرضات لمجموعة من العملاء المرتبطين، أو الإشارة إذا كان عميلان منفصلان ظاهريًا يشتركان في مالك مستفيد عالي المخاطر.

يتضمن تنفيذ ذلك في (ERPNext) إنشاء (DocTypes) مخصصة مثل: Client (لتوسيع (Customer/Supplier Doctype) القياسي بإضافة حقول مصرفية)، وClient Relationship، وربما جداول فرعية منفصلة مثل Individual Client وCorporate Client أو حقل للتمييز بينهما. كما نحافظ على سلامة المراجع – على سبيل المثال، يجب أن يشير سجل الملكية إلى مؤسسة واحدة (الهدف) وشخص واحد (المالك). يجب على النظام أن يفرض تسجيل المالكين المستفيدين النهائيين (UBOs) لكل عميل من نوع شركة حتى الحد المطلوب (مثل جميع الأفراد الذين يمتلكون 10٪ أو أكثر). يتماشى هذا مع معايير (AML/KYC) العالمية: فعند إعداد شركة جديدة، يجب على البنوك جمع معلومات المالكين المستفيدين (الأسماء، أرقام الهوية، إلخ) للملاك الرئيسيين [2]. يدعم نموذج البيانات ذلك من خلال السماح بوجود سجلات متعددة للمالكين لكل كيان، بحيث يرتبط كل سجل بشخص عميل. أثناء الاستخدام، يمكن لوحدة الامتثال تقييم هذه البيانات تلقائيًا: فمثلًا، إذا كان أحد المالكين المستفيدين شخصًا خاضعًا للعقوبات، يتم وضع علامة على العميل من نوع الشركة (لأن سجل الشخص في النظام يحمل حالة العقوبات).

بالإضافة إلى الملكية، يمكن لجدول Client Relationship أن يسجل، على سبيل المثال، أن الشخص A هو مدير في الشركة B، أو أن الشخص C هو زوج/زوجة الشخص D. يمكن أن تحتوي كل علاقة على نوع وربما مؤشر مدى صلتها بالمخاطر. على سبيل المثال، إذا فتح قريب لشخص معرض سياسيًا (PEP) حسابًا، تتطلب العديد من اللوائح معاملتهم على أنهم ذوو مخاطر عالية أيضًا (حيث يُعتبر المقربون من PEP ذوي مخاطر مرتفعة) [3]. من خلال نمذجة مثل هذه العلاقات، يمكن للنظام تطبيق المعالجة الصحيحة للمخاطر تلقائيًا. ورغم أن نموذج البيانات العلائقي هذا أكثر تعقيدًا من قائمة عملاء مسطحة، إلا أنه يعزز بشكل كبير قدرتنا على تنفيذ التقييمات الائتمانية للمخاطر وعمليات التحقق من الامتثال عبر شبكة من الأطراف المرتبطة – وهو أمر ضروري في القطاع المصرفي الحديث حيث تنتشر الشركات الوهمية والهياكل المعقدة للملكية في عمليات غسل الأموال [3].

عمليات الإعداد: (KYC)، (CDD/EDD)، (FATCA/CRS)، وتكامل مكاتب الائتمان

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

على المستوى العام، يتبع سير الإعداد أفضل الممارسات المعتمدة في القطاع [2][2]:

برنامج تعريف العميل (CIP): تُعد هذه الخطوة الأولى حيث يتم التحقق من هوية العميل. يقوم النظام بجمع البيانات الشخصية – الاسم الكامل، تاريخ الميلاد، العنوان، رقم الهوية الرسمي (مثل جواز السفر أو الهوية الوطنية)، وبالنسبة للشركات، تفاصيل التسجيل (اسم الشركة، رقم التأسيس، إلخ) [2]. يتم تحميل المستندات مثل بطاقات الهوية أو جوازات السفر أو شهادات التسجيل. هنا نقوم بدمج خدمات التحقق من المستندات (عبر واجهات برمجة التطبيقات API) للتحقق من صحة الهويات وتنفيذ اختبارات الحيوية (Liveness Checks) للصور الذاتية عند الحاجة. في الوقت نفسه، يقوم النظام بفحص فوري للأسماء في قوائم العقوبات العالمية وقواعد بيانات (PEP) [2]. وهذا أمر بالغ الأهمية: قبل إنشاء الحساب، نضمن أن مقدم الطلب غير مدرج في أي قائمة محظورة (مثل قائمة (OFAC SDN) أو عقوبات الأمم المتحدة)، ونحدد ما إذا كان شخصًا معرضًا سياسيًا. ستستخدم منصتنا إما قاعدة بيانات داخلية يتم تحديثها يوميًا أو خدمة خارجية عبر واجهة برمجة تطبيقات للامتثال لإجراء عمليات الفحص الخاصة بالعقوبات و(PEP). إذا تم العثور على تطابق أو تطابق محتمل، يتم إيقاف عملية الإعداد للمراجعة اليدوية (أو رفضها تلقائيًا إذا تم تأكيد التطابق الحقيقي مع قائمة العقوبات وفق السياسة). بالنسبة للعملاء الأفراد، يتضمن (CIP) أيضًا التحقق من العنوان المقدم (ربما من خلال تحميل فاتورة خدمات أو فحص إلكتروني)، وبالنسبة للشركات، جمع تفاصيل المالكين المستفيدين النهائيين (UBO) كما أُشير سابقًا. في الواقع، تتطلب اللوائح جمع أسماء ومعلومات (UBO) لأي عميل من نوع كيان [2]. سيحتوي نموذج الإعداد للشركات على حقول لإدخال المالكين الذين تتجاوز نسبهم الحد الأدنى، وسترتبط هذه البيانات بالنموذج الموضح سابقًا.
العناية الواجبة بالعميل (CDD): بعد تأكيد الهوية الأساسية، ينتقل النظام إلى (CDD) – الذي يتضمن جمع معلومات إضافية لتقييم الملف الائتماني والمخاطر للعميل [2]. يتضمن ذلك فهم طبيعة عمل العميل أو نشاطه التجاري، النشاط المتوقع للحساب، مصدر الأموال، والغرض من الحساب. قد يقدم سير العمل استبيانًا (خاصة للشركات: نوع الصناعة، الدول التي تعمل فيها، حجم المعاملات المتوقع، إلخ). تُغذى المعلومات المجمعة في نموذج تقييم المخاطر الأولي. على سبيل المثال، العميل الذي يفتح حسابًا بقيمة عالية أو من دولة عالية المخاطر أو يعمل في صناعات تعتمد على النقد (كالكازينوهات أو خدمات تحويل الأموال) سيُمنح تصنيف مخاطر أعلى. يستخدم النظام محركًا قائمًا على القواعد (مع إمكانات ذكاء اصطناعي) لتحديد تقييم المخاطر (منخفض، متوسط، مرتفع) استنادًا إلى البيانات والفحوصات المنفذة [3]. يمكن للعملاء منخفضي المخاطر (مثل موظف محلي براتب ثابت وإيداعات صغيرة) المضي قدمًا بالعناية الواجبة القياسية، بينما يتطلب العملاء ذوو المخاطر المتوسطة أو العالية خطوات إضافية.
العناية الواجبة المعززة (EDD): إذا أظهر تقييم المخاطر أن العميل عالي المخاطر (أو بناءً على عوامل مثل كونه (PEP)، أو لديه ملكية معقدة، أو من دولة عالية المخاطر، إلخ)، ينتقل الإعداد إلى مسار فرعي (EDD) [3]. قد تتضمن العناية الواجبة المعززة طلب مستندات إضافية (مثل إثبات مصدر الثروة، أو البيانات المالية للشركات)، أو المزيد من التحقق (رسائل توصية، مقابلات شخصية)، أو موافقة الإدارة العليا قبل فتح الحساب. سيقوم النظام بإنشاء مهمة لموظفي الامتثال لتنفيذ هذه الفحوصات. يمكن تخصيص معايير (EDD): على سبيل المثال، الكيان الذي يملك هيكل ملكية معقد (طبقات متعددة أو صناديق ائتمانية) سيتم وضع علامة عليه، وكذلك الفرد الذي هو قريب لشخص (PEP) [3]. يتم تتبع معالجة (EDD) داخل النظام (بقائمة تحقق للخطوات الإضافية المنفذة) لضمان عدم إغفال أي متطلبات.
الامتثال لـ (FATCA/CRS): بالتوازي مع (KYC)، يجب أن تتضمن عملية الإعداد جمع بيانات التقارير الضريبية. يتطلب قانون (FATCA) (قانون الامتثال الضريبي للحسابات الأجنبية) تحديد الأشخاص الأمريكيين (المواطنين الأمريكيين أو المقيمين الضريبيين) والإبلاغ عن تفاصيل حساباتهم إلى (IRS) عبر الهيئة المحلية. أما (CRS) (المعيار المشترك للإبلاغ)، فيلزم بجمع معلومات الإقامة الضريبية للعملاء من أي من الدول المشاركة. تتضمن نماذج الإعداد لدينا أسئلة للإقرار الذاتي مثل: “هل أنت مواطن أو مقيم ضريبي في الولايات المتحدة؟” و“يرجى ذكر جميع دول الإقامة الضريبية وأرقام التعريف الضريبي”. بالنسبة للكيانات، نقوم بجمع رقم (GIIN) (رقم التعريف الوسيط العالمي) إذا كان ذلك ممكنًا أو على الأقل حالة (FATCA) (مثل ما إذا كان الكيان “شخصًا أمريكيًا محددًا” أم لا). يجب على النظام تخزين هذه البيانات وأن يكون قادرًا على إنشاء تقارير (XML) المطلوبة لاحقًا. يُعد جمع البيانات بدقة أثناء الإعداد أمرًا حيويًا – إذ إن أساس الامتثال لـ (FATCA/CRS) يعتمد على معلومات العميل الدقيقة والكاملة[8]. يمكن أن تؤدي الأخطاء الشائعة مثل نقص أو أخطاء الإقرارات الذاتية إلى أخطاء كبيرة في التقارير [8]، لذا يفرض سير العمل لدينا تعبئة النماذج الضريبية الإلزامية. إذا فشل العميل في تقديم النموذج المطلوب (مثل (W-9) للأشخاص الأمريكيين أو الإقرار الذاتي لـ (CRS) للآخرين)، يجب على النظام إما منع إكمال الإعداد أو وضع الحساب في حالة تقييد. يمكن لنظامنا أيضًا أتمتة التذكيرات للمعلومات الضريبية المفقودة وحتى استخدام تحليل الأنماط لاكتشاف التناقضات (مثل أن يكون مكان الميلاد في أمريكا ولكن الإجابة “لست شخصًا أمريكيًا” – مما يتطلب متابعة).
تكامل مكاتب الائتمان (للمنتجات الائتمانية): إذا تضمنت عملية الإعداد طلبًا ائتمانيًا (مثل قرض أو بطاقة ائتمان)، يتم تنفيذ تكامل مع مكاتب الائتمان في هذه المرحلة أو بعد فتح الحساب مباشرة. فعلى سبيل المثال، عندما يتقدم عميل بطلب قرض، يمكن للنظام سحب تقريره الائتماني أو تقييمه تلقائيًا من المكاتب المحلية (مثل (Experian) أو (TransUnion)) عبر (API). تُغذى هذه المعلومات في عملية الاكتتاب (التي ستُشرح لاحقًا) ولكنها أيضًا تساعد من منظور (KYC) في التحقق من الهوية وفهم السلوك المالي. بالإضافة إلى ذلك، لدى بعض الدول سجلات ائتمان مركزية أو قوائم سوداء من البنك المركزي – يمكن التحقق منها أثناء الإعداد لتجنب فتح حسابات لمحتالين معروفين أو مدينين متخلفين. تستخدم البنية خدمة تكامل (Integration Service) للاتصال الآمن بهذه الأنظمة الخارجية باستخدام بيانات تعريف العميل التي تم جمعها ضمن (CIP). يتم تخزين البيانات المسترجعة بطريقة آمنة (نظرًا لحساسيتها) وتكون مرئية فقط لمسؤولي المخاطر لاتخاذ القرار.
الموافقة وفتح الحساب: بعد اجتياز مراحل (CIP) و(CDD) وأي مرحلة (EDD) مطلوبة، تُحال الطلبات إلى الموافقة النهائية. في العديد من البنوك، قد تكون العملية مؤتمتة للعملاء منخفضي المخاطر (معالجة مباشرة) ويدوية للعملاء ذوي المخاطر العالية. يمكن لنظامنا تعيين إجراء في سير العمل إلى مدير الامتثال أو المشرف لمراجعة المعلومات والفحوصات. إذا كانت جميع البيانات صحيحة، يتم اعتماد العميل. عندها ينشئ النظام الأساسي سجل العميل (إذا لم يكن موجودًا بالفعل) ويفتح الحسابات المبدئية (مثل الحساب الجاري). يؤدي فتح الحساب في النظام إلى إنشاء حسابات الأستاذ العام والحسابات الفرعية وإصدار البطاقات البنكية (إن كانت ضمن المنتج)، كما تم توضيحه في الجزء الثاني من إعداد المنتج. في هذه المرحلة، يمكن إرسال رسائل الترحيب أو بيانات الدخول إلى القنوات الرقمية للعميل.

يتم تنظيم عملية الإعداد بواسطة محرك سير عمل (Workflow Engine) يمكن تمثيله بالمخطط التالي:


flowchart TD
    A[Collect CIP data & documents] --> B[Sanctions & PEP screening]
    B -->|Possible match| F[Manual review for false positives]
    B -->|Clear| C[Automated Risk Scoring (CDD)]
    C -->|High risk| E[Enhanced Due Diligence tasks]
    C -->|Low/Med risk| D[Approval & Account Opening]
    E --> G[Compliance Officer Approval]
    G --> D
    F --> G

الشكل: سير عمل الإعداد المبسط. يقوم النظام أولًا بجمع بيانات ووثائق (CIP) (الخطوة 1)، ثم ينفذ فحص العقوبات و(PEP) الفوري (الخطوة 2). إذا ظهر تطابق مع قائمة، يتم إجراء مراجعة يدوية (F) لتأكيد ما إذا كان تطابقًا حقيقيًا أو تشابه أسماء. إذا اجتاز العميل الفحص، يحسب النظام درجة المخاطر ويحدد مستوى المخاطر بناءً على معلومات (CDD) (الخطوة 3). العملاء منخفضو أو متوسطو المخاطر ينتقلون مباشرة إلى فتح الحساب والموافقة النهائية (D). إذا تم تصنيف العميل عالي المخاطر أو استوفى معايير معينة، يتم تفعيل خطوات العناية الواجبة المعززة (EDD) (الخطوة 4)، مثل جمع مستندات إضافية والحصول على موافقة الامتثال العليا (G) قبل المتابعة. فقط بعد استيفاء جميع الفحوصات يتم اعتماد العميل وفتح حسابه (D). خلال هذا المسار، يتم دمج جمع بيانات (FATCA/CRS) في الخطوة الأولى (لكل العملاء)، بينما تُجرى فحوصات مكاتب الائتمان ضمن مرحلة التقييم الائتماني والمخاطر (للمنتجات الائتمانية).

يجدر بالذكر أن عملية الإعداد هذه لا تقتصر على العملاء الجدد فقط. إذ يمكن للنظام نفسه التعامل مع تحديث (KYC) الدوري (كل 1 إلى 3 سنوات أو عند حدوث مؤشرات)، باستخدام نفس المسار، للحفاظ على تحديث بيانات العميل وإعادة تقييم المخاطر. تدعم البنية حفظ النماذج ونتائج (KYC) مع سجل تدقيق يوضح من قام بالتحقق والموافقة، لتشكيل جزء من أدلة الامتثال الخاصة بالبنك.

من خلال تنفيذ سير الإعداد المذكور أعلاه ضمن نظام قائم على (ERPNext)، نضمن أن الامتثال مدمج ضمن أول نقطة تفاعل مع العميل. يتبع هذا التصميم إرشادات (Thomson Reuters) في خطواتها الخمس لإعداد العملاء ضمن (KYC) [2] (التعريف، العناية الواجبة، العناية الواجبة المعززة، المراقبة المستمرة، التقارير). تغطي الخطوات 1-3 التعريف والعناية الواجبة. وستتناول الأقسام التالية كيفية معالجة الخطوات اللاحقة: المراقبة المستمرة (مراقبة المعاملات) والتقارير (التقارير التنظيمية مثل (SARs)، و(FATCA) وغيرها) بعد تفعيل العميل.

تقييم المخاطر ونمذجة مخاطر الأطراف

يُعد تقييم المخاطر عنصرًا مستمرًا يبدأ من الإعداد (كما هو موضح أعلاه) ويمتد طوال علاقة العميل مع البنك. ينفذ نظامنا محرك تقييم مخاطر (Risk Scoring Engine) لحساب وتحديث درجات المخاطر للعملاء (وأحيانًا للحسابات أو المعاملات الفردية) بناءً على مجموعة من المعايير. هناك عدة أبعاد يجب أخذها بالاعتبار:

تقييم مخاطر (AML/CFT) – تصنيف مخاطر العميل: يُمنح كل عميل تصنيفًا يعكس مخاطر غسل الأموال أو تمويل الإرهاب الخاصة به. يُصنف عادة ضمن منخفض أو متوسط أو مرتفع (بعض البنوك تستخدم درجات أكثر تفصيلًا) [3]. ينتج التصنيف الأولي من عملية (CDD/EDD) أثناء الإعداد (مع الأخذ في الاعتبار نوع العميل، المهنة، الدولة، المنتج، حجم المعاملات، حالة (PEP)، إلخ). يمكن لنظامنا استخدام مصفوفة تقييم حيث يضيف كل عامل وزنًا معينًا. على سبيل المثال، كون العميل من دولة عالية المخاطر يضيف +20 نقطة، وكونه (PEP) يضيف +30، وامتلاكه هيكل ملكية بسيط يضيف 0 نقاط، وهكذا. ينتج المجموع النهائي ضمن نطاق يُترجم إلى منخفض/متوسط/مرتفع. هذا النموذج قابل للتخصيص وفق شهية المخاطر لدى البنك ويمكن تعديله مع تغير اللوائح. والأهم أن النظام لا يعتبر هذا التصنيف ثابتًا – بل يتم تحديثه مع بيانات المراقبة المستمرة. لذلك، يقوم نظامنا بتحديث درجة المخاطر للعميل عند حدوث أي حدث ذي صلة بالمخاطر (معاملة كبيرة، ظهور خبر سلبي، إلخ) أو بمراجعة دورية. يتماشى هذا مع النهج القائم على المخاطر الذي تتطلبه الجهات التنظيمية: “تقييم المخاطر عملية مستمرة” ويمكن أن تتغير مستويات المخاطر حتى للعميل منخفض المخاطر مبدئيًا [3][3].
تقييم مخاطر المعاملات: بالإضافة إلى تصنيف العميل العام، يمكن تقييم المخاطر لكل معاملة على حدة في الوقت الفعلي. تحدد مراقبة (AML) قواعد حيث يتم تعليم بعض المعاملات بمؤشرات مخاطر. على سبيل المثال، قد يتم تقييم تحويل دولي إلى دولة عالية المخاطر وإحالته للمراجعة. يوضح مثال النظام البنكي (Advapay) أهمية تقييم المخاطر لكل معاملة وإمكانية ضبط الإنذارات للمراقبة الدقيقة [9]. نُنفذ قدرات مشابهة: تُعطى كل معاملة تستوفي شروطًا معينة (قيمة عالية، أنماط غير اعتيادية، إلخ) درجة مخاطر أو مستوى خطر. يمكن للنظام بعد ذلك أن يقرر السماح بالعملية أو تعليقها لمراجعة الامتثال أو رفضها بناءً على هذه الدرجة والسياسة المعتمدة.
تقييم/تصنيف المخاطر الائتمانية: بشكل منفصل، للمنتجات الائتمانية، قد يكون لكل مقترض (عميل) تصنيف مخاطر ائتماني – غالبًا درجة داخلية أو احتمال تعثر. يُشبه هذا التقييم الائتماني أو التصنيف الائتماني ويُستخدم في قرارات الائتمان وتصنيف المراحل وفق (IFRS 9). ستتضمن وحدة الائتمان في نظامنا بيانات من مكاتب الائتمان والبيانات المالية وسلوك السداد لتخصيص درجة أو تصنيف ائتماني. رغم اختلاف الأساليب (لأنها تتعلق بالمخاطر المالية لا بمخاطر غسل الأموال)، إلا أن البنية تتعامل معها بنفس الشكل – حقل أو مجموعة حقول مرتبطة بالعميل (أو بكل تسهيل ائتماني) قابلة للتغيير مع الزمن. وتُستخدم هذه البيانات في تكوين مخصصات الخسائر وإدارة الحدود الائتمانية كما سيتم توضيحه لاحقًا.
الملف التعريفي الموحّد للمخاطر: من منظور إدارة المخاطر المؤسسية، قد يجمع البنك بين درجات تقييم المخاطر المختلفة لتكوين ملف شامل للعميل. يدعم نموذج البيانات لدينا تخزين عدة درجات مخاطر (مع تسميات نوعية مثل: AML_RISK_RATING، CREDIT_RATING، إلخ). يمكن للوحة المعلومات عرض رؤية شاملة؛ على سبيل المثال، قد يكون العميل المؤسسي منخفض المخاطر من حيث (AML) (شركة محلية في قطاع منخفض المخاطر) ولكنه عالي المخاطر من حيث الائتمان (بيانات مالية ضعيفة)، أو العكس – قد يكون الفرد الثري منخفض المخاطر الائتمانية لكنه عالي مخاطر (AML) (بسبب كونه شخصية سياسية بارزة). تتمثل وظيفة النظام في تتبع جميع الأبعاد ذات الصلة.

نمذجة العلاقات بين الأطراف لأغراض المخاطر: كما ذُكر سابقًا، تؤثر العلاقات بين العملاء بشكل كبير على المخاطر. يضمن تنفيذنا أن منطق تقييم المخاطر لا ينظر إلى كل عميل بمعزل عن غيره بل يأخذ في الاعتبار علاقاته أيضًا. على سبيل المثال، إذا كان لدى عميل مؤسسي مالك منفعة نهائي (UBO) يُعد شخصية سياسية بارزة (PEP)، فيجب رفع تصنيف مخاطر (AML) للعميل تلقائيًا إلى مرتفع [3]. ننفذ ذلك عبر تمرير سمات المخاطر خلال شبكة العلاقات؛ فمثلاً عند تحديد فرد على أنه (PEP)، يمكن لوحدة الامتثال وسم جميع الكيانات المرتبطة به بأنها مرتبطة بشخص (PEP). وبالمثل، إذا كان الفرد مدرجًا في قائمة العقوبات، فيجب أن يحمل أي حساب يمتلكه (حتى بشكل غير مباشر) نفس الحالة المحظورة (وفي الممارسة، لن يتم فتح حساب لكيان يملك أحد مالكيه النهائيين عقوبة). يمكن للنظام تنفيذ مهام دورية لتحديث ذلك – على سبيل المثال، وظيفة ليلية تجتاز جميع روابط الملكية المؤسسية لضمان أن التصنيفات تعكس أي تغييرات في حالة المالكين. من الناحية التقنية، يمكن تحقيق ذلك عبر استعلامات قاعدة بيانات تربط العملاء بالأطراف المرتبطة بهم لتطبيق التحديثات. كما نأخذ في الاعتبار مخاطر العلاقات ضمن التقييم؛ فامتلاك هياكل ملكية غير شفافة قد يعد بحد ذاته علامة خطر. إذا أظهرت بيانات العلاقات أن الكيان يملك عدة طبقات من الملكية (أو تملكه شركة في ولاية خارجية)، يمكن تهيئة محرك المخاطر لرفع مستوى المخاطر [3] (مثل قاعدة تقول: “إذا تجاوزت طبقات الملكية ثلاث طبقات، صنّف العميل عالي المخاطر”). وبذلك يغذي نموذج البيانات الغني للعلاقات نظام التقييم بمعلومات أكثر دقة.

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

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

إدارة مخاطر الأطراف الخارجية والموردين (المتعهدين، المراسلين، إلخ)

لا تعمل البنوك بمعزل عن الآخرين – فهي تعتمد على العديد من مزودي الخدمات الخارجيين (من مزودي تكنولوجيا المعلومات إلى الشركاء التقنيين)، كما تحافظ على علاقات مع مؤسسات مالية أخرى (مثل البنوك المراسلة). وتدخل هذه العلاقات في نطاق مخاطر التعهيد والأطراف المقابلة التي تحظى باهتمام متزايد من الجهات التنظيمية. رغم أن البنية الأساسية تركز على العملاء والمعاملات، إلا أنها توفر وحدات لإدارة هذه المخاطر والتخفيف منها.

مخاطر الموردين/البائعين: يتضمن النظام سجلًا لموردي الخدمات الرئيسيين في البنك – مثل مزود خدمات الاستضافة السحابية، أو مزود نظام (Core Banking) (في هذه الحالة شركة ClefinCode إن كانت النسخة محلية)، أو شركاء معالجة المدفوعات، إلخ. لكل مورد، يمكن تخزين المعلومات الأساسية ووثائق العناية الواجبة (العقود، اتفاقيات الخدمة (SLA)، الشهادات مثل (ISO 27001) أو تقارير (SOC)). والأهم أننا ننفذ سير عمل لـتقييم ومراقبة مخاطر الموردين، بما في ذلك: تصنيف المورد حسب مستوى الوصول للبيانات أو أهمية الخدمة، تتبع تواريخ المراجعة، وتوثيق أي متعهدين فرعيين. تفرض الجهات التنظيمية وجود برامج قوية لإدارة مخاطر الأطراف الثالثة (TPRM) [10]. على سبيل المثال، تؤكد إرشادات هيئة البنوك الأوروبية وتشريعات مثل (DORA) على الإشراف على مزودي خدمات تكنولوجيا المعلومات [10]. يساعد نظامنا في ذلك من خلال الاحتفاظ بـسجل للتعهيد (Outsourcing Register) – وهو مطلب في عدة دول – يتضمن جميع عقود التعهيد، أهميتها، وتقييمات المخاطر الخاصة بها [10]. نضيف حقولًا مثل “هل هذا التعهيد حرج أو مهم (نعم/لا)؟”، “حساسية البيانات”، “هل يتطلب موافقة تنظيمية؟” وغيرها، مع نماذج استبيانات لتقييم المخاطر لكل مورد. كما يمكن ربط تقارير المراجعة الخارجية – مثل إرفاق تقرير (SOC 2) الخاص بـ (AWS) كمستند لمزود الاستضافة السحابية [5]. يمكن للنظام إنشاء تنبيهات أو مهام تلقائيًا لمواعيد تجديد العقود أو المراجعات الدورية لكل مورد.

بالإضافة لذلك، نطبق سير عمل للحوكمة – مثلًا قبل التعاقد مع مورد حرج جديد، يمكن للنظام إلزام المستخدمين بملء استمارة تقييم مخاطر والحصول على موافقة مسؤول المخاطر. يندمج هذا مع عمليات الشراء أو إدارة تكنولوجيا المعلومات. الهدف هو تجنب التعهيد غير المنضبط الذي قد يسبب مخاطر إضافية. وكما تشير تقارير Deloitte، فإن توسع نطاق التعهيد وتعقيده يجلب معه مخاطر إلكترونية وتشغيلية وتراكمية [10]. من خلال تتبع هذه الجوانب داخل المنصة الأساسية، يمكن للبنك إدارتها بفعالية. تجدر الإشارة إلى أن خدمة (ClefinCode Cloud) نفسها تُعد نوعًا من التعهيد البنكي، لذا قمنا بتصميمها لتفي بأعلى المعايير (ISO/SOC2) لتخفيف المخاوف المتعلقة بالمخاطر لدى البنوك العميلة.

مخاطر البنوك المراسلة: إذا تم استخدام منصتنا من قبل بنك يقوم بعمليات دفع عبر الحدود، فمن المرجح أن يكون لديه علاقات بنكية مراسلة (أي أن البنك “أ” يحتفظ بحسابات لدى البنك “ب” في دولة أخرى لتسهيل المدفوعات). تعتبر هذه العلاقات من المناطق الحساسة في مجال (AML)، إذ يجب على البنوك إجراء عناية واجبة تجاه البنوك المراسلة، تمامًا كما يتم مع العملاء. يمكن للنظام تضمين فئة خاصة بـ “العملاء المؤسسيين” أو وحدة منفصلة للبنوك المراسلة. ولكل بنك مراسل، يجب جمع معلومات مثل هيكل الملكية، جودة ضوابط (AML)، الجهة المنظمة، خطوط الأعمال الرئيسية، إلخ. تعتمد العديد من البنوك استبيانات مثل (Wolfsberg CBDDQ) للعناية الواجبة البنكية. يمكن للنظام تخزين الاستبيان المكتمل وتقييم المخاطر لكل بنك مراسل. البنوك في دول عالية المخاطر أو ذات شفافية ضعيفة تُصنف بمستوى أعلى وتتطلب موافقة الإدارة العليا. يمكن إعادة استخدام محرك تقييم المخاطر هنا بمعايير تناسب المؤسسات (مثل الوجود في دول خاضعة لعقوبات أو غرامات حديثة). كما تنطبق المراقبة المستمرة: فعلى سبيل المثال، إذا ظهرت أخبار عن البنك المراسل تشير إلى فضيحة أو مشكلة، يجب أن تُحفّز مراجعة فورية. يمكن دمج عمليات بحث عن الأخبار السلبية للمساعدة في ذلك.

من حيث التنفيذ، يمكن تمثيل البنوك المراسلة كنوع من العملاء داخل النظام (بحقل مثل is_financial_institution = True). تُعلَّم المعاملات عبر حسابات المراسلة (Nostro/Vostro) على هذا الأساس، مما يتيح مراقبة الأحجام والكشف عن أي تدفقات غير اعتيادية (مثل تمرير أموال من مصادر عالية المخاطر). كما يدعم النظام سير عمل للمراجعات الدورية – مثل “مراجعة المراسل X سنويًا”، بحيث تُنشأ مهمة لفريق الامتثال بتاريخ استحقاق محدد لتحديث المعلومات وإرفاق بيانات مالية جديدة للبنك المعني.

الجهات التنظيمية والتعهيد: تشير عبارة “for regulators” إلى توقعات الجهات التنظيمية بشأن الرقابة على أي خدمات تعهيد متعلقة بالامتثال أو إدارة المخاطر. تقوم بعض البنوك بتعهيد أجزاء من وظائف الامتثال (مثل مراقبة المعاملات أو فحص العقوبات) لشركات تقنية مالية. ومع ذلك، تظل المسؤولية القانونية على البنك. لذلك صُمم نظامنا ليُدمج مع الخدمات الخارجية للامتثال بطريقة تضمن الشفافية والسيطرة الكاملة للبنك. على سبيل المثال، إذا كانت المراقبة تتم عبر منصة ذكاء اصطناعي خارجية، يرسل نظامنا البيانات إليها ويتلقى التنبيهات منها ويخزنها مع سجل المتابعة الداخلي. يضمن ذلك التتبع الكامل أمام الجهات الرقابية. علاوة على ذلك، يمكن للنظام إنشاء تقارير عن ترتيبات التعهيد عند طلب الجهة التنظيمية (تتضمن جميع الخدمات الحرجة، والمزودين، وإجراءات الأمان المتبعة).

تماشيًا مع التوجيهات التنظيمية[10]، حتى في حال استخدام البنك لخدمة (ClefinCode Cloud) كتعهيد خارجي لتقنية المعلومات أو خدمة خارجية لـ(KYC) كتعهيد لإجراءات الإعداد، يساعد النظام البنك على إثبات الرقابة الفعالة: من خلال تسجيل العناية الواجبة لمزود الخدمة، ومتابعة اتفاقيات الخدمة (SLA) (يمكننا حتى تتبع زمن التشغيل أو الحوادث)، وضمان مراجعة تقارير الامتثال الصادرة عن المزود. تذكر الهيئات التنظيمية مثل (MFSA) صراحةً أن تعهيد وظائف الرقابة الداخلية (مثل الامتثال والمخاطر والتدقيق الداخلي) يُعتبر حرجًا ويجب إدارته بعناية شديدة [10]. إذا اختار أحد عملائنا من البنوك تعهيد مراجعات تنبيهات (AML) من المستوى الأول إلى شركة خارجية، سنقوم بتكوين النظام بحيث تُسجل التنبيهات داخل إدارة الحالات الخاصة بالبنك (مع ملاحظة “تمت المعالجة من قبل شركة XYZ”)، ويستمر موظفو الامتثال في البنك بإجراء اختبارات عشوائية. يمكن توثيق هذه العمليات داخل النظام والتحقق منها.

التكامل مع (ERPNext): نظرًا لأن (ERPNext) يحتوي على وحدات لإدارة الموردين، يمكن توسيع بعض هذه الوظائف من هناك. يمكننا تعزيز مستند المورد (Supplier DocType) ليشمل حقولًا خاصة بالمخاطر وربطه بوحدة الامتثال لدينا. وبالمثل، يمكن تصنيف العملاء الذين هم بنوك أو مؤسسات بطريقة مختلفة. تسمح مرونة إطار (Frappe) بإنشاء هذه النماذج وسير العمل المخصصة بسهولة، مما يضمن أن نظامنا المصرفي الأساسي لا يقتصر على العمليات الداخلية فقط، بل يدير أيضًا بيئة الشركاء والموردين للبنك.

دورة حياة مخاطر الائتمان: الإنشاء، التقييم، الحدود، الخدمة، والتحصيل

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

الإنشاء (تقديم الطلب): تتداخل هذه المرحلة جزئيًا مع عملية إعداد العميل للمقترضين الجدد. تلتقط وحدة إنشاء القروض تفاصيل الطلب: مقدم الطلب (مرتبط بالعميل)، نوع المنتج (مثل قرض تقسيط أو سحب على المكشوف أو رهن عقاري)، المبلغ المطلوب، المدة، والغرض من القرض، إلخ. ندمج ذلك مع عملية (KYC) الموضحة سابقًا – فلا يمكن معالجة طلب القرض إلا بعد اجتياز العميل لإجراءات (KYC/CIP). عند تقديم الطلب، يتم التحقق من الهوية وتنفيذ فحوصات (AML) لضمان عدم منح القروض لأطراف غير مشروعة [11]. يمكن للنظام فرض ذلك عبر عدم السماح بتقدم الطلب ما لم يكن العميل في حالة “KYC معتمد”. عند استلام الطلبات (عبر نموذج أو من قبل الموظفين)، يقوم النظام بتسجيلها ويمكنه تلقائيًا تنفيذ استدعاءات لمكاتب الائتمان كما تم شرحه سابقًا. يتم إرفاق نتيجة التقرير الائتماني أو الدرجة الائتمانية بسجل الطلب.
التقييم الائتماني (Underwriting): في هذه المرحلة، يقوم المقرض بتقييم الجدارة الائتمانية للمقترض ويقرر ما إذا كان سيوافق على القرض وبأي شروط [11]. يتضمن نظامنا مزيجًا من القواعد الآلية والمراجعة اليدوية. نُعد محركات قواعد الائتمان التي تقوم بحساب نسبة الدين إلى الدخل (إن وُجدت بيانات الدخل)، وتتحقق من الدرجة الائتمانية مقابل الحدود المسموح بها، وتضمن أن المبلغ المطلوب يقع ضمن حدود السياسة لتلك الفئة من العملاء، إلخ. يمكن اتخاذ القرار تلقائيًا لبعض المنتجات البسيطة (مثل قرض شخصي صغير لعميل ذو تصنيف ائتماني مرتفع). بخلاف ذلك، يُحال الطلب إلى قائمة انتظار ضابط الائتمان الذي يمكنه مراجعة جميع المعلومات في مكان واحد: بيانات (KYC)، التقرير الائتماني، السجل الداخلي (إن وُجد)، والضمانات المقدمة. يمكنه إدخال تقييم داخلي للمخاطر أو تجاوز القرار المقترح. نضمن تطبيق مبدأ “الأربع عيون” للتمويلات الكبيرة، أي وجوب وجود موافقين اثنين أو قرار لجنة ائتمان، ويمكننا تمثيل ذلك عبر مستند “Approval DocType” لتوثيق التوقيعات.

خلال عملية التقييم، يشير نظامنا إلى معايير مخاطر الائتمان المرتبطة بمعيار (IFRS 9) واتفاقية (Basel). على سبيل المثال، ضمن (IFRS 9) نخصص احتمال التعثر (PD) وخسارة التعثر (LGD) عند إنشاء القرض (قد تأتي هذه القيم من نموذج تقييم أو من تصنيف خارجي). تُستخدم هذه المعايير في حساب الخسائر الائتمانية المتوقعة (ECL). في نموذج البيانات، يمكن تخزينها في مستند القرض أو جداول مرتبطة. يتطلب (IFRS 9) الاعتراف المبدئي بخسارة متوقعة لمدة 12 شهرًا لأصول المرحلة 1 [4]، لذا بمجرد تسجيل القرض، يُحسب مخصص الانخفاض في القيمة تلقائيًا. كما نقوم بتعيين وزن المخاطر وفقًا لنهج (Basel) المعياري عند الإنشاء (مثل قرض تجزئة غير مضمون بوزن 75٪). يخزن نظامنا، كما ورد في الجزء الأول، سمات المخاطر لكل تعرض ائتماني [4]، مما يسمح بتجميعها لاحقًا.

حدود الائتمان وإدارة التعرض: يجب أن يفرض النظام المصرفي الأساسي حدودًا ائتمانية على مستوى العميل الفردي وعلى مستوى القطاعات (مثل حدود التركّز القطاعي). لكل عميل، يمكن تحديد حد ائتماني أقصى – أي إجمالي التعرض المسموح به. نقوم بنمذجة ذلك كحقل في مستند العميل أو كمستند منفصل. عند الموافقة على قرض جديد، يتحقق النظام من إجمالي تعرضات العميل (إجمالي أرصدة القروض والالتزامات غير المسحوبة) ويضمن عدم تجاوز الحد المسموح. في حال تجاوزه، يلزم الحصول على تفويض استثنائي. كما ندعم حدود المجموعة المرتبطة – مثلًا جميع الشركات ضمن تكتل واحد لا يجوز أن تتجاوز نسبة معينة من رأس المال التنظيمي. يمكن للنظام جمع التعرضات حسب المجموعة وإصدار تقارير Large Exposure للامتثال التنظيمي.

يدعم النظام أيضًا الحدود على مستوى المنتج – مثل سياسة “لا يُمنح قرض غير مضمون يتجاوز 50,000 دولار لعميل جديد للبنك”. يمكن تكوين هذه كقواعد تحقق داخل عملية التقييم الائتماني.

إدارة القرض (Servicing): بعد الموافقة على القرض، ينتقل إلى مرحلة الخدمة التي تمثل دورة حياته الفعلية. يحتفظ النظام بـحساب القرض لكل قرض لتتبع الرصيد القائم، الفوائد المستحقة، تاريخ الاستحقاق التالي، إلخ. يضمن التكامل مع دفتر الأستاذ العام أن جميع المعاملات (الصرف، السداد، الفوائد، الرسوم) تولد القيود المحاسبية الصحيحة تلقائيًا (يُشرح ذلك في الجزء 2). من ناحية المخاطر، يراقب النظام الأداء: عدد أيام التأخير، أي خروقات للعقود (مثل العهود المالية للقروض المؤسسية)، ومؤشرات لإعادة التصنيف. وفقًا لـ(IFRS 9)، يتم نقل القروض من المرحلة 1 إلى المرحلة 2 إذا تدهورت جودتها الائتمانية بشكل كبير. ننفذ ذلك بمقارنة المؤشرات على مر الزمن: مثل تجاوز التأخير 30 يومًا أو انخفاض الدرجة الائتمانية للمقترض. عندها يُعلِّم النظام القرض كـ“مرحلة 2”، ليقوم نموذج (ECL) بحساب الخسائر المتوقعة مدى الحياة بدلاً من 12 شهرًا [4]. يمكن للمنصة أيضًا دمج التقييم السلوكي – مثل ترقية التقييم بعد 6 أشهر من السداد المنتظم، أو تخفيضه في حال التأخير المتكرر.

أثناء تقديم الخدمة، نتعامل أيضًا مع تخفيف مخاطر الائتمان (credit risk mitigation): إذا كان هناك ضمان، يقوم النظام بتتبع قيمة الضمان ونسبة القرض إلى القيمة (LTV). نحافظ على جدول للضمانات مرتبط بالقروض (كما هو موضح في الجزء 2 من (ERD)). إذا تغيرت قيمة الضمان (على سبيل المثال، تم تحديث القيمة السوقية لعقار يضمن قرض رهن عقاري)، فقد يؤدي ذلك إلى تغيير مؤشرات المخاطر. يمكن للنظام أن يحتوي على مهمة مجدولة لتحديث قيم الضمانات (تقوم بعض البنوك بإجراء تقييمات دورية أو استخدام تقديرات فهرسية). إذا ارتفعت نسبة (LTV) فوق المستويات المقبولة (مثل انخفاض قيمة العقار)، يمكن للنظام تنبيه مديري الحسابات لطلب ضمان إضافي أو مراجعة القرض (وهذا متقدم أكثر، لكنه ميزة ممكنة). يوضح مثال (Canopy) كيف تتعامل الأنظمة الحديثة مع الضمان بشكل ديناميكي، حتى أنها تقوم بتعديل توفر الائتمان بناءً على تغييرات الضمان [12][12] – ويتماشى تصميمنا مع هذه الفلسفة لأي منتجات إقراض مضمونة.

التحصيل والاسترداد: إذا أصبح القرض متعثراً (تجاوز فترة السماح دون سداد الأقساط)، تبدأ ميزات إدارة التعثر في النظام بالعمل. نقوم بتحديد شرائح التعثر (30 يومًا، 60 يومًا، أكثر من 90 يومًا، إلخ)، ويقوم النظام بتصنيف القروض وفقًا لذلك. يمكن لوحدة التحصيلات (Collections Module) الداخلية أن تنشئ مهام أو قوائم بالقروض المتأخرة لموظفي التحصيل، تحتوي على معلومات مثل المبلغ المستحق، بيانات الاتصال، ووعود السداد، مع إمكانية الدمج مع أنظمة التواصل (لإرسال تذكيرات آلية). عندما يتجاوز القرض 90 يومًا من التأخير، يُعتبر عادةً غير عامل (Non-Performing Loan - NPL) وفقًا للجهات التنظيمية. سيقوم نظامنا بوضع علامة على هذه الحسابات، وسيتم تضمين هذه الحالة في تقارير (IFRS 9 Stage 3) (القروض المتعثرة التي تتطلب الاعتراف بخسائر مدى الحياة والتوقف عن احتساب الفوائد)، وكذلك في تقارير الجهات الرقابية عن نسبة القروض المتعثرة. نضمن أنه عندما يتم تصنيف القرض كغير عامل، يتم تحويل طريقة احتساب الدخل من الفوائد إلى عدم الاحتساب (قد تستمر الفوائد في التراكم كمذكرة ولكن لا تُدرج في الأرباح والخسائر إلا عند استلامها). كما سيقوم محرك المخصصات بتكوين مخصص بنسبة تصل إلى 100% بمرور الوقت أو حسب السياسة.

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

طوال دورة حياة القرض، يكون الدمج مع دفتر الأستاذ العام والتقارير التنظيمية مستمرًا. على سبيل المثال، في نهاية كل شهر، يمكن للنظام حساب (IFRS 9 ECL) المطلوب لكل قرض أو لكل شريحة من المحفظة تلقائيًا وتسجيل تعديلات المخصص بحيث تبقى الحسابات المالية محدثة [4]. كما يمكنه حساب مؤشرات رأس المال عند الحاجة (مثل نسبة المحفظة في المرحلة 2 أو المرحلة 3، والتي قد تُستخدم كمؤشر داخلي لشهية المخاطر).

بالإضافة إلى ذلك، فإن الهيكلية المعتمدة على الأحداث (event-driven architecture) (كما في الجزء 1 من الرؤية) تعني أن الأحداث المهمة في حياة القرض (الموافقة، الصرف، تغيير حالة التعثر، إلخ) يتم نشرها في قناة داخلية. يسمح ذلك، على سبيل المثال، بإشعار قسم المخاطر عند الموافقة على قرض كبير (لتتبع مخاطر التركز) أو عند التعثر (لإبلاغ إدارة الأصول والخصوم بإدخال سيناريوهات اختبار الضغط). كما يساعد في المتطلبات التنظيمية (regulatory triggers) – مثل اشتراط بعض السلطات الإبلاغ الفوري عن التعثرات أو التعرضات الائتمانية الكبيرة. يمكننا إعداد معالج أحداث يقوم بتجميع هذه المعلومات وإرسال الإشعار المطلوب تلقائيًا.

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

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

مراقبة المعاملات وإدارة الحالات لمكافحة غسل الأموال وتمويل الإرهاب (AML/CTF)

بينما يحدد (KYC) وإجراءات الانضمام الملف الائتماني الأولي للعميل، فإن المراقبة المستمرة لمكافحة غسل الأموال وتمويل الإرهاب (AML/CTF) ضرورية لاكتشاف الأنشطة المشبوهة خلال فترة علاقة العميل بالبنك. يتضمن نظامنا المصرفي الأساسي نظام مراقبة متعدد المستويات، في الوقت الحقيقي وعلى دفعات (batch)، مدمجًا مع وحدة إدارة الحالات (case management) للتحقيقات.

فحص المعاملات في الوقت الحقيقي (Real-Time Transaction Screening): يجب إجراء بعض الفحوصات عند بدء المعاملة أو معالجتها. المثال الأكثر شيوعًا هو فحص العقوبات على المدفوعات (sanctions screening on payments). في كل مرة يتم فيها تنفيذ دفعة أو تحويل (خصوصًا التحويلات الخارجية، ويفضل جميعها)، يجب أن يقوم النظام بفحص اسم المستفيد واسم المرسل (إن كان واردًا) وأي حقول ذات صلة في الرسائل مقابل قوائم العقوبات والمراقبة. في هيكليتنا، عندما يتم إنشاء تعليمات الدفع (كما هو موضح في الجزء 1 من محرك المدفوعات)، فإنها تُطلق خدمة الفحص. إذا تم العثور على تطابق محتمل (على سبيل المثال، إذا كان اسم المستفيد يشبه اسمًا في قائمة (OFAC) أو (UN))، يمكن للنظام إيقاف المعاملة للمراجعة اليدوية. يمكننا إما دمج واجهة برمجة تطبيقات خارجية للفحص أو الاحتفاظ بقائمة سوداء داخلية يتم تحديثها بانتظام [4]. كما يشمل الفحص الفوري كلمات مفتاحية محددة (مثلًا إذا احتوى حقل مرجع التحويل على كلمات قد تدل على غرض غير مشروع مثل “XYZ Donation Syria”، فقد يُعتبر مؤشرًا على تمويل إرهاب). يمكن تكوين هذه الكلمات المحظورة في النظام.

بالإضافة إلى ذلك، يمكن أن تتعامل القواعد الفورية (real-time rules) مع سيناريوهات مثل الإيداعات النقدية التي تتجاوز حدًا معينًا. على سبيل المثال، إذا أودع عميل 15,000 دولار نقدًا (فوق الحد التنظيمي 10,000 في بعض الدول)، يمكن للنظام تلقائيًا وضع علامة عليها وربما يطلب من الصراف جمع تصريح بمصدر الأموال.

يعتمد تصميمنا على النهج القائم على الأحداث (event-driven approach): كل حدث مالي (إيداع، سحب، تحويل) يتم نشره إلى وحدة (AML) التي تمرره عبر مجموعة من القواعد في الوقت الفعلي أو قريب من الوقت الفعلي. يمكن تقييم القواعد البسيطة بشكل متزامن (أثناء تنفيذ المعاملة)، بينما يتم تقييم الأنماط الأكثر تعقيدًا بشكل غير متزامن (حتى لا تتسبب في تأخير العملية إلا إذا كان من الضروري إيقافها).

المراقبة الدورية والتعرف على الأنماط (Batch Monitoring and Pattern Recognition): تظهر العديد من الأنماط المشبوهة فقط عند تحليل الأنشطة على مدى فترة زمنية، ولهذا يلزم التحليل الدفعي أو بأثر رجعي. سيدعم نظامنا تعريف سيناريوهات (AML) مثل التجزئة (structuring أو smurfing) – مثلًا، عدة إيداعات نقدية بقيم أقل قليلًا من الحد التنظيمي خلال فترة قصيرة، أو نشاط مفاجئ في حساب خامد، أو حسابات قمع (funnel accounts) تتلقى العديد من التحويلات من مصادر مختلفة ثم ترسلها بسرعة إلى أطراف أخرى. تتطلب هذه السيناريوهات غالبًا جمع أو عد المعاملات على مدى أيام أو أسابيع. لتنفيذ ذلك، يمكن تغذية بيانات المعاملات من النظام الأساسي إلى محرك تحليلات (AML) بشكل دوري. يمكننا استخدام وحدة مدمجة تعتمد على قاعدة البيانات (استعلامات (SQL) يمكنها اكتشاف العديد من الأنماط)، أو تصدير البيانات إلى نظام متخصص إذا استخدم البنك نظامًا خارجيًا. ومع ذلك، وبما أننا نهدف إلى حل متكامل، يمكننا الاستفادة من مهام الخلفية في (ERPNext) أو المهام المجدولة – مثل تشغيل مهمة ليلية لتطبيق قواعد (AML).

على سبيل المثال، يمكن أن تكون القاعدة: “إذا تجاوز إجمالي الإيداعات النقدية من قبل عميل خلال أي فترة 7 أيام مبلغ 50,000 دولار، يتم إنشاء تنبيه” – يمكن تحقيق ذلك باستخدام دالة (SQL window) أو مجموع متحرك محفوظ في جدول. مثال آخر: “إذا استقبل حساب أكثر من 10 تحويلات واردة من مرسلين مختلفين خلال شهر، يتم وضع علامة عليه كحساب مشبوه محتمل (mule account).” سنوفر واجهة مستخدم لموظفي الامتثال لتعديل بعض المعايير (الحدود، الفترات الزمنية، الكلمات المحظورة). يسلط نظام (advapay core banking) الضوء على المرونة في إعداد قواعد وتنبيهات (AML)، بما في ذلك كلمات التوقف والفلاتر القائمة على المعايير[9] – ونحن نعكس هذا المفهوم من خلال جعل محرك القواعد قابلاً للتهيئة. يمكن تخزين القواعد في (doctype) يحتوي على حقول مثل نوع القاعدة، والحد، وما إلى ذلك، بحيث يقوم المحرك بتنفيذها تباعاً.

عندما يتم اكتشاف أنماط مشبوهة، يقوم النظام بإنشاء سجل تنبيه (Alert). يحتوي كل تنبيه على تفاصيل مثل: أي قاعدة تم تفعيلها، أي حساب/عميل معني، المعاملات التي ساهمت في ذلك، التاريخ، مستوى الخطورة، إلخ. يمكن ربط عدة تنبيهات لنفس العميل في قضية واحدة (Case) للتحقيق.

التنبيهات وتسجيل المخاطر (Risk-Based Alerts and Scoring): ليست جميع التنبيهات متساوية؛ يستخدم نظامنا تصنيف المخاطر الخاص بالعميل لتحديد الأولويات. بالنسبة لعميل عالي المخاطر، قد تستدعي معاملة صغيرة الانتباه، بينما لعميل منخفض المخاطر يمكن وضع حدود أعلى. يمكن تنفيذ مفهوم الحدود الديناميكية من خلال الإشارة إلى درجة المخاطر الخاصة بالعميل في منطق القاعدة (مثلًا، يمكن أن تحدد القاعدة مبالغ مختلفة حسب مستويات المخاطر). علاوة على ذلك، يمكن أن يحمل كل تنبيه درجة خطر خاصة به. تذكر (Advapay) تقييم المخاطر لكل معاملة وتفعيل المراقبة المعززة[9] – في نظامنا، عندما يتم إنشاء تنبيه، يمكننا تعيين درجة أو مستوى له (على سبيل المثال، إذا كان العميل يتعامل مع دولة عالية المخاطر، يتم تصنيف التنبيه على أنه عالي الخطورة). إذا تجاوزت درجة التنبيه حدًا معينًا، يمكن تصعيده فورًا (مثل إرسال بريد إلكتروني إلى مسؤول مكافحة غسل الأموال (MLRO) للمراجعة العاجلة).

إدارة القضايا (Case Management): تتدفق جميع التنبيهات إلى سير عمل إدارة القضايا. في هذا السياق، تمثل القضية حالة تحقيق، وغالبًا ما ترتبط بتقرير نشاط مشبوه (SAR) إذا وصل التحقيق إلى تلك المرحلة. يمكن لمستخدمي الامتثال (المحللين والمحققين) رؤية لوحة تحكم أو قائمة بالتنبيهات والقضايا المفتوحة في (AML). يمكنهم تجميع التنبيهات ذات الصلة (قد يقوم النظام تلقائيًا بتجميع التنبيهات لنفس العميل ضمن فترة زمنية في قضية واحدة). داخل القضية، يمكن للمحقق تسجيل تحليله: حيث يقوم بمراجعة المعاملات (يجب أن يعرض له النظام دفتر الحساب، ومعلومات (KYC) الخاصة بالعميل، وما إلى ذلك بشكل مريح)، ثم يقرر ما إذا كان النشاط مبررًا أم مشبوهًا فعلاً.

تتيح إدارة القضايا للمستخدم إضافة ملاحظات، وإرفاق أي مستندات داعمة (ربما تم طلب مزيد من المعلومات من الفرع)، وفي النهاية تحديد القرار (disposition) الخاص بالقضية. القرارات المعتادة تشمل: إنذار كاذب / تم مسح التنبيه (مع ذكر السبب)، أو تصعيده لتقديم تقرير (SAR). إذا كان هناك حاجة لتقرير (SAR) أو (STR – Suspicious Transaction Report)، يمكن للنظام إنشاء مسودة تقرير تتضمن المعلومات المتوفرة: تفاصيل العميل، المعاملات ذات الصلة، والسرد التوضيحي. يمكن تصدير التقرير بالتنسيق المطلوب من الجهات التنظيمية (بعضها يستخدم ملفات (XML) إلكترونية أو نماذج (PDF)). يحتفظ النظام بسجل لجميع تقارير (SAR) المقدمة، وهو أمر حاسم لأن الجهات التنظيمية تقوم بمراجعتها؛ كما نقوم بربط مرجع التقرير بالقضية في النظام.

القوائم السوداء / البيضاء (Blacklist/Whitelists): بمرور الوقت، قد يطور البنك قوائم سوداء داخلية (مثل الأشخاص أو الكيانات المعروفين بسوء السلوك، حتى إن لم يكونوا في القوائم الرسمية) وقوائم بيضاء (لحالات التنبيهات المتكررة الناتجة عن نشاط مشروع تم توثيقه). يوفر نظام (AML) طريقة لإدارة هذه القوائم. على سبيل المثال، قد يؤدي نمط تحويل معين إلى تنبيهات، ولكن إذا كان معروفًا ومبررًا (مثل شركة ترسل مدفوعات منتظمة إلى بلد معين لأغراض تجارية مشروعة)، يمكن للمحللين إدراج هذا النمط في القائمة البيضاء لذلك العميل، وسيقوم النظام بعد ذلك بتقليل أو منع التنبيهات المشابهة مستقبلًا. وبالعكس، إذا قرر البنك إدراج جهة في القائمة السوداء (مثلاً بعد اكتشاف متقدم احتيالي)، يتم إدخال بيانات تلك الجهة في جدول القائمة السوداء، وسيقوم كل من نظام الانضمام ومراقبة المعاملات بالرجوع إليه لمنع أي تعاملات تلقائيًا.

يضمن نظامنا، من خلال التحديثات المنتظمة لقوائم العقوبات وقوائم (PEP)[9] (عادة من مزودين خارجيين أو مصادر تنظيمية)، أن تكون عمليات الفحص محدثة دائمًا. نقوم بجدولة مهام لسحب أحدث القوائم (تحديثات (OFAC)، تحديثات الاتحاد الأوروبي، إلخ) لضمان أن الفحص الفوري والتحليلات الدورية تلتقط أي إدراجات جديدة (وهذا مهم لأن القوائم تتغير يوميًا).

التكامل والتدقيق (Integration and Audit): تتكامل وظائف (AML/CTF) مع دفتر الأستاذ العام، ولكن يمكن النظر إليها كمكون يستمع للأحداث ويستعلم من قاعدة البيانات. يتم تسجيل جميع النتائج والإجراءات. كل تغيير في القضية (من راجعها، وما القرار) يتم توثيقه لأغراض التدقيق. يمكن للنظام إصدار تقارير مثل عدد التنبيهات، عدد تقارير (SAR) المرفوعة، إلخ، وهي مطلوبة للجان المخاطر الداخلية والجهات التنظيمية الخارجية. من المهم التأكيد على أن الأتمتة لا تلغي الحاجة إلى التقدير البشري – إذ تم تصميم النظام لدعم موظفي الامتثال من خلال معالجة البيانات الثقيلة، حتى يتمكنوا من التركيز على التحليل. على سبيل المثال، من خلال تزويدهم بسياق ملخص (المعاملات، بيانات العميل، سلوك المجموعة المماثلة) في شاشة القضية، يقضون وقتًا أقل في جمع البيانات ووقتًا أكثر في اتخاذ القرارات.

علاوة على ذلك، كجزء من خارطة طريق (ClefinCode)، تم التخطيط لإضافة مساعد ذكي (AI assistant) يسمى (ClefinCode Chat) لمساعدة موظفي الامتثال – على سبيل المثال، يمكن للذكاء الاصطناعي الإجابة على أسئلة حول قضية (“هل أرسل هذا العميل أموالًا إلى دول عالية المخاطر من قبل؟”) واسترجاع الإجابات فورًا من البيانات، أو الإشارة إلى أنماط شاذة قد لا تغطيها القواعد الصريحة.

النتيجة النهائية هي نظام شامل لمكافحة غسل الأموال وتمويل الإرهاب (AML/CFT) حيث تمر كل معاملة من خلال عدة طبقات من المراقبة، ويتم إبراز المشبوهة منها بتفاصيل غنية، دون أن يفلت أي شيء من المتابعة. يلتزم النظام بمتطلبات الجهات التنظيمية التي تلزم البنوك بوجود مراقبة في الوقت الحقيقي (لمنع تدفقات الأموال غير المشروعة فورًا) ومراقبة مستمرة (لتحديد أنماط غسل الأموال)[2][2]. وعندما يكتشف النظام نشاطًا مشبوهًا فعلاً، فإنه يوجه البنك إلى الوفاء بواجبه القانوني من خلال تقديم تقارير (SAR) في الوقت المناسب[2] – مع التوثيق الكامل. ومن خلال أتمتة التنبيهات وتوفير سير عمل واضح للقضايا، يمكن للبنك التعامل مع عدد أكبر من الحالات بكفاءة، وهو أمر بالغ الأهمية نظرًا لتطور أساليب المجرمين باستمرار (حتى أنهم يستخدمون الذكاء الاصطناعي لتجنب الاكتشاف)[2].

الامتثال التنظيمي والتقارير (رأس المال، السيولة، القروض المتعثرة، الإفصاحات)

بالإضافة إلى إدارة المخاطر الداخلية، يجب أن يسهل النظام المصرفي الأساسي مجموعة واسعة من متطلبات التقارير التنظيمية. وتشمل هذه التقارير المالية والدورية للمخاطر (عادةً للبنوك المركزية أو الجهات التنظيمية) والتقارير المرفقة بالقوائم المالية (IFRS 7/IFRS 9) وتقارير الملاءة المالية (Basel III/IV). تم تصميم (ClefinCode) لإنتاج هذه التقارير مباشرة أو على الأقل تجميع البيانات اللازمة لأنظمة التقارير الخارجية.

كفاية رأس المال (Basel III/IV): بالنسبة للبنوك الخاضعة لمتطلبات (Basel)، فإن حساب نسب كفاية رأس المال (Capital Adequacy Ratios) إلزامي (غالبًا ربع سنوي أو أكثر). يقوم نظامنا بتجميع البيانات اللازمة لهذه الحسابات، بما في ذلك: قيمة الأصول المرجحة بالمخاطر (RWA) لكل تعرض ائتماني، ومكونات رأس المال التنظيمي، وغيرها من التعرضات (السوقية أو التشغيلية إذا وجدت). بالنسبة لمخاطر الائتمان، كما ذُكر، نقوم بتخزين وزن المخاطر أو مدخلات نموذج (IRB) مثل (PD, LGD, EAD). عند إعداد التقارير، يمكن للنظام جمع إجمالي (RWA) عبر المحفظة مصنفة حسب فئات الأصول. على سبيل المثال، عند استخدام المنهج المعياري، قد تكون هناك جداول للتعرضات حسب وزن المخاطر (0٪، 20٪، 50٪، 100٪، إلخ). يمكن للنظام توليد هذه المجاميع بسهولة من سجلات القروض والأصول. كما نتعامل مع التعرضات خارج الميزانية (مثل الالتزامات غير المسحوبة أو الضمانات) من خلال تطبيق عوامل تحويل ائتمانية – يمكن ضبطها بحيث يحسب النظام قيمة (EAD) لها.

قدمت (Basel III) نسبًا جديدة مثل نسبة الرافعة المالية (Leverage Ratio) (رأس مال الشريحة الأولى / إجمالي التعرضات) والهوامش الإضافية. يقوم نظامنا بتجميع إجمالي التعرضات (بما في ذلك خارج الميزانية) لحساب نسبة الرافعة[4]. ونظرًا لأن حساب رأس المال التنظيمي يمكن أن يكون معقدًا، فإننا نخطط لتوفير تصدير بيانات إلى أنظمة مخاطر متخصصة للمناهج المتقدمة. ومع ذلك، يتضمن النظام دعمًا أساسيًا مثل تقرير يلخص إجمالي (RWA) ورأس المال، لإظهار نسب مثل (CET1) ونسبة رأس المال الإجمالية، استنادًا إلى بيانات رأس المال المُدخلة من الإدارة المالية. وقد أدخل (Basel IV) إصلاحات جديدة غيرت بعض المعادلات وأضافت حدودًا دنيا للإخراج، ولكن نظرًا لأن نظامنا قائم على البيانات، يمكننا التكيف مع هذه التغييرات عبر تحديث منطق الحسابات؛ كما أن نموذج البيانات لدينا مرن بما يكفي (من خلال تخزين معلمات المخاطر التفصيلية) للتعامل مع القواعد المتغيرة[4].

تقارير السيولة وإدارة الأصول والخصوم (Liquidity and ALM Reporting): تتطلب الجهات التنظيمية أيضًا حساب نسبة تغطية السيولة (LCR) ونسبة التمويل المستقر الصافي (NSFR) بموجب معايير (Basel III)[4]. يحتاج النظام إلى تصنيف الأصول والخصوم إلى مجموعات (حسب السيولة). بالنسبة إلى (LCR)، يجب تحديد الأصول السائلة عالية الجودة (HQLA) – على سبيل المثال، يجب أن يميز النظام الأصول التي تُعتبر من المستوى 1 أو 2A، إلخ، ويجمع قيمها. كما يجب عليه حساب التدفقات النقدية الخارجة المتوقعة خلال 30 يومًا من مصادر مختلفة (الودائع، القروض، الالتزامات) وكذلك التدفقات الداخلة. وبينما تتداخل بعض هذه الجوانب مع إدارة الأصول والخصوم (ALM)، فإن تصميمنا المتكامل يعني أنه عند إعداد منتج إيداع جديد، يمكن تحديد خاصية تُشير إلى فئته ضمن (LCR) (مثل ودائع التجزئة المستقرة مقابل ودائع الشركات، إلخ، ولكل منها عامل تصريف مختلف). وبالمثل، تتطلب (NSFR) تصنيف التمويل والأصول حسب آجال الاستحقاق > سنة أو < سنة، إلخ. نقوم بتخزين أجل الاستحقاق لكل حساب (القروض لها مدة، والودائع إما فورية أو لأجل). بعد ذلك، يمكننا إنشاء تقرير (NSFR) عن طريق جمع التمويل المستقر المتاح والتمويل المستقر المطلوب وفقًا للأوزان التنظيمية[4]. ونظرًا لتعقيد هذه الحسابات، سنقوم على الأرجح بإنشاء استخراج بيانات يمكن معالجته في جدول بيانات أو أداة تنظيمية، لكن المفتاح هو أن النظام الأساسي يحتوي على المعلومات الخام: كل حساب مع رصيده وفئته.

القروض غير العاملة (NPL) وجودة الائتمان: تتابع الجهات التنظيمية نسب القروض غير العاملة ونسب تغطية المخصصات. يحتفظ نظامنا تلقائيًا بعلامة (NPL) على القروض (كما ذُكر، عادة بعد أكثر من 90 يومًا من التأخير). يمكننا إنتاج نسبة القروض غير العاملة إلى إجمالي القروض، وتفاصيل مثل قروض المرحلة الثالثة وتغطيتها وفقًا لمعيار (IFRS 9). كما تتطلب معايير (IFRS 7) واللوائح المحلية الإفصاح عن معلومات المخاطر الائتمانية مثل تحليل أعمار القروض المتأخرة وجودة الأصول الائتمانية، إلخ[4]. نقوم بتطبيق تقارير تُفصل محفظة القروض حسب درجة المخاطر الائتمانية، وفئة التأخر، ومستوى الضمانات. على سبيل المثال، قد يتضمن إفصاح (IFRS 7): “القروض حسب التصنيف: درجة استثمارية X، دون الاستثمارية Y؛ القروض حسب الحالة: عاملة $A، متعثرة جزئيًا $B، غير عاملة $C؛ مخصصات الانخفاض لكل فئة؛ قيمة الضمانات مقابل القروض غير العاملة.” جميع هذه البيانات موجودة في نظامنا: التصنيفات من مرحلة المنح، الحالات من مرحلة الخدمة، المخصصات من وحدة (IFRS 9)، والضمانات من وحدة الضمان. وننشئ قوالب تقارير قياسية لإخراج هذه الأرقام[4].

مخاطر التركز (Concentration Risk): تطلب العديد من الجهات التنظيمية تقارير عن التركز – مثل أكبر 20 تعرضًا، أو التركز القطاعي، أو التركز الجغرافي للقروض أو الودائع. باستخدام تصنيفات العملاء والصناعات لدينا (لدينا حقل للصناعة لعملاء الشركات)، يمكننا تجميع التعرضات حسب الصناعة. وكذلك حسب الدولة (في حال العمليات العابرة للحدود). يحدد تقرير التعرضات الكبيرة (Large Exposures) أي تعرض يتجاوز نسبة معينة من رأس المال. وبما أننا نعرف الرصيد القائم لكل قرض، يمكننا جمعه حسب مجموعة العميل (باستخدام العلاقات كما تمت مناقشتها) ووضع علامة إذا تجاوز أي تعرض جماعي مثلاً 10% من رأس المال (أو الحد الداخلي). يمكن للنظام إنشاء قائمة بهذه التعرضات وتفاصيلها للتقديم التنظيمي.

إفصاحات (IFRS 9): بالإضافة إلى الأرقام، تتطلب معايير (IFRS 7) المعدلة بـ (IFRS 9) إفصاحات نوعية حول كيفية إدارة البنك للمخاطر وكيف يتم قياس خسائر الائتمان المتوقعة (ECL)[4]. بينما السرد التوضيحي خارج نطاق النظام، ندعم بعض الإفصاحات الكمية مثل: تسوية حسابات المخصصات (الرصيد الافتتاحي، صافي المخصصات، الشطب، الرصيد الختامي)، وتقسيم القروض حسب المراحل 1 و2 و3 مع المخصصات المقابلة. يضع نموذج البيانات لدينا علامة المرحلة على كل قرض، مما يتيح جمع إجمالي المرحلة الأولى مقابل الثانية بسهولة. وإذا انتقل قرض بين المراحل، يسجل النظام التاريخ – ويمكننا تقديم بيانات عن التحركات بين المراحل (كم جزء من المحفظة تغير مرحلته خلال فترة معينة، وهو ما يُطلب غالبًا). كما يتطلب (IFRS 9) عرض جودة الائتمان للأصول – ويمكننا استخدام التصنيفات الداخلية أو عدد أيام التأخر كمؤشر للتصنيف.

تنسيقات التقارير التنظيمية (Regulatory Filing Formats): تتطلب العديد من الجهات التنظيمية الآن تقديم البيانات بتنسيقات محددة (مثل XBRL أو XML لتقارير Basel، أو تنسيقات محلية للبنك المركزي لتقارير القروض الفردية). بينما إنشاء محرك (XBRL) كامل يتجاوز نطاق النظام الأساسي، نضمن إمكانية تصدير البيانات بشكل منظم. على سبيل المثال، يمكننا تقديم تصدير لجميع حسابات القروض مع الحقول المطلوبة من الجهة التنظيمية (مثل رقم القرض، رقم العميل، المبلغ، الحالة، الضمان، إلخ). يمكن لوحدة التقارير لدينا إنشاء هذا الملف (CSV/XML) مباشرة من قاعدة البيانات، مما يقلل العمل اليدوي والأخطاء في التقارير التنظيمية.

مسارات التدقيق وفحوصات الامتثال (Audit Trails and Compliance Checks): يفرض النظام الامتثال في العمليات اليومية لتقليل مشكلات التقارير. على سبيل المثال، تصنيف الحسابات ضمن فئات (Basel/IFRS) عند إنشائها يضمن أن التقارير لاحقًا لا تحتاج إلى تصنيف يدوي. ندمج أيضًا فحوصات التحقق (مثل التأكد من أن كل قرض لديه وزن مخاطر أو تصنيف داخلي). إذا كان هناك نقص في البيانات، يتم وضع علامة استثناء قبل فترة التقارير.

سنقوم أيضًا بإضافة تقويم تنظيمي (Regulatory Calendar) – وهو (doctype) في (ERPNext) يسرد جميع التقارير الدورية ومواعيد استحقاقها. يمكن ربطه بالمهام أو إعداد توليد البيانات تلقائيًا في تلك التواريخ. على سبيل المثال، يمكن لإدخال بعنوان “كفاية رأس المال Basel III – ربع سنوي” أن يُفعّل النظام لتجميع الأرقام في نهاية الربع وتجهيز تقرير مسودة لفريق المالية/المخاطر للمراجعة.

مثال – تقرير الركيزة الثالثة (Pillar 3 Report): بموجب ركيزة Basel الثالثة (الإفصاح العام)، تنشر البنوك جداول الأصول المرجحة بالمخاطر ورأس المال والتعرضات. باستخدام نظامنا، يمكن لقسم المخاطر إعداد بيانات الركيزة الثالثة مباشرة. على سبيل المثال، قد يُظهر أحد الجداول (RWA) حسب نوع المخاطر (شركات، أفراد، إلخ) – وبما أن منتجات القروض لدينا مصنفة، يمكن جمعها حسب الفئات. تتطلب (IFRS 7) أيضًا الإفصاح عن طبيعة ومدى المخاطر بما في ذلك تركّز المخاطر الائتمانية وتحليل السيولة[4]. على سبيل المثال، يتضمن تحليل استحقاقات السيولة قائمة بالأصول والخصوم في فترات زمنية (مثل التدفقات النقدية التعاقدية في أقل من شهر، من 1–3 أشهر، حتى أكثر من 5 سنوات). وبما أننا نخزن أجل استحقاق كل وديعة وجدول سداد كل قرض (يمكننا اشتقاق الجدول من بيانات السداد)، يمكننا توليد هذا الجدول بسهولة. قد يتطلب ذلك دمج العديد من النقاط، لكن إحدى ميزات الاعتماد على نظام (ERP) هي إمكانية الاستفادة من أدوات التقارير والاستعلامات المدمجة لربط الوحدات المختلفة.

باختصار، يتم التقاط البيانات على مستوى تفصيلي دقيق (لكل معاملة ولكل سمة حساب)، لكننا نُنتج معلومات مجمعة مطلوبة من الجهات التنظيمية. تعتمد فلسفة (ClefinCode) على تقليل الاعتماد على جداول البيانات والتعديلات اليدوية – بل إعداد النظام ليصنف ويحسب تلقائيًا بحيث تصبح التقارير قابلة للتوليد بنقرة زر. وبالطبع، تختلف المتطلبات التنظيمية بين البلدان، لذا فإن النظام مرن: يمكن إضافة تنسيقات جديدة أو حسابات عبر سكربتات مخصصة أو استعلامات. ويُثبت تركيز البنية على نموذج بيانات متكامل (كيانات معيارية) فعاليته هنا: لأن جميع الوحدات (القروض، الودائع، إلخ) تشترك في مرجع موحد للعميل والمنتج، يمكن بسهولة دمج البيانات لتكوين تقارير شاملة على مستوى المؤسسة[13][13].

أخيرًا، نأخذ بعين الاعتبار أيضًا تكامل التكنولوجيا التنظيمية (RegTech integration): في المستقبل، قد تطلب الجهات التنظيمية وصولًا أكثر تفصيلاً أو حتى في الوقت الفعلي إلى البيانات. يمكن لنظامنا توفير واجهات (APIs) أو تدفقات بيانات مخصصة للجهات التنظيمية (مع الأمان المناسب) إذا طُلب ذلك – على سبيل المثال، بعض البنوك المركزية في الأنظمة المتقدمة تفكر في سحب البيانات التشغيلية مباشرة (مفهوم “الإشراف المضمن (embedded supervision)” حيث تكون بيانات الامتثال متاحة تقريبًا في الوقت الفعلي)[14]. ورغم أن ذلك ليس شائعًا بعد، إلا أن بنيتنا السحابية يمكنها استيعاب عقدة آمنة تتيح للجهات التنظيمية الوصول إلى استعلامات محددة، مما يجعل تقارير الامتثال مؤتمتة على المدى الطويل.

ClefinCode Chat – المساعد الذكي للانضمام والامتثال باستخدام الذكاء الاصطناعي

من الميزات الفريدة التي ندمجها هي ClefinCode Chat، وهي واجهة دردشة متعددة القنوات مدعومة بالذكاء الاصطناعي ومتكاملة مع النظام المصرفي الأساسي. لا تُستخدم هذه الدردشة فقط لاستفسارات العملاء، بل تُستغل لدعم عمليات الانضمام، وإجراء مقابلات (KYC) تفاعلية، ومساعدة موظفي الامتثال بطريقة محادثية. الهدف هو جعل العمليات المعقدة أكثر سهولة للمستخدمين والاستفادة من الذكاء الاصطناعي لتحسين الكفاءة مع الحفاظ على الأمان (بما في ذلك إخفاء المعلومات الشخصية (PII) وحماية البيانات).

الانضمام الموجّه بالذكاء الاصطناعي (AI-Guided Client Onboarding): بدلاً من إرغام العملاء على ملء النماذج الطويلة، يمكن لـ ClefinCode Chat التفاعل معهم في حوار طبيعي لجمع المعلومات المطلوبة. على سبيل المثال، عندما يرغب عميل محتمل في فتح حساب عبر موقع البنك أو تطبيق مراسلة، يرحب به المساعد الذكي ويسأله الأسئلة المطلوبة ضمن عملية (CIP): “مرحبًا! دعنا نبدأ إعداد حسابك. ما اسمك الكامل كما هو في الهوية؟”، ثم “يرجى إدخال تاريخ ميلادك”، “ما عنوانك؟” وهكذا. أثناء الإجابات، يقوم النظام الخلفي بملء الحقول الخاصة بالانضمام تلقائيًا. كما يمكن للدردشة توجيه العميل لتحميل المستندات: “أحتاج صورة لهويتك. يمكنك تحميلها هنا أو التقاطها الآن.” على الهاتف المحمول، يمكن للمستخدم التقاط صورة وإرسالها عبر الدردشة. بعد ذلك، يتكامل ClefinCode Chat مع خدمة التحقق من المستندات للتحقق من الهوية في الوقت الفعلي، ويرد بالخطوات التالية (“رائع، تم استلام الهوية والتحقق منها.” أو “لم أتمكن من التحقق من الهوية، هل يمكنك المحاولة مرة أخرى أو استخدام مستند آخر؟”). هذا التفاعل يقلل من معدلات الانسحاب من العملية ويمنح تجربة تشبه التعامل مع موظف بنك حقيقي ولكن بطريقة رقمية ذاتية الخدمة.

مقابلات KYC والتدفقات الديناميكية: في حالات الانضمام الأكثر تعقيدًا أو عالية المخاطر (مثل حسابات الشركات)، يمكن للدردشة إجراء مقابلة KYC. قد يسأل: “هل يمكنك وصف طبيعة عملك؟” أو “من هم الملاك الرئيسيون للشركة؟” ويجمع البيانات بشكل محادثي. إذا كانت إجابات العميل تُظهر عوامل مخاطرة (مثل التعامل النقدي أو وجود شركة أم في الخارج)، يمكن للروبوت أن يفرّع الحوار تلقائيًا إلى أسئلة إضافية تتعلق بالفحص المعزز (EDD). يعتمد هذا التدفق الديناميكي على الذكاء الاصطناعي لفهم إجابات المستخدم المختلفة. على سبيل المثال، إذا سُئل عن مصدر الأموال وكتب المستخدم شرحًا طويلاً، يستطيع الذكاء الاصطناعي تحليل التفاصيل الرئيسية وطرح أسئلة متابعة إذا كان هناك غموض (“ذكرت أن التمويل من الإيرادات والمستثمرين – هل يمكنك تقدير النسبة من المستثمرين وهل هم محليون أم أجانب؟”). هذا الأسلوب التفاعلي يشبه إلى حد كبير ما يفعله موظف الامتثال البشري، ولكن بشكل مؤتمت.

يتم حفظ جميع المعلومات المجمعة في ملف (KYC) الخاص بالعميل بشكل منظم. في الوقت نفسه، يمكن للروبوت تقديم تغذية راجعة فورية أو توضيحات – مثلًا، إذا تردد المستخدم في الإجابة على سؤال (“لماذا أحتاج إلى الإجابة على هذا؟”)، يشرح له الروبوت أنه مطلب قانوني لفهم العميل. هذا يعزز الشفافية وراحة المستخدم.

فحوصات الامتثال الآلية عبر الدردشة: أثناء سير المحادثة، يقوم النظام الخلفي بإجراء الفحوصات المذكورة سابقًا (مثل قوائم العقوبات و(PEP)). يمكن جعل الذكاء الاصطناعي على دراية بنتائج هذه الفحوصات. على سبيل المثال، بعد أن يقدم المستخدم اسمه وبلده، يقوم النظام بتشغيل فحص العقوبات. إذا ظهر تطابق محتمل، يمكن للروبوت طرح أسئلة توضيحية: “لاحظنا وجود شخص خاضع للعقوبات يحمل اسمًا مشابهًا لاسمك. للتأكد من الامتثال، هل يمكنك تأكيد أنك لست [الاسم المدرج] المولود في [تاريخ الميلاد]؟”. إذا أجاب المستخدم “لا، هذا ليس أنا ولم أزر تلك الدولة”، يتم تسجيل ذلك في سجل الامتثال كمبرر لحالة التطابق السلبي. هذا الأسلوب يتيح معالجة الحالات الحساسة بشكل ذكي وسلس.

يمكن لـ ClefinCode Chat أيضًا جلب بيانات خارجية: مثل استعلام السجل التجاري للتحقق من الشركات. إذا ذكر المستخدم اسم شركته، يمكن للروبوت التحقق من وجودها وسحب أسماء المدراء، مما يسرّع عملية انضمام الشركات.

إخفاء المعلومات الشخصية والخصوصية (PII Masking and Privacy): يُعدّ الحفاظ على الخصوصية أمرًا حاسمًا. نقوم بتطبيق إخفاء البيانات الحساسة (PII masking) على مستويات متعددة[15]. تُزال أو تُخفي الأرقام الحساسة مثل رقم الهوية أو رقم الحساب (مثلاً، إظهار آخر 4 أرقام فقط). كما نضمن أن نموذج الذكاء الاصطناعي (سواء كان على السحابة أو مستضافًا داخليًا) لا يحتفظ ببيانات PII الكاملة. وإذا استخدمنا خدمات مثل (OpenAI)، فسيتم ذلك ضمن بيئة معزولة أو باستخدام التشفير لمنع تمرير البيانات الحساسة في النصوص. بالإضافة إلى ذلك، يتم تطبيق التحكم في الوصول بناءً على الدور (RBAC) بحيث لا يرى سوى الموظفين المخوّلين أو العميل نفسه بياناته الكاملة. وعند مراجعة المحادثة، يرى الموظف مثلًا “[رقم الهوية: XXXX1234 مخفي]”. ينسجم هذا النهج مع مبادئ الخصوصية ومتطلبات (GDPR). كما يلتزم الروبوت بمبدأ تقليل جمع البيانات، بحيث لا يطلب سوى ما هو ضروري.

نُدمج أيضًا فحوص منع تسرب البيانات (DLP) في الدردشة – على سبيل المثال، إذا حاول العميل إرسال رقم بطاقة ائتمان أو بيانات حساسة لا يحتاجها النظام، يكتشف الروبوت ذلك ويخفيها أو يُنبه المستخدم بعدم مشاركتها. ولأغراض الامتثال لـ (PCI DSS)، نتجنب تمامًا جمع أرقام البطاقات الكاملة عبر الدردشة الحرة[16].

مساعدة موظفي الامتثال (الاستخدام الداخلي): لا يقتصر ClefinCode Chat على العملاء فقط. يمكن استخدامه داخليًا من قبل الموظفين. على سبيل المثال، يمكن لموظف الامتثال أن يسأل الروبوت عن السياسات (“ما الحد الأدنى لتحديد المستفيدين الفعليين وفقًا لسياستنا؟”). إذا تم تغذية الروبوت بأدلة الامتثال واللوائح التنظيمية، فسيجيب بشكل متسق، مما يجعله مساعد سياسات ذكي (policy Q&A assistant) يوفر الوقت[15]. كما يمكن دمجه في نظام إدارة القضايا: إذ يستطيع المحقق أن يكتب “اعرض جميع المعاملات التي أجراها هذا العميل مع الدولة X خلال آخر 6 أشهر”، فيقوم الذكاء الاصطناعي باسترجاع البيانات المصرح بها فورًا. هذا التفاعل الطبيعي مع قاعدة البيانات يسرّع التحقيقات بشكل كبير.

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

التقنية والتكامل (Technology & Integration): يعتمد ClefinCode Chat على إطار (Frappe) كنظام إضافي قابل للتثبيت ضمن (ERPNext)[17][17]. ويوفر واجهة متعددة القنوات – أي أن نفس المحادثة يمكن أن تتم على موقع البنك، تطبيقه، أو عبر تطبيقات المراسلة مثل (WhatsApp) و(Telegram) وغيرهما، كما هو موضح في وصفه بسوق (Frappe)[17][17]. هذه الميزة مهمة لأنها تتيح للبنك التواصل مع العملاء في القنوات التي يفضلونها. ويُعد الأمان عنصرًا أساسيًا: فجميع الاتصالات تتم عبر قنوات مشفرة (بما في ذلك التشفير من الطرف إلى الطرف حيثما أمكن مثل (WhatsApp))، كما يقوم النظام الخلفي بتنقية البيانات والتحكم في تدفقها.

أما الذكاء الاصطناعي نفسه في الدردشة، فيمكن أن يكون هجينا: تدفقات محادثة محددة بالقواعد للخطوات الواضحة، مع استخدام نموذج لغوي كبير لفهم الأسئلة المفتوحة أو الإجابات غير المهيكلة. نضمن أن أي قرار متعلق بالامتثال يعتمد على منطق محدد وليس على استنتاجات الذكاء الاصطناعي وحده – مثلًا، لن يُسمح للذكاء الاصطناعي بالموافقة على عميل، بل سيجمع المعلومات فقط وفق القواعد. تساعد قدرات اللغة في الفهم متعدد اللغات وتوضيح نية المستخدم. في الواقع، تُعتبر ميزة التعدد اللغوي نقطة قوة – إذ يمكن للروبوت إجراء محادثة (KYC) بلغة العميل المفضلة، ثم ترجمة وتخزين المعلومات بالإنجليزية للبنك، مما يوسع الوصول ويوفر تجربة مرنة ومتوافقة[15].

الفوائد والمستقبل: من خلال نشر (ClefinCode Chat) لعمليات (onboarding)، نقوم بتقليص وقت الإعداد بشكل كبير مع الحفاظ على الامتثال. أشار تقرير من (Thomson Reuters) إلى أن التقنيات الحديثة في مجال الذكاء الاصطناعي يمكن أن تكون أفضل وسيلة دفاع ضد التهديدات المتطورة [2] – ويجسد روبوت الدردشة لدينا ذلك من خلال اكتشاف المشكلات مبكرًا (عبر الأسئلة الذكية والتحقق الفوري). مثال على سيناريو نجاح: بنك إقليمي يستخدم روبوت دردشة لعمليات (KYC onboarding) تمكن من تقليص وقت الإعداد والأخطاء، بالإضافة إلى إنشاء ملفات الحالات تلقائيًا مع جميع الأدلة المرفقة [15]. في حالتنا، عندما تنتهي الدردشة من جمع البيانات، نكون فعليًا قد أنشأنا ملف (KYC) رقميًا كاملًا لذلك العميل جاهزًا للتدقيق أو المراجعة التنظيمية. المحادثة نفسها تشكل سجل تدقيق (audit trail) – حيث نوثق الأسئلة التي تم طرحها وكيف أجاب العميل عليها، وهو أمر ذو قيمة في حال احتاج البنك لإثبات أنه حصل على معلومات حول مصدر الأموال مثلًا.

علاوة على ذلك، يمكن توسيع هذا النهج التفاعلي ليشمل التعاملات المستمرة: يمكن تنفيذ تحديثات (KYC) الدورية عبر الدردشة (“مرحبًا، لقد مر عام منذ آخر تحديث لمعلوماتك. هل حدث أي تغيير في عملك أو إقامتك الضريبية؟” وهكذا). وقد يجد العملاء أن هذا الأسلوب أكثر تفاعلية من النماذج الثابتة.

نستخدم الدردشة أيضًا في تفاعلات مراقبة المعاملات (transaction monitoring): إذا كانت معاملة معينة غير معتادة، بدلاً من رفع تقرير (SAR) فورًا، قد يسأل البنك العميل عبر روبوت الدردشة للحصول على توضيح (“لاحظنا تحويلًا كبيرًا إلى دولة Y. هل يمكنك توضيح الغرض بإيجاز؟”). يتم تسجيل الرد (مثلًا: “استثمار في عمل أحد الأقارب”)، ويمكن لموظف الامتثال استخدامه في التقييم. يجب تنفيذ ذلك بحذر ووفقًا للتوجيهات القانونية (إذ أن بعض الجهات لا تشجع على تنبيه العملاء بوجود شك). لكن في حالات الشذوذ البسيطة، يمثل هذا نهج خدمة عملاء لحل الإنذارات الخاطئة.

في الختام، يعمل (ClefinCode Chat) كـواجهة رقمية أمامية (digital front office) للعملاء ومساعد ذكي لموظفي الامتثال. فهو يستخدم الذكاء الاصطناعي لتبسيط الامتثال – سواء من خلال إرشاد المستخدم أثناء تعبئة نموذج معقد بلغة بسيطة أو استرجاع معلومات السياسة فورًا عند الطلب. يتم تنفيذ كل ذلك ضمن بيئة أمان من مستوى المؤسسات (مع الالتزام بضوابط (SOC 2) مثل مبدأ أقل صلاحية وإخفاء البيانات) [15]. ومع تطور التكنولوجيا، نتوقع استخدامات أكثر تقدمًا، مثل أن يقوم روبوت الدردشة بتنبيه العملاء استباقيًا بمتطلبات الامتثال (“أنت على وشك تلقي 100 ألف دولار – يرجى ملاحظة أننا سنطلب إثبات مصدر الأموال وفق اللوائح؛ يمكنك تجهيز المستندات مسبقًا.”) أو مساعدة البنك في اكتشاف الأنماط (“إجابات هذا العميل حول مصدر الأموال تغيّرت بشكل ملحوظ عن العام الماضي – ربما تحتاج للمراجعة”). يمثل تكامل (ClefinCode Chat) ضمن بنية النظام المصرفي الأساسي لدينا مثالًا على استراتيجيتنا في استخدام أدوات الذكاء الاصطناعي الحديثة لتعزيز، وليس استبدال، الإطار القوي للامتثال المدمج في النظام.

خدمات ClefinCode Cloud – بيئة استضافة آمنة ومتوافقة

يُقدَّم حل (ClefinCode) المصرفي الأساسي ليس فقط كبرنامج، بل كخدمة (ClefinCode Cloud) مستضافة على بنية تحتية آمنة وقابلة للتوسع. نظرًا لحساسية بيانات القطاع المصرفي والمتطلبات الصارمة للامتثال، تم تصميم بنية الاستضافة السحابية لدينا لتلبية أو تجاوز المعايير الصناعية المتعلقة بالأمان والخصوصية والتوافر. نُوائم خدماتنا مع شهادات مثل ISO 27001 وSOC 2 Type II، مستفيدين من بنية سحابية (AWS في حالتنا) المتوافقة بدورها مع هذه الأطر [5].

بنية آمنة بالتصميم (Secure-by-Design Architecture): تم بناء النشر السحابي لدينا على بنية متعددة الطبقات مع عزل قوي للشبكة. تُوضع قواعد البيانات وخوادم التطبيقات الإنتاجية في شبكات فرعية خاصة (بدون وصول مباشر للإنترنت)، وتُحمى بواسطة بوابات وخوادم موازنة تحميل آمنة. تُشفّر جميع البيانات أثناء السكون (تشفير كامل للأقراص بالإضافة إلى التشفير على مستوى الحقول الحساسة مثل كلمات المرور والمفاتيح والبيانات الشخصية). أما البيانات أثناء النقل فدائمًا ما تكون مشفرة عبر (TLS). نطبق نظام صارم لإدارة الهوية والوصول: لا يُسمح بالوصول إلى البنية التحتية إلا لموظفي (ClefinCode DevOps) المخولين، وحتى ذلك وفق نموذج أقل صلاحية (وصول عند الحاجة فقط مع سجلات تدقيق). داخل التطبيق، يتم إعداد التحكم بالوصول حسب احتياجات البنك (مع إمكانية استخدام ضوابط تعتمد على السمات إذا لزم الأمر، مثلًا أن دور الامتثال فقط يمكنه رؤية بيانات معينة) [4].

يخضع بيئتنا لاختبارات تقييم الثغرات واختبارات الاختراق (vulnerability assessments and penetration tests) بشكل دوري. كما نراقب باستمرار على مدار الساعة لاكتشاف أي محاولات اختراق أو أنشطة غير طبيعية. ومن منظور الأمان التشغيلي، ندمج السجلات وأنظمة (SIEM - Security Information and Event Management) بحيث تؤدي أي أنشطة غير معتادة (مثل قيام مسؤول بتنزيل بيانات ضخمة أو محاولات تسجيل دخول متكررة فاشلة) إلى إطلاق تنبيهات فورية.

التوافق مع المعايير (ISO 27001, SOC 2, PCI DSS, GDPR): من خلال الاستضافة على (AWS)، نحصل على قاعدة أمان قوية – إذ يوفّر امتثال (AWS) لمعايير (ISO 27001) و(SOC 2) أساسًا متينًا [5]. ومع ذلك، ونظرًا لنموذج المسؤولية المشتركة، فإننا نطبّق الضوابط على مستوى التطبيق والبيانات. لقد طورنا نظام إدارة أمن المعلومات (ISMS) وفق معايير (ISO 27001) يشمل تقييم المخاطر والسياسات والاستجابة للحوادث واستمرارية الأعمال وغيرها. تساعد ميزات النظام مثل سجلات التدقيق لأنشطة المستخدمين [4]، وتشفير البيانات، وضوابط الوصول في معالجة العديد من متطلبات (ISO) المتعلقة بإدارة الوصول وأمن البيانات. بالنسبة لمعيار (SOC 2)، فإننا نلتزم بمعايير خدمات الثقة الخمسة: الأمان، التوافر، سلامة المعالجة، السرية، الخصوصية. على سبيل المثال، نحقق معايير التوافر من خلال بنية (HA)، والنسخ الاحتياطية، وخطط التعافي من الكوارث؛ ومعايير السرية/الخصوصية من خلال التشفير وتقييد الوصول؛ ومعايير سلامة المعالجة من خلال ضمان اكتمال ودقة ومعالجة المعاملات في الوقت المناسب (مع آليات للمطابقة والتعامل مع الأخطاء).

التوافر العالي (HA) والتعافي من الكوارث (DR): تتطلب البنوك خدمة شبه مستمرة (خدمة 24/7). تم تصميم سحابتنا بمرونة عالية – خوادم تطبيق متعددة خلف موزعات تحميل، ومجموعات قاعدة بيانات ذات تحويل تلقائي في حالة الفشل (مثل استخدام (AWS Aurora) أو (PostgreSQL) مع النسخ المتزامن بين المناطق). نستهدف عدم فقدان البيانات (RPO ≈ 0) باستخدام النسخ المتزامن قدر الإمكان، وأقل فترة توقف (RTO بالدقائق) بفضل التحويل التلقائي [4][4]. كما يمكننا النشر في مناطق متعددة (للعملاء الذين يتطلب تنظيمهم أو عملياتهم وجود نسخ متعددة الأقاليم). ومع أن بعض الجهات التنظيمية تفرض إقامة البيانات داخل الدولة، فإننا ندعم أيضًا اختيار المنطقة. تُؤخذ النسخ الاحتياطية يوميًا وداخل اليوم الواحد، ويمكن استعادتها في بيئات معزولة لاختبار إجراءات الاستعادة. وقد تم توضيح هذه الميزات في بنيتنا المستهدفة، ونطبقها في الخدمة السحابية لضمان استمرار الخدمة حتى لو تعطّل مركز بيانات بالكامل.

تعدد العملاء والعزل (Multi-Tenancy and Isolation): يمكن لمنصة (ClefinCode Cloud) العمل بنموذج متعدد العملاء (عدة بنوك ضمن عنقود مشترك مع فصل منطقي لكل عميل) أو بنموذج العميل الواحد (كل بنك في بيئته الخاصة). ندرك أن بعض البنوك – لأسباب تنظيمية أو متعلقة بالمخاطر – تفضل بيئات مخصصة، لذا نوفر هذا الخيار، بما في ذلك إمكانية النشر على سحابة خاصة أو في الموقع (on-premise) مع دعمنا في عملية الإعداد وفق نفس المعايير. في الإعدادات متعددة العملاء، نطبق فصلًا صارمًا للبيانات داخل البرمجيات، مع مراقبة إضافية لضمان عدم تجاوز البيانات للحدود. حتى البيانات الوصفية والذاكرة المؤقتة يتم فصلها حسب العميل. كما نعزل عمليات المعالجة – بحيث لا تؤثر الأحمال الثقيلة من بنك على آخر بفضل نظام الحصص والتوسع التلقائي.

التدقيق والشفافية: للبنوك التي تستخدم خدماتنا السحابية، نوفر مستوى عالٍ من الشفافية لتسهيل تقييم المخاطر الخاصة بالمورد. على سبيل المثال، يمكننا تقديم تقرير (SOC 3) أو شهادة مختصرة من (AWS) كدليل على أمان البنية التحتية [5][5]. بالإضافة إلى ذلك، نقوم بتوثيق ضوابطنا الداخلية ويمكننا دعوة مدققي حسابات البنك لمراجعتها إذا لزم الأمر (قد تقوم بعض البنوك بإجراء تدقيق خاص بها لنا – ونحن نتعاون في ذلك). كما نحافظ على السجلات التي يمكن للبنك الاطلاع عليها لتلبية احتياجاته التدقيقية – مثل سجلات كل وصول إداري إلى بياناته، وسجلات أنشطة التحديث والإصلاح وغيرها.

خصوصية البيانات و(GDPR): بالنسبة لأي بيانات شخصية نستضيفها، تنطبق قوانين (GDPR) والقوانين المشابهة. نحن نعمل كمعالج بيانات للبنك (حيث يكون البنك هو المتحكم بالبيانات). تتضمن خدماتنا السحابية ميزات تدعم حقوق أصحاب البيانات: يمكن للنظام استرجاع جميع بيانات العميل الشخصية عبر الوحدات بسرعة (لتسهيل طلبات الوصول للبيانات) [4]، كما قمنا ببناء وظائف لإخفاء هوية البيانات أو حذفها عند الطلب (مع مراعاة متطلبات الاحتفاظ القانونية). وإذا طلب العميل ممارسة “حق النسيان”، يمكن لأداة حذف البيانات في نظامنا إخفاء معرفاته الشخصية مع الاحتفاظ بالسجلات التشغيلية (التي غالبًا يجب الاحتفاظ بها لأسباب تنظيمية) [4][4]. كما نضمن أن جميع النسخ الاحتياطية والسجلات يتم حذفها تلقائيًا بعد انتهاء فترات الاحتفاظ القانونية.

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

(PCI DSS – Payment Card Industry Data Security Standard): إذا شمل النظام المصرفي الأساسي لدينا إصدار بطاقات أو معالجة بيانات بطاقات الدفع، فإننا نعزل ذلك الجزء ضمن بيئة متوافقة مع (PCI). عادةً لا يتم تخزين أرقام البطاقات (PAN) داخل النظام الأساسي (حيث يتولى نظام إدارة البطاقات ذلك). ولكن في الحالات التي نتعامل فيها مع بيانات البطاقات (مثل تخزين رقم البطاقة المشفر أو آخر 4 أرقام فقط)، نتبع إرشادات (PCI) – من تقسيم الشبكات، وتطبيق قواعد جدار حماية صارمة، إلى الامتناع عن تخزين بيانات التوثيق الحساسة. ونظرًا لأن (ClefinCode Chat) ومكونات أخرى قد تلتقط أرقام البطاقات بالخطأ (إذا كتبها المستخدم في الدردشة)، ندمج نظام (DLP) لإخفائها كما ذُكر [16]، مما يساعد على الحفاظ على امتثال (PCI) من خلال منع تخزين أرقام البطاقات الكاملة في سجلات الدردشة.

نماذج النشر السحابي – (AWS) أو (On-Prem): نعتمد في الأساس على (AWS) باستعمال بنية معيارية (مثل (Kubernetes) أو (Frappe Bench) بالحاويات، مدعومة بـ (AWS RDS) لقاعدة البيانات، و(S3) لتخزين المستندات، وغيرها). ومع ذلك، ندرك أن بعض البنوك، خاصة في بعض الدول، قد تفضل أو تُلزم بتنفيذ الحل محليًا (on-premise) أو على سحابة خاصة لأسباب تنظيمية أو تفضيلية. تم تصميم بنيتنا لتكون (cloud-native) ولكن غير مرتبطة بمزوّد سحابة محدد – مما يعني أنه يمكن نشرها على مركز بيانات خاص أو مزود آخر. بالنسبة للأنظمة المحلية، نوفر أدوات بنية تحتية ككود (infrastructure-as-code) وحاويات جاهزة لتشغيلها بإشراف قسم تقنية المعلومات لدى البنك مع دعمنا. كما نضمن أن النشر المحلي يطبق معايير الأمان نفسها (مثل أفضل ممارسات (Linux security) وتشفير قاعدة البيانات). ويمكننا أيضًا السعي للحصول على شهادة (ISO 27001) للحل كما تم نشره في بيئة البنك إذا لزم الأمر، من خلال توثيق الضوابط واختبارها ضمن تلك البيئة.

المراقبة والدعم: تتضمن (ClefinCode Cloud) نظام مراقبة شامل – على مستوى البنية التحتية (المعالج، الذاكرة، التخزين، الشبكة) وعلى مستوى التطبيق (زمن الاستجابة، معدلات أخطاء المعاملات، إلخ). قمنا بإعداد نظام تنبيهات يضمن معالجة أي مشكلة غالبًا قبل أن يلاحظها العميل. ولأغراض الامتثال، يُعد التوافر عنصرًا أساسيًا – حيث تطلب العديد من الجهات التنظيمية الإبلاغ عن حالات الانقطاع، لذلك نعمل على منعها، ونحتفظ بسجلات عند حدوث أي تدهور جزئي في الأداء (مع الأسباب والإجراءات التصحيحية). يتوفر فريق الدعم لدينا للبنوك العملاء، كما يمكنهم استخدام (ClefinCode Chat) للتواصل مع الدعم أو الاطلاع على الوثائق.

التحديثات المستمرة وإدارة التصحيحات: من مزايا الخدمة السحابية إمكانية تطبيق التحديثات الأمنية وتحديثات البرمجيات مركزيًا. لدينا برنامج صيانة لتحديث النظام باستمرار (بالاتفاق مع البنك على الجدول الزمني عادة). تُطبق التصحيحات الأمنية فورًا (وفق السياسة – مثل التصحيحات الحرجة خلال 24 ساعة). نعمل بشفافية ونحتفظ ببيئة اختبار لتجربة التحديثات قبل تطبيقها على بيئة الإنتاج لتفادي أي تعطل. هذا يضمن أن النظام محدث دائمًا ضد التهديدات، وهو مطلب أساسي في أطر مثل (SOC 2) التي تتوقع معالجة الثغرات في الوقت المناسب.

باختصار، لا تقتصر (ClefinCode Cloud Services) على تقديم خوادم لتشغيل برمجياتنا – بل هي منصة جاهزة للامتثال من البداية. من خلال إسناد إدارة البنية التحتية والأمان لنا، يمكن للبنوك (وخاصة الصغيرة أو الرقمية الحديثة) التركيز على عملياتها مع الثقة بأن النظام الأساسي يفي بمتطلبات الجهات التنظيمية. يمكنهم الاعتماد على شهاداتنا وممارساتنا أثناء عمليات التدقيق الخاصة بهم. لقد أصبح المنظمون أكثر تقبلاً للحلول السحابية عندما تكون آمنة ومبنية على الشفافية مع احتفاظ البنك بالرقابة. تم بناء خدمتنا السحابية بهذا المفهوم: نحن شفافون، نوفر خيارات لتحديد موقع البيانات، وملتزمون تعاقديًا بمعايير الأمان. كما نلتزم بمتطلبات الامتثال المحلي – مثلًا للبنوك في الإمارات يمكننا الاستضافة في مراكز بيانات داخل الدولة وفق توجيهات المصرف المركزي؛ وللبنوك في الاتحاد الأوروبي نضمن تطبيق بنود المعالجة وفق (GDPR) وغيرها.

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

ختامًا، تجمع (ClefinCode Cloud) بين المرونة والابتكار في التكنولوجيا السحابية والضوابط الصارمة لتقنية المعلومات المصرفية. فهي آمنة (تفي بأعلى المعايير)، متاحة (بتصميم (HA))، قابلة للتوسع (لمواكبة النمو أو الحجم العالي للعمليات)، ومتوافقة (تدعم البنك في التزاماته التنظيمية). من خلال اختيار سحابتنا، يحصل البنك فعليًا على بيئة خضعت مسبقًا للتدقيق وتساعده في طمأنة الجهات التنظيمية والعملاء بأن بياناتهم آمنة وأن النظام موثوق. يكمل هذا النهج الاستضافة الجوانب الوظيفية المدمجة في البرنامج المصرفي الأساسي لدينا، ليشكل عرضًا متكاملًا من البداية للنهاية.

3. نظرة مستقبلية وتوقعات

عند النظر إلى السنوات 5–10 القادمة، نتوقع تطورًا كبيرًا في كيفية تعامل الأنظمة المصرفية الأساسية مع العملاء وعمليات (onboarding) والامتثال – مدفوعًا بالتقدم في التكنولوجيا (كالذكاء الاصطناعي، وتقنيات (distributed ledgers) وغيرها) وكذلك التغيرات المستمرة في اللوائح التنظيمية. نستعرض هنا كيف يمكن لـ (ClefinCode) والمنصات المشابهة أن تتطور وتقود هذه الاتجاهات مستقبلًا:

الامتثال و(Onboarding) المدعوم بالذكاء الاصطناعي: سينتقل الذكاء الاصطناعي من المساعدة إلى التعزيز والأتمتة الجزئية لاتخاذ القرار في الامتثال. نستخدم اليوم روبوتات الدردشة لجمع المعلومات، لكن ذكاء المستقبل سيقوم بتقييم المخاطر للعملاء بشكل ديناميكي من خلال تحليل كميات هائلة من البيانات (الوجود الرقمي، الاتجاهات الاقتصادية، تحليل الشبكات الاجتماعية) خلال ثوانٍ. على سبيل المثال، قد تتضمن عملية (onboarding) مستقبلاً ذكاءً اصطناعيًا يمكنه التحقق من هوية العميل بمطابقة مصادر بيانات متعددة (قواعد بيانات الهوية الرقمية الحكومية، والسجلات العامة) تقريبًا بشكل فوري وبمستوى دقة أعلى من الفحص اليدوي. وقد نشهد ظهور مفهوم الهوية الرقمية الحقيقية (digital KYC identity): حيث يمكن للعميل الحصول على رمز هوية رقمية صادر من جهة حكومية أو سلطة موثوقة، وتصبح عملية (onboarding) مجرد موافقة العميل على مشاركة هذا الرمز – دون الحاجة لإعادة رفع المستندات في كل مرة. يمكن لـ (ClefinCode) التكامل مستقبلًا مع أنظمة الهوية الرقمية الوطنية أو أدوات (digital KYC).

سيساهم الذكاء الاصطناعي أيضًا بشكل كبير في مراقبة المعاملات. فبدلاً من الاعتماد على القواعد التقليدية (التي يتعلم المجرمون كيفية تجاوزها)، ستكتشف نماذج التعلم الآلي (بما فيها التعلم العميق) الأنماط غير الطبيعية في تدفقات المعاملات التي قد لا يلاحظها المحللون البشر. قد تدرس تسلسل الأحداث وشبكات الأطراف المقابلة، وتكشف مخططات تبييض أموال معقدة. هذا يمكن أن يُحسّن بشكل كبير من اكتشاف حالات التلاعب المعقدة التي قد تفلت اليوم. في الوقت نفسه، سيستخدم المجرمون الذكاء الاصطناعي (كما هو مذكور، مثل (deepfakes) للهوية، أو الذكاء لتنظيم المعاملات بذكاء) [2]، مما يجعلها سباقًا تقنيًا مستمرًا. نتوقع أن يبدأ المنظمون قريبًا بالموافقة أو التوصية باستخدام أساليب معينة من الذكاء الاصطناعي (بعد معالجة قضايا الشفافية والتحيز). قد تدمج (ClefinCode) مستقبلاً تقنيات (federated learning) أو مشاركة البيانات ضمن اتحادات (بطرق تحافظ على الخصوصية) لجعل نظام مكافحة غسيل الأموال أكثر ذكاءً – مثل التعلم من الأنماط المكتشفة عبر مؤسسات متعددة وليس من بنك واحد فقط.

الامتثال المدمج و«الأمان بالتصميم (Security by Design)»: نتوقع اتجاهًا متزايدًا نحو دمج الامتثال في كل معاملة في الوقت الفعلي – ويُطلق عليه أحيانًا الإشراف المدمج (embedded supervision) أو تكنولوجيا التنظيم 2.0 (regulation technology 2.0). على سبيل المثال، في المعاملات القائمة على العقود الذكية أو (blockchain)، يمكن أن يكون المنظمون أو أنظمة الذكاء الاصطناعي الخاصة بالامتثال في البنك عقدًا داخل هذه الشبكات، تتحقق تلقائيًا من المعاملات عند حدوثها. ويبرز هنا مفهوم «RegTech على blockchain»، حيث يمكن إعداد بعض التقارير التنظيمية تلقائيًا من دفتر أستاذ موزع. وبحلول عام 2030، سيصبح الامتثال المعزز بالذكاء الاصطناعي هو القاعدة، وقد نشهد حتى أن الجهات التنظيمية تتلقى تدفقات بيانات مستمرة بدلاً من تقارير دورية [14]. قد يتكامل (ClefinCode) مع مثل هذه الأنظمة (DLT) المصرح بها لتقارير البنوك البينية أو لاستخدام (blockchain) لمشاركة بيانات (KYC) بين البنوك (بموافقة العميل). مثال على سيناريو: عدة بنوك تساهم في أداة (KYC) مشتركة على (blockchain) – بمجرد أن يتحقق أحد البنوك من هوية العميل (ويُسجل هذا التحقق كرمز أو شهادة على السلسلة)، يمكن لبنك آخر إتمام عملية (onboarding) بنقرة واحدة عبر الوثوق بذلك السجل (مع تحديث المعلومات المتغيرة فقط). هذا يمكن أن يقلل بشكل كبير من تكرار جهود (KYC).

تقنيات تعزيز الخصوصية: مع مشاركة البيانات واستخدام الذكاء الاصطناعي يأتي تحدي الخصوصية. يمكن للأنظمة المصرفية المستقبلية استخدام تقنيات مثل التشفير المتماثل الكامل (homomorphic encryption) أو الحوسبة الآمنة متعددة الأطراف (secure multi-party computation)، مما يسمح بتحليل البيانات (لمكافحة غسل الأموال، تقييم الائتمان، إلخ) عبر مؤسسات متعددة دون الكشف عن البيانات الأصلية. على سبيل المثال، قد تقوم البنوك بتشغيل نموذج تعلم آلي مشترك لاكتشاف ما إذا كان العميل يقوم بتقسيم المعاملات عبر بنوك متعددة، ولكن بطريقة مشفرة لا تكشف بيانات أي بنك إلا عند تجاوز حد معين للمخاطر.

تمكين العميل وتجربة الاستخدام (UX): من المرجح أن يحمل المستقبل عملية امتثال مرتكزة على العميل. قد يمتلك العملاء خزائن بيانات مالية شخصية يتحكمون بها بأنفسهم، يمنحون من خلالها وصولًا مؤقتًا للبنوك. وقد تصبح عملية (onboarding) بسيطة مثل نقر العميل على “مشاركة هويتي المعتمدة وملف (KYC) الخاص بي مع هذا البنك” عبر محفظة رقمية (على غرار الجوازات الرقمية أو بيانات الاعتماد الموثقة في التطبيقات). سيتكيف (ClefinCode) لقبول والتحقق من هذه الاعتمادات بدلاً من جمع البيانات الأولية بشكل متكرر. هذا يُحوّل النموذج إلى مبدأ “تحقق مرة، واستخدم عدة مرات”. الجهات التنظيمية في بعض المناطق (مثل أوروبا) تدفع بالفعل نحو أطر الهوية الرقمية؛ ومن خلال تبنيها، يظل النظام في طليعة التطور.

المراقبة المستمرة للعملاء والمشاركة: بدلاً من مراجعات (KYC) الدورية (كل 1–3 سنوات مثلاً)، قد تتحول البنوك إلى المراقبة المستمرة لملفات العملاء باستخدام البيانات المفتوحة. على سبيل المثال، مراقبة الأخبار السلبية في الوقت الفعلي لجميع العملاء (تحليل الذكاء الاصطناعي للأخبار التي تذكر العملاء أو أعمالهم). إذا وُجهت تهمة جريمة مالية لعميل، يمكن للنظام معرفة ذلك في اليوم نفسه عبر المراقبة الإخبارية بالذكاء الاصطناعي، ورفع مستوى المخاطر تلقائيًا وربما تجميد الأنشطة عالية المخاطر مؤقتًا لحين المراجعة. يمثل هذا الانتقال من إدارة المخاطر التفاعلية إلى الاستباقية. يمكن لـ (ClefinCode) التكامل مع قواعد بيانات إعلامية وقانونية عالمية للحفاظ على قوائم مراقبة محدثة لأسماء العملاء، باستخدام تقنيات معالجة اللغة الطبيعية لتقليل التطابقات الخاطئة.

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

تكامل أعمق مع الخزينة وإدارة الأصول والالتزامات (ALM): في الجانب المالي والخزينة، ستعمل الأنظمة المستقبلية على محاكاة سيناريوهات الضغط باستمرار. مع توفر بيانات أكثر في الوقت الفعلي (ربما بفضل (CBDC) أو أنظمة المدفوعات الفورية)، يمكن للنظام الأساسي تنبيه الخزينة مبكرًا بشأن مؤشرات نقص السيولة. يمكن للذكاء الاصطناعي تحسين احتياطات السيولة أو اقتراح استراتيجيات التحوط. على سبيل المثال، من خلال تحليل آلاف السيناريوهات، قد يقترح الذكاء الاصطناعي على البنك تعديلات مثالية في المحفظة لتحقيق أعلى عائد مع الحفاظ على متطلبات السيولة وفقًا لمعايير (Basel) – وهي مهام كانت تُدار يدويًا في لجان (ALM).

الاستعانة بمصادر خارجية للامتثال: قد نشهد انتشار مفهوم الامتثال كخدمة (compliance-as-a-service) – مثل أدوات (KYC) المشتركة، أو مراكز مراقبة المعاملات المشتركة خاصة للبنوك الصغيرة. وبحلول عام 2030، قد يصبح الاستعانة بمصادر خارجية للامتثال أمرًا اعتياديًا للبنوك المجتمعية التي تعتمد على مثل هذه الخدمات لإدارة المراقبة اليومية [18]. يمكن لـ (ClefinCode) أن تتموضع لتتكامل مع مثل هذه المرافق أو حتى تستضيفها – مثل تقديم منصة مشتركة لمؤسسات متعددة، حيث تُفصل بيانات كل بنك بينما يتعلم الذكاء الاصطناعي من البيانات المجمعة لاكتشاف الأنماط النظامية. قد يتقبل المنظمون هذا النموذج إذا أدى إلى تحسين الامتثال العام (إذ يشجعون بالفعل مشاركة المعلومات عبر وحدات الاستخبارات المالية). بالطبع، يجب إدارة الخصوصية بعناية (بحيث تُشارك المؤشرات فقط وليس البيانات الكاملة).

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

(Blockchain) والعقود الذكية: لطالما طُرحت فكرة استخدام (blockchain) في العمليات المصرفية – مثل تمويل التجارة، التسوية بين البنوك، وحتى دفاتر الحسابات الأساسية. ورغم أن المصارف التجزئية قد لا تنتقل بالكامل إلى (blockchain) بسبب مشكلات الأداء والخصوصية، إلا أن بعض المجالات المتخصصة قد تفعل. مستقبلًا، إذا تم تحويل بعض الأصول أو العقود (مثل القروض المشتركة أو المشتقات المعقدة) إلى (blockchain)، فسيحتاج نظامنا للتكامل معها. قد يدمج (ClefinCode) وحدة الأصول الرقمية (digital asset module) مستقبلًا – مما يتيح للبنك دعم المحافظ الخاصة بالعملات المشفرة أو (CBDC) ضمن الحسابات. العديد من البنوك المركزية تستكشف (CBDCs)؛ وإذا أصبحت واقعًا، يجب أن تدمج الأنظمة المصرفية الأساسية معاملات (CBDC) جنبًا إلى جنب مع المعاملات التقليدية. قد لا يلاحظ المستخدم أي فرق سوى أن بعض المعاملات تتم بالنقد الرقمي؛ لكن في الخلفية، يجب على الامتثال تتبع تدفقات (CBDC) (وقد يكون ذلك أسهل إذا كانت قابلة للتتبع). قد نحتاج إلى تكييف نماذج مكافحة غسل الأموال لمراقبة العملات الرقمية ودمج التحليلات التي توفرها البنوك المركزية بشأن (CBDC).

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

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

التقارب العالمي للمعايير: خلال العقد القادم، قد نشهد مزيدًا من التوحيد بين المعايير العالمية للامتثال. على سبيل المثال، تبني مزيد من الدول أنظمة مشابهة لـ (FATCA/CRS)، أو تطبيق القواعد النهائية لـ (Basel IV)، أو توحيد معايير الهوية الرقمية. هذا يمكن أن يتيح لمزودي البرامج مثلنا بناء وحدات قياسية تعمل في عدة دول مع تعديلات بسيطة. قد تقدم (ClefinCode) “حزمة امتثال عالمية أساسية” تفي بتوصيات (FATF) افتراضيًا، مع إمكانية التخصيص المحلي. وإذا تعاونت الجهات التنظيمية على أدوات (KYC) أو قوائم سوداء مشتركة (مثل قاعدة بيانات (PEP) عالمية تُدار من جهة دولية)، فسيتكامل نظامنا معها مباشرة بدلاً من أن يعمل كل بنك بشكل منفصل.

الذكاء الاصطناعي الأخلاقي وقابلية التفسير: مع الاعتماد المتزايد على الذكاء الاصطناعي في الامتثال (مثل تقييم المخاطر واتخاذ القرارات)، سيطالب المنظمون بـالشفافية والتفسير لهذه القرارات لضمان عدم وجود تحيز غير قانوني (ضد فئات محمية مثلًا) وللسماح للعملاء بالاعتراض. ستتضمن أنظمتنا المستقبلية ذكاءً اصطناعيًا يمكنه تقديم التفسير (“تم رفض هذا القرض لأن التدفق النقدي للعميل غير كافٍ وفقًا لتحليل بيانات الحساب وتقييمه الائتماني أقل من الحد؛ العوامل المساهمة كانت X وY.”). سنحتفظ بهذه الأسباب لأغراض التدقيق. وبالمثل، إذا أشار الذكاء الاصطناعي إلى معاملة مشبوهة، فسيُظهر “السمات” التي أدت لذلك (مثل “تحويلات متعددة إلى دولة عالية المخاطر خلال فترة قصيرة”). هذا يجعل الذكاء الاصطناعي أداة تعاونية مع البشر وليس صندوقًا أسود غامضًا، وهو أمر أساسي للثقة والقبول التنظيمي.

ثقافة الامتثال والتدريب عبر التكنولوجيا: الثقافة أمر غير ملموس، لكن التكنولوجيا يمكن أن تساعد. قد تتضمن الأنظمة المستقبلية تدريبًا تفاعليًا على الامتثال مدمجًا في سير العمل اليومي – مثل نوافذ منبثقة للموظفين الأماميين (“هل ستتجاهل هذا التحذير؟ نعم/لا”)، وتُستخدم إجاباتهم لتحديد احتياجات التدريب. قد يحاكي النظام أيضًا سلوكيات مشبوهة معينة لاختبار التزام الموظفين بالإجراءات. هذه الميزات تتجاوز وظائف النظام الأساسية، لكنها جزء من نهج شمولي يدمج الامتثال في البيئة التشغيلية.

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

وباختصارها في عبارة واحدة، قد يعمل النظام المصرفي الأساسي المستقبلي كـالطيار الآلي (autopilot): يراقب الأفق باستمرار (المعاملات، الأخبار، السلوكيات) لاكتشاف الاضطرابات (المخاطر) ويضبط المسار (الضوابط) تلقائيًا، مع بقاء المشغلين البشريين (ضباط الامتثال) للإشراف والتعامل مع الاستثناءات. البنوك التي تتبنى هذه القدرات المستقبلية لن تكتفي بالامتثال التنظيمي فحسب، بل ستتقدم أيضًا خطوة للأمام، محوّلة الامتثال إلى ميزة استراتيجية. وكما جاء في أحد التعليقات: “مستقبل الامتثال التنظيمي حتى عام 2030 يتمحور حول (AI-augmented RegTech) و(embedded supervision)” [14] – ونحن نتفق تمامًا مع هذا الاتجاه ونعمل على جعل (ClefinCode) عنصرًا رئيسيًا في تمكين هذا المستقبل.

Global Digital Vibes