المصرفية المفتوحة Open Banking: إطار البنك المركزي والواجهات

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

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

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

• ما المصرفية المفتوحة، والمشكلة التي تحلها، والخدمتان الأساسيتان: معلومات الحساب AIS وبدء الدفع PIS.
• إطار البنك المركزي السعودي وإصداراته، والمراحل المنشورة حتى سبتمبر 2026.
• الأطراف والتزاماتها كما يذكرها الباب الثامن من اللائحة التنفيذية لنظام المدفوعات وخدماتها.
• الموافقة Consent من الطلب إلى السحب، ولماذا هي قلب النظام كله.
• كيف تبدو الواجهات APIs من الناحية التقنية بشكل عام، وما يجب أن يحميه التطبيق.
• مختبر الموافقات في Python، وماذا يحدث إذا سحبت الموافقة ونسي الكود الحذف.
• ماذا تبني الشركة الناشئة، والترخيص، والأخطاء الشائعة، وقائمة تحقق.

ما المشكلة التي تحلها المصرفية المفتوحة؟

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

والمصرفية المفتوحة تستبدل الطريقتين بواجهات APIs يقدمها البنك وفق معايير موحدة، والعميل يوافق في بنكه على نطاق محدد ومدة محددة، والتطبيق يستلم توكن يعمل لهذا النطاق فقط، والبنك يعرف من يقرأ وماذا يقرأ، والعميل يرى موافقاته ويسحبها. وفي المملكة يذكر إعلان البنك المركزي في 9 فبراير 2024 أن إطار المصرفية المفتوحة مجموعة من الإرشادات والمعايير التقنية مبنية على أفضل الممارسات الدولية، وأن برنامج المصرفية المفتوحة من مبادرات استراتيجية التقنية المالية الوطنية، إحدى ركائز برنامج تطوير القطاع المالي ضمن رؤية المملكة 2030، وأن مجلس الوزراء أقر الاستراتيجية في 2022.

لماذا تفتح البنوك بياناتها لغيرها؟

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

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

خدمتان أساسيتان: معلومات الحساب وبدء الدفع

الصورة التالية تبين الخدمتين اللتين يقوم عليهما الإطار:

• خدمة معلومات الحساب Account Information Service واختصاراً AIS: تطبيق طرف ثالث يقرأ بموافقة العميل بيانات حسابه، مثل الحسابات والأرصدة والعمليات، ويستخدمها في خدمة يقدمها له: تجميع حساباته من عدة بنوك في شاشة واحدة، أو التحقق من دخله قبل تمويل أو تقسيط، أو تصنيف مصاريفه، أو ربط حساب منشأته بنظامها المحاسبي.
• خدمة بدء الدفع Payment Initiation Service واختصاراً PIS: تطبيق طرف ثالث يبدأ بموافقة العميل أمر دفع من حسابه البنكي إلى مستفيد، فيدفع العميل من حسابه داخل تطبيق التاجر دون بطاقة ودون أن ينتقل إلى تطبيق بنكه ليكتب الحوالة يدوياً.

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

المصرفية المفتوحة في المملكة: أين وصلت؟

من المصادر المنشورة يمكن أن نرسم الصورة التالية للمراحل، مع ملاحظة أن التواريخ هي تواريخ الإعلانات والتقارير لا بالضرورة تواريخ التفعيل لكل بنك:

• 2023: يذكر التقرير السنوي الستون للبنك المركزي من إنجازات تلك السنة إطلاق مختبر المصرفية المفتوحة Open Banking Lab، وهو منصة تقدم للبنوك وشركات التقنية المالية بيئة اختبار تقنية تتأكد فيها من توافقها مع الإطار والمعايير، وإطلاق المركز التعاوني للمصرفية المفتوحة لتسهيل إجراءات الموافقات والاستفسارات والتقارير والشكاوى، وتفعيل خدمات معلومات الحساب بعد أن تكمل البنوك وشركات التقنية المالية الإجراءات اللازمة، والتصريح لعدد من شركات التقنية المالية بالمشاركة في المصرفية المفتوحة ضمن البيئة التجريبية التشريعية. ويذكر التقرير أيضاً أن البنوك المحلية أكملت إجراءات الترخيص التقني وتوافقت مع الإطار ومعاييره التقنية لخدمة معلومات حساب الدفع.
• 9 فبراير 2024: الإصدار الثاني من الإطار لبدء الدفع، كما في الإعلان المذكور.
• سبتمبر 2026: في كلمة محافظ البنك المركزي في مؤتمر Money20/20 الشرق الأوسط (15 سبتمبر 2026) أن الخدمات المصرفية المفتوحة انتقلت من البيئة التجريبية التشريعية إلى مرحلة الترخيص، وأن عدد مستخدميها النشطين يزيد على 337 ألف مستخدم. وفي لقاء المصرفية المفتوحة مع البنوك في 16 سبتمبر 2026 تركزت النقاشات على أولويات المرحلة القادمة، ومنها جاهزية البنوك لتفعيل خدمات إنشاء المدفوعات، وتوسيع استفادة الشركات من خدمات المصرفية المفتوحة.

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

