Bank payment obligation - where do we go from here?

Blog | 14 April 2016

john-bugeja

John Bugeja reviews how far the bank payment obligation has come and its relevance in a blockchain world

This discussion document is a follow-up to my article regarding the Bank Payment Obligation (BPO) entitled ‘A Split Personality?’ (April 2015). That wasn’t the original title: my working title had been ‘Game Changer or Red Herring?’ but this felt somewhat pejorative, which was not the impression I was seeking to convey. The abandoned working title did, however, sum up the dilemma facing the BPO quite succinctly.

The idea behind BPO ought to be embraced by the trade and supply chain finance community as it promises a paperless financing solution that offers a measure of risk mitigation. Moreover, focusing on cross-border trade, the BPO employs a ‘four-corner’ model familiar to trade financiers that eliminates some of the KYC and on-boarding challenges seen in the ‘three-corner’ model typical of current payables finance solutions. Adoption has, however, been stubbornly slow and there is a real danger that the BPO will be overtaken by events as more recent innovations in supply chain threaten to capture the imagination of trading companies and finance providers alike, rendering the BPO obsolete before it has gained any significant critical mass.

Should the BPO survive?

Before launching into a defence of the BPO, it is worth asking the question: ‘who cares?’ We need to be confident that the BPO has the potential to meet a real need and to deliver meaningful benefits to both trading parties and finance providers before we spend too much time trying to commercialise it. At this point, I should disclose that I am a member of the BPO Commercialisation Group so I am in the ‘develop it’ camp. I believe it has the potential to gain critical mass and am prepared to persevere with the developments I believe are required. The key point here, I believe, is that the BPO has to evolve (and quickly) if its potential is to be realised.

At the ICC Supply Chain Financing Summit in Singapore in March 2016, the BPO was discussed at some length in various panel sessions. Interestingly, the other hot topic discussed at the summit was blockchain, of which more later.

At the start of my panel session, I was asked what is inhibiting adoption of the BPO. I suggested that there were a number of factors impacting adoption. Recalling the words of a former boss when considering the merits of a business case for new product development, “I am not interested in your opinion”, I noted that business cases typically depend on evidence of client demand. A successful business case for the development of a new product invariably requires “the voice of the client”. Even a good business case, underpinned by evidence of demand and a commitment to delivering tangible business benefits, is not guaranteed to gain approval. In most banks, investment budgets are finite and proposals are prioritised based on criteria which typically play off benefits against cost/ease of implementation/risk/speed to market/strategic fit. A good business case can fail to ‘make the cut’ as mandatory and ‘keep the show on the road’ developments inevitably take top priority.

The reality is that there is currently no significant evidence of demand for BPO from corporates, so the next question is: “why not?” Is it that the BPO does not meet a genuine need or that the corporates are largely unaware of the potential BPO benefits? If the former were to be the case then the BPO would truly be a solution looking for a problem that doesn’t exist, in which case a rapid mercy killing would be in order.  I do not subscribe to this view, however, and believe the latter to be the case for a couple of reasons.

  • First, most banks have not told their clients about the BPO.
  • Second, and more significantly, the BPO does not exist in the corporate world. It is an interbank instrument not a product that corporates can buy.

As noted in my previous article, the BPO has been positioned in the bank-to-bank space and is explicitly not a product. This is a major inhibitor to corporate buy-in.

BPO as a transactional trade finance product

There was widespread support at the ICC Summit to the suggestion that the BPO in its current form should be repositioned as a transactional trade finance product, albeit one driven by data rather than paper. It is, in effect, a digital alternative to the traditional LC. It isn’t an LC replacement, but a complementary alternative that sits between the full blown LC and open account finance solutions. Since its inception this positioning has been strenuously avoided but I believe this is precisely where the BPO should now be positioned.

