The short answer

You can build a neobank on top of an existing core banking system when you stop treating the core as the place where every new digital capability must live. The core remains authoritative for the financial state it already owns. A new platform owns the digital proposition including customer journeys product configuration where appropriate workflow coordination access control channel behaviour and the integration contracts that connect those pieces.

The objective is not to make a legacy core look modern. It is to create a controlled change boundary around it. The core should continue to do what it is good at by maintaining accounts posting financial entries enforcing the product rules it owns settling instructions and preserving the accounting record. The new digital layer should make change faster without quietly becoming a second ungoverned core.

The architecture must be deliberate. It needs a clear system of record middleware that normalises the old world orchestration that coordinates the new one a ledger policy that makes every balance explainable digital channels that are genuinely channel ready and an identity model that supports complex corporate entities and granular multi user access.

The proposition is new. The financial estate does not have to be.

The phrase build a neobank can be misleading. It suggests a single new application with a card, a mobile interface and a marketing launch. The real deliverable is a new operating proposition. It must acquire customers, create accounts, accept and execute payments, show balances, handle exceptions, support staff, produce records, and keep its promises when an upstream dependency is slow or unavailable.

When an institution already operates a core banking system, the question is not whether the new proposition should use the core. It already will, in some form. The question is whether it uses the core as an internal service with a stable contract, or whether every customer journey and product change is forced through core customisation. The first option preserves optionality. The second makes the new proposition depend on the release cycle, data model and implementation style of the existing estate.

For a business banking proposition, that distinction matters early. A company is not a retail customer with a larger balance. It has legal entities, directors, signatories, delegated users, approval policies, accounting staff, branches, payroll operators and sometimes several subsidiaries. Its daily journey blends information and execution such as reviewing cash position, uploading a payment file, approving a payment, requesting a facility, reconciling an account, inviting a colleague, changing a limit, and downloading a statement. The user interface is visible, but the real product is the coordinated execution of those actions.

The right first principle is therefore simple.

Do not create a new bank inside the channel. Create a modern proposition around a defined system of financial record.

That principle has three consequences. The digital proposition needs its own vocabulary including organisation, user, account, approval, payment batch, beneficiary, role, cash position, facility, case and task. It must not expose the CBS screen model. At the same time, the core cannot become the default home for workflow, UI state, reusable integrations or every new business rule. Finally, the bank must define how an action becomes final. A payment can be drafted, submitted, awaiting approval, accepted, sent, settled, returned or failed. Those are states owned by different systems at different times. The channel can be simple only when the architecture keeps the underlying facts distinct and traceable.

This is why a digital overlay is more than a collection of APIs. It is an architecture for making change predictable.

Start with ownership, not integration.

A system ownership map is the essential first artefact. For every meaningful business object and action, it must answer four questions: which system is authoritative for the object or decision; which system may create or update it; which system publishes its lifecycle events; and which system presents the customer‑facing state. These answers must be explicit and agreed across teams. A shared database does not equate to shared ownership; a replicated copy is not a new source of truth; a channel cache is not an account statement. Any ambiguity in ownership will eventually manifest as an operational dispute.

In a typical overlay architecture, the existing CBS retains ownership of the financial book of record. This includes booked accounts, authoritative balances, posting rules, interest and fee logic where those remain in the core product, settlement instructions, core customer identifiers, and general‑ledger interfaces. A separate lending engine may own the servicing state of a loan, and a payments hub may own routing and scheme‑state detail. These allocations do not weaken the new proposition; they define its dependable foundation.

The modern platform, in turn, owns the elements that must evolve rapidly and span multiple systems. Its scope typically includes digital onboarding state, customer‑journey state, organisation memberships, user entitlements, workflow tasks, product catalogue overlays, limits and policy evaluation, channel‑specific presentation models, notification preferences, integration adapters, and a canonical event stream. The precise boundary varies by institution. The critical requirement is that the line is drawn once and enforced consistently across all development and operations teams.

Three common architectural patterns emerge in practice:

