Šablona dat pro onboarding zákazníků KYC
Šablona dat pro onboarding zákazníků KYC
- Doporučené atributy ke sběru
- Aktivity, které je vhodné sledovat
- Pokyny k extrakci dat
Atributy onboardingu zákazníků KYC
| 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
|
|||
Aktivity onboardingu zákazníků KYC
| 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
|
|||
Průvodci extrakcí dat
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.
Bez nutnosti zadávat platební kartu. Vyzkoušejte si službu na 14 dní zdarma.