Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Radar – A new set of integrated tools to help prevent fraud

stripe.com

Post reply on HN
Print view View original

101–110 of 120 posts

Re: Radar – A new set of integrated tools to help prevent fraud

#101

Post by joshmn »

Yeah, I still wouldn't trust it.

Nothing beats manual verification. People aren't sharing credit card numbers on public forums and mashing them against Stripe. People are paying for fulls, and grabbing a socks5 that's piped within a few miles of the address of the cardholder.

Never trust your processor to protect you against your (potential) customers. Stripe has very little incentive to do so. They'd rather you pay that fat $15 fee when you get hit with a chargeback. They really would.

I'm coming out with a book about Stripe (and a few other processors) and fraud. Trust me it will be good, and this is already a part of it.

Sincerely,

Someone who was once your enemy

PS my favorite part of this? Telling the carder how to defeat their algos:

* "This card has been used from an unusually large number of IP addresses across the Stripe network over the last 24 hours."

* "This email has been linked to an unusually large number of cards across the Stripe network over the last hour."

Thanks for not saying the card was declined. If you wouldn't mind, please hold while I switch socks and make a new email.

Sorry if this is crass, but whoever decided on telling the end-user why a card was declined... complete fucking idiot and should never work in fraud protection or payment processing again.

Re: Radar – A new set of integrated tools to help prevent fraud

#103

Post by derefr »

johnhenry wrote: post #85
arcticfox wrote: post #75

Earlier quoted context omitted.

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.

Re: Radar – A new set of integrated tools to help prevent fraud

#104

Post by _pmf_ »

rwmurrayVT wrote: post #98
arcticfox wrote: post #75

Earlier quoted context omitted.

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.

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 t…

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

Re: Radar – A new set of integrated tools to help prevent fraud

#105

Post by louischatriot »

maratc wrote: post #77

Most merchants don't want a rule engine, or rules. Most merchants want either a declined transaction (possibly with explanation -- possibly), or an accepted one with a guarantee against chargebacks. If Stripe is sure that their models work, they should offload the chargebacks from the merchants. A friend of mine worked for a startup that did exactly that. They were sold to an online payments behemoth in about 2009.

-- Most merchants want either a declined transaction (possibly with explanation -- possibly), or an accepted one with a guarantee against chargebacks.

Well in fact their is an issue of misaligned incentives here. Your chargeback insurance has a strong incentive not to receive any chargeback (of course), so they will be overly cautious and decline a lot of valid charges. Stripe on the other hand as perfectly aligned incentives with the merchant, as they don't make money on a blocked transaction.

(disclaimer: I work at Stripe)

Re: Radar – A new set of integrated tools to help prevent fraud

#106

Post by Dylan16807 »

derefr wrote: post #103
johnhenry wrote: post #85

Earlier quoted context omitted.

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 fraudulen…

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

Re: Radar – A new set of integrated tools to help prevent fraud

#107

Post by maratc »

louischatriot wrote: post #105
maratc wrote: post #77

Most merchants don't want a rule engine, or rules. Most merchants want either a declined transaction (possibly with explanation -- possibly), or an accepted one with a guarantee against chargebacks. If Stripe is sure that their models work, they should offload the chargebacks from the merchants. A friend of mine worked for a startup that did exactly that. They were sold to an online payments behemoth in about 2009.

-- Most merchants want either a declined transaction (possibly with explanation -- possibly), or an accepted one with a guarantee against chargebacks. Well in fact their is an issue of misaligned incentives here. Your chargeback insurance has a strong incentive not to receive any chargeback (of course), so they will be overly cautious and decline a lot of valid charges. Stripe on the other hand as perfectly aligned i…

This does not contradict what I said. Declines should be free. Accepts should be guaranteed (but not free). Stripe currently offers free declines, but not guaranteed accepts.

Re: Radar – A new set of integrated tools to help prevent fraud

#108

Post by anc84 »

edwinwee wrote: post #30
bflesch wrote: post #12

I like the rotating 3D model in the landing page very much. Are they using some sort of pre-baked library which lets you create such an visualization with 30 lines of Javascript, or is it 100% custom? Maybe someone can point me to a good resource for such elegant WebGL renderings.

Glad you like it! We used Three.js ( https://threejs.org ) to handle rendering the icosahedron itself. Three.js actually includes an icosahedron as one of its built-in primitives, however we also wanted to add some subtle details to the model such as rounded edges. So, we created a rounded version in Cinema 4D, and then rendered both that model as well as an invisible copy of the object using the Three.js primitive.…

It burns CPU like mad. See if limiting the framerate to something sane makes sense, 15-20 might be enough for fluent motion. https://stackoverflow.com/questions/11285065/limiting-framer...

Re: Radar – A new set of integrated tools to help prevent fraud

#109

Post by jamies888888 »

Cool feature. Stripe are pretty awesome at creating marketing pages for these things too. Although it's a shame they messed up the green HTTPS padlock on that page by serving mixed content. (The Teespring video on AWS S3 simply needs the protocol changing from http to https to rectify this.)

Re: Radar – A new set of integrated tools to help prevent fraud

#110

Post by MertsA »

Dylan16807 wrote: post #106
derefr wrote: post #103

Earlier quoted context omitted.

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 fraudulen…

"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.
Post reply on HN