Pit: Pre-trade Integrity Toolkit

openpit is an embeddable pre-trade risk SDK for integrating policy-driven risk checks into trading systems.

For an overview and links to all resources, see the project website openpit.dev. For full project documentation, see the repository README. For conceptual and architectural pages, see the project wiki.

Versioning Policy (Pre‑1.0)

Until Pit reaches a stable 1.0 release, the project follows a relaxed interpretation of Semantic Versioning.

During this phase:

• PATCH releases are used for bug fixes and small internal corrections.
• MINOR releases may introduce new features and may also change the public interface.

This means that breaking API changes can appear in minor releases before 1.0. Consumers of the library should take this into account when declaring dependencies and consider using version constraints that tolerate API evolution during the pre‑stable phase.

Getting Started

Visit the crate page on crates.io and the API documentation on docs.rs.

Install

Run the following Cargo command in your project directory:

cargo add openpit

Engine

Overview

The engine evaluates an order through a deterministic pre-trade pipeline:

• start_pre_trade(order) runs lightweight start-stage policies
• PreTradeRequest::execute() runs main-stage policies
• PreTradeReservation::commit() applies reserved state
• dropping PreTradeReservation rolls state back automatically
• apply_execution_report(report) updates post-trade policy state

Start-stage policies stop on the first reject. Main-stage policies aggregate rejects and roll back registered mutations in reverse order when any reject is produced.

Built-in start-stage policies currently include:

• OrderValidationPolicy
• PnlBoundsKillSwitchPolicy
• RateLimitPolicy
• OrderSizeLimitPolicy

The primary integration model is to write project-specific policies against the public Rust policy API described in the wiki: Custom Rust policies.

There are two types of rejections: a full kill switch for the account and a rejection of only the current request. This is useful in algorithmic trading when automatic order submission must be halted until the situation is analyzed.

Threading

Canonical contract: Threading Contract.

1. The SDK never spawns OS threads. Every public method runs on the OS thread that invoked that method.
2. Concurrent invocation of any public method on the same SDK handle is the caller's responsibility to prevent. Entering one handle concurrently from multiple threads is undefined behavior.
3. Sequential calls to public methods on the same handle from different OS threads are supported. Handles, contexts, and callbacks are not pinned to a specific thread.
4. Go binding addendum: goroutine migration between OS threads during a single SDK call is supported. SDK callbacks into Go may run on a different OS thread than the goroutine that started the call; callback code must not rely on thread-local OS state.
5. Reject.user_data / Order.user_data / ExecutionReport.user_data / AccountAdjustment.user_data are opaque caller tokens. The SDK never inspects, dereferences, or frees them. Lifetime, thread-safety, and meaning are entirely caller-managed.

Usage

use std::time::Duration;

use openpit::{
    FinancialImpact, ExecutionReportOperation, OrderOperation,
    WithFinancialImpact, WithExecutionReportOperation,
};
use openpit::param::{
    AccountId, Asset, Fee, Pnl, Price, Quantity, Side, TradeAmount, Volume,
};
use openpit::pretrade::policies::{OrderSizeLimit, OrderSizeLimitPolicy};
use openpit::pretrade::policies::OrderValidationPolicy;
use openpit::pretrade::policies::{PnlBoundsBarrier, PnlBoundsKillSwitchPolicy};
use openpit::pretrade::policies::RateLimitPolicy;
use openpit::{Engine, Instrument};

# fn main() -> Result<(), Box<dyn std::error::Error>> {
let usd = Asset::new("USD")?;

// 1. Configure policies.
let pnl_policy = PnlBoundsKillSwitchPolicy::new(
    PnlBoundsBarrier {
        settlement_asset: usd.clone(),
        lower_bound: Some(Pnl::from_str("-1000")?),
        upper_bound: None,
        initial_pnl: Pnl::ZERO,
    },
    [],
)?;

let rate_limit_policy = RateLimitPolicy::new(100, Duration::from_secs(1));

let size_policy = OrderSizeLimitPolicy::new(
    OrderSizeLimit {
        settlement_asset: usd.clone(),
        max_quantity: Quantity::from_str("500")?,
        max_notional: Volume::from_str("100000")?,
    },
    [],
);

// 2. Build the engine (one time at the platform initialization).
let engine = Engine::builder()
    .check_pre_trade_start_policy(OrderValidationPolicy::new())
    .check_pre_trade_start_policy(pnl_policy)
    .check_pre_trade_start_policy(rate_limit_policy)
    .check_pre_trade_start_policy(size_policy)
    .build()?;

// 3. Check an order.
let order = OrderOperation {
    instrument: Instrument::new(
        Asset::new("AAPL")?,
        usd.clone(),
    ),
    account_id: AccountId::from_u64(99224416),
    side: Side::Buy,
    trade_amount: TradeAmount::Quantity(
        Quantity::from_f64(100.0)?,
    ),
    price: Some(Price::from_str("185")?),
};

let request = engine.start_pre_trade(order)?;

// 4. Quick, lightweight checks, such as fat-finger scope or enabled killswitch,
// were performed during pre-trade request creation. The system state has not
// yet changed, except in cases where each request, even rejected ones, must be
// considered (for example, to prevent frequent transfers). Before the
// heavy-duty checks, other work on the request can be performed simply by
// holding the request object.

// 5. Real pre-trade and risk control.
let reservation = request.execute()?;

// Optional shortcut for the same two-stage flow:
// let reservation = engine.execute_pre_trade(order)?;

// 6. If the request is successfully sent to the venue, it must be committed.
// The rollback must be called otherwise to revert all performed reservations.
reservation.commit();

// 5. The order goes to the venue and returns with an execution report.
let report = WithExecutionReportOperation {
    inner: WithFinancialImpact {
        inner: (),
        financial_impact: FinancialImpact {
            pnl: Pnl::from_str("-50")?,
            fee: Fee::from_str("3.4")?,
        },
    },
    operation: ExecutionReportOperation {
        instrument: Instrument::new(
            Asset::new("AAPL")?,
            usd,
        ),
        account_id: AccountId::from_u64(99224416),
        side: Side::Buy,
    },
};

let result = engine.apply_execution_report(&report);

// 6. After each execution report is applied, the system may report that it has
// been determined in advance that all subsequent requests will be rejected if
// the account status does not change.
assert!(!result.kill_switch_triggered);
# Ok(())
# }

Errors

Rejects from start_pre_trade(order) and PreTradeRequest::execute() are returned as Err(Reject) and Result<PreTradeReservation, Vec<Reject>>.

Each Reject contains:

• policy: policy name
• code: stable machine-readable code (for example RejectCode::OrderQtyExceedsLimit)
• reason: short human-readable reject type (for example "order quantity exceeded")
• details: concrete case details (for example "requested 11, max allowed: 10")
• scope: RejectScope::Order or RejectScope::Account
• user_data: opaque caller-defined pointer payload (null by default)

RejectCode values are standardized and stable across Rust, Python, and C FFI.