IBM partially has a hold on banking because they have supported decimal floating point. By switching binary floating-point from radix 2 to radix 10 (decimal exponents) they get rid of some of the problems.

IEEE has had these Decimal types for a while, but IBM is the only company shipping CPUs with them.

Fixed decimal is still used where appropriate, but Decimal floating point is a critical feature for some processes.

While personal taxes typically drop the cents, tariffs and other taxes are often small percentages as an example.

There are software implementations if you don't need performance.

But Decimal64 has a lot more represented values and it is easier to trap on some edge cases.

As Decimal floating point types were added into C23 we will see if hardware support follows.

Note this is also why HP calculators were more accurate for a given bit size, because the engineering ones used radix 10 floats.

What does radix 10 floating point bring to the table in terms of precision other than a whole new set of rounding problems?

As far as I know, all accounting systems use 'round to nearest cent' integers (or whatever the lowest denomination is in a given currency). Is there a case where calculations using integer cents is in any way inferior to radix-ten fixed point?

In Europe, after MIFID II, equities are priced with tick sizes (i.e. the minium whole unit) that depend on the magnitude of the price, i.e are de-jure (decimal) floating points that behave weirdly.

money systems work with whatever tool is convenient to the operations staff which these days is typically Microsoft Excel and Visual Basic, neither of which come with a built in Decimal type.

this will typically get transmuted through multiple layers of javascript, xml, back end java, cobol, SQL, python, some domain specific language, and back again.