BPO Draft 2_Mexico - International Chamber of Commerce
Download
Report
Transcript BPO Draft 2_Mexico - International Chamber of Commerce
Bank Payment Obligation
URBPO Draft 2
URBPO Drafting Group
ICC Banking Commission November 2012
Mexico City
1
Agenda
Uniform Rules for Bank
Payment Obligations (URBPO)
• Background and Status
• Key Points
• URBPO Articles
• Next Steps
2
Background and Status
•
•
•
•
June 2012: Release of Draft 1 and guidance notes to ICC National Committees
July 2012: Detailed comments received from 21 National Committees
August 2012: Comments from Consulting Group
September 2012: Release of Draft 2 to ICC National Committees
•
As these rules cover a new concept in trade finance, guidance notes are again a
key feature of draft 2 and have been updated to reflect the changes made to the
text of the articles; changes in the order of the sub-articles; and to provide further
information in response to comments made by National Committees
•
Additionally, the BPO Educational Group provided various documents that will aid
in review of the draft text and further understanding of the BPO product
3
Agenda
Uniform Rules for Bank
Payment Obligations (URBPO)
• Background and Status
• Key Points
• URBPO Articles
• Next Steps
4
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 UCP, a collection under URC and a guarantee
under URDG, the actual settlement of a BPO is outside the scope of the URBPO.
The URBPO exist in the bank-to-bank space. The rules do not cover the
interaction between a bank and their corporate client. The interaction between the
banks is to be seen to be within a collaborative space where the banks use a
common transaction matching application (data matching engine) for a data match
to occur and for this purpose the rules offer clear guidelines.
The bank to corporate space is seen to be within a competitive space, one in
which the banks are able to differentiate themselves from each other by way of the
products and services that they offer based on the strength of a BPO being issued.
5
Agenda
Uniform Rules for Bank
Payment Obligations (URBPO)
• Background and Status
• Key Points
• URBPO Articles
• Next Steps
6
URBPO – draft 2
Article 1 Scope
Article 10 Undertaking of an Obligor Bank
Article 2 Application
Article 11 Amendments
Article 3 General Definitions
Article 12 Charges
Article 4 Message Definitions
Article 13 Disclaimer on Effectiveness of Data
Article 5 Interpretations
Article 14 Force Majeure
Article 6 Bank Payment Obligations (BPO) vs. Contracts
Article 15 Unavailability of a Transaction Matching Application
Article 7 Data v. Documents, Goods, Services or Performance
Article 16 Applicable Law
Article 8 Expiry Date and Submission
Article 17 Assignment and Transfer
Article 9 Role of an Involved Bank
7
National Committee Feedback
•
Significant reduction in quantity of comments – good sign
–
•
•
•
•
•
Proves the value of Educational material ... which should now be intensified
19 pages of comments from 22 countries
Consolidated comments only received on 1st November so further in-depth review
required
Where comments have been provided on Guidance Notes, these will be
considered for Draft 3
Formatting / grammatical changes will be reviewed and accommodated where
relevant
Every comment received will be reviewed and considered
8
General Comments
Request for article indicating that criteria for Data Match / Mismatch covered by a TMA
rulebook and not URBPO.
As it is mandatory to use a TMA it seems more appropriate to use the term “the TMA” rather
than “a TMA”.
Is it intended that ‘Guidance Notes’ notes be included in final publication?
9
Article 1: Scope
The ICC Uniform Rules for Bank Payment Obligations (URBPO) provide a framework for
Bank Payment Obligations (BPO). A BPO relates to an underlying trade transaction between
a buyer and seller with respect to which Involved Banks have agreed to participate in the
establishment of a Baseline through the use of the same Transaction Matching Application.
Comments
Certain ‘Guidance Notes’ essential to understand the context of the rules which suggests
that the rules may lack clarity in places. Rules written in more of a legal context than
operational.
10
Article 2: Application
a.
The URBPO are rules that apply to a BPO issued by an Obligor Bank to a Recipient Bank
where the Established Baseline expressly states that it is subject to these rules or where
each Involved Bank agrees that the Established Baseline is subject to these rules. They
are binding on each Involved Bank unless expressly modified or excluded. This is
Version 1.0 of the URBPO.
b.
If an Established Baseline does not indicate the applicable version of URBPO, it is
subject to the version in effect on the date and at the time of the Established Baseline.
c.
The URBPO require use of the appropriate ISO 20022 Trade Services Management
messages (TSMT) registered with the ISO. Use of any other message type means that
the transaction is out of scope of these rules.
11
Article 2: Comments
Rules intended to be technology-neutral, so logically also ‘standards’ neutral. Suggest
avoiding restriction to TSMT messages: i) need for synchronisation to ensure that at all
times URBPO reflect current ISO standard; ii) reference to specific message standards
represents a departure from normal ICC rules procedure
12
Article 3: General Definitions
Guidance Notes
•
•
•
•
•
•
Similar to all recent revisions of ICC rules, the URBPO include a list of defined terms for the roles of the various
banks and other key terms used in the rules. In order to differentiate these rules from other ICC rules,
terminology that is often associated with those rules i.e., issuing bank, advising bank, confirming bank, etc.
have not been used. New terminology has been introduced. The TMA will be the solution that is chosen by the
respective banks for the matching of data relating to trade transactions. This could be the SWIFT TSU offering
or any other proprietary solution. In response to a specific comment from a national committee, it is confirmed
that the term “Bank Payment Obligation” is not subject to any intellectual property right restrictions and does
not require that SWIFT be the teletransmission service provider.
The reference to UTC may not be recognised by everyone, but this is the time standard used for many internet
and World Wide Web standards. In effect, it is the network time protocol designed to synchronise the clocks of
computers over the Internet. The definition of UTC and others within this article have been expanded to make
their understanding and application easier. Following a request from a few national committees, a definition of
Zero Mismatches has been added.
In respect of the definition of Data Set, the reference to ‘commercial, transport, insurance, certificate and any
other data’ follow the message protocols that exist within the ISO standards.
It has been questioned as to whether the Recipient Bank could be a bank other than the Seller’s Bank. Under
the current ISO standards, the Recipient Bank is always the Seller’s Bank.
A comment was made that an Obligor Bank should not accept any other bank to submit data instead of the
Recipient Bank. Questions were also raised as to the responsibility of a Submitting Bank and their failure to
input data correctly. No change has been made as this is an issue for the Involved Banks to decide upon and
not the rules.
In response to comments from national committees, Transaction Matching Application has been shortened to
TMA throughout the rules.
13
Article 3: Comments...
Separate URBPO from underlying message standards. Include further definitions such as
buyer / seller.
Needs a Guidance Note explanation of where an Obligor Bank may be different to the
Buyer’s Bank.
Is this statement correct? How is this affected by article 17: this implies to a bank other than
Recipient Bank.
Are the words ‘Bank Payment Obligation’ covered by copyright?
14
Article 4: Message Definitions
Guidance Notes
•
All the message titles are as shown in the ISO 20022 TSMT message definitions. This is the
complete list of those messages that will apply to a BPO and will only be changed or updated if
ISO make any changes to their own definitions.
•
It has been suggested that the list should be in process order as opposed to alphabetical order.
National committees have been requested in the cover note to this draft to indicate their
preference.
15
Article 4: Comments ...
Alphabetical order or process order?
The point was raised that if the Submitting Bank can only withdraw in the event of “force
majeure” occurring, it might be useful to state this in Article 11(g).
In the event of force majeure such as failure of communications, how should Submitting
Bank send the special request message? What’s the deadline for Submitting Bank to notify
the involved bank?
If these definitions will automatically change when ISO makes changes it must be stated as
a rule and incorporate an effective date. This ought to be stated as a rule. Should also have
a Guidance Note discussing this. How will the ISO changes / updates take effect?
16
Article 5: Interpretations
Branches of an Involved Bank, whether in the same or a different country, are considered
different banks.
Comments:
Branches of a bank in the same country cannot be considered a different bank. Legal,
regulatory and compliance issues. What is the background, please clarify. Should be in line
with UCP600.
17
Article 6: Bank Payment Obligations (BPO) vs. Contracts
a.
A BPO is separate and independent from a sale or other contract on which it 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 any Established Baseline. Consequently,
the undertaking of an Obligor Bank is not subject to claims or defences by the buyer
resulting from its relationship with any Involved Bank or the seller.
b.
A Recipient Bank can in no case avail itself of the contractual relationship existing
between the buyer and the Obligor Bank.
c.
Performance of an Obligor Bank’s obligations under a BPO is not conditional upon
receipt of funds from any other party or any condition linked to its relationship with the
buyer.
18
Article 7: Data vs. Documents, Goods, Services or Performance
An Involved Bank deals with data and not with documents, goods, services or performance
to which the data may relate.
Comments
Inclusion of "documents" here only supports our view that the product is designed as too
far distant from the underlying transaction.
19
Article 8: Expiry Date and Submission
a.
b.
c.
An Established Baseline must state an expiry date for the Submission of a Data Set
under a BPO. If an Established Baseline contains more than one BPO, a separate expiry
date must be stated for each BPO.
A Data Set must be received by a TMA on or before 23:59:59 UTC on the expiry date.
Submission of a Data Set by an Involved Bank to a TMA represents a request for data
comparison.
Comments
Consequences if no expiry date mentioned? Suggest adding “An Established Baseline that
does not state an expiry date is [insert consequence].
What happens if someone attempts to send Data Set after deadline?
23.59.59 is the Obligor Bank timing or the Recipient Bank?
20
Article 9: Role of an Involved Bank
a.
In the event that a TSMT message is sent by a TMA and received by an Involved Bank on
a day that it is closed for reasons other than those referred to in article 14, such Involved
Bank will be deemed to have received the message on the first following Banking Day.
b.
If 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 is
unchanged from the data it has been instructed to submit.
d.
A Baseline will only become established after all Involved Banks have accepted their
roles.
i.
ii.
Where the Buyer’s Bank is the only Obligor Bank: the Baseline is established when a TMA issues a Baseline Match
Report with Zero Mismatches confirming that the Baseline submitted by a Buyer’s Bank matches the Baseline
submitted by a Recipient Bank.
Where there is an Obligor Bank other than the Buyer’s Bank: the Baseline is established when a TMA issues a Role
and Baseline Acceptance Notification confirming that such Obligor Bank has accepted its role as specified in the
Baseline Submission of both the Buyer’s Bank and the Recipient Bank.
21
Article 9: Comments
Comments
Since the submission is purely data – and the matching is done electronically, we are of the
opinion that the submission is received when it is received – regardless of whether or not
the bank is open or closed.
Meaning of / replace / parameters of ‘without delay’.
Implies there is no established Baseline in case any Obligor Bank is not willing to give a
BPO. In scenario with more than one Obligor Bank, the entire Established Baseline will be
void based on refusal of only one Obligor Bank.
What is the impact and the consequence of a TMA sending the message prior to the
agreement of the Obligor Bank?
22
Article 10: Undertaking of an Obligor Bank
Guidance Notes
•
•
•
•
•
•
•
•
The rules do not, as neither do any other ICC rules, invoke a timeline within which an Obligor Bank is required
to pay or to incur their deferred payment obligation following a Data Match.
This article has been the subject of a re-ordering of the sub-articles to reflect the proper flow in a transaction.
The Obligor Bank is bound as of the time the Baseline Match Report indicates the status of ‘Established’. (Subarticle 10 (a)).
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-articles 10 (c) and (e) now makes it clear that the payment under a BPO, including the timing for that
payment, is to be made in accordance with the instructions contained in the Established Baseline. A number of
comments from national committees requested a specific timeframe in which the payment was to be made
(where payable “at sight”) but the Baseline contains a field for the insertion of the payment details. It is these
details that should be followed by an Obligor Bank. 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 stated earlier, the discharging of the obligation is not covered by, nor is it within the boundaries of, the rules
and is to be made in accordance with the conditions expressed in the Established Baseline.
Sub-article 10 (f) outlines the basis under which an Obligor Bank could be relieved of its obligations under a
BPO.
Sub-article 10 (g) emphasises, as with other rules, any cancellation of an undertaking that has been given is
outside the scope of the rules. Sub-article 10 (h) is added for clarity to highlight that there is no obligation
where a Data Mismatch has occurred.
23
Article 10: Comments ...
New wording suggested to reflect that the crucial issue is that in the case there is a Data
Mismatch an Obligor Bank is only bound once a Mismatch Acceptance Notification has been
sent by the TMA.
A BPO is an irrevocable and independent undertaking of an Obligor Bank, thus the decision
of an Obligor Bank to continue its obligation by accepting a Data-Mismatch must not depend
on the decision of any other Obligor Bank.
Include a wording to allow for prepayment.
It is mentioned that the buyer’s bank can “reject” the submission – and thereby the obligor
bank is not obligated to pay. We believe this should be elaborated
upon; i.e. how to reject? When to reject? Further we fail to understand (given we read this as
is intended) that acts or no acts of the buyer’s bank can obligate the obligor bank.
24
Article 11: Amendments
Guidance Notes
•
The process of amendments is outlined in article 11, in particular who is required to agree to an
amendment to an Established Baseline (sub-article (a)).
•
Sub-articles 11 (c), (d) and (e) outline the basis for an amendment to be considered as effective
and sub-article (f) where the amendment is rejected.
•
If a Submitting Bank wishes to terminate its role, the process is outlined in sub-article 11 (g). It
should be noted that a Special Request message can only be sent in the event of force
majeure (see definition in article 4).
25
Article 11: Comments ...
Article 11 should refer to the amendment of BPO and not to the amendment of Established
Baseline only.
We do not understand why each Obligor Bank must receive a Full Push Through
Report when an amendment concerns only one BPO. This is not the normal way to amend
one undertaking such as a BPO.
26
Article 12: Charges
If an Established Baseline states that the charges of an Involved Bank are to be deducted
from a payment made under the BPO, and such charges cannot be collected or deducted
due to the absence of a Submission, the Obligor Bank remains liable for payment of those
charges.
Comments
Why should Obligor Bank be primarily liable for charges?
27
Article 13: 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; (ii) the documents, 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.
Comments
Following the language of Article 34 of UCP 600 too closely could result in an unexpected
result. The problem that arises in our view is that whereas Article 34 clearly refers to
documents, goods, services or performance of a third party, Article 13 of URBPO refers,
inter alia, to “ANY data”. Our concern is, therefore, that this may inadvertently include data
actually generated by an involved bank for which such bank is responsible.
28
Article 14: 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, 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 14 (a), an Obligor Bank will, upon
resumption of its business, remain liable to pay or to incur a deferred payment
obligation and pay at maturity the amount due to a Recipient Bank in respect of a BPO
that expired during such interruption of its business and for which there has been a
Submission of a Data Set on or before the expiry date of the BPO which resulted in a
Data Match or a Mismatch Acceptance pursuant to sub-article 10 (c).
29
Article 14: Comments
Re-draft as follows, “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, including a failure of equipment, software, or communications network, caused by
Acts of God, riots, civil commotions, insurrections, wars, acts of terrorisms, or by any
strikes or lockouts or any other causes beyond its Control.”
What happens to BPO which expires during interruption of services with no Data received?
The principle established here is contrary to the rules provided until now by the ICC, inter
alia contrary to the UCP (article 36, 2d alinea) and URDG (article 26), and contrary to what
decided courts in many jurisdictions and applicable laws. The principle here provided is
totally inacceptable.
Add at the end of the sentence “whether such Data Match or Mismatch Acceptance occurred
before or after the expiry date of the BPO.” To clarify that the critical time line is the
submission of data, not when the TMA runs the match test.
We felt that there may well be a greater risk to the Recipient Bank if the TMA is to be issued
by a bank using a proprietary TMA platform. It would not be appropriate to suggest these be
prohibited; however, the final URBPO notes may want to consider pointing out this risk to its
member banks.
30
Article 15: 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.
No comments received.
31
Article 16: Applicable Law
a.
Unless otherwise provided in the Established Baseline, the governing law of a BPO will
be that of the location of the Obligor Bank’s branch or office specified in the Established
Baseline.
b.
These rules supplement the applicable law to the extent that they do not conflict with
that law.
c.
An Obligor Bank is not required to comply with its obligations under a BPO if the
Obligor Bank would be restricted from doing so pursuant to applicable law or regulatory
requirements.
32
Article 16: Comments
Jurisdiction provision required.
Two comments, one requesting deletion with no reason given, and one stating that as a
matter of English law, the rules do not supplement the applicable law but are rules to be
applied under the applicable ( e.g. English) law.
Proposal to re-draft as follows: “In addition to its obligations under these rules, an Obligor
Bank is also required to comply with applicable law or regulatory requirements.” Counterproposal to delete as redundant / not a rule but a guidance.
33
Article 17: Assignment and Transfer
A Recipient Bank has the right to assign or otherwise transfer any claims or proceeds to
which it may be or may become entitled under a BPO, in accordance with the provisions of
applicable law. This article relates only to the assignment or transfer of claims or proceeds
and not to the transfer of the Recipient Bank role under the Established Baseline to another
bank (which requires amendment of the Established Baseline in accordance with article 11).
Comments
In line with UCP and URDG, suggest providing for separate provisions for assignment of
proceeds and transfer.
34
URBPO: Other comments
ICC Uniform Rules for Bank Payment Obligations should accurately state the duty and
function of the Recipient Bank.
Recommend seller to be beneficiary of the BPO.
If beneficiary remains Recipient Bank, suggest right of receivables from exporter to be
mentioned.
Obligor Bank undertake to pay seller.
Is it possible (for clarification purpose) including in these Rules that Data should be
submitted in the same language of the BPO unless stated otherwise.
35
Agenda
Uniform Rules for Bank
Payment Obligations (URBPO)
• Background and Status
• Key Points
• URBPO Articles
• Next Steps
36
Next Steps
•
30 October 2012: Deadline for Draft 2 comments from National Committees DONE
•
December 2012: Drafting Group will produce Draft 3
•
January 2013: Comments on Draft 3 from ICC National Committees
37