Live data from Hacker News

Improved fraud prevention with Radar 2.0

stripe.com

31–40 of 83 posts

Re: Improved fraud prevention with Radar 2.0

#31

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 payments would be allowed).

- Radar surfaces the primary reason a transaction is believed to be high-risk, but that is never the only reason (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 didn’t quite make it in under the wire for today’s launch, but we’re working on making the explanations more detailed.

We believe that Radar 2.0 (and in particular Radar for Fraud Teams) should also be helpful here:

- With Radar for Fraud Teams, you can customize the threshold at which Radar blocks charges—so if false positives are very costly for your business (because you have large margins, e.g.), you can tune Radar to reflect that; you can also specify lists of trusted payment attributes to “allow” (if you have known good card numbers, e-mail addresses, IPs, etc.)

- Radar 2.0’s custom machine-learning models (for businesses that have enough data with Stripe) should adapt to the unique circumstances/patterns/trends of your business, and

- Radar 2.0’s ML overall has substantially improved performance, which you should see after you’ve upgraded.

Re: Improved fraud prevention with Radar 2.0

#32

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 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 they had blocked a transaction to the UK for fraud prevention, and disabled my card to protect me. Apparently the bank (a small US-based bank) block any transaction in the UK as it's a "high risk country"... I'm sorry, but this is the Internet. No one cares where the company is located, and I have no way of knowing beforehand that the payment is processed by Stripe US or Stripe UK. Blocking entire countries for fraud prevention is a really lazy way of doing fraud prevention.

But I've even seen worse at another bank. My area of the US doesn't have Publix grocery stores. Apparently this bank considered shopping at Publix to be unacceptable risk when I was traveling for work, and disabled my debit card because of this. Stopping at Walgreens beforehand and getting dinner the night before wasn't suspicious though.

Bank fraud is a hard problem, and taking lazy solutions doesn't solve that problem. It just hurts customers and hurts businesses.

Re: Improved fraud prevention with Radar 2.0

#33

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 work on Stripe support. Chat support's now available through the Dashboard Monday through Friday, 24 hours a day. We're testing phone support, and we're working to roll it out soon. If you do run into any issues, always feel free to email me at edwin@stripe.com

Re: Improved fraud prevention with Radar 2.0

#34

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…

Agree. We have a non-US Stripe account, so we are heavily penalised when we try to charge the US market.

Large percentage of support calls start with "my bank blocked the transaction because it was international / fraud"

Incorporating in the US is not a feasible option. This is where Stripe's "Global" reach and 150 currencies loses a bit of power.

Would be great if there was a way non-US stripe merchants could bill us customers as if they were in the US. Sure it is more of a regulatory/legal issue than a technical one.

Re: Improved fraud prevention with Radar 2.0

#35
post #26

I wish they will be a way to minimize false positives. It’s a biggger issue to block legitimate customers because they are not from the US.

For any fraud detection scheme (or any binary classification scheme, really) there’s a tradeoff between false positives and false negatives. The Radar 2.0 updates—particularly Radar for Fraud Teams—will help here in a few ways: - With Radar for Fraud Teams, you can customize the threshold at which Radar blocks charges—so if false positives are very costly for your business (because you have large margins, e.g.), you…

Ok, thanks, we'll try that!

Re: Improved fraud prevention with Radar 2.0

#36
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!

Why don't you show location + device data for all payments? Not only those under review.

It would be pretty useful information to have, since you're collecting it already.

Re: Improved fraud prevention with Radar 2.0

#37

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 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 session from timing out, although sometimes I'd have to start over. Eventually, air canada added a timeout popup which helped prevent this.

I tried everything to get BoA to fix this (escalating calls, writing letters, etc). By the end, I gave up and just accepted it when they "put a note" on my account so this "would never happen again". This went on for over 2 years. Thankfully my company switched our cards to another bank and I never had this problem again.

Re: Improved fraud prevention with Radar 2.0

#38
post #36
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!

Why don't you show location + device data for all payments? Not only those under review. It would be pretty useful information to have, since you're collecting it already.

We're working on it!

Re: Improved fraud prevention with Radar 2.0

#39
post #30
post #19

Earlier quoted context omitted.

Most of our ML stack has been developed internally given the unique constraints we have for Radar. Among other things, we need to be able to - compute a huge number of features, many of which are quite complex (involving data collected from throughout the payment process), in real-time: e.g. how many distinct IP addresses have we seen this card from over its entire history on Stripe, how many distinct cards have we s…

Broadly speaking, what approach do you use to "build simpler 'explanation models'" from the more complicated "core fraud models"? Do you learn the models separately over the training data, or does the more complicated model somehow influence the training of the simpler model?

The rough idea is that you look at all the decisions made by the fraud model (sample 1 is fraud, sample 2 is not fraud) and the world of possible "predicates" ("feature 1 > x1", "feature 1 > x2", ..., "feature 10000 > z1," etc.) and try to find a collection of explanations (which are conjunctions of these predicates) that have high precision and recall over the fraud model's predictions. For example, if "feature X > X0 and feature Y It's a little tough to talk about this in an HN comment but please feel free to shoot me an e-mail (mlm@stripe.com) if you'd like to talk more.

Re: Improved fraud prevention with Radar 2.0

#40

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…

We've found that fraud vs. genuine closely matches the percentage of assholes and psychopaths in the general population, somewhere ~1% to 2%. And just like in meat-space these people are the cause for increased prices and frustrating checkout experiences - i.e. payment holds and refusals. The problem is said people can do so much damage to a profit margin as they tend to hit an online store hard and quickly, racking…

Oh man you win my favourite post of the week with "assholes and psychopaths" quote :-)

I will read the rest of your post after I get some dry pants on.

Post reply on HN