CTO of Modern Treasury here. We're very happy with the quality of the client libraries being generated by Stainless. It also integrates nicely into our workflow, we've got the releases almost fully automated whenever new API routes are added or changed.
It was also done in The Animatrix [1]. In order to defeat the robot uprising, the world agrees to block out the sun and starve the robots of solar power. It also backfires on them.
I'm sure everyone's setup is different but I did this for about 8 years and had to stop recently due to a variety of problems. The first being the lack of support for group messaging. I couldn't send group messages at all but what was even worse was that when I was part of group messages I would receive the messages individually as if the person was texting me directly. My system could mark them as being group messages but I couldn't see the other recipients so there was no way of knowing who else was in a thread until other people started texting and then could piece together the group from context.
Also some services straight up refuse to send SMS to cloud phone providers meaning you can't sign up for certain services that needed a verified phone number (unless they had an option to receive a call with the verification code which worked like 25% of the time).
Dialing was another huge issue, you can somewhat intercept outbound calls on Android but the system is buggy so I had to find other methods. Since I had integrated my SMS/MMS messaging with Slack (one slack channel per phone number) I created a /dial command that would call my phone and then when I answered it would transfer me to the person I wanted to call.
Happy to answer more questions about it but I highly recommend people think about all the consequences before moving their main number over.
Modern Treasury (YC S18) | Software Engineer | San Francisco | Full-time | ONSITE
We're looking for Full-Stack Engineers to join our Engineering team. In this role, you will build innovative payments products that delight both engineering and finance teams. As one of our first engineers, you will help shape the engineering culture of a fast-growing startup.
On the consumer banking side I would agree with you, not many individuals have complex enough banking needs where programmatic access would be a value-add. However if you look at businesses, any company doing more than (let's say) 50 bank-to-bank payments a month I think would benefit from being able to automate their bank account interactions in some fashion.
Modern Treasury is looking for a Fullstack Engineer to help us automate the world of RTP, ACH, Wire, and Check. Currently our platform supports 5 major commercial banks in the United States and we plan to double that in the next 6 months. Fullstack engineers who join the team will be responsible for designing new features and implementing them into our web application and API.
On the bank side, one of the main providers offering RTP payments to businesses right now is JPMorgan Chase. If you have a commercial account with them, you can originate RTP payments.
Historically Americans have been wary of handing out their bank account information because that's all the information needed for a bad actor to issue an ACH debit and pull money from your account. The NACHA guidelines have very strict rules around this and the payment protections are rather strong but it's still a pain to deal with as a consumer. RTP itself is non-reversible so when someone sends you an RTP payment it clears instantly and can never be pulled back as it can with Check and ACH payments.
"because they can" is probably the best answer. Before RTP, which is still rolling out, wire tranfers were the only way to do same-day, non-reversible, high-value payments. On occasion we also see that wire transfers being sent manually need what's called "repair", as in the sending party didn't put enough information in the wire so the sending bank or receiving bank have to go get a human being to figure out what went wrong. Repairs and rejects add to the operational complexity of wire transfers and probably contribute to the higher end-user cost of sending one.
CTO of Modern Treasury here. Banks are actually starting to setup a new payment system between themselves called Real-Time Payments (RTP) which has a lot of the same benefits as wire transfers. RTP is 24/7, instant, and (from our experience) much cheaper than wire transfers. It's starting to roll-out across more banks and currently ~50% of bank accounts can receive RTP transfers [1]. I just cashed out on Venmo the other day and their instant transfers are going over the RTP system. Other than coverage not being complete, one of the main downsides is the $25,000 cap which means that for higher dollar volumes people will likely choose a wire. If you're sending $1mil, then the $35 wire fee doesn't seem like so much in comparison.
Totally agree on the interest use case, that's exactly where precision beyond 2 decimal places is needed. For payments specifically it makes sense to keep it at 2 because all the payment systems in the US have that precision. When we do build support for ledgers we've considered a few approaches for how that might be serialized. For example we sometimes deal with MasterCard data that tags every amount with an exponent field so something like 1.2345 might be serialized as
CTO of Modern Treasury here, like the other replies said it's much safer to use integers so we can bypass all the complexity (and gotchas) of floating point.
The lack of acks is why most companies receiving money through ACH will "season" the transactions for a set amount of time. Most of the returns occur in the first 3 business days so most seasoning periods are just around that long. The reality is you can receive a reject up until (I believe) 60 days after the transaction date. I've seen a lot of companies be a little smarter here and reduce the seasoning times for repeat users using the same source bank account. It is a fascinating system to work with every day. Wire transfers are their own bundles of fun too.