• A commercial customer reportedly waited 18 months for a direct instant-payments connection because the bank had to rebuild its architecture first, per PYMNTS.
• Rail-by-rail builds duplicate integration, controls and reconciliation work; a shared hub aims to build them once.
• The incentive shifts: the scarce resource is onboarding capacity, not rail access.
• Fraud and compliance controls that sit inside a hub apply to every rail at once, which raises the cost of getting them wrong.
• Treat the 18-month figure as one anecdote from one discussion, not an industry average.

A commercial customer asked its bank for a direct connection to instant payments and was told to wait 18 months, according to PYMNTS. Robert Mancini of SRA Consulting recounted the case on PYMNTS On Air: the bank needed to rebuild its architecture before onboarding the client. The episode points to a structural shift, in which banks stop treating each payment rail as a separate project and start building shared hubs.

Why the queue exists

The 18-month wait is a symptom of rail-by-rail architecture, not of weak demand. When each connection is built as its own stack, a bank can face duplicated messaging, screening, liquidity and reconciliation work before it can onboard even a ready customer. According to PYMNTS, the customer was prepared to transact, but the bank's architecture was not. The delay was an engineering backlog, and the customer bore its cost.

What a shared hub changes

A shared hub changes the unit of work from building a rail connection to configuring a route. Once connectivity, controls and reconciliation sit in one layer, adding a rail such as the FedNow Service, run by the Federal Reserve Banks, or the RTP network, run by The Clearing House, becomes an extension of existing infrastructure. The reported incentive is speed: onboarding capacity, not rail access, becomes the constraint banks compete on.

What compliance and fraud teams should price in

Consolidation concentrates risk as well as efficiency. A fraud rule, sanctions check or limit that lives in the hub applies to every rail at once, so a misconfiguration propagates faster than in separate stacks. Instant payments also leave little time to reverse an error. Compliance teams should therefore ask who owns control logic in the hub, how changes are tested, and whether rail-specific rules survive consolidation. These are questions to settle before migration, not after.

How much weight the anecdote can bear

The 18-month figure comes from one account of one bank and one customer, relayed in a discussion, so it should not be read as an industry average. It is useful as an illustration of the bottleneck, not as a measurement. What to watch next is whether banks report shorter onboarding timelines after hub migrations, and whether regulators or rail operators say anything about third-party hub concentration.