3 ms·

My very very naive take on this: why don't banks have more common operating systems and data structures? Why is it this hard for acquisitions to work? They're a

My very very naive take on this: why don't banks have more common operating systems and data structures? Why is it this hard for acquisitions to work? They're a guaranteed part of business so a common software stack could help Chase integrate First Republic without two parallel systems? (I welcome any responses on why this will never happen though!)

patio11 3y ago
There is a famous joke about standards: the great thing about common standards is that you have so many to choose from. A corollary to it: if none of the existing common standards meets your need, how about letting some of your senior staff get promoted by successfully creating and popularizing a new common standard?
mrkeen 3y ago
Every problem you solve takes time away from solving other problems, and this one is a particularly difficult coordination problem with very little payoff. You might be imagining two banks coordinating together, now scrap that and imagine ALL banks coordinating, because you don't know which two are going to merge. Banks have been born at different times (think centuries - or even millenia). So they'd all have to move in lockstep from clay tablets to papyrus to printing press to typewriter before they even decide whether or not they want to bet on computers as a way forward. To some degree banks already have 'a shared operating system' in the form of clearing houses and central banks. I don't know enough about that stuff. But it's the reason why bank transfers have mostly taken days to complete, rather than seconds, in the past few decades. Come to think of it, there's a huge incentive not to stay in lockstep with all the other banks if you can offer customers instantaneous transfers when other banks make you wait for days.
- nvm0n2 3y ago
  Bank transfers take days to complete because of liquidity management, not due to IT system delays. When you do a big enough transfer, the bank has to have a balance with the central bank that can be moved to the target bank's CB account, but, your bank doesn't actually have the money you deposited. It's out on loan instead. So the bank has to go into the market and sell some assets to raise that money. It may not be possible to do this immediately, and even if it is, they want to be able to time their sales to reduce capital inefficiencies. This is also why they're often so very expensive. That $25 or whatever isn't being spent on the cost of updating the ledger. It's the cost the bank incurs because of the need to sell assets (loans) before they intended to.
  - mrkeen 3y ago
    That's not a sufficient explanation for non-instantaneous transfers of $50.
    - nvm0n2 3y ago
      It is, because in some older payment systems all payments go via the same "rails" as they call it. Specifically, the reason that payments are still tied to the nightly cycle is because orders submitted to the central bank aren't executed immediately. At night they suspend submission of new orders and do something called netout or payment compression on the transfer graph, the goal of which is to reduce the amount of money banks need to hold at the central bank. Every payment no matter how small can contribute to the netout, reducing liquidity needs at the CB.
CamouflagedKiwi 3y ago
Why don't software companies have more common operating systems and data structures? Why is it hard for acquisitions of software companies to work? They are a common part of business in that industry too.
deleted 3y ago
[deleted]
cowthulhu 3y ago
My two cents from the perspective of smaller financial institutions - cores do not care about making it easier for you to move off of them. They probably wouldn’t mind making it easier to move on, but core conversions are such a nightmare that they have dedicated onboarding teams for this with lots of tooling and knowledge, and since everyone else’s data structures are different, there’s no point standardizing your own. Additionally, there are, like, three big players in the space (at our level, at least). When you’re choosing a core, you’re probably going to be more concerned by questions such as “what percentage of our total revenue will go to this one application” and “what features can we use to save us tons of work and money” and “will this make us more money”. You probably won’t be too concerned with whether converting off the core fifteen years down the line is super difficult or “just” pretty difficult. If you do ask, all three will give you the same answer anyways.
Kalium 3y ago
Pick any two small businesses in the same niche. Grow them for three or four decades. How identical do you think their evolved business practices will be? My very very naive take is that they will have had to solve similar problems over time and will have practices and systems that work analogously. I would bet they will probably not use identical software packages or data structures and will have had little reason to structure their internal operations around someone else's standards. This is especially likely to be true of standards that came along well after the companies already solved the problems the standards are aimed at.

patio11 3y ago

There is a famous joke about standards: the great thing about common standards is that you have so many to choose from. A corollary to it: if none of the existing common standards meets your need, how about letting some of your senior staff get promoted by successfully creating and popularizing a new common standard?

mrkeen 3y ago

Every problem you solve takes time away from solving other problems, and this one is a particularly difficult coordination problem with very little payoff. You might be imagining two banks coordinating together, now scrap that and imagine ALL banks coordinating, because you don't know which two are going to merge. Banks have been born at different times (think centuries - or even millenia). So they'd all have to move in lockstep from clay tablets to papyrus to printing press to typewriter before they even decide whether or not they want to bet on computers as a way forward. To some degree banks already have 'a shared operating system' in the form of clearing houses and central banks. I don't know enough about that stuff. But it's the reason why bank transfers have mostly taken days to complete, rather than seconds, in the past few decades. Come to think of it, there's a huge incentive not to stay in lockstep with all the other banks if you can offer customers instantaneous transfers when other banks make you wait for days.

nvm0n2 3y ago
Bank transfers take days to complete because of liquidity management, not due to IT system delays. When you do a big enough transfer, the bank has to have a balance with the central bank that can be moved to the target bank's CB account, but, your bank doesn't actually have the money you deposited. It's out on loan instead. So the bank has to go into the market and sell some assets to raise that money. It may not be possible to do this immediately, and even if it is, they want to be able to time their sales to reduce capital inefficiencies. This is also why they're often so very expensive. That $25 or whatever isn't being spent on the cost of updating the ledger. It's the cost the bank incurs because of the need to sell assets (loans) before they intended to.
- mrkeen 3y ago
  That's not a sufficient explanation for non-instantaneous transfers of $50.
  - nvm0n2 3y ago
    It is, because in some older payment systems all payments go via the same "rails" as they call it. Specifically, the reason that payments are still tied to the nightly cycle is because orders submitted to the central bank aren't executed immediately. At night they suspend submission of new orders and do something called netout or payment compression on the transfer graph, the goal of which is to reduce the amount of money banks need to hold at the central bank. Every payment no matter how small can contribute to the netout, reducing liquidity needs at the CB.

CamouflagedKiwi 3y ago

Why don't software companies have more common operating systems and data structures? Why is it hard for acquisitions of software companies to work? They are a common part of business in that industry too.

deleted 3y ago

[deleted]

cowthulhu 3y ago

My two cents from the perspective of smaller financial institutions - cores do not care about making it easier for you to move off of them. They probably wouldn’t mind making it easier to move on, but core conversions are such a nightmare that they have dedicated onboarding teams for this with lots of tooling and knowledge, and since everyone else’s data structures are different, there’s no point standardizing your own. Additionally, there are, like, three big players in the space (at our level, at least). When you’re choosing a core, you’re probably going to be more concerned by questions such as “what percentage of our total revenue will go to this one application” and “what features can we use to save us tons of work and money” and “will this make us more money”. You probably won’t be too concerned with whether converting off the core fifteen years down the line is super difficult or “just” pretty difficult. If you do ask, all three will give you the same answer anyways.

Kalium 3y ago

Pick any two small businesses in the same niche. Grow them for three or four decades. How identical do you think their evolved business practices will be? My very very naive take is that they will have had to solve similar problems over time and will have practices and systems that work analogously. I would bet they will probably not use identical software packages or data structures and will have had little reason to structure their internal operations around someone else's standards. This is especially likely to be true of standards that came along well after the companies already solved the problems the standards are aimed at.