¿Qué es el Open Banking?

Este concepto se desprende de la tendencia hacia la apertura de datos. En el Open Banking (Banca Abierta) los bancos permitirán el acceso a los datos de sus clientes a otras entidades financieras a través de una interfaz de programación de aplicaciones (API), que permitirá la integración de servicios con terceros y la posibilidad de ofrecerlos a través de actores no financieros.

Cabe destacar que, en este modelo, los usuarios son los dueños de su información financiera, por lo tanto, ellos autorizan sí compartir sus datos o no. Si deciden hacerlo, se abre la posibilidad para que los bancos, fintechs o empresas no financieras puedan ofrecer productos y servicios financieros personalizados en el momento de compra adecuado.

Como resultado de esta nueva interacción se formarán nuevos ecosistemas de datos digitales que facilitarán las interacciones entre las instituciones financieras con sus clientes. Brasil, México, Colombia y Chile son los países en América Latina que avanzan en materia de regular el Open Banking. 

‍

Entonces, ¿cómo se ve aplicado el Open Banking? 

Imagina, por ejemplo, que quieres comprar un carro a través de una página de internet. Necesitas un crédito y el portal ofrece varias entidades aliadas que te pueden ayudar, distintas a tu banco habitual. Lo que permite el Open Banking es que estas entidades, si estás de acuerdo, puedan acceder a tu información financiera para así brindarte un crédito de acuerdo a tus necesidades. 

Este es solo un caso de muchos. Otro ejemplo es que tienes varios productos en distintos bancos. Una tarjeta de crédito, una tarjeta débito, un crédito hipotecario, un CDT, cada uno con una entidad. A través de la apertura de las APIS, una Fintech puede ofrecer una aplicación para tener todo en un solo lugar, en vez de entrar a la app o página de cada banco. Una solución así permite tener más control sobre las finanzas personales.

Estas soluciones también estarán dirigidas a empresas y pequeños negocios. Si una nueva empresa con expediente de crédito poco abultado paga con fiabilidad los servicios públicos, el alquiler y otras facturas, pueden mejorar sus posibilidades de recibir un préstamo, a veces por primera vez.

Otro caso es el Banco Topazio en Brasil, que con ayuda de la tecnología de Sensedia, pudo integrarse con más de 70 fintechs y aceleró el proceso para lanzar nuevos productos, de 1 año a 3 meses.

‍

Conozca más sobre los casos de Éxito de Sensedia 

Banco Original

BMG

‍

¿Se deben abrir los datos? 

Normalmente, la información financiera de clientes y usuarios se almacena de manera centralizada en bancos y entidades de crédito. En línea con la tendencia del Open Data, que es la democratización del acceso a los datos, también nace el Open Banking, que es abrir los datos en el ámbito financiero. 

Abrir los datos estimula la innovación de productos y servicios, así como  la competencia entre bancos y proveedores tecnológicos. Un mayor acceso a los datos bancarios podría facilitar muchos de los procesos de las empresas, eliminar burocracia, ineficiencias y reprocesos. En últimas, el cliente será el más beneficiado, pues su experiencia de usuario será mejor. En este sentido, el banco que cree una percepción de eficiencia e innovación en los usuarios, será el que mejor se posicione.

‍Open Banking: ¿oportunidad o amenaza?

La apertura de datos genera cierta desconfianza entre los usuarios. Esta es la principal barrera para la implementación del Open Banking. Sin embargo, si una API está bien diseñada, desarrollada y estructurada, y existen controles estrictos que rigen el ciclo completo de administración de API, estos problemas de seguridad desaparecerán. 

La solución al problema de la seguridad en la banca online es el desarrollo de software y APIs con estructuras adecuadas y herramientas que garanticen su funcionamiento. Además, la mayoría de países cuentan con regulaciones o normativas bien establecidas frente al uso de datos, por lo que su implementación no supone una amenaza. Por el contrario, es una oportunidad para fortalecer la seguridad a la vez que la experiencia de usuario mejora .

