I doubt that's the reason - or at least not the main reason. The main reason is legacy: Banks and other financial institutions are among the oldest users of co

I doubt that's the reason - or at least not the main reason. The main reason is legacy: Banks and other financial institutions are among the oldest users of computer systems (I would not hesitate to say that certain banks even utilized Hollerith tabulating systems; they certainly likely used tabulating and other accounting machines made by the early IBM). Code in these institutions likely consists (in a large part) of many lines of COBOL (and possibly other archaic languages - I wouldn't doubt there is some old RPG lurking around). You might ask "well, they could just translate the code or rewrite it" - but it probably isn't that simple. Over time, what we now call "technical debt" built up in a massive way. They fixed and patched and fixed some more, and probably comments don't match the code, and there likely isn't a singular design document or API description anywhere that shows what the system is actually doing (and any that does exist probably doesn't match what is actually happening). Coders came and went, most are probably dead now. But that code is the baseline for how the system works, warts and all. Heck - there's probably code in there that works around bugs in older COBOL compilers or who knows what else. They keep this around - probably emulation on top of emulation - because to refactor all of this would take a super-human level of dedication and effort, and likely introduce new bugs along the way. In fact, there are likely still a ton of "edge case" bugs lurking deep inside that have yet to be found. It may be that fixing these bugs (if found during a refactor, say) might break other working code that depends upon them existing! Even if the refactor were successful, they would still only get to the point of having a system that does everything it currently does (but still may have unknown bugs). You're right that there isn't a financial incentive to fix it. In fact, the opposite is likely, because if fixing it breaks something, in even a subtle way (and that would be worse than anything, because something like a small rounding error might go easily unnoticed until far too late) - it could end up costing the business so much money as to ruin them. I can't really blame them for being so hesitant about such a change. This kind of legacy affects all kinds of businesses and institutions, especially the ones that are quasi-considered "foundational" to society, and hence are likely to be among the oldest users of computer, transaction processing, and accounting systems. A few others I can think of would be accounting firms, logistics (especially railroads - as they were among the first to use Hollerith's systems after the 1890 census), air traffic control (we've already seen this system try to be updated - and fail), airline ticketing (arguably maybe second oldest - how old is SABRE?), insurance... None though - with the exception of the ATC systems - have the same level of repercussions to happen should a new system not perform and act the same as the old system(s) currently in place.