When Banks Merge, Their Technology Must Learn to Operate as One
A bank merger brings together more than core systems. It must reconcile customer identities, product promises, payment routes, security boundaries and operating responsibilities—while everyday banking continues.
Perspectives · Inside the Banking Backbone
A bank merger may be announced through a new name, a larger balance sheet and a promise of broader reach. Inside the organisation, a different question emerges: how do two functioning banks become one functioning bank without losing control of customer service, money or risk?
Each institution brings more than applications and infrastructure. It brings years of product decisions, customer commitments, accounting treatments, access rules, exceptions and operational habits embedded in technology.
The technology challenge is to make these different operating realities work together—and eventually simplify them—while customers continue to bank.
One merger, several transition dates
The legal effective date, brand transition, customer migration and technology consolidation need not happen together. A bank can become one legal entity while continuing to run separate core banking systems, mobile applications and operational processes under an approved transition arrangement.
That distinction matters. Leadership needs to define what “one bank” means at each stage: common financial reporting, shared customer servicing, unified risk visibility, a single digital experience, or a consolidated technology estate. These are connected outcomes, but each has different dependencies.
A plan built around one merger weekend can overlook the months of coexistence surrounding it. During that period, the bank needs to know which system owns each account, which team resolves each exception and which records support the consolidated position.
Before completion, integration preparation must also respect the permitted boundaries for information sharing and access. Planning a future combined bank does not itself authorise unrestricted access between the existing institutions.
What changes across the IT landscape?
Almost every technology domain needs an explicit disposition: retain, integrate, migrate, replace or retire. Some systems can remain separate for a time; others need a consolidated view much earlier.
| Technology domain | What must be resolved | What can be missed |
|---|---|---|
| Core banking and products | Accounts, deposits, loans, interest, charges and product rules | The same product name can conceal different customer terms |
| Customer data and CRM | Customer identifiers, KYC, relationships, consent and servicing history | Matching people incorrectly or losing mandates and complaints |
| Payments and cards | Routing, settlement, identifiers, mandates, disputes and reversals | A payment initiated before migration may return afterwards |
| Channels and branches | Apps, internet banking, ATM services, branch tools and corporate connectivity | A successful login can hide unavailable banking functions |
| Integration | APIs, queues, files, database feeds and partner connections | Old identifiers, credentials and duplicate message processing |
| Security and identity | Employee access, privileged accounts, machine identities and cryptographic keys | Equivalent role names with very different permissions |
| Infrastructure and recovery | Networks, hosting, capacity, backups and disaster recovery | A shared dependency can weaken previously independent recovery paths |
| Finance, risk and reporting | Ledgers, exposure aggregation, definitions, lineage and reporting periods | Consolidated totals that conceal inconsistent underlying treatment |
| Operations and suppliers | Service ownership, schedules, licences, contracts and specialist knowledge | Costs and dependencies that survive application retirement |
The first architecture decision is how to coexist
There are three broad choices. The bank can migrate onto one institution’s platforms, retain selected strengths from each estate, or move both towards a new target architecture. The choice may differ by domain.
Consolidating onto one existing platform can reduce duplication, but the chosen system may need significant capacity, functional and control improvements. Selecting the strongest platform in each domain can preserve useful capabilities while creating additional interfaces. A new platform can support a future operating model, but adds transformation uncertainty to merger uncertainty.
The acquiring bank’s platform should not win automatically. Nor should the newest platform. A defensible decision compares business fit, resilience, security, scale, migration complexity, skills, contractual constraints and total operating cost.
Whatever the destination, the transition architecture deserves its own design. If accounts remain in two cores, how does a branch identify the owning core? Where are customer limits checked? How are consolidated reports reconciled? Can a channel route transactions correctly during partial migration?
Temporary routing layers and adapters can protect continuity. Without ownership, monitoring and retirement criteria, they can also become permanent sources of cost and failure.
The same core banking software does not mean the same bank
Two institutions may run the same vendor’s core banking product and still have materially different implementations: releases, customisations, interest calculations, product parameters, business calendars, accounting events and batch sequences.
Consider two fixed deposits labelled “one-year deposit”. One implementation may apply a different compounding convention, premature-withdrawal treatment or rounding method. Copying the opening balance into the target proves that a value moved. It does not prove that the next interest calculation will honour the original commitment.
Product mapping therefore needs business and finance decisions before technical conversion. Which terms must continue for existing contracts? Which products stop accepting new business? Which differences need target-system configuration or approved exception handling?
The same discipline applies to loan repayment schedules, rate resets, overdue calculations, collateral links, liens, nominees and account-operating instructions. Product harmonisation and data migration should be governed together, with customer communication where required.
Customer consolidation is an identity problem
A person may hold accounts in both banks under different customer information file numbers, addresses or name spellings. Conversely, two different people may share a name, phone number or household address.
Matching too aggressively risks combining unrelated records, exposing information or applying the wrong restrictions. Matching too cautiously leaves fragmented relationships, duplicate communications and incomplete visibility of exposure.
A shared mobile number, for example, may belong to a family contact rather than identify one customer. It should not by itself trigger irreversible consolidation. Matching needs appropriate evidence, confidence thresholds, review of ambiguous cases and an auditable record of decisions.
Customer consolidation must preserve account-specific rights. A joint account, corporate account and personal account can involve the same individual without granting identical visibility or transaction authority. A unified customer view must respect those distinctions.
KYC evidence, beneficial ownership, risk classifications, deceased-customer markers, legal restrictions, consent records and open service requests need explicit treatment. A merged record is useful only if the bank can explain where its attributes came from and what they mean.
Payments carry the old bank into the new one
Changing an internal account number is only part of a payment migration. Customers, employers, merchants, corporate systems and external networks may still use previously issued identifiers.
For an Indian bank, the assessment may include account and branch identifiers, IFSC routing, UPI relationships, NACH mandates, card servicing, NEFT/RTGS and IMPS connectivity, cheque processing and settlement arrangements. Which identifiers change, which continue and for how long depends on the approved scheme and the relevant network arrangements.
The difficult cases often arrive later: a returned payment, a card dispute, an old cheque or a mandate presented after account migration. The bank needs historical mappings and a service path that remains valid after the original platform stops processing new transactions.
Illustrative failure: an inward-payment route is changed to the surviving bank, but an existing mandate still references the former account mapping. Normal transfers succeed while recurring collections fail. A dashboard showing aggregate payment availability may miss the affected customer group.
Testing must cover the lifecycle: initiation, authorisation, debit, external submission, settlement, rejection, reversal and reconciliation. Every in-flight instruction needs an accountable owner across the cutover boundary.
The API can be available while the journey fails
A merger can change domains, API gateways, service accounts, client identifiers, certificates, cryptographic trust, source addresses and network allowlists. An interface inventory should record these dependencies alongside schemas, schedules, consumers and support owners.
Illustrative failure: the merged bank activates a new gateway and rotates production credentials. Most consumers receive the new configuration, but one corporate batch service retains the previous API key. The gateway is healthy and customer channels work; salary-file processing fails overnight.
The preventive work includes production-identity validation, credential-distribution checks across every consuming instance, expiry monitoring and an end-to-end run using the actual production connection. A successful network test does not prove authentication or business processing.
Data meaning also changes at interfaces. A “branch code” or “customer ID” may be unique only within the originating bank. Until mappings are resolved, messages need enough origin context to prevent collisions.
Queues and event streams need clear ownership too. Running old and new consumers together can create duplicate postings. Replaying a failed message safely requires a stable business identity and proven duplicate protection across the transition.
A shared network must not imply shared trust
Connecting estates can expand the consequences of an existing weakness. An unpatched server or overprivileged account in one environment may gain a path towards the other if connectivity is opened too broadly.
NIST’s zero trust architecture rejects implicit trust based solely on network location or ownership.[3] Applied to a merger, the practical lesson is to establish access according to verified identities, device posture, resource needs and approved purpose, rather than assuming the combined corporate boundary is sufficient.
Identity integration includes employee directories, single sign-on, privileged access, vendor access and non-human identities used by applications and schedulers. Role names need comparison against actual permissions: “branch manager” may mean different approval limits or data scopes in each institution.
Combining roles can also create conflicts. Someone who could create a payment in one estate might gain approval authority through a second role in the other. Segregation-of-duties checks must examine effective access across the combined environment.
Security monitoring needs coverage of both estates and their new connections. Domain changes and migration communications also create opportunities for impersonation, making clear customer guidance and coordinated fraud monitoring part of technology readiness.
Infrastructure consolidation changes the failure model
Capacity planning needs more than adding the two banks’ average transaction volumes. Peaks can coincide around salaries, repayments, settlements and reporting. Migration jobs, synchronisation, retries and historical queries add temporary load precisely when teams need operating headroom.
Network integration can expose overlapping private IP ranges, incompatible routing, DNS dependencies and inconsistent segmentation. Branch connectivity, endpoint management, email, collaboration tools and contact-centre telephony also need transition plans; these services determine whether employees can operate the bank.
Disaster recovery must be reassessed for the combined service. Two applications with separate recovery tests may become dependent on one identity platform, gateway, network link or key-management service after consolidation.
The Basel Committee’s operational resilience principles emphasise critical operations, dependency mapping, continuity testing and third-party dependencies.[1] The merger implication is to test recovery across the new banking journey, including the components that now connect formerly separate estates.
Backups must also remain usable. Historical data encrypted under an old key-management arrangement is not meaningfully retained if the bank retires the keys or the means to restore and interpret it.
Reconciliation must prove both value and meaning
Moving every row is a technical milestone. Establishing a correct financial position requires more evidence.
Validation should cover account balances, accrued interest, loan principal and overdue components, limits, liens, suspense positions, settlement accounts and sub-ledger-to-general-ledger reconciliation. Opening positions need a defined extraction time and a controlled treatment of transactions occurring around that boundary.
Illustrative failure: two conversion errors offset each other in the overall total. One group of accounts is overstated and another understated. The bank-wide balance reconciles, yet individual customers are wrong.
Controls therefore need several levels: record counts, aggregate values, product and branch comparisons, account-level exceptions and recalculation of important business outcomes. Finance should distinguish migration adjustments from merger accounting entries and new operational transactions.
Risk and management reporting face a related challenge. “Active customer”, “overdue loan” or “digital transaction” can mean different things in each bank. Adding two reports together does not resolve their definitions.
BCBS 239 provides a useful reference for governance, data architecture, accuracy, completeness and timely risk reporting.[2] Its formal applicability is distinct from its value as a design reference; it should not be presented as an identical direct obligation for every bank.
The operating model and contracts are part of the architecture
A combined estate needs named service owners, support queues, severity definitions, batch ownership and escalation authority. A customer should not be passed between former-bank teams because an application boundary survives the merger.
Branch and operations staff need practice with changed workflows and unusual cases. Their undocumented knowledge often explains why a batch runs in a particular sequence or why a product has an exception. Losing that knowledge before migration can remove an important control.
Supplier consolidation also takes time. Contracts may require review of assignment, licence scope, volume commitments, support coverage, audit access and exit assistance. Retiring an application does not automatically eliminate its contractual cost.
Using one supplier can simplify support while concentrating dependency. Retaining two can preserve options while increasing integration and operating cost. The business case should include parallel running, data remediation, additional staffing, recovery capability and legacy retention—not only the target licence bill.
Readiness needs gates across the whole transition
A useful programme separates several evidence-based decisions:
- Before legal completion: establish the permitted planning boundary, critical dependencies, transition services, ownership and Day 1 continuity requirements.
- During coexistence: prove routing, consolidated risk visibility, reconciliation, access control and customer servicing across both estates.
- Before each migration wave: rehearse the real sequence and duration, confirm financial acceptance criteria, handle in-flight work and define stop conditions.
- After migration: monitor customer outcomes, payment exceptions, batch completion, financial differences and time-dependent product behaviour.
- Before retirement: prove that retained records are retrievable, residual dependencies are removed, recovery obligations remain covered and contracts and access are addressed.
Rollback needs particular care. Before external settlement and new customer activity, reversal may be feasible. Afterwards, restoring a database snapshot can conflict with transactions already accepted outside the bank. Recovery plans must define that boundary and how controlled forward correction would work.
A successful opening day cannot validate month-end interest, quarter-end reporting or every dispute cycle. Each infrequent process needs rehearsal evidence and a monitored first-live-run plan.
Our perspective
A merger creates an opportunity to simplify technology, strengthen controls and improve service. Realising it requires distinguishing continuity work, consolidation work and optional modernisation.
Combining every desired improvement into one deadline increases uncertainty. Deferring every difficult decision leaves the bank paying indefinitely for two estates. A credible roadmap protects essential journeys first, makes coexistence manageable and retires complexity through explicit milestones.
The acquiring institution does not need to win every technology decision. The combined bank needs systems that support its future customers, products and operating responsibilities.
The merger is technologically successful when the bank can explain every customer relationship, account for every material financial movement, control access across the combined estate and retire old dependencies with confidence.
Key takeaway
A bank merger changes the rules and responsibilities surrounding technology as much as the technology itself. Success depends on preserving customer commitments and financial integrity while deliberately moving from two operating estates to one sustainable bank.
A decision to take back to your team
Two banks use the same core banking product. Their account counts and total balances match after a trial migration. One deposit product calculates the next interest payment differently in the target system. Is migration ready?
The stronger response is to resolve the product-rule difference, establish the treatment for existing contracts, test recalculated outcomes and repeat the relevant reconciliation before accepting that product for migration. Matching totals alone does not demonstrate that the bank can honour the next customer commitment.
Sources & further reading
- Basel Committee on Banking Supervision: Principles for Operational Resilience, March 2021 — reference for critical operations, dependencies, continuity and recovery.
- Basel Committee on Banking Supervision: Principles for Effective Risk Data Aggregation and Risk Reporting (BCBS 239), January 2013 — reference for risk-data governance and reporting quality.
- NIST SP 800-207: Zero Trust Architecture, August 2020 — reference for identity- and resource-based access decisions.
The merger scenarios and implementation recommendations are original editorial analysis. Examples are hypothetical, rather than accounts of a specific bank. Actual identifier transitions, customer-term changes and regulatory obligations depend on the approved merger scheme, applicable jurisdiction and relevant payment-network arrangements.
Related perspective: When a Bank Goes Live, the Real Test Begins.
Put this perspective into practice.
Explore the concepts, make a decision and test what changes when the situation changes.
The article covers the topic that’s most buzzed of late in the banking industry.
Depth of perspectives is really enlightening and the best part of the article is the coverage of different spectra which are impacted by mergers.
A merger is essentially not happening only in board rooms. unless it transpires into delivery touch points the New Organisation cannot leverage on the very decision to merge .
Wonderful to read this Narayanan Sir .Thanks
Thanks for the review sir. We look forward for your regular feedbacks