From voluntary to mandatory: an open finance platform for a mid-sized Colombian bank

The situation

A mid-sized Colombian bank offered current accounts, cards and small business loans. It had taken part in the earlier, voluntary open finance scheme in a limited way: a few partner integrations, each built separately, with its own consent screens and its own security setup. Customer data lived in a core banking system, a card platform and a lending system, each with a different idea of what a "customer" was.

Why now. Decree 368 of 2026 made open finance mandatory for institutions supervised by the Financial Superintendence of Colombia (SFC), replacing the voluntary framework¹. Supervised entities must act as both data providers and data receivers, and data can only flow with the customer's prior, express and informed consent². The common technical standards are left to the SFC, and commentary on the decree sets out a deadline in October 2026 for the SFC to publish its schedule for them, with a period for institutions to comply after each standard is issued³. The bank had to start building before the details were final.

What had to be true

• One consent model for every data flow, out and in, that customers can see and revoke.
• Standards-ready APIs: a canonical internal model that can be mapped to the SFC standards as they arrive.
• Financial-grade security for every third party, with no bespoke partner setups.
• Measurable reliability: availability and latency per endpoint, because the regulator will publish indicators.
• Useful received data: data from other institutions available to credit and product teams, with purpose recorded.

Architecture

The data flow, end to end

The hard part: building to standards that do not exist yet

The decree sets the framework, but the technical standards come later¹³. Waiting meant missing the window; building to a guess meant rework. The team separated what was certain from what was not.

Security was the most certain. Open finance schemes around the world converge on financial-grade API profiles, so the authorisation server was built to the OpenID Foundation's FAPI 2.0 Security Profile, with sender-constrained tokens and strong client authentication⁴. Whatever the local profile adds, most of that work carries over.

Data formats were the least certain. Instead of exposing internal systems directly, the team built a canonical model of customers, accounts, cards and loans, fed by change data capture from each source system. The public API shapes became a thin mapping layer on top. When the SFC publishes a standard, the change lands in the mapping, not in three core systems. More on that pattern in change data capture and event streams and data contracts.

Reliability had to be measurable from day one, because the SFC must publish indicators on the system². The gateway emits a trace for every call, so availability and latency can be reported per endpoint and per participant, and a slow downstream system shows up in the trace rather than in a complaint⁵.

How it ran

Key decisions and trade-offs

What I'd do again, and differently

Again: treat the receiver side as a product, not a compliance task. Data from other institutions is what makes open finance worth the cost, as the Brazilian lender found when it used consented data in credit decisions. Differently: start participant onboarding earlier. Technical integration was faster than agreeing testing and support arrangements with other institutions. Related: idempotent financial pipelines and where I work.

If you are preparing for open finance in Colombia or elsewhere in Latin America, see my fractional CTO work, or analyse your challenge and bring the result to a call.