Durante casi una década, la región discutió el Open Banking en sandboxes regulatorios y hojas de ruta voluntarias. Ese periodo terminó: la obligación legal ya es una realidad en varios países. Ahora, la pregunta pendiente es si esa obligación legal se refleja en APIs que un tercero pueda usar en producción sin fricción constante.
¿Qué es el Open Banking y en qué se diferencia del Open Finance?
El Open Banking es el intercambio de datos de cuentas y pagos entre instituciones financieras y terceros autorizados, bajo consentimiento explícito del titular. El Open Finance amplía ese alcance a crédito, inversiones, seguros y pensiones. La región usa ambos términos de forma intercambiable, aunque la mayoría de los marcos recientes —Brasil, Colombia, Chile— ya se diseñaron directamente como Open Finance, con el sistema bancario como un participante más entre cooperativas, aseguradoras y administradoras de fondos.
¿Cómo funciona técnicamente el intercambio de datos?
El flujo típico combina OAuth 2.0 y OpenID Connect bajo el perfil de seguridad FAPI (Financial-grade API), con autenticación mutua por certificado (mTLS) y firma de mensajes (JWS). Un tercero registrado —un Account Information Service Provider (AISP) o un Payment Initiation Service Provider (PISP)— solicita el consentimiento del usuario, la institución financiera lo valida y, a partir de ahí, expone los datos o ejecuta el pago a través de endpoints REST estandarizados por el regulador de cada país.
Flujo típico de autenticación y acceso en Open Banking (FAPI)
Registro del tercero (TPP)
El proveedor de servicios (AISP o PISP) se registra ante el regulador y la institución financiera, obteniendo credenciales y certificados para operar en el ecosistema.
Solicitud de consentimiento del usuario
El TPP redirige al usuario al portal de la institución financiera mediante OAuth 2.0 + OpenID Connect, solicitando acceso a datos o ejecución de pagos bajo un alcance (scope) definido.
Autenticación del usuario y validación del consentimiento
La institución financiera autentica al usuario (MFA) y valida explícitamente el consentimiento bajo el perfil FAPI, asegurando que el usuario autoriza los alcances solicitados.
Emisión de tokens con mTLS y firma JWS
Tras aprobar el consentimiento, el servidor de autorización emite tokens de acceso (y opcionalmente ID token) con autenticación mutua por certificado (mTLS) y mensajes firmados (JWS).
Acceso a endpoints REST estandarizados
El TPP utiliza el token para llamar a los endpoints REST de información de cuentas o iniciación de pagos, expuestos por la institución financiera según los estándares del regulador de cada país.
¿Cuáles son los componentes de una implementación de Open Finance?
Una implementación completa necesita cuatro piezas fundamentales para ser implementada:.
Piezas de una implementación completa de Open Banking
-
Capa de consentimientoGestión del ciclo de vida completo: creación, consulta, revocación y expiración del consentimiento del usuario.
-
Catálogo de APIs estandarizadasAPIs organizadas por categoría de dato: cuentas, tarjetas, crédito, inversiones y seguros.
-
Esquema de certificación de seguridadCumplimiento de estándares FAPI y OpenID para garantizar la autenticación y autorización segura entre participantes.
-
Marco de gobernanza técnicaDefine SLAs, límites de tráfico y métricas de disponibilidad para cada participante del ecosistema.
¿Los bancos cumplen la ley en el papel pero no su espíritu?
Brasil ofrece el caso más documentado de la región. Hasta octubre de 2025, el sistema evaluaba a cada institución con un modelo binario: cumple o no cumple. Desde entonces, la Associação Open Finance introdujo notas de 0 a 10 por categoría, con un piso mínimo de conformidad de 7. La nota promedio del ecosistema alcanzó ese piso por primera vez en abril de 2026, subiendo desde 5,98 en octubre de 2025.
La evolución no fue pareja. Los bancos digitales grandes mantuvieron notas consistentemente altas. Varios bancos incumbentes mejoraron de forma notable en seis meses. Pero un grupo de instituciones de tamaño medio permanece por debajo del mínimo exigido; en los casos más graves, la nota es cercana a cero, lo que significa que la mayor parte de sus APIs simplemente no está funcionando. Los nombres de esas instituciones todavía no son públicos, pendientes de aprobación del directorio de la asociación y del Banco Central.
Evolución de la nota de madurez del ecosistema Open Finance en Brasil
Pix Automático, el producto de pagos recurrentes construido sobre Open Finance, ilustra el problema con un solo número: su nota promedio es 5,2, muy por debajo del piso de conformidad, porque solo el 35 % de los consentimientos otorgados por los usuarios termina en un pago efectivamente ejecutado.
El cumplimiento mínimo fuera de Brasil
La realidad del ecosistema en otros paises presentan diferentes contrastes: desde el mínimo cumplimiento de la ley hasta casos de mala fe por parte de las instituciones financieras. El siguiente cuadro muestra con un poco más de detalle el ecosistema fuera de Brasil.
El patrón de cumplimiento mínimo fuera de Brasil
-
España (PSD2)La Asociación Española de Fintech e Insurtech (AEFI) reconoció públicamente que la mala calidad de una API puede deberse a falta de experiencia o presupuesto, pero también a que algunos bancos prefieren limitar deliberadamente el acceso de terceros. La propia directiva europea incorporó un mecanismo de respaldo —el fallback por screen scraping— precisamente porque anticipó ese incentivo.
-
México (Ley Fintech)El artículo 76 de la Ley Fintech de 2018 obligó a construir APIs estandarizadas, pero ocho años después la regulación secundaria para datos transaccionales y agregados —los que de verdad permiten competir— sigue sin publicarse.
-
Patrón regionalNinguno de estos casos prueba coordinación ni mala fe puntual de una entidad con nombre propio. Prueba algo más simple y más difícil de corregir con una multa: el Open Finance reduce el costo de cambiar de banco, y una API que cumple lo mínimo exigido logra frenar ese cambio sin infringir la ley.
¿Cómo se compara el estado del Open Finance entre los principales mercados de Latinoamérica?
Estado del Open Finance por país (2026)
| País | Estado regulatorio | Obligatoriedad | Hito reciente |
|---|---|---|---|
| Brasil | Consolidado, sistema más grande del mundo | Obligatorio para bancos grandes y medianos | ~117M de clientes y ~200M de consentimientos activos (mayo 2026) |
| México | Pionero (2018) pero incompleto | Obligatorio en datos abiertos; pendiente en transaccionales | Regulación secundaria del artículo 76 sin publicar tras 8 años |
| Colombia | Obligatorio desde 2026 | ~200 entidades supervisadas por la SFC | Decreto 0368/2026; transición extendida de 18 a 30 meses |
| Chile | Estándares técnicos finalizados | Obligatorio, implementación progresiva | Entrada en vigor pospuesta a julio de 2027 |
| Perú | Hoja de ruta publicada | Aún sin obligatoriedad | Primer grupo de datos habilitado a fines de 2027 |
| Argentina | Anuncio formal del BCRA | En fase de especificación técnica | Sin cronograma de obligatoriedad definido |
¿Cómo se implementa en la práctica una integración con Open Finance?
Implementación práctica paso a paso
Elegir el mercado y el marco vigente
Confirmar si el país tiene obligatoriedad activa (Brasil, Colombia) o solo voluntaria (Perú, Argentina) antes de comprometer fechas de lanzamiento.
Certificarse en el directorio de participantes
Completar el proceso FAPI/OpenID exigido por el regulador y registrar la aplicación como AISP, PISP o ambos.
Construir la capa de consentimiento
Implementar creación, consulta, revocación y expiración auditable, respetando el plazo máximo del país (365 días en Brasil, por ejemplo).
Validar en sandbox antes de producción
Probar contra el entorno de pruebas del regulador y, si es posible, contra al menos un banco de cada categoría de madurez conocida.
Instrumentar monitoreo propio por institución
Medir latencia, tasa de error y disponibilidad real de cada banco contraparte, sin depender solo del reporte oficial del regulador.
Definir una estrategia de degradación
Diseñar un comportamiento explícito —caché, reintento, mensaje al usuario— para cuando una institución no cumple el SLA esperado.
Revisar el changelog de versiones
Suscribirse a las notas de cambio de cada API bancaria consumida; los bancos de menor madurez suelen introducir cambios sin aviso previo suficiente.
Comparativa de rendimiento, coste, complejidad y escalabilidad
Integración directa vs. agregador vs. fallback por scraping
| Enfoque | Rendimiento | Coste | Complejidad de mantenimiento | Escalabilidad |
|---|---|---|---|---|
| Integración directa con APIs bancarias | Alto cuando el banco tiene score alto; variable en general | Bajo en licencias, alto en ingeniería propia | Alta — un cliente distinto por banco y por país | Buena a largo plazo, lenta de arrancar |
| Agregador (Belvo, Prometeo, Fiskil y similares) | Estable, normalizado entre bancos | Medio, con tarifa por conexión o por llamada | Baja — una sola integración para múltiples bancos | Rápida de escalar, con dependencia de un tercero |
| Fallback por screen scraping | Bajo, más lento y más frágil ante cambios de interfaz | Variable, puede encarecerse con el mantenimiento reactivo | Alta — requiere ajustes constantes | Limitada, pensada como respaldo temporal, no como base |
Tecnologías relacionadas
Piezas del ecosistema técnico
-
OAuth 2.0 / OpenID Connect + FAPIBase de autenticación y autorización exigida por prácticamente todos los marcos regulatorios de la región.
-
mTLS y JWSAutenticación mutua por certificado y firma de mensajes, obligatorias en los perfiles de seguridad más exigentes.
-
Agregadores de datos financierosBelvo, Prometeo y Fiskil, entre otros, ofrecen una capa normalizada sobre múltiples bancos y países.
-
Rieles de pago instantáneoPix en Brasil es el ejemplo más maduro de integración entre pagos instantáneos e iniciación vía Open Finance.
-
Observabilidad y API gatewaysHerramientas de monitoreo de latencia y disponibilidad, y gateways con rate limiting propio, son necesarias para operar con SLAs desiguales entre bancos.
¿Qué tendencias futuras existen?
Brasil sigue ampliando su modelo de monitoreo: ya incorporó un capítulo de desempeño por producto y prepara categorías de gobernanza de APIs y eficiencia del ecosistema, además de evaluar si hace pública la lista de instituciones con score bajo. Colombia y Chile, en cambio, siguen extendiendo plazos de transición, una señal de que la implementación técnica avanza más lento que la obligación legal. A mediano plazo, es probable que otros reguladores de la región adopten un modelo de nota de madurez similar al brasileño como mecanismo de presión pública sobre los bancos rezagados.
Glosario de conceptos clave
Glosario de conceptos clave
-
TPP (Third Party Provider)Empresa externa autorizada para acceder a datos financieros o iniciar pagos en nombre del usuario, previo consentimiento.
-
AISPAccount Information Service Provider — TPP especializado en consultar información de cuentas.
-
PISPPayment Initiation Service Provider — TPP especializado en iniciar pagos directamente desde la cuenta del usuario.
-
FAPI (Financial-grade API)Perfil de seguridad de OpenID Foundation diseñado para APIs financieras de alto riesgo, más estricto que OAuth 2.0 estándar.
-
Sandbox regulatorioEntorno de pruebas controlado que un regulador habilita para validar productos o integraciones antes de operar en producción.
-
Fallback mechanism (screen scraping)Mecanismo de respaldo que permite a un tercero acceder a datos mediante emulación de navegación cuando la API oficial no cumple el nivel de servicio exigido.
-
Nota de madurez / maturity scorePuntuación (0 a 10 en el modelo brasileño) que mide la calidad real de una institución en el ecosistema, calculada como la nota más baja entre todas sus categorías evaluadas, no un promedio.
-
SLA (Service Level Agreement)Compromiso técnico formal sobre disponibilidad, latencia y capacidad de respuesta que una institución debe cumplir frente a otros participantes.
Preguntas frecuentes
¿Existe en Latinoamérica un mecanismo de respaldo similar al screen scraping europeo?
No de forma generalizada. La región construyó sus marcos asumiendo las APIs como único canal, sin el mecanismo de fallback regulado que sí existe en PSD2, lo que deja a las fintechs sin alternativa formal cuando un banco no cumple el nivel de servicio esperado.
¿Qué riesgo tiene integrar solo contra bancos digitales y evitar a los incumbentes con score bajo?
Reduce la fricción técnica a corto plazo, pero limita la cobertura de mercado: los bancos incumbentes con score bajo suelen tener, de todas formas, bases de clientes grandes que un producto de agregación o scoring necesita alcanzar.
¿Cuánto tarda en promedio una integración de Open Finance desde cero hasta producción?
Varía por país y por número de bancos contraparte, pero equipos con experiencia previa suelen estimar entre tres y seis meses para la certificación, el consentimiento y las primeras integraciones estables, sin contar el tiempo de negociación regulatoria si aplica.
Conclusión: ¿cumplimiento real o resistencia disfrazada?
La evidencia disponible no permite acusar a una entidad puntual de sabotaje deliberado, y tampoco hace falta para explicar el patrón. El incentivo es estructural: el Open Finance existe para bajar el costo de cambiar de proveedor financiero, y ese es exactamente el costo que a un banco incumbente le conviene mantener alto. Cumplir la letra de la ley sin invertir en la calidad de la API logra ese objetivo sin infringir ninguna norma, y el caso brasileño —con instituciones que aprueban en el papel y fallan en la práctica— es la evidencia más cercana que la región tiene hasta ahora de que ese cálculo ya está ocurriendo.
Para equipos técnicos que construyen sobre esta infraestructura, la recomendación práctica es no diseñar para el marco regulatorio ideal, sino para el ecosistema real: con monitoreo propio, degradación explícita y una arquitectura que no dependa de que todos los bancos cumplan por igual. Quien ya evalúa cómo exponer o consumir datos financieros bajo un modelo de responsabilidad compartida puede revisar también nuestra cobertura sobre finanzas embebidas y Banca como Servicio (BaaS), donde se tratan los mismos riesgos de gobernanza desde el lado de la infraestructura bancaria.
¿Te gustó este artículo? ¡Compártelo y suscríbete!
