How do I set up a trade surveillance system for monitoring wash trades and managing case workflow?

Setting up a trade surveillance system for wash trade monitoring and case workflow management usually involves combining data ingestion, detection logic, alert tuning, case handling, and audit controls. Here’s a practical blueprint.

1) Define the surveillance scope

Start by documenting:

• Markets/instruments: equities, options, futures, FX, crypto, fixed income, etc.
• Venues: exchanges, ATS/MTF, OTC, internal crossing, dark pools
• Accounts/participants: proprietary, client, beneficial owner, related accounts
• Jurisdictions/regulations: e.g. SEC/FINRA, MiFID II, CFTC, local market rules
• Surveillance objectives:
  • Detect potential wash trades
  • Detect self-trades / same-beneficial-owner trades
  • Identify prearranged trading
  • Manage investigations and escalation

2) Build the data foundation

You need clean, timely, normalized data.

Required inputs

• Order events: new, amend, cancel, replace, reject
• Execution reports/trades: fills, partial fills, timestamps, venue, price, quantity
• Reference data:
  • Account hierarchy
  • Trader IDs
  • Client/beneficial owner mapping
  • Instrument master
  • Trading permissions
  • Venue/session calendars
• Optional but useful:
  • Market data
  • Position data
  • Communications metadata
  • KYC/ownership relationships
  • Algo identifiers / strategy tags

Data requirements

• Normalize timestamps to a single clock standard
• Preserve event sequencing and latency
• Support linkage across:
  • account ↔ trader ↔ desk ↔ legal entity ↔ beneficial owner
• Store immutable raw data plus a curated surveillance layer

3) Create wash trade detection logic

Wash trade detection should combine hard rules and behavioral analytics.

Core rule patterns

A potential wash trade often has:

• Same account buyer and seller
• Related accounts with common ownership/control
• Same trader/desk/strategy on both sides
• Opposite-side trades in the same instrument, near-same time
• Matching or similar price/quantity
• No meaningful net market exposure change
• Repeated patterns around end of day, benchmarks, auctions, or illiquid names

Detection approaches

A. Direct self-trade detection

Flag executions where:

• Buyer account = seller account
• Or same beneficial owner / controlled entity on both sides

B. Related-account wash trade detection

Flag when:

• Accounts share ownership, trader, desk, or strategy
• Trades occur within a short time window
• Same instrument and near-identical size/price
• Resulting position change is minimal

C. Pattern-based risk scoring

Assign a score based on:

• Time proximity
• Price proximity
• Quantity match
• Account relationship strength
• Frequency/repetition
• Illiquidity/market impact
• End-of-session concentration
• Cancel/replace behavior before execution

Example scoring fields

• same_beneficial_owner = true
• same_trader = true
• time_delta_seconds
• price_diff_bps
• qty_match_ratio
• net_position_change
• instrument_liquidity_score
• repeat_pattern_count

4) Tune for false positives

Wash trade rules can generate many false positives, so tuning matters.

Common false-positive sources

• Legitimate internal crossing
• Market maker activity
• Portfolio transitions / rebalancing
• Auction participation
• Cross trades approved under policy
• Error corrections
• Multi-leg strategies or spread trades

Tuning techniques

• Whitelist approved workflows and venues
• Add exemptions for authorized cross transactions
• Use desk/instrument-specific thresholds
• Require multiple conditions before alerting
• Separate “hard alerts” from “risk signals”
• Back-test against historical data and known cases

5) Design the alert engine

Your alert engine should be configurable and explainable.

Alert object should include

• Alert ID
• Rule/pattern triggered
• Entity/account/instrument details
• Trade sequence and timestamps
• Evidence summary
• Risk score and severity
• Related parties
• Supporting market context
• Status and owner

Alert prioritization

Use severity levels such as:

• Low: possible pattern, weak linkage
• Medium: multiple indicators
• High: direct self-trade or strong related-account pattern
• Critical: repeated, intentional-looking behavior with regulatory significance

6) Set up case workflow management

A surveillance system is only useful if investigators can manage cases efficiently.

Typical case lifecycle

1. Alert generated
2. Auto-triage / deduplication
3. Analyst review
4. Evidence gathering
5. Disposition
   • True positive
   • False positive
   • Needs more info
   • Escalated
6. Escalation / reporting
7. Closure and retention

Case management features

• Assignment queues by desk, region, or severity
• SLA timers and aging
• Notes and commentary
• Evidence attachments
• Linked alerts and related cases
• Status history / full audit trail
• Approval workflow for closure
• Escalation paths to compliance/legal/MLRO

Recommended statuses

• New
• Triage
• In Review
• Pending Information
• Escalated
• Closed — False Positive
• Closed — Confirmed Issue
• Closed — Reported

7) Build investigator tools

Investigators need context, not just alerts.

Useful UI views

• Trade timeline
• Order book / event sequence
• Entity relationship graph
• Position impact view
• Comparable trading activity
• Historical behavior by account/trader/instrument
• Market context overlay

Helpful functions

• One-click drill-down from alert to raw events
• Link analysis across related accounts
• Export to case notes / PDF / regulator package
• Search across historical alerts and cases

8) Governance, controls, and auditability

This is critical for regulatory defensibility.

Controls to implement

• Role-based access control
• Segregation of duties
• Immutable audit logs
• Evidence versioning
• Model/rule change approval
• Threshold change tracking
• Data retention policy
• Daily reconciliation between trade feed and surveillance feed

Audit readiness

You should be able to show:

• Why an alert fired
• What data was used
• Who reviewed it
• What decision was made
• When and by whom thresholds/rules changed

9) Operational monitoring and QA

Surveillance systems need continuous testing.

KPIs to track

• Alert volume by rule
• True positive rate
• False positive rate
• Average time to disposition
• Case aging
• Escalation rate
• Coverage gaps by venue/instrument
• Data latency and completeness

QA process

• Sample closed cases regularly
• Validate rule effectiveness
• Re-run rules after threshold changes
• Review missed-event scenarios
• Test with historical enforcement examples if available

10) Technology architecture

A common architecture looks like:

• Ingestion layer: FIX, market feeds, OMS/EMS, clearing, reference data
• Normalization layer: data standardization and entity resolution
• Surveillance engine: rule-based + analytics
• Alert store: searchable alert repository
• Case management system: workflow, notes, disposition
• Reporting layer: dashboards, MI, regulator reports
• Governance layer: access, audit, configuration control

11) Implementation roadmap

A sensible rollout plan:

Phase 1: Foundation

• Define scope and policies
• Build data ingestion and normalization
• Establish account/entity hierarchy
• Set up audit logging

Phase 2: Detection

• Implement core wash trade rules
• Add relationship matching
• Tune thresholds using historical data

Phase 3: Case management

• Deploy alert triage and case workflow
• Add investigator dashboards
• Build escalation and closure controls

Phase 4: Optimization

• Add analytics and scoring
• Reduce false positives
• Monitor KPIs and improve rules
• Expand to other market abuse typologies

12) Best practices specific to wash trades

• Don’t rely on exact same-account matching only; related-account logic is essential
• Use beneficial ownership and control mappings where available
• Include position-impact analysis to distinguish legitimate crossing from suspicious activity
• Consider venue and product-specific behavior
• Make rule logic explainable to compliance and regulators
• Keep a formal policy for exemptions and approvals

---

If you want, I can also provide:

1. a sample wash-trade detection ruleset,
2. a case workflow diagram, or
3. a data model/schema for implementing this system.