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






fraud risk is my core - but i've ended up owning a few other things that i genuinely enjoy.
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.