751E - Guide To URBPO - EBOOK

THE ICC GUIDE
to the Uniform Rules for

Bank Payment Obligations
ICC GUIDE ■ ICC GUIDE ■ ICC GUIDE ■ ICC GUIDE ■ ICC GUIDE ■ ICC
GUIDE ■ ICC GUIDE ■ ICC GUIDE ■ ICC GUIDE ■ ICC GUIDE ■ ICC GU
by David J. Hennah
THE ICC GUIDE
by David J. Hennah
The ICC Guide to the Uniform Rules
for Bank Payment Obligations
Copyright © 2013
International Chamber of Commerce (ICC)
All rights reserved.
ICC holds all copyright and other intellectual property rights in this
work. No part of this work may be reproduced, distributed,
transmitted, translated or adapted in any form or by any means,
except as permitted by law, without the written permission of ICC.
Permission can be requested from ICC through [email protected].
ICC Services
Publications Department
38 Cours Albert 1er
75008 Paris
France
ICC Publication No. 751E
ISBN: 978-92-842-0191-4
Acknowledgements/Disclaimer
The author would like to thank those companies, banks,
other institutions and individuals who have given their
advice and support in the creation of this book.
While every care has been taken to ensure the accuracy
of this work, no responsibility for any loss occasioned to
any person or company acting or refraining from action
as a result of any statement made therein can be
accepted by the author or the publisher.
Special thanks
Special thanks to all those people who have persevered
in the long and arduous process of making the Bank
Payment Obligation a reality. With apologies to those
not mentioned here, they include: Doris Braun, John
Bugeja, Neil Chantry, Chris Conn, Gary Collyer, Mary De
Tuerk, Jose Carlos Guedes, Hank Hsu, Daisuke Kamai,
Michael Kang, Urs Kern, Jana Kies, Michelle Knowles,
Patrick Krekels, Ashutosh Kumar, Sara Joyce, Nadine
Louis, Alexander Malaket, Manoj Menon, David Meynell,
Robert Marchal, Murray McGuire, Evy Passa, Shin
Mizutani, Thiago Fernandes Nascimento, Mike Quinn,
Harriette Resnick, Lakshmanan Sankaran, Jay Singh,
Tan Kah-Chye, Sanjay Tandon, Dan Taylor, Peter Tijou,
Sharyn Trainor, David Vermylen, Hugo Verschoeren,
Suwatchai Visanvit, Wang Guosheng, Alan Wong and
Xiong Yuanmeng.
Dedication
For Miriam, Tamsin, Jeni, Kerenza and Serena
INTERNATIONAL CHAMBER OF COMMERCE (ICC) | 3

About the Author
David Hennah is an Associate of the Institute of Financial

Services, formerly the Chartered Institute of Bankers. He
has considerable expertise, accumulated over many
years, in transaction banking, software services, financial
services marketing and business consultancy and has a
track record of driving change through the innovative
use of new technology to deliver business benefit. He
has previously lived in France, Belgium and Germany, as
well as in the UK, and has worked for Barclays Bank,
ICL/Fujitsu Services, Misys Banking Systems and SWIFT.
At SWIFT, David held a key role in bringing the Bank
Payment Obligation to market and was a member of the
ICC Drafting Group that worked on version 1.0 of the
Uniform Rules for Bank Payment Obligations (URBPO).
He is a well-known chairperson, speaker and moderator
at trade and industry events worldwide. He is also the
author of numerous articles, often related to product
innovation and the use of technology in international
payments and cash management, trade and supply
chain finance. He is a regular contributor to Trade and
Forfaiting Review.
David is Managing Director of Hennah FSC Advisory
(http://hennahfscadvisory.co.uk), whose clients include
the International Chamber of Commerce, Demica and
Wilmington Publishing & Information Limited, while also
working in close collaboration with Trade Finance
Associates (www.www.tradefinanceassociates.com) and
advising International Financial Bridge. David may be
contacted directly at [email protected] or
alternatively at [email protected].
4 | INTERNATIONAL CHAMBER OF COMMERCE (ICC)

Foreword
The trade finance industry has often been subject to

criticism for using outdated platforms and processes.
Industry initiatives that are designed to simplify
transaction processing and bring the business of trade
finance into the 21st century are to be welcomed by
bankers and corporates alike. The Bank Payment
Obligation (BPO) is a great example of one such
initiative.
As an instrument of trade finance, the BPO is similar in
nature to a documentary letter of credit. Simply put, it is
an irrevocable undertaking given by one bank to another
bank that payment will be made on a specified date
after the successful matching of electronic data. The key
difference here is that the BPO works in an environment
that is totally automated, relying on the comparison and
matching of structured messages as opposed to the
physical examination of paper documents. The ability to
process trade data in this way represents a significant
leap forward in terms of industry efficiency.
A landmark agreement signed in 2011 between the
International Chamber of Commerce (ICC) Banking
Commission and SWIFT has paved the way for the ICC
to assume responsibility for the rules governing the BPO.
The importance of this change cannot be understated.
Not only will the BPO benefit from the established role
and reputation that the ICC has in managing industry
rules, but it will also obtain a globally accepted dispute
resolution capability, building on the solid foundations
that have already been laid. The Uniform Rules for Bank
Payment Obligations (URBPO) will underpin the future
strength and standing of the BPO in international trade.
Over time, these rules may eventually help to elevate the
Bank Payment Obligation to a status similar to that
enjoyed for decades by the documentary letter of credit.
There are two important aspects of the URBPO to be
noted here. The first is that they are technology neutral.
This means that the rules can be applied to any BPO
transaction, regardless of the underlying Transaction

Matching Application or service provider used for the
exchange of BPO-related data. The second is that the
rules rely upon mandatory compliance with ISO 20022
messaging standards. This means that the data itself
must always be presented consistently and in
accordance with established industry requirements.
There can be no doubt that the establishment of the
Bank Payment Obligation as an accepted market
practice has been significantly enhanced as a result of
the transfer of governance to the ICC. The next step is
for the market to embrace this new way of doing
business and to adapt established processes and
procedures accordingly. At a time of restricted risk
management and lending practices, transaction bankers
have an open opportunity and responsibility to guide
their corporate clients to take advantage of new
developments in best practice, such as those
engendered by the introduction of the Bank Payment
Obligation. Education and communication are of vital
importance in assuring successful adoption. Works such
as this Guide to the URBPO will help to extend
knowledge, awareness and understanding as we look
forward to the continued evolution of a next generation
of financial supply chain solutions.
Gary Collyer
Chair, ICC BPO Rules Drafting Group

If I had my life to live over again,
I would elect to be a trader of goods
rather than a student of science.

– Albert Einstein

Introduction
The letter of credit is a creation of commerce. There are

those who believe that its origins date back to ancient
Babylon in the year 3000 B.C. Indeed, a clay promissory
note of that era is exhibited in the University Museum of
Philadelphia and bears an inscription providing for the
repayment of a specified amount plus interest on a
specific date.
It is widely believed that the development of letters of
credit in Europe was inspired by the discoveries of
Marco Polo in China in the 13th century. By the 17th
century letters of credit were in common use both on
the European continent and in England, and by the 19th
century British banks had a virtual monopoly on the
issuance of letters of credit, owing to the pre-eminence
of both the pound sterling and the grand reputation of
the bankers of London in furthering the field of
international finance.
The outbreak of World War I severed many of the
trusted trading links that had become well established
between merchants worldwide. In 1919 the International
Chamber of Commerce was created to help facilitate the
flow of trade at a time when nationalism and
protectionism had taken hold.
Since 1933 the universal usage of lex mercatoria has
been supplemented by a set of rules aimed at
establishing uniformity of practice. Now in its sixth
revision, the Uniform Customs and Practice for
Documentary Credits (UCP 600) remains the most
successful set of private rules ever developed for trade.
At the start of the 21st century, we are faced with an
inexorable flow of more and more trade across borders.
At the same time, we are embarking on a new chapter in
the history of trade and trade finance. Whatever walk of
life we may pursue, whatever business interests we may
have, our daily existence cannot fail to have been
touched by the irresistible tidal wave of new technology.
When applied to positive effect, technology can both
form and change culture. The exploitation of new

technology enables us to pursue our business goals and
objectives through the application of science.
Today, thanks to the power of new technology, we are
facing a paradigm shift in the processing of trade
instruments. The demand to mitigate risk is now
complemented by an even stronger demand for systems
and services that are both smart and simple. Corporates
regard clear visibility into their supply chains as key to
the unlocking of trapped cash. Technology can be
deployed to deliver detailed insights into day-to-day
dealings and enable the leveraging of information flows
to support the movement of goods and money.
Unlike the letter of credit, the Bank Payment Obligation
(BPO) is the brainchild of bankers. It has variously been
described as a “game changer” and a “creative vision of
the future”.
To interpret a BPO as merely an electronic or “lite” letter
of credit is an injustice. Nevertheless, the simplest
definition of a BPO does rely upon a direct comparison
to the letter of credit.
Whereas the letter of credit places an obligation on the
issuing bank to pay subject to the physical presentation
of compliant documents, the BPO places a similar
obligation on the issuing bank (the Obligor Bank) to pay
subject to the electronic presentation of compliant data.
The execution of a BPO-based transaction relies in
practice upon the consistent interaction of three
components. The first is a set of structured messages to
support the exchange of data in accordance with
predefined standards. The second is a platform to
support the matching of the data in accordance with a
predefined workflow. The third is a set of rules to
support uniformity of practice and thus promote
universal adoption, just as the UCP has successfully
supported uniformity of practice in the universal
adoption of documentary letters of credit.
Every student of trade finance will know that the term
“letter of credit” is derived from the Latin accreditivus,
meaning “a power to do something”. The Bank Payment
Obligation empowers us to take the business of trade
finance to another level and to give birth to a whole new
tradition for the next generation of trade financiers.
In this book, we will closely examine the above-
mentioned three components of standards, platform
and rules. We will look at the ways in which these three
components must interact and complement one another

in order to facilitate the successful completion of a BPO
transaction. We will discuss workflow and provide some
examples of how a Bank Payment Obligation may be
applied in practice to support a variety of value
propositions such as pre-shipment and post-shipment
finance. As such, this work is designed not only to guide
practitioners in their interpretation of the Uniform Rules
for Bank Payment Obligations but also to provide
substance to the practical application of the BPO in the
context of real life business scenarios.
David Hennah
Burnham, Bucks
April 2013

Contents
LIST OF FIGURES.. . . ...................................................................................... 16
LIST OF TABLES. . . . . ...................................................................................... 20
LIST OF FLOW DIAGRAMS.......................................................................... 21
CHAPTER 1
What is a Bank Payment Obligation?.. ........................................... 23
1.1 What is a Baseline?.......................................................................... 24
1.2 Why do we need a BPO?............................................................... 25
1.3 Addressing inefficiencies in the financial supply chain........... 27
1.4 Optimisation of working capital................................................... 29
1.5 Payment assurance.. ........................................................................ 29
1.6 Enhanced process efficiency.. ....................................................... 30
1.7 Reduced risk of discrepancies...................................................... 30
1.8 Mitigating the risk of supplier default.. ........................................ 31
1.9 Strengthening buyer/supplier relationships.............................. 31
1.10 Growing the supplier network...................................................... 31
1.11 Integrated technology based on global

messaging standards...................................................................... 32
1.12 Flexible forms of financing............................................................ 33
1.13 “Silent” BPOs. . ................................................................................... 33
1.14 Summary of the main financing opportunities

using the BPO................................................................................... 34
1.14.1 Basic financing options................................................. 34
1.14.2 Adapting the due date of the BPO. . ........................... 35
1.14.3 Delaying the establishment of the BPO.................... 36
1.14.4 Using the TMA “pre-match” facility to create the
BPO later.. ......................................................................... 37
1.15 Accounting Policy for BPOs.......................................................... 38

1.16 Capital Treatment for BPOs. . ......................................................... 40
1.16.1 Probability of Default..................................................... 40
1.16.2 Loss Given Default.......................................................... 40
1.16.3 Effective Maturity.. .......................................................... 40
1.16.4 Leverage........................................................................... 40
CHAPTER 2
The ISO 20022 TSMT messages.. ...................................................... 42
2.1 What is ISO?. . .................................................................................... 42
2.2 What is ISO 20022?......................................................................... 43
2.3 What is ISO 20022 TSMT?.. ............................................................ 44
2.4 The ISO 20022 TSMT messages................................................... 44
CHAPTER 3
The Transaction Matching Application.......................................... 55
3.1 TMA Subscription............................................................................ 56
3.2 TMA Roles.. . . . . .................................................................................... 57
3.3 TMA Transaction States. . ................................................................ 57
3.4 TMA Data Sets. . ................................................................................ 58
3.5 TMA Minimum fields. . ...................................................................... 59

3.5.1 Baseline............................................................................. 59
3.5.2 Commercial Data Set..................................................... 59
3.5.3 Transport Data Set......................................................... 60
3.5.4 Insurance Data Set.. ........................................................ 60
3.5.5 Certificate Data Set........................................................ 60
3.5.6 Other (Certificate) Data Set......................................... 60
3.6 TMA Establishment of a BPO. . ...................................................... 61
3.7 TMA Data and Message Matching Rules.................................... 64
3.8 TMA Pre-Match. . ............................................................................... 66
3.9 TMA Baseline Amendments.......................................................... 66
3.10 TMA Mismatch Acceptance and Rejection................................ 67
3.11 TMA Single shipments and partial shipments........................... 68
3.12 TMA Multiple Obligor Banks. . ........................................................ 68
3.13 TMA Special Messages................................................................... 70
3.14 TMA Reporting................................................................................. 71
3.15 TMA Data Storage........................................................................... 71
3.16 TMA Timers and Time Violations. . ................................................ 71

CHAPTER 4
The Uniform Rules for Bank Payment Obligations................... 72
4.1 Key points. . . . ...................................................................................... 72
4.2 Key differences between the URBPO

and the UCP/eUCP. . ........................................................................ 73
Article 1. . . . . . . . ...................................................................................... 76
Article 2. . . . . . . . ...................................................................................... 78
Article 3. . . . . . . . ...................................................................................... 80
Article 4. . . . . . . . ...................................................................................... 84
Article 5. . . . . . . . ...................................................................................... 86
Article 6. . . . . . . . ...................................................................................... 87
Article 7. . . . . . . . ...................................................................................... 88
Article 8. . . . . . . . ...................................................................................... 89
Article 9. . . . . . . . ...................................................................................... 89
Article 10.. . . . . ...................................................................................... 92
Article 11.. . . . . ...................................................................................... 95
Article 12.. . . . . ...................................................................................... 96
Article 13.. . . . . ...................................................................................... 97
Article 14.. . . . . ...................................................................................... 98
Article 15.. . . . . ...................................................................................... 98
Article 16.. . . . . .................................................................................... 100
CHAPTER 5
Understanding Workflow. . ................................................................ 101
5.1 Establishing a Baseline.. ................................................................ 101
5.1.1 Establishing a Baseline between
two primary banks only. . ............................................. 101
5.1.2 Establishing a Baseline with additional banks.. ...... 106
5.1.3 Role and Baseline Acceptance.................................. 107
5.1.4 Role and Baseline Rejection....................................... 108
5.2 Baseline Amendment Request................................................... 110

5.2.1 Baseline Amendment Acceptance
between two primary banks only............................. 112
5.2.2 Baseline Amendment Acceptance involving
additional banks............................................................ 113
5.2.3 Baseline Amendment Rejection between two
primary banks only....................................................... 114
5.2.4 Baseline Amendment Rejection
involving additional banks.......................................... 115

5.3 Data Set Submission..................................................................... 116
5.3.1 Baseline involving two primary banks only............ 117
5.3.2 Baseline involving additional banks.......................... 118
5.4 Data Set Pre-Match....................................................................... 118
5.5 Mismatch Acceptance.. ................................................................. 119

5.5.1 Baseline involving two primary banks only; Buyer’s
Bank is Obligor Bank.. .................................................. 121
5.6 Mismatch Rejection....................................................................... 122

5.6.1 Baseline involving two primary banks only; Buyer’s
Bank is Obligor Bank.. .................................................. 123
5.7 Special Messages........................................................................... 126
CHAPTER 6
Corporate-to-Bank Guidelines and Messaging............................................... 128
6.1 Adapting the ISO 20022 TSMT messages. . .............................. 128
6.2 Differences in scope...................................................................... 134
6.3 End-to-end message flows.......................................................... 135
CHAPTER 7
Corporate Agreements...................................................................... 140
7.1 Interactions outside the scope of the URBPO........................ 140
7.2 Agreement between a buyer and a seller................................ 142

7.2.1 The ICC Approach........................................................ 143
7.2.2 Specific and General Conditions............................... 143
7.2.3 Extract from the ICC Model International
Sale Contract................................................................. 144
7.3 Agreement between a corporate customer
and a financial institution............................................................. 146
CHAPTER 8
BPO Business Scenarios.................................................................... 147
8.1 Bank-assisted Open Account. . .................................................... 148
8.2 Open Account Processing/Servicing........................................ 150

8.2.1 Purchase Order Advice............................................... 150
8.2.2 Document Presentment and Data Matching. . ........ 153
8.2.3 Discrepancy Handling/Dispute Resolution.. ........... 155
8.2.4 Management of Approved Invoices/Drafts............ 158

8.2.5 Document Payment..................................................... 160
8.2.6 Documents/Payment Reconciliation....................... 160
8.3 Open Account Finance................................................................. 162

8.3.1 Purchase Order Commitment to Pay. . ..................... 162
8.3.2 Pre-Shipment Finance................................................. 163
8.3.3 Warehouse Finance...................................................... 164
8.3.4 Post-Shipment Finance............................................... 166
8.3.5 Approved Payables Finance. . ..................................... 168
8.3.6 Receivables Purchase.................................................. 172
8.3.7 Flexible Due Date. . ........................................................ 173
8.4 BPO Case Studies.......................................................................... 175

8.4.1 BP Chemicals (Exporter)............................................ 175
8.4.2 Standard Chartered Bank........................................... 176
8.4.3 Ito-Yokado (Importer).................................................. 176
8.4.4 Bank of Tokyo-Mitsubishi UFJ (BTMU).................... 176
CHAPTER 9
Useful Links. . . . . . . . . .................................................................................... 177
9.1 Uniform Rules for Bank Payment Obligations....... 177
9.2 Messaging Standards. . ................................................. 177
9.3 Transaction Matching Application Service. . ............ 177
9.4 Industry Organisations................................................ 177
9.5 Software service providers and technology
platforms. . ....................................................................... 178
9.6 Business consultancy and business intelligence. . .. 180
9.7 Banks............................................................................... 181
9.8 Education and Media................................................... 183

List of figures
Figure 1 Example of an Initial Baseline Submission

with one line item.................................................................... 24
Figure 2 The BPO comprises a complete set of standards,
processes and rules.. ............................................................... 25
Figure 3 The BPO is designed to deliver the best
of both worlds.......................................................................... 28
Figure 4 ISO 20022 for Cash Management, Trade
and Supply Chain Finance. . ................................................... 32
Figure 5 The setting up of a BPO as part of the Baseline
establishment process at the start of a transaction
creates a range of basic financing options.. ...................... 35
Figure 6 Adapting the payment due date supports
interbank funding opportunities.......................................... 35
Figure 7 Delaying the issuance of the BPO reduces
the demand on the buyer’s credit lines.............................. 36
Figure 8 Pre-match enables the creation of the BPO to be
delayed to the last possible moment.. ................................ 37
Figure 9 The adoption of mandatory ISO 20022 TSMT
messaging standards and the URBPO is only
applicable to the exchange of data between
an Involved Bank and a TMA................................................ 56
Figure 10 A BPO is an optional part of a TMA Baseline................... 62
Figure 11 The BPO transaction lifecycle.. ............................................. 63
Figure 12 Inaddition to the URBPO, users must consider
the terms and conditions of the TMA and any
specific matching rules that may be proprietary
to that TMA. . ............................................................................. 65
Figure 13 Multiple BPOs create an opportunity for trade
asset distribution..................................................................... 70
Figure 14 The URBPO governs interactions between
Involved Banks and the TMA.............................................. 140
Figure 15 Business flows that take place outside the TMA
are not governed by the URBPO....................................... 141

Figure 16 Overview of BPO-related flows through a TMA............ 147
Figure 17 Buyers and sellers must upload their purchase
order data to the bank......................................................... 150
Figure 18 The banks will use the PO data to create a Baseline
in the TMA. The Baseline may include a BPO.. ............... 151
Figure 19 If
the Baseline includes a BPO, the Buyer’s Bank
becomes the Obligor Bank and the Seller’s Bank
becomes the Recipient Bank.............................................. 151
Figure 20 Ifanother Obligor Bank is involved, it must
accept its role by submitting a Role and Baseline
Acceptance message........................................................... 152
Figure 21 The seller must deliver the commercial and
transport data to the Seller’s Bank. . .................................. 153
Figure 22 Ifthe data comparison results in Zero Mismatches,
the TMA will send a Data Set Match Report
with Zero Mismatches and a Baseline Report
to the Buyer’s/Obligor Bank and the Seller’s/
Recipient Bank. The BPO is now due............................... 154
Figure 23 Additional banks will receive a copy of the Data
Set Match Report with Zero Mismatches and
Baseline Report. The BPO with other Obligor
Bank(s) is now due.. .............................................................. 154
Figure 24 If
the Data Set(s) contain mismatches, these will
be reported in the Data Set Match Report. . .................... 155
Figure 25 Ifthe Buyer’s Bank accepts the mismatches,
the TMA sends a Mismatch Acceptance Notification
and Baseline Report to Involved Banks.
The BPO is due...................................................................... 156
Figure 26 If the Buyer’s Bank rejects the mismatches,
the Baseline remains unchanged and the BPO
is not due. . ............................................................................... 156
Figure 27 Ifthe additional Obligor Bank accepts its continued
role following the acceptance of mismatches by
the Buyer’s Bank, it will submit a Role and Baseline
Acceptance message. The TMA will send a Role
and Baseline Acceptance Notification to the other
banks and issue a Baseline Report to reflect the
changes and to show that the BPO is now due............. 157
Figure 28 If an Obligor Bank rejects its role following
the acceptance of mismatches by the Buyer’s Bank,
the Baseline will remain unchanged and the BPO
is not due. . ............................................................................... 158

Figure 29 The seller uploads the commercial invoice
and transport data as before.............................................. 159
Figure 30 The Seller’s Bank/Recipient Bank submits
the Data Sets that match the Established Baseline.
This means that any BPO that was included
in the Baseline is now due................................................... 159
Figure 31 TheSeller’s Bank/Recipient Bank can now rely
upon the BPO as a source of repayment.. ....................... 159
Figure 32 The Obligor Bank will pay the Recipient Bank
at maturity in accordance with the agreed
settlement terms of the BPO. . ............................................ 160
Figure 33 The Buyer’s Bank/Obligor Bank and the Seller’s
Bank/Recipient Bank can request a variety
of reports to be generated by the TMA
at any time.............................................................................. 161
Figure 34 Usingthe TMA generated reports, the Buyer’s
Bank/Obligor Bank and the Seller’s Bank/Recipient
Bank will be able to offer a range of value-added
payment and account reconciliation services................ 161
Figure 35 If the two Baseline Submissions match, the Baseline
is established. If a BPO is included, the BPO is
also established.. .................................................................... 162
Figure 36 The Seller’s Bank/Recipient Bank may consider
financing the seller based upon the purchase order
commitment to pay (BPO) of the Obligor Bank. . .......... 163
Figure 37 The establishment of the Baseline confirms
the agreed content of the purchase order...................... 164
Figure 38 Similar to Figure 33, the Recipient Bank may
consider making an offer of finance to the seller,
relying on the BPO of the Obligor Bank as a source
of repayment.......................................................................... 164
Figure 39 A Seller’s Bank/Recipient Bank can submit
a Data Set with the instruction “pre-match”
in order to force a match, the results of which are
seen by the Seller’s Bank/Recipient Bank only. . ............ 165
Figure 40 The pre-matched Data Set enables the Seller’s
Bank/Recipient Bank to consider a request
for warehouse finance.......................................................... 166
Figure 41 The BPO becomes due upon Submission
of matching Data Sets. . ........................................................ 167
Figure 42 The Seller’s Bank/Recipient Bank may rely upon
the Obligor Bank’s BPO to support a proposition
for post-shipment finance................................................... 167

Figure 43 Baseline establishment without a BPO............................ 169
Figure 44 Bysubmitting data for a pre-match, the Seller’s
Bank retains the option to create a BPO......................... 170
Figure 45 If
the Buyer’s Bank accepts the Baseline Amendment
Request, the BPO is established. The Buyer’s Bank
becomes the Obligor Bank and the Seller’s Bank
becomes the Recipient Bank.............................................. 171
Figure 46 When the Data Sets are successfully matched to
the Established Baseline, the BPO becomes due.......... 171
Figure 47 The Seller’s Bank/Recipient Bank can finance
the seller directly using the BPO of the Obligor
Bank as collateral. . ................................................................. 172
Figure 48 The matching of the Data Sets to the Established
Baseline means the BPO is due......................................... 172
Figure 49 The Seller’s Bank/Recipient Bank can discount
the receivables and obtain repayment from
the Obligor Bank on the due date. . ................................... 173
Figure 50 The Obligor Bank pays on the due date.......................... 173
Figure 51 TheRecipient Bank may request a Baseline
Amendment to bring forward the due date................... 174
Figure 52 TheObligor Bank may request a Baseline
Amendment to push back the due date. . ........................ 174

List of tables
Table A Summary of proposed BPO accounting policy............... 39

Table B Summary of proposed BPO capital treatment................ 41
Table C This is a complete list of all ISO 20022 TSMT
messages. Those highlighted are the ones
that are defined in URBPO article 4.................................... 52
Table D Baseline Establishment messages. . ..................................... 53
Table E Baseline Amendment messages. . ........................................ 53
Table F Data Set Submission messages........................................... 53
Table G Reporting messages............................................................... 54
Table H Special messages.................................................................... 54
Table J Status Change messages...................................................... 54
Table K Technical messages................................................................ 54
Table L The possible roles of Involved Banks in a TMA
transaction................................................................................ 57
Table M The possible states of a TMA transaction. . ........................ 57
Table N Illustration of a multi-bank BPO........................................... 69
Table P The key differences between the UCP, eUCP
and URBPO. . ............................................................................. 75
Table Q ISO 20022 TSMT messages that could be
adapted and sent from a corporate to a bank............... 130
Table R ISO 20022 TSMT messages that could be adapted
and sent from a bank to a corporate................................ 133
Table S Trigger points for the provision of financial
supply chain services. . .......................................................... 149

List of flow diagrams
Flow Diagram 1 Initial Baseline Submission (Buyer’s Bank/

Seller’s Bank)............................................................... 104
Flow Diagram 2 BaselineReSubmission successful (Zero
Mismatches): Baseline established......................... 105
Flow Diagram 3 Baseline ReSubmission unsuccessful
(Mismatches): Baseline partially matched. . .......... 105
Flow Diagram 4 Baseline Establishment (Buyer’s Bank/
Seller’s Bank)............................................................... 106
Flow Diagram 5 ReSubmission failure – transaction closed........... 106
Flow Diagram 6 Additional banks required to establish
the Baseline................................................................. 107
Flow Diagram 7 Additional bank accepts its role
and the Baseline is established............................... 108
Flow Diagram 8 Additional bank rejects its role – transaction
closed............................................................................ 109
Flow Diagram 9 Amendment Acceptance (Buyer’s Bank/
Seller’s Bank)............................................................... 112
Flow Diagram 10 Amendment Acceptance (additional banks).. ..... 113
Flow Diagram 11 Baseline Amendment Request rejected............... 114
Flow Diagram 12 Baseline Amendment Request rejected
(additional banks)...................................................... 115
Flow Diagram 13 Transaction completed and closed........................ 117
Flow Diagram 14 Transaction status is complete
(additional banks)...................................................... 118
Flow Diagram 15 Data Set Pre-Match – no change in status........... 119
Flow Diagram 16 Mismatch Acceptance (Buyer’s Bank/
Seller’s Bank)............................................................... 121
Flow Diagram 17 Mismatch Acceptance (additional banks)............ 122
Flow Diagram 18 Mismatch Rejection. . .................................................. 123

Flow Diagram 19 ReSubmission of previously mismatched
Data Sets...................................................................... 124
Flow Diagram 20 Roleand Baseline Rejection
by additional bank(s). . ............................................... 125
Flow Diagram 21 Submitting Bank cannot submit
Data Set(s)................................................................... 127
Flow Diagram 22 InvolvedBank must withdraw
from transaction......................................................... 127
Flow Diagram 23 Example of how messages might flow
end-to-end between buyer, Buyer’s Bank,
Seller’s Bank and seller. . ............................................ 136

Chapter 1
What is a Bank Payment

Obligation?
When first considering the unfamiliar concept of a BPO,
it is natural to draw comparisons with something that
we know, namely the documentary letter of credit.
Certainly, it is fair to say that the two instruments share a
common purpose in the mitigation of risk and assurance
of payment.
At the heart of trade facilitation beats a basic desire to
ensure that the buyer receives the goods or services
ordered and the seller gets paid on time.
In the traditional world of trade finance, the letter of
credit places an obligation on an issuing bank to pay
subject to the physical presentation of compliant
documents. This arrangement is particularly beneficial to
the exporter in terms of mitigating risk, obtaining an
assurance of being paid and having access to finance
if required.
Until now, there has been no equivalent instrument
available in the market that would enable banks to
deliver similar levels of assistance to the increasing
number of buyers and sellers trading on open account.
The BPO brings to market an alternative means of
satisfying the risk mitigation, financing, settlement and
information management needs of banks and
businesses engaged in trade. Its primary focus is on
cross-border trade, but it may also be applied to a
domestic trade scenario.
It is important to note from the outset that, unlike a
letter of credit, the BPO represents an undertaking given
by a bank (known as the Obligor Bank) acting on behalf
of the buyer to another bank (known as the Recipient
Bank) acting on behalf of the seller.
It is technically possible for a single transaction to
comprise multiple BPOs issued by multiple Obligor
Banks. However, there can only be one Recipient Bank
and under current rules that bank is always the
Seller’s Bank.

THE ICC GUIDE TO THE UNIFORM RULES FOR BANK PAYMENT OBLIGATIONS
Within the Uniform Rules for Bank Payment Obligations

(URBPO), a BPO is defined as follows:
“ ‘Bank Payment Obligation’ or ‘BPO’ means an

irrevocable and independent undertaking of an Obligor
Bank to pay or incur a deferred payment obligation and
pay at maturity a specified amount to a Recipient Bank
TABLE OF CONTENTS
following Submission of all Data Sets required by an

Established Baseline resulting in a Data Match or an
1.1
acceptance of a Data Mismatch…
WHAT IS A BASELINE?
”
To understand the above-mentioned definition from the
URBPO, we first need to know what a Baseline is and
how it becomes established.
A Baseline can only be established between banks.
Those banks must both be connected to the same
messaging platform, known as the Transaction Matching
Application (TMA).
INDEX
A BPO
is an
optional
part of
a TMA
Baseline
Figure 1: Example of an Initial Baseline Submission with one line

item. Source: SWIFT
By exchanging structured messages via the TMA, a

Buyer’s Bank and a Seller’s Bank may come to a mutual
agreement as to what the Baseline for a particular
transaction should look like (see Figure 1). If the Initial
Baseline Submissions of both banks are the same (i.e.
they match), then the Baseline becomes established. If
that Baseline contains the optional component of a BPO,
then the BPO also becomes established.

What is a Bank Payment Obligation?
The Established Baseline therefore defines those data

elements that must subsequently be presented by the
Seller’s Bank (the Recipient Bank) in order for the BPO
eventually to become due.
Taken in this context, the BPO is more than just a
product. It comprises a complete framework of
TABLE OF CONTENTS
standards, processes and rules to support the delivery of

financial supply chain services in a fully automated
environment. The principles are similar to those that
apply to the familiar framework for documentary letters
of credit (see Figure 2).
Letters of credit BPO
Rules
Platform Transaction
FIN TMA Matching
Application
Standards 20022
MT700 TSMT
INDEX
Figure 2: The BPO comprises a complete set of standards, processes

and rules.
During the course of this book, we will take a closer look

at all of the mandatory elements required to complete a
BPO transaction, including:
The ISO 20022 TSMT messaging standards
The processes and workflow of a Transaction
Matching Application (TMA) and, of course,
The ICC Uniform Rules for Bank Payment Obligations
(URBPO)
1.2 WHY DO WE NEED A BPO?

In recent times, there has been a sustained growth in
both the volume and value of world trade. According to
the World Trade Organisation, the dollar value of world
merchandise trade increased by 19% in 2011 to $18.2
trillion, while the value of world commercial services
exports increased by 11% to $4.2 trillion. Yet the

statistical usage of traditional trade instruments such as

documentary letters of credit has remained flat for
many years.
This suggests that the vast majority of new relationships
that are being established now are trading on open
account terms where documents are sent directly to the
TABLE OF CONTENTS
buyer by the seller, thus bypassing the banking system.

Not only does this commonly confine the business
opportunity for a bank to the processing of a payment
at the end of a transaction, but it potentially challenges
the corporate counterparties to seek out alternative
solutions to their risk, financing, payment and
information needs.
In light of these changing customer requirements and
market dynamics, many financial institutions have had to
redirect their range of products and services to address
the customer’s value-added supply chain, seeking out
new ways to support payment transactions, risk
management, liquidity supply and information flows.
Finding alternative ways of financing transactions has
become increasingly more important. Traditional
products such as factoring have risen in popularity and
are being offered in competition with more innovative
forms of financing such as so-called “reverse factoring”
or supply chain finance.
Moreover, banks increasingly consider themselves as
INDEX
service providers that support their customers in the

collection and analysis of data. International cash
management, e-invoicing and the creation and matching
of commercial documents are just some of the services
offered. The quality of data is of central importance for
banks, as it forms the basis of successful customer
relationship management combined with financial
profile analysis.
The adoption of a common platform (or TMA) for the
exchange of structured data is beneficial to financial
service providers and corporates alike, since it not only
avoids the cost, risk and inherent limitations of being
locked into proprietary systems and processes but also
supports the swift and accurate processing of reusable
data elements. This in turn facilitates the development
and delivery of a range of value-added open account
services, including risk mitigation and financing, as well
as payment, reconciliation and account management
services designed to enhance process efficiency.
The comparison of data within the TMA supports the

tracking of the movement of goods along the physical

supply chain, enabling trigger points to be identified
for the provision of innovative financial supply
chain services.
In the remainder of Chapter 1, we will consider how a
bank’s customer value propositions may be enhanced
TABLE OF CONTENTS
by the incorporation of a BPO.
1.3 ADDRESSING INEFFICIENCIES IN THE FINANCIAL

SUPPLY CHAIN
Optimisation of the physical supply chain has been one
of the main concerns of corporates for years.
Widespread inefficiencies have been collectively
addressed through stakeholder collaboration.
Recent trade market evolutions have highlighted the
need to address related inefficiencies in the financial
supply chain. By adopting a similar collaborative
approach, corporates can develop end-to-end financial
supply chain strategies through win-win business
models to address the needs of all the players, from
upstream suppliers to downstream customers.
At the same time, the rules of the game are changing.
This is due, for example to the advent of new players
and the growth of South-South trade. More than ever,
financial supply chain strategies require innovative trade
finance solutions that combine security, speed and
convenience.
INDEX
Although very effective from a risk and financing point

of view, traditional paper-based finance instruments,
such as letters of credit, have declined in popularity,
partly due to cost and partly due to perceived
inefficiencies for all parties in the value chain. From a
corporate perspective, such solutions are often regarded
as being too slow to address working capital financing
needs efficiently and on time, as well as too slow to
facilitate a timely response to market opportunities.
At the opposite end of the risk spectrum, open account
transactions, though extremely convenient, do not allow
corporates the opportunity either to mitigate the risk of
payment default or to obtain access to alternative
means of financing.
The BPO is designed to deliver the best of both worlds
(see Figure 3). On the one hand, it provides the security
of paper-based finance instruments thanks to the
payment assurance provided by a financial institution.
On the other hand, it delivers both the speed and

convenience of open account transactions thanks to the

efficiency gains of straight-through processing resulting
from digitised data processing and electronic matching.
Letter of credit
Bank services based on paper document processing
TABLE OF CONTENTS
Contract
Buyer Seller
Application Documents
Documents Advice
Documents
Issuance
LC LC
issuing bank advising bank
Payment
Bank Payment Obligation

Bank services based on electronic exchange of trade data
Contract
Documents
Buyer Seller
Data Data
INDEX
Data (via TMA)
Obligor Recipient
Bank Bank
Payment
Open account
Bank services limited to payment processing
Contract
Documents
Buyer Seller
Buyer’s Bank Seller’s Bank
Payment
Figure 3: The BPO is designed to deliver the best of both
worlds. Source: International Chamber of Commerce

More than a risk mitigation or process efficiency tool, the

BPO is also a business enabler that strengthens buyer-
seller relationships and offers significant value across the
entire supply chain.
1.4 OPTIMISATION OF WORKING CAPITAL

TABLE OF CONTENTS
The improvement of corporate liquidity through the

optimisation of working capital management and the
cash conversion cycle and the reduction of cost through
the rationalisation of billing and invoice reconciliation
processes are core requirements for international trading
companies today.
Measures include the reduction of inventory by
optimising purchasing conditions and the negotiation of
improved, standardised payment terms. Flexible use of
external financing, adapted to the status of related
ordering, production and delivery processes, will
contribute to the maintenance of optimum liquidity.
The implementation of measures designed to enhance
process efficiency and streamline the management of
inventory can be complemented by the incorporation of
a BPO within the agreed payment terms, thus providing
a flexible form of finance as well as an assurance that
payment will be effected on time.
1.5 PAYMENT ASSURANCE

The Bank Payment Obligation allows buyers to provide
INDEX
key suppliers with an absolute assurance that they will

be paid on time according to the agreed payment terms.
This assurance of payment comes from the legal
commitment of an Obligor Bank (or Banks) to pay on
the due date, provided that the data submitted by the
Recipient Bank (the Seller’s Bank) is compliant with the
agreed terms.
From a cash management point of view, this is beneficial
to buyers and sellers alike since it delivers certainty on
cash flow in and out. The ability to provide such an
absolute level of payment assurance strengthens the
buyer-supplier relationship, resulting in the opportunity
to negotiate improved terms and conditions.
The BPO is safer than pre-payment, since it allows the
buyer to confirm that the goods have been shipped on
or before the due date according to the required
specification before becoming committed to pay.
Because the electronic processing of data is faster,
buyers can also potentially get quicker access to
banking services, including financing where required.

The BPO provides banks with greater visibility into the

underlying trade transaction so that buyers and sellers
can benefit from specific financing services tailored to
their working capital needs at any stage of the
transaction lifecycle.
This feature is similar to what is available through
TABLE OF CONTENTS
existing letter of credit practices but offers a wider

spectrum of financing opportunities across selected
trigger points in the supply chain.
1.6 ENHANCED PROCESS EFFICIENCY

One of the main criticisms of documentary credits is that
the manual checking processes are costly and slow.
Buyers and sellers who decide to adopt the BPO will only
have to focus on a limited subset of data or elements
that are relevant to the banking services required.
These elements of data will be electronically exchanged
and matched. The electronic matching of data will
improve the quality of processing, reducing the risk of
discrepancies and disputes and thus accelerating the
verification process. Electronic processing will
significantly reduce the processing costs related to
data compliance.
1.7 REDUCED RISK OF DISCREPANCIES

The manual checking and analysis of documentation
is inherently subjective. Hence, the results can often
INDEX
be uncertain.
The risk of discrepancies, resulting in disputes, delays
and increased demurrage costs, is significant. Empirical
evidence suggests that more than 70% of documents
are found to be discrepant on first presentation.
Buyers and sellers who decide to adopt the BPO will
reduce the risk of discrepancies. By replacing the
manual document checking process with the electronic
matching of data, buyers and sellers will benefit from
significantly increased accuracy and objectivity.
While manual processing implies a line-by-line
verification of documents, the BPO requires only the
matching of a limited number of relevant data elements
in order to guarantee payment or to support a
proposition for financing.
At the same time, there is the added flexibility that, in
the event of data mismatches being found, the buyer
has the immediate discretion to accept or reject
such mismatches.

1.8 MITIGATING THE RISK OF SUPPLIER DEFAULT

For critical suppliers, buyers may decide to offer a BPO
in order to ensure that the goods ordered continue to be
delivered on time and that there are no unnecessary
interruptions to the supply chain. A supplier can get
financing from its bank at different stages in the
TABLE OF CONTENTS
transaction lifecycle.
The BPO can be used to sustain the seller’s working
capital, for example in support of production (pre-
shipment finance, inventory finance), product shipment
(packing and distribution loans) or business
development and growth.
Failure to have access to these facilities could prove
detrimental to the supplier’s continued ability to trade.
1.9 STRENGTHENING BUYER/SUPPLIER

RELATIONSHIPS
By adopting the BPO, buyers can strengthen their
relationships with key suppliers. They can become
trusted counterparties by demonstrating reliability and
giving suppliers the assurance of being paid on time as
per the payment terms and conditions agreed.
Buyers who engage in a BPO contract with their
suppliers will contribute to the streamlining of supply
chain processes, resulting in enhanced risk mitigation
and process efficiency. This may be turned into a
INDEX
competitive advantage over other buyers, resulting in

improved payment terms. Conversely, the delayed
issuance of a BPO can result in significant cost savings
for a buyer, thus presenting a supplier with an
opportunity to gain a competitive advantage over
other suppliers.
1.10 GROWING THE SUPPLIER NETWORK

Buyers typically trade with multiple suppliers across the
globe, often in different jurisdictions, resulting in a
variety of payment terms and potentially using more
than one supply chain finance platform.
Platforms use different exchange mechanisms, from
electronic proprietary data formats to fax and email. The
cost of integration with corporate back office
applications becomes prohibitive when the number of
trading players grows or varies over time. It also implies
significant on-boarding costs and lengthy know-your-
customer (KYC) processes. The BPO is designed for a
four-corner business model. It helps buyers to reach

multiple suppliers through selected banks in the existing

correspondent banking network.
1.11 INTEGRATED TECHNOLOGY BASED ON GLOBAL

MESSAGING STANDARDS
Financing costs can be reduced by regularly informing
TABLE OF CONTENTS
banks about the movement of goods and associated

cash flows. Further potential lies in structured
receivables and collections management. Managing
processes that are relevant to liquidity can insulate the
company from the risk of a declining credit rating
through to the prevention of insolvency.
The condition for meeting these requirements in terms
of best practice is, however, a standardised and reliable
data structure. This can only be achieved by the
networking of all of the IT systems relevant to the
liquidity management process across all of the corporate
functions, including acquisitions, logistics, cash
management, treasury management and credit
management.
International trading companies and exporting industrial
enterprises also have to consider a multitude of
gateways to external parties, such as banks, logistics and
insurance providers, suppliers, clients and authorities
that exist in a global environment.
ISO 20022 for Cash Management (since 2006)

INDEX
Credit transfer (pain.001, pacs.008, pacs.009, etc.)

Direct debit (pain.008, pacs.003, etc.)
Account statement (camt.05x)
ISO 20022 for Trade & Supply Chain Finance

Bank-to-bank: baseline establishment, data set submission,
baseline amendment, intent to pay, status change and
extension, etc. (tsmt.0xx)
Corporate-to-bank: new set of guidelines published in 2011
Figure 4: ISO 20022 for Cash Management, Trade and Supply Chain
Finance. Source: Misys
The BPO is based on a standard ISO 20022 messaging

format that facilitates the technological integration of
trade, payment and cash management data, including
e-invoicing (see Figure 4). The key difference between
the BPO and past electronic solutions resides in the
common use of a trade transaction matching scheme.

Whereas previous solutions have implemented

electronic data interchange (EDI) standards, the BPO
includes not only a structured data exchange but, more
importantly, an industry standard set of rules that can
eventually be implemented by any open Transaction
Matching Application (TMA).
TABLE OF CONTENTS
1.12 FLEXIBLE FORMS OF FINANCING

The BPO offers increased flexibility over a letter of credit
because it can be created at any time during the
lifecycle of a transaction and for an amount that can
differ from the total value of the goods. The matching of
data extracted from trade-related documents creates
the continuum of information and visibility required to
identify trigger points in support of a variety of financing
propositions, including pre-shipment, post-shipment,
approved payables and buyer finance.
A syndicated BPO can also help the buyer to spread the
payment risk across multiple Obligor Banks. For
example, a lead bank can be instructed to allocate the
risk according to a trade asset distribution model.
Having the opportunity to take advantage of alternative
forms of financing throughout the transaction lifecycle
may result in lower financing costs for the buyer, as well
as reduced confirmation costs for the seller, creating
more value in the supply chain and potential
opportunities for improved commercial terms.
INDEX
Increased flexibility also creates the opportunity for

buyers and sellers to reduce their recourse to expensive
working capital loans, thus preserving the availability of
related credit facilities.
Buyers with idle cash balances can benefit from the fact
that the BPO allows for early repayment of the
obligations. Buyers who opt to pay early may benefit
from dynamic discounting and eventually become
preferred buyers, increasing the mutual level of trust
between commercial counterparties.
1.13 “SILENT” BPOs

It is fair to say that there has been a certain amount of
debate around the advantages and disadvantages of a
BPO being established as a bank-to-bank instrument as
opposed to a bank-to-corporate undertaking.
One aspect that has not been widely discussed or
considered is the circumstance in which a bank may
wish to establish a BPO with another bank

independently of the payment arrangements made

between the corporate counterparties.
For example, in an approved payables scenario, the
Buyer’s Bank may be required to establish a credit
facility in the name of the buyer that is to be used to
finance that customer’s suppliers. The Buyer’s Bank now
TABLE OF CONTENTS
has to deal with the supplier on-boarding issues,

including KYC and so forth.
Rather than adopting a three-corner approach, in which
the Buyer’s Bank finances the suppliers directly (to the
exclusion of the Seller’s Bank), the Buyer’s Bank could
instead negotiate an arrangement with the Seller’s Bank
whereby data is exchanged via a shared TMA.
Following Baseline establishment, a BPO can optionally
be established between the banks at any time during
the transaction lifecycle in order to support a required
financing proposition. Thus, the Seller’s Bank is able to
take care of the supplier on-boarding issues and can
assume an active role in the execution of a four-corner
solution (buyer, Buyer’s Bank, Seller’s Bank, seller).
Such an arrangement may require an element of risk
sharing/revenue sharing between the banks involved.
However, given that the BPO exists purely as an
undertaking between the banks, it can potentially be set
up as a private arrangement between those banks,
remaining “silent” towards both the buyer and the seller,
since neither the buyer nor the seller is required to take
INDEX
on an active role in the BPO undertaking.
1.14 SUMMARY OF THE MAIN FINANCING

OPPORTUNITIES USING THE BPO
1.14.1 Basic financing options

A number of basic financing options are made available
by setting up a BPO at the start of a transaction as part
of an Established Baseline (see Figure 5).
These include:
1. At the initial Baseline establishment, the Recipient
Bank is able to make an offer of pre-shipment
finance to the seller based on a purchase order
commitment to pay.
2. At the successful matching of Data Sets when
compared to the Established Baseline, the Recipient
Bank is able to make an offer of post-shipment
finance to the seller based on approved payables.

3. The Obligor Bank has the option to pay the BPO

when due but to defer the collection of payment
from the buyer by offering extended payment terms.
Purchase Order Production Shipment Delivery
hase
Purc er
Ord
TABLE OF CONTENTS
The Recipient Bank may offer The Recipient Bank The Obligor Bank
pre-shipment finance to the seller based may offer post- may offer extended
Financing
on PO commitment to pay shipment finance payment terms to

to the seller based the buyer
on approved
payables
Baseline Establishment with BPO

TMA
Data Match
(Zero
Mismatches)
BPO
BPO irrevocable but conditional BPO irrevocable and due
Figure 5: The setting up of a BPO as part of the Baseline establishment pro-

cess at the start of a transaction creates a range of basic financing options.
1.14.2 Adapting the due date of the BPO

The BPO payment terms can be amended dynamically
to respond to the changing needs of both buyers and
sellers. This enables inter-bank funding to take place. For
example, bringing forward the due date enables the
Buyer’s Bank/Obligor Bank to fund the Seller’s Bank/
INDEX
Recipient Bank. Alternatively, pushing back the due date

enables the Seller’s Bank/Recipient Bank to fund the
Buyer’s Bank/Obligor Bank (see Figure 6).
hase
Purc er
Ord
The Recipient Bank may offer The Recipient Bank The Obligor Bank
pre-shipment finance to the seller may offer post- may offer extended
Financing
based on PO commitment to pay shipment finance to payment terms to

the seller based the buyer, having
on pre-funded BPO secured a delay in
the BPO due date
Baseline Baseline Data Match

TMA
Establishment Amendment (Zero

with BPO (due date) Mismatches)
BPO
BPO irrevocable but conditional BPO irrevocable and due
Figure 6: Adapting the payment due date supports interbank funding

opportunities.

1. The Recipient Bank may request the Obligor Bank to

bring forward the payment due date by amending
the Baseline accordingly. This means that the
Recipient Bank will receive payment earlier and be
able to use these funds to finance the seller.
2. The Obligor Bank may request the Recipient Bank to
put back the payment due date by amending the
TABLE OF CONTENTS
Baseline accordingly. This means that the Obligor

Bank is able to extend payment terms to the buyer
without having to pay the BPO on the due date.
1.14.3 Delaying the establishment of the BPO

A BPO does not have to be included in the Baseline
establishment process. The creation of the BPO can be
delayed until needed. This is achieved by amending the
Baseline (see Figure 7).
By delaying the establishment of the BPO, the Recipient
Bank may offer post-shipment or approved payables
finance to the seller only if/when the seller needs it.
This approach is also beneficial to the buyer and the
Buyer’s Bank/Obligor Bank, since it limits the demand
on the buyer’s credit lines and therefore reduces the
overall cost of capital.
hase
Purc er
Ord
INDEX
Financing
The Recipient Bank may offer

post-shipment finance to the seller
based on approved payables
Baseline Establishment without BPO Baseline Data Match

TMA
Amendment (Zero
(add BPO) Mismatches)
BPO irrevocable but conditional

BPO
BPO irrevocable and due
Figure 7: Delaying the issuance of the BPO reduces the demand on the
buyer’s credit lines.

1.14.4 Using the TMA “pre-match” facility to create

the BPO later
Use of the TMA “pre-match” facility enables the creation
of the BPO to be delayed until the last possible moment
(see Figure 8). This is particularly relevant in an
approved payables finance scenario where the seller
only identifies a financing requirement after the
TABLE OF CONTENTS
commercial and transport data has been submitted.

By pre-matching the Data Sets, the Seller’s Bank can
satisfy itself that the data does match. However, the
results of a pre-match are delivered to the Seller’s Bank
only. This means that the Seller’s Bank still has the
option, if required, to submit a Baseline Amendment
Request at a later date, asking the Buyer’s Bank (or
another Obligor Bank) to agree to the addition of a BPO.
Provided the Buyer’s Bank/Obligor Bank agrees, the
BPO is added to the Baseline.
The Seller’s Bank can now submit the Data Sets for “full
push through” matching, the results of which will be seen
by all Involved Banks, and the BPO will become due.
hase
Purc er
Ord
The Recipient Bank

may offer post-
Financing
INDEX
shipment finance to
the seller based
on approved
payables
Baseline Establishment Data Set Baseline Data

without BPO Pre-Match Amendment Match
(Zero (add BPO)
TMA
(Zero
Mismatches) Mismatches)
BPO irrevocable
but conditional
BPO
BPO irrevocable
and due
Figure 8: Pre-match enables the creation of the BPO to be delayed to the

last possible moment.

1.15 ACCOUNTING POLICY FOR BPOS

The main issues to consider in relation to accounting for
a BPO transaction include the nature of the obligation
and the trigger points for transitioning the obligation
from one type of liability to another.
There is a general consensus that, for accounting and
TABLE OF CONTENTS
financial reporting purposes, the BPO should be treated

in a similar manner to an import letter of credit.
Therefore, if the Initial Baseline Submission includes a
Payment Obligation Segment that shows that the
Buyer’s Bank will take on the role of the BPO Obligor
Bank, then the obligation itself is immediately recorded
by the Buyer’s Bank/Obligor Bank as an off-balance-
sheet contingent obligation.
If the Initial Baseline Submission includes a Payment
Obligation Segment that shows that a bank other than
the Buyer’s Bank will take on the role of a BPO Obligor
Bank, then that other Obligor Bank should similarly
record its risk as an off-balance-sheet contingent
obligation at the time of accepting its designated role.
In the case of a deferred payment undertaking, the
obligation of the Obligor Bank becomes a direct liability
when all of the required Data Sets have been presented
and matched successfully, or if mismatches have been
accepted. At this point, the TMA transaction is
considered complete, since no further Submissions of
INDEX
data are required.

If the undertaking is discounted by the Seller’s Bank, its
exposure becomes a cash item that is recorded as a
loan/advance and becomes a funded obligation.
Of course, there is one material difference between a
BPO and a letter of credit insofar as the BPO is issued in
favour of a Recipient Bank and not in favour of the
corporate beneficiary (the seller).
When and how value is passed from a Recipient Bank
to a seller is a matter of negotiation between the
corporate and the bank, the terms of which will be
reflected in the contractual agreement that exists
between the two parties.
For example, the Recipient Bank may record a
contingent obligation in favour of the seller. For
accounting purposes, this would be treated in a similar
way to a silent confirmation of a letter of credit.

For guidance purposes only, Table A provides a

summary of the views that have been put forward for
discussion on this subject.
Party/Role Type of Period Transaction Accounting
liability Flow Policy
Obligor Contingent From Baseline BPO Off
TABLE OF CONTENTS
Banks establishment established as balance

to successful an irrevocable, sheet
matching of conditional
all required Data payment Unfunded
Sets obligation
pending
Submission of
Data Sets
Recipient Contingent From Baseline BPO Off

Bank establishment established as balance
to successful an irrevocable, sheet
matching of all conditional
required Data payment Unfunded
Sets obligation
pending
Submission of
Data Sets
Obligor Direct From time Deferred On

Bank of successful payment balance
matching of all undertaking sheet
Recipient required Data after successful
Bank Sets to the end matching of Funded
of any deferred data
payment period
Recipient Direct From time of BPO discounted On

Bank discounting to without balance
INDEX
the end of any recourse sheet

deferred payment
period Funded
Obligor Closed Paid immediately Transfer Closed

Bank at sight following of value to
successful corporate
Recipient matching of all beneficiary
Bank required Data Sets (seller)
or at end of any
deferred payment
period
Table A: Summary of proposed BPO accounting policy.

Source: ICC Discussion Paper

1.16 CAPITAL TREATMENT FOR BPOS

It is widely acknowledged that the recent changes
affected to the Basel Committee regulatory framework
have highlighted some unintended consequences that
may be detrimental to the business of traditional
trade finance.
TABLE OF CONTENTS
As a new financial instrument, the BPO at this moment

in time lacks any formal history of usage. Therefore, it is
difficult to put forward any meaningful analysis of its
performance in the context of capital adequacy.
The development of cogent guidelines for the capital
treatment and reporting of a BPO can only be developed
over time and in light of real-life commercial experience.
The current expectation is that a BPO should be treated
as a contingent liability and hence qualify as an off-
balance-sheet commitment. An Obligor Bank has no
obligation to execute payment if there is a Data
Mismatch between Data Sets presented and the
Established Baseline.
When considering the capital treatment of a BPO, a
number of factors come into play, including the type of
obligation, the duration of the exposure and the
likelihood of default and/or loss.
1.16.1 Probability of Default

The Probability of Default (PD) ratio is counterparty-
INDEX
driven. It is dependent upon the financial standing that

has been assigned to the Obligor Bank.
1.16.2 Loss Given Default

The Loss Given Default (LGD) ratio is product-driven. In
the absence of any track record of usage, the calculation
of the LGD ratio for a BPO will be subject to the Internal
Ratings-Based Foundation model, currently fixed at
45%. This should be subject to review over time as
evidence of a track record develops.
1.16.3 Effective Maturity

It is thought that the waiver related to the one-year
maturity floor that has now been applied to the letter
of credit should similarly apply to the BPO.

1.16.4 Leverage
Regarding the calculation of risk-weighted assets
as an off-balance-sheet undertaking, the BPO should be
subject to a credit conversion factor of 20% for
commitments of up to one year and 50% for
commitments of more than one year.
TABLE OF CONTENTS
In the light of enhanced efficiencies resulting from

automated processing and the fact that a BPO can often
be issued late in the transaction lifecycle, it is thought
that the average tenor of a BPO is likely to be less than
one year.
Under Basel III, all off-balance-sheet undertakings are
currently considered the same as on-balance-sheet
items and are consequently subject to a credit
conversion factor of 100% for the calculation of the
leverage ratio *.
For guidance purposes only, Table B provides a
summary of the views that have been put forward for
discussion on this subject.
Probability Loss Given Effective Credit Conversion

of Default Default Maturity Factor *
Counterparty- 45% (as per IRB Minimum one RWA
driven Foundation) day (as per L/C) 1 year: 20%
1 year+ : 50%
Leverage
100%
INDEX
Table B: Summary of proposed BPO capital treatment.

Source: ICC Discussion Paper
* In April 2013, the European Parliament approved the Capital Reserve Requi-
rements IV Directive (CRR IV) which revises the credit conversion factor for
secured letters of credit back down to the previous level of 20%. This means that
banks operating in Europe will be able to benefit from more favourable capital
treatment. At the time of writing, it remains to be seen whether banks in other
regions may be able to obtain a similar benefit should local regulators decide in
favour of adopting similar measures.

Chapter 2
The ISO 20022

TSMT messages
TABLE OF CONTENTS
The ICC Uniform Rules for Bank Payment Obligations

(URBPO) are predicated on the fact that messages
exchanged between Involved Banks (i.e. a Seller’s Bank,
a Recipient Bank, a Buyer’s Bank, an Obligor Bank or a
Submitting Bank) and a Transaction Matching
Application (TMA) will comply with ISO 20022
standards. Any TMA used in connection with the URBPO
must therefore be able to process at a minimum the ISO
20022 TSMT messages as defined in URBPO article 4.
2.1 WHAT IS ISO?

For those who may not be entirely familiar with the
world of financial messaging, ISO is the International
Organization for Standardization and the world’s largest
developer and publisher of International Standards,
with a membership of more than 160 national standards
bodies. Its purpose is to promulgate worldwide
standards in a variety of domains aimed at facilitating
INDEX
cross-border exchanges of goods, services

and techniques.
It goes without saying that, in order to conduct their
business, financial institutions need to exchange massive
amounts of information on a daily basis with both their
customers and their counterparties. In order to do this
efficiently, there needs to be a common understanding
of the way in which specific types of information are to
be presented and an agreed structure for achieving this
exchange in a fully automated environment, such that
one computer is able to read and interpret data received
from another computer.
Over the years, the financial services industry has
developed the means of organising data into structured
formats, known as syntax, and definitions, known as
semantics. Based upon a common understanding of
these structured formats and definitions, financial
institutions are able to exchange messages electronically
with a minimum of human intervention. One drawback,
however, is that across the industry there continues to

The ISO 20022 TSMT messages
be a variety of competing standards, meaning that data

is not always presented in the same way. The use of
different syntax and semantics, sometimes based on
standards that are proprietary to one organisation, is a
barrier to straight-through processing.
2.2 WHAT IS ISO 20022?

TABLE OF CONTENTS
ISO 20022 is a set of standards developed by ISO for

use in the financial industry. Usage of ISO 20022
messages results in consistency and uniformity of
format and terminology through use of a common data
dictionary.
In ISO 20022, the most widely used syntax is eXtensible
Markup Language (XML), which allows users to define
identifiers and data types for each component of a
message.
ISO 20022 comprises a common platform for the
development of messages using:
a methodology based on Unified Modelling
Language (UML) to capture financial business areas,
business transactions and associated message flows
in a syntax-independent way;
a central dictionary of business items used in
financial communications;
a set of XML design rules to convert the messages
described in UML into XML schemas whenever the
INDEX
use of the ISO 20022 XML-based syntax is preferred.

The resulting models and derived messages are
published in the catalogue of messages and stored in
the ISO 20022 Financial Repository available on the ISO
20022 website (http://www.iso20022.org).
This flexible framework allows communities of users and
message development organisations to define message
sets according to an internationally agreed approach,
using internationally agreed business semantics and,
whenever desirable, to migrate to the use of a common
XML-based syntax.
Financial message definitions are organised by business
area, each one of which is uniquely identified by a
four-character business area code. In the case of Trade
Services Management, the business area code is TSMT.

2.3 WHAT IS ISO 20022 TSMT?

ISO 20022 TSMT standards specify the format for the
commercial, transport, insurance, certificate and other
certificate Data Sets to be submitted by an Involved
Bank in respect of an underlying trade transaction and
for the related TSMT messages exchanged between
TABLE OF CONTENTS
Involved Banks and the TMA. As is the case with other

ISO standards in the area of financial services, ISO
20022 standards for TSMT messages are publically
available and are not proprietary to any technology
provider or financial institution. The message definitions
that are currently published on the ISO website are
those that were approved by the Trade Services
Standards Evaluation Group on 11 April 2008. The
messages are designed to be exchanged between the
users of a TMA and the TMA itself. They are not user-to-
user messages. They support the features of a TMA with
an integrated workflow management capability.
The message definitions cover the following key
application features:
the establishment of a transaction (also referred to
as Baseline)
the matching of Data Sets
the amendment of a transaction (Baseline)
the acceptance/rejection of mismatches
reports on status and activity
INDEX
2.4 THE ISO 20022 TSMT MESSAGES

There are currently 50 officially registered ISO 20022
TSMT messages that are in active use and are designed
specifically to support the exchange of information and
related reports between all of the banks that are
involved in a transaction and the TMA used to perform
the data processing. All of these messages are defined
below. It should be noted that message types tsmt.039.
xxx.xx and tsmt.043.xxx.xx are not currently in use.
Of the 50 messages listed in Table C, only 19 are defined
in the Uniform Rules for Bank Payment Obligations
(URBPO). These 19 messages are highlighted in bold
type. The reason for this limitation is that the messages
defined in the URBPO are those that are directly
referenced within the Rules themselves. The other
messages comprise mainly a variety of reports, requests
and notifications.

Although these other messages are outside the direct

scope of the URBPO, they nevertheless form an essential
part of the transaction matching workflow. It is
important to note, therefore, that during the course
of a transaction these messages will also be exchanged,
in addition to those that fall within the scope
of the URBPO.
TABLE OF CONTENTS
Message Message Name Purpose Sent by Sent to

Type
tsmt. Acknowledgement To acknowledge The TMA The
001.001.03 the receipt of Involved
an incoming Bank from
message. which the
original
message
was
received
tsmt. Activity Report To report The TMA The

002.001.03 on all those Involved
transactions Bank from
for which an which an
activity has Activity
taken place Report
within a given Request
time span. has been
received
tsmt. Activity Report To request An Involved The TMA

003.001.03 Request a report on Bank
all those
transactions
for which an
activity has
INDEX
taken place
within a given
time span.
tsmt. Activity Report To request the An Involved The TMA

004.001.02 Set-Up Request setting-up of Bank
a regular time
at which an
activity report is
to be generated.
tsmt. Amendment To accept A Buyer’s The TMA

005.001.02 Acceptance a Baseline Bank, a
Amendment Seller’s
Request. Bank or a
Recipient
Bank (as
applicable)
tsmt. Amendment To notify the The TMA A Buyer’s

006.001.03 Acceptance acceptance Bank, a
Notification of a Baseline Seller’s
Amendment Bank or a
Request. Recipient
Bank (as
applicable)


Type
tsmt. Amendment To reject A Buyer’s The TMA
007.001.02 Rejection a Baseline Bank, a
Amendment Seller’s
Request. Bank or a
Recipient
TABLE OF CONTENTS
Bank (as
applicable)
tsmt. Amendment To notify the The TMA A Buyer’s

008.001.03 Rejection rejection of Bank, a
Notification a Baseline Seller’s
Amendment Bank or a
Request. Recipient
Bank (as
applicable)
tsmt. Baseline To request the A Buyer’s The TMA

009.001.03 Amendment amendment of Bank, a
Request an Established Seller’s
Baseline. Bank or a
Recipient
Bank (as
applicable)
tsmt. Baseline Match To report The TMA Involved

010.001.03 Report either (a) the Banks
successful (other than
establishment an Obligor
of a Baseline Bank that
(following is not the
Submission Buyer’s
of two Initial Bank)
Baseline
Submissions
with Zero
INDEX
Mismatches) or
(b) the failure
to establish a
Baseline owing
to mismatches
having been
found between
the two Initial
Baseline
Submissions.
tsmt. Baseline Report To report The TMA Banks

011.001.03 either a pre- involved in
calculation or a Baseline
final calculation Amend
of the dynamic ment
part of an Request or
Established Data Set
Baseline. match


Type
tsmt. Baseline To respond A sender The TMA
012.001.03 ReSubmission to an Initial of an Initial
Baseline Baseline
Submission or Submission
to resubmit or the
TABLE OF CONTENTS
Baseline data counterparty

that has been bank named
mismatched. in such
Submission
tsmt. Data Set Match To report on The TMA Each

013.001.03 Report either a Data Involved
Match or a Bank
Data Mismatch,
following
Submission of
all Data Sets
required by an
Established
Baseline and
the automatic
comparison
of such Data
Sets with that
Established
Baseline.
tsmt. Data Set To trigger either An Involved The TMA

014.001.03 Submission a match or a Bank
pre-match of
the information
submitted
against the
Established
INDEX
Baseline.
tsmt. Delta Report To list the The TMA Banks

015.001.03 differences involved
between the in the
Established request for
Baseline and a a Baseline
newly proposed Amend
Baseline, ment
following a
request for
a Baseline
Amendment.
tsmt. Error Report To advise the The TMA The

016.001.03 inability of the submitter
TMA to process of the
a message message
received from that
an Involved resulted in
Bank due to an the error in
error detected processing
in that message.


Type
tsmt. Forward Data Set To pass on The TMA Involved
017.001.03 Submission Report information Banks
related to
the Data Sets
covered by the
TABLE OF CONTENTS
transaction.
tsmt. Full Push Through To advise details The TMA Each

018.001.03 Report of a proposed Involved
Baseline, an Bank
Established
Baseline or
a proposed
amendment to
an Established
Baseline. The
Baseline data
forms part of
the Full Push
Through Report.
tsmt. Initial Baseline To initiate a A Buyer’s The TMA

019.001.03 Submission transaction. Bank or a
Seller’s Bank
tsmt. Mismatch To accept a A Buyer’s The TMA

020.001.02 Acceptance Data Mismatch. Bank
tsmt. Mismatch To notify the The TMA Each

021.001.03 Acceptance acceptance of a Involved
Notification Data Mismatch Bank
by a Buyer’s
Bank.
INDEX
tsmt. Mismatch Rejection To reject a Data A Buyer’s The TMA

022.001.02 Mismatch. Bank
tsmt. Mismatch Rejection To notify the The TMA Each

023.001.03 Notification rejection of a Involved
Data Mismatch Bank
by a Buyer’s
Bank.
tsmt. Action Reminder To remind an The TMA An

024.001.03 Involved Bank Involved
of an action that Bank
is overdue.
tsmt. Status Change To notify a The TMA Involved

025.001.03 Notification change of status Banks
of a Baseline
(transaction),
e.g. from
proposed to
established.
tsmt. Status Change To request a A Buyer’s The TMA

026.001.02 Request change in the Bank or a
status of a Seller’s Bank
transaction, e.g.
from complete
to closed.


Type
tsmt. Status Change To advise the A Buyer’s The TMA
027.001.02 Request acceptance Bank or a
Acceptance of a request Seller’s Bank
to change the
status of a
TABLE OF CONTENTS
transaction.
tsmt. Status Change To notify receipt The TMA A Buyer’s

028.001.03 Request of the request Bank or
Notification for a change in a Seller’s
the status of a Bank
transaction.
tsmt. Status Change To advise the A Buyer’s The TMA

029.001.02 Request Rejection rejection of Bank or a
a request to Seller’s Bank
change the
status of a
transaction.
tsmt. Status Change To notify the The TMA A Buyer’s

030.001.03 Request Rejection counterparty Bank or
Notification of the rejection a Seller’s
of a request Bank
to change the
status of a
transaction.
tsmt. Status Extension To advise the A Buyer’s The TMA

031.001.03 Acceptance counterparty Bank or a
bank of the Seller’s Bank
acceptance
of a request
to extend the
status of a
INDEX
transaction.
tsmt. Status Extension To notify all The TMA Involved

032.001.03 Notification parties of the Banks
acceptance
of a request
to extend the
status of a
transaction.
tsmt. Status Extension To advise the A Buyer’s The TMA

033.001.03 Rejection rejection of Bank or a
a request to Seller’s Bank
extend the
status of a
transaction.
tsmt. Status Extension To advise a The TMA A Buyer’s

034.001.03 Rejection counterparty Bank or
of a request Bank
to extend the
status of a
transaction.


Type
tsmt. Status Extension To request the A Buyer’s The TMA
035.001.03 Request extension of Bank or a
the status of a Seller’s Bank
transaction.
TABLE OF CONTENTS
tsmt. Status Extension To notify a The TMA A Buyer’s

036.001.03 Request counterparty Bank or
Notification of the request a Seller’s
to extend the Bank
status of a
transaction.
tsmt. Status Report To report on The TMA An

037.001.03 the status of Involved
all transactions Bank
in the TMA that has
in which a requested
bank may be such report
involved.
tsmt. Status Report To request An Involved The TMA

038.001.03 Request a report on Bank
the status of
transactions in
the TMA.
tsmt. Time-out To advise that a The TMA Involved

040.001.03 Notification transaction will Banks
be closed within
a given time
if no action is
taken.
INDEX
tsmt. Transaction Report To report on The TMA An

041.001.03 the details of a Involved
transaction in Bank
the TMA. that has
requested
such report
tsmt. Transaction Report To request a An Involved The TMA

042.001.03 Request report on the Bank
details of a
transaction in
the TMA.
tsmt. Intent to Pay To express a A Buyer’s The TMA

044.001.01 Notification confirmed intent Bank
on the part of
the buyer to
pay a certain
amount at a
certain time
in relation to
one or more
transactions.


Type
tsmt. Forward Intent to To inform the The TMA A Seller’s
045.001.01 Pay Notification Seller’s Bank Bank
of a confirmed
intent on the
part of the
TABLE OF CONTENTS
buyer to pay a
certain amount
at a certain
time in relation
to one or more
transactions.
tsmt. Intent to Pay To report upon The TMA A Buyer’s

046.001.01 Report intent to pay Bank and
messages a Seller’s
received. Bank
tsmt. Special Request Used in special (1) A The TMA

047.001.01 circumstances Submitting
(1) to advise Bank
a reason for
being unable
to submit a
Data Set or (2) (2) An
to withdraw Involved
from a role in Bank
an Established
Baseline due to
force majeure.
tsmt. Special Notification To provide The TMA Involved

048.001.01 information Banks
related to the
receipt of a
INDEX
Special Request
message
from another
Involved Bank.
tsmt. Role and Baseline To confirm A Submitting The TMA

049.001.01 Acceptance acceptance Bank or an
of a role in a Obligor Bank
transaction as other than
specified in the Buyer’s
the Baseline Bank
contained in
a Full Push
Through Report.
tsmt. Role and Baseline To advise A Submitting The TMA

050.001.01 Rejection rejection of a Bank or an
role as specified Obligor Bank
in the Baseline other than
contained in the Buyer’s
a Full Push Bank
Through Report.


Type
tsmt. Role and Baseline To advise the The TMA Each other
051.001.01 Acceptance receipt of a Role Involved
Notification and Baseline Bank
Acceptance
in response
TABLE OF CONTENTS
to a Full Push
Through Report.
tsmt. Role and Baseline To advise the The TMA Each other
052.001.01 Rejection receipt of a Role Involved
Notification and Baseline Bank
Rejection in
response to
a Full Push
Through Report.
N.B. Message types tsmt.039.Xxx.Xx (store data set request)

and tsmt.043.Xxx.Xx are not in use.
Table C: This is a complete list of all ISO 20022 TSMT messages. Those
highlighted are the ones that are defined in URBPO article 4.
INDEX

It may also be helpful to consider how these messages

are grouped in terms of function and flow. For example:
Baseline Establishment messages
TMA IN TMA OUT

TABLE OF CONTENTS
Initial Baseline Submission Full Push Through Report
Baseline ReSubmission Baseline Match Report
Role and Baseline Acceptance Role and Baseline Acceptance Notification
Role and Baseline Rejection Role and Baseline Rejection Notification
Table D: Baseline Establishment messages.
Baseline Amendment messages
TMA IN TMA OUT
Baseline Amendment Request Delta Report
Amendment Acceptance Amendment Acceptance Notification
Amendment Rejection Amendment Rejection Notification
Baseline Report
Full Push Through Report

INDEX
Table E: Baseline Amendment messages.
Data Set Submission messages
TMA IN TMA OUT
Data Set Submission Forward Data Set Submission Report
Data Set Match Report
Mismatch Acceptance Mismatch Acceptance Notification
Mismatch Rejection Mismatch Rejection Notification
Baseline Report
Table F: Data Set Submission messages.

Reporting messages
TMA IN TMA OUT
Activity Report Set-Up Request
Activity Report Request Activity Report
Status Report Request Status Report

TABLE OF CONTENTS
Transaction Report Request Transaction Report
Intent to Pay Report
Table G: Reporting messages.
Special messages
TMA IN TMA OUT

Special Request Special Notification
Intent to Pay Notification Forward Intent to Pay Notification
Table H: Special messages.
Status Change messages
TMA IN TMA OUT
Status Change Request Status Change Notification
Status Change Request

Status Change Request Notification
Acceptance
INDEX
Status Change Request Rejection Status Change Request Rejection Notification
Status Extension Request Status Extension Request Notification
Status Extension Acceptance Status Extension Notification
Status Extension Rejection Status Extension Rejection Notification
Table J: Status Change messages.
Technical messages
TMA IN TMA OUT

Acknowledgement
Action Reminder
Error Report
Time-out Notification
Table K: Technical messages.
These flows are elaborated upon in the context of the

URBPO in Chapter 5.

Chapter 3
The Transaction
Matching Application
As noted above, the ICC Uniform Rules for Bank
Payment Obligations (URBPO) are predicated on the
fact that messages exchanged between Involved Banks
and a Transaction Matching Application (TMA) will
comply with ISO 20022 TSMT standards. Any TMA used
in connection with the URBPO must therefore be able to
process at a minimum the ISO 20022 TSMT messages
as defined in URBPO article 4. It is likely that any TMA
deployed for the purposes of processing BPO-related
transactions will also be able to process the other ISO
20022 TSMT messages, as defined in Chapter 2. These
messages are not directly related to the BPO but
nevertheless form an essential part of the overall
transaction workflow, which also incorporates
acknowledgements and reports.
Participation in a TMA scheme is limited to banks only.
The adoption of mandatory ISO 20022 TSMT messaging
standards and the URBPO is only applicable to the
exchange of data between an Involved Bank and a TMA
(see Figure 9). There are no mandatory rules or
standards that apply to the exchange of contracts and/
or documents between a buyer and a seller. These
exchanges will commonly be paper-based. Similarly,
there are no mandatory rules or standards that apply to
the exchange of data between a corporate and a bank.
This data can be exchanged using any standard, any
format and via any preferred channel as may be agreed
between the parties concerned.

Paper documents
Buyer Seller
No mandatory TMA No mandatory

TABLE OF CONTENTS
standards standards
No mandatory No mandatory
channels channels
No mandatory ISO 20022 ISO 20022 No mandatory
solutions TSMT TSMT solutions
URBPO
Buyer’s Bank/ Seller’s Bank/
Obligor Bank Recipient Bank
Figure 9: The adoption of mandatory ISO 20022 TSMT messaging

standards and the URBPO is only applicable to the exchange of data
between an Involved Bank and a TMA.
3.1 TMA SUBSCRIPTION

Any bank wishing to engage in BPO business in order to
deliver BPO-based services to its corporate customers
must first subscribe to a TMA. In order to exchange
BPO-related data, banks must be subscribed to the
same TMA scheme.
INDEX
Often, there will be an annual subscription fee to be paid

in order to be a member of the TMA scheme.
Subscription to a TMA will normally be restricted to
eligible financial institutions only. The operator of the
TMA scheme will determine the eligibility criteria.
The operator of the TMA scheme will maintain a
directory of its members so that any bank joining such a
scheme can see who the other members are.
Banks subscribing to a TMA scheme should familiarise
themselves with the terms and conditions attached to
the operation of such scheme, including any specific
operating requirements and notice periods.
Where appropriate, an Involved Bank may wish to
consider the impact of such terms and conditions on
any contractual obligations entered into with a corporate
customer insofar as those obligations may be reliant
upon the availability and performance of the TMA.

The Transaction Matching Application
3.2 TMA ROLES

Banks subscribing to a TMA may assume one or more of
the following roles. These roles are referred to
collectively as “Involved Banks” (as per Table L).
Buyer’s The bank of the buyer. The Buyer’s Bank may also be an Obligor
Bank Bank.
TABLE OF CONTENTS
Seller’s The bank of the seller. The Seller’s Bank will be indicated as
Bank the Recipient Bank in the Payment Obligation Segment of an
Obligor The bank that issues a BPO. The Obligor Bank may be the Buyer’s
Bank Bank and/or another bank that has been invited to take on this role.
Recipient The beneficiary of a BPO. Under current rules, the Recipient Bank is
Bank always the Seller’s Bank.
Submitting A bank whose only role is to submit one or more Data Sets required
Bank by an Established Baseline. For example, a branch of the Seller’s
Bank located in another country.
Table L: The possible roles of Involved Banks in a TMA transaction.
3.3 TMA TRANSACTION STATES

As a transaction passes through the various stages of
processing within a TMA, its status will change. Table M
is indicative of some of the “TMA transaction states” that
might apply at any given time:
TMA Transaction TMA Description

State
INDEX
Proposed An Initial Baseline Submission has been received from a

Buyer’s Bank or a Seller’s Bank.
Partially matched After Baseline ReSubmission by a Buyer’s Bank or a Seller’s

Bank (as applicable), some of the data elements in the two
Baselines match but others do not.
Established The Baseline ReSubmission matches exactly the Initial

Baseline Submission. The TMA issues a Baseline Match
Report with Zero Mismatches to confirm that the Baseline is
“established”.
Active Data Sets have been submitted for matching to an Established

Baseline.
Amendment An Involved Bank has proposed an amendment to a Baseline

Requested that the other Involved Banks must either accept or reject.
Status Change A Buyer’s Bank or a Seller’s Bank has requested a change in

Requested status that the counterparty bank must either accept or reject.
Complete All Data Sets have been matched successfully against the
Established Baseline. The Baseline can now be re-opened or
closed.
Closed With the exception of a report request, no further action is

possible.
Table M: The possible states of a TMA transaction.

A change of status will normally arise as a result of a

Data Match, a Baseline Amendment, a Status Change
Request or a timing violation.
Every TMA transaction starts with an Initial Baseline
Submission message sent by either a Buyer’s Bank or a
Seller’s Bank. The Initial Baseline Submission message
TABLE OF CONTENTS
may or may not contain a BPO in the form of a Payment

Obligation Segment. Whilst it is technically possible to
create a Baseline using data extracted from an invoice, it
is common practice to make use of data extracted from
the purchase/sales order.
If the Payment Obligation Segment is missing, it may be
added at a later date by way of a Baseline Amendment
to which Involved Banks must agree.
On receipt of an Initial Baseline Submission message, the
TMA will send an Acknowledgement message that
includes a unique Transaction Identifier.
A transaction can be closed before establishment. In this
case, the submitter of the Initial Baseline Submission
message should submit a Status Change Request
message to the TMA.
To close a transaction after establishment, either the
Buyer’s Bank or the Seller’s Bank must submit a Status
Change Request message to the TMA. The TMA will
send a Status Change Request Notification message to
the counterparty bank.
INDEX
If the counterparty bank agrees, it will send a Status

Change Request Acceptance message to the TMA and
the transaction will be closed.
3.4 TMA DATA SETS

In accordance with ISO 20022 TSMT messaging
standards, there are five types of Data Set that can be
submitted to a TMA for comparison to a Baseline:
commercial (based on data extracted from a
commercial invoice)
transport
insurance
certificate
other certificate
It is possible to submit a Data Set for comparison to
more than one Baseline. For example, a single invoice
may need to be matched to multiple purchase orders.

3.5 TMA MINIMUM FIELDS
3.5.1 Baseline
The minimum fields required to establish a Baseline are:
Transaction reference
Purchase order reference
TABLE OF CONTENTS
Buyer name and country

Buyer’s Bank identifier code (BIC8)
Seller’s name and country
Seller’s Bank identifier code (BIC8)
Goods: quantity and amount per line item
Payment terms
Commercial Data Set submitting bank identifier code
(Seller’s Bank or Submitting Bank)
BPO (optional)
Obligor Bank
Recipient Bank
amount
expiry date
Contact person (either Buyer’s Bank or Seller’s Bank)
3.5.2 Commercial Data Set

Transaction reference
Commercial Data Set Identifier
INDEX
Invoice number and issue date

Buyer name and country
Buyer’s Bank identifier code (BIC8)
Seller’s name and country
Seller’s Bank identifier code (BIC8)
Payment terms
Goods: quantity and amount per line item
Settlement terms: Identification of Creditor Account

3.5.3 Transport Data Set

Transport Data Set Identifier
Consignor: name and country
Transport document reference and date of issue
Proposed or Actual Shipment Date
Transport: at least one Port of Origin and one
TABLE OF CONTENTS
Destination
3.5.4 Insurance Data Set

Insurance Data Set Identifier
Issuer of insurance policy: name and country
Issue date
Insurance document reference
Insured amount
Assured party: bank identifier code (BIC8) or name
and address
Where claims payable
3.5.5 Certificate Data Set

Certificate Data Set Identifier
Certificate identification
Certificate type
Certified characteristics
INDEX
Issuer of certificate: name and country

Issue date
3.5.6 Other (Certificate) Data Set

Certificate Data Set Identifier
Certificate identification
Certificate type
Issuer of certificate: name and country
Issue date

3.6 TMA ESTABLISHMENT OF A BPO

A BPO is an optional part of a Baseline (see Figure 10). It
contains very few data elements:
The Obligor Bank: the bank that has to pay under the
obligation.
The Recipient Bank: the bank that will be paid under
TABLE OF CONTENTS
the obligation.
The amount: the maximum amount that will be paid
under the obligation.
The percentage: the maximum amount that will be
paid under the obligation, expressed as a percentage
of the Established Baseline.
The charges: the amount of charges to be deducted
by the Obligor Bank.
The charges percentage: the amount of charges to
be deducted by the Obligor Bank, expressed as a
percentage of the amount paid by the Obligor Bank.
Expiry date: the latest available date of the BPO.
Applicable law: country of the law governing the BPO.
Payment terms (payment code, percentage and
amount): details of payment processes required to
transfer value, including amount before deduction of
charges etc.
Settlement terms: instructions stipulating the transfer
of value.
INDEX

◆ Obligor Bank
BICIdentification1
◆ Recipient Bank
BICIdentification1
◆ Amount
CurrencyAndAmount
1
◆ Percentage
PercentageRate
TABLE OF CONTENTS
◆ ChargesAmount
CurrencyAndAmount
◆ ChargesPercentage
PercentageRate
◆ PaymentObligation ◆ ExpiryDate
PaymentObligation1 ISODate
◆ ApplicableLaw
CountryCode
◆ OtherPaymentTerms
Max140Text
1
◆ PaymentCode
◆ PaymentTerms PaymentPeriod2
PaymentTerms2
◆ Percentage
PercentageRate
1
◆ Amount
CurrencyAndAmount
◆ SettlementTerms
SettlementTerms2
Figure 10: A BPO is an optional part of a TMA Baseline. Source: SWIFT
The “other payment terms” field has space for 140

characters of free text that are capable of being
matched character-by-character by a TMA. It is
interesting to note that this field creates a potential
INDEX
opportunity for banks to qualify their obligations,

provided the text used in each Baseline Submission
matches precisely so as to reflect a common
understanding of the exact same payment conditions.
For example, a Buyer’s Bank acting as an Obligor Bank
could propose wording to the effect that “this BPO is
payable if the buyer does not pay the seller”.
Alternatively, an Obligor Bank other than a Buyer’s Bank
may qualify its obligation by adding the words “this BPO
is payable if the Buyer’s Bank does not pay the Seller’s
Bank”. Such qualifications in payment conditions may
permit banks to take advantage of an added degree
of flexibility when entering into an undertaking
of this nature.
By repeating the payment code and percentage fields it
is also possible for an Obligor Bank to indicate how it
may intend to effect payment at set intervals, e.g. 25% at
the end of January and 75% at the end of March.

BPO establishment based on matching of PO data

Initial Baseline Submission and ReSubmission
(including BPO)
Baseline Match Report (Zero Mismatches) TMA
BPO is irrevocable and conditional subject
TABLE OF CONTENTS
to matching of specified data
Data Set Submission

Data Set Submission
Possible Baseline Amendments TMA
Possible Mismatch Acceptance Or Rejection
Data Set Match Report (Zero Mismatches)
On successful completion of Data Match,

the Bank Payment Obligation becomes due.
The Obligor Bank must either pay or incur
a deferred payment obligation to pay at maturity
Payment and settlement
Payment (quoting BPO references)
Figure 11: The BPO transaction lifecycle.
It should be noted that the TMA does not create a BPO.

The TMA notifies an Involved Bank of the BPO’s
existence, reflecting the agreement of an Involved Bank
to participate in a transaction that includes a BPO.
INDEX
Involved Banks are notified of the Data Match conditions

that must be met in order for the BPO to become a
legally enforceable, irrevocable obligation when the TMA
generates a Baseline Match Report with Zero
Mismatches (see Figure 11).
The TMA subsequently permits the Submission of Data
Sets by an Involved Bank. The Submission of Data Sets
is automatically compared to an agreed set of
requirements, referred to in the URBPO as an
Settlement of the BPO eventually takes place outside
the TMA. For reconciliation purposes, it is recommended
to make use of a structured narrative field including the
unique TMA transaction identifier and related invoice
number reference when effecting payment. Such
narrative would normally be applied in field 70 of a
SWIFT MT 103 or field 72 of a SWIFT MT 202.
The messages and data exchanged via the TMA do not
represent or establish a contract. The TMA does not

make any business decisions. Therefore, any obligations

entered into between Involved Banks, their corporate
customers and other third parties, and any disputes
arising from such obligations, are beyond the scope of
the TMA.
Data exchanged via a TMA will not replace or be used in
TABLE OF CONTENTS
substitution of physical documents. There is no

mandatory dematerialisation. In the vast majority of
cases, physical documentation will continue to exist. As
noted in Chapter 4, this represents a key difference
between the URBPO and the eUCP.
Whereas the eUCP acts as a supplement to the UCP,
providing a framework for the electronic presentation of
the equivalent of paper documents and rules that enable
the UCP and the eUCP to work together, the URBPO
provides a similar framework for the electronic
presentation of data that has been extracted from the
underlying documents.
3.7 TMA DATA AND MESSAGE MATCHING RULES

In addition to the ICC rules (URBPO) and ISO messaging
standards (ISO 20022 TSMT), which exist in the public
domain, there will most likely be a variety of rules that
are proprietary to each TMA.
These will include the rules of the message matching
scheme as reflected in the terms and conditions of
membership, plus a set of matching rules to determine
INDEX
how the data submitted will be matched (see Figure 12).

For example, a set of message matching rules may be
used to place restrictions and rules on message
elements that cannot be expressed in the message
structure or schema.
General matching rules may be used to describe rules
that are valid for an entire message. The validation of
such restrictions and rules will generally form part of the
functionality of the TMA.

Terms & Conditions

of TMA Service
To use a BPO a financial institution
must subscribe to a matching scheme
and abide by the operational rules
of that matching scheme as defined
by the scheme operator
TABLE OF CONTENTS
TMA Message Matching Rules

When exchanging data with the
The URBPO are an industry- matching application the financial
wide set of rules which provide institution must ensure that the data
a framework for financial conforms to the message matching
institutions participating rules which are specific to the
to a BPO transaction matching scheme
Figure 12: In addition to the URBPO, users must consider the terms and
conditions of the TMA and any specific matching rules that may be pro-
prietary to that TMA.
Restrictions and rules applied to individual messages

can be represented in various ways. For example, it is
common practice to specify whether information in a
message is mandatory or optional or whether the
information has to be submitted in the form of a code
rather than as text.
It is normal for some data elements to be designated as
“core”, i.e. those elements that must always be present
and must always be matched.
INDEX
At the same time, it can be advantageous to limit the

number of mandatory elements so as to provide the
user with a certain amount of flexibility in relation to the
complexity of the matching process.
Matching rules are used to describe whether or not a
message element must match (a) with the exact same
message element of another message or (b) with the
exact same or different message element of another
message. The matching rules will also determine how a
match will be made, i.e. “strictly” or “loosely”.
“Matching strictly” means that the content of one field
has to be exactly the same as the content of the
corresponding field to which it is being matched, i.e. the
elements to be matched are compared character by
character and only when both values are identical will it
be considered a match. Most data elements will be
matched strictly.
“Matching loosely” means that upper and lower cases,
spaces and punctuation will not be considered when

matching the content of the data elements. All

characters except alphabetical and numerical characters
are regarded as punctuation.
In each case, the TMA will normally perform a certain
amount of processing in advance of matching, for
example to remove leading and trailing spaces or to
TABLE OF CONTENTS
convert selected elements, such as time and date, to

their XML canonical representations. This minimises the
risk of “false positives” arising in the matching process.
3.8 TMA PRE-MATCH

In some circumstances, a Seller’s Bank may wish to
present a Data Set for matching but avoid making the
results visible to the Buyer’s Bank, for example to keep
open the possibility of adding a BPO at a later date. A
BPO cannot subsequently be created if the data
specified in the Baseline has already been matched and
reported back to all Involved Banks.
This objective is achieved by submitting the Data Set as
a “pre-match”. In this case, the TMA will send the Data
Match Report back to the Seller’s Bank only. The status
of the transaction remains unchanged and a Baseline
Amendment Request to add a BPO remains a possibility.
3.9 TMA BASELINE AMENDMENTS

In accordance with the URBPO, only a Buyer’s Bank or a
Seller’s Bank/Recipient Bank may request an
INDEX
amendment or accept a request to amend an

Established Baseline. Any proposal to amend must be
accepted in its entirety or rejected. It is not possible to
partially accept a Baseline Amendment Request.
If a Baseline involving a Submitting Bank is subject to a
Baseline Amendment Request, the TMA will inform the
Submitting Bank by sending a Full Push Through Report
and a Delta Report listing any differences between the
Established Baseline and the newly proposed Baseline.
The Submitting Bank is not required to accept or reject
the amendment but, if applicable, must confirm its role
by submitting a Role and Baseline Acceptance message
to the TMA.
If a Baseline involving an Obligor Bank that is not the
Buyer’s Bank is amended, the TMA will similarly inform
the Obligor Bank by sending a Full Push Through Report
and Delta Report.

In this case, the Obligor Bank must respond with either a

Role and Baseline Acceptance message or a Role and
Baseline Rejection message.
A Role and Baseline Acceptance message confirms the
Obligor Bank’s explicit acceptance of the amendment
and its continued acceptance of its role in light of the
TABLE OF CONTENTS
amended Established Baseline.

If the Obligor Bank submits a Role and Baseline
Rejection message, the Baseline will remain unchanged
and the Obligor Bank’s responsibilities will also remain
unchanged in the context of the previously agreed
Baseline. In this case, the Buyer’s Bank and Seller’s Bank
must either continue to work under the Established
Baseline, consider an alternative form of amendment
(e.g. to replace the Obligor Bank) or agree to close
the transaction.
3.10 TMA MISMATCH ACCEPTANCE AND REJECTION

If a Data Set contains a Data Mismatch, the TMA will
advise all of the Involved Banks by sending a Data Set
Match Report highlighting any areas of inconsistency. A
Buyer’s Bank can accept a Data Mismatch by sending a
Mismatch Acceptance message to the TMA.
If the Buyer’s Bank is the only Obligor Bank, the TMA will
recalculate the Baseline to accommodate the required
changes. In this case, the transaction state will change to
“complete”. If the Buyer’s Bank wishes to reject a Data
INDEX
Mismatch, it will send a Mismatch Rejection message to

the TMA. In this case, the TMA will dispose of/ignore the
mismatched Data Sets and the Baseline will remain
unchanged with a status of “active”. Mismatches are
always accepted in full or rejected. It is not possible to
accept some mismatches and reject others.
If the Buyer’s Bank accepts a Data Mismatch but there is
a Submitting Bank and/or an Obligor Bank other than
the Buyer’s Bank, the TMA will send a Mismatch
Acceptance Notification message to each Involved Bank.
If the Submitting Bank or the Obligor Bank agrees with
the Mismatch Acceptance, it will submit a Role and
Baseline Acceptance message to the TMA to confirm
such agreement and its continued role in light of the
Data Mismatch.
If the Submitting Bank or the Obligor Bank disagrees, it
can respond with a Role and Baseline Rejection
message. In this case, the Data Set Submission will be
discarded by the TMA and the mismatches will be

rejected. The Baseline will remain active pending further

submissions, such as another Data Set, a Baseline
Amendment or a Status Change Request.
3.11 TMA SINGLE SHIPMENTS

AND PARTIAL SHIPMENTS
TABLE OF CONTENTS
An Established Baseline will state whether or not partial

shipments are allowed.
A TMA will normally store Data Sets received until such
time as all Data Sets are present before carrying out a
comparison to the Established Baseline.
If a Data Match Report is required in advance of the
Submission of all Data Sets, it may be possible for the
Seller’s Bank or a Submitting Bank to flag its Data Set
Submission in such a way as to force the TMA to
perform a match and generate a report.
Shipment schedules are optional blocks of data in a
TMA Baseline. They may be captured at line item level or
at goods level. The line item may include an earliest and
latest shipment date. Alternatively, it may list the dates
for several individual shipments to be made. A TMA will
not permit shipment schedules to overlap within a line
item, so each line item must specify a discreet and
distinct time window for shipment.
3.12 TMA MULTIPLE OBLIGOR BANKS

INDEX
A BPO always relates to a single TMA transaction. A

single TMA transaction may contain multiple BPOs. Each
BPO is the obligation of one Obligor Bank.
If a single TMA transaction contains multiple BPOs, no
joint and several obligations are created between the
involved Obligor Banks.
If multiple Obligor Banks are involved in a single TMA
transaction, the amount due by each Obligor Bank is
proportional to its share of the total of all BPO amounts.
For example, the combined amounts of the BPOs of two
Obligor Banks may be less than the total value of the
transaction as reflected in the Established Baseline.
Table N provides an illustration of how the amounts due
from each Obligor Bank would be calculated in the
event of multiple shipments.
In this example, the Baseline has been established with a
value of 100. Bank A has issued a BPO with a value of 30
and Bank B has issued a BPO with a value of 60.

Amounts Amount owed to the Amount owed to the

Recipient Bank by Bank A Recipient Bank by Bank B
1st shipment = 27 27 x (30 / 100) = 8.1 27 x (60 / 100) = 16.2
2nd shipment = 21 21 x (30 / 100) = 6.3 21 x (60 / 100) = 12.6
Final shipment = 52 52 x (30 / 100) = 15.6 52 x (60 / 100) = 31.2

TABLE OF CONTENTS
Total = 100 Total = 30 Total = 60
Table N: Illustration of a multi-bank BPO.
In the course of the three combined shipments, the full

amount of 100 has been shipped (27 + 21 + 52 = 100). At
the same time, each Obligor Bank has fulfilled its
obligations (Bank A: 8.1 + 6.3 + 15.6 = 30; Bank B: 16.2 +
12.6 + 31.2 = 60).
If there are Obligor Banks other than the Buyer’s Bank
and a Data Mismatch has been found, the Buyer’s Bank
must first accept the mismatch.
Secondly, all Obligor Banks must confirm their
acceptance of a Data Mismatch by submitting a Role
and Baseline Acceptance to the TMA.
The TMA will then issue a Role and Baseline Acceptance
Notification to all Involved Banks, indicating that all
Obligor Banks have affirmed their continued roles. In the
case of a Baseline Amendment Request where there are
Obligor Banks other than the Buyer’s Bank, the TMA
INDEX
must send a Role and Baseline Acceptance Notification

to all Involved Banks, notifying them that each Obligor
Bank has affirmed its continued role in light of the
amended Established Baseline.
Having multiple BPOs for a single transaction creates a
wider opportunity for trade asset distribution, for
example in a lead bank model (see Figure 13).
In the current economic climate, there is evidence
of an increasing demand for this kind of risk
distribution structure.
In a BPO “club”, the buyer could, for example, instruct
one bank (the Buyer’s Bank) to assume the role of lead
Obligor Bank and propose to invite other Obligor Banks
to assume a share of the risk on a pro rata basis. Of
course, the Seller’s Bank must also accept each of those
other banks as an Obligor Bank before those banks can
be invited to assume an active role in the transaction.

Buyer informs lead Obligor

Bank of investor bank shares
Buyer Seller
Lead Recipient
Obligor Bank Bank
TABLE OF CONTENTS
e.g. Buyer informs

the ‘club’ of investor
banks of their pro rata
share in the BPO
Risk participation
Obligor Bank Obligor Bank Obligor Bank Obligor Bank
Figure 13: Multiple BPOs create an opportunity for trade asset distribution.
There are a number of ways of facilitating risk

participation. It can also be arranged on the initiative of
the Seller’s Bank/Recipient Bank.
3.13 TMA SPECIAL MESSAGES

A Special Request message may contain one of the
following codes:
CSDS: Cannot Submit Data Set
INDEX
MWFT: Must Withdraw From Transaction

A Special Request message containing the code CSDS
may be sent by a Submitting Bank to notify other
Involved Banks of its inability to submit the required
data in accordance with the agreed terms of the
A Special Request message containing the code MWFT
may be sent by an Involved Bank to notify other
Involved Banks of a circumstance of force majeure.
In each case, the TMA will notify the other Involved
Banks by sending a Special Notification message. The
status of the transaction remains unchanged pending
the further instructions of the other Involved Banks, for
example to amend the Baseline.

3.14 TMA REPORTING

All TMAs will have their own procedures in place
regarding the generation of reports. Some reports may
be generated automatically upon the occurrence of an
event, for example a Data Set Match Report after a
comparison of data with an Established Baseline. Other
TABLE OF CONTENTS
reports may only be generated on request, for example

an Activity Report covering all transactions on which
some form of activity has taken place within a specified
period of time and in which the bank requesting such
report is involved.
3.15 TMA DATA STORAGE

A TMA must maintain a complete audit trail of all
messages sent and received. Messages exchanged via a
TMA may be considered admissible as evidence as
required in case of dispute. However, the TMA itself does
not act as a system of record in the context of
regulatory compliance.
3.16 TMA TIMERS AND TIME VIOLATIONS

A TMA will have its own rules with regard to timers
and time-outs. The functionality of a TMA should include
the ability to generate warning messages and reminders
automatically if an action is required or a response
is overdue.
INDEX

Chapter 4
The Uniform Rules for

TABLE OF CONTENTS
The scope of the Uniform Rules for Bank Payment

Obligations (URBPO) relates solely to the interactions
that must take place between Involved Banks and the
TMA. Use of the URBPO and ISO 20022 standards is
only mandated between banks. There will normally be
an agreed collaboration between a buyer and a seller in
the selection of the BPO as the selected term of
payment.
There is competition between banks in terms of the level
of service they can offer to the corporate in respect of
risk mitigation, financing, payment assurance, process
efficiency, price and so forth. In this competitive space,
there are no rules or mandatory standards. Banks and
corporates are free to negotiate their own terms by way
of bilateral forms of agreement.
There is collaboration between banks in terms of the
establishment of a BPO subject to the matching of
specified data elements through a shared TMA. In this
INDEX
collaborative space, the adoption of URBPO and ISO

20022 TSMT messaging standards is mandatory.
One of the advantages of putting in place a globally
recognised and accepted set of industry standard rules
is that Involved Banks can reduce if not avoid altogether
the need to negotiate supplementary bilateral
agreements between themselves, other than on an
exceptional basis.
4.1 KEY POINTS

The BPO is an alternative instrument for trade
settlement. It is designed to complement existing
solutions and not to replace them.
Similar to a letter of credit under the UCP, a
collection under the URC and a guarantee under the
URDG, the actual settlement of a BPO is outside the
scope of the URBPO.

The Uniform Rules for Bank Payment Obligations
The URBPO exist in the bank-to-bank space. The

rules do not cover the interaction between a bank
and its corporate client.
The interaction between banks is seen to be within a
collaborative space, where the banks use a common
TMA to achieve a Data Match, and for this purpose
the rules offer clear guidelines. The bank to corporate
TABLE OF CONTENTS
relationship is seen to be within a competitive space,

where the banks are able to differentiate themselves
by way of the products and services that they offer
based on the strength of a BPO having been issued.
4.2 KEY DIFFERENCES BETWEEN THE URBPO

AND THE UCP/EUCP
Over the years, the International Chamber of Commerce
(ICC) has established itself as an essential part of the
global economy. In this pivotal role, it forges
international rules, mechanisms and standards that are
used every day throughout the vastly complex world of
international trade and business.
The ICC Uniform Customs and Practice for Documentary
Credits (commonly known as “UCP”) is now in its sixth
revision since first being promulgated in 1933. It remains
the most successful set of private rules for trade ever
developed and is now supplemented by the eUCP to
cover the possibility of documents under a letter of
credit being presented electronically.
INDEX
Table P is designed to capture some of the key

differences between the UCP/eUCP and the URBPO.
Whereas the UCP relates to documentary trade and the
routing of physical documents through the banking
system, the URBPO is designed to support “bank-
assisted open account” trade where physical documents
will continue to exist but are sent directly from the seller
to the buyer.
Instead of examining physical documents, the banks
will rely upon Data Match Reports generated by a
common TMA.
In comparison to the UCP, the URBPO is a relatively
short and simple set of rules. The concise nature of the
URBPO reflects the relative simplicity of the rules
required to govern the electronic processing of data in
an automated environment compared to the complexity
of manually processing significant volumes of
paper documents.
The important thing to bear in mind is that the URBPO is

an independent set of rules whereas the eUCP is to be

read as a supplement to the UCP. As such, the eUCP
applies to letter of credit transactions in which the
documents themselves have been dematerialised,
including the optional possibility of document scanning
and imaging. There are no mandatory standards for the
exchange of data under eUCP. Hence, the data will not
TABLE OF CONTENTS
necessarily be available in a format suited to

electronic matching.
On the other hand, data presented under the URBPO is
not designed to replace physical documents but simply
to allow the data elements extracted from those
documents to be structured in such a way as to support
electronic matching according to an agreed set of
industry standards (ISO 20022 TSMT).
This allows the documents to be sent directly to the
buyer by the seller rather than through the banking
system, so that any banking service that is provided on
the strength of the data matched in a TMA and made
subject to the URBPO will therefore qualify as “bank-
assisted open account”.
INDEX

Rules UCP eUCP URBPO
Coverage Letters of credit Letters of credit Bank-assisted open

account
Length 50 pages 10 pages 10 pages
Scope Deals with Deals with data Deals with data not
TABLE OF CONTENTS
documents not not goods goods

goods
Issuance L/C will normally A BPO may be

be established at added at any time
the outset of a through a Baseline
transaction Amendment
Obligations Bank to corporate Supplements Bank to bank

UCP
Discrepancies Release of Mismatches may

documents may be accepted
be withheld by the without delay
Issuing Bank pending through Mismatch
receipt of waiver Acceptance and
from the applicant Role and Baseline
Acceptance
Confirmation L/C may be “Confirmation” of a

confirmed or BPO will normally be
unconfirmed by way of a separate
agreement between
Seller’s Bank and
seller
Documents Paper documents Possible Data elements are

only dematerialisation extracted from paper
of paper documents
documents,
INDEX
including
scanned images
Standards Paper None Mandatory ISO

20022 TSMT
Platform Paper Technology Technology neutral

neutral (file (TMA)
transfer)
Table P: The key differences between the UCP, eUCP and URBPO.

ARTICLE 1
Scope
a. The ICC Uniform Rules for Bank Payment Obligations
(URBPO) provide a framework for a Bank Payment
Obligation (BPO). A BPO relates to an underlying trade
transaction between a buyer and seller with respect to
TABLE OF CONTENTS
which Involved Banks have agreed to participate in an

Established Baseline through the use of the same
Transaction Matching Application (TMA).
b. The URBPO do not provide the basis for determining
whether a Data Match or Data Mismatch has occurred.
This is determined by the functionality of the applicable
TMA and the terms and conditions applying to that TMA
as subscribed to by each Involved Bank.
Summary notes
The URBPO provide a “framework” in much the same
way as the UCP 600 provides a framework for
documentary letters of credit.
However, the scope is limited to bank-to-bank
undertakings in support of collaboration between
participating financial institutions, leaving banks to
compete in terms of their corporate service agreements.
References made to the “Transaction Matching
Application” (TMA) are technology neutral.
INDEX
Each bank must participate/subscribe to the same TMA.
Comments
Although it is not common to other ICC rules, the
Drafting Group considered, by way of exception, that
the URBPO should contain a statement of scope. This
approach is justified on the basis that the rules cover a
completely new financing tool. The reference that is
made to the relationship of the data to an underlying
trade transaction is considered necessary in the current
banking and regulatory environment and, in particular, to
address know-your-customer (KYC) principles. The
inclusion of the term “underlying trade transaction” does
not infer any relationship with the underlying contract,
nor should it be seen as creating a conflict with URBPO
articles 6 and 7.

It is important to remember that the scope of the

URBPO is limited to the exchange of data between
Involved Banks and the TMA in what is popularly known
as the “bank-to-bank space”. This is consistent with the
scope agreed in the memorandum of understanding
signed between the ICC and SWIFT in September 2011
and the terms of reference provided to the URBPO
TABLE OF CONTENTS
Drafting Group. This definition represents a material

difference between a BPO and a Documentary Credit.
The beneficiary or recipient of a BPO will always be the
Seller’s Bank, which is entitled to receive payment on
behalf of the seller.
Under Version 1.0 of the URBPO, the seller can never be
the direct beneficiary or recipient of a BPO. Therefore,
the exact terms under which the Seller’s Bank will
ultimately pass value to the seller will be captured in the
Service Agreement that must exist between these two
parties.
Given this prescribed limitation in scope, the URBPO are
consciously designed to support collaboration between
Involved Banks through the exchange of an agreed set
of structured data via a common TMA to which all of the
Involved Banks must subscribe.
Beyond this collaborative exchange of data through a
common platform, it is for each bank, in what may be
described as the “competitive” space, to offer its clients
financing or other products and services based on the
INDEX
strength of a BPO which that bank has either issued

or received.
A bank’s services should also define the manner in
which data is to be received and delivered, as well as the
output of such data in the form of reports and
spreadsheets, including those relating to the status of
individual transactions.
In a future revision of the rules, it remains possible that
the URBPO could be changed in order to allow a party
other than the Seller’s Bank (e.g. another bank or
eventually the seller itself) to become the recipient/
beneficiary of the BPO. This would, however, require
consistent changes to be made not only in the ISO
20022 messaging standards but also in the workflow
and design of a TMA and any related restrictions in the
governance of the TMA scheme as defined by the
operator of that scheme.

ARTICLE 2
Application
a. The URBPO are rules that apply to a BPO when the
Payment Obligation Segment within an Established
Baseline expressly states that it is subject to these rules
or when each Involved Bank agrees in a separate
TABLE OF CONTENTS
agreement that a BPO is subject to these rules. They are

binding on each Involved Bank unless expressly
modified or excluded by the Established Baseline or by
the separate agreement.
b. (i) If an Established Baseline or separate agreement
does not indicate the applicable version of URBPO,
the BPO will be subject to the latest version in effect
when the Baseline is established in accordance with
sub-article 9(d).
(ii) This is URBPO Version 1.0.
c. (i) The URBPO require use of the appropriate ISO
20022 Trade Services Management (TSMT)
messages registered with the International
Standards Organisation (ISO). Use of any other
message type means that the transaction is out of
scope of these rules.
(ii) Only those TSMT messages that are applicable to a
BPO are referred to in these rules.
INDEX
Summary notes
The issuer of the BPO is the Obligor Bank, which may or
may not be the Buyer’s Bank.
The beneficiary of a BPO is the Recipient Bank which is
always the Seller’s Bank.
A Baseline can be established with/without a BPO.
If the Baseline is first established without a BPO, the
BPO may be added later through a Baseline
Amendment.
The use of ISO 20022 TSMT messages is mandatory.
Currently, there is no field designated in the ISO 20022
TSMT messages to declare the applicability of the
URBPO.
An enhancement to these messaging standards will
need to be made in due course.

In the meantime, banks will need to agree between

themselves that the URBPO will be applied, modified
or excluded.
As in the case of the eUCP, version numbering has been
applied in recognition of the fact that electronic
solutions will evolve and develop more quickly than
TABLE OF CONTENTS
traditional paper-based solutions.
Comments
The BPO is not a message. Details of a BPO are to be
found only in the Payment Obligation Segment that
forms part of an Established Baseline.
As noted above, the beneficiary of a BPO is a bank,
known as the Recipient Bank, which under current rules
will always be the Seller’s Bank. A BPO may be added to
an Established Baseline at any time with the mutual
agreement of an Obligor Bank and a Recipient Bank.
This is another potential differentiator between a BPO
and a Documentary Credit. While there is nothing in
UCP 600 to preclude the possibility of a Documentary
Credit being issued at any time during the lifecycle of a
transaction, in practice the letter of credit is invariably
established at the outset as a means of mitigating risk
and remains extant for the duration of that transaction.
With the streamlined processing of electronic data
rather than the manual processing of physical
documents, it is a more practical possibility to defer the
INDEX
issuance of a BPO until such time as it may be required,

either to mitigate the risk of non-payment or to be used
as collateral for working capital finance. Delaying the
issuance of a BPO reduces the demand on buyer credit
lines and therefore brings advantages in terms of
reduced cost of capital.
The wording of sub-article 2(a) introduces the option
that applicability of the URBPO can either be indicated
within the ISO 20022 TSMT messages themselves or by
separate agreement between Involved Banks. As at the
time of writing, there is no field that currently exists
within the ISO 20022 TSMT messages to declare
applicability of the URBPO. An enhancement to address
this gap has been requested. Therefore, those banks
wishing to rely upon the URBPO will need to enter into a
bilateral agreement to that effect until such time as
the ISO 20022 TSMT messaging standards have
been changed.

As per sub-article 2(c)(ii), only the appropriately

registered ISO 20022 TSMT message types are to be
used under the URBPO. Use of any other message type
will invalidate the transaction for use under the URBPO.
Similar to other ICC rules such as the UCP and the
URDG, the URBPO may be modified or excluded by
TABLE OF CONTENTS
agreement of all the Involved Banks.

As electronic solutions are expected to evolve and
develop more quickly than paper-driven initiatives, the
URBPO have been given a version number. This is similar
to the concept first introduced in the eUCP (now on
Version 1.1).
It is felt that this approach will, for example, allow a
revision to be based solely on changes to one or two
articles, in order to reflect any significant changes in
market practice or industry standards.
ARTICLE 3
General Definitions
FOR THE PURPOSE OF THESE RULES:
“Bank Payment Obligation” or “BPO” means an
following Submission of all Data Sets required
by an Established Baseline resulting in a Data Match
INDEX
or an acceptance of a Data Mismatch pursuant to

sub-article 10(c).
“Banking Day” means a day on which an Involved Bank
is regularly open at the place at which an act subject to
these rules is to be performed by such Involved Bank.
“Baseline” means data in respect of an underlying trade
transaction submitted to a Transaction Matching
Application by a Buyer’s Bank or a Seller’s Bank.
“Buyer’s Bank” means the bank of the buyer. The Buyer’s
Bank may also be an Obligor Bank.
“Data Match” means a comparison of all required Data
Sets with an Established Baseline resulting in Zero
Mismatches as specified in a Data Set Match Report.
“Data Mismatch” means a comparison of all required
Data Sets with an Established Baseline resulting
in one or more mismatches as specified in a Data Set
Match Report.
“Data Set” means any of the categories (for example,

‘commercial’, ‘transport’, ‘insurance’, ‘certificate’ or ‘other

certificate’) included in a Data Set Submission sent to a
Transaction Matching Application by an Involved Bank
for comparison with an Established Baseline.
“Established Baseline” means a Baseline from the time
when a Transaction Matching Application sends a
TABLE OF CONTENTS
Baseline Match Report containing Zero Mismatches and

with the status ‘established’.
“Involved Bank” means a Seller’s Bank or Recipient Bank
(depending upon its role at any given time), a Buyer’s
Bank, an Obligor Bank or a Submitting Bank.
“Obligor Bank” means the bank that issues a BPO.
“Payment Obligation Segment” means the part of a
Baseline designated as ‘payment obligation’ that
incorporates the terms of the BPO including the terms
on which payment is to be made.
“Recipient Bank” means the bank that is the beneficiary
of a BPO. The Recipient Bank is always the Seller’s Bank.
“Seller’s Bank” means the bank of the seller. The Seller’s
Bank will be indicated as the Recipient Bank in the
Payment Obligation Segment of an Established Baseline.
“Submission” means (i) the act of a Buyer’s Bank or
Seller’s Bank presenting data by submitting a Baseline to
a Transaction Matching Application, or the Baseline so
submitted, as the context requires, or (ii) the act of an
INDEX
Involved Bank presenting data to an Obligor Bank by

means of submitting one or more Data Sets to a
Transaction Matching Application, or the Data Sets so
submitted, as the context requires.
“Submitting Bank” means an Involved Bank whose only
role is to submit one or more Data Sets required by an
“Trade Services Management (TSMT) messages” or
“TSMT messages” means ISO 20022 message types as
published under the trade services management
business area by the International Standards
Organisation (ISO).
“Transaction Matching Application” or “TMA” means any
centralised data matching and workflow application,
whether or not proprietary to an Involved Bank, which
provides the service of processing TSMT messages
received from Involved Banks, the automatic comparison
of the data contained in such messages, and the
subsequent sending of all related TSMT messages to
each Involved Bank.

“Universal Time Coordinated” or “UTC” means the

international time scale defined by the International
Telecommunications Union used by electronic
computing and data management equipment, and the
technical equivalent of GMT, Greenwich Mean Time, and
is the applicable time scale for a BPO.
TABLE OF CONTENTS
“Zero Mismatches” means that the data represented in

one Baseline match the data represented in a
corresponding Baseline or, as the context may indicate,
that all required Data Sets match the data required by
an Established Baseline.
Summary notes
Definitions have been differentiated from those in
traditional use, such as issuing bank, confirming bank
and so forth.
Comments
Similar to all recent revisions of ICC rules, the URBPO
includes a list of defined terms for the roles of the
various banks and other key terms used within the
scope of the rules. In order to differentiate the URBPO
from other ICC rules, terminology that is often
associated with existing rules, such as issuing bank,
advising bank, confirming bank and so forth, has not
been used. Instead, a new terminology has been
introduced. For example, the Obligor Bank in place of
the issuing bank.
INDEX
The TMA is the platform chosen by the respective banks

for the matching of data. This could in theory be the
SWIFT Trade Services Utility platform or any other
proprietary solution that is capable of processing the
prescribed ISO 20022 TSMT messages in accordance
with the required workflow.
For the sake of clarity, it should be noted that the term
“Bank Payment Obligation” is not subject to any
restrictions in terms of intellectual property rights, and it
is not mandated that the SWIFT Trade Services Utility
should be the only platform selected for the processing
of BPO-related transactions.

One of the less familiar terms in the URBPO is “Universal

Time Coordinated” or “UTC”. UTC is the recognised
network time protocol designed to synchronise with the
highest degree of accuracy possible the clocks and time
of computers all over the world. As such it may be
regarded as a modern-day scientific equivalent of
Greenwich Mean Time (GMT) and the natural choice of
TABLE OF CONTENTS
time scale to apply to BPOs.

With regard to the definition of “Data Set”, the reference
to “commercial, transport, insurance, certificate or other
certificate” is consistent with the messaging protocols
that exist within the ISO 20022 TSMT standards.
One interesting aspect that has been challenged and
may well be revisited at a later date and in a subsequent
version of the URBPO is the insistence that the Recipient
Bank must always be the Seller’s Bank.
This definition precludes the possibility of any
assignment of proceeds within the exchange of ISO
20022 messages through a TMA. Therefore, as things
stand today, such assignment would need to be
arranged separately.
From a technical point of view, there is no reason why
the system, and therefore the rules, could not be
changed so that the situation that prevails on the buyer
side (i.e. that it is possible to have an Obligor Bank
that is not the Buyer’s Bank) can be replicated on the
seller side (i.e. to allow for the possibility that the
INDEX
Recipient Bank may eventually be a bank other than

the Seller’s Bank).
Some observers have suggested that an Obligor Bank
should not allow any bank other than the Recipient Bank
to submit a Data Set for comparison to an Established
Baseline. This reflects some concerns regarding the
responsibility of a Submitting Bank and its potential
failure to input the required data correctly and on time.
The current version of the URBPO does recognise the
independent role of a third-party Submitting Bank
(often a branch of the Seller’s Bank but located in
another country) as a bank whose only role is to submit
data as required in an Established Baseline.
This allows an Involved Bank the discretion to decide for
itself whether this is acceptable or not in the context of
any given transaction.

ARTICLE 4
Message Definitions
“Amendment Acceptance” means a TSMT message sent
to a TMA by a Buyer’s Bank, a Seller’s Bank or a
Recipient Bank (as applicable) accepting a Baseline
Amendment Request.
TABLE OF CONTENTS
“Amendment Acceptance Notification” means a TSMT

message sent by a TMA to a Buyer’s Bank, a Seller’s
Bank or a Recipient Bank (as applicable) notifying it of
the acceptance of a Baseline Amendment Request.
“Amendment Rejection” means a TSMT message sent
Recipient Bank (as applicable) rejecting a Baseline
Amendment Request.
“Amendment Rejection Notification” means a TSMT
the rejection of a Baseline Amendment Request.
“Baseline Amendment Request” means a TSMT message
sent to a TMA by a Buyer’s Bank, a Seller’s Bank or a
Recipient Bank (as applicable) requesting an
amendment to an Established Baseline.
“Baseline Match Report” means a TSMT message sent
by a TMA to each Involved Bank (except an Obligor
Bank other than a Buyer’s Bank), after Submission of a
INDEX
Baseline, indicating an Established Baseline or that

mismatches have been found between two Baselines.
“Data Set Match Report” means a TSMT message sent
by a TMA to each Involved Bank after Submission of all
Data Sets required by an Established Baseline and the
automatic comparison of such Data Sets with that
Established Baseline, advising it of either a Data Match
or a Data Mismatch.
“Data Set Submission” means a TSMT message sent to a
TMA by an Involved Bank that contains one or more
categories of Data Set for data comparison.
“Full Push Through Report” means a TSMT message
sent by a TMA to each Involved Bank advising of a
proposed Baseline, an Established Baseline or a
proposed amendment to an Established Baseline.

“Mismatch Acceptance” means a TSMT message sent to

a TMA by a Buyer’s Bank accepting a Data Mismatch.
“Mismatch Acceptance Notification” means a TSMT
message sent by a TMA to each Involved Bank
notifying it of the acceptance of a Data Mismatch by a
Buyer’s Bank.
TABLE OF CONTENTS
“Mismatch Rejection” means a TSMT message sent to a

TMA by a Buyer’s Bank rejecting a Data Mismatch.
“Mismatch Rejection Notification” means a TSMT
message sent by a TMA to each Involved Bank notifying
it of the rejection of a Data Mismatch by a Buyer’s Bank.
“Role and Baseline Acceptance” means a TSMT message
sent to a TMA by a Submitting Bank, or an Obligor Bank
other than the Buyer’s Bank, accepting such bank’s role
as specified in the Baseline contained in a Full Push
Through Report.
“Role and Baseline Acceptance Notification” means a
TSMT message sent by a TMA informing each other
Involved Bank that a Submitting Bank, or an Obligor
Bank other than the Buyer’s Bank, has sent a Role
and Baseline Acceptance in response to a Full Push
Through Report.
“Role and Baseline Rejection” means a TSMT message
other than the Buyer’s Bank, rejecting such bank’s role
INDEX
Through Report.
“Role and Baseline Rejection Notification” means a
TSMT message sent by a TMA informing each Involved
Bank that a Submitting Bank, or an Obligor Bank other
than the Buyer’s Bank, has sent a Role and Baseline
Rejection in response to a Full Push Through Report.
“Special Notification” means a TSMT message sent by a
TMA to an Involved Bank notifying it of a Special
Request made by another Involved Bank.
“Special Request” means a TSMT message sent to a
TMA by (i) a Submitting Bank advising a reason that
prevents it from being able to submit a Data Set, or (ii)
an Involved Bank withdrawing from its role in an
Established Baseline due to force majeure (subject to
article 13).

Summary notes
All references to TSMT messages are to be interpreted
as ISO 20022 Trade Services Management messages.
Only those messages that are directly relevant to the
BPO message flows have been defined in the URBPO.
TABLE OF CONTENTS
Comments
All of the messages defined in the URBPO are part of
the official list of ISO 20022 TSMT messages as
published on the ISO website.
However, as shown in Chapter 2, this is just a subset of
messages that is limited to those terms that appear in
the body of the URBPO.
It is likely that other messages will need to be
exchanged between an Involved Bank and a TMA in the
course of completing a live transaction. However, those
other messages have no direct bearing on the relevance
or enforceability of the URBPO.
From time to time, the message definitions in use by ISO
will need to be changed to reflect changes in market
practice or industry standards. In this case,
commensurate changes to the URBPO will need to be
applied, as will any consequential effects arising from
such changes.
It is the responsibility of the ICC to ensure that the
URBPO remains at all times consistent with the design
INDEX
and definition of the ISO 20022 TSMT messaging

standards.
ARTICLE 5
Interpretations
FOR THE PURPOSE OF THESE RULES:
Where applicable, words in the singular include the
plural and in the plural include the singular.
Branches of an Involved Bank in different countries are
considered separate banks.
Summary notes
The rules have been written mainly in the singular as is
common practice in ICC rules.

Comments
The URBPO have been written, in the main, in the
singular. This rule follows a similar stance as taken in
other ICC rules (e.g. UCP 600 article 3), whereby the
singular can be taken to include the plural.
Within the design of a TMA it is likely that an Involved
TABLE OF CONTENTS
Bank will be identified by means of an individual branch

bank identifier code, for example the SWIFT BIC8. Each
individual BIC8 can be separately identifiable as an
Involved Bank.
Such interpretation is also consistent with the
established practice of other ICC rules (e.g. once again
UCP 600 article 3).
ARTICLE 6
Bank Payment Obligations v. Contracts

a. A BPO is separate and independent from the sale or
other contract on which the underlying trade transaction
may be based. An Involved Bank is in no way concerned
with or bound by such contract, even if any reference
whatsoever to it is included in an Established Baseline.
Consequently, the undertaking of an Obligor Bank is not
subject to claims or defences by the buyer resulting
from its relationship with an Involved Bank or the seller.
b. A Recipient Bank can in no case avail itself of the
contractual relationship existing between the buyer and
INDEX
the Buyer’s Bank or an Obligor Bank other than the

Buyer’s Bank.
Summary notes
This rule indicates the separateness of the Bank
Payment Obligation from the underlying contract.
Comments
This rule indicates the separate and independent nature
of the BPO from the underlying sale contract and
follows the wording and principles expressed in UCP
600 article 4 as adapted to suit the context of
the URBPO.

ARTICLE 7
Data v. Documents, Goods, Services or Performance

An Involved Bank deals with data and not with
documents, or the goods, services or performance to
which the data or documents may relate.
TABLE OF CONTENTS
Summary notes
Data may be based on/extracted from the physical
documents that will still exist in most cases.
However, the Involved Bank will not have any
responsibility towards those documents, goods, services
or performance to which the data relates.
Comments
This rule emphasises the general principle that an
Involved Bank has no responsibility towards the
documents, goods, services or performance to which
the data that it will input or receive relates.
It should be noted that the adoption of a BPO as the
agreed payment terms to a transaction does not imply
document substitution or replacement. It is anticipated
that, in the vast majority of cases, physical documents
will continue to be used and exchanged as part of the
physical supply chain process.
In parallel with this physical exchange of documents,
INDEX
data will be extracted and submitted electronically

through a TMA in order to determine whether or not the
terms and conditions of a BPO have been satisfied.
This is an aspect that distinguishes the URBPO from
the eUCP.
Whereas the eUCP acts as a supplement to the UCP
600 in order to accommodate the electronic
presentation of paper documents, the URBPO provides
a framework for the electronic presentation and
matching of data that has been extracted from paper
documents that, for the most part, continue to exist.

ARTICLE 8
Expiry Date of a BPO

a. An Established Baseline must state an expiry date for
the Submission of Data Sets.
b. All Data Sets required by an Established Baseline must
TABLE OF CONTENTS
be received by a TMA no later than 23:59:59 UTC on

such expiry date.
c. A data comparison will only occur after the Submission
of all Data Sets required by an Established Baseline.
A TMA will then send a Data Set Match Report to each
Involved Bank advising it of either a Data Match or
Data Mismatch.
Summary notes
The expiry date for a Bank Payment Obligation is the
last date for submission of data and not for the
completion of the matching process by a Transaction
Matching Application.
Comments
Similar to UCP 600 article 6, an expiry date for a BPO is
the last available date for submission of data and not for
the completion of the matching process by a
Transaction Matching Application.
The handling of data in an electronic environment
INDEX
removes the limitation of a bank only being able to act

solely within its stated hours of business.
The use of UTC allows for the adoption of a consistent
and standard timing protocol on a global basis.
ARTICLE 9
Role of an Involved Bank

a. When a TSMT message is received by an Involved Bank
on a day that it is closed for reasons other than those
referred to in article 13, the TSMT message will be
deemed to have been received on the first following
Banking Day.
b. When an Involved Bank is required to act upon a
message sent by a TMA it must do so without delay.
c. An Involved Bank is required to ensure that any data
submitted by it to a TMA accurately reflects the data it
has received from a buyer or seller of goods, services
or performance in connection with an underlying
trade transaction.

d. A Baseline incorporating a BPO will only become an

Established Baseline after each Involved Bank has
accepted is role:
(i) When the Buyer’s Bank is the only Obligor Bank:
when a TMA sends a Baseline Match Report with
Zero Mismatches confirming that the Baseline
TABLE OF CONTENTS
submitted by a Buyer’s Bank matches the Baseline

submitted by a Seller’s Bank or Recipient Bank (as
applicable); or
(ii) When an Obligor Bank, other than the Buyer’s
Bank, is the only Obligor Bank: when a TMA sends
a Role and Baseline Acceptance Notification
confirming that such Obligor Bank and, if applicable,
a Submitting Bank, has accepted its role as specified
in the Baseline Submission of both the Buyer’s Bank
and the Seller’s Bank or Recipient Bank (as
applicable). The sending of such a notification will
follow a TMA sending a Baseline Match Report with
Zero Mismatches; or
(iii) When there is more than one Obligor Bank that
may include the Buyer’s Bank: when a TMA sends a
Role and Baseline Acceptance Notification
confirming that each Obligor Bank and, if applicable,
a Submitting Bank, has accepted its role as specified
in the Baseline Submission of both the Buyer’s Bank
INDEX

Zero Mismatches.
Summary notes
A TMA will send periodic reminders in respect of
outstanding actions.
An Involved Bank has a responsibility to ensure that data
is unchanged.
Comments
Sub-article 9(a) reflects the position that, if a bank is
closed due to a weekend, national holiday or similar (but
not due to a force majeure event as covered by article
13), TSMT messages will still be delivered. However, these
messages are not considered as having been received
until the next Banking Day.

Sub-article 9(b) requires that a bank receiving a

message from a TMA on which it is required to act
should do so without delay. The TMA should, as part of
its standard service and within the prescribed workflow
of its transaction processing (and not as a result of any
reliance placed on the URBPO), send periodic chasers
to the bank in question in order to prompt an
TABLE OF CONTENTS
appropriate action.
Use of the term “without delay”, while lacking a clear
definition, is consistent with the concept and meaning of
such expression in other ICC rules, e.g. UCP 600 article
9. It should be noted that the wording of this article
refers to the requirement to act upon the content of any
message received and not necessarily the execution
of a payment.
It may be argued that it would be preferable for sub-
article 9(b) to mandate that an Involved Bank must act
within a specific timeline, e.g. one Banking Day. However,
the enforcement of such a rule would require there
to be an enforceable penalty for not acting within the
given time.
In practice, there is no penalty that can reasonably be
inflicted so as to compel a bank to act at a given time.
Therefore, the term “without delay” is the most effective
wording possible in this context. It may be possible for
individual buyers and sellers to agree terms with their
service providers that would effectively compel them to
INDEX
act at a given time. This is a matter for individual

negotiation.
Sub-article 9(c) reaffirms that an Involved Bank has a
responsibility to ensure that any data submitted to a
TMA is unchanged from that received from their
corporate customer or other trusted source. This follows
the concept in UCP 600 sub-articles 9(b) and (c) that
the data should always reflect what has been received.
Sub-article 9(d) outlines the determination of when an
Involved Bank has accepted its role. This will vary
according to whether the Buyer’s Bank is the one and
only Obligor Bank, whether a bank other than the
Buyer’s Bank is the one and only Obligor Bank or
whether there are multiple Obligor Banks.

ARTICLE 10
Undertaking of an Obligor Bank

a. An Obligor Bank is irrevocably bound in accordance
with a BPO:
(i) when a BPO is incorporated in an Established
TABLE OF CONTENTS
Baseline at the time of its establishment: as of the

time a TMA has sent either a Baseline Match Report
with Zero Mismatches or a Role and Baseline
Acceptance Notification with the status ‘established’
to each Involved Bank pursuant to sub-article 9(d);
or
(ii) when a BPO is incorporated by an amendment to
an Established Baseline: as of the time a TMA has
sent either an Amendment Acceptance Notification
or a Role and Baseline Acceptance Notification to
each Involved Bank pursuant to sub-article 11(c).
b. A BPO always relates to a single Established Baseline.
An Established Baseline may contain more than one
BPO and each BPO is the obligation of one Obligor
Bank.
c. An Obligor Bank must pay or incur a deferred payment
obligation and pay at maturity a specified amount to a
Recipient Bank in accordance with the payment terms
specified in the Payment Obligation Segment of an
Established Baseline if, following the Submission of all
Data Sets required by an Established Baseline on or
INDEX
before the expiry date of the BPO specified in the

Established Baseline and following a data comparison:
(i) there is a Data Match; or
(ii) there is a Data Mismatch and the Buyer’s Bank is
the only Obligor Bank: when a TMA acknowledges
the Mismatch Acceptance of the Buyer’s Bank by
sending a Mismatch Acceptance Notification to a
Recipient Bank; or
(iii) there is a Data Mismatch and an Obligor Bank,
other than the Buyer’s Bank, is the only Obligor
Bank: when the Obligor Bank and, if applicable, a
Submitting Bank has affirmed its role by sending a
Role and Baseline Acceptance to a TMA and a TMA
acknowledges it by sending a Role and Baseline
Acceptance Notification to each Involved Bank. The
sending of such a notification will follow a TMA
acknowledging the Mismatch Acceptance of the
Buyer’s Bank by sending a Mismatch Acceptance
Notification to each Involved Bank; or

(iv) there is a Data Mismatch and there is more than

one Obligor Bank that may include the Buyer’s
Bank: when
a) a TMA acknowledges the Mismatch Acceptance
of the Buyer’s Bank by sending a Mismatch
Acceptance Notification to each Involved Bank;
and
TABLE OF CONTENTS
b) the Obligor Bank and, if applicable, a Submitting

