منصة (ERPNext) إلى النظام المصرفي الأساسي: الملخص التنفيذي والهيكلية المستهدفة

الملخص التنفيذي

(ERPNext)، وهو نظام (ERP) مفتوح المصدر وقوي، يحتاج إلى تحسينات كبيرة لتلبية متطلبات نظام مصرفي أساسي. بينما يبرع (ERPNext) في المحاسبة العامة وعمليات المؤسسات، إلا أنه يفتقر إلى الوظائف المصرفية المتخصصة وميزات الامتثال. تشمل الفجوات الرئيسية المحاسبة وفقاً للمعايير التنظيمية للأدوات المالية (IFRS 9/IAS 39) المتعلقة بالخسائر الائتمانية المتوقعة والمحاسبة عن التحوط، إدارة المخاطر وفق بازل III/IV، إدارة مخصصة للموجودات والالتزامات (ALM) والعمليات المالية، معالجة المدفوعات (ISO 20022/SWIFT)، الامتثال الصارم لمتطلبات KYC/AML/CTF، التكامل مع التقارير الضريبية (FATCA/CRS) وفحص العقوبات، وضوابط متقدمة للأمن/الخصوصية. هذه الجوانب تتجاوز الوحدات القياسية في (ERP) ويجب أن تتم إضافتها أو توسيعها في (ERPNext) لتحويله إلى منصة مصرفية أساسية آمنة وقابلة للتوسع.

رؤية الهيكلية: الهيكلية المستهدفة هي منصة معيارية مدفوعة بالأحداث مبنية على إطار عمل (ERPNext) القابل للتوسع، ومدعمة بوحدات وخدمات مخصصة للقطاع المصرفي. وهي تتبع مبادئ الهيكلية الحديثة (سحابي-أصلي، تصميم قائم على (API)، توفر عالٍ، وإمكانية استخدام (microservices) بشكل اختياري) مشابهة للأنظمة المصرفية المفتوحة المصدر الرائدة مثل (Apache Fineract)[1]. سيتولى النظام الأساسي إدارة العملاء، الحسابات، القروض، المدفوعات، مراكز الخزينة، وعمليات الامتثال، مع تسجيل جميع المعاملات المصرفية الأساسية في دفتر أستاذ عام مركزي. سيضمن دعم (Command Query Responsibility Segregation - CQRS) وأنماط المنصات المدفوعة بالأحداث القدرة على التوسع وإمكانية التدقيق، بما يتماشى مع النهج المستخدم في محرك (Fineract)[2]. سيتم تكرار البيانات باستمرار لتعزيز المرونة، بهدف تصفير فقدان البيانات (RPO ~0) وتقليل التوقف (RTO بالدقائق) من خلال نشر متعدد المناطق ومتعدد الأقاليم. ستدعم المنصة نشر (SaaS) متعدد العملاء أو التثبيت المحلي حسب احتياجات البنك[2]، وسيتم تسويقها كـClefinCode Cloud Services عند استضافتها على (AWS).

المنتج الأدنى القابل للتطبيق (MVP) وخارطة الطريق: المنتج الأدنى القابل للتطبيق – المرحلة 1 – سيقدم وظائف مصرفية أساسية لمؤسسة مالية صغيرة (مثل بنك رقمي أو اتحاد ائتماني). يشمل ذلك إدخال العملاء مع (KYC)، الحسابات الأساسية للودائع (توفير/جارٍ) وحسابات القروض، دفتر أستاذ موحد مع قيود محاسبية متوافقة مع (IFRS)، تحويلات مدفوعات أساسية، وفحوصات امتثال أولية (فحص العقوبات، سجلات التدقيق). العناصر التأسيسية مثل التحكم في الوصول القائم على الأدوار، التشفير، وإطار التكامل مع الخدمات الخارجية (مثل التحقق من الهوية) هي جزء من (MVP) لضمان الأمان والامتثال منذ اليوم الأول. المرحلة 2 ستتوسع إلى حزمة كاملة: دعم منتجات أكثر تعقيداً (الودائع لأجل، بطاقات الائتمان)، وحدات التقارير التنظيمية (إفصاحات IFRS 7، نسب رأس المال والسيولة بازل III)، محرك مراقبة المعاملات (AML) المطور، والتكامل مع شبكات الدفع الخارجية (SWIFT ISO 20022 للمدفوعات العابرة للحدود). سيطور (ClefinCode Chat AI) للتعامل مع مسارات العملاء الموجهة (مثل إرشاد العميل خلال فتح حساب أو طلب قرض) ومساعدة موظفي الامتثال عبر الإجابة عن الأسئلة أو الإشارة إلى الشذوذ. المرحلة 3 تتصور منصة قابلة للتوسع بالكامل ومؤممة دولياً: دعم العملات المتعددة، الامتثال المتعدد للأنظمة (مثل دول مجلس التعاون الخليجي)، أدوات متقدمة للخزينة/إدارة الموجودات والالتزامات (اختبارات ضغط السيولة، تحليلات مخاطر أسعار الفائدة)، وربما الانتقال إلى (microservices) لتوسيع الوحدات بشكل مستقل عند الحاجة. بحلول المرحلة 3، سيضاهي النظام الأنظمة المصرفية الأساسية الراسخة من حيث الوظائف، مع الاستفادة من نقاط قوة (ERPNext) (قابلية التوسع والتكامل مع وظائف (ERP)) لتقديم حل مصرفي متكامل.

الفجوات الرئيسية بين (ERPNext) ومتطلبات الأنظمة المصرفية الأساسية

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

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

3. الامتثال التنظيمي بازل III/IV: يجب على البنوك حساب رأس المال التنظيمي والأصول المرجحة بالمخاطر وفق معايير بازل، وهو ما لا يقدمه (ERP). الميزات التي يجب إضافتها تشمل تتبع معلمات بازل II/III لكل تعرض (أوزان مخاطر الائتمان، بيانات المخاطر التشغيلية، إلخ) وحساب نسب رأس المال. على سبيل المثال، في النهج القياسي لمخاطر الائتمان، يجب أن يخزن النظام وزن المخاطرة لكل قرض (بناءً على نوع الطرف المقابل وتصنيفه) ويجمع الأصول المرجحة بالمخاطر (RWA). بالنسبة للنهج المتقدم (IRB)، يلزم التكامل مع النماذج الداخلية (أو إدخال (PD, LGD, EAD) لكل قرض). كما قدمت بازل III مؤشرات السيولة – نسبة تغطية السيولة (LCR) ونسبة التمويل المستقر الصافي (NSFR) – والتي تتطلب تصنيف الأصول والخصوم حسب آجال السيولة[3]. يجب أن يكون النظام قادراً على إنشاء تقارير (LCR) (مثل حساب التدفقات الخارجة لمدة 30 يوماً مقابل الأصول السائلة عالية الجودة) وتقارير (NSFR) (التمويل المستقر المتاح مقابل المطلوب على مدى عام). بالإضافة إلى ذلك، هناك حاجة لتتبع نسبة الرافعة المالية (رأس مال الشريحة الأولى/إجمالي التعرض) واحتياطيات رأس المال. قد يتم تنفيذ العديد من هذه الحسابات في وحدة مخاطر منفصلة أو عبر التكامل مع أدوات تحليل المخاطر، ولكن يجب على النظام الأساسي توفير البيانات ونقاط التكامل (مثل وضع إشارات على الحسابات إذا كانت تُحتسب ضمن الأصول السائلة أم لا، جداول التدفقات النقدية لـ(ALM)). ستجلب بازل IV (الإصلاحات النهائية) المزيد من التغييرات في حسابات المخاطر وزيادة متطلبات الإفصاح (مثل الحدود الدنيا لرأس المال، النهج المحسنة)[3] – لذا يجب أن يكون نموذج بيانات النظام مرناً ليستوعب هذه التغييرات مع طرحها.

4. إدارة الموجودات والالتزامات (ALM) والخزينة: على عكس (ERP) التقليدي، يحتاج النظام المصرفي إلى إدارة مخاطر أسعار الفائدة ومخاطر السيولة في الميزانية العمومية. تتضمن إدارة (ALM) تحليل الفجوات بين آجال الاستحقاق وإعادة التسعير بين الموجودات (القروض، الأوراق المالية) والخصوم (الودائع، القروض)[5]. يجب أن يدعم النظام إنشاء تقارير تحليل الفجوة (تجميع التدفقات النقدية حسب الفترات)، حساب حساسية صافي الدخل من الفوائد (NII) تحت صدمات أسعار الفائدة، وربما حساب القيمة الاقتصادية للملكية (EVE) للمخاطر طويلة الأمد[5]. لتحقيق ذلك، هناك حاجة لهياكل بيانات جديدة لتخزين جداول التدفقات النقدية للقروض والودائع، سمات أسعار الفائدة (ثابتة، متغيرة، تاريخ إعادة التسعير التالي)، والسيناريوهات لاختبارات الضغط. يجب أن يتتبع نظام الخزينة الاستثمارات والسيولة – مثل محافظ السندات، التوظيفات بين البنوك – بما في ذلك دعم تصنيف الأوراق المالية كمتاحة للبيع أو محتفظ بها حتى الاستحقاق والتعامل مع محاسبتها (القيمة العادلة مقابل الكلفة المطفأة). كما تتطلب (ALM) والخزينة آليات تسعير تحويل الأموال (تخصيص تكاليف الأموال للقروض/الودائع)، والتي قد تكون ميزة للمرحلة 3. في البداية، يجب التركيز على ضمان أن النظام الأساسي يمكنه إخراج البيانات اللازمة إلى نظام (ALM) أو وحدة. التكامل مع بيانات السوق (منحنيات أسعار الفائدة، أسعار الصرف) مطلوب للتقييم وقياس المخاطر. كل ذلك يمثل إضافات فوق وحدة المالية في (ERPNext).

5. معالجة المدفوعات (ISO 20022 و SWIFT): يتعامل (ERPNext) مع إدخالات المدفوعات الأساسية ولكنه لا يغطي معايير الاتصال والرسائل المستخدمة في العمل المصرفي. لكي يصبح منصة مصرفية أساسية، يجب أن يتكامل مع شبكات الدفع. يشمل ذلك إنشاء وتحليل رسائل (ISO 20022 XML) (المعيار الحديث للمدفوعات) لمختلف مسارات العمل: مثل رسائل (PAIN) لبدء مدفوعات العملاء، رسائل (PACS) للتحويلات المالية بين البنوك، ورسائل (CAMT) لكشوفات الحساب. يجب على النظام تخزين ربط المعاملات بالرسائل الصادرة وتتبع حالتها (مرسلة، مؤكدة، مرفوضة). وبالمثل، يجب دعم رسائل SWIFT MT/MX للمدفوعات عبر الحدود حتى يتم استبدال (MT) بالكامل بواسطة (ISO 20022). قد تتضمن المنصة محرك/منسق مدفوعات داخلي لتوجيه المعاملات: على سبيل المثال، تحديد ما إذا كان التحويل محلياً (عبر شبكة ACH المحلية) أو دولياً (عبر SWIFT). يجب أن يكون هذا المحرك قائماً على الأحداث – فعندما يقوم العميل بطلب تحويل، ينشئ النظام تعليمات دفع، يحجز الأموال، يولد الرسالة اللازمة، ويستمع لحدث التأكيد. سيتصل خادم بوابة أو محول تكامل بشبكات الدفع أو واجهات برمجة التطبيقات الخارجية (مثل SWIFT Alliance أو أنظمة RTGS/ACH المحلية). يجب أن يأخذ التصميم في الاعتبار البيانات الغنية التي يحملها (ISO 20022) (مما يعزز الامتثال وقابلية التشغيل البيني)[6] – على سبيل المثال، تحتوي الرسائل على تفاصيل التحويل وبيانات الأطراف، وهي أمور كانت تواجه الأنظمة القديمة صعوبة في التعامل معها[6]. منصتنا ستتعامل بشكل أصيل مع هذه الحقول الغنية وتضمن إجراء فحوصات الامتثال (مثل فحص العقوبات على المستفيدين) قبل إرسال الرسائل.

