KYC müşteri kabulü Veri Templateiniz

Refinitiv World-Check
KYC müşteri kabulü Veri Templateiniz

KYC müşteri kabulü Veri Templateiniz

Bu Template, KYC müşteri kabul sürecinizi analiz etmek için gerekli verileri toplamanıza yardımcı olur. Kaydetmeniz gereken temel öznitelikleri ve izlemeniz gereken önemli etkinlikleri açıklar; ayrıca bu bilgileri kaynak sistemlerinizden nasıl çıkarabileceğinizi anlatır. Süreç analizi ve iyileştirme için gereken tüm verilere sahip olduğunuzdan emin olmak üzere bu kaynaktan yararlanın.
  • Toplanması önerilen öznitelikler
  • İzlenecek temel etkinlikler
  • Veri çıkarma yönergeleri
Olay günlüklerine yeni misiniz? Process Mining için nasıl Event Log oluşturacağınızı öğrenin.

KYC müşteri kabulü öznitelikleri

Kapsamlı bir KYC müşteri kabulü analizi için Event Logunuza eklemeniz önerilen veri alanları bunlardır.
3 Zorunlu 5 Önerilen 11 İsteğe bağlı
Ad Açıklama
Etkinlik adı
ActivityName
KYC müşteri kabul sürecinde gerçekleşen belirli bir iş olayının veya görevin adı.
Açıklama

Etkinlik adı, müşteri kabul sürecindeki tek bir adımı veya olayı tanımlar. Örneğin 'Başvuru gönderildi', 'Analist incelemesi başladı' ya da 'Tarama tamamlandı - sonuç temiz'. Bu etkinlikler süreç haritasındaki düğümleri oluşturur ve iş akışının uçtan uca ayrıntılı görünümünü sunar.

Etkinlikleri incelemek, Process Mining çalışmalarının temelidir. Farklı etkinliklerin sırasını ve sıklığını takip ederek gerçek süreç akışını keşfedebilir, yaygın yolları belirleyebilir, standart prosedürden sapmaları tespit edebilir ve gecikmeye ya da yeniden çalışmaya neden olan adımları bulabilirsiniz. Süreç haritaları oluşturmak ve etkinlik düzeyindeki metrikleri hesaplamak için bu öznitelik gereklidir.

Neden önemli?

Bu öznitelik, sürecin tek tek adımlarını tanımlar. Süreç akışını keşfetmek ve görselleştirmek, darboğazları belirlemek için gereklidir.

Nereden alınır?

Bu bilgi genellikle olay günlüklerinde veya denetim izi tablolarında bulunur ve çoğu zaman vaka yönetimi kaydındaki durum değişiklikleriyle ilişkilidir.

Örnekler
Olası eşleşme belirlendiAnalist incelemesi başladıHatalı eşleşme olduğu doğrulandıBaşvuru onaylandı
Müşteri başvurusu
CustomerApplication
Tek bir müşterinin müşteri kabul başvurusuna ait benzersiz kimlik; birincil vaka kimliği olarak kullanılır.
Açıklama

Müşteri başvurusu, tek bir müşterinin kabul süreciyle ilgili tüm olayları ve etkinlikleri bir araya getiren temel vaka kimliğidir. İlk başvurudan nihai karara kadar her müşterinin Müşterinizi Tanıyın (KYC) sürecindeki ilerlemesini kronolojik olarak takip etmenizi sağlar.

Process Mining analizinde bu öznitelik, her başvurunun uçtan uca yolculuğunu yeniden oluşturmanın temelini oluşturur. Süreç akışlarını görselleştirmenize, toplam çevrim sürelerini hesaplamanıza ve farklı süreç varyantlarını belirlemenize yardımcı olur. Kuruluşlar, bu kimliğe göre gruplandırılmış vakaları inceleyerek başvuruların izleyebileceği farklı yolları anlayabilir, darboğazları belirleyebilir ve çeşitli müşteri kabul süreçlerinin verimliliğini karşılaştırabilir.

Neden önemli?

İlgili tüm etkinlikleri birbirine bağlayan bu temel vaka kimliği, müşteri kabul sürecini uçtan uca analiz etmenizi sağlar.

Nereden alınır?

Bu kimlik genellikle Refinitiv World-Check sistemindeki veya entegre bir CRM’deki ana başvuru ya da vaka yönetimi tablosunun birincil anahtarıdır.

Örnekler
APP-2023-00123APP-2023-00124APP-2023-00125
Olay zamanı
EventTime
Belirli bir etkinliğin veya olayın ne zaman gerçekleştiğini gösteren zaman damgası.
Açıklama

Olay zamanı, bir etkinliğin kaydedildiği kesin tarih ve saati belirtir. Bu zaman damgası, vaka geçmişini yeniden oluşturmak için olayları doğru sıraya koymanızı sağlar.

Process Mining çalışmalarındaki zamana dayalı tüm analizler bu özniteliğe bağlıdır. Etkinlikler arasındaki süreleri (çevrim ve bekleme süreleri) hesaplamak, toplam vaka süresini ölçmek, süreç performansını zaman içinde incelemek ve hizmet seviyesi anlaşmalarına (SLA) uyumu kontrol etmek için kullanılır. Zaman damgaları doğru değilse süreç performansını anlamak ve zamana bağlı darboğazları belirlemek mümkün olmaz.

