Mechanics of Interbank Fund Transfers

Interbank fund transfers are the lifeblood of the global financial system, enabling money to move securely between banks across different networks and countries. This process is complex, involving standardized message protocols, correspondent banking arrangements, and highly secure settlement systems. In this report, we examine how interbank transfers operate in practice, detailing the communication networks, the actual movement of funds through accounts, the security architecture protecting bank ledgers, and the institutional frameworks that uphold these processes. Each component – from SWIFT messages to central bank real-time gross settlement – plays a distinct role in ensuring that large sums of money can be transferred efficiently, accurately, and safely.

Messaging Systems and Protocols

Interbank transfers begin with the exchange of electronic payment instructions between banks. These instructions are carried by dedicated messaging systems and protocols that ensure all parties interpret payment details uniformly. It is crucial to note that these messaging networks carry information, not actual funds – they communicate payment orders, while the actual money moves through a separate settlement process. Below we explore major messaging systems and their protocols, including SWIFT and SEPA, as well as legacy or alternative communication channels.

The SWIFT Network and Message Types

The Society for Worldwide Interbank Financial Telecommunication (SWIFT) is the dominant global network for bank-to-bank financial messaging. SWIFT provides a secure standardized format for sending payment orders, statements, and other financial communications among over 11,000 institutions in more than 200 countries . Importantly, SWIFT transmits messages only – it does not transfer actual funds or maintain accounts for members . In other words, a SWIFT message is an instruction (often called a “wire transfer message” or payment order) that tells banks how to settle a payment; the settlement (the actual movement of money) occurs via debit/credit entries in accounts as described later.

Common SWIFT MT Messages: SWIFT messages are categorized by type (MT = Message Type). Key examples relevant to fund transfers include:

• MT 103/pacs.008 – Single Customer Credit Transfer: This is the standard message for cross-border transfers initiated by a customer. An MT103 is sent from the sending bank to the beneficiary’s bank to instruct the crediting of the beneficiary’s account for a specified amount. It contains details of the payer, beneficiary, and payment (amount, currency, value date, etc.). An MT103 is essentially the payment order from one bank to another on behalf of a customer.
• MT 202 COV/pacs.009 – Cover Payment Instruction: The MT202 COV is a bank-to-bank transfer message used to move funds between correspondent banks in support of an underlying customer payment . In a cross-border transfer where an intermediary (correspondent) bank is involved, the originating bank sends an MT103 to the beneficiary’s bank (to inform them of the incoming payment) and simultaneously sends an MT202 COV through the chain of correspondent banks to actually cover the funds. The MT202 COV carries only interbank settlement information (no retail customer data) but crucially includes references to the underlying MT103 so that intermediaries can perform compliance checks . This “cover” method allows faster credit to the beneficiary while the funds “catch up” via the correspondent network. (Prior to 2009, a standard MT202 was used for cover payments, but the enriched MT202 COV became mandatory to improve transparency of originator and beneficiary details for AML purposes .)
• MT 910/campt.054 – Confirmation of Credit: This is an advice message to confirm that an account has been credited . For example, when a correspondent bank receives funds on behalf of a beneficiary bank, it may send that beneficiary bank an MT910 to notify them that their account (nostro/vostro) was credited with the funds. The MT910 serves as a real-time notification of incoming money. (Similarly, an MT 900 is a debit confirmation advice for account debits .)
• MT 940 – Customer Statement Message: An MT940 is an end-of-day (or intraday) account statement sent by a bank to an account holder (which could be a corporate or another bank) detailing all transactions. In the context of fund transfers, a bank receiving funds might later send an MT940 to a corporate customer to report the credit on their account. This message type is for reporting/accounting rather than initiating a transfer.

SWIFT messages are highly standardized and encoded according to strict format specifications, which ensures that all parties interpret the payment data consistently. They include fields for originator, beneficiary, amounts, currency, dates, and references, among other details. For security, SWIFT messages travel over a closed network and use authentication protocols between banks. Historically, banks communicated international payment instructions via telex before SWIFT existed – a method known as Key Tested Telex (KTT). KTT was much slower and required manual verification of code words (“test keys”) to authenticate messages. SWIFT was conceived in 1973 as an answer to those flaws . Today, SWIFT’s infrastructure boasts robust encryption, authentication, and redundancy, making it a trusted backbone for international payments.

It is important to stress that a SWIFT MT103 or MT202 message does not itself move money – it is essentially a standardized electronic letter instructing a debit and credit. As one compliance resource succinctly puts it: “SWIFT is solely a messaging system. It does not perform any type of settlement between financial institutions.” . Settlement of the payment occurs via the transfer of funds across accounts (such as correspondent accounts or central bank accounts, discussed in the next section). This distinction is important: SWIFT and similar systems carry the instructions, and separate mechanisms actually transfer value .

Note: SWIFT is in the process of migrating from the older MT format to the newer ISO 20022 MX format for many of its messages. In ISO 20022 terminology, for example, a pacs.008 message is equivalent to an MT103 (customer credit transfer) and pacs.009 to an MT202 (financial institution transfer). The MT202 COV’s ISO equivalent is often referred to as pacs.009 COV, and a camt.054 message can serve a similar role as an MT910 (credit notification). This migration aims to enrich the data content and improve interoperability across systems, but the fundamental purpose of the messages remains the same.

