ComplyAdvantage
Risk intelligence + AML platform
ComplyAdvantage Mesh connects customer screening, ongoing monitoring, payment screening, transaction monitoring, and case review. Its own risk intelligence is central to the proposition. The current API uses persistent customer records and a customer-to-case-to-alert-to-risk structure, which matters when migrating from older screening integrations.
Our assessment
A broad AML platform. The claim that it can do all onboarding, underwriting, and fraud work needs qualification.
Best fit and limitations
A useful candidate when screening data and ongoing AML operations are the central needs. It can also serve as a screening layer under an orchestration or merchant onboarding platform.
- A screened company is not a verified company. Business registries, ownership discovery, documents, and liveness need separate proof.
- Payment sanctions screening is not equivalent to card fraud authorization scoring.
- Mesh and the older screening API have different identifiers, monitoring behavior, and webhook events.
Tools 6
Customer screening + ongoing monitoringRelationship screening+
- Create a persistent person or company record
- Screen, review matched profiles, and monitor changes
Payment ScreeningPayment-party checks+
- Screen names, BICs, and reference text
- Synchronous submission plus held-payment review and webhooks
Transaction monitoringBehavioral controls+
- Monitoring cases share the Mesh case environment
- Group alerts around the customer rather than isolated searches
Mesh Case ManagerReview and disposition+
- Cases contain alerts and individual risk matches
- Historical cases retain their screening configuration
Headless payment screeningOwn your review interface+
- Fetch risks using your payment reference
- Record risk decisions from an external case tool
Mesh agentic workflowsScreening alert review+
- Resolve eligible routine alerts under configured policies
- Record agent actions and their decision reasons
AI capabilities
Risk intelligence + screening review agents
Mesh documents agents that resolve routine screening alerts under configured thresholds and risk policies. The published scope includes sanctions, PEP, and adverse-media review, with recorded decision reasons.
What to validate
Test allowed actions, uncertain matches, policy limits, and escalation. Keep source profile IDs, list versions, risk decisions, and approvals beside each AI output.
Implementation
Integration checklist
- Build around stable external customer IDs and store Mesh identifiers.
- Test alert grouping and webhook handling when an alert is added to an existing case.
- Define who holds a payment and how release/rejection reaches the payment processor.
Commercial scope
Quote required. Price customer screening, rescreening, payment volume, monitoring, case access, data rights, and AI usage separately.
Questions for the demo
- Which Mesh features, agents, reporting tools, and data collections are licensed?
- How do existing false-positive decisions survive a migration or list update?
- Which fraud and underwriting functions require another vendor?
Engineering
- Inputs
- Search term, client reference, search profile, fuzziness, and filters · Payment transactions linked to Mesh customer records · Single transactions or batches · Access key and secret exchanged at POST /v3/token · Customer screening requests with configuration_identifier
- Outputs
- Screening responses with status and content fields · Risk records linked to payment references and configuration identifiers · Bearer access token and results from the configured screening workflow · WORKFLOW_COMPLETED for asynchronous create-and-screen · TRANSACTION_REVIEWED for payment-screening or monitoring reviews
- Webhooks
- TRANSACTION_REVIEWED reports a held payment's review decision. The headless API supports review from an external case tool. At-least-once delivery; deduplicate webhook-id. Retries occur after 1, 5, and 10 seconds; each attempt has a 5-second response timeout. Persist the payload and return 2xx promptly.
- Decision timing
- Synchronous payment screening and batch ingestion are documented. Combining synchronous transaction monitoring changes the response time; no independent latency test was performed.
- Deployment
- Published endpoint families: EU, EU3, US, US2, Canada, Australia
- Dependencies
- Authorization: Token API key for the documented screening API · Mesh customer records and payment-screening configuration · Credentials created in Access Management with selected permissions and optional expiry · Compliance-team screening configuration · Webhook signing is opt-in per account through support · Verify HMAC-SHA256 over webhook-id, timestamp, and raw body; decode the base64 secret first · Use v2 webhooks; v1 is deprecated · Handle 429 and ratelimit headers; apply backoff · Idempotency keys are endpoint-specific, not a universal request guarantee
Verified details 23
- Inputs
Search term, client reference, search profile, fuzziness, and filters
Source Checked 2026-09-18 - Outputs
Screening responses with status and content fields
Source Checked 2026-09-18 - Dependency
Authorization: Token API key for the documented screening API
Source Checked 2026-09-18 - Inputs
Payment transactions linked to Mesh customer records
Source Checked 2026-09-18 - Inputs
Single transactions or batches
Source Checked 2026-09-18 - Decision timing
Synchronous payment screening and batch ingestion are documented. Combining synchronous transaction monitoring changes the response time; no independent latency test was performed.
Source Checked 2026-09-18 - Dependency
Mesh customer records and payment-screening configuration
Source Checked 2026-09-18 - Outputs
Risk records linked to payment references and configuration identifiers
Source Checked 2026-09-18 - Webhooks
TRANSACTION_REVIEWED reports a held payment's review decision. The headless API supports review from an external case tool.
Source Checked 2026-09-18 - Inputs
Access key and secret exchanged at POST /v3/token
Source Checked 2026-09-18 - Inputs
Customer screening requests with configuration_identifier
Source Checked 2026-09-18 - Outputs
Bearer access token and results from the configured screening workflow
Source Checked 2026-09-18 - Dependency
Credentials created in Access Management with selected permissions and optional expiry
Source Checked 2026-09-18 - Dependency
Compliance-team screening configuration
Source Checked 2026-09-18 - Webhooks
At-least-once delivery; deduplicate webhook-id. Retries occur after 1, 5, and 10 seconds; each attempt has a 5-second response timeout. Persist the payload and return 2xx promptly.
Source Checked 2026-09-18 - Deployment
Published endpoint families: EU, EU3, US, US2, Canada, Australia
Source Checked 2026-09-18 - Dependency
Webhook signing is opt-in per account through support
Source Checked 2026-09-18 - Dependency
Verify HMAC-SHA256 over webhook-id, timestamp, and raw body; decode the base64 secret first
Source Checked 2026-09-18 - Outputs
WORKFLOW_COMPLETED for asynchronous create-and-screen
Source Checked 2026-09-18 - Outputs
TRANSACTION_REVIEWED for payment-screening or monitoring reviews
Source Checked 2026-09-18 - Dependency
Use v2 webhooks; v1 is deprecated
Source Checked 2026-09-18 - Dependency
Handle 429 and ratelimit headers; apply backoff
Source Checked 2026-09-18 - Dependency
Idempotency keys are endpoint-specific, not a universal request guarantee
Source Checked 2026-09-18
Illustrative contract
An example for your internal adapter. This is not a vendor endpoint, request, or response.
{
"contract": "internal-risk-review/v1",
"vendorId": "complyadvantage",
"internalCorrelationId": "example-001",
"vendorRecordId": null,
"control": "Relationship screening",
"evidence": [],
"status": "pending",
"decision": "review",
"requiresHumanReview": true
}Integration limits
- Illustrative internal integration contract. This is not a vendor request, response, endpoint, or SDK example.
- Empty country, deployment, or provider lists mean not verified in this review. A documented country refers to the specific product noted in its source, not universal platform coverage.
- This REST/JSON screening API is distinct from Mesh. EU, US, and APAC base URLs describe API routing, not screening-data country coverage.
- A screening decision is a signal for the client's payment system. It is not evidence that Mesh executes settlement.
- Legacy user/password /v2/token remains for existing integrations; do not assume identical setup for a new account.
- Signing supports overlapping keys during rotation. The guide recommends a five-minute timestamp tolerance. Hosting endpoints do not establish screening coverage.
- The August 26, 2026 FAQ states a 24-hour access-token lifetime and separates UI-based from headless remediation.
Sources 8
Source review dates are shown above. Product claims come from public sources. Fit, limits, and evaluation questions are our analysis. This is not a hands-on performance test. Methodology · Changelog