IBKR execution client cannot submit provider-resolved stock instruments because ExecutionEngine requires instrument venue == client venue

[silarin]

First time submitting an issue for discussion.

I've checked the discord but seems there was only a short mention of this five years ago.

For context, I'm using Rust to write a simple trading strategy and connecting via IBKR.

I'm currently stuck with some gaps and this came up as an upstream fix as recommended by Codex.

Let me know how else I can help. Thank you.

Edit: this is for 0.58.0

Summary

nautilus-interactive-brokers can resolve executable stock instruments as venues such as NASDAQ, XNAS, or SMART, while the IBKR execution client is registered with fixed venue IB. The current ExecutionEngine submit path denies these orders before the adapter sees them because it requires:

• order.instrument_id().venue == client.venue()

This blocks valid IBKR live orders even though the IBKR adapter can resolve the instrument to a contract and submit it.

Observed failure

Downstream live runtime logs show denials like:

OrderDenied(... reason='Order venue NASDAQ does not match client venue IB')

and then reconciliation fallout such as:

Error querying order: No venue order id for client_order_id

The second error is only a consequence of the first: the order never reached IBKR, so no venue order id exists.

Current upstream structure

On downstream pinned revision 568e53d43625d8d40073d20121043078fe2f2f8e:

• crates/execution/src/engine/mod.rs denies submit when order.instrument_id().venue != client.venue()
• crates/adapters/interactive_brokers/src/factories.rs constructs the IBKR execution client with fixed venue IB
• crates/adapters/interactive_brokers/src/providers/instruments.rs can resolve instruments such as AAPL.NASDAQ to valid IBKR contracts

So the current routing assumption is too strict for IBKR multi-venue instrument identity.

Why this is a framework gap

For IBKR, instrument venue and execution-client venue are not the same concept:

• instrument venue identifies the resolved market/instrument identity (NASDAQ, XNAS, SMART, etc.)
• execution-client venue identifies the adapter/client domain (IB)

The current engine assumes they must be identical, which is not true for this adapter.

Recommended fix

Introduce an execution-client capability check instead of hard-coding strict venue equality in the engine.

Suggested patch shape

1. Add a default method to ExecutionClient, for example:

fn accepts_instrument_id(&self, instrument_id: &InstrumentId) -> bool {
    instrument_id.venue == self.venue()
}

2. Change the ExecutionEngine submit path to call that method instead of directly comparing venues.

3. Override it in InteractiveBrokersExecutionClient so it returns true when the IBKR instrument provider can resolve the given InstrumentId to a contract, for example via:

self.instrument_provider
    .resolve_contract_for_instrument(*instrument_id)
    .is_ok()

Why this approach

• preserves current behavior for all other adapters via the default implementation
• keeps instrument venue separate from execution-client venue
• avoids forcing downstream projects to rewrite instrument ids to IB
• avoids adapter-specific special cases inside the generic execution engine
• matches the real IBKR model, where one execution client can validly handle instruments resolved under multiple venues

What should not be required downstream

Downstream apps should not have to:

• rewrite AAPL.NASDAQ / AAPL.XNAS / AAPL.SMART to AAPL.IB
• collapse instrument venue into execution-client venue
• add local routing shims or adapter wrappers
• bypass nautilus-interactive-brokers with direct ibapi execution

Expected outcome

With the capability-hook approach, valid IBKR stock orders should no longer be denied purely because the resolved instrument venue differs from the fixed client venue IB, while other adapters keep the existing strict venue behavior by default.