Live data from Hacker News

SQL patterns I use to catch transaction fraud

analytics.fixelsmith.com

51–60 of 138 posts

Re: SQL patterns I use to catch transaction fraud

#51

Earlier quoted context omitted.

> 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)

Not everything of course, not because of a few phrases, not your comment. But the recent omnipresence of these is just hard to ignore.

Re: SQL patterns I use to catch transaction fraud

#52
post #18

Earlier quoted context omitted.

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.

The article is about the US and your example uses Euros, so I don’t think your experience applies here.

Re: SQL patterns I use to catch transaction fraud

#53
Some of these heuristics are dystopian to no end.

> Most people are creatures of habit when they spend money. A nine-to-fiver doesn’t suddenly start buying gas at 3am.

Breaking out of a habit once in a while is what keeps one's mind sharp.

A big "fuck you" to financial analysts with those groundhog-day mindsets for making my life much more miserable than it needs to be and for adding a chilling effect to those little getaways that make life interesting and worthwhile. I despise you for this.

Re: SQL patterns I use to catch transaction fraud

#54
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.

Ive always suspected that this is all of a tax dodge, a money spinner, and a pr exercise "we gave xxx to charity" - no, your customers did.

Just set up a direct debit to your favourite charity.

Re: SQL patterns I use to catch transaction fraud

#56

Earlier quoted context omitted.

> 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)

Nah, human writing will bleed through as imperfect (in a quaint way).

Re: SQL patterns I use to catch transaction fraud

#57
We develop tirreno (1), an open-source security framework.

I question the described approaches. For example, while impossible travel is a legitimate and widely used technique, it's related to online user behaviour based on IP address. Moreover, tirreno, for example, has separate rules for cases where the IP clearly comes from Apple Relay or VPN/Tor — those are separate flags. I assume some or all examples are LLM-generated, as the context is mixed up and no one actually collects GPS location in bulk for card swipes.

1. https://github.com/tirrenotechnologies/tirreno

Re: SQL patterns I use to catch transaction fraud

#58

> Border crossings inside 10 minutes. International rings. Or normal people living in Europe in border-adjacent areas. Also, I guess you don't include card-not-present transactions in this, but you incorrectly assume that every merchant has their location set correctly. And that every sale happens in a brick-and-mortar establishment, not from travelling salespeople or whatever. And that all transactions happen online…

Even US -> CA was maybe 10 min when I crossed a few weeks ago...

Re: SQL patterns I use to catch transaction fraud

#59

> Border crossings inside 10 minutes. International rings. Or normal people living in Europe in border-adjacent areas. Also, I guess you don't include card-not-present transactions in this, but you incorrectly assume that every merchant has their location set correctly. And that every sale happens in a brick-and-mortar establishment, not from travelling salespeople or whatever. And that all transactions happen online…

Even US -> CA was maybe 10 min when I crossed a few weeks ago...

Is it possible that you are actually in a transnational crime syndicate without knowing it?
Post reply on HN