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

Tell HN: Automatic fraud detection is making my life hell

news.ycombinator.com

Post reply on HN
Print view View original

141–150 of 406 posts

Re: Tell HN: Automatic fraud detection is making my life hell

#141

Post by quags »

dreamcompiler wrote: post #131

Wrong assumptions programmers make about fraud prevention: -- A mobile phone number uniquely identifies a single person. -- Every person has a mobile phone number and they only have one mobile phone number. -- If a person's mobile phone number is associated with VoIP or Google Voice, that indicates fraud. -- Every person always has their mobile phone handy and it is always able to receive calls and SMS messages under…

All these can be the wrong assumptions for sure. Working in a space with some fraud though I can tell you the majority of users verify fine and there ate only the few percentage that don’t for any number of reasons some what you have given above. For smaller vendors though things to consider are

- a charge back can come up to 6 months later. A loss of that is not only a loss of funds but a charge back fee

- too many charge backs could affect the merchant account with the potential of a loss of being able to run your business and this can extend to PayPal or anything merchants run charges through.

- Fees may go up like interchange fees on running credit cards if an account is deemed higher risk.

- blacklisting from visa or Mastercard or merchant accounts in general is not unheard of. Loosing access to running credit cards would be the end of many businesses.

So mom and pop shops need to be aware of fraud and ensure it is low or taken care of. You can’t just accept every order and hope for the best. Fraud does exists and when only a few percentage of users meet your list of incorrect fraud assumptions it’s easy to see why they are used at least for extra verification.

One good thing for merchants for those who accept crypto like Bitcoin is all the risk moves to the sender not the merchant. There are no charge backs - so merchants who take crypto should be able to be a bit more lenient on payments and verification.

Re: Tell HN: Automatic fraud detection is making my life hell

#142

Post by jey »

dreamcompiler wrote: post #131

Wrong assumptions programmers make about fraud prevention: -- A mobile phone number uniquely identifies a single person. -- Every person has a mobile phone number and they only have one mobile phone number. -- If a person's mobile phone number is associated with VoIP or Google Voice, that indicates fraud. -- Every person always has their mobile phone handy and it is always able to receive calls and SMS messages under…

Why would LEO satellite internet cause frequent change of IP addresses? Shouldn't all that moving-satellite stuff be handled on a lower level of the OSI Model (probably Layer 2: Data Link), and the IP stuff at Layer 3 isn't affected?

Re: Tell HN: Automatic fraud detection is making my life hell

#143

Post by LoganDark »

cj wrote: post #137
dreamcompiler wrote: post #131

Wrong assumptions programmers make about fraud prevention: -- A mobile phone number uniquely identifies a single person. -- Every person has a mobile phone number and they only have one mobile phone number. -- If a person's mobile phone number is associated with VoIP or Google Voice, that indicates fraud. -- Every person always has their mobile phone handy and it is always able to receive calls and SMS messages under…

The problem with many of these examples is that 99% of the time, it is a sign of fraud, and 1% of the time it’s a false positive. > If a person's mobile phone number is associated with VoIP or Google Voice, that indicates fraud. I’ve been using this heuristic (along with VPN and IP geo lookup) when screening job candidates after a massive influx of developers outside the US applying for US-only remote roles. I discov…

> US-only remote roles.

The entire premise of remote is that it shouldn't matter where you work from, as long as you get the work done. This is extremely, incredibly harmful. I hope you know that.

Re: Tell HN: Automatic fraud detection is making my life hell

#144

Post by Aldipower »

I would like to emphasize his point. When we get into a digital only currency world, you are loosing control. He is giving a real life example. Nothing hypothetical. Think about blocked - without given reason - Google accounts and such. Could be you bank account, in the future, too!

Re: Tell HN: Automatic fraud detection is making my life hell

#145

Post by indrora »

dreamcompiler wrote: post #131

Wrong assumptions programmers make about fraud prevention: -- A mobile phone number uniquely identifies a single person. -- Every person has a mobile phone number and they only have one mobile phone number. -- If a person's mobile phone number is associated with VoIP or Google Voice, that indicates fraud. -- Every person always has their mobile phone handy and it is always able to receive calls and SMS messages under…

I'll add another to that list:

-- People will never have a physical mailing address that contains "funny" numbers like "000", "420", "69420", or "80085".

