Plataforma BaaS para entidad bancaria estadounidense

Una de las principales revoluciones en el mundo de la banca moderna es el cambio de paradigma en la forma de vender los servicios bancarios: de atender a los clientes en oficinas, se ha pasado a atender la mayor parte del negocio de forma online, para lo cual pueden ofrecer dos canales: el más tradicional de las aplicaciones de banca online y el más reciente, nacido al calor de la disrupción provocada por las nuevas empresas Fintech, que consiste en ofrecer sus servicios a través de APIs, interfaces para conectar aplicaciones externas al banco a los sistemas de la entidad y permitirles realizar operaciones haciendo uso de su infraestructura bancaria.

Evidentemente, conectarse a los sistemas de un banco es una cosa muy seria, y los bancos no están dispuestos (por muy buenas razones) a integrar de cualquier manera una aplicación de un tercero dentro de sus militarizados sistemas digitales. No sólo esto, sino que existen normativas muy restrictivas (como PSD2 en Europa, CMA Open Banking en Reino Unido o HKMA en Hong Kong) que regulan tanto la obligatoriedad de proporcionar estos servicios como la forma de gestionar la seguridad y la privacidad de los mismos.

En esta ocasión, el reto que se presentaba a nuestros equipos venía de una entidad bancaria estadounidense que quería poner en marcha un ecosistema de APIs abiertas para ofrecer este tipo de servicios, con un marketplace que permitiese el descubrimiento de las mismas y facilitase al máximo su contratación e integración en las aplicaciones de los clientes, garantizando a la vez tanto la seguridad como la escalabilidad en rendimiento.

Es importante poner en contexto la importancia de este proyecto, pues finalmente acabaría implicando, de facto, la creación de una arquitectura bancaria completa, totalmente basada en la nube que, a pesar de emplear el HOST del cliente como fuente de la verdad, reduciría significativamente el volumen de trabajo del mismo comparado con el mismo volumen de transacciones provenientes del sistema tradicional.

Y ¿cómo llegó este proyecto a SNGULAR? Nuestro cliente nos contactó por su experiencia de años trabajando con nosotros en la creación de múltiples canales digitales, tanto para banca comercial como empresarial, nuestro conocimiento del negocio y nuestra experiencia creando sistemas de integración, tanto para ellos como para muchos otros clientes de gran tamaño y complejidad. Además, SNGULAR es un relevante miembro de BIAN, la red de arquitectura de la industria bancaria, una entidad global cuyo objetivo es trabajar para crear estándares de negocio y de TI comunes para la industria de los servicios financieros, por lo que estamos muy familiarizados con esta problemática.

El objetivo de negocio de nuestro cliente estaba claro: tener una nueva vía para ofrecer servicios digitales, un canal extra para dar estos servicios y aliarse con las fintech que de manera inexorable les han ido comiendo una parte significativa del mercado a los propios bancos, basado en una arquitectura moderna y elástica, que pudiese escalar bajo demanda para atender cualquier volumen de transacciones que pudiesen traer estas alianzas.

Para ello, nuestros equipos crearon una capa completa de servicios de primer orden, que encapsulaban los servicios internos del propio banco y proporcionaban acceso a los mismos a través de un sistema que garantizaba la seguridad tanto a los clientes del banco como a los clientes de estas terceras empresas.

Para la creación de toda esta capa de servicios, se optó por una arquitectura de microservicios desarrollada usando Java Spring Boot, sobre una infraestructura AWS containerizada y desarrollada bajo la filosofía de “infraestructura como código”, altamente escalable, que permitía un bajo uso de recursos en los momentos de baja ocupación y una alta fiabilidad y agilidad de respuesta en momentos de alta volumen de operaciones concurrentes, así como el despliegue rápido en nuevos entornos.

Se optó también por el uso de servicios gestionados, para minimizar la complejidad y el coste derivados de la operación de un sistema del volumen y complejidad como el creado. No en vano, estamos hablando de una decena de entornos, con más de 400 servicios desplegados en cada uno de ellos, virtualmente un “bank as a service” completo, que encapsulaba el uso del HOST bancario como fuente de la verdad detrás de un patrón CQRS, particularmente útil en entornos complejos basados en eventos y que permite emplear modelos diferentes para la lectura y para la actualización de la información, aportando entre otras ventajas un importante ahorro en MIPS en el HOST, con la consiguiente reducción de costes.

Es de reseñar que a pesar de tratarse de un sistema extremadamente complejo, estaba montado para ser extremadamente ágil y robusto por diseño, totalmente levantado por infraestructura como código y un sistema de integración y despliegue continuo que permitía realizar decenas de despliegues diarios, en horario comercial, sin interrupción del servicio, a diferencia de los ciclos habituales de despliegue en entornos bancarios, muy escasos y de alto impacto en las operaciones. Para asegurar que no se producían sorpresas a pesar de tener ciclos de despliegue tan ágiles, el pipeline de integración y despliegue continuo incluía más de 6.000 escenarios de prueba que se ejecutaban antes de cada uno de ellos para comprobar su solidez.

Resulta ilustrativo que se superase el ambicioso SLA propuesto, superior al 99,95%, a pesar de hablar de un sistema que procesaba 130 millones de logs a la hora, o 12.000 solicitudes por minuto. Todo ello, con un completo sistema de dashboards de monitorización y alertas para asegurar que absolutamente todo aquello que debiese estar monitorizado, lo estaba.

A pesar de la complejidad interior del sistema, éste era extremadamente sencillo de comenzar a utilizar: sólo había que darse de alta y recibir un token con el que podían conectarse a un sandbox. Este sandbox permitía probar las APIs tanto como se quisiera en un entorno virtualmente idéntico al de producción, pero sin acceder a los datos y usuarios reales. Cuando los usuarios desarrollaban su implementación en el sandbox y estaban satisfechos con la misma, podían progresar a entornos reales, evidentemente con sistemas de seguridad más avanzados, consiguiendo un equilibrio perfecto entre potencia, facilidad de uso y versatilidad. Todos los servicios prestados quedaban, por supuesto, protegidos detrás de los sistemas de seguridad del banco.

Por su lado, el marketplace de APIs se desarrolló con tecnología JavaScript + WebComponents, con la librería Polymer de Google, que con el tiempo se fué migrando a LitElement. Esta elección vino impuesta por el propio cliente, por la flexibilidad otorgada por estas tecnologías y su nivel de “future proofness” (al ser estándares de convergencia).

Nuestro trabajo fue desarrollado por varios equipos totalmente de SNGULAR, en contacto directo con los Product Owner de nuestro cliente, trabajando en sprints SCRUM. Nosotros realizamos el desarrollo y la infraestructura y nuestro cliente se encargaba del soporte a la producción y el contacto directo con los clientes que consumían los servicios.

Una de las mayores dificultades a la que nos enfrentamos radicaba en la propia complejidad de las APIs, pues nuestro cliente era la rama local de una entidad bancaria internacional con un sistema interno de APIs globales diseñado para cubrir las necesidades de un gran número de países. De esta manera, las respuestas de las APIs internas incluían una gran complejidad de datos, innecesaria para el servicio a los clientes de EE.UU., por lo que una de las partes más importantes consistió en la encapsulación de esa complejidad para ofrecer a los clientes unas interfaces limpias, sobrias y efectivas.

Otro de los problemas, habituales en este tipo de servicios tenía que ver con el versionado, pues las APIs no son “contratos” estables e inmutables, sino que evolucionan con el tiempo según se mejoran o se actualizan los servicios que se prestan a través de ellas. Sin embargo, cuando múltiples aplicaciones acceden a una API, cambiar ésta puede “romper” el funcionamiento de las mismas, por lo que siempre que haya cambios que afecten a la forma en las que se invoca a las APIs o se reciben sus resultados, hay que mantener un acceso a la versión previa para que nada deje de funcionar. Por ello, que se trabajó en conseguir un sistema de versionado que fuese a la vez robusto, fiable, fácil de entender y mantener y sencillo de consumir.

Adicionalmente, el estar constantemente en el estado del arte de la tecnología era una necesidad en un servicio como este que tiene que ser lo más future proof posible, lo que obligó a numerosas actualizaciones tecnológicas cuando se producían cambios importantes (y que nos proporcionasen una ventaja evidente) en las tecnologías sobre las que nos apoyábamos, como los servicios de AWS o las herramientas que se empleaban.

El desarrollo de este proyecto puede estar entre los más enriquecedores para nuestros equipos, pues se trataba de un proyecto enormemente innovador en el que aparte de todos los aprendizajes tecnológicos derivados de estar en el estado del arte, nos permitió ampliar muchísimo la comprensión del negocio y de los servicios demandados por los clientes en este tipo de entornos e iniciativas, así como lo que hay que ofrecer a estos clientes finales, muchos de ellos empresas fintech punteras, cuando desarrollas APIs.

El resultado no pudo ser mejor, pues el sistema ha sido considerado uno de los mejores servicios de su categoría por versatilidad, robustez y facilidad de uso y en su momento llegó a permitir a nuestro cliente cerrar un acuerdo con Google para que fuese ésta plataforma sobre la que Google ofrecería sus servicios de cuenta bancaria en EE.UU.