05 Sep PSD2 y RTS: implicaciones prácticas de las nuevas aclaraciones de la EBA
En agosto de 2025, la Autoridad Bancaria Europea (EBA) publicó un conjunto de preguntas y respuestas (Q&A) destinadas a aclarar la aplicación práctica de la Directiva de Servicios de Pago 2 (PSD2) y del Reglamento Delegado (UE) 2018/389, más conocido como RTS sobre autenticación fuerte del cliente (SCA) y comunicación segura (CSC). Estas nuevas interpretaciones tienen un impacto directo en la forma en la que bancos, grandes corporaciones y proveedores de servicios de pago (TPPs) implementan mecanismos de autenticación, gestionan el acceso a la información financiera y regulan la interacción con terceros en el marco del open banking.
Las aclaraciones se centran en tres cuestiones muy concretas que habían generado debate en los últimos años: el rol que juegan los API keys dentro de los factores de autenticación, la validez de las denominadas proxy matrices o matrices de poderes corporativas, y la posibilidad de que las entidades financieras impongan identificadores adicionales a los iniciadores de pagos (PISPs) para acceder al estado de las transacciones.
El API key como factor de conocimiento en la autenticación fuerte
Un API key es, en esencia, un identificador único que permite a una aplicación comunicarse con otra y acceder a determinados servicios. Funciona como una “contraseña técnica”, diseñada para entornos de integración y automatización, más que para un uso humano directo. En el marco de la PSD2 surgía la duda de si un API key podía considerarse un factor válido de conocimiento dentro de la autenticación fuerte. La EBA aclara que sí es posible, pero solo bajo condiciones estrictas: debe tratarse de un dato confidencial que solo conozca el usuario, debe estar protegido contra accesos no autorizados y debe estar inequívocamente asociado al usuario del servicio de pago (PSU). Esto implica que la gestión de API keys debe realizarse con medidas técnicas sólidas, como el almacenamiento seguro en HSMs o bases de datos cifradas, garantizando que el sistema no pueda recuperar el valor en claro.
La EBA recuerda, sin embargo, que no todo identificador puede elevarse a la categoría de factor de conocimiento. Un User ID, por ejemplo, no cumple los requisitos de confidencialidad. Además, la combinación de un API key con un OTP podría no respetar el principio de independencia entre factores exigido por el RTS, lo que obliga a las entidades a revisar cuidadosamente cómo diseñan sus esquemas de SCA.
Las proxy matrices como herramienta de control en empresas
En el ámbito corporativo, la gestión de accesos a cuentas bancarias y operaciones de pago es un reto complejo. Empresas con múltiples cuentas, en distintas divisas y con cientos de empleados necesitan mecanismos de control que definan quién puede autorizar qué tipo de operación, bajo qué condiciones y con qué límites. Para ello utilizan las llamadas proxy matrices, que son estructuras de poderes y autorizaciones que permiten segmentar el acceso y reducir riesgos de fraude o abuso.
Con la apertura del open banking, muchas compañías han reclamado que esas mismas reglas también se apliquen al acceso a través de terceros proveedores (TPPs). La EBA aclara que esta práctica es totalmente válida: los bancos pueden implementar las matrices de poderes que sus clientes corporativos definan, siempre que dichas reglas sean las mismas que se aplican en sus canales propios. Lo que no está permitido es que la entidad financiera introduzca restricciones adicionales en el canal PSD2 que no existan en su banca directa, pues esto supondría un obstáculo indebido al libre acceso garantizado por la Directiva. En definitiva, los clientes deben encontrar las mismas condiciones de autorización independientemente de si acceden por el canal del banco o a través de un TPP autorizado.
El acceso de los PISPs al estado de los pagos
El tercer punto de aclaración se refiere a la información que los bancos deben proporcionar a los iniciadores de pagos (PISPs) sobre el estado de las transacciones. PSD2 establece que los PISPs deben recibir el mismo nivel de información que el propio usuario cuando opera directamente en el canal del banco. Esto incluye el estado de ejecución del pago, sin retrasos ni limitaciones artificiales.
Algunas entidades habían intentado imponer requisitos adicionales, como el uso de identificadores extra o “user tokens” específicos, lo que dificultaba a los PISPs acceder de manera fluida a los datos. La EBA ha sido tajante en este punto: no es aceptable condicionar el acceso a la información básica obligatoria mediante la imposición de identificadores adicionales no contemplados en la regulación. Eso sí, se admite que, si un banco decide ofrecer información adicional más allá de la exigida por la Directiva, pueda establecer condiciones técnicas para acceder a esa información extra, siempre que ello no limite la entrega de la información mínima obligatoria.
Recomendaciones prácticas para el cumplimiento
A la luz de estas aclaraciones, tanto entidades financieras como TPPs deben reforzar sus políticas y procedimientos internos para garantizar el cumplimiento. Algunas recomendaciones clave son las siguientes:
-
Verificar que los factores de autenticación cumplen de forma estricta con los artículos 6, 9 y 24 del RTS.
-
Gestionar los API keys de forma segura, asegurando su confidencialidad y evitando que sean recuperables por el sistema.
-
Documentar las matrices de poderes corporativas y garantizar que se aplican de forma coherente en todos los canales.
-
Asegurar que el acceso a través de TPPs no introduce obstáculos adicionales frente al acceso directo.
-
Revisar que la información proporcionada a los PISPs es equivalente a la del canal bancario, evitando la imposición de identificadores adicionales en los casos básicos.
-
Aplicar controles de trazabilidad y seguridad que garanticen la integridad y transparencia de las operaciones en cualquier canal.
Con estas aclaraciones, la EBA pretende dar mayor seguridad jurídica y operativa a todas las partes implicadas en el ecosistema PSD2. Las entidades que adapten sus procesos de forma proactiva no solo minimizarán riesgos regulatorios, sino que también podrán ofrecer experiencias de usuario más seguras y fluidas, consolidando la confianza en el open banking europeo.