Fintech Settlement System
Reconciles payment processor and bank data so daily settlement closes automatically.
- Timeline
- About 6 months
- Team size
- 5 people
- Platforms
- Web · Server
- Integrated systems
- Payment processor and bank data
Background
Staff reconciled transaction records from payment processors against bank deposit records by hand in spreadsheets, every day. As transaction volume grew, reconciliation started taking more than a day, and delayed closings began affecting the next settlement cycle.
Scope
- Data collection from payment processors and banks
- Automated transaction reconciliation
- Exception-handling screen for mismatched transactions
- Daily settlement closing process
- Settlement result report generation
- Settlement history lookup
Technical decisions
What we chose, and why it fitDid not auto-finalize reconciliation results; only exception cases required staff confirmation before closing
Since settlement involves real money, letting the system finalize automatically would delay catching errors. We split the flow so that transactions matching the rules were processed automatically, while anything outside the rules required a human to confirm and approve before closing.
Stored settlement history in PostgreSQL as immutable records
Settlement data needs to allow tracing back why an amount was what it was, for audit purposes. Closed settlement entries were never edited; corrections were added as new entries instead, so the previous state was never erased.
Engineering challenges
Problem
Each payment processor used a different file format and field naming, so a single reconciliation logic couldn't handle all of them.
Approach
We added an adapter layer that converted each processor's file into a common transaction model, and kept the reconciliation logic looking only at that common model.
Result
Adding a new payment processor now just means attaching a new adapter, with no need to touch the reconciliation logic itself.
Problem
Bank deposits sometimes slipped to the next business day, leaving some transactions each day where the settlement date and actual deposit date didn't match.
Approach
We added a pending-reconciliation state for settlement entries, and if a deposit remained unconfirmed past a set period, it was surfaced separately on staff's screen.
Result
Transactions with delayed settlement dates were tracked continuously instead of falling through the cracks, so nothing that still needed checking after closing got missed.
Handover and operations
We delivered an operations manual for settlement staff along with a document defining exception-handling criteria. We handed over the source code and infrastructure configuration, and agreed that integrating additional payment processors would fall under a separate maintenance scope.