Neden önemli?

Her etkinliğin zaman damgası, süreye dayalı metrikleri hesaplamak, süreç sırasını ortaya çıkarmak ve darboğaz analizi yapmak için gereklidir.

Nereden alınır?

Herhangi bir olay günlüğünde veya denetim izi tablosunda bulunan 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
Departman
DepartmentName
Etkinliği gerçekleştirmekten sorumlu departman veya işlevsel ekip.
Açıklama

Bu öznitelik, kullanıcının bağlı olduğu 'Müşteri kabulü', 'Uyumluluk' veya 'Kalite güvencesi' gibi iş birimini ya da ekibi belirtir. Böylece analiz, tek tek kullanıcıların ötesinde kuruluş düzeyinde yapılabilir.

Departmana göre analiz yapmak, departmanlar arasındaki darboğazları belirlemek ve devir teslim sürelerini ölçmek açısından önemlidir. İşin farklı ekipler arasında nasıl ilerlediğini ve geçişlerde nerelerde gecikme yaşandığını görselleştirir. Bu görünüm, ekipler arası iş birliğini kolaylaştırmaya ve genel süreç verimliliğini artırmaya yardımcı olur.

Neden önemli?

Süreç performansını departmana göre analiz etmenizi sağlar ve farklı ekipler arasındaki devir teslim gecikmelerini belirlemek için gereklidir.

Nereden alınır?

Bu bilgi, sistemdeki kullanıcı profiliyle veya bağlantılı bir İK sistemiyle birlikte tutulabilir. Olay verileriyle birleştirmek için kullanıcı kimliğinin kullanılması gerekebilir.

Örnekler
Müşteri kabul ekibiUyumluluk incelemesiÜst yönetim
İnceleyen kimliği
ReviewerId
Etkinliği gerçekleştiren kullanıcının, analistin veya otomatik aracının kimliği.
Açıklama

İnceleyen kimliği, KYC sürecinde belirli bir görevi kimin gerçekleştirdiğini gösterir. Bu kişi bir uyumluluk analisti, müşteri kabul uzmanı veya otomatik etkinlikler için kullanılan bir sistem hesabı olabilir. Bu bilgiyi takip ederek iş yükünün nasıl dağıldığını ve kişisel performansı görebilirsiniz.

Bu öznitelik, kaynaklara dayalı analiz için gereklidir. Kullanıcılar veya ekipler arasındaki performans farklarını anlamaya, eğitim ihtiyaçlarını belirlemeye ve iş yükünü dengelemeye yardımcı olur. Devir teslimleri, sosyal ağları ve uyumluluk kaynaklarının kullanımını analiz etmek için de önemlidir.

Neden önemli?

İş yükü dağılımını, kullanıcı performansını ve departmanlar arasındaki devir teslimleri analiz etmenizi sağlar; kaynakları verimli kullanmak için önemlidir.

Nereden alınır?

Genellikle olay günlüklerinde veya denetim izlerinde bulunur; 'UserID', 'PerformedBy' ya da 'Owner' olarak adlandırılabilir.

Örnekler
analyst_jdoesystem_auto_screenermanager_bsmith
Olay bitiş zamanı
EventEndTime
Belirli bir etkinliğin veya olayın ne zaman tamamlandığını gösteren zaman damgası.
Açıklama

Olay bitiş zamanı, bir etkinliğin tamamlandığı anı gösterir. Başlangıç ve bitiş zamanlarının aynı olduğu anlık olaylar şeklinde modellenebilen birçok etkinliğin yanı sıra, 'Analist incelemesi başladı' ve 'Analist incelemesi tamamlandı' gibi ölçülebilir süreye sahip etkinlikler de vardır. Başlangıç ve bitiş zamanlarının ikisi de varsa işlem süresini hassas biçimde ölçebilirsiniz.

Süreç analizinde bitiş zamanının bulunması, bekleme süresini de içeren çevrim süresinden farklı olarak etkinliğin tam işlem süresini hesaplamanızı sağlar. Böylece vakanın aktif olarak üzerinde çalışıldığı süreyle kuyrukta beklediği süreyi birbirinden ayırabilirsiniz. Bu ayrım, kaynakları verimli kullanmak ve verimlilik analizi yapmak açısından önemlidir.

Neden önemli?

Etkinliğin işlem süresini hassas biçimde hesaplamanızı sağlar. Aktif çalışma süresini bekleme süresinden ayırarak performansı daha doğru analiz edebilirsiniz.

Nereden alınır?

Süreye sahip etkinlikler için bu bilgi, olay günlüğünde veya denetim izi tablolarında 'CompletionDate' ya da 'EndDate' gibi ayrı bir alanda tutulabilir.

Örnekler
2023-10-26T10:45:00Z2023-10-26T12:00:00Z2023-10-27T15:00:00Z
Risk düzeyi
RiskLevel
Müşteri başvurusu için hesaplanan risk sınıflandırması; örneğin düşük, orta veya yüksek.
Açıklama

Risk düzeyi, KYC süreçlerinde gereken ayrıntılı incelemenin kapsamını belirleyen önemli bir bilgidir. Genellikle müşteri türü, coğrafi konum ve işletmenin niteliği gibi etkenlere göre belirlenir. Bu sınıflandırma, başvurunun izleyeceği süreci önemli ölçüde etkileyebilir.

