Session 466 - CBPR+ Charges information

 Transaction charges are the charges that banks apply for the processing of customer payments.

Interbank transfers do not have associated charges, only customer payments do.

Each bank can decide at its discretion about its own price policy.

pacs.008 elements related to charges

 

How the charges-related information is presented in customer payment?

To answer this question, we have to consider the following elements of pacs.008:

Interbank Settlement Amount – this is the point-to-point currency amount that is settled between banks in one payment leg. This element may change throughout payment chain.

Instructed Amount – this is a conditional element that captures currency and amount instructed by the Debtor.

The Instructed Amount is present when Interbank Settlement Amount is in a different currency or amount. This may happen because of charges deduction or currency conversion. Instructed Amount cannot be changed in the payment chain.

Exchange Rate – this is a rate used for currency conversion. It must be present when currencies in Interbank Settlement Amount and Instructed Amount differ.

How the Exchange Rate is presented?

Instructed Amount currency is a base currency referred to as a whole unit to perform the exchange and the Interbank Settlement Amount currency is the quote currency.

If for example the Instructed Amount is in USD and the Interbank Settlement Amount is in EUR, USD 1 will be taken to show the exchange rate: 0.93998, because USD 1 equals EUR 0.93998.

Charge Bearer – this element specifies which party would bear the charges. Possible values in CBPR+ are:

CRED – Creditor

DEBT – Debtor

SHAR – Shared

Charges Information – this field provides information on the charges to be paid by the Charge Bearer. The meaning of this element is twofold. It shows either:

•     The amount of charges and the bank for whom the charges are due. This is a pre-paid scenario. In this scenario, the BIC of the bank for whom the charges are due is populated by the previous bank in the payment chain. The next bank upon receiving the message identifies its BIC and knows that the charges were pre-paid.
•     The amount of charges and the bank that has deducted the charges. In this scenario, charges were not pre-paid. Bank deducts its charges from the Interbank Settlement Amount and provides its BIC and amount deducted to inform the next banks in the payment chain.

This is a repetitive field and it may be added at each payment leg. As this element may show both charges pre-paid for Bank X, and in other business case charges deducted by Bank X, it is crucial that other charges-related information in the message (e.g. Interbank Settlement Amount and Instructed Amount) are used correctly.

Additionally it is important to note, that even that CBPR+ does not prevent Charges from being booked in different currency, for transparency the Charges in the message should be represented in the Interbank Settlement Amount Currency.

 

So, now, let’s have a look at how the information analyzed above is provided in the message itself: 

I hope that you can identify each element we discussed above.

However, I know that the business usage of these elements may not be clear for the time being. The theoretical explanation is not enough. But, I am sure it will become more understandable if we put it in the business context. And this is precisely the aim of the below examples.

The examples show the 3 charges options: DEBT, SHAR, and CRED.

While investigating them we are going to see how in practice banks levy their charges. 

 

DEBT

 

In this scenario, Bank A received the request for payment in EUR. The Amount is the EUR equivalent of USD 100.

The Instructed Amount is in USD, but the Interbank Settlement Amount is going to be in EUR. 

The Debtor’s account with Bank A is in USD.

Debtor informed Bank A that he will bear all the charges – DEBT option.

Three banks are involved in the payment. All of them have their own charges.

The below diagram depicts how the messages are structured.

 

(1) pacs.008 sent by Bank A

In our scenario, the Instructed Amount is USD 100.

The Instructed Amount is in USD and the Interbank Settlement Amount is in EUR. Instructed currency is used as the whole unit to perform the exchange, that is  USD 1 equals EUR 0.9401. This is our Exchange Rate.

EUR equivalent of the USD 100 is EUR 94.01. 

Bank A knows, however, Bank B’s charges for such a payment. They equal 10 EUR. In the message, Bank A adds EUR 10 to the EUR 94.01. So, the Interbank Settlement Amount is EUR 104, 01 (EUR equivalent of USD 100 + Bank B’s EUR 10 charges).

Additionally, Bank A signals to Bank B that the charges have been prepaid. How?

In Charges Information Bank A adds the BIC of BANK B (Agent – BANKFRBBXXX). This will indicate to Bank B that the charges have been pre-paid. Additionally Bank A populates the Amount that has been pre-paid (EUR 10).