SEPA Credit Transfer Systems (SCT and SCT Inst)

In addition to SWIFT, which is global, many regions have their own interbank payment messaging frameworks. In Europe, the Single Euro Payments Area (SEPA) initiative harmonized electronic euro payments across the EU and several other countries. Under SEPA, two key credit transfer schemes exist for bank transfers in EUR:

• SEPA Credit Transfer (SCT): The “classic” SEPA credit transfer, launched in 2008, is a non-urgent electronic payment from one bank account to another in the SEPA zone. SCTs are often used for everyday transactions like salaries, invoices, or person-to-person transfers. They typically settle on a same-day or next-business-day basis. In practice, an SCT payment initiated by a customer is processed by the sending bank and dispatched through a clearing network (often an automated clearing house) to the receiving bank. By rule, the funds must be credited to the beneficiary by the next business day at the latest. In many cases it happens within hours or sooner, but SCT is not real-time – transactions are batch-processed. Settlement for SCTs is usually done by netting many payments and settling the net positions among banks via a central bank (for example, the pan-European clearing system STEP2 nets SCT transactions and then settles the net balance via the ECB’s TARGET2 RTGS system ).
• SEPA Instant Credit Transfer (SCT Inst): Implemented in 2017, this is an instant payment scheme in euros. SCT Inst enables transfers that are processed in seconds on a 24/7 basis, with funds made available to the recipient almost immediately at any time (even nights, weekends, holidays) . The scheme guarantees that within 10 seconds of the payer initiating the transfer, the payer’s bank and beneficiary’s bank will communicate and the beneficiary’s bank will have either credited the funds or sent a failure notification . To achieve this speed, SCT Inst transactions are processed individually (not in batches) and typically settle in real-time or near-real-time. For example, the Eurosystem’s TIPS platform (TARGET Instant Payment Settlement) allows participating banks to settle each instant payment in central bank money within seconds. Other intermediaries like EBA Clearing’s RT1 system use a pre-funded account model to ensure immediate finality. The key point is that SCT Inst payments are both messaged and settled almost instantly, giving finality of payment to the end-users within seconds. (By contrast, a legacy SCT might take until the next day, as noted – “basic SCTs take at least one business day to complete… so SCT Inst is a huge improvement.” )

Both SCT and SCT Inst use ISO 20022 XML messaging formats defined by the European Payments Council. From an end-user perspective, the main differences are speed and availability. From a bank’s perspective, the difference lies in how the payments are cleared and settled: SCT goes through batch clearing with deferred net settlement, whereas SCT Inst uses continuous or immediate settlement. It’s worth noting that not all European banks immediately joined the SCT Inst scheme; adoption has been growing, and regulators (the European Commission and ECB) have pushed for wider participation to make instant payments ubiquitous across Europe .

Other Communication Channels: KTT, S2S, and IP-to-IP, Telefax, Phone, written communication, etc.

Aside from mainstream systems like SWIFT and SEPA, there are other channels and protocols through which banks can exchange payment instructions. These range from legacy methods to bespoke connections:

• Key Tested Telex (KTT): Before electronic networks like SWIFT were widespread, banks relied on telegraphic telex systems for international payments. KTT is a form of authenticated telex messaging where a test key (a sequence of numbers/letters) was exchanged in the message to verify the sender’s identity. Even today, in some regions with limited SWIFT access, “institutions often rely on the secure and efficient KTT protocol for critical information exchanges with trusted counterparts”. KTT messages would often mirror the content of SWIFT MT forms (e.g. containing fields equivalent to an MT103 or MT202) but sent via telex lines. This method is largely obsolete in major corridors but can serve as a backup or alternative in certain scenarios. It is slower and more manual, with higher operational risk, which is why SWIFT effectively supplanted it by the late 20th century .
• Server-to-Server (S2S) integrations: This refers to direct connections between banks’ computer systems to exchange payment files or messages, without using an intermediary network like SWIFT. Many large banks and corporates set up host-to-host file transfers or APIs to send payment instructions directly in bulk. For example, a corporate treasury might send a batch payment file directly to its bank’s server for processing, or two banks that frequently do business might establish a secure VPN link to send payment instructions to each other. These S2S connections typically still use standardized formats (perhaps ISO 20022 XML or JSON APIs), but they ride on internet protocols between the institutions. S2S arrangements are private and require both sides to implement compatible technology. In practice, even S2S links often ultimately rely on established clearing/settlement networks (for example, two banks might send files to each other but still settle the payments via an ACH or RTGS). The advantage of S2S is automation and speed for high-volume bilateral information or instruction exchanges (no need to manually input or rely on a third-party network), but the disadvantage is that each connection can be bespoke and requires strong security measures.
• IP-to-IP Transmission: This term “IP-to-IP” generally implies sending payment instructions directly from one bank’s IP address to another’s, over the internet, without an intermediary messaging hub. It is essentially a variant of S2S, emphasizing the use of internet protocol connectivity. Pure IP-to-IP bank transfers are not common or recommended in the industry due to security and standardization concerns . While any two servers on the internet can technically exchange data, banks typically prefer to use established networks (SWIFT, secure ACH networks, etc.) that have governance, encryption, and counterparty authentication frameworks in place. An unauthenticated IP-to-IP message could be vulnerable to hacking or might not be legally recognized. Therefore, direct IP transmissions tend to be limited to very closed groups or within a banking group’s internal network. As one observer noted, “IP to IP transfers can be less secure compared to established banking networks, such as SWIFT or ACH, which implement multiple layers of security, encryption, and authentication” . In summary, while the internet underpins most modern communication (even SWIFT now uses IP-based transport), banks do not usually just “send a payment to an IP address” without layering it in the proper financial messaging standards and security protocols.

