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

Improved fraud prevention with Radar 2.0

stripe.com

Post reply on HN
Print view View original

41–50 of 83 posts

Re: Improved fraud prevention with Radar 2.0

#41

Post by jhca »

sixhobbits wrote: post #24

I really hope that this improves the false-positive rate, as mentioned in another comment. We've been hurt badly as a startup breaking into the US market and getting many of our genuine charges blocked by Radar (and at a "highest risk" level where it is not possible to disable rules). As a developer, I had the best possible impression of Stripe, as they provide easily the cleanest API and best documentation of any pa…

Hey, would checkout Bolt. Know the team there well, and they’re very focused on false positive reduction, which they recently published a post on:

https://blog.bolt.com/better-fraud-detection-with-bolt/

Re: Improved fraud prevention with Radar 2.0

#42

Post by gr2020 »

mlm wrote: post #2

Engineering manager for Stripe Radar here. Today’s update has been almost a year in the making and we’re excited to help Stripe businesses fight fraud more effectively. Here's more on what's new: https://stripe.com/blog/radar-2018 I (and the entire Radar team) are on hand to answer any questions you may have!

The only problem I ran into with the old Radar was a situation where a card was declined, and the customer contacted his bank to clear it up. The bank said they had no idea, they didn't decline the charge. When I followed up with Stripe, turns out Stripe declined the charge, and it never got to the bank.

Is there a way to tell when this happens in the Dashboard? There wasn't at the time, but I'm hoping this is maybe now visible somehow? It's obviously helpful to know when trying to help a customer resolve the situation.

Re: Improved fraud prevention with Radar 2.0

#43

Post by eecc »

mlm wrote: post #2

Engineering manager for Stripe Radar here. Today’s update has been almost a year in the making and we’re excited to help Stripe businesses fight fraud more effectively. Here's more on what's new: https://stripe.com/blog/radar-2018 I (and the entire Radar team) are on hand to answer any questions you may have!

What prevented you from introducing changes incrementally rather than a “almost a year in the making” release?

Edit: no polemic intended

Re: Improved fraud prevention with Radar 2.0

#44

Post by iagooar »

sixhobbits wrote: post #24

I really hope that this improves the false-positive rate, as mentioned in another comment. We've been hurt badly as a startup breaking into the US market and getting many of our genuine charges blocked by Radar (and at a "highest risk" level where it is not possible to disable rules). As a developer, I had the best possible impression of Stripe, as they provide easily the cleanest API and best documentation of any pa…

Got the some exact issues that you mention. Also in the US, not that much in Europe.

Given the kind of company that we are, we lose way more from false-positives than from true-positives. With this system in place, Stripe is punishing legit users and businesses, with no way to change the default behavior.

I enjoy using Stripe as the next guy, but this needs to radically improve. At least provide me as a merchant a button to whitelist / accept a customer and override your rules.

Re: Improved fraud prevention with Radar 2.0

#45

Post by dwyerm »

bonestamp2 wrote: post #37
freehunter wrote: post #32

Earlier quoted context omitted.

>We had one payment blocked by Radar due to it being from a "high risk location" This, to me, represents the worst that banking fraud protection has to offer. Just yesterday I (from the USA) tried to purchase a software license for a tool I've been using the free version of for a long time. My card was declined, so I used my American Express. About two hours later, I got a call from my bank's fraud department saying…

This reminds me of Bank of America and Air Canada. I used to fly to Canada every week for work and every week my card would be declined by BoA when I tried to book on AirCanada.com. I had it down to a science, I knew the direct number to their fraud dept and I knew when I should place my call so that I'd usually be connected at just the right time to get the charge authorized with enough time to avoid the website ses…

Heh. My bank did something right, and my yearly $AUS payment to Fastmail finally went through without getting flagged by the automated systems.

Alas, a human also saw the transaction, failed to read the note or look in the history and locked the card up anyway.

Re: Improved fraud prevention with Radar 2.0

#46

Post by eeke »

gr2020 wrote: post #42
mlm wrote: post #2

Engineering manager for Stripe Radar here. Today’s update has been almost a year in the making and we’re excited to help Stripe businesses fight fraud more effectively. Here's more on what's new: https://stripe.com/blog/radar-2018 I (and the entire Radar team) are on hand to answer any questions you may have!

The only problem I ran into with the old Radar was a situation where a card was declined, and the customer contacted his bank to clear it up. The bank said they had no idea, they didn't decline the charge. When I followed up with Stripe, turns out Stripe declined the charge, and it never got to the bank. Is there a way to tell when this happens in the Dashboard? There wasn't at the time, but I'm hoping this is maybe…

