Data quality has become a hot topic in payments. Partially driven by compliance needs but also big data projects, the request for highly accurate data is increasing. Data fidelity means that as data travels from the point of origination to consumption, it retains its granularity and meaning. While format might change for data in transit, the goal is to ensure that its meaning remains unaltered.
To illustrate the issue let’s look at the following scenario:
- Person 1 types the name Frank Reich on a piece of paper and hands it to person 2 with the request to reproduce it.
- Person 2 types the name but forgets a space — FrankReich — and hands it to person 3.
- Person 3 reviews the message and corrects the spelling to Frankreich before handing it to Person 4.
- Person 4 who has lived a long time in Germany is asked what the paper reads and he says: France.
The issue here is the data was transmitted in free format text and none of the processors (people in this case) had any context what this data element was supposed to mean. Differentiating geographic names from company and individual names is especially critical in sanctions screening and AML. Differentiating between whether Cuba is the country or the first name is important. In this article, we will explore in more detail the recent industry developments and discussions around party fields in payment orders.
Finding your place in the world
In the absence of a globally unique identification scheme (for legal entities it is emerging as the LEI), the traditional way to identify an individual or legal entity is by:
- Name. For individuals First Name, Last Name
- Street Address. Comprised of dwelling identifier (e.g. apt number), building number and street name. In some jurisdictions, a PO Box is acceptable as well, or a building might have a unique name.
- City and Postal Code
Of course, another mechanism to identify a location is latitude and longitude, methods that are used in our GPS systems and phones. But while these are great for identifying a place on earth in the two dimensional space, no clear standards exist to identify a specific dwelling in a multi-story or tenant building.
The free format trap
Ideally, all key data elements should be identified separately and concatenations should be avoided. This starts already with the name. Having clarity what the first and last name is will make it easier to differentiate between Frank Madison and Madison Frank. However, having dedicated fields will increase the size of the underlying message. This is probably the best explanation of why in the initial design of SWIFT messages, the name and address field did not have any specific format or subfields. Free format text provided the most flexible way to accommodate various name and address formats and sizes. This is especially relevant in the case of limited field sizes like in the ordering party and beneficiary field in traditional SWIFT messages. The downside is that it can be more ambiguous and difficult to validate if all the required information is not present.
The dreaded F option
Heightened regulatory scrutiny has motivated the payments community to address the issue by eliminating the free format option in 2020. The industry will need to move to a more structured address format such as field 50F and 59F. Of course, field 50A and 59A are still appropriate when the ordering customer or beneficiary is a corporation with a non-financial institution Business Identifier Code (BIC) assigned to it. In most cases, however, parties will not have BIC identifiers and hence the F option will need to be used. The recommended1 usage is:
|Subfield 1 ‘Party Identifier‘||/(Account) or (Code)(Country)(Identifier)
1/Name of the ordering customer
|Subfield 2 ‘Name & Address‘|
The relevant aspects of these subfields are:
- Dedicated subfields for name, address (e.g. street and building), and town & country
- Use of the ISO country in subfield 3
- Other code options for identification numbers ad date and place of birth
At the moment, the size of the party field is not changing and we still need to accommodate the relevant information in 4×35 characters. From a data population perspective, it will be important to decide how name and address information is populated should the line size be not sufficient (example: name or address is longer than 35 characters). In these cases, the subfield tag can be repeated in another line. For more technical details, please review the PMPG market practice guidelines and the BAFT Best Practices and Guidance: Formatting Payments and Handling Inquiries Related to FATF Recommendation 162
The payments industry is contemplating an expansion of the party fields, either in the number of lines, or the length of each line to accommodate longer names and avoid truncation issues. Payments on behalf of (POBO) and receiving on behalf of (ROBO) create further challenges as traditional MT 103 messages do not have fields for ultimate debtor and creditor parties, further increasing the need for either additional fields or more lines in existing party fields.
The party is on ISO 20022
Looking further into the future, the industry needs to consider the upcoming adoption of ISO 20022 in the correspondent banking space. Granularity of party fields will need to be discussed in this context once more.
For example, in ISO 20022, the structured option to represent parties has a name field of 140 characters and very detailed subfields for the address data3:
- CountrySubDivision (e.g. States, Cantons, Provinces)
While the F option provides a subfield for town and country postal codes, states and provinces, and building numbers were not tagged specifically. Overall, it would be ideal to have separate fields for first and last name. ISO 20022 does have a field to label an address as residential versus a business address so that might help as well.
At this time, it is not known when the industry will switch to ISO 20022 for interbank payment orders, but many local payment systems have embarked already on the journey. The U.S., Canada, and the euro zone have firm plans in place to migrate to the new format, and Switzerland and Japan have done so already. By 2022, the majority of high value payments will be settled via ISO 20022 compliant payment systems4.
Where do we go from here?
While domestic requirements on name and address information will vary in the international context, we are on a path for ever more granularity. To position an organization for these changes, it will be best to implement the most granular data format so that it is easier to generate other less stringent formats.
For example, going from the ISO 20022 address fields to the F option in the MT messages will be easier than when starting with a free format field.
|ISO 20022 structure||F option structure||Free format|
2/115 125 TH ST
3/US/NEW YORK,NY 10027
115 125 TH St
NEW YORK, NY 10017
The first step in this endeavor is to inventory all existing sources of payment party data and identify which systems house the gold copy of such information. For beneficiary details, this will, in most cases, be the customer. If the customer is using a bank owned interface such as an electronic banking system, then these need to be modified to capture structured address data if they still allow unstructured data. In the event that payment files are received from a customer’s ERP system, then this change will not be just dependent on the bank’s system, but the corporate customer and their vendor will also need to adjust their payment output formats.
It is also recommended that cross border payments use the ISO country codes in the beneficiary and ordering party field. In Electronic Banking systems, it might be best to provide country code selection lists for the user.
When populating field 50 and 59 if the content exceeds the available space, then follow the earlier referenced guidelines provided by BAFT and PMPG.
Some countries do not like PO Boxes in payment party messages and it will be best to ensure full street addresses are available. This recommendation will be easier to address in the ordering party field but might be harder to accommodate in the beneficiary field.
All these technical changes and requirements will need to be supplemented with a customer education campaign. Some end-user customers might not be willing to update their internal data bases and systems, but it will be important to point out the benefits such as avoiding delays in payment execution and investigation fees.
The year 2020 might sound like the industry has plenty of time to adjust to these changes, but this is really not the case. The scope of the changes and number of systems impacted might vary by bank, but in most cases, this will be a multi-year effort including the required testing and customer engagement.
The preparation needs to start now in 2017 to gather the overall requirements and put budgets in place for 2018 and 2019.
1. PMPG Market Practice Guidelines for use of fields 50a Ordering Customer and 59a Beneficiary Customer to comply with FATF Recommendation 16
3. Additional subfields exist but in the article we want to focus on the most common ones.
4. A detailed map of global ISO 20022 payments initiatives is available at: https://www.iso20022.org/documents/adoption/Introduction_maps.ppt
Wells Fargo & Company provides financial services in Asia, Canada, and Latin America through its duly authorized and regulated subsidiaries. In Europe, banking services are provided through Wells Fargo Bank International (WFBI), directly regulated by the Central Bank of Ireland, and Wells Fargo Bank, N.A. London Branch, authorized by the Prudential Regulation Authority (PRA) and regulated by the Financial Conduct Authority (FCA) and the PRA. All products and services may not be available in all countries. Each situation needs to be evaluated individually and is subject to local regulatory requirements.
© 2017 Wells Fargo Bank, N.A. All rights reserved.