AML API Reference

This document describes how to integrate the anti-money laundering (AML) capabilities of the Fraud Prevention Platform (FPP). It covers the tenant profile, the canonical transaction endpoint, batch ingestion, the scenario catalog and its parametrization API, the alert object, the dispatch of alerts to the Case Management Platform (CMP), the return path that brings the desk’s verdicts back, and the deployment switches that govern all of it.

It complements the FPP API Reference, which documents the fraud contract. Authentication, the response envelope, the error format and the outbound webhook mechanics are shared and are referenced here rather than repeated.

The model is the same as for fraud: Guardline detects and signals, the institution acts. The FPP evaluates, produces the alert and hands it to the desk; the CMP owns the case, the committee and the dossier; the institution files the regulatory communication.

Availability. Every contract on this page is fixed. The sections on the tenant profile, domains and workflows, and the canonical transaction are live in the current release. The sections on batch ingestion, the scenario catalog, alerts, dispatch to the CMP and the return path carry a short note naming the architecture decision that fixes them; they ship with the next releases of the AML program and the sandbox exposes each one as it lands.

What changes for existing fraud integrations

Nothing. POST /api/v2/decisions/analyze, its payload, its response and its webhooks are unchanged and guarded against drift in continuous integration. A tenant that adds AML keeps the same API key, the same endpoint and the same decisions. The AML evaluation of a transaction that arrives on /decisions/analyze runs after the fraud decision is returned, outside the request, and never changes the fraud response.

Authentication and conventions

All AML endpoints use the same X-API-Key header, HTTPS requirement and permission scopes described in Authentication. Administrative endpoints (workflows, catalog, parametrization) use the session token of a panel user with the role the endpoint names.

Responses use the standard envelope: {"error": false, "data": {...}} on success and the error format on failure. Every error carries a stable code from the published error catalog and, when the message depends on values, a params object with language-neutral data; branch on code, never on message.

Tenant profile

Each FPP installation declares a profile: fraud, aml or both. The profile is deployment configuration, read once at boot, and it governs surface (panel routes and menus) and external emission (dispatch of alerts to the CMP). It never changes an evaluation: what decides whether a transaction is evaluated in a domain is the active workflow of that domain.

Public configuration

GET /api/v2/tenant/config

Public, no authentication: the panel needs it before login. Relevant fields of data.tenant:

Field	Type	Description
slug	string	Tenant identifier
profile	string	fraud, aml or both. Always present
country	string	Tenant jurisdiction, ISO 3166-1 alpha-2
currency	string	Tenant currency, ISO 4217
default_language	string	Panel language
supported_languages	array	Languages available on the panel

{
  "error": false,
  "data": {
    "tenant": {
      "slug": "example",
      "display_name": "Example Bank",
      "profile": "both",
      "country": "AR",
      "currency": "ARS",
      "default_language": "es",
      "supported_languages": ["es", "pt", "en"]
    },
    "theme": { "primary_color": "#003366", "secondary_color": "#0066cc" },
    "features": {}
  }
}

Operational identity

GET /api/admin/version

Requires the ADMIN role. Besides version, commit, ref, build_time and pod_name, it reports the profile as the running pod reads it and the result of the profile gate:

Field	Description
tenant_profile	fraud, aml or both, read from the environment at boot
profile_workflow_mismatch	true when a domain outside the profile has an active workflow. Evaluation is never blocked by it; it means the deployment and the database disagree and someone has to reconcile them
profile_offending_domains	The domains behind the flag, empty when there is no mismatch
seeds	Version of each catalog seed on this tenant

The gate runs at boot and periodically (see Deployment); a mismatch also raises a system alert of severity WARNING visible on the admin system screen.

Domains and workflows

The engine evaluates one workflow per domain. fraud and aml are the two domains this reference covers; each has at most one active workflow, and a transaction is evaluated once per active domain.

POST /api/v2/workflows

Session authentication. The request is the standard workflow creation with one additional optional field:

