DEV Community

oludeleoluwapelumi
oludeleoluwapelumi

Posted on

I built a free, offline tool to check your transaction logs for one specific silent failure

I built a free, offline tool to check your transaction logs for one specific silent failure

CIF (Chronological Input Failure) has been through a simulation, a mapping against real Apache Fineract defects, and a reconciliation check against real PaySim data. All of that is public. What was missing was a way for someone else to check their own data without having to hand it to me first.

So I built a small command-line tool that does one thing: it checks whether your transaction log's recorded balances actually reconcile with the transactions that supposedly caused them, and flags the ones that don't, unless something in your data already caught it.

It runs entirely on your machine. Nothing gets uploaded, logged, or sent anywhere. You point it at a CSV, it reads it, it prints a report, that's the whole interaction.

What it actually checks
For each row: does old_balance plus or minus the transaction amount equal new_balance? If not, and nothing flags that row as an error already, it gets reported as a candidate anomaly.
That's a narrower test than CIF's original mechanism, which is about validation completing before commit. Most transaction logs don't record validation and commit as separate timestamped events, so this checks something related but smaller: whether the recorded end state is internally consistent with what supposedly produced it.

Why I'm being upfront about its limits
The first time I ran an early version of this exact check against real PaySim data, it flagged 75.92% of transactions. That wasn't a real finding. It took investigating two dataset-specific quirks, untracked merchant balances and balances clipped to zero instead of going negative, plus fixing a direction bug in my own formula, before the number came down to something real: 0.07%, 26 rows, in about 35,000 checkable transactions.
I'm telling you that because if you run this on your own data and get a high number back, that is probably not a discovery. It's much more likely your data has its own quirks the tool doesn't know about yet. Read the flagged rows. Ask why. The full writeup of that process, mistakes included, is linked in the repo.

Try it safely first
There's a small, obviously fake sample file included in the repo specifically so you can see what the tool does before pointing it at anything real.

What I'm actually hoping for
If you run this against your own staging or test data and it flags something real, or if it behaves strangely on your data's specific shape, I want to hear about it either way.

Genuinely, if you try it, even just to say it ran fine and found nothing, tell me. That's useful too, and right now, hearing from real people who actually looked at this matters more to me than the numbers. A false positive you can explain is genuinely as useful to me as a real finding, it's exactly the kind of thing that made the PaySim writeup honest instead of just impressive-looking.

The tool, the code, and everything else CIF has produced so far is here: https://github.com/oludeleoluwapelumi/cif-simulation/tree/main/scanner

Top comments (0)