Appendix XXXVII - Purpose of payment code (UGX)

View appendix in PDF
S.NoPurpose of payment DescriptionCode Value
1Salary PaymentSALA
2Tax PaymentTAXS
3Value Added Tax PaymentVATX
4Insurance PremiumINSU
5Loan RepaymentLOAR
6RefundREFU
7DividendDIVD
8Pension PaymentPENS
9Bank Loan FeesBKFE
10Cash Management TransferCASH
11Collection PaymentCOLL
12DepositDEPT
13Intra Company PaymentINTC
14Intra Party PaymentINTP
15Agricultural TransferAGRT
16Business ExpensesBEXP
17Commercial PaymentCOMC
18CopyrightCPYR
19License FeeLICF
20RoyaltiesROYA
21Service ChargesSERV
22SubscriptionSUBS
23Supplier PaymentSUPP
24CommercialTRAD
25Charity PaymentCHAR
26Mobile P2P PaymentMP2P
27Guaranteed E PaymentECPG
28E paymentEPAY
29Compensation PaymentCOMP
30Government InsuranceGOVI
31Property Loan RepaymentHLRP
32Property Loan SettlementHLST
33Insurance Premium CarINPC
34Insurance Premium RefundINPR
35Payment Of Insurance ClaimINSC
36InterestINTE
37Labor InsuranceLBRI
38Life InsuranceLIFI
39LoanLOAN
40Advance PaymentADVA
41CostsCOST
42Debit Card PaymentDCRD
43EducationEDUC
44GiftGIFT
45Government PaymentGOVT
46InstallmentINSM
47Invoice PaymentIVPT
48Payment TermsPTSP
49Receipt PaymentRCPT
50RebateREBT
51RentRENT
52StudySTDY
53Instant PaymentsIPAY
54AnnuityANNI
55DerivativesDERI
56SavingsSAVG
57SecuritiesSECU
58Treasury PaymentTREA
59AllowanceALLW
60Bonus Payment.BONU
61CommissionCOMM
62PayrollPAYR
63Price PaymentPRCP
64Estate TaxESTX
65Housing TaxHSTX
66Income TaxINTX
67Property TaxPTXP
68WithHoldingWHLD
69TaxRefundTAXR
70AirAIRB
71BusBUSB
72FerryFERB
73RailwayRLWY
74EnergiesENRG
75UtilitiesUBIL
76Lottery PaymentLOTT
E-commerce
Ikano Bank Brings E-commerce Thinking into the Physical Retail World

Ikano Bank and BNP Paribas Bank Polska have reshaped Poland’s in‑store instalment lending by introducing a BLIK‑based credit journey that brings online‑level speed and simplicity into physical retail.

Read more
Digital Wallet
Wero Leads Europe’s Charge for Payments Sovereignty

The launch of Wero marks a major step in Europe’s ambition to reclaim control over its payments landscape, with BNP Paribas among the key banks driving the initiative. By offering a single European wallet for everyday transactions, Wero reduces fragmentation, enhances data sovereignty, and positions Europe to compete more effectively with global payment providers through European‑led infrastructure.

Read more

Appendix XXXVI - ISO 20022 Structured adress

View appendix in PDF

As of November 14, 2026 cross-border and high value domestic payments with addresses that do not comply with the new ISO 20022 standards (structured or semi-structured format) will be rejected by SWIFT and market infrastructures (such as TARGET2 or CHAPS). This change follows the definitive migration of SWIFT messages to ISO 20022 in November 2025 and aims to enhance transaction efficiency, strengthen anti-money laundering and counter-terrorism financing measures, and standardize international payment processes.

Key Requirements and deadlines

DateAction Required
November 2025- November 2026Transition period: All 3 formats (unstructured, semi-structured, structured) are accepted.
14 November 2026Fully Unstructured addresses rejected: Only semi-structured or fully structured allowed.

Why does this matter to you? 

Unstructured addresses, previously accepted, now pose operational risks: they may lead to delays, additional compliance investigation costs, or even rejection by the beneficiary’s bank.

Further details are available in the newsletter via this link: https://cashmanagement.bnpparibas.com/sites/default/files/2026-03/Newsl…

