PMPG Fatf Rec 16 Update 2018 v1.5
PMPG Fatf Rec 16 Update 2018 v1.5
PMPG Fatf Rec 16 Update 2018 v1.5
Note: Relevant regulations and any applicable legislation take precedence over the guidance notes issued by
this body. These Guidelines represent an industry’s best effort to assist peers in the interpretation and
implementation of the relevant topic(s). The PMPG - or any of its Members - cannot be held responsible
for any error in these Guidelines or any consequence thereof.
1. Introduction
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 straight-through processing (STP) and improved customer
service.
1) Introduction
2) Background
The PMPG will regularly review these guidelines, using the frequently asked questions and community
feedback as input.
1
2. Background
In February 2012, FATF published revisions to its Forty Recommendations. This included the
integration of former Special Recommendations on Terrorist Financing. SR VII on wire transfers is now
known as R 16 and it is being transposed into national legal frameworks
Several jurisdictions have already adopted R 16. In the European Union for example, the Regulation
(EU) N° 2015/847 became effective in June 2017. It is expected that the recommendation will be
implemented across all jurisdictions over time.
R 16 extends the scope of the former SRVII by applying the requirements to cross-border and domestic
wire transfers, including serial payments and cover payments. It aims to ensure that the necessary
information on the Ordering and Beneficiary Customers of wire transfers is immediately available to
ordering, intermediary and beneficiary Financial Institutions (FIs) in order to facilitate the identification
of both customers as well as the reporting of suspicious transactions.
It is important to maintain efficiency in payment flows and the service that banks provide to their clients.
When utilising the international SWIFT FIN standard, the updating of the PMPG guidance for the
structuring of both Ordering and Beneficiary Customers information in field 50a and field 59a (where
“a” means that multiple option letters are available) of SWIFT MT 103 and MT 202 COV messages will
provide reference documents for use by instructing banks to insure that their payment instructions are
compliant with regulations in other markets.
The PMPG welcomes and endorses the work of the Wolfsberg Group to enhance transparency
regarding parties to transactions in international payments. In October 2017, the Wolfsberg Group
published its Payment Transparency Standards 1, providing additional standards on the use of customer
data. These standards should be considered along the PMPG's Market Practice Guidelines for use of
fields 50a Ordering Customer and 59a Beneficiary Customer to comply with FATF Recommendation
16.
Please note that this MPG document is based on the FATF Recommendation 16 (which, among
many things, "[…] aims to ensure that basic information on the originator and beneficiary of wire
transfers is immediately available"), but local/regional regulators may have additional or other
requirements once the FATF Recommendation has been applied in their respective legal
frameworks, and sufficient guidance from regulators is available.
1
https://www.wolfsberg-principles.com/sites/default/files/wb/pdfs/wolfsberg-standards/1.%20Wolfsberg-
Payment-Transparency-Standards-October-2017.pdf
2
3. Market Practice Guidelines (MPG) for the use of field 50a,
Ordering Customer and field 59a, Beneficiary Customer to
comply with the FATF R 16
Only Field 50a is to be used for ordering customer information. Ordering customer information should
not be included in Fields 20, 52a, 70 or 72.
The account number of the ordering customer must be stated in the account line, preceded by a slash.
Only Field 59a is to be used for beneficiary customer information. Beneficiary customer information
should not be included in Fields 20, 57a, 70 or 72.
The account number of the beneficiary customer must be stated in the account line, preceded by a slash.
Field 59a has three options – A, option F (implemented in November 2015) and No letter option (i.e.
free format).
3
MPG FATF R 16 #2: The use of field 50a with Option A
50A is appropriate when the ordering customer is a corporation with a non-financial institution Business
Identifier Code (non-financial institution BIC) assigned to it.
The second scenario where 50A is appropriate is when a bank makes payments on its own behalf and
the bank’s Business Identifier Code (financial institution BIC) is used as the identifier.
The BIC must be a SWIFT registered address, either connected or non-connected.
Option A – Usage
Subfield 1 ‘Account’ if present 2 must include the account number of the ordering customer, preceded
by a slash.
Subfield 2 ‘Identifier code’ must include the registered BIC of the ordering customer.
:50A:/SE1350000000054910000011
WXYZSESS
2
The account number, if present, must be used. The case of non-existence of an account number should rather be a rare occasion, e.g. in the
case of returns. It may also be the case for settlements in favour of banks for which usually a BIC is used without account numbers, e.g.
settlement of FX transactions or money market placements.
4
MPG FATF R 16 #3: The use of field 50a with Option F
Field 50F provides the possibility to structure clearly the ordering customer information for validation
by networks and processing applications. For this reason, in absence of a BIC, it is the preferred option.
Option F – Usage
The minimum for field 50F is 2 lines: one for the subfield 1 ‘Party Identifier’ and one for the subfield 2
‘Name & Address’:
• Subfield 1 ‘Party Identifier’ must be present and must start with either a slash (Account option)
or with a code of a restricted list (Identifier option).
• Subfield 2 ‘Name & Address’ must be present. All lines must start with a number between 1 and
8 followed by a slash. As the subfield is mandatory, at a minimum one line containing the name
of the ordering customer must be present in line with that format.
For subfield 1 ‘Party Identifier’, one of the following line formats must be used:
/34x (Account)
Or
4!a/2!a/27x (Code)(Country Code)(Identifier)
When subfield 1 ‘Party Identifier’ is used with the (Code)(Country Code)(Identifier) format, one of the
codes as described within the SWIFT User Handbook must be used.
For subfield 2 ‘Name & Address’, the following line format must be used:
1!n/33x (Number)(Details)
PMPG recommendations:
• The preference for subfield 1 ‘Party Identifier’ is to fill the Party Identifier with the account
number of the ordering customer, preceded by a slash.
• Subfield 2 ‘Name & Address’, concerning the ‘Country and Town’ (line starting with number
3), it is preferred that the Country Code and Town indicate the ordering customer’s address
verified as part of the customer due diligence.
Option F – Preferred example: account number with name, address and country code/town
:50F:/12345678
1/SMITH JOHN
2/299, PARK AVENUE
3/US/NEW YORK, NY 10017
5
MPG FATF R 16 #4: The use of field 50a with Option K
Option K is used to provide ordering customer information, in a less structured format. Correct use of
option K is an acceptable means of complying with FATF recommendations.
Option K – Usage
Subfield 1 ‘Account’ must include the account number of the ordering customer, preceded by a slash.
Subfield 2 ‘Name & Address’ must include the following information:
The first line must carry the name of the ordering customer and the following lines are for address details
of the ordering customer in accordance with the generic format specifications for a 4*35x field.
PMPG recommendations:
• If no account number is available, then subfield 1‘Account’ must carry a unique transaction
identifier, preceded by a slash.
• It is preferred that the last line of the subfield 2 ‘Name & Address’ starts with a slash ‘/’ followed
by the ISO country code of the address verified as part of the customer due diligence of the
related customer, followed by a slash ‘/’,complemented with town, postal code, country
subdivision, etc.
:50K:/BE68539007547034
DUPONT MARTIN
AVENUE DU LAC 26
/BE/BRUSSELS-1000
6
MPG FATF R 16 #5: The use of field 59a with Option A
59A is appropriate when the beneficiary customer is a corporation with a non-financial institution
Business Identifier Code (non-financial institution BIC) assigned to it.
The second scenario where 59A is appropriate is when a bank makes payments in favour of another
bank acting as a corporate and the bank’s Business Identifier Code (financial institution BIC) is used as
the identifier.
Option A – Usage
Subfield 1 ‘Account’ if present2 must include the account number of the beneficiary customer, preceded
by a slash.
Subfield 2 ‘Identifier Code’ must include the registered BIC of the beneficiary customer.
:59A:/SE1350000000054910000011
WXYZSESS
7
MPG FATF R 16 #6: The use of field 59a with option F
Field 59F provides the possibility to structure clearly the beneficiary customer information in order to
facilitate anti money laundering (AML) screening and controls, which secure the business applications
of banks. For these reasons, in absence of a BIC, it is the preferred option.
Option F – Usage
PMPG recommendations:
• If no account number is available, then subfield 1 ‘Account’ must carry a unique transaction
identifier, preceded by a slash’.
• It is preferred3 that the last line starts with number 3 followed by a slash ‘/’, followed by the
ISO country code of the beneficiary customer’s address, followed by another slash ‘/’ and
complemented with town, postal code, country subdivision, etc.
Option F – Preferred example: account number with name, address and country code/town
:59F:/12345678
1/SMITH JOHN
2/299, PARK AVENUE
3/US/NEW YORK, NY 10017
8
MPG FATF R 16 #7: The use of field 59a with No letter Option
Field 59 without letter option (in free text format) is appropriate when the beneficiary customer cannot
be identified with any structured identifier such as a Business identifier code (BIC). Correct use of the
No letter Option is an acceptable means of complying with FATF recommendations.
It may also be used when a specific format is required for regulatory reason.
Subfield 1 ‘Account’ must include the account number of the beneficiary customer, preceded by a slash.
Subfield 2 ‘Name & Address’ must include at least the name of the beneficiary customer.
PMPG recommendations:
• If no account number is available, then subfield 1 ‘Account’ must carry a unique transaction
identifier, preceded by a slash.
• It is preferred 3 that the last line of the subfield 2 ‘Name & Address’ starts with a slash ‘/’
followed by the ISO country code of the beneficiary customer’s address followed by a slash ‘/’,
complemented with town, postal code, country subdivision, etc.
:59:/BE62510007547061
JOHANN WILLEMS
RUE JOSEPH II, 19
/BE/BRUSSELS-1040
3
For good order’s sake, please note that the inclusion of the beneficiary customer’s address represents best practice but is not required by
FATF R 16
9
4. Frequently Asked Questions
A: It is the account owner as specified in the ordering institution’s books 4, more commonly referred to
as the Debtor.
A: It is the account owner in the books of the beneficiary’s institution4, more commonly referred to as
the Creditor.
Q3: Is it acceptable if my applications only support the preferred option F for field 50a?
Q4: How do I specify the address if there are no streets or street numbers involved?
If only the street number is missing, it is preferred3 the street name is combined with the town and
country. In case of fields 50F and 59F, this means that ‘Name & Address’ field carries:
• The name of the ordering, respectively beneficiary, customer (on the first line(s) after "1/"),
• The street name (on the next line after "2/") and
• The ISO country code and town name of the customer’s address verified as part of customer
due diligence (on the next line after "3/").
If the street number and the street name or only the street name are/is missing, and an alternative piece
of information for the street name (for example, a P.O. Box) is available, then it is preferred to give a
combination with the town and country. In case of fields 50F and 59F, this means that ‘Name & Address’
field carries:
• The name of the ordering, respectively beneficiary, customer (on the first line(s) after "1/"),
• The alternative piece of information, e.g. P.O. Box (on the next line after "2/") and
• The ISO country code and town name the customer’s address verified as part of customer due
diligence (on the next line after "3/").
If the street number and the street name or only the street name are/is missing, and no alternative for the
street name is available, then it's preferred3 that in fields 50F and 59F, the ‘Name & Address’ subfields
carry :
• the name of the ordering, respectively beneficiary, customer (on the first line(s) after "1/"),
• the ISO country code and town name of the customer’s address verified as part of customer due
diligence (on the next line after "3/").
4
This Market Practice Guidelines is centered on FATF R 16 and on the correct qualification of the ordering and beneficiary customer fields.
However the PMPG recognizes that both the evolution in standards (like e.g. IS020022, SEPA standards) and in the rules to combat money
laundering and the financing of terrorism imply a wider reflection on the additional information represented by the "ultimate ordering
customer" and "ultimate beneficiary customer". In some countries’ legislation this information is already mandatory and there is a common
interest for a deeper reflection in evaluating this evolution in the market and regulatory practice.
10
If this is done, it should be clear that the identification of the person and the country and town are
sufficient to uniquely identify the ordering / beneficiary customer.
Note that e.g. the Australian AML/CTF legislation states P.O. Box not be used in lieu of full business or
residential address. Accordingly, any inbound message to Australia containing a P.O. Box might be
queried, delayed or rejected. Similar requirements may exist in other countries.
A: In certain regions the name of the ordering customer or of the beneficiary customer indeed does not
fit onto a single line of an MT ‘Name&Address’ field with format 4*35x. This length issue has been
addressed in the ISO 20022 payments messages where the name has been extended to 140 characters.
In the meantime, there are several options to cater for long names.
For a field 50K, the name can be continued on a second line of the 4*35x field. If a line break is
necessary, the line break should be created only between words but not within a word:
:50K:/BE68539007547034
SHOE SHINE IMPORT AND EXPORT
ZANG MI TRADING CORPORATION
AVENUE DU LAC 26
/BE/BRUSSELS-1000
However, the second line in the example above might not be recognized as continuation of the name
due to the free format of the field.
This issue can be solved by using field 50F for the ordering customer and field 59F for the beneficiary
customer where the information on the ordering customer / the beneficiary customer is respectively
structured by using numbers at the beginning of each line of the field.
A number "1" followed by a slash is used to indicate that following text is the name of the ordering
customer / the beneficiary customer respectively. If more than one line is needed to provide the complete
information, the number "1" followed by a slash has to be repeated on several lines to indicate that the
name of the ordering customer / the beneficiary customer respectively is continued.
When using 50F and 59F, the same example will become:
:50F:/BE68539007547034
1/SHOE SHINE IMPORT AND EXPORT
1/ZANG MI TRADING CORPORATION
2/AVENUE DU LAC 26
3/BE/BRUSSELS-1000
A: While not a very common issue, in certain regions the country and town of the ordering customer
indeed does not fit onto a single line of an MT “Country and Town” field with format 4*35x. This length
issue has been addressed in the ISO 20022 payments messages where this field has been extended to
140 characters. In the meantime, there are several options to cater for long addresses.
:50K:/68539007547034
HIDALGO IMPORT AND EXPORT
Calle Guerrero 26
/MX/Dolores Hidalgo Cuna de la
Independencia Nacional
11
:50F:/68539007547034
1/HIDALGO IMPORT AND EXPORT
2/Calle Guerrero 26
3/MX/ Dolores Hidalgo Cuna de la
3/Independencia Nacional
The same approach has to be used for field 59F; for instance:
:59F:/68539007547034
1/HIDALGO IMPORT AND EXPORT
2/Calle Guerrero 26
3/MX/ Dolores Hidalgo Cuna de la
3/Independencia Nacional
Q7: Does the IBAN of the beneficiary replace the BIC of the bank holding the related beneficiary
account?
A: No, field 57a designates the bank where the beneficiary customer account is open any time the
receiving bank (designated at the header level of the FIN messages) is different from the beneficiary
customer one.
In order to process a credit transfer in a STP and secure manner, the BIC of the beneficiary customer’s
bank is required and this is the case even when the IBAN of the beneficiary customer is quoted in field
59a.
Q8 - Where no account number is available, what does the unique transaction identifier represent?
A: The unique transaction identifier would represent a reference which allows the transaction to be
traced back to the ordering customer. This would also allow the ordering institution to identify the
original payment during any Exception and Investigation exchange, enabling a common understanding
of the payment transaction being referred to. This could remove the need to change Exception and
Investigation messages with the previous party in the payment chain using the point to point sender’s
reference.
12
5. Observations and Recommendations (to be possibly updated
depending on FATF guidelines if any)
6. Revision record
Revision Date Author Description
1 Sept 2015 PMPG Update in MPG #3
2 Sept 2016 PMPG Update to say that field 59F has now been implemented since
Nov 2015
3 Dec 2017 PMPG Updates across Market Practice Guidelines to provide
clarification. Furthermore, alignment of required address
information with The Wolfsberg Group’s Payment Transparency
Principles
4 Dec 2018 PMPG Updates to take into account the reverse of the scheduled
removal of free format text options in Fields 50a and 59a
13