Section C · DE inside a neocloud

Trust & Fraud Data

The pipelines that protect the marketplace from bad actors and protect customers from bad supply. Hardware verification, identity signals, abuse detection inputs, and the enforcement workflow that ties them together.

Why trust data matters

For marketplaces and self-serve dedicated clouds alike, trust is foundational:

Without it, buyers don't trust supply (marketplace failure).
Without it, payment fraud erodes margin.
Without it, the platform attracts bad actors (illegal compute, abuse).
Without it, regulatory compliance breaks.

Trust data is the substrate for the safety systems that protect against all of the above. The DE team that builds these pipelines makes the customer-facing platform credible.

Hardware verification signals

For marketplaces specifically, verifying that listed hardware is what providers claim is critical. Signals:

GPU model reported by NVML matches listing.
Benchmark performance within expected range for the claimed SKU.
PCIe topology consistent with claimed configuration.
Memory size and type as expected.
Firmware version checks.

The DE team captures these signals at listing time and continuously. Anomalies feed enforcement workflows.

Identity and KYC signals

The platform's customer and provider identity layer generates data critical for fraud detection:

Account creation events.
Email / phone verification status.
Payment method validation (card BIN, billing address).
KYC documentation submitted (for higher tiers).
IP geolocation and history.
Device fingerprinting.

These signals stream into a customer-identity fact table used by fraud models and compliance reporting.

Abuse and misuse data

Behavioral signals for abuse detection:

Unusual usage patterns (sudden traffic spikes, geographic anomalies).
Payment fraud indicators (chargebacks, suspicious billing addresses).
Outbound network traffic patterns (potential abuse: spam, attacks, illegal content distribution).
Compute fingerprints (specific code patterns associated with abuse).
Account farming signals (many accounts sharing infrastructure).

The DE team works with security / trust-and-safety teams to define which signals to capture and how. Privacy and legal considerations shape what can be collected.

Provider quality data

From the buyer's perspective, provider quality is itself a trust dimension. The signals overlap with marketplace event streams (chapter 9):

Long-term reliability (uptime over weeks / months).
Dispute history.
Customer ratings.
Performance consistency (DLPerf or equivalent).
Compliance attestations (where applicable).

Aggregated into a provider-quality score that surfaces in search ranking.

Enforcement workflow

When abuse or fraud is detected, the DE pipeline supports the enforcement workflow:

Case management — each detected issue becomes a case with evidence linked.
Action tracking — was the account suspended, refunded, escalated to legal?
Appeals and reinstatement — supports manual review.
Outcomes feed back into the fraud models (see DS guide).

The DE team builds the case-management fact tables; trust-and-safety operators use them; DS teams train on the labeled outcomes.

✓ Check yourself

Answer from memory before opening each one.

A listing claims 8 H100s and NVML reports the right model, but benchmarks come in at 60 percent of the expected figure. What does it suggest, and what do you do?

Show answer
The reported model alone is not proof. Throttling, shared or virtualized hardware, or misreported configuration could explain it. Flag the listing, re-benchmark, compare topology and firmware, and open a case. See hardware verification signals.
Why capture hardware verification signals continuously rather than once at listing time?

Show answer
A provider can pass at listing and then swap or degrade hardware. Continuous capture catches drift and makes anomalies feed enforcement while the listing is live. See hardware verification signals.
Forty accounts opened in a week share a device fingerprint and a payment BIN. Which data do you join to confirm farming?

Show answer
The customer-identity fact table with device, IP history, payment validation and verification status, joined to usage and chargeback data. Shared infrastructure across many accounts is the signal. See identity and KYC signals and abuse and misuse data.
Trust and safety asks you to store outbound traffic from rented hosts to detect abuse. What do you ask before building it?

Show answer
What legal and privacy limits apply, whether metadata or patterns suffice instead of content, and how long it is kept. Privacy and legal considerations decide what can be collected. See abuse and misuse data.
Why store enforcement outcomes as case data, and who uses it?

Show answer
Operators work cases with linked evidence, appeals and reinstatement need history, and data science trains on the labeled outcomes. Without recorded outcomes, models lose their labels. See enforcement workflow.

Takeaway

Trust data keeps buyers confident in supply, limits payment fraud and keeps bad actors and regulators away.
Hardware verification checks the claimed model, benchmark range, topology, memory and firmware, at listing time and continuously.
Identity, payment and device signals land in one customer-identity fact table.
Abuse signals depend on privacy and legal limits, so collection scope is agreed with trust-and-safety and legal.
Enforcement cases carry evidence and outcomes, and outcomes become labels for fraud models.

The last chapter sets both perspectives side by side. → Synthesis & Outlook