# v.2.4.1 – Test Environment ## v.2.4.1 – Test Environment **2026-05-26 - Planned deployment to Live** **2026-05-12 - Test Environment** *** **Added** **Customer Products: Tokenized Stock Holdings** The Customer Products API now exposes customer positions for tokenized stocks (tracker certificates) alongside the existing `cryptoAssets` and `traditionalAssets` arrays, so partners can render full portfolio views and statements that include tokenized holdings. * **Documentation Location:** API REFERENCE → [Products](/documentation/products.md) * **Endpoints:** `GET /customers/{customerId}/products`, `GET /products/{customerProductId}` * **Added field on `CustomerProduct`:** `tokenizedAssets` (array of `TokenizedAsset`, optional) — list of tokenized stock positions held in the wallet product * **New schema `TokenizedAsset`:** `underlying` (ISIN of the underlying security), `tokenSymbol`, `name`, `quantity`, `availableQuantity`, `avgBuyPrice`, `currentPrice` (optional), `currency` (`EUR`), `modifiedOn` * **Note:** Tokenized holdings are returned under the existing `WALLET` product type — no new `productType` value is introduced. Positions update on order execution (`FILLED`); average buy price uses FIFO with 8 decimal places on quantities. *** **Onboarding Webhooks: Tax Information Validation Error** A new validation error type is now reported on onboarding webhooks when rejects a customer's tax-relevant data (e.g. an invalid postal code). Previously these failures were not surfaced to partners - affected customers stalled in `PENDING` and the `customer.rejected` webhook was never sent. * **Documentation Location:** API REFERENCE → [Webhooks](/api-reference/webhooks.md) * **Affected Schema:** `OnboardingValidationErrorEnum` * **New enum value:** `TAX_INFORMATION_VERIFICATION` — emitted on the `customer.rejected` webhook payload when a tax engine validation step fails during onboarding * **Note:** Partners using strict enum validation on the onboarding rejection webhook should add `TAX_INFORMATION_VERIFICATION` to their accepted error set before deployment. *** **Tokenized Asset Orders: New `PARTIALLY_FILLED` Order Status** The WAWEX (tokenized asset) order status enum now mirrors the Traditional Trading lifecycle — partners may receive a `PARTIALLY_FILLED` status for tokenized orders that have been executed for part of the requested quantity while the remainder is still working. * **Documentation Location:** API REFERENCE → Trading → [Tokenized Assets](/api-reference/asset-management/wawex-tokenized-assets/tokenized-assets.md) * **Affected Schema:** `OrderStatus` on `GET /wawex/orders/{orderId}` and related WAWEX order responses * **New enum value:** `PARTIALLY_FILLED` — order has been partially executed; the remaining quantity is still being worked * **Note:** Partners using strict enum validation on WAWEX order responses must add `PARTIALLY_FILLED` to their accepted `OrderStatus` values before deployment. This value already exists for traditional trading orders and now aligns across both flows. *** **Changed** **Corporate Actions: Reference Number Linking MT564 and MT566 Events** A new `corporateActionReference` field links the announcement (MT564) and settlement (MT566) events for the same underlying corporate action, so partners can correlate webhook payloads and query results that previously appeared as unrelated events. * **Documentation Location:** API REFERENCE → Trading → [Corporate Actions](/api-reference/asset-management/corporate-actions.md) / API REFERENCE → [Webhooks](/api-reference/webhooks.md) * **Endpoints:** `GET /corporate-actions`, `GET /corporate-actions/customers/{customerId}` and the corporate action partner webhook payload * **Response Changes:** * **Added:** `corporateActionReference` (string, optional) — reference number that is identical on both the MT564 (ANNOUNCED) and MT566 (SETTLED) events for the same corporate action * **Query Parameter Changes:** * **Added:** `corporateActionReference` (string, optional) — filter results to only the events that share a given reference number * **Note:** The existing `eventId` differs between announcement and settlement events; `corporateActionReference` is the value to use when grouping related events on the partner side. *** **Savings Plans: Operation Sync / Async Model Alignment** The HTTP response codes for the savings-plans command endpoints have been realigned to match the actual sync vs. async behavior of each operation. * **Documentation Location:** API REFERENCE → Trading → [Savings Plans](/api-reference/asset-management/savings-plans.md) * **Endpoint Changes:** * `POST /savings-plans` — now responds with `200 OK` (was `202 Accepted`) — plan creation is synchronous; the created `SavingsPlan` is returned in the response body * `PATCH /savings-plans/{savingPlanId}` — now responds with `202 Accepted` (was `200 OK`) — update is asynchronous * `DELETE /savings-plans/{savingPlanId}` — now responds with `202 Accepted` (was `200 OK`) — deletion is asynchronous * **Note:** Partners that began integrating against the v.2.4.0 Pretest spec must adjust their expected status codes accordingly. The 2xx range is preserved on every operation, so partners checking only `response.ok` / status class will not break. *** **Savings Plans: `savingsAmount` Type Refinement** The `savingsAmount` field in savings-plan request and response payloads is now typed as a JSON number with a 0.01 multiple constraint, replacing the previous decimal-string representation. * **Documentation Location:** API REFERENCE → Trading → [Savings Plans](/api-reference/asset-management/savings-plans.md) * **Affected Schemas:** `SavingsPlan`, `SavingsPlanCreate`, `SavingsPlanUpdate`, `SavingsPlans` (list response) * **Field Changes:** * `savingsAmount` — type changed from `string` (e.g. `"50.00"`) to `number` (e.g. `50.00`) with `multipleOf: 0.01` * `intervalDay` example representation aligned across schemas * **Response Schema:** * `SavingsPlans` (list) now declares `data` as a required field * **Note:** Partners must accept `savingsAmount` as a JSON number rather than a quoted decimal string in both request bodies and response payloads. *** **Traditional Assets: Ex-Ante Savings-Plan Timeline Schema** The `timeline` block returned by `POST /traditional/ex-ante/savings-plans` now uses a dedicated `SavingsPlanTimelineCost` schema with explicit per-year buckets, replacing the generic `TimelineCost` reference originally referenced in v.2.4.0. * **Documentation Location:** API REFERENCE → Trading → [Traditional Assets](/api-reference/asset-management/trading.md) * **Endpoint:** `POST /traditional/ex-ante/savings-plans` * **Response Changes (`ExAnteSavingsPlansCostResult.timeline`):** * Schema changed from `TimelineCost` to `SavingsPlanTimelineCost` * Required buckets: `year1`, `year2`, `year3`, `year4`, `year5`, `yearOfSale` — each holds a `TransactionFees` object * **Note:** Partners integrating against the v.2.4.0 Pretest ex-ante endpoint must regenerate client code or update their model to expect the new `SavingsPlanTimelineCost` shape on the `timeline` field. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.tradevest.ai/release-notes/v.2.4.1-test-environment.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.