‍

Beneficios

El Open Banking trae beneficios para todos los implicados. En primer lugar, los clientes verán cambios que favorecen su experiencia de usuario. Entre tanto, las entidades financieras y otros proveedores tendrán que innovar y generar valor agregado en su apuesta comercial. 

Beneficios para los usuarios 

1. Mejores servicios y productos adaptados y personalizados
2. Mayor control de la información 
3. Más dominio de las finanzas personales

Beneficios para las entidades 

1. Aumento en la inclusión financiera 
2. Aceleración en la innovación y transformación tecnológica
3. Mayor interacción y fidelización del usuario.

Beneficios para la economía de los países 

De acuerdo con McKinsey Global Institute, los beneficios macroeconómicos de las Finanzas Abiertas son enormes. En un análisis de 24 iniciativas de intercambio de datos financieros en banca y pagos, la empresa descubrió que la adopción generalizada de sistemas de datos abiertos puede suponer un impulso económico considerable. Este podría oscilar entre el 1-1,5% del PIB en 2030 en la Unión Europea, el Reino Unido y EE.UU. y hasta el 4-5% en la India.

Mapa del Estado del Open Banking en América

¿Cuál es el rol de las APIs? 

Al implementar API, es posible integrar, de forma ágil, segura y escalable, entre sistemas heredados, aplicaciones móviles, servicios en la nube y ecosistemas de socios. Al combinar estas tecnologías, el potencial para generar nuevos negocios es enorme. Por ejemplo: los dispositivos pueden realizar microtransacciones con criptomonedas (pagos, inversiones, préstamos) de forma autónoma y directa entre ellos, utilizando contratos inteligentes y algoritmos.

Del Open banking al Open Finance

Al compartir datos de todos los productos del sector financiero con un conjunto de empresas – ya sean financieras o no – se expandirá la apertura de información del sector a otros actores. De esta manera, se amplía el concepto de sistema bancario abierto para players de otros segmentos, como los minoristas, que poseen operaciones de pagos. 

Las finanzas abiertas van más allá del alcance de los datos y servicios disponibles en su banco, cubriendo toda su huella financiera. Con su consentimiento, un tercero de confianza podría acceder a los datos financieros relacionados con pensiones, impuestos y seguros.

De esta forma, el Open Finance será responsable de la creación de un mercado más abierto e integrado en el sector financiero y esa tendencia acompañará nuevas oportunidades de negocios en diferentes industrias.

‍

¿Cuál es la diferencia entre Open Baking y Open Finance?

Con la aparición y la creciente adopción de la Arquitectura de Microservicios, también crece la demanda de estándares arquitectónicos que puedan ayudar a crear e implementar estos servicios. Un estándar arquitectónico puede ser de gran ayuda en este viaje de creación e implementación de servicios. El objetivo de este post es presentar el estándar arquitectónico hexagonal, sus ventajas y algunas desventajas, y cómo utilizarlo es importante recordar que cada elección tiene un costo. Por lo tanto, vale la pena mencionar que se recomienda conocer varias herramientas, sus ventajas y costos. Se debe elegir la que sea más rentable teniendo en cuenta las ventajas.

Estándar de arquitectura hexagonal

En algún momento de mi vida escuche una frase relacionada con la vida. Sin embargo, también se aplica al desarrollo de software:

"Una persona inmadura piensa que todas sus elecciones generan beneficios... una persona madura sabe que todas las elecciones tienen pérdidas." (Augusto Cury)

Por lo general, cuantas más herramientas conozcas y más información tengas sobre sus ventajas y costo. Podrás tomar una mejor decisión acerca de que herramienta utilizar como solución según el reto que se presente en su organización. Bueno, vamos a entender ya el patrón de la Arquitectura Hexagonal.