Bank, has affirmed its role by sending a Role and
Baseline Acceptance to a TMA and a TMA
Acceptance Notification to each Involved Bank.
d. (i) The total amount due by an Obligor Bank to a
Recipient Bank shall not exceed the amount of
its BPO.
(ii) When a Submission relates to a partial shipment or
partial provision of services or performance, the
amount due under a BPO by an Obligor Bank to a
Recipient Bank in respect of such Submission shall
be proportional, subject to sub-article 10(d)(iii), to
the value of such Submission in relation to the total
value reflected in the Established Baseline. In no
event shall the amount due exceed the remaining
amount of the BPO.
(iii) When an Established Baseline incorporates more
than one BPO, the amount due by each Obligor
Bank to a Recipient Bank in respect of a Submission
INDEX
shall be proportional to the amount of its BPO

in relation to the total value reflected in the
(iv) When an Established Baseline incorporates more
than one BPO, no joint and several obligations are
created between Obligor Banks.
e. Performance of an Obligor Bank’s obligations under a
BPO does not depend on its right or ability to obtain
reimbursement from any other party.
f. A BPO remains in effect until the earliest to occur
of the following:
(i) the BPO expires prior to the Submission of all Data
Sets required by an Established Baseline resulting in
a Data Match or a Mismatch Acceptance pursuant to
sub-article 10(c), or
(ii) the Established Baseline is amended to release the
Obligor Bank from its undertaking, or

