> Continu verbeteren van processen > KYC klantonboarding > LexisNexis Risk Solutions > Datatemplate

Datatemplate voor KYC-klantacceptatie

LexisNexis Risk Solutions

Attributen voor KYC-klantacceptatie (20) Activiteiten voor KYC-klantacceptatie (14) Extractiegidsen (1)

Datatemplate voor KYC-klantacceptatie

Deze template helpt je de data te verzamelen die nodig is om het KYC-klantacceptatieproces te analyseren. Je vindt hierin welke attributen je verzamelt, welke activiteiten je volgt en hoe je deze informatie uit de bronsystemen haalt. Gebruik deze bron om een volledig event log op te bouwen en het acceptatietraject te analyseren.

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

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

Template downloaden

Attributen voor KYC-klantacceptatie

Dit zijn de aanbevolen datavelden voor je event log. Ze vormen de basis voor een volledige analyse en process discovery van KYC-klantacceptatie.

3 Verplicht 6 Aanbevolen 11 Optioneel

	Naam	Beschrijving
	Activiteitsnaam ActivityName	De naam van de specifieke taak of gebeurtenis die op een bepaald moment tijdens het onboardingproces plaatsvond.
Beschrijving De activiteitsnaam beschrijft een stap in de KYC-onboardingworkflow, zoals ‘Aanvraag ingediend’, ‘Documenten beoordeeld’ of ‘Aanvraag goedgekeurd’. Elke activiteit staat voor een afzonderlijke handeling of mijlpaal in het proces. Dit attribuut is essentieel voor het opstellen van de proceskaart, die de activiteitenstroom visueel weergeeft. Je kunt er procesvarianten mee analyseren, bottlenecks tussen specifieke stappen opsporen en zien hoe vaak herstelwerk voorkomt. Door activiteiten te analyseren, begrijp je wat er in het proces gebeurt. Waarom dit belangrijk is Dit attribuut vormt de basis van de proceskaart. Je kunt er de volgorde van events in de klantreis mee visualiseren en analyseren. Waar vind je dit? Meestal te vinden in een event log of auditspoordatabel in LexisNexis Risk Solutions, waarin processtappen worden bijgehouden. Voorbeelden Aanvraag ingediendEerste screening uitgevoerdDocumenten opgevraagdCompliancebeoordeling afgerond
	Klantaanvraag CustomerApplication	De unieke identificatiecode van elke klantaanvraag voor onboarding, die als primaire case-ID dient.
Beschrijving De klantaanvraag is de centrale identificatiecode die alle activiteiten en datapunten voor de onboarding van één klant met elkaar verbindt. De aanvraag begint wanneer een klant die indient en blijft de case volgen tot deze is afgerond of afgewezen. Bij process mining is dit attribuut essentieel om alle events in één samenhangende case te groeperen. Zo kun je de volledige processtroom voor elke aanvrager reconstrueren en de doorlooptijden berekenen, procesvarianten analyseren en de status van een aanvraag in de tijd volgen. Waarom dit belangrijk is Dit is de primaire case-ID. Zonder deze code kun je de volledige klantaanvraag niet volgen en is procesanalyse onmogelijk. Waar vind je dit? Dit is de primaire case-identificatiecode in de casemanagementmodule van LexisNexis Risk Solutions. Voorbeelden APP-2023-001234APP-2023-005678APP-2024-009101
	Timestamp van event EventTimestamp	De exacte datum en tijd waarop een activiteit is gestart.
Beschrijving Deze timestamp geeft aan wanneer een activiteit begint en bepaalt de chronologische volgorde van alle events binnen een case. Dit vormt de basis voor alle tijdsanalyses bij process mining. Met de timestamp van het event kun je de duur van activiteiten, de wachttijd ertussen en de totale doorlooptijd van het onboardingproces berekenen. Deze data is essentieel om bottlenecks op te sporen, naleving van SLA’s te volgen en de efficiëntie van het proces te begrijpen. Waarom dit belangrijk is Deze timestamp is essentieel om events chronologisch te ordenen en alle tijdsmetriek te berekenen, zoals doorlooptijden en bottlenecks. Waar vind je dit? Te vinden in het event log of de auditspoordtabellen, naast de Activiteitsnaam. Voorbeelden 2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T14:15:00Z
	Aanvraagstatus ApplicationStatus	De huidige of definitieve status van de klantaanvraag.
Beschrijving Dit attribuut geeft de algemene status van een case op een bepaald moment of de uiteindelijke uitkomst weer. Veelvoorkomende statussen zijn ‘In behandeling’, ‘Goedgekeurd’, ‘Afgewezen’ en ‘Wacht op informatie’. Met Aanvraagstatus volg je de uitkomsten van het onboardingproces. Het attribuut wordt gebruikt in de dashboards ‘Redenen en fasen van afgewezen aanvragen’ en ‘Dagelijkse doorvoer en aanvraagstatus’ om succespercentages en de procesgang te volgen. Door statuswijzigingen in de tijd te analyseren, krijg je inzicht in de levenscyclus van een case. Waarom dit belangrijk is Houdt de uitkomst van elke aanvraag bij. Zo kun je belangrijke KPI’s, zoals het afwijzingspercentage, berekenen en de doorvoer volgen. Waar vind je dit? Raadpleeg de documentatie van LexisNexis Risk Solutions of de systeembeheerder. Dit is meestal een belangrijk veld op het hoofdobject van de case of aanvraag. Voorbeelden In behandelingGoedgekeurdAfgewezenWacht op klantinformatie
	Afdeling Department	De bedrijfsafdeling of het team waartoe de toegewezen gebruiker behoort.
