Weekend and Holiday Payment Settlement: What Actually Stops, and What Doesn't

A customer pays at 11 p.m. on Saturday and the authorization approves in two seconds, exactly as it would on a Tuesday. What happens to that money next depends entirely on which rail carries it — and on three separate calendars that operators routinely collapse into one. Transaction processing runs continuously everywhere. Settlement — the actual discharge of the obligation between institutions — runs on the settlement system's own calendar, which for some rails has gaps and for others has none. And the payout a merchant actually sees runs on a third calendar again, set by the PSP. Weekends delay settlement is not a true sentence: some systems pause until the next banking day, and some settle a Sunday-morning payment with full finality while the banks are dark. This reference walks the rails one at a time: when processing continues but the banking day doesn't, where does the money actually stop — and on the rails where it doesn't stop, what mechanism makes that possible?

Scope note. This article owns the mechanism — what each settlement system does when there is no banking day. The treasury response to it — sizing a liquidity buffer for the longest non-processing window, funding cut-offs, calendar-aware funding schedules — is owned by merchant payout treasury operations and is not repeated here.

Three Clocks, Three Calendars

Every payment an operator handles is timed by three independent clocks:

1. Transaction processing — authorization, acceptance, the customer-facing event. Card networks, instant rails, and PSP APIs all take transactions 24/7. Nothing in this layer observes a weekend.
2. Clearing and settlement — the scheme or operator calculating who owes whom, and the settlement system discharging it. This is where calendars live, and every rail's calendar is different.
3. Merchant payout — the PSP moving the merchant's share to the merchant's bank account, on the provider's own schedule, usually across a conventional bank rail with its own non-processing days.

The layers are independently owned and nothing forces them to align. The first clock never stops, the second stops or doesn't depending on the rail, and the third almost always stops — which is why a merchant's weekend experience is set by layer three even when layer two settled on Sunday.

Banking Day, Business Day, Calendar Day

The words matter because the rulebooks use them precisely. A calendar day is any day. A business day is, in Stripe's definition, a working day: its payouts documentation states that calendar days include "every day, including weekends and holidays" while business days include only "working days, typically Monday through Friday, and excludes public holidays". A banking day is a day the relevant settlement institution is open — for US rails, a day the Federal Reserve is open, which is governed by a published holiday schedule with two conventions worth knowing verbatim: "For holidays falling on Saturday, Federal Reserve Banks and Branches will be open the preceding Friday." and "For holidays falling on Sunday, Federal Reserve Banks and Branches will be closed the following Monday." A Sunday holiday therefore takes Monday out of the settlement calendar — the long-weekend case that turns two non-processing days into three.

The distinction is not pedantry; it moves money by whole days. Stripe's own worked example: for a charge created on a Saturday, "If you use calendar days, Saturday is day 0. If you use business days, the next Monday is day 0." Same charge, same delay setting, two days apart before counting even starts. PaymentBrief's Nacha credit-push rules reference already leans on the banking-day concept for funds availability — from 18 September 2026 an RDFI must make non-Same Day credits available by 9:00 a.m. local time on the settlement date — and "settlement date" there means a banking day, never a Saturday.

US ACH: Where Files Go When There Is No Banking Day

ACH is the clearest case of processing continuing while settlement waits. FedACH accepts file transmissions around the clock against published deadlines — but the schedule's footnotes, not its headline table, carry the weekend mechanics.

Footnote 4 is the core rule: "Settlement for ACH items not eligible for same day will occur at 8:30 a.m. ET on the later of (i) the next banking day or (ii) the settlement date that results from the application of paragraph 3 of Appendix B of Operating Circular 4." A file transmitted Friday evening, or any time across the weekend, is processed and distributed on schedule — and then its settlement waits for 8:30 a.m. ET on the next banking day, which is Monday in an ordinary week and Tuesday when a Monday federal holiday intervenes.

Footnote 5 is the one operators discover the hard way: "The 8:00 p.m. ET transmission deadline and 10:00 p.m. ET target distribution occur only Sunday through Thursday, and not on Friday." The late-evening window that exists all week simply isn't there on Friday night. And around each holiday, the FedACH holiday schedule publishes explicit processing-ends and processing-resumes times — for a typical Monday holiday under the current schedule, processing ends at 3 a.m. ET on the Saturday and resumes at 5:30 p.m. ET on the holiday itself. The mechanism to internalise: ACH processing and ACH settlement are decoupled, and only settlement needs a banking day. Cite the living schedule, not a remembered table — the deadlines have changed before and carry effective dates.