6. المخاطر والامتثال (KYC/AML/CTF، FATCA/CRS، العقوبات): سيتطلب (ERPNext) تحول إدارة علاقات العملاء إلى نظام فحص عناية للعملاء (CDD) كامل. ستدير وحدة العملاء/KYC الجديدة معلومات هوية العملاء، التحقق من المستندات، وتقييم المخاطر. يجب أن تدعم إجراءات التعرف على العملاء مثل جمع وثائق الهوية، صور شخصية (selfie)، إثبات العنوان، إلخ، والتحقق منها (إما يدوياً أو عبر واجهة برمجة تطبيقات لخدمة تحقق الهوية). يجب أن يفحص النظام العملاء مقابل قوائم العقوبات وقوائم الأشخاص المعرضين سياسياً (PEP) عند الانضمام وبشكل دوري[7]. ويعني ذلك التكامل مع قواعد بيانات أو خدمات خارجية للفحص، أو الحفاظ على قائمة داخلية محدّثة. بالإضافة إلى ذلك، يجب جمع معلومات العملاء المطلوبة لـ(FATCA/CRS) (الإقامة الضريبية، (GIIN) إذا كان كياناً، إلخ) لإعداد التقارير اللازمة لاحقاً.

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

الجوانب الأخرى للامتثال: يتطلب إعداد تقارير FATCA/CRS من النظام تحديد الحسابات التي يمتلكها أجانب أو أفراد ذوو ثروة عالية، تجميع الأرصدة، وإنتاج تقارير (XML) للسلطات الضريبية. يمكن لوحدة الامتثال الاستعلام عن بيانات العملاء بحثاً عن مؤشرات أمريكية (FATCA) أو تعدد الإقامات الضريبية (CRS) والحفاظ على العلامات اللازمة في الحسابات. متطلبات مكافحة تمويل الإرهاب (CTF) تتداخل مع (AML) (المراقبة والعقوبات)، لذا تعالج نفس البنية التحتية ذلك. تتطلب الخصوصية وحماية البيانات (مثل (GDPR)) ميزات مثل القدرة على استرجاع جميع بيانات العميل عند طلبه أو حذف/إخفاء البيانات إذا كان ذلك قانونياً – يجب بناء هذه العمليات ضمن نموذج البيانات (مثل إمكانية إزالة البيانات الشخصية مع الاحتفاظ بسجلات المعاملات عبر التمويه). كما نحتاج إلى سجلات تدقيق لجميع عمليات الوصول والتغييرات على البيانات، لتلبية عمليات تدقيق الامتثال (من شاهد/غيّر ماذا ومتى).

7. ضوابط أمن البيانات والخصوصية: بينما يوفر (ERPNext) أذونات أدوار أساسية، إلا أن السياق المصرفي يتطلب تعزيز الأمان. يتضمن ذلك الامتثال لمعايير مثل ISO 27001 و SOC 2 لحوكمة الأمان، وPCI DSS إذا كان يتعامل مع بيانات بطاقات الدفع. عملياً، يجب تطبيق التشفير أثناء التخزين للبيانات الحساسة (معلومات العملاء، أرقام الحسابات، الهويات الوطنية) – إما على مستوى قاعدة البيانات أو مستوى الحقول. كما أن التشفير أثناء النقل (TLS لجميع الاتصالات) إلزامي. هناك حاجة إلى تحكم دقيق بالوصول: ليس فقط قائم على الأدوار، بل ربما قائم على السمات لبيانات معينة (مثلاً، لا يمكن سوى لموظفي الامتثال رؤية تفاصيل الهوية الكاملة). يجب دعم 2FA/MFA لتسجيل دخول المستخدمين، خاصة للمسؤولين أو الموظفين الذين يقومون بعمليات حساسة. كما يتطلب الأمر تسجيل ومراقبة واسعة لرصد الوصول غير المصرح به أو النشاط الإداري المشبوه. يجب أن يحتفظ النظام بسجلات تدقيق لجميع المعاملات الحيوية وتغييرات البيانات الرئيسية (مع من، متى، القيم الأصلية والجديدة) – قد يغطي الإصدار في (ERPNext) بعض ذلك، لكن في السياق المصرفي نحتاج إلى سجلات غير قابلة للتغيير وتقارير أسهل.

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

8. التوافر العالي والموثوقية: عادة ما تكون الأنظمة المصرفية الأساسية متاحة على مدار الساعة (خاصة مع الخدمات المصرفية عبر الإنترنت)، بخلاف العديد من أنظمة (ERP) التي تتحمل التوقف الليلي. يجب تهيئة (ERPNext) ليعمل مع توقف شبه صفري. وهذا يعني نشره في بيئة عنقودية مع خوادم تطبيق متوازنة التحميل، وإعداد قاعدة بيانات مرنة. يجب تكوين ميزات مثل النسخ الاحتياطي عبر الإنترنت، النسخ المتماثلة للقراءة، أتمتة الفشل. باختصار، يجب أن يضمن الحل التشغيل المستمر والقدرة على الاسترداد الفوري، وهي قدرات لا توفرها تثبيتات (ERPNext) العادية افتراضياً[8]. سنفصل استراتيجية (HA/DR) في قسم لاحق.

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

10. قدرات التكامل: أخيراً، نادراً ما تعمل الأنظمة المصرفية الأساسية بمعزل؛ يجب أن تتكامل مع شبكات (ATM/POS)، قنوات الإنترنت/الموبايل، مكاتب الاستعلام الائتماني، إلخ. سيحتاج (ERPNext) إلى طبقة (API) (REST/GraphQL) تعرض جميع الوظائف الأساسية بشكل آمن، وربما تدفق أحداث (ليتمكن الأنظمة الخارجية من الاشتراك في أحداث الحساب أو المعاملات). رغم أن (ERPNext) يحتوي على واجهات (REST APIs)، إلا أننا قد نحتاج إلى توسيعها أو إضافة طبقة وسيطة للأداء والأمان (بوابة API مع تحديد معدل، مصادقة JWT/OAuth للقنوات الخارجية). يشمل ذلك أيضاً تمكين webhooks أو آلية outbox لضمان تسليم الأحداث بشكل موثوق إلى الخدمات المت downstream.

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

الهيكلية المستهدفة لمنصة النظام المصرفي الأساسي

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

تفصل الهيكلية عالية المستوى لـ (Apache Fineract) الخدمات الأساسية (مثل العميل، القرض، الحساب) خلف واجهات (RESTful APIs) وطبقة تخزين، موضحةً تصميماً معيارياً قائماً على الخدمات[9][9]. نتبع نهجاً مشابهاً مع (ERPNext): وحدات قائمة على المجالات ضمن نظام موحد، مع واجهات (APIs) واضحة وواجهات أحداث لكل وحدة. (المصدر: Apache Fineract)

الوحدات والخدمات الأساسية

في المركز يوجد تطبيق ERPNext المصرفي الأساسي، والذي يمكن اعتباره مونوليث معياري يحتوي على جميع الوحدات المصرفية الأساسية. تتوافق هذه الوحدات مع مجالات الأعمال المميزة ولكنها تعمل ضمن نسخة واحدة من (Frappe/ERPNext) لضمان الاتساق في المعاملات (على الأقل في (MVP)). تشمل الوحدات الأساسية ما يلي:

1. وحدة إدارة العملاء وKYC: تدير سجلات العملاء (الأفراد/الشركات)، بما في ذلك التفاصيل الشخصية/التجارية، مستندات (KYC)، ملفات المخاطر، وسجلات الموافقة. تمدد (Customer doctype) القياسي في (ERPNext) (ويشار إليه هنا بـClient) ببيانات مصرفية إضافية (مثل الرقم الوطني، عناوين متعددة/جهات اتصال، حالة (FATCA)، تصنيف المخاطر). يتم تعريف تدفقات العمل لإدخال العملاء هنا – مثلاً، تسجيل عميل جديد يؤدي إلى مهام رفع مستندات وفحوصات امتثال. موصلات التكامل مع مزودي (KYC) الخارجيين (للتحقق من الهوية، التعرف الضوئي على المستندات OCR، إلخ) جزء من هذه الوحدة. كما تفرض الوحدة قواعد خصوصية البيانات (إخفاء أو إظهار مشروط بناءً على الدور).
2. وحدة إدارة الحسابات: تدير حسابات الإيداع (التوفير، الجارية/الشيكات، الودائع لأجل) والعمليات ذات الصلة. (DocType) جديد باسم Bank Account يربط العميل بمنتج الحساب. يخزن بيانات الحساب: رقم الحساب (IBAN إذا كان متاحاً)، الفرع، العملة، نوع المنتج، سعر الفائدة، الرسوم، إلخ. تنفذ الوحدة دورة حياة الحساب: الفتح (مع سير موافقة إذا لزم)، تغييرات الحالة (نشط، خامل، مغلق)، والإغلاق. كما تدير احتساب الفوائد لحسابات التوفير (إن كانت تحمل فوائد) وفرض الرسوم. يتم تسجيل المعاملات على الحسابات (إيداعات، سحوبات، تحويلات داخلية) في وحدة فرعية دفتر المعاملات (مع قيود تتم مزامنتها أيضاً مع (GL)). تضمن وحدة الحسابات قواعد الامتثال مثل منع الخصم بما يتجاوز الرصيد (أو الحد المسموح به للسحب على المكشوف)، وقد تبدأ تنبيهات على الأنشطة غير المعتادة (بالتنسيق مع وحدة AML). كما توفر واجهات (APIs) لاسترجاع الأرصدة والكشوف للقنوات.
3. وحدة القروض والائتمان: تدير منتجات القروض وحسابات القروض. تشمل (DocTypes) مثل طلب القرض (سير عمل منح القرض)، اتفاقية/حساب القرض، وجدول السداد. يمكن للوحدة دعم أنواع مختلفة من القروض (القروض بالتقسيط، الائتمان الدوار، حسابات البطاقات الائتمانية) مع شروط قابلة للتهيئة (سعر الفائدة، نوع الجدول، الضمانات، إلخ). تقوم بأتمتة احتساب الفوائد وجداول الاستهلاك – توليد جداول السداد عند صرف القرض ونشر الاستحقاقات الدورية. تتكامل مع دفتر الأستاذ المحاسبي لنشر إيرادات الفوائد والذمم المستحقة. من أجل (IFRS 9)، تُضاف حقول مثل مرحلة القرض (1/2/3)، (PD)، (LGD)، ومبلغ (ECL) كسجل في القرض. يمكن حسابها داخل الوحدة (إذا استخدم نهج مبسط) أو استيرادها من نموذج مخاطر. كما يجب أن تعالج الوحدة حالات التعثر: تعليم الدفعات المتأخرة، حساب أيام التأخير، وتحفيز تكوين المخصصات أو تغييرات التصنيف (مثل نقل القرض إلى حالة غير منتج). يمكن تضمين التكامل مع خدمات التقييم الائتماني أو مكاتب الائتمان لعمليات المنح.
4. وحدة المدفوعات والتحويلات: تعتبر هذه الوحدة محرك المدفوعات. تدير كل حركة أموال بين الحسابات أو خارج البنك. داخلياً، يؤدي تحويل الأموال بين حسابات عملاء داخل البنك إلى تحديث الأرصدة في وحدة الحساب وإنشاء سجل معاملة (يتدفق إلى (GL)). للتحويلات الخارجية، تتكامل هذه الوحدة مع شبكات الدفع. تحول الطلبات الداخلية إلى تعليمات دفع خارجية (مثل تحويل ائتماني (SEPA) صادر أو رسالة (SWIFT)). تدير حالات المدفوعات والتأكيدات – مثلاً، عند وصول دفعة واردة (رسالة (ISO 20022 PACS))، تقيد الوحدة الحساب المناسب وتحدث المعاملة كمسواة. من المحتمل أن تتضمن مكونات فرعية أو خدمات لمسارات دفع مختلفة (ACH، SWIFT، شبكات البطاقات). تشمل الوحدة آلية جدولة للأوامر الدائمة (التحويلات المتكررة) ومنطق مواعيد القطع للمعالجة اليومية. نظراً لتعقيد الرسائل، قد يتم تصميم هذه الوحدة كغلاف خدمة حول مركز مدفوعات أو مكتبة موجودة، ولكن من منظور (ERPNext) ستوفر (DocTypes) مثل تعليمات الدفع، معاملة المقاصة، إلخ، مع تدفقات عمل مقابلة.
5. وحدة دفتر الأستاذ العام والمحاسبة: يحتوي (ERPNext) بالفعل على وحدة محاسبة مع مخطط حسابات وقواعد ترحيل. سنقوم بمواءمة المعاملات المصرفية مع القيود المحاسبية المناسبة. كل معاملة للعميل (إيداع، سحب، صرف قرض، استحقاق فائدة، رسوم، إلخ) تولد قيوداً في (GL) وفقاً للقواعد المحاسبية المعدة. قد نقدم مفهوم دفتر الأستاذ المصرفي الأساسي (دفتر فرعي لحسابات العملاء) يبقى دائماً متزامناً مع (GL). على سبيل المثال، يزيد الإيداع رصيد حساب العميل (دفتر أساسي) ويؤثر أيضاً على (GL) (مدين نقدية، دائن التزامات ودائع العملاء). تضمن هذه الوحدة سلامة القيد المزدوج وتدعم عمليات الإغلاق المالي. كما تنتج القوائم المالية القياسية للبنك (الميزانية العمومية، قائمة الدخل) بالإضافة إلى تقارير مالية تنظيمية. تشمل التحسينات على محاسبة (ERPNext) في القطاع المصرفي دعم المحاسبة متعددة العملات (إعادة تقييم المراكز بالعملات الأجنبية)، قيود استحقاق الفوائد، محاسبة القروض المتعثرة (نقل الفوائد إلى التعليق، إلخ)، وقيود المحاسبة عن التحوط إذا لزم الأمر. كما يجب أن تكون الوحدة قادرة على توحيد الحسابات إذا كان البنك جزءاً من مجموعة (مع أنه قد لا يكون ضرورياً للبنوك ذات الكيان الواحد في (MVP)).
6. وحدة المخاطر والامتثال: تشمل وظائف مراقبة (AML/CTF) وإعداد تقارير الامتثال. تحتوي على محرك قواعد لمكافحة غسل الأموال: ربما جدول قواعد قابل للتهيئة أو نص يُنفذ على كل معاملة (أو بشكل دوري على أرصدة الحسابات) وينتج تنبيهات. كما تشمل وظيفة الفحص (DocType لنتائج فحص العقوبات/PEP لكل عميل أو مستفيد). تدير الوحدة حالات الامتثال – مثلاً، يتم تسجيل معاملة مشبوهة كحالة، مع سير عمل لموظف الامتثال للتحقيق، إضافة الملاحظات، ووضع علامة كمبلّغ عنها أو مرفوضة. بالنسبة لـ(KYC)، تضمن الوحدة المراجعات الدورية (تجديد KYC كل X سنوات) عبر إنشاء مهام عند الاستحقاق. كما تخزن تقارير تنظيمية مثل: تقارير المعاملات النقدية (CTR) للعمليات النقدية التي تتجاوز الحد، تقارير FATCA، إلخ. يمكنها توليد البيانات لهذه التقارير بالتنسيقات المطلوبة. جانب آخر هو مراقبة نشاط المستخدم لمكافحة الاحتيال – لضمان رصد أي إجراءات غير معتادة من الموظفين (قد تكون وظيفة أمن معلومات أكثر، لكنها تُعرض هنا). باختصار، تصل هذه الوحدة بين البيانات التشغيلية ومخرجات الامتثال، مطبقةً السياسات التي يلتزم بها البنك.
7. وحدة الخزينة وإدارة الموجودات والالتزامات (ALM): في المراحل الأولية، قد تقتصر على أداة إدارة السيولة – تتبع مراكز النقد الخاصة بالبنك عبر الحسابات (حساب البنك المركزي، حسابات (nostro/vostro) للعملات الأجنبية، النقد في الخزينة) وربما إدارة محفظة الاستثمارات. يمكن أن تتضمن (DocType) للأوراق المالية الاستثمارية التي يحتفظ بها البنك مع قيمها السوقية. تكون الوحدة مسؤولة عن توقعات السيولة قصيرة الأجل (باستخدام بيانات من وحدتي الحسابات والقروض حول التدفقات الداخلة/الخارجة المتوقعة) ويمكن أن تنتج حساب (LCR/NSFR) من تلك البيانات[3]. بالنسبة لمخاطر أسعار الفائدة، ستسحب الوحدة الجداول من القروض وودائع الأجل لحساب تحليل الفجوة. في (MVP) قد لا تكون هذه العمليات مؤتمتة بالكامل؛ ربما توفر الوحدة تصدير البيانات إلى نظام (ALM) خارجي. في النهاية، نتخيل إضافة قدرات إدارة التمويل (مثل تتبع الاقتراض من البنوك الأخرى أو إصدار شهادات الإيداع/السندات من قبل البنك) ونمذجة مخاطر أسعار الفائدة (سيناريوهات الصدمات). من المحتمل أن تتطلب هذه الوحدة التكامل مع بيانات السوق (لأسعار الفائدة وأسعار السندات) في حال تطبيق التقييم بالقيمة السوقية أو تحليل السيناريو. بحلول المرحلة 3، ستساعد وحدة (ALM) لجنة الموجودات والالتزامات (ALCO) في اتخاذ القرار من خلال تقديم تقارير شاملة عن السيولة وهامش الفائدة تحت ظروف مختلفة.
8. وحدة التقارير والتحليلات: تحتاج البنوك إلى مجموعة واسعة من التقارير – تشغيلية، مالية، تنظيمية، وتقارير الإدارة. بينما قد توفر كل وحدة بعض التقارير، يمكن لوحدة تقارير مخصصة أن توحد البيانات وتنتج مخرجات للجهات التنظيمية والإدارة. يشمل ذلك الإقرارات التنظيمية (غالباً بصيغة Excel أو XML للبنوك المركزية)، تقارير (MIS) داخلية (نمو المحافظ، تقسيم العملاء، أداء الفروع)، ولوحات متابعة لمؤشرات الأداء الرئيسية (مثل كفاية رأس المال، نسبة القروض المتعثرة NPL، كلفة الأموال، العائد على الأصول). قد نستفيد من محرك التقارير في (ERPNext) لبعضها، ولكن للتقارير المعقدة قد نبني استعلامات SQL مخصصة أو نستخدم تكامل مع أداة ذكاء أعمال. مكون فرعي هنا هو مستودع بيانات أو Data Mart: إذا تم استخدام (CQRS)، يمكن لقاعدة بيانات محسنة للقراءة أن تخدم التقارير الثقيلة دون التأثير على قاعدة البيانات التشغيلية. يجب أن ندرج على الأقل Data Mart أساسي لتحليل البيانات التاريخية (خصوصاً إذا تم استخدام (event sourcing)، يمكننا إعادة إنشاء الحالات لأي تاريخ).

بالإضافة إلى هذه الوحدات الأساسية، يتم دمج خدمات تقنية شاملة ضمن الهيكلية:

1. حافلة الأحداث/نظام الرسائل: نتبنى نهجاً قائماً على الأحداث لفصل الوحدات وتكامل الأنظمة الخارجية. على سبيل المثال، عند تسجيل معاملة في وحدة الحساب، يتم نشر حدث "TransactionPosted". تشترك وحدة AML في هذا الحدث لتشغيل قواعد الفحص، ويشترك روبوت المحادثة لإشعار العميل، إلخ. يمكن تنفيذ ذلك عبر طابور رسائل داخلي (مثل Redis أو RabbitMQ أو Kafka). حتى في النشر الأحادي (Monolith)، تساعد حافلة الأحداث على تحقيق المعالجة غير المتزامنة والمرونة (إذا فشل مشترك، يمكنه اللحاق لاحقاً). سنطبق نمط (Transactional Outbox) لضمان نشر الأحداث بشكل موثوق – أي يتم تخزين بيانات المعاملة والحدث معاً ثم يُرسل الحدث لاحقاً، بحيث لا يُفقد أي حدث إذا تعطل النظام أثناء العملية[10]. يكتب هذا النمط الأحداث (مثل "تم إرسال الدفع") إلى جدول Outbox في نفس معاملة قاعدة البيانات، ثم يقوم عمل في الخلفية بإرسالها إلى الحافلة، مما يضمن الاتساق.
2. طبقة API/بوابة التكامل: يتم كشف جميع الوظائف الأساسية عبر طبقة (API) آمنة، ربما باستخدام (REST API) في (Frappe) ولكن مع تحسينها للاحتياجات المصرفية. قد ننفذ بوابة API تجمع نقاط نهاية (ERPNext) في واجهات موجهة للأعمال (على سبيل المثال، نقطة نهاية "تحويل أموال" والتي تقوم داخلياً بإنشاء سجل دفع وترحيل القيود). ستتعامل هذه الطبقة مع المصادقة (على الأرجح OAuth2 أو JWT للأطراف الثالثة) والتحكم في المعدل. كما تسمح بدمج القنوات الخارجية: تطبيقات الموبايل، أجهزة الصراف (ATM)، أنظمة الصرافين في الفروع، إلخ. جميعها تتصل عبر هذه (APIs). يمكن للبوابة أيضاً دمج إدارة الجلسات متعددة القنوات – مثل ضمان عرض موحد للعميل عبر الموبايل والويب.
3. خدمة المصادقة والهوية: بينما يحتوي (ERPNext) على إدارة المستخدمين، إلا أنه في السياق المصرفي قد نفصل بين مصادقة العملاء (لمستخدمي الخدمات المصرفية عبر الإنترنت) ومصادقة المستخدمين الداخليين. يمكن التكامل مع (SSO) أو التحقق من الهوية (مثل إرسال OTP عبر SMS/البريد الإلكتروني لبعض العمليات). نضمن الامتثال لمتطلبات (PSD2) للمصادقة القوية للعملاء إذا كانت مطبقة (توثيق ثنائي للمعاملات).
4. المجدول/معالج الدُفعات: بعض العمليات المصرفية تعتمد على الدُفعات (وظائف نهاية اليوم: حساب الفوائد، فرض الرسوم، قيود إغلاق (GL)، إعداد التقارير). سنستخدم وظائف الخلفية في (ERPNext) أو خدمة جدولة خارجية لتشغيل هذه المهام بشكل موثوق. على سبيل المثال، كل ليلة عند منتصف الليل، يتم حساب الفائدة على حسابات التوفير لليوم وترحيلها لكل حساب؛ أو شهرياً، تشغيل نموذج (ECL) لتحديث المخصصات.
5. تشفير البيانات وإدارة المفاتيح: ستكون خدمة أو مكتبة للتشفير جزءاً من البنية. يتم تشفير الحقول الحساسة (مثل رقم التعريف الضريبي للعميل، أرقام البطاقات إن وجدت) على مستوى التطبيق. يمكن التكامل مع (HSM) أو خدمة إدارة مفاتيح سحابية (AWS KMS) لإدارة مفاتيح التشفير، وضمان الامتثال لمعيار (PCI DSS) لأي بيانات بطاقات ولحماية البيانات بشكل عام.
6. أدوات المراقبة والتدقيق: تتضمن البنية مكونات للمراقبة (مثل عارض سجلات التدقيق، المراقبة اللحظية للمعاملات). يمكن التكامل مع أنظمة (SIEM) (إدارة معلومات وأحداث الأمان) لسجلات الأمان. من أجل التدقيق، يتم توفير استرجاع سهل لجميع الإجراءات التي قام بها مستخدم أو جميع التغييرات على سجل (باستخدام سجلات الأحداث أو تاريخ الإصدارات).

تدفق البيانات والحدود

