The headlines on open banking in LATAM focus on dates: Mexico’s LRITF, Brasil’s phased Open Finance, Chile’s SBIF framework. The interesting story is what happens inside an incumbent bank that needs to comply — not because the API specs are hard, but because the institution was never designed to expose its own data on someone else’s schedule.

The four readiness dimensions that actually matter

Technical readiness is necessary but not sufficient. We assess clients across four dimensions: API surface (can your core systems even expose the required endpoints with the required SLAs?), identity and consent (do you have a working customer identity layer that supports granular, revocable consent?), data governance (do you know which fields are in scope, which are derived, which are protected by other regulations?), and operating model (when a fintech partner has an outage, who in your bank handles it?).

Most incumbents have a plan for #1 and #2. Few have one for #3 and #4. The institutions that struggled in the early Brasilian phases were not the ones with weaker APIs — they were the ones whose operations teams had no playbook for partner-driven failures.

Why Salesforce + MuleSoft is not the same as open banking

We say this gently because we deliver both: having Salesforce Financial Services Cloud and MuleSoft does not make you open-banking-ready. It makes you well-positioned to become ready, but the open banking journey adds three layers that those platforms alone do not provide.

First, the consent management layer. Open finance regimes require customer-driven, time-bound, revocable consent at the data-element level. Out-of-the-box CRM consent is not granular enough.

Second, the certified API gateway with regulator-recognized authentication (FAPI, OIDC FAPI-CIBA, mTLS depending on jurisdiction). MuleSoft can host this but the configuration must match the local regulator’s technical spec exactly.

Third, the auditable event log. Every consent grant, every API call, every data element transmitted must be reconstructable years later. This is a data lake problem, not an application problem.

The operating model gap

The most common stall pattern we see: a bank builds technically compliant APIs, passes the regulator audit, and then watches usage stay near zero for 18 months. Why? Because the customer-facing experience of granting consent is buried six clicks deep in the mobile app, and the partner-onboarding process is run by a legal team that takes 90 days to review each fintech.

Open banking only delivers business value when the bank treats partner enablement as a product, not a compliance project. That means dedicated developer experience, sandbox access in under an hour, a partner success team, and SLAs that fintechs can actually rely on. None of this is in the regulation. All of it determines whether you are a hub or a backwater in your market’s ecosystem.

A 90-day pragmatic plan

Days 0-30: API surface audit, identity layer review, consent architecture design. Output: technical gap list with sizing.

Days 30-60: build the certified API gateway pilot (one product area), implement consent management, set up the auditable event log. Output: working sandbox, ready for partner onboarding.

Days 60-90: onboard 2-3 friendly fintechs, run end-to-end consent flows, validate against regulator spec. Output: regulator-ready submission plus a partner onboarding playbook.