Position Manager

Your broker's platform shows positions but may not provide: multi-strategy tracking, detailed lot-level records, custom alerts and limits, integration with your trading strategies, or a consolidated view across multiple brokers and across CDP and custodian accounts. 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. Popular Singapore retail tools like StocksCafe also help aggregate and track holdings.

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 P&L reporting, the cost basis of the shares sold is determined by your chosen method (commonly FIFO), which may differ from your display average cost if you bought in multiple lots. In Singapore this only affects your P&L presentation, not tax, since there is no capital gains tax.

Key differences: (1) Futures use daily mark-to-market - gains/losses are settled to your account each day, not just when you close. (2) Margin requirements fluctuate with position value. (3) Derivatives positions have expiry dates. (4) Lot/contract sizes are fixed. (5) For stocks, settlement is T+2 and Singapore's contra mechanic lets you net-settle a buy-then-sell within the cycle. Your position manager should track these differences and display appropriate information for each position type.

Common reasons: (1) The broker may include brokerage and fees in average cost while you may not. (2) Different handling of partial fills. (3) Corporate actions may have been applied differently. (4) Your calculation might use average cost while the broker uses FIFO for certain displays. Always reconcile and understand the methodology difference. Keep your own accurate records for performance tracking.

Investigate immediately: (1) Check for pending settlement (T+2 means a buy today shows in holdings two business days later). (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/CDP 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 (StocksCafe is popular in Singapore; robo-adviser dashboards also help) that aggregate across brokers. (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, and reconcile each account separately - keeping in mind that some holdings sit in CDP and some in custodian/nominee accounts. The key is having one source of truth for total exposure while maintaining per-broker accuracy for execution.

This is much simpler than in markets with capital gains tax. Singapore has no capital gains tax, so there is no tax-loss harvesting to do and no holding-period clock to track for an individual investor. What to track: (1) Turnover and trade frequency - if your activity is frequent and systematic, IRAS may assess it as a trade and tax profits as income, so high turnover is the thing to watch. (2) Foreign dividend withholding tax on any foreign holdings (e.g., ~30% on US-domiciled, ~15% on Irish UCITS) - capture this per holding. (3) Dividend income for completeness (Singapore dividends are tax-exempt under the one-tier system). Your position manager should support turnover reporting and per-holding withholding-tax tracking rather than capital-gains lot optimisation.

Methods: (1) Tag at entry - when placing a trade, specify the strategy. Most accurate. (2) Rules-based - define rules (e.g., contra/intraday = 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, and allow manual override. Track strategy separately from account - the same account can hold 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 ITM options. (5) Decision framework: close before expiry to capture remaining value, let it expire worthless if OTM, or manage exercise/assignment if ITM. Remember that on SGX single-stock options are thin, so most options activity is in index or overseas options - factor in their settlement conventions. The position manager should highlight approaching expiries and provide decision-support data.

When positions are transferred (e.g., broker to broker, or CDP to custodian): (1) Document the original acquisition date and cost before the transfer. (2) After the transfer, manually input the original lot details into the new system. (3) Keep a paper trail (old contract notes/statements) for your records. (4) If history is truly lost, use the first statement from the new broker as cost basis - in Singapore this affects only your P&L presentation, not tax, since capital gains aren't taxed. For CDP transfers, original details should travel with the securities - verify this happened correctly.

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 and journal changes for 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/CDP data, or a vendor). (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 (tax-exempt for residents in Singapore). Rights - create a rights position, handle the subscription choice. (5) Apply adjustments transactionally. (6) Reconcile against the broker/CDP 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 a 100-share position 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.