Many LCs are used by regular trading parties and are relatively straight forward, involving minimal documentation. The BPO would be a more efficient alternative which nevertheless provides a source of pre and post shipment finance similar to an LC. For companies currently trading on open account, the rationale for moving to a BPO is less obvious. Why might trading parties currently operating on open account switch to a transactional trade finance solution? There are a few possible reasons:

  • They might be uncomfortable with the level of risk mitigation available in the open account space, constraining their appetite for business growth.
  • They might be struggling to access open account finance to grow their business but do not need the protection and complexity of a traditional LC.

A buyer might be looking for extended payment terms which the seller cannot easily accommodate in terms of risk mitigation and finance.

The BPO is a viable solution in all of the above scenarios – provided it is positioned as a transactional trade finance product.

The fact that URBPO (the ICC rules governing the operating of the BPO) only covers the roles, rights and responsibilities of the issuing/obligor bank and the recipient bank, and excludes the corporate trading parties, is certainly unhelpful when it comes to positioning the BPO as a transactional trade finance product. This should be addressed in due course through an update to URBPO but this isn’t a quick solution. In the short/medium term we have to live with URBPO in its present form and find other ways to promote BPO adoption as a digital LC alternative. Education and communication are clearly key:

  • We need to change the language we use when we describe the BPO in case studies and promotional literature, emphasising the benefits relative to the LC and to open account finance solutions.
  • We need to promote a low cost approach to commencing proof of concept development so that banks can engage effectively with their clients. This is essential in order to establish demand to support a subsequent business case for investment in the automated solution.

As far as possible, in the absence of end to end rules covering corporates as well as banks, we need to try to standardise the agreements between corporates and banks, in order to provide a consistent product experience.

Given that any proof of concept requires the collaboration of two corporates and two banks, we need a BPO equivalent of a dating site to bring consenting parties together.

We are working with banks to help them to develop proof of concept business cases so that they can confidently engage with their clients knowing that, should the client express an interest, they can then execute a BPO albeit using manually entered data at this stage.

BPO and blockchain - together an SCF enabler?

I am convinced that the BPO could have a role as a transactional trade finance solution, but this is only part of the story. The bigger opportunity lies in the open account space though this requires something of a leap of faith and a commitment to innovation. This is where Blockchain might play a pivotal role.

What I am about to describe doesn’t yet exist, but I am aware that work is in progress in innovation labs to build this type of capability. Indeed, we at Trade Advisory Network are actively engaged in a number of such initiatives. The prime movers behind this are not necessarily the banks, however, as technology service providers and FinTechs appear to be taking the lead here.

In my earlier article, I suggested that BPO could be further developed to act as a default instrument, similar to a Standby LC or Credit Insurance. A claim under the BPO would be made in the event of default by the buyer. Since writing the earlier article Trade Advisory Network has engaged with banks, alternative finance providers/FinTechs, technology service providers and Blockchain specialists and have refined our thinking regarding the application of BPO as a default instrument supporting a ‘flow-based’ end-to-end SCF solution.

Getting back to first principles, most physical supply chains involve a minimum of three trading parties. Each trading party in a supply chain, other than the final consumer, is both a buyer and a seller. If the parties are trading on open account terms, the supply chain financing options available to them today are typically invoice based: seller-centric receivables finance and buyer-centric payables finance. Both are focused on the post-shipment phase of the trade cycle and, unlike transactional trade finance, neither provides a scalable financing solution for the pre-shipment phase. Both solutions are underpinned by credit appetite on the buyer (the source of repayment) which may be enhanced with credit insurance if required. In the case of receivables finance there remains an important element of performance risk on the seller which may be reflected in the recourse conditionality and/or the advance rate relative to the value of invoices assigned.

It seems clear that the current SCF proposition is quite limited in scope, which suggests that there is a gap in the market for end-to-end SCF, triggered by events in the physical supply chain starting with the purchase order.

We often talk about there being three interlinked supply chains:

  •  the physical supply chain;
  •  the financial supply chain; and
  • the information supply chain.

