Monitoring Model

Signals is the umbrella under which everything you monitor about an entity is grouped. A signal is a detected event, pattern or trigger that warrants attention. The Signals area gathers five linked views, all keyed to the entity:

• Activities: the immutable audit trail of actions and verifications.

• Behavioural insights: patterns in how an entity behaves over time (transaction rhythm, channel, counterparties, device/access), the “user behaviours” layer that moves monitoring from single-event flags to pattern-of-life risk.

• Transactions: financial activity and its evaluations.

• Alerts: monitoring outputs that need triage.

• Cases: investigations opened off the back of a signal or alert, with an AI-generated summary.

KYT is the legacy integration path. The standalone Know-Your-Transaction client/transaction endpoints (R7) remain available, but the platform is moving to full AI-agent / workflow automation that automates decisions end to end across customer onboarding, transaction screening, transaction monitoring and fraud detection. New integrations should build on workflows; treat the raw KYT client/transaction surface as legacy and prefer submitting transactions into the monitoring workflow.

Data residency, localisation and bring-your-own-database

For transaction screening and monitoring, where the data physically resides is itself a regulatory requirement, not just an integration preference. A number of countries mandate data localisation: customer and payment-transaction data generated in-country must be stored (and often processed) within that country. Cowork is built so that your data always resides in the jurisdiction you are required to keep it in.

Cowork meets this two ways:

• Data residency / localisation by region: in countries where this service is available, customers can select the country/region where their data is stored and processed, so locally-generated data never leaves the required jurisdiction. When your footprint changes, data can be moved to another supported region without losing history or the entity 360.

• Bring your own database (BYODB): customers can also connect their own datastore for storage and processing, so the screening and monitoring workflows run against their data in place, keeping the system of record inside their own environment and jurisdiction, while results (signals, alerts, scores, cases) still attach to the entity 360.

This lets an institution keep each market’s data in its own jurisdiction to satisfy local rules, and underpins the data-protection posture in AI Governance.

Workflows and Decisions

This is the heart of the new platform. AI Agents are deployable, AI-powered workflows, powered by Vyra, that automate multi-step compliance tasks end to end. Rather than you wiring check-thendecide logic by hand, an agent orchestrates the same underlying capabilities the API exposes and automates the decision across four domains:

• Customer onboarding: verify, score, and approve / reject / restrict / escalate.

• Transaction screening: screen parties and transactions before they complete.

• Transaction monitoring: watch behaviour over time and raise signals/alerts.

• Fraud detection: apply detection models to catch fraud in real time.

The platform ships agent families (Customer Onboarding, Transaction Monitoring) built from templates (ID Verification, Address Verification, Business Verification). Crucially, entity approval is itself an AI-agent workflow: once an entity is Created and scored, the onboarding agent applies your configured rules to the score, signals and check results to drive the outcome, escalating edge cases to a human or a case.

Fraud Traps are custom AI models trained on your own data, not generic or static rules. Each Fraud Trap is trained on the customer’s specific data, patterns and realities and is exclusively used by that customer (private to your tenant, never shared). The defining use: when a fraud event occurs, you model that fraud as a Fraud Trap so the platform can detect the same pattern in future activity and across your historical data, and you can fine-tune the model whenever you like to increase its performance. An entity’s transactions and behaviour flow through your Fraud Traps, and matches surface as alerts and signals on the 360. This is the difference from a fixed rule engine: the detection reflects your fraud, learned from your patterns.

Because agents orchestrate the documented API operations, the API and the agents stay consistent: an agent is a packaged, automated sequence of the same calls.

Create a watchlist

Beyond global PEP, sanctions and adverse-media sources, you can maintain your own custom AML watchlist: add targets individually or bulk-upload by CSV (target name, type, risk rating, reason), then retrieve, update and remove entries. Screening runs against your custom watchlist alongside the global lists, so internally known bad actors are caught even when they are not on a public list. See Custom AML Watchlist

AI governance

Because decisions and scoring are AI-driven, Cowork treats AI governance as first-class, aligned to ISO 42001 (AI management system) and Youverify’s responsible-AI posture:

• Explainability: risk scores are weighted and transparent (2.5), and every score can be traced to the factors that produced it.

• Human-in-the-loop: AI-agent workflows escalate edge cases to a human or a case rather than deciding silently; approval rules are configured by you.

• Auditability: activities form an immutable log, and the evidence/confidence model records the basis for each compliance signal.

• Data protection and residency: processing complies with GDPR and regional data-protection regimes (Nigeria, Côte d’Ivoire, Kenya, South Africa, UK and others), under SOC 2 Type II and ISO 27001/27018/42001 controls. Customers control where data lives through bring-your-own-database and region selection, and can move data between supported regions to meet residency rules.