Ctrlk
tradevest.ai

v.2.4.1 – Live Environment

2026-05-28 - 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

  • 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

  • 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

  • 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 → Webhooks

  • 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

  • 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

  • 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

  • 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.

Last updated