> Continu verbeteren van processen > KYC klantonboarding > Refinitiv World Check > Datatemplate

Datatemplate voor KYC-klantonboarding

Refinitiv World-Check

Attributen voor KYC-klantonboarding (19) Activiteiten voor KYC-klantonboarding (14) Extractiegidsen (2)

Datatemplate voor KYC-klantonboarding

Deze template helpt je de essentiële data te verzamelen voor de analyse van het KYC-klantonboardingproces. Je ziet welke attributen je moet vastleggen en welke activiteiten je moet volgen. Ook lees je hoe je deze informatie uit de bronsystemen haalt. Gebruik de template om te controleren of je alle data hebt die nodig is voor een goede procesanalyse en verbetering.

Aanbevolen attributen om te verzamelen
Belangrijke activiteiten om te volgen
Richtlijnen voor data-extractie

Nieuw met event logs? Lees hoe je een event log voor process mining maakt.

Template downloaden

Attributen voor KYC-klantonboarding

Dit zijn de aanbevolen datavelden voor je event log, zodat je het KYC-klantonboardingproces volledig kunt analyseren.

3 Verplicht 5 Aanbevolen 11 Optioneel

	Naam	Beschrijving
	Activiteitsnaam ActivityName	De naam van een specifieke bedrijfsgebeurtenis of taak in het KYC-onboardingproces.
Beschrijving De activiteitsnaam beschrijft één stap of gebeurtenis in het onboardingtraject van de klant, zoals ‘Aanvraag ingediend’, ‘Beoordeling door analist gestart’ of ‘Screening afgerond, geen overeenkomst’. Deze activiteiten vormen de knooppunten van de proceskaart en geven een gedetailleerd beeld van de volledige workflow. Activiteiten analyseren is de kern van process mining. Door de volgorde en frequentie van activiteiten te volgen, kunnen analisten de werkelijke processtroom ontdekken, veelvoorkomende routes herkennen, afwijkingen van de standaardprocedure opsporen en specifieke stappen vinden die vertraging of herstelwerk veroorzaken. Dit attribuut is belangrijk voor het maken van proceskaarten en het berekenen van metrieken per activiteit. Waarom dit belangrijk is Dit attribuut beschrijft de afzonderlijke processtappen. Dat is essentieel om de processtroom te ontdekken en te visualiseren en bottlenecks te vinden. Waar vind je dit? Deze informatie staat doorgaans in event logs of tabellen met auditsporen, vaak gekoppeld aan statuswijzigingen in de casemanagemententiteit. Voorbeelden Mogelijke overeenkomst gevondenBeoordeling door analist gestartVals-positieve overeenkomst bevestigdAanvraag goedgekeurd
	Klantaanvraag CustomerApplication	De unieke identificatiecode van één onboardingaanvraag van een klant. Deze code dient als primaire case-ID.
Beschrijving De klantaanvraag is de centrale case-ID die alle gebeurtenissen en activiteiten rond het onboardingtraject van één klant groepeert. Hiermee kun je de voortgang van elke klant chronologisch volgen tijdens het volledige Know Your Customer-proces (KYC), vanaf de eerste indiening tot het definitieve besluit. Bij process mining is dit attribuut essentieel om het volledige traject van elke aanvraag te reconstrueren. Je kunt processtromen visualiseren, totale doorlooptijden berekenen en varianten herkennen. Door cases met deze ID te groeperen, zie je welke routes aanvragen kunnen volgen, waar bottlenecks zitten en hoe efficiënt verschillende onboardingprocessen zijn. Waarom dit belangrijk is Dit is de essentiële case-ID die alle bijbehorende activiteiten met elkaar verbindt. Zo kun je het volledige onboardingproces van de klant analyseren. Waar vind je dit? Deze identificatiecode is doorgaans de primaire sleutel in de hoofdapplicatie- of casemanagementtabel van Refinitiv World-Check of een geïntegreerd CRM. Voorbeelden APP-2023-00123APP-2023-00124APP-2023-00125
	Tijdstip van gebeurtenis EventTime	De timestamp die aangeeft wanneer een specifieke activiteit of gebeurtenis plaatsvond.
Beschrijving Het tijdstip van de gebeurtenis geeft de exacte datum en tijd aan waarop een activiteit is vastgelegd. Deze timestamp vormt de chronologische basis van het proces. Zo kun je gebeurtenissen in de juiste volgorde zetten en de geschiedenis van een case reconstrueren. Dit attribuut is essentieel voor alle tijdsanalyses in process mining. Je gebruikt het om de duur tussen activiteiten te berekenen, zoals doorlooptijden en wachttijden, de totale duur van een case te meten, procesprestaties door de tijd heen te analyseren en compliance met service level agreements (SLA’s) te controleren. Zonder nauwkeurige timestamps kun je procesprestaties niet begrijpen en geen tijdsgebonden bottlenecks vinden. Waarom dit belangrijk is De timestamp van elke activiteit is essentieel om metrieken op basis van tijdsduur te berekenen, de procesvolgorde te achterhalen en bottlenecks te analyseren. Waar vind je dit? Dit is een standaardveld in elke event log of tabel met auditsporen. Het heet vaak ‘Timestamp’, ‘EventDate’ of ‘CreationDate’. Voorbeelden 2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T14:22:15Z
	Afdeling DepartmentName	De afdeling of het functionele team dat verantwoordelijk is voor de activiteit.
Beschrijving Dit attribuut geeft aan bij welke bedrijfseenheid of welk team de gebruiker hoort, zoals ‘Onboarding’, ‘Compliance’ of ‘Kwaliteitsborging’. Zo kun je analyses maken op een hoger organisatieniveau dan dat van individuele gebruikers. Analyse per afdeling is belangrijk om bottlenecks tussen afdelingen te vinden en overdrachtstijden te meten. Je ziet hoe het werk tussen teams verloopt en waar bij die overdrachten vertraging ontstaat. Dit overzicht helpt om de samenwerking tussen teams te verbeteren en het proces efficiënter te maken. Waarom dit belangrijk is Maakt het mogelijk om procesprestaties per afdeling te analyseren en vertragingen bij overdrachten tussen teams te vinden. Waar vind je dit? Deze informatie kan in het gebruikersprofiel in het systeem of in een gekoppeld HR-systeem staan. Mogelijk moet je de informatie op basis van de gebruikers-ID aan de eventdata koppelen. Voorbeelden OnboardingteamCompliancebeoordelingSenior management
	Eindtijd van gebeurtenis EventEndTime	De timestamp die aangeeft wanneer een specifieke activiteit of gebeurtenis is voltooid.
Beschrijving De eindtijd van een gebeurtenis geeft aan wanneer een activiteit is voltooid. Veel gebeurtenissen kun je modelleren als momenten zonder duur, waarbij de starttijd gelijk is aan de eindtijd. Andere activiteiten hebben wel een meetbare duur, zoals ‘Beoordeling door analist gestart’ en ‘Beoordeling door analist voltooid’. Met een begin- en eindtijd kun je de verwerkingstijd nauwkeurig meten. Bij procesanalyse heb je een eindtijd nodig om de exacte verwerkingstijd van een activiteit te berekenen. De doorlooptijd omvat ook wachttijd. Zo kun je onderscheid maken tussen de tijd waarin actief aan een case wordt gewerkt en de tijd waarin die ongebruikt in een wachtrij staat. Dat helpt bij het verbeteren van de inzet van medewerkers en de efficiëntieanalyse. Waarom dit belangrijk is Maakt een nauwkeurige berekening van de verwerkingstijd van activiteiten mogelijk. Zo kun je actieve werktijd onderscheiden van wachttijd en prestaties nauwkeuriger analyseren. Waar vind je dit? Voor activiteiten met een duur kan deze informatie in een apart veld staan, zoals ‘CompletionDate’ of ‘EndDate’ in de event log of tabellen met auditsporen. Voorbeelden 2023-10-26T10:45:00Z2023-10-26T12:00:00Z2023-10-27T15:00:00Z
	ID van beoordelaar ReviewerId	De identificatiecode van de gebruiker, analist of geautomatiseerde agent die de activiteit heeft uitgevoerd.
Beschrijving De ID van de beoordelaar geeft aan wie een bepaalde taak in het KYC-proces heeft uitgevoerd. Dit kan een compliance-analist, een onboardingmedewerker of een systeemaccount voor geautomatiseerde activiteiten zijn. Met deze informatie zie je hoe het werk is verdeeld en hoe individuele medewerkers presteren. Dit attribuut is essentieel voor analyses van de inzet van medewerkers. Je kunt prestatieverschillen tussen gebruikers of teams onderzoeken, opleidingsbehoeften vaststellen en de werkverdeling verbeteren. Het is ook belangrijk voor analyses van overdrachten, sociale netwerken en de inzet van compliancepersoneel. Waarom dit belangrijk is Maakt analyses mogelijk van de werkverdeling, gebruikersprestaties en overdrachten tussen afdelingen. Dit is belangrijk om de inzet van medewerkers te verbeteren. Waar vind je dit? Staat doorgaans in event logs of auditsporen, vaak onder de naam ‘UserID’, ‘PerformedBy’ of ‘Owner’. Voorbeelden analyst_jdoesystem_auto_screenermanager_bsmith
	Risiconiveau RiskLevel	De berekende risicoclassificatie van de klantaanvraag, bijvoorbeeld laag, gemiddeld of hoog.
