Bank Payment Obligation: il funzionamento operativo

BPO: i requisiti di base

Come già visto nell’articolo pubblicato sul numero 193 di Newsmercati, per utilizzare la BPO è necessario che il venditore e il compratore siano d’accordo nell’utilizzare tale strumento nell’ambito dell’accordo commerciale sottostante, definendo, ad esempio, i "Payment Terms" come segue: "Irrevocable Bank Payment Obligation  □ Settlement by Payment or □ Settlement by Deferred Payment Undertaking and payment at maturity. Deferred payment terms: x days after sight or after date of…). Date on which the Bank Payment Obligation must be notified to seller: x days before date of shipment/other…….".

Il compratore, inoltre, deve avere un accordo in essere con una banca disponibile ad agire come "Obligor Bank" e ad emettere una BPO. La banca del venditore e la banca del compratore devono, infine, supportare la gestione di una BPO per la ricezione e l’invio dei dati utilizzando la stessa Transaction Matching Application "TMA" (ad es. la SWIFT Trade Service Utility platform "TSU") e aderendo alla messaggistica ISO 20022 TSMT.

Proviamo ora a comprendere il funzionamento operativo di una BPO.

La messaggistica ISO 20022 TSMT

I messaggi ISO 20022 sono un set di standard sviluppato da ISO (International Organization for Standardization) per essere utilizzati dal sistema finanziario. Tali messaggi sono organizzati per area di business, ognuno dei quali identificato da 4 caratteri i quali, per il Trade Service Management, sono identificati dalla sigla "TSMT".

Lo standard ISO 20022 TSMT specifica:

• il formato dei "Data Sets" (Commercial/Transport/Insurance/Certificate/Other certificate) che le "Involved Banks" (le banche coinvolte in una operazione di BPO) inseriscono, in riferimento ad una operazione commerciale sottostante, nella TMA (Transaction Matching Application) e
• il formato dei relativi messaggi TSMT che vengono scambiati fra le "Involved Banks".

Attualmente, sono 50 i messaggi ISO 20022 TSMT ufficialmente registrati, di cui solo 19 sono definiti dalle URBPO ICC. Per visualizzarli clicca qui.

I messaggi ISO 20022 TSMT coprono le seguenti aree:

• The establishment of a transaction (Baseline)
• The matching of Data Sets
• The amendment of a transaction (Baseline)
• The acceptance/rejection of mismatches
• Reports on status and activity

I messaggi ISO 20022 pubblicati sul sito ISO, sono stati ideati esclusivamente per consentire lo scambio di dati e messaggi fra la TMA e le "Involved Banks". Ciò in quanto non sono previsti né messaggi né canali standard per supportare lo scambio di dati e messaggi fra le controparti commerciali e le rispettive banche, che possono comunicare secondo metodologie e strumenti condivisi. Alcune controparti potrebbero, comunque, decidere di utilizzare la messaggistica ISO 20022 TSMT per comunicare con le loro banche, utilizzando un subset adattato dei messaggi.

La Transaction Matching Application o TMA

Le banche interessate a sviluppare business utilizzando la BPO sono tenute ad aderire ad una stessa TMA (ad es. la SWIFT Trade Service Utility platform "TSU"). Solitamente l’adesione alla TMA è ristretta alle sole istituzioni finanziarie e sarà il gestore della TMA a definirne i relativi criteri di adesione. Si segnala che una TMA dovrà conservare tutti i messaggi inviati e ricevuti che potrebbero essere utilizzati come prove in caso di dispute.

I campi minimi richiesti per aprire una Baseline sono i seguenti:

• Transaction reference
• Purchase Order reference
• Buyer name and country
• Buyer’s Bank BIC
• Seller’s name and country
• Seller’s Bank BIC
• Goods: quantity and amount per line item 
• Payment terms
• Data Sets (Commercial/Transport/Insurance/Certificate/Other certificate)
• Submitting Bank BIC
• BPO (opzionale): Obligor Bank - Recipient Bank - Amount – Percentage – The charges percentage - Expiry date - Applicable Law – Payment Terms - Settlement Terms;
• Contact person (either Buyer’s Bank or Seller’s Bank)

