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 are extremely common.

In fact a lot of the rest of the stuff in the post seems like it wouldn't work very well either. (E.g. you're flagging anyone who has done a transaction in the last 90 days outside the range of hours at which they have 2+ transactions? Wouldn't that be like 50% of people?).

It's unclear to me whether this article is an attempt at breaking down complex expertise into over-simplified SQL queries, or whether it is all speculative and made up.

There is a conflict between "Six SQL patterns I use to catch transaction fraud" and "Nothing here comes from anything I’ve actually worked on or seen".

  If a card swipes in Chicago and seven minutes later swipes in Los Angeles, one of those swipes is fake.

Can also imagine an edge case: couple shares an online account, one is traveling and purchases with the saved card details.

This is an underrated CX factor: If my card gets denied when i’m a new customer or exhibiting a new pattern, i’m impressed with their software.

However if they deny a transaction where there is any previous history of me authenticating, then I’m frustrated by their naive paranoid algorithm.

Or, the cardholder is trying to do the cannonball run:

https://www.youtube.com/shorts/Dx5WPNIEwiE

> The roundness is the signal.

> Slight pain, same result.

to point at a few.