تدفق البيانات: عند قيام عميل ببدء معاملة (من أي قناة)، تصل الطلبات إلى طبقة (API) وتُوجَّه إلى الوحدة المعنية. على سبيل المثال، تحويل الأموال من منظور العميل يمر بالخطوات التالية: (1) تستقبل (API) الطلب وتوثق العميل، (2) تتحقق وحدة الحساب من كفاية الرصيد وتنشئ قيد خصم على الحساب المصدر وقيد دائن على الحساب الوجهة (إذا كان داخلياً) أو تولد تعليمات دفع خارجية (إذا كان خارجياً)، (3) يتم إنشاء قيود (GL) للخصم والدائن (عبر المنطق المحاسبي المتكامل)، (4) يُنشر حدث “PaymentInitiated”، (5) تلتقط وحدة المدفوعات هذا الحدث (إذا كان التحويل خارجياً) وتنسق رسالة (ISO 20022) لإرسالها إلى الشبكة الخارجية. ثم تحدث حالة تعليمات الدفع (مثل "تم الإرسال"). (6) في الوقت نفسه، تشترك وحدة AML في الحدث – تفحص التفاصيل (الأطراف، المبلغ) مقابل القواعد وإذا وُجد خلل (مثلاً المبلغ > الحد والعميل عالي المخاطر)، تولد تنبيه AML. (7) إذا عاد الدفع برفض أو تأكيد (رسالة واردة)، تقوم وحدة المدفوعات بتحديث أرصدة الحسابات أو عكسها عند الحاجة وتنشر حدث "PaymentSettled" أو "PaymentFailed". (8) خدمة روبوت المحادثة، المشترك في الأحداث أو عبر استعلام (API)، تخطر العميل عبر تطبيق المحادثة/الموبايل بحالة العملية. يوضح هذا التدفق كيف يسمح الفصل عبر الأحداث لكل جزء (الحسابات، (GL)، AML، الإشعارات) بالتعامل مع مهامه دون وجود معاملة ضخمة واحدة تعيق كل المنطق.

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

البنية مقسمة إلى طبقات مع العرض (القنوات)، التطبيق (وحدات (ERPNext))، والبيانات (قاعدة البيانات إضافة إلى مخازن بيانات خارجية). وباتباع مبادئ مشابهة لـ(Fineract)، نضمن أن كل طبقة يمكن أن تتوسع أفقياً[2]. إن الطبيعة عديمة الحالة لطبقة (API) وخوادم التطبيقات تسمح بإضافة المزيد من النسخ للتعامل مع الحمل، حيث يتم تخزين جميع تغييرات الحالة في قاعدة البيانات أو الذاكرة المؤقتة.

الأنماط المعمارية وتطبيقها

يعتمد تصميمنا على عدة أنماط معمارية رئيسية لتلبية المتطلبات:

1. المونوث (Modular Monolith) كأساس: في البداية، نحافظ على قاعدة كود واحدة وقاعدة بيانات واحدة لجميع الوحدات المصرفية الأساسية، بالاستفادة من قابلية (ERPNext) للتجزئة (كل مجال كوحدة/تطبيق). هذا يضمن اتساقًا قويًا (مهم للمعاملات المالية) وتطويرًا أسرع (دون الحاجة إلى إعداد اتصال بين الخدمات لكل شيء). داخل المونوث، نفرض حدودًا للوحدات لتجنب الترابط الوثيق. ومع زيادة الاستخدام، يمكن فصل وحدات معينة وتحويلها إلى خدمات صغيرة (Microservices) إذا لزم الأمر (على سبيل المثال، محرك المدفوعات قد يكون مرشحًا جيدًا للفصل والتوسع بشكل مستقل نظرًا لاحتمالية ارتفاع معدل العمليات واحتياجات تقنية مميزة). هذا النهج التطوري يتبع المقولة: "ابنِ مونوثًا معياريًا، ثم قسّمه إلى خدمات صغيرة عندما يكون مبررًا". ومن الجدير بالذكر أن تجربة (Apache Fineract) تُظهر أن المونوث يمكن أن يكون فعالًا للبنوك الأساسية؛ حيث بدأ (Fineract) كمونوث بتصميم معياري ولمحاولة لاحقة كنسخة خدمات صغيرة[1] (والتي تم الاستغناء عنها لاحقًا لصالح البنية الأبسط). لذلك سنعطي الأولوية لـالبساطة والاتساق في المرحلة الأولى، لكن نصمم بواجهات جاهزة للخدمات الصغيرة (APIs, events) بحيث يمكننا في المرحلة الثالثة نشر مكونات معينة بشكل منفصل دون إعادة هيكلة كبيرة.
2. التصميم الموجه بالمجال (Domain-Driven Design) & السياقات المقيدة (Bounded Contexts): كل وحدة أساسية تعادل سياقًا مقيدًا بمفهوم DDD. على سبيل المثال، معنى "الحساب" في سياق الودائع يختلف عن "الحساب العام GL" في المحاسبة؛ ومن خلال فصل الوحدات نتجنب الغموض. البيانات الخاصة بكل مجال مملوكة لنماذج ذلك المجال، والوحدات الأخرى تُشير إليها فقط عبر معرفات أو واجهات APIs. هذا يقلل من خطر منطق الأعمال غير المتسق. نقرر نقاط التكامل بوعي – على سبيل المثال، وحدة القروض تستدعي واجهة محاسبية لنشر الاستحقاقات، بدلاً من التلاعب المباشر بالقيود المحاسبية نفسها، مما يحافظ على القواعد المحاسبية مركزية. هذا يتماشى مع التفكير الموجه نحو الخدمات، حتى داخل قاعدة كود واحدة.
3. (CQRS – Command Query Responsibility Segregation): نقوم بتنفيذ (CQRS) في المجالات التي يكون فيها حمل القراءة والكتابة مختلفًا في المتطلبات. جانب الكتابة (الأوامر) للنظام هو قاعدة بيانات المعاملات في (ERPNext) التي تتعامل مع تحديثات العملاء والمعاملات وما إلى ذلك. جانب الاستعلام يمكن أن يكون قاعدة بيانات واحدة أو أكثر مُحسّنة للقراءة أو وجهات نظر مادية. على سبيل المثال، إنشاء تقرير تنظيمي أو لوحة معلومات تحليلية قد يتطلب عمليات ربط معقدة أو بيانات تاريخية قد تُبطئ قاعدة البيانات التشغيلية. يمكننا الحفاظ على قاعدة بيانات للتقارير يتم تغذيتها عبر الأحداث: في كل مرة يتغير فيها معاملة أو بيانات ذات صلة، يقوم حدث بتحديث جدول تقارير غير مُطبع (أو نستخدم نسخ قاعدة البيانات لعمل نسخة قراءة). استخدام (CQRS) يعني أننا نقبل الاتساق النهائي لجانب القراءة، وهو مقبول للتحليلات (على سبيل المثال، قد يتأخر التقرير بضع ثوانٍ عن الوقت الفعلي). في الوقت نفسه، يظل الاتساق القوي محفوظًا في جانب الكتابة. عمليًا، يمكننا استخدام نسخ (MariaDB) لإنشاء نسخ قراءة للاستعلامات الثقيلة، و/أو استخدام التخزين المؤقت المدمج في (Frappe). إذا لزم الأمر، يمكننا اعتماد نهج event-store plus projector: تخزين الأحداث لكل معاملة (مثل سجل تدقيق للتغييرات)، ثم عرضها في نماذج قراءة (مثل أرصدة الحسابات حسب المنطقة، وما إلى ذلك)[10]. يمكن توسيع (ERPNext ORM) أو تجاوزه لمثل هذه النماذج إذا لزم الأمر (باستخدام SQL خام للأداء). (CQRS) يسهل أيضًا الفصل المستقبلي للخدمات: إذا أصبحت وحدة ما مثقلة بالقراءة، يمكنها امتلاك قاعدة بيانات خاصة تُنشأ من الأحداث، دون التأثير على القاعدة الأساسية.
4. تتبع الأحداث (Event Sourcing – Audit Trail Pattern): نعتمد بشكل جزئي على تتبع الأحداث عبر تخزين جميع الأحداث الحرجة (المعاملات الحسابية، تغييرات الحالة) كسجلات غير قابلة للتغيير. على سبيل المثال، بدلاً من تحديث رصيد الحساب فقط، نقوم دائمًا بإنشاء سجل معاملة لكل دائن/مدين ونستخلص الرصيد كمجموع للمعاملات. هذا لا يوفر فقط سجل تدقيق مدمج (يمكننا إعادة إنشاء دفتر الحسابات من الأحداث) بل يتماشى أيضًا مع المبادئ المحاسبية. التتبع الكامل للأحداث (تخزين كل التغييرات كأحداث واستخلاص الحالة منها) قد يكون قفزة كبيرة لنظام مبني على (ERPNext)، لكن المجالات الأساسية ستستخدم النمط. دفتر الأستاذ العام (GL) بطبيعته قائم على الأحداث (قيود اليومية). بالنسبة للقروض، قد نخزن أحداثًا لتغييرات الحالة (مثل القرض تمت الموافقة عليه، القرض تم صرفه، دفعة فائتة) بحيث يكون لدينا خط زمني لما حدث. هذه الأحداث تغذي عمليات أخرى – على سبيل المثال، حدث "حالة القرض = متعثر" يُطلق تحديثًا في المخصصات. الفائدة هي وجود سجل لا جدال فيه لأغراض الامتثال وأسهل لتصحيح الأخطاء (يمكننا معرفة "من فعل ماذا ومتى" من خلال سجلات الأحداث). إذا اخترنا، يمكننا استخدام مخزن أحداث (مثل جدول سجل مضاف فقط أو موضوع (Kafka)) بالإضافة إلى الجداول القياسية؛ ومع ذلك، نظرًا لأن قاعدة بيانات علائقية قوية تدعم (ERPNext)، فقد نكتفي بجداول تدقيق وتصدير ليلي للأحداث للنسخ الاحتياطي. ينسجم نهج تتبع الأحداث مع (CQRS): الأحداث تُحدث نماذج القراءة بشكل غير متزامن، وتوفر البيانات لإعادة بناء الحالة إذا لزم الأمر[10].
5. نمط (Saga) للمعاملات الموزعة: في العمليات التي تتضمن خطوات أو وحدات متعددة (خاصة إذا تم تقسيمها لاحقًا إلى خدمات صغيرة)، نستخدم نمط (Saga) (آلية choreography أو orchestration لمعاملات محلية متعددة)[10]. على سبيل المثال، فكر في عملية صرف القرض: قد تتضمن إنشاء حساب قرض، تحويل الأموال إلى حساب الودائع الخاص بالعميل، وإرسال إشعار. هذه قد تكون ثلاث معاملات منفصلة. يضمن (Saga) إما إتمام جميع الخطوات أو تنفيذ إجراءات تعويضية للتراجع. في (choreographed saga)، يمكن لحدث وحدة القروض "LoanApproved" أن يطلق وحدة الحسابات لزيادة مبلغ الصرف؛ إذا فشل ذلك (مثلًا لعدم كفاية السيولة)، يُرسل حدث تعويضي لوحدة القروض لوضع علامة أن القرض لم يُصرف. بديلًا عن ذلك، يمكن أن يكون لدينا منسق (process manager) يدير العملية، لكن (choreography) عبر الأحداث يبقي الوحدات غير مترابطة بشكل وثيق. مثال آخر هو الدفع الدولي: خصم الحساب ثم الإرسال عبر (SWIFT). إذا كانت شبكة (SWIFT) معطلة ولم يتمكن الدفع من التنفيذ، يجب أن يتراجع (saga) عبر إعادة رصيد الحساب للعميل. نظرًا لتورط نظامين مختلفين (النظام المصرفي الأساسي والشبكة الخارجية)، فإن (saga) مع معاملة تعويضية يكون مناسبًا[10]. سننفذ منطق التعويض لكل خطوة قابلة للعكس (على سبيل المثال، لعملية الخصم من الحساب سيكون لدينا عملية عكسية للإيداع عند الحاجة). هذا يضمن الاتساق النهائي بين الوحدات دون الحاجة إلى قفل معاملة موزعة واحدة. يمكن أن يكون تنسيق (Saga) مبدئيًا ضمنيًا عبر الأحداث (وجود أو غياب أحداث متابعة معينة يمكن أن يشير إلى النجاح/الفشل)، لكن من أجل الوضوح قد ننفذ سجل (Saga) لتتبع تقدم العمليات متعددة الخطوات.
6. نمط (Transactional Outbox): كما ذكرنا، كلما احتجنا إلى إصدار أحداث بناءً على تحديث قاعدة بيانات (وهو أمر متكرر في التصميم القائم على الأحداث)، نستخدم نمط outbox لضمان الموثوقية[10]. بشكل ملموس، عند حفظ معاملة في قاعدة البيانات، نقوم أيضًا بإدراج سجل حدث في جدول "Outbox" داخل نفس معاملة (SQL). يقوم عامل في الخلفية بقراءة الإدخالات الجديدة في (Outbox) ونشرها إلى وسيط الرسائل (Kafka/RabbitMQ). بعد النشر الناجح فقط يتم وضع علامة عليها كمُرسلة. إذا تعطل النظام بعد تنفيذ عملية قاعدة البيانات ولكن قبل إرسال الحدث، يظل (Outbox) يحتوي عليها وسيقوم العامل بإرسالها عند إعادة التشغيل – وبالتالي لا تُفقد الأحداث، ولا يتم إرسال أحداث وهمية لمعاملات تم التراجع عنها. هذا النمط ضروري إذا/عندما تعمل أجزاء من النظام في عمليات أو خدمات مختلفة. حتى داخل المونوث، فإنه يضيف مرونة لضمان عدم فقدان المهام الداخلية غير المتزامنة (مثل إرسال بريد إشعار بعد معاملة). سننفذ ذلك إما عبر خطاف (ERPNext) عند نجاح تنفيذ المعاملة أو باستخدام نظام الطوابير المرتبط بتنفيذ قاعدة البيانات.
7. Idempotency و Exactly-Once Processing: في نظام مالي قائم على الأحداث، يجب علينا التعامل مع التكرارات أو محاولات الإعادة بعناية لتجنب الترحيل المزدوج. سيتم اتباع أنماط مثل المعرفات الفريدة للمعاملات والمستقبلات (idempotent). على سبيل المثال، سيكون لكل دفعة معرف فريد، وإذا تم استلام نفس الحدث مرتين، ستتعرف وحدة المدفوعات على أنه تمت معالجته بالفعل وتتجاهل التكرار. هذا يُعتبر مبدأ تصميم أكثر من كونه نمطًا، لكنه يستحق الذكر كجزء من أفضل الممارسات في هندسة الأنظمة القائمة على الأحداث.
8. أنماط التوافر العالي (High Availability Patterns): نقوم بنشر عدة نسخ من خوادم التطبيق (عديمة الحالة) خلف موزع تحميل (load balancer) (إذا كان على AWS، مثلاً باستخدام ELB). بالنسبة لقاعدة البيانات، نستخدم النسخ الأساسية-التابعة (primary-replica replication). يمكن أن يكون التحويل عند الفشل يدويًا في (MVP) (مع فترة توقف لبضع دقائق) أو آليًا عبر أدوات مثل (etcd) أو أدوات خاصة بقاعدة البيانات (مثل MariaDB Master-Slave مع التحويل التلقائي، أو Galera cluster للتعدد النشط). عند استخدام (Galera) للتجميع النشط-النشط لقواعد البيانات، نحصل على نسخ متزامنة بين العقد، مما يوفر عدم فقدان للبيانات عند فشل عقدة، وذلك على حساب بعض التأخير في الكتابة[11]. بدلاً من ذلك، الإعداد الأبسط primary-secondary مع نسخ غير متزامن أسهل، لكنه قد يفقد آخر المعاملات إذا تعطل الأساسي (نخفف ذلك عبر تحديث سجلات binlog بشكل متكرر أو استخدام النسخ شبه المتزامن semi-sync). سننظر في الموازنة بين الخيارات: (Galera/Percona XtraDB Cluster) يمكن أن يوفر لنا توافر عالي مع تحويل تلقائي عند الفشل وتوزيع متساوٍ للقراءة. في كلتا الحالتين، نخطط لـصيانة بدون توقف عبر استخدام النسخ: ترقية عقدة واحدة بينما تخدم الأخرى العملاء، ثم التحويل، وهكذا. بالنسبة لحافلة الأحداث، إذا استخدمنا (Kafka)، فإن مجموعة متعددة الوسطاء مع عامل نسخ >1 تضمن أن فشل وسيط واحد لا يسبب انقطاعًا. خدمات أخرى (مثل Redis cache، أو أي خدمة صغيرة) ستكون أيضًا موزعة أو احتياطية. ستُستخدم أنماط مثل قواطع الدائرة (circuit breakers) للتكاملات الخارجية – إذا كانت خدمة خارجية (مثل KYC API) معطلة، لن يتوقف النظام إلى أجل غير مسمى؛ بل سيُعطل هذا التكامل مؤقتًا ويرسل تنبيهًا، بحيث تستمر العمليات الأساسية (مع بعض الوظائف المحدودة).

