# Venue controls and evidence Source: https://docs.settlemint.com/docs/concepts/issuing-and-markets/venue-controls How a Trading Venue checks admission, which roles change a running instrument and who must agree, and the FIX drop copy and surveillance files it produces. A [Trading Venue](https://docs.settlemint.com/docs/concepts/issuing-and-markets/trading-venue) is a tenant's own exchange for tokenised assets. It checks a participant's admission on every new order and ties each change to a running instrument to a venue role. When the deployment enables its FIX drop copy, it also sends a surveillance provider each order and trade event as the venue records it. The Trading Venue page explains how an order becomes a delivered trade. Admission is checked when an order arrives. Revoking a participant's admission does not cancel the orders they already have resting. Cancel those from the **Orders** screen. At intake the maker must be a participant the venue admits and, on a private instrument, a participant of that instrument. Removing a wallet from a private instrument cancels its open orders on that instrument and leaves one cancellation batch. An [instrument denial](https://docs.settlemint.com/docs/concepts/issuing-and-markets/venue-market-denials) is narrower than losing admission: it bars one wallet from one instrument, records the reason and who recorded it, and leaves the venue's other instruments open to that wallet. Evidence is identity-linked, sequenced, and venue-scoped: the trail carries signed orders, book events, session transitions, fills, deliveries, and undos with their reason, each naming the venue it belongs to. The platform rebuilds a book's state by replaying that trail, and it rebuilds the drop-copy reports and the daily surveillance files from the same trail. The trail is the platform's own record. Order commits, fills, deliveries and undos are also on chain, and the [retention policy](https://docs.settlemint.com/docs/concepts/issuing-and-markets/venue-retention) moves expired records to the venue archive. Every order also has a trading member: the broker a venue operator assigned to the participant that owns the wallet, or the participant itself when it has no broker. The platform works the member out as of the moment of the order, so assigning or clearing a broker changes the member of later orders only. An earlier order keeps the member it had. Only venue operators receive the member (`PATCH /api/v2/addons/trading-venues/{venueAddress}/participants/{walletAddress}/access` assigns it). A trader or a broker never sees a member, another participant's name or the counterparty's order on the platform. The venue contract's trade events name both wallets on chain, so a reader of the chain can still link a trade to the buyer's and the seller's wallets. ## Who can change a running venue, and who must agree [#who-can-change-a-running-venue-and-who-must-agree] An operator changes a running instrument through a fixed set of controls, each tied to a venue role. Whether a control waits for a second person follows one organisation setting, the **Trading venues** row under "Approvals" on the "General" page of "Organisation settings", and an exception there can turn it on or off for one venue. With the row on, a different holder of the required role must approve, and the platform refuses a decision from the person who proposed. With the row off, the change applies at once and "Actions" logs it as "No second approval (approval off)". | Control | What it changes | Role | With the Trading venues row on | | --- | --- | --- | --- | | Desk limit | Caps the open order value one trader wallet may carry on one instrument. Intake refuses an order that would pass the latest approved limit | Venue operator | A second operator approves. An undecided proposal lapses after a configurable window, 24 hours by default | | Trade bust | Undoes a trade within 24 hours of it, before or after delivery | Venue operator | A second operator approves. An undecided proposal lapses like a desk limit | | Order cancel and mass cancel | Cancels one open order, or every open order that matches a filter. A mass cancel leaves one cancellation batch per instrument | Venue operator | A second operator approves | | Venue configuration | The venue calendar and its closed days, the venue price band, admission, listing rules (including order-rule limits and starting values), the [VAT](https://docs.settlemint.com/docs/concepts/issuing-and-markets/venue-vat) and [retention](https://docs.settlemint.com/docs/concepts/issuing-and-markets/venue-retention) policies, and resuming the venue | Venue admin | A second venue admin approves within 24 hours. A pending change blocks a second proposal for the same setting, and an approval whose recorded before-state no longer matches the live configuration is refused | | Venue approval requirement | Switches the venue's second-person requirement off, or lets an emergency halt skip it | Venue admin | A second venue admin approves, even when the venue has no other admin yet: add one first. Switching the requirement on, or tightening the emergency halt, applies at once. With the row off there is nothing to approve, so the change applies at once | | Instrument configuration | Instrument listings, instrument calendars, collection windows, price bands, instrument fields and limits such as the holding period, fees, fee tiers, instrument transitions, scheduled and dated changes, participant removal, and pausing the venue | A platform administrator or the organisation owner, signing with a venue operator wallet | A venue operator other than the proposer approves, on the same terms as venue configuration | | Emergency halt | Halts one instrument at once, through the Platform API | Venue operator | Runs at once when a venue admin allowed emergency halts for the venue and the halt request asks for one. It records the halt as executed, with no checker, and a resume is its own request. Resume and delist never take this path | | Instrument groups | Defines the groups, such as equities or fixed income, that the venue sorts its instruments into | Venue admin | Applies at once | The second approval binds the Console and the Platform API. A holder of the venue operator role can also cancel any order directly on the venue contract, or flag and clear a pending trade there, with no second approval, and that cancel does not name its caller on chain. A venue administrator grants and revokes the venue operator and venue submitter roles through the Platform API. The same venue keeps read-only records an auditor can check against these controls. The Orders screen lists every order submitted to the venue. Each operator action that cancels orders in bulk leaves a cancellation batch with the operator, the reason and the orders it closed. The settlement instructions show which token moved from whom to whom for each trade. **Held settlement fills** lists the fills settlement could not complete, each with its reason. The venue read, `GET /api/v2/addons/trading-venues/{venueAddress}`, adds a summary: the orders resting now and the instruments they rest in, the trades of the last 24 hours and of the 24 hours before, the settlement batches that fully delivered in each of those windows, and the batches still awaiting delivery. An undone trade counts in none of them. [Venue operations](https://docs.settlemint.com/docs/console/asset-lifecycle/venues), [Orders](https://docs.settlemint.com/docs/console/asset-lifecycle/venues/orders), [Mass cancellations](https://docs.settlemint.com/docs/console/asset-lifecycle/venues/mass-cancellations), [Instrument](https://docs.settlemint.com/docs/console/asset-lifecycle/venues/instrument) and [Trading calendar](https://docs.settlemint.com/docs/console/asset-lifecycle/venues/trading-calendar) cover each control and record in the Console. ## How the drop copy session runs [#how-the-drop-copy-session-runs] The drop copy is one Financial Information eXchange (FIX) session from one venue to one surveillance provider, and the provider sees each order and trade event as the venue records it. It runs FIX 5.0 SP2 over the FIXT.1.1 session layer. The session belongs to the deployment's configuration, not to a Console setting. It stays off until it is enabled with the venue's network and address, the port, the SenderCompID and TargetCompID, the time reporting starts from and the venue's market identifier code. A session that dials out also needs the provider's host name. The Console has no drop copy screen. An operator reaches the session's output through the venue reports API: the replay preview and request, and the daily file list and download. The session either dials the provider or waits for the provider to dial in. Dialling out is the default and uses TLS unless the configuration turns it off. Waiting for the provider needs three settings, and the configuration is refused without any of them: the provider's host on the session's allow list, plain TCP over a private link, and no sequence reset at logon. For an incoming session, the deployment must also make the listening port reachable from the provider, and it does not do that by default. One process holds the session at a time. When the provider's sequence numbers skip, the session asks for a resend. A SequenceReset whose NewSeqNo is missing or lower than the number the session expects ends the session. The expected number never moves backwards. An incoming message body longer than 65,536 bytes is refused. Once each UTC day the session also sends start-of-day position reports, built from indexed balances at midnight UTC. While the balances, accounts or instrument mappings for the day are incomplete, the session sends no positions and tries again through that UTC day. It never reports a missing balance as zero. An undone trade reaches the provider as a Trade Cancel ExecutionReport (`150=H`) on each leg. Its Text (58) carries the undo reason, such as `bust` for an approved bust or `refused` for a delivery an outside cause blocked. The leg of the side that failed delivery adds `;failed-side`, and a report timed by the trade's execution time, because no undo time was recorded, adds `;undo-time-unrecorded`. ## What each drop copy report carries [#what-each-drop-copy-report-carries] The drop copy sends one FIX ExecutionReport for each order and trade event, and one for each new, validly signed order that intake refused. It also sends instrument events in the same sequence: SecurityStatus (`35=f`) carries halts, resumes, suspensions, band changes, configuration changes and official close, while TradingSessionStatus (`35=h`) carries session transitions. These messages carry the symbol and the status or session fields a surveillance system uses to attribute and time the event, and they support the same resend path as order reports. The field table below describes order and trade ExecutionReports (`35=8`). Instrument messages (`35=f` and `35=h`) use the status, session and configuration fields described above. Instrument status reports use `326=2` for halted, `326=3` for resumed and `326=4` for suspended or delisted. Band reports use `326=6` with `332` and `333` when bounded, while session reports use `340=4/2/5/3` for pre-open, open, closing auction and closed. An auction collection reports as open (`340=2`), and a Trade-At-Last session reports as open (`340=2`) with `625=5` for post-trading on that report only. A volatility interruption reaches the provider as a sequenced SecurityStatus message (`35=f`). When it starts, the report carries `326=2`, the trigger price in LastPx (31) and a Text (58) of `volatility-interruption:started:resumes-at=