Open Finance: cinco decisiones de arquitectura antes de exponer su primera API

Las finanzas abiertas dejaron de ser una conversación de innovación para convertirse en una agenda regulatoria y comercial. En Colombia, el Decreto 1297 de 2022 estableció el marco de las finanzas abiertas; en la región, Brasil y México llevan años construyendo sus propios esquemas. Para un banco, una fintech o una aseguradora, la pregunta ya no es si exponer APIs, sino cómo hacerlo sin poner en riesgo el core ni acumular deuda técnica.

En los proyectos que acompañamos vemos que el éxito se decide antes de escribir el primer endpoint. Estas son las cinco decisiones que recomendamos tomar primero.

1. Trate las APIs como un producto, no como un proyecto

Una API abierta tiene consumidores externos, contratos y expectativas de estabilidad. Eso exige un catálogo, versiones y un ciclo de vida, igual que cualquier producto.

• Contrato primero: diseñe con OpenAPI (y AsyncAPI para eventos) y valide el contrato antes de implementar.
• Versionamiento explícito y una política de deprecación publicada para terceros.
• Un API gateway como punto único para autenticación, cuotas, enrutamiento y métricas por consumidor.

2. Seguridad y consentimiento como servicios de primera clase

En finanzas abiertas, el consentimiento del cliente es el activo central. No puede ser un campo en una tabla: necesita su propio servicio, con trazabilidad completa de quién autorizó qué, a quién, para qué y hasta cuándo.

• OAuth 2.0 con perfiles de alta seguridad como FAPI, de la OpenID Foundation, diseñados para APIs financieras.
• mTLS entre participantes y tokens con alcance mínimo.
• Revocación inmediata del consentimiento, propagada a todos los sistemas que consumen esos datos.

3. Proteja el core: desacople con eventos

El error más costoso es conectar las APIs abiertas directamente al core bancario. El tráfico de terceros es impredecible y el core no fue diseñado para eso.

El patrón que mejor funciona combina captura de cambios (CDC) desde el core, un bus de eventos como Kafka y una capa anticorrupción que traduce el modelo legado al modelo canónico de la API. Las consultas se sirven desde vistas optimizadas y el core solo recibe las operaciones que realmente le corresponden.

Regla práctica: ninguna llamada de un tercero debería llegar al core sin pasar por una capa que pueda limitarla, cachearla o encolarla.

4. Gobierno de datos desde el diseño

Exponer datos exige saber exactamente cuáles son, de dónde vienen y con qué calidad salen. Un catálogo de datos, linaje y reglas de calidad automatizadas evitan que un error interno se convierta en un incidente con un tercero.

También es el momento de aplicar minimización: cada API entrega solo lo que el consentimiento cubre, en línea con el régimen de protección de datos (Habeas Data) y la regulación sectorial.

5. Diseñe la operación antes del lanzamiento

Una API abierta en producción es un compromiso de servicio con terceros. Antes de salir, defina:

• Objetivos de nivel de servicio (SLO) de disponibilidad y latencia por API.
• Observabilidad de punta a punta, con trazas que sigan cada solicitud desde el gateway hasta el sistema de origen.
• Un sandbox con datos sintéticos para que los terceros integren sin tocar producción.
• Límites de tasa por consumidor y un proceso claro de soporte e incidentes.

Por dónde empezar

Recomendamos un assessment corto que mida la madurez actual en estas cinco dimensiones y priorice una hoja de ruta. En nuestra experiencia con entidades del sector, esa claridad inicial es lo que permite acelerar el time-to-market de nuevos productos sin sacrificar cumplimiento ni escalabilidad.