Una "Established Baseline" dovrà anche segnalare se le spedizioni parziali sono consentite o proibite. Una volta che la "Baseline" è stata "established", la eventuale BPO, che può essere aggiunta "at any time", diventa operativa ed irrevocabile. Una "Established Baseline"può contenere più di una BPO.

In riferimento alla messaggistica ISO 20022 TSMT, ci sono 5 tipologie di "Data Sets" che possono essere inseriti in una TMA per la relativa comparazione nella "Baseline". Le tipologie sono le seguenti:

• Commercial, Dati estratti dalla fattura commerciale:
  o Transaction reference
  o Commercial Data Set Identifier
  o Invoice number and  Issue date
  o Purchase Order reference
  o Buyer name and country
  o Buyer’s Bank BIC
  o Seller’s name and country
  o Seller’s Bank BIC
  o Payment terms
  o Goods: quantity and amount per line items
  o Settlement terms: Identification of Creditor Account
   
• Transport, Dati estratti dal documento di trasporto
  o Transport Data Set Identifier
  o Consignor: name and country
  o Transport document reference and date of issue
  o Proposed or Actual Shipment Date
  o Transport: at least one Port of Origin and one Destination
  o Purchase Order reference
   
• Insurance, Dati estratti dalla polizza o dal certificato assicurativo
  o Insurance Data Set Identifier
  o Issuer of Insurance Policy: name and country
  o Issue date
  o Insurance document reference
  o Insured Amount
  o Assured party: BIC or name and address
  o Claims payable at
   
• Certificate, Dati estratti dai certificati
  o Certificate Data Set Identifier
  o Certificate identification
  o Certificate type
  o Certified characteristics
  o Issuer of certificate: name and country
  o Issue date 
   
• Other certificate, Dati estratti dai certificati
  o Certificate Data Set Identifier
  o Certificate identification
  o Certificate type
  o Issuer of certificate: name and country
  o Issue date

Per completezza, si segnala che è possibile utilizzare i dati estratti dai documenti per la relativa comparazione di più "Baseline".  I dati di una singola fattura, pertanto, potrebbero essere utilizzati per la relativa comparazione per più transazioni.

In alcune circostanze la banca del venditore potrebbe essere interessata, magari per chiedere l’emissione di una BPO in un momento successivo, a inserire i "Data Sets" per il relativo matching nella TMA, evitando che il relativo output sia visibile alla banca del compratore. Tale obiettivo può essere raggiunto inserendo i "Data Sets" in modalità "pre-match".  In tal caso, la TMA invierà un "Data  Match  Report" solo alla banca del venditore e lo status della transazione rimarrà invariato.

Pare opportuno segnalare che oltre alle ICC rules (URBPO) e agli standard ISO (ISO 20022 TSMT) esistono altre "rules" che si riferiscono a ogni TMA. Per esempio l’indicazione se un messaggio deve essere obbligatorio o opzionale, se un dato può essere inserito con un codice o con un testo, se un matching di dati deve essere "strictly" o "loosely":

• "Strictly" significa che il contenuto di un campo, carattere per carattere, deve corrispondere esattamente al dato richiesto;
• "Loosely" significa che i caratteri minuscoli o maiuscoli, gli spazi o la punteggiatura non saranno presi in considerazione per il matching dei dati e tutti i caratteri non alfabetici o numerici saranno considerati come punteggiatura.

BPO: Aprire una Baseline

Per aprire una Baseline, le banche del compratore e del venditore devono inviare una "Initial Baseline Submission" alla "TMA". Una "Initial Baseline Submission" conterrà i dati relativi alla transazione sottostante come indicati dal venditore e dal compratore e la compilazione della  "Payment Obligation Segment" per l’emissione della BPO.
Se, ad esempio, la banca del compratore inserisce la "Initial Baseline Submission" la TMA invierà un "Full Push Through Report" alla banca del venditore. Se quest’ultimo è d’accordo con i relativi contenuti, richiederà alla sua banca di riproporre la Baseline contenente il "Full Push Through Report" alla TMA. La TMA reinvierà il "Full Push Through Report"  alla banca del compratore. La TMA invierà poi la "Baseline Match Report" ad entrambe le banche indicando "zero mismatches."

