Why would you? For most forward-looking calculations, the uncertainty of the future completely swamps any cent-rounding.
Even for plain-vanilla bond price calculations, floats are the right tool for the job. Say you have a bond that pays $5 every year for 10 years, then $100. What's that worth today?
Well, you have a forecast yield curve of interest rates. Say it's quoted as continuously compounded rates, so then you get something like price = sum_{t=1..10}($5*exp(-r(t)*t)) + $100*exp(-r(10)*10).
But wait, say you actually have 1000 different potential paths of interest rates, and you want to average over all of them.
Oh, and there's a 1% chance of default every year.
Oh, and actually these are mortgages, so there's a path-dependent chance of them refinancing every year, if the rates get low enough.
And then there's an overall economic forecast, so if you have a bunch of mortgages, there's a bigger chance they'll all default at the same time.
And so on. Rounding the cents isn't really worth the worry, once you're putting noisy forecasts through `exp` (or worse special functions).
This applies for vanilla bond valuation, any option, any future. More so if you want risk measures (what if rates go up 0.10%? volatility increases?), and so on.
This is true in complex scenarios but not true in other finances scenarios. For example, there is a reason why any electronic exchange will use integers with implied decimal precision as the wire format and will continue to use such representations before and after encoding/decoding. We do not need to do hugely complex operations, it is mostly simple comparisons and some simple maths operations. We absolutely need exact precision and speed and it is difficult to get that when using doubles.
In parts of the stack where things are more complex and outside of the critical path, then yes, you use floating point.
Also, it isn't just that rounding the cents isn't worth it, it is that if you work with implied decimal integers with an implied 2DP, then you're going to end up with massively inaccurate results after a few operations.
Even for plain-vanilla bond price calculations, floats are the right tool for the job. Say you have a bond that pays $5 every year for 10 years, then $100. What's that worth today?
Well, you have a forecast yield curve of interest rates. Say it's quoted as continuously compounded rates, so then you get something like price = sum_{t=1..10}($5*exp(-r(t)*t)) + $100*exp(-r(10)*10).
But wait, say you actually have 1000 different potential paths of interest rates, and you want to average over all of them.
Oh, and there's a 1% chance of default every year.
Oh, and actually these are mortgages, so there's a path-dependent chance of them refinancing every year, if the rates get low enough.
And then there's an overall economic forecast, so if you have a bunch of mortgages, there's a bigger chance they'll all default at the same time.
And so on. Rounding the cents isn't really worth the worry, once you're putting noisy forecasts through `exp` (or worse special functions).
This applies for vanilla bond valuation, any option, any future. More so if you want risk measures (what if rates go up 0.10%? volatility increases?), and so on.
Floats work just fine for this.