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






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.