In all cases above – whether SWIFT MT messages, SEPA XML messages, or even a direct host-to-host file – the communication’s purpose is to convey the payment instruction from the sending bank to the receiving bank (and any intermediaries). The next question is how the banks actually move the money to fulfill that instruction. That is where the funds movement architecture comes into play.

Funds Movement Architecture

Once the payment instructions are exchanged via messaging, the banks must settle the corresponding funds. Settlement can occur through different mechanisms depending on the type of payment: via correspondent banking accounts or via central bank-operated settlement systems (or a combination of both). We will explain how correspondent banking works (nostro/vostro accounts at intermediary banks) and how high-value payments are often settled in real-time by central banks. We will also touch on how clearinghouses and net settlement operate for bulk or retail payments. Throughout, the principle is that for every debit there must be an equal credit somewhere in the banking system – and settlement is the process that ensures each bank ultimately records the necessary debits/credits on the correct balance sheets.

Correspondent Banking: Nostro/Vostro Accounts and Intermediaries

For international payments, it is not feasible for every bank in the world to hold accounts at every other bank. Instead, banks maintain accounts with a smaller number of correspondent banks in key financial centers or jurisdictions. A correspondent bank is an intermediary that holds deposits of other banks and services payments between them. If Bank A in country X needs to pay Bank C in country Y, it may use Bank B (a correspondent that has relationships with both) to facilitate the transfer. This arrangement requires maintaining accounts on each other’s books:

• Nostro and Vostro: These are two sides of the same coin referring to a correspondent account. “Nostro” is Latin for “ours” and refers to our money held by you. From Bank A’s perspective, its account at Bank B (in foreign currency or in B’s jurisdiction) is Bank A’s nostro account. Bank B would call that same account a vostro account (Latin “yours”) on its own ledger – i.e. “your money held by us” (Bank A’s funds held by Bank B). Essentially, a nostro account is an asset of the account holder (claim on correspondent), while a vostro account is a liability of the correspondent (owed to the account holder) . Correspondent banks also sometimes use the term loro account (“theirs”) to refer to accounts of a third party held by another bank, but this term is less common.

How funds move via correspondents: Suppose an Originating Customer at Bank A (in New York) wants to send $10,000 to a Beneficiary Customer at Bank C (in a country where Bank A has no branch). Bank A will find a route, perhaps through its correspondent Bank B (in London), which in turn may have a relationship with Bank C. 

The sequence might be:

1. Debit the Originator’s account at Bank A for $10,000 (plus any fees). This reduces the payer’s balance and is the initial step in the transfer .
2. Credit Bank A’s Nostro account at Bank B. On Bank A’s books, it will reduce its USD balance (if sending USD) and increase its due from Bank B (nostro) account for the amount (this may be done via an internal ledger entry often called a “mirror account” representing Bank B’s funds on Bank A’s ledger) . In effect, Bank A is earmarking $10k that will now be owed by Bank B.
3. Send a payment message to Bank B. Bank A uses SWIFT (or another network) to send an instruction to Bank B, such as an MT202 COV, stating: “Please debit our account (Bank A’s nostro) with you by $10,000 and credit Bank C’s account (the beneficiary’s bank) with you by $10,000.” This message may reference an underlying MT103 that Bank A sent to Bank C to advise the details of the beneficiary, etc. At this stage, no money has actually left Bank B – it’s just an instruction pending in Bank B’s queue.
4. Debit Bank A’s Account at Bank B (Nostro/Vostro). Upon processing the instruction, Bank B will deduct $10,000 from Bank A’s nostro account on Bank B’s books . Now Bank A’s balance at Bank B is $10k lower, meaning Bank A effectively has $10k less claim on Bank B. From Bank A’s perspective, the obligation has been passed to Bank B.
5. Credit Bank C’s Account at Bank B. Still at Bank B, they now credit Bank C’s correspondent account (vostro) with $10,000 . Bank C likely maintains a USD account with Bank B (if Bank C regularly deals in USD). So Bank B’s liability to Bank C increases by $10k. At this point, Bank B has effectively moved the funds from Bank A’s account to Bank C’s account internally. If Bank C also did not have a direct account at Bank B, there could even be multiple correspondents (nested) but we’ll assume one intermediary for simplicity.
6. Send payment message from Bank B to Bank C. Bank B now sends a message (e.g., MT202 or MT103 depending on context) to Bank C: “We have credited your account with $10,000 on behalf of Bank A for ultimate beneficiary [Customer]. Please credit the beneficiary’s account.” . This message tells Bank C that funds are available in their vostro at Bank B, ready to be credited to the end recipient.
7. Debit Bank B’s Account at Bank C (if one exists). This step is somewhat reciprocal to step 4, if Bank C also holds an account with Bank B in Bank C’s currency. However, in our scenario Bank C has received the funds in USD at Bank B, so step 7 in the BIS diagram refers to debiting Bank B’s “mirror” account at Bank C – essentially an accounting entry if needed. In practice, if Bank C simply had its USD nostro at Bank B credited, there may not be a need for Bank C to debit an account for Bank B. The BIS example shows a symmetric arrangement (each has accounts with the other), but either way, Bank C will record that it has an extra $10k claim on Bank B now (which it will likely transfer out or use).
8. Credit the Beneficiary’s account at Bank C. Finally, Bank C credits the local currency account or USD account of the Beneficiary Customer, making the funds available to the recipient . Bank C now owes $10k to that customer (liability on its books), balanced by the fact it has $10k more due from Bank B or already received from Bank B (asset). The payment is complete from the perspective of the customers.

