بنية نظام التشغيل المالي

---

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

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

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

ثلاث طبقات، ثلاثة نطاقات فشل

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

ملاحظة المعماري: يتطلب التكامل المباشر مع غرف المقاصة تسلسلات رسائل دقيقة. تدير Fernel إنشاء pacs.008 وتسوية camt.054 بشكل مستقل.

الطبقة 1: محرك دفتر الحسابات

المسؤولية: ثوابت القيد المزدوج، سلامة الرصيد، عدم القابلية للتغيير. هذا هو السجل المحاسبي. يجيب على سؤال واحد: ما هي الحالة الموثوقة لكل حساب؟

الخصائص:

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

تردد التغيير: تقريبًا أبدًا. محرك دفتر الحسابات هو بنية تحتية. تُحدّثه لتصحيحات الأداء أو الأمان، وليس لتغييرات منطق الأعمال.

تأثير الفشل: كارثي. إذا فسد دفتر الحسابات، يصبح السجل المالي غير موثوق. كل نظام لاحق، المطابقة، التقارير، الامتثال، يرث الفساد.

الطبقة 2: محرك التنسيق

المسؤولية: تنسيق العمليات متعددة الخطوات. فتح الحساب (إنشاء كيان ← توفير حسابات ← تعيين IBAN ← تشغيل KYC). تنفيذ المدفوعات (التحقق ← الفحص ← الخصم ← الإرسال إلى المقاصة ← تتبع التسوية). هذه ليست عمليات مفردة، إنها سير عمل تمتد عبر خدمات متعددة وقد تستغرق ثوانٍ أو دقائق أو أيامًا لإكمالها.

الخصائص:

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

تردد التغيير: نادرًا. تُضاف أنواع سير عمل جديدة عند تقديم قدرات جديدة (مخطط دفع جديد، فحص امتثال جديد)، لكن المحرك نفسه مستقر.

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

الطبقة 3: طبقة المجال

المسؤولية: كل ما يجعل المنتج منتجًا. هياكل الرسوم. قواعد الامتثال. تكامل مزود KYC. تدفقات الإعداد. محولات API للشركاء. قوالب التقارير. هنا يتميز العمل.

الخصائص:

• التكوين ككود. قواعد المنتج معبر عنها كتكوين مُنسَّخ، وليس مضمنة في كود التطبيق. هيكل رسوم جديد هو نشر تكوين، وليس إصدار كود.
• تجريد المزود. مزود KYC، مخطط الدفع، خدمة فحص AML، كلها خلف واجهات موحدة. طبقة المجال تعرف أنها تحتاج فحص KYC؛ لا تعرف (ولا تهتم) ما إذا كان Identomat أو Onfido أو عملية يدوية تنفذه. تبديل المزودين هو تغيير تكوين.
• إصدارات متكررة. هذه الطبقة تتغير كل سباق. ميزات جديدة، قواعد معدلة، تكاملات جديدة. إيقاع النشر سريع لأن الأعطال هنا محتواة.

تردد التغيير: عالٍ. هذا هو المنتج. يتطور باستمرار.

تأثير الفشل: محتوى. خطأ في حساب المكافآت يكسر المكافآت. لا يفسد دفتر الحسابات. لا يوقف المدفوعات. نطاق الضرر محدود بحدود الخدمة.

لماذا يفشل "استخدم طابور فقط" للعمليات المالية

الغريزة، عند تنسيق عمليات متعددة الخطوات، هي اللجوء إلى طابور رسائل. الخطوة 1 تنشر حدثًا. الخطوة 2 تشترك، تعالج، تنشر الحدث التالي. التعويض هو حدث آخر يُنشر عند الفشل.

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

فكر في تحويل SEPA الائتماني:

1. التحقق من IBAN والمبلغ
2. فحص مكافحة غسل الأموال (استدعاء مزود خارجي)
3. خصم حساب المرسل (عملية دفتر حسابات)
4. الإرسال إلى شبكة المقاصة
5. تتبع حالة التسوية

