When you buy a rural bank in an emerging market as a fintech, digital bank or investor, the loan book is the part everyone examines, but the core banking system is the part that really decides whether the deal works. Credit quality can be sampled and provisioned for, but the technology you inherit, the core, the data, the integrations, the compliance infrastructure, are all what determines whether you can execute the strategy you bought the licence to pursue, and these elements are routinely the least examined parts of these transactions. 

Accenture research on financial services M&A found that bank mergers which failed to deliver expected synergies most often cited technology integration as the primary cause, with data harmonisation failures persisting in the combined systems for years after physical integration was declared complete. Across M&A more broadly, a Harvard Business Review study puts the share of mergers that fail during integration at 70 to 90 percent, and analysis of post-merger integration finds IT integrations run into major problems around 84% of the time. The pattern is consistent enough to plan around: the deal is won or lost on the technology, and the technology is what diligence teams look at last. 

Here’s why technology diligence gets skipped, the specific risks hiding in an inherited core, and the questions that turn a technology problem discovered after close into a negotiating point discovered before it. 

Why does technology due diligence get skipped? 

Not because acquirers think it does not matter, but because it is harder to do than financial diligence and the deal timeline rarely makes room for it. Technology due diligence in bank M&A is frequently compressed, under-resourced, and narrowly scoped, missing the risks that drive post-close cost overruns. A financial model can be built from statements the seller already produces. Assessing a core banking platform means understanding architecture, data quality, integration fragility and regulatory technology debt, and much of that is invisible from the outside until someone with the right expertise goes looking. 

The cost of leaving it late is specific in banking, because the regulator is part of the transaction. Technology problems discovered after close become examination findings for the combined institution, and merger applications require the acquirer to demonstrate that the combined technology architecture is sound. A gap found during diligence is a line in the negotiation. The same gap found after close is a remediation project you own, on a timeline the examiner sets. 

There is a reasonable chance the core you are inheriting is one the seller was already unhappy with. An American Bankers Association survey found roughly one-third of financial institutions are dissatisfied with their core technology providers, rising to nearly 60% among banks with fewer than two years left on their contract. Buying the institution means buying the contract, the lock-in, and the dissatisfaction with it. 

What are you actually inheriting when you buy the core? 

Six things come with a bank, and they carry very different levels of risk.  

• The licence, whose value depends on the regulator approving the change of control 

• The loan book, which is quantifiable and can be discounted 

• The branches and people 

• The obligations, including deposits and any open findings from the last examination 

• The governance the regulator expects to keep seeing 

• The core, the technology platform everything else runs on 

Of those six, the loan book is the one buyers instinctively over-examine and the core is the one they under-examine. That is the wrong way round, because you are usually not buying the institution to run it unchanged. You are buying it to modernise, to turn a rural bank or a legacy lender into a real-time institution, and that transformation lives or dies on the core you start from and your freedom to replace or extend it. 

The questions to ask before you sign 

Know what to ask before signing so that the cost of fixing what you find is priced into the deal.  

The five questions that matter most 

1. What percentage of core functionality is exposed through documented, versioned APIs? 

Complete, versioned API coverage is what lets a buyer integrate, automate and modernise without a vendor release for every change. Partial coverage caps product velocity and turns every integration into a bespoke project, which shows up directly in launch timelines. 

2. Does the platform support real-time events, or must downstream systems poll or reconcile in batch? 

Real-time events let the institution act at the moment something happens, on fraud, collections and customer experience. A batch-bound core limits the products a buyer can launch and the AI it can run, which constrains the growth case the valuation rests on. 

3. Can the acquirer access governed transaction-level data without depending on vendor-built reports? 

Governed, direct access to transaction-level data is the foundation for analytics, AI and regulatory reporting. Dependence on vendor-built reports slows every decision and raises regulatory risk, because the institution cannot produce or explain its own numbers on demand. 

4. What are the proven throughput, end-of-day and availability limits under projected growth? 

The core has to hold at the volumes the deal thesis assumes. Proven throughput, end-of-day and uptime limits tell a buyer whether the platform can carry the growth it is paying for, or whether a costly migration is coming, which belongs in the valuation now rather than as a surprise later. 

5. Can modernisation be phased by product or capability, or does change require a full replacement? 

A platform that modernises in stages lets a buyer stabilise, then improve, without betting the institution on a single cutover. A core that can only be replaced wholesale makes modernisation slower, riskier and more expensive, and pushes back every launch that depends on it. 

Want to go deeper? Here’s a wider pool of questions to go through.  

