Why does the financial system only retain two decimal places? What if there is an amount with more than two decimal places?

I suddenly discovered a problem. The financial system in our lives only has two decimal places at most, such as 12.37, which is accurate to minutes. However, when calculating with two decimal places and non-integers, it will also result in three decimal places, such as the daily rate of a bank. , there will definitely be calculations with three decimal places or more, but why do we only see the balance with two decimal places? Aren’t the extra decimal places also money? Are they omitted? How come they are omitted? I think this question is interesting.

My guess:

In fact, as long as our financial system only uses two decimal places, when more than two decimal places are generated, the following decimal places are not needed, just do not, instead of adding one after five, if one is added, it will cause more money to the user. , even if it is 0.001 yuan more, the loss in the entire system will be huge, so when there are more than two decimal places, we can only directly omit the following decimal places, even if it is 0.239, we must omit 0.009, this 0.009 The loss of RMB 10,000 can only be borne by the user.

For example, bank systems, Alipay, these all have two decimal places. We generally use decimal(10,2) for the balance field, retaining two decimal places. I suddenly thought of this problem, I am so confused, I don’t know Is it what I thought.

For example, when Alipay uses points and shopping coupons to deduct multiple orders at the same time, the deduction money seems to be split under each order according to the proportion of the order amount, so a decimal appears, but the decimal is also two Well, I haven't paid close attention and I don't know if the deductions for multiple orders add up to the amount deducted when placing the order.

If that’s what I think, then I feel like we must have lost a lot of money a lot of the time? I originally wanted to solve this problem by keeping a few more decimals, but I feel that there may be infinite decimals, which is still unlikely. Will it only cause the user to lose money, even just a little bit.

I hope someone can give me some guidance. I'm so confused. I'm currently encountering this kind of problem in my project.

Thank you!

Reply content:

I suddenly discovered a problem. The financial system in our lives only has two decimal places at most, such as 12.37, which is accurate to minutes. However, when calculating with two decimal places and non-integers, it will also result in three decimal places, such as the daily rate of a bank. , there will definitely be calculations with three decimal places or more, but why do we only see the balance with two decimal places? Aren’t the extra decimal places also money? Are they omitted? How come they are omitted? I think this question is interesting.

My guess:

In fact, as long as our financial system only uses two decimal places, when more than two decimal places are generated, the following decimal places are not needed, just do not, instead of adding one after five, if one is added, it will cause more money to the user. , even if it is 0.001 yuan more, the loss in the entire system will be huge, so when there are more than two decimal places, we can only directly omit the following decimal places, even if it is 0.239, we must omit 0.009, this 0.009 The loss of RMB 10,000 can only be borne by the user.

For example, bank systems, Alipay, these all have two decimal places. We generally use decimal(10,2) for the balance field, retaining two decimal places. I suddenly thought of this problem, I am so confused, I don’t know Is it what I thought.

For example, when Alipay uses points and shopping coupons to deduct multiple orders at the same time, the deduction money seems to be split under each order according to the proportion of the order amount, so a decimal appears, but the decimal is also two Well, I haven't paid close attention and I don't know if the deductions for multiple orders add up to the amount deducted when placing the order.

If that’s what I think, then I feel like we must have lost a lot of money a lot of the time? I originally wanted to solve this problem by keeping a few more decimals, but I feel that there may be infinite decimals, which is still unlikely. Will it only cause the user to lose money, even just a little bit.

I hope someone can give me some guidance. I’m so confused. I’m currently encountering this kind of problem in my project.

Thank you!

There is a banker rounding method, namely:

When the value of the rounding digit is less than 5, it is discarded directly;
When the value of the rounding digit is greater than or equal to 6, it is rounded after carrying;
When the value of the rounding digit is equal to 5, there are two situations: there is something after 5 Other numbers (non-0) will be rounded and discarded; if 5 is followed by 0 (that is, 5 is the last digit), then whether a carry is needed is determined based on the parity of the digit before 5. Odd numbers will be carried and even numbers will be discarded.

According to the above rules, suppose we require numbers to be accurate to single digits:

49.6101 -> 50
49.499 -> 49
49.50921 -> 50
48.50921 -> 48
48.5101 -> 49

Here is a good example to see the advantages of this calculation method:

2.55 + 3.45 = 6

If we want to retain one decimal place and convert 2.55 and 3.45, it will become like this:

2.6 + 3.5 = 6.1

