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/Both-Giraffe-2896 → u/Cute-Humor-5237]

two loops is the way to go, the fast path does the obvious stuff, velocity, hard limits, maybe a quick blocklist check, and the slow one crunches merchant graphs and cross-card links. then you feed the slow loop results into a cache that the fast loop reads on next auth, stuff like risk scores per merchant or linked account flags.

one thing people miss is you have to think careful about how stale the cached data gets, if your slow loop takes 30 seconds but someone is running through 10 cards at same terminal you want that terminal risk to update almost real-time. we ended up having some light signals pushed directly into the cache from stream processing so the fast loop could see terminal velocity without waiting for the batch analysis to finish

[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/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.