Migration of Compliance Platform from Legacy solution to SaaS based platform

Migration of Compliance rules of Clients from System M to System CR, rules were majorly prospectus rules with some regulatory rules .Usually proprietary solutions have their pre-built rule set which contain most of the known regulations such as UCITS V, AIFMD, MiFID II, EMIR, PRIPs , Dodd-Frank Act and FACTA.

The Goal was to review the Client Investment Guidance documents and SYSTEM M rules to come up with the list of rules that need to be moved to System CR in an optimized manner.

Step by Step method for Compliance conversion

1. Build a list of rules that need to be converted by analyzing the existing inventory from System M. Many clients which operate from different regions have multi region instances which lead to duplication of similar rules but since the underlying data and configuration might be different there needs to be special care while converting such rules.

2. De-Duplication of rules, as mentioned earlier, that many rule are duplicate or can be consolidated into single rule, a deep syntax level analysis is required to get the de-duplication done which will help reduce the number of rules.

3. Investment Class and Security Type mapping is one of the major steps in the conversion as mostly the Security Types and Investment Class are not one to one mapped, System M is a customizable system hence anybody can create their own Security Type and Investment class even for a specific rule but System CR has pre-defined Security Types and Investment Class with very less opportunity for customization, especially in case where you are moving multi region System M to single instance System CR

4. Data Mapping needs to be done by mapping Fund, Position,Holding,Security,Exchanges,Country,Currency,Counterparty,Industry Classification,Rating etc,there are two aspects of the mapping one is mapping of the attributes and another is the mapping of the values.

5. Cash & Collateral securities would need special mapping as usually they are structured differently within different systems, for example system A might have Security Types for every individual Cash Type but system B might have only one Cash Security Type and would need some user defined fields to do sub classification

6. Derivatives are complex instruments with one Instrument having multiple legs and the number of legs and leg structure vary among systems where one System Might have 2-legged Swap and other might have 3 legged Swap and mapping their cash flow and consolidating under correct leg might be a difficult task

7. Syntax Mapping is another very important activity as different systems use different syntactical parameters,attributes and values

Syntax like EQUITY(COUNTRY = INDIA) > 0 would need to be converted hence would need mapping of the Security Class Equity to something similar in destination system along with that the attribute COUNTRY would also need to be mapped with the equivalent syntax in the destination system along with this value INDIA.

8. There are many system level gaps in how value is passed from one rule to another or executing dependent rules which one System Might allow but the another might not.

9. Once we have the initial level of mapping then we can go ahead with Tranching or dividing the rules based on complexity or client preference to start converting them one by one and putting the tranches in a timeline plan with Development, Testing and Deployment cycle as Agile in Sprints.

10. Once the first Tranche is Developed and Tested, it should be deployed in the UAT for Business Users to test and review as per the Fund Prospectus provided by Client.

11. Any issues found during Testing and UAT should be sent back to Development.

Issues & Challenges of Project

1. Data mapping should be the first step and mostly projects are kicked off without doing Data mapping. Example of Data Mapping: In Securities Table Coupon Rate or Yield are Bond related fields which are present in Securities table in source system but in Securities Details table in destination system with Field name being CNPN or YLD.

2. Rules De-duplication is a tedious exercise and clients usually start doing rule de-duplication and rule alignment to investment prospectus guidelines task late which should be done at the start of the project

3. Syntax mapping, as with any System Migration where coding is involved mapping of syntax formats, attributes, parameters and values are prudent to start the transformation.

4. Big bang or Waterfall approach usually doesn’t work with such projects and an Agile approach by breaking the set of rules into tranches is the most efficient and specially if the tranching is done per client as that would lead to client specific Go-Lives and would be helpful for the end users (Operations Team) to manage.

5. Documentation of known system differences and addressing them one by one.

6. Knowledge Base of addressing issues should be published across project so that everyone is aware of the issues and there is a standard solution implemented across the project

7. Addressing any existing manual rules and potential for conversion to new system