In my recent article on the Federal Reserve's Payment Account proposal, I argued that the third priority for community bank leadership over the next ninety days was to evaluate the bank's integrated payment routing capability — and that the source of that capability may be the core provider, the digital banking platform, a dedicated payments hub, or a BaaS partner. Several readers asked the obvious follow-up. Which path is right for which bank, and when does a dedicated payment hub move from "nice to have" to "necessary"?

That question has gotten harder, not easier, in the last twelve months. The SWIFT MT/MX coexistence period ended November 22, 2025. The Fed moved Fedwire to ISO 20022 in July 2025. Structured address requirements take effect November 14, 2026, with unstructured CBPR+ messages rejected after that date. FedNow's participant base has crossed 1,700 institutions, the RTP network is past one billion cumulative transactions, Same Day ACH is moving to a $10 million per-payment cap, and the Federal Reserve's payment account proposal is about to extend direct rail access to a new class of non-bank participants. Every one of those developments raises the cost of a bank running ACH, wire, RTP, and FedNow on separate, point-to-point integrations.

What Is a Payment Hub?

A payment hub is a centralized platform that routes, processes, and manages transactions across multiple payment rails through a single integration layer, replacing point-to-point connections with one governed architecture. CCG Catalyst's Sector Spotlight on Payment Hubs catalogued the vendor landscape across both purpose-built and core-embedded options. Modern hubs have evolved well past simple rail consolidation: they orchestrate by business rule, normalize messages across ISO 20022 and legacy formats, expose APIs for third-party fraud and analytics overlays, and increasingly run on cloud-native, microservice architectures. Omdia sized the global market at $2.4 billion in 2024, with 58 percent of banks planning to increase payment hub spending and 33 percent citing payments modernization as a top three technology priority per Celent.

Four Pathways

Every bank evaluating payment infrastructure modernization is effectively choosing among four pathways.

1. Build. Customers Bank's cubiX is the proof point that a mid-size institution can build a proprietary real-time payments platform — with over $1.5 trillion in processed volume — and use it as a competitive weapon. It challenges the assumption that only the largest banks or fintechs can build transformative payments infrastructure. The caveat is that building demands engineering depth and a strategic commitment most community banks cannot replicate.
2. Purpose-built hub. This is the broadest category and the most often misunderstood. It includes payments-only vendors such as Alacriti's Orbipay Payments Hub, Finzly's Payment Galaxy, Volante Technologies, Form3, ProgressSoft, ACI Connetic, and the standalone hubs sold by the core providers themselves: Fiserv's Enterprise Payments Platform (which grew out of the Dovetail acquisition), Finastra's Payments To Go and Fusion Global PAYplus, and FIS's Open Payment Framework. The common architectural attribute is core-agnostic: the hub operates independently of the bank's core system of record, integrates via API, and gives the bank rail-adoption independence from any single provider's release cycle. The trade-off is adding a vendor.
3. Core-embedded module. A smaller category, but the one most community banks default to without realizing the distinction. Jack Henry's JHA PayCenter is the cleanest example: it is certified for FedNow, RTP, and Zelle and integrates naturally for institutions already on the Jack Henry core, but the payment capability set is bounded by what Jack Henry has built and shipped. Finxact's Payment Rails follows a similar pattern for institutions running Finxact as a sidecar core. The integration path is familiar; the constraint is that new rail adoption is tied to the core provider's release cycle, and commercial-grade payment capability beyond the core's roadmap requires going outside.
4. BaaS overlay. Stablecore, AlphaPoint, and similar middleware platforms provide payment orchestration as a service layer that sits alongside the core rather than replacing payment infrastructure outright. This pathway is most relevant for banks pursuing tokenized deposit, stablecoin, or digital-asset payment use cases.

The right answer is rarely a single vendor and increasingly a combination — a core-embedded module for the rails the core handles well, a purpose-built hub for the rails it does not, and a BaaS overlay for the digital-asset roadmap.

Five Signals That Say Evaluate a Dedicated Hub Now

The decision to add a purpose-built hub is rarely driven by one consideration. It is usually three or more of the following stacking up at the same time.

