Core Banking and Payments Platform Implementations: The High-Stakes Playbook

In most industries, a troubled SaaS implementation means delayed efficiency gains, frustrated users, and a difficult conversation with the board. In core banking and payments, a troubled implementation means customers unable to access their accounts, transactions failing at the point of sale, reconciliation errors cascading through downstream systems, and regulators asking questions that carry personal liability implications for the executives who signed off on the programme.

The technical complexity of core banking and payments implementations is not categorically different from other large SaaS rollouts. The integration scope is broad, the data migration is large, and the configuration requirements are detailed. What makes these projects different is the consequence profile. There is no graceful degradation. A core banking system does not have a “partially working” mode that customers experience as inconvenient but tolerable. It either works at the required standard, meaning 24/7 availability, real-time processing, accurate reconciliation, and complete audit trails, or it doesn’t, and the failure is immediately visible to customers, counterparties, and regulators simultaneously.

That consequence profile changes how these programmes need to be managed from first principles.

 

Why Core Banking Implementations Are Fundamentally Different

The distinguishing characteristics of core banking and payments implementations come from the nature of the underlying systems and the regulatory environment they operate within.

 

24/7 Availability Requirements

Retail banking systems cannot be taken offline for maintenance windows in the way that most enterprise SaaS platforms can. Customers access their accounts at all hours. Payment processing runs continuously. The implementation programme must be designed around this constraint from day one: there is no “maintenance window” during which the system can be migrated. Everything that happens, including data migration, cutover, and post-cutover stabilisation, must be designed to occur within the boundaries of what the availability requirements permit.

 

Real-Time Transaction Processing

Payments platforms process transactions in real time. A payment processed at 11:47pm must be posted, reconciled, and reflected in the account balance immediately. The new system’s ability to handle the full transaction processing volume, not just average volumes but peak volumes, must be verified before production deployment. This makes performance testing under production-equivalent load a non-negotiable element of the programme, not an optional quality assurance step.

 

Reconciliation Complexity

Core banking systems sit at the centre of a reconciliation architecture that extends across general ledger entries, interbank settlement, regulatory reporting, and internal management accounts. A migration that moves customer balances correctly but introduces reconciliation errors between the core system and downstream systems creates a problem that may not be visible at go-live but compounds daily until it’s discovered, at which point the remediation requires forensic accounting as well as technical work.

 

Regulatory Approval Gates

For APRA-regulated entities in Australia, and their equivalents in other jurisdictions, core system replacements are not purely internal technical decisions. APRA’s CPS 231 (Outsourcing) and CPS 234 (Information Security) impose obligations that must be satisfied before a new core system can go live. The prudential regulator has the authority to delay or prevent a go-live if they are not satisfied with the programme’s risk management. Building regulatory approval as a genuine dependency in the project timeline, with lead time for APRA engagement, is essential. Treating it as a box-ticking exercise at the end is a programme risk of the first order.

 

The Parallel Running Requirement

Parallel running, operating the old and new systems simultaneously for a defined period before final cutover, is standard practice in core banking implementations, and for good reason. It is also consistently underestimated in complexity, duration, and cost when programmes are initially scoped.

 

How Parallel Running Works

Parallel running requires that every transaction processed in the production environment is processed through both systems and that the outputs reconcile. This means double the operational overhead: support teams managing two systems, reconciliation processes running continuously to compare outputs, and a clear decision framework for what constitutes an acceptable discrepancy. There will always be timing differences; the question is which differences are within tolerance and which indicate a genuine system error.

The duration of parallel running is determined by data, not by schedule preference. A parallel run ends when the new system has demonstrated that it can handle the full range of transaction types, peak volumes, and edge cases without discrepancies above the defined tolerance threshold. If the parallel run data shows ongoing discrepancies in a particular transaction type, the parallel run extends until the root cause is identified and resolved. A parallel run that ends because the schedule says it should end, rather than because the data supports it, is a programme risk that typically surfaces in post-cutover stabilisation at much higher cost.

 

The Data Synchronisation Challenge

Parallel running also has a data migration dimension that is often underappreciated. Customer account data migrated to the new system during parallel running is live data that changes constantly. The migration is not a point-in-time exercise. It’s a continuous synchronisation challenge until the moment of final cutover, when the old system is turned off and the new system becomes the sole source of truth. Managing that synchronisation correctly, and verifying it continuously during parallel running, requires dedicated technical resource and a rigorous reconciliation process.

 

Cutover Weekend Planning

