Always-On Settlement, Always-On Treasury: The Liquidity and Exception Clock

“24/7” describes a window, not an end-to-end operating state

Consider three terms that often appear together.

Available can mean a network will accept and process a message. It does not necessarily mean every participant is sending, every downstream system is posting, or every support function is staffed.

Instant or real-time describes processing speed once the prerequisites are satisfied. It says less about whether the necessary balance, quote, beneficiary approval or bank endpoint was usable before the instruction was sent.

Final describes a settlement state under a rail’s rules. It does not by itself establish that the original invoice, trade, payroll obligation or internal ledger entry has been reconciled and closed.

The U.S. instant-payment rails show why this distinction is useful. The Federal Reserve’s FedNow operating-hours page says the service processes instant-payment messages continuously across a 24-hour funds-transfer business day every day of the week, with no processing interruption at its roughly 7:01 p.m. ET business-day rollover. But FedNow’s Liquidity Management Transfer messages have their own window: 7 p.m.–7 a.m. ET on weekdays and 24 hours on weekends and Federal Reserve holidays. The same operating-hours page also notes that certain Federal Reserve activities may not be available outside standard business days and core hours.

That is not evidence that FedNow “stops” outside business hours. It is evidence that the payment clock and a specific liquidity-management clock are different clocks.

The accounting layer can differ again. Federal Reserve accounting materials say daily statements and reconcilement data are available seven days a week, including weekends and holidays, and that institutions decide for themselves how to ingest weekend and holiday accounting activity. In other words, the evidence clock can be continuous even where a participant’s internal processing model is not.

Counterevidence matters: liquidity can be designed to stay on

The strongest version of the “always-on rail, part-time liquidity” thesis is too broad.

The Clearing House describes the RTP network as operating 24/7. It requires receiving institutions to make funds available immediately, subject to limited exceptions in the RTP rules, and describes settlement as final and irrevocable. More importantly for the treasury question, The Clearing House also documents a funding-agent model: funding agents manage settlement accounts and provide 24/7/365 liquidity for participating institutions.

That architecture does not prove every RTP participant has identical liquidity depth, internal controls or support coverage. But it is important counterevidence. An institution does not necessarily have to reproduce every round-the-clock treasury function internally. Some dependencies can be prefunded, automated, delegated or covered by a specialist service provider.

The reviewer therefore should not ask, “Is treasury 24/7?” as if there were one binary answer. A better set of questions is: Which liquidity function is needed at this point in the flow? Who owns it? What window is documented? What happens when that path is unavailable?

Stablecoin settlement adds another boundary: the bank edge

Stablecoins make the clock separation especially visible because onchain transfer and bank-money conversion can have materially different operating conditions.

Circle Mint is an institutional product, and Circle’s USDC terms distinguish between eligible Circle Mint customers who can redeem directly and other holders who cannot redeem directly with Circle unless they become eligible and open an account. The terms cited here apply to holders outside the EEA; other jurisdictions can have different rules.

Circle’s current developer documentation then separates three states that are easy to conflate. A domestic wire deposit received before the daily cutoff typically settles the same business day. Supported real-time interbank rails can settle in seconds, subject to the relevant network’s hours and limits. A fiat payout created through redemption typically settles on the next business day. Meanwhile, onchain transfers move through pending, running and complete, with complete reached after the required blockchain confirmations.

So “USDC can move onchain now” and “the institution has usable fiat in its bank account now” are not the same statement. Neither is “the payout API returned complete” necessarily the end of the exception clock: Circle’s withdrawal documentation notes that a bank-side issue can still cause a wire to be returned after a payout reaches a completed status, with webhook monitoring available for returned payouts.

This is where exception design becomes part of liquidity design. A treasury operation needs to know not only when conversion was requested, but when the fiat became usable, which status was authoritative, how a return is detected, who owns it, and what evidence closes the break.

Bank settlement can extend faster than support and close processes

The recent SoFi/Payward announcement is a useful live-company example, but it needs narrow wording. SoFi says Payward is joining the SoFi Exchange Network and that institutional clients can clear and settle U.S. dollar transactions 24 hours a day, seven days a week. Kraken’s same-day participant post describes access to the same SEN rails. These are two participant statements about one underlying partnership announcement, not two independent operating outcomes.

The claim that is supported is about the announced architecture and availability window. The public sources reviewed here do not establish recurring reliability, adoption, participant-specific liquidity limits, exception-resolution targets or internal reconciliation closure times.

The Bank of England’s CHAPS work shows the same timing problem from a different direction—and with unusually explicit operational detail. The Bank’s February 2026 policy statement decided to move the CHAPS start from 06:00 to 01:30, Monday to Friday, with implementation targeted for September 2027. Sending in the early-morning extension will be optional, while all direct participants will receive payments from 01:30. The Bank also says each participant can decide when to process those received payments into internal systems and when to credit its own or end-user accounts, subject to applicable law.

That is a clean separation between rail receipt and internal funds availability.

The planned support model separates exception clocks too. The Bank says 24×7 technical monitoring will generate alerts. Critical settlement-impacting incidents in the early-morning window will trigger escalation and response. Non-critical, idiosyncratic or non-core incidents can wait until core settlement hours. Detection can therefore be continuous while resolution is explicitly severity-dependent.

And the accounting clock remains visible. In its May 2026 consultation on later phases of near-24×7 settlement, the Bank notes that current RTGS end-of-day/start-of-day processing includes reconciliation, accounting close-off, booking end-of-day balances and interest. It also warns that extending hours can require changes to liquidity provision, staffing, value-date treatment, batch processing and operational support, particularly if money markets or other infrastructure do not extend in parallel. Those later weekend and longer-day steps are proposals, not current operating hours.

The lesson is not that longer settlement hours are bad. It is that operating-hour design is a dependency map.

The Liquidity and Exception Clock

The owner column is deliberately functional rather than a named company role. Public documents often identify the rail and process but do not disclose the internal on-call roster, acknowledgment target, escalation matrix or time-to-resolution commitment for a specific participant. Not disclosed is not the same as nonexistent.

Illustrative synthetic example

At 02:15 UTC on a Sunday, an institution receives an onchain stablecoin transfer and the required confirmations are reached. That is the settlement timestamp for the token leg.

The institution’s next obligation is to make USD available in a bank account. Its direct redemption path is eligible, but the documented payout timing for the chosen route is next business day. Monitoring records the payout state automatically. If the receiving bank later returns the wire, the exception clock starts a new phase: detection, acknowledgment, ownership, investigation, retry or alternative handling, and finally reconciliation closure.

Nothing in that example implies a real incident, loss amount, expected delay or recommended liquidity buffer. It simply shows why one financial event can carry several valid timestamps.

What a reviewer should ask before calling an operation “always on”

The practical test is evidence, not adjectives.

For each material flow, record the rail’s acceptance window and the state that constitutes settlement or finality. Then record when funds become economically usable at the next layer. Identify the funding or liquidity mechanism needed at that moment, including issuer redemption and FX where relevant. Separate system monitoring from human acknowledgment and human resolution. Preserve the internal posting time, the reconciliation result and the point at which the exception is actually closed.

Finally, identify what is not in the public evidence: participant-specific cutoffs, support tiers, capacity limits, backup providers, acknowledgment targets, resolution targets, weekend staffing, or close procedures. Those become review questions—not assumed deficiencies.

This is the meaningful change when settlement windows expand. Treasury does not automatically become a 24/7 dealing desk, and every bottleneck does not automatically migrate to liquidity. Instead, the operating model becomes easier to falsify: the next narrow window can be named, timed, owned and evidenced.

That is what the Liquidity and Exception Clock is for.

What this does not prove

Final caveat