Leave clean matches to your matching engine and give the agent the breaks. For each unmatched item it searches both sides, proposes a match with its reasons, classifies charges and timing differences, and drafts the query to the correspondent bank. A person approves every proposed match below full confidence, every adjustment and every write-off.
What is nostro reconciliation, and who owns it?
A nostro account is your bank's account held at another bank, usually in a foreign currency. You keep your own record of it, and the correspondent sends statements. Reconciliation matches the two: every debit and credit on your books against the correspondent's statement, item by item. Unmatched items are breaks. Some are timing, some are charges the correspondent deducted, some are errors, and some are money that has gone somewhere it should not.
Reconciliation or payment operations teams own the work, often in a shared service. Treasury watches the balances, because an unplanned overdraft on a nostro is expensive. Finance relies on the result for the general ledger. The bulk of items match automatically; the agent's work starts where the engine stops.
What are the steps?
- Agent, depth 1: loads the breaks. Unmatched items from both sides after the matching engine has run, with their ages.
- Agent, depth 1: searches for partners. For each item, candidates on the other side by amount, value date, reference, counterparty, and combinations where one payment matches several entries.
- Agent, depth 2: proposes matches. Each proposal states which fields agree, which do not and why the agent still thinks they belong together. Exact matches the engine missed for a format reason can be confirmed at depth 3 once that capability is certified.
- Agent, depth 1: classifies the rest. Correspondent charges, FX differences, timing items, apparent duplicates, items with no partner at all.
- Agent, depth 2: drafts entries and queries. Proposed postings for charges, and investigation messages to the correspondent for items it cannot explain.
- Person: approves. Non-exact matches, adjusting entries, small-difference write-offs within tolerance, and sending queries.
- Agent, depth 1: reports position and ageing. Projected nostro balances for treasury and breaks by age for management.
| Step | The agent does | Depth | Stays with a person |
|---|---|---|---|
| Load | Reads unmatched items | 1 | None |
| Search | Finds candidates | 1 | None |
| Propose | Explains each proposed match | 2 | Approving non-exact matches |
| Confirm exact | Confirms format-only misses | 3 | Spot checks |
| Classify | Labels charges, timing, duplicates | 1 | Disputed labels |
| Entries and queries | Drafts postings and messages | 2 | Posting and sending |
| Report | Ageing and projected balances | 1 | Funding decisions |
Which controls apply, and what evidence do they leave?
Reasons for every match. Every proposal carries the fields compared and the result of each. A reviewer can reject a match by pointing to the field that disagrees. Evidence: the match record with the reviewer's decision.
Tolerance in the bounds. Small differences may be written off within a tolerance finance sets, per item and in total per period. The bound refuses any write-off above either. Evidence: the tolerance version used and the running total.
Separation of matching and posting. The agent proposes adjusting entries; it does not post them to the ledger. Evidence: held verdicts with the approver's name.
Ageing that cannot be reset. An item's age runs from its first appearance. Reversing and rebooking an item does not restart the clock. The agent tracks items by origin, not by booking date.
Statement integrity. The agent checks for statements imported twice or with gaps in sequence before it works any break.
What should you measure?
- Breaks by age band. Old breaks are where losses hide.
- Agent-proposed matches rejected by reviewers. A rising rate means the matching logic has loosened.
- Matches reversed after approval. Each is a review failure as well as an agent one.
- Correspondent charges identified and queried, and amounts recovered.
- Unplanned nostro overdrafts. Better projected balances should reduce them.
Where does it usually go wrong?
Forced matches. Two items with the same amount on the same day are paired, but they are different payments. The real partner of each is still out there, and two breaks are now hidden. Require at least one reference field to agree for any proposal, and send amount-only pairs to a person.
Offsetting breaks. A debit break and a credit break of similar size are matched against each other. The net looks clean; the underlying problems remain. Proposals should never pair two items from the same side.
Death by tolerance. Small write-offs within tolerance add up. Watch the total per period, not just the item.
Duplicates misread. An apparent duplicate on the statement may be two genuine payments. The agent drafts a query before proposing any reversal.
Customer money in a house account. Some nostros carry funds that belong to customers, such as balances used to settle client or e-money payments. A break there may be a shortfall in customer money, not just an accounting difference. Flag those accounts so their breaks also reach the safeguarding owner; whether an agent can reconcile safeguarded customer funds sets out the extra care involved.
The same matching discipline applies when you reconcile bank accounts to the general ledger. Safeguarding reconciliations look similar but have a different requirement side, set out in reconciling e-money safeguarding accounts. The general bounds for bank agents are in AI agents in banking.
Where Pryme fits
In Pryme, match proposal and exact-match confirmation are separate capabilities, each certified through Attest on your own past breaks. Your own ledger reaches the agent as sealed data and correspondent statements as external, so a proposal shows which side each fact came from. Postings and write-offs are held, and every verdict is filed.
Questions people ask
Can the agent send investigation messages to correspondents?
In this design a person sends them. Once the drafts are consistently accepted unchanged, standard queries can move to depth 3 with their own certificate.
What about many-to-one matches?
The agent can propose them, for example one statement entry covering several outgoing payments. These always go to a person, because the space of possible combinations makes false matches more likely.
Does the agent need access to payment messages as well as statements?
It helps. The original payment message often holds the reference that ties two sides together. Read access is enough.