How It Works?
Individual AML Screening evaluates a person against Shufti's connected watchlists and returns every record that resembles them, each with a match score you can act on. This page explains the full pipeline: how you search, what you search against, how matches are scored, and how results are monitored and resolved.
The screening pipeline
Every screening follows the same five stages:
- Collect the subject's details: name (required) and, ideally, date of birth, plus any optional refining parameters.
- Select the data sources: either pick categories directly or apply a saved search profile.
- Search and score: the name-matching engine compares the input against each source and assigns every record an AML Match Score.
- Return results: records at or above your match threshold are returned in the response; the rest are suppressed.
- Resolve and monitor: review matches through case management, apply a decision, and optionally enroll the subject in ongoing monitoring.
Screening modes
AML screening can source the subject's details in two ways:
| Mode | How details are supplied |
|---|---|
| Search-based | Name and date of birth are provided by the end user or merchant via the API and searched against AML data sources. |
| Document-based | Name and date of birth are extracted directly from a document supplied by the end user. |
OCR-based extraction
Document-based screening relies on OCR. It only works alongside services that include OCR, such as Document Verification, Document Two Verification, and Address Verification. See the process_from_document parameter in Onsite Integration.
Search options
You control which data sources a screening runs against in one of two ways.
Search by Databases
Shufti's AML data sources span 4,000+ global watchlists, covering millions of high-risk entity profiles across 240+ countries and territories, all drawn from reputable international and local databases. When searching by database, you select which sources to screen against from these categories:
- Sanctions
- Warnings and Regulatory Enforcement
- PEPs (Politically Exposed Persons)
- PEP Level 1
- PEP Level 2
- PEP Level 3
- PEP Level 4
- Fitness & Probity
- Adverse Media
- Insolvency
- Special Interest Person (SIP)
- Special Interest Entity (SIE)
Search by Profile
A search profile is a custom, reusable set of data sources. Search profiles are created and managed in AML Settings and let you fix the exact scope of a check in advance. When building a search profile, sources are grouped under three headings, each with its underlying sources individually included or excluded:
- PEP: PEP Level 1, PEP Level 2, PEP Level 3, and PEP Level 4.
- Warnings and Regulatory Enforcement: Fitness & Probity, Regulatory Enforcements, Special Interest Persons (SIP), Special Interest Entities (SIE), and Insolvency.
- Sanctions: underlying sanctions sources that can be filtered by country.
At search time, the request carries a Search By key. You either choose Select Databases Manually and pick categories directly, or choose Use Search Profile, which reveals a dropdown of your preconfigured search profiles to screen the subject against. Using a saved search profile gives you consistent, repeatable checks.
Search parameters
These are the parameters that drive an Individual AML screening. Full Name is the foundation of every search; the rest refine, filter, or organize results. For request formats and limits, see Onsite and Offsite.
| Parameter | Required | Description |
|---|---|---|
| Full Name | Yes | Primary identifier and the basis of every search. Carries the highest weight in scoring. |
| Date of Birth | No | Supporting identifier that distinguishes people with similar names and improves precision. |
| Unique Identifier | No | Passport, national ID, or registry number. Does not affect the score; promotes records with a matching identifier to the top of results. |
| Biometric Screening | No | Optional facial image used for a biometric comparison alongside name and DOB matching. The API key remains face. |
| Country(s) | No | Pre-search filter by country or nationality. Filters out non-matching records before scoring, with no effect on the score itself. |
| Search By | Yes | Sets the data scope: select databases manually, or use a saved search profile. |
| Custom Risk Engine | Yes | The risk scoring engine applied to results. If none is selected, the default engine is applied. |
| Match Score | No | Minimum match threshold, set with a 0 to 100 slider. An Exact Match checkbox sets the score to 100. |
| Enable Ongoing AML? | No | Enables continuous re-screening so the subject is monitored against database changes over time. |
| Enable Ongoing Adverse Media? | No | Available only when Adverse Media is among the selected databases. Enables continuous adverse media monitoring. |
| Enable AI Compliance Co-Pilot? | No | Enables AI-assisted review of results. Additional subject data is passed through the context key. |
| Additional Configurations | No | Search for Relatives & Close Associates (RCA), and Search for Aliases & Alternate Names. |
Full Name
Full Name is the primary and mandatory parameter. The engine evaluates name similarity using phonetic analysis, alias resolution, transliteration, and cultural name-variation handling, so spelling differences, alternative forms, and cross-jurisdictional representations are all accounted for. As the core identifier, name carries the greatest weight in scoring.
Date of Birth
DOB is a supporting parameter. When provided, it differentiates between people who share similar names, increasing confidence and reducing ambiguity. It is not mandatory, but supplying it significantly improves reliability, especially for common names or records spanning multiple jurisdictions.
Unique Identifier
A specific identification number, such as a passport number or national ID, used to narrow the search toward a specific subject. It does not affect the match score. Instead, after scoring, records whose identifier matches or closely aligns with the value provided are promoted to the top of the results, while others remain visible but ranked lower.
Biometric Screening
An optional facial image of the subject, submitted as a biometric input. Shufti compares the image against records in the connected AML databases and returns biometric match results alongside the standard output, adding a visual verification layer to name- and DOB-based matching. The image is submitted through the face field.
Country(s)
The country filter narrows results to records associated with one or more selected countries, removing unrelated jurisdictions and reducing noise.
The country filter is a pre-search filter only. Records that do not match the selected country never appear in results; records that pass through are scored on name and DOB as usual, so the filter has no effect on the match score itself.
Search By
Search By sets the scope of data the subject is screened against. You either choose Select Databases Manually and pick categories directly, or choose Use Search Profile and select one of your preconfigured search profiles. See Search by Databases and Search by Profile for the available sources.
Custom Risk Engine
The risk engine applies your configured scoring criteria to the returned results. It is mandatory: if no custom engine is selected, the default risk engine is applied automatically. For configuration details, see the Custom Risk Scoring Engine.
Match Score
Match Score sets the minimum score a record must reach to be returned, configured with a 0 to 100 slider. A separate Exact Match checkbox is available; when enabled, the score is set to 100 by default. For how scores are calculated and the recommended threshold, see AML Match Score.
Enable Ongoing AML
When enabled, the subject is enrolled in continuous re-screening, so any future changes across the connected databases are surfaced without resubmitting the check. See Ongoing monitoring.
Enable Ongoing Adverse Media
This option appears only when Adverse Media is among the databases selected for screening. When enabled, the subject is continuously monitored for new adverse media coverage in addition to standard ongoing AML updates.
AI Compliance Co-Pilot
Enabling the AI Compliance Co-Pilot adds an AI-assisted review layer over the screening results. Additional subject information can be passed into the request to give the Co-Pilot richer data for its assessment, passed through the context field. When AML runs alongside identity verification and KYC, this data can be enriched with details extracted during KYC, such as document number, address, and occupation, combined with anything the merchant supplies. See the AI Compliance Co-Pilot section for what it returns.
Additional Configurations
Two optional toggles extend the scope of a search:
- Search for Relatives & Close Associates (RCA): extends the search to relatives and close associates of the subject. People who are not themselves listed may still pose indirect risk through shared finances, business relationships, or personal ties. RCA coverage brings beneficial-ownership structures, family-held assets, and associate networks into scope.
- Search for Aliases & Alternate Names: screens the subject against aliases, maiden names, transliterations, and name variations across all connected databases. Shufti applies fuzzy matching and transliteration logic so that non-exact variations are still captured, reducing false negatives.
Data sources and categories
The following categories are supported across Shufti's AML databases.
| Category | Description |
|---|---|
| Sanctions | Penalties or restrictions imposed by authorities on individuals, organizations, or countries for violating laws or international norms. View source list |
| Warnings and Regulatory Enforcement | Alerts to rule violations, plus penalties or legal actions for non-compliance with laws and regulations. View source list |
| Fitness and Probity | Evaluation of an individual's or entity's competence, skills, integrity, and ethical conduct in financial services. View source list |
| Adverse Media | Negative or damaging information about individuals, organizations, or entities that can pose significant risk. |
| Politically Exposed Person (PEP) | Individuals entrusted with prominent public functions, and those closely connected to them, who present a higher risk of involvement in bribery or corruption. View source list |
| PEP Level 1 | High-risk PEPs: state and government executives, military/judicial/law-enforcement leaders, parliament officials, prominent political party figures. View source list |
| PEP Level 2 | Medium-high risk PEPs: senior state/military/law-enforcement officials, high-ranking civil servants, religious and state-agency leaders, ambassadors, diplomats, and commissioners. View source list |
| PEP Level 3 | Medium-risk PEPs: senior management in government-owned businesses, state organization board members. View source list |
| PEP Level 4 | Low-risk PEPs: senior officials and employees in international bodies, state/district assembly members. View source list |
| Special Interest Person (SIP) | Individuals presenting a heightened level of risk due to suspected or confirmed involvement in criminal activity. View source list |
| Special Interest Entity (SIE) | Companies or organizations presenting a heightened level of risk due to suspected or confirmed involvement in criminal activity. View source list |
| Insolvency | Companies and organizations that are unable to pay the debts they owe or have been declared bankrupt by a judicial process. View source list |
Adverse media screening
Shufti's adverse media screening searches a network of 50,000+ integrated global sources, including news outlets, regulatory publications, court records, and watchlist databases. The engine applies sentiment analysis to each piece of coverage, scoring its tone on a scale from -3 to +3: -3 severely negative, -2 moderately negative, -1 negative, 0 neutral, and +1 to +3 increasingly positive. This lets reviewers prioritise the most damaging coverage rather than treating every mention equally.
Searches run against keywords derived from FATF's 21 designated predicate offences for money laundering, supplemented by the 6th EU Anti-Money Laundering Directive (6AMLD), organized into these categories:
- Financial Crimes: money laundering, fraud, bribery, corruption, tax evasion, embezzlement, sanctions evasion, counterfeiting, insider trading.
- Organized Crime & Trafficking: drug, arms, and human trafficking, migrant smuggling, sexual exploitation, racketeering, smuggling of stolen goods.
- Terrorism & Proliferation: terrorist financing, proliferation financing, extremism, weapons of mass destruction.
- Violent & Serious Crimes: murder, kidnapping, hostage-taking, robbery, theft.
- Regulatory & Legal Violations: court convictions, criminal investigations, enforcement actions, sanctions violations, regulatory breaches, license revocations.
- Environmental & Cybercrime: illegal trafficking of natural resources and protected species, cybercrime, hacking, ransomware, data breaches (introduced under 6AMLD).
- Reputational & Political Risk: PEPs, abuse of power, conflict of interest, government misconduct, links to shell companies or offshore structures.
The name-matching engine
At the core of scoring is a proprietary name-matching engine built for global AML screening. Its goal is reducing false positives, matches that look plausible but refer to different people, without missing genuine hits obscured by spelling, cultural differences, or data quality. It handles four categories of name variation:
- Phonetics and diacritics: names that sound identical but are spelled differently. José Hernández and Jose Hernandez, or Mohamed and Muhammad, are treated as equivalent.
- Structural and spacing differences: hyphenation, multi-part names, suffixes (Jr., II), and spacing. Kim-Jong Un and Kim Jong Un are treated as structurally identical.
- Error and alias handling: OCR, legacy-system, and manual-entry errors are normalised, and known aliases, AKAs, and transliteration variants are linked into one subject profile.
- Cultural name variations: East Asian family-name-first names, Arabic patronymics and honorifics, and other non-Western structures are handled natively rather than treated as errors.
AML Match Score
The AML Match Score is a value between 0% and 100% generated for every returned record. It quantifies how closely the subject's details, primarily name and date of birth, match a record in Shufti's sanctions, PEP, or watchlist databases.
Match threshold
The match threshold is a configurable minimum cut-off. Only records scoring at or above it are returned; records below it are suppressed entirely.
- Set it too high and you risk missing genuine matches where data varies slightly across sources.
- Set it too low and you return loosely related results, burdening compliance teams.
Recommended threshold A threshold of 85% is recommended as the optimal balance between accuracy and coverage. The threshold is configurable per screening, so you can control sensitivity for each individual check rather than only globally.
Worked examples
These examples illustrate how the engine treats different kinds of name variation, and the role a matching DOB plays.
| Search input | DOB provided | How the engine treats it |
|---|---|---|
| Hajjaj Bin Fahad Al Ajmi | No | Exact match on every token. A strong, high-confidence match on name alone. |
| Hajjaj Bin Fahd Al Ajni | Yes | Minor phonetic spelling variants (fahad/fahd, ajmi/ajni) are still recognised as the same name. A matching DOB adds further confidence. |
| Hajjaj Bin Al Ajmi | Yes | A name token (the middle name Fahad) is missing, so name confidence is lower. The result may fall closer to the threshold and warrant manual review. |
Two things to note from these examples:
- Name similarity is the primary driver. The closer the name match, the higher the confidence. A partial name match lowers confidence and may push a result below the threshold.
- DOB is a supporting signal. A matching DOB increases confidence and helps separate people with similar names, but it does not by itself rescue a weak name match.
Multilingual and transliteration matching
Names transliterated from Arabic, Persian, Urdu, and other scripts into Latin characters may appear under multiple valid spellings, none matching the input exactly. A keyword search would miss most of these; the phonetic algorithm resolves them by matching on sound rather than spelling. For supported languages, see AML Supported Languages.
Ongoing monitoring
Watchlists and regulatory requirements change constantly. Ongoing monitoring keeps enrolled records current with real-time updates, reducing the risk of missed alerts from stale data.
How monitoring works
The monitoring engine runs automatically in the background, re-screening active profiles against the latest AML databases at a configurable frequency. The default interval is 15 minutes, so status changes are detected with minimal delay and no manual intervention. When a subject is added to or removed from any watchlist, the system triggers an alert.
Alerts can be delivered through one or more channels:
- Webhook: automated event notifications sent to your integrated URL.
- Back Office: notifications surfaced in the Shufti merchant dashboard.
- Registered Email: alerts sent to your registered address.
Monitoring alert triggers
| Event | Description |
|---|---|
| New information found | The entity appears in a watchlist or database they were not previously associated with. |
| Existing information updated | Details for the entity on an existing list have been modified or revised. |
| Entity added or removed from a source | The entity has been newly added to, or delisted/removed from, a watchlist they are tracked against. |
Adverse media monitoring
Alongside watchlist monitoring, Shufti continuously scans for adverse media about the subject. If new adverse media is detected, the status is updated and an alert is sent automatically.
Enabling ongoing monitoring
Set ongoing = 1 to enable watchlist monitoring and ongoing_adverse_media = 1 for adverse media monitoring. Both are available on production accounts only.
Compliance tooling
AI Compliance Co-Pilot
The AI Compliance Co-Pilot is an AI-powered review layer that performs an automated first-line review of flagged profiles. It evaluates matches against sanctions, PEP, and adverse media sources and returns a structured, evidence-backed risk summary, helping teams manage alert volume. It can be enabled while you run a screening or applied afterwards, and it is also available in ongoing monitoring.
When you enable the Co-Pilot during a screening, a form appears so you can supply context about the subject. None of these fields are mandatory; the more you provide, the sharper the assessment. For an individual, the context is grouped as:
| Group | Fields you can supply |
|---|---|
| Identity | Full name, date of birth, image file, nationality, occupation, industry, identification number, passport / national ID / Emirates ID, and similar. |
| Relationships | Parents, siblings, spouse. |
| Address | Residence. |
You can also configure how the Co-Pilot runs:
- Records analysed per screening: any value from 5 to 50, in steps of 5.
- Use IDV data for context: turn on "Use Identity Verification (IDV) data for AI Compliance context?" to let the Co-Pilot reuse data already captured during identity verification. Only successfully extracted and verified fields are shared; anything not captured is excluded automatically. Selectable fields are face image, full name, date of birth, document number, nationality, gender, and full address.
- Co-Pilot in ongoing monitoring: when ongoing monitoring is enabled, you can have the Co-Pilot re-run on cases that receive updates, at one of four frequencies: instantly (on a new hit or update), daily, weekly, or monthly.
- Risk-change alerts: notify analysts when the Co-Pilot detects a risk change, by email or webhook.
Advisory only The Co-Pilot does not make final determinations or define AML policy. All outputs are advisory and subject to human review and override.
Custom Risk Scoring Engine
The Custom Risk Scoring Engine lets you define your own risk-assessment criteria instead of relying on a fixed model. Risk configuration defines threshold ranges across three levels, Low, Medium, and High, with a decision assigned to each level.
Scoring is distributed across three components:
| Component | What it scores |
|---|---|
| Country | One or more countries assigned a custom risk score |
| Category | AML watchlist categories scored by the risk they carry in your context |
| Criminal Records | Entities convicted by a court, and entities with a criminal penalty enforced |
Each component is assigned a weightage that determines its proportional contribution, and the three weightages must total 100%, keeping the model balanced and complete.
Risk decision is separate from the verification decision The detected risk level and its associated risk decision are returned separately from the main verification decision (accepted or declined). Treat the risk level as a parallel signal for your compliance workflow rather than the verification outcome itself.
Case Management
Case Management provides a structured, fully auditable workflow for reviewing and resolving screening results.
- Case assignment: every screening result becomes a case, assigned to the admin by default and reassignable to secondary team members. Assignees are notified by email and in the Back Office.
- Comments: added at the report level (whole report) or entity level (a specific entity), with support for tagging team members and attaching files.
- Activity logs: a complete history per case: creation time, report-viewed events, assignee changes, and status changes with timestamps.
- Case resolution: every case opens with a status of potential match by default. Assignees review the case and update the status to mark it a true positive or false positive.
- Alerts and notifications: assignees are notified instantly, in the Back Office and by email, on assignment and unassignment.
Only users with the appropriate role and permissions can update a case's resolution status. All status changes are recorded in the Activity Log for full auditability.