The thesis: an extra settlement day turns the calendar into data.
On 9 October 2025 the Federal Reserve Board announced that the Reserve Banks will expand the operating days of the Fedwire Funds Service and the National Settlement Service to include Sundays and weekday holidays. The decision was published on 17 November 2025 at 90 FR 51356 under Docket No. OP-1870. Fedwire moves to 22 hours a day across six operating days, Sunday through Friday. NSS follows at 21.5 hours, closing 30 minutes earlier as it does today. The Board expects the Reserve Banks to implement it in 2028 or 2029.
Most coverage of that decision, reasonably enough, is about liquidity and cross-border settlement. There is a second consequence that lands squarely inside finance systems, and it is easy to miss because it is a definitional change rather than a technical one. Today the phrase business day resolves to one shared answer across a payment estate. The rail is open on weekdays, the regulation counts weekdays, the banks are open on weekdays, and the ERP holiday table lists the same weekdays. After implementation, those stop agreeing. Fedwire will treat Sunday as a business day. Regulation CC will not. Each bank chooses for itself whether to participate in expanded hours and where to put its cutoff times.
The encouraging part is the runway. Two or three years of notice on a change of this shape is unusually generous, and the work it invites is worth doing for its own sake. A payment calendar that is named, owned, sourced from a citable authority and versioned by effective date pays back on every payment run between now and then, in fewer missed cutoffs, cleaner value dating, and due dates a supplier dispute cannot unpick. The Fedwire change is the reason to schedule it. The benefits arrive well before 2028.
What the Board actually decided.
The 2024 proposal asked about going straight to 22 hours a day, seven days a week, every day of the year. It drew 145 comment letters from 37 states. Large banks, financial market utilities, service providers and fintech firms largely supported it. Small and midsize banks largely did not, citing staffing, operational change and competitive pressure. The Board landed on six days as an interim step, and set out the schedule in detail.
| Service | Hours and days | Worth knowing |
|---|---|---|
| Fedwire Funds Service, today | 9:00 p.m. ET of the preceding calendar day to 7:00 p.m. ET, five days a week, Monday through Friday, excluding holidays observed by the Reserve Banks. | Twenty-two hours a day across five operating days. The operating day is named for the day it closes on. |
| Fedwire Funds Service, planned | The same daily hours, six days a week, Sunday through Friday, including weekday holidays. | A Sunday operating day opens at 9:00 p.m. ET on the Saturday. The Board decided against changing the opening or closing times. |
| National Settlement Service, today | 9:00 p.m. to 6:30 p.m. ET, five days a week, Monday through Friday, excluding holidays observed by the Reserve Banks. | NSS settles obligations arising from private-sector clearing arrangements. It closes 30 minutes before Fedwire by long-standing convention. |
| National Settlement Service, planned | 21.5 hours a day on the same six operating days, still closing 30 minutes before the Fedwire Funds Service. | The 30 minute gap is deliberate. Fedwire is the fallback if a multilateral settlement cannot complete through NSS. |
| Saturday | Stays closed. | Fedwire keeps 26 hours of weekend downtime, from the 7:00 p.m. ET Friday close to the 9:00 p.m. ET Saturday open. Participants and the Reserve Banks use it for maintenance and testing. |
| Fedwire Securities Service | Not expanding. | Transfers between participants run 8:30 a.m. to 3:30 p.m. ET on weekdays, with self-repositioning to 7:00 p.m. ET. Collateral has to be pledged ahead of a weekend or a weekday holiday. |
| FedACH and check services | No current plans to expand processing days. | The Board said any expansion of ACH or check settlement into the weekend or holidays warrants public consultation first. |
| Beyond six days | Possible, and not decided. | The Board will stand ready to offer 22x7x365 no sooner than two years after 22x6 goes live, and would issue a fresh Federal Register proposal before deciding. |
Two details in that table carry more weight than their length suggests. Participation is optional, and the Reserve Banks are keeping it that way. And the Board chose the 2028 to 2029 window partly to give the industry room to finish work related to the Fedwire Funds Service migration to ISO 20022, which completed in July 2025. The same window is available to finance teams, and it is long enough to do the data work calmly.
@federalreserve announces expanded operating days of two large-value payments services, Fedwire® Funds Service and the National Settlement Service (NSS), to include Sundays and weekday holidays
Six calendars, and only one of them is yours.
Ask a finance systems team where the business day is defined and the usual answer is a holiday table, loaded once, shared across company codes. That answer has been serviceable because every calendar it stands in for happened to look the same. Here is what it is actually standing in for.
| Calendar | What it says | Who sets it |
|---|---|---|
| The Fedwire operating day | Sunday through Friday, weekday holidays included, from 2028 or 2029. | Set by the Reserve Banks. This is the clock that decides when central bank money actually moves, and it is the one that is changing. |
| The Regulation CC business day | Any calendar day other than a Saturday, a Sunday, or one of ten named federal holidays. | Set by regulation at 12 C.F.R. 229.2(g), and unchanged. The Board confirmed no amendment to Regulation CC is needed for the expansion. |
| The Regulation CC banking day | The part of a business day on which an office of a bank is open to the public for substantially all of its banking functions. | A subset of the business day, defined at 12 C.F.R. 229.2(f), and specific to each bank and each office. |
| Your bank’s funds-transfer business day | Whatever the bank declares, plus its own cutoff times. | Participation in expanded hours is optional. A bank that does not treat Sunday as a funds-transfer business day is not required to act on payment orders received then until its next one. |
| Your contract’s business day | Whatever the contract says, which is often defined by reference to Fedwire. | The Board noted that private parties often use the Fedwire Funds Service operating day to define the term, and said it expects those parties to adapt their contracts. |
| Your ERP calendar | A holiday table, usually loaded once, usually shared across every company code and every payment method. | This is the one you control. It is also, in most systems, the only one of the six that nobody owns by name. |
The Regulation CC line is the one to sit with. Its business day definition at 12 C.F.R. 229.2(g) is a calendar day other than a Saturday or a Sunday and other than ten specifically named federal holidays, and the Board confirmed that no amendment to Regulation CC is needed to facilitate the expansion. Depository institutions in scope are deemed not to receive funds from wire transfers on weekends or holidays, and are not required to make those funds available for withdrawal on those days. A Sunday Fedwire settlement is therefore final, and the funds behind it are not necessarily available. Both of those statements are correct at the same time, and a system that holds one date field cannot record both.
The contract line matters just as much and is easier to act on. The Board acknowledged that private parties often rely on the Fedwire Funds Service operating day for contractual definitions, including for the term business day, and said it believes those parties will be able to adapt their contracts after the expansion. That is an invitation to read your own templates now. A definition that points at Fedwire will change meaning by itself, on a date set by someone else, in every agreement that carries it.
Four dates that used to be one.
Once the calendars separate, so do the dates on a payment. Most systems already carry fields for several of these and populate them all from the same source, which works right up until the sources diverge.
| Date | What it records | What decides it |
|---|---|---|
| Settlement date | When the Reserve Banks credit the receiving participant. On the planned schedule this can be a Sunday or a weekday holiday. | Immediate, final and irrevocable. It happens whether or not the receiving bank has opted into expanded hours, because the Reserve Banks will still deliver and settle. |
| Availability date | When funds have to be made available for withdrawal under Regulation CC. | Banks are deemed not to receive funds from wire transfers on weekends or holidays for Regulation CC purposes, and are not required to make those funds available on those days. |
| Bank posting date | When the transaction appears on a statement, in the value date field, and in the balance your reporting reads. | A per-bank answer that depends on whether it opted in, which of its systems run on the expanded day, and where it set its cutoff. |
| Accounting date | The period the entry belongs to in your ledger. | Derived from a calendar you own. A Sunday settlement at the end of a month is a period-end question before it is anything else. |
| Terms date | The day a net 30 clock starts and the day it ends, after any business day adjustment. | Governed by the contract, which may itself define business day by pointing at Fedwire. Two contracts on the same invoice run can end up on different calendars. |
The optional participation model is what makes the third row genuinely per-bank. A participant that has not adopted expanded hours still receives the payment: the Reserve Banks will continue to deliver payment orders sent to it and settle them by crediting its settlement account. What changes is obligation. If a Sunday is not a funds-transfer business day for that participant, or the order arrives after a cutoff it has set for that day, it is not required to act until its next funds-transfer business day. Sent, settled, acted on and available become four separate facts about the same payment.
Collateral timing deserves its own note because it moves the other way. The Fedwire Securities Service is not expanding, and the Board said so plainly, acknowledging that participants will need to anticipate needs for and pledge securities in advance of weekends and weekday holidays. Intraday credit will be available during expanded hours on the same terms as today, and the expectation to avoid overnight overdrafts applies across weekends and holidays too. Any liquidity model that assumes every service moved together will be wrong in the direction that costs money.
#ISO20022 makes it easier to understand #payments processed through the Fedwire Funds Service.
The payment calendar as a governed object.
The fix is not a new module. It is promoting something that already exists from configuration to master data, with the attributes master data normally carries: a name, an owner, a source, a version and an effective date. Here is what a calendar record needs to hold.
calendar_id
A named calendar rather than a flag. One per rail and per jurisdiction at minimum: Fedwire operating days, FedACH processing days, Regulation CC business days, the local statutory holiday list, and each bank relationship that differs from its rail.
authority
Where the calendar comes from, as a citable source rather than a note. The Reserve Banks for a Fedwire calendar, 12 C.F.R. 229.2(g) for the Regulation CC list, the contract clause reference for a contractual one. A calendar without an authority cannot be audited or refreshed.
effective_from and effective_to
Calendars change on dates. The Fedwire calendar has one shape until the Reserve Banks implement 22x6 and another after. Storing a single current calendar makes it impossible to reprice a historical payment or to model a future one.
open_days and exception_dates
The recurring pattern plus the named exceptions. Exceptions carry a reason and a source, so a date that is closed for a federal holiday and a date that is closed for an announced extended maintenance window are distinguishable.
open_time, close_time and time_zone
A calendar without hours cannot answer a cutoff question. Store eastern time explicitly for a Fedwire calendar rather than in local time, and let the system convert.
participant_opt_in
Per bank relationship, per expanded day. This is the field that does not exist in any ERP today, because until now every participant was open on the same days.
cutoff_times
Per bank, per rail, per day type. A bank may opt into Sunday operations and still close its own window earlier on that day than on a Tuesday.
adjustment_convention
Following, modified following, preceding, or none, held against the contract rather than as a global setting. This is the field that turns a calendar into a due date.
One calendar record, carrying its authority and its exceptions
{
"calendar_id": "FEDWIRE_FUNDS_OPERATING_DAYS",
"authority": "Federal Reserve Banks, per 90 FR 51356 (Docket OP-1870)",
"effective_from": "2029-01-01",
"effective_to": null,
"status": "planned",
"time_zone": "America/New_York",
"open_days": ["SUN", "MON", "TUE", "WED", "THU", "FRI"],
"open_time": "21:00 (preceding calendar day)",
"close_time": "19:00",
"includes_weekday_holidays": true,
"exception_dates": [],
"linked_calendars": {
"availability": "REG_CC_BUSINESS_DAYS",
"securities_collateral": "FEDWIRE_SECURITIES_WEEKDAYS"
},
"bank_relationships": [
{
"bank_id": "BANK-0417",
"participant_opt_in": { "SUN": true, "WEEKDAY_HOLIDAY": false },
"cutoff_times": { "SUN": "16:00", "DEFAULT": "18:00" }
}
]
}Two fields in that record are the ones worth arguing about internally. The authority field looks like documentation and behaves like a control: a calendar that names its source can be refreshed by anyone, verified by an auditor, and corrected without archaeology. The participant_opt_in field does not exist in any finance system today, because until now there was no such thing as a bank that was open on a day its rail was not. Adding it while it can sit empty is a schema decision. Adding it in 2028 is a change request with a date attached.
The linked_calendars idea is worth taking seriously too. Availability follows a different calendar from settlement, and collateral follows a third. Modelling those as links between named calendars rather than as logic inside a payment program keeps the relationship inspectable, which is what makes a cash forecast explainable when someone asks why a Sunday inflow did not raise the available balance.
Implementation checklist.
Find every place a business day is decided today. Payment terms, dunning, late payment interest, FX rate date selection, bank statement import, cash forecasting, cutoff warnings, intercompany settlement, and the treasury workstation each hold an answer. In most estates the same holiday table has been copied into several of them and has drifted apart since.
Give each calendar a name and an owner. The single largest improvement available here costs nothing and needs no vendor: stop calling it the holiday table and start calling it the Fedwire calendar, the Regulation CC calendar, and the calendar for a specific bank relationship. Naming them makes the disagreements visible, and the disagreements are the finding.
Record the authority for each one. A calendar sourced from a regulation should cite the regulation. A calendar sourced from a bank should cite the bank agreement or the service circular. This is the difference between a table you can refresh with confidence in 2028 and a table nobody dares touch.
Version the calendars rather than overwriting them. The Fedwire calendar in force in 2027 and the one in force after implementation are different objects. Repricing a payment made last year, or modelling a payment run in the first expanded month, both need the right version rather than the current one.
Separate settlement date from availability date in the payment record now. They coincide today for most flows, which is exactly why the distinction is cheap to introduce today and expensive to introduce during a go-live. Regulation CC already treats them differently for wires received on a weekend.
Add an opt-in attribute to the bank relationship master. Leave it null until banks publish their intentions. An empty field that exists is a question you can answer later. A field that does not exist becomes a schema change under time pressure.
Ask each banking partner two questions in the next relationship review: whether they expect to support expanded operating days, and where their cutoff times would sit on a Sunday or a weekday holiday. Their answers will change over the next two years, which is a reason to record them with a date attached rather than a reason to wait.
Read your own contract templates for the phrase business day. Where it is defined by reference to Fedwire, note it. The Board expects parties to adapt their contracts, and a contract review that starts now is a paragraph in a renewal rather than a repapering exercise.
Plan collateral timing against a calendar that is not moving. The Fedwire Securities Service is not expanding, so securities have to be pledged in advance of a weekend or a weekday holiday. Treasury teams that model liquidity on a single calendar will get this wrong in the direction that costs money.
Treat fraud controls as a staffing and automation question, not a systems one. Commenters told the Board that fraud risk is often greater on weekends and holidays. Whatever monitoring runs on a Tuesday needs an answer for a Sunday, and that answer is usually people or rules rather than a new module.
Sequence it by what is already true. The discovery step and the naming step describe the estate as it stands and need nothing from anyone outside the team, so they can start this quarter and will surface drift that is costing money today. Versioning and the extra date fields come next, since they are schema work best done while nothing depends on the outcome. The bank conversations and the contract review run on other people’s timetables, which is precisely why they benefit from an early first pass and a second one closer to the go-live window.
Constructive failure modes to design around.
Treating the change as a 2028 project. The runway is the useful part. Naming calendars, recording their authority and versioning them are improvements that pay for themselves against today’s payment runs, and doing them under a deadline turns a data-modelling exercise into a migration.
Assuming one global holiday table can absorb it. It could when every rail and every participant observed the same days. A six-day Fedwire week alongside an unchanged Regulation CC business day and a per-bank opt-in makes a single table structurally unable to hold the answer.
Reading settled as available. The Reserve Banks will deliver and settle a payment on a Sunday whether or not the receiving bank opted in. Regulation CC separately deems banks not to have received wire funds on a weekend and does not require availability then. A cash position built on settlement alone will show money that cannot be spent yet.
Forgetting that participation is optional. Fedwire being open is not the same as your counterparty’s bank being open. A payment sent on a Sunday to a participant that has not opted in will settle to that participant’s account, and the participant is not required to act on it until its next funds-transfer business day.
Letting cutoff times live in documentation. Cutoffs already differ by bank and by rail. Adding day types multiplies them. Cutoffs held in a wiki page cannot warn a user at 4:30 p.m. on a Sunday, and a system that cannot warn will let the payment sit.
Modelling liquidity as if every service expanded together. Fedwire and NSS are expanding. The Fedwire Securities Service is not, and the Board has no current plans to expand ACH or check processing days. Anything that needs collateral movement or an ACH leg still runs on the weekday calendar.
Overwriting a calendar when the go-live window narrows. The Reserve Banks will publish a specific window closer to the time, through channels such as their service pages. That is an update to a versioned record with an effective date, and a team that overwrites the old one loses the ability to explain any payment dated before it.
The common thread is a single assumption that has quietly held for decades: that everyone involved in a payment agrees on which days count. It held because the rails, the regulation and the banks all observed the same days. A six-day settlement week retires the assumption in an orderly way, with years of notice, which is about as gentle as an assumption of that size ever gets retired.
What to ask ERP and treasury vendors now.
Can the system hold more than one business day calendar, and attach a specific calendar to a specific payment method, bank relationship and contract rather than to the company code alone?
Are calendars versioned with effective dates, so a payment made in 2027 and a payment modelled for 2030 each resolve against the calendar in force at that time?
Does the payment record store settlement date, availability date, bank posting date and accounting date as distinct fields, or does one date field serve all four?
Can a bank relationship record carry per-day-type attributes, including whether that bank operates on an expanded day and what its cutoff time is on that day?
Does the due date engine hold its adjustment convention against the contract, so two contracts in the same payment run can follow different conventions?
Can cutoff logic warn a user before a payment is released, using the calendar and cutoff for that specific bank and day rather than a single global cutoff?
Does cash forecasting distinguish a settled inflow from an available balance, and can it show both for the same day?
Can the calendar be sourced or refreshed from a named authority, with the source recorded on the record rather than in a change ticket?
Is there an audit trail showing which calendar version produced a given due date, so a disputed late payment charge can be explained years later?
A platform that already supports multiple named calendars, versions them by effective date, and keeps settlement separate from availability has most of what this needs. Ask the questions during a renewal or a roadmap review rather than during an implementation, and the answers arrive while there is still time for them to influence something.
Practical takeaway.
A six-day Fedwire week is a good change for anyone who moves money, and the timeline is generous. The work it asks of finance systems is small in scope and unusually durable in value: name the calendars, record where each one comes from, version them, and stop letting one date field answer four different questions. None of that waits on the Reserve Banks, none of it needs a vendor, and every step of it improves a payment run happening this month. When the go-live window narrows and the first Sunday operating day arrives, a team that did this adds a calendar version and moves on.
Sources.
- Federal Register: Federal Reserve Action To Expand Fedwire Funds Service and National Settlement Service Operating Hours, Docket No. OP-1870, 90 FR 51356, published 17 November 2025. The source of every hour, day, date and mechanic described here, read in full rather than in summary
- Board of Governors of the Federal Reserve System: press release of 9 October 2025 announcing the expanded operating days of the Fedwire Funds Service and the National Settlement Service
- Federal Register: Expansion of Fedwire Funds Service and National Settlement Service Operating Hours, 89 FR 39613, published 9 May 2024, the original request for comment on 22x7x365 operations
- Federal Reserve Financial Services: Fedwire Funds Service and National Settlement Service Expansion of Operating Days, the participant-facing programme page the Reserve Banks named as the channel for the narrowed go-live window
- eCFR: 12 C.F.R. 229.2, Regulation CC definitions, source of the banking day definition at paragraph (f) and the business day definition at paragraph (g) with its list of ten named holidays
- Board of Governors of the Federal Reserve System: Federal Reserve Policy on Payment System Risk, the policy governing intraday credit and the penalty fee that discourages overnight overdrafts
- Federal Register: Request for Information on Potential Actions To Address Payments Fraud, 90 FR 26293, published 20 June 2025 by the Board, the FDIC and the OCC, whose comments the agencies were still assessing when the operating hours notice was published
Every hour, day, date, count and quotation above comes from the Federal Register notice at 90 FR 51356, downloaded and read in full rather than taken from a summary, and from the Regulation CC definitions read directly on the eCFR. Where the Board described an intention rather than a decision, such as considering a participant directory or exploring expanded discount window days, it is described here the same way. Two public posts on X are quoted, from the Federal Reserve on 9 October 2025 and from Federal Reserve Financial Services on 3 November 2025, and both were checked before being cited. A wider set of practitioner posts could not be assembled honestly, because a logged out view of X exposes only a handful of recent posts per account and search needs a session, and nothing has been invented to fill the gap. The calendar record shown above is a worked example of the shape we are describing and is not an extract from any customer system. The implementation window remains 2028 or 2029 until the Reserve Banks narrow it, so no specific go-live date is stated here.