If we trace the liquidity: originally the $10k was in Bank A (deducted from originator). After completion, the $10k is in Bank C (credited to beneficiary). In between, Bank B’s accounts served as conduits: Bank A’s claim on Bank B decreased, Bank C’s claim on Bank B increased. No physical cash moved; it was all ledger entries across these institutions. The SWIFT messages (or other network messages) orchestrated these ledger updates in a synchronized way.

The above scenario is a serial correspondent banking chain (A → B → C). Sometimes multiple intermediaries are involved, especially if the banks do not have direct relationships (nested correspondents). Each intermediary will debit the account of the prior bank and credit the account of the next bank in the chain, based on the instructions. Each step requires trust: correspondents take on credit risk of the banks whose funds they hold. That’s why banks carefully choose correspondent relationships and perform due diligence (a nostro account is effectively an unsecured loan of funds to the correspondent) .

Now, correspondent transfers can be settled solely via banks as above (Bank B directly moves funds to Bank C), or correspondents might use a central payment system for part of the route. For example, perhaps Bank B and Bank C are both members of a major currency’s RTGS system (explained next). In that case, instead of step 5-7 occurring internally at Bank B, Bank B might send the $10k to Bank C via a payment system like Fedwire or TARGET2. The BIS graphic we cited illustrates this alternative as “B. Involvement of payment system” . In scenario B, steps would be:

• 5. Bank B sends a payment message into a payment system (eg. an RTGS) to transfer $10k from Bank B to Bank C .
• 6. That payment system settles the transfer (likely by debiting Bank B’s central bank account and crediting Bank C’s central bank account).
• 7. The payment system sends a message to Bank C that $10k has been settled in its account .
• 8. Bank C then credits the beneficiary’s account .

Either route achieves the same end: Bank C gets the money and credits the beneficiary. Correspondent banking is thus a mix of account relationships and message exchanges. The correspondent handles the currency settlement for banks that are not local in that currency. For instance, USD payments around the world often funnel through New York correspondents; Euro payments through banks in the Eurozone, etc. Correspondent banks keep the global system connected, but at the cost of additional layers (time, fees, compliance checks). Modern initiatives like SWIFT gpi aim to improve transparency and speed in correspondent banking by tracking payments end-to-end.

To summarize, correspondent banking enables cross-border transfers by using intermediaries. Each transfer results in a series of debits/credits across nostro/vostro accounts. The messaging (SWIFT MT103/202 COV, etc.) coordinates these actions. Table: Key Stages in a Correspondent Transfer (A→B→C) (see figure 1 below).

Real-Time Gross Settlement (RTGS) Systems – TARGET2, Fedwire, CHAPS, etc.

While correspondents handle many cross-border payments, for high-value domestic currency payments, banks typically use RTGS systems run by central banks. Real-Time Gross Settlement means that payments are settled individually, one by one, in real-time, with finality (irrevocable) once processed . “Gross” indicates no netting – each transaction stands on its own. Central banks operate RTGS systems to settle interbank obligations in central bank money, eliminating credit risk between banks for those payments.

Examples of RTGS systems include:

• Fedwire Funds Service (USA): Operated by the U.S. Federal Reserve, for USD payments. Banks that hold accounts at the Fed can instruct transfers from their Fed account to another bank’s Fed account. Fedwire transactions are final and irrevocable as soon as they are executed by the Fed’s system . Fedwire is often used for large-value transactions like interbank loans, corporate payments, settlements of securities trades, etc. (in 2024, Fedwire processed on average hundreds of billions of dollars daily).
• TARGET2 (Eurozone): Until 2023, TARGET2 was the RTGS for the euro, operated by the Eurosystem (ECB and national central banks). It processed high-value payments in EUR and settlement for clearing systems. TARGET2 has since been succeeded by a new RTGS system called simply “T2” in 2023, but the function remains the same: real-time settlement of interbank euro transfers. TARGET2/T2 settles not only interbank transfers but also provides the backbone for settling net positions from other systems (like SEPA clearings). All major Eurozone banks (and many non-Euro central banks via links) participate, as it’s critical for monetary policy operations and large-value payments .
• CHAPS (UK): The RTGS system for GBP, operated by the Bank of England. It handles large sterling payments, settling across accounts at the Bank of England. Like others, payments are final upon execution.
• Others: Almost every country has an RTGS for its currency (often with names like Canada’s LVTS/LYNX, Japan’s BOJ-NET, India’s RTGS, etc.). These systems typically operate during business hours of the local central bank, and participating institutions must fund their accounts to cover outgoing payments (intraday credit may be provided by the central bank under certain conditions).

