KYC Müşteri Edinimi Veri Template'iniz

Refinitiv World-Check
KYC Müşteri Edinimi Veri Template'iniz

KYC Müşteri Edinimi Veri Template'iniz

Bu şablon, KYC Müşteri Kayıt sürecinizi analiz etmek için temel verileri toplama konusunda size rehberlik eder. Yakalanması gereken kritik öznitelikleri, izlenmesi gereken ana faaliyetleri özetler ve bu bilgiyi kaynak sistemlerinizden nasıl çıkaracağınıza dair rehberlik sağlar. Etkili süreç analizi ve iyileştirme için gerekli tüm verilere sahip olduğunuzdan emin olmak için bu kaynağı kullanın.
  • Toplanması Önerilen Nitelikler
  • Takip Edilmesi Gereken Temel Aktiviteler
  • Veri Çekim Rehberliği
Event log'lara yeni mi başlıyorsunuz? Öğrenin Process Mining event log'u nasıl oluşturulur.

KYC Müşteri Kayıt Süreci Öznitelikleri

Bunlar, kapsamlı KYC Müşteri Kayıt analizi için olay günlüğünüze dahil etmeniz önerilen veri alanlarıdır.
3 Gerekli 5 Önerilen 12 İsteğe Bağlı
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
Gerekli Önerilen İsteğe Bağlı

KYC Müşteri Kayıt Süreci Faaliyetleri

Bunlar, doğru süreç keşfi için `event log`'unuza kaydetmeniz gereken temel süreç adımları ve kilometre taşlarıdır.
8 Önerilen 6 İsteğe Bağlı
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
Önerilen İsteğe Bağlı

Veri Çekim Kılavuzları

Verilerinizi Refinitiv World-Check'ten Nasıl Alırsınız?