How too much compliance might actually increase the risk of financial service companies?

Following the financial crisis, bank control authorities (like the FCA in the UK or the FSMA in Belgium) and compliance departments within banks have grown exponentially. As a result, regulatory costs have also increased dramatically relative to banks’ earnings.
At first sight, this seems indeed the correct reaction, to better control and monitor the banks and avoid a new crisis. Unfortunately in reality, this increased supervision, both internally and externally, often leads to bureaucracy (a check-the-box mentality), a lack of innovation and contraproductive measures, which often lead to an increase of risk rather than to a decrease.

This doesn’t mean that the increased government scrutiny and focus on compliance should be reduced, but a revision and modernization is in order. Instead of a prescriptive regulation, enforcing strict rules and often forcing specific solutions, which are quickly outdated (especially as regulations take several years to be agreed upon) due to technical and business evolutions, the ultimate goal of each compliance measure should never be forgotten, i.e. consumer protection (compliance should never be turned into an end, but should always be a means to an end).

Of course such goal-based compliance (= outcome-based compliance) is more difficult to impose and control than a rule- and process-based compliance, but it will ultimately lead to much better results, as it fosters a culture of innovating towards the best possible solution. For such goal-based compliance to work a strong open collaboration between project teams and external regulators and internal compliance and security departments is required. Hopefully this can allow regulators to become more forward-looking (anticipating future problems), rather than backward-looking (i.e. regulating what went wrong in the past).

Typical examples of well intended rules and policies imposed by regulators and compliance departments, which ultimately lead to bigger risks are:

• Strict password policies: many companies enforce complex passwords, with the need to change each password every X weeks. As a typical employee has often dozens of applications, each requiring to change its password on regular intervals (and usually at different moments for every application), this becomes almost impossible to remember. As a result almost each employee has some kind of file (at best password protected) with all his passwords. The result is a weaker security, than if passwords would not have to be modified every X weeks.
  Of course, the goal of the password policy is excellent, but the implementation lacks an end-to-end vision. Such a strict password policy can only be enforced, when SSO is in place or when a proper password management tool (like 1Password) has been deployed within the company.

• Separation of Dev (Change) and Ops (Run) departments(segregation of duties). In order to avoid fraud by internal employees and to ensure sufficient focus can be given to the day-to-day operations on bank systems, many regulators and compliance departments have imposed a strict separation between Dev and Ops departments (with only Ops departments having production access). The result is however all issues the DevOps movement tries to resolve, such as:

  • Bugs which can not be properly investigated by Dev teams as insufficient possibilities to analyse and reproduce the issue and thus stay open for a long time, resulting in significant operational risk

  • Lack of ownership of the IT systems, as Dev and Ops departments point to each other in case of issues

  • Ops departments which are often outsourced to off-shore countries, as it is difficult and expensive to hire internal Ops teams and keep them motivated. As a result many banks have very little info about the identity of the people having access to production data, because they assume that the contract with the outsourcing party sufficiently protects them.

  • Data extracts and log files from production which are shared in an unprotected way (e.g. via mail) between Ops and Dev teams for further analysis, as the Dev team can not access these files directly

  • …​

• Strong restrictions in security roles in applications: regulators and compliance departments impose that everyone should only have the minimum application access required to execute his job. In reality a job is not so strictly defined, as several people combine multiple roles or need to take-on temporarily additional tasks in context of a temporary assignment (such as a project) or in case of absense of a colleague or for supporting an overloaded department.
  In these cases, the need for an access is rather urgent. Unfortunately most banks don’t have the fine-grained authorization and the fast authorization change processes in place for quickly giving people the necessary authorization (usually handled via a ticketing system to a central shared team, which has often a large backlog and thus long lead times).
  As a result, people typically ask colleagues to execute tasks on their behalf or even worse they get the password of their colleagues. In the end this leads to a higher risk, as there is no clear trace anymore of who did which action.

