Structured ordering and beneficiary

customer data in payments

Market Practice Guidelines

Note:

The Payments Market Practice Group (PMPG) is an independent body of payments subject matter
experts from Asia Pacific, EMEA and North America. The mission of the PMPG is to:

• Take stock of payments market practices across regions

• Discuss, explain, and document market practice issues, including possible commercial
impact
• Recommend market practices, covering end-to-end transactions
• Propose best practice, business responsibilities and rules, message flows, consistent
implementation of ISO messaging standards and exception definitions
• Ensure publication of recommended best practices
• Recommend payments market practices in response to changing compliance
requirements

The PMPG provides a truly global forum to drive better market practices which, together with
correct use of standards, will help in achieving full STP and improved customer service.

November 2019 Version 1.0

Page 1
1 Introduction
1.1 Background
In late 2017, PMPG published the Structured ordering and beneficiary customer data in payments whitepaper,
to bring awareness to the community about the complexity, implications, challenges, drivers, and ‘whole of
community’ impact of transitioning to structured ordering and beneficiary customer data in payment
messages, particularly in the context of the impending elimination of the free format options in FIN fields 50a
and 59a respectively as part of SWIFT standards release 2020. Since then, the community has endorsed
CR001410 (proposed by PMPG as part of SWIFT standards release 2019) to extend the use of the free format
options until the end of the ISO20022 migration coexistence period (circa 2025). The premise is that the
transition to structured customer data “will be both more efficient and more effective if the industry aligns the
requirements for structured data with the adoption of ISO20022 messages in payment markets” rather than
tackle the initiatives independently. The extension of the free format options in no way mitigates the
importance, benefits or underlying need to transition to structured customer data, but rather provides an
opportunity to take a holistic approach to evolving payment messages.

This paper will build on the earlier whitepaper, by:

i. Explaining structured customer data in ISO20022 and SWIFT FIN payment messages;
ii. Providing best practice and use cases for dealing with translation & truncation, aligning with the
important outputs from the Cross Border Payment & Reporting Plus (CBPR+) working group;
iii. Providing guidance on the specific responsibilities of the actors within the payment chain to achieve
completeness, structure, and minimize truncation;
iv. Elaborating on the impacts across the payment community (and considerations for each group);
v. Highlighting what the community should consider before and during the ISO20022 migration
coexistence period.

While this publication aims to help and guide the industry in their efforts towards structured customer data
along their migration of the ISO20022 standard, the PMPG will continue to support to the communities by
updating this market practice guideline document and by establishing additional guidance papers that will
provide more details throughout the stages of the global adoption of ISO20022.

This paper, like its predecessor, will remain focused on ordering and beneficiary customer information
(including ultimate debtor and ultimate creditor).

Illustration 1 – Logical overview of the different format options and the ultimate target state

PMPG Market Practice Guidelines - Structured ordering and beneficiary customer data in payments Page 2
1.2 Importance of aligning the migration towards ISO20022 and structured customer
data as one holistic project

Market Practice Guideline #1: The global community should target November 2023 as the end-date for
unstructured customer information payments, regardless of their format (ISO20022, FIN or native
clearing).

There are strong reasons for the industry to address the challenge of structured data with equal priority, and
approach it simultaneously with the ISO20022 project.

Amongst those:
• The fact that important market infrastructures (MIs), including the Real Time Gross Settlement
Systems in Europe (Target2), in the US (FEDWIRE), in UK (CHAPS) and in Hong Kong (CHATS), will
all move to ISO20022 in the next 2- 4 years. These MIs follow different timelines and migration
approaches. Whereas Target will be moving in a “big bang” migration November 22, 2021 to fully
fledged ISO20022, the FEDWIRE will follow a phased approach starting with a like for like
migration in 2022 and enabling the extended ISO20022 in phase 3 in 2023 only. To support
interoperability, the MIs agreed to align their respective ISO20022 messages with the CBPR+
usage guidelines for the addressing of parties for a limited period of time. The unstructured
address (Address Line element) is expected to be used in rare "exceptions" only after November
2023 and will be removed by end of 2025 with the end of the coexistence phase between FIN and
ISO20022 for payments and reporting messages.
• The CBPR+ Usage Guidelines requires the usage of structured address only, if a payment is
initiated by the debtor’s agent in ISO20022 effective with the start of the co-existence phase in
November 2021
• The unstructured format in ISO20022, unlike FIN, requires a certain level of structure already.
Name and address are dedicated elements in ISO20022, while FIN allows name and address to be
included in a single field (detailed description in chapter 2)
• ISO20022 usage guideline´s mandates the inclusion of the address for the debtor and creditor for
cross border payments with the minimum of country and town. This information, in particular for
the creditor, can only, and therefore must be provided by the initiating customer (the debtor).
• Unstructured data is a material barrier of building robust and efficient transaction surveillance
tools to mitigate sanction and AML risks and will regularly lead to exception handling and
significant delays in payment processing as a result of transaction due diligence (such as filtering,
monitoring) or mapping of data to/from legacy formats

On the other hand, the project will require:

• Review and clean-up of existing party static data for any parties in the payment chain (such as
clients, counterparties, and agents)
• Redesign of any customer payment initiation media and channels (to eliminate unstructured data
option from the point of initiation)
• Client education, and vendor engagement (to ensure counterparty information is delivered in the
target standard)

Based on its nature, the ISO20022 migration project will also touch on many of those interfaces and
stakeholders. To reduce the touch points and the impact on clients, optimize resources and investments while
enabling the bank to provide significant improvement in client experience, it is crucial to include the need for
structured data as part of the ISO20022 project.

PMPG Market Practice Guidelines - Structured ordering and beneficiary customer data in payments Page 3
2 Definition & best practices of structured customer data in ISO20022
2.1 Definition of structured customer data in SWIFT MT vs. MX
Structured data refers to data that is logically specified in dedicated data elements whereby it is clearly
documented what element includes which data. In the SWIFT MT format, unstructured customer data are
carried in the K- or no-letter options of field 50 (ordering customer) & field 59 (beneficiary customer), while
the option F defines the structured variation.

Illustration 2 – Example of unstructured vs. structured data in SWIFT FIN (e.g. MT103)

The above clearly illustrates that the Address lines 1 – 4 in the unstructured option does not allow
unambiguous interpretation of information due to the lack of qualified elements. The option F in the SWIFT
FIN standard provides a certain level of structure by the qualifiers (e.g. 1/ for name). While the elements
"Name" and "Country" can be unambiguously identified, the data in the address (2/…) and location (3/XY/…)
line could contain multiple information such as Street Name, Building Number, Floor Number, Building Name,
Town/City name, Postal Code etc. which therefore is not easily identifiable.

The ISO20022 standard on the other side offers much more granular structure for the individual address
elements. The SWIFT MX standard as defined by HVPS+ (High Value Payments Systems Plus) and CBPR+ (Cross-
Border Payments & Reporting Plus) guidelines foresee an unstructured and structured option of the customer
data. The difference between the two is determined by the nature of the Level 3 element “Postal Address”. In
the unstructured option, this element contains up to three iterations of unstructured “Address Lines”. In the
structured variation of ISO20022, the Postal Address consists of up to 13 dedicated data elements and a
country code. In both cases, the element “Name” is a dedicated data element.

Illustration 3 – Example of unstructured vs. structured data in ISO20022

PMPG Market Practice Guidelines - Structured ordering and beneficiary customer data in payments Page 4
Illustration 4 – Description of customer data elements in MX/ISO20022:

Level Element description ISO20022 tag Position in subfield

2 Debtor <Dbtr>
Name by which a party is known and which is usually used
3 Name <Nm>
to identify that party
Information that locates and identifies a specific address,
3 Postal Address <PstlAdr>
as defined by postal services
Identification of a division of a large organisation or
4 Department <Dept>
building
Identification of a sub-division of a large organisation or
4 Sub Department <SubDept>
building
4 Street Name <StrtNm> Name of a street or thoroughfare
Number that identifies the position of a building on a
4 Building Number <BldgNb>
street
4 Building Name <BldgNm> Name of the building or house

4 Floor <Flr> Floor or storey within a building

Numbered box in a post office, assigned to a person or
4 Post Box <PstBx>
organisation, where letters are kept until called for
4 Room <Room> Building room number

Identifier consisting of a group of letters and/or numbers

4 Post Code <PstCd> that is added to a postal address to assist the sorting of
mail
Name of a built-up area, with defined boundaries, and a
4 Town Name <TwnNm>
local government
4 Town Location Name <TwnLctnNm> Specific location name within the town

4 District Name <DstrctNm> Identifies a subdivision within a country sub-division

Identifies a subdivision of a country such as state, region,
4 Country Sub Division <CtrySubDvsn>
county
4 Country <Ctry> Nation with its own government

3 Identification <Id> Unique and unambiguous identification of a party

4 Organizational Identification <OrgId> Unique and unambiguous way to identify an organisation

5 Any BIC <AnyBic> Business identification code of the organisation

Legal entity identification as an alternate identification for
5 Legal Entity Identifier <LEI>
a party

*This field definition also applies for the ultimate debtor, creditor & ultimate creditor

PMPG Market Practice Guidelines - Structured ordering and beneficiary customer data in payments Page 5
2.2 Variety of unstructured and structured formats in SWIFT FIN & ISO20022
Compared to the unstructured SWIFT FIN format, the unstructured ISO20022 provides some degree of
structure as it contains the mandatory element "name" (Nm). Even more transparency will be achieved when
the fully structured option in ISO20022 will be used due to the granularity of the data definition.

Illustration 5 – Comparison of data elements in SWIFT FIN and ISO20022

The increased data unambiguousness will significantly increase data quality in payments messages; however, it
comes with a substantial challenge during the coexistence of SWIFT FIN and MX/ISO20022: the different data
options are not fully interoperable in both directions. While more granular/structured data can easily be
mapped into aggregated/unstructured data elements (e.g. ISO20022 structured -> structured SWIFT FIN), it is
much more difficult to map aggregated/unstructured data in to more granular/structured data element.

Illustration 6 – Overview of different standards/options and mapping challenges (red arrows)

PMPG Market Practice Guidelines - Structured ordering and beneficiary customer data in payments Page 6
2.3 Format handling during the coexistence phase (2021 – 2025)
As visualized in illustration 6, there is no simple mechanism to ensure 100% integrity of data when mapping
between different formats. This is accentuated by the fact that a payment could be mapped several times
between MT and MX along the payment chain. As a result of the various mapping challenges, the PMPG
proposes the following mapping principles until the sun-setting of unstructured customer data.

Market Practice Guideline #2: Ensure full ISO20022 data structure at source
The key principle in the migration towards structured customer data is that good data quality (= structured,
complete & accurate) must be provided at the source / origination of a payment transaction. As stated in the
previous chapter, the CBPR+ Usage Guidelines require the usage of structured address for payments that are
initiated by the debtor’s agent in ISO20022 effective with the start of the co-existence phase in November
2021. The debtor agents are hence the primary key enabler of a successful migration to structured customer
addresses and must take this responsibility seriously. As a matter of urgency, a project must be initiated to
review and improve the data on file for all clients. Equally important is the dialogue with corporate clients to
raise the awareness about the requirements and the consequences, such as increased delays in processing and
exception handling, if failing timely delivery.

Market Practice Guideline #3: Maintain ISO20022 format throughout the entire payments chain
Conversion from MX to MT comes with the risk of data truncation/loss at the price of operational efficiency,
customer satisfaction and efficient transaction surveillance. The simplest way to avoid interoperability issues
due to mapping between different formats is to maintain the ISO20022 format through the entire payment
chain. This will obviously not be achievable for all cross-border payments during the coexistence of SWIFT FIN
and MX/ISO20022 and the individual ISO20022 adoptions of market infrastructures around the globe.

Illustration 7 – Target state of a payment chain where structured ISO20022 customer data is maintained end-to-end

Illustration 8 – Example of an interim state during coexistence with format conversion

The mapping between different formats will typically happen between the sender and the receiver of a SWIFT
message (e.g. when the receiver is not yet able to process ISO20022 and leverages the SWIFT translation
service), or at the intermediary bank. These cases will be quite common at the beginning of the coexistence
phase but should become less frequent along the global migration to ISO20022. During that time, it is critical
that the conversion is done in line with the usage guidelines of CBPR+ and the mapping rules published by
SWIFT as further explained in the market practice guidelines in the following chapters.

PMPG Market Practice Guidelines - Structured ordering and beneficiary customer data in payments Page 7
2.4 Master data management. Where is the golden source for party data?
Market Practice Guideline #4: To ensure the highest quality of party data, the preferred source of data must
be identified and agreed. The creditor and the debtor source of identification must be differentiated.

Debtor Identification
For customer credit transfer the debtor’s legal name and address data should be sourced from the debtor
agent’s KYC master records. Any intermediary agent will place a high level of trust in the debtor’s name and
address data, the assumption being that the debtor agent followed the Wolfsberg principles 1 when populating
the field. This also ensures that the debtor did not have the opportunity to modify or overwrite the field. If the
debtor maintains an LEI, then the name and address data provided in the credit transfer should be consistent
with the name and address data published in the official LEI database, regardless whether the LEI is provided
as an organizational identifier or not. As a best practice, PMPG is recommending to include the LEI, in addition
to the legal name, as a party identifier for debtor and creditor if available 2.

Party Field Golden Source

Debtor Name Debtor Agent’s KYC File = LEI DB (if applicable)
Debtor Postal Debtor Agent’s KYC File = LEI DB (if applicable)
Debtor Identification Debtor Agent sourced from LEI DB (if available)

Ultimate debtor Identification

In case the debtor includes ultimate debtor name and address data in the credit transfer, unless required by
local regulation, subject data is sourced by the debtor and not the debtor agent. The debtor agent should
recommend to the debtor to source the ultimate debtor information from the LEI database if an LEI is
available, if the ultimate debtor maintains an LEI that is different from the LEI of the debtor. In other cases, this
data field may include brand names (e.g. doing business as info) or other name, address or identification
needed to allow the creditor to reconcile the payment.

Party Field Golden Source

Ultimate Debtor Name Debtor’s ERP or customer system
Debtor’s ERP or customer system (only if different from debtor’s
Ultimate Debtor Postal Address
address)
Unique identification - such as LEI, Customer ID, Student ID in the
Ultimate Debtor Identification
University - in the debtor’s ERP or customer system.

Creditor Identification (including ultimate creditor):

Creditor name and address data is in most cases more problematic to source unless the debtor is transferring
funds to his/her own account at another agent. If that is the case the creditor name and address should, in
most cases, be identical to the name and address of the debtor. If the creditor is different from the debtor, the
debtor agent should request from its customer the full name and address data of the beneficiary/creditor. If
the payment order has to carry ultimate creditor information the same principles apply. At a minimum, the
debtor must include the full legal name, the ISO country code and town of residency of the creditor in the
credit transfer.

Party Field Golden Source

Creditor Name Debtor's ERP system = LEI DB (if applicable)
Creditor Postal Address Debtor's ERP system = LEI DB (if applicable)
Creditor Identification Debtor's ERP system = LEI DB (if applicable)

1
See publication "Wolfsberg Payment Transparency Standards 2017" (https://www.wolfsberg-principles.com/publications/wolfsberg-standards)
2
For more details on using the LEI in payments please consult the PMPG paper: ”Adoption of LEI in Payment Messages – 2019” on the PMPG website
(www.pmpg.info).

PMPG Market Practice Guidelines - Structured ordering and beneficiary customer data in payments Page 8
2.5 Mapping and translation guidelines during coexistence of MT and MX/ISO20022

2.5.1 Basic principles for mapping & translation

Market Practice Guideline #5: Whenever mapping / translating between the various format options during the
coexistence phase, the PMPG recommends to apply the mapping scheme as highlighted in the illustration
below and the detailed mapping rules described in the following sub-chapters.

ISO20022 provides more structured and granular data for the identification of a “party” in the name & address
component than the SWIFT FIN F option. Therefore, mapping from MX/ISO20022 to MT address details will
naturally lead to a loss of data structure.

The name and address data for creditor and debtor in ISO20022 use the complex data type
PartyIdentification135_2 which is comprised of the simple data type Name, the complex data types Postal
Address (PostalAddress24_1) and Identification Party38Choice_2. The account details for debtor and creditor
are expressed as the complex data type CashAccount38_2. The max number of characters including the
account number that this data structure can contain is 819. The current fields 50 & 59 in the MT103 message
allow a maximum of 175. In the F option, the number of usable characters without counting the delimiters is
166 (34x for the account number and 4 * 33x for name/address). This means the MX party fields can contain 4
times more characters than the corresponding MT fields. This will require field and content prioritization rules
when mapping the party content from a source MX message into MT.

These mapping rules will apply and truncation issues will occur during the co-existence period only. SWIFT will
always deliver the original message to the receiver, however, to facilitate in-house processing, tools will be
available to utilize the (central or onsite) translation for the provision of the SWIFT MT equivalent in addition.
This will allow the receiver to consult the original ISO20022 message in case data was truncated during the
conversion to the SWFIT FIN message.

Illustration 9 – Mapping table during coexistence of MT and MX/ISO20022

Structured MX/ISO20022 > Structured SWIFT FIN see chapter MPG #6

Structured SWIFT FIN > Unstructured MX/ISO20022 see chapter MPG #7

Unstructured MX/ISO20022
> Structured SWIFT FIN see chapter MPG #8
with 2/… and 3/… qualifiers

Unstructured MX/ISO20022
> Unstructured SWIFT FIN see chapter MPG #9
without 2/… and 3/… qualifiers

Unstructured SWIFT FIN > Unstructured MX/ISO20022 see chapter MPG #10

PMPG Market Practice Guidelines - Structured ordering and beneficiary customer data in payments Page 9
2.5.2 How to deal with truncation

Market Practice Guideline #6: Whenever data is truncated during this mapping due to space limitation, the
indicator "+" must be added at the end of the respective line/data element. Data should be priorities according
to the table on the next page.

Intermediaries must understand their liabilities/responsibilities to provide all information received to the next
party in the payment chain. If not ISO20022 capable yet, the information truncated must be provided by the
intermediary via an alternative method in addition to keeping the truncation sign "+” unchanged when
forwarding an MT103 to the next agent for further processing. This will ensure that the receiver is made aware
of the “loss of data” and allow a potential follow up via Exceptions and Investigations. The intermediary must
provide the additional information requested with the highest priority. To mitigate this risk, it is key the
prioritization and sequencing of data elements is done in accordance of the table below.

Illustration 10– Data priorities of customer data elements in MX/ISO20022

Occu
Target field/sub-field in Position in
Level Element description ISO20022 tag rrenc Data type
SWIFT FIN subfield
es
2 Debtor <Dbtr> [1..1]
F Option Subfield 1 (two
occurrences if no LEI is
3 Name <Nm> [0..1] text{1,140} 1
present, 1 occurrence if
LEI is present)
3 Postal Address <PstlAdr> [0..1]
4 Department <Dept> [0..1] text{1,70} F Option Subfield 2 7
4 Sub Department <SubDept> [0..1] text{1,70} F Option Subfield 2 8
4 Street Name <StrtNm> [0..1] text{1,70} F Option Subfield 2 1
4 Building Number <BldgNb> [0..1] text{1,16} F Option Subfield 2 2
4 Building Name <BldgNm> [0..1] text{1,35} F Option Subfield 2 3
4 Floor <Flr> [0..1] text{1,70} F Option Subfield 2 4
4 Post Box <PstBx> [0..1] text{1,16} F Option Subfield 2 5
4 Room <Room> [0..1] text{1,70} F Option Subfield 2 6
4 Post Code <PstCd> [0..1] text{1,16} F Option Subfield 3 3
4 Town Name <TwnNm> [0..1] text{1,35} F Option Subfield 3 2
4 Town Location Name <TwnLctnNm> [0..1] text{1,35} F Option Subfield 3 5
4 District Name <DstrctNm> [0..1] text{1,35} F Option Subfield 3 6
4 Country Sub Division <CtrySubDvsn> [0..1] text{1,35} F Option Subfield 3 4
4 Country <Ctry> [0..1] text[A-Z]{2,2} F Option Subfield 3 1

3 Identification <Id> [0..1] complex

Organizational
4 <OrgId> [1..1] complex
Identification
5 Any BIC <AnyBic> [0..1] Any BIC A option second line 1
50F Option Subfield 6
5 Legal Entity Identifier <LEI> [0..1] LEI Identifier 1
59F Option Subfield 3

PMPG Market Practice Guidelines - Structured ordering and beneficiary customer data in payments Page 10
2.5.3 Field mapping from structured MX/ISO20022 to structured MT

Market Practice Guideline #7: Structured customer data elements in MX/ISO20022 should be mapped to the
respective sub-field of structured option F of SWIFT FIN. This will allow to preserve a certain level of structure
(1/name, 2/address, 3/country/town).

During this mapping from MX to MT, the data elements belonging to the "Address" and "Town" group will be
consolidated, leading to the loss of certain granularity of data. Furthermore, not all data available in the
various ISO20022 address elements may fit into the 4*35 lines of the SWIFT FIN format.

During this mapping from MX to MT, the data elements belonging to the "Address" and "Town" group need to
be consolidated, leading to the loss of certain granularity of data. Furthermore, not all data available in the
various ISO20022 address elements may fit into the 4*35 lines of the SWIFT FIN format. Whenever data is
truncated during this mapping due to space limitation, the indicator "+" must be added by the translation tool
at the end of the respective line/data element.

Illustration 11 – Example for field mapping from structured MX/ISO20022 to structured MT

structured MX/ISO20022 structured SWIFT FIN

Name <Nm> JOHN SMITH > Name (1/) 1/JOHN SMITH
Department <Dept>
Sub Department <SubDept>
Street Name <StrtNm> HOOGSTRAAT
Building Number <BldgNb> 6 > Address 2/HOOGSTRAAT,6, PREMIUM TOWER,14
Building Name <BldgNm> PREMIUM TOWER (2/…) 2/17822
Floor <Flr> 14
Post Box <PstBx> 17822
Room <Room>
Post Code <PstCd> 1000
Town Name <TwnNm> BRUSSELS
Country /
Town Location Name <TwnLctnNm>
Town 3/BE/BRUSSELS,1000
District Name <DstrctNm> >
(3/…)
Country Sub Division <CtrySubDvsn>
Country <Ctry> BE

The mapping will be done based as per the following steps and prioritization of data (see previous page):
• Step 1: Map XML fields into the appropriate subfields of the F option if no BIC present as per the
column "Position in subfield". Use the comma ("," without space) as a delimiter so separate the
various available data elements in the sub-fields 2/… (address) and 3/XY/… (town).
• Step 2: If LEI is present do not use second line for name, truncate if needed using the ‘+’ character at
as the last character. Truncate any other line the same way. Mapping rules for LEI element:
o Place LEI on last line of 50F or 59F, if space allows.
o For 50F, insert a 6/XY/LEIC/ before LEI. XY is the country code of the debtor.
o For 59F, insert a 3/XY/LEIC/ before LEI. XY is the country code of the creditor.

• Step 3: If LEI not present use two lines for the name and truncate any other line, indicating truncation
with the + character
• Step 4: If no LEI and single line name use two lines for the Country, town etc.
• Step 5: If no second line for any other field use two lines for the street and building

PMPG Market Practice Guidelines - Structured ordering and beneficiary customer data in payments Page 11
Illustration 12– Example without LEI for 50F:

structured MX/ISO20022 structured SWIFT FIN

Chris Evans and Robert R Downey Junior The
<Nm> > Name 1/Chris Evans and Robert R Downey J
Second Family Office
(1/…) 1/unior The Second Family Office
<Dept>
<SubDept>
<StrtNm> Muddafarganj-Chitosi-Ramganj Road
<BldgNb> 123
Address
<BldgNm> Anchor Tower 3 > 2/Muddafarganj-Chitosi-Ramganj Roa+
(2/…)
<Flr> 25th
<PstBx>
<Room> 5003
<PstCd> 3622
<TwnNm> Pashchim Kherihar Al
Country /
<TwnLctnNm>
Town 3/BD/Pashchim Kherihar Al,3622,Chi+
<DstrctNm> >
(3/XY/…)
<CtrySubDvsn> Chittagong Province
<Ctry> BD

Illustration 13– Example with LEI for 50F:

structured MX/ISO20022 structured SWIFT FIN

Chris Evans and Robert R Downey Junior The Name
<Nm> > 1/Chris Evans and Robert R Downey +
Second Family Office (1/…)
<Dept>
<SubDept>
<StrtNm> Muddafarganj-Chitosi-Ramganj Road
<BldgNb> 123 Address
2/Muddafarganj-Chitosi-Ramganj Roa+
<BldgNm> Anchor Tower 3 > (2/…)
<Flr> 25th
<PstBx>
<Room> 5003
<PstCd> 3622
<TwnNm> Pashchim Kherihar Al
Country /
<TwnLctnNm>
Town 3/BD/Pashchim Kherihar Al,3622,Chi+
<DstrctNm> >
(3/XY/…)
<CtrySubDvsn> Chittagong Province
<Ctry> BD
Identification
<LEI> 549300Y5RWQU43R0QM07 6/BD/LEIC/549300Y5RWQU43R0QM07
(6/…)

The ISO country code preceding the "/LEIC/LEI identifier" is not meaningful in this particular context as it is a
repetition of the country of the domicile of debtor or creditor. Nevertheless it is aligned with FATF 16
recommendation implementation and allows to maintain a standard interpretation of the field and an
automated processing / validation of the payment message. For more information about the LEI ("Legal Entity
Identifier), please refer to the discussion papers and industry updates that the PMPG published in this
3
context .

3
Link to PMPG document centre: https://www.swift.com/about-us/community/swift-advisory-groups/payments-market-practice-
group/document-centre/document-centre

PMPG Market Practice Guidelines - Structured ordering and beneficiary customer data in payments Page 12
2.5.4 Field from mapping from structured MT to unstructured MX/ISO20022

The challenge to map structured customer data from structured SWIFT FIN F option to ISO20022 is that the FIN
fields are not as granular as the data elements in ISO20022. As a consequence, the data in the FIN subfield
"Address" (2/…) and "Town" (3/XY/…) may contain richer content than the target element in ISO20022. For
instance, subfield "Address" could contain street name, street number, building name, floor number and many
more. A similar challenge exists for the subfield “Town" (data after 3/XY/…) that could contain data such as
postal code, district name, country sub-division etc. Therefore, the mapping from structured SWIFT FIN to
structured ISO20022 comes with the risk that the data mapped to the designated elements may be polluted by
the inclusion of additional data, as shown in the following diagram (not allowed):

Illustration 14– Non-recommended mapping from structured MT to unstructured MX/ISO20022

Market Practice Guideline #8: Structured customer data in SWIFT FIN (F option) should therefore be mapped
into "Name (Nm)" and unstructured "Address line (AdrLine)" elements in MX/ISO20022. In order to keep the
transparency and the benefits of the original FIN structure, the mapping of the SWIFT FIN subfields should
apply the same structure and include the original qualifiers 2/ for address and 3/ for country and town. Those
should be copied and included at the beginning of the respective (two or three occurrences of) AdrLine in ISO.

Illustration 15– Recommended mapping from structured MT to unstructured MX/ISO20022

structured SWIFT FIN unstructured MX/ISO20022

Name (1/…) 1/JOHN SMITH > <Nm> JOHN SMITH

Address 2/HOOGSTRAAT,6, PREMIUM TOWER,14 <AdrLine 1> 2/HOOGSTRAAT,6, PREMIUM TOWER,14

(2/…) 2/17822 <AdrLine 2> 2/17822
>
Country / Town <AdrLine 3> 3/BE/BRUSSELS,1000
3/BE/BRUSSELS,1000 >
(3/…)

Mapping rules if LEI can be located in field 50F or field 59F of SWIFT FIN message:

• Field 50F: Locate LEI after 6/XY/LEIC/… and map it to the LEI element in MX/20022 (the information
before the LEI can be dropped)
• Field 59F: Locate LEI after 3/XY/LEIC/… and map it to the LEI element in MX/20022 (the information
before the LEI can be dropped)

PMPG Market Practice Guidelines - Structured ordering and beneficiary customer data in payments Page 13
2.5.5 Map unstructured MX/ISO20022 with 2/ and 3/ qualifiers to structured SWIFT FIN

Market Practice Guideline #9: For the mapping of unstructured ISO20022 to SWIFT FIN it must be checked
whether all occurrences of the AdrLine elements start with a SWIFT FIN qualifier, such as 2/ (up to two
occurrences allowed) or 3/. If this is the case, the target format in SWIFT FIN will be structured (option F). The
mapping of the fields will be as follows:
• Name: Map ISO20022 element "Nm" (Name) to line 1 of the SWIFT FIN field 50 / 59 option F with the
prefix "1/" at the beginning of the line
• Address: Map all occurrences of the "AdrLine" to the residual lines of SWIFT FIN field 50 / 59 option F
under preservation of the prefix available in the AdrLine

The background of this constellation are scenarios where the original message started as structured MT or was
translated from MX into structured MT (hence the presence of the number qualifiers). Hence, there should not
be any truncation issue for these cases. If any of the occurrences of "AdrLine" does not start with "2/" or "3/",
the target format in SWIFT FIN must be unstructured as described in the chapter 2.5.6.

Illustration 16– Example for field mapping from unstructured MX/ISO20022 with 2/ and 3/ qualifiers

unstructured MX/ISO20022 structured SWIFT FIN

<Nm> JOHN SMITH > Name (1/…) 1/JOHN SMITH

<AdrLine 1> 2/HOOGSTRAAT,6, PREMIUM TOWER,14

2/HOOGSTRAAT,6, PREMIUM TOWER,14
> Address (2/…)
<AdrLine 2> 2/17822 2/17822

Country / Town
<AdrLine 3> 3/BE/BRUSSELS,1000 > 3/BE/BRUSSELS,1000
(3/…)

2.5.6 Map unstructured MX/ISO20022 without 2/ and 3/ qualifiers to unstructured SWIFT FIN

Market Practice Guideline #10: In case not all occurrences of "AdrLine" in the ISO20022 message start with 2/
or 3/, the target format should be the unstructured SWIFT FIN format (K- or no letter option).

The mapping of the fields will be as follows:

• Name: Map to element "Nm" (Name) to line 1 of MT FIN field 50 / 59 option (K- or no letter option)
• Address: Map all occurrences of "AdrLine" to the residual lines of MT FIN field 50 / 59

Illustration 17– Example for field mapping without 2/ and 3/ qualifiers (without truncation)

unstructured MX/ISO20022 unstructured SWIFT FIN

<Nm> JOHN SMITH > Name / Address Line 1 JOHN SMITH
<AdrLine> 1 HOOGSTRAAT 6 Name / Address Line 2 HOOGSTRAAT 6
<AdrLine> 2 1000 BRUSSELS > Name / Address Line 3 1000 BRUSSELS
<AdrLine> 3 BE Name / Address Line 4 BE

PMPG Market Practice Guidelines - Structured ordering and beneficiary customer data in payments Page 14
A potential space issue will occur if the data of the ISO20022 business component Debtor or Creditor exceeds
the capacity of 4*35 characters in total. Although CBPR+ is restricted to max. 3 occurrences of AdrLine, there
could be Market Infrastructures allowing 4 or more occurrences. If the data mapped from unstructured
ISO20022 does not fit into unstructured SWIFT FIN, this will be indicated with a truncation sign "+" at the last
line of the truncated element/line. The user of the MT message must ensure procedures are in place how to
deal with truncated data available in the original MX message.

Illustration 18– Example for field mapping without 2/ and 3/ qualifiers (with truncation)

unstructured MX/ISO20022 unstructured SWIFT FIN

<Nm> Chris Evans > Name / Address Line 1 Chris Evans
<AdrLine> 1 Muddafarganj-Chitosi-Ramganj Road 123 Name / Address Line 2 Muddafarganj-Chitosi-Ramganj Road +
<AdrLine> 2 Pashchim Kherihar Al, 3622 > Name / Address Line 3 Pashchim Kherihar Al, 3622
<AdrLine> 3 BD Name / Address Line 4 BD

2.5.7 Map unstructured SWIFT FIN to unstructured MX/ISO20022

Market Practice Guideline #11: The mapping of unstructured data from ISO20022 to SWIFT FIN is relatively
straight-forward. The main challenge of mapping unstructured customer data from SWIFT FIN to ISO20022 is
that the ISO20022 message has a dedicated data element for the Name, even in the unstructured format.

• Name: Map line 1 of MT FIN field 50 / 59 to element "Nm" (Name)

• Address: Map line by line, 2, 3 and 4 of the SWIFT FIN field 50 / 59 to ISO20022 element "AdrLine"
(line 2 to first occurrence of AdrLine, line 3 to second occurrence of AdrLine, etc.)

Note: There are cases where the name exceeds one line. The above described mapping could therefore lead to
the result that a part of the name information will be mapped to the element "AdrLine".

Illustration 19– Example for field mapping from unstructured SWIFT FIN to unstructured MX/ISO20022

unstructured SWIFT FIN unstructured MX/ISO20022

Name / Address Line 1 JOHN SMITH > <Nm> JOHN SMITH
Name / Address Line 2 HOOGSTRAAT 6 <AdrLine> 1 HOOGSTRAAT 6
Name / Address Line 3 1000 BRUSSELS > <AdrLine> 2 1000 BRUSSELS
Name / Address Line 4 BE <AdrLine> 3 BE

PMPG Market Practice Guidelines - Structured ordering and beneficiary customer data in payments Page 15
3 Guiding Principles for a successful migration
3.1 Best practices for the parties in the payments chain
The following section describes the responsibilities, challenges and risks associated to the individual actors in
the lifecycle of a payment. There are four main best practices (disciplines) that apply when it comes to the
handling of structured data. Depending on the role of a party involved in the payment, one or several of these
best practices may apply.

Market Practice Guideline #12: The key success factor for a global migration to structured customer data in
payments is that all actors are aware of their responsibilities and take the required steps to comply with these
requirements.

Illustration 20 – Actors & roles along the payment lifecycle

1. Provide / map structured data

As high quality of data can only be guaranteed at the “source of the information”, it must be sourced at the
origin of a payment transaction to avoid labor and cost intensive repair to structure data for subsequent
processing. As mentioned in chapter 2.4 ("Master data management. Where is the golden source for party
data?”), the originating party (=Debtor) is responsible for providing high quality (structured) information of
the creditor and ultimate parties (ultimate debtor & ultimate creditor), while the debtor agent is responsible
for delivering the required, accurate and structured customer data of the debtor.

2. Encourage usage of structured data

The vast majority of today’s customer data in payment transactions is unstructured. In order to move from
the status quo to the target state it is crucial that the financial institutions, SWIFT and Market infrastructures
should strongly promote, monitor and – at a certain stage – enforce structured customer data from their
customers / senders.

3. Forward structured data:

FATF recommendation 16 and relating local regulations & jurisdictions demand that the intermediary of a
payment transaction ‘should ensure that all originator and beneficiary information that accompanies a wire
transfer is retained in it’. It is equally important that the intermediary parties maintain the structure of the
provided customer data. If one party in the chain is not able to maintain the data structure and therefore
data integrity, all subsequent parties in the chain will need to deal with unstructured data.

4. Process structured data:

Financial institutions should adapt their processing, screening and monitoring processes to optimize the
process and fully benefit from the positive impact of structured customer data in payments messages.

PMPG Market Practice Guidelines - Structured ordering and beneficiary customer data in payments Page 16
3.1.1 Role of the Debtor (Ordering Customer)

Provide / map structured creditor data

The only party in the payment chain that has the full information of the creditor, is the party that initiates the
payment transaction. It is therefore critical that the debtor provides this data in the payment as part of the
credit transfer initiation sent to its financial institution/agent. Note: same applies for the ultimate party
information (ultimate debtor & ultimate creditor). Responsibilities of the debtor:
• Obtain structured customer creditor data from its counterparties and store & maintain it accordingly
in the respective data inventories (e.g. ERP system, payments templates)
• Ensure that creditor data is provided in a structured format when executing payments (e.g. pain.001
to its financial institution, manual payment entry in an online/mobile channel)
• Engage with its service provider(s) and/or software provider(s) on format requirements & timelines to
ensure a timely and smooth migration and to avoid rejects or delays of domestic or cross-border
payments due to incomplete/missing data structure

Potential challenges & risks to be addressed:

• How to clean up existing data in ERP systems, templates, standing orders, etc.
• Potential use of Artificial Intelligence to create structured data from unstructured data

3.1.2 Role of the Debtor Agent (Ordering Institution)

Provide / map structured debtor data

Responsibilities of the debtor agent:

• Ensure that client static data are available in structured format
• Adapt mapping processes generating the debtor information in outgoing payments

Potential challenges & risks to be addressed:

• Heavy change management internally, but also vis-à-vis the clients, to be compliant with the rule "If a
payment is initiated in ISO20022, postal address must be structured"

Encourage usage of structured creditor data

Responsibilities of the debtor agent:

• Request debtor to always provide counterparties (creditor’s) name and address with the minimum of
country and town irrespective of the initiation channel used for cross-border payments
• Provide its clients with a revised front-ends that encourage/enforce structured data from its clients
(ISO20022 compliant, especially for customer data)
• Validate adequacy/integrity of data entered by the customer and align if required with ISO20022 data
structure and (if necessary) clean-up of data
• Initiate an ISO20022 messages whenever possible

Potential challenges & risks to be addressed:

• Efforts required for technical amendments of client channels/interfaces
• Establish clear communication and migration plan vis-à-vis clients
• According to local rules, transform MT into MX / ISO20022

PMPG Market Practice Guidelines - Structured ordering and beneficiary customer data in payments Page 17
 Forward structured creditor data

Responsibilities of the debtor agent:

• Ensure that provided beneficiary/creditor details are forwarded unaltered to the next party in the
payments chain
• Maintain the data structure of the customer data provided

Potential challenges & risks to be addressed:

• No regulation mandating creditor address

Process structured debtor & creditor data:

Responsibilities of the debtor agent:

• To provide, validate and improve quality of data in line with the new standard
• To screen against embargo/sanction/local rules

Potential challenges & risks to be addressed:

• Adapt processing, screening and monitoring processes to be optimized and fully benefit from the
positive impact of structured customer data in payments messages

3.1.3 Role of SWIFT / Market Infrastructures

Encourage usage of structured debtor & creditor data

Responsibilities of SWIFT / Payment Market Infrastructures:

• For SWIFT: support the coexistence period between SWIFT FIN and ISO20022 by allowing the
exchange of messages using both standards, in the various combination
• Support the community in promotion and marketing in adopting structured customer data by
November 2023
• Dedicated reporting to the communities to monitor the ISO20022 migration
• Encourage Market Infrastructure, especially the "smaller" ones, to migrate to ISO20022 within the
coexistence period of SWIFT FIN and ISO20022 which ends in Q 4 2025
• Engage/continue the dialogue with the Payment Market Infrastructures regarding the enforcement of
structured data
• Engage/continue the dialogue with the Wolfsberg Group, the CPMI/IOSCO to mandate structured
beneficiary/creditor address at the end of the coexistence period
• For Payment Market Infrastructures: ensure coordination in terms of migration planning & ISO20022
versioning, combined with proactive communication and marketing in adopting structured customer
data by November 2023

Potential challenges & risks to be addressed:

• In order to manage the impact on clients, and the operational and liquidity risk globally, it is vital to
ensure sufficient time between the migration of major Market Infrastructures to avoid a global big
bang and minimize migration fatigue

Forward structured debtor & creditor data

• Ensure that structure of the provided customer data is maintained

PMPG Market Practice Guidelines - Structured ordering and beneficiary customer data in payments Page 18
3.1.4 Role of the Intermediary Agent(s)

Encourage usage of structured debtor & creditor data

Responsibilities of the intermediary:

• Transfer unchanged the received data
• During the coexistence period, transform MT message into MX / ISO20022 message when appropriate

Forward structured debtor & creditor data

• Ensure that provided beneficiary/creditor and details are forwarded unaltered to the next party in the
payments chain
• Maintain the data structure of the customer data provided by the debtor end to end

Process structured debtor & creditor data:

• Adapt processing, screening and monitoring processes to be optimized and fully benefit from the
positive impact of structured customer data in payments messages.

As highlighted in MPG guideline #6, Intermediaries must understand their liabilities/responsibilities to provide
all information received to the next party in the payment chain. If not ISO20022 capable yet, the information
truncated must be provided by the intermediary via an alternative method in addition to keeping the
truncation sign "+” unchanged when forwarding an MT103 to the next agent for further processing. This will
ensure that the receiver is made aware of the “loss of data” and allow a potential follow up via Exceptions and
Investigations. The intermediary must provide the additional information requested with the highest priority.

3.1.5 Role of the Creditor Agent (Beneficiary/Creditor Institution)

Process structured debtor & creditor data:

• Adapt processing, screening and monitoring processes to optimized and fully benefit from the positive
impact of structured customer data in payments messages.

PMPG Market Practice Guidelines - Structured ordering and beneficiary customer data in payments Page 19
3.2 The importance of an aligned roadmap
Market practice guideline #13: Market infrastructures, banks and SWIFT should closely align their roadmap for
adoption of ISO20022 and structured customer data in closed alignment to ensure interoperability throughout
each the coexistence phase (November 2021 – November 2025). They should promote, monitor and
incentivize the migration to structured customer data with the targeted end-date of November 2023.

With the major market infrastructures completing their migration to fully-fledged ISO20022 effective Q4 2023,
the global demand for structured party information for all parties in the payment messages will become the
new normal for more than 80% of all high value payments by November 2023 globally.

Although Market Infrastructures agreed to support unstructured address (address line) until the end of the
coexistence period with FIN for exceptional scenarios (e.g. forwarding an unstructured SWIFT FIN MT103 into
local clearing), November 2023 should be targeted by all communities as the end-date for unstructured
customer information payments, regardless of their format (ISO20022, FIN or native clearing).

Banks and their clients must work toward this deadline to ensure interoperability and timely execution of their
payments. Payments failing structured party information will undoubtedly trigger delays and higher processing
cost leading to frustrations for the end clients. PMPG strongly encourages all communities to start engaging
with their members and corporate clients now on the need for structured party information.

Illustration 21 – The road to structured customer data

PMPG Market Practice Guidelines - Structured ordering and beneficiary customer data in payments Page 20
3.3 How to engage various stakeholders
As articulated in our Structured ordering and beneficiary customer data in payments whitepaper, published in
September 2017, there are end-to-end impacts of migrating to structured customer data for most
stakeholders in the payment industry, including Market Infrastructures, Financial Institutions, End Clients (in
particular originating parties) and Application/Software Providers. It is important that these stakeholders
engage in bilateral and multilateral discussions to consider the solutions required for the industry.

Market Practice Guideline #14: Recommended engagement mechanisms for stakeholders include:
• Market Infrastructure user groups where Market Infrastructures can communicate ISO20022
migration plans and structured data requirements, and Financial Institutions participants can
contribute to the transition plans schema development.
• Regulatory forums where Financial Institutions can highlight the benefits (and potential challenges)
the use of structured customer data may pose to regulatory obligations such as AML/sanctions
screening, transaction reporting, etc. and how these could be realized (or avoided) with an agreed,
collaborative approach.
• Correspondent banking relationships where alignment can assist in maintaining structured customer
data through the payment chain.
• Client forums and direct engagement where the need for additional information (such as
beneficiary/creditor address which is not commonly included today), cleanse of customer data, and
enablement within respective ERP systems can be shared.
• Vendor engagement with software suppliers from both a client and Financial Institutions
perspective, highlighting the importance of structure and ISO20022 compatibility.

To make this transition successful, it will come down to all stakeholders in the community recognizing its
importance, the breadth and magnitude of impact, and actively engaging with each other to ensure the end-
to-end payment chain is not compromised.

PMPG Market Practice Guidelines - Structured ordering and beneficiary customer data in payments Page 21