> ## Documentation Index
> Fetch the complete documentation index at: https://docs.korint.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Compliance & sanctions screening

> How Korint screens customers and companies against sanctions, asset-freeze, and politically-exposed-person watch-lists.

Insurance distributors are legally required to check that the people and companies they do business with are not subject to financial sanctions or asset-freeze measures, and to apply enhanced diligence to politically exposed persons. Korint automates this obligation by continuously screening your book against the relevant regulatory watch-lists and raising alerts that a compliant user must review.

Screening covers two families of lists:

* **Asset-freeze and sanctions lists** (*gel des avoirs*) — individuals and entities whose assets are frozen under national or international measures.
* **Politically-exposed persons (PPE)** — people holding, or connected to, prominent public functions, sourced from both national and international lists.

<Note>
  This is **regulatory screening**. It is distinct from document fraud detection and from document validity checks, which look at the documents themselves rather than at who the customer is. Screening asks "is this person or company on a watch-list?", not "is this document genuine and complete?".
</Note>

***

## What gets screened

Screening targets both the people and the companies attached to your portfolio:

* **Individuals** are matched on their name together with their date of birth, which sharpens matching and reduces false positives on common names.
* **Companies** are matched on their name together with their registration identifiers.

When a candidate match is found, Korint records it as a compliance **alert** linked to the check. Alerts start life unacknowledged and remain visible until a compliant user reviews them.

***

## How screening runs

Screening is not a one-off check at onboarding — it runs continuously so that a customer who becomes sanctioned *after* being onboarded is still caught.

<Steps>
  <Step title="Initial check">
    When a customer or company enters the portfolio, Korint creates a compliance check and screens it against the watch-lists. Any candidate matches become alerts.
  </Step>

  <Step title="Daily re-screening of the book">
    A daily batch re-screens the existing portfolio against the current lists, so a person who is added to a sanctions list later is flagged even though nothing changed on their record.
  </Step>

  <Step title="Daily alert synchronisation">
    A separate daily job pulls in newly published alerts, looking back over roughly the last two days to catch list updates without re-scanning everything from scratch.
  </Step>

  <Step title="Review and acknowledgement">
    Matches surface as alerts. A compliant user reviews each alert and acknowledges it, creating a clear record of who assessed the match and when.
  </Step>
</Steps>

***

## Screening providers

Screening runs through a **pluggable provider**, so the same workflow and the same alert experience apply regardless of how checks are actually performed. Two providers are available:

<CardGroup cols={2}>
  <Card title="Efficiale" icon="shield-check" href="/concepts/integrations/efficiale">
    Automated screening against the vendor's watch-lists. Runs the initial check, the daily re-screening of the book, and the daily synchronisation of new alerts.
  </Card>

  <Card title="Manual" icon="user-pen" href="#screening-providers">
    Brokers record the checks they perform themselves. Suitable where a partner runs screening outside Korint or is not yet integrated with an automated vendor.
  </Card>
</CardGroup>

<Note>
  The provider is selected per tenant. With the **manual** provider, the automated batch re-screening and new-alert synchronisation do not run — the compliant user is responsible for performing and recording checks. With **Efficiale**, those daily jobs run automatically.
</Note>

***

## Alerts and acknowledgement

Every candidate match becomes an alert attached to its compliance check. Alerts are the working surface for your compliance team:

* New matches appear as **unacknowledged** alerts and stay visible until reviewed.
* A compliant user **acknowledges** an alert once they have assessed whether it is a genuine match or a false positive.
* Alerts can be acknowledged individually, for all checks on a given entity, or across a set of checks — so a reviewer can clear a customer in one action once they have made their determination.

This acknowledgement trail is what demonstrates, for audit and regulatory purposes, that every match raised against your portfolio was seen and assessed by a responsible person.
