User Journey: Book a trade

Table of Contents

This page documents a user journey: A trader records a new deal: its trade type, its party and counterparty, its book, and its instrument terms.

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

"I have agreed a deal and I want the firm to hold it exactly as agreed, in the right book, against the right counterparty, so that it is valued, confirmed and reported from the first day." The journey is done when the trade reads back with its instrument, its booking, its first state and the activity that created it.

2. Actor and trigger

The actor is a trader, or an operations user booking for a trader, inside one party of the tenant. The trigger is a deal agreed by voice, by chat or on a venue, or a draft the trader wants to capture before the deal is agreed. The journey starts with the choice of a trade type and ends when the trade is booked, saved as a draft, or refused.

3. Steps

  1. Choose the trade type. The person names the kind of deal in a combo box, grouped by product. The system lists the trade types from the catalogue, and lists the ones with no instrument table without letting the person choose them. The trade type decides which instrument terms the deal has, because each trade type routes to one instrument table.
  2. Say who is on the deal. The person names the party, the counterparty and the book. The system offers only the counterparties the party may trade with. A book must be a real book, unless the trade is a pre-agreement draft, a test or a hypothetical.
  3. Say how it was struck. The person gives the trade date, the execution time, the booking nature, the entry channel and the counterparty scope. The system offers the values each lookup holds.
  4. Enter the instrument terms. The person gives the terms the trade type needs: notional, dates, rates, legs and so on. The system shows the fields for that trade type and no others.
  5. Add what identifies and classifies the trade. The person adds identifiers (the firm's own, a venue's, ORE's trade id), party roles, portfolios and additional fields. All are optional.
  6. Choose live or draft. The person books a live trade (activity new_booking) or captures a draft (activity draft_capture).
  7. Confirm. The system writes the anchor, the booking, the first state and the activity in one transaction. The system then writes the instrument. It reports the trade, its state and its version.
  8. Handle a refusal. The system refuses a trade id that is already booked, a book that is not allowed, and a field that fails the trade type's checks. The system keeps what the person entered and says what was refused.

4. Screens

This journey is a use case. It has no screen of its own. Booking is the Add of the trade list: a Book a trade button opens a new-trade page, which the Entity screen specification describes. The page has four tabs (Trade, Instrument, Identifiers and Review), and the person fills them in. The trade type is a combo box, and the Instrument tab has a tab for each part of that instrument. A guided sequence is allowed only when it makes booking quicker, and a trader booking a deal knows the whole deal, so the page is not a sequence.

The Trades prototypes draw it in book-a-trade, as one page in tabs. 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 The anchor and the wide trade: party, counterparty, trade type, classification, origin ores.trading.trade

6. Operations and messages

Step Operation Subject Status
Choose the type Offer the trade types trading.v1.trade_types.list exists
Say who Offer counterparties and books refdata.v1.counterparties.list, refdata.v1.books.list exists
Say how Offer booking natures, entry channels and counterparty scopes trading.v1.booking_nature_types.list, trading.v1.entry_channel_types.list, trading.v1.counterparty_scope_types.list exists
Instrument terms Offer the lookups the trade type's fields use trading.v1.<lookup>.list for each lookup exists
Identify Write identifiers, party roles, portfolios and additional fields trading.v1.trade_identifiers.put_many, trade_party_roles.put_many, trade_portfolios.put_many, trade_additional_fields.put_many exists
Confirm Book the anchor, the booking, the first state and the activity trading.v1.ops.book_trade partial
Confirm Write the instrument and its child rows trading.v1.<instrument>s.put, then each child table's put_many partial

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

  • book_trade does not write the instrument. A trade is booked, and for a moment has no instrument, until a second write. One operation must write both, or the order and the repair of a half-booked trade must be defined.
  • No operation tells a client which fields a trade type needs. The client would have to read the model. A catalogue read would remove that.
  • The web app and the BFF have no trading route. Nothing here is reachable from a browser yet.
  • The four-eyes rule for a trade, if any, is not stated for booking. The activity types carry a requires_confirmation flag, which is the counterparty's confirmation and not an internal approval. No journey covers the counterparty's confirmation. The story Build the four-eyes framework owns any escalation.

8. Related journeys

9. Related knowledge

10. See also

Emacs 29.3 (Org mode 9.6.15)