Table of Contents
Summarize and analyze this article with
Why the strategy choice matters more than the platform choice
The three strategy patterns
1. Consolidate to the acquirer's core
2. Coexist and convert in waves
3. Use the deal to replace both cores
A decision matrix for choosing the pattern
| Factor | Consolidate to acquirer | Coexist & convert | Replace both |
|---|---|---|---|
| Deal size sweet spot | Acquirer >> target | Comparable sizes | Combined asset growth ambition |
| Disruption risk | Medium | Low | High |
| Time to single core | Fast | Medium | Slowest |
| Data foundation required | High (acquirer side) | High (both sides) | Very high |
| Total cost | Lowest | Medium | Highest |
| Upside | Limited | Steady | Largest |
What examiners ask, regardless of pattern
Partner-screening criteria specific to post-M&A core conversion
- Multi-source mapping discipline. Can the partner profile and map two source estates into a target not just one and show a redacted artifact from a prior bank merger?
- Reporting continuity track record. Has the partner converted a bank core without breaking a regulatory report?
- BSA/AML and fraud-model continuity. Treated as a first-class deliverable in the SOW with explicit acceptance criteria, not handed off?
- Strategy honesty. Will the partner tell you when consolidate-to-acquirer is wrong for your data condition?
- Senior staffing through cutover. Named architect and SME in the working sessions on the night of cutover, not juniors with an escalation path?
- Three-year TCO transparency. Including dual-platform run cost if coexistence runs long?
Anti-patterns to avoid
- Consolidating to a core that cannot scale. The acquirer’s core looks fit on paper but fails at combined volumes or product mix. Profile actual data, not slide decks.
- Coexistence without an end date. Coexistence with no exit becomes a permanent dual-platform run cost that erodes deal economics.
- Skipping the model inventory re-baseline. Required regardless of conversion timing; deferring it concentrates SR 26-2 exposure.
- Treating reporting continuity as a post-cutover cleanup. Examiners evaluate what produced on the day, not what was fixed afterward.
- Pyramid staffing across cutover. Defects surface where program risk concentrates; juniors cannot triage them.
Cost realities and the dual-platform run question
TCO modeling for post-M&A core conversion has four buckets: target-platform license/subscription, integration and data-foundation work, dual-platform run cost during coexistence, and the cost of inaction (delayed deal value, slow reporting, customer attrition, model degradation). The dual-platform run bucket is where coexistence strategies erode deal economics if they run longer than planned; build a defined exit window into the strategy, with budget consequences if it slips. The integration and data-foundation bucket is consistently the largest single line and the one vendors exclude from their quotes.
How PiTech approaches post-M&A core conversion
Frequently Asked Questions (FAQs)
What is core banking conversion after M&A?
What are the three strategy patterns?
How do we choose between the three patterns?
How do we choose a partner for post-M&A core conversion?
How long does post-M&A core conversion take?
A defensible Day-1 plus first-quarter integration win is achievable in roughly 90 days; full conversion is typically 12–24 months for mid-market mergers, depending on the chosen strategy, asset size, the number of source systems, the condition of the data layer, and regulatory reporting complexity. Cutover timing should be set by reconciliation readiness, not by calendar; rushed cutovers concentrate risk.
What does post-M&A core conversion cost?
Four buckets: target-platform license or subscription, integration and data-foundation work (largest bucket and the one vendors exclude), dual-platform run cost during coexistence (where deal economics erode if coexistence runs long), and the cost of inaction (delayed deal value, slow reporting, customer attrition, model degradation). Get a specific dollar number for the integration bucket before signing, not a percentage.
What happens to BSA/AML and fraud models during conversion?
They must be a first-class deliverable, not handed off. Inherited models need re-baselining against the combined data estate, alert thresholds re-validated on post-conversion data, lineage rebuilt so analysts can trace alerts to source, and case feedback re-wired into retraining. Skipping this work means monitoring quality degrades silently after cutover and the bank discovers it during the next examination.
How do we protect regulatory reporting through cutover?
Inventory every regulatory report impacted by source-system changes, map upstream fields across both banks, recalculate disclosures in parallel for at least two cycles, retain audit evidence through transition, and lock reconciliation checkpoints before and after each migration wave. CECL, capital, stress-testing, BSA/AML, and Call Reports are the most exposed because they depend on the most data domains.
Should we re-baseline the combined model inventory?
Yes regardless of conversion timing. The integrated institution may inherit duplicate, overlapping, vendor-supplied, or poorly documented models. SR 26-2 (April 2026) re-baselined model risk expectations: capture traditional models, ML models, GenAI use cases, agentic workflows, and vendor models each with owner, purpose, data inputs, risk tier, validation status, monitoring metrics, and retirement/change controls.


