Los titulares sobre open banking en LATAM se enfocan en fechas: LRITF de México, Open Finance fasado de Brasil, marco SBIF de Chile. La historia interesante es qué pasa dentro de un banco incumbente que debe cumplir — no porque las specs de API sean difíciles, sino porque la institución nunca fue diseñada para exponer su propia data en el horario de otro.

Las cuatro dimensiones de readiness que importan

La readiness técnica es necesaria pero no suficiente. Evaluamos a los clientes en cuatro dimensiones: superficie de API (¿tus sistemas core pueden exponer los endpoints requeridos con los SLAs requeridos?), identidad y consentimiento (¿tienes una capa funcional de identidad de cliente que soporte consent granular y revocable?), gobierno de datos (¿sabes qué campos están en scope, cuáles son derivados, cuáles están protegidos por otras regulaciones?) y modelo operativo (cuando un fintech partner tiene un outage, ¿quién en tu banco lo maneja?).

La mayoría de incumbentes tienen plan para #1 y #2. Pocos para #3 y #4. Las instituciones que sufrieron en las fases tempranas brasileñas no fueron las de APIs más débiles — fueron aquellas cuyos equipos de operaciones no tenían playbook para fallas de partners.

Por qué Salesforce + MuleSoft no es lo mismo que open banking

Lo decimos suavemente porque entregamos ambos: tener Salesforce Financial Services Cloud y MuleSoft no te hace open-banking-ready. Te deja bien posicionado para llegar, pero la jornada open banking agrega tres capas que esas plataformas solas no proveen.

Primero, la capa de gestión de consentimiento. Los regímenes de open finance exigen consent customer-driven, time-bound y revocable a nivel de elemento de dato. El consent out-of-the-box de CRM no es lo suficientemente granular.

Segundo, el API gateway certificado con autenticación reconocida por el regulador (FAPI, OIDC FAPI-CIBA, mTLS según jurisdicción). MuleSoft puede hostearlo pero la configuración debe matchear exactamente la spec técnica del regulador local.

Tercero, el log de eventos auditable. Cada otorgamiento de consent, cada API call, cada elemento de dato transmitido debe ser reconstruible años después. Esto es un problema de data lake, no de aplicación.

La brecha del modelo operativo

El patrón de atasco más común que vemos: un banco construye APIs técnicamente compliant, pasa la auditoría del regulador, y luego observa que el uso queda cerca de cero por 18 meses. ¿Por qué? Porque la experiencia customer-facing de otorgar consent está enterrada seis clics adentro de la app móvil, y el proceso de partner-onboarding lo lleva un equipo legal que tarda 90 días por cada fintech.

Open banking solo entrega valor cuando el banco trata el partner enablement como producto, no como proyecto de compliance. Eso significa developer experience dedicado, acceso a sandbox en menos de una hora, equipo de partner success y SLAs en que los fintechs realmente puedan confiar. Nada de esto está en la regulación. Todo determina si eres hub o periferia en el ecosistema de tu mercado.

Un plan pragmático de 90 días

Días 0-30: auditoría de superficie de API, revisión de capa de identidad, diseño de arquitectura de consent. Output: lista de gaps técnicos con sizing.

Días 30-60: construir el piloto de gateway certificado (un área de producto), implementar gestión de consent, montar el log auditable. Output: sandbox funcional, listo para partner onboarding.

Días 60-90: onboard 2-3 fintechs amigables, correr flujos end-to-end de consent, validar contra spec del regulador. Output: submission regulator-ready más playbook de partner onboarding.