Süreç analizinde vakaları risk düzeyine göre gruplandırmak gerekir. Bu, çevrim süreleri ve süreç akışlarındaki farklılıkları 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 ret oranı ve nedenleri' ile 'Arka plan kontrolü başlatma çevrim süresi' Dashboardlarında kullanılır.

Neden önemli?

Süreci risk düzeyine göre gruplandırmak, bazı vakaların neden daha uzun sürdüğünü veya farklı yollar izlediğini anlamak ve ret oranlarını incelemek açısından önemlidir.

Nereden alınır?

Müşteri başvurusu veya vaka kaydındaki temel veri noktalarından biridir. Refinitiv World-Check vaka yönetimi modülüne bakın.

Örnekler
DüşükOrtaYüksek
SLA hedef tarihi
SlaTargetDate
Müşteri kabul sürecinin tamamlanması gereken hedef tarih.
Açıklama

SLA hedef tarihi, müşteriyle yapılan hizmet seviyesi anlaşmasında veya iç politikalarda belirtilen, tüm müşteri kabul vakasının tamamlanması gereken son tarihtir. Gerçek tamamlanma süreleri bu tarihle karşılaştırılır.

Bu öznitelik, 'SLA uyumu ve ihlal analizi' Dashboardunun temel verisidir. Vakanın zamanında tamamlanıp tamamlanmadığını hesaplamak için kullanılır. SLA ihlallerini incelemek, gecikmelere yol açan sistemik sorunları belirlemeye yardımcı olur. Böylece kuruluş, zamanında tamamlanma oranını artırmak ve uyumluluk gerekliliklerini karşılamak için düzeltici adımlar atabilir.

Neden önemli?

Zamanında tamamlanma performansını ölçmek için karşılaştırma noktasıdır; SLA uyum oranını hesaplamak ve ihlalleri incelemek açısından önemlidir.

Nereden alınır?

Bu tarih genellikle başvurunun gönderildiği tarih ve iş kuralları temel alınarak hesaplanır. Vaka kaydında bir alan olarak tutulabilir.

Örnekler
2023-11-10T17:00:00Z2023-11-15T17:00:00Z2023-11-20T17:00:00Z
Başvuru kanalı
ApplicationChannel
Müşteri başvurusunun gönderildiği kanal; örneğin çevrimiçi portal, şube veya mobil uygulama.
Açıklama

Başvuru kanalı, müşteri başvurusunun hangi kaynaktan gönderildiğini gösterir. Farklı kanallardaki veri bütünlüğü ve kalitesi ile müşteri profilleri değişebilir; bu da sonraki süreçleri etkileyebilir.

Bu öznitelik, 'Kanala göre başvuru hacmi' Dashboardu için gereklidir. Kuruluşlar, farklı kanallardan gelen başvuruların hacmini, çevrim süresini ve sonuçlarını inceleyerek hangi kanalların daha verimli olduğunu ve hangilerinde süreç iyileştirmesi gerektiğini belirleyebilir. Bu analiz, kaynak dağılımı ve kanal yatırımlarıyla ilgili 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 deneyimiyle ilgili stratejik kararlara bilgi sağlar.

Nereden alınır?

Bu bilgi genellikle sürecin başında alınır ve başvuru kaydında bir öznitelik olarak saklanır.

Örnekler
Çevrimiçi portalMobil uygulamaŞubeMüşteri ilişkileri yöneticisi
Eşleşme kimliği
MatchId
World-Check taraması sırasında bulunan olası eşleşmeye ait benzersiz kimlik.
Açıklama

Otomatik tarama süreci yaptırım listelerinde, PEP listelerinde veya olumsuz haber kaynaklarında olası bir eşleşme bulduğunda, ilgili bulguyu izlemek için genellikle bir Eşleşme Kimliği oluşturulur. Bu kimlik, başvuru vakasını uyarıyı tetikleyen World-Check veritabanındaki kayda bağlar.

Bu öznitelik, ayrıntılı uyumluluk analizi için kullanışlıdır. Analistlerin eşleşmelerin niteliğini incelemesine, belirli uyarıların nasıl sonuçlandığını izlemesine (ör. yanlış pozitif veya gerçek eşleşme olduğunu doğrulamasına) ve hangi uyarı türlerinin daha sık görüldüğünü ya da sonuçlandırılmasının daha uzun sürdüğünü anlamasına yardımcı olur. 'Olası Eşleşme Belirlendi' etkinliğini daha ayrıntılı inceleme olanağı sunar.

Neden önemli?

Belirli tarama sonuçlarına doğrudan bağlantı sağlar; böylece eşleşmelerin sonuçlandırılma süreleri ve uyarı türleri daha ayrıntılı incelenebilir.

Nereden alınır?

Olası bir eşleşme bulunduğunda bu kimlik, World-Check tarama motoru tarafından oluşturulur ve başvuru vakasına kaydedilir.

Örnekler
WC-MATCH-459021WC-MATCH-459022WC-MATCH-459023
Kaynak sistem
SourceSystem
Bu örnekte Refinitiv World-Check olmak üzere, olay verilerinin alındığı sistem.
Açıklama

Bu öznitelik, süreç verilerinin kaynağını belirtir. Tek bir kaynaktan veri alındığında sabit bir değer olabilir; ancak bütünsel bir süreç görünümü oluşturmak için CRM ve World-Check gibi birden fazla sistemin verileri birleştirildiğinde önem kazanır.