الأطراف والتزاماتها في اللائحة

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

وأهم ما في المواد للمطور، بصياغتنا المختصرة لنصها الإنجليزي في الدليل:

• المادة 95: على مقدمي خدمات الدفع إتاحة الوصول إلى خدمات الدفع ذات الصلة وفق تعليمات البنك المركزي للمصرفية المفتوحة والأمن السيبراني وخصوصية البيانات.
• المادة 96: على مقدم خدمة الحساب، أي البنك الذي يحتفظ بحساب العميل، أن يمنح مقدم خدمة بدء الدفع ومقدم خدمة معلومات الحساب الوصول بشرط موافقة المستخدم، وله أن يرفض الوصول لأسباب مبررة تتعلق بالاحتيال أو الوصول غير المصرح به.
• المادة 97: على مقدم خدمة بدء الدفع الحصول على موافقة المستخدم قبل تقديم خدمته.
• المادة 99: على مقدم خدمة معلومات الحساب الحصول على موافقة المستخدم قبل تقديم خدمته، وحذف بيانات المستخدم عند سحب الموافقة أو إلغائها، مع مراعاة الالتزامات النظامية الأخرى.
• المادة 100: للمقدم الذي يصدر أدوات دفع قائمة على البطاقات أن يطلب من مقدم الحساب تأكيد توفر الأموال، بشرط موافقة الدافع.

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

الموافقة Consent: قلب النظام

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

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

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

كيف تصمم شاشة الموافقة؟

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

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

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

كيف تبدو الواجهات من الناحية التقنية؟

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

• التفويض بنمط OAuth 2.0 وOpenID Connect: العميل يحول إلى بنكه ليوافق، ثم يعود بكود يستبدله التطبيق بتوكن، كما شرحنا في شرح OAuth وOpenID Connect للمبتدئين، ومع إضافات أمنية تفرضها معايير القطاع المالي عادة، مثل ربط التوكن بشهادة العميل التقنية وتوقيع الطلبات.
• موارد واضحة: الحسابات، والأرصدة، والعمليات، والموافقات نفسها، وأوامر الدفع، ولكل منها نقطة في ال API ونطاق في الموافقة.
• هوية الطرف الثالث: لا يتصل بالبنك إلا مقدم مسجل ومصرح له، يعرف نفسه بشهادة رقمية، والبنك يعرف من يطلب كل بيان.
• السجلات والمراقبة: كل طلب يسجل عند البنك وعند المقدم، لأن الطرفين مسؤولان أمام العميل والجهة المنظمة.

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

التوكنات: الحفظ والتجديد والإلغاء

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

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

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

# consent.py: an account-information app that may only read what the user consented to, and forgets on withdrawal
import sys
from datetime import date, timedelta
from collections import defaultdict

# synthetic data held by two banks (amounts in halalas); nothing here is a real account
BANK_DATA = {
    "bank_x": {"balances": {"SA-X-001": 1_250_000},
               "transactions": [("2026-09-27", "SALARY", 1_800_000), ("2026-09-28", "RENT", -600_000),
                                ("2026-10-02", "GROCERIES", -42_150), ("2026-10-05", "GYM APP", -9_900),
                                ("2026-10-27", "SALARY", 1_800_000)]},
    "bank_y": {"balances": {"SA-Y-777": 310_000},
               "transactions": [("2026-10-01", "TRANSFER IN", 150_000), ("2026-10-09", "FUEL", -18_000)]},
}

consents, store, audit = {}, defaultdict(list), []
today = date(2026, 10, 27)

def grant(cid, user, bank, scopes, days):
    consents[cid] = {"user": user, "bank": bank, "scopes": set(scopes), "expires": today + timedelta(days=days), "status": "active"}
    audit.append((str(today), cid, "granted", ",".join(sorted(scopes))))

