What Is Banker’s Rounding and How Does It Work?

Banker’s rounding is a method for handling values that fall exactly halfway between two whole numbers: instead of always rounding .5 upward, it rounds to the nearest even number. So 2.5 becomes 2, and 3.5 becomes 4. The technique exists because always rounding .5 up pushes every tie in the same direction, and that one-way push accumulates into measurable error across large datasets. By splitting midpoint values evenly between rounding up and rounding down, banker’s rounding keeps aggregate totals much closer to the true unrounded sum. It is the default rounding mode under IEEE 754, the standard that governs floating-point arithmetic in virtually all modern processors.¹

How the Rule Works

The method only changes behavior at exact midpoints. For anything else, banker’s rounding behaves like ordinary rounding: 3.7 goes to 4, 6.2 goes to 6, and 8.4999 goes to 8. The special rule kicks in only when the fractional part is exactly .5, and it looks at the digit sitting to the left of the decimal point.

If that digit is even, the .5 drops away. So 2.5 stays at 2, because 2 is already even. If the digit is odd, the number rounds up. So 3.5 becomes 4. A few more examples: 4.5 becomes 4, 7.5 becomes 8, 0.5 becomes 0, and 1.5 becomes 2. The result after a tie always lands on an even number.

Negative Numbers

The same even-number rule applies symmetrically on the negative side. So -2.5 rounds to -2, since 2 is already even, and -3.5 rounds to -4. That symmetry matters in financial systems where credits and debits run through the same rounding logic. A method that treated positive and negative midpoints differently would reintroduce the bias the technique is meant to eliminate.

When the Value Only Looks Like a Midpoint

The parity check applies only to true midpoints. A value like 4.5001 is not a midpoint; it is closer to 5 and rounds up under any method. Likewise, 4.4999 rounds down. Software implementations examine all trailing decimal places before deciding whether a value is really halfway. This is worth knowing because binary floating-point representation can make a number that looks like 4.5 on screen actually store internally as something like 4.4999999999999996, which is not a midpoint and will not trigger the even-number rule.

Why Always Rounding Up Creates Bias

The traditional round-half-up rule feels intuitive. 2.5 goes to 3, 7.5 goes to 8, done. In any single calculation the difference between methods is trivial. The problem is structural: every midpoint moves in the same direction, so the push accumulates.

Picture 10,000 transactions with randomly distributed fractional components. Roughly half the midpoint cases will have an even preceding digit and half odd. Under round-half-up, all of them round upward. Under banker’s rounding, half go up and half stay put. The gap between the two approaches grows linearly with the number of midpoint values. In interest calculation, payroll processing, or securities settlement, where millions of line items pass through rounding every day, even fractions of a cent per transaction add up to real money.

That accumulation is where reconciliation headaches come from. An internal ledger that consistently rounds up will drift above the sum of its original unrounded values. When that ledger gets compared against an external system using a different method, the totals diverge. Banker’s rounding keeps the aggregate close to the true unrounded sum because the upward and downward adjustments roughly cancel.

Where You’re Already Using It by Default

IEEE 754, the international standard for floating-point arithmetic, defines five rounding modes. The default is “round to nearest, ties to even,” which is banker’s rounding.¹ Every modern processor that implements the standard ships with this mode active, so the vast majority of arithmetic on any computer, phone, or server already uses round-half-to-even at the hardware level.

Programming languages follow suit. In C# and .NET, Math.Round() defaults to banker’s rounding. Microsoft describes the behavior as “rounding to nearest even” and notes that it “conforms to IEEE Standard 754, section 4” and is “the standard in financial and statistical operations.”² To get traditional round-half-up behavior, you have to pass MidpointRounding.AwayFromZero explicitly. Python 3’s built-in round() works the same way: round(0.5) returns 0, and round(1.5) returns 2.

This surprises developers regularly. Someone writing payroll software might assume round(2.5) returns 3, test a few values, and only learn the default differs from school arithmetic when an accountant flags the discrepancy.

Rounding Mode Alone Isn’t Enough

Picking the right rounding mode only helps if the underlying number is stored accurately. Many common decimal fractions, including 0.1 and 0.01, cannot be represented exactly in binary floating-point and get silently rounded to the nearest representable value when stored.³ For financial software, the practical fix is to use decimal-based data types (such as decimal in C# or Python’s Decimal module) that store numbers in base 10 and represent cents exactly. Rounding mode and storage type are separate decisions, and both have to be right.

Where Banker’s Rounding Does Not Apply

A common misconception is that banker’s rounding is the standard throughout finance. It is not. Several regulatory regimes override the IEEE default with their own rules, and getting this wrong can cause compliance problems.

Federal Tax Returns

The IRS uses the opposite approach. On federal tax returns, taxpayers are told to drop amounts under 50 cents and round amounts from 50 to 99 cents up to the next dollar.⁴ Under that rule, $2.50 becomes $3, not $2. That is standard round-half-up, not banker’s rounding.

The IRS also requires consistency: if you round to whole dollars, you have to round all amounts on the return, not just some. When adding multiple amounts to arrive at a line total, include the cents during addition and round only the final result.⁵ A tax application that uses the IEEE default will produce midpoint results that don’t match IRS expectations, so developers need to override the default and apply round-half-up explicitly.

Consumer Credit Disclosures

Federal consumer lending rules take yet another approach. Rather than mandating a rounding method, Regulation Z sets accuracy tolerances within which a disclosed Annual Percentage Rate is considered correct. For most consumer credit transactions, the disclosed APR is accurate if it falls within one-eighth of one percentage point (0.125%) of the precisely calculated rate. For irregular transactions involving features like multiple advances or uneven payment amounts, the tolerance widens to one-quarter of one percentage point (0.25%).⁶ Regulation Z also permits creditors to disregard the effect of collecting payments in whole cents when performing calculations and disclosures.⁷ The regulation cares about final accuracy, not the specific rounding method used to get there.

Quick Reference: Which Convention Goes Where

Hardware and most software defaults: IEEE 754’s round-to-even is the default at the processor level and in languages like Python 3 and C#. A built-in rounding function with no mode specified is probably giving you banker’s rounding.²
Federal tax returns: round-half-up. Override the default.⁴
Consumer lending disclosures: Regulation Z sets tolerance bands rather than a specific method.⁶
Scientific and statistical work: banker’s rounding is widely used to prevent systematic bias in aggregated results, and ISO 80000-1 includes a normative annex on rounding.
Internal financial systems: large transaction processors like ERP platforms and trading engines generally use banker’s rounding internally to minimize cumulative drift, even when customer-facing outputs follow a different convention.

The rounding method has to match the regulatory or business context. Banker’s rounding is the mathematically sound default for reducing aggregate error, and that is why IEEE 754 adopted it. But specific regimes override that default with their own rules, so the first question for any financial calculation is which rounding convention it actually requires.

1
Arm Developer. ARM Compiler ARM C and C++ Libraries and Floating-Point Support User Guide – IEEE 754 Arithmetic and Rounding
2
Microsoft Learn. Math.Round Method (System)
3
Oracle Documentation. What Every Computer Scientist Should Know About Floating-Point Arithmetic
4
Internal Revenue Service. Publication 17 (2025), Your Federal Income Tax
5
Internal Revenue Service. Instructions for Form 8725 (12/2025)
6
eCFR. Determination of Annual Percentage Rate
7
eCFR. 12 CFR Part 226 – Truth in Lending (Regulation Z)