Ex-Googlers Train Machine Army to Sift Out Crooks | Hacker News Reader

Ex-Googlers Train Machine Army to Sift Out Crooks

wired.com

100 pointsdivad1231 comments

$0.10/query is a hefty price to pay. For comparison's sake - http://www.maxmind.com/en/ccfd_features

If siftscience turns out to be significantly more accurate, it may end up being worth it.. but at somewhere between 6 and 20x their competition's price, it will take quite the improvement.

That was my main takeaway from skimming. I'm not a sales person, but I could see ten cents being a significant portion of the profit margin on certain items.

(I work at Sift Science.)

For what it's worth, you can score up to 5000 users per month completely free with Sift Science. So if you run a small site, there's no fee. If you run a large site, you can see for yourself whether we're saving you enough money to justify the price.

In addition, there are discounts from high volume, for pre-payment, and there's the possibility of scoring only high-risk users. If you run a web site, feel free to shoot me an e-mail at brandon@siftscience.com, and we can figure out how to make it work for you.

(I work at Sift Science too.)

Just to clarify, we charge 10 cents per unique user that you query in a month, not per query. So, you can query the same user as many times as you like in a month and the cost will not exceed 10 cents for that user.

How would this sit with payment gateways from a PCI standpoint?

An ideal customer would be an e-commerce marketplace, I imagine that Sift Science would want to receive as much information about the customer as possible, including credit card / address details. Are you guys completely PCI compliant? You're taking 10 out of 16 credit card digits...

From a quick glance of your website you make no reference to PCI.

https://siftscience.com/docs/rest-api

There is no requirement in their api to supply CC details... so no requirement to be PCI.

So it would be weird if they did mention PCI...

The first 6 and the last 4 is not enough to make a valid CC... And if you are still guessing the last details then it's the same as just guessing the full number. (just you'll get their quicker)

No, but 10 of 16 numbers that must conform to a checksum algorithm significantly reduces the search space to a point that a brute force seems trivial if other information is already possessed (e.g., zip code, or especially, cvv).

The MyKi ticketing system in Australia prints the first 6 digits, last 4 digits, expiry date and full name on it's recepts. I mentioned to them in the past how easily it could be attacked, but the response was "nobody would do that".

Brute forcing "ALL" the credit card numbers is not hard... Limitiing the search space doesn't make it easier... it just saves a little bit of electricity.

Great question. We should add it to a FAQ. The PCI-DSS rules apply to systems that store the entire credit card number ("PAN" in PCI-DSS parlance). We don't accept the full credit card number -- just the first six digits (which identify the type of credit card and bank) and the last four (typically printed on receipts), which the PCI-DSS rules allow for. So if you're PCI compliant already, you'll still be PCI compliant if you use Sift Science.

Thanks for the information, I think I'll be in touch about an account in the next few weeks for a marketplace I'm developing.

Perfect timing too, I just started looking at our options for developing something similar internally.

Would love to see the systems that Etsy / Ebay for handling this type of fraud.

So what happens when a user scores high? Suppose I'm a firefox & windows xp user from elbonia shopping at 3am, does the site not let me make a purchase? Am I forced to provide extra information or are items delayed before shipping?

(I work at Sift Science.)

We provide a score, and then let our customers decide what to do. The majority of our customers have a human review the user, and sometimes as part of that review, they'll do extra verification such as calling the user up. In other cases, customers will delay charging the credit card until they can verify it's legitimate.

Interesting that a prepaid gift card strongly suggests fraud. What if a person simply wants to protect his privacy?

I think it's best to rephrase that data and say "using a real credit card makes the transaction look more legit". (But it should be obvious that fraudsters want to "protect their privacy". In this case, it's the difference between going to jail and not!)

The same thing than purchasing something at 3am. Those are only behaviors associated with higher chances of fraud. With the models they work p(fraud|prepaid_card) > p(fraud|!prepaid_card)

And how do you defraud a retailer using a prepaid gift card anyway?

Not sure if this counts as fraud:

I live in Malaysia, and for the longest time, we didn't have access to the iTunes store. We effectively couldn't buy apps or music online from Apple.

To circumvent this, we could open a fake US account. Problem is, you can only purchase items with a valid US credit card. To circumvent that, some people went to the US, bought a lot of prepaid gift cards, and sold them here at a marked-up price. Then all we have to do is set up a US account with a fake US address (thank you, Beverly Hills 90210!).

(I work at Sift Science.)

One thing to note -- our system analyzes a whole bunch of patterns for each user. So just shopping at 3am by itself won't cause problems, nor will using a prepaid gift card by itself. But if a user matches multiple fraud patterns, then they're likely to get a high fraud score.

Cool, thanks for clarifying.

Then they are making a purchase in a category that is most often fraud though they are not committing fraud. Its not like the two things can't exist at the same time.

If I want to protect my privacy, I can wear a ski mask to any place with surveillance cameras, such as banks and gas stations. But this does tend to strongly suggest that I'm there to rob the joint.

Why does people complain if I enter my bank with a ski mask? What if a person simply wants to protect their privacy?

In other words: A lot of things can have perfectly legitimate reasons but still strongly suggest that you're up to no good.

The tricky thing is to combine sufficient number of signals to get a high enough confidence to act on it without angering users with legitimate reasons.

Since the Sift guys are responding: from where do you get the raw data about fraudulent transactions? I'm assuming you have streams of fraudulent and valid transactions, otherwise you can't figure out what correlates with fraud.

Our customers send examples of users that they've banned from their site or who have caused a credit card chargeback -- these are the $label events in our API and quickstart.

Those $label events let us do two really important things.

First, we can learn patterns that are unique to a particular site. Every site is a little different, so that has a big impact. Patterns that catch fraud accurately for an auction site may not work at all on a travel site.

Two, if a user gets banned from one site in our network, we can identify when they attack another site. That means as more sites join the network, the system gets more accurate for everybody.

This strikes me as a very dramatic title.

There is a second point of feedback that should be exploited. He knows which services are used for fraud, it is not unreasonable to conclude that Yahoo (2x) has something wrong in their service (terrible security problem) that AOL doesn't (0.5x).

I've used sift science, it's pretty neat! I recommend checking out their product.

From what I've read about this project so far, it requires adding "a single line of JavaScript to the site." So what's to stop scammers and spammers from just blocking the file from loading?

(I work at Sift Science)

If there has been no JavaScript activity from a user who makes a transaction on your site, that is a fraud signal in its own right. (You can send us events from your server in addition to adding the JS to your site, so that we know characteristics of your users' transactions that can't be gleaned from the JS. In both cases you set the user ID in the call to Sift.)

Ah, okay that makes sense, considering that both client side and server side events will be used. Thanks for the reply!

Reply on news.ycombinator.com