Beschrijving Het risiconiveau is belangrijke informatie in KYC-processen en bepaalt welk niveau van cliëntenonderzoek nodig is. Het wordt vaak bepaald aan de hand van factoren zoals het klanttype, de geografische locatie en de aard van de bedrijfsactiviteiten. Deze classificatie kan grote invloed hebben op de route die een aanvraag door het proces volgt. Het is belangrijk om cases in procesanalyses op risiconiveau in te delen. Zo kun je verschillen in doorlooptijden en processtromen verklaren. Aanvragen met een hoog risico kunnen bijvoorbeeld meer stappen vereisen en langer duren. Dit attribuut is belangrijk voor de dashboards ‘Afwijzingspercentage en redenen van aanvragen’ en ‘Doorlooptijd tot start van achtergrondcontrole’. Daarmee zie je hoe risico’s de uitkomsten en efficiëntie beïnvloeden. Waarom dit belangrijk is Door het proces in te delen naar risiconiveau, zie je waarom bepaalde cases langer duren of een andere route volgen. Ook kun je afwijzingspercentages analyseren. Waar vind je dit? Dit is een kerngegeven in de klantaanvraag of het caserecord. Raadpleeg de casemanagementmodule van Refinitiv World-Check. Voorbeelden LaagGemiddeldHoog
	SLA-streefdatum SlaTargetDate	De datum waarop het onboardingproces van de klant afgerond moet zijn.
Beschrijving De SLA-streefdatum is de deadline voor het afronden van de volledige onboardingcase, zoals vastgelegd in de service level agreement met de klant of in intern beleid. Deze datum is de maatstaf waarmee je de werkelijke doorlooptijd vergelijkt. Dit attribuut is de basis voor het dashboard ‘SLA-naleving en analyse van overschrijdingen’. Je gebruikt het om te berekenen of een case op tijd is afgerond. Door SLA-overschrijdingen te analyseren, kun je structurele oorzaken van vertraging opsporen en maatregelen nemen om de doorlooptijd te verbeteren en aan de compliancevereisten te voldoen. Waarom dit belangrijk is Dit is de maatstaf voor prestaties op tijd. Je hebt deze nodig om de SLA-naleving te berekenen en overschrijdingen te analyseren. Waar vind je dit? Deze datum wordt vaak berekend op basis van de datum waarop de aanvraag is ingediend en de bedrijfsregels. Mogelijk staat de datum als veld in het caserecord. Voorbeelden 2023-11-10T17:00:00Z2023-11-15T17:00:00Z2023-11-20T17:00:00Z
	Aanvraagkanaal ApplicationChannel	Het kanaal waarlangs de klantaanvraag is ingediend, zoals het online portaal, een filiaal of een mobiele app.
Beschrijving Het aanvraagkanaal geeft aan waar de klantaanvraag is ingediend. De volledigheid en kwaliteit van de data en de klantgroepen kunnen per kanaal verschillen. Dat kan gevolgen hebben voor het vervolg van het proces. Dit attribuut is belangrijk voor het dashboard ‘Doorvoer van aanvragen per kanaal’. Door het aantal aanvragen, de doorlooptijd en de uitkomsten per kanaal te analyseren, zie je welke kanalen het efficiëntst zijn en waar procesverbeteringen nodig zijn. Deze analyse helpt bij strategische keuzes over de inzet van medewerkers en investeringen in kanalen. Waarom dit belangrijk is Helpt de prestaties en efficiëntie van verschillende aanvraagkanalen te analyseren en ondersteunt strategische keuzes over technologie en klantervaring. Waar vind je dit? Deze informatie wordt doorgaans aan het begin van het proces vastgelegd als attribuut in het aanvraagrecord. Voorbeelden Online portaalMobiele appIn een filiaalRelatiemanager
	Bronsysteem SourceSystem	Het systeem waaruit de eventdata zijn gehaald, in dit geval Refinitiv World-Check.
Beschrijving Dit attribuut geeft aan waar de procesdata vandaan komen. Bij een extractie uit één bron kan de waarde steeds hetzelfde zijn. Het attribuut wordt belangrijk wanneer data uit meerdere systemen, zoals een CRM en World-Check, worden gecombineerd om een volledig beeld van het proces te krijgen. Bij analyses helpt dit attribuut bij datagovernance, het oplossen van problemen en het begrijpen van de context van de data. Activiteiten uit een kernsysteem voor screening kunnen bijvoorbeeld andere eigenschappen of een ander detailniveau hebben dan activiteiten uit een ondersteunend systeem. Zo blijft de herkomst van de data duidelijk en controleerbaar. Waarom dit belangrijk is Geeft de herkomst van de data aan. Dit is belangrijk voor datagovernance en validatie, en bij het samenvoegen van data uit meerdere bronnen. Waar vind je dit? Dit is vaak een vaste waarde die tijdens het proces voor extractie, transformatie en laden (ETL) wordt toegevoegd om de dataset te labelen. Voorbeelden Refinitiv World-CheckWorldCheckOne
	Is geautomatiseerd IsAutomated	Een aanduiding die aangeeft of de activiteit door een systeem (true) of een persoon (false) is uitgevoerd.
Beschrijving Dit booleaanse attribuut maakt onderscheid tussen geautomatiseerde systeemtaken en handmatige activiteiten van gebruikers. Zo wordt 'Geautomatiseerde screening uitgevoerd' als geautomatiseerd gemarkeerd, terwijl 'Beoordeling door analist gestart' als handmatig wordt aangemerkt. Dit onderscheid is belangrijk voor automatiseringsanalyse. Je kunt hiermee meten wat automatisering doet voor de procesefficiëntie, bepalen welke handmatige taken in aanmerking komen voor automatisering en zien hoe mensen en systemen samenwerken. Ook kun je de verwerkingstijd van systemen onderscheiden van de tijd die medewerkers aan de afhandeling besteden. Waarom dit belangrijk is Maakt onderscheid tussen systeemactiviteiten en activiteiten van medewerkers. Dat is nodig om het effect van automatisering te meten en nieuwe mogelijkheden voor automatisering te vinden. Waar vind je dit? Dit wordt meestal afgeleid van de activiteitsnaam of de gebruikers-ID die bij de gebeurtenis hoort, bijvoorbeeld wanneer de gebruiker een 'system'-account is. Voorbeelden truefalse
	Is herstelwerk IsRework	Een aanduiding die laat zien of een activiteit voor de tweede of volgende keer binnen dezelfde case wordt uitgevoerd.
Beschrijving IsRework is een berekend booleaans attribuut dat aangeeft wanneer een activiteit binnen dezelfde klantaanvraagcase wordt herhaald. Als 'Risicobeoordeling uitgevoerd' bijvoorbeeld meer dan één keer voorkomt voor dezelfde aanvraag, worden de volgende uitvoeringen als herstelwerk gemarkeerd. Dit attribuut helpt inefficiënties, lussen en onnodige herhalingen in het proces te vinden. Het ondersteunt rechtstreeks het dashboard 'Herstelwerk en efficiëntie bij risicobeoordeling' en de KPI 'Percentage herstelwerk bij risicobeoordeling'. Door herstelwerk te analyseren, kun je problemen met kwaliteit, duidelijkheid van informatie of besluitvorming opsporen. Die leiden tot verspilde inspanning en langere doorlooptijden. Waarom dit belangrijk is Maakt inefficiënties zichtbaar door herhaalde activiteiten te markeren. Zo kun je lussen met herstelwerk analyseren, de kwaliteit verbeteren en doorlooptijden verkorten. Waar vind je dit? Dit wordt tijdens de datatransformatie berekend door de activiteitenvolgorde per case te analyseren en elke activiteit na de eerste uitvoering te markeren. Voorbeelden truefalse
	Klant-ID CustomerId	Een unieke identificatiecode voor de klant die wordt onboarded.
Beschrijving De klant-ID is de unieke identificatiecode van het klantprofiel. Deze verschilt van de klantaanvraag-ID, omdat één klant in de loop van de tijd meerdere aanvragen kan indienen. Met dit attribuut koppel je het onboardingproces aan het hoofdrecord van de klant. Met de klant-ID kun je herhaalde aanvragen van dezelfde klant volgen. Je kunt de procesdata ook aanvullen met andere klantgegevens uit een CRM- of stamgegevenssysteem. Zo krijg je een vollediger beeld van het klanttraject dan met één onboardingaanvraag. Waarom dit belangrijk is Koppelt de onboardingcase aan een specifieke klant. Zo kun je herhaalde aanvragen analyseren en de data aanvullen met stamgegevens van de klant. Waar vind je dit? Dit is een belangrijk veld in het aanvraag- of caserecord dat de aanvraag koppelt aan de stamgegevens van de klant. Voorbeelden CUST-98765CUST-98766CUST-98767
	Klanttype CustomerType	De classificatie van de klant, bijvoorbeeld particulier, onderneming of trust.
