Guideline Monitoring - Ensuring you get what you want
Recent events have, not surprisingly, focused attention at a number of Investment Managers onto Compliance in general and onto Investment Guideline monitoring in particular. The collapse of Lehmans highlighted the need for organisations to be able to both calculate their exposures to particular counterparties and to demonstrate to clients that their investment guidelines are in fact being adhered to. Ideally all organisations will already have in place processes and systems for undertaking guidelines checking. There should be a pre-trade process for ensuring mistakes are avoided in the first place and there should be a post trade process carried out by a team independent of the front office, for demonstrating that no mistakes have been made. And to those who might question the justification of doing something twice I would point out the demonstrable fact that most of us perform better when we know that someone else will be re- viewing or overseeing what we claim to have done.
So much for the ideal world, but what if the organisation is not quite there yet, what are they to do?
The Vision Thing
It is a well worn saying that knowing where you want to get to is an essential prerequisite of actually getting there. Time and again in our sector we see the consequences of an organisation not truly knowing where it was going: a veritable smorgasbord of processes, systems and pack- ages all integrated within an architecture known to few and understood by fewer still.
It need not be this way. Early on in the change process those that want or require the change, the key stakeholders, should agree on the high level architecture, a picture if you like, that is the target destination of the change. The ‘picture’ should answer such questions as ‘what guideline monitoring functions need to be performed and by whom?’, ‘what data is required to enable the guidelines to be checked and from where?’, ‘what technology components and new systems are required to support the functionality and data?’ At this stage, nothing should be ruled out. It is natural to allow one’s thinking to become constrained by the current environment. Clearly there will be pressures on revenues and a desire to cut costs but it will not always be like this. Decide what you really want and set out the vision. There will be pressures aplenty in the future to reduce but usually very few opportunities to expand the scope.
Now, it’s all very well having a vision, but achieving it requires ‘buy-in’ from all those that will ultimately be impacted either through having to adopt the delivered changes or having to finance the change. Achieving buy-in, of course, it not just about selling the vision of the end state but also persuading people that the steps along the way are the appropriate activities to be embarking on.
What To Do When?
It is at this point that a dose of realism is often required. Even in the best of times there is rarely the funding to do everything that is desired. It is now that the articulation and adoption of a shared vision comes into its own. The target end point will help structure the prioritisation discussions. It will provide an ideal end state against which all decisions on intermediate milestones can be assessed. Often the decisions on what is or should be done are based around who is feeling the most pain in the current environment or who is putting up the most funding. Both are perfectly valid prioritisation approaches so long as whatever is decided is judged against the extent to which it contributes to delivering the end vision. Often phrases such as ‘delivering business benefit as soon as possible’ will be used to justify prioritisation calls. But beware the false choice of delivering quick wins versus investing in laying down the foundations. Both are needed. Quick wins such as coding up half the guide- lines for a sub-set of funds will demonstrate achievement and result in credibility for those tasked with delivering change. But failure to start any required big infrastructure changes such as implementing a data ware- house for collating required data will delay or indeed prevent the ultimate completion with all that would entail with respect to additional cost.
For those organisations that may have a set of processes but few automated systems the choice may be relatively straightforward: build or buy and then decide on the sequence of development/ implementation. The decision will be more complex for those who may be expanding through acquisition or integrating separate businesses into a single entity. The existence of diverse legacy systems and processes will raise the questions as to what stays and what goes? Will all asset classes be traded on a single platform or will there be multiple applications? Many of the ultimate decisions will vary from place to place but with regards to guideline monitoring the ideal is to perform all checks, whether pre- or post- trade against a single set of guidelines. Running checks in multiple systems carries the risk of trades passing in one system and failing in another. Quite apart from the need to ensure guideline changes are kept up to date in multiple systems. In- deed, what becomes clear is that the vision itself and the system choices will often have significant operational business change implications.
Business Process or Technology Change?
Obviously, it’s both. The challenge is that the long lead time of technology projects can grab much of the initial attention and budget thereby relegating the operational change to almost an afterthought. But the business process changes need to be properly thought through if the full benefits of a successful guideline monitoring system implementation are to be realised.
There needs to be a comprehensive operating model that incorporates all the events that impinge on guideline monitoring. Everything from the point of client take-on and the initial contract negotiation through to the identification and extraction of the guidelines themselves and the process by which the guidelines are actually entered onto the system and automatically checked. Of course it does not stop there. What happens when a guideline check fails and a potential breach is identified? There needs to be a process that links the automated monitoring activities with the breach escalation and resolution process that ought to already be in place.
If the Operating Model represents the end state there are also the business activities that need to be carried out as part of the implementation itself. The sourcing, collating and coding of all the guidelines into the new system can be a major undertaking, especially if diverse partly manual based processes across different fund management groups are being replaced by a single automated process. There will be challenges in locating the most up to date legal documentation, agreeing standard definitions for the terms used in the guidelines and once coded into the system getting sign-off from the fund managers and/or client relationship officers. It should also be noted that the act of identifying and coding the guidelines will in large part define the bulk of the data requirements, which is itself a preursor to identifying all the technology change that is required.
Pulling It All Together
As always with any change there will be a lot that needs doing. The larger the organisation and the more moving parts, the more that will need to be done in parallel if an end date that will be acceptable to the sponsors is to be achieved.
Programme Management. It has become a bit of a dirty term at some organisations but when there are multiple change projects happening in parallel there really is no substitute for putting in place a proper programme management structure. You can put in place an appropriate governance structure with sponsors, project boards and accountable project managers but there will still be the need for someone to take overall responsibility on a daily basis. By definition sponsors and the members of the project board will be part time whilst they continue with their ‘day jobs’. Project managers, with the best will in the world will become focused on their own individual deliverables. To ensure the change process keeps momentum, that inter-project issues get resolved, that appropriate re-prioritisation and scope calls are made in the best interests of all you need someone who is focused on delivering the overall change.
So there you have it. It’s straight forward really. Agree the vision, decide upon the intermediate milestones and sequencing, ensure both the business change and technology work streams have appropriate levels of focus and wrap it all within a Programme Structure. It’s a wonder why change programmes ever fail.