(iii) the BPO has been fully paid in accordance with

its terms.
g. An Obligor Bank is not required to pay or incur a
deferred payment obligation to pay at maturity if a data
comparison results in a Data Mismatch that is rejected
by the Buyer’s Bank or another Obligor Bank other than
TABLE OF CONTENTS
the Buyer’s Bank.
Summary notes
The Obligor Bank is bound as of the time the Baseline
Match Report indicates the status ‘established’.
The timing of the payment is to be made in accordance
with the instructions contained in the Established
Baseline.
If there is more than one Obligor Bank, each Obligor
Bank is only bound by the amount of the BPO that
relates to it and has no concern with the payment or
non-payment by any other Obligor Bank under the
same Established Baseline.
Comments
Sub-article 10(a)(i) states that an Obligor Bank is bound
as of the time the Baseline Match Report indicates a
status of “Established”. In common with other ICC rules,
the URBPO, once again, do not invoke a timeline within
which an Obligor Bank is required to pay or to incur a
deferred payment obligation following a Data Match.
INDEX
However, sub-articles 10(c) and (e) do make it clear that

the payment under a BPO, including the timing of that
payment, is to be made in accordance with the
instructions contained in the Established Baseline.
Here again, there is an argument to say that the URBPO
should mandate a specific timeframe in which payment
is to be made. However, the Baseline contains a field for
the insertion of the payment details, and it is these
details that should be followed by an Obligor Bank in
each case. Therefore, the URBPO does not need to
dictate a standard payment practice for all
BPO transactions.
Each BPO is included in a single Established Baseline,
but there may be more than one Obligor Bank included
in that Established Baseline. Each BPO is an undertaking
of the concerned Obligor Bank. This is covered in
sub-article 10(b). Sub-article 10(d) emphasises that,
where there is more than one Obligor Bank, each
Obligor Bank is only bound by the amount of the BPO
that relates to it and has no concern with the payment

