Para un banco, la PSD2 es el momento en que unos sistemas construidos durante años para operar en cerrado tienen que abrirse de golpe al mundo a través de API. La directiva exige que el banco exponga los datos de cuenta y la iniciación de pagos a terceros autorizados, y el open banking convierte eso, de un deber legal, en un cambio real de arquitectura. Para un chief digital officer, un arquitecto o un director de TI eso significa una cosa: la PSD2 es un proyecto tecnológico, no solo un ejercicio de cumplimiento.
Por nuestra experiencia, lo difícil no es entender la directiva, sino traducirla a API seguras, estables y mantenibles en un entorno donde el core bancario, los sistemas antifraude y las exigencias regulatorias corren a la vez. No tenemos un caso de éxito público en esta área y no vamos a fingir lo contrario. Hacemos otra cosa, y somos fuertes en ella: aportamos a las personas que lo van a construir - ingenieros con experiencia en integraciones bancarias y entrega de plataformas, integrados en tu equipo como refuerzo de equipo o equipo dedicado.
¿Qué son la PSD2 y el open banking, y a qué obligan a un banco?
La PSD2 es la directiva europea de servicios de pago que abre el mercado a nuevos actores y obliga a los bancos a trabajar con ellos. El open banking es el fenómeno más amplio que crece a partir de ella: el banco deja de ser un silo cerrado y se convierte en un proveedor de servicios a través de interfaces.
En la práctica, la directiva obliga al banco a varias cosas a la vez:
- acceso a cuentas (AIS) e iniciación de pagos (PIS) puestos a disposición de terceros,
- autenticación reforzada de cliente (SCA) allí donde el riesgo lo pide,
- una interfaz segura y documentada para terceros, alineada con un estándar adoptado,
- un entorno de pruebas y un registro para que los proveedores externos puedan conectarse.
No es un cambio puntual en un solo sistema, sino una capa nueva que hay que mantener y hacer crecer junto con el resto del banco.
¿Cómo se exponen las API para terceros (AIS/PIS)?
En el centro de la preparación hay dos tipos de servicio. AIS (Account Information Service) permite a un tercero leer, con el consentimiento del cliente, los datos de cuentas y transacciones. PIS (Payment Initiation Service) le permite iniciar un pago directamente desde la cuenta del cliente, sin una tarjeta de por medio.
Construir estas interfaces es más que exponer un endpoint. Las diseñamos para que aguanten tráfico real de muchos actores a la vez, con un contrato claro y sin sobrecargar los sistemas de origen. Conectamos la capa de API al core bancario mediante integraciones estables, añadimos rate limiting y versionado y lo apoyamos todo en el estándar que el banco haya adoptado, de modo que cada nueva conexión de un tercero no exija reconstruir los cimientos.
¿Cómo funciona la autenticación reforzada (SCA) en el contexto de las API?
La autenticación reforzada de cliente (SCA) es la exigencia de confirmar la identidad con al menos dos factores independientes: algo que el cliente sabe, algo que tiene y algo que es. En el mundo de las API, la SCA es lo que decide si la apertura del banco sigue siendo segura o se convierte en una puerta para los abusos.
El reto es entretejer la SCA en los flujos de API sin romper la experiencia del cliente. La montamos a partir de varias piezas:
- redirecciones y tokens que ligan la sesión del cliente con la petición del tercero,
- gestión de las exenciones de SCA allí donde la regulación las permite (p. ej. importes bajos, beneficiarios de confianza),
- vinculación del consentimiento con la autenticación, para que el cliente sepa a qué está accediendo,
- coherencia con los sistemas antifraude que puntúan el riesgo de la transacción de fondo.
Una SCA bien diseñada protege al banco y al cliente sin convertir cada operación en una prueba de paciencia.
¿Cómo se gestionan la seguridad y el consentimiento del cliente?
Abrir el banco a través de API empuja la frontera de confianza hacia fuera, así que la gestión del consentimiento se convierte en un componente propio, no en una nota al pie. El cliente tiene que saber a quién concede acceso y durante cuánto tiempo, y poder revocarlo en cualquier momento, mientras el banco registra, aplica y audita ese estado.
Aquí miramos varias capas a la vez: cifrado y certificados en la comunicación con terceros, un registro de consentimientos ligado a un alcance de datos concreto, un rastro de auditoría completo de cada acceso y monitorización que detecte patrones de tráfico inusuales. La seguridad en open banking no es una funcionalidad, sino una propiedad de toda la arquitectura - y la tratamos así desde la primera línea de código del proyecto.
¿Cómo se diseña y se gestiona la arquitectura de API?
El corazón técnico de la PSD2 es la capa entre el mundo exterior y el interior del banco. Normalmente se construye alrededor de un API gateway y de una gestión coherente del ciclo de vida de la interfaz.
Montamos esa capa con piezas que tienen que entenderse entre sí:
- un API gateway como punto de entrada, autenticación y rate limiting,
- microservicios que traducen las peticiones a operaciones en los sistemas del banco,
- un portal para desarrolladores con documentación y un entorno de pruebas (sandbox),
- monitorización y observabilidad, para ver tráfico, errores y rendimiento en tiempo real.
Esta base mantiene las API bajo control a medida que crece el número de actores conectados.
¿Por qué el open banking es una oportunidad y no solo una obligación?
La mayoría de los bancos empiezan por el cumplimiento, pero quedarse ahí desperdicia el potencial. La misma infraestructura que construyes por obligación abre el camino hacia Banking as a Service y nuevos modelos de ingresos.
Con API sólidas y bien gestionadas, un banco puede ir más lejos: ofrecer servicios a partners a través de interfaces, incrustar pagos dentro de aplicaciones de terceros, construir sus propios productos fintech sobre su plataforma. Este es el cambio clave de mentalidad: la inversión en API deja de ser un coste de cumplimiento y pasa a ser una base de producto. Por eso merece la pena diseñar la arquitectura pensando en esa segunda etapa desde el principio, aunque sea la regulación la que fuerce el arranque.
¿Qué competencias aportamos a un proyecto PSD2?
Un solo perfil no basta para un proyecto así. Cubrimos los roles alrededor del trabajo concreto, no «por si acaso»:
- arquitectos de solución que entienden las integraciones con el core bancario y los patrones de API,
- desarrolladores backend (p. ej. Java, .NET) que construyen los servicios AIS/PIS y la lógica de SCA,
- especialistas de DevOps / plataforma que levantan el API gateway, los entornos y los pipelines,
- ingenieros de seguridad que se ocupan del cifrado, el consentimiento y la auditoría.
Tratamos la experiencia en entrega de plataformas e integraciones bancarias como una condición de entrada, no como un extra deseable.
¿Con qué rapidez puede incorporarse un equipo a un proyecto bancario?
Aquí la velocidad puede ser crítica, porque los plazos regulatorios no negocian. Nuestra selección suele cerrarse en unas tres semanas y se estira hasta dos meses solo con requisitos poco habituales. Como partner nearshore desde Polonia trabajamos en una zona horaria cercana, así que los ingenieros entran en tu ritmo de trabajo, tus revisiones de código y tus reuniones sin una larga puesta en marcha. En un entorno bancario añadimos tiempo para los procesos de seguridad y los accesos, y lo planificamos de forma honesta.
¿Cómo lo hacemos en RITS?
Lo hacemos como partner nearshore desde Polonia que refuerza tu equipo con personas, no con diapositivas. En PSD2 y open banking nuestro papel es concreto:
- cubrimos los perfiles de arquitectos, backend, DevOps y seguridad, ajustados a tu stack,
- construimos la capa de API y las integraciones bajo la dirección y los estándares de tu banco,
- aportamos experiencia en plataformas e integraciones, sin atribuirnos despliegues ajenos,
- verificamos las competencias antes de empezar, porque un banco no deja margen para suposiciones.
La mayoría de las veces trabajamos como refuerzo de equipo o equipo dedicado y, cuando hace falta un alcance cerrado, como un proyecto de software a medida entregado por nuestro equipo.
¿Por dónde empezar a prepararse para la PSD2 y el open banking?
Empieza por una pregunta: qué servicios (AIS, PIS, SCA) y en qué estándar tienes que exponer primero, y cómo se conecta eso con tu core bancario. Esa respuesta define la arquitectura de API, los requisitos de seguridad y los perfiles que necesitas en el equipo. Solo después merece la pena decidir el modelo de colaboración - repasamos las diferencias en nuestro artículo sobre modelos de colaboración en TI.
¿Estás preparando un banco para la PSD2 y el open banking? Hablemos - buscamos a los ingenieros y la arquitectura que lo construirán contigo.
Prepara con nosotros tu banco para la PSD2 y el open banking