Transaction banking and distribution now produce 57% of bank profits, according to McKinsey’s Global Banking Annual Review 2026, and the same report tells banks to rework their core systems toward leaner, modular designs without repeating the expensive full-scale programs of the past. Many banks are answering that with a bank operating system rather than core upgrades or replacement. The harder part is telling the platforms apart, who all promise a long list of modules, a cloud logo and a promise of faster launches.
The best independent evidence of how these purchases go wrong comes from payments, usually one of the first areas banks move to when adopting a bank operating system. The 2026 ABA Product Assessment: Payment Hubs, published by Datos Insights, found that the most common problem banks reported in vendor selection was a platform still incomplete when they bought it, which left them testing unfinished rails and back-office tools while running live payments.
So how does a bank assess bank operating system providers and separate the platforms ready to carry its payments and products from those still being built? This guide sets out five capabilities to test, ranked by how hard each one is to fix once a contract is signed, along with the questions to put to each vendor and the warning signs that should take a provider off the shortlist.
The order matters because architecture is close to permanent. Although delayed roadmap deliverables can eventually be realized, foundational architecture is virtually immutable. For this reason, this guide prioritizes infrastructure over feature sets, which typically dominate standard vendor demonstrations.
What a bank operating system has to do
A bank operating system is a cloud-native, API-first platform that runs in parallel with a bank’s legacy core and handles money movement, product launches, workflows and integrations. The core remains the system of record, and the bank operating system becomes the system of growth. For the full definition, see What is a bank operating system? and Bank operating system vs. core banking system.
The five capabilities, ranked
1. A real-time ledger that runs in parallel with the core
The first test is whether the platform keeps its own real-time ledger. A bank operating system with a parallel ledger can settle an instant payment at 2 a.m. on a Sunday, update the customer’s available balance and post the result to the core when the core is ready. A platform without one is middleware, and it inherits every batch window the core has.
This ranks first because the other four depend on it. Instant payments need a balance the platform can trust at any hour, and a phased exit from legacy systems, which Finzly calls surround and shrink, needs somewhere for each workload to land before the old system is switched off. Datos Insights also found that banks regularly struggle with core connectivity after go-live.
What to ask in the demo
Process a payment while the core is in its batch window and show how the two ledgers reconcile. If “real-time” turns out to mean a real-time API call into a batch core, the platform fails this test.
2. Every payment rail on one ISO 20022-native engine, live in production
The second test is how many rails run on a single engine today. A modern bank operating system should process ACH, Fedwire, RTP, FedNow and SWIFT through one set of workflows, limits and exception queues, with ISO 20022 as its native format rather than one it translates into and out of. Translation layers can truncate the party and remittance data the standard was built to carry.
Datos Insights reported that many banks still haven’t moved all payment types onto one platform, largely because many vendors don’t support every method. The gap widens every year. The Federal Reserve Bank of Richmond reported in August 2026 that 1,725 banks and credit unions had joined FedNow by the first quarter and that 49% of them had also joined RTP. Running two instant rails beside ACH and Fedwire on separate systems means four sets of exception queues and no single view of liquidity.
What to ask in the demo
Ask for a production reference for every rail on the vendor’s slide, kept separate from rails on the roadmap. Datos Insights found that Finzly’s Payment Galaxy orchestrates ACH, Fedwire, RTP, FedNow and SWIFT on one platform, with native ISO 20022 support across every rail and direct, certified connections to the payment networks.
3. Operational control that the bank’s own staff can change
The third test is who changes the platform after go-live. Operations and product teams should be able to adjust workflows, approval limits, routing rules, reports and exception handling through configuration, without a change request to the vendor.
Two of the five selection challenges Datos Insights identified sit here. Banks said modern payment hubs often process payments well but fall short on reconciliation, reporting and exception management. They also described a dependency trap, where heavily customized implementations drift from the vendor’s standard releases and every nonstandard change waits in the provider’s queue.
What to ask in the demo
Ask the vendor to change a routing rule or approval limit live, without a developer. When a vendor answers a requirement with “we can build that,” ask whether the result stays on the standard upgrade path. Datos Insights reported that Finzly’s workflow engine lets banks configure business rules through a user interface without developer involvement.
4. A delivery model measured in months, with a planned exit from legacy
The fourth test is how quickly the first rail goes live and whether the plan ends with legacy systems retired. A credible vendor can name the first workload, the go-live date and the legacy component that will be switched off, and can point to a bank that has done it.
Datos Insights found that banks often describe lengthy deployments and missed delivery dates, a problem that falls hardest on community institutions with small IT teams. Every month of dual running also costs money, so a platform that goes live quickly but never retires anything can raise costs. Datos Insights reported that Finzly implementations typically take three to six months, with instant payments live in as little as 12 weeks for specific use cases. Wings Credit Union went live on Finzly’s ISO 20022-native Fedwire in four months, and one Finzly client used the platform for a core-independent launch of RTP and FedNow.
What to ask in the demo
Ask whether a quoted timeline includes core integration, fraud connections and bank-side testing, since that is where most delays sit, and ask who carries the cost if the date slips.
5. Room for the next product, money type and AI agent
The fifth test is whether new capabilities run on the same ledger, controls and data as the rest of the platform. Virtual accounts, tokenized deposits, stablecoin payments and AI agents should extend the bank operating system rather than arrive as separate platforms with their own integrations.
It ranks fifth because it is the most exposed to roadmap claims and the hardest to verify in a demo. Datos Insights notes that next-generation payment hub features may become standard or stay niche.
What to ask in the demo
Ask which of these capabilities are in production at a bank today and which are pilots. For AI agents, ask how each action is approved and logged. Finzly launched Agentic Galaxy, its suite of AI agents with human-in-the-loop governance, on Oct. 22, 2025, and Token Galaxy, which moves fiat, tokenized deposits and stablecoins through one engine, on March 11, 2026.
A shortlist scorecard for bank operating system vendors
| Rank | Capability | Ask the vendor to show | Red flag |
| 1 | Parallel real-time ledger | A payment settling during the core’s batch window, then reconciling to the core | “Real-time” means API calls into a batch core |
| 2 | All rails on one ISO 20022-native engine | A production reference for each rail | Rails on the slide that exist only on the roadmap; message translation layers |
| 3 | Operational control | Your operations lead changing a routing rule without a developer | “We can build that” for routine changes |
| 4 | Delivery and legacy exit | A dated plan and a reference that retired a legacy component | Timelines that leave out core integration or testing |
| 5 | Room for new products and AI | What runs in production, and how AI agent actions are logged | Tokenized money or AI on a separate platform |
Frequently asked questions
What should banks look for when evaluating bank operating system vendors? Five capabilities, in this order: a real-time ledger that runs in parallel with the core; every payment rail on one ISO 20022-native engine in production; operational controls the bank’s staff can change; a delivery model that goes live in months and retires legacy workloads; and room to add new products, tokenized money and AI agents on the same platform.
How long should a bank operating system implementation take? It depends on the rails and integrations involved. Datos Insights reported that Finzly implementations typically take three to six months, with instant payments live in as little as 12 weeks for specific use cases. Ask any vendor what its quoted timeline leaves out.
Should banks weight a vendor’s product roadmap? Yes, but below what runs in production today. Datos Insights advises banks to review each vendor’s current implementations alongside its roadmap. Score live capability first and use the roadmap as a tiebreaker.
Take the scorecard into the first demo
Send each vendor the five tests before the first demo and ask it to prove the first two on a live system with a production reference. Vendors that can’t will usually say so early, which saves weeks of evaluation. To see how Finzly BankOS measures up, explore the platform or talk to the Finzly team about a demo built around your current core.
About Finzly: Finzly offers BankOS, a modern operating system for banks that serves as an innovation core, free from legacy core dependencies. It manages traditional and tokenized money and its movement across ACH, wires, RTP, FedNow, SWIFT, and other payment rails through ISO 20022-native processing, all on a single platform with advanced payment processing and a unified ledger. This gives banks a simpler path to modernize payments, launch new services, and create growth channels across embedded banking, FX, and payments.
