Thee level of regulatory compliance facing the financial services sector has increased significantly in recent years, culminating in an environment of multiple complex regulations such as the Dodd-Frank reform, FATCA, KYC, FRTB, IFRS 9, IFRS 17, IRRBB, SACCR, Basel III final reforms, and a new risk-based approach to AML and data privacy regulations, to name a few. In addition to becoming more frequent, compliance requirements are becoming more complicated, as is the implementation thereof, due to the inter-dependence between disparate regulations and their shared data and process requirements. Reporting is further complicated by the need to align and reconcile the reported compliance numbers to finance, as well as across all presented reports. The consequence of more regular and intricate regulation is higher costs, as financial institutions respond to the compliance requirements through investments in technology and additional staff. According to GlobalSCAPE’s 2017 Ponemon report, the cost of compliance for financial services companies almost doubled between 2011 and 2017. The same report also shows that the cost of compliance is significantly less than non-compliance, with the cost of non-compliance being 171% more than the cost of compliance for 2017.[1]
In South Africa, the compliance reporting burden is no less onerous. Financial services organisations face stringent compliance reporting requirements from the country’s regulators, including the Banks Act returns, Conduct of Business Report, Conduct of Business Return, SACRRA, NCR Form 39, FATCA and the NPS 100 return, amongst others. With financial services organisations facing the certainty of more regulatory compliance requirements in the future, with increased levels of complexity, they are encouraged to seek out more efficient solutions to manage their compliance challenges. A good place to start would be for organisations to reevaluate their compliance reporting obligations through the lens of identifying additional digitisation and automation opportunities and, in so doing, relieve resources of mundane, repetitive tasks and create capacity to allow for greater analysis and insights-gathering within teams.
Compliance reporting involves the processing of significant amounts of data, achieved either through manual or automated systems. As with all aspects of life, the decision to use manual versus automated operations to achieve reporting requirements, depends on timing. Small organisations, with notably smaller amounts of data and reporting requirements are more likely to opt for manual reporting methods, as these offer them the benefits of lower costs, higher levels of flexibility and increased oversight, whilst still limiting their risk of non-compliance. Nevertheless, a high level of manual intervention makes an organisation’s reporting processes prone to human error and introduces key-man dependencies. As organisations increase in size, so too do they experience an increase in the number of disparate data sources, higher data volumes and increased touch points between people and processes. Consequently, the larger an organisation becomes, the greater and more evident the need becomes to transition to an automated reporting process, as the risk-reward trade-off of using a manual system becomes unsustainable. A transition is often necessitated by the increased experience of negative elements of annual reporting, such as data entry errors, reduction in information sharing, poor security and data and process duplication.
A successful transition from manual to automated approaches will present an array of benefits for an organisation:
Reduced Risk – Manual reporting requires human intervention, which often leads to errors and increases the risk of incorrect reporting, non-compliance and insider leaks. Automation can substantially lower – or even eliminate – the risk of human error in the production of compliance reports. In addition, automation improves efficiency by enabling valuable resources to shift their focus away from report-production, to the task of results-analysis and the reconciliation and control of processes.
Cost Reduction and Increased Capacity – Automation can result in meaningful cost savings and increased resource capacity since resources are no longer required to spend hours consolidating data from various sources and creating rules to generate manual reports. With automation in place, an organisation‘s employees can perform more effective analysis and derive meaningful insights from an organisation’s data.
Enhanced Scalability – Once an effective and efficient automated process is established, it characteristically eases scalability to deal with increased data volumes.
Improved Efficiency – Automation enables efficiency through quicker data collection and consolidation and subsequently allows for more frequent reporting, e.g. monthly reporting can become daily reporting, as well as smoother reruns in the event of upstream data errors. Additionally, improved efficiency and increased frequency can enable an organisation to leverage the reporting process for scenario analysis purposes.
Increased Audit Preparedness – Automation ensures the availability of audit trails to identify and trace all changes that were made to the data, thus reducing the time and costs of both internal and external audits.
Enhanced Regulatory Compliance – With reduced levels of manual intervention and adjustment of data, automation ensures that organisations are better positioned to meet their compliance reporting needs, such as timeliness, accuracy, integrity and quality.
Reduced Key-Man Dependencies – Automation assists by reducing the level of key-man dependency, by using individuals’ subject matter expertise and institutional business knowledge to develop a robust solution.
Competitive Advantage – Automation can offer organisations a competitive advantage by achieving the above-listed benefits and by freeing up employees. Through the latter, organisations can enhance employee utilisation, moving resources on to strategic initiatives that can advance the organisation.
Compliance reporting is designed to provide regulators and other stakeholders with insights into the financial health and soundness of an organisation e.g. profitability, solvency, liquidity, operating efficiency, data management and other market demographics, including products, customers, business structure and governance. Based on the measurement of specific metrics that are informed by calculated indicators, compliance reporting enables regulators to conduct the business of supervision and develop pragmatic public policies required for financial risk management. Other stakeholders tend to also leverage reported content to make business or investment decisions. Those who are responsible for the reporting are, however, faced with a great deal of complexity and effort in producing the regulatory required results on a regular and accurate basis. This is further complicated when considering the unique data and process nuances of individual organisations.
It is one thing to read and understand the regulations, but the challenges lie in translating these into actionable steps to build an automated capability within the business. One of the most significant of these challenges is to effectively relay the business requirements to an organisation’s IT teams. Ultimately, IT will be the key role players in any automation project and are responsible for the physical implementation thereof. It is therefore important to be able to translate the regulations into business requirements and the business requirements into logical data concepts and data requirement specifications for the responsible IT enablement teams.
To overcome these challenges, a robust approach and well-designed plan are required to meet the obligations of implementing an automated compliance reporting solution. To ensure success, organisations require a clearly defined plan and operating model to govern the interaction between business and IT. To this end, Monocle advocates the use of a multi-stage methodology that incorporates a data derivation approach.
Comprehensively defined business requirements;
Integrity and completeness of considered information;
Rapid escalation and agreement of solution design decisions, given the upfront ownership identification; and
An effective project roadmap to guide the automation implementation.
a. Define project objectives, approach and governance
b. Identify business ownership
c. Agree on engagement model
d. Agree on project timelines
The scoping stage is critical as it provides a level of understanding, as well as the rules of engagement for all the parties involved e.g. business as the requirements owners, business analysts and IT as the implementation partners. It also provides a boundary within which to deliver a project. A clearly scoped project supports a project team by helping it to understand what to deliver (i.e. functional, operational, technical and transitional requirements) and enabling the team to make rapid decisions during the life of the project. Identification of business owners is critical for sign-offs and interpretation approval. This stage also allows for the development of a project governance framework by identifying the project sponsor and other key stakeholders who need to ensure alignment between the project goals and the organisation’s strategic objectives. Agreeing on an engagement model is another important consideration during the scoping stage as it shapes the relationship with key internal and external stakeholders, identifying who is responsible for each component of the project i.e. delivery, testing and approval. The scoping stage further provides a reference point against which the progress and success of the project can be measured considering the projected timelines, budgets, milestones and deliverables.
a. Source latest regulations and report/return templates
b. Identify and define relevant regulatory components
c. Convert report/return elements into interpretable data concepts and derivation rules using a Data-Derivation Approach
d. Document the analysis, interpretation results and business requirements garnered during this exercise
A successful implementation will see the IT teams receive detailed specifications from the business analysts. These specifications are to be reflective of the regulations, business requirements, the required data, as well as the business rules that need to be catered for in the automated solution. The specifications need to outline all the steps, transformations and calculations that need to take place from the data source to the reported data element. A reporting element Data-Derivation Approach The aim of a data-derivation approach is to segment the data lineage – between the final report/return result and the primary data source – into derivation levels to capture the steps and inputs required at each point in its transformation. The methodology is illustrated in Figure 1 below, which shows that data can be transformed in various ways at each derivation point. These derivations are may constitute a single cell on a form, but it represents an intricate web of steps, sources and process interactions, which becomes evident when broken into its principal components. It is important to consider how the regulations and associated reporting requirements apply to organisations given the specifics of each business i.e. certain sections of a regulation may not be in scope due to an organisation’s product offering. The development of an automated compliance reporting solution cannot commence until the project team has clearly established the regulatory components and report/return elements that are relevant to the client. To do so, subject matter expertise is required to analyse and convert the report/return elements into data concepts and derivation rules using the latest regulations, directives or guidance notes available from the regulators. To achieve this, Monocle suggests the use of a Data-Derivation Approach. Not only does this approach interpret the relevant regulations into usable data concepts, but it also provides for the identification of mathematical metrics, functions, macros and models that need to be applied to these data concepts to derive the required business fields. Once the analysis and interpretation exercise is complete, it is important to properly document the results and accompanying business requirements to ensure that the project teams are aligned regarding the project objectives and the core functionality required from the automated compliance solutions.
The aim of a data-derivation approach is to segment the data lineage – between the final report/return result and the primary data source – into derivation levels to capture the steps and inputs required at each point in its transformation. The methodology is illustrated in Figure 1 below, which shows that data can be transformed in various ways at each derivation point. These derivations are classified as either metrics, functions or model calculations. Furthermore, the use of this approach classifies data into either fact or dimension data at each derivation point. Following this approach allows for the definition of all inputs, transformations and calculations required between the primary data source and report/return result.
a. Define the database model
b. Define the model relationships and constraints
c. Database design and construction
The most effective way to structure data is to define and construct a data model. Using insights from Stage 2, the project team can identify all essential data components and appropriately design and construct the model and database required for the automation of all scoped reports/returns. Constructing a database on a properly defined data model ensures an understanding of the available data and, thus, informs the data sourcing requirements. It ensures a primary data source that encompasses the data requirements from various regulations that can be used to feed multiple business processes, including reporting. Additionally, a properly defined data model ensures fewer data errors, clear scope, data quality, accuracy and an alignment of data between the various regulatory reports.
a. Data sourcing and analysis
b. Solutions design
c. Prototype scenario definition
d. Solution build and test
With a database constructed, the successful identification of the key data elements and a detailed requirements document, the project team will be able to perform data analysis and consequently source all data required. Once the necessary data has been sourced, a solution design should be developed. A solution design is a critical component for the physical deployment of the automated solution, as it provides the development team with a blueprint of the functionality and architectural guidelines for building a robust and scalable solution. The design, with the assistance of the organisation’s IT and architecture teams, should also provide guidance regarding the technical specifications, physical IT and system capabilities required for automation. With a proper design in place, the team can begin the build. In addition, this stage involves defining business scenarios that would pertain to the audit process and can be used for testing purposes to ensure that the final solution delivers on the documented requirements.
Though Monocle advocates a multi-stage methodology, we also understand that there is no one-size-fits-all approach when it comes to compliance reporting automation. With years of experience in the financial services sector, we are well equipped to help potential clients realise the value of automation. Using a combination of deep knowledge and expertise in the areas of automation and regulatory compliance, we can develop a fit-for-purpose solution that effectively leverages your existing technology, while encompassing further considerations for automation enhancements i.e. robotics, to provide a robust, cost-effective and efficient regulatory compliance framework.
Monocle is a results-focused consulting firm, established in 2001, that specialises in banking and insurance. Our experienced consultants translate business and regulatory requirements into tangible and data-driven results to bridge the gap between business stakeholders and IT. In so doing, we believe in operating with integrity and transparency and working closely with our clients to determine and build a unique and pragmatic solution that will solve their challenges. At Monocle, we understand that institutional and subject matter expertise are critical to the success of any consulting engagement, therefore, we believe in having our projects overseen by senior consultants with years of experience. Over the last decade and a half, we have gained extensive institutional knowledge into all areas of financial services and have consulted in multiple regions including Africa, the UK, Scandinavia and Asia-Pacific.
[1] 1 The 2017 Ponemon report focused on the cost of complying with data protection regulations.
Explore trending topics in the banking and insurance industries
View allCopyright © 2024 | Monocle