The SWIFT 2026 Standards Release introduces mandatory regulatory changes that will take effect globally on 14 November 2026. 

These changes impact SWIFT MT and MX messages, associated directories, and all corporate and interbank communication channels that rely on SWIFT standards, including 

• SWIFT Interbank changes in MT messages in categories 4 (Collections) and 7 (LC and Guarantees), 
• SWIFT Score, 
• EBICS (DTA), 
• RIVO,
• CBPR+ Changes in MX messages,
• TARGET2 Changes in MX messages, 
• SEPA Changes in MX messages, and 
• Bolero.

Major Areas of Changes:

1. Structured Name and Address Information.
2. Unstructured name and address fields of non-financial parties in MT messages will not be permitted after November 2026.
3. Existing address blocks are replaced by separate, structured tags (Name, Street, City/State, Post Code, Country).
4. These changes affect core Trade Finance parties such as Applicants, Beneficiaries, Obligors, and Drawees across LC, Guarantee, and Collection messages.
5. Multiple fields are revised or extended (e.g. shipment routes, instructions to banks, drafts, charges).
6. New optional fields are introduced, such as HS Code and Incoterms.
7. Character set changes (from X to Z) and increased field lengths improve expressiveness but require system readiness.
8. New and revised NVRs enforce stricter message validation (e.g. conditional field presence).
9. Unstructured Postal address removed for CBPR+ messages from November 2026.

SWIFT Activation Settings in DOKA: 

SWIFT 2026 functionality can be activated via central switches. The new functionality can be switched on / switched off, allowing to view and test the functionality before the activation date in November 2026.

Switch ON: 
To activate the new logic, configuration parameters are available in transaction ‘Maintaining System Configuration (DBxSYS)’ on panel ‘Regulatory.’ To test for ‘SWIFT 2026 activation’, the date in DBxSYS should be set to a date in the past. This will activate the full SWIFT MT 2026 logic as of the entered date.

Switch OFF:

To deactivate the SWIFT 2026 activation’ logic, the date in DBxSYS should be set to a date in the future, such as the SWIFT MT 2026 going-live date 14. November 2026.

Overview of Changes in MT/MX messages:

1. Address Structure Changes

A) New Address Structure in MT Messages: 

Until now, the name and address of all non-financial institutions in SWIFT messages were shown in a block of 4 lines with 35 characters in character set X each.
This is referred to as ‘unstructured name and address information’ and will only be allowed until November 2026.

Old Address Structure : 

The purpose of the address changes in SWIFT 2026 is to split the existing
tags that represent non-financial name and address in MT messages into 5 individual tags as illustrated below.

Example:

Similarly, 50B (non-bank issuer) has been split into:
 

• 50E (Name)
• 50I (Address)
• 50M (Town/City/State)
• 50U (Post Code)
• 50W (Country)

The change is affecting mainly the tags 50 (Applicant), 50B (Non-Bank Issuer), 51 (Obligor) and 59 (Beneficiary/ Drawee) in the LC, Guarantee and Collection messages. Previously, tags such as 59 allowed an optional subline for the account.
Now, Name and Address fields for non-financial parties do not have this optional account line anymore. 

Address-related changes have been implemented only for parties and tags that were supported prior to SWIFT 2026. For example, in MT740, tag 59 was not included in outgoing messages before SWIFT 2026, and this behavior remains unchanged. Consequently, changes have been applied exclusively to tags that were supported prior to SWIFT 2026

Impacted Messages: 

B) Address Structure in MX Messages: 

Since November 2025, outgoing MX messages can be generated in either hybrid or fully structured format and are used in the payment messages pacs.008/ pacs.009 that replaced the former MT103/ MT202. Though the fully structured will be the preferred format in the future, a hybrid address format is introduced indefinitely.
The hybrid format in CBPR+ MX messages uses the same DOKA fields as the structured address fields that SWIFT is introducing for MT messages in November 2026.
Therefore, it is necessary that the banks have received the party address changes in DOKA either with the CBPR+ changes in 2025 or with the address master when starting the SWIFT 2026 project.
It will not be possible to send unstructured addresses anymore after Swift 2026 release.

C) Impact of Address Changes in DOKA : 

The following areas are impacted by the above address structure changes.

