acceptable rounding practices in banking.

  • Thread starter Thread starter cj
  • Start date Start date
C

cj

Lets assume all calculations are done with decimal data types so things
are as precise as possible.

When it comes to the final rounding to cut a check to pay dividends for
example in VB rounding seems to be done like this

3.435 = 3.44
3.445 = 3.44

Dim decNbr1 As Decimal
Dim decNbr2 As Decimal
decNbr1 = InputBox("Enter a number")
decNbr2 = Math.Round(decNbr1, 2)
MessageBox.Show(decNbr2)

5 is rounded to the nearest even number. But in all my non-computer
life I was always told 5 rounds up. It makes sense as 1,2,3,4 (4 nbrs)
round down and 6,7,8,9 (4 nbrs) round up. So 5 rounds down or up
depending on whether the number in front of it is odd or even. Still
most folks say 5 rounds up and that's that.

So if a banking auditor comes in would he have a problem with the way VB
rounds 5?

Is that the way banks round?
 
cj,

This has been argued very often. I think that it is the reason that in
version 2005 are now more rounding systems possible.

I have asked often in this newsgroup who was using the Banking rounding, I
never have got any answer.

Cor
 
I had hoped someone here was or is a programmer at a financial
institution and could say how 5 is handled. Surely there is some
approved standard. Banking has got to be highly regulated. we can't
have people being screwed out of .5 cents.

I'm working on a $40,000 telephone bill now made of an tremendous number
of less than 1 minute calls so all the amounts are quite small. The
figures I'm starting with have 3 decimal places. Many were figured
incorrectly so I'll need to figure the correct amount .035 cents X .7
minutes for example = .0245 so should that have been billed as .025 or
..024???????
 
I have heard, but don't know for sure that when rounding a 5, round towards
the even result. I believe VB 6 does just this.

Mike Ober.
 
If this is the way VB is rounding ... wow ...

- a work around would be to ...

either

1. - before rounding, check the 3rd decimal place ... if it is 5 ... add
0.001 to your number, than round. Force the round up.

or

2. - check how the following is handled ...

3.4351 = 3.44 or 3.44
3.4451 = 3.45 or 3.44

If this acts the same as before (you always get 3.44), you will need to use
method 1.

If this works - when you add a small decimal to your original amount you get
the desired result - you could add a small decimal before rounding ...
Watch out for situations where your small decimal could result in a 'problem
number' before rounding... ie: 3.445 .
Depending on the precision of your numbers ... you may want to choose a very
small decimal ...
ie...
3.434999 + 0.000001 = 3.435 = which will give you the wrong 3.44 result...
3.434999 + 0.0000001 = 3.4349991 = which will give you the desired 3.43
result...

so, when you have...

3.445 + 0.000001 = 3.4450001 = you should get you desired result of 3.45 ...
as long as the rounding function looks past the third decimal ... the 5 ...
before it rounds.


Hope this helps...

jeff...

PS: having dealt with accountants / auditors before ... the problem does not
lie with individual transactions ... the problem lies when you try to
reconcile different reports ... sums of many 'rounded' amounts compared to
lump sum amounts from other reports ... you will not balance penny for penny
.... and to some this is an issue... you need to ask yourself ... what is
the materiality of the problem ... if we are taking .005 for a few
transaction , none issue auditor will not bother ... however, if we are
talking 0.005 for 2 million tractions (10,000 dollars) ... you may have an
issue ... accountants get comfussed when things do not balance... trust me
I am married to one.
 
You taught me one thing.

? math.round(.451d, 1)
0.5D
I didn't know the last 1 had any effect on the rounding.

According to your link which is
http://en.wikipedia.org/wiki/Banker's_rounding

"Round up or down to the nearest even digit if the next digit is a five
followed (if followed at all) only by zeros. That is, increase the
rounded digit if it is currently odd; leave it if it is already even."
? math.round(.4500000000000000000000000001d, 1)
Click to expand...
0.5D
that's good.
? math.round(.45000000000000000000000000001d, 1)
Click to expand...
0.4D
Hummmm, guess I hit VB's precision limits cause this isn't correct.
Good enough for me though.

Now to understand how the phone company figures
..035 * .3 = .012 when I get .0105
even better they say
..035 * .3 + .6 = .613 in some places and .612 in others.

Must be anther type of rounding called they'll never miss .0015 to .0025
dollars. But on each of 161,000 calls? Still that's just my nature to
wonder that. I've been advised to find their errors greater than $.01
per call.


If this is the way VB is rounding ... wow ...
Click to expand...

what did you thought of Delphi and PHP etc etc etc ?

Bankers rounding is not invented by MS it is a standard

for accounting you would use common rounding

http://en.wikipedia.org/wiki/Banker's_rounding

regards

Michel Posseth [MCP]




jeff said:
If this is the way VB is rounding ... wow ...

- a work around would be to ...

either

1. - before rounding, check the 3rd decimal place ... if it is 5 ... add
0.001 to your number, than round. Force the round up.

or

2. - check how the following is handled ...

3.4351 = 3.44 or 3.44
3.4451 = 3.45 or 3.44

If this acts the same as before (you always get 3.44), you will need to
use method 1.

