Payment platforms
Card testing attacks are spotted by velocity counters within seconds and blocked before the next attempt.
Core dataFintechPerformance and Scale plans
Real-Time Fraud Detection
Score every payment in the request path with velocity counters, known-bad lists, card frequency and model features, read from one server.
- signals per payment
- 4
- before approval
- In-path
- memory for blocklists
- Constant
Step 1 of 5
Count attempts per card
One counter per card per minute, given a one-minute expiry after the first increment.
Example sessionplaying
# Count attempts per card
hotkv> INCR velocity:card:4f1a:m
(integer) 7
An animated walkthrough with real HotKV commands and example replies. Click any step to jump to it.
The problem
Fraud checks have to happen before a payment is approved, within the latency budget of a checkout. The signals that matter, such as how many attempts this card made in the last minute or whether this device is on a blocklist, are hard to compute quickly from a transactional database.
How HotKV handles it
HotKV keeps the signals ready. Counters with short expiries track velocity, a Bloom filter answers whether a card or device is known to be bad, a Count-min sketch estimates how often a card has been used across the day, and the feature store serves the risk model's inputs. A rules engine or model combines them before the payment goes through.
Step by step
What happens, command by command
- 01
Count attempts per card
One counter per card per minute, given a one-minute expiry after the first increment.
INCR velocity:card:4f1a:m - 02
Check the blocklist
A Bloom filter of known-bad devices in constant memory.
BF.EXISTS blocked:devices dev:8812 - 03
How often today?
A Count-min sketch estimates card usage across millions of cards without a counter per card.
CMS.QUERY cards:today card:4f1a - 04
Model features
Account age, usual country and average basket for the risk model.
FEATURE.GET risk_features account:42 - 05
Decide before charging
High velocity on a three-day-old account. The payment is sent to review instead of the provider.
XADD fraud:review * card 4f1a account 42 score 0.91
Where it fits
Real-world scenarios
Marketplaces
New accounts with unusual baskets and devices on a blocklist are sent to manual review.
Promotions and referrals
Coupon abuse is caught by counting redemptions per device and payment method.
Built in
What you get
Velocity counters
INCR with an expiry per time bucket, down to nanosecond precision.
INCREXPIRENEXPIREBlocklists
Bloom filters for cards, devices and emails.
BF.ADDBF.EXISTSFrequency estimates
Count-min sketches for usage across huge key spaces.
CMS.INCRBYCMS.QUERYModel features
Typed features for the risk model.
FEATURE.GETCommon questions
Can a Bloom filter block a good customer?
It can report a false positive at the error rate you configure, so use it to trigger extra checks rather than a hard decline.
Where do the rules run?
In your own service. HotKV provides the signals quickly so your rules or model can decide inside the checkout's latency budget.
Which plans include it?
Counters and probabilistic structures work on every plan. The feature store is part of the Performance and Scale plans.
Related use cases
Try it on your own workload
HotKV speaks the Redis protocol, so you can point an existing client at it and run these same commands.