Overview
This article explains how FundApps codes rules and the internal controls we employ to reduce the risk of errors.
When Do We Create or Change a Rule?
We rely on aosphere and its interpretation of regulations as our trusted legal information provider. A new rule may be created when a new regulation is introduced that affects a holder's compliance obligations, such as EU Short Selling Regulation (EU SSR) or Transparency Directive. Rules may also be updated when aosphere updates its memos or when we improve our legal interpretation. In some circumstances, we may introduce new properties or change existing ones if required by regulation to ensure rule accuracy.
We commonly engage in discussions with aosphere and our clients about regulatory matters. You can read more about that here.
How Do We Code Our Rules?
Our dedicated Compliance team maintains our entire library of rules and creates new ones. Before any new rule versions are pushed into the cloud and deployed across client environments, all new code must pass through a firmly established procedure:
Legal memo analysis: Once we receive a legal memo from aosphere, our Regulatory team interprets the changes and outlines how they apply to our rules.
Interpretation review: A second person reviews the interpretation of the legal memo to ensure accuracy.
New rule version: An assigned team member codes the first draft of the rule.
Testing: We test this code against individualised, automated test cases involving up to 100 real business scenarios. This is known as Behaviour-Driven Development. For example, we test for particular asset classes, characteristics, and other nuances the rule needs to pick up.
Code improvement: We review test failures and use them to improve the draft code, after which we run additional tests.
4-eye review: After passing those stages, we assign the code to a second reviewer. The reviewer checks the regulatory justification for the rule and verifies through testing that the code aligns with the legal interpretation.
Deployment: If the rule coding passes review, it is ready to be deployed into the live production version across all client environments.
Behaviour-Driven Development
Behaviour-Driven Development is an automated, scenario-based testing method where the initial assignee specifies testing criteria using a Given, When, Then model. This approach offers several benefits:
Each rule is tested against strict criteria determined entirely from an individual, specific use case.
Simple syntax makes it easy to understand and see exactly what is being tested and what is not.
Expressive test names are useful when tests fail.
Simple sentence test cases keep tests focused.
Deploying a new rule
When deploying any new rules or properties, we send a notification to inform you if any special action or new data is required.
Whether it is a completely new rule (such as a new jurisdiction) or an updated version of an existing rule, it will appear on your Task List. You must approve the rule before it takes effect in your environment. When you review a new rule version, the platform highlights the changes for comparison.