Cover payments: where the originator data goes on each leg

A cover payment is a cross-border transfer in which the originator's bank sends the customer's payment message directly to the beneficiary's bank and routes the money separately, through one or more correspondent banks, in a bank-to-bank "cover" message. Because the two travel apart, the correspondents that move the funds historically saw only two banks' names and an amount, not who was paying whom; since November 2009 the cover message has had to carry the originator and beneficiary data (MT 202 COV on SWIFT, a pacs.009 cover in ISO 20022), and US supervisors expect a cover intermediary to screen it, monitor it for blank and meaningless fields and act on what it finds. Botminds' Funds Transfer Recordkeeping & Travel Rule reads the cover leg as well as the customer leg, judging each required field on pacs.009 cover messages as it does on pacs.008s, and keeps the requests, replies and decisions on one file per wire.

What is a cover payment?

The Basel Committee's 2009 paper gives the classic description. Cover payments "are used by a bank to facilitate funds transfers on behalf of a customer to a beneficiary, most often in another country", typically where the payment is in a third currency and the two banks have no relationship that lets them settle directly. "In this circumstance, the originator's bank may directly instruct the beneficiary's bank to effect the payment and advise that transmission of funds to 'cover' the interbank obligation created by the payment order has been arranged through a separate channel" (BCBS, May 2009, paragraph 2).

The reason banks use it is speed and cost: the most frequent use, the paper says, is "to avoid the delays associated with differences in time zones between the originator's bank and the beneficiary's bank and to reduce costs of commercial transactions." The beneficiary can be paid before the banks have settled. FATF's revised Recommendation 16 now defines a cover payment as one that "combines a payment message sent directly by the ordering financial institution to the beneficiary financial institution with the routing of the funding instruction (the cover)" through one or more intermediaries (FATF, revised R.16 glossary).

Serial vs cover payments: what is the difference?

In a serial payment the customer message and the money move together, bank to bank, so every intermediary sees the full customer data. In a cover payment they split, so the intermediaries on the money leg see only what the cover message carries. FATF defines a serial payment as "a direct sequential chain of payment where the wire payments or value transfer and accompanying payment message travel together from the ordering financial institution to the beneficiary financial institution directly or through one or more intermediary financial institutions (e.g., correspondent banks)."

Where the originator data goes, leg by leg

Follow one invented payment. Orla Têxteis Lda, a textile maker in Porto, pays USD 46,200 to Mesa Verde Packaging S.A. de C.V. in Monterrey. Its bank, Banco Ribeira Alta, has no dollar account with Banco Sierra Clara, the Mexican beneficiary's bank, so it sends the customer message straight to Banco Sierra Clara and routes the dollars through its New York correspondent, Harrowgate Trust Bank, which pays them to Banco Sierra Clara's correspondent in Houston, Alder Point Bank. All four banks and both companies are fictional.

Before 2009, the cover leg in this example would have been an MT 202 naming Banco Ribeira Alta and Banco Sierra Clara and nothing else. The Basel Committee described the problem: transparency "is limited when the message format used to settle the interbank payment (in the example, below, a SWIFT MT 202) does not contain information about the originators and beneficiaries", leaving the cover intermediary "unable to screen transactor information against locally applicable lists" (BCBS 2009, paragraph 4).

There is also a risk that such messages could be chosen on purpose to conceal the names of parties to a transaction.

Basel Committee on Banking Supervision, 2009

Two things can still go wrong at Harrowgate Trust Bank in this example. The data can arrive blank or meaningless, because Banco Ribeira Alta's systems filled the cover from a template rather than the customer message. Or it can arrive complete and leave altered, because Harrowgate reformats it when it builds its own message to Alder Point. The first is a monitoring question; the second is a travel rule question for Harrowgate itself.

What is MT 202 COV, and how does it differ from MT 202?

The MT 202 COV is the SWIFT variant of the bank-to-bank transfer used when the transfer covers a customer payment; it carries mandatory fields for the originator and beneficiary. The federal banking agencies explained in 2009 that the existing MT 202 "will remain effective for bank-to-bank transactions but should not be used for cover payments", that "For all MT 202 payments for which there is an associated MT 103, the MT 202 COV will be mandatory and must be used," and that it took effect on November 21, 2009 (interagency guidance, 2009). A COV variant was also made available for the MT 205.

The agencies went further than SWIFT for US banks. They expected the MT 202 COV "to be used by U.S. originators' banks for all cover payment transactions for which there is an associated MT 103, whether or not they are cross-border transfers," and said a bank's procedures "should address the appropriate use of the new message format for transactions in which the bank acts as the originator's bank." Using a plain MT 202 when the COV is available and appropriate is, in their words, "inconsistent with the Message Standards" that the Wolfsberg Group and the New York Clearing House set out in 2007.

Does the travel rule apply to cover payments?

Yes, to the underlying customer transfer. The bank-to-bank exception in the funds transfer rules covers transfers where both the originator and the beneficiary are banks; a cover message moves money between banks, but on behalf of a customer originator and a customer beneficiary, and the agencies wrote in 2009 that "Where the travel rule (31 CFR 103.33(g)) applies to a funds transfer by a U.S. originator's bank, compliance can be achieved by including the required information on the MT 202 COV." The rule they cited is today's 31 CFR 1010.410(f).

For a US cover intermediary like Harrowgate, the travel rule duty is the intermediary's: include in its own outgoing order the items it received "if received from the sender" (31 CFR 1010.410(f)(2)). It has no duty to obtain data Banco Ribeira Alta did not send. Its further duties, to screen and to monitor, come from sanctions law and from supervisory expectations for correspondent banking, which is why the guide on who owes which field in the funds transfer rules treats the intermediary's role separately.

What must an intermediary bank check in a cover payment?

Four things, under the 2009 guidance: screen the parties, make sure the fields are not blank, monitor for fields that are manifestly meaningless or incomplete, and factor the correspondent's messaging practice into its risk assessment. None requires the intermediary to verify that the data is accurate; the agencies said explicitly that neither the SWIFT change nor the Basel paper asks intermediaries to check that the data in the fields is true (originator information on wire transfers quotes the passage).

The Basel paper sets out what to do when a field fails: contact the originator's bank or the preceding intermediary, consider restricting or ending the relationship after repeated incidents, and file a suspicious activity report where the local definition is met, documenting the reasons. It is also realistic about what an intermediary can know: "As neither the originator nor the beneficiary are the cover intermediary bank's customers, the cover intermediary bank is usually not in a position to understand the purpose of such transactions," but it can monitor patterns, and where they point at a correspondent, review the relationship (BCBS 2009, paragraphs 30–31). The test for a meaningless field is explained in the guide on originator information on wires.

A correspondent's gaps, quarter by quarter, as an input to its due diligence review

How does ISO 20022 handle cover payments?

In ISO 20022 the customer message is a pacs.008 and the bank-to-bank transfer is a pacs.009; a cover is a pacs.009 that carries the underlying customer transfer's parties. Fedwire's own list of supported ISO 20022 messages shows "Cover Payment (pacs.009)" separately from the ordinary "Financial Institution Credit Transfer (pacs.009)", and notes that cover payments can be imported and exported but not created manually in its FedPayments Manager application (Federal Reserve Financial Services FAQ).

The richer format helps the cover intermediary in two ways. Party data now arrives in defined, structured elements rather than free-text lines, and the structure is tightening: the BIS recorded November 2026 as the date from which a postal address in a cross-border message would have to be fully structured or hybrid (BIS CPMI Brief 13, May 2026). That date has since slipped: the removal of free-text addresses was delayed in August 2026, and the deadline that moved is now expected in November 2027, subject to confirmation. Structure makes a blank or country-only address visible as such. It does not make "ONE OF OUR CLIENTS" in a name element any more meaningful.

FATF's revision keeps cover payments squarely in scope and adds a warning about a newer pattern: "cross-border payment chains are often, in effect, broken into two or more domestic transfers, with the result that the financial institutions involved may not have the full information required on the ultimate originator and / or beneficiary" (FATF explanatory note). A cover that arrives as an apparently domestic transfer is the same transparency problem with a different message type.

When the answer comes back on a different message

Asking the sending bank is the first response the Basel paper lists, and it is where cover payments are hardest to manage by hand. The request goes out as a SWIFT investigation message or a Fedwire service message; the answer may come back on a different message type, days later, quoting a reference that is not the one on the cover. A team that tracks requests in a spreadsheet loses the thread, and the wire sits in suspense or is credited with the gap unresolved.

The solution's Request agent drafts each request on the bank's approved template in the channel the correspondent uses, sets the clock, chases on the day the bank chooses, matches the reply to the wire by its UETR and has the Field agent re-read the answer. When the sample bank's BSA Officer approved an early due diligence review of a repeat correspondent, the relationship manager was asked to raise data quality with it, with the data attached and nothing about any referral.

An early correspondent review, approved, with the relationship manager asked to raise data quality

For what the enforcement record says about banks that strip party data from cover messages, see what the travel rule enforcement cases show, or start from Funds Transfer Recordkeeping & Travel Rule.

Questions people ask

What is a cover intermediary bank?

A correspondent on the money leg of a cover payment, usually in the country of the payment's currency, which settles the interbank obligation but does not receive the customer message. The Basel Committee used the term to distinguish it from an intermediary in a serial chain, which sees the customer message as it passes through.

Can a cover intermediary rely on the originator's bank's sanctions screening?

The Basel paper allows that some intermediaries may consider relying on a respondent's screening where their law permits, but says the intermediary "remains responsible for compliance with domestic law". The US agencies' position in 2009 was that all MT 202 and MT 202 COV messages should be screened.

Is the plain MT 202 still allowed?

Yes, for bank-to-bank transfers on the banks' own account. The 2009 guidance said it "should not be used for cover payments", and that a correspondent's habit of sending covers without the COV format should feature in the receiving bank's risk assessment of that correspondent.

Does the European Union count as one jurisdiction for cover payments?

For the Basel Committee's 2009 guidance, yes: the EU and the European Economic Area were treated as one jurisdiction, following a FATF decision of February 2008, so the guidance does not apply to a chain of transfers entirely within the EU and EEA.

Who should file a suspicious activity report on a cover payment?

Whichever bank's law requires it when the facts meet its reporting definition. The Basel paper notes the cover intermediary usually cannot judge the purpose of a transaction between two non-customers, but it can monitor for patterns, report them, and review a correspondent associated with them.

Does a US beneficiary's bank see the cover message?

Usually not in full: it receives the customer message from the originator's bank and settlement through its own correspondent. In the Basel paper's diagram the last hop to the beneficiary's bank on the cover leg is an MT 9xx message, so the customer message is its main source of party data.