PM on Radar here. There is! If you see a payment blocked for high risk in the Stripe Dashboard, it means that Radar blocked it before the card was charged. That is, the customer’s bank would have no record of the charge. In addition to the risk evaluation, Radar also provides the primary reason a transaction is believed to be high-risk (for example, the card has been linked to an unusually large number of card payments in the Stripe network over the past 24 hours).

Re: Improved fraud prevention with Radar 2.0

#47

Post by dwyerm »

lifeisstillgood wrote: post #14

Ok some really dumb questions if you don't mind, but how "fraud detection" works has always been one of those areas I am interested in, but not enough to seek out a practitioner and pin them down - until now ! - Any idea what the total fraud vs genuine transactions ratio is? And how that breaks down across industries? I am assuming that SaaS services don't get as much of this - i mean would people buy bingo cards wit…

> - how does fraud get monetised?

In the early days of ecommerce, we jokingly called it 'Toners for Taliban'. They would purchase goods with a stolen card from a company that ships fast. They'd have the item shipped to a rube who answered a "Make money fast! All you need is a computer and a mail box!" advertisement. Then, the rube would resell the item on Ebay and send a cut back. The rube takes the fall, if any.

Detecting this fraud was pretty obvious when you actually had a chance to look. Someone with a billing address in Florida is shipping a video projector to an address in Arizona, from an IP address in Austria? And they always fill out the forms in ALL CAPS? And that same IP has placed orders on a dozen other accounts?

The problem back then was that humans didn't have the time to do that exercise, and ML wasn't up to snuff, yet. Things are obviously better, now. However, at the same time, the fraudsters are probably smarter, too.

Re: Improved fraud prevention with Radar 2.0

#48

Post by ploxiln »

sixhobbits wrote: post #24

I really hope that this improves the false-positive rate, as mentioned in another comment. We've been hurt badly as a startup breaking into the US market and getting many of our genuine charges blocked by Radar (and at a "highest risk" level where it is not possible to disable rules). As a developer, I had the best possible impression of Stripe, as they provide easily the cleanest API and best documentation of any pa…

I think this is the one big reason why cryptocurrencies like bitcoin are not useless.

I'm not a big proponent of bitcoin etc, really, there sure are big downsides. But this is the big upside: the credit card system is "good enough" for average Americans and average retail chains, but breaks down all the time with international and/or indie stuff. (See also: random people banned from using Square for life, because the fraud detection algorithm can't handle them.)

Re: Improved fraud prevention with Radar 2.0

#49

Post by mehrdadn »

mlm wrote: post #31
sixhobbits wrote: post #24

I really hope that this improves the false-positive rate, as mentioned in another comment. We've been hurt badly as a startup breaking into the US market and getting many of our genuine charges blocked by Radar (and at a "highest risk" level where it is not possible to disable rules). As a developer, I had the best possible impression of Stripe, as they provide easily the cleanest API and best documentation of any pa…

We’re really sorry that you ran into this. There are a couple things we can help you with: - We give users the ability to disable the default rules and mark transactions as safe if you write in to support@stripe.com (so in the example you gave of a user clearing transactions with his or her bank, if Radar incorrectly blocked a subsequent payment because of high card velocity, you could mark it as safe and subsequent…

> so the primary reason might be that the IP is in country X, but that doesn’t mean there’s a blanket ban on X—just that that reason combined with everything else we saw across thousands of signals resulted in our giving the payment a high score

It might not be that one reason, but could it be something like the following two? Because that would be practically equivalent in terms of unacceptability:

1. Customer IP is in a high risk location, and

2a. Vendor rarely does business successfully with people in that location, OR

2b. Vendors around this region don't usually do business successfully with customers in that region.

("Does business successfully" here was meant to both encompass lack of transactions as well as lots of unsuccessful transactions; I'm asking about both possibilities.)

Re: Improved fraud prevention with Radar 2.0

#50

Post by lifeisstillgood »

alexbeloi wrote: post #25
lifeisstillgood wrote: post #14

Ok some really dumb questions if you don't mind, but how "fraud detection" works has always been one of those areas I am interested in, but not enough to seek out a practitioner and pin them down - until now ! - Any idea what the total fraud vs genuine transactions ratio is? And how that breaks down across industries? I am assuming that SaaS services don't get as much of this - i mean would people buy bingo cards wit…

> how much do the "obvious" checks help - highly unlikely purchases (3 iphones) timing or physical activity (I probably won't buy books on amazon, clothes on boohoo and petrol in a garage in the same five minutes) versus the more ML / secret squirrel stuff? ML solutions very often are just learning to codify these 'obvious' scenarios, and as a bonus sometimes less obvious ones. You could sit in meetings for hours/day…

This raises another question i guess - how to tell the difference between a chargeback that was fraud and a chargeback that was "i don't like it" i assume they get reasons for chargebacks?
Post reply on HN