Mutually inclusive: Running Asia Pacific from a single infrastructure
Having an integrated regional operation is more advantageous than having great national siloes.
If you were to put together the greatest football team across Asia Pacific (APAC), you would not take the best player from each country and hope they bonded over breakfast. Football is a team sport, and teamwork is about a single vision. Standalone skill does not translate into optimal group performance.
Yet many financial services firms take a siloed approach to building operations across APAC. Banks set up the best local siloes they can, in each market, and expect them to collectively function as a single team. Instead, the lack of integration on the ground translates into greater management costs.
The flaws to this approach are obvious, for local banks building out into the wider region, and for global banks trying to step in and gain a foothold in APAC. Replicating cost and process across the many national markets offers little in the way of advantage over national operators, who can have a home market advantage, in depth knowledge, regulatory approval and established brand.
So why is the siloed model popular? It is borne of frustration, not optimisation. Its use stems from the considerable barriers that exist to developing a more mutualised infrastructure. The two biggest challenges that an organisation needs to overcome, if it is to succeed in creating a more common regional model, are the management of client data, and regulatory compliance / reporting.
The first issue, client data privacy, is an issue common to most regions, but APAC lacks the type of agreed standard approach that can be found in Europe and across the US. Regulators are often very unwilling to let people within the same organisation, let alone across different countries, see client data. As a result banks are driven towards client data segregation.
The second challenge, that of regulation, affects conduct of business and associated reporting for a regulator. The optimal situation, from an efficiency point of view, would be to enable a bank to capture all of the relevant data for reporting in a single instance, and then report that data across the different types of format necessary to different regulators.
There are other issues to consider. For example, handling multiple entities, currencies and instruments is often beyond the capabilities of a single instance of a back-office system. Equally, the segregation of onshore and offshore clients and how they are dealt with from a taxation point of view can impact regulatory reporting, with more regulatory reporting typically needed for onshore clients, than offshore clients.
A central repository of information, which then feeds out to multiple-regulators and enables multiple-reporting capabilities while supporting client data compliance would be ideal, and indeed is possible.
The first step to building a business into a team, is to consider which parts of an organisation’s middle and back office processes can be mutualised across the region, and what must stay in-country. To get economies of scale from housing infrastructure, a hub should be developed that captures as much activity as is possible.
To develop this mutualised back office across APAC, a firm must bring together client data from a number of different countries. That is subject to limits. Some countries operate very rigid national boundaries, for example, Malaysia will quickly penalise a business if it believes client data has been shared. As a result, client static data will need to be held in local databases for some countries.
Where it can be allowed, to overcome data privacy concerns when data is moved outside of a given function or country, data should be masked, so that only the people who are permissioned can see it. This requires that data can be easily moved in a contained way, which would be most viable if a single system were used to handle cross asset and cross currency post-trade processing.
Although older technology might use hardwired data architecture to set out the handling of trades, payments and associated processes, modular systems are now able to provide flexible service offerings as standard, so users can tailor which asset classes and currencies are handled, and build them out over time, as the business grows.
Taking a modular approach also reduces the need for banks to build application programming interfaces (APIs) to connect a web of disparate systems, and the problems associated with upgrading multiple systems simultaneously and risking some lagging behind.
If the infrastructure is to be housed in a single jurisdiction, the firm must have the appropriate skills and expertise in-house within that country, as well as the technology, to manage processing and reporting for other localities. That team will be responsible for tracking regulatory changes and making appropriate adjustments across the processing being handled within the infrastructure, and then build this into the systems themselves. In this respect, having a single instance of the platform can reduce the operational impact of regulatory change.
Whether a bank is changing to expand its presence, or to better manage cost for existing operations, it needs to take stock of the very real opportunity that a mutualised infrastructure presents. By bringing multiple components of the back office together, it is easier to automate parts of the transaction lifecycle, and to apply tools such as artificial intelligence when engaging very large data sets for tasks such as exception management.
Mutualisation also allows firms to optimise the qualities of the countries found within APAC, whether for skills, technical abilities, scale or cost. From a team perspective, it is playing the passing game, so players can help each other to score goals and beat the competition with less effort and more speed.