PEP- og sanktionsscreening i Strise (v.3)Kopiér link til overskriften

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 advarsler sendes, samt væsentlige forbedringer implementeret i v.3 – udført i 4. kvartal 2025.

---

1. Sådan fungerer screeningKopiér link til overskriften

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 ekskluderede 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 ovenstående trin.

1.1 ForbehandlingKopiér link til overskriften

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øgningKopiér link til overskriften

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 om match pr. termKopiér link til overskriften

• 75 %-reglen: En term skal have mindst 75 % lighed med den tilsvarende term. Vi beregner dette ved hjælp af Damerau-Levenshtein-afstand. Dette kan forenkles som: "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 om samlet matchKopiér link til overskriften

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 match, 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 samlet lighed, der er lig med eller større end den angivne lighedsscore fastsat af brugeren.

1.3 FiltreringKopiér link til overskriften

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

• Navnets samlede lighedsscore
• Opbevaringsvarigheden for en PEP (hvor længe statussen er gyldig, efter at en rolle er afsluttet)

1.4 ScoringKopiér link til overskriften

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 BrugerverificeringKopiér link til overskriften

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. IndstillingerKopiér link til overskriften

For både PEP- og sanktionsindstillinger er det muligt at påvirke søge-, filtrerings- og scoringstrinnene:

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

3. AdvarslerKopiér link til overskriften

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

Advarsler sendes ikke i følgende tilfælde:

• Et PEP- eller sanktionshit verificeres via appen eller API'et. Verificering af et hit registrerer dit teams disposition og sender ikke i sig selv en advarsel. Hvis du integrerer via API'et, kan du abonnere på entity.disposition.created-webhook-hændelsen for at få besked, når et hit verificeres.
• Dataene for entiteten i Strise ændres.

Andre relevante punkter:

• Der sendes 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 versionKopiér link til overskriften

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 om match pr. term" er blevet tilføjet som understøttelse af den nye logik for delmængdematchning.

5. FAQKopiér link til overskriften

Hvor kommer RCA-familierelationer fra?Kopiér link til overskriften

RCA-relationer (Relative or Close Associate) stammer direkte fra PEP/RCA-listerne leveret af vores dataleverandører (Trapets og Dow Jones). Strise bestemmer eller udleder ikke selvstændigt familierelationer.

Hvordan et forkert entitetsmatch kan opståKopiér link til overskriften

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.

OpsummeringKopiér link til overskriften

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, 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.