Beschrijving Het klanttype geeft aan wat voor entiteit wordt onboarded. Verschillende klanttypen hebben vaak andere onboardingvereisten, risicoprofielen en wettelijke verplichtingen. Zo is het onboarden van een onderneming doorgaans ingewikkelder dan dat van een particulier. Dit attribuut wordt gebruikt om segmenten te analyseren, vooral in het dashboard ‘Prestaties per KYC-klanttype’. Je kunt de procesefficiëntie, doorlooptijden en afwijzingspercentages van verschillende klantsegmenten vergelijken. Zo kun je het onboardingproces afstemmen op elk klanttype en verbeteren. Waarom dit belangrijk is Maakt het mogelijk om prestaties van verschillende klantsegmenten te vergelijken en het onboardingproces per klanttype af te stemmen en te verbeteren. Waar vind je dit? Dit is een basisattribuut in het klant- of aanvraagrecord in het bronsysteem. Voorbeelden ParticulierOndernemingNon-profitorganisatieTrust
	Laatste data-update LastDataUpdate	De timestamp waarop de data voor deze gebeurtenis voor het laatst zijn vernieuwd of uit het bronsysteem zijn gehaald.
Beschrijving Dit attribuut geeft aan hoe actueel de data zijn. Het bevat de datum en tijd waarop de data voor het laatst uit Refinitiv World-Check zijn opgehaald. Zo weet je hoe actueel de process mining-dashboards en analyses zijn. Voor analyses kun je hiermee zien of je met bijna realtime data werkt of met een momentopname. Dit is belangrijk voor datagovernance en om duidelijk te maken hoe actueel de inzichten zijn. Waarom dit belangrijk is Geeft belangrijke context over de actualiteit van de data, zodat gebruikers weten hoe recent de procesanalyse is. Waar vind je dit? Deze timestamp wordt aangemaakt en toegevoegd tijdens het data-extractieproces (ETL). Voorbeelden 2023-11-01T02:00:00Z2023-11-02T02:00:00Z
	Land van de klant CustomerCountry	Het land waar de klant woont of is gevestigd.
Beschrijving Dit attribuut geeft de geografische locatie van de klant aan. Het land speelt een belangrijke rol bij de risicobeoordeling en wettelijke vereisten voor KYC-processen. De regels verschillen per rechtsgebied en kunnen invloed hebben op de processtroom en doorlooptijd. Door het proces per land te analyseren, kunnen organisaties prestaties in verschillende regio’s vergelijken, regionale bottlenecks vinden en controleren of ze aan lokale regelgeving voldoen. Zo voeg je een geografische dimensie toe aan de procesanalyse en komen belangrijke verschillen in de bedrijfsvoering aan het licht. Waarom dit belangrijk is Maakt geografische analyse van het proces mogelijk, zodat je regionale verschillen in prestaties, risico’s en compliancevereisten kunt vinden. Waar vind je dit? Dit is een standaardveld in het klantprofiel of op het aanvraagformulier. Voorbeelden USAGBRSGPDEU
	Overeenkomst-ID MatchId	De unieke identificatiecode van een mogelijke overeenkomst die tijdens een World-Check-screening is gevonden.
Beschrijving Wanneer het geautomatiseerde screeningsproces een mogelijke overeenkomst vindt met sanctielijsten, PEP-lijsten of negatieve berichtgeving, wordt vaak een Match ID aangemaakt om de specifieke bevinding te volgen. Dit ID koppelt de aanvraagcase aan het specifieke record in de World-Check-database dat de melding heeft veroorzaakt. Dit attribuut is nuttig voor een gedetailleerde complianceanalyse. Analisten kunnen hiermee de aard van overeenkomsten onderzoeken, de afhandeling van specifieke meldingen volgen, bijvoorbeeld om een false positive of een echte overeenkomst te bevestigen, en nagaan welke soorten meldingen het vaakst voorkomen of het langst duren om af te handelen. Het geeft meer detail over de activiteit 'Mogelijke overeenkomst vastgesteld'. Waarom dit belangrijk is Biedt een directe koppeling naar de specifieke screeningsresultaten, zodat je de afhandelingstijden en soorten meldingen verder kunt analyseren. Waar vind je dit? Deze ID wordt aangemaakt door de World-Check-screeningengine en aan de aanvraagcase gekoppeld wanneer een mogelijke overeenkomst wordt gevonden. Voorbeelden WC-MATCH-459021WC-MATCH-459022WC-MATCH-459023
	Reden van afwijzing RejectionReason	De specifieke reden die wordt opgegeven wanneer een klantaanvraag wordt afgewezen.
Beschrijving De reden van afwijzing legt vast waarom een aanvraag is afgewezen. Mogelijke redenen zijn ‘Sanctielijstovereenkomst’, ‘Documentatie onvolledig’ of ‘Hoog risicoprofiel’. Zo krijg je gestructureerde feedback over de kwaliteit van binnenkomende aanvragen en de werking van het screeningsproces. Dit attribuut is de belangrijkste basis voor het dashboard ‘Afwijzingspercentage en redenen van aanvragen’. Door de redenen te analyseren, kun je de oorzaken van afwijzingen vinden. Dat kan leiden tot procesverbeteringen, duidelijkere communicatie met aanvragers en mogelijk minder onnodige afwijzingen. Het attribuut geeft kwalitatieve context bij het kwantitatieve KPI-afwijzingspercentage. Waarom dit belangrijk is Geeft de oorzaak van afgewezen aanvragen aan. Zo kun je verbeterpunten in het onboardingproces vinden en het afwijzingspercentage verlagen. Waar vind je dit? Dit wordt waarschijnlijk vastgelegd als veld in het case- of aanvraagrecord wanneer de gebeurtenis ‘Aanvraag afgewezen’ plaatsvindt. Voorbeelden PEP-overeenkomstTreffer op sanctielijstDocumentverificatie misluktOngunstige berichtgeving
	SLA overschreden SlaBreached	Een booleaanse aanduiding die aangeeft of de onboardingcase is afgerond na de SLA-streefdatum.
Beschrijving Dit attribuut is een berekende aanduiding die laat zien of een case de Service Level Agreement heeft overschreden. Hiervoor wordt de timestamp van de laatste afrondingsactiviteit, bijvoorbeeld 'Aanvraag goedgekeurd' of 'Aanvraag afgewezen', vergeleken met de 'SlaTargetDate' van de case. Deze aanduiding vormt de basis voor het dashboard 'Analyse van SLA-naleving en overschrijdingen' en de KPI 'SLA-nalevingspercentage'. Je kunt hiermee eenvoudig alle cases filteren waarbij de SLA is overschreden. Door de proceskenmerken van deze cases te analyseren, kunnen organisaties de oorzaken van vertragingen vinden en verbeteringen gericht aanpakken. Waarom dit belangrijk is Meet rechtstreeks of service level agreements worden nageleefd. Je kunt vertraagde cases eenvoudig filteren en de oorzaken analyseren. Waar vind je dit? Dit wordt tijdens de datatransformatie berekend door de timestamp van de laatste activiteit van een case te vergelijken met het veld SlaTargetDate. Voorbeelden truefalse

Verplicht Aanbevolen Optioneel

Activiteiten voor KYC-klantonboarding

Dit zijn de belangrijke processtappen en mijlpalen om in je event log vast te leggen voor een nauwkeurige procesontdekking.

8 Aanbevolen 6 Optioneel

	Activiteit	Beschrijving
	Aanvraag afgewezen	De klantaanvraag wordt formeel afgewezen, vaak omdat World-Check een ‘Overeenkomst gevonden’ meldt of vanwege andere risicofactoren. Dit is de definitieve negatieve uitkomst van het onboardingproces.
Waarom dit belangrijk is Dit is het belangrijkste eindpunt bij een mislukte aanvraag. Door afwijzingen te analyseren, vooral de redenen en voorafgaande activiteiten, kun je het proces verbeteren en onnodige afwijzingen terugdringen. Waar vind je dit? Dit definitieve bedrijfsbesluit wordt vastgelegd in het bovenliggende CRM- of kernsysteem voor aanvragen, niet in World-Check zelf. De data moet uit dat systeem komen. Vastleggen Gebeurtenis die in het bronsysteem wordt vastgelegd, vaak met een bijbehorende afwijzingscode. Gebeurtenistype explicit
	Aanvraag ingediend	Deze activiteit markeert de start van het KYC-onboardingproces, wanneer een klant een aanvraag indient. Dit event wordt meestal vastgelegd in een CRM- of kernapplicatiesysteem. Vervolgens start de screening in Refinitiv World-Check.