Re: Tell HN: Automatic fraud detection is making my life hell

#146

Post by [deleted] »

LoganDark wrote: post #143
cj wrote: post #137

Earlier quoted context omitted.

The problem with many of these examples is that 99% of the time, it is a sign of fraud, and 1% of the time it’s a false positive. > If a person's mobile phone number is associated with VoIP or Google Voice, that indicates fraud. I’ve been using this heuristic (along with VPN and IP geo lookup) when screening job candidates after a massive influx of developers outside the US applying for US-only remote roles. I discov…

> US-only remote roles. The entire premise of remote is that it shouldn't matter where you work from, as long as you get the work done. This is extremely, incredibly harmful. I hope you know that.

[deleted]

Re: Tell HN: Automatic fraud detection is making my life hell

#147

Post by thaumasiotes »

fishyjoe wrote: post #30
agubelu wrote: post #5

Earlier quoted context omitted.

I have a Raspberry Pi at home running an OpenVPN server, and a client config for each of my devices, and it's been extremely useful ever since.

How do you expose the Raspberry Pi so that you can reach it from the outside internet? My OpenVPN runs on a Digital Ocean droplet and I use it to tunnel into my home network, but having a direct route might be better.

> How do you expose the Raspberry Pi so that you can reach it from the outside internet?

I had this issue recently trying to enable port forwarding on a comcast router, which is no longer allowed.

Turns out the answer is "stop the router from blocking ipv6 connections". You can just connect directly to whatever device you want over ipv6.

Re: Tell HN: Automatic fraud detection is making my life hell

#148

Post by ajb »

quags wrote: post #141
dreamcompiler wrote: post #131

Wrong assumptions programmers make about fraud prevention: -- A mobile phone number uniquely identifies a single person. -- Every person has a mobile phone number and they only have one mobile phone number. -- If a person's mobile phone number is associated with VoIP or Google Voice, that indicates fraud. -- Every person always has their mobile phone handy and it is always able to receive calls and SMS messages under…

All these can be the wrong assumptions for sure. Working in a space with some fraud though I can tell you the majority of users verify fine and there ate only the few percentage that don’t for any number of reasons some what you have given above. For smaller vendors though things to consider are - a charge back can come up to 6 months later. A loss of that is not only a loss of funds but a charge back fee - too many…

The problem is that it's not acceptable for online providers to converge on making life miserable for "a few percent" of people.

This is a market failure: to save the cost of a few bucks, huge costs are imposed on these individuals. The answer is to have some mechanism whereby people who run into these issues can pay (once) the small cost of being validated in an alternative way (like, actually talking to a human and explaining what's going on, which is how these issues got solved in meatspace originally)

Re: Tell HN: Automatic fraud detection is making my life hell

#149

Post by cj »

LoganDark wrote: post #143
cj wrote: post #137

Earlier quoted context omitted.

The problem with many of these examples is that 99% of the time, it is a sign of fraud, and 1% of the time it’s a false positive. > If a person's mobile phone number is associated with VoIP or Google Voice, that indicates fraud. I’ve been using this heuristic (along with VPN and IP geo lookup) when screening job candidates after a massive influx of developers outside the US applying for US-only remote roles. I discov…

> US-only remote roles. The entire premise of remote is that it shouldn't matter where you work from, as long as you get the work done. This is extremely, incredibly harmful. I hope you know that.

To be clear, “US Only” means “eligible to work in the US”.

The candidates that I’m calling fraudulent are answering “Yes” to a question on our applicant form asking if they’re eligible to work in the US.

There’s absolutely nothing wrong with a US company wanting to hire US employees.

(FWIW I also hire contract developers outside the US… have nothing against outsourcing, but I prefer to do so knowingly rather than being conned)

Re: Tell HN: Automatic fraud detection is making my life hell

#150

Post by thaumasiotes »

ellyagg wrote: post #33

I live in California and nike.com just cancelled my last two orders without notice because they "couldn't verify my billing information", according to the chat rep. It's the same billing information I use everywhere for years.

Years ago I kept having Blizzard cancel my subscription to World of Warcraft because of unspecified problems with the payment information. I'd get locked out, I'd pay again, and a couple days later they'd be angry again over my invalid payment information.

I eventually learned that what they meant by "invalid" was "sure, your payment information is already associated with your account, but it doesn't match the preferred card listed on your account".

Post reply on HN