Bank mergers are meant to deliver scale, synergies, and growth—but for payments operations, the reality often looks like chaos. Routing numbers get duplicated or retired. ACH batches show up under old identifiers. Customer segments end up on different rails. By the time the dust settles, systems are tangled, manual workarounds abound, and customers are left asking why payroll didn’t post. The challenge goes beyond the merger itself - it’s rooted in how payments systems operate. ACH, wires, real-time rails—they all need to work together seamlessly. Routing numbers have to reconcile. Posting workflows must line up. Fail at any of these, and your merger quickly becomes a nightmare.
 

It’s no surprise that 58% of executives whose deals met or exceeded expectations told EY they started integration early. The lesson? Waiting until Day 1 to tackle payments is a recipe for chaos. Smart, future-proof payment integration isn’t optional. It’s the difference between a merger that runs like clockwork and one that leaves systems tangled and customers frustrated.

For payment operations teams, a routing number is the switchboard for how money moves through the bank. When two banks merge, you don’t end up with one clean routing number. You inherit several, each tied to different systems, customers, and operational processes.
 

Operationally, this appears as:
 

     ·  ACH originations still keyed off an acquired bank’s routing number.
     ·  Retail DDA accounts mapped to a different payment core. 
     ·  Incoming wires splitting across back-end systems - sometimes for no reason other than history.
 

The result? Every routing number adds complexity to posting, reconciliation, and exception handling. Instead of running one streamlined operation, your team is forced to manage multiple parallel processes, introducing risk, slowing down modernization, and making it harder to roll out new payment services.
 

With a unified payments operating system, these complexities can be normalized, reducing the strain on operations while creating a cleaner path to future growth.

Now layer on an entirely new payment rail - instant payments. In a clean, single-core, single-routing-number world, rolling this out is straightforward. But in a merged-bank reality?
 

Key decisions include:
 

       ·  Which customers get access first (by routing number? by segment?)
       ·  Which transactions should go to the new instant rail vs. the old ACH batch?
       ·  Which core will handle posting for each rail, and what happens if the core isn’t instant-ready?
 

This is where banks that haven’t built flexibility into their payments infrastructure hit a wall. They either delay the launch or add a separate instant payment platform. This platform does not connect well with the rest of the system, creating another silo to manage

When banks merge, payment operations become exponentially more complex: multiple routing numbers, parallel cores, and diverse customer segments all need to coexist without disruption. Banks that manage these flows effectively rely on an operating system with event- and rule-based orchestration.
 

Think of it as air traffic control for payments during a merger:
 

       ·  Events (like “ACH file received” or “instant payment request submitted”) trigger automated workflows.
       ·  Rules (like “if routing number = X, post to Core A; else Core B”) route payments automatically across merged systems.
 

This approach enables operations teams to:
 

      ·  Handle multiple routing numbers seamlessly, even when different cores are involved.
      ·  Post transactions to multiple cores in parallel, based on customer or transaction attributes.
      ·  Introduce new rails - RTP, FedNow, and others - without interrupting legacy flows.
      ·  Take advantage of payment processing capabilities as part of the operating system
 

Embedding orchestration into post-merger payment processes ensures operational efficiency, reduces manual intervention, and maintains accuracy across complex, multi-core environments.

Another critical capability is "Payment Preprocessing". Before a payment ever hits your core, you can:
 

      ·  Validate data formats.
      ·  Apply fraud checks.
      ·  Reformat messages into ISO 20022 or whatever your destination system needs.
 

This minimizes exceptions, reduces rework, and ensures that every payment regardless of source or rail, arrives in the right place, in the right format, at the right time.

Payments aren’t a 9-to-5 business anymore. If your operating system isn’t built for real-time, 24/7 availability, you’re effectively gating innovation.
 

       ·  M&A migrations can happen gradually, with both old and new routing numbers active simultaneously without outages.
       ·  New services can roll out incrementally, without “big bang” conversions that risk downtime.
       ·  Customers can transact anytime, knowing their payments will be processed instantly, even if the back end is juggling multiple systems because of ledgering capabilities in shadow core of the operating system.

Banks planning for M&A (or already living in a post-merger state) need an operating system that’s flexible enough to manage multiple routing numbers, multiple cores, and multiple rails without requiring an army of ops staff to keep it running.
 

That’s the playbook that lets you:
 

          ·   Keep the lights on during a merger.
          ·   Launch new rails without breaking old ones.
          ·   Migrate at your own pace, not your vendor’s.
 

Because in payments, speed is good, but control is everything. If your bank is undergoing a merger and you’re looking for expert help with merging your payment operations, contact us here.