Or, “rules-based logic encoded in SQL queries without any backing data”.
Bunch of thresholds, no data proving those thresholds are meaningful.
SQL patterns I use to catch transaction fraud
131–138 of 138 posts
Re: SQL patterns I use to catch transaction fraud
#132> 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 "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.
Oportunistic thieves sure, but more knowledgweable thieves would 100% try to replicate more normal usage patterns, like buying gas just after normal work hours
Re: SQL patterns I use to catch transaction fraud
#133Earlier quoted context omitted.
> It's definitely a real post. The fact that the 'person' behind this post managed to publish a novel, a music album, and a few posts on fraud prevention all within a few days this month is enough for me to redflag it. > you don't have any real criticisms. Please check once again, I've already given my opinion on the article itself below. Here it is again for your convenience. > I question the described approaches. F…
Yeah the content of the post is totally bogus, but it's still a real post. The post exists, you can read it. A fake blog post would be something that purports to be a blog post but actually isn't. This is definitely a real post.
> A fake blog post would be something that purports to be a blog post but actually isn't.
What would be a possible example of this?
Re: SQL patterns I use to catch transaction fraud
#134Earlier quoted context omitted.
Yeah the content of the post is totally bogus, but it's still a real post. The post exists, you can read it. A fake blog post would be something that purports to be a blog post but actually isn't. This is definitely a real post.
> A fake blog post would be something that purports to be a blog post but actually isn't. What would be a possible example of this?
I don't know, I'm not the one pointing at things and saying they're fake blog posts!
But examples might include something that looks at a glance like a blog post, but actually it's all just squiggles instead of words.
Or a link on the home page that looks like there's a blog post, but when you click it it's just a YouTube video.
Re: SQL patterns I use to catch transaction fraud
#135> 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…
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
I’ve always fancied landing on a round number at the pump, kind of a little game I play lol. Glad it’s never set off any alarm bells for my bank
Re: SQL patterns I use to catch transaction fraud
#136Isn'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.
Anything that can't be explained and iterated deterministically is too risky for the business of declining financial transactions. Human analysts need to be able to explain to compliance in a single 5 minute email why a specific transaction was declined, and most importantly, what could have been done differently to avoid the adverse decision. Fixing one problem with ML often creates two new problems that aren't quit…
Interpretable models can create rules like what you see.
Re: SQL patterns I use to catch transaction fraud
#137Re: SQL patterns I use to catch transaction fraud
#138I 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…
[flagged]
There's no such rule.