> ## 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.

# كيف تنتقل الأموال بين البنوك؟ المقاصة Clearing والتسوية
- URL: https://arabroot.io/articles/كيف-تنتقل-الاموال-بين-البنوك-المقاصة-والتسوية/
- Published: 2026-10-26T22:20:05.000Z
- Updated: 2026-10-27T18:18:04.000Z
- Description: ماذا يحدث بين ضغطة «ادفع» ووصول المال: الدفع والمقاصة والتسوية الإجمالية والصافية، مع محاكاة يوم من التسويات بين ستة بنوك.
- Author: فريق عرب رووت
- Tags: الأدلة التقنية, التقنية المالية والمدفوعات

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

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

وهذا المقال هو المدخل إلى قسم التقنية المالية والمدفوعات في خارطة الطريق، والتفاصيل السعودية لكل نظام وطني لها مقالها، وكذلك مسار الدفع بالبطاقة والمصرفية المفتوحة، وأما دفتر القيود داخل نظامك فقد شرحناه في [المحفظة الرقمية من الداخل: دفتر القيد المزدوج 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/)، فلن نكرره هنا.

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

- المراحل الثلاث لأي دفعة: أمر الدفع، والمقاصة، والتسوية، ولماذا «مدفوع» لا تعني أن المال وصل.
- أين يتحرك المال فعلاً: نقود البنوك التجارية ونقود البنك المركزي، وحسابات التسوية.
- التسوية الإجمالية الفورية RTGS والتسوية الصافية المؤجلة DNS، وما يكسبه ويخسره كل منهما.
- التقاص الثنائي والمتعدد، والنهائية Finality، وخطر التسوية بقصة بنك Herstatt سنة 1974.
- كيف تبدو هذه المنظومة في المملكة بالأرقام المنشورة من البنك المركزي السعودي.
- مختبر في Python: يوم من 20,000 دفعة بين ستة بنوك بالتسوية الإجمالية والصافية، وماذا يحدث إذا عجز بنك.
- ما يعنيه ذلك لمنتجك: مواعيد الأموال، والمطابقة، والأخطاء الشائعة، وقائمة تحقق.

## ثلاث مراحل في كل دفعة: الدفع والمقاصة والتسوية

عندما يضغط العميل «ادفع» يبدأ تسلسل من المراحل، وكل مرحلة يملكها طرف مختلف وتجيب عن سؤال مختلف، والصورة التالية تبينها:

![خمس محطات من اليمين إلى اليسار: أمر الدفع العميل يطلب نقل 99 ريالاً، ثم التفويض هل يوجد رصيد وهل الطلب صحيح، ثم المقاصة Clearing تجميع وتدقيق وحساب من يدين لمن، ثم التسوية Settlement نقل نهائي بين حسابات البنوك، ثم الإتاحة المال في حساب التاجر فعلاً، وتحتها أن الموافقة على الدفع ليست وصول المال والتسوية النهائية Finality هي اللحظة التي لا رجوع بعدها](https://arabroot.io/content/images/2026/10/payments-clearing-01-three-steps.webp)

«مدفوع» في لوحة التحكم تعني غالباً أن التفويض نجح، والمال لم يتحرك بعد

ولنعرف كل مرحلة كما تعرفها لجنة المدفوعات والبنى التحتية للأسواق CPMI في [مسرد مصطلحاتها](https://www.bis.org/committees/cpmi/glossary?ref=arabroot.io) لدى بنك التسويات الدولية BIS، مع تبسيط بلغة المهندس:

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

وفي قصة الشركة الناشئة حدث التفويض في ثانيتين، فكتب مزود الدفع «مدفوع»، ثم جمع المزود عمليات اليوم مع عمليات تجار آخرين ومرت عبر شبكة البطاقات في المقاصة، ثم سويت بين البنوك، ثم حول المزود إلى حساب الشركة صافي ما يستحقه بعد خصم رسومه، بحسب الجدول المكتوب في عقده معها. والسطر الذي لم يفهمه المؤسس هو هذا الصافي: مجموع عمليات عدة أيام، ناقص الرسوم، ناقص أي استرداد، في مبلغ واحد. وهذا يفسر لماذا المطابقة بين ما في نظامك وما في كشف البنك ليست رفاهية، كما شرحنا في [فقرة المطابقة](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/#reconciliation) في مقال المحفظة الرقمية.

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

## أين يتحرك المال فعلاً؟

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

![أربع محطات من اليمين إلى اليسار: حساب العميل في البنك أ ينقص 99 ريالاً وهي نقود البنك التجاري، ثم حساب بنك أ لدى البنك المركزي ينقص في التسوية وهي نقود البنك المركزي، ثم حساب بنك ب لدى البنك المركزي يزيد في التسوية، ثم حساب التاجر في البنك ب يزيد 99 ريالاً، وتحتها أن العميل والتاجر يريان سطرين والبنكان يسويان بينهما في حساباتهما لدى البنك المركزي ولو كان الطرفان في نفس البنك فلا حاجة لتسوية بين البنوك أصلاً](https://arabroot.io/content/images/2026/10/payments-clearing-02-accounts.webp)

سطران يراهما العميل والتاجر، وسطران آخران لا يراهما أحد منهما

في الصورة أعلاه لاحظ التالي:

- البنك أ يخصم من عميله ويلتزم أمام البنك ب بنفس المبلغ، والبنك ب يضيف لتاجره ويصبح دائناً للبنك أ، وإلى أن تحدث التسوية بين البنكين فهناك دين بين بنكين، وهذا الدين هو ما نسميه خطر التسوية.
- التسوية تنقل نقود البنك المركزي من حساب البنك أ إلى حساب البنك ب، فتنتهي العلاقة، ولا يستطيع أحد أن يعيدها، وهذه هي النهائية.
- إذا كان العميل والتاجر في نفس البنك فالبنك يحرك السطرين داخل دفاتره فقط، دون أي تسوية خارجية، لذلك التحويل داخل نفس البنك كان دائماً أسرع وأرخص تاريخياً.
- البنوك الصغيرة أو الجهات التي ليس لها حساب مباشر لدى البنك المركزي تسوي عبر بنك مشارك يسمى وكيل التسوية Settlement Agent، وقواعد البنك المركزي السعودي تعرف المشاركة غير المباشرة Indirect Participation في [قواعد المشاركة غير المباشرة في SARIE](https://rulebook.sama.gov.sa/en/entiresection/3053?ref=arabroot.io) بأنها بنك غير مشارك يقوم مشارك مفوض بمقاصة عملياته وتسويتها وتسجيلها.

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

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

## التسوية الإجمالية الفورية RTGS أم الصافية المؤجلة DNS؟

هناك طريقتان أساسيتان لتسوية الدفعات بين البنوك، والصورة التالية تقارن بينهما:

![لوحتان: في اليمين RTGS التسوية الإجمالية الفورية كل دفعة وحدها بالكامل ونهائية لحظة تنفيذها وتحتاج سيولة كبيرة وتناسب المبالغ الكبيرة مثل SARIE بين البنوك، وفي اليسار DNS التسوية الصافية المؤجلة تجميع خلال فترة وتسوية صافي كل بنك وسيولة أقل بكثير وخطر حتى لحظة التسوية مثل مقاصة الشيكات، وتحتهما أن المفاضلة دائماً بين السيولة والخطر](https://arabroot.io/content/images/2026/10/payments-clearing-03-rtgs-dns.webp)

نظامان، والفرق بينهما في توقيت النهائية وكمية السيولة

- **التسوية الإجمالية الفورية Real-Time Gross Settlement واختصاراً RTGS:** كل دفعة تسوى وحدها، بقيمتها الكاملة (إجمالية Gross)، لحظة وصولها (فورية Real-Time)، فإذا كان رصيد البنك الدافع لدى البنك المركزي يكفي تنتقل القيمة فوراً وتصبح نهائية، وإذا لم يكف تنتظر الدفعة في طابور حتى يصل إليه المال. والميزة أن خطر التسوية يختفي تقريباً، لأن كل دفعة نهائية لحظة تنفيذها، والثمن أن البنوك تحتاج سيولة كبيرة خلال اليوم.
- **التسوية الصافية المؤجلة Deferred Net Settlement واختصاراً DNS:** تجمع الدفعات خلال فترة (دورة أو يوم)، ثم يحسب صافي ما على كل بنك أو له، ثم تسوى هذه الصافيات فقط في نهاية الدورة. والميزة أن السيولة المطلوبة جزء صغير من القيمة الإجمالية كما سنرى في المختبر، والثمن أن الدفعات كلها معلقة حتى لحظة التسوية، فإذا عجز بنك عن دفع صافيه فالمشكلة تصيب الجميع.

والأنظمة الحديثة لا تختار طرفاً صافياً، فأنظمة RTGS اليوم فيها طوابير وآليات توفير السيولة Liquidity-Saving Mechanisms تبحث في الطابور عن دفعات متقابلة تسويها معاً، وأنظمة الدفع الفوري للأفراد تعطي العميل تأكيداً فورياً وتسوي بين البنوك على دورات متكررة أو بضمانات مسبقة، وتفاصيل كل نظام تختلف بحسب قواعده المنشورة. والمبدأ الذي يحكم هذه الاختيارات في البنوك المركزية هو [مبادئ البنى التحتية للأسواق المالية PFMI](https://www.bis.org/cpmi/info%5Fpfmi.htm?ref=arabroot.io) التي أصدرتها CPMI مع المنظمة الدولية لهيئات الأوراق المالية IOSCO سنة 2012، ويذكر [التقرير السنوي الستون للبنك المركزي السعودي](https://www.sama.gov.sa/en-US/Publications/EconomicReports/AnnualReport/Sixtieth%5FAnnual%5FReport-EN.pdf?ref=arabroot.io) أنه يأخذ هذه المبادئ في الاعتبار في رقابته على أنظمة المدفوعات والتسوية.

### من أين تأتي البنوك بالسيولة خلال اليوم؟

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

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

### أين تقع SARIE من ذلك؟

في المملكة يقوم بدور RTGS نظام التحويلات المالية السعودي SARIE، وتصفه وثيقة أنظمة المدفوعات في [دليل قواعد البنك المركزي](https://rulebook.sama.gov.sa/en/payment-systems?ref=arabroot.io) بأنه نظام التسوية الإجمالية الفورية، وأنه يقدم خدمات التسوية لأنظمة المدفوعات الأخرى المرتبطة به، مثل مقاصة الشيكات الإلكترونية ومدى وسداد، وأن ثلاثة أنظمة صنفت أنظمة مدفوعات مهمة نظامياً Systemically Important Payment Systems هي SARIE ومدى وسداد. ولاحظ أن تاريخ هذه الوثيقة 8 أبريل 2021 وأنها موصوفة في الدليل بأنها مستبدلة Superseded، فالتصنيف الحالي قد يكون في وثيقة أحدث، ولكن الوصف الوظيفي لـ SARIE ما زال يصلح لفهم الصورة. وهذا يعني عملياً أن الدفعة الكبيرة التي أرسلها المؤسس لعقد الإيجار تسوى في SARIE، وأن ما يمر في مدى وسداد يصل في النهاية إلى SARIE ليسوى بين البنوك.

### والمدفوعات الفورية، كيف تكون فورية؟

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

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

## التقاص Netting: لماذا تنقل البنوك الفرق فقط؟

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

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

## المختبر: يوم من التسويات بين ستة بنوك

الآن سوف نبني في Python محاكاة ليوم عمل فيه 20,000 دفعة بين ستة بنوك افتراضية، ثم نسويها بثلاث طرق ونقيس السيولة المطلوبة لكل منها، ثم نشغل نفس اليوم بالتسوية الإجمالية الفورية بسيولة محدودة لنرى الطابور، ثم نجرب ما يحدث في التسوية الصافية إذا عجز بنك في آخر اليوم. والبيانات كلها مولدة بمولد أرقام عشوائي ببذرة ثابتة، فتحصل على نفس الأرقام إذا شغلت الكود، ولا علاقة لها بأي بنك حقيقي. والتشغيل على Python 3.13 دون أي مكتبة خارجية، ولا يحتاج Docker.

### الخطوة الأولى: الإجمالي والصافي الثنائي والصافي المتعدد

الملف التالي يولد الدفعات، ثم يحسب ثلاثة أرقام: مجموع كل الدفعات كما هي، ومجموع ما ينتقل لو تقاص كل بنكين، ومجموع ما ينتقل لو تقاص الجميع في رقم واحد لكل بنك:

```python
# settle.py: one business day of interbank payments, settled gross (RTGS) and net (DNS)
import random
from collections import defaultdict

BANKS = ["A", "B", "C", "D", "E", "F"]
rnd = random.Random(2026)

# 20,000 customer payments between six banks, amounts in halalas (integers, never floats)
payments = []
for i in range(20_000):
    payer, payee = rnd.sample(BANKS, 2)
    amount = rnd.choice([5_000, 9_900, 25_000, 120_000, 1_500_000]) * rnd.randint(1, 4)
    payments.append((i, payer, payee, amount))

gross_total = sum(p[3] for p in payments)

# bilateral positions: what each pair owes after offsetting both directions
pair = defaultdict(int)
for _, payer, payee, amt in payments:
    pair[(payer, payee)] += amt
bilateral_total = 0
for a in BANKS:
    for b in BANKS:
        if a < b:
            bilateral_total += abs(pair[(a, b)] - pair[(b, a)])

# multilateral net position: one number per bank against the system
net = defaultdict(int)
for _, payer, payee, amt in payments:
    net[payer] -= amt
    net[payee] += amt
multilateral_total = sum(-v for v in net.values() if v < 0)
assert sum(net.values()) == 0        # money is only moved, never created

sar = lambda h: f"{h / 100:>16,.2f}"
print(f"payments                  {len(payments):>10,}")
print(f"gross value (SAR)         {sar(gross_total)}")
print(f"bilateral net (SAR)       {sar(bilateral_total)}   {bilateral_total / gross_total:6.2%} of gross")
print(f"multilateral net (SAR)    {sar(multilateral_total)}   {multilateral_total / gross_total:6.2%} of gross")
print()
print("bank  multilateral net position (SAR)")
for b in BANKS:
    print(f"  {b}   {sar(net[b])}")
```

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

```text
payments                      20,000
gross value (SAR)           166,438,304.00
bilateral net (SAR)           9,585,946.00    5.76% of gross
multilateral net (SAR)        3,424,306.00    2.06% of gross

bank  multilateral net position (SAR)
  A        -419,287.00
  B      -2,209,253.00
  C       1,182,918.00
  D         -30,703.00
  E       2,241,388.00
  F        -765,063.00
```

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

- المبالغ بالهللة وبأعداد صحيحة، ولا يوجد أي `float` في الحساب إلا عند الطباعة، والسبب الذي شرحناه في [فقرة المبالغ بالهللة](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/#money-integers) في مقال المحفظة: الكسور العشرية في الحاسب تخطئ في الهللات، والخطأ الصغير في عشرين ألف دفعة يصبح فرقاً لا تجده المطابقة.
- السطر `assert sum(net.values()) == 0` هو قانون حفظ المال في المقاصة: مجموع الصافيات صفر دائماً، لأن كل ريال خرج من بنك دخل إلى آخر. وإذا فشل هذا السطر في نظام حقيقي فهناك دفعة سجلت في طرف واحد فقط.
- القيمة الإجمالية حوالي 166.4 مليون ريال، والتقاص الثنائي يخفض ما ينتقل فعلاً إلى 9.59 مليون (5.76%)، والتقاص المتعدد إلى 3.42 مليون فقط (2.06%). أي أن البنوك الستة تحتاج لتسوية يوم كامل حوالي خمسين مرة أقل من السيولة التي تحتاجها لو سوت كل دفعة وحدها.
- الصافي المتعدد رقم واحد لكل بنك: البنك ب عليه 2.2 مليون، والبنك ه له 2.24 مليون، والبنك د تقريباً متوازن بعجز 30,703 ريالات فقط مع أنه دفع واستلم آلاف الدفعات. ولاحظ أن النسبة كبيرة هنا لأن الدفعات عشوائية ومتوازنة بين البنوك، أما في الواقع فالتدفقات غير متوازنة غالباً (رواتب الشهر تخرج من بنوك الشركات الكبيرة في يوم واحد مثلاً)، فتكون نسبة التقاص أقل.

والصورة التالية تلخص الأرقام الثلاثة:

![ثلاث بطاقات: إجمالي 166.4 مليون ريال كل دفعة تسوى وحدها 100% من القيمة، ثم صافي ثنائي 9.59 مليون ريال كل بنكين يتقاصان 5.76% من القيمة، ثم صافي متعدد 3.42 مليون ريال رقم واحد لكل بنك 2.06% من القيمة، وتحتها أن التقاص يقلل السيولة المطلوبة ولكنه يؤجل لحظة النهائية](https://arabroot.io/content/images/2026/10/payments-clearing-04-netting.webp)

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

### الخطوة الثانية: نفس اليوم بالتسوية الإجمالية وسيولة محدودة

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

```python
# rtgs.py: the same day settled one payment at a time, with limited liquidity per bank
import random
from collections import deque, defaultdict

BANKS = ["A", "B", "C", "D", "E", "F"]
rnd = random.Random(2026)
payments = []
for i in range(20_000):
    payer, payee = rnd.sample(BANKS, 2)
    amount = rnd.choice([5_000, 9_900, 25_000, 120_000, 1_500_000]) * rnd.randint(1, 4)
    payments.append((i, payer, payee, amount))

def run(opening_sar):
    balance = {b: opening_sar * 100 for b in BANKS}     # halalas in each bank's account at the central bank
    queue = deque()
    settled = 0
    peak_queue = 0
    for p in payments:
        queue.append(p)
        progress = True
        while progress and queue:                       # retry the queue after every new payment
            progress = False
            for _ in range(len(queue)):
                pid, payer, payee, amt = queue.popleft()
                if balance[payer] >= amt:               # gross: each payment needs the full amount now
                    balance[payer] -= amt
                    balance[payee] += amt
                    settled += 1
                    progress = True
                else:
                    queue.append((pid, payer, payee, amt))
        peak_queue = max(peak_queue, len(queue))
    stuck = sum(p[3] for p in queue)
    return settled, len(queue), peak_queue, stuck

for opening in (100_000, 500_000, 1_000_000, 3_000_000):
    s, q, peak, stuck = run(opening)
    print(f"opening {opening:>10,} SAR per bank  settled {s:>6,}  still queued {q:>5,}  peak queue {peak:>5,}  stuck value {stuck/100:>14,.2f} SAR")
```

والمخرج سوف يكون كما يلي:

```text
opening    100,000 SAR per bank  settled 19,812  still queued   188  peak queue   255  stuck value   9,810,000.00 SAR
opening    500,000 SAR per bank  settled 19,930  still queued    70  peak queue    99  stuck value   3,450,000.00 SAR
opening  1,000,000 SAR per bank  settled 19,974  still queued    26  peak queue    41  stuck value   1,215,000.00 SAR
opening  3,000,000 SAR per bank  settled 20,000  still queued     0  peak queue     0  stuck value           0.00 SAR
```

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

- برصيد افتتاحي 100,000 ريال لكل بنك سويت أغلب الدفعات (19,812)، ولكن 188 دفعة بقيمة 9.81 مليون ريال بقيت في الطابور في آخر اليوم، أي أن عملاء هذه الدفعات لم يصلهم مالهم، مع أن الصافي المتعدد للنظام كله 3.42 مليون فقط. والسبب أن الدفعات الكبيرة (6 ملايين هللة مضروبة في 1 إلى 4) تحتاج رصيداً أكبر من 100,000 ريال لحظة وصولها، مهما كان البنك سيستلم لاحقاً.
- كلما زاد الرصيد الافتتاحي قل الطابور، وعند 3 ملايين ريال لكل بنك سويت كل الدفعات دون انتظار. ولاحظ أن 3 ملايين أكبر من أكبر صافي مدين في الخطوة الأولى (البنك ب بـ 2.2 مليون)، وهذا ليس صدفة: البنك يحتاج في الأقل ما يغطي أسوأ لحظة في يومه.
- هذا بالضبط ما تدفعه البنوك ثمناً للنهائية الفورية: سيولة محجوزة في حساباتها لدى البنك المركزي، أو اقتراض خلال اليوم من البنك المركزي بضمانات. ولهذا تضيف أنظمة RTGS الحقيقية آليات تبحث في الطابور عن دفعات متقابلة تسويها معاً، ومحاكاتنا لا تفعل ذلك، فهي تبين المشكلة وليس كل حلولها.
- الطابور نفسه خطر تشغيلي: إذا انتظرت كل البنوك أن تستلم قبل أن تدفع، يتوقف النظام كله ولا يتحرك شيء، وهذا ما يسمى الجمود Gridlock، وهو قريب في فكرته من الجمود في قواعد البيانات.

### الخطوة الثالثة: ماذا يحدث إذا عجز بنك قبل التسوية الصافية؟

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

```python
# failure.py: deferred net settlement when bank B cannot pay its net debit at the end of the day
import random
from collections import defaultdict

BANKS = ["A", "B", "C", "D", "E", "F"]
rnd = random.Random(2026)
payments = []
for i in range(20_000):
    payer, payee = rnd.sample(BANKS, 2)
    amount = rnd.choice([5_000, 9_900, 25_000, 120_000, 1_500_000]) * rnd.randint(1, 4)
    payments.append((i, payer, payee, amount))

def positions(pays):
    net = defaultdict(int)
    for _, payer, payee, amt in pays:
        net[payer] -= amt
        net[payee] += amt
    return net

before = positions(payments)
# unwind: remove every payment to or from the failed bank and recompute everyone else
after = positions([p for p in payments if "B" not in (p[1], p[2])])

print("bank   net with B (SAR)   net after unwinding B (SAR)        change")
for b in BANKS:
    if b == "B":
        continue
    print(f"  {b}   {before[b]/100:>16,.2f}   {after[b]/100:>16,.2f}   {(after[b]-before[b])/100:>16,.2f}")
print("unwound payments:", sum(1 for p in payments if "B" in (p[1], p[2])))
```

والمخرج سوف يكون كما يلي:

```text
bank   net with B (SAR)   net after unwinding B (SAR)        change
  A        -419,287.00         146,484.00         565,771.00
  C       1,182,918.00         206,837.00        -976,081.00
  D         -30,703.00        -553,720.00        -523,017.00
  E       2,241,388.00       1,571,492.00        -669,896.00
  F        -765,063.00      -1,371,093.00        -606,030.00
unwound payments: 6783
```

وهنا الدرس الأهم في المختبر كله، فلاحظ ما حدث للبنك د: كان صافيه في الصباح تقريباً صفراً (عجز 30,703 ريالات فقط)، فجهز سيولة صغيرة للتسوية، ثم بعد إلغاء دفعات البنك ب أصبح عليه 553,720 ريالاً لم يخطط لها، لأن جزءاً مما كان سيستلمه من البنك ب اختفى. والبنك و زاد عجزه من 765 ألفاً إلى 1.37 مليون. فإذا لم يملك أحدهما هذه السيولة في نفس الساعة، يعجز هو أيضاً، ويعاد الحساب مرة أخرى، وهكذا ينتقل العجز من بنك إلى آخر، وهذا ما يسمى الخطر النظامي Systemic Risk. ولاحظ أيضاً أن 6,783 دفعة من 20,000 ألغيت، أي أن عملاء ستة بنوك كانوا يظنون أن مدفوعاتهم تمت، ثم اكتشفوا في الصباح أنها لم تتم.

ولهذا السبب تحديداً انتقلت البنوك المركزية في العالم إلى التسوية الإجمالية الفورية للمبالغ الكبيرة، وأضافت لأنظمة التسوية الصافية ضمانات مسبقة وحدوداً للعجز وقواعد واضحة لمن يتحمل الخسارة، وأضافت القوانين مبدأ النهائية الذي يمنع إلغاء التسوية بعد حدوثها. وفي المملكة يذكر التقرير السنوي الستون للبنك المركزي أن مجلس إدارته وافق على [اللائحة التنفيذية لنظام المدفوعات وخدماتها](https://rulebook.sama.gov.sa/en/implementing-regulations-payments-and-payment-services-law?ref=arabroot.io) في 13 يونيو 2023، وأنها تضمنت أحكاماً تتعلق بتصنيف أنظمة المدفوعات المهمة نظامياً والنهائية Finality لضمان سلامة المعاملات واستقرارها.

### ما الذي لا تحاكيه هذه التجربة؟

المحاكاة تبين الفكرة، ولكنها تبسط الواقع في أكثر من مكان، ومن المهم أن تعرف أين حتى لا تبني عليها أكثر مما تحتمل:

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

### ماذا لو أضفنا آلية بسيطة لتوفير السيولة؟

بعد الخطوة الثانية أردنا أن نرى هل تحرك فكرة توفير السيولة الطابور في حالة الرصيد الصغير (100,000 ريال لكل بنك)، فكتبنا أبسط نسخة منها: بعد كل ألف دفعة نحاول تسوية الطابور كله دفعة واحدة، بشرط ألا يصبح رصيد أي بنك سالباً بعد التسوية المجمعة:

```python
# lsm.py: the 100,000 SAR day again, with a simple liquidity-saving step every 1,000 payments
import random
from collections import deque

BANKS = ["A", "B", "C", "D", "E", "F"]
rnd = random.Random(2026)
payments = []
for i in range(20_000):
    payer, payee = rnd.sample(BANKS, 2)
    amount = rnd.choice([5_000, 9_900, 25_000, 120_000, 1_500_000]) * rnd.randint(1, 4)
    payments.append((i, payer, payee, amount))

balance = {b: 100_000 * 100 for b in BANKS}
queue = deque()
offset_batches = 0

def drain():
    progress = True
    while progress and queue:
        progress = False
        for _ in range(len(queue)):
            p = queue.popleft()
            if balance[p[1]] >= p[3]:
                balance[p[1]] -= p[3]; balance[p[2]] += p[3]; progress = True
            else:
                queue.append(p)

def offset_all():
    """settle the whole queue at once if no bank would end up negative"""
    global offset_batches
    after = dict(balance)
    for _, payer, payee, amt in queue:
        after[payer] -= amt; after[payee] += amt
    if queue and min(after.values()) >= 0:
        balance.update(after); queue.clear(); offset_batches += 1

for n, p in enumerate(payments, 1):
    queue.append(p)
    drain()
    if n % 1_000 == 0:
        offset_all()
offset_all()
print(f"still queued {len(queue)}  stuck value {sum(p[3] for p in queue)/100:,.2f} SAR  offset batches {offset_batches}")
```

والمخرج سوف يكون كما يلي:

```text
still queued 188  stuck value 9,810,000.00 SAR  offset batches 0
```

ولم تنجح التسوية المجمعة ولا مرة (`offset batches 0`)، وبقي الطابور كما كان بـ 188 دفعة. والسبب أن شرط «كل الطابور أو لا شيء» صارم جداً: يكفي أن يكون بنك واحد مديناً صافياً في الطابور بأكثر من رصيده لتفشل المحاولة كلها، وهذا ما حدث في كل محاولة. ثم جربنا نسخة ثانية أذكى قليلاً تحذف من المجموعة أكبر دفعة للبنك الذي سيصبح سالباً وتعيد المحاولة حتى تجد مجموعة ممكنة، فنجحت في ثلاث تسويات مجمعة، ولكن الطابور في آخر اليوم أصبح أسوأ (226 دفعة بقيمة 11.09 مليون ريال)، لأن تسوية مجموعة من الدفعات القديمة استهلكت سيولة بعض البنوك في لحظة كانت ستحتاجها فيها دفعات جديدة كانت ستمر وحدها. والدرس أن آليات توفير السيولة في الأنظمة الحقيقية مسألة تحسين Optimisation صعبة، تختار أي المجموعات تسوي ومتى، وليست حلقة بسيطة تكتبها في ساعة، وأن تغييراً يبدو منطقياً في نظام تسوية قد يجعل النتيجة أسوأ إذا لم يقس على بيانات تشبه الواقع.

## خطر التسوية بقصة حقيقية: بنك Herstatt

أشهر مثال على خطر التسوية حدث في ألمانيا قبل خمسين سنة، وصار اسمه اسماً لنوع من الخطر. وتروي [مراجعة BIS الفصلية في يونيو 2026](https://www.bis.org/publ/qtrpdf/r%5Fqt2606c.htm?ref=arabroot.io) القصة كما يلي، والصورة التالية تبين ترتيبها:

![أربع محطات من اليمين إلى اليسار: الصباح في Frankfurt البنوك تدفع المارك لـ Herstatt، ثم 3:30 عصراً السلطات الألمانية تغلق البنك، ثم New York البنك المراسل يوقف دفع الدولار، ثم الطرف المقابل دفع المارك ولم يستلم الدولار، وتحتها أن الحل الذي جاء بعد عقود هو الدفع مقابل الدفع PvP في 26 يونيو 1974 بحسب مراجعة BIS الفصلية في يونيو 2026](https://arabroot.io/content/images/2026/10/payments-clearing-05-herstatt.webp)

طرفا الصفقة دفعا في مدينتين بتوقيتين، وبينهما ساعات لم يحمها شيء

📌

في عصر 26 يونيو 1974 أمرت السلطات الألمانية بتصفية بنك Herstatt، وأغلق البنك في الساعة 3:30 عصراً بتوقيت Frankfurt، فأوقف بنكه المراسل في New York كل المدفوعات الصادرة بالدولار من حسابه. والبنوك التي كانت قد باعت المارك الألماني لـ Herstatt مقابل الدولار كانت قد دفعت المارك في Frankfurt صباحاً، وكان الدولار سيصلها في New York بعد ساعات بسبب فرق التوقيت، فبقيت مكشوفة بكامل قيمة المارك الذي دفعته. والدرس أن الدفعتين في صفقة واحدة إذا سويتا في نظامين منفصلين بتوقيتين مختلفين، فبينهما فترة يكون فيها أحد الطرفين قد دفع ولم يستلم.

والحل الذي جاء بعد ذلك بعقود هو الدفع مقابل الدفع Payment versus Payment واختصاراً PvP: لا تسلم الدفعة الأولى إلا إذا سلمت الثانية في نفس اللحظة، ومن أشهر تطبيقاته نظام CLS لتسوية العملات الأجنبية. ومع ذلك فالمشكلة لم تختف تماماً، ففي نفس المراجعة تقول BIS إن مسحها الثلاثي لسنة 2025 وجد أن أكثر بقليل من 5 تريليونات دولار، أي 36% من متوسط التسوية اليومية للعملات في أبريل 2025، سويت بطريقة PvP التي تزيل خطر التسوية، وأن أكثر من 1.4 تريليون دولار (10%) سويت إجمالياً بين طرفين دون حماية، فهي معرضة لخطر التسوية بالكامل.

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

## المنظومة في المملكة بالأرقام المنشورة

يملك البنك المركزي السعودي عدة أنظمة مدفوعات وطنية، وصفحة [أنظمة المدفوعات الوطنية](https://www.sama.gov.sa/en-US/payment?ref=arabroot.io) على موقعه تذكر منها سداد ومدى وسريع وإيصال، ولكل منها صفحة بسنة إطلاقه ووصفه، إلى جانب SARIE الذي تسوى فيه البنوك فيما بينها. والصورة التالية تجمعها مع أرقام من التقرير السنوي الستين للبنك المركزي، الذي يغطي سنة 2023:

![خمس بطاقات: SARIE نظام التسوية بين البنوك RTGS بـ 199.5 مليون عملية في 2023، ثم سريع للمدفوعات الفورية أطلق 2021 حوالات فورية على مدار الساعة، ثم مدى أطلق 1990 للبطاقات ونقاط البيع والصراف والمتاجر، ثم سداد أطلق 2004 للفواتير بـ 322.4 مليون عملية في 2023، ثم إيصال أطلق 2019 لفواتير المنشآت والمطابقة، وتحتها أن الأرقام من التقرير السنوي الستين للبنك المركزي وسنوات الإطلاق من صفحات الأنظمة الوطنية](https://arabroot.io/content/images/2026/10/payments-clearing-06-saudi.webp)

كل نظام لنوع من المدفوعات، وكلها تنتهي إلى التسوية بين البنوك

وفي [التقرير السنوي الستين](https://www.sama.gov.sa/en-US/Publications/EconomicReports/AnnualReport/Sixtieth%5FAnnual%5FReport-EN.pdf?ref=arabroot.io) أرقام تشرح الفرق بين التسوية بين البنوك ومدفوعات العملاء بوضوح، والجدول التالي ينقل أرقام SARIE لسنة 2023 كما وردت في الجدولين 5.24A و5.24B، مع متوسط قيمة العملية الذي حسبناه بقسمة القيمة على العدد:

| النوع في SARIE (2023)          | عدد العمليات      | القيمة                  | متوسط العملية (حسابنا) |
| ------------------------------ | ----------------- | ----------------------- | ---------------------- |
| مدفوعات العملاء المجمعة Bulk   | 193.7 مليون       | حوالي 5,743 مليار ريال  | حوالي 29,650 ريالاً    |
| مدفوعات العملاء المفردة Single | 2.9 مليون         | حوالي 6,310 مليار ريال  | حوالي 2.18 مليون ريال  |
| المدفوعات المفردة بين البنوك   | حوالي 891 ألفاً   | حوالي 35,917 مليار ريال | حوالي 40.3 مليون ريال  |
| المجموع بكل الأنواع            | حوالي 199.5 مليون | حوالي 49,503 مليار ريال |                        |

وفي الأرقام أعلاه لاحظ التالي:

- المدفوعات بين البنوك أقل من 1% من عدد العمليات، وأكثر من 70% من قيمتها، ومتوسط الواحدة منها حوالي 40 مليون ريال، وهذا هو نوع المدفوعات الذي صممت له التسوية الإجمالية الفورية: عدد قليل ومبالغ ضخمة لا يحتمل أحد أن تبقى معلقة حتى آخر اليوم.
- مدفوعات العملاء المجمعة، مثل الرواتب والتحويلات الدورية، هي أغلب العدد، ومتوسطها حوالي 30 ألف ريال، وهي التي تصل فيها تحويلات الشركات إلى الموظفين والموردين.
- وفي نفس التقرير مرت عبر سداد 322.4 مليون عملية بقيمة حوالي 719 مليار ريال، وبلغ عدد عمليات نقاط البيع حوالي 8,972 مليون عملية بقيمة حوالي 614 مليار ريال، وانخفض عدد الشيكات التجارية والشخصية المقاصة إلى 951 ألف شيك بقيمة 126.1 مليار ريال، أي أن الشيك أصبح نادراً بينما تضاعفت عمليات نقاط البيع في سنوات قليلة بحسب الجدول 5.23 في التقرير.

أما نظام المدفوعات الفورية للأفراد، فتصفه [صفحة سريع](https://www.sama.gov.sa/ar-SA/payment/Pages/Sarie.aspx?ref=arabroot.io) بأنه أطلق سنة 2021 لتسهيل الحوالات منخفضة القيمة بين البنوك المحلية وتنفيذها فوراً على مدار الساعة، وأنه يتيح استخدام معرفات بديلة عن رقم الآيبان مثل رقم الجوال، وهذا ما رآه المؤسس عندما وصل تحويله لمورد الأجهزة خلال دقائق. وتفاصيل حدود سريع ومعرفاته ومدى وسداد ورسائلها لها مقال مستقل في هذه السلسلة، ولن نكررها هنا.

### مواعيد القطع وأيام العمل

بقي سؤال من قصة المؤسس: لماذا لم تظهر مدفوعات الخميس في حساب الشركة إلا يوم الثلاثاء؟ والإجابة في مفهومين يحكمان أغلب أنظمة التسوية بين البنوك: يوم العمل Business Day، وموعد القطع Cut-off Time. فلكل نظام ساعات تشغيل، وكل دفعة تصل بعد موعد القطع تدخل في دورة اليوم التالي، وأيام العطل لا تحسب في أنظمة كثيرة، بينما أنظمة الدفع الفوري تعمل على مدار الساعة طوال الأسبوع كما تذكر صفحة سريع. ثم فوق مواعيد الأنظمة تأتي مواعيد كل طرف في الطريق: متى يرسل مزود الدفع ملف التسوية، ومتى يحول، ومتى يضيف بنكك المبلغ لحسابك. وكل هذه المواعيد يحددها النظام والعقد، فاكتبها في جدول واحد لمنتجك من مصادرها، وراجعها عندما تتغير، ولا تبن على ما «يحدث عادة».

## ماذا يعني ذلك لمنتجك؟

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

- **حالات الدفع ليست كلمة واحدة:** بدلاً من «مدفوع» أصبح للدفعة في النظام حالات: مفوضة Authorised، ومحصلة Captured، ومسواة Settled كما يذكرها ملف التسوية من المزود، ومحولة Paid Out عندما تصل إلى حساب الشركة. والخدمة للعميل تبدأ بعد التفويض، لأن هذا قرار أعمال مقبول للاشتراك الشهري، ولكن التقارير المالية لا تحسب المال إلا بعد التسوية.
- **اقرأ جدول التسوية في عقد المزود:** متى يحول المزود، وكيف يحسب الصافي، وماذا يخصم، ومتى يحجز جزءاً احتياطياً. وهذه الأرقام تختلف بين المزودين والعقود، ولا توجد قاعدة عامة لها، فلا تبن خطة السيولة على افتراض.
- **مطابقة يومية:** كل تحويل يصل إلى حساب الشركة يطابق آلياً مع ملف التسوية من المزود، وكل سطر في الملف يطابق مع عمليات النظام، والفرق في أي منها تنبيه وليس ملاحظة في آخر الشهر. وقد بنينا هذه المطابقة بالكود في [مختبر مقال المحفظة الرقمية](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/#lab-recon).
- **التحويلات الصادرة:** اختر القناة بحسب المبلغ والاستعجال، فالتحويل الفوري للمبالغ الصغيرة يصل في دقائق، والمبالغ الكبيرة تمر في نظام التسوية الإجمالية بقواعده ومواعيده، وكل ذلك يحدده بنكك، فاسأله عن مواعيد قطع العمليات Cut-off لكل قناة.
- **الاسترداد والاعتراض جزء من المسار:** المال الذي سوي قد يعود في استرداد يطلبه العميل أو اعتراض Chargeback يرفعه عبر بنكه، فاحسب في خطة السيولة أن جزءاً مما وصلك قد يخصم لاحقاً، واجعل لكل استرداد سجلاً يربطه بالدفعة الأصلية في دفتر قيودك، وتفاصيل الاعتراضات في مقال مسار الدفع بالبطاقة.
- **كل عملية آمنة عند التكرار:** لأن الرسائل بين الأطراف قد تتكرر أو تتأخر، فكل إشعار من المزود يعالج مرة واحدة بمفتاح فريد، كما شرحنا في [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/).
- **الترخيص:** إذا كانت منصتك تحتفظ بأموال العملاء أو تحولها للغير، فهذا نشاط مدفوعات منظم في المملكة، وقد ذكرنا أنواع التراخيص ومصادرها في [فقرة التنظيم](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/#regulation) في مقال المحفظة، وراجع [نظام المدفوعات وخدماتها](https://rulebook.sama.gov.sa/en/law-payments-and-payment-services?ref=arabroot.io) مع مستشار قبل أن تبني.

## أخطاء شائعة عند المهندسين

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

## قائمة تحقق قبل أن تقبل أول ريال

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

## الخلاصة

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

- كل دفعة تمر بثلاث مراحل: أمر الدفع، والمقاصة التي تحسب، والتسوية التي تنقل نهائياً، و«مدفوع» في لوحة التحكم تعني غالباً التفويض فقط.
- العملاء يتعاملون بنقود البنوك التجارية، والبنوك تسوي فيما بينها بنقود البنك المركزي في حساباتها لديه.
- التسوية الإجمالية الفورية RTGS تعطي النهائية فوراً بثمن السيولة، والتسوية الصافية المؤجلة DNS توفر السيولة بثمن الخطر حتى لحظة التسوية، وفي المختبر انخفضت السيولة المطلوبة من 166.4 مليون إلى 3.42 مليون ريال بالتقاص المتعدد.
- عجز بنك واحد قبل التسوية الصافية ينقل العجز إلى غيره، كما رأينا مع البنك د، ولهذا جاءت قواعد النهائية والضمانات، وقصة Herstatt سنة 1974 هي المثال الأشهر.
- في المملكة SARIE هو نظام التسوية الإجمالية الفورية، وتمر فيه مدفوعات بين البنوك متوسطها حوالي 40 مليون ريال لكل عملية في 2023، وتنتهي إليه تسوية الأنظمة الأخرى.
- لمنتجك: حالات دفع منفصلة، وعقد مزود مقروء، ومبالغ بالهللة، ومطابقة يومية، وقرار واع في كل مكان تحمل فيه خطر تسوية.

وبقية مقالات قسم التقنية المالية والمدفوعات، والمقال الأقرب إلى هذا الموضوع على الموقع:

[![](https://arabroot.io/content/images/2026/10/saudi-payments-cover-cover.webp)دليلمنظومة المدفوعات في السعودية: سريع وSARIE ومدى وسدادالأنظمة الوطنية للمدفوعات في المملكة كما تصفها مصادر البنك المركزي، وما يعنيه كل نظام للمطور، مع تحليل تقارير نقاط البيع الأسبوعية.](https://arabroot.io/articles/%D9%85%D9%86%D8%B8%D9%88%D9%85%D8%A9-%D8%A7%D9%84%D9%85%D8%AF%D9%81%D9%88%D8%B9%D8%A7%D8%AA-%D9%81%D9%8A-%D8%A7%D9%84%D8%B3%D8%B9%D9%88%D8%AF%D9%8A%D8%A9-%D8%B3%D8%B1%D9%8A%D8%B9-%D9%88-sarie-%D9%88-%D9%85%D8%AF%D9%89-%D9%88-%D8%B3%D8%AF%D8%A7%D8%AF/)[![](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/)[![](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/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/idempotency-cover-cover.webp)دليل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/)

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

- أكتوبر 2026: كتابة المقال، وتشغيل محاكاة التسوية على Python 3.13.3، والتحقق من صفحات البنك المركزي السعودي ودليل قواعده والتقرير السنوي الستين ومسرد CPMI ومراجعة BIS الفصلية (يونيو 2026) بتاريخ 27 أكتوبر 2026.