How to test a foreign exchange trading workflow

Foreign exchange trading workflow testing verifies that an FX trade moves correctly through the systems and controls that handle pricing, validation, execution, booking and settlement. It checks that each stage uses the right trade data, applies the configured business rules, and leaves consistent records across connected applications. The exact workflow depends on the product, such as spot, forward or swap, and on the institution's operating model.

Map the workflow and its states

Document the expected path before writing tests. A common front-to-back flow starts with a customer or trader request, obtains a price, applies pre-trade controls, executes or rejects the trade, books the result, sends or receives confirmation, and prepares settlement instructions. Reconciliation then compares records across relevant systems. Some workflows omit stages or use different applications.

Define valid states and transitions for each trade. For example, a trade may progress from quoted to accepted, partially filled, fully filled, booked, confirmed and settled. Specify which roles or system events can cause each transition, and what happens after cancellation, amendment, rejection or a timeout. State-transition testing helps expose illegal transitions, such as settling an unbooked trade.

Set the test scope and preconditions. Record the currency pair and its direction, the trade date, product, amount, price source and timestamp, customer or counterparty, applicable limits, and settlement instructions. Confirm that reference data, permissions, market calendars and downstream interfaces are configured for the test environment. Environment drift in rate conventions, limits or calendars can create misleading failures.

Test the rules and system boundaries

Check pricing and trade calculations against an explicit oracle: the captured quote and its validity period, configured pair conventions, and agreed rounding rules. Test expired or unavailable quotes, price changes during acceptance, invalid pair or amount, and boundary values at configured limits. Verify that a request outside a limit is rejected or routed for approval according to the specified rules.

Exercise integrations at the points where data changes hands. Compare the request, execution response, booked trade and confirmation for pair, buy and sell currencies, amounts, rate, value date, counterparty and identifiers. For an interface timeout, establish whether the trade was accepted before retrying. Verify duplicate protection and recovery behaviour so a retry cannot create an unintended second trade. Check that failures are visible and can be investigated from recorded events or audit data.

Test execution outcomes including full fills, partial fills, rejection and cancellation where the product supports them. For each outcome, verify the resulting trade state, remaining quantity, cash amounts and downstream messages. Settlement checks should cover the configured value date, settlement instructions and currencies, then verify that status and amounts reconcile across the trade and settlement records. Treat trade execution and settlement as separate stages: a successful execution does not prove that settlement completed.

Worked example: EUR/USD spot trade

Assume the test system receives a valid EUR/USD quote of 1.08420 USD per EUR. The trader requests to buy EUR 1,000,000 at that rate, and the simulated execution service returns a full fill. Excluding fees, the expected USD amount is 1,084,200.

Verify that the quote was valid when accepted, the buy and sell currency amounts use the stated pair direction, and the execution response and booking contain the same trade identifier and agreed values. Then check that the confirmation reflects the booked trade and that settlement uses the value date and instructions configured for the test. The exact date and any rounding or fees must come from the product rules and test data, rather than assumptions in the test.

Add a companion case where the execution response times out after the service has accepted the request. Retry using the workflow's supported recovery mechanism and verify that the system finds or resumes the original trade instead of booking a duplicate. Also check the final state in each connected system, not just the user interface response.

Verify outcomes and evidence

Use API assertions, message or event checks, database queries where permitted, and user-interface checks to cover the appropriate boundaries. An end-to-end test can confirm that the business journey works, while focused integration tests help identify which interface or rule failed. Keep test data controlled and isolated, especially for trade identifiers, counterparties and settlement instructions.

Capture the inputs, quote source and timestamp, responses, state changes, correlation identifiers and reconciliation results. A test passes when expected records and states agree across the systems in scope, and any rejected or interrupted path follows its defined recovery process. Link cases to the relevant workflow rules and risks so changes to pricing, controls or interfaces prompt targeted regression testing.