Core replacement is a multi-year, multi-million bet most CIOs cannot reasonably take. CoreFi is designed to coexist with the legacy core and modernize one workflow at a time — under permissions, policy gates, human approvals and a case-level audit record per workflow. The legacy stays system-of-record for what has not moved; CoreFi takes over the journeys where it earns the right to.
The platform is built so the legacy ledger keeps doing what it does — system-of-record for unmigrated workflows — while CoreFi handles the journeys that have moved across. Agents operate inside CoreFi’s governance plane; the legacy is integrated, not replaced. The migration boundary is per workflow, not per system, so progress is incremental, reversible at the routing layer, and auditable.
Until a workflow is fully migrated, the legacy ledger remains authoritative. CoreFi reads and writes through integration adapters; the institution never loses access to its existing books, reports or operator screens.
Workflows that have moved across — onboarding, lending decisions, servicing tasks, treasury operations — run on CoreFi’s real-time core and governed AI control plane. Agents act under permissions, policy gates and human approval routing.
CoreFi records its side of every workflow case-by-case — trigger, retrieved data, plan, policy outcome, API calls, human decisions. Legacy events feed in through integration adapters so the case record remains traceable across the boundary.
Each workflow follows the same four phases: discover what it does, observe in shadow, run in parallel, and only then cut over. The institution decides which workflow earns the next phase — based on evidence from the previous one, not a fixed program-management deadline.
Map the legacy workflow end-to-end: the data it touches, the integration points, the operator screens and batch jobs around it, the controls that already apply. Output: a scoped target workflow and a measurable success definition before any code moves.
CoreFi receives the same inputs as the legacy through integration adapters but produces no side effects. Agent recommendations and policy outcomes are recorded against real traffic so they can be compared with what legacy actually does — without changing what customers experience.
CoreFi handles a defined slice of the workflow live — a customer segment, a product line, a geography — while legacy stays system-of-record. Outcomes are reconciled per case; risk and operations sign off; the slice grows on evidence, not on a Gantt chart.
For the migrated slice, CoreFi becomes the system-of-record. The legacy path drains down or stays as a historical read source. Cutover is per workflow, so the rest of the bank continues unaffected; the next workflow re-enters Discovery on its own timeline.
CoreFi connects to the legacy through the integration surface the bank already runs — APIs, events, file imports and operator-facing exports. The legacy is not asked to be rewritten; the bridge is on CoreFi’s side.
CoreFi calls the legacy through whatever API surface it exposes — REST, SOAP, JDBC views, mainframe gateway services. Adapters live inside CoreFi; the legacy schema does not change for the migration.
Where the legacy emits events (Kafka, MQ, change-data-capture streams), CoreFi subscribes and keeps its working state in sync. Where it does not, CoreFi polls through the API layer and treats the response as the event.
Batch files — positions, reconciliations, regulatory extracts, end-of-day cuts — are first-class inputs and outputs. CoreFi consumes legacy files for shadow and parallel phases, and produces them for downstream systems that still expect the legacy format after cutover.
CoreFi exports metrics, logs and audit events to the bank’s existing observability stack on request. Reconciliation between CoreFi and legacy outcomes during shadow and parallel phases is exposed as a dashboard for risk and operations.
Coexistence is not one program; it is a choice of starting point. Select the path closest to your situation and see what ships first on CoreFi, what stays on the legacy core, how governance and rollback work, and the production evidence behind it. All four paths run on the same platform and the same audit record.
A greenfield digital bank, neobank, EMI or BaaS programme. There is no legacy core inside the migration boundary, so coexistence is the simplest case: CoreFi is the system of record from day one.
The full proposition on CoreFi: onboarding, ledger, lending, payments and channels run on CoreFi APIs from the first customer. Channels connect through headless APIs or white-label.
Nothing. Where group systems exist around the new venture, they consume CoreFi reports and exports through the same integration surface described above; nothing is rewritten to accommodate the launch.
Permissions, policy gates and human-approval routing are active from the first customer. Customer, account, ledger and audit data remain exportable through documented APIs in a standard double-entry model, so the exit path is a data export, not a reverse migration.
An established bank ships one product or journey on CoreFi, such as onboarding, an SME lending product or a deposit product, without touching the rest of the estate.
One journey end-to-end on CoreFi APIs. The resulting accounts, balances and postings write back to the legacy core through integration adapters, in near real time or on batch, whichever the bank’s operations prefer.
Everything else. The legacy core remains system of record for the rest of the bank, and for the journey’s downstream accounting where the bank wants it to.
The journey is decoupled from the rest of the bank by design. Phase transitions require two-eyes approval from named owners on the bank side, and retiring the journey returns the customer file and the audit trail through the same connectors used during sync.
A second core for a discrete segment: digital-only customers, SME, a new brand or a new geography, operated in parallel with the existing core for as long as the business case requires.
The chosen segment runs entirely on CoreFi as an operationally independent core. Two-way data flows cover the shared functions: general-ledger consolidation, regulatory reporting and treasury, with the customer master shared where required.
The existing book, in full. No customer migration is forced; the legacy core continues to serve every customer outside the new segment, on the screens and batch jobs it runs today.
The two cores stay operationally independent and consolidated reporting reconciles across both. Unwinding the parallel core means switching off connectors and exporting the segment, not re-platforming the rest of the bank.
A board-level mandate to retire the legacy core, executed as a sequence of per-workflow phases rather than a single cutover. This is the full strangler-fig pattern described on this page.
The first workflow through the four phases above: Discovery, Shadow, Parallel, Cutover. Each customer cohort, product line or geography follows on the evidence of the previous phase, and AI workflows are introduced phase by phase, never as part of a cutover.
Every workflow that has not yet earned cutover. The legacy ledger remains authoritative for unmigrated workflows until each slice completes its parallel run and the bank signs the cutover.
Each phase is independently reversible until cutover; rollback re-routes new cases to the legacy adapters as an operational decision, not a project. Two-eyes approval gates every phase transition, and for the duration the case-level audit record is structured to reconcile with what legacy records on the same case.
Compare all five implementation paths, including the managed platform →
Every phase is designed so that “back to legacy” is an operational decision, not a project. CoreFi’s control plane keeps the institution in charge of when a workflow moves forward, when it pauses, and when it reverts — and writes every step into the case record.
If a parallel slice or post-cutover workflow needs to be returned to the legacy path, CoreFi re-routes new cases to the legacy integration adapters. State already written by the authoritative system — CoreFi for cutover workflows, legacy for unmigrated ones — is not unwound by the switch; any reconciliation needed is scoped in the reversal runbook prepared with the workflow before parallel begins; detail available on request.
Phase transitions — promoting a workflow from shadow to parallel, expanding a parallel slice, cutting over — require approval from two named owners on the bank side. The approval is logged against the case the way any other policy gate is.
Through shadow, parallel and cutover, CoreFi keeps a case-level record — trigger, retrieved data, agent plan, policy outcome, API calls, human decisions, final state — that is structured to reconcile with what legacy records on the same case. The format is designed to support a bank’s supervisory review process; mapping to a specific bank’s audit standard is scoped during Discovery.
Bring one workflow you would migrate first if the risk envelope held. We will scope Discovery against your legacy core, name the integration adapters, and define what shadow and parallel would look like on your traffic before you commit anything to a program.