>>9
Not the poster you're replying to, but here's my 0.02€...
Side-effectless operations are far easier to re-use than ones that do have side effects. They are also somewhat easier to validate, test and prove correct than their side-effectful counterparts, given that their scope is limited to their definition and the definitions of their leaves instead of that and the state of the system as in an imperative language. This latter bit I suppose would be plenty important to a financial organization, but see the cons at the bottom of this reply...
Components of a program written in a functional language are also easier to reason about, given that the nature of a function (is it a simple function? a map? a fold? an unfold? an accumulating map? etc) is generally apparent right away, just from its documentation and type signature. They also tend to be virtually busywork- and housekeeping-free due to memory management being implicit, in contrast to e.g. Java or C where a major operation generally consists of "1. acquire resources; 2. perform operations; 3. release resources".
Really, the only cons I can think of for functional programming is that first, it's mostly unsuitable for system-level programming (not much of a big deal since the gigahertz line was broken) and second, that J. Random Code Monkeys aren't educated in it. Used to be that universities and even some colleges had a mandatory Scheme course for CS/SE people, but these days it's all Java and anything else is optional, even C is optional these days. One could make the argument that Java programmers aren't that suited for financial-type things either, given that most aren't taught (or don't remember) the reason why using "double" instead of "float" is _not_ good enough for doing computations on money, but they're the people who are available. For better or worse, I suppose.