Fedwire ISO 20022 and FedNow, from an operations desk

FedNow

FedNow launched on ISO 20022 in 2023, so there is no legacy shape to migrate from. What changes for operations is not the format but the clock: instant settlement, 24 hours a day, means reconciliation cannot be a nightly batch habit. Positions move at the weekend, and an exception that ages for two days aged over a period when nobody was looking.

• Files and reports arrive more often and are smaller.
• Aging thresholds have to be set in hours for some item types, not days.
• Returns and rejects need to be tied to the original in near real time.
• Weekend and holiday coverage becomes an operating model question, not a technology one.

CHIPS and the correspondent view

CHIPS operates its own ISO 20022 based messaging for large value clearing, with its own usage rules. Add correspondents sending CBPR+ messages, and a US bank reconciling a nostro position can meet three or four flavours of the same standard in one day. This is normal, and it is the strongest practical argument for a reconciliation layer that treats format as a property of the source rather than as a system-wide assumption.

Why a single day cutover was the easier choice

Coexistence sounds safer than a cutover and is usually harder to operate. Running two formats in parallel means every downstream process needs two paths, two sets of rules and a way to reconcile across both, for as long as the window lasts. The Fedwire approach put the difficulty into one weekend of preparation instead of spreading it over two years of dual running.

The operational lesson generalises. Wherever you have a choice about a format change on a source you control, the shorter the period in which two shapes exist, the smaller the permanent complexity. Where you do not have the choice, which is most correspondent relationships, the answer is to make format a per source setting so that dual running costs configuration rather than code.

The always on problem, in detail

Instant rails break assumptions that a batch reconciliation never had to state. The most important one is that there is a moment each day when the books stop moving. On an always on rail there is no such moment, so every part of the process that implicitly relied on it has to be reconsidered.

None of this requires a different matching engine. It requires the aging and escalation configuration to be expressed in hours where the rail is instant, and it requires somebody to have decided what happens to an exception raised outside working hours. That second decision is an operating model choice that software cannot make for you.

Three rails, one account, one reconciliation

A US bank reconciling its own position frequently sees the same commercial payment described three ways: an instruction in its payment engine, a settlement leg on one of the rails, and a posting on an account. The reconciliation is not between the rails, it is between what the bank instructed and what settled, and the rail decides the shape of the evidence. The product page for the two instant rails is instant payments reconciliation software.

Domestic guidelines are not CBPR+

The most common configuration error on US rails is reusing cross border rules domestically. Both are ISO 20022 and both look similar in a specification. The differences that matter are which elements are mandatory, how identifiers are populated, and what appears in remittance information. A matching rule that keys on a field that is mandatory under CBPR+ and optional domestically will work in testing and degrade quietly in production, which is the worst failure mode available.

The defensive habit is to write rules against fields you have verified are populated in real files from that specific source, and to review the assumption when the source changes anything. A source that changes shape should raise an ingestion exception rather than silently matching less.

What to measure on each rail

• Exact match rate per rail, tracked separately, because a blended number hides which rail is degrading.
• Time to first match, which on an instant rail is the honest measure of whether the reconciliation is keeping up.
• Break age distribution in hours for instant flows and in days for correspondent flows.
• Return and reject volume tied to originals, since an untied return is an investigation that has not started yet.
• Fee items as a proportion of breaks, which tells you whether accruals are modelled or discovered.

What to change in the operating model

1. 01Configure tolerances and aging per source, because a domestic instant payment and a cross border correspondent leg have nothing in common operationally.
2. 02Reconcile intraday where the rail is intraday. An end of day statement on an always-on rail is a report about history.
3. 03Classify breaks by cause so the difference between a Fedwire formatting habit and a correspondent truncation is visible in the data.
4. 04Keep MT parsing alive for the flows that still use it, and stop treating it as a legacy embarrassment.

The weekend, and other times nobody planned for

An instant rail that runs continuously creates a category of operational risk that batch banking never had to name: exposure that accumulates while the building is empty. It is not a theoretical concern. A returned payment on a Saturday evening, a duplicate posting caused by a replayed batch, or a settlement that did not complete are all events that can happen at times when the reconciliation is running and nobody is reading the result.

There are three defensible answers and one indefensible one. You can staff the coverage, which is expensive and appropriate at some volumes. You can define which item types can wait until the next working day and document that decision, which is legitimate if the decision is explicit and reviewed. You can automate the handling for a narrow set of item types where the action is unambiguous, under maker-checker applied retrospectively. The indefensible answer is to leave it undefined and discover the position on Monday.

• Decide which classifications may wait and which must page somebody, and write it down.
• Set aging thresholds in hours for the item types that cannot wait, and make escalation automatic rather than dependent on a person noticing.
• Distinguish an item that arrived out of hours from an item that has genuinely aged, so Monday morning is not a false alarm.
• Record the out of hours decision itself, because an examiner reading a Monday morning action will ask when the exposure started.

Three way matching, and why two way is not enough here

A two way reconciliation compares the account posting with one other record and proves that two things agree. On a rail where an instruction, a settlement and a posting are three separate events with three separate identifiers, agreement between two of them does not prove very much. The case that two way matching misses is common: the instruction and the posting agree, and the settlement never happened, because the posting was made on an assumption rather than on a confirmation.

Three way matching, instruction to settlement to posting, catches it. It costs an extra source and an extra set of normalization rules, and it converts a class of silent failure into a visible break on the day it occurs rather than at month end. On rails where settlement finality is immediate and irreversible, that difference in timing is the whole value.

A note on scope

Rail rules and timelines change, and the details above describe the general shape rather than the current position of any scheme. Before making a plan, confirm the present state with the operator of each rail you use. What does not change is the operational conclusion: treat format, tolerance and aging as properties of the source, keep the ability to read older formats, and measure breaks by cause so that the difference between a rail habit and a real problem is visible in the data rather than in somebody's memory.

On the accounting side, the master account statement, FIRD detail and the 7 p.m. ET FedNow cycle date are handled on Federal Reserve account reconciliation software. The standard itself is covered in ISO 20022 explained, the cross border rules in SWIFT ISO 20022 and CBPR+, and the product view in payment reconciliation software.

Instant settlement changes what a break costs

On a rail where settlement is final in seconds and available every hour of every day, an unreconciled item is a different kind of object from an unreconciled wire. There is no window in which a mistake can be recalled by agreement, and there is no overnight period during which the position is static and can be examined calmly. The reconciliation either keeps pace with settlement or it produces a position that is always slightly historical.

The practical consequence is that the exception process, not the matching, becomes the constraint. Matching more frequently is a configuration change. Having somebody available to work an exception at the moment it arises, with the authority to act on it, is an operating model change, and it is the part that institutions consistently underestimate when they add an instant rail to an existing operation.

Request for payment, and the reconciliation it implies

Request for payment introduces a message that is not itself a payment and that expects a response which may never arrive. That creates a population no traditional reconciliation models: requests sent, requests answered, requests declined and requests that simply expired. None of those are breaks, and all of them will look like breaks to a process that only understands instructed and settled. Modelling the request as its own state, with its own age and its own expected outcome, keeps that population out of the exception queue where it would otherwise generate constant noise.