A Virtual Approach to Treasury & Payments Centralisation
by Yann Guengant, Assistant Group Treasurer, Pierre Fabre Laboratories
Pierre Fabre’s Group Treasury is made up of five people, who manage the treasury requirements for France, which includes both the holding company and 40 subsidiaries. The company is also present in a further 35 countries which have not historically been covered by Group Treasury.
Project objectives
We recognised that our decentralised approach to treasury and cash management made it difficult to apply consistent policies and procedures globally, which in turn restricted our visibility and control over cash, cash management efficiency and ability to monitor and manage risk proactively. We therefore made the decision to centralise and standardise our approach to treasury and cash management at a global level. This comprised two key objectives:
Firstly, to establish a global centre for treasury and cash management and optimise treasury operations. Our aim is to accelerate the velocity of the cash by extending the reach of treasury so that although in-country finance teams will continue to perform local payments and collections within a global framework, other financial activities such as cash management, FX, interest rate and counterparty risk management, trade finance, financing and investment, will be conducted directly by Global Treasury.
Secondly, to leverage SWIFTNet to achieve standardised connectivity between our entities and the banks, essentially creating a virtual payment factory. We made the decision not to relocate our finance teams into a central shared service centre as we recognised that we could leverage our existing physical infrastructure and use technology in a way that permits our people to spend time on value-added functions versus transactional ones. One important aspect of this was to rationalise the number of banking partners and standardise financial messaging using international financial message formats, such as SEPA Credit Transfers for mass payments (vendor payments and payroll) in the European Economic Area, and XML ISO 20022 for mass payments outside Europe.
Having fully centralised our treasury activities across our entities in France, the centralisation project is now under way for our 70 overseas subsidiaries.
Treasury technology
Before embarking on our transformation project, our treasury technology framework was relatively fragmented. We have now centralised our treasury systems infrastructure to reduce the number of systems and data silos currently in operation and leverage the standardisation that SWIFT offers. In treasury, we use Reuters’ Kondor for transaction processing and cash management. We work with seven banks in France with which we used to communicate through ETEBAC before implementing SWIFT. Outside France, we have a multitude of different systems and means of communication in place at a local level, including fax, email, electronic banking and a plethora of spreadsheets. Without a standardised approach to technology, it is difficult to implement and monitor global treasury policies and processes, to manage risk, to strengthen security or to leverage shared investments in technology.By rationalising and standardising our technology and communication infrastructure, our people will be able to spend time analysing rather than inputting information in order to make better and faster decisions.
An important element in achieving this objective was to implement a central systems infrastructure to enable consistent processes across the company and to facilitate a global approach to reporting and real-time information-sharing. We have therefore implemented a third-party system which will act as the internal communication highway for connecting the various applications across the group. Information is then consolidated within the system and consolidated files are transmitted through to HSBC. HSBC then sends the relevant messages to the appropriate banks.
The decision for SWIFT
We looked at various connectivity solutions for communicating with our banks to assess geographic range, range of services, support for XML-based standards and protocols. We included our banks’ proprietary web-based electronic banking and host-to-host systems in this analysis. We quickly recognised that proprietary electronic banking tools would not support our requirements; not only are they inconsistent in their formats and security protocols, but we would need to replicate our systems infrastructure across each of our 60 banks. Similarly, there were limitations with host-to-host systems as again, they were proprietary and were not standardised; furthermore, as they would be ‘hard coded’ into our business, our ability to flex our banking relationships in the future would be compromised.
While ETEBAC had served our cash management needs in France, its coverage extended only across France and Germany so it was not a viable global solution for us. In contrast, we recognised that SWIFT was a global solution with a growing range of services available. SWIFT both provides a communication network (SWIFTNet) and acts as a standards body, so it is in a position to drive standardisation and international adoption of common formats. The security provided through SWIFTNet is best in class and provides users with significant protection through authentication, non-repudiation and message delivery guarantees. [[[PAGE]]]
Connecting to SWIFT
We had the option to connect to SWIFTNet directly i.e., to manage our own infrastructure, or indirectly by outsourcing this to a third party: this would effectively mean that we could share the cost of setting up and maintaining the necessary infrastructure with other users. We reviewed the total cost of ownership of SWIFT based on both models but quickly recognised that the cost and effort required to achieve direct connectivity would be prohibitive. As the value of SWIFT to Pierre Fabre is not the technical infrastructure but the management of data through the network, ultimately, the decision to outsource was not a difficult one.
We reviewed different service bureaus that could manage the SWIFT technical infrastructure on our behalf. The key to selecting the right service bureau was to ensure that our connection to SWIFT would be no weaker than SWIFT itself, so we were sure to check potential service bureaus’ availability, security, resilience, service level agreement and financial standing. Most were small software companies, which led to some concerns about the impact on our activities if their business were to fail. We decided that we would have greater leverage as well as more confidence in business continuity if we selected a service bureau supported by a bank. There are clearly some potential issues with this approach too: after all, we were looking for a service bureau to act as a processor in sending and receiving information to and from multiple banks globally, and we did not want these bank relationships to be compromised. Consequently, there needed to be some Chinese walls between the activities of the service bureau and the bank as a whole.
Based on our analysis, we made the decision to contract with HSBC for service bureau services. The service is delivered by a third party, but the support of a banking partner with the financial standing of HSBC gave us considerable confidence in the continuity and integrity of the service. HSBC is a member of our revolving credit facility, and provides cash management services in the UK, Mexico and Czech Republic, as well as in France. We had confidence in our long-term relationship with HSBC and as we roll out our centralisation project and rationalise our banking partners, we will aim to concentrate our services with banks such as HSBC that are at the forefront of cash management.
Progress to date
We are currently in the final stages of testing and going live on our new infrastructure in France, both for treasury and the virtual payments factory. During the second half of the year, we will move onto the second phase of the project, which will be a two-year roll-out of centralised treasury and our virtual payments factory across the business globally. This will start in mainland Europe, then move into developing countries and finally, our most challenging countries.
Addressing the challenges
Although our intention was to standardise financial messaging as far as possible at a global level, there remain exceptions due to each country’s financial, technical and cultural diversity. Even within the Eurozone, we have found that in some countries, SEPA Credit Transfers are being adapted to meet local needs in terms of how fields are used. However, while there were some technical challenges to resolve, technology was only one element of our project, with financial flows, policy and procedures, reporting and data management and people all impacted. A project of this type has a large number of participants: banks; service bureau; specialist software application vendors; ERP vendors; subsidiaries; senior management; regulators; tax, legal and finance departments etc. Consequently, co-ordinating, communicating and delivering our wider objectives, value proposition and migration path was more complex and challenging than resolving the technical inconsistencies that arose; for example, agreeing an approach to policies and processes that could be implemented globally, and establishing a migration path.
Achieving internal standardisation
Although there needs to be some flexibility when rolling out new business arrangements across the company, there cannot be scope left for local interpretation or the benefits of standardisation are lost. For example, while we enable subsidiaries to select their local banking partner, the decision needs to be made within the terms of our global framework, so a partner bank can meet SWIFT connectivity and XML-based standards, as well as credit rating criteria. In turn, this will result in a reduced number of banking partners and therefore less complexity in our banking relationships.
To achieve the right degree of standardisation whilst ensuring local buy-in, we needed to construct policies and procedures carefully, communicate regularly, and obtain senior level sponsorship for the project. There is a great deal of resourcing required to conduct these tasks successfully, with a very clear vision of the end result and a strong commitment to achieving it. After all, we were not implementing our treasury transformation and SWIFT connectivity for the sake of it, we had a compelling business reason for doing so that we needed to keep in mind throughout. Furthermore, it was also important to make use of skills within the company, such as change management. We needed a clear governance structure, the right level of sponsorship, a disciplined approach to project management, and a clear budget and cost benefit analysis. It was therefore important to leverage the experience and expertise that we had in the company to ensure the right approach in these areas.[[[PAGE]]]
A successful change management programme
Ultimately, the scale and range of factors involved in delivering this type of project means that it effectively needs to be considered as more of a programme than a discrete project. For Pierre Fabre, the experience has proved positive both in terms of the degree of centralisation, control, transparency and efficiency that we were seeking, but also in cementing a positive relationship between headquarters and our subsidiaries. In the future, we will extend our use of SWIFT from cash management to trade finance, as we have a large volume of performance bonds that we would like to automate. Furthermore, while we are currently performing FX transactions and confirmations manually today, we will seek to automate the end-to-end process in the future.
This article appears in the HSBC Corporate Connectivity Guide version 3, published by HSBC in October 2010.