Šablona dat pro onboarding zákazníků KYC

Refinitiv World-Check
Šablona dat pro onboarding zákazníků KYC

Šablona dat pro onboarding zákazníků KYC

Tato šablona vám pomůže shromáždit potřebná data pro analýzu procesu onboardingu zákazníků KYC. Uvádí atributy, které je vhodné zaznamenávat, a hlavní aktivity, které je třeba sledovat. Najdete v ní také pokyny, jak tyto informace získat ze zdrojových systémů. Využijte ji jako pomůcku při přípravě dat pro analýzu a zlepšování procesů.
  • Doporučené atributy ke sběru
  • Aktivity, které je vhodné sledovat
  • Pokyny k extrakci dat
Pracujete se záznamy událostí poprvé? Přečtěte si, jak vytvořit záznam událostí pro process mining.

Atributy onboardingu zákazníků KYC

Toto jsou doporučená datová pole pro záznam událostí, která využijete při analýze onboardingu zákazníků KYC.
3 Povinné 5 Doporučené 11 Volitelné
Název Popis
Čas události
EventTime
Časové razítko určující, kdy došlo ke konkrétní aktivitě nebo události.
Popis

Čas události udává přesné datum a čas zaznamenání aktivity. Tvoří časovou osu procesu a umožňuje správně seřadit události při rekonstrukci historie případu.

Tento atribut je nezbytný pro veškerou časovou analýzu v process mining. Používá se k výpočtu doby mezi aktivitami, včetně doby zpracování a čekání, k měření celkové doby trvání případu, analýze výkonnosti procesu v čase a kontrole dodržování dohod o úrovni služeb (SLA). Bez přesných časových razítek nelze porozumět výkonnosti procesu ani určit časová úzká místa.

Proč je to důležité

Časové razítko každé aktivity je nezbytné pro výpočet ukazatelů doby trvání, zjištění pořadí aktivit v procesu a analýzu úzkých míst.

Kde data získat

Jde o běžné pole v záznamu událostí nebo tabulce auditní stopy. Často se nazývá „Timestamp“, „EventDate“ nebo „CreationDate“.

Příklady
2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T14:22:15Z
Název aktivity
ActivityName
Název konkrétní obchodní události nebo úkolu, který nastal v procesu přijetí zákazníka KYC.
Popis

Název aktivity popisuje jednotlivý krok nebo událost v procesu přijetí zákazníka, například „Žádost odeslána“, „Zahájena kontrola analytikem“ nebo „Prověřování dokončeno, bez nálezu“. Tyto aktivity tvoří uzly procesní mapy a podrobně zachycují celý workflow.

Analýza aktivit je základem process mining. Sledováním pořadí a četnosti jednotlivých aktivit mohou analytici zjistit skutečný průběh procesu, určit obvyklé cesty, odhalit odchylky od standardního postupu a najít konkrétní kroky, které způsobují zpoždění nebo opakovanou práci. Tento atribut je nezbytný pro tvorbu procesních map a výpočet ukazatelů na úrovni aktivit.

Proč je to důležité

Tento atribut vymezuje jednotlivé kroky procesu. Je nezbytný pro zjištění a zobrazení procesního toku i pro hledání úzkých míst.

Kde data získat

Tyto informace se obvykle nacházejí v záznamech událostí nebo tabulkách auditní stopy, často u změn stavu v záznamu případu.

Příklady
Zjištěna možná shodaZahájena kontrola analytikemPotvrzen falešný nálezŽádost schválena
Žádost zákazníka
CustomerApplication
Jedinečný identifikátor žádosti o přijetí jednoho zákazníka, který slouží jako hlavní identifikátor případu.
Popis

Žádost zákazníka je hlavní identifikátor případu, který sdružuje všechny události a aktivity související s přijetím jednoho zákazníka. Umožňuje sledovat celý průběh každého případu v časovém pořadí, od prvního podání až po konečné rozhodnutí v rámci procesu Know Your Customer (KYC).

Při analýze process mining je tento atribut základem pro rekonstrukci celého průběhu každé žádosti. Umožňuje zobrazit procesní toky, vypočítat celkovou dobu zpracování a určit varianty procesu. Analýza případů seskupených podle tohoto identifikátoru ukazuje, jakými cestami se žádosti mohou ubírat, kde vznikají úzká místa a jak efektivní jsou jednotlivé postupy přijetí zákazníka.

Proč je to důležité