What is not presented in the pacs.008 is what are the charges of Bank A for this payment. Let’s assume they equal USD 5.

In accordance with Debtor’s banking agreement Bank A will debit Debtor’s account for:

• USD 100 that the Debtor instructed
• USD 5 of Bank A’s charges
• USD equivalent for Bank B’s EUR 10 charges that have been pre-paid. As the Debtor’s account is in USD, any bookings on this account have to be reflected in USD.

(2) pacs.008 sent by Bank B

Bank B recognizes the pre-payment of charges by the inclusion of its BIC in the Charge Information Agent element. 

What is characteristic about the pre-paid scenario is also the fact that Interbank Settlement Amount is higher than Instructed Amount.

Bank B deducts its charges from the Interbank Settlement Amount. In the outgoing pacs.008 the Interbank Settlement Amount equals EUR 94.01 (EUR 104.01 – EUR 10). Now, the Interbank Settlement Amount is precisely the EUR equivalent of instructed USD 100.

Bank B removes the Charges Information as it is not needed for Bank C. If bank B left the Charges Information with Bank B’s BIC the information could be misleading for Bank C. The amounts presented would not add up.

(3) pacs.008 at Bank C

Bank C receives the payment and notices that the Charge Bearer code is DEBT. Bank C identifies that its charges have not been pre-paid. There is no its BIC in the Charges Information.

With DEBT option Bank C cannot deduct its charges from the amount it credits to the Creditor. In other words, Creditor receives EUR 94, 01 which is the EUR equivalent of USD 100 as instructed by Debtor.

Bank C may in such a situation claim the charges. Sometimes it is also possible to debit the Nostro account of Bank B that Bank C may hold for Bank B. This is subject to a bilateral agreement between banks.

 

Before we move on I would like to make one remark about the above scenario.

You may have noticed that Bank B is located in France. In European Union, there is PSD2 legislation (you can access this document here) that regulates that for certain payments only SHAR option is allowed (Article 62 (2)). Additionally, there is a so-called full amount principle introduced (Article 81). However, let’s assume that this scenario is a one-leg payment (both Bank A and Bank C are outside EEA). In this case, according to the Guidance for implementation of the revised Payment Services Directive (available here), these PSD2 articles are not applicable.

 

 SHAR

 

In this scenario, Bank A received the request for payment of USD 100. To avoid making this example too complex this time the currency of the Instructed Amount and Interbank Settlement Amount is going to be USD. Additionally, all four banks involved in the payment are located in the USA. All of them have their own charges expressed in USD. Debtor’s and Creditor’s accounts are also in USD.

I am aware that this may not be very probable business scenario, as such payment would be processed via the Payment system in the USD, however, for educational purposes I think is still valuable and will allow us to understand how the charges are processed.

Debtor informed Bank A that the charges will be shared – SHAR option.

The below diagram depicts how the messages are structured. 

 

(1) pacs.008 sent by Bank A

As the Interbank Settlement Account is in the same currency as the Instructed Amount, and there is no Charges Information, Bank A does not include Instructed Amount element in pacs.008.

In SHAR option Bank A’s charges are borne by Debtor, so Bank A will debit Debtor’s account for:

• USD 100 that the Debtor instructed
• USD 5 of Bank A’s charges

(2) pacs.008 sent by Bank B

In SHAR option, except the charges of the Debtor’s Agent (Bank A), all other banks’ charges are borne by Creditor. So, in practice, beginning of Bank B the way SHAR charges are processed is the same as for CRED option.

How do banks levy their charges in such a scenario? Banks deduct their charges from the Interbank Settlement Amount. 

Following this logic, Bank B reduces the Interbank Settlement Amount by the amount of its charges (USD 10), so that the Interbank Settlement Amount in pacs.008 sent to Bank C equals USD 90.

Additionally, Bank B adds also the Charges Information to inform the next banks in the chain that it has deducted its charges.

Because, the Charges Information has been added and Interbank Settlement Amount is now different from the amount that Debtor instructed, Bank B adds also the Instructed Amount to pacs.008. This way, the whole picture becomes clear for the next banks.

(3) pacs.008 sent by Bank C

