There's a particular look engineers from startups give you when you describe what banks run on. Java. Relational databases. Batch jobs that wake at 2am and grind through files like it's 1999. I used to pre-empt the look with an apology. I've stopped.
What the apology missed: those systems are dull the way a load-bearing wall is dull. The batch job reconciling positions overnight has survived crashes, failovers, three reorganisations, and several attempts to replace it with something more interesting. Its dullness isn't a failure of imagination. It's imagination, slowly sanded off by reality, until only the part that works is left.
I learned this watching a clever system and a boring system handle the same bad day. The clever one — event-driven, beautifully decoupled, a diagram you'd frame — failed in a way that took three teams two days to even describe. The boring one fell over, wrote down exactly where it had fallen, and was rerun before lunch by one person who barely looked up. Cleverness in a system is a debt serviced every time something goes wrong, and things go wrong on the worst available day.
None of this argues against new technology. It argues about where novelty belongs. Spend the innovation budget where it changes what the business can do, and spend ruthlessly boring choices everywhere else. The firms that get in trouble rarely moved too slowly. They made something exciting out of a thing that needed to be a wall.
The startup engineers are right that banks could be faster. But I've made my peace with being the one who asks the boring questions in the room. What happens when this fails at quarter-end. Who reruns it, and how do they know.