Beschrijving Het attribuut Afdeling geeft aan welke functionele groep verantwoordelijk is voor een activiteit, zoals ‘Compliance’, ‘Onboarding’ of ‘Fraudepreventie’. Met dit attribuut kun je het proces per afdeling analyseren en overdrachten tussen teams bekijken. Het is een belangrijke dimensie in het dashboard ‘Bronverdeling en werkbelasting’ en helpt inefficiënties tussen afdelingen en vertragingen in de communicatie op te sporen. Waarom dit belangrijk is Maakt het mogelijk om overdrachten en prestaties per functioneel gebied te analyseren en bottlenecks tussen afdelingen op te sporen. Waar vind je dit? Raadpleeg de documentatie van LexisNexis Risk Solutions of de systeembeheerder. Mogelijk moet je deze informatie ophalen uit een tabel met gebruikersgegevens of HR-stamgegevens. Voorbeelden ComplianceOnboardingteamKYC-analistenKlantenservice
	Eindtijd EndTime	De exacte datum en tijd waarop een activiteit is afgerond.
Beschrijving Deze timestamp markeert het einde van een activiteit. Het verschil tussen de eindtijd en de starttijd van een event is de verwerkingstijd. De eindtijd is nodig om nauwkeurig te berekenen hoelang elke stap duurt. Die berekening vormt een belangrijke basis voor het dashboard ‘Verwerkings- en wachttijden van activiteiten’. Zo zie je hoeveel tijd een bron actief aan een taak heeft gewerkt en hoelang de case op de volgende stap heeft gewacht. Waarom dit belangrijk is Maakt een nauwkeurige berekening van de verwerkingstijd van activiteiten mogelijk. Dat is nodig om inefficiënte stappen te vinden en de werkbelasting van bronnen te analyseren. Waar vind je dit? Raadpleeg de documentatie van LexisNexis Risk Solutions of de systeembeheerder. Vaak is deze informatie beschikbaar in event logs waarin zowel start- als eindevents worden vastgelegd. Voorbeelden 2023-10-26T10:45:10Z2023-10-26T11:55:30Z2023-10-28T09:05:00Z
	Risiconiveau RiskLevel	Het berekende risiconiveau van de klantaanvraag, bijvoorbeeld laag, gemiddeld of hoog.
Beschrijving LexisNexis Risk Solutions is gespecialiseerd in risicobeoordeling. Dit attribuut bevat de uitkomst daarvan: elke aanvraag wordt ingedeeld op basis van het risicoprofiel. Het risiconiveau bepaalt vaak hoe grondig en hoelang het due diligence-proces moet zijn. Dit attribuut is de belangrijkste dimensie in het dashboard ‘Risiconiveau en onboardingduur’. Door het proces per risiconiveau te analyseren, zie je of aanvragen met een hoog risico inderdaad veel langer duren en of aanvragen met een laag risico onnodig vertraging oplopen. Zo kun je risicogestuurde onboardingstrategieën toetsen en bijstellen. Waarom dit belangrijk is Belangrijk voor risicoanalyses. Je ziet hoe het risicoprofiel van klanten de complexiteit, duur en route van het proces beïnvloedt. Waar vind je dit? Raadpleeg de documentatie van LexisNexis Risk Solutions of de systeembeheerder. Dit is een belangrijke uitkomst van de risicobeoordelingsmodules. Voorbeelden LaagGemiddeldHoogOp sanctielijst
	SLA-streefdatum SlaTargetDate	De datum waarop het onboardingproces voor de klant naar verwachting is afgerond.
Beschrijving De SLA-streefdatum bepaalt wanneer een aanvraag volgens de service level agreement afgerond moet zijn. Deze datum hangt vaak af van factoren zoals het type aanvraag, het klantsegment of de jurisdictie. Dit attribuut is nodig voor het dashboard ‘Bewaking van SLA-doelen’ en de KPI ‘SLA-nalevingspercentage’. Vergelijk de werkelijke afrondingsdatum met de SLA-streefdatum om te zien hoe de organisatie haar afspraken nakomt. Zo vind je cases die het risico lopen de SLA te overschrijden en kun je de oorzaken van vertraging onderzoeken. Waarom dit belangrijk is Maakt het mogelijk om prestaties te meten aan de hand van service level agreements en procesinefficiënties op te sporen die tot SLA-overschrijdingen leiden. Waar vind je dit? Raadpleeg de documentatie van LexisNexis Risk Solutions of de systeembeheerder. De datum kan op de case zijn opgeslagen of op basis van bedrijfsregels worden berekend. Voorbeelden 2023-11-10T17:00:00Z2023-11-15T17:00:00Z2023-12-01T17:00:00Z
	Toegewezen gebruiker AssignedUser	De unieke identificatie van de gebruiker of agent die verantwoordelijk is voor de activiteit.
Beschrijving Dit attribuut geeft aan wie een taak heeft uitgevoerd, bijvoorbeeld een compliance-medewerker die een document beoordeelt. Je kunt hiermee de verdeling van het werk en individuele prestaties analyseren. In analyses is Toegewezen gebruiker een belangrijk veld voor het dashboard ‘Bronverdeling en werkbelasting’. Je kunt de proceskaart filteren op gebruiker, prestaties van teamleden vergelijken en mogelijkheden voor training of een andere werkverdeling vinden. Ook kun je bottlenecks opsporen die door specifieke gebruikersgroepen ontstaan. Waarom dit belangrijk is Dit attribuut is belangrijk voor het analyseren van bronprestaties en de verdeling van het werk, en voor het vinden van mogelijkheden om taken te automatiseren of bronnen efficiënter in te zetten. Waar vind je dit? Raadpleeg de documentatie van LexisNexis Risk Solutions of de systeembeheerder. Meestal staat deze informatie in auditsporen of taakbeheertabellen. Voorbeelden j.doem.smithk.chen
	Aanvraagtype ApplicationType	Het type klantaanvraag, bijvoorbeeld ‘Particulier’ of ‘Bedrijf’.
Beschrijving Dit attribuut deelt aanvragen in op basis van het type entiteit dat wordt onboarded. Verschillende aanvraagtypen volgen vaak een andere procesroute en hebben een ander risicoprofiel en andere SLA-doelen. Door het proces per aanvraagtype te analyseren, kun je de data uitsplitsen en de efficiëntie en complexiteit van onboarding voor verschillende klanttypen vergelijken. Dit is een veelgebruikt filter in dashboards, waarmee je prestaties gedetailleerder kunt bekijken. Waarom dit belangrijk is Maakt een gedetailleerde uitsplitsing van het proces mogelijk. Zo zie je hoe verschillende aanvraagtypen worden afgehandeld en waar per type bottlenecks ontstaan. Waar vind je dit? Raadpleeg de documentatie van LexisNexis Risk Solutions of de systeembeheerder. Dit is meestal een belangrijk veld op het aanvraag- of caseobject. Voorbeelden ParticulierBedrijfVermogende particulierTrust
	Bronsysteem SourceSystem	Het systeem of de applicatie waar de eventdata vandaan komt.
Beschrijving Dit attribuut geeft aan uit welk bronsysteem de eventdata afkomstig is, bijvoorbeeld LexisNexis Risk Solutions of een geïntegreerde tool van een derde partij. In complexe omgevingen kan data voor één proces uit meerdere systemen komen. Het bronsysteem kennen is handig voor datavalidatie, het oplossen van problemen en het analyseren van procesvarianten die specifiek zijn voor een bepaald systeem. Zo kun je de data-integriteit controleren en zie je waar en hoe een activiteit is vastgelegd. Waarom dit belangrijk is Geeft aan waar de data vandaan komt. Dat is belangrijk voor datagovernance, validatie en inzicht in de uitvoering van processen in verschillende IT-systemen. Waar vind je dit? Deze informatie kan als vaste waarde zijn opgeslagen of in een specifiek veld in de data-export of API-respons staan. Voorbeelden LexisNexis Risk SolutionsThreatMetrixBridger Insight XG
	Compliancebeoordelaar ComplianceReviewer	De gebruiker of agent die specifiek is toegewezen aan de compliancebeoordeling.
Beschrijving ‘AssignedUser’ geeft de gebruiker voor elke activiteit aan. Dit attribuut identificeert specifiek de compliancespecialist die betrokken is bij belangrijke beoordelingsstappen. Zo kun je de compliancefunctie gerichter analyseren. Dit attribuut is belangrijk voor het dashboard ‘Duur en achterstand van compliancebeoordelingen’. Je kunt de werkbelasting en prestaties van het complianceteam analyseren en zien of bepaalde beoordelaars bottlenecks vormen of dat het team als geheel te weinig capaciteit heeft. Waarom dit belangrijk is Geeft gericht inzicht in de compliancefunctie. Je kunt de werkbelasting en prestaties van beoordelaars analyseren in deze belangrijke procesfase, die vaak vertraging oploopt. Waar vind je dit? Raadpleeg de documentatie van LexisNexis Risk Solutions of de systeembeheerder. Je kunt dit attribuut afleiden door ‘AssignedUser’ te filteren op complianceactiviteiten. Voorbeelden c.joness.patelsystem_escalation
	Doorlooptijd CycleTime	De totale tijd van begin tot eind van een klantaanvraag, vanaf indiening tot de definitieve beslissing.
Beschrijving Doorlooptijd meet de totale tijd tussen het eerste event, bijvoorbeeld ‘Aanvraag ingediend’, en het laatste event, zoals ‘Klantonboarding afgerond’ of ‘Aanvraag afgewezen’, voor één case. Dit is een belangrijke KPI voor de algemene procesgezondheid en wordt weergegeven in het dashboard ‘Totale doorlooptijd van onboarding’. Door de gemiddelde doorlooptijd te volgen, zie je wat het effect is van procesverbeteringen en hoe factoren zoals risiconiveau of aanvraagtype de totale klantervaring beïnvloeden. Waarom dit belangrijk is Deze KPI meet hoelang het duurt voordat de klant waarde ervaart. Dat heeft direct invloed op de klanttevredenheid en de efficiëntie van de bedrijfsvoering. Waar vind je dit? Dit is een berekende metriek. Per case wordt de timestamp van het eerste event afgetrokken van die van het laatste event. Voorbeelden 5 dagen en 4 uur22 dagen en 8 uur1 dag en 2 uur
	Geautomatiseerd IsAutomated	Een aanduiding die aangeeft of een activiteit automatisch door het systeem of handmatig door een gebruiker is uitgevoerd.
Beschrijving Dit booleaanse attribuut maakt onderscheid tussen taken die door systeemautomatisering worden uitgevoerd, zoals een eerste screening, en taken waarvoor menselijke tussenkomst nodig is, zoals een handmatige documentbeoordeling. ‘Geautomatiseerd’ wordt gebruikt om de KPI ‘Aandeel handmatige activiteiten’ te berekenen en de effectiviteit van automatiseringsinitiatieven te analyseren. Op de proceskaart zie je hiermee waar geautomatiseerde en handmatige stappen op elkaar aansluiten. Zo vind je mogelijkheden om meer taken te automatiseren en kosten en verwerkingstijden te verlagen. Waarom dit belangrijk is Maakt onderscheid tussen handmatige en geautomatiseerde taken. Dat helpt bij het vinden van mogelijkheden voor automatisering en het meten van het effect ervan. Waar vind je dit? Raadpleeg de documentatie van LexisNexis Risk Solutions of de systeembeheerder. Dit kan een aanduiding in het event log zijn of worden afgeleid uit ‘AssignedUser’, bijvoorbeeld als de gebruiker ‘system’ is. Voorbeelden truefalse
	Herstelwerk IsRework	Een aanduiding die activiteiten markeert die deel uitmaken van een herhaalcyclus.
Beschrijving Deze booleaanse aanduiding krijgt de waarde true wanneer een activiteit binnen dezelfde case wordt herhaald. Dat gebeurt bijvoorbeeld als ‘Documentbeoordeling uitgevoerd’ een tweede keer voorkomt nadat om aanvullende informatie is gevraagd. Dit betekent dat het proces een stap terug heeft gezet. ‘Herstelwerk’ is belangrijk voor het dashboard ‘Analyse van herstelwerk en herhalingen’ en de KPI ‘Percentage herhaalcycli’. Je kunt er verspilde inspanning mee kwantificeren en de oorzaken van herstelwerk opsporen, zoals onduidelijke instructies of slechte datakwaliteit. Zo kun je gericht verbeteringen doorvoeren. Waarom dit belangrijk is Maakt inefficiëntie en verspilde inspanning in het proces meetbaar. Je ziet welke activiteiten vaak worden herhaald en de kosten en doorlooptijden verhogen. Waar vind je dit? Dit is een berekend attribuut. De process mining-tool leidt het meestal af door herhaalde reeksen activiteiten binnen een case te detecteren. Voorbeelden truefalse
	Kanaal Channel	Het kanaal waarlangs de aanvraag is ingediend, bijvoorbeeld via internet, mobiel of een kantoor.