RTGS systems are used for both high-value transfers and any time immediate finality is needed. A key feature is that settlement happens in central bank money, which carries no default risk (central bank can always create its currency). So if Bank A pays Bank C $10 million via Fedwire, the Fed debits A’s reserve account and credits C’s reserve account – the money is now an asset of Bank C at the central bank. This eliminates the exposure that would exist if Bank A just promised to pay later. As a result, RTGS payments are considered final settlement. By contrast, in correspondent banking, Bank C might wait to use funds until it’s sure Bank B actually received from Bank A, etc., introducing a slight settlement risk lag.

One can see RTGS as the plumbing that often underlies other systems. For instance, at the end of the day an ACH clearing may settle net positions through an RTGS (the Fed’s ACH settles over Fedwire; Europe’s STEP2 SEPA clears settle over TARGET2 ). Even in correspondent chains, sometimes the final leg is an RTGS transfer (as scenario B earlier). Thus RTGS is a cornerstone of interbank settlement. “Most real-time gross settlement systems are operated by a country’s central bank… Each transaction is settled on an individual basis without netting… Once completed, the payment is final and irrevocable.” . This direct real-time settlement drastically reduces systemic risk for large payments but requires participants to have sufficient liquidity at the central bank.

Deferred Net Settlement and Clearing Systems (ACH, CHIPS, and Faster Payments)

Not all payments are processed one-by-one; many systems collect payment instructions and settle the net amount at intervals. This is efficient for high-volume, lower-value payments (like payrolls, utility payments, card payments, etc.), as it economizes on liquidity. However, it introduces settlement delay and interbank credit risk in the interim. Two important types of such systems are ACH networks and certain real-time payment systems that use deferred settlement.

• ACH (Automated Clearing House): ACH systems are batch clearing networks for electronic payments, typically used for direct deposits, bill payments, and other recurring transactions. In the US, for example, the ACH network (operated by Nacha and the Federal Reserve/EPN) processes millions of payments during the day, but settlement between banks occurs one or a few times daily on a net basis. If Bank A’s customers sent $5 million to Bank B’s customers, and Bank B’s sent $4 million to Bank A’s, at the end of the cycle Bank A pays $1 million net to Bank B (via their Federal Reserve accounts). This net settlement often happens through the central bank’s RTGS at specified times. Until settlement, participants have a risk exposure to the clearinghouse or other participants, which is managed by limits or prefunding or loss-sharing arrangements. ACH payments are not instant; they usually clear in a day or two (though same-day ACH has narrowed this window). They are ideal for non-urgent transactions. Clearing is the process of transmitting, reconciling, and in some cases confirming the payments before settlement. The ACH operator ensures each bank knows its net position. Settlement is then executed, often by an entry on the central bank’s books (for example, “All STEP2 balances are settled via TARGET2” in Euro ACH clearing ). Because ACH payments rely on a central infrastructure, they are considered “information and netting” systems – they route payment info and calculate who owes whom, but the actual interbank money movement is one lump sum at settlement time.
• CHIPS (Clearing House Interbank Payments System): This is a private clearing system in the U.S. for large-value USD payments, an interesting hybrid. Operated by The Clearing House, CHIPS processes a lot of international/dollar payments using a continuous batch settlement mechanism. Banks send payment messages into CHIPS (often via SWIFT). CHIPS continuously matches and offsets payments multilaterally throughout the day, greatly reducing the need for each bank to have liquidity for the gross amount. It settles net or partial net positions periodically during the day through a central CHIPS account at the Fed. CHIPS thus is not RTGS (not every transaction is settled one by one in central bank money at the exact time) but it provides intraday finality by an elaborate algorithm and loss-allocation procedures. At end of day, any residual net positions are settled via Fedwire. CHIPS handles a large share of international USD transfers among big banks and exemplifies deferred net settlement with a private-sector twist. It exists because it can be more liquidity-efficient than Fedwire for participants, at the cost of some additional complexity.
• Real-Time Retail Payments (Immediate Funds Availability with Deferred Settlement): In many countries, so-called “fast payment” or “instant payment” systems have been introduced for consumer and business payments. We discussed SEPA Instant already as a near-real-time settlement system. However, some instant payment systems achieve immediate user-to-user transfer without immediate interbank settlement. For example, the UK’s Faster Payments Service (FPS), launched in 2008, allows funds to be posted to the recipient within seconds, but the settlement between banks occurs periodically (historically, three times a day net settlement in the Bank of England RTGS). This means banks process and credit transactions in real-time, extending credit to each other in between settlement cycles. Risk is mitigated by prefunding or debit caps. FPS thus provides the customer experience of instant payment, with the operational model of deferred net settlement. Similarly, some early instant payment systems in other countries worked this way. Increasingly, however, newer instant payment systems (like SCT Inst, India’s IMPS, Brazil’s PIX, FedNow in the USA) are tending toward true immediate settlement, often through central bank facilities or prefunded accounts, to remove credit risk and simplify operations.
• The Clearing House RTP (US): The RTP network in the United States (launched 2017 by The Clearing House) is a real-time payments system for small-value payments that provides immediate confirmation and availability. RTP achieves this by requiring participating banks to pre-fund a joint account at the Federal Reserve. When an RTP payment is made, behind the scenes the funds move from the sender’s bank’s balance in that joint account to the receiver’s bank’s balance immediately, so the settlement is effectively immediate in central bank money (though not each transaction separately on Fedwire, but via the standing prefunded account). This gives finality with each message. It’s an example of innovative architecture marrying real-time messaging with continuous settlement assurances. The Federal Reserve’s own new service FedNow (2023) takes a more traditional approach: it is an RTGS provided by the Fed for instant payments, settling each transfer in central bank money in real-time (similar to Fedwire but geared for smaller payments and 24/7 operation).

