Clearing, Settlement, Availability and Finality. A practitioner deep dive separating clearing, interbank settlement, customer posting, funds availability and finality across ACH, high-value, instant, card, check and on-us payment models.
One of the easiest ways to create a bad payment requirement is to use the words cleared, settled, posted, available, and final as though they all mean the same thing.
They do not.
A customer may see money in an account before the bank has reached the same legal or operational point it would call final settlement. A payment can be accepted by a network but not yet posted to the beneficiary account. An ACH entry can settle through an operator while the bank still has return exposure. A check can be deposited and provisionally credited while funds availability and return risk follow their own timetable. A Fedwire payment, by contrast, has a much stronger and more immediate settlement-finality story at the interbank layer. An instant payment may settle in seconds, but the bank still has to post, report and reconcile it correctly.
This chapter therefore answers a deceptively simple question:
At what exact point has what happened — and for whom?
That is the foundation for good payment design, customer communication, reconciliation, accounting, liquidity management, investigations and risk control.
This chapter stays deliberately focused on clearing, settlement, posting, availability and finality as concepts. Later chapters go deeply into the mechanics of ACH, Fedwire, CHIPS, RTP, FedNow, checks, cards, National Settlement Service, liquidity and specific rulebooks.
For a roughly 60-minute core session, spend about 35 minutes on Sections 1–7 and Sections 13–15. For the next 10 minutes, use the chapter’s three diagrams to separate clearing, settlement, posting, availability and finality. Use 10 minutes to work through one case in Section 16, then spend the final 5 minutes explaining: How could a customer have spendable funds while the bank still has payment risk? Treat these timings as a study guide. The remaining sections, additional cases and extended reference material are follow-up study; completing the whole chapter takes longer.
Chapter navigator
- Why these five words must be separated
- Clearing: exchanging and determining obligations
- Settlement: discharging interbank obligations
- Posting: putting the transaction onto the customer ledger
- Availability: when the customer can use the funds
- Finality: when the transfer becomes legally or operationally conclusive
- Gross, net, deferred and prefunded settlement models
- ACH: settlement is not the end of the risk story
- Fedwire and CHIPS: high-value settlement and finality
- RTP and FedNow: instant settlement, posting and confirmation
- Cards and checks: why authorisation or deposit is not settlement
- On-us movements: no external settlement does not mean no finality question
- Liquidity, settlement accounts and intraday control
- Accounting, reconciliation and evidence across the stages
- Exceptions, reversals, returns and investigations around finality
- End-to-end cases, BA checklist and testing
1. Why these five words must be separated
A payment lifecycle contains several events that can occur close together, hours apart, or even on different business days. The mistake is to collapse all of them into one status such as SUCCESS.
Imagine a corporate supplier payment. The corporate sends the instruction. The bank accepts it. The instruction is released into a payment system. The receiving institution gets the payment. Interbank settlement occurs. The beneficiary bank posts the credit. The beneficiary can use the money. The sending and receiving banks reconcile their books. Each of those is a different event.
The same problem appears in collections. A utility originates an ACH debit. The file is accepted by the ODFI. The entry is transmitted through an ACH Operator. Settlement occurs at the scheduled settlement time. The RDFI debits the consumer account. The biller may see cash in its account. Yet the entry can still be returned under applicable ACH rules. If the biller's receivables system calls the invoice FINAL immediately at first settlement, it may create an accounting and customer-service problem later.
A robust model therefore separates at least five concepts.
Clearing is the exchange, validation, sorting, matching or calculation process that determines what participants owe each other or what instruction should proceed.
Settlement is the actual discharge of the financial obligation between settlement participants, generally through settlement accounts or another defined settlement asset.
Posting is the bank's booking of the payment onto the customer's account or internal ledger.
Availability is when the customer is permitted to use, withdraw or further transfer the funds.
Finality is the point at which the transfer or settlement becomes conclusive under the applicable legal, rulebook or contractual framework and cannot simply be unwound as though it never occurred.
Those definitions overlap in some systems because events happen almost simultaneously. They remain conceptually different.
A practical BA rule is:
Never ask “is the payment complete?” without asking complete at which layer.
At minimum distinguish:
- customer instruction accepted;
- network message accepted;
- clearing completed;
- settlement completed;
- customer debit posted;
- customer credit posted;
- funds available;
- settlement final;
- customer informed;
- reconciliation complete.
The chapter will use this layered language throughout.
2. Clearing: exchanging and determining obligations
Clearing happens before or around settlement, but clearing is not itself the movement of settlement money.
The word can describe different activities depending on the payment system.
In a batch system, clearing can include receiving files, validating them, sorting entries by destination institution, calculating participant positions and preparing settlement data.
In a real-time payment system, the clearing function can be embedded into a transaction-by-transaction workflow where each payment is validated, routed to the receiving participant and associated with immediate settlement.
In card payments, clearing typically follows authorisation and includes presentation of transaction records, fee/interchange calculation and net position formation before settlement.
In checks, clearing can involve presentment of check images and data from the depositary bank toward the paying bank.
The common idea is that clearing determines what is payable, by whom, to whom, and under what processing state.
Clearing can be bilateral or multilateral.
A bilateral arrangement involves obligations between two institutions.
A multilateral arrangement calculates obligations across several participants. Instead of every bank settling every gross transaction separately, the system may calculate a net debit or credit position for each participant.
This is where the concept of netting becomes important.
Suppose Bank A owes Bank B $100 million from one set of transactions, while Bank B owes Bank A $92 million from another set. A gross model might settle both flows separately. A net model may result in an $8 million net obligation, depending on the rules and legal structure of the system.
Netting can reduce liquidity requirements, but it also changes operational and risk design. The bank must understand:
- when positions are calculated;
- whether netting is bilateral or multilateral;
- whether the netting is legally enforceable;
- when the position becomes binding;
- what happens if a participant cannot fund;
- whether settlement is deferred;
- whether payments can be released before final settlement;
- how losses or failures are handled.
Clearing therefore affects liquidity, credit exposure and operational timing even though it is not the final settlement entry itself.
Clearing acknowledgement is not settlement confirmation
A common system-design mistake is to use one acknowledgement to represent multiple states.
A file accepted by an ACH Operator means the operator accepted the file or entries for processing. That does not automatically mean every entry has already settled or posted.
A card acquirer receiving an authorisation response does not mean clearing and settlement have occurred.
A check deposit being accepted by the depositary bank does not mean the paying bank has finally paid the item.
Status semantics should name the event they represent.
Good status names are explicit:
FILE_ACCEPTED;ENTRY_VALIDATED;NETWORK_ACCEPTED;CLEARING_POSITION_CALCULATED;SETTLED;BENEFICIARY_POSTED.
Bad status design calls all of those SUCCESS.
Clearing can fail before settlement
Failures can occur because of:
- invalid data;
- duplicate detection;
- routing failure;
- participant ineligibility;
- message-format failure;
- account or product restrictions;
- cut-off or processing-window rules;
- scheme or network validation;
- sanctions/fraud controls at the institution;
- participant suspension;
- technical outage.
The earlier the failure, the more likely the payment can be rejected without any settlement unwind.
That distinction becomes important later when we compare reject, return and reversal.
3. Settlement: discharging interbank obligations
Settlement is the point where obligations between settlement participants are discharged using the settlement mechanism defined by the payment system.
The settlement asset matters.
For many US interbank payment systems, settlement ultimately uses balances held in Federal Reserve master accounts or other arrangements tied to central-bank money. Some private-sector systems use prefunded or designated accounts with settlement structures defined by their rules. Some systems calculate positions privately and settle those positions through a Federal Reserve service.
The most important question is not only where did the message go? It is where did the financial obligation between institutions get discharged?
Suppose Bank A sends a payment to Bank B.
At customer level:
- Customer A loses funds.
- Customer B receives funds.
At interbank level:
- Bank A owes Bank B.
- The payment system or settlement arrangement determines how that obligation is settled.
- The relevant settlement accounts are debited and credited or participant positions are otherwise discharged.
The customer ledgers and the interbank settlement accounts are different accounting layers.
A bank can debit its customer before interbank settlement. A receiving bank can sometimes credit its customer before a later settlement event, depending on the instrument and rules. That is why customer posting cannot be treated as proof of settlement.
Settlement account is not customer account
This distinction deserves to be explicit.
A corporate current account at Bank A is not the same thing as Bank A's Federal Reserve master account.
A consumer deposit account is not an RTP settlement position.
A merchant settlement account is not the card network's interbank settlement mechanism.
Different balance domains exist:
- customer balance;
- bank ledger / GL balance;
- network or clearing position;
- settlement-account balance;
- liquidity capacity.
A good payment hub understands which balance it is checking and why.
Settlement can be individual or position-based
Fedwire is a classic real-time gross settlement model. Qualifying payment orders are processed individually, and settlement occurs by debit and credit to the participants' Federal Reserve master accounts.
Other systems can calculate net positions and settle those positions later.
The Clearing House's CHIPS combines sophisticated liquidity-efficient processing with final settlement under its rules rather than behaving like a simple bilateral gross wire exchange.
ACH uses scheduled settlement windows and operator processing rather than gross real-time settlement of every entry.
The model changes the bank's liquidity requirement and timing, but the business principle remains:
settlement is about discharging the participant obligation, not merely moving a message.
4. Posting: putting the transaction onto the customer ledger
Posting is the bank's act of booking the debit or credit to the relevant customer account or internal ledger.
A payment system can settle correctly while customer posting fails.
That sounds alarming, but it is exactly why banks build reconciliation and exception processes.
Imagine an incoming instant payment.
The network accepts and settles the transfer. The receiving bank's external settlement position is correct. But the bank's core-accounting interface is unavailable for three seconds or rejects the account posting because of an internal technical issue.
From the external network's perspective, the interbank transfer may already be complete.
From the beneficiary's perspective, the money is not yet visible or usable.
The receiving bank now owns a serious posting exception.
That is why the bank needs a reliable link between:
- network transaction;
- settlement event;
- internal booking;
- beneficiary account;
- customer notification.
Debit posting and credit posting are different events
On the sending side, the payer's account may be debited before or at release.
On the receiving side, the beneficiary account may be credited after settlement confirmation.
For batch payments, posting can be coordinated with processing windows.
For on-us transfers, debit and credit may be part of one internal atomic transaction.
For checks, a deposit credit may be provisional.
For cards, authorisation can create a hold without creating the final posted transaction.
The word posted therefore needs context:
- pending debit?
- booked debit?
- pending credit?
- provisional deposit?
- settled card transaction?
- internal memo post?
- final ledger post?
Posting date, value date and transaction date can differ
Banking systems often carry multiple dates:
- transaction date;
- processing date;
- value date;
- posting date;
- settlement date;
- availability date.
Those dates can be identical in an instant payment and different in other instruments.
Requirements should define each field rather than creating one generic paymentDate.
This matters for:
- interest;
- statements;
- cut-off treatment;
- reconciliation;
- accounting period;
- regulatory reporting;
- customer disputes.
Customer statement is a downstream representation
A transaction being visible on a statement or app does not itself define settlement finality.
The customer channel is reporting a state decided by underlying systems.
A clean architecture prevents the channel from inventing payment truth.
The system of record should expose explicit statuses and timestamps that the channel can translate into human language.
5. Availability: when the customer can use the funds
Funds availability is about the customer's ability to use money, not merely whether a ledger entry exists.
This distinction is especially visible with check deposits.
A bank may accept a check deposit and create a provisional credit, but Regulation CC and the bank's funds-availability policy determine when deposited funds must be made available, subject to applicable rules and exceptions.
Regulation CC requires banks to make certain deposited funds available within specified time periods and to disclose funds-availability policies. It is therefore wrong to say that "money shown in the account is always immediately spendable."
Availability also matters outside checks.
A receiving bank can display an incoming transaction while placing a product or compliance restriction on the account.
A card refund can be posted through a card lifecycle but customer availability depends on issuer processing.
An ACH credit may settle and become available according to applicable ACH and bank rules.
Instant payments are designed to support rapid funds availability, but the receiving bank still needs a functioning posting and account system.
Ledger balance and available balance are not the same thing
A customer account can expose several balance concepts:
- ledger/current balance;
- available balance;
- collected balance;
- pending debit amount;
- pending credit amount;
- hold amount.
A deposit can increase ledger balance while the available balance remains lower.
A card authorisation can reduce available balance before final posting.
An incoming payment can increase available balance immediately if the bank has confidence in finality.
The bank's balance model therefore reflects both accounting and risk.
Availability can precede final interbank certainty in some instruments
This is an important risk point.
Banks may provide funds to customers before all return or collection risk has expired. They do this because regulations, product design and customer expectations require usable funds within defined timeframes.
That means the bank can carry exposure.
Checks demonstrate this well. The customer can obtain availability while the check still carries some risk of later return.
Similarly, certain credits can be made available even though exception rights still exist.
This is why finance and risk teams distinguish customer availability from settlement/finality.
Availability is a customer promise
From a product perspective, availability is part of the service promise.
If a bank says an incoming instant payment is available immediately, its posting, balance, fraud and availability processes must support that 24/7.
If a bank advertises same-day payroll credits, operations cannot depend on an overnight posting job.
The promise exposed to the customer must match the actual processing model.
6. Finality: when the transfer becomes legally or operationally conclusive
Finality is one of the most misused words in payments.
It does not simply mean "the screen says done."
Finality describes the point at which a transfer or settlement becomes conclusive under the applicable legal, rulebook or contractual framework.
Different layers can have different finality questions.
Settlement finality asks when the obligation between participating financial institutions is finally discharged.
Customer-payment finality asks when the customer payment can no longer be revoked, cancelled or undone in the ordinary course.
Ledger finality can describe when the bank treats its internal posting as complete.
These concepts can align, but they are not automatically identical.
Fedwire provides a strong finality example
Federal Reserve material states that Fedwire Funds Service payment to the receiving participant is final and irrevocable upon the relevant finality point defined under Regulation J and Operating Circular 6. The service settles in central-bank money by debiting and crediting Federal Reserve master accounts.
That gives the interbank payment a strong legal-finality foundation.
But even then, customer operations still need to distinguish:
- payment order accepted by the bank;
- order accepted by Fedwire;
- receiving participant credited;
- beneficiary account credited;
- customer notified.
The settlement can be final while a downstream customer-posting issue remains operationally unresolved.
Finality does not mean there is never a later return or recovery
This is another critical distinction.
A final payment can still be followed by:
- a separate return payment;
- a request for return of funds;
- a customer refund;
- a legal order;
- a bank adjustment;
- fraud recovery cooperation;
- restitution.
Those later events are new or compensating events. They do not mean the original settlement never happened.
A system that "deletes" the original payment to represent a later refund destroys audit evidence.
The correct model preserves the original final event and links the later compensating event.
Revocability is not identical to finality
A payment can become non-cancellable before all downstream processing is complete.
A payment instruction can also be cancelled before settlement.
Requirements should therefore define:
- until when may the customer cancel?
- until when may the bank reject?
- when does the network accept?
- when does settlement become final?
- what recovery mechanisms remain afterward?
These are separate control points.
7. Gross, net, deferred and prefunded settlement models
Settlement design affects liquidity, credit risk, speed and resilience.
Four broad concepts are especially useful.
Real-time gross settlement
In real-time gross settlement, transactions settle individually rather than being accumulated into a net position.
Fedwire is the classic US example.
Advantages include:
- immediate settlement;
- clear transaction-level finality;
- reduced settlement-credit exposure between participants.
The cost is liquidity intensity. The sending institution needs sufficient settlement capacity when each payment is processed.
Deferred net settlement
In a deferred net settlement model, transactions are accumulated and participant obligations are netted, with settlement occurring at defined times.
This reduces the gross amount of liquidity required for settlement.
But the system must manage the period between clearing and settlement.
Questions include:
- what if a participant cannot fund its net debit?
- are payments provisional before settlement?
- what risk controls or loss-sharing arrangements exist?
- can positions be recalculated?
- what happens to customer credits?
ACH uses scheduled settlement cycles rather than transaction-by-transaction RTGS.
Liquidity-efficient hybrid models
Some systems use sophisticated algorithms, queues, netting or offsetting to reduce liquidity consumption while still processing high-value payments efficiently.
CHIPS is the important US example to understand conceptually.
Do not describe CHIPS as simply "Fedwire but private." Its liquidity-efficient design and rules are materially different.
Prefunded models
A prefunded model requires participants or funding arrangements to maintain value in advance to support payments.
The RTP network uses a prefunded settlement approach.
Prefunding reduces certain settlement-credit risks because payments cannot exceed available funded capacity under the network model.
But the bank must actively manage the prefunded position. A customer can have plenty of money while the bank's network prefunding is insufficient.
That is a routing/liquidity issue, not a customer-funds issue.
Why the settlement model matters to product teams
Product teams often see only customer speed.
Treasury sees:
- funding requirement;
- intraday liquidity;
- prefunding;
- collateral;
- settlement-account balances;
- liquidity buffers.
Operations sees:
- cut-offs;
- queues;
- settlement failures;
- funding alerts.
Finance sees:
- nostro/master account entries;
- clearing accounts;
- suspense;
- GL reconciliation.
Architecture must connect all of them.
8. ACH: settlement is not the end of the risk story
ACH is a perfect instrument for learning the difference between clearing, settlement, posting, availability and return risk.
The ACH chain is:
Originator → ODFI → ACH Operator → RDFI → Receiver
The ODFI submits entries to an ACH Operator. The operator processes and sorts entries. Settlement occurs according to ACH settlement schedules and participant positions. The RDFI posts credits or debits to Receiver accounts.
The important point is that ACH is not simply "sent, therefore final."
Clearing and settlement are scheduled
ACH entries are processed in batches/cycles.
Same Day ACH adds same-day processing windows, but the entry is still an ACH entry. It does not become an instant-payment transaction merely because settlement is accelerated.
A file can be accepted earlier than the settlement event.
A bank can know an entry is coming before the actual settlement posting occurs.
Credit availability has rules
For ACH credits, applicable Nacha requirements and bank operating rules determine when funds must be made available to the Receiver.
A customer may therefore see the credit promptly even though internal reconciliation continues afterward.
Returns remain central to ACH
An ACH entry can be settled and later returned for rule-defined reasons.
This is especially important for debits.
The biller should not interpret initial settlement as absolute economic certainty in the same way it might interpret a final high-value wire settlement.
The bank's accounting policy may therefore distinguish:
- settled amount;
- available cash;
- return-risk period;
- final receivable status.
Reversal is a corrective mechanism, not a generic undo
Nacha allows reversals under defined circumstances.
A reversal is not "the user changed their mind."
Requirements must preserve the original entry and the reversing entry as separate events.
ACH reconciliation needs several checkpoints
For an outgoing ACH file, reconcile:
- customer accepted entries;
- file/control totals;
- operator accepted entries;
- settlement totals;
- ODFI settlement account/position;
- customer debit postings;
- returns and NOCs;
- fees;
- GL.
For incoming ACH, reconcile:
- operator incoming entries;
- settlement;
- customer credits/debits;
- rejects/returns;
- suspense;
- reporting.
The settlement event is only one checkpoint in the full control chain.
9. Fedwire and CHIPS: high-value settlement and finality
Fedwire and CHIPS are both important USD high-value payment systems, but their settlement models are not identical.
Fedwire
Fedwire Funds Service is a real-time gross settlement service operated by the Federal Reserve Banks.
Each qualifying payment order is processed individually.
When a payment order is accepted, the sending participant's Federal Reserve master account is debited and the receiving participant's master account is credited.
Federal Reserve material describes the credit to the receiving participant as final and irrevocable under the applicable Regulation J / Operating Circular 6 framework.
This creates a very different risk profile from an ACH debit.
The sending bank should treat pre-release controls seriously because ordinary cancellation options disappear quickly after acceptance and final settlement.
The downstream receiving bank still needs to:
- validate the beneficiary account;
- post the credit;
- create customer reporting;
- reconcile the Fedwire advice and ledger posting;
- handle investigations if the beneficiary says the payment is missing.
Strong settlement finality does not eliminate operational work.
CHIPS
CHIPS is operated by The Clearing House and is designed for high-value USD payments.
It uses a liquidity-efficient settlement design and private-system rules rather than simply reproducing Fedwire's RTGS model.
The participant bank needs to understand:
- its CHIPS position;
- liquidity requirements;
- payment release;
- final settlement under CHIPS rules;
- correspondent/respondent implications;
- customer posting;
- reconciliation.
A bank may use both Fedwire and CHIPS for USD payments depending on reachability, product, timing, liquidity, correspondent relationships and routing policy.
Chapter 17 later goes deeply into CHIPS. For this foundation chapter, the key lesson is:
two high-value USD rails can both provide strong finality while using different clearing and liquidity mechanics.
Do not infer customer availability from network finality
Even where interbank settlement is final, the receiving bank must still post the beneficiary account.
Customer availability depends on the receiving bank successfully completing that customer-side step.
Network settlement finality therefore cannot be used as a substitute for beneficiary-posting evidence.
10. RTP and FedNow: instant settlement, posting and confirmation
Instant payments compress the lifecycle.
The request, validation, network processing, settlement and status exchange can happen within seconds.
But compression does not erase the conceptual layers.
The bank still needs to know:
- when the instruction was accepted;
- when fraud controls passed;
- when the network accepted;
- when settlement occurred;
- when the beneficiary was credited;
- when funds became available;
- when the payer was told the payment succeeded;
- when reconciliation evidence was written.
FedNow
The FedNow Service operates through Federal Reserve infrastructure. Operating Circular 8 and the FedNow operating procedures govern service use.
The service is designed for instant payments and settles through Federal Reserve accounts according to the service model.
From a system perspective, a bank should not mark the payment customer-complete merely because it successfully constructed a pacs.008.
It needs evidence of the network result and receiving-side treatment.
RTP
The RTP network is a 24/7 real-time payment system with a prefunded settlement model.
Payments under the network rules are designed to provide immediate, final and irrevocable transfer treatment at the network level.
Again, the customer experience depends on receiving-bank posting.
Instant does not mean "skip reconciliation"
Instant payments actually make reconciliation more demanding.
There is no overnight window to fix every difference before the customer wakes up.
The bank needs near-real-time monitoring of:
- network acknowledgements;
- settlement position;
- customer posting;
- duplicate detection;
- rejected or failed credits;
- returns;
- liquidity;
- ledger breaks.
Status sequencing matters
A payer channel should not display "Completed" based solely on local release.
A safer model uses defined states such as:
APPROVED → RELEASED → NETWORK_ACCEPTED → SETTLED → BENEFICIARY_CONFIRMED
The exact network message semantics vary, but the business idea is important: local transmission success is not the same as end-to-end success.
Immediate availability creates a 24/7 dependency chain
If a bank promises immediate availability for incoming instant payments, all of these components become part of the 24/7 service:
- network gateway;
- fraud/compliance controls;
- account validation;
- core posting;
- balance service;
- customer notification;
- reconciliation;
- operational monitoring.
An "instant rail" built on top of batch internal systems creates a false customer promise.
11. Cards and checks: why authorisation or deposit is not settlement
Cards and checks make the distinction between customer event and settlement especially clear.
Card authorisation is not clearing
When a cardholder taps a card, the merchant sends an authorisation request.
The issuer can approve or decline.
An approval tells the merchant that the issuer has authorised the transaction under the card rules and account conditions.
It does not mean final clearing and interbank settlement have occurred.
The issuer may place an authorisation hold against the cardholder's available balance.
Later, the merchant/acquirer presents clearing records.
Clearing determines the transaction amounts, fees and positions.
Settlement follows through the card network's settlement arrangements.
The merchant is funded according to its acquiring agreement.
Therefore:
authorised ≠ cleared ≠ settled ≠ merchant funded
A banking platform that treats card authorisation as a final ledger transaction will misstate customer and merchant positions.
Check deposit is not final payment
A customer deposits a check.
The depositary bank may create a provisional credit.
The bank sends the check image/data for presentment through Federal Reserve, TCH image exchange or another arrangement.
The paying bank may pay or return the item.
Funds availability rules can require the depositary bank to make some or all of the funds available before ultimate return risk has completely disappeared.
Therefore:
deposited ≠ collected ≠ finally paid
This is why checks can create loss even when a customer saw an available balance and withdrew funds.
Regulation CC belongs to the availability story
Regulation CC governs important aspects of funds availability and check collection.
It should not be confused with the settlement rules of Fedwire, ACH or instant payments.
Different legal frameworks answer different questions.
Why Chapter 4 includes cards and checks only at foundation level
Later chapters go deeply into card authorisation, card clearing/settlement, check collection, funds availability and Check 21.
Here, the objective is simply to prevent one conceptual error:
an early customer-facing event is not proof that final settlement has happened.
12. On-us movements: no external settlement does not mean no finality question
On-us transfers do not require an external interbank settlement event when both relevant accounts are on the same bank ledger or settlement domain.
The bank debits one liability account and credits another.
That simplifies the external settlement chain.
It does not eliminate the need to define completion.
What replaces external settlement?
The bank's own ledger rules.
An on-us transfer may be considered complete when:
- debit validation passes;
- both ledger legs post;
- the bank commits the transaction;
- the receiving balance becomes available;
- audit records are written.
The precise point is a bank/product design decision governed by account agreements, applicable law and internal controls.
Do not copy Fedwire wording such as "final and irrevocable" onto an internal transfer without legal and product analysis.
Atomicity matters
The safest internal design treats both sides as one business transaction.
A dangerous failure is:
- debit posts;
- credit fails.
The system should either provide atomic posting or a controlled compensation/recovery mechanism.
The bank must be able to prove:
- payer debit;
- payee credit;
- same amount;
- same business reference;
- consistent value date;
- fees;
- completion timestamp.
Same brand is not always same settlement domain
A banking group can contain multiple legal entities.
Two accounts with the same brand may be on different legal ledgers.
A transfer between those entities can require intercompany settlement or an external rail.
"On-us" should therefore be determined from authoritative legal/account ownership data, not from logo or channel.
Availability can be immediate
On-us transfers can often provide immediate availability because the bank controls both sides.
That can create a better customer experience and reduce external fees/liquidity use.
It also increases the importance of internal fraud controls because the transfer may post very quickly.
13. Liquidity, settlement accounts and intraday control
Settlement cannot occur if the participant cannot meet its settlement obligation.
That is why liquidity is inseparable from settlement design.
Customer funds and settlement liquidity are separate
A corporate customer can have $10 million available.
The bank may still be unable to route a specific instant payment if its relevant network settlement capacity is exhausted.
Conversely, the bank can have abundant settlement liquidity while the customer lacks sufficient funds.
The payment decision requires both layers.
Fedwire liquidity
Fedwire settles through Federal Reserve master accounts.
The bank manages balances, intraday credit arrangements and payment queues according to Federal Reserve rules and its own treasury policy.
A high volume of large-value outgoing wires can consume substantial intraday liquidity.
Treasury may therefore:
- monitor master-account position;
- schedule some nonurgent payments;
- use incoming flows;
- manage daylight overdraft capacity;
- move liquidity between accounts or services.
RTP prefunding
RTP's prefunded model means funding capacity must be available within the network's settlement structure.
The bank cannot send beyond that capacity merely because its customer's account is good.
FedNow liquidity
FedNow settles through Federal Reserve accounts and includes liquidity-management capabilities.
The bank must support the 24/7 nature of instant payments. Liquidity management cannot assume a weekday-only operating day.
Net settlement liquidity
Net settlement can reduce total funding needs compared with gross settlement, but the participant still has to fund the final debit position.
The bank therefore monitors both gross payment activity and expected net position.
Liquidity controls belong in requirements
A payment requirement should identify:
- which settlement account/position is used;
- who owns funding;
- whether prefunding applies;
- intraday limits;
- low-liquidity thresholds;
- queue or reject behaviour;
- alternative routing;
- liquidity alerts;
- end-of-day or continuous reconciliation.
If the requirement says only "send payment to network," treasury requirements are missing.
14. Accounting, reconciliation and evidence across the stages
A payment is operationally complete only when the bank can prove the story from customer intent through settlement and ledger accounting.
This is where the five-stage model becomes useful.
Evidence chain
For an outgoing payment, the bank should be able to link:
customer instruction → approval → network message → clearing/network acceptance → settlement debit → customer debit → beneficiary/network outcome → fees → GL → customer reporting
For an incoming payment:
network receipt → settlement credit → account validation → beneficiary credit → availability → notification → GL → reconciliation
These arrows show evidence linkage, not a universal execution order. Customer debits or provisional credits can precede interbank settlement. In RTP and FedNow, the receiving bank’s acceptance decision precedes settlement; that decision must be distinguished from subsequent customer posting. The exact systems and posting sequence depend on the payment method and bank design.
Reconciliation is not one reconciliation
Banks perform several reconciliations.
Customer-to-payment-hub reconciliation
Did every accepted customer instruction create the expected payment?
Hub-to-network reconciliation
Did every released payment reach the network exactly once?
Network-to-settlement reconciliation
Do network-confirmed transactions agree with settlement positions?
Settlement-to-ledger reconciliation
Do settlement-account movements agree with internal GL/clearing accounts?
Ledger-to-customer reconciliation
Did each completed payment create the correct debit/credit and reporting entry?
Returns/exceptions reconciliation
Did later returns, reversals or adjustments correctly reopen or offset the original position?
A single "reconciled = yes" flag hides too much.
Suspense is evidence of a broken mapping
If money settles but the bank cannot post to the intended customer account, it may need to hold value in a suspense or exception account while operations investigates.
That is not just an IT issue.
Finance needs the balance controlled.
Operations needs the case.
Customer service needs the status.
Risk needs ageing.
The payment system needs the original network reference.
Accounting should preserve gross truth
Do not net away transaction detail purely because settlement uses net positions.
The settlement system may debit one net amount while the bank has thousands of customer transactions.
The accounting and reconciliation model must bridge the aggregate settlement amount back to the underlying transactions.
Timestamps are part of evidence
Store named timestamps:
- instruction accepted;
- released;
- network accepted;
- cleared;
- settlement;
- debit posted;
- credit posted;
- available;
- returned/reversed;
- customer notified;
- reconciliation completed.
The names make investigations much faster than one generic updatedAt.
15. Exceptions, reversals, returns and investigations around finality
Exception terminology should be tied to lifecycle stage.
Reject
A reject normally means the instruction or message did not reach successful processing.
No settlement may have occurred.
Examples:
- invalid message;
- invalid routing;
- participant unavailable;
- account ineligible before release.
The corrective action is usually repair or resubmission, not a return of settled funds.
Return
A return normally represents funds or an entry moving back after the original entry was processed under the applicable rail rules.
ACH uses returns extensively.
Instant-payment rails can support payment returns or return-of-funds-related processes under their rules.
The return should be linked to the original transaction.
Reversal
A reversal is a specific corrective event allowed under defined rules.
ACH reversals are a good example.
The reversal does not erase the original payment.
Recall or request for return
For high-finality push payments, a sending bank may ask the receiving bank to return funds.
That request does not magically cancel a final settlement.
The receiving bank may need customer consent or other conditions depending on the circumstances and applicable rules.
Investigation
An investigation begins when the bank cannot determine the state from normal automated evidence.
Examples:
- network says settled, beneficiary says not received;
- settlement account moved, customer posting missing;
- duplicate network acknowledgement;
- return received without matched original;
- customer ledger shows credit but settlement evidence missing;
- check funds available but item later returned.
A strong investigation platform needs the full evidence chain.
Finality determines the remedy
The later the lifecycle stage, the fewer ordinary cancellation options remain.
Before release: cancel.
Before network acceptance: perhaps withdraw or reject.
After settlement but before posting: fix internal posting.
After final settlement and beneficiary posting: request return, process a refund, use a permitted return mechanism, or open an investigation.
The correct remedy depends on the rail and stage.
This is why a generic cancelPayment() API is dangerous.
16. End-to-end cases, BA checklist and testing
This final section turns the concepts into practical operating scenarios.
Case 1 — payroll ACH credit
A company sends payroll on Thursday for Friday availability.
The ODFI accepts the file.
The ACH Operator receives and clears the entries.
Settlement occurs according to the ACH settlement schedule.
The RDFI receives the entries and posts employee credits.
The employees see funds available according to applicable ACH/bank timing.
Later reconciliation confirms:
- employer debit;
- operator settlement;
- employee credits;
- returned entries if any;
- GL.
What was "complete"?
For the employer, file acceptance was not enough.
For the bank, settlement was not enough if employee posting failed.
For the employee, availability mattered.
For finance, reconciliation mattered.
Case 2 — $4 million Fedwire supplier payment
A corporate approves a $4 million wire.
The bank validates the instruction and releases it.
Fedwire accepts the payment order.
The sending master account is debited and the receiving participant's master account is credited.
The interbank payment becomes final under the applicable Fedwire legal framework.
The receiving bank then posts the supplier's account.
If the supplier says the funds are missing, operations should not conclude "Fedwire failed" merely because the supplier cannot see the credit.
The investigation must compare network advice and beneficiary posting.
Case 3 — RTP invoice payment
A corporate sends an RTP credit.
The network validates and settles through the RTP model.
The receiving bank posts the beneficiary account and makes funds available.
The biller applies the payment to the invoice.
If the network settlement succeeded but the biller's ERP did not match the remittance reference, the payment is financially complete but the receivable is operationally unresolved.
That is why cash application is downstream of settlement.
Case 4 — check deposit
A consumer deposits a $3,000 check.
The depositary bank accepts the item and creates a provisional credit.
Funds become available according to Regulation CC, bank policy and any applicable exception.
The check is later returned unpaid.
The customer's earlier ability to use some funds did not mean the check was economically final.
The bank now follows the return and customer-account process.
This case demonstrates why availability and finality must be separate attributes.
Case 5 — card purchase
A customer buys a laptop.
The issuer approves the card authorisation.
The customer's available credit/balance reflects the hold.
The merchant later submits clearing.
Network settlement follows.
The merchant acquirer funds the merchant according to the merchant agreement.
The initial authorisation did not equal merchant settlement.
Case 6 — on-us rent payment
Tenant and landlord both bank at the same institution.
The tenant sends $2,200.
The bank debits the tenant and credits the landlord internally.
No external settlement occurs.
The bank still must define:
- when the internal transaction is committed;
- when the landlord can use the funds;
- what happens if one ledger leg fails;
- how a bank error is corrected;
- how the event appears on both statements.
Case 7 — settlement completed, posting failed
An incoming instant payment settles.
The beneficiary account interface is unavailable.
The bank has received value but cannot credit the customer.
The payment goes to an internal exception/suspense process.
This is a priority incident because the bank holds the funds while the customer does not have access.
The recovery should not resend the interbank payment. It should repair the customer posting.
Case 8 — customer posted, settlement reconciliation missing
A batch processing error causes customer credits to post, but the settlement control file is not reconciled.
Customers appear correct.
Finance cannot prove the interbank settlement position.
This is still a material operational break.
Customer correctness does not eliminate accounting-control requirements.
Practitioner comparison table
| Instrument/model | Clearing characteristic | Settlement characteristic | Availability/finality lesson |
|---|
| ACH | batch/operator processing | scheduled settlement positions | settlement does not remove return risk |
| Fedwire | transaction-level processing | RTGS in Federal Reserve master accounts | strong interbank finality; beneficiary posting still separate |
| CHIPS | high-value liquidity-efficient clearing | settlement under CHIPS rules | strong finality with different liquidity mechanics from Fedwire |
| RTP | real-time processing | prefunded real-time settlement model | settlement and customer posting should be near-immediate but remain separate events |
| FedNow | real-time processing | Federal Reserve instant settlement | network outcome, settlement, posting and availability need evidence |
| Cards | authorisation then clearing | scheme/acquirer settlement process | authorisation is not settlement |
| Checks | presentment/image exchange | paying-bank/collection settlement | availability can precede ultimate collection certainty |
| On-us | internal validation | no external interbank settlement | internal posting rules define completion; regulation can still apply |
BA requirement checklist
For every payment or collection flow, answer these questions.
Clearing
- Which system or operator receives the instruction?
- What validations happen before settlement?
- Is processing transaction-by-transaction or batch?
- Is netting involved?
- What acknowledgement proves clearing acceptance?
- Can the instruction still be rejected before settlement?
Settlement
- Who are the settlement participants?
- What settlement account or position is used?
- Is settlement gross, net, deferred, hybrid or prefunded?
- When exactly does settlement occur?
- What reference proves settlement?
- Who monitors funding/liquidity?
- What happens if funding is insufficient?
Posting
- When is the payer debited?
- When is the beneficiary credited?
- Can posting occur before settlement?
- What if settlement succeeds and posting fails?
- Which ledger/GL accounts are involved?
- Is posting atomic for on-us?
Availability
- When can the receiving customer use the funds?
- Is availability governed by scheme rule, regulation, bank policy or product terms?
- Are holds possible?
- What balance is shown in the channel?
- Can available balance differ from ledger balance?
Finality
- What rule or legal framework defines finality?
- At which layer is finality being described?
- Until what point can the customer cancel?
- After final settlement, what return/recovery processes remain?
- Are later refunds represented as separate transactions?
Reconciliation
- How are customer, network, settlement and ledger references linked?
- Which controls run intraday?
- What is reconciled end-of-day?
- What suspense process exists?
- Who owns aged breaks?
If those questions are not answered, the lifecycle is not fully specified.
Testing matrix
A serious test pack should include:
Clearing
- valid instruction accepted;
- invalid format;
- invalid routing;
- duplicate;
- participant unavailable;
- cut-off/window failure;
- batch totals mismatch.
Settlement
- successful settlement;
- insufficient participant liquidity;
- queued payment;
- settlement file mismatch;
- duplicate settlement message;
- network acknowledgement without settlement;
- settlement without expected customer posting.
Posting
- debit success/credit success;
- debit success/credit failure;
- settlement success/posting failure;
- posting retry;
- duplicate posting prevention;
- wrong value date;
- suspense posting.
Availability
- ledger credit but funds unavailable;
- funds available immediately;
- hold applied;
- hold released;
- check availability timing;
- incoming instant credit at night/weekend.
Finality and exceptions
- cancel before release;
- reject before settlement;
- return after settlement where allowed;
- reversal under valid conditions;
- invalid reversal attempt;
- request for return after final push;
- customer refund after final payment.
Reconciliation
- all layers matched;
- network missing;
- ledger missing;
- settlement mismatch;
- unmatched return;
- duplicate payment;
- amount mismatch;
- aged suspense item.
Testing must verify customer state + network state + settlement state + ledger state + availability + reporting + reconciliation.
Common misconceptions to eliminate
“Cleared means settled.”
Not necessarily. Clearing can determine obligations before settlement.
“Settled means customer got the money.”
Not necessarily. Customer posting can still fail.
“Posted means available.”
Not always. Holds and availability rules can apply.
“Available means final.”
Not always. Check deposits are the clearest counterexample.
“Final means no later money movement can happen.”
Wrong. A separate refund, return or recovery transaction can follow.
“Instant means all internal systems are instant.”
Only if the bank has actually engineered the full chain that way.
“On-us means unregulated.”
Wrong. Internal routing does not remove applicable law, customer protection or account-agreement obligations.
Final practitioner checkpoint
Before moving to Chapter 5, you should be able to explain:
- the difference between clearing and settlement;
- why customer posting is separate from interbank settlement;
- why ledger balance and available balance can differ;
- why check availability can precede ultimate payment certainty;
- why Fedwire settlement finality is stronger than ordinary ACH return exposure;
- why instant-payment finality does not eliminate posting/reconciliation;
- gross versus net settlement;
- deferred versus real-time settlement;
- prefunding and its liquidity impact;
- why customer funds and bank settlement liquidity are different;
- why an acknowledgement is not always settlement confirmation;
- why a final payment can still be followed by a separate return/refund;
- how to investigate “network settled but customer not credited”;
- why card authorisation is not card settlement;
- how on-us completion should be defined;
- which references and timestamps a bank must preserve to prove the lifecycle.
If those distinctions are clear, you are ready for the next foundation chapter on payment data, remittance and ISO 20022.
Professional depth before you move on
Clearing risk, settlement risk and credit risk are not the same thing
A bank can face several different risks during one payment lifecycle. Processing risk exists while the instruction is being validated and routed. Settlement risk exists where one participant may fail to meet an obligation when due. Credit risk exists when a bank makes value available before it has full certainty that the incoming value will be collected. Liquidity risk exists when the bank cannot meet a settlement obligation at the required time even though it remains solvent overall. Operational risk exists when systems, data, people or third parties fail. These risks can overlap, but they should not be collapsed into one generic paymentRisk field.
This distinction matters because the control changes depending on the risk. A malformed message is not a liquidity problem. A customer with sufficient funds does not solve a bank-level settlement-capacity shortage. A check that later returns is not evidence that the check image was formatted incorrectly. A beneficiary-posting outage after successful network settlement is an operational break, not a failure of the external settlement system.
A useful design habit is to ask at each lifecycle stage: what financial exposure exists if the next step does not happen? That question exposes hidden dependencies much faster than asking whether the overall payment is simply “successful”.
Netting changes liquidity, not the underlying customer truth
Net settlement can dramatically reduce the amount of money participants need to move between settlement accounts, but the bank must still preserve the underlying transaction detail.
Imagine three banks during one clearing cycle. Bank A has $120 million of outgoing obligations and $100 million of incoming obligations. Bank B has $75 million outgoing and $90 million incoming. Bank C has $55 million outgoing and $60 million incoming. The customer transactions total hundreds of millions, but the final settlement positions are much smaller because opposing obligations offset.
The settlement engine may therefore post only a net debit or credit for each participant. Customer accounts, however, still need every individual payment. Reconciliation must bridge the many customer transactions to the few settlement positions.
A good reconciliation design therefore stores a hierarchy such as:
individual transaction → batch/clearing cycle → participant position → settlement posting
If the bank can see only the final net debit but cannot prove which transactions created it, finance has a control problem. If the bank can see every customer transaction but cannot tie them to the settlement position, operations has the same problem from the opposite direction.
Netting therefore reduces liquidity consumption; it does not justify losing transaction-level evidence.
Provisional credit is a controlled exposure, not a finality statement
The word provisional is especially important in checks and some collection contexts. A bank may credit a customer before it has absolute certainty that the underlying item cannot be returned. The customer may even receive availability under applicable law and policy while the bank still carries collection risk.
This is not contradictory. It is a deliberate operating model.
The bank is effectively saying: “we have credited your account and may allow you to use some or all of the funds, but the item can still be returned under the applicable framework.”
This is why a ledger system should not equate CREDIT_POSTED with FINAL_COLLECTED_FUNDS unless the product genuinely supports that conclusion.
The distinction also matters to fraud. A fraudster can exploit the gap between early availability and later return by depositing a bad check and withdrawing available funds. The risk response may include holds, deposit-risk models and account monitoring, but the legal availability framework still applies.
A learner should therefore remember:
provisional posting answers “what did the bank book?”; availability answers “what can the customer use?”; finality answers “what can still be unwound under the governing framework?”
Settlement failure needs a defined operating response
A bank should never design only the happy path “calculate position → settle”. It also needs to understand what happens if settlement cannot occur as expected.
The exact response depends on the payment system. Possible mechanisms across different infrastructures can include queueing, delaying release, requiring additional funding, rejecting new payments, recalculating positions, invoking loss-management rules, suspending a participant, or escalating to contingency procedures. A bank must follow the actual rulebook for the rail rather than inventing a universal response.
From an internal architecture perspective, the important requirement is to preserve state. A transaction that has cleared but not settled is not equivalent to a transaction that never entered clearing. Operations needs to know whether the payment can still settle, whether the customer can be informed, whether customer posting should be delayed or reversed, and whether treasury must fund a position.
A robust state model may therefore need distinctions such as:
CLEARED_AWAITING_SETTLEMENT
SETTLEMENT_QUEUED
SETTLEMENT_FUNDING_REQUIRED
SETTLEMENT_FAILED
SETTLED
Those are business states. The exact technical messages differ by system.
Business day, processing day and value date can diverge
Payments are full of date terms that look interchangeable until an exception happens.
A customer may create an instruction on Monday evening. The bank may process it on Tuesday. Settlement may occur Tuesday. The beneficiary may receive value dated Tuesday. A statement may display the transaction under the original customer instruction date or the posting date depending on the product.
Batch rails make these differences particularly visible. Instant systems compress them, but even there the bank may cross midnight, a reporting boundary or an accounting date.
A proper data model should therefore define, where relevant:
- instruction date/time;
- bank acceptance date/time;
- processing date;
- effective date;
- settlement date/time;
- value date;
- posting date/time;
- funds-availability date/time;
- accounting date;
- return/reversal date/time.
The same field should not be reused for all of these simply because the happy path usually keeps them equal.
This becomes critical for end-of-month reporting, interest, liquidity reporting, tax payments, cutoff handling and customer disputes.
Finality must be stated at the correct legal layer
A system designer should resist writing sentences such as “the payment is final” without naming the basis.
For Fedwire, finality is grounded in the Federal Reserve legal framework, including Regulation J and Operating Circular 6. For FedNow, Operating Circular 8 and the service rules matter. RTP and CHIPS use their own contractual/network rule frameworks. ACH has a different return-and-reversal structure. Checks sit within a different legal and funds-availability environment. On-us transfers depend on account agreements, applicable law and bank ledger rules.
This means one global field called isFinal=true can be dangerously ambiguous.
A stronger design asks:
- final at the network settlement layer?
- non-cancellable by the originator?
- beneficiary funds available?
- return rights expired?
- internal ledger committed?
- receivable economically closed?
The answer can differ by product.
The system can still expose a simple customer status such as “Completed”, but the underlying model should preserve the deeper state.
Central-bank money and commercial-bank money are different layers
When Fedwire settles between participant master accounts, the interbank obligation is discharged in central-bank money. The customer's deposit, however, is a liability of its commercial bank.
That means a $1 million customer payment can involve two different balance-sheet layers:
- the sending bank reduces its liability to the payer;
- settlement moves value between participating banks;
- the receiving bank increases its liability to the beneficiary.
This distinction explains why settlement can be final between banks while the receiving bank still has a customer-posting obligation to complete.
It also explains why internal bank liquidity is not the same as customer balance. The customer owns a claim on the bank. The bank must separately manage the asset/liquidity needed to settle with other banks.
Understanding these balance-sheet layers makes many payment architecture questions easier.
Intraday liquidity is a timeline problem, not only an end-of-day balance problem
A bank can end the day perfectly balanced and still face serious intraday liquidity pressure.
Suppose a bank must send several billion dollars of time-critical payments in the morning but receives large incoming payments only later in the day. The end-of-day net position may be small, yet the bank needs enough intraday capacity to release the morning payments.
This is why payment timing matters to treasury.
RTGS systems make intraday liquidity needs especially visible because payments settle individually. Netting can reduce the requirement. Prefunding moves some of the liquidity decision earlier. Incoming payments can replenish capacity. Queues and payment prioritisation can change the timing profile.
A bank-grade payment product should therefore avoid promising “all valid payments release immediately” without understanding treasury constraints and system rules.
The liquidity design should specify:
- which payments are time-critical;
- whether queueing is allowed;
- whether priority can change;
- what balance threshold triggers an alert;
- whether another settlement source can be used;
- what happens outside staffed treasury hours;
- who owns 24/7 instant-payment liquidity.
A settlement account break is not necessarily a customer-account break
During reconciliation, finance may discover that the settlement account does not match the expected position while every customer debit and credit appears correct.
That can happen because of fees, duplicate settlement records, missing network transactions, timing differences, incorrect internal clearing entries, manual adjustments or data-feed issues.
The reverse can also happen: the settlement account is correct while one customer posting is missing.
These two situations require different investigations.
Settlement correct + customer wrong usually points toward internal posting or customer-account processing.
Customer correct + settlement wrong points toward network/settlement/GL reconciliation.
Both wrong may indicate a deeper processing or duplicate/missing-transaction issue.
The reconciliation dashboard should therefore show the layers separately rather than presenting one red/green payment status.
Suspense accounts must have ownership and ageing
A suspense account is not a permanent solution. It is a controlled temporary location for value that cannot yet be assigned correctly.
If an incoming payment settles but the beneficiary account cannot be credited, the bank may need to hold the amount in a suspense or technical clearing account while the issue is resolved. The design should specify:
- which suspense account receives the amount;
- transaction reference preserved;
- case creation;
- operations owner;
- customer communication rule;
- ageing threshold;
- escalation;
- eventual credit, return or adjustment path;
- GL reconciliation.
A payment can become financially dangerous when suspense items age because ownership of the money becomes unclear and manual corrections accumulate.
The best control is not “operations will fix it.” It is a traceable exception process with measurable ageing.
Customer status should translate, not invent, payment truth
A mobile app often needs only a few simple statuses: Pending, Completed, Failed, Returned. The underlying payment architecture may have dozens of technical and business states.
The solution is not to force the whole bank to use the four customer words. Instead, build a controlled status translation layer.
For example, several internal states may map to customer PENDING while the payment is still cancellable or awaiting network settlement. COMPLETED should map only after the product-defined completion point. A later ACH return should create a new customer-visible event rather than silently rewriting the historical transaction as though it never happened.
The mapping should be documented because customer communication, operations and investigations all depend on it.
A good requirement therefore includes both:
- internal business state — precise enough for operations and accounting;
- customer-facing state — simple enough to understand.
Settlement finality and receivables finality are different business questions
A biller cares about whether an invoice can be treated as paid. A payment-system operator cares about whether participant settlement is final. Those questions are related but not identical.
An ACH debit may settle while return exposure remains. A biller may choose not to treat the receivable as economically final until its defined return-risk treatment is satisfied. An RTP or FedNow credit may provide a much stronger immediate payment-finality profile, allowing faster cash application. A check can be available to the depositor but later returned.
The receivables platform therefore needs its own rule for RECEIVABLE_CLOSED rather than blindly copying the network settlement status.
That rule may consider:
- rail;
- payment direction;
- return rights;
- settlement result;
- posting result;
- remittance match;
- accounting policy;
- customer/business policy.
This distinction is crucial for treasury and collections products.
A bank should be able to answer the “missing money” question in minutes
When a customer says “the sender says it was paid, but I do not see the money,” the bank should reconstruct the lifecycle quickly.
The investigation should answer:
- Was the customer instruction accepted?
- Was the payment released?
- Did the network accept it?
- Did clearing complete?
- Did settlement occur?
- Which settlement reference proves it?
- Did the receiving bank receive the payment message?
- Did the beneficiary account post?
- Was the credit made available?
- Was it later returned, reversed or adjusted?
- Did reporting fail even though posting succeeded?
- Is the payment sitting in suspense?
A bank that cannot answer those questions without searching five systems manually has an observability problem.
The chapter's core model is therefore not academic terminology. It is the structure of a real investigation.
Architecture checkpoint: preserve one business lineage across aggregation
Settlement and clearing often aggregate transactions. Accounting may aggregate again. Reporting may summarise by customer or day.
The challenge is to preserve lineage.
At every aggregation level, the bank should be able to move both directions:
transaction → batch → clearing position → settlement entry → GL
and
GL / settlement break → clearing position → batch → individual transaction
That bidirectional traceability is what turns reconciliation from a manual spreadsheet exercise into a controlled operational process.
Useful identifiers can include customer payment ID, bank transaction ID, file/batch ID, network reference, clearing-cycle ID, settlement reference, booking ID and reconciliation case ID.
The names vary by rail and bank. The requirement is the ability to trace the complete chain.
Final design rule: every “complete” status needs a definition
Before approving a requirement that uses the word complete, ask the author to finish this sentence:
“Complete means that…”
Possible answers are:
- the bank accepted the instruction;
- the network accepted the payment;
- settlement is final;
- the beneficiary account is credited;
- funds are available;
- the biller applied the receivable;
- reconciliation is complete.
Only one of those may be the correct customer promise for a given product.
If the team cannot finish that sentence consistently, the lifecycle design is not finished.
Final precision points before Chapter 5
Payment finality and settlement finality are related, but not identical
Settlement finality asks whether the obligation between settlement participants has been discharged conclusively under the rules and legal framework of the settlement system. Payment finality is a broader business question: has the payment reached the point at which the relevant parties can treat the transfer as completed, subject to the rights and obligations that still exist for that instrument?
The distinction matters because a system can achieve final interbank settlement while the receiving bank still has work to do at the customer layer. The beneficiary credit may still need to post, funds may still need to become available, customer reporting may still need to complete, and a later separate return-of-funds process may still exist without undoing the original settlement event.
A useful model is therefore:
settlement finality = participant obligation discharged
payment finality = product/instrument completion under its governing framework
Do not use one boolean to represent both unless the product has explicitly defined why they are equivalent for that rail and use case.
Principal risk and the Herstatt lesson
Some settlement arrangements involve two linked legs. Foreign-exchange settlement is the classic example: one party delivers one currency and expects another currency in return. Principal risk arises when one side delivers with finality but does not receive the counter-leg. This is often called FX settlement risk or Herstatt risk.
The lesson for a payments learner is broader than FX history. When two obligations are economically linked, settling them independently can expose one participant to the full principal amount if the other side fails between the two settlements. Payment-versus-payment arrangements reduce this risk by making settlement of one leg conditional on settlement of the other.
Chapter 4 does not go deeper into FX infrastructure, but the concept belongs here because it demonstrates why the timing and finality of settlement legs matter. Finality is safest when linked obligations are coordinated rather than relying on one party paying first and hoping the second leg arrives later.
Deferred net settlement: liquidity efficiency can concentrate settlement risk
Consider a simplified deferred net settlement cycle involving three banks. During the day, thousands of underlying payments are exchanged and netted. At the settlement point, Bank A owes a net $40 million, Bank B is due $25 million and Bank C is due $15 million.
If Bank A cannot fund its $40 million obligation at settlement time, the issue is no longer one individual customer payment. The entire calculated position and the system's default-management rules become relevant. Depending on the infrastructure, the response could involve additional funding, loss-sharing, recalculation, collateral, queuing, participant suspension or another rulebook-defined mechanism.
This illustrates the trade-off clearly:
- netting reduces the amount of liquidity that normally has to move;
- deferring settlement means obligations can accumulate before they are finally discharged;
- a participant default at the settlement point can therefore affect more than one bilateral payment relationship.
The correct conclusion is not that deferred net settlement is unsafe. It is that liquidity efficiency and settlement-risk management must be designed together, with legally sound netting and clear default procedures.
Funds-availability law and settlement-finality law answer different questions
Checks make this distinction particularly visible. Funds-availability requirements determine when a bank must make deposited funds available to its customer, subject to the applicable framework and exceptions. Settlement/finality rules determine when obligations associated with the payment item become conclusive and what return or adjustment rights remain.
Those are different legal questions. A customer may receive access to funds before every possibility of a later returned item has disappeared. Conversely, an interbank settlement event does not by itself tell the customer exactly when deposited funds must be available.
A requirement should therefore never state: "the item is settled, therefore Regulation CC availability is complete" or the reverse. The bank must model the availability obligation and the settlement/finality state separately, then connect them through product policy and applicable law.
Operational boundary checks before sign-off
A final requirements review should force every status to declare its layer. If a service says settled, the specification should identify the settlement system, settlement account or position, timestamp and evidence source. If it says posted, the specification should identify the customer or internal ledger and whether the posting is provisional, final or reversible under the relevant product rules. If it says available, the specification should define whether the customer can withdraw, transfer or reuse the funds. If it says final, the legal or scheme basis for that finality should be clear rather than inferred from a user-interface label.
This separation is particularly important in asynchronous processing. A network can complete successfully while a downstream posting service is unavailable. A customer ledger can post before a later reconciliation process proves that the external settlement and internal accounting agree. A receiving bank may make funds available according to its obligations even though a separate exception right still exists. Good design therefore stores distinct timestamps and outcomes for network acceptance, settlement, posting, availability, customer notification and reconciliation instead of overwriting them with one generic completion time.
For operations, the same model determines escalation. A settlement failure belongs with liquidity, network or settlement operations; a posting failure belongs with ledger or account processing; an availability issue may involve product or regulatory rules; a reconciliation break belongs with financial control; and an uncertain network outcome requires investigation before reprocessing. This prevents the dangerous response of simply retrying a payment because one downstream system did not show SUCCESS. The bank must first establish which financial event already occurred.
For testing, timeline assertions should be explicit. A scenario should verify the order and independence of message acceptance, interbank settlement, customer debit, customer credit, availability, notification and reconciliation. Negative cases should deliberately break one downstream stage after an upstream stage succeeds. Those tests prove that the platform can distinguish partial completion from financial failure and can recover without creating duplicate value movement.
Official and primary references
Federal Reserve Financial Services — Fedwire Funds Service
https://www.frbservices.org/financial-services/wires
Federal Reserve Financial Services — Operating Circulars, including OC 6 and OC 8
https://www.frbservices.org/resources/rules-regulations/operating-circulars.html
Federal Reserve Financial Services — Fedwire Funds Service Disclosure / settlement finality
https://www.frbservices.org/binaries/content/assets/crsocms/financial-services/wires/funds-service-disclosure.pdf
Federal Reserve Financial Services — FedNow Service resources
https://www.frbservices.org/resources/financial-services/fednow
Nacha — Same Day ACH schedules and funds availability
https://www.nacha.org/resources/same-day-ach-schedules-and-funds-availability
Federal Reserve Board — Regulation CC, Availability of Funds and Collection of Checks
https://www.federalreserve.gov/paymentsystems/regcc-about.htm
The Clearing House — RTP network
https://www.theclearinghouse.org/payment-systems/rtp
The Clearing House — CHIPS
https://www.theclearinghouse.org/payment-systems/chips
Bank for International Settlements — FX settlement risk and principal risk
https://www.bis.org/committees/bcbs/basel-consolidated-guidelines/module/rma/20
This application uses JavaScript for the full interactive experience. This text summary is served for accessibility and search indexing.