INDA, INGA, COVE and CLRG codes

SWIFT messages carry codes that tell the receiving bank how the payment is being made, and four codes in particular matter for the serial versus cover distinction. INDA means instructing bank is the debtor agent, which is the code used when the sending bank is itself sending the payment and the funds are moving with the instruction, as in a serial payment. INGA means instructing bank is not the debtor agent, which is used when the bank sending the instruction is not the bank that holds the funds, for example when a bank sends an instruction on behalf of another bank. These two codes appear in the settlement method field of the payment message, and they tell the receiving bank whether the sender is also the bank that will fund the payment. COVE means cover payment, and it is the code that identifies an MT202 COV message as a cover payment rather than a simple bank to bank transfer. When a bank receives an MT202 with the COVE code, it knows that the funds are the cover for a customer payment that has been sent separately as an MT103, and it knows that it must not treat the funds as a payment in their own right. The bank must screen the cover payment using the originator and beneficiary information carried in the COVE message, and it must pass the funds on to the next bank in the cover chain. The COVE code is what makes the cover method work as a distinct method rather than a series of unrelated bank transfers, and the analyst must ensure that the system generates it correctly. CLRG means clearing, and it is used when the payment is being settled through a clearing system rather than through correspondent accounts. A payment that is sent through a clearing house will carry the CLRG code to indicate that the settlement will happen through that clearing system, and the receiving bank should not expect the funds to arrive through a nostro account. For example, a SEPA payment settled through STEP2 or through TARGET2 carries a clearing settlement method, and the receiving bank credits the beneficiary on the strength of the clearing settlement, not on the receipt of funds through a nostro. A payment with the wrong code will be processed incorrectly, will be charged incorrectly, or will be stopped for a query. In the MT world, these codes live in field 53a, the sender's correspondent, and in field 72, the sender to receiver information, and in the settlement method of the message. In the ISO 20022 world, the same information is carried in the settlement information element, SttlmInf, of the pacs.008 and pacs.009, with the settlement method element SttlmMtd taking values INDA, INGA, COVE or CLRG. The mapping from MT to ISO 20022 is part of the CBPR+ translation rules, and a system that migrates from MT to ISO 20022 must translate these codes correctly. A payment that was INDA in MT must be INDA in pacs.008, and a cover payment that was COVE in MT202 must be COVE in pacs.009. A worked example shows why the codes matter in practice. Bank A sends a payment to Bank D by cover. The instruction is a pacs.008 with settlement method INDA, because Bank A is the debtor agent for the instruction. The funds leg is a pacs.009 COV with settlement method COVE, because it is a cover payment. If the system mistakenly generates the funds leg as a plain pacs.009 with settlement method INDA, Bank B will treat it as a bank to bank payment in its own right, will not link it to the customer payment, and will not screen it using the originator information. The funds may still arrive, but Bank D will not be able to match them to the instruction, and the payment will sit in suspense. That is a real operational failure, and it is caused by a single wrong code. The analyst's responsibility is to specify which code is used in which scenario, to test that the system generates the right code, and to be able to explain to an operations colleague why a payment that should have been COVE was sent as INDA, and what to do about it. The test pack should include a serial payment, a cover payment, a clearing payment, and an INGA payment, each with the expected settlement method code, and the test should verify the code in the generated message, not just the amount and the beneficiary. The operations runbook should include a section on settlement method codes, so that when a payment is stopped for a wrong code, the team knows how to identify it and how to fix it. There is one more code that analysts confuse with these four, and it is worth clarifying. The charge code, OUR, SHA or BEN, is carried in field 71A in MT and in the ChrgsInf element in pacs.008, and it says who pays the charges. It is not a settlement method code, and it does not say how the funds travel. A payment can be OUR and serial, OUR and cover, SHA and serial, or SHA and cover. The two sets of codes are independent, and the analyst must keep them separate. A payment that is OUR by cover still needs the COVE code on the funds leg, and a payment that is SHA by serial still needs the INDA code on the instruction. Confusing the charge code with the settlement method code is a common error in requirements documents, and it leads to systems that generate the wrong messages.