That is profoundly untrue in my experience (13 years of working as a Dev manager at UBS and BofAML). The knowledge of how the business really works sits largely with the long-served IT and Operations staff. This is certainly the case in the back office (clearing and settlement) and in the regulatory space. I can't speak so much for the front office, but it seemed that the developers with successful careers were those who understood the business and therefore could talk to traders and desk heads in their own language (far more successful than the developers who were actually any good at producing maintainable software, but that's a different rant).

There are lots of things wrong with technology in large banks but the business knowledge of developers is pretty low on the list.

I left banking a few months ago, so I am no apologist for the sector.

As a counter, I've contracted for a bank and big business generally, and they are activly resistent to allowing you to interface with the business in any meaningful way.

There's several reasons for this, but at the end of the day people don't take kindly for your making them redundent and there's a lot of fiefdoms going around.

Why would any developer who wants a deeper look stick around?

I've seen that pattern too, and perhaps I'm a little guilty of it.

But if you say:

> we want to encrypt this field with your public key before sending it to you

and they respond:

> yeah, we can handle that

and then contracts with deadlines and penalties are signed... Wouldn't you expect there to be somebody on the other end that is willing/capable to generate a GPG keypair?

At what point is it worth holding their hand through the technical bits, and at which point would it be better to replace them?