Create an Intelligence Evaluation
Evaluates payee, instrument, payout, merchant onboarding, or monitoring inputs through Anton Intelligence.
The request contract is strict and uses fixed enums so enterprise clients can generate SDKs safely. Direct PII may be supplied over TLS or recovered from a vault token; Anton uses it in memory for the evaluation and persists only redacted decision evidence.
Per-use-case required fields. Beyond the always-required use_case and entity.type, each
use case imposes additional requirements (a 422 validation_error otherwise):
payee_registration—entity.nameORentity.vault_token_id.merchant_onboarding—entity.typemust bebusiness, plusentity.nameORentity.vault_token_id.instrument_screening— aninstrumentblock.payout_screening— apayoutblock, plus searchableentityorinstrumentdata.monitoring— searchableentityorinstrumentdata. These conditional requirements can’t be expressed in the staticrequiredarrays below, so they are enumerated here.
Dual surface. With OAuth+DPoP credentials, the evaluation is persisted under YOUR merchant account
(retrievable via the scoped reads below) and the Idempotency-Key header is REQUIRED. The credential
must carry the intelligence scope and the account the intelligence capability — every Anton account
has it, including AI-compliance-only merchants. Vault-token enrichment only accepts tokens owned by the
calling merchant. Without credentials, the request runs on the anonymous public TEST surface (where
enabled) under a synthetic shared merchant — public evaluations are not tied to your account.
Asynchronous money-movement evaluations. On the authenticated (OAuth+DPoP) surface, a
payout_screening evaluation runs the full AI panel and can take up to ~20 seconds, so it is accepted
asynchronously: the response is 202 Accepted with {evaluation_id, status: "pending"} and a
Location header. Poll GET /v1/intelligence/evaluations/{id} (which returns the pending state until
the evaluation settles), or subscribe to the intelligence.evaluation.completed /
intelligence.evaluation.failed webhook events for push notification. All other use cases — and every
call on the anonymous test surface — respond synchronously with 200 and the full evaluation.
Authorizations
Per-request DPoP proof JWT (RFC 9449). MUST accompany the Authorization: DPoP <access_token> header on every protected operation. The proof is signed by the merchant's private DPoP key and carries htm, htu, iat, jti, and ath claims.
Headers
Recommended for enterprise retries (REQUIRED on the authenticated surface). If both this header and body idempotency_key are supplied, the header wins.
255Body
payee_registration, instrument_screening, payout_screening, merchant_onboarding, monitoring Client-supplied reference for reconciliation. Not used for merchant scoping.
Body fallback for testing. Prefer the Idempotency-Key header.
Accepted for future compatibility but ignored on the public test endpoint.
Response
Evaluation created (synchronous use cases).