Cree su aplicación para que funcione sin una UI o base de datos, a la que pueda ejecutar pruebas de regresión automatizadas, implementar cuando la base de datos no esté disponible y conectar aplicaciones sin involucrarlas. (Alistair Cockburn)

Así es como comienza el post, extraído de la documentación de la página web de Alistair Cockburn, creador del patrón de la Arquitectura Hexagonal o también conocido como el patrón de puertas y adaptadores.

Una de las razones para crear esta pauta fue principalmente delegar la infraestructura y la parte UI del proyecto, centrarse en la regla empresarial y hacerla funcional, además de no mezclarla, es decir, una regla empresarial en la base de datos o incluso en la parte UI de un proyecto.

La arquitectura hexagonal se comparte en 3 partes:

• El lado izquierdo del hexágono
• Centro del hexágono
• El lado derecho del hexágono

En este escenario, tenemos a actores que interactúan con el centro del hexágono:

• El actor principal, (El que dirige una acción)
• El actor secundario es dirigido.

Una pregunta común es la diferencia entre los actores: ¿Quiénes son los actores principales de mi solicitud? y ¿Quiénes son los actores secundarios de esta misma?

Para responder a esta pregunta, es necesario hacer otra pregunta:

"¿Quién empieza la conversación?

"Es decir, ¿quién es el responsable de iniciar el flujo, el actor que realiza una acción?

Una vez esta pregunta se responda, tendrás a los actores principales. No importa si se trata de una persona, otro sistema, un guión bash que llama a tu adaptador, si activa un disparador que llama al core business de su aplicación.. Este es el actor principal.

Entonces, el actor secundario será llevado a realizar cierta acción que el actor primario ha desencadenado. Puede estar grabando datos, registrándolos, o incluso llamando a una tercera aplicación y obteniendo una respuesta, volviendo al actor primario.

El centro del hexágono

Es donde se encuentran los modelos, dominios y reglas de negocio de su software . Es un entorno que debe estar totalmente aislado en términos de no ser afectado por acontecimientos externos, por ejemplo, la base de datos que se utilizará para el frontend.

Centro del hexágono

Es el lado del actor principal, el lado del usuario, el que lleva a cabo una acción, ya que es el lado del usuario el que realizará algunas tareas.

El lado derecho del hexágono

Es el lado del actor secundario. Este es el lado de los datos, el que se lleva a cabo ya sea para escribir los datos, leer los datos, modificar los datos y borrar los datos.

Puertos

Las puertas son la comunicación gateway entre el centro de tu hexágono con los lados izquierdo y derecho de tu hexágono, con los lados externos.

Adapters

Los adaptadores son los usuarios de las puertas. Por cada puerta que tenga su hexágono se debe crear un adaptador. Por lo tanto, tiene la libertad de modificarlo y borrarlo dinámicamente. En las puertas y adaptadores, también tenemos el concepto de puertas primarias y secundarias, y el concepto es el mismo que se utiliza con los actores.

En los actores primarios de nuestra aplicación tenemos los conductores de la acción, que utilizarán los adaptadores primarios, y esto "llamará" a las puertas primarias. Así, las puertas secundarias y los adaptadores conducirán la acción al actor secundario en el flujo continuo de la aplicación.

Inversión de Control (IoC)

En un flujo real, usando como ejemplo el simple registro de datos, tendríamos lo siguiente:

• El lado izquierdo (el conductor) entrega la información, usando un adaptador y a través de la puerta principal, al centro del hexágono (dominio).
• El centro del hexágono, entonces, recibe datos a través del puerto, luego los procesa usando una puerta secundaria y llama al lado derecho.
• El lado derecho (el conducido) llama a una base de datos para registrarlos.

Al final, tendríamos esto como el flujo del Hexágono:

Lado izquierdo -> Centro -> Lado derecho

Este escenario impacta en los conceptos de la Arquitectura Hexagonal, ya que el dominio debe estar aislado y ser el único responsable de la regla de negocio, porque en el ejemplo anterior, tendría que ser responsable de llamar a la entidad responsable de la grabación.

