Appropriateness Test

Before a natural person may trade certain asset types, they must complete an appropriateness test. The test establishes that the customer understands the risks of the instrument class, and it is a regulatory precondition - not an optional questionnaire.

The flow is: fetch the current test for an asset type, present the questions to the customer, submit their answers, then read back the outcome.

Asset types that require a test

Asset type	Value
Security token	`SECURITY_TOKEN`
Tracker certificate	`TRACKER_CERTIFICATE`

A test is taken per asset type. Passing the test for one asset type says nothing about the other.

1. Fetch the current test

GET /appropriateness-test/asset-types/{appropriatenessTestAssetType}

Returns the latest version of the test for that asset type. The response carries an appropriatenessTestId, a version, and the list of questions:

{
  "appropriatenessTestId": "c855e259-15d8-4385-a60f-bdf8f7695ef7",
  "version": 3,
  "assetType": "SECURITY_TOKEN",
  "questions": [
    {
      "questionCode": "Q1",
      "category": "KNOWLEDGE",
      "questionText": "How would you describe your experience with security tokens?",
      "answers": [
        { "answerCode": "A", "answerText": "No experience" },
        { "answerCode": "B", "answerText": "Some experience" }
      ]
    }
  ],
  "createdOn": "2026-01-15T10:30:00Z"
}

Pass the TradingProfileLanguage query parameter to receive the question and answer texts in the customer's language.

Important

Always fetch the test immediately before presenting it. The version you receive here is the one you must submit back - see below.

2. Submit the answers

POST /entities/natural-persons/{naturalPersonId}/appropriateness-test/asset-types/{appropriatenessTestAssetType}/responses

{
  "TradingProfileLanguage": "de",
  "version": 3,
  "responses": [
    { "questionCode": "Q1", "answerCode": "B" },
    { "questionCode": "Q2", "answerCode": "A" }
  ]
}

Requires the Requestor-ID header.

All three body fields are required. version must be the version you fetched in step 1 - this is what prevents answers being scored against a test the customer never saw. If the test has been updated in the meantime, fetch it again and re-present it.

You submit questionCode and answerCode pairs, not free text. The response returns an appropriatenessTestResponseId.

The endpoint returns 202 Accepted: scoring is asynchronous. The submission is not the outcome.

3. Read the outcome

The result arrives as a status on the response record. Poll for it, or read a specific submission directly.

GET /entities/natural-persons/{naturalPersonId}/appropriateness-test/asset-types/{appropriatenessTestAssetType}/responses

Returns a paginated list of that person's submissions for the asset type. Supports cursor, limit, TradingProfileLanguage, and TradingProfileStatus to filter by outcome.

GET /entities/natural-persons/appropriateness-test/responses/{appropriatenessTestResponseId}

Returns one submission, including the answers given and the resulting status.

Outcome values

Status	Meaning
`RECEIVED`	Submitted, not yet scored
`PASSED`	Customer may trade this asset type
`FAILED`	Customer did not pass
`INVALID`	Submission was rejected - for example the `version` no longer matches the current test

Only PASSED unlocks trading for that asset type. Treat RECEIVED as "not yet", never as success.

Where this sits in onboarding

The appropriateness test is tied to the natural person, not to the customer role, so it can be completed independently of the onboarding process. What it gates is trading in the relevant asset types - a customer can be fully onboarded and still be blocked from trading a security token until the test is passed.

For the surrounding entity flow, see Natural Person Management.