ReconSync
Finds the debits whose matching credit never arrived.
- Go
- PostgreSQL
- TypeScript
- Docker
The problem
In a transfer, money leaves the wallet and arrives at the destination. Between them sits an API call that can time out, return ambiguously, or succeed silently after the client gave up. When the credit fails and the debit is not reversed, the customer has lost money.
The problem is structural: the system that failed cannot be the system that detects the failure. If the transaction service crashed mid-flow, its reconciliation logic crashed with it — which is why most fintechs fall back to nightly batch, and a customer is out of pocket for twenty-four hours.
What I built
- Watches both legs of a transfer and fires a signed reversal webhook before the regulatory window closes.
- Corroborates with the rail before proposing anything — asking the provider rather than inferring from silence.
- An append-only, hash-chained audit trail with Ed25519 signed checkpoints, and a regulator-ready SLA report in JSON, CSV and PDF.
- Client libraries in Go, Node and Python — one signature scheme, three implementations, cross-checked against each other.
Decisions worth naming
- ReconSync never moves money. Every payload is marked
"advisory": true. Even a total compromise — every key stolen, every row rewritten — cannot cause an unauthorised payment. The worst an attacker achieves is noise in a queue. - Ingest gaps route to suspect, not to reversal. If our own ingest had a hole, a missing credit proves nothing. The system checks its blind spots before it accuses anyone.
- Silence suppression. A tenant outage looks exactly like ten thousand failed credits. It refuses to mass-reverse on that signal.
What is not finished
- Bank connectivity is per-institution: an API where one exists, a settlement-file adapter where one does not.