Addressing ISO20022 with sender and receiver distinguished names (DN)

Posted on Jun 16, 2016

When communicating with ISO15022 SWIFT FIN messages the sender and receiver where always specified in the blocks 1 and 2 of the message. These values where known as Bank Identification Codes more commonly named BICs


A BIC is an 8 character long unique identifier for all BANKs on the SWIFT Financial network. It is the Banks messaging equivalent of an address. A specific branch of a bank can also be defined with 3 further characters making a BIC 11 code whereby the default code XXX is commonly used as general Identification.

Example BICs

Credit Suisse: CRESCHZZXXX

As SWIFT is the owner of the network, all participating banks are registered a unique BIC which is then listed in a BIC reference directory by SWIFT. This directory can be purchased for download and use to feed bank internal addressing tools. See for more details on the options.

So in the world of FIN and ISO15022 addressing of messages was generally straight forward. Each bank has a BIC and the BICs are listed in a central list maintained by SWIFT.

Distinguished Names DNs

The ISO20022 standard however changes this. BICs are generally replaced with Distinguished Names (DNs).

Distinguished names originate from the LDAP (Lightweight Directory Access Protocol) where they are used to unique identify each element in a Hierarchical Directory structure. LDAP is the basis for many network directories for example windows domains. If you work in a corporation or larger company, you are most likely readying this from a PC within an LDAP managed active directory domain and both you as user and your PC/Laptop have unique distinguished names which are registered and maintained in central directories or domain controllers.

To enable ISO20022 to work for multiple use cases and independent of networks, the general convention is to use DNs to specify sender and receiver information.

Example DN (For the FUNDs service)

Credit Suisse: cn=invfunds,ou=80a,o=creschzz,o=swift

DN Structure

A DN follows a hierarchical naming principle. In the example above the top level is SWIFT followed by the BIC 8 of the BANK and then specifying further levels to help route the message to the correct internal recipient of the bank.

DNs consist of LDAP attributes like cn (common name) ou (organizational unit) uid (user identifier) and o (organization). These are given in comma separated order of hierarchy whereby the left value is the lowest most local and specific identifier moving up to the value on the right which is the top level parent.

All values should be written in lowercase.

See for more generic information.

DNs registry for MX messages.

A central element of a distinguished name is that it is an identifier within a directory. As such the value of the DN is strongly bound to the usability of the directory to which it belongs. In case of ISO20022 messages this is unfortunately not solved in an optimal way. The main reason for this is that there is no central network on which ISO20022 messages are to be exchanged. As such it is up to each group which organizes communication, to also organize addressing.

ISO20022 messages used on the SWIFT Network are also called MX messages. MX messages are coordinated into SWIFTNet services. Services are defined by SWIFT based on market requirements and group messages related to certain business areas such as FUNDs which can then be sent via SWIFT on the FUNDs specific service (swift.if.ia). When participants register for a SWIFTNet service, they also define one or more DNs that can then be used to identify the participant within the service. This list of previously registered participants is available for download on SWIFT for users with a SWIFT login.

So DNs are services specific and must be used with the matching service and messages.

Get SWIFTNet DNs list

To get a list of DNs from registered participants of a SWIFTNet service go to the Swift homepage and login.

swift services list

under My Tools, choose SWIFTNet Services Directory

This opens the services list overview. To find the actual DN list first choose the Service of choice.

Services List

! Please note that this list does not contain all the services that are valid on the SWIFT Network. Numerous exceptions exist where the SWIFT Network is used for messaging but where a third party is service owner. Examples are the T2S service owned by the EU Central bank or service owned by VP Securities of Denmark. !

Once the correct service and service type has been chosen, verify that the List Type is set to Destinations and run the search.Services

The returned list contains all registered participants with their DN of choice.

The download provides a csv file that can be processed and used to feed internal messaging applications.



Best Practices when registering your own DN in a SWIFT Service

Please refer to your local market practice guidelines for the service in question. It is quite likely that the market you want to communicate with has already defined common patterns for the DN.

If not please note that as the service is running on the SWIFT Network you will have to us the convention of o=[your BIC],o=swift as minimal mandatory pattern.

In addition to adhering to the minimal standard I strongly recommend that you specify a unique DN for each service on which you register. One way of doing this which also offers minimal interchangeability with the ISO15022 standard is to include a branch code relevant to the service in the DN. For example ou=80a,o=creschzz,o=swift

If is also valuable to include a speaking reference to the service within the DN. So in the example above from credit suisse cn=invfunds,ou=80a,o=creschzz,o=swift

It is strongly recommended not to use more than 4 hierarchy elements in your DN.