Partner API - Test Environment Order Execution Scenarios

Purpose

This document explains how to trigger selected traditional asset order execution scenarios in the test environment by using specific values in the quantity field when creating an order through the Partner API.

The goal is to help Partners verify how their integration handles order lifecycle statuses returned by the Partner API, especially full execution, partial execution, cancellation, expiration, rejection, invalid orders and pending/no-reply behaviour.

The document intentionally describes only Partner API behaviour. It does not describe internal execution venue, broker or custodian integration details.

Scope

This guide covers scenarios that are visible and relevant from the Partner API perspective.

Some internal execution simulation scenarios may exist in the test environment but are not included here if they are intended only for internal testing or if their result is not exposed as a Partner API order status.

How to trigger a scenario

The scenario is selected by the numeric value sent in the quantity field of the create-order request.

Use the relevant create-order endpoint depending on the order type:

POST /traditional/orders/market
POST /traditional/orders/limit
POST /traditional/orders/stop

For quantity-based execution tests, use:

"quantityType": "UNIT"

The quantity value must be a whole number.

Example create-order request

Example Limit order request:

POST /traditional/orders/limit
Requestor-ID: <uuid>
Content-Type: application/json
{
  "depositoryCustomerProductId": "<depositoryCustomerProductId>",
  "cashCustomerProductId": "<cashCustomerProductId>",
  "tradeSide": "BUY",
  "quantityType": "UNIT",
  "exchangeCode": "TGAT",
  "isin": "IE00B4L5Y983",
  "quantity": 10,
  "limitPrice": 100.00,
  "expiryDate": "2026-12-31",
  "externalId": "partner-test-quantity-10"
}

In this example, quantity = 10 triggers a full execution scenario.

Partner API order statuses

The following statuses are relevant for Partner API order lifecycle testing:

Status Meaning
RECEIVED Initial technical status after the order request is received by the platform. In most standard flows, it moves to PENDING.
PENDING The order is being processed or is waiting for confirmation. In some flows, the order may move from PENDING directly to REJECTED.
PLACED The order was accepted for execution and is active/open. Most execution scenarios described below start from this status.
INVALID The order did not pass internal platform validation and was not sent for execution.
REJECTED The order was rejected after processing started. In this case, PLACED may not appear in the Partner API status flow.
FILLED The order was fully executed.
PARTIALLY_FILLED The order was partially executed and remains open unless followed by another terminal status.
CANCELLED The order was cancelled without any execution.
PARTIALLY_FILLED_CANCELLED The order was partially executed and then cancelled.
EXPIRED The order expired without execution.
PARTIALLY_FILLED_EXPIRED The order was partially executed and then expired.

The following statuses should not be used for Partner-facing test expectations: UPDATED, CANCELLATION_ACCEPTED, CANCELLATION_REJECTED, RECONCILIATION_CORRECTION.

General status flow rules

For most execution scenarios, the relevant Partner API flow starts from PLACED:

PLACED → final or intermediate execution status

However, not every order reaches PLACED. The following flows are also possible:

RECEIVED → INVALID
PENDING → REJECTED

A rejected cancellation request does not create a visible Partner API status change. If a cancel request is rejected by the execution venue or broker, the order remains in its previous visible Partner API status.

Invalid order scenario

The INVALID status means that the order was not sent for execution because it did not pass internal platform validation.

This scenario is not triggered by a specific quantity value. It can be triggered by submitting an order that fails validation.

Partner API status flow How to trigger
RECEIVED → INVALID Buy order with insufficient funds on the customer’s Balance Account.
RECEIVED → INVALID Sell order with insufficient quantity of the given asset on the customer’s Depository Account.
RECEIVED → INVALID depositoryCustomerProductId and/or cashCustomerProductId do not belong to the customer.

Quantity-based execution scenarios

Additional low-quantity scenarios

These scenarios are also available in the test environment.

Quantity Expected behaviour Expected Partner API status flow Final status
1 Full execution in one execution. PLACED → FILLED FILLED
2-8 Full execution in multiple executions. PLACED → PARTIALLY_FILLED → FILLED FILLED
9 Same behaviour as quantity 1; full execution in one execution. PLACED → FILLED FILLED

Full execution scenarios

Quantity Expected behaviour Expected Partner API status flow Final status
10, 100, 1000 Full execution in one execution. PLACED → FILLED FILLED
20, 200, 2000 Multiple partial executions followed by full execution. Usually 6-7 execution events in total. PLACED → PARTIALLY_FILLED → FILLED FILLED
21, 210, 2100 Multiple partial executions followed by full execution. Usually 2-60 execution events. PLACED → PARTIALLY_FILLED → FILLED FILLED
22, 212, 2200 High-volume partial execution scenario followed by full execution. Usually 1000-2000 execution events. PLACED → PARTIALLY_FILLED → FILLED FILLED
9* Parameterized execution count. Digits after 9 define the number of executions. Example: 91 = 1 execution, 9120 = 120 executions. PLACED → PARTIALLY_FILLED → FILLED FILLED

Note: scenario 22 may generate a very high number of execution events and should be used only when the Partner explicitly wants to test high-volume execution handling.

Partial execution scenarios

Quantity Expected behaviour Expected Partner API status flow Final status
30, 300, 3000 One partial execution. The order remains open. PLACED → PARTIALLY_FILLED PARTIALLY_FILLED
35, 350, 3500 Several partial executions. The order remains open. Usually 6-7 execution events. PLACED → PARTIALLY_FILLED PARTIALLY_FILLED
36, 360, 3600 Several partial executions. The order remains open. Usually 2-60 execution events. PLACED → PARTIALLY_FILLED PARTIALLY_FILLED
37, 370, 3700 Several partial executions. The order remains open. Usually 6-7 execution events. PLACED → PARTIALLY_FILLED PARTIALLY_FILLED

Cancellation scenarios

Quantity Expected behaviour Expected Partner API status flow Final status
40, 400, 4000 Order is accepted and then cancelled without execution. PLACED → CANCELLED CANCELLED
50, 500, 5000 Order is accepted and then cancelled with a cancellation reason. PLACED → CANCELLED CANCELLED
32, 320, 3200 One partial execution followed by cancellation. PLACED → PARTIALLY_FILLED → PARTIALLY_FILLED_CANCELLED PARTIALLY_FILLED_CANCELLED

For Partner API purposes, there is no visible intermediate CANCELLATION_ACCEPTED status. If the final result is a successful cancellation, the order should end in CANCELLED or PARTIALLY_FILLED_CANCELLED.

If a cancellation request is rejected, the order status does not change in the Partner API.

Expiration scenarios

Quantity Expected behaviour Expected Partner API status flow Final status
13, 130, 1300 Order is accepted and then expires without execution. PLACED → EXPIRED EXPIRED
33, 330, 3300 One partial execution followed by expiration. PLACED → PARTIALLY_FILLED → PARTIALLY_FILLED_EXPIRED PARTIALLY_FILLED_EXPIRED

Pending / no-reply scenarios

Quantity Expected behaviour Expected Partner API status flow Final status
52, 520, 5200 No execution response is received. The order stays pending/open. PENDING or PLACED PENDING or PLACED
53, 530, 5300 No execution response is received. The order stays pending/open, but cancellation can still lead to final cancellation. PENDING or PLACED; after successful cancel: CANCELLED PENDING, PLACED or CANCELLED after cancel

GTD multi-day scenarios

These scenarios are intended for Good-Till-Date style tests where the order can remain active across multiple days until the expiry date.

