SEPA: speed versus efficiency

In front-office operations, most people would probably think that speed and efficiency go together.  They work with high-speed automated trading, low-latency computing and networks – maximum efficiency at maximum speed.  Somehow they can take an order from a client’s system, process it through their own different system, send it to an exchange that has yet another different system, and make it all happen efficiently and in seconds.

Things work fast when people make more money by making them work fast.  Things work slowly when people make more money by making them work slowly.

Retail securities settlement works slowly in the UK (eg T+14 - as mentioned in a previous blog) because somebody is making money out of the difference between wholesale T+3 and retail T+14 settlement.  Payments work slowly (and particularly international payments) because somebody is making money out of keeping payments working slowly.

One argument by banks in favour of such slowness is that this extra money that they earn in fact helps to cover their cost of having to run all those piddling retail bank accounts at no cost to the customer.  If they had to do things faster, they would have to start passing more costs on to customers.

As Chris Skinner points out in his blog today, in a lot of European countries banks do charge for running bank accounts.  Unfortunately it does cost, but at least you know what the cost is.  Most of us don’t know what the opportunity cost is of letting the banks use our money for a few days or a couple of weeks without passing the benefit on to us.

Do we want a transparent market, where we can see what service we are really getting and how much we are really paying for it?  SEPA raises this issue in the same way that MiFID does.