Live data from Hacker News

SQL patterns I use to catch transaction fraud

analytics.fixelsmith.com

81–90 of 138 posts

Re: SQL patterns I use to catch transaction fraud

#81
> If their card does, it’s either being used by someone else or they’re traveling — and travel produces other signals you can check.

Signal's he can check? So some random dude is looking at my credit card purchase history while playing around with his SQL queries?

Re: SQL patterns I use to catch transaction fraud

#82
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…

The article is LLM-generated.

Re: SQL patterns I use to catch transaction fraud

#86
post #75

Hacker News, we need to talk! "Fixel Smith" is an AI-generated person, with an article that has very little to do with fraud analysis. 'This' is also a music artist (1), novelist (2), fraud analyst (3), influencer (4), and whatever else you can imagine. 220+ points and 70 comments, and very few notice it's quite a fake post — and no one that it's an AI generated person? 1. https://www.amazon.it/Forged-Soundtrack-Expl…

I was checking the submission on the phone and only peeked at the comments section. While it's not always easy to judge if something is AI-generated or edited, here it was obvious at first glance from the quotes. Assuming that all of the comments were done in good faith, I think that the low AI literacy even here is really concerning.

>Assuming that all of the comments were done in good faith

Well,sure. But some people come here just for the comments and don't read the articles

Re: SQL patterns I use to catch transaction fraud

#88
After 35 years of building software systems I've learned to temper my hubris. These days I rarely assume things to be "definitely true".

For example "Impossible travel": these days you can add your credit card to your phone and use Apple Pay. Well, this is useful for many things, one of them being adding your credit card to your kid's (teenager) phone, so that your kid can use your card in case of need/emergency when they are away from you. I did exactly that recently and actually worried about fraud control systems when my child paid using my card in Boston while I was in Europe.

Many things which you think are true might not be.

Anecdotally, US banks are terrible at building fraud control systems. It seems US banks assume any transaction that is charged by an entity outside the US is fraud. In my 10-year history of running a SaaS, the US banks and their "fraud control" systems have been one of the biggest billing problems.

Re: SQL patterns I use to catch transaction fraud

#89
post #88

After 35 years of building software systems I've learned to temper my hubris. These days I rarely assume things to be "definitely true". For example "Impossible travel": these days you can add your credit card to your phone and use Apple Pay. Well, this is useful for many things, one of them being adding your credit card to your kid's (teenager) phone, so that your kid can use your card in case of need/emergency when…

Apple Pay & Google Wallet are actually considered lower risk by card brand than other card transactions because Apple and Google have so much tracking and biometrics on you, the phone must be unlocked and pin entered to pay. My company gets lower rates on these types of transactions than regular card transactions, lower rates because fraud is paid for by the fees, less fraud for a transaction type, lower merchant rates. So likely those transactions your kid does on their phone are flying way below the fraud threshold to trigger, even if it hits one trigger like “impossible travel distance”.

Re: SQL patterns I use to catch transaction fraud

#90
In reality, most banks perform a lot of these transaction checks in real time to block fraudulent txes up-front, instead of validating tx legitimacy retroactively at a point where the money is already gone. Some 15 years ago a security rep with Nordea (a large Nordic bank) called me late at night asking if I was currently in South Korea and had just a minute ago used my card in a shop. Someone had initiated a "card present" purchase with my card for 1337 SEK (I'm certain this amount was intentional), which Nordea automatically blocked as it was near the edge of possibility relative to my previous card swipe in Sweden earlier in the day, and they wanted to make sure they weren't about to mistakenly strand me abroad by blocking the card.
Post reply on HN