In summary, clearing refers to the process of transmitting and reconciling payment orders, often with netting; settlement is the act of discharging obligations by moving funds (usually across accounts at a central settlement institution like a central bank or a correspondent). RTGS performs settlement transaction by transaction, whereas deferred systems perform settlement less frequently on a netted basis.

What ties these systems together is that a payment often uses both messaging and settlement layers. For instance, a SWIFT MT103 might instruct a payment that will settle via Fedwire. SEPA credit transfers use clearing house messages and settle via TARGET2. A debit card transaction might go through card network messaging and later settle via ACH nets. In all cases, the integrity of the system relies on accurate, secure messaging combined with reliable settlement mechanisms to move the money as instructed.

Illustrative Diagrams and Examples

To visualize the concepts discussed, this section provides simplified diagrams of interbank transfer processes, highlighting the flow of messages and funds through various steps. These examples tie together messaging (SWIFT/SEPA) with the movement of money via correspondents or settlement systems.

In Figure 1, we see that the SWIFT MT103 goes directly from sender to receiver banks (solid line along the bottom), carrying customer payment details. Meanwhile, the MT202 COV (top line) goes from the sending bank to an intermediary bank (perhaps more than one) and then to the receiving bank. The MT202 COV is how the money moves through the correspondent network: the sending bank will debit its nostro at the intermediary and the intermediary will credit the receiving bank’s nostro (its account at the intermediary) as per this instruction . The MT910 confirmation from the intermediary to the receiving bank (top right) lets the receiving bank know “your account has been credited with the funds” so that the receiving bank is assured it actually has the money before releasing it to the beneficiary . Finally, the receiving bank notifies the beneficiary (which could simply be the customer seeing the deposit, or a formal MT940 message if the beneficiary is itself a financial institution expecting a statement). This example underscores the separation of roles: SWIFT messages are instructions/signals, and the correspondent banking rails are the path for fund settlement.

Figure 2 complements the narrative steps we discussed earlier by putting them in a visual context. It shows how ledger entries are made in each institution corresponding to the payment. In both scenarios, the ultimate debit is to the payer’s account (Bank A) and the ultimate credit is to the receiver’s account (Bank C). The difference is whether Bank B directly transfers on its books, or whether a formal payment system (like an RTGS) is used for the leg between B and C. This kind of multi-step process is what every payment including international ones undergoes, though often hidden from the end customers. Each arrow in the diagram implies a secure message that triggers the next accounting entry. The integrity of the system relies on each institution only acting on authentic instructions and each ledger entry balancing out across books with real fund settlements. The regulatory frameworks and standards discussed next ensure that all banks perform these roles responsibly and safely.

Security and Segregation of Ledger Server Infrastructure

Given the critical nature of interbank payments, banks employ robust security architecture to protect their core servers and ledger servers from unauthorized access. A fundamental principle is the segregation of the bank’s internal core systems from external networks. The computers that hold and update the bank’s general ledger (customers’ account balances, the bank’s positions, etc.) are kept in a highly secure environment, isolated behind multiple layers of defence. External payment instructions, therefore, must pass through controlled gateways before they can affect the core servers, while ledger servers are secluded from the exterior environment.

A typical bank’s payment processing architecture looks like this: the bank operates a SWIFT interface server or payment gateway server that is connected to the SWIFT network (or to other external networks like ACH, SEPA, etc.). This interface server resides in a demilitarized zone (DMZ) or secure segment of the bank’s network, separated by firewalls from the internal core server banking system. Incoming messages from SWIFT (for example, an MT103 that credits one of the bank’s customers) arrive at the interface, which validates and parses them. Only then are the relevant details forwarded to the core banking application for actual posting to the ledger servers and the respective accounts.

