Allá por 2019, cuando me adentré por primera vez en el ámbito de las integraciones bancarias, mis búsquedas iniciales arrojaron poco más allá de la documentación oficial. Cuatro años después, una búsqueda similar en un bar local seguía sin dar resultados fructíferos. Fue en ese momento cuando se me ocurrió la idea de embarcarme en una serie de artículos que detallasen nuestras experiencias de integración con bancos en Circit - compartiendo nuestros escenarios de usuario, ideas adquiridas y conocimientos.
El enfoque inicial de estos artículos girará en torno a nuestra utilización de las integraciones bancarias, dilucidando los retos que hemos encontrado, la evolución de nuestros productos y nuestros encuentros de primera mano. Las publicaciones posteriores profundizarán en aspectos prácticos como la gestión de certificados, la validación de firmas, los procedimientos de autorización, los protocolos de incorporación y los entresijos del cumplimiento normativo.
Dentro de nuestra empresa, contamos con varios productos que aprovechan los datos de las transacciones bancarias, uno de los cuales es Transacciones verificadas. En esencia, ofrecemos acceso acelerado a los datos bancarios de los clientes durante las auditorías. Con más de 2.300 integraciones activas que abarcan bancos tradicionales, nuevas empresas de tecnología financiera, criptocarteras, etc., Circit opera bajo la supervisión reguladora de la FCA en el Reino Unido y del CBI en Irlanda. Como proveedor de servicios de información de cuentas (AIS), nuestras operaciones implican únicamente acceso de lectura sin transacciones financieras.
Sin duda, uno de los aspectos más arduos del desarrollo de nuestra solución reside en el proceso de integración.
Aunque el mundo de la tecnología va camino de la unificación, aún estamos lejos de ella, y he aquí por qué:
Hay varios marcos disponibles: CDR, PSD2, SX2A, STET y muchos otros, cada banco, y a veces incluso cada sucursal, elige independientemente qué marco utilizar y si lo utiliza o no.
Los reguladores locales suelen tener sus propios requisitos para las oficinas bancarias locales, que pueden tener muchas implicaciones, desde restricciones en los datos facilitados hasta métodos de autorización y autenticación.
Los distintos bancos se encuentran en diferentes fases de implantación de la innovación, a menudo tienen sistemas antiguos detrás de una interfaz elegante, o todo tipo de sistemas Frankenstein, no te sorprendas cuando el mismo endpoint pueda devolver json o xml dependiendo del escenario.
Aunque el mundo de la tecnología aspira a la unificación, varios factores dificultan este avance:
- Múltiples marcos: Existen numerosos marcos, como CDR, PSD2, SX2A, STET, cada uno elegido independientemente por los bancos o incluso por sucursales individuales. Esto provoca fragmentación e incoherencia en los enfoques del tratamiento de datos y las medidas de seguridad.
- Diversidad normativa: Los reguladores locales imponen requisitos diversos a las oficinas bancarias, desde restricciones de datos a métodos de autorización y autenticación. Esto añade complejidad y prácticas divergentes entre regiones.
- Infraestructura bancaria diversa: Los bancos operan con infraestructuras diversas, que van desde sistemas anticuados enmascarados por interfaces modernas hasta complejas configuraciones híbridas. En consecuencia, los puntos finales pueden devolver datos en diferentes formatos (por ejemplo, JSON o XML), lo que complica los esfuerzos de integración.
Estos retos ponen de manifiesto la necesidad de normalizar las prácticas y la interoperabilidad en el sector bancario para facilitar la fluidez de las operaciones y mejorar las medidas de seguridad.
La ausencia de normas mundiales en el sector bancario lleva a los bancos a tomar decisiones independientes, a menudo divergentes de las tendencias del sector. Esta falta de uniformidad nos ha planteado importantes retos, sobre todo en las primeras fases, cuando nuestros conocimientos y experiencia eran limitados. He aquí algunos de los supuestos que asumimos y las lecciones que aprendimos:
- Interpretación británica de la DSP2: Supusimos que las integraciones con los bancos se alinearían con la interpretación británica de la DSP2. Sin embargo, esto condujo a una integración incorrecta de muchos estados de dominio, a una desalineación terminológica y a un modelo de dominio basado en una aplicación defectuosa de la directiva.
- Aplicación uniforme del marco: Creíamos que todos los bancos que utilizaban un marco concreto lo implantarían de la misma manera. En realidad, la flexibilidad de los marcos dio lugar a diversas opciones de implementación, lo que llevó a importantes esfuerzos de refactorización tras las integraciones iniciales.
- Suministro coherente de datos: Esperábamos que todos los bancos facilitaran los mismos datos según los contratos. Sin embargo, surgieron discrepancias debido a restricciones normativas, motivos comerciales o incentivos para utilizar API de pago, lo que complicó nuestros esfuerzos de integración.
- Terminología de dominio uniforme: Suponíamos que la terminología de dominio se interpretaría de manera uniforme en todos los bancos. Sin embargo, surgieron incoherencias, como las distintas interpretaciones de los tipos de balance.
- Complejidad de la autorización: La autorización resultó ser un aspecto desafiante de la integración, ya que requería configuraciones adicionales del cliente que a menudo carecían de intuitividad. Inicialmente centrados en la autorización OAuth2, más tarde descubrimos más de 20 métodos de autorización diferentes.
- Escala de transacciones: Subestimamos la escala de las transacciones, lo que nos llevó a tomar decisiones de almacenamiento de datos que no eran las óptimas. Lo que en un principio esperábamos que fueran varios miles de transacciones por cuenta con importes de 14 caracteres resultó ser millones de transacciones con importes mucho mayores.
- Soluciones bancarias a medida: En contra de nuestras expectativas, más del 50% de las integraciones se realizaron con soluciones propias de las entidades financieras, en lugar de marcos estandarizados.
Cada uno de estos supuestos supuso un reto que superamos con éxito. Un enfoque evolutivo del desarrollo de soluciones y una arquitectura adaptable fueron decisivos para superar estos obstáculos.
En conclusión, navegar por el intrincado panorama de las integraciones bancarias ha sido un viaje plagado de retos, lecciones y evolución. Al reflexionar sobre nuestras experiencias, es evidente que el camino hacia la unificación en el sector bancario es largo y sinuoso, pero no exento de recompensas. Al adoptar un enfoque evolutivo del desarrollo de soluciones, hemos transformado los contratiempos en oportunidades de crecimiento e innovación.
De cara al futuro, mantenemos nuestro compromiso de compartir nuestras ideas, experiencias y conocimientos técnicos con la comunidad en general. Mediante la colaboración, la adaptabilidad y un compromiso compartido con la excelencia, podemos superar los obstáculos que nos esperan y seguir allanando el camino hacia un ecosistema bancario más unificado y eficiente.
Gracias por acompañarnos en este viaje, y esperamos embarcarnos juntos en el próximo capítulo.