Ahora, surge el concepto de Inversión de Control (IoC).

La inversión de control (IO) es un patrón que aboga por utilizar instancias de una cierta clase, tratándola externamente y no dentro de la clase, es decir, delega el control de una clase a otra. Puede ser una interfaz, un componente, un servicio, etc.

En nuestro caso, invertirá precisamente en el flujo del orden, asegurándose de que, aún utilizando el ejemplo nuestra base de datos vaya a nuestro centro y no al revés, dejando nuestro dominio realmente aislado.

Al final, este sería nuestro flujo correcto:

Left side -> Center <- Ioc- Right side

Fortalezas

Fortalezas del uso de esta arquitectura:

• Solución de servicios externos independientes
• Permite aplazar algunas decisiones técnicas
• Creación y sustitución de adaptadores
• Fácil de probar la aplicación
• Tecnologías fáciles de intercambiar

Debilidades

También consideramos algunos aspectos negativos en el uso de esta arquitectura hexagonal:

• Complejidad adicional (Construcción de más capas)
• Costo de creación y mantenimiento
• No hay ninguna orientación sobre la organización del código (Directorios, capas)

Conclusión

Se toma como guía la arquitectura hexagonal, a partir de ella se crearon nuevos conceptos arquitectónicos con información más granular en la organización del código (Directorios y Capas), como ejemplos tenemos la Arquitectura Cebolla, de Jeffrey Palermo, y la Arquitectura Limpia, de Robert C. Martin (Tío Bob). Ambos se refieren al patrón creado por Alistair Cockburn.

Incluso si ya ha elegido seguir la idea de Jeffrey o del tío Bob, le recomiendo estudiar la arquitectura hexagonal para entender el concepto de aislamiento del dominio y la comunicación con sus respectivos actores. Después de eso, se dará cuenta que será más fácil entender las ideas de otros autores que crearon nuevos conceptos basados en esa idea inicial.

Contexto

Actualmente, la arquitectura de Microservicios se convirtió en un hype dentro del segmento de desarrollo software . Este modelo de arquitectura es un enfoque que determina el despliegue de las aplicaciones en una gama de servicios. El equipo de desarrollo puede adoptar las tecnologías más adecuadas para resolver problemas específicos. La arquitectura de microservicios también aumenta la escalabilidad al permitir el uso de enfoques como el autoescalado y el microcontenedor.Las APIs y los microservicios están estrechamente relacionados, ya que el estándar es utilizar una interfaz API totalmente dirigida a RESTful. Sin embargo, en la actualidad todavía nos encontramos con algunos problemas cuando necesitamos integrarnos con sistemas heredados para externalizar funcionalidades como los servicios, ya que la mayoría de los sistemas no disponen de protocolos como WebServices o interfaces RESTful; por lo tanto, vamos a explorar ese tema.

El problema y el enfoque de los microservicios

La mayoría de las empresas desean exponer APIs internamente (dentro de la corporación) y/o externamente (a socios o clientes), sin embargo, sus sistemas o aplicaciones no fueron diseñados para ese fin. La mayoría de las aplicaciones se basan en la siguiente arquitectura:

• Aplicaciones web monolíticas que utilizan una única base de datos. Por ejemplo Java (JSF) con base de datos Oracle.
• Producto o plataforma, como SAP ERP.
• Aplicaciones de alto nivel escritas en Cobol
• Aplicaciones cliente-servidor implementadas en VB6 y SQL Server.

Cuando nos enfrentamos a este tipo de escenario, la solución común es construir un adaptador para exponer un protocolo estándar. Ese componente debería parecerse al diagrama que se presenta a continuación:

El adaptador es el componente principal de la solución, ya que permitirá la externalización del servicio. Para promover esa estandarización, es necesario utilizar algunos estándares:

• Compatibilidad total con el estándar RESTful
• Organización por áreas de negocio
• Ser fácilmente escalable
• Paquetes ligeros con una rápida inicialización.

Para tener una aplicación con un modelo de integración simple y escalable es necesario tener un estilo de arquitectura que cumpla con todos esos requisitos y el estilo de arquitectura que más se asemeja a esas características es el de Microservicios.Recuerda que esta recomendación aplica cuando tu backend no está expuesto con el protocolo HTTP, ya que la mayoría de las soluciones de API Gateways lograrán enrutar y transformar fácilmente los mensajes para la comunicación con el backend.Otros escenarios en los que la arquitectura de Microservicios es muy recomendable son:

• Orquestación: en algunos casos, se debe enrutar y/o ejecutar otros servicios dependiendo de alguna condición específica.
• Composición: a veces, es necesario ejecutar más de un servicio para componer y devolver una respuesta.
• Transformación de mensajes complejos: cuando es necesario utilizar algoritmos más complejos para devolver un mensaje al consumidor del servicio.

Por último, ten en cuenta que los microservicios deben organizarse dentro de los dominios de tu negocio. De esta manera, podemos ver que este estilo de arquitectura es una oportunidad para romper el monolitismo de su negocio y proporcionar una mejor arquitectura, como el diseño presentado a continuación:

Este es un artículo muy interesante sobre los microservicios.

Estrategia de implementación de microservicios

Después de decidir que la implementación del adaptador se basará en una arquitectura de Microservicios, son necesarias algunas características:

• Paquetes ligeros y bajo consumo de memoria
• La inicialización de la aplicación debe ser rápida para crear rápidamente nuevas instancias de contenedores o servidores.
• Desarrollo rápido y sencillo basado en la especificación Swagger
• Funciones de seguridad como OAuth2

Algunos de los marcos que sugerimos son: Java:

• Spring boot
• Marco de trabajo de Spark
• Marco de juego
• Dropwizard
• Apache Camel

JavaScript:

• js

Otra característica crucial a la hora de implementar APIs utilizando Microservicios es la capacidad de integración con sistemas heredados. Este tipo de característica requiere un framework específico que implemente los estándares de integración empresarial (patrones EAI); la recomendación en este caso es utilizar el framework Java Apache Camel.

Estrategia de implementación de microservicios

Después de implementar el paquete de Microservicios y asegurarse de que está listo, hay que implementarlo para que esté disponible para su uso. La estrategia más recomendable es utilizar servicios PaaS (Platform as a service) para implementar los paquetes de Microservicios. Esto se debe a que este tipo de servicio ofrece algunas características muy interesantes como:

• Uso de contenedores
• Orquestación de contenedores
• Almacenamiento (sistema de archivos y base de datos)
• Seguimiento en tiempo real
• Registro y seguimiento

Otras dos características importantes son:

• Ser capaz de escalar para apoyar el transporte
• Ofrecer APIs para automatizar el proceso de implantación

Se deben evaluar las principales ofertas de PaaS en el mercado para una estrategia de implementación, incluyendo:

1. Pivotal Cloud Foundry
2. Red Hat OpenShift
3. SalesForce Heroku

Otras opciones que se pueden considerar son Amazon Elastic Beanstalk y Google App Engine. Ambas son muy interesantes, ya que tienen una integración nativa con los servicios Cloud y de Infraestructura y además ofrecen servicios de infraestructura como servicio (IaaS).Sin embargo, en nuestra opinión, la mejor alternativa para la implementación de microservicios es la que resulta de una integración completa con una plataforma de gestión de APIs y, en este caso, la Suite API de Sensedia ofrece una funcionalidad denominada BaaS (Backend as a Service) que utiliza las mismas características del servicio PaaS y realiza esta integración.Esta característica le permite realizar la implementación y ejecutar sus microservicios, exponiendo directamente las APIs de sus sistemas heredados.Las tecnologías soportadas por BaaS son:

