Side-core deployment
Modernize the core without replacing it.
Side-core deployment is a way to run a modern core banking platform beside an incumbent core, in production. With Nucleus BankOS the bank sets the system of record per data class and moves workflows over on its own timeline.
At a glance
- What it is
- A deployment architecture, not a product
- Existing core
- Keeps running; nothing moves on day one
- System of record
- Set per data class: legacy, dual or adapfin
- Integration
- Lightweight read and sync of accounts and transactions
- Cost
- No upcharge for side-core mode
- Exit
- Convert to full core on your timeline, or never
- Nucleus BankOS
- No-code products
- DarkMatter
- Foundry
- Fabric
- Horizon
- Prism
How it works
One experience for customers. Two cores, kept in sync.
Your customers
One experience. They never see which system served them.
Nucleus BankOS
Runs beside, in production
- New products, launched in minutes
- Selected deposit & lending workflows
- Fraud, BSA and cyber on what it can see
- Real-time ledger and exception queues
Customer master
synchronized
Your existing core
Keeps running
- System of record, untouched
- Existing GL and statements
- Settlement on current rails
- Your current contract, still running
Note what does not happen: no cutover weekend, no forced conversion date, and no upcharge for running in side-core mode.
The path
Evaluate, run, then migrate at your pace.
Phase 1: Evaluate
Nucleus runs alongside your existing core, in production, against real operations. Your core keeps running.
Phase 2: Run workflows
Move selected operations over. Customer master stays synchronized. No upcharge for side-core mode.
Phase 3: Migrate at your pace
Shift the core on your timeline, or never. The decision stays yours instead of your vendor’s.
System of record
Who is authoritative, data class by data class.
Every surface works the same way in every mode; what changes is which side is authoritative and where money posts.
| legacy | The incumbent core is authoritative; Nucleus projects the record read-only and posts balanced legs into the shared GL |
|---|---|
| dual | Both systems hold the record; a nightly tie-out proves they match, and exactly one side owns holds |
| adapfin | Nucleus BankOS is authoritative and reads and writes the record directly |
| Accounts and balances | Whichever side owns the pointer is the balance of record |
|---|---|
| Loans | Serviced in Nucleus, or kept on an external register with postings to the shared GL |
| Customer record | Canonical on the authoritative side; the other side projects it |
| Card authorization | Decided against the side that holds balance authority and owns holds |
| General ledger | One shared GL underneath; owners outside Nucleus tie out daily, and drift raises a finding |
When you're ready for full core
Conversion runs in parallel, with your people in control.
Side-core can be permanent. When a bank chooses to convert, adapfin runs the conversion with AI-assisted tooling while the bank approves every gate.
Stand up Nucleus while the data converts
adapfin deploys Nucleus BankOS and trains staff while Continuum, our conversion tooling, works the data. Nothing waits on a single cutover.
- AI agents map and normalize the core profile
- Sampling with continuous error correction
- Testing throughout, not at the end
SMEs validate their own domains
Subject-matter experts in each area check their part as it converts, so problems surface early, where they are cheap.
Cut over in parallel
Customers and employees keep working while the numbers are reconciled. General-ledger parity is proven before cutover.
Built by people who have run conversions
The checkpoints come from bankers who have converted to and from the major legacy cores, so they sit where conversions actually break.
| Mapping | Automated mapping and normalization of the source core’s data |
|---|---|
| Sampling | Advanced sampling with continuous error correction |
| Human oversight | Agents do the heavy lifting; the bank approves at every gate |
| Cutover | Parallel; GL parity proven before switching |
| Timeline | Under 90 days demonstrated for standard environments |
Questions
Side-core banking: what banks ask
What is side-core banking?
Side-core banking is a deployment architecture in which a modern core runs alongside an incumbent core. The bank moves selected products, workflows or data classes onto the new platform without an immediate full-core replacement.
Does side-core replace my existing core?
No. The existing core keeps running and stays authoritative for whatever the bank leaves on it. Nothing is forced to cut over.
Which system is the system of record?
The bank decides, per data class. Each one, such as accounts, loans or the customer record, is set to legacy, dual or adapfin, and a program can be adapfin for deposits and legacy for loans at the same time.
How do the two cores stay in sync?
Money moves as balanced double-entry legs into one shared general ledger, whoever owns the subledger. Where a subledger is owned outside Nucleus, a daily tie-out proves the totals match and raises a finding on drift.
Is fraud and transaction monitoring real-time in side-core?
For activity that flows through Nucleus BankOS, yes. Activity still settled on the incumbent core is analyzed on synced data, near-real-time rather than instantaneous, until those flows move onto the platform.
What can run in side-core?
No-code product deployment for onboarding and servicing, DarkMatter fraud and compliance controls, Foundry lending, Fabric BaaS and embedded finance, Horizon wealth and Prism digital assets.
What integration does side-core need?
A lightweight integration with the existing core, typically a read and sync of accounts and transactions. Nucleus is reached over BroadStreet, a private connectivity layer through the bank’s own network.
Does side-core cost extra, and can we move to full core later?
There is no upcharge for side-core mode; it is the same product. The bank can convert to full core whenever it chooses, with adapfin running the conversion, or stay side-core indefinitely.
How long does a conversion to full core take?
A conversion path of under 90 days has been demonstrated for standard environments. Timelines depend on the source core and the institution’s complexity.
Who stays in control of a conversion?
The bank. adapfin’s conversion tooling, Continuum, does the mapping and error correction, and the bank’s subject-matter experts validate their own areas before anything moves on.
Is there a single cutover weekend?
No. Nucleus is stood up and staff trained in parallel with the data work, and cutover runs in parallel with reconciliation until general-ledger parity is proven.
Move forward without betting the bank.
See side-core run against your workflows before you commit to a full-core decision.