Three challenges to be considered when migrating an Italian Transfer Agency service

1) The number of counterparties involved

The Transfer Agent system interfaces with numerous third parties: in addition to the Fund Accounting and Custodian Bank systems, it is important to remember the distribution networks (the number of which varies according to the fund placement model) and their IT outsourcers, which often transmit orders with proprietary connections which  may require ad hoc developments. Even where the  distributor adopts connectivity protocols aligned with the standards promoted by ABI (Association of Italian Banks), the additional information necessary for the management of specific servicesand the different releases, not always backward compatible, of the ABI standard path, must be considered. Then there are the Asset Manager systems to be fed with subscriber data and the suppliers who handle the printing and mailing of statements and letters to investors. Each counterpart adds additional complexity and interfaces to be developed.

2) The level of customisation of regulations (especially services)

Within the constraints outlined by the regulations, for Asset Managers there are several possibilities to make their mutual fund products unique.  Generally, in order to stand out in the market, this result is pursued by offering additional services. These include, for example, classic investment/redemption/switch plans and insurance coverage for the subscriber (with personalised maturities, amounts and frequency according to parameters linked to the subscriber or to market trends). Similarly, the commission model varies from fund to fund and often it is the result of rules and models “stratified” over the years. The result is a low level of standardisation of the Transfer Agency service, unlike, for example, other Fund Services such as Fund Accounting and Custody.

Consequences on migration? In the definition of the project plan and timing, it is necessary to foresee adequate time for the initial phase of analysis of the funds’ regulations, consistent with the need to keep the planned services active, at least for pre-existing clients. In this phase, both the Asset Manager and the incoming and outgoing service providers can complement their knowledge, which will allow a clear definition of the functional requirements to be implemented on the target system and the business processes in order to support operations.

3) The level of involvement and participation of the Transfer Agent

The transferring Transfer Agent has the widest visibility of all operational details (processes, active customisations with collectors, logic of the transferor system, manual interventions necessary for correct data processing, any historical misalignments, etc.).  A full involvement of the transferor is therefore a key success factor both for the definition of the implementations to be envisaged on the target system, and for the minimisation of the anomalies that may be found in daily operations (e.g.: in the interviews with collectors), downstream of the migration.

Before starting up the operational meetings, it is therefore necessary to have negotiated the support (resources, effort, costs, deliverables to be supplied etc.) requested from the outcoming Transfer Agent. These aspects are generally mentioned at a high level in the service contract, but require in-depth study depending on the most relevant aspects of the migration.

4) Historical Movements

In our experience, Transfer Agent migrations generally take place “by balances”. Access to the historical archive, necessary to provide continuity to ordinary operations, such as inheritances or requests from judicial bodies, is often guaranteed through access to the “old” system, which remains active for read-only consultation within the timeframe imposed by regulations (typically, 10 years after the closure of each relationship).

The eventual migration of historical movements introduces additional complexities, linked on the one hand to the volumes of data to be transferred, and on the other to the inevitable presence of data that is not always perfectly reliable, since it is the result of years of “stratified” operations, carried out under different regulatory regimes and potentially by different providers.

The management of these critical issues requires a significant effort (which is proportional to the historical depth of the data being migrated) for data cleaning activities. It is also worth remembering that any migration of historical data entails greater complexity in the negotiation of the terms of responsibility for the data itself: if the data remains on the original system, it is more simple to negotiate contractual support from the outgoing Transfer Agent (who has the deeper knowledge of the platform); if, on the other hand, historical data is migrated to the target system, it becomes more complex to obtain such support and there is a need to guarantee a reconciliation process that ensures data consistency between systems that may have different data aggregation logics.