¿Y eso por qué? Porque, en la mayoría de los casos, las API se han implementado como una capa adicional a los sistemas existentes. Esto conduce a una serie de problemas que pueden costar dinero a las empresas y socavar la confianza de sus clientes y socios que dependen de sus sistemas. Expliquemos por qué las API deben ser tratadas como "ciudadanos de primera clase" para crear arquitecturas que sean funcionales y escalables.

Malos cimientos…

Las API han surgido como la solución para modernizar los sistemas bancarios ante un doble fenómeno: por un lado, el auge de las nuevas tecnologías que aumenta las expectativas de los consumidores y, por otro, un entorno normativo en constante cambio que introduce nuevos imperativos y, simultáneamente, nuevas formas de competencia. En particular, la DSP2 (segunda Directiva de Servicios de Pago en español) obliga a los bancos europeos a crear API de banca abierta para abrir los datos de sus clientes (relacionados con los pagos, las cuentas, los préstamos...) a otros bancos y fintech, haciendo así el sector bancario más abierto y transparente. Según el Observatorio de Banca Abierta de KPMG, cuanto más rápido obedezcan los bancos a la DSP2, más probabilidades tendrán de pasar de ser "conformes" a ser "competitivos", adaptando el enfoque de las API abiertas a casos de uso más allá del marco de la DSP2, o incluso "innovadores", creando nuevos servicios (nuevos canales de distribución, monetización de herramientas estadísticas, banco como servicio...).

Como resultado de estos dos fenómenos, el sistema bancario se ha convertido en una hidra de dos cabezas: por un lado, los bancos tradicionales con infraestructuras envejecidas y procesos largos e ineficientes, y por otro, las fintech que ofrecen servicios financieros más eficaz y rentables a través de soluciones web y móviles innovadoras.

De hecho, los bancos tradicionales han sido durante mucho tiempo organizaciones aisladas, compuestas por diferentes departamentos que utilizan un mosaico de sistemas dispares para cumplir sus diferentes objetivos. En un esfuerzo por digitalizar los flujos de trabajo y liberarse de los procesos basados en el papel, han introducido una variedad de soluciones de software independientes que, al unirse, permiten completar los procesos bancarios. Sin embargo, las interrupciones que quedan necesitan la intervención humana, lo que da lugar a flujos de trabajo digitalmente incompletos. No sólo eso, sino que también requieren una amplia codificación por parte del departamento de IT. A pesar de sus esfuerzos, no se integran bien con los sistemas existentes, para que no se comuniquen automáticamente y creen silos de información.

Aquí es donde las API entraron en escena. Ofrecían la promesa de integrar estos sistemas y servicios dispares en plataformas unificadas en las que pudieran intercambiar datos y realizar un conjunto de rutinas en colaboración con sistemas externos.

… y una mala lógica de implementación

En esta lógica, las API se implementan como una capa adicional a los sistemas existentes. Estos últimos ya funcionaban antes de la introducción de las API, por lo que cuando los desarrolladores las prueban no pasan por ellas. Entonces, una serie de problemas de rendimiento no se detecta porque no se realizan las comprobaciones adecuadas en las API: problemas de volumen, carga de usuarios, regresión del rendimiento tras varias iteraciones, etc., que generan errores y lentitud y, por tanto, añaden costes adicionales al TCO (Coste Total de Propiedad en español).

Las API de bajo rendimiento desencadenan un efecto dominó e impiden que otras API de la integración respondan correctamente. Todos estos factores aumentan los tiempos de respuesta y degradan la experiencia del usuario, minando así la confianza de los clientes y socios que dependen de estos sistemas.

Más graves aún son los agujeros de seguridad causados por la realización de pruebas de productos sin pasar por las API. Al dividir los sistemas en aplicaciones autónomas, modulares y reutilizables, el enfoque de las API abre nuevos puntos de acceso al riesgo de ciberataques. La exposición y el carácter crítico de las API, ya que manejan datos sensibles (personales, bancarios...), hacen absolutamente necesaria la adopción de protocolos de seguridad para garantizar que ninguna amenaza pase desapercibida. Estas pruebas sólo se llevarán a cabo correctamente si las API se consideran un elemento central de las arquitecturas bancarias.

