Rejects: stopped before the money moves

A reject happens when a payment is stopped before the funds have moved, usually because the receiving bank or an intermediary bank cannot process the instruction as it stands. The IBAN is invalid, the BIC does not exist, the account number is wrong, or a mandatory field is missing. The bank that detects the problem sends a reject message back to the sender, using a pacs.002 payment status report in ISO 20022, which carries the reason code and a description of the problem. A SWIFT MT199 free format message can follow for extra explanation, but it is not the reject itself. The funds are not debited from the sender's account, or if they were debited, they are returned immediately, because the payment never left the sending bank's control in a way that requires a separate return leg. The reason codes for a reject are standardised, and the analyst must know the most important ones. AC01 means incorrect account number. AC04 means closed account. AC06 means blocked account. AG01 means transaction forbidden, for example because the account does not allow that type of payment. AM04 means insufficient funds. FF01 means invalid file format, which usually means a schema error. RC01 means bank identifier incorrect, which usually means the BIC is wrong or does not exist. Each code is carried in the pacs.002 in the Rsn element, with a code and a description, and the system must translate the code into plain language for the customer. A reject message that says incorrect account number is useful. A reject message that says payment rejected is not. Rejects are the best kind of exception, because they happen early, they are cheap to fix, and the customer can be told quickly what went wrong. The analyst must design the reject handling to be fast and clear. The system should receive the reject, match it to the original payment by reference and UETR, update the payment status to rejected, notify the customer with the specific reason, and offer the customer the chance to correct the details and resend. A reject message that says invalid IBAN is useful, and the resend flow should pre fill the original details so that the customer only has to fix the one field that was wrong. The customer should be notified within one business day, because the payment never left the sending bank and there is no reason to wait. Prevention is the most effective way to reduce rejects, and it happens at the payment capture screen. IBAN validation with the MOD 97 check, BIC validation against the SWIFT directory, account number format checks, and mandatory field validation will catch most of the errors that cause rejects, before the payment is sent. Confirmation of payee, where it is available, will catch a name mismatch before the payment is sent. A screen that shows the beneficiary name and account together and asks the customer to confirm will catch a copy and paste error. The analyst should measure the reject rate by reason code, should identify the top three reasons, and should fix the capture screen to prevent them. There is a specific reject scenario that catches analysts out: the reject that arrives after the funds have been debited from the customer's account but before they have left the bank. In this case the funds must be credited back to the customer immediately, and the credit must be for the full amount debited, including any charges that were taken. If the bank debited USD 10,025 and the payment is rejected, the customer must be credited USD 10,025, not USD 10,000, because the charges were for a payment that did not happen. The system must handle this reversal automatically, and must not leave the customer waiting for a manual refund. The test pack should include this scenario, because it is the scenario that generates the most complaints when it is handled badly. The analyst must also design for the reject that is caused by a compliance hit. If the payment matches a sanctions list, the bank may reject it and return the funds, or it may block it and hold the funds. The difference matters, and the system must distinguish them. A reject for a compliance reason must be recorded with the reason, must be reported to compliance, and must not be resent by the customer without a compliance review. A customer who resends a payment that was rejected for a sanctions hit, without changing anything, will have it rejected again, and the bank may be reported for attempting to evade sanctions. The analyst must ensure that a compliance reject cannot be resent through the normal flow, and that it goes to a compliance queue instead. The reject handling must also cover the case where the reject message itself is incomplete or cannot be matched to the original payment. If the pacs.002 arrives without a UETR or with a reference that does not match any payment, the system must put it in an exception queue and alert operations, because an unmatched reject may mean a payment was rejected that the bank does not know about, or it may mean the reject is a duplicate. The operations team must investigate, must match it manually if possible, and must record the outcome. An unmatched reject that is ignored is a payment that the customer thinks is in transit but has actually been stopped, and that is the worst possible outcome. A customer sends USD 10,000 to a supplier in Germany, but the IBAN has a transposed digit. The sending bank validates the IBAN with the MOD 97 check, but the check passes because the transposition happens to produce a valid checksum, which is rare but possible. The beneficiary bank receives it, checks the IBAN against its own accounts, finds no matching account, and sends a pacs.002 with status RJCT and reason code AC01, incorrect account number. The sending bank receives the pacs.002, matches it to the original payment by UETR, updates the status to rejected, credits the customer USD 10,025, and notifies the customer that the IBAN was incorrect and asks them to check it and resend. The whole cycle takes one business day, and the customer can fix the IBAN and resend.