Setting up a governance program for effective management of investment product master data
This is part 6 of a series of blogs on setting up a governance program for the effective management of investment product data - in this blog I will briefly consider the importance of process and procedure documentation.
In my previous blog in this series, I highlighted why standards and policies are important to the task at hand. Similarly, process and procedure are also key elements of an overall program of governance for your investment product data.
If you consider the statement of your policies and standards as the clear communication of the strategy for your program, the explicit documentation of the processes and associated procedures speaks directly to the execution of the strategy.
A process is an operational workflow description that takes into account starting states, end states, resources, participant teams and individuals who interact at each stage or state in the process – a procedure on the other hand is a simply detailed set of instructions for carrying out a specific task, or part of an overall process.
If you consider the example I used in the standards and policies post:
- Policy: ”the policy in our firm is that all client requests for data must be signed off by compliance“
- Standard: “all requests from clients for bespoke client reports should be logged in the ‘reports-requested’ database by the client service team. Only users with a security role of ‘compliance authority’ will have the capability to approve a request in this database and no report shall flow to a third-party without reference to an approval record in the ‘reports-requested’ database”.
In this scenario we clearly need a detailed description of the process which starts with the event of a client request being received, ending with the delivery of the report to the client. In between the start and end points we need to clearly document the various valid paths or stages the process would need to pass through – for example, showing the logging of a request for compliance approval – this process document should call out the specific valid (and invalid) paths, stages, resources, systems and people interacting at each stage in the process. Typically, the document will contain a process flow diagram (there are tens of different diagram types) and related verbiage that explains in detail each step.
Within this process we will need a set of detailed procedure documents that explicitly call out the instructions for carrying out specific tasks – for example, you may decide you need to have a specific procedure for calling out how to log a client request into the compliance database.
From my own perspective, the definition of the processes that come under the remit of your program is a far more important task than the documentation of the procedures - get your processes down pat first, and only then start to consider the documentation of your procedures.
Next up I will explore the creation of a master data plan…