Mastering Investment Product Data

What do I mean by investment product data? In my domain, an investment product is a collection of investments or securities pooled into a single product. So to me it encompasses mutual funds, institutional accounts, SMAs and any other similar collective investment vehicles.

So investment product data is any information, data, or content which is communicated to the external world about that product – we call this the “product master”.  For a mutual fund this could be the fees/charges, fund manager personal data, the fund’s objective, holdings, external ratings etc. Effectively any data you would regularly see on a document used in the sales process e.g. fund fact sheets, documents produced and filed for compliance reasons e.g. Summary Prospectus (Europe), Simplified Prospectus (USA), the soon to be KID (Europe), Fund Facts (Canada) and annual reports, or indeed any information delivered via web channels, be that distributor micro-sites or retail web offerings, fund trading platforms and so on.

So we have a reasonable view on what the product master data sets encompasses, more importantly though how do you master investment product data?

Mastering Investment Product Data

The core of any master data management process requires a “System of Entry” and “Statement of Record”

In layman’s terms – you need a way to get your master data into the master data management system, and once there you need the system to be a statement of record – that is your system needs to know who added what data, when they added, from where did they add it, what was the source of the data, who owns the data, what business rules were applied to the data, what exceptions occurred, who approved those exceptions, what was the previous value….and so on – effectively you want to have a forensic audit trail for every data item in the master data system.

When mastering investment product data there are four key problem spaces your master management system must solve for you:

1. You need your system to apply governance and support  stewardship. What do I mean here? Well if we consider that governance is the definition of the strategic plan you have for your data management, then stewardship is the operational application of the governance strategy. You need your system to support de-centralised ownership/stewardship and to enable governance and oversight to be centralised.
2. You need your system to provide data aggregation or ETL (extract, load, transform) interfaces. All MDM systems have ETL interfaces to facilitate the aggregation of a myriad of sources, formats and delivery protocols as well as the core master record data management set.
3. You need your system to manage the quality (timeliness, accuracy, consistency) of your data. For a domain-specific master data management system you need all of the standard BRE (business rule engine) features you’d expect to see in any ETL platform, complemented by an iBRE (intelligent BRE) that deals with domain- specific data analysis.
4. You need your system to manage the accessibility and  availability/security of your data. Finally, your system needs to ensure data can be easily communicated and made accessible to those who have rights to view it. This can mean system to system exchanges, be they batch or event-driven and ad hoc query and reporting.

I will be producing a whitepaper which explores the subject in more depth and will publish the link to this document on the blog once it is ready.