The cover flow step by step

Now consider the same payment from Bank A in India to Bank D in Brazil, but this time by the cover method. The amount is USD 10,000, the charge arrangement is SHA, and each bank in the cover chain charges USD 25. Bank A sends a SWIFT MT103 customer payment message directly to Bank D, carrying the full details of the originator, the beneficiary, the amount and the remittance information. In ISO 20022 the same instruction travels as a pacs.008 sent directly from Bank A to Bank D. Bank D receives the instruction and knows exactly who is to be paid and how much, even though the funds have not yet arrived. Bank D can prepare the credit, screen the beneficiary, and check the account, all before the money moves. Separately, Bank A sends a SWIFT MT202 COV bank to bank payment message to Bank B, instructing Bank B to move the funds to Bank C, which moves them to Bank D. The MT202 COV is the cover payment. It carries the money, and it also carries a copy of the originator and beneficiary information, so that the banks in the cover chain can screen the payment for sanctions and compliance. Since the CBPR+ migration, the same cover payment travels as a pacs.009 COV for the funds, carrying the UETR of the customer payment it covers, so that the funds leg and the instruction leg can be matched by Bank D. The funds leg has its own accounting at each step. Bank A debits its nostro account with Bank B by USD 10,000 and instructs Bank B to pay Bank C. Bank B debits Bank A's vostro account USD 10,000, deducts its charge of USD 25, and credits Bank C USD 9,975 through its own nostro account. Bank C deducts USD 25 and credits Bank D USD 9,950. Bank D receives USD 9,950 in its nostro account, matches it to the pacs.008 instruction it received directly from Bank A using the UETR, and credits the beneficiary USD 9,950. The beneficiary receives the same USD 9,950 as in the serial example, because the charges are the same, but the journey is different. The key difference is that Bank D receives the instruction directly from Bank A, so it does not have to wait for the funds to travel through the chain before it knows the payment is coming. In many cases Bank D can credit the beneficiary account as soon as it receives the pacs.008 and is satisfied that the cover funds will arrive, or it can wait for the cover funds and then credit the account. The decision depends on Bank D's risk appetite and on its relationship with Bank A. A bank that credits before the funds arrive is taking a credit risk on Bank A, and it will only do so for banks it trusts and for amounts within an agreed limit. A bank that waits for the funds is slower but takes no credit risk. The cover method is faster for the beneficiary in many cases, because the instruction arrives directly and the beneficiary bank does not have to wait for a chain of intermediaries to process the payment one by one. It is also more transparent, because the beneficiary bank sees the full originator information directly from the sending bank, rather than receiving it through intermediaries that might have altered or reduced it. The cover method is the standard for payments where the sending and receiving banks have no direct relationship, and for payments in US dollars, where the funds often travel through a US correspondent while the instruction travels directly. Failure modes in cover are different from serial, and the analyst must know them. If the cover funds are delayed, Bank D still has the instruction and can tell the beneficiary that the payment is expected and the funds are in transit, which is a better customer experience than serial, where Bank D may know nothing. If the cover funds arrive but cannot be matched to the instruction because the UETR is missing or the reference is different, Bank D must hold the funds in a suspense account while it investigates, and the beneficiary is not credited. If a bank in the cover chain stops the funds for a sanctions query, the instruction has already reached Bank D, so Bank D can start its own checks and can explain the position to the beneficiary. For a system design, the cover flow needs the following: the ability to generate a pacs.008 instruction and a pacs.009 COV from a single payment instruction, with the same UETR on both; a matching engine at the receiving bank that links the cover funds to the instruction by UETR and amount; a credit decision rule that says whether to credit on instruction or on receipt of funds; and a suspense process for cover funds that cannot be matched. The most common operational failure in cover payments is a mismatch between the instruction and the funds, and the analyst should test that scenario explicitly, because it is the scenario that generates the most customer complaints. One more point that catches analysts out: the cover payment must carry the originator and beneficiary information, and it must be screened. A pacs.009 COV that carries no originator information is a compliance failure, and the intermediary bank that receives it must stop it for a query. The MT202 COV form existed for exactly this reason, to distinguish a cover payment that carries the underlying customer information from a plain bank to bank transfer that does not. In ISO 20022 the same distinction is made by the cover indicator on the pacs.009. A system that generates a plain pacs.009 where a pacs.009 COV is required will produce payments that are stopped at the first intermediary, and the analyst must ensure the correct form is generated. Worked example with real numbers: a bank in London sends USD 250,000 to a beneficiary in Singapore by cover, and the cover is USD 250,000 sent through a reimbursement institution in New York. The London bank debits its customer USD 250,000, sends the customer payment to Singapore, and sends the cover to New York, where the reimbursement institution debits London USD 250,000 and credits Singapore USD 250,000. The Singapore bank receives the customer payment and the cover, matches them by UETR, and credits the beneficiary USD 250,000. If the reimbursement institution had been wrong, the cover would have gone to a bank that does not hold the Singapore account, and the beneficiary would not have been credited. Failure and recovery: the cover flow fails when the cover and the customer payment arrive at different times, and the beneficiary bank holds one while waiting for the other, and the hold exceeds the cut-off, so the payment is not credited that day. The recovery is to check the status of each leg by pacs.028, to find the missing leg, and to release the held leg once the missing one arrives, but the beneficiary is paid a day late, and the bank must pay interest compensation. A cover flow that is not monitored for unmatched legs will leave payments in suspense for days, and the BA must require a daily report of unmatched covers, with an owner and a deadline, because an unmatched cover is a payment that has not been completed. For a business analyst, product owner or subject matter expert, the cover flow requirement must name the reimbursement institution, the matching rule by UETR, the suspense handling for an unmatched cover, and the daily report. The ISO 20022 pacs.009 COV carries the reimbursement institution in its agent fields, and the requirement must map the MT202 COV field 54a to those fields, so the settlement is preserved in migration. A cover flow that does not name the reimbursement institution is a cover flow that cannot settle, and a cover flow without a matching rule is a cover flow that will leave money in suspense.