الجمع بين هذه الأنماط ينتج نظامًا قويًا، قابلاً للتدقيق، وقابلاً للتوسع. من خلال استخدام أنماط مثبتة مثل (Saga) و(Outbox) لتحقيق الاتساق الموزع، و(CQRS) للتوسع، نضمن أن (ERPNext) الموسع لدينا يمكنه التعامل مع تعقيد الأنظمة المصرفية. والأهم أننا نختار الأنماط بحكمة: فالتتبع الكامل للأحداث والخدمات الصغيرة قويان لكنهما يزيدان التعقيد – لذلك ننفذهما بطريقة مدروسة (ربما فقط لوحدات معينة أو كخيارات لاحقة في مراحل لاحقة) لجعل المرحلة الأولى قابلة للتحقيق.

التوافر العالي والتعافي من الكوارث (HA/DR)

تتطلب منصات البنوك زمن تشغيل مرتفع للغاية وقدرة قوية على التعافي من الكوارث. نعرض هنا استراتيجية (HA/DR) تحقق المرونة على مستوى مركز البيانات المحلي وعبر المناطق الجغرافية.

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

بالنسبة لـقاعدة البيانات، كما أُشير سابقًا، نستخدم النسخ/التجميع. الإعداد النموذجي هو قاعدة بيانات أساسية (للكتابة) وواحدة أو أكثر من النسخ المخصصة للقراءة (للاستعلامات، التقارير، والجاهزية للتحويل عند الفشل). العديد من البنوك ستختار نسخًا متزامنًا أو حل تجميع لتفادي فقد البيانات عند الفشل. على سبيل المثال، نشر MariaDB باستخدام Galera cluster يسمح بإعداد أساسي-أساسي حيث يمكن لأي عقدة قبول الكتابة، ويضمن العنقود الاتساق (وهذا يتطلب ضبطًا دقيقًا بعدد عقد فردي لتحقيق النصاب). نهج آخر هو أساسي-ثانوي مع نسخ شبه متزامن semi-synchronous (ينتظر الأساسي حتى يؤكد تابع واحد على الأقل عملية الكتابة). هدفنا في التصميم هو RPO = 0 (لا فقدان للبيانات) أو في أسوأ الحالات بضع ثوانٍ (إذا أثّر النسخ المتزامن الكامل كثيرًا على الأداء). هذا قابل للتحقيق باستخدام (Galera) أو تقنيات مشابهة[11].

عادةً ما تكون التطبيقات وقواعد البيانات في نفس الشبكة المحلية أو منطقة السحابة لتقليل الكمون. سنوزع العقد عبر ما لا يقل عن منطقتين للتوافر (availability zones) بحيث لا يؤدي انقطاع إحدى المناطق إلى توقف النظام بأكمله. على سبيل المثال، في AWS، يمكننا وضع عقدة قاعدة بيانات وخادم تطبيق في AZ1، وعقدة قاعدة بيانات وخادم تطبيق آخر في AZ2، وربما عقدة قاعدة بيانات ثالثة في AZ3 (عنقود Galera من 3 عقد لتحقيق النصاب). يوجّه موزع التحميل الحركة إلى مثيلات التطبيق السليمة. إذا فشل مثيل التطبيق في اختبارات الصحة، يتوقف موزع التحميل عن إرسال الحركة إليه. إذا فشلت قاعدة البيانات الأساسية، يرقّي العنقود تلقائيًا نسخة احتياطية (أو في Galera تبقى جميع العقد متزامنة، لذلك يستمر عقدة أخرى دون حاجة للترقية)، ويعيد التطبيق الاتصال تلقائيًا أو نقوم بسرعة بتحديث DNS/سلسلة الاتصال.

التعافي من الكوارث (متعدد المناطق): بالنسبة لـ (DR) (على سبيل المثال: انقطاع على مستوى المنطقة أو سيناريو كارثي)، سنحافظ على نشر ثانوي في منطقة أخرى (أو موقع DR داخلي). هناك استراتيجيتان: DR نشط-سلبي (active-passive) أو متعدد المناطق نشط-نشط (active-active). النشط-السلبي أبسط: المنطقة الثانوية تحتوي على قاعدة بيانات احتياطية دافئة (تنسخ من الأساسي بشكل غير متزامن) وخوادم تطبيق احتياطية (لا تخدم الحركة). إذا تعطلت المنطقة الأساسية، نفشل إلى الثانوية: نُرقي قاعدة بياناتها إلى أساسية، نُعيد توجيه العملاء (تبديل DNS أو باستخدام موزع تحميل عالمي)، ونوسع خوادم التطبيقات هناك. قد يتسبب هذا في بضع دقائق من التوقف عند التحويل واحتمالية فقد بيانات صغيرة (حيث قد لا تكون آخر المعاملات قد نُقلت إذا تعطل الأساسي – نخفف ذلك عبر النسخ المتكرر أو نقاط التزام متزامنة).

النشط-النشط متعدد المناطق أكثر تعقيدًا لأنه يتطلب إما تقسيم الحركة (على سبيل المثال، المنطقة A تخدم بعض العملاء، والمنطقة B تخدم آخرين) أو استخدام قاعدة بيانات موزعة يمكنها التعامل مع الكتابة متعددة المناطق (وهو أمر صعب مع الحفاظ على اتساق ACID؛ وغالبًا لا يُستخدم في البنوك الأساسية بسبب احتياجات الاتساق). يمكننا التفكير في نشط-نشط للقراءة: أي أن كلا المنطقتين تخدمان حركة القراءة، لكن واحدة أساسية للكتابة. أو استخدام قاعدة بيانات SQL موزعة متقدمة مستقبلًا (مثل CockroachDB أو Yugabyte) لامتلاك كتابات متعددة المناطق بشفافية، لكن ذلك جهد كبير وغير نموذجي حاليًا في البنوك الأساسية بسبب مشاكل الكمون.

مع التكنولوجيا الحالية، من المرجح أن نختار النشط-السلبي مع تحويل سريع كنهج DR في المرحلة الأولى. هدف (RTO – Recovery Time Objective) قد يكون في حدود < 1 ساعة للتحويل الكامل على مستوى المنطقة في (MVP)، مع تحسينه إلى بضع دقائق عبر الأتمتة. هدف (RPO – Recovery Point Objective) قريب من الصفر؛ قد نقبل بضع ثوانٍ من فقد البيانات في أسوأ الحالات، لكن المثالي هو الصفر من خلال النسخ شبه المتزامن.

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

اختبار التحويل عند الفشل: الخطة لا قيمة لها دون اختبارها. سنقوم بشكل روتيني بعمل تدريبات DR: محاكاة فشل قاعدة البيانات الأساسية لمعرفة إذا كان التحويل يعمل، ومحاكاة انقطاع المنطقة لممارسة التحويل. هذا ضروري أيضًا للمُنظمين – لإثبات القدرة على (BCP – Business Continuity Planning).

التوافر العالي للواجهات الخارجية: يجب أن يُكمل التوافر العالي للنظام الأساسي بتوافر عالٍ لتكاملاته. على سبيل المثال، إذا تكاملنا مع بوابة SWIFT، يجب أن تكون هناك اتصالات بوابة احتياطية. يجب أن تكون نقاط نهاية API للخدمات المصرفية عبر الإنترنت خلف مدير حركة عالمي بحيث إذا تعطل موقع واحد، يتولى الآخر خدمة العملاء. وبالمثل، إذا كانت خدمة chatbot خارجية يجب نشرها بشكل احتياطي. جميع المكونات المساندة (Redis caches، الوسطاء الرسائل، إلخ) يجب أن تكون موزعة. على سبيل المثال، يمكن لمجموعة (Kafka) من 3 عقد أن تتحمل فشل عقدة واحدة دون توقف.

