5 ms·

What has "amount gets subtracted but added again right away after that" have to do that with DB transactions? Basically each Banking transaction is an immutabl

What has "amount gets subtracted but added again right away after that" have to do that with DB transactions? Basically each Banking transaction is an immutable log, which can easily reside in a DB with DB transactions feature. They are not related. Can you please elaborate in technical terms what you mean?

willcipriano 6y ago
Not the OP but I think it's essentially a event driven system as opposed to real time. Think of a account with $0 in it. 1. A -$25 event comes in 2. A +$50 event comes in 3. A -$25 event comes in The first event would fail in a transactional/real time system, but in my bank it doesn't. This tells me the balance is only calculated every once in a while. The balance you get in a app is only a estimate. This makes sense when you think how slow bank transfers and using paper checks is. At some point it is decided to run the events "for real" and that's where overdrafts and the like are applied. Don't think of them as transactions, instead it's a transaction request that can be rejected.
- bouncycastle 6y ago
  Sure, it just means that the processing is done in a batch job at the end of the day. However, it doesn't mean that the batch jobs don't use a database. There's probably something like db2 on the mainframe, possibly even COBOL or RPG
  - sohamsankaran 6y ago
    Yep, it's pretty clear they use IBM db2 on z/OS internally for some applications. Here's an example job posting: https://webcache.googleusercontent.com/search?q=cache:Aqb9oUECiiYJ:https://intellijobs.ai/job/HSBCJava-DB2-Corporate-Functions-IT-vlNi7DLloFfOK915ijrK+&cd=4&hl=en&ct=clnk&gl=in https://webcache.googleusercontent.com/search?q=cache:Aqb9oU...
- kenniskrag 6y ago
  It depends on the country and currency but there is the SWIFT system, which works like messaging. There is also the SIC and EuroSIC. For SWIFT system as a bank you have an account on the other bank and sends an instruction to decrease your amount and book it to a receiver. If there are more than one bank between them it gets routed but always "own decrease and other bank increase". Only the receiver bank books to the client. This system works because every bank has an account on other banks and you can build up some paths.
- lscharen 6y ago
  Related to this — Wells Fargo was sued[1] (and lost) around 2010 for the practice of ordering daily transaction to (indirectly) maximize fees and penalties. In your example, a “good” bank would order the transactions: +$50, -$25, -$25 resulting in a zero balance with no penalties. What Wells Fargo did could result in the transactions being ordered as: -$25 (overdraft), -$25 (overdraft), +$50. Each overdraft could charge a fee up to $35, leaving the account holder with a -$70 balance. [1] https://www.latimes.com/nation/la-fi-court-bank-overdraft-fees-20160404-story.html https://www.latimes.com/nation/la-fi-court-bank-overdraft-fe...
  - alexchamberlain 6y ago
    Seems much simpler only to charge fees at the end of the day...
    - eqvinox 6y ago
      Unfortunately, the optimization goal for commercial entities generally is maximum money extraction, not simplicity :)
- tigershark 6y ago
  How slow bank transfers are? Is 2 seconds really that slow?
  - willcipriano 6y ago
    In the US they clear overnight, as I understand (from a previous hn post I can no longer find) it's a big sftp server and flat files.
    - nobleach 6y ago
      Working in the fintech has opened my eyes to how many shortcomings there really are in banking/ACH. What you describe above is both my nightmare, and my reality. Pipe-delimited flat files being SFTPed via cronjobs overnight. Getting the emails at 5am that balances are off/not reconciled because somehow an errant '|' got into the mix. Additionally, the number of folks that ask for spreadsheets (not encrypted) with your SSN... and then proceed to email that data around (sometimes via Gmail!)
      - deleted 6y ago
        [deleted]
    - tigershark 6y ago
      The article is about HSBC, a British bank, where the transfers happen in a matter of seconds. What is the point of comparing it with US banks?
attilakun 6y ago
I could be wrong but I think the following scenario is worth considering. Let's say a client wants to transact money from bank A to bank B. The following steps are taken: 1. Client initiates the transfer request. 2. Bank A decreases the client's balance. 3. Bank A sends the request to transfer money to bank B. Now, I guess you would expect that steps 2 and 3 should form part of a DB transaction. This however does not really work because it is unclear what conclusion we should draw from step 3 failing. On one hand, it is possible that the request failed on its way to bank B, in which case step 2 should not be applied. On the other hand, it is possible that the request successfully reached bank B but the response got lost on its way back. In this case step 2 should be applied. Therefore, not treating steps 2 and 3 as a single transaction makes sense if you want to take a conservative approach that does not allow for accidental transfer of infinite amounts of money to bank B in scenarios when the response fails to come back from an otherwise successful transfer.
- samus 6y ago
  We have exactly the same problem at work. One possible way to solve it is by ensuring that the receiving system treats the request as idempotent. One could also poll first at the receiver whether the transaction exists, and then send it if it doesn't. But both measures require that there is a way to uniquely identify a request. Also, idempotency can be annoying to implement correctly. Thus, implementors might try to wiggle their way out of it, technically or politically.

