I was just complaining to my wife about this earlier this morning (we are in the US).
I made a credit card payment last Thursday (1/14) in the mid morning, maybe 9:45 AM. Ideally this should happen pretty quickly, but I know in the US the infrastructure just doesn't match my current expectations. Seemingly there was zero movement until my credit account was credited the payment Friday afternoon, but the money was still in my checking account (no holds or pending transactions).
The weekend goes by, no movement. Monday (a bank holiday) comes and goes, as does Tuesday. I get a text message early this morning (~6:45 AM) that there was a large withdrawal from my checking account - the payment showed up! Nearly three full business days before the money was actually moved, and as of right now it's still a pending transaction.
The cynic in my wants to think that it's so people who don't pay attention to their finances are more likely to overdraw/double-spend the money, but part of me thinks it's just because the US infrastructure around banking and payments is so old it just isn't capable of anything approaching real time transactions. I would love to see a logistical/technical explanation of why it takes so long for this type of thing in the US.
The fastest possible resolution for your fact pattern would have been "money withdrawn on Friday" unless one or both of your banks decided to covertly extend you credit. This is because ACH pulls are an overnight batch process in the US.
Given that it took a few days, it's possible that your credit card company is using an intermediary to process ACH payments (there could be a variety of reasons for this) and, as a cost-savings measure, either the CC told the intermediary "We'll take your cheaper 3 business days option in preference to next day" or the intermediary told your bank "We'll take your cheaper 3 business days option in preference to next day."
The cynic in you should probably not worry overmuch about why a bank is willing to grant you free float. It's pretty pedestrian: back office optimizations, yay.
> The fastest possible resolution for your fact pattern would have been "money withdrawn on Friday" unless one or both of your banks decided to covertly extend you credit. This is because ACH pulls are an overnight batch process in the US.
I don't think this is true. There is the NACHA same-day ACH initiative [0] which is opt-in and at least some institutions have already opted-in.
I've experienced frequent same-day resolution of ACH transactions when using bank services from two very large US banks (one based on the west coast, one based in the east coast) and also a small employer credit union.
It's true that my experience is not common and it often does take longer than a day. Many banks still do use overnight ACH. But I don't agree with the statement that overnight is "the fastest possible resolution" -- some banks have opted-in to doing faster and have already begun doing so.
I did know that ACH stuff is a daily batch, but I hadn't thought about an intermediary between the card and bank, that's a good point. And even without it, I would imagine that even an entity the size of Chase probably gets a discount on 3-day v. next-day.
I worked at a data center for a bank from 1997-2001. Processing ACH transactions for our data center involved a 1970s-era NCR mainframe, a decade-old MS-DOS PC (they tried to upgrade it once, but the expansion card that handled the encryption wouldn't work with a faster system and a new card cost upwards of $10k), 9-track vacuum-fed tape drives, manually dialing a phone and then switching it over to a 9600 baud modem, and running batch-processing jobs which took greatly varying amounts of time to run. I did not handle the sending of ACH data back to the ACH system, only receiving it and processing it. I worked from 4PM "until it was done". Most nights this meant around 9:30PM. However, in situations like you described, where there is a bank holiday on a Monday, things would always take longer (higher volume of transactions, nothing was done on weekends so everything just accumulated). In situations where it was the end of a month AND a bank holiday on a Monday? Holy crap. I wouldn't get out of there until 4AM usually in those situations.
There was a great deal of hand-holding and operator intervention during the processing. The systems used were older than many of the people working on them. When software updates needed to be made, companies had to locate retired software engineers that originally made the systems and pay them astronomical amounts to either perform the modifications or consult on such modifications. When hardware broke down, like our high-speed dot matrix printer that printed on that green-bar paper with holes on each side, they had to pay specialized repair techs $400+/hr (starting from when they got in their car in a city 1.5hr away) to come out to troubleshoot. Then they had to track down replacement parts.
When you work with a bank, if something still functions, or the cost of repairing or updating it costs less than purchasing and transitioning to a new system, it does not get replaced. Systems ossify and live pretty much forever. The mainframe we used was literally the only one of its kind still in operation in the entire country (we found this out when the other people who used one, a restaurant, decommissioned theirs and gave it to us for free if we would hail it away... we finally got a disaster recovery solution that way).
I get why they don't want to migrate, but wouldn't it be sensible to create a new bank, with new systems, and gradually move people over? All new accounts go to the new system, and over 20 years or more it's migrated.
Yes, but in 2016 it'll be same-day ACH Credit only. That doesn't solve the problem. The ACH delay is on the Debit side (2 working days ) which will not be same-day until 2017 and the banks are not mandated to update balances same day until 2018. So same day ACH will not be effective till mid 2018
>> Virtually all types of ACH payments, including both credits and debits, will be eligible for same-day processing. Only international transactions (IATs) and high-value transactions above $25,000 will not be eligible. Eligible transactions account for approximately 99 percent of current ACH Network volume.
Also of note, same-day is not real-time...it is disappointing that we are not pursuing real-time transactions.
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.
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.
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.
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.
What protocols and software stacks do they use? How are they networked? What are the steps in the verification process? What prevents it from being able to work in real time? Where is this type of information formally recorded? I had a hard time turning it up. For such a critical and prolific infrastructure it's unusually opaque.
I once worked with an ACH system where the transactions were in a txt file on a Windows box that was, IIRC, copied over ZMODEM after a dialup modem connection was opened to whatever the other party was (bank? processor? I don't know). Obviously, given the liability involved, I never messed around with it. But I always wondered what would happen if some amount was different than expected. One would hope there's all kinds of verification going on, but I kind of doubt it.
When I worked at a data center for a bank, we had basically the exact setup you are describing. Part of my responsibilities was to take note of the amount that came through via ACH on that Windows machine (Windows 3.11 actually... this was in 2001) and enter it into a Lotus 1-2-3 spreadsheet, along with totals which I got from reports that ran after the days batch processing completed, and make sure they balanced. If they didn't balance, I had to go hunting and pray that I simply transposed a number or typoed something along the way... if I did not, I honestly don't know what happened. I had to call one of the other employees to come in and orchestrate getting it fixed. (I was alone at the data center, which consisted of a mainframe and a handful of PCs... probably an order of magnitude smaller than what you would picture if I just say 'data center') Luckily, it happened very very rarely. Maybe a handful of times in the 4 years I worked there.
Heterogenous, differs between institutions, differs within institutions, also many/most institutions are a mix of incompatible systems because the business institutions are a merger of mergers with acquisitions of mergers, all while requiring to keep constant operations, full archives of all past deals of all those legacy institutions and compatibility.
In some spaces, Java is popular, in some spaces COBOL is used, and many have something from a multitude of different exotic niche platforms. In any case you'd expect to have a mix of systems/platforms, some of them modern, some of them older than you are. You'd have 'common' platforms/stacks e.g. oracle on linux, or mssql on windows, you might encounter something also running on LAMP somewhere, and you might have e.g. a custom platform with integrated DB-like and programming-like functionality running on a particular version of AIX, all of those in a single institution.
> How are they networked?
All kinds of things. Some use common TLS channels. Some parts of business may even use simple file transfer or public email without expecting the channel to provide any security, but rely on each separate message being securely encrypted and signed.
For anyone that you "don't know personally", there's SWIFT that will give you secure though not cheap messaging - if you get a swift message from e.g. FBNINGLA then you can be sure that yes, this actually is an authorised representative of the First Bank of Nigeria.
> What are the steps in the verification process?
Depends on your pre-existing relationship - if you trust them up to some limit (equivalent to a credit line up to that limit), then you do technical verification that the request is authorised and authentic and that's it. If you don't, you wait until they somehow hand over the 'cover funds' to someplace that you securely control, verify that it is received there (e.g. account statement from that place at the end of their business day), and then proceed further.
> What prevents it from being able to work in real time?
I believe mainly because multiple independent parts of the process that have no motivation to change, and often have motivation to not change - if you agree to do your part of the things faster and cheaper, it adds cost and decreases fee revenue; and changing things requires cooperation and investment from a majority of players.
Up to some part, there may be legal obstacles that prevent some particular ways to be done faster (the liability 'hot potato' issues) but IMHO those would be quickly solved by the industry, lobbyists and involved lawmakers if the motivation was there.
> Where is this type of information formally recorded?
It's heterogenous, so it's a multitude of similar-and-different things. For any particular payment system you'll have short public descriptions and also available training courses, technical standards, etc though often at a significant fee. It is niche expertise required within that niche, and not particularly PR-useful to publicize in detail, probably entirely the other way around.
Huh? Would a move to a real time gross settlement system fix all of this? We run all interbank transactions over a real time gross settlement system. There is no counter party risk. Everything is backed by a giro account at the central bank.
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.
These are real problems. However they are solved elegantly by central banking, and indeed that is what we have in the US: ACH and FedWire. Each bank holds an account with the Federal Reserve, and can make cheap instantaneous or free nightly batch transfers between its Fed account and other banks' Fed accounts. The strong central system extracting guarantees and ensuring minimal abuse is a major production, but we still use it for all electronic transfers.
The problem is that many American banks also process their own transfers in a nightly batch on the same 60s mainframe application they've been using since mainframes were cool.
First business night: money is taken out of your account.
Second business night: money is moved between banks via the Fed.
Third business night: money from the Fed is credited to recipient account.
If both banks were to actually do online transaction processing (like MC/Visa) then you'd only wait for the Fed's nightly batch. Some institutions like Alliant Credit Union have the rare differentiator of actually transacting with you and the Fed on the same day, instead of in separate nightly batches.
FedWire is actually instantaneous settlement, but the banks have all apparently conspired to charge an enormous markup on it. It doesn't help that cheap ubiquitous wires would outright destroy MC/Visa, who effectively get to tax all consumer spending by being the only system with live/online transaction processing for authorizations.
The EU solution to a very similar problem that we had earlier was essentially a single item in legislation (the payment services directive) that states that if a consumers payment is not credited to the beneficiary within a specific time limit, then the consumer is entitled to compensation from their (sending) institution. The industry had a couple of years before it came into force, by that time everybody implemented it.
I believe that a similar approach is the only way that can be effective in achieving a similar result in USA - unless some regulator draws a line and says "your product must meet a certain quality level or it's not fit to be sold" the current market has no reason to change, it's more profitable as it is now.
+1 business day if made in paper, and cut-off times apply - if you make an order at late evening, the bank can treat it as received in the following business day.
"for what cases" is a bit tricky. It must apply to all intra-EU deals in EUR and for the EU countries that don't use EUR, their national transactions. But for other combinations of countries and currencies (e.g. to non-EU places like Switzerland, local transfers in USD, etc), it varies, and there's some room for interpretation by member states.
>It doesn't help that cheap ubiquitous wires would outright destroy MC/Visa, who effectively get to tax all consumer spending by being the only system with live/online transaction processing for authorizations.
Cheap (actually: free) ubiquitous wires are a reality in the UK as described or in the Euro zone, and I think MC/Visa do just fine there.
>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?
"The money" is money held in the bank's account at the Federal Reserve, and sending an electronic message to the Fed to transfer this money immediately (FedWire) counts as actually moving money. The only problem is that all banks have decided to charge $25 for this service, despite it costing them on the order of $1.
But they have agreements with banks to process the final transaction at the close of day [don't they??] - so the reserve would then charge them $1 per day per bank they had to settle a debt with? Presumably the transaction receipts and acknowledgements are binding meaning they can't legally screw another bank out of that money. So the risk is that they'll have to sue another bank in to the ground and make oodles of money if that bank refuses to settle with them at the end of the day? [Off-shore is obviously going to be different.]
Can someone speak to the situation in the UK in this respect too, please.
Insolvency screws another bank out of that money no matter what legally binding acknowledgements you have, and you won't be able to recover much from suing because, well, they don't have enough to pay.
They are rare, but not that rare, especially whenever the economic cycle again and again reaches some hard times. for example http://www.statista.com/statistics/276231/bank-insolvencies-... lists a few hundred insolvent institutions just in the last dozen years.
First, let's not look at credit card payments which work very differently from what you describe (the 'network' i.e. MasterCard company, Visa, etc play a big role) but at payer-initiated transfers.
Second, keep in mind that in almost all cases you won't have a bilateral relationship, this is unrealistic to have every institution to handle close relationships with each other - instead, usually the best case you can rely on is a "star" scheme where any A in some market can reach any B in the same market by sending a payment message + money to some "central" C and asking that C to forward the same money to B; and in more distant situations you can easily get 2,3,4 or more intermediaries for various reasons.
Third, be very careful with terms like "the account" - unless you add more specifics, all that "the account" generally means is "our accounting department believes that this is how much you owe us"; it should reflect 'having money' if accurate but it is not the same e.g. if you're unable to collect what your accounts say you own. If you say "A has $10 in their account with me" it literally means "As far as I know&have accounted for, I owe $10 to A, and should allow them to do stuff worth $10 as they order".
But for the main points - your proposal has two weak spots.
1) It requires any paying institution to have large available reserve funds with all receiving institutions. I.e. if I'm bank A, and I want my large corporate customer to be able to send $100m to any of the banks B,C,D,E,F,G,H,I,J,K when chey choose to, then I would have to keep $100m 'in my account' with each of them (or alternatively, have a credit line, where I'm sure that they will allow me to overdraft $100m) - in this case this requires having $1b of capital just so I can have this capability even in this small toy example. If you'd want to have more potential recipients instead of 10, you'd need even more capital. Part of this is actually done so in practice, but as you can see it's not that simple.
2) Your proposed messages (which are similar to real world implementation) + appropriate legal agreements only achieve that after all this ritual is completed, there is a legally binding situation that yes, the sending bank does owe the receiving/executing bank the required amount.
However, from a risk-averse viewpoint "the money" is transferred from A to B if and only if B is ensured to have full access to the full money (as in, they can actually request it driven by a truck to them and be sure that this will happen) even if e.g. A declares insolvency after sending all the required messages.
Do note that in the usual insolvency procedures, if A has $10 as "funds available in the account of A" (i.e. you owe $10 to A) and also A legally owes you $10 for the payment you did an hour ago, then you will not be able to take that $10 - all their assets (e.g. money in that account) will be split among all the creditors, so you can expect to actually not get most of that money in such an event. This is part of the 'liability hot potato'; it goes a bit deeper but you'd need a finance lawyer to explain it in more detail.
You would expect to be safe from counterparty risk only after 'your account' with the sending bank shows 0, they have legally acknowledged so (which for various legal reasons depending on country may require an end of business day, not just a signed message from them), and you have "got the money" in some form that's more trustworthy than simply 100% legally&cryptographically secure acknowledgement that A owes you the money - e.g. a message from a truly trusted institution (e.g. your central bank) that they owe you this money and it will stay so even if A goes insolvent.
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.
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.
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.
This used to be a big thing, but since Check 21 and truncation that amount of money banks made has been severely marginalized. The big reason stems for risk.
The 2-3 allows the receiving FI to mitigate, IIRC, around 70% of the risk associated with the most popular types of rejects. (e.g. insufficient funds)
In addition to the time needed for ACH, some or most of the lag may be due to fraud/money laundering concerns, even if it's low-risk. If that's true then it's a regulatory issue.
"The cynic in my wants to think that it's so people who don't pay attention to their finances are more likely to overdraw/double-spend the money"
The cynic in you is right. There have been numerous lawsuits that have won against banks for structuring the movement of money so that it is the most likely to incur overdraft fees, which are a $1 billion money maker just for the top three...
Bankers are more the enemy of the people than terrorists.
It's possible to "game" this a bit to squeeze an extra $50 or so out of an empty account. Of course, it's a losing proposition given the overdraft fees, but I managed to get a few desperately needed bottles of booze this way back when I was struggling with alcoholism.
Source: I one of the elected tech-reps on the The Faster Payment Task Force,a Fed-chartered initiative to create a real-time improved bank transfer system, like the one in the UK. I also work at Dwolla, a payment platform that has exclusively focused on modernizing the backend ACH system for over 5 years, as well as created our own real-time system for banks (See: FiSync).
There's a lot of good, and bad, information here. It's all impossible to tackle, so I'm going to point to the good things the US has going for it. (Worth getting other Fed Fast members and doing an AMA? Let me know):
1) As many mentioned, Same-Day ACH is coming (slowly but surely). Although not real-time, it will be a helpful stopgap as more real-time systems come online at financial institutions (see: #3). Combined with new Payment API Platforms, like Dwolla, many of us are enabling meaningful access and adding flexibility to an otherwise outdated platform. This will position platforms to take advantage of these new timeframes when they start arriving late 2016 and 2017.
2) The major ACH operators, The Federal Reserve and the bank-owned The Clearing House, are both making significant investments in their tech stack to enable real-time capabilities (The Fed just inked a $17M deal with IBM to update their software and capabilities, and TCH signed a deal with UK Faster Payments Provider, VocaLink).
3) The Faster Payment Task Force is an unprecedented market-led initiative, which despite all odds, that actually making meaningful progress on aligning the criteria and expectations for an interoperable real-time system. This is HUGE. Imagine cramming +300 lifelong competitors, embattled legal adversaries, entrenched interests, and long-standing rivalries in one room to debate the future of a trillion dollar landscape. Now imagine them to agreeing to create a better system. And I'm not just talking about improvements in speed, but better security, flexibility, and capabilities that could enable the next wave of commerce. Keep your eyes on https://fedpaymentsimprovement.org/, big news is coming in the next few weeks.
You've made me terribly jealous of the UK. I'm in the US and see our current situation with regard to money transfer as an extremely dangerous one. Aside from the annoyance of money transfers needing to go through a bank, the fact that payment networks charge a PERCENTAGE drives me mad. It does not cost more to move a larger number over the wire. There is no justification whatsoever in charging a fee which gets larger when more money changes hands. And as more and more of our economy moves away from cash and toward payments that flow through these networks that skim percentages, we are quickly getting to a point where banks and credit card companies are getting to skim a percentage off of each and every single transaction that ever takes place in our entire economy. That is madness. We are setting them up as de-facto tax collectors, with the ability to levy and collect taxes with no public involvement. People fought wars over that in the past.
I've had an account with Dwolla for ages, and absolutely love what they provide. Flat fee money transfer. It saddens me that I can't use Dwolla everywhere. Are the advances in the ACH system going to do away with fees that include a percentage component? I would be very surprised if banks simply decided to voluntarily step back from a system that will enable them to have more control over the US economy than the federal government (there are many tax-free transactions in our economy that the banks will still get to 'tax' with their transfer fees, giving them more control).
Most people probably don't realize what a herculean effort you are involved in. During college I worked in a data center for a bank as a mainframe operator (this was 1997-2001), and processing the ACH data was one of my responsibilities. The system the bank used was an NCR mainframe. It was so old that during my time there, the company (it was actually a separate company from the bank for some reason) received a call and was told that the only other organization in the country still running that model of mainframe, a restaurant in North Carolina, was getting rid of it and would give it to us for free if we would haul it away. We setup a Disaster Recovery system with it. I left the data center shortly before graduating college, and the bank was being acquired by a larger bank which was going to bring all of the processing into their own data center. However, about a decade later I ran into my old boss and learned that the transition never happened. Moving away from that ancient mainframe was apparently deemed too problematic/expensive so it persisted. I would not be surprised if that mainframe was still running the show for half a dozen bank branches, with its antiquated tape drives (the kind where the tape is a big reel, 9-track I think, like the things you see in films of mainframes from the 1960s). Banks are, as far as I understand it, the pinnacle of 'if its working, don't upgrade it'. My hats off to you sir for being involved with trying to move us forward!
>> Are the advances in the ACH system going to do away with fees that include a percentage component?
Didn't Stripe just debut ACH that had (admittedly an initial percentage based) pricing capped at $5? They have a $10,000 limit per payment, so maybe you that's not high enough for what you're talking about, but it does seem like things will move that way.
I will say, the higher the dollar amount, it seems like there is an increasing fraud/risk component that while not costing any more money to send/receive, needs to be considered and paid for by someone.
We live in a capitalist country where no endeavor willl be undertaken without some vision for profitability. This is fair. Stakeholders in the new system, the ones that put up the money to build and support the system (Financial Institutions, providers, etc), will need to find a way to compensate themselves for their investment and prove to their share holders the fiduciary value of doing so.
From there, there are three factors that will most influence pricing.
1) Scale: how many transactions the system as a whole will process? We're all familiar with Wires and how expensive they're compared to ACH. That's because they don't have the critical mass or number of transaction ACH does. The more transactions on the system, the less financial burden the system has to assess on the end-users.
2) Market forces: How providers will price their services all depends on the market and their target customers. You mention stripe's percentage model, that's their business decision. Dwolla, a counterpoint, offers a flat fixed monthly model. The intelligence that formed the pricing models is what makes the free market so powerful.
3) Fraud: How this system mitigates fraud (through tokenization, improved fraud sharing among participants, better authorization practices, etc.) will greatly influence how much financial burden is passed on to us, the consumer. Good news is that we're starting over. LOTS OF POTENTIAL HERE!
> Are the advances in the ACH system going to do away with fees that include a percentage component?
See my answer to @hannan below. (Short answer: yes)
> I would be very surprised if banks simply decided to voluntarily step back from a system that will enable them to have more control over the US economy than the federal government.
I don't think I've ever heard this more accurately or succinctly put. In this megathread, here on HN, everyone thinks it's about banks wanting money. From working with banks on this for nearly 5 years, this isn't true. They're fighting for relevancy, the status quo. They've had control over this system since the 70s and have built fortification after fortification (through regulation, technology, etc.) to protect themselves from the whims of trending market forces.
But you remember in Rocky 4, when Rocky made Ivan Drago (the invincible super-soldier) bleed? (source: https://www.youtube.com/watch?v=VefZwIhCdqI) It showed Balboa that Ivan was human, had vulnerabilities. The match shifted after that.
The fear Ivan felt is exactly how financial institutions feel now. New market entrants (see: Apple, Stripe, BTC, Dwolla), regulatory uncertainty (CFPB, Dodd-Frank, etc), and changing customer expectations (real-time communication, uberization, etc) have shown banks that they're no longer unaffected to the whims and trends of consumer innovation.
This is why they're at the table (despite torpedoing Same-Day ACH in 2011). They're choosing the least worst of two options: have the Fed step-in with a mandate (could get from congress in the next 2 years) or inform the next infrastructure of the US economy.
The good news is that this time, unlike in the 70s, it's not just banks designing the system. Fed Fast Task Force is comprised of consumer groups, retailers, innovative tech companies (including Dwolla, Ripple, and many more), regulators, academics, and many more. We may not have as many cards as we think, but we've been able to influence some pretty key decisions.
Also, banks aren't always the villians we make'em out to be. Behind those logos are real people that really want a better payment system, not just to protect their bottom-line but because they want something better for their families, neighbors, and (selfishly) themselves. We'll get lapped by other economies if we don't (See: 37 other nations with or creating a real-time system). They're fighting hard to make the best system possible, given their constraints (fraud, liability, existing regulation, and, yes, their P&L).
Regarding international payments, I dug into this a little one day out of curiosity and ended up here: https://www.frbservices.org/eventseducation/education/fedwir...
The PDFs on that page appear to show you precisely how the XML messages that conduct the transfers are formatted
Cross-border payments are more definitely more interesting. There's a lot of complexity that is outside the scope of the standards - research correspondent (nostro/vostro) accounts and cash management, for instance.
Basically, you need to find a path from your bank to the target bank account through the cheapest path of intermediary banks that factors into account fees charged along the path, expected daily transfers at that bank, the payment's impact on liquidity and interest rates of cash left on books in a particular account at a particular time of day vs. alternative options.
The thing about international wire payments is you never know what you will receive. I send out an invoice for X and I get some seemingly random value less than X. My bank can't tell me why - the best I can get out of them is some intermediate bank along the way took out some fee. It makes it a nightmare to match up an invoice with a payment.
If you wanted to exploits this effect for fun and profit you could always deduct $50 to $100 from every invoice you pay and the recipient would just assume it was some intermediate bank fee.
Switch banks? If your bank is using SWIFT, the MT103 message has fields to track this information (fields 71F and 71G) and validations to ensure the fields are populated correctly (i.e. 32A and 33B must reflect 71F and 71G correctly). Any decent bank should be able to display the originating payment instruction details for a given cross-border payment ledger entry. (I've implemented SWIFT processing fees for cross-border payments.)
Well it is a little more difficult here in Australia. I have asked a few times and the only way they can provide me with the data is to do a trace which they charge me $50 for doing. Paying $50 extra to learn that some bank took out a fee is not too helpful. I more wish I could stop it happening.
I never thought I'd say this, but banks in the UK are actually pretty good. Over the last few years I've lived in a few different countries and banks just dont compare.
In the UK you can open a bank account for free, with no minimum balance and no stupid charges (i.e. ATM withdrawals, even at your own bank).
In comparison to where I'm from(Poland), UK banks seem to be stuck in middle ages and it's infuriating.
- cannot get two separate cards for the same account(unless it's a joint account). Why would I want to? I'll explain in a second. In Poland I have a visa debit + mastercard debit cards for the same account.
- the cards have a limit of 300 pounds for ATM withdrawals. There is not way to change that limit, I've asked at a few banks and that's just what it is, even in an emergency. With my Polish bank, I can log in online and change it on their website - I can set it to any amount, 100k a day if I want to. I used my Polish card to withdraw few thousand pounds out of an ATM in UK and it worked fine(the ATM itself had a limit of 400 pounds per transaction but I just used it a few times and it worked fine). I can also set a separate limit for internet transactions - which is why I have two cards. One card that I carry with me all the time but which has 0 limit on internet transactions, and another card which always stays at home but which has 0 limit on ATM and over the counter transactions. If someone steals the card that is on me they can't use it on the internet, and if someone steals the card at home they can't use it to withdraw cash or to pay for stuff.
- No ability to see pending transactions online on my debit cards until they clear. This one is absolutely crazy to me. How can I know if someone hasn't stolen my money if I can't see pending transactions? The only way to do that is to call the bank. As far as I know, only lloyds shows pending transactions online, Barclays had it as a "suggestion" for ages now.
- Credit cards. In Poland, I apply for a certain limit when applying for a card and I either get it or I don't. In UK, you apply for a card, have to sign all the documents for the card, and only after the card arrives I can see what sort of limit was given me. If I don't like it, there's nothing I can do - well, I could ring the bank and ask, but they don't have to increase it. I could close the account and apply somewhere else but that negatively impacts my credit score, what a nightmare.
- can't change the pin for my card online.
- most UK banks won't send any of my documents to a foreign address even if I ask for "security reasons" but my Polish banks sends all theirs to my UK address no problem.
"the cards have a limit of 300 pounds for ATM withdrawals"
Some banks have slightly higher limits, I've seen up to £500 but I have not seen any that allow you to set an arbitrary limit.
"only after the card arrives I can see what sort of limit was given"
It is quite common to request a credit limit when applying for a credit card and have it accepted or declined, but I guess different banks do things differently.
I don't know if banks work differently in Poland, but in the UK if I see a fraudulent transaction on any of my cards (debit or credit) it will be refunded, except where I disclosed my PIN.
That seems really terrible. It basically gets banks or credit companies off the hook for fraud. It presumes Chip and PIN is secure (it's not, fraud levels dropped momentarily when it was debuted, but are high as ever now) but ends up being nothing but a way to transfer fraud liability to the consumer - who has absolutely no power to improve the system to reduce fraud and can't really be said to be to 'blame' for the fraud at all in the first place. Build a flawed system by cutting corners, but get the marketing spot on, and get yourself off the hook for fraud AND remove all pressure for repairing the system you cheaped out on in the first place? Wow.
It isn't, but at least for a long time that wasn't an issue. Most terminals were set to online mode, so pin wasn't verified by card but by bank. On the other hand the ones in UK mostly work in offline mode which requires the PIN to be verified by card. Not a great thing to discover abroad that your card chip doesn't contain any PIN at all. Good thing is that it can be placed/updated on card by simply using ATM.
Well, I can change the pin for my Polish cards on my bank's online page, so I guess the pin must be validated with the bank's servers before allowing any transaction.
There's a screenshot of what it looks like on the website:
Its not actually possible for this to work with a 'chip' card.
If your polish card has a chip and you change the pin online, there is a slight chance the change wont register. Many ATMs don't send a request to check the pin/they check the pin stored on the chip.
This is why you have to be physically present at an ATM to change the pin.
So if you change the pin, and say go out of Poland and use it somewhere else, without using it in Poland first, it would say the PIN is incorrect.
This risk might be why it is not readily available with UK banks.
Well, I know that it definitely, absolutely works while abroad. How do I know? Because the cards from that bank don't arrive with a pin. You don't get two envelopes, one with the card another with a pin - it's just the card, then you have to go online, log in, activate the card and set the pin. I've had new cards delivered to my UK address, activated them online and they worked in the UK without any problem(without ever being used in Poland first). So maybe there is something on the chip, some variable saying "always check the pin with server"?
I'd agree, they do just about everything could want you want quickly, efficiently, and most services are free if you're careful.
the customer support can range from OK to terrible... if I'm not sure how some new "mobile only" bank is going to be any better, if anything I'd expect it to be worse as I can't go into a branch and shout at the manager
if it ends up being anything like google support that'll go down like a lead balloon.
There was a discussion a couple of years ago around how ACH works. ACH is the dominant system of money transfer in the US and takes 2-5 business days on average for a transfer, compared to the real-time systems in many other countries.
I'm disappointed there isn't a guy moving a small gold coin from one vault to another at the central bank every time I buy something with my debit card. "looks like bob is getting drunk on cheap beer at the local pub again. If he'd just order a bottle of wiskey instead I wouldnt have to run back and forth all damn night. Maybe id get to go home and see my kids for once"
This is actually how it works (or did work, recalling the stories of gold manager at a bank) when central banks move gold deposited from one bank (usually other central banks, not necessarily) to another. The gold bar is moved from one pile or trolley to another. The clipboard list is updated, and the daily tally is done at the end of the day to make sure nothing's been done incorrectly.
Banks in stressed/developing countries may do cash transactions with each other where there are issues of trust.
And then to abstract it a bit, there's the cash van moving money deposited at larger, more trusted banks, to smaller commercial banks that have more business customers (again, a much bigger differentiation in banking business in developing/emerging countries), creating a long term net flow of cash (but, if the commercial banks hopefully don't go bankrupt) not of money as credits come electronically.
I think the main reason is all seems pretty stupid is because the system, even within one country, is so f'n goddamn huge with a lot of legacy stuff in it, that bad UX is just inevitable, rather than being incompetent.
But an exception to incompetence is the EMV's decision in the U.S. to transition from swipe & sign, to chip & sign, and later (2018?) to chip & PIN. That really is just stupid. In the U.S. my debit card I never sign for whether chip or swipe, I always use PIN. In Europe, that same card when swiped I'm asked for PIN, if I use the chip it wants sign! WTF?
The delays of ACH seem less between friends at least if you use Venmo or Google Wallet since that's effectively private currency (within that system) and then only periodically use a "sweep" action if that balance gets higher than you want.
The Swedish equivalent to Paym, called Swish, has been really successful. Probably an interesting case to study for those trying to create the next Paypal.
The reason Swish is successful is because it is owned and maintained by 6 Swedish banks [1]. So the payments network - the hard part - was already in place. The banks just had to brand the app in an attractive way, offer discounts/promotions to get user adoption, and provide good UX/UI.
I doubt we'll see a new Paypal until there is a new marketplace (Ebay) on a new communications medium (internet) that attracts enough users that a new solution needs to be created to deal with it.
I don't see how that makes a difference at all, considering Paym is owned by Vocalink - which is 18 banks according to the article.
"Paym is a new service launched by VocaLink in 2014"
"This money goes to Vocalink, a company owned by a consortium of 18 banks, which operates FPS, along with Bacs (for Direct Debit), and the LINK network (ATMs)."
I would say it's likelier that the fact that Swish transactions are instant from the customers perspective have played a large part in why the uptake for Swish has been so good in Sweden. As regular bank transfers still take hours to days to settle.
> So the payments network - the hard part - was already in place.
Similar example: Polish mobile payments company (Blue Media) wanted to speed up most commonly used service - charging prepaid GSM accounts so they created account in pretty much every existing bank as internal transfers are pretty much instant. This also required to integrate with many APIs to fill out/automate transfer details. Thanks to that it was easy for them to offered express transfers (5-15 minutes instead of standard 2-4 hours)
That's not the only reason. After all, the British system is owned by the 15 banks.
Yet the British banks have done very little marketing. I wonder if they prefer the current situation, where they perhaps earn more money from debit card fees.
In the market of payments, all banks compete with rather similar products. They make money of it in (a combination of) three ways - 1) direct fees; 2) "float" (interest earned on money 'in transit', low currently because of low rates, but huge money in other decades); 3) selling other products (credit, etc) to people who also need your payment services.
If you offer a faster and cheaper way to settle payments than your competitors, you'll be able to gain a lot of lucrative corporate customers.
However, if all of the major banks offer a faster and cheaper way to settle payments, then they all simply earn less in fees and also have to pay for developing a new system. This is a loss-loss situation, so it's going to happen only in face of strong competition by other payment systems (in which case they can near-immediately lower prices and increase speed to undercut them, while still making profit) or by regulatory means - e.g. the SEPA-payment legislation in EU forced many inter-EU payments to become much faster and cheaper than before.
Ok, all you need is a good platform, a good brand, good marketing and a nice app? So you're basically saying that the reason Swish is successful is that they are doing a good job and deliver a good product?
I'm saying that they did not have to build a payments network from scratch, or convince the largest banks in the country to provide APIs for their platform, which would have been the hardest part of launching a similar product as a private company or individual.
I would say it's likelier that the fact that Swish transactions are instant from the customers perspective have played a large part in why the uptake for Swish has been so good in Sweden. As regular bank transfers still take hours to days to settle.
In the United Kingdom, sending bank to bank or Paym is all the same if I'm not mistaken. The only difference is that on Paym you'll use a phone number instead of an account number.
Same for "MobilePay" in Denmark -- everybody has it, you can use it to pay in supermarkets or transfer money to friends. I suspect it is really good for things like flea markets because people like myself who never carry cash can suddenly pay there.
Good article. I'd like more technical details, especially security related, as some pretty hard problems must have been solved to implement such system where every error or vulnerability might costs tons of money. Any recommendations?
Disclaimer: I work at Mondo and am the one implementing the way we talk to our agency bank.
How it actually works is theres a Message Queue (IBM MQ) that is connected over dedicated lines (MPLS or point to point, but not over the internet).
Each side uses a couple of layers of Crypto, including using Hardware Security Modules (HSMs) to actually encrypt and sign the messages.
The crypto signatures also have legal standing in a sense, if the message is valid and signed then the counter party or agency bank is authorised to process it.
Banks are full of great lessons in system design that extend past the realm of purely technical solutions. They regularly make cost vs. risk trade-offs that make technical people nervous, for example, straight-through processing of low value payments with the expectation that material fraud can be detected through regular analysis/reconciliation/auditing and dealt with out of band.
It sounds that you have a very interesting job. Mind if I ask few questions/career advice? If so, please drop me an email (can be found on my profile).
In Canada we have something called an Interact E-Transfer that the major banks all support. You add a recipients email address and create a "secret question" they can answer. Then, you simply fill our a form that says "Send $X From Account Y to Recipient Z". Depending on the bank the email is sent between 0-60 minutes later, the recipient clicks the link, logs in, and picks which account to deposit it to. The whole process is super easy to use.
Most banks charge about $1 per Interact E-Transfer, but some accounts will get a certain number of free transfers.
With all that being said, I just received an email from TD Canada Trust (One of the major banks) stating that they are now imposing a $5 fee to cancel an E-Transfer (previously free). I can't remember the last time I cancelled an E-Transfer, but I'm still most likely going to close all my accounts with them over it. I find it absolutely outrageous that they would charge you $5 to cancel a completely automated process. The only explanation I can think of is to nickle and dime their customers.
In the Netherlands I take my phone and send money to friends, companies, tax services etc, for free in about 15 seconds... arrives within minutes usually. Then there's iDeal which is nice, too.
Creditcard payments are a different story, also pretty quick but not as seamless, and not as popular either. I only have a CC to buy some stuff from other countries, or when I leave the continent although my regular debitcard worked in 4 different continents so far, too... Tbh my CC is pretty much collecting dust.
My experience is quite different, sending from Rabobank to ABN AMRO seems to take a few hours. From Rabobank to ING at least a day. From Rabobank to a bank in Ecuador is usually faster (within 30 minutes), but not reliably so.
All the fast payment systems outside the US are Government-run. In the US, online payments are run by private enterprise. The US doesn't have enough socialism for this to work.
The US Fed has been pushing for faster payment processing, but the big banks don't want it.
The UK system is now private, but the Payments Council, which set it up, was sort of a quango. The UK has a history of organizations which are semi-private but have close ties to the government.
It's less about private vs. public. It is more about national banks vs. regional banks.
In Canada, the "Big 5" banks span the entire country. In the US, there are so many of these tiny regional banks. Harder to get everyone on board with a new bank-to-bank service. Especially with banking IT that is so rigid and every bank wanting to do their own thing.
As an example, all the Big 5 Canadian use the following account number system: 123 12348 7234561.
"123" is the Bank Number.
"12348" is the Branch number (the last digit, eg. 8, specifies which province).
"7234561" is the account number. If your account number starts with "7" then it's a US dollar account.
You'd usually make a CHAPS payment for high value payments, instead of through Faster Payments. (There's mention of this in the article, in the Net Settlement section).
CHAPS costs a little bit of money (~£30), and for that sort of value your bank may want to see you in person and check ID, etc.
You can still do it electronically, it'll just take more than a few minutes as it has to run through the bank's daily reconciliation process. That's probably OK though, I doubt many people have the need to transfer > £250,000 and the entirety to be available immediately.
In the US, anyway, I had to do such big transfers via wire transfer, and while it happens (almost) immediately, you have to catch the 10am or 11am (Pacific) deadline, depending on the bank, or else you're waiting another whole day.
Unless you do that sort of thing regularly, you'll likely get a phone call from your bank, asking if the transfer is legit. At least that's how I've seen it done in Germany.
This type of system looks like somewhere that a blockchain could be genuinely useful.
Each of the trusted banks could be given access to the blockchain (rather than needing proof-of-work) and it would work as a distributed ledger without the need for VocaLink as a trusted intermediary.
Of course the question is how the costs of running VocaLink compare to those of running a blockchain type system.
A 'blockchain' without proof of work isn't a blockchain and would be no different than the system described. Someone or something has to arbitrate to prevent cheating. In the case of this system it's Vocalink in the case of Bitcoin it's the proof of work.
The advantage of using a trusted intermediary over blockchain technology is in bandwidth.
With blockchain technology you have multiple copies of the transaction ledger. Each transaction is recorded in every copy of the ledger. This multiplies the required bandwidth to keep these ledgers up to date. This creates a scalability problem, which is a problem that cryptocurrency developers are actively working on.
Compare this to a centralised system and you can see that the bandwidth to keep the banking systems in sync is far lower.
Blockchains have many advantages, but they aren't perfect, you effectively give up some efficiency for the advantages of decentralised trust. Considering the volume of transactions these banks deal with, they can't really give up on efficiency without impacting their bottom line.
While bitcoin is very small compared to banks and credit cards, at this point it is definitely cheaper to send bitcoin than to send Visa money. How it would work if that blockchain was scaled to the level of VocaLink I have no idea about.
No, in terms of the overall cost of operation of the system, bitcoin is most definitely not cheaper. Transaction costs paid by the users are low because of the inflation subsidy paid out to the miners.
In terms of overall costs, the bitcoin mining network alone (i.e., ignoring the cost associated with running all the full nodes, the underlying network and so on) costs $1MM per day to process a measly 100k transactions.
The 'cost' of bitcoin the system, is in the inflation of its money supply. That's indeed about $1m a year. (let's not try to do an equivalent calculation for the many billions of dollars of value that are lost from dollar inflation per year).
But recognise that it's $1m a year whether there are 0 transactions or 1 trillion. It's not a transaction cost, it's not related to the amount of transactions. It's a fixed system cost in the form of inflation. Calling it a transaction cost is misleading straight away.
The actual transaction costs are a few cents or so on average.
Of course, it's still costing money, but not to the person making the transaction. After all, if I send you a bitcoin and you forward it, you pay 5 cents. You don't pay for any inflation, only bitcoin holders do, which don't have to necessarily be those who transact. Similarly I, at times, make payments in dollars on dollar-denominated financial systems. I pay transaction costs, which are completely separate from the cost of dollar-inflation which I don't incur as I don't hold my wealth in dollars (european here). These two things are not the same.
Do bitcoin holders lose value due to bitcoin inflation in the form of unrealised gains? Absolutely, but then also recognise it's the best performing currency of the past 5 years, or indeed last year, and that they don't really care. Further also recognise that in the code of bitcoin it's written that the inflation will permanently drop to sub 1% levels pretty soon, a level of inflation lower than any major currency.
Actual transaction fees will probably rise somewhat to compensate for mining rewards dropping over time, but not by much. For one miners are deemed to be overcompensated from the perspective of the level of security they offer, and if you scale transactions by 10x or 100x (which from an economics point of view is pretty trivial, although the political ramifications of bigger blocks aren't) you can keep the transaction fee really low while massively scaling fee rewards to miners, further compensating a drop in mining rewards. (and if bitcoin doesn't scale, who cares if it's economically sustainable, if it doesn't grow then it'll stay trivial and I couldn't care less).
The cost to secure the system is orthogonal to the cost of processing transactions and rises and lowers proportional to coin price, providing a level of security commensurate with the market value of the thing secured.
The cost per transaction is simply a function of the rate limiter that is attached to Bitcoin. Bitcoin could secure many more transactions per second if the rate limiter was removed.
> a measly 100k transactions
As I type this the network is averaging ~12000 txns per hour, or 288,000 per day, FWIW.
12,000 transactions per hour translates to 200 transactions per minute or 3 per second. However, you're being generous here because what you're suggesting is what it currently does at best, when in reality it is anywhere between 1 and 3 transactions per second, meaning that it is doing anything between 86,400 and 288,000 per day--that's a large spread.
Visa claims it can do 2,000 transactions per second or 172,800,000 per day and Paypal suggests its maximum is 115 per second or 9,936,000 total per day [1]. At best, Bitcoin is able to handle 3% of the volume that Paypal is able to and it doesn't even register as a blip when compared to a single major credit card.
If we continue to read the link I cited for those numbers, we get these details:
>Let's assume an average rate of 2000tps, so just VISA. Transactions vary in size from about 0.2 kilobytes to over 1 kilobyte, but it's averaging half a kilobyte today.
>That means that you need to keep up with around 8 megabits/second of transaction data (2000tps * 512 bytes) / 1024 bytes in a kilobyte / 1024 kilobytes in a megabyte = 0.97 megabytes per second * 8 = 7.8 megabits/second.
>This sort of bandwidth is already common for even residential connections today, and is certainly at the low end of what colocation providers would expect to provide you with.
If we were to expect that everyone was to get onboard the blockchain, we would have to assume that we're all going to start sucking up 0.97 MB per second, or about 82 GB a day. This would mean that in a month, one would use just about 2.5 TB of bandwidth. If the average residential user were to want to transfer 2.5 TB for just a blockchain (ignoring modern life's pleasures like Netflix and other streaming services), you'd have to find an Internet service that would not impose a usage cap. As it stands with Comcast, if you exceed 300 GB, you'll get charged $10 USD for every 50 GB you use [2], meaning that a month's worth of transactions will cost you just about $450 on top of what you already pay for the privilege of having access to a blockchain.
This doesn't even take into account that transactions are replayed once confirmed so those numbers could end up even higher if the whole protocol isn't changed. Heck, I am not even taking storage into account which is a different problem all together.
The idea that blockchains are going to be the future is pure lunacy. It's either going to be limited to data centres that can handle this load or it's not going to be used at all. It has no future for the general public and is part of the reason why Bitcoin in itself is not practical.
First off, the numbers I cited were not theoretical, they were the observed network run rate at the time I posted.
Secondly, Bitcoin doesn't have to scale up to Visa levels, at least not in 2016. In 2016, it just has to scale up. And there's plenty of room to scale up.
Bitcoin has a growth plan that subsidizes the expansion of the network (via inflation and adoption) for many more decades. In two decades, the Moore's Law equivalent of a 1MB block size is a 16GB block size. Even without additional scalability, Bitcoin can process a lot of transactions with 16GB blocks.
No, in terms of the overall cost of operation of the system, bitcoin is most definitely not cheaper. Transaction costs paid by the users are low because of the inflation subsidy paid out to the miners.
Now compare that to the subsidies in the form of bailouts to banks, and we'll see what's cheaper.
Yes, I'm being facetious, but my point is that if you want to include such costs on one side, you must do the same on the other.
Should we also then count the amount of money that are lost to bitcoins being stolen due to malware, poorly written private key generators, exit scams and so forth?
> Net settlement is used because it’s more efficient - it only requires a few hundred entries in the Bank of England’s ledgers each day for potentially millions of payments.
The banks still have to process millions of payments between them.
But they also have to process the BoE payments - which is an added overhead.
The only real benefit is confidence, because the BoE effectively acts as escrow for all parties. So no one has to worry that settlement won't happen.
From the user's POV, it's not a bad system. It's vastly better than the situation ten years ago, when you literally had to wait a week for a cheque to clear - because the receiver had to validate it, and then post it back by snail mail to the originator.
However, some transactions still use that system. I recently closed a savings account and could only transfer the money by physically taking a cheque from one bank to another, and waiting a week.
Basic transaction processing should really be part of the national (international?) infrastructure. It would be hugely beneficial to all kinds of businesses to have a simple, secure publicly available service for moving money around, at all scales from microtransactions to many millions - ideally linked to a free no-credit-offered cash account for everyone.
Anyone who doubts why something like Bitcoin would be of use in banking should read the part about net settlement and counter party risk.
This article describes the system for moving money within one country but similar mechanisms exist for moving money internationally. Imagine the counter party risk involved between banks who are governed by different central banks in different countries half way around the world. Bitcoin removes the counter party risk in transfers by making settlement instant per transaction instead of net daily settlement in traditional banking.
The reason this is important is that these transfers revolve around credit and when there is a banking crisis and everyone suspects everyone else's credit worthiness then payment systems can break down.
"Instant." I just need to wait for the transaction to be finalized in a block, and then wait for enough blocks to be reasonably sure there isn't a longer chain elsewhere. I'm sure that won't take any time at all. /s
Don't forget there is still counter-party risk on the side that is sending Bitcoin in exchange for goods as well.
You illustrate the misunderstanding a lot of people have. You are conflating the completion of payment between end users with the settlement. In Bitcoin they are one in the same. The issue is not whether the payment takes 1 minute or 20 minutes to complete it is whether settlement is incidental to the payment or deferred. Deferred settlement creates credit risk.
The issue of risk of non delivery of goods is one that is a insurance service someone provides on top of a payment system and isn't particularly relevant to this discussion.
Physical exchange of cash and Bitcoin are the only two payment systems that I've ever heard of that don't have counter party credit risk in some form.
The OP is pointing out that bitcoin can take hours for your transaction to be included in a block. So it's far from 'instant' payment or settlement. You then have to wait for several block confirmations to be sure that your transfer took place.
Currently, people are reporting three or more hours wait to get a transaction on to the blockchain, because bit-coin has a capacity problem.
Cryptocurrencies reduce (but hardly eliminate) counterparty risk in exchange for an increase in systemic and personal risk. The dominant financial markets have exhibited a preference for reducing systemic risk over other forms of risk. I tend to think they have made the right trade-off. I have not seen a convincing argument for the alternative.
The security problem in a Bitcoin world is real though: The "instant" settlement is equally instantaneous, and equally non reversible, when someone has access to a private key. At the same time, if I lose the key, the coins are gone.
So instead of being afraid of everyone else's credit worthiness, we now need Fort Knox level security, and any breach of said security means losing everything, permanently. It's like keeping savings inside a mattress, except people can use automated to try to hack into everyone's mattresses.
You can have a different opinion of course, but seeing how even Bitcoin exchanges get hacked all the time, it seems to me that the traditional banking system is far less risky.
The difference is you have no control over counter party risk you can only choose to accept it or not. You can do a a lot of simple things to prevent your Bitcoin from being stolen. The security problem with Bitcoin is largely a myth boosted by people and companies that were paying little to no attention to security or who were outright dishonest. People who kept their Bitcoins on deposit with exchanges. didn't own Bitcoin they put themselves in a position of being a Bitcoin creditor of an exchange.
Regularly improving regulatory requirements protect the average person on the street from the majority of material risks. Cryptocurrencies have no such protection.
Banking systems were not forced on the world; they evolved to solve real problems, and continue to evolve. It's is unreasonable to dismiss the structure of these institutions without a deeper discussion considering the reasons for complexity and where the industry is headed.
I believe that cryptocurrencies may present some improvement in the status quo at some point in the future, but not until there is more regulation (through government and/or through private contracts enforceable by civil law).
So instead of being afraid of everyone else's credit worthiness, we now need Fort Knox level security, and any breach of said security means losing everything, permanently. It's like keeping savings inside a mattress, except people can use automated to try to hack into everyone's mattresses.
No, you just need the mechanism we generally use when our assets might be stolen or lost: insurance. This is also one of the services provided by banks, in that bundle they call an "account".
Settlement would not be instant - blocks would still need to be validated multiple times before that money would be cleared for a new transaction. So instead of the current system of "net" settlement where the net value of all inflows and outflows is reported to the banks 3 times a day, there would be constant individual settlement.
Settling each transaction individually decreases the risk of double spend and counterparty risk (exponentially with each additional validation), but adds latency between every single transaction to the network. Instead of 3 "spikes" of latency throughout the day, you would have billions of miniscule "drops" of latency added onto the transactions.
It also introduces a new fee structure - how do you decide validation priority when you have billions of transactions to process and check? In the bitcoin protocol, a fee is built into every transaction as a percentage of the transaction amount. The miner that verifies the transaction by performing the necessary proof of work gets to collect the fee. Thus the miner has an incentive to verify larger transactions before smaller ones.
In an interbank clearing scenario there would be no explicit fees because the banks would be doing the validation themselves rather than using a distributed network of miners, but the banks would no doubt prioritize larger transfers first. This would make micropayments hard. I'm not sure how a blockchain would get around this, unless there were multiple different chains for different sized transactions?
My friends know my mobile number. When they want to send me money, then I have to give them my sort code and account number. Having a mapping from mobile number to account credentials seems sensible to me.
I'm set up on PayM, but no one else seems to use it.
I love it, but find it takes around the same amount of effort to send money by PayM as it does to send it by regular bank transfer to somebody already set up in my mobile banking app (my main use case is usually sending smallish amounts of cash to my kids, like a modern-day Al Bundy). PayM could do with a really nice streamlined app of its own, rather than being buried deep within each of my banks' own apps.
Here in Hong Kong we can make direct account transfers at the ATM, though you still need to know the recipient account number, after you enter the number it will show the recipient account name (with some chars masked) which is always a nice confirmation that you've entered the right digits.
So everything seems to go back to money in accounts at the bank of England. Where does that "money" come from? How are there non-zero balances there? What stops someone at BoE from just changing a balance?
I guess changing an account balance without a corresponding transaction would make automated checks (accounting verification) fail. But then we get back to the question of how any money got in the system in the first place.
The money in accounts at the Bank of England is created when the BoE buys assets and it is destroyed when they sell the assets again - traditionally, those assets are mostly bonds issued by the treasury (or repurchase agreements or other derived stuff).
The BoE does those buys/sells with an eye to ensuring that the inter-bank short term interest rate hits their target interest rate set by policy. The whole connection is pretty well explained by the modern monetary theory school of economics.
What stops someone at BoE from just changing a balance?
What stops people from carrying out fraud elsewhere? A system of security controls and reviews. The high-value end-of-day transactions may well be manually confirmed at both ends.
How did it get in the first place? Ultimately, deposits; dating back to the establishment of the bank as a credit management vehicle for the government when it would have been deposited in gold.
The BoE may also issue loans, in its "lender of last resort" role.
No. If their transactions add up to a net outflow, banks use the money that is already in their BoE accounts to make transactions in favour of the BoE accounts of other banks or the FPS (those where the net outflow went to).
Since this does not change the total amount of money at BoE accounts, it does not affect the parent's question about where that money originally came from.
You mean that's what made it so hard to get into bitcoin in the first place, preventing its wider adoption? I know when I originally bought some bitcoin (back when it was ~$3/btc) it took WEEKS. The US govt hadn't yet said 'we won't kill you if you follow the rules and work as a money-handling institution' so I had to create an account with Dwolla (badass service that needs to see more adoption), which required the 3-day wait to verify my bank account, then transfer money into the Dwolla account, which took another 3 days, then transfer from Dwolla to the exchange (MtGox but I luckily did not let MtGox hold my coins).
Not too long ago, there were companies formed that used bitcoins faster payment clearing to offer faster processing to some sort of trading companies, I remember reading about their IPO. That was before the time for bitcoin transactions to clear started growing significantly... according to an article I found on HN a week or so ago, that's what's going to finally kill off bitcoin. Due to not increasing the block size, either wait times or processing fees will keep growing steeply.
I made a credit card payment last Thursday (1/14) in the mid morning, maybe 9:45 AM. Ideally this should happen pretty quickly, but I know in the US the infrastructure just doesn't match my current expectations. Seemingly there was zero movement until my credit account was credited the payment Friday afternoon, but the money was still in my checking account (no holds or pending transactions).
The weekend goes by, no movement. Monday (a bank holiday) comes and goes, as does Tuesday. I get a text message early this morning (~6:45 AM) that there was a large withdrawal from my checking account - the payment showed up! Nearly three full business days before the money was actually moved, and as of right now it's still a pending transaction.
The cynic in my wants to think that it's so people who don't pay attention to their finances are more likely to overdraw/double-spend the money, but part of me thinks it's just because the US infrastructure around banking and payments is so old it just isn't capable of anything approaching real time transactions. I would love to see a logistical/technical explanation of why it takes so long for this type of thing in the US.