API and JSON in Banking: What They Actually Do (and What They Don't)

If you've spent any time around fintech, you've probably heard someone say "the API moved the money" or seen a screenshot of a JSON response treated as proof a transfer happened. Both are wrong — sometimes innocently, sometimes deliberately. This guide explains what APIs and JSON actually do in banking, where they sit in a bank's architecture, and where the real settlement happens. Glossary at the bottom so you can scan back when an acronym blurs together.

The Myth We Need to Kill First

Many customers — and a few con artists — talk about banking APIs as if they were money pipes. They aren't.

An API is a messenger, not a vault. It carries requests, responses, and information between software systems. When you press "send" in your banking app, the API tells the bank "the customer wants to move $1,000 to account X." That's a message, not a transfer. The actual movement happens deeper inside the bank, through tightly regulated channels — and only after compliance checks, account-level validation, and reconciliation with correspondent banks, RTGS, or RTP systems.

What an API Actually Is

API stands for Application Programming Interface. In plain English, it's a contract that says: "if you send me a request shaped like this, I'll respond with something shaped like that." It's how two pieces of software talk to each other.

In banking, that contract sits at the bank's digital edge. Mobile apps, internet banking portals, partner platforms, fintech aggregators — they all speak to the bank through APIs. The API authenticates them, validates the request, applies rate limits, and forwards the message inward. Crucially, it doesn't execute anything financial on its own.

Think of a banking API as a highly secure postal service:

• It accepts a letter (the request).
• It checks the sender is allowed to send it (authentication).
• It makes sure the envelope is well-formed (schema validation).
• It delivers the letter to the right department (routing).
• It carries a reply back to the sender (the response).

What it does not do is open the safe and hand out cash. That's a different system, behind several more doors.

Why APIs Never Touch the Ledger

Modern banks are built in three deliberately separated layers, and the API lives only in the outermost one.

Layer 1 — The Middle Layer (where APIs live)

This is the bank's digital front door: API gateways, authentication servers, data transformation, rate limiting. It's flexible, frequently updated, and talks to the outside world. It's also not allowed to hold financial state. Every transaction it sees gets handed off inward.

Layer 2 — The Core Banking System (CBS)

The operational engine. The CBS holds customer accounts, applies product rules (limits, fees, interest), executes transactions, and updates balances. It does not accept connections from the public internet — only from the middle layer, through narrow internal APIs.

Layer 3 — The Ledger Server

The authoritative double-entry record of every financial movement in the bank. Often physically separated, behind extra firewalls, with multi-factor authentication and hardware security modules. The ledger doesn't even talk to the middle layer — only to the core, and even then through tightly controlled interfaces. It is, by design, invisible from the outside.

This separation exists for six concrete reasons:

1. Isolation of sensitive data. Account balances and customer financial records never sit on an externally reachable system.
2. Minimised attack surface. Fewer connection points to the ledger means fewer doors an attacker can try.
3. Enhanced access control. The middle layer enforces rate limits, authentication, and authorisation before anything reaches the core.
4. Data integrity. Mistakes or malicious payloads can't directly corrupt the ledger — every change passes through validation in the layer above.
5. Regulatory compliance and auditing. A clear boundary between external requests and the ledger makes audit trails clean and traceable.
6. Systemic-risk reduction. A breach of an external API doesn't compromise the financial record itself.

JSON: The Language APIs Speak

JSON — JavaScript Object Notation — is just a way of writing structured data so two computers can read it the same way. It looks like this:

{
  "transactionRef": "TXN-2026-0515-AB12",
  "sender": { "iban": "DE89370400440532013000", "name": "ACME Holdings" },
  "beneficiary": { "iban": "FR1420041010050500013M02606", "name": "Globex SAS" },
  "amount": 12500.00,
  "currency": "EUR",
  "valueDate": "2026-05-15"
}

That's a payment instruction, written in JSON. Crisp, machine-readable, easy to validate. It describes a transfer. It does not, in any way, perform one.

What JSON is good at

• Carrying structured payloads between client apps and bank back-ends.
• Being human-readable enough that developers can debug it.
• Travelling cleanly over HTTPS, which makes it the natural pair for REST APIs.
• Mapping to ISO 20022 message types when a bank needs to bridge old MT-format SWIFT messages to modern rails.

What JSON cannot do

• Authorise a transaction.
• Move value.
• Substitute for compliance checks, account validation, or settlement.
• Serve as standalone proof that anything actually happened.

Because JSON is plain text, anyone with a keyboard can write a JSON document that looks like a successful transfer. Without the institutional infrastructure behind it — the bank's authorisation, the reconciled credit entry, the matching statement from the correspondent — the file is just text on a screen.

Instruction vs. Settlement

This is the same principle that comes up with SWIFT MT103 messages and ILP packets: a payment instruction is not a payment.

1. The customer (or partner app) sends an API request — a JSON payload — asking the bank to execute a transfer.
2. The middle layer validates and authenticates the request, then forwards it to the core.
3. The core applies compliance, sanctions screening, available-funds checks, and account-level rules.
4. If everything passes, the core books the debit on the sender's account and queues an outbound message to the settlement rail (SWIFT, SEPA, RTGS, an ILP connector, an instant-payments scheme, etc.).
5. The bank waits for confirmation from the rail and from the receiving bank's correspondent. Only now is the transfer final.
6. The ledger server records the final entries in double-entry form, and the API returns a final status to the original caller.

A JSON "success" response anywhere before step 5 is just confirmation that the instruction was accepted — not that the funds settled.

Types of Banking APIs

Not all banking APIs do the same thing. They fall into four broad families:

Core Banking APIs

Cover fundamental banking operations: opening accounts, deposits, lending, SME cross-border transactions. These are the most powerful APIs a bank exposes and are usually only available to partner institutions or licensed counterparties under strict agreements.

Plug & Play APIs

Tailored for specific financial operations like trading, accounting, and authentication flows (OAuth, OpenID Connect). Designed to drop into existing systems with minimal integration effort. Banks expose these to fintech partners building consumer-facing apps.

Cards, Wallets & Transfers APIs

Handle card issuing, multi-currency wallets, fraud monitoring, and transfer initiation. Common in neobanks and embedded-finance products.

Acquiring APIs

Focus on payment acceptance: mobile payments, NFC, online card acquiring, point-of-sale integrations. The merchant-facing side of payments.

REST vs. SOAP, Quickly

Banking APIs come in two architectural flavours.

REST (Representational State Transfer)

A lightweight style using standard HTTP verbs (GET, POST, PUT, DELETE) and usually JSON. Easy to consume from any language, scales well, and dominates modern public-facing APIs. Open banking, fintech, and most neobank products are REST + JSON.

SOAP (Simple Object Access Protocol)

An older XML-based protocol with built-in security (WS-Security), transactions (WS-Transaction), and rigorous schema enforcement. Heavier on the wire, more verbose, but still widely used in interbank messaging, legacy core banking integrations, and any environment where formal contracts and signed messages matter.

For day-to-day fintech work you'll almost always meet REST. For internal banking pipelines and ISO 20022 message exchange, you may still meet SOAP. Neither is "better" — they're tuned for different problems.

PSD2 and Open Banking

In Europe, the second Payment Services Directive (PSD2, in force since 2018) forced banks to expose specific APIs to authorised third-party providers (TPPs). Three categories matter:

• AISP (Account Information Service Provider) — read access to account data, with the customer's consent.
• PISP (Payment Initiation Service Provider) — initiate a payment on the customer's behalf, again with consent.
• CBPII (Card-Based Payment Instrument Issuer) — query whether sufficient funds are available for a card transaction.

PSD2 mandates Strong Customer Authentication (SCA) — usually a combination of something you know, have, and are — for any payment initiation or sensitive data access. The UK has its own Open Banking Standard, broadly aligned with PSD2; many other jurisdictions (Australia's CDR, Brazil's Open Finance, Saudi Arabia's Open Banking Framework, etc.) have adopted similar models.

These regulations matter because they define the shape of the APIs banks must expose, the security model behind them, and the liability rules when something goes wrong. They also reinforce a key point: APIs are conduits — institutional banks remain responsible for settlement.

How API Security Works in Practice

A banking API isn't just a URL. It's a layered stack of controls, all running before any request even reaches the core.

• Transport security. All traffic over TLS 1.2 or 1.3, often with Perfect Forward Secrecy and pinned certificates.
• Mutual TLS (mTLS). Both client and server present certificates, so the bank knows exactly which institution is calling.
• OAuth 2.0 / OpenID Connect. Standardised flows for delegated authorisation, used to issue short-lived access tokens scoped to specific operations.
• JWT (JSON Web Tokens). Signed, sometimes encrypted tokens that carry caller identity and permissions. Verified on every request.
• Rate limiting and throttling. Caps on requests per second to prevent abuse and protect downstream systems.
• Schema and input validation. Every JSON payload is checked against a strict schema before it's processed; malformed requests are rejected immediately.
• Web Application Firewalls (WAF). Block common attack patterns at the edge.
• Logging and anomaly detection. Every call is logged with a unique correlation ID; suspicious patterns trigger automated review and SAR (Suspicious Activity Report) workflows.
• Sanctions and AML screening. Each payment instruction is screened against OFAC, EU Consolidated, and UN lists before authorisation.

The API gateway sitting in the middle layer enforces all of this before a request is ever routed to the core. That's why an API can be exposed safely to the internet: by the time a malicious payload reaches a critical system, it's already been filtered, authenticated, and audited multiple times.

What You Can Actually Do With a Banking API

For a typical commercial-banking API exposed to authorised clients, the common operations are:

• Payment initiation — submit an outbound transfer instruction (single or batch).
• Balance enquiry — fetch current and available balances.
• Transaction history — retrieve historical statements with filters by date, amount, counterparty.
• Beneficiary management — add, update, and remove approved beneficiaries.
• FX quoting — request a foreign-exchange rate and reservation.
• Status polling / webhooks — track the lifecycle of a submitted payment, from accepted to in-flight to settled.
• Account information — IBAN/BBAN validation, account name verification, sort-code lookups.

Each one is a JSON request/response over HTTPS. None of them moves money on its own. The payment-initiation endpoint, for example, returns an immediate acknowledgement; the actual settlement happens through SWIFT, SEPA, an RTGS, or an internal instant rail and reports back asynchronously — often via a webhook that delivers the final status hours or sometimes days later.

Why a JSON Payload Is Not Proof of Payment

This deserves its own section because it's the most common place people get fooled.

JSON is human-readable text. Anyone can construct a document that looks like a successful banking response — same field names, same status codes, same timestamps. There is no cryptographic guarantee in the file itself that the bank ever saw it.

Even a real JSON response from a real bank only confirms what the API saw at that moment. Common pitfalls:

• "status: ACSC" (AcceptedSettlementCompleted, an ISO 20022 status) means the sending bank has settled its side. It does not by itself prove the receiving bank has credited the beneficiary.
• A 200 OK from a payment-initiation endpoint usually means the instruction was accepted for processing, not that money has moved.
• A signed webhook proves the bank sent the message — but the message can still be reporting a pending or in-flight transfer.

Verification is anchored in two places, always:

1. The receiving bank's ledger, showing a credit entry to the beneficiary account.
2. The matching settlement statement from the correspondent or RTGS, reconciled to the original instruction via a UETR (Unique End-to-End Transaction Reference) or ISO 20022 message ID.

Without both, no real transfer has occurred. A JSON payload alone is suggestive — not conclusive.

Glossary

Quick definitions for the terms and acronyms used above. Skim this section any time something feels foggy.

• API (Application Programming Interface) — a contract by which one piece of software talks to another. In banking, the bank's digital front door.
• JSON (JavaScript Object Notation) — a lightweight, text-based data format for structured payloads.
• REST (Representational State Transfer) — an architectural style for APIs using HTTP verbs, usually paired with JSON.
• SOAP (Simple Object Access Protocol) — an older XML-based protocol with built-in security and transactional features.
• HTTPS / TLS — encrypted transport for web traffic. TLS 1.3 is the current standard.
• mTLS (Mutual TLS) — both ends of a connection present certificates, so each verifies the other's identity.
• OAuth 2.0 — a delegated-authorisation framework; the basis for "log in with..." flows and most open-banking access.
• OpenID Connect (OIDC) — an identity layer on top of OAuth 2.0.
• JWT (JSON Web Token) — a signed token that carries claims (identity, permissions, expiry) in JSON form.
• API gateway — the component in the middle layer that authenticates, validates, and routes incoming API traffic.
• WAF (Web Application Firewall) — filters incoming HTTP traffic to block common attack patterns.
• SCA (Strong Customer Authentication) — a PSD2 requirement combining two or more factors (knowledge, possession, inherence).
• PSD2 — the EU's second Payment Services Directive; the legal basis for European open banking.
• AISP / PISP / CBPII — PSD2 third-party-provider roles for reading accounts, initiating payments, and checking card funds.
• ISO 20022 — a modern international standard for financial messages, replacing legacy SWIFT MT formats.
• PACS.008 / PACS.009 — ISO 20022 customer credit transfer and FI-to-FI credit transfer messages.
• UETR (Unique End-to-End Transaction Reference) — a unique ID used to track a payment through every hop.
• Middle layer — the bank's API and integration hub, where external traffic enters and is filtered.
• CBS (Core Banking System) — the bank's central processing engine that holds accounts and applies business rules.
• Ledger server — the most isolated layer; holds the authoritative double-entry record of every financial movement.
• RTGS — Real-Time Gross Settlement, a central-bank-run rail for settling each payment in real time.
• SEPA — Single Euro Payments Area; the EU's harmonised euro-payment scheme.
• SWIFT MT103 — a customer credit transfer instruction over the SWIFT network. An order, not a settlement.
• Webhook — a callback URL the bank invokes asynchronously when a payment status changes.
• AML / KYC / KYB — Anti-Money Laundering / Know Your Customer / Know Your Business compliance checks.

FAQ

Summary

APIs and JSON together power the modern digital-banking experience, but their role is narrower than it sometimes appears.

• An API is a messenger between software systems. It does not move money.
• JSON is the data format the messages are written in. It does not authorise, hold, or settle value.
• Banks expose APIs only at the middle layer — the outermost of three deliberately separated layers. The core and ledger sit behind extra walls.
• Banking APIs fall into four broad families: core banking, plug & play, cards/wallets/transfers, and acquiring. Open banking APIs (PSD2, UK OBS, and equivalents) are a regulated subset.
• REST + JSON dominates modern APIs; SOAP + XML still appears in interbank and legacy contexts.
• Security is layered: TLS, mTLS, OAuth, JWT, rate limiting, schema validation, WAFs, sanctions screening — all before a request reaches the core.
• A JSON response is never standalone proof of payment. Real settlement is confirmed by reconciled ledger entries and matching statements from correspondent banks or RTGS systems.

If a single sentence helps it stick: APIs and JSON are how a bank's systems talk; settlement is how money actually moves — and the two are never the same thing.