> For the complete documentation index, see [llms.txt](https://doc.youverify.co/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://doc.youverify.co/monitoring-model.md). # 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](/api-reference/api-reference/quick-check/aml-services-anti-money-laundering.md) #### 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. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://doc.youverify.co/monitoring-model.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.