Events in the physical supply chain have financial consequences and each event generates data. Data from the physical supply chain drives financial interventions that address the financial consequences. Today, in the transactional trade finance world, this data is delivered in paper form. A viable end-to-end SCF solution will capture this data digitally and use it to calculate an ‘availability’ – a limit up to which the seller can draw funds in advance of settlement by the buyer.

If we think firstly about a domestic supply chain, with a single funder involved (i.e. a three-corner model) there is no need for a BPO, but it is worth examining this scenario before we overlay the complexity of a cross-border supply chain and a four-corner model.

There are two risks at play across a trade cycle – credit risk and performance risk. Credit risk may be defined as the ability of the buyer to pay for the goods (the ‘can’t pay’ risk). Performance risk relates to the ability of the seller to fulfil all aspects of the commercial contract resulting in the obligation of the buyer to pay (the ‘can pay, won’t pay’ risk). As each event in the physical supply chain takes place, performance risk reduces culminating in zero performance risk once the goods have been accepted and the invoice approved for payment by the buyer. This is the situation we see in the current payables finance programmes.

In order for a bank to finance the end-to-end supply chain, it would need data to tell it how much is outstanding at each stage. For the sake of simplicity, let us assume there are just four stages:

  • purchase order signed;
  • goods shipped;
  • invoice raised; and
  • invoice approved.

In practice there will be more. There will be a value outstanding at each stage which can be weighted to reflect the perceived performance risk at each stage. To illustrate, a bank might apply the following weightings:

  • 20% of the value of purchase orders outstanding;
  • 50% of the value of goods shipped;
  • 75% of the value of invoices raised;
  • 100% of the value of invoices approved.

By applying the weightings to the values outstanding, the bank will create an ‘availability’ against which the seller can draw funds as required. The ‘availability’ would change as goods move through the supply chain.

The quoted weightings are purely illustrative. The bank would have to determine the weightings based on their assessment of the seller’s performance track record and their ability to withstand non-payment due to non-performance. The nature of the goods will also be a factor. It will be appreciated that, if a seller fails to perform, the performance risk is crystallised and becomes credit risk on the seller at that point.

The data will need to be captured at source and then matched and stored in a secure environment to which all parties have visibility access. This is where Blockchain comes in. The irrefutability of evidence held in the Blockchain should eliminate uncertainty and avoid disputes – either the data matched, evidencing contractual performance, or it didn’t. If it did, the seller has fulfilled all contractual obligations and the buyer has a legal obligation to pay. If there is s failure to fulfil contractual terms this would be evidenced by a mismatch meaning the buyer has no obligation to pay and the funder will exercise rights of recourse to the seller. In practice, this would mean that the ‘availability’ would reduce.

As we are operating in the open account space, we have to think in terms of ‘flow’ rather than individual transactions. In essence, this is how invoice discounters think already. This is why the concept of ‘availability’ is, in my view, so important. This is a significant departure from traditional trade finance methodology and has more in common with the invoice discounters’ thought process and with the banks’ approach to borrowing base facilities.

Where a single bank cannot effectively evaluate both the performance risk on the seller and the credit risk on the buyer (e.g. in a cross-border scenario), we need two banks – one that has a relationship with the seller and one with the buyer. This is where the BPO comes in.

By definition, the seller’s bank will be the primary finance provider, at least prior to the approved payable being created at which point the advance could conceivably be refinanced by the buyer’s bank. If the data capture and storage via blockchain takes place as in the previous example, we have the basis for a collaborative solution. The BPO would be issued by the buyer’s bank in favour of the seller’s bank for an agreed percentage of the ‘availability’.  Let’s say 10% for the sake of simplicity. I see the SCF solution, involving the BPO, working as follows:

  • The seller’s bank would determine an ‘availability’ using the data captured from the physical supply chain and the agreed weightings.
  • The seller can draw up to the ‘availability’ as required.
  • Should the buyer fail to pay due to a data mismatch prior to the approved payable being created, the seller’s bank would exercise their right of recourse to the seller and reduce the ‘availability’ accordingly. If necessary, the bank might demand partial repayment of any funds drawn down by the seller to bring the exposure back within the reduced ‘availability’.
  • Should the buyer fail to pay despite all data having matched (evidencing full contractual performance by the seller) a claim under the BPO would automatically be triggered. The buyer’s bank would pay the seller’s bank the value outstanding subject to the BPO limit.