def read(cid, scope, on=None):
    on = on or today
    c = consents.get(cid)
    reason = ("no consent" if c is None else
              "withdrawn" if c["status"] != "active" else
              "expired" if on > c["expires"] else
              "scope not granted" if scope not in c["scopes"] else None)
    audit.append((str(on), cid, f"read {scope}", reason or "ok"))
    if reason:
        return None, reason
    data = BANK_DATA[c["bank"]][scope]
    store[cid].append((scope, data))            # what the app keeps because of this consent
    return data, "ok"

def withdraw(cid):
    consents[cid]["status"] = "withdrawn"
    if "--forget-to-delete" in sys.argv:        # the bug: access stops, but the copied data stays
        deleted = 0
    else:
        deleted = len(store.pop(cid, []))       # delete what was collected under this consent
    audit.append((str(today), cid, "withdrawn", f"deleted {deleted} records"))

# 1. the user lets the app read transactions at bank_x for 90 days (our product choice, not a rule)
grant("c1", "u1", "bank_x", ["transactions"], 90)
tx, status = read("c1", "transactions")
income = sum(a for _, _, a in tx if a > 0)
spend = -sum(a for _, _, a in tx if a < 0)
print(f"c1 transactions: {status}, {len(tx)} rows, income {income/100:,.2f} SAR, spending {spend/100:,.2f} SAR")

# 2. the app tries to read balances, which the user did not grant
_, status = read("c1", "balances")
print("c1 balances:", status)

# 3. a second consent at bank_y, read, then the user withdraws it
grant("c2", "u1", "bank_y", ["transactions", "balances"], 30)
read("c2", "balances"); read("c2", "transactions")
print("c2 records kept before withdrawal:", len(store["c2"]))
withdraw("c2")
_, status = read("c2", "balances")
print("c2 after withdrawal:", status, "| records kept:", len(store.get("c2", [])))

# 4. the same c1 consent, 91 days later
_, status = read("c1", "transactions", on=today + timedelta(days=91))
print("c1 after 91 days:", status)

print("\naudit trail:")
for row in audit:
    print("  " + " | ".join(row))

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

c1 transactions: ok, 5 rows, income 36,000.00 SAR, spending 6,520.50 SAR
c1 balances: scope not granted
c2 records kept before withdrawal: 2
c2 after withdrawal: withdrawn | records kept: 0
c1 after 91 days: expired

audit trail:
  2026-10-27 | c1 | granted | transactions
  2026-10-27 | c1 | read transactions | ok
  2026-10-27 | c1 | read balances | scope not granted
  2026-10-27 | c2 | granted | balances,transactions
  2026-10-27 | c2 | read balances | ok
  2026-10-27 | c2 | read transactions | ok
  2026-10-27 | c2 | withdrawn | deleted 2 records
  2026-10-27 | c2 | read balances | withdrawn
  2027-01-26 | c1 | read transactions | expired

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

• الموافقة c1 تمنح نطاق transactions فقط في bank_x، فقرأ التطبيق خمس عمليات، وحسب منها الدخل 36,000 ريال (راتبان في 27 سبتمبر و27 أكتوبر) والمصروف 6,520.50 ريالاً. وهذا ما يحتاجه الفريق للتحقق من قدرة العضو على التقسيط، دون أن يرى رصيده أو حساباته في بنك آخر.
• عندما حاول التطبيق قراءة الأرصدة بنفس الموافقة جاء الرد scope not granted، والسبب أن النطاق غير ممنوح، وهذا الرفض يحدث في كودنا قبل أن يصل الطلب إلى أي بنك، لأن التطبيق الذي يعتمد على رفض البنك وحده سيرسل طلبات لا يحق له إرسالها، وتسجل عليه عند البنك.
• الموافقة c2 منحت نطاقين، فقرأ التطبيق سجلين، ثم سحبها العميل، فتوقف الوصول (withdrawn) وحذف السجلان، والمخرج يقول records kept: 0، وسجل التدقيق يقول deleted 2 records، وهذا تطبيق لما تطلبه المادة 99 من حذف البيانات عند سحب الموافقة.
• القراءة بالموافقة c1 بعد 91 يوماً رفضت بسبب expired، لأن مدتها 90 يوماً، والتاريخ في سجل التدقيق 2027-01-26 هو التاريخ المحاكى للطلب.
• سجل التدقيق Audit Trail يحفظ كل منح وقراءة ورفض وسحب، بالتاريخ والموافقة والنتيجة، وهو ما ستحتاجه عندما يسأل عميل «من قرأ بياناتي ومتى؟» أو تسأل جهة رقابية. وقد شرحنا بناء سجل تدقيق لا يقبل العبث في Audit Trail: كيف تبني سجل تدقيق لا يقبل العبث.

