Introduction: What is happening to the traditional bank?

For over a century, traditional banks operated as a “one-stop-shop.” If you needed a checking account, a mortgage, a credit card, a stock trading account, and a way to send money overseas, you went to one single building and used one single institution.

Today, that model is being torn apart. Modern financial technology is driven by a concept called Unbundling, and the technological engine making this possible is the API (Application Programming Interface).

To understand why this is happening now, we must look at the 2008 Global Financial Crisis. Following the crash, public trust in traditional, monolithic banks plummeted. At the same time, the first smartphones were released, training a new generation of consumers to expect flawless, instant digital experiences. Traditional banks, burdened by heavy regulations and ancient computer systems, could not keep up. This created a massive gap in the market for agile tech companies to step in.

1. The Concept of “Unbundling” the Bank

The Swiss Army Knife Analogy: A traditional bank is like a Swiss Army Knife. It has a knife, a screwdriver, a corkscrew, and scissors all in one tool. It is convenient because it is all in one place, but the scissors on a Swiss Army knife are usually small and clumsy compared to a real, dedicated pair of scissors.

FinTechs looked at the bank and decided to “unbundle” it. Instead of trying to be a Swiss Army Knife, a FinTech company focuses on being just one tool, but making it the absolute best tool in the world.

• Remittances (Cross-Border Transfer): Instead of using your bank to send money overseas (which relies on the ancient, slow SWIFT network and carries hidden exchange rate markups), a FinTech like Wise focuses only on cross-border payments. They use local bank accounts in every country to bypass international wires entirely, making transfers instant and cheap.
• Payments & Merchant Services: Instead of a small business spending weeks setting up a clunky merchant account with a traditional bank and renting expensive credit card terminals, they use Stripe or Square. These companies focus only on processing card payments online or via simple mobile dongles seamlessly.
• Investing & Wealth Management: Instead of using a traditional bank’s expensive stockbroker who charges $10 per trade, users download Robinhood or Wealthsimple, which focuses only on intuitive, commission-free trading.
• Lending (Credit): Instead of filling out reams of paperwork for a bank loan, FinTechs like SoFi (for student loans) or Affirm (for “Buy Now, Pay Later” point-of-sale loans) use alternative data algorithms to approve credit in seconds.

By breaking the bank into specialized, vertical slices (unbundling), FinTechs offer a vastly superior user experience. But how do all these separate apps talk to each other to move your money around without a central bank building? The answer is the API.

2. Deep Dive: What is an API?

API stands for Application Programming Interface. In simple terms, an API is a software messenger. It allows two completely separate computer systems to talk to each other, ask for information, and send data back and forth securely, without needing to know how the other system is built. A developer building an iPhone app doesn’t need to know how a bank’s massive IBM mainframe works; they just need to know how to talk to the bank’s API.

The Restaurant Waiter Analogy: Imagine you are sitting at a table in a restaurant.

• You (The Client App): You know what you want to eat, but you are not allowed to walk into the kitchen to cook it yourself.
• The Kitchen (The Bank’s Server/Database): The kitchen has all the ingredients (data) and the chefs (processing power) to make your meal, but they don’t know what you want until someone tells them.
• The Waiter (The API): The waiter is the API. You give your order (a Request) to the waiter. The waiter takes your order to the kitchen. The kitchen prepares the food. The waiter then brings the food (the Response) back to your table.

In FinTech, when you open a personal finance app and it automatically shows your live bank balance, the app is acting as the customer. It sends a “waiter” (an API) to your bank’s servers, asks for your balance, and brings that data back to display on your screen.

3. The Mechanics of an API: How Software Communicates

To understand FinTech, you must understand how APIs actually communicate over the internet. The standard architecture used globally is called REST (Representational State Transfer). If an API follows these rules, it is called a RESTful API.

(Note: Before REST, banks used a clunky, heavy technology called SOAP/XML. REST revolutionized the web because it is lightweight, fast, and uses minimal bandwidth, which is essential for mobile banking apps.)

