RTGS, Deferred Net Settlement, Prefunding and Payment Finality. Compare gross and net settlement, prefunded positions and legal finality through actual account movements, liquidity use and exception outcomes.
Three banks have accepted instructions arising from a day's customer activity. Bank A owes Bank B $90 million, Bank B owes Bank C $70 million, and Bank C owes Bank A $40 million. One arrangement could settle each obligation individually. Another could calculate the banks' net positions and settle those later. A third could use prefunded positions and a liquidity-saving process. The same underlying business values do not produce the same funding requirement, timing or failure exposure.
Chapter 52 established the authority needed to release an instruction. This chapter examines what happens to financial obligations after release. It compares settlement models and the evidence of finality, using the previously studied US rails as concrete examples. It does not repeat their complete message catalogues or operating manuals.
Settlement describes discharge of a financial obligation in the relevant asset and accounts. Finality describes the legal certainty of that discharge. Neither can be inferred from an app's speed or from the word accepted.
Allow roughly 60 minutes for the chapter, diagram walkthroughs and worked cases. Banks and amounts are fictional. Model examples simplify fees, credit arrangements and ancillary positions. Sources were checked on October 5, 2026; each live system's current rules and agreements govern its own settlement events.
Chapter navigator
- Identify the obligation, asset and account
- Clearing and settlement can be integrated without being identical
- Real-time gross settlement
- What gross settlement means in the three-bank example
- Deferred net settlement
- The interval before settlement creates a management problem
- Prefunding is a funding arrangement, not a synonym for netting
- RTP and the prefunded joint-account model
- CHIPS and liquidity-saving final settlement
- Finality and customer availability answer different questions
- Finality does not erase returns, remedies or investigations
- Credit exposure, liquidity exposure and settlement risk
- Reconciliation and accounting across models
- Implementing a settlement-aware bank service
- Worked cases and implementation decisions
- Role checklist and learning closure
1. Identify the obligation, asset and account
Before calling a payment settled, identify who owed whom and which obligation was discharged. A payer can owe a supplier, a bank can owe another bank under a payment system, and a provider can owe a customer a withdrawal. Those obligations are related but not identical. Completion of one does not automatically prove completion of the others.
Next identify the settlement asset. Central-bank money held in a Federal Reserve account differs from a commercial-bank deposit or an internal provider balance. The distinction affects the claim being held and the associated credit exposure. Describing all of them as dollars does not explain whose liability the receiving institution now holds.
Finally identify the account entries and the governing finality event. A system may exchange instructions and calculate obligations before any settlement account moves. A receiving bank may make funds available before its own interbank position settles under another arrangement. The implementation needs evidence for each event, even if customer-facing language is simpler.
A useful bank record therefore links business obligation, payment instruction, system reference, settlement account, settlement event and customer posting. It should allow a reviewer to state precisely what has become final and what remains subject to another process. A single timestamp called payment complete is rarely sufficient for all those purposes.
2. Clearing and settlement can be integrated without being identical
Clearing can include transmitting, validating, reconciling or confirming payment information and, where applicable, calculating obligations. Settlement discharges those obligations. Some services integrate these functions tightly; others separate them across organizations or time. Integration does not remove the conceptual distinction.
Consider a file of accepted payment instructions. Its validity establishes that the system can process the records under its rules, not necessarily that settlement has occurred. If a clearing arrangement calculates net positions, the calculation identifies what must settle. It does not itself move funds into the receiving participants' settlement accounts.
In an instant service, message exchange and settlement can occur within a short coordinated process. That can make the stages nearly invisible to the customer. The bank still needs to know which response confirms settlement, which is a technical acknowledgment and which indicates a failed or unresolved attempt. The message name alone is not enough without the service's implementation meaning.
Do not turn ISO 20022 into a settlement model. A pacs.008 communicates a customer credit-transfer instruction within a specified implementation. A status message communicates its defined result. Different systems can use related message families while employing different accounts, liquidity arrangements and legal rules.
3. Real-time gross settlement
Real-time gross settlement, or RTGS, settles eligible obligations individually rather than waiting to replace a population with a later net amount. Real time concerns processing when the relevant conditions are met; gross concerns the unit of settlement. Neither means that every customer request is accepted immediately or that the originating bank has unlimited liquidity.
Fedwire Funds is the US high-value RTGS example studied earlier. A bank releases an eligible instruction, the Federal Reserve processes it under the service's rules, and the applicable account entries establish interbank payment. FedNow also uses real-time gross settlement, with an instant-payment process and its own operating and participation framework. Their shared model does not make the two services interchangeable.
The diagram follows three individual settlements and the resulting account balances. Incoming funds can support a later outgoing payment without turning gross settlement into net settlement. Its $90 million opening balance illustrates one feasible sequence, not a universal minimum funding requirement.
Liquidity can be reused as incoming payments arrive. RTGS therefore does not require prefunding the sum of every payment the bank will send all day in one untouched balance. The amount and timing of needed funding depend on the sequence of flows, permitted credit and operational choices. Chapter 55 develops that intraday management problem.
4. What gross settlement means in the three-bank example
Take the opening obligations in a simple order. Assume A initially has $90 million available for this exercise, while B and C initially have none assigned to these flows. A pays B $90 million. B can then use $70 million of that receipt to pay C. C can use $40 million to pay A. The three gross transfers total $200 million, although the same liquidity circulates.
The final balances attributable to the example are A $40 million, B $20 million and C $30 million. They total the original $90 million. This is an illustration of one feasible sequence, not a claim that $90 million is the theoretical minimum for every scheduling or credit arrangement. It shows why gross value and required initial liquidity are different measures.
Each settled transfer has its own financial history. If B's payment to C is delayed after A has paid B, A's completed transfer does not simply disappear. The remaining obligations and the institutions' current balances must be assessed from that point. Reversing the earlier leg is not an automatic way to restore the initial picture.
For the bank's test case, record each balance after each transfer and identify which institution can fund the next one. Then change the order. The exercise makes the timing dependence visible without inventing a universal queue algorithm or assuming incoming funds are available before they actually arrive.
5. Deferred net settlement
In a deferred net settlement arrangement, eligible activity is accumulated and positions are calculated for later settlement under the arrangement's rules. The netting may be bilateral or multilateral. The details determine which obligations are replaced or discharged, when that occurs and how a failure is handled. Net arithmetic alone is not a legal agreement.
For the opening example, A sends $90 million and receives $40 million, leaving a net debit of $50 million. B receives $90 million and sends $70 million, leaving a net credit of $20 million. C receives $70 million and sends $40 million, leaving a net credit of $30 million. The net debit equals the two net credits.
Only $50 million of debit funding is needed to discharge those particular net positions in this simplified model. That is not a claim that a live system can operate with no collateral, credit controls, buffers or default resources beyond that amount. It is the arithmetic benefit of netting this population, assuming the arrangement validly settles it as net obligations.
Until the relevant settlement and legal conditions are met, participants may face exposure to an unsettled position. A customer receiving early availability can also create a separate bank exposure. The system's default and loss-allocation rules determine the treatment; the chapter does not assume every net system unwinds all transactions when one institution cannot fund.
6. The interval before settlement creates a management problem
A net position can change as new activity enters, returns are processed or adjustments are included. The bank should distinguish a provisional estimate from the final instructed position for a cycle. Treasury cannot safely fund a settlement using a dashboard that silently mixes those versions.
The interval also creates a deadline. A bank expecting to be a net receiver can become a net payer after a large late transaction. The arrangement may control such exposure through limits, collateral, prefunding or other rules. Those controls must be understood at participant level rather than inferred from the eventual net amount.
Suppose A expected a $30 million net debit and receives a final obligation of $50 million. The additional $20 million is a funding requirement at the relevant deadline. A bank should identify the source, availability and authority to move it before accepting further commitments based on the old estimate.
Operational reporting needs to state whether a cycle is open, calculated, submitted for settlement, partially processed within the settlement mechanism, completed or subject to a supported exception. The precise states depend on the service. A generic batch-success message should not conceal which financial events have actually occurred.
7. Prefunding is a funding arrangement, not a synonym for netting
Prefunding places value in the required location before payments or settlement obligations use it. It can support a system that settles individual payments, a net arrangement or another contractual model. Saying a service is prefunded does not answer whether it settles gross, nets obligations or provides finality before a later funding reconciliation.
The bank should identify whose funds are placed where, how participation positions are represented and what controls prevent spending beyond the permitted position. A customer's prefunded account at a payment provider is different from an institution's prefunded position in a payment system. Both may be called available balance, but they do not represent the same claim.
For an illustrative institution with a $6 million system position, a $400,000 outgoing payment reduces that position to $5.6 million if no other events occur. An incoming $250,000 payment then increases it to $5.85 million. The bank must use the actual system's accounting and limits rather than infer the position from its ordinary deposit-account balance.
Prefunding reduces reliance on unsecured settlement credit within the defined mechanism, but it does not remove every risk. Operational failure, fraud, participant access problems, legal uncertainty and insufficient funding can still disrupt service. The bank also bears the opportunity cost and availability constraints of placing liquidity in a particular account or system.
8. RTP and the prefunded joint-account model
The RTP network uses prefunded positions supported by funds in a joint account at the Federal Reserve Bank of New York. A participant's position changes as its payments settle under RTP rules. Funding the arrangement is distinct from the individual customer payments subsequently settled within it.
An individual RTP payment does not require a fresh Fedwire transfer between the two participants' ordinary master accounts for every transaction. Within the prefunded arrangement, value moves between the participants' positions. The aggregate joint-account funding need not change merely because one participant pays another. Additions and withdrawals of funding are separate financial events.
The diagram illustrates that distinction without reproducing the full RTP technical specification. Treasury needs the participant position and any funding-agent relationship; operations needs the payment's actual network outcome; finance needs the relationship between those records and the bank's own books.
If the participant lacks available position, being operationally connected is not enough to send every requested payment. Its supported funding and control processes must establish capacity. Conversely, a funded position does not override customer authority, sanctions restrictions or transaction eligibility. Funding and permission remain different conditions.
9. CHIPS and liquidity-saving final settlement
CHIPS should not be described as a simple end-of-day deferred-net system. The Clearing House describes a process that evaluates payments using available liquidity and its liquidity-saving mechanism; when a payment is released under the rules, it settles with finality. Funding, offsetting and end-of-day procedures support that model without making released payments provisional until the close.
The practical distinction is between an instruction waiting for release and a payment already released and settled. A bank can monitor queued value to anticipate funding needs, but it should not report that value as final recipient-bank receipt. Nor should it assume a later close-of-day funding movement is the finality event for every earlier released payment.
Liquidity-saving mechanisms can reduce the funding needed by using offsetting flows under defined conditions. That does not mean any two banks can privately net instructions and treat the result as a CHIPS settlement. The system's rules, account structure and release process establish the outcome.
For an architecture review, require a precise description of the queue, release signal, settlement evidence and account position. Labels such as hybrid or liquidity efficient can be useful summaries, but they are not substitutes for the actual financial lifecycle. Earlier CHIPS material remains the source for its detailed participant process.
10. Finality and customer availability answer different questions
Final interbank settlement concerns the participating institutions' financial obligation under the applicable framework. Customer availability concerns when the recipient can use money in the relevant account or product. The two can be closely coordinated, but they are not interchangeable definitions.
Regulation J's Fedwire and FedNow provisions establish specific final and irrevocable interbank payment treatment. A bank should use those rules and the applicable operating circular to identify the event, rather than invent its own finality from the first technical response. Different arrangements require their own legal basis and evidence.
A receiving bank's customer posting remains an operational and legal responsibility. If interbank settlement completes but an internal posting process has a problem, the bank must investigate that customer-account outcome. It cannot tell the sender that no settlement occurred merely because a customer screen has not updated, or tell the recipient that a screen alone is the complete financial record.
The reverse distinction also matters. A bank can make funds available based on provisional information or credit policy in arrangements that allow it. That customer availability does not retroactively accelerate the system's settlement event or erase return exposure. Customer service needs clear language about both the money the customer can use and the bank's underlying position.
11. Finality does not erase returns, remedies or investigations
A final payment can be followed by another payment returning funds under an applicable process. That subsequent movement does not mean the original settlement was merely a temporary screen status. Preserve both financial events and their references so the bank can explain the net customer outcome without rewriting history.
Distinguish a request to return funds from the return itself. A request message does not guarantee the receiving institution's agreement or recover money automatically. The responsible teams must follow the actual service rules and applicable law, including any customer-protection duties that operate independently of interbank recovery.
ACH provides another important distinction: a settled entry can later have a permitted return or reversal under the applicable rules. The original settlement movement and the later adjustment are separate events. Do not describe every possibility of a later correction as proof that no settlement ever occurred.
For an uncertain outcome, establish the authoritative service record before replacing the instruction. A timeout in the sending bank does not make a settled payment reversible. The bank needs inquiry, reconciliation and an escalation path that preserves both financial finality and the unresolved customer question.
12. Credit exposure, liquidity exposure and settlement risk
Credit exposure concerns loss if an obligated party does not pay. Liquidity exposure concerns obtaining usable funds when needed, even where eventual value may be recoverable. Settlement arrangements can reduce one exposure while increasing demands elsewhere. A strongly prefunded system can still challenge a bank that has put liquidity in the wrong location.
RTGS removes the need to wait for a later net settlement of already settled individual obligations, but it requires timely funding and disciplined release. Deferred netting can economize on funding while requiring controls for the interval before settlement. Prefunding provides a defined resource but can constrain capacity when outflows are one-sided.
Assess exposure at each level. The payment system may have final settlement while a bank has extended credit to its customer. A provider may have received a final bank payment while still owing beneficiaries. An institution can also hold a claim on a correspondent instead of directly holding central-bank money. The word final does not make those separate exposures vanish.
Risk reports should identify the affected obligation, counterparty, amount, time and potential resolution. A generic unsettled total that mixes customer receivables, expected incoming payments and confirmed system positions is difficult to act on and can lead to double-counted liquidity.
13. Reconciliation and accounting across models
Reconcile gross business activity, system obligations and cash movements using the model actually employed. In the three-bank net example, the gross population totals $200 million, while net debit funding totals $50 million. A bank statement showing a net movement should not be forced to contain all three gross payments as separate cash entries.
At Bank A, the relevant payment and customer ledgers must explain its $90 million outgoing and $40 million incoming activity. The settlement ledger must explain the resulting $50 million net debit if the arrangement settles net. Gross transaction history remains necessary for customer reporting and exceptions even when cash settlement is net.
For prefunded systems, reconcile opening participant position, funding additions, incoming payments, outgoing payments, withdrawals and applicable adjustments to closing position. Separately reconcile the bank's asset and control accounts to the authoritative records. A funding transfer should not also be counted as customer payment volume merely because it uses a payment rail.
For RTGS, reconcile individual settlement evidence and the account statement, including timing or reporting differences. A missing acknowledgment may be a messaging problem even when the account entry is present. The reconciliation process should resolve the evidence gap instead of generating an unnecessary replacement payment.
14. Implementing a settlement-aware bank service
Define a settlement profile for each supported route: participating entities, account relationship, asset, operating calendar, release conditions, finality evidence and exception process. Keep it separate from the customer product name. A corporate payment product can select different routes while retaining the same commercial purpose.
Use precise internal statuses with source evidence. Bank accepted, queued, sent, service rejected, settlement confirmed and recipient posting confirmed are different states. Not every service supplies every event to the bank; the interface should state the evidence available rather than manufacture a universal beneficiary confirmation.
Test the transitions that can create false conclusions. Lose an acknowledgment after settlement. Delay a net cycle. Exhaust a prefunded position. Receive a legitimate return after finality. In each case, confirm that financial records remain balanced and the customer obligation is handled without duplicate release or unexplained write-off.
Implementation review should involve treasury, operations, finance, legal and the service specialists together. A technically valid message mapping can coexist with an incorrect settlement assumption. The design is ready only when those teams can agree where the money moved and which obligation the evidence discharged.
15. Worked cases and implementation decisions
Gross value exceeds starting liquidity
A, B and C settle the three opening payments in sequence using the illustrative $90 million starting balance at A. After each transfer, record the institutions' balances and the settled obligation. The total gross value is $200 million, but no additional money is created as receipts are reused.
Then delay B's payment. Explain why A's completed payment stays in history while B still owes C. The exercise separates circulation of liquidity from the finality of each financial event.
Net positions settle a large gross population
The same $200 million population produces A's $50 million debit and B's and C's $20 million and $30 million credits. Reconcile the zero-sum net instruction and identify the gross records each bank still needs.
Now introduce an omitted $5 million underlying item. A balanced net file can still be wrong if the source population is incomplete. Explain why arithmetic balance is necessary but not proof of complete clearing or correct customer allocation.
A prefunded balance is confused with the bank's cash
A bank has sufficient ordinary master-account funds but too little position in its prefunded payment arrangement. Its routing service assumes the master-account balance alone authorizes release. Identify the missing funding step or approved funding-agent arrangement.
Prepare the account and position records before and after funding. Explain why the movement creates capacity without itself completing the queued customer payments. Do not count the same funds as freely available in both locations.
A final payment has a missing customer posting
The originating institution has authoritative settlement evidence, but the beneficiary reports no visible account credit. The receiving bank must investigate its posting and availability process. Reissuing the original immediately could duplicate a payment that already settled.
Identify the evidence needed from each institution and the customer communication appropriate to the known facts. The answer should distinguish the interbank result from the unresolved customer-account outcome.
An operator releases a liquidity-saving payment
A CHIPS instruction waits, then the network releases it under its rules. A monitoring report continues to label it awaiting end-of-day finality. Correct the status model and identify the authoritative event that should have changed it.
Keep the subsequent funding and closing reconciliation visible without treating them as a condition that retrospectively makes every released payment provisional. The exercise tests the difference between queue management and settlement finality.
Returned funds follow an already final transfer
A bank receives a supported return of funds linked to an earlier final payment. Finance proposes deleting the original transaction and leaving only the net balance. That would remove evidence needed for the customer, service records and investigation.
Retain the original and the subsequent return with their respective dates, references and accounting. Explain the net customer outcome separately. A correct reversal of a local erroneous posting must not be confused with erasing a genuine external settlement event.
16. Role checklist and learning closure
Product should state what completion means for its customer service. Business analysis should identify obligations, assets, accounts and authoritative states. Technology should map messages to those states without equating every acknowledgment with settlement. Treasury should fund the actual model. Operations should investigate uncertainty and subsequent returns without rewriting final events. Finance and legal should agree the accounting perspective and governing finality treatment.
The learner should now be able to compare gross settlement, deferred netting, prefunding and liquidity-saving release without treating them as interchangeable labels. Chapter 54 examines National Settlement Service, where a clearing arrangement submits settlement positions for posting to Federal Reserve accounts.
Authoritative references
Sources checked on October 5, 2026. The numerical examples compare models and are not reproductions of a particular system's full rulebook or algorithm.
This application uses JavaScript for the full interactive experience. This text summary is served for accessibility and search indexing.