En la era del Open Banking, la confianza no se basa solo en mecanismos criptográficos. Estos incluyen la transmisión segura de datos mediante cifrado, la garantía de la integridad de la información transmitida, la autenticación mediante firmas digitales y la protección de la confidencialidad. Lo más importante es que la confianza depende de la disponibilidad de datos regulatorios actualizados y fiables. Los mecanismos criptográficos, como los Qualified Web Authentication Certificates (QWAC) o los Qualified Electronic Seal Certificates (QSealCs), establecen una conexión técnica segura y confirman la identidad de un proveedor externo, pero no indican si dicho proveedor sigue estando legalmente autorizado para ofrecer determinados servicios.
Un riesgo que a menudo se pasa por alto
Esto supone un riesgo regulatorio significativo: un certificado puede seguir siendo válido formalmente, incluso aunque el proveedor externo ya no esté autorizado para prestar servicios de pago. Por ejemplo, un TPP puede haber perdido su licencia, ya sea tras una revocación de la autoridad supervisora o una renuncia voluntaria. También es posible que se le hayan retirado funciones específicas, como la de proveedor de servicios de iniciación de pagos (PISP), lo que significa que ya no podrá iniciar pagos en nombre de los clientes finales. Otra cosa que a menudo se pasa por alto es cuando un TPP posee una licencia válida en su país de origen, pero no la ha ampliado al país de destino mediante el procedimiento de pasaporte, por lo que carece de derecho legal para operar en esa jurisdicción.
Todos estos casos tienen algo en común: el acceso del TPP parece legítimo desde una perspectiva técnica, pero no lo es desde una perspectiva regulatoria. No examinar esto con atención puede abrir la puerta a accesos no autorizados, generar riesgos de responsabilidad y conducir a infracciones de los requisitos de la PSD2.
Riesgo regulatorio: ¿qué está en juego con las comprobaciones incompletas?
Un ejemplo concreto: los datos de los clientes podrían compartirse involuntariamente con un TPP cuya licencia ha sido revocada, quizás debido a infracciones regulatorias o porque el proveedor ha cesado sus operaciones. También existe el riesgo de procesar una transacción de pago iniciada por un proveedor que ya no desempeña la función de PISP y, por lo tanto, no está autorizado a ejecutar órdenes de pago. Es especialmente grave que un TPP regulado en un país de la UE obtenga acceso a una interfaz de otro país sin disponer de una autorización de pasaporte válida para la jurisdicción pertinente, puesto que no estaría legalmente autorizado para operar en ese mercado.
Estas situaciones no solo constituyen violaciones del principio de cumplimiento normativo, sino que también pueden tener consecuencias financieras y legales directas. En algunos casos, el proveedor de servicios de pago gestor de cuenta (ASPSP) puede ser responsable de transacciones no autorizadas, por ejemplo, a través de obligaciones de reembolso en virtud del art. 73 de la PSD2. Además, estos incidentes siempre ponen en peligro la confianza del cliente. Si los clientes perciben que una infraestructura de Open Banking no está suficientemente protegida contra los accesos no autorizados, esto podría dañar su reputación a largo plazo. Este riesgo puede evitarse fácilmente con un enfoque de cumplimiento proactivo.
La solución: validación continua y multicapa
En Qwist entendemos que el cumplimiento de la PSD2 requiere más que la validación técnica de un certificado. Por eso, nuestra solución PSD2 API complementa las comprobaciones de certificados tradicionales con una validación inteligente multicapa basada en datos regulatorios actualizados.
En la práctica, esto significa que verificamos en tiempo real si un proveedor externo posee un QWAC o QSealC válido y si está realmente autorizado para desempeñar su función en la jurisdicción específica donde se solicita el acceso. Para lograrlo, nuestra solución se conecta automáticamente al registro de la Autoridad Bancaria Europea (ABE) y a los registros nacionales pertinentes. Allí verificamos:
- Si el TPP está actualmente inscrito en el registro.
- Si cuenta con la autorización correcta para su función (p. ej., AISP, PISP o ambas).
Además, trabajamos continuamente para mejorar la calidad de estas comprobaciones. Un elemento clave es la integración técnica con los Servicios Nacionales Competentes en Autorización (NAC) y otras fuentes descentralizadas. Esto no solo nos permite ampliar la información disponible, sino también aumentar considerablemente su precisión, una ventaja decisiva, sobre todo en casos con matices nacionales específicos o cambios repentinos en las licencias.
Cumplimiento en tiempo real en lugar de comprobaciones estáticas
¿Qué ocurre, en la práctica, si cambia el estatus regulatorio de un TPP? Por ejemplo, ¿si se revoca una licencia o se retira una función?
Incluso si el certificado siga siendo válido, nuestra solución detecta el cambio de inmediato y bloquea el acceso automáticamente en tiempo real. No se requiere ninguna intervención manual ni comprobar listas a diario. Nuestra tecnología garantiza que solo los proveedores verdaderamente autorizados obtengan acceso, según la normativa vigente. Esto ofrece el máximo nivel de seguridad posible, no solo en términos de cifrado, sino también desde una perspectiva legal. Todo esto es crucial para el éxito a largo plazo y la confianza en tu infraestructura de Open Banking.
Qué significa esto para tu negocio
Esta verificación mejorada basada en registros te ayuda a:
- Cumplir con las expectativas regulatorias de diligencia debida, incluso aunque no estén estipuladas explícitamente en las Normas Técnicas de Regulación (RTS).
- Reducir el riesgo de acceso no autorizado y los intentos de fraude.
- Demostrar a clientes y auditores que tu PSD2 API se basa en el cumplimiento normativo en tiempo real y no en una lógica estática.
Conclusión
Para lograr el cumplimiento de la PSD2, tanto en la teoría como en la práctica, necesitas más que certificados válidos: necesitas una verificación continua e inteligente que combine a la perfección la seguridad tecnológica con la conformidad normativa. Si quieres proteger realmente tus interfaces PSD2 y mantener su seguridad, tanto técnica como legal, deberás verificar los certificados y la normativa.
