> ## Content Index
> Fetch the complete content index at: https://arabroot.io/llms.txt
> Use this file to discover other available public pages before exploring further.

# النظام المصرفي الأساسي Core Banking: البنك من الداخل
- URL: https://arabroot.io/articles/النظام-المصرفي-الاساسي-core-banking-كيف-يعمل-البنك-من-الداخل/
- Published: 2026-10-27T11:15:07.000Z
- Updated: 2026-10-27T17:30:13.000Z
- Description: ما الذي يحفظه النظام المصرفي الأساسي وكيف تمر فيه الحركة، ولماذا يعمل بتاريخ عمل ودورة ليلية، مع مختبر لاستحقاق العائد على ألف حساب.
- Author: فريق عرب رووت
- Tags: الأدلة التقنية, التقنية المالية والمدفوعات

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

هذه الكلمات هي لغة النظام المصرفي الأساسي Core Banking System، وهو البرنامج الذي يحفظ عملاء البنك وحساباتهم وأرصدتهم وقيودهم، ويحسب العائد والرسوم والأقساط، ويغلق كل يوم ويفتح اليوم التالي. وكل ما رأيناه في مقالات هذا القسم، من [المقاصة والتسوية](https://arabroot.io/articles/%D9%83%D9%8A%D9%81-%D8%AA%D9%86%D8%AA%D9%82%D9%84-%D8%A7%D9%84%D8%A7%D9%85%D9%88%D8%A7%D9%84-%D8%A8%D9%8A%D9%86-%D8%A7%D9%84%D8%A8%D9%86%D9%88%D9%83-%D8%A7%D9%84%D9%85%D9%82%D8%A7%D8%B5%D8%A9-%D9%88%D8%A7%D9%84%D8%AA%D8%B3%D9%88%D9%8A%D8%A9/) إلى [عملية البطاقة](https://arabroot.io/articles/%D9%83%D9%8A%D9%81-%D8%AA%D8%B9%D9%85%D9%84-%D8%B9%D9%85%D9%84%D9%8A%D8%A9-%D8%A7%D9%84%D8%AF%D9%81%D8%B9-%D8%A8%D8%A7%D9%84%D8%A8%D8%B7%D8%A7%D9%82%D8%A9-%D8%A7%D9%84%D8%AA%D9%81%D9%88%D9%8A%D8%B6-%D9%88%D8%A7%D9%84%D8%AA%D8%B3%D9%88%D9%8A%D8%A9-%D9%88%D8%A7%D9%84%D8%A7%D8%B9%D8%AA%D8%B1%D8%A7%D8%B6/) و[المصرفية المفتوحة](https://arabroot.io/articles/%D8%A7%D9%84%D9%85%D8%B5%D8%B1%D9%81%D9%8A%D8%A9-%D8%A7%D9%84%D9%85%D9%81%D8%AA%D9%88%D8%AD%D8%A9-open-banking-%D8%A7%D8%B7%D8%A7%D8%B1-%D8%A7%D9%84%D8%A8%D9%86%D9%83-%D8%A7%D9%84%D9%85%D8%B1%D9%83%D8%B2%D9%8A-%D9%88%D8%A7%D9%84%D9%88%D8%A7%D8%AC%D9%87%D8%A7%D8%AA/)، ينتهي في النهاية بقيد في هذا النظام. وفي هذا المقال ندخل البنك من الداخل: ما الأجزاء التي يتكون منها النظام الأساسي، وكيف تمر الحركة فيه، ولماذا يعمل بتاريخ عمل ودورة ليلية، ولماذا تحديثه من أخطر مشاريع البنوك، مع مختبر صغير في Python لدورة نهاية اليوم يبين أين تختبئ الأخطاء التي لا يكشفها ميزان المراجعة.

وسوف نناقش في هذا المقال ما يلي:

- أين يقع النظام الأساسي بين قنوات البنك وأنظمته الأخرى، ولماذا يسمى «سجل الحقيقة».
- أجزاؤه: ملف العميل، والحسابات، ومحرك المنتجات، والعائد والرسوم، والدفتر العام، ونهاية اليوم.
- مسار الحركة من القناة إلى الحساب والدفتر، والرصيد الدفتري والمتاح، وتاريخ القيمة.
- دورة نهاية اليوم وتاريخ العمل، ولماذا ما زالت البنوك تعمل بها.
- مختبر: استحقاق يومي على ألف حساب، والتقريب، وتشغيل الدورة مرتين.
- تحديث النظام الأساسي ومخاطره، بقصة TSB الموثقة، والتعهيد في قواعد البنك المركزي.
- Apache Fineract كنظام أساسي مفتوح المصدر، وماذا يعني كل ذلك لشركة تبني مع بنك.

## أين يقع النظام الأساسي؟

البنك من الناحية التقنية عشرات الأنظمة، ولكن نظاماً واحداً منها يملك الإجابة عن السؤال الأهم: كم يملك هذا العميل الآن؟ وهذا هو النظام الأساسي، والصورة التالية تبين موقعه بين الطبقات:

![خمس بطاقات من اليمين إلى اليسار: القنوات التطبيق والإنترنت والفروع والصراف، ثم طبقة التكامل Integration أو API بواجهات موحدة أمام النظام الأساسي، ثم النظام الأساسي Core Banking سجل الحقيقة للعملاء والحسابات والمنتجات والدفتر، ثم الأنظمة المحيطة للمدفوعات والبطاقات والامتثال والمخاطر، ثم التقارير المالية والرقابية والإدارية، وتحتها أن النظام الأساسي يملك الأرصدة والقيود وكل ما حوله يقرأ منه أو يكتب إليه](https://arabroot.io/content/images/2026/10/core-banking-01-layers.webp)

النظام الأساسي في الوسط، وكل قناة ونظام محيط يقرأ منه أو يكتب إليه

- **القنوات Channels:** تطبيق الجوال والخدمات المصرفية عبر الإنترنت والفروع والصرافات ومراكز الاتصال، وكلها واجهات لا تحفظ الأرصدة، وإنما تطلبها وتطلب الحركات.
- **طبقة التكامل:** واجهات موحدة أمام النظام الأساسي، تحميه من أن تتصل به كل قناة بطريقتها، وتترجم بين لغته القديمة أحياناً ولغة القنوات الحديثة، وهي ما يتصل به التطبيق الشريك عادة.
- **النظام الأساسي:** ملف العميل والحسابات والمنتجات والأرصدة والقيود والدفتر العام، وهو «سجل الحقيقة» System of Record، أي المرجع الذي يحسم أي اختلاف.
- **الأنظمة المحيطة:** مركز المدفوعات الذي يتصل بالأنظمة الوطنية التي شرحناها في مقال منظومة المدفوعات، ونظام البطاقات، وأنظمة مكافحة غسل الأموال والاحتيال، وأنظمة المخاطر والتمويل، وكل منها يكتب حركاته في النظام الأساسي في النهاية.
- **التقارير:** القوائم المالية، والتقارير الرقابية للبنك المركزي، وتقارير الإدارة، وتقرأ غالباً من نسخة من بيانات النظام الأساسي، لا منه مباشرة، حتى لا تبطئه.

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

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

## ماذا يوجد داخل النظام الأساسي؟

تختلف الأنظمة الأساسية التجارية والمفتوحة في تفاصيلها، ولكنها تشترك في ستة أجزاء تظهر في الصورة التالية:

![ست بطاقات مرقمة: ملف العميل Customer أو CIF بالهوية والمعرفة بالعميل KYC، والحسابات جارية وادخار وتمويل وودائع، ومحرك المنتجات بقواعد كل منتج دون كود جديد، والعائد والرسوم بالاستحقاق اليومي والأقساط، والدفتر العام General Ledger بقيد مزدوج لكل حركة، ونهاية اليوم End of Day بدفعات ليلية بتاريخ عمل، وتحتها أن كل حركة في حساب عميل لها قيد في الدفتر العام ومجموع الدفتر صفر دائماً](https://arabroot.io/content/images/2026/10/core-banking-02-modules.webp)

ستة أجزاء تتكرر في كل نظام أساسي تقريباً

### ملف العميل Customer Information File

كل شيء في البنك يبدأ بالعميل: من هو، وما هويته، وما نتيجة إجراءات معرفة العميل Know Your Customer التي تطلبها أنظمة مكافحة غسل الأموال، وما مستوى مخاطره، وما علاقته بعملاء آخرين (شركة وملاكها، وأب وحساب ابنه القاصر). ويسمى هذا السجل تقليدياً ملف معلومات العميل CIF، وكل حساب يرتبط به، والعميل الواحد قد يملك عشرة حسابات. والدرس للشركة الشريكة أن «العضو» في تطبيقها ليس «العميل» في البنك تلقائياً، فلا يفتح الحساب الادخاري إلا بعد أن يصبح العضو عميلاً في البنك بإجراءاته، والربط بين معرف العضو في التطبيق ومعرف العميل في البنك قرار تصميم مهم: من يحفظه، وماذا يحدث إذا غير العضو رقم جواله أو أغلق حسابه في البنك.

### الحسابات والمنتجات

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

### الدفتر العام General Ledger

كل حركة في حساب عميل لها قيد مزدوج في الدفتر العام: إيداع العميل يزيد التزام البنك تجاهه (ودائع العملاء) ويزيد نقده، والسحب يعكس ذلك، وعائد التمويل يزيد مستحقات البنك ويزيد دخله. وقد شرحنا القيد المزدوج للمهندسين في [مقال المحفظة الرقمية](https://arabroot.io/articles/%D9%83%D9%8A%D9%81-%D8%AA%D8%A8%D9%86%D9%8A-%D9%85%D8%AD%D9%81%D8%B8%D8%A9-%D8%B1%D9%82%D9%85%D9%8A%D8%A9-ledger/#double-entry)، والفرق في البنك أن هناك مستويين: حسابات العملاء الفرعية بالملايين، والدفتر العام بحساباته المحاسبية المعدودة، ومجموع أرصدة حسابات العملاء من منتج معين يجب أن يساوي رصيد حساب الدفتر العام المقابل في كل لحظة. وهذه المطابقة بين الدفترين من أهم الفحوص اليومية في البنك، وأي اختلاف فيها يعني أن حركة سجلت في مكان ولم تسجل في الآخر.

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

### العائد والرسوم والأقساط

البنك يحسب العائد على الودائع والتمويل يومياً في الغالب، حتى لو دفعه أو حصله شهرياً، والسبب أن الرصيد يتغير كل يوم، فالعائد العادل يحسب على رصيد كل يوم بعدد أيامه. وطريقة عد الأيام Day Count Convention جزء من تعريف المنتج: Actual/365 مثلاً يقسم المعدل السنوي على 365 ويضربه في عدد الأيام الفعلية، وطرق أخرى تعامل كل شهر كثلاثين يوماً. والفرق بين الطرق صغير في اليوم الواحد وكبير على ملايين الحسابات وسنوات، لذلك تكتب في العقد وفي إعدادات المنتج. ومع العائد تأتي الرسوم الدورية، والأقساط المستحقة، والتأخر في السداد وما يترتب عليه، وكلها تحسب في دورة نهاية اليوم.

### الوديعة والتمويل: منتجان بسلوكين مختلفين

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

## مسار الحركة: سحب 500 ريال من الصراف

لنتبع حركة واحدة بسيطة داخل البنك، والصورة التالية تبين مسارها:

![خمس محطات من اليمين إلى اليسار: القناة الصراف أو التطبيق بطلب برقم وتوقيت، ثم الفحوص الرصيد المتاح والحدود والحجوزات، ثم قيد الحساب مدين حساب العميل بتاريخ القيمة، ثم قيد الدفتر ودائع العملاء مقابل النقد، ثم المطابقة بين الصراف والدفتر آخر اليوم، وتحتها أن الرصيد الذي يراه العميل والقيد الذي يراه المحاسب يجب أن يتحركا معاً أو لا يتحركا](https://arabroot.io/content/images/2026/10/core-banking-03-posting.webp)

حركة واحدة تلمس الحساب والدفتر والمطابقة، وكلها في معاملة واحدة

1. **القناة:** الصراف يرسل طلب سحب بمعرف فريد ووقت، وفي بطاقات مدى يمر الطلب أولاً بالشبكة إلى البنك المصدر كما شرحنا في مقال منظومة المدفوعات.
2. **الفحوص:** النظام الأساسي يحسب الرصيد المتاح Available Balance، وهو الرصيد الدفتري مطروحاً منه الحجوزات مثل تفويضات البطاقات التي لم تحصل بعد، ويفحص حدود السحب اليومية وحالة الحساب.
3. **قيد الحساب:** يخصم 500 ريال من حساب العميل، بتاريخ قيد هو تاريخ العمل الحالي، وتاريخ قيمة Value Date هو التاريخ الذي يبدأ منه أثر الحركة على حساب العائد.
4. **قيد الدفتر:** في نفس المعاملة قيد في الدفتر العام: مدين ودائع العملاء، ودائن نقد الصراف.
5. **المطابقة:** في نهاية اليوم يطابق النقد المصروف فعلاً من الصراف مع قيود الدفتر، وأي فرق يذهب إلى حساب وسيط للتحقيق.

وفي هذا المسار ثلاثة مفاهيم تحتاجها الشركة الشريكة: الرصيد الدفتري والرصيد المتاح مختلفان، فالتطبيق الذي يعرض الدفتري قد يعد العضو بمال محجوز، وتاريخ القيد وتاريخ القيمة مختلفان أحياناً، فالإيداع بعد موعد القطع قد يقيد اليوم بقيمة الغد، والحركة إما تتم كلها (الحساب والدفتر) أو لا تتم، وهذه هي المعاملة Transaction بمعناها في قواعد البيانات، كما شرحنا في [تعلم SQL (3)](https://arabroot.io/articles/%D8%AA%D8%B9%D9%84%D9%85-sql-3-cte-%D9%88%D8%AF%D9%88%D8%A7%D9%84-%D8%A7%D9%84%D9%86%D9%88%D8%A7%D9%81%D8%B0-%D9%88%D8%A7%D9%84%D9%85%D8%B9%D8%A7%D9%85%D9%84%D8%A7%D8%AA/).

### الحجوزات Holds: المال الموجود وغير المتاح

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

## دورة نهاية اليوم وتاريخ العمل

أكثر ما يستغربه المهندس القادم من الأنظمة الحديثة أن البنك يعمل بتاريخ عمل Business Date مستقل عن التاريخ الحقيقي، وأن هذا التاريخ لا يتقدم وحده عند منتصف الليل، وإنما تقدمه دورة نهاية اليوم End of Day. والصورة التالية تبين خطوات الدورة النموذجية:

![سلم من ست درجات: إغلاق القنوات أو تحويلها لتاريخ الغد، ثم الاستحقاق عائد يومي لكل حساب، ثم المستحقات أقساط ورسوم وتأخر، ثم الدفتر العام ترحيل القيود وميزان المراجعة، ثم التقارير المالية والرقابية، ثم فتح اليوم بتاريخ عمل جديد، وتحتها أن كل خطوة مرتبطة بتاريخ العمل وتشغيلها مرتين لنفس التاريخ خطأ لا يكشفه ميزان المراجعة](https://arabroot.io/content/images/2026/10/core-banking-04-eod.webp)

الدورة الليلية تغلق يوماً محاسبياً كاملاً وتفتح الذي بعده

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

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

### الحركات بتاريخ قيمة سابق

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

## المختبر: دورة نهاية يوم على ألف حساب تمويل

المختبر برنامج Python صغير يحاكي جزءاً من دورة نهاية اليوم: ألف حساب تمويل بأرصدة ومعدلات مولدة عشوائياً ببذرة ثابتة، لا تمثل أي بنك أو منتج حقيقي، ولكل يوم من أكتوبر 2026 يحسب العائد اليومي لكل حساب بطريقة Actual/365، ويرحله إلى الدفتر العام بقيد مزدوج: مدين حساب المستحقات، ودائن حساب الدخل، ثم يحسب ميزان المراجعة. والمبالغ بالهللة، والحسابات الوسيطة بالنوع `Decimal` لا `float`، للسبب الذي شرحناه في مقال المقاصة والتسوية. وفي البرنامج طريقتان للتقريب، وحماية من تشغيل الدورة مرتين لنفس التاريخ، وخيار `--allow-rerun` يعطل هذه الحماية لنرى ما يحدث بدونها:

```python
# eod.py: a tiny core-banking end-of-day: daily accrual on 1,000 financing accounts, GL postings, trial balance
import sys
from datetime import date, timedelta
from decimal import Decimal, ROUND_HALF_EVEN
from collections import defaultdict
import random

rnd = random.Random(7)
# 1,000 synthetic financing accounts: outstanding balance in halalas and an annual rate
accounts = [{"id": f"FIN{i:04}", "balance": rnd.randrange(1_000_000, 50_000_000), "rate": Decimal(rnd.choice(["0.045", "0.055", "0.065"]))}
            for i in range(1000)]

gl = defaultdict(int)          # general ledger: account code -> halalas (debits positive, credits negative)
accrued_exact = defaultdict(Decimal)
processed_dates = set()

def post(debit, credit, amount):
    gl[debit] += amount
    gl[credit] -= amount

def run_eod(business_date, round_daily):
    if business_date in processed_dates and "--allow-rerun" not in sys.argv:
        return "skipped: already processed"
    for a in accounts:
        daily = Decimal(a["balance"]) * a["rate"] / Decimal(365)           # Actual/365 day count
        if round_daily:
            amt = int(daily.quantize(Decimal("1"), rounding=ROUND_HALF_EVEN))   # round each day to a halala
            post("1300 accrued receivable", "4100 financing income", amt)
        else:
            accrued_exact[a["id"]] += daily                                 # keep the exact amount, round at month end
    processed_dates.add(business_date)
    return "done"

start = date(2026, 10, 1)
mode = "--round-daily" in sys.argv
for d in range(31):
    run_eod(start + timedelta(days=d), round_daily=mode)
print("rerun of 2026-10-15:", run_eod(date(2026, 10, 15), round_daily=mode))
if not mode:
    for acc_id, exact in accrued_exact.items():
        post("1300 accrued receivable", "4100 financing income", int(exact.quantize(Decimal("1"), rounding=ROUND_HALF_EVEN)))

income = -gl["4100 financing income"]
print(f"mode: {'round every day' if mode else 'exact, round at month end'}")
print(f"October income: {income/100:,.2f} SAR   GL lines: {dict((k, v) for k, v in gl.items())}")
print("trial balance (must be 0):", sum(gl.values()))
```

وعند تشغيله بالأمر `python eod.py` على Python 3.13 سوف يكون المخرج كما يلي:

```text
rerun of 2026-10-15: skipped: already processed
mode: exact, round at month end
October income: 1,149,017.41 SAR   GL lines: {'1300 accrued receivable': 114901741, '4100 financing income': -114901741}
trial balance (must be 0): 0
```

في الكود والمخرج أعلاه لاحظ التالي:

- دخل أكتوبر من الحسابات الألف 1,149,017.41 ريالاً، والطريقة هنا تحفظ العائد الدقيق لكل حساب كل يوم بالنوع `Decimal`، وتقربه إلى الهللة مرة واحدة في آخر الشهر عند الترحيل، بطريقة تقريب المصرفيين ROUND\_HALF\_EVEN التي تقرب الخمسة إلى الرقم الزوجي حتى لا يميل التقريب في اتجاه واحد على ملايين العمليات.
- الدفتر العام فيه حسابان فقط، ومجموعهما صفر، فميزان المراجعة Trial Balance متوازن: كل هللة في حساب المستحقات يقابلها هللة في حساب الدخل.
- السطر الأول يقول إن إعادة تشغيل الدورة لتاريخ 15 أكتوبر تخطيت، لأن البرنامج يحفظ التواريخ التي عالجها في `processed_dates` ويرفض تكرارها. وفي نظام حقيقي يكون هذا قيداً في قاعدة البيانات على تاريخ العمل وخطوة الدورة، لا مجموعة في الذاكرة.

### ماذا لو قربنا كل يوم؟

كثير من الأنظمة تقرب العائد اليومي إلى الهللة كل يوم وترحله، وهذا أبسط، فلنقارن بالأمر `python eod.py --round-daily`:

```text
rerun of 2026-10-15: skipped: already processed
mode: round every day
October income: 1,149,017.79 SAR   GL lines: {'1300 accrued receivable': 114901779, '4100 financing income': -114901779}
trial balance (must be 0): 0
```

الفرق 38 هللة على ألف حساب في شهر واحد، أي 1,149,017.79 مقابل 1,149,017.41 ريالاً. والرقم صغير، ولكن له معنى: التقريب اليومي يجمع خطأ تقريب لكل حساب في كل يوم، أي 31 ألف عملية تقريب في الشهر بدلاً من ألف، والخطأ لا يختفي بالتقريب المتوازن بالضرورة، فيظهر فرق. وفي بنك فيه ملايين الحسابات لسنوات يصبح الفرق مبلغاً يسأل عنه المدقق، والأهم أن العميل الذي يحسب عائده بنفسه بطريقة العقد قد يجد هللات لا تطابق. لذلك طريقة التقريب ليست تفصيلاً تقنياً، وإنما جزء من تعريف المنتج يكتب في العقد وفي محرك المنتجات، ويختبر بحسابات معروفة النتيجة.

### ماذا لو أعيد تشغيل الدورة لنفس التاريخ؟

الآن نعطل الحماية بالخيار `--allow-rerun`، كأن مشغل الدورة أعاد تشغيلها بعد عطل دون أن يعرف أن خطوة الاستحقاق كانت قد اكتملت:

```text
rerun of 2026-10-15: done
mode: exact, round at month end
October income: 1,186,082.61 SAR   GL lines: {'1300 accrued receivable': 118608261, '4100 financing income': -118608261}
trial balance (must be 0): 0
```

وهنا الدرس الأهم في المختبر: الدخل قفز إلى 1,186,082.61 ريالاً، أي زيادة 37,065.20 ريالاً هي عائد يوم كامل استحق مرتين على كل الحسابات، ومع ذلك فميزان المراجعة ما زال صفراً. والسبب أن القيد المكرر نفسه متوازن، مدين ودائن بنفس المبلغ، فالميزان يكشف القيد الذي ينقص طرفه الآخر، ولا يكشف القيد الكامل المكرر. وهذا الخطأ لا يظهر إلا بفحوص أخرى: مقارنة الدخل اليومي بالمتوقع من الأرصدة والمعدلات، وعدد الأيام المستحقة لكل حساب في الشهر، وحماية التكرار نفسها على مستوى تاريخ العمل وخطوة الدورة. والقاعدة التي يحفظها كل من عمل في الأنظمة المصرفية: كل خطوة في الدورة الليلية يجب أن تكون آمنة عند إعادة التشغيل، تماماً مثل معالج الأحداث في مقال البطاقات، وقد شرحنا الفكرة في [Idempotency: كيف تجعل العملية آمنة عند تكرارها](https://arabroot.io/articles/idempotency-%D9%83%D9%8A%D9%81-%D8%AA%D8%AC%D8%B9%D9%84-%D8%A7%D9%84%D8%B9%D9%85%D9%84%D9%8A%D8%A9-%D8%A7%D9%85%D9%86%D8%A9-%D8%B9%D9%86%D8%AF-%D8%AA%D9%83%D8%B1%D8%A7%D8%B1%D9%87%D8%A7/).

والصورة التالية تلخص النتائج الثلاث:

![ثلاث بطاقات: دقيق ثم تقريب 1,149,017.41 بالتقريب في آخر الشهر، وتقريب يومي 1,149,017.79 بفرق 0.38 ريال على 1,000 حساب، وتشغيل مكرر 1,186,082.61 بيوم زائد وميزان المراجعة صفر، وتحتها أن المبالغ بالريال من المختبر في المقال ببيانات مولدة](https://arabroot.io/content/images/2026/10/core-banking-05-lab.webp)

ميزان المراجعة متوازن في الحالات الثلاث، والخطأ الأكبر في الثالثة

## النظام الذي لا يتوقف: الأداء والتدقيق

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

### من غير ماذا؟ مبدأ العينين الأربع

في النظام الأساسي عمليات لا يكفي أن يقوم بها شخص واحد، مثل تعديل بيانات عميل حساسة، أو قيد يدوي في الدفتر العام، أو تغيير معدل منتج، أو رفع حجز قضائي. ولهذه العمليات مبدأ يسمى المنشئ والمراجع Maker-Checker أو العينان الأربع: موظف ينشئ التغيير، وموظف آخر بصلاحية مختلفة يراجعه ويعتمده، ولا يصبح التغيير فعالاً قبل الاعتماد، وكل خطوة تسجل باسم صاحبها ووقتها. والسبب أن الخطأ أو الاحتيال من شخص واحد صعب الاكتشاف بعد وقوعه، وسهل المنع قبله. ونفس المبدأ يصلح لأي نظام مالي تبنيه: القيد اليدوي في دفتر شركتك، وتعديل مبلغ استرداد كبير، وتغيير الحساب البنكي لمورد، كلها تستحق موافقة ثانية وسجل تدقيق، كما شرحنا في [Audit Trail: كيف تبني سجل تدقيق لا يقبل العبث](https://arabroot.io/articles/%D8%B3%D8%AC%D9%84-%D8%A7%D9%84%D8%AA%D8%AF%D9%82%D9%8A%D9%82-audit-trail-%D9%85%D9%86-%D9%81%D8%B9%D9%84-%D9%85%D8%A7%D8%B0%D8%A7-%D9%88%D9%85%D8%AA%D9%89/).

### التقارير: من النظام الأساسي إلى الجهة المنظمة

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

### كيف تختبر نظاماً يعيش على التواريخ؟

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

### والبنوك الرقمية: هل تغير شيء؟

يذكر [التقرير السنوي الستون للبنك المركزي](https://www.sama.gov.sa/en-US/Publications/EconomicReports/AnnualReport/Sixtieth%5FAnnual%5FReport-EN.pdf?ref=arabroot.io) أن ثلاثة بنوك رقمية حصلت على تراخيص مصرفية، وصفحة [الجهات المرخصة](https://www.sama.gov.sa/en-US/Supervision/LicenseEntities/Pages/default.aspx?ref=arabroot.io) فيها تصنيف مستقل للبنوك الرقمية. والبنك الرقمي يبدأ دون أنظمة قديمة، فيستطيع أن يختار نظاماً أساسياً حديثاً من البداية، يعمل في السحابة أحياناً، ويتصل بالقنوات عبر واجهات حديثة، ودورته الليلية أقصر وأقل إزعاجاً. ولكن المفاهيم التي في هذا المقال لا تتغير: ملف العميل، والحسابات والمنتجات، والدفتر العام بقيده المزدوج، وتاريخ العمل، والمطابقة، والتقارير الرقابية، فهذه متطلبات العمل المصرفي نفسه لا اختيارات تقنية. والفرق أن البنك الرقمي يستطيع أن يجعلها أسرع وأوضح لعملائه، وأن يتيح للشركاء مثل الشركة الناشئة في قصتنا واجهات أنظف للتكامل.

## تحديث النظام الأساسي: أخطر مشروع في البنك

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

![ثلاث لوحات: استبدال دفعة واحدة Big bang كل العملاء في ليلة أسرع على الورق أخطر عند الفشل مثال TSB في 2018، ونقل تدريجي Progressive منتج أو شريحة في كل مرحلة والنظامان يعملان معاً أطول وأقل خطراً، وطبقة جانبية Sidecar منتجات جديدة على نظام جديد والقديم كما هو تكامل أكثر، وتحتها أن غرامة TSB بلغت 48.65 مليون جنيه بحسب بنك إنجلترا في 20 ديسمبر 2022](https://arabroot.io/content/images/2026/10/core-banking-06-modernise.webp)

الطريقة التي تنقل بها البيانات أخطر من النظام الذي تنقلها إليه

📌

في أبريل 2018 نقل بنك TSB البريطاني بيانات خدماته للشركات والعملاء إلى منصة تقنية جديدة، ويذكر [بيان بنك إنجلترا في 20 ديسمبر 2022](https://www.bankofengland.co.uk/news/2022/december/tsb-fined-for-operational-resilience-failings?ref=arabroot.io) أن البيانات نقلت بنجاح، ولكن المنصة واجهت أعطالاً تقنية فورية عطلت الخدمات في الفروع والهاتف والإنترنت والجوال، وتأثرت كل الفروع ونسبة كبيرة من عملاء البنك البالغين 5.2 مليون، ولم يعد البنك إلى عمله الطبيعي حتى ديسمبر 2018\. وغرمت هيئة السلوك المالي FCA وهيئة التنظيم الاحترازي PRA البنك 48.65 مليون جنيه إسترليني مجتمعة، وقال المنظمون إن البنك لم ينظم برنامج النقل ولم يتحكم فيه بشكل كاف، ولم يدر المخاطر التشغيلية الناشئة عن تعهيد التقنية لمورد ثالث حرج، ودفع البنك 32.7 مليون جنيه تعويضات للعملاء المتضررين.

والدرس من القصة ليس أن الاستبدال مستحيل، وإنما أن النقل نفسه مشروع حوكمة ومخاطر قبل أن يكون مشروعاً تقنياً: من يقرر أن النظام الجديد جاهز، وبأي اختبارات أداء وحمل، وما خطة العودة إذا فشل، ومن يراقب المورد الخارجي. ولهذا تتجه بنوك كثيرة إلى النقل التدريجي: شريحة من العملاء أو منتج واحد في كل مرحلة، والنظامان يعملان معاً لفترة، مع مطابقة بينهما كل يوم، أو إلى طبقة جانبية: منتجات جديدة على نظام حديث بجانب القديم، ثم ينقل القديم تدريجياً. والطريقتان أطول وأغلى في التكامل، وأقل خطراً بكثير، وتشبهان نمط النقل التدريجي الذي شرحناه في [قرار Monolith أم Microservices](https://arabroot.io/articles/monolith-%D8%A7%D9%85-microservices-%D9%82%D8%B1%D8%A7%D8%B1-%D8%B5%D8%A7%D8%AF%D9%82-%D9%84%D9%84%D9%81%D8%B1%D9%82-%D8%A7%D9%84%D8%B5%D8%BA%D9%8A%D8%B1%D8%A9-%D9%88%D8%A7%D9%84%D9%83%D8%A8%D9%8A%D8%B1%D8%A9/).

### التعهيد في قواعد البنك المركزي

قصة TSB تذكر المورد الخارجي، وهذا ما تنظمه في المملكة [قواعد التعهيد Rules on Outsourcing](https://rulebook.sama.gov.sa/en/entiresection/2426?ref=arabroot.io) في دليل قواعد البنك المركزي، ففي فقرة نطاق التطبيق أنها تنطبق على ترتيبات التعهيد مع مقدمي الخدمات المحليين والأجانب، وأن على البنوك الحصول على عدم ممانعة مكتوبة من البنك المركزي قبل التعهيد الجوهري Material Outsourcing لمقدمي خدمات من طرف ثالث، وتستثني ترتيبات مثل المقاصة والتسوية والعلاقات المصرفية بالمراسلة. وهذا يعني للشركة التي تقدم للبنك خدمة تقنية جوهرية، مثل استضافة جزء من نظامه أو تشغيله، أن العقد معها قد يحتاج موافقة البنك المركزي قبل أن يبدأ، وأن البنك سيطلب منها متطلبات رقابة وتدقيق ومخارج لا تطلبها شركة عادية، فاحسب هذا الوقت في خطتك إذا كنت تبيع للبنوك.

## Apache Fineract: نظام أساسي مفتوح المصدر

الأنظمة الأساسية في البنوك الكبيرة غالباً تجارية، ولكن هناك نظاماً مفتوح المصدر معروفاً يستحق أن يعرفه المهندس ليفهم المجال بيده: [Apache Fineract](https://fineract.apache.org/?ref=arabroot.io)، وتصفه صفحته بأنه برنامج نظام مصرفي أساسي مفتوح المصدر للخدمات المالية الرقمية، يغطي بيانات العملاء ومحافظ التمويل والادخار والمحاسبة المتكاملة في الوقت الفعلي والتقارير، برخصة Apache 2.0، وأحدث إصدار مستقر تذكره الصفحة 1.15.0\. وفي [مستودعه](https://github.com/apache/fineract?ref=arabroot.io) تجد الكود وطريقة التشغيل. وله مقال عملي مستقل في هذا القسم نشغله فيه ونفتح حساباً ونرى قيوده.

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

## ماذا يعني ذلك لشركة تبني مع بنك؟

عاد فريق الشركة الناشئة من الاجتماع بقائمة قرارات، وهي ما يحتاجه أي فريق يبني منتجاً فوق بنك شريك:

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

### حساب الادخار في قصتنا: من الفكرة إلى الإطلاق

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

### ما الذي تطلبه في وثيقة التكامل مع البنك؟

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

## أخطاء شائعة

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

## قائمة تحقق لمن يبني مع بنك أو داخله

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

## الخلاصة

وصلنا لنهاية الموضوع، وأهم ما فيه:

- النظام المصرفي الأساسي سجل الحقيقة للعملاء والحسابات والأرصدة والقيود، وكل قناة ونظام محيط يقرأ منه أو يكتب إليه.
- أجزاؤه ستة: ملف العميل، والحسابات، ومحرك المنتجات، والعائد والرسوم، والدفتر العام، ونهاية اليوم، وكل حركة في حساب عميل لها قيد مزدوج في الدفتر العام.
- البنك يعمل بتاريخ عمل تقدمه الدورة الليلية، لأن اليوم المحاسبي مفهوم مالي، والأنظمة الحديثة تقلل إزعاجه ولا تلغيه.
- في المختبر فرق التقريب اليومي 38 هللة على ألف حساب في شهر، وتشغيل الدورة مرتين أضاف 37,065.20 ريالاً وميزان المراجعة صفر، فالحماية من التكرار وفحوص المعقولية ضرورية.
- تحديث النظام الأساسي مشروع حوكمة ومخاطر، وقصة TSB في 2018 مثال موثق، والتعهيد الجوهري في المملكة يحتاج عدم ممانعة البنك المركزي.
- Apache Fineract نظام أساسي مفتوح المصدر يصلح للتعلم والمؤسسات الصغيرة، والرخصة المفتوحة لا تعني نظاماً مصرفياً جاهزاً.
- لمن يبني مع بنك: اطلب وثيقة تكامل تجيب عن الرصيد والتواريخ والمعرفات والأحداث والمطابقة وبيئة الاختبار، وابدأ الخطة من المنتج والعميل لا من الشاشات.
- الحجوزات تقلل المتاح ولا تتحرك كحركات، والحركة بتاريخ قيمة سابق قد تغير عائد أيام مضت.

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

وبقية مقالات قسم التقنية المالية والمدفوعات:

[![](https://arabroot.io/content/images/2026/10/wallet-ledger-cover-cover.webp)دليلالمحفظة الرقمية من الداخل: دفتر القيد المزدوج Ledgerكيف تبني محفظة رقمية لا يضيع فيها ريال ولا يخصم مرتين، بالقيد المزدوج والمعاملات والمطابقة مع مزود الدفع.](https://arabroot.io/articles/%D9%83%D9%8A%D9%81-%D8%AA%D8%A8%D9%86%D9%8A-%D9%85%D8%AD%D9%81%D8%B8%D8%A9-%D8%B1%D9%82%D9%85%D9%8A%D8%A9-ledger/)[![](https://arabroot.io/content/images/2026/10/payments-clearing-cover-cover.webp)دليلكيف تنتقل الأموال بين البنوك؟ المقاصة Clearing والتسويةماذا يحدث بين ضغطة «ادفع» ووصول المال: الدفع والمقاصة والتسوية الإجمالية والصافية، مع محاكاة يوم من التسويات بين ستة بنوك.](https://arabroot.io/articles/%D9%83%D9%8A%D9%81-%D8%AA%D9%86%D8%AA%D9%82%D9%84-%D8%A7%D9%84%D8%A7%D9%85%D9%88%D8%A7%D9%84-%D8%A8%D9%8A%D9%86-%D8%A7%D9%84%D8%A8%D9%86%D9%88%D9%83-%D8%A7%D9%84%D9%85%D9%82%D8%A7%D8%B5%D8%A9-%D9%88%D8%A7%D9%84%D8%AA%D8%B3%D9%88%D9%8A%D8%A9/)[![](https://arabroot.io/content/images/2026/10/open-banking-cover-cover.webp)دليلالمصرفية المفتوحة Open Banking: إطار البنك المركزي والواجهاتما تتيحه المصرفية المفتوحة في المملكة وما تفرضه لائحتها، والموافقة من الطلب إلى الحذف، مع مختبر لتطبيق يقرأ بموافقة العميل فقط.](https://arabroot.io/articles/%D8%A7%D9%84%D9%85%D8%B5%D8%B1%D9%81%D9%8A%D8%A9-%D8%A7%D9%84%D9%85%D9%81%D8%AA%D9%88%D8%AD%D8%A9-open-banking-%D8%A7%D8%B7%D8%A7%D8%B1-%D8%A7%D9%84%D8%A8%D9%86%D9%83-%D8%A7%D9%84%D9%85%D8%B1%D9%83%D8%B2%D9%8A-%D9%88%D8%A7%D9%84%D9%88%D8%A7%D8%AC%D9%87%D8%A7%D8%AA/)[![](https://arabroot.io/content/images/2026/10/payment-gateways-cover-cover.webp)دليلبوابات الدفع Payment Gateways في السعودية والبدائل المفتوحةكيف تختار مزود الدفع في المملكة بما تنشره صفحاتهم الرسمية، وأين يقف Stripe والبرمجيات المفتوحة، مع مختبر التحويل بين مزودين.](https://arabroot.io/articles/%D8%A8%D9%88%D8%A7%D8%A8%D8%A7%D8%AA-%D8%A7%D9%84%D8%AF%D9%81%D8%B9-payment-gateways-%D9%81%D9%8A-%D8%A7%D9%84%D8%B3%D8%B9%D9%88%D8%AF%D9%8A%D8%A9-%D9%88%D8%A7%D9%84%D8%A8%D8%AF%D8%A7%D8%A6%D9%84-%D9%85%D9%81%D8%AA%D9%88%D8%AD%D8%A9-%D8%A7%D9%84%D9%85%D8%B5%D8%AF%D8%B1/)[![](https://arabroot.io/content/images/2026/10/card-payment-flow-cover-cover.webp)دليلكيف يعمل الدفع بالبطاقة؟ التفويض Authorization والتسويةمن ضغطة «ادفع» إلى آخر اعتراض: التفويض و3D Secure والتحصيل والتسوية والاسترداد والاعتراض، مع مختبر لأحداث مزود الدفع ومطابقتها.](https://arabroot.io/articles/%D9%83%D9%8A%D9%81-%D8%AA%D8%B9%D9%85%D9%84-%D8%B9%D9%85%D9%84%D9%8A%D8%A9-%D8%A7%D9%84%D8%AF%D9%81%D8%B9-%D8%A8%D8%A7%D9%84%D8%A8%D8%B7%D8%A7%D9%82%D8%A9-%D8%A7%D9%84%D8%AA%D9%81%D9%88%D9%8A%D8%B6-%D9%88%D8%A7%D9%84%D8%AA%D8%B3%D9%88%D9%8A%D8%A9-%D9%88%D8%A7%D9%84%D8%A7%D8%B9%D8%AA%D8%B1%D8%A7%D8%B6/)

## سجل التحديثات

- أكتوبر 2026: كتابة المقال، وتشغيل مختبر دورة نهاية اليوم على Python 3.13.3 ببيانات مولدة، والتحقق من صفحة Apache Fineract وبيان بنك إنجلترا عن TSB وقواعد التعهيد في دليل قواعد البنك المركزي بتاريخ 27 أكتوبر 2026.