Hacker News new | past | comments | ask | show | jobs | submit | saarons's comments login

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.


Big fans of Vanta over here. Compared to everything else in the market, they were clearly the furthest ahead for our SOC2 needs.


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.

[1] https://en.wikipedia.org/wiki/The_Animatrix#The_Second_Renai...


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.


> 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).

I've ran into the same issue with this on Google Voice. Though sometimes I wonder if I could have gotten the best of both worlds by just porting a number from a traditional carrier to Google Voice/Twilio.

Are these kinds of checks only against the number itself? Or is there some kind of dynamic registry?


Google Voice has been my primary number for about 10 years and it usually works.

My main concern is what to do when Google kills it.


"Are these kinds of checks only against the number itself? Or is there some kind of dynamic registry?"

In general it is much simpler than that. These companies are sending you these SMS messages not from a "normal" phone number (xxx-yyy-zzzz) but from a shortcode (xxxxx). The "from" is a shortcode and only mobile numbers can receive SMS from shortcodes.

So if your number is not a "mobile" number, you might still receive SMS from other real phone numbers, but you cannot receive SMS from shortcodes.

Twilio, for instance, does not provide mobile numbers. Period. So even if you port a mobile number to twilio, as soon as it is theirs, you cannot receive SMS from shortcodes.


Your assertion that only mobile phones can receive SMS from shortcodes is not true in general, and additionally many verification SMS are not sent from shortcodes.


Only true mobile phone numbers can receive SMS from shortcodes.

Here is a list of carriers that are properly registered to receive SMS from shortcodes:

https://usshortcodedirectory.com/faq/what-wireless-carriers-...

"... short code carriers have arrangements to exchange messages with mobile phone numbers only ..."[1]

[1] https://support.twilio.com/hc/en-us/articles/223133447-Not-R...


I guess this is a US thing, then. It's definitely not true in general, as I said.


I’m almost certain the check is against what the number is behind. Also the opposite situation - Google Voice to carrier would result in issues if carrier to GV was fine. Not the case however.

The number needs to be non-VoIP. Off the top of my head, Uber, Lyft, Craigslist all require non-voip which means no Google Voice.


They have databases that they look up, but they're notoriously inaccurate. If you can use a number from another country (not always possible since some services require an in-country number, but a surprising number don't) you'll often find it works better, especially if you choose a country where the database provider might have less access to information about which ranges are assigned to which providers.


I have a number in Google voice that I ported from a regular old T-Mobile SIM years ago. I haven't seen many that won't send me an SMS message, but when I do, they are usually banks. I don't think it much matters where the phone number originates.


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.

https://angel.co/company/moderntreasury/jobs/617123-full-sta...


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.

Disclosure: I work on banking APIs


And I would humbly ask for someone to think again about the regular people on a more pragmatic or tech-savvy end. My banking is relatively simple, and yet many of my needs are not covered by any existing solutions. The absolute basics I want is an API access to my current per-account balance. Another step would be programmatic access to per-account transaction history.

I don't want to use banking apps and sites daily, they all offer garbage UX that's designed for upselling credit cards, consumer loans and other financial product. What I want is simple API access. I can take it from there, and do a better job than banks do, because my own incentives align better with my own interest.


Modern Treasury (YC S18) | Fullstack Engineer | San Francisco |ONSITE | Full-Time | https://www.moderntreasury.com

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.

Our stack: Ruby on Rails, React, Postgres, Redis, AWS, GitHub, Buildkite.

Apply here: https://angel.co/company/moderntreasury/jobs/617123-fullstac... or reach out to me sam [at] moderntreasury.com


"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.

[1] https://www.theclearinghouse.org/payment-systems/rtp/institu...


Thank you for the RTP information! Had not heard of it yet. The fees look very reasonable ($0.01-$0.045 depending on type of transaction) and they provide a level playing field (flat-fee, no discounts for volume)

I also heard someone say at some point that Americans are very wary of having people transfer money to their bank account. Not sure what the rationale is (maybe taxes or afraid of criminal money?) but I was wondering if you have heard this and if so, whether RTP has some protections or safeguards against this?


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.


You hand out your bank account information every time you give somebody a check


And indeed that's one reason (of many) I don't like to write checks. But I'd still argue that the threat model from giving a physical check to someone you know or do business with is different from linking your bank account with some online service like Venmo, where any mass breach or vulnerability might result in a wide array of people now having access to my banking information. And even if my bank covers me in the case of fraud, they don't compensate me for the domino effect problems that can come from having bill payments bounce because the account was emptied.

To be clear I'm not arguing that this is a good system, but as long as it is the system we have, it's wise to limit who you give your banking account information to, regardless of channel.


This is exactly why Donald Knuth doesn't give out checks

https://en.wikipedia.org/wiki/Knuth_reward_check


Many banks have different values for the check MICR account numbers vs ACH routing purely to avoid easily spoofed ACH requests.


my bank prints out paper checks but they seem to xfer the money through another company. money leaves my bank account, but the checks, when delivered, have a completely different routing and account number. doesn't matter to me, but I had a paper check payment I needed to return and the local branch couldn't help me at all - the floor guy there couldn't even understand my situation. there was an 800 number on the check to call and I explained and they cancelled that check.