• 4-eyes principle: in banks it is a standard that all critical processes (like executing payments or making important data updates) are protected via a 4-eyes principle mechanism. This seems again at first sight a great practice to reduce fraud and errors, but in reality research has showed that a 4-eyes principle actually leads to a lower quality, as none of the 2 persons feels fully accountable for the action (lack of ownership).

• Strict release cycles: in banks there are very strict release procedures, with very complex governance around it. These procedures are in place to safeguard the quality of the production systems, but in reality they are often very bureaucratic in nature and not very content driven. The downside of these strict processes is that bug fixes and security patches often take weeks to get deployed, resulting in unnecessary operational risks.

• Directives forcing the bank to warn/inform customers about different risks and forcing the customer to accept them before continuing, e.g.

  • MiFID2 directive in the securities space, where customers are requested to sign (accept derogation) when the Appropriateness test (test for necessary Knowledge & Experience in a financial product) fails. In practice most customers just sign this, without reading in detail the content. Again the intend to protect the customer against investment risks is great, but the execution does not take the typical behavior of a customer into account.

  • GDPR directive imposing pop-ups for users to confirm to store cookies: this recent directive results now in a lot of additional friction (all websites overloading us with messages) and very few users intentionally taking a decision with regards to their cookie policy (i.e. most people just accept without any thoughts). This overload of opt-ins actually results in less compliance as users tend to accept these pop-ups automatically, while the more important opt-in consents might be clicked away now as well.

  • Agreeing on Terms & Conditions: research has showed that if we need to read all Terms & Conditions of all sites and transactions we engage with online, this would take us 76 years per year. As a result everyone confirms without actually reading the content, making the forced reading of terms and conditions not very adequate.

• Raising capital through an IPO is highly regulated and complex. Obviously this is very desirable, but again this leads to some perverse side-effects:

  • As IPOs are very complex, companies only go public, when the majority of their growth trajectory has passed. During the steepest part of the growth curve, only wealthy individuals can invest (via VC funds) in these growth companies, resulting in an increase in wealth inequality (which is one of the issues regulators try to reduce).

  • Due to the complexity of the IPO process, companies find creative work-arounds, which are usually insufficiently regulated and as such very prone to fraud. Examples are Direct Listings (such as Palantir, Slack, Spotify and Asana) and ICOs (Initial Coin Offering).

• Other very regulated financial processes, being circumvented by innovative work-around and alternatives, such as:

  • Consumer credit origination being circumvented by different peer-to-peer initiatives and "Buy now, Pay later" vendors (such as Klarna)

  • Bank licenses bypassed by taking over a small player just for the license or by operating under an eMoney license which is less regulated

  • Payment and eMoney licenses avoided via different exemption mechanisms, like the commercial agent model, staying under certain thresholds by delivering the service via several small entities or by creative usage of the exemptions foreseen in the definition of the eMoney regulation

  • AML (Anti-Money Laundering): the AML regulation imposes that suspicious cash transfers should be reported and potentially blocked from execution. In reality the rules are so strict, that almost every large transaction of a (wealthy) customer should be reported or even stopped, which negatively impacts customer satisfaction. As a result, very creative solutions are found by relationship managers to make sure AML checks can be bypassed.

All these examples show that as soon as compliance impacts too much the usability and the operational business, people will find creative solutions to circumvent the regulation, often leading to a higher risk than if the standard service would have been used, without its strict policies.
While compliance is guaranteed on paper (the boxes are checked), in reality the compliance risk remains or has even increased, but under another form (which due to its additional complexity is usually less easy to understand, manage and mitigate).

The answer should be found in innovation and (new) technology (especially now that banks become more and more digital), allowing to impose the compliance goals, without jeopardizing usability and business models. The compliance departments and regulators, applying goal-based compliance, will verify if the goal is met, while the market can find the best solutions to find the optimal compromise between compliance and user convenience.

In order to transform to a goal-based compliance model, following practices should be implemented internally within a bank:

• Improve collaboration between all stakeholders of a project: compliance departments and security officers are too often considered by project teams as hurdles (bariers) to delivery. Instead these departments should be involved from the start (cfr. DevSecOps movement) but in a collaborative way, where all stakeholders try to find together the optimal solution to meet everyone’s objectives.

• Compliance departments should always look at the end-to-end process, when adding an additional rule (policy), i.e. can all persons impacted by a compliance/security rule still effectively execute their work, also in the case of situations of exception, i.e. a situation of stress, crisis or emergency.
  If this can not be guaranteed, alternatives for the policy should be investigated (or existing processes should first be improved), which meet the same goal. If this is not done, people will invent work-arounds, leading to higher risks.

• Teams should get more end-to-end responsibility and accountability, including taking decisions (in cooperation with compliance departments) for specific compliance issues.

• Alignment of objectives: compliance and risk departments should also get business objectives, but vice-versa business departments should also get objectives on compliance and risk. This way both department have common objectives to find compromises on.

• Instead of blocking all entrances, resulting mainly in user frictions for benevolent employees and customers, it is better to give more flexibility (and access), but have a continuous automated monitoring system, which keep an audit trail of all actions of everyone, but which also identifies (using Machine Learning algorithms) anomalies in an application usage. Such a system is much more convenient for users and it is also harder to bypass for malicious users (as the security policies are less strictly defined).

• Compliance projects should also be initiated based on a business case, instead of just accepting them under the category "mandatory compliance". Currently in many banks, large percentages of IT budgets are being consumed by so-called "mandatory" compliance and regulatory projects, which means that very little budget remains for business added value projects. Often those projects don’t effectively improve compliance.
  In order to calculate the business case, the cost of a risk should be calculated (by multiplying the probability of the risk with the cost ,such as penalties from regulators, lawsuit costs, reputation risk, loss of business…​) when the risk occurs. By multiplying this cost with the percentage the project is going to mitigiate this risk (very important factor, as many compliance projects only marginally mitigate the risk), we arrive at an estimation of the revenue of the compliance project, which can be balanced with the project cost, to create a standard business case.
  Via such business cases, the compliance projects can be compared between each other, but also compared with business projects (such as new product launches or cost-reduction exercises). Many compliance projects will still appear on the top when classifying projects on ROI, as the cost of certain risks are so enormous. For example companies not complying with GDPR regulation can face fines of up to 4% of their global annual turnover.

For external regulators, a number of improvements should also be considered:

• Regulations should be enforced more severely. E.g. many banks are still implementing improvements in context of MiFID II, now 2 years after it came into effect. Idem for PSD2, where ver few banks in Belgium already provides a well-working API for AIS/PIS services.

• Don’t focus on the low hanging fruit (i.e. the simple businesses, products and processes). As the financial crisis has showed, most risk is in the complex trading departments, where banks are not not always willing to cut too deep, as these are their most profitable departments.

• Transform from a prescriptive to a goal-based (outcome-based) compliance, allowing to give freedom for banks to implement the best solution (often based on real feedback and insights obtained from their customers). This is especially important as regulations tend to take several years, meaning that any solution proposed in a regulation will likely be already outdated by the time the regulation comes into force.

• Don’t be afraid to get rid of ineffective regulations. Governments should understand that rules and reports imposed, which do not bring additional protection, have ultimately adverse effects on customers, as the extra costs of those practices are in the end charged to the customers.

• Have a long term vision (a plan), instead of reacting on issues. Such quick measures on incidents, typically leads to overregulation and an inconsistent policy.

Of course all this is easier said than done. The job of a compliance deparment and regulator is typically not a very grateful job. If everything goes well, everybody complains about compliance as it imposes restrictions and frictions. However once an issue occurs, everybody shouts that compliance departments and regulators should have seen it. It’s a "Damned if you, damned if you don’t" situation.

It’s clear that with our world becoming more complex and digital, compliance will need to increase even more. However it’s time to go for a new approach, driven by innovation and technology, with a focus on the goal (outcome) and not on the process.