Nell’ambito di una "Established Baseline" con BPO, possono verificarsi tre distinte situazioni:

1. la Buyer’s Bank è la sola Obligor Bank;
2. una Obligor Bank, diversa dalla Buyer’s Bank, è la sola Obligor Bank;
3. più di una Obligor Bank che può includere la Buyer’s Bank.

La modifica di una BPO

L’art. 11 della URBPO ICC riporta che solo la banca del compratore o la banca del venditore possono richiedere una modifica o accettare una richiesta di modifica di una "Established Baseline".  Qualsiasi proposta di modifica deve essere accettata integralmente o rifiutata. Non è possibile accettare parzialmente una "Baseline Amendment".

Inoltre se una "Baseline" in cui la Obligor Bank non è la Buyer’s Bank viene modificata, la TMA invierà alla Obligor Bank un "Full Push Through Report" e un "Delta Report". In questo caso, la Obligor Bank è tenuta a rispondere inviando o un "Role and Baseline Acceptance  message" o un "Role and Baseline Rejection message". In quest’ultimo caso, la Baseline rimane invariata e la banca del compratore e la banca del venditore possono o continuare a lavorare con la "Established Baseline" precedente o proporre ulteriori modifiche (per esempio chiedendo di modificare la Obligor Bank) oppure concordare la chiusura della transazione.

Fulfilling a BPO

Effettuata la spedizione delle merci, il venditore invierà i "Data Sets" richiesti alla Recipient Bank (o alla Submitting Bank scelta dalla Recipient), con modalità da condividere con la stessa. La Recipient Bank inserisce i dati nella TMA (sempre con messaggio TSMT) che provvederà a una comparazione automatica dei "Data Set Submission" contro la "Established Baseline" per determinare "a data match" o  "data mismatch".

Una "Established Baseline" deve definire una data di scadenza per l’inserimento dei  "Data Sets" e tutti i "Data Sets" richiesti da una "Established Baseline" devono essere ricevuti dalla "TMA" non più tardi delle 23:59:59 UTC/GMT della relativa data di scadenza della BPO.

Con un "data match" nasce l’impegno al pagamento della BPO in accordo con i termini di pagamento indicati  nella "Payment Obligation Segment" della "Baseline" e il venditore invierà i documenti originali al cliente.

Con un "data mismatch", la TMA invia una notifica a tutte le "Involved Bank". In tal caso la banca del compratore, può decidere se accettare o rifiutare i "Data Mismatch". Solitamente l’accettazione dei "Data Mismatch" si rileva dopo il confronto col compratore e la ricezione dell’accordo del compratore all’accettazione dei  "mismatches".  Se la Obligor Bank è una banca diversa dalla banca del compratore, "they will be required to separately agree to continue with their obligation should the Buyer’s Bank agree to the data mismatch acceptance of the buyer".

Data Match on Data Set Submission

Con il matching dei dati, la TMA invia un "Data Set Match Report" con "zero mismatches" alle "Involved Bank". Si possono rilevare  tre distinte situazioni:

• La banca del compratore è l’unica Obligor Bank, tale banca deve pagare a vista o assumere un impegno di pagamento differito secondo i termini riportati nel "Payment Obligation Segment" della "Established Baseline".
• La Obligor Bank è diversa dalla banca del compratore: la Obligor Bank, deve pagare a vista o assumere un impegno di pagamento differito secondo i termini riportati nel "Payment Obligation Segment" della "Established Baseline".
• Presenza di più di una Obligor Bank, che può includere la banca del compratore. Ciascuna Obligor Bank deve pagare a vista o assumere un impegno di pagamento differito secondo i termini riportati nel "Payment Obligation Segment" della "Established Baseline", in relazione al proprio impegno.
   

Data Mismatch on Data Set Submission

Con un "data mismatch" si possono rilevare tre distinte situazioni:

1a situazione: La banca del compratore è la sola Obligor Bank

Il Data Set Match Report segnala Data Mismatch. La banca del compratore, può decidere se accettare o rifiutare i “Data Mismatch”. Solitamente l’accettazione dei "Data Mismatch" si rileva dopo il confronto col compratore e la ricezione dell’accordo del compratore all’accettazione dei "mismatches". In caso contrario, la Recipient Bank (o la Submitting Bank) dovrebbero reinserire dati corretti (if that is the reason for the Data Mismatch).

