Anti-fraud decision logic for consumer lending / BNPL
After eligibility checks, add anti-fraud decision rules to the same decision flow. In consumer lending and BNPL, cover Know Your Customer (KYC) checks plus volatility, velocity, and concentration signals.
Use four rule categories:
- Veracity Rules
- Volatility Rules
- Velocity Rules
- Concentration & Networking Rules
Veracity Rules
KYC rules validate submitted data against authoritative sources, such as a national identity database. If your market does not have automated access, verify the data through cross-checks and document analysis.
Cross-check core personally identifiable information (PII):
- Full name
- Address
- Employment
- Date and place of birth
- Identification card number
Verify PII against identity documents. Validate the address with alternative data such as delivery history, utility records, or geolocation consistency.
Cross-check the identification card number against stolen document lists and other relevant blocklists. Apply format rules, issuing authority checks, and expiry validation where available.
Also evaluate these signals:
- Social network profiles
- Phone number
- Email address
- IP address
- Bank account number
- Credit card number
Volatility Rules
Volatility is the difference between previously observed data and the current application. Data sources include your historical portfolio, credit bureaus, and alternative data providers. Some changes are normal, such as a recent job change. Others are signals, such as multiple addresses in a short period.
High volatility can indicate the use of stolen or synthetic identity elements that look plausible but do not persist. Examples include a new mobile number, a first-seen email domain, or a recently opened bank account with no prior activity.
Velocity Rules
Velocity measures how many applications appear for the same identity within a time window. Compute velocity across identity attributes such as address, employer, phone number, email, device ID, IP, bank account, or card number. Fraud rings reuse the same attributes across multiple applications. Include time-aware rules such as
- first seen
- last seen
- average interval between sightings
Concentration and Networking Rules
Concentration and networking rules limit risk from fraud clusters in one location or across connected identities. Concentration can signal an exploited loophole followed by a rapid rise in submitted cases. If left unchecked, it can create a fraud bubble that harms portfolio performance.
Reduce concentration using geolocation controls, sometimes called geofencing in fintech. Set thresholds by region, branch, merchant, or delivery point, and trigger step-up verification when caps are breached.
Networking rules rely on graph analysis with edges built from shared attributes. Useful edges include addresses, phone numbers, IP addresses, device IDs, and funding accounts.
Example rules:
- number of loans defaulted within the nth degree
- number of loans defaulted from the same region
Implement these rules as decision tables and rulesets in your decision logic. Orchestrate external APIs for KYC, device, and geodata checks. Log decision traces so every evaluation is explainable and auditable.
Frequently asked questions
Which time windows should I test for velocity rules?
Start with rolling 1-hour, 24-hour and 7-day windows, then compare them against the application patterns in your own portfolio. Short windows can catch bursts of coordinated applications, while longer windows can reveal slower reuse of identity details. Track first seen and last seen dates too, because a count alone can miss a sudden change in activity.
How should I set a velocity cutoff for an identity attribute?
Set the cutoff from observed application volumes and confirmed fraud, rather than applying one number to every attribute. A shared device may be more informative than a shared address in a multi-person household, for example. Review the approval and decline rates around each candidate cutoff, then adjust for legitimate reuse and the cost of sending more applicants to manual review.
When should a shared attribute trigger extra verification instead of a decline?
Use extra verification when the shared attribute raises concern but does not establish that the application is fraudulent. A shared address or IP address can have legitimate explanations, so consider whether it connects to other suspicious attributes and whether the applicant can verify their identity or funding account. Reserve declines for combinations your team has validated as strong evidence of fraud.
How should I test anti-fraud rules before putting them into the decision flow?
Replay historical applications through the proposed decision tables and rule sets, using only information that would have been available at the time of each application. Compare fraud detection, false declines and manual-review volume across applicant groups, then check results on a later period that was not used to tune the rules. Keep a record of the policy revision and monitor results after release.