Quantity Expected behaviour Expected Partner API status flow Final status
80, 800, 8000 Partial execution each day until the order expires. If cancelled before expiry, cancellation is reflected in the final status. PLACED → PARTIALLY_FILLED → PARTIALLY_FILLED_EXPIRED; or after successful cancel: PARTIALLY_FILLED_CANCELLED PARTIALLY_FILLED_EXPIRED or PARTIALLY_FILLED_CANCELLED
81, 810, 8100 Partial execution each day until expiry. Cancellation request rejection is not exposed as a separate Partner API status. PLACED → PARTIALLY_FILLED → PARTIALLY_FILLED_EXPIRED PARTIALLY_FILLED_EXPIRED
82, 820, 8200 Partial execution each day until expiry. Cancel/update requests may remain pending internally. PLACED → PARTIALLY_FILLED → PARTIALLY_FILLED_EXPIRED PARTIALLY_FILLED_EXPIRED
83, 830, 8300 Partial execution each day until expiry. Successful cancellation ends the order as partially filled and cancelled. PLACED → PARTIALLY_FILLED; after successful cancel: PARTIALLY_FILLED_CANCELLED; otherwise: PARTIALLY_FILLED_EXPIRED PARTIALLY_FILLED_CANCELLED or PARTIALLY_FILLED_EXPIRED
84, 840, 8400 Partial execution each day until expiry. Cancellation may remain pending internally. PLACED → PARTIALLY_FILLED → PARTIALLY_FILLED_EXPIRED PARTIALLY_FILLED_EXPIRED

For most Partner integration tests, the following reduced set should be sufficient:

Test purpose Suggested quantity / setup Expected Partner API status flow Expected final status
Invalid order - failed internal validation Invalid setup, not quantity-based RECEIVED → INVALID INVALID
Rejected order after processing starts Test setup that causes rejection after initial processing PENDING → REJECTED REJECTED
Full execution in one execution 1 or 10 PLACED → FILLED FILLED
Full execution in multiple executions 2-8 or 20 PLACED → PARTIALLY_FILLED → FILLED FILLED
Single partial execution, order remains open 30 PLACED → PARTIALLY_FILLED PARTIALLY_FILLED
Partial execution followed by cancellation 32 PLACED → PARTIALLY_FILLED → PARTIALLY_FILLED_CANCELLED PARTIALLY_FILLED_CANCELLED
Partial execution followed by expiration 33 PLACED → PARTIALLY_FILLED → PARTIALLY_FILLED_EXPIRED PARTIALLY_FILLED_EXPIRED
Cancellation without execution 40 PLACED → CANCELLED CANCELLED
Expiration without execution 13 PLACED → EXPIRED EXPIRED
No-reply / pending behaviour 52 PENDING or PLACED PENDING or PLACED
GTD partial execution until expiry 80 PLACED → PARTIALLY_FILLED → PARTIALLY_FILLED_EXPIRED PARTIALLY_FILLED_EXPIRED

Verification checklist

For each scenario, the Partner should verify at least the following fields in the order response or order status update:

Field What to verify
orderId The order can be identified and retrieved after creation.
externalId The Partner's own order identifier is preserved.
status The expected Partner API status is returned.
quantity The submitted quantity matches the selected test scenario.
execution.executionQuantity For fully executed orders, the executed quantity is consistent with the scenario.
execution.remainingQuantity For partially executed orders, the remaining quantity is consistent with the scenario.
partialExecutions[] For partial-fill scenarios, each fill appears as an entry with its own executionQuantity and executionPrice.
message / reason fields For rejected, invalid or cancelled scenarios, check whether a business message or reason is provided.

Field names above follow the Order / PartialExecution schemas in the Traditional Assets reference.

Notes and limitations

  • Exact timing can differ between scenarios. Some statuses may be visible only briefly as intermediate statuses.
  • The create-order response does not necessarily mean that the order has already reached its final status.
  • Some scenarios are asynchronous. The Partner may need to poll the order endpoint or wait for order status webhook updates, depending on the integration setup.
  • For partial-fill scenarios with many executions, the Partner should not rely on receiving only one execution update.
  • For cancellation flows, Partner API exposes the final cancellation status, not internal cancellation acknowledgement or rejection statuses.
  • Internal execution venue or broker integration scenarios that do not produce Partner-facing statuses are intentionally excluded from the recommended Partner test set.