Se la banca del compratore accetta i "Data Mismatch", invia un messaggio di "Mismatch Acceptance" alla TMA (che lo invia alla Recipient Bank) e la BPO è dovuta.

Se la banca del compratore decide di non accettare i "Data Mismatch" invia un "Mismatch Rejection"  alla TMA che lo notifica a tutte le "involved banks".

2a situazione:  Una Obligor Bank, diversa dalla banca del compratore, è la sola Obligor Bank

Il "Data Set Match Report" segnala "Data Mismatch". La banca del compratore, può decidere se accettare o rifiutare i "Data Mismatch". Solitamente l’accettazione dei "Data Mismatch" si rileva dopo il confronto col compratore e la ricezione dell’accordo del compratore all’accettazione dei "mismatches".  In caso contrario, la Recipient Bank (o la Submitting Bank) dovrebbero reinserire dati corretti (if that is the reason for the Data Mismatch.)

Se la banca del compratore decide di accettare i “Data Mismatch”, invierà un messaggio di “Mismatch Acceptance” alla TMA, che notificherà il messaggio a tutte le “involved banks”. In questo caso, la Obligor Bank potrà confermare il suo impegno a pagare la BPO in relazione ai termini stabiliti inviando un “Role and Baseline Acceptance” alla TMA che lo notificherà a tutte le “involved Banks”. La BPO è ora dovuta.

Se la banca del compratore accetta i "Data Mismatch" e la "Obligor Bank" decide di rifiutare i "Data Mismatch", la Obligor Bank invierà una messaggio di "Role and Baseline Rejection" alla TMA che lo notificherà a tutte le banche coinvolte.

In questo caso, la banca del compratore e la Recipient Bank devono decidere il da farsi. La banca del compratore potrebbe essere d’accordo nel pagare o assumere un impegno di pagamento a scadenza o le banche possono modificare la "Established Baseline" per eventualmente sostituire la Obligor Bank che sarà d’accordo nell’accettare i "Data Set Submission" nonostante i "mismatches".

Se la banca del compratore decide di rifiutare i "Data Mismatch", invierà un messaggio di "Mismatch Rejection" alla TMA che lo notificherà a tutte le "Involved Banks".

3a situazione: Più di una Obligor Bank e la buyer’s bank è anche una Obligor Bank

La banca del compratore, (come Obligor Bank) può accettare i "Data Mismatch" inviando un messaggio "Mismatch Acceptance" alla TMA, che lo notificherà a tutte le "Involved Banks". Ogni ulteriore Obligor Bank dovrà inviare un "Role and Baseline Acceptance" alla TMA  per accettare il loro ruolo nella "Established Baseline". La TMA notificherà il messaggio a tutte le "Involved Banks" Quando la "Baseline Acceptance Notification" per una Obligor Bank è inviato dalla TMA, la BPO è dovuta. Quando un "Role and Baseline Acceptance Notification” è inviato dalla TMA ciascuna Obligor Bank “agrees to pay or incur a deferred payment undertaking" secondo i termini specificati "Payment Obligation Segment" della "Established Baseline". Se invece, la banca del compratore intende rifiutare i "Data Mismatch", invierà un "Mismatch Rejection message" alla TMA. In questo caso la TMA la Baseline rimarrà "unchanged" con lo status "active".

Se la banca del compratore continua ad accettare i mismatches e le ulteriori Obligor Banks non intendono accettare di onorare la propria BPO, è decisione del compratore stabilire come la transazione debba essere conclusa.
Si segnala che i "mismatches" possono essere accettati in toto o rifiutati. Non è possibile accettare alcuni mismatches e rifiutarne altri.

Come abbiamo già segnalato, una singola transazione TMA può contenere più BPOs. In questo caso, l’ammontare dovuto da ogni Obligor Bank è proporzionale alla sua quota sul totale dell’ammontare della BPO. Di seguito si riporta un esempio:

- Established Baseline: Euro 100,00

- Banca 1 emette una BPO per Euro 10,00

- Banca 2 emette una BPO per Euro 70,00
 

 A cura del Dr. Domenico Del Sorbo