المراقبة وأتمتة التحويل: سنستخدم أدوات مراقبة لاكتشاف الأعطال (مثل نبضات DB، فحوصات صحة التطبيق). أدوات مثل (MHA – Master High Availability Manager) أو Orchestrator لـ MySQL يمكنها أتمتة التحويل عند الفشل. على Kubernetes (إذا قمنا بالحاويات)، يمكن لمُشغل (operator) التعامل مع التحويل. كما نُعد تنبيهات (SMS/Email) لفريق العمليات عند الأعطال الحرجة، للتدخل إذا فشلت الأنظمة الآلية.

لتلخيص (HA/DR): يعمل النظام على بنية تحتية احتياطية بدون نقطة فشل واحدة: عدة خوادم تطبيق، قاعدة بيانات عنقودية، مكونات شبكة احتياطية. يتم نشره عبر عدة مناطق توافر لـ HA محلي، وينسخ إلى موقع بعيد لـ DR. هدفنا تحقيق توافر مستمر بحيث حتى في سيناريو كارثي، يمكن استعادة العمليات المصرفية الأساسية بسرعة، بما يتماشى مع اتفاقيات مستوى الخدمة الصارمة وتوقعات المنظمين (غالبًا يطلب المنظمون RPO <= 15 دقيقة وRTO <= ساعتين للأنظمة الحرجة، وهو ما يلبيه تصميمنا بسهولة).

التحليل المقارن: أنظمة البنوك الأساسية مفتوحة المصدر

تحويل (ERPNext) بهذه الطريقة يضعه في منافسة أو تكامل مع حلول البنوك الأساسية مفتوحة المصدر الموجودة. النظامان الأبرز هما Apache Fineract (وتوزيعه Mifos X) وأنظمة أخرى مثل Mifos/Fineract CN. سنفحص كيف يقارن نهجنا.

Apache Fineract/Mifos: يُعتبر (Apache Fineract) محركًا ناضجًا ومفتوح المصدر للبنوك الأساسية، استُهدف في البداية للتمويل الأصغر، ثم توسّع ليشمل البنوك الرقمية. يوفر مجموعة شاملة من الخدمات المصرفية جاهزة للاستخدام – بما في ذلك إدارة العملاء، حسابات القروض والادخار، المعاملات، تعريف المنتجات، والتقارير[1]. هذه تتوافق بشكل وثيق مع الوحدات التي نخطط لبنائها. على سبيل المثال، تتضمن مجموعة ميزات (Fineract) إدارة العملاء، إدارة المحافظ/الحسابات، إنشاء القروض وإدارتها، الادخار، دفتر الأستاذ العام، التقارير، وحتى التكاملات مثل الخدمات المصرفية عبر الهاتف المحمول[12]. في الأساس، فإن "قائمة الرغبات" للوظائف في (ERPNext) موجودة إلى حد كبير في نموذج (Fineract). ومن خلال دراسة (Fineract)، نضمن أننا لا نفتقد مجالات رئيسية. يغطي تصميمنا بالفعل تلك الميزات (القروض، الودائع، GL، التقارير، إلخ)، وبالإضافة إلى ذلك نُركز على الامتثال والمدفوعات الفورية (مجالات قد لا يغطيها (Fineract)، الذي ركّز تاريخيًا على التمويل الأصغر، بشكل كامل مثل تكامل SWIFT).

البنية المعمارية: يُبنى (Fineract 1.x) كتطبيق مونوثي مدفوع بـ (REST API) مع هيكلية معيارية (مشابهة لرؤيتنا للمونوث المعياري). وهو متعدد المستأجرين ويمكن نشره على السحابة أو داخليًا[2]. ومن المثير للاهتمام أن (Fineract) يستخدم (CQRS) كمبدأ أساسي، حيث يفصل بين معالجة الأوامر والاستعلامات لتحسين التوسع والحفاظ على سجل للتغييرات[2]. نحن نتماشى مع ذلك من خلال دمج (CQRS) وتسجيل الأحداث. كما يعزل (Fineract) منطق كل وحدة في طبقات خدمة ويُعرّض كل شيء عبر (REST API)[2][2]. نهجنا باستخدام (ERPNext) سيكشف أيضًا عن واجهات APIs لجميع العمليات ويُفصل الاهتمامات حسب الوحدات. أحد الفروقات هو التكنولوجيا: (Fineract) مبني على (Java/Spring) مع قاعدة بيانات (MySQL)، بينما (ERPNext) مبني على (Python/Frappe) مع (MariaDB). لكن من الناحية المفاهيمية، كلاهما يعتمدان على قواعد بيانات علائقية ولديهما طبقات خدمات ويب.

حاول (Fineract) تطوير بنية جيل جديد قائمة على الخدمات الصغيرة (Fineract CN)، والتي استخدمت عشرات الخدمات الصغيرة، (Cassandra و MariaDB) و (ActiveMQ)[13]. لكن المشروع تم الاستغناء عنه في النهاية (اعتبارًا من 2023) بسبب التعقيد ونقص المساهمين[14]. هذه الملاحظة التاريخية تدعم نهجنا الحذر تجاه الخدمات الصغيرة – فهي تُشير إلى أن المونوث المعياري قد يكون أسهل في الصيانة في السياق مفتوح المصدر. نحن نضع امتداد (ERPNext) بنفس الطريقة: نظام مترابط يمكن توسيعه بشكل معياري.

فجوات الوظائف: أحد المجالات التي قد لا يغطيها (Fineract) بالكامل هو الامتثال التنظيمي – لأن العديد من تطبيقات التمويل الأصغر تتعامل مع المحاسبة ولكن ليس معايير (Basel) المتقدمة. منصتنا تستهدف صراحةً الامتثال (Basel, IFRS, AML) كعنصر أساسي. قد يكون ذلك نقطة تميّز أو مجالًا للنظر في المساهمة في (Fineract). النقطة المهمة هي أنه باستخدام (ERPNext) (الذي يملك محرك محاسبة غنيًا ونظام تقارير مرنًا)، يمكننا تنفيذ تقارير (IFRS) والتقارير التنظيمية بشكل أكثر سهولة. غالبًا ما تتطلب تطبيقات (Fineract) أدوات إضافية للتقارير التنظيمية.

قابلية التوسع: لدى (ERPNext) ميزة كونه نظام ERP كامل – لذلك إلى جانب البنوك الأساسية، يتضمن وحدات مثل الموارد البشرية، الرواتب، المشتريات، CRM، إلخ. يمكن أن يستفيد البنك من ذلك باستخدام نظام واحد للبنوك الأساسية والعمليات المؤسسية (مثل استخدام HR في (ERPNext) لإدارة الموظفين، أو وحدة إدارة الأصول لإدارة معدات الفروع). يركز (Fineract) على الخدمات المالية وسيحتاج إلى تكامل مع ERP منفصل لتلك الوظائف. على النقيض من ذلك، يمكن أن يخدم (ERPNext) المطوَّر كحل متكامل للبنك الصغير أو (fintech) الذي يرغب أيضًا بقدرات ERP. هذا يمكن أن يقلل من تكاليف التكامل بين النظام المصرفي الأساسي والأنظمة المؤسسية الأخرى. من ناحية أخرى، قد يكون هذا النطاق الواسع عيبًا للبنوك الكبيرة جدًا التي تفضل أنظمة متخصصة، لكن جمهورنا المستهدف على الأرجح يبدأ مع المؤسسات المالية الصغيرة والمتوسطة في الخليج أو الأسواق الناشئة، التي تُقدّر الحلول الشاملة وذات التكلفة المعقولة.

المجتمع والدعم: يحظى (Apache Fineract) بدعم مجتمع عالمي وحوكمة (Apache)، مما يجعله نظامًا معروفًا (أكثر من 400 مؤسسة تستخدم واجهات (Mifos/Fineract) APIs[12]). يملك (ERPNext) أيضًا مجتمعًا قويًا ولكن بشكل أساسي في مجال ERP العام، وليس في البنوك. من خلال ريادة تطوير البنوك الأساسية عبر (ERPNext)، قد نُنشئ شريحة جديدة من المجتمع. يجب أن نضع في الاعتبار أن التوثيق، والموافقات التنظيمية، وما إلى ذلك قد تكون أقل نضجًا لحل مصرفي عبر (ERPNext) مقارنةً بشيء مثل (Fineract) الذي خضع لتطبيقات التمويل الأصغر. للتخفيف من ذلك، سننتج توثيقًا شاملاً ونفكر في المساهمة بامتداداتنا المصرفية كموديول مفتوح المصدر لجذب التعاون (مماثل لطريقة مجتمع Fineract).

الأداء: أثبت (Fineract) أنه يتوسع إلى ملايين العملاء في سياقات التمويل الأصغر. أداء (ERPNext) في مثل هذه السيناريوهات ذات الحجم الكبير غير موثّق بشكل كافٍ، لكن إطار عمل (Frappe) مُحسّن بشكل جيد للمعاملات التجارية. من المرجح أن نحتاج إلى إجراء اختبارات أداء. إذا لزم الأمر، يمكننا الاستفادة من نهج (Fineract) في المعالجة الدُفعية وتصميم الـ (APIs) للعمليات الكبيرة (مثل تطبيق الفائدة على 100 ألف حساب – ربما يمتلك (Fineract) تحسينات عبر SQL أو مهام دفعية، ويمكننا القيام بالمثل عبر الإجراءات المخزنة أو العمليات المتجهة لتجنب التكرار عبر (Python)).

تكامل ClefinCode Chat AI مقابل الآخرين: الأنظمة مفتوحة المصدر مثل Fineract لا تأتي مع روبوت محادثة بالذكاء الاصطناعي. هذا ابتكار في هيكليتنا – حيث أن الاستفادة من الذكاء الاصطناعي للمحادثة في الدعم والإرشاد هو مفهوم جديد نسبياً في أنظمة المصرفية الأساسية. بعض الأنظمة الحديثة المملوكة (مثل Thought Machine Vault) تتفاخر بجاهزيتها للذكاء الاصطناعي، لكن الأنظمة مفتوحة المصدر لم تدمج ذلك بعد. إدراج ClefinCode Chat omni-channel AI في تصميمنا يمكن أن يكون نقطة بيع فريدة، مما يحسن تجربة المستخدم والالتزام بالامتثال.

حلول أخرى: إلى جانب Fineract، هناك حلول مفتوحة أخرى (مثل Genesis Open Bank Project، OSC Core وغيرها)، لكنها إما ليست شاملة بالقدر الكافي أو تركز أكثر على الـ APIs. كما توجد أنظمة مصرفية أساسية متخصصة في التكنولوجيا المالية مثل Thought Machine أو Temenos (proprietary) التي تستخدم تقنيات microservices و cloud-native. Vault التابع لـ Thought Machine مثال على نظام أساسي سحابي مع عقود ذكية للمنتجات. رغم كونه مملوكاً، إلا أنه يوضح الاتجاه: أنظمة تعتمد بالكامل على الـ APIs والأحداث. هيكليتنا تتماشى مع هذه التوجهات (APIs، الأحداث، الاستعداد للسحابة).

مقارنة أخرى: Mifos X (الذي هو أساساً Fineract مع واجهات ويب وموبايل مقدمة من مبادرة Mifos). يقدم Mifos X واجهة ويب جاهزة للموظفين وتطبيق موبايل للعملاء، على رأس نظام Fineract الخلفي[12]. في حالتنا، يوفر ERPNext نفسه واجهة الويب (Desk) لمستخدمي النظام الخلفي (الصرافين والموظفين) وسيتوجب علينا تطوير أو دمج واجهة موجهة للعملاء عبر الإنترنت (قد تكون بوابة أو واجهة أمامية منفصلة باستخدام الـ APIs). قد نستخدم ميزات “Portal” في ERPNext للعملاء، مع أن ذلك سيتطلب تخصيصاً كبيراً لجعله مناسباً لهم. هذا فرق أساسي: Fineract صُمم ليكون نظاماً خلفياً ويتوقع منك بناء الواجهة الأمامية، بينما ERPNext يوفر إطار واجهة يمكننا الاستفادة منه سريعاً للمستخدمين الداخليين، وربما توسيعه للعملاء.

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

