Compliance and verification

The /v3/compliance routes hold the checks and documents you ask a Payee to complete before you pay them. This section covers the resources that have their own guide here. Tax filings are covered elsewhere; see the links at the end.

Resources in this section

Tax identity is verified through the Tax verification of a payee's ComplianceEntity; see Tax information.

The pattern most of these resources share

Background checks, biometric requests, insurance monitors, shared file requests, and signature requests all follow the same shape.

1. A configuration says what you want. A background check configuration, insurance monitor configuration, shared file request configuration, or document template is created once and reused. Its id is the dataSourceId of a requirement definition.
2. A request or monitor is opened for one payer-payee relationship. The body carries payerPayeeId, never an Account ID. The caller must hold one of the two seats on that record, or the call returns 404.
3. The Payee acts, and the status moves on its own. Status, jobs, and timestamps are written by the vendor or the platform. You can't set them with PATCH.

Payer and payee callers

One create endpoint serves both seats, with different rules:

• A payer can order directly. It names the configuration (or template, or package) and needs no requirement.
• A payee opens its own request only against a requirement. It must send requirementId, and it must leave out the payer-only fields (externalId, metadata, and the configuration, template, or package ID).

The checks run in order. A payee body with no requirementId returns 400, whatever else it carries. A payee body with a requirementId and a payer-only field returns 422. So a 400 on a payee call means the requirement is missing, not that the whole body is malformed.

Repeated creates

A create that cites a requirementId returns the request that is already outstanding instead of opening a second one. The repeat's metadata is not merged. These opt out and open a new request: a payer's direct order, an externalId, and a payer reset of the requirement.

externalId, metadata, and idempotency

• externalId is your own reconciliation ID. A value already in use for your account returns 409 ResourceConflict. Create is not an upsert. Look the existing record up with filter[externalId][eq] where the resource has a list endpoint.
• PATCH on these resources uses JSON Merge Patch and is limited to what each guide lists. Status fields are never writable.
• Send an Idempotency-Key header on every POST and PATCH. If a 409 or 422 tells you to retry, use a new key. Reusing the old one replays the earlier response.

Events

Webhook events marked Published in the event catalog for this section:

Biometric identity verifications have no published events. Poll the request instead. See Webhooks and events for delivery and signature checks.

Related guides

• Requirements and eligibility: attach these checks to engagements.
• Files and documents: upload, download, and share files.
• Identity verification: the account holder's KYC record, which is separate from biometric verification.