5 ms·

I've asked bankers at the branch about this before and received a vague answer about how they need time to verify things, but I strongly suspect they were just

by jrcii 11y ago

I've asked bankers at the branch about this before and received a vague answer about how they need time to verify things, but I strongly suspect they were just non-technical and didn't know.

pc86 11y ago
Is part of the problem inertia? What I mean is if there are multiple pending transactions on an account, is it even possible from a technical perspective to say "Is there $100 available in this account for immediate withdrawal?" I would suspect it is possible, but I also wouldn't expect the majority of US banking infrastructure to run on AS400s.
- icebraining 11y ago
  Isn't that the available balance? At least here in Portugal, we have three balances: accounting (based on all non-pending transactions), authorized (accounting plus all pending transactions) and available (like authorized, but just with the pending debits). The latter is the amount actually "yours", which you can use without paying interest on.
  - pc86 11y ago
    Yes but particularly for restaurants where us Americans will tip 99% of the time, the "pending" amount is often different from the finalized amount. You won't usually see that until the item actually posts, which could be several days.
ChuckMcM 11y ago
I don't know how current it is but back in the 90's when I was dealing with technical issues with payments at UBS (UBS was a big Sun purchaser) one of their bankers described bank transfers as a giant exercise in "liability hot potato". Which is to say that at each step of the way the person receiving the funds was trying to avoid becoming liable for them until they were really certain they had them in an account somewhere, and people sending funds wanted to be absolutely sure the destination had accepted liability for the funds before they were willing to release them. Because when it went wrong, they ended up liable for funds they no longer had. And he suggested that there were people that tried to make that true (basically stealing from the system) and that it happened enough to be priced into the transaction fees. The amount of money that was flowing on a daily business through the bank was staggering.
- jrcii 11y ago
  Given the crowd on HN I'm surprised there isn't at least one person chiming in that works on these backend bank systems.
  - tolle 11y ago
    A wild guess would be that roughly 90% of all systems handling this are written in COBOL running on z/OS or IBM i. And that most of the developers are currently close to 60, spending their free time with their grandchildren and not on Hacker News. I'm not much help either since I work with mortgages, and having it all explained during a lunch break might be a bit much. There are also, depending on company and country, rules and laws about what you can talk about.
    - zhte415 11y ago
      There are still a lot of developers for these systems. Updates happen constantly and developers are constantly in need and training-up. For example, credit card legal and security compliance updates happen a lot with really strict deadlines that have to be adhered to, or else the credit card issuer gets into hot water. Some organisations choose to merge old features that differ by country get merged in a central trunk with flagable switches. The code bases are very active. My company (not going to say the name here) employ 500+ mainframe engineers, some working on new projects and codebases because mainframe is the preferred platform. If you or anyone else would like to get in contact regarding COBOL or Mainframe in general, especially getting work done, especially in finance, please find my email in my profile.
      - jrcii 11y ago
        > There are still a lot of developers for these systems. I hear Initech is hiring.
  - PeterisP 11y ago
    I've worked on those systems and there's not much more to say, the hot potato analogy is pretty much a perfect description.