Waarom dit belangrijk is Dit is de belangrijkste startgebeurtenis van het volledige klantacceptatieproces. Door de tijd vanaf dit moment tot de afronding te meten, krijg je de totale onboarding-doorlooptijd. Die is belangrijk om de klantervaring en het halen van SLA-doelen te meten. Waar vind je dit? Dit event komt niet standaard uit World-Check. Je moet het ophalen uit een eerder systeem, zoals een CRM- of klantaccountbeheerplatform, en koppelen op basis van de Customer Application ID. Vastleggen Event dat bij de eerste indiening in het bronsysteem wordt vastgelegd. Gebeurtenistype explicit
	Account geactiveerd	Het account van de klant wordt aangemaakt en geactiveerd in het kernsysteem. Daarmee is het onboardingtraject afgerond en kan de klant het account gebruiken. Dit gebeurt nadat de aanvraag definitief is goedgekeurd.
Waarom dit belangrijk is Dit is de laatste stap in het proces die waarde oplevert. De tijd tussen het indienen van de aanvraag en de activering van het account is een belangrijke metriek voor de efficiëntie van de bedrijfsvoering en de klanttevredenheid. Waar vind je dit? Deze gebeurtenis wordt niet vastgelegd in World-Check. Ze staat in het kernbanksysteem of klantaccountsysteem en moet worden gekoppeld via de klantaanvraag-ID. Vastleggen Gebeurtenis die in het kernsysteem voor accounts wordt vastgelegd zodra het account is geactiveerd. Gebeurtenistype explicit
	Beoordeling door analist gestart	Een compliance-analist begint met het handmatig onderzoeken van mogelijke overeenkomsten voor een klantaanvraag. De analist vergelijkt de gegevens van de mogelijke overeenkomsten met de klantgegevens om te bepalen of ze relevant zijn.
Waarom dit belangrijk is Dit markeert het begin van de handmatige compliancebeoordeling, een veelvoorkomende bottleneck. De tijd tussen ‘Mogelijke overeenkomst gevonden’ en deze activiteit laat wachttijd zien. De duur van de beoordeling geeft inzicht in de efficiëntie van analisten. Waar vind je dit? Dit is af te leiden wanneer een analist een case uit de beoordelingswachtrij claimt of opent. Het systeem kan deze gebeurtenis ook expliciet vastleggen in een auditspoor wanneer de casestatus verandert in ‘In beoordeling’ of de case aan een specifieke gebruiker wordt toegewezen. Vastleggen Af te leiden uit een statuswijziging van de case naar ‘In behandeling’ of uit de toewijzing van de case aan een analist. Gebeurtenistype inferred
	Echte overeenkomst bevestigd	Een analist bevestigt dat de mogelijke overeenkomst inderdaad de gescreende klant is en dat er mogelijk sprake is van een risico. Dit is een belangrijk moment dat doorgaans leidt tot verder cliëntenonderzoek of afwijzing van de aanvraag.
Waarom dit belangrijk is Dit is een belangrijke uitkomst voor risicobeperking en een bepalend moment in het proces. De uitkomst heeft rechtstreeks invloed op het definitieve besluit over de klantaanvraag en is belangrijk voor complianceverslaglegging en analyse. Waar vind je dit? Dit is een expliciete gebruikersactie waarbij de analist een specifieke overeenkomst afhandelt als ‘Echte overeenkomst’ of ‘Bevestigde overeenkomst’. Deze gebeurtenis wordt vastgelegd in het auditspoor van de case. Vastleggen Wordt vastgelegd wanneer een analist een overeenkomst formeel bevestigt in het systeem. Gebeurtenistype explicit
	Screening afgerond, geen overeenkomst	De screeningscase wordt officieel afgesloten met de uitkomst ‘Geen overeenkomst’. Er zijn dus geen echte overeenkomsten gevonden. Dit besluit wordt teruggekoppeld aan het bronsysteem, zodat het onboardingproces verder kan.
Waarom dit belangrijk is Dit is de succesvolle afronding van het screeningsproces via de ideale route. Deze activiteit is een belangrijk eindpunt voor het meten van de doorlooptijd van standaardaanvragen met een laag risico. Waar vind je dit? Af te leiden uit de definitieve casestatus ‘Geen overeenkomst’, ‘Voltooid’ of ‘Gesloten, geen overeenkomst’. De timestamp van deze laatste statuswijziging wordt gebruikt. Vastleggen Afgeleid van de timestamp van de definitieve casestatus die aangeeft dat er geen overeenkomst is gevonden. Gebeurtenistype inferred
	Screening afgerond, overeenkomst gevonden	De screeningscase wordt officieel afgesloten met de uitkomst ‘Overeenkomst gevonden’. Dit betekent dat er een bevestigd risico is vastgesteld. Dit besluit leidt tot een ander vervolgproces, zoals verscherpt cliëntenonderzoek of afwijzing.
Waarom dit belangrijk is Dit is het belangrijkste eindpunt van de afwijkende route in het screeningsproces. Door deze cases te analyseren, krijg je inzicht in risicoprofielen en de werking van de screeningsmaatregelen. Waar vind je dit? Af te leiden uit de definitieve casestatus ‘Overeenkomst gevonden’, ‘Risico vastgesteld’ of ‘Gesloten, positief’. De timestamp van deze laatste statuswijziging wordt gebruikt. Vastleggen Afgeleid van de timestamp van de definitieve casestatus die een bevestigde overeenkomst aangeeft. Gebeurtenistype inferred
	Screeningsaanvraag aangemaakt	In het Refinitiv World-Check-systeem wordt een nieuwe screeningcase voor een klantaanvraag aangemaakt. Dit gebeurt via een API-aanroep of handmatige invoer vanuit een eerder systeem en markeert de start van de risicocontrole.
Waarom dit belangrijk is Dit markeert de officiële start van het screeningssubproces. De tijd tussen het indienen van de aanvraag en deze activiteit laat zien waar overdrachten tussen het bedrijfssysteem en de compliancefunctie vertraging oplopen. Waar vind je dit? Vastgelegd in de casemanagementlogs of het auditspoor van World-Check. Hiervoor wordt de aanmaakgebeurtenis met timestamp gebruikt voor de betreffende case of entiteit-ID. Vastleggen Wordt automatisch vastgelegd wanneer in het systeem een nieuwe screeningscase wordt aangemaakt. Gebeurtenistype explicit
	Aanvraag goedgekeurd	De klantaanvraag is volledig goedgekeurd na een succesvolle KYC-screening en eventuele andere vereiste controles. Deze gebeurtenis vindt doorgaans plaats in het bronsysteem nadat het een resultaat ‘Geen overeenkomst’ van World-Check heeft ontvangen.
Waarom dit belangrijk is Dit markeert de succesvolle uitkomst van het onboardingproces. De tijd tussen het indienen van de aanvraag en dit moment laat zien hoe lang het duurt voordat een nieuwe klant wordt goedgekeurd. Waar vind je dit? Deze gebeurtenis komt niet standaard voor in World-Check. De data moet afkomstig zijn uit het bovenliggende CRM- of kernsysteem voor aanvragen, waar het definitieve bedrijfsbesluit wordt genomen. Vastleggen Gebeurtenis die in het bronsysteem wordt vastgelegd zodra de aanvraag definitief is goedgekeurd. Gebeurtenistype explicit
	Aanvullende informatie opgevraagd	De analist stelt vast dat er meer informatie nodig is om de mogelijke overeenkomst te beoordelen en vraagt die op bij de bedrijfseenheid. De case blijft in behandeling totdat de informatie is aangeleverd.
Waarom dit belangrijk is Als deze activiteit vaak voorkomt, wijst dat op problemen met de kwaliteit van de oorspronkelijke data voor de screening. De activiteit leidt tot aanzienlijke vertraging, omdat andere teams de informatie moeten aanleveren. Dit is een belangrijke oorzaak van lange doorlooptijden. Waar vind je dit? Dit kan een expliciete gebruikersactie zijn die wordt vastgelegd in de casenotities of het auditlogboek. Je kunt de gebeurtenis ook afleiden uit een statuswijziging van de case naar ‘Wacht op informatie’ of ‘RFI’. Vastleggen Wordt vastgelegd wanneer een analist een functie gebruikt om aan te geven dat er meer informatie nodig is. Gebeurtenistype explicit
	Case geëscaleerd voor beoordeling	Een eerstelijnsanalist escaleert een ingewikkelde case of een case met een hoog risico naar een senior analist of manager voor een definitief besluit. Dit is een belangrijk overdrachtsmoment binnen het complianceteam.