والصورة التالية تلخص الحالات الأربع:

ماذا لو أوقف السحب الوصول ونسي الحذف؟

أكثر خطأ يحدث في هذا النوع من الأنظمة ليس أن يقرأ التطبيق بعد السحب، فهذا يمنعه البنك، وإنما أن يتوقف التطبيق عن القراءة ويبقي ما قرأه قبل ذلك في جداوله وتقاريره. والخيار --forget-to-delete في الكود يحاكي هذا الخطأ: الدالة withdraw تغير حالة الموافقة ولا تحذف شيئاً. ونقارن المخرجين بالأمر diff:

python consent.py > o1.txt
python consent.py --forget-to-delete > o2.txt
diff o1.txt o2.txt

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

4c4
< c2 after withdrawal: withdrawn | records kept: 0
---
> c2 after withdrawal: withdrawn | records kept: 2
14c14
<   2026-10-27 | c2 | withdrawn | deleted 2 records
---
>   2026-10-27 | c2 | withdrawn | deleted 0 records

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

من المختبر إلى قاعدة البيانات

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

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

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

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

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

بدء الدفع مقابل البطاقة: ما الذي يتغير؟

عندما فكر الفريق في «الدفع من حسابي» للاشتراك السنوي، قارنه بما يعرفه من البطاقات، فوجد أن الاختلاف أكبر من مجرد وسيلة دفع أخرى:

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

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

تأكيد توفر الأموال

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

من العمليات إلى قرار: التحقق من الدخل

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

اختبار الميزة قبل الإطلاق

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

الترخيص: من يحق له تقديم الخدمة؟

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

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

ما الذي لا تفعله بالبيانات؟

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

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

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

على الجهة الأخرى: ماذا يبني البنك؟

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

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

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

كيف تعرف أن الميزة نجحت؟

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

أخطاء شائعة

قائمة تحقق قبل أن تطلب أول موافقة

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

الخلاصة

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

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

وفي مقالات قادمة بإذن الله في هذا القسم سوف نتناول رسائل البنوك بمعياري ISO 8583 وISO 20022، وبوابات الدفع، وأمن المدفوعات وPCI DSS، وكشف الاحتيال، والمطابقة بين كشف البنك ونظامك، وكلها تبني على الموافقة والأحداث والمطابقة التي رأيناها هنا.

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

دليلكيف تنتقل الأموال بين البنوك؟ المقاصة Clearing والتسويةماذا يحدث بين ضغطة «ادفع» ووصول المال: الدفع والمقاصة والتسوية الإجمالية والصافية، مع محاكاة يوم من التسويات بين ستة بنوك.دليلمنظومة المدفوعات في السعودية: سريع وSARIE ومدى وسدادالأنظمة الوطنية للمدفوعات في المملكة كما تصفها مصادر البنك المركزي، وما يعنيه كل نظام للمطور، مع تحليل تقارير نقاط البيع الأسبوعية.دليلكيف يعمل الدفع بالبطاقة؟ التفويض Authorization والتسويةمن ضغطة «ادفع» إلى آخر اعتراض: التفويض و3D Secure والتحصيل والتسوية والاسترداد والاعتراض، مع مختبر لأحداث مزود الدفع ومطابقتها.دليلالمحفظة الرقمية من الداخل: دفتر القيد المزدوج Ledgerكيف تبني محفظة رقمية لا يضيع فيها ريال ولا يخصم مرتين، بالقيد المزدوج والمعاملات والمطابقة مع مزود الدفع.

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

• أكتوبر 2026: كتابة المقال، وتشغيل مختبر الموافقات على Python 3.13.3 ببيانات اختبار، والتحقق من إعلان البنك المركزي (9 فبراير 2024) والباب الثامن من اللائحة التنفيذية لنظام المدفوعات وخدماتها في دليل القواعد والتقرير السنوي الستين وكلمة المحافظ ولقاء المصرفية المفتوحة (سبتمبر 2026) بتاريخ 27 أكتوبر 2026.