> I also heard someone say at some point that Americans are very wary of having people transfer money to their bank account.

All it takes to extract money from my bank account is the routing and account numbers. Print a fake check with that info, take a couple crappy photos with one of those mobile deposit apps, and boom my money is gone. This happened to me just a couple years ago. The signature on the check was literally "John Hancock." Perhaps things have improved in the past couple years, but I doubt it.

As for replacement programs, I trust banks no further than I can throw them. You want me to sign up for Zelle, or whatever new money transfer program is? What's the catch? No way I'm trusting any program introduced by a bank.


You can't transfer money between banks in US Dollars within the US for free?

We really are blessed with SEPA¹.

Still, a few cents sounds at least reasonable.

1: https://en.wikipedia.org/wiki/Single_Euro_Payments_Area


Most times, the financial institution will eat the ACH fee, so to the customer it looks like it's free.

SEPA also doesn't mean that the transactions are free, either. According to a third party transfer service (https://transferwise.com/help/15/paying-for-your-transfer/29...) there might still be some fees from banks.


If you do commercial SEPA Transfers, yes there are fees. If you only do push transactions (ie, customers sends SEPA transaction to you), it's largely account management fees.

The pull transaction (SEPA Debit) isn't free, you can buy transaction packets (usually around 5-15€ per 1000 transactions) as well as paying a fee on monthly cash inflow (usually around 0.1-0.3%). Honestly, it's peanuts.


Naturally the UK banks found a way to charge consumers for SEPA payments.


SEPA can be free for customer but participating banks and payment institutions pay per transaction.


I had this random thought, I wonder if it holds water:

The EU states are (fairly) confident in their status as independent countries, and thus dare subject themselves to and implement such things as SEPA.

While the U.S. is a single country, the states within are not independent countries and, very aware of that, try to defend their independence within the union at every turn.


I'm not sure it's the independence being defended so much as local grift of one form or another.


There's same day ACH, but I have no idea how widespread it is yet:

https://www.nacha.org/same-day-ach-resource-center

Anecdotally, I recently moved my banking to a discount broker and my paycheck is now credited to my account the night before. I don't know if that has anything to do with same-day ACH.

Also anecdotally, Ally takes 5 business days (!) to open a CD via ACH even for an already verified bank. Definitely faster to have a checking/savings account with them, wire in the funds, then open the CD from checking/savings which is instant.


Businesses use ACH extensively to pay each other same-day (and debit consumer bank accounts). But it has never caught on for consumer "push" payments.


One reason why ACH is tricky with consumer accounts is that there are LOOOONG reversal windows (~30 days) whereas the business transfers ("Corporate Credit and Debit") are final in 24-48 hours.

That means for consumer accounts there's a ton more risk of things going sideways well after the money has moved on.

(Source: possibly outdated circa 2011 NACHA rules and transaction types)


Is pull a totally different process? I’ve noticed for pull you have to authenticate the account (usually) with the “verify the two small deposits” dance while push will sometimes let you skip that.

In fact, I just called Citi earlier today because I’d closed a CC with them and had a credit. The CS rep asked for my routing and acct number and without even verifying it with me immediately said “you’ll see the credit in a couple days.” I asked her to verify the account number and she said “I’m sorry but the number is no longer visible to me but rest assured I sent it to the correct account.” So if those funds went somewhere else I suppose I’ll never see them?

I was also able to establish the ability to wire from my discount broker today to another checking account I have without performing any verification of the destination beyond providing the routing/acct number.

I have a feeling I actually don’t want to know how this all works...


If you don’t get the money you’ll call up Citibank again to complain and they’ll take the hit to their operational losses budget [0], which happens infrequently as a percentage of transactions but quite frequently over the totality of the system. That’s what the budget is for.

[0] Contingent on the transaction going through and not being reversible, which can happen for many reasons (staleness by the time you report it, disinclination of someone who enjoys Monopoly to repay Bank Error In Your Favor, CS staff not having a button that reverses the transaction, Citi’s ops team [1] considering it beneath their notice, etc.)

[1] I oddly enough know the name of their SVP in charge of this team because Citi escheated a check due to me to the state of Illinois back in 200X. Illinois told me they had insufficient information to determine that I’m the same Patrick McKenzie so they want said SVP to file a report on my behalf. I assess 80%+ likelihood that they’ll comply. This is boring inside baseball mostly meant to underline the fact that BigBank actually does have people with names and addresses who deal individually with transactions according to some fairly involved business processes.


> If you don’t get the money you’ll call up Citibank again to complain

I hope not. You can't imagine how annoying it is to get them on the phone. Well actually, you of all people probably know exactly how annoying it is. But I'll recap it anyway. First, when you login to the web site to access your closed account to check the statement, the 1-800 number displayed is for card activation only. Go to main web site, dig up correct number. None of the usual tricks (wait in silence, try 0, try 9, ask for an operator, ask for customer service) will bypass they infernal voice response system. Even "close account" is automated now. I guess they don't care about retention.

While I'm griping, the account has been closed for more than 90 days. Are they required at any point to send me a check?


Are they required at any point to send me a check?

They're required to do what they promised to do in your Deposit Account Agreement and/or are required to do by state law. In some states if you take no action to recover it they will be required to "escheat" the money to the safekeeping of the state treasurer to await your eventual claim for it.


For the better since ACH is woefully insecure.


Tbh there isn't much security in SEPA either. The only reason SEPA Debit Fraud is rare is because A) it requires you having a bank account with a verified address and business registration and B) the bank is liable if the vendor goes fraudstering. The bank gets the money from the fraudster or they loose it.

You can also easily block or reverse transfers either in general or for specific merchants including down to blocking only weekly payments under 50€ from vendor X if you want to be really specific.


Secure enough to process $50 trillion in 2018.


> Secure enough to process $50 trillion in 2018.

How is that any indication of its security?


It is an existence proof that the security is good enough to get the job done and keep losses to an acceptable level. If it was truly "woeful" enough to actually matter then an alternative with better security would have displaced it by now.


This is overly simplistic and assumes an open market witn no barrier to entry for competitors, which is not the case.

It’s like saying the people of North Korea believe their government is good enough to get the job done, otherwise KJU would have been displaced by now.


It is a high indication of many people considering it secure enough (for their respective business case)


If I produced applications with that level of security, i would be unemployed.


> my paycheck is now credited to my account the night before

Some "nice" banks always do this, like USAA.


Sad part that I've seen... worked on an implementation of Visa push payments at a TPA/ISO (I think it was formally called something else by Visa [Visa Direct?]) - it was designed as a real time payment system to make small payments to vendors or contractors. In order to settle everything at the end of the day, we were using ACH and wires behind the scenes to re-balance the source accounts. It was really comical IMO . I know progress has to start somewhere but it just felt like we were adding layers of complexity.


Is this the same thing as Zelle?


I don't think Zelle is real time. I'm curious if it's the same working group for RTP that was behind Zelle.


Zelle is roughly real time.

It is owned by the same company doing RTP.


Not correct . RTP is from theclearinghouse and Zelle is from clearexchange. Zelle came from a mix of banks trying to address only P2P scenarios. RTP goes beyond to B2C and all other combinations .


Zelle is owned by Early Warning Systems, a wholely owned subsidiary of the top 7 banks in the US. The Clearing House is a joint venture by the top 25 banks in the US.

Clearexchange was purchased by EWS a few years ago.


The times I’ve used Zelle to send money, it has been real-time.


Once I've sent money to someone a few times it's typically instant, but it isn't always.


it is not


> main downsides is the $25,000 cap

I suppose this isn't inflation indexed, so RTP will become increasingly useless over time? -- halving in 35 years per fed plans and much sooner under monetary policy twitter-proposed by the president?


We've heard (unofficially) the cap will be raised over time.


$35! No wonder everyone pays with credit cards and cheques...


If I wanted to use RTP for my business- do any third-party processors offer it already?


Paypal (and subsequently Venmo) offers it. I've "instant transfered" money from eBay sales right to my account. They do charge a 1% fee (up to $25) versus zero fees for classic ACH transfer. If I need the money right away, I'll pay the 1% but I usually can wait the couple days.


Yup. Just transferred $2K from my PayPal account (ebay sales) to my checking account. Slight clarification: PayPal caps the transfer fees at $10.


Folks do realize that paying 1% to speed up a transfer by 1-2 days is equivalent to a 180%-365% interest loan?


In many cases they’ll be paying 1% of e.g. $40 either to avoid having to think about this any more or because they have extremely toothy consequences to not having the cash today. e.g. The implicit interest rate on an NSF fee if they don’t fund the $10 overdraft currently happening on their checking account due to the rent check being deposited, which they have 3 hours to cover before the cutoff, is on the order of 3.8e200%. ($35 interest to borrow $10 for a day.)


My sense is that's the vast minority.

I think most of the % fee-based "instant withdrawals" are done without understanding the effective APR. "It's only 1%!"


Venmo used to have a flat fee of $0.25 then they changed it to 1%. I'm guessing for most people, it would never be a problem since most people are usually only sending small amounts to eachother on Venmo (paying someone back for lunch or splitting utilities) but now Paypal gets a larger cut of people doing instant transfer of things like rent payments.


I love when folks over-analyze stuff like this.

I had $2K in my Paypal account. I had about $1200 in my primary checking account. And another few Gs in savings.

I needed to pay a $2700 expense. I could have transfered from the savings, but you are restricted to the number of times per year you can do that, without penalty.

TLDR: I have no problem sacrificing $10 to get immediate access to another $2K in cash, with the thought co-resident in my mind that I do not want to incur any potential savings -> checking with-drawl penalties.

The APR in this case is meaningless to me completely. $10 for low latency access to my cash is a small price to pay, versus waiting a day or longer for slower (free) transfer methods to complete.


The only problem with trusting PayPal is you can't trust PayPal.


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.


Does RTP bypass Fedwire?


Yes and no. Banks reconcile funds via Fedwire.


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

  { "amount": 12345, "exponent": 4 }
We could do that or something like:

  { "amount": "1.2345" }


Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: