Fraud flag

Cambridge TCG has a scheduled detection sweep and event-specific checks for unusual trading and payment patterns. A matching rule records afraud_signal with low, medium, high or critical severity and puts it in an operator review queue. A signal is a risk indicator, not proof that a person committed fraud.

A signal is not consequence-free. Every unresolved signal at medium severity or above automatically subtracts 20 points the next time the person’s trust score is calculated. That lower score can change the displayed trust tier, per-trade and daily limits, trust-based commission rate, escrow or inspection route, and the payout hold applied to a future trade. A limit check can therefore reject a new order, offer, auction bid or swap without waiting for an operator to decide whether the signal is correct.

The stored auto_actionvalue is currently a classification label, not an action runner. Creating a fraud signal does not directly set the account’s flagged or suspended fields, and does not stop an already-earned payout. The automatic effect described above happens through the trust-score calculation and its downstream rules.

Where this lives in code. apps/storefront/src/lib/fraud/detection.ts (signal definitions), apps/storefront/src/lib/fraud/passes.ts and event handlers (detection), and apps/storefront/src/lib/escrow/trust-engine.ts plus apps/storefront/src/lib/escrow/service-tiers.ts (automatic score and trade effects).

What current detection looks at

• rapid_listing — at least 10 market orders in one hour.
• self_trading — a recent trade counterparty has used the same normalised shipping address.
• velocity_spike — seven-day volume of at least £500 that is also at least ten times the preceding seven-day baseline.
• failed_payment_burst — repeated Stripe payment failures over 24 hours, seven days or repeated attempts on one payment.
• new_account_high_value — an order of at least £200 on an account less than seven days old.
• bid_sniping — at least three final-two-minute bids across at least two auctions within an hour.
• auction_default andtrade_payment_default — a winning bidder or matched buyer lets the applicable payment deadline expire.
• chargeback — Stripe reports a bank dispute against a paid transaction.

How signals clear

A fraud signal does not clear itself merely because later activity normalises, and the daily sweep does not resolve old signals. It remains active until an operator resolves or dismisses it. Once resolved, the deduction is excluded from the score. Resolve, dismiss and escalation actions record the authenticated operator and written reason; the signal change and governance record commit together, then the affected trust score recalculation is awaited. If that recalculation fails after commit, the admin route reports that partial outcome instead of claiming full success. Escalating a signal can increase its severity. You can see current unresolved signals on /account/standing and contact support to add context, challenge inaccurate input data or request human review.

Production release boundary

The participant-facing request channel is currently email. There is not yet a durable decision-review case queue with assignment, status, a published service level and a governed way to correct every input and change every affected outcome. A support link alone is not operational human intervention.

Because these automatic effects can change access and transaction terms, production rejects new P2P commitments by default unless the deployment uses the exact reviewed mode P2P_COMMITMENT_MODE=reviewed-adult-human-review-v1. The route guard and each order, offer, auction, swap, lot and automatic-rule data-layer entry point both enforce the pause. Payment, shipping, receipt, cancellation, return, dispute, refund, payout, evidence and revocation for existing obligations remain available.

The one exception: a break-glass for emergencies

There is exactly one way an account can be frozen, and it is reserved for a genuine platform-integrity emergency — an active exploit draining the platform, a compromised account being used to attack others, a systemic fraud threatening everyone at once. The kind of event where a blockchain hard-forks to undo a hack. It is never used for ordinary disputes or bad manners. A freeze is a hold, not a verdict: it pauses an account to protect everyone else, and it can be lifted. It is human-only (no automation can trigger it), it demands a written justification, and every use — freeze and lift alike — is logged and available for review. The state change and governance record commit in one database transaction; if the record cannot be written, the state change rolls back and the operator sees failure. It hides affected public market surfaces and blocks new trades; current payout sweeps also skip a suspended account, so a pending payout can be delayed until the freeze is lifted. It does not delete or seize account data or funds, and it has no automatic expiry. In the normal run of things it should never fire at all.

Effect on trust score

The −20 deduction applies by severity, not by a prior finding that the signal was “genuine”. This is why prompt human review and a way to contest an inaccurate match matter. See /methodology/trust-score for the full score model and the other inputs that can offset or compound this effect.