Investigation: the blotter and import design

The plan holds imported trades in a system book, in a new pending state, with a nullable counterparty and a nullable book. I checked whether the new model can hold that.

• The trade anchor has no nullable book. A booking names a book, and the book column is not null.
• The anchor allows no counterparty only for an intra-entity trade.
• The trade_status machine has four states: draft, live, expired and cancelled. It has no pending state.
• The sandbox page states the rule that replaces the Pending Book. A real deal is never imported into a sandbox. It is booked into a real book at once. Operations holds it as unauthorised until the queue releases it.

So the Pending Book answers a real risk with a mechanism that no longer fits. The risk is that dirty data reaches risk and P&L at once. The new model meets the risk with the operational authorisation status. That status is not a state of the trade. A trade contributes to risk when it is live and authorised.

The control exists as knowledge and as inbox machinery. The inbox holds approval kinds, requests, decisions and policies. The code does not yet join the two. The seed file holds three kinds: iam.role_grant, refdata.book_change and refdata.counterparty_change. It holds no trading.operational_authorisation kind, and no trade write raises a request.

The plan adds an is_live flag to every reference table that an import touches. The sandbox model does the same work with sources. Imported market data enters the universe under its own source. The official configuration does not resolve to that source. A configuration that an import brings has its own name. Nothing in the code carries is_live. Nothing needs it.

The plan copies from a workspace to the live workspace through the Pending Book. The workspace feature is gone. The story "Workspaces: finish the feature" is abandoned and "Remove workspaces from every component" is done. The blotter story still lists the first as its blocker. The blocker is dead.

The plan asks for a completed_with_warnings outcome and a list of failed items. The workflow has both. The step outcome has the value completed_with_warnings. The import result carries item_errors, and the execute handler sets the outcome from them. This part of the plan is complete.

The window has a batch selector, a unit selector and one tab for each data type. The code has no such window. The ORE import already runs into a sandbox. The execute handler books a trade as test when it imports into a sandbox, and as actual otherwise. The ORE portfolio prototype now chooses the sandbox and the functional currency of the new books. The sandbox page says an import is a run of a process with an identity, and refers to trade sets and trade groups. Another environment works on tracing a process run and the trade groups it creates.

The blotter page is a May domain reference. It predates the entity screen specification and the trade shape. The prototypes of this story now answer most of it.

Each trade component has its own list operation: trades, bookings, states and so on. The code has no operation that returns one row for a trade with its book, status, counterparty and authorisation status. The prototype list needs that row. It also needs structures as rows of the same level. A row that joins components in the client costs one call for each component. A row that the service joins costs one query.

The web client has no trade screen yet. The packages hold the generated wire types and the BFF only.

• Pending Book: retire it. Record the retirement on the plan page and on the sandbox page.
• Real imports: book into a real book at once. Raise an operational authorisation request for each new live trade. Use the inbox. Do not add a trade state.
• Rows that cannot be booked: report them with the source file, the trade id and the message. Store nothing. The user corrects the source or the counterparty mapping and runs the import again. This needs a check that a second run does not double-book. Treat that check as the first step of the import task.
• Read model: build one service query that returns the list rows. A row holds the trade or the structure, the book, the status, the counterparty, the authorisation status and the instrument type. The service pages, sorts and filters. The client does no joining.
• Blocker: remove the workspace dependency from the story.

Create these under the story, in this order.

1. Seed the operational authorisation kind. Add the trading.operational_authorisation approval kind. Raise a request when an actual trade goes live. Decide who may decide it.
2. Read the trade list rows. Build the list query from the decision above.
3. Build the trade list and the trade page in the web client, from the two prototypes.
4. Build Book a trade from its prototype. Include the structure card.
5. Build the structure page from its prototype.
6. Import real deals through the authorisation queue. Make the ORE import raise requests. Report the rows that fail. Prove a second run is safe.
7. Build the authorisation queue screen for Operations.

The prototype task left four items open. Each needs a decision before its screen: the enforcement of a change reason that requires commentary, a screen to add a Hedge or UserDefined link, the links that Exercise, CloseOut, Roll and MisbookingCorrection events write, and the permission that shows each trade tab. Settle them in tasks 3 and 4.

• The two May plans: mark the Pending Book and the workspace import as superseded.
• The sandbox page: state that a failed import row is reported and not stored.
• The story: drop the workspace blocker and add the tasks above.