KYC-ügyfélbeléptetési adatmintája
KYC-ügyfélbeléptetési adatmintája
- Javasolt attribútumok
- Nyomon követendő tevékenységek
- Útmutató az adatok kinyeréséhez
A KYC-ügyfélbeléptetés attribútumai
| Név | Leírás | ||
|---|---|---|---|
| Kezdés időpontja EventStartTime | Az az időbélyeg, amely megmutatja, mikor kezdődött hivatalosan egy tevékenység vagy esemény. | ||
| Leírás Ez az attribútum rögzíti egy adott tevékenység pontos kezdési dátumát és időpontját. Megadja a folyamat rekonstruálásához szükséges időrendet, és minden időalapú elemzéshez nélkülözhetetlen. A process mining során a kezdési időpont alapján számítható ki a tevékenységek időtartama, a közöttük eltelt várakozási idő és az ügy teljes ciklusideje. Ez adja az eseménynapló időbeli alapját, és elengedhetetlen a teljesítmény és a szűk keresztmetszetek elemzéséhez. Miért fontos? Ez az időbélyeg elengedhetetlen az események időrendi sorba rendezéséhez és az időalapú mutatók, például a ciklusidők és az időtartamok kiszámításához. Hol szerezhető be? A Fenergo auditnaplójában, eseménynaplójában vagy workflow-előzménytábláiban található, gyakran „Timestamp”, „StartDate” vagy „CreationDate” néven. Példák 2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:15:00Z | |||
| Tevékenység neve ActivityName | Az ügyfél-átvilágítási folyamat egy adott időpontjában történt üzleti esemény vagy feladat neve. | ||
| Leírás A tevékenység neve az ügyfél-átvilágítás egy lépését vagy mérföldkövét jelöli, például „Első átvilágítás elvégezve” vagy „Kérelem jóváhagyva”. A tevékenységek sorrendje adja a folyamattérkép alapját. Az attribútum elemzésével megjeleníthető a folyamat menete, azonosíthatók a gyakori és alternatív útvonalak, valamint mérhető az egyes lépések gyakorisága. Segít megérteni, milyen műveletek történnek, és milyen sorrendben. Miért fontos? Ez az attribútum határozza meg a folyamat lépéseit, így folyamattérkép készíthető, és elemezhető a folyamat menete, valamint az attól való eltérés. Hol szerezhető be? Ez az információ jellemzően a Fenergo workflow- vagy auditnapló-tábláiban található, az ügyállapot-változásokhoz vagy a feladatok befejezéséhez kapcsolva. Példák Adatok és dokumentumok bekéréseMegfelelőségi ellenőrzés elindítvaKérelem jóváhagyva | |||
| Ügyfélkérelem CustomerApplication | Egy ügyfél-átvilágítási folyamat egyedi azonosítója, amely az ügy elsődleges azonosítójaként szolgál. | ||
| Leírás Az ügyfélkérelem az azonosító, amely egy ügyfél KYC-folyamatának összes kapcsolódó tevékenységét és eseményét összefogja. Segítségével a kérelem a benyújtástól a végső döntésig követhető, akár jóváhagyják, elutasítják, akár lezárják. A process mining során ez az attribútum alapvető fontosságú az egyes kérelmek teljes folyamatának rekonstruálásához. Kérelemszinten elemezhetők vele a folyamatútvonalak, a ciklusidők, az eltérések és a szűk keresztmetszetek, így jól láthatóvá válik az egyes ügyek kezelése. Miért fontos? Ez az alapvető ügyazonosító kapcsolja össze az összes kapcsolódó eseményt, így elemezhetővé válik az ügyfél-átvilágítás teljes folyamata. Hol szerezhető be? Ez jellemzően a Fenergo központi ügykezelési vagy ügyfél-életciklus-kezelési entitásának elsődleges kulcsa. Példák APP-2023-00123APP-2023-00124APP-2023-00125 | |||
| Forrásrendszer SourceSystem | Az a nyilvántartó rendszer, amelyből az adatokat kinyerték. | ||
| Leírás Ez az attribútum azonosítja az eseményadatok forrásrendszerét. Ennél a folyamatnál ez mindig a Fenergo, de több forrásból összeállított adatkészlet esetén segít megkülönböztetni az adatforrásokat. Elemzéskor az attribútum segítségével szűrhetők az egyes rendszerekből származó adatok, illetve ellenőrizhető az adatok eredete. Egyértelművé teszi az elemzést akkor is, ha több rendszer adatait egyesítik a folyamat teljesebb áttekintéséhez. Miért fontos? Azonosítja az adatok eredetét, ami elengedhetetlen az adatirányításhoz, az ellenőrzéshez és annak biztosításához, hogy az elemzés a megfelelő forrásra épüljön. Hol szerezhető be? Ez jellemzően egy állandó érték, amelyet az adatok kinyerésekor adnak hozzá a rekordok forrásának megjelölésére. Példák FenergoFenergo CLM | |||
| Utolsó adatfrissítés LastDataUpdate | Az az időbélyeg, amely megmutatja, mikor frissítették vagy nyerték ki utoljára a folyamathoz tartozó adatokat. | ||
| Leírás Ez az attribútum rögzíti a legutóbbi adatfrissítés dátumát és időpontját. Jelzi, mennyire frissek az elemzett adatok, és segít megítélni, mennyire aktuálisak az elemzés megállapításai. A dashboardokon és jelentésekben ez az információ tájékoztatja a felhasználókat az adatok aktualitásáról. Segít tisztázni, hogy az elemzés a valós idejű működést vagy egy korábbi időszak állapotát mutatja-e. Miért fontos? Jelzi az adatok frissességét, így a felhasználók tudják, mennyire aktuális a folyamatelemzés. Hol szerezhető be? Ezt az értéket az ETL-folyamat során állítják elő és rögzítik az adatkészleten. Példák 2024-05-21T02:00:00Z2024-05-22T02:00:00Z | |||
| Befejezés időpontja EventEndTime | Az az időbélyeg, amely megmutatja, mikor fejeződött be egy tevékenység vagy esemény. | ||
| Leírás Ez az attribútum rögzíti egy adott tevékenység pontos befejezési dátumát és időpontját. A kezdési időponttal együtt megadja a feladat tényleges időtartamát. A process mining során a befejezési időpontot a kezdési időponttal együtt használják az egyes tevékenységek feldolgozási idejének kiszámításához. Ez segít azonosítani, mely lépések tartanak a legtovább, és elemezni az erőforrások hatékony felhasználását. Miért fontos? Lehetővé teszi a tevékenységek feldolgozási idejének kiszámítását, ami segít azonosítani a hosszan tartó feladatokat és a teljesítmény szűk keresztmetszeteit. Hol szerezhető be? A Fenergo auditnaplójában vagy workflow-előzménytábláiban található, gyakran „EndDate” vagy „CompletionDate” néven. A következő esemény kezdési időpontjából is meghatározható. Példák 2023-10-26T11:30:00Z2023-10-26T15:00:10Z2023-10-27T11:45:00Z | |||
| Felhasználó szervezeti egysége UserDepartment | Az a szervezeti egység vagy üzletág, amelyhez a kezdeményező felhasználó tartozik. | ||
| Leírás Ez az attribútum megadja a tevékenységet végző felhasználó szervezeti hátterét, például „Megfelelés”, „Ügyfél-átvilágítási működés” vagy „Értékesítés”. Az érték gyakran a felhasználói profilból származik. Ez a dimenzió segít elemezni a szervezeti egységek közötti átadásokat és feltárni a területeken átívelő szűk keresztmetszeteket. A „Munkatársi tevékenységek megoszlása” dashboardon lehetővé teszi a munka csapat vagy szervezeti egység szerinti összesítését. Miért fontos? Lehetővé teszi a folyamat teljesítményének szervezeti egység szerinti elemzését, és megmutatja az egységek közötti átadásokat, késedelmeket és a munkaterhelés megoszlását. Hol szerezhető be? Előfordulhat, hogy ezt az adatot egy külön felhasználói vagy HR-törzsadat-táblából kell összekapcsolni az „InitiatingUser” azonosító alapján. A Fenergo a felhasználói profil részeként is tárolhatja. Példák ComplianceÜgyfélbeléptetésMinőségbiztosítás | |||
| Kérelem állapota ApplicationStatus | Az ügyfélkérelem aktuális állapota vagy végső kimenetele. | ||
| Leírás Ez az attribútum a folyamat végén mutatja a kérelem kimenetelét, vagy folyamatban lévő ügy esetén annak aktuális állapotát. Gyakori értékei: „Jóváhagyva”, „Elutasítva” és „Folyamatban”. A kimenetelek elemzésének fontos dimenziója. Segítségével a végső eredmény szerint szűrhetők és összehasonlíthatók a folyamatútvonalak. Ez elengedhetetlen a „Kérelmek újramunkálása és elutasítása” dashboardhoz, valamint olyan KPI-k kiszámításához, mint a kérelmek elutasítási aránya. Miért fontos? Meghatározza az ügy kimenetelét, így összehasonlíthatók a jóváhagyott és elutasított kérelmek útvonalai, és elemezhető a sikerességi arány. Hol szerezhető be? Ez jellemzően a Fenergo ügykezelő rendszerében, az ügy entitásán rögzített végső állapot. Példák JóváhagyvaElutasítvaMegfelelési jóváhagyásra várLezárva | |||
| Kezdeményező felhasználó InitiatingUser | A tevékenységet végző személy felhasználói azonosítója vagy neve. | ||
| Leírás Ez az attribútum azonosítja azt a munkatársat vagy rendszerfelhasználót, aki egy adott feladatért vagy eseményért felelős. Értéke lehet egyedi felhasználói azonosító, név vagy szerepkör. A felhasználó szerinti elemzés segít megérteni a munkaterhelés eloszlását és az egyéni teljesítményt, valamint feltárni a képzési igényeket. Alapja a „Munkatársi tevékenységek megoszlása” dashboardnak, és lehetővé teszi az egyes személyek vagy csapatok tevékenységeinek részletes vizsgálatát. Miért fontos? Rögzíti, melyik felhasználó hajtotta végre a műveletet, így elemezhető a munkaterhelés megoszlása, a csapat teljesítménye és az erőforrások elosztása. Hol szerezhető be? Ez az információ jellemzően a Fenergo auditnaplóiban vagy feladatelőzmény-tábláiban szerepel az esemény részletei mellett, gyakran „UserID”, „UserName” vagy „ModifiedBy” néven. Példák j.doea.smithSYSTEM | |||
| Kockázati pontszám RiskScore | Az ügyfél számított kockázati szintjét kifejező numerikus érték. | ||
| Leírás A kockázati pontszám az ügyfélhez kapcsolódó potenciális kockázat számszerű értéke. Kiszámításakor többek között az országot, az iparágat és az átvilágítás eredményeit veszik figyelembe. A pontszámot jellemzően a Fenergo szabálymotorja számítja ki. Ez az attribútum lehetővé teszi a kockázati szint és a folyamat alakulása közötti összefüggések elemzését. Például kiderülhet, hogy a magas kockázatú ügyfelek ügyei tovább tartanak-e, vagy több manuális beavatkozást igényelnek. Ez hasznos a „Kockázati és megfelelési felülvizsgálat részletes elemzése” dashboardhoz. Miért fontos? Számszerűsíti az ügyfél kockázatát, így elemezhető, hogyan hat a kockázati szint a folyamat időtartamára, az újramunkálásra és az eredményre. Hol szerezhető be? Ez a Fenergo Client Risk Assessment moduljának egyik fontos kimenete. Az ügy vagy az ügyfél entitásán tárolják. Példák 154585 | |||
| SLA-határidő SlaTargetDate | Az a határidő, ameddig az ügyfél-átvilágítási ügyet várhatóan be kell fejezni. | ||
| Leírás Az SLA-határidő az ügyfélkérelem teljes ügyfél-átvilágítási folyamatának egyeztetett befejezési határideje. Ehhez a célértékhez viszonyítjuk a tényleges teljesítményt. Ez az attribútum elengedhetetlen az „SLA-megfelelés figyelése” dashboardhoz és az „SLA-határidő betartási aránya” KPI kiszámításához. Segítségével időben kezelhetők a határidő túllépésével fenyegető ügyek, és rangsorolható a munka. Miért fontos? Megadja a célként kitűzött befejezési dátumot, így figyelhető az SLA-követelmények teljesítése, és előnyben részesíthetők a lejárt ügyek. Hol szerezhető be? Ezt a dátumot gyakran a kérelem benyújtásának dátuma és a Fenergo SLA-kezelő moduljában beállított üzleti szabályok alapján számítják ki. Példák 2023-11-15T23:59:59Z2023-12-01T23:59:59Z | |||
| Automatikus végrehajtás IsAutomated | Logikai érték, amely jelzi, hogy a tevékenységet rendszer vagy emberi felhasználó végezte-e. | ||
| Leírás Ez az attribútum megkülönbözteti a rendszer által automatikusan végrehajtott feladatokat, például az első átvilágítást és a rendszerellenőrzéseket, azoktól, amelyeket egy felhasználó végez el. Ezt gyakran annak ellenőrzésével állapítják meg, hogy a végrehajtó felhasználó rendszer- vagy szolgáltatásfiók-e. Ennek a jelzőnek az elemzése segít megérteni a folyamat automatizáltságának mértékét. Számszerűsíthető vele az automatizálás hatása a hatékonyságra, a költségekre és a sebességre, valamint feltárhatók a további automatizálási lehetőségek. Miért fontos? Megkülönbözteti az emberi és a rendszer által végzett tevékenységeket, ami elengedhetetlen az automatizálás és az erőforrásköltségek elemzéséhez. Hol szerezhető be? Ez az érték jellemzően az „InitiatingUser” mező alapján származtatható. Az ismert rendszerfelhasználói azonosítók listája alapján állítják igazra ezt a jelzőt. Példák truefalse | |||
| Elutasítás oka RejectionReason | Az elutasítás okát megadó kód vagy leírás. | ||
| Leírás Ha a kérelem végső állapota „Elutasítva”, ez az attribútum megadja az elutasítás konkrét okát. Ilyen lehet például a „Sikertelen háttérellenőrzés”, a „Hiányos dokumentáció” vagy a „Magas kockázatú profil”. Ez az attribútum elengedhetetlen az elutasított kérelmek kiváltó okainak elemzéséhez. A „Kérelmek újramunkálása és elutasítása” dashboardon az elutasítások ok szerinti csoportosításával segít feltárni a gyakori problémákat és meghatározni a szükséges intézkedéseket, hogy több kérelem menjen át elsőre. Miért fontos? Feltárja, miért buknak el a kérelmek, így elemezhetők a kiváltó okok és csökkenthető az elutasítások aránya. Hol szerezhető be? Jellemzően a Fenergo ügykezelési workflow-jában, a végső elutasítási állapothoz kapcsolódó okkód- vagy megjegyzésmezőben található. Példák Szankciós találatÉrvénytelen dokumentumokSzabályzatsértésAz ügyfél visszavonta a kérelmet | |||
| Kérelem benyújtási csatornája ApplicationChannel | Az a csatorna, amelyen keresztül az ügyfél benyújtotta a kérelmet. | ||
| Leírás Ez az attribútum a kérelem benyújtásának forrását jelöli, például online portált, bankfiókot vagy ügyfélkapcsolati munkatársat. A csatorna hatással lehet az adatok minőségére és a feldolgozás követelményeire. Az „Ügyfélforrás és -típus szerinti hatékonyság” dashboardon a különböző csatornák teljesítményének összehasonlítására használható. Segít megérteni, mely csatornák működnek hatékonyan, és melyeken érdemes fejleszteni a folyamatot. Miért fontos? Azonosítja a kérelmek forrását, így elemezhető a csatornák hatékonysága, költsége és az ügyfélélmény. Hol szerezhető be? Ez az információ a Fenergo kezdeti adatbeviteli űrlapján is rögzíthető, vagy érkezhet egy korábbi rendszerből. Példák Online portálBankfiókÜgyfélkapcsolati munkatársMobilalkalmazás | |||
| Ország Country | Az ügyfélkérelemhez tartozó lakóhely vagy joghatóság szerinti ország. | ||
| Leírás Ez az attribútum megadja az ügyfélhez tartozó országot, amely gyakran meghatározza az ügyfél-átvilágításra vonatkozó szabályokat és kockázati tényezőket. Az ország szerinti elemzés lehetővé teszi a ciklusidők, a kockázati szintek és a folyamat összetettségének összehasonlítását a különböző joghatóságok között. Segít megérteni, hogyan hatnak a regionális különbségek a működés teljesítményére, és hogy a folyamat megfelel-e a helyi előírásoknak. Miért fontos? Földrajzi szempontok szerint csoportosítható vele a folyamat, ami segít elemezni a szabályozás hatását és a regionális teljesítményt. Hol szerezhető be? Ez az információ az ügyfélkérelem során rögzített alapvető ügyféladatok része, és a Fenergo ügyfél-entitásán tárolják. Példák USAGBRSGPDEU | |||
| SLA-követelmények teljesítve IsSlaCompliant | Logikai érték, amely jelzi, hogy az ügyet az SLA-határidőn belül fejezték-e be. | ||
| Leírás Ez az attribútum egy befejezett ügy SLA-teljesítését jelzi igen/nem értékkel. Értéke „true”, ha a végső, lezáró tevékenység időbélyege az „SlaTargetDate” dátummal megegyezik vagy annál korábbi, egyébként pedig „false”. Ez a számított mező egyszerűsíti az SLA-követést és a jelentéskészítést. Könnyen összesíthető vele az „SLA-határidő betartási aránya” KPI, és szűrhetők a követelményeknek megfelelő, illetve az azokat nem teljesítő ügyek a folyamat jellemzőinek elemzéséhez. Miért fontos? Közvetlenül méri az SLA-teljesítményt, így egyszerűen kiszámítható az SLA-határidő betartási aránya KPI, és kiszűrhetők a követelményeknek nem megfelelő ügyek. Hol szerezhető be? Ezt a végső ügytevékenység, például a „Kérelem jóváhagyva” vagy a „Kérelem elutasítva” időbélyegének az „SlaTargetDate” dátummal való összehasonlításával határozzák meg. Példák truefalse | |||
| További információkérések száma AdditionalInfoRequestCount | Az egy kérelemhez kapcsolódó további információkérések összesített száma. | ||
| Leírás Ez a mutató ügyenként számolja a „További információ kérése” tevékenység előfordulásait. A magasabb érték több oda-vissza egyeztetést jelez, ami késleltetheti a folyamatot és ronthatja az ügyfélélményt. Ez az attribútum közvetlenül támogatja a „További információkéréssel érintett ügyek” KPI-t. Segítségével azonosíthatók a túl sok kéréssel járó ügyek, amelyek a kezdeti adatgyűjtés hiányosságaira vagy az ügy összetettségére utalhatnak. Az elemzés segít egyszerűsíteni az információgyűjtést. Miért fontos? Számszerűsíti, milyen nehézséget és késedelmet okoz az ügyfélnek a kezdeti információk hiánya, így fejleszthető az adatgyűjtés lépése. Hol szerezhető be? Ez egy számított mutató, amely ügyfelenként, a „CustomerApplication” azonosító alapján összesíti a „További információ kérése” események számát. Példák 013 | |||
| Ügyfél-azonosító CustomerId | Az ügyfél-átvilágítás alatt álló ügyfél vagy jogi személy egyedi azonosítója. | ||
| Leírás Az ügyfél-azonosító az ügyfél törzsadat-rendszerben szereplő egyedi hivatkozási száma. A folyamat ügyazonosítója a kérelem száma, az ügyfél-azonosító pedig egy adott ügyfélhez kapcsolja az ügyfél-átvilágítási tevékenységeket. Ezzel az attribútummal elemezhető egy ügyfél korábbi átvilágításainak története, például ha az ügyféllel kapcsolatban több ilyen folyamat is zajlott. A folyamatadatok más ügyféladatokkal is összekapcsolhatók, így teljesebb üzleti kép alakítható ki. Miért fontos? Az ügyfél-átvilágítási folyamatot egyedi ügyfélhez kapcsolja, így ügyfélközpontú elemzés és adatbővítés válik lehetővé. Hol szerezhető be? Ezt az azonosítót a Fenergo ügyfél- vagy jogiszemély-rekordján tárolják, és az ügyfél-átvilágítási ügyhöz kapcsolják. Példák CUST-98765CUST-98766CUST-98767 | |||
| Ügyfelelős CaseOwner | Az elsődlegesen felelős felhasználó vagy csapat, amely a kérelem teljes életciklusa alatt kezeli az ügyet. | ||
| Leírás Az ügyfelelős az a személy vagy csoport, akit elsődlegesen felelőssé tesznek az ügyfél-átvilágítási ügy kezeléséért. Jellemzően ő felel azért, hogy az ügy időben és sikeresen lezáruljon. Ez az attribútum segít elemezni az ügykezelők munkaterhelését és teljesítményét. Megmutathatja, hogy egyes ügyfelelősök ügyei tovább tartanak-e, vagy gyakrabban végződnek elutasítással, ami képzési igényre vagy az erőforrások egyenlőtlen elosztására utalhat. Miért fontos? Azonosítja az ügyért felelős személyt vagy csapatot, így elemezhető az ügykezelők teljesítménye. Hol szerezhető be? Ez általában a Fenergo elsődleges ügyentitásának külön mezője, amely az ügy hozzárendelését jelzi. Példák s.jonesonboarding_team_am.chen | |||
| Ügyféltípus CustomerType | Az ügyfél-átvilágítás alatt álló ügyfél besorolása, például magánszemély, vállalat vagy vagyonkezelői konstrukció. | ||
| Leírás Ez az attribútum az ügyfeleket jogi formájuk vagy a pénzügyi intézménnyel fennálló kapcsolatuk alapján csoportosítja. Az egyes ügyféltípusok ügyfél-átvilágítási folyamata eltérhet, és más-más összetettséggel, illetve átvilágítási követelményekkel járhat. Az ügyféltípus szerinti elemzés feltárja a szegmensek közötti teljesítménykülönbségeket. Az „Ügyfélforrás és -típus szerinti hatékonyság” dashboardon összehasonlíthatók a ciklusidők és a jóváhagyási arányok, ami segíti a célzott folyamatfejlesztést. Miért fontos? Lehetővé teszi a folyamat teljesítményének összehasonlítását a különböző ügyfélszegmensek között, amelyek összetettsége és SLA-követelményei eltérhetnek. Hol szerezhető be? Ez az információ jellemzően a Fenergo ügyfél- vagy ügyfélszervezet-entitásán található, és az ügyfélkérelemhez kapcsolódik. Példák MagánszemélyVállalatVagyonkezelői konstrukcióTársulás | |||
| Újramunkálás IsRework | Logikai érték, amely jelzi, hogy egy tevékenység része-e egy újramunkálási ciklusnak. | ||
| Leírás Ez az attribútum azonosítja azokat a tevékenységeket, amelyek visszalépést jelentenek a folyamatban. Ilyen például, ha a „Megfelelési felülvizsgálat” megkezdése után ismét „Dokumentumellenőrzés” következik, vagy ha újra megjelenik a „További információ kérése” tevékenység. Az újramunkálás azonosítása elengedhetetlen a folyamat hatékonyságának és akadályainak megértéséhez. Ezzel a jelzővel közvetlenül kiszámítható az „Újramunkálási ciklusok aránya” KPI, valamint megjeleníthető és számszerűsíthető a felesleges, ismétlődő lépések hatása a folyamat menetére. Miért fontos? Feltárja a folyamat nem hatékony újramunkálási ciklusait, így számszerűsíthető a veszteség, és azonosíthatók a fejlesztendő területek, hogy több ügy menjen át elsőre. Hol szerezhető be? Ezt a jelzőt a tevékenységek sorrendjét elemző process mining módszerekkel határozzák meg. Ha például az „A tevékenység” után a „B tevékenység” következik, majd ugyanabban az ügyben ismét megjelenik az „A tevékenység”, akkor a második „A tevékenység” újramunkálásnak számít. Példák truefalse | |||
A KYC-ügyfélbeléptetés tevékenységei
| Tevékenység | Leírás | ||
|---|---|---|---|
| Dokumentumellenőrzés befejezve | Azt jelzi, hogy befejeződött a benyújtott ügyféldokumentumok hitelességének és helyességének manuális vagy automatikus ellenőrzése. Ezt az eseményt általában egy munkafolyamat-feladat befejezéséből vagy a Fenergóban bekövetkező állapotváltozásból lehet megállapítani. | ||
| Miért fontos? Ez fontos mérföldkő, ahol gyakran fordulnak elő késések. A tevékenység időtartamának és eredményének elemzése segít feltárni a dokumentumfeldolgozás szűk keresztmetszeteit, és támogatja az olyan KPI-k mérését, mint az elsőre sikeresen ellenőrzött kérelmek aránya. Hol szerezhető be? A Fenergo ügy-munkafolyamatában a „Dokumentumellenőrzés” feladat befejezési időbélyegéből vagy az ügy előzményeiben a „Dokumentumok jóváhagyva” állapot rögzítéséből állapítható meg. Rögzítés Használja a dokumentumellenőrzési feladat befejezési időbélyegét vagy a kapcsolódó állapotváltozás időpontját. Eseménytípus inferred | |||
| Kérelem elutasítva | Ez a lezáró esemény jelzi az ügyfél kérelmének végleges elutasítását. Az eseményre abból lehet következtetni, hogy az ügy állapota végleges „Elutasítva” vagy „Visszautasítva” értékre változik. | ||
| Miért fontos? A folyamat egyik fontos végpontjaként ez a tevékenység nélkülözhetetlen az „Elutasított kérelmek aránya” kiszámításához és az elutasítások okainak elemzéséhez. Segít feltárni, hol utasítják el leggyakrabban a kérelmeket, és javítani azok minőségét. Hol szerezhető be? Az ügy ellenőrzési naplójából nyerhető ki a végleges „Elutasítva” állapotra váltás időpontja. Az elutasítás oka gyakran egy kapcsolódó mezőben szerepel. Rögzítés Keresse meg a végleges „Elutasítva” állapotra váltás időpontját. Eseménytípus inferred | |||
| Kérelem jóváhagyva | Ez a tevékenység jelzi az ügyfél-átvilágítási kérelem végleges jóváhagyását. Az eseményre abból lehet következtetni, hogy az ügy állapota végleges „Jóváhagyva” vagy „Ügyfél-átvilágítás jóváhagyva” értékre változik. | ||
| Miért fontos? Ez a fontos mérföldkő a sikeres eredményt jelzi, még a számla végleges aktiválása előtt. Nélkülözhetetlen a jóváhagyási arány kiszámításához és a sikeresen átvilágított ügyfelek jellemzőinek elemzéséhez. Hol szerezhető be? Az ügy előzményeiből vagy ellenőrzési naplójából állapítható meg a végleges „Jóváhagyva” vagy hasonló, pozitív lezáró állapotra váltás időpontja. Rögzítés Keresse meg a végleges „Jóváhagyva” állapotra váltás időpontját. Eseménytípus inferred | |||
| Kockázatértékelés befejezve | A belső kockázati besorolás befejezését jelzi. Ennek során az ügyfél különböző tényezők alapján kockázati besorolást kap. Az eseményre az állapotváltozásból vagy a kockázati besorolás mező kitöltéséből lehet következtetni. | ||
| Miért fontos? Ez fontos döntési mérföldkő, amely gyakran meghatározza a további munkafolyamatot. Az időtartam elemzése segít egyszerűsíteni ezt a kritikus megfelelőségi lépést, és biztosítani a kockázatértékelés következetességét. Hol szerezhető be? Az ügy előzményeiből állapítható meg, hogy mikor vált az állapot például „Kockázatértékelés kész” értékre, vagy mikor kapott értéket a végleges „Ügyfél kockázati besorolása” mező. Rögzítés Használja azt az időpontot, amikor véglegesítették a kockázati besorolás mezőt vagy beállították a kapcsolódó állapotot. Eseménytípus inferred | |||
| Megfelelőségi ellenőrzés befejezve | A megfelelőségi részleg hivatalos jóváhagyását jelzi, vagyis azt, hogy minden szabályozói előírás teljesült. Az eseményre egy feladat befejezéséből vagy a „Megfelelőség jóváhagyva” állapotváltozásból lehet következtetni. | ||
| Miért fontos? Fontos mérföldkő, amelynek befejezése jelentősen befolyásolja a teljes átfutási időt. Ez az „Átlagos megfelelőségi ellenőrzési idő” mérésének végpontja, és segít feltárni a megfelelőségi terület szűk keresztmetszeteit. Hol szerezhető be? A Fenergo-munkafolyamatban a „Megfelelőségi ellenőrzés” feladat befejezési időbélyegéből vagy az ügy előzményeiben rögzített állapotváltozásból állapítható meg. Rögzítés Használja a megfelelőségi ellenőrzési feladat befejezésének vagy az állapotváltozásnak az időpontját. Eseménytípus inferred | |||
| Megfelelőségi ellenőrzés elindítva | Ez a tevékenység jelzi a megfelelőségi részleg ellenőrzésének kezdetét. Ez kritikus, gyakran hosszadalmas szakasz. Az eseményre abból lehet következtetni, hogy az ügy bekerül a megfelelőségi munkasorba, vagy állapota „Megfelelőségi ellenőrzésre vár” értékre változik. | ||
| Miért fontos? Ez a tevékenység adja az „Átlagos megfelelőségi ellenőrzési idő” KPI mérésének kezdőpontját. Segít megállapítani, mennyi ideig várnak az ügyek, mielőtt a megfelelőségi csapat ténylegesen foglalkozni kezd velük. Hol szerezhető be? A Fenergo ügyének ellenőrzési naplójából nyerhető ki az „Ellenőrzés alatt” állapotra váltás időpontja, illetve az, amikor az ügyet egy megfelelőségi szakértőhöz vagy csapathoz rendelik. Rögzítés Keresse meg az „Ellenőrzés alatt” állapotra váltás vagy a hozzárendelés eseményének időpontját. Eseménytípus inferred | |||
| Ügy létrehozva | Ez a tevékenység jelzi a KYC-átvilágítás kezdetét, amikor a Fenergóban hivatalosan létrehozzák az új ügyfél kérelmét. Általában külön eseményként, időbélyeggel rögzül, amikor először mentik az ügy rekordját. | ||
| Miért fontos? Kezdő eseményként ez a tevékenység elengedhetetlen a teljes ügyfél-átvilágítási idő és az átbocsátás kiszámításához. Ez adja az alapot a további folyamatmérésekhez és az SLA-k nyomon követéséhez. Hol szerezhető be? Az adat általában a Fenergóban található elsődleges ügyrekord létrehozási időbélyegéből nyerhető ki. Ez gyakran az ügyfél-átvilágítási ügyekhez vagy munkafolyamatokhoz kapcsolódó táblákban található. Rögzítés Használja az ügyfél-átvilágítási ügy rekordjának létrehozási időbélyegét. Eseménytípus explicit | |||
| Ügy lezárva | Ez az utolsó tevékenység, amely azt jelzi, hogy az ügyfél-átvilágítási ügyet adminisztratív szempontból lezárták a Fenergóban, és nincs szükség további intézkedésre. Ez a jóváhagyott és az elutasított kérelmekre egyaránt vonatkozik, és a végső „Closed” állapotból következtethető ki. | ||
| Miért fontos? Ez jelöli a teljes folyamat végpontját. Lehetővé teszi a ciklusidő pontos kiszámítását minden ügy esetében, annak kimenetelétől függetlenül, és megerősíti, hogy a folyamat lezárult. Hol szerezhető be? A Fenergo ügy-auditnaplójából következtethető ki: azt az időbélyeget kell megkeresni, amikor az ügy állapota „Closed”, „Completed” vagy más végállapot lesz. Rögzítés Keresse meg a „Closed” vagy „Completed” állapotra váltás időbélyegét. Eseménytípus inferred | |||
| Adatok és dokumentumok bekérése | Ez az esemény azt jelzi, hogy a rendszer vagy az ügyfél-átvilágítást végző munkatárs hivatalosan bekérte az ügyféltől a szükséges adatokat és dokumentumokat. Gyakran külön eseményként rögzül, amikor elküldenek egy szabványos kommunikációs sablont. | ||
| Miért fontos? Ezzel a tevékenységgel kezdődik az ügyféltől függő szakasz. Az ügyfélút és a kommunikációs késések elemzéséhez fontos mérni, mennyi idő telik el a kérés és a dokumentumok beérkezése között. Hol szerezhető be? Az ügyfélkommunikációhoz kapcsolódó eseménynaplóból vagy a „Dokumentumok bekérése” feladat befejezési naplójából nyerhető ki. Az „Ügyfél adataira vár” állapotváltozásból is következtetni lehet rá. Rögzítés Keresse meg az ügyfélkommunikációhoz tartozó naplózott eseményt vagy a feladat befejezését. Eseménytípus explicit | |||
| Dokumentumok beérkeztek | Ez a tevékenység azt jelzi, hogy az ügyfél feltöltötte vagy benyújtotta a szükséges dokumentumokat, amelyek így már ellenőrizhetők a Fenergóban. Erre általában abból lehet következtetni, hogy az ügy állapota „Dokumentumok beérkeztek” vagy „Ellenőrzésre vár” értékre változik. | ||
| Miért fontos? Ezzel véget ér az ügyfél várakozási ideje, és megkezdődik a belső ellenőrzési szakasz. Ez az esemény fontos az ügyfél válaszidejének és a belső feldolgozási sorban töltött időnek a méréséhez. Hol szerezhető be? Az ügy ellenőrzési nyomvonalából állapítható meg, amely rögzíti a „Dokumentumok beérkeztek” vagy hasonló állapotra váltás időpontját. A dokumentumfeltöltési eseményekhez is kapcsolódhat. Rögzítés Keresse meg a „Dokumentumok beérkeztek” vagy „Ellenőrzésre kész” állapotra váltás időpontját. Eseménytípus inferred | |||
| Előzetes ellenőrzés elvégezve | Az előzetes automatikus vagy manuális ellenőrzések, például az alapadatok érvényesítése vagy a szankciós listák ellenőrzésének befejezését jelzi. Ezt gyakran a Fenergo ügy-munkafolyamatában bekövetkező állapotváltozásból lehet megállapítani, például amikor az állapot „Új”-ról „Ellenőrzés kész”-re változik. | ||
| Miért fontos? Ennek a korai mérföldkőnek a követése segít felismerni az adatminőségi problémákat és az előminősítési szakasz szűk keresztmetszeteit. Elkülöníti a kezdeti automatikus szakaszt a hosszabb manuális ellenőrzéstől. Hol szerezhető be? Az ügy előzményeiből vagy az ellenőrzési naplóból állapítható meg, hogy mikor változott az ügy állapota az ellenőrzés befejezését jelző értékre, például „Ellenőrzés sikeres” vagy „Dokumentumokra vár” állapotra. Rögzítés Keresse meg az ügy előzményeiben az „Ellenőrzés kész” vagy hasonló állapotra váltást. Eseménytípus inferred | |||
| Háttérellenőrzések elindítva | Ez a tevékenység jelzi a külső háttérellenőrzések, pénzmosás elleni (AML) vizsgálatok vagy hitelképességi ellenőrzések elindítását. Gyakran külön eseményként rögzül, amikor a rendszer egy külső szolgáltatáshoz kapcsolódik. | ||
| Miért fontos? Ellenőrzések elindításának és befejezésének követése nélkülözhetetlen a külső függőségek okozta késések megértéséhez. Segít elkülöníteni a belső feldolgozási időt a külső várakozástól. Hol szerezhető be? Általában a külső ellenőrzést végző szolgáltatókhoz intézett API-hívásokat rögzítő rendszer naplóiból, vagy a Fenergo ügyében létrehozott „Háttérellenőrzés” feladatból nyerhető ki. Rögzítés Keresse meg a külső szolgáltatásokhoz intézett hívások naplóit vagy az „Ellenőrzés” feladat létrehozását. Eseménytípus explicit | |||
| Számla aktiválva | Azt jelzi, hogy az ügyfél számláját jóváhagyás után sikeresen létrehozták és aktiválták az alapbanki vagy az érintett kapcsolódó rendszerben. Ez a Fenergo jóváhagyás utáni végső állapotfrissítéséből is kikövetkeztethető. | ||
| Miért fontos? Ez a tevékenység jelzi, hogy az ügyfél-átvilágítási folyamat sikeresen átadta az ügyet az aktív ügyfélstátuszba. A jóváhagyás és az aktiválás közötti idő mérése feltárhatja a működési beállítások késedelmeit. Hol szerezhető be? Az esemény például az „Account Active” vagy az „Onboarding Complete” ügyállapotból következtethető ki. A kapcsolódó rendszerrel való integráció sikerét rögzítő eseményként is megjelenhet. Rögzítés Keresse a jóváhagyás utáni állapotváltozást vagy az integráció sikerét rögzítő eseményt. Eseménytípus inferred | |||
| További adatok bekérése | Ez ismételt ügyintézési kört jelez: az ügyfél-átvilágítást végző csapatnak pontosításért vagy hiányzó dokumentumokért újra meg kell keresnie az ügyfelet. Ez külön eseményként rögzül, jellemzően az ügyfélnek küldött üzenet elküldésekor. | ||
| Miért fontos? Ez a tevékenység a folyamat hatékonysági problémáinak és a rossz ügyfélélménynek az egyik fő jelzője. Gyakoriságának követése segít feltárni az ismételt ügyintézés okait, és támogatja az „Ismételt ügyintézési körök aránya” KPI mérését. Hol szerezhető be? Az ügyfélkommunikáció eseménynaplójából vagy a „További adatokra vár” állapotváltozásból nyerhető ki. Az előbbi pontosabban jelzi a kérés időpontját. Rögzítés Keresse meg a naplózott kommunikációs eseményeket vagy a „Válaszra vár” állapotváltozást. Eseménytípus explicit | |||
Útmutatók az adatok kinyeréséhez
Lépések
- Nyissa meg a Reporting modult: Jelentkezzen be a Fenergo alkalmazásba olyan felhasználói fiókkal, amely megfelelő jogosultságokkal rendelkezik a Reporting & Analytics modulhoz. Nyissa meg a modult, amely általában a fő alkalmazásmenüben található.
- Hozzon létre új jelentést: Indítsa el egy új egyéni jelentés létrehozását. Adjon neki olyan nevet és leírást, amely egyértelműen jelzi a célját, például: „KYC onboarding eseménynapló process mininghez”.
- Adja meg az elsődleges adatforrást: Válassza ki azt az alapul szolgáló adatobjektumot vagy nézetet, amely rögzíti az esetek életciklusát. Ez gyakran egy előre beállított nézet, például a
[CaseWorkflowHistory]vagy a[LifecycleEventsView]. Az objektumnak tartalmaznia kell az esetazonosítókat, az események nevét vagy állapotát, valamint az időbélyegeket. - Állítsa be a jelentés oszlopait (attribútumait): A jelentéskészítő felületen adja hozzá az oszlopokat. Rendelje hozzá a Fenergo adatmodelljének forrásmezőit a szükséges eseménynapló-attribútumokhoz. Például rendelje a Fenergo
CaseIDmezőjét aCustomerApplication, azEventTimestampmezőt azEventStartTime, azEventPerformermezőt pedig azInitiatingUserattribútumhoz. - Állítsa be a tevékenységek logikáját: Ez a legfontosabb lépés. A jelentést úgy kell beállítani, hogy mind a 14 szükséges tevékenységhez külön sort hozzon létre. Ehhez hozzon létre minden tevékenységhez logikai blokkokat vagy szűrt adathalmazokat, majd egyesítse őket a jelentéskészítőben UNION vagy hasonló függvény használatával.
- Határozza meg az „Eset létrehozva” logikáját: Hozza létre az első blokkot. Szűrje az adatforrást az eset kezdeti létrehozási eseményére. Ez gyakran az esethez tartozó legkorábbi időbélyeg vagy az „Eset létrehozva” nevű eseménytípus alapján történik. Rendelje a
CreationDatemezőt azEventStartTimeattribútumhoz. - Határozza meg az állapotváltozásokhoz kötött tevékenységek logikáját: Az állapotváltozásokból következtetett tevékenységekhez, például a „Dokumentumok beérkeztek” vagy a „Kérelem jóváhagyva” eseményhez hozzon létre külön blokkokat. Szűrjön az adott
Állapotmező értékére, és azEventStartTimeértékeként használja aStatusChangeDatemezőt. - Határozza meg a feladatokhoz kötött tevékenységek logikáját: A munkafolyamat-feladatokhoz kapcsolódó tevékenységekhez, például a „Megfelelőségi ellenőrzés befejeződött” eseményhez hozzon létre olyan blokkokat, amelyek a
TaskNameés aTaskCompletionDatemező alapján szűrnek. AzEventStartTimeértékeként a befejezés dátumát használja. - Állítsa be a jelentés globális szűrőit: A jelentés adatait jelentésszintű szűrőkkel korlátozza. Az
EventStartTimemezőhöz állítson be konkrétDate Rangeértéket, hogy elkerülje a túl nagy exportot. Első elemzéshez 3–6 hónapos időszak javasolt. Szűrjön a megfelelő esettípusra, például a „KYC ügyfél-onboarding” folyamatra. - Futtassa és tekintse meg a jelentést: Futtassa a jelentést a Fenergo felületén. Tekintse meg az első 100–200 sort, és ellenőrizze, hogy megfelelő-e az adatok szerkezete, minden oszlop a várt értékeket tartalmazza-e, és megjelennek-e a különböző tevékenységek.
- Exportálja az adatokat: Exportálja a teljes jelentést CSV- vagy Excel-fájlba. Ez lesz a nyers eseménynapló-fájl.
- Végezze el az utolsó adat-előkészítési lépéseket: Nyissa meg az exportált CSV-fájlt. Ha a jelentés nem tudta létrehozni a
SourceSystemés aLastDataUpdateoszlopot, adja hozzá őket kézzel. Minden sorban állítsa aSourceSystemértékét „Fenergo” értékre, aLastDataUpdatemezőbe pedig írja be az export időbélyegét.
Konfiguráció
- Előfeltételek: A felhasználónak hozzá kell férnie a Fenergo Reporting & Analytics modulhoz, és jogosultsággal kell rendelkeznie egyéni jelentések létrehozásához és futtatásához.
- Elsődleges adatforrások: A jelentést elsősorban a Fenergo ügykezelési és munkafolyamat-előzményeket tároló objektumaira kell építeni. Gyakori források:
[CaseDetails],[CaseStatusHistory]és[WorkflowTaskHistory]. A pontos elnevezések a Fenergo beállításaitól függően eltérhetnek. - Dátumtartomány: A teljesítmény megőrzése érdekében feltétlenül állítson be dátumszűrőt az esemény időbélyegére. Kezdje az elmúlt 3–6 hónappal. Korábbi időszakok elemzéséhez futtassa a jelentést több részletben, például negyedéves vagy éves bontásban.
- Fontos szűrők: Mindig szűrjön a megfelelő folyamatra vagy ügytípusra, például a „KYC-ügyfélbeléptetésre”, hogy kizárja a nem releváns adatokat. Az elemzés céljától függően jogi személytípus vagy joghatóság szerint is szűrnie kell.
- Tevékenységek meghatározása: Minden tevékenységet konkrét szűrési feltételekkel kell meghatározni, például a
Status,TaskNamevagy egy erre szolgálóEventTypemező alapján. Ezek a mezők teszik lehetővé, hogy a folyamat egyes eseményei külön azonosíthatók legyenek. - Teljesítmény: A sok adatforrást egyesítő vagy hosszú időszakot vizsgáló jelentések lassan futhatnak. Ha lehetséges, időzítse a futtatást a kisebb terhelésű órákra. Ne exportáljon szükségtelen oszlopokat, mert ezek növelik a feldolgozási időt.
Példa-lekérdezés 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]' Kezdje el most?
Ezzel az adatmintával máris közelebb kerülhet a hatékonysági problémák feltárásához és a Fenergo KYC-ügyfélbeléptetési folyamatának egyszerűsítéséhez. Kezdje el még ma a működés fejlesztését és az ügyfél-elégedettség javítását.
Egyszerűsítse a KYC-ügyfélbeléptetést, és gyorsítsa fel a jóváhagyásokat még ma
Csatlakozzon azokhoz a vállalkozásokhoz, amelyek 24 órára csökkentik az ügyfélbeléptetés idejét.
Nincs szükség bankkártyára. Néhány perc alatt elkezdheti.