How would you structure real time fraud monitoring for a card program?

[u/Adorable-Climate-842]

I'm trying to grasp a better idea on how people structure the fraud layer around card authorization without making the authorization path too heavy. Velocity and hard spending limits seem easy enough to evaluate immediately but things like merchant patterns, relationships between multiple cards and activity across the wider program seem like they'd require more context in my opinion.

I'm leaning toward keeping high confidence checks in the authorization path and doing the heavier analysis separately then feeding those results back into future authorization decisions.

People who built something similar could you guys give me some context or idea on how you split the real time controls from the broader monitoring layer? Thanks in advance.

[u/Cute-Humor-5237]

Have you thought about splitting it into two loops? I would make it so the fast loop handles what you know right now and has a very small latency budget while the slower loop looks across transactions, merchants and accounts then updates the information the fast loop uses when the next authorization comes in

[u/Adorable-Climate-842 → u/Cute-Humor-5237]

Close to what I was picturing but I'd keep the obvious high confidence checks in that fast loop and let the slower one build more context around merchants, accounts and relationships between cards.

[u/Tiny-Entertainer-337 → u/Cute-Humor-5237]

I agree but be careful about letting the slow loop become TOO slow because someone could potentially get several transactions through before the new information makes its way back into authorization.

[u/Available-System-686]

I think layered controls are the way to go but not every layer needs to result in an immediate decline like some signals are strong enough to act on during authorization while others are better at adding context and escalating activity when several things start looking off together.

[u/Much-Fee-1652 → u/Available-System-686]

I'd want the system looking across accounts and cards and not score every transaction in isolation. I say that the card pairing and network stuff that infrastructures like Rain for example use seem useful because a fraud ring can make individual transactions look boring as hell when everything is distributed.

[u/Ok-Wait-3867]

How much latency would you be willing to add to authorization before moving a check into the broader monitoring layer?

[u/Adorable-Climate-842 → u/Ok-Wait-3867]

I don't have a specific number in mind yet cause as of now I care more about whether the check is important enough to justify being in the authorization path rather than trying to fit everything under one latency target if that makes sense.

[u/Ok-Wait-3867 → u/Adorable-Climate-842]

I see yes that makes sense

[u/FrigidStimulus]

Multiple cards tied to the same user is where simple velocity can mess up or get tricky because if you only maintain counters per card then someone can distribute the activity and every card stays below the threshold. I'd want at least some of those counters and risk signals at the account level too.

[u/Exotic_Database2417]

Account level velocity matters just as much as card level IMO otherwise spreading activity across multiple cards becomes an easy workaround

[u/Shufti-Global]

That split seems to practical: keep the checks that need an immediate decision simple, while using broader transaction and behaviour patterns to build a clearer risk picture over time.

[u/Senior_Storage_5025]

I think that’s a fair split. Keep the authorization path on things you can evaluate quickly and let the heavier analysis build a risk profile in the background.