Field note

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.

Jan 20, 2026 · Navin Agrawal · Architecture · 3 min read

A name check just became a priced control

Visual brief

Visual brief

A name check just became a priced control

As of January 2026

A name check just became a priced control in US payments. The Fed's 2026 pricing notice introduces Payee Name Verification, an expansion of FedDetect Notification Services, at two cents a transaction, starting on FedACH.

That changes the architecture, not just the UI. From an architect’s view this is not a yes-or-no check bolted on at the edge. It is a new control point that reshapes routing, exception handling, and reconciliation.

How it works is what makes it architectural. The service searches historic FedACH data for past transactions to the payee account and compares the submitted name against the names previously associated with it. So the answer is not a clean yes or no. It is a match, a near-match, or nothing on file, and each of those is a different downstream decision. A control that returns three shapes of answer needs three lanes built for it.

A name check just became a priced control (as of January 2026): the Fed's 2026 pricing notice introduces Payee Name Verification at $0.02 per transaction as an expansion of FedDetect Notification Services; it launches for FedACH customers and the Reserve Banks may add other rails later; it works by searching past FedACH transactions to the account and comparing the submitted name to prior recipients; and from an architect's view it should be treated as a data contract with pass, review, and block lanes, tagged outcomes, and tunable thresholds.
A two-cent check that returns match, near-match, or nothing - and each answer reshapes the payment's path.

Price

$0.02

per transaction for Payee Name Verification, an expansion of FedDetect Notification Services (2026 pricing).

First rail

FedACH

the service launches for FedACH customers, and the Reserve Banks may add other rails later.

Mechanism

Historic match

it searches past FedACH transactions to the account and compares the submitted name to prior recipients.

Not a yes-or-no check

It is a control point. Where it sits in the flow, what each result triggers, and how the outcome is recorded all become architecture decisions the moment you turn it on.

Design it as a data contract

Normalize and tokenize the name data before submission so formatting differences do not manufacture false mismatches. Set match policy by use case, because payroll, treasury, bill-pay, and A2A transfers should not share one threshold or one action. Build a three-lane decision model - pass, review, or block - each with its own SLA and customer messaging. Tag the payment record with the check outcome so disputes, audits, and returns trace without reconstructing history. And add feedback loops so operations tune thresholds against real exception rates rather than assumptions.

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.

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.

Payroll virtual accounts break on the real-world edge cases

Payroll virtual accounts break on the real-world edge cases

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.