Automated reconciliation of incoming payments: from the payment reference to the payer's NDG
Incoming payments arrive with a free-text payment reference written by whoever paid: abbreviated names, partial references, typos, a different format from every ordering bank. Linking that reference to the final payer's NDG — the unique counterparty identifier in the core systems — was done by hand, transaction by transaction, on a flow in the order of hundreds of thousands of transactions a year: a volume no manual process absorbs without falling behind. The cost is not only time: an unattributed payment sits in suspense, and a payment attributed to the wrong position creates an error that surfaces downstream.
Analysis
Inventory of incoming flow formats and recurring reference structures, analysis of the signals actually usable for matching (name, ordering IBAN, case references, internal codes) and mapping of which combinations produce a certain match and which only a candidate. The decisive step in the analysis: the two errors are not equivalent. A payment attributed to the wrong position costs more than a payment left in suspense, and calibration has to be done on that asymmetry, not on overall match rate.
Solution
A pipeline that normalizes the payment reference, extracts the relevant entities and compares them against the counterparty registry, producing a candidate NDG with a confidence score. Above the agreed threshold attribution is automatic; below it, the case is routed to an operator with ranked candidates and the reason for each, so the human decision starts from work already done rather than from a line of text.
Architecture
Normalization and entity extraction from the free-text reference, deterministic rules first on exact identifiers (IBAN, case code) with the model handling the residual ambiguity, matching against the NDG registry with a confidence score, thresholds configurable by amount band, an audit trail that records for every attribution the criterion that produced it, and integration with the reconciliation systems already in use.
Implementation
A first phase running alongside the existing process: the system proposes the match, operators work as before and compare. This measures real accuracy on live flows and tunes the thresholds against the two error costs before automatic attribution is switched on.
Measured results
- 92% of transactions reconciled automatically on the comparison sample, with the remainder routed to an operator for low-confidence cases
- Automatic attribution of payments whose reference contains recognizable identifiers, with uncertain cases routed to an operator together with the candidates and the reason for each
- Less manual matching work on recurring transactions, where the reference follows stable patterns
- Every automatic attribution keeps a trace of the criterion that produced it and can be reconstructed afterwards
- Thresholds calibrated on the asymmetry between the two errors: the system prefers leaving a case to the operator over attributing it to the wrong position
ROI: Return is read through operator hours freed from manual matching, a smaller balance of suspended payments and fewer downstream corrections for wrong attributions.
Scope and measurement method
- Scope: incoming payment flows in the order of hundreds of thousands of transactions a year, on the most recurring reference types, progressively extended to less regular structures.
- Evaluation set: a sample of roughly 15,000 transactions with the correct NDG already attributed manually by operators, used as the reference for comparison.
- What is measured: the share of transactions reconciled automatically out of the total, and among those the share attributed to the correct NDG. The two have to be read together: raising the threshold improves the second and worsens the first.
- The two errors are counted separately. A payment left to the operator is a processing cost; a payment attributed to the wrong position is an error that propagates, and weighs more.
- Measured share: 92% of transactions reconciled automatically on a sample of roughly 15,000 transactions. The reference period for this measurement is still to be confirmed: we publish only what is already verified.
Client: Project delivered for FBS SPA. www.fbs.it