Field	Type	Required	Description
domain	string	no	fraud or aml. Omitting it creates a fraud workflow. An unknown value is refused with 400 and a localized message naming the accepted values

Activating a second workflow in a domain that already has one active answers 409 with a localized message; deactivate or update the existing one first. Everything else about workflows (stages, policies, rules, conditions, thresholds, draft, review, approval, versions) is the same for both domains and is managed by the same endpoints and by the same editor.

Which domain decides synchronously

When a transaction arrives, the FPP resolves the tenant’s active domains:

• With a fraud workflow active, the fraud domain decides synchronously and the response carries that decision; the other active domains are evaluated right after, outside the request.
• With no fraud workflow active, the single active domain decides synchronously. An AML-only tenant therefore evaluates and persists like any other.
• With no active workflow in any domain, the request is refused with the existing NO_WORKFLOW error.

The AML evaluation writes its decision and produces alerts (see Alerts); it never executes fraud outcomes, never calls the fraud integrator’s webhooks and never changes the fraud score.

Canonical transaction (v2)

Jurisdiction-neutral intake. Use it for AML tenants and for any tenant whose data does not fit the Brazilian shape of the fraud payload.

Endpoint

POST /api/v2/transactions

API key authentication. The transaction is evaluated once per active domain exactly as it would be on /decisions/analyze, and the response is the same decision payload documented in Understanding the Response.

Request

Field	Type	Required	Description
externalId	string	yes	Your identifier for the transaction and the idempotency key. The same id sent twice answers from the stored row without a second evaluation
accountId	string	yes	The account the transaction belongs to, as your system identifies it
businessDate	datetime	yes	When the transaction happened for the issuer, ISO 8601 with offset. Velocity, baselines, the counterpart network and batch ordering use this date, never the server clock
operationType	string	yes	The rail, validated against the transaction type catalog of the tenant’s jurisdiction (see Lookups)
direction	string	yes	IN or OUT
amount	string	yes	Decimal string in the unit amountUnit names
amountUnit	string	yes	cents or major. No default: inside the engine every value is integer cents, and the wire must say what it is sending
currency	string	yes	ISO 4217. No default
payer	object	yes	The party the account belongs to (see Party object)
counterpart	object	conditional	Required when the operation type’s catalog row has requires_counterpart: true. The rail decides, never the domain
channel	string	no	Origination channel, read by the engine when present
product	string	no	The institution’s product the operation belongs to, as you name it
economicActivityCode	string	conditional	The payer’s economic activity code. Travels with economicActivitySource and is refused without it
economicActivitySource	string	conditional	The register that issued the code (for example CNAE, or the tax authority register of the jurisdiction)
isCash	boolean	no	The operation involves cash
isGamblingOrigin	boolean	no	The funds originate in gambling
skipEngine	boolean	no	Persist the transaction with an ALLOW of score 0 instead of evaluating it. This is how a history is loaded before it is scored (see Two-phase replay)

Every signal field (product, economicActivityCode, channel, isCash, counterpart.isCrypto, isGamblingOrigin) is available as a condition field in the rule editor.

Party object

payer and counterpart share one shape:

Field	Type	Required	Description
identifierValue	string	yes	The document, the account key or the alias itself, stored as sent
identifierType	string	conditional	CPF, CNPJ, CUIT, CUIL, DNI, PASSPORT, ALIAS, CBU or CVU, validated by exact match against the active rows of the document type catalog. Required outside Brazil; accepted on a Brazilian tenant. The type is never inferred from the number of digits
country	string	conditional	ISO 3166-1 alpha-2 of the issuer. Required outside Brazil
holderType	string	conditional	natural_person or legal_entity. Required only when the declared type’s holder is either (today, CUIT); refused when it contradicts a type whose holder is fixed
name	string	no	Carried through to the counterpart record
isCrypto	boolean	no	This counterpart is a crypto asset service provider for this operation

Example

