Reconciliation Engines

A reconciliation engine compares two or more sets of records and reports the differences. The most important comparison in payments is three-way matching, which checks the payment instruction, the settlement record, and the bank statement against each other. The instruction says what the customer asked for, for example a payment of 250,000 pounds to a supplier on 5 November. The settlement record says what actually left the bank through the clearing system. The statement from the correspondent bank or clearing system says what was received at the other end. When all three agree on amount, currency, date, and reference, the payment is matched and closed. When any one of them differs, the engine raises a break. Nostro reconciliation is the daily check of the accounts a bank holds with other banks overseas. A nostro account is an account a bank holds in a foreign currency with a correspondent bank, for example a London bank holding a US dollar account with a bank in New York. Every payment sent in dollars debits that nostro account, and every payment received credits it. At the end of each day, the correspondent bank sends a statement, usually as an MT950 message or a camt.053 statement in ISO 20022 format, listing every entry. The reconciliation engine matches each statement line against the bank internal ledger. A balance of 12.4 million dollars in the ledger must equal 12.4 million dollars on the statement, to the cent. Matching is rarely a simple equality check, because real payments carry fees, value-date shifts and rounding. A good engine applies a rule hierarchy: exact match first on reference, amount and value date; then a tolerance match where the amount differs by a known charge, for example a 25 dollar intermediary fee deducted from a 10,000 dollar payment, leaving 9,975 dollars credited; then a value-date tolerance of one or two business days for payments that crossed a weekend. Each rule must be explicit and auditable, because an auditor will ask why two records were declared a match when the amounts differ. Rules that auto-match on amount alone, without checking the reference, are a known source of false matches and must never be used. Break management is the process of handling the items that do not match. Breaks fall into common categories: a timing difference, where a payment was sent on Monday but appears on the statement on Tuesday; an amount difference, where a fee of 25 dollars was deducted by an intermediary bank; a missing item, where the bank sent a payment but the statement shows no entry; and a duplicate, where the same payment appears twice. Each break is assigned an age, an owner, and a priority. A break of 5 million dollars that is one day old gets urgent attention, while a break of 12 dollars that is thirty days old may be written off under a defined policy. The engine tracks every break until it is resolved or formally written off. Investigating a break is detective work. The analyst starts with the payment reference and traces it through every system: the hub log, the payment engine log, the SWIFT message archive, and the core banking entries. If the statement is missing a payment, the analyst checks whether the SWIFT message was actually sent and whether the correspondent bank has acknowledged it. If the amount differs, the analyst checks the fee schedule and the intermediary charges. If the value date differs, the analyst checks the cut-off time and the time zone. The analyst then takes corrective action, which may mean asking the correspondent bank for a missing entry, posting a manual adjustment, or contacting the customer. Every action is recorded, because auditors will ask how each break was resolved. Unresolved breaks do not sit in limbo; they sit in a suspense account, and suspense is where operational risk hides. When a payment cannot be matched, the funds are parked in a suspense ledger until the break is resolved. A suspense balance that grows week on week is a red flag: it usually means a systematic problem, such as a mapping error that drops the same reference on every payment. Banks set ageing limits, for example no item older than 30 days without a documented reason, and any write-off above a threshold, often 1,000 dollars, needs a manager sign-off. A business analyst specifying a reconciliation engine must define the suspense rules, the ageing ladder, and the write-off authority, because these are the controls that keep a small break from becoming a material misstatement. For a business analyst or product owner, the reconciliation engine is specified through its matching rules, its break taxonomy, and its reporting. The specification must state which records are compared, in which order, with what tolerances, and what happens at each decision point. It must define the break categories, the ageing rules, the ownership model, and the escalation path. It must also define the management information: daily match rate, break ageing profile, suspense balance, and the top ten breaks by value. A good acceptance test is a statement with a known set of breaks, and the engine must classify each one correctly. If the engine cannot explain why it matched two records, it is not fit for audit. A worked example shows a reconciliation engine matching a nostro statement. A bank receives an MT950 statement from its correspondent in New York for its USD nostro account. The statement shows 1,240 entries for the day. The reconciliation engine matches each statement entry to a ledger entry by value date, amount and reference. 1,238 entries match exactly. Two do not. One is a payment of USD 50,000 that the bank sent but the correspondent has not yet recorded, because of a value date difference: the bank posted it on 5 November and the correspondent will post it on 6 November. The engine marks it as a timing break and expects it to match tomorrow. The other is a charge of USD 25 that the correspondent deducted but the bank did not expect, because the correspondent applied a fee the bank had not agreed. The engine marks it as a charge break and routes it to the nostro team to query. A reconciliation engine that only counts matches is useless; the value is in how it classifies the breaks. A failure scenario tests the engine under stress. On the last working day of the month, the correspondent sends a statement with 50,000 entries, ten times the normal volume, because it is catching up after a system outage. The reconciliation engine must process the whole statement within the working day, or the nostro balance will be unverified and the bank cannot be sure how much money it has in New York. The engine scales by processing entries in parallel and by matching on indexed fields, but if it is not designed for peak volume, it will still be running when the next statement arrives. For a business analyst, the requirement is to define the matching rules, the break categories, the tolerance for timing differences, the escalation for charge breaks, and the performance requirement for peak statement volume. Last reviewed 7 November 2026. Further reading: public post on nostro reconciliation; SWIFT MT950 and camt.053 message definitions.