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

SQL patterns I use to catch transaction fraud

analytics.fixelsmith.com

Post reply on HN
Print view View original

11–20 of 138 posts

Re: SQL patterns I use to catch transaction fraud

#11

Post by thedebuglife »

0cf8612b2e1e wrote: post #8

If a card swipes in Chicago and seven minutes later swipes in Los Angeles, one of those swipes is fake. How does this work with online shopping? When I am sitting on the couch and buy from Amazon, where does the address get registered? Can also imagine an edge case: couple shares an online account, one is traveling and purchases with the saved card details.

They can tell based on transaction metadata. Source: I worked at a cc company

Re: SQL patterns I use to catch transaction fraud

#12

Post by themafia »

jstanley wrote: post #2

> Real cardholders almost never buy something for exactly $1.00. Coffee is $4.73, gas is $52.81. The roundness is the signal. Surely this depends on how the vendor sets their prices? If you're going to buy something from a website to test a stolen credit card you don't just get to make up your own prices. And I think you may be over-indexing on the US "prices don't include tax" thing. Elsewhere, round-number prices a…

I'm seeing a few stores here and there which have a "round up to donate" option. I guess I'm a bit of a sucker and I always use that option. My groceries are always a round number as a result.

Re: SQL patterns I use to catch transaction fraud

#14

Post by jorisnoo »

achierius wrote: post #4

This seems interesting, but has so many signs of AI writing that I worry it's not just edited but generated from whole cloth. Probably still a lot of truth in there but it does give me pause! > The roundness is the signal. > Slight pain, same result. to point at a few.

> Three filters. That’s it.

And my favourite most hated pattern, the no no no:

> Not machine learning, not graph databases, not whatever Gartner is hyping this year.

Re: SQL patterns I use to catch transaction fraud

#15

Post by vesrah »

maciekkmrk wrote: post #7

What if I go on a roadtrip and suddenly get gas at 2am?

I had this happen once - I flew to a city about 8 hours of driving time away to buy a motorcycle and landed late in the evening. My card was declined when I got gas a little after midnight and I had no cash or other card with me so I called the 24 hour support line. I had a quick conversation with a support agent explaining that I was traveling and the card needed to be reactivated right away. Within five minutes the card was working and I was back to working my way down a long chain of mistakes.

Re: SQL patterns I use to catch transaction fraud

#16

Post by dogscatstrees »

The main problem with these SQL calculations is that they are deterministic shortcuts for a probabilistic problem. Fraud is not usually a “true because rule X matched.” It is more like "what is the probability this is fraudulent"? SQL patterns are useful, but they are blunt instruments. I really don't think banks use deterministic heuristics but more data science stuff.

Re: SQL patterns I use to catch transaction fraud

#18

Post by Niksko »

normie3000 wrote: post #6
jstanley wrote: post #2

> Real cardholders almost never buy something for exactly $1.00. Coffee is $4.73, gas is $52.81. The roundness is the signal. Surely this depends on how the vendor sets their prices? If you're going to buy something from a website to test a stolen credit card you don't just get to make up your own prices. And I think you may be over-indexing on the US "prices don't include tax" thing. Elsewhere, round-number prices a…

Worse than that. Coffee usually _is_ a round number in my experience, and I know of people who aim for round numbers when filling their car, and of fuel stations which require a pre-set value, often 10, 20, 50€ etc

All of that is easy to account for, all of the metadata you need is available. This also applies to the sibling comment about rounding up to charity at the grocery store, the data is all there, even if it's e.g. the fraud analyst at the bank or credit card company instead of the fraud analyst at the grocery store.
Post reply on HN