Jde o nezbytný identifikátor případu, který propojuje všechny související aktivity a umožňuje analyzovat proces přijetí zákazníka od začátku do konce.

Kde data získat

Tento identifikátor je obvykle primárním klíčem v hlavní tabulce žádostí nebo správy případů v systému Refinitiv World-Check či integrovaném CRM.

Příklady
APP-2023-00123APP-2023-00124APP-2023-00125
Čas ukončení události
EventEndTime
Časové razítko určující, kdy byla dokončena konkrétní aktivita nebo událost.
Popis

Čas ukončení události označuje dokončení aktivity. Mnohé události lze modelovat jako okamžité, kdy se čas zahájení rovná času ukončení. Některé aktivity však mají měřitelnou dobu trvání, například „Zahájena kontrola analytikem“ a „Kontrola analytikem dokončena“. Záznam času zahájení i ukončení umožňuje přesně měřit dobu zpracování.

Při analýze procesu je čas ukončení nezbytný pro výpočet přesné doby zpracování aktivity, na rozdíl od doby průchodu, která zahrnuje i čekání. Díky tomu lze rozlišit, jak dlouho se na případu aktivně pracuje a jak dlouho čeká ve frontě. To je důležité pro efektivní využití zdrojů a analýzu výkonnosti.

Proč je to důležité

Umožňuje přesně vypočítat dobu zpracování aktivity a oddělit aktivní práci od čekání, což zpřesňuje analýzu výkonnosti.

Kde data získat

U aktivit s měřitelnou dobou trvání může být tento údaj uložen v samostatném poli, například „CompletionDate“ nebo „EndDate“, v záznamu událostí či tabulkách auditní stopy.

Příklady
2023-10-26T10:45:00Z2023-10-26T12:00:00Z2023-10-27T15:00:00Z
Cílové datum SLA
SlaTargetDate
Datum, do kterého má být proces přijetí zákazníka dokončen.
Popis

Cílové datum SLA je termín pro dokončení celého případu přijetí zákazníka, stanovený dohodou o úrovni služeb se zákazníkem nebo interními pravidly. Podle tohoto termínu se porovnává skutečná doba dokončení.

Tento atribut je základem dashboardu „Dodržování SLA a analýza překročení termínů“. Slouží k výpočtu, zda byl případ dokončen včas. Analýza nedodržených SLA pomáhá odhalit systémové příčiny zpoždění a přijmout nápravná opatření, která zlepší včasnost a zajistí shodu s požadavky.

Proč je to důležité

Jde o referenční termín pro měření včasného dokončení. Je nezbytný pro výpočet míry dodržování SLA a analýzu překročení termínů.

Kde data získat

Toto datum se často vypočítává podle data podání žádosti a obchodních pravidel. Může být uloženo jako pole v záznamu případu.

Příklady
2023-11-10T17:00:00Z2023-11-15T17:00:00Z2023-11-20T17:00:00Z
ID kontrolujícího
ReviewerId
Identifikátor uživatele, analytika nebo automatizovaného agenta, který aktivitu provedl.
Popis

ID kontrolujícího, tedy uživatele, určuje, kdo provedl konkrétní úkol v procesu KYC. Může jít o analytika odpovědného za shodu, specialistu na přijetí zákazníků nebo systémový účet pro automatické aktivity. Sledování těchto údajů ukazuje rozložení pracovní zátěže a výkon jednotlivců.

Tento atribut je nezbytný pro analýzu podle zdrojů. Pomáhá porovnávat výkonnost uživatelů a týmů, určovat potřebu školení a lépe rozdělovat pracovní zátěž. Je také důležitý při analýze předávání práce, sociálních sítí a využití zdrojů odpovědných za shodu.

Proč je to důležité

Umožňuje analyzovat rozložení pracovní zátěže, výkon uživatelů a předávání práce mezi odděleními, což je důležité pro efektivní využití zdrojů.

Kde data získat

Obvykle se nachází v záznamech událostí nebo auditních stopách a bývá označeno jako „UserID“, „PerformedBy“ nebo „Owner“.

Příklady
analyst_jdoesystem_auto_screenermanager_bsmith
Oddělení
DepartmentName
Oddělení nebo funkční tým odpovědný za provedení aktivity.
Popis

Tento atribut určuje obchodní jednotku nebo tým, například „Přijetí zákazníků“, „Shoda“ nebo „Kontrola kvality“, ke kterému uživatel patří. Umožňuje analyzovat proces na vyšší organizační úrovni než podle jednotlivých uživatelů.

