Story: Trade Blotter
Table of Contents
This page documents a story in Sprint 28. It captures the goal, current status, acceptance criteria, and the tasks that compose it.
1. Goal
Build the Trade Blotter: the primary front-office screen from which traders, sales, and middle office view, manage, and act on the live book of trades – booking new deals, amending existing ones, and routing trades through their lifecycle (expiry, fixing, delivery, exercise, settlement). See the target-state reference: Trade Blotter (knowledge doc) – multi-panel architecture, deal grid, deal actions, STP panel, Expiry/Fixing Manager, Barrier Management, Delta Jump Screen, Spike Map.
The original design said this story depends on Workspaces: finish the feature,
and that a production import needs a holding location, the Pending
Book. The design task found that the sandbox model replaced both. The
workspace story is abandoned and the Pending Book is retired. A real
deal books into a real book at once and waits in the operational
authorisation queue (see * Decisions).
2. Status
| Field | Value |
|---|---|
| State | DONE |
| Parent sprint | Sprint 28 |
| Now | Nothing. |
| Waiting on | Nothing. |
| Next | Nothing. |
| Last touched | 2026-10-24 |
3. Acceptance
The story closes on the tasks it finished:
- Design: recover and re-validate the prior blotter/import analysis.
- Check the trade prototypes against the entity screen specification.
- Bring the trade page prototype to the entity screen specification.
- Seed the operational authorisation kind.
- Read the trade list rows.
4. Tasks
| Task | State | Start | End | Description |
|---|---|---|---|---|
| Design: recover and re-validate the prior blotter/import analysis | DONE | 2026-10-21 | 2026-10-21 | Check the May import plan against the code and the sandbox model, record the design, and scope the implementation tasks. |
| Check the trade prototypes against the entity screen specification | DONE | 2026-10-19 | 2026-10-20 | Check each trade prototype against the entity screen specification and fix the differences, starting with the trade page, then book a trade, the structure page, the ORE portfolio and trade entry. |
| Bring the trade page prototype to the entity screen specification | DONE | 2026-10-19 | 2026-10-20 | Fix the differences the review of the trade page prototype recorded, and carry the shared fixes to the four prototypes that share common.js. |
| Seed the operational authorisation kind | DONE | 2026-10-21 | 2026-10-21 | Add the trading.operational_authorisation approval kind and raise a request when an actual trade goes live. |
| Read the trade list rows | DONE | 2026-10-22 | 2026-10-24 | Build one service query that returns trades and structures as rows of one level, paged, sorted and filtered. |
| Move the authorisation request into a booking workflow | ABANDONED | 2026-10-23 | Raise the authorisation request in a workflow step after the trade commits, so trading no longer writes inbox rows in its own transaction. |
5. Decisions
- Closed at sprint 28 close with its 5 done tasks. The 7 open tasks and the original acceptance moved to Trade Blotter — the remaining work in the product backlog inbox.
The design is in Investigation: the blotter and import design. These decisions come from it.
- The Pending Book is retired. The sandbox, the
draftstate and the operational authorisation status replace it. A real deal books into a real book at once. It waits in the authorisation queue, which uses the inbox. The trade gets no new state. - The
is_livemarker is not built. Sources and named configurations keep imported data out of official use. - The workspace dependency is gone. The workspace story is abandoned and the workspaces are removed.
- The
completed_with_warningsoutcome and theitem_errorslist are built. No task remains for them. - A row that an import cannot book is reported with its source file, trade id and message. Nothing is stored. The user corrects the source and runs the import again.
- The trade list reads one row for each trade or structure, joined in the service. The client does no joining.
- The blotter is a trade list and a trade page. The authorisation queue is a second screen for Operations. The Expiry, Fixing, Barrier, Delta and Spike screens are separate and stay out of this story.
- Positions and the trade-expiry workflow stay in the backlog. The capture on separate trade and instrument dialogs is answered by the trade page, which has a Details tab and an Instrument tab. Close the capture when the page ships.
6. Out of scope
- The Positions domain model and the trade-expiry workflow stay in the backlog as separate captures.
- Importing from FpML, CSV or another trading system. Only the ORE import exists. Each other source needs its own story.
- The Expiry, Fixing, Barrier, Delta and Spike screens.