or non-payment by any other Obligor Bank under the

same Established Baseline. As previously stated, the
discharging of an obligation is not covered by, nor is it
within the boundaries of, the URBPO. Discharge is to be
made in accordance with the conditions expressed in
the Established Baseline. As with other ICC rules,
sub-article 10(f) emphasises that any cancellation of an
TABLE OF CONTENTS
undertaking that has been given is outside the scope of

the rules. Sub-article 10(g) is included for clarity in order
to highlight that there is no obligation where a Data
Mismatch has occurred.
ARTICLE 11
Amendments
a. An amendment to an Established Baseline that
incorporates a BPO or an amendment to incorporate a
BPO in an Established Baseline requires the agreement
of each Involved Bank.
b. (i) A Seller’s Bank or Recipient Bank (as applicable) or
a Buyer’s Bank may request an amendment to an
Established Baseline by sending a Baseline
Amendment Request. The Seller’s Bank or Recipient
Bank (as applicable) or a Buyer’s Bank, as applicable,
may accept the Baseline Amendment Request by
sending an Amendment Acceptance; and
(ii) After such acceptance, a TMA will send a Full Push
Through Report to each Obligor Bank and, if
INDEX
applicable, a Submitting Bank, requesting it to

confirm its role in the transaction by sending a Role
and Baseline Acceptance message to the TMA.
c. An amendment to an Established Baseline that
BPO in an Established Baseline is effective:
when a TMA sends an Amendment Acceptance
Notification to it in response to an Amendment
Acceptance.
a Role and Baseline Acceptance Notification to each
Involved Bank confirming that such Obligor Bank
and, if applicable, a Submitting Bank, has accepted
its role as specified in the Baseline contained in a
Full Push Through Report.


Role and Baseline Acceptance Notification to each
Involved Bank in response to a Full Push Through
Report acknowledging that each Obligor Bank and,
if applicable, a Submitting Bank, has affirmed its role
following an Amendment Acceptance.
TABLE OF CONTENTS
d. An Established Baseline will remain unchanged when

any Involved Bank rejects a proposed amendment to the
Established Baseline by sending an Amendment
Rejection or a Role and Baseline Rejection (as
applicable) and a TMA sends an Amendment Rejection
Notification or a Role and Baseline Rejection Notification
(as applicable) to each other Involved Bank.
Summary notes
This article outlines the amendment process and who is
required to agree to an amendment to an Established
Baseline before it can become effective.
Comments
Sub-articles 11(a) and (b) cover the process of Baseline
Amendments and who is required to agree to an
Sub-article 11(c) outlines the basis for an Amendment
Acceptance to be considered effective.
Sub-article 11(d) outlines the process where a Baseline
INDEX
Amendment Request has been rejected.
ARTICLE 12
Disclaimer on Effectiveness of Data

An Involved Bank does not assume any liability or
responsibility for: (i) the source, accuracy, genuineness,
falsification or legal effect of any data received from the
buyer or seller; (ii) the documents, or the description,
quantity, weight, quality, condition, packing, delivery,
value or existence of the goods, services or other
performance, to which such data relates; or (iii) the
good faith or acts or omissions, solvency, performance
or standing of the consignor, carrier, forwarder,
consignee or insurer of the goods or any other person
referred to in any data.
Summary notes
The use of a disclaimer clause is consistent with other
ICC rules and follows the wording of UCP 600 article 34.

Comments
Like all other ICC rules, there is a need for a disclaimer
clause in respect of the data that is provided to or from
an Involved Bank.
The wording of article 12 follows the language used in
UCP 600 article 34 in relation to the effectiveness of
TABLE OF CONTENTS
documents.
ARTICLE 13
Force Majeure
a. An Involved Bank assumes no liability or responsibility
for the consequences arising out of the interruption of
its business, including its inability to access a TMA, or a
failure of equipment, software or communications
network, caused by Acts of God, riots, civil commotions,
insurrections, wars, acts of terrorism, or by any strikes or
lockouts or any other causes, including failure of
equipment, software or communications networks,
beyond its control.
b. Notwithstanding the provisions of sub-article 13(a), an
Obligor Bank will, upon resumption of its business,
remain liable to pay or to incur a deferred payment
Recipient Bank in respect of a BPO that expired during
such interruption of its business and for which there has
been the Submission of all Data Sets required by an
INDEX
Established Baseline on or before the expiry date of the

BPO resulting in a Data Match or a Mismatch
Acceptance pursuant to sub-article 10(c).
c. In the event of force majeure, a Submitting Bank or
(subject to sub-article 13(b)) another Involved Bank may
terminate its role in an Established Baseline by sending a
Special Request to a TMA, following which a TMA will
send a Special Notification to each Involved Bank.
Summary notes
The concept of force majeure is the same as in other ICC
rules but is extended to cover the inability of an Involved
Bank to access a Transaction Matching Application.
Comments
Sub-article 13(a) provides a somewhat standard wording
of the text that is seen in respect of force majeure
clauses, e.g. UCP 600 article 36. However, the clause is
extended to cover the inability of an Involved Bank to
access a TMA for one or more of the stated reasons.

Sub-article 13(b) refers to the circumstances where the

Obligor Bank is closed due to an event of force majeure
after a Data Set Submission has been made but prior to
a Data Match or Mismatch Acceptance being completed.
The Obligor Bank is required to pay or incur a deferred
payment obligation once it reopens for business.
If a Submitting Bank or other Involved Bank wishes
TABLE OF CONTENTS
to terminate its role, the process is outlined in

sub-article 13(c).
ARTICLE 14
Unavailability of a Transaction Matching Application

An Involved Bank assumes no liability or responsibility
for the consequences arising out of the unavailability of
a TMA for any reason whatsoever.
Summary notes
An Involved Bank cannot be held liable if a Transaction
Matching Application is unavailable.
Comments
It may be that by exception there will be occasions
where a TMA is unavailable. In these circumstances, an
Involved Bank cannot be held liable, and this is reflected
in article 14. Since there will only be one TMA for each
Established Baseline, any issue surrounding unavailability
will become known to and have an impact upon each
INDEX
Involved Bank at the same time.
ARTICLE 15
Applicable Law
a. The governing law of a BPO will be that of the location
of the branch or office of the Obligor Bank specified in
the Established Baseline.
b. URBPO supplement the applicable law to the extent not
prohibited by that law.
c. An Obligor Bank is not required to comply with its
obligations under a BPO and assumes no liability or
responsibility for any consequences if it would be
restricted from doing so pursuant to applicable law or
regulatory requirements.

Summary notes
Sub-article 15(a) follows the same principles as URDG
article 34.
Sub-article 15(b) is taken from ISP98 rule 1.02(a).
There is currently no available field in the ISO 20022
TSMT messages to indicate a place of jurisdiction.
TABLE OF CONTENTS
Comments
There is a need to achieve certainty as to what law will
apply when interpreting and enforcing the URBPO.
Sub-article 15(a) reflects the applicable law position
relating to a BPO and follows the guiding principles
already established in URDG article 34.
Sub-article 15(b) is adapted from ISP98 rule 1.02(a). As
an Obligor Bank is dealing with data and not with
documents, its review of certain pieces of data for
compliance in accordance with local or international
laws, including any sanctions violation, will be an
immediate act that gives rise to an obligation to pay.
Therefore, sub-article 16(c) provides that an Obligor
Bank is not required to act if the result of a Data Match
or Data Mismatch would result in a breach of applicable
law or regulatory requirements that may follow from any
filtering process that may be attached to a TMA. In this
respect, it should be noted that a TMA itself may not be
relied upon to perform compliance checks and that
INDEX
Involved Banks should apply their standard risk

management procedures and policies in order to
address any such issues as may be related to KYC, AML
and so forth.
The wording of article 15 is currently limited to a choice
of applicable law only and does not address the place of
jurisdiction. This is due to a technical limitation whereby
there is no field within the current version of the ISO
20022 TSMT messages in which to indicate a place
of jurisdiction.

ARTICLE 16
Assignment of Proceeds
a. A Recipient Bank has the right to assign any proceeds
to which it may be or may become entitled under a
BPO, in accordance with the provisions of the applicable
law. This article relates only to the assignment of
TABLE OF CONTENTS
proceeds and not to the transfer of the Recipient Bank

role under the Established Baseline to another bank
(which would require an amendment to the Established
Baseline in accordance with article 11).
b. An Obligor Bank is not required to recognise such
assignment of proceeds until it provides its consent.
Summary notes
Under current rules, the Seller’s Bank is the only bank
that can take on the role of BPO Recipient Bank.
There may be a situation in which the Recipient Bank is
not the bank that is providing finance to the seller.
In this case, article 16 provides for the Recipient Bank to
assign or transfer claims or proceeds to another bank
(similar to the UCP).
Comments
If a Recipient Bank is not the bank that is providing
finance to the seller, article 16 will provide for the
INDEX
Recipient Bank to assign or transfer claims or proceeds

to another bank in much the same way as assignments
operate under UCP 600 article 39.
Although there is no facility within the current scope of
URBPO to allow any bank other than the Seller’s Bank to
act as a Recipient Bank, this does not preclude the
possibility that any rights to a BPO payment due from
an Obligor Bank could be assigned by the Recipient
Bank to a third party under a separate contract outside
the URBPO and pursuant to applicable law.

Chapter 5
Understanding Workflow
In this chapter we take a closer look at some working

examples of transaction workflow in order to obtain a
clear understanding of how a transaction can become
established and how the status of that transaction can
change as the result of an exchange of data between an
Involved Bank and the TMA.
Of course, the possible permutations here are almost
infinite, so the examples provided are designed to give
only a flavour of how the flow of messages would
appear in some of the more common business
scenarios.
Based on this limited set of examples, the reader is
encouraged to apply the same business logic in order to
construct other flows consistent with the needs of
alternative scenarios.
For convenience, relevant extracts from the URBPO are
repeated here so as to facilitate a direct link between the
individual rules and the related workflow.
5.1 ESTABLISHING A BASELINE
5.1.1 Establishing a Baseline between two primary

banks only
In order to establish a Baseline, one of the primary banks
(i.e. a Buyer’s Bank or a Seller’s Bank) must first submit
an Initial Baseline Submission message to the TMA. The
transaction can be initiated by either the Buyer’s Bank or
the Seller’s Bank and may or may not include a BPO. If
no BPO is included in the Initial Baseline Submission, the
BPO may be added later by way of a Baseline
Amendment to which Involved Banks must agree.
If the Initial Baseline Submission message fails validation,
the transaction will not be initiated and the TMA will
issue an Error Report to the bank that submitted
the message.

If the Initial Baseline Submission message is successfully

validated, the transaction will be captured in a
“proposed” state and the TMA will send an
Acknowledgement to the first bank (Bank A) plus a Full
Push Through Report to the second bank (Bank B). The
Full Push Through Report contains a copy of the Initial
Baseline Submission.
TABLE OF CONTENTS
The transaction becomes “established” when the second

bank (Bank B) sends a Baseline ReSubmission (i.e. it
resubmits the Baseline contained in the Full Push
Through Report) to the TMA, resulting in Zero
Mismatches. This is a basic scenario involving only two
banks: a Buyer’s Bank and a Seller’s Bank.
If the Established Baseline contains an optional block of
data called the “Payment Obligation Segment”, then the
BPO is also established when the Baseline is established.
In this case, the Buyer’s Bank will become the Obligor
Bank and the Seller’s Bank will become the Recipient
Bank. More complex scenarios may involve other Obligor
Banks and/or a Submitting Bank.
The following definitions and other extracts taken from
the URBPO are most relevant to the process of
establishing a Baseline in the TMA, as illustrated by the
set of flow diagrams that follow:
Article 3 General Definitions

“Bank Payment Obligation” or “BPO” means an
INDEX

following Submission of all Data Sets required by an
Established Baseline resulting in a Data Match
or an acceptance of a Data Mismatch pursuant to
sub-article 10(c).
“Baseline” means data in respect of an underlying trade
transaction submitted to a Transaction Matching
Application by a Buyer’s Bank or a Seller’s Bank.
“Buyer’s Bank” means the bank of the buyer. The Buyer’s
Bank may also be an Obligor Bank.
“Established Baseline” means a Baseline from the time
when a Transaction Matching Application sends a
Baseline Match Report containing Zero Mismatches and
with the status ‘established’.
“Involved Bank” means a Seller’s Bank or Recipient Bank
(depending upon its role at any given time), a Buyer’s
Bank, an Obligor Bank or a Submitting Bank.

“Obligor Bank” means the bank that issues a BPO.

“Payment Obligation Segment” means the part of a
Baseline designated as ‘payment obligation’ that
incorporates the terms of the BPO including the terms
on which payment is to be made.
“Recipient Bank” means the bank that is the beneficiary
TABLE OF CONTENTS
of a BPO. The Recipient Bank is always the Seller’s Bank.

“Seller’s Bank” means the bank of the seller. The Seller’s
Bank will be indicated as the Recipient Bank in the
Payment Obligation Segment of an Established Baseline.
“Submitting Bank” means an Involved Bank whose only
role is to submit one or more Data Sets required by an
“Transaction Matching Application” or “TMA” means any
centralised data matching and workflow application,
whether or not proprietary to an Involved Bank, which
provides the service of processing TSMT messages
received from involved Banks, the automatic comparison
INDEX
of the data contained in such messages, and the

subsequent sending of all related TSMT messages to
each Involved Bank.
“Zero Mismatches” means that the data represented in
one Baseline match the data represented in a
corresponding Baseline or, as the context may indicate,
that all required Data Sets match the data required by
an Established Baseline.

Article 4 Message Definitions

“Baseline Match Report” means a TSMT message sent
by a TMA to each Involved Bank (except an Obligor
Bank other than the Buyer’s Bank), after Submission of a
Baseline, indicating an Established Baseline or that
mismatches have been found between two Baselines.
TABLE OF CONTENTS
“Full Push Through Report” means a TSMT message

sent by a TMA to each Involved Bank advising of a
proposed Baseline, an Established Baseline or a
proposed amendment to an Established Baseline.
Article 9 Role of an Involved Bank

accepted its role:
when a TMA sends a Baseline Match Report with
Zero Mismatches confirming that the Baseline
submitted by a Buyer’s Bank matches the Baseline
submitted by a Seller’s Bank or Recipient Bank (as
applicable);
Article 10 Undertaking of an Obligor Bank

An Obligor Bank is irrevocably bound in accordance
a.
with a BPO:
(i) when a BPO is incorporated in an Established
Baseline at the time of its establishment: as of the
time a TMA has sent either a Baseline Match Report
INDEX
with Zero Mismatches or a Role and Baseline

Acceptance Notification with the status ‘established’
to each Involved Bank pursuant to sub-article 9(d);
Applying these rules, the following flow diagrams
illustrate the process of Baseline establishment by
tracking the sequential flow of ISO 20022 TSMT
messages in and out of the central TMA.
Bank A (e.g. Buyer’s Bank/ TMA Bank B (e.g. Seller’s Bank/

Obligor Bank) Recipient Bank)
Initial Baseline Failed validation.
Submission
No transaction
Error Report initiated.
Initial Baseline Successful

Submission validation.
Full Push Through
Acknowledgement Transaction
Report
Status: Proposed
Flow Diagram 1: Initial Baseline Submission (Buyer’s Bank/Seller’s Bank).

Flow Diagram 1 illustrates the simplest case where a

valid Initial Baseline Submission from Bank A results in a
Full Push Through Report being received by Bank B. The
Full Push Through Report contains details of the
Baseline that was originally submitted by Bank A. At this
stage the transaction is in a “proposed” state.
TABLE OF CONTENTS
Bank B must now resubmit the Baseline contained in the

Full Push Through Report. Provided that Bank B’s
Baseline ReSubmission matches the Initial Baseline
Submission of Bank A, the Baseline will become
“established”. In this case, both banks will receive a
Baseline Match Report with Zero Mismatches (see Flow
Diagram 2).

Full Push Through Transaction Baseline
Report Status: ReSubmission
Established
Baseline Match Baseline Match
Report (Zero Report (Zero
Flow Diagram 2: Baseline ReSubmission successful (Zero Mismatches):

Baseline established.
If the Baseline ReSubmission is unsuccessful, resulting in

a Data Mismatch, the Baseline Match Report will report a
status of “partially matched” and highlight any items
that do not match (see Flow Diagram 3).
INDEX

Full Push Through Transaction Baseline
Report Status: Partially ReSubmission
Matched
Baseline Baseline
Match Report Match Report
(Mismatches) (Mismatches)
Flow Diagram 3: Baseline ReSubmission unsuccessful (Mismatches): Base-

line partially matched.
In order to correct any Data Mismatch, either Bank A or

Bank B must resubmit the Baseline again.
As soon as the two banks can achieve a perfect match
in their twin submissions, the Baseline can be
established (see Flow Diagram 4).
If the Established Baseline contains a BPO, the BPO also
becomes established. In this case, the Buyer’s Bank
would become the Obligor Bank and the Seller’s Bank
would become the Recipient Bank of the BPO.


Baseline Baseline
ReSubmission ReSubmission
Transaction
Baseline Match Baseline Match
Status:
Established
TABLE OF CONTENTS
Full Push Through Full Push Through

Report Report
Flow Diagram 4: Baseline Establishment (Buyer’s Bank/Seller’s Bank).
If the Baseline ReSubmissions continue to result in a

Data Mismatch, the TMA will eventually reach a ceiling
and force the transaction to be closed as shown in Flow
Diagram 5.

Baseline ReSubmission Baseline
ReSubmission limit reached. ReSubmission
Status Change Status Change

Transaction
Notification Notification
Status: Closed
Flow Diagram 5: ReSubmission failure – transaction closed.
If necessary, the two banks can start again by initiating a

new transaction. This is a worst case scenario.
5.1.2 Establishing a Baseline with additional banks

INDEX
Sub-articles 9(d) (ii) and (iii) reference a more complex

scenario involving additional banks. In this case, there
are some additional steps required before the Baseline
can become established. The Baseline matching phase is
the same, except that when a Baseline ReSubmission is
successfully matched the transaction status moves
temporarily to Role Acceptance Pending, as shown in
Flow Diagram 6. That is to say that the Baseline is only
partially matched.
Article 9 Role of an Involved Bank

accepted its role:
(ii) When an Obligor Bank, other than the Buyer’s Bank,
is the only Obligor Bank: when a TMA sends a Role
and Baseline Acceptance Notification confirming
that such Obligor Bank and, if applicable, a
Submitting Bank, has accepted its role as specified in

the Baseline Submission of both the Buyer’s Bank

Zero Mismatches; or
(iii) When there is more than one Obligor Bank that may
TABLE OF CONTENTS
include the Buyer’s Bank: when a TMA sends a Role

and Baseline Acceptance Notification confirming
that each Obligor Bank and, if applicable, a
Submitting Bank, has accepted its role as specified in
the Baseline Submission of both the Buyer’s Bank
Zero Mismatches.
Bank A (e.g. TMA Bank B Additional

Buyer’s Bank/ (e.g. Seller’s Bank/ Banks
Obligor Bank) Recipient Bank) (e.g. Obligor
Bank/
Submitting
Bank)
Full Push Baseline
Through ReSubmission
Report Additional banks
required.
Baseline Baseline
Match Transaction Status: Match
Report (Zero Role Acceptance Report (Zero
Mismatches) Pending Mismatches)
INDEX
Full Push
Through
Report
Flow Diagram 6: Additional banks required to establish the Baseline.
The additional banks are required to confirm their roles

by submitting a Role and Baseline Acceptance message
as described in section 5.1.3.
5.1.3 Role and Baseline Acceptance

“Role and Baseline Acceptance” means a TSMT message
other than the Buyer’s Bank, accepting such bank’s role
Through Report.
“Role and Baseline Acceptance Notification” means a
TSMT message sent by a TMA informing each other
Involved Bank that a Submitting Bank, or an Obligor

Bank other than the Buyer’s Bank, has sent a Role and
Baseline Acceptance in response to a Full Push Through
Report.
Where additional banks are involved, in order for the
Baseline to become established the additional banks
(Obligor Banks and/or Submitting Bank) must submit a
TABLE OF CONTENTS
Role and Baseline Acceptance message in response to

the Baseline received in the Full Push Through Report.
The other Involved Banks will then receive a Role and
Baseline Acceptance Notification message from the
TMA confirming the additional banks’ acceptance of
their roles. As shown in Flow Diagram 7, the Full Push
Through Report confirms the establishment of the
Baseline in this case to all Involved Banks.
Bank A (e.g. TMA Bank B Additional Banks

Buyer’s Bank/ (e.g. Seller’s Bank/ (e.g. Obligor Bank/
Obligor Bank) Recipient Ban÷k÷) Submitting Bank)
Additional Role And Baseline

bank accepts Acceptance
its role.
Acknowledgement
Role And Role And

Baseline Transaction Baseline
Acceptance Status: Acceptance
Notification Established Notification
Full Push Full Push Full Push Through

INDEX
Through Through Report

Report Report
Flow Diagram 7: Additional bank accepts its role and the Baseline is
established.
5.1.4 Role and Baseline Rejection

“Role and Baseline Rejection” means a TSMT message
other than the Buyer’s Bank, rejecting such bank’s role
Through Report.
“Role and Baseline Rejection Notification” means a
TSMT message sent by a TMA informing each Involved
Bank that a Submitting Bank, or an Obligor Bank other
than the Buyer’s Bank, has sent a Role and Baseline
Rejection in response to a Full Push Through Report.
The definition of the Role and Baseline Rejection
message in URBPO article 4 refers to the possibility that

a bank may reject the role it has been invited to play in a

particular transaction.
If an additional bank rejects its role by submitting a Role
and Baseline Rejection message, the TMA will notify the
other Involved Banks by sending a Role and Baseline
Rejection Notification message.
TABLE OF CONTENTS
The other Involved Banks must now agree upon an

alternative course of action in order to remedy the
matter, for example by replacing the bank that has
chosen to reject its role.
If the additional banks’ rejection of its role cannot
satisfactorily be resolved by the remaining banks, this
may result in a Status Change Request leading to the
transaction being closed (see Flow Diagram 8). This
would be a worst case scenario.
Bank A (e.g. Buyer’s TMA Bank B (e.g. Seller’s Additional

Bank/Obligor Bank) Bank/Recipient Banks (e.g.
Bank) Obligor Bank/
Submitting
Bank)
Additional Role And
bank Baseline
rejects its Rejection
role.
Acknowledgement
Role And Baseline Transaction Role And

Rejection Status: Role Baseline
Notification Acceptance Rejection
INDEX
Pending Notification
Status Change
Request
Acknowledgement Status Change

Notification
Status Change
Request
Acceptance
Acknowledgement
Status Change Transaction Status Change

Notification Status: Notification
Closed
Flow Diagram 8: Additional bank rejects its role – transaction closed.

5.2 BASELINE AMENDMENT REQUEST
Article 11 Amendments
a. An amendment to an Established Baseline that
BPO in an Established Baseline requires the agreement
TABLE OF CONTENTS
of each Involved Bank.

b. (i) A Seller’s Bank or Recipient Bank (as applicable) or
a Buyer’s Bank may request an amendment to an
Established Baseline by sending a Baseline
Amendment Request. The Seller’s Bank or Recipient
Bank (as applicable) or a Buyer’s Bank, as applicable,
may accept the Baseline Amendment Request by
sending an Amendment Acceptance; and
(ii) After such acceptance, a TMA will send a Full Push
Through Report to each Obligor Bank and, if
applicable, a Submitting Bank, requesting it to
confirm its role in the transaction by sending a Role
and Baseline Acceptance message to the TMA.
c. An amendment to an Established Baseline that
BPO in an Established Baseline is effective:
when a TMA sends an Amendment Acceptance
Notification to it in response to an Amendment
Acceptance.
INDEX

a Role and Baseline Acceptance Notification to each
Involved Bank confirming that such Obligor Bank
and, if applicable, a Submitting Bank, has accepted
its role as specified in the Baseline contained in a
Full Push Through Report.
Involved Bank in response to a Full Push Through
Report acknowledging that each Obligor Bank and,
if applicable, a Submitting Bank, has affirmed its role
following an Amendment Acceptance.

d. An Established Baseline will remain unchanged when

any Involved Bank rejects a proposed amendment to the
Established Baseline by sending an Amendment
Rejection or a Role and Baseline Rejection (as
applicable) and a TMA sends an Amendment Rejection
Notification or a Role and Baseline Rejection Notification
(as applicable) to each other Involved Bank.
TABLE OF CONTENTS

“Baseline Amendment Request” means a TSMT message
sent to a TMA by a Buyer’s Bank, a Seller’s Bank or a
Recipient Bank (as applicable) requesting an

a. An Obligor Bank is irrevocably bound in accordance
with a BPO:
(ii) when a BPO is incorporated by an amendment to an
Established Baseline: as of the time a TMA has sent
either an Amendment Acceptance Notification or a
Involved Bank pursuant to sub-article 11(c).
The process for handling Baseline Amendment Requests
is covered in URBPO article 11.
A Baseline Amendment Request may be submitted by
either a Buyer’s Bank or a Seller’s Bank after the Baseline
has been established.
INDEX
If there is a Mismatch Acceptance pending, then the

Baseline Amendment Request will be rejected by the
TMA.
Data Set messages may be received during the period
between the issuance of a Baseline Amendment
Request and the acceptance/rejection of the Baseline
Amendment Request.
Following completion of the Amendment Acceptance/
Rejection process, a data comparison can be performed.
The process for Baseline Amendment Acceptance is
covered in sections 5.2.1 and 5.2.2 and for Baseline
Amendment Rejection in sections 5.2.3 and 5.2.4.

5.2.1 Baseline Amendment Acceptance between

two primary banks only

“Amendment Acceptance” means a TSMT message sent
Recipient Bank (as applicable) accepting a Baseline
TABLE OF CONTENTS
Amendment Request.
“Amendment Acceptance Notification” means a TSMT
the acceptance of a Baseline Amendment Request.
Flow Diagram 9 shows that an Amendment Acceptance
message must be submitted by the primary bank
(Buyer’s Bank or Seller’s Bank) that did not submit the
Baseline Amendment Request. In this case, the TMA will
send an Amendment Acceptance Notification to the
bank requesting such amendment. At this point, the
Baseline is amended. This is confirmed to both banks by
the issuance of Baseline Report by the TMA.

Baseline Full Push Through
Amendment Report
Request Transaction Status:
Amendment Baseline Report
Requested
INDEX
Delta Report Delta Report
Amendment Amendment
Acceptance Acceptance
Notification
Baseline Report Acknowledgement

Transaction
Status: Established
Baseline Report
(Baseline changed)
Flow Diagram 9: Amendment Amendment Acceptance (Buyer’s Bank/

Seller’s Bank).

5.2.2 Baseline Amendment Acceptance involving

additional banks
Bank A (e.g. TMA Bank B (e.g. Seller’s Additional Banks
Buyer’s Bank/ Bank/Recipient (e.g. Obligor
Obligor Bank) Bank) Bank/Submitting
Bank)
TABLE OF CONTENTS
Baseline Full Push

Amendment Through
Request Transaction Report
Status:
Amendment Baseline
Requested Report
Transaction Amendment
Status: Role Acceptance
Acceptance
Pending
Amendment Acknowledgement
Acceptance
Notification
Full Push
Through Report
Baseline Report
Delta Report
Role and
Baseline
Acceptance
INDEX
Transaction Acknowledgement
Status:
Role and Role and
Established
Baseline Baseline
(Baseline
Acceptance Acceptance
changed)
Baseline Baseline Baseline Report

Report Report
Flow Diagram 10: Amendment Acceptance (additional banks).
If there are additional banks involved in the transaction,

those banks must confirm their continued acceptance of
their role – and thereby confirm their acceptance of the
amended Baseline – by submitting a Role and Baseline
Acceptance message.
In this case, the message flows will continue as shown in
Flow Diagram 10.

5.2.3 Baseline Amendment Rejection between two

primary banks only

“Amendment Rejection” means a TSMT message sent to
a TMA by a Buyer’s Bank, a Seller’s Bank or a Recipient
Bank (as applicable) rejecting a Baseline Amendment
TABLE OF CONTENTS
Request.
“Amendment Rejection Notification” means a TSMT
the rejection of a Baseline Amendment Request.
In Flow Diagram 11, the Baseline Amendment Rejection
message is submitted by the primary bank (Buyer’s
Bank or Seller’s Bank) that did not submit the Baseline
Amendment Request. In this case, the TMA will send an
Amendment Rejection Notification to the bank
requesting such amendment. At this point the Baseline
remains unchanged.
Bank A (e.g. Buyer’s TMA Bank B (e.g. Seller’s

Bank/Obligor Bank) Bank/Recipient Bank)
Baseline Full Push
Amendment Through Report
Request Transaction Status:
Amendment Requested Baseline Report

INDEX
Amendment Amendment
Rejection Rejection
Notification Transaction Status:
Established (Baseline
unchanged) Acknowledgement
Flow Diagram 11: Baseline Amendment Request rejected.

5.2.4 Baseline Amendment Rejection involving addi-

tional banks
Where there are additional banks involved in a
transaction, it is possible for a primary bank to accept a
proposed amendment to a Baseline but for such
changes to subsequently be rejected by one or more of
those additional banks. In such cases, the Baseline will
TABLE OF CONTENTS
also remain unchanged (see Flow Diagram 12).
Bank A (e.g. TMA Bank B Additional Banks

Buyer’s Bank/ (e.g. Seller’s Bank/ (e.g. Obligor Bank/
Obligor Bank) Recipient Bank) Submitting Bank)
Baseline Full Push

Amendment Through
Request Transaction Report
Status:
Amendment Baseline
Requested Report
Transaction Amendment
Status: Role Acceptance
Acceptance
Amendment Pending Acknowledgement
Acceptance
Notification
Full Push Through

Report
Baseline Report
INDEX
Delta Report
Role and Baseline

Rejection
Transaction
Acknowledgement
Status:
Role and Established Role and
Baseline (Baseline Baseline
Rejection unchanged) Rejection
Baseline Baseline Baseline Report

Report Report
Flow Diagram 12: Baseline Amendment Request rejected (additional

banks).

5.3 DATA SET SUBMISSION

“Data Match” means a comparison of all required Data
Sets with an Established Baseline resulting in Zero
Mismatches as specified in a Data Set Match Report.
TABLE OF CONTENTS
“Data Set” means any of the categories (for example,

‘commercial’, ‘transport’, ‘insurance’, ‘certificate’ or ‘other
certificate’) included in a Data Set Submission sent to a
Transaction Matching Application by an Involved Bank
for comparison with an Established Baseline.

“Data Set Match Report” means a TSMT message sent
by a TMA to each Involved Bank after Submission of all
Data Sets required by an Established Baseline and the
automatic comparison of such Data Sets with that
Established Baseline, advising it of either a Data Match
or a Data Mismatch.
INDEX
“Data Set Submission” means a TSMT message sent to a

TMA by an Involved Bank that contains one or more
categories of Data Set for data comparison.
Article 8 Expiry Date of a BPO

c. A data comparison will only occur after the Submission
of all Data Sets required by an Established Baseline. A
TMA will then send a Data Set Match Report to each
Involved Bank advising it of either a Data Match or a
Data Mismatch.


(i) there is a Data Match;

The above-referenced articles relate to the rules on data
submission. At any point in time after a Baseline has
been established, Data Sets can be submitted for a
comparison of data to that Established Baseline.
TABLE OF CONTENTS
5.3.1 Baseline involving two primary banks only

In the simplest scenario, the Data Set(s) will be
submitted by one of the primary banks, often the Seller’s
Bank or Recipient Bank (as applicable). If the Data Set
matches the Established Baseline it will result in the TMA
issuing a Data Set Match Report with Zero Mismatches.
If the Established Baseline contains a Payment
Obligation Segment and the Data Sets submitted match
the Established Baseline, then the BPO will become due.
Bank A (e.g. Buyer’s TMA Bank B (e.g. Seller’s Bank/

Bank/Obligor Bank) Recipient Bank)
Forward Data Set Data Set Submission
Submission
Acknowledgement
Data Set Match Data Set Match

Mismatches) Transaction Status: Mismatches)
Complete
Baseline Report Baseline Report
Status Change Transaction Status:

INDEX
Request Status Change

Requested
Acknowledgement Status Change

Request Notification
Status Change
Request Acceptance
Acknowledgement
Status Change Transaction Status: Status Change

Notification Closed Notification
Flow Diagram 13: Transaction completed and closed.
The transaction is now complete but not closed.

Involved Banks may continue to request reports on the
transaction until it is formally closed. The transaction
cannot be closed without the common consent of both
the Buyer’s Bank and the Seller’s Bank. Closure may
eventually be achieved by the Submission of a Status
Change Request message, as shown in Flow Diagram 13.
This “two-step” approach towards completion and
closure is somewhat at variance with established

procedures for traditional trade finance. For example,

when a letter of credit, guarantee or collection is paid,
the file is normally closed. By following the structured
workflow of the ISO 20022 TSMT messages, a TMA will
not automatically close a Baseline transaction even
when fully utilised. In the absence of any specific
instruction to close the transaction, the Baseline will
TABLE OF CONTENTS
remain extant within the TMA, leaving the door open to

a further exchange of messages. However, if there is no
further activity within a prescribed period of time, the
Baseline will eventually “time out” in accordance with
the TMA operating rules and the transaction will then be
closed by the TMA.
5.3.2 Baseline involving additional banks

If there are additional banks involved in the transaction,
those banks will also receive a copy of the Baseline
Match Report (see Flow Diagram 14). This is particularly
relevant in the case of an Obligor Bank, which needs to
know if and when an obligation becomes due, such as
when the data as specified in the Baseline has been
submitted and matches.
Bank A (e.g. TMA Bank B (e.g. Seller’s Additional

Buyer’s Bank/ Bank/Recipient Bank) Banks (e.g.
Obligor Bank) Obligor Bank/
Submitting
Bank)
INDEX
Transaction Data Set

Status: Submission
Complete
Forward Data Acknowledgement Forward Data
Set Submission Set Submission
Data Set Match Data Set Match Data Set Match

Report (Zero Report (Zero Report (Zero
Mismatches) Mismatches) Mismatches)
Baseline Baseline Report Baseline

Report Report
Flow Diagram 14: Transaction status is complete (additional banks).
5.4 DATA SET PRE-MATCH

In some circumstances, a Seller’s Bank/Recipient Bank
may wish to present Data Sets for matching without the
knowledge of the Buyer’s Bank/Obligor Bank. It is
possible to do this by presenting the Data Sets for what
is known as a “pre-match” (see Flow Diagram 15). In this
case, no Data Set Match Report is issued. Instead, a
Baseline Report is sent to the Seller’s Bank/Recipient
Bank only. The transaction status remains “established”.

No obligation to pay can result from a pre-match.
Bank A (e.g. Buyer’s TMA Bank B (e.g. Seller’s Bank/

Bank/Obligor Bank) Recipient Bank)
Transaction Status: Data Set Submission

Established [CODE: PRE-MATCH]
TABLE OF CONTENTS
Acknowledgement
Baseline Report
Flow Diagram 15: Data Set Pre-Match – no change in status.
If a Baseline has been established without a BPO and

the Seller’s Bank successfully submits the corresponding
Data Sets for a pre-match only, resulting in Zero
Mismatches, it remains possible for the Seller’s Bank to
subsequently submit a Baseline Amendment Request in
order to add a BPO.
If the Buyer’s Bank is the only bank required to take on
the role of Obligor Bank, then the BPO will become
established as soon as the Buyer’s Bank submits its
Amendment Acceptance. If the Seller’s Bank then
presents the Data Sets for matching, the BPO will
immediately become due.
If there are other Obligor Banks involved, then those
other Obligor Banks must also submit a Role and
Baseline Acceptance in order that the BPO can become
established as per section 5.2.2.
INDEX
5.5 MISMATCH ACCEPTANCE

“Data Mismatch” means a comparison of all required
Data Sets with an Established Baseline resulting in one
or more mismatches as specified in a Data Set Match
Report.

“Mismatch Acceptance” means a TSMT message sent to
a TMA by a Buyer’s Bank accepting a Data Mismatch.
“Mismatch Acceptance Notification” means a TSMT
it of the acceptance of a Data Mismatch by a
Buyer’s Bank.


TABLE OF CONTENTS

(ii) there is a Data Mismatch and the Buyer’s Bank is
the only Obligor Bank: when a TMA acknowledges
the Mismatch Acceptance of the Buyer’s Bank by
sending a Mismatch Acceptance Notification to a
Recipient Bank; or
(iii) there is a Data Mismatch and an Obligor Bank,
other than the Buyer’s Bank, is the only Obligor
Bank: when the Obligor Bank and, if applicable, a
Submitting Bank has affirmed its role by sending a
Role and Baseline Acceptance to a TMA and a TMA
Acceptance Notification to each Involved Bank. The
sending of such a notification will follow a TMA
acknowledging the Mismatch Acceptance of the
Buyer’s Bank by sending a Mismatch Acceptance
Notification to each Involved Bank; or
(iv) there is a Data Mismatch and there is more than
one Obligor Bank that may include the Buyer’s
INDEX
Bank: when
a) a TMA acknowledges the Mismatch Acceptance
of the Buyer’s Bank by sending a Mismatch
Acceptance Notification to each Involved Bank;
and
b) the Obligor Bank and, if applicable, a Submitting
Bank, has affirmed its role by sending a Role and
Baseline Acceptance to a TMA and a TMA
Acceptance Notification to each Involved Bank.
As previously noted, Data Sets can be submitted for a
comparison of data at any point in time after a Baseline
has been established.
If the Data Sets submitted contain a Data Mismatch then
the Buyer’s Bank (which may also be an Obligor Bank)
must either accept or reject such a Data Mismatch.

5.5.1 Baseline involving two primary banks only;

Buyer’s Bank is Obligor Bank
If the Buyer’s Bank is the only Obligor Bank, then the
transaction is completed as soon as the Buyer’s Bank
has accepted the mismatches and the TMA confirms
this by issuing a Mismatch Acceptance Notification to
the Seller’s Bank/Recipient Bank (see Flow Diagram 16).
TABLE OF CONTENTS

Submission
Acknowledgement
Data Set Match Transaction Data Set Match Report

Report (Mismatches) Status: Active (Mismatches)
Mismatch Acceptance
Acknowledgement Mismatch Acceptance

Notification
Baseline Report Transaction Baseline Report

Status:
Complete
Flow Diagram 16: Mismatch Acceptance (Buyer’s Bank/Seller’s Bank).

INDEX


If there is an additional Obligor Bank involved in the
transaction, such Obligor Bank must affirm its continued
role by submitting a Role and Baseline Acceptance
message to the TMA, whereupon the TMA will issue a
Role and Baseline Acceptance Notification to other
Involved Banks (see Flow Diagram 17).
TABLE OF CONTENTS

Bank/Obligor Bank) Bank/Recipient Banks (e.g.
Bank) Obligor Bank/
Submitting
Bank)
Transaction Data Set
Status: Submission
Active
Forward Data Acknowledgement
Set Submission
Data Set Data Set

Mismatch Transaction Mismatch Mismatch

Acceptance Status: Acceptance Acceptance
Role Notification Notification
acceptance
pending
Acknowledgement
Full Push
Through Report
Role and
INDEX
Baseline
Acceptance
Acknowledgement
Role and Transaction Role and

Baseline Status: Baseline
Acceptance Complete Acceptance
Baseline Report Baseline Report Baseline Report
Flow Diagram 17: Mismatch Acceptance (additional banks).
5.6 MISMATCH REJECTION

“Mismatch Rejection” means a TSMT message sent to a
TMA by a Buyer’s Bank rejecting a Data Mismatch.
“Mismatch Rejection Notification” means a TSMT
it of the rejection of a Data Mismatch by a Buyer’s Bank.


g. An Obligor Bank is not required to pay or incur a
deferred payment obligation to pay at maturity if a data
comparison results in a Data Mismatch that is rejected
by the Buyer’s Bank or another Obligor Bank other than
the Buyer’s Bank.
TABLE OF CONTENTS
5.6.1 Baseline involving two primary banks only;

Buyer’s Bank is Obligor Bank
If the Data Set Submission of the Seller’s Bank/Recipient
Bank results in a Data Mismatch and the Buyer’s Bank/
Obligor Bank rejects such a mismatch, the TMA will
advise the Seller’s Bank/Recipient Bank by way of a
Mismatch Rejection Notification.
In this case, the transaction remains active and
incomplete (see Flow Diagram 18).

Submission
Acknowledgement
Data Set Match Data Set Match

Report (Mismatches) Report (Mismatches)
Transaction Status:
Mismatch Rejection
Active
Acknowledgement Mismatch Rejection
Notification
INDEX
Flow Diagram 18: Mismatch Rejection.
At this point, in order for the transaction to continue, the

Seller’s Bank/Recipient Bank must resubmit the Data
Set(s) as per Flow Diagram 19.
Provided there is now a Data Set Match (i.e. Zero
Mismatches) or a number of mismatches have been
eliminated and all of the remaining mismatches are
acceptable to the Buyer’s Bank/Obligor Bank, then the
transaction can be completed.
It is not possible for a Buyer’s Bank/Obligor Bank to
make a partial acceptance of any mismatches.


Forward Data Set Transaction Status: Data Set Submission
Submission Active
Acknowledgement
Data Set Match Transaction Status: Data Set Match

TABLE OF CONTENTS
Report (Zero Complete Report (Zero

Baseline Report Baseline Report
Flow Diagram 19: ReSubmission of previously mismatched Data Sets.

In a more complex scenario, there may be an additional
Obligor Bank whose agreement to any Data Mismatch
must also be obtained in order for the transaction to
continue. As noted above, the Data Mismatch must first
be accepted by the Buyer’s Bank (which may also be an
Obligor Bank). The additional Obligor Bank is then
required to agree by submitting a Role and Baseline
Acceptance.
If the additional Obligor Bank disagrees, it will instead
submit a Role and Baseline Rejection. In this case, the
Baseline remains unchanged and the transaction
remains active (see Flow Diagram 20).
The Buyer’s Bank and the Seller’s Bank/Recipient Bank
INDEX
must then decide what action to take. For example, they

may decide to reject the Data Mismatch and retain the
original Baseline. Alternatively, they may request an
amendment to the Baseline, for example to replace the
additional Obligor Bank.
If there is more than one Data Mismatch, it may be
possible to correct those mismatches to which the
additional Obligor Bank does not agree and to represent
the Data Set Submission in such a way as to enable the
additional Obligor Bank to submit a Role and Baseline
Acceptance.


Bank/Obligor Bank) Bank/Recipient Banks
Bank) (e.g. Obligor
Bank/
Submitting
Bank)
Data Set
TABLE OF CONTENTS
Submission
Forward Data Transaction Acknowledgement

Set Submission Status:
Active
Data Set Data Set
Mismatch Mismatch
Transaction Acceptance Acceptance
Mismatch Status: Role Notification Notification
Acceptance acceptance
pending
Acknowledgement
Full Push
Through
Report
Role and
Baseline
Rejection
Acknowledgement
Role and Baseline Role and

Rejection Transaction Baseline
Notification Status: Rejection
INDEX
Active Notification
(Baseline
Baseline Report unchanged) Baseline Baseline
Report Report
Flow Diagram 20: Role and Baseline Rejection by additional bank(s).
If the Buyer’s Bank continues to accept mismatches to

which an additional Obligor Bank will not agree, it
becomes the decision of the buyer as to how the
transaction should eventually be settled. This may result
in the closure of the transaction in the TMA so that
further action will fall outside the scope of the URBPO.
This is a worst case scenario.

5.7 SPECIAL MESSAGES

“Special Notification” means a TSMT message sent by a
TMA to an Involved Bank notifying it of a Special
Request made by another Involved Bank.
TABLE OF CONTENTS
“Special Request” means a TSMT message sent to a

TMA by (i) a Submitting Bank advising a reason that
prevents it from being able to submit a Data Set, or (ii)
an Involved Bank withdrawing from its role in an
Established Baseline due to force majeure (subject to
article 13).
Article 13 Force Majeure

a. An Involved Bank assumes no liability or responsibility
for the consequences arising out of the interruption of
its business, including its inability to access a TMA, or a
failure of equipment, software or communications
network, caused by Acts of God, riots, civil commotions,
insurrections, wars, acts of terrorism, or by any strikes or
lockouts or any other causes, including failure of
equipment, software or communications networks,
beyond its control.
b. Notwithstanding the provisions of sub-article 13(a), an
Obligor Bank will, upon resumption of its business,
remain liable to pay or to incur a deferred payment
INDEX
Recipient Bank in respect of a BPO that expired during

such interruption of its business and for which there has
been the Submission of all Data Sets required by an
Established Baseline on or before the expiry date of the
BPO resulting in a Data Match or a Mismatch
Acceptance pursuant to sub-article 10(c).
c. In the event of force majeure, a Submitting Bank or
(subject to sub-article 13(b)) another Involved Bank may
terminate its role in an Established Baseline by sending a
Special Request to a TMA, following which a TMA will
send a Special Notification to each Involved Bank.
There are two circumstances in which a Special Request
message may be submitted to the TMA:
(i) If a Submitting Bank is unable to submit a Data Set
under the terms of its agreed role in an Established
Baseline (see Flow Diagram 21). In this case, the
Submitting Bank submits a Special Request
message with the code CSDS (Cannot Submit Data
Set); or

(ii) If an Involved Bank must withdraw from its agreed

role in an Established Baseline (see Flow Diagram
22). This option may only be exercised in force
majeure. In this case the Involved Bank submits a
Special Request message with the code MWFT
(Must Withdraw From Transaction).
TABLE OF CONTENTS
Scenario 1: CSDS
Bank A (e.g. Buyer’s TMA Bank B (e.g. Seller’s Submitting

Bank/Obligor Bank) Bank/Recipient Bank) Bank
Special Request
Transaction
Acknowledgement
Status:
Special Active Special
Flow Diagram 21: Submitting Bank cannot submit Data Set(s).
Scenario 2: MWFT
Bank A (e.g. Buyer’s TMA Bank B (e.g. Seller’s Additional Banks

Bank/Obligor Bank) Bank/Recipient Bank) (e.g. Obligor
Bank/Submitting
Bank)
Special Request
Transaction
Acknowledgement
Status:
Special Active Special Special
Notification Notification Notification
INDEX
Flow Diagram 22: Involved Bank must withdraw from transaction.
In either circumstance, the remaining banks involved in

the transaction must decide what action to take, for
example (a) to replace the bank that is unable to fulfil its
role or (b) to close the transaction.

Chapter 6
Corporate-to-Bank
Guidelines and Messaging
TABLE OF CONTENTS
Under Version 1.0 of the Uniform Rules for Bank

Payment Obligations (URBPO), a BPO is only
recognised if it is part of an Established Baseline in a
Transaction Matching Application (TMA). It represents
an obligation between banks that are subscribed to the
same TMA. As such, it is impossible to establish a BPO
as either a corporate-to-corporate obligation or bank-to-
corporate obligation. The obligation is between banks
only, the Obligor Bank being the bank that is obligated
to pay and the Recipient Bank (the Seller’s Bank) being
the designated beneficiary.
The ISO 20022 TSMT messages published on the ISO
website are designed exclusively to support the
exchange of data between Involved Banks and a TMA.
As such, there are no mandatory messaging standards
to support the exchange of BPO-related data between a
corporate and a bank/financial services provider. Nor are
there any mandatory channels for the exchange of such
data. This means that data can be exchanged between a
INDEX
corporate and a bank using any standard and any

channel. For example, an Excel spreadsheet presented
via a bank’s front-end trade application in a web portal.
In a worst case scenario, though far from ideal, the
information could even be passed to the bank by way of
paper documents.
6.1 ADAPTING THE ISO 20022 TSMT MESSAGES

Some corporates may eventually wish to consider the
possibility of using an adapted subset of the ISO 20022
TSMT messages to communicate with their banks. Such
messages could, for example, be fed directly to/from an
Enterprise Resource Planning (ERP) application, such as
SAP or Oracle, where all the relevant data is stored.
In principle, the only messages in which a corporate end
user would have an active interest/involvement would be:
a. Baseline establishment
b. Baseline amendment
c. Data Set Submission

Corporate-to-Bank Guidelines and Messaging
Some TMAs may also support the processing of the

so-called Intent to Pay Notification message, which
allows a Buyer’s Bank to confirm to a Seller’s Bank a
buyer’s intention to pay in accordance with the agreed
terms but which has no binding effect in law. In such
cases, a corporate may also wish to be able to make use
of the relevant messages such as the Intent to Pay
TABLE OF CONTENTS
Notification, Forward Intent to Pay Notification and

Intent to Pay Report.
The following Tables Q and R represent a subset of ISO
20022 TSMT messages that could be adapted to
support the exchange of data related to a BPO
transaction between a corporate and a bank. In this
instance, for the sake of clarity, two lists are shown. The
first describes messages that could be sent by a
corporate to a bank; the second shows the reverse flow
of messages that could be sent by a bank to a corporate.
N.B. These lists are provided for illustrative purposes
only. As stated, there are no officially defined
standards for corporate/bank messaging.
Adapted Message Purpose Sent by Sent to

Message Type Name
tsmt. Amendment To instruct a A buyer or A Buyer’s
005.001.02 Acceptance bank to accept a seller Bank or
a Baseline a Seller’s
Amendment Bank
Request.
INDEX
tsmt. Amendment To instruct a A buyer or A Buyer’s

007.001.02 Rejection bank to reject a seller Bank or
a Baseline a Seller’s
Amendment Bank
Request.
tsmt. Baseline To request a A buyer or A Buyer’s

009.001.03 Amendment bank to submit a a seller Bank or
Request request to amend a Seller’s
an Established Bank
Baseline.
tsmt. Baseline To instruct a bank A buyer or A Buyer’s

012.001.03 ReSubmission to respond to an a seller Bank or
Initial Baseline a Seller’s
Submission or Bank
to resubmit
Baseline data
that has been
mismatched.

Adapted Message Purpose Sent by Sent to

Message Type Name
tsmt. Data Set To instruct a A buyer or A Buyer’s
014.001.03 Submission bank to trigger a seller Bank or
either a match or a Seller’s
a pre-match of Bank
the information
TABLE OF CONTENTS
submitted against
the Established
Baseline.
tsmt. Initial Baseline To instruct a A buyer or A Buyer’s

019.001.03 Submission bank to initiate a a seller Bank or
transaction. a Seller’s
Bank
tsmt. Mismatch To instruct a bank A buyer A Buyer’s

020.001.02 Acceptance to accept a Data Bank
Mismatch.
tsmt. Mismatch To instruct a bank A buyer A Buyer’s

022.001.02 Rejection to reject a Data Bank
Mismatch.
tsmt. Intent to Pay To instruct a A buyer A Buyer’s

044.001.01 Notification bank to express Bank
a confirmed
intent to pay a
certain amount
at a certain
time in relation
to one or more
transactions.
Table Q: ISO 20022 TSMT messages that could be adapted and sent from
INDEX
a corporate to a bank.

Adapted Message Name Purpose Sent By Sent To

Message Type
tsmt. Acknowledgement To A Buyer’s A buyer or
001.001.03 acknowledge Bank or a seller
the receipt of a Seller’s
an incoming Bank
message from
TABLE OF CONTENTS
a buyer or a
Seller.
tsmt. Amendment To notify A Buyer’s A buyer or

006.001.03 Acceptance a buyer or Bank or a seller
Notification seller of the a Seller’s
acceptance Bank
of a Baseline
Amendment
Request.
tsmt. Amendment To notify a A Buyer’s A buyer or

008.001.03 Rejection buyer or seller Bank or a seller
of a Baseline Bank
Amendment
Request.
tsmt. Baseline Match To report to a A Buyer’s A buyer or

010.001.03 Report buyer or seller Bank or a seller
either (a) the a Seller’s
successful Bank
establishment
of a Baseline
(following
Submission
of two Initial
Baseline
Submissions
INDEX
with Zero
Mismatches) or
(b) the failure
to establish a
Baseline owing
to mismatches
having been
found between
the two Initial
Baseline
Submissions.
tsmt. Baseline Report To report to a A Buyer’s A buyer or

011.001.03 buyer or seller Bank or a seller
either a pre- a Seller’s
calculation Bank
or final
calculation of
the dynamic
part of an
Established
Baseline.


Message Type
tsmt. Data Set Match To report to a A Buyer’s A buyer or
013.001.03 Report buyer or seller Bank or a seller
on either a a Seller’s
Data Match Bank
or a Data
TABLE OF CONTENTS
Mismatch,
following
Submission of
all Data Sets
required by an
Established
Baseline and
the automatic
comparison
of such Data
Sets with that
Established
Baseline.
tsmt. Delta Report To list the A Buyer’s A buyer or

015.001.03 differences Bank or a seller
between the a Seller’s
Established Bank
Baseline
and a newly
proposed
Baseline,
following a
request for
a Baseline
Amendment.
tsmt. Error Report To advise A Buyer’s A buyer or

016.001.03 the inability Bank or a seller
INDEX
of the TMA a Seller’s

to process Bank
a message
received from
an Involved
Bank due to an
error detected
in that
message.
tsmt. Forward Data Set To pass on to a A Buyer’s A buyer or

017.001.03 Submission Report buyer or seller Bank or a seller
information a Seller’s
related to Bank
the Data Sets
covered by the
transaction.


Message Type
tsmt. Full Push Through To advise A Buyer’s A buyer or
018.001.03 Report the buyer or Bank or a seller
seller details a Seller’s
of a proposed Bank
Baseline, an
TABLE OF CONTENTS
Established
Baseline or
a proposed
amendment to
an Established
Baseline. The
Baseline data
forms part
of the Full
Push Through
Report.
tsmt. Mismatch To notify the A Seller’s A seller

021.001.03 Acceptance seller that Bank
Notification a buyer has
accepted a
Data Mismatch.
tsmt. Mismatch Rejection To notify a A Seller’s A seller

023.001.03 Notification seller that Bank
a buyer has
rejected a Data
Mismatch.
tsmt. Action Reminder To remind a A Buyer’s A buyer or

024.001.03 buyer or seller Bank or a seller
of an action a Seller’s
that is overdue. Bank
tsmt. Time-out To advise A Buyer’s A buyer or

INDEX
040.001.03 Notification a buyer or Bank or a seller

seller that a a Seller’s
transaction Bank
will be closed
within a given
time if no
action is taken.
tsmt. Forward Intent to To inform A Seller’s A seller

045.001.01 Pay Notification a seller of Bank
the Buyer’s
confirmed
intent to pay a
certain amount
at a certain
time in relation
to one or more
transactions.
tsmt. Intent to Pay To report upon A Buyer’s A buyer or

046.001.01 Report intent to pay Bank and a seller
messages a Seller’s
received. Bank
Table R: ISO 20022 TSMT messages that could be adapted and sent
from a bank to a corporate.

6.2 DIFFERENCES IN SCOPE

When a financial institution subscribes to a TMA, it does
so for the purpose of exchanging information with other
financial institutions that are similarly subscribed to the
same TMA.
The information itself will invariably be sourced from a
TABLE OF CONTENTS
corporate customer, a buyer or a seller, or a trusted third

party acting on behalf of that corporate customer. For
example, in order for a bank to submit an Initial Baseline
Submission, it must first receive the relevant purchase
order data from the buyer or seller. In order to submit a
Commercial Data Set, the bank must first receive the
relevant invoice data. The bank will validate and process
this data before submitting it to the TMA itself.
It follows that the scope of the messages exchanged
between a buyer or seller and a Buyer’s Bank or a
Seller’s Bank differs from that of the messages
exchanged between a Buyer’s Bank or a Seller’s Bank
and a TMA.
Any message sent by a buyer or seller to a Buyer’s Bank
or Seller’s Bank represents a request for that bank to
submit data to a TMA. The messages sent by the Buyer’s
Bank or Seller’s Bank to the TMA represent formal
instructions to act and form part of a structured
exchange of data between Involved Banks and the TMA.
It is important to bear in mind that any request received
INDEX
by a Buyer’s Bank or Seller’s Bank from a buyer or seller

will differ in content from the corresponding instruction
that is sent by the Buyer’s Bank or Seller’s Bank to the
TMA. For that reason, it is advisable that the buyer or
seller receives an acknowledgement and/or a copy of
that corresponding instruction from the Buyer’s Bank or
Seller’s Bank.
For example, if the buyer or seller submits a request to
create an Initial Baseline Submission, a copy of that
Baseline will be included in the Full Push Through
Report, which can be copied to the buyer or seller for
information purposes. Buyers and sellers should similarly
be copied in on any other responses received by the
Buyer’s Bank or Seller’s Bank from the TMA.
When a Buyer’s Bank or a Seller’s Bank submits an Initial
Baseline Submission message to a TMA, it will receive an
Acknowledgement message from the TMA. This
Acknowledgement message will contain a unique
transaction identifier code (TID), which must
subsequently appear on all related messages that are

exchanged between the Involved Banks and the TMA

regarding that particular transaction.
The buyer and the seller should be instructed to make
use of that same code in any messages that are
subsequently exchanged between themselves and an
Involved Bank.
TABLE OF CONTENTS
Before submitting an Initial Baseline Submission to a

TMA, a financial institution will perform all necessary
internal checks and validations and complete any
missing data that the corporate may be unable to
provide, such as the bank identifier code (BIC) of the
counterparty bank.
6.3 END-TO-END MESSAGE FLOWS

Adopting a similar style to Chapter 5 above, the end-to-
end message flows that could possibly take place
between buyers, sellers, Involved Banks and a TMA may
be illustrated by way of the following example in Flow
Diagram 23 (see pages 136-139):
INDEX

Buyer Buyer’s Bank/Obligor Bank TMA
Initial Baseline Submission

Request (with/without
BPO)
Initial Baseline
Submission
TABLE OF CONTENTS
Acknowledgement Acknowledgement
Copy (containing unique (containing unique
Transaction Identifier) Transaction Identifier)
Transaction
Status:
Proposed
Copy of Full Push Through Full Push Through Report

Report
Baseline Match Report
Copy of Baseline Match (Zero Mismatches)
Report
Transaction
Status:
Established
Report
Delta Report
Copy of Delta Report
Request to submit an Amendment Acceptance

Amendment Acceptance
INDEX
Copy of Acknowledgement Acknowledgement

Report
Baseline Report
Copy of Baseline Report
Copy of Forward Data Set Forward Data Set

Submission Submission

Seller’s Bank/Recipient Bank Seller

TABLE OF CONTENTS
Full Push Through Report Copy of Full Push Through Report
Baseline ReSubmission Copy of Baseline ReSubmission
Acknowledgement Copy of Acknowledgement (containing

(containing unique unique Transaction identifier)
Transaction identifier)
Baseline Match Report Copy of Baseline Match Report

(Zero Mismatches)
Baseline Amendment
Request to Amend Baseline
Request
Acknowledgement Copy of Acknowledgement
Delta Report Copy of Delta Report

INDEX
Amendment Acceptance Copy of Amendment Acceptance

Baseline Report Copy of Baseline Report
Data Set Submission Copy of Data Set Submission
Acknowledgment Copy of Acknowledgement

Buyer Buyer’s Bank/Obligor Bank TMA
Copy of Data Set Match Data Set Match Report

Report (with mismatches) (with mismatches) Transaction
Copy of Baseline Report Baseline Report Status: Active
Instruction to accept Mismatch Acceptance

TABLE OF CONTENTS
mismatches
Copy of Acknowledgement Acknowledgement
Copy of Data Set Match Data Set Match Report Transaction

Report Status:
Baseline Report Complete
Copy of Baseline Report
INDEX

Seller’s Bank/Recipient Bank Seller
Data Set Match Report Copy of Data Set Match Report (with
(with mismatches) mismatches)

TABLE OF CONTENTS
Mismatch Acceptance Copy of Mismatch Acceptance Notification

Notification
Data Set Match Report Copy of Data Set Match Report
Flow Diagram 23: Example of how messages might flow end-to-end

between buyer, Buyer’s Bank, Seller’s Bank and seller.
For the purposes of the above example, the possibility

of an Amendment Rejection or a Mismatch Rejection
has been ignored, as has the possibility of an invalid
submission resulting in an Error Report. Other messages
not shown in the example include the Action Reminder
and the Time-out Notification.
INDEX

Chapter 7
Corporate Agreements
TABLE OF CONTENTS
7.1 INTERACTIONS OUTSIDE THE SCOPE

OF THE URBPO
Figure 14 shows that the URBPO governs only those
interactions that take place between the TMA and an
Involved Bank. Any interactions between the bank and
its corporate customer or between the two corporate
counterparties (the buyer and the seller) are strictly
outside the scope of the URBPO.
Contract, e.g.
International Sale
Contract (includes BPO
Buyer under Payment
Seller
Conditions)
Customer Customer
Agreement Agreement
(includes definition TMA (includes definition
of any BPO-based of any BPO-based
banking service) banking service)
INDEX
URBPO
Figure 14: The URBPO governs interactions between Involved Banks and
the TMA.
Figure 15 illustrates the business flows that take place

outside the TMA and which are therefore outside the
scope of the URBPO.
These include the exchange of documents between the
buyer and the seller, the exchange of data between a
corporate customer and a bank and the execution of a
payment instruction between banks.

Contract
Buyer Shipment of goods and Seller

delivery of documents
Purchase Payment Payment Invoice Purchase

order data and order data
TABLE OF CONTENTS
shipment
data
Payment
Buyer’s Bank/ Seller’s Bank /

Figure 15: Business flows that take place outside the TMA are not
governed by the URBPO.
After a buyer and a seller have entered into a contractual

agreement in which the agreed payment term is shown
as a BPO, both the buyer and the seller will need to put
in place an agreement with a bank that is able to provide
them with the required BPO-related services.
It is important for the buyer and the seller to ensure that
both the Buyer’s Bank and the Seller’s Bank, as well as
any other bank as may be required to become involved
in the transaction, are all subscribed to the same
TMA scheme.
INDEX
When all of the underlying agreements between the

buyer, seller and participating banks are formally in
place, the exchange of data can begin. Purchase order
data must be provided by both buyers and sellers to
their respective banks in order that the Baseline can be
established. Once the goods are shipped, physical
documents are sent directly by the seller to the buyer.
The relevant data elements that have been extracted
from these documents are passed to the bank for
matching.
When the transaction is complete and all required data
has been satisfactorily matched, the payment is
authorised and executed.
All of these interactions take place outside the TMA.
They are not subject to the URBPO and do not require
adoption of ISO 20022 TSMT standards.

7.2 AGREEMENT BETWEEN A BUYER AND A SELLER

Any international business transaction requires a
precisely detailed underlying contract. The ICC Model
International Sale Contract provides a template for the
presentation of a set of clear and concise standard
contractual conditions for the most basic international
TABLE OF CONTENTS
trade agreement.
Although denominated as a “sale” contract, the model is
equally appropriate for use by buyers, as it balances the
interests of exporters (sellers) and importers (buyers). It
may therefore also be used for a purchase agreement.
The model contract is divided into two parts: Specific
Conditions, which allow the parties to use the model
directly by filling in the blanks in the form, and General
Conditions, which provide a platform of standard legal
terms and thus a reference tool for contract drafting or
negotiation. These General Conditions may be used
together with the Specific Conditions or independently.
The ICC Model International Sale Contract is specifically
adapted for transactions governed by the UN
Convention for the International Sale of Goods (CISG),
which applies to an increasingly large volume of
international sales.
The model is available for sale on the ICC’s website at:
www.iccwbo.org.
The expansion of global trade goes hand in hand with
INDEX
the need for standard contracts that are universally

acceptable. Without access to model contract forms,
SMEs in particular are at a disadvantage, as they risk
building the legal basis of their international business
dealings on agreements that have either been drafted
without any professional legal support or imposed by
the other party.
Large companies may also benefit from such models, as
they may offer the compromise required to solve the
deadlock entered into during negotiations.
In the past, model contracts often had a rather limited
focus. For example, sector-specific organisations
created standard contracts for their constituencies, and
there existed a host of models intended for specific
categories of users (e.g. buyers, agents, distributors,
manufacturers and so forth), which tended to provide
the best possible contractual solutions for the category
of user for which they were drafted.

7.2.1 The ICC Approach

The ICC has always favoured a different, more balanced
approach, as it aims to represent all those involved in
trade alike: sellers and buyers, principals and agents,
suppliers and distributors. Consequently, model
contracts issued by the ICC try to take into account the
interests of all parties involved, without favouring any
TABLE OF CONTENTS
one of them over another.

Although the basics of international sales do not change
overnight, model contracts should reflect current trade
usage or else they are bound to fall into disuse.
This requires models to be updated and revised from
time to time, but at the same time to remain predictable,
in line with proven practices.
7.2.2 Specific and General Conditions

The ICC Model International Sale Contract is intended to
be used by business circles, and its language is
conceived to be understandable for business people.
Therefore, the model is short, clear and specific, while
still presenting a comprehensive set of rights and
obligations. Moreover, it allows those not participating in
the negotiations to use the resulting contract as a guide
to executing the transaction and assessing the execution
of the agreement afterwards.
The contract is divided into two parts:
INDEX
a. Specific Conditions, setting out terms that are specific

