KYC Müşteri Kimlik Doğrulama Veri Template'inuz

Refinitiv World-Check
KYC Müşteri Kimlik Doğrulama Veri Template'inuz

KYC Müşteri Kimlik Doğrulama Veri Template'inuz

Bu şablon, KYC Müşteri Kayıt sürecinizi analiz etmek için temel verileri toplama konusunda size rehberlik. eder. Yakalanması gereken kritik nitelikleri, izlenmesi gereken ana faaliyetleri özetler ve bu bilgiyi kaynak sistemlerinizden nasıl çıkaracağınıza dair rehberlik. sunar. Etkili süreç analizi ve iyileştirme için gerekli tüm verilere sahip olduğunuzdan emin olmak için bu kaynağı kullanın.
  • Önerilen Öznitelikler
  • İzlenecek Temel Etkinlikler
  • Veri Çekim Kılavuzu
Olay günlüklerine (Event Log) yeni mi başlıyorsunuz? Öğrenin Process Mining event log nasıl oluşturulur.

KYC Müşteri Edinimi Öznitelikleri

Bunlar, detaylı KYC Müşteri Kayıt analizi için event lognüze dahil etmeniz önerilen veri alanlarıdır.
3 Gerekli 5 Önerilen 11 Opsiyonel
Ad Açıklama
Aktivite Adı
ActivityName
KYC kayıt süreci içinde meydana gelen belirli bir iş olayı veya görevin adı.
Açıklama

Aktivite 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 büyük önem taşır.

Neden Önemli?dir?

Bu öznitelik, süreç akışını keşfetmek, görselleştirmek ve darboğazları belirlemek için temel 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 (case) 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 (case) 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 sunar.

Process Mining analizinde bu öznitelik, her başvurunun tüm sürecini yeniden yapılandırmak için büyük önem taşır. Süreç akışlarının görselleştirilmesini, toplam döngü sürelerinin hesaplanmasını ve varyantların belirlenmesini sunar. 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?dir?

Bu, tüm ilgili faaliyetleri birbirine bağlayan temel vaka (case) tanımlayıcısıdır ve uçtan uca müşteri kayıt sürecini analiz etmeyi sunar.

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 temel rol oynar.

Örnekler:::::::
APP-2023-00123APP-2023-00124APP-2023-00125
Olay Zamanı
EventTime
Belirli bir faaliyetin veya olayın ne zaman gerçekleştiğini gösteren zaman damgası (zaman damgası)dır.
Açıklama

Olay Zamanı, bir aktivitenin kaydedildiği tam tarih ve saati sunar. Bu zaman damgası (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 büyük önem taşır. 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ı belirlemek imkansızdır.

Neden Önemli?dir?

Her faaliyetin zaman damgası (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 gereklidir.

Nereden Alınır??

Bu, herhangi bir event log veya denetim kaydı tablosunda standart bir alandır, genellikle 'zaman damgası (zaman damgası)', '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 sunar.

Departmana göre analiz yapmak, departmanlar arası darboğazları belirlemek ve devir sürelerini ölçmek için büyük önem taşır. İş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 büyük önem taşır.

Neden Önemli?dir?

Süreç performansının departman bazında analizine sunar ve farklı ekipler arasındaki devirlerdeki gecikmeleri belirlemek için gereklidir.

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:::::::
Edinim 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 sunar.

Bu öznitelik, kaynak tabanlı analiz için büyük önem taşır. 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?dir?

İş yükü dağılımı, kullanıcı performansı ve departmanlar arası devirlerin analizine sunar, bu da kaynak optimizasyonu için büyük önem taşır.

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ı (zaman damgası)dır.
Açıklama

Olay Bitiş Zamanı, bir faaliyetin tamamlanmasını işaretler. Birçok olay anlık olarak modellenebilse de (Başlangıç Saati Bitiş Zamanı'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 sunar.

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 büyük önem taşır. 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 temel rol oynar.

Neden Önemli?dir?

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ı sunar.

Nereden Alınır??

Süreçli aktiviteler için bu, event log 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 hesaplanan risk sınıflandırması.
Açıklama

Risk Seviyesi, KYC süreçlerinde gereken durum tespiti düzeyini belirleyen kritik bir bilgidir. 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 gereklidir. 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 temel rol oynar.

Neden Önemli?dir?

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 büyük önem taşır.

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 büyük önem taşır. 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ı sunar.

Neden Önemli?dir?

Bu, zamanında performansı ölçmek için bir ölçüttür ve SLA uyum oranını belirlemeye yardımcı olur.saplamak ve ihlalleri analiz etmek için büyük önem taşır.

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 büyük önem taşır. 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?dir?

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ı sunar.

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 sunar. 'Potansiyel Eşleşme Tespit Edildi' etkinliğine daha derin bir detay seviyesi sunar.

Neden Önemli?dir?

Belirli tarama sonuçlarına ayrıntılı bir bağlantı sunar, eşleşme çözüm sürelerinin ve uyarı türlerinin daha ayrıntılı analizine sunar.

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
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, uçtan uca 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ı sunar.

Neden Önemli?dir?

Verinin kaynağını belirler; bu, veri yönetişimi, doğrulama ve birden çok kaynaktan gelen verileri birleştirirken büyük önem taşır.

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 sunar ve süreç verilerini bir CRM veya ana veri sisteminden diğer müşteri nitelikleriyle zenginleştirmek için kullanılabilir. Bu, tek bir kayıt örneğinin ötesinde müşteri yolculuğunun daha uçtan uca görmenizi sunar.

Neden Önemli?dir?

Kayıt vakasını belirli bir müşteriye bağlar, tekrarlayan başvuruların analizini ve ana müşteri verileriyle zenginleştirilmesini sunar.

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ı' kontrol paneli'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 sunar. Bu, kuruluşların belirli müşteri tipleri için kabul deneyimini özelleştirmesine ve optimize etmesine yardımcı olur.

Neden Önemli?dir?

Farklı müşteri segmentleri arasında performans karşılaştırması yapılmasına sunar, 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ütmeyenTröst
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ı tespit etmesine ve yerel düzenlemelere uyumu güçlüasına sunar. Süreç analizine coğrafi bir boyut sunar, bu da önemli operasyonel farklılıkları ortaya çıkarabilir.

Neden Önemli?dir?

Sürecin coğrafi analizine sunar, 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 büyük önem taşır. 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ı sunar.

Neden Önemli?dir?

Sistem ve insan faaliyetleri arasında ayrım yapar; bu, otomasyonun etkisini ölçmek ve yeni otomasyon fırsatlarını belirlemek için önemlidir.

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
Bir 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 sunar.

Bu öznitelik, 'Başvuru Reddetme Oranı ve Nedenleri' kontrol paneli'unun temel belirleyicisidir. 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 sunar.

Neden Önemli?dir?

Başvuru reddedilmesinin temel nedenini sunar; bu, reddedilme oranını azaltmak için kayıt sürecinde iyileştirilmesi gereken alanları belirlemek için gereklidir.

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ı (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?dir?

Hizmet seviyesi anlaşmalarına uyumu doğrudan ölçer, bu da geciken vakaların kolayca filtrelenmesini ve kök neden analizini sunar.

Nereden Alınır??

Bu, veri dönüşümü sırasında bir vaka için son faaliyet zaman damgası (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ı (zaman damgası)dır.
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 Panellerin 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 sunar. Veri yönetişimi ve sağlanan stratejik bilgilerin güncelliği hakkındaki kullanıcı beklentilerini yönetmek için gereklidir.

Neden Önemli?dir?

Veri güncelliği hakkında önemli bilgiler sunar, kullanıcıların süreç analizinin ne kadar güncel olduğunu anlamalarını garanti eder.

Nereden Alınır??

Bu zaman damgası (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 büyük önem taşır. '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?dir?

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 sunar.

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 Opsiyonel

KYC Müşteri Edinimi Aktiviteleri

Bunlar, doğru süreç keşfi için event lognüze (event log) kaydetmeniz gereken temel süreç adımları ve kilometre taşlarıdır.
8 Önerilen 6 Opsiyonel
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?dir?

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?dir?

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 sunar.

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?dir?

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 büyük önem taşır.

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?dir?

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 büyük önem taşır.

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 Aktive Edildi
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?dir?

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 göstergedir.

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?dir?

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ı (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?dir?

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ı (zaman damgası) kullanılır.

Yakala

Doğrulanmış bir eşleşmeyi gösteren nihai vaka durumunun zaman damgası (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?dir?

Bu faaliyet, tarama sürecinin başarılı, 'ideal süreç akışı' 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ı (zaman damgası) kullanılır.

Yakala

Net bir sonuç gösteren nihai vaka durumunun zaman damgası (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?dir?

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?dir?

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 belirleyicisidir.

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
İnceleme İçin Vaka Yükseltildi
Birinci seviye bir analist, karmaşık veya yüksek riskli bir vakayı nihai karar için kıdemli bir analiste veya yöneticiye destekler. Bu, uyumluluk ekibi içindeki önemli bir devir noktasıdır.
Neden Önemli?dir?

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
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?dir?

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ı (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?dir?

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
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?dir?

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 Opsiyonel

Veri Çıkarma Kılavuzları

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