v.2.11.0 - Test Environment

2026-09-01 - Planned deployment to Live

2026-08-18 - Test Environment

Added

Position Sells for Fractional Holdings

Fractional positions can only arise from savings plans, and the exchange accepts whole-share orders only, so a sub-one-share remainder could not be sold with an ordinary order. Two position-level sell endpoints now bring any holding to zero, replacing the plan-scoped savings-plan sell with actions that belong to trading rather than to a single savings plan.

• Documentation Location: API REFERENCE - Trading - Traditional Assets
• New Endpoint: POST /traditional/orders/sell-all - sells the customer's entire position in one ISIN within one depository product, whole shares and the fractional remainder together, as a single sell order; ends with a zero position on that ISIN
• New Endpoint: POST /traditional/orders/fractional-sell - sells only the sub-one-share remainder, always in full; whole shares are never touched, so a position of 3.4 becomes 3
• Payload includes: depositoryCustomerProductId (depository product holding the position), cashCustomerProductId (cash product the proceeds are credited to), isin
• Note: both are accepted asynchronously with 202 Accepted and an order id. The order is readable on the /v2 read endpoints immediately with status RECEIVED and quantity 0 - the quantity is resolved from the custody position when the order is routed. Rejections surface as an order with status REJECTED, or INVALID for validation failures, together with a message.
• Note: sell-all deactivates every ACTIVE savings plan on that customer, depository product and ISIN, so buying does not resume after the position is closed.
• Note: sell-all is rejected when part of the position is already blocked by another open order - cancel that order first, otherwise a zero position cannot be guaranteed. fractional-sell is rejected when the position has no fractional remainder, and works whether or not an active savings plan exists.
• Note: the resulting order cannot be cancelled - DELETE /traditional/orders/{orderId} responds with 409. Amendment remains unavailable for all traditional orders (PATCH responds with 501). Both endpoints go through the same pre-trade authorization check as other sells.

Versioned Order Reads Covering Position Sells

Position sells can settle a fractional quantity, which the existing order contract guarantees to be a whole number. Rather than change that guarantee, the traditional-order read family gains a /v2 alongside the existing endpoints, and only the /v2 reads carry position sells.

• Documentation Location: API REFERENCE - Trading - Traditional Assets
• New Endpoint: GET /v2/traditional/orders/{orderId} - identical to GET /traditional/orders/{orderId} except that quantity may be fractional
• New Endpoint: GET /v2/products/{customerProductId}/traditional/orders - identical to GET /products/{customerProductId}/traditional/orders except that quantity may be fractional and no order is excluded, so a page always contains limit items while more items remain
• Payload includes: OrderV2 / OrdersV2, matching Order / Orders field for field; the quantity in OrderDataV2 carries no whole-share constraint
• Note: the unversioned endpoints are unchanged for every order type that existed before this release. Partners who never use sell-all or fractional-sell need not migrate. Partners who do should read those orders through /v2, and can read their whole-share orders there too - the two families otherwise return the same data.

Traditional Asset Order Notification V2

Position-sell orders are not delivered on the existing traditional-order webhook, for the same fractional-quantity reason. A second event carries the full order lifecycle including position sells.

• Documentation Location: API REFERENCE - Webhooks
• New Webhook: POST /v2/traditional-asset-order-notification - delivered on the new event type; same payload shape as the existing notification
• New enum value: EventTypeEnum - TRADITIONAL_ASSET_ORDER_NOTIFICATION_V2
• Payload includes: orderId, customerProductId, externalId, exAnteId, executionId, status, notificationType, validationError, executionData - unchanged from TraditionalAssetOrderNotification, except that executionData.quantity may carry a fractional remainder
• Note: replace the v1 subscription rather than holding both. A partner subscribed to TRADITIONAL_ASSET_ORDER_NOTIFICATION and TRADITIONAL_ASSET_ORDER_NOTIFICATION_V2 at the same time receives every whole-share order twice.

Asset Search by Name and Total Count

The asset list is what partners use to present the tradeable universe. It can now be searched by asset name and reports how many assets match, so a partner can build a search box and a result count without paging the whole universe.

• Documentation Location: API REFERENCE - Trading - Traditional Assets
• Endpoint: GET /traditional/assets
• New query parameter: assetName (string, max 100 characters) - narrows the list to assets whose name contains the given value; the match is case-insensitive and matches any part of the name, and it combines with the existing filters
• Added field: total (integer) - the number of assets matching the applied filters across all pages, independent of limit and cursor, so it is the same on every page of a paged result
• Note: omitting assetName leaves the endpoint behaving exactly as before. A search that matches nothing returns an empty list and a total of 0, not an error. Assets the endpoint already hides from partners are neither returned nor counted.

Changed

Traditional Order Reads Exclude Position Sells

The unversioned order reads keep their whole-share quantity guarantee, so the new position-sell orders are not visible through them.

• Documentation Location: API REFERENCE - Trading - Traditional Assets
• Endpoint: GET /traditional/orders/{orderId} - responds with 404 for an order created through /traditional/orders/sell-all or /traditional/orders/fractional-sell
• Endpoint: GET /products/{customerProductId}/traditional/orders - position sells are excluded from the list
• Behavior change: because the exclusion is applied after the page is read, a page of the unversioned list may contain fewer items than limit while more items remain. Keep following cursor until it is absent rather than treating a short page as the end of the result set.
• Note: no order type that existed before this release changes its behaviour on these endpoints. To see position sells, read GET /v2/traditional/orders/{orderId} and GET /v2/products/{customerProductId}/traditional/orders.

Savings Plan Executions Are Buy-Only

With the exit moved out of savings plans, a savings plan models recurring purchases only. Disposal of the accumulated position is an ordinary trading action.

• Documentation Location: API REFERENCE - Trading - Savings Plans
• Endpoint: GET /savings-plans/{savingsPlanId}/executions - lists the periodic BUY executions; a sell is no longer a savings-plan execution and is read through GET /v2/products/{customerProductId}/traditional/orders
• Behavior change: DELETE /savings-plans/{savingsPlanId} stops future purchases and does not liquidate the accumulated position - it never did, and the documentation now says so explicitly. Use POST /traditional/orders/sell-all or POST /traditional/orders/fractional-sell to dispose of the position.
• Note: SavingsPlansExecution is unchanged structurally. Its tradeSide no longer distinguishes a BUY execution from a SELL exit, because only BUY executions are returned.

Removed

Savings Plan Sell

The plan-scoped sell introduced in v.2.7.0 could only dispose of the amount one plan had accumulated, tied the sale to a single plan, and decoupled the tax treatment of a mixed position from oldest-first cost basis. It is replaced by the two position-level sell endpoints, which can close any position containing a fraction.

• Removed: POST /savings-plans/{savingsPlanId}/sell
• Replacement: POST /traditional/orders/sell-all (whole shares plus the fractional remainder) and POST /traditional/orders/fractional-sell (the remainder only)
• Change: the request schema SavingsPlanSellData and the response schema SavingsPlanSellResult are removed with it. The replacement endpoints take depositoryCustomerProductId where the removed endpoint took savingsCustomerProductId, cashCustomerProductId where it took liquidityCustomerProductId, and additionally require isin because the sale is scoped to a position rather than to a plan.
• Note: the outcome is no longer delivered as a savings-plan notification. A position sell reports its outcome as an order - through the /v2 order reads and the TRADITIONAL_ASSET_ORDER_NOTIFICATION_V2 event - and a successful sale no longer transitions the plan to DELETED; sell-all deactivates the plan instead.