Waarom dit belangrijk is Escalaties veroorzaken vaak bottlenecks en verlengen de doorlooptijd. Door de frequentie en redenen van escalaties te analyseren, kun je opleidingsbehoeften bij junior analisten of onduidelijkheid in het beoordelingsbeleid opsporen. Waar vind je dit? Vastgelegd als expliciete actie in de workflow of het auditspoor van de case. Je kunt dit ook afleiden uit een wijziging van de toegewezen gebruiker, vooral als de case wordt toegewezen aan iemand met meer bevoegdheden. Vastleggen Vastgelegd via een aparte knop ‘Escaleren’ of een workflowactie in de case. Gebeurtenistype explicit
	Geautomatiseerde screening uitgevoerd	Het World-Check-systeem controleert automatisch de gegevens van de klant aan de hand van de database met risico-informatie. Deze systeemactiviteit levert een eerste reeks resultaten op, zoals mogelijke overeenkomsten of de status ‘Geen overeenkomst’.
Waarom dit belangrijk is Dit is de eerste stap in het screeningsproces die waarde toevoegt. Vertraging vóór deze stap wijst op problemen met het systeem of de beschikbaarheid van data. De uitkomst bepaalt hoeveel handmatig werk daarna nodig is. Waar vind je dit? Deze gebeurtenis kan expliciet worden vastgelegd in het auditspoor van de case. Je kunt de gebeurtenis ook afleiden uit de timestamp waarop de eerste screeningsresultaten voor de case beschikbaar komen. Vastleggen Systeemlogboekvermelding die wordt aangemaakt zodra de geautomatiseerde databasescan is voltooid. Gebeurtenistype explicit
	Mogelijke overeenkomst gevonden	De geautomatiseerde screening heeft een of meer mogelijke overeenkomsten gevonden die een analist handmatig moet beoordelen. De case gaat hiermee van een geautomatiseerde status naar een wachtrij voor handmatig onderzoek.
Waarom dit belangrijk is Dit is een belangrijk splitsingspunt in het proces. Cases met mogelijke overeenkomsten volgen een langer en ingewikkelder traject. Door deze cases te volgen, kan het reviewteam de inzet van medewerkers plannen en bottlenecks analyseren. Waar vind je dit? Af te leiden uit een statuswijziging van de case naar ‘Beoordeling vereist’, ‘Mogelijke overeenkomst’ of een vergelijkbare status in de casemanagementmodule van World-Check. Vastleggen Afgeleid van een statuswijziging van de case die aangeeft dat handmatige beoordeling nodig is. Gebeurtenistype inferred
	Vals-positieve overeenkomst bevestigd	De analist concludeert dat de mogelijke overeenkomst niet dezelfde persoon of entiteit is als de gescreende klant. De overeenkomst wordt afgewezen en de screening van deze melding is afgerond.
Waarom dit belangrijk is Dit is een veelvoorkomende uitkomst van het beoordelingsproces. Door te meten hoe lang het duurt om vals-positieve overeenkomsten af te handelen, krijg je inzicht in de efficiëntie van analisten en de nauwkeurigheid van de geautomatiseerde screening. Waar vind je dit? Dit is een expliciete gebruikersactie waarbij de analist een specifieke overeenkomst afhandelt als ‘Vals-positief’ of ‘Geen overeenkomst’. Deze actie wordt doorgaans vastgelegd in de casgeschiedenis. Vastleggen Wordt vastgelegd wanneer een analist een mogelijke overeenkomst formeel afwijst in het systeem. Gebeurtenistype explicit

Aanbevolen Optioneel

Extractiegidsen

Zo haal je data uit Refinitiv World-Check

Stappen

Meld je aan bij World-Check One: Open het Refinitiv World-Check One-portaal met je inloggegevens.
Ga naar Case Management: Open het onderdeel Case Management, waar alle screeningscases worden opgeslagen en beheerd.
Bereid de export van het caserapport voor: Ga in Case Management naar de rapportage- of exportfunctie. Deze kan 'Export Cases' of 'Case Report' heten.
Stel het caserapport in: Selecteer de kolommen voor de export. Neem velden op voor de Case ID (CustomerApplication), aanmaakdatum, afhandelingsdatum, casestatus (bijvoorbeeld Clear of Match Found) en risiconiveau.
Exporteer de Case Management-data: Stel een datumbereik in, meestal de afgelopen 3 tot 6 maanden. Pas zo nodig filters toe, bijvoorbeeld op gebruikersgroep of casetype. Exporteer de data als CSV-bestand en noem het case_report.csv.
Bereid de export van het auditspoor voor: Ga in World-Check One naar de rapportage voor het auditspoor of de auditlog. Hier staan de gedetailleerde gebeurtenisgeschiedenissen van elke case.
Stel het auditspoor in en exporteer het: Selecteer alle relevante kolommen, waaronder de Case ID, de naam of beschrijving van de gebeurtenis, de timestamp van de gebeurtenis en de gebruiker die de actie heeft uitgevoerd. Exporteer de data over hetzelfde datumbereik als het caserapport. Sla het bestand op als audit_trail.csv.
Verzamel externe processtappen: Haal data op voor activiteiten buiten World-Check, zoals Application Submitted, Application Approved, Account Activated en Application Rejected. Deze data komt meestal uit een CRM- of corebankingsysteem. Exporteer de data met de ID CustomerApplication en de relevante timestamps.
Combineer en transformeer de data: Laad de geëxporteerde CSV-bestanden (case_report.csv, audit_trail.csv en de data uit het externe systeem) in een datavoorbereidingstool of script.
Koppel auditgebeurtenissen aan activiteiten: Verwerk het bestand audit_trail.csv. Koppel de onbewerkte gebeurtenisbeschrijvingen uit de auditlog aan gestandaardiseerde waarden voor ActivityName. Een auditlogregel als 'Case Assigned to Analyst' wordt bijvoorbeeld 'Beoordeling door analist gestart'.
Koppel statuswijzigingen van cases aan activiteiten: Verwerk het bestand case_report.csv en maak activiteiten aan op basis van statuswijzigingen. Gebruik de afhandelingsdatum en eindstatus van de case om de gebeurtenissen 'Screening afgerond - geen overeenkomst' of 'Screening afgerond - overeenkomst gevonden' aan te maken.
Maak het definitieve event log: Voeg alle verwerkte data uit de verschillende bronbestanden samen in één CSV-bestand. Zorg dat het bestand de verplichte kolommen CustomerApplication, ActivityName en EventTime bevat, plus eventuele aanbevolen attributen. Sla het bestand op om het te uploaden naar de process mining-tool.

Configuratie

Rapporttypen: Maak ten minste twee aparte rapporten: een samenvattend Case Management-rapport en een gedetailleerd rapport van het auditspoor.
Datumbereik: Kies voor een eerste analyse een periode van minstens 3 tot 6 maanden, zodat je genoeg afgeronde en lopende cases hebt. Gebruik voor alle geëxporteerde bestanden hetzelfde datumbereik.
Exportformaat: Kies CSV (Comma Separated Values) als exportformaat, zodat de data eenvoudig te verwerken is.
Belangrijke kolommen (caserapport): Neem in de case-export de Case ID, Creation Timestamp, Resolution Timestamp, Final Status, Assigned Analyst en Risk Level op.
Belangrijke kolommen (auditspoorrapport): Neem in de auditlogexport de Case ID, Event Description, Event Timestamp en User ID op.
Vereisten: Je hebt toegang nodig tot het World-Check One-portaal en gebruikersrechten om casemanagement- en auditlogdata te bekijken en te exporteren. Hiervoor zijn mogelijk ruimere rechten nodig dan die van een standaardanalist.

a Voorbeeldquery sql

/*
This is a configuration and mapping guide, not an executable script. 
The process relies on manually exporting two reports from World-Check One and combining them with data from an upstream system (e.g., CRM).
*/

-- Step 1: Export 'Case Management Report' as case_report.csv
-- Step 2: Export 'Audit Trail Report' as audit_trail.csv
-- Step 3: Export relevant events from CRM/core system as source_system_events.csv

-- Step 4: Combine and map the files using a script or ETL tool to create the final event log.

-- Mapping logic for final_event_log.csv

-- Part A: Data from source_system_events.csv
SELECT
  ApplicationID AS CustomerApplication,
  'Application Submitted' AS ActivityName,
  SubmissionTimestamp AS EventTime,
  NULL AS EventEndTime,
  OriginatorID AS ReviewerId,
  OriginatingDept AS DepartmentName,
  RiskRating AS RiskLevel,
  SlaDate AS SlaTargetDate
FROM source_system_events.csv
WHERE EventType = 'Submission'

UNION ALL

SELECT
  ApplicationID AS CustomerApplication,
  'Application Approved' AS ActivityName,
  ApprovalTimestamp AS EventTime,
  NULL AS EventEndTime,
  ApproverID AS ReviewerId,
  ApprovingDept AS DepartmentName,
  RiskRating AS RiskLevel,
  SlaDate AS SlaTargetDate