Analýza podle oddělení je důležitá pro hledání úzkých míst mezi odděleními a měření doby předávání práce. Ukazuje, jak práce přechází mezi týmy a kde při předávání vznikají zpoždění. Tento pohled pomáhá zjednodušit spolupráci napříč týmy a zvýšit celkovou efektivitu procesu.

Proč je to důležité

Umožňuje analyzovat výkonnost procesu podle oddělení a pomáhá hledat zpoždění při předávání práce mezi týmy.

Kde data získat

Tyto informace mohou být uloženy v uživatelském profilu v systému nebo v souvisejícím HR systému. Možná bude nutné propojit je s daty událostí pomocí ID uživatele.

Příklady
Tým pro přijetí zákazníkůKontrola shodyVedení společnosti
Úroveň rizika
RiskLevel
Vypočtená klasifikace rizika žádosti zákazníka, například nízká, střední nebo vysoká.
Popis

Úroveň rizika je důležitým údajem v procesech KYC, protože určuje rozsah požadovaného hloubkového prověření. Často se stanovuje podle faktorů, jako je typ zákazníka, zeměpisná oblast a povaha jeho podnikání. Tato klasifikace může výrazně ovlivnit průběh žádosti.

Při analýze procesu je důležité rozdělit případy podle úrovně rizika. Pomáhá to vysvětlit rozdíly v době zpracování a procesních tocích. Žádosti s vysokým rizikem mohou například vyžadovat více kroků a trvat déle. Tento atribut je důležitý pro dashboardy „Míra a důvody zamítnutí žádostí“ a „Doba zahájení prověření“, které ukazují, jak riziko ovlivňuje výsledky a efektivitu.

Proč je to důležité

Rozdělení procesu podle úrovně rizika pomáhá pochopit, proč některé případy trvají déle nebo procházejí jiným postupem, a analyzovat míru zamítnutí.

Kde data získat

Jde o základní údaj v záznamu žádosti zákazníka nebo případu. Najdete jej v modulu správy případů Refinitiv World-Check.

Příklady
NízkáStředníVysoká
Došlo k porušení SLA
SlaBreached
Booleovský příznak označující, zda byl případ onboardingu dokončen po cílovém datu SLA.
Popis

Tento vypočítaný příznak označuje, zda případ překročil sjednanou úroveň služeb. Určuje se porovnáním časového razítka poslední aktivity dokončení, například „Žádost schválena“ nebo „Žádost zamítnuta“, s hodnotou „SlaTargetDate“ u daného případu.

Příznak slouží jako základ dashboardu „Dodržování a porušení SLA“ a KPI „Míra dodržení SLA“. Analýzu zjednodušuje tím, že uživatelé mohou rychle vyfiltrovat všechny případy s překročenou lhůtou. Analýza průběhu těchto případů pomáhá organizacím určit příčiny zpoždění a zaměřit zlepšování procesů tam, kde přinese největší užitek.

Proč je to důležité

Přímo měří dodržování sjednaných úrovní služeb a usnadňuje filtrování opožděných případů i analýzu jejich příčin.

Kde data získat

Vypočítá se při transformaci dat porovnáním časového razítka poslední aktivity případu s polem SlaTargetDate.

Příklady
truefalse
Důvod zamítnutí
RejectionReason
Konkrétní důvod uvedený při zamítnutí žádosti zákazníka.
Popis

Pokud je žádost zamítnuta, důvod zamítnutí vysvětluje, proč k tomu došlo. Může jít například o „Shodu se sankčním seznamem“, „Neúplnou dokumentaci“ nebo „Vysoký rizikový profil“. Jde o strukturovanou zpětnou vazbu ke kvalitě příchozích žádostí a účinnosti prověřování.

Tento atribut je hlavním podkladem pro dashboard „Míra a důvody zamítnutí žádostí“. Analýza důvodů pomáhá odhalit příčiny zamítnutí, zlepšit proces, srozumitelněji komunikovat se žadateli a případně omezit zbytečná zamítnutí. K číselnému ukazateli KPI míry zamítnutí přidává kvalitativní kontext.

Proč je to důležité

Ukazuje příčiny zamítnutí žádostí a pomáhá určit, co je třeba v procesu přijetí zákazníka zlepšit, aby se snížila míra zamítnutí.

Kde data získat

Tento údaj se zaznamenává při události „Žádost zamítnuta“, pravděpodobně jako pole v záznamu případu nebo žádosti.

Příklady
Shoda s PEPNález na sankčním seznamuNeúspěšné ověření dokumentůNegativní informace v médiích
ID shody
MatchId
Jedinečný identifikátor možné shody nalezené při prověřování ve World-Check.
Popis

Když automatizovaný screening najde možnou shodu se sankčními seznamy, seznamy PEP nebo negativními zprávami v médiích, často se vygeneruje ID shody, které umožňuje konkrétní nález sledovat. Toto ID propojuje případ žádosti s konkrétním záznamem v databázi World-Check, který upozornění vyvolal.

Tento atribut se hodí pro podrobnou analýzu shody. Analytici díky němu mohou prověřit povahu shod, sledovat vyřešení konkrétních upozornění, například potvrzení falešně pozitivního nálezu nebo skutečné shody, a zjistit, které typy upozornění se objevují nejčastěji nebo jejichž vyřešení trvá nejdéle. Poskytuje podrobnější pohled na aktivitu „Zjištěna možná shoda“.

Proč je to důležité

Propojuje záznam s konkrétními výsledky screeningu a umožňuje podrobněji analyzovat dobu řešení shod i typy upozornění.

Kde data získat

Toto ID by měl generovat screeningový modul World-Check a při nalezení možné shody ho zaznamenat u případu žádosti.

Příklady
WC-MATCH-459021WC-MATCH-459022WC-MATCH-459023
ID zákazníka
CustomerId
Jedinečný identifikátor zákazníka, který prochází procesem přijetí.
Popis

ID zákazníka je jedinečný identifikátor zákaznického profilu. Liší se od ID žádosti zákazníka, protože jeden zákazník může v průběhu času podat více žádostí. Tento atribut propojuje proces přijetí s hlavním záznamem zákazníka.

Při analýze umožňuje ID zákazníka sledovat opakované žádosti téhož zákazníka a doplnit procesní data o další údaje z CRM nebo systému kmenových dat. Díky tomu lze získat celkový pohled na cestu zákazníka, nejen na jeden případ jeho přijetí.

Proč je to důležité

Propojuje případ přijetí s konkrétním zákazníkem, umožňuje analyzovat opakované žádosti a doplnit data o hlavní záznam zákazníka.

Kde data získat

Jde o důležité pole v záznamu žádosti nebo případu, které jej propojuje s hlavními údaji o zákazníkovi.

Příklady
CUST-98765CUST-98766CUST-98767
Jde o opakovanou práci
IsRework
Příznak označující, zda se aktivita v rámci stejného případu provádí podruhé nebo opakovaně.
Popis

IsRework je vypočítaný booleovský atribut, který označuje opakování aktivity v rámci stejného případu zákaznické žádosti. Pokud se například u jedné žádosti aktivita „Provedeno posouzení rizika“ objeví vícekrát, další výskyty se označí jako opakovaná práce.

Tento atribut pomáhá odhalit neefektivní postupy, smyčky a zbytečné opakování. Přímo podporuje dashboard „Opakované posouzení rizika a efektivita“ a KPI „Míra opakovaného posouzení rizika“. Analýza opakované práce může odhalit problémy s kvalitou, srozumitelností informací nebo rozhodováním, které vedou ke zbytečnému úsilí a prodlužují dobu průchodu procesem.

Proč je to důležité

Označením opakovaných aktivit upozorňuje na neefektivní postupy. Analýza opakování pomáhá zlepšit kvalitu a zkrátit dobu průchodu procesem.

Kde data získat

Vypočítá se při transformaci dat analýzou pořadí aktivit v každém případu. Označí se každý další výskyt aktivity po jejím prvním výskytu.

Příklady
truefalse
Je automatizovaná
IsAutomated
Příznak označuje, zda aktivitu provedl systém (true), nebo člověk (false).
Popis

Tento booleovský atribut rozlišuje automatizované systémové úlohy od ručních aktivit uživatelů. Například „Proveden automatizovaný screening“ by byl označen jako automatizovaný, zatímco „Zahájena kontrola analytikem“ jako ruční.

Toto rozlišení je důležité pro analýzu automatizace. Pomáhá měřit její vliv na efektivitu procesu, určit ruční úlohy vhodné k budoucí automatizaci a porozumět spolupráci lidí se systémy. Umožňuje jasně oddělit dobu zpracování systémem od času, který případu věnují lidé.

Proč je to důležité

Rozlišuje systémové a lidské aktivity. Díky tomu lze měřit vliv automatizace a hledat další příležitosti k automatizaci.

