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.
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.
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.
The API worked. The books did not. A clean REST interface with pretty JSON still leaves accounting stitching exports for three days to answer one question - what happened to this payment across every rail and every failure path. ERP-grade APIs treat the contract as a shared language with finance.
A clean virtual-account hierarchy looks simple until an HCM client asks you to reverse payroll for 200 employees across three states from three weeks ago. Multi-entity payroll is where account architecture meets 50 sets of wage law - and where instant rails do not yet fit.
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.