Core‑led overlay. The CBS retains ownership of accounts, balances, product parameters, and transaction processing. The new platform owns channels, orchestration, integration, and user experience. This is the safest route when the initial proposition closely aligns with existing products.
Co‑existing product domain. The new platform owns a bounded domain—for example, a wallet or a new business‑account product—while the core continues to own other books and the enterprise accounting interface. This approach demands an explicit ledger and reconciliation model; it is not merely a more modern API facade.
Progressive extraction. The institution starts with the overlay and gradually moves individual capabilities behind stable contracts. This is a long‑term strategy, not a sprint.

The pattern to avoid is a concealed hybrid, some balances calculated in the channel, some approval logic embedded in the mobile app, some payment state inferred from a batch file, and some customer records changed independently in multiple systems. Such an arrangement can appear expedient in the short term, but it inevitably fails at the first real operational incident.

An ownership map becomes useful only when it is translated into concrete contracts. For each core capability, the following must be specified: the command (what is being requested and what makes the request valid); the synchronous response (what can be safely confirmed at that moment); the asynchronous event (what is published when the action completes or changes state); the idempotency rule (how a retry is recognised as the same instruction); the error taxonomy (business rejection, technical failure, timeout, and unknown outcome); and the reconciliation key (the identifiers that allow two systems to prove they are describing the same entity).

A business payment illustrates the value of this discipline. The channel creates a draft; the orchestration layer validates permissions and policy; a payment service creates an immutable instruction and hands it to the core or payments hub. The immediate response may be “accepted for processing” rather than “settled.” Later events report approval, booking, scheme submission, settlement, or return. The customer sees a single consolidated timeline, while the architecture preserves every underlying fact and state transition behind it. This contract discipline is what prevents the digital platform from devolving into a fragile collection of screenshots and polling jobs.

Core Principles

Architectural Boundaries

Building a modern banking proposition requires establishing a controlled change boundary around the existing core rather than forcing all new capabilities through legacy customisation.

The True Product Definition

Business banking involves complex multi user workflows and operational tasks where the real product is the coordinated execution of actions rather than just a visible user interface.

System Ownership Map

Every meaningful business object and action must have explicit answers regarding authority, creation rights, event publishing, and customer facing presentation to prevent operational disputes.

Core Responsibilities

In an overlay architecture, the legacy core system retains ownership of the financial book of record, booked balances, posting rules, and core customer identifiers.

Digital Platform Domain

The modern digital layer takes ownership of fast moving capabilities including onboarding state, customer journeys, user entitlements, workflow tasks, and channel presentation models.

Core Led Overlay Pattern

The core led overlay model is the safest approach when launching a new proposition close to existing products because the core handles accounts and processing while the new platform manages experience and integration.

Coexisting Product Domains

When the new platform owns a specialized domain like a wallet or business account, the architecture requires an explicit ledger and reconciliation model rather than just a modern API facade.

The existing core is still an asset.

The existing core remains a substantial asset and should be treated as such. The regional landscape offers clear evidence of this premise. Temenos publicly documents ADCB Egypt's use of Temenos Core across retail, corporate, SME, and institutional segments, with payments capabilities integrated to the core and additional schemes planned under an orchestration layer. Vista Bank describes an integrated Temenos estate comprising core banking, analytics, payments, and digital solutions serving consumers and SMEs across African markets. Oracle positions FLEXCUBE for retail, corporate, SME, Islamic banking, and microfinance, while Access Bank's Oracle modernisation programme spans accounts, lending, payments, trade finance, corporate lending, and treasury at scale. These examples do not suggest that every institution should adopt the same vendor. They demonstrate that the systems already supporting business and SME banking are substantial financial platforms, not obstacles to be discarded by default.

The CTO's responsibility is to assess the particular core honestly, without beginning with an API brochure. The starting point is operating facts.