{
  "externalId": "TX-20260917-00000001",
  "accountId": "ACC-00086",
  "businessDate": "2026-09-17T10:17:19-03:00",
  "operationType": "TRANSFERENCIA",
  "direction": "OUT",
  "amount": "125000.00",
  "amountUnit": "major",
  "currency": "ARS",
  "channel": "app",
  "product": "cuenta_corriente",
  "economicActivityCode": "471110",
  "economicActivitySource": "ARCA",
  "isCash": false,
  "isGamblingOrigin": false,
  "payer": {
    "identifierType": "CUIT",
    "identifierValue": "30712345678",
    "country": "AR",
    "holderType": "legal_entity",
    "name": "Comercial Ejemplo S.A."
  },
  "counterpart": {
    "identifierType": "CVU",
    "identifierValue": "0000003100010000000001",
    "country": "AR",
    "name": "Proveedor Ejemplo S.R.L.",
    "isCrypto": false
  }
}

Validation

400 with a stable code and params when: amountUnit or currency is missing; identifierType is not an active row of the catalog; the type and the country are missing on a tenant outside Brazil; holderType contradicts the declared type; economicActivityCode comes without economicActivitySource; the operation type requires a counterpart and none was sent; the operation type is not in the jurisdiction’s catalog.

Idempotency

externalId is the key. A retry after a network timeout answers from the stored decision with idempotent_replay: true, exactly as on /decisions/analyze.

Lookups

Public catalogs the v2 payload validates against.

GET /api/v2/lookups/document-types
GET /api/v2/lookups/transaction-types?jurisdiction=AR

Document types carry kind (person_document or account_identifier) and holder (natural_person, legal_entity, either or none). Transaction types carry requires_counterpart and are listed per jurisdiction; the jurisdiction query parameter defaults to the tenant’s own. Adding a rail or an identifier type is catalog data, not a release.

Batch ingestion

Contract fixed by ADR aml-003 D4; ships with the batch release of the AML program.

Batch ingestion is a queue in the platform’s database, not a synchronous array endpoint. You submit a batch and receive its identifier; a worker processes the items in order of businessDate; each item has a state you can query; rejected items are listed with their reason.

Aspect	Behavior
Item shape	The canonical transaction of the previous section, one per item
Ordering	By businessDate, never by arrival. The order in which the engine sees history determines velocity, baselines and the counterpart network
Item states	Queued, in flight, processed, rejected, with the decision identifier on processed items and the reason on rejected ones
Rejection report	Per item, with a stable reason code, available through the status API and as a downloadable file. A malformed item never stops the batch
Idempotency	externalId per item. Resubmitting a batch after a failure processes only what was not processed
Backpressure	Size and rate ceilings per batch; exceeding them answers 429 with the retry delay. The batch worker has its own concurrency limit and connection budget so that real-time evaluation keeps its latency while a batch runs
Visibility	Queue depth, rejection rate and processing lag are exposed as metrics

Two-phase replay

Loading a history has two phases, and the batch executes them in order:

1. Archive. Items are persisted with skipEngine: true: each becomes a transaction with an ALLOW of score 0 and the mark engine_skipped. Velocity, baselines and the counterpart network are built from them, in business-date order.
2. Score. Items are evaluated serially, in business-date order, against the baselines the archive phase formed. Alerts are produced from this phase.

The mark of historical ingestion is visible on the item status and on the transaction, so archived history is distinguishable from scored traffic.

Scenario catalog and parametrization

Contract fixed by ADR aml-002 D1 and ADR aml-005 D9; ships with the catalog release of the AML program.

A scenario is a typology with identity. The catalog is per jurisdiction and versioned, with an approval trail; every AML rule points to a scenario, and a rule without a scenario produces no alert.

Scenario fields

