Does anyone know how this guarantees exactly zero fraud? The page just tells you to book a demo.
There are other companies that do this, but none of them also do payments. They're kinda like rebate programs where you submit your fraud to them and they pay it off like insurance. It's a lot of manual work, back-and-forth, and they end up not doing a great job. So, this is a first for the industry.
Why is our fraud detection so much more accurate? We have access to the full stack of data across checkout, payments, and the user's shopping experience, collecting 200+ variables on every transaction. Most silo'd fraud providers may end up getting 10-20 variables and have to make uniformed decisions, resulting in $10's billions in false positives (good customers getting rejected by fraud tools) in the US every year.
I once had a tracked package marked as delivered, despite the entire neighborhood being cordoned off by police with nobody but residents being allowed in. Despite proof of this, the merchant refused to accept the package was not and could never have been delivered.
However, you can't know which features carry information until you collect and analyze them. For a problem like fraud -- where "expert" input probably would not allow you to figure out which features you need ahead of time -- it was almost certainly more reasonable to gather all the data and then, after the fact, perform feature selection[1].
- Collect as much as possible
- Figure out what features are worthwhile
- Focus on those features
Our competitors have an extremely narrow lens into all the data around a transaction. We've found things that they'll never find or even have access to in the first place. Blog posts to come here as well.
In short: on this platform merchants have the ability to process a transaction that Bolt suggests is likely to be fraudulent (in effect ignoring the warning).
In a general sense, all merchants have to balance their false positive rates with their false negative rates in a way that makes sense for the products/services they sell.
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?
But the genuine holder is probably going to be blocked when they start throwing flags like that, and that's probably just standard everywhere with any type of automated fraud protection.
In both cases the vast majority of their 200 variables will look the same. The only differences will be in the IP and latency data and, possibly, the time zone/locale information if a fraudster is not being careful.
Point being is that differentiating these two cases comes down to analyzing just few bits of data, so I'm not sure why they are using "200 points" as a selling point.
I also wouldn't expect them to detail all their fraud prevention techniques in a public forum.
IMO this is a really interesting idea! Since they are also the payment processor, they have access to more data for fraud prevention, so much so that fraud "insurance" is basically baked into the rate.
Increased efficiency through data analysis, and they are passing the savings on to yoooouuuu!
This could be a paradigm shift. Very cool. The docs look good, AND it works in Canada!?! Thank you! Canada is rarely a priority for US fintec companies. Even amazon DevPay doesn't work here last i checked. Sign me up!
We'd factor this in, and it may be negative, but if the other 198 variables match up, you'll be in good shape with Bolt given your purchase behavior, on-page event patters, order details, and many other factors that are much better predictors of fraud than VPN/Country/etc.
With what exactly? 198 variables will be the same between two cases I described.
The follow up question is what your false-positive rates are. As I said in another reply - there is a set of simple and common cases when both fraud and legit purchases look the same, so by having a zero fraud rate you will be driving the false-positive rate up - and that is bad. People won't be able to pay even though they are already with a wallet in hand.
This in turn means that merchants will need to implement a fallback option to cover this risk... which is going to be PayPal, probably.
All of this is why Stripe Radar implements _provisional_ blocking. They let purchases through, but flag them for a human review. I am going to make a bold prediction and say that you will converge to the same approach sooner rather later. There's no magic recipe.
At the bottom of https://bolt.com/fraud
"MACHINE POWERED, HUMAN REVIEWED"
"Everything we do at Bolt is tailored to maximize your order approval rates. Purely algorithmic systems falsely reject good customers. Every suspicious order goes through an extra layer of human review to ensure the best results."
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 other similar reasons), you probably are much more likely to be involved in fraud from their perspective.
If you have Canadian accounts and are travelling in Romania, that's a different story.
Have you considered that discussing API design decisions regarding security in a public forum is a bad decision of your own?
After literally 10 seconds on the site, I found this: https://bolt.com/security
My concern is not a security issue or vulnerability on their site or service. I am concerned that a processes they are recommending may not be safe, and if I am incorrect (I still feel that I may be missing something), I feel that a response may be insightful to others.
Your post tried to chastise him for calling out a vulnerability, and then tried to shame him for not quietly emailing their security team. Chances are if someone were a bad actor they would have: A) seen that themselves outside of his message, or B) Found out through sheer luck and brute force
If anything, the poster mentioning it invites the team to fix it before someone exploits it. It's worse to blunder on a hole someone told you was 1.5km down the road, so hopefully they either address it or fix it
We have a server-based webhooks to create orders which is how we do secure order creation. Bolt provides a webhook (Bolt server -> merchant server) and REST APIs (merchant server -> Bolt server) to exchange data (including transaction details) through a secure channel.
Appreciate it again.
You're contradicting yourself when you also say that you charge $20 for chargebacks.
Here are a few articles with more : https://techcrunch.com/2018/01/23/bolt-launches-an-amazon-li...
There's really nothing of a sea change here, just optimization of existing techniques.
It does things like track where the mouse is moving on the page, whether someone is copying and pasting information into the fields, whether they’re making typos, how fast they’re typing, and many other factors. By analyzing customer behavioral patterns, Bolt says it has a better shot at stopping fraud than just asking for the billing address.
I wonder how this handles autocomplete? In a sense it would be a good sign if the browser already knows given and family names etc., but could that be differentiated from a quick (perhaps extension-assisted) cut'n'paste?