Four questions matter when evaluating the core's fitness for a digital overlay. First, can it make the financial state available at the cadence the proposition requires? Account balances, available balance, transaction history, holds, pending items, account status, and limits all require clear read semantics. A balance refreshed overnight is fundamentally a different product from a balance updated after real-time posting. The channel must know precisely which it is presenting to the customer.

Second, can it publish a reliable outcome? A successful synchronous call is insufficient if scheme processing, batch posting, or end-of-day controls can later alter the result. The integration requires either events, status queries, or controlled reconciliation feeds that definitively answer what happened to each instruction.

Third, can it distinguish identities and business roles? A consumer-centric core may only recognise a primary account holder. The wider platform must then own the organisation structure, delegated users, approval roles, and policy checks, while the core remains the financial account record. This division is acceptable provided the handoff is explicit and well-documented.

Fourth, can it support a controlled release process? An excellent technical interface still fails a product programme if every change requires a six-month core release cycle. The overlay should limit core changes to the smallest set of stable capabilities, allowing new channel and workflow versions to evolve independently.

The integration tier is where the old and new systems learn to work together. An existing core may expose APIs, SOAP services, files, database replication, or queues. The overlay absorbs these differences behind a stable integration tier that translates core-specific data into a canonical banking model, contains vendor-specific retries, protects the core from uncontrolled traffic, and publishes normalised events. If a country entity changes its CBS, the impact should be concentrated in the adapter, not spread through channels and workflows.

This is the technical justification for placing a genuine boundary around the core. It enables the institution to build on what it already possesses without inheriting every internal peculiarity indefinitely.

Middleware connects systems. Orchestration runs the proposition.

These terms are often used interchangeably. They should not be. Middleware is the connective tissue. It mediates protocols, transforms payloads, applies security controls, routes messages, manages retries and makes heterogeneous systems interoperable. An API gateway, enterprise service bus, message broker, adapter layer and event-streaming platform can all be part of middleware. It is responsible for dependable movement and translation.

Orchestration is the decision and execution layer for a business journey. It coordinates multiple systems, maintains workflow state, applies policy, creates tasks, waits for events, escalates exceptions and decides what should happen next. It is responsible for the controlled completion of work.

The difference is practical. When a business customer submits a payment file, middleware may receive the upload, validate the message format, secure the API call and send a request to a payments service. Orchestration decides whether the user is allowed to submit the file, whether the amount requires another approver, whether beneficiaries must be screened, whether a failed item should stop the entire batch, which operations team receives an exception and when the customer should be notified.

Treating orchestration as an integration flow creates brittle systems. Treating middleware as a workflow engine creates an untraceable tangle of routing logic. The best architectures separate the two but make them work together.

A reference shape for the middle layer

Channel-facing APIs and backend-for-frontends. These give web, mobile, staff and partner channels the responses they need without exposing raw core APIs.

Canonical domain services. These own reusable concepts such as organisations, users, payment instructions, beneficiaries, cases and notifications.

Core and third-party adapters. These contain legacy format conversion, controlled retries and vendor-specific quirks.

Workflow and policy services. These record long-running work, decisions and manual intervention; a workflow must survive a deploy, a timeout and a user returning a day later.

Event backbone and observability. Events carry change with correlation IDs, timestamps, producer version and a defined schema. Operational tools must answer what happened, who was affected and whether a retry is safe.

The diagram in this guide is intentionally simple. In implementation, each box might consist of several products or services. The important thing is not the product count. It is the direction of ownership: channels use the platform; the platform coordinates services; the integration tier protects and translates the core; the core remains responsible for its financial record.

Build a canonical model, but do not build an empire

A canonical model is valuable because it stops core terminology from leaking into every channel. It should represent stable banking concepts: party, organisation, account, account relationship, balance, transaction, instruction, beneficiary, payment, limit, role and entitlement. It should identify source system and version. It should not attempt to map every field from every legacy table on day one.

Keep the model narrow at first. Define it around the journeys you intend to ship. The goal is to create a stable language that lets a new product work across systems, not to complete an enterprise data programme before launch. When an unknown or obscure field is needed, add it with provenance rather than silently overloading an existing concept.