Field	Description
code	Stable code, unique per jurisdiction among active rows
jurisdiction	ISO 3166-1 alpha-2
domain	aml (the fraud catalog holds the sentinel scenario for fraud alerts)
name, description	Translated through the platform’s lookup translations
regulatory_reference	The norm the scenario answers to; empty until the tenant’s Compliance anchors it
scenario_kind	transaction (produced by a rule at evaluation time) or entity (produced by the periodic entity evaluator)
default_severity	low, medium or high
sla_hours	Null until the tenant’s Compliance fills it
consolidation_window_hours	Window in which triggers for the same subject and scenario consolidate into one alert
dispatch_min_severity	Minimum severity dispatched to the CMP, seeded medium
aggregate_kind, aggregate_field, window_hours, threshold_value, threshold_unit	What the entity evaluator computes for an entity scenario: sum or count of which field, over which window, against which threshold (money thresholds in cents)
weight	The scenario’s contribution to the AML score
threshold_condition_id, weight_rule_id	For a transaction scenario, pointers to the condition and the rule that hold the authoritative threshold and weight

Rule of authority

For an entity scenario the catalog row is the authority: the evaluator reads threshold, window and aggregate from it. For a transaction scenario the authority stays in the workflow: the condition holds the threshold and the rule or the stage policy holds the weight; the catalog holds pointers, never copies. The parametrization API writes a transaction scenario through the conditions and rules services, with the versioning and approval they already have, so a parameter saved by the matrix screen and the same parameter written by the API cannot diverge.

Parametrization API

Read the catalog of the tenant’s jurisdiction, with translations; read and propose changes to the editable parameters (is_active, threshold, window, severity, SLA, weight); list the change history (who, when, from what, to what). Every change is a proposal that another user approves, reusing the approval endpoints the workflow objects already expose. Reads require the Compliance or analyst roles; writes and approvals require the roles the tenant assigns to parametrization.

Alerts

Contract fixed by ADR aml-002 D1 to D4 and D14; ships with the alert release of the AML program.

The alert is a first-class object, served by a read API, with two kinds and one consolidation rule.

Alert object

Field	Description
id	UUID. Stable across resends and the idempotency key sent to the CMP
alert_kind	transaction or entity
domain	aml or fraud
subject	Customer or counterpart: document, document_type, document_country, name, customer_type, and the account with its identifier_type and identifier
scenario	code, name, jurisdiction, catalog_version, regulatory_reference
severity, severity_source	low, medium or high; scenario for AML (from the catalog) or decision for fraud (BLOCK is high, REVIEW is medium)
sla_hours	From the scenario, null when not declared
state, outcome	Open, dispatched, then the desk’s verdict: dismissed, confirmed, reported
window	start, end and label for entity alerts; null for a transaction alert without a window
amount	Aggregated value of the evidence, with currency and minor_units
evidence	The transactions sustaining the alert, stored as a snapshot at trigger time; survives reprocessing of the transaction
origin	engine_decision, entity_job or manual, with decision_id, transaction_id and workflow_id when they apply
subject_risk	Level, score, scale, source and date of the customer risk level as known at trigger time
dispatch_state	Pending, dispatched, or not_applicable for fraud alerts
occurrence	sequence, first_seen_at, last_seen_at

Consolidation

An entity alert always has a window greater than zero. A transaction alert consolidates by customer, scenario and originating decision. Within the scenario’s consolidation window, the first trigger for a subject and scenario creates the alert; the following ones add evidence to it and increment occurrence.sequence. The consolidation bucket is anchored on the business date of the evidence, never on the clock, so concurrent writers and historical replays land on the same alert.

Query

Alerts are listed by subject, scenario, severity, state and window, ordered by date, with their evidence. A transaction alert links to the analyst case of the same decision through decision_id; nothing is written twice. Fraud alerts stay in the FPP workbench and are never dispatched.

Dispatch to the CMP

Contract fixed by ADR aml-002 D4 to D9; ships with the dispatch release of the AML program, when the CMP exposes the route below.

A dedicated worker reads AML alerts pending dispatch and sends them to the CMP of the same tenant. It reuses the platform’s webhook sender (durable outbox, retries with backoff, exhaustion alert, secrets encrypted at rest) with an api_key authentication mode.

