Optimising Payments through a Payments-on-behalf of Model

Published: November 01, 2013

Optimising Payments through a Payments-on-behalf of Model

by Gaetan Dumont, Senior Director, Group Treasury Operations, UCB

At UCB, we are committed to achieving the highest level of efficiency and control in our treasury activities, which included a centralised, harmonised approach to payments processing. We therefore made the decision to set up an innovative payment factory solution together with a streamlined banking structure that allows payments to be made on behalf of group companies. SunGard’s AvantGard Trax has played a pivotal role in automating our payment processes and standardising formats, both as part of the initial implementation in Europe and as the payment factory is rolled out globally. As a result, we have been able to achieve smarter operations around their payments processes as this article describes.

Centralising the payments process

In the past, we had in-country payment teams across UCB that were responsible for creating payment files from SAP in the relevant format and transmitting these to the bank, usually via a web-based electronic banking platform. Each team also retrieved MT940 messages (end of day bank statements) for reconciliation purposes. We recognised that maintaining payment teams in each country was not cost-effective, so we made the decision to outsource the payments process to a business process management company, with centralised teams in India and Romania.

Initially, we outsourced payments processes and the technology used to support them on an ‘as is’ basis. This meant that although personnel were physically located in the same place, therefore reducing the administrative overhead for business units, processes were still diverse and separate banking systems still needed to be maintained. Consequently, the advantages of centralised payments were relatively limited.

Harmonising the payments processes

We therefore made the decision to harmonise our payment processes, technology and formats by implementing a payment factory. As a small treasury team, we took a phased approach to implementation, starting first in Western Europe. The treasury team therefore appointed a partner bank for European payments to replace the variety of banking relationships that were previously maintained. Other banks will be appointed in the future to cover other regions.

Payments on behalf of (POBO)

The aim of our payment factory was both to enable treasury to centralise and harmonise our payments processing, but also to make payments on behalf of (POBO) group companies wherever appropriate to do so. This was to eliminate the need for business units to hold foreign currency accounts. By using a POBO model, only one account per currency would be required, from which payments would be made on behalf of all group companies, supported by an in-house bank to ensure the correct intercompany account postings. The bank would then provide information to the receiving entity as part of the remittance information to indicate the entity on whose behalf payment was made.

Implementing a POBO model is more difficult in some countries, such as France, so it is important to understand the regulations that apply, but where POBO is feasible, it can greatly enhance the efficacy of the payment factory. For example, we have been able to reduce the number of accounts and achieve far better visibility and control over cash. This approach was also acceptable to our suppliers who would receive cash from a different entity from the one they invoiced.

Payment factory infrastructure

We already had a single instance of SAP in place, from which payments would originate. Our payments solution needed to integrate with SAP but we decided that it would not be feasible to use SAP for all aspects of the payment factory for a variety of reasons. Firstly, we would have needed to implement the bank communication module (BCM) which would have resulted in additional cost and implementation effort, not least the version of SAP that we were using would need to be upgraded. Secondly, we were keen to implement a solution that was independent of either our banks or our core system vendor and therefore provided greater flexibility and versatility in the future. Consequently, we made the decision to implement a dedicated payment factory solution.

We reviewed various options for bank communication and ultimately selected SunGard’s AvantGard Trax solution. The solution supports the ISO 20022 PAIN version 3 message, which was our chosen global payments format, and can manage the information flows for a POBO model effectively.[[[PAGE]]]

Payment factory in practice

Fig 1
   Click image to enlarge

Our implementation has progressed significantly with 90,000 payments each year already managed through the payment factory from Western Europe alone. ISO 20022-formatted files are produced in SAP, which is integrated seamlessly with AvantGard Trax. One standardised file per country is then routed to the payments bank through a host-to-host connection. Once confirmation of successful payment has been received from the bank (payments status reporting or PSR’s) in AvantGard Trax, the system initiates automatically a flat file reflecting the internal account entries and passes these through to SAP, with payment orders created in the in-house cash module of SAP. Suppliers receive remittance information which indicates the originating entity in a structured format, so that payments received can be reconciled with outstanding invoices.

We are continuing to refine this process, focusing on the remittance information media that is additional information to that transmitted in the wire transfer.

Reduced transactional, banking and infrastructure costs

We were impressed by the quality of the implementation process and professionalism of the SunGard team which has contributed significantly to the success of the project. As the payment factory implementation continues to roll out across all regions, we have already realised cost benefits by reducing the resources required to process payments. Additionally, far less technical support is required now that multiple banking connections have been replaced with a single host-to-host channel and standardised formats. The solution is also more secure as offshore teams send payment files to a single, secure location.

We have also been in a position to reduce our banking fees. By working with a single payments bank in the region, we have been able to negotiate better conditions and reduced costs. We now have better visibility and control over outgoing cash flows in treasury which enables a more proactive approach to liquidity management. Furthermore, we have been able to leverage this project to migrate to SEPA payments.

Business units have also benefited considerably. They no longer need to deal with payment execution, manage bank relationships and technology or ensure SEPA compliance. Skills in these areas can now be concentrated in treasury, allowing business unit finance teams to concentrate on their core activities.

Looking ahead

We will now focus on rolling out the payment factory to regions such as United States, Central & Eastern Europe, Nordics and Asia. In some cases, the existing model will need to be adapted to regional requirements: for example, POBO is less common in the United States, but centralisation of payments still offers considerable value. As the number of payment banks increases, it is also likely that we will move from a host-to-host connection to SWIFT to allow bank-neutral, multi-bank communication through a single channel. Not only is AvantGard Trax an essential component of the current infrastructure, but it has a vital role in facilitating the global rollout of the payment factory. As files can be converted within the application, SAP does not need to be adapted to meet format requirements in each country, whilst still ensuring that files are transmitted to the bank in a standard format.

Sign up for free to read the full article

Article Last Updated: May 07, 2024

Related Content