• Party (DBxPTY) 
• Party Address static data (DBxPTA)
• Interfaces / Imports 
• Address information in business transactions
• Letter correspondence 
• Existing deals

Party (DBxPTY) and Party Address (DBxPTA) Static Data: 

The party information in the static data maintenance transactions (DBxPTY, DBxPTA) panels display all necessary fields for MT addresses.

Static Data Party Panel: 

The upper part of the panel displays the fields that are required for MT messages and the creation of MX payment messages in hybrid format. In line with CBPR+ and SWIFT MT specifications, additional fields are added, e.g. NAM 4 and STR3 and STR4. The lower part of the panel (ISO 20022 Fully Structured Payments Fields) contains all the fields for the ISO postal address which are required for fully structured CBPR+ messages. 

The layout of the panels ‘Address Info’ and ‘Add. Details’ are revised and additional fields for fully structured CBPR+ are added.

Address Information in Business Transactions:

There are only minor changes to the layout of the main transaction panels in business transactions. In all business transactions the new address fields are displayed in popup panels.

 For example, the ‘Overview’ panel in transactions will still display the address block of the parties.

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

Business Transaction – New Address Fields :

Additional information can be entered when toggling to the next panel using the button ‘More.’

Business Transaction – Address Fields Additional Info:

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.

Business Transaction- Address Block Sample:

By clicking the 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.

When the user clicks on the icon , a popup panel is displayed that allows the user to compare contract information from incoming messages against the current or old database address information. This comparison is also enhanced with the new address fields. The individual address fields such as Name, Street etc. can be modified by the user. If the individual address fields are modified by the user then the address block needs to be updated using the icon added next to it.

Display functions in all searches and show modules that display address information will be updated to include all the new fields.

Letter Correspondence : 

The receiver’s address information in outgoing letters can be configured by the bank to a format that includes the desired fields. The maintenance transaction for the Entity address (DBxETA) contains several predefined format options for domestic and international letters (Address Type A- D). An ‘Address Type F’ is added that allows the bank to freely define their own format.

DBxETA- Receiver Address Format

Existing Deals

It is not expected that existing deals need to be updated as the address information in static data already contains the fields that are mandatory in SWIFT MT and MX messages. If the pre-existing party address in DOKA does not include mandatory Swift elements (e.g., Address Line or Town/City), the system will prevent generation of MT700/MT760 messages. In such cases, an MT799 message is being sent instead and the warning mentions the missing Swift tags.

Overview of Changes in LC Module:

1) Shipment Route - Format Changes for Tags 44A, 44B,44E, 44F : 

The format of fields 44A, 44B, 44E, and 44F which contain the shipment route is changed from 1*140z to 2*70z. In the Business Sectors Import, Export and Transfer LC (LI, LE, LT), four new Database fields are created in addition to the ones detailed below with the SR2026 format and size specifications for Tags 44A, 44E, 44F, 44B. 

•  'Dispatch from' 44A 
•  'Air-/Port of Departure' 44E 
•  'Air-/Port of Destination' 44F 
•  'Final Destination' 44B

Shipment Fields

The “old” fields are located on the Details panel, but a new panel dedicated to Shipment Details is designed in LI, LE and LT considering that now each field will have 2 lines, and the full content of the fields should be displayed when Swift2026 is active.
 

The new panel shows the new fields and the field shipment period. The old fields are invisible on the Details panel. The old fields are invisible on the Details panel. The content of the new fields is defaulted with existing values from the old fields, if there was content in the old field.

If the new fields have defaulted content with more than 70 characters, a warning is added that checks if any previously existing information is truncated. The 70 characters for the first line are validated based on space after each word and then the content is moved to the next line. See screenshot below for better understanding:

Affected messages:
The new fields are used in the following outgoing messages when SWIFT 2026 is active. On the incoming side, the alternate mapping is adjusted to the new fields.

2) New Tag 44I ‘Incoterms': 