Gate

The worker dispatches only when the tenant profile includes AML and an aml workflow is active, and only alerts whose severity is at or above the scenario’s dispatch_min_severity (medium by default: low alerts stay in the FPP). Fraud alerts are never dispatched.

Route and authentication

POST /api/v2/ingest/alert
X-API-Key: <CMP ingestion key of the tenant>
X-Tenant-Slug: <tenant slug>
Content-Type: application/json

Body

Field	Description
schema_version	"2.0"
alerta_externo_id	The alert id. Stable across resends because consolidation lives in the FPP
alert_kind	transaction or entity
domain	aml
subject	kind, document, document_type, document_country, name, customer_type, account with external_id, identifier_type, identifier. No inference by digit count
scenario	code, name, jurisdiction, catalog_version, regulatory_reference
severity, severity_source, sla_hours	As on the alert
detected_at	Timestamp of the trigger
window	start, end, label; null when the alert has no window
amount	value as a decimal string, currency (required whenever a value is present), minor_units
evidence	count, returned, truncated and up to the cap of transactions, each with transaction_id, external_id, occurred_at, amount, currency, type, channel, direction and counterpart. The full dossier stays in the FPP behind source_url
customer_risk	level, score, scale_max, source and as_of. Sent with the level the FPP actually holds and its provenance, or null; never invented
customer_profile	The current transactional profile of the subject, free form
engine	origin, decision_id, transaction_id, workflow_id, score with value and scale_max, rules_triggered with scenario_code per rule
source_url	Link to the alert in the FPP panel
occurrence	sequence, first_seen_at, last_seen_at. A second trigger arrives with the same alerta_externo_id and a higher sequence

Fields deliberately absent: cpf_cnpj, tipo_alerta, is_coe, tipologia_sugerida, score_risco. The subject carries a typed document, the scenario replaces the free-text typology, the score travels with its scale, and cash-related obligations are derived by the CMP from the tenant’s jurisdiction, never from the payload.

Example

{
  "schema_version": "2.0",
  "alerta_externo_id": "0f1c1f3a-2f2f-4b3d-9a3e-2f9d6a0b7c11",
  "alert_kind": "entity",
  "domain": "aml",
  "subject": {
    "kind": "customer",
    "document": "30712345678",
    "document_type": "CUIT",
    "document_country": "AR",
    "name": "Comercial Ejemplo S.A.",
    "customer_type": "company",
    "account": { "external_id": "ACC-00931", "identifier_type": "CBU", "identifier": "0170099220000067797364" }
  },
  "scenario": { "code": "ar_incremento_abrupto", "name": "Incremento abrupto de actividad", "jurisdiction": "AR", "catalog_version": 1, "regulatory_reference": null },
  "severity": "medium",
  "severity_source": "scenario",
  "sla_hours": null,
  "detected_at": "2026-09-10T14:12:03Z",
  "window": { "start": "2026-09-03T00:00:00Z", "end": "2026-09-10T14:12:03Z", "label": "7d" },
  "amount": { "value": "12500000.00", "currency": "ARS", "minor_units": 1250000000 },
  "evidence": {
    "count": 37,
    "returned": 20,
    "truncated": true,
    "transactions": [
      {
        "transaction_id": "8f2d3c1e-...",
        "external_id": "TX-20260909-0918233",
        "occurred_at": "2026-09-09T22:41:00Z",
        "amount": "480000.00",
        "currency": "ARS",
        "type": "TRANSFERENCIA",
        "channel": "app",
        "direction": "OUT",
        "counterpart": { "identifier_type": "CVU", "identifier": "0000003100010000000001", "name": "Proveedor Ejemplo S.R.L.", "country": "AR" }
      }
    ]
  },
  "customer_risk": { "level": "high", "score": 720, "scale_max": 1000, "source": "fpp_formula", "as_of": "2026-09-01T03:11:00Z" },
  "customer_profile": { "measured_avg_30d": "2100000.00", "p95_30d": "5400000.00", "baseline_as_of": "2026-09-08T00:00:00Z" },
  "engine": {
    "origin": "entity_job",
    "decision_id": null,
    "transaction_id": null,
    "workflow_id": "3a1f...",
    "score": { "value": null, "scale_max": 1000 },
    "rules_triggered": []
  },
  "source_url": "https://fpp.example.com/aml/alerts/0f1c1f3a-2f2f-4b3d-9a3e-2f9d6a0b7c11",
  "occurrence": { "sequence": 3, "first_seen_at": "2026-09-04T10:00:00Z", "last_seen_at": "2026-09-10T14:12:03Z" }
}