Analiz sırasında veri yönetişimine, sorun gidermeye ve verilerin bağlamını anlamaya yardımcı olur. Örneğin, temel tarama sistemine kaydedilen etkinliklerin özellikleri veya ayrıntı düzeyi, yardımcı bir sistemdekilerden farklı olabilir. Ayrıca verilerin kaynağının açıkça izlenebilmesini ve denetlenebilmesini sağlar.

Neden önemli?

Verilerin kaynağını belirtir. Veri yönetişimi ve doğrulama için, ayrıca birden fazla kaynaktan gelen verileri birleştirirken önem taşır.

Nereden alınır?

Veri setini etiketlemek için genellikle veri çıkarma, dönüştürme ve yükleme (ETL) sürecinde eklenen sabit bir değerdir.

Örnekler
Refinitiv World-CheckWorldCheckOne
Müşteri kimliği
CustomerId
Müşteri kabul sürecine alınan müşteriye ait benzersiz kimlik.
Açıklama

Müşteri kimliği, müşteri profilinin benzersiz kimliğidir. Bir müşteri zaman içinde birden fazla başvuru yapabileceğinden, bu kimlik Müşteri Başvuru Kimliğinden farklıdır. Müşteri kabul sürecini ana müşteri kaydına bağlar.

Analizde Müşteri Kimliği, aynı müşterinin tekrarlanan başvurularını takip etmenizi sağlar. Ayrıca süreç verilerini CRM’den veya ana veri sisteminden alınan diğer müşteri öznitelikleriyle zenginleştirmek için kullanılabilir. Böylece tek bir müşteri kabul sürecinin ötesinde, müşteri yolculuğunun bütününü görebilirsiniz.

Neden önemli?

Müşteri kabul vakasını belirli bir müşteriye bağlar; tekrarlanan başvuruları analiz etmenizi ve verileri ana müşteri bilgileriyle zenginleştirmenizi sağlar.

Nereden alınır?

Başvuru veya vaka kaydında bulunan ve kaydı ana müşteri verilerine bağlayan önemli bir alandır.

Örnekler
CUST-98765CUST-98766CUST-98767
Müşteri türü
CustomerType
Müşterinin birey, şirket veya tröst gibi sınıflandırması.
Açıklama

Müşteri türü, müşteri kabul sürecine alınan varlığı sınıflandırır. Farklı müşteri türlerinin kabul koşulları, risk profilleri ve mevzuat yükümlülükleri değişebilir. Örneğin, bir şirketin müşteri kabul süreci genellikle bir bireyinkinden daha karmaşıktır.

Bu öznitelik, özellikle 'KYC müşteri türüne göre performans' Dashboardunda segmentasyon analizi için kullanılır. Farklı müşteri segmentlerinin süreç verimliliğini, çevrim sürelerini ve ret oranlarını karşılaştırmanızı sağlar. Böylece kuruluşlar, müşteri kabul deneyimini farklı müşteri türlerine göre uyarlayıp iyileştirebilir.

Neden önemli?

Farklı müşteri segmentlerinin performansını karşılaştırmanızı, her tür için müşteri kabul sürecini uyarlayıp iyileştirmenizi sağlar.

Nereden alınır?

Kaynak sistemdeki müşteri veya başvuru kaydında tutulan temel bir özniteliktir.

Örnekler
BireyŞirketKâr amacı gütmeyen kuruluşTröst
Müşterinin ülkesi
CustomerCountry
Müşterinin ikamet ettiği veya kurulduğu ülke.
Açıklama

Bu öznitelik, müşterinin coğrafi konumunu gösterir. Ülke, KYC süreçlerinde risk değerlendirmesini ve mevzuat gerekliliklerini önemli ölçüde etkiler. Farklı ülkelerin kuralları, süreç akışını ve süresini değiştirebilir.

Süreci ülkeye göre incelemek, kuruluşların farklı bölgelerdeki performansı karşılaştırmasına, bölgesel darboğazları belirlemesine ve yerel düzenlemelere uyumu sağlamasına yardımcı olur. Süreç analizine coğrafi bir boyut katar ve operasyonlardaki önemli farklılıkları ortaya çıkarabilir.

Neden önemli?

Süreci coğrafi açıdan analiz etmenizi sağlar; bölgesel performans, risk ve uyumluluk gerekliliklerindeki farklılıkları belirlemeye yardımcı olur.

Nereden alınır?

Müşteri profilinde veya başvuru formunda bulunan standart bir alandır.

Örnekler
USAGBRSGPDEU
Otomatik mi
IsAutomated
Etkinliğin bir sistem (true) ya da bir kişi (false) tarafından gerçekleştirildiğini belirten bir işaret.
Açıklama

Bu boole özniteliği, otomatik sistem görevleriyle kullanıcıların gerçekleştirdiği manuel etkinlikleri birbirinden ayırır. Örneğin, 'Otomatik tarama yapıldı' otomatik olarak işaretlenirken 'Analist incelemesi başladı' manuel olarak işaretlenir.

Bu ayrım, otomasyon analizinde büyük önem taşır. Otomasyonun süreç verimliliğine etkisini ölçmeye, gelecekte otomatikleştirilebilecek manuel görevleri belirlemeye ve insanlarla sistemlerin etkileşimini anlamaya yardımcı olur. Sistem işlem süresiyle manuel işlem süresini net biçimde ayırmanızı sağlar.

Neden önemli?

Sistem etkinlikleriyle insan etkinliklerini ayırır. Bu ayrım, otomasyonun etkisini ölçmek ve yeni otomasyon fırsatlarını belirlemek için önemlidir.

Nereden alınır?

Bu değer genellikle etkinlik adına veya olayla ilişkilendirilmiş kullanıcı kimliğine göre belirlenir (ör. kullanıcı bir 'system' hesabıysa).

Örnekler
truefalse
Ret nedeni
RejectionReason
Müşteri başvurusu reddedildiğinde belirtilen özel neden.
Açıklama

Başvuru reddedildiğinde ret nedeni, bu kararın nedenini belirtir. Nedenler arasında 'Yaptırım listesi eşleşmesi', 'Eksik dokümantasyon' veya 'Yüksek risk profili' bulunabilir. Bu bilgi, gelen başvuruların kalitesi ve tarama sürecinin etkililiği hakkında yapılandırılmış geri bildirim sağlar.

Bu öznitelik, 'Başvuru ret oranı ve nedenleri' Dashboardunun temel verisidir. Ret nedenlerini incelemek, retlerin temel nedenlerini belirlemeye yardımcı olur. Böylece süreç iyileştirilebilir, başvuru sahipleriyle daha açık iletişim kurulabilir ve gereksiz retler azaltılabilir. Ayrıca sayısal ret oranı metriğine niteliksel bağlam kazandırır.

Neden önemli?

Başvuruların neden reddedildiğini ortaya koyar. Ret oranını azaltmak için müşteri kabul sürecinde iyileştirilmesi gereken alanları belirlemeye yardımcı olur.

Nereden alınır?

'Başvuru reddedildi' olayı gerçekleştiğinde, muhtemelen vaka veya başvuru kaydındaki bir alana yazılır.

Örnekler
PEP eşleşmesiYaptırım listesinde eşleşme bulunduBelge doğrulaması başarısız olduOlumsuz medya kaydı
SLA ihlal edildi
SlaBreached
İşe alım vakasının SLA hedef tarihinden sonra tamamlanıp tamamlanmadığını belirten bir boole işareti.
Açıklama

Bu öznitelik, bir vakanın Hizmet Seviyesi Anlaşmasını ihlal edip etmediğini gösteren hesaplanmış bir işarettir. Vakanın son tamamlama etkinliğinin zaman damgası (ör. 'Başvuru onaylandı' veya 'Başvuru reddedildi'), vakaya ait 'SlaTargetDate' değeriyle karşılaştırılarak belirlenir.

Bu işaret, 'SLA uyumu ve ihlal analizi' Dashboardunun ve 'SLA uyum oranı' KPI’ının temelini oluşturur. Kullanıcıların ihlal edilen tüm vakaları hızla filtrelemesini sağlayarak analizi kolaylaştırır. Kuruluşlar, SLA’yı ihlal eden vakaların süreç özelliklerini inceleyerek gecikmelerin temel nedenlerini belirleyebilir ve iyileştirme çalışmalarını doğru alanlara yöneltebilir.

Neden önemli?

Hizmet seviyesi anlaşmalarına uyumu doğrudan ölçer; geciken vakaları kolayca filtreleyip temel nedenlerini analiz etmenizi sağlar.

Nereden alınır?

Bu değer, veri dönüştürme sırasında vakanın son etkinliğinin zaman damgası ile SlaTargetDate alanı karşılaştırılarak hesaplanır.

Örnekler
truefalse
Son veri güncellemesi
LastDataUpdate
Bu olaya ait verilerin kaynak sistemden en son yenilendiği veya alındığı zamanı gösteren zaman damgası.
Açıklama

Bu öznitelik, verilerin ne kadar güncel olduğunu gösterir. Refinitiv World-Check’ten en son veri alımının tarih ve saatini kaydeder. Process Mining Dashboardlarının ve analizlerinin güncelliğini anlamak için önemlidir.

Analiz sırasında kullanıcıların gerçek zamana yakın verileri mi yoksa belirli bir andan alınmış bir anlık görüntüyü mü incelediğini anlamalarını sağlar. Veri yönetişimi ve sunulan içgörülerin güncelliğine ilişkin beklentileri yönetmek için gereklidir.

Neden önemli?

Verilerin güncelliği hakkında önemli bağlam sağlar ve kullanıcıların süreç analizinin ne kadar güncel olduğunu anlamasına yardımcı olur.

Nereden alınır?

Bu zaman damgası, veri çıkarma (ETL) sürecinde oluşturulur ve eklenir.

Örnekler
2023-11-01T02:00:00Z2023-11-02T02:00:00Z
Yeniden çalışma mı
IsRework
Bir etkinliğin aynı vaka içinde ikinci veya daha sonraki kez gerçekleştirildiğini belirten bir işaret.
Açıklama

IsRework, aynı müşteri başvuru vakasında bir etkinliğin tekrarlandığını belirleyen hesaplanmış bir boole özniteliğidir. Örneğin, tek bir başvuru için 'Risk değerlendirmesi yapıldı' etkinliği birden fazla kez gerçekleşirse sonraki tekrarlar yeniden çalışma olarak işaretlenir.

Bu öznitelik, süreç verimsizliklerini, döngüleri ve gereksiz tekrarları belirlemek için önemlidir. 'Risk değerlendirmesinde yeniden çalışma ve verimlilik' Dashboardunu ve 'Risk değerlendirmesinde yeniden çalışma oranı' KPI’ını doğrudan destekler. Yeniden çalışmayı analiz etmek; kalite, bilgi açıklığı veya karar alma süreçlerindeki sorunları ortaya çıkarır. Bu sorunlar boşa harcanan emeğe ve daha uzun çevrim sürelerine yol açar.

Neden önemli?

Tekrarlanan etkinlikleri işaretleyerek süreç verimsizliklerini ortaya çıkarır. Böylece kaliteyi artırmak ve çevrim sürelerini kısaltmak için yeniden çalışma döngülerini analiz edebilirsiniz.

Nereden alınır?

Bu değer, veri dönüştürme sırasında her vakadaki etkinlik sırası incelenerek ve bir etkinliğin ilk gerçekleşmesinden sonraki tüm tekrarları işaretlenerek hesaplanır.

Örnekler
truefalse
Zorunlu Önerilen İsteğe bağlı

KYC müşteri kabulü etkinlikleri

Süreci doğru biçimde keşfetmek için Event Logunuza kaydetmeniz gereken temel süreç adımları ve kilometre taşları bunlardır.
8 Önerilen 6 İsteğe bağlı
Aktivite Açıklama
Analist incelemesi başladı
Uyumluluk analisti, müşteri başvurusundaki olası eşleşmeleri manuel olarak incelemeye başlar. Bu incelemede, olası eşleşmelerin ayrıntıları müşterinin bilgileriyle karşılaştırılarak eşleşmenin geçerli olup olmadığı değerlendirilir.
Neden önemli?

Bu etkinlik, manuel uyumluluk incelemesinin başlangıcını gösterir. Bu aşama sıkça darboğaz oluşturur. 'Olası eşleşme belirlendi' ile bu etkinlik arasındaki süre, kuyrukta bekleme gecikmelerini; incelemenin süresi ise analistlerin verimliliğini gösterir.

Nereden alınır?

Bir analistin inceleme kuyruğundan vakayı 'üstlenmesi' veya açmasıyla çıkarılabilir. Vaka durumu 'İnceleniyor' olarak değiştiğinde ya da vaka belirli bir kullanıcıya atandığında sistem bu olayı denetim izine açıkça kaydedebilir.

Kaydedin

Vaka durumunun 'İnceleniyor' olarak değişmesinden veya vakanın bir analiste atanmasından çıkarılır.

Olay türü inferred
Başvuru gönderildi
Bu etkinlik, müşterinin başvurusunu göndermesiyle KYC müşteri kabul sürecinin başladığını gösterir. Bu olay genellikle bir CRM veya temel başvuru sisteminde kaydedilir ve ardından Refinitiv World-Check’te tarama sürecini başlatır.
Neden önemli?

Bu, müşterinin baştan sona kabul sürecindeki temel başlangıç olayıdır. Bu noktadan tamamlanmaya kadar geçen süreyi analiz ederek toplam müşteri kabul çevrim süresini ölçebilirsiniz. Bu ölçüm, müşteri deneyimini ve SLA hedeflerine uyumu değerlendirmek için önemlidir.

Nereden alınır?

Bu olay World-Check’te yerleşik olarak bulunmaz. CRM veya müşteri hesabı yönetim platformu gibi önceki bir sistemden alınmalı ve Müşteri Başvurusu Kimliği kullanılarak ilişkilendirilmelidir.

Kaydedin

İlk başvuru gönderildiğinde kaynak başvuru sistemine kaydedilen olay.

Olay türü explicit
Başvuru reddedildi
Müşteri başvurusu, çoğunlukla World-Check’te 'Eşleşme bulundu' sonucu alınması veya başka risk etkenleri nedeniyle resmen reddedilir. Bu olay, müşteri kabul sürecinin nihai olumsuz sonucudur.
Neden önemli?

Bu, sürecin başlıca başarısızlıkla sonuçlanan bitiş noktasıdır. Özellikle ret nedenlerini ve öncesindeki etkinlikleri incelemek, süreci iyileştirmek ve gereksiz retleri azaltmak açısından önemlidir.

Nereden alınır?

Bu nihai iş kararı World-Check’te değil, üst sistemdeki CRM’de veya temel başvuru sisteminde kaydedilir. Veriler bu sistemden alınmalıdır.

Kaydedin

Kaynak başvuru sistemine, çoğu zaman ilgili bir ret nedeni koduyla birlikte kaydedilen olay.

Olay türü explicit
Gerçek eşleşme olduğu doğrulandı
Analist, olası eşleşmenin taranan müşteriyle gerçekten aynı kişi ya da kuruluş olduğunu doğrulayarak olası bir riski belirler. Bu önemli aşama genellikle ayrıntılı incelemeyi başlatır veya başvurunun reddedilmesine yol açar.
Neden önemli?

Bu, riski azaltmaya yönelik önemli bir sonuç ve süreçte belirleyici bir aşamadır. Müşteri başvurusu hakkındaki nihai kararı doğrudan etkiler; uyumluluk raporlaması ve analizi açısından da önem taşır.

Nereden alınır?

Analistin belirli bir eşleşmeyi 'Gerçek eşleşme' veya 'Doğrulanmış eşleşme' olarak sonuçlandırdığı açık bir kullanıcı işlemidir. Bu olay vaka denetim izine kaydedilir.

Kaydedin

Analist sistemde bir eşleşmeyi resmen doğruladığında kaydedilir.

Olay türü explicit
Hesap etkinleştirildi
Müşterinin hesabı temel sistemde oluşturulur ve etkinleştirilir; böylece müşteri kabul süreci tamamlanır. Bu adım, başvurunun nihai onayından sonra gelir ve hesabı kullanıma hazır hâle getirir.
Neden önemli?

Bu, süreçte müşteriye değer sağlayan son adımdır. Başvurunun gönderilmesinden hesabın etkinleştirilmesine kadar geçen süre, operasyonel verimlilik ve müşteri memnuniyeti açısından önemli bir metriktir.

Nereden alınır?

Bu olay World-Check’te kaydedilmez. Temel bankacılık veya müşteri hesap sisteminde tutulur ve Müşteri Başvuru Kimliği kullanılarak ilişkilendirilmelidir.

Kaydedin

Hesap etkinleştirildiğinde temel hesap sistemine kaydedilen olay.

Olay türü explicit
Tarama talebi oluşturuldu
Refinitiv World-Check sisteminde müşteri başvurusu için yeni bir tarama vakası resmî olarak oluşturulur. Bu işlem, önceki bir sistemden gelen API çağrısıyla veya manuel girişle başlatılır ve risk istihbaratı kontrolünün başlangıcını gösterir.
Neden önemli?

Bu, tarama alt sürecinin resmen başladığını gösterir. Başvurunun gönderilmesi ile bu etkinlik arasındaki süre, iş birimi sisteminden uyumluluk ekibine yapılan devir teslimlerdeki gecikmeleri ortaya çıkarır.

Nereden alınır?

World-Check vaka yönetimi günlüklerinde veya denetim izinde kaydedilir. İlgili vaka ya da varlık kimliği için oluşturma olayı ve zaman damgası kullanılır.

Kaydedin

Sistemde yeni bir tarama vakası oluşturulduğunda otomatik olarak kaydedilir.

Olay türü explicit
Tarama tamamlandı - eşleşme bulundu
Tarama vakası, doğrulanmış bir risk bulunduğunu belirten 'Eşleşme bulundu' sonucuyla resmen kapatılır. Bu karar, ayrıntılı inceleme veya başvurunun reddedilmesi gibi farklı bir sonraki süreci başlatır.
Neden önemli?

Bu, tarama sürecinin başlıca olumsuz sonuçla biten yoludur. Bu vakaları incelemek, risk profillerini ve tarama kontrollerinin ne kadar etkili olduğunu anlamaya yardımcı olur.

Nereden alınır?

Nihai vaka durumunun 'Eşleşme bulundu', 'Risk belirlendi' veya 'Kapandı - olumlu' olarak değişmesinden çıkarılır. Bu son durum değişikliğinin zaman damgası kullanılır.

Kaydedin

Doğrulanmış eşleşmeyi belirten nihai vaka durumunun zaman damgasından elde edilir.

Olay türü inferred
Tarama tamamlandı - sonuç temiz
Tarama vakası, gerçek bir eşleşme bulunmadığını belirten 'Temiz' sonucuyla resmen kapatılır. Bu karar başvurunun geldiği sisteme iletilir ve müşteri kabul sürecinin devam etmesini sağlar.
Neden önemli?

Bu etkinlik, tarama sürecinin başarıyla tamamlandığı ideal yolu gösterir. Standart ve düşük riskli başvuruların çevrim süresini ölçmek için önemli bir bitiş noktasıdır.

Nereden alınır?

Nihai vaka durumunun 'Temiz', 'Tamamlandı' veya 'Kapandı - eşleşme yok' olarak değişmesinden çıkarılır. Bu son durum değişikliğinin zaman damgası kullanılır.

Kaydedin

Temiz sonucu belirten nihai vaka durumunun zaman damgasından elde edilir.

Olay türü inferred
Başvuru onaylandı
Başvuru, KYC taraması ve gerekli diğer kontroller başarıyla tamamlandıktan sonra tamamen onaylanmıştır. Bu olay genellikle World-Check’ten 'Temiz' sonucu alındıktan sonra kaynak sistemde gerçekleşir.
Neden önemli?

Bu, müşteri kabul sürecinin başarılı iş sonucunu gösterir. Başvurunun gönderilmesinden bu aşamaya kadar geçen süreyi takip ederek yeni bir müşteri için toplam onay süresini görebilirsiniz.

Nereden alınır?

Bu olay World-Check’e özgü değildir. Nihai iş kararını veren üst sistemdeki CRM’den veya temel başvuru sisteminden alınmalıdır.

Kaydedin

Nihai onay verildiğinde kaynak başvuru sistemine kaydedilen olay.

Olay türü explicit
Ek bilgi istendi
Analist, olası eşleşmeyi sonuçlandırmak için daha fazla bilgi gerektiğine karar verir ve bu bilgiyi iş biriminden ister. Bilgi sağlanana kadar vaka beklemede kalır.
Neden önemli?