Event-driven does not mean eventually vague

Asynchronous processing is normal in banking. The mistake is to conceal uncertainty. A payment instruction can be accepted by an API, queued in a hub, booked in the core and rejected by a scheme later. The platform must represent this honestly.

Use immutable instruction IDs. Persist the command before sending it. Use an idempotency key to turn a retry into the same request rather than a duplicate payment. Publish state transitions, not only final outcomes. Have a defined process for a timeout where the channel does not know whether a downstream system accepted the request. Then reconcile. The customer experience can still be clear: we have received your payment; it is awaiting approval; it is being processed; it has completed; it needs attention. Clarity comes from a robust state model, not from pretending every call is synchronous.

The ledger question: know which book answers which question.

"Do we need a ledger?" is the wrong first question. Every institution already has ledgers. The question is whether the new proposition needs an independent transaction or sub-ledger, what it will own, and how it will reconcile to the existing accounting estate.

There are three different things casually called a ledger: the core account ledger, the operational record for accounts, postings, balance and product behaviour; a transaction or sub-ledger, the detailed double-entry record for a bounded domain such as a wallet or card authorisation; and the general ledger, the institution's accounting book for reporting and control. They answer different questions and must not be substituted for each other.

The key design decision is not whether a ledger is modern. It is whether the new platform is taking financial ownership. If it accepts value into its own wallet domain, keeps a balance that customers can spend, calculates fees independently or represents pending obligations before a core booking, it is taking on ledger responsibilities. That needs an explicit financial model.

When the existing CBS can remain the balance authority

For a first business-banking proposition, keeping the core as the balance authority is often right. The platform reads accounts and balances from the core, applies journey and approval logic, then reflects the official outcome once the core or payments hub confirms it. It may show a clearly derived projected balance, but must never label it as the authoritative book balance.

When a platform ledger is justified

A platform ledger becomes justified when the proposition needs to operate a discrete financial domain that cannot safely be represented as a transient workflow. Examples include a wallet with its own spendable balance, a multi-party marketplace allocation model, high-volume card authorisations and clearing, granular fee or commission accounting, virtual-account structures, or a lending product with its own servicing and schedule logic.

When you introduce one, apply bank-grade properties from the beginning:

journals are append-only; corrections are compensating entries, not edits;
each business event maps to balanced debit and credit postings;
posting rules are versioned and traceable to the product and policy that produced them;
pending, reserved, available and settled states are modelled separately;
every journal has source references, correlation IDs and timestamps;
balances can be recomputed from entries and checked against stored projections;
daily and intraday reconciliation to the CBS, payments hub and general ledger is designed before volume arrives;
manual adjustment is controlled, attributed and auditable.

Double-entry makes value movement explainable under stress. A team should trace an instruction through authorisation, journal, core and scheme references without relying on application logs as its primary evidence.

Reconciliation is a product capability

Reconciliation is a product capability, not a post-launch finance activity. Design three loops: platform instruction store to core or payments hub; sub-ledger to authoritative account and general ledger; and external scheme or settlement files to internal processing. Every accepted instruction needs a downstream reference or a defined exception.

This is where a generic digital banking platform either proves itself or becomes a presentation layer. The ledger model is how the proposition keeps its promises when real money and time discrepancies are involved.

Digital channels should be thin in code and rich in capability.

The mobile app is not the bank. The web portal is not the bank. They are delivery surfaces for a proposition that must behave consistently across customer self-service, assisted service, operations and partner integrations.

Channels should use shared backend capabilities while tailoring presentation to their users: a business owner needs cash overview and approvals; a finance officer needs files and reconciliation data; an operations user needs cases, evidence and controlled overrides.

Use a backend-for-frontend pattern

A backend-for-frontend (BFF) composes domain services for a specific channel, manages session context and prevents raw core APIs from reaching mobile or web clients. It is not a hiding place for reusable business logic: policy, payment state, entitlement evaluation and workflow decisions remain platform services.

