خارطة الفنتك

الجزء 04 · قنوات الدفع Payment rails

المصرفية المفتوحة Open BankingOpen Banking

حقّك القانوني في السماح لتطبيق آخر بقراءة بياناتك المصرفية أو تنفيذ دفعة نيابة عنك، دون تسليمه كلمة مرور بنكك.

قراءة 8 دقائق

شارك المقال:

المصرفية المفتوحة أن تسمح لتطبيق بقراءة بيانات حسابك في بنكك، بإذنك أنت، وبلا إعطائه كلمة مرورك.

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

وقيمة مفتاح الضيف ليست في شكله، بل في الأبواب التي يعجز عن فتحها.

ليش ما أعطي التطبيق كلمة مرور بنكي وخلاص؟

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

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

وفكّر فيما يعنيه هذا. فالتطبيق يملك مفاتيح بيتك كاملة. ولا يستطيع البنك التمييز بينك وبين التطبيق، لأن الدخول تمّ باسمك. فلو أراد التطبيق تحويل مالك، لاستطاع. ولو سُرّبت قاعدة بياناته، لسُرّبت كلمات مرور آلاف الحسابات معها. ولو أنكرت عملية، لقال البنك إنها تمّت بمفتاحك.

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

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

الباب القديم كان كلمة المرور

وقبل بناء مدخل نظامي، استعملت تطبيقات أسلوباً يسمى «كشط الشاشة» Screen scraping. فكان التطبيق يطلب اسم دخولك المصرفي وكلمة مرورك. ثم يدخل إلى موقع البنك متظاهراً بأنه أنت، ويقرأ الأرقام المصممة لشاشة بشرية. وقد يكرر الدخول كل ليلة لجلب معاملات جديدة.

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

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

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

واجهة تطلب ولا تتنكر

Loading diagram…

مسار الموافقة في المصرفية المفتوحة

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

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

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

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

القراءة ليست حركة مال

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

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

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

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

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

رحلة الموافقة هي المنتج

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

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

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

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

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

الثقة تحتاج سجلاً قابلاً للتتبع

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

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

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

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

المصرفية المفتوحة في السعودية

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

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

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

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

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

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

كلمات جديدة هنا

واجهة برمجيةAPI
طريقة محدّدة يطلب بها برنامج شيئاً من برنامج آخر. وهي المدخل الذي بُنيت عليه المصرفية المفتوحة.
التفويضConsent
إذنك الصريح لتطبيق محدّد بالوصول إلى بيانات محدّدة لمدة محدّدة.
كشط الشاشةScreen scraping
الأسلوب القديم السيئ: يدخل التطبيق إلى بنكك بصفتك مستخدماً كلمة مرورك. ووُجدت المصرفية المفتوحة للقضاء عليه.

الخلاصة

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

اختبر فهمك

أجب قبل أن تقرأ التفسير. والخطأ هنا أنفع لك من تخمين صحيح.

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

المصادر الرسمية

للتحقّق بنفسك من القواعد المذكورة أعلاه. والمقال مكتمل بدونها.

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

العودة إلى الخارطة

المصرفية المفتوحة Open Banking | Roadmap FinTech