Beschrijving Het attribuut Kanaal geeft aan via welke bron de aanvraag is ingediend. Het kanaal kan invloed hebben op de datakwaliteit, het klantgedrag en de problemen die tijdens onboarding optreden. Met dit attribuut vergelijk je de procesprestaties per kanaal. Zo kun je het dashboard ‘Conversiepercentages van de onboardingfunnel’ filteren op kanaal en zien of meer mobiele aanvragers dan webaanvragers afhaken. Die informatie helpt bij het verbeteren van processen per kanaal. Waarom dit belangrijk is Helpt procesprestaties per indieningskanaal te analyseren. Zo vind je verschillen die richting geven aan de kanaalstrategie en verbeteringen in de gebruikerservaring. Waar vind je dit? Raadpleeg de documentatie van LexisNexis Risk Solutions of de systeembeheerder. Deze informatie wordt meestal aan het begin van het aanvraagproces vastgelegd. Voorbeelden WebportaalMobiele appOp kantoorAPI
	Laatste data-update LastDataUpdate	De timestamp die aangeeft wanneer de data voor het laatst is vernieuwd of uit het bronsysteem is opgehaald.
Beschrijving Dit attribuut bevat de timestamp van de laatste update van de dataset. Meestal wordt deze tijdens het extractie- en laadproces aan de hele dataset toegevoegd. Zo kunnen dashboardgebruikers zien hoe actueel de data is die ze analyseren. Beslissingen zijn daardoor gebaseerd op data die actueel genoeg is, en je weet hoe recent de inzichten zijn. Waarom dit belangrijk is Geeft aan hoe actueel de data is, zodat analyses relevant blijven en beslissingen niet op verouderde informatie zijn gebaseerd. Waar vind je dit? Deze waarde wordt meestal tijdens het ETL-proces (Extract, Transform, Load) gegenereerd en aan de dataset toegevoegd. Voorbeelden 2024-01-15T02:00:00Z2024-01-16T02:00:00Z2024-01-17T02:00:00Z
	Land van de klant CustomerCountry	Het land waar de klant woont of is gevestigd.
Beschrijving Dit attribuut geeft het land van de klant aan. Dat is belangrijk voor KYC, omdat internationale regels en risiconiveaus per jurisdictie verschillen. Door het proces per land van de klant te analyseren, kun je verschillen in doorlooptijden en procescomplexiteit vinden. Voor aanvragen uit jurisdicties met een hoog risico zijn bijvoorbeeld extra compliancechecks nodig, waardoor ze langer duren. Deze analyse helpt bij de planning van bronnen en het vaststellen van realistische SLA’s per regio. Waarom dit belangrijk is Maakt analyse per jurisdictie mogelijk. Zo zie je hoe regionale regelgeving en risicofactoren de procesprestaties beïnvloeden. Waar vind je dit? Raadpleeg de documentatie van LexisNexis Risk Solutions of de systeembeheerder. Dit is een standaardveld in de klantstamgegevens. Voorbeelden USAGBRDEUSGP
	Reden van afwijzing RejectionReason	Een code of omschrijving die aangeeft waarom een aanvraag is afgewezen.
Beschrijving Als de definitieve status van een aanvraag ‘Afgewezen’ is, geeft dit attribuut de specifieke reden. Voorbeelden zijn ‘Identiteitscontrole mislukt’, ‘Match met sanctielijst’ en ‘Documentatie onvolledig’. Deze data vormt de belangrijkste basis voor het dashboard ‘Redenen en fasen van afgewezen aanvragen’. Door afwijzingsredenen te analyseren, vind je veelvoorkomende problemen in het proces. Die informatie kan helpen om aanvraagrichtlijnen, klantcommunicatie of interne beoordelingscriteria te verbeteren. Inzicht in de redenen voor afwijzing helpt het totale goedkeuringspercentage te verhogen. Waarom dit belangrijk is Laat zien waarom onboarding mislukt, zodat je gericht verbeteringen kunt doorvoeren en het goedkeuringspercentage kunt verhogen. Waar vind je dit? Raadpleeg de documentatie van LexisNexis Risk Solutions of de systeembeheerder. Vaak staat deze informatie in een veld dat wordt ingevuld wanneer de Aanvraagstatus op ‘Afgewezen’ wordt gezet. Voorbeelden Match met sanctielijstDocumentatie onvolledigIdentiteitscontrole misluktHoog risicoprofiel
	SLA-status SlaStatus	Geeft aan of de afgeronde aanvraag aan de SLA-doelstelling voldeed.
Beschrijving Dit attribuut deelt elke afgeronde case in op basis van de naleving van de ‘SlaTargetDate’. Veelvoorkomende waarden zijn ‘Gehaald’ en ‘Overschreden’. Dit berekende veld vormt de basis voor het dashboard ‘Bewaking van SLA-doelen’ en de KPI ‘SLA-nalevingspercentage’. Het geeft een helder overzicht van de prestaties ten opzichte van serviceafspraken. Je kunt ook verder inzoomen om te zien welke kenmerken vaak voorkomen bij cases waarin de SLA is overschreden. Waarom dit belangrijk is Geeft een duidelijke uitkomst voor de SLA-prestaties, zodat je eenvoudig kunt volgen, rapporteren en analyseren of service level-doelen worden nagekomen. Waar vind je dit? Dit is een berekend attribuut. Per case wordt de timestamp van de laatste activiteit vergeleken met de ‘SlaTargetDate’. Voorbeelden GehaaldOverschredenRisico

Verplicht Aanbevolen Optioneel

Activiteiten voor KYC-klantacceptatie

