With this article, I want to start a series dedicated to CBPR+ messages.
First I am going to investigate the pacs.009.001.08 Financial Institution Credit Transfer (core) message. I will call this message simply pacs.009.
Before we dive deep into the analysis itself, let’s position this message in the bigger picture.
pacs.009 in the broader context
The CBPR+ UHB states that:
The Financial Institution Credit Transfer message is sent by a Debtor Financial Institution to a Creditor Financial Institution:
- directly or
- through other agents and/or
- a payment clearing and settlement system.
From the above fragment, we can learn about the ways pacs.009 can be processed.
In the ISO 20022 market implementations article, I presented the diagram showing the main sectors in which the payments may be processed.
What I would like to do now is to use this diagram to show the above-listed ways of exchanging pacs.009.
When we place the above information on the diagram we get the following picture:
So, what can we learn from this diagram?
To begin with, we can notice that the institution sending the message and receiving the message is always the Financial institution. This is the reason why pacs.009 is always placed in the Bank-to-Bank space.
Based on the fragment quoted from the CBPR+ UHB I placed in the diagram 4 scenarios of processing pacs.009.
Let’s have a closer look at them:
The first two scenarios are placed in the upper part of the Bank-to-Bank space.
There is only green background color there indicating that these messages are CBPR+ messages:
(1) First scenario depicts pacs.009 sent directly between Bank B and Bank C
(2) Second scenario shows pacs.009 processed by several agents
The next pair of messages is in the lower part of the Bank-to-Bank space:
(3) Third scenario presents pacs.009 sent by Bank A via CBPR+ message that is later on processed by a Market Infrastructure
(4) Fourth message shows the pacs.009 exchanged only via Market Instrafstucture.
As we are in the CBPR+ part of my website I will not cover here scenarios (3) and (4). These scenarios will be investigated while discussing the TARGET system.
In this article, we are going to have a closer look at pacs.009 sent over CBPR+ space.
– our business scenario –
Here is the scenario I would like to investigate in this article.
There are four banks involved in the payment in this scenario.
Bank A in Australia (BANKAUAA) is required to pay USD 2000000 to Bank D in Poland (BANKPLDD) on 5th April, 2023.
Bank B (BANKUSBB) is Bank A’s USD correspondent. It means that Bank B holds a USD account for Bank A.
Bank C (BANKUSCC) is Bank D’s USD correspondent. It holds a USD account for Bank D.
Bank A as the debtor initiates a payment by sending pacs.009 to its correspondent. Upon receiving pacs.009 from Bank A, Bank B debits the account of Bank A and initiates a serial payment towards Bank D via Bank C as an intermediary (Creditor Agent). As discussed in the cross-border payments article, since the payment leg between Bank B and Bank C takes place in the USA it might be settled via a Payment System in the USA (e.g. Fedwire). However, for the sake of this example, let’s assume that it is settled by direct pacs.009 from Bank B to Bank C. This means that these two banks have the necessary business relationship to process this payment.
In this article, we are going to discuss the payment leg from Bank B to Bank C.
It will be the second and last pacs.009 sent in this payment chain.
Upon receiving pacs.009 from Bank B, Bank C will not send another pacs.009 to Bank D. As Bank C credits the USD account of Bank D, it will inform Bank D by the means of camt.053 (account statement) and optionally via camt.054 (credit notification). Of course, we are going to explore these messages in future articles.
– payment message –
Now let’s look at the message from Bank B to Bank C.
The below picture illustrates the BAH (head.001) that will be sent together with pacs.009.
Of course, the Business Message (BAH and pacs.009) needs to be embedded in the proper SWIFT envelope. You can learn about CBPR+ message structure
in a dedicated article. For this example, I used only the simple <Envelope> tag.
As you may remember, the BAH From element identifies the BIC of the party who created the Business Document (in our case pacs.009), and To element identifies the BIC of the party who will ultimately process the Business Document.
These two elements can be understood as Sender and Receiver.
It’s worth highlighting that according to the CBPR+ rules BAH From BIC must match Instructing Agent BIC and BAH To BIC must match Instructed Agent BIC.
So, in our scenario From element contains BIC of Bank B (Instructing Agent) and To element contains BIC of Bank C (Instructed Agent).
Business Message Identifier has to be the same as Message Identification captured within the Business Document’s Group Header.
Message Definition Identifier is pacs.009.001.08.
Business Service for pacs.009 core is swift.cbprplus.02.
Creation Date captures the date and time when the Business Application Header was created. You can learn more about the format of this element in UTC offset article.
When we look closer at the names of the elements and compare them with the tags in the message we can spot some pattern that will allow us to link the name of the element to the tag used in the message. For example we can figure out that the XML tag for Message Definition Identifier is <MsgDefIdr>.
The BAH is attached to the pacs.009 which contains further business information.
For readability reasons, I split the pacs.009 into two parts.
Below is the first part:
Message Identification element is a point-to-point reference used to unambiguously identify the message. Point-to-point means that this is an element created by Bank B, that sends this message. It has to be the same as Business Message Identifier from BAH.
Creation Date captures the date and time when the message was created. You can learn more about the format of this element in UTC offset article.
Number of Transactions in CBPR+ payment usage guidelines is fixed to 1.
Settlement Method indicates how the payment leg is settled. INGA means that Instructing Agent (Bank B) has settled this payment leg. You can learn more about this topic in Settlement Method: INGA vs. INDA article.
In Payment Identification there are three references:
- Instruction Identification – a point-to-point reference restricted in CBPR+ to 16 characters. This is the reference of Bank B, sending the message.
- End to End Identification – an end-to-end reference provided by the Debtor which must be passed unchanged throughout the payment chain and reported to the Creditor. This is the reference that Bank A populated in the first message, which is now forwarded by Bank B. Later on, Bank C will provide this reference to Bank D.
- UETR – the end-to-end Transaction Reference created using the UUIDv4 standard. This reference must be passed unchanged throughout the payment chain. This is the reference that Bank A populated in the first message, which is now forwarded by Bank B.
You can learn more about these different kind of references in Point-to-point vs. End-to-end article.
Interbank Settlement Amount contains the amount that Bank A wants to send to Bank D. You can learn about the format of this element in Currency and Amount article.
Interbank Settlement Date contains the date when Bank A is required to pay to Bank D. It is a date when the payment between the Instructing Agent and the Instructed Agent should be executed.
And now it’s time for the final part of the pacs.009:
Instructing Agent and Instructed Agent represent the Agents involved in the pacs point-to-point message exchange. These roles, therefore, change on each payment leg. In the analyzed payment leg, Bank B is the Instructing Agent (Sender) and Bank C is the Instructed Agent (Receiver).
Debtor, Debtor Agent, Creditor and Creditor Agent are static roles. These roles were the same in the first pacs.009 sent by Bank A in this payment chain.
As we already know the Debtor Agent services the account for the Debtor, and Creditor Agent services the account for the Creditor.
You can learn more about these roles in the following articles:
Remittance Information enables the reconciliation of the payment.
– file –
You can access the file I analyzed in this article here: pacs.009 (core)
If you are interested you can play with it in the SWIFT Readiness Portal.
You can learn about SWIFT Readiness Portal in CBPR+ documentation article.
I have tested this file there and it is a valid message:
The Warnings in the Portal relate only to the Envelope and BIC formats. Of course, the BICs used by me are not registered and published BICs.
In the next article, we are going to explore pacs.009 ADV.