PEP- og sanktionsscreening i Strise (v.3)

Denne artikel beskriver, hvordan Strise udfører screening for PEP (politisk eksponeret person) og sanktioner. Artiklen fremhæver også, hvordan screeningen kan tilpasses via indstillinger, hvordan og hvornår der sendes advarsler, samt væsentlige forbedringer implementeret i v.3 – udført i 4. kvartal 2025.

---

1. Sådan fungerer screening

Begge processer for screening af PEP'er og sanktioner følger et lignende flow:

1. Forbehandling: Dette indebærer rensning af data ved at fjerne accenter, titler, forkortelser for virksomheders selskabsformer osv.
2. Søgning: Der udføres en navnesøgning mod PEP- og sanktionslister for at finde relevante hits.
3. Filtrering: Resultater filtreres baseret på brugerindstillinger, såsom udløb af PEP-/RCA-status, lighedstærskler og udelukkede kilder.
4. Scoring: Der beregnes et vægtet aritmetisk gennemsnit baseret på et sæt konfigurerbare felter, og hits markeres som foreslået falsk eller foreslået sand.
5. Brugerverificering: Brugere kan verificere resultaterne fra trinnet ovenfor.

1.1 Forbehandling

Dette trin normaliserer navnet og aliaser, hvilket sikrer, at mindre variationer i stavning, accenter eller specialtegn ikke forhindrer os i at identificere et potentielt match mod screeninglisterne.

1.2 Søgning

De normaliserede navne og aliaser fra forbehandlingstrinnet fungerer som en omfattende søgeforespørgsel. De PEP- og sanktionslister, der søges i, kan konfigureres i indstillingerne.

Et navn betragtes kun som et match, hvis det opfylder begge følgende betingelser:

1. Match pr. term: Hvert enkelt ord i navnet skal bestå en specifik lighedstest.
2. Samlet match: Navnet som helhed skal opfylde en minimumstærskel for lighed.

Reglen for match pr. term

• 75 %-reglen: En term skal have mindst 75 % lighed med dens tilsvarende term. Vi beregner dette ved hjælp af Damerau-Levenshtein-afstand. Dette kan forenkles til: "For hver 4 tegn i en term er 1 redigering tilladt."
• Undtagelse for korte termer: For meget korte termer (2 eller 3 tegn) tillader vi 1 redigering, selvom dette er under tærsklen på 75 %.

Eksempler:

Reglen for samlet match

Håndtering af manglende navne (delmængdelogik)

• Reglen: Et match er tilladt, hvis det ene navn er en fuldstændig delmængde af det andet. For eksempel kan A C matche A B C (hvor B er et manglende mellemnavn). Ordenes rækkefølge er underordnet.
• Begrænsningen: Algoritmen tillader ikke matches, hvor termer simpelthen er forskellige. A B C vil ikke matche A B D.

Eksempler:

Den samlede lighedsscore

Efter tilpasning af navnene beregner vi en endelig lighedsscore for hele sættet af matchede termer. Det samlede sæt af matchede termer skal have en overordnet lighed, der er lig med eller større end den angivne lighedsscore fastsat af brugeren.

1.3 Filtrering

Resultater fra søgningen bortfiltreres baseret på de definerede indstillinger. De tilgængelige filtreringsmuligheder er:

• Navnets samlede lighedsscore
• En PEP's opbevaringsperiode (hvor længe status er gyldig, efter at en rolle er ophørt)

1.4 Scoring

Når et potentielt hit består vores indledende navnematchningsfiltre, beregner vi en endelig matchscore ved hjælp af et vægtet aritmetisk gennemsnit, udtrykt som en procentdel fra 0 % til 100 %.

Vigtige aspekter af scoringen:

• Hver vægtning kan konfigureres i indstillingerne.
• En komponent ignoreres, hvis datapunktet mangler i Strise-entiteten eller PEP- eller sanktionskilden.
• Et match på SSN fra Strise-entiteten med entiteten fra kilden vil altid overskrive matchprocenten til 100 %.