Leg deze belangrijke processtappen en mijlpalen vast in je event log voor een nauwkeurige process discovery en prestatieanalyse.

8 Aanbevolen 6 Optioneel

	Activiteit	Beschrijving
	Aanvraag afgewezen	Het definitieve besluit om de aanvraag van de klant af te wijzen, wordt vastgelegd. Dit is een eindevent dat wordt geregistreerd als een definitieve statuswijziging in het systeem.
Waarom dit belangrijk is Dit is het belangrijkste eindevent voor een mislukte aanvraag. Door te analyseren in welke fases aanvragen worden afgewezen en waarom, kun je het proces verbeteren. Waar vind je dit? Vastgelegd wanneer het definitieve statusveld van de aanvraag wordt ingesteld op ‘Afgewezen’, ‘Niet goedgekeurd’ of een vergelijkbare eindstatus. Vastleggen Vastgelegd als definitieve statuswijziging in de hoofdtafel voor aanvragen of cases. Gebeurtenistype explicit
	Aanvraag goedgekeurd	Het definitieve besluit om de aanvraag van de klant goed te keuren, wordt genomen en vastgelegd in het systeem. Dit is een belangrijk bedrijfsresultaat en wordt vrijwel altijd als expliciete statuswijziging geregistreerd.
Waarom dit belangrijk is Deze mijlpaal markeert het succesvolle einde van het besluitvormingsproces. Door de routes naar goedkeuring te analyseren, kun je goede werkwijzen vinden. Waar vind je dit? Zoek in het aanvraagdossier naar de definitieve statuswijziging naar ‘Goedgekeurd’ of een vergelijkbare eindstatus. Vastleggen Vastgelegd als definitieve statuswijziging in de hoofdtafel voor aanvragen of cases. Gebeurtenistype explicit
	Aanvraag ingediend	Dit markeert het begin van het KYC-onboardingproces, wanneer het systeem de aanvraag van een klant ontvangt. Meestal wordt dit event expliciet vastgelegd wanneer het aanvraagformulier wordt ingediend via een klantenportaal of een intern gegevensinvoersysteem dat is gekoppeld aan LexisNexis.
Waarom dit belangrijk is Dit is het belangrijkste startevent van het proces. Door de tijd tussen deze activiteit en de afronding te analyseren, kun je de totale doorlooptijd en naleving van SLA’s meten. Waar vind je dit? Vastgelegd in systeemlogs of een aanvraagtabel met de timestamp waarop een nieuwe klantaanvraag is aangemaakt. Vastleggen Het event wordt vastgelegd wanneer een nieuwe aanvraagcase of vermelding in de centrale aanvraagtabel wordt aangemaakt. Gebeurtenistype explicit
	Compliancebeoordeling afgerond	De compliance officer rondt de beoordeling af en doet een aanbeveling, waarna de case naar de volgende fase gaat. Dit wordt expliciet vastgelegd wanneer een taak als ‘afgerond’ wordt gemarkeerd, of is af te leiden uit een statuswijziging van ‘Wacht op compliance’ naar een andere status.
Waarom dit belangrijk is Dit is een belangrijke mijlpaal die een essentieel en vaak handmatig deel van het proces afsluit. Hiermee kun je de duur van de compliancebeoordeling meten. Waar vind je dit? Vastgelegd met de timestamp waarop de compliancetaak is afgerond of af te leiden uit een statuswijziging vanuit ‘Compliancebeoordeling loopt’. Vastleggen Af te leiden uit een statuswijziging die aangeeft dat de beoordeling klaar is, bijvoorbeeld naar ‘Goedgekeurd’, ‘Afgewezen’ of ‘Definitief besluit’. Gebeurtenistype inferred
	Compliancebeoordeling gestart	Een case wordt toegewezen aan een compliance officer of team voor handmatige beoordeling, meestal bij aanvragen met een hoog risico. Dit is vaak af te leiden uit een statuswijziging naar ‘Wacht op compliancebeoordeling’ of uit een log van de taaktoewijzing.
Waarom dit belangrijk is Dit markeert het begin van een handmatige beoordelingsstap die vaak lang duurt. Door de tijd tot de afronding te meten, kun je bottlenecks rond compliance in kaart brengen. Waar vind je dit? Vastgelegd in een log van de taaktoewijzing, een wijziging van de case-eigenaar naar een complianceteam of een statuswijziging in de casegeschiedenis. Vastleggen Af te leiden uit een statuswijziging zoals ‘Compliancebeoordeling loopt’ of uit de toewijzing van de case aan een gebruikerswachtrij voor compliance. Gebeurtenistype inferred
	Documenten ontvangen	Bevestigt dat de klant de vereiste documenten naar het systeem heeft geüpload of aangeleverd. Meestal wordt dit event expliciet vastgelegd door het documentportaal of handmatig door een medewerker.
Waarom dit belangrijk is Met deze activiteit eindigt een wachttijd en beginnen de volgende beoordelingsstappen. Dit is een belangrijke mijlpaal in de gegevensverzameling. Waar vind je dit? Vastgelegd in logs van het documentbeheersysteem of als vermelding met timestamp in het aanvraagdossier wanneer nieuwe documenten worden toegevoegd. Vastleggen Het event wordt vastgelegd wanneer een document is geüpload of in het systeem handmatig als ontvangen is gemarkeerd. Gebeurtenistype explicit
	Klantonboarding afgerond	Dit event markeert het succesvolle einde van het volledige onboardingproces en bevestigt dat de klant volledig actief is. Het kan een expliciete eindstatus zijn of worden afgeleid uit het event ‘Account geactiveerd’.
Waarom dit belangrijk is Dit is het belangrijkste startevent voor een succesvolle afronding. Het is essentieel om de totale doorlooptijd te berekenen voor alle klanten die succesvol zijn onboarded. Waar vind je dit? Af te leiden uit de timestamp van ‘Account geactiveerd’ of vastgelegd als definitieve eindstatus, zoals ‘Onboarding afgerond’, in het dossier. Vastleggen Af te leiden uit het laatste belangrijke positieve event, zoals accountactivatie, of uit een definitieve statuswijziging. Gebeurtenistype inferred
	Risicobeoordeling uitgevoerd	Het systeem berekent een risicoscore voor de klant op basis van de verzamelde informatie en uitgevoerde controles. Dit is een kernfunctie van LexisNexis en wordt meestal als afzonderlijk, geautomatiseerd event vastgelegd in de casegeschiedenis.