وعليه، بينما توفر Fineract/Mifos معياراً مرجعياً، فإن نجاح حلنا سيعتمد على التكامل المحكم (نظام واحد يقوم بكل شيء)، المرونة (تخصيص ERPNext)، وقدرات الامتثال المتقدمة التي يزداد الطلب عليها، خصوصاً من البنوك في مناطق مثل دول مجلس التعاون الخليجي.

تكامل حل ClefinCode Chat AI

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

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

الدمج في الهيكلية: يُنفذ Chat AI كخدمة منفصلة تتصل مع النظام الأساسي عبر APIs والأحداث. سنحافظ على واجهة API آمنة يمكن للروبوت الاتصال بها (مع المصادقة والموافقة المناسبة) لاسترجاع أو تحديث البيانات نيابة عن المستخدم. على سبيل المثال، إذا قال العميل في الدردشة "ما رصيدي في حساب التوفير؟"، سيقوم الروبوت باستدعاء Accounts API للحصول على الرصيد. وإذا قال العميل "رجاءً حوّل 500$ لأخي"، سيوجه الروبوت عبر خطوات الأمان (مثل التحقق عبر OTP)، ثم يستدعي Payments API لتنفيذ التحويل، وأخيراً يرد بالتأكيد.

لتحقيق تجربة سلسة، يستخدم الروبوت Natural Language Processing (NLP) لفهم رسائل المستخدم. على الأرجح يعتمد على نموذج تعلم آلي (ربما مُحسّن لقطاع المصارف) يمكنه التعرف على النوايا (الاستعلام عن الرصيد، تحويل الأموال، إصدار بطاقة، إلخ) والكيانات (المبلغ، الحساب، المستفيد). بعض الاستفسارات يمكنه الإجابة عليها من قاعدة معارفه (مثل: “ما هي ساعات عملكم؟” أو معلومات المنتجات)، لكن بالنسبة لأسئلة الحسابات أو المعاملات، يجب أن يسترجع من الأنظمة الأساسية (حيث يقع التكامل). قد نستخدم نهج مثل Retrieval-Augmented Generation (RAG) حيث يسترجع وكيل الذكاء الاصطناعي البيانات ذات الصلة من ERPNext عبر API ويضمنها في رده[15]. هذا يضمن أن الإجابات مبنية على بيانات حقيقية ومحدثة.

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

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

وظائف الدعم: بصفته وكيلاً للدعم، يمكن للذكاء الاصطناعي التعامل مع العديد من الاستفسارات الشائعة. على سبيل المثال:

1. أسئلة وإجابات معلوماتية: "كيف يمكنني تحديث عنواني؟" – يمكن للروبوت إرشاد العميل ("يمكنك القيام بذلك من إعدادات ملفك الشخصي، أو هل أرشدك الآن؟") وحتى توجيهه عبر مسار محدد (ربما من خلال رابط عميق في التطبيق أو رسائل تفاعلية). أو "ما هو معدل الفائدة على وديعة ثابتة لمدة سنة واحدة؟" – يمكن للروبوت جلب المعدلات الحالية من قاعدة بيانات المنتجات أو قاعدة المعرفة.
2. طلبات المعاملات: "أوقف بطاقتي، لقد سُرقت." – يمكن للروبوت تفعيل وحدة البطاقات (إن وجدت) أو وضع علامة إيقاف على البطاقة في النظام، ثم تأكيد ذلك للمستخدم. "أحتاج قرضاً بقيمة 10,000$" – يمكن للروبوت طرح بعض الأسئلة للتأهيل المبدئي (قد يسحب بعض البيانات مثل درجة الائتمان، أو على الأقل ينشئ Lead في وحدة القروض للمتابعة).
3. التدفقات الموجهة: يمكن للذكاء الاصطناعي المساعدة خطوة بخطوة في العمليات مثل فتح الحساب ("لنبدأ بفتح حساب جديد. الرجاء تزويدي...") أو حل المشكلات (مساعدة المستخدم على التنقل في ميزة معينة). هذا يزيد من سهولة الاستخدام لما قد يكون في الأصل نماذج في الواجهة.

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

بالنسبة للموظفين، يمكن أن يكون الذكاء الاصطناعي مرجعاً سريعاً لقواعد الامتثال. قد يسأل المستخدم: "ما هي الإجراءات للإبلاغ عن معاملة مشبوهة؟" – يمكن للروبوت جلب السياسة ذات الصلة من قاعدة معرفة داخلية أو حتى التحقق مباشرة مما إذا كانت المعاملة المعنية تلبي الحدود من خلال سحب البيانات. سيناريو آخر: يمكن لموظف الامتثال كتابة اسم عميل في الروبوت وسؤاله "هل هناك أي مطابقة على قوائم العقوبات لهذا العميل؟" – يمكن للروبوت تشغيل فحص سريع عبر API للعقوبات أو البحث في السجلات الداخلية والرد. هذا النوع من الفحوصات عند الطلب يحسن كفاءة الامتثال.

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

تعزيز تجربة العملاء: من المعروف أن الذكاء الاصطناعي المحادثاتي في المصارف يحسن من توفر الخدمة للعملاء والتخصيص[15][15]. حلنا يسير في هذا الاتجاه، حيث يهدف إلى كسب رضا العملاء وتقليل العبء التشغيلي. تشير الدراسات إلى أن مثل هذا الذكاء الاصطناعي يمكنه حل غالبية الاستفسارات الروتينية ويصبح قناة رئيسية للتفاعلات[15]. من خلال دمج ClefinCode Chat بعمق، نسعى لتقديم تجربة مستخدم متطورة تعادل ما تقدمه البنوك الكبرى. يمكن تقديم رؤى مالية شخصية عبر الروبوت – مثل: "لقد أنفقت 500$ على الطعام هذا الشهر، بزيادة 10% عن المتوسط؛ جرب أداة الموازنة الخاصة بنا."

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

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

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

باختصار، يُعتبر ClefinCode Chat AI طبقة حاسمة تجلس فوق المنصة المصرفية، مما يجعلها أكثر تفاعلاً وسهولة للمستخدم، بينما تفرض أيضاً عمليات معينة عبر التفاعلات الموجهة. فهو يعزز الدعم من خلال معالجة الاستفسارات بدقة واتساق، ويرشد المستخدمين عبر التدفقات المعقدة مما يقلل الأخطاء، ويمكنه حتى المساعدة في الامتثال من خلال ضمان إلمام العملاء وجمع البيانات الضرورية بشكل محادثاتي. يضع هذا التكامل لحلول الذكاء الاصطناعي المحادثي منصتنا المصرفية في طليعة الابتكار، متماشياً مع اتجاهات الصناعة حيث يتولى المساعدون الافتراضيون بالذكاء الاصطناعي معالجة ما يصل إلى 80% من الاستفسارات الروتينية، مما يحرر الموظفين البشريين للقضايا المعقدة[15][15]. إنه يجسر الفجوة بين المستخدم والعمليات الخلفية المعقدة، مما يجعل التعامل مع منصتنا المصرفية يبدو كحوار ذكي وبسيط بدلاً من التنقل بين متاهة من النماذج والقوائم.

استراتيجيات النشر: ClefinCode Cloud (AWS) و On-Premises

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

ClefinCode Cloud على AWS: ستقدم ClefinCode Cloud Services المنصة المصرفية الأساسية كخدمة مُدارة على بنية AWS التحتية. في هذا النموذج، تقوم ClefinCode بإعداد وصيانة كامل المكدس على AWS، وتقوم البنوك بالاشتراك فيه (نموذج SaaS). العناصر الرئيسية لهذا النشر:

1. نهج تعدد المستأجرين: يمكننا إما استخدام موقع ERPNext منفصل (قاعدة بيانات) لكل بنك عميل (مما يضمن العزل التام للبيانات)، أو قاعدة بيانات واحدة متعددة المستأجرين مع معرفات لكل مستأجر. نظراً لحساسية بيانات البنوك، نميل إلى عزل قاعدة بيانات لكل مستأجر، وربما حتى حسابات AWS أو VPCs منفصلة لكل عميل لتحقيق عزل قوي. ومع ذلك، بالنسبة لعملاء التمويل الأصغر، يمكن استخدام قاعدة بيانات متعددة المستأجرين مع أمان على مستوى الصفوف لتقليل التكلفة؛ هذا خيار تصميم يتم تقييمه حسب الحالة. على سبيل المثال، Fineract متعدد المستأجرين بشكل افتراضي على قاعدة بيانات واحدة[2]، لكن بالنسبة لأغراضنا، قد تجعل النسخ المنفصلة الامتثال أبسط. يمكننا أتمتة التهيئة بحيث يحصل كل بنك جديد على بيئة جديدة (ومع الحاويات، هذا ممكن مع تكلفة بسيطة إضافية).
2. بنية AWS: نستخدم خدمات AWS المُدارة قدر الإمكان. بالنسبة لقاعدة البيانات، يمكن استخدام Amazon RDS (مع محرك MySQL/MariaDB) مع نشر Multi-AZ (الذي يدير داخلياً نسخة احتياطية متزامنة في منطقة توافر أخرى بالإضافة إلى النسخ الاحتياطية) – مما يوفر توافرية عالية بدون الحاجة لإدارة النسخ المتماثلة بأنفسنا. سنقوم بتهيئة نسخ قراءة في RDS لتخفيف الحمل الخاص بالتقارير. يمكن تشغيل التطبيق على AWS ECS أو EKS (حاويات) أو على مثيلات EC2 خلف ELB. الحاويات جذابة من حيث قابلية النقل وسهولة التوسع – يمكننا حاوية تطبيق Frappe/ERPNext واستخدام Kubernetes (EKS) لإدارة الـ pods عبر مناطق التوافر، مع استخدام services للواجهة الأمامية عديمة الحالة و stateful set لأي خدمات دقيقة ذات حالة. يمكن أن يكون event bus عبر AWS MSK (Kafka مُدار) أو SQS/SNS للاحتياجات الأبسط. تكاملات أخرى: AWS S3 لتخزين المستندات (ملفات KYC، الكشوف) بشكل آمن – مما يخفف من عبء تخزين الملفات على قاعدة البيانات ويوفر المتانة. AWS KMS لإدارة مفاتيح التشفير لأي تشفير على مستوى التطبيق. يمكننا الاستفادة من AWS CloudHSM إذا كانت هناك حاجة إلى أمان مادي للمفاتيح (مثل توقيع رسائل SWIFT). بالنسبة لروبوت الدردشة الذكي، إذا كان يستخدم تعلم آلي كثيف، يمكننا استضافة النماذج على AWS باستخدام خدمات مثل Amazon SageMaker أو استخدام واجهات OpenAI APIs، حسب النهج.
3. الأمان على AWS: نفرض تقسيم صارم للشبكة: الخوادم الأساسية موجودة في شبكات فرعية خاصة؛ ولا يُكشف سوى عن النقاط النهائية الضرورية عبر ELB عام (وربما VPN/Direct Connect للوصول الداخلي). تقوم مجموعات الأمان بتقييد حركة المرور بين التطبيق وقاعدة البيانات، إلخ. نستخدم أدوار AWS IAM لأذونات الخدمات و AWS CloudTrail لتدقيق جميع الإجراءات على AWS. البيانات في حالة السكون: تمكين تشفير RDS، وتشفير S3، واستخدام مفاتيح KMS التي نتحكم بها (أو مفاتيح مُدارة من قبل العميل إذا لزم الأمر). البيانات أثناء النقل: فرض TLS على جميع النقاط النهائية (AWS ACM للشهادات). من ناحية الامتثال، تتمتع AWS ببنية تحتية معتمدة (ISO 27001، SOC 2، PCI DSS، إلخ)، مما يعزز وضعنا العام في الامتثال.
4. قابلية التوسع على AWS: باستخدام مجموعات التوسع التلقائي لخوادم التطبيق يمكننا التعامل مع ذروة الاستخدام (مثل معاملات نهاية الشهر أو الانتشار السريع). يمكن للتصميم أن يتوسع إلى مناطق متعددة إذا كنا نخدم عملاء دوليين، ولكن عادةً، لبنك واحد، نختار منطقة أساسية واحدة ومنطقة DR واحدة. يعني الانتشار العالمي لـ AWS أنه يمكننا أيضاً الاستضافة في مراكز بيانات AWS الخاصة بكل منطقة (بالنسبة لدول مجلس التعاون الخليجي، يمكن استخدام منطقة البحرين للعملاء في الشرق الأوسط لتلبية متطلبات مكان البيانات، أو الإمارات إذا فتحت AWS هناك، إلخ). يمكننا أيضاً نشر بيئات اختبار/تجريب بسرعة على AWS لكل عميل أو لكل إصدار جديد.
5. الإدارة والتحديثات: ستتولى ClefinCode جميع التحديثات في بيئة السحابة. من المرجح أن نتبنى نهج DevOps مع Infrastructure as Code (Terraform أو CloudFormation) و CI/CD لتحديث التطبيق بأقل فترة توقف ممكنة (ربما باستخدام blue-green deployment أو التحديثات المتدرجة على Kubernetes). نظراً لأن تحديثات المصرفية الأساسية تتطلب الحذر، سنحدد نوافذ صيانة (لكننا نسعى إلى التحديث بدون توقف قدر الإمكان). كما سنطبق تحديثات الأمان لنظام التشغيل والاعتمادات بشكل مستمر كجزء من الخدمة المُدارة.

