fraud & risk strategy

strong onboarding.
continuous monitoring.
rapid reaction.

the approach that has held up across wallets, lending, and payments. i build fraud systems around them - starting from the data, ending with closed feedback loops that keep evolving.

8+years in fraud and risk
3domains, zero to one
90%fraud loss reduction
download cv ↓
core principles
onboarding is where most fraud is won or lost
Bad actors are easiest to stop before they transact. Risk tiering at signup, device and geo checks, blacklist screening - the work done at the front door means less work everywhere else.
you can only react to what you can see
Before rules, models, and dashboards - the right signals need to flow into one place. Device, location, IP, transaction behaviour. A detection system is only as good as its data layer.
short feedback loops beat perfect systems
no fraud system is ever finished. build something, measure it, find what it misses, fix it. confirmed fraud cases should feed back into the model automatically. a system that stops learning goes stale fast - particularly in fraud, where the MO keeps evolving.
case study 01
platform

the rule engine
i'd build today

i've built two from scratch: one on metabase queries at fampay, one on a vendor engine at poptech. neither gave ops the thing they needed most: seeing what a rule costs before it goes live. this is the spec for the one i'd build now, and you can run a prototype of it below.

the problem, from first principles

a rule engine doesn't catch fraud. it allocates two scarce things: user friction and analyst minutes. every rule is a bet with three costs: the fraud it misses, the good users it blocks, and the review queue it creates.

most engines are designed to maximise catches. i'd design one where all three costs are visible before a rule is switched on, so the argument between growth and risk happens over numbers, not adjectives.

constraints i'd design for
  • decides in under 200ms on the payment path. anything slower gets bypassed.
  • ops can change a rule without engineering, and every change is versioned with who and why.
  • every rule explainable in one sentence to an analyst and to a regulator.
  • nothing goes live without shadow mode.
  • confirmed fraud flows back automatically, so precision is a live number.
what i'd build, in this order, and why
01
signals before rules
device, ip, geo, account age, velocity and payee history go into one table, on every event. why first: a rule on data you don't reliably have just fires on nulls.
02
a readable rule language, with shadow mode
rules are plain conditions (velocity_1h ≥ 3), not sql. each has a name, an owner, points and a switch: off / shadow / live. why: shadow lets you see what a rule would do before it touches a real user.
03
scores and bands, not binary rules
rules add or subtract points, and the score lands in allow / review / block. two thresholds, owned by risk, movable in minutes. why: when an attack changes, moving the threshold is faster and safer than writing a new rule.
04
ops tooling: block, unblock, audit
bulk and section-level blocks, one-click unblock with reason codes, and an audit log that answers "who blocked this and why." why: it's unglamorous, but it's where analyst hours actually go.
05
the feedback loop
every confirmed case tags the rules that fired and the ones that missed. precision updates continuously, and a rule below its floor proposes its own threshold change. why: the system proposes, a human approves, and the engine doesn't go stale.

deliberately not in v1: ml models (you need labels before you can learn from them), graph features (v2, once device and payee links are clean), and any vendor you can't export rules from. the engine should be boring. the decisions shouldn't be.

working prototype
threshold: the engine, running on one day of transactions
toggle rules and shadow mode, drag the review and block lines, open any transaction to see why it scored what it did, clear the review queue yourself. every number is computed live.
open the prototype →
how i'd know it's working
  • every live rule stays above a precision floor, or it goes back to shadow
  • the review queue stays inside analyst capacity every day, not just on average
  • a rule change takes under an hour, needs only ops, and leaves an audit trail
  • coverage: the share of confirmed fraud hit by at least one rule
  • the false-block rate on good users is reported next to fraud loss, never below it
what i'd probably get wrong

i'd over-tune for precision and under-weight friction. i've spent eight years being the one called when fraud gets through, never the one called when a good user churns. the friction guardrail is there to correct for me.

