MT202 COV — General Financial Institution Transfer (Cover)
A variant of the MT202 used only to provide cover — the interbank settlement leg — for an underlying customer credit transfer that travels separately, classically an MT103 sent directly to the beneficiary's bank. A mandatory second sequence repeats the underlying ordering and beneficiary customers so every bank moving the money can screen the real parties.
DIRECTION: Sent by the ordering customer's bank into the correspondent chain that actually moves the funds, in parallel with the underlying customer message sent directly to the beneficiary's bank.
WHO IS INVOLVED
- Ordering institutionSends the underlying MT103 to the beneficiary's bank and the MT202 COV into its correspondent chain.
- Correspondents in the cover chainMove the funds and screen the underlying customer details carried in sequence B.
- Beneficiary institution's correspondentCredits the beneficiary institution's nostro account, completing the cover.
- Beneficiary institutionMatches the incoming cover against the waiting customer message, then credits the customer.
- Underlying ordering and beneficiary customersNot parties to the cover settlement itself — they appear in sequence B for transparency and screening only.
KEY FIELDS
Curated subset of the fields practitioners meet first — the official SWIFT Standards MT documentation is the complete specification.
| FIELD | NAME | PRESENCE | WHAT IT MEANS |
|---|---|---|---|
:20: | Transaction Reference Number (sequence A) | MANDATORYSWIFT Standards MT | The sender's unique reference for the cover transfer.Distinct from the underlying MT103's reference — the linkage happens through field 21 and the shared UETR. |
:21: | Related Reference (sequence A) | MANDATORYSWIFT Standards MT | Links the cover to the underlying customer payment.Market practice is to quote the sender's reference (field 20) of the underlying MT103 here, so the beneficiary bank can match cover to announcement.⚠ An unmatchable related reference leaves the customer payment waiting for funds that have in fact arrived. |
:32A: | Value Date / Currency / Amount (sequence A) | MANDATORYSWIFT Standards MT | When the cover settles, in which currency, and for how much.Should line up with the underlying MT103's settlement details; differences are a classic source of cover mismatches.⚠ An amount or value date that differs from the underlying payment stalls the credit at the beneficiary bank. |
:52a: | Ordering Institution (sequence A) | OPTIONALSWIFT Standards MT | The bank on whose behalf the cover is sent, when it is not the sender.Seen in relay structures; prefer a BIC in option A. |
:56a: | Intermediary (sequence A) | OPTIONALSWIFT Standards MT | A bank the funds must pass through on the way to the account-with institution.As in the plain MT202, its presence makes 57a required under a network-validated rule. |
:57a: | Account With Institution (sequence A) | CONDITIONALSWIFT Standards MT | The bank servicing the beneficiary institution's account, when it is not the receiver.Required when 56a is present; otherwise used as the routing demands. |
:58a: | Beneficiary Institution (sequence A) | MANDATORYSWIFT Standards MT | The bank receiving the covering funds — normally the beneficiary customer's bank.This is the settlement destination of the cover; the beneficiary customer of the underlying payment appears only in sequence B. |
:72: | Sender to Receiver Information (sequence A) | OPTIONALSWIFT Standards MT | Bank-to-bank instructions about the cover, often using coded keywords.Should not be needed to explain the underlying payment — that is what sequence B is for. |
:50a: | Ordering Customer (sequence B) | MANDATORYSWIFT Standards MT | The customer behind the underlying payment — copied from the MT103 so the cover chain can see who is really paying.Must replicate the underlying MT103's field 50a unaltered; this transparency requirement is the reason the COV variant exists.⚠ Truncating or 'tidying' the copied data creates mismatches against the MT103 and triggers screening escalations. |
:59a: | Beneficiary Customer (sequence B) | MANDATORYSWIFT Standards MT | The customer who will ultimately receive the money, copied from the underlying MT103.Like 50a in sequence B, it must mirror the underlying customer message unchanged so every bank in the cover chain screens the same parties.⚠ Divergence between sequence B and the underlying MT103 is a classic cover-mismatch investigation. |
:70: | Remittance Information (sequence B) | OPTIONALSWIFT Standards MT | The payment purpose text from the underlying transfer, when the sender chooses to copy it.Optional in sequence B, but screening teams appreciate having it: free-text hits found here are the same ones the MT103 route will find. |
:33B: | Currency / Instructed Amount (sequence B) | OPTIONALSWIFT Standards MT | The originally instructed amount of the underlying payment, when copied across.Optional in sequence B; when present it should match the underlying MT103's 33B. |
FIELD BY FIELD — FULL STRUCTURE
The whole MT202 COV laid out as a parent-child tree: every field in its nesting, with a sample value and what it means. Expand a branch to drill in. Values are fictional (SYNTHETIC / TRAINING ONLY); this is a curated practitioner view, not the full schema.
Block 1F01DEMODEFFAXXX0000000000MandatoryBasic header — identifies the sender and the session (application id, service id, the sender's logical-terminal address built on its BIC, session and sequence numbers).Block 2I202DEMOUS33XXXXNMandatoryApplication header — the message type, the counterparty address, whether it is input or output, and the priority.Block 3—User header — optional service data; most importantly field 121, the UETR.119COVValidation Flag — a user-header flag marking a message variant that must pass extra rules, e.g. COV (a cover payment) or STP (straight-through).1216f9619ff-8b86-4e9f-a6dd-2cce35e4b321UETR — the unique end-to-end transaction reference (a UUID) in the user header, tracked network-wide.
Block 4—MandatoryText — the business content, as numbered :tag: fields. The only block whose shape changes by message type.:20:DEMO-COV-20260712MandatoryThe sender's unique reference for the cover transfer.- Use case
- Distinct from the underlying MT103's reference — the linkage happens through field 21 and the shared UETR.
- Example
:20:DEMO20260712
:21:DEMO20260712MandatoryLinks the cover to the underlying customer payment.- Use case
- Market practice is to quote the sender's reference (field 20) of the underlying MT103 here, so the beneficiary bank can match cover to announcement.
- Watch out
- An unmatchable related reference leaves the customer payment waiting for funds that have in fact arrived.
:32A:260712EUR1250,00MandatoryWhen the cover settles, in which currency, and for how much.- Use case
- Should line up with the underlying MT103's settlement details; differences are a classic source of cover mismatches.
- Example
:32A:260712EUR1250,00- Watch out
- An amount or value date that differs from the underlying payment stalls the credit at the beneficiary bank.
:52A:DEMODEFFXXXOptionalThe bank on whose behalf the cover is sent, when it is not the sender.- Use case
- Seen in relay structures; prefer a BIC in option A.
:56A:DEMOUS33XXXOptionalA bank the funds must pass through on the way to the account-with institution.- Use case
- As in the plain MT202, its presence makes 57a required under a network-validated rule.
:57A:DEMOGB2LXXXConditionalThe bank servicing the beneficiary institution's account, when it is not the receiver.- Use case
- Required when 56a is present; otherwise used as the routing demands.
:58A:DEMOGB2LXXXMandatoryThe bank receiving the covering funds — normally the beneficiary customer's bank.- Use case
- This is the settlement destination of the cover; the beneficiary customer of the underlying payment appears only in sequence B.
:72:/INS/NON-PRODUCTION EXAMPLEOptionalBank-to-bank instructions about the cover, often using coded keywords.- Use case
- Should not be needed to explain the underlying payment — that is what sequence B is for.
:50K:/DEMO-ORIGINATOR ⏎ JANE EXAMPLE ⏎ 1 SAMPLE STREET ⏎ DUBLIN IEMandatoryThe customer behind the underlying payment — copied from the MT103 so the cover chain can see who is really paying.- Use case
- Must replicate the underlying MT103's field 50a unaltered; this transparency requirement is the reason the COV variant exists.
- Watch out
- Truncating or 'tidying' the copied data creates mismatches against the MT103 and triggers screening escalations.
:59:/DEMO-BENEFICIARY ⏎ JOHN EXAMPLE ⏎ 2 TEST ROAD ⏎ LONDON GBMandatoryThe customer who will ultimately receive the money, copied from the underlying MT103.- Use case
- Like 50a in sequence B, it must mirror the underlying customer message unchanged so every bank in the cover chain screens the same parties.
- Watch out
- Divergence between sequence B and the underlying MT103 is a classic cover-mismatch investigation.
:70:NON-PRODUCTION EXAMPLEOptionalThe payment purpose text from the underlying transfer, when the sender chooses to copy it.- Use case
- Optional in sequence B, but screening teams appreciate having it: free-text hits found here are the same ones the MT103 route will find.
:33B:EUR1250,00OptionalThe originally instructed amount of the underlying payment, when copied across.- Use case
- Optional in sequence B; when present it should match the underlying MT103's 33B.
Sources for the field structure4
- Official requirement
ISO 20022 Catalogue of messages ↗ — ISO 20022 Registration Authority · pain/pacs/camt message-definition elements
Each message set is described by a Message Definition Report; earlier versions remain available in the ISO 20022 messages archive.
- Official requirement
Cross-Border Payments and Reporting Plus (CBPR+) usage guidelines ↗ — Swift (CBPR+ working group) · cross-border agent chain and structured-data usage
Full guidelines require MyStandards access; content here relies on public summaries. MT-to-CBPR+ translation rules are published on Swift's translation portal.
- Official requirement
Swift Standards MT (annual standards releases) ↗ — Swift · FIN block structure
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.
- Simplified educational illustration
Payments Signal editorial teaching models — Payments Signal
What this simplifies: One-line plain-language descriptions of the commonly-populated elements — a practitioner view, not the authoritative ISO 20022 / MT schema, which defines many more optional elements.
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.
COMMON ERRORS
- Sequence B customer details that differ from the underlying MT103.Consequence: Cover-mismatch investigations, screening escalations, and a delayed customer credit while the banks reconcile the two legs.Avoid it: Generate sequence B by copying the MT103's fields programmatically — never re-key or reformat them.
- A UETR that differs from the underlying customer payment.Consequence: gpi tracking shows two unrelated transactions; automated cover matching at the beneficiary bank fails.Avoid it: Propagate the MT103's UETR into the COV at creation time and validate the pair before release.
- Cover released after the correspondent's cut-off while the MT103 has already arrived.Consequence: The beneficiary bank holds the customer payment waiting for funds; the customer sees a delay nobody explains.Avoid it: Release both legs together and check currency cut-offs for the cover route, not just the announcement route.
- Downgrading to a plain MT202 because sequence B data is awkward to assemble.Consequence: The underlying parties become invisible to the cover chain — a transparency breach with regulatory consequences.Avoid it: Treat the availability of complete underlying customer data as a precondition for using the cover method at all.
USAGE CONTEXTS
- The cover methodUsed when the beneficiary's bank is not reachable through the sender's own correspondent chain in one line: the MT103 goes straight to the beneficiary's bank as an announcement while the MT202 COV moves the money through correspondents. The beneficiary bank credits its customer once the cover arrives on its nostro.
- Shared UETR with the underlying paymentThe UETR in header block 3, field 121 — mandatory on these messages since November 2018 — must be identical to the underlying MT103's UETR, which is how gpi tracking and automated matching tie the two legs together.
- ISO 20022 migrationAfter the cross-border coexistence period ended in November 2025, pacs.009 COV took over this role in Swift's CBPR+ space. The transparency design — underlying customer details embedded in the cover — carries over directly, so understanding the MT202 COV transfers well.
- Sanctions screening of sequence BSequence B exists so that correspondents moving the money can screen the underlying customers, not just the banks. Screening teams treat sequence B hits exactly like hits on a customer payment.
SEE IT IN A PLAYABLE FLOW
Sources for this reference2
- Official requirement
Swift Standards MT (annual standards releases) ↗ — Swift · Category 2 — MT 202 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.
- Simplified educational illustration
Payments Signal editorial teaching models — Payments Signal
What this simplifies: Field list curated for learning; national and bilateral usage rules omitted.
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.