mlm

This looks great, but it's also focused on people—what happens when more and more support is done via AI?

I’m sorry that you had this experience. We vehemently agree that any one signal (such as IP address or use of a proxy) is a pretty poor predictor of fraud in isolation. We are trying to move the industry towards holistic evaluation rather than inflexible blacklists; not everyone behind a TOR exit node is a fraudster, for example.

While we can’t fix the previous experience you had, we’ve rebuilt almost every component of our fraud detection stack over the past year. We’ve added hundreds of new signals to improve accuracy, each payment is now scored using thousands of signals, and we retrain models every day.

We hope these improvements will help. We want our customers to be able to provide you services; that’s what keeps the lights on here. We’d be happy to look into what happened if you have specific websites in mind—feel free to shoot me a note at [email protected].

In short, no.

A little more color: Stripe’s incentives are aligned with those of our users in that we want to let through as many legitimate customers as possible. We keep a very close eye on false positives.

Our machine learning models examine thousands of attributes for each payment and make predictions based on how frequently the observed attributes were associated with fraud in the past. The comparison here is never just on one or two or three attributes (as in your example), and no logic is hard-coded.

We’ve been working on Radar, and releasing updates and improvements, continuously since we first launched. What we’re announcing today is (1) a completely revamped machine learning system (which we couldn’t release in pieces—we needed to finish every layer of the stack before we could launch it, though we’ve been running it in beta for a percentage of users since late last year) and (2) a new package of features specifically designed for teams working on fraud prevention.

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 < Y0" is true for 20% of all payments the fraud model thinks are fraudulent, and 95% of all payments matching those conditions are predicted by the fraud model to be fraud, that's a good "explanation" in terms of its recall and precision.

It's a little tough to talk about this in an HN comment but please feel free to shoot me an e-mail ([email protected]) if you'd like to talk more.

We're working on it!

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 [email protected] (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.

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.

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

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 seen from the IP address over its history, and do payments from this card usually come from this IP address?

- train custom models for all Stripe users who have enough data to make this feasible, necessitating the ability to train large numbers of models in parallel,

- provide human-readable explanations as to why we think a payment has the score that it does (which involves building simpler “explanation models”—which are themselves machine learning models—on top of the core fraud models),

- surface model performance and history in the Radar dashboard,

- allow users to customize the risk score thresholds at which we action payments in Radar for Fraud teams,

- and so forth.

We found that getting everything exactly right on the data-ML-product interactions necessitated our building most of the stack ourselves.

That said, we do use a number of open source tools—we use TensorFlow and pytorch for our deep learning work, xgboost for training boosted trees, and Scalding and Hadoop for our core data processing, among others.

(I work at Stripe) We've thought about this a little, and while we'd be excited to make Radar available more broadly (i.e., even to businesses not using Stripe for payments), for now we're focusing our efforts on improving the product.

We've been thinking about (and working on) a lot of these issues--we're definitely aware that users would like (totally reasonably!) more visibility and control. If you have any more feedback, I'd love to hear it!