A Low‑Level Bug: Misplaced Decimal in Interest Rate Calculation and the Lessons Learned

Background

The problem originates from a very common interest calculation formula: Interest = principal * daily_rate and daily_rate = annual_rate / 360 . The business initially required the daily rate to be stored with seven decimal places.

Both the annual rate and the daily rate are stored in separate fields; the daily rate is pre‑computed and persisted, so the application simply reads the stored value.

After the system went live without issues, the business later asked to increase the precision to eleven decimal places.

Because the change seemed trivial, the developer quickly modified the SQL that updated the stored daily rate.

However, the existing data had many rows with the old seven‑decimal precision, so the developer asked how to handle the legacy configuration.

The business answered that the new SQL should recalculate the daily rate to eleven decimals and run an update.

The developer assumed the calculation was straightforward and agreed.

When the new SQL was executed, the correct value for a 2.5% annual rate should be 0.00006944444 , but a typo caused the stored value to be 0.00069444444 , ten times larger.

0.00006944444 0.00069444444

This ten‑fold increase in the daily rate multiplied the accrued interest by ten, creating a serious financial error.

Why Was It Not Detected?

The erroneous SQL passed through code review because the developer had both commit and review permissions and approved the change themselves.

There was no separate reviewer; the usual peer‑review process was bypassed.

Testing focused on whether the system could still compute interest with the new precision, not on the correctness of the hard‑coded value.

The tester ran the full business flow, which used the automatically calculated daily rate from the UI, so the test did not expose the wrong constant.

The tester only verified that the SQL syntax was correct, trusting the developer to ensure data correctness.

In production verification, the developer randomly sampled two rows; both happened to correspond to the correctly calculated SQL, leading to a false sense of success.

The verification plan was not rigorous, and luck favored the developer.

How Was It Exposed?

The error was eventually discovered by chance during an unrelated data validation task, where a markedly larger interest amount was observed.

Further investigation traced the anomaly back to the faulty SQL, three days after it had been deployed, by which time erroneous data had already been generated.

If the accidental check had not occurred, the issue would likely have been noticed only when business users compared the inflated figures against expected values.

What Can Be Learned?

The core lesson is that developers should avoid directly modifying critical business parameters; such changes belong to a formal OA approval workflow.

Even seemingly trivial data‑level fixes should be subject to proper change‑management processes to reduce risk.

While rapid, ad‑hoc fixes may feel efficient, they bypass safeguards that protect both the system and the developers.

Broader Reflections on Process and Permissions

In early, fast‑growing companies, developers often have unrestricted database access, which enables quick fixes but also increases the chance of costly mistakes.

As organizations mature, they typically restrict direct database modifications, requiring multi‑level approvals for any change to business parameters.

These controls may slow down response time but ultimately protect the stability of the system and the people operating it.

The author reflects that his early “wild‑west” experience taught him the value of disciplined processes and that developers should respect the boundaries of business‑critical data.