The year is 2026, you’re facing a core modernisation, and you wake up to this barrage of emails:
- Your board wants to know how you’ll maintain financial accuracy during migration.
- Your auditors want evidence the new system meets regulatory standards.
- Your CEO needs proof the investment won’t compound operational risk.
These are the governance questions you’ll face that will determine whether a core modernisation project gets funded, executed, and approved by regulators.
When core banking modernisation is positioned as an infrastructure upgrade, the business case emphasises technical architecture and system replacement, with risk and finance leaders only engaging at approval gates, reviewing proposals they can’t fully evaluate because the governance framework hasn’t been built yet.
So, by the time the migration begins, accountability is unclear, reconciliation procedures are incomplete, and the institution is absorbing execution risk that should have been designed out months earlier, with you sitting in front of that risk, which is barrelling towards you, all while your hands are tied behind your back.
This article addresses what CFOs, Chief Risk Officers, and audit committees should verify before a core modernisation project proceeds. This article is not a checklist of what vendors promise, but it contains what governed transformation actually requires.
The three questions that determine governance success
Core modernisation introduces execution risk across three domains. If any one of these areas fails, the project fails, regardless of technical quality.
Can you prove transaction integrity every day of migration?
Migration moves transaction data between systems. Every transfer creates reconciliation points where errors enter undetected. If your general ledger cannot be reconciled daily discrepancies accumulate until they’re too large to trace back to source.
Most modernisation projects assume reconciliation happens at cutover. This is too late. By the time you discover a variance of 0.3% across six months of transactions, you cannot isolate which batch, which day, or which process introduced the error.
What finance leaders should demand: Automated reconciliation reports generated daily throughout migration, not just at milestones. Define variance thresholds before migration starts; typically 0.01% for transaction values and zero tolerance for transaction counts. Any variance above threshold stops the next migration phase until the root cause is identified and corrected.
If the vendor cannot demonstrate how their platform maintains double-entry accounting integrity during each migration stage, the project is not ready for approval.
Do you have documented fallback procedures for every migration phase?
Migration does not proceed smoothly; data anomalies surface, integration points fail, and customer-facing systems behave unexpectedly under production load. When this happens (and it will) you need defined procedures to roll back to a stable state without any data loss.
Many projects document happy-path migration but leave rollback procedures undefined until problems occur. This forces teams to improvise under pressure, which is when mistakes compound.
What risk leaders should demand: Written rollback procedures for every migration phase, tested in non-production environments before production deployment. Each procedure must define the decision criteria that triggers rollback, the maximum time window for rollback execution, and how customer operations continue during rollback.
If rollback procedures are marked as to be developed or will be handled by vendor support, the governance framework is incomplete.
Who is accountable when things go wrong and do they have the authority to act?
Core modernisation projects distribute responsibility across technology teams, operations, vendors, system integrators, and third-party providers. When something fails—a reconciliation variance, a customer-facing error, a payment rail disruption—decision-making becomes fragmented. Without clear accountability, teams wait for consensus before acting. This delays response and amplifies customer impact.
What governance leaders should demand: A single accountable executive for migration outcomes. These should not be project management outcomes, but business outcomes including transaction accuracy, customer continuity, and regulatory compliance. This executive should have the authority to halt migration phases, engage vendor escalation, and make trade-offs between timeline and risk.
Supporting this executive should be defined escalation paths with response-time commitments. If a critical issue surfaces, who responds within two hours? Who has the authority to decide to activate a rollback? Who communicates with regulators if required?
If accountability is described as shared or collaborative, it is actually undefined.
The compliance risks that surface after go-live
Regulators and auditors evaluate core banking systems through a specific lens: Can you prove what happened, when it happened, who authorised it, and whether it complied with applicable rules?
Many modern cores are built for speed and configurability, with product managers able to adjust lending terms, fees, eligibility criteria, and operational workflows without engineering dependencies. This is valuable, but only if every change is logged, approved, and reversible.
When configurability lacks governance, compliance risk compounds silently until it surfaces in examinations.
Change tracking and approval workflows
Every product configuration change must be traceable to a specific user, timestamp, and approval workflow. Without this, you cannot demonstrate to auditors that changes were authorised.
What compliance leaders should verify
- The new core maintains immutable audit logs for all configuration changes.
- Logs must include user identity, timestamp, before-and-after values, and approval chain.
- Changes made outside approval workflows should be technically prevented, not just discouraged.
Test this during vendor evaluation: Ask the vendor to demonstrate a product configuration change, then produce the audit trail showing who made it, when, what approvals were required, and whether the approval workflow was followed. If this cannot be demonstrated in the evaluation environment, it will not exist in production.
Data retention and regulatory reporting
Regulators require transaction history, customer communications, and decision rationales to be retained for defined periods, often seven to ten years. During modernisation, historical data must migrate accurately and remain accessible in formats regulators accept.
What compliance leaders should verify:
- The migration plan includes complete historical data transfer with validation procedures.
- The new platform must be able to generate regulatory reports for periods that span the old and new systems.
- If a regulator requests transaction history from three years ago, you must be able to produce a unified, accurate report.
This is not automatic. Many modern cores do not import historical workflows, approval chains, or customer communications from legacy systems. If regulatory reporting depends on this data, migration must include it or you should be able to maintain parallel access to both systems indefinitely.
Customer data accuracy and consent management
Data protection regulations require that customer information is accurate, current, and used only with appropriate consent. During migration, customer records transfer between systems. If data mapping errors occur, for instance, if addresses are truncated or consent flags lost, the institution is non-compliant from day one.
What compliance leaders should verify:
- Customer data validation occurs before, during, and after migration.
- Validation should include sample testing across high-risk fields: names with special characters, addresses exceeding field lengths, phone numbers in multiple formats, consent timestamps and flags.
If validation finds a 2% error rate during testing, do not assume errors will resolve in production, assume they will compound.
The financial risks that don’t appear in the business case
Core modernisation business cases typically quantify implementation costs, licensing fees, and training expenses. Three specific categories of financial risk are consistently underestimated or absent entirely.
Opportunity cost of delayed revenue
If your growth plan includes launching new products, entering new customer segments, or enabling partnerships, delays in modernisation delay this revenue. Every month the current core prevents you from shipping a new product is a month of lost revenue that may never return.
What finance leaders should calculate: Quantify the revenue your current core is blocking. If you cannot profitably serve customers below a certain balance threshold because operational costs are too high, calculate the revenue from expanding downmarket. If product launches take nine months instead of six weeks, calculate the revenue from three additional products per year. This opportunity cost should be compared to the cost of modernisation.
In many cases, delaying modernisation by 12 months costs more in lost revenue than the modernisation project itself.
Operational costs that scale with manual workarounds
When your core cannot support required functionality, operations teams build workarounds: manual processes, spreadsheet-based tracking, email-based approvals. These workarounds allow business to continue, but they scale linearly with volume.
If you serve 100,000 customers with five people managing manual processes, serving 500,000 customers requires 25 people. Revenue scales, but operational cost scales proportionally, which destroys margins.
What finance leaders should calculate:
- Identify processes that scale linearly with customer volume or transaction count.
- Calculate the cost of these processes at your three-year growth target.
If the cost becomes unsustainable, modernisation is required for profitable growth.
Customer remediation and regulatory penalties
If migration errors cause customer-facing problems such as incorrect account balances, failed payments, unauthorised fees, your institution must remediate affected customers and potentially face regulatory penalties.
Remediation costs are often underestimated. If 0.5% of customers experience errors during migration, that might seem acceptable. But if you serve 300,000 customers, that’s 1,500 affected accounts. Each requires investigation, correction, customer communication, and potentially compensation. At an average cost of $50 per remediation, that’s $75,000, plus reputational damage and regulatory attention.
What finance leaders should model:
- Include a remediation reserve in the business case.
- Assume a baseline error rate based on migration testing results and model the cost at scale.
- If testing shows a 1% error rate, budget accordingly.
How to structure governance before migration starts
Finance and risk leaders should require these governance elements to be in place before approving the project.
Define reconciliation cadence and variance thresholds
Establish daily reconciliation between old and new systems during parallel operation, define what constitutes an acceptable variance, both as a percentage and as absolute value and define escalation procedures when variances exceed thresholds. Document who reviews reconciliation reports, who investigates variances, who has authority to halt migration if variances persist, and what constitutes resolution.
Establish phase-gate criteria with measurable conditions
Each migration phase should have defined success criteria that must be met before the next phase starts. These should be measurable, not subjective.
For example: Phase 2 begins when Phase 1 has operated for 30 days with zero customer-reported balance discrepancies, daily reconciliation variances below 0.01%, and zero critical incidents in the previous 14 days.
Phase gates ensure that problems are resolved in controlled environments before they scale to full production.
Assign single-point accountability for business outcomes
Designate one executive, typically a COO or CFO, as accountable for migration business outcomes. This executive has authority to halt phases, escalate vendor issues, make trade-offs between timeline and risk, and communicate with regulators if required.
Supporting this executive should be a governance committee with representatives from finance, risk, operations, technology, and compliance. The committee reviews phase-gate criteria, approves variance threshold changes, and validates that governance procedures are followed.
Document vendor accountability and support commitments
Vendor contracts should specify response times for critical issues, availability during migration phases, and accountability for errors introduced by vendor-supplied components.
For example: Vendor provides 24/7 support during migration phases with two-hour response time for critical issues. Critical issues are defined as: reconciliation variances exceeding threshold, customer-facing transaction failures affecting more than 100 customers, or payment rail disruptions.
Without contractual commitments, vendor support during problems becomes a negotiation instead of an obligation.
The questions that determine readiness
Before approving core modernisation, finance and risk leaders should verify that clear answers exist for these questions:
- How will we prove transaction integrity to auditors throughout migration?
- What happens if we discover a material error three weeks into a migration phase?
- Who has authority to halt migration if customer impact exceeds acceptable thresholds?
- Can our new platform produce regulatory reports that span old and new systems?
- What is our contractual recourse if vendor support is unavailable during a critical incident?
Ultimately, core modernisation is not a technical project that finance and risk leaders can approve at gates and then hand to technology teams, it is a transformation that introduces financial accuracy risk, compliance risk, and operational continuity risk that only finance and risk leaders can govern effectively.
When governance is built into the project from the start through daily reconciliation, defined rollback procedures, clear accountability, and measurable phase gates, modernisation becomes controllable.
The question is not whether to modernise. It’s whether to modernise with governance or without it.
Ready to see governed modernisation in practice?
Oradian was built to support daily reconciliation, immutable audit trails, phased migration with defined rollback procedures, and the compliance evidence that regulators and auditors require. If you are considering a core modernisation project and want to understand how governance can be built into execution, rather than added afterward, drop vanda.jirasek@oradian.com an email and we’ll show you what controlled, auditable transformation looks like.
