Selecting a core banking system involves more than evaluating technical features. For payment institutions and e-money institutions operating under PSD2, GDPR, and AML directives, the system’s ability to support banking system regulatory compliance across multiple dimensions is a primary selection criterion. A system that cannot generate accurate regulatory reports, enforce data protection controls, or adapt to evolving requirements will create ongoing compliance risk regardless of its operational capabilities. The key compliance-related considerations when evaluating a core banking system are set out below.
As illustrated in a typical compliance workflow within a core banking system, a customer onboarding event triggers KYC verification and the assignment of an initial customer risk score. Ongoing transactions are monitored against the customer’s risk profile and defined AML rules, with alerts generated for transactions that exceed risk thresholds. Regulatory reports are generated from the general ledger on a scheduled basis, drawing on structured transaction data classified according to the chart of accounts. All actions, alerts, and report submissions are captured in an audit trail that is available for internal review and regulatory inspection. Each of these functions depends on the underlying system architecture supporting them natively, rather than through manual processes or disconnected third-party tools.
Key Takeaways: #
- A core banking system selected for banking system regulatory compliance must support KYC and KYB workflows, customer risk profiling, transaction risk scoring, transaction monitoring, consisting of sanction, PEP, adverse media screening, transaction monitoring rules, and behavioural analysis, and data security controls as integrated capabilities rather than add-on modules;
- For payment institutions and e-money institutions specifically, the system must support safeguarding reporting, client fund segregation, own funds calculations, and the reporting formats required by the relevant national competent authority;
- The system provider’s regulatory expertise and commitment to ongoing updates is as important as the system’s current feature set, given the pace of change in EU and UK payment regulation.
Key Banking System Regulatory Compliance Considerations #
- Regulatory reporting capability: The core banking system must be capable of generating accurate, timely regulatory reports in the formats required by the relevant supervisory authority. For institutions licensed in Europe, this includes the periodic reports required covering own funds, safeguarded client funds, payment transaction volumes, and operational data. For UK-licensed institutions, equivalent returns are required under the Payment Services Regulations 2017 and the Electronic Money Regulations 2011, submitted to the FCA. The system should support configurable reporting templates that can be adapted when reporting formats or data requirements change, without requiring structural changes to the underlying system.
- Safeguarding and client fund segregation: Payment institutions and e-money institutions are required to safeguard customer funds held against outstanding payment obligations or e-money liabilities. The core banking system must support the accurate tracking, recording, and segregation of client funds from the institution’s own funds within the general ledger. It must also generate the safeguarding reports that regulators require to verify compliance with these obligations. A system without native accounting functionality and a chart of accounts configured for this purpose cannot reliably support safeguarding compliance.
- AML and KYC workflows: The system must support end-to-end AML and KYC processes, including customer risk scoring at onboarding, ongoing monitoring of customer risk profiles, transaction risk scoring, transaction monitoring against defined rules and thresholds. These functions are most reliable when integrated within the core banking system and drawing on real-time transaction data, rather than dependent on a disconnected third-party AML tool. The system should also support enhanced due diligence (EDD) workflows for higher-risk customers, including politically exposed persons (PEPs) and customers from high-risk jurisdictions.
- Data security and GDPR compliance: The system must implement robust data security controls, including encryption of data at rest and in transit, role-based access controls, multi-factor authentication for system access, and comprehensive audit logging of all user actions. Compliance with GDPR requires that personal data processed within the system is handled in accordance with defined retention schedules, subject access request procedures, and data minimisation principles. The system provider should be able to demonstrate that their infrastructure and data processing arrangements meet GDPR requirements, including clarity on data residency and sub-processor arrangements.
- Audit trail and compliance oversight: The system must maintain a complete, tamper-resistant audit trail of all transactions, system events, user actions, and compliance-related activities. This audit trail must be available for internal audit review, regulatory examination, and financial crime investigations. In addition to historical logging, the system should provide real-time alerting for defined compliance events, enabling compliance teams to identify and respond to potential issues as they arise rather than during periodic reviews.
- Integration with regulatory and external systems: The core banking system should support integration with regulatory reporting platforms, tax authority systems, and third-party compliance tools where required. For the best banking system regulatory compliance, the system must provide or integrate with a PSD2-compliant API interface that meets the EBA RTS requirements for TPP access, SCA, and secure communication. Seamless integration reduces the need for manual data transfers between systems, lowers the risk of reporting errors arising from data inconsistencies, and enables a more efficient compliance operation overall.
- Adaptability to regulatory change: Payment regulation in the EU and UK is subject to ongoing development. The forthcoming PSD3 and Payment Services Regulation (PSR) in the EU, the UK’s retail payments strategy, and evolving EBA guidelines on topics including AML, outsourcing, and operational resilience all have implications for the compliance requirements placed on payment institutions and e-money institutions. The core banking system must be capable of adapting to changes in reporting formats, data fields, compliance rules, and API standards without requiring full system replacement. The provider’s track record in delivering regulatory updates and their engagement with upcoming regulatory developments should be assessed as part of the selection process.
- Provider regulatory expertise and ongoing support: The banking system regulatory compliance capability of a core banking software is only as reliable as the provider’s understanding of the regulatory environment in which it operates. The provider should demonstrate active knowledge of the regulatory frameworks applicable to payment institutions and e-money institutions in the relevant jurisdictions, a documented process for monitoring and implementing regulatory changes, and a commitment to updating the system in response to new requirements. Institutions should evaluate not only the system’s current compliance features but also the provider’s roadmap for maintaining compliance as regulation evolves.
- Documentation and version control: The system should provide comprehensive documentation of its compliance-related functionality, including user guides, compliance configuration materials, and records of regulatory updates applied to the system. Documentation management features, including version control and access controls, ensure that compliance teams have accurate, up-to-date reference materials and that changes to compliance configurations are tracked and auditable.
FAQ: #
What is the difference between AML transaction monitoring and customer risk scoring in a core banking system?
- Customer risk scoring assigns a standing risk rating to each customer based on their type, location, business activities/occupation, and source of funds, and is reviewed periodically or when new information is received. AML transaction monitoring is the real-time or near-real-time surveillance of individual transactions against sanctions, PEP, adverse media, defined rules and thresholds to detect potentially suspicious activity. The two functions are interdependent: customer risk scores typically inform the rules and thresholds applied within the transaction risk scoring and monitoring system. Both are most effective when integrated within the same core banking infrastructure, sharing real-time data without the latency or data gaps introduced by disconnected systems.
What regulatory changes should payment institutions and e-money institutions anticipate when selecting a core banking system?
- Institutions selecting a core banking system in 2026 and beyond should consider the implications of PSD3 and the EU Payment Services Regulation (PSR), which are expected to replace PSD2 and introduce updated requirements for open banking, SCA, and payment institution licensing. In the UK, the Payment Systems Regulator’s work on variable recurring payments (VRP) and the FCA’s ongoing review of the Payment Services Regulations are likely to result in updated compliance obligations. Institutions should assess whether their chosen system provider has a clear plan for implementing these changes and a track record of delivering regulatory updates in a timely manner.
