Field note

Static payment routing could not handle the 2:47 AM wire

A $2.3M wire hit the system at 2:47 AM on a Friday, the rule saw "large wire" and chose Fedwire, and Fedwire does not run weekends. The transaction waited until Monday. The fix is not a faster rule - it is routing that understands business context.

Aug 18, 2025 · Navin Agrawal · Architecture · 3 min read

Static payment routing could not handle the 2:47 AM wire

Visual brief

Visual brief

Static payment routing could not handle the 2:47 AM wire

As of August 2025

Static routing rules cannot read context. A high-value wire arrives at 2:47 AM Friday, the rule defaults to Fedwire because the amount is large, and Fedwire settles Monday to Friday - so the payment sits until Monday while contract penalties accrue.

The amount triggered the wrong rail. Nothing in the logic asked whether the timing worked, whether the destination bank could receive it, or what the delay would cost.

Three generations of payment thinking

Paper moved value with checks and armored trucks - slow, predictable, and dollars per item. Electronic rails dropped the cost to pennies but kept human-written routing rules. The next step is context-aware routing: instead of “large wire goes to Fedwire,” the logic weighs the customer’s SLA, the destination bank, the timing, and the penalty exposure, then picks the path.

Where static rules break

They optimize on one variable, usually amount, and ignore the rest. A rule that cannot tell 2:47 AM Friday from 2:47 PM Tuesday will keep routing weekend wires to a weekday-only rail. The rail is fine. The logic that cannot see the calendar is the problem.

The cost arc is what makes the case. Industry benchmarks put paper checks at a few dollars per item and ACH at pennies, a real collapse in unit cost, yet the decision layer on top barely changed. We moved the rails into software and left the routing logic in the 1990s.

Fedwire hours

Weekdays only

Fedwire Funds settles Monday to Friday, so a 2:47 AM Friday wire waits until Monday.

Paper check

~$2-4

industry cost per paper check (AFP / Federal Reserve payments-cost research).

ACH

~$0.05-0.10

industry cost per ACH transaction - pennies versus dollars per check.

The 2:47 AM wire that static routing could not handle (as of August 2025): Fedwire Funds settles Monday to Friday, so a 2:47 AM Friday wire waits until Monday; industry benchmarks put paper checks at roughly $2 to $4 per item and ACH at roughly $0.05 to $0.10 (AFP / Federal Reserve payments-cost research); and in one treasury audit about 30 percent of 8,200 monthly high-value transactions showed questionable routing (field estimate).
The rails got cheap and fast. The logic deciding which rail to use did not keep up.
Manual routing decisions cannot compete with logic that reads the customer's SLA, the destination bank, and the calendar before it picks a rail.

Was this useful?

Choose once.

Related Posts

View All Posts »
BRICS does not need to kill SWIFT to change cross-border architecture

BRICS does not need to kill SWIFT to change cross-border architecture

The interesting BRICS payments question is not geopolitics. It is architecture: when a US company pays a supplier in a BRICS country, does the payment still default to USD correspondent banking, or does the hub choose the corridor before release? A mature local-currency corridor adds a routing decision, and that decision is middleware, policy, liquidity, and evidence rather than a new button in the portal.

A multi-rail exception mesh, not best-effort dedupe

A multi-rail exception mesh, not best-effort dedupe

A duplicate payment in production is not an edge case. It is the control plane showing you what you never modeled. A retried request can land as a final success on one rail and a settlement reject on another, look clean on the dashboard, and still move two accounts twice. Best-effort dedupe is not a control.

A name check just became a priced control

A name check just became a priced control

The Fed's 2026 pricing notice introduces Payee Name Verification at two cents a transaction, starting on FedACH. It works by comparing a submitted payee name against names previously seen on that account. From an architect's view that is not a yes-or-no check - it is a new control point that reshapes routing, exceptions, and reconciliation.

API governance is payment architecture, not a footnote

API governance is payment architecture, not a footnote

A duplicate API call looks harmless until two payments clear and operations is left explaining the gap. The same error behaves differently on every rail - ACH hides it until batch, RTP and FedNow clear it instantly and final, wire forces a manual recall. On a multi-rail platform, governance is the architecture.