
Improved fraud prevention with Radar 2.0 - collision
https://stripe.com/blog/radar-2018
======
sixhobbits
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 payment provider I've
used.

From a business side, it was highly frustrating losing so many of our early US
sales. A lot of this was due to US banks blocking the payment, but Stripe did
not handle these cases well in our case.

* Error messages presented to the customer are often ambiguous or misleading, and if you're using checkout.js you cannot customize these easily. In some cases, the customer gets a client-side "Card is declined" error, with no communication passed through to the merchant at all, which makes telephone support very difficult.

* Stripe will not provide any kind of telephone or chat support to merchants. By the time a specific blocked payment can be escalated to a "fraud specialist" the customer is usually long gone.

* Stripe will not allow you disable certain Radar rules.

* If a user tries to pay several times (due to their bank blocking the payment as suspicious), and then phones their bank to clear the payment, Stripe will often then block the payment due to "repeated attempted uses of the card". This is highly frustrating as even very determined customers who try several times and then contact their bank to resolve the issue there still get blocked by Stripe, and usually give up at that point.

* We had one payment blocked by Radar due to it being from a "high risk location" (Pakistan if I remember correctly). This represented unacceptable levels of discrimination for us. Machine learning and probability is useful, but ethically it's hugely problematic to deny people service based on their country, race, gender, age, or other attributes that they do not have control over.

My early experiences with PayPal were nothing short of terrible, but BrainTree
is looking like a more and more attractive alternative to Stripe, especially
with the PayPal integration built in -- if people have issues with their
Credit Card they can simply pay with PayPal credit instead.

~~~
freehunter
>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.

~~~
bonestamp2
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.

~~~
dwyerm
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.

~~~
asclepi
Fastmail charges you in AUD? Weird, I know it's an Australian company but I
paid for service earlier this month and was charged in USD. And I'm not
misinterpreting the "$" as a USD-only sign, the invoice literally says "USD".

~~~
nmjenkins
(I work for FastMail) We charge in USD, but the payment is processed in
Australia. For some reason, American banks often block all payments processed
outside of the USA; it's like they haven't heard of the concept of the
internet and global trade…

We don't see this problem with banks in any other country (not do I ever have
the problem in reverse, buying goods and services from foreign websites with
my Australian credit card).

~~~
freehunter
Working in information security, I see this a lot in security practices for US
companies. The client says "let's block all traffic from outside the US"
because they don't do business outside the US. Then come to find out they have
contractors in India... and a partner datacenter in Singapore, and oh yeah
their factory in China. And now the CEO is on vacation in Costa Rica and can't
get on the VPN. And oh shit, there's the field office at one of their
suppliers in the UK.

I say this as an American who has never lived outside the US but who deals
with international clients regularly: the US seems uniquely inclined (in my
experience) to think that everything they need falls within their borders, and
everything outside their borders should be treated with suspicion. I've never
had a German client want to block all traffic from South Africa. That's just
an observation, I make no judgements as to why that is.

I did have an American university for a client who said "we cannot block or
otherwise discriminate traffic from anywhere, since we have students or staff
in every country outside of North Korea" which is a refreshing outlook IMO.