Following the same logic, Bank C reduces further the Interbank Settlement Amount by the amount of its charges (USD 7), so that the Interbank Settlement Amount in pacs.008 sent to Bank D equals USD 83.

Additionally, Bank C adds also the Charges Information to inform the next bank in the chain that it has deducted its charges.

Here we have an example of the repetitive nature of Charges Information. We have two occurrences of this element. 

What we can observe is that there is a very straightforward relationship between the following elements:
Instructed Amount – Charges = Interbank Settlement Amount.

(4) pacs.008 at Bank D

Bank D receives the payment and notices that the Charge Bearer code is SHAR so its charges will be borne by Creditor.

Bank D decreases Interbank Settlement Amount (USD 83) with the amount of its charges (USD 5) and credits the Creditor (USD 78).

 

CRED

 

This scenario is a simpler version of the previous one. We have only 3 banks located in the USA. 

Bank A received the request for payment of USD 100. Again, to avoid making this example too complex the currency of the Instructed Amount and Interbank Settlement Amount is going to be USD. All of the banks have their own charges expressed in USD. Debtor’s and Creditor’s accounts are also in USD.

Debtor informed Bank A that the charges will be borne by Creditor – CRED option.

The below diagram depicts how the messages are structured. 

(1) pacs.008 sent by Bank A

As the Interbank Settlement Amount is in the same currency as the Instructed Amount we could expect that the Instructed Amount will not be populated by Bank A. However, in this scenario Bank A’s charges are paid by Creditor. Bank A makes Creditor pay its charges by reducing the Interbank Settlement Amount by its charges (USD 5). Also, Bank A adds the relevant information in Charges Information indicating that it has deducted its charges by including its BIC (BANKUSAAXXX) and providing the amount (USD 5). 

In CRED option Bank A’s charges are borne by Creditor, so Bank A will debit Debtor’s account only for:

• USD 100 that the Debtor instructed

(2) pacs.008 sent by Bank B

In CRED option charges are borne by Creditor. Banks deduct their charges from the Interbank Settlement Amount.

Following this logic, Bank B reduces the Interbank Settlement Amount by the amount of its charges (USD 10), so that the Interbank Settlement Amount in pacs.008 sent to Bank C equals USD 85.

Additionally, Bank B adds also the Charges Information, to inform the next bank in the chain that it has deducted its charges.

(3) pacs.008 at Bank C

Bank C receives the payment and notices that the Charge Bearer code is CRED so its charges will be borne by Creditor.

Bank C decreases Interbank Settlement Amount (USD 85) with the amount of its charges (USD 5) and credits the Creditor (USD 80).

 

This is the end of the charges part. In my opinion, this is one of the most difficult aspects of payment processing. It would be great if the information I provided were of some help. In CBPR+ pacs.008 usage Guidelines there are many detailed rules that show cross-element dependencies in this context. I advise you to consult them in case of any questions.  

Reference - https://www.iso20022payments.com/cbpr/charges/

Session 465 - ISO 20022 & Addresses: Structured, Unstructured, and Semi-Structured 🧩📬

 ISO 20022 & Addresses: Structured, Unstructured, and Semi-Structured 🧩📬

By the end of 2026, address data must be transmitted in a structured format. But what does this mean in practice? And what role do semi-structured addresses play? 🤔

📌 What does “structured address data” mean?

In structured addresses, information such as street, house number, city, postal code, and ISO country code is entered in separate fields. This clear segmentation improves data quality, enables automated processing, more precise validation, and reduces errors.

🔄 What is a semi-structured address?

A semi-structured address combines elements of unstructured data with some structured fields.

• Example: Street and house number, along with other data, can remain combined in one field, while city and country code are provided separately. 🌍

• Advantage: Offers flexibility during data migration, making it ideal for companies transitioning gradually to fully structured processing.

📅 When will it be available?

Semi-structured addresses will be available starting in November 2025, providing companies with a practical solution.

💡 5 Tips to Prepare:

1️⃣ Understand the requirements:

By end of 2026, address data must be structured for payment transactions. This is mandatory for cross-border payments 🌏 and relevant for 🇪🇺 SEPA payments as well.

2️⃣ Ensure data quality:

Review your master data! Are fields like “City,” “Country,” and other address elements already separated and complete? 🗂️

