Worked Example and Exercise: a bank sends 10,000 payments, 9,850 settled, 100 rejected, 30 returned, 20 have no corresponding settlement record

The starting point is the control total, because the engine must first prove that it is looking at the complete population before it matches anything. The bank sent 10,000 payments, and the settlement report must account for all 10,000, either as settled, rejected, returned, or missing. The engine adds the four groups, 9,850 settled plus 100 rejected plus 30 returned plus 20 with no settlement record equals 10,000, so the population is complete and no payment has been lost from the report itself. If the total had been 9,980, the engine would stop and raise an alert that twenty payments are missing from the feed, because matching an incomplete population would hide real breaks. For the 9,850 settled payments, the engine performs transaction-level matching against the settlement report and the nostro statement. Each payment is matched on its reference, amount, currency, and value date, and a clean match clears both the internal record and the statement line. Suppose 9,800 match exactly on all four fields, and 50 match on reference, amount, and currency but with a value date one day later because of a holiday in the beneficiary country. The engine marks the 9,800 as matched and the 50 as matched with a timing difference, and it records the reason so that the timing group can be reviewed separately. None of the 9,850 should remain open after this step. For the 100 rejected payments, the engine must confirm that each rejection is genuine, that the money never left the bank, and that the customer has been told. A rejection arrives as a pacs.002 message with a reason code, for example AC01 for an incorrect account number or AM05 for a duplicate payment, and the engine matches that pacs.002 to the original pacs.008 by its reference. It then checks that the customer account was re-credited with the full amount, for example EUR 12,000, and that no settlement debit exists for that payment. If a payment shows both a rejection and a settlement debit, that is a serious break, because the money cannot have been both rejected and settled. For the 30 returned payments, the engine must trace a longer journey, because these payments left the bank, reached the beneficiary side, and then came back. A return arrives as a pacs.004 message, often with reason code AC04 for a closed account or MD07 for an end customer who is deceased, and the engine matches it to the original payment by reference. It then checks that the returned amount matches the original amount, allowing for any fees deducted in transit, and that the customer account was re-credited with the returned funds. If a return of USD 5,000 arrives but the original payment was USD 5,000 and the customer is credited only USD 4,975, the USD 25 difference must be posted to a charges account and explained. For the 20 payments with no corresponding settlement record, the engine creates 20 breaks and assigns each one an owner and a deadline, because these are the most dangerous group. The first step is to check whether each payment is simply in transit with a later value date, by looking at its intended settlement date and the clearing calendar. The second step is to check whether the payment file reached the clearing system at all, by comparing the file control totals. The third step, for any payment still unexplained after those checks, is to contact the clearing system or correspondent bank and ask for the status. Until each of the 20 is explained, the reconciliation cannot be signed off, and the total value of the 20 must be reported to the operations manager as an open exposure.