ComplyAdvantage joint cases need risk-by-risk disposition

Build a parent payment record and typed risk children

The direct answer is to model the joint screen as a case graph, not one undifferentiated alert. The parent record should preserve the payment identifier and message version, rail and schema, originator and beneficiary, ordering and beneficiary institutions, every intermediary, BICs and other identifiers, accounts, amount and currency, reference text, value and requested execution times, source system, screening submission, response, hold state, deadline, and current processing owner.

Each child risk should identify the exact message field and party role that generated it, the submitted and normalized value, list or custom-list record, issuer and program, profile identifier and version, matching configuration, compared fields, score or rule output where available, conflicts, missing data, related risks, evidence gathered, analyst, status, reason, escalation, and timestamps. Two hits on one payment can require different identity and legal analysis even when the interface places them together.

Resolve every material child before deciding the payment

Define which child states permit a parent decision and which require continued hold. A false-positive identity disposition, confirmed match, unresolved ownership question, custom-list policy hit, reference-text concern, BIC candidate, and unavailable source are not interchangeable. The payment should not become releasable because one prominent alert was cleared while a lower-ranked or newly created risk remains open, hidden, duplicated, or assigned to another queue.

Preserve dispositions at both levels. A child result states what the reviewer concluded about that risk under a particular source and evidence cutoff; the parent result records the authorized release, reject, return, cancel, escalate, or continue-hold action for the payment as a whole. Link the applied jurisdiction, policy, license or exception evidence, legal or compliance review where needed, accountable decision maker, conditions, downstream instruction, execution receipt, and later correction without copying the parent outcome back onto every child.

Keep the boundary distinct from adjacent controls

This article does not repeat the standing-customer-versus-payment boundary addressed in the Facctum review. It assumes the payment case already exists and asks whether multiple risks inside that one payment are individually complete before the parent action. It also differs from Dow Jones pre-trade and post-trade records and from a generic true-or-false name match. The affected record is the parent-child disposition graph for one held payment at one evidence cutoff.

Configuration history remains important but is not the decision object here. A case should reference the list and matching setup it used, while the control test concentrates on completeness, typed relationships, reviewer accountability, and parent action. Reporting should show open risks per held payment, time in each state, reassignment, source gaps, overrides, releases with unresolved children, rejected payments, cancellations, late updates, and downstream execution differences without presenting case closure as proof of legal compliance.

Test one payment with conflicting risk outcomes

Use a synthetic payment with a near-match on the beneficiary, a BIC hit involving an intermediary, a custom-list record, and reference text that produces a separate review. Clear one candidate, confirm one source identity, leave an ownership question unresolved, correct the message, duplicate a child alert, and receive a list update before the processing deadline. Reviewers should prove that every child retains its evidence and history and that the parent remains held until the organization's authorized conditions are met.

ComplyAdvantage's official page supports the attributed field coverage, list, configuration, hold-and-review, joint-view, case-context, audit-trail, and release-or-reject positioning. It does not establish a customer's message completeness, source coverage or freshness, match accuracy, case configuration, analyst conclusion, legal applicability, processing latency, payment decision, settlement, control effectiveness, compliance, or outcome. Payment operations, sanctions, anti-financial-crime, trade, compliance, risk, technology, and legal owners retain those determinations.

Enterprise buyer test

Translate this change into the exact population, record type, workflow stage, decision owner, effective date, and evidence that could be affected. Ask current or prospective providers to demonstrate the named workflow with representative data and an exception—not a polished feature tour. Record what official documentation establishes, what a provider states, what the team observes, and what remains unresolved.

A defensible review also identifies the dependency outside the product. Authority interpretation, policy configuration, data quality, integrations, human judgment, approval rights, release governance, training, and retained evidence may remain customer or service responsibilities. The evaluation should preserve those boundaries instead of treating a technology claim as the complete operating model.

What we will watch next

Trade Controls Brief will watch the named source and affected market records for later evidence that changes status, scope, availability, implementation timing, workflow consequence, or the limits of the initial report. A later announcement does not silently overwrite this dated account; the change ledger preserves the sequence.