User Journey: Amend a trade's economics

"The deal changed after we booked it, and I want the firm's record to say what was agreed now, with the reason, and I want everyone who relies on the trade to see that it changed." The journey is done when the trade reads with the new terms, a new version and an activity that names the reason, and the external version has moved if the change was economic.

The actor is a trader, or an operations user acting for one. The trigger is a correction of a booking error, or an agreed change to the terms of a live trade. The journey starts on a trade and ends when the amendment is saved, awaits confirmation, or is refused.

1. Open the trade. The person opens the trade they want to change.
2. Say what kind of change it is. The person chooses the activity first: an amendment of the economic terms, a change of reference details, a correction of a misbooking, or a null amend. The kind of change bounds what the person may edit. A person who chooses an economic amendment cannot edit a field that is not economic. The system offers only the activity types the state machine allows from the trade's present state.
3. Change the terms. The person edits the part of the trade that changed: an instrument term, a leg, a booking field or an identifier. The person changes one part at a time and gives a reason each time.
4. Review the effect. The system shows the fields that changed and says whether the change is economic. An economic change moves the trade's external version. A change that is not economic does not.
5. Save. The system writes the activity and the component versions that the activity causes, and shows the new versions.
6. See what follows. A confirmable change issues a new confirmation to the counterparty, and the amended terms wait for it.
7. Handle a refusal. The system refuses a stale write, a change the state does not allow, and a field that fails a check. The trade stays as it was.

This journey is a use case. The trade page serves it: an Edit button on each card opens a dialog that asks for the change and the reason, as the Entity screen specification requires. History shows the result. There is no separate amend screen. A prototype must show the activity type, the state check and the economic mark inside that dialog.

The Trades prototypes draw it in trade-page: Edit on the Instrument card. No wireframe is drawn here. The prototype story draws the screens, from the UX standards and from this use case.

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.

• Nothing writes an activity with the versions it causes in one transaction. Only book_trade does. An amendment is several writes today.
• Nothing tells the client which activity types the present state allows. The state machine is in the model and the client cannot ask.
• Nothing tells the client whether a change is economic before it saves. The server computes the digest and moves the external version afterwards.
• The economic digest does not read the option's exercise prices or a composite trade's legs. A change to either does not move the external version. Fix both before this journey is built. The captures are linked below.
• The party and the counterparty are fixed for the life of a trade. A change to either is a cancel and rebook, which the lifecycle journey covers, and not an amendment. See Trade Versioning.
• The confirmation the counterparty gives has no operation and no journey. The escalation of some reasons to a head of desk belongs to the story Build the four-eyes framework.

• Review a trade and its history — to read the history of the amendment.
• Record a lifecycle event on a trade — when the change is an exercise, a termination or a novation.

• Exact Numbers and Economic Change — what is economic, and when the external version moves.
• The option's exercise prices are not in the economic digest — capture.
• A composite trade's legs are not in the economic digest — capture.

• Trade journeys
• User Journeys