Many emerging Asian multinationals are “still managing their banking on a country-by-country basis,” says Victor Penna, Head of Regional Solutions & Advisory Team, Asia Pacific, at J.P.Morgan Treasury Services. “The challenge for them is how to go from a very decentralised structure, where they’ve got finance managers in each country managing their banking, to having a regional or global structure.”
Treasury: Why Asia's New MNCs Must Catch Up
In Part 3 of an interview he did with CFO Innovation’s Cesar Bacani, Penna discussed how Asian and Western MNCs are approaching treasury and cash management, the progress being made towards the standardisation of formats, and other developments that are making the corporate-banking relationship run more smoothly. Excerpts:
Let me ask you about treasury and cash management in emerging Asian multinationals compared with established MNCS. Are there differences?
We work with a lot of Asia-headquartered names and there are big differences. The first tier names are quite sophisticated and they’ve often set up similar structures to European and US organisations.
But there’s now a whole emerging group of Asian multinationals that are going global. Part of the challenge for them is they’ve built factories around the world, they have maybe made some acquisitions, but they don’t have a global treasury operation.
They do have a regional treasury centre, though, right?
Many don’t. Many are actually still managing their banking on a country-by-country basis. The challenge for them is how to go from a very decentralised structure where they’ve got finance managers in each country managing their banking to having a regional or global structure.
Let’s take the example of a global Asian corporation. I’m operating in 25 countries, and I really want to get to the point of operating a sophisticated global treasury centre, but I want to do it in one or two years, not the 10, 15, 20 years that it took European and US firms. And they don’t have a global ERP system. They don’t have a treasury management system.
If you look at the top European and US treasuries, they’ll have a global ERP system, and they’ll have quite an expensive treasury management system, and they’ll have all these feeds coming into the treasury management system.
A lot of Asian corporations will say, ‘No, I don’t want to do that, but I want you to give me a similar level of information and visibility.’ So we would give them our global liquidity portal. They can look at their cash positions all around the world using a module that we provide on our internet banking system. This gives them a lot of treasury management-type functionality without having a treasury management system in place.
Will they need to bank only with J.P. Morgan in every country to get that level of information and visibility?
If they have all their accounts with J.P. Morgan, the key advantage is they get real-time information. If they’re with a third party bank, then we can take a feed of that data but they’re relying on that bank data coming in on time. But they will still get a view of all of their balances through a comprehensive dashboard format.
If you’re a global treasurer, you can see exactly how much liquidity you’ve got in different accounts around the world, and then you can start to move your excess liquidity and redeploy it to achieve greater efficiencies.
You get what a treasury system delivers to you, without having to spend a significant amount of money on the treasury management system, hardware and integration, and you get it very quickly.
Is this a make-do solution or can companies actually do treasury and cash management using just this portal?
If you want to start to do complex foreign exchange netting, you will need a treasury management system.
If your needs are relatively straight forward, you can get 80% of your treasury and cash management work done through some of the tools that the bank can provide. And once you’ve got control of the basics – I can see my cash, I can control my cash, I can consolidate my cash, and therefore I can redeploy that excess cash to pay down debt or to help grow my company – you’re really achieving one of the most important things as a treasurer.
That might be enough, or you might say, ‘Well, I actually now need to do FX netting, and I need a system to track my exposures, I need a system to manage my commodity risk. I can’t do that without a good treasury management system, so I might have to invest in one.’
Or you might say, ‘My hedging strategies are pretty basic, so long as I can forecast my different exposures at a macro level, and I hedge 80% of the risk, I’m happy. So I don’t need an FX netting system. I don’t need a treasury management system. I’ve got the liquidity management running well on the bank system and I can manage my FX exposures at a macro level which I’m happy with.’ So it really comes down to what level you want to operate at.
The downside is just the risk management of it, because if your banking partner disappears like Lehman Brothers did, you’re dead.
That’s why most clients have to balance counterparty risk diversification with dealing with one bank. Most treasurers are pretty smart these days. They’re really looking to have a group of banks they work with, and usually within that group, there are two or three that they work most closely with.
Let’s talk about the issue of different codes and formats used by banks in various jurisdictions. Are we coming to a point where everything is standardised?
It’s getting closer, but even every bank’s MT940, for example, is slightly different. The overall format might be the same, but the content at the reference level might be a little bit different. Even if you look at XML standards like ISO 20022, each bank’s version is slightly different, though most banks are moving from Version 2 to Version 3, which is supposed to be more standardised.
There’s always some variation at the bank level, purely because different banks can produce different levels of information. Some banks will have their own restrictions on how much reference data can be passed through into a payment file or into a bank statement. Some banks may receive X and then they cut it down to Y; whereas some banks can receive X and pass on X. So it’s these variations that often come down to the systems that banks are running.
Where are Asia’s banks now in terms of standardisation?
In terms of taking files from their corporate clients, many banks are still supporting their own proprietary formats, but there is a move towards adopting industry standards like ISO 20022.
Whilst standardization in Asia has not reached the pace and intensity of Europe, it is beginning to move in a similar direction as banks respond to demand from clients, industry initiatives from SWIFT, and more importantly, the adoption of industry standards like ISO 20022 message formats by local financial regulators.
However, one of the challenges in Asia is that different countries are using different standards for similar high value payments in each country. So you’ve got China with its own proprietary CNAPS [China National Advanced Payment System] standard; you’ve got Japan and Korea with their own proprietary standards. On the other hand, Hong Kong, Singapore and Australia all use SWIFT-based standards. Hence, banks coming out of these markets may be used to supporting different standards or formats.
But even at this level, things are changing. China for example is looking potentially to adopt SWIFT standards for local payments, so it is moving towards more standardisation. But there’s still quite a long way to go.
What about XML? Isn’t that supposed to be the overarching standard?
ISO 20022 XML is supposed to be the overarching standard for host-to-host transmission between banks and corporates. However, with any initiative around standardization, it takes time to mature. Some of the teething issues are now being addressed with Version 3 of ISO 20022 XML, which includes a common set of implementation standards.
Of course this standard is for corporates, not necessarily bank-to-bank, where the most predominant standard is still SWIFT and the SWIFT series.
But XML is consistent with SWIFT, right?
In fact SWIFT drafted the original specifications for ISO 20022 XML as part of the ISO working group and continues to promote XML in industry events. SWIFT is also a significant contributor to the message definitions within the standard.
It’s also consistent in the sense that the XML message carries the information that the bank can then use to move payments via SWIFT or other clearing systems. The corporate client sends the file to us in ISO 20022 XML format, we translate it into the appropriate SWIFT message or local clearing format, and then send to other banks. But that’s all behind the scenes as far as the client is concerned.
If the client sends it to you in SWIFT format, there’s no need to translate, it just goes straight through?
In order for the client to send their messages in SWIFT format, they must first be a member of SWIFT. Even though the client may be sending SWIFT messages to the bank, there is still a level of translation required, but it’s pretty straightforward.
What if it’s CNAPS?
CNAPS is used internally in China. If somebody wants to execute a payment in China, they can still send it to us in a standard format, then we translate it into the CNAPS format and send it via the CNAPS system.
How difficult is it to translate those files?
For banks that have invested in the infrastructure, we can get the file and then translate it into the right payment format for each clearing system. But there is a fair amount of upfront effort working with clients to set up host-to-host links and file formats.
J.P. Morgan supports many different standards, so we’re happy to receive files in different formats. For example, we can take it in IDoc format, which is the SAP file standard format, or they can drop it down to us in a flat file format or in the ISO XML format. There’s really a lot of flexibility for the client.
So in theory there’s actually no need for standardisation because banks like J.P. Morgan can automatically translate the different formats?
Yes, we overcome the issue of different payment formats in different countries by enabling the corporate to send us all their payments to us in one standard format and then we take care of the rest. This can be via SWIFT for corporates, ISO 20022 XML or various other formats.
When you’re looking at SWIFT for corporates, for example, it’s most appropriate when a client is dealing with multiple banks. It’s more efficient and makes more sense to have one SWIFT pipe and allow SWIFT to route the transactions out to the different banks.
But if you’re predominantly using one bank in the region, it may make more sense to use that bank’s host-to-host connectivity and formats.