Cover Payment Enhancements Aimed at AML Vulnerabilities
August 25, 2008
Swift, in response to industry concerns, is bringing increased transparency to cover payments--a particularly vulnerable part of the global payments system--with an enhanced message format that identifies both the party sending the funds transfer and the bank receiving it.
"The term 'cover payment' applies to cases where the originator and beneficiary banks do not have a direct beneficiary relationship," explained Jim Wills, business manager for standards at Swift. "So they have to work through correspondent banks."
Because cover payments, which are often used for international transactions, can mask the source and destination of a transfer as it passes through a chain of banks, they increase the risk of an institution unknowingly facilitating illicit activity. While the identifying information is contained in MT 103 messages, correspondent banks can only see the MT 202 part of a cover payment, which does not include such data.
In 2007, Wolfsberg Group, an association of global banks that promotes anti-money-laundering standards, requested that the MT 202 messages be updated. Though Wolfsberg asked Swift for an enhancement in 2008, the messaging cooperative determined that more time was needed for the change and is rolling out the beefed-up MT 202s as part of Standards Release (SR) 2009.
Swift will introduce "a variant of the MT 202 bank-to-bank message ... called a 202 cover payment message, or 202 COV," said Wills. "Within that message, Swift is adding fields so that the originator and the beneficiary of the transaction can be identified. There will also be the ability to add remittance information. If there were more banks involved in the chain, those intermediary banks would be included."
Nine fields will be introduced in SR 2009 for the MT 202 COV messages, which will go live Nov. 21, 2009. Though the fields are designed for tagged data, two will accept free-text entries. "Field 70 typically relates to the remittance and the purpose of the remittance," said Wills. "Field 72 is really a bank-to-bank field that can contain free-text information. Those free-text fields will ... include information on the originating customer and the beneficiary customer."
"Swift's introduction of a new message type is intended to enable remitting banks to choose a message type that will overcome the lack of transparency in cover payments," said the head of group compliance at a large investment bank in London. "This would apply regardless of currency or country." The executive asked for anonymity because of concerns across the industry about the cost of the changes.
Nancy Atkinson, senior analyst at Boston-based Aite Group, said the initiative will extend beyond next year. "The November 2009 data is the first of two implementations that are iterative," she said. "Cover payments are messages between banks, not corporations. Therefore, firms will not be involved in this first change."
According to Atkinson, 202 COV was delayed until 2009 to give Swift, the Federal Reserve, the Clearing House Payments Co. (TCH), the vendors supporting them and global banks time to convert their systems. "Given the broad reach of Swift, that can be time-consuming and has the potential to create problems if not managed thoroughly," she said.
Remittance Data
The original driver for the upgrade, said Atkinson, was the need to add remittance information to wire transfers to help post corporate payments. TCH's Clearing House Interbank Payments System (Chips) and the Federal Reserve's Fedwire had been looking at the International Organization for Standardization (ISO) 20022 format and Electronic Payments Network (EPN) STP 820 standard as models for providing more remittance data, she said. "They initially started down the EPN path, with the plan to migrate to ISO 20022 over time," she noted. "However, even if Fedwire and Chips had the data, it is essential that Swift can support the data as well, or it may be truncated on international transactions."
