A SaaS product with a security incident apologizes and patches. A marketplace with a trust incident, fake listings, payment fraud, a wave of scammed users on either side, can lose the liquidity it took years to build, because trust is the product in a way it isn't for most software. That makes AI trust and safety one of the highest-stakes hires a marketplace makes, and one of the most commonly under-specified: teams hire a generic 'fraud analyst' role or bolt detection onto a data scientist's existing workload, instead of hiring for what the job actually is.
Why this hire is higher-stakes than it looks
Trust and safety can't lag growth in a marketplace: fraud and bad actors erode trust fast, and unlike churn from a mediocre feature, trust erosion is difficult to win back because the next user who gets scammed tells others before they tell you. That asymmetry is why the use case exists as a named priority on every mature marketplace's roadmap, and why hiring for it deserves the same rigor as hiring a lead ranking engineer, not the treatment of a support-adjacent function staffed as an afterthought.
What the job actually is, and isn't
The role is to detect bad actors and risky transactions before they damage trust, which is a materially different problem from after-the-fact fraud reporting. That means real-time or near-real-time scoring, feature engineering on behavioral and transactional signals, and a model that gets evaluated not just on accuracy but on how its errors distribute, because a fraud model that's simply 'accurate on average' can still be operationally useless if its false positives fall disproportionately on legitimate high-value users.
- Real-time or near-real-time transaction and behavior scoring, not batch reports reviewed after the fact.
- Feature engineering across account signals, transaction patterns, device/network signals and cross-side behavior.
- A defined false-positive cost model, blocking a real seller or buyer has a business cost, and the candidate should be able to quantify that trade-off, not wave at it.
- A feedback loop with human reviewers so the model improves from confirmed fraud and confirmed false alarms alike.
The trade-off every good candidate has an opinion on
Every fraud model sits somewhere on a spectrum between catching more fraud (more false positives, more legitimate users blocked or slowed down) and being more permissive (more fraud slips through, but legitimate users have a smoother experience). There's no universally correct point on that spectrum, it depends on your marketplace's margins, its user trust budget, and how expensive a false positive is relative to a false negative. A strong candidate will ask you these questions before proposing a threshold; a weak one will hand you a single accuracy number and call it done.
| Topic | What a strong answer sounds like |
|---|---|
| False positive cost | Names a specific business cost of blocking a legitimate user, and how they'd measure it |
| Model latency | Explains how they kept scoring fast enough not to slow the transaction/listing flow |
| Adversarial adaptation | Describes how bad actors changed behavior after being caught, and how the model kept up |
| Human-in-the-loop design | Has built a review queue or escalation path, not just a binary block/allow |
| Cross-side signal | Uses signals from both sides of the marketplace, not just the transacting party |
Why this hire sits next to the ranking team, not apart from it
Trust and safety and matching/ranking are more coupled than org charts usually reflect. A weak fraud model lets bad listings or bad actors into the pool that ranking models train on, degrading relevance quality in a way that looks, from the outside, like a ranking problem rather than a trust problem. Marketplaces that hire trust and safety in isolation, reporting into a different team with different priorities, tend to discover this coupling the expensive way, months after matching quality has already quietly degraded.
Interview questions that expose a weak trust and safety hire
- 1Describe a fraud or bad-actor detection model you built. What was your false-positive rate, and what did that cost the business?
- 2How did bad actors adapt once your model started catching them, and what did you do in response?
- 3How fast did your model need to score a transaction or listing, and what did you trade off to hit that speed?
- 4How did you get feedback from human reviewers back into the model, and how often did you retrain?
- 5Give an example of a signal from the 'other side' of a marketplace that improved fraud detection on the transacting side.