الخطوة 3 تخصم من حساب المرسل. الخطوة 4 تفشل، شبكة المقاصة ترفض الدفع. يجب على النظام عكس الخصم من الخطوة 3.

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

بمحرك تنفيذ متين: الخطوة 4 تفشل. يسجل المحرك الفشل في السجل. ينفذ التعويض (عكس الخصم) كخطوة مُسجَّلة. إذا انقطع التعويض، يُعاد تشغيله من السجل. العملية بأكملها، بما في ذلك الفشل والتعويض، مرئية في سجل واحد بمعرف ارتباط واحد.

الفرق تشغيلي: "نعتقد أننا عكسناه" مقابل "السجل يثبت أننا عكسناه، وهذا هو التسلسل الدقيق للأحداث."

نمط بوابة الكتابة

نتيجة لهذه البنية: جميع العمليات المغيرة للحالة تمر عبر طبقة التنسيق. القراءات تتجاوزها.

خدمة التمويل (Zig API) تحتفظ بدفتر الحسابات وبيانات المجال. لا تُعرض أبدًا للإنترنت العام. محرك التنسيق هو نقطة الدخول الوحيدة المتحكم بها لجميع التغييرات.

القراءات تذهب مباشرة إلى خدمة التمويل. لا عبء تنسيق. سريع.

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

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

أين تتميز

طبقتا دفتر الحسابات والتنسيق هما بنية تحتية. ضروريتان، لكنهما ليستا ما يجعل منتجك قيمًا للعملاء. يختارك العملاء بسبب:

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

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

البنية تمكّن هذا: طبقات البنية التحتية توفر ضمانات الصحة والمرونة التشغيلية. طبقة المجال توفر مرونة المنتج. الاثنان يتطوران بشكل مستقل.

التوافق التنظيمي بالتصميم

البنية ذات الطبقات الثلاث تتطابق مباشرة مع متطلبات تنظيمية محددة. الامتثال خاصية للتصميم، وليس طبقة تُضاف لاحقًا.

كل متطلب تنظيمي تلبيه الطبقة المصممة له. دفتر الحسابات يتعامل مع سلامة المحاسبة (PSD2، HGB). محرك التنسيق يتعامل مع التتبع والتعافي (DORA المادة 11-12). طبقة المجال تتعامل مع منطق الامتثال (AMLD). لا طبقة واحدة تتحمل العبء التنظيمي الكامل.

ثلاثة أسئلة لتقييم أي منصة مالية

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

1. هل يمكن لخطأ في منطق منتجك أن يفسد دفتر حساباتك؟

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

2. إذا أُعيد تشغيل محرك التنسيق أثناء دفعة، ماذا يحدث للدفعة؟

إذا كانت الإجابة "يعتمد على منطق إعادة المحاولة للمستهلك" أو "سنحتاج للتحقق من طابور الرسائل الميتة"، ليس لديك تنفيذ متين. إذا كانت الإجابة "يعيد المحرك تشغيل السجل ويستأنف عند الخطوة 4"، لديك.

3. هل يمكنك تبديل مزود KYC دون تغيير كود الإعداد؟

إذا كان API المزود يُستدعى مباشرة من تدفق الإعداد، المزود والتدفق مقترنان. تغيير المزود هو تغيير كود، دورة اختبار، ونشر. إذا كان تدفق الإعداد يستدعي واجهة مزود والتكوين يحدد أي تنفيذ ينفذه، التبديل هو تغيير تكوين.

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

---

اقرأ المزيد: دفتر الحسابات | سير العمل، التنفيذ المتين | لماذا القيد المزدوج غير قابل للتفاوض

---

المصادر:

• ThoughtWorks، "Kill your core: The banking revolution you didn't see coming"
• ThoughtWorks، "Cloud-native composable banking" (ورقة AWS البيضاء)
• DORA، اللائحة (EU) 2022/2554، المادة 11-12 (تتبع تكنولوجيا المعلومات والتعافي)
• Stripe (Temporal)، Wise (ترحيل Saga ← Temporal)، N26 (Kafka+Sagas)، Revolut (Temporal)، اعتماد الصناعة للتنفيذ المتين للمسارات الحرجة للمدفوعات