Senior Python Trading Systems Engineer – SPX/XSP 0DTE, Schwab, Asyncio & OMS

TITLE Senior Python Trading-Systems Engineer — SPX/XSP 0DTE, Schwab, Asyncio and OMS OVERVIEW I am hiring a senior Python trading-systems engineer to review, complete and production-harden AURA-QUANT V13.3.3, an event-driven options-trading platform focused initially on SPX/XSP 0DTE execution. The long-term product universe includes: - SPX - XSP - SPY - QQQ - IWM The first engagement will be a paid Discovery & Verification milestone. The successful engineer may continue into the full milestone-based implementation. This is not an open-ended strategy-design role. The architecture, trading pipeline, safety requirements and implementation boundaries are already defined. The engineer must implement them accurately while identifying contradictions, unsafe assumptions or missing failure states. The current baseline includes: - A frozen technical architecture - A detailed implementation specification - Defined execution and risk invariants - A runnable reference scaffold - Automated reference tests - A staged roadmap from replay to shadow and supervised micro-live The repository is not being represented as an already completed production trading system. Discovery must determine what is reusable, partial, mocked, disconnected, missing or research-only before the full build is priced. CORE ARCHITECTURE The platform follows this pipeline: DATA → FILTERS → CONTEXT → SIGNAL → RISK → EXECUTION → FEEDBACK Primary technologies and integrations include: - Python 3.11 - asyncio - PostgreSQL - Real-time underlying and options data - REST and WebSocket market-data feeds - Massive/Polygon-style options integration - Charles Schwab brokerage integration - Deterministic point-in-time replay - AWS US-East deployment - Structured logging, monitoring, alerts and audit evidence INITIAL MILESTONE — DISCOVERY & VERIFICATION The first milestone is a separately scoped technical discovery, not the entire implementation. Expected outputs include: 1. Reproduce the repository build and test baseline 2. Produce an exact repository and module inventory 3. Classify components as: - implemented - partially implemented - mocked - disconnected - duplicated - conflicting - missing - reference-only - research-only 4. Produce a requirement-to-code-to-test traceability matrix 5. Review Python asyncio correctness, task supervision, queues, backpressure and shutdown behavior 6. Review: - Risk Kernel - OMS and EMS - order lifecycle - partial fills - cancel/replace - idempotency - broker reconciliation - restart recovery - protective exits 7. Validate Schwab capability and integration assumptions 8. Validate market-data capabilities, entitlements and historical-data requirements 9. Review point-in-time options replay feasibility 10. Identify release blockers, unsafe assumptions and missing states 11. Recommend the first focused SPX/XSP vertical slice 12. Provide revised implementation milestones, estimates, dependencies, exclusions and acceptance criteria No production brokerage credentials or unrestricted broker-write authority will be supplied during discovery. SAFETY-CRITICAL REQUIREMENTS Applicants must understand that this is not a basic signal bot. The system must preserve controls including: - Durable economic order intent before broker submission - Stable idempotency across retries, reconnects and restarts - No blind resubmission after a timeout or missing acknowledgment - Missing broker order IDs treated as UNKNOWN - UNKNOWN orders blocking conflicting activity until reconciliation - Partial fills and late fills treated as authoritative - Cancel/replace based only on conclusively remaining quantity - Prevention of duplicate opening exposure - Broker orders, executions and positions reconciled before entries resume - Separate entry and risk-reducing exit authority - Routine limit-order execution - Bounded marketable-limit protective exits - No unrestricted routine market orders - Maximum authorized planned loss may tighten but may not widen after entry - Stale or incomplete market data blocks new entries - Reconnect does not automatically restore trading authority - Raw events and audit evidence may not be silently discarded - Replay may not access future information PRODUCT-SPECIFIC REQUIREMENTS The platform may not treat SPX, XSP, SPY, QQQ and IWM as interchangeable. The architecture must support differences involving: - Cash versus physical settlement - European-style versus American-style exercise - Assignment and early-exercise risk - Contract multipliers - Option symbology - Tick sizes and pricing rules - Expiration behavior - Trading sessions - Liquidity and spread behavior - Broker permissions and restrictions The first production-focused vertical slice will target SPX/XSP. SPY, QQQ and IWM will be added through later evidence-gated milestones after the core runtime, replay, execution and reconciliation systems are proven. EXPECTED IMPLEMENTATION PATH AFTER DISCOVERY The anticipated sequence is: M1 — Deterministic runtime and core domain M2 — Historical ingestion and point-in-time replay M3 — Live market data, Schwab read access and broker reconciliation in shadow mode M4 — Controlled broker writes, OMS/EMS validation and failure testing M5 — Guarded one-contract supervised micro-live M6 — Expansion to SPY, QQQ and IWM with portfolio and correlated-risk controls The complete specification also includes advanced options analytics and research modules such as: - Greeks and selected higher-order Greeks - Implied volatility - Volatility surfaces, skew and term structure - GEX, DEX and zero-gamma context - Call and put walls - Market structure and liquidity analysis - Volume and auction context - Signal uncertainty and abstention - Strategy challengers - Feature ablation - Multiple-testing controls - Post-trade attribution - Capacity analysis These advanced modules are research-only until evidence supports promotion. They are not all required to block the initial SPX/XSP shadow deployment. IDEAL CANDIDATE Strong applicants should have personally implemented several of the following: - Production Python asyncio systems - Event-driven trading platforms - Live broker API integrations - OMS or EMS state machines - Partial-fill and cancel/replace handling - Lost acknowledgments and uncertain broker states - Durable order idempotency - Broker and position reconciliation - PostgreSQL event storage and restart recovery - Tick-level or quote-level replay - WebSocket ingestion - Reconnect, resubscription and gap recovery - U.S. listed-options systems - OPRA options data - SPX or XSP - SPY, QQQ or IWM options - 0DTE execution - Greeks, IV or GEX - AWS deployment - Monitoring and incident recovery Direct Schwab and Massive/Polygon options experience is preferred. Comparable broker or market-data experience may be considered if supported by verifiable evidence and a clear validation plan. Crypto-only trading experience is not sufficient by itself. OWNERSHIP AND SECURITY - All code, tests, documentation and infrastructure definitions must be delivered into repositories and accounts controlled by the project owner. - No subcontractors, personnel substitutions or undisclosed repository access without written approval. - No proprietary specification, code, interfaces, tests, logs, broker payloads, screenshots, errors, credentials or repository-derived context may be submitted to external AI systems without written approval. - NDA and IP ownership terms apply before confidential repository access. - No production credentials are required during bidding. TO APPLY Please answer the following directly. 1. Describe two broker-connected trading systems you personally implemented. 2. Identify the exact brokers, exchanges and market-data providers used. 3. Which components did you personally design and code? - market-data ingestion - OMS or EMS - partial fills - cancel/replace - idempotency - reconciliation - restart recovery - replay - monitoring 4. Explain how your system handled: - HTTP success without a broker order ID - crash after broker acceptance but before local persistence - partial fill while cancellation was pending - late fills - local and broker positions disagreeing after restart - stale data while a protective exit was required 5. Describe your direct production Python asyncio experience, including task supervision, bounded queues, backpressure, cancellation, exception propagation and graceful shutdown. 6. Describe your direct U.S. listed-options experience with SPX, XSP, SPY, QQQ, IWM, OPRA, 0DTE, Greeks, IV, settlement, assignment and expiration-day controls. 7. Provide a preliminary Discovery & Verification proposal containing: - fixed or capped structure - duration - exact deliverables - acceptance criteria - payment structure - assumptions and exclusions - preliminary focused SPX/XSP vertical-slice estimate Please provide redacted architecture diagrams, code samples, tests, logs, demonstrations, repository history or references where available. Applications that only say “I can build this” without answering the screening questions will not be considered.