Home / Knowledge hub / Rounding abuse
Knowledge hub
Rounding abuse
Exploiting how amounts are rounded to gain tiny sums repeated many times.
What it means
Rounding abuse is taking advantage of how an application rounds amounts so that each transaction gains a tiny sum, a fraction of a cent or a paisa, that the system does not notice. Repeated thousands of times, the fractions become real money.
It depends on a gap between what is calculated and what is stored or charged. If an app rounds up when it credits and down when it debits, or rounds each line separately but the total another way, the difference can be collected by splitting actions into many small ones.
Why it matters
The loss per transaction is invisible, which is why it can run for months. Totals drift from the ledger, payouts exceed receipts, and reconciliation shows small gaps nobody can explain. Where money is moved between currencies, the fractions can be larger.
It is also a design signal: money handled with floating-point numbers will round unpredictably. Automated bot traffic makes the repetition cheap, and price manipulation can combine with it. Auditors and finance teams care about it long before customers do, so findings here tend to be taken seriously.
How it shows up
You meet it in currency conversion, tax and discount calculation, fee splits, interest, loyalty points and refunds. The repeated mistakes are storing money as floating-point numbers, rounding at different steps in different places, and letting a user choose the size of each transaction freely.
Store money as integers in the smallest unit, or use a decimal type designed for it. Round once, at a defined step, with a rule everyone uses. Compare the sum of parts with the whole. To test, run many tiny transactions and refunds and check that totals agree to the unit.
Questions people ask
Rounding abuse, answered
Is rounding abuse the same as a salami attack?
Yes, the terms describe the same idea: shaving amounts too small to notice and collecting them many times. Rounding abuse usually refers to a customer exploiting how your rules round, rather than an insider skimming.
Why are floating-point numbers a problem for money?
Binary floating point cannot represent many decimal amounts exactly, so 0.1 plus 0.2 does not equal 0.3. Small errors accumulate. Money should be stored as integers in the smallest unit, or in a decimal type.
Where should rounding happen?
At one defined step with one rule, applied the same way every time. Round the final amount rather than each stage, unless regulation requires otherwise, and test that refunds reverse a charge to the exact same amount.
How would we notice it?
Through reconciliation. Compare what customers were charged, what was credited, and what the payment provider settled. A consistent small gap, growing with volume, points here. Look at accounts with unusually many tiny transactions.
How do we test for it?
Create transactions of very small and awkward amounts, split one purchase into many, convert between currencies and back, and refund partially. Compare the total with a single equivalent transaction. Any consistent difference is worth fixing.
Sources
Where this comes from
Related
Terms that sit next to this one
Price manipulation
Changing a price, quantity or discount in a request so you pay less than you should.
Negative quantity
A numeric field accepting values below zero so balances move the wrong way.
Double spend
Using the same balance, credit or voucher twice by acting faster than your checks.
Payment fraud
Using stolen or fake payment details to buy from your business.
Business logic flaw
Nothing is technically broken, but your own rules turn against you.
Do the totals still add up?
Money rules are business logic, and we test them with awkward amounts, splits and refunds, then report what actually moved. If the numbers differ, you get the requests that show it. Book a pilot on one app.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.