Firewalled Communication Gateways: As per best practices, “Alliance Gateway can be placed between two firewalls – the ‘demilitarized zone’ – enabling tighter IP protocol filtering as well as segregating connectivity and business processing.”. In plainer terms, the SWIFT Alliance Gateway (the software many banks use to connect to SWIFT) is installed in a zone that has one firewall facing outward to SWIFT’s network and another firewall facing inward to the bank’s core. This two-firewall approach ensures that even if the outward-facing system is exposed, the core ledger remains shielded. The gateway will typically only allow well-defined message traffic and perhaps specific API calls through to the core systems, nothing else.

Banks also often utilize message queueing and middleware internally. When an external payment instruction comes in, it might land in a middleware queue where additional checks occur (e.g., compliance screening for sanctions, format validation, duplicate checking, authorization by operations staff if needed) before final posting. This layered approach prevents a rogue or erroneous message from directly altering accounts without oversight.

Additionally, the core banking servers are usually not directly accessible from the internet at all and ledger servers never are. Even the administrators of those systems often must go through jump servers or VPNs with strong authentication to access them. Customer online banking portals are separated from core ledgers by multiple application layers. In the context of interbank messaging, this means if a hacker wanted to, say, send fraudulent SWIFT instructions or alter the books, they would face multiple obstacles: gaining access to the SWIFT network (which itself requires authentication keys and is monitored), then breaching the bank’s interface system, then breaching internal firewalls, and then the core system – all without being detected. Banks implement intrusion detection and strict network segmentation to make this extremely difficult.

Historically, there have been cases (such as the infamous 2016 Bangladesh Bank incident) where attackers compromised a bank’s SWIFT interface server and sent fraudulent messages. In response, SWIFT and regulators have doubled down on security requirements (SWIFT’s Customer Security Programme now mandates controls to segregate critical systems, manage access, and monitor for anomalies). The ledger integrity is paramount: even if a malicious payment message is injected, banks have reconciliation and monitoring that would catch unexpected account movements, and central banks have oversight that might catch suspicious patterns.

Another aspect of security is that the cryptographic keys and credentials used for interbank messaging are protected. For example, SWIFT communications use authentication via the exchange of secure keys (formerly physical tokens, now often HSMs – Hardware Security Modules – hold the keys). These are kept in secure environments. Many banks use dedicated SWIFT terminals or appliances that are hardened and separately managed from general IT.

Furthermore, transaction screening and verification add security. A payment instruction arriving via an external network may be subject to approval checks. For instance, if a huge unusual payment comes in, the bank might have an automated rule or a manual intervention step to verify it out-of-band before executing.

In summary, banks design their infrastructure such that the core ledger servers are never directly reachable from external networks. Instead, communication servers act as gatekeepers, sitting at the boundary to receive incoming instructions and then passing only legitimate, screened transactions inward for processing. This compartmentalization localizes any potential breach to the boundary, where damage can be contained. The result is that the integrity of banks’ ledgers (the official record of who has what money) is preserved even as those ledgers are updated based on external instructions.

Institutional and Regulatory Frameworks

Interbank payment systems do not operate in a vacuum – they are subject to oversight by central banks and regulators to ensure stability, standardization, and integrity. Several key institutions play roles:

• Bank for International Settlements (BIS) and the CPMI: The BIS, based in Switzerland, serves as a forum for the world’s central banks to cooperate on financial stability issues. Under the BIS, the Committee on Payments and Market Infrastructures (CPMI) (formerly CPSS) sets global standards for payment, clearing, and settlement systems. A landmark contribution is the Principles for Financial Market Infrastructures (PFMI), published in 2012 by CPMI and IOSCO, which are international standards that systemically important payment systems must follow. The PFMI covers areas like governance, risk management, settlement finality, default handling, and security for critical infrastructures (including RTGS systems and major clearinghouses). Countries have by and large adopted these principles into their oversight frameworks. The BIS also conducts research and issues reports on improving cross-border payments, reducing correspondent banking risks, etc. (e.g., the BIS CPMI has studied and encouraged ISO 20022 adoption, digital innovations, etc., to enhance interoperability of payment systems).

Another role of BIS and central banks is oversight of messaging networks. Even though SWIFT is just a messaging provider, it’s considered critical infrastructure for global finance. Consequently, central banks oversee it collectively. SWIFT is a cooperative based in Belgium, and the National Bank of Belgium (NBB) is the lead overseer, chairing an oversight group of G10 central banks plus the ECB. This group monitors SWIFT’s operational resilience, security standards, and risk controls. It was formalized in the 1990s and continues today. Such oversight does not mean central banks run SWIFT, but they ensure that SWIFT (as a private sector entity) meets high reliability and security expectations. This is an example of regulators stepping in to oversee even a non-settlement system, recognizing its crucial role. In fact, “the system is overseen by the central banks of the G10 countries, the European Central Bank, and the National Bank of Belgium”.

