Š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 zahájení EventStartTime | Časové razítko označující, kdy aktivita nebo událost oficiálně začala. | ||
| Popis Tento atribut zaznamenává přesné datum a čas zahájení konkrétní aktivity. Poskytuje chronologické pořadí potřebné k rekonstrukci průběhu procesu a je nezbytný pro veškeré časové analýzy. V process mining se čas zahájení používá k výpočtu délky aktivit, čekání mezi nimi a celkové doby průchodu případu. Tvoří časovou osu záznamu událostí a je důležitý pro analýzu výkonnosti a úzkých míst. Proč je to důležité Toto časové razítko je zásadní pro chronologické řazení událostí a výpočet časových ukazatelů, například doby průchodu a trvání aktivit. Kde data získat Najdete ho v auditní stopě, záznamu událostí nebo tabulkách historie workflow ve Fenergo. Bývá označen jako „Timestamp“, „StartDate“ nebo „CreationDate“. Příklady 2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:15:00Z | |||
| Název aktivity ActivityName | Název konkrétní obchodní události nebo úkolu, který v určitém okamžiku nastal v procesu onboardingu. | ||
| Popis Název aktivity popisuje jeden krok nebo milník v procesu onboardingu zákazníka, například „Provedeno úvodní prověření“ nebo „Žádost schválena“. Pořadí těchto aktivit tvoří základ mapy procesu. Analýza tohoto atributu umožňuje znázornit průběh procesu, určit obvyklé i alternativní cesty a měřit četnost jednotlivých kroků. Pomáhá zjistit, jaké činnosti se provádějí a v jakém pořadí. Proč je to důležité Tento atribut určuje jednotlivé kroky procesu. Umožňuje vytvořit mapu procesu a analyzovat jeho průběh i odchylky. Kde data získat Tyto údaje se obvykle nacházejí v tabulkách workflow nebo auditních záznamů ve Fenergo a souvisejí se změnami stavu případu nebo dokončením úkolů. Příklady Vyžádání údajů a dokumentůZahájení kontroly shodySchválení žádosti | |||
| Žádost zákazníka CustomerApplication | Jedinečný identifikátor jednoho procesu onboardingu zákazníka, který slouží jako hlavní identifikátor případu. | ||
| Popis Žádost zákazníka je hlavní identifikátor, který sdružuje všechny související aktivity a události v rámci KYC onboardingu jednoho zákazníka. Umožňuje sledovat žádost od prvního podání až po konečné vyřízení, ať už je schválena, zamítnuta, nebo uzavřena. V process mining je tento atribut zásadní pro rekonstrukci celé cesty každé žádosti. Umožňuje analyzovat průběh procesu, dobu průchodu, odchylky a úzká místa u jednotlivých žádostí a poskytuje přehled o tom, jak se konkrétní případy vyřizují. Proč je to důležité Jde o hlavní ID případu, které propojuje všechny související události a umožňuje analyzovat celý proces onboardingu zákazníka. Kde data získat Obvykle jde o primární klíč v hlavní entitě správy případů nebo správy životního cyklu klienta ve Fenergo. Příklady APP-2023-00123APP-2023-00124APP-2023-00125 | |||
| Poslední aktualizace dat LastDataUpdate | Časové razítko označující, kdy byla data pro tento proces naposledy obnovena nebo extrahována. | ||
| Popis Tento atribut zaznamenává datum a čas poslední aktualizace dat. Informuje o jejich aktuálnosti a pomáhá posoudit, nakolik jsou získané poznatky včasné. V dashboardech a reportech tato informace uživatelům ukazuje, jak aktuální data jsou. Pomáhá jim posoudit, zda analýza zachycuje provoz v reálném čase, nebo historický stav. Proč je to důležité Informuje o aktuálnosti dat, aby uživatelé věděli, jak současný je pohled na proces. Kde data získat Tato hodnota se vytvoří a připojí k datové sadě při extrakci a načítání dat (ETL). Příklady 2024-05-21T02:00:00Z2024-05-22T02:00:00Z | |||
| Zdrojový systém SourceSystem | Systém, ze kterého byla data získána. | ||
| Popis Tento atribut určuje zdrojový systém dat o událostech. V tomto procesu půjde vždy o Fenergo, ve spojených datových sadách však pomáhá rozlišit jednotlivé zdroje. Při analýze slouží hlavně k filtrování dat z konkrétních systémů nebo k ověření jejich původu. Zajišťuje přehlednost v prostředí, kde se kombinují data z více systémů, aby bylo možné získat celkový pohled na proces. 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 pro zajištění, že analýza vychází ze správného zdroje. Kde data získat Obvykle jde o statickou hodnotu, která se přidává při extrakci dat a označuje původ záznamů. Příklady FenergoFenergo CLM | |||
| Čas ukončení EventEndTime | Časové razítko označující, kdy byla aktivita nebo událost dokončena. | ||
| Popis Tento atribut zaznamenává přesné datum a čas dokončení konkrétní aktivity. Spolu s časem zahájení určuje dobu, po kterou úkol probíhal. V process mining se čas ukončení používá spolu s časem zahájení k výpočtu doby zpracování každé aktivity. Pomáhá určit, které kroky procesu zaberou nejvíce času, a analyzovat efektivitu využití zdrojů. Proč je to důležité Umožňuje vypočítat dobu zpracování aktivit, což je důležité pro odhalení dlouhotrvajících úkolů a úzkých míst ve výkonnosti. Kde data získat Najdete ho v auditní stopě nebo tabulkách historie workflow ve Fenergo. Bývá označen jako „EndDate“ nebo „CompletionDate“, případně se odvozuje z času zahájení následující události. Příklady 2023-10-26T11:30:00Z2023-10-26T15:00:10Z2023-10-27T11:45:00Z | |||
| Cílové datum SLA SlaTargetDate | Datum, do kterého má být případ onboardingu zákazníka dokončen. | ||
| Popis Cílové datum SLA je dohodnutý termín dokončení celého procesu onboardingu zákazníka. Slouží jako měřítko pro porovnání se skutečnou výkonností. Tento atribut je důležitý pro dashboard „Sledování plnění SLA“ a výpočet KPI „Míra dodržení SLA“. Umožňuje včas věnovat pozornost případům, u kterých hrozí nedodržení SLA, a pomáhá určit priority práce. Proč je to důležité Určuje cílové datum dokončení. Je důležité pro sledování plnění SLA a stanovení priorit u případů po termínu. Kde data získat Toto datum se často vypočítává podle data podání žádosti a obchodních pravidel nastavených v modulu správy SLA ve Fenergo. Příklady 2023-11-15T23:59:59Z2023-12-01T23:59:59Z | |||
| Oddělení uživatele UserDepartment | Oddělení nebo obchodní jednotka, do které patří uživatel, který aktivitu zahájil. | ||
| Popis Tento atribut uvádí organizační zařazení uživatele, který aktivitu provedl, například „Kontrola shody“, „Provoz onboardingu“ nebo „Prodej“. Často se odvozuje z profilu uživatele. Pomáhá analyzovat předávání práce mezi odděleními a odhalovat úzká místa napříč týmy. Podporuje také dashboard „Rozložení aktivit zaměstnanců“, protože umožňuje agregovat práci podle týmu nebo oddělení. Proč je to důležité Umožňuje analyzovat výkonnost procesu podle oddělení a odhalit předávání práce mezi odděleními, zpoždění i rozložení pracovní zátěže. Kde data získat Možná bude nutné doplnit tento údaj z oddělené tabulky uživatelů nebo personálních dat pomocí ID „InitiatingUser“. Fenergo ho může ukládat také v profilu uživatele. Příklady ComplianceNástup klientaZajištění kvality | |||
| Skóre rizika RiskScore | Číselné vyjádření vypočtené úrovně rizika zákazníka. | ||
| Popis Skóre rizika je číselné vyjádření potenciálního rizika spojeného se zákazníkem. Vypočítává se z různých faktorů, například jurisdikce, odvětví a výsledků prověřování. Obvykle ho počítá pravidlový engine Fenergo. Tento atribut umožňuje porovnat úroveň rizika s průběhem procesu. Analýza může například ukázat, zda vyřízení zákazníků s vysokým rizikem trvá déle nebo vyžaduje více ručních zásahů. Tyto poznatky využijete v dashboardu „Podrobná analýza rizik a kontroly shody“. Proč je to důležité Vyjadřuje míru rizika zákazníka a umožňuje analyzovat, jak ovlivňuje délku procesu, přepracování a výsledky. Kde data získat Jde o jeden z hlavních výstupů modulu Client Risk Assessment ve Fenergo. Ukládá se u případu nebo klienta. Příklady 154585 | |||
| Stav žádosti ApplicationStatus | Aktuální nebo konečný výsledek žádosti zákazníka. | ||
| Popis Tento atribut označuje výsledek žádosti po dokončení procesu, případně její aktuální stav, pokud se stále vyřizuje. Mezi běžné hodnoty patří „Schváleno“, „Zamítnuto“ nebo „Probíhá“. Jde o důležitý rozměr pro analýzu výsledků. Umožňuje filtrovat a porovnávat průběh procesu podle konečného výsledku. To je důležité pro dashboard „Přepracování a zamítnutí žádostí“ i pro výpočet KPI, například míry zamítnutých žádostí. Proč je to důležité Určuje výsledek případu a umožňuje porovnat průběh schválených a zamítnutých žádostí i zjistit míru úspěšnosti. Kde data získat Obvykle jde o konečný stav zaznamenaný u případu v systému správy případů Fenergo. Příklady SchválenoZamítnutoČeká se na kontrolu shodyUzavřeno | |||
| Uživatel, který aktivitu zahájil InitiatingUser | ID uživatele nebo jméno osoby, která aktivitu provedla. | ||
| Popis Tento atribut určuje konkrétního zaměstnance nebo systémového uživatele odpovědného za provedení úkolu či události. Může jít o jedinečné ID uživatele, jméno nebo roli. Analýza podle uživatele pomáhá porozumět rozložení pracovní zátěže a individuální výkonnosti a určit potřeby školení. Je důležitá pro dashboard „Rozložení aktivit zaměstnanců“ i pro podrobnější analýzu aktivit konkrétních osob nebo týmů. Proč je to důležité Zaznamenává, který uživatel provedl danou činnost. Umožňuje analyzovat rozložení pracovní zátěže, výkonnost týmů a přidělování zdrojů. Kde data získat Tyto údaje se obvykle ukládají spolu s podrobnostmi o události do auditních záznamů nebo tabulek historie úkolů ve Fenergo. Bývají označeny jako „UserID“, „UserName“ nebo „ModifiedBy“. Příklady j.doea.smithSYSTEM | |||
| Důvod zamítnutí RejectionReason | Kód nebo popis důvodu, proč byla žádost zamítnuta. | ||
| Popis Pokud je konečný stav žádosti „Zamítnuto“, tento atribut uvádí konkrétní důvod. Může jít například o „Neúspěšná prověrka“, „Neúplná dokumentace“ nebo „Vysoké riziko“. Tento atribut je důležitý pro analýzu příčin neúspěšných žádostí. Podporuje dashboard „Přepracování a zamítnutí žádostí“, který třídí neúspěšné případy a pomáhá odhalit opakující se problémy a přijmout nápravná opatření ke zvýšení podílu žádostí vyřízených správně napoprvé. Proč je to důležité Ukazuje, proč žádosti neprošly, a umožňuje analyzovat příčiny a snížit míru zamítnutí. Kde data získat Obvykle se nachází v poli s kódem důvodu nebo poznámkami, které je ve workflow případu ve Fenergo spojeno s konečným stavem zamítnutí. Příklady Shoda se sankčním seznamemNeplatné dokumentyPorušení zásadZákazník žádost stáhl | |||
| ID zákazníka CustomerId | Jedinečný identifikátor zákazníka nebo právnické osoby, která prochází onboardingem. | ||
| Popis ID zákazníka je jedinečný identifikátor klienta v systému kmenových dat. Číslo žádosti slouží jako ID případu v procesu, zatímco ID zákazníka propojuje aktivity onboardingu s konkrétním klientem. Tento atribut umožňuje analyzovat historii onboardingu jednoho zákazníka, například pokud v průběhu času prošel více procesy onboardingu. Umožňuje také propojit data o procesu s dalšími údaji o zákazníkovi a získat tak širší pohled na podnikání. Proč je to důležité Propojuje proces onboardingu s konkrétním zákazníkem a umožňuje analýzu z pohledu zákazníka i doplnění dalších dat. Kde data získat Toto ID se ukládá u záznamu klienta nebo právnické osoby ve Fenergo a propojuje se s případem onboardingu. Příklady CUST-98765CUST-98766CUST-98767 | |||
| Jde o přepracování IsRework | Příznak typu ano/ne, který označuje, zda je aktivita součástí opakovaného cyklu přepracování. | ||
| Popis Tento atribut označuje aktivity, které představují návrat v procesu, například návrat ke „Kontrole dokumentů“ poté, co už začala „Kontrola shody“, nebo jakýkoli výskyt aktivity „Vyžádány další informace“. Odhalení přepracování je důležité pro pochopení neefektivity a překážek v procesu. Tento příznak umožňuje přímo vypočítat KPI míry opakovaného přepracování a znázornit i vyčíslit dopad zbytečných opakovaných kroků na průběh procesu. Proč je to důležité Upozorňuje na neefektivní opakované cykly přepracování. Pomáhá vyčíslit zbytečnou práci a určit, co zlepšit, aby se zvýšil podíl případů vyřízených správně napoprvé. Kde data získat Tento příznak se odvozuje pomocí technik process mining, které analyzují pořadí aktivit. Pokud například po „Aktivitě A“ následuje „Aktivita B“ a poté se ve stejném případu znovu objeví „Aktivita A“, jde u druhého výskytu o přepracování. Příklady truefalse | |||
| Je automatizovaná IsAutomated | Příznak typu ano/ne, který označuje, zda aktivitu provedl systém, nebo uživatel. | ||
| Popis Tento atribut rozlišuje mezi úkoly, které systém provedl automaticky, například úvodním prověřením a systémovými kontrolami, a úkoly provedenými uživatelem. Obvykle se to určuje podle toho, zda je vykonavatelem systémový nebo servisní účet. Analýza tohoto příznaku pomáhá zjistit míru automatizace procesu. Umožňuje vyčíslit její dopad na efektivitu, náklady a rychlost a určit, kde lze automatizaci dále rozšířit. Proč je to důležité Rozlišuje mezi činnostmi prováděnými lidmi a systémem. Je důležitý pro analýzu automatizace a nákladů na zdroje. Kde data získat Obvykle se odvozuje z pole „InitiatingUser“. Příznak se nastaví na true, pokud ID uživatele odpovídá některému ze známých systémových účtů. Příklady truefalse | |||
| Kanál podání žádosti ApplicationChannel | Kanál, kterým zákazník podal žádost. | ||
| Popis Tento atribut určuje, odkud byla žádost podána, například přes online portál, na pobočce nebo prostřednictvím vztahového manažera. Zdroj může ovlivnit kvalitu dat i požadavky na zpracování. Tento rozměr se používá v dashboardu „Efektivita podle zdroje a typu žádosti“ k porovnání výkonnosti jednotlivých kanálů. Pomáhá zjistit, které kanály jsou nejefektivnější a kde je potřeba proces upravit. Proč je to důležité Určuje zdroj žádostí a umožňuje analyzovat efektivitu kanálů, náklady i zákaznickou zkušenost. Kde data získat Tyto údaje mohou být zaznamenány v úvodním formuláři ve Fenergo nebo předány z předcházejícího systému. Příklady Online portálPobočkaVztahový manažerMobilní aplikace | |||
| Počet žádostí o další informace AdditionalInfoRequestCount | Celkový počet případů, kdy byly k žádosti vyžádány další informace. | ||
| Popis Tato metrika počítá výskyty aktivity „Vyžádány další informace“ u každého případu. Vyšší počet znamená častější komunikaci tam a zpět, která může proces zdržet a zhoršit zákaznickou zkušenost. Tento atribut přímo podporuje KPI „Případy s žádostí o další informace“. Pomáhá určit žádosti s nadměrným počtem požadavků, které mohou ukazovat na problémy při úvodním sběru údajů nebo na složité požadavky případu. Analýza těchto údajů pomáhá zefektivnit shromažďování informací. Proč je to důležité Vyčísluje komplikace pro zákazníka a zpoždění procesu způsobené neúplnými úvodními informacemi. Pomáhá zlepšit jejich sběr. Kde data získat Jde o vypočítanou metriku, která pro každé ID „CustomerApplication“ počítá počet událostí „Vyžádány další informace“. Příklady 013 | |||
| SLA dodrženo IsSlaCompliant | Příznak typu ano/ne, který označuje, zda byl případ dokončen do cílového data SLA. | ||
| Popis Tento atribut vyjadřuje plnění SLA u dokončeného případu pomocí hodnoty ano/ne. Nastaví se na „true“, pokud časové razítko závěrečné aktivity připadá na cílové datum SLA nebo před něj, jinak na „false“. Toto vypočítané pole zjednodušuje sledování a vykazování plnění SLA. Umožňuje snadno vypočítat celkovou míru dodržení SLA KPI a filtrovat případy pro porovnání těch, které SLA dodržely, s těmi, které ho nedodržely. Proč je to důležité Přímo měří plnění SLA, usnadňuje výpočet KPI míry dodržení SLA a umožňuje filtrovat případy, které požadavkům nevyhověly. Kde data získat Odvozuje se porovnáním časového razítka poslední aktivity případu, například „Žádost schválena“ nebo „Žádost zamítnuta“, s cílovým datem SLA. Příklady truefalse | |||
| Typ zákazníka CustomerType | Kategorie zákazníka, který prochází onboardingem, například fyzická osoba, společnost nebo svěřenský fond. | ||
| Popis Tento atribut rozděluje zákazníky do kategorií podle jejich právní formy nebo vztahu k finanční instituci. Jednotlivé typy zákazníků často procházejí odlišným onboardingem s různou náročností a požadavky na hloubkovou kontrolu. Analýza procesu podle typu zákazníka pomáhá odhalit rozdíly ve výkonnosti jednotlivých skupin. Je důležitá pro dashboard „Efektivita podle zdroje a typu žádosti“, který umožňuje porovnat dobu průchodu a míru schválení a na základě toho upravit proces. Proč je to důležité Umožňuje porovnat výkonnost procesu mezi různými skupinami zákazníků, které se často liší náročností i SLA. Kde data získat Tyto údaje se obvykle ukládají u zákazníka nebo klienta ve Fenergo a propojují se s případem žádosti. Příklady Fyzická osobaSpolečnostSvěřenský fondPartnerství | |||
| Vlastník případu CaseOwner | Hlavní uživatel nebo tým odpovědný za správu žádosti po celou dobu jejího vyřizování. | ||
| Popis Vlastník případu je osoba nebo skupina, která nese hlavní odpovědnost za případ onboardingu. Obvykle odpovídá za jeho včasné a úspěšné dokončení. Tento atribut pomáhá analyzovat pracovní zátěž a výkonnost na úrovni správců případů. Lze podle něj zjistit, zda některým správcům trvá vyřízení déle nebo mají vyšší míru zamítnutí. To může ukazovat na potřebu školení nebo nerovnoměrné rozložení zdrojů. Proč je to důležité Určuje osobu nebo tým odpovědný za případ a umožňuje analyzovat výkonnost správců případů. Kde data získat Obvykle jde o konkrétní pole v hlavní entitě případu ve Fenergo, které označuje přiřazení případu. Příklady s.jonesonboarding_team_am.chen | |||
| Země Country | Země bydliště nebo jurisdikce, ke které se žádost zákazníka vztahuje. | ||
| Popis Tento atribut určuje zemi zákazníka, která často ovlivňuje konkrétní regulační pravidla a rizikové faktory platné pro proces onboardingu. Analýza procesu podle země umožňuje porovnávat dobu průchodu, úroveň rizika a náročnost procesu v jednotlivých jurisdikcích. Pomáhá zjistit, jak regionální rozdíly ovlivňují provozní výkonnost a zda proces odpovídá místním předpisům. Proč je to důležité Umožňuje rozdělit proces podle zeměpisné oblasti, což je důležité pro analýzu dopadu regulace a výkonnosti v jednotlivých regionech. Kde data získat Tyto údaje patří mezi základní informace o zákazníkovi, které se zaznamenávají při podání žádosti a ukládají u klienta ve Fenergo. Příklady USAGBRSGPDEU | |||
Aktivity při onboardingu zákazníků KYC
| Aktivita | Popis | ||
|---|---|---|---|
| Dokončení kontroly dokumentů | Označuje dokončení ručního nebo automatického ověření pravosti a správnosti všech dokumentů od zákazníka. Tato událost se obvykle odvozuje z dokončení úkolu ve workflow nebo ze změny stavu ve Fenergo. | ||
| Proč je to důležité Jde o důležitý milník, při kterém často dochází ke zpožděním. Analýza délky a výsledků této činnosti pomáhá odhalit úzká místa při zpracování dokumentů a sledovat KPI, jako je „Podíl úspěšných žádostí napoprvé“. Kde data získat Odvozuje se z časového razítka dokončení úkolu „Ověření dokumentů“ ve workflow případu nebo ze změny stavu na „Dokumenty schváleny“ v historii případu. Zachycení Použijte čas dokončení úkolu kontroly dokumentů nebo související změnu stavu. Typ události inferred | |||
| Dokončení kontroly shody | Označuje formální schválení oddělením odpovědným za shodu a potvrzuje splnění všech regulatorních požadavků. Odvozuje se z dokončení úkolu nebo ze změny stavu na „Shoda schválena“. | ||
| Proč je to důležité Dokončení této důležité fáze zásadně ovlivňuje celkovou dobu procesu. Je koncovým bodem pro měření KPI „Průměrná doba kontroly shody“ a odhalování úzkých míst v činnosti oddělení odpovědného za shodu. Kde data získat Odvozuje se z časového razítka dokončení úkolu „Kontrola shody“ ve workflow Fenergo nebo z události změny stavu v historii případu. Zachycení Použijte čas dokončení úkolu kontroly shody nebo změny stavu. Typ události inferred | |||
| Dokončení posouzení rizika | Označuje dokončení interního procesu klasifikace rizika, při kterém zákazník získá rizikové hodnocení na základě různých faktorů. Odvozuje se ze změny stavu nebo vyplnění pole s rizikovým hodnocením. | ||
| Proč je to důležité Jde o důležitý rozhodovací milník, který často určuje další postup workflow. Analýza jeho délky pomáhá zefektivnit důležitý krok kontroly shody a zajistit jednotné posuzování rizik. Kde data získat V historii případu vyhledejte změnu stavu na „Riziko posouzeno“ nebo okamžik, kdy bylo vyplněno pole „Rizikové hodnocení zákazníka“. Zachycení Použijte čas dokončení rizikového hodnocení nebo nastavení souvisejícího stavu. Typ události inferred | |||
| Případ uzavřen | Jde o poslední aktivitu, která znamená administrativní uzavření případu onboardingu ve Fenergo bez očekávání dalších kroků. Platí pro schválené i zamítnuté žádosti a lze ji odvodit z konečného stavu „Uzavřeno“. | ||
| Proč je to důležité Tato aktivita představuje konec celého procesu. Umožňuje přesně vypočítat dobu průchodu u všech případů bez ohledu na jejich výsledek a potvrzuje, že proces skončil. Kde data získat Lze ji odvodit z auditního záznamu případu ve Fenergo podle časového razítka, kdy se stav případu změní na „Uzavřeno“, „Dokončeno“ nebo jiný konečný stav. Zachycení Určete časové razítko poslední změny stavu na „Uzavřeno“ nebo „Dokončeno“. Typ události inferred | |||
| Schválení žádosti | Tato činnost označuje konečné rozhodnutí schválit žádost zákazníka o onboarding. Odvozuje se ze změny stavu případu na konečnou hodnotu „Schváleno“ nebo „Onboarding schválen“. | ||
| Proč je to důležité Tento důležitý milník označuje úspěšný výsledek před závěrečnými kroky aktivace účtu. Je nezbytný pro výpočet míry schválení a analýzu vlastností úspěšně onboardovaných zákazníků. Kde data získat V historii nebo auditním záznamu případu vyhledejte časové razítko konečné změny stavu na „Schváleno“ nebo jinou obdobnou kladnou konečnou hodnotu. Zachycení Určete časové razítko konečné změny stavu na „Schváleno“. Typ události inferred | |||
| Vytvoření případu | Tato činnost označuje zahájení KYC onboardingu, kdy je ve Fenergo formálně vytvořena žádost nového zákazníka. Obvykle jde o zaznamenanou událost s konkrétním časovým razítkem, kdy je záznam případu poprvé uložen. | ||
| Proč je to důležité Jako počáteční událost je tato činnost nezbytná pro výpočet celkové doby onboardingu a analýzu průchodnosti procesu. Poskytuje výchozí bod pro všechna další měření procesu a sledování SLA. Kde data získat Obvykle se zaznamenává čas vytvoření hlavního záznamu případu ve Fenergo. Tento údaj bývá v tabulkách souvisejících s případy nebo workflow onboardingu klientů. Zachycení Použijte čas vytvoření záznamu případu onboardingu. Typ události explicit | |||
| Zahájení kontroly shody | Tato činnost označuje začátek kontroly oddělením odpovědným za shodu. Jde o důležitou a často zdlouhavou fázi. Odvozuje se od přiřazení případu do pracovní fronty tohoto oddělení nebo od změny stavu na „Čeká na kontrolu shody“. | ||
| Proč je to důležité Tato činnost je výchozím bodem pro měření KPI „Průměrná doba kontroly shody“. Pomáhá zjistit, jak dlouho případy čekají, než na nich tým odpovědný za shodu začne pracovat. Kde data získat Z auditního záznamu případu ve Fenergo se převezme časová značka změny stavu na „Probíhá kontrola shody“ nebo přiřazení případu pracovníkovi či týmu odpovědnému za shodu. Zachycení Určete časovou značku změny stavu na „Probíhá kontrola shody“ nebo událost přiřazení. Typ události inferred | |||
| Zamítnutí žádosti | Tato činnost označuje konečné rozhodnutí zamítnout žádost zákazníka. Odvozuje se ze změny stavu případu na konečnou hodnotu „Zamítnuto“ nebo „Odmítnuto“. | ||
| Proč je to důležité Jako jeden z koncových bodů procesu je tato činnost důležitá pro výpočet „Míry zamítnutí žádostí“ a analýzu příčin neúspěchu. Pomáhá odhalit častá místa zamítnutí a zlepšit kvalitu žádostí. Kde data získat Z auditního záznamu případu se převezme časové razítko konečné změny stavu na „Zamítnuto“. Důvod zamítnutí bývá uložen v souvisejícím poli. Zachycení Určete časové razítko konečné změny stavu na „Zamítnuto“. Typ události inferred | |||
| Aktivace účtu | Označuje, že účet zákazníka byl po schválení úspěšně vytvořen a aktivován v core banking systému nebo v příslušném navazujícím systému. Lze to odvodit z konečné změny stavu ve Fenergo po schválení. | ||
| Proč je to důležité Tato aktivita potvrzuje úspěšné předání z procesu onboardingu do stavu aktivního zákazníka. Měření doby od schválení po aktivaci může odhalit zpoždění při provozním nastavení. Kde data získat Lze to odvodit ze stavu případu, například „Účet aktivní“ nebo „Onboarding dokončen“. Může jít také o samostatnou událost zaznamenanou integrací s navazujícím systémem. Zachycení Hledejte změnu stavu po schválení nebo záznam o úspěšné integraci. Typ události inferred | |||
| Přijetí dokumentů | Tato aktivita označuje, že zákazník nahrál nebo odeslal požadované dokumenty a že jsou nyní ve Fenergo k dispozici ke kontrole. Obvykle ji lze odvodit ze změny stavu případu na 'Documents Received' nebo 'Pending Review'. | ||
| Proč je to důležité Tím končí doba, po kterou zákazník čekal, a začíná interní kontrola. Tento okamžik je důležitý pro měření doby odezvy zákazníka i čekání na interní zpracování. Kde data získat Odvozuje se z auditního záznamu případu, který obsahuje časové razítko změny stavu na „Dokumenty přijaty“ nebo podobnou hodnotu. Může se také vázat na události nahrání dokumentů. Zachycení Určete časové razítko změny stavu na „Dokumenty přijaty“ nebo „Připraveno ke kontrole“. Typ události inferred | |||
| Provedení úvodní kontroly | Označuje dokončení předběžných automatických nebo ručních kontrol, například základního ověření údajů nebo kontroly sankčních seznamů. Obvykle se odvozuje ze změny stavu případu ve workflow Fenergo, například z „Nový“ na „Kontrola dokončena“. | ||
| Proč je to důležité Sledování tohoto počátečního milníku pomáhá odhalit problémy s kvalitou údajů a úzká místa ve fázi předběžného posouzení. Odděluje úvodní automatickou fázi od náročnějších ručních kontrol. Kde data získat Odvozuje se z historie případu nebo auditního záznamu podle časového razítka změny stavu na hodnotu označující dokončení kontroly, například „Kontrola úspěšná“ nebo „Čeká se na dokumenty“. Zachycení V historii případu vyhledejte změnu stavu na „Kontrola dokončena“ nebo podobnou hodnotu. Typ události inferred | |||
| Vyžádání dalších informací | Označuje opakování procesu, kdy tým onboardingu musí zákazníka požádat o vysvětlení nebo chybějící dokumenty. Jde o samostatnou událost, která se obvykle zaznamená při odeslání zprávy zákazníkovi. | ||
| Proč je to důležité Tato činnost je hlavním ukazatelem neefektivity procesu a špatné zákaznické zkušenosti. Sledování její četnosti pomáhá odhalit příčiny opakované práce a vyhodnotit KPI „Míra opakování kroků“. Kde data získat Zaznamenává se v protokolu událostí komunikace se zákazníkem nebo jako změna stavu na „Čeká se na další informace“. První možnost přesněji určuje okamžik odeslání žádosti. Zachycení Vyhledejte zaznamenanou komunikaci nebo změnu stavu na „Čeká se na odpověď zákazníka“. Typ události explicit | |||
| Vyžádání údajů a dokumentů | Tato událost označuje, že systém nebo pracovník onboardingu formálně požádal zákazníka o potřebné údaje a dokumenty. Často se zaznamenává jako samostatná událost při odeslání standardizované zprávy. | ||
| Proč je to důležité Tato činnost zahajuje fázi, jejíž délku ovlivňuje zákazník. Doba od tohoto okamžiku do doručení dokumentů je důležitá pro analýzu zákaznické cesty a odhalení zpoždění v komunikaci. Kde data získat Zaznamenává se v protokolu událostí souvisejícím s komunikací se zákazníkem nebo v záznamu o dokončení úkolu „Vyžádat dokumenty“. Lze ji také odvodit ze změny stavu na „Čeká se na údaje od zákazníka“. Zachycení Vyhledejte zaznamenanou komunikaci se zákazníkem nebo dokončení úkolu. Typ události explicit | |||
| Zahájení prověřování | Tato činnost označuje okamžik zahájení externího prověřování, kontroly AML nebo úvěrové kontroly. Často se zaznamenává jako samostatná událost při volání služby třetí strany prostřednictvím integrace. | ||
| Proč je to důležité Sledování zahájení a dokončení těchto kontrol je důležité pro pochopení zpoždění způsobených externími závislostmi. Pomáhá oddělit dobu interního zpracování od čekání na externí službu. Kde data získat Obvykle se zaznamenává v systémových protokolech, které obsahují volání API externím poskytovatelům prověřování, nebo při vytvoření úkolu „Prověření“ v případu ve Fenergo. Zachycení Vyhledejte záznamy o integraci s externí službou nebo o vytvoření úkolu „Prověření“. Typ události explicit | |||
Návody k extrakci dat
Kroky
- Otevřete modul Reporting: Přihlaste se do aplikace Fenergo pomocí uživatelského účtu s dostatečnými oprávněními pro modul Reporting & Analytics. Přejděte do modulu, který obvykle najdete v hlavní nabídce aplikace.
- Vytvořte nový report: Spusťte vytváření vlastního reportu. Zvolte název a popis, které jasně vystihují jeho účel, například „Záznam událostí onboardingu KYC pro process mining“.
- Určete primární zdroj dat: Vyberte hlavní datový objekt nebo pohled, který zachycuje životní cyklus případu. Často jde o přednastavený pohled, například
[CaseWorkflowHistory]nebo[LifecycleEventsView]. Objekt by měl obsahovat identifikátory případů, názvy událostí nebo stavy a časová razítka. - Nastavte sloupce reportu (atributy): V rozhraní pro tvorbu reportů přidejte sloupce. Namapujte zdrojová pole z datového modelu Fenergo na požadované atributy záznamu událostí. Například namapujte
CaseIDnaCustomerApplication,EventTimestampnaEventStartTimeaEventPerformernaInitiatingUser. - Nastavte logiku aktivit: Jde o nejdůležitější krok. Report musí vytvořit samostatný řádek pro každou ze 14 požadovaných aktivit. Vytvořte logické bloky nebo filtrované datové sady pro jednotlivé aktivity a spojte je pomocí UNION nebo obdobné funkce v nástroji pro tvorbu reportů.
- Definujte logiku aktivity „Vytvoření případu“: Vytvořte první blok. Ve zdroji dat vyfiltrujte událost založení případu. Ta se obvykle určuje podle nejstaršího časového razítka případu nebo podle typu události s názvem „Case Created“. Namapujte
CreationDatenaEventStartTime. - Definujte aktivity podle změn stavu: U aktivit odvozených ze změn stavu, například „Přijetí dokumentů“ nebo „Schválení žádosti“, vytvořte samostatné bloky. Filtrujte zdroj dat podle konkrétní hodnoty pole
Statusa jakoEventStartTimepoužijteStatusChangeDate. - Definujte aktivity podle úkolů: U aktivit navázaných na úkoly workflow, například „Dokončení kontroly shody“, vytvořte bloky, které filtrují podle
TaskNameaTaskCompletionDate. JakoEventStartTimepoužijte datum dokončení. - Nastavte globální filtry reportu: Pomocí filtrů na úrovni reportu omezte rozsah dat. Nastavte konkrétní
Date RangeproEventStartTime, aby export nebyl příliš velký. Pro úvodní analýzu doporučujeme období 3 až 6 měsíců. Filtrujte podle konkrétního typu případu, například „KYC Customer Onboarding“. - Spusťte report a zkontrolujte náhled: Spusťte report v rozhraní Fenergo. Zkontrolujte prvních 100 až 200 řádků a ověřte, že struktura dat je správná, všechny sloupce jsou vyplněné podle očekávání a jsou zastoupeny různé aktivity.
- Exportujte data: Exportujte celý výsledek reportu do souboru CSV nebo Excel. Výsledkem je nezpracovaný soubor záznamu událostí.
- Připravte data: Otevřete exportovaný soubor CSV. Pokud report nedokázal vytvořit sloupce
SourceSystemaLastDataUpdate, přidejte je ručně. Do všech řádků vyplňte jakoSourceSystemhodnotu „Fenergo“ a jakoLastDataUpdatečasové razítko exportu.
Konfigurace
- Předpoklady: Uživatel potřebuje přístup k modulu Fenergo Reporting & Analytics a oprávnění vytvářet a spouštět vlastní reporty.
- Hlavní zdroje dat: Report by měl vycházet především z objektů Fenergo pro správu případů a historii workflow. Mezi běžné zdroje patří
[CaseDetails],[CaseStatusHistory]a[WorkflowTaskHistory]. Přesné názvy se mohou lišit podle konfigurace Fenergo. - Časové období: Pro zajištění výkonu je důležité nastavit filtr časového razítka události. Začněte nedávným obdobím 3 až 6 měsíců. Pro historickou analýzu spouštějte report po částech, například za jednotlivá čtvrtletí nebo roky.
- Hlavní filtry: Vždy filtrujte podle konkrétního procesu nebo typu případu, například „KYC Customer Onboarding“, aby se vyloučila nesouvisející data. Podle účelu analýzy může být potřeba filtrovat také podle typu právního subjektu nebo jurisdikce.
- Definice aktivity: Každou aktivitu je třeba definovat pomocí konkrétních filtrů polí, jako jsou
Status,TaskNamenebo vyhrazené poleEventType. Tato pole umožňují oddělit jednotlivé události procesu. - Výkon: Reporty, které spojují mnoho zdrojů dat nebo prohledávají dlouhé časové období, mohou běžet pomalu. Pokud je to možné, naplánujte jejich spuštění mimo špičku. Do exportu nezařazujte nepotřebné sloupce, protože prodlužují zpracování.
Ukázkový dotaz sql
/*
This is a logical representation of the configuration needed in the Fenergo Reporting & Analytics module.
The module uses a graphical interface, but this query structure illustrates the required data sources, filters, and unions.
Fields like [CaseLifecycleData].[CaseID] are placeholders for actual Fenergo fields selected in the UI.
*/
-- Base data selection for common attributes
WITH CaseAttributes AS (
SELECT
C.CaseID AS CustomerApplication,
C.SlaTargetDate AS SlaTargetDate,
C.FinalRiskScore AS RiskScore,
C.CurrentStatus AS ApplicationStatus
FROM [CaseDetails] C
WHERE C.CaseType = 'KYC Customer Onboarding'
)
-- 1. Case Created
SELECT
A.CustomerApplication,
'Case Created' AS ActivityName,
L.CreationTimestamp AS EventStartTime,
L.CompletionTimestamp AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseLifecycleEvents] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.EventType = 'CASE_CREATED'
AND L.CreationTimestamp >= '[StartDate]' AND L.CreationTimestamp <= '[EndDate]'
UNION ALL
-- 2. Initial Screening Performed
SELECT
A.CustomerApplication,
'Initial Screening Performed' AS ActivityName,
L.CompletionTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseLifecycleEvents] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.TaskName = 'Initial Screening' AND L.TaskStatus = 'Completed'
AND L.CompletionTimestamp >= '[StartDate]' AND L.CompletionTimestamp <= '[EndDate]'
UNION ALL
-- 3. Data & Documents Requested
SELECT
A.CustomerApplication,
'Data & Documents Requested' AS ActivityName,
L.CreationTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseLifecycleEvents] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.EventType = 'CUSTOMER_COMMUNICATION' AND L.TemplateName = 'Initial Document Request'
AND L.CreationTimestamp >= '[StartDate]' AND L.CreationTimestamp <= '[EndDate]'
UNION ALL
-- 4. Documents Received
SELECT
A.CustomerApplication,
'Documents Received' AS ActivityName,
L.StatusChangeTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseStatusHistory] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.NewStatus = 'Pending Review'
AND L.StatusChangeTimestamp >= '[StartDate]' AND L.StatusChangeTimestamp <= '[EndDate]'
UNION ALL
-- 5. Document Review Completed
SELECT
A.CustomerApplication,
'Document Review Completed' AS ActivityName,
L.CompletionTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseLifecycleEvents] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.TaskName = 'Document Verification' AND L.TaskStatus = 'Completed'
AND L.CompletionTimestamp >= '[StartDate]' AND L.CompletionTimestamp <= '[EndDate]'
UNION ALL
-- 6. Background Checks Initiated
SELECT
A.CustomerApplication,
'Background Checks Initiated' AS ActivityName,
L.CreationTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseLifecycleEvents] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.EventType = 'EXTERNAL_CHECK_INITIATED'
AND L.CreationTimestamp >= '[StartDate]' AND L.CreationTimestamp <= '[EndDate]'
UNION ALL
-- 7. Risk Assessment Completed
SELECT
A.CustomerApplication,
'Risk Assessment Completed' AS ActivityName,
L.CompletionTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseLifecycleEvents] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.TaskName = 'Risk Assessment' AND L.TaskStatus = 'Completed'
AND L.CompletionTimestamp >= '[StartDate]' AND L.CompletionTimestamp <= '[EndDate]'
UNION ALL
-- 8. Compliance Review Initiated
SELECT
A.CustomerApplication,
'Compliance Review Initiated' AS ActivityName,
L.StatusChangeTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseStatusHistory] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.NewStatus = 'Pending Compliance Review'
AND L.StatusChangeTimestamp >= '[StartDate]' AND L.StatusChangeTimestamp <= '[EndDate]'
UNION ALL
-- 9. Additional Information Requested
SELECT
A.CustomerApplication,
'Additional Information Requested' AS ActivityName,
L.CreationTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseLifecycleEvents] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.EventType = 'CUSTOMER_COMMUNICATION' AND L.TemplateName = 'Additional Information Request'
AND L.CreationTimestamp >= '[StartDate]' AND L.CreationTimestamp <= '[EndDate]'
UNION ALL
-- 10. Compliance Review Completed
SELECT
A.CustomerApplication,
'Compliance Review Completed' AS ActivityName,
L.CompletionTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseLifecycleEvents] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.TaskName = 'Compliance Review' AND L.TaskStatus = 'Completed'
AND L.CompletionTimestamp >= '[StartDate]' AND L.CompletionTimestamp <= '[EndDate]'
UNION ALL
-- 11. Application Approved
SELECT
A.CustomerApplication,
'Application Approved' AS ActivityName,
L.StatusChangeTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseStatusHistory] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.NewStatus = 'Approved'
AND L.StatusChangeTimestamp >= '[StartDate]' AND L.StatusChangeTimestamp <= '[EndDate]'
UNION ALL
-- 12. Application Rejected
SELECT
A.CustomerApplication,
'Application Rejected' AS ActivityName,
L.StatusChangeTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseStatusHistory] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.NewStatus = 'Rejected'
AND L.StatusChangeTimestamp >= '[StartDate]' AND L.StatusChangeTimestamp <= '[EndDate]'
UNION ALL
-- 13. Account Activated
SELECT
A.CustomerApplication,
'Account Activated' AS ActivityName,
L.StatusChangeTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseStatusHistory] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.NewStatus = 'Active'
AND L.StatusChangeTimestamp >= '[StartDate]' AND L.StatusChangeTimestamp <= '[EndDate]'
UNION ALL
-- 14. Case Closed
SELECT
A.CustomerApplication,
'Case Closed' AS ActivityName,
L.StatusChangeTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseStatusHistory] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.NewStatus = 'Closed'
AND L.StatusChangeTimestamp >= '[StartDate]' AND L.StatusChangeTimestamp <= '[EndDate]' Chcete začít?
Tato šablona dat vám pomůže odhalit neefektivitu a zefektivnit onboarding zákazníků KYC ve Fenergo. Začněte zlepšovat provoz a zákaznickou zkušenost.
Zefektivněte onboarding zákazníků KYC a urychlete schvalování
Přidejte se k firmám, které zkracují onboarding na pouhých 24 hodin.
Platební kartu nepotřebujete. Začít můžete během několika minut.