• Java
• js
• Apache Camel

Es importante recordar que si puedes utilizar esta plataforma para ejecutar tus microservicios que no son sólo los que permiten la integración con legados, podría ser tu plataforma oficial de ejecución de microservicios.

Microservicios y plataformas API Management

Después de que los Microservicios estén funcionando correctamente, las APIs que exponen los Microservicios deben ser bien gestionadas y algunas de las características esenciales para ello, que la mayoría de las plataformas de este tipo ofrecen son:

• Seguridad y resiliencia: necesaria para proteger su backend de personas o aplicaciones no habilitadas para consumir esas APIs. Cuando una API se abre a los socios, sus Microservicios deben estar protegidos contra los picos de transporte, para que no esté fuera de servicio y, por lo tanto, es necesario tener un control del límite de tráfico (Rate Limit y Spike Arrest) y del límite de tamaño del cuerpo del mensaje (Payload Size).
• Control de acceso: Los consumidores de la API deben estar bajo su control y, por tanto, hay que utilizar estándares de mercado como OAuth 2.0 o JSON Web Tokens.
• Monitoreo y seguimiento: se debe lograr monitorear todos los tipos de solicitudes realizadas en su plataforma; además, se debe contar con un poderoso mecanismo de registro para encontrar los errores que se producen en su API.

Todas las capacidades anteriores son comunes en una API Gateway solución, pero algunas otras características cruciales para la gestión completa de sus APIs son:

• Almacenamiento en caché: debería ser capaz de evitar peticiones innecesarias en la propia API, ofreciendo una latencia mucho mejor para las propias peticiones, ahorrando incluso el coste de la infraestructura de backend.
• Analytics: el uso de la API monitorizado en tiempo real es muy importante, tanto para controlar el consumo como para ofrecer insights sobre cómo vender, monetizar y utilizar la API de la mejor manera.

Como se ha mencionado anteriormente, algunas plataformas API Management ofrecen una integración total con la plataforma de ejecución de microservicios. Este tipo de funcionalidad ofrece una gestión total de todas las partes de la solución, no requiriendo una infraestructura separada. De este modo, su arquitectura será la que se muestra en la siguiente figura:

Conclusión

El uso de la arquitectura de microservicios permite el desarrollo de interfaces RESTful que expondrán su legado que nativamente no tiene una interfaz HTTP, pero el primer reto es elegir las herramientas correctas para esa implementación. Hay muchos frameworks y lenguajes que pueden ayudar en la implementación de microservicios. La decisión depende mucho del escenario al que se enfrente, pero en este artículo se mencionan algunos de los más utilizados.Después de elegir el kit de desarrollo, la siguiente decisión que se debe tomar es determinar la plataforma de implementación y ejecución. Una vez más, la decisión depende mucho del escenario que se esté afrontando, pero, en este caso, el objetivo principal es la exposición de APIs RESTful cumpliendo de forma consistente con los requisitos funcionales y no funcionales.Sensedia API Suite es una herramienta de API management que consigue ofrecer la funcionalidad de Backend as Services (BaaS), que puede sustituir las responsabilidades de una PaaS en la implementación y ejecución de Microservicios. Además, la herramienta ofrece todas las características clave para la gestión ideal de una API, como API Gateway con Caching y Analytics. En definitiva, la recomendación es utilizar una o varias plataformas integradas que consigan permitir la gestión total de tus Microservicios y de las APIs que serán expuestas.

Referencias

1] Microservicios - http://www.martinfowler.com/articles/microservices.html
[2] Apache Camel - http://camel.apache.org/
[3] Comparador PaaS - https://paasfinder.org/compare
[4] Twelve Factor App - https://12factor.net/
[5] Plataforma Sensedia API Management - http://sensedia.com/api-management-platform/
[6] API Gateway Patrón - https://www.nginx.com/blog/building-microservices-using-an-api-gateway/