Broker venues

Broker venues

Broker venues: overview

A broker is a venue whose session also routes orders. One plugin DLL, the same seam every data venue uses, and a trading port implemented directly over your own vendor client.

On this page

A broker is a venue

A broker is a venue plugin like any other — same IVenuePlugin export, same manifest, same session, same settings form — whose session publishes a Trading port alongside (or instead of) Data. One seam covers market data and order routing alike.

Everything in the Venue plugins chapter applies unchanged. This chapter is only about what is specific to routing orders: implementing the trading port directly, the venue-neutral components that carry the order-lifecycle invariants, and the contract kit every trading venue is gated by. 

graph LR
  PL["IVenuePlugin"] --> D["IVenueDescriptor
VenueManifest"]
  D -->|CreateSession| S["IVenueSession"]
  S -->|Data| DP["IDataProvider
(optional for a broker)"]
  S -->|Trading| TP["ITradingProvider"]
  S -->|AsPort| PO["Chains · Trade history · Cash activity"]

What a broker plugin contains

One DLL per broker, referencing only the SDK contract packages plus its vendor client. The vendor API mapping — the real venue knowledge — is retained verbatim from whatever you had; what changes is the interface layer around it.

Piece What it does
IVenuePlugin + IVenueDescriptor TypeId verbatim, credential schema 1:1 with the legacy profile shape, capabilities declared honestly.
IVenueSession The vendor login / stream bring-up, and the composition root for both ports.
ITradingProvider Your own implementation over your own vendor client — accounts, orders, positions, fills.
IDataProvider Present when the broker also serves market data (most do). Same shape as any data venue.
Session ports Option chains, trade-history backfill, cash activity — whichever the broker has.
Tests VenuePluginConformanceKit + TradingProviderContractKit + your own suite.

The ports a broker publishes

MyBrokerVenueSession.csinternal sealed class MyBrokerVenueSession(VenueSessionContext context)
    : IVenueSession, IVenueTradeHistorySource, IVenueCashActivitySource
{
    private MyBrokerDataProvider? _data;
    private MyBrokerTradingProvider? _trading;

    public IDataProvider?    Data    => _data;
    public ITradingProvider? Trading => _trading;

    // Option chains are a separately-owned object built in ConnectAsync, so it is
    // exposed only while connected. Trade history + cash activity are implemented
    // on the session itself and resolve through the default GetPort probe.
    public T? GetPort<T>() where T : class
        => (this as T) ?? (Volatile.Read(ref _chains) as T);
}

Declare the matching manifest flags so the host's registrars know to look: Trading, TradeHistoryBackfill, CashActivity, OptionChains.

Shared components

The order-lifecycle invariants that are genuinely venue-neutral live as small, single-purpose components in SabrTrader.Pipeline.Venues.Trading, and any venue — broker, crypto exchange, futures gateway — composes the ones it needs. Each takes primitives and delegates rather than vendor types, and each carries the incident it exists for in its own tests, so the expensive lesson is learned once and inherited by every venue after.

They are covered on The trading port. The short version: cancel-replace revision tracking, ambiguous-placement resolution, the missed-fill probe, position-snapshot retirement, the order-update fold, and quantity/price snapping.

Two merge gates

A trading venue is gated twice. VenuePluginConformanceKit checks the seam shape — loader compatibility, manifest validity, verbatim TypeIds, contracts-only references, offline lifecycle safety. TradingProviderContractKit checks the behaviour of your trading port against the incident-derived contracts: cancel semantics, the OCO leg-gateway dual contract, realized-PnL nullability, commission honesty.

Both are abstract xunit base classes you subclass in your venue's test project. Details on Contract kit & capabilities.

Keeping saved profiles working

Two things brick a customer's setup, and both are silent. The TypeId is the key every saved profile of that broker is stored under, and the settings schema decides the exact JSON those profiles are written as. Keep the id stable, point every field's StorageName at the property the profile already uses (dotted paths such as PlainValues.Environment and GatewaySecretsBase64.refresh_token nest into the existing objects), and pin the result byte-identical against a captured REAL profile before shipping.

A tour of the chapter

Page Covers
The trading port Implementing ITradingProvider directly, the four operations, OCO and multi-leg, the event stream, and the venue-neutral components.
Contract kit & capabilities Declaring capabilities across both layers, session ports, credential rotation, and the two merge gates.
Trading providers The full trading contract surface: orders, positions, accounts, events, risk, commissions.
← BackTrading hours & sessions