Partner API - Pre-Trade Authorization

Purpose

This document explains the pre-trade authorization check that runs on every order creation across all trading channels (traditional, digital, WAWEX). It describes when a customer's Trading Profile (and, for higher-risk assets, an Appropriateness Test) is required before an order can be placed, and how a failed check surfaces in the Partner API.

The goal is to help Partners understand why an order may be rejected at creation time, and what onboarding state a Natural Person must have before trading a given asset type.

The document describes only Partner API behaviour. Internal policy implementation details are out of scope.

Scope

The check applies to order creation on:

POST /traditional/orders/{market|limit|stop}
POST /digital/orders/market
POST /wawex/orders/market

It does not apply to Corporate Actions (Tender Offer, Choice Dividend, etc.).

Who is evaluated

The check always evaluates the Natural Person identified by the requestor-id header - the actor placing the order.

  • For a Natural Person customer, this is the customer's own NP.
  • For a Legal Entity, this is the linked Natural Person on the requestor-id.
  • For a proxy, this is the proxy's NP (the actor), not the represented customer.

The Trading Profile / Appropriateness state is the acting NP's, never the underlying customer's or legal entity's.

This pre-trade check is additive to the existing requestor/customer validation. The existing validation (e.g. invalid requestor-id, unknown asset, missing product IDs) runs first; the pre-trade authorization check runs after it passes.

What drives the requirement

Two inputs decide whether a Trading Profile is required:

  1. counterpartyLicence - your partner group's licence. One of:
    • BAFIN_LICENSE_BANK
    • BAFIN_LICENSE_ASSET_MANAGER
    • NO_LICENSE
  2. assetRiskScore - the asset's risk score (0–3), returned in the asset/symbol metadata (e.g. GET /traditional/assets returns assetRiskScore).

Authorization matrix

counterpartyLicence Risk score 0 Risk score 1–2 Risk score 3
BAFIN_LICENSE_BANK / BAFIN_LICENSE_ASSET_MANAGER Authorized (no check) Authorized - no Tradevest check (appropriateness is the partner's responsibility) Trading Profile required and (Appropriateness Test passed or risk acknowledged)
NO_LICENSE Authorized (no check) Trading Profile required and (trading experience or risk acknowledged) Trading Profile and Appropriateness Test required (test passed or risk acknowledged)

BAFIN-licensed partners are not gated on a Trading Profile for risk 1–2 assets. This is intended behaviour, not a missing validation - the licensed partner carries the appropriateness responsibility. Only risk 3 assets are gated, and even then the Appropriateness Test can be substituted by a risk acknowledgement.

Risk score 0 assets bypass the check entirely for every licence.

Asset classification per channel

Each channel maps its asset to a canonical trading-profile assetType and a risk score:

Channel Asset Trading-profile assetType Risk score
Traditional Bond / ETF / Equity / Fund / Commodity / Derivative / ETN BOND, ETF, EQUITY, FUND, COMMODITY, DERIVATIVE, ETN From assetRiskScore (1–3) in GET /traditional/assets
Digital Cryptocurrency CRYPTOCURRENCY 0 (bypasses the check)
Digital Security token SECURITY_TOKEN 3
WAWEX Tokenized share TRACKER_CERTIFICATE 3 (always)

Notes:

  • WAWEX tokenized shares are classified as TRACKER_CERTIFICATE with risk score 3 - they are not mapped to SECURITY_TOKEN.
  • Cryptocurrency is currently risk score 0, so crypto orders bypass the Trading Profile check.

How a failed check surfaces

A failed pre-trade check does not let the order proceed to placement. How it is reported differs per channel:

Channel Behaviour on rejection
Traditional Synchronous validation; the order is not placed. The reason is delivered via the TRADITIONAL_ASSET_ORDER_NOTIFICATION webhook (VALIDATION_ERROR).
Digital Asynchronous; the order is persisted with status INVALID. The reason is delivered via webhook (VALIDATION_ERROR, errorType: VALIDATION_FAILED).
WAWEX Synchronous HTTP 400 (errorCode: VALIDATION); the order is not persisted.

Rejection reasons

The reason text identifies which condition failed:

Reason Meaning
trading profile for the asset type is missing No Trading Profile exists for the asset's assetType for the acting NP.
appropriateness test has not been taken for the asset type A risk-3 asset requires an Appropriateness Test that has not been taken.
appropriateness test not passed and no risk acknowledgement provided The Appropriateness Test failed/was not passed and no risk acknowledgement is on file.
trading experience condition not met and no risk acknowledgement provided A risk-1/2 asset under NO_LICENSE where the NP has no recorded experience and no risk acknowledgement.

How to satisfy the check

Trading Profile and Appropriateness Test results are stored globally per Natural Person - the same NP keeps the same result across all partners.

  1. Read existing state first - GET /entities/natural-persons/{naturalPersonId} returns the NP's tradingProfile (including assetTypeProfiles[]) and appropriateness state. If a profile already exists, reuse it; do not restart the flow.
  2. Create a Trading Profile / run the Appropriateness Test only if the matrix requires it for your licence + the asset's risk score, and the NP does not already have one.
  3. Risk acknowledgement (where permitted by the matrix) - POST /entities/natural-persons/{naturalPersonId}/trading-profile/asset-types/{assetType}/acknowledge. This satisfies the check when experience/test conditions are not met.

Verification checklist

When testing the pre-trade behaviour, verify:

Check What to verify
Authorized order Order is created and proceeds normally (no VALIDATION_ERROR / no INVALID from pre-trade).
Rejected order - traditional No placement; VALIDATION_ERROR webhook with the expected reason.
Rejected order - digital Order persisted as INVALID; VALIDATION_ERROR webhook (errorType: VALIDATION_FAILED).
Rejected order - WAWEX HTTP 400 (errorCode: VALIDATION) with the expected reason; order not persisted.
Correct NP evaluated The Trading Profile of the requestor-id NP drives the result, not the customer/LE.
Risk-0 bypass Crypto / risk-0 assets place without a Trading Profile.
BAFIN risk-1/2 bypass For a BAFIN-licensed partner, low/mid-risk traditional orders place without a Trading Profile.

Notes and limitations

  • The existing requestor/customer validation runs before the pre-trade check; failures there surface with their own (non-pre-trade) reasons.
  • Trading Profile / Appropriateness results are global per NP - always fetch current state via GET /entities/natural-persons/{naturalPersonId} before starting any profile flow.
  • The check is being rolled out across channels; behaviour may not be enabled in every environment at the same time.
  • Corporate Actions are not gated by this check.