This page explains how Global RADAR disposes of a sanctions alert, what the model is allowed to decide on its own, what always reaches a human, and how you supervise and evidence the whole thing to an examiner.
Most screening vendors publish outcomes. Fewer publish method. We publish method because a managed clearing service is a regulated control operating inside your programme, and you cannot adopt a control you cannot describe.
The four stages
Stage 1 · Screening
10,000
subjects screened against sanctions, PEP and watchlist data
Stage 2 · Matching
1,000
potential matches raised by name, alias and identifier matching
Stage 3 · Clearing
10
alerts survive risk ranking and analyst review, and reach your team
Stage 4 · Decision
1
true match requiring a documented decision by your compliance officer
Illustrative ratios showing how alert volume falls across the four stages. Your own ratios are established during the pilot and reported to you monthly.
Stage 1. Screening
Subjects are screened against sanctions, PEP, adverse media and watchlist data on a daily list update cycle. Screening scope, list selection and refresh frequency are set in your service schedule, not chosen by us unilaterally.
Stage 2. Matching
Name, alias, identifier and jurisdiction matching raises every potential hit. This stage is deliberately wide and nothing is suppressed here. A narrow matching stage hides risk. The volume it creates is absorbed by the engine at the ranking stage, which is the entire point of automated clearing.
Stage 3. Clearing
Each potential match is scored on genuine risk using name similarity, contextual data, jurisdiction and customer history, and the queue is ordered so the alert that matters is at the top. Matches that meet the agreed clearing criteria are disposed of with a recorded reason code. Everything else is queued for human review by your own analysts or by your accredited delivery partner. It is never discarded.
Stage 4. Decision
What survives that review reaches your compliance team as a true match with the evidence file attached. The decision, and the regulatory obligation attached to it, remains yours.
What the Agent decides, and what it does not
The AI Alert Clearing Agent sits between the sanctions matching engine and the human review queue. It performs identity resolution on each alert and routes it to a downstream state. It does not replace human review, and it never finalises a regulatory determination.
Every alert is assigned one of three outcomes:
- Obvious False Positive. Cleared on well defined structural or naming rule mismatches: name order, first initial and surname, gender prefix conflict, partial single names, entity versus individual where a corporate suffix evidences the difference, and mismatches between entity types (individual, entity, vessel, aircraft).
- False Positive. Cleared only where the names are an exact match and secondary identifying information, meaning date of birth, address, nationality, passport or IMO, definitively proves a different party.
- Possible True Match. Not cleared. Escalated to a human analyst, and from there to you.
The Agent has no ability to make external calls, browse, send communications, modify screening lists or take any action other than returning a decision. It operates from a fixed, version controlled system prompt that end users and screening subjects cannot influence.
What always reaches a human
The decision logic is deliberately asymmetric. It is built to escalate rather than to clear.
- Any uncertainty, any missing critical data, any conflicting information must be categorised as a Possible True Match. This is a rule in the prompt, not a tendency of the model.
- Any Possible True Match escalates the whole case. Once any alert in a case carries that status, the only outcome the platform permits is Escalate. The case moves to Customer Action and can only be updated by you.
- An exact name match is never cleared on the name alone. It can only be disposed of where secondary identifiers positively establish a different party.
- Vessels are not cleared without IMO evidence. A vessel alert is only discounted where the vessel name and IMO number fail to correspond across the document and the alert.
- Entity type is not assumed. Where the documents do not make it clear whether a name is a person, a company, a vessel or an aircraft, the alert cannot be cleared on entity type.
- Aliases are always checked. Sanctioned parties routinely use aliases when buying financial products, so full name and alias review is mandatory before any disposal.
The standing instruction across the whole process is the simplest one: if there is any uncertainty, the name is not cleared.
How the service fails safe
The failure modes are designed to produce escalation, never silent clearance.
- If the Agent returns a response that does not parse, contains an unknown outcome, or is missing a required field, the decision is not applied and the case stays in the Alert state for human handling.
- If the Agent service is unreachable, the case stays in the Alert state. The system falls back to legacy behaviour, not to clearance.
- Analysts can override any Agent outcome on any case. The original decision is preserved as an immutable audit record rather than overwritten.
How you supervise the work
Outsourcing the work does not outsource the obligation. Your compliance programme remains the system of record, and the introduction of the Agent does not change the regulated decision maker.
- A decision record for every alert. Every disposal carries a structured rationale, the risk factors identified, and a confidence rating. Nothing is disposed of silently.
- Full override rights. Analysts on your side and ours can override any outcome. The original decision survives as an immutable record.
- Independent sampling. You draw your own sample of cleared alerts, at a rate you set, and re-review them yourself. We do not choose the sample.
- Run it alongside your current process. The Agent state can be enabled per environment, so you can run Agent and non-Agent workflows side by side and compare outcomes on the same population before anything is promoted to production.
The audit trail, and reproducibility
Every Agent invocation writes a record containing the model identifier, the prompt version, the input payload, the raw model response, the parsed outcome, the confidence score, the risk factors, the rationale and the resulting state transition. Records are retained alongside the case and are available to compliance reviewers and auditors through the existing audit interface.
Any historical decision can be reproduced. Replaying the recorded input through the recorded prompt version returns the recorded outcome. An examiner asking why a specific alert was cleared eighteen months ago gets an answer, not an explanation of why the answer is unavailable.
Model governance and change control
- The system prompt is fixed and version controlled. It is not influenced by end users or by the content of screening records.
- The prompt version is recorded on every decision, so the logic that produced any given outcome is identifiable after the fact.
- Agent state is opt in and can be disabled per environment. Disabling reverts to legacy behaviour with no impact on the screening engine, the list data or case history.
- The upstream matching algorithm, the screening lists and the list ingestion process are unchanged by the Agent. It evaluates alerts; it does not generate them.
- Filter and exclusion changes are forward looking only. They apply to alerts generated after deployment and are verified with a new test case, never against historical alerts.
Where the AI runs, and what happens to your data
This section exists because it is the first thing a vendor due diligence reviewer asks.
- Inference provider. Amazon Web Services Bedrock, using a model from the Amazon Nova foundation model family. AWS is the sole vendor in the inference path. There is no direct engagement with any other model vendor.
- Retention and training. The model is invoked statelessly. No customer data is used to train, fine tune or otherwise modify the model, consistent with Bedrock’s published zero retention and no training terms.
- Residency. All inference requests are processed in the AWS us-west-2 region. Bedrock is region scoped and inference requests do not fail over across regions.
- Credentials. The Agent authenticates through an AWS IAM execution role. No static API keys or long lived secrets exist anywhere in the deployment. Credentials are short lived, rotated automatically on every invocation, and scoped to model invocation only.
- Transport. Encrypted in transit at TLS 1.2 or above.
- Subprocessors. Two, in total: Amazon Web Services for inference and Rackspace for platform hosting. Formal DPA documentation covering both is available on request.
- Data scope. The Agent processes only data already authorised for sanctions screening under your existing contract. No new categories of personal data are collected, and no new egress path is introduced.
- Prompt injection. Inputs are structured screening records rather than free form instructions, instructional content is isolated from data content, and the strict output schema limits the effect of anything injected.
Validated performance
A 1,000 name validation run was completed in a controlled non-production environment in April 2026. Measured against the same population processed without the Agent:
- 47.4% reduction in manual workload. Fewer cases reached a human reviewer.
- 98.2% reduction in raw, uncategorised alerts. Alerts arrive categorised rather than raw.
- Clearance rate improved from 94.3% to 97.0%.
- Escalated cases were routed to a targeted Investigate state carrying a rationale, rather than into a generic alert queue.
The service runs today for specialty insurers and banks operating to Lloyd’s of London market standards, delivered alongside partners including NTT DATA, Alchemy London Market and Buckhill.
Validating the service before you rely on it
The service is designed to be tested on your own data before it carries any of your obligation. A pilot, run over 30 to 90 days and scoped to your volume, puts your live alert queue through the full process and produces:
- Your actual disposal rate, not an industry average
- The decision record for every alert cleared during the period
- A sample you select and re-review yourself
- Measured turnaround against the proposed service levels
- A side by side comparison against your current non-Agent workflow on the same population
You keep the output whether or not you proceed.
Request the full methodology pack
Detailed clearing criteria, threshold documentation, DPA documentation and validation evidence are provided under NDA to institutions evaluating the service, and to their auditors.
Request the methodology pack
Hosting, data residency, subprocessors and our attestation position are set out in full on the trust and security page.
Back to Managed Sanctions Alert Clearing as a Service
Regulatory guides
Plain English explainers on the obligations behind sanctions screening, each written from primary sources and dated:
