Ledger to Ledger (L2L) Transfers and the Interledger Protocol (ILP): A Plain-English Guide

"Ledger to Ledger" sounds intimidating, but the idea is simple: every bank, payment app, and even every blockchain keeps a list of who owns what. When value moves between two of those lists, that's an L2L transfer. The mechanics behind it — correspondent banks, MT103 messages, nostro accounts, ILP packets — are where things get dense. This guide unpacks them in plain English, with a glossary at the end so you can scan back when an acronym blurs together.

What L2L Actually Means

L2L is short for Ledger-to-Ledger. It describes moving value between two separate ledgers — and there are two very different flavours of it depending on whether you're in traditional banking or in blockchain.

In traditional banking

A ledger is just a record-keeping system. A bank's ledger tracks every account, every balance, every credit and debit. When money moves from your account to someone else's, no physical cash is teleported anywhere. The bank simply adjusts entries: your balance goes down, theirs goes up. If the two accounts are at the same bank, that's an intra-bank L2L. If the two ledgers belong to different banks, that's an inter-bank L2L — and it requires the global banking system to coordinate.

In blockchain

The same idea applies, but the ledgers are distributed. Moving value from one blockchain to another (say, Bitcoin to Ethereum, or a CBDC pilot to a stablecoin network) requires specialised tools: atomic swaps, cross-chain bridges, or interoperability protocols like ILP. The principle is identical — one ledger decrements, another increments — but the trust model and tooling differ.

The Three Layers Behind Every Bank

Before going further, it helps to picture the inside of a modern bank. Banks don't run on one big system — they run on three deliberately separated layers, each with its own job and its own security posture.

1. The Middle Layer (API and Integration Hub)

This is the bank's digital front door. It's where mobile apps, internet banking, partners, and external networks plug in. The middle layer authenticates requests, translates between data formats (JSON, XML, ISO 20022), enforces rate limits, and routes incoming traffic. It's flexible, modern, and frequently updated — but it doesn't move money on its own.

2. The Core Banking System (CBS)

This is the operational engine. The CBS holds customer accounts, applies product rules (interest, fees, limits), processes transactions, and updates balances in real time. Vendors you may have heard of include Temenos T24, Finastra Fusion, Oracle FLEXCUBE, FIS Profile, and Mambu. The CBS is more stable and more guarded than the middle layer — and importantly, it isn't directly reachable from the outside world.

