Skip to main content
Question

Structured Payment Requirement (Creditor tag) - Employee Payments

  • May 26, 2026
  • 2 replies
  • 65 views

Forum|alt.badge.img+2

The bank confirms that new MTMX / ISO 20022 requirements will become effective as of 1 October 2026.

The key requirement is that postal addresses must be provided in a structured format going forward.

The unstructured address field PstlAdr/AdrLine will be ignored by the bank’s system.

The following fields will become mandatory:

  • PstlAdr/TwnNm (Town Name)
  • PstlAdr/Ctry (Country)
  • PstlAdr/CtrySubDvsn (only mandatory for payments to Canada)

According to the bank’s feedback, this requirement is limited to the Creditor section. For both suppliers and employee payments (since this is handled in the same way for the bank).

 

Issue:

The default Employee Payments API file does not have detailed postal sections (in comparison to the supplier payment file) and the default transformer cannot put a detailed Postal Address in the Creditor Section. Why does the employee payment file not have creditor detailed postal address data as default in structured way (town and country)? And what is the solution for the new bank requirement?

Overview – Structured Address Requirements (ISO 20022, Nov 2026)

1. Background

  • ISO 20022 payment messages (pain.003.001.x) are transitioning from unstructured (free‑text) to structured or hybrid postal addresses.
  • As of 22 November 2026fully unstructured address usage (AdrLine only) will no longer be allowed for SEPA and cross‑border payments.

 

2. Structured vs. Unstructured Addresses

Unstructured Address

  • Uses free‑text fields (e.g. AdrLine or <Ustrd>).
  • Example: “123 Main St, London”.
  • Being phased out due to poor validation and compliance handling.

Structured Address

  • Uses dedicated XML elements for each address component.
  • Mandatory fields (even in structured formats):
    • TwnNm (Town Name)
    • Ctry (Country)

 

3. Example of Structured Address (pain.003)

<Dbtr>

  <PstlAdr>

    <Ctry>GB</Ctry>

    <TwnNm>London</TwnNm>

    <StrtNm>Main St</StrtNm>

    <BldgNb>123</BldgNb>

    <PstCd>EC1A 1AA</PstCd>

  </PstlAdr>

</Dbtr>

 

  • Stop using AdrLine only; rely on dedicated address elements instead.
  • Town and Country must always be populated.
  • Payments containing only unstructured addresses risk rejection after Nov 2026.

2 replies

Forum|alt.badge.img
  • Do Gooder (Customer)
  • June 23, 2026

 hi ​@marie.peltot ! we have tried to extract this new format by enabling two checkboxes (we have also tried one at the time):

  • Detailed Postal Address in window Format Specific Info per Institute
  • Show Detailed Postal Address of Payee in window Payment Address (Supplier specific)

we haven’t managed to get this format correct even though the Help text for Show Detailed Postal Address of Payee says that these tags should be used, see below.

do you know if we need to modify or update the XML?

we are using App10 UPD 26 and XML version 001.001.03.


Forum|alt.badge.img+2
  • Author
  • Do Gooder (Partner)
  • June 23, 2026

@joaborkla Hi,

For supplier payments, putting the two checkboxes you mention on should work to be alligned with the requirement to have the country and townname filled in for Creditor structure in the payment. For expense payments to employees this does not work as the standard API file before transformation does not show any detailed postal address structure, this is lacking in the core IFS file. Because of this issue I created a ticket to IFS and they will fix it in one of the following service updates.

If you still work with APPS10 this will require a CRIM to for example use the employee properties to store employee town and country, and adapt and change file before transformation and transformer to be alligned with the requirement.

Let me know if you would have more questions.