READ
Risk & Compliance

The digitisation of the compliance function – Compliance by design & default

Most financial institutions are required to establish an effective and independent compliance function. Much is known about the independence of the compliance function, but how do you ensure an actually effective compliance function? And how does that work in practice with complex operations, changing processes, a walk-through of employees and a large amount of data? In this article, we explain a specific approach: achieving an effective compliance function by setting up ‘compliance by design and default’.

Date:October 11, 2022

Notice: Undefined index: titleWrapper in /data/sites/web/projectivegroupcom/www/wp-content/plugins/seo-by-rank-math/includes/modules/schema/blocks/toc/class-block-toc.php on line 103

The challenges of a compliance function

Adequate compliance setup or getting (and keeping) experienced staff on board is not the biggest compliance challenge for financial institutions. The real challenge lies in constantly improving the effectiveness of the compliance function to ensure that the entire financial institution is operating compliant at all times, while at the same time keeping costs at an acceptable level. As described in the second article of the ‘Digitisation of the compliance function’ series, financial institutions tend to operate on the basis of a silo structure, with data duplication (different departments creating and/or managing (the same) data) having a negative impact on information management and the overall knowledge level of the organisation.

Today’s times – in which costs are rising, business complexity (and hence the complexity of the applicable regulatory framework) is increasing and process inefficiencies are coming to light – call for a smarter compliance function than most financial institutions have realised to date. Often, financial institutions respond to such challenges with a more fragmented (or ‘specialised’, because that sounds more positive) approach. Especially in terms of compliance risk and control activities. This is also certainly explainable. After all, such investments are often made decentrally by different budget holders, with little or no focus on integrating the activities, processes and underlying data. In this way, the compliance function is (even) more shielded from the business, which pertinently goes against its raison d’être. After all, the compliance function exists because it has to independently and effectively monitor the management of the financial institution’s compliance risks. Compliance risks arise from business operations and are precisely not only to be found within the compliance function. Therefore, the compliance function also needs to be more integrated into the business if it wants to be aware of these compliance risks in a timely manner. In short, as Doyle et al [1] point out, “The GRC [Governance, Risk and Compliance] function, to date, has failed to deliver Boards with a comprehensive profile of its role and potential impact in terms of its ability to contribute to manage the uncertainty around both favourable and unfavourable events”.

Compliance by design and default

Compliance functions can use the strategic approach of ‘compliance by design’ to reshape their processes so that they are truly 100% ‘in control’. “Compliance by design means applying a systematic approach to integrating regulatory requirements into manual and automated tasks and processes” [2]. In addition, the extra step can be taken towards ‘compliance by default’. This involves not only looking at the design of processes in advance, but also at their execution on a real-time basis. If a financial institution has implemented compliance by design and default, compliance is thus realised at the time of defining the means (such as software and systems that support processes), as well as at the time of the actual execution of those processes (by employees). This dual solution ensures compliance both beforehand and during the moment suprême.

Compliance by design can be achieved by developing software and systems that by definition only allow ‘compliant’ actions. Here, non-compliant actions or actions are technically impossible to perform. An example is the customer due diligence performed in a CDD process, where the financial institution’s policies (and procedures) are built into the onboarding software. In this way, one possible path is effectively created for the employee to go through during the onboarding process. In such a case, it is wise to take a systematic approach in the CDD policies, so that it is not necessary to (completely) change the software for every small change in the CDD policies.

Compliance by default can be achieved by triggering certain security aspects during the execution of a process that inhibits an employee from acting non-compliant on a real-time basis. An example is providing a pop-up notification with ‘please note, by performing this action you are acting in breach of policy’. This can be done, for example, during a client screening as part of a CDD process, when the employee indicates that he considers the potential client’s risk profile to be lower than that indicated by the red flags in the system. In this case, the red flags from the CDD policy are implemented in the system (compliance by design), stopping the employee from circumventing such policies during the actual execution of the process.

Why do few financial institutions use compliance by design and default?

Change is hard for people. Especially when IT will begin to exert a greater influence than it did before. In addition, the compliance function is a function that has traditionally not been at the top of the priority list to get investment. However, this is an unwise choice: after all, a good level of compliance ensures that the licence is maintained which is ultimately the raison d’être for most financial institutions.

Another reason could be that, somewhere, financial institutions may also find it fine that their compliance function does not have constant insight into all data, patterns and trends, but only into certain (less interesting) fragments at certain moments. After all, who knows what will come to light when all the data is integrated and certain trends and patterns become clear?

Moreover, employees cannot ‘forget’ something that is automated. This forces them to act compliantly (provided compliance by design and default is properly implemented). However, they probably find it more pleasant to carry out their activities freely, without being forced to act compliantly because the systems and software enforce it. Thus, a ‘compliance-first’ approach in processes, systems and software will help achieve a more effective compliance function. The question, however, is whether all employees will welcome this approach with open arms.

Want to know more?

Want to read more about the digitisation of the compliance function? Then read the other two articles in the series:

The digitisation of the compliance function – The Regtech landscape

The digitisation of the compliance function – Data-driven compliance

Curious about compliance by design and default in practice? Projective Group can help you make your compliance function more effective. Please contact us without any obligation.