Banca API-First: La Base Técnica del Open Finance
- WAU Marketing
- 17 mar
- 4 min de lectura
Actualizado: hace 3 días
"Ya tenemos APIs." Es la respuesta que más escuchamos cuando preguntamos si una institución está lista para Open Finance. Y casi siempre significa lo contrario de lo que cree.
Tener una API no es ser API-first. Son dos cosas distintas, y la diferencia decide si tu institución va a competir en la banca abierta o va a quedarse mirando desde afuera. Porque el Open Finance no es una funcionalidad que se agrega: es una arquitectura. Y si tu core no nació para ella, ningún parche la simula.
Empecemos por la ley, no por la moda
En México, el Open Finance no es una tendencia: es un mandato. El Artículo 76 de la Ley Fintech obliga a las entidades financieras a compartir información de sus clientes mediante interfaces de programación de aplicaciones —APIs— estandarizadas. Léelo otra vez: la obligación regulatoria es, literalmente, una obligación de tener APIs. Sin APIs estandarizadas no hay Open Finance; hay incumplimiento.
Las primeras disposiciones se publicaron en junio de 2020 y aplican a más de 2,400 entidades del sistema financiero —no solo bancos—. Por ahora cubren la capa de datos abiertos, pero la dirección es clara y México tiene un rasgo que nadie más en la región comparte: permite a los proveedores cobrar por el acceso a sus APIs, ya que deben publicar y registrar ante la CNBV los montos de contraprestación por el intercambio de datos, como documenta el despacho Holland & Knight. Es decir, una API bien construida no es solo cumplimiento; puede ser una fuente de ingresos.
Qué significa "API-first" de verdad
Aquí está la distinción que casi nadie hace bien. API-first —también llamado "contract-first" o "diseño primero"— significa que el contrato de la API se diseña antes que el código. Primero defines la interfaz: qué datos entran, qué datos salen, cómo se comporta. Y luego construyes el sistema alrededor de ese contrato. La API no es una salida del sistema; es el punto de partida.
Lo contrario —lo que tiene la mayoría— es un core construido a su manera, al que años después se le "atornillan" APIs por encima para conectarlo al mundo. Funciona en una demo. Falla en producción, porque esas APIs heredan todas las limitaciones del core que tienen debajo.
El espejismo del gateway
Esta es la trampa más cara que vemos. Una institución pone un API gateway frente a su core legado, expone unos endpoints, y declara victoria: "ya somos API-first". No lo es. Vale la pena separar tres conceptos que suelen confundirse:
El API gateway es un controlador de tráfico: enruta peticiones, balancea carga, autentica. Táctico, útil, pero solo una puerta.
El API management es todo el ciclo de vida: versionado, analítica, gobernanza, portal de desarrolladores. El gateway es una pieza dentro de él.
API-first no es ninguno de los dos. Es una metodología de diseño. El gateway y el management exponen y gestionan APIs que ya existen; API-first determina cómo nacen esas APIs.
El punto incómodo: ponerle un gateway a un core monolítico y batch te da APIs, sí, pero APIs que no operan en tiempo real, que se rompen cuando tocas el sistema, que arrastran el acoplamiento de abajo. Maquillaste la fachada; la casa sigue siendo la misma.
Por qué un core legado no da APIs de calidad
Dos razones técnicas, concretas. Primero, el procesamiento por lotes: los sistemas legados acumulan operaciones para procesarlas en ventanas —de noche, por hora—, lo que hace imposible exponer datos en tiempo real. Una API sobre un core batch te entrega el saldo de ayer, no el de ahora. Segundo, el acoplamiento fuerte: en un monolito, todo está entrelazado; cambiar un componente obliga a tocar y reprobar el resto. Cada API nueva es un proyecto, y cada proyecto, un riesgo.
El contraste de escala lo dice todo. En el Reino Unido, donde el Open Banking ya maduró, el ecosistema procesó más de 24 mil millones de llamadas API exitosas en 2025, un 27% más que el año anterior, según Open Banking Limited. En Brasil, las llamadas superaron los 100 mil millones en 2024, de acuerdo con The Paypers. A nivel global, se proyecta que el volumen de llamadas de Open Banking rebase los 720 mil millones para 2029, según Juniper Research. Ese tráfico no corre sobre cores batch con APIs atornilladas; corre sobre arquitecturas diseñadas, desde el inicio, para hablar por API.
Cómo lo vemos en WAU
En WAU no le ponemos una capa de APIs a tu core legado y te decimos que ya estás listo para Open Finance. Diseñamos —o rediseñamos— el core con mentalidad API-first: el contrato primero, capacidades expuestas en tiempo real, desacopladas, listas para cumplir el Artículo 76 y, de paso, para monetizar el acceso. La diferencia entre una API maquillada y una API-first real es la diferencia entre cumplir en el papel y competir en serio.
Si quieres saber si tu arquitectura es de verdad API-first o solo tiene un gateway encima, hablemos. Te lo decimos sin adornos y trazamos la ruta. 👉 Agenda una conversación con nuestro equipo.
Comentarios