SWIFT Message MT202 COV: What are the background and impact points for banks?

Currently the messages MT103/103+ are used to effect a customer credit transfer and the MT202 is used for a financial institution transfer. In order to speed up the payment process for customer credit transfers, in some cases, an additional cover payment message (MT202) is sent to an intermediary bank whereas the underlying customer credit transfer (MT103/MT103+) is sent directly to the beneficiary bank.

The MT103/MT103+ can be sent directly to the next party in the transaction, who then sends the next MT103/MT103+ to the next party. This increases the time until the payment arrives into the beneficiary’s account. Cover payments and any bank to bank payments currently use MT202, but this does not contain fields for the originator of the credit transaction and this results in having unknown parties in the cover payment.

After 9/11, there were concerns that some institutions were deliberately altering or omitting details from payment messages in order to avoid detection. The suspicion was that this was occasionally being done at the request of individual customers or corporations.

The use of cover payments (MT202), where the details of the beneficiary and originator were not usually present, represented a significant risk, particularly in situations where the underlying payment message (MT103) went directly to the beneficiary bank, often without passing through the same jurisdiction or filtering processes as the underlying MT202.

With the increasing concerns about the transparency of the global payments system, the desire was to produce a solution to the transparency challenge in a manner that:

1. Did not disrupt the financial services sector.
2. Allowed the valid business purpose of cover payments to continue and yet provided assurance to regulators and governments that the system was appropriately secure.

To allow easy tracking, a new variation of SWIFT message type, MT202 COV, will be introduced on 21 November this year, containing mandatory information fields for both the originator and beneficiary of a payment.

Due to the availability of this new message type MT202 COV, MT202 should not be used any more to order the movement of funds related to an underlying customer credit transfer that was sent with the cover method. However, the previous stated workaround should still be available to the users and MT202 should only be used for financial institution transfers without underlying customer credit transfer.

Flow of Events for MT202 COV

The flow of events in an MT202 COV can be illustrated with the below example:

Value 27 May 2009, Mr. Big orders Bank A, Brussels, to pay an invoice with number 1234 of US$10,500 to Mr. Small who has an account 987654321 with Bank B, London. Bank A processes this transaction through the cover method by sending:

1. A customer credit transfer message MT 103 to Bank B, using reference 090525/123COV.
2. A message MT 202 COV with reference 090525/124COV for the US dollar payment to its US dollar correspondent Bank C, New York, for credit of Bank B, London, on their account 123444555 at Bank D, New York.

“After 9/11, there were concerns that some institutions were deliberately altering or omitting details from payment messages in order to avoid detection. The suspicion was that this was occasionally being done at the request of individual customers or corporations”

SWIFT MT202 COV – High-level Impact Points for Banks

Business practices

With the emphasis on transparency, banks need to amend/update their business practices to ensure that all originator and beneficiary information remains unchanged right from receipt of customer instructions to generation and transmission of the MT202 COV message. The following are the impact points:

• Filtering rules – While defining filtering rules for incoming and outgoing payments, banks need to take into account the new MT202 COV message that is being introduced.
• Post-payment regulatory screening practices – KYC/AML/OFAC screening needs to be extended for MT202 COV. Screening processes must also be rigorous to ensure that messages are not stopped and reported by intermediary banks in the payment cycle.
• Repair practice – For the banks that have automated repair and reprocess capabilities, a new business rule needs to be put in place for MT202 COV validation.
• Funds control practice – Banks need to enhance their Funds Control practice to ensure that the beneficiary customer is paid only when the bank has received a notification that settlement of cover transactions is confirmed OK. Matching of payment versus cover message has to be robust to reduce settlement and operational risk.
• Late payments and compensation practice – Downstream institutions in the payment value chain are likely to have more alerts to investigate as increased information is available in MT202 COV, which in turn impacts processing times. This might result in extended payment cycles and banks need to adjust their late payments and compensation policies and practices in line with new industry standards.
• Cover payment risk management rules – Banks need to amend/update their operational workflows to ensure that sender/ beneficiary information on all cover payments are being checked. Banks need to put in place business rules and validations for cover payments, as required by the enhanced transparency and details available in MT202 COV.
• Statements and advising – Banks need to modify the layouts/placeholders of their customer advice and statements to capture/populate the additional information that will be available from the MT202 COV.
• Amendments, cancellations, investigations practices – Banks need to amend their KOPs relating to amendments, cancellations and investigations practices to ensure that MT202 COV is also covered.
• Legal implications – Upgrade controls related to payments processing to avoid compliance breaches that might result in penal action/bad publicity.

Technical impact

All SWIFT member banks need to enhance their systems to populate and receive the MT202 COV minimal impact on existing application environment in the bank. The following are the impact areas for banking systems and applications:

• Customer access/channel management – Banks have integrated channels for customers to initiate payments. These channels need to be enhanced to ensure that they collect and populate necessary originator and beneficiary information as required by MT202 COV in all payment initiation requests.
• Messaging systems – Banks will have multiple messaging systems across the globe based on geographic convenience, country/region-specific back-end systems, etc. Banks need to enhance IT infrastructure across the globe to enable messaging systems to send and receive new MT202 COV messages.
• Clearing interfaces (non-SWIFT based CSMs) – Since MT 02 COV requires that the payment information should travel with the cover payment as well (unlike the earlier MT202), local clearing systems would need to be extended to cater for the additional information and this requires change to local clearing system interfaces.
• Payment processing engines – Banks need to upgrade payment processing engines to create and send new MT202 COV messages and also to have the capability to receive and process the MT202 COV.
• Regulatory filtering applications – Enhance sanctions processes to avoid significant increases and alerts to investigate. Name filtering against multiple sanction and watch-lists.
• Pricing and billing applications – New message type MT202 COV to be added to the rule based attributes of pricing/billing engines.
• Post-payment regulatory screening applications – Almost all banks have payment systems that do regulatory screening after the transaction has been input. The screening happens before the payments are released into the Swift Alliance Gateway (SAG) and the screening has several dimensions – the local, regional, Global KYC/AML/OFAC/FATF screening. Banks need to ensure that MT202 COV messages are also screened for all regulatory sanctions.
• Historical databases and archiving applications – Banks need to define a new parameter in their databases for handling the new message type. They also need to define the purge criteria for MT202 COV as per their existing retention and back-up requirements.
• Investigations systems – Banks that have automation in place to process common payment exceptions without manual input need to extend the logic for MT202 COV. These post settlement events are typically:

1. Beneficiary claims non-receipt of funds.
2. Beneficiary is unable to apply the funds.
3. Additional information required.
4. Return of funds.
5. Compensation claims.
6. Incorrect payment details.

• Nostro reconciliation systems – When banks reconcile ledger account statements with the nostro account statements, the tracking system that is used needs to cater to the new MT 202 COV in addition to MT 202.

Read more GTNews articles on payments here and more on technology here.