When people talk about open banking APIs, they usually jump to modern milestones: REST conventions, OAuth-based authorization, and regulations that pushed banks to enable customer-permissioned data sharing. But the deeper story—especially the part about financial data portability—starts earlier than most timelines acknowledge. It starts in the era when the Web itself was taking shape, roughly 1990 through 1994, when HTTP was young, browsers were new, and the concept of “an interface on the network” was being redefined.

This chapter sits in the chronological history of web APIs at an unusual moment: before “API” became common Web vocabulary, but after networked interfaces had already proven valuable in finance. The early 1990s introduced a deceptively simple idea that still anchors open banking today: a uniform way to request information using a URL, a standard protocol, and a predictable response format. Not yet JSON, not yet “developer portals,” but the blueprint was forming.

Before Web APIs, finance already had a data-sharing problem

In the early 1990s, consumer and small-business finance software was growing, and banks were already wrestling with a dilemma that sounds familiar today: customers wanted their data to move between systems. Long before open banking branding, there were practical needs:

• Personal finance tools needed transaction history and balances.
• Businesses needed account reconciliation and payment files.
• Banks needed ways to expose data without giving away internal systems.

But the dominant integration approaches were not “web APIs.” They were a mix of proprietary formats, file transfers, and institution-specific connectivity. In some cases, data access meant manual exports; in other cases, it meant scripts that logged in and collected data in fragile ways. Even when structured standards existed in broader electronic data interchange, they were not the same as the Web’s emerging “request/response” worldview.

So when the Web appeared, it didn’t merely add a new channel for publishing pages. It introduced a shared language for interaction. That language would later become essential for regulated financial data portability.

1990–1992: The Web’s minimal interface hints at a universal API

The earliest Web implementations prioritized one key abstraction: resources addressed by URLs and retrieved via a simple protocol. Early HTTP was intentionally small. Yet that smallness mattered for finance-like portability problems because it implied:

• Uniform addressing: a predictable way to “point to” a resource (an account summary, a statement, a rate sheet—conceptually).
• Uniform interaction: a standardized method of asking for that resource.
• Interoperability by default: if two parties speak HTTP and understand the same resource representation, they can integrate without bespoke networking stacks.

Even when the content was primarily HTML meant for humans, the interface model was already machine-friendly. The “API-ness” was hiding in plain sight: URLs, headers, and response bodies created a structured contract. You could imagine an automated agent requesting a resource, parsing it, and using it elsewhere. That is strikingly close to what financial aggregators would later do—first in crude ways, and later via official APIs.

1993: Browsers, servers, and CGI make the Web interactive

By around 1993, the Web shifted from a publishing system to an interaction platform. As widely distributed browsers and servers gained traction, the Web got an essential ingredient for API history: server-side programs that could accept inputs and generate outputs on demand.

This is where CGI (Common Gateway Interface) becomes historically important. CGI popularized a simple idea: the server receives a request, passes request metadata to a program, and returns output as an HTTP response. That “program behind a URL” pattern is one of the most direct ancestors of today’s web APIs.

In a finance context, this mattered because it hinted at a future where banks could expose:

• “Get balance” endpoints (not called that yet, but conceptually similar)
• “Search transactions” queries
• “Download statement” resources

At the time, most financial institutions were not deploying public HTTP interfaces for accounts. Security models were immature, and the idea of third-party access to accounts was politically and operationally fraught. Still, the Web’s interaction model gave the industry a new technical north star: standardize transport and concentrate complexity in application logic.

1994: A standards mindset emerges—and finance later borrows it

By roughly 1994, the Web community was increasingly oriented toward interoperability through standards. That cultural shift is as relevant to open banking as any specific protocol detail. Open banking depends on shared conventions: authentication patterns, data schemas, consent flows, and error semantics. Those expectations trace back to the Web’s early insistence that different systems should communicate through common rules rather than private agreements.

The Web standards ecosystem also clarified a long-term lesson for financial data portability: without stable interfaces, data access devolves into scraping and reverse engineering. In other words, if a bank doesn’t provide a supported interface, someone will approximate one anyway—often by automating a browser session and extracting what looks like data. In the early Web era, the tooling for automation began to look practical, because HTTP was accessible and consistent compared to many proprietary network stacks.

For a developer-oriented overview of the protocol lineage that made these interfaces possible, the W3C’s protocol hub is a helpful canonical reference: https://www.w3.org/Protocols/.

From “early HTTP interfaces” to “open banking APIs”: the continuity

It would be inaccurate to claim that open banking was “invented” between 1990 and 1994. It wasn’t. What happened instead is more subtle and more important for understanding API history:

1. The Web normalized networked self-service. People became used to retrieving information without calling someone or installing a custom client.
2. HTTP normalized generic clients. A single browser could talk to many servers. That concept later maps to a single fintech app connecting to many banks.
3. URLs normalized resource thinking. Once you can point to a “thing” on a network, it’s a short conceptual jump to pointing to an “account,” “transaction list,” or “beneficiary.”
4. Dynamic endpoints normalized automation. CGI-era patterns taught the industry that servers could compute results per request—exactly what account and payment APIs do today.

Financial data portability is essentially the right to (and practical ability for) a customer to direct their financial information from one system to another. The Web’s early interface model made the “practical ability” part believable at Internet scale.

The hidden tension: portability vs. safety

One reason the early 1990s matter for open banking history is that they introduced a tension we still live with: easy access versus controlled access. HTTP made it easier to expose information, but the security story lagged. If you can put data behind a URL, you also need to decide:

• Who can request it?
• How do you authenticate them?
• How do you prove the customer consented?
• How do you log and audit access?

Those questions became central to open banking decades later, but their roots are visible in this early period: the Web quickly made “connectivity” cheap, which forced “governance” and “security” to become first-class design requirements.

Why this era belongs in a web API history of open banking

If your mental model of API history starts with REST, you miss the deeper continuity. Open banking APIs are not just a fintech innovation; they are the financial sector adopting the Web’s oldest promise: interoperability through standard interfaces.

In practical terms, the 1990–1994 era contributed three enduring building blocks:

• Request/response as a universal interaction shape (later formalized and optimized, but already recognizable).
• Resource orientation (the habit of modeling “things” that can be retrieved, updated, or listed).
• Interface separation (the server owns data and logic; clients consume via a contract).

Those building blocks eventually made it possible for banks to publish stable, supportable interfaces instead of forcing customers and third parties into fragile, unofficial methods. If you’re tracking how these ideas evolve into modern automation and integration patterns, you may also want to browse related API and tooling discussions at AutomatedHacks.com.

FAQ: Early Web Interfaces and Open Banking API Origins