Minimum requirements 

As of November 2026, every address must include at least a country code and a town/city name (in the dedicated structured fields in MX). 

Generic terms (e.g., “not provided”, “unknown”) in the Town/City field will not trigger automatic rejection by BNP Paribas but may cause processing delays or rejection by the beneficiary’s bank.

MX (pain.001)

Semi-structured format

 <Nm>ALAIN DUPONT</Nm>

<PstAdr>

<PstCd>1000</PstCd>

<TwnNm>Brussels</TwnNm>

<Ctry>BE</Ctry>

<AdrLine>Rue de France 23</AdrLine>

<PstAdr>

The semi-structured postal address format enables you to combine structured and unstructured address data. At a

minimum, the structured part must include the Town Name and Country Code (ISO 2-letter format).

In the semi-structured address, structured elements must not be repeated in the AdrLine element(s)

Fully structured format

 <Nm>ALAIN DUPONT</Nm>

<PstlAdr>

<StrtNm>Rue de France</StrtNm>

<BldgNb>23</BldgNb>

<PstCd>1000</PstCd>

<TwnNm>Brussels</TwnNm>

<Ctry>BE</Ctry>

<PstlAdr>

 

We strongly

encourage you to provide as much address information as possible in the structured data elements—such as Postal Code,

Street Name and Building Number—whenever this data is available in a structured form.

The remaining address details can be entered across two lines, each limited to 70 characters of free-form text in <AdrLine> . The unstructured address lines should only be used for information that cannot be reliably structured or does not

fit into the available structured data elements.

Impacted legacy formats:

  • MT101: This format does not support fully structured addresses. However, using the 59F field for the beneficiary’s address allows for a semi-structured format that meets the financial industry requirements.
  • CFONB320: This format only supports semi-structured addresses under limited conditions. We recommend planning its phase-out and migrating to pain.001 before November 2026.

MT (MT101)

If you are still using the MT101, use Field 59F to indicate a beneficiary address and ensure that it includes Country

Code and Town Name as structured elements in line 3.

This is the only way to support the transmission of semi structured postal addresses.

If no beneficiary address is provided, Field 59 withoutLetter Option may be applied. In this case, the first two lines will

be processed as the beneficiary’s name only, excluding address interpretation.

 

Semi-structured format

:59F:/BE30001216371411

1/JOHN SMITH

2/HOOGSTRAAT 6, 18TH FLOOR

3/BE/BRUSSELS  1000

 

 

 

 

Where:

1/= Name (JOHN SMITH)

2/=Address Line (HOOGSTRAAT 6, 18TH FLOOR)

3/=Country Code (BE)/Town Name (BRUSSELS) , and Postal Code (1000)

 

 

Subfield 1

'Party Identifier' /(Account) or (Code)(Country Code)(Identifier)

 

Subfield 2 'Name & Address'

1/Name of the ordering customer

2/Address details

3/Country code/Town, Postal Code

! We emphasize the importance of properly respecting the structure “Country Code / Town name”. If additional information follows the Town Name, it must be separated by a comma.

   

CFONB320

Semi-structured format

Address line n°1 = Batiment Alsace

Address line n°2 = 60 rue de la source

Address line n°3 = FR/Paris  , 75010

In the CFONB320 file, BNP Paribas can only identify the Country Code and Town Name if line 3 is present in the address and formatted as :

Line “3” = Country code ( 2 character ISO code)a slash and the  Citya comma and the Postal Code

! We emphasize the importance of properly respecting the structure “Country Code / Town name”. If additional information follows the Town Name, it must be separated by a comma.

ISO 20022 Migration Hub

Connected countries
Boston Consulting Group Forges a Future-Ready Treasury

Boston Consulting Group (BCG) modernises its treasury by building a connected, data-driven cash management framework with BNP Paribas and technology partners. The transformation improves global cash visibility, centralises liquidity, and automates payments and FX processes across dozens of countries. A strong foundation of systems, data, and collaboration positions treasury to scale innovation and efficiency worldwide.

Read more
Engineering
Engineering Liquidity: Babcock’s Blueprint for Cash Management Efficiency

Babcock International, a British multinational defence, aerospace, and engineering services company, transformed its cash management by consolidating 25+ banking relationships into a 14-currency pool with BNP Paribas, gaining 95% global cash visibility and reducing costs. The six-month project combined technical upgrades (SAP, ISO 20022) and change management to transition subsidiaries to intercompany loans, backed by leadership alignment.

The result: lower operational friction, automated processes, and a strategic treasury function, with adaptability for regional needs.

Read more

Appendix XXXV - Tax Payment list (PLN)

View appendix in PDF

This appendix provides detailed specifications for tax payments to the Tax Offices of Poland. The following table outlines the structure and content of the remittance information, including the payer identifier, type of payer identifier, period, and type of tax. These specifications are mandatory for tax payments to the Tax Offices of Poland and must be followed to ensure accurate and efficient processing of tax payments. The tables below provide a breakdown of the required fields and their formats.

Position

Description

Content

1-14

Payer

identifier

Minimum 4 and maximum 14 characters

This filled must contain one of the following types of ID 

numbers used for TAX identification in Poland:

  • NIP: National TAX identification number 

  • REGON: National identification number company

  • PESEL: Personal ID number 

  • ID Card Number 

  • Passport Number 

  • Other ID Number 

after “Payer

identifier”

Space

1 character  = space

 

after “space”

Type of Payer

identifier

1 character. 

The ‘Type of Payer identifier’ should be the value 

corresponding to the identifier inputted just above. The following table describes what character must be 

used for each type of identifier:

  • N – if NIP 

  • R – if REGON 

  • P – if PESEL 

  • 1 – if ID card number

  • 2 – if Passport number

  • 3 – if Other ID number

after “Type of

payer

identifier”

Space

1 character = space

 

after “space”

Period

Tax period concerned - maximum 7 characters

The period value can be given in one of the following 

formats:

  • yyR

For example: 25R - Tax is being paid for year 2025

  • yyKqq

For example: 25K02 - Tax is being paid for quarter 2 of 2025. 

  • yyMmm

For example: 25M10 - Tax is being paid for 10.2025. 

  • yyDkkmm 

For example: 25D0210 - Tax is being paid for days 10-20 

(second 10 days) of 10.2025. 

  • yyJddmm 

For example 25J1610 - Tax is being paid for the 16th day

of 10.2025.

  • 0 : In case of some tax payments (according to 

tax law) value ‘0’ can be inputted in period filled. These 

are payments which are not paid for a given period /  

day. 

The Legend is:

‘yy’: 2 digits for year

‘qq’: 2 digits for one of the quarters: 01, 02, 03 or 04. 

‘mm’: 2 digits for the month number.

‘kk’: 2 digits for: 01, 02 or 03 for each 10 days of the

month.

after “Period”

Space

1 character 

after “space”

Declaration

Declaration filled contains the “symbol of TAX payment 

type”

For example: PIT (Personal Income Tax), CIT (Corporate Income Tax), VAT (Value Added Tax)

Maximum of 7 characters.

1-21

Comments

Free text (optional) or only string ‘/TAX/’ on the second line of remittance.

Maximum 21 characters 

1-5

End line

If 2nd line contains optional comments, except ‘/TAX/’, then the End line 

must contain ‘/TAX/’.

Maersk
Maersk Reshapes its Eurozone Cash Management

Maersk has streamlined its eurozone cash management by consolidating hundreds of bank accounts into a centralised structure built around one euro account. With BNP Paribas, the company implemented virtual IBANs and zero-balancing to centralise liquidity while maintaining clear segregation of entity-level flows. The approach simplifies operations, strengthens liquidity control, and creates a scalable treasury model for Europe.

Read more
Hygiene
Essity’s One Treasury Ethos Powers Progress

Essity, a global hygiene and health company, has transformed its treasury through decades of innovation, achieving 99% straight-through processing (STP) with its centralised “One Treasury” model that integrates treasury, shared services, and external partners. Together with partners such as BNP Paribas, Essity has implemented solutions like DNLevel3, ICEM, and AtlasFX, creating a highly automated system and process environment where treasury can focus on strategy, risk management, and global cash flow efficiency rather than manual tasks.

Read more
Subscribe to