track record
fast growth outpaces fraud risk. i've spent my career in that gap - connecting data, operations, and compliance before it becomes a problem.
Aspora
AsporaJun 2026 - Sep 2026
product manager, fincrime
rule engine migration fraud observability chargeback fraud
Led the migration of fraud rules from one rule engine to another across the UK, EU and UAE corridors.
Built fraud observability for the FinCrime stack, so attack patterns showed up early. It led directly to two catches: US checkout card chargeback fraud and referral fraud.
For the chargeback fraud: tightened the process with 3DS, fixed a couple of bugs, and set up a chargeback dispute procedure to raise the win rate.
Took product features for KYC checks live.
rule engine migrationfraud observabilitychargeback fraud3DSreferral fraudKYC
POPTech
POPTechJun 2025 - Jun 2026
fraud and risk manager
ATO mitigation first party fraud NPCI · ISO 27001
Built the entire fraud framework end to end across a platform of 10M+ users: chargeback procedures, investigation SOPs, UPI and RuPay transaction monitoring, cashback and coin fraud detection, Shop order and RTO monitoring, a block management feature, and a fraud attack mitigation and recovery plan.
Built anomaly detection systems, real-time dashboards, and investigation SOPs that eliminated SIM binding fraud, SMS spoofing, referral fraud, and coin farming entirely.
Identified and stopped an active ATO attack - immediate friction changes on day 1 reduced incidents by 70%, fully eliminated within 4 days.
Caught and closed a cashback loophole that was actively being exploited - losses dropped to zero within days of the fix. Caught first party RuPay card-to-cash abuse (velocity checks and refund friction) and RTO abuse in Shop (pattern detectors for order, return, and geography clustering).
When a fraud incident hit, worked with the data team to build a risk scoring model - mapping confirmed fraud user patterns across transaction amount, merchant category, error codes, and failure rates. Model kept evolving as new inputs came in, with a plan to integrate directly into the rule engine as a live feedback loop.
Implemented an AI typology based pattern detector seeded from confirmed fraud cases.
Compliance: built the compliance calendar, managed audit policies on Sprinto, liaised with InfoSec end to end, and drove audit readiness for NPCI, ISO 27001, PCI DSS, SOC 2, and DLSAR - zero lapses across 5 certifications.
ATO mitigationfirst party fraudrisk scoring modelanomaly detectionai pattern detectorNPCIISO 27001PCI DSSSOC 2DLSAR
Kissht
Kissht and RingJun 2023 - Sep 2023
senior, risk and fraud analytics
35% fraud reduction geo-risk blocking
Led a team of analysts to build fraud policies and investigation workflows, reducing fraud losses by 35% within 3 months.
Strengthened KYC and onboarding processes and created anomaly monitoring dashboards; identified and blocked 3 high fraud-risk regions, reducing high-risk sign-ups by 30% and boosting credit underwriting compliance by 25%.
Enhanced name-match accuracy by ~5% through algorithm improvements; led inter and intra-user deduplication and blacklisting projects, reducing duplicate accounts by 10%.
onboarding hardeninggeo-risk blockinganomaly dashboards35% fraud loss reduction
FamPay
FamPayOct 2021 - May 2023
manager, risk and fraud
90% fraud reduction AML blacklist
Built the complete fraud framework: rule engine on ClickHouse and Metabase, investigation procedures for every fraud type, chargeback procedures, and anomaly monitoring dashboards across transaction, onboarding, and rewards layers.
Handled first party fraud where bad actors used the platform to defraud innocent users, and rewards loophole abuse where gaps in cashback and referral logic were exploited at scale.
Built the AML blacklist screening service on Whitebook to screen sanctioned individuals at onboarding - first structured AML layer the product had. Established FIU-IND and RBI regulatory reporting workflows.
Migrated all users to a risk-aware onboarding flow. Developed SOPs aligned with KYC and CDD/EDD, resulting in a 40% reduction in case resolution time. ~90% reduction in fraud losses. Rs 5M in rewards abuse prevented.
Launched three fraud-related products working with Engineering, Product, Legal, and Design - resulting in a 30% faster fraud review process.
full fraud frameworkrule engineKYC AML blacklistfirst party fraudregulatory compliance90% fraud reduction
Empower
Empower RetirementJan 2019 - Sep 2021
analyst, fraud and business intelligence
90% manual review reduction
Detected key fraud patterns through data analysis, building a proof-of-concept model that laid the groundwork for shifting fraud operations to an analytics-driven model.
Developed and implemented an automated fraud detection system using Selenium - 90% reduction in manual review time, 15% increase in identification of suspicious transactions.
Led projects to optimise workflows and automate reporting for 5+ departments saving ~100+ hours per week.
automation90% manual review reduction
Amazon
AmazonAug 2016 - Dec 2018
investigations specialist, sanctions compliance
sanctions investigations
Investigated suspicious accounts and trained a 120-member investigations team, enhancing procedures to improve investigation efficiency and consistency.
Built three SharePoint sites for risk assessments, compliance training modules, and reporting surveys, enhancing knowledge sharing across a 200+ member team and improving investigation rates.
sanctions investigationsteam training
the framework

