Your nostro reconciliation shows a break this morning. How do you investigate it, and how do you know when the money has actually gone?

What the two sides actually are

A nostro is your account held on the books of another bank, usually to hold a currency you do not settle yourself. You keep a mirror of it in your own general ledger. The reconciliation compares your mirror against the statement the account-holding bank sends you, and the two are structurally asymmetric in ways that generate most of what looks like error.

Your side records intent at the moment your process decided to pay. Their side records the effect at the moment their books moved. Between those two instants sit a message in transit, a cut-off, a value date convention, a correspondent in the middle, and possibly a fee deducted by someone else. Your side is denominated in the account currency but your ledger may also hold a base-currency translation that moves with rates. Their statement carries their references, not yours, unless the reference you supplied survived every hop.

So the first thing to establish about any break is not who is wrong but which of these asymmetries could produce it. Investigators who start by hunting a bug spend their morning on differences that resolve themselves at the next statement.

Match in layers, in a defined order

Matching is not one join. It is a sequence of passes, each looser than the last, each running only on what the previous pass left unmatched. Stating that sequence is the quickest way to show you have done this work.

• Unique reference. Your end-to-end identifier as echoed on the statement. Cheap, exact, and it should clear the large majority. If it does not, your reference is being stripped somewhere and that is the real finding.
• Strong composite. Amount, currency, value date and counterparty, within a tight tolerance on date. This catches items where the reference was mangled but the economics are unmistakable.
• Grouped matching. One-to-many and many-to-one. A single statement credit against several of your expected receipts, or your one instruction that the correspondent split. Requires searching for subsets that sum to the counter-item, which is why it runs late and against a reduced population.
• Tolerance matching. Amount differences inside a documented threshold, typically fees or rounding on a currency conversion. The residual is booked to a difference account with the reason, not absorbed.
• Manual. What is left, presented to an investigator with everything already gathered.

Two things about this sequence are worth saying explicitly. The order matters because a loose pass run early will make wrong matches that a tight pass would have made correctly, and a wrong match is worse than an unmatched item because it hides two problems at once. And every automatic match must be recorded with the rule and the pass that made it, so that a matching rule change can be evaluated against history rather than trusted.

Classify the break before you chase it

A flat queue of differences is unworkable. Classification turns it into a set of small, differently owned problems.

Timing differences are the largest bucket: you booked it, they have not yet, or the reverse. The evidence is that an item unmatched today matches tomorrow with the expected value date, so the control is not investigation but ageing — an item is a timing difference until it is older than the rail's plausible settlement window, at which point it is reclassified and investigated. This reclassification threshold is per rail, because a domestic real-time transfer that has not appeared within hours is a genuine problem while a cross-border payment through two correspondents is not yet interesting.

Then the substantive classes. An item on the statement that you have no record of at all, which may be an unexpected receipt, a fee, or somebody else's item misposted to your account. An item you booked that the statement never shows, which may be a payment that never left, a rejection whose message you did not process, or a return. Amount differences, most often deducted fees or a rate applied differently. Duplicates on either side. And postings to the wrong nostro, which look like a shortage in one account and a surplus in another and are only visible if you look across accounts.

Each class carries an owner and an escalation clock. Age matters far more than count: a hundred one-day items are business as usual, and one unexplained item that is thirty days old is a finding, because an aged unexplained break in a cash account means either you are missing money or you are holding someone else's.

The repair you must not make

Here is where discipline separates from competence. The break is a difference between your books and theirs, and the fastest way to make it disappear is to post an entry on your side that agrees with the statement. Sometimes that is correct — the statement is authoritative for what happened on their books, and if you failed to record a fee, you record the fee.

It is wrong whenever you do not yet know the cause. An adjustment posted to silence a break destroys the only evidence that something in your payment path is misbehaving, and it converts a visible control exception into an invisible loss. The rule is that you may adjust your ledger to record a fact you have established, and never to make a reconciliation agree. Where you must clear the difference for reporting purposes before you understand it, it goes to a suspense or difference account that is itself reconciled and aged, with the investigation still open. A suspense account nobody reviews is where reconciliation programmes go to die, so its balance and the age profile of its items belong on the same report as the breaks themselves.

Your ledger moving is not finality

The second half of the question is a different concept entirely, and candidates routinely conflate them. Settlement finality is the point at which the transfer becomes unconditional and irrevocable, so that it cannot be reversed even if a participant fails afterwards. It is a legal property of the system the payment moved through, and it is defined by that system's rules.

In a real-time gross settlement system operated by a central bank, finality comes when the accounts on the central bank's books are debited and credited, one payment at a time, and it typically arrives within seconds. In a deferred net settlement arrangement, individual instructions are exchanged during the day and only the net obligations settle at the settlement cycle, so a payment your customer can see in the morning is not final until that cycle completes and until the arrangement's own rules say the settlement is irrevocable. Retail rails add return rights on top: a debit can be recalled or returned for a defined period under the scheme rules, and a card authorisation is a promise that is later captured and then settled and can still be charged back long after. Cheques carry their own return window.

The practical consequence is that "confirmed", "cleared", "settled" and "final" are four different states and your ledger and your product must not treat them as one. Your general ledger entry is a record of your own decision, not evidence that the money is irrevocably somewhere else. The state a customer is shown, the point at which you release goods or allow onward withdrawal, and the point at which you stop carrying the risk are three different lines, and where you draw the first two is a commercial choice about how much of the return window you are willing to fund.

Age a break before you investigate it and never post an entry to make one agree, because the reconciliation is the only place some payment defects are visible. And keep confirmed, cleared, settled and final as distinct states, because only the last one means the money cannot come back.