Mobile should optimise for concise tasks, device security and notifications; web for information density, files and batch work; staff tools for evidence and controlled execution. The underlying facts must remain coherent.

Build business banking as a multi-user system

A business account must understand at least three layers of relationship:

the legal organisation and its account relationships;
the human users who may view, prepare, approve, administer or operate on its behalf;
the policies that govern which action each person may take, on which account, for what amount and at which stage.

This is an entitlement model, not a profile page with extra fields. It represents organisation, accounts, roles, permissions, limits, approval rules and delegations separately. A policy service evaluates actor, organisation, resource, action, amount, context and policy version; a workflow service records how that decision changed the work item state. Never encode the rules only in the channel.

Sign-on is identity. Approval is a separate decision.

SSO establishes a user session and can centralise authentication across web, mobile and staff applications. OpenID Connect is a practical standard for identity-layer authentication on top of OAuth 2.0; SCIM is useful for user and group provisioning. It still does not solve organisation-level access: authentication asks who the user is; authorisation asks what the user may do; approval asks whether the required sequence for a specific instruction is complete.

For customers, support enrolment, recovery, step-up authentication, devices and delegated access. For staff, integrate with the institution's identity provider. For partners, use separate client credentials, scopes and tenant isolation. Every sensitive action should retain authentication context, not only a user ID.

Design the digital state model before polishing screens

An excellent interface has exact language for imperfect states. If a transfer is being processed, say so. If a payment is waiting for another signatory, show who needs to act when policy permits. If an operation is under review, give the customer a case reference and a next step. If a balance includes or excludes a pending item, make that decision consistent and explainable.

This requires a shared state model across channels. It also makes the platform more resilient. A user can start an instruction in a browser, approve it on mobile and see the outcome in a staff-assisted conversation because the state lives in the platform, not in a screen session.

Payments expose every weak boundary. Design them first.

Payments are a useful architectural test because they bring together identity, entitlements, workflows, core integration, ledgering, external networks, notifications, observability and operations. If the design works for a business payment, it has likely created the right foundations for many other journeys.

Use a payment instruction as the central object. It should be immutable once accepted for processing, even if its lifecycle continues. A batch can contain several instructions. An instruction can have parties, accounts, amounts, currencies, dates, purpose, beneficiaries, fees, approvals, scheme references and a state history. A correction creates a new instruction or controlled change record, not an invisible edit to history.

A durable payment sequence

Draft and validate. The channel captures the payment data and validates what it can locally. The platform validates format, beneficiary data, account status and business rules against current information. No money has moved.
Authorise and submit. The platform checks the actor's entitlement and required authentication context. It records the instruction and returns an acknowledgement with a stable reference. For business payments, this may move the instruction into an approval workflow rather than downstream processing.
Approve and release. The workflow service evaluates the approval matrix. It records each decision and prevents prohibited combinations, such as a preparer approving their own payment where policy disallows it. Once complete, the orchestration layer releases the instruction to the appropriate downstream service.
Book, route and settle. The core, payments hub or dedicated payment service applies its financial and scheme logic. The platform consumes outcomes through events, queries or reconciliation files. It does not infer completion merely because an outbound request returned 200 OK.
Notify and investigate. The platform updates the customer-facing timeline, creates notifications and opens an operational case when an item requires intervention. The same instruction reference joins customer support, operational work and technical telemetry.

Engineering rules that prevent expensive incidents

Every boundary needs idempotency. A network retry must not create a second payment. Every command must have a correlation ID. Every synchronous timeout must have an unknown-outcome path rather than an automatic retry that assumes nothing happened. Every downstream event must be deduplicated. Every manual action must be traceable. Every visible state should be backed by a state transition that operations can inspect.

Queues need back-pressure, dead-letter handling, replay controls and monitored service-level objectives. The operational dashboard should show volume, queue depth, downstream latency, error rate, aged instructions, reconciliation breaks and approvals awaiting action. A team that can only observe a payment by searching logs does not yet have a production platform.

How to Build a Neobank on Top of an Existing Core Banking System