Coastline newsletter / 2012 edition

ISSUE 46 Oct2012

The Bank Payment Obligation – now a reality (Part 2)

Where we are today

By Gary Collyer

In the September 2012 newsletter the current status of the BPO and URBPO were discussed. This newsletter provides further detailed explanation of the process and messaging flows that occur at various stages of the BPO cycle.

To aid with the understanding of the five message flow examples, the URBPO Draft 2 offers the following definitions:

"Zero Mismatches" means that the data represented in an Established Baseline matches the data submitted in a corresponding Data Set; it may also refer to the matching of data in two initial Baseline submissions which causes the Baseline to be established (see Example 1 below).

"Data Match" means a comparison of a Data Set with an Established Baseline resulting in Zero Mismatches as specified in a Data Set Match Report; and

"Full Push Through Report" means a TSMT [Trade Services Management] message sent by a TMA [Transaction Matching Application] to each Involved Bank advising the current status of a proposed, established or amended Baseline.

It should be noted that in each example the message flows are not always complete. Additional messages, such as acknowledgements, are also generated by a Transaction Matching Application (TMA) to complement the overall workflow. For the purposes of these examples, however, these additional flows have been consciously omitted since they are not critical to the overall understanding.

Example 1: Baseline Establishment where the Buyer's Bank is the only Obligor Bank (zero mismatches)



1. The Buyer's Bank submits a Baseline to the Transaction Matching Application (TMA) consisting of the data supplied by the buyer. Within the Baseline, the Buyer's Bank will indicate that they are the Obligor Bank and give details of their undertaking (see the September newsletter for the data elements that make up the BPO segment of a Baseline).

2. The TMA generates a Full Push Through Report to the Recipient Bank.

3. The Recipient Bank submits its own version of the Baseline to the TMA, consisting of the data supplied by the seller or extracted from copies of documents submitted by the seller.

4. Provided both Baseline Submissions match, the Baseline is established.

5. The TMA confirms the Established Baseline by generating a Baseline Match Report containing zero mismatches and showing status 'established' to each of the Involved Banks.



Example 2: Baseline Establishment where the Buyer’s Bank is the only Obligor Bank (with mismatches)




1. The Buyer's Bank submits a Baseline to the TMA.

2. The TMA generates a Full Push Through Report to the Recipient Bank.

3. The Recipient Bank submits its own version of the Baseline to the TMA.

4. The TMA generates a Full Push Through Report to the Buyer's Bank.

5. The TMA then generates a Baseline Match Report containing mismatches to each of the Involved Banks.

6. A second baseline is to be submitted to correct the mismatches (if applicable). It may be that the mismatches are unavoidable and a re-submitted Baseline will not be appropriate i.e., the goods have been shipped late. In this event, the buyer will be required to give an acceptance of the mismatches. This acceptance will be subject to the agreement of the Obligor Bank in order to obligate them to pay or incur a deferred payment undertaking under their BPO.

7. Assuming that their initial Baseline was incorrect, a re-submission is made by the Recipient Bank (upon receipt of fresh data from the seller) and the TMA confirms the Established Baseline by sending a Baseline Match Report containing zero mismatches and showing status 'established' to each of the Involved Banks.

Note: In accordance with its own operating rules, a TMA will allow a limited number of attempts to be repeated until the two Submissions match and the Baseline can be established with zero mismatches.


Example 3: Baseline Amendment request and acceptance



1. In this example, the Buyer's Bank has requested an amendment to the Established Baseline by sending a Baseline Amendment Request to the TMA.

2. The TMA generates a Full Push Through Report containing the amended Baseline to the Recipient Bank.

3. The Recipient Bank accepts the amendment by sending an Amendment Acceptance message to the TMA.

4. The TMA generates an Amendment Acceptance Notification to the Buyer's Bank.


Example 4: Data Set Submission with zero mismatches



1. In this example, the Data Set submission from the Recipient Bank has resulted in zero mismatches of data following a comparison with the Established Baseline.

2. The TMA generates a Data Set Match Report to the Buyer's Bank and the Recipient Bank, confirming zero mismatches.


Example 5: Data Set Submission with mismatches accepted



1. In this example, the Data Set submission from the Recipient Bank has resulted in mismatches.

2. The TMA generates a Data Set Match Report with an indication of the mismatches, which is sent to the Buyer's Bank and the Recipient Bank.

3. The Buyer's Bank decides to accept the mismatches and sends a Mismatch Acceptance message to the TMA.

4. The TMA generates a Mismatch Acceptance Notification confirming acceptance of the mismatches.


In the final part of this newsletter, a selection of frequently asked questions raised by banks and corporates is provided:


Are there limitations to the data fields in the baselines supporting BPO? Of concern is the availability of data for compliance screening.

There is an incorrect perception in the market that BPO baseline messages are always very complex, while in fact the number of mandatory fields to complete a BPO is very limited. This does not prevent banks from including other data elements as and when required in order to satisfy e.g. regulatory compliance as the ISO 20022 message set underlying the BPO can represent most data elements found in documents associated with LCs.


How would a BPO prevent a fraudulent shipment?
The BPO does not of itself prevent fraud. Of course, banks will be required to carry out their standard KYC and due diligence checks for their customers before engaging in any transactions. However, banks submitting data are not required to validate the data they submit to the TMA but are only expected to ensure that the data received from their customer is the same as the data they submit.


Will the BPO be a good alternative for documentary collections as well? If yes, what about physical documents?
A documentary collection may be regarded as a more secure alternative for the seller compared to trading on open account, but less secure than a L/C. The BPO would be more secure than a documentary collection since there would be an obligation to pay. This obligation would be based upon the presentation of data through the banking system rather than physical documents. The underlying shipping documents would be sent directly to the buyer.


What exactly is agreed in the establishment of the baseline?
The buyer and seller need to agree on the use of the BPO, the payment terms and conditions, the banks involved and what data elements of the trade transaction are necessary in order to effect payment. They then instruct their banks to create the appropriate baselines. The enforceability of a BPO ultimately depends upon the matching of that data. The establishment of the baseline will determine exactly what data elements need to be matched in order for the BPO to be enforced. The baseline will normally include information extracted from the purchase order, details of the BPO (if any), payment terms and any other processing requirements.


Who decides the amount of data to be matched?
The amount of data to be matched is determined by mutual agreement between the buyer and the seller who instruct the involved banks.


If the buyer does not pay, who is responsible to pay the seller? Obligor Bank or Recipient Bank?
The only obligation arising from a BPO is that of the Obligor Bank to pay the Recipient Bank. The obligation of the Recipient Bank to pay the seller, as ultimate
beneficiary, will be covered in the underlying agreement between that bank and their customer.


What is the difference between a L/C and a BPO?
A L/C requires physical presentation of documents through the banking system. Under a BPO those physical documents will be sent directly from seller to buyer, as in an open account transaction. However, selected elements of data which have been extracted from the documents will be routed through the banking system for the purposes of automated matching in order to mitigate risk and to support the value proposition for a financial service e.g. pre-or post-shipment financing. It should also be noted that whereas a L/C represents a direct obligation between an issuing bank and the beneficiary, the BPO is a bank-to-bank obligation. The delivery of value to the beneficiary (seller) will be subject to the terms and conditions agreed with the BPO Recipient Bank.


Who has the final say for resolving a mismatch, the Buyer or the Bank?

In most cases the Buyer will have the final say to resolve a mismatch though they may delegate resolution of some mismatches to the bank.


Note: These questions and answers are a small sample of the FAQ documents that accompanied Draft 2 of the URBPO. For further information on the BPO, visit www.swift.com

 

 

Sign up to Newsletter