An effective blueprint for onboarding with third-party administrators

By Tim Fox, Senior Consultant, Citisoft
By Soapbox

By Tim Fox, Senior Consultant, Citisoft

The last decade has seen a marked increase in the amount of investment managers outsourcing various back- and middle-office functions to third-party administrators (TPAs). The driving force behind this trend has usually been cost: Many investment managers have simply not had the scale or budget to sustain such functionality without it detrimentally affecting their competitiveness. Instead they have looked to a growing number of dedicated market providers who offer to perform these services, whilst allowing the investment managers to concentrate on their established core skills of investment decision making and portfolio management (traditionally viewed as front-office functions).

Although there have been obvious benefits through outsourcing, the initial stages of an implementation from due diligence through to migration of the client onto a third-party platform has consistently proved to be a painful and protracted experience.

The industry is now seeing first-generation outsourcing contracts coming up for renewal, and investment managers are examining their current relationships with more diligence. So why has this process of onboarding at times been so troublesome both for the TPA and the investment manager? There are a whole host of reasons for this, and below are just a sample of areas where significant improvements should be made in order to develop an effective blueprint for onboarding with a TPA.

Firstly, the structuring and resourcing of project teams tasked with the various phases of the implementation is absolutely integral to ensuring a smooth transition. All too often, service providers have not spent enough time and effort in selecting who will lead projects and the most appropriate structure for the project team. Key positions such as the program manager and work stream leaders are often sourced internally and tend to consist of people who may have sound proprietary operational knowledge but lack essential project management and business analysis discipline. Such practice is not exclusive to the TPAs, however, and investment managers are sometimes guilty of assuming that operational resource will be able to effectively manage the transition.

Secondly, repeatability should be a byword for the client onboarding process. Whether the client has multiple functions that require transition in different phases, or whether they are to transition in one effort (a big bang), the methodology and tools deployed within many functions should be repeatable and scalable. In practice, however, this frequently proves not to be the case. TPAs invariably focus on maintaining a healthy pipeline of potential business rather than on analyzing the existing practices they deploy to transition clients onto their platform. A classic example of this approach is when an implementation enters a testing phase. Different asset managers will have a variety of asset classes that they are looking to migrate, but the TPA should still have a test pack methodology covering all the asset classes that an investment manager may trade in. In this way, the test pack can be reused in a multitude of situations. The problem is that all too often, when an implementation gets to this phase, a certain element of reinventing the wheel occurs, with new test cases and examples being created. This scenario highlights two issues. First of all, the TPA does not have a robust infrastructure to record repeatable project functions. Additionally, such ambiguity and uncertainty does not reassure the client and thus can further strain relationships at what is already is an inherently tense period within an implementation.

Thirdly, a lack of emphasis is placed on the change control process as and when the client fully implements. A clear delineation between what is part of the implementation and what is agreed to be part of the change control process post migration is essential so that the boundaries are clearly defined and both the client and TPA are agreed on the schedule of work.

Going forward, TPAs need to establish a template for their implementation teams to adopt. By investing time and effort into examining what elements of the project phases can be documented and repeated, the TPA will be in a position of strength once the requirements phase gets underway. Past experience suggests that the initial phases of an implementation can set the tone of the relationship between the client and service provider, so it is critical that every effort is made to make this process as smooth as possible. If the client sees the TPA adopting a robust, repeatable process, this will engender more confidence. A confident client will be more receptive, and this in turn will result in a smoother onboarding experience for both parties.