u/ExtremeProgress2201

I’m looking at the grey area between approving a payment and sending it for manual review.

An extra authentication step can give you more information, but it also adds delay and customer friction.

How do teams usually judge whether another check is actually worth it?

For example, if a 3DS challenge or customer confirmation only changes the final decision in a tiny fraction of cases, would you still run it because the fraud downside is large?

Or is there a point where the information simply isn’t worth the extra friction?

I’m trying to understand how this trade-off is handled in practice rather than assuming that “more evidence is always better.”

A lot of fraud features depend on comparing the current transaction with what the customer normally does.

But I’m not sure how far back “normal” should go.

Someone’s behaviour can genuinely change - new country, new job, different spending pattern, new phone - and the fraud system itself can also change over time.

If you work with this kind of data, what normally makes you decide that older behaviour is no longer comparable enough to trust?

Is it mainly age of the data, a major behaviour change, system changes, or something else?

I’m trying to avoid building an agent that treats every deviation from an old pattern as suspicious forever.

One thing I’m struggling with in transaction fraud is that the clearest label can arrive much later than the original decision.

A chargeback or confirmed fraud report might take days or weeks, but the system still has to make decisions now.

What earlier signals do you actually trust enough to use before that final outcome exists?

For example:

• successful/failed authentication,
• customer confirmation,
• analyst review,
• account activity after the transaction,
• something else?

I’m especially interested in what you would treat as useful evidence but not ground truth.

I’m building a small probability-based transaction decision model, not a production fraud system.

A problem I’ve run into is that some of the evidence clearly isn’t independent.

For example:

• new device
• new IP
• location mismatch

could all be caused by the same underlying thing, like the customer travelling or switching devices.

If I update the fraud probability as though all three pieces of evidence are independent, I’m worried I’ll make the posterior much more confident than it deserves to be.

For a small prototype with limited data, what would you consider the simplest defensible way to handle this?

I’m not looking for the fanciest model - mainly something I can explain and test without pretending the signals are independent when they obviously aren’t.

I originally treated a sudden location change as a fairly strong fraud signal, but the more I read about it, the less comfortable I am using it by itself.

Travel, VPNs, mobile networks, new devices, etc. can all make a legitimate payment look strange.

If you see a customer buying from a new location, what other signal would make that location change actually matter to you?

For example, would you care more if it came with a new device, unusual amount, high transaction velocity, or something else?

I’m mainly trying to understand when location is genuinely useful evidence and when it just creates false positives.

I’m working on a small transaction-risk decision agent and one part I’m unsure about is what should happen in the grey area.

Say a transaction has a few weak signals - maybe a new device, unusual amount, or location change; but nothing strong enough on its own to decline it.

My current idea is to try one more useful check before sending it to manual review, something like customer confirmation, extra authentication, or a deeper history/device check.

For people who actually work with payment fraud: what usually makes you say -

“check one more thing” instead of “send this to an analyst”?

And is there a check that sounds useful in theory but rarely changes the decision in practice?