قبل ربط تطبيقك بالخدمات المصرفية المفتوحة في عُمان: صمّم دورة حياة الموافقة

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

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

ابدأ بتحديد حدود دورك

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

نمذج الموافقة كدورة حياة صغيرة

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

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

اجعل سحب الموافقة حدثاً تشغيلياً

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

حافظ على ضيق حدود الواجهة البرمجية

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

قائمة تنفيذ أولية

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

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

1. 01Open Banking Regulatory Framework — Central Bank of Oman