2.16.0 Test Environment Current

v.2.16.0 - Test Environment

2026-11-10 - Planned deployment to Live 2026-10-27 - Test Environment

2026-11-10 - Planned deployment to Live

2026-10-27 - Test Environment

Added

Tokenized Asset Price Stream - BART NAV in USDC (TVDY)

The tokenized asset price stream now carries the net asset value of BART in USDC as a separate, price-only market, so partners can show the NAV in the token's own currency next to the EUR price.

  • Documentation Location: API REFERENCE - WebSocket Tokenized Prices
  • Endpoint: /websocket/prices on the tokenized asset price stream.
  • New market: TVDY with currency USDC. Its bid and ask both equal the BART NAV per unit in USDC and update with every new NAV.
  • New enum value: USDC on the currency of a price-stream market (CurrencyEnum in the tokenized price stream). Every other market stays quoted in EUR.
  • Behavior change: each symbol is accepted in one currency only. TVDY must be requested in USDC, and every other symbol, BART included, in EUR. Any other combination is rejected with an ERROR response (unexpected currency "<CURRENCY>") and the connection is closed.
  • Note: TVDY is a price-only market. It cannot be traded and has no REST price. BART stays the tradable symbol, as announced in v.2.13.0, and BART in EUR is unchanged. TVDY is not included in a subscription to all markets - request it explicitly.

Entities - Employment Income as Origin of Assets

Natural persons can now declare income from dependent employment (salary or wages) as the origin of their assets. Until now the list had no value for it.

  • Documentation Location: API REFERENCE - Entities
  • Endpoint: POST /entities/natural-persons and the natural person update. The same value appears wherever a natural person's asset disclosures are returned, including joint persons and the natural person webhooks.
  • New enum value: EMPLOYED_LABOR on originOfAssets (NaturalPersonAssetOriginEnum) - income from dependent employment (salary/wages).
  • Note: existing values are unchanged. If you validate originOfAssets against a fixed list, add EMPLOYED_LABOR so that responses and webhooks containing it are not rejected by your integration.

Changed

Transaction History - Trade Dates, Value Date Filter and Paging

The transaction history now reports trades with the trade date as booking date and the settlement date as value date, adds a value date filter, and always fills a page up to limit.

  • Documentation Location: API REFERENCE - Transaction History
  • Endpoint: GET /customers/{customerId}/transactions
  • Changed: bookingDate and valueDate on trade transactions (traditional, digital, tokenized and savings-plan executions). bookingDate is now the trade (execution) date of the latest execution. valueDate is now the settlement date, typically two business days after the trade date (T+2) for securities and digital assets. Tokenized SELL trades settle T+3 and tokenized BUY trades on the trade date. Both are UTC calendar dates. Until now the two dates were reported the other way round for trades. The same applies to the dates of each execution in the traditional and digital trading transaction.
  • New query parameters: startValueDate and endValueDate (date, inclusive) filter by value date, the same way startBookingDate and endBookingDate filter by booking date.
  • Behavior change: booking date filters and value date filters cannot be combined in one request (400 Bad Request). Within a pair, a start date after the end date is rejected with 400 Bad Request. A reversed booking date range used to return 200 with an empty list.
  • Behavior change: filters are applied before limit. A page now contains limit transactions whenever that many matching transactions exist. Before, a page could contain fewer matches even though more existed.
  • Behavior change: the customerProductId filter now matches transactions booked on that product: the cash or technical cash account, the wallet or depository account of a trade, or the depository account of a corporate action. Savings-plan transactions are not matched by this filter.
  • Note: results stay sorted by createdOn descending (most recently created first). A cursor is only valid together with the filters of the request that returned it. Cash, technical cash and corporate action transactions keep their dates. The execution dates on the order endpoints are unchanged. Trade transactions recorded before this release are converted to the new date meaning as part of the rollout.

Entities - Natural Persons Awaiting Review

A natural person that goes to status REVIEW when it is created can no longer be used until Tradevest has decided on it. Requests that reference it now fail at once with an error instead of being accepted and failing later.

  • Documentation Location: API REFERENCE - Entities; API REFERENCE - Roles; API REFERENCE - Documents; API REFERENCE - Taxes
  • Endpoint: POST /entities/natural-persons - when the person matches or resembles a person that already exists on the platform, it goes to status REVIEW and is created only after Tradevest's internal review decision. The partner cannot clear the REVIEW status.
  • Behavior change: until the decision, every other request that references the natural person is rejected with 400 Bad Request (errorCode VALIDATION, error detail code VALIDATION_ENTITY_PENDING_REVIEW). This covers updating the person, identification and identification verification, the trading profile (asset types, acknowledgement, investment objectives), appropriateness test responses, document upload and signing, joint person, customer and proxy creation, and tax exemption order create and update. Before, these requests were accepted and then failed through a webhook that reported the person as not found.
  • Behavior change: GET /entities/natural-persons/{naturalPersonId} still returns the person, with status REVIEW.
  • Added: the 400 Bad Request response is now documented on POST /taxes/tax-exemption-orders.
  • Note: wait for the natural person status webhook before retrying. A person that enters REVIEW through a later update is not affected by this rule. The Natural Person Create Process guide now explains when a new person goes to REVIEW.