3️⃣ Keep track of specific rules:

While address data is not recommended for SEPA payments, it may be a mandatory for payments outside the SEPA area 🌍 e.g., to the UK or Switzerland, even if it’s classified as a SEPA payment.

4️⃣ Leverage semi-structured options:

From 2025, semi-structured addresses will provide a smoother entry point. 🛠️ They allow for incremental updates to your systems and processes.

5️⃣ Stay informed:

ISO 20022 standards are continuously evolving. Use updates from organizations like SWIFT or consult your banking partner 💛.

🔍 Conclusion:

The structured processing of addresses is a key component of the ISO 20022 migration. Semi-structured addresses offer a pragmatic transition and help companies optimize their processes efficiently and future-proof their operations.

♻️ Did you find this post helpful? Share it with your network and follow me for more insights and updates.

Session 453- CBPR+ - HVPS+ Comparison pacs.008 pacs.009 pacs.002 pacs.004 pacs.010

 Session 453- CBPR+ - HVPS+ Comparison pacs.008 pacs.009 pacs.002 pacs.004 pacs.010

CBPR+ ➢ Number of transactions Single Transaction only ➢ Date/Time Datatype: Time Offset made mandatory (Mandatory in FIN)

HVPS+ ➢ Number of transactions Single transaction only ➢ Date/Time Datatype: Time Offset made mandatory 

Ex: Ottawa 2019-08-07T09:27:01.001-05:00 A particular point in the progression of time defined by a mandatory date and a mandatory time component, expressed in local time with UTC offset format (YYYY-MM-DDThh:mm:ss.sss+/-hh:mm). This representation is defined in "XML Schema Part 2: Datatypes Second Edition - W3C Recommendation 28 October 2004" which is aligned with ISO 8601. Note on the time format: 1) beginning / end of calendar day 00:00:00 = the beginning of a calendar day 24:00:00 = the end of a calendar day 2) fractions of second in time format Decimal fractions of seconds may be included. In this case, the involved parties shall agree on the maximum number of digits that are allowed. Example: 2020-07-16T19:20:30.45+01:00 

CBPR+ ➢ 

Character Set: All textual fields (all messages) are restricted to FIN X Characters: 0-9 a-z A-Z / - ? : ( ) . , ' + .

Special characters are allowed in ❑ All Name and postal Address for all actors, ❑ Related Remittance Information and Remittance Information (structured and unstructured), ❑ Email Address where included as part of a proxy element are extended to support the following additional characters. 

List of special characters: !#$&%*=^_’{|}~";<>@[\] 

