Control test outcomes

In the Preview environment, you can control the outcome of submitted individual verifications by using special keywords in the middleName parameter. This allows you to test different scenarios without needing real data.

Test keywords only work in the Preview environment (dev.bronid.com). In production, verifications are processed using real data sources.

Test keywords

Use these keywords at the start of the individual's middleName field to trigger different verification outcomes:

Keyword	Outcome
`ok`	Results in a verified status.
`pass`	Results in a verified status.
`pep`	Results in a verified status with positive watchlist matches.

The middle name is the only field checked for test keywords, so the first and last name stay free for realistic test data. There is no rejection keyword — synthetic identities don't match any real data source in Preview, so any individual submitted without a verified keyword results in a rejected status. Screening outcomes (sanctions, PEP, criminal, negative media) can be controlled with additional keywords — see Test values.

Entity (KYB) verifications carry their test keyword at the start of the entity's name instead (entities have a single name field): pass → verified, info → an automated information request (a sample stakeholder and document are requested, then the status becomes info), fail → rejected. Entity screening outcomes can also be controlled with keywords in the entity name (see Test values).

How it works

When you submit an individual verification in the Preview environment, the system checks if the middle name starts with one of the test keywords. If it does, the verification will be processed to produce the corresponding outcome.

For example:

"middleName": "ok" will result in a verified status
"middleName": "pep" will result in a verified status with positive watchlist matches
"middleName": "James" (or any other value) will result in a rejected status, because the synthetic identity doesn't match any real data source

POST/v5/verifications

Example: Trigger a verified outcome

In this example, we submit an Australian individual with a middle name of ok to trigger a verified outcome.

Request body

Name
userId
Type
string
Description
Your unique identifier for the individual
Name
country
Type
string
Description
ISO3 Country code of the individual
Name
type
Type
string
Description
Entity type (individual)
Name
subType
Type
string
Description
Entity sub-type
Name
firstName
Type
string
Description
First name (free for realistic test data)
Name
middleName
Type
string
Description
Middle name (carries the test keyword)
Name
lastName
Type
string
Description
Last name (free for realistic test data)
Name
email
Type
string
Description
Email address of the individual
Name
dateOfBirth
Type
string
Description
Date of birth (YYYY-MM-DD)

Request

POST

/v5/verifications

curl https://dev.bronid.com/v5/verifications \
  --user "your-api-key:your-api-secret" \
  --header "Content-Type: application/json" \
  --data '{
      "userId": "test-verified-individual",
      "country": "AUS",
      "type": "individual",
      "subType": "none",
      "firstName": "John",
      "middleName": "ok",
      "lastName": "Smith",
      "email": "john.smith@example.com",
      "dateOfBirth": "1990-01-15"
  }'

Response

{
  "timestamp": "2026-01-30T03:00:42.101Z",
  "serviceUid": "XL7ULiU6B4QE9Y2iWFZnhtMDKFN2",
  "trace": "_mycHhuXA8vDMTgbCsqJf",
  "path": "/v5/verifications",
  "pathParams": {},
  "statusCode": 200,
  "message": "Verification created successfully",
  "help": null,
  "status": "success",
  "data": null,
  "error": null
}

What's next?

Now that you know how to control test outcomes, learn how to provide missing information for incomplete verifications.