Core Banking App Development

Core banking systems are the operational backbone of every retail and commercial bank: the real-time ledger engines that process deposits, withdrawals, loans, and account management across every channel. When a customer checks their balance at 2am, initiates a SEPA transfer, or draws on a revolving credit facility, the core banking system is what makes it happen without fail.

For engineering leaders at financial institutions, the decision isn't whether to modernise core banking software development: it's how to do it without disrupting live operations. Legacy monolithic CBS platforms carry decades of undocumented business logic, making rip-and-replace a multi-year risk. The teams that succeed decompose incrementally: extracting discrete domains (payments, savings, lending) behind well-defined APIs while the mainframe continues to process transactions.

Scrums.com provides dedicated engineering squads to financial institutions and FinTech companies building or modernising core banking platforms. Our teams have delivered CBS components across the UK, EU, and Sub-Saharan Africa, working within Basel III capital requirements, PSD2/Open Banking mandates, and central bank regulatory frameworks.

Core Banking Platform Architecture

Modern core banking architecture has moved decisively away from single-vendor monoliths toward composable, API-first designs. The key architectural domains your engineering team needs to resolve before writing a line of code:

Account and Ledger Engine

The double-entry ledger is the technical heart of any CBS. Every debit must have a corresponding credit; every posting must be atomic, consistent, isolated, and durable (ACID). At scale this means careful partitioning strategies (typically by account number range) so that high-volume retail current accounts don't starve commercial lending workflows.

Transaction Processing Pipeline

Real-time gross settlement (RTGS) and deferred net settlement (DNS) have different throughput and latency profiles. A high-street retail bank processing 50,000 transactions per second at peak requires a different pipeline architecture than a commercial bank clearing 500 large-value CHAPS/Fedwire payments per day. Your queue topology (Kafka, IBM MQ, ActiveMQ), idempotency handling, and reconciliation logic all flow from this choice.

Channel Integration Layer

Branches, ATMs, internet banking, mobile, and third-party FinTech apps all consume core banking services through an integration layer. ISO 8583 remains dominant for card and ATM channels; ISO 20022 is the emerging standard for payment messaging and is now mandated for SWIFT cross-border and UK CHAPS. Designing your CBS to speak both natively, rather than relying on translation middleware, reduces latency and failure surface area.

Regulatory and Compliance Engine

AML transaction monitoring, sanctions screening (OFAC, HMT, EU consolidated list), KYC/CDD record management, and suspicious activity reporting all need to be embedded in the transaction pipeline, not bolted on afterwards. Late-binding compliance is the single most common cause of core banking project overruns.

Why Financial Institutions Work With Scrums.com

Core banking programmes fail most often not because of poor technology choices, but because of team structure. A vendor delivering a fixed-scope CBS implementation has no incentive to flag scope risk early. An internal team building greenfield on a timeline set by a board presentation is under pressure to cut corners on the compliance layer.

Scrums.com operates on a dedicated team model: a permanent engineering squad embedded in your organisation, aligned to your roadmap, and accountable to your engineering leadership. No time-and-materials billing incentives, no project managers creating overhead between your team and ours.

Our CBS teams carry domain knowledge in banking regulation and payment scheme certification that takes years to build. We've delivered core banking components for regulated institutions under PRA, FCA, FSCA, and Central Bank of Kenya oversight. Explore how we work on the dedicated engineering team page, or read about our mobile app development and FinTech delivery track record via the FinTech software solutions page.

Core Banking Platform Types We Build

Different institution types have fundamentally different CBS requirements. Scrums.com engineering teams have delivered across five platform categories:

Retail Core Banking

High-volume, low-value transactional systems for current accounts, savings, and personal loans. Optimised for throughput, mobile-first channel delivery, and open banking API compliance (PSD2, CDR, Open Banking UK). Key integrations: payment scheme rails (Faster Payments, SEPA, ACH), credit bureau APIs, and card management systems.

Commercial and Corporate Banking

Multi-currency account management, trade finance, syndicated lending, and treasury management. Lower transaction volume but significantly more complex data models: facility structures, covenant monitoring, drawdown waterfall logic. Regulatory overlay includes BCBS 239 risk data aggregation and FRTB for banks with trading books.

Digital Challenger Bank

Greenfield builds for neobanks and embedded finance providers. Event-driven microservices architectures deployed on AWS or GCP, with Kafka-based event sourcing for the ledger. BaaS (Banking-as-a-Service) API layers for downstream FinTech clients. Typically UK FCA authorised or operating under an e-money licence.

Credit Union and Community Bank

Member-owned institutions need CBS platforms that handle share accounts, member loans, and dividend/interest allocation; terminology and data models that differ from commercial banking. Integration with CUSO technology partners and compliance with NCUA or PRA prudential requirements.

Central Bank and Development Finance

National payment system infrastructure, central securities depositories, and development bank platforms. ISO 20022 native messaging, real-time gross settlement engines, and sovereign-grade security architecture. Scrums.com has delivered CBS components for regulated financial institutions across Sub-Saharan Africa. See our national payments compliance platform case study.

Technology Stack for Core Banking Development