6-layer
defence system

every layer targets a distinct fraud vector. click any layer to see what needs to be built and why.
01
onboarding defence
catch bad actors before they transact
02
anomaly detection
population-level pattern watching
03
transaction monitoring
individual user level, real time
04
rewards monitoring
cashbacks, coins, vouchers, referrals
05
user safety
screen protection, scam warnings, reporting
06
ecommerce fraud
orders, returns, RTO, address clustering
the playbook

how i
sequence the build

phase 1 / foundation
enrich data
instrument / unify / enable
instrument SDK - device ID, lat/long, IP into backend tables
route all signals to a unified source
internal blocklist - phone, device ID, GAID
NPCI MNRL screening at onboarding
geofencing on known fraud clusters
compliance calendar and audit baseline
phase 2 / detection
build detection
score / alert / monitor
rule engine live with first typologies from real patterns
risk scoring at onboarding - gate COD, restrict new user flows
alert triage - P1 auto-block, P2 and P3 review queues
anomaly dashboards live and queryable
transaction monitoring - UPI and RuPay velocity
AML blacklist screening wired into onboarding
phase 3 / scale
automate and scale
automate / calibrate / evolve
block management tool - bulk, section-level, unblock, audit logs
automate fraud model pipeline - no manual data feeds
rewards monitoring automated - cashback, coins, vouchers
ecommerce signals - bulk orders, address clustering
confirmed fraud cases feed back into model automatically
SOPs documented, thresholds calibrated
01
enrich data
instrument SDK - device ID, lat/long, IP into backend tables
route all signals to a unified source
internal blocklist - phone, device ID, GAID
NPCI MNRL screening at onboarding
geofencing on known fraud clusters
compliance calendar and audit baseline
02
build detection
rule engine live with first typologies from real patterns
risk scoring at onboarding - gate COD, restrict new user flows
alert triage - P1 auto-block, P2 and P3 review queues
anomaly dashboards live and queryable
transaction monitoring - UPI and RuPay velocity
AML blacklist screening wired into onboarding
03
automate and scale
block management tool - bulk, section-level, unblock, audit logs
automate fraud model pipeline - no manual data feeds
rewards monitoring automated - cashback, coins, vouchers
ecommerce signals - bulk orders, address clustering
confirmed fraud cases feed back into model automatically
SOPs documented, thresholds calibrated
end goal: model runs automatically / ops blocks without engineering / dashboards give comfort
models and ai

what i've done.
what i'd do next.

