Core banking, cloud, outsourcing and technology regulation

A bank is a set of promises recorded in a ledger. If the ledger is wrong, unavailable or compromised, the bank cannot know what it owes, pay its customers or report to its supervisor. For this reason, regulators now examine technology architecture, outsourcing and cyber resilience as closely as capital plans.

What a core banking system does

The core banking system is the ledger of record. It holds customer and account data, posts every transaction, calculates interest and fees, and produces the balances on which everything else relies.

Typical functions include:

Function	What it covers
Customer and account management	Customer records, account opening, product terms, account status
Ledger and posting	Real-time or batch posting of debits and credits, general ledger feeds
Deposits	Current, savings and term accounts, interest accrual and capitalisation
Lending	Loan origination interfaces, schedules, repayments, arrears, provisioning feeds
Payments interfaces	Connections to payment hubs, card processors and correspondent accounts
Product configuration	Rates, fees, limits and rules without code changes
Data and reporting	Extracts for finance, risk, regulatory reporting and AML monitoring

Around the core sit other systems: digital channels, a payment hub, card management, customer onboarding and identity verification, sanctions screening, transaction monitoring, treasury, finance and the regulatory reporting engine.

Architecture choices

New banks usually choose between three models.

1. Licensed software, hosted by the bank or a provider. The bank controls configuration and data, but bears the integration burden.
2. Software as a service on a cloud platform. Faster to launch, but the bank depends on the vendor’s roadmap and resilience, and the arrangement is outsourcing.
3. Banking as a service from another licensed institution. The fastest route, but it can raise the question whether the new bank has enough substance of its own.

Supervisors do not prescribe a model. They assess whether the bank understands and controls the one it chose.

Outsourcing rules

Outsourcing means a service provider performs a process, service or activity that the bank would otherwise perform itself. In the EU, the EBA Guidelines on outsourcing arrangements (EBA/GL/2019/02) entered into force on 30 September 2019. They replaced earlier guidance, including the EBA’s separate recommendation on outsourcing to cloud service providers.

The central principle is that responsibility cannot be outsourced. The management body remains responsible for all outsourced functions. Institutions “should maintain at all times sufficient substance and not become ‘empty shells’ or ‘letter-box entities’”.

Critical or important functions

The guidelines apply stricter requirements where the outsourced function is critical or important, meaning a failure would materially impair compliance, financial performance or continuity. For such functions, the bank should:

1. Perform a risk assessment and due diligence on the provider before contracting.
2. Include contractual rights of access, information and audit for the bank and the competent authority.
3. Control sub-outsourcing, including notification and the right to object or terminate.
4. Set out data security, location and confidentiality requirements.
5. Have documented and tested exit strategies.
6. Inform the competent authority in advance of planned critical or important outsourcing.

All arrangements must be recorded in an outsourcing register maintained by the bank.

Outside the EU

Similar rules apply elsewhere. In the United Kingdom, PRA Supervisory Statement SS2/21 on outsourcing and third party risk management, published in March 2021 and effective from 31 March 2022, covers materiality, data security, cloud and exit planning. The PRA describes it as intended to facilitate “greater resilience and adoption of the cloud and other new technologies”.

In Singapore, the MAS Technology Risk Management Guidelines, published on 18 January 2021, set principles for technology risk governance, IT and cyber resilience, and are supplemented by a binding notice and incident reporting instructions.

DORA: digital operational resilience in the EU

The Digital Operational Resilience Act, Regulation (EU) 2022/2554, has applied since 17 January 2025. It brings ICT risk management, incident reporting, testing and third-party risk into one regulation for most EU financial entities, including banks.

DORA area	Core requirement for banks
ICT risk management	A documented framework approved and overseen by the management body, covering identification, protection, detection, response and recovery
Incident reporting	Major ICT-related incidents must be reported to the competent authority under Article 19, using harmonised classification and templates
Resilience testing	A testing programme for all entities; for entities identified by authorities, advanced threat-led penetration testing at least every three years on live production systems under Article 26
ICT third-party risk	A strategy on ICT third-party risk, contractual minimums, and a register of information on all ICT service contracts under Article 28
Oversight of critical providers	The European Supervisory Authorities designate critical ICT third-party service providers and oversee them directly under Article 31

Article 28 states that financial entities using ICT services “shall, at all times, remain fully responsible for compliance with, and the discharge of, all obligations” under DORA and financial services law. The register must distinguish services supporting critical or important functions. Entities must report annually on new arrangements and inform the authority in a timely manner about planned contracts for critical or important functions.

DORA applies alongside the EBA outsourcing guidelines. In practice, banks maintain one inventory that satisfies both.

Cybersecurity

Cyber risk is now part of prudential supervision. Supervisors expect a bank to know its information assets, protect them in proportion to their criticality, detect attacks quickly, and recover critical services within defined tolerances.

Key controls usually include:

1. Strong identity and access management, with multi-factor authentication and privileged access controls.
2. Secure software development and change management, including for vendor releases.
3. Encryption of data in transit and at rest, and key management that the bank controls.
4. Continuous monitoring and a security operations capability, in-house or outsourced.
5. Vulnerability management and regular penetration testing.
6. Backups that are isolated from the production environment and tested for restoration.
7. Incident response plans that cover regulatory notification and customer communication.

Fraud controls connect cyber and payments. Payee verification, behavioural analytics and strong customer authentication protect customers as payments become instant and irrevocable.

Regulatory reporting

Banks report large volumes of data to supervisors and central banks. In the EU, Article 430 of the CRR requires institutions to report on own funds requirements including the leverage ratio, large exposures, liquidity requirements, asset encumbrance and ESG exposures, among other items, and certain institutions must also report financial information. Central banks add statistical reporting, and financial intelligence units receive suspicious transaction reports.

Reports are only as good as the data behind them. The chain from core system to regulator usually runs:

1. Source data in the core system and other operational systems.
2. A data warehouse or reporting layer with reconciliation to the general ledger.
3. A regulatory reporting engine that maps data to supervisory templates and validation rules.
4. Review and sign-off by finance and risk, with documented controls.
5. Submission through the regulator’s portal or format.

Errors in reporting can lead to supervisory findings and, where they mislead the supervisor, enforcement. New banks often underestimate the work of mapping product data to reporting templates before launch.

What supervisors look for in a licence application

1. A clear target architecture, with each system, its owner, its provider and its location.
2. A critical or important functions map, showing which functions are outsourced and to whom.
3. Exit plans for each critical provider, realistic in time and cost.
4. Data location and access, including for the supervisor and resolution authority.
5. Tested resilience, with recovery times that match the business plan’s service promises.
6. Readiness evidence, such as end-to-end testing, migration rehearsal and operational acceptance.

The ECB’s guide to fintech bank licensing asks applicants to consider an exit plan for ceasing operations in an orderly and solvent manner, without harming consumers or requiring regulatory intervention. Technology choices determine whether such a plan is credible: data must be retrievable, accounts transferable and payments able to stop cleanly.

The next article explains the payment rails that the core system connects to: card schemes, SEPA, instant payments and real-time gross settlement.