رؤى · تقرير · القطاعات · مايو 2026
المصادقة القوية للعميل، ونطاقات رموز الوصول، والعناية الواجبة تجاه مجمّعي البيانات، وتوزيع المسؤولية عن الحوادث حين تتسرب البيانات أو تمر مدفوعات خاطئة عبر أطراف ثالثة مرخّصة.
تربط منظومات الخدمات المصرفية المفتوحة البنوك، ومقدّمي الخدمات من الأطراف الثالثة المرخّصين، وتطبيقات التقنية المالية، وأعداداً كبيرة من المستخدمين النهائيين، عبر واجهات برمجة تطبيقات (APIs) موحّدة المعايير ووثائق موافقة قابلة للقراءة آلياً. ورغم سنوات من التطوير التنظيمي في الاتحاد الأوروبي، والمملكة المتحدة، وأستراليا، والبرازيل، والخليج، حيث تتبلور أنظمة مثل «إطار المصرفية المفتوحة» الصادر عن البنك المركزي السعودي (SAMA)، و«نظام التمويل المفتوح» الصادر عن مصرف الإمارات العربية المتحدة المركزي (CBUAE)، لا يزال الغموض قائماً حول الطرف الذي يُعد جهة التحكم في البيانات، والطرف الذي يُعد جهة المعالجة، ومن يتحمّل التكلفة في النهاية حين يكشف حادث أمني معلومات الحسابات أو يتسبب في دفعة خاطئة.
لهذا الغموض تكلفة حقيقية. فقد أعقبت حوادث بارزة في الخدمات المصرفية المفتوحة إجراءات إنفاذ تنظيمية ودعاوى قضائية وأضرار بالسمعة. والمؤسسات المالية التي تتعامل مع إدارة الموافقات كإجراء شكلي لاستيفاء المتطلبات، لا كتخصص هندسي، تعرّض نفسها لمسؤوليات تتراكم وتتضاعف. ويضع هذا التقرير إطاراً منظماً لحوكمة دورة حياة الموافقة، والعناية الواجبة تجاه الأطراف الثالثة، وتوزيع المسؤولية عن الحوادث، صُمّم لتقليل المخاطر القانونية والاحتكاك التشغيلي معاً.
الموافقة في الخدمات المصرفية المفتوحة، في جوهرها، لبنة معمارية أساسية لا مجرد وثيقة قانونية. فكل منح للموافقة يطلق سلسلة من استدعاءات API، وإصدار الرموز، ونقل البيانات، وأحداث التدقيق. وحين تفتقر هذه السلسلة إلى أدوات رصد كافية، تعجز المؤسسات بعد الحادث عن الإجابة عن أسئلة أساسية في التحقيق الجنائي الرقمي: ما البيانات التي خرجت من نطاق الحماية؟ وأي بيانات اعتماد أجازت النقل؟ وهل وافق العميل فعلاً على النطاق الذي استُخدم؟ والتعامل مع الموافقة بوصفها بنية تحتية لا أوراقاً إدارية يغيّر طريقة تصميم الفرق لمنصات API ونشرها ومراقبتها.
تبدأ إدارة دورة حياة الموافقة عند التسجيل. فخلال الانضمام، يتحقق العميل من هويته لدى مقدّم خدمة الدفع الذي يدير حسابه، ويأذن صراحةً بمجموعة محددة من صلاحيات البيانات لمقدّم الخدمة من الطرف الثالث الذي يطلبها. وعلى الفرق الهندسية أن تضمن أن شاشات التسجيل تعرض نطاقات الصلاحيات بلغة واضحة، وتسجّل التوقيت الدقيق للموافقة وقناتها، وتُصدر إيصال موافقة محفوظاً يرجع إليه البنك والطرف الثالث، كلٌّ على حدة. والبيانات الوصفية الناقصة عند التسجيل هي السبب الجذري لمعظم مطالبات الموافقة المتنازع عليها.
تقييد النطاق هو نقطة التحكم الحاسمة الثانية. فينبغي لمقدّمي الخدمات من الأطراف الثالثة أن يطلبوا أضيق مجموعة من بيانات الحسابات وسجلات المعاملات يحتاجها منتجهم فعلاً. وعلى البنوك بدورها أن تفرض تعريفات دقيقة للنطاقات على مستوى بوابة API، بدلاً من الاعتماد على صلاحيات قراءة شاملة. فحين لا يحتاج تطبيق لتجميع بيانات التمويل الشخصي إلا إلى معلومات الرصيد، فإن منحه وصولاً كاملاً إلى تفاصيل المعاملات يخالف مبدأ الحد الأدنى من الصلاحيات، ويوسّع نطاق الأثر لأي اختراق مستقبلي لبيانات الاعتماد.
تختلف فترات تجديد الموافقة وإعادة التفويض اختلافاً كبيراً بين الأنظمة التنظيمية. فتوجيه خدمات الدفع المعدّل (PSD2) في أوروبا يُلزم بإعادة المصادقة كل 180 يوماً لخدمات معلومات الحسابات (بعد أن كانت المدة 90 يوماً حتى 2022)، بينما يسمح نظام حق المستهلك في البيانات في أستراليا بمدد أطول وفق شروط معينة. لذا ينبغي للفرق الهندسية أن تجعل هذه الفترات قيماً قابلة للضبط في ملفات الإعدادات، بدلاً من تثبيت نمط وطني واحد في شيفرة تطبيق عالمي. وتتيح مفاتيح تفعيل الميزات المرتبطة برموز الدول لفرق المنتجات تكييف سلوك التجديد دون إعادة نشر البرمجيات الوسيطة للأنظمة المصرفية الأساسية.
يجب أن يكون إلغاء الموافقة فورياً وقابلاً للتحقق. فحين يسحب العميل موافقته عبر أي قناة، سواء تطبيق البنك على الجوال، أو لوحة معلومات لدى طرف ثالث، أو اتصال بمركز خدمة العملاء، يجب إبطال رموز API المرتبطة بها خلال ثوانٍ لا ساعات. والمؤسسات التي تعتمد على عمليات معالجة مجمّعة ليلية لنشر قرارات الإلغاء تترك فترات يُتاح فيها وصول غير مصرّح به إلى البيانات، وهو ما تعدّه الجهات التنظيمية عدم امتثال جوهرياً. وأصبحت البنى القائمة على الأحداث في الوقت الفعلي، باستخدام خطافات الويب أو طوابير الرسائل، هي المعيار المتوقع اليوم.
وتكتمل دورة الحياة بتصدير سجلات التدقيق. إذ تطلب الجهات التنظيمية، وأمناء المظالم، ولجان تسوية النزاعات على نحو متزايد سجلات موافقة قابلة للقراءة آلياً خلال التحقيقات. وينبغي للبنوك والأطراف الثالثة الاحتفاظ بسجلات تدقيق غير قابلة للتعديل ترصد كل انتقال في حالة الموافقة، وهوية الطرف الذي بادر به، والآلية التقنية المستخدمة. وتصدير هذه السجلات بصيغ معيارية مثل JSON أو CSV، مع بصمات تشفيرية تثبت سلامتها، يسرّع الاستجابة للجهات التنظيمية ويُظهر نضجاً تشغيلياً.
تشكّل المصادقة القوية للعميل ومتطلبات الربط الديناميكي العمود الفقري الأمني لخدمات بدء الدفع في الخدمات المصرفية المفتوحة. فبموجب التوجيه PSD2 والتشريعات التي تخلفه، يجب ربط كل دفعة ربطاً ديناميكياً بالمبلغ والمستفيد المحددين لحظة التفويض. وعلى الفرق الهندسية مقاومة إغراء تخزين رموز المصادقة مؤقتاً أو إعادة استخدامها عبر المعاملات. فكل عملية بدء دفع ينبغي أن تُطلق إجراء مصادقة جديداً يربط موافقة العميل بالتفاصيل الدقيقة لتلك الحوالة بعينها، بما يمنع هجمات إعادة الإرسال والتعديلات غير المصرّح بها على المبالغ.
تمتد العناية الواجبة تجاه مجمّعي البيانات إلى ما هو أبعد بكثير من استبيانات الانضمام الأولية. فينبغي للبنوك أن تعامل مجمّعي البيانات الحيويين معاملة المورّدين الجوهريين الخاضعين لمراقبة مستمرة، وتقييمات أمنية دورية، وتقارير تُرفع إلى مجلس الإدارة عن مخاطر التركّز. وينبغي أن تقيّم برامج العناية الواجبة المتانة المالية لمجمّع البيانات، ووتيرة اختبارات الاختراق لديه، ونضج قدرته على الاستجابة للحوادث، واعتماده على معالجين من الباطن. فمجمّع واحد يمرّر حركة البيانات لعشرات من تطبيقات التقنية المالية يركّز المخاطر النظامية بطرق لم تُصمَّم أطر إدارة المورّدين التقليدية لرصدها.
تستحق الشفافية بشأن المعالجين من الباطن اهتماماً خاصاً. فكثير من مقدّمي الخدمات من الأطراف الثالثة يعتمدون على أطراف رابعة للاستضافة، أو التحليلات، أو تقييم مخاطر الاحتيال، أو التحقق من الهوية. ونادراً ما تكون للبنوك علاقات تعاقدية مباشرة مع هذه الجهات، ومع ذلك قد يكشف اختراق لدى طرف رابع بيانات العملاء ذاتها التي أتاحها البنك أصلاً عبر واجهة API الخاصة به. لذا ينبغي أن تُلزم البنود التعاقدية الأطراف الثالثة بالإفصاح عن جميع المعالجين من الباطن، وإخطار البنك قبل إضافة أي معالج جديد، ونقل التزامات أمنية مكافئة إلى جميع حلقات سلسلة الإمداد.
تقليل البيانات متطلب تنظيمي واستراتيجية عملية لخفض المخاطر في آن واحد. فينبغي لمقدّمي الخدمات من الأطراف الثالثة تطبيق التصفية على مستوى الحقول لحظة استهلاك واجهة API، واستبعاد عناصر البيانات غير الضرورية لحالة الاستخدام المعلنة. ويمكن للبنوك تعزيز هذا الانضباط بتقديم منتجات API متدرّجة تضيق حمولة البيانات فيها تدريجياً. فتطبيق إعداد الميزانية الذي لا يحتاج إلا إلى فئات المعاملات ومبالغها يجب ألا يتلقى أبداً تفاصيل الطرف المقابل كاملة، أو حقول الملاحظات، أو الأرقام المرجعية الداخلية.
يجب أن يرتبط توزيع المسؤولية في عقود الخدمات المصرفية المفتوحة مباشرةً بضوابط تقنية يمكن رصدها. فبنود التعويض العامة التي تحمّل الطرف الثالث كامل المخاطر دون تحديد معايير التسجيل، أو متطلبات التشفير، أو مهل الإبلاغ عن الحوادث، يصعب إنفاذها، وتحويلها إلى ممارسة تشغيلية أصعب. أما العقود الفعالة فتحدد مصفوفات للمسؤولية المشتركة تربط التزامات كل طرف بإشارات قياس محددة: سجلات استخدام الرموز، وأحجام استدعاءات API، ومعدلات الأخطاء، وجداول الاحتفاظ بالبيانات. وحين يقع اختراق، تصبح هذه الإشارات الأساس الإثباتي لتحديد المسؤولية عن الخطأ.
تتطلب الاستجابة للحوادث في منظومات الخدمات المصرفية المفتوحة أدلة إجراءات منسّقة تتجاوز حدود المؤسسة الواحدة. فتعرّض البيانات الذي ينشأ لدى مقدّم خدمة من طرف ثالث ويمس عملاء البنك يستلزم مسارات عمل متوازية: يحقق الطرف الثالث في السبب الجذري ويتولى الاحتواء، بينما يتولى البنك إبلاغ العملاء والإفصاح للجهات التنظيمية. وتقلّص النماذج المتفق عليها مسبقاً للاستجابة المشتركة، وقنوات التواصل المشتركة، وجهات الاتصال المحددة للتصعيد، متوسط الوقت اللازم للوصول إلى إجراء منسّق. أما المؤسسات التي تفتقر إلى هذه الاتفاقات فتنزلق إلى تبادل الاتهامات، فتتضرر كل علامة تجارية في السلسلة.
يُعد التواصل مع العملاء بعد حادث لدى طرف ثالث مسألة شائكة تهدد السمعة. فالعملاء يحمّلون بنكهم المسؤولية عادةً بصرف النظر عن موضع الخلل الفعلي. لذا ينبغي صياغة نماذج الإبلاغ المشتركة خلال مرحلة الانضمام، لا في خضم الأزمة. ويجب أن توضح هذه النماذج ما حدث، والبيانات المتأثرة، وما ينبغي للعميل فعله، وكيف يتعاون الشركاء في المنظومة لمنع التكرار. فالتواصل الشفاف يحفظ الثقة بفاعلية تفوق كثيراً إخلاءات المسؤولية القانونية أو إلقاء اللوم على الآخرين.
توفّر المؤشرات التشغيلية نظام إنذار مبكر يمنع تصاعد نزاعات الموافقة إلى إجراءات تنظيمية. ومن أبرز هذه المؤشرات: حجم الموافقات الممنوحة لكل مقدّم خدمة من طرف ثالث، ومعدلات الإلغاء كنسبة مئوية من الموافقات النشطة، وهامش الأخطاء المسموح لواجهات API مقسّماً حسب نقطة النهاية، ومتوسط الوقت اللازم لتعطيل بيانات اعتماد تطبيق مخترقة، ونسبة نجاح تجديد الموافقات مقارنةً بحالات إخفاقه. ولوحات المعلومات التي تعرض هذه المؤشرات في وقت شبه فعلي تتيح لفرق المخاطر والامتثال رصد الحالات الشاذة قبل أن تتحول إلى حوادث.
وعلى المدى الأبعد، سيزداد مشهد الموافقة في الخدمات المصرفية المفتوحة تعقيداً مع توسيع الجهات الرقابية نطاقها ليشمل التأمين، والمعاشات التقاعدية، وحسابات الاستثمار. فالمدفوعات المتكررة متغيرة القيمة، والتفويضات طويلة الأجل، وتدفقات البيانات عبر الحدود، ستُدخل أنماط موافقة جديدة لا تعالجها الأطر الحالية معالجة كاملة. والمؤسسات التي تستثمر اليوم في بنية موافقة مرنة ومزوّدة بأدوات رصد جيدة ستتكيف أسرع من تلك المقيّدة بتطبيقات جامدة خاصة بدولة بعينها. والميزة التنافسية من نصيب المؤسسات التي تتعامل مع الموافقة بوصفها قدرة من قدرات المنتج، لا عبئاً امتثالياً.
نعرض النتائج في جلسة عمل، ونربط التوصيات بمحفظة مشاريعك وسجل المخاطر لديك، ونساعدك على ترتيب أولويات الخطوات التالية، مع تحديد المسؤول عن كل خطوة وموعدها.
