Field note

The hard part of payments is access, not the API

A payroll rollout taught me the friction is never the integration. It is funding caps, routing permissions, and what can clear directly versus what has to detour through a sponsor bank. That is why the Fed's new payment-account RFI matters - access is becoming a design decision, not just a policy one.

Jan 12, 2026 · Navin Agrawal · Payments · 3 min read

The hard part of payments is access, not the API

Visual brief

Visual brief

The hard part of payments is access, not the API

As of January 2026

A payroll rollout taught me the hard part of payments is not the API. It is access. We had a clean integration, a sponsor-bank path, and a settlement window that looked fine on paper.

The real friction showed up in funding caps, routing permissions, and what could clear directly versus what had to detour through a sponsor. That is exactly the seam the Fed’s new payment-account RFI sits on.

RFI opened

Dec 19 2025

Fed seeks input on a limited-purpose payment account to clear and settle, without a full master account.

Comment deadline

Feb 6 2026

on the Reserve Bank Payment Account Prototype (Federal Register).

Constraints

Capped

no interest, no Fed credit, balance caps, and no change to who is legally eligible.

What the RFI proposes

On December 19, 2025, the Federal Reserve asked for input on a limited-purpose payment account that would let an eligible institution clear and settle its own payments without holding a full master account. The constraints are the point: it would pay no interest, provide no Fed credit, sit under balance caps, and would not expand who is legally eligible for Fed payment services. Comments are due February 6, 2026.

Where it changes real systems

HCM and PEO payroll flows could isolate payroll settlement from other balances, but only through an eligible institution. Gig payout platforms could cut sponsor-bank friction if the eligible entity uses a payment account, though the caps force active liquidity management. Bill-pay and treasury processors could gain a cleaner settlement path and still need a fallback route for when the account hits its limit.

The hard part of payments is access, not the API (as of January 2026): on December 19, 2025 the Federal Reserve opened an RFI on a limited-purpose payment account that lets eligible institutions clear and settle without a full master account; comments on the Reserve Bank Payment Account Prototype are due February 6, 2026; the account would pay no interest, provide no Fed credit, sit under balance caps, and not change legal eligibility; and the design answer is a new access tier with account-class routing, balance and liquidity controls, sponsor-bank fallback, and stronger AML gating.
The integration was never the hard part. Who is allowed to clear, and under what caps, is the design decision.
Payment access is turning into a design decision, not just a policy decision. The platforms that model access as a tier in the entitlement layer will absorb a change like this without re-plumbing settlement.

Was this useful?

Choose once.

Related Posts

View All Posts »
Spend limits are not delegated payment authority

Spend limits are not delegated payment authority

An invoice agent hits a transient timeout, retries, and two payments clear to the same vendor. The model calls it success. Ops calls it a week of cleanup. Spend limits and roles are a speed bump. Real delegated authority is a delegation object, policy on every attempt, ledger-bound idempotency, and an instant kill switch.

Under a second is the right answer to the wrong question

Under a second is the right answer to the wrong question

At an AWS Bedrock AgentCore Payments session the question was what happens at a thousand transactions a second, and the answer was settlement in under a second. Both are true and they answer different questions. The right frame for one payment crossing a trust boundary is the wrong frame for a million events a day inside one agent fleet, where the chain fee stacks up before anything else does.

ACH's most boring 10 characters just became policy

ACH's most boring 10 characters just became policy

From March 2026, Nacha standardizes the ACH Company Entry Description as PAYROLL or PURCHASE for those payment types. It sounds trivial, but a free-text field becoming a dependable category is what finally lets reconciliation automation stick on a rail that still moves tens of billions of payments a year.

Pay-by-bank's 3% savings hides a reconciliation bill

Pay-by-bank's 3% savings hides a reconciliation bill

The CFO sees "save 3 percent on transactions" and the math looks obvious. Treasury sees continuous settlement at 3 AM and a reconciliation process built for batch. Before you switch to account-to-account, count the operating cost the savings slide leaves out.