Worked example: cover method, Paris to Madrid in USD

This worked example is set before the CBPR+ migration, so the payment travels as an MT103 announcement with an MT202 COV cover. Take a concrete payment. A French company, a customer of BNP Paribas in Paris (BIC BNPAFRPP), needs to pay a Spanish company, a customer of Banco Santander in Madrid (BIC BSCHESMM). The payment is in US dollars, for USD 367,574.90. Neither BNP Paribas nor Santander is located in the dollar currency zone, so the funds cannot move directly between them. They move through correspondent accounts held with banks in the United States. In this example, the correspondent of BNP Paribas is Wells Fargo (PNBPUS3N) and the correspondent of Santander is Bank of New York Mellon (IRVTUS3N). BNP Paribas sends a combination of two SWIFT messages, an MT103 announcement and an MT202 COV cover payment. The same payment today travels as a pacs.008 for the customer leg and a pacs.009 COV for the cover leg. The first message is the MT103 announcement. BNP Paribas sends it directly to Santander. Its purpose is to inform Santander that funds are coming for a specific customer, and that the funds will be credited to Santander's dollar account with its correspondent, Bank of New York Mellon. The announcement does not carry the funds. It only announces them. Two fields tell the story. Field 53A names Wells Fargo, the bank that will provide the funds to Santander on behalf of BNP Paribas. Field 54A names Bank of New York Mellon, the bank that will receive the funds on behalf of Santander. The presence of fields 53A and 54A proves there is no dollar account relationship between sender and receiver. There is no field 52A, which means the ordering customer is a customer of BNP Paribas itself. There is no field 57A, which means the beneficiary account is held by Santander, the receiver of the message. Charges are SHA, shared between ordering and beneficiary customer. The second message is the MT202 COV. BNP Paribas sends it to Wells Fargo, its correspondent. It instructs Wells Fargo to debit BNP Paribas dollar account and send the funds to Bank of New York Mellon, for credit to Santander's account there. The MT202 COV carries a validation flag in Block 3, tag 119, which marks it as a cover payment linked to an underlying customer transfer. It has two sequences. Sequence A holds the cover payment transmission details. Sequence B holds the underlying MT103 details, and it must contain at least the ordering customer and beneficiary customer, matching the announcement exactly. The MT202 COV carries the same Unique End-to-end Transaction Reference (UETR) as the MT103 announcement, which proves that even though two messages were sent, it is one transaction. The related reference, field 21, is 103REF405775, the same as the sender's reference in field 20 of the MT103. Wells Fargo then forwards the cover. It sends a second MT202 COV to Bank of New York Mellon. In this second cover, Wells Fargo is the sender and Bank of New York Mellon is the receiver. Field 52A is now present, telling Bank of New York Mellon that the original instruction came from BNP Paribas, not from Wells Fargo. Without it, the receiver would wrongly assume Wells Fargo was the ordering institution. Field 57A is absent in this second cover, because Bank of New York Mellon itself holds Santander's dollar account. Field 58A, the beneficiary institution, is still Santander. The funds can move between Wells Fargo and Bank of New York Mellon through a local US clearing system, because both banks are in the same country. SWIFT is not mandatory for this leg. What matters is that the funds move. Finally, Bank of New York Mellon sends an MT910, Confirmation of Credit, to Santander. This tells Santander its dollar account has been credited. The MT910 is itself a cover. When Santander receives it, it has confirmation that the funds related to the announcement have arrived, so it can credit the final beneficiary. There is no need to receive an MT202 COV. The related reference in the MT910, field 21, is 103REF405775, the same reference BNP Paribas generated, so Santander can reconcile the cover with the announcement. One limitation. The UETR is not available in the MT910, because the SWIFT MT standard does not allow field 72 to carry it. A common workaround is to generate the MT910 and convert it into an MT199 or MT299 to meet SWIFT gpi requirements. Worked example with real numbers: the Paris to Madrid USD payment in the cover worked example carries field 72 on both messages, and the two field 72s are different. The MT103 from Paris to Madrid carries field 72 with /REC/ and a note to advise the beneficiary, because the customer payment must be received in full and the beneficiary must be told. The MT202 COV from Paris to New York carries field 72 with /COVE/ and the reimbursement instruction, because the cover must be settled through the reimbursement institution in New York. The worked example therefore teaches the field 72 difference by showing both messages side by side, with the same payment, the same amount, and different field 72s. Failure and recovery: the cover worked example fails when the MT202 COV field 72 carries /CLRG/ instead of /COVE/, because /CLRG/ tells the receiving bank to clear the payment through a clearing system, while /COVE/ tells it to settle as a cover, and the two are different settlement methods, so the payment is processed through the wrong system and is delayed. The recovery is to recall the cover, correct field 72 to /COVE/, and resend it, but the beneficiary is paid a day late, and the bank must pay interest compensation. A bank that does not validate the settlement method code in field 72 before sending will create this failure, and the BA must require the code to be validated against the payment type, because a cover with a clearing code is a payment sent to the wrong system. For a business analyst, product owner or subject matter expert, the cover worked example must show field 72 on both the MT103 and the MT202 COV, with a comparison, and must state the validation that checks the code against the message type. In ISO 20022 the settlement method is carried in the settlement information of the pacs.009 COV, and the requirement must map field 72 to that information, so the settlement method survives migration. A worked example that shows only one field 72 is a worked example that does not teach the difference.