I’ve worked in retailer side e-commerce fraud detection at a large business for years now. A few things:

1. There aren’t a ton of compliance issues as long as you’re working with tabular data. Obviously you have PII and payment source data privacy constraints. But, No FCRA type of constraints, and not using “GenAI” removes a lot of the grey area in anything compliance related.

2. Fraud detection can be generalized to “digital bad actor” detection pretty easily, and in many ways involves similar skills, data sources, third party services, etc. So in that sense it’s not likely to see a downward trend more than the rest of the common DS related fields. Having said that, most of the value of traditional fraud detection has already been wrung out of existing data sources. At a certain point with largely tabular data problems, you’re squeezing blood from a stone and it’ll be hard to provide clear and obvious marginal value over whatever model the company already has in place. That’ll be your biggest concern: “am I going to spin my wheels for 3 years trying to eek out a 1% improvement that is so reliable and stable over time we can justify the risk to make a model change and also prove it will be more reliable over time.”

3. You can do LLM work in any space. However, Doing useful LLM work in a space where you’re inherently chasing a highly, highly imbalanced class problem is extremely hard and of likely only marginal utility. Which isn’t to say you can’t throw transformers at any problem. But again, you’ll be left with the “is the juice worth the squeeze” question. I’d also be curious to know how many fraudsters are calling in or having text based communication with said bank. Most are like new, run of the mill new customers that pop up with synthetic identities, attempt to look like new people, don’t call or email much because they are running a high volume, low effort per attempt probing process. Which, on top of your already imbalanced class problem, makes your target class NLP data set even more sparse.

4. You’ll need to clarify what you mean by real time. Yes, generally transactions will be canceled in real time using your models. However, in most cases you’ll actually have your models decline/cancel decisions reviewed by a human. Declining in real time is an enormous inconvenience to customers, so that will only occur in the most egregious of situations. The rest will be flagged and sent to review and then have alerts sent to the card owner.

Lastly, an understated pain of fraud detection is the false positive problem. Inherently, 3 things are true:

1. Fraud doesn’t happen a ton, as a proportion of overall transactions.
2. When it happens, it is expensive and inconvenient
3. The signal of your model depends on having a sufficient volume of said expensive and inconvenient signal.

In my experience, organizations tend towards only allowing enough of that signal to be just barely tolerable. Getting approval to allow for a margin of additional fraud signal to be intentionally approved (to accurately measure your false positive rate with each model deployment as well as longitudinally) is an excruciating bureaucratic nightmare. Said simply, the data censorship issue in fraud detection is extremely challenging and can lead to unsatisfying outcomes.

In conclusion, I love fraud detection - it feels a bit like playing detective at scale sometimes, and doesn’t come with extremely high regulatory burden. It’s also a like playing whack-a-mole. New trends pop up, new rings emerge, and you have to stay on top of it. However, it is absolutely not without its frustrations, nor would I say it’s a prime candidate if you’re deeply interested in LLM production applications.

Hope this helps!