BPO in layman’s terms

The world of Trade Finance and Risk Management is often perceived as very complicated, this is mostly due to discussions around content, interpretations and the paper based document flows.

Fortunately the all-new Bank Payment Obligation (BPO) is a clear and simple instrument that works in a digital environment and can therefore be easily summarized as follows:

BPO is an irrevocable conditional payment obligation from one bank to another bank which becomes payable after an automated check and positive match of transaction data against the BPO conditions

So what is that BPO in more detail? First of all we have to look at the uniform rules of the game. Most of us know the standard rules of soccer or tennis; hence we can have competitions globally. The Bank Payment Obligation is also covered by global rules; the Uniform Rules for Bank Payment Obligations (URBPO). All the banks have adopted these International Chamber of Commerce (ICC) governed rules in May 2014, so the rules of the game are clear and fully agreed around the globe.

Due to the digital nature of the BPO, there is no room for rule interpretation. For instance no bank staff will be performing document examination; this means that the rulebook for BPO is a lot thinner and simpler, than those for the more traditional trade finance products (like the UCP 600 for L/C’s).

Having the rules in place is one thing, but this could only be achieved on the precondition of having a common digital language set for BPO messages between the banks. Here is where the Society for Worldwide Interbank Financial Telecommunication (SWIFT) played a crucial role in setting these standards. Banks use dedicated TMST (XML) messages for BPO that follow the ISO20022 standards, this will not only enable Straight Through Processing but also enable integration with client systems.

These many different TSMT messages flow between the banks, corporates will not have to create or even understand these XML messages themselves. The banks will communicate with the corporates via portals offering access to the transactions and potentially offering up/download functionalities or even integration with the corporate back office infrastructure.

Meanwhile, as per Q3 2014, already 58 banks have stated to adopt the Bank Payment Obligation to service their client base. It is expected that this number will continue to grow as more and more corporates become aware of this efficient tool for cross border trade and risk management.

BPO transaction example

So now we have the rules and the message standards covered, let’s look at the actual mechanism of the BPO transaction by means of a flow example. In this simplified case we represent the four most common parties is such a transaction as follows: A Dutch buyer and their Dutch bank on the import side and a Chinese seller and their Chinese bank on the export side performing a sight transaction. Basis being an underlying contract between buyer and seller, reflected in an agreed purchase order.

Dutch Importer Dutch Bank Matching Engine* Chinese Bank Chinese Exporter

* This matching engine can be the SWIFT Trade Services Utility matching application or any other proprietary transaction matching application.

Step 1: The Dutch buyer will request their Dutch Bank for a Bank Payment Obligation from the Dutch Bank towards the Chinese bank based on the Purchase Order and additional information.

Step 2: The Dutch bank will process this request and initiates the BPO process by sending a message to a BPO matching engine* where the data is stored  as basis for the future check of data once claimed. Thereafter the matching engine* sends a message to the Chinese Bank

Step 3: The Chinese bank will process the message and will contact the exporter to see if this transaction is indeed as expected.

Step 4: Once the Chinese exporter agrees, the Chinese bank informs the matching engine* which will then inform both banks that the BPO has been agreed and established. The seller now has the security that his bank will receive payment once correct performance data has been presented and the buyer knows payment is triggered by correct data only.

Step 5: Once the Chinese exporter has performed, transaction data will be presented (usually via the bank of the exporter) to the BPO matching engine* to trigger the respective payment The matching engine* automatically compares the transaction data against the stored BP0 data (In this example the data is correct) and the matching engine informs the banks

Step 6: The Dutch Bank will now effect payment to the Chinese Bank and debits the Dutch importer

Step 7: The Chinese bank receives payment from the Dutch bank and credits the Chinese Exporter