SQL patterns I use to catch transaction fraud

(analytics.fixelsmith.com)

39 points | by redbell 5 hours ago ago

2 comments

  • jstanley 19 minutes ago

    > 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 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".

  • crmd 14 minutes ago

    > Drawback: this doesn’t work until you have history. New accounts have no baseline.

    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.