Test Cases

[SelwynChan]

An investment bank has a regulatory requirement to provide cash equity order lifecycle to the regulator in a specific format. The PWM division of the bank has salespeople who receive orders from their clients and enter them into the PWM OMS. The order is then routed to the trading OMS where the trader in the global markets division sees the order, splits it to market and executes. Executions / fills are populated by the trader in the trading OMS which route the events back to the PWM OMS.
The regulator requires order lifecycle event data and associated reference data (about clients, accounts, users mentioned in the event data) to be provided in CSV files. As the PWM client, account and salespeople are not routed from the PWM OMS to the trading OMS, the global markets division cannot populate these fields when generating the regulatory dataset for orders they received from PWM.

In the regulatory format, each order has a logicalOrderID. Each event has a logicalOrderID field that is used to link all events into an overall order.

To resolve this, global markets will generate a dataset compliant with the regulatory data format but the below data will be missing:

1. accountID for each order lifecycle event will be populated with a garbage value
2. clientID for each order event will be populated with garbage
3. salesID is blank
4. aggregated order details are missing

Let me expand on #4. The regulator requires that aggregated orders be reported in a specific way. An aggregated order, say for 1000 shares can be an aggregated order of multiple constituent orders. The constituent orders might be 400 shares for account 123 and then 600 shares for account 456 in this example. The regulator requires that the constituent orders are represented as completely separate orders with their own logicalOrderIDs. In this example, the logicalOrderIDs for each constituent order might be ALLOC1 and ALLOC2The aggregated order should have accountID = na and clientID = na but there's another field aggregatedOrders that links the aggregated order to the constituent orders (e.g. aggregatedOrders might be "ALLOC1=400|ALLOC2=600" for this example). Whenever executed quantities are allocated to the accounts, there needs to be an event with eventType 'AALC' belonging to the aggregated order's logicalOrderID which specifies that a quantity has been allocated to a constituent logicalOrderID. As order allocations are not routed to global markets, PWM need to enrich the dataset with these constituent orders and AALC events as well.

To create a compliant data package, PWM need to download the data from a global markets API and enrich it with data found in the PWM OMS.

Based on your general knowledge of different high-touch equity flow orders, generate a full set of test scenarios or test cases for PWM to comprehensively test this workflow. It should include different scenarios in order handling by PWM.

[SelwynChan]

Orders received by an In-Scope Broker may be one of several different ’types’ of orders specifying different behaviours, such as price limitations, conditional logic and targeting a benchmark price, etc. The types of orders offered by InScope Brokers differ widely across organisations. To capture such instructions in a consistent manner, the orderType and orderInst fields are used where orderType categorises the order into one of several types as defined in the orderType enumerations and orderInst is a dictionary look-up value which maps the name of an order type or instruction (e.g., CD order) to its full name and/or detailed description as per the In-Scope Broker’s Reference Data Dictionary. 12

27. Multiple instructions should be separated using '|'9 as a delimiter. E.g. 1) a 'special limit order' could have orderType=LMT and orderInst=special-limit; 2) a 'CD order, stay on bid-side only' could have orderType=MKT and orderInst=CD|stayonbid. The instruction string keys can be freely defined and should map to the In-Scope Broker’s Reference Data Dictionary. A filler value is required when not applicable. 3.1.1.2 Multi-Day Orders
28. Orders received by In-Scope Brokers that remain in force for more than one day such as GTC, GTD, etc. are referred to as ’multi-day’ orders. When presenting multi-day orders, the LOID is required to remain unchanged during their life cycles, regardless of how multi-day orders are implemented in the InScope Broker’s systems (e.g., by automatically recreating a new order every business day or rolling over the same order to the next business day).
29. The treatment of order quantities (orderQty) may differ across systems with respect to multi-day orders. To support systems which do not modify the original orderQty during the order life cycle, the nDayOrderQty field should be used to indicate the outstanding orderQty. 3.1.1.3 Trading Capacity of Agency and Principal Orders
30. The ’Order Capacity’ (orderCapacity) 10 of a new order should indicate the intended trading or executing capacity of the order. E.g., if a client requests the In-Scope Broker to provide a guaranteed price (a guaranteed VWAP order for example), the orderCapacity should be ’Principal’ when it is recorded in the Order New event.
31. If the orderCapacity changes (e.g. from agency to principal) after an order has been received, this should be recorded with an Order Modify event. In this case, individual Order and/or Split events will be denoted as agency or principal as the case may be, and in the Order Summary, the orderCapacity will be mixed (value ’AP’ which is only applicable in an Order Summary event). 3.1.1.4 Basket Orders, Multi-Leg Orders and Strategies
32. For any order which is part of a collection of orders, (e.g. a basket order, or a multi-leg order/strategy) there is an additional field, collectionID, in the Order New event which is used to indicate such a relationship with other orders in the same collection.11
33. The collectionID is composed of two parts using ’=’12 as a separator. The first part is a free text field with an indicative name for the type of a collection when the second part is an identifier for individual collections which must be unique on each trading day. Examples of the collectionID field value are ’basket=BSK123’, ’wave=20181011-123’ and ’tmc=TMC_HSI/123’. In