The cutover from old system to new is the highest risk moment in a core banking or payments implementation. The planning for that weekend needs to begin months before it happens.

 

The Cutover Playbook

A core banking cutover plan is not a document. It’s a detailed, sequenced operational playbook that covers every action required from the moment the old system is taken into restricted mode to the moment the new system is confirmed in full production operation. It should specify: who does what, in what order, with what dependencies between steps, and with what rollback triggers at each stage.

 

Rollback Planning

The rollback plan deserves as much design attention as the go-forward plan. At what point in the cutover process is rollback no longer viable? What are the criteria that would trigger a rollback decision rather than a decision to push through a problem? Who has the authority to call a rollback, and what is the communication cascade if that decision is made? These questions must be answered before cutover weekend, in writing, with the relevant stakeholders briefed and in agreement. A cutover team that reaches a decision point at 3am and discovers there’s no agreed rollback trigger is a programme in serious trouble.

 

Cutover Rehearsals

Cutover rehearsals are standard practice in well-run core banking implementations. Running the cutover sequence in a non-production environment, with the actual team, following the actual playbook, against production-equivalent data volumes, identifies timing problems, dependency gaps, and communication failures that can’t be found in a document review. The first time the cutover team runs through the full sequence should not be the real thing.

 

QA Intensity: Testing Every Transaction Type

The QA requirements for a core banking or payments implementation are qualitatively different from standard SaaS implementations in two key ways: test coverage breadth and data volume requirements.

 

Transaction Coverage

Test coverage in a core banking implementation must include every transaction type the system will process in production. Not a representative sample. Every type. This is not a theoretical standard. It’s a practical requirement that comes from the consequence profile described above. Transaction types that haven’t been tested are transaction types that may fail in production in ways that affect customer accounts. For a retail bank, the transaction catalogue runs to hundreds of types across deposits, withdrawals, transfers, direct debits, direct credits, card transactions, fee processing, interest calculations, and interbank settlements. Each one needs test cases. Each one needs to pass.

 

Production-Equivalent Data Volumes

Data volume requirements distinguish performance testing in core banking from performance testing in most other contexts. The test environment needs to be loaded with data at production-equivalent volumes, not a subset of accounts that’s large enough to look realistic but small enough to perform well. A system that performs acceptably under 20% of production data volume and fails under full load has not been tested. It’s been validated for a scenario that doesn’t exist.

In practice, this means that core banking QA programmes require dedicated performance test environments with production-equivalent data, realistic load simulation that models actual customer transaction behaviour across a 24-hour period including peak periods, and performance test cycles that run multiple times, not just at the end of the programme but iteratively as configurations are finalised and integrations are completed. A performance problem identified three sprints before go-live is a manageable technical problem. The same problem identified in final testing is a programme risk that may require schedule revision and executive escalation.

 

Building the QA Workstream for Core Banking

The QA workstream on a core banking implementation needs to be structured from the first sprint with the same rigour as the development workstream. Sprint-embedded QA, meaning testing each piece of functionality as it’s delivered rather than accumulating functionality for a final test phase, is not just a quality best practice in this context. It’s a financial and regulatory risk management requirement.

 

Documentation Standards

The test documentation standard is also higher. In an APRA-regulated environment, implementation test records may be subject to regulatory review. Test cases must document the requirement being tested with sufficient specificity that an external reviewer can understand what the test validates and why. Test results must be signed off with names and dates. Any defects identified during testing, and their resolution, must be documented in the test management system with a clear audit trail.

 

Regulatory Control Traceability

Specific regulatory controls need to be mapped to test cases explicitly. APRA CPS 234 controls relating to access management, audit logging, and security configuration are not abstract requirements. They have specific, testable system behaviours. A QA specialist on a core banking implementation should be able to produce a traceability matrix showing, for each applicable regulatory control, the test cases that validate compliance and the test results that confirm it passed. That matrix is a compliance artefact as well as a quality artefact.

 

Risk-Based Defect Triage

Finally, defect management on a core banking implementation requires a risk-based triage approach that goes beyond standard severity classifications. A defect that would be rated “medium” severity in a standard SaaS implementation, such as a reporting discrepancy that doesn’t affect transaction processing, may be rated “critical” in a core banking context if it affects regulatory reporting accuracy or creates a reconciliation gap. The severity framework needs to be calibrated for the regulatory and operational context from the start of the programme, not applied with generic definitions that don’t reflect the specific consequence profile of core banking failures.