How to test trade cancellations and amendments

Trade cancellation and amendment testing verifies that cancelling or changing a booked trade applies the permitted lifecycle transition, preserves transaction integrity and propagates the correct state and values to dependent systems. It checks eligibility against trade status and business rules, records an auditable history, and prevents duplicate or partial effects when requests are retried, rejected or processed asynchronously.

What to test in trade cancellations and amendments

Start with the product and lifecycle rules. A cancellation before execution may remove an unexecuted instruction from further processing. A post-execution cancellation may instead be handled as a trade bust, reversal or compensating transaction. The names and permitted actions vary by system and market process, so derive expected behaviour from the applicable requirements.

For amendments, identify which fields can change at each lifecycle stage. Common examples include quantity, price, counterparty, settlement date and allocation. Check that each change is permitted, that the resulting trade satisfies validation rules, and that the system retains the original values and the amendment history where required.

Build cases around valid and invalid states, such as:

• Amend a booked trade before confirmation and verify the updated values reach confirmation processing.
• Attempt to amend a trade in a state where changes are prohibited and verify a clear business rejection with no data change.
• Cancel an eligible trade and verify its status, positions and downstream processing reflect the cancellation.
• Submit the same cancellation or amendment request again and verify the defined duplicate-request behaviour.
• Change a field at a boundary, such as a quantity at the permitted minimum, and verify the relevant rule.

State transition testing helps make the permitted actions and outcomes explicit for each status.

Check the full transaction chain

Trace the trade across the systems that consume or act on it. Depending on the architecture, these may include the trading platform, confirmation service, settlement processing, position keeping, risk calculations and the general ledger. Verify both the trade's current state and any events or messages sent to downstream systems.

For an amendment, check that a consumer receives the correct version and does not retain stale values. If the implementation represents a change as a cancellation followed by a replacement trade, verify the relationship between the original and replacement records. For a cancellation, check that downstream positions or settlement instructions are reversed or stopped according to the relevant rules. Cross-system testing can expose discrepancies that a successful response from the trade API alone will miss.

Exercise API behaviour and failure handling

Use API tests to check request validation, authorisation, business responses and persistence. Include missing or invalid fields, an unknown trade identifier, an unauthorised user and a request for a trade in an ineligible state. Confirm that a rejected request leaves the trade and its downstream records unchanged.

Test retries and asynchronous processing deliberately. A client may time out after the service commits a change, then retry. Verify that an idempotency mechanism or equivalent rule prevents a second business effect. Where events are delivered asynchronously, check ordering, duplicate delivery and recovery after a consumer or network failure. A retry should not create multiple replacement trades or apply an amendment to an obsolete version.

Worked example: amend a booked trade

Assume trade TR-8041 is booked at a quantity of 100 and price of 25.50. The business rule permits a quantity amendment before confirmation. The example request is illustrative; use the interface and field names defined by the system under test.

{
  "tradeId": "TR-8041",
  "expectedVersion": 3,
  "changes": { "quantity": 120 },
  "reason": "Allocation correction"
}

Assert that the response identifies the accepted amendment and resulting version. Then retrieve the trade and check that its quantity is 120, its price remains 25.50, and its status follows the specified lifecycle rule. Check that the amendment record links to the original trade and contains the actor, timestamp and reason required by the system. Finally, verify that confirmation and position records reflect the amended quantity, with no duplicate trade or stale version remaining.

Repeat with an obsolete expectedVersion or a trade already past the permitted stage. The expected result should follow the interface contract: reject the request or route it through an approved correction process, with no unintended partial update. Keep test data isolated and resettable so that asynchronous messages and prior runs do not affect the result.