Obviously this is 0.1 more, then calculate according to our "rounding up to five", 2.55 can actually be said to be 2.550, the 5 we want to round out is followed by 0, then according to the previous The parity of one digit is used to determine whether there is a carry. Obviously, if the front is an odd number, then the carry is 2.6. For 3.45, if the front of 5 is an even number, then it is discarded, and the result is 3.4. Therefore, the calculation of the two is as follows:

2.6 + 3.4 = 6

2016-11-24 Additional instructions

Someone proposed 2.55 + 2.55, which is still an overcount of 0.1. Why didn’t I give this example? Because rounding is used, this situation will also exist. The key point is 2.45 + 2.45, which will be rounded off by conventional rounding. We need to avoid this situation of being close to the middle value without carrying, because only in this way can we ensure that the probability of rounding and carrying in the approximate calculation is equal. This is the main purpose. After all, as long as the accuracy is limited, there must be loss. We only need to ensure that the probabilities are equal under a large number of samples.

The funding issue in this area still needs to consider business needs. According to my previous practice, I saved 4 decimal places. Make a choice based on different scenarios! But all the amounts displayed at the front desk only show 2 digits, and the digits are rounded down

Such as the following scene:

Balance withdrawal, transfer, etc.

Generally, the number

---

will be rounded down

, for example 10.1234; then the actual amount of cash that can be withdrawn is 10.12. Instalment related

For example, if the total bank limit is 1,000 yuan, and you just buy something, and you spend it all, you can apply for installments. Divided into 3 installments;

---

According to normal thinking,

1000/3=333.3333333
; after rounding, it becomes 333.33; when you have paid off all three installments, you find that you only paid 999.99. This is a trap The general practice is:

The first two periods are calculated by rounding. The last period, calculated by subtraction:

1000-333.33-333.33=333.34
; Other instructions

Depending on different businesses, the number of reserved digits and trade-offs are different. Such as the net value of the fund. The length of the decimal point still affects the amount of funds greatly. The more accurate this is, the better. Communicate with the product about your specific needs!

Actually, this is not the case. When our e-commerce financial system performs reconciliation and commission calculation, it all reaches the last six digits. decimal(16, 6) will not be rounded until after calculation. Generally, the final rounding step is written in the agreement. I think the last step should fall within the scope of negotiation. It has nothing to do with the system anymore.

I don’t understand very professional things, but I think there is nothing to consider when building a system. All users after two decimal places will lose

If the amount is 0.111, it will be recorded as 0.11

If the amount is 0.111, only 0.11 will be output

Of course it won't be two digits, both calculation and storage are 6 digits and above (it's not clear if there are more, but at least 6 digits is for sure)

It's just that the final points given to the user cannot be cashed out after the calculation. Calculate the final result according to a certain algorithm.

The integer 1 in the computer is not equal to the decimal 1.0, so the decimals in money are converted to integers for processing

I think it is safer to use cents as the unit of measurement for the amount field stored in the database. In this way, when displaying it at the front desk, round it up first and then divide it by 100 to get the yuan.

The calculation method is "give" and "receive", if the bank is the main body ,

"Give": If the field value is 200.11, then the calculated yuan is 2 yuan and 1.1 cents. This 1.1 cents can be discarded and only give 2 yuan, that is, only the integer part is taken.
"Receive": It can be relatively selfish. In line with the design principle of never losing money, 1 centimeter should be counted as 1 point. Then it is judged whether the field value has a decimal point. If there is a decimal point, round it to +1, if not, just take it. If it is based on rounding. .Masters need to judge and process values ​​with decimal points. Personal preference is the principle of never losing money. This principle should also be a common principle of financial institutions.
The key point is to use cents as the unit of measurement for amounts, if it is hundreds of millions. , you need to consider the Max of the data type, don’t exceed the range.

The questioner, you actually revealed a secret method for financial institutions to collect money, hahaha.

收款时直接把分以后的数字进位处理，付款时直接截去分以后的小数位。

展示显示2位小数不代表系统中处理都是2位小数吧。我觉得应该会有很多位

要么四舍五入，要么向下取整，保留两位

合理的均分方法可以固定小数位.
比如100元平均分成N份(保留2为小数)并计算尾差:

 '33.33',
  1 => '33.34',
)
100=16.66+16.66+16.66+16.66+16.66+16.70
100=16.66*(6-1)+16.70
array (
  0 => '16.66',
  1 => '16.70',
)

4舍5入，没有什么好纠结的，相信老祖宗的智慧。

从统计学的角度上来看，在大规模的应用的情况下，你们金融系统多出来的和少掉的钱是近似的，同样的，用户多出来和少掉的钱也是近似的，没有必要纠结。

没有做过金融系统开发，权当抛砖引玉了。