5. The core cannot deliver multi-rail routing. If your core processes ACH in overnight batches and wires through a separate operational team and FedNow through a recently bolted-on module, intelligent routing across rails by speed, cost, and recipient capability does not exist in your stack today. The payment account proposal raises the cost of leaving that gap open.
6. ISO 20022 readiness is a translation layer, not native support. The November 2025 coexistence end and the November 2026 structured-address deadline make ISO 20022 a gating requirement, not a forward-looking capability. A hub with native ISO 20022 and CBPR+ support — ProgressSoft delivered MT/MX converters to 30-plus banks last year and was running at 70 to 80 percent STP — is materially less risky than translation middleware bolted onto legacy formats.
7. Commercial clients are demanding integrated treasury experiences. When treasury management clients ask why they cannot initiate ACH, wire, RTP, and FedNow from the same interface with consistent visibility into status and exception management, the bank is feeling the absence of an orchestration layer. The fix is rarely in the core.
8. Cross-border and correspondent volume are meaningful. Banks with material SWIFT activity face a different cost-benefit calculus than purely domestic institutions. SWIFT gpi, Pre-Validation, SWIFTRef integration, and Alliance Cloud API support are the kind of capabilities that purpose-built hubs deliver, and core-embedded modules typically do not.
9. The digital asset roadmap is real. As I argued in "Your Deposits Are Going Digital," tokenized deposits and stablecoin issuance settle on infrastructure most cores do not support natively. Cross River's stablecoin work, the consortium models we have been tracking, and the March 2026 interagency capital FAQ all point in the same direction: the institutions that build first inside the regulated bank perimeter need an orchestration layer that can route across fiat and tokenized rails on a shared data model.

If two of these signals are present, the bank should be running a structured payment hub evaluation. If three or more are present, the bank is already behind.

What the Market Is Actually Delivering

Judging this year's PayTech Awards UK Best Payment Orchestration category clarified what is being delivered in this market and what is still aspirational.

The strongest entries paired technical depth with named customer evidence. The in-person orchestration leader cited 250,000-plus endpoints, EUR 100 billion-plus in volume, and named deployments at Rabobank (38,000 terminals, 60 million annual transactions) and Aera (~40 percent of Norway's transaction volume). A switch-level chargeback orchestration entry built on a national switch in Morocco showed dispute win rates rising from 42 percent to 78 percent and a 95 percent reduction in manual work. ProgressSoft's payments hub demonstrated cross-border and correspondent capability with native ISO 20022 and CBPR+ translation, rail connectivity in about three months against the 9 to 12 typical, and STP rates of 70 to 80 percent.

The most architecturally ambitious submissions converged on a recurring pattern worth studying independent of any specific vendor: a unified, API-first engine that centralizes every U.S. rail (ACH, Fedwire, RTP, FedNow, tokenized money) on a real-time virtual ledger decoupled from the core, with active-active failover and increasingly AI-driven natural-language operations consoles for exception management. The "coexistence" approach — modernizing alongside the legacy core rather than ripping it out — is the de-risked path for banks wary of a full replacement. This architectural model is the one community and regional banks should be using as a reference when evaluating any vendor's roadmap.

The lesson for buyers is consistent across the field: vision without evidence is a procurement risk. The vendor's roadmap is interesting; the vendor's documented go-live timeline at a comparable institution is decisive.

A Decision Framework

Combine the four-pathway view with the five-signal trigger and a community or regional bank lands in one of three positions.

Stay with the core, for now. Single-rail commercial activity, modest cross-border exposure, no near-term tokenized deposit roadmap, and a core provider with a credible FedNow and RTP module. Reassess in twelve months. Use the time to press the core provider for specific delivery dates against the ISO 20022 structured-address deadline and the FedNow feature roadmap.

Add a purpose-built hub alongside the core. This is the right move when two or more of the five signals are firing, when the core provider's rail roadmap is lagging the bank's commercial demand, or when an upcoming cross-border or treasury management investment requires capability the core cannot deliver. The architectural pattern to target is coexistence: a virtual ledger decoupled from the core, the hub handling routing and ISO 20022 normalization, and the core remaining the system of record. Evaluate the pureplay and the standalone hubs from the major core providers side-by-side and ask each vendor for two named references at a comparable institution and one documented go-live timeline. Vendor selection should follow that evidence, not the marketing.

Build, but only with conviction. The Customers Bank example shows it can be done. It demands a payments-as-strategic-product thesis, engineering capacity most community banks do not have, and a board willing to fund a multi-year build against vendor alternatives. For the right institution this becomes a durable competitive advantage. For most institutions it becomes a stranded investment.

The payment hub decision is not a technology procurement. It is a position the bank takes on whether payments are a defensive function or a strategic capability. The rails are consolidating around ISO 20022, real-time settlement, and direct Federal Reserve participation by a widening population of institutions. The institutions that treat payment infrastructure as a back-office maintenance line will keep operating point-to-point integrations until commercial clients walk. The institutions that treat it as a competitive surface will define the standard the rest of the industry is measured against in the next decade.

CCG Catalyst advises community and regional banks, credit unions, and fintech companies on payments strategy, vendor evaluation, and technology planning. If your institution is evaluating a dedicated payment hub, reach out to our team at www.ccgcatalyst.com.

See our latest announcement: CCG Catalyst's Paul Schaus Named a 2026 Top Consultant by Consulting Magazine

By: Paul Schaus | Founder & Managing Partner, CCG Catalyst Consulting

Disclaimer: The views expressed in this article represent the perspective of CCG Catalyst Consulting based on our direct experience advising financial institutions. This commentary is intended to stimulate industry discussion and does not constitute legal, accounting, or regulatory advice.