Responses

Status	result	Meaning
201	created	A new case was opened
200	consolidated	The alert was attached to an open case of the same subject
200	updated	A resend or a new trigger of the same alerta_externo_id; the desk updated evidence, amount, window and occurrence, and raised severity if higher
400		Validation: missing document, unknown scenario, invalid severity, amount without currency
401, 403		Key missing, invalid or outside the ingest:alert scope
429		Rate limited; retried by the sender with backoff

The response carries case_id, numero_caso and result. The FPP stores them in its correlation table, keyed by alert, external system and tenant, which is what the alert list shows and what the return path resolves.

Retries

Failed deliveries follow the sender’s retry policy (backoff of 5 seconds, 30 seconds, 2 minutes and onward) and raise the exhaustion alert when attempts run out. Because alerta_externo_id is stable, a retry never opens a second case.

Return path from the CMP

Contract fixed by ADR aml-002 D10 and D11; ships with the return path release of the AML program.

The CMP emits its seven case events to a signed receiver on the FPP.

Receiver

POST /api/v2/inbound/cmp
X-Webhook-Signature: <hex HMAC-SHA256 of the raw body>
X-Webhook-Delivery: <delivery identifier, stable across retries>
X-Webhook-Event: <event name>
Content-Type: application/json

The signature is HMAC-SHA256 over the whole raw body, hexadecimal, no prefix, with the secret registered on the CMP outbound webhook configuration. It is verified in constant time, on the body as received and before any JSON parsing, with an explicit size cap. There is no timestamp header on this path, so deduplication by X-Webhook-Delivery is the replay defense: a delivery id already recorded answers 200 and is not processed again.

The receiver accepts and then processes: it verifies, records the delivery in a durable inbound ledger, answers 2xx, and processes outside the request. The CMP delivers at least once (three attempts with backoff of 0, 30 and 120 seconds), which the ledger absorbs.

Events and their effect

The envelope carries case_id, numero_caso, action, pld_status, motivo and occurred_at. The FPP resolves case_id through the correlation table to the alerts absorbed into that case (one case can hold several alerts) and writes per alert:

Event	Alert state	Alert outcome	Customer 360
triagem_concluida (closed at triage)	closed	dismissed	customer event recorded
comite_aprovado	acknowledged	confirmed	customer event recorded
comite_reprovado	closed	dismissed	customer event recorded
coaf_registrado (report filed)	closed	reported	customer event recorded
coaf_retificado (report amended)	unchanged	amended	customer event recorded
coaf_cancelado (report cancelled)	unchanged	cancelled	customer event recorded
coaf_erro (filing error)	unchanged	unchanged	none; operational problem on the desk side

The event names are the CMP’s own and are kept as they are. Every write lands in customers.customer_events and is visible on the customer 360.

Verdicts and the fraud score

By default the desk’s verdicts change nothing in the fraud evaluation: no counter, no risk score, no condition field. The switch GUARDLINE_VERDICT_FEEDS_RISK (absent means off) exists for the institution that wants confirmed alerts to feed the customer risk; turning it on changes fraud decisions and therefore ships in its own release with a differential proof, never alongside anything else.

Deployment and operation