Damos al César lo que es del César

En lugar de una superposición, una idea de última hora, las API deben ser tratadas como "ciudadanos de primera clase", es decir productos propios y no sólo integraciones subsumidas en otros sistemas. Para que su eficacia y seguridad se conviertan en una prioridad, en una arquitectura "API-first" cada proyecto de desarrollo debe tener en cuenta el objetivo final de consumo de las API.

A partir de entonces, las API se convierten en las piedras angulares de los sistemas informáticos. Interconectados y omnicanal – llamables en cualquier momento y por cualquier vía –, son los enlaces de una red. Los monolitos, en cambio, son callejones sin salida, nodos terminales, porque pueden ser llamados, pero no hacen ninguna llamada al exterior, no rebotan. Para que los datos se muevan de un sistema a otro, las API deben ser eficientes, rápidas y muy seguras, y esto sólo puede funcionar si son tratadas como ciudadanos de primera clase.

Además de integrarse fácilmente con otros sistemas, las API permiten arquitecturas modulares en las que las capacidades de las organizaciones se dividen en microservicios, es decir, servicios individuales, independientes y poco acoplados. Los componentes de la plataforma pueden entonces añadirse o sustituirse mediante el método de "arrastrar y soltar" para introducir nuevas funciones a medida que el negocio crece y se introducen las últimas tecnologías. En lugar de desarrollar nuevo código cada vez que se necesitan nuevas conexiones entre aplicaciones, los equipos técnicos pueden establecerlas más rápidamente aprovechando las API existentes.

Este enfoque también está cambiando la forma en que las instituciones bancarias gestionan sus procesos empresariales. Los flujos de trabajo se están automatizando y digitalizando: al sustituir la intervención humana por el autocuidado, mejoran la conductividad entre el front y el back office y hacen que los recorridos de los clientes sean más completos.

Lea también: Por qué el autoservicio front-to-back es el futuro de la banca de nueva generación

Buenas noticias, ¡la plataforma Basikon es API-first!

Más que API-first, API-second o API-third, es API-only. Ahora que lo has leído todo, habrás comprendido que las API, que forman la columna vertebral de la plataforma, están presentes en todas las etapas de los procesos de negocio y de los recorridos de los clientes (verificación de la identidad, banca abierta, scoring de crédito, generación de contratos, firma electrónica, iniciación y cobro de pagos seguros, generación de asientos contables…). La supervisión del rendimiento y de la exposición de la plataforma, incluidas los de las API, garantiza que toda la integración sea sólida, rápida y segura.

Y no se queda ahí. La plataforma Basikon también es altamente personalizable por dos razones. En primer lugar, además de una amplia cartera de API "estándar", es posible crear otras API ad hoc para que se adapten perfectamente a las necesidades de cada cliente y a sus especificidades en la forma de distribuir los créditos: es la API como servicio. En segundo lugar, como los flujos de trabajo son 100% configurables, son capaces de gestionar todos los tipos de financiación y adaptarse a todos los casos de uso (banca, leasing, crédito al consumo, financiación de automóviles, mayorista, revolving, garantía, factoring, Buy Now Pay Later, Revenue-Based Finance, microfinanciación...). Gracias a la tecnología de “código bajo”, se adaptan a la evolución de su modelo de negocio sin necesidad de codificación adicional: los gestores de proyectos pueden establecer sus propias reglas y realizar ajustes a medida que la organización crece y su oferta se diversifica.

Lea también: Lanzar su oferta Buy Now Pay Later es posible con Basikon

Plataforma de Revenue-Based Finance: ¿fabricar or comprar?

Para saber más sobre la plataforma API-first de Basikon y cómo su fiabilidad, agilidad y seguridad permitirán una experiencia fluida para sus usuarios internos, clientes y socios, solicite una demostración aquí.