Hacker News Reader

Comment by compumike | Hacker News Reader

Just checked our Stripe dashboard and it looks like this has quietly been doing good work for us for many months now blocking suspicious charges. It took me a few clicks to find https://dashboard.stripe.com/search/rules?rule_token=block_i... and after going through a few of them, the per-charge risk factor descriptions are really helpful too. The high-risk reasons are messages like: "This card has been used from an unusually large number of IP addresses across the Stripe network over the last 24 hours." and "This email has been linked to an unusually large number of cards across the Stripe network over the last hour."

Thanks to Stripe for making it not-a-black-box! I hope others who build machine learning systems also find a way to make its decisions understandable by humans (when possible).

View on HN

"Primary risk factor: The country where this card was issued (EC) does not match the country where the payment was made (US)."

This has become clear now....but Stripe has thus been blocking legitimate payments from our users with no insight for us

80% of our clients are travelling at the time of purchase... Now we understand why we were getting so many BLOCKED transactions!!

Although this is a welcome addition, a heads up would have been nice...

One thing to note is that the risk factor surfaced in the dashboard is the primary risk factor, but the final risk level is a combination of many different factors--it's not accurate to say that the charge was blocked only because the card country did not match the IP country. That said, if you are certain that there are areas where there are high numbers of false positives, Radar does provide tools for making corrections (by writing rules to allow or send charges to review, for example). I'm happy to talk more about the specifics in your case if you send me a note (and definitely let me know if there's a way we can make this clearer in docs/product) -- I'm tara@stripe.com.

Usually fraud systems are black boxes to prevent abuse, not because they can't be human readable.

I agree however that to my eye it does usually seem excessively black-box, as it's not like most fraudsters are idiots, they already know what tools are arrayed against them.

If a system requires that it be a black box to prevent abuse, you should use another system. A black box with flaws that allow abuse is difficult to fix. With an open, auditable system, methods of abuse are more easily exposed and fixed.

The problem is not "flaws" being protected in a security-by-obscurity sense.

Rather, it's that these predictive models mostly consist of linear combinations of metrics. (By necessity: "linear combinations of metrics" is usually what most accurately reflects the real world.)

If you know exactly which factors, at what weightings, a given predictive model has, you can build a simple function to spread out your fraudulent activity that will ensure that you never exceed their fraud threshold in your aggregate score.

Say someone's anti-fraud model uses two factors: P(using a prepaid card) and P(using a Nigerian postal address). If you know the weights on those two factors are (0.3, 0.7), and you know that the system says "fraud" when you score above 1.0, then you can still do both of those things, just so long as you never do them both at the same time.

Basically the only thing that makes these systems useful at all is that their input-factors and weights are hidden information. There is no anti-fraud system that would survive being public; they'd all, as a class, be rendered instantly useless.

"Useless" is a pretty big exaggeration. Harshly limiting the methods of scammers is still valuable.

But you can't really harshly limit their methods. So long as a scammer uses the exact same method as a real customer would use he can get away with it. The effectiveness of fraud detection is finding where the scammer slipped up.

Prime example is MaxMind's minFraud. How long do you think it took for someone to pay $500 and test their card details + billing information + shipping information + sock5/rdp before submitting payment on a MaxMind "protected" webstore?

MaxMind isn't a black box either. You can pay 0.03 USD to get the full break down of scores on an inquiry. You can register and get an ID number to token your fraudulent VM/RDP with the card before submitting a real payment. That partially helps defeat their device tracking [1].

https://www.maxmind.com/en/minfraud-device-tracking

> You can register and get an ID number to token your fraudulent VM/RDP with the card before submitting a real payment.

That leaves a trail.

Purchasing minFraud or creating device ID numbers? If you're on a RDP or VM who cares? The trail will lead back to nowhere.

You want to create a history, a trail, so to speak with browser/device, IP, and card usage. MaxMind's device ID tracking is similar to what Radar is offering. You've used your card before on a MaxMind protected website with device ID creating LSOs. Now they have you fingerprinted and they can tell if you suddenly start making purchases from an unusual PC/IP. It helps you as a legitimate cardholder at the expense of your privacy.

Stripe uses IESnare when you sign up to determine if you have any sketchy internet history or are a previously banned user. It's a similar strategy, pose as a legitimate user for a week by browsing the internet normally and search for payment processors to "compare" online. Then sign up after you've created history on the device and IP.

I have a similar transaction blocked as well. Very cool to see this has been in action for awhile.

Reply on news.ycombinator.com