The AML surface is governed by the tenant’s Helm values and by environment variables the chart renders from them. Nothing here is editable from the panel.

Values

Key	Values	Effect
tenantProfile	fraud, aml, both	Rendered as GUARDLINE_TENANT_PROFILE on the API deployment and as TENANT_PROFILE in the web configuration. Absent means fraud. Validated by the chart schema: any other value fails helm lint and helm template
tenant.country, tenant.currency	ISO codes	The tenant’s jurisdiction and currency, exposed by /tenant/config and used to resolve the catalogs

The same profile is declared on the CMP release of the tenant; a lint in the infrastructure repository fails when the two disagree, and a second lint proves that a fraud render and an AML render differ exactly in the profile keys and in nothing else. On-premises installations receive an example values file where the profile is a mandatory field to fill in.

Environment variables

Variable	Default	Effect
GUARDLINE_TENANT_PROFILE	fraud	The profile. An unknown value fails the boot
TENANT_PROFILE_GATE_INTERVAL_SEC	600	Interval of the gate that compares the profile with the active domains. Zero or negative runs the gate at boot only
DOMAIN_EVAL_CONCURRENCY	100	Per-process cap on concurrent asynchronous domain evaluations (AML after fraud). Waiting evaluations time out after five minutes and are dropped with a stable warning event; the fraud decision is never affected
BACKGROUND_JOBS_ENABLED	true	false keeps every periodic job off the pod, the entity evaluator included
GUARDLINE_VERDICT_FEEDS_RISK	off	See Verdicts and the fraud score

All are read once at boot; changing any of them takes a rollout.

What to check after a rollout

1. GET /api/v2/tenant/config returns the expected profile, country and currency.
2. GET /api/admin/version reports the same tenant_profile on every pod and profile_workflow_mismatch: false.
3. The panel shows the AML menu only on profiles aml and both, and a hand-typed AML route is refused on fraud.
4. For both, a transaction sent to /decisions/analyze returns the fraud decision unchanged and, seconds later, has an AML decision on the same transaction.

Error handling

Errors follow the standard format with a stable code. Codes specific to this reference:

Code	Status	When
INVALID_REQUEST_BODY, VALIDATION_ERROR	400	Malformed body or any v2 payload rule of Validation; params names the field
INVALID_IDENTIFIER_TYPE	400	identifierType is not an active row of the document type catalog
INVALID_DOCUMENT	400	The identifier value does not match its declared type
INVALID_ACCOUNT_ID	400	Missing or malformed accountId
ERR_INVALID_DOMAIN	400	Unknown domain on workflow creation
WORKFLOW_DOMAIN_ALREADY_ACTIVE	409	A second active workflow in the same domain
NO_WORKFLOW	500	No active workflow in any domain of the tenant; params carries the domains looked up
API_KEY_INVALID, AUTH_REQUIRED	401	API key or session missing or invalid
FORBIDDEN	403	The key or the user is outside the scope or role the endpoint requires
RATE_LIMIT_EXCEEDED	429	Request rate or batch ceiling exceeded; retry after the indicated delay

Every code is listed, with its statuses and parameters, in the error catalog published with the API.

Endpoint summary

Method	Path	Auth	Purpose
GET	/api/v2/tenant/config	none	Tenant profile, jurisdiction, currency, languages
GET	/api/admin/version	session, ADMIN	Running profile and profile gate result
POST	/api/v2/workflows	session	Create a workflow in a domain
POST	/api/v2/transactions	API key	Canonical transaction intake and evaluation
GET	/api/v2/lookups/document-types	none	Identifier types with kind and holder
GET	/api/v2/lookups/transaction-types	none	Operation types per jurisdiction
POST	/api/v2/ingest/alert (on the CMP)	CMP API key	Receives the dispatched alert
POST	/api/v2/inbound/cmp	signature	Receives the desk’s events

Batch, catalog, parametrization and alert query endpoints are published with their releases, with the shapes fixed in the sections above.