Currency: Danish krone (DKK)

RTGS: Kronos2 for DKK payment and Target2 for EUR payment

Message format currently in use: SWIFT MT

Coexistence vs big Bang approach: Big Bang approach

ISO migration planned? Timeline: For the payment settled in EUR, it will go through Target2 which will migrate in November 2021, therefore it will be a Big Bang approach, see above for the specifications.

Concerning the payment settled in DKK, it will go through Kronos2. For Kronos, there is no sign of a potential migration to ISO20022. Based on a report published in 2016 by the Danmarks National Bank, Kronos2 will observe the same standards and procedures as Kronos, but will also be compatible with the newer ISO 20022 standard. However, in consultation with the market, it has been decided not to switch to the new standard immediately.[1]

Denmark DKK ISO migration

Governing body of the migration: European Central Bank for Target2 and Danmarks National Bank for Kronos2.


Messaging format:

The European HVPS messaging format has been published by the ECB and is available in MyStandards in the T2 RTGS group. Access is automatically granted if requested. The current latest version is UDFS 2.1, which was released in December 2019. UDFS 2.2 is expected to be published in November 2020 and will incorporate the final change requests.

The Eurosystem supports ISO messages for payments and associated reporting and recall requests through the TARGET2 module, securities processing through the T2S module, as well liquidity management through the CLM module.

Batch Payments: Each pacs.008 can only contain a single credit transfer, TARGET2 and EBA Clearing will not support batch payments.

End-to-end identification: if provided in the payment instruction, should be carried throughout the payment chain. If none is provided, the value NOTPROVIDED should be used. This should not be confused with SWIFT’s UETR, and cannot be mapped to MT messages.

Structured Party Information:

The following two rules related to parties (eg. debtor, creditor, ultimate debtor, ultimate creditor) in UDFS 2.0, when taken together, result in the requirement to submit structured addresses:

  • If OrganisationIdentification/AnyBIC and LEI are absent then Name, TownName and Country are mandatory to identify the Debtor
  • If PostalAddress is used and if AddressLine is present, then all other optional elements in PostalAddress must be absent.

UDFS 2.1 did away with the requirement to use structured addresses, with several national banks commenting that this requirement would likely be reinstated at the end of SWIFT’s coexistence period in 2025.

Structured Remittance Information is supported by UDFS 2.1 and allows for up to 9000 characters of structured remittance information, tags not included. Structured remittance information cannot be mapped to MT and can provide essential information for compliance and reconciliation purposes. Banks should ensure they are not truncating remittance information, and take into account that extended remittance information can significantly bloat message sizes. Banks should ensure they either isolate their payment systems are adequately dimensioned.

Purpose Code

Ultimate debtor/creditor: Ultimate creditor and debtor information is enabled, as well as instructing party. None of these fields can be structurally mapped to an MT message. Passing this information down the chain is not only essential for reconciliation by corporate customers making use of payment/collection factories, but a legal requirement for correspondent banks in light of FATF recommendation-16.

Tax: Unlike in CBPR+ messages, Tax fields are not supported.


[1] (p.57)