Core banking software development demands technology choices that prioritise correctness and durability over development velocity. The stacks our teams deploy:

Backend and Ledger

Java (Spring Boot) and Kotlin are the dominant choices for CBS backends: both offer strong type systems, mature ACID-compliant database drivers, and deep ecosystems of financial libraries. For high-frequency transaction processing, C++ remains relevant in settlement engines where microsecond latency matters. Event sourcing frameworks (Axon, Eventuate) provide immutable audit trails essential for regulatory examination.

Databases

PostgreSQL is the default for OLTP workloads: MVCC concurrency control, row-level locking, and mature partitioning make it well-suited to ledger tables. Oracle remains common in established institutions for its RAC clustering and long-standing regulatory acceptance. TimescaleDB or ClickHouse handle time-series analytical workloads (balance history, transaction analytics) without burdening the OLTP primary.

Messaging and Integration

Apache Kafka underpins event-driven CBS architectures: topics map naturally to banking domains (payments, accounts, lending). IBM MQ and RabbitMQ are common in hybrid environments integrating with legacy mainframe components. ISO 20022 message parsing libraries (prowide-core for Java, SWIFT SDK) handle payment scheme message formatting.

Cloud and Infrastructure

AWS (with FSx for ONTAP for shared storage) and Microsoft Azure (with Azure confidential computing for data sovereignty) are the dominant cloud platforms for regulated banking workloads. Multi-region active-active deployments with synchronous replication between availability zones achieve the 99.999% uptime targets most central banks and regulators mandate. See how Scrums.com stabilised a FinTech platform with similar infrastructure requirements.

Integration and Compliance Considerations

Payment Scheme Connectivity

Direct scheme participation (Faster Payments, CHAPS, SEPA CT/DD, ACH, SWIFT gpi) or indirect access through an agency bank each carry different technical and commercial implications. Direct participants need certified payment gateway software meeting scheme technical standards: our team has built and certified payment interfaces against Vocalink (UK), EBA Clearing (EU), and SWIFT specifications. Read more in our guide to compliant payment software delivery.

Regulatory Reporting

COREP/FINREP (EBA), DFAST stress testing (US), and XBRL regulatory submissions require your CBS data model to support regulatory dimensions from day one. Retrofitting regulatory reporting into a CBS that wasn't designed for it is expensive: dimensional data models and a separate regulatory reporting data store (separate from OLTP) are standard practice.

Legacy Core Migration

Most core banking modernisation programmes involve a strangler fig pattern: new microservices gradually absorb functionality from a legacy Temenos T24, FIS Profile, or Finacle system. The parallel run phase, where both old and new ledgers process the same transactions and results are reconciled, is the highest-risk period. Our legacy modernisation approach covers the architectural patterns that reduce this risk.

Open Banking APIs

PSD2 Strong Customer Authentication (SCA), consent management, and AIS/PIS APIs require specific CBS integration points. Your core needs to expose account information and payment initiation in real time; batch overnight processing won't satisfy PSD2 regulatory technical standards. We also build the dedicated interfaces your CBS needs to connect with FinTech ecosystem partners.

Frequently Asked Questions

How long does core banking app development take?

A greenfield digital bank CBS (current accounts, payments, basic lending) typically takes 12 to 18 months with a dedicated squad. Legacy modernisation programmes run longer: 18 to 36 months depending on the scope of strangler fig extraction. Scrums.com dedicated teams can mobilise within 21 days, which materially accelerates the early architecture and domain modelling phases where delay is most expensive.

What's the difference between a core banking system and a payment gateway?

A core banking system manages the account ledger, customer records, and product catalogue (deposits, loans, cards). A payment gateway handles authorisation and routing of individual payment instructions to scheme rails. In a modern architecture they are separate bounded contexts: the CBS exposes a payment API that the gateway consumes. Both need to be designed together to avoid the impedance mismatches that cause settlement breaks.

How do you handle data migration from a legacy CBS?

Data migration from legacy systems (Temenos T24, FIS, Finastra Fusion) follows a three-phase approach: extraction and cleansing (fixing data quality issues that accumulated over decades), parallel ledger reconciliation (running old and new systems simultaneously and reconciling to the penny each night), and cutover (a weekend freeze with automated validation gates before go-live). The reconciliation phase typically surfaces 5 to 15% more remediation work than initial estimates; factoring this into your timeline is critical.

Which regulatory frameworks does your team have experience with?

Our engineering teams have worked within UK PRA/FCA requirements, EU CRD IV/Basel III, South African FSCA regulations, and Central Bank of Kenya frameworks. On the payment side: PCI-DSS for card data environments, PSD2 SCA for open banking, and SWIFT CSCF for correspondent banking connectivity. Compliance requirements are baked into our engineering process, not treated as a post-build audit.

Can you integrate with our existing card management system or lending platform?

Yes. CBS integration with third-party card management systems (Marqeta, Galileo, GPS), lending origination platforms, and treasury management systems is standard in our delivery model. We design integration contracts using ISO 20022 message schemas where scheme-compliant, and REST/AsyncAPI specifications for internal domain boundaries. Explore our dedicated engineering team model for how we staff and govern these integrations.