FROM source_system_events.csv
WHERE EventType = 'Approval'

UNION ALL

SELECT
  ApplicationID AS CustomerApplication,
  'Account Activated' AS ActivityName,
  ActivationTimestamp AS EventTime,
  NULL AS EventEndTime,
  'SYSTEM' AS ReviewerId,
  'Operations' AS DepartmentName,
  RiskRating AS RiskLevel,
  SlaDate AS SlaTargetDate
FROM source_system_events.csv
WHERE EventType = 'Activation'

UNION ALL

SELECT
  ApplicationID AS CustomerApplication,
  'Application Rejected' AS ActivityName,
  RejectionTimestamp AS EventTime,
  NULL AS EventEndTime,
  ReviewerID AS ReviewerId,
  'Compliance' AS DepartmentName,
  RiskRating AS RiskLevel,
  SlaDate AS SlaTargetDate
FROM source_system_events.csv
WHERE EventType = 'Rejection'

-- Part B: Data from World-Check audit_trail.csv
UNION ALL

SELECT
  CaseID AS CustomerApplication,
  'Screening Request Created' AS ActivityName,
  EventTimestamp AS EventTime,
  NULL AS EventEndTime,
  UserID AS ReviewerId,
  'Compliance' AS DepartmentName,
  NULL AS RiskLevel,
  NULL AS SlaTargetDate
FROM audit_trail.csv
WHERE EventDescription LIKE '%Case Created%'

UNION ALL

SELECT
  CaseID AS CustomerApplication,
  'Automated Screening Performed' AS ActivityName,
  EventTimestamp AS EventTime,
  NULL AS EventEndTime,
  'SYSTEM' AS ReviewerId,
  'Compliance' AS DepartmentName,
  NULL AS RiskLevel,
  NULL AS SlaTargetDate
FROM audit_trail.csv
WHERE EventDescription LIKE '%Automated Screening Completed%'

UNION ALL

SELECT
  CaseID AS CustomerApplication,
  'Potential Match Identified' AS ActivityName,
  EventTimestamp AS EventTime,
  NULL AS EventEndTime,
  'SYSTEM' AS ReviewerId,
  'Compliance' AS DepartmentName,
  NULL AS RiskLevel,
  NULL AS SlaTargetDate
FROM audit_trail.csv
WHERE EventDescription LIKE '%Potential Match Found%'

UNION ALL

SELECT
  CaseID AS CustomerApplication,
  'Analyst Review Started' AS ActivityName,
  EventTimestamp AS EventTime,
  NULL AS EventEndTime,
  UserID AS ReviewerId,
  'Compliance' AS DepartmentName,
  NULL AS RiskLevel,
  NULL AS SlaTargetDate
FROM audit_trail.csv
WHERE EventDescription LIKE '%Case Assigned%' OR EventDescription LIKE '%Review Started%'

UNION ALL

SELECT
  CaseID AS CustomerApplication,
  'Additional Information Requested' AS ActivityName,
  EventTimestamp AS EventTime,
  NULL AS EventEndTime,
  UserID AS ReviewerId,
  'Compliance' AS DepartmentName,
  NULL AS RiskLevel,
  NULL AS SlaTargetDate
FROM audit_trail.csv
WHERE EventDescription LIKE '%Information Requested%'

UNION ALL

SELECT
  CaseID AS CustomerApplication,
  'Case Escalated for Review' AS ActivityName,
  EventTimestamp AS EventTime,
  NULL AS EventEndTime,
  UserID AS ReviewerId,
  'Compliance' AS DepartmentName,
  NULL AS RiskLevel,
  NULL AS SlaTargetDate
FROM audit_trail.csv
WHERE EventDescription LIKE '%Case Escalated%'

UNION ALL

SELECT
  CaseID AS CustomerApplication,
  'False Positive Confirmed' AS ActivityName,
  EventTimestamp AS EventTime,
  NULL AS EventEndTime,
  UserID AS ReviewerId,
  'Compliance' AS DepartmentName,
  NULL AS RiskLevel,
  NULL AS SlaTargetDate
FROM audit_trail.csv
WHERE EventDescription LIKE '%Match Dismissed as False Positive%'

UNION ALL

SELECT
  CaseID AS CustomerApplication,
  'True Match Confirmed' AS ActivityName,
  EventTimestamp AS EventTime,
  NULL AS EventEndTime,
  UserID AS ReviewerId,
  'Compliance' AS DepartmentName,
  NULL AS RiskLevel,
  NULL AS SlaTargetDate
FROM audit_trail.csv
WHERE EventDescription LIKE '%Match Confirmed as True%'

-- Part C: Data from World-Check case_report.csv
UNION ALL

SELECT
  CaseID AS CustomerApplication,
  'Screening Completed - Clear' AS ActivityName,
  ResolutionTimestamp AS EventTime,
  NULL AS EventEndTime,
  ResolverID AS ReviewerId,
  'Compliance' AS DepartmentName,
  RiskLevel AS RiskLevel,
  NULL AS SlaTargetDate
FROM case_report.csv
WHERE FinalStatus = 'Clear'

UNION ALL

SELECT
  CaseID AS CustomerApplication,
  'Screening Completed - Match Found' AS ActivityName,
  ResolutionTimestamp AS EventTime,
  NULL AS EventEndTime,
  ResolverID AS ReviewerId,
  'Compliance' AS DepartmentName,
  RiskLevel AS RiskLevel,
  NULL AS SlaTargetDate
FROM case_report.csv
WHERE FinalStatus = 'Match Found'

Stappen

Vereisten en installatie: Installeer Python 3.6 of hoger, samen met de bibliotheken requests en pandas. Vraag je Refinitiv-contactpersoon of het ontwikkelaarsportaal om je World-Check One API Key en API Secret. Bewaar deze gegevens veilig.
Stel de authenticatie in: Maak in je Python-script een functie die een POST-verzoek naar het authenticatie-eindpunt van World-Check One stuurt. Gebruik je API Key en Secret om een tijdelijk bearer token op te halen. Dat token is nodig voor de volgende API-aanroepen.
Bepaal de data uit het bronsysteem: Het proces begint en eindigt buiten World-Check. Bepaal welk bronsysteem, zoals een CRM of corebankingplatform, de oorspronkelijke aanvraagdata bevat. Haal hier gebeurtenissen op zoals Application Submitted, Application Approved, Account Activated en Application Rejected. Dit kan met een databasequery of een andere API.
Haal World-Check-cases op: Gebruik het geauthenticeerde token om een GET-verzoek naar het /cases-eindpunt van de World-Check One API te sturen. Gebruik queryparameters om cases binnen een bepaald datumbereik te filteren, bijvoorbeeld op aanmaak- of wijzigingsdatum.
Verwerk API-paginering: Antwoorden van de World-Check API zijn gepagineerd. Je script moet de pagineringsgegevens in het antwoord controleren en alle pagina's doorlopen om de volledige lijst met cases voor het gekozen datumbereik op te halen.
Haal casedetails en geschiedenis op: Stuur voor elke opgehaalde case-ID aanvullende GET-verzoeken naar eindpunten zoals /cases/{case_system_id} en /cases/{case_system_id}/audit-trail. Deze eindpunten bevatten gedetailleerde statuswijzigingen, afhandelingsgegevens en gebruikersacties voor de case.
Koppel onbewerkte data aan activiteiten: Dit is een belangrijke transformatiestap. Schrijf logica die voor elke case de API-gegevens doorloopt, zoals casedetails en het auditspoor. Koppel specifieke statuswijzigingen, resultaatcodes en auditgebeurtenissen aan de vereiste bedrijfsactiviteiten. Een case-aanmaakgebeurtenis wordt bijvoorbeeld Screening Request Created; een afhandelingsresultaat False Positive wordt False Positive Confirmed.
Combineer databronnen: Voeg de data uit World-Check samen met de data uit het bronsysteem (uit stap 3). Gebruik de ID CustomerApplication als gemeenschappelijke sleutel om voor elke klant een volledig event log van begin tot eind te maken.
Structureer en verrijk de data: Verzamel alle gekoppelde gebeurtenissen in één lijst met records. Vul voor elk record de verplichte attributen (CustomerApplication, ActivityName, EventTime) en de aanbevolen attributen in. Bereken waar mogelijk EventEndTime, bijvoorbeeld met de timestamp van de volgende gebeurtenis voor die case.
Exporteer naar CSV: Zet de uiteindelijke lijst met gebeurtenisrecords om in een pandas DataFrame. Zet de kolommen in de vereiste volgorde en exporteer het DataFrame naar een CSV-bestand. Sla het bestand op met UTF-8-codering, zodat het compatibel is met ProcessMind.

Configuratie