• European Central Bank (ECB) and European Regulators: The ECB (and Eurosystem national central banks) not only operate systems like TARGET2/T2 and TIPS but also have a mandate to promote the smooth operation of payment systems under the EU treaties. The ECB oversees systemically important payment systems in the Eurozone (including TARGET2 itself, private systems like EURO1 or STEP2, and even SWIFT to an extent via the oversight college). The ECB has worked with the European Commission to drive the SEPA initiative – for example, by fostering the creation of the European Payments Council (EPC) which developed the SCT and SDD (direct debit) rulebooks, and by co-chairing the Euro Retail Payments Board (a successor to the SEPA Council) to involve stakeholders in payments governance. Through regulations like the Payment Services Directive (PSD2) and various guidelines, European authorities standardize aspects of payments (such as requiring the use of IBANs for transfers, mandating instant payments provision by banks as is being legislated in 2024, and ensuring robust customer authentication to prevent fraud). The ECB also has an interest in reducing systemic risk – for example, it might require banks above a certain size to settle large payments in TARGET2 rather than risking delays via correspondents. Another example: the ECB and national central banks oversee that Euro clearinghouses settle their positions in central bank money (TARGET2) to eliminate credit risk.

In addition, the European Banking Authority (EBA) issues guidelines that can affect payment systems (for instance on outsourcing or security), and the European Commission has legal frameworks like the Instant Payments Regulation aimed at standardizing instant payment availability. The ECB’s role is often one of catalyst and overseer – pushing the industry toward efficient, unified protocols (like ISO 20022 adoption across Europe, which has been coordinated through Eurosystem for TARGET2 and subsequently the banks).

• National Central Banks and Regulators: Each country’s central bank (or financial regulator) typically has oversight authority over payment systems in its jurisdiction. For example, the U.S. Federal Reserve oversees Fedwire (which it operates) and also has regulatory oversight over CHIPS and ACH as they involve member banks (in practice, the Fed and other agencies ensure these systems manage risks properly). In the UK, the Bank of England oversees CHAPS (which it operates) and has taken on oversight of retail systems like Faster Payments and Bacs under its Financial Market Infrastructure supervision remit. Many countries have explicit laws that designate certain payment systems as “systemically important payment systems (SIPS)” which must observe standards (often PFMI). Regulators will conduct periodic audits, require self-assessments, and set requirements for participant banks (for instance, minimum technical capabilities, liquidity arrangements, contingency plans, and cybersecurity standards).

Safeguarding integrity is a common regulatory goal. Regulators require that payment systems have strong resilience (e.g., redundant infrastructure, backup sites, the ability to recover from disasters quickly) and security (protection against cyber attacks, and fraud). In recent times, cyber resilience guidance has been a big focus (as referenced by CPMI-IOSCO’s guidance on cyber for FMIs ). National regulators also enforce anti-money laundering (AML) and sanction compliance in payment messaging – e.g., requiring banks to include certain information in payment messages (like originator info in SWIFT messages per FATF Recommendation 16, which was one impetus for MT202 COV changes). They may inspect banks for compliance with these rules and can levy penalties if, for example, a bank’s controls on screening transactions are inadequate.

On the user protection side, regulators also put in place consumer safeguards (like the EU’s requirement that a SEPA credit transfer reaches the beneficiary the next day, or US requirements on electronic transfers under Reg E for consumers). While these might not directly affect interbank plumbing, they influence how banks implement their payment processing to meet those rules.

• The Role of BIS Innovation Hub and International Initiatives: In the last few years, there have been concerted international efforts to improve cross-border payments, recognizing issues like high cost and slow speed partly due to correspondent banking complexity. The G20 (group of major economies) 2020 launched a roadmap for enhancing cross-border payments, involving the BIS CPMI, Financial Stability Board (FSB), IMF, World Bank, etc. This roadmap includes building blocks such as: increasing data standardization (ISO 20022 everywhere), extending operating hours of RTGS systems to overlap more, exploring reciprocal account arrangements between central banks, and investigating central bank digital currencies (CBDCs) that could facilitate cross-border settlement. While these are forward-looking, they show the continued importance of international coordination. Bodies like the BIS and FSB ensure that as technology evolves (e.g., blockchain-based settlement or digital currencies), the new solutions integrate safely with existing systems or meet equivalent robustness.

In summary, the institutional framework is multi-layered: global standard-setters (BIS/CPMI) provide principles and foster cooperation; regional bodies (ECB, EC) drive harmonization and regulation in their zone; national regulators/central banks implement oversight, enforce rules, and operate key systems. Thanks to this framework, interbank transfer systems have very strong track records – failures or insolvencies are extremely rare, and when they occur (e.g., a bank failure), the mechanisms in place (like loss sharing or central bank liquidity) prevent wider contagion. The collaborative oversight of a utility like SWIFT or the enforcement of universal standards (PFMI) are unseen by everyday users but critical to maintaining trust that when Bank A hits “send”, Bank C will reliably receive.

Conclusion

Interbank fund transfers are a symphony of communication and accounting. The messaging systems (like SWIFT and SEPA) provide the score – the detailed instructions – while the settlement systems and correspondent banks perform the movements that relocate the money on stage. This entire process takes place behind the scenes in seconds or days, abstracted from the end-user who simply sees that money appeared in an account. Underlying it all is a dense web of protocols, bilateral relationships, and security measures that have been refined over decades to minimize risk and maximize efficiency. It is thanks to these meticulously designed mechanisms – and the vigilance of institutions that regulate and maintain them – that a bank in one corner of the world can confidently send value to another bank half a globe away, knowing that the funds will arrive intact and the ledgers will remain in balance.