Antifraud Hub
Read the articles, then see how your confirmed-fraud list and vendor checks become one decision.
- IP reputation tools for fraud and bot decisions
- Anti-fraud operations models for your business
- Fraud rule engines: complex policies and third-party data
- Deepening our understanding of BIN attacks: an advanced analysis
- The fallacy of evading fingerprinting by disabling JavaScript
- Canvas fingerprinting: a stealthy technique for tracking
- Why case management matters in anti-fraud work
- Centauri: a new approach to device fingerprinting
- The conflict between data minimization techniques and the rise of fraudulent synthetic profiles
- Detecting potential merchant fraud in point-of-sale consumer lending and BNPL
- Event-driven antifraud in eCommerce: using behavioral analytics and a rule engine to prevent fraud
- The evolution of browser fingerprinting
- Media device fingerprinting: a modern approach to online tracking
- Evercookie: the persistent tracking mechanism
- Using a rule engine to tailor your antifraud strategy
- Improving login security with a rule engine: how configurable rules can protect against account takeover and bot attacks
- What ArkOwl can reveal about an email address
- Application fraud after refusal and which cases need review
- Application fraud checks for deciding which applications to refer
- Fraud checks for night loan applications need history
- Fake employer loan applications and when concentration warrants review
- When early loan repayment merits a fraud referral
- Breached password checks for sign-up and login decisions
- Pwned email results guide application and login decisions
- Fingerprinting Alternative to ThreatMetrix
- Using distance calculation with the spherical law of cosines to detect fraud in ecommerce
- Tools used in online fraud prevention
- ETags: a subtle web tracking mechanism
- Subdomain verification for email authentication
- WebGL fingerprinting: tracking online users through graphics rendering
Frequently asked questions
Which identifiers should I use to match confirmed fraud to new transactions?
Join confirmed-fraud records to new transactions on the strongest stable identifier you have, such as a payment token or account ID. Keep the identifier type and match confidence with the result, because a shared device, phone number, or IP address can connect unrelated people. Treat weaker matches as review evidence, not an automatic decline.
How far back should my confirmed-fraud list reach?
Compare 30-, 90-, and 180-day lookbacks against fraud labels that have had time to mature. Choose a window that captures repeat fraud relevant to your product and identifier lifespan. A long window can make recycled phone numbers, devices, or payment details look more suspicious than they are.
What should my fraud decision do when a vendor check times out?
Set the fallback by transaction risk and the cost of delay. For a high-risk transaction, send it for review or pause it if your team can respond in time. For lower-risk traffic, use the signals already available. Record a timeout as missing data, not as a clean result, and monitor timeout rates and response times.
How often should I refresh the confirmed-fraud list?
Update the list as soon as confirmed outcomes reach your system, and remove or recheck records when a fraud finding is reversed. Keep the date and source of each confirmation so older matches can be weighed against newer evidence. A list that only grows can keep flagging recycled identifiers and resolved disputes.