API-inloggegevens: Je hebt een geldige API Key en API Secret nodig voor de World-Check One Screening API. Deze moeten de juiste rechten hebben om case- en auditdata te lezen.
API-basis-URL: Stel het script in met de juiste basis-URL voor je World-Check API-omgeving, bijvoorbeeld https://api.world-check.com/v2/.
Datumbereik: Voeg de parameters start_date en end_date toe aan het script om de extractieperiode in te stellen. Voor een eerste analyse wordt een periode van 3 tot 6 maanden aanbevolen. Voer het script voor doorlopende monitoring met kortere perioden uit, bijvoorbeeld voor de vorige dag of week.
Verbinding met het bronsysteem: Je hebt verbindingsgegevens nodig voor de upstream- en downstreamsystemen, zoals een CRM of corebankingplatform, om gebeurtenissen buiten de screening op te halen. Dit kan een databaseverbindingsreeks zijn of een ander API-eindpunt met inloggegevens.
Paginering verwerken: Stel bij API-aanroepen om cases op te halen een paginagrootte in, vaak limit genoemd. Een waarde tussen 50 en 100 werkt meestal efficiënt. De logica moet alle pagina's ophalen.

a Voorbeeldquery python

import requests
import pandas as pd
from datetime import datetime, timedelta

class=class="hl-string">"hl-comment"># --- Configuration and Placeholders ---
WC_API_KEY = class="hl-string">'[Your World-Check API Key]'
WC_API_SECRET = class="hl-string">'[Your World-Check API Secret]'
WC_API_BASE_URL = class="hl-string">'https://api.world-check.com/v2' class=class="hl-string">"hl-comment"># Use correct URL for your environment

class=class="hl-string">"hl-comment"># Date range for the extraction
START_DATE = (datetime.now() - timedelta(days=90)).strftime(class="hl-string">'%Y-%m-%dT%H:%M:%SZ')
END_DATE = datetime.now().strftime(class="hl-string">'%Y-%m-%dT%H:%M:%SZ')

class=class="hl-string">"hl-comment"># --- MOCK FUNCTIONS (Replace with actual data source connections) ---

def get_source_system_events(application_ids):
    class="hl-string">"""Simulates fetching pre- and post-screening events from a CRM or core system."""
    print(fclass="hl-string">'Fetching source system events for {len(application_ids)} applications...')
    mock_events = []
    for i, app_id in enumerate(application_ids):
        class=class="hl-string">"hl-comment"># Simulate initial application events
        mock_events.append({class="hl-string">'CustomerApplication': app_id, class="hl-string">'ActivityName': class="hl-string">'Application Submitted', class="hl-string">'EventTime': (datetime.now() - timedelta(days=i+5)).isoformat() + class="hl-string">'Z', class="hl-string">'DepartmentName': class="hl-string">'Sales'})
        class=class="hl-string">"hl-comment"># Simulate final outcome events
        if i % 3 == 0:
            mock_events.append({class="hl-string">'CustomerApplication': app_id, class="hl-string">'ActivityName': class="hl-string">'Application Approved', class="hl-string">'EventTime': (datetime.now() - timedelta(days=i)).isoformat() + class="hl-string">'Z', class="hl-string">'DepartmentName': class="hl-string">'Onboarding'})
            mock_events.append({class="hl-string">'CustomerApplication': app_id, class="hl-string">'ActivityName': class="hl-string">'Account Activated', class="hl-string">'EventTime': (datetime.now() - timedelta(days=i-1)).isoformat() + class="hl-string">'Z', class="hl-string">'DepartmentName': class="hl-string">'Operations'})
        else:
            mock_events.append({class="hl-string">'CustomerApplication': app_id, class="hl-string">'ActivityName': class="hl-string">'Application Rejected', class="hl-string">'EventTime': (datetime.now() - timedelta(days=i)).isoformat() + class="hl-string">'Z', class="hl-string">'DepartmentName': class="hl-string">'Compliance'})
    return mock_events

def get_worldcheck_cases(token):
    class="hl-string">"""Simulates fetching a list of cases from the World-Check API."""
    print(class="hl-string">'Fetching World-Check cases...')
    class=class="hl-string">"hl-comment"># In a real implementation, you would call GET /cases with date filters and handle pagination
    mock_case_list = [
        {class="hl-string">'caseId': class="hl-string">'0a1b2c3d-case-001', class="hl-string">'name': class="hl-string">'John Doe', class="hl-string">'caseSystemId': class="hl-string">'WC-001', class="hl-string">'customReference': class="hl-string">'APP-1001', class="hl-string">'creationDate': class="hl-string">'2023-10-01T10:00:00Z', class="hl-string">'riskLevel': class="hl-string">'Medium'},
        {class="hl-string">'caseId': class="hl-string">'0a1b2c3d-case-002', class="hl-string">'name': class="hl-string">'Jane Smith', class="hl-string">'caseSystemId': class="hl-string">'WC-002', class="hl-string">'customReference': class="hl-string">'APP-1002', class="hl-string">'creationDate': class="hl-string">'2023-10-02T11:30:00Z', class="hl-string">'riskLevel': class="hl-string">'Low'},
        {class="hl-string">'caseId': class="hl-string">'0a1b2c3d-case-003', class="hl-string">'name': class="hl-string">'Peter Jones', class="hl-string">'caseSystemId': class="hl-string">'WC-003', class="hl-string">'customReference': class="hl-string">'APP-1003', class="hl-string">'creationDate': class="hl-string">'2023-10-03T09:05:00Z', class="hl-string">'riskLevel': class="hl-string">'High'}
    ]
    return mock_case_list

def get_worldcheck_case_details(case_system_id, token):
    class="hl-string">"""Simulates fetching the audit trail and results for a single World-Check case."""
    print(fclass="hl-string">'Fetching details for case {case_system_id}...')
    class=class="hl-string">"hl-comment"># This mock data simulates a complex history for one case to generate multiple activities
    if case_system_id == class="hl-string">'WC-001':
        return {
            class="hl-string">'auditTrail': [
                {class="hl-string">'timestamp': class="hl-string">'2023-10-01T10:05:00Z', class="hl-string">'event': class="hl-string">'AUTOMATED_SCREENING', class="hl-string">'details': class="hl-string">'Screening performed', class="hl-string">'user': class="hl-string">'SYSTEM'},
                {class="hl-string">'timestamp': class="hl-string">'2023-10-01T10:06:00Z', class="hl-string">'event': class="hl-string">'MATCH_FOUND', class="hl-string">'details': class="hl-string">'Potential match identified', class="hl-string">'user': class="hl-string">'SYSTEM'},
                {class="hl-string">'timestamp': class="hl-string">'2023-10-02T14:00:00Z', class="hl-string">'event': class="hl-string">'REVIEW_STARTED', class="hl-string">'details': class="hl-string">'Case assigned', class="hl-string">'user': class="hl-string">'analyst1'},
                {class="hl-string">'timestamp': class="hl-string">'2023-10-02T15:30:00Z', class="hl-string">'event': class="hl-string">'MATCH_RESOLVED', class="hl-string">'details': class="hl-string">'Match resolved as False Positive', class="hl-string">'user': class="hl-string">'analyst1'},
                {class="hl-string">'timestamp': class="hl-string">'2023-10-03T11:00:00Z', class="hl-string">'event': class="hl-string">'ESCALATED', class="hl-string">'details': class="hl-string">'Case escalated to senior analyst', class="hl-string">'user': class="hl-string">'analyst1'},
                {class="hl-string">'timestamp': class="hl-string">'2023-10-04T09:00:00Z', class="hl-string">'event': class="hl-string">'INFORMATION_REQUESTED', class="hl-string">'details': class="hl-string">'Additional documents requested', class="hl-string">'user': class="hl-string">'senior_analyst'},
                {class="hl-string">'timestamp': class="hl-string">'2023-10-05T16:00:00Z', class="hl-string">'event': class="hl-string">'CASE_CLOSED', class="hl-string">'details': class="hl-string">'Case closed as Clear', class="hl-string">'user': class="hl-string">'senior_analyst'}
            ]
        }
    elif case_system_id == class="hl-string">'WC-003':
        return {
            class="hl-string">'auditTrail': [
                {class="hl-string">'timestamp': class="hl-string">'2023-10-03T09:10:00Z', class="hl-string">'event': class="hl-string">'AUTOMATED_SCREENING', class="hl-string">'details': class="hl-string">'Screening performed', class="hl-string">'user': class="hl-string">'SYSTEM'},
                {class="hl-string">'timestamp': class="hl-string">'2023-10-03T09:11:00Z', class="hl-string">'event': class="hl-string">'MATCH_FOUND', class="hl-string">'details': class="hl-string">'Potential match identified', class="hl-string">'user': class="hl-string">'SYSTEM'},
                {class="hl-string">'timestamp': class="hl-string">'2023-10-04T10:00:00Z', class="hl-string">'event': class="hl-string">'REVIEW_STARTED', class="hl-string">'details': class="hl-string">'Case assigned', class="hl-string">'user': class="hl-string">'analyst2'},
                {class="hl-string">'timestamp': class="hl-string">'2023-10-04T11:25:00Z', class="hl-string">'event': class="hl-string">'MATCH_RESOLVED', class="hl-string">'details': class="hl-string">'Match resolved as True Positive', class="hl-string">'user': class="hl-string">'analyst2'},
                {class="hl-string">'timestamp': class="hl-string">'2023-10-04T12:00:00Z', class="hl-string">'event': class="hl-string">'CASE_CLOSED', class="hl-string">'details': class="hl-string">'Case closed with matches', class="hl-string">'user': class="hl-string">'analyst2'}
            ]
        }
    else: class=class="hl-string">"hl-comment"># Simple class="hl-string">'Clear' case
        return {
            class="hl-string">'auditTrail': [
                {class="hl-string">'timestamp': class="hl-string">'2023-10-02T11:35:00Z', class="hl-string">'event': class="hl-string">'AUTOMATED_SCREENING', class="hl-string">'details': class="hl-string">'Screening performed', class="hl-string">'user': class="hl-string">'SYSTEM'},
                {class="hl-string">'timestamp': class="hl-string">'2023-10-02T11:36:00Z', class="hl-string">'event': class="hl-string">'CASE_CLOSED', class="hl-string">'details': class="hl-string">'Case closed as Clear', class="hl-string">'user': class="hl-string">'SYSTEM'}
            ]
        }

