User Journey: Review a trade and its history
Table of Contents
This page documents a user journey: A trader or an operations user reads a trade, its instrument, its parties and how it came to be in its present form.
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 want to see this trade as it stands, who it is with, what it is, and how it came to be this way, so that I can answer a question about it without asking anyone." The journey is done when the person has read the trade and, if they asked, any earlier version of it.
2. Actor and trigger
The actor is a trader or an operations user who may read the trade's party. The trigger is a question: a counterparty query, a break in a report, an audit request. The journey starts at a list of trades, or at a link from another record, and ends when the person leaves the trade.
3. Steps
- Find the trade. The person searches the trades by identifier, counterparty, book, trade type, state or date. The system lists them a page at a time.
- Read the trade. The system shows the parties and the book, how the deal was struck, the state, the instrument terms with their legs and schedules, the identifiers, the party roles, the portfolios and the additional fields. Every other record is a link to its own page.
- Read the history. The system lists every version of the trade, and every activity that caused one, with who did it, when and why. The person sees the difference between two versions.
- Read the trade as it stood. The person chooses a date. The system shows the trade as of that date.
- Follow a link. The person goes to the counterparty, the book, a structure the trade belongs to, or a linked trade.
4. Screens
This journey is a use case. The standard screens serve it: the trade list, the trade page with a tab for each aspect, and the History timeline, all as the Entity screen specification and the Record screen standard describe. The Qt client had a detail dialog and a history dialog. They become a page and a tab, and the person reads one subject on one page.
The Trades prototypes draw it in trade-page: the list, the page and the History tab. 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 trade's facts, version and external version | ores.trading.trade |
6. Operations and messages
| Step | Operation | Subject | Status |
|---|---|---|---|
| Find | Search the trades by trade type, and filter by counterparty and trade type | trading.v1.trades.list: the filter record has counterparty_id, trade_type, their one-of members and search |
exists |
| Find | Search by identifier, and filter by state and book | trading.v1.trades.list has no member for them |
missing |
| Read | Read the trade and its instrument | trading.v1.trades.get, trading.v1.<instrument>s.get |
exists |
| Read | Read the booking and the state of a trade | trading.v1.trade_bookings.list, trading.v1.trade_states.list with trade_id_one_of |
exists |
| Read | Read the identifiers, party roles, portfolios, additional fields and the instrument's legs of a trade | trade_identifiers.list, trade_party_roles.list, trade_portfolios.list, trade_additional_fields.list, bond_legs.list and the other child tables: no by-trade filter |
missing |
| History | List the versions | trading.v1.trades_versions.list, trading.v1.trades_versions.get |
exists |
| History | List the activities of a trade | trading.v1.trade_activities.list filters only by activity id |
missing |
| As of | Read the trade and its parts as of a date | the as_of field of the list requests (checked on trades, trade states and the bond instrument) |
exists |
Status is one of exists, partial, or missing.
A screen reads and writes through the standard entity operations of the NATS entity protocol specification. Where a row below says missing, the fix is a change to the entity's model (a filterable or searchable column, or a scoped read) and not a new operation.
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
- The trade list filters by counterparty and trade type, and searches the trade type. A person cannot yet search by identifier, or filter by state, book or date. Each filter is a server change. Until it exists, a screen cannot list trades usefully.
- The identifier, party role, portfolio, additional field and instrument child lists
(checked on
bond_leg) have no by-trade filter. They list the whole table. A trade page cannot read its own parts without reading every trade's. - The activity list filters only by activity id. It cannot return the activities of one trade, so the history cannot show what caused each version.
as_ofexists on the reads checked above. It is not checked on every child table.- The list needs the paging rule of the Entity screen specification: the pager is the request.
8. Related journeys
- Amend a trade's economics — to change what the person has read.
- Record a lifecycle event on a trade — to record an event.
- Group trades into a structure — when the trade belongs to a deal.