9 The pipe character is defined as “ASCII decimal 124, hex 7C” 10 This field is not a direct equivalent to the order capacity tag in FIX protocol, In-Scope Brokers might be required to derive the orderCapacity as defined by the DS-OL using multiple internal values in their trading system 11 For multi-leg orders or strategies, only those order legs of In-Scope Products are needed in the DS-OL format. 12 The equal sign is defined as “ASCII decimal 61, hex 3D” 13 case an order is part of multiple collections (i.e. an order may appear in multiple groupings), the In-Scope Broker should use ’|’ as delimiter to concatenate them, e.g., ’basket=BSK123|tmc=TMC_HSI/123’. 3.1.1.5 Aggregated Orders

34. Aggregated orders (i.e., orders created in the In-Scope Broker’s trading system by consolidating similar orders into a single order to be handled collectively) should also be recorded using the Order New event with the list of constituent orders and their respective quantities captured using the aggregatedOrders field.13 Below is an example of how the aggregatedOrders field could be populated:

[SelwynChan]

Here is a set of test scenarios or test cases to comprehensively test the workflow for enriching the dataset with data found in the PWM OMS:

1. Single order with no aggregation

   • Test a simple case where a single order is placed with no aggregation or allocation involved.
   • Validate that the order life cycle events and reference data are correctly populated, including accountID, clientID, and salesID.

2. Single order with single allocation

   • Test a single order that is executed and allocated to a single account.
   • Validate that the AALC event is created with the correct logicalOrderID and allocated quantity.

3. Single order with multiple allocations

   • Test a single order that is executed and allocated to multiple accounts.
   • Validate that the AALC event is created with the correct logicalOrderID and allocated quantities for each account.

4. Aggregated order with no allocations

   • Test an aggregated order with multiple constituent orders but no allocations.
   • Validate that the aggregatedOrders field links to the correct constituent orders with the correct quantities.

5. Aggregated order with allocations

   • Test an aggregated order with multiple constituent orders and allocations.
   • Validate that the AALC event is created with the correct logicalOrderID and allocated quantities for each account.
   • Validate that the aggregatedOrders field links to the correct constituent orders with the correct allocated quantities.

6. Order cancellation

   • Test scenarios where orders are canceled before execution or allocation.
   • Validate that the canceled order life cycle events are correctly captured.

7. Order amendment

   • Test scenarios where orders are amended, such as a change in quantity or price.
   • Validate that the amended order life cycle events and reference data are correctly captured.

8. Partial execution and allocation

   • Test scenarios where orders are partially executed and allocated.
   • Validate that the AALC events are created for the partial allocations with the correct logicalOrderID and allocated quantities.

9. Multiple order types

   • Test scenarios with different order types, such as market orders, limit orders, and stop orders.
   • Validate that the order life cycle events and reference data are correctly captured for each order type.

10. Multiple asset classes

    • Test scenarios with orders for different asset classes, such as equities, options, and ETFs.
    • Validate that the order life cycle events and reference data are correctly captured for each asset class.

11. Error handling

    • Test scenarios with missing or incorrect data in the PWM OMS or the global markets API.
    • Validate that the system can handle errors and generate appropriate error messages or logs.

12. Performance and scalability

    • Test the system's ability to handle a large number of orders, allocations, and events.
    • Validate that the system can process and enrich the dataset efficiently without any performance issues.

[SelwynChan]

Based on the additional information provided, here are more comprehensive test scenarios:

13. Different order types and instructions

    • Test scenarios with various order types and orderInst values separated by '|'.
    • Validate that the system correctly captures and maps the orderType and orderInst values to their full names and detailed descriptions.

14. Multi-day orders

    • Test scenarios with multi-day orders, such as GTC and GTD orders.
    • Validate that the LOID remains unchanged during the order lifecycle and that the nDayOrderQty field is correctly used to indicate the outstanding orderQty.

15. Trading capacity of agency and principal orders

    • Test scenarios with orders having different trading capacities, such as Agency and Principal orders.
    • Validate that the orderCapacity field is correctly captured in Order New and Order Modify events.

16. Order capacity change

    • Test scenarios where the orderCapacity changes during the order lifecycle.
    • Validate that the system correctly records the change with an Order Modify event and updates the orderCapacity in the Order Summary.

17. Basket orders, multi-leg orders, and strategies

    • Test scenarios with orders that are part of a collection, such as basket orders or multi-leg orders/strategies.
    • Validate that the collectionID field is correctly composed and used to indicate the relationship with other orders in the same collection.

18. Multiple collections

    • Test scenarios where an order is part of multiple collections.
    • Validate that the system correctly uses the '|' delimiter to concatenate the collectionIDs.

19. Aggregated orders

    • Test scenarios with aggregated orders created by consolidating similar orders into a single order.
    • Validate that the aggregatedOrders field is correctly populated with the constituent orders and their respective quantities.

20. Aggregated orders with multiple allocations

    • Test scenarios with aggregated orders that have multiple allocations to different accounts.
    • Validate that the AALC events are correctly generated for each allocated quantity and the aggregatedOrders field is accurately updated.

Remember to consider various combinations of these scenarios to ensure comprehensive testing of the overall workflow.