User Journey: Record a lifecycle event on a trade

Table of Contents

This page documents a user journey: An operations user records an exercise, a termination, a novation or another event that changes a live trade.

A user journey describes what one person is trying to do, before anything is built. It is a design document that outlives any sprint. These trade journeys are use cases, so they name the operations and messages each step needs and leave the screens to the UX standards.

1. Goal

"Something happened to a live trade, such as an exercise, a termination or a novation, and I want the firm's record to say so, with the effect on the trade, so that the trade is right on the day." The journey is done when the activity is recorded, the trade's state has moved, and the versions the event causes are written.

2. Actor and trigger

The actor is an operations user. The trigger is a notice from a counterparty or a venue, or a date in the trade. The journey starts on a trade and ends with the event recorded, awaiting confirmation, or refused.

3. Steps

  1. Open the trade. The person opens the trade the event concerns.
  2. Choose the event. The person chooses an event type. The system offers only the events the trade's state allows. A trade is draft, live, expired or cancelled, and expiry and cancellation are reversible, because either may have been recorded in error. See Trade Lifecycle.
  3. Give the facts of the event. The person gives the date and the terms the event changes, such as the exercised amount or the new counterparty.
  4. Review the effect. The system shows the trades the event touches, the state each one moves to and the versions it writes. A novation and a book move are a cancel and rebook: the original trade is cancelled, a new trade with a fresh id is booked, and a trade link joins the two in one transaction. The system never deletes a version. A person undoes an event with its mirror event.
  5. Record. The system writes the activity and the versions in one transaction.
  6. Confirm, if needed. When the event requires confirmation, it waits for it.

4. Screens

This journey is a use case. The Workflows menu of the trade page carries the event actions, and the activity shows in the History timeline. The Qt event window maintained the lookup of event types, which is reference data. This journey records an event on one trade.

The Trades prototypes draw it in trade-page: Workflows, Record a lifecycle event. No wireframe is drawn here. The prototype story draws the screens, from the UX standards and from this use case.

5. Entities composed

Entity What it contributes Model
trade_activity The event, who recorded it and when ores.trading.trade_activity

6. Operations and messages

Step Operation Subject Status
Choose Offer the activity and event types trading.v1.activity_types.list, trading.v1.lifecycle_events.list exists
Choose Say which events the state allows none missing
Record Write the activity and the versions it causes in one transaction none missing
Record Write the activity trading.v1.trade_activities.put exists

Status is one of exists, partial, or missing. A subject that contains <instrument> stands for the one instrument table the trade type routes to. The plural is written with a plain s. A table whose plural is irregular, such as trade_activities, has its own subject: check the protocol header, not the pattern.

7. What is missing

  • No operation writes an activity with the versions it causes. This is the same gap as in the amendment journey. One operation should serve both.
  • A novation or a book move books a second trade and a trade link with the cancellation. No operation does the three writes in one transaction.
  • The model lists lifecycle_event as reference data and activity_type as the type of an event. The two overlap. A decision on which one the screen offers is needed.

8. Related journeys

9. Related knowledge

10. See also

Emacs 29.3 (Org mode 9.6.15)