PEP- och sanktionsscreening i Strise (v.3)

Den här artikeln beskriver hur Strise utför screening för PEP (Politically Exposed Person) och Sanktioner. Artikeln belyser även hur screeningen kan anpassas via inställningar, hur och när aviseringar skickas samt centrala förbättringar som implementerats i v.3 – lanserat under Q4 2025.

---

1. Hur screening fungerar

Båda processerna för screening mot PEP och Sanktioner följer ett liknande flöde:

1. Förbearbetning: Detta innebär att data rensas genom att ta bort accenter, titlar, förkortningar av företagsformer etc.
2. Sökning: En namnsökning görs mot PEP- och sanktionslistor för att hitta relevanta träffar.
3. Filtrering: Resultaten filtreras baserat på användarinställningar, såsom utgångsdatum för PEP/RCA-status, likhetströsklar och exkluderade källor.
4. Poängsättning: Ett vägt aritmetiskt medelvärde beräknas baserat på en uppsättning konfigurerbara fält, och träffarna markeras som föreslagen falsk eller föreslagen sann.
5. Användarverifiering: Användare kan verifiera resultaten från steget ovan.

1.1 Förbearbetning

Detta steg normaliserar namnet och alias, vilket säkerställer att mindre variationer i stavning, accenter eller specialtecken inte hindrar oss från att identifiera en potentiell matchning mot screeninglistorna.

1.2 Sökning

De normaliserade namnen och aliasen från förbearbetningssteget fungerar som en heltäckande sökfråga. Vilka PEP- och sanktionslistor det söks mot kan konfigureras i inställningarna.

Ett namn betraktas som en matchning endast om det uppfyller båda följande villkor:

1. Matchning per term: Varje enskilt ord i namnet måste klara ett specifikt likhetstest.
2. Övergripande matchning: Namnet som helhet måste uppnå en lägsta likhetströskel.

Regeln för matchning per term

• 75 %-regeln: En term måste ha minst 75 % likhet med sin motsvarande term. Vi beräknar detta med hjälp av Damerau-Levenshtein-avstånd. Detta kan förenklas till: "För varje 4 tecken i en term tillåts 1 ändring."
• Undantag för korta termer: För mycket korta termer (2 eller 3 tecken) tillåter vi 1 ändring, även om detta understiger 75 %-tröskeln.

Exempel:

Regeln för övergripande matchning

Hantering av saknade namn (delmängdslogik)

• Regeln: En matchning tillåts om det ena namnet är en fullständig delmängd av det andra. Till exempel kan A C matcha A B C (där B är ett saknat mellannamn). Ordningen på orden saknar betydelse.
• Begränsningen: Algoritmen tillåter inte matchningar där termer helt enkelt är olika. A B C kommer inte att matcha A B D.

Exempel:

Den övergripande likhetspoängen

Efter att namnen har passats ihop beräknar vi en slutgiltig likhetspoäng för hela uppsättningen av matchade termer. Den kombinerade uppsättningen av matchade termer måste ha en övergripande likhet som är lika med eller högre än den angivna likhetspoängen som angetts av användaren.

1.3 Filtrering

Resultaten från sökningen filtreras bort baserat på de definierade inställningarna. De tillgängliga filtreringsalternativen är:

• Den övergripande likhetspoängen för namnet
• Retentionsperioden för en PEP (hur länge statusen är giltig efter att en roll har avslutats)

1.4 Poängsättning

När en potentiell träff passerar våra inledande namnmatchningsfilter beräknar vi en slutgiltig matchningspoäng med hjälp av ett vägt aritmetiskt medelvärde, uttryckt som en procentsats från 0 % till 100 %.

Viktiga aspekter av poängsättningen:

• Varje viktning kan konfigureras i inställningarna.
• En komponent ignoreras om datapunkt saknas i Strise-entiteten eller i källan för PEP eller Sanktioner.
• En matchning på personnummer (SSN) från Strise-entiteten med entiteten från källan åsidosätter alltid matchningsprocenten till 100 %.

Se dokumentationen för mer information:

• Viktning av datafält i PEP-inställningar
• Viktning av datafält i sanktionsinställningar

1.5 Användarverifiering

Användaren kan verifiera varje resultat som sant eller falskt. Det kommer alltid vara möjligt att se information om ändringarna, t.ex. vilken användare som verifierade träffen, vilken status, vid vilken tidpunkt etc. Denna logg kan även laddas ned som en .csv-fil.

2. Inställningar

För både inställningar gällande PEP och Sanktioner är det möjligt att påverka stegen för sökning, filtrering och poängsättning:

• Sökning: Välj vilka listor för PEP och Sanktioner som screeningen ska ske mot.
• Filtrering:
  • Lägsta oskarp namnmatchning (fuzzy match) – styr hur likt ett namn måste vara för att flaggas.
  • PEP/RCA-retentionsperiod – hur länge en person förblir PEP efter att deras roll har avslutats.
• Poängsättning:
  • Viktning av datafält – bestämmer den relativa betydelsen för varje datafält.
  • Föreslagen sann matchning – tröskelvärdet som används för att avgöra om en poäng klassificeras som föreslagen sann eller falsk.

3. Aviseringar

Aviseringar skickas när följande villkor är uppfyllda:

• De underliggande uppgifterna för informationen om PEP eller Sanktioner uppdateras
• Poängsättningen har klassificerat träffen som föreslagen sann, eller ditt team har verifierat träffen som en sann matchning (via appen eller API:et)

Att verifiera en träff som ditt teams screening inte föreslog som en sann matchning för in den träffen i övervakning: den rapporteras som en tillagd träff vid nästa övervakningskörning och genererar aviseringar vid datauppdateringar därefter. En träff som redan föreslogs som sann övervakas redan, så att verifiera den ändrar ingenting och skapar ingen dubblettavisering.

Aviseringar skickas inte i följande fall:

• En träff som redan övervakas verifieras, oavsett om det är som en sann eller falsk matchning. Verifieringen registrerar ditt teams beslut; den är inte en aviseringsutlösare i sig.
• Uppgifterna för entiteten i Strise ändras.

Andra relevanta punkter:

• Aviseringar skickas för tidigare verifierade träffar, oavsett om de har bekräftats som sanna eller falska, så länge de uppfyller ovanstående villkor.

4. Förbättringar i denna version

Oktober–november 2025:

• En tidigare hård gräns för sökresultat har tagits bort. Dessa tak var satta till 10 för PEP och 250 för Sanktioner.
• Den nya delmängdslogiken hanterar fall där valfritt antal termer saknas från något av namnen, och sorterar bort namn som har helt olika termer.
• "Regeln för matchning per term" har lagts till som stöd för den nya delmängdsmatchningslogiken.

5. Vanliga frågor

Varifrån kommer RCA-familjerelationer?

RCA-relationer (Relative or Close Associate) kommer direkt från PEP/RCA-listorna som tillhandahålls av våra dataleverantörer (Trapets och Dow Jones). Strise fastställer eller härleder inte familjerelationer på egen hand.

Hur en felaktig entitetsmatchning kan uppstå

Om en Strise-entitet matchar ett namn på listan men saknar födelsedatum för särskiljning kan matchningen kopplas till fel person. Relationsdatan från källan är korrekt; problemet ligger i entitetsidentifieringen när födelsedatum saknas.

Sammanfattning

Om du ser en oväntad RCA-relation kommer relationstypen från dataleverantören och är sannolikt korrekt för personen på listan – men den Strise-entitet som den har matchats mot kanske inte är rätt individ.

Har du några andra frågor kring detta ämne? Kontakta oss på support@strise.ai.