What do banks actually use as a data type for money? [closed]

I'm aware of a few good options:

1. Big integers (e.g., int64_t, mpz_t, any bignum lib) to represent cents or 10-n cents—say, an integer represents 1/100 of a penny (\$1.05 == 10500). This is called a scaled integer.

2. High level library for arbitrary precision decimal arithmetic such as BigDecimal in Java, Decimal in Python, decimal.js in Javascript, boost::multiprecision in C++

3. Strings.

4. Packed BCDs (binary coded decimals) is a more esoteric method that seemed popular in old software. Read more about it.

In production code for banks (or credit cards, ATMs, POS systems), what data type is actually used the most? I'm especially asking those who worked for banks.

EDIT: Super useful links for those with the same problem domain (needing to implement a "money" data structure that doesn't break).

EDIT for the fellow who said this is a duplicate question: This is a practical not a theoretical question of "what's the best". Read the unedited title of my question. I'm asking what people have seen first-hand in banks' codebases.

I know BigDecimal is "best" obviously, but nice APIs like that aren't available everywhere, believe it or not, and decimal libraries are expensive as opposed to ints.

• Kind of bank related although not specifically for a bank. A few years ago I worked on a system dealing with transactions and payments and we circumvented floatbugs by introducing a completely new datatype, a class, consisting of not only but two 64bit integers, one representing the whole number, the other the decimal part.
– Andy
Feb 14, 2016 at 14:52
• David Packer that is a great idea. I think it might be better than the common implementation, which is a struct of two integers: a big number and the exponent (the value's log_10) Feb 14, 2016 at 15:44
• Question needs a 4th option: BCD Feb 14, 2016 at 15:48
• To answer the question in the title, a COBOL S9(13)V99 COMP-3. Fits in 8 8 bit bytes. Feb 14, 2016 at 16:33
• The problem you have here is "which bank". they use COBOL, Java, C/C++, .NET etc - there's no answer that will fit what you want to know as each of these use different types. You could ask about the backing storage, but even then Oracle decimal types, or a mainframe type would be used depending on the technology used. Feb 15, 2016 at 9:15

Most banks are still on mainframes. Data types on mainframes are very clumsy to today's standards. They may be just the digits encoded as characters. So 1234.56 would really be a string containing those digits. And a character could be 4, 6 or 9 bits. Or, in "optimized" situations, there could be two digits packed in one character. After all, you only need 4 bits (a nibble) for a decimal character.

You would wonder how on earth they ever came op with these solutions. They are often based in the hardware architecture. We are used to multiples of 8-bit architectures. In the old days this was not a given.

Unisys uses 36-bit words and words may be broken up in 6-bit, 9-bit, 12-bit or 18-bit parts before they are used to store data.

Just be glad we won't have to deal with this stuff anymore. The .NET framework has a nice type called decimal which is good for currencies.

• "Most banks are still on mainframes" - is this merely your opinion or you can back it up somehow?
– gnat
Feb 14, 2016 at 16:03
• @gnat: This is a year old and somewhat self-serving; How Do Banks Maintain Financial Data? Mainframes. Feb 14, 2016 at 16:30
• -1 for "Data types on mainframes are very clumsy to today's standards." You obviously know nothing about mainframes. IEEE-754 floats, decimal data, etc. abound. Feb 14, 2016 at 22:40
• @Ross IEEE 754 was established in 1985. A lot of mainframe software is much older. BCD and similar encodings are still very common in active mainframe systems. And they do not compare well against modern encodings. But please, give us the right answer to the question. You obviously know a lot about mainframes. Although your timing seems to be off by a couple of decades... Enlighten us. Feb 14, 2016 at 23:20
• .NET has a nice type called Decimal.. which is really slow and not exactly useful when processing millions of transactions. Thank god we have mainframes with their archaic, but fast, data processing. Feb 15, 2016 at 9:10