Cross-Account Fund Transfer - Code Review Caught Two Ways Money Could Go Missing
Built a fund transfer feature ahead of a planned account restructuring in mid-December, and an independent review caught two separate ways money could silently vanish or get fabricated.
This is the English version of a post originally written in Korean for my algorithmic trading system devlog(new tab).
Getting ready for an account restructuring
An account restructuring is scheduled for mid-December.
Ahead of that, a new feature was built to move part of the funds from one account to another. It stays off most of the time, and only gets switched on when the day actually comes.
The transfer splits into two legs, a withdrawal and a deposit. Each leg is idempotent (sending the same request twice only processes it once), and a verification step checks that the total balance across both accounts is unchanged afterward.
What happens if only one leg fails
Once the code was written, an independent AI review was requested.
The most serious issue it flagged was this: if the second leg (the deposit) fails after the first leg (the withdrawal) already succeeded, only the withdrawal stays recorded in the ledger.
And in that case, no alert fires and nothing gets logged — so one account's balance quietly shrinks without anyone noticing. If that happened repeatedly, the real cash balance and the ledger's baseline could drift apart permanently.
The fix was to immediately put the whole transfer into a blocked state with an alert the moment the deposit leg fails, and keep blocking any other activity on that account until the same transfer is explicitly retried. Instead of failing quietly, it now stops visibly.
What happens if the retry amount doesn't match
After the fix went back for another review, a second issue turned up.
When resuming an interrupted transfer, entering a different amount than the original request was accepted without question. Both the relaxed safety guard and the post-transfer verification were checking against whatever amount was typed in, not the original one.
That gap could be used to fabricate funds out of nowhere. The reviewer even reran the test with a different amount typed in and reproduced it.
The fix was straightforward: compare the newly entered amount against the original request amount recorded at the time, and reject the retry outright if they differ by more than a tiny rounding margin, or if the original record can't be read.
Only after this second fix did the merge get approved. The feature is still switched off — it only turns on once the mid-December account change actually happens.
Also today: a reporting notation experiment got redesigned
Separately, an experiment was underway to change how a certain unit notation is displayed in reports.
Measured against a bar set in advance, this version showed a clear effect but fell short of the pass threshold, so it wasn't adopted. A different placement for the notation is being redesigned instead, to be tested again at the end of the month.