I worked for years on the modernization of a critical banking infrastructure system. The problems are manifold. The biggest problem is overall architectural impedance mismatch - switching from a batch system (most of those old COBOL mainframe apps are batch systems) to a service-oriented architecture. This makes incremental replacement extremely difficult. But a cutover? On a system that moves more money in a day than the GDP of most countries? A failure could put the entire banking world in a tailspin, cause an economic crash.
Next, there's a lot of business logic basically embedded in the COBOL, or even at lower layers. For example, lots of banking files are in EBCDIC, a different character set from ASCII. Except there are lots of different EBCDIC variants, and there's no good way to tell which one you're viewing just by looking at the file. So you have to reverse-engineer COBOL to figure out the "correct" meaning of a given file.
The problems go on and on. When I see people in the startup world rolling their eyes at the "incompetence" of the enterprise world, I take it to mean they've never actually worked on a truly hard problem in their lives.