to a particular contract of sale; and
b. General Conditions, setting out standard terms common
to all contracts.
The model has been designed on the assumption that
parties would normally use both parts, with each part
being drafted with the other part in mind.
It is particularly important to designate the mode and
time of payment. Where payment is to be made by
transfer to the Seller’s Bank, the bank or branch
identifier code should be clearly stated, together with
sufficient details to identify the account (IBAN or other)
and, if desired, the mode of the payment message (e.g.
wire transfer or electronic funds transfer).

Some of the payment modes available require the buyer

to execute payment or provide for payment security
prior to shipment of the goods. If the time of shipment
precedes the time of delivery (e.g. when selling
Documents Against Payment), the parties should not
only agree on a time of delivery but also on a time of
shipment.
TABLE OF CONTENTS
The model now also provides buyers and sellers with the
possibility to organise payment through a BPO.
7.2.3 Extract from the ICC Model International

Sale Contract
A-7 PAYMENT CONDITIONS (ART. 5)
Payment on open account (art 5.1)
Time for payment (if different from art 5.1) _____ days
from date of invoice. Other: _____
FF Open account backed by demand guarantee or standby
letter of credit (art. 5.6)
Payment in advance (art 5.2)
Date (if different from art 5.2): ________
FF Total price
FF % of the price: remaining amount ________%
to be paid at __________
FF Payment in advance backed by advance payment bond
INDEX
Documentary collection (art 5.4)

FF D/P Documents against payment
FF D/A Documents against acceptance
Irrevocable documentary credit (art 5.3)
FF Confirmed
FF Unconfirmed

Place of issue (if applicable)_________

Place of confirmation (if applicable)__________
Credit available:
FF At sight
FF By deferred payment at: __ days
TABLE OF CONTENTS
FF By acceptance of drafts at: __ days

FF By negotiation
Partial shipments: __ Allowed __ Not allowed
Transhipment: __Allowed __Not allowed
Date on which the documentary credit must be
notified to seller (if different from 5.3)
___ days before date of shipment other ___
Irrevocable Bank Payment Obligation (art 5.5)
FF Settlement by Payment
FF Settlement by Deferred Payment Undertaking
and payment at maturity. Deferred payment terms ___
days after sight or after date of ___
Date on which the Bank Payment Obligation must be
notified to seller (if different from art. 5.5)
___ days before date of shipment other ___
Other:______________________________
(e.g. cheque, bank draft, electronic funds transfer
INDEX
to designated bank account or seller)

Seller’s Bank Details
IBAN/bank account number_____________________________
BIC/SWIFT code_________________________________________
N.B. For information on IBAN, see http://www.ecbs.org/
iban.htm. For information on BICs, see https://www2.
swift.com/directories.
If the parties have agreed on payment against the
security of a BPO, then, unless otherwise agreed, the
buyer must arrange for the seller to receive an assurance
of payment in accordance with the agreed payment
terms in the form of a BPO to be issued by a bank in
favour of the Seller’s Bank, subject to the URBPO, and to
be notified at least 30 days before the agreed date of
shipment or at least 30 days before the earliest date
within the agreed shipment period. Unless otherwise
agreed, the BPO is payable at sight.

7.3 AGREEMENT BETWEEN A CORPORATE

CUSTOMER AND A FINANCIAL INSTITUTION
Financial institutions in general will have standard
templates (boilerplates) in place to reflect the terms and
conditions and levels of service under which specific
services will be delivered to their corporate customers.
TABLE OF CONTENTS
When incorporating a BPO-related service into such

agreements, it is the financial institution’s responsibility
to ensure compliance with applicable law and its own
policies and procedures. Issues to take into account
when considering the wording of such agreements
include the following:
definition of the banking service;
commercial terms for the delivery of such service, in
particular payment and settlement that fall outside
the scope of both the TMA and the URBPO;
any operational requirements that may need to be
complied with in relation to the exchange of data
with a TMA and the terms and conditions applied by
the operator of the transaction matching service;
any limitations linked to the availability of the TMA;
any limitations around the amendment of
instructions and/or processing of mismatched data;
and
definition of force majeure.
INDEX

Chapter 8
BPO Business Scenarios
The Bank Payment Obligation (BPO) may be regarded

first and foremost as a risk mitigation tool. It provides the
means to ensure that a buyer receives the goods or
services required and that that the seller is paid on time.
As such, a BPO may be seen to complement the
traditional trade finance services that are currently
available, not only through documentary letters of credit,
but also alternative instruments such as payment
guarantees, standby letters of credit and credit insurance.
The BPO may also be used to support a variety of
financing propositions. As such, it is again
complementary to existing trade services available not
only through documentary letters of credit but also
factoring, forfaiting and so-called “reverse factoring” or
approved payables finance.
Figure 16 shows the high-level flows associated with the
establishment of a Baseline, based upon the matching of
purchase order data and the subsequent matching of
invoice and transport data that results in the BPO
BPO data becoming due.
flows for the Transaction Matching Application
Banks Trade Platforms need to offer

workflow capability with a secure
exchange mechanism that guarantees
Importer data authentification and integrity Supplier
(Purchasing unit) (Business unit)
6
1 4 7 5
Purchase Match Accept or Invoice
order results reject Select the BPO option and
data mismatches shipment
data
2 PO Advise
2 PO Advise
3 (Accept) PO data
4 Match results TMA 4 Match results
6 Match results
6 Invoice & shipment data
Obligor Bank Recipient
Bank
8 (Conditional) Payment at maturity
Figure 16: Overview of BPO-related flows through a TMA. Source: ICC

At various stages in the BPO transaction lifecycle, it is

possible for Involved Banks to identify trigger points for
the provision of risk mitigation and financing services
based upon the electronic matching of data.
This is increasingly important in a world where more and
more trade is being conducted on open account, that is,
TABLE OF CONTENTS
where physical documents are sent directly from the

seller to the buyer instead of being routed through the
banking system.
The fact that the processing of the BPO revolves around
an automated matching of data rather than the physical
examination of documents means that any risk of delay
arising out of a dispute over “discrepancies” can be
minimised. Data “mismatches” are highlighted
immediately so that the Buyer’s Bank can either accept
or reject them.
Automation also allows additional flexibility in the
handling of amendments and the ability to reduce the
cost of capital, for example by delaying the issuance of
the BPO. All of this adds up to increased process
efficiency for everyone involved in the supply chain.
The objective is to fill in the missing links. While the
management of the physical supply chain refers to the
movement of goods from production to distribution, the
management of the financial supply chain refers to the
movement of money and hence working capital.
INDEX
These two sides of the supply chain can effectively be

linked together by the processing of information and the
generation of reports by a centralised TMA, using a BPO
to facilitate a comprehensive range of bank-assisted
open account services, including risk mitigation,
payment assurance and financing.
8.1 BANK-ASSISTED OPEN ACCOUNT

It is estimated that more than 80% of world trade today
is conducted on open account, not making use of
traditional trade finance instruments such as
documentary letters of credit. At the same time, the
industry as a whole has suffered from a lack of clear
definition around what open account is.
In 2011 the Washington-based BAFT-IFSA organisation
(see www.baft-ifsa.com) took the initiative to publish a
standard set of product definitions for open account
trade processing and open account trade finance, in
support of its mandate to evaluate and guide
standardisation, improve risk management and enhance

the role and relevance of financial institutions.

Part of the rationale behind this common list of
definitions was a recognition of the fact that the recent
development of new technologies has brought about an
opportunity for increased collaboration between banks
to service the business needs of both buyers and sellers.
TABLE OF CONTENTS
There is now an established niche for open account

transactions to benefit from bank assistance, particularly
in those areas where access to working capital finance
may still be required. The BAFT-IFSA definitions are
designed to provide clarity on open account trade-
related products and services.
They describe open account transaction lifecycles and
identify related trade service processing and financing
services that a bank may provide. Additionally, these
definitions are designed to provide the flexibility to
encourage service customisation and differentiation,
thus enabling banks to enhance further the wide
spectrum of solutions covering different elements of the
transaction banking value chain.
During the course of this chapter, we will use the
BAFT-IFSA standard definitions as a means of
illustrating a range of BPO-related business scenarios.
In Table S, the processing and financing opportunities
are matched to the corresponding trigger points in the
supply chain.
INDEX
Supply Chain Trigger Bank Processing Bank Financing Opportunity

Points Opportunity
Purchase Order agreed Purchase Order Advice Pre-Shipment Finance
Goods warehoused Document Checking/ Warehouse Finance

Data Matching
Documents issued Documents/Purchase Receivables Purchase

Order Reconciliation
Documents presented Document Checking/ Post-Shipment Finance

Data Matching
Documents approved Management of Approved Payables Finance

Approved Documents
Due date Document Payment Repay any outstanding

financing
Table S: Trigger points for the provision of financial supply chain services.
Source: BAFT-IFSA

8.2 OPEN ACCOUNT PROCESSING/SERVICING

Open account processing is linked to the existing
processing capabilities for trade services, including
purchase order upload, data matching and payment
services. An important aspect of this activity is the
exchange and sharing of data to trigger supply chain
TABLE OF CONTENTS
finance opportunities.
8.2.1 Purchase Order Advice

A purchase order specifying the goods and terms is
created by the buyer. The seller is then notified of the
purchase order and other shipping instructions through
a collaboration platform, fax, email, portal or other
method. Once notified, the buyer may require the seller’s
acknowledgement. Source: BAFT-IFSA
In Figure 17 we show the agreement of the purchase
order details between the buyer and the seller. Both
buyer and seller must subsequently upload these
purchase order details to their own banks. All of this
happens outside the TMA and outside the scope of
the URBPO.
Purchase order
details agreed
Buyer Seller
INDEX
PO details PO details
uploaded uploaded
to bank to bank
TMA

Figure 17: Buyers and sellers must upload their purchase order data
to the bank.
In the example shown in Figure 18, the Initial Baseline

Submission is submitted by the Buyer’s Bank. It is
equally possible for the Initial Baseline Submission to be
submitted by the Seller’s Bank.

Buyer Seller
TMA 2
1 Full Push
Initial 3 Through
TABLE OF CONTENTS
Baseline Baseline Report

Submission ReSubmission
4 Baseline Match Report

(Zero Mismatches)

Figure 18: The banks will use the PO data to create a Baseline in the TMA.
The Baseline may include a BPO.
On receipt of the Initial Baseline Submission, the TMA

generates a Full Push Though Report, which contains a
copy of the proposed Baseline. In response to the Full
Push Through Report, the Seller’s Bank must resubmit
the Baseline so that the transaction can become
established in the TMA.
In this example, there are two banks only, the Buyer’s
Bank and the Seller’s Bank. Therefore, if the Baseline
ReSubmission of the Seller’s Bank matches the Initial
Baseline Submission of the Buyer’s Bank, the TMA will
generate a Baseline Match Report with Zero Mismatches
and the Baseline will be established.
INDEX
If the Baseline includes a BPO (which is optional), then

the BPO is also established. At this point, the Buyer’s
Bank would become the Obligor Bank and the Seller’s
Bank would become the Recipient Bank (see Figure 19).
Buyer Seller
TMA 2
1 Full Push
Initial 3 Through
(including
BPO)
4 Baseline Match Report BPO established

(Zero Mismatches)
Figure 19: If the Baseline includes a BPO, the Buyer’s Bank becomes the
Obligor Bank and the Seller’s Bank becomes the Recipient Bank.

5 6
Full Push Role and
Through
Obligor Baseline
Report Bank Acceptance
TABLE OF CONTENTS
TMA 2
1
Full Push
Initial 3 Through
(including
BPO) BPO established
with other
Obligor Bank
7 Role and Baseline
Acceptance Notification
Buyer’s Bank/ (Zero Mismatches) Seller’s Bank/
Figure 20: If another Obligor Bank is involved, it must accept its role by
submitting a Role and Baseline Acceptance message.
If there are more than two banks involved in the

transaction (e.g. another bank is named as an Obligor
Bank in the Baseline), then the Baseline status will remain
“partially matched” unless or until the other bank accepts
its role as an Obligor Bank in the transaction. This bank
may be acting as an Obligor Bank either instead of the
Buyer’s Bank or in addition to the Buyer’s Bank.
In such cases, the TMA will send another Full Push
INDEX
Through Report to the other bank, in response to which

the bank must submit a Role and Baseline Acceptance
message, confirming its acceptance of its role, for
example, as an Obligor Bank (see Figure 20).
Provided the other bank does accept its role, the TMA
will advise both the Buyer’s Bank and the Seller’s Bank
by sending them a Role and Baseline Acceptance
Notification message. If the Baseline includes a BPO, the
Seller’s Bank will in any case become the Recipient Bank,
since the beneficiary of a BPO is always the Seller’s Bank.
Should the additional bank fail to accept its role, the
Baseline will remain unestablished. The Buyer’s Bank and
Seller’s Bank will need to agree an alternative course of
action, such as amending the Baseline in order that
another bank can be invited to act as Obligor Bank. If no
agreement can be made, the transaction will be closed.

The above examples illustrate how a TMA can be

deployed to support purchase order advice, potentially
including a BPO to facilitate risk mitigation, payment
assurance and financing.
8.2.2 Document Presentment and Data Matching

Documents are created and presented by the seller.
TABLE OF CONTENTS
Matching criteria under Open Account are defined by

the buyer. They may consist of simple checking for the
presence of all the required documents or detailed
checking of specific data values within or among
documents in an automated, semi-automated, or manual
fashion as defined in the Purchase Order Advice.
[Source: BAFT-IFSA]
Data matching replaces document checking. In a
BPO-related transaction, the relevant data elements as
specified in the Baseline are extracted from the
corresponding commercial invoice and transport
documents and input into the TMA in the form of
Data Sets.
The seller must deliver the data (or documents) to the
Seller’s Bank/Recipient Bank. This happens outside the
TMA and therefore outside the scope of the URBPO
(see Figure 21).
Shipment of goods and

Buyer Seller
INDEX
Invoice
and
shipment
data

Figure 21: The seller must deliver the commercial and transport data to
the Seller’s Bank.
The Seller’s Bank will use this data to create the

Commercial and Transport Data Sets. These Data Sets
are input into the TMA and compared to the
If the data comparison results in Zero Mismatches, the
TMA will generate a Data Set Match Report with Zero
Mismatches (see Figure 22).

If there is a BPO, then the BPO is now due, since all the
data matching requirements included in the Baseline
will have been met. This will be reflected in the
Baseline Report.
TABLE OF CONTENTS
Buyer Seller
TMA
1
Data Set
Submission
2 Baseline Report
BPO due
2 Data Set Match Report
(Zero Mismatches)
Figure 22: If the data comparison results in Zero Mismatches, the TMA
will send a Data Set Match Report with Zero Mismatches and a Baseline
Report to the Buyer’s/Obligor Bank and the Seller’s/Recipient Bank. The
BPO is now due.
If there is an additional bank involved in the transaction,

that bank will also receive a copy of the Data Set Match
Report and Baseline Report (see Figure 23).
INDEX
2 2
Data Set Baseline Report
Match
Obligor
Report Bank
(Zero
Mismatches) BPO with other
Obligor Bank
TMA is due
1
Data Set
Submission
2 Baseline Report
(Zero Mismatches)
Figure 23: Additional banks will receive a copy of the Data Set Match
Report with Zero Mismatches and Baseline Report. The BPO with other
Obligor Bank(s) is now due.

8.2.3 Discrepancy Handling/Dispute Resolution

If the matching results include discrepancies between
the buyer’s matching criteria and the presented
document data, the buyer is typically notified to
determine if the documents will be rejected or approved.
For efficiency purposes, the buyer can pre-authorise the
bank to pay documents where there are no
TABLE OF CONTENTS
discrepancies. Dispute resolution enables buyers and

sellers to resolve disputes related to Open Account
activity on-line or via other methods of communication.
[Source: BAFT-IFSA]
If a data comparison results in a mismatch of data
between the Data Set(s) and the Established Baseline,
the TMA will generate a Data Set Match Report that will
highlight such mismatches (see Figure 24).
Buyer Seller
TMA 1
Data Set
Submission

(Mismatches)
INDEX

Figure 24: If the Data Set(s) contain mismatches, these will be reported in
the Data Set Match Report.
The Buyer’s Bank/Obligor Bank now has the option

either to accept or to reject these mismatches.
Mismatches can be accepted by the submission of a
Mismatch Acceptance. The TMA will then issue a
Mismatch Acceptance Notification and Baseline Report
to Involved Banks (see Figure 25). The Baseline Report
will reflect the acceptance of the mismatches. In
addition, the BPO will become due, since all matching
conditions have been met.

Buyer Seller
TMA
3 1
Mismatch Data Set
Acceptance Submission
TABLE OF CONTENTS
5 Baseline Report BPO due after

Mismatch
4 Mismatch Acceptance
Acceptance
Notification
Buyer’s Bank/ 2 Data Set Match Report Seller’s Bank/
Obligor Bank (Mismatches) Recipient Bank
Figure 25: If the Buyer’s Bank accepts the mismatches, the TMA sends
a Mismatch Acceptance Notification and Baseline Report to Involved
Banks. The BPO is due.
If the Buyer’s Bank does not accept the mismatches, it

will submit a Mismatch Rejection message to the TMA.
The TMA will then issue a Mismatch Rejection
Notification message. In this instance, the Baseline
remains unchanged. The rejected Data Set is effectively
discarded, and the BPO is not due (see Figure 26).
Buyer Seller
INDEX
TMA
3 1
Mismatch Data Set
Rejection Submission
4
Mismatch
Rejection
Notification

Buyer’s Bank/ (Mismatches) Seller’s Bank/
Figure 26: If the Buyer’s Bank rejects the mismatches, the Baseline
remains unchanged and the BPO is not due.
The ability to accept mismatches that are identified

simply, clearly and early through the electronic
comparison of data reduces the risk of delays being
caused by disputes over discrepancies. This reinforces
the value of the BPO as a means of avoiding the risk of
late payment and providing an assurance that payment
will be made on time as per the agreed terms.

If there are other Obligor Banks involved in the

transaction, the Buyer’s Bank must first accept the
mismatches. The TMA will then send a Full Push
Through Report to the other Obligor Banks inviting
them to respond with a Role and Baseline Acceptance.
Provided the other banks accept their continued roles
following the acceptance of mismatches by the Buyer’s
TABLE OF CONTENTS
Bank, then the transaction may proceed to completion.

The TMA will issue a Role and Baseline Acceptance
Notification and a Baseline Report reflecting that the
BPO is now due (see Figure 27).
5 8
Role and
Baseline
Full Push Baseline
Obligor Acceptance
Through Report
Report Bank
TMA
BPO due after Mismatch
3 Acceptance and Role
1
Mismatch and Baseline Acceptance
Acceptance Data Set
Submission
8 Baseline Report
7 Role and Baseline
Acceptance Notification
Buyer’s Bank/ 4 Mismatch Acceptance Seller’s Bank/
Obligor Bank Notification Recipient Bank
INDEX

(Mismatches)
Figure 27: If the additional Obligor Bank accepts its continued role fol-
lowing the acceptance of mismatches by the Buyer’s Bank, it will submit
a Role and Baseline Acceptance message. The TMA will send a Role and
Baseline Acceptance Notification to the other banks and issue a Baseline
Report to reflect the changes and to show that the BPO is now due.
If an additional Obligor Bank rejects its continued role

by sending a Role and Baseline Rejection message, then
the Baseline will remain unchanged (see Figure 28). The
Data Set Submission will effectively be discarded and
the BPO is not due. The other Involved Banks must now
decide what action to take in order for the transaction
to continue, such as requesting a Baseline Amendment
to remove/replace the bank that has rejected its role.

5 6
Full Push Role and
Obligor
Through Baseline
Report Bank Rejection
TABLE OF CONTENTS
3
TMA 1
Mismatch Data Set
Acceptance Submission
7 Role and Baseline

Rejection Notification
4 Mismatch Acceptance
Buyer’s Bank/ Notification Seller’s Bank/
(Mismatches)
Figure 28: If an Obligor Bank rejects its role following the acceptance of
mismatches by the Buyer’s Bank, the Baseline will remain unchanged
and the BPO is not due.
8.2.4 Management of Approved Invoices/Drafts

The bank manages the approved documents process
with respect to potential financing and the scheduling of
transaction settlement and/or the collection of invoice
proceeds. [Source: BAFT-IFSA]
INDEX
As we have seen previously, once the goods have been

shipped, the seller is required to upload the commercial
and transport data to the Seller’s Bank in order that the
Seller’s Bank can submit the relevant Data Sets for
matching. If the Data Sets match, or if mismatches are
accepted, it means that the commercial invoice data has
been approved. This in turn means that the Seller’s
Bank/Recipient Bank may agree to finance the seller
and that any BPO that has been issued may be relied
upon as a source of repayment. This scenario is played
out in Figures 29, 30 and 31.

Shipment of goods and

Buyer Seller
Invoice
and
shipment
data
TABLE OF CONTENTS

Figure 29: The seller uploads the commercial invoice and transport data
as before.
Buyer Seller
TMA
1
Data Set
Submission
BPO due
2 Baseline Report
INDEX

Figure 30: The Seller’s Bank/Recipient Bank submits the Data Sets that
match the Established Baseline. This means that any BPO that was
included in the Baseline is now due.
Buyer Seller
Opportunity to finance
approved invoices
and to manage the
collection of proceeds
relying on the BPO as
a source of repayment

Figure 31: The Seller’s Bank/Recipient Bank can now rely upon the BPO
as a source of repayment.

8.2.5 Document Payment

The buyer pays at maturity (usually the document due
date) and the seller is paid or Seller’s financing (if any)
is repaid with any remaining proceeds going to the
seller. [Source: BAFT-IFSA]
Following on from the management of approved
TABLE OF CONTENTS
invoices under 8.2.4 above, the Seller’s Bank/Recipient

Bank will eventually collect payment from the Buyer’s
Bank/Obligor Bank in accordance with the agreed terms
of the BPO.
If the Seller’s Bank/Recipient Bank has provided finance
to the seller, then the proceeds of the BPO payment will
be used as a source of repayment. Otherwise, the
Seller’s Bank/Recipient Bank will complete payment to
the seller (see Figure 32).
Buyer Seller
Payment Payment
At maturity, the Obligor Bank

will collect payment from
the buyer and pay the
Recipient Bank in accordance
with the terms of the BPO.
Monies received will either be
INDEX
applied in repayment of
financing or paid to the seller.
(BPO) Payment

Figure 32: The Obligor Bank will pay the Recipient Bank at maturity in
accordance with the agreed settlement terms of the BPO.
8.2.6 Documents/Payment Reconciliation

When payment is received, the bank may, on behalf of
the buyer and the seller, reconcile payment to the
documents’ value (usually the invoice/draft value) and
keep track of PO balances. [Source: BAFT-IFSA]
Reporting services will be proprietary to each TMA. It
would normally be expected that each TMA will be
capable of generating reports automatically upon the
completion of an event. For example, the Baseline Match
Report will be sent automatically upon successful
establishment of a Baseline, and a Data Set Match

Report will be automatically generated after Submission

of Data Sets.
In addition to these automatically generated reports, the
ISO 20022 TSMT messaging standards provide for the
delivery of reports that may be requested by an Involved
Bank at any time. These reports include an Activity
TABLE OF CONTENTS
Report to describe activities that have taken place

within a given time span, a Transaction Report to
provide details relating to a specific transaction and a
Status Report to report on the current status of any
transactions in which a bank may be involved (see
Figure 33). The TMA operator may levy an additional
charge for such reports.
Buyer Seller
TMA
Report Report
Requests Requests
Activity Report
Status Report
Buyer’s Bank/ Transaction Report Seller’s Bank/
Figure 33: The Buyer’s Bank/Obligor Bank and the Seller’s Bank/Reci-
INDEX
pient Bank can request a variety of reports to be generated by the TMA

at any time.
Buyer Seller
Payment and Payment and

Account Account
Reconciliation Reconciliation
services services
TMA

Figure 34: Using the TMA generated reports, the Buyer’s Bank/Obligor
Bank and the Seller’s Bank/Recipient Bank will be able to offer a range
of value-added payment and account reconciliation services.

The information included in these reports will enable the

bank to keep track of outstanding purchase orders and
reconcile payments made pursuant to approved
invoices. This in turn facilitates the provision of value-
added payment and account reconciliation services to
the corporate customer (see Figure 34).
TABLE OF CONTENTS
8.3 OPEN ACCOUNT FINANCE

Financial supply chain solutions are designed to link
together buyers, sellers and financial institutions in order
to facilitate financing opportunities across the entire
lifecycle of an open account trade transaction.
8.3.1 Purchase Order Commitment to Pay

The Buyer’s Bank issues its commitment to pay the
seller (at sight or at maturity) once the seller ships and
makes available the required documents that match the
purchase order and other stipulated conditions. This
service allows the seller to take the risk of the bank
issuing its commitment to pay instead of that of the
buyer. [Source: BAFT-IFSA]
As we have seen previously, the establishment of a
Baseline is indicative of a purchase order match. That is
to say that the two Baseline Submissions, which are
both based upon the same data elements extracted
from the agreed purchase order, have been compared
and matched resulting in Zero Mismatches. If the
INDEX
Baseline includes a BPO, the BPO is also established

(see Figure 35). In this case, the Buyer’s Bank may
assume the role of the Obligor Bank, and the Seller’s
Bank will assume the role of the Recipient Bank.
Buyer Seller
TMA 2
1
Full Push
Initial
3 Through
Baseline
Baseline Report
Submission
(including ReSubmission
BPO)
BPO established
(Zero Mismatches)
Figure 35: If the two Baseline Submissions match, the Baseline is
established. If a BPO is included, the BPO is also established.

At this point, the BPO represents the commitment of the

Buyer’s Bank/Obligor Bank to pay the Seller’s Bank/
Recipient Bank or to incur a deferred payment
obligation and pay at maturity. Relying on this
commitment to pay and taking into account the risk of
the Obligor Bank, the Seller’s Bank/Recipient Bank is
able to consider any request for financing from the seller
TABLE OF CONTENTS
(see Figure 36).
Buyer Seller
Opportunity for the Recipient

Bank to provide working capital
finance to the seller based upon
purchase order commitment to
pay (BPO of the Obligor Bank)
Figure 36: The Seller’s Bank/Recipient Bank may consider financing the
seller based upon the purchase order commitment to pay (BPO) of the
Obligor Bank.
8.3.2 Pre-Shipment Finance

INDEX
Pre-Shipment Finance, also known as purchase order

financing, is made available to a seller based on a
purchase order received from a buyer. This financing can
cover all the related working capital needs of the seller
including raw materials, wages, packing costs and other
pre-shipment expenses. Once the goods are ready,
refinancing or repayment can occur. [Source: BAFT-
IFSA]
As per the purchase order commitment to pay
arrangements shown under 8.3.1 above, an offer of
pre-shipment finance is dependent upon the
confirmation of a purchase order, as may be evidenced
by the establishment of a TMA Baseline (see Figure 37).

Buyer Seller
TMA 2
1
Full Push
Initial
3 Through
Baseline
TABLE OF CONTENTS
Baseline Report
Submission
(including ReSubmission
BPO)
BPO established
(Zero Mismatches)
Figure 37: The establishment of the Baseline confirms the agreed content
of the purchase order.
The scenario shown here is very similar to the one

shown under 8.3.1.
The terms and conditions attached to an offer of
pre-shipment finance (see Figure 38) may vary from
those attached to finance under a purchase order
commitment to pay.
Buyer Seller

INDEX
Bank to make an offer

of pre-shipment finance
to the seller based upon the
BPO of the Obligor Bank
Figure 38: Similar to Figure 33, the Recipient Bank may consider making
an offer of finance to the seller, relying on the BPO of the Obligor Bank
as a source of repayment.
8.3.3 Warehouse Finance

Warehouse financing is a form of trade finance in which
goods are held in a warehouse for the buyer, usually by
the seller, until needed. At a minimum, warehouse
receipts are commonly required as evidence for the
financing. Some banks may only do this under
structured trade transactions. [Source: BAFT-IFSA]

The Submission of data into a TMA provides visibility

into the underlying trade transaction. This enables
Involved Banks to keep track of the movement of goods
along the physical supply chain, opening up the
possibility to identify multiple trigger points for the
delivery of financial services, including financing itself.
TABLE OF CONTENTS
The matching of warehouse receipt data to an

Established Baseline could be used as a means to
support a proposition for warehouse finance.
This is one example where a Seller’s Bank/Recipient
Bank may wish to take advantage of the possibility to
“pre-match” in order to force a match of a Data Set, the
results of which will be seen by the Seller’s Bank/
Recipient Bank only (see Figure 39).
Buyer Seller
TMA 1
Data Set
Submission
(Pre-Match
only)
2
Data Set
Match Report
INDEX
(Zero
Obligor Bank Mismatches) Recipient Bank
Figure 39: A Seller’s Bank/Recipient Bank can submit a Data Set with the
instruction “pre-match” in order to force a match, the results of which
are seen by the Seller’s Bank/Recipient Bank only.
If the Seller’s Bank/Recipient Bank is satisfied that the

data matches, it may be in a position to make an offer of
warehouse finance to the seller (see Figure 40).

Buyer Seller
Based upon the pre-matching

of the Data Set to the
Established Baseline, the
TABLE OF CONTENTS
Seller’s Bank may consider

making an offer of warehouse
finance to the Seller.

Figure 40: The pre-matched Data Set enables the Seller’s Bank/Recipient
Bank to consider a request for warehouse finance.
8.3.4 Post-Shipment Finance

Post-shipment finance is provided to a seller using the
receivable as collateral. The seller presents shipping
documents as evidence of a receivable and the bank
may also require a bill drawn on the buyer for the goods
exported. The bank may prefer to purchase and
discount a bill drawn on the buyer for the goods
exported. [Source: BAFT-IFSA]
Once the goods have been shipped, the seller is able to
send the documents directly to the buyer in order that
INDEX
the buyer can take delivery, just as they would in a pure

open account arrangement.
At the same time, the seller will submit related data to
the Seller’s Bank in accordance with the Established
Baseline. The Submission of matching Data Sets will
cause the BPO to become due (see Figure 41). The
Obligor Bank must then pay the Seller’s Bank/Recipient
Bank or incur a deferred payment obligation and pay
at maturity.

Buyer Seller
TMA
1
Data Set
Submission
TABLE OF CONTENTS
BPO due
2 Baseline Report
Figure 41: The BPO becomes due upon Submission of matching Data Sets.
If payment is deferred to a due date at some time in the

future, say 180 days, there is an opportunity for the
Seller’s Bank/Recipient Bank to provide post-shipment
finance to the seller. Reliance is placed on the Obligor
Bank’s commitment to pay at maturity (see Figure 42).
Buyer Seller

Bank to make an offer of
post-shipment finance to the
INDEX
Seller based upon the BPO of

the Obligor Bank
BPO PAID AT MATURITY

Figure 42: The Seller’s Bank/Recipient Bank may rely upon the Obligor
Bank’s BPO to support a proposition for post-shipment finance.
At this later stage of the transaction lifecycle, when the

goods have been shipped and the invoice and transport
data have been matched, this represents a more secure,
less risky form of finance than the earlier confirmed
purchase order/pre-shipment financing scenarios.

8.3.5 Approved Payables Finance

Approved Payables Finance allows sellers to sell their
receivables and/or drafts relating to a particular buyer to
a bank at a discount as soon as they are approved by
the buyer. This allows the buyer to pay at normal
invoice/draft due date and the seller to receive early
payment. The bank relies on the creditworthiness of the
TABLE OF CONTENTS
buyer. [Source: BAFT-IFSA]

In recent times, a considerable amount of interest has
been expressed in so-called “reverse factoring”. Some
niche market players have marketed this service as
“supply chain finance”, while a more accurate
description of the service in question would arguably be
“approved payables finance”.
In simple terms, this is a business scenario that enables a
bank to finance the seller by placing reliance on the
creditworthiness and credit rating of the buyer and
making use of the buyer’s own credit lines.
Since the financing arrangements are reliant upon the
availability of credit from the buyer, approved payables
finance business has tended to flourish in what is
popularly known as the “three corner model”, where
only one bank, namely the Buyer’s Bank, is involved, to
the exclusion of the Seller’s Bank. That is to say that the
Buyer’s Bank finances the seller directly.
This kind of structure originally emerged in the Spanish-
speaking countries, where it was known as “confirming”.
INDEX
Given the three corner nature of the business model, it is

an arrangement that works well for big players with
global reach and the capacity to support the supplier
base of big buyers. Other banks are able to participate
in these arrangements by subscribing to a multi-bank
platform where buyers, sellers and financial institutions
are able to share information related to the management
of risk and financing.
The BPO potentially offers an alternative approach to
approved payables finance, moving away from the
“three corner model” towards a “four corner model” in
which a Buyer’s Bank/Obligor Bank and a Seller’s Bank/
Recipient Bank may collaborate with one another. Once
again, the ability to pre-match Data Sets may be
advantageous to this scenario.

Very often, a seller may not have identified an early

