Skip to content

PATTERN Cited by 1 source

Tenant features plus network data fraud model

Pattern

Train and deploy a per-tenant custom fraud model that combines:

  • Tenant-private features — data only this tenant has (product catalog, loyalty status, behavioural metrics, any structured metadata relevant to the tenant's risk profile).
  • Shared network features — fraud-signal density built up across the whole network's transaction corpus.

The model is per-tenant (the parameter set, the deployment, the prediction surface are isolated to one tenant), but its feature plane is hybrid (tenant features + network features). This is distinct from:

  • Pure shared models — one model for all tenants. Loses tenant-specific signal.
  • Pure per-tenant models trained from scratch — every tenant builds its own model from its own data. Loses network signal density.
  • Federated learning — models train on distributed data without raw-data sharing; here tenants explicitly send features to a central training pipeline.

Canonical wiki instance

systems/stripe-radar at 2026-05-27 (sources/2026-05-27-stripe-expanding-stripe-radar-to-protect-more-of-your-business):

"For businesses with more complex risk profiles, Radar now offers custom fraud models. You can pass signals unique to your business to Stripe, such as product catalog data, loyalty status, behavioral metrics, or any structured metadata relevant to your risk profile. Stripe then combines this information with our global network data to deploy a model customized specifically to your business."

Outcome: "For early adopters, custom models are detecting at least 15% more fraud with no increase in false positives."

Why hybrid features beat the alternatives

Pure shared models see global fraud patterns but miss tenant-specific nuance: a tenant's high-loyalty customer's sudden purchase pattern shift is meaningful only to that tenant.

Pure per-tenant models trained from scratch see tenant nuance but miss network-level signal density: most fraud actors are already known to the network from other tenants, so a from-scratch model relearns the population from a fraction of the data.

The hybrid pattern lets the per-tenant model be a thin specialisation over a shared signal substrate: most of the prediction power comes from network features, with tenant features adding the last few percent of accuracy on tenant-specific cases.

Required substrate

  • Multi-tenant feature ingestion — schema flexible enough to absorb arbitrary tenant features, with per-tenant isolation and access control.
  • Shared network-feature pipeline — global signal-density features computed once across the network, available as input to every tenant's model.
  • Per-tenant model deployment isolation — one tenant's model parameters can't leak via prediction outputs or feature-influence to another tenant.
  • Per-tenant retraining cadence — tenant features change at different rates; retraining must respect that without destabilising the shared network-feature plane.

Trade-off

  • vs pure shared model: more accurate for tenant-specific patterns, but higher operational cost (per-tenant model deployment, monitoring, retraining).
  • vs pure per-tenant model: better signal density, but requires the tenant to share features with the central network — a privacy / data-handling trade-off.
  • vs federated learning: simpler architecture (no cryptographic protocols), but raw features must be shared.

Caveats

  • Model class not disclosed in the canonical instance. Gradient-boosted trees? Deep nets? Embedding-similarity? Mixture?
  • Feature-schema versioning posture not described. When the tenant's feature set changes, how is it propagated?
  • Cross-tenant feature-influence isolation not characterised. How is one tenant's gradient prevented from leaking into another's model via the shared network features?
  • 15% improvement is over an unstated baseline (presumably shared-only models).

Seen in

Last updated · 542 distilled / 1,571 read