➢ Settlement Information (if present) Settlement Method: Instructed Agent Instructing Agent COVER (pacs.008 and pacs.009 ADV) Settlement Account: Used (in pacs.009 Core and COV only) Clearing System: Not Used → No impact – Many to Many multiple transactions leg ➢ Original Transaction Reference block (Pacs.004

 

HVPS+ 

➢ Character Set: All textual fields (all messages) are restricted to FIN X Characters: 0-9 a-z A-Z / - ? : ( ) . , ' + . Special characters are allowed in ❑ All Name and Postal Address for all actors, 

 ❑ Related Remittance Information and Remittance Information (structured and unstructured),

 ❑ Email Address where included as part of a proxy element are extended to support the following additional characters. List of special characters: !#$&%*=^_’{|}~";<>@[\] 

➢ Settlement Information (if present) Settlement Method: Clearing System Settlement Account: Not Used Clearing System: Used → No impact - High Value Payment ➢ Original Transaction Reference block (Pacs.004) Not Use

Session 451 – What is T-account and Wash account ?

 Session 451 – What is T-account and Wash account ?

In this article, I would like to briefly present the bookings on T-accounts and Wash accounts.

T-accounts

As not all of the readers may be familiar with double-entry accounting represented on T-accounts, in many sections of my website I use the simplified illustration of booking entries. It still seems important, however, to illustrate how bookings would look on T-accounts. This is the purpose of this section.

What is a T-account?

A T-account is a term used in the context of double-entry bookkeeping.

It is called a T-account because the bookkeeping entries are laid out in a way that resembles a T-shape.

This is what the T-account looks like:

As you can see debits are listed on the left and credits are recorded on the right.

But we can still ask what a debit or a credit mean in the context of the account that banks hold.

So, when the account is debited it means that the balance on the account decreases. As a consequence, if you are Debtor funds are taken from your account.

On the other hand, when the account is credited it means that the balance on the account increases. If you are Creditor, you receive funds on your account.

Additionally, a very important notion is the rule according to which to record every transaction, there will be two accounting entries needed:

 one account will get a debit entry and

 the second one will get a credit entry.

This is to ensure that the total sum of debits is equal to the total sum of credits.

How about having a look at an example?

Let’s say that Bank A sends the Credit transfer to Bank B.

We can illustrate the bookings with T-accounts in the following way:

Needless to say, in the above example, we do not consider any currencies, charges, etc.

What we can see, however, is that in both banks there is one entry on the debit side and one entry on the credit side. In both banks amount debited is equal to the amount credited.

What is additionally worth noticing is that, if the Mirror Nostro is credited then the actual Nostro in a correspondent bank is debited and vice versa. Mirror Nostro is used to reflect the status/balance of the Nostro account.

Between Bank A and Bank B, we can see an arrow symbolizing a payment message. And what is written above the arrow may be easily overlooked, but in fact, is very important.

The above example refers to Credit transfer.

In Credit transfer, the direction of the message is the same as the direction of the funds: from Debtor to Creditor. We can see that message arrow points from the left to the right.

The same is the direction of the bookings in Bank A and in Bank B.

Bank A sends the message as Debtor Agent to Bank B which is Creditor Agent.

Why Bank A sends this message?

It does so on behalf of its customer. The Debtor initiates the transfer and Debtor Agent pushes funds toward Creditor Agent.

This is why Credit transfer is an example of push transfer.

The opposite situation we are going to have in the case of Direct debit.

In the case of Direct debit, it is Creditor that initiates the transfer. It’s a pull transfer. The Creditor Agent pulls the funds.

The direction of the message is from Creditor to Debtor, but the direction of the funds will be from Debtor toward Creditor.

Of course in the case of Direct debit, the bookings will look different, however, the logic still is the same: debits on the left, credits on the right.

Wash accounts

As you certainly know, accounting rules differ among banks.

One of the differences is that some banks may use additional temporary accounts, like Wash accounts during the processing flow.

Temporary accounts are zero-balance accounts. It means that after all the transactions are finalized these accounts should not have any debit or credit balance. You always take out the same amount that you put in.

There are many benefits of using Wash accounts.

In this section, I would like to complement the above example with only one scenario.

What I have in mind is a Customer payment sent with Cover method.

As you may know, Cover method decouples the settlement from the payment information. There are two messages sent:

 one is an announcement with information concerning payment details

 second is the cover payment which moves the funds

So, let’s say that Bank B from the example above is going to receive the payment sent with Cover method.

When should Bank B perform bookings?

Of course, it may be that when Bank B receives an announcement it decides to wait for the arrival of the respective funds before doing any bookings.

But sometimes Bank B may decide that it will book the Creditor without waiting for the funds. The bookings will be carried out upon receiving the announcement. This may be because Bank B trusts the banks involved in the transfer.

What will these first bookings based on the announcement look like?

In such a case Bank B will credit the Creditor.

But, what account will be debited?

Bank B will not want to debit Bank A’s Nostro Account because the funds have not arrived yet.

We can see already, that Bank B will need a temporary account to perform the bookings.

Bank B is going to use a dedicated Wash account.

This will be done as follows:

We can see that in that case the credit side of the transaction is decoupled from the debit side.

To perform bookings only on the Credit side of the transaction a temporary account is needed.

And what will happen when the funds finally arrive?

When the Cover payment arrives the second booking will be conducted:

This second booking takes care of the debit side of the transaction.

Nostro account of Bank A is debited, and Wash account is credited.

After this second booking, the Wash account is correctly balanced.

As a temporary account, the Wash account is a 0-balance account.

And precisely, after this second booking, there is no debit or credit balance on this account.

Source of information - https://www.iso20022payments.com/miscellaneous/t-account-and-wash-account/

Please follow

www.linkedin.com/in/prashantpppatil

https://www.linkedin.com/groups/9809571/

https://www.youtube.com/@BankingPayments