What does a development environment look like, both architecturally and simply visually?
Like: Do developers spin up entire fake economies with two banks and the fed on their latop, or is it all incremental changes to individual microservices in a big permanent test setup? Do other banks / service providers / the fed run test instances of their systems with fake money for other companies to do interop with, like a "global test financial network", or do you generally test with "real" money?
What do you see on your screen in day to day developer live? Are there like dummy online banking web interfaces? Or is it all text logs?
Is it just normal software development like anywhere else, or is there anything that really sets it apart in terms of developer workflow?
Once the service provider is connected to the Fed (a somewhat complex process), it's normal software development. The client uses either MQI or JMS to send and receive messages; the messages are essentially ISO20022 XML. The development environment could be anything (any OS, any IDE). You interface those messages with your system of accounts. The Fed also provides a simple web UI and a testing network where you can test with other participants and run regression tests.
From a software development perspective, it's really quite normal.
That's really interesting. I worked in PCI (payment cards industry) and we had terminals we could relay the ISO8583 messages through, eventually opting to emulate via software for obvious reasons.
generally having to rely on a piece of hardware for high-iteration software development is very unpleasant, so my guess is they chose to abstract what the hardware would do in software for testing/development.
One of the huge pain points I was responsible for was certification of certain payment terminals. Meaning, hardcoded PANs (personal account numbers) written to magnetic stripe cards (or, worse, EMV chips) that have to make physical contact with a reader to transmit data.
Up until a point, we were able to (easily) reproduce these messages via the ISO8583 message format via software. Makes certification much more automation-friendly.
Once we got into hardware encryption/decryption via HSM devices, it wasn't as easily done.
What is normal though? From the perspective of a hardware engineer, from the perspective of a contractor or small company developer, from the perspective of a developer at a medium-sized firm, and from the perspective of an engineer at a FAANG, what is normal is different. Twitter famously doesn't have a dev environment and that's not a bad thing. That's because coordinating umpteen teams to have an actually useful dev-dev and qa-dev env costs more than it's worth, in their eyes. And then, what does normal look like depends on when, too. Local dev envs looked a lot different before Docker came on the scene.
So back to the question, what's the dev env look like? :)
In front of your eyes: TSO-ISPF for everything. IDz for the 5 seconds per month that code is actually written
Test env: Separate permanent envs. From playground where nothing matters, env with some fake data in similar databases and variants of all systems, to mirror of prod with anonymised data, then prod
There are dummy online banking web interfaces
What sets it apart is that the operating system is painful to use and never stops being painful to use. And your employer is paranoid and keeps you in a digital prison for security so very few permissions so there is no creativity or off-road improvisational innovation just assemblyline style development
>> the operating system is painful to use and never stops being painful to use.
But this is regretful, and slows down everything by orders of magnitude. One of the big problems is lack of EFFICIENT documentation/Quick Starts. The guides are labrynthine in layout, looping and colliding spiders' webs of wtfness.
Access to production and its data should be highly regulated. Ideally no dev machine has any kind of write access to prod - instead it's commit access to a (non-master) branch which needs multiple approvals to be merged into a release branch.
Access to dev environments and their local code? Who cares, let them explore. As long as all code is reviewed prior to deploying, they could even be developing on a compromised machine and the live system will still be secure.
Practically, if your dev machine was compromised by a targeted attacker, they could create commits using your identity and if they compromised another dev machine could approve those commits using their identity. Then the attack would only be visible in commit logs with low odds of discovery before release to prod.
I'd rather not have "off-road improvisational innovation" with the nation's banking infrastructure, thanks. If that's what you want to do go write another JS framework or static site generator, don't work at a bank.
Your gut reaction is disgust and I don't blame you. You could do without the insults, however. The "nation's banking infrastructure" is outdated and messy. There is no chance in the entire world to upgrade it or clean it up if we the workers are not equipped with the power to do so. A first step could be informational transparency, I would for example really like read access on other systems in the bank and not just my own. Truthfully, separation of duties in this case is more of a controlling function and less of a security function. Of course I care about security, we all do. But let's not stifle the workers that can change the system from within in such low risk work that it's bordering on fear of change. Don't insult me again on something you know nothing about and haven't seen with your own eyes.
I think anything that could be appropriately described as infrastructure could also be described as outdated and messy, so that's not necessarily a reason in and of itself to let people experiment on banking infrastructure. Are software engineers (again, the type who end up working for the federal government and banks and government contractors) any more qualified to experiment on this stuff than people who have working in banking and finance?
Are they qualified? Sometimes a fresh perspective and courage is what is actually required rather than the home blindness that comes with following the careful bureacratic method for decennia. I would want there to be at least one mechanism in the universe that willpower from the bottom to actually improve the health of the core of these old institutions and companies. There is no mechanism at all currently for the person doing the actual work to take ownership, out of passion or duty, without first climbing the corporate ladder and becoming the grey suit decisionmaker not actually doing the tinkering any more.
I want to be able to own my own risk. If I identify a team need or personal need or business need I want to prototype it autonomously and have the control over my own computer and systems to do so while following all tests and procedures. I can pass it upward for a green light while following all test and development practices. Not only put someone elses decisions into practice while being bottlenecked by guardrails. These old institutions and old companies would pay anything to have something resembling startup agility, but they won't give up any power to self-selected intrapreneurs. I say let me own my own calculated risk . It can even be calculated risk, agreed ahead of time, this happens, that consequence. Off with my head, sure, tell me the cost that comes if I fail with some freedom and if it's losing my job then I'll accept it. If it's paying out of my pocket then I'll accept it. I'm not saying be reckless or not know what sort of risk one is taking. Open the door for calculated personal risk and let me remove the appropriate part of the guardrail. What's the point of being here if I can't use my own life force to change for the better that which crosses my path. Certainly not going to waste time, just fire me or fine me, I agreed to it to do more and better work because I care, hypothetically.
I'll admit the risks that comes with more access, if the risk is uncalculated and can't be owned in scale. Don't take risks, any at all, where the worst outcome is unethical or illegal, for everything that is production and customer data, or where the worst outcome is not even understood or out of scale. So some mindfulness, yes.
If someones personal tool becomes actually useful and the person leaves, then it becomes a weak link in an already unhealthy codebase. Or if they take decisions that don't come from above and somehow have enough access to also leak customer data or cause production issues, then compliance fines could happen. Or getting hacked, or breaking laws with unlicensed software or piracy or anything else, or disrupting other teams, or causing irreversible damage or data loss. Scary, I admit it! I see the paranoia from the top and I empathise!
Let's use bottom-up freedom for replacing the infrastructure with new technology, or lifecycle treatment or archiving, not for entrenching it with new development, or just not knowing what one is doing. But let's not get paralysed with fear. The scale is too heavily tipped in one direction. Shift it in the right direction.
> I'm happy to share anything that is not under NDA.
Meta-questions that you quite possibly can't answer: broadly speaking, what parts of this system are under NDA? Why would any part of this system be under NDA? Did any government agencies impose the NDA, or was it private companies? Is the NDA intended to protect those running the system, or is it intended to protect those using the system (IOW, is it security by obscurity)?
In my line of US government coding (no relationship with this project), NDA is orthogonal to security. NDA is used to protect confidential vendor information. For example: that they have a contract with the government at all (in the case of a stealth startup), specific technical capabilities they don’t want broadcast to their competitors, the size of the contract vs. committed resources, etc
Basically everything that is not publicly documented on the Federal Reserve's website. Unfortunately, it is really common in the financial services space to overuse a NDA. Things like specific fraud safeguards, hardware information, network diagrams, etc. are all under NDA.
Is the eventual end-game that I can send money from my account at Bank A, to a friend's account at Bank B to split a check at dinner without using a third party like Venmo?
Yes, that is absolutely a use case. Similar to Venmo, there is also a Request for Payment (RFP) mechanism. I'm on the Request for Payment (RFP) Work Group that is composed of a number of financial institutions, service providers, and billers.
Netflix is part of the RFP Work Group. So presumably they are interested in offering consumers the ability to pay for Netflix using FedNow instead of a credit card. Instead of Netflix paying ~$0.50 in credit card processing fees per U.S. subscription they'll probably be able to find a bank willing to charge them < $0.25. It also gives consumers more control as they have to authorize each charge.
> So presumably they are interested in offering consumers the ability to pay for Netflix using FedNow instead of a credit card.
I do wonder how stuff like this will shake out. I will use a credit card, always, with any vendor that doesn't pass along credit card fees to the customer in some way. (Why would I choose otherwise? The credit card gives me rewards, and better fraud protection.)
But more and more, I see companies charging "convenience fees" for credit card usage or offering "discounts" for cash/debit. Hell, T-Mobile just started requiring you not use a credit card to get their $5/mo autopay discount.
So this is all cool (and perhaps would make it easier for people who don't have a credit card to pay for Netflix), but I don't see why I'd use anything but a credit card to pay for my Netflix subscription, unless they offer discounts for using FedNow. Which... they probably won't?
RFP i.e. Request for Payment is not part of this release. Furthermore there is no ETA from the Fed as to the release date for RFP.
Currently FedNow is simply a push payment system i.e. bank account holder may be able to use FedNow to push money out from their bank account to someone else's bank account.
The limitation here is the bank account holder must know the account number of the recipient. This is a huge limiter in adoption since most people don't want to share their bank account numbers and maintaining a directory of people's bank account numbers is cumbersome to say the least
Yes, the Fed is working on a directory but they have not yet announced the launch date for such a directory, not have they mentioned the index i.e. will it be phone number ? email ? something else ?
Bottom line: FedNow launch: Step in the right direction but still a long way to go
> most people don't want to share their bank account numbers
While far less common these days, people gave this information to arbitrary payees (via personal checks) for decades. The idea that it's not to be given to payers, despite it having been given to arbitrary payees, seems misguided. If someone tries to commit fraud with that number, they're probably going to get caught, making it sufficiently unlikely, no?
When I first came to USA as a tourist in 2011, one of the most amusing thing I witnessed was at a party at my Couch Surfer’s host when a friend of theirs payed back a debt by writing them a check. This cranked me up, as I had not seen a real world check in use since I was a kid in the early 1990s. I was equally surprised to learn how nobody else at the party thought anything of this. Coming from Iceland where you simply transfer them money via a bank app (or a website back then), this was my first American culture shock.
Now I live in the USA and I actually use checks all the time. I get paid via a check, I pay with checks at my local farmstand, I used to pay my rent with a check, my immigration fees were paid with a check etc.
This is orthogonal to the original point. Passing around your checking account number isn’t that big of a security risk. We do it now and banks have built guard rails in place because we do it now.
Checks are easy to use: just write a name and an amount on a piece of paper.
They’re secure: they can only be cashed by the person they’re made out to (unlike cash).
They have theoretically infinite throughput: you can write any amount on a single check.
They have extremely high latency, which is why digital payments are being preferred in many situations. But the remaining situations where checks are used high latency is acceptable or even desirable.
Australia's "PayID" system gets around this by allowing you to pay to a mobile phone number or email address (generally findable via your phone's contacts). The implementation is a little clunky, but an additional benefit is that it's a bit like DNS for your payments - you can associated those details with different bank account to redirect payments if you move.
I’m going to lose $30 a month in discounts with T-mobile if I don’t switch to debit card or checking account. T-mobile has a horrible history when it comes to security. I definitely don’t want to give them access to my checking account
Create an account just for T-mobile. With someone like Fidelity setting up a new account is a few clicks. Ally makes it pretty easy too. Then set it up to fund automatically from another account within a certain limit. Or if your monthly bill is stable, setup a schedule to fund it monthly.
What are the rights of the T-mobile customer in the USA, if they somehow do mess up an automatic bill payment?
I'm searching using the European/international term for this sort of payment ("direct debit usa") which gives me API documentation from many American payment providers, but nothing about the customer's rights. I assume it's the technical term there, and there's another term used with the public.
(In Britain and the EU this kind of bill-paying agreement has very strong rights for the payer, they can ask their bank to reverse any transaction for a long time without giving a reason. My online banking interfaces have easy buttons to do this, or to block future transfers.)
I’m not sure about ACH (directly from your checking account) rights. But, debit cards issued with the Mastercard, Visa, Amex logos give you the same rights as credit cards. Where you can get the charge reversed.
However there are a lot more knock on effects while you’re waiting for actual cash to be put back into your account than there are when you’re just waiting to get a credit card transaction reversed.
Not only can they potentially drain your checking account. They can also drain any linked Savings account that you have to cover overdrafts.
I only keep $500 in my linked Savings account to cover any of our accounts.
ACH has many of the same consumer protections as credit card networks. The window is 60 days instead of 90 days and the dispute outcome is always in your favor—merchants cannot respond to the dispute or win.
I still don’t get the phone warranty that comes by just charging the bill to my Amex card (potentially saves about $500 a year) or the close to 5000 Amex points per year (worth about $75)
"Hell, T-Mobile just started requiring you not use a credit card to get their $5/mo autopay discount."
Yes. Visited a T-Mobile store to set that up. Brought in a voided check. Said "Set up an ACH transfer, please." "What's an ACH transfer?" Took about half an hour, two rejects from the T-Mobile payment system with both me and the clerk checking the numbers, and a conversation with Bank of America customer support ("We didn't reject that, we won't see it until the daily batch.") Too many people are going to be paying T-Mobile a $60/year "convenience fee".
(Worse, BofA is apparently still charging for outgoing ACH transfers. And they're not on FedNow.)
Yea BoA is not the most consumer friendly bank. I specifically have checking accounts with 4 different banks to capitalize on the various services they all offer, and to avoid being caught by a bank run type situation (or even just a bank’s services being down for a technical reason).
If you’re looking for a large bank that has a large physical presence, I like chase more. They offer more services than BoA for free, though they don’t have a totally fee-free checking account (unless you have monthly direct deposits, or will maintain a minimum amount of money with them). Their website is much much better and honestly their cc offerings are better.
I was never a big fan of any of the smaller credit union websites. A lot of stuff still required either going into a branch or hanging out on the phone, though here’s the one place they’re almost all better: you’ll never talk to someone overseas with a local credit union, often tech support will be a real life unix greybeard, who you’ll appreciate talking to once you provide the right shibboleth. But everyone else will most likely be branch employees manning the phones when they’re not busy in the branch. So if you’re ok with needing to talk to people to perform a lot of stuff the bigger banks offer web services for, a CU is definitely a more personal experience.
If you’re ok with no physical presence, discover is a pretty good option, totally free checking, and last time I checked they gave checks for free. I got like 500 almost 10 years ago and haven’t used more than 50, so idk if this is still something they offer but it sure is nice not worrying about inning out of checks or needing to pay for them.
"any vendor that doesn't pass along credit card fees to the customer in some way"
I think every vendor passes along the fees, either in aggregate through pricing, or to the individual as a charge. At least in the latter case it is more transparant and fair to non cc users.
I moved to Europe in 2018. The banking system is decades more advanced than the US. At least where I am, no restaurant will “split a check” and one person is expected to pay. We settle the bill between each other in a matter of seconds.
Most bills are paid using this exact system. Credit cards are very rarely used except in-person. Since you have to accept (or tell your bank to always accept certain vendors) debits using this system, there’s never any surprises. You usually have nearly a week to accept a debit.
Inability to "split a cheque" is still a very annoying limitation; completely normal behaviour to do this in NZ, still moderately weird in Australia (although it's got better).
The ability to resolve this electronically rather than with cash makes it less bad, but still easier and faster to resolve it in store.
The GP shouldn't be generalizing across Europe with that statement. It's somewhere between completely wrong, half wrong and correct depending which of the 50 European countries are included.
Credit card fees that aren’t passed through to you are a bit tragedy of the commons. Probably good for them to go away. It’s fine if you choose to pay them, and it’s still worth it to you, but otherwise you’re forcing everyone around you to subsidize your credit card rewards. That’s not fair.
Alternatively, everyone not taking advantage of the credit card protections isn't taking advantage of what's offered around them. Everyone should be subsidizing everyone else, because no one should be using a debit card to make direct consumer purchases in 2023. It's too fraught with risk comparatively, and even the scummiest of the sub-prime credit cards give you a grace period to not accrue interest.
It is relevant that credit cards with good reward programs are more accessible to wealthier people, meaning that both people who don't use credit cards and poorer people with inferior credit cards are subsidizing them.
No one? That's a rather brash statement to make. Here in Ireland I can count on zero hands how many people use credit cards on a day to day basis. Debit cards are the norm in much of the EU I would assume.
Credit cards are pretty common here in AU; I don't care so much about the fraud protection, but up to 55 day interest free periods are common (if the bill is paid in full each month) and so the cards literally save me money because I earn interest on savings and/or don't pay interest on mortgage vs having to pay everything immediately.
To me I feel the money Id save on using the credit card is so infinitesimally small that it’s easily worth it to use debit for the ease of mind that everything is settled and I truly can afford everything I pay for. I also hate credit card rewards programs with a passion because they just complicate our lives to get back money that should’ve just been lower credit card fees to begin with.
The argument that you save interest on savings account doesn’t make any sense at all because I count my credit cards towards my emergency buffer. If I maxed out the credit card I would absolutely make sure to keep more money in my savings account.
I get that it’s different for people living paycheck to paycheck. But arguing that credit is a solution for the poor is a slippery slope. We should solve those problems other ways.
I use cc for literally everything but car payment and mortgage and pay off every month. The only time I pull out my debit card is to get cash out. I feel peace of mind that nothing is going to drain my bank account fraudulently, I have one bill per month to look at, and I end up with 1-2 vacations (hotel and flight) for my family each year. Seems like a pretty good deal to me.
I'm not arguing it's a solution for the poor, the absolute opposite - because I have sufficient income to pay my bills in full it just comes out cheaper than paying them with cash. It's a terrible solution _if you actually need credit_ because it typically comes with really bad interest rates.
You come out ahead because the card issuers expect to make money from you because you'll stay with them a long time so offer substantial sign up bonuses (I don't) and that you'll pay interest (I don't). There are generally annual fees, but if you ask they'll often waive them (if you spend enough, again not accessible if you're living pay to pay).
It's ~effortless (bills paid automatically in full from a mortgage offset account) and saves money even without rewards and other perks (0% loans via interest free "balance transfers").
You can get a 2% cash back rewards card and literally receive 2% of every dollar you spend back, deposited electronically in your bank account whenever you press a button on your credit card website.
Everyone agreeing to not conduct financial crime would be nice, agreed, but there would be no societal need for common law and court mediated legal relief.
In lieu of that, how would you envision any society arriving at such an end state?
> Then we would live in a high-trust society, like the United States and Europe used to be 100 years ago.
The United States didn’t even “trust” Black folks enough to allow them to drink from the same water fountain, live in the same neighborhood, go to the same school or be part of the financial system as late as the 60s.
Cool, now follow this logic and do health insurance right
The failure in your logic is that different credit cards do have different fees and that some form of consumer protection should apply to debit cards as well
... umm, no, at least in my experience. I happily ordered stuff online for years from many merchants.
I want banks and stripe and gateways and shopify and visa/mc to weed out bad actors fast.
and if some small shop starts to transact a lot, let them manage their risk, don't require consumer side credit for this.
there's already a ton of data, endless kyc/aml paperwork put on consumers and banks/gateways they should figure it out, and if someone still insists on paying hundreds of thousands on totally-free-bitcoins.top after the bank, the app, the browser, their neighbor warned them then let them. and let them try a chargeback.
Interesting, most credit cards with rewards I have seen in Aus have substantially higher interest rates which is where I assume they capture the cost of rewards back. Is that not the case in the US?
As for fairness, I agree they should go away. Companies with margin can swallow the fee, companies without could be unprofitable and make no sense if they don't pass on the fee. It's a practical reality of the dollars and cents, but it is a private apparatus we opt into so I guess we can't complain that much.
Have you looked at other systems across the world for inspiration / design choices, and if so, could you elaborate on how this system compares? For example, the use case mentioned is probably the prime use case for UPI in India, which has now been extended to become a full fledged payment network alongside CC networks etc.
"Netflix is part of the RFP Work Group. So presumably they are interested in offering consumers the ability to pay for Netflix using FedNow instead of a credit card. Instead of Netflix paying ~$0.50 in credit card processing fees per U.S. subscription they'll probably be able to find a bank willing to charge them < $0.25. It also gives consumers more control as they have to authorize each charge."
NB that last sentense. FedNow does NOT support recurring.
I had to read this twice - is it really not like in the UK? Is this the first US implementation of "Faster Payments"? Sure people in the UK sometimes use PayPal, Revolut, but most of the time its always just a friend gives (and you save on your banking app) their bank account number and sort code, and you instantly send it across. edit: with no fee
No, Wire Transfers have been the official fast settlement method in US for a while. They have a fixed fee associated but given the larger transaction amounts that people generally use it for, it's not a bad thing. Everyday consumers have their silly apps for money transfer (PayPal, Cash app, iMessage Cash). Other than that, people are just used to transactions taking 2-3 days and over drafting because they made another payment and forgot about it. Yay, ACH!
ACH has been next day for like 2 years now at least with every bank and employer I’ve used. I’m sure there’s some banks that didn’t join the next day system, but I haven’t experienced it. Then again being part of a credit union has lost a lot of its allure these last few years, so maybe that’s where you’d see that sort of thing more.
I just received a next-day ACH via Apple savings to my credit union. CUs still have their allure, I'll never get over Wells Fargo charging me fees for minimum account balances when I was 18 and working for minimum wage. What a sour taste to leave in a young customers mouth and good way to shoo them away once they start gaining some value.
Yes, and only next day settlement. Because there’s no real time authorization, payments have two business days after settlement for the banks to report ordinary failures like insufficient funds.
How quickly a bank responds in that window depends greatly on the bank. In practice at decent scale, we see banks using every possible hour of that two day window to fail transactions.
An ACH debit made on Friday night technically has until open of business Wednesday to fail.
People outside the US stopped using cheques ~decades ago. At 40+ from New Zealand I've literally never paid anyone with one and have been paid with them only a handful of times.
Oddly, given the context of this thread, the UK is an exception. Or at least it was until a few years ago (I left in 2019). They have Faster Payments, but they also still use (used?) cheques more often than any other non-US country I've interacted with. For example, a number of UK universities still do (or until recently did?) expense reimbursements in the form of paper cheques, when reimbursing people not employed by the institution. One university even mailed a paper cheque, made out in British pounds and drawn on a UK bank, to our French invited speaker! The speaker found it inconvenient/expensive to have to deal with that, but their bank was fortunately able to figure out how to deposit it.
The only time I've seen a cheque in the decade since I moved to UK has been from DVLA. They send refund as a cheque, and for relatively small amounts likely expect a significant fraction of people to never cash it in because handling the bloody things is just annoying.
My bank's mobile app supports cashing them in via camera. Niche use case, but nice to have it for this attempt at government agency nickle-and-diming the populace.
They are still in use in France from time to time. Typical use cases I have seen are security deposits, and for small non-profits to expense volunteers and getting paid without bothering with payment terminals.
You probably have a very small illegal population, here in the US, if you don’t wanna hand someone a ton of cash but wanna pay them for something and they’re not allowed to open a bank account, a check is the easiest way to give them money. They can go to a check cashing place pay the 1-3% fee and cash the check. Otherwise you’re giving them cash or doing some complicated load to a prepaid card.
I remember my father had a checkbook in the 1970's. I never had one, not sure they even exist here anymore (Belgium).
For payments to friends we use bank apps. Usually the receiver generates a QR code for the payment on their phone, which you scan from your bank app, sign with a pincode, and the payment is executed immediately. If you are not near you can also use their account number to transfer money instantly.
I got a cheque book with my first real bank account in 2004, and felt like a real grown up. In the time since, I have written 2 cheques.
However, I have cashed some cheques - a tax refund cheque and a refund for my remaining balance when I closed a utilities account.
They have the advantage, for the sender, that you can discharge your responsibility to offer a refund by sending a letter, rather than having to interact with the other party. Of course these days you could email them a link to a web form.
I am currently disputing an international payment and wire transfer (or walking/driving my happy ass to their office and paying cash) is the only method allowed by the lawyer representing me. That's at least one occasion you are not accounting for (a foreign entity that needs the equivalent of cash to proceed)
Zelle is crap. It was created by banks to skirt regulations which make them responsible for fraud. It exists to make things worse for their customers which is why they pushed people to use it so hard.
The UK and Ireland have identical banking codes (six-digit sort code & eight-digit account number) and constructed IBANs the same way (BIC, sort code, account number), but Ireland switched to using IBANs domestically, while the UK didn't. That means that you in the UK need one interface for domestic payments and a different interface for SEPA payments, while we use the same for both.
Wire transfers exist, but have a high fixed-transfer cost ($20 is not unusual).
The larger banks have their own systems that only work within the bank; some smaller banks offer systems that work with any bank that offers the same system.
ACH exists, and I've used it to move money between accounts I own, but there is some friction to set up. I don't know anyone who uses it for C2C payments.
This got me surprised too. In Mexico we are also used to giving our bank account CLABE number (https://en.wikipedia.org/wiki/CLABE) that is used to transfer without fees and instantly. Even small shops use it to get paid, friends to split dinner, etc.
Poland has BLIK, which links your bank account number to your phone number. Then, just send a transfer to the phone number instead of punching in the 26 digits of the account number.
And if you don't want to share your phone number, you can use a temporary six digit code instead.
Mostly the worst system you can imagine from power user perspective:
* banks won't let you use it without a bank app (there is one exception that will let you use only some only outgoing transfers through the web page) although it is technically not required
* giving out your IBAN is not a problem but I don't want to give everyone my phone number, and the temporary code is temporary
* don't ask what happens if you have multiple accounts and multiple phone numbers.
It sounds very much like some of the Interac services that we have here in Canada (and have had for ages). We can do what is called "email money transfer" where as long as I know your email address I can go into my bank app, transfer money to you and it will automatically show up in your bank account.
The US already has Zelle which does this. However the roll out was botched, many banks don't seem to use it and most people (including me until a few months ago) thought it was a paypal competitor - but it's actually a government based system system which renders free transfers between bank accounts (your own or others) with a cap of 3 or 5k/month.
The interface is very weird. Many people can't figure out how to use it. I ended up having to set up new email addresses and assign them to different bank accounts in order to distinguish my accounts.
> but it's actually a government based system system which renders free transfers between bank accounts (your own or others) with a cap of 3 or 5k/month.
Zelle is run by Early Warning Services [1], a joint venture between Bank of America, Truist, Capital One, JPMorgan Chase, PNC Bank, U.S. Bank, and Wells Fargo.
1) The recipient needs to download the app and sign up. How does the Payor know whether the recipient has Zelle app or not
2) Even with the app, there are only about 50-100 banks that allow Zelle transfers. If someone's bank does not offer Zelle they are directed to enter their Debit Card number using "Push to Card" to receive the funds. While the funds land up in the bank account instantly either way, some Debit Cards have limitations and will not be enabled to receive funds
3) Zelle is essentially a "messaging layer" i.e. the actual settlement happens overnight using ACH rails. As a result the sending as well as the receiving bank are taking some risk in terms of allow the recipient to withdraw money when the underlying settlement hasn't happened. If the settlement fails the receiver's bank will need to claw bank the money from the receiver
As a result there are some really low limits on daily transfers i.e. between 1-2K/day for most banks
4) Above all Zelle (like most other payment rails ) is a push system i.e. one can push money using Zelle. One may not pull money using Zelle
You’re heavily limited in terms of transfers also. I need to split my rent over several payments over several days using zelle. It really sucks compared to something like SEPA
This depends entirely on the bank. Chase, for example, has a Zelle outgoing transfer limit of $2k/day and $16k/month for regular consumer accounts. There's a higher limit of $5k/day and $40k/month for their higher-end and business checking accounts. Other banks' limits are higher or lower than that.
Interac is a company formed by the big banks in Canada to link all their networks and help insure we have uniformity. I believe it started as a way to standardize ATM machines and has grown to a bunch of other things and is largely why Canada was able to so quickly and completely adopt chip and pin and tap to pay literal decades before the US did.
Not OP, but I thought FedNow will do this on day one for participating banks. Someone correct me if I’m wrong. FedNow will also settle faster than Venmo currently does (unless you pay for Venmo’s instant settlement) because it’s instantaneous. To be fair to Venmo, their bottleneck was precisely the lack of FedNow. I assume Venmo will make instant settlement free. But they will need to add more features now that people might substitute with FedNow. Anyway, this is a big deal for Americans and was a long time coming.
From the perspective of most people from other developed countries, it’s honestly incredible that the US hasn’t already had this for years like we all have…
1) Write a physical check (2-10 days from deposit, usually 2)
2) Use ACH (a virtual check) (2-10 days, usually 2)
3) Fedwire which costs $10-$15 to both the sender and receiver (15 minutes).
There are some banks that give free Fedwire transfers, often just to higher account tiers. Fidelity Investments gives free Fedwire to everyone, though.
Tell us as much as you can about the tech stack. What is going to be able to handle truly massive volumes of transactions? Database, hardware, communications channels, programming lang, everything.
At the very least, one would hope that credentials and perhaps also certain design documents such as threat models aren't public.
There may also be implementation details or code which are subject to NDA, either from the Fed itself or from service providers such as IBM in this case. Sometimes you can get that info from a FOIA request, but that doesn't negate the fact that the employees working on the system are bound by an NDA. The FOIA has to happen and run its course.
certain design documents such as threat models aren't public
That smells like security through obscurity (which admittedly is the status quo in the banking world).
Contrasted to approaches like Bitcoin, for which full code and whitepaper are public, and which has managed to survive every attack vector thrown at it for the last decade and a half. Not arguing for Bitcoin as money here, just highlighting the diverse approaches to security and that it shouldn't be taken as a given that hiding those details makes it more secure.
Fraud detection heuristics, at least, fundamentally have to rely on security through obscurity. If fraudsters know exactly what is detected as fraud, they can avoid detection.
Bitcoin gets around this by having absolutely no fraud prevention, and just saying "lol sucks for you should've been more careful"...
There is fraud prevention (yes, you being careful, and more importantly, only doing transactions with parties you trust to reverse in the event of a mistake), you've just been accustomed to outsourcing this to a third party for some expected added value.
Using that ridiculous definition, there is no conceivable method of transaction that DOESN'T have fraud protections in place, which makes it a meaningless distinction. When people say that a system has fraud prevention methods, they obviously mean something on top of some vague notion that people shouldn't send money to people they don't trust.
LOL what? Keeping private keys private is not "security through obscurity". Or if it is then basically all security is security through obscurity.
No one is posting their private keys on github, and when they do their crypto goes poof nearly instantly. None of the exchanges publish their threat model documents. I sure as shit don't tell people where I store my private keys.
The bitcoin whitepaper and code are more analogous to the ISO standard, which is public.
I must have missed something. Wasn't the person you replied to talking about design documents? I don't think they suggested credentials like private keys should be public.
That is exactly that kind of thing that needs to be in a contract. When someone inevitably shares private keys and it results in some kind of financial loss ... who is responsible for the damages? Contracts codify the liability if it isn't otherwise defined by statute.
guess -- knowing the currently discussed threat models is a competitive advantage for the dozen fintech security firms that are in on this, and a "moat" against the other four hundred fintech security firms that are frantically trying to find a way to get inside this obviously well-funded Big Gov project.
After 9/11 everyone in the Fed working on the payments systems had to get National Security Clearance. These systems are considered critical national infrastructure. Exposing the source code will get you jail time.
Fraud and people trying to mess with the system has been a long term problem and likely always will be. The results of which can hurt people. Keeping details private can make it more difficult for those folks.
If we try to prioritize goals of a system like this... security for people should be one of the highest. I think of the middle income single parent when I envision an example of a person in this system.
> The FedNow Service requires all messages to be cryptographically signed. The service validates the signature
and association between the entity sending the message and the key used to sign it.
Hey, that's neat. I'm super curious how much the internals of this thing could be compared with something like a cryptocurrency. Are those signatures representative of the identities making the transaction? Might it be technically feasible some day for me to craft a transaction on my phone to send money to someone, then publish it directly, and have the person instantly confirm that they received a payment without needing to talk to a bank?
I'm really curious if this is what is going to eventually morph into the CBDC that everyone seems so excited about, or if that project is going to start from scratch.
I'm no expert on this so this is pure speculation, but what immediately jumps out from this document is the amount of security- and availability-critical work that depends on each member bank. With wire transfers this has historically been achieved by gating transfers behind physically visiting a branch (not universally true). The synchronous nature (recipient must confirm transaction in real-time) of transfers may also cause annoying failures when recipient banks do maintenance or something at inconvenient times.
What is innovative and/or well engineered there? Could any bank or financial institution connect seamlessly with the system? How does it handle security keys, transparency, and transaction log duration?
As I see it, the innovative part is that the service is push-only. With ACH and most other systems in the US, payees can pull from accounts, while FedNow has no support for forceful debits. That's a significant shift in the way we think about payments (for the better, IMHO). This has been done before by other service providers, but not by someone with this kind of influence and clout in the US.
Hmm, surely there's some kind of support for a pull request that has to be approved, no?
It seems like requiring the consumer to manually set up a push payment to a company would probably be annoying and error prone, compared to having them entering their details on a website and then the company requesting payment.
We already have a push system called Check 21. You scan an image of a check and it will send the money instantly to the bank instead of through the Fed. It created after 9/11, as money couldn't move when the Fed was frozen.
Super curious, were you involved in the implementation of ISO20022 from software perspective or were you more on the hardware end? Asking because naturally entire banking in US is kinda waiting to see hows its implementation going to turn out ( for non-fednow payments ).
Is there anything special about the IBM MQ implementation which makes it worth naming them? It looks like you can connect to it using AMQP so I wonder why they wouldn't just say something generic like "MQ" or "AMQP protocol".
I assume IBM Message Queue Interface (MQI) is the only supported protocol in this installation. Don't know of any other compatible brokers to support MQI.
It’s a little especially strange as IBM hasn’t exactly made a great reputation for themselves over the last several years. Name dropping IBM makes me think that the reserve is generally not confident and is ready to blame IBM for what they expect to happen.
IBM MQ has been the standard for message queues for literal decades.
Hitching a horse to a different technology platform that has only been around for a few years to complete a project that should last for many more decades would be an architectural choice that would only lead to high costs and high risk of major changes in the future and puts the whole system at risk.
There is a huge variation in "quality" across IBM's product line. There are still a few sectors where they are legitimately top-tier competitors, and there are others where they're a joke.
Half the banking sector runs on IBM and has been running on IBM for decades. They know the domain well and have legitimate credibility for being reliable. It's not comparable to some of their other markets.
Last time, a decade ago, I played with RabbitMQ and similar open source queue system they didn't handle congestion and rate limitation well (crashed). From my little experience with classical IBM systems like MQ they knew about that stuff.
I spent a couple years deploying and integrating IBM MQ, and I own a couple of services currently that interact with it. It was (just a couple years ago) and probably still is more robust than current open source solutions, as long as you weren't planning on forking the code for some very specific use case that requires heavy modification, or the more likely situation of just wanting to save money.
As far as message queues go for something like the federal reserve, IBM MQ is really the only option that wouldn't raise a lot of eyebrows in the industry. The Fed is not the kind of institution that I think people would be lenient on for being open and innovative with their software solutions, banks really need to know that this thing is going to work and they all run IBM MQ themselves already. Not to mention the integration possibilities with Db2 and IMS, which are both huge in finance.
My only complaint is that it is very expensive. That's the story with most of the kind of hardcore technical products IBM sells that are likely to wind up near mainframes. I'd imagine the Fed gets a sizeable discount though.
Being able to publicly claim your product as the one that underlies part of the federal reserve banking system has got to be worth some real money to IBM.
That's part of it I'm sure, but it's much more than just advertising. What bank is going to make a risky move to a new message queueing service to save a few bucks when all their connections with the Fed use IBM's? And the hook there goes even deeper, because all of this stuff is deeply integrated with your databases.
On the one hand, I guess. On the other hand, I have a pile of the WebSphere product stack in my life. The app server is ten times the cost of MQ. WPS is another ten times the cost of the app server. It looks cheap when you're buying the really expensive stuff!
Also if you're using MQ for things like guaranteed delivery and making use of clustering and security controls I suspect it's cheaper to pony up for the IBM software than it is to spend time messing about in the thickets of the free alternatives.
FIX is, at its core, a message queue, and it’s a free financial industry standard. And, for any serious use in which the message queueing ability is important, FIX is wildly unfit for purpose.
Seriously, a deliver-once [0] message queue between two parties is very simple, and it’s truly remarkable how severely it can be screwed up. I’ve never used IBM’s solution, but I assume it actually works.
[0] Yes, deliver-once is impossible. But arranging for a failure to result in all messages up to a point being delivered, subsequent messages not being delivered, and the fact that a failure occurred being obvious to both parties is straightforward.
I can try, but the difficulty there is that Kafka is not really a traditional message queue system and the use cases are different. In short though, redundancy isn't sufficient to solve the reliability issues inherent in financial applications and transaction processing.
If you want througput, Kafka is the better option. Use a message queue for transaction processing against a specific target, where it is a requirement for you to have guaranteed, one-time and one-time only delivery, and possibly that its secret and should only be delivered to one target. You should conceptualize Kafka as being a tool to maintain a sort of distributed, global state. A message queue is more like getting served to go to court.
Technically, Kafka is an event stream, not a message queue (this can be confusing because event streams are often implemented at a surface level like message queues). The difference between an event and a message on a conceptual level is important though. There's plenty of good literature out there if you want to dig deep into the difference.
I'm aware that Kafka is low-level (and that there is kmq, which tries to implement a message queue on top of it https://github.com/softwaremill/kmq/ ), but the exactly-once semantics seems isomorphic to having the sender and the receiver doing a 2 phase commit using the log.
what are MQ's guarantees? how are they implemented?
I think that it's a pretty handy format to be familiar with, and is quite simple to work with too.
If the Fed or participating banks decide to open up the system like European banks have done so, it can be handy to get familiar with it for us financial hackers out there!
Ironical that same system in Russia, was built (around 5 years ago) using _exactly_ same set of technologies (and many others of course). Central Banks fucking loves IBM
Man I was talking about how badly IBM fumbled the last ten years of AI between getting Watson on TV and then getting sent back to the minors by every other player. And yet here they come with a bajillion dollar government contract to keep them afloat for another 100 years. Gotta tip the cap.
What is your opinion of the FedNow Service bespoke flavor / enhanced message schemas vs what is formally defined in ISO 20022? Do you foresee any impact those differences having on how future versions of ISO 20022 can evolve? Is there an aspect of ISO 20022 you wish was different in some way?
TLDR: Nearly all payments will irrefutably settle within a handful of seconds
Strictly speaking the primary means in which money moves in the United States from a volume perspective is ACH today. That system is a T+1 day from a default perspective, but it has offered the option to same-day settle during a handful of batches throughout a business day. However, ACH is not irrefutable and so it is common to have holds associated with this movement of money.
FedNow is truly 24/7/365 and push only.
All payment flows are subject to an end-to-end payment timeout clock of 20 seconds, starting from the creation timestamp to the point at which the recipient FI (almost always really a Service Provider on their behalf) sends a formal response that they intend to accept or reject the message.
An accepted payment must then be posted to the receiving account "as soon as practicable, but no longer than a few seconds” unless there are compliance/fraud concerns.
In practice, it should rarely take 23 seconds and will likely take 1-5 seconds from an end-to-end perspective depending on the processing speed of the originator, receiver and FedNow Service itself.
Couldn't having payments settle so quickly result in increased risk of overall system instability? I don't have a specific example, but I'm thinking of things like bank run panics. I'm sure this sort of thing would have been considered, however.
Yes, it absolutely does increase the overall system instability. However, that is at great benefit to the consumer. There are some safeguards in place in the actual FedNow Service, but it is primarily up to the Service Providers to give the financial institutions tools to manage risk. This includes features like liquidity management, circuit breakers, fraud/compliance monitoring, limits, etc.
Faster settlement can also have stabilizing effects. With less money in transit there's less counter-party risk. Annoying rules like having to wait 10 bank days to spend money from a larger check you deposited can go away. The whole point of a checking account is liquidity.
I'm not sure if that's what the previous poster was referring to, but before SVB officially collapsed it tried to get an emergency loan but failed because the system for such emergency loans is slower than the systems its clients could use to transfer money out.
> And yet! Man! What the heck! A lot has been written about how SVB was a bank run for a speedier, modern age. Instead of hearing a rumor at the coffee shop and running down to the bank branch to wait on line to withdraw your money, now you can hear a rumor on Twitter or the group chat and use an app to withdraw money instantly. A tech-friendly bank with a highly digitally connected set of depositors can lose 25% of its deposits in hours, which did not seem conceivable in previous eras of bank runs.
But the other part of the problem is that, while depositors can panic faster and banks can give them their money faster, the lender-of-last-resort system on which all of this relies is still stuck in a slower, more leisurely era. “When the user interface improves faster than the core system, it means customers can act faster than the bank can react,” wrote Byrne Hobart. You can panic in an instant and withdraw your money with an app, but the bank can’t get more money without a series of phone calls and test trades that can only happen during regular business hours. And so sometimes a bank that theoretically has a lot of liquidity can just run out of cash.
"retail investors" normally refers to individuals at home and T+2 doesn't affect them because they have margin accounts.
The only limitation is that if you day trade, you'll need $25k in your margin account. If you don't day trade or you have $25k, you can withdraw $0.01 a few milliseconds after selling $0.01 in shares
You can use that, but there are pretty well understood terms in finance already (like retail investors), and probably best to use the standard if you want to be well understood.
Apologies if I’ve misunderstood you (edit: I have) but assuming you are saying that 1ms to transfer funds between banks is ridiculously slow, why do you say that?
Light travels about 300km in one millisecond in a vacuum, about 200km in optical fiber. The best achievable theoretical fiber optic RTT for NYC-LA is about 35-40ms. In practice 65ms+ is more realistic due to routing overhead and the fact that cables aren’t always laid in a great circle. This being a financial API with three parties involved in most transactions (the two banks and the fed clearinghouse) there is sure to be more than one round trip involved for TLS establishment, authentication, verification of funds and account availability etc, many of which involve traversing many inevitably complicated systems on each side. It would shock me if such a system could realistically target anything less than 500ms P50.
Not sure it's even useful to call it a "transaction" at that point, since nothing has been transacted. It feels like the difference between updating a value in-memory and committing a value to the database. Maybe you can hide the latency, but that hasn't removed the need to actually do the transaction, eventually, and now you have the added problem of managing consistency.
The problem is, which "database"? If you know the data is always going to be in the range of ~1TB, use Postgres or some other ACID database. But I don't know of any petabyte scale ACID compliant database.
Also I'm not sure if ACID is sufficient or not for banking systems.
Yes, but in addition to being ACID compliant (serializable ANSI), you need to support a million transactions per second - it’s not just about data size.
Any database easily handles terabytes, idk why that's a condition.
DuckDB and SQLite easily handle terabytes of data. They're just not so much for cloud based apps, or things that need multiusers and access control junk. They're the best choice for just about everything else though.
Was it difficult avoiding using an ESB? I've heard stories about how requirements to use those were listed as an example of an interoperable system in law and then ended up being mandated across DoD for everything.
The FedNow Service itself is the tip of the iceberg in terms of what actually happens from an end-to-end perspective.
We've been working to become a Certified Service Provider so feel free to ask me anything. I'm happy to share anything that is not under NDA.
[1] https://www.ibm.com/products/mq