Story: Trade status FSM and activity type
Table of Contents
This page documents a story in Sprint 14. It captures the goal, current status, acceptance criteria, and the tasks that compose it.
Goal
Replace the loose lifecycle_events concept with a proper trade- status FSM + activity_type taxonomy so trade lifecycles are enforced + auditable.
Status
| Field | Value |
|---|---|
| State | DONE |
| Parent sprint | Sprint 14 |
| Now | Completed 2026-03-02. |
| Waiting on | None. |
| Next | None. |
| Last touched | 2026-03-02 |
Acceptance
- Trade status FSM enforces valid state transitions.
- activity_type taxonomy maps to FpML event types + FSM transitions where applicable.
- trade_status_service::resolve_status() validates + applies transitions.
- Cross-tenant leak fix in refdata.
Tasks
| Task | State | Start | End | Description |
|---|---|---|---|---|
| Implement trade status state machine | DONE | 2026-05-20 | 2026-03-02 | Trade status FSM (new / live / expired / cancelled) inside ores.dq integrated into ores.trading; activity_type taxonomy replaces lifecycle_events (categories: new activity, lifecycle event, misbooking, valuation change, cancellation; FpML + FSM mapping); ores_trading_trades_tbl grows activity_type_code + status_id; trade_status_service::resolve_status() enforces transitions; reflectcpp portfile bson fix; ores.refdata cross-tenant leak fix. |
Decisions
- activity_type, not lifecycle_events
- richer taxonomy for P&L attribution and reporting.
- FSM in ores.dq
- lifecycle FSMs are DQ metadata (per the sprint-13 FSM consolidation).
Out of scope
- Multi-leg trade transitions.
- Cancellation-with-counterparty-confirmation workflow.
See also
- FSM consolidation into DQ (sprint 13) — supplies the FSM home.