Appendix XXXVII - Purpose of payment code (UGX)
| S.No | Purpose of payment Description | Code Value |
| 1 | Salary Payment | SALA |
| 2 | Tax Payment | TAXS |
| 3 | Value Added Tax Payment | VATX |
| 4 | Insurance Premium | INSU |
| 5 | Loan Repayment | LOAR |
| 6 | Refund | REFU |
| 7 | Dividend | DIVD |
| 8 | Pension Payment | PENS |
| 9 | Bank Loan Fees | BKFE |
| 10 | Cash Management Transfer | CASH |
| 11 | Collection Payment | COLL |
| 12 | Deposit | DEPT |
| 13 | Intra Company Payment | INTC |
| 14 | Intra Party Payment | INTP |
| 15 | Agricultural Transfer | AGRT |
| 16 | Business Expenses | BEXP |
| 17 | Commercial Payment | COMC |
| 18 | Copyright | CPYR |
| 19 | License Fee | LICF |
| 20 | Royalties | ROYA |
| 21 | Service Charges | SERV |
| 22 | Subscription | SUBS |
| 23 | Supplier Payment | SUPP |
| 24 | Commercial | TRAD |
| 25 | Charity Payment | CHAR |
| 26 | Mobile P2P Payment | MP2P |
| 27 | Guaranteed E Payment | ECPG |
| 28 | E payment | EPAY |
| 29 | Compensation Payment | COMP |
| 30 | Government Insurance | GOVI |
| 31 | Property Loan Repayment | HLRP |
| 32 | Property Loan Settlement | HLST |
| 33 | Insurance Premium Car | INPC |
| 34 | Insurance Premium Refund | INPR |
| 35 | Payment Of Insurance Claim | INSC |
| 36 | Interest | INTE |
| 37 | Labor Insurance | LBRI |
| 38 | Life Insurance | LIFI |
| 39 | Loan | LOAN |
| 40 | Advance Payment | ADVA |
| 41 | Costs | COST |
| 42 | Debit Card Payment | DCRD |
| 43 | Education | EDUC |
| 44 | Gift | GIFT |
| 45 | Government Payment | GOVT |
| 46 | Installment | INSM |
| 47 | Invoice Payment | IVPT |
| 48 | Payment Terms | PTSP |
| 49 | Receipt Payment | RCPT |
| 50 | Rebate | REBT |
| 51 | Rent | RENT |
| 52 | Study | STDY |
| 53 | Instant Payments | IPAY |
| 54 | Annuity | ANNI |
| 55 | Derivatives | DERI |
| 56 | Savings | SAVG |
| 57 | Securities | SECU |
| 58 | Treasury Payment | TREA |
| 59 | Allowance | ALLW |
| 60 | Bonus Payment. | BONU |
| 61 | Commission | COMM |
| 62 | Payroll | PAYR |
| 63 | Price Payment | PRCP |
| 64 | Estate Tax | ESTX |
| 65 | Housing Tax | HSTX |
| 66 | Income Tax | INTX |
| 67 | Property Tax | PTXP |
| 68 | WithHolding | WHLD |
| 69 | TaxRefund | TAXR |
| 70 | Air | AIRB |
| 71 | Bus | BUSB |
| 72 | Ferry | FERB |
| 73 | Railway | RLWY |
| 74 | Energies | ENRG |
| 75 | Utilities | UBIL |
| 76 | Lottery Payment | LOTT |
Appendix XXXVI - ISO 20022 Structured adress
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
| Date | Action Required |
| November 2025- November 2026 | Transition period: All 3 formats (unstructured, semi-structured, structured) are accepted. |
| 14 November 2026 | Fully 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
Appendix XXXV - Tax Payment list (PLN)
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:
| |
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:
| |
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:
For example: 25R - Tax is being paid for year 2025
For example: 25K02 - Tax is being paid for quarter 2 of 2025.
For example: 25M10 - Tax is being paid for 10.2025.
For example: 25D0210 - Tax is being paid for days 10-20 (second 10 days) of 10.2025.
For example 25J1610 - Tax is being paid for the 16th day of 10.2025.
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/’. |