Kde data získat

Obvykle se určuje podle názvu aktivity nebo ID uživatele přiřazeného k události, například pokud jde o účet „system“.

Příklady
truefalse
Kanál podání žádosti
ApplicationChannel
Kanál, kterým byla žádost zákazníka podána, například online portál, pobočka nebo mobilní aplikace.
Popis

Kanál podání žádosti určuje, odkud žádost zákazníka přišla. Jednotlivé kanály se mohou lišit úplností a kvalitou dat i charakteristikami zákazníků, což může ovlivnit navazující proces.

Tento atribut je důležitý pro dashboard „Počet zpracovaných žádostí podle kanálu“. Analýza objemu, doby zpracování a výsledků žádostí z různých kanálů ukazuje, které kanály jsou nejefektivnější a kde je třeba proces zlepšit. Výsledky pomáhají při strategickém rozhodování o rozdělení zdrojů a investicích do jednotlivých kanálů.

Proč je to důležité

Pomáhá porovnávat výkonnost a efektivitu jednotlivých kanálů podání a podporuje strategická rozhodnutí o technologiích a zákaznické zkušenosti.

Kde data získat

Tyto informace se obvykle zaznamenávají na začátku procesu jako atribut žádosti.

Příklady
Online portálMobilní aplikacePobočkaManažer vztahů se zákazníky
Poslední aktualizace dat
LastDataUpdate
Časové razítko poslední aktualizace dat této události nebo jejich získání ze zdrojového systému.
Popis

Tento atribut udává aktuálnost dat. Zaznamenává datum a čas posledního načtení dat z Refinitiv World-Check. Díky tomu lze posoudit, jak aktuální jsou dashboardy a analýzy process mining.

Uživatelé tak mohou zjistit, zda pracují s téměř aktuálními daty, nebo se snímkem dat z určitého okamžiku. Atribut je důležitý pro správu dat i pro nastavení očekávání uživatelů ohledně aktuálnosti poskytovaných poznatků.

Proč je to důležité

Poskytuje důležitý kontext o aktuálnosti dat, aby uživatelé věděli, jak aktuální je analýza procesu.

Kde data získat

Toto časové razítko se vytvoří a přidá při extrakci dat (ETL).

Příklady
2023-11-01T02:00:00Z2023-11-02T02:00:00Z
Typ zákazníka
CustomerType
Klasifikace zákazníka, například fyzická osoba, společnost nebo svěřenský fond.
Popis

Typ zákazníka určuje kategorii subjektu, který prochází procesem přijetí. Různé typy zákazníků mívají odlišné požadavky na přijetí, rizikové profily a regulatorní povinnosti. Přijetí společnosti je například obvykle složitější než přijetí fyzické osoby.

Tento atribut se používá k segmentaci, zejména v dashboardu „Výkonnost KYC podle typu zákazníka“. Umožňuje porovnávat efektivitu procesu, dobu zpracování a míru zamítnutí u různých skupin zákazníků. Organizace tak mohou přizpůsobit a zlepšit proces přijetí pro jednotlivé typy zákazníků.

Proč je to důležité

Umožňuje porovnávat výkonnost různých skupin zákazníků a přizpůsobit proces přijetí potřebám každého typu.

Kde data získat

Jde o základní atribut uložený v záznamu zákazníka nebo žádosti ve zdrojovém systému.

Příklady
Fyzická osobaSpolečnostNezisková organizaceSvěřenský fond
Zdrojový systém
SourceSystem
Systém, ze kterého byla data událostí získána, v tomto případě Refinitiv World-Check.
Popis

Tento atribut určuje původ procesních dat. Při získávání dat z jediného zdroje může mít stále stejnou hodnotu. Je však důležitý při spojování dat z více systémů, například CRM a World-Check, pro vytvoření celkového pohledu na proces.

Při analýze pomáhá se správou dat, řešením problémů a pochopením jejich kontextu. Aktivity zaznamenané v hlavním systému prověřování mohou mít například jiné vlastnosti nebo úroveň podrobnosti než aktivity z pomocného systému. Atribut zajišťuje jasnou a kontrolovatelnou návaznost dat na jejich zdroj.

Proč je to důležité

Určuje původ dat, což je důležité pro správu a ověřování dat i při slučování údajů z více zdrojů.

Kde data získat

Často jde o statickou hodnotu přidanou při extrakci, transformaci a načítání dat (ETL), která označuje datovou sadu.

Příklady
Refinitiv World-CheckWorldCheckOne
Země zákazníka
CustomerCountry
Země pobytu zákazníka nebo země, ve které je registrován.
Popis

Tento atribut udává zeměpisnou polohu zákazníka. Země je důležitým faktorem při hodnocení rizik a určování regulatorních požadavků v procesech KYC. Jednotlivé jurisdikce mají různá pravidla, která mohou ovlivnit průběh i délku procesu.

Analýza procesu podle země umožňuje porovnávat výkonnost v různých regionech, hledat místní úzká místa a ověřovat shodu s místními předpisy. Zeměpisný pohled na proces může odhalit důležité rozdíly v provozu.

Proč je to důležité

Umožňuje analyzovat proces podle zeměpisné oblasti a hledat regionální rozdíly ve výkonnosti, rizicích a požadavcích na shodu.

Kde data získat

Jde o běžné pole v zákaznickém profilu nebo formuláři žádosti.

Příklady
USAGBRSGPDEU
Povinné Doporučené Volitelné

Aktivity onboardingu zákazníků KYC

Toto jsou hlavní kroky a milníky procesu, které je vhodné zaznamenat pro přesné zjištění průběhu procesu.
8 Doporučené 6 Volitelné
Aktivita Popis
Potvrzena skutečná shoda
Analytik potvrdí, že možná shoda skutečně odpovídá prověřovanému zákazníkovi, a identifikuje možné riziko. Jde o důležitý milník, který obvykle vede k dalšímu hloubkovému prověření nebo zamítnutí žádosti.
Proč je to důležité

Jde o důležitý výsledek z hlediska omezení rizik a zásadní okamžik v procesu. Přímo ovlivňuje konečné rozhodnutí o žádosti zákazníka a je důležitý pro vykazování a analýzu shody.

Kde data získat

Jde o výslovnou akci uživatele, při níž analytik označí konkrétní shodu jako „Skutečná shoda“ nebo „Potvrzená shoda“. Událost se zaznamená do auditní stopy případu.

Zachycení

Záznam se vytvoří, když analytik v systému formálně potvrdí shodu.

Typ události explicit
Prověřování dokončeno, bez nálezu
Případ prověřování se oficiálně uzavře s výsledkem „Bez nálezu“, což znamená, že nebyla nalezena žádná skutečná shoda. Výsledek se předá zpět do zdrojového systému, aby mohl pokračovat proces přijetí zákazníka.
Proč je to důležité

Tato aktivita představuje úspěšné dokončení prověřování podle standardního postupu. Slouží jako koncový bod pro měření doby zpracování běžných žádostí s nízkým rizikem.

Kde data získat

Událost lze odvodit z konečné změny stavu případu na „Bez nálezu“, „Dokončeno“ nebo „Uzavřeno, bez shody“. Použije se časové razítko této poslední změny stavu.

Zachycení

Odvozeno z časového razítka konečného stavu případu, který značí výsledek bez nálezu.

Typ události inferred
Prověřování dokončeno, nalezena shoda
Případ prověřování se oficiálně uzavře s výsledkem „Nalezena shoda“, který značí potvrzené riziko. Výsledek spouští jiný navazující proces, například hloubkové prověření nebo zamítnutí žádosti.
Proč je to důležité

Jde o hlavní koncový bod nepříznivé větve prověřování. Analýza těchto případů pomáhá porozumět rizikovým profilům a účinnosti kontrol při prověřování.

Kde data získat

Událost lze odvodit z konečné změny stavu případu na „Nalezena shoda“, „Zjištěno riziko“ nebo „Uzavřeno, pozitivní nález“. Použije se časové razítko této poslední změny stavu.

Zachycení

Odvozeno z časového razítka konečného stavu případu, který značí potvrzenou shodu.

Typ události inferred
Účet aktivován
Účet zákazníka je vytvořen a aktivován v hlavním systému, čímž se dokončí proces jeho přijetí. K tomu dochází po konečném schválení žádosti a účet je následně připraven k použití.
Proč je to důležité

Jde o poslední krok procesu, který přináší hodnotu. Doba od podání žádosti do aktivace účtu je důležitým ukazatelem provozní efektivity a spokojenosti zákazníků.

Kde data získat

Tato událost se v World-Check nezaznamenává. Zaznamenává se v hlavním bankovním systému nebo systému zákaznických účtů a musí se propojit pomocí ID žádosti zákazníka.

Zachycení

Událost zaznamenaná v hlavním systému účtů při aktivaci účtu.

Typ události explicit
Žádost o prověření vytvořena
V systému Refinitiv World-Check se pro zákaznickou žádost formálně vytvoří nový případ prověření. Spustí jej volání API nebo ruční zadání z navazujícího systému. Tím začíná prověření rizikových informací.
Proč je to důležité

Tímto začíná oficiální část prověřování. Doba mezi odesláním žádosti a touto aktivitou ukazuje zpoždění při předávání mezi systémem obchodní jednotky a útvarem odpovědným za shodu.

Kde data získat

Záznam se nachází v protokolech správy případů World-Check nebo v auditní stopě. Použije se událost vytvoření konkrétního případu či subjektu a její časové razítko.

Zachycení

Záznam se vytvoří automaticky při založení nového případu prověřování v systému.

Typ události explicit
Žádost podána
Tato aktivita označuje začátek procesu nástupu v rámci KYC, kdy zákazník podá žádost. Událost se obvykle zaznamená v CRM nebo v hlavním aplikačním systému, který následně spustí prověření v Refinitiv World-Check.
Proč je to důležité

Jde o hlavní počáteční událost celého procesu nástupu zákazníka. Doba od tohoto okamžiku do dokončení ukazuje celkovou délku nástupu, která je důležitá pro měření zákaznické zkušenosti i dodržování SLA.

Kde data získat

Tato událost není nativní součástí World-Check. Je třeba ji získat z navazujícího systému, například CRM nebo platformy pro správu zákaznických účtů, a propojit podle ID zákaznické žádosti.

Zachycení

Událost zaznamenaná ve zdrojovém aplikačním systému při prvním podání žádosti.

Typ události explicit
Žádost zamítnuta
Žádost zákazníka je formálně zamítnuta, často kvůli výsledku „Nalezena shoda“ v World-Check nebo jiným rizikovým faktorům. Jde o konečný nepříznivý výsledek procesu přijetí zákazníka.
Proč je to důležité

Jde o hlavní koncový bod neúspěšné větve procesu. Analýza zamítnutých žádostí, zejména jejich důvodů a předchozích aktivit, je důležitá pro zlepšování procesů a omezení zbytečných zamítnutí.

Kde data získat

Toto konečné obchodní rozhodnutí se zaznamenává v navazujícím CRM nebo hlavním aplikačním systému, nikoli přímo ve World-Check. Data je proto třeba získat z tohoto systému.

Zachycení

Událost zaznamenaná ve zdrojovém aplikačním systému, často spolu s odpovídajícím kódem důvodu zamítnutí.

Typ události explicit
Zahájena kontrola analytikem
Analytik odpovědný za shodu zahájí ruční šetření možných shod u zákaznické žádosti. Porovnává údaje o možných shodách s informacemi o zákazníkovi a posuzuje, zda spolu souvisejí.
Proč je to důležité

Tímto začíná ruční kontrola shody, která často představuje úzké místo. Doba od zjištění možné shody do této aktivity ukazuje čekání ve frontě. Délka samotné kontroly vypovídá o efektivitě analytiků.

Kde data získat

Událost lze odvodit z okamžiku, kdy analytik případ převezme z fronty nebo otevře. Systém ji může zaznamenat přímo do auditní stopy při změně stavu případu na „Probíhá kontrola“ nebo při přiřazení konkrétnímu uživateli.

Zachycení

Odvozeno ze změny stavu případu na „V kontrole“ nebo z přiřazení případu analytikovi.

Typ události inferred
Automatické prověření
Systém World-Check automaticky porovná údaje o zákazníkovi se svou databází informací o rizicích. Tato systémová aktivita vytvoří první sadu výsledků, například možné shody nebo stav bez nálezu.
Proč je to důležité

Jde o první krok prověřování, který přináší hodnotu. Zpoždění před touto aktivitou ukazuje na problémy s připraveností systému nebo dat. Výsledek pak určuje rozsah následné ruční práce.

Kde data získat

Tato událost může být zaznamenána přímo v auditní stopě případu. Lze ji také odvodit z časového razítka, kdy jsou pro případ k dispozici první výsledky prověření.

Zachycení

Záznam v systémovém protokolu vytvořený po dokončení automatického prohledání databáze.

Typ události explicit
Potvrzen falešný nález
Analytik dospěje k závěru, že nalezená možná shoda není prověřovaným zákazníkem. Shodu zamítne a prověřování daného upozornění tím uzavře.
Proč je to důležité