Clearly there is great deal more work to do to make this a viable proposition but hopefully the underlying principles can be seen to have merit.

I don’t believe that the challenges will be primarily technological, though as a non-techie, this is easy for me to say! I am reliably assured by those that are genuinely expert in the application of blockchain technology that the functionality upon which the above-mentioned process would depend is largely deliverable today.

The challenges would, however, be significant:

  • The BPO does not currently operate as a default instrument. The rules would need to be revised or, in the short term, every application would be an exception to URBPO.
  • The concept of performance risk and credit risk driving ‘availability’ based on weightings does not currently exist in bank credit policies.
  • The legal framework within which the recourse conditionality would operate would need to be developed.
  • The weightings themselves are a matter of judgement, which will be difficult given there currently is no past performance data to use as a benchmark.

Similarly, the acceptable level of BPO cover will be a source of debate between the various parties. Given that the the BPO, being a contingent obligation, consumes capital and generates a cost to the buyer, there will be pressure to make the value as small as possible, but this will be resisted by the seller and the seller’s bank.

We are working with blockchain specialists and banks/non-bank funders to develop a value proposition that delivers benefits to all parties – seller, buyer and funder.

Believe in better?

The biggest challenges will, I believe, be establishing that there is a real need for end-to-end SCF. To put this another way, we need to establish whether the current limited SCF offering actually constrains growth in global trade. If the availability of end-to-end SCF merely replaces existing funding sources without materially increasing appetite, reducing cost, enhancing risk mitigation or improving operational efficiency, there would be no business benefit and no business case. If, on the other hand, we can demonstrate that there is real benefit in developing an end-to-end SCF solution, then we are looking at a paradigm shift in the provision of working capital finance.

Further work is required here to evaluate potential benefit and prove demand.

Given the feedback from corporates at a recent SCF summit in Frankfurt, which was attended mainly by non-bank funders, technology service providers, fintechs and corporates (not banks) my impression is that there is latent demand for this type of solution. Non-bank funders see this as a way to intermediate in the financial supply chain. They see the potential to generate good returns from low risk assets and to extend the provision of finance to upstream suppliers (tier two, tier three etc.). Using the credit standing of the anchor party (usually towards the end of the supply chain) to support the provision of finance to suppliers much earlier in the supply chain would indeed enhance risk, reduce cost and increase appetite.

A final thought - why do we need Blockchain when we already have the SWIFT’s TSU (Trade Service Utility). Today, the BPO is inextricably associated with the TSU, though URBPO is actually platform agnostic, and in its application as a transactional trade finance product, this is probably still the best option. In its envisioned role as a default instrument supporting an end-to-end SCF programme, a bank-to-bank matching application is almost certainly not going to be acceptable to corporates or to non-bank funders. They would not want to be tied to a bank centric platform for the submission of physical supply chain data when a more accessible technology, blockchain, is available. Furthermore, TSU has limited data matching capability whereas blockchain should deliver much greater scope in terms of data elements and accessibility to all supply chain stakeholders, not just seller, buyer and funder. The funder doesn’t need to see or handle the data, just to know whether it has matched or not.

Perhaps the first step in the development of the BPO as an SCF enabler would be to decouple it from the TSU.

As stated at the outset, this is a discussion document intended to stimulate a reaction and hopeful move the development of digitised trade and supply chain finance forward a little. As always, feedback is invited.

John Bugeja is the co-founder of Trade Advisory Network with more than 40 years experience in senior leadership roles with HSBC, NatWest, RBS, Barclays, and Lloyds Banking Group. His TFR profile published in 2013 can be accessed here

Comments

Excellent article
Give Feedback