User Journey: Group trades into a structure
Table of Contents
This page documents a user journey: A trader links trades that make one deal, such as the legs of a package, so that they are read and managed together.
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
"These trades are one deal, or one order, and I want the firm to hold them that way, so that they are read and managed together, and the customer gets the confirmation they expect." The journey is done when the trades belong to a structure or a package of the right kind, and it reads as one.
2. Actor and trigger
The actor is a trader. The trigger is a package, a strategy or a spread that was booked as separate trades. The journey starts with the trades, or with an existing structure, and ends when the structure is saved.
3. Steps
- Choose the trades. The person chooses the trades that make the deal. All must share the party and the counterparty, and none may belong to another structure.
- Choose the kind. The kind is a rung of the composition ladder, and it decides what the customer sees. A package is not a second entity. It is the bottom rung, a structure of kind Package, in the same table. A strategy, a typed structure and a dynamic structure bind their legs economically: the customer holds one deal, so it is confirmed as one document and priced as a whole. A package binds nothing economic: the customer holds each trade under its own terms, so each leg confirms on its own and the package is priced leg by leg. A strategy has one product family. A strategy and a typed structure rest on a template. A package has none. The test is how the customer holds the trades, not the size of the deal. See Trade Structures and Deal Composition and Confirmations.
- Assign the roles. For a template, the person assigns each trade to a role, and the system checks how many legs each role holds. For a package, any role is allowed and none is required.
- Save. The system writes the structure, its members and the links. A trade moves from one structure to another without being rewritten.
- Read the structure. The system shows the legs, and how the deal confirms and prices. The internal version is read from the legs. The external version is the deal's for a structure that confirms as a whole, and each trade's own for a package.
- Unlink. The person may unlink a trade. For a package the other legs are unaffected. For a structure that confirms as a whole, unlinking changes the deal the customer holds, so a partial close-out is a lifecycle event and not an unlink.
4. Screens
This journey is a use case. The structure is an entity with its own page, which lists its members and holds the Edit and Workflows actions of the Entity screen specification. The trade page links to the structure it belongs to.
The Trades prototypes draw it in structure-page. 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 |
|---|---|---|
structure |
The deal: party, counterparty, kind, template, parent | ores.trading.structure |
6. Operations and messages
| Step | Operation | Subject | Status |
|---|---|---|---|
| Choose | Offer kinds and templates | trading.v1.structure_kinds.list, trading.v1.structure_templates.list |
exists |
| Save | Write the structure | trading.v1.structures.put |
exists |
| Save | Write the members | trading.v1.structure_members.put_many |
exists |
| Save | Write trade links | trading.v1.trade_links.put_many |
exists |
| Read | List a structure and its members | trading.v1.structures.get, trading.v1.structure_members.list |
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
- The rule that all members share the party and the counterparty is enforced by the database. The client gets an error and no check beforehand.
- A structure nests one level at most. The client gets the error from the insert trigger.
- The structure's internal version is read from its legs and is not stored. No operation returns it. The structure page needs one.
- A structure that confirms as a whole has an external version that lives on the structure,
and the
structuretable has no column for it. Only a package's legs carry their own. Where the deal's external version is stored is not decided. It is filed as a capture. - The kind carries
confirms_as_whole. Whether a dynamic structure confirms as a whole is assumed from the ladder and is not stated in the model. - A strategy has one product family and a typed structure may mix them. The database does not check the family. The screen checks it.
- A composite trade is not a package. A composite trade is one trade that holds its own legs
(
composite_leg). A package links separate trades withstructure_member. The two overlap today, and the data model note treats the composite trade as the untyped structure of the present. A decision is needed on whether a composite trade becomes a package. - A composite trade's legs are not in the economic digest (capture linked in the amend journey).
8. Related journeys
- Book a trade — to book the trades before they are grouped.
- Review a trade and its history — to read a member.
9. Related knowledge
- Trade Structures and Deal Composition — the composition ladder and the rules.