A new optional tag ‘Incoterms’ (format 3! a/2*70z (Code) (Narrative*) is added to the business sectors Import, Export and Transfer LC (LI, LE, LT).
The field ‘Incoterms Code’ includes the list of allowed codes according to the SWIFT specification. The list includes all common codes and the possibility to select a code ‘OTH – Others.’
Codes:
EXW Ex Works , FCA Free Carrier, FAS Free Alongside Ship, FOB Free on Board, CPT Carriage Paid To, CIP Carriage and Insurance Paid to, CFR Cost and Freight, CIF Cost, Insurance and Freight,  DAP Delivered at Place, DPU Delivered at Place Unloaded,  DDP Delivered Duty Paid, OTH Others

The field ‘Incoterms Place’ is defined as a textfield of 2*70z. This field is optional and only allowed, if ‘Incoterm Code’ is entered. Otherwise, the field is disabled and the content is cleared. Both fields are added to the panel ‘Shipment details’ above the other shipment route fields.

If the optional Incoterms fields are filled, then the content of this field is printed in tag 44I. The following messages in the business modules Import, Export and Transfer LC are affected:

3. New Tag 45H HS Code:

A new optional field “HS Code” (format 1*65x) is added to LC and Guarantee messages. The HS Code field specifies the respective Harmonized System Code(s) of the covered goods.
A new database text field is created in the business modules Import, Export and Transfer LC and Guarantees.
In the LC modules, the field is positioned on panel 'Goods'. In the Guarantees module, it is positioned in the 'Details' panel (of Seq B and Seq C). The field is displayed only when SWIFT 2026 is active. The content of this field is printed in tag 45H of the outgoing SWIFT message.

4. Tag 42C ‘Drafts at .  Updated Character Set : 

The character set of tag 42C ‘Drafts at…’ is changed from 3*35x to 3*35z. The existing field ‘Drafts at’ (DFTAT) which is located on the Details panel in the business modules Import, Export and Transfer LC remain as is.
When SWIFT 2026 is active, the content of tag 42C in the outgoing messages is printed with character set z format. On the incoming side, incoming messages containing character Z in Tag 42C will be uploaded and mapped accordingly.

5. Tag 78K Instructions to Paying, Accepting Bank : 

The new field is located on panel ‘Additional Conditions’ and Instructions to Paying, Accepting, Negotiating Bank’ in amendment transactions under Import, Export, Transfer LC and Participation. In the messages, the new tag 78K will be used when SWIFT 2026 is active and if the field contains data.

6. MT707 - Tag 71N ‘Amendment Charge Payable By‘ : 

Field 71N ‘Amendment Charge Payable By’ in message MT707 in the import and export LC module has changed the name of the code ‘OTHR’ from Other party to Other arrangement.
In DOKA, the code name is ‘Other’, and it is available in the panels where ‘Amendment charge by’ field is present. Additionally, the code ‘OTHR’ or word ‘Other’ is printed in the correspondence depending on its type. Considering that the word ‘party’ was not part of the name or printed in the correspondence, no changes are required within the application.

7. Tag 71D Charges New Definition: 

The field definition for :71D: ‘Charges’ in MT 700, MT 707, MT 710, and MT720 are revised to "This field may be used to specify the party(s) responsible for the documentary credit charges" instead of "This field may be used only to specify charges to be borne by the beneficiary."

8. MT710/MT720 Tag 78D Updated Character Set:

The format of field 78D (Instructions from intermediary/transferring bank) is changed from 12*65x to 12*65z.
Tag 78D in MT710 and MT720 refers to the field '78D (Instructions from Intermediary bank' in DOKA.
The field is displayed on the panels ‘Further Bank Instructions’ and ‘Transferring Bank Instructions’ in Export LC and Transfer LC. The panels will be visible only when the checkboxes for ‘Instructions from 3rd Bank (:78D:)’ / ‘Instructions from Transferring Bank’ in the Additional Conditions panel of the business transactions ‘Advise Export LC (LETOPN)’ or ‘Open Transfer LC (LTTOPN)’ are selected. With SR2026 the fields allow character set Z instead of character set X.

Overview of Changes in Guarantee Module:

     1. MT760 Tag 44J Split into Separate Fields 44J & 44P:

The current tag 44J (Governing Law/Jurisdiction) is now split into two separate fields: 

• Governing Law (44J) 2!a[/35x] (Country Code) (Country Subdivision)   Optional and 

• Place of Jurisdiction (44P) = 65x Narrative Conditional 

  This change is accompanied by a new Network Validation Rule (NVR), that stipulates ‘if 44P is present, then field 44J must be present.
  The Jurisdiction fields are 3 individual fields in DOKA-NG, hence no change is needed on the panels. 
   

The outgoing messages are adjusted to include the new / revised tag content in both sequences. The incoming messages are updated (for both Seq B and Seq C). 

2. MT760 – New Rule for Tag 23 ‘Advising Bank’s Ref:

A new Network Validated Rule (NVR) is added for tag 23 of MT760:
‘In sequence A, if field 22A is ACNF or ADVI, then field 23 in sequence B may be present, otherwise field 23 is not allowed.’
Tag 23 is printed in the outgoing message only when purpose of message is ‘ADVI’ or ‘ACNF’ i.e. when the message is sent to another advising bank. 
In the Outgoing MT760, OWNREF is printed in tag 23. During transaction processing, OWNREF is not yet available; therefore, NONREF is initially printed in Tag 23 and later updated with OWNREF in the Workflow 
Manager.
For Incoming MT760 with ADVI or ACNF with reference number of Advising Bank :56a present in tag 23 to be mapped to reference of ADA in additional parties.

Affected Messages:

3. MT760 Applicable Rules Tag 40C NVR Rule:

The NVR for tag 40C of only Seq. B is changed from ‘If Type is OTHR, then Narrative may be present, otherwise Narrative is not allowed’ to ‘If Type is OTHR, then Narrative must be present, otherwise Narrative is not allowed.’
The change refers to the field ‘Applicable Rules’ for Sequence B only. The field is located in the Guarantees module on the ‘Overview’ panel, e.g. in the opening transaction. 
In case none of the existing Codes ISPR, UCPR or URDG are suitable for the Guarantee, then Code OTHR can be selected and a free text field for further specification opens. 
In DOKA-NG this free text is already mandatory if the Narrative text field is available. Tag 40C is already printed in the correct format in the Guarantee issuance message. Therefore, no change in DOKA-NG is necessary as this 
free text is already mandatory if the Narrative text field is available. 

4. New Tag 45H HS Code:

The new tag 45H is added to the Sequence B and Sequence C of MT 760 Guarantee issuance messages.

5. MT765 - New fields for ‘Claiming Charges’:

New optional tags 71D Charges and 33a Total Amount Claimed are added to MT 765. 
In the ‘Receipt of Claim’ transaction within the Guarantee module, the ‘Advice of Claim’ message sent to the payer includes the following new tags:

• Breakdown of charges settled in tag 71D.

• Total Amount Claimed in tag 33a being the sum of charges plus Demand Amount (i.e. Amount Claimed + Drawn Additional Amounts). 
   

  On the outgoing side, the information is printed in the outgoing MT765 or their respective message equivalents and on the incoming side, the information is listed in unmapped fields.

CBPR+ Changes : 

The following chapter contains an overview of changes relevant for existing SWIFT CBPR+ messages.

1. Retirement of Unstructured address – All messages 

After the SWIFT Release, unstructured postal addresses will no longer be supported for CBPR+ messages. Only Hybrid or Fully Structured addresses can be sent.
If the activation date for Fully Structured address is set in DBxSYS, a Fully Structured address is sent from that date onwards; otherwise, a Hybrid address is sent.

DBISYS Activation - Fully Structured Address 

DBxPTY and Fully Structured address vs Hybrid address: The Party Information section in the upper part of the Static Data Maintenance (DBxPTY) transaction panel displays the fields required for MT messages as well as the Hybrid Address for payment messages.                                                        DBxPTY - Hybrid address

For Hybrid address, the address line 1 and 2 are populated from the Address fields maintained in the upper part of the panel.  

The lower part of the panel (ISO 20022 Fully Structured Payment Fields) contains all the fields which are required only for fully structured addresses in payment messages.

2. Business Application Header (BAH) Changes – All     messages

“Business Service” in Business Application Header (BAH) becomes a mandatory “constant” header value enforced by validation, replacing the old textual rule. This means that all CBPR+ messages now must use the fixed value (example: swift.cbprplus.04) as mentioned by SWIFT in element Business Service in BAH (/AppHdr/BizSvc).