Changes in Party / Addresses

The party address fields and panels in static data and in the business transactions have been redesigned. 

Under the framework of ISO20022, this is reflected in the hybrid and fully structured CBPR+ messages which will become the future in payment messages as of November 2026. As of this date, it will not be allowed to send unstructured address information anymore.

In the light of these upcoming / expected changes, the party address information is extended to the additional fields required.

• Party Address information in static data (DBxPTY) / (DBxPTA)

The upper part of the panel displays the existing DOKA-NG party fields that are also required for MT messages. Here a few additional fields are added, e.g. a 4th line for the name, and a 3rd and 4th line for the address.

The fields in the upper part of the panel are typically used in SWIFT MT messages, hybrid CBPR+ XML messages and letter correspondence.

The lower part of the party details panel contains all the fields for the ISO postal address which are required only for fully structured CBPR+ messages.

Party panel in static data (DBxPTY)

 

The layout of the panels “Address Info” and “Add. Details” have been revised and additional fields for fully structured CBPR+ have been added, e.g. “Clearing System ID Code”, “Other Organization ID” fields and “Private Individual Information”.

Address Info in static data (DBxPTY)

Additional party details in static data (DBxPTY)

Reports, List files and the info transaction (INFPTY) are also enhanced with all new fields for parties.

In line with the static data of parties (DBxPTY), also the party addresses (DBxPTA) are updated in a similar format.

Address Association in static data (DBxPTA)

Address Information in static data (DBxPTA)

• Address information on business transactions

The new address fields will be displayed in popup panels in all business transactions. The “Overview” panel in transactions continues to display the address block of the parties.

Address block in Overview panel of business transactions (without data)

When a new temporary address is created in the database (using the “+” icon), a new popup panel is displayed that contains all the new address fields.

Creating a new temporary party in business transactions (1/2)

Additional information can be entered when toggling to the next panel using the button “More”.

Creating a new temporary party in business transactions (2/2)

When an existing party is selected from the database, the “+” icon is exchanged with a new icon that allows the user to view the party address details.

By clicking the new icon , a popup panel opens, that displays the address details of the selected role. The main information is on the first panel. If needed, the user can toggle back and forth between the popup panels.

Viewing a loaded address in business transactions (1/2)

Viewing a loaded address in business transactions (2/2)

 

Incoming Message: 

When the user clicks on the edit icon , a popup panel will be displayed that allows the user to compare contract information from e.g. incoming messages against the current or previous database address information.
This comparison is enhanced with the new address fields where the new/modified address information is compared with the old / database information side by side.

Editing and side by side comparison of addresses in business transactions (1/3)

The fully structured CBPR+ fields can be compared in a similar way by clicking the “CBPR+” button.

Side by side comparison of CBPR+ addresses in business transactions (2/3)

 

Address Details in business transactions (3/3)

Usage in Letter Correspondence: 

When used in letter correspondence, the built-in address format is used unless configured differently for the entity address or the receiver country. The built-in format consists of name line 1-3, address line 1-2, zip code, city and optionally the country.

 

It is possible to define the format that is used to print the receiver address in letter correspondence differently. In the Entity address maintenance transaction (DBxETA), the user can select from various predefined address formats or define their own preferred format for domestic or international receivers.

Usage in SWIFT MT messages:

When used in SWIFT MT messages, the address block, e.g. tag 50 of the MT700 prints 1st and 2nd line of the name + 1st line of the address + Country, Zip code and City.

There is no change to the existing functionality as the SWIFT standard in MT messages for the category 4 and 7 remains unchanged.

Example of the address block in a MT message

• CBPR+ payment messages in XML format

Under the ISO20022 framework, CBPR+ payment messages that were previously sent via a MT103 or MT202 message must be sent as XML messages in either a pacs.008 or pacs.009 format starting November 2025.

This being a major change to the payment industry, a transition period was started in 2023, and banks could opt for an early move towards xml. November 2025 now marks the end of the transition period and as of this date, banks cannot send payment messages in MT format.
When the xml messages were introduced in 2023, the address information of parties was transferred in an unstructured manner, meaning that all information in the postal address was transferred via the <AdrLine> element, leading to difficulties in interpreting the data and co-mingling of address elements.

As of November 2026, unstructured information will not be allowed anymore and must be replaced with either the hybrid or the fully structured address format.
The hybrid or fully structured address will be optionally allowed for early adopters from November 2025 onwards.

New Address structure in MX messages

In the future, the fully structured format will be the preferred format according to SWIFT. However, it will be possible to use the hybrid format for an indefinite time.

The hybrid format can be filled with the existing mandatory static data fields in DOKA system.

The hybrid address contains the fully structured fields plus the <address line>. The hybrid format can be used to provide additional information that is not included in the structured address. This additional information can then be given in the <address line>.

In the transaction “Maintaining System Configuration (DBxSYS)” the bank can decide as of which date the hybrid or fully structured format should be used.

Hybrid Address

As of November 2025, a hybrid option will also be allowed. Though intended as an interim format in the migration from unstructured to fully structured, there is no definite end of time for this format.

Hybrid address format allows mixing structured elements (e.g. town and country) and unstructured elements, providing flexibility while transitioning to fully structured formats. In DOKA system, the address fields, i.e. STR1-4 are printed in the <AdrLine> element.

Fully Structured Postal Address

Structured address data refers to a standardized and organized format for representing location information, typically comprising distinct components, such as street name, post code, town and country details. The structured postal address definition in ISO 20022 offers 14 specific attributes, where it is clearly visible what element includes which data.
When used in CBPR+ payment messages using the fully structured format, the postal address is printing all available fields in the structured fields in the postal address:

Pretty print format: 

Raw message format: