Improved fraud prevention with Radar 2.0

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.

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.

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.

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