KYC Müşteri Edinimi Veri Template'iniz
KYC Müşteri Edinimi Veri Template'iniz
- Toplanması Önerilen Nitelikler
- Takip Edilmesi Gereken Temel Aktiviteler
- Veri Çekim Rehberliği
KYC Müşteri Kayıt Süreci Öznitelikleri
| Ad | Açıklama | ||
|---|---|---|---|
|
Faaliyet Adı
ActivityName
|
KYC kayıt süreci içinde meydana gelen belirli bir iş olayı veya görevin adı. | ||
|
Açıklama
Faaliyet Adı, müşteri kayıt yolculuğundaki 'Başvuru Gönderildi', 'Analist İncelemesi Başlatıldı' veya 'Tarama Tamamlandı - Temiz' gibi tek bir adımı veya olayı tanımlar. Bu faaliyetler, uçtan uca iş akışının ayrıntılı bir dökümünü sağlayarak süreç haritasının düğümlerini oluşturur. Faaliyetleri analiz etmek, süreç madenciliğinin temelidir. Farklı faaliyetlerin sırasını ve sıklığını takip ederek analistler, gerçek süreç akışını keşfedebilir, ortak yolları belirleyebilir, standart prosedürden sapmaları tespit edebilir ve gecikmelere veya yeniden işlemlere neden olan belirli adımları belirleyebilir. Bu öznitelik, süreç haritaları oluşturmak ve faaliyet düzeyinde metrikleri hesaplamak için çok önemlidir.
Neden önemli
Bu öznitelik, süreç akışını keşfetmek, görselleştirmek ve darboğazları belirlemek için esansiyel olan sürecin bireysel adımlarını tanımlar.
Nereden alınır
Bu bilgi genellikle olay günlüklerinde veya denetim kaydı tablolarında bulunur, sıklıkla vaka yönetimi varlığındaki durum değişiklikleriyle ilişkilendirilir.
Örnekler
Potansiyel Eşleşme Tespit EdildiAnalist İncelemesi BaşlatıldıYanlış Pozitif OnaylandıBaşvuru Onaylandı
|
|||
|
Müşteri Başvurusu
CustomerApplication
|
Tek bir müşterinin kayıt başvurusu için birincil vaka tanımlayıcısı olarak hizmet veren benzersiz tanımlayıcı. | ||
|
Açıklama
Müşteri Başvurusu, tek bir müşterinin kayıt yolculuğuyla ilgili tüm olayları ve faaliyetleri gruplandıran merkezi vaka tanımlayıcısıdır. Her müşterinin tüm Müşterinizi Tanıyın (KYC) sürecindeki ilerlemesinin, ilk gönderimden nihai karara kadar eksiksiz, kronolojik takibini sağlar. Süreç madenciliği analizinde bu öznitelik, her başvurunun uçtan uca yolculuğunu yeniden yapılandırmak için temeldir. Süreç akışlarının görselleştirilmesini, toplam döngü sürelerinin hesaplanmasını ve varyantların belirlenmesini sağlar. Bu tanımlayıcıya göre gruplandırılmış vakaları analiz ederek, kuruluşlar bir başvurunun izleyebileceği farklı yolları anlayabilir, darboğazları belirleyebilir ve çeşitli kayıt süreçlerinin verimliliğini karşılaştırabilir.
Neden önemli
Bu, tüm ilgili faaliyetleri birbirine bağlayan temel vaka tanımlayıcısıdır ve uçtan uca müşteri kayıt sürecini analiz etmeyi mümkün kılar.
Nereden alınır
Bu tanımlayıcı genellikle Refinitiv World-Check sistemi veya entegre bir CRM içindeki ana başvuru veya vaka yönetimi tablosundaki birincil anahtardır.
Örnekler
APP-2023-00123APP-2023-00124APP-2023-00125
|
|||
|
Olay Zamanı
EventTime
|
Belirli bir faaliyetin veya event'in ne zaman gerçekleştiğini gösteren zaman damgasıdır. | ||
|
Açıklama
Olay Zamanı, bir aktivitenin kaydedildiği kesin tarih ve saati sağlar. Bu zaman damgası, olayların vaka geçmişini yeniden yapılandırmak için doğru bir şekilde sıralanmasına olanak tanıyan sürecin kronolojik omurgasıdır. Bu öznitelik, süreç madenciliğindeki tüm zaman tabanlı analizler için kritik öneme sahiptir. Aktiviteler arasındaki süreleri (döngü süreleri ve bekleme süreleri) hesaplamak, genel vaka süresini ölçmek, zaman içinde süreç performansını analiz etmek ve Hizmet Seviyesi Anlaşmaları (SLA'lar) ile uyumu kontrol etmek için kullanılır. Doğru zaman damgaları olmadan, süreç performansını anlamak ve zamana bağlı darboğazları (bottleneck) belirlemek imkansızdır.
Neden önemli
Her faaliyetin zaman damgası, tüm süre tabanlı metrikleri hesaplamak, süreç sırasını keşfetmek ve darboğaz analizini gerçekleştirmek için esastır.
Nereden alınır
Bu, herhangi bir olay günlüğü veya denetim kaydı tablosunda standart bir alandır, genellikle 'Timestamp', 'EventDate' veya 'CreationDate' olarak adlandırılır.
Örnekler
2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T14:22:15Z
|
|||
|
Bölüm
DepartmentName
|
Faaliyeti gerçekleştirmekten sorumlu departman veya fonksiyonel ekip. | ||
|
Açıklama
Bu öznitelik, kullanıcının ait olduğu 'Kayıt', 'Uyumluluk' veya 'Kalite Güvence' gibi iş birimini veya ekibi belirtir. Bireysel kullanıcıdan daha yüksek bir organizasyonel düzeyde analize olanak tanır. Departmana göre analiz yapmak, departmanlar arası darboğazları belirlemek ve devir sürelerini ölçmek için kritik öneme sahiptir. İşin farklı ekipler arasında nasıl aktığını ve bu geçişlerde gecikmelerin nerede meydana geldiğini görselleştirmeye yardımcı olur. Bu görünüm, çapraz fonksiyonel işbirliğini kolaylaştırmak ve genel süreç verimliliğini artırmak için paha biçilmezdir.
Neden önemli
Süreç performansının departman bazında analizine olanak tanır ve farklı ekipler arasındaki devirlerdeki gecikmeleri belirlemek için esastır.
Nereden alınır
Bu bilgi, sistemdeki kullanıcı profiliyle veya ilişkili bir İK sistemiyle saklanabilir. Kullanıcı ID'si kullanılarak olay verileriyle birleştirilmesi gerekebilir.
Örnekler
Kayıt EkibiUyumluluk İncelemesiÜst Yönetim
|
|||
|
İnceleyici ID'si
ReviewerId
|
Faaliyeti gerçekleştiren kullanıcı, analist veya otomatik aracının tanımlayıcısı. | ||
|
Açıklama
İnceleyici ID'si veya kullanıcı, KYC sürecinde belirli bir görevi kimin yürüttüğünü gösterir. Bu, bir uyumluluk analisti, bir kayıt uzmanı veya otomatik faaliyetler için bir sistem hesabı olabilir. Bu bilgiyi takip etmek, iş yükü dağılımı ve bireysel performans hakkında görünürlük sağlar. Bu öznitelik, kaynak tabanlı analiz için çok önemlidir. Kullanıcılar veya ekipler arasındaki performans farklılıklarını anlamaya, eğitim ihtiyaçlarını belirlemeye ve iş yükü dengelemesini optimize etmeye yardımcı olur. Ayrıca devirleri, sosyal ağları ve uyumluluk kaynak kullanımını analiz etmek için temel bir bileşendir.
Neden önemli
İş yükü dağılımı, kullanıcı performansı ve departmanlar arası devirlerin analizine olanak tanır, bu da kaynak optimizasyonu için kritik öneme sahiptir.
Nereden alınır
Genellikle event log'larında veya denetim izlerinde bulunur, çoğunlukla 'Kullanıcı Kimliği', 'Gerçekleştiren' veya 'Sahip' olarak adlandırılır.
Örnekler
analist_jdoesystem_auto_screenermanager_bsmith
|
|||
|
Olay Bitiş Zamanı
EventEndTime
|
Belirli bir faaliyetin veya olayın ne zaman tamamlandığını gösteren zaman damgası. | ||
|
Açıklama
Olay Bitiş Saati, bir faaliyetin tamamlanmasını işaretler. Birçok olay anlık olarak modellenebilse de (Başlangıç Saati Bitiş Saati'ne eşit olduğunda), bazı faaliyetlerin 'Analist İncelemesi Başlatıldı' ve 'Analist İncelemesi Tamamlandı' gibi ölçülebilir bir süresi vardır. Hem başlangıç hem de bitiş saatlerine sahip olmak, işlem süresinin kesin olarak ölçülmesine olanak tanır. Süreç analizinde, bir bitiş zamanına sahip olmak, bekleme süresini içeren döngü süresinin aksine, bir faaliyetin kesin işlem süresini hesaplamak için hayati öneme sahiptir. Bu, bir vakanın aktif olarak üzerinde çalışıldığı süre ile bir kuyrukta boşta beklediği süre arasındaki farkı ayırt etmeye yardımcı olur. Bu, kaynak optimizasyonu ve verimlilik analizi için anahtardır.
Neden önemli
Daha doğru performans analizi için aktif çalışma süresini boşta bekleme süresinden ayırarak, aktivite işlem süresinin hassas bir şekilde hesaplanmasını sağlar.
Nereden alınır
Süreçli aktiviteler için bu, olay günlüğü veya denetim izi tablolarında 'Tamamlanma Tarihi' veya 'Bitiş Tarihi' gibi ayrı bir alanda saklanabilir.
Örnekler
2023-10-26T10:45:00Z2023-10-26T12:00:00Z2023-10-27T15:00:00Z
|
|||
|
Risk Seviyesi
RiskLevel
|
Düşük, Orta veya Yüksek gibi müşteri başvurusunun hesaplanmış risk sınıflandırması. | ||
|
Açıklama
Risk Seviyesi, KYC süreçlerinde gereken durum tespiti düzeyini belirleyen kritik bir bilgi parçasıdır. Genellikle müşteri türü, coğrafya ve işlerinin doğası gibi faktörlere göre belirlenir. Bu sınıflandırma, bir başvurunun izleyeceği süreç yolunu önemli ölçüde etkileyebilir. Süreç analizinde, vakaları Risk Seviyesine göre segmentlere ayırmak esastır. Döngü süreleri ve süreç akışlarındaki varyasyonları açıklamaya yardımcı olur, örneğin yüksek riskli başvurular daha fazla adım gerektirebilir ve daha uzun sürebilir. Bu öznitelik, riskin sonuçları ve verimliliği nasıl etkilediğini anlamak için 'Başvuru Reddedilme Oranı ve Nedenleri' ve 'Geçmiş Kontrolü Başlatma Döngü Süresi' Dashboard'ları için anahtardır.
Neden önemli
Süreci risk seviyesine göre segmentlere ayırmak, belirli vakaların neden daha uzun sürdüğünü veya farklı yolları izlediğini anlamak ve ret oranlarını analiz etmek için çok önemlidir.
Nereden alınır
Bu, müşteri başvurusu veya vaka kaydındaki temel bir veri noktasıdır. Refinitiv World-Check'teki vaka yönetimi modülüne danışın.
Örnekler
DüşükOrtaYüksek
|
|||
|
SLA Hedef Tarihi
SlaTargetDate
|
Müşteri kayıt sürecinin tamamlanması gereken hedef tarih. | ||
|
Açıklama
SLA Hedef Tarihi, müşteriyle yapılan hizmet seviyesi anlaşması veya şirket içi politikalar tarafından tanımlandığı şekilde, tüm kayıt vakasının tamamlanması için son tarihtir. Bu tarih, gerçek tamamlama sürelerinin ölçüldüğü karşılaştırma ölçütüdür. Bu öznitelik, 'SLA Uyum ve İhlal Analizi' Dashboard'u için temeldir. Bir vakanın zamanında tamamlanıp tamamlanmadığını hesaplamak için kullanılır. SLA ihlallerini analiz etmek, gecikmelere neden olan süreçteki sistemik sorunları belirlemeye yardımcı olur ve kuruluşun zamanında iyileştirme yapmak ve uyumluluk gereksinimlerini karşılamak için düzeltici önlemler almasını sağlar.
Neden önemli
Bu, zamanında performansı ölçmek için bir ölçüttür ve SLA uyum oranını hesaplamak ve ihlalleri analiz etmek için kritik öneme sahiptir.
Nereden alınır
Bu tarih genellikle başvuru gönderim tarihi ve iş kurallarına göre hesaplanır. Vaka kaydında bir alan olarak saklanabilir.
Örnekler
2023-11-10T17:00:00Z2023-11-15T17:00:00Z2023-11-20T17:00:00Z
|
|||
|
Başvuru Kanalı
ApplicationChannel
|
Müşteri başvurusunun çevrimiçi portal, şube içi veya mobil uygulama gibi gönderildiği kanal. | ||
|
Açıklama
Başvuru Kanalı, müşteri başvurusunun gönderim kaynağını belirtir. Farklı kanalların farklı veri eksiksizliği, kalitesi ve müşteri demografisi seviyeleri olabilir, bu da sonraki süreci etkileyebilir. Bu öznitelik, 'Kanala Göre Başvuru Hacmi' Dashboard'u için hayati öneme sahiptir. Farklı kanallardan gelen başvuruların hacmini, döngü süresini ve sonuçlarını analiz ederek, bir kuruluş hangi kanalların en verimli olduğunu ve hangilerinin süreç iyileştirmeleri gerektirebileceğini belirleyebilir. Bu analiz, kaynak tahsisi ve kanal yatırımına ilişkin stratejik kararları destekler.
Neden önemli
Farklı başvuru kanallarının performansını ve verimliliğini analiz etmeye yardımcı olur, teknoloji ve müşteri deneyimi hakkında stratejik kararlar alınmasını sağlar.
Nereden alınır
Bu bilgi genellikle sürecin başında yakalanır ve başvuru kaydında bir öznitelik olarak saklanır.
Örnekler
Online PortalMobil UygulamaŞube İçiİlişki Yöneticisi
|
|||
|
Eşleşme ID'si
MatchId
|
World-Check taraması sırasında bulunan potansiyel bir eşleşme için benzersiz tanımlayıcı. | ||
|
Açıklama
Otomatik tarama süreci yaptırım listeleri, PEP listeleri veya olumsuz medya kayıtlarında potansiyel bir eşleşme bulduğunda, belirli bulguyu izlemek için genellikle bir Eşleşme Kimliği oluşturulur. Bu kimlik, başvuru vakasını uyarıyı tetikleyen World-Check veri tabanındaki belirli kayda bağlar. Bu öznitelik, ayrıntılı uyumluluk analizi için faydalıdır. Analistlerin eşleşmelerin doğasını araştırmasına, belirli uyarıların çözümünü takip etmesine (örneğin, yanlış pozitif veya gerçek bir eşleşmeyi doğrulaması) ve hangi tür uyarıların en yaygın olduğunu veya çözülmesinin en uzun sürdüğünü anlamasına olanak tanır. 'Potansiyel Eşleşme Tespit Edildi' etkinliğine daha derin bir detay seviyesi sağlar.
Neden önemli
Belirli tarama sonuçlarına ayrıntılı bir bağlantı sağlar, eşleşme çözüm sürelerinin ve uyarı türlerinin daha derinlemesine analizine olanak tanır.
Nereden alınır
Bu ID, World-Check tarama motoru tarafından oluşturulur ve potansiyel bir eşleşme bulunduğunda başvuru vakasına kaydedilir.
Örnekler
WC-MATCH-459021WC-MATCH-459022WC-MATCH-459023
|
|||
|
Faaliyet İşlem Süresi
ActivityProcessingTime
|
Bir faaliyet üzerinde aktif olarak çalışılan süre. | ||
|
Açıklama
Bu metrik, bir faaliyetin başlangıcından bitişine kadar tamamlanması için geçen gerçek süreyi hesaplar. EventEndTime ve EventTime arasındaki fark olarak hesaplanır. Bu, bir görev için 'dokunma süresini' veya aktif çalışma süresini ölçer. Bu hesaplanmış öznitelik, performans analizi için esastır ve 'Ort. Belge İnceleme Döngü Süresi' ve 'Ort. Uyumluluk İnceleme Döngü Süresi' dahil birçok KPI'da kullanılır. Bir görevin aktif olarak işlendiği süre ile bir kuyrukta beklediği süre arasındaki farkı ayırt etmeye yardımcı olur. Bu, gerçek işlem verimsizliklerini belirlemek ve kapasite planlaması yapmak için temeldir.
Neden önemli
Bir faaliyet için aktif çalışma süresini ölçer, hangi belirli görevlerin bekleme süresinden ayrı olarak tamamlanması için en çok zaman aldığını belirlemeye yardımcı olur.
Nereden alınır
Bu, veri dönüşümü sırasında bir faaliyetin bitiş zaman damgasından başlangıç zaman damgasını çıkararak (örneğin, Bitiş Saati - Başlangıç Saati) hesaplanır.
Örnekler
1S30DP2G4S15DPT25M
|
|||
|
Kaynak Sistem
SourceSystem
|
Olay verilerinin çıkarıldığı sistem, bu durumda Refinitiv World-Check. | ||
|
Açıklama
Bu öznitelik, süreç verilerinin kaynağını tanımlar. Tek kaynaklı bir çıkarmada sabit bir değer olabilse de, bütünsel bir süreç görünümü oluşturmak için birden çok sistemden (bir CRM ve World-Check gibi) gelen veriler birleştirildiğinde kritik hale gelir. Analizde bu, veri yönetişiminde, sorun gidermede ve verinin bağlamını anlamada yardımcı olur. Örneğin, temel bir tarama sisteminde kaydedilen faaliyetler, çevresel bir sistemden gelenlere göre farklı özelliklere veya detay seviyelerine sahip olabilir. Veri soy ağacının net ve denetlenebilir olmasını sağlar.
Neden önemli
Verinin kaynağını belirler; bu, veri yönetişimi, doğrulama ve birden çok kaynaktan gelen verileri birleştirirken çok önemlidir.
Nereden alınır
Bu, genellikle veri çıkarma, dönüştürme ve yükleme (ETL) süreci sırasında veri kümesini etiketlemek için eklenen statik bir değerdir.
Örnekler
Refinitiv World-CheckWorldCheckOne
|
|||
|
Müşteri Kimliği
CustomerId
|
Müşteri kabul sürecindeki müşteri varlığı için benzersiz bir tanımlayıcı. | ||
|
Açıklama
Müşteri ID'si, müşteri profili için benzersiz tanımlayıcıdır. Bu, Müşteri Başvuru ID'sinden farklıdır, çünkü bir müşteri zamanla birden fazla başvuru gönderebilir. Bu öznitelik, kayıt sürecini ana müşteri kaydına bağlar. Analizde, Müşteri ID'si aynı müşteriden tekrarlanan başvuruların izlenmesine olanak tanır ve süreç verilerini bir CRM veya ana veri sisteminden diğer müşteri öznitelikleriyle zenginleştirmek için kullanılabilir. Bu, tek bir kayıt örneğinin ötesinde müşteri yolculuğunun daha bütünsel bir görünümünü sağlar.
Neden önemli
Kayıt vakasını belirli bir müşteriye bağlar, tekrarlayan başvuruların analizini ve ana müşteri verileriyle zenginleştirilmesini sağlar.
Nereden alınır
Bu, başvuru veya vaka kaydında, müşteri ana verilerine bağlayan önemli bir alan olacaktır.
Örnekler
CUST-98765CUST-98766CUST-98767
|
|||
|
Müşteri Türü
CustomerType
|
Bireysel, Kurumsal veya Güven gibi müşterinin sınıflandırması. | ||
|
Açıklama
Müşteri Tipi, kabul edilen varlığı kategorize eder. Farklı müşteri türleri genellikle farklı kabul gereksinimlerine, risk profillerine ve düzenleyici yükümlülüklere sahiptir. Örneğin, bir şirketi kabul etmek, bir bireyi kabul etmekten genellikle daha karmaşıktır. Bu öznitelik, özellikle 'KYC Müşteri Tipi Performansı' dashboard'u için segmentasyon analizinde kullanılır. Farklı müşteri segmentleri arasında süreç verimliliği, döngü süreleri ve ret oranlarının karşılaştırılmasına olanak tanır. Bu, kuruluşların belirli müşteri tipleri için kabul deneyimini özelleştirmesine ve optimize etmesine yardımcı olur.
Neden önemli
Farklı müşteri segmentleri arasında performans karşılaştırması yapılmasına olanak tanır, bu da her tür için kabul sürecini özelleştirmeye ve optimize etmeye yardımcı olur.
Nereden alınır
Bu, kaynak sistemdeki müşteri veya başvuru kaydında saklanan temel bir özniteliktir.
Örnekler
BireyselKurumsalKâr Amacı GütmeyenGüven
|
|||
|
Müşteri Ülkesi
CustomerCountry
|
Müşterinin ikamet veya kuruluş ülkesi. | ||
|
Açıklama
Bu öznitelik, müşterinin coğrafi konumunu gösterir. Ülke, KYC süreçleri için risk değerlendirmesi ve düzenleyici gereksinimlerde önemli bir faktördür. Farklı yargı alanlarının farklı kuralları vardır, bu da süreç akışını ve süresini etkileyebilir. Süreci ülkeye göre analiz etmek, kuruluşların farklı bölgelerdeki performansı karşılaştırmasına, konuma özgü darboğazları belirlemesine ve yerel düzenlemelere uyumu sağlamasına olanak tanır. Süreç analizine coğrafi bir boyut sağlar, bu da önemli operasyonel farklılıkları ortaya çıkarabilir.
Neden önemli
Sürecin coğrafi analizine olanak tanır, performans, risk ve uyumluluk gereksinimlerindeki bölgesel farklılıkların belirlenmesine yardımcı olur.
Nereden alınır
Bu, müşteri profili veya başvuru formunda standart bir alandır.
Örnekler
USAGBRSGPDEU
|
|||
|
Otomatikleştirildi mi?
IsAutomated
|
Aktivitenin bir sistem (doğru) veya insan (yanlış) tarafından gerçekleştirilip gerçekleştirilmediğini gösteren bir bayrak. | ||
|
Açıklama
Bu boolean öznitelik, otomatik sistem görevleri ile kullanıcılar tarafından gerçekleştirilen manuel faaliyetler arasında ayrım yapar. Örneğin, 'Otomatik Tarama Gerçekleştirildi' otomatik olarak işaretlenirken, 'Analist İncelemesi Başlatıldı' manuel olacaktır. Bu ayrım, otomasyon analizi için çok önemlidir. Otomasyonun süreç verimliliği üzerindeki etkisini ölçmeye, hangi manuel görevlerin gelecekteki otomasyon için aday olduğunu belirlemeye ve insan ile sistem aktörleri arasındaki etkileşimi anlamaya yardımcı olur. Sistem işlem süresini manuel işlem süresinden net bir şekilde ayırmayı sağlar.
Neden önemli
Sistem ve insan faaliyetleri arasında ayrım yapar; bu, otomasyonun etkisini ölçmek ve yeni otomasyon fırsatlarını belirlemek için kilit öneme sahiptir.
Nereden alınır
Bu, genellikle faaliyet adına veya olayla ilişkili kullanıcı ID'sine (örneğin, kullanıcı bir 'sistem' hesabıysa) göre türetilir.
Örnekler
truefalse
|
|||
|
Ret Nedeni
RejectionReason
|
Müşteri başvurusu reddedildiğinde belirtilen özel neden. | ||
|
Açıklama
Bir başvuru reddedildiğinde, Reddetme Nedeni bu kararın neden alındığını açıklar. Nedenler arasında 'Yaptırım Eşleşmesi', 'Eksik Belgeler' veya 'Yüksek Risk Profili' bulunabilir. Bu, gelen başvuruların kalitesi ve tarama sürecinin etkinliği hakkında değerli, yapılandırılmış geri bildirim sağlar. Bu öznitelik, 'Başvuru Reddetme Oranı ve Nedenleri' dashboard'unun temel itici gücüdür. Bu nedenlerin analizi, retlerin temel nedenlerini belirlemeye yardımcı olur; bu da süreç iyileştirmelerine, başvuru sahipleriyle daha net iletişime ve potansiyel olarak gereksiz retlerin azaltılmasına yol açabilir. Nicel ret oranı KPI'ına nitel bir bağlam sağlar.
Neden önemli
Başvuru reddedilmesinin temel nedenini sağlar; bu, reddedilme oranını azaltmak için kayıt sürecinde iyileştirilmesi gereken alanları belirlemek için esastır.
Nereden alınır
'Başvuru Reddedildi' olayı meydana geldiğinde, muhtemelen vaka veya başvuru kaydında bir alan olarak kaydedilecektir.
Örnekler
PEP EşleşmesiYaptırım Listesi EşleşmesiBelge Doğrulaması Başarısız OlduOlumsuz Medya
|
|||
|
SLA İhlal Edildi
SlaBreached
|
Müşteri kabul vakasının, Hizmet Seviyesi Anlaşması (SLA) Hedef Tarihinden sonra tamamlanıp tamamlanmadığını gösteren bir boolean bayrak. | ||
|
Açıklama
Bu öznitelik, bir vakanın Hizmet Seviyesi Anlaşmasını ihlal edip etmediğini gösteren hesaplanmış bir işarettir. Son tamamlama faaliyetinin (örneğin, 'Başvuru Onaylandı' veya 'Başvuru Reddedildi') zaman damgasının vakanın 'SlaTargetDate' ile karşılaştırılmasıyla belirlenir. Bu işaret, 'SLA Uyum ve İhlal Analizi' Dashboard'u ve 'SLA Uyum Oranı' KPI'ının temelini oluşturur. Kullanıcıların ihlal edilen tüm vakaları hızlı bir şekilde filtrelemesine olanak tanıyarak analizi basitleştirir. İhlal edilen vakaların süreç özelliklerini analiz ederek, kuruluşlar gecikmelerin temel nedenlerini belirleyebilir ve iyileştirme çabalarını etkili bir şekilde odaklayabilir.
Neden önemli
Hizmet seviyesi anlaşmalarına uyumu doğrudan ölçer, bu da geciken vakaların kolayca filtrelenmesini ve kök neden analizini sağlar.
Nereden alınır
Bu, veri dönüşümü sırasında bir vaka için son faaliyet zaman damgasını SlaTargetDate alanı ile karşılaştırarak hesaplanır.
Örnekler
truefalse
|
|||
|
Son Veri Güncellemesi
LastDataUpdate
|
Bu olaya ait verilerin kaynak sistemden en son ne zaman yenilendiği veya çıkarıldığına dair zaman damgası. | ||
|
Açıklama
Bu öznitelik, verilerin güncelliğini gösterir. Refinitiv World-Check'ten en son veri çekiminin tarihini ve saatini kaydeder. Bu, süreç madenciliği Dashboard'larının ve analizlerinin zamanında olup olmadığını anlamak için önemlidir. Analitik amaçlar için bu, kullanıcıların neredeyse gerçek zamanlı verilere mi yoksa belirli bir zaman noktasından alınmış bir anlık görüntüye mi baktıklarını bilmelerini sağlar. Veri yönetişimi ve sağlanan içgörülerin güncelliği hakkındaki kullanıcı beklentilerini yönetmek için esastır.
Neden önemli
Veri güncelliği hakkında kritik bağlam sağlar, kullanıcıların süreç analizinin ne kadar güncel olduğunu anlamalarını garanti eder.
Nereden alınır
Bu zaman damgası, veri çıkarma (ETL) süreci sırasında oluşturulur ve eklenir.
Örnekler
2023-11-01T02:00:00Z2023-11-02T02:00:00Z
|
|||
|
Yeniden İşleme mi?
IsRework
|
Bir aktivitenin aynı vaka içinde ikinci veya sonraki bir kez gerçekleştirilip gerçekleştirilmediğini gösteren bir bayrak. | ||
|
Açıklama
IsRework, aynı müşteri başvuru vakası içinde bir faaliyetin tekrarlandığını belirten hesaplanmış bir boolean özniteliğidir. Örneğin, 'Risk Değerlendirmesi Yapıldı' tek bir başvuru için birden fazla kez gerçekleşirse, sonraki tekrarlar yeniden işleme olarak işaretlenir. Bu öznitelik, süreç verimsizliklerini, döngüleri ve gereksiz tekrarları belirlemek için kritik öneme sahiptir. 'Risk Değerlendirme Yeniden İşleme ve Verimlilik' Dashboard'unu ve 'Risk Değerlendirme Yeniden İşleme Oranı' KPI'ını doğrudan destekler. Yeniden işleme analizi, kalite, bilgi netliği veya karar verme ile ilgili sorunları ortaya çıkarmaya yardımcı olur; bu da boşa harcanan çabaya ve daha uzun döngü sürelerine yol açar.
Neden önemli
Tekrarlanan faaliyetleri işaretleyerek süreçteki verimsizlikleri vurgular, kaliteyi artırmak ve döngü sürelerini azaltmak için yeniden işleme döngülerinin analizine olanak tanır.
Nereden alınır
Bu, veri dönüşümü sırasında her vakadaki faaliyetlerin sırasını analiz ederek ve bir faaliyetin ilk olmayan herhangi bir tekrarını işaretleyerek hesaplanır.
Örnekler
truefalse
|
|||
KYC Müşteri Kayıt Süreci Faaliyetleri
| Aktivite | Açıklama | ||
|---|---|---|---|
|
Analist İncelemesi Başlatıldı
|
Bir uyumluluk analisti, bir müşteri başvurusu için potansiyel eşleşmelerin manuel incelemesine başlar. Bu, potansiyel eşleşmelerin detaylarını müşterinin bilgileriyle karşılaştırarak uygunluğunu değerlendirmeyi içerir. | ||
|
Neden önemli
Bu, yaygın bir darboğaz olan manuel uyumluluk incelemesinin başlangıcını işaretler. 'Potansiyel Eşleşme Tespit Edildi'den bu faaliyete kadar geçen sürenin ölçülmesi, kuyruk gecikmelerini ortaya koyarken, incelemenin süresi analist verimliliğini gösterir.
Nereden alınır
Bu, bir analistin inceleme kuyruğundan bir vakayı 'talep ettiğinde' veya açtığında çıkarılabilir. Sistem, vaka durumu 'İncelemede' olarak değiştiğinde veya belirli bir kullanıcıya atandığında bu olayı açıkça bir denetim kaydına kaydedebilir.
Yakala
Bir vaka durumunun 'İnceleme Altında' olarak değişmesinden veya vakanın bir analiste atanmasından çıkarılır.
Event tipi
inferred
|
|||
|
Başvuru Gönderildi
|
Bu faaliyet, bir müşteri başvurusunu gönderdiğinde KYC kayıt sürecinin başlangıcını işaretler. Bu olay genellikle bir CRM'de veya temel bir uygulama sisteminde yakalanır ve daha sonra Refinitiv World-Check'te tarama sürecini tetikler. | ||
|
Neden önemli
Bu, uçtan uca müşteri kayıt yolculuğunun birincil başlangıç olayıdır. Bu noktadan tamamlanmaya kadar geçen süreyi analiz etmek, müşteri deneyimini ve SLA uyumunu ölçmek için kritik olan genel kayıt döngü süresini sağlar.
Nereden alınır
Bu olay World-Check'e özgü değildir. Bir CRM veya müşteri hesap yönetimi platformu gibi bir üst sistemden alınmalı ve Müşteri Başvuru ID'si ile ilişkilendirilmelidir.
Yakala
İlk başvuru üzerine kaynak başvuru sistemine kaydedilen olay.
Event tipi
explicit
|
|||
|
Başvuru Reddedildi
|
Müşteri başvurusu, genellikle World-Check'te 'Eşleşme Bulundu' veya diğer risk faktörlerinin bir sonucu olarak resmi olarak reddedilir. Bu olay, kayıt sürecinin son olumsuz sonucudur. | ||
|
Neden önemli
Bu, sürecin birincil hata bitiş noktasıdır. Reddetme olaylarını, özellikle nedenlerini ve önceki faaliyetleri analiz etmek, süreç iyileştirme ve gereksiz reddedilmeleri azaltma için çok önemlidir.
Nereden alınır
Bu nihai iş kararı, World-Check'in kendisinde değil, üst düzey CRM veya temel uygulama sisteminde kaydedilir. Veriler o sistemden alınmalıdır.
Yakala
Kaynak başvuru sistemine kaydedilen, genellikle ilgili bir ret nedeni kodu içeren olay.
Event tipi
explicit
|
|||
|
Gerçek Eşleşme Onaylandı
|
Bir analist, potansiyel bir eşleşmenin gerçekten taranan müşteri olduğunu doğrular ve potansiyel bir risk tanımlar. Bu, genellikle ek durum tespiti veya başvuru reddini tetikleyen kritik bir kilometre taşıdır. | ||
|
Neden önemli
Bu, anahtar bir risk azaltma sonucudur ve süreçte önemli bir andır. Müşteri başvurusu hakkındaki nihai kararı doğrudan etkiler ve uyumluluk raporlaması ve analizi için kritik öneme sahiptir.
Nereden alınır
Bu, analistin belirli bir eşleşmeyi 'Gerçek Eşleşme' veya 'Onaylanmış Eşleşme' olarak değerlendirdiği açık bir kullanıcı eylemidir. Bu olay vaka denetim kaydına kaydedilir.
Yakala
Bir analist sistemde bir eşleşmeyi resmi olarak onayladığında kaydedilir.
Event tipi
explicit
|
|||
|
Hesap Etkinleştirildi
|
Müşterinin hesabı çekirdek sistemde oluşturulur ve etkinleştirilir, kayıt yolculuğu tamamlanır. Bu, nihai başvuru onayını takip eder ve hesabı kullanıma hazır hale getirir. | ||
|
Neden önemli
Bu, süreçteki son, değer sunan adımdır. Başvuru gönderiminden hesap aktivasyonuna kadar geçen süre, operasyonel verimlilik ve müşteri memnuniyeti için temel bir metriktir.
Nereden alınır
Bu olay World-Check'te yakalanmaz. Çekirdek bankacılık veya müşteri hesap sisteminde kaydedilir ve Müşteri Başvuru ID'si ile ilişkilendirilmelidir.
Yakala
Hesap etkinleştirildiğinde ana hesap sistemine kaydedilen olay.
Event tipi
explicit
|
|||
|
Tarama Talebi Oluşturuldu
|
Refinitiv World-Check sistemi içinde bir müşteri başvurusu için resmi olarak yeni bir tarama vakası oluşturulur. Bu, bir yukarı akış sisteminden gelen bir API çağrısı veya manuel giriş ile tetiklenir ve risk istihbarat kontrolünün başlangıcını temsil eder. | ||
|
Neden önemli
Bu, tarama alt sürecinin resmi başlangıcını işaretler. Başvuru Gönderildi ile bu faaliyet arasındaki süre, iş kolu sistemi ile uyumluluk işlevi arasındaki devirlerdeki gecikmeleri ortaya koyar.
Nereden alınır
World-Check vaka yönetimi günlüklerine veya denetim kaydına kaydedilir. Belirli vaka veya varlık ID'si için oluşturma olayı ve zaman damgası kullanılır.
Yakala
Sistemde yeni bir tarama vakası oluşturulduğunda otomatik olarak kaydedilir.
Event tipi
explicit
|
|||
|
Tarama Tamamlandı - Eşleşme Bulundu
|
Tarama vakası, 'Eşleşme Bulundu' sonucuyla resmi olarak kapatılır, bu da onaylanmış bir riskin tespit edildiğini gösterir. Bu karar, gelişmiş durum tespiti veya reddetme gibi farklı bir sonraki süreci tetikler. | ||
|
Neden önemli
Bu, tarama süreci için birincil 'mutsuz yol' bitiş noktasıdır. Bu vakaları analiz etmek, risk profillerini ve tarama kontrollerinin etkinliğini anlamaya yardımcı olur.
Nereden alınır
Son vaka durumunun 'Eşleşme Bulundu', 'Risk Tespit Edildi' veya 'Kapalı - Pozitif' olarak değişmesinden çıkarılır. Bu son durum değişikliğinin zaman damgası kullanılır.
Yakala
Doğrulanmış bir eşleşmeyi gösteren nihai vaka durumunun zaman damgasından türetilmiştir.
Event tipi
inferred
|
|||
|
Tarama Tamamlandı - Temiz
|
Tarama vakası, 'Temiz' sonucuyla resmi olarak kapatılır, yani gerçek eşleşme bulunamadı. Bu karar, kayıt sürecinin devam etmesine izin vererek kaynak sisteme geri iletilir. | ||
|
Neden önemli
Bu faaliyet, tarama sürecinin başarılı, 'mutlu yol' tamamlanmasını temsil eder. Standart, düşük riskli başvuruların döngü süresini ölçmek için anahtar bir bitiş noktası görevi görür.
Nereden alınır
Son vaka durumunun 'Temiz', 'Tamamlandı' veya 'Kapalı - Eşleşme Yok' olarak değişmesinden çıkarılır. Bu son durum değişikliğinin zaman damgası kullanılır.
Yakala
Net bir sonuç gösteren nihai vaka durumunun zaman damgasından türetilmiştir.
Event tipi
inferred
|
|||
|
Başvuru Onaylandı
|
Müşteri başvurusu, başarılı bir KYC taraması ve diğer gerekli kontrollerin ardından tamamen onaylandı. Bu olay tipik olarak World-Check'ten 'Temiz' sonucu alındıktan sonra kaynak sistemde gerçekleşir. | ||
|
Neden önemli
Bu, kayıt sürecinin başarılı iş sonucunu işaretler. Başvuru gönderiminden bu noktaya kadar geçen süreyi takip etmek, yeni bir müşteri için tam 'evet' süresini ortaya koyar.
Nereden alınır
Bu olay World-Check'e özgü değildir. Nihai iş kararını veren üst düzey CRM veya temel uygulama sisteminden alınmalıdır.
Yakala
Nihai onay üzerine kaynak başvuru sistemine kaydedilen olay.
Event tipi
explicit
|
|||
|
Ek Bilgi Talep Edildi
|
Analist, potansiyel eşleşmeyi çözmek için daha fazla bilgiye ihtiyaç duyulduğunu belirler ve bunu iş biriminden talep eder. Bu, bilgi sağlanana kadar vakayı bekleyen duruma getirir. | ||
|
Neden önemli
Bu aktivitenin sık sık meydana gelmesi, tarama için sağlanan başlangıç verilerinin kalitesiyle ilgili sorunlara işaret eder. Bu aktivite, harici ekiplere bağlı olduğu için önemli gecikmelere neden olur ve uzun döngü sürelerinin temel itici gücüdür.
Nereden alınır
Bu, vaka notlarına veya denetim günlüğüne kaydedilmiş açık bir kullanıcı eylemi olabilir. Alternatif olarak, bir vaka durumunun 'Bekleyen Bilgi' veya 'RFI' olarak değişmesinden çıkarılabilir.
Yakala
Bir analist, vakanın daha fazla bilgiye ihtiyacı olduğunu belirtmek için bir özellik kullandığında kaydedilir.
Event tipi
explicit
|
|||
|
Otomatik Tarama Yapıldı
|
World-Check sistemi, müşterinin detaylarını risk istihbarat veri tabanına karşı otomatik olarak tarar. Bu, potansiyel eşleşmeler veya temiz bir durum gibi ilk sonuç setini üreten sistem odaklı bir faaliyettir. | ||
|
Neden önemli
Bu faaliyet, tarama süreci içindeki ilk değer katan adımdır. Bu noktadan önceki gecikmeler sistem veya veri hazırlık sorunlarını gösterirken, sonuç sonraki manuel iş yükünü belirler.
Nereden alınır
Bu olay, vaka denetim kaydında açıkça kaydedilebilir veya vaka için ilk tarama sonuçlarının kullanılabilir hale geldiği zaman damgasından çıkarılabilir.
Yakala
Otomatik veritabanı taramasının tamamlanması üzerine oluşturulan sistem günlük girişi.
Event tipi
explicit
|
|||
|
Potansiyel Eşleşme Tespit Edildi
|
Otomatik tarama süreci, bir analist tarafından manuel inceleme gerektiren bir veya daha fazla potansiyel eşleşme buldu. Bu olay, vakayı otomatik durumdan manuel bir inceleme kuyruğuna geçirir. | ||
|
Neden önemli
Bu faaliyet, süreçte kritik bir dallanma noktasıdır. Potansiyel eşleşmelere sahip vakalar daha uzun, daha karmaşık bir yolu izler ve bunu takip etmek, inceleme ekibi için kaynak planlamasına ve darboğaz analizine yardımcı olur.
Nereden alınır
Vaka durumunun World-Check vaka yönetimi modülü içinde 'İnceleme Gerekli', 'Potansiyel Eşleşme' veya benzer bir duruma değişmesinden çıkarılır.
Yakala
Manuel incelemenin artık gerekli olduğunu gösteren bir vaka durumu değişikliğinden türetilmiştir.
Event tipi
inferred
|
|||
|
Vaka İnceleme İçin Yönlendirildi
|
Birinci seviye bir analist, karmaşık veya yüksek riskli bir vakayı nihai karar için kıdemli bir analiste veya yöneticiye yönlendirir. Bu, uyumluluk ekibi içindeki önemli bir devir noktasıdır. | ||
|
Neden önemli
Yönlendirmeler genellikle darboğazlar (bottleneck) oluşturur ve döngü süresini artırır. Yönlendirmelerin sıklığını ve nedenlerini analiz etmek, genç analistler için eğitim ihtiyaçlarını veya inceleme politikalarındaki belirsizliği vurgulayabilir.
Nereden alınır
Vaka iş akışında veya denetim kaydında açık bir eylem olarak kaydedilir. Bu, özellikle daha yüksek izinlere sahip bir kullanıcıya atanmışsa, vakaya atanmış kullanıcının değişmesinden de çıkarılabilir.
Yakala
Vaka içinde özel bir 'Yükselt' düğmesi veya iş akışı eylemi aracılığıyla kaydedilir.
Event tipi
explicit
|
|||
|
Yanlış Pozitif Onaylandı
|
Analist, potansiyel bir eşleşmenin taranan müşteriyle aynı olmadığı sonucuna varır. Eşleşme reddedilir ve o belirli uyarı için tarama süreci çözülür. | ||
|
Neden önemli
Bu, inceleme sürecinin yaygın bir sonucunu temsil eder. Yanlış pozitifleri değerlendirmek için geçen süreyi anlamak, analist verimliliğini ve otomatik tarama mantığının doğruluğunu ölçmeye yardımcı olur.
Nereden alınır
Bu, analistin belirli bir eşleşmeyi 'Yanlış Pozitif' veya 'Eşleşme Değil' olarak değerlendirdiği açık bir kullanıcı eylemidir. Bu eylem tipik olarak vaka geçmişine kaydedilir.
Yakala
Bir analist sistemdeki potansiyel bir eşleşmeyi resmi olarak reddettiğinde kaydedilir.
Event tipi
explicit
|
|||