Trading system engineer

Ainnocence; Hong Kong; On-site; HKD 900,000 - 1,500,000; Full time

Job summary

Ainnocence is seeking a Trading System Engineer to own the production trading system for a global multi-asset Quant fund. You will work with an in-house Python stack to turn signals into filled orders via Interactive Brokers, running 24/5 across Asia, Europe and the US.

The role combines keeping the system running with real improvements: designing execution logic, reducing costs, and extending the architecture for new strategies and asset classes.

Qualifications

• 4+ years of production Python in a trading or low-latency setting.
• Hands-on Interactive Brokers API experience in live trading.
• Ownership of an execution or latency-sensitive system.
• Profiling and performance work in Python; know asyncio and related tools.
• Knowledge of market microstructure and fill quality reasoning.
• Linux, Git, CI/CD; time-series data stores; messaging systems.

Responsibilities

• Build and optimize execution algorithms with order placement logic.
• Reduce transaction costs via a TCA feedback loop and measurable slippage.
• Profile hot paths; address latency, serialization, and bottlenecks.
• Refactor and extend codebase for new assets and strategies.
• Move strategies from backtest to live with behavioural parity.
• Harden IB layer: session management, reconnection, idempotent orders.
• Own order lifecycle: routing, state machine, end-of-day handling.
• Perform pre-trade risk checks and post-trade reconciliation.
• Establish observability: monitoring, runbooks, on-call coverage.

Skills

Python

Low-latency

IB API

Performance profiling

Linux

Git CI/CD

Tools

PostgreSQL

Redis

Kafka

ZeroMQ

Job description

ROLE SPECIFICATION

Trading System Engineer — Quantitative Fund

Hong Kong·Global Multi-Asset Quantitative Fund·~US$50M AUM

1. Role Summary

We are hiring a Trading System Engineer to own the production trading system of a global multi-asset quantitative fund — the in‑house Python stack that turns strategy signals into filled orders through Interactive Brokers, running 24/5 across Asian, European and US sessions.

This is not a maintenance seat. The successful candidate will both keep the system running and make it measurably better: designing execution logic, reducing transaction costs, and extending the architecture as new strategies and asset classes come online. Accountability is for execution quality and uptime, not for alpha generation.

2. Key Responsibilities

2.1 Build and Optimize

• Execution algorithms.Design and implement passive/aggressive placement logic, order slicing, participation control, spread capture and smart limit placement in place of naive market orders.
• Transaction cost reduction.Build the TCA feedback loop and then close it — every optimization justified against measured slippage per strategy and per asset class.
• Performance engineering.Profile and optimize the hot path: event-loop latency, API round‑trip and pacing constraints, serialization, data structures. Judge when Python is the true bottleneck and select the appropriate remedy.
• Architecture and extension.Refactor and extend the codebase as new asset classes and strategies are added — interfaces, modularity, and test coverage.
• Research‑to‑production path.Move strategies from backtest to paper to live with behavioural parity, working alongside the research team.

2.2 Run and Operate

• Broker connectivity.Harden the Interactive Brokers layer (TWS/Gateway API): session management, daily restart windows, reconnection and recovery, idempotent order submission.
• Order lifecycle.Own routing and the order‑state machine — partial fills, rejects, cancel/replace, and end‑of‑day handling across time zones.
• Pre‑trade risk in code.Position and notional limits, fat‑finger checks, per‑strategy caps, and a tested kill switch.
• Post‑trade control.Daily reconciliation against IB Flex reports and statements; PnL attribution; margin and multi‑currency exposure monitoring.
• Observability.Monitoring, alerting, runbooks and on‑call coverage; deployment and infrastructure ownership.

3. Requirements

• 4+ years of production Python in a trading or comparable low‑latency environment — asyncio, typing, and genuine test discipline.
• Hands‑on Interactive Brokers API experience in live trading (native API or ib_async / ib_insync).
• Demonstrable ownership of an execution or latency‑sensitive system they designed, not merely maintained.
• Profiling and performance work in Python (cProfile, py‑spy, asyncio internals; C extensions, Cython or numba where warranted).
• Working knowledge of order types and market microstructure; ability to reason quantitatively about fill quality and transaction cost.
• Linux, Git, CI/CD; PostgreSQL or a time‑series store; a message bus (Redis, ZeroMQ or Kafka).
• Correct handling of exchange calendars, sessions, and instrument/contract data across multiple markets and currencies.

4. Preferred

• FIX protocol experience.
• Integration of a second broker or prime relationship.
• Futures, options or FX plumbing beyond cash equities.
• C++ or Rust in the hot path.
• Exposure to Hong Kong regulatory and operational requirements.

5. Screening Guide

The following questions separate candidates who have genuinely owned a live execution system from those who have only used one.

5.1 Operational judgement

1.The IB gateway drops mid‑session with a working order outstanding. Walk through recovery — how do you establish the true position without double‑submitting?

2.A strategy signal flips while an order is 40% filled. What does the system do, and where does that logic live?

3.How do you reconcile the internal position book against the broker each day, and what happens when they disagree?

5.2 Build and optimization

4.Describe an execution system you designed. What was the architecture, and what would you do differently now?

5.Your VWAP‑style slicer underperforms arrival price by 8bps on Hong Kong equities but performs well on US futures. How do you diagnose it?

6.IB pacing limits are throttling you at the open. Walk through the options — and which you would choose at this AUM.

7.Where would you decline to optimize? (Strong candidates push back on latency work that does not pay at our strategy horizon.)