Processing a payment for banks used to be all about getting the instruction to the next party in the payment chain. Straight-through Processing (STP) was synonymous with not touching the payment in your own shop regardless if the payment was causing issues downstream at other banks. Over the years, this model has changed due to increased regulation and compliance requirements, and just knowing debit and credit parties and amounts are not sufficient. Anti-Money Laundering (AML) analysis requires banks to understand transactions and country flows. Data Quality in all fields of the payment order becomes paramount.
Two segments of a payment order have been subject to increased scrutiny: Ordering Party and Beneficiary (debtor and creditor in ISO 20022 terminology) and the purpose of the payment. However, while party details are subject to specific international regularity recommendations such as FATF 16, the purpose of payments discussion has been mainly a concern for local regulators without much international compatibility discussion.
This paper primarily focuses on the current state of the purpose of payment codes and their challenges in the international payments environment. In particular, we will look at the challenges in the current MT messages and the efforts of the industry to standardize them. Special consideration will be given to the upcoming ISO 20002 migration and the impact on interoperability.
Purpose of Payment Codes
While payment purpose codes are nothing new and have been in existence since the last century to support central bank reporting requirements, their use has initially been declining. However, they are getting a new life as some markets like China and India have introduced new requirements for their use. As their definition and use are driven by various local regulators, no standard exists. For example: South Africa uses a five-digit numeric code while China has implemented a five-character alphanumeric version. Definitions vary, and are overlapping in some cases. Jordan has a purpose code 0801 for Telecommunication Services, 0803 for Information Technology Services, and 0807 for Marketing and Media Services. Selecting the right code for “storing videos in a cloud-based service” becomes a real challenge in this case.
The examples above illustrate how difficult it is for the ordering party to select the right code and for the regulators to have assurance that the codes being used provide high quality data. Let’s look at key aspects of data quality:
Issues with data quality:
Completeness: Data is missing or unusable
Conformity: Data is stored/transported in non-standard format
Consistency: Data values give conflicting information
Accuracy: Data is incorrect or out of date
And apply it to POP codes:
|Data Quality Attribute||Relevance to POP Codes||Current Issue|
|Completeness||Is the user in possession of the various codes?||As POP codes are very local, the ordering party will in most cases struggle with obtaining the relevant code list.|
|Conformity||Can the code be transported consistency in different payment message types?||As we will see in the next section, this is really the biggest issue between message types.|
|Consistency||Can codes be used across countries in a consistent manner?||As code lists are local, conflicts can arise if regulators from the sender and beneficiary country have different code requirements.|
|Accuracy||Do all parties have access to the most recent code list and is the right code being used?||The sender will have difficulty knowing if the codes are correct and the most current.|
So, who owns the accuracy of the purpose of payment codes? The sender initiates the payment and should know what class of services is being paid for; however, the lack of standards makes it difficult for the sender to comply and they would need to rely on the beneficiary to advise the correct code. But from an accuracy perspective, that might be problematic if the wrong code is communicated. For financial transactions, the sender is probably best suited to determine the right code.
Fit for purpose and existing standards
As highlighted in the table above, the challenge is to decide. Which field should one use for payment purpose codes in cross-border transactions? Should the code be populated in field 26T, 77B, 70, or even field 72? The answer to this question varies and depends on the geography of the payment parties. In some markets, 26T is not supported by local banks; hence, a generic field such as field 72 is recommended, which runs counter to efforts in other markets that would like to restrict the use of this free format field.
Field 26T MT103
The definition of this field stipulates that it should be used to identify “the nature of, purpose of, and/or reason for the individual transaction; for example, salaries, pensions, dividends” and a three-character code can be used. While the field definition is describing the purpose of the payment, what is interesting to note is that most of the codes that local regulatory agencies have defined are longer than three characters (UAE has three). In some cases, the purpose of payment is a free text description. Also, the current three characters do not allow referring to a specific issue of a code list. In summary, the existing filed 26T is not adequate to house the payment purpose codes in use.
Most markets have hence selected a free format field 70 or 72 to include the purpose of payments code.
Field 77B MT103
The regulatory reporting field provides more options as it is more general and allows for “regulatory information required by the authorities in the country of Receiver or Sender.” However, restricting the use to the sender and receiver is misleading as in most cases, the purpose of payment needs to be advised to authorities in the country of the beneficiary or ordering customer (or bank). The field size at least of 3 X 35 characters makes this field more suitable for purpose of payment codes as it can capture multiple codes and country codes.
In some markets, 77B is not supported by local banks; hence, a generic field such as field 72 is recommended, which runs counter to efforts in other markets that would like to restrict the use of this free format field.
The MT202 does not offer field 26T or 77B; hence, users need to place payment purpose related information in field 72.
ISO 20022 external code list
In pain and pacs messages, a field purpose ( < purp >< cd > ) in the CreditTransferTransactionInformation < cdttrftxinf > segment references an external code list (ExternalPurpose1Code), which contains 162 purpose of payment codes covering various aspects of payment transactions. As this is an external codes list, maintenance can be done quarterly if codes need to be added. The codes contain a definition but do not follow a consistent taxonomy. More work will need to be done to ensure the industry has a more consistent framework in assigning these codes.
Agreeing on a standard list of codes and definitions will make it easier for users to pick the right code and manage against a complete list. The standard list would also enable local regulators to map against the global list and identify gaps that then can be added to the external codes list.
Reality in the field
Lack of guidance by the global community and absence of standardization has led local regulators to come up with their own recommendations and requirements where codes are to be placed. The current unstructured approach leads to an increase in inquiries and payment delays.
More countries are adding requirements around purpose of payment information. Recently, Cambodia announced the requirement to include the purpose of a payment.
Search for the missing payment purpose codes: Semantic Model
Having a standard code list is a start, but gaps exist. For example, codes are in place to advise that a payment relates to transportation by Air, Railway, Bus, or Ferry but no codes exist for truck or vessel. Some codes are very granular, like differentiating between an E-Purse Top Up and a Mobile Top Up, while others are broad, like Costs.
While these cases have been developed with the input from different communities, it would be good to look at this from an overall standardization perspective that keeps these codes at the same level of granularity, or introduces a hierarchy to them (like the service codes in the BankServicesBillingStatement message). From a standards perspective, this is desirable but also a significant task.
The chart on the left provides an illustration of this approach by establishing categories and a hierarchy. Well defined categories with adequate descriptions and code descriptions should make it easier for communities to map local codes and decide if the global codes are sufficient for their needs or identify gaps that should then be closed through the regular quarterly maintenance process of external codes list.
How do we map from ISO 20022 to legacy standards?
More RTGs systems are adopting the ISO 20022 standard for payments. Once USD and EUR payment systems have migrated, a large part of value and volume of international wires will be conducted in the ISO 20022 format. However, for cross border payments, the existing MT messages will still dominate; hence, intermediary banks will be faced with the problem to map incoming ISO 20022 messages into the existing legacy standard. One challenge will be where to map the purpose code field, which exists in Customer Credit Transfer and FI to FI credit Transfer to the correct field in MT103 and MT202 messages. Absent any standard change in the MT messages, a market practice will need to be agreed upon as to how to accomplish this.
Standards development can only provide us with fields, codes, and descriptions but the actual usage will require agreement on market practice. One such practice could be to use the global codes list and require that the mapping to the right local codes should be the responsibility of the beneficiary bank or the beneficiary.
Of course the payment details as well as the global codes need to be granular enough to enable the mapping. (Example: differentiation between resident and non-resident creditor is better done by the creditor agent.)
Purpose of Payment Codes need to serve multiple masters in the future. While initially the focus has been on the beneficiary bank country compliance, requirements in the interbank chain to have more insights into what the gets paid will require a more globally consistent approach. So far, requirements and standards have been driven locally, but the myriad of codes make it difficult for the originator of the payment to make the right decision what to use and when. Resulting data quality issues should also be a concern for the authorities requesting the usage of these codes. If the users of these codes want to be able to aggregate payment data domestically and cross border, and use the data for policy decisions with some level of quality assurance, then a more standardized approach should be promoted.
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.