Hedge venue exposure - trdrs Engine API

Venue hedging keeps two books separate:

Customers trade on the TRDRS-held venue book. Their fills, balances and P&L stay there.
The venue measures the net exposure of an account group.
A hedge policy creates a target in a separate provider account owned by the venue.
TRDRS sends and reconciles that hedge as its own order.

It does not forward a customer’s order to a liquidity provider or rewrite a customer fill after the fact. A hedge failure changes the hedge report, not the customer’s trading result.

Before you activate a policy

Connect and validate a provider under the venue.
Discover an account with both read and trade permission.
Bind it with mode: "hedge". A hedge account cannot be invited or shown to a trader.
Activate the instruments you will hedge, including their mapping to the provider connection.
Create the customer account group whose net exposure the policy will measure.
Issue a Venue key with hedge:read, hedge:manage and hedge:execute as needed.

Production activation also requires a qualified provider. Sandbox may use a provider that has passed the sandbox checks.

Publish and activate

curl -X POST "$TRDRS_API/api/partner/venues/$VENUE_ID/hedges/policies" \
  -H "Authorization: Bearer $TRDRS_VENUE_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: hedge-policy-standard-v1" \
  -d '{
    "groupId": "standard",
    "name": "Standard 100% hedge",
    "destinationAccountId": "00000000-0000-0000-0000-000000000001",
    "ratio": "1",
    "quantityCap": null,
    "notionalCap": null,
    "residualThreshold": "0.001"
  }'

Publishing changes nothing by itself. Activate the returned policy with compare-and-swap:

curl -X POST "$TRDRS_API/api/partner/venues/$VENUE_ID/hedges/activation" \
  -H "Authorization: Bearer $TRDRS_VENUE_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: activate-standard-v1" \
  -d '{"policyId":"POLICY_ID","state":"active","expectedRevision":null}'

Calculate, dispatch and reconcile

POST /api/partner/venues/{venueId}/hedges/calculate reads the durable customer book and stores one target. The target records customer exposure, desired hedge, confirmed provider position, already pending amount and rounding residual separately. Repeating a calculation against the same source checkpoint returns the same target and intent. Set dryRun: true on that request to preview the same calculation without saving a target, creating an order, writing an audit event or sending a webhook. Dispatch the returned intent through POST /api/partner/venues/{venueId}/hedges/intents/{intentId}/dispatch. A provider refusal removes the pending amount. A lost or uncertain reply stays unknown; it still counts as pending so a retry cannot double the hedge. Resolve it with the matching /reconcile call. Read the full state with:

curl "$TRDRS_API/api/partner/venues/$VENUE_ID/hedges" \
  -H "Authorization: Bearer $TRDRS_VENUE_KEY"

The report also returns aggregate execution count, adverse slippage in basis points, fees grouped by currency and a complete flag. Missing fee data, unresolved commands and open incidents make the report incomplete instead of silently reading as zero.

Webhooks

The venue’s existing signed webhook endpoints may subscribe to hedge.target, hedge.intent, hedge.fill, hedge.failure, hedge.drift and hedge.halt. They use the same signature and retry log as account and risk events. A hedge event always names a venue-owned hedge action; it never claims that a customer order was routed externally.

Emergency controls

Emergency stop pauses all policies, cancels additions that have not been dispatched and opens an incident. It deliberately does not flatten the provider account. Flattening is a separate explicit call:

curl -X POST "$TRDRS_API/api/partner/venues/$VENUE_ID/hedges/flatten" \
  -H "Authorization: Bearer $TRDRS_VENUE_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: flatten-incident-42" \
  -d '{"destinationAccountId":"DESTINATION_ACCOUNT_ID"}'

The reducing command remains available during a halt. It only targets an account bound to this venue with hedge purpose and never closes a customer account.

What can block a target

the policy is not active
provider state or its stream proof is stale
the active instrument has no mapping for the destination connection
the mark is older than the instrument’s configured maximum age
the customer book is incomplete
an incident is open
a previous command still has an unknown outcome

Treat these as incomplete operating state. Do not turn one into a zero exposure or a successful hedge in your own reporting.

​Before you activate a policy

​Publish and activate

​Calculate, dispatch and reconcile

​Webhooks

​Emergency controls

​What can block a target