Back to all articles

The Pitfalls of Coding Your Own Rules (Part 2)

5 mins
Posted on Jun 22 2020 by Karl Schindler

Here we discuss the complexities of maintaining regulatory data in detail & address the importance of enlisting domain expertise necessary to ensure compliance.

Compliance expertise and challenging regulatory data.

In the first blog of this series, we discussed how both the pace of regulatory change and the difficulty in sourcing official regulatory data should lead firms to seriously reconsider coding and maintaining one’s own rule code. Now, we’d like to revisit the complexities of maintaining regulatory data in more detail and address the importance of enlisting domain expertise necessary to ensure compliance.

Seemingly simple but difficult-to-implement regulatory change

In considering whether your firm can, or should, monitor global disclosure obligations using their own rules, it’s important to know that rule code is often dependent on specific, official regulatory information for which there is no clear data standard. Lists published by regulators or exchanges might seem straightforward, until one discovers:

  • The source might be updated at any time
  • One must accurately map the values identified in the official source to industry standard asset data (more on this in a minute)

Not only must substantial time be devoted to keep the required data up to date, but operational risk increases due to repetitive manual processes like ensuring these lists are mapped to one’s rule engine as soon as the regulatory source changes. It’s best to demonstrate this by running through a few examples: 

UK Prescribed Markets

Rules under the UK major shareholding regime (also referred to as DTR Chapter 5) require that one must disclose holdings in securities of UK companies traded on “prescribed markets” (which are determined by the FCA’s list of Registered Investment Exchanges (RIEs)). This must be done in addition to those traded on Regulated Markets (and, at the time of writing, those whose issuer has a Home Member State of the UK). 

The list of what the FCA considers an RIE can change at any time, due to new registrations or due to exchange mergers or name changes. The FCA also doesn’t indicate how the list of RIEs should map to standard exchange identifiers like ISO’s MIC. When maintaining your own rule engine, one must carefully assign individual markets (MICs) to each RIE. Since doing so is not clear, this might also entail contacting the FCA directly about how to perform the mapping precisely. This is also not a one-off exercise. If either the FCA or ISO updates their lists, both changes must be considered and the mapping updated.

London

Australian Licenced Markets

Similarly, under the short selling reporting regime in Australia, short positions taken on ASIC’s list of “licensed domestic and overseas financial markets operating in Australia” is required. In this case, the list provided is not a list of specific markets, but a list of legal entities which operate specific markets, and often more than one market. This means a mapping exercise must be undertaken for each entity listed and the mapping maintained if changes occur at any time. Like the case of the UK prescribed markets, the mapping must be done from an official website to standard ISO MICs or another common exchange identifier to complete a full compliance check. 

Currently, almost every country’s disclosure obligations refer to specific, regulated, or licensed markets, many of which do not provide standardised identifiers. This means just about every holder of financial instruments who decide to code their own rules needs to ensure accurate identification and mapping and perform the steps outlined above.

Why spend vast amounts of time doing so when you can benefit from an industry-standard service used by peers where this is taken care of using the latest technology?

Sydney

Compliance expertise in SD, SI or PL

A significant cost associated with coding and maintaining your own rule set is making sure your firm is staffed with qualified compliance officers, coding specialists, and legal professionals so that everything is interpreted correctly, translated into a domain-specific coding language, tested, and maintained when either the regulation or software versions are updated. The skills needed come from both a breadth of knowledge in regulation and finance and from specialised compliance monitoring experience. It includes the interpretation of often opaque regulatory language, having specific coding skills, and holding a deep knowledge of financial instruments. Finding compliance analysts which fit the bill isn’t easy and usually comes at a steep price (to say nothing of the sky-high day-rates of compliance and IT contractors), both financially but often also in the form of key-person risk. Ensuring that your compliance team follows operational best practices like robust end-to-end testing and 4-eye review only complicates matters further. 

Deciding to fully monitor shareholding obligations internally also means that one will rely on a limited range of coding tools as the main vendors aren’t focused on a compliance engine fit for the purpose of shareholding disclosure, sensitive industries or derivative position limits.

Having over a decade of experience coding the very systems many institutions still rely on to build a monitoring function in-house, I can attest that they cannot handle the range of complexity in important areas such as aggregation requirements, detailed regulatory exemptions or regime-specific netting requirements.

But let’s say that you’re still not convinced that finding a best of breed compliance service in the cloud backed by compliance experts is right for you, and you feel confident in handling this internally. It still stands that you’d be duplicating the same effort expended by all of your peers in the industry. We are all subject to the same regulations. A robust managed service, where your firm's specific needs are taken into account when enhancements and upgrades are made replaces the high, hidden costs of doing it internally. In any case, shouldn’t your compliance officers be focused on areas of regulatory compliance which require human judgement, instead of exchange code mapping, rule coding, and training in outdated technology?

At FundApps, our service includes a dedicated client support team to assist you at any point, and an expert regulatory content team whose role is to interpret legal information into automatically tested and fully corroborated code which always reflects the latest regulatory changes. We strive to make all of our interpretations and coding both transparent and understandable to our users, and encourage our compliance community to give us feedback in a dedicated rule commentary forum so we all benefit from each other’s knowledge and experience.

In case you missed it, you can check out the first part of this series here.