A repayment landed, got split across the investors who funded that loan, and the sum of the parts did not equal the whole.
Not by much. By the smallest unit the currency has.
P2P lending: one loan is funded by many investors, each holding a pro-rata share, and every repayment has to be divided by those shares and credited to individual virtual accounts. The math is trivial until you round. Each share got rounded to the minor unit on its own, and whatever was left over after the division had nowhere to go.
Nothing failed. No exception, no alert. No failed transaction. Every single distribution was internally consistent and looked correct in isolation. The bank side reconciled fine, because the money genuinely arrived.
The remainder just stayed behind, on the platform's own account, one fraction at a time, across every repayment on every active loan.
That is the part worth remembering: a rounding bug in a distribution doesn't surface as an error. It surfaces as a platform that looks very slightly more profitable than it is, holding money that belongs to investors. It reads like a rounding artifact in a report until someone asks whose money it is, and then it's a compliance conversation.
What I do differently now: distribution is a closing operation, not a loop. The remainder is allocated deterministically to a named recipient by an explicit rule, and the invariant (sum of parts equals the original amount, to the minor unit) is asserted in the same transaction that writes the entries. If it does not hold, nothing commits. The check lives in the write path, not only in a test.
I write more about this kind of money-handling detail on my blog: https://polycratia.com/c/317afccf
If you split money between parties in production, your remainder is going somewhere right now, and you probably want to be able to name the account it sits in...