Waarom dit belangrijk is De uitkomst van deze beoordeling bepaalt vaak de volgende procesroute, bijvoorbeeld of verscherpt cliëntenonderzoek nodig is. Dit is een belangrijk beslismoment in de workflow. Waar vind je dit? Zoek in het auditspoor of de workflowgeschiedenis van de aanvraag naar een event dat aangeeft dat de risicoscore of beoordelingsmodule klaar is. Vastleggen Er wordt een specifiek event vastgelegd wanneer de risico-engine de analyse afrondt en een risicoprofiel of -score toekent. Gebeurtenistype explicit
	Aanvullende informatie opgevraagd	Een compliance officer of beoordelaar vraagt de klant om meer informatie of toelichting. Dit is een belangrijke oorzaak van herstelwerk en wordt meestal expliciet vastgelegd als statuswijziging of vermelding in het communicatielog.
Waarom dit belangrijk is Deze activiteit leidt tot herstelwerk en verlengt de doorlooptijd van onboarding. Door de frequentie te volgen, kun je onduidelijke vereisten of veelvoorkomende tekortkomingen in aanvragen opsporen. Waar vind je dit? Zoek naar een statuswijziging naar ‘Wacht op klantinformatie’ of een event in het log van uitgaande communicatie. Vaak wordt dit gestart door een medewerker. Vastleggen Vastgelegd wanneer een medewerker de functie ‘Informatie opvragen’ gebruikt. Hierdoor verandert de casestatus en kan ook een communicatie-event worden vastgelegd. Gebeurtenistype explicit
	Account geactiveerd	Na goedkeuring wordt het account van de klant aangemaakt en geactiveerd op het kernbankplatform of dienstenplatform. Dit wordt vaak vastgelegd in een auditspoor of afgeleid uit de aanmaakdatum van het account.
Waarom dit belangrijk is Dit is de laatste stap waarin de klant waarde krijgt. Vertraging tussen ‘Aanvraag goedgekeurd’ en deze stap kan wijzen op problemen met systeemintegraties. Waar vind je dit? Vastgelegd in een accountaanmaaklog, een API-aanroep naar een ander systeem of de timestamp waarop de accountvermelding zelf is aangemaakt. Vastleggen Vastgelegd als afzonderlijk event na goedkeuring of af te leiden uit de activatietimestamp in het klantrecord. Gebeurtenistype explicit
	Documenten beoordeeld	Een medewerker of geautomatiseerde tool controleert de ingediende documenten op echtheid, geldigheid en volledigheid. Deze activiteit is af te leiden uit een statuswijziging van ‘Documenten ontvangen’ naar ‘Beoordeling afgerond’ of uit een expliciete logvermelding.
Waarom dit belangrijk is Hier ontstaan vaak bottlenecks en herstelwerk. Door de verwerkingstijd en herhalingen te analyseren, kun je de efficiëntie verbeteren en mogelijkheden voor automatisering vinden. Waar vind je dit? Af te leiden uit de tijd tussen de status ‘Documenten ontvangen’ en een volgende status, zoals ‘Verificatie geslaagd’ of ‘Aanvullende informatie nodig’. Vastleggen Berekend als de tijd tussen het event waarbij de documenten zijn ontvangen en het event dat aangeeft dat de beoordeling is afgerond. Gebeurtenistype inferred
	Documenten opgevraagd	Het systeem of een medewerker vraagt de klant om specifieke documenten, zoals een rijbewijs of energierekening. Dit event is terug te vinden in automatisch gegenereerde communicatielogs of in een statuswijziging die aangeeft dat de case op documenten wacht.
Waarom dit belangrijk is Deze activiteit leidt vaak tot een lange wachttijd. Door de frequentie en duur te analyseren, kun je vertragingen door de reactietijd van klanten opsporen. Waar vind je dit? Zoek naar een event in de communicatielogs van berichten aan de klant of naar een statuswijziging van de aanvraag, bijvoorbeeld ‘Documenten van klant in afwachting’. Vastleggen Afgeleid uit een statuswijziging naar ‘Wacht op documenten’ of uit de timestamp van een uitgaand bericht. Gebeurtenistype inferred
	Eerste screening uitgevoerd	Direct na indiening controleert het systeem automatisch of de basisgegevens volledig zijn en voert het een eerste controle uit. Deze activiteit wordt vaak als afzonderlijke, geautomatiseerde stap vastgelegd in de workflowgeschiedenis.
Waarom dit belangrijk is Hiermee zie je welke aanvragen al in een vroeg stadium worden afgewezen, wat helpt om problemen met de datakwaliteit te begrijpen. Het markeert ook de eerste geautomatiseerde stap die waarde toevoegt. Waar vind je dit? Zoek naar logs van automatisch uitgevoerde regels of een statuswijziging in de workflowgeschiedenis van de aanvraag die aangeeft dat de eerste screening is afgerond. Vastleggen Vastgelegd als een afgeronde automatische taak of als een specifieke statuswijziging in de casegeschiedenis. Gebeurtenistype explicit
	Identiteitsverificatie gestart	Dit is het moment waarop het systeem met de identiteitsverificatie begint via diensten van LexisNexis, bijvoorbeeld door gegevens in databases te controleren. Meestal wordt dit als afzonderlijk event vastgelegd wanneer de verificatiedienst wordt aangeroepen.
Waarom dit belangrijk is Deze activiteit markeert het begin van een belangrijke deelprocesstap die vaak veel tijd kost. Door de duur te volgen, kun je bottlenecks bij identiteitscontroles opsporen. Waar vind je dit? Vastgelegd in API-aanroeplogs van de module voor identiteitsverificatie of als vermelding in het auditspoor die aangeeft wanneer de verificatietaak is gestart. Vastleggen Er wordt een event vastgelegd wanneer de module voor identiteitsverificatie of de API van het systeem voor de aanvraag wordt gestart. Gebeurtenistype explicit