------
mlm
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](https://stripe.com/blog/radar-2018)

I (and the entire Radar team) are on hand to answer any questions you may
have!

~~~
deepGem
One of the issues that I faced during my short stint building ML models for
fraud detection in debit card transactions was dealing with class imbalance. I
was not completely convinced that over sampling techniques or under sampling
techniques would work. My initial experiments just resulted in more false
positives. Just curious if you guys faced similar problems.

The other point I bring about is rather rhetorical - There are no open
standards, model baselines and datasets in the Fraud domain. Compare building
a model for fraud detection to building a model for image recognition or
object detection There is a standard baseline, standard datasets and your
model competes against that baseline. Because of the open nature of image
recognition, the models have improved astronomically. I feel that a lack of
such openness is fraud is holding back on innovation. I could be wrong in this
assessment so please correct me if so.

~~~
mlm
I agree that the lack of standards and baselines in the fraud detection space
isn't ideal. One example: some fraud products will build models using human
labels as the target to be predicted. Radar, on the other hand, tries to
predict whether a charge _actually turns out to be fraudulent_ (we use
dispute/chargeback data we get directly from card issuers/networks). These are
in fact different problems and the fact that the industry generally doesn't
have a consistent target makes discourse and comparisons more muddled.

(And on class imbalance: we spent quite a bit of time experimenting/analyzing
how to deal with it—we found that sampling rate has a marginal impact on
performance but not a huge one.)

~~~
deepGem
If you are still on this thread - check this video out at 28:56

[https://www.youtube.com/watch?v=4inIBmY8dQI&feature=youtu.be](https://www.youtube.com/watch?v=4inIBmY8dQI&feature=youtu.be)

------
Silhouette
Anything that will cut the number of false positives is a welcome development.
We lose far more to mysteriously failing charges than we've ever lost to
fraud...

Can the new system now distinguish between the initial charge to start a
subscription and subsequent ones? A recurring cause of those false positives
is someone moving house after they've subscribed and not telling us, and thus
failing a mandatory address verification when their next charge goes through.
The concept of pre-approved and automatically-blocked lists seems like it
might help with that problem, but it would be better still if we could just
define the rules more flexibly in the first place so the address-related
checks are done the first time but if they've passed previously then we're not
too concerned if they start failing later.

~~~
eeke
PM on Radar here. There are a couple of ways to handle this. You could, as you
said, add a customer to your allow list as soon as they pass the initial
charge (and AVS) check. You can also use the new `is_recurring` rule attribute
[0] which identifies whether the payment is a subscription charge or not
(though there’s some additional work to distinguish the first charge, and how
you use it depends on the nuances of your integration). I’d be happy to
discuss your specific use case in more detail. Feel free to email me directly
(eeke@stripe.com).

[0]
[https://stripe.com/docs/radar/rules/reference](https://stripe.com/docs/radar/rules/reference)

------
lifeisstillgood
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 with a stolen card?

\- how does fraud get monetised? Once i have downloaded my millions of credit
card numbers from Tor (or stolen my friends mothers wallet) I need to persuade
a merchant to deliver me something - but it's always bugged me that they
actually have to deliver it. to a physical address. that can presumably be
traced. It all seems very low level

(Quick story, years ago, call it the year 2000, was in the UK version of
BestBuy and the manager called up a service to verify that this 17 year old
kid could have a laptop. The manager asked what's your name ? Ok Your address
? Ok. Date of Birth? March 1954? really? you look a bit young for fifty. It
just seems a poor way to commit crime)

The question i am trying to ask is that turning credit card numbers into cash
seems like a grind that farmville would be impressed by? is it just lots of
low level grunts in shops and online or is there something i am missing?

\- what advantages do you get as a payment processor that a merchant does not
have? And how is that better / worse than the card provider? I would assume
there are people trying the same card in multiple different stores at the same
time, so if you spot one attempt you stop them all, whereas individual
merchants could not know. But Visa probably spots that i just paid for goods
on two continents which you can only spot of both merchants use you? Do you
and visa share data or do sequential checks and the like?

\- 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?

cheers

~~~
slivanes
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 up huge potential
reversal costs. For us, being in a specialized digital space makes this
especially painful as the digital items can be "used" and no longer resell-
able or recoverable, so inventory and real dollar value is lost.

Visa / MC has no real incentive to stop the fraud as the merchant in most
cases is liable for the reversal - Visa / MC is just a facilitator that bends
towards keeping the buyer happy (same with PayPal). 3DSecure was introduced
over a decade ago to alleviate some fraud based on unauthorized \ unknown but
uptake has been anemic due to poor buyer experience.

As for converting stolen card to profit, purchasing and delivering high ticket
physical items online and reselling is one known method.

~~~
lifeisstillgood
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.

------
kawsper
It is really cool that Stripe is building Radar, we wanted to use
[https://siftscience.com](https://siftscience.com) for something similar, but
they went all corporate, and changed their pricing model before we could
implement, so instead of them charging per "transaction" or user action, you
now had to pay a minimum of $1000 per month for their smallest offering.

~~~
globile
I'm seriously hoping this will make SiftScience reconsider their pricing, but
more importantly their handling of customers on legacy plans. Grandfathering?
Anyone?

This is a big win for Stripe. Sift is bullying customers into a minimum of
1,000 USD regardless of previous volume or history.

We were in the 10k orders per month around 250 USD with Sift. Now get kicked
in the teeth with the minimum 1,000 USD and no real additional value. Not
cool.

You know what's cool? Stripe's decision to not charge anyone who was a Stripe
Radar user before today. Kudos.

It must be said that Sift does not only apply to Credit Card fraud and has
many verticals (content abuse, ecomm, etc), but I think the big stuff is
definitely on the chargeback and fraud prevention.

~~~
badwolf
This is the boat we're in currently. We haven't been forced to change our
SiftScience plan to the $1k/mo minimum (which would over double our current
costs)

I'd love to move to Stripe Radar, but that doesn't really help with PayPal
orders.

~~~
globile
We've gotten a few weeks extension, but at some point I'm pretty sure things
will be enforced.

Regarding Paypal, I believe the fraud that hurts the most is credit card
(chargebacks, threshold maximums and card programs!), and Paypal in general is
not that bad at that (not as bad as other things).

If Sift sticks with their new pricing, I think it comes down to doing some
math.

Our Current Sift Scenario: 3,000 USD a year.

Proposed Sift Scenario: 12,000 USD a year.

Potential Stripe Radar Only Scenario: 0.

Assuming Stripe is as good or possibly better than Sift at catching
fraud/automating flows, then we've got 3 to 12k to offset any potential PayPal
fraud and still come out on top.

Ok, Not proper math, but worth considering...

Edit: formatting.

~~~
badwolf
I'm currently looking at some of our txn stats on Sift/PayPal, it seems like
we could get by there with some simple internal rules.

Definitely something I'm considering.

------
kweks
We've all but given up on Stripe's radar. We plugged in Signifyd, and it's
amazing to see how often Stripe gets things .. completely wrong.

Now obviously Signifyd scrub, but we haven't seen a case where we've had clean
transactions scrubbed, and when a CB goes through, you're refunded.

Likewise, you no longer have to worry about your CB% going over and you
getting blacklisted for life.

Until Stripe steps up and starts providing chargeback protection, their
protection is simply lipservice.

~~~
eeke
Radar PM here. I’m sorry to hear this. If you’re up for it, I’d love to dig
into the charges you think Radar’s gotten wrong (my email is eeke@stripe.com).

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

~~~
mlm
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 can tune Radar to reflect that,

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

~~~
hartator
Ok, thanks, we'll try that!

------
guessmyname
Clean landing page as always, keep up the good work.

~~~
noaccount1231
Except the spinning polygon ball. I found it so distracting, I couldn't read
the bullet points.

------
DTE
Good video on how they built out Radar.
[https://www.infoq.com/presentations/stripe-machine-
learning](https://www.infoq.com/presentations/stripe-machine-learning)

------
johnnyg
I love Stripe and am an early and long time customer.

Everything about them is beautiful, simplified and easy - except Radar.

For all the blogs and good intentions of the team, Radar to me means an email
3 days after I've processed and shipped an order telling me it may be
fraudulent, followed a month later by a reminder "I'm sorry, you lost your
credit dispute for $X" email, followed by a $15 charge by Stripe for no error
or bad faith on the part of my company.

When Radar isn't busy sending me reminders that we're having money stolen from
us, they are hard at work denying legit charges and sending customers down a
Kafka-esque rabbit hole, hell bent on seeing exactly how much friction can be
introduced into our website's buying process by a single third party service.

Stripe didn't create the fraud and they are taking on a difficult and
emotional part of their business, which is commendable, but it must be said:

1\. The false positive rate of Radar is so bad that it renders the product
worse than useless - worse because it initially provides a false hope.

2\. You can't disable some parts of Radar. Better to throw the whole thing
into the sea and use a plugin then be forced into some parts of this.

I know there are good people trying hard to build this product well. Some of
the people on it serviced our account in the early days. They had a vision of
a better way and they made it real. My hats off to them. Now, people I
respect, I have hard words and a hard truth to impart to you:

You are not delivering the value you claim to provide. Do not continue
iterating. Discontinue the product. Allow others who focus on this to do it
well. You are great at what you do but you are frustratingly, annoyingly,
arrogantly bad at this. It pisses us all off to be forced to use it and to be
told again and again how great it is going to be or how fixed it is this time.
I don't want to engage with Stripe on Radar or "learn more about it", I don't
want to be interviewed by you so you can better understand the voice of
customer, there is no email or back channel thing you can send to make this
better. The beauty of Stripe is that it "just works" but Radar does not just
work - and it never will.

~~~
eeke
PM for Radar here. Really sorry to hear that. Portions of your comment are
surprising to me but I don’t want to discuss your business in public. We’d be
happy to discuss in private. If you don’t want to, we respect that.

For the benefit of other HNers: if you ever have a concern about this sort of
issue, we’d love to hear from you (my email is eeke@stripe.com). This is all I
do every day; you can never waste my time.

------
etaioinshrdlu
Stripe's false positive problem has been awful for my business. Hoping it gets
better.

------
the_arun
Shouldn't fraud detection available by default? Why customer has to pay extra?

------
Sephr
Do you use ML on street view imagery of addresses to attempt to detect if an
address is abandoned (and subsequently, more likely to be used to recieve
fraudulent orders)?

------
throwaway123121
On a throwaway so I can reply to this. Creditcard fraud is ripe and easy when
it came to stripe a few years ago, I havn't carded anything for awhile. But
glad to see stripe working on fraud prevention. We use to use tor and not even
need to hop exit nodes and we could drain 100+ ccs into twitch streamers
alerts for a gag and without stripe then we'd be stuck with paypal, screw
carding paypal stripe all the way. Might be useful if stripe tried to card
their services themselves to learn to prevent it, but they didnt even appear
to try. Atleast block tor for credit card transactions come on, no one is
going to use tor to pay for something under their own credit card. Kinda
defeats the purpose of tor.

