Adatsablon az ügyfelek KYC-átvilágításához
Adatsablon az ügyfelek KYC-átvilágításához
- Javasolt attribútumok
- Nyomon követendő tevékenységek
- Útmutató az adatok kinyeréséhez
Az ügyfelek KYC-átvilágításának attribútumai
| Név | Leírás | ||
|---|---|---|---|
|
Esemény időpontja
EventTime
|
Az időbélyeg, amely megmutatja, mikor történt egy adott tevékenység vagy esemény. | ||
|
Leírás
Az esemény időpontja pontosan rögzíti, mikor jegyeztek fel egy tevékenységet. Ez az időbélyeg adja a folyamat időrendi alapját, és lehetővé teszi az események helyes sorrendbe rendezését az ügy előzményeinek rekonstruálásához. Ez az attribútum minden időalapú process mining elemzéshez nélkülözhetetlen. A tevékenységek közötti időtartamok, például az átfutási és várakozási idők kiszámítására, a teljes ügyidő mérésére, a folyamat teljesítményének időbeli elemzésére és a szolgáltatási szintre vonatkozó megállapodások (SLA-k) betartásának ellenőrzésére használható. Pontos időbélyegek nélkül nem érthető meg a folyamat teljesítménye, és nem tárhatók fel az időbeli szűk keresztmetszetek.
Miért fontos?
Minden tevékenység időbélyege szükséges az időtartam-alapú mutatók kiszámításához, a folyamat sorrendjének feltárásához és a szűk keresztmetszetek elemzéséhez.
Hol szerezhető be?
Az eseménynaplók és auditnapló-táblák szokásos mezője, gyakran „Timestamp”, „EventDate” vagy „CreationDate” néven.
Példák
2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T14:22:15Z
|
|||
|
Tevékenység neve
ActivityName
|
A KYC ügyfél-belépési folyamatban történt konkrét üzleti esemény vagy feladat neve. | ||
|
Leírás
A tevékenység neve az ügyfél-belépési folyamat egy-egy lépését vagy eseményét jelöli, például „Application Submitted”, „Analyst Review Started” vagy „Screening Completed - Clear”. Ezek a tevékenységek alkotják a folyamattérkép csomópontjait, és részletesen bemutatják a teljes munkafolyamatot. A tevékenységek elemzése a process mining alapja. A különböző tevékenységek sorrendjének és gyakoriságának követésével az elemzők feltárhatják a tényleges folyamatmenetet, azonosíthatják a gyakori útvonalakat, észrevehetik a szokásos eljárástól való eltéréseket, valamint meghatározhatják, mely lépések okoznak késést vagy ismételt munkát. Ez az attribútum nélkülözhetetlen a folyamattérképek elkészítéséhez és a tevékenységszintű mutatók kiszámításához.
Miért fontos?
Ez az attribútum határozza meg a folyamat egyes lépéseit. Nélkülözhetetlen a folyamatmenet feltárásához és megjelenítéséhez, valamint a szűk keresztmetszetek azonosításához.
Hol szerezhető be?
Ez az adat jellemzően az eseménynaplókban vagy auditnapló-táblákban található, gyakran az ügykezelési entitás státuszváltozásaihoz kapcsolva.
Példák
Lehetséges egyezés azonosítvaElemzői ellenőrzés megkezdveTéves pozitív egyezés megerősítveKérelem jóváhagyva
|
|||
|
Ügyfélkérelem
CustomerApplication
|
Az egyes ügyfelek ügyfél-belépési kérelmének egyedi azonosítója, amely elsődleges ügyazonosítóként szolgál. | ||
|
Leírás
Az ügyfélkérelem az azonosító, amely egy adott ügyfél beléptetéséhez kapcsolódó összes eseményt és tevékenységet összefogja. Segítségével időrendben követhető az ügyfél teljes útja a Know Your Customer (KYC) folyamaton keresztül, a kérelem benyújtásától a végső döntésig. A process mining elemzésben ez az attribútum alapvető az egyes kérelmek teljes folyamatának rekonstruálásához. Lehetővé teszi a folyamatmenetek megjelenítését, a teljes átfutási idő kiszámítását és az eltérő folyamatváltozatok azonosítását. Az azonosító szerint csoportosított ügyek elemzésével a szervezetek megérthetik, milyen útvonalakon haladhat egy kérelem, feltárhatják a szűk keresztmetszeteket, és összehasonlíthatják a különböző ügyfél-belépési folyamatok hatékonyságát.
Miért fontos?
Ez az alapvető ügyazonosító kapcsolja össze az összes kapcsolódó tevékenységet, így elemezhetővé teszi az ügyfél-belépés teljes folyamatát.
Hol szerezhető be?
Ez az azonosító jellemzően az elsődleges kulcs a Refinitiv World-Check rendszer vagy egy integrált CRM fő kérelmi vagy ügykezelési táblájában.
Példák
APP-2023-00123APP-2023-00124APP-2023-00125
|
|||
|
Ellenőrző azonosítója
ReviewerId
|
A tevékenységet végrehajtó felhasználó, elemző vagy automatikus rendszer azonosítója. | ||
|
Leírás
Az ellenőrző azonosítója, vagyis a felhasználó megmutatja, ki hajtott végre egy adott feladatot a KYC-folyamatban. Ez lehet megfelelési elemző, ügyfél-belépési szakértő vagy az automatikus tevékenységeket végző rendszerfiók. Az adat követésével láthatóvá válik a munkaterhelés eloszlása és az egyéni teljesítmény. Ez az attribútum nélkülözhetetlen az erőforrás-alapú elemzéshez. Segít megérteni a felhasználók és csapatok közötti teljesítménykülönbségeket, feltárni a képzési igényeket és kiegyensúlyozni a munkaterhelést. Az átadások, a kapcsolati hálók és a megfelelési erőforrások kihasználtságának elemzéséhez is fontos.
Miért fontos?
Lehetővé teszi a munkaterhelés eloszlásának, a felhasználói teljesítménynek és a részlegek közötti átadásoknak az elemzését, ami fontos az erőforrások optimalizálásához.
Hol szerezhető be?
Jellemzően az eseménynaplókban vagy auditnaplókban található, gyakran „UserID”, „PerformedBy” vagy „Owner” néven.
Példák
analyst_jdoesystem_auto_screenermanager_bsmith
|
|||
|
Esemény befejezési időpontja
EventEndTime
|
Az időbélyeg, amely megmutatja, mikor fejeződött be egy adott tevékenység vagy esemény. | ||
|
Leírás
Az esemény befejezési időpontja jelöli a tevékenység végét. Sok esemény pillanatszerűként modellezhető, amikor a StartTime megegyezik az EndTime értékével, egyes tevékenységeknek azonban mérhető időtartamuk van, például az „Analyst Review Started” és az „Analyst Review Completed” közötti időnek. A kezdési és befejezési időpont együttesen pontosan megmutatja a feldolgozási időt. A folyamatelemzésben a befejezési időpont szükséges a tevékenység pontos feldolgozási idejének kiszámításához, amely nem tartalmazza a várakozást, szemben az átfutási idővel. Így elkülöníthető, mennyi időt tölt az ügy aktív feldolgozással, és mennyit várakozik egy sorban. Ez fontos az erőforrások optimalizálásához és a hatékonyság elemzéséhez.
Miért fontos?
Lehetővé teszi a tevékenység feldolgozási idejének pontos kiszámítását, és elkülöníti az aktív munkát a várakozástól, így pontosabb teljesítményelemzést tesz lehetővé.
Hol szerezhető be?
Az időtartammal rendelkező tevékenységeknél ez külön mezőben szerepelhet az eseménynaplóban vagy az auditnapló-táblákban, például „CompletionDate” vagy „EndDate” néven.
Példák
2023-10-26T10:45:00Z2023-10-26T12:00:00Z2023-10-27T15:00:00Z
|
|||
|
Kockázati szint
RiskLevel
|
Az ügyfélkérelem számított kockázati besorolása, például alacsony, közepes vagy magas. | ||
|
Leírás
A kockázati szint a KYC-folyamat egyik fontos adata, amely meghatározza a szükséges átvilágítás mértékét. Besorolása gyakran olyan tényezőkön alapul, mint az ügyfél típusa, földrajzi elhelyezkedése és tevékenysége. Ez jelentősen befolyásolhatja, milyen útvonalon halad a kérelem. A folyamat kockázati szint szerinti szegmentálása nélkülözhetetlen. Segít megmagyarázni az átfutási idők és a folyamatmenetek eltéréseit, például azt, hogy a magas kockázatú kérelmek több lépést igényelhetnek és tovább tarthatnak. Ez az attribútum fontos az „Application Rejection Rate and Reasons” és a „Background Check Initiation Cycle Time” dashboardokhoz, mert megmutatja, hogyan hat a kockázat az eredményekre és a hatékonyságra.
Miért fontos?
A folyamat kockázati szint szerinti bontása segít megérteni, miért tart tovább egyes ügyek feldolgozása, miért haladnak más útvonalon, és hogyan alakulnak az elutasítási arányok.
Hol szerezhető be?
Ez az ügyfélkérelem vagy ügy nyilvántartásának alapvető adata. A Refinitiv World-Check ügykezelő moduljában található.
Példák
AlacsonyKözepesMagas
|
|||
|
Részleg
DepartmentName
|
A tevékenység végrehajtásáért felelős részleg vagy funkcionális csapat. | ||
|
Leírás
Ez az attribútum megadja a felhasználó üzleti területét vagy csapatát, például az „Onboarding”, „Compliance” vagy „Quality Assurance” részleget. Így az elemzés az egyes felhasználók helyett magasabb szervezeti szinten végezhető el. A részleg szerinti elemzés fontos a részlegek közötti szűk keresztmetszetek feltárásához és az átadási idők méréséhez. Megmutatja, hogyan halad a munka a csapatok között, és hol keletkeznek késések az átadások során. Ez segít gördülékenyebbé tenni a csapatok közötti együttműködést és javítani a folyamat egészének hatékonyságát.
Miért fontos?
Lehetővé teszi a folyamat teljesítményének részlegenkénti elemzését, és segít feltárni a csapatok közötti átadások késéseit.
Hol szerezhető be?
Ez az adat a rendszer felhasználói profiljában vagy egy kapcsolódó HR-rendszerben szerepelhet. Előfordulhat, hogy a felhasználói azonosító alapján kell összekapcsolni az eseményadatokkal.
Példák
Ügyfél-belépési csapatMegfelelési ellenőrzésFelső vezetés
|
|||
|
SLA-határidő
SlaTargetDate
|
Az a határidő, ameddig az ügyfél-belépési folyamatot be kell fejezni. | ||
|
Leírás
Az SLA-határidő az ügyféllel kötött szolgáltatási szintre vonatkozó megállapodásban vagy a belső szabályzatokban meghatározott határidő az ügy teljes feldolgozására. Ehhez viszonyítják a tényleges befejezési időt. Ez az attribútum nélkülözhetetlen az „SLA Adherence and Breach Analysis” dashboardhoz. Segítségével megállapítható, hogy az ügy időben lezárult-e. Az SLA-túllépések elemzése feltárja a késéseket okozó rendszerszintű problémákat, és lehetővé teszi a korrekciós intézkedések meghozatalát a határidők betartása és a megfelelési követelmények teljesítése érdekében.
Miért fontos?
Ez az időben történő teljesítés viszonyítási alapja, és nélkülözhetetlen az SLA-betartási arány kiszámításához, valamint a túllépések elemzéséhez.
Hol szerezhető be?
Ezt a dátumot gyakran a kérelem benyújtásának dátuma és az üzleti szabályok alapján számítják ki. Az ügy nyilvántartásának egyik mezőjében tárolható.
Példák
2023-11-10T17:00:00Z2023-11-15T17:00:00Z2023-11-20T17:00:00Z
|
|||
|
Adatok utolsó frissítése
LastDataUpdate
|
Az az időbélyeg, amely megmutatja, mikor frissítették vagy nyerték ki utoljára az esemény adatait a forrásrendszerből. | ||
|
Leírás
Ez az attribútum az adatok frissességét jelzi. Rögzíti, mikor kérdezték le utoljára az adatokat a Refinitiv World-Checkből. Ez segít megítélni, mennyire aktuálisak a process mining dashboardok és elemzések. Az elemzés során a felhasználók ebből tudhatják meg, hogy közel valós idejű adatokat vagy egy adott időpontban készült pillanatképet látnak-e. Az adatirányításhoz is szükséges, és segít reális elvárásokat kialakítani az elemzések aktualitásával kapcsolatban.
Miért fontos?
Fontos információt ad az adatok frissességéről, így a felhasználók tudják, mennyire aktuális a folyamatelemzés.
Hol szerezhető be?
Ezt az időbélyeget az adatkinyerés (ETL) során állítják elő és adják hozzá.
Példák
2023-11-01T02:00:00Z2023-11-02T02:00:00Z
|
|||
|
Automatizált
IsAutomated
|
Jelzi, hogy a tevékenységet rendszer (true) vagy ember (false) végezte-e. | ||
|
Leírás
Ez a logikai attribútum megkülönbözteti az automatizált rendszerfeladatokat a felhasználók által végzett manuális tevékenységektől. Például az „Automatizált szűrés végrehajtva” tevékenység automatizáltnak, míg az „Elemzői felülvizsgálat megkezdődött” manuálisnak számít. Ez a megkülönböztetés elengedhetetlen az automatizálás elemzéséhez. Segít felmérni, hogyan hat az automatizálás a folyamat hatékonyságára, azonosítani a később automatizálható manuális feladatokat, és megérteni az emberek és a rendszerek közötti együttműködést. A rendszer feldolgozási ideje így egyértelműen elkülöníthető a manuális ügyintézés idejétől.
Miért fontos?
Megkülönbözteti a rendszer és az emberek által végzett tevékenységeket. Ez segít felmérni az automatizálás hatását és azonosítani a további automatizálási lehetőségeket.
Hol szerezhető be?
Az érték általában a tevékenység neve vagy az eseményhez tartozó felhasználói azonosító alapján állapítható meg, például ha a felhasználó egy „system” fiók.
Példák
truefalse
|
|||
|
Egyezésazonosító
MatchId
|
A World-Check-átvilágítás során talált lehetséges egyezés egyedi azonosítója. | ||
|
Leírás
Ha az automatizált szűrés potenciális egyezést talál a szankciós listákon, a kiemelt közszereplők (PEP) listáin vagy a negatív sajtóhírek között, gyakran Match ID-t rendel a találathoz. Ez az azonosító összekapcsolja a kérelmet azzal a World-Check-adatbázisban szereplő rekorddal, amely a riasztást kiváltotta. Ez az attribútum részletes megfelelési elemzést tesz lehetővé. Az elemzők megvizsgálhatják az egyezések jellegét, nyomon követhetik az egyes riasztások lezárását, például hogy téves riasztásról vagy valódi egyezésről van-e szó, és feltárhatják, mely riasztástípusok fordulnak elő leggyakrabban, illetve melyek lezárása tart a legtovább. Részletesebb képet ad a „Potenciális egyezés azonosítva” tevékenységről.
Miért fontos?
Közvetlenül összekapcsolja az esetet a konkrét szűrési eredménnyel, így részletesebben elemezhetők az egyezések lezárási ideje és a riasztások típusai.
Hol szerezhető be?
Ezt az azonosítót a World-Check szűrőmotorja hozza létre, és potenciális egyezés esetén rögzíti a kérelemhez.
Példák
WC-MATCH-459021WC-MATCH-459022WC-MATCH-459023
|
|||
|
Elutasítás oka
RejectionReason
|
Az ügyfélkérelem elutasításakor megadott konkrét indok. | ||
|
Leírás
Az elutasítás oka rögzíti, miért utasították el a kérelmet. Ilyen ok lehet például a „Sanctions Match”, a „Incomplete Documentation” vagy a „High Risk Profile”. Ez strukturált visszajelzést ad a beérkező kérelmek minőségéről és az átvilágítás hatékonyságáról. Ez az attribútum az „Application Rejection Rate and Reasons” dashboard fő adata. Az elutasítási okok elemzése segít feltárni az elutasítások kiváltó okait, fejleszteni a folyamatot, egyértelműbb tájékoztatást adni a kérelmezőknek, és csökkenteni a szükségtelen elutasításokat. Minőségi háttérrel egészíti ki az elutasítási arány számszerű KPI-ját.
Miért fontos?
Feltárja a kérelmek elutasításának kiváltó okait, így segít meghatározni, hol kell fejleszteni az ügyfél-belépési folyamatot az elutasítási arány csökkentéséhez.
Hol szerezhető be?
Az „Application Rejected” esemény bekövetkezésekor rögzítik, valószínűleg az ügy vagy a kérelem egyik mezőjében.
Példák
Politikailag közszereplővel való egyezésSzankciós listán szereplő egyezésSikertelen dokumentum-ellenőrzésKedvezőtlen sajtómegjelenés
|
|||
|
Forrásrendszer
SourceSystem
|
Az a rendszer, amelyből az eseményadatokat kinyerték, ebben az esetben a Refinitiv World-Check. | ||
|
Leírás
Ez az attribútum azonosítja a folyamatadatok forrását. Egyetlen forrásból történő adatkinyerésnél az értéke állandó lehet, több rendszer, például egy CRM és a World-Check adatainak egyesítésekor viszont nélkülözhetetlen a folyamat teljes képének kialakításához. Az elemzésben segíti az adatirányítást, a hibakeresést és az adatok környezetének megértését. Például az alapvető átvilágítási rendszerben rögzített tevékenységek tulajdonságai vagy részletessége eltérhetnek egy kapcsolódó rendszerben rögzítettektől. Az attribútum biztosítja, hogy az adatok eredete egyértelmű és ellenőrizhető legyen.
Miért fontos?
Azonosítja az adatok forrását, ami nélkülözhetetlen az adatirányításhoz, az ellenőrzéshez és a több forrásból származó adatok egyesítéséhez.
Hol szerezhető be?
Gyakran az adatkinyerés, -átalakítás és -betöltés (ETL) során hozzáadott állandó érték, amely az adatkészletet jelöli.
Példák
Refinitiv World-CheckWorldCheckOne
|
|||
|
Ismételt tevékenység
IsRework
|
Jelzi, ha egy tevékenység ugyanazon az eseten belül másodszor vagy többször is előfordul. | ||
|
Leírás
Az IsRework egy számított logikai attribútum, amely azonosítja, ha egy tevékenység ugyanazon ügyfélkérelem esetében ismétlődik. Ha például egy kérelemhez többször is végrehajtják a „Kockázatértékelés elvégezve” tevékenységet, az ismételt előfordulások újramunkálásként jelennek meg. Ez az attribútum segít feltárni a folyamat hatékonysági problémáit, a köröket és a szükségtelen ismétléseket. Közvetlenül támogatja a „Kockázatértékelés újramunkálása és hatékonysága” dashboardot és a „Kockázatértékelés újramunkálási aránya” KPI-t. Az újramunkálás elemzésével feltárhatók a minőségi, információs vagy döntéshozatali problémák, amelyek felesleges munkához és hosszabb átfutási időhöz vezetnek.
Miért fontos?
Az ismétlődő tevékenységek jelölésével feltárja a folyamat hatékonysági problémáit. Az újramunkálási körök elemzése segít javítani a minőséget és csökkenteni az átfutási időt.
Hol szerezhető be?
Az adatátalakítás során számítjuk ki: elemezzük az egyes eseteken belüli tevékenységsorrendet, és megjelöljük az adott tevékenység első előfordulását követő összes ismétlődést.
Példák
truefalse
|
|||
|
Kérelem benyújtási csatornája
ApplicationChannel
|
Az a csatorna, amelyen keresztül az ügyfél benyújtotta a kérelmet, például online portál, bankfiók vagy mobilalkalmazás. | ||
|
Leírás
A kérelem benyújtási csatornája megmutatja, honnan érkezett az ügyfélkérelem. A különböző csatornákon eltérhet az adatok teljessége és minősége, valamint az ügyfelek összetétele, ami hatással lehet a folyamat további lépéseire. Ez az attribútum nélkülözhetetlen az „Application Throughput by Channel” dashboardhoz. A különböző csatornákon érkező kérelmek számának, átfutási idejének és eredményeinek elemzésével a szervezet azonosíthatja a leghatékonyabb csatornákat, valamint azokat, ahol fejlesztésre van szükség. Az elemzés támogatja az erőforrások elosztásáról és a csatornák fejlesztéséről szóló stratégiai döntéseket.
Miért fontos?
Segít összehasonlítani a benyújtási csatornák teljesítményét és hatékonyságát, támogatva a technológiával és az ügyfélélménnyel kapcsolatos stratégiai döntéseket.
Hol szerezhető be?
Ezt az adatot jellemzően a folyamat elején rögzítik, és a kérelem egyik attribútumaként tárolják.
Példák
Online portálMobilalkalmazásBankfiókÜgyfélkapcsolati menedzser
|
|||
|
SLA megsértve
SlaBreached
|
Logikai jelző, amely mutatja, hogy az ügyfél-átvilágítási eset az SLA-céldátum után zárult-e le. | ||
|
Leírás
Ez a számított jelző azt mutatja, hogy az eset megsértette-e a szolgáltatási szintre vonatkozó megállapodást (SLA). Meghatározásához az esetet lezáró tevékenység, például a „Kérelem jóváhagyva” vagy a „Kérelem elutasítva” időbélyegét kell összevetni az esethez tartozó „SlaTargetDate” értékkel. Ez a jelző szolgál az „SLA-teljesítés és -sértések elemzése” dashboard és az „SLA-teljesítési arány” KPI alapjául. Egyszerűbbé teszi az elemzést, mert a felhasználók gyorsan kiszűrhetik az összes SLA-t sértő esetet. Ezek folyamatjellemzőit elemezve a szervezetek feltárhatják a késések kiváltó okait, és célzottan javíthatják a folyamatot.
Miért fontos?
Közvetlenül méri a szolgáltatási szintre vonatkozó megállapodások teljesülését, így könnyen kiszűrhetők a késedelmes esetek, és elemezhetők azok kiváltó okai.
Hol szerezhető be?
Az adatátalakítás során számítjuk ki: az eset utolsó tevékenységének időbélyegét összevetjük a SlaTargetDate mező értékével.
Példák
truefalse
|
|||
|
Ügyfél országa
CustomerCountry
|
Az ügyfél lakóhelye vagy bejegyzésének országa. | ||
|
Leírás
Ez az attribútum az ügyfél földrajzi elhelyezkedését jelzi. Az ország fontos tényező a KYC-folyamatok kockázatértékelésében és a szabályozási követelmények meghatározásában. Az egyes joghatóságok szabályai eltérnek, ami befolyásolhatja a folyamat menetét és időtartamát. Az ország szerinti folyamatelemzés lehetővé teszi a régiók teljesítményének összehasonlítását, a helyi szűk keresztmetszetek feltárását és a helyi szabályozásnak való megfelelés ellenőrzését. A földrajzi bontás fontos működési különbségekre világíthat rá.
Miért fontos?
Lehetővé teszi a folyamat földrajzi elemzését, és segít feltárni a teljesítmény, a kockázatok és a megfelelési követelmények regionális eltéréseit.
Hol szerezhető be?
Az ügyfélprofil vagy a kérelem szokásos mezője.
Példák
USAGBRSGPDEU
|
|||
|
Ügyfél-azonosító
CustomerId
|
Az ügyfél-belépési folyamatban részt vevő ügyfél egyedi azonosítója. | ||
|
Leírás
Az ügyfél-azonosító az ügyfélprofil egyedi azonosítója. Nem azonos az ügyfélkérelem-azonosítóval, mivel egy ügyfél idővel több kérelmet is benyújthat. Ez az attribútum kapcsolja össze az ügyfél-belépési folyamatot az ügyfél törzsadatával. Az elemzésben az ügyfél-azonosítóval követhetők ugyanannak az ügyfélnek az ismételt kérelmei, és CRM- vagy törzsadat-rendszerből származó további ügyféladatokkal egészíthetők ki a folyamatadatok. Így az ügyfél teljes útja is vizsgálható, nem csak egyetlen beléptetési folyamat.
Miért fontos?
Az ügyfél-belépési ügyet egy adott ügyfélhez kapcsolja, így elemezhetők az ismételt kérelmek, és az adatok kiegészíthetők az ügyfél törzsadataival.
Hol szerezhető be?
Ez a kérelem vagy az ügy nyilvántartásának fontos mezője, amely összekapcsolja azt az ügyfél törzsadataival.
Példák
CUST-98765CUST-98766CUST-98767
|
|||
|
Ügyféltípus
CustomerType
|
Az ügyfél besorolása, például magánszemély, gazdasági társaság vagy vagyonkezelői trust. | ||
|
Leírás
Az ügyféltípus az ügyfél-belépési folyamatban részt vevő entitást sorolja kategóriába. Az egyes ügyféltípusokhoz eltérő beléptetési követelmények, kockázati profilok és szabályozási kötelezettségek tartozhatnak. Egy gazdasági társaság beléptetése például rendszerint összetettebb, mint egy magánszemélyé. Ez az attribútum szegmentációs elemzéshez használható, különösen a „KYC Customer Type Performance” dashboardon. Segítségével összehasonlítható a folyamat hatékonysága, átfutási ideje és elutasítási aránya az egyes ügyfélszegmensek között. Az eredmények alapján az ügyfél-belépési folyamat az egyes ügyféltípusok igényeihez igazítható és optimalizálható.
Miért fontos?
Lehetővé teszi a különböző ügyfélszegmensek teljesítményének összehasonlítását, így az ügyfél-belépési folyamat az egyes típusokhoz igazítható és optimalizálható.
Hol szerezhető be?
Ez a forrásrendszerben az ügyfél vagy a kérelem nyilvántartásában szereplő alapvető attribútum.
Példák
MagánszemélyGazdasági társaságNonprofit szervezetVagyonkezelői trust
|
|||
Az ügyfelek KYC-átvilágításának tevékenységei
| Tevékenység | Leírás | ||
|---|---|---|---|
|
Átvilágítás befejezve, egyezés található
|
Az átvilágítási ügyet hivatalosan „Match Found” eredménnyel zárják le, ami azt jelzi, hogy megerősített kockázatot azonosítottak. Ez más további folyamatot indít el, például fokozott átvilágítást vagy elutasítást. | ||
|
Miért fontos?
Ez az átvilágítás fő kedvezőtlen kimenetele. Az ilyen ügyek elemzése segít megérteni a kockázati profilokat és az ellenőrzési intézkedések hatékonyságát.
Hol szerezhető be?
A végső ügyállapot „Match Found”, „Risk Identified” vagy „Closed - Positive” értékre változásából következtethető ki. Az időbélyeg a végső státuszváltozás időpontja.
Rögzítés
A megerősített egyezést jelző végső ügyállapot időbélyegéből származik.
Eseménytípus
inferred
|
|||
|
Átvilágítás befejezve, nincs egyezés
|
Az átvilágítási ügyet hivatalosan „Clear” eredménnyel zárják le, vagyis nem találtak valós egyezést. A döntést visszaküldik a kezdeményező rendszernek, így folytatódhat az ügyfél beléptetése. | ||
|
Miért fontos?
Ez az átvilágítás sikeres, szokásos útvonalának végét jelöli. Végpontként használható az alacsony kockázatú kérelmek átfutási idejének mérésére.
Hol szerezhető be?
A végső ügyállapot „Clear”, „Complete” vagy „Closed - No Match” értékre változásából következtethető ki. Az időbélyeg a végső státuszváltozás időpontja.
Rögzítés
A tiszta eredményt jelző végső ügyállapot időbélyegéből származik.
Eseménytípus
inferred
|
|||
|
Elemzői ellenőrzés megkezdve
|
A megfelelési elemző megkezdi az ügyfélkérelemhez kapcsolódó lehetséges egyezések manuális vizsgálatát. Összeveti az egyezések adatait az ügyfél adataival, hogy megállapítsa, valóban relevánsak-e. | ||
|
Miért fontos?
Ez jelöli a manuális megfelelési ellenőrzés kezdetét, amely gyakran szűk keresztmetszet. A „Potential Match Identified” és e tevékenység közötti idő megmutatja a sorban állásból eredő késést, az ellenőrzés időtartama pedig az elemzői munka hatékonyságát.
Hol szerezhető be?
Akkor következtethető ki, amikor egy elemző megnyit vagy magához rendel egy ügyet az ellenőrzési sorból. A rendszer ezt az auditnaplóban külön is rögzítheti, amikor az ügy státusza „In Review” értékre változik, vagy az ügyet egy adott felhasználóhoz rendelik.
Rögzítés
Az ügy „Under Review” státuszra váltásából vagy abból állapítható meg, hogy az ügyet egy elemzőhöz rendelik.
Eseménytípus
inferred
|
|||
|
Kérelem benyújtva
|
Ez a tevékenység jelzi a KYC-ügyfélbeléptetés kezdetét, amikor az ügyfél benyújtja a kérelmét. Az eseményt általában egy CRM- vagy alapalkalmazási rendszer rögzíti, amely ezután elindítja a Refinitiv World-Checkben a szűrést. | ||
|
Miért fontos?
Ez az ügyfélbeléptetés teljes folyamatának első eseménye. A kezdőpont és a befejezés közötti idő mutatja a teljes ügyfélbeléptetési átfutási időt, amely fontos mérőszáma az ügyfélélménynek és az SLA-k teljesítésének.
Hol szerezhető be?
Ez az esemény nem a World-Check saját eseménye. Egy korábbi rendszerből, például CRM-ből vagy ügyfélszámla-kezelő platformról kell kinyerni, majd a Customer Application ID alapján összekapcsolni.
Rögzítés
Az eseményt a forrásalkalmazás rögzíti a kérelem első benyújtásakor.
Eseménytípus
explicit
|
|||
|
Kérelem elutasítva
|
Az ügyfélkérelmet hivatalosan elutasítják, gyakran a World-Check „Match Found” eredménye vagy más kockázati tényező miatt. Ez az ügyfél-belépési folyamat végső kedvezőtlen kimenetele. | ||
|
Miért fontos?
Ez a folyamat fő sikertelen végpontja. Az elutasítások, különösen azok okainak és az őket megelőző tevékenységeknek az elemzése segít a folyamat fejlesztésében és a szükségtelen elutasítások csökkentésében.
Hol szerezhető be?
Ezt a végső üzleti döntést a felsőbb szintű CRM- vagy alapalkalmazási rendszerben rögzítik, nem magában a World-Checkben. Az adatokat ebből a rendszerből kell kinyerni.
Rögzítés
A forrásalkalmazás rögzíti az eseményt, gyakran az elutasítás okát jelölő kóddal együtt.
Eseménytípus
explicit
|
|||
|
Számla aktiválva
|
Az ügyfél számláját létrehozzák és aktiválják az alaprendszerben, ezzel lezárul az ügyfél-belépési folyamat. Erre a kérelem végső jóváhagyása után kerül sor, és a számla használatra kész lesz. | ||
|
Miért fontos?
Ez a folyamat utolsó, értéket teremtő lépése. A kérelem benyújtása és a számla aktiválása közötti idő fontos mutatója a működési hatékonyságnak és az ügyfél-elégedettségnek.
Hol szerezhető be?
Ezt az eseményt a World-Check nem rögzíti. Az alaprendszerben, például a banki vagy ügyfélszámla-rendszerben szerepel, és az ügyfélkérelem-azonosító alapján kell összekapcsolni.
Rögzítés
A számla aktiválásakor az alaprendszer rögzíti az eseményt.
Eseménytípus
explicit
|
|||
|
Szűrési kérelem létrehozva
|
A Refinitiv World-Check rendszerben hivatalosan létrejön egy új szűrési eset az ügyfélkérelemhez. Ezt egy API-hívás vagy egy korábbi rendszerből végzett manuális adatbevitel indítja el. Ez jelzi a kockázati információk ellenőrzésének kezdetét. | ||
|
Miért fontos?
Ez jelöli az átvilágítási alfolyamat hivatalos kezdetét. Az Application Submitted és e tevékenység közötti idő megmutatja, mennyit késik az átadás az üzleti terület rendszere és a megfelelési funkció között.
Hol szerezhető be?
A World-Check ügykezelési naplóiban vagy auditnaplójában rögzítik. Az adott ügyhöz vagy entitásazonosítóhoz tartozó létrehozási esemény és annak időbélyege használható.
Rögzítés
A rendszer automatikusan rögzíti, amikor új átvilágítási ügy jön létre.
Eseménytípus
explicit
|
|||
|
Valós egyezés megerősítve
|
Az elemző megerősíti, hogy a lehetséges egyezés valóban az átvilágítás alatt álló ügyfél, és ezzel lehetséges kockázatot azonosít. Ez fontos mérföldkő, amely rendszerint további átvilágítást vagy a kérelem elutasítását vonja maga után. | ||
|
Miért fontos?
Ez fontos kockázatcsökkentési eredmény és a folyamat meghatározó pontja. Közvetlenül befolyásolja az ügyfélkérelemről hozott végső döntést, és a megfelelési jelentésekhez, illetve elemzésekhez is nélkülözhetetlen.
Hol szerezhető be?
Az elemző egy adott egyezést „True Match” vagy „Confirmed Match” értékkel zár le. Az eseményt rögzítik az ügy auditnaplójában.
Rögzítés
A rendszer akkor rögzíti, amikor az elemző hivatalosan megerősít egy egyezést.
Eseménytípus
explicit
|
|||
|
Automatikus átvilágítás lefuttatva
|
A World-Check rendszer automatikusan összeveti az ügyfél adatait a kockázati adatbázisával. A rendszer által végzett ellenőrzés kezdeti eredményeket ad, például lehetséges egyezéseket vagy tiszta státuszt. | ||
|
Miért fontos?
Ez az átvilágítási folyamat első értékteremtő lépése. Az ezt megelőző késések rendszer- vagy adat-előkészítési problémákra utalnak, az eredmény pedig meghatározza a későbbi manuális munkaterhelést.
Hol szerezhető be?
Az esemény szerepelhet kifejezetten az ügy auditnaplójában, de az időpontja az első átvilágítási eredmények elérhetővé válásából is kikövetkeztethető.
Rögzítés
A rendszer naplóbejegyzést hoz létre az automatikus adatbázis-ellenőrzés befejezésekor.
Eseménytípus
explicit
|
|||
|
Kérelem jóváhagyva
|
Az ügyfélkérelmet a sikeres KYC-ellenőrzés és az összes szükséges további vizsgálat után teljes körűen jóváhagyták. Ez az esemény rendszerint a forrásrendszerben történik, miután megérkezik a World-Check „Clear” eredménye. | ||
|
Miért fontos?
Ez jelöli az ügyfél-belépési folyamat sikeres üzleti eredményét. A benyújtástól eddig eltelt idő megmutatja, mennyi idő alatt születik meg az új ügyfél felvételéről szóló döntés.
Hol szerezhető be?
Ez az esemény nem a World-Check rendszerben keletkezik. A végső üzleti döntést meghozó felsőbb szintű CRM- vagy alapalkalmazási rendszerből kell származnia.
Rögzítés
A forrásalkalmazás a végső jóváhagyáskor rögzíti az eseményt.
Eseménytípus
explicit
|
|||
|
Lehetséges egyezés azonosítva
|
Az automatikus átvilágítás egy vagy több lehetséges egyezést talált, amelyet elemzőnek kell manuálisan ellenőriznie. Ezzel az ügy az automatikus feldolgozásból a manuális vizsgálati sorba kerül. | ||
|
Miért fontos?
Ez a tevékenység a folyamat egyik fontos elágazási pontja. A lehetséges egyezést tartalmazó ügyek hosszabb és összetettebb útvonalon haladnak. Ennek követése segíti az erőforrás-tervezést és az ellenőrző csapat szűk keresztmetszeteinek feltárását.
Hol szerezhető be?
A World-Check ügykezelő moduljában az ügy státusza „Review Required”, „Potential Match” vagy hasonló értékre változik.
Rögzítés
Az ügy státuszváltozásából állapítható meg, amely jelzi, hogy manuális ellenőrzésre van szükség.
Eseménytípus
inferred
|
|||
|
Téves pozitív egyezés megerősítve
|
Az elemző megállapítja, hogy a lehetséges egyezés nem az átvilágítás alatt álló ügyfél. Az egyezést elveti, és az adott riasztáshoz tartozó ellenőrzést lezárja. | ||
|
Miért fontos?
Ez az ellenőrzés gyakori kimenetele. A téves pozitív egyezések lezárásához szükséges idő megmutatja az elemzői munka hatékonyságát és az automatikus ellenőrzési logika pontosságát.
Hol szerezhető be?
Az elemző egy adott egyezést „False Positive” vagy „Not a Match” értékkel zár le. Ezt a műveletet általában rögzítik az ügy előzményeiben.
Rögzítés
A rendszer akkor rögzíti, amikor az elemző hivatalosan elvet egy lehetséges egyezést.
Eseménytípus
explicit
|
|||
|
További adatok bekérése
|
Az elemző úgy ítéli meg, hogy a lehetséges egyezés tisztázásához további adatokra van szükség, ezért bekéri azokat az üzleti területtől. Az ügy függőben marad, amíg meg nem érkeznek az adatok. | ||
|
Miért fontos?
Ha ez a tevékenység gyakran fordul elő, az arra utal, hogy az átvilágításhoz kezdetben megadott adatok minősége nem megfelelő. Jelentős késést okoz, mert külső csapatoktól függ, és a hosszú átfutási idő egyik fő oka.
Hol szerezhető be?
Ez lehet az ügy megjegyzéseiben vagy auditnaplójában rögzített felhasználói művelet. Az ügy „Pending Information” vagy „RFI” státuszából is kikövetkeztethető.
Rögzítés
A rendszer akkor rögzíti, amikor az elemző az ügyet további adatigényűként jelöli meg.
Eseménytípus
explicit
|
|||
|
Ügy továbbítása ellenőrzésre
|
Az első szintű elemző egy összetett vagy magas kockázatú ügyet végső döntésre továbbít egy vezető elemzőnek vagy vezetőnek. Ez fontos átadási pont a megfelelési csapaton belül. | ||
|
Miért fontos?
A továbbítások gyakran szűk keresztmetszetet okoznak és növelik az átfutási időt. Gyakoriságuk és okaik elemzése rámutathat a junior elemzők képzési igényeire vagy az ellenőrzési szabályok bizonytalanságaira.
Hol szerezhető be?
Az ügy munkafolyamatában vagy auditnaplójában rögzített műveletként jelenik meg. Az ügyhöz rendelt felhasználó megváltozásából is kikövetkeztethető, különösen akkor, ha magasabb jogosultságú felhasználó veszi át.
Rögzítés
Az ügyben található külön „Escalate” gomb vagy munkafolyamat-művelet használatakor rögzítik.
Eseménytípus
explicit
|
|||
Útmutatók az adatok kinyeréséhez
Kezdheti?
Használja ezt az adatsablont az ügyfelek KYC-átvilágításának process mining elemzéséhez. Az útmutatót követve értékes információkat tárhat fel, és érdemben javíthatja a működést.
Fejlessze most az ügyfelek KYC-átvilágítását, és erősítse a megfelelést
Tegye gördülékenyebbé az ügyfelek befogadását, és csökkentse az átfutási időt mindössze 24 órára.
Nincs szükség bankkártyára. Használja ingyen 14 napig.