This takes me back, fighting telephone fraud back when folks use to accept cc over the phone. We used similar patterns but only had phone numbers and the white pages. Cross state boundaries inside similar time frames and categorizing similar merchant types. It’s fun to see these same patterns still in use 20 years later for the same purpose.
SQL patterns I use to catch transaction fraud
21–30 of 138 posts
Re: SQL patterns I use to catch transaction fraud
#222 can be genuine use. I let my partner use my card and I use it on my phone as rfid. Maybe ignore phone usages since they are secured pretty well.
They can distinguish a physical card vs Apple Pay
Re: SQL patterns I use to catch transaction fraud
#232 can be genuine use. I let my partner use my card and I use it on my phone as rfid. Maybe ignore phone usages since they are secured pretty well.
All of them can be genuine use, these are fraud signals not fraud proofs, and the article does cover this:
> What works is running them all and scoring each transaction across the signals. A transaction that fails on three or four of them is almost always fraud. A transaction that fails on one might be your grandma being weird with her debit card on vacation.
Re: SQL patterns I use to catch transaction fraud
#242 can be genuine use. I let my partner use my card and I use it on my phone as rfid. Maybe ignore phone usages since they are secured pretty well.
Exactly, hopefully this is not an autoblock in the future.
> A transaction that fails on three or four of them is almost always fraud. A transaction that fails on one might be your grandma being weird with her debit card on vacation.
Re: SQL patterns I use to catch transaction fraud
#25What if I go on a roadtrip and suddenly get gas at 2am?
As the tail end of the article explains these are independent pieces of evidence not independent proofs: most of them can be legitimate operations (even the speed one, airliners cruise at that speed but if you get to ride a long-range business plane they can cruise faster).
Re: SQL patterns I use to catch transaction fraud
#26Isn't the point of ML that you learn these rules from the data? The right approach to me would be to use ML models to detect patterns that correspond with fraud and then evaluate them to see if any make sense. This way you might discover new hyptotheses.
Re: SQL patterns I use to catch transaction fraud
#27This 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.
Oh shyte, I use (and have used) these for a long time. Guess everything is classes as AI nowadays just yield and use it (everyone thinks you do anyway)
Re: SQL patterns I use to catch transaction fraud
#28This is the sort of thing I used to love doing and I often gaze at raw data analysis and sometimes wish my career had pivoted towards working with data like this.
But I must admit there was a point where I suddenly lost my love for SQL and it was pretty much when the OVER PARTITION BY syntax appeared.
It never clicks. I always have to look up how it works, I always find it unintuitive. I've never understood why I hate it so much.
Re: SQL patterns I use to catch transaction fraud
#29Earlier quoted context omitted.
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.
I don't need to account for it - I'm just stating that this doesn't match my experience:
> Real cardholders almost never buy something for exactly $1.00. Coffee is $4.73, gas is $52.81. The roundness is the signal.
Re: SQL patterns I use to catch transaction fraud
#302 can be genuine use. I let my partner use my card and I use it on my phone as rfid. Maybe ignore phone usages since they are secured pretty well.
All of them can be genuine use, these are fraud signals not fraud proofs, and the article does cover this: > What works is running them all and scoring each transaction across the signals. A transaction that fails on three or four of them is almost always fraud. A transaction that fails on one might be your grandma being weird with her debit card on vacation.
> If a card swipes in Chicago and seven minutes later swipes in Los Angeles, one of those swipes is fake. The card is cloned. This is the most uncontroversial fraud signal you’ll find — there’s almost no legitimate reason a single card is in two distant places in seven minutes.