Other Functional languages are being used more as well, but since a huge amount of financial software sits on either a .Net or a Java stack, using FP languages which can easily interop with the rest of your libraries makes life a lot easier.
That's more true in certain Enterprisey, conservative parts of the financial world, backoffice bank records and that kind of thing. In investment/quant/trading parts there's more experimentation with other languages, both functional languages like F#, and even particularly "weird" languages like K (an APL successor).
While k is extremely terse, a lot of investment banks these days are using systems which utilise q and it's associated kdb+ database. q is basically a wrapper around k which makes it a lot easier to read and code in and which allows for sql-esque select statements from databases. This combination makes it far more flexible and useful for dealing with financial databases than straight k.
My rule of thumb these days is that the smaller and more obscure the hedge fund, the more likely it is that they're using an unusual set of languages. The more PhDs they have, the more likely they're using something weird like K!
I used K (well, actually the combination of Q and kdb+) in my previous job at an investment bank, and I've used it (to a lesser degree) in my current job at a hedge fund (disclaimer: I have a PhD...).
K/Q is a beautiful language - it's uncompromisingly terse, extremely powerful, and very fast. The interop with kbd+ (a lightning fast, column-oriented, in-memory database) is gorgeous.
It has an unfortunate reputation for obscurity, stemming mainly from the people who think it's fun to write your entire program as a K one-liner and remove all the whitespace. You can write perfectly clear code in Q - super modular, concise, and well documented. It's just that a lot of Q programmers don't bother.
Hardly. They used to be in love with Smalltalk and even Objective C, even before it was cool with Apple and iOS. Also, lots of LISP. The financial world is incredibly hungry for talent and whatever technology can give them an edge over the competition.
The financial world is a big place. There's everything from backend systems at banks to stock exchanges, trading houses, stockbrokers, all with different requirements. I think perhaps the most ancient systems are the backend money ones at banks since there's not much money in scraping speed out of them, but I'd love to hear from someone in the field?
Certainly the enterprise stuff at Spanish banks is run on Cobol, and there's still a fair amount of active Cobol development going on. (By enterprise I mean the bread and butter stuff, accounts etc.)
No idea about the trading / derivatives / whatnot, though.
The core financials may be in COBOL and assembler, but these days most things talking to them will be Java or C#; the middleware will most likely be Java as will many of the front-end apps.
And plenty of banks are migrating away from COBOL on the core systems (slowly), and for them Java is usually the new COBOL, and the JVM is the new s390 microcode.
There is almost certainly a hell of a lot of Fortran and COBOL floating around as well. Most of it is likely at retail banks where things centre around end-of-day processing runs and batch processing.
Other Functional languages are being used more as well, but since a huge amount of financial software sits on either a .Net or a Java stack, using FP languages which can easily interop with the rest of your libraries makes life a lot easier.