جاهزية PSD3 ليست مشكلة المستقبل. إنها مشكلة الحاضر.

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

جزء من المشكلة هو الاعتقاد أن PSD3 هو في الأساس PSD2 مع بعض الطبقات الإضافية - نوع من PSD2.0. ليس الأمر كذلك. الحزمة الجديدة - التوجيه الثالث للخدمات الدفعية واللوائح ذات الصلة بالخدمات الدفعية (PSR) - ترفع المعايير فيما يتعلق بكيفية إدارة الأذونات، وكيفية إثبات المصادقة، وكيفية إدارة وصول الأطراف الثالثة.

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

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

حيث لا تزال البنوك معرضة للخطر

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

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

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

المؤسسات التي عززت هذه الأسس بعد PSD2، تتكيف الآن مع PSD3 بأقل قدر من الاضطراب. أما تلك التي تركت بنائها على PSD2 دون تغيير، فهي الآن تواجه تحديًا أكبر.

ما تركه PSD2 وراءه

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

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

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

العمل الذي تم تحت PSD2 هو الآن من يحدد مدى اضطراب PSD3.

القرارات التي لا يمكن تأجيلها

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

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

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

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

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