Aanbevolen Optioneel

Extractiegidsen

Zo haal je data op uit LexisNexis Risk Solutions

Stappen

Python-omgeving voorbereiden: Installeer Python 3.8 of nieuwer op je systeem. Open een terminal of opdrachtprompt en installeer de benodigde bibliotheken met pip install requests pandas.
API-inloggegevens opvragen: Neem contact op met je beheerder of accountmanager bij LexisNexis Risk Solutions voor API-inloggegevens. Je hebt een API Key, API Secret en de Base URL van de API-eindpunten nodig.
Python-script instellen: Open het meegeleverde Python-script in een teksteditor. Zoek bovenaan het configuratiegedeelte en vervang de tijdelijke waarden voor API_KEY, API_SECRET en BASE_URL door je eigen inloggegevens.
Extractieparameters instellen: Stel in hetzelfde configuratiegedeelte de periode voor de data-extractie in met de variabelen START_DATE en END_DATE. Gebruik de datumnotatie 'YYYY-MM-DD'. Begin bij voorkeur met een kortere periode, bijvoorbeeld één maand, om de extractie te testen.
Activiteiten controleren: Bekijk de dictionary ACTIVITY_MAP in het script. Deze koppelt eventtypen uit het LexisNexis-API-antwoord aan de gestandaardiseerde activiteitnamen voor het event log. Mogelijk moet je de sleutels aanpassen aan de eventnamen in je LexisNexis-configuratie. Je vindt die namen door een voorbeeld van een API-antwoord te bekijken.
Script uitvoeren: Voer het script vanuit de terminal uit met de opdracht python your_script_name.py. Het script meldt zich aan, haalt de lijst met klantaanvragen binnen de opgegeven periode op en verzamelt vervolgens de eventgeschiedenis van elke aanvraag.
Voortgang controleren: Het script toont voortgangsberichten in de console, zoals het aantal aanvragen dat wordt verwerkt. Let op foutmeldingen. Die kunnen wijzen op problemen met inloggegevens, API-eindpunten of limieten voor het aantal aanvragen.
Uitvoerbestand ophalen: Na een geslaagde uitvoering maakt het script in dezelfde map het bestand lexisnexis_event_log.csv aan. Dit bestand bevat het geëxtraheerde event log.
Bestand voorbereiden voor upload: Open het CSV-bestand voordat je het naar een process mining-tool uploadt. Controleer of de verwachte kolommen erin staan, zoals CustomerApplication, ActivityName, EventTimestamp en andere. Kijk ook of de data correct en consistent is.
Uploaden naar ProcessMind: Upload het gegenereerde bestand lexisnexis_event_log.csv naar je process mining-applicatie. Koppel de kolommen aan de velden voor case-ID, activiteit en timestamp.

Configuratie

API-inloggegevens: Voor authenticatie heb je een geldige API Key en API Secret nodig. Vraag deze op bij je LexisNexis-beheerder en houd ze vertrouwelijk.
API-eindpunten: Stel het script in met de juiste Base URL voor de LexisNexis REST API. De specifieke eindpunten voor het ophalen van aanvragen en hun eventgeschiedenis staan in de scriptcode.
Datumbereik: Met de parameters START_DATE en END_DATE stel je de periode voor de extractie in. Haal de data bij voorkeur op in delen van 3 tot 6 maanden. Zo blijft de verwerking beheersbaar en voorkom je dat je API-limieten bereikt.
Activiteiten koppelen: De dictionary ACTIVITY_MAP is een belangrijke configuratie. Controleer of de eventnamen uit de API, die als sleutels in de dictionary staan, overeenkomen met de namen die je systeem genereert. Events zonder koppeling worden genegeerd.
Aanvraaglimieten: Het script wacht kort tussen API-aanvragen om rekening te houden met mogelijke limieten. Bij zeer grote datasets moet je mogelijk de waarde van API_CALL_DELAY_SECONDS aanpassen of een uitgebreidere wachtrijlogica toevoegen.
Vereisten: Voor deze methode heb je een systeem nodig met Python 3.x en de bibliotheken requests en pandas. De gebruiker of het serviceaccount dat het script uitvoert, moet voldoende rechten hebben voor de LexisNexis-API.

a Voorbeeldquery python

import requests
import pandas as pd
import time
import json
from datetime import datetime

class=class="hl-string">"hl-comment"># --- Configuration Section --- #
class=class="hl-string">"hl-comment"># Replace with your actual LexisNexis API credentials and endpoints
API_KEY = class="hl-string">'[Your_API_Key]'
API_SECRET = class="hl-string">'[Your_API_Secret]'
BASE_URL = class="hl-string">'[https://api.example.lexisnexis.com/v1]' class=class="hl-string">"hl-comment"># e.g., your specific API gateway URL

class=class="hl-string">"hl-comment"># Set the date range for the extraction
START_DATE = class="hl-string">'2023-01-01'
END_DATE = class="hl-string">'2023-06-30'

class=class="hl-string">"hl-comment"># Delay between API calls to avoid rate limiting
API_CALL_DELAY_SECONDS = 0.5

class=class="hl-string">"hl-comment"># Mapping from LexisNexis event types to standard activity names
class=class="hl-string">"hl-comment"># CRITICAL: The keys of this dictionary must be adjusted to match the event names
class=class="hl-string">"hl-comment"># returned by your specific LexisNexis API endpoint.
ACTIVITY_MAP = {
    class="hl-string">'application.submitted': class="hl-string">'Application Submitted',
    class="hl-string">'screening.initial.performed': class="hl-string">'Initial Screening Performed',
    class="hl-string">'verification.identity.initiated': class="hl-string">'Identity Verification Initiated',
    class="hl-string">'documents.requested': class="hl-string">'Documents Requested',
    class="hl-string">'documents.received': class="hl-string">'Documents Received',
    class="hl-string">'review.document.performed': class="hl-string">'Document Review Performed',
    class="hl-string">'assessment.risk.performed': class="hl-string">'Risk Assessment Performed',
    class="hl-string">'review.compliance.initiated': class="hl-string">'Compliance Review Initiated',
    class="hl-string">'information.additional.requested': class="hl-string">'Additional Information Requested',
    class="hl-string">'review.compliance.completed': class="hl-string">'Compliance Review Completed',
    class="hl-string">'application.approved': class="hl-string">'Application Approved',
    class="hl-string">'account.activated': class="hl-string">'Account Activated',
    class="hl-string">'onboarding.completed': class="hl-string">'Customer Onboarding Completed',
    class="hl-string">'application.rejected': class="hl-string">'Application Rejected'
}