If this works - when you add a small decimal to your original amount you
get the desired result - you could add a small decimal before rounding
... Watch out for situations where your small decimal could result in a
'problem number' before rounding... ie: 3.445 .
Depending on the precision of your numbers ... you may want to choose a
very small decimal ...
ie...
3.434999 + 0.000001 = 3.435 = which will give you the wrong 3.44 result...
3.434999 + 0.0000001 = 3.4349991 = which will give you the desired 3.43
result...

so, when you have...

3.445 + 0.000001 = 3.4450001 = you should get you desired result of 3.45
... as long as the rounding function looks past the third decimal ... the
5 ... before it rounds.


Hope this helps...

jeff...

PS: having dealt with accountants / auditors before ... the problem does
not lie with individual transactions ... the problem lies when you try to
reconcile different reports ... sums of many 'rounded' amounts compared to
lump sum amounts from other reports ... you will not balance penny for
penny ... and to some this is an issue... you need to ask yourself ...
what is the materiality of the problem ... if we are taking .005 for a few
transaction , none issue auditor will not bother ... however, if we are
talking 0.005 for 2 million tractions (10,000 dollars) ... you may have
an issue ... accountants get comfussed when things do not balance...
trust me I am married to one.
Click to expand...
Click to expand...
 
Dear Customer,

The Banker's rounding is a standard rule in certain industries.
Anyway, if you did not like that, in vb.net 2005 we have an option to
change the behavior.
Here goes the code for your reference.
Sub Main()
Dim d1 As Decimal
d1 = 0.5
Dim d2 As Decimal
d2 = 1.5
Console.WriteLine(Math.Round(d1, MidpointRounding.AwayFromZero))
Console.WriteLine(Math.Round(d2, MidpointRounding.AwayFromZero))
Console.WriteLine(Math.Round(d1, MidpointRounding.ToEven))
Console.WriteLine(Math.Round(d2, MidpointRounding.ToEven))
End Sub

Best regards,

Peter Huang

Microsoft Online Community Support
==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================
This posting is provided "AS IS" with no warranties, and confers no right
 
The Banker's rounding is a standard rule in certain industries.
Anyway, if you did not like that, in vb.net 2005 we have an option to
change the behavior.
Here goes the code for your reference.
Sub Main()
Dim d1 As Decimal
d1 = 0.5
Dim d2 As Decimal
d2 = 1.5
Console.WriteLine(Math.Round(d1,
MidpointRounding.AwayFromZero))
Console.WriteLine(Math.Round(d2,
MidpointRounding.AwayFromZero))
Console.WriteLine(Math.Round(d1, MidpointRounding.ToEven))
Console.WriteLine(Math.Round(d2, MidpointRounding.ToEven))
End Sub
Best regards,

Peter Huang
Click to expand...

Peter, why is the default implemention on .ToString different from Math.Round?
Consider the following:
dim d1 as Decimal = 0.5D
Console.WriteLine(Math.Round(d1)
Console.WriteLine(d1.ToString(n0))

You would get the following results:
0.0
1.0

See http://devauthority.com/blogs/jwooley/archive/2006/03/24/806.aspx for
my full writeup.

Jim Wooley
http://devauthority.com/blogs/jwooley/default.aspx
 
Hi Jim,

Please try the code below.

Dim d1 As Decimal = 0.5D
Dim d2 As Decimal = Math.Round(d1)
Console.WriteLine(Math.Round(d1))
Console.WriteLine(d1.ToString())

The order in the code below is that.
First we get a decimal = Math.Round(d1) which is 0D.

And then Console.WriteLine have an overload methos to accept a Decimal as a
parameter, we did not call ToString()

Console.WriteLine(Math.Round(d1))



Best regards,

Peter Huang

Microsoft Online Community Support
==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
 
Dim d1 As Decimal = 0.5D
Dim d2 As Decimal = Math.Round(d1)
Console.WriteLine(Math.Round(d1))
Console.WriteLine(d1.ToString())
The order in the code below is that.
First we get a decimal = Math.Round(d1) which is 0D.
And then Console.WriteLine have an overload methos to accept a Decimal
as a parameter, we did not call ToString()
Peter Huang
Click to expand...

Yes, I understand that part. My question was why the ToString("n0") overload
(using Format I assume) uses the overloaded version of round (AwayFromZero)
rather than the default banker's rounding. This causes UI binding to an unrounded
value (not explicitly rounded) to produce values which do not agree with
computed values which sum the unrounded value and display a math.round()
value. I have had end users notice this and question the system's accuracy
as it doesn't appear able to do simple math correctly whereas it is actually
just a difference in rounding schemes. It has also caused me to replace the
simple calls to Math.Round with the overloaded version thereby defeating
the advantage of the ISO standard.

Jim Wooley
http://devauthority.com/blogs/jwooley/default.asp
 
Hi Jim,

Thanks for your quickly reply!
Yes, the code ToString("n0") will use common math round automatically.

I do understand your concern in this scenario, I highly suggest you can
submit this feedback to our product feedback center:
http://lab.msdn.microsoft.com/productfeedback/default.aspx


Thanks for your understanding!

Best regards,

Peter Huang

Microsoft Online Community Support
==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
 
Back
Top