Screening for PEP og Sanksjoner i Strise (v.3)

Denne artikkelen beskriver hvordan Strise utfører Screening for PEP (politisk eksponert person) og Sanksjoner. Artikkelen belyser også hvordan screeningen kan tilpasses via innstillinger, hvordan og når varsler sendes, samt viktige forbedringer implementert i v.3 – utført i Q4 2025.

---

1. Slik fungerer screening

Begge prosessene for screening av PEP og Sanksjoner følger en lignende flyt:

1. Forhåndsbehandling: Dette innebærer å rense data ved å fjerne aksenter, titler, forkortelser for selskapsformer osv.
2. Søk: Det utføres et navnesøk mot PEP- og sanksjonslister for å finne relevante Treff.
3. Filtrering: Resultatene filtreres basert på Bruker-innstillinger, som utløp av PEP/RCA-Status, likhetsterskler og ekskluderte kilder.
4. Scoring: Et vektet aritmetisk gjennomsnitt beregnes basert på et sett med konfigurerbare felter, og Treffene markeres som foreslått usant eller foreslått sant.
5. Brukerverifisering: Brukere kan verifisere resultatene fra steget over.

1.1 Forhåndsbehandling

Dette steget normaliserer navnet og aliaser, noe som sikrer at mindre variasjoner i staving, aksenter eller spesialtegn ikke hindrer oss i å identifisere en potensiell match mot screeninglistene.

1.2 Søk

De normaliserte navnene og aliasene fra forhåndsbehandlingssteget fungerer som en omfattende søkespørring. Hvilke PEP- og sanksjonslister det søkes mot, kan konfigureres i innstillingene.

Et navn anses som en match kun dersom det oppfyller begge følgende vilkår:

1. Match per term: Hvert enkelt ord i navnet må bestå en spesifikk likhetstest.
2. Samlet match: Navnet som helhet må oppfylle en minimumsterskel for likhet.

Regelen for match per term

• 75 %-regelen: En term må ha minst 75 % likhet med sin tilsvarende term. Vi beregner dette ved hjelp av Damerau-Levenshtein-distanse. Dette kan forenkles som: «For hvert fjerde tegn i en term tillates én endring.»
• Unntak for korte termer: For svært korte termer (2 eller 3 tegn) tillater vi 1 endring, selv om dette er under terskelen på 75 %.

Eksempler:

Regelen for samlet match

Håndtering av manglende navn (delmengdelogikk)

• Regelen: En match er tillatt dersom ett navn er en fullstendig delmengde av det andre. For eksempel kan A C matche A B C (hvor B er et manglende mellomnavn). Rekkefølgen på ordene har ingen betydning.
• Begrensningen: Algoritmen tillater ikke matcher der termer ganske enkelt er forskjellige. A B C vil ikke matche A B D.

Eksempler:

Den samlede likhetsscoren

Etter å ha samkjørt navnene beregner vi en endelig likhetsscore for hele settet med matchende termer. Det samlede settet med matchende termer må ha en total likhet som er lik eller høyere enn den spesifiserte likhetsscoren fastsatt av Brukeren.

1.3 Filtrering

Resultater fra søket filtreres ut basert på de definerte innstillingene. De tilgjengelige filtreringsalternativene er:

• Den samlede likhetsscoren for navnet
• Oppbevaringsvarigheten for en PEP (hvor lenge Statusen er gyldig etter at en Rolle er avsluttet)

1.4 Scoring

Når et potensielt Treff passerer de innledende filtrene for navnematching, beregner vi en endelig matchscore ved hjelp av et vektet aritmetisk gjennomsnitt, uttrykt som en prosentandel fra 0 % til 100 %.

Viktige aspekter ved scoringen:

• Hver vekting kan konfigureres i innstillingene.
• En komponent ignoreres dersom datapunktet mangler fra Strise-entiteten eller kilden for PEP eller Sanksjoner.
• En match på fødselsnummer/organisasjonsnummer (SSN) fra Strise-entiteten mot entiteten fra kilden vil alltid overstyre matchprosenten til 100 %.