Se dokumentationen for flere detaljer:

• Vægtning af datafelter i PEP-indstillinger
• Vægtning af datafelter i sanktionsindstillinger

1.5 Brugerverificering

Brugeren kan verificere hvert resultat som sandt eller falsk. Det vil altid være muligt at se oplysninger om ændringerne, f.eks. hvilken bruger der verificerede hittet, hvilken status, på hvilket tidspunkt osv. Denne log kan også downloades som en .csv-fil.

2. Indstillinger

For både PEP- og sanktionsindstillinger er det muligt at påvirke trinene for søgning, filtrering og scoring:

• Søgning: Vælg, hvilke PEP- og sanktionslister der screenes mod.
• Filtrering:
  • Minimum fuzzy-navnematch – styrer, hvor ensartet et navn skal være for at blive flaget.
  • PEP/RCA-opbevaringsperiode – hvor længe en person forbliver en PEP, efter at vedkommendes rolle er ophørt.
• Scoring:
  • Vægtning af datafelter – bestemmer den relative betydning af hvert datafelt.
  • Foreslået sandt match – tærsklen, der bruges til at bestemme, om en score klassificeres som foreslået sand eller falsk.

3. Advarsler

Advarsler sendes, når følgende betingelser er opfyldt:

• De underliggende data for PEP- eller sanktionsdataene opdateres
• Scoringen har klassificeret hittet som foreslået sandt, eller dit team har verificeret hittet som et sandt match (via appen eller API'et)

Verificering af et hit, som dit teams screening ikke foreslog som et sandt match, bringer dette hit ind i overvågning: Det rapporteres som et tilføjet hit ved næste overvågningskørsel, og det udløser advarsler ved dataopdateringer fra da af. Et hit, der allerede var foreslået sandt, overvåges allerede, så verificering af det ændrer intet og genererer ingen duplikeret advarsel.

Advarsler sendes ikke i følgende tilfælde:

• Et hit, der allerede overvåges, verificeres, uanset om det er som et sandt eller et falsk match. Verificering registrerer dit teams beslutning; det er ikke en advarselsudløser i sig selv.
• Dataene for entiteten i Strise ændres.

Andre relevante punkter:

• Der vil blive sendt advarsler for tidligere verificerede hits, uanset om de er bekræftet som sande eller falske, så længe de opfylder ovenstående betingelser.

4. Forbedringer udført i denne version

Oktober-november 2025:

• En tidligere fast grænse for søgeresultater er blevet fjernet. Disse lofter var sat til 10 for PEP og 250 for sanktioner.
• Den nye delmængdelogik håndterer tilfælde, hvor et vilkårligt antal termer mangler i et af navnene, og kasserer navne, der har helt forskellige termer.
• "Reglen for match pr. term" er blevet tilføjet som understøttelse af den nye delmængdematchningslogik.

5. FAQ

Hvor kommer RCA-familierelationer fra?

RCA-relationer (Relative or Close Associate) stammer direkte fra de PEP-/RCA-lister, som leveres af vores dataleverandører (Trapets og Dow Jones). Strise fastslår eller udleder ikke selvstændigt familierelationer.

Hvordan et forkert entitetsmatch kan opstå

Hvis en Strise-entitet matcher et navn på listen, men mangler en fødselsdato til entydig identifikation, kan matchet linke til den forkerte person. Relationsdataene fra kilden er korrekte; problemet ligger i entitetsopløsningen, når fødselsdatoer mangler.

Opsummering

Hvis du ser en uventet RCA-relation, stammer relationstypen fra dataleverandøren og er sandsynligvis nøjagtig for personen på listen – men den Strise-entitet, som den er blevet matchet med, er muligvis ikke den korrekte person.

Har du andre spørgsmål om dette emne? Kontakt os på support@strise.ai.