Complex Data and M&A

One of the last things to be considered when merging entities post M&A is client tax reporting. I do not think it is intentional, it is just that the detail around this element of the business is usually not very well understood by those making the decisions around the wider strategy.

There are obvious attractions of acquiring a new book of business and increasing AUM - streamlining administration, activating economies of scale and increasing profits. Everyone wins and everyone is happy with the theory. But, as studies reveal, the average success rate is only 31%*.?When we consider the average cost of these transformations, that is a pretty poor return for firms in charge of growing client money.

There are so many layers to consider when merging firms after M&A.

1. Company cultures and values; these can be so different between entities and can really hinder a transformation project where a shared vision and common goal are vital across all functions.
2. Client profiles and investment types/models; e.g. investing in simple "vanilla" equities and funds versus non-reporting funds and deep discounted securities; the different asset types may have more or less maintenance from an operations perspective. If there are multiple technology solutions at play, the cross over between each asset universe may have an impact in terms of capability, so should factor in the target operating model (TOM) considerations.
3. Core client administration, custody, dealing and rebalancing technology. Even if both firms have the same system, it is unlikely to be the same version or even configuration. If selecting from existing relationships, a thorough review must be done to establish the core benefits and disadvantages with a risk factor applied to these. The data feeds from many custody platforms are inefficient, the differences in these available outputs and the support the vendor will provide for updates is a critical factor. We have been involved in some solutions where data outputs are described as plug and play. They were not. Ensure these possible issues are discovered early!
4. Additional reporting plug-ins (data sharing/integrations), tax systems or dealing systems for example. Different systems have different capabilities, weaknesses and strengths. Sometimes both entities have the same solution plugged in. In these scenarios, our common experience is that there is an assumption it is a case of lift and drop - with tax systems this is never the case! But also consider points 2 and 3 above as these can further impact the decisions. I personally had experience of this and had to migrate onto a LIVE version of software whilst changing the reporting structure and filling the gaps as the configuration of both versions was completely different. And if anyone had a mild heart attack thinking about migrating onto a live platform, do not worry - I had it under control and processed in stages hidden from users.
5. Most tax systems must recalculate all the positions again when the transactions land and, because they are configured and used differently, may not reconcile!! The migrated data landed and retained the correct tax history and costs (without taking full transactional history), but the live weekend highlighted a user-mapping/configuration issue that had processed incorrectly in the target system for decades. That took some unpicking and looked, without any context, as if the migration did not go very well!
6. Consultants. Always a contentious issue as we do consultancy too and there are some great ones out there. But no-one will know your business like the people doing the job. It is vital that the preliminary stages of requirement gathering and technology selection get the operations team view. Often, because the strategy discussions and decisions don't tend to involve those that do it, there may be some oversimplification of BAU process and checks. In addition, there may be scenarios or information not considered as they weren’t documented or captured during early engagement chats and there could be known issues with data. You get the picture. Ensure you have consultants with direct experience and expertise for the complex areas, even if just for a smaller assignment to check processes underway haven’t missed anything. We frequently get called in too late for tax implementations and data migrations because project teams have figured it is not that complicated and mapped it based on their understanding of the interface requirements. (And then we are in the predicament of making the best of it, as change control makes any updates to the interface build or mappings difficult to get sponsorship for as there are normally higher priority regulatory or customer facing issues to resolve).

So, what are the keys to a successful transformation? It will be variable depending on the firms and what they are trying to achieve but the following may help steer:

• Be curious. If you are using a firm to gather requirements and pick your software, question their process and understand it. Engage your operational team as early as possible - if you are not in a position to tell them transformation may be upon you, do it a different way - level up workshops, ask key persons to identify the top 10 challenges they face, ask them what does work and ask them what they would like to do to make their jobs more efficient. The team in general will not have enough information to make strategy decision, but the information they hold could really enhance your decision making and some of the replies may surprise you.
• Do not choose solutions based only on the usual metrics - everyone has it so it must be good. This is the leading provider so it must be good. Most technology provisions are competent but there some great solutions and technologies being built by people trying to modernise this industry and boy does it need it! Investigate them, technology will be the key to operational efficiency and resilience.
• Be sceptical of buzz words - my peeve at the moment is the focus on AI to do everything. I think AI and machine learning could be powerful for driving a user experience in a software, but only if the core data processing and storing is great. There is little point bolting this kind of technology onto systems that are decades old in design and have patchwork quilt pockets of features all stitched together! TIARA being a splendid example (shameless plug!)
• As mentioned above, if you do not have the technical expertise in house, get someone who does have it in. It is far better to spend extra now to ensure the implementation is right for you, than risking workarounds for BAU and increased risk for the reporting and increased expenses trying to fix it. I am thinking of tax but this applies to most operational areas.
• Ensure the target system is tested prior to migration. Really tested. This seems like a silly thing to say but you would be surprised how often it does not get tested enough. An amount of data should be migrated in, and then you should layer new transactions on top of this to test the end-to-end processing. At times, the test system is not end to end activated and each micro-area is tested in isolation, but not the downstream impacts or reporting... you need a great relationship with the software vendor and an overarching map/view of how it works. This and a great test manager can make all the difference.

There are likely lots more thoughts to be had on this, but I will leave it there in the hopes I haven't lost anyone wittering away!

*McKinsey & Company - Losing from day one: Why even successful transformations fall short