Entities - Trading Experience Must Be Greater Than Zero

The trading experience on an asset-type trading profile must now be greater than zero, so 0 no longer stands in for "no experience".

  • Documentation Location: API REFERENCE - Entities
  • Endpoints: POST /entities/natural-persons/{naturalPersonId}/trading-profile/asset-types/{assetType} and PATCH /entities/natural-persons/{naturalPersonId}/trading-profile/asset-types/{assetType}
  • Changed: yearsOfExperience, numberOfTrades and tradeVolume in tradingExperience must be greater than 0 (exclusiveMinimum). A value of 0 is rejected with 400 Bad Request (VALIDATION_LESS_THAN_EXCLUSIVE).
  • Behavior change: tradeVolume: 0 used to be accepted and is now rejected. 0 for yearsOfExperience and numberOfTrades was already rejected and now returns this error code.
  • Note: for a customer without trading experience, send hasExperience: false and omit tradingExperience. When hasExperience is true, tradingExperience is required. A customer with less than one year of experience reports yearsOfExperience: 1.

Tokenized Assets - Empty Order List

Listing the tokenized orders of a wallet that has no orders now returns an empty list instead of 404 Not Found.

  • Documentation Location: API REFERENCE - Trading - Tokenized Assets
  • Endpoint: GET /wawex/products/{customerProductId}/orders
  • Behavior change: a wallet with no matching orders returns 200 OK with an empty data array and an empty pagination.cursor, the same response shape as a non-empty list. 404 Not Found is returned only when the customer product does not exist or is not owned by the caller.
  • Note: if your integration treated 404 as "no orders", handle the empty data array the same way. Keep the 404 handling for unknown products.

Savings Plans - Ex-Ante Cost Calculation

The savings plan ex-ante now calculates its costs per execution and over the assumed 5-year holding period, so the figures match the cost disclosure the customer receives. The request and response structure is unchanged; only the values differ.

  • Documentation Location: API REFERENCE - Trading - Traditional Assets
  • Endpoint: POST /traditional/ex-ante/savings-plans
  • Changed: purchaseCosts - the costs of a single execution of the savings amount: the Tradevest transaction fee plus the fund's entry charge. percent is relative to the savings amount. Before, this was the transaction fee for twelve executions relative to the annual amount, without the entry charge. For a fund without an entry charge the amount is now one twelfth of what it was.
  • Changed: saleCosts - the costs of selling one savings amount: the Tradevest transaction fee plus the fund's exit charge, relative to the savings amount. Before, the exit charge was not included and the percentage was relative to the annual amount.
  • Changed: timeline.year1 to timeline.year5 - the ongoing product costs of each year, calculated on the average holding value of that year as the plan builds up. percent is relative to the capital paid in by the end of that year. Before, years 1 to 4 showed the same full-year figure, and year 5 also included the sale.
  • Changed: timeline.yearOfSale - the costs of selling the full holding at the end of the 5-year period (transaction fee plus exit charge on the total paid-in amount), relative to that amount.
  • Changed: total.transactionFees and total.productCosts now cover the full 5-year period, relative to the total paid-in amount. total.transactionFees holds the Tradevest fees of all executions plus the final sale. total.productCosts holds the ongoing product costs of all five years plus the fund's entry charges and the final exit charge.
  • Note: productCosts (the annual ongoing product costs) and total.grants are unchanged. The ex-ante document returned by GET /traditional/ex-ante/{exAnteId} has a new layout with the same figures: costs per execution, ongoing costs per year, sale costs, total costs per year, and the split into service, product and third-party costs. No integration change is required, but if you display these figures, expect different values for the same input.

Digital Assets - Savings Plan Eligibility of BTC and ETH

Savings plans are offered for traditional assets only. BTC and ETH were wrongly flagged as eligible for savings plans and now report false.

  • Documentation Location: API REFERENCE - Trading - Digital Assets
  • Endpoint: GET /digital/assets
  • Changed: savingsPlansEligible is false for BTC and ETH. Filtering with savingsPlansEligible=true no longer returns them.
  • Behavior change: a new savings plan with instrumentType: DIGITAL_ASSET on BTC or ETH is rejected as asset is not eligible for savings plans.