class=class="hl-string">"hl-comment"># --- Main Extraction Logic ---

def main():
    class="hl-string">"""Main function to run the extraction process."""
    class=class="hl-string">"hl-comment"># 1. Authenticate (real implementation)
    class=class="hl-string">"hl-comment"># token = get_wc_auth_token()
    token = class="hl-string">'mock_token' class=class="hl-string">"hl-comment"># Using a mock token for this example

    class=class="hl-string">"hl-comment"># 2. Get list of cases from World-Check
    cases = get_worldcheck_cases(token)
    if not cases:
        print(class="hl-string">'No cases found for the specified period.')
        return

    event_log = []

    class=class="hl-string">"hl-comment"># 3. Process each case from World-Check
    for case in cases:
        app_id = case.get(class="hl-string">'customReference')
        if not app_id:
            continue

        class=class="hl-string">"hl-comment"># Add class="hl-string">'Screening Request Created' event
        event_log.append({
            class="hl-string">'CustomerApplication': app_id,
            class="hl-string">'ActivityName': class="hl-string">'Screening Request Created',
            class="hl-string">'EventTime': case[class="hl-string">'creationDate'],
            class="hl-string">'ReviewerId': class="hl-string">'SYSTEM',
            class="hl-string">'DepartmentName': class="hl-string">'Compliance',
            class="hl-string">'RiskLevel': case.get(class="hl-string">'riskLevel')
        })

        details = get_worldcheck_case_details(case[class="hl-string">'caseSystemId'], token)
        for event in details.get(class="hl-string">'auditTrail', []):
            activity = None
            user = event.get(class="hl-string">'user', class="hl-string">'SYSTEM')
            department = class="hl-string">'Compliance' if user != class="hl-string">'SYSTEM' else class="hl-string">'System'
            
            class=class="hl-string">"hl-comment"># 4. Map audit trail events to activities
            if event[class="hl-string">'event'] == class="hl-string">'AUTOMATED_SCREENING':
                activity = class="hl-string">'Automated Screening Performed'
            elif event[class="hl-string">'event'] == class="hl-string">'MATCH_FOUND':
                activity = class="hl-string">'Potential Match Identified'
            elif event[class="hl-string">'event'] == class="hl-string">'REVIEW_STARTED':
                activity = class="hl-string">'Analyst Review Started'
            elif event[class="hl-string">'event'] == class="hl-string">'INFORMATION_REQUESTED':
                activity = class="hl-string">'Additional Information Requested'
            elif event[class="hl-string">'event'] == class="hl-string">'ESCALATED':
                activity = class="hl-string">'Case Escalated for Review'
            elif event[class="hl-string">'event'] == class="hl-string">'MATCH_RESOLVED' and class="hl-string">'False Positive' in event[class="hl-string">'details']:
                activity = class="hl-string">'False Positive Confirmed'
            elif event[class="hl-string">'event'] == class="hl-string">'MATCH_RESOLVED' and class="hl-string">'True Positive' in event[class="hl-string">'details']:
                activity = class="hl-string">'True Match Confirmed'
            elif event[class="hl-string">'event'] == class="hl-string">'CASE_CLOSED' and class="hl-string">'Clear' in event[class="hl-string">'details']:
                activity = class="hl-string">'Screening Completed - Clear'
            elif event[class="hl-string">'event'] == class="hl-string">'CASE_CLOSED' and class="hl-string">'matches' in event[class="hl-string">'details']:
                activity = class="hl-string">'Screening Completed - Match Found'

            if activity:
                event_log.append({
                    class="hl-string">'CustomerApplication': app_id,
                    class="hl-string">'ActivityName': activity,
                    class="hl-string">'EventTime': event[class="hl-string">'timestamp'],
                    class="hl-string">'ReviewerId': user,
                    class="hl-string">'DepartmentName': department,
                    class="hl-string">'RiskLevel': case.get(class="hl-string">'riskLevel')
                })
    
    class=class="hl-string">"hl-comment"># 5. Get events from source system
    application_ids = [case[class="hl-string">'customReference'] for case in cases if case.get(class="hl-string">'customReference')]
    source_events = get_source_system_events(application_ids)
    event_log.extend(source_events)

    class=class="hl-string">"hl-comment"># 6. Create and format DataFrame
    if not event_log:
        print(class="hl-string">'No events were generated.')
        return

    df = pd.DataFrame(event_log)
    df[class="hl-string">'EventTime'] = pd.to_datetime(df[class="hl-string">'EventTime'])
    df = df.sort_values(by=[class="hl-string">'CustomerApplication', class="hl-string">'EventTime'])

    class=class="hl-string">"hl-comment"># Add EventEndTime by shifting the EventTime of the next event
    df[class="hl-string">'EventEndTime'] = df.groupby(class="hl-string">'CustomerApplication')[class="hl-string">'EventTime'].shift(-1)
    
    class=class="hl-string">"hl-comment"># Add placeholder for non-extractable attribute
    df[class="hl-string">'SlaTargetDate'] = pd.NaT

    class=class="hl-string">"hl-comment"># 7. Finalize and Export
    output_columns = [
        class="hl-string">'CustomerApplication',
        class="hl-string">'ActivityName',
        class="hl-string">'EventTime',
        class="hl-string">'EventEndTime',
        class="hl-string">'ReviewerId',
        class="hl-string">'DepartmentName',
        class="hl-string">'RiskLevel',
        class="hl-string">'SlaTargetDate'
    ]
    class=class="hl-string">"hl-comment"># Ensure all required columns exist, even if empty
    for col in output_columns:
        if col not in df.columns:
            df[col] = None
    
    df = df[output_columns]

    output_filename = class="hl-string">'event_log_worldcheck.csv'
    df.to_csv(output_filename, index=False, date_format=class="hl-string">'%Y-%m-%dT%H:%M:%S.%fZ')
    print(fclass="hl-string">'Successfully exported event log to {output_filename}')

if __name__ == class="hl-string">'__main__':
    main()

Klaar om te beginnen?

Gebruik deze datatemplate als startpunt voor process mining van KYC-klantonboarding. Volg de richtlijnen om waardevolle inzichten te krijgen en de bedrijfsvoering merkbaar te verbeteren.

Terug naar de verbetergids Template downloaden

Verbeter nu KYC-klantonboarding en versterk compliance

Zorg voor een soepel onboardingproces en verkort de doorlooptijd tot 24 uur.

Start je gratis proefperiode

Geen creditcard nodig. Probeer het 14 dagen gratis.

Datatemplate voor KYC-klantonboarding

Datatemplate voor KYC-klantonboarding

Attributen voor KYC-klantonboarding

Activiteiten voor KYC-klantonboarding

Extractiegidsen

Export van cases en auditlog uit Refinitiv World-Check One

Stappen

Configuratie

a Voorbeeldquery sql

Python-script met de World-Check One Screening API

Stappen

Configuratie

a Voorbeeldquery python

Klaar om te beginnen?

Verbeter nu KYC-klantonboarding en versterk compliance

Datatemplate voor KYC-klantonboarding

Datatemplate voor KYC-klantonboarding

Attributen voor KYC-klantonboarding

Activiteiten voor KYC-klantonboarding

Extractiegidsen

Export van cases en auditlog uit Refinitiv World-Check One

Stappen

Configuratie

a Voorbeeldquery sql

Python-script met de World-Check One Screening API

Stappen

Configuratie

a Voorbeeldquery python

Klaar om te beginnen?

Verbeter nu KYC-klantonboarding en versterk compliance

We gaan zorgvuldig om met je privacy