With this article, we continue the series dedicated to CBPR+ messages.

In the previous article, we investigated the pacs.009.001.08 Financial Institution Credit Transfer (core) message, and now we are going to have a look at the ADVICE version of pacs.009.

But, before analyzing pacs.009 (ADV) I would like to recall very briefly two methods of processing payments: SERIAL and COVER.

 

SERIAL method vs. COVER method

 

We usually talk about this differentiation in the context of customer payments, however, as we will see in this article it is also relevant for interbank payments.

 

The SERIAL method means that the payment is sent through a ‘series’ of banks. 

In SERIAL method, there is a direct account relationship between each connected pair of banks in the payment chain.

There is only one message exchanged in the SERIAL method. This message is sent from one financial institution to the next financial institution in the chain.

We saw the example of SERIAL method in the previous article about pacs.009 (core). The message was forwarded from one bank to another.

If there is only one message used in SERIAL method it means that this message contains the necessary information about payment details but it is also the settlement instruction. And this aspect is the most important difference when we compare SERIAL method to COVER scenario. 

 

The COVER method decouples the settlement from the payment information.

To do so, COVER method uses two messages. In the context of interbank payment, these are:

• pacs.009 (ADV) which transports information – for this message, there is no need to have an account relationship. The only requirement is to have RMA* authorization set up. 
• pacs.009 (core) which is a settlement instruction. It is called COVER message, as it settles the underlying pacs.009 (ADV). For CBPR+ pacs.009 (core) messages not only RMA is necessary but also the business account relationship. 

*Relationship Management Application (RMA) was introduced by SWIFT to stop unwanted messages from reaching banks.

 

Pacs.009 (ADV) is part of the payment sent via COVER method. So, this is the method we are going to discuss in this article.

Now, that we have some understanding of COVER method, let’s position pacs.009 (ADV) in the bigger picture.

 

pacs.009 (ADV) in the broader context

 

The CBPR+ UHB states that the pacs.009 (ADV) is used to pre-advice an Agent of a fund movement toward the Creditor.

This message is sent directly by a Debtor Agent to a Creditor Agent.

Similarly to the pacs.009 (core) also in pacs.009 (ADV) both Debtor and Creditor are Financial Institutions.

In the ISO 20022 market implementations article, I presented the diagram showing the main sectors where payments may be processed.

What I would like to do now is to use this diagram to position pacs.009 (ADV) in the broader context.

When we place the above message on the diagram we get the following picture:

 

 

As we can see there is only one arrow with pacs.009 (ADV) in the Bank-to-Bank space.

In the previous article concerning pacs.009 (core) we saw that core variant of pacs.009 may be processed in more scenarios.

Why is there such a difference?

To understand this we have to further clarify the purpose of the pacs.009 (ADV).

Unlike the other pacs.009 variants in the CBPR+ collection, the pacs.009 (ADV) message is exchanged directly between the Debtor Agent (as an Instructing Agent) and Creditor Agent (as an Instructed Agent). Since pacs.009 (ADV) is used as a direct advice message sent by a Debtor Agent to a Creditor Agent it is not forwarded by the intermediary banks. In the picture above, this message is sent by Bank B to Bank C directly.

This constitutes the first difference to pacs.009 (core) which can be forwarded by several intermediaries. Pacs.009 (core) can be sent through a „series” of banks, and for each CBPR+ payment leg, there is a direct account relationship between Sender and Receiver.

Additionally, we have noticed that for pacs.009 (ADV) there is no need to have an account relationship.

Why is that?

This is because pacs.009 (ADV) is as an advice message, and not a settlement instruction. It is used to inform upfront an Agent of a fund movement through pacs.009 (core). We can say that pacs.009 (ADV) carries information but does not carry the funds. In other words, pacs.009 (ADV) has to be accompanied by pacs.009 (core), which is used to perform the settlement of this pre-advice message. 

As pacs.009 (core) results in a settlement, it can be processed via Market Infrastructure where the settlement is done. However, since pacs.009 (ADV) is not a settlement instruction it cannot be processed via Payment Systems. This is why I did not place this message in the lower part of the Bank-to-Bank space, where the settlement via Market Infrastructure is present. This is the second difference between pacs.009 (ADV) and pacs.009 (core).

 

I said above that pacs.009 (ADV) is sent directly between Debtor Agent and Creditor Agent. It is important to clarify here that it does not mean that the whole transaction involves only two banks. On the contrary. To understand it better let’s take a look at the business scenario.

 

pacs.009 (ADV) and (core)
– our business scenario –

 

Here is the scenario I would like to investigate in this article. 

 

 

There are six banks involved in the payment. 

Bank A wants to pay Bank F.