When an app sends an API Request, it consists of four main parts:

1. The Endpoint (The Address) Just like a website has a URL (like www.google.com), an API has a specific URL called an endpoint. These are highly structured. For example, a bank might have an endpoint specifically for checking balances: https://api.bank.com/v1/accounts/balance.
2. The HTTP Method (The Action) The app must tell the API exactly what action it wants to perform. It does this using standard HTTP verbs:

• GET: Ask for data. (e.g., “GET my account balance.”)
• POST: Create new data. (e.g., “POST a new transaction” or “Create a new user profile.”)
• PUT / PATCH: Update existing data. (e.g., “PATCH a new home address on my profile.”)
• DELETE: Remove data. (e.g., “DELETE my connected credit card.”)

1. The Header and the Payload (The Details)

• Headers: This contains invisible metadata. Most importantly, it contains the security credentials (API Keys or Tokens) proving the app has permission to ask for this data. It also tells the server what type of device is making the request.
• Payload (Body): If you are sending a POST request to transfer money, the API needs details. The payload will contain the amount of money, the destination account number, and the routing number.

1. JSON (The Universal Language) When the API brings the data back (the Response), it needs to be in a format that any computer can easily read. The global standard is JSON (JavaScript Object Notation). JSON organizes data into simple, hierarchical “Key-Value” pairs.

Example of a nested JSON response from a bank API:

JSON

{

  “user_id”: “98765”,

  “account_type”: “Checking”,

  “currency”: “USD”,

  “balance”: 1500.50,

  “status”: “Active”,

  “recent_transaction”: {

      “date”: “2026-07-29”,

      “merchant”: “Starbucks”,

      “amount”: -4.50

  }

}

 

It is lightweight, logically nested, easy for human developers to read, and effortless for a computer app to parse and display on your screen.

1. Status Codes (The Result) When the API returns the response, it includes a three-digit code telling the app if the request was successful or if it failed.

• 200 Level (Success): E.g., 200 OK (The balance was retrieved successfully) or 201 Created (A new account was successfully opened).
• 400 Level (Client Error): E.g., 400 Bad Request (You forgot to include the amount you want to transfer), 401 Unauthorized (Your API key is invalid), or 404 Not Found (The account number doesn’t exist).
• 500 Level (Server Error): E.g., 500 Internal Server Error (The bank’s database crashed) or 503 Service Unavailable (The bank is doing maintenance).

1. Advanced API Concepts: Rate Limiting & Webhooks

• Rate Limiting (Throttling): Banks cannot let a single app ask for data a million times a second; it would crash their servers (a DDoS attack). Therefore, APIs use Rate Limiting. If an app asks for data too fast, the API returns a 429 Too Many Requests status code, forcing the app to pause.
• Webhooks (Asynchronous APIs): Sometimes an action takes a long time (like verifying a passport for KYC). Instead of the app constantly asking the API “Is it done yet? Is it done yet?” (called Polling), FinTechs use Webhooks. A webhook is essentially a reverse API. The app tells the bank, “Here is my phone number. Don’t call me, I’ll call you.” When the passport is verified, the bank’s server automatically sends a message to the app letting it know.

4. How APIs Create “Banking-as-a-Service” (BaaS)

Because APIs make it so easy for systems to connect, it has created a massive disruption called Banking-as-a-Service (BaaS).

Historically, starting a bank required hundreds of millions of dollars in capital reserves and years of strict regulatory approval to get a banking charter. This made it impossible for small tech startups to enter the finance world.

Today, established, licensed banks (often smaller, regional banks) have realized they can make money by renting out their banking license via software. They build APIs that allow other companies to use their banking infrastructure in the background. This is called a “white-label” service.

The Three Layers of the BaaS Stack:

1. The Brand (The App): This is the company the customer actually interacts with (e.g., Uber, Apple, or a specialized startup). They design the beautiful user interface and handle marketing.
2. The Middleware (The BaaS Provider): Companies like Stripe, Unit, or Treasury Prime write the complex API code that acts as a bridge between the modern app and the ancient bank.
3. The Sponsor Bank (The License Holder): A real, federally regulated bank (like Green Dot Bank, Evolve Bank & Trust, or Celtic Bank) that actually holds the physical money, ensures FDIC insurance, and handles regulatory compliance.

Example in the Real World: Apple offers the “Apple Card.” Apple is a hardware and software company; it is not a bank. Beneath the beautiful titanium card and iPhone app, Apple uses BaaS APIs to connect to Goldman Sachs (the sponsor bank). Goldman Sachs does all the underwriting and holds the debt. Apple just designs the interface. This API model allows any company (retailers, airlines, tech companies) to instantly embed financial services into their products without ever becoming a real bank.

5. Open Banking and The API Economy

The ultimate evolution of the API is Open Banking.

In the past, banks hoarded your financial data. They believed that your transaction history belonged to them, not you.

The Dark Ages: Screen Scraping Before Open Banking, if you wanted to use an early budgeting app (like Mint), the app forced you to type in your actual bank username and password. The app’s servers would then log into your bank website pretending to be you, read the HTML on the webpage, and scrape the text off the screen to figure out your balance. This was incredibly slow, prone to breaking every time the bank redesigned its website, and wildly insecure.

The Open Banking Revolution Open Banking is a regulatory framework (most famously mandated in Europe under a law called PSD2 – Payment Services Directive 2).

• The law fundamentally shifted data rights: it states that financial data belongs to the customer, not the institution.
• It legally forced all traditional banks to abolish screen scraping and instead build secure, standardized, dedicated APIs.
• If a customer gives explicit permission, the bank must allow a third-party FinTech app to access the customer’s data via these secure APIs.

This regulatory shift has created the API Economy—an interconnected web where apps, banks, and services plug into each other instantly. We are now moving beyond Open Banking toward Open Finance, which mandates API access not just for checking accounts, but for mortgages, pensions, investments, and insurance, creating a unified, customer-centric financial ecosystem.

6. Securing the API (OAuth 2.0 and Cryptography)

If APIs are constantly moving highly sensitive financial data across the public internet, how are they secured? As we established, you cannot give a FinTech app your bank username and password.

The industry-standard solution is a security framework called OAuth 2.0 (Open Authorization) combined with mTLS (Mutual Transport Layer Security).

The Valet Key Analogy (OAuth 2.0): When you give your car to a valet at a hotel, you don’t give them your master key (which opens the trunk, the glovebox, and the doors). You give them a “Valet Key”—a restricted key that only lets them turn on the engine and park the car within a 1-mile radius for a limited time.

OAuth 2.0 works exactly the same way in software:

1. The Request: You want to connect a budgeting app to your bank.
2. The Redirect: The app does not ask for your password. Instead, it securely redirects your web browser directly to your actual bank’s website.
3. The Consent: You log into the bank (the app never sees this happen). A screen appears from your bank asking, “Do you authorize this budgeting app to read your balance?”
4. The Token Issuance: When you click “Yes,” the bank generates a JSON Web Token (JWT). This token is the valet key. The bank hands this token to the budgeting app.
5. Secure Access: The app can now attach this Token to the Header of its API Requests.

Why Tokens are Secure:

• Scoped Access: The Token has strict cryptographic rules baked into it. It is “scoped” to only allow “READ” access. If the budgeting app gets hacked and a cybercriminal tries to use the token to initiate a “POST” request to transfer money, the bank’s API will instantly reject it (401 Unauthorized).
• Time-Limited: Tokens expire. Usually, after 90 days, the token destroys itself, and you must re-authenticate the connection.
• Revocable: You can log into your bank at any time and click “Revoke Access.” The token is instantly voided, immediately severing the FinTech app’s connection to your data without you having to change your bank password.