Position Manager

Your broker's platform shows positions but may not provide: multi-strategy tracking, detailed cost-basis information for the Section 104 pool and CGT, custom alerts and limits, integration with your trading strategies, or a consolidated view across multiple brokers. A dedicated position manager adds these capabilities. For basic trading, broker platforms suffice. For systematic trading or multi-account portfolios, dedicated position management adds significant value.

Your average cost doesn't change when you sell - it only changes when you buy more at a different price. When you sell 50 out of 100 shares, your remaining 50 shares still have the same average cost. For UK CGT, the cost of the shares sold is taken from your Section 104 pool (the weighted-average cost), after first applying the same-day and 30-day matching rules - not FIFO.

Key differences: (1) Futures use mark-to-market daily - gains/losses are settled to your account each day, not just when you close. (2) Margin requirements fluctuate with position value. (3) Positions have expiry dates. (4) Tax treatment differs: spread bets are tax-free, while CFDs and futures/options fall under CGT (not income). (5) Contract sizes are fixed. Your position manager should track these differences and display appropriate information for each position type.

Common reasons: (1) The broker may include commission/stamp duty in average cost, you may not. (2) Different handling of partial fills. (3) Corporate actions may have been applied differently. (4) Your display may use a simple average while the figure that matters for tax is the Section 104 pool. Always reconcile and understand the methodology difference. For tax purposes, maintain your own accurate pool records.

Investigate immediately: (1) Check for pending settlement (T+2 means a buy today settles two business days later; the UK moves to T+1 on 11 October 2027). (2) Look for recent corporate actions that might have adjusted quantities. (3) Check for any trades that failed to sync. (4) Review whether there were partial fills that weren't fully captured. The broker record is authoritative - update your position manager to match, then fix the underlying sync issue to prevent recurrence.

Options: (1) Use each broker's platform separately and maintain a master spreadsheet. (2) Use portfolio tracking tools (Sharesight, or broker portfolio tools from Hargreaves Lansdown, AJ Bell, or interactive investor) that aggregate across accounts. (3) Build a custom position manager that connects to each broker's API. (4) For a consolidated view: import holdings from each broker (CSV or API), aggregate in your system, reconcile each account separately. The key is having one source of truth for total exposure while maintaining per-broker accuracy for execution and compliance. Remember that for CGT your Section 104 pool for a given share class spans all of your own accounts.

For tax-loss harvesting in the UK: (1) Track each lot with acquisition date and cost. (2) Before the tax year-end (5 April), identify holdings sitting at a loss. (3) Sell to realise the loss (offset against gains, or carry forward). (4) Crucially, mind the 30-day 'bed and breakfast' rule - if you buy the same shares back within 30 days, the sale is matched to the repurchase and the loss is neutralised. The same applies if your spouse/civil partner buys them back. To keep the loss, either stay out for more than 30 days or buy a similar-but-not-identical asset (e.g., a different fund or ETF tracking the same market). (5) Use your GBP 3,000 annual exempt amount each year - it cannot be carried forward. The position manager should sort lots by gain/loss and flag any 30-day windows.

Methods: (1) Tag at entry - when placing a trade, specify the strategy. Most accurate. (2) Rules-based - define rules (e.g., CFD/spread-bet day-trades = intraday strategy, holdings >30 days = long-term). Automated but less precise. (3) Manual attribution - periodically assign unattributed positions. Flexible but requires effort. Best practice: tag at entry, use rules as a backup, allow manual override. Track strategy separately from account - the same account can have multiple strategies.

Key considerations: (1) Track days to expiry prominently. (2) Alert when expiry is within X days (e.g., 5 days). (3) Monitor time decay (theta) acceleration near expiry. (4) Understand exercise/assignment scenarios for in-the-money options. (5) Decision framework: close before expiry to capture remaining value, let it expire worthless if out-of-the-money, or manage exercise/assignment if in-the-money. The position manager should highlight approaching expiries and provide decision-support data.

When positions are transferred (e.g., broker to broker): (1) Document the original acquisition dates and pool cost before transfer. (2) After transfer, manually input the original lot details into the new system. (3) Keep a paper trail (old contract notes) as evidence for HMRC. (4) If history is truly lost, you may have to reconstruct the Section 104 pool from statements, but this risks an inaccurate cost. For in-specie/nominee transfers, the original acquisition details should travel with the securities - verify this happened correctly so your pool stays accurate.

Key design elements: (1) In-memory position store - a database is too slow for HFT. Use Redis or a custom in-memory structure. (2) Lock-free updates - use atomic operations, avoid blocking. (3) Aggregate tracking - track net position, not every micro-lot. Lot details can be computed later. (4) Async persistence - write to the database asynchronously, don't block trading. (5) Snapshot + journal - periodically snapshot state, journal changes, enabling fast recovery. (6) Pre-computed limits - check limits without database queries. Target: position update <1ms, limit check <100us.

HA architecture: (1) Primary-standby with synchronous replication for the position store. (2) Failover within seconds using leader election (Zookeeper, etcd). (3) Stateless application servers - multiple instances behind a load balancer. (4) Event sourcing enables a standby to catch up from the event log if needed. (5) Health checks and automatic failover. (6) Geographic redundancy for disaster recovery - async replicate to a secondary region. (7) Graceful degradation - read-only mode if the primary fails but the standby isn't ready. Test failover regularly.

Corporate action automation: (1) Subscribe to a corporate action feed (exchange data, or a vendor such as Refinitiv/Reuters). (2) Parse action details: type, ratio, ex-date, record date. (3) On the ex-date, identify affected positions. (4) Calculate adjustments: Split/Bonus - multiply quantity by ratio, divide cost by ratio. Dividend - no position change, log income separately. Rights - create a rights position, handle the subscription choice. (5) Apply adjustments transactionally. (6) Reconcile against the broker statement post-adjustment. (7) Handle edge cases: fractional shares, positions opened between record and ex-date.

Reservation prevents over-allocation when multiple orders compete for limited position capacity: (1) When an order is submitted, reserve capacity: available_capacity -= order_quantity. (2) Store the reservation with order ID and timestamp. (3) On fill, convert the reservation to a position. (4) On cancel/reject, release the reservation. (5) Handle partial fills - convert the filled portion, keep the reservation for the remainder. (6) Timeout stale reservations (if order status is unknown for too long). (7) Atomic operations - check capacity and reserve in a single transaction. (8) Include reservations in limit calculations. This prevents scenarios where two strategies both think they can take 100-share positions when only 100 shares of capacity remain.

Consistency challenges and solutions: (1) Single source of truth - one authoritative position store, read replicas for queries. (2) Event ordering - use a message queue with ordering guarantees (Kafka partitioned by account). (3) Idempotent updates - the same event applied multiple times yields the same result. Use an event ID to detect duplicates. (4) Eventual consistency - accept temporary inconsistency, reconciliation catches up. (5) Conflict resolution - if two systems have different values, use timestamps (latest wins) or the broker as arbiter. (6) Saga pattern for multi-step updates - compensating transactions if part fails. (7) Validation at boundaries - verify consistency when crossing service boundaries.