requirement for financing. If the seller has confidence
that the buyer will pay and has no identified need for
finance, it is possible for a Baseline initially to be set up
in the TMA without the inclusion of a BPO.
It will sometimes happen that the seller then does have
TABLE OF CONTENTS
a need for finance but this need arises only very late in
the transaction lifecycle.
One thing always to bear in mind here is that a BPO
cannot be created after Submission of matching Data
Sets. The simple reason for this is that a BPO always
represents a conditional obligation to pay. The
conditional element of a BPO is that the Data Sets
specified in the Established Baseline are an exact match.
In order to satisfy these conditions, the Data Sets must
always be submitted after the establishment of the BPO,
and never before. If the Data Sets required in the
Established Baseline have already been submitted and
matched, a BPO cannot now be created since the
matching conditions can never be met. Hence, the
potential advantage of the “pre-match”.
In order to support this kind of business scenario, the
Baseline must first be established without a BPO (see
Figure 43).
INDEX
Buyer Seller
TMA 2
1
Full Push
Initial
Through
Baseline 3
Report
Submission Baseline
(without ReSubmission
BPO)

(Zero Mismatches)
Buyer’s Bank NO BPO Seller’s Bank
Figure 43: Baseline establishment without a BPO.
At the next step, when the goods have been shipped and
the documents have been sent directly from seller to
buyer, thus enabling the buyer to take delivery, the seller
submits the data to the Seller’s Bank but requests the
Seller’s Bank to keep open the possibility of providing
finance against the selected invoices, should the need for
short-term finance arise before the due date.

Buyer Seller
TMA 1
Data Set
Submission
TABLE OF CONTENTS
(Pre-Match
only)
2
Data Set
Buyer’s Bank Match Report Seller’s Bank
(Zero
Mismatches)
Figure 44: By submitting data for a pre-match, the Seller’s Bank retains
the option to create a BPO.
In order to retain the possibility of creating a BPO

against the related invoices, the Seller’s Bank will request
a “pre-match” (see Figure 44). By doing this, the Seller’s
Bank can satisfy itself in advance that the Data Sets,
when eventually presented for full matching, will match.
In order to create a BPO after a Data Set pre-match, the
Seller’s Bank will need to submit a Baseline Amendment
Request message. This message will request an
amendment to the Baseline to add a BPO. The TMA will
send details of the proposed amendment to the Buyer’s
INDEX
Bank. Of course, the Buyer’s Bank must agree to the

proposed amendment by sending an Amendment
Acceptance to the TMA in which case the Baseline will
be amended and the BPO will come into force (see
Figure 45).
If the Buyer’s Bank rejects the proposed amendment, it
will send an Amendment Rejection message to the TMA
and the Baseline will remain unchanged.

Buyer Seller
TMA 1
3
Amendment Baseline
Acceptance Amendment
TABLE OF CONTENTS
2
(BPO) Request
Full Push 4 (BPO)
Through Amendment
Report Acceptance
Notification
BPO
5 Baseline Report established

Figure 45: If the Buyer’s Bank accepts the Baseline Amendment Request,
the BPO is established. The Buyer’s Bank becomes the Obligor Bank and
the Seller’s Bank becomes the Recipient Bank.
After the BPO has been established, the Seller’s Bank/

Recipient Bank may, if it wishes to do so, immediately
submit the Data Sets for full data matching. Having
already submitted the data for a successful pre-match,
the Seller’s Bank/Recipient Bank knows that the Data
Sets will match and that the BPO will therefore become
due (see Figure 46).
INDEX
Buyer Seller
TMA 1
Data Set
Submission
BPO due
2 Baseline Report
Figure 46: When the Data Sets are successfully matched to the Esta-
blished Baseline, the BPO becomes due.
If the BPO is payable on deferred payment terms, the

Seller’s Bank/Recipient Bank may now consider
financing the seller, placing reliance on the BPO of the
Obligor Bank as its source of repayment (see Figure 47).

Buyer Seller

Bank to make an offer of
approved payables finance to
TABLE OF CONTENTS
the Seller based upon the BPO

of the Obligor Bank

Figure 47: The Seller’s Bank/Recipient Bank can finance the seller directly
using the BPO of the Obligor Bank as collateral.
8.3.6 Receivables Purchase

Receivables Purchase allows sellers to sell their
receivables/drafts relating to one or many buyers to
their bank to receive early payment. The bank may
require insurance and/or limited or full recourse to the
seller to mitigate the risk of the pool of
receivables. [Source: BAFT-IFSA]
This scenario can again be underwritten by the
matching of the Data Sets to the Established Baseline so
that the BPO is due (see Figure 48).
INDEX
Buyer Seller
TMA 1
Data Set
Submission
BPO due
2 Baseline Report
Figure 48: The matching of the Data Sets to the Established Baseline
means the BPO is due.
As a variation on previous scenarios, the Seller’s Bank/

Recipient Bank may elect to purchase the receivables.
Repayment will in any case eventually come from the
Obligor Bank.

This scenario is further illustrated and completed in

Figures 49 and 50.
Buyer Seller
TABLE OF CONTENTS
Opportunity for the

Recipient Bank to finance
the Seller through the
purchase of receivables

Figure 49: The Seller’s Bank/Recipient Bank can discount the receivables
and obtain repayment from the Obligor Bank on the due date.
Buyer Seller
Payment
INDEX
(BPO) Payment on the due date

Figure 50: The Obligor Bank pays on the due date.
8.3.7 Flexible Due Date

As an alternative to payment on the scheduled repay
ment date, customers may request payment prior to or
following the scheduled due date. Repayment prior to
the scheduled date would result in expected prepayment
discount, while extensions of due date would equate to
additional financing. [Source: BAFT-IFSA]
Another illustration of the flexibility attached to the
issuance of a BPO is the ease with which a due date
may be amended so as to either bring forward or delay
the execution of the payment.
Going back to the example of approved payables
finance, another way for the Seller’s Bank/Recipient

Bank to potentially finance the seller would be by

bringing forward the due date of the BPO. This would
force the Obligor Bank to pay early so that the Seller’s
Bank/Recipient Bank could finance the seller using
funds that it has already received from the Obligor Bank.
This is somewhat similar to a bank loan arrangement
and may be associated with some form of risk/revenue
TABLE OF CONTENTS
sharing between banks.

In order to bring forward or postpone a due date there
needs to be an amendment to the Baseline (see Figures
51 and 52). By pushing back the due date of a BPO the
Buyer’s Bank is delivering extended credit to the buyer.
Buyer Seller
3
TMA 1
Amendment Baseline
Acceptance Amendment
2 Request
Full Push (bring
Through 4 forward due
Report Amendment date)
Acceptance
Notification
5 Baseline Report
Buyer’s Bank/ (Due date brought Seller’s Bank/
forward)
INDEX
Figure 51: The Recipient Bank may request a Baseline Amendment to

bring forward the due date.
Buyer Seller
TMA 2
1
Full Push
Baseline
Through
Amendment 3
Report
Request Amendment
(push back 4 Acceptance
due date) Amendment
Acceptance
Notification
5 Baseline Report
(Due date pushed back)
Figure 52: The Obligor Bank may request a Baseline Amendment to push
back the due date.

8.4 BPO CASE STUDIES

Although a growing number of financial institutions have
declared themselves operationally ready, it is fair to say
that, to date, the number of banks and corporates that
have used a BPO in a live environment is quite limited.
Banks leading the way have mostly been Asian-based
TABLE OF CONTENTS
and include the Bank of Tokyo-Mitsubishi UFJ, the Bank

of China, Siam Commercial Bank and Standard
Chartered Bank. Only a small number of corporate
adopters have been identified in the public domain. The
best-known examples include BP Chemicals and Ito-
Yokado.
One of the factors that has to some extent constrained
market adoption is the absence of an industry-owned
rulebook. At its Spring Banking Commission meetings
held in Lisbon (Portugal) on 16-17 April 2013, the ICC
voted 100% in favour of the adoption of the URBPO.
It is widely anticipated that ICC ownership of the rules
will prove to be a natural turning point and a catalyst
that will accelerate market demand for BPO-based
services.
8.4.1 BP Chemicals (Exporter)

Working with Standard Chartered Bank, BP Chemicals
and its Middle East counterparty, Octal Petrochemicals,
went live on the BPO in May 2012.
INDEX
With trade account receivables in the region of EUR 1.4

billion and more than 600 clients worldwide, BP
Chemicals was actively seeking a secure and cost-
effective means of collecting payment, avoiding some of
the high processing and confirmation costs commonly
associated with the use of letters of credit.
The flexibility surrounding the use of the BPO has
enabled BP and Octal to strengthen their strategic
relationship by dematerialising the trade flow
documentation. Owing to the delayed issuance of the
BPO, Octal is able to benefit from a reduced demand on
credit lines while BP is able to reduce costs as a result of
enhanced operational efficiencies.

8.4.2 Standard Chartered Bank

Standard Chartered Bank has a broad geographic
coverage capable of supporting BPO-based transactions
on a global scale. The bank has invested in BPO-based
solutions that can be adapted to meet specific client
needs in terms of credit protection, pre- and post-
shipment financing, risk mitigation and working capital
TABLE OF CONTENTS
management.
8.4.3 Ito-Yokado (Importer)

Working with the Bank of Tokyo-Mitsubishi UFJ, Ito-
Yokado also went live on the BPO in 2012.
Having experienced a decline in sales revenue in 2011,
Ito-Yokado was seeking to leverage the strengths of the
Seven and I Holdings Group in order to raise
competitiveness. Adoption of the BPO has enabled
Ito-Yokado to streamline its operations, enhancing
reconciliation processes and negotiating improved
terms. Inventory levels have been reduced by placing
smaller orders at higher frequency. Suppliers are able to
benefit from the ease of operation and an accelerated
cash conversion cycle, resulting in improved working
capital management.
8.4.4 Bank of Tokyo-Mitsubishi UFJ (BTMU)

BTMU has been one of the most active banks in
pioneering the BPO solution across Asia. Recognising
INDEX
the continued shift of business towards trading on open

account, BTMU has actively pursued the opportunity to
provide a new range of solutions to service the open
account market, providing increased process efficiency
and winning new business in new markets.

Chapter 9
Useful Links
9.1 Uniform Rules for Bank Payment Obligations

International Chamber of Commerce
www.iccwbo.org
9.2 Messaging Standards

ISO 20022
www.iso20022.org
9.3 Transaction Matching Application Service

SWIFT
www.swift.com
9.4 Industry Organisations

Asian Development Bank
www.adb.org
Association of International Credit and Trade Finance
Professionals
www.ictfworld.org
BAFT-IFSA
www.baft-ifsa.com
EBRD
www.ebrd.com
Factors Chain International
www.fci.nl
Finance, Credit and International Business Association
fcibglobal.com
Institute of International Banking Law and Practice
www.iiblp.org
International Factors Group
www.ifgroup.com
National Association of Credit Managers
www.nacm.org
Pan-Asian Alliance
www.paa.net
World Trade Organisation
www.wto.org

9.5 Software service providers

and technology platforms
ACI Worldwide
www.aciworldwide.com/en/Products-and-services
Ariba
www.ariba.com
TABLE OF CONTENTS
Asyx
www.asyx.com
Basware
www.basware.co.uk
Bolero
www.bolero.net
Bottomline Technologies
www.bottomline.co.uk
China Systems
www.chinasystems.com/solutions
CGI
www.cgi.com
CSI Banktrade
www.banktrade.com
Core Solutions
www.coresolutions.com
Corporate LinX
www.corporatelinx.com/home.html
Demica
INDEX
www.demica.com
Earthport
www.earthport.com
Electronic Shipping Solutions
www.essdocs.com
Fundtech
www.fundtech.com
Getronics
www.getronics.com
Global Trade Corporation
www.globaltradecorp.com
Gresham
www.gresham-computing.com
GTNexus
www.gtnexus.com
GXS
www.gxs.com

Useful Links
Misys
www.misys.com
NTT Data
www.nttdata.com
OB10
www.ob10.com
TABLE OF CONTENTS
Orbian
www.orbian.com
Pinnacle Solutions
www.pinnaclesolutions.com
Polaris
www.polarisft.com
Premium Technology
www.premiumit.com
PrimeRevenue
primerevenue.com
Quadrem
www.ariba.com/programs/quadrem
Siscom
www.siscom.com.sa
SmartStream Technologies
www.smartstream.com
Sopra Group
www.sopragroup.co.uk
Sterling Commerce
INDEX
www-01.ibm.com/software/uk/commerce/sterling-
commerce
Sungard
www.sungard.com
Surecomp
www.surecomp.com
Syncada
www.syncada.com
Taulia
www.taulia.com/en/solutions
Temenos
www.temenos.com
The Receivables Exchange
www.receivablesxchange.com
Tieto Enator
www.tieto.com
Tradebeam
www.tradebeam.com

Tradecard
www.tradecard.com
Tradevan
www.tradevan.com.tw
Volante
www.volantetech.com
TABLE OF CONTENTS
9.6 Business consultancy and business intelligence

Aberdeen Group
www.aberdeen.com
Acarate
www.acarate.com
Aite Group
www.aitegroup.com/Reports
Capco
www.capco.com
Cap Gemini
www.capgemini.com
Celent
www.celent.com
Collyer Consulting
www.collyerconsulting.com
Deloitte
www.deloitte.com
Gartner
INDEX
www.gartner.com/technology
Global Business Intelligence
www.globalbanking.com
Hennah FSC Advisory
www.hennahfscadvisory.co.uk
KPMG
www.kpmg.com
Oliver Wyman
www.oliverwyman.com
Opus Advisory
www.opus-advisory.com
PriceWaterhouse
www.pwc.com
Trade Finance Associates
www.tradefinanceassociates.com
Tradewiz
www.tradewiz.net

Useful Links
TradeLC Advisory
www.davidmeynell.com
Vanasse & Associés
www.vanasse-associes.com
Xalles
www.xalles.com
TABLE OF CONTENTS
9.7 Banks
Afrasiabank
www.afrasiabank.com
ANZ
www.anz.com
Banco do Brasil
www.bb.com.br
Banco Itau BBA
www.itau.com
Bangkok Bank
www.bangkokbank.com
Bank al Etihad
www.bankaletihad.com
Bank of China
www.boc.cn/en
Bank of Communications
www.bankcomm.com
Bank of Montreal
INDEX
www.bmo.com
Barclays
www.barclayscorporate.com
BNP Paribas
www.bnpparibas.com/en
BTMU
www.bk.mufg.jp/global
Byblos Bank
www.byblosbank.com
China Citic Bank
www.cncbinternational.com/home/en/index.jsp
China Minsheng Banking Corp
www.cmbc.com.cn/index_en.shtml
Citigroup
www.citigroup.com/transactionservices
Commercial Bank of Dubai
www.cbd.ae

Commerzbank
www.commerzbank.com
Deutsche Bank
www.db.com/en/content/company/global_
transaction_banking.htm
FIMBank
TABLE OF CONTENTS
www.fimbank.com
First National Bank
www.fnb.co.za
Handelsbanken
www.handelsbanken.com
HSBC
www.business.hsbc.co.uk/1/2/international-business
Hua Nan Bank
www.hncb.com.tw/eng
ING
www.ing.com
JPMorgan
www.jpmorgan.com
Kasikornbank
www.kasikornbank.com/EN
Korea Exchange Bank
www.keb.co.kr/main/en
La Caixa
www.lacaixa.com/index_en.html
INDEX
Maybank
www.maybank.com/en/index.page
National Bank of Greece
www.nbg.gr
Nova Llubljanska Banka
www.nlb.si
Rabobank
www.rabobank.com/en/group/index.html
Qatar National Bank
www.qnb.com.qa
SEB
www.sebgroup.com
Siam Commercial Bank
www.scb.co.th/en/home
SMBC
www.smbcgroup.com
Société Générale
www.societegenerale.com/en

Useful Links
Standard Bank of South Africa

www.standardbank.co.za
Standard Chartered
www.standardchartered.com
Swedbank
www.swedbank.com
TABLE OF CONTENTS
The Royal Bank of Scotland

www.rbs.co.uk/corporate/finance.ashx
Unicredit
www.unicreditgroup.eu
UBS
www.ubs.com
9.8 Education and Media

Banking Technology
www.bankingtech.com
BCR Publishing
www.bcrpub.co.uk
Bobs Guide
www.bobsguide.com
Cash & Trade
www.cashandtrademagazine.com
Coastline Solutions
www.coastlinesolutions.com
Corporate Treasurer
INDEX
www.thecorporatetreasurer.com
Euromoney
www.euromoney.com
Exporta Group
www.exportagroup.com
FX-MM
www.fx-mm.com
Global Finance
www.gfmag.com
Global Trade Review
www.gtreview.com
GTNews
www.gtnews.com
IBS Intelligence
www.ibsintelligence.com
LinkedIn
www.linkedin.com/home

Slide share
www.slideshare.net
The Asian Banker
www.theasianbanker.com
The Banker
www.thebanker.com
TABLE OF CONTENTS
The Benche
www.thebenche.com
TFR
www.tfreview.com/news
Trade Finance
www.tradefinancemagazine.com
Treasury Today
www.treasurytoday.com/magazine
INDEX

Index
A C
Applicable Law 61, 98, 99, 100 Cash Conversion Cycle 29
Approved Payables Finance 34, Customer Relationship
36, 147, 149, 167, 168 Management 26
B D
BAFT-IFSA 148, 149, 150, 153, 155, 158, Data Match 58, 73, 76, 80, 92, 97, 99,
160, 162, 163, 164, 166, 168, 172, 173 102, 116, 117, 126
Bank Payment Obligation (BPO) Data Mismatch 30, 40, 67, 68, 69, 76,
Accounting Policy 38, 39 80, 92, 93, 95, 99, 102, 105, 106, 119,
Assignment 100 120, 123, 124, 148
Capital Treatment 40, 41 Data Set Submission 37, 38, 44, 47,
Case Studies 175 53, 63, 67, 80, 81, 84, 89, 93, 103, 116,
Confirmation 75 117, 118, 121, 122, 124, 156, 157, 161, 165, 166
Definitions 24, 80, 102
Due Date 35
Establishment 36, 61, 63
E
Expiry Date 59, 60, 61, 89, 116, 126 eUCP 64, 73, 74, 75, 78, 79, 80, 88
Intellectual Property 82
E-invoicing 26, 32
Payment Terms 59, 60, 61, 62, 145
Baseline
Amendment 36, 46, 53, 58, 66, 68, F
69, 84, 95, 96, 110, 111, 112, 114, 128, 157 Factoring 26, 147
Amendment Acceptance 45, 84,
Force majeure 90, 97, 98, 126, 146
92, 96, 110, 111, 112, 113, 119, 170
Amendment Rejection 84, 111, Full Push Through Report 48, 66,
114, 115, 170 84, 95, 102, 103, 104, 105, 106, 108, 110,
Definitions 24, 80, 102 134, 151, 152
Establishment 24, 34, 40, 53, 66,
67, 81, 83, 90, 93, 94, 95, 100, 101,
102, 103, 106, 128, 147, 151

I O
Initial Baseline Submission 24, 38, Obligor Bank 23, 29, 33, 35, 36, 37,
53, 57, 58, 62, 101, 102, 104, 105, 107, 134, 38, 40, 61, 62, 66, 67, 68, 69, 78, 79, 81,
135, 150, 151, 162 83, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99,
Intent To Pay 50, 51, 129 100, 102, 104, 105, 106, 107, 108, 110, 111,
116, 118, 119, 120, 123, 124, 125, 126, 140,
TABLE OF CONTENTS
International Chamber of
141, 151, 152, 154, 155, 156, 157, 158, 159,
Commerce (ICC) 73, 76, 77, 80,
160, 163, 166, 167, 168, 171, 172, 174
82, 86, 87, 94, 96, 97, 142, 143, 144
Open Account 26, 27, 28, 73, 74, 75,
International Organization for
144, 148, 149, 150, 153, 162
Standardization (ISO)
ISO 20022 32, 42, 43, 72, 77, 82
ISO 20022 TSMT 25, 42, 44, 55, P
56, 64, 72, 74, 75, 77, 78, 79, 80, 82,
Payment Assurance 23, 27, 29, 31,
83, 86, 99, 104, 118, 128, 141, 161
148, 153, 156
International Sale Contract 140,
Payment Obligation Segment 38,
142, 143, 144
58, 78, 79, 81, 92, 102, 103, 117
Post-shipment finance 34, 36, 37,
K 149, 166
KYC 31, 34, 76, 99 Pre-shipment finance 31, 34, 149,
163, 167
L Process Efficiency 26, 29, 30, 31
Letter of Credit 23, 25, 26, 27, 28, 30,

33, 38, 72, 73, 75, 77, 79, 118, 144, 147,
R
148 Recipient Bank 23, 25, 29, 34, 35, 36,
INDEX
38, 61, 79, 81, 83, 93, 95, 100, 102, 105,
M 107, 117, 123, 124, 140, 141, 151, 152, 153,
154, 158, 159, 160, 161, 163, 164, 165, 166,
Message Matching Rules 64, 65 167, 168, 171, 172, 173, 174
Mismatch Acceptance 48, 67, 85, Reverse Factoring 26, 147, 168
92, 93, 97, 98, 111, 119, 120, 121, 126, 155,
Risk Mitigation 23, 26, 27, 29, 31, 148
156
Risk Participation 70
Mismatch Rejection 48, 67, 85, 122,
123, 156 Role and Baseline
Acceptance 52, 53, 67, 69, 85, 92,
93, 95, 96, 106, 107, 108, 110, 113, 119,
120, 122, 124, 152, 156, 157
Role and Baseline Rejection 52,
53, 67, 85, 96, 108, 109, 111, 115, 125, 157

Index
S W
Silent BPOs 33, 34 Working Capital 27, 29, 30, 31, 79,
South-South trade 27 149
Special Messages 51, 54, 70, 85, 97, World Trade Organisation 25

126
TABLE OF CONTENTS
Status Change 49, 54, 58, 68, 109, 117 Z

Submitting Bank 66, 67, 69, 81, 82, Zero Mismatches 63, 82, 102, 103,
83, 85, 90, 95, 96, 97, 98, 102, 103, 106, 104, 105, 106, 107, 117, 119, 123, 153, 154,
107, 110, 126 162, 169, 170
Supplier Default 31
Transaction Matching
Application (TMA)
Data Sets 58, 59, 60, 80
Messages 53, 54
Pre-match 37, 66, 118, 169, 170
Reporting 54, 71
Roles 57
Subscription 56
Transaction Identifier 63
Transaction States 57
Unavailability 98
U
UCP 64, 72, 73, 74, 75, 76, 79, 80, 87, 88,
89, 90, 91, 96, 97, 100
INDEX
Uniform Rules for Bank Payment

Obligations (URBPO) 24, 42, 44,
45, 55, 64, 65, 72, 73, 74, 76, 77, 78, 79,
80, 82, 83, 86, 87, 88, 102, 108, 128, 140,
145
Universal Time Co-ordinated
(UTC) 82, 83, 89
V
Value Proposition 26, 27

ICC Tools
for Trade Finance
URBPO — online training

Four hours of structured e-training in all aspects
of the URBPO from the basic concepts through
to a detailed analysis of the rules.
Book now online www.iccwbo.org/onlinetraining
ICC Uniform Rules for Forfaiting — URF 800

Including Model Agreements
Created by the ICC Banking Commission
and the International Forfaiting Association (IFA)
ICC Pub. No. 800E, €25
ICC’s URF provide a standard set of forfaiting
rules that reflect a broad consensus among
bankers, users and all members of the forfaiting
community worldwide. Created by experts for
experts, ICC URF is a must-have for anyone
involved in international trade finance transactions.
ICC Uniform Rules for Demand Guarantees

— URDG 758
Officially endorsed by UNCITRAL, this edition
provides a clear layout of the examination process
for demands, a step-by-step roadmap for
handling extend or pay demands, a checklist
of drafting recommendations and more.
Guide to ICC Uniform Rules for Demand

Guide to
ICC
Uniform
Guide to ICC
Uniform Rules
Guarantees (URDG 758)
for Demand
by Dr. Georges Affaki, Sir Roy Goode
Rules for
Demand
Guarantees
URDG 758 Guarantees
URDG 758
ICC Pub. No. 702E, €149
Georges Affaki Dr. Georges Affaki
This Guide is a vital tool to help you efficiently use

Roy Goode
Professor Sir Roy Goode QC
ICC’s Uniform Rules for Demand Guarantees

(URDG 758) - indispensable for issuers and users
The world business organization
of guarantees and their advisors.

International Standard Banking Practice
(ISBP)
For the Examination of Documents under UCP 600
International Standard Banking Practice - ISBP
2013 is the most up to date, comprehensive guide
to handling and examining trade documents
under documentary credits. An invaluable source
of practical information for trade finance
professionals and academics!
Collected DOCDEX Decisions

2009 - 2012
Decisions by ICC experts on documentary credits,
collections and demand guarantees
The DOCDEX Decisions collections complement
the ICC Banking Commission Opinions. Together,
they are indispensable aids to practitioners
seeking to understand how ICC’s trade finance
rules are applied in daily practice.
DCInsight — The Trade Finance Quarterly

of the International Chamber of Commerce
Electronic and multiple user subscriptions available.
Contact [email protected] for more information.
DCInsight is the world’s most authoritative
newsletter on trade finance that brings you frank
and insightful interviews with L/C experts, official
ICC Banking Commission Opinions, in-depth
analyses of the ICC banking rules and standards,
fraud alerts and more.
Order now at www.iccbooks.com

ICC at a glance
International Chamber of Commerce (ICC) is the world business
organization, a representative body that speaks with authority on
behalf of enterprises from all sectors in every part of the world.
The fundamental mission of ICC is to promote open international
trade and investment and help business meet the challenges and
opportunities of globalization. Its conviction that trade is a
powerful force for peace and prosperity dates from the
organization’s origins early in the 20th century. The small group of
far-sighted business leaders who founded ICC called themselves
“the merchants of peace”.
ICC has three main activities: rule setting, dispute resolution, and
policy advocacy. Because its member companies and associations
are themselves engaged in international business, ICC has
unrivalled authority in making rules that govern the conduct of
business across borders. Although these rules are voluntary, they
are observed in countless thousands of transactions every day and
have become part of the fabric of international trade.
ICC also provides essential services, foremost among them the ICC
International Court of Arbitration, the world’s leading arbitral
institution. Another service is the World Chambers Federation,
ICC’s worldwide network of chambers of commerce, fostering
interaction and exchange of chamber best practice. ICC also offers
specialized training and seminars and is an industry-leading
publisher of practical and educational reference tools for
international business, banking and arbitration.
Business leaders and experts drawn from the ICC membership
establish the business stance on broad issues of trade and
investment policy as well as on relevant technical subjects. These
include anti-corruption, banking, the digital economy, marketing
ethics, environment and energy, competition policy and
intellectual property, among others.
ICC works closely with the United Nations, the World Trade
Organization and intergovernmental forums including the G20.
ICC was founded in 1919. Today its global network comprises over
6 million companies, chambers of commerce and business
associations in more than 130 countries. National committees work
with ICC members in their countries to address their concerns and
convey to their governments the business views formulated by ICC.

ICC Banking Commission
at a glance
The world’s essential rule-making body for the banking industry
With 80 years of experience and more than 600 members
in +100 countries, the ICC Banking Commission — the largest
commission of ICC, the World Business Organisation — has rightly
gained a reputation as the most authoritative voice in the field
of trade finance.
Rules
ICC Banking Commission produces universally accepted rules and
guidelines for international banking practice. ICC rules on
documentary credits, UCP 600, are the most successful privately
drafted rules for trade ever developed, serving as the basis of
USD2 trillion trade transactions a year.
Policy-making
ICC Banking Commission is helping policy makers and standard
setters to translate their vision into concrete programmes and
regulations to enhance business practices throughout the world.
Publications and market intelligence
Used by banking professionals and trade finance experts
worldwide, ICC Banking Commission publications and market
intelligence is the industry’s most reputable and reliable source of
guidance to bankers and practitioners in a broad range of fields.
Dispute resolution
The ICC Banking Commission and ICC International Centre for
Expertise administer the ICC Rules for Documentary Instruments
Dispute Resolution Expertise (DOCDEX) to facilitate the rapid
settlement of disputes arising in banking.
Education and certification
Over ten thousand people in over 100 countries have trained and
been certified in international trade finance using our suite of ICC
approved online training services and certification facilities.
Specialized training and events
In addition to its bi-annual summit gathering +300 international
delegates every six months, the ICC Banking Commission
organizes regular seminars and conferences around the world, in
partnerships with ICC National Committees and other sponsors.
Strategic partnerships
Well-established collaboration with leading policy makers and
trade association, including WTO (World Trade Organization), ADB
(Asian Development Bank), Berne Union, EBRD (European Bank
for Reconstruction and Development), IDB (Inter-American
Development Bank), IFC (International Finance Corporation), IMF
(International Monetary Fund), SWIFT, the World Bank and others.

THE ICC GUIDE
Bank Payment Obligations (BPOs) enable banks to mitigate the risks associated
with international trade to the benefit of both buyers and sellers. They enable
flexible financing propositions across the entire transaction lifecycle, including
pre-shipment, post-shipment and buyer finance.
ICC drafted the first-ever Uniform Rules for Bank Payment Obligations (URBPO),
a 21st century standard in supply chain finance that governs BPO transactions
worldwide and facilitates international trade. The rules were developed by
the Banking Commission of the International Chamber of Commerce (ICC),
in partnership with financial messaging provider SWIFT to take into account
the legitimate expectations of all relevant sectors.
The ICC Guide to the Uniform Rules for Bank Payment Obligations closely
examines the ways in which the three critical components of standards,
platform and rules must interact and complement one another in order
to facilitate the successful completion of a BPO transaction.
It explains workflow in detail and provides examples of how a Bank Payment

Obligation may be applied in practice to support a variety of customer value
propositions, enabling corporates to take full advantage of a host of bank-
assisted open account solutions designed to optimise the management
of the cash conversion cycle and of working capital.
This manual is designed not only to guide practitioners in their interpretation

of the Uniform Rules for Bank Payment Obligations but also to provide
substance to the practical application of the BPO in the context of real life
business scenarios. It is a vital reference for anyone involved in financial
supply chain transactions and for students of international commerce.
ICC Publication: 751E

ISBN: 978-92-842-0191-4
ICC Business Bookstore
www.iccbooks.com

751E - Guide To URBPO - EBOOK

Uploaded by

Copyright:

Available Formats

751E - Guide To URBPO - EBOOK

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

751E - Guide To URBPO - EBOOK

Uploaded by

Copyright:

Available Formats

THE ICC GUIDE

to the Uniform Rules for

INTERNATIONAL CHAMBER OF COMMERCE (ICC) | 3

David Hennah is an Associate of the Institute of Financial

4 | INTERNATIONAL CHAMBER OF COMMERCE (ICC)

The trade finance industry has often been subject to

INTERNATIONAL CHAMBER OF COMMERCE (ICC) | 5

6 | INTERNATIONAL CHAMBER OF COMMERCE (ICC)

I would elect to be a trader of goods

rather than a student of science.

INTERNATIONAL CHAMBER OF COMMERCE (ICC) | 7

The letter of credit is a creation of commerce. There are

8 | INTERNATIONAL CHAMBER OF COMMERCE (ICC)

INTERNATIONAL CHAMBER OF COMMERCE (ICC) | 9

10 | INTERNATIONAL CHAMBER OF COMMERCE (ICC)

LIST OF FIGURES.. . . ...................................................................................... 16

LIST OF TABLES. . . . . ...................................................................................... 20

LIST OF FLOW DIAGRAMS.......................................................................... 21

1.2 Why do we need a BPO?............................................................... 25

1.3 Addressing inefficiencies in the financial supply chain........... 27

1.4 Optimisation of working capital................................................... 29

1.5 Payment assurance.. ........................................................................ 29

1.6 Enhanced process efficiency.. ....................................................... 30

1.7 Reduced risk of discrepancies...................................................... 30

1.8 Mitigating the risk of supplier default.. ........................................ 31

1.9 Strengthening buyer/supplier relationships.............................. 31

1.10 Growing the supplier network...................................................... 31

1.11 Integrated technology based on global

1.13 “Silent” BPOs. . ................................................................................... 33

1.14 Summary of the main financing opportunities

INTERNATIONAL CHAMBER OF COMMERCE (ICC) | 11

2.2 What is ISO 20022?......................................................................... 43

2.3 What is ISO 20022 TSMT?.. ............................................................ 44

2.4 The ISO 20022 TSMT messages................................................... 44

3.2 TMA Roles.. . . . . .................................................................................... 57

3.3 TMA Transaction States. . ................................................................ 57

3.4 TMA Data Sets. . ................................................................................ 58

3.5 TMA Minimum fields. . ...................................................................... 59

3.6 TMA Establishment of a BPO. . ...................................................... 61

3.7 TMA Data and Message Matching Rules.................................... 64

3.8 TMA Pre-Match. . ............................................................................... 66

3.9 TMA Baseline Amendments.......................................................... 66

3.10 TMA Mismatch Acceptance and Rejection................................ 67

3.11 TMA Single shipments and partial shipments........................... 68

3.12 TMA Multiple Obligor Banks. . ........................................................ 68

3.13 TMA Special Messages................................................................... 70

3.14 TMA Reporting................................................................................. 71

3.15 TMA Data Storage........................................................................... 71

3.16 TMA Timers and Time Violations. . ................................................ 71

12 | INTERNATIONAL CHAMBER OF COMMERCE (ICC)

4.2 Key differences between the URBPO

5.2 Baseline Amendment Request................................................... 110

INTERNATIONAL CHAMBER OF COMMERCE (ICC) | 13

5.4 Data Set Pre-Match....................................................................... 118

5.5 Mismatch Acceptance.. ................................................................. 119

5.6 Mismatch Rejection....................................................................... 122

5.7 Special Messages........................................................................... 126

6.2 Differences in scope...................................................................... 134

6.3 End-to-end message flows.......................................................... 135