5 ms·

As discussed in the OP, this is cheque kiting:" https://en.wikipedia.org/wiki/Check_kiting https://en.wikipedia.org/wiki/Check_kiting It is a scheme that goes

As discussed in the OP, this is cheque kiting:" https://en.wikipedia.org/wiki/Check_kiting https://en.wikipedia.org/wiki/Check_kiting It is a scheme that goes back literally centuries in commerce. I'm amazed that I can hit send on an iMessage now and within seconds (or fractions of a second!) somebody's phone gives out a "ping!," anywhere in the world, yet cheque kiting hasn't been eliminated in 2019. --- (I am speaking rhetorically. Yes, I understand about legacy systems and legacy processes. I'm not surprised that it works with what we have running today, I'm surprised that it hasn't been fixed in the 40-odd years that I've been old enough to have a bank account.)

r00fus 7y ago
Perhaps the reason it's not "solved" has to do with who benefits from the latency of check cashing process?
- throwwsydj 7y ago
  What do you have in mind? Who might benefit?
nickjj 7y ago
My naive explanation is it must be really really really scary to modify a banking routine that affects an entire country's currency or even most of the world in some way or another. If your iMessage doesn't get sync'd 1 out of 10,000,000 times because of some software bug then there's really no harm but if your balance isn't correct because of a bug in the software, that's a whole different category level of concern that has cascading negative effects.
- braythwayt 7y ago
  Risk is always an interesting thing to consider in software, especially with complex systems. Let's say there are two bugs in our banking code. Bug A means that every once in a while, it fails and a user can't log in. Bug B means that the system always works, but every once in a while, it shows an incorrect balance on an account. Hmmm... Which one is worse? Well, that depends. Obviously B is very bad in some very obvious ways. But A could be catastrophic if one of the system's uses is doing something like making payroll for hundreds or thousands of people. Hmmm...
  - vinniejames 7y ago
    Sure it's something to consider. But what's worse...a system that may have minor bugs while upgrading; or one that lets low level criminals easily swindle the system for millions on an everyday basis?
    - braythwayt 7y ago
      You’re right, we can’t let low-level criminals swindle the system, we need that money for the really elite criminals running our multi-year system modernization IT projects. /ducks!
    - perl4ever 7y ago
      Well, there's always been a huge difference between predictable small losses, and unpredictable ones with no limit. Variance matters a lot. Millions are negligible if you're processing trillions and the losses are shared by everyone.
- lostgame 7y ago
  I work as a senior iOS dev at a major bank here in Canada, and I can say this is by far the most likely scenario. First off, killing cheques would have to be a Universal - global - and immediate, thing. For as long as the technology is still in use (everywhere) - even for obscure purposes - it will remain supported and thusly these issues will remain. Nobody in the bank industry is stupid enough to self-sabatoge by not accepting or pressing cheques, because when your landlord wants a stack of post-dated cheques (still) - you’re going to be flying to the next bank. Updating a new system, yes, we’re careful, as all hell, but we push iOS updates consistently. Destroying an old one that is still in place by unfortunate necessity? We can’t do that yet. Doesn’t matter how insecure it is. We just focus on making the apps and web and the new technology that we have a lot more control over as secure as possible.
  - namibj 7y ago
    My bank makes it prohibitively expensive to cash/write checks. I think even SWIFT wires are cheaper, and those are _expensive_. SEPA wires are free though.
zelon88 7y ago
Because nobody profits off the time/value of money nearly as much as the banks do. If transactions were "instant" the bank wouldn't be able to kite your money. There really is no reason transactions need to take as long as they do other than that money disappears from one account and re-appears two days later in another account. In the meantime those funds are still a part of the bank's bottom line. It's not technically yours, and it's not technically the other account holders.... but the bank still possesses it. And the amount of money the bank has "floating" around probably coincidentally lines up pretty closely with a sum of money the bank has invested in high-risk investments. Banks are essentially legal "Kiting centers" where they get to kite everyone elses money because it's federally insured anyway.
- jdm2212 7y ago
  That's a pretty wild claim. Do you have any sources to support it?
  - rrauenza 7y ago
    How about this article from 1985(!): https://www.nytimes.com/1985/05/27/business/squeezing-profits-from-float.html https://www.nytimes.com/1985/05/27/business/squeezing-profit...
  - lostgame 7y ago
    I work at a major bank in Canada and can confirm this is the case. There is - confirmed here by a dev - at least in our instance, absolutely no technical reason why transactions can not happen immediately. It is an intentionally-staggered process for bureaucratic purposes, certainly.