Architecture and technical debt 

1. What core does the target run, which version, and how far has it been customised from the vendor standard? Heavy undocumented customisation is where migration cost hides. 

2. Is the core real-time or batch? Establish what genuinely updates instantly versus what waits for an overnight cycle. 

3. How much of the codebase is bespoke, and who understands it? Confirm whether critical knowledge sits with one or two people who are not on retention. 

4. What is the contract position with the incumbent vendor? Check for termination fees, lock-in clauses and data-extraction charges that survive a change of control. 

5. Can the core expose its data and functions through APIs, or is every integration a custom build? This determines how quickly you can modernise anything. 

Data quality and integration 

6. Is customer, account and transaction data held in one coherent model, or spread across systems that must be reconciled? Fragmentation is the single most common driver of failed integration. 

7. Can you extract a complete, clean customer record today, and how long does it take? The answer tells you the true state of the data underneath the reports. 

8. What is the real data quality picture: duplicates, gaps, unreconciled entries, manual workarounds? Assume the demo hides the mess; ask to see the mess. 

9. What third-party integrations does the institution depend on, and which are fragile, undocumented or out of support? Each one is a dependency you inherit. 

10. How is historical data stored, and what will migrating it actually involve? Migration scope is where timelines slip. 

Regulatory and compliance technology 

11. Can the institution produce its regulatory reports directly from the core, or are they assembled by hand in spreadsheets? Manual reporting is a finding waiting to happen. 

12. What is the state of the AML and transaction monitoring infrastructure? This is the most consistently underweighted risk in bank M&A.  

13. Is the KYC and onboarding technology capable of meeting current requirements, or running on forbearance you will not enjoy? You inherit the remediation. 

14. What audit trail exists for transactions, decisions and access, and would it survive examination? Auditability is the property regulators test first. 

Security, resilience and people 

15. When was the last independent security assessment, and what did it find? Note that the average time to identifyand contain a breach is around 280 days, so an institution can be compromised at the point of sale without either party knowing. 

16. What is the disaster recovery position, and has it ever been tested? Untested recovery is not recovery. 

17. How does the core perform under peak load: payday, month-end, campaign spikes? Peak behaviour is where scale problems appear. 

18. Does the institution have the internal engineering capability to support a modernisation, or will everything depend on external resources? Capability gaps become your hiring plan. 

19. What is the realistic cost and timeline to modernise or migrate off the inherited core, and how does that change the valuation? This is the question every other answer feeds into. 

The reason to run this before signing rather than after is financial as much as operational. Industry research findsbank technology integrations frequently run 50 to 100 percent over budget and more than 60 percent beyond their timelines. A cost that size belongs in the deal price, not in a surprise the year after close. 

Stabilise, then modernise 

The instinct after closing is to move fast on the transformation that justified the deal. The sequence that works is the opposite in its first phase. Stabilise before modernising, and harmonise data before consolidating systems. Data harmonisation failures that persist for years after integration are the most common root cause of merger technology problems and consolidating onto one system before the data is clean simply runs the combined institution on duplicated, conflicted records.  

A platform that is API-first, real-time and built for governed data access lets an acquirer move from a stabilised legacy institution to a modern one on a bounded, phased timeline instead of a single high-risk replacement. Oradian is built for exactly that transition, with in-market implementation teams in Makati, Lagos and Zagreb who understand the specific regulatory environment and payment rails of the market you have entered, so the modernisation happens with people who know the market rather than an integrator learning it on your deal. 

The acquirers who examine the core as closely as the loan book, then modernise it in the right order, launch the institution they set out to build. The ones who do not spend year one discovering what they bought. 

Breaking into emerging markets? Use Oradian 

The questions above give a buyer a clear test: can the acquired platform carry the business you intend to build? Oradian gives acquirers a way to answer that with certainty and a route to act on it.  

Our in-market teams assess the inherited core against the business the buyer is planning, whether its data, APIs, real-time capability and scale can carry the strategy, and where the gaps are. Where the platform falls short, Oradianprovides the foundation to close the gap through a phased modernisation: stabilising the institution first, harmonising its data, then moving onto real-time processing, open integration and governed data access in bounded stages.  

That means rural bank buyers get a modern core without a single high-risk replacement, delivered by teams in Makati, Lagos and Zagreb who know the market, the regulator and the payment rails.  

Whether you’re assessing a core before you sign or planning the modernisation after a deal has closed, our team can walk through what it means for your target, your market and your timeline. Talk to us at vanda.jirasek@oradian.com