النشر في مقر البنك (On-Premises): بعض البنوك (خاصة الأكبر أو تلك في الولايات القضائية الصارمة) ستختار النشر في مقراتها – سواء في مركز بياناتها أو في سحابة خاصة. يمكن نشر هيكليتنا على أجهزة عادية أو آلات افتراضية بشكل مشابه للإعداد السحابي:

1. الهيكلية المرجعية: سنوفر هيكلية مرجعية (مع مخططات وأدلة تثبيت) للنشر في المقر، والتي تعكس عملياً البنية السحابية: موزعات حمل (قد تكون أجهزة مادية أو HAProxy/Nginx)، عدة خوادم تطبيق (افتراضية أو أجهزة فعلية)، مجموعة قاعدة بيانات (قد تستخدم RDBMS المفضل للبنك مثل Oracle أو PostgreSQL إذا أراد – رغم أن برمجيتنا مبنية على MariaDB/MySQL، على الأرجح سنلتزم بها لتجنب تغييرات كبرى)، خادم message broker، إلخ. ينبغي علينا حاوية التطبيق لتبسيط النشر في المقر أيضاً – ربما نقدمه كحاويات Docker مع تنسيق (إذا كان البنك يستخدم OpenShift أو Kubernetes، نزوده بـ Helm charts، أو docker-compose للإعدادات الأبسط).
2. التوافر العالي في المقر: إذا كان لدى البنك مركزا بيانات، نوصي بنفس النسخ المتماثلة متعددة المواقع للـ DR. إذا كان هناك موقع واحد فقط، يتم على الأقل إعداد خوادم متعددة ونسخ احتياطية. سندعم تكوينات مثل MySQL Group Replication أو Percona XtraDB cluster في المقر لتحقيق التوافر العالي. إذا فضلت البنوك Oracle أو MS SQL، سيكون هناك جهد لنقل النظام – على الأرجح ليس ضمن MVP ولكن ربما مستقبلاً للاندماج مع معاييرهم الحالية لتقنية المعلومات. ومع ذلك، قد يكون استخدام MariaDB المدمجة مناسباً حيث أن العديد من حلول المصرفية الأساسية تعتمد عليها (مثل Fineract الذي يستخدم MySQL).
3. تحديد حجم الأجهزة: سنوفر إرشادات بناءً على عدد العملاء/المعاملات المتوقع. ربما يمكن للبنوك الصغيرة تشغيل كل شيء على عدة عقد VM؛ بينما الأكبر قد تستخدم خوادم DB منفصلة مع تخزين عالي IOPS (SSD أو مصفوفات NVMe)، إلخ. سنستفيد من حقيقة أن ERPNext يمكن تشغيله على أجهزة متواضعة ولكن للمصرفية الأساسية مع مئات الآلاف من الحسابات، سنوصي بخوادم عالية الأداء.
4. الصيانة والتحديثات: عادةً ما تعني عمليات النشر في المقر أن قسم تقنية المعلومات بالبنك (أو فريقنا إذا قدمنا عقود دعم للمقر) سيتولى التحديثات. من المرجح أن نصدر إصدارات مرقمة ونوفر سكربتات للتصحيح. تساعد الحاويات هنا أيضاً: نوفر صور حاويات جديدة يتم نشرها في بيئة اختبار، تشغيل سكربتات الترحيل (ERPNext لديه نظام ترحيل لتغييرات قواعد البيانات)، الاختبار، ثم التحويل. بالنسبة للبنوك، إدارة التغيير رسمية، لذا نتوقع دورات تحديث ربع سنوية ربما، مع التصحيحات الحرجة عند الحاجة. نضمن أن تتضمن حزمة المقر مجموعات اختبارات آلية يمكن للبنك تشغيلها بعد التحديث للتحقق من كل شيء (مثل اختبار انحدار على المعاملات الرئيسية).
5. ClefinCode Chat في بيئة On-Prem: قد يكون المكون الذكي أكثر صعوبة في بيئة المقر إذا كان يعتمد على نماذج لغة كبيرة مستضافة خارجياً. قد لا تسمح بعض البنوك بإرسال البيانات إلى واجهات ذكاء اصطناعي خارجية. قد نحتاج إلى خيار لنشر نموذج محلي أصغر أو على الأقل ضمان عدم إرسال بيانات PII إلى أي خدمة خارجية. كخيار بديل، إذا كان البنك موافقاً، يمكن أن تذهب استفسارات الروبوت إلى خدمة ذكاء اصطناعي سحابية لكن بشكل مجهول. سنتكيف مع تفضيل العميل: من أجل العزل الكامل، يمكننا دمج محرك NLP مفتوح المصدر في المقر (مثل Rasa أو spaCy مع نماذج مخصصة).
6. الامتثال في بيئة On-Prem: سيكون البنك مسؤولاً عن الامتثال للبنية التحتية (الأمن المادي، إلخ)، لكن يجب أن يدعم برنامجنا عمليات التدقيق لديهم. على سبيل المثال، قد نوفر سجلات بتنسيق يمكنهم تغذيته في نظام SIEM لديهم. إذا لزم الأمر، يمكننا الدمج مع Active Directory/LDAP الخاص بهم لتمكين تسجيل الدخول الموحد للموظفين.

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

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

بيئات التطوير/الاختبار: يجب أن تسمح كلا طريقتي النشر بسهولة إنشاء بيئات تطوير/اختبار. في ClefinCode Cloud، يمكننا تشغيل نسخة تجريبية لبنك لاختبار ميزات جديدة بأمان. في المقر، ننصح البنك بإنشاء إعداد اختبار منفصل (ربما عدة VMs) لإجراء اختبار قبول المستخدم للإصدارات أو الإعدادات الجديدة.

في الختام، استراتيجيتنا للنشر مرنة: ClefinCode Cloud على AWS لتقديم حل جاهز وقابل للتوسع مع وضوح عالٍ في من يدير ماذا (نحن ندير المكدس، والعميل يستهلك كخدمة)، والنشر في المقر لأولئك الذين يحتاجون للتحكم، مع إرشادات لتنفيذ نفس الهيكلية القوية في بيئتهم. كلا الخيارين يحققان نفس النتيجة من حيث القدرات والأمان – الاختلاف فقط في المسؤولية ومكان الاستضافة. يضمن هذا النهج المزدوج أننا قادرون على خدمة نطاق واسع من العملاء والامتثال للوائح المختلفة المتعلقة بالسحابة في القطاع المصرفي. كما تلاحظ وثائق Apache Fineract، يمكن نشره أيضاً كـ SaaS أو On-Prem[2]، ونحن نتبع نفس النموذج المزدوج المثبت.

من خلال معالجة الفجوات الرئيسية بإضافة وحدات وضوابط جديدة، واعتماد هيكلية قوية بأنماط مثبتة، وضمان التوافر العالي، والتعلم من الأنظمة مفتوحة المصدر القائمة، ودمج المساعدة المبتكرة بالذكاء الاصطناعي، وتقديم نشر مرن، نضع النسخة المطورة من ERPNext (ClefinCode Core Banking) كمنصة مصرفية أساسية متوافقة وآمنة وقابلة للتوسع. ستمكن هذه المنصة المؤسسات المالية من إدارة عملياتها بكفاءة وثقة، مدعومة بتكنولوجيا حديثة ونظام ERP متكامل. وقد أبرز الملخص التنفيذي أعلاه خارطة الطريق: بدءاً من MVP مع الميزات الأساسية، ثم التطوير التدريجي لإضافة قدرات متقدمة (المرحلة 2 و3) بطريقة منظمة. سيتم تطوير كل مرحلة مع مراعاة دقيقة للامتثال التنظيمي واحتياجات المصارف الواقعية، لضمان أن ما يُبنى فوق ERPNext ليس مجرد نظري، بل عملي وقابل للتطبيق لكل من المصرفيين والعملاء. الرؤية النهائية هي نظام مصرفي أساسي مفتوح وقابل للتوسعة يمكنه بالفعل أن يكون بديلاً عن الأنظمة القديمة (كما أصبح ERPNext بديلاً عن أنظمة ERP المملوكة)، مما يوفر في النهاية المرونة والابتكار (مثل الدعم المدفوع بالذكاء الاصطناعي) الذي يمنح المؤسسات ميزة تنافسية مع الحفاظ على الامتثال والاستقرار الصارمين في جوهره.

المصادر:

1. لجنة بازل للإشراف المصرفي، IFRS 9 and expected loss provisioning – Executive Summary، BIS (ديسمبر 2015)[3][3].
2. مؤسسة IFRS، IFRS 7 Financial Instruments: Disclosures – حول الإفصاح عن مخاطر الأدوات المالية[4].
3. Abhijeet Anand، Basel Accords and IFRS 9 – Essentials، Medium (2023) – نظرة عامة على نسب السيولة Basel III (LCR/NSFR)[3].
4. Baker Tilly، It’s time to review liquidity and ALM practices (2025) – تعريف ALM وأهميته[5].
5. Björn Hólmþórsson، ISO 20022 and cloud-native core banking، Akkuro (2025) – يتيح ISO 20022 بيانات أكثر ثراءً للمدفوعات والامتثال[6].
6. Advapay، AML & KYC – Core Banking platform – ميزات وحدة AML/KYC (قوائم العقوبات، التحقق من الهوية، المراقبة القائمة على القواعد، تقييم المخاطر)[7][7].
7. Ali Gelenler، Saga, Outbox, and CQRS with Kafka، Medium (2022) – شرح نمط Saga للمعاملات الموزعة[10] ونمط Outbox للأحداث الموثوقة[10]، وفوائد CQRS[10].
8. 9T9 Information Tech، ERPNext FAQ – يؤكد أن ERPNext يمكن تهيئته للتوافر العالي (موازنة التحميل، النسخ المتماثلة، الفشل التلقائي)[8].
9. Tarapong Sreenuch، Apache Fineract: A Strategic Option for Neo-Banks، Medium (2023) – ميزات Fineract (العملاء، القروض، الادخار، التقارير)[1] ومبادئ البنية الحديثة (cloud-native، API-driven، microservices)[1].
10. مبادرة Mifos، Mifos X on SourceForge – ملخص وظائف Fineract/Mifos (إدارة العملاء، إدارة الحسابات، القروض، الادخار، GL، التقارير، المدفوعات، الخدمات المصرفية عبر الهاتف المحمول)[12] وبنية متعددة المستأجرين قائمة على API[12].
11. Apache Fineract Confluence، Key Design Principles – Fineract هو متعدد المستأجرين يمكن نشره SaaS أو On-Prem[2]، يستخدم CQRS للتدقيق وقابلية التوسع[2]، ويعرض جميع الخدمات عبر REST API مع بنية طبقية[2].
12. K2View، Conversational AI in banking (2025) – فوائد الذكاء الاصطناعي المحادثي: دعم على مدار الساعة، تخصيص، تفاعلات آمنة عبر روبوتات الدردشة[15] والقدرة على الاستفادة من بيانات المؤسسات في الوقت الحقيقي للردود[15].