Corporate Treasury Payment Service Provider Relationship Management

This call focused on one area of the information revolution – Payment Service Providers

(PSPs), but it was an illuminating insight into the challenges treasurers face. The multitude of payment methodologies and PSPs are forcing treasurers to deal with many different approaches, companies and formats. Today digital sales are mostly for B2C transactions, but this is spreading to B2B as business models evolve.

As treasuries move to APIs, bots and other less structured forms of communication, everyone will face the issues discussed in this report (the full 18 page report is available to premium subscribers – enquire here for details).

The biggest issues participants raised are:

• Ownership. Treasury clearly owns the relationship with traditional banks. But many treasurers find that marketing or other functions (notably IT) sign up the company for a PSP relationship, and then leave it for treasury to resolve the issues. Participants are beginning to lay down rules for approving new relationships, usually involving marketing and IT.
• Management system. One participant has a rigourous process which involves marketing, IT and treasury to make sure all aspects are covered.
• Local vs global. Some PSPs are global, while others are regional, or purely local. The purely local ones are usually left to local or regional teams to manage, while global ones are typically managed from HQ. In some cases, only local options are available: this is a challenge for centralised treasuries.
• Global PSPs. The main providers mentioned were PayPal, Ayden and WorldPay. No-one finds they can cover all markets.
• Reconciliation. PSPs typically provide files with the payment details for reconciliation purposes, but these do not necessarily feed directly into the ERP. As the transactions are digital, this process needs to be real time.
• Different standards. The reconciliation issues occur because each PSP has its own coding and file structure. This leaves participants to struggle with the challenge of building all the systems interfaces. It becomes particularly acute with some of the less frequently used locations: one participant has PSPs in Azerbaijan and Georgia. Their TMS provider intends to write the relevant interfaces, but it is not their top priority. This is the same challenge treasurers face with APIs – a big debate is starting about whether we should try to impose a single format (ISO 20022), or manage libraries of conversion software.
• Fintechs, banks. One participant has employed a fintech to manage the conversions. Generally, most have found that traditional banks are behind the curve. However, some banks, such as Citi, who had left the credit card business, are returning. Another participant uses a utility called BlackLine to manage the reconciliations.
• China. In China, people have tended to build interfaces to AliPay and WeChat pay, given their size and the fact it is difficult to do consumer business without them.
• Africa. E-wallets are increasingly popular – and very diversified  (The Mobile Payments Association identified 157 mobile money providers in sub-Saharan Africa) companies struggle to find suitable PSPs in some African countries.
• Virtual accounts. Several participants are using virtual accounts to ease the reconciliation process. This does not solve invoice level reconciliations, but it does help identify the PSP. Banks quoted include JPMorgan, Citibank and Standard Chartered for Africa.
• Fees. PSPs often deduct their fees from the payment, unlike credit card providers, who usually bill their fees separately. Again, this complicates the reconciliation process – especially as the fee levels vary widely, and the negotiating position can be weak, if the volumes are small.
• Counterparty risk. There is a delay between when the PSP collects from the end user customer, and when they pass the cash on. During this period, participants are exposed to the counterparty risk of the PSP, on whom they often have little to no financial information. Many are startups, so not the strongest credits.
• Buy Now, Pay Later (BNPL). This service is often provided by PSPs – this can complicate even further the management of counterparty risk.
• Business continuity. One participant does a thorough examination of PSPs, and is developing contingency plans in case they fail.
• Cash forecasting. The payment delay varies from one PSP to another, so it is difficult to know when the cash will come in.
• Numbers. There are many different PSPs, especially as many are purely local. This means the volume going through each PSP can be low – so it is even harder to justify the expense of setting up systems interfaces and management processes
• Refunds. When the customer returns the goods, a refund has to be triggered, and the related process set up.

Bottom line: what seems simple at first sight – the adoption of a new payment method – turns out to be a major technical and process development with risks we might not have thought of beforehand. And it takes us to the heart of a current dilemma in the industry: with the proliferation of different formats and protocols, should we try to standardise file structures, or go for general reformatting utilities? For the time being, these payment channels typically represent a relatively  small percentage of revenue – so the risk is manageable.

Welcome to the brave new world!