Version history

What changed in the sandbox, newest first. This page starts on 16 July 2026 and grows forward. Earlier changes are not listed.

11 August 2026

AML-only company cases are now simulated

Sending caseProcessingType: "AML" on POST /v2/Companies now creates a screening-only case instead of returning the documented refusal. Any company name works and needs no jurisdiction or registration details (an unregistered entity in an automated jurisdiction takes the same path). Names outside the seed catalogue always screen clean; three documented synthetic test names return deterministic hits, one each for sanctions, regulatory enforcement with SIC, and PEP, readable at GET /v2/Companies/{caseCommonId}/amlchecks and in caseAmlSummary on the case.

AML-only cases carry the production shape, including a production quirk worth knowing: the case list and the case detail read report some header fields differently. On GET /v2/Companies/{caseCommonId} (the read you poll) an AML-only case reports caseProcessingType: "Empty", isAMLCase: false and a populated caseReadyDatetime once Ready; the case LIST row for the same case reports isAMLCase: true with caseProcessingType and caseReadyDatetime null. The sandbox mirrors each surface as production serves it. On both: the org chart returns 404, member lists are empty, mandatory document rules are [], and the case report serves a PDF. AML-only cases participate in ongoing monitoring: the sandbox re-screen control works on them (the sanctions persona’s first re-screen lands a fresh AML alert) and results arrive on the polling alert endpoints.

One breaking change: case imports (POST /v2/Companies/import, POST /v2/Individuals/import) remain refused, but the refusal marker changed from [SANDBOX_AML_ONLY_UNSUPPORTED] to [SANDBOX_IMPORT_UNSUPPORTED], because the old marker’s statement that the sandbox does not simulate AML-only cases is no longer true. If your integration branches on the old marker, update it.

Three synthetic test names renamed

Three of the sandbox’s synthetic entities turned out to collide with real companies, so they have been renamed; the data, behaviour, and identifiers behind them are unchanged. If your test suite pins any of these names, update it: seed company Victoria Harbour Trading Co Limited (HK) is now Selverhaven Harbour Trading Co Limited; the monitoring simulation’s AML-match persona is now Perlhaven Marine Services Ltd (catalogue key perlhaven-marine); the shareholder-change persona is now Veldmoor Capital Partners Limited and its catalogue key is veldmoor-capital. Every synthetic name in the sandbox is checked against real-company registers; none of the sandbox’s screening outcomes refer to any real organisation.

8 August 2026

Monitoring is now testable in the sandbox

Ongoing monitoring can now be exercised end to end. The production Live Monitoring endpoints (lm-cases, lm-alerts, lm-alerts-action, review-date, amlchecks) serve real alert data in the sandbox, the Workspace carries the Live Monitoring section (alert cards, accept/decline, apply/dismiss, the five-type filter, and the alert-count badge), and two sandbox-only simulation controls generate monitoring activity on demand:

• POST /v2/sandbox/monitoring/rescreen/{caseCommonId} runs a deterministic scripted re-screen (director change, shareholder change, shareholder change with a new AML hit, or the everyday clean review that rolls the review date). Results land after the case’s per-jurisdiction latency window, like a real sweep.
• POST /v2/sandbox/monitoring/alerts injects a typed alert immediately, from a fixed persona catalogue; GET /v2/sandbox/monitoring/catalogue publishes every deterministic input.

Both controls require a Ready case: a case that is still building rejects with 409 and the message marker [SANDBOX_CASE_BUILDING]. Tenant reset restores seeded alerts, rewinds the scenario scripts, and discards applied changes. See the new Test monitoring in the sandbox guide.

Amended the same week: the monitoring guide now carries captured 200 response samples for lm-alerts and lm-cases, including a note on the caseType integer-vs-string wire quirk.

Monitoring alerts are retrieved by polling, and the docs now say so everywhere

Monitoring alerts are not delivered by webhook, in the sandbox or in production; the retrieval pattern is polling the alert endpoints. Portal pages that previously suggested monitoring alerts could be pushed to a webhook endpoint have been corrected. Webhooks remain the push channel for case lifecycle events.

Stricter 404s on case routes

Every /v2/Companies/{caseCommonId}/... and /v2/Individuals/{caseCommonId}/... route now returns 404 when the case belongs to the other family, exactly like the plain case read always did. Previously a handful of per-case routes would serve or mutate a case through the wrong route family.

16 July 2026

Company cases in jurisdictions without a registry search

Not every jurisdiction has a searchable company registry behind the API. GET /v2/Jurisdictions reports those with "isautomated": false. The sandbox used to refuse a case in one of them, because there was nothing to search and nothing to match. It now accepts them.

Since there is no search, you have no company identifier to send. Supply entityType instead. It stands in for the identifier:

curl -X POST https://api.knowyourcustomer.dev/v2/Companies \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"rawname":"mdm software GmbH","codeiso31662":"LI","entityType":"Company"}'

entityType accepts Company, Regulated, Listed, Trust or Partnership. The value comes back on the case as company.type and as the Company Type property. The name is accepted as given, so any name works. There is no catalogue to match against.

Leave entityType out and the API tells you exactly what is missing:

{
  "statusCode": 400,
  "message": "Api Error",
  "apiErrors": [
    {
      "description": "The jurisdiction 'Liechtenstein' is not yet automated. Please provide the entity type that best suits the company.",
      "timeStamp": "07/16/2026 12:42:23"
    }
  ]
}

The message names the jurisdiction rather than its code, so you can catch the 400, add entityType, and retry. That is the intended flow if you do not want to read isautomated up front.

The lifecycle you will observe

These cases take a different path from a registry-backed case, and a slower one. Poll GET /v2/Companies/{caseCommonId} and you will see common.statusId move through:

Two things worth designing for. caseReadyDatetime is null while the case is being worked and is populated once it reaches Ready, so do not treat it as a scheduled completion time. And GET /v2/Companies/{caseCommonId}/report returns 409 until the case is Ready, as it does for any case still building.

Budget about 18 minutes from create to Ready. A registry-backed case in an automated jurisdiction is much faster.

These cases finish empty, and that is correct

A case created this way reaches Ready with no members, no officers and no ownership structure. The org chart contains the company itself and nothing else.

This is worth stating plainly, because it looks like a failure and is not. The sandbox serves pre-loaded data. It holds none for a company it has never seen, and it will not invent officers and attach them to a real company name, because you would have no way to tell invented data from real data. So the case is well-formed and empty rather than populated and fictional.

Everything else about the case behaves normally: the status walk, the AML step, the audit trail, the report at Ready, close and reopen. If you need a case with a populated ownership structure to develop against, use one of the companies on Test cases in a jurisdiction with a registry search.

Jurisdiction automation flags now match the platform

isautomated on GET /v2/Jurisdictions now carries the same value as the production platform for all 253 jurisdictions, rather than a shorter hand-maintained list. Two consequences you may notice:

• Jurisdictions without a registry search are now listed. They are creatable by name with entityType, so they belong in the picker.
• A few jurisdictions changed flag. The British Virgin Islands is reported as automated, which is what the platform reports.

isautomated is the flag to branch on if you want to decide up front whether to send entityType.