- vanderZwan 7y ago
  > There really is no reason transactions need to take as long as they do other than that money disappears from one account and re-appears two days later in another account. Well, that and legacy systems that run batch jobs in COBOL at midnight to do the bank-to-bank transfers: > Roughly 80% of their systems are batch jobs. These are jobs that runs at a certain time or interval, doing some processing on their data or sends data to other banks/agencies/etc. For example when I buy a can of Coke, the money is withdrawn from my account balance, however the money is not actually transferred anywhere until one of their batch jobs does so. These jobs are usually executed during the night, which is usually why it takes a day before transactions between banks are completed. Transactions to the same bank are usually instant because it executes immediately. https://hackerfall.com/story/interviewing-my-mother-a-mainframe-cobol-programme https://hackerfall.com/story/interviewing-my-mother-a-mainfr... Also, that interview convinced me that the busfactor of the entire Swedish economy is a handful of old Cobol programmers.
iamsb 7y ago
It is incredible how much banking system still runs on COBOL and nightly ETL processes running on mainframes!
- shadowgovt 7y ago
  Not really. Once the software works, there is no reason to change it (and cost incentives not to).
  - toomuchtodo 7y ago
    Indeed. Cheaper to keep COBOL folks on staff and the mainframe running than to rewrite it (millions vs tens or hundreds of millions of dollars in costs).
    - iamsb 7y ago
      Honestly, that is not true. As someone who had to interface with these systems, the cumulative cost of keeping them running is far greater. There are number of layers which run of top of them to support modern age use cases. The problem is no CEO/CTO at big banks who wants to keep their job is going to pull the trigger and transform it, as most likely that project will run over budget and is risky.
      - Retric 7y ago
        You also need to pay to keep the new system running. That’s the real ‘hidden’ cost that you need to be aware of. COBAL may not be sexy, but it’s stable in ways most new systems can’t hope to match.
      - walshemj 7y ago
        The experience in the UK of the TSB porting to some Java system written by Santander is a good lesson of why this is risky
      - perl4ever 7y ago
        You seem to be implying risk is not a cost.
coliveira 7y ago
One of the many reasons is that you don't want to see your money withdraw from an account on error, without a reasonable way to stop the process. That's why account owners are not interested in a system that immediately draws the money without recourse. The price to pay on potential abuse of the current system seems to be a small inconvenience.
hetspookjee 7y ago
Ha, this makes me think of PingFS [1] where the data is in the latency of the network, whereas here the money is in the latency of the banks. 1 https://github.com/yarrick/pingfs https://github.com/yarrick/pingfs
DesaiAshu 7y ago
Checks are, quite literally the least secure mode of non cash transacting. Yet the banking system is built in a way that checks are often either the fastest way to get someone money, or the only way certain merchants accept payment. This technology should have been sun-setted years ago, and wire transfers should be free and instant.

r00fus 7y ago

Perhaps the reason it's not "solved" has to do with who benefits from the latency of check cashing process?

throwwsydj 7y ago
What do you have in mind? Who might benefit?

nickjj 7y ago

My naive explanation is it must be really really really scary to modify a banking routine that affects an entire country's currency or even most of the world in some way or another. If your iMessage doesn't get sync'd 1 out of 10,000,000 times because of some software bug then there's really no harm but if your balance isn't correct because of a bug in the software, that's a whole different category level of concern that has cascading negative effects.

braythwayt 7y ago
Risk is always an interesting thing to consider in software, especially with complex systems. Let's say there are two bugs in our banking code. Bug A means that every once in a while, it fails and a user can't log in. Bug B means that the system always works, but every once in a while, it shows an incorrect balance on an account. Hmmm... Which one is worse? Well, that depends. Obviously B is very bad in some very obvious ways. But A could be catastrophic if one of the system's uses is doing something like making payroll for hundreds or thousands of people. Hmmm...
- vinniejames 7y ago
  Sure it's something to consider. But what's worse...a system that may have minor bugs while upgrading; or one that lets low level criminals easily swindle the system for millions on an everyday basis?
  - braythwayt 7y ago
    You’re right, we can’t let low-level criminals swindle the system, we need that money for the really elite criminals running our multi-year system modernization IT projects. /ducks!
  - perl4ever 7y ago
    Well, there's always been a huge difference between predictable small losses, and unpredictable ones with no limit. Variance matters a lot. Millions are negligible if you're processing trillions and the losses are shared by everyone.