3. The Ledger Server (the bank's book of truth)

This is the most isolated layer of all. The ledger server keeps the authoritative double-entry record of every financial movement at the institution — debits balance credits, always. It generates regulatory reports, supports the chart of accounts, and is often deployed in a physically separate data centre, behind extra firewalls, with multi-factor authentication and hardware security modules. It does not talk to the internet. Period.

Why Funds Can't Be "Downloaded"

A common misconception — often spread by scams — is that you can somehow "download" funds from a bank's ledger or core server. You can't. Here's why:

• The ledger and core systems are not internet-facing. They sit behind multiple network boundaries and only accept requests through narrowly defined internal interfaces.
• Funds aren't files. There is no folder called /balances/ sitting on a hard drive that anyone could copy. A balance is an entry in a tightly controlled database, protected by encryption at rest, integrity checks, and audit logging.
• Every change to that database has to be paired with a corresponding entry elsewhere (double-entry accounting). You can't increase your balance without simultaneously decreasing someone else's — and that someone else has to actually agree.

Real fund movement always passes through the regulated framework of the global banking system. The integrity of every transaction depends on that — and so does compliance with anti-money-laundering and sanctions rules.

Instructions vs. Actual Settlement

This is the single most important concept in the whole article. Banking has two distinct things that beginners often confuse:

1. A payment instruction — a message saying "please move X amount from account A to account B."
2. Settlement — the actual change in cash balances between the institutions involved.

A SWIFT MT103 message, for example, is an instruction. So is an MT202. They tell the receiving bank: "funds are coming, here's the beneficiary, here's the amount." On their own, they move nothing. The receiving bank doesn't credit the beneficiary just because an MT103 arrives — it waits for confirmation that real money hit its correspondent account first.

Correspondent vs. Intermediary Banks

When two banks want to exchange money across borders, they usually don't trade dollar bills. Instead, they hold accounts with each other. Two terms come up constantly.

Correspondent bank

A correspondent bank holds a direct, bilateral account (called a nostro account from the sender's perspective, or vostro from the holder's) for another bank. These accounts have real cash balances. When Bank A wants to pay someone in Bank B's country, it can debit its nostro account at Bank B — actual money already sitting there — and credit the beneficiary.

Intermediary bank

If Bank A and Bank B have no direct correspondent relationship, the payment has to be forwarded through one or more intermediary banks that do have those relationships. Intermediaries route the funds along the chain, handle currency conversions, and produce their own SWIFT confirmations along the way.

How a Bank Confirms Funds Really Arrived

Modern core banking systems don't trust an instruction — they trust reconciled confirmations. Here's the simplified workflow when an inbound payment arrives.

When a correspondent bank is involved

1. Instruction arrives. The CBS receives the MT103 or MT202 and stores it in a holding area (a "suspense" ledger). Nothing is credited yet.
2. Nostro statement comes in. The bank's correspondent sends an automated account statement — usually an MT940 (intraday) or MT950 (end-of-day) — showing actual credits to the bank's nostro account.
3. Reconciliation. The CBS matches the SWIFT instruction to the credit entry using a UETR (Unique End-to-End Transaction Reference). Same reference, same amount, same date? It's a match.
4. Final credit. Only now does the CBS credit the beneficiary's customer account.

When an intermediary bank is involved

Routing is slightly more layered:

1. CBS receives the MT103 (the original instruction).
2. The intermediary issues an MT910 (Confirmation of Credit) or a follow-on MT202, telling the receiving bank that funds were credited to its nostro at the next hop.
3. The correspondent bank then sends its own MT940/MT950 confirming the cash actually landed.
4. The CBS pieces all of these together via the UETR and only then credits the client.

This process is automated by software like SmartStream TLM, SAP FS-CD, Oracle Flexcube, and Temenos Recon, with SWIFT gpi providing real-time tracking. AML and sanctions screening run on every message. The probability of a CBS misposting is typically below 0.1%.

What the Interledger Protocol (ILP) Is

Now that you understand how traditional bank settlement works, ILP is easier to place.

The Interledger Protocol is an open protocol — originally proposed by engineers at Ripple, now maintained as a community standard — that lets payments hop across different ledgers without any of them having to be the same kind. Bank ledgers, blockchains, mobile money systems, prepaid networks: ILP doesn't care, as long as each ledger has a "connector" that speaks the protocol.

How ILP transfers work, roughly

An ILP transfer is a chain of conditional packets. Each connector along the route prepares a small transfer with a cryptographic condition. If the next hop fulfills its condition within a time window, the transfer locks in. If not, the whole chain reverses — automatically. This is similar in spirit to the Bitcoin Lightning Network's HTLCs (hashed time-locked contracts), but ledger-agnostic.

For very small payments, ILP uses STREAM, which chunks a payment into many tiny packets to discover route capacity and minimise loss. Settlement is fast — often sub-second — and supports streaming micropayments down to fractions of a cent.

Where ILP sits in a bank

When a bank exposes an ILP gateway, it almost always sits in a hardened middle-layer connector, not on the core. External traffic uses BTP/STREAM over TLS 1.3; once a packet is fulfilled, the connector converts it into a normal ISO 20022 message (PACS.008 or PACS.009) and hands it off to the bank's internal payment rails. No ILP socket ever touches the core ledger directly — that segregation satisfies NIST SP 800-53 boundary protection rules and Basel III operational risk expectations.

Important nuance

ILP "fulfilment" is not the same as legal settlement. Even when an ILP packet is cryptographically released, the bank still has to settle the corresponding fiat leg through TARGET2, an RTGS, or a correspondent nostro before the customer's balance is finally updated. ILP coordinates; it does not replace the underlying settlement rails.

Other Modern Payment Rails

ILP is one option among several. Different corridors, currencies, and regulatory regimes favour different rails. Here's a tour of the main ones.

SWIFT gpi Instant

An overlay on top of national instant-payment schemes. Funds land in seconds, 24/7, while still using the familiar MT 103 / ISO 20022 messaging banks already speak. No new tokens, no new infrastructure — just upgraded SWIFT pipes. Best when broad global bank coverage matters more than novelty.

SEPA Instant Credit Transfer (SCT Inst)

The European Payments Council's standard for euro transfers. Guarantees that funds arrive in under ten seconds, anywhere in the SEPA zone, up to €100,000 per transfer, 24/7/365. For pure euro corridors this beats ILP because there's no FX spread and it settles natively on TIPS (TARGET Instant Payment Settlement). It's also mandatory under the EU's Instant Payments Regulation — banks operating in the EU have to support it.

RTGS.global

A newer initiative that does atomic Payment-versus-Payment (PvP) across central-bank RTGS platforms in milliseconds. Both legs of an FX trade settle simultaneously, eliminating Herstatt (settlement) risk entirely. Where ILP still needs post-fulfilment nostro reconciliation, RTGS.global bonds both legs in a single atomic instruction.

RippleNet / xCurrent

Ripple's bilateral messaging and settlement orchestration suite. Some LATAM and APAC banks are Ripple-native, in which case xCurrent is a turnkey way to interoperate. Settlement can occur on the XRP Ledger or via traditional nostros, giving treasury teams choice based on jurisdiction.

Mojaloop

An open-source reference implementation for inclusive instant-payments systems, especially in emerging markets. It actually uses ILP under the hood, but adds directory services and quoting on top to optimise for low-value mobile remittances. Aligned with UN Sustainable Development Goal 8.10 (universal access to financial services).

On the roadmap

• Wholesale CBDC corridors — the BIS Innovation Hub is piloting multi-CBDC bridges that combine PvP atomicity with central-bank money.
• ILP-over-QUIC — a draft transport profile that reduces handshake latency.
• Tokenised deposit networks — bank-issued on-chain euros settled via smart contracts (e.g. RLN Europe).

Which Rail Should You Use?

Different priorities pick different rails. A quick cheat sheet:

• ILP — when you need multi-asset streaming, micropayments, or programmable conditional payments across heterogeneous ledgers.
• SWIFT gpi Instant — when you want maximum bank coverage with minimal integration overhead.
• SEPA Instant — for euro-only corridors under ECB supervision.
• RTGS.global — when eliminating bilateral PvP risk is the board's number-one priority.
• RippleNet — when counterparties are already Ripple-native or XRP liquidity gives FX advantage.
• Mojaloop — for low-value, inclusion-focused remittances in emerging markets.

Glossary

Quick definitions for the acronyms and jargon used above. Skim this section any time a term gets fuzzy.

• CBS (Core Banking System) — the bank's transaction-processing engine that holds customer accounts and applies business rules.
• Correspondent bank — a bank that holds a direct cash account (nostro/vostro) for another bank to settle cross-border payments.
• Intermediary bank — a transit bank that forwards payments when sender and receiver have no direct correspondent relationship.
• Nostro account — "our account at your bank." Holds real cash in a foreign currency on your behalf.
• Vostro account — "your account at our bank." The mirror image of a nostro from the other side.
• MT103 — a SWIFT message: customer credit transfer instruction. An order to pay, not a confirmation of payment.
• MT202 — a SWIFT message: financial-institution-to-institution funds transfer.
• MT910 — SWIFT confirmation of credit. Tells the receiving bank funds were posted to its nostro at the next hop.
• MT940 / MT950 — automated bank statements (intraday / end-of-day) showing real account activity.
• UETR — Unique End-to-End Transaction Reference. A unique ID SWIFT assigns to every payment so it can be tracked through the chain.
• ISO 20022 — a modern international messaging standard for payments, gradually replacing legacy MT formats.
• PACS.008 / PACS.009 — ISO 20022 message types for customer credit transfer and financial-institution credit transfer respectively.
• RTGS — Real-Time Gross Settlement. A central-bank-run system that settles each payment individually and in real time.
• TARGET2 / TIPS — the Eurozone RTGS system (TARGET2) and its instant-payments cousin (TIPS).
• ILP — Interledger Protocol. An open protocol for routing conditional payments across heterogeneous ledgers.
• STREAM — an ILP transport layer that breaks a payment into many small packets for reliability and route discovery.
• BTP — Bilateral Transfer Protocol. The ILP wire format used between two connectors.
• Suspense ledger — a temporary holding account where inbound funds sit until reconciliation completes.
• Double-entry accounting — every transaction creates equal-and-opposite entries (debit/credit) so the books always balance.
• KYC / AML / KYB — Know Your Customer / Anti-Money Laundering / Know Your Business. The compliance checks every regulated payment goes through.
• PvP — Payment-versus-Payment. Both currency legs of an FX trade settle simultaneously, eliminating settlement risk.
• HSM — Hardware Security Module. Tamper-resistant hardware for cryptographic operations and key storage.

FAQ

Summary

L2L transfers are about coordinating updates across two ledgers — that's it. The complexity comes from how banks actually do that safely:

• Banking runs on three separated layers — middle, core, ledger — each with its own job and security posture.
• Funds can't be "downloaded" from a bank; balances change through coordinated double-entry edits, not file transfers.
• SWIFT messages like MT103 are instructions, not settlements. Real settlement is confirmed by separate statements (MT940/MT950) and credit confirmations (MT910).
• Correspondent banks settle directly; intermediary banks route when no direct relationship exists.
• ILP is a modern protocol that routes conditional payments across heterogeneous ledgers, sitting in the middle layer alongside other rails like SWIFT gpi Instant, SEPA Instant, RTGS.global, RippleNet, and Mojaloop.
• The right rail depends on the corridor, currency, and risk priorities — most large banks run several in parallel.

If a single sentence helps it stick: An L2L transfer is two ledgers agreeing to change at the same time — and every protocol and acronym above exists to make that agreement fast, accurate, and provably real.