Jde o běžný výsledek kontroly. Doba potřebná k uzavření falešných nálezů pomáhá měřit efektivitu analytiků a přesnost automatického prověřování.

Kde data získat

Jde o výslovnou akci uživatele, při níž analytik označí konkrétní shodu jako „Falešný nález“ nebo „Nejde o shodu“. Akce se obvykle zaznamená do historie případu.

Zachycení

Záznam se vytvoří, když analytik v systému formálně zamítne možnou shodu.

Typ události explicit
Případ předán k další kontrole
Analytik první úrovně předá složitý nebo vysoce rizikový případ seniornímu analytikovi či manažerovi, který rozhodne. Jde o důležité předání v rámci týmu odpovědného za shodu.
Proč je to důležité

Předání často vytvářejí úzká místa a prodlužují dobu zpracování. Analýza četnosti a důvodů předání může odhalit potřebu školení juniorních analytiků nebo nejasnosti v pravidlech kontroly.

Kde data získat

Zaznamenává se jako výslovná akce ve workflow případu nebo v auditní stopě. Lze ji také odvodit ze změny uživatele přiřazeného k případu, zejména pokud jde o uživatele s vyššími oprávněními.

Zachycení

Zaznamenává se pomocí tlačítka „Předat k eskalaci“ nebo příslušné akce ve workflow případu.

Typ události explicit
Vyžádány další informace
Analytik zjistí, že k vyřešení možné shody potřebuje další informace, a vyžádá si je od obchodní jednotky. Případ zůstane čekat, dokud informace nedorazí.
Proč je to důležité

Častý výskyt této aktivity ukazuje na problémy s kvalitou vstupních dat pro prověřování. Aktivita výrazně prodlužuje proces, protože závisí na externích týmech, a patří mezi hlavní příčiny dlouhé doby zpracování.

Kde data získat

Může jít o výslovnou akci uživatele zaznamenanou v poznámkách k případu nebo v auditním protokolu. Událost lze také odvodit ze změny stavu případu na „Čeká na informace“ nebo „RFI“.

Zachycení

Záznam se vytvoří, když analytik pomocí funkce označí případ jako vyžadující další informace.

Typ události explicit
Žádost schválena
Žádost zákazníka byla plně schválena po úspěšném prověření KYC a dokončení dalších požadovaných kontrol. Tato událost obvykle nastává ve zdrojovém systému po obdržení výsledku „Bez nálezu“ z World-Check.
Proč je to důležité

Tímto je dosaženo úspěšného obchodního výsledku procesu přijetí zákazníka. Doba od podání žádosti do tohoto okamžiku ukazuje celkovou dobu potřebnou ke schválení nového zákazníka.

Kde data získat

Tato událost není součástí World-Check. Je třeba ji získat z navazujícího CRM nebo hlavního aplikačního systému, ve kterém se přijímá konečné obchodní rozhodnutí.

Zachycení

Událost zaznamenaná ve zdrojovém aplikačním systému po konečném schválení.

Typ události explicit
Zjištěna možná shoda
Automatické prověření našlo jednu nebo více možných shod, které musí analytik ručně posoudit. Případ tím přechází z automatického zpracování do fronty pro ruční šetření.
Proč je to důležité

Jde o důležitý bod, který určuje další větev procesu. Případy s možnou shodou procházejí delším a složitějším postupem. Jejich sledování pomáhá plánovat zdroje a hledat úzká místa v týmu, který provádí kontrolu.

Kde data získat

Událost lze odvodit ze změny stavu případu na „Vyžaduje kontrolu“, „Možná shoda“ nebo podobný stav v modulu správy případů World-Check.

Zachycení

Odvozeno ze změny stavu případu, která značí, že je nyní nutná ruční kontrola.

Typ události inferred
Doporučené Volitelné

Průvodci extrakcí dat

Jak získat data z Refinitiv World-Check

Chcete začít?

Využijte tuto datovou šablonu jako výchozí bod pro process mining onboardingu zákazníků KYC. Podle uvedených pokynů získáte užitečné poznatky a můžete zlepšit provoz.

Zlepšete onboarding zákazníků KYC a posilte dodržování pravidel

Zjednodušte onboarding zákazníků a zkraťte jeho dobu na pouhých 24 hodin.

Vyzkoušejte zdarma

Bez nutnosti zadávat platební kartu. Vyzkoušejte si službu na 14 dní zdarma.