Se dokumentasjonen for flere detaljer:

• Data field weighting in PEP settings
• Data field weighting in Sanctions settings

1.5 Brukerverifisering

Brukeren kan verifisere hvert resultat som sant eller usant. Det vil alltid være mulig å se informasjon om endringene, f.eks. hvilken Bruker som verifiserte Treffet, hvilken Status, på hvilket tidspunkt osv. Denne loggen kan også lastes ned som en .csv-fil.

2. Innstillinger

For både PEP- og sanksjonsinnstillinger er det mulig å påvirke stegene for Søk, Filtrering og Scoring:

• Søk: Velg hvilke PEP- og sanksjonslister det screenes mot.
• Filtrering:
  • Minimum fuzzy-navnematch – styrer hvor likt et navn må være for å bli flagget.
  • Oppbevaringsperiode for PEP/RCA – hvor lenge en Person forblir en PEP etter at Rollen deres er avsluttet.
• Scoring:
  • Datafeltvekting – bestemmer den relative viktigheten av hvert datafelt.
  • Foreslått sann match – terskelen som brukes til å avgjøre om en score klassifiseres som foreslått sann eller usann.

3. Varsler

Varsler sendes når følgende vilkår er oppfylt:

• De underliggende dataene for PEP eller Sanksjoner oppdateres
• Scoringen har klassifisert Treffet som foreslått sant, eller ditt Team har verifisert Treffet som en sann match (via appen eller API-et)

Å verifisere et Treff som ditt Teams Screening ikke foreslo som en sann match, bringer Treffet inn i Monitorering: det rapporteres som et lagt til Treff ved neste monitoreringskjøring, og varsler deretter ved dataoppdateringer. Et Treff som allerede var foreslått sant er allerede under Monitorering, så verifisering av dette endrer ingenting og genererer ikke noe duplikatvarsel.

Varsler sendes ikke i følgende tilfeller:

• Et Treff som allerede er under Monitorering verifiseres, enten som en sann eller en usann match. Verifisering registrerer ditt Teams beslutning; det er ikke en varselutløser i seg selv.
• Dataene for Entiteten i Strise endres.

Andre relevante punkter:

• Varsler vil sendes for tidligere verifiserte Treff, uavhengig av om de er bekreftet som sanne eller usanne, så lenge de oppfyller vilkårene ovenfor.

4. Forbedringer gjort i denne versjonen

Oktober–november 2025:

• En tidligere fast grense for søkeresultater er fjernet. Disse grensene var satt til 10 for PEP og 250 for Sanksjoner.
• Den nye delmengdelogikken håndterer tilfeller der et vilkårlig antall termer mangler fra et av navnene, og forkaster navn som har helt andre termer.
• «Regelen for match per term» er lagt til som støtte for den nye delmengdematchingslogikken.

5. Ofte stilte spørsmål

Hvor kommer RCA-familierelasjoner fra?

RCA-relasjoner (Relative or Close Associate) kommer direkte fra PEP/RCA-listene levert av våre dataleverandører (Trapets og Dow Jones). Strise fastslår eller utleder ikke familierelasjoner på egen hånd.

Hvordan en feilaktig entitetsmatch kan oppstå

Dersom en Strise-Entitet matcher et navn på listen, men mangler en fødselsdato for disambiguering, kan matchen kobles til feil Person. Relasjonsdataene fra kilden er korrekte; problemet ligger i entitetsavstemmingen (entity resolution) når fødselsdatoer mangler.

Oppsummering

Dersom du ser en uventet RCA-relasjon, er relasjonstypen hentet fra dataleverandøren og er sannsynligvis nøyaktig for Personen på listen – men Strise-Entiteten den er matchet mot, er kanskje ikke det korrekte individet.

Har du andre spørsmål om dette emnet? Kontakt oss på support@strise.ai.