willcipriano 6y ago

Not the OP but I think it's essentially a event driven system as opposed to real time. Think of a account with $0 in it. 1. A -$25 event comes in 2. A +$50 event comes in 3. A -$25 event comes in The first event would fail in a transactional/real time system, but in my bank it doesn't. This tells me the balance is only calculated every once in a while. The balance you get in a app is only a estimate. This makes sense when you think how slow bank transfers and using paper checks is. At some point it is decided to run the events "for real" and that's where overdrafts and the like are applied. Don't think of them as transactions, instead it's a transaction request that can be rejected.

bouncycastle 6y ago
Sure, it just means that the processing is done in a batch job at the end of the day. However, it doesn't mean that the batch jobs don't use a database. There's probably something like db2 on the mainframe, possibly even COBOL or RPG
- sohamsankaran 6y ago
  Yep, it's pretty clear they use IBM db2 on z/OS internally for some applications. Here's an example job posting: https://webcache.googleusercontent.com/search?q=cache:Aqb9oUECiiYJ:https://intellijobs.ai/job/HSBCJava-DB2-Corporate-Functions-IT-vlNi7DLloFfOK915ijrK+&cd=4&hl=en&ct=clnk&gl=in https://webcache.googleusercontent.com/search?q=cache:Aqb9oU...
kenniskrag 6y ago
It depends on the country and currency but there is the SWIFT system, which works like messaging. There is also the SIC and EuroSIC. For SWIFT system as a bank you have an account on the other bank and sends an instruction to decrease your amount and book it to a receiver. If there are more than one bank between them it gets routed but always "own decrease and other bank increase". Only the receiver bank books to the client. This system works because every bank has an account on other banks and you can build up some paths.
lscharen 6y ago
Related to this — Wells Fargo was sued[1] (and lost) around 2010 for the practice of ordering daily transaction to (indirectly) maximize fees and penalties. In your example, a “good” bank would order the transactions: +$50, -$25, -$25 resulting in a zero balance with no penalties. What Wells Fargo did could result in the transactions being ordered as: -$25 (overdraft), -$25 (overdraft), +$50. Each overdraft could charge a fee up to $35, leaving the account holder with a -$70 balance. [1] https://www.latimes.com/nation/la-fi-court-bank-overdraft-fees-20160404-story.html https://www.latimes.com/nation/la-fi-court-bank-overdraft-fe...
- alexchamberlain 6y ago
  Seems much simpler only to charge fees at the end of the day...
  - eqvinox 6y ago
    Unfortunately, the optimization goal for commercial entities generally is maximum money extraction, not simplicity :)
tigershark 6y ago
How slow bank transfers are? Is 2 seconds really that slow?
- willcipriano 6y ago
  In the US they clear overnight, as I understand (from a previous hn post I can no longer find) it's a big sftp server and flat files.
  - nobleach 6y ago
    Working in the fintech has opened my eyes to how many shortcomings there really are in banking/ACH. What you describe above is both my nightmare, and my reality. Pipe-delimited flat files being SFTPed via cronjobs overnight. Getting the emails at 5am that balances are off/not reconciled because somehow an errant '|' got into the mix. Additionally, the number of folks that ask for spreadsheets (not encrypted) with your SSN... and then proceed to email that data around (sometimes via Gmail!)
    - deleted 6y ago
      [deleted]
  - tigershark 6y ago
    The article is about HSBC, a British bank, where the transfers happen in a matter of seconds. What is the point of comparing it with US banks?

attilakun 6y ago

I could be wrong but I think the following scenario is worth considering. Let's say a client wants to transact money from bank A to bank B. The following steps are taken: 1. Client initiates the transfer request. 2. Bank A decreases the client's balance. 3. Bank A sends the request to transfer money to bank B. Now, I guess you would expect that steps 2 and 3 should form part of a DB transaction. This however does not really work because it is unclear what conclusion we should draw from step 3 failing. On one hand, it is possible that the request failed on its way to bank B, in which case step 2 should not be applied. On the other hand, it is possible that the request successfully reached bank B but the response got lost on its way back. In this case step 2 should be applied. Therefore, not treating steps 2 and 3 as a single transaction makes sense if you want to take a conservative approach that does not allow for accidental transfer of infinite amounts of money to bank B in scenarios when the response fails to come back from an otherwise successful transfer.

samus 6y ago
We have exactly the same problem at work. One possible way to solve it is by ensuring that the receiving system treats the request as idempotent. One could also poll first at the receiver whether the transaction exists, and then send it if it doesn't. But both measures require that there is a way to uniquely identify a request. Also, idempotency can be annoying to implement correctly. Thus, implementors might try to wiggle their way out of it, technically or politically.