
In the modern world of financial technology, the cloud-based banking system security measures has become a paramount concern. Developers tasked with creating these sophisticated systems implement a myriad of strategies to safeguard against potential threats. It is a delicate process that requires a robust and multifaceted approach, much like a chess game, where every move is calculated and decisive. Below we will explore several of the key security measures typically undertaken by developers to address and counteract security concerns within the realm of cloud-based banking. These strategies range from encryption to access control, disaster recovery to routine audits, and more, all underpinning the resilience and reliability of cloud-based banking system security.
Security in cloud-based core banking systems must address a broad and evolving threat landscape, spanning external cyber attacks, insider threats, infrastructure failures, and regulatory compliance gaps. Developers building these systems implement a layered security architecture in which multiple independent controls protect different aspects of the system, so that the compromise or failure of any single control does not result in a complete security breach.
This defence-in-depth approach is the standard model for financial services ICT security and is reflected in the security requirements of DORA, GDPR, and PCI DSS, all of which apply to payment institutions and e-money institutions operating cloud-based core banking systems.
As illustrated in a typical cloud-based core banking security architecture, a user authentication event triggers multi-factor authentication before access is granted. All data transmitted between the user and the system is encrypted using TLS. Once authenticated, the user’s access is limited to the functions and data permitted by their role-based access control profile. All user actions are logged to a centralised security information and event management (SIEM) system, which monitors for anomalous behaviour in real time.
The underlying infrastructure is protected by firewalls, network segmentation, and intrusion detection systems. Regular vulnerability scans and penetration tests identify weaknesses before they can be exploited. Automated backup and failover mechanisms ensure that the system can recover from infrastructure failures or cyber incidents within defined recovery time objectives.
Key Takeaways: #
- Cloud-based core banking systems must implement a layered security architecture covering data encryption, access control, network security, vulnerability management, security monitoring, and disaster recovery, each addressing a distinct category of security risk;
- For payment institutions and e-money institutions, security measures in the core banking system must satisfy the requirements of multiple overlapping regulatory frameworks simultaneously, including GDPR for data protection, PCI DSS for cardholder data security, and DORA for ICT operational resilience;
- DORA requires financial institutions to conduct regular resilience testing of their ICT systems, including vulnerability assessments and, for significant entities, Threat-Led Penetration Testing (TLPT) at least every three years. Security audits and penetration testing are therefore both a security best practice and a regulatory obligation.
Core Security Measures in Cloud-Based Core Banking Systems #
Data encryption: All data within a cloud-based core banking system must be encrypted both at rest and in transit. Encryption at rest protects data stored in databases, file systems, and backup media from unauthorised access in the event of physical or logical access to the underlying storage. Encryption in transit protects data transmitted between users, application components, and external systems from interception or modification during transmission. The specific encryption standards applied must meet the requirements of the applicable regulatory frameworks.
GDPR requires appropriate technical measures to protect personal data, PCI DSS specifies minimum encryption standards for cardholder data, and the EBA RTS on SCA and secure communication defines encryption requirements for open banking API connections. Transport Layer Security (TLS) 1.2 or higher is the standard protocol for encrypting data in transit in financial services systems.
Access control and multi-factor authentication: Role-based access control (RBAC) restricts each user’s access to the system functions and data required for their specific role, preventing both accidental and intentional access to sensitive functions or data outside a user’s authorised scope. RBAC must be configured and maintained carefully, with access rights reviewed regularly to ensure they remain appropriate as roles and responsibilities change.
Multi-factor authentication (MFA) is required for all access to the core banking system, combining at least two independent authentication factors to verify user identity before access is granted. Under DORA, MFA for access to systems supporting critical or important functions is an expected baseline security control, and its absence would represent a significant ICT risk management gap.
Network security: Network security controls form the perimeter layer of the cloud-based core banking security architecture. Firewalls enforce rules governing which network traffic is permitted to reach the core banking system, blocking traffic from unauthorised sources. Intrusion detection and prevention systems (IDPS) monitor network traffic for patterns associated with known attack types and can block or alert on suspicious activity in real time. Network segmentation divides the core banking infrastructure into isolated segments, limiting the ability of an attacker who gains access to one segment to move laterally to other parts of the system. Virtual private networks (VPNs) or equivalent secure tunnelling technologies protect administrative access to the system infrastructure. Secure network protocols ensure that all connections between system components and external services use encrypted, authenticated channels.
Vulnerability management and patch management: Identifying and remediating security vulnerabilities in the system’s software components is an ongoing operational requirement. Developers maintain an inventory of all software components, monitor vulnerability disclosure databases for newly identified issues, and apply security patches within timeframes defined by the severity of the vulnerability.
Under DORA, financial institutions must implement a systematic ICT vulnerability management process and must be able to demonstrate to their national competent authority that vulnerabilities are identified and remediated in a timely manner. For cloud-based core banking systems built on microservices and container architectures, vulnerability management must cover the application code, container images, base operating system layers, and all open-source dependencies, maintained through a documented software bill of materials (SBOM).
Security monitoring and logging: Comprehensive security monitoring requires the collection, centralisation, and analysis of security-relevant events from across the core banking system, including authentication events, access control decisions, transaction processing events, API calls, and infrastructure health metrics. Security information and event management (SIEM) platforms aggregate these events and apply correlation rules to identify patterns that may indicate a security incident, enabling rapid detection and response.
Under DORA, financial institutions are required to implement monitoring capabilities that enable them to detect ICT-related incidents promptly and to classify major incidents in accordance with the criteria defined in the EBA regulatory technical standards. The audit log generated by the monitoring system also supports regulatory examinations, forensic investigations, and internal governance reviews.
Disaster recovery and business continuity: Cloud-based core banking systems must implement disaster recovery and business continuity capabilities that ensure the system can recover from infrastructure failures, cyber incidents, or other disruptive events within defined recovery time and recovery point objectives.
Core recovery mechanisms include automated data backup with defined retention periods and tested restore procedures, redundant infrastructure across multiple availability zones or data centres, automated failover that redirects traffic to standby infrastructure when a primary component fails, and documented incident response procedures that define the roles and actions required to manage and recover from different incident scenarios. Under DORA, financial institutions must define and document recovery time objectives and recovery point objectives for their critical ICT systems, test their recovery capabilities regularly, and be able to demonstrate resilience to their national competent authority.
Security audits and penetration testing: Regular security audits assess whether the security controls implemented in the core banking system are operating effectively and in accordance with the applicable security policies and regulatory requirements. Penetration testing involves simulating attack scenarios against the system to identify exploitable vulnerabilities that may not be detected by automated scanning.
Under DORA, all financial entities must conduct regular digital operational resilience testing, including vulnerability assessments and scenario-based testing. Significant financial entities are additionally required to conduct Threat-Led Penetration Testing (TLPT) at least every three years, following the TIBER-EU framework or an equivalent national framework. For payment institutions and e-money institutions, the scope and frequency of security testing should be calibrated to the institution’s risk profile and the criticality of the systems tested.
FAQ: #
What is the difference between a security audit and a penetration test?
- A security audit is a structured review of the security controls, policies, and procedures implemented within a system, assessing whether they are correctly configured, consistently applied, and aligned with the applicable regulatory requirements and security standards. It is typically conducted by reviewing documentation, interviewing staff, and inspecting system configurations. A penetration test is a simulated attack against the system, conducted by qualified security professionals, with the objective of identifying exploitable vulnerabilities that an actual attacker could use to gain unauthorised access or cause harm.
- Security audits assess whether controls are in place; penetration tests assess whether those controls are effective against a real attack. Both are required under DORA, with penetration testing for significant financial entities required to follow the structured TLPT methodology defined in the TIBER-EU framework.
How does DORA affect the security requirements for cloud-based core banking systems?
- DORA establishes binding ICT risk management requirements for financial institutions, including payment institutions and e-money institutions, that directly affect how cloud-based core banking systems must be designed, operated, and tested. Key DORA requirements relevant to core banking security include the implementation of a comprehensive ICT risk management framework covering identification, protection, detection, response, and recovery functions; systematic vulnerability management with documented remediation timelines; regular resilience testing including TLPT for significant entities; ICT incident detection and mandatory reporting of major incidents to the national competent authority within defined timeframes.
- Contractual ICT third-party risk management requirements for cloud infrastructure and SaaS providers. Financial institutions must be able to demonstrate compliance with these requirements to their national competent authority through documented policies, procedures, and testing records.
In conclusion, these measures illustrate the depth of security considerations in cloud-based banking system development. It’s worth noting that specific security requirements may vary depending on the unique context, regulatory compliance, and risk tolerance of each financial institution. Thus, developers need to tailor their security measures to meet these specific needs, ensuring robust and reliable cloud-based banking system security. Read more on how Baseella created secure cloud-based banking system.