lostgame 7y ago
I work as a senior iOS dev at a major bank here in Canada, and I can say this is by far the most likely scenario. First off, killing cheques would have to be a Universal - global - and immediate, thing. For as long as the technology is still in use (everywhere) - even for obscure purposes - it will remain supported and thusly these issues will remain. Nobody in the bank industry is stupid enough to self-sabatoge by not accepting or pressing cheques, because when your landlord wants a stack of post-dated cheques (still) - you’re going to be flying to the next bank. Updating a new system, yes, we’re careful, as all hell, but we push iOS updates consistently. Destroying an old one that is still in place by unfortunate necessity? We can’t do that yet. Doesn’t matter how insecure it is. We just focus on making the apps and web and the new technology that we have a lot more control over as secure as possible.
- namibj 7y ago
  My bank makes it prohibitively expensive to cash/write checks. I think even SWIFT wires are cheaper, and those are _expensive_. SEPA wires are free though.

zelon88 7y ago

Because nobody profits off the time/value of money nearly as much as the banks do. If transactions were "instant" the bank wouldn't be able to kite your money. There really is no reason transactions need to take as long as they do other than that money disappears from one account and re-appears two days later in another account. In the meantime those funds are still a part of the bank's bottom line. It's not technically yours, and it's not technically the other account holders.... but the bank still possesses it. And the amount of money the bank has "floating" around probably coincidentally lines up pretty closely with a sum of money the bank has invested in high-risk investments. Banks are essentially legal "Kiting centers" where they get to kite everyone elses money because it's federally insured anyway.

jdm2212 7y ago
That's a pretty wild claim. Do you have any sources to support it?
- rrauenza 7y ago
  How about this article from 1985(!): https://www.nytimes.com/1985/05/27/business/squeezing-profits-from-float.html https://www.nytimes.com/1985/05/27/business/squeezing-profit...
- lostgame 7y ago
  I work at a major bank in Canada and can confirm this is the case. There is - confirmed here by a dev - at least in our instance, absolutely no technical reason why transactions can not happen immediately. It is an intentionally-staggered process for bureaucratic purposes, certainly.
vanderZwan 7y ago
> There really is no reason transactions need to take as long as they do other than that money disappears from one account and re-appears two days later in another account. Well, that and legacy systems that run batch jobs in COBOL at midnight to do the bank-to-bank transfers: > Roughly 80% of their systems are batch jobs. These are jobs that runs at a certain time or interval, doing some processing on their data or sends data to other banks/agencies/etc. For example when I buy a can of Coke, the money is withdrawn from my account balance, however the money is not actually transferred anywhere until one of their batch jobs does so. These jobs are usually executed during the night, which is usually why it takes a day before transactions between banks are completed. Transactions to the same bank are usually instant because it executes immediately. https://hackerfall.com/story/interviewing-my-mother-a-mainframe-cobol-programme https://hackerfall.com/story/interviewing-my-mother-a-mainfr... Also, that interview convinced me that the busfactor of the entire Swedish economy is a handful of old Cobol programmers.

iamsb 7y ago

It is incredible how much banking system still runs on COBOL and nightly ETL processes running on mainframes!

shadowgovt 7y ago
Not really. Once the software works, there is no reason to change it (and cost incentives not to).
- toomuchtodo 7y ago
  Indeed. Cheaper to keep COBOL folks on staff and the mainframe running than to rewrite it (millions vs tens or hundreds of millions of dollars in costs).
  - iamsb 7y ago
    Honestly, that is not true. As someone who had to interface with these systems, the cumulative cost of keeping them running is far greater. There are number of layers which run of top of them to support modern age use cases. The problem is no CEO/CTO at big banks who wants to keep their job is going to pull the trigger and transform it, as most likely that project will run over budget and is risky.
    - Retric 7y ago
      You also need to pay to keep the new system running. That’s the real ‘hidden’ cost that you need to be aware of. COBAL may not be sexy, but it’s stable in ways most new systems can’t hope to match.
    - walshemj 7y ago
      The experience in the UK of the TSB porting to some Java system written by Santander is a good lesson of why this is risky
    - perl4ever 7y ago
      You seem to be implying risk is not a cost.

coliveira 7y ago

One of the many reasons is that you don't want to see your money withdraw from an account on error, without a reasonable way to stop the process. That's why account owners are not interested in a system that immediately draws the money without recourse. The price to pay on potential abuse of the current system seems to be a small inconvenience.

hetspookjee 7y ago

Ha, this makes me think of PingFS [1] where the data is in the latency of the network, whereas here the money is in the latency of the banks. 1 https://github.com/yarrick/pingfs https://github.com/yarrick/pingfs

DesaiAshu 7y ago

Checks are, quite literally the least secure mode of non cash transacting. Yet the banking system is built in a way that checks are often either the fastest way to get someone money, or the only way certain merchants accept payment. This technology should have been sun-setted years ago, and wire transfers should be free and instant.