Trade journeys

Table of Contents

A trade is an anchor that never changes, a booking and a state that do, and an instrument chosen by the trade type. Every change to the booking, the state or the instrument is caused by an activity, which is the record of one business event. The firm holds a trade exactly as agreed. When the agreed terms change, the trade's external version moves.

These journeys are use cases. Each one names a goal, an actor, the operations it needs and what is missing. A journey does not define a screen. The screens come from the UX standards. A trade is an entity, so one trade page with a tab for each aspect serves most of these journeys, and one journey can reach several screens. The Qt client was built around the trade as the entry. The prototypes keep that entry and use these journeys to decide the cards and the workflows on the page.

1. Journeys

Journey Actor Gist
Book a trade trader Record a new deal, live or as a draft, with its instrument terms
Amend a trade's economics trader Change the agreed terms, give the reason, and move the external version
Review a trade and its history trader, operations Read a trade, its parts, and every version and activity
Import a portfolio from ORE operations Bring an ORE directory's portfolio files, chosen from a list, and roll the import back
Export a portfolio to ORE operations Write trades out as the portfolio the engine reads
Record a lifecycle event on a trade operations Record an exercise, a termination or a novation
Group trades into a structure trader Hold several trades as one deal

2. Prototypes

The Trades prototypes serve these journeys. Review, amendment and lifecycle events are one trade page. Booking, ORE import and export, and grouping are workflows reached from the trade list.

3. How the screens reach the server

The trade screens use the standard entity operations of the NATS entity protocol specification: list with a page, an order and a filter record, get, put with a precondition and a change intent, and the versions of an entity. Booking and the ORE operations are domain operations in the ops namespace, and each is a gap to review.

4. What blocks all of them

  • The BFF and the web app have no trading route.
  • The trade list filters only by trade id, and most child tables have no by-trade read.
  • No operation writes an activity together with the versions it causes, except booking.
  • The economic digest leaves out the option exercise prices and a composite trade's legs.

5. How the operations were checked

Every full subject (for example trading.v1.trade_types.list) was checked by script against the protocol headers: 33 of 33 exist. A row that names a pattern, such as trading.v1.<instrument>s.put, or a short form, such as trade_states.list, was read by hand in the headers and cannot be checked by script. The filters, the as_of field and the by-trade reads were read in the protocol headers of trade, trade_state, trade_activity, trade_identifier and bond_leg. They were not read for every child table.

6. Related

Emacs 29.3 (Org mode 9.6.15)