SWIFT MTs / Learning brief
MT202 COV: cover payments explained
Your notes
In simple terms / 01
What this means in plain language
Explains how a cover payment funds the bank-to-bank leg with a SWIFT MT202 COV while the customer's MT103 travels separately to the beneficiary's bank, and why the cover message must carry the underlying customer details.
In cross-border payments a customer transfer sometimes splits into two messages that travel by different routes. In the cover method, the beneficiary's bank receives the customer instruction — a SWIFT (Society for Worldwide Interbank Financial Telecommunication) message type known as an MT103 customer credit transfer — directly, while the money to fund it moves separately between banks through their correspondents. That funding leg uses an MT202 COV, a variant of the general bank-to-bank transfer whose 'COV' marks it as covering a specific customer payment. What makes the COV special is that it must carry the underlying customer details — who ordered the payment and who is to receive it — in a dedicated second section. A plain bank-to-bank message would show only bank names, so any intermediary moving the funds would be blind to the actual parties. The COV exists so those intermediaries can see, and screen, whose payment they are helping to move — which is why using a plain message where a COV is required is treated as a transparency failure.
Complete lesson / 02
Understand the full idea, step by step
Imagine posting a signed letter to a friend that says "pay my cousin €12,400 today", and — because the letter carries no cash — separately arranging for the money to reach your friend through a third person you both trust. Two things travel by two routes for one payment. That split is exactly how a cover payment works, and the message that moves the funding is an MT202 COV.
MT202 and MT202 COV — SWIFT Message Type 202, the general financial-institution transfer, and its cover variant
A plain MT202 is one bank instructing another to move money between institutions — to settle a foreign-exchange deal, fund a nostro account, or meet any bank-to-bank obligation. It names only institutions. The MT202 COV is a distinct variant reserved for one job: covering a specific underlying customer payment. "COV" marks it as the funding leg of an MT103, and it carries the underlying customer details that a plain MT202 never would.
Two parallel flows, one payment
- The instruction
- MT103 sent directly from Bank Alfa to Nordbank — what to pay, to whom.
- The funding
- MT202 COV sent through Meridian Bank — how the money is actually moved between the banks.
- The link
- The cover's field 21 quotes the MT103's field 20, so the two can be paired at Nordbank.
- The extra content
- The COV repeats the ordering and beneficiary customers, unlike a plain MT202.
Read the steps as text
- 01MessageThe customer orders a USD transfer abroadOrdering customer → Bank Alfa (ordering bank)
Same starting point as the serial method — the difference is how Bank Alfa chooses to route instruction and money.
- 02ProcessingBank Alfa validates, screens, and debitsBank Alfa (ordering bank)
After checks and screening, the customer's account is debited and the bank decides on the cover method: announce directly, pay through correspondents.
- DR Ordering customer's account at Bank Alfa — USD 250,000.00
Screening checkpoint: Outbound cross-border screening — Both the announcement and the cover leg will be screened by every bank that touches them.
- 03MessageThe MT103 goes directly to CassiaBank Alfa (ordering bank) → Cassia Bank (beneficiary bank) · MT103
The beneficiary bank learns the full payment details immediately — who is paying whom, how much, and why. But this message alone brings no money.
- 04MessageThe cover transfer goes to the correspondentBank Alfa (ordering bank) → Meridian Bank (correspondent) · MT202 COV
The MT202 COV moves the money along the account chain. Its sequence B repeats the underlying customer details so every bank in the chain can screen the real parties.
- 05SettlementMeridian settles the cover across its booksMeridian Bank (correspondent)
As in the serial flow, settlement is a book transfer between the two banks' USD accounts held at Meridian.
- DR Bank Alfa's USD account at Meridian (vostro) — USD 250,000.00
- CR Cassia's USD account at Meridian (vostro) — USD 250,000.00
- 06MessageCassia sees the cover arrive on its nostroMeridian Bank (correspondent) → Cassia Bank (beneficiary bank) · MT910
The credit advice tells Cassia the money side is complete. Now it has both halves: instruction and funds.
- 07ProcessingCassia matches the announcement against the coverCassia Bank (beneficiary bank)
The beneficiary bank pairs the MT103 with the incoming cover by references and amount. Crediting on the MT103 alone would be paying before being paid.
- 08PostingThe beneficiary is creditedCassia Bank (beneficiary bank)
With instruction and funds matched, Cassia credits its customer. The cover method can be faster for the beneficiary bank's information, but credit still waits for money.
- CR Beneficiary's account at Cassia — USD 250,000.00
SWIFT MT — ILLUSTRATIVE, NON-PRODUCTION
A synthetic MT202 COV. The header carries {119:COV}, marking it as a cover. Field :21: quotes the related MT103's reference so the two messages pair up. Below the bank-to-bank fields, a second sequence repeats :50K: the ordering customer and :59: the beneficiary — the detail a plain MT202 would not carry.
Why the cover carries the customer
The defining feature of the MT202 COV is that dedicated second sequence naming the ordering and beneficiary customers. If the funding leg used a plain MT202, every intermediary moving the money would see only bank names, with no view of the people or companies behind the payment. The COV closes that gap on purpose: each bank in the chain can screen the actual customers against the lists it must check, not just the banks. Industry guidance from the Wolfsberg Group — an association of large correspondent banks — sets this expectation: originators populate the underlying details accurately, and intermediaries screen what the second sequence shows them. The second sequence is a control that makes screening possible, not a formality.
How the two legs come together
- INSTRUCTION
Bank Alfa sends the MT103 directly to Nordbank: pay the supplier EUR 12,400.00, reference in field 20.
- MESSAGE
Bank Alfa sends the MT202 COV through Meridian Bank, its field 21 quoting that same reference, its second sequence repeating the two customers.
- SETTLEMENT
Meridian Bank moves the funds between the accounts it holds for Bank Alfa and Nordbank — the funding leg settling through the correspondent.
- VALIDATION
Kabir's screening at each bank checks the underlying customers the COV carries, not only the institutions.
- NOTIFICATION
Nordbank pairs the MT103 with the matching cover, confirms funding, and credits the supplier once.
COMMON CONFUSION
“The MT103 and the MT202 COV are the same payment sent twice, so the supplier could be paid two times.”
They are two legs of one payment: the MT103 announces what to pay, the MT202 COV funds it. Nordbank links them by reference and credits the supplier exactly once. Sending an announcement plus its funding is not a duplicate — it is the cover method working as designed.
WHAT IF — The underlying details in the cover's second sequence do not agree with the MT103 it funds — a different beneficiary name, or an amount that does not tie out.
What happens: This is a recognised investigation trigger. At best it is a data error; at worst it can look like an attempt to keep a party out of view of screening, which is precisely what the COV design guards against.
How it is handled: Kabir and Maya hold the payment and reconcile the pair before it proceeds. If the link between field 21 and field 20 breaks entirely, Nordbank may be left holding an MT103 it cannot safely credit because it cannot find the matching cover, and the payment stalls as an operational break until reconciled.
STRICTLY SPEAKING
Strictly speaking, the exact field layout — the second sequence, the ordering and beneficiary customer fields, the related reference — and the rules on when the COV variant must be used are set out in the SWIFT Standards MT Category 2 documentation, which requires a SWIFT user account. Under CBPR+, the same cover role is carried by the ISO 20022 message pacs.009 in its cover form. Check the standard in force before quoting a precise layout.
FOR NOW, REMEMBER
- In the cover method, one customer payment travels as two linked messages: an MT103 announcement and an MT202 COV funding leg.
- A plain MT202 names only institutions; the COV variant adds a second sequence naming the underlying customers.
- That second sequence exists so every intermediary can screen the real customers, not just the banks.
- The cover's field 21 links to the MT103's field 20; a mismatch or broken link is an investigation trigger and can stall the payment.
TRY IT YOURSELF
Kabir at Meridian Bank receives an MT202 COV. Its bank-to-bank fields are complete, but the second sequence names a beneficiary different from the linked MT103. What is the right reading?
You have seen the cover method split a payment into an announcement and a funding leg. But a payment can also travel hop by hop, money and message together. Next we compare the two routing methods side by side.
KEEP GOINGKey takeaways / 03
Three things to remember
- 01
In a cover payment the customer's MT103 goes to the beneficiary's bank while the funding travels separately as an MT202 COV.
- 02
The MT202 COV carries the underlying ordering customer and beneficiary in a dedicated second sequence, unlike a plain MT202.
- 03
Those underlying details let intermediary banks see and screen the real parties, so a plain MT202 in their place is a transparency failure.
Practical use cases / 04
Where you would use this
A correspondent bank screens the underlying customer details in an MT202 COV against the parties it is required to check.
An investigations analyst pairs an MT202 COV with the MT103 it covers to confirm the beneficiary and amount agree.
A beneficiary's bank waits to identify the cover before crediting a customer, so a broken link becomes an operational break.
Worked example / 05
Put the idea into a real situation
Illustrative example: a fictional bank, Harbourline Bank, sends a EUR 180,000.00 MT103 directly to the beneficiary's bank for its customer 'Delta Castings SA'. To fund it, Harbourline Bank sends an MT202 COV for EUR 180,000.00 to a correspondent, and in the cover message's second sequence it repeats the ordering customer 'Delta Castings SA' and the beneficiary. The COV's related reference quotes the MT103's transaction reference, so the two messages can be paired. If the second sequence named a different beneficiary, or the amount read EUR 108,000.00, the mismatch would trigger an investigation before the funds settled.
Evidence & review / 07
Evidence & review
SWIFT FIN MT202 and MT202 COV in cross-border correspondent banking; ISO 20022 pacs.009 (cover) is the CBPR+ successor. Transparency expectations follow Wolfsberg guidance.
What this brief simplifies: The correspondent chain is reduced to a single correspondent (Meridian Bank). Field layout is taught at concept level; exact MT Category 2 specifications require a SWIFT user account. Screening is presented defensively — how controls detect discrepancies.
Sources for this brief4
- Official requirement
Swift Standards MT (annual standards releases) ↗ — Swift · MT Category 2 — MT202 and MT202 COV
Full field-level specifications live in the Swift Knowledge Centre User Handbook behind a swift.com login; content here relies on public summaries. Swift ended MT-to-ISO 20022 coexistence for in-scope cross-border payment instructions (for example MT103 and MT202) in November 2025; MT statement messages are being phased out on a separate timeline.
- Market practice
Wolfsberg Group Payment Transparency Standards ↗ — The Wolfsberg Group · Underlying customer transparency in cover payments
The 2023 standards replace the 2017 version and are supplemented by separate Wolfsberg guidance on roles and responsibilities in payment chains.
- Scheme-specific rule
Cross-Border Payments and Reporting Plus (CBPR+) usage guidelines ↗ — Swift (CBPR+ working group) · pacs.009 cover form under CBPR+
Full guidelines require MyStandards access; content here relies on public summaries. MT-to-CBPR+ translation rules are published on Swift's translation portal.
- Simplified educational illustration
Payments Signal editorial teaching models — Payments Signal · Asha Traders cover scenario via Meridian Bank
Used wherever diagrams, scenarios, figures, or example values are didactic constructions rather than sourced facts; every such use carries a simplifications disclosure. All people, companies, banks, and list entries in examples are fictional.