Bu etkinliğin sık tekrarlanması, tarama için sağlanan ilk verilerin kalitesinde sorun olduğuna işaret eder. Başka ekiplere bağlı olduğu için önemli gecikmelere yol açar ve uzun çevrim sürelerinin başlıca nedenlerinden biridir.

Nereden alınır?

Vaka notlarında veya denetim günlüğünde kaydedilen açık bir kullanıcı işlemi olabilir. Alternatif olarak, vaka durumunun 'Bilgi bekleniyor' veya 'Bilgi talebi' olarak değişmesinden çıkarılabilir.

Kaydedin

Analist, vakayı daha fazla bilgi gerekiyor şeklinde işaretleyen bir özelliği kullandığında kaydedilir.

Olay türü explicit
Hatalı eşleşme olduğu doğrulandı
Analist, olası eşleşmenin taranan müşteriyle aynı kişi ya da kuruluş olmadığı sonucuna varır. Eşleşme reddedilir ve ilgili uyarı için tarama süreci sonuçlandırılır.
Neden önemli?

Bu, inceleme sürecinde sık karşılaşılan sonuçlardan biridir. Hatalı eşleşmeleri sonuçlandırma süresini anlamak, analist verimliliğini ve otomatik tarama mantığının doğruluğunu ölçmeye yardımcı olur.

Nereden alınır?

Analistin belirli bir eşleşmeyi 'Hatalı eşleşme' veya 'Eşleşme değil' olarak sonuçlandırdığı açık bir kullanıcı işlemidir. Bu işlem genellikle vaka geçmişine kaydedilir.

Kaydedin

Analist olası eşleşmeyi sistemde resmen reddettiğinde kaydedilir.

Olay türü explicit
Olası eşleşme belirlendi
Otomatik tarama süreci, bir analistin manuel olarak incelemesi gereken bir veya daha fazla olası eşleşme bulmuştur. Bu olay, vakayı otomatik işlem aşamasından manuel inceleme kuyruğuna taşır.
Neden önemli?

Bu etkinlik, süreçte önemli bir ayrım noktasıdır. Olası eşleşme bulunan vakalar daha uzun ve karmaşık bir yol izler. Bu vakaları takip etmek, inceleme ekibinin kaynak planlamasına ve darboğaz analizine yardımcı olur.

Nereden alınır?

World-Check vaka yönetimi modülünde vaka durumunun 'İnceleme gerekli', 'Olası eşleşme' veya benzer bir duruma değişmesinden çıkarılır.

Kaydedin

Manuel incelemenin gerektiğini belirten vaka durumu değişikliğinden elde edilir.

Olay türü inferred
Otomatik tarama yapıldı
World-Check sistemi, müşterinin bilgilerini risk istihbaratı veri tabanıyla otomatik olarak karşılaştırır. Sistem tarafından yürütülen bu etkinlik, olası eşleşmeler veya temiz sonuç gibi ilk bulguları üretir.
Neden önemli?

Bu etkinlik, tarama sürecindeki ilk katma değerli adımdır. Bu noktadan önceki gecikmeler, sistemin veya verilerin hazır olmadığını gösterebilir. Sonuç ise sonraki manuel iş yükünü belirler.

Nereden alınır?

Bu olay, vaka denetim izinde açıkça kaydedilebilir veya ilk tarama sonuçlarının vaka için kullanılabilir hâle geldiği zaman damgasından çıkarılabilir.

Kaydedin

Otomatik veri tabanı taraması tamamlandığında oluşturulan sistem günlüğü kaydı.

Olay türü explicit
Vaka inceleme için üst kademeye aktarıldı
İlk düzeydeki bir analist, karmaşık veya yüksek riskli bir vakayı nihai karar için kıdemli bir analiste ya da yöneticiye aktarır. Bu, uyumluluk ekibindeki önemli bir devir teslim noktasıdır.
Neden önemli?

Üst kademeye aktarılan vakalar çoğu zaman darboğazlara yol açar ve çevrim süresini uzatır. Aktarımların sıklığını ve nedenlerini incelemek, deneyimsiz analistlerin eğitim ihtiyacını veya inceleme politikalarındaki belirsizlikleri ortaya çıkarabilir.

Nereden alınır?

Vaka iş akışında veya denetim izinde açık bir işlem olarak kaydedilir. Vakanın atandığı kullanıcının, özellikle daha yüksek yetkilere sahip bir kullanıcının değişmesinden de çıkarılabilir.

Kaydedin

Vaka içindeki özel bir 'Üst kademeye aktar' düğmesi veya iş akışı işlemiyle kaydedilir.

Olay türü explicit
Önerilen İsteğe bağlı

Veri çıkarma rehberleri

Refinitiv World-Check verilerinizi nasıl alabilirsiniz?

Başlamaya hazır mısınız?

KYC müşteri kabulü için Process Mining çalışmalarınıza bu veri Templateiyle başlayın. Bu yönergeleri izleyerek değerli içgörüler elde edebilir ve operasyonlarınızda önemli iyileştirmeler yapabilirsiniz.

KYC müşteri kabulünü şimdi iyileştirin, uyumluluğu artırın

Müşteri kabulünü sorunsuz hale getirin ve süreyi yalnızca 24 saate indirin.

Ücretsiz denemeyi başlatın

Kredi kartı gerekmez. 14 gün ücretsiz deneyin.