Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bolt: An End-To-End Payments Stack with Zero Fraud

bolt.com

Post reply on HN
Print view View original

141–150 of 154 posts

Re: Bolt: An End-To-End Payments Stack with Zero Fraud

#141

Post by joshmn »

rbres wrote: post #4
StavrosK wrote: post #2

Does anyone know how this guarantees exactly zero fraud? The page just tells you to book a demo.

CEO of Bolt here. We'll be writing more about this in the future. In short, our fraud detection is really really good (although not perfect). However, the fraud that ends up making it through the pipeline is so minimal that we cover it fully. So, for a small fee as an online business you never have to pay for / deal with fraudulent chargebacks again. There are other companies that do this, but none of them also do pa…

Have a public list of clients anywhere?

Re: Bolt: An End-To-End Payments Stack with Zero Fraud

#142

Post by rbres »

amcnett wrote: post #135
rbres wrote: post #134

Earlier quoted context omitted.

It's not zero sum if you have overall greater precision. We believe we do and have proven it across dozens of case studies. As we publish more, we hope to let data talk. If I were in your shoes, I'd be similarly skeptical. Most companies in the space overpromise and underdeliver.

I would argue it is zero sum ("you've got some fraud" vs "you have no fraud") if there is any great volume of transactions and what's being sold is valuable, and/or marketable at a black market price below retail, and/or offers fraudsters liquidity options. I am skeptical because an untrained system is going to make mistakes out of the gate, even if it's trained on oodles of transactions from other businesses. Anti-f…

We've been processing orders for a year and a half in stealth with many clients. So we have a lot of data.

The key: everyone is focused on large data sets (breadth of data). We have some of that, but not nearly as much as large processors. We have, however, much more depth (sometimes 10X-20X as much). This allows us to achieve high accuracy in short amounts of time. Often times we'll lose money in the beginning to ensure high approval rates and, in essence, pay for learning data.

Re: Bolt: An End-To-End Payments Stack with Zero Fraud

#145

Post by AdieuToLogic »

dawhizkid wrote: post #119
rbres wrote: post #118

Earlier quoted context omitted.

Hey dawhizkid - totally right. Some comments on that in this thread: https://news.ycombinator.com/item?id=16216682 https://news.ycombinator.com/item?id=16216936 We vet our merchants before onboarding and make sure to work with high-integrity companies. We monitor orders not just for identity fraud, but for merchant / collusion fraud. That being said, we can certainly make mistakes. We also end up in the red some mont…

What's the source of truth for deciding whether it was friendly fraud or not? Is it the chargeback reason code? As far I know there isn't a specific reason code for "friendly fraud" (i.e. banks are passing along chargebacks telling you as a merchant that they think it's not actual fraud) and more often than not, especially having worked on this problem at scale in the past, friendly fraud chargebacks just come back w…

In my "prior life", I can say that processors provide generic reason codes in order to mask how the determination was reached. The idea being that it helps mitigate forms of phishing attacks.

Re: Bolt: An End-To-End Payments Stack with Zero Fraud

#146

Post by AdieuToLogic »

dawhizkid wrote: post #116

Consumer identity fraud isn't the only type of fraud problem that needs to be solved from the payment processor POV - there's also friendly fraud (when the customer is actually the owner of the credit card but claims fraud anyway), merchant fraud (merchants setting up bad sites and trying to steal funds), and collusion between merchant and customer. It seems like Bolt is focused on solving the consumer identity fraud…

Other insidious forms of fraud include, but are not limited to, "settlement attacks" and "refund attacks."

Note that both do not require merchant knowledge or collusion.

Re: Bolt: An End-To-End Payments Stack with Zero Fraud

#147

Post by huhtenberg »

thephyber wrote: post #117
huhtenberg wrote: post #40

Earlier quoted context omitted.

Say, I got myself a credit card number of someone from Toronto, Canada and I am checking out through your system using a botnet-based Toronto exit node. Similar scenario, but this time I am an actual owner of that Canadian credit card, but I'm using Tor (or VPN) with an exit in Romania. Can you elaborate how your 200+ variables will be able to block first and allow second purchase?

> Can you elaborate how your 200+ variables will be able to block first and allow second purchase A Bolt employee already replied[1] with a section about false positives vs. false negatives. I can't imagine any legitimate financial industry company cares much about supporting Tor users. If your financial accounts are based in Canada but your IP traffic appears to be coming from Romania (whether through Tor or VPN or…

Tor is an extreme example, but VPNs are now commonplace. From the top of my head, we have a double-digit percentage of purchases coming from the UK done that way. Zero fraud.

Re: Bolt: An End-To-End Payments Stack with Zero Fraud

#148

Post by mcntsh »

Our team did a pretty significant integration with Bolt last year.

Their platform is solid and was straight forward to integrate with. Their development team was also extremely helpful and helped us through the process at every step we needed them. They really did go above and beyond for us.

Re: Bolt: An End-To-End Payments Stack with Zero Fraud

#149

Post by rbres »

dsl wrote: post #101
rbres wrote: post #35

Earlier quoted context omitted.

Bolt.com has a huge history, including video-sharing that may have gotten it on those types of lists several years back. We've had it for close to 3 years though.

If your domain has a mixed past, I'd strongly recommend registering a new clean domain (boltapi.net or similar) and loading all your checkout critical components from that.

Ah interesting suggestion, will consider it, thanks dsl.
Post reply on HN