At IMP, we have seen our fair share of compliance rule coding errors. They can range from something so simple that a recent grad could spot it to something so complex that only an expert with in-depth industry knowledge would ever notice. Obviously, there’s no point to having a library of compliance rules if you aren’t sure they’re even working. This is where your testers come in. However, testers are going to have varying levels of knowledge and experience when it comes to compliance rules. It would be obnoxious of me to sit here and tell you to just find smarter people to test your library, so instead, here are my top five tips for anyone testing a compliance rule library, regardless of their background:
Before starting, think about how you’d code it
The easiest way to spot something that seems wrong is if you actively expected it to not be there in the first place. It can sometimes be tougher to spot a mistake that your eyes have already adjusted to. So, before you even look at the way the rule is coded, read the name of the rule. Think about how a rule with this name should be coded. Then, when you actually read the expression, pay attention if the coding deviates from your expectation. If this happens, there are a few explanations for you to run through in your head:
· Is the issue in the expression itself?
· Is it a syntax error, meaning that it was just the name that was written incorrectly, which falsely led you to believe the rule was testing for something different?
· Was your hypothetical approach on how to code this incorrect, but now you see why the original coder did it a better way after you’ve looked at it?
When you think about the rule before you look, you are far less likely to gloss over a real error that wouldn’t look out of place at first glance.
Assume something is wrong
Even the best of the best compliance coders make mistakes. They are human, after all. And sometimes, the people coding your rules might think they’re coding something correctly, but they lack the level of experience necessary to recognize when they’re coding a particular rule incorrectly. That is why you never want to give your coder the benefit of the doubt in such a high-stakes situation. Ultimately, money and jobs could be at stake from a single poorly coded rule. So put your detective hat on and really scrutinize for mistakes. It’s sort of like the U.S. criminal justice system, but opposite. Your attitude toward every rule you test should be: ~Erroneous until proven correct~
Check everything
This one is related to the last point because a good detective will look in every single nook and cranny around the crime scene. Every list, asset class, classification, etc. in your compliance rule should be checked. You don’t want to cut corners in the interest of time only to find out years later that the rule had an easily preventable mistake.
Learn how to look in the Database
Knowledge of how to tap into your OMS’s database can be your best friend. Not only does it help you find things that can easily get lost in a sea of front-end drop-down lists, but it also helps you find and validate information faster. Need to check what security types are in that asset class? Database! Want to see an alphabetical list of countries of risk of the securities in a particular benchmark? Database!
NEVER test your own rules
If there’s one thing I want you to take away from this blog, it’s this last point. Most of us probably think we’re better than we are, especially in this industry. Typically, you are going to be much more critical of others than you are of yourself. You also want another set of eyes on your rules to catch your mistakes. Maybe you didn’t know something or maybe you forgot something, so there is a much greater chance of filtering out the dirt if there is second person there to provide that extra protective layer.
Nobody is perfect, and coders and testers alike are all prone to making the occasional mistake. However, by following these guidelines, you can vastly reduce your risk of letting a coding error slip through.
