Core Banking Parser

If you look at the raw output of a core banking system or legacy mainframe, you won't see nicely formatted JSON or XML. You'll likely see a massive block of text where every character's position has a specific meaning. This is often based on or inspired by ISO-8583, the international standard for financial transaction messaging.

Legacy mainframes written in COBOL were built in an era where memory was incredibly expensive. To save space, they didn't use variable names like "account_number": "12345". The system simply knows that characters 1 through 16 are the account number, characters 17 through 28 are the balance, and so on.

Modern variations of these fixed-width schemas use a "bitmap" (a string of 1s and 0s) at the start of the message.

If the 3rd bit of the bitmap is a 1, it means "Data Element 3 (Processing Code) is present in this message". If it's a 0, the parser knows to skip it and immediately look for the next data element. This creates a highly compressed, dynamic message structure.

Many core banking systems process thousands of transactions per second. JSON parsing is extremely CPU intensive compared to reading fixed-width strings from memory offsets.

Furthermore, rewriting the core ledger logic of a bank (which has run flawlessly for 40 years) introduces massive, unacceptable risk just for the sake of modernizing a data format. Thus, these formats persist today.