... I am going to highlight the one thing that you should NOT do. I am hoping and praying that you are a lucky person and don't get sucked into the awful quagmire that I am about to outline below. ... If you are really, really unlucky, like most of us, you will leave school and 'go do IT for a bank'.
There's quite a bit of truth in much that Cron has written -- indeed, like in pretty much any other corporation that is not concerned with IT as a primary business area, there's little clarity of what and why to do this or that type of IT. Sure, just like in any larger organization, especially entrusted with a rather serious business of keeping other people's savings, technology choices tend to be rather "safe" ones.
Yet on the other side, there is an important aspect to banking that drives a lot of activity in some IT areas that are unlikely to be paid enough attention to in many other businesses.
Take, for instance, security, encryption, digital identity. Banks are the first organizations that have to be looking at that simply due to the nature of their businesses. So, if you're interested in *that* type of IT, and are not very much inclined in 'doing IT' for NSA or FSB (ex-KGB) -- banks are a much more peaceful place of employment that can still allow you doing enough research and technology development.
Or take the 24x7 resilience and uptime/on-line. Sure, you'd have to do the same for the military, medical, NASA. But a bank might be just another good place to try and do the same.
Or maybe mainframes is your thing. Maybe you were always fascinated with wonders of COBOL. Again, banks are the only few enclaves left where you can apply that skill and itch that urge.
So, to put it another way -- it is about what *you want to do*, not about how bad banks' IT is.
That said, there's a lot of mediocrity in banking IT, that is true. Things tend to be done by the book, in a very conservative way. So, if you know that you can't cope with any of that at all -- no, by all means, don't go do IT for the bank.