Monitor ERC-3643 identity and freeze events and run real-time market surveillance on tokenized securities with Turbo and Compose.
Tokenized stocks are securities, and securities carry obligations that payment stablecoins do not: only eligible, identity-verified investors may hold them, transfers must respect restrictions, and the market they trade in must be surveilled for abuse. The ERC-3643 standard builds identity and compliance into the token itself, and every check it performs emits an onchain event.This guide covers both halves of securities compliance: transfer-level compliance (identity, eligibility, freezes) and market surveillance (wash trading, best execution). It is the securities counterpart to the payments-focused AML monitoring guide.
ERC-3643 tokens enforce rules through an identity registry and a compliance contract, and they can freeze holdings or force recovery. Stream those events to keep a real-time compliance picture.
When a new holder must be onboarded or a transfer needs an eligibility check, route it to a Compose task that verifies against your identity provider and records the outcome in a TEE. The pattern is identical to the AML screening task: fetch the verification, write an attestation on-chain, and keep the full trace. That attestation is what makes an eligibility decision defensible.
Tokenized equities trade 24/7 on open venues, which means the market-integrity checks a broker-dealer runs - wash trading, spoofing, best execution - now run against public onchain data in real time.
A wash trade is a sale with no change in beneficial ownership - the same owner on both sides, usually across two different addresses. The operative word is same: it is not enough for both parties to be known investors. You have to resolve each address to its beneficial owner and check that the two owners match.
A membership test like dynamic_table_check('watchlist', sender) AND dynamic_table_check('watchlist', recipient) is wrong here - it fires on any trade between two listed investors, not just self-trades, flooding surveillance with false positives. Dynamic tables answer “is this address known?”, not “do these two addresses share an owner?”
Resolve both counterparties to a beneficial-owner ID with an HTTP handler that calls your identity/KYC system, then flag trades where the two owners are equal.
wash-trade-surveillance.yaml
name: wash-trade-surveillanceresource_size: ssources: trades: type: dataset dataset_name: robinhood_testnet.erc20_transfers version: 1.0.0 start_at: latesttransforms: # Resolve each side to its beneficial owner via your identity service. # The endpoint echoes each row and adds sender_owner + recipient_owner. with_owners: type: handler from: trades url: https://identity.example.com/resolve-beneficial-owners primary_key: id secret_name: IDENTITY_API_SECRET schema_override: sender_owner: Utf8 recipient_owner: Utf8 # Self-trade: both addresses resolve to the SAME (non-null) owner suspected_wash: type: sql primary_key: id sql: | SELECT id, address AS token, sender, recipient, sender_owner AS beneficial_owner, amount, block_timestamp, transaction_hash, _gs_op FROM with_owners WHERE sender_owner IS NOT NULL AND sender_owner = recipient_ownersinks: surveillance_alerts: type: webhook from: suspected_wash url: https://surveillance.example.com/alerts/wash-trade one_row_per_request: true secret_name: SURVEILLANCE_WEBHOOK_AUTH
Your resolver’s ownership graph is the source of truth and is queried live, so linking new addresses to an owner takes effect on the next trade with no redeploy.
To cut volume, add a SQL pre-filter before the handler that drops trades where neither side is a known investor - a dynamic table membership check is fine for that. Just don’t mistake membership for detection; the same-owner comparison is what identifies a wash trade. If you maintain the address→owner map as a table, you can equivalently detect downstream with a Postgres self-join: join trades to the mapping on both sender and recipient and keep rows where the owner IDs match.
Compare each fill to the prevailing market price at the moment of the trade. Join your trade stream to the VWAP price feed from the tokenized-equities data layer and flag fills that executed materially outside the spread - the raw material for a best-execution report.
A surveillance alert becomes a case, and a case becomes a filing. A Compose task enriches each alert, opens a case in your surveillance system, and - where required - files a regulatory report, with every step traced and TEE-attested. Durable execution means a required report is never dropped because a downstream API blipped.