Bank A as the Debtor initiates a payment instruction to the Debtor Agent (Bank B). Bank B holds an account for Bank A.

Bank B decides (according to the agreement it has with Bank A) that this payment will be sent using COVER method. This may be, for example, because of the time zone differences, which results in the final settlement occurring on the next business day of Creditor Agent. The COVER method allows the Creditor Agent to take the incoming funds into their position.

According to the COVER method, Bank B sends two messages:

• pre-advice message via pacs.009 (ADV) directly to Bank E (Creditor Agent)
• settlement message via pacs.009 (core) to Bank C (Bank B’s correspondent) 

Upon receiving pacs.009 (core) from Bank B, Bank C sends the next pacs.009 (core) to Bank D (Bank E’s correspondent).

Bank D credits the account of Bank E and informs Bank E by the means of camt.053 (account statement) and optionally via camt.054 (credit notification).

Bank E as the Creditor Agent credits the account of Bank F.

Let’s have a closer look at the messages sent by Bank B.

 

pacs.009  (ADV) and (core)
– payment messages –

 

So we know that Bank B sends two instructions. 

I would like to illustrate below what these messages will look like and in what aspects they will be similar to/different from each other.

To make it easier to compare the two variants of pacs.009 I prepared the table that summarises the most important elements:

 

 

So let’s now discuss several points from the above table.

(1) In both messages From element and Instructing Agent element contains Bank B, as Bank B is the Sender.

Pacs.009 (ADV) is sent to Bank E, so Bank E is present in To element and Instructed Agent element. 

Pacs.009 (core) is sent to Bank C, so Bank C is present in To element and Instructed Agent element. 

(2) Dedicated Business Service elements clearly differentiate the two message variants. 

(3) In pacs.009 (ADV) Settlement Method is COVE, indicating COVER method. 

In our scenario pacs.009 (core) has value INDA reflecting the fact that Bank C (INstructeD Agent) will settle this payment leg. 

(4) In pacs.009 (ADV) there are two elements containing information about Reimbursement Agents.

These elements detail the Agents who will process the pacs.009 (core). In our scenario, these are: Bank C and Bank D.

(5) There are the following two textual rules in the pacs.009 (core) Usage Guidelines regarding references.

If pacs.009 (core) is used to cover pacs.009 (ADV):

• the E2E identification should transport the Instruction Identification of the underlying pacs.009 (ADV)

• the UETR should transport the UETR of the underlying pacs.009 (ADV)

This second requirement (same UETR) informs us that pacs.009 (ADV) and covering pacs.009 (core) should be understood as one transaction.

(6) In this point we are looking at Debtor, Debtor Agent, Creditor Agent and Creditor.

 

Let’s start with pacs.009 (ADV).

As per definition pacs.009 (ADV) is sent by the Debtor Agent to the Creditor Agent.

In our scenario, Bank B is a Debtor Agent in pacs.009 (ADV) and Bank E is a Creditor Agent*.

*since Debtor Agent and Creditor Agent are both optional elements, we can imagine that Bank B might also decide not to populate these elements because both Bank B and Bank E are already present in this message as Instructing and Instructed Agents. 

 

Bank B holds an account for Bank A – Bank A is a Debtor in pacs.009 (ADV).

Bank E holds an account for Bank F – Bank F is a Creditor in pacs.009 (ADV).

 

And now we move to the pacs.009 (core).

So, what is the situation in the pacs.009 (core) regarding Debtor, Debtor Agent, Creditor Agent and Creditor?

We can see that pacs.009 (core) as a COVER is processed from Bank B to Bank E.

To determine which banks play these roles let’s start with the debit side in pacs.009 (core).

CBPR+ UHB states that to provide party transparency the Debtor of the pacs.009 (ADV) remains the Debtor of the pacs.009 (core).

So, on the debit side banks in pacs.009 (ADV) and pacs.009 (core) are the same.

Bank B sends pacs.009 (core) with the same Debtor (Bank A) and the same Debtor Agent (Bank B) as in pacs.009 (ADV). 

 

And what about the credit side in pacs.009 (core)?

Here the situation changes. 

Creditor Agent and Creditor are populated according to the flow of pacs.009 (core).

The flow of the COVER payment ends with the crediting of the Bank E account held by Bank D. 

So, in pacs.009 (core) Bank E is the Creditor and Bank D plays the role of the Creditor Agent.

 

And what about Bank F? This Bank is the Creditor in pacs.009 (ADV).

Is Bank F identified in the pacs.009 (core)?

Yes. 

According to the CBPR+ UHB, the Creditor of the pacs.009 (ADV) is captured in the following element of pacs.009 (core):

• Instruction for Creditor Agent/Instruction Information

Additionally /UDLC/ (UnDerLying Creditor) codeword is used.