▲ 320 points
back
130 comments
> 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".
The "transaction outside usual hour range" seems pretty basic.
I don't usually buy gas, coffee or snacks at 2am. But on the very rare occasion that I do, I'm dealing with some kind of personal emergency and don't also want to have to call my bank.
I get that that's also a time opportunistic thieves, etc, might be operating. But the cost of false positives is also a thing.
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
Yeah I was in a bar one night and was peckish, so tried to buy a packet of crisps. They said minimum spend on card was £5, so I said just charge me the £5 it's fine.
Card got blocked as they thought it was fraud. Annoying! And not something inebriated me wanted to deal with at 2am.
Ok. Maybe they protected me from myself, but still!
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.
I do not know if this is still used anywhere, but in the past there were places, e.g. hotels or car rental services, where the validity of a credit card was tested by a $1.00 transaction, before booking a room or renting a car.
This is also
a) trivial to bypass by adding dither to the test transactions and
b) trivial to improve upon with proper statistical analysis and
c) shouldn't this kind of heuristic pattern recognition with no expectation of near-100% accuracy be what AI is good at?
Their approach to “Suspicious merchants” also confuses me: the description doesn’t make logical sense to me and doesn’t match the abuse pattern as far as I understand it.
> When a skimmer compromises a card reader at, say, a gas pump, you don’t get one fraud case. You get dozens. Every card swiped at that pump for the next few weeks is now in someone’s database. So the symptom from the merchant side is: an unusual number of unrelated cards spending more than usual, in a short window.
So he checks for hour-bucketed increases in high-value transactions originating from that merchant.
Seems to me like a good way to catch a sale, an opening, a launch event, or a product “drop,” a single high-value sale that somebody spreads across several cards… less so a good way to detect a steady trickle of stolen card data that’s inexplicably used back at the same merchant.
If you’re installing a card skimmer, why would you charge the stolen cards at the same business where you’re stealing them? And why would you concentrate your spending into bursts if the skimmer’s harvesting all day every day?
If you’re the merchant doing the skimming in order to spend at your own store, wouldn’t it be easier to punch a higher amount into the terminal? If you’re a skimming ring, wouldn’t you prefer to have purchasing power rather than this $5000 threshold (?!) of extra gas (plus a giant neon sign advertising where you placed your skimmer)?
Wouldn’t a more sensible approach involve something like looking for merchant clusters in the combined transaction histories of known-stolen accounts?
The LLM runs so strong in this whole enterprise… I want to give the person the benefit of the doubt, but I can’t resist the sneaking suspicion that LLM fabulism to push a slop novel just wasted 15 minutes of my life.
The article is LLM-generated.
Reading this to the very end uncovers empty and contradictory advice. I'm almost sure it's LLM generated.
We learn simultaneously that 'your team' shouldn't rely on any one of those patterns ('none of them is enough'), but that pattern 1 'alone will surface a useful amount of fraud'.
We also read strange sentences like "Every analyst on your team will use them (ie window functions) once they exist, and adding the next fraud pattern stops being a project. [end of paragraph]"
Or irrelevant discussions about how filtering by "IS NULL" might be not applicable when almost none of the provided examples uses it (and the one which does uses it in different context).
This is low quality and too long.
> 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...
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-Explicit-Fixel-Smith...
Hacker News has developed recently a frustrating habit of upvoting such low quality AI sloppy submissions.
Makes me wonder if this AI flood uncovers the unflattering truth about this community acuteness, or it's only a failure of existing guardrails and we just need to change them.
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.
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.
This 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.
> Fraud detection in transaction data is mostly SQL. Not machine learning, not graph databases, not whatever Gartner is hyping this year. SQL, run against the right tables, with the right joins, looking for the right shapes.
It's also not all program-integrity, which is the only work that could justify such blanket statements. Worse is better as long as it addresses the problem domain.
Fintech clients are generally interested in knowing whether a transaction happening _right now_ is fraud. They want to know that in a few milliseconds, for high-dimensional data. It's work done at a scale where relational databases cannot meet these real-time constraints, and instead find other uses like historical data loading. That's how you end up with in-memory databases, stream-processing engines, and yes, even machine learning.
Having said that, some of the author's points are valid, and I'm looking forward for their next writings, in particular dealing with noisy alerts is a general problem beyond performance engineering.
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.
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.
> 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.
Isn'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.
I agree the post looks a little AI written but generally this kind of analysis is quite common. Leaving aside human heuristics that are generally too well known to catch real scammers (like time travel or "7 days", which is bad because often weekly patterns are important so at the very least look at 10 days) and actually have low precision, what I find odd it that all results just return a user ID.
So this is really just surfacing cases, but with not enough context to be useful to prioritise. I would expect a score to be included.
Apart from that it misses a lot of signals like refunds, declines, disputes etc [1].
1) https://stripe.com/gb/guides/improve-fraud-management-with-r...
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.
What if I go on a roadtrip and suddenly get gas at 2am?
This 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.
2 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.
The main problem with these SQL calculations is that they are deterministic shortcuts for a probabilistic problem. Fraud is not usually a “true because rule X matched.” It is more like "what is the probability this is fraudulent"? SQL patterns are useful, but they are blunt instruments. I really don't think banks use deterministic heuristics but more data science stuff.
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.
> Views are mine, not my employer’s.
What about the tables?
> If a card swipes in Chicago and seven minutes later swipes in Los Angeles, one of those swipes is fake. The card is cloned.
Or, the cardholder is trying to do the cannonball run:
This is quite interesting, but the blatantly AI generated explanations are like an anti-signal for quality
Article was written by AI (dozens of give aways), so take the content with a grain of salt! They author could not be bothered to write it by hand, yet demands your attention to read it. I'm not even sure which parts are based on his prompt and which were hallucinated... How to butcher what could have been an interesting article... sigh
> 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?
These seem like reasonable interview questions. Otherwise, these seem very basic and naive.
This is very cool to read. Although I've never truly worked in fraud prevention, I stumbled into automating a lot of similar pattern checks to catch collusion and fraud when I wrote and ran a poker site / casino. Window functions were not available then so the queries were LONG. One way I'd deal with it was to assign uuids to every pair of players who'd ever shared a poker table, and then run nightly analysis of how much their betting deviated from expected norms and their own baseline on each stage of the game if they were in the same hand as each other. This could actually be done in one or two magnificent 100+ line SQL queries on the history table, on a read replica.
Lagging window functions and/or lateral joins probably would have reduced it to 1/4 the size but definitely increased the cost versus just narrowing the sets into smaller tables first.
These all seem pretty elementary TBH. they focus on identifying fraudulent transactions, vs (IME) the more valuable deciding if a transaction is fraudulent. This is totally double today. Example: instead of some sort of "outside of normal transaction" you can confidently determine that "coffee at 2am" is likely fine, if they also bought gas 10 minutes earlier from the same merchant, dinner 300 miles away at 7pm, and again gas 8 hours ago in their home town.
Or, “rules-based logic encoded in SQL queries without any backing data”.
Bunch of thresholds, no data proving those thresholds are meaningful.
Wait, you can clone a credit card? Why don't they use a public-private key pair?
the real question is whether you would point hour agentic system at this blog post and create
chargeback-mcp
or would you turn it all into a markdown file and call it a skill?
Fascinating stuff. More please :/)
How do you deal with vacations and online shopping. You could be in another country or two in a few hours and purchase from across the world
This is AI slop, as has been pointed out by several other commenters. Flagged.
This is gold, mate. Much obliged.
I feel like if you've done any kind of investigation work then this is the normal baseline.
People here provide counterexamples to show this article is bullshit. Don't forget, fraud detection is about statistics. Outliers always exist.
Machine learning systems also learn your pattern. The article gives simple SQL rules. Don't dismiss this article as worthless.
Obligatory in any discussion of money fraud: https://www.bitsaboutmoney.com/archive/optimal-amount-of-fra...
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.