def get_auth_token():
    class="hl-string">"""Handles authentication and returns an access token."""
    class=class="hl-string">"hl-comment"># This is a placeholder for the actual authentication mechanism.
    class=class="hl-string">"hl-comment"># Adjust according to LexisNexis API documentation (e.g., OAuth2).
    class=class="hl-string">"hl-comment"># For simplicity, we assume the API Key can be used directly in a header.
    class=class="hl-string">"hl-comment"># In a real scenario, you might POST to a token endpoint.
    print(class="hl-string">"Authentication successful (simulated).")
    return fclass="hl-string">'Bearer {API_KEY}' class=class="hl-string">"hl-comment"># Simplified for example purposes

def main():
    class="hl-string">"""Main function to orchestrate the data extraction process."""
    auth_token = get_auth_token()
    if not auth_token:
        print(class="hl-string">"Failed to authenticate. Exiting.")
        return

    headers = {
        class="hl-string">'Authorization': auth_token,
        class="hl-string">'Content-Type': class="hl-string">'application/json'
    }

    print(fclass="hl-string">"Fetching applications from {START_DATE} to {END_DATE}...")
    
    class=class="hl-string">"hl-comment"># 1. Fetch all application IDs within the date range
    try:
        applications_endpoint = fclass="hl-string">'{BASE_URL}/applications'
        params = {class="hl-string">'startDate': START_DATE, class="hl-string">'endDate': END_DATE}
        response = requests.get(applications_endpoint, headers=headers, params=params)
        response.raise_for_status()
        applications = response.json().get(class="hl-string">'applications', [])
        print(fclass="hl-string">"Found {len(applications)} applications to process.")
    except requests.exceptions.RequestException as e:
        print(fclass="hl-string">"Error fetching applications: {e}")
        return

    all_events = []

    class=class="hl-string">"hl-comment"># 2. For each application, fetch its detailed event history
    for i, app in enumerate(applications):
        app_id = app.get(class="hl-string">'customerApplicationId')
        if not app_id:
            continue

        print(fclass="hl-string">"Processing application {i+1}/{len(applications)}: {app_id}")
        try:
            events_endpoint = fclass="hl-string">'{BASE_URL}/applications/{app_id}/events'
            event_response = requests.get(events_endpoint, headers=headers)
            event_response.raise_for_status()
            events_data = event_response.json().get(class="hl-string">'events', [])
            
            class=class="hl-string">"hl-comment"># 3. Parse events and map them to the event log format
            for event in events_data:
                event_type = event.get(class="hl-string">'eventType')
                if event_type in ACTIVITY_MAP:
                    activity_name = ACTIVITY_MAP[event_type]
                    
                    class=class="hl-string">"hl-comment"># Extract attributes, using .get() to handle missing data gracefully
                    record = {
                        class="hl-string">'CustomerApplication': app_id,
                        class="hl-string">'ActivityName': activity_name,
                        class="hl-string">'EventTimestamp': event.get(class="hl-string">'eventTimestamp'),
                        class="hl-string">'EndTime': event.get(class="hl-string">'eventCompletionTimestamp', None), class=class="hl-string">"hl-comment"># Optional
                        class="hl-string">'AssignedUser': event.get(class="hl-string">'userId', class="hl-string">'System'),
                        class="hl-string">'Department': event.get(class="hl-string">'userDepartment', None),
                        class="hl-string">'ApplicationStatus': event.get(class="hl-string">'applicationStatusAfterEvent'),
                        class="hl-string">'RiskLevel': event.get(class="hl-string">'riskAssessment', {}).get(class="hl-string">'level', None),
                        class="hl-string">'SlaTargetDate': app.get(class="hl-string">'slaTargetDate', None)
                    }
                    all_events.append(record)

        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">"Could not fetch events for application {app_id}: {e}")
        
        time.sleep(API_CALL_DELAY_SECONDS)

    if not all_events:
        print(class="hl-string">"No events were extracted. The output file will be empty.")
        return

    class=class="hl-string">"hl-comment"># 4. Create a DataFrame and save to CSV
    df = pd.DataFrame(all_events)
    df[class="hl-string">'EventTimestamp'] = pd.to_datetime(df[class="hl-string">'EventTimestamp'])
    df.sort_values(by=[class="hl-string">'CustomerApplication', class="hl-string">'EventTimestamp'], inplace=True)
    
    output_filename = class="hl-string">'lexisnexis_event_log.csv'
    df.to_csv(output_filename, index=False, date_format=class="hl-string">'%Y-%m-%d %H:%M:%S')
    print(fclass="hl-string">"Extraction complete. Event log saved to {output_filename}")

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

Klaar om te beginnen?

Gebruik deze template om aan de slag te gaan met process mining voor KYC-klantacceptatie. Zet vandaag de eerste stap van data naar concrete inzichten.

Terug naar de verbetergids Template downloaden

Verbeter KYC-klantacceptatie en voorkom uitval

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

Start je gratis proefperiode

Geen creditcard nodig. Begin vandaag met verbeteren.

Datatemplate voor KYC-klantacceptatie

Datatemplate voor KYC-klantacceptatie

Attributen voor KYC-klantacceptatie

Activiteiten voor KYC-klantacceptatie

Extractiegidsen

Data-extractie uit de LexisNexis-API met een Python-script

Stappen

Configuratie

a Voorbeeldquery python

Klaar om te beginnen?

Verbeter KYC-klantacceptatie en voorkom uitval

We gaan zorgvuldig om met je privacy