Back to all articles

The Pitfalls of Coding Your Own Rules (Part 1)

5 mins
Posted on May 18 2020 by Karl Schindler

Regulation is ever evolving and can change at short (or no) notice. As a result, coding your own rules poses several risks.

Falling behind the pace of regulatory change. 

Prior to joining FundApps in 2014, before “RegTech” was a thing, I noticed that it was commonplace for asset managers, banks, and other holders of financial instruments to buy expensive, on-premise compliance software and hire compliance analysts, legal staff, and IT professionals with specialised knowledge of how to code these very specific systems. In fact, many financial institutions seemed happy to maintain the status-quo, partly because almost all of the associated costs were hidden! Multi-year implementation fees were added to already high upgrade costs just to ensure firms could keep up. Compliance monitoring contractors were brought in at high rates to ensure that changes in risk guidelines and regulations were reflected accurately and to train permanent compliance staff to use a new system. The cycle repeated every few years when a shiny, new version of the software was released.

www.fundapps.cohubfsExcel Download 3It was either that, or companies employed the risky strategy of using Excel to monitor complex disclosure obligations where errors could result in massive fines and reputational damage.

Here at FundApps, we believe in the power of cloud software to allow compliance officers to benefit from a shared set of compliance rules. We’d like to share some of the major pitfalls to either purchasing a compliance system and maintaining your own rules, or deciding on a cheaper, but much less robust alternative.

Regulatory Change at Short (or no) notice

Regulation is ever-evolving.

The only constant in life is change. Shareholding disclosure, position limit monitoring, and sensitive industry compliance share a common attribute: the underlying regulation can and does change, often without notice. This means that buying software which provides the tools to code rules is only a sliver of what will be needed. Updated regulation will need to be reviewed, interpreted, and coded whilst keeping in mind complicated aspects such as what calculations or thresholds will apply, which asset classes are in scope, which portfolios or entities in your firm to aggregate or not, and the list goes on. Consider if your firm (or a less agile competitor) would be able to deploy the following regulatory changes in time and with accuracy: 

  • EU Short Selling Regulation (16th March 2020): In response to the COVID-19 pandemic, ESMA lowered the reportable threshold for EU net short positions to 0.1% overnight. Imagine maintaining a rule set comprising at least one rule for each EEA jurisdiction. Now consider what would happen if the regulator (ESMA) immediately changed the lowest reportable threshold to 0.1% of shares outstanding. Without an experienced team to support you or the rule changes necessary to implement at your firm at the click of a button, the time spent keeping your rule set up-to-date would likely mean a missed disclosure given the quick turnaround time. Add in the time for thorough testing, 4-eye review, and communication of the change to management, and both the risk of errors and the stress-level rises precipitously. Thankfully, we were able to deploy these rule changes to our entire client base of nearly 100 clients, with robust testing and review, on the same day - and on time.


  • EU Amended Transparency Directive (TDAD - 26 November 2015): When the Transparency Directive was amended in 2013, there was a two year period in which Member States were to implement the Directive locally. As this was done, each EU jurisdiction’s law in relation to the Directive needed to be interpreted and reflected in code, including the paying of sufficient attention to possible “gold-plating” (additional rules) of the disclosure obligations. Examples include the Netherlands additional nominal share capital regime, or Spain’s additional 1% threshold on entities or funds domiciled in a tax-haven. This is to say nothing of the way certain parts of the TDAD, such as which asset classes to include, often differed among countries.

Constantly changing and difficult to source regulatory data.

In the area of both shareholding disclosure and positions limits, there are a high number of obligations which require up to date, accurate regulatory data. Changes in this official regulatory data can impact your obligations immediately.

A few examples are:

  • ESMA’s FIRDS database: It is vital that one uses FIRDS to ensure compliance with the EU Short Selling Regime. This is because the database contains which “Relevant Competent Authority” (RCA) one must disclose a given position to. Monitoring this manually or finding ways to integrate the changing values from FIRDS automatically will incur significant cost and lead to a much slower and riskier disclosure workflow.
  • Takeover panel lists: There are many jurisdictions which require additional, separate compliance obligations for issuers who are party to a takeover offer. It’s important to ensure that all issuers or securities are on these official lists. The UK Takeover Panel is a salient example of how important it is to do so properly. The list can change every day, and in some cases during the day. The same is true for a number of other countries.

When coding your own rule set, you will invariably spend time, and incur costs monitoring regulatory and exchange websites. Significant resources will be needed to automatically check this data via web crawling, scraping, and mapping to security data, or spent by a team of compliance officers to manually (yes, that dirty word) monitor data. Time spent on such menial tasks means time taken away from focusing on more important compliance tasks - where human judgement is required. Manual checking is also prone to error and introduces key-person risk. In fact, we’ve heard many stories of compliance officers not being able to take a holiday or having to work overtime due to others not being able to cover their work in such cases.

I hope I’ve shed some light on some of the challenges the compliance community faces with regards to regulatory interpretation and rule coding. In the next part of this two-part series we will be investigating a few more areas where an isolated and outdated approach to compliance monitoring may not be sufficient. We will also look at how the industry is solving such problems. 

Don’t let the pitfalls of coding your own compliance rules get you down any longer! Book a demo to see our automated services in action. 

Click here for part 2 of this series where we discuss the complexities of maintaining regulatory data in more detail and address the importance of enlisting domain expertise necessary to ensure compliance.