PeterisP 11y ago
The "need to verify" is not a technical need and can't be solved with technical means - it's all about counterparty risk, it is a business need to verify so that you're not vulnerable to all kinds of exploits and fluctuations. It is trivial to have the payment messages happen in near-real time. However, to actually make a final credit in the receiving account and allow the end user free access to withdraw that money, you need one of three things: 1) the receiving institution simply trusts that they'll receive the money and releases the money as soon as they can - which is not realistic due to counterparty risk, fraud/revocation risk, etc and can happen only either if the whole payment happens in a single central system/institution (e.g. something like paypal) or the system includes very high fees to cover those risks. 2) each sending institution has a large binding collateral and there are appropriate safeguards that in the case of someone "going bad" the receivers are going to get paid anyway - which requires a strong central system to manage it, and the institutions deffering a lot of power and money to it (in this context, a million doesn't come close to a lot of money). This is the system described in the original article - the payment gets credited/finished first, and covered/settled between the banks afterwards. 3) in the absence of strong guarantees or blind trust, everyone in a payment chain pays the money forward only after they have been actually paid to cover the payment, adding days and days to the processing time. This is the current US system and also how general arbitrary international payments can be settled - particularly in international payments, you can get the full payment data nearly immediately, but you generally wouldn't receive the funds until every institution involved has covered their risks.
- pbhjpbhj 11y ago
  >It is trivial to have the payment messages happen in near-real time. [...] receiving institution simply trusts that they'll receive the money and releases the money as soon as they can // Surely the message is "the money", it's not like a truck pulls up at the bank each night with the transaction balance for the day? I don't see how there's a risk if there's a transactional process: for example Bank A sends request for money from B (eg to fulfill a payment by debit card); B reserves the money and sends a verified payment (crypto signed and what-have-you); A processes the payment and increments the relevant account with reserved funds and sends a receipt to B; B processes the receipt completes the decrease on the relevant account using the previously reserved fund and acknowledges the receipt; A receives the acknowledgement and verifies the funds as available in the account. So, if B doesn't have funds to reserve then the payment can't be processed and A won't acknowledge any receipts claiming the transfer of monies. "A" thus won't increase a balance for any accounts. Where's the risk?

by jrcii 11y ago

I've asked bankers at the branch about this before and received a vague answer about how they need time to verify things, but I strongly suspect they were just non-technical and didn't know.

pc86 11y ago

Is part of the problem inertia? What I mean is if there are multiple pending transactions on an account, is it even possible from a technical perspective to say "Is there $100 available in this account for immediate withdrawal?" I would suspect it is possible, but I also wouldn't expect the majority of US banking infrastructure to run on AS400s.

icebraining 11y ago
Isn't that the available balance? At least here in Portugal, we have three balances: accounting (based on all non-pending transactions), authorized (accounting plus all pending transactions) and available (like authorized, but just with the pending debits). The latter is the amount actually "yours", which you can use without paying interest on.
- pc86 11y ago
  Yes but particularly for restaurants where us Americans will tip 99% of the time, the "pending" amount is often different from the finalized amount. You won't usually see that until the item actually posts, which could be several days.

ChuckMcM 11y ago

I don't know how current it is but back in the 90's when I was dealing with technical issues with payments at UBS (UBS was a big Sun purchaser) one of their bankers described bank transfers as a giant exercise in "liability hot potato". Which is to say that at each step of the way the person receiving the funds was trying to avoid becoming liable for them until they were really certain they had them in an account somewhere, and people sending funds wanted to be absolutely sure the destination had accepted liability for the funds before they were willing to release them. Because when it went wrong, they ended up liable for funds they no longer had. And he suggested that there were people that tried to make that true (basically stealing from the system) and that it happened enough to be priced into the transaction fees. The amount of money that was flowing on a daily business through the bank was staggering.

jrcii 11y ago
Given the crowd on HN I'm surprised there isn't at least one person chiming in that works on these backend bank systems.
- tolle 11y ago
  A wild guess would be that roughly 90% of all systems handling this are written in COBOL running on z/OS or IBM i. And that most of the developers are currently close to 60, spending their free time with their grandchildren and not on Hacker News. I'm not much help either since I work with mortgages, and having it all explained during a lunch break might be a bit much. There are also, depending on company and country, rules and laws about what you can talk about.
  - zhte415 11y ago
    There are still a lot of developers for these systems. Updates happen constantly and developers are constantly in need and training-up. For example, credit card legal and security compliance updates happen a lot with really strict deadlines that have to be adhered to, or else the credit card issuer gets into hot water. Some organisations choose to merge old features that differ by country get merged in a central trunk with flagable switches. The code bases are very active. My company (not going to say the name here) employ 500+ mainframe engineers, some working on new projects and codebases because mainframe is the preferred platform. If you or anyone else would like to get in contact regarding COBOL or Mainframe in general, especially getting work done, especially in finance, please find my email in my profile.
    - jrcii 11y ago
      > There are still a lot of developers for these systems. I hear Initech is hiring.
- PeterisP 11y ago
  I've worked on those systems and there's not much more to say, the hot potato analogy is pretty much a perfect description.

PeterisP 11y ago

The "need to verify" is not a technical need and can't be solved with technical means - it's all about counterparty risk, it is a business need to verify so that you're not vulnerable to all kinds of exploits and fluctuations. It is trivial to have the payment messages happen in near-real time. However, to actually make a final credit in the receiving account and allow the end user free access to withdraw that money, you need one of three things: 1) the receiving institution simply trusts that they'll receive the money and releases the money as soon as they can - which is not realistic due to counterparty risk, fraud/revocation risk, etc and can happen only either if the whole payment happens in a single central system/institution (e.g. something like paypal) or the system includes very high fees to cover those risks. 2) each sending institution has a large binding collateral and there are appropriate safeguards that in the case of someone "going bad" the receivers are going to get paid anyway - which requires a strong central system to manage it, and the institutions deffering a lot of power and money to it (in this context, a million doesn't come close to a lot of money). This is the system described in the original article - the payment gets credited/finished first, and covered/settled between the banks afterwards. 3) in the absence of strong guarantees or blind trust, everyone in a payment chain pays the money forward only after they have been actually paid to cover the payment, adding days and days to the processing time. This is the current US system and also how general arbitrary international payments can be settled - particularly in international payments, you can get the full payment data nearly immediately, but you generally wouldn't receive the funds until every institution involved has covered their risks.

pbhjpbhj 11y ago
>It is trivial to have the payment messages happen in near-real time. [...] receiving institution simply trusts that they'll receive the money and releases the money as soon as they can // Surely the message is "the money", it's not like a truck pulls up at the bank each night with the transaction balance for the day? I don't see how there's a risk if there's a transactional process: for example Bank A sends request for money from B (eg to fulfill a payment by debit card); B reserves the money and sends a verified payment (crypto signed and what-have-you); A processes the payment and increments the relevant account with reserved funds and sends a receipt to B; B processes the receipt completes the decrease on the relevant account using the previously reserved fund and acknowledges the receipt; A receives the acknowledgement and verifies the funds as available in the account. So, if B doesn't have funds to reserve then the payment can't be processed and A won't acknowledge any receipts claiming the transfer of monies. "A" thus won't increase a balance for any accounts. Where's the risk?