what i've done
fraud risk model built mid-incident
when fraud hit at POPTech, worked with the data team to map every confirmed fraud user's transaction pattern - amount type, merchant category, error codes, failure rates. built a risk score from that dataset. the model kept getting better as new inputs came in, with a plan to wire it into the rule engine as a live feedback loop. i defined what signals mattered, shaped what the model should look for, and validated whether the outputs made sense in a fraud context - built it with the data team.
risk signals from real data
identified and defined the right signals for detection - velocity, device fingerprinting, geo clustering, error code sequences. these fed both the rule engine and the risk scoring layer at POPTech and FamPay.
rule engine typologies from real patterns
seeded AI vendor typologies from confirmed fraud cases - not hypothetical ones. rules that come from actual data stay accurate longer and generate fewer false positives.
model validation and outcome tracking
tracked TPR, FPR, and analyst workload as indicators of whether a rule or model is doing its job. a rule that blocks everything has perfect recall and terrible precision. both matter.
fraud risk model built mid-incident
when fraud hit at POPTech, worked with the data team to map every confirmed fraud user's transaction pattern - amount type, merchant category, error codes, failure rates. built a risk score from that dataset. the model kept getting better as new inputs came in, with a plan to wire it into the rule engine as a live feedback loop. i defined what signals mattered, shaped what the model should look for, and validated whether the outputs made sense in a fraud context - built it with the data team.
risk signals from real data
identified and defined the right signals for detection - velocity, device fingerprinting, geo clustering, error code sequences. these fed both the rule engine and the risk scoring layer at POPTech and FamPay.
rule engine typologies from real patterns
seeded AI vendor typologies from confirmed fraud cases - not hypothetical ones. rules that come from actual data stay accurate longer and generate fewer false positives.
model validation and outcome tracking
tracked TPR, FPR, and analyst workload as indicators of whether a rule or model is doing its job. a rule that blocks everything has perfect recall and terrible precision. both matter.
what i'd build next
dynamic risk scoring
a model that re-scores users continuously as behaviour evolves, not just at onboarding. risk tier gates features and triggers step-up auth in real time. signals: transaction velocity, device consistency, geo behaviour, network graph - who referred them, who they transact with.
network and graph detection for linked accounts
users sharing devices, IPs, referral chains, or beneficiary VPAs are hard to catch with rules alone. graph ML can surface connections traditional models miss. something i've been researching and want to bring into practice.
anomaly explanation for analysts
most fraud systems flag and stop there. what analysts actually need is context: why was this flagged, what combination of signals triggered it, how does it compare to known patterns. building an explanation layer on top of detection - transaction location vs onboarding city, device change velocity, amount sequence match - cuts investigation time and improves decision quality.
auto-updating rule engine
confirmed fraud cases suggest rule modifications automatically. tighten what is generating false positives. loosen what is missing new patterns. closes the feedback loop without needing a human to review every threshold.
dynamic risk scoring
a model that re-scores users continuously as behaviour evolves, not just at onboarding. risk tier gates features and triggers step-up auth in real time. signals: transaction velocity, device consistency, geo behaviour, network graph - who referred them, who they transact with.
network and graph detection for linked accounts
users sharing devices, IPs, referral chains, or beneficiary VPAs are hard to catch with rules alone. graph ML can surface connections traditional models miss. something i've been researching and want to bring into practice.
anomaly explanation for analysts
most fraud systems flag and stop there. what analysts actually need is context: why was this flagged, what combination of signals triggered it, how does it compare to known patterns. building an explanation layer on top of detection - transaction location vs onboarding city, device change velocity, amount sequence match - cuts investigation time and improves decision quality.
auto-updating rule engine
confirmed fraud cases suggest rule modifications automatically. tighten what is generating false positives. loosen what is missing new patterns. closes the feedback loop without needing a human to review every threshold.
beyond fraud risk

fraud risk is my core - but i've ended up owning a few other things that i genuinely enjoy.

bizfin and cost
i managed the entire tech budget, which sat above growth and marketing at POPTech. most of the savings came from contract renegotiations - vendors, tools, infrastructure. ~1Cr in annual savings. i liked the negotiation part more than i expected to.
legal
NDAs, vendor contracts, dispute resolution, suits. i use AI tools and agents like Alingo for the routine work and bring in external counsel when it gets complex. doing this solo has been a steep learning curve and i am still on it.
bizfin and cost
i managed the entire tech budget, which sat above growth and marketing at POPTech. most of the savings came from contract renegotiations - vendors, tools, infrastructure. ~1Cr in annual savings. i liked the negotiation part more than i expected to.
legal
NDAs, vendor contracts, dispute resolution, suits. i use AI tools and agents like Alingo for the routine work and bring in external counsel when it gets complex. doing this solo has been a steep learning curve and i am still on it.
let's talk

fraud is a small world. if you're building in this space, thinking through a hard problem, curious about any of this, or just want to compare notes - reach out. no agenda needed.