top of page

API-First Banking: The Technical Foundation of Open Finance

  • Writer: WAU Marketing
    WAU Marketing
  • Mar 17
  • 4 min read

Updated: 3 days ago

"We already have APIs." It's the answer we hear most when we ask whether an institution is ready for Open Finance. And it almost always means the opposite of what they think.


Having an API isn't being API-first. They're two different things, and the difference decides whether your institution will compete in open banking or watch from the sidelines. Because Open Finance isn't a feature you add: it's an architecture. And if your core wasn't born for it, no patch will fake it.


Let's start with the law, not the trend


In Mexico, Open Finance isn't a trend: it's a mandate. Article 76 of the Fintech Law requires financial entities to share their clients' information through standardized application programming interfaces—APIs. Read it again: the regulatory obligation is, literally, an obligation to have APIs. Without standardized APIs there is no Open Finance; there's non-compliance.


The first provisions were published in June 2020 and apply to more than 2,400 entities in the financial system—not just banks. For now they cover the open-data layer, but the direction is clear, and Mexico has a trait no one else in the region shares: it lets providers charge for access to their APIs, since they must publish and register with the CNBV the compensation amounts for the exchange of data, as the law firm Holland & Knight documents. In other words, a well-built API isn't just compliance; it can be a revenue source.


What "API-first" really means


Here's the distinction almost no one gets right. API-first—also called "contract-first" or "design-first"—means the API contract is designed before the code. First you define the interface: what data goes in, what comes out, how it behaves. Then you build the system around that contract. The API isn't an output of the system; it's the starting point.


The opposite—what most have—is a core built its own way, onto which APIs get "bolted on" years later to connect it to the world. It works in a demo. It fails in production, because those APIs inherit every limitation of the core beneath them.


The gateway mirage


This is the most expensive trap we see. An institution puts an API gateway in front of its legacy core, exposes a few endpoints, and declares victory: "we're API-first now." It isn't. It's worth separating three concepts that often get confused:


  • The API gateway is a traffic controller: it routes requests, balances load, authenticates. Tactical, useful, but only a door.

  • API management is the whole lifecycle: versioning, analytics, governance, developer portal. The gateway is one piece within it.

  • API-first is neither. It's a design methodology. The gateway and management expose and manage APIs that already exist; API-first determines how those APIs are born.


The uncomfortable point: putting a gateway on a monolithic, batch core does give you APIs, yes—but APIs that don't run in real time, that break when you touch the system, that drag the coupling underneath. You painted the façade; the house is still the same.


Why a legacy core doesn't deliver quality APIs


Two concrete technical reasons. First, batch processing: legacy systems accumulate operations to process them in windows—overnight, hourly—making it impossible to expose data in real time. An API on a batch core hands you yesterday's balance, not today's. Second, tight coupling: in a monolith, everything is intertwined; changing one component forces you to touch and re-test the rest. Each new API is a project, and each project, a risk.


The contrast in scale says it all. In the UK, where Open Banking has matured, the ecosystem processed more than 24 billion successful API calls in 2025, 27% more than the year before, according to Open Banking Limited. In Brazil, calls surpassed 100 billion in 2024, per The Paypers. Globally, Open Banking call volume is projected to top 720 billion by 2029, according to Juniper Research. That traffic doesn't run on batch cores with bolted-on APIs; it runs on architectures designed, from the start, to speak through APIs.


How we see it at WAU


At WAU we don't put an API layer on your legacy core and tell you you're ready for Open Finance. We design—or redesign—the core with an API-first mindset: contract first, capabilities exposed in real time, decoupled, ready to comply with Article 76 and, along the way, to monetize access. The difference between a dressed-up API and a real API-first one is the difference between complying on paper and competing for real.


If you want to know whether your architecture is truly API-first or just has a gateway on top, let's talk. We'll tell you straight and map the route. 👉 Book a conversation with our team.


Sources


Comments

bottom of page