ATM settlement reconciliation rework

The bank reconciled ATM transactions against the switch operator's settlement files with a process that was half stored procedures and half a spreadsheet one senior operations officer had maintained for years. Unmatched items sat for over a week on average, and month-end was routinely two late nights for her team. What actually funded the rework was an examination finding that flagged the manual controls around settlement — suddenly a modernization nobody had time for became a project with a deadline attached to an audit response.

Senior backend developer, one of five on the settlements team, for about fourteen months. I sat between a business analyst who owned the audit response and the operations officer whose spreadsheet we were retiring — she knew every edge case, and half my job was extracting those from her politely. QA was a separate team, and every release went through a monthly change advisory board.

I owned the matching engine and the exception queue backend: ingestion for the two settlement file formats our switch produced, the multi-pass matching job itself, and the API the review screens sat on. I also wrote the cutover plan, including the two parallel-run cycles where the old spreadsheet process kept running alongside mine so operations could compare outputs line by line. Another developer owned the review UI; I did not touch frontend on this one.

The big decision was deterministic multi-pass matching with an explicitly ordered rule set, instead of the fuzzy scoring approach the vendor pitched us. Operations needed to explain to auditors exactly why any two records matched, and 'the score was above 0.9' is not an explanation a bank examiner accepts. I also insisted we match into staging tables in our own schema rather than writing anything back into core — the core banking database was off-limits territory, and keeping a hard boundary there is what let us release monthly instead of quarterly.

The batch window was fixed: settlement files arrived by 11pm and branches opened at 8am, and every other nightly job had a prior claim on that window. The core schema could not be touched at all, the change advisory board met monthly whether we were ready or not, and the audit response gave us a hard external date. We also had to keep the operations officer's process alive and identical until sign-off, which meant every discrepancy between her spreadsheet and my service was my bug to explain, even the times she was wrong.

Unmatched items went from an average age of about nine days to being worked the same morning, and the audit finding was formally closed on the strength of the new controls. The nightly run matches roughly 180,000 transactions in under forty minutes, well inside the window. The operations officer moved from maintaining the spreadsheet to reviewing the exception queue, which she runs to this day — the parallel runs caught two real defects in my matching order, and I still think giving her veto power over cutover was the best process decision on the project.

A business analyst owned the audit response and requirements, the settlement operations officer was our subject-matter expert and toughest tester, two other developers built the review screens, and a separate QA team ran regression against both file formats. The switch operator's support desk deserves a mention for answering file-format questions that their own documentation contradicted.