Indirect matches: see the relative behind an alert

A PEP alert can be about someone other than your client. Your client has never held public office, but her husband is a minister. Her name appears in his profile, and the screening finds it.

The Smart Oversight API now states in the alert which relative of the listed person matched your client, and how the two are related.

What an indirect match is

FATF Recommendation 12 extends the measures for PEPs to their family members. Comparing your client’s name with listed names alone is therefore not enough. Smart Oversight also compares it with the relatives named in each profile, whether a spouse, child, parent or sibling.

When your client’s name matches one of those relatives, the alert is raised on the listed person. This is called an indirect match. The alert then shows the listed person’s profile, and the reviewer reads “John Doe, Minister of Finance” on Jane Doe’s file.

In the API response

An API key with the alerts:read scope reads an alert by its identifier.

GET /v2/alerts/alr_66f1a2b3c4d5e6f708194000
Authorization: Bearer <your API key>

For a hit on a sanctions or PEP list, the match object describes the listed person with name, aliases, dates_of_birth, places_of_birth, nationalities and positions. A PEP hit adds occupations and description, a sanctions hit sanction_programs. The new field is match.indirect. The extract below uses fictional data.

{
  "object": "alert",
  "id": "alr_66f1a2b3c4d5e6f708194000",
  "client": "cli_66f1a2b3c4d5e6f708192a3b",
  "media": "PEP_LIST",
  "targets": ["PEP"],
  "status": "OPEN",
  "resolution": "UNRESOLVED",
  "match": {
    "type": "pep_entity",
    "name": "John Doe",
    "aliases": ["Johnny Doe"],
    "dates_of_birth": [
      { "value": "1962-03-14", "precision": "day", "raw": "14/03/1962" }
    ],
    "places_of_birth": ["Springfield"],
    "nationalities": ["Freedonia"],
    "positions": ["Minister of Finance"],
    "occupations": ["Politician"],
    "description": ["Member of the national government since 2019"],
    "indirect": { "relation": "spouse", "name": "Jane Doe" }
  },
  "created_at": "2026-09-14T08:12:40.000Z",
  "resolved_at": null
}

Here, Jane Doe is the spouse of John Doe. name is the relative’s name as written in the profile, and relation gives their link to the listed person: spouse, child, parent or sibling.

When indirect is null, your client’s name matched the listed person directly. When the field is missing, the type of match is not known. That is the case for hits recorded before this change. The API never passes off an unknown case as a direct match, so a missing field should not be read that way.

The same match object appears in GET /v2/alerts and GET /v2/clients/{ref}/alerts. Both lists can be filtered by status (OPEN, DONE, VALIDATED) and by media (SANCTIONS_LIST, PEP_LIST, INTERNET_SCREENING). The webhook sent when a decision is made on an alert carries the field too.

Internet search works differently. Its hits have no match object and give the page address in page_url. Indirect matches therefore only concern the lists.

Showing it in your CRM

In your integration, each case gets its own label.

function matchLabel(match) {
  if (!('indirect' in match)) {
    return `Possible match on ${match.name}. Match type not reported.`;
  }
  if (match.indirect === null) {
    return `Direct match on ${match.name}.`;
  }
  const { relation, name } = match.indirect;
  return `Indirect match: ${name}, ${relation} of ${match.name}.`;
}

Put that line at the top of the alert card, above the listed person’s positions. The reviewer then reads the relationship before the profile. When the field is missing, show the profile alone and let the reviewer check the source list.

Recording the decision

The decision goes back through POST /v2/alerts/{id}/review, with a status, a resolution and, if you wish, a comment. Choose NOT_RELATED_TO_CLIENT when the relative named in the profile is not your client, and TRUE_RELEVANT or TRUE_NOT_RELEVANT when they are.

The comment is added to the alert’s existing one without replacing it. Note the relationship there.

Setting an alert to VALIDATED requires the alerts:validate scope. A decision made in a team member’s name can only be validated if that person is your MLRO. Decisions made through the API carry a name explains how to record who made the decision.

The integrations page lists what the Smart Oversight API covers. Our guide to connecting KYC & AML screening to your CRM shows how to bring these endpoints together in one integration.