The 24/7 Rails: How a Sunday Settlement Actually Works

The interesting engineering question is not that FedNow, RTP, and TIPS run on weekends — their operators say so prominently — but how an interbank obligation can reach finality when no banking day exists. Each of the three answers it differently, and the answers are the substance behind the marketing.

FedNow: the service doesn't close — the business day does. The Federal Reserve's operating procedures describe "an interbank 24x7x365 real-time gross settlement (RTGS) service with integrated clearing functionality that helps enable financial institutions to deliver end-to-end instant payments to their customers." The settlement mechanism is the same one behind every Fed service: "the service settles obligations between financial institutions by generating entries to Federal Reserve Bank Master Accounts." Master-account entries need no branch staff, so value moves with finality at 3 a.m. on a Sunday. What does observe a calendar is the accounting wrapper. The procedures state that the service "does not close", but for accounting and reconciliation purposes the Funds Transfer Business Day "closes and moves to the next cycle day" — at approximately 7 p.m. ET, aligned with the Fedwire Funds close, and "On holidays and weekends when Fedwire Funds is unavailable, the FedNow Service rollover is at approximately 7 p.m. ET." The consequence operators must build for: "Settlement dates are based on the cycle day rather than the calendar date." A payment settled at 8 p.m. Friday carries Saturday's cycle date; a whole weekend of activity carries non-banking-day settlement dates that your reconciliation has to accept as valid. Reporting has its own weekend wrinkle: after rollover a provisional balance is served until end-of-day accounting completes, and "On non-standard business days, such as weekends and holidays, the provisional balance remains until the next standard business day."

RTP: prefunding replaces the banking day. The Clearing House advertises "availability around the clock, including bank holidays, weekends and after hours", and the operating rules show the mechanism that makes the claim honest. RTP participants pay into a Prefunded Balance Account, defined as "The special deposit account established for the joint benefit of all Funding Participants and Funding Agents by the Prefunded Balance Account Bank for the purpose of supporting the operations of the RTP System." Every payment adjusts positions against that already-funded pool, so no interbank transfer needs to happen at the moment of payment — the money was positioned in advance. Finality is then a bookkeeping event the rules make explicit: settlement is complete when the system records the decrease in the sender's net position and the increase in the receiver's, and "Completion of settlement constitutes final settlement of the RTP Payment and final discharge and payment of a Sending Participant's obligation to pay the amount of the Payment Message to the Receiving Participant under Rule III(D)." Note the date convention differs from FedNow's: an RTP Day is "The calendar day in which an RTP Payment is made, beginning at 12:00 a.m. and ending at 11:59:59 p.m. ET." — a calendar day, not a rolled cycle day. Two 24/7 rails, two different answers to the question of what date a payment settled.

TIPS versus T2: one currency, two calendars. The euro area runs the same split explicitly. The ECB's T2 page states the large-value calendar plainly: "T2 is open from Monday to Friday and closed on Saturday and Sunday." — and for euro settlement it is additionally closed on six euro closing days: 1 January, Good Friday, Easter Monday, 1 May, 25 December, and 26 December. TIPS, sitting beside it on the same TARGET Services platform, has no calendar at all: "Settlement in TIPS takes place in real time and in central bank money, 24 hours a day, 365 days a year." Same central bank, same currency, same central-bank-money finality — and an instant payment settles on Easter Sunday while a large-value transfer waits until Tuesday. The generalisation to carry away: 24/7 settlement is achieved either by keeping central-bank ledger entries available around the clock (FedNow, TIPS) or by prefunding a pool so the settlement-critical money moves before the weekend starts (RTP). Both push the liquidity problem upstream — the funding of the master account or prefunded pool still depends on rails with calendars, which is precisely the treasury problem the payout-treasury article owns.

Cards: A Daily Net, on Visa-Defined Dates

Card settlement is scoped honestly here, because the public rulebook supports less than operators often assert. What Visa's public rules do establish is the shape: clearing produces a Settlement Amount, defined as "The daily net amounts expressed in a Member's Settlement Currency resulting from Clearing." — a daily net, not a per-transaction transfer. The Settlement Date is "The date on which Visa initiates the transfer of Settlement Amounts in the Settlement of Interchange." — a Visa-initiated date, not one the merchant or acquirer picks. And the glossary's Deferred Settlement — a settlement funds transfer occurring "more than 2 business days after the Processing Date" — confirms the rulebook thinks in business days at this layer.

What the public rulebook does not contain is a weekend or holiday settlement calendar, and this article will not invent one. Whether and how a given member's Saturday net settles rests on scheme schedules and member agreements that are not in the public edition. For an operator the honest model is: the card leg produces a daily net on Visa-defined dates, and everything you can actually observe and manage about weekend timing lives one layer down, at the PSP.

The PSP Payout Layer: Where the Weekend Becomes Visible

Whatever the scheme leg does, the merchant experiences the payout schedule — and payout schedules are business-day artefacts, because the payout itself usually travels on a bank rail with a banking-day calendar. Stripe's documentation is explicit on both halves: on a daily schedule, "Stripe automatically transfers your available funds every business day." and "Payouts scheduled on weekends or holidays arrive on the next business day." Combined with the calendar-day/business-day distinction above — which Stripe applies per country, business days for the US and Australia, calendar days for the UK and EU — two merchants with identical volume and identical delay settings can see materially different weekend behaviour purely from the day-counting regime their country uses.

Adyen makes the consolidation explicit rather than implicit: as PaymentBrief's PSP reconciliation failure runbook documents from Adyen's sales-day payout model, Friday, Saturday, and Sunday transactions are consolidated into a single batch paid out the following week, with the exact day set by the configured payout delay. Three sales days landing as one settlement event is not an error to investigate; it is the documented weekend behaviour of that provider.

What This Does to Monday

The operational consequences follow directly from the mechanisms, and each is per-rail:

• Monday accumulation on batch rails. Where settlement waits for a banking day, Monday (or the day after a holiday) carries the accumulated weekend: three days of ACH files settling at one 8:30 a.m. moment, three sales days in one PSP batch. Exception queues, limit checks, and anything alerting on daily settlement value needs weekend-aware baselines, or every Monday looks like an anomaly.
• Settlement date ≠ transaction date, visibly. On 24/7 rails the settlement date is real but unfamiliar — a Saturday cycle date from FedNow, a Sunday RTP Day — while on batch rails the settlement date detaches from the transaction date by two or three days. Pipelines that normalise multiple providers' files, per the settlement-data ingestion reference, must carry both dates as first-class fields; keying on either alone breaks every weekend.
• Liquidity moves upstream, not away. A rail that settles on Sunday still has to be funded, and the funding legs — master-account balances, RTP prefunding top-ups, payout-account funding — ride calendars of their own. That buffer-sizing and funding-cut-off discipline is the treasury article's territory; the mechanism-level point is that 24/7 settlement relocates the weekend problem rather than deleting it.

Operator Checklist

• Model three calendars per flow — processing, scheme/operator settlement, payout — and never assume any two align.
• For each rail you touch, write down what its rulebook or schedule actually says happens with no banking day; cite the living schedule, not a remembered table.
• Treat non-banking-day settlement dates (FedNow cycle days, RTP calendar days) as valid values in every downstream system.
• Reconcile weekend PSP batches against the provider's documented consolidation behaviour before opening a discrepancy investigation.
• Build Monday-aware baselines for settlement-value monitoring and exception staffing.
• Hand the funding consequences to treasury explicitly — the longest non-processing window in your combined calendars is their input.

Related References

• Merchant Payout Treasury Operations — the treasury response: buffer sizing, funding cut-offs, and calendar-aware funding schedules for the gaps described here.
• Settlement Data Ingestion and Normalisation Across Multiple PSPs — carrying transaction date and settlement date as separate first-class fields.
• PSP Reconciliation Failure Runbook — weekend batch consolidation as a reconciliation scenario, including the Adyen Friday–Sunday case.
• Nacha Credit-Push Fraud Rules: An ACH Operator Reference — the banking-day-based funds-availability rules on the receiving side of ACH.
• Fedwire or CHIPS: when the rail behind a USD wire matters — participation, settlement semantics and cutoffs on the two US large-value rails.