Investigation: the missing MT202 COV

A missing MT202 COV is the investigation where the customer payment arrived but the cover did not, or the cover arrived but the customer payment did not, and the two legs of a cover payment have become separated. In ISO 20022 terms the missing message is a pacs.009. The cover is the bank-to-bank payment that moves the funds, while the customer payment is the message that tells the beneficiary bank who the money is for, and when one arrives without the other, the beneficiary bank cannot credit the beneficiary, because it has the instruction but not the money, or the money but not the instruction. Source: SWIFT CBPR+ usage guidelines; ISO 20022 pacs.009 and pacs.008 definitions. Why the cover goes missing is usually a reference failure, and the investigation must check the references before anything else. The cover and the customer payment are linked by the UETR and by the related reference, and if the cover carries a different reference, or no reference, the beneficiary bank cannot match them, so the cover sits in a suspense account and the customer payment sits in a queue, and both wait for a human to link them. The third cause is a compliance hold on the cover, because the cover carries the debtor and creditor information that screening checks, and a hold on the cover holds the funds even though the customer payment is clean. The parties are the debtor bank, which sent both legs, the intermediary banks, which forwarded them, the creditor bank, which should have received both, and the reimbursement institution, which settles the cover where the cover chain uses one. The enquiry messages are pacs.028 for the status of each leg, and in the legacy MT world MT199 for a free-format enquiry and MT192 for a cancellation request if the cover must be stopped. The answer is pacs.002, which states the status of the leg that was asked about, and the investigation must ask about each leg separately, because a status that says the customer payment arrived says nothing about the cover. How the investigation runs is shown by a worked example. A bank in Paris sends EUR 480,000 to a beneficiary in Tokyo, as a pacs.008 customer payment and a pacs.009 COV cover, on Monday at 10:00, both carrying the same UETR. On Tuesday the Tokyo bank has received the pacs.008 but not the pacs.009 COV, so it cannot credit the beneficiary, because it has the instruction but not the funds. The Tokyo bank sends pacs.028. The cover is found at the wrong bank, which returns it, the Paris bank resends the cover through the correct correspondent, and the Tokyo bank credits the beneficiary on Wednesday, one day late, with interest compensation of EUR 480,000 for one day at 4 percent, about EUR 53, paid by the bank that used the stale instruction. On success both legs are matched, the beneficiary is credited, and the case closes with a note recording which leg was missing, where it was found, and why it went astray. On failure the cover cannot be found, and the investigation must decide whether to wait, to resend the cover, or to recall the customer payment and start again, and each option has a different cost and a different risk. Resending the cover risks a duplicate if the original cover later arrives, so the resend must carry the same UETR and the same references, and the receiving bank must deduplicate by UETR. Recalling the customer payment and starting again is the cleanest option when the cover is truly lost, but it takes days, and the customer must be told. The data the investigation needs is the UETR, the references on each leg, the amount and currency of each leg, the value dates, the correspondent chain for each leg, and the status of each leg. The UETR is the field that matters most, because it is the only identifier that appears on both legs, and a cover that does not carry the UETR of its customer payment cannot be matched automatically. A BA must require the UETR to be carried on both legs, must specify the matching rule that links them, and must specify the suspense account handling for an unmatched cover, because an unmatched cover that sits in suspense for a week is a customer payment that is a week late. Edge cases show the depth. A cover that arrives for a larger amount than the customer payment, because charges were deducted from the customer leg but not the cover, must be investigated as a charges discrepancy, not as a missing cover. A cover that arrives at the beneficiary bank before the customer payment must be held, not credited, because the bank does not yet know who the money is for, and the hold must have a deadline, after which the cover is returned. A cover that is sent through a reimbursement institution must be traced through that institution, which is a separate hop with its own status, and the investigation must ask the reimbursement institution, not just the next bank in the chain. The effect on the bank is a suspense account that grows when covers go unmatched, and a reconciliation break the next morning when the cover and the customer payment do not match. The effect on the customer is a payment that is late even though the bank did everything right on the customer leg, because the cover leg failed, and the customer will blame the bank for the whole delay. The effect on operations is a queue of unmatched covers, each needing a human to link it to its customer payment, and a manager who can see how many covers are unmatched and how old they are. What a BA, PO or SME must understand is that a cover payment is two legs that must be matched, and the investigation is about the matching, not about either leg alone. The requirement must name the UETR on both legs, the matching rule, the suspense handling, the pacs.028 flow for each leg, and the deduplication rule for a resent cover. The test is to take one cover payment where the legs have separated, and to trace each leg to the bank that holds it, and if the two legs cannot be matched by UETR, the gap is in the references. Further reading: SWIFT CBPR+ usage guidelines; ISO 20022 pacs.009 COV definition; Paiementor articles on cover payments. Last reviewed 7 November 2026.