> Perbaikan proses berkelanjutan > Onboarding nasabah KYC > Refinitiv World Check > Templat data

Templat data onboarding pelanggan KYC Anda

Refinitiv World-Check

Atribut onboarding pelanggan KYC(19) Aktivitas onboarding pelanggan KYC(14) Panduan ekstraksi(2)

Templat data onboarding pelanggan KYC Anda

Templat ini memandu Anda mengumpulkan data penting untuk menganalisis proses onboarding pelanggan KYC. Templat ini menjelaskan atribut utama yang perlu dicatat, aktivitas penting yang perlu dilacak, serta cara mengekstrak informasi dari sistem sumber. Gunakan panduan ini untuk memastikan data yang diperlukan tersedia bagi analisis dan perbaikan proses.

Atribut yang disarankan untuk dikumpulkan
Aktivitas utama yang perlu dilacak
Panduan ekstraksi

Baru mengenal log peristiwa? Pelajari cara membuat log peristiwa process mining.

Unduh template

Atribut onboarding pelanggan KYC

Berikut kolom data yang disarankan untuk disertakan dalam log peristiwa agar analisis onboarding pelanggan KYC lebih menyeluruh.

3 Wajib 5 Disarankan 11 Opsional

	Nama	Deskripsi
	Nama aktivitas ActivityName	Nama peristiwa bisnis atau tugas tertentu yang terjadi dalam proses penerimaan pelanggan KYC.
Deskripsi Nama Aktivitas menjelaskan satu langkah atau peristiwa dalam proses penerimaan pelanggan, seperti 'Application Submitted', 'Analyst Review Started', atau 'Screening Completed - Clear'. Aktivitas ini menjadi simpul dalam peta proses dan merinci alur kerja dari awal hingga akhir. Analisis aktivitas merupakan inti process mining. Dengan melacak urutan dan frekuensi berbagai aktivitas, analis dapat menemukan alur proses yang sebenarnya, mengenali jalur yang umum, mendeteksi penyimpangan dari prosedur standar, dan menemukan langkah tertentu yang menyebabkan keterlambatan atau pengerjaan ulang. Atribut ini penting untuk menyusun peta proses dan menghitung metrik di tingkat aktivitas. Mengapa ini penting Atribut ini menjabarkan setiap langkah dalam proses. Informasi ini penting untuk menemukan dan memvisualisasikan alur proses serta mengidentifikasi hambatan. Sumber data Informasi ini biasanya terdapat dalam log peristiwa atau tabel jejak audit, sering kali terkait dengan perubahan status pada entitas manajemen kasus. Contoh Kemungkinan kecocokan ditemukanPeninjauan analis dimulaiPositif palsu dikonfirmasiPengajuan disetujui
	Pengajuan pelanggan CustomerApplication	Pengenal unik untuk pengajuan penerimaan satu pelanggan, yang berfungsi sebagai ID kasus utama.
Deskripsi Customer Application adalah ID kasus utama yang mengelompokkan semua peristiwa dan aktivitas terkait proses penerimaan seorang pelanggan. ID ini memungkinkan Anda melacak seluruh perjalanan setiap pelanggan secara kronologis dalam proses Know Your Customer (KYC), dari pengajuan awal hingga keputusan akhir. Dalam analisis process mining, atribut ini menjadi dasar untuk merekonstruksi perjalanan setiap pengajuan dari awal hingga akhir. Atribut ini membantu memvisualisasikan alur proses, menghitung total waktu siklus, dan menemukan variasi proses. Dengan mengelompokkan kasus berdasarkan ID ini, organisasi dapat memahami berbagai jalur yang ditempuh pengajuan, menemukan hambatan, dan membandingkan efisiensi proses penerimaan pelanggan. Mengapa ini penting ID kasus penting ini menghubungkan semua aktivitas terkait, sehingga proses penerimaan pelanggan dari awal hingga akhir dapat dianalisis. Sumber data Pengenal ini biasanya menjadi kunci utama di tabel pengajuan utama atau tabel manajemen kasus dalam sistem Refinitiv World-Check atau CRM terintegrasi. Contoh APP-2023-00123APP-2023-00124APP-2023-00125
	Waktu peristiwa EventTime	Stempel waktu yang menunjukkan kapan aktivitas atau peristiwa tertentu terjadi.
Deskripsi Waktu Peristiwa menunjukkan tanggal dan waktu persis saat aktivitas dicatat. Stempel waktu ini menjadi dasar kronologis proses, sehingga peristiwa dapat diurutkan dengan benar untuk merekonstruksi riwayat kasus. Atribut ini penting untuk semua analisis berbasis waktu dalam process mining. Atribut ini digunakan untuk menghitung durasi antaraktivitas, termasuk waktu siklus dan waktu tunggu, mengukur durasi keseluruhan kasus, menganalisis kinerja proses dari waktu ke waktu, serta memeriksa kepatuhan terhadap Service Level Agreement (SLA). Tanpa stempel waktu yang akurat, kinerja proses dan hambatan berdasarkan waktu tidak dapat diketahui. Mengapa ini penting Stempel waktu setiap aktivitas diperlukan untuk menghitung semua metrik durasi, menemukan urutan proses, dan menganalisis hambatan. Sumber data Kolom ini umum ditemukan dalam log peristiwa atau tabel jejak audit, biasanya bernama 'Timestamp', 'EventDate', atau 'CreationDate'. Contoh 2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T14:22:15Z
	Departemen DepartmentName	Departemen atau tim fungsional yang bertanggung jawab menjalankan aktivitas.
Deskripsi Atribut ini menunjukkan unit bisnis atau tim tempat pengguna bekerja, seperti 'Onboarding', 'Compliance', atau 'Quality Assurance'. Atribut ini memungkinkan analisis pada tingkat organisasi yang lebih luas daripada pengguna perorangan. Analisis berdasarkan departemen penting untuk menemukan hambatan antarbagian dan mengukur waktu serah terima. Analisis ini memperlihatkan alur kerja antar tim dan titik terjadinya keterlambatan. Tampilan ini membantu memperlancar kolaborasi lintas fungsi dan meningkatkan efisiensi proses secara keseluruhan. Mengapa ini penting Memungkinkan analisis kinerja proses berdasarkan departemen dan membantu menemukan keterlambatan serah terima antar tim. Sumber data Informasi ini mungkin tersimpan di profil pengguna dalam sistem atau di sistem SDM terkait. Data mungkin perlu digabungkan dengan data peristiwa menggunakan ID pengguna. Contoh Tim penerimaan pelangganPeninjauan kepatuhanManajemen senior
	ID peninjau ReviewerId	Pengenal pengguna, analis, atau agen otomatis yang melakukan aktivitas.
Deskripsi ID Peninjau atau pengguna menunjukkan siapa yang menjalankan tugas tertentu dalam proses KYC. Pelaksananya bisa berupa analis kepatuhan, spesialis penerimaan pelanggan, atau akun sistem untuk aktivitas otomatis. Pelacakan informasi ini memperlihatkan pembagian beban kerja dan kinerja tiap orang. Atribut ini penting untuk analisis berdasarkan sumber daya. Informasi ini membantu memahami perbedaan kinerja antar pengguna atau tim, menemukan kebutuhan pelatihan, dan menyeimbangkan beban kerja. Atribut ini juga penting untuk menganalisis serah terima, jaringan kerja sama, dan pemanfaatan sumber daya kepatuhan. Mengapa ini penting Mendukung analisis pembagian beban kerja, kinerja pengguna, dan serah terima antarbagian, yang penting untuk mengoptimalkan sumber daya. Sumber data Biasanya terdapat dalam log peristiwa atau jejak audit, dengan nama seperti 'UserID', 'PerformedBy', atau 'Owner'. Contoh analyst_jdoesystem_auto_screenermanager_bsmith
	Tanggal target SLA SlaTargetDate	Tanggal target penyelesaian proses penerimaan pelanggan.
Deskripsi Tanggal Target SLA adalah tenggat penyelesaian seluruh kasus penerimaan pelanggan, sesuai perjanjian tingkat layanan dengan pelanggan atau kebijakan internal. Tanggal ini menjadi patokan untuk membandingkan waktu penyelesaian aktual. Atribut ini menjadi dasar dashboard 'SLA Adherence and Breach Analysis'. Atribut ini digunakan untuk menghitung apakah kasus selesai tepat waktu. Analisis pelanggaran SLA membantu menemukan masalah sistemik yang menyebabkan keterlambatan, sehingga organisasi dapat mengambil tindakan korektif untuk meningkatkan ketepatan waktu dan memenuhi persyaratan kepatuhan. Mengapa ini penting Menjadi patokan untuk mengukur ketepatan waktu dan penting untuk menghitung tingkat kepatuhan terhadap SLA serta menganalisis pelanggaran. Sumber data Tanggal ini sering dihitung berdasarkan tanggal pengajuan dan aturan bisnis. Tanggal tersebut mungkin disimpan sebagai kolom pada catatan kasus. Contoh 2023-11-10T17:00:00Z2023-11-15T17:00:00Z2023-11-20T17:00:00Z
	Tingkat risiko RiskLevel	Klasifikasi risiko pengajuan pelanggan yang dihitung, seperti Rendah, Sedang, atau Tinggi.
Deskripsi Tingkat Risiko merupakan informasi penting dalam proses KYC karena menentukan tingkat uji tuntas yang diperlukan. Tingkat ini biasanya ditentukan berdasarkan faktor seperti jenis pelanggan, wilayah, dan bidang usahanya. Klasifikasi ini dapat sangat memengaruhi jalur yang ditempuh suatu pengajuan. Dalam analisis proses, kasus perlu dikelompokkan berdasarkan Tingkat Risiko. Pengelompokan ini membantu menjelaskan perbedaan waktu siklus dan alur proses. Misalnya, pengajuan berisiko tinggi mungkin memerlukan lebih banyak langkah dan waktu lebih lama. Atribut ini penting untuk dashboard 'Application Rejection Rate and Reasons' dan 'Background Check Initiation Cycle Time' agar Anda dapat memahami dampak risiko terhadap hasil dan efisiensi. Mengapa ini penting Pengelompokan proses berdasarkan tingkat risiko penting untuk memahami alasan kasus tertentu memerlukan waktu lebih lama atau menempuh jalur berbeda, serta untuk menganalisis tingkat penolakan. Sumber data Ini merupakan data utama pada catatan pengajuan pelanggan atau kasus. Periksa modul manajemen kasus di Refinitiv World-Check. Contoh RendahSedangTinggi
	Waktu akhir peristiwa EventEndTime	Stempel waktu yang menunjukkan kapan aktivitas atau peristiwa tertentu selesai.
Deskripsi Waktu Akhir Peristiwa menandai selesainya suatu aktivitas. Banyak peristiwa dapat dimodelkan sebagai kejadian seketika, dengan StartTime sama dengan EndTime. Namun, beberapa aktivitas memiliki durasi yang dapat diukur, seperti 'Analyst Review Started' dan 'Analyst Review Completed'. Data waktu mulai dan selesai memungkinkan pengukuran waktu pemrosesan secara akurat. Dalam analisis proses, waktu selesai diperlukan untuk menghitung waktu pemrosesan aktivitas secara tepat, terpisah dari waktu siklus yang mencakup waktu tunggu. Dengan begitu, Anda dapat membedakan waktu saat kasus sedang ditangani dari waktu saat kasus menganggur di antrean. Informasi ini penting untuk mengoptimalkan sumber daya dan menganalisis efisiensi. Mengapa ini penting Memungkinkan penghitungan waktu pemrosesan aktivitas secara akurat. Waktu kerja aktif dapat dipisahkan dari waktu tunggu agar analisis kinerja lebih tepat. Sumber data Untuk aktivitas yang memiliki durasi, waktu ini mungkin disimpan di kolom terpisah seperti 'CompletionDate' atau 'EndDate' dalam log peristiwa atau tabel jejak audit. Contoh 2023-10-26T10:45:00Z2023-10-26T12:00:00Z2023-10-27T15:00:00Z
	Alasan penolakan RejectionReason	Alasan khusus yang diberikan saat pengajuan pelanggan ditolak.
Deskripsi Saat pengajuan ditolak, Alasan Penolakan mencatat dasar keputusan tersebut. Alasannya dapat berupa 'Sanctions Match', 'Incomplete Documentation', atau 'High Risk Profile'. Informasi ini memberikan masukan terstruktur yang berguna tentang kualitas pengajuan yang masuk dan efektivitas proses penyaringan. Atribut ini menjadi dasar utama dashboard 'Application Rejection Rate and Reasons'. Analisis alasan penolakan membantu menemukan akar masalah dan mendorong perbaikan proses, komunikasi yang lebih jelas dengan pemohon, serta pengurangan penolakan yang tidak perlu. Atribut ini melengkapi KPI tingkat penolakan dengan konteks kualitatif. Mengapa ini penting Menunjukkan akar penyebab penolakan pengajuan. Informasi ini penting untuk menemukan bagian proses penerimaan pelanggan yang perlu diperbaiki agar tingkat penolakan turun. Sumber data Informasi ini dicatat saat peristiwa 'Application Rejected' terjadi, kemungkinan sebagai kolom pada catatan kasus atau pengajuan. Contoh Kecocokan PEPKecocokan dalam daftar sanksiVerifikasi dokumen gagalPemberitaan negatif
	ID kecocokan MatchId	Pengenal unik untuk kemungkinan kecocokan yang ditemukan saat penyaringan World-Check.
Deskripsi Saat proses penyaringan otomatis menemukan kemungkinan kecocokan dengan daftar sanksi, daftar PEP, atau pemberitaan negatif, sistem biasanya membuat Match ID untuk melacak temuan tersebut. ID ini menghubungkan kasus permohonan dengan catatan tertentu di database World-Check yang memicu peringatan. Atribut ini berguna untuk analisis kepatuhan secara terperinci. Analis dapat menyelidiki jenis kecocokan, melacak penyelesaian peringatan tertentu, misalnya memastikan hasil positif palsu atau kecocokan yang benar, serta mengetahui jenis peringatan yang paling sering muncul atau paling lama diselesaikan. Atribut ini memberikan detail lebih lanjut tentang aktivitas 'Kemungkinan Kecocokan Ditemukan'. Mengapa ini penting Menghubungkan hasil penyaringan tertentu secara terperinci, sehingga Anda dapat menganalisis waktu penyelesaian kecocokan dan jenis peringatan lebih lanjut. Sumber data ID ini dibuat oleh mesin penyaringan World-Check dan dicatat pada kasus permohonan saat ditemukan kemungkinan kecocokan. Contoh WC-MATCH-459021WC-MATCH-459022WC-MATCH-459023
	ID pelanggan CustomerId	Pengenal unik untuk entitas pelanggan yang menjalani proses penerimaan.
Deskripsi ID Pelanggan adalah pengenal unik untuk profil pelanggan. ID ini berbeda dari Customer Application ID karena seorang pelanggan dapat mengirim beberapa pengajuan dari waktu ke waktu. Atribut ini menghubungkan proses penerimaan dengan catatan utama pelanggan. Dalam analisis, ID Pelanggan memungkinkan pelacakan pengajuan berulang dari pelanggan yang sama. ID ini juga dapat digunakan untuk melengkapi data proses dengan atribut pelanggan lain dari CRM atau sistem data induk. Dengan begitu, Anda dapat melihat perjalanan pelanggan secara lebih menyeluruh, bukan hanya satu proses penerimaan. Mengapa ini penting Menghubungkan kasus penerimaan dengan pelanggan tertentu, sehingga pengajuan berulang dapat dianalisis dan data dapat dilengkapi dengan informasi utama pelanggan. Sumber data Kolom utama ini terdapat pada catatan pengajuan atau kasus dan menghubungkannya dengan data induk pelanggan. Contoh CUST-98765CUST-98766CUST-98767
	Jenis pelanggan CustomerType	Klasifikasi pelanggan, seperti Perorangan, Korporasi, atau Perwalian.
Deskripsi Jenis Pelanggan mengelompokkan entitas yang menjalani proses penerimaan. Setiap jenis pelanggan mungkin memiliki persyaratan penerimaan, profil risiko, dan kewajiban regulasi yang berbeda. Misalnya, penerimaan pelanggan korporasi biasanya lebih rumit daripada penerimaan perorangan. Atribut ini digunakan untuk analisis segmentasi, terutama pada dashboard 'KYC Customer Type Performance'. Atribut ini memungkinkan perbandingan efisiensi proses, waktu siklus, dan tingkat penolakan antarsegmen pelanggan. Dengan begitu, organisasi dapat menyesuaikan dan mengoptimalkan proses penerimaan untuk setiap jenis pelanggan. Mengapa ini penting Memungkinkan perbandingan kinerja antarsegmen pelanggan, sehingga proses penerimaan dapat disesuaikan dan dioptimalkan untuk setiap jenis pelanggan. Sumber data Atribut dasar ini tersimpan pada catatan pelanggan atau pengajuan di sistem sumber. Contoh PeroranganKorporasiNirlabaPerwalian
	Kanal pengajuan ApplicationChannel	Kanal yang digunakan untuk mengirim pengajuan pelanggan, seperti Portal Online, Kantor Cabang, atau Aplikasi Seluler.
Deskripsi Kanal Pengajuan menunjukkan sumber pengiriman pengajuan pelanggan. Kelengkapan dan kualitas data serta demografi pelanggan dapat berbeda di setiap kanal, sehingga memengaruhi proses selanjutnya. Atribut ini penting untuk dashboard 'Application Throughput by Channel'. Dengan menganalisis volume, waktu siklus, dan hasil pengajuan dari berbagai kanal, organisasi dapat mengetahui kanal yang paling efisien dan kanal yang perlu diperbaiki. Analisis ini mendukung keputusan strategis tentang alokasi sumber daya dan investasi kanal. Mengapa ini penting Membantu menganalisis kinerja dan efisiensi berbagai kanal pengajuan, sebagai dasar keputusan strategis tentang teknologi dan pengalaman pelanggan. Sumber data Informasi ini biasanya dicatat di awal proses dan disimpan sebagai atribut pada catatan pengajuan. Contoh Portal onlineAplikasi selulerKantor cabangManajer relasi
	Negara pelanggan CustomerCountry	Negara tempat pelanggan tinggal atau badan usaha didirikan.
Deskripsi Atribut ini menunjukkan lokasi geografis pelanggan. Negara menjadi faktor penting dalam penilaian risiko dan persyaratan regulasi untuk proses KYC. Aturan berbeda di setiap yurisdiksi dan dapat memengaruhi alur serta durasi proses. Analisis proses berdasarkan negara memungkinkan organisasi membandingkan kinerja antarwilayah, menemukan hambatan khusus di lokasi tertentu, dan memastikan kepatuhan terhadap peraturan setempat. Dimensi geografis ini dapat mengungkap perbedaan operasional yang penting. Mengapa ini penting Memungkinkan analisis proses berdasarkan wilayah geografis untuk menemukan perbedaan kinerja, risiko, dan persyaratan kepatuhan antarwilayah. Sumber data Kolom ini umum ditemukan pada profil pelanggan atau formulir pengajuan. Contoh USAGBRSGPDEU
	Otomatis IsAutomated	Penanda yang menunjukkan apakah aktivitas dilakukan oleh sistem (true) atau manusia (false).
Deskripsi Atribut boolean ini membedakan tugas otomatis yang dilakukan sistem dari aktivitas manual yang dilakukan pengguna. Contohnya, 'Penyaringan Otomatis Dilakukan' ditandai sebagai otomatis, sedangkan 'Peninjauan Analis Dimulai' ditandai sebagai manual. Pembedaan ini penting untuk menganalisis otomatisasi. Anda dapat mengukur dampak otomatisasi terhadap efisiensi proses, menemukan tugas manual yang berpotensi diotomatisasi, serta memahami interaksi antara manusia dan sistem. Atribut ini juga memisahkan waktu pemrosesan sistem dari waktu penanganan manual. Mengapa ini penting Membedakan aktivitas sistem dan manusia. Ini penting untuk mengukur dampak otomatisasi dan menemukan peluang otomatisasi baru. Sumber data Biasanya, nilai ini ditentukan dari nama aktivitas atau ID pengguna yang terkait dengan peristiwa, misalnya jika pengguna memakai akun 'system'. Contoh truefalse
	Pembaruan data terakhir LastDataUpdate	Stempel waktu saat data untuk peristiwa ini terakhir diperbarui atau diambil dari sistem sumber.
Deskripsi Atribut ini menunjukkan seberapa baru data yang digunakan. Atribut ini mencatat tanggal dan waktu pengambilan data terakhir dari Refinitiv World-Check. Informasi ini penting untuk memahami kebaruan data pada dashboard dan analisis process mining. Dengan atribut ini, pengguna dapat mengetahui apakah data yang dilihat mendekati waktu nyata atau merupakan rekam data dari waktu tertentu. Informasi ini penting untuk tata kelola data dan membantu mengelola ekspektasi pengguna tentang kebaruan wawasan yang tersedia. Mengapa ini penting Memberi konteks penting tentang kebaruan data, sehingga pengguna memahami seberapa mutakhir analisis proses yang mereka lihat. Sumber data Stempel waktu ini dibuat dan ditambahkan saat proses ekstraksi data (ETL). Contoh 2023-11-01T02:00:00Z2023-11-02T02:00:00Z
	Pengerjaan Ulang IsRework	Penanda yang menunjukkan apakah suatu aktivitas dilakukan untuk kedua kalinya atau lebih dalam kasus yang sama.
Deskripsi IsRework adalah atribut boolean hasil perhitungan yang menandai aktivitas yang berulang dalam kasus permohonan pelanggan yang sama. Contohnya, jika 'Penilaian Risiko Dilakukan' terjadi lebih dari sekali untuk satu permohonan, kejadian berikutnya ditandai sebagai pengerjaan ulang. Atribut ini penting untuk menemukan proses yang tidak efisien, pengulangan alur, dan aktivitas yang tidak perlu. Atribut ini mendukung dashboard 'Pengerjaan Ulang dan Efisiensi Penilaian Risiko' serta KPI 'Tingkat Pengerjaan Ulang Penilaian Risiko'. Analisis pengerjaan ulang membantu menemukan masalah kualitas, kejelasan informasi, atau pengambilan keputusan yang menyebabkan pekerjaan terbuang dan waktu siklus lebih lama. Mengapa ini penting Menandai aktivitas yang berulang untuk menunjukkan proses yang tidak efisien. Anda dapat menganalisis pengulangan pengerjaan ulang untuk meningkatkan kualitas dan mempersingkat waktu siklus. Sumber data Nilai ini dihitung saat transformasi data dengan menganalisis urutan aktivitas dalam setiap kasus dan menandai aktivitas yang terjadi setelah kemunculan pertama. Contoh truefalse
	Sistem sumber SourceSystem	Sistem tempat data peristiwa diambil, dalam hal ini Refinitiv World-Check.
Deskripsi Atribut ini menunjukkan asal data proses. Nilainya mungkin tetap jika data diambil dari satu sumber, tetapi menjadi penting saat data dari beberapa sistem, seperti CRM dan World-Check, digabungkan untuk memberikan gambaran proses secara menyeluruh. Dalam analisis, informasi ini membantu tata kelola data, pemecahan masalah, dan pemahaman konteks data. Misalnya, aktivitas yang dicatat di sistem penyaringan inti mungkin memiliki karakteristik atau tingkat detail berbeda dari aktivitas di sistem pendukung. Atribut ini memastikan asal-usul data jelas dan dapat diaudit. Mengapa ini penting Menunjukkan asal data. Informasi ini penting untuk tata kelola dan validasi data, serta saat menggabungkan data dari beberapa sumber. Sumber data Nilai ini sering ditambahkan secara statis saat proses ekstraksi, transformasi, dan pemuatan data (ETL) untuk memberi label pada kumpulan data. Contoh Refinitiv World-CheckWorldCheckOne
	SLA Terlampaui SlaBreached	Penanda boolean yang menunjukkan apakah kasus onboarding selesai setelah tanggal target SLA.
Deskripsi Atribut ini berupa penanda hasil perhitungan yang menunjukkan apakah suatu kasus melanggar Service Level Agreement. Nilainya ditentukan dengan membandingkan waktu aktivitas penyelesaian akhir, misalnya 'Permohonan Disetujui' atau 'Permohonan Ditolak', dengan 'SlaTargetDate' pada kasus tersebut. Penanda ini menjadi dasar dashboard 'Analisis Kepatuhan dan Pelanggaran SLA' serta KPI 'Tingkat Kepatuhan SLA'. Pengguna dapat dengan cepat memfilter semua kasus yang melampaui SLA. Dengan menganalisis karakteristik proses pada kasus-kasus tersebut, organisasi dapat menemukan penyebab keterlambatan dan memusatkan upaya perbaikan. Mengapa ini penting Mengukur kepatuhan terhadap perjanjian tingkat layanan secara langsung, sehingga Anda dapat memfilter kasus yang terlambat dan menganalisis penyebabnya dengan mudah. Sumber data Nilai ini dihitung saat transformasi data dengan membandingkan waktu aktivitas terakhir pada suatu kasus dengan kolom SlaTargetDate. Contoh truefalse

Wajib Disarankan Opsional

Aktivitas onboarding pelanggan KYC

Berikut tahapan dan pencapaian proses utama yang perlu dicatat dalam log peristiwa agar proses dapat ditemukan dengan akurat.

8 Disarankan 6 Opsional

	Aktivitas	Deskripsi
	Kecocokan sebenarnya dikonfirmasi	Analis memastikan bahwa kemungkinan kecocokan memang pelanggan yang sedang diperiksa, sehingga risiko teridentifikasi. Ini merupakan tonggak penting yang biasanya memicu uji tuntas lebih lanjut atau penolakan pengajuan.
Mengapa ini penting Hasil ini penting untuk mengurangi risiko dan menjadi titik penentu dalam proses. Hasilnya langsung memengaruhi keputusan akhir atas pengajuan pelanggan dan penting untuk pelaporan serta analisis kepatuhan. Sumber data Ini adalah tindakan eksplisit pengguna. Analis menetapkan hasil kecocokan tertentu sebagai 'True Match' atau 'Confirmed Match'. Peristiwa ini dicatat dalam jejak audit kasus. Pengumpulan data Dicatat saat analis secara resmi mengonfirmasi kecocokan di sistem. Jenis peristiwa explicit
	Pengajuan Dikirim	Aktivitas ini menandai dimulainya proses onboarding KYC saat nasabah mengirimkan pengajuan. Peristiwa ini biasanya tercatat di CRM atau sistem aplikasi utama, yang kemudian memulai proses pemeriksaan di Refinitiv World-Check.
Mengapa ini penting Ini adalah peristiwa awal utama dalam seluruh proses onboarding nasabah. Dengan menganalisis waktu dari tahap ini hingga proses selesai, Anda dapat mengukur waktu siklus onboarding secara keseluruhan. Ukuran ini penting untuk menilai pengalaman nasabah dan kepatuhan terhadap SLA. Sumber data Peristiwa ini tidak berasal dari World-Check. Data harus diambil dari sistem sebelumnya, seperti CRM atau platform pengelolaan akun nasabah, lalu dicocokkan menggunakan ID Pengajuan Nasabah. Pengumpulan data Peristiwa tercatat di sistem aplikasi sumber saat pengajuan pertama kali dikirim. Jenis peristiwa explicit
	Pengajuan ditolak	Pengajuan pelanggan resmi ditolak, sering kali karena hasil 'Match Found' di World-Check atau faktor risiko lainnya. Peristiwa ini menandai hasil akhir negatif dari proses penerimaan pelanggan.
Mengapa ini penting Ini merupakan titik akhir utama kegagalan proses. Analisis peristiwa penolakan, terutama alasannya dan aktivitas sebelumnya, penting untuk perbaikan proses dan mengurangi penolakan yang tidak perlu. Sumber data Keputusan bisnis akhir ini dicatat di CRM hulu atau sistem aplikasi inti, bukan di World-Check. Data harus diambil dari sistem tersebut. Pengumpulan data Peristiwa dicatat di sistem aplikasi sumber, sering kali disertai kode alasan penolakan. Jenis peristiwa explicit
	Peninjauan analis dimulai	Analis kepatuhan mulai memeriksa secara manual kemungkinan kecocokan untuk pengajuan pelanggan. Analis membandingkan detail kemungkinan kecocokan dengan informasi pelanggan untuk menentukan apakah keduanya relevan.
Mengapa ini penting Menandai dimulainya peninjauan kepatuhan manual, yang sering menjadi hambatan. Waktu dari 'Potential Match Identified' hingga aktivitas ini menunjukkan lamanya antrean, sedangkan durasi peninjauan menggambarkan efisiensi analis. Sumber data Peristiwa ini dapat disimpulkan saat analis mengambil atau membuka kasus dari antrean peninjauan. Sistem mungkin mencatatnya secara eksplisit dalam jejak audit ketika status kasus berubah menjadi 'In Review' atau kasus ditugaskan kepada pengguna tertentu. Pengumpulan data Disimpulkan dari perubahan status kasus menjadi 'Under Review' atau penugasan kasus kepada analis. Jenis peristiwa inferred
	Penyaringan selesai, kecocokan ditemukan	Kasus penyaringan resmi ditutup dengan hasil 'Match Found', yang menunjukkan bahwa risiko telah dikonfirmasi. Keputusan ini memicu proses lanjutan yang berbeda, seperti uji tuntas yang ditingkatkan atau penolakan.
Mengapa ini penting Ini merupakan titik akhir utama untuk jalur penyaringan yang tidak berjalan sesuai harapan. Analisis kasus-kasus ini membantu memahami profil risiko dan efektivitas kontrol penyaringan. Sumber data Disimpulkan dari perubahan status akhir kasus menjadi 'Match Found', 'Risk Identified', atau 'Closed - Positive'. Stempel waktu perubahan status terakhir digunakan. Pengumpulan data Diambil dari stempel waktu status akhir kasus yang menunjukkan kecocokan telah dikonfirmasi. Jenis peristiwa inferred
	Penyaringan selesai, tidak ada kecocokan	Kasus penyaringan resmi ditutup dengan hasil 'Clear', yang berarti tidak ditemukan kecocokan sebenarnya. Keputusan ini dikirim kembali ke sistem asal agar proses penerimaan pelanggan dapat dilanjutkan.
Mengapa ini penting Aktivitas ini menandai penyelesaian proses penyaringan yang berjalan sesuai harapan. Tahap ini menjadi titik akhir utama untuk mengukur siklus proses pengajuan standar berisiko rendah. Sumber data Disimpulkan dari perubahan status akhir kasus menjadi 'Clear', 'Complete', atau 'Closed - No Match'. Stempel waktu perubahan status terakhir digunakan. Pengumpulan data Diambil dari stempel waktu status akhir kasus yang menunjukkan hasil bersih. Jenis peristiwa inferred
	Permintaan Pemeriksaan Dibuat	Kasus pemeriksaan baru dibuat secara resmi untuk pengajuan nasabah di sistem Refinitiv World-Check. Proses ini dipicu oleh panggilan API atau entri manual dari sistem sebelumnya dan menandai dimulainya pemeriksaan informasi risiko.
Mengapa ini penting Menandai dimulainya subproses penyaringan secara resmi. Jeda antara Application Submitted dan aktivitas ini menunjukkan keterlambatan serah terima antara sistem unit bisnis dan fungsi kepatuhan. Sumber data Tercatat dalam log manajemen kasus atau jejak audit World-Check. Data yang digunakan adalah peristiwa pembuatan beserta stempel waktunya untuk ID kasus atau entitas terkait. Pengumpulan data Dicatat otomatis saat kasus penyaringan baru dibuat di sistem. Jenis peristiwa explicit
	Rekening diaktifkan	Rekening pelanggan dibuat dan diaktifkan di sistem inti, sehingga proses penerimaan pelanggan selesai. Tahap ini berlangsung setelah pengajuan disetujui dan rekening siap digunakan.
Mengapa ini penting Ini adalah langkah terakhir dalam proses yang memberikan nilai. Durasi dari pengajuan hingga aktivasi rekening menjadi metrik penting untuk mengukur efisiensi operasional dan kepuasan pelanggan. Sumber data Peristiwa ini tidak dicatat di World-Check. Data tersimpan di sistem perbankan inti atau sistem rekening pelanggan dan harus dicocokkan menggunakan Customer Application ID. Pengumpulan data Peristiwa dicatat di sistem rekening inti saat rekening diaktifkan. Jenis peristiwa explicit
	Informasi tambahan diminta	Analis memutuskan bahwa informasi tambahan diperlukan untuk memastikan kemungkinan kecocokan, lalu memintanya dari unit bisnis. Kasus berstatus tertunda sampai informasi tersebut diberikan.
Mengapa ini penting Jika aktivitas ini sering terjadi, kemungkinan ada masalah pada kualitas data awal yang diberikan untuk penyaringan. Aktivitas ini dapat menambah keterlambatan karena bergantung pada tim lain, dan menjadi salah satu penyebab utama siklus proses yang panjang. Sumber data Permintaan ini mungkin dicatat sebagai tindakan pengguna dalam catatan kasus atau log audit. Alternatifnya, peristiwa ini dapat disimpulkan dari perubahan status kasus menjadi 'Pending Information' atau 'RFI'. Pengumpulan data Dicatat saat analis menggunakan fitur untuk menandai bahwa kasus memerlukan informasi tambahan. Jenis peristiwa explicit
	Kasus dieskalasikan untuk ditinjau	Analis tingkat pertama meneruskan kasus yang rumit atau berisiko tinggi kepada analis senior atau manajer untuk keputusan akhir. Ini merupakan titik serah terima penting dalam tim kepatuhan.
Mengapa ini penting Eskalasi sering menimbulkan hambatan dan memperpanjang siklus proses. Analisis frekuensi dan alasan eskalasi dapat menunjukkan kebutuhan pelatihan bagi analis junior atau ketidakjelasan kebijakan peninjauan. Sumber data Dicatat sebagai tindakan eksplisit dalam alur kerja kasus atau jejak audit. Peristiwa ini juga dapat disimpulkan dari perubahan pengguna yang ditugaskan ke kasus, terutama jika kasus dialihkan kepada pengguna dengan izin lebih tinggi. Pengumpulan data Dicatat melalui tombol khusus 'Escalate' atau tindakan alur kerja di dalam kasus. Jenis peristiwa explicit
	Kemungkinan kecocokan ditemukan	Proses penyaringan otomatis menemukan satu atau beberapa kemungkinan kecocokan yang perlu ditinjau oleh analis. Peristiwa ini mengalihkan kasus dari tahap otomatis ke antrean pemeriksaan manual.
Mengapa ini penting Aktivitas ini menjadi titik percabangan penting dalam proses. Kasus dengan kemungkinan kecocokan menempuh jalur yang lebih panjang dan rumit. Pelacakan tahap ini membantu perencanaan sumber daya dan analisis hambatan bagi tim peninjau. Sumber data Disimpulkan dari perubahan status kasus menjadi 'Review Required', 'Potential Match', atau status serupa di modul manajemen kasus World-Check. Pengumpulan data Disimpulkan dari perubahan status kasus yang menunjukkan bahwa peninjauan manual diperlukan. Jenis peristiwa inferred
	Pengajuan disetujui	Pengajuan pelanggan telah disetujui sepenuhnya setelah penyaringan KYC berhasil dan pemeriksaan lain yang diwajibkan selesai. Peristiwa ini biasanya terjadi di sistem sumber setelah sistem menerima hasil 'Clear' dari World-Check.
Mengapa ini penting Menandai hasil bisnis yang berhasil dari proses penerimaan pelanggan. Waktu dari pengajuan hingga tahap ini menunjukkan total waktu yang diperlukan untuk menyetujui pelanggan baru. Sumber data Peristiwa ini tidak berasal dari World-Check. Data harus diambil dari CRM hulu atau sistem aplikasi inti yang membuat keputusan bisnis akhir. Pengumpulan data Peristiwa dicatat di sistem aplikasi sumber setelah persetujuan akhir. Jenis peristiwa explicit
	Penyaringan otomatis dilakukan	Sistem World-Check secara otomatis mencocokkan detail pelanggan dengan basis data intelijen risikonya. Aktivitas yang dijalankan sistem ini menghasilkan temuan awal, seperti kemungkinan kecocokan atau status bersih.
Mengapa ini penting Aktivitas ini merupakan langkah pertama dalam proses penyaringan yang menghasilkan nilai. Keterlambatan sebelum tahap ini menunjukkan masalah kesiapan sistem atau data, sedangkan hasilnya menentukan beban kerja manual berikutnya. Sumber data Peristiwa ini mungkin dicatat secara eksplisit dalam jejak audit kasus, atau disimpulkan dari stempel waktu saat hasil penyaringan awal tersedia untuk kasus tersebut. Pengumpulan data Entri log sistem yang dibuat setelah pemindaian basis data otomatis selesai. Jenis peristiwa explicit
	Positif palsu dikonfirmasi	Analis menyimpulkan bahwa kemungkinan kecocokan tersebut bukan pelanggan yang sedang diperiksa. Kecocokan ditolak dan proses penyaringan untuk peringatan tersebut dinyatakan selesai.
Mengapa ini penting Ini merupakan hasil yang umum dari proses peninjauan. Dengan mengukur waktu yang diperlukan untuk menetapkan hasil positif palsu, Anda dapat menilai efisiensi analis dan ketepatan logika penyaringan otomatis. Sumber data Ini adalah tindakan eksplisit pengguna. Analis menetapkan hasil kecocokan tertentu sebagai 'False Positive' atau 'Not a Match'. Tindakan ini biasanya dicatat dalam riwayat kasus. Pengumpulan data Dicatat saat analis secara resmi menolak kemungkinan kecocokan di sistem. Jenis peristiwa explicit

Disarankan Opsional

Panduan ekstraksi

Cara mengambil data dari Refinitiv World-Check

Langkah

Masuk ke World-Check One: Buka portal Refinitiv World-Check One menggunakan kredensial Anda.
Buka Manajemen Kasus: Masuk ke bagian Manajemen Kasus, tempat semua kasus penyaringan disimpan dan dikelola.
Siapkan ekspor laporan kasus: Buka fitur pelaporan atau ekspor di Manajemen Kasus. Namanya mungkin 'Ekspor Kasus' atau 'Laporan Kasus'.
Atur laporan kasus: Pilih kolom yang akan disertakan. Pastikan Anda memilih kolom untuk ID Kasus (CustomerApplication), tanggal pembuatan, tanggal penyelesaian, status kasus (misalnya, Clear, Match Found), dan tingkat risiko.
Ekspor data Manajemen Kasus: Tentukan rentang tanggal, biasanya mencakup aktivitas 3 hingga 6 bulan terakhir. Terapkan filter yang diperlukan, misalnya berdasarkan grup pengguna atau jenis kasus. Ekspor data sebagai file CSV dan beri nama case_report.csv.
Siapkan ekspor jejak audit: Buka bagian pelaporan jejak audit atau log audit di World-Check One. Bagian ini berisi riwayat peristiwa terperinci untuk setiap kasus.
Atur dan ekspor jejak audit: Pilih semua kolom yang relevan, termasuk ID Kasus, nama atau deskripsi peristiwa, waktu peristiwa, dan pengguna yang melakukan tindakan. Ekspor data untuk rentang tanggal yang sama dengan laporan kasus. Simpan file sebagai audit_trail.csv.
Ambil data tahapan proses eksternal: Dapatkan data aktivitas yang terjadi di luar World-Check, seperti Application Submitted, Application Approved, Account Activated, dan Application Rejected. Data ini biasanya berasal dari CRM atau sistem perbankan inti. Ekspor data dengan ID CustomerApplication dan waktu yang relevan.
Gabungkan dan transformasikan data: Muat file CSV yang diekspor (case_report.csv, audit_trail.csv, dan data dari sistem eksternal) ke alat atau skrip persiapan data.
Petakan peristiwa audit ke aktivitas: Olah file audit_trail.csv. Petakan deskripsi peristiwa mentah dari log audit ke nilai ActivityName yang sudah distandardisasi. Contohnya, entri log audit 'Case Assigned to Analyst' menjadi 'Analyst Review Started'.
Petakan perubahan status kasus ke aktivitas: Olah file case_report.csv untuk membuat aktivitas berdasarkan perubahan status. Gunakan tanggal penyelesaian kasus dan status akhir untuk membuat peristiwa 'Screening Completed - Clear' atau 'Screening Completed - Match Found'.
Buat log peristiwa akhir: Gabungkan semua data yang telah diolah dari berbagai file sumber ke dalam satu file CSV. Pastikan file akhir memuat kolom wajib CustomerApplication, ActivityName, dan EventTime, serta atribut lain yang disarankan. Simpan file ini untuk diunggah ke alat process mining.

Konfigurasi

Jenis laporan: Buat setidaknya dua laporan terpisah, yaitu laporan ringkasan Manajemen Kasus dan laporan Jejak Audit terperinci.
Rentang tanggal: Untuk analisis awal, pilih rentang 3-6 bulan agar mencakup cukup banyak kasus yang sudah selesai maupun yang masih berjalan. Pastikan rentang tanggal sama untuk semua file yang diekspor.
Format ekspor: Pilih CSV (Comma Separated Values) agar data mudah diolah.
Kolom utama (laporan kasus): Pastikan ekspor kasus memuat ID Kasus, Waktu Pembuatan, Waktu Penyelesaian, Status Akhir, Analis yang Ditugaskan, dan Tingkat Risiko.
Kolom utama (laporan jejak audit): Pastikan ekspor log audit memuat ID Kasus, Deskripsi Peristiwa, Waktu Peristiwa, dan ID Pengguna.
Prasyarat: Anda memerlukan akses ke portal World-Check One dengan izin pengguna untuk melihat dan mengekspor data manajemen kasus serta log audit. Anda mungkin memerlukan hak akses lebih tinggi daripada peran analis standar.

Contoh kueri sql

/*
This is a configuration and mapping guide, not an executable script. 
The process relies on manually exporting two reports from World-Check One and combining them with data from an upstream system (e.g., CRM).
*/

-- Step 1: Export 'Case Management Report' as case_report.csv
-- Step 2: Export 'Audit Trail Report' as audit_trail.csv
-- Step 3: Export relevant events from CRM/core system as source_system_events.csv

-- Step 4: Combine and map the files using a script or ETL tool to create the final event log.

-- Mapping logic for final_event_log.csv

-- Part A: Data from source_system_events.csv
SELECT
  ApplicationID AS CustomerApplication,
  'Application Submitted' AS ActivityName,
  SubmissionTimestamp AS EventTime,
  NULL AS EventEndTime,
  OriginatorID AS ReviewerId,
  OriginatingDept AS DepartmentName,
  RiskRating AS RiskLevel,
  SlaDate AS SlaTargetDate
FROM source_system_events.csv
WHERE EventType = 'Submission'

UNION ALL

SELECT
  ApplicationID AS CustomerApplication,
  'Application Approved' AS ActivityName,
  ApprovalTimestamp AS EventTime,
  NULL AS EventEndTime,
  ApproverID AS ReviewerId,
  ApprovingDept AS DepartmentName,
  RiskRating AS RiskLevel,
  SlaDate AS SlaTargetDate
FROM source_system_events.csv
WHERE EventType = 'Approval'

UNION ALL

SELECT
  ApplicationID AS CustomerApplication,
  'Account Activated' AS ActivityName,
  ActivationTimestamp AS EventTime,
  NULL AS EventEndTime,
  'SYSTEM' AS ReviewerId,
  'Operations' AS DepartmentName,
  RiskRating AS RiskLevel,
  SlaDate AS SlaTargetDate
FROM source_system_events.csv
WHERE EventType = 'Activation'

UNION ALL

SELECT
  ApplicationID AS CustomerApplication,
  'Application Rejected' AS ActivityName,
  RejectionTimestamp AS EventTime,
  NULL AS EventEndTime,
  ReviewerID AS ReviewerId,
  'Compliance' AS DepartmentName,
  RiskRating AS RiskLevel,
  SlaDate AS SlaTargetDate
FROM source_system_events.csv
WHERE EventType = 'Rejection'

-- Part B: Data from World-Check audit_trail.csv
UNION ALL

SELECT
  CaseID AS CustomerApplication,
  'Screening Request Created' AS ActivityName,
  EventTimestamp AS EventTime,
  NULL AS EventEndTime,
  UserID AS ReviewerId,
  'Compliance' AS DepartmentName,
  NULL AS RiskLevel,
  NULL AS SlaTargetDate
FROM audit_trail.csv
WHERE EventDescription LIKE '%Case Created%'

UNION ALL

SELECT
  CaseID AS CustomerApplication,
  'Automated Screening Performed' AS ActivityName,
  EventTimestamp AS EventTime,
  NULL AS EventEndTime,
  'SYSTEM' AS ReviewerId,
  'Compliance' AS DepartmentName,
  NULL AS RiskLevel,
  NULL AS SlaTargetDate
FROM audit_trail.csv
WHERE EventDescription LIKE '%Automated Screening Completed%'

UNION ALL

SELECT
  CaseID AS CustomerApplication,
  'Potential Match Identified' AS ActivityName,
  EventTimestamp AS EventTime,
  NULL AS EventEndTime,
  'SYSTEM' AS ReviewerId,
  'Compliance' AS DepartmentName,
  NULL AS RiskLevel,
  NULL AS SlaTargetDate
FROM audit_trail.csv
WHERE EventDescription LIKE '%Potential Match Found%'

UNION ALL

SELECT
  CaseID AS CustomerApplication,
  'Analyst Review Started' AS ActivityName,
  EventTimestamp AS EventTime,
  NULL AS EventEndTime,
  UserID AS ReviewerId,
  'Compliance' AS DepartmentName,
  NULL AS RiskLevel,
  NULL AS SlaTargetDate
FROM audit_trail.csv
WHERE EventDescription LIKE '%Case Assigned%' OR EventDescription LIKE '%Review Started%'

UNION ALL

SELECT
  CaseID AS CustomerApplication,
  'Additional Information Requested' AS ActivityName,
  EventTimestamp AS EventTime,
  NULL AS EventEndTime,
  UserID AS ReviewerId,
  'Compliance' AS DepartmentName,
  NULL AS RiskLevel,
  NULL AS SlaTargetDate
FROM audit_trail.csv
WHERE EventDescription LIKE '%Information Requested%'

UNION ALL

SELECT
  CaseID AS CustomerApplication,
  'Case Escalated for Review' AS ActivityName,
  EventTimestamp AS EventTime,
  NULL AS EventEndTime,
  UserID AS ReviewerId,
  'Compliance' AS DepartmentName,
  NULL AS RiskLevel,
  NULL AS SlaTargetDate
FROM audit_trail.csv
WHERE EventDescription LIKE '%Case Escalated%'

UNION ALL

SELECT
  CaseID AS CustomerApplication,
  'False Positive Confirmed' AS ActivityName,
  EventTimestamp AS EventTime,
  NULL AS EventEndTime,
  UserID AS ReviewerId,
  'Compliance' AS DepartmentName,
  NULL AS RiskLevel,
  NULL AS SlaTargetDate
FROM audit_trail.csv
WHERE EventDescription LIKE '%Match Dismissed as False Positive%'

UNION ALL

SELECT
  CaseID AS CustomerApplication,
  'True Match Confirmed' AS ActivityName,
  EventTimestamp AS EventTime,
  NULL AS EventEndTime,
  UserID AS ReviewerId,
  'Compliance' AS DepartmentName,
  NULL AS RiskLevel,
  NULL AS SlaTargetDate
FROM audit_trail.csv
WHERE EventDescription LIKE '%Match Confirmed as True%'

-- Part C: Data from World-Check case_report.csv
UNION ALL

SELECT
  CaseID AS CustomerApplication,
  'Screening Completed - Clear' AS ActivityName,
  ResolutionTimestamp AS EventTime,
  NULL AS EventEndTime,
  ResolverID AS ReviewerId,
  'Compliance' AS DepartmentName,
  RiskLevel AS RiskLevel,
  NULL AS SlaTargetDate
FROM case_report.csv
WHERE FinalStatus = 'Clear'

UNION ALL

SELECT
  CaseID AS CustomerApplication,
  'Screening Completed - Match Found' AS ActivityName,
  ResolutionTimestamp AS EventTime,
  NULL AS EventEndTime,
  ResolverID AS ReviewerId,
  'Compliance' AS DepartmentName,
  RiskLevel AS RiskLevel,
  NULL AS SlaTargetDate
FROM case_report.csv
WHERE FinalStatus = 'Match Found'

Langkah

Prasyarat dan penyiapan: Pastikan Python 3.6+ sudah terpasang bersama pustaka requests dan pandas. Dapatkan API Key dan API Secret World-Check One dari perwakilan Refinitiv atau portal pengembang. Simpan kredensial ini dengan aman.
Buat logika autentikasi: Dalam skrip Python, buat fungsi untuk mengirim permintaan POST ke endpoint autentikasi World-Check One. Gunakan API Key dan Secret untuk mendapatkan token bearer sementara yang diperlukan untuk panggilan API berikutnya.
Identifikasi data sistem sumber: Proses dimulai dan berakhir di luar World-Check. Identifikasi sistem sumber, seperti CRM atau platform perbankan inti, yang menyimpan data awal permohonan. Anda perlu mengekstrak peristiwa seperti Application Submitted, Application Approved, Account Activated, dan Application Rejected dari sistem tersebut. Anda dapat melakukannya melalui kueri database atau API lain.
Ambil kasus World-Check: Gunakan token autentikasi untuk mengirim permintaan GET ke endpoint /cases pada API World-Check One. Gunakan parameter kueri untuk memfilter kasus berdasarkan rentang tanggal tertentu, misalnya tanggal pembuatan atau perubahan.
Tangani paginasi API: Respons API World-Check dibagi ke beberapa halaman. Skrip harus memeriksa detail paginasi dalam respons dan menelusuri semua halaman untuk mengambil seluruh daftar kasus dalam rentang tanggal yang ditentukan.
Ambil detail dan riwayat kasus: Untuk setiap ID kasus yang diperoleh, kirim permintaan GET berikutnya ke endpoint seperti /cases/{case_system_id} dan /cases/{case_system_id}/audit-trail. Endpoint ini menyediakan detail perubahan status, penyelesaian, dan tindakan pengguna yang terkait dengan kasus.
Petakan data mentah ke aktivitas: Ini tahap transformasi yang penting. Buat logika untuk menelusuri data respons API (detail kasus dan jejak audit) setiap kasus. Petakan perubahan status, kode hasil, dan peristiwa audit tertentu ke aktivitas bisnis yang diperlukan. Contohnya, peristiwa pembuatan kasus menjadi Screening Request Created, sedangkan hasil penyelesaian False Positive menjadi False Positive Confirmed.
Gabungkan sumber data: Gabungkan data yang diambil dari World-Check dengan data dari sistem sumber Anda (dari langkah 3). Gunakan ID CustomerApplication sebagai kunci bersama untuk membuat log peristiwa menyeluruh bagi setiap pelanggan.
Susun dan perkaya data: Satukan semua peristiwa yang telah dipetakan ke dalam satu daftar catatan. Pastikan setiap catatan memuat semua atribut wajib (CustomerApplication, ActivityName, EventTime) dan atribut yang disarankan. Jika memungkinkan, hitung EventEndTime, misalnya dengan menggunakan waktu peristiwa berikutnya untuk kasus tersebut.
Ekspor ke CSV: Ubah daftar catatan peristiwa akhir menjadi pandas DataFrame. Susun ulang kolom sesuai format yang diwajibkan, lalu ekspor DataFrame ke file CSV. Simpan file dengan encoding UTF-8 agar kompatibel dengan ProcessMind.

Konfigurasi

Kredensial API: Anda memerlukan API Key dan API Secret yang valid untuk Screening API World-Check One. Kredensial ini harus memiliki izin yang diperlukan untuk membaca data kasus dan audit.
URL dasar API: Atur skrip dengan URL dasar yang benar untuk lingkungan API World-Check Anda, misalnya https://api.world-check.com/v2/.
Rentang tanggal: Tambahkan parameter start_date dan end_date ke skrip untuk menentukan periode ekstraksi. Untuk analisis awal, disarankan rentang 3 hingga 6 bulan. Untuk pemantauan rutin, jalankan skrip secara bertahap untuk periode yang lebih singkat, seperti hari atau minggu sebelumnya.
Koneksi sistem sumber: Anda memerlukan detail koneksi ke sistem hulu dan hilir, misalnya CRM atau platform perbankan inti, untuk mengambil peristiwa di luar penyaringan. Detail ini dapat berupa string koneksi database atau endpoint API beserta kredensialnya.
Penanganan paginasi: Saat memanggil API untuk membuat daftar kasus, skrip harus menentukan ukuran halaman, yang sering disebut limit. Nilai antara 50 dan 100 biasanya efisien. Logika skrip harus mengambil semua halaman dengan benar.

Contoh kueri python

import requests
import pandas as pd
from datetime import datetime, timedelta

class=class="hl-string">"hl-comment"># --- Configuration and Placeholders ---
WC_API_KEY = class="hl-string">'[Your World-Check API Key]'
WC_API_SECRET = class="hl-string">'[Your World-Check API Secret]'
WC_API_BASE_URL = class="hl-string">'https://api.world-check.com/v2' class=class="hl-string">"hl-comment"># Use correct URL for your environment

class=class="hl-string">"hl-comment"># Date range for the extraction
START_DATE = (datetime.now() - timedelta(days=90)).strftime(class="hl-string">'%Y-%m-%dT%H:%M:%SZ')
END_DATE = datetime.now().strftime(class="hl-string">'%Y-%m-%dT%H:%M:%SZ')

class=class="hl-string">"hl-comment"># --- MOCK FUNCTIONS (Replace with actual data source connections) ---

def get_source_system_events(application_ids):
    class="hl-string">"""Simulates fetching pre- and post-screening events from a CRM or core system."""
    print(fclass="hl-string">'Fetching source system events for {len(application_ids)} applications...')
    mock_events = []
    for i, app_id in enumerate(application_ids):
        class=class="hl-string">"hl-comment"># Simulate initial application events
        mock_events.append({class="hl-string">'CustomerApplication': app_id, class="hl-string">'ActivityName': class="hl-string">'Application Submitted', class="hl-string">'EventTime': (datetime.now() - timedelta(days=i+5)).isoformat() + class="hl-string">'Z', class="hl-string">'DepartmentName': class="hl-string">'Sales'})
        class=class="hl-string">"hl-comment"># Simulate final outcome events
        if i % 3 == 0:
            mock_events.append({class="hl-string">'CustomerApplication': app_id, class="hl-string">'ActivityName': class="hl-string">'Application Approved', class="hl-string">'EventTime': (datetime.now() - timedelta(days=i)).isoformat() + class="hl-string">'Z', class="hl-string">'DepartmentName': class="hl-string">'Onboarding'})
            mock_events.append({class="hl-string">'CustomerApplication': app_id, class="hl-string">'ActivityName': class="hl-string">'Account Activated', class="hl-string">'EventTime': (datetime.now() - timedelta(days=i-1)).isoformat() + class="hl-string">'Z', class="hl-string">'DepartmentName': class="hl-string">'Operations'})
        else:
            mock_events.append({class="hl-string">'CustomerApplication': app_id, class="hl-string">'ActivityName': class="hl-string">'Application Rejected', class="hl-string">'EventTime': (datetime.now() - timedelta(days=i)).isoformat() + class="hl-string">'Z', class="hl-string">'DepartmentName': class="hl-string">'Compliance'})
    return mock_events

def get_worldcheck_cases(token):
    class="hl-string">"""Simulates fetching a list of cases from the World-Check API."""
    print(class="hl-string">'Fetching World-Check cases...')
    class=class="hl-string">"hl-comment"># In a real implementation, you would call GET /cases with date filters and handle pagination
    mock_case_list = [
        {class="hl-string">'caseId': class="hl-string">'0a1b2c3d-case-001', class="hl-string">'name': class="hl-string">'John Doe', class="hl-string">'caseSystemId': class="hl-string">'WC-001', class="hl-string">'customReference': class="hl-string">'APP-1001', class="hl-string">'creationDate': class="hl-string">'2023-10-01T10:00:00Z', class="hl-string">'riskLevel': class="hl-string">'Medium'},
        {class="hl-string">'caseId': class="hl-string">'0a1b2c3d-case-002', class="hl-string">'name': class="hl-string">'Jane Smith', class="hl-string">'caseSystemId': class="hl-string">'WC-002', class="hl-string">'customReference': class="hl-string">'APP-1002', class="hl-string">'creationDate': class="hl-string">'2023-10-02T11:30:00Z', class="hl-string">'riskLevel': class="hl-string">'Low'},
        {class="hl-string">'caseId': class="hl-string">'0a1b2c3d-case-003', class="hl-string">'name': class="hl-string">'Peter Jones', class="hl-string">'caseSystemId': class="hl-string">'WC-003', class="hl-string">'customReference': class="hl-string">'APP-1003', class="hl-string">'creationDate': class="hl-string">'2023-10-03T09:05:00Z', class="hl-string">'riskLevel': class="hl-string">'High'}
    ]
    return mock_case_list

def get_worldcheck_case_details(case_system_id, token):
    class="hl-string">"""Simulates fetching the audit trail and results for a single World-Check case."""
    print(fclass="hl-string">'Fetching details for case {case_system_id}...')
    class=class="hl-string">"hl-comment"># This mock data simulates a complex history for one case to generate multiple activities
    if case_system_id == class="hl-string">'WC-001':
        return {
            class="hl-string">'auditTrail': [
                {class="hl-string">'timestamp': class="hl-string">'2023-10-01T10:05:00Z', class="hl-string">'event': class="hl-string">'AUTOMATED_SCREENING', class="hl-string">'details': class="hl-string">'Screening performed', class="hl-string">'user': class="hl-string">'SYSTEM'},
                {class="hl-string">'timestamp': class="hl-string">'2023-10-01T10:06:00Z', class="hl-string">'event': class="hl-string">'MATCH_FOUND', class="hl-string">'details': class="hl-string">'Potential match identified', class="hl-string">'user': class="hl-string">'SYSTEM'},
                {class="hl-string">'timestamp': class="hl-string">'2023-10-02T14:00:00Z', class="hl-string">'event': class="hl-string">'REVIEW_STARTED', class="hl-string">'details': class="hl-string">'Case assigned', class="hl-string">'user': class="hl-string">'analyst1'},
                {class="hl-string">'timestamp': class="hl-string">'2023-10-02T15:30:00Z', class="hl-string">'event': class="hl-string">'MATCH_RESOLVED', class="hl-string">'details': class="hl-string">'Match resolved as False Positive', class="hl-string">'user': class="hl-string">'analyst1'},
                {class="hl-string">'timestamp': class="hl-string">'2023-10-03T11:00:00Z', class="hl-string">'event': class="hl-string">'ESCALATED', class="hl-string">'details': class="hl-string">'Case escalated to senior analyst', class="hl-string">'user': class="hl-string">'analyst1'},
                {class="hl-string">'timestamp': class="hl-string">'2023-10-04T09:00:00Z', class="hl-string">'event': class="hl-string">'INFORMATION_REQUESTED', class="hl-string">'details': class="hl-string">'Additional documents requested', class="hl-string">'user': class="hl-string">'senior_analyst'},
                {class="hl-string">'timestamp': class="hl-string">'2023-10-05T16:00:00Z', class="hl-string">'event': class="hl-string">'CASE_CLOSED', class="hl-string">'details': class="hl-string">'Case closed as Clear', class="hl-string">'user': class="hl-string">'senior_analyst'}
            ]
        }
    elif case_system_id == class="hl-string">'WC-003':
        return {
            class="hl-string">'auditTrail': [
                {class="hl-string">'timestamp': class="hl-string">'2023-10-03T09:10:00Z', class="hl-string">'event': class="hl-string">'AUTOMATED_SCREENING', class="hl-string">'details': class="hl-string">'Screening performed', class="hl-string">'user': class="hl-string">'SYSTEM'},
                {class="hl-string">'timestamp': class="hl-string">'2023-10-03T09:11:00Z', class="hl-string">'event': class="hl-string">'MATCH_FOUND', class="hl-string">'details': class="hl-string">'Potential match identified', class="hl-string">'user': class="hl-string">'SYSTEM'},
                {class="hl-string">'timestamp': class="hl-string">'2023-10-04T10:00:00Z', class="hl-string">'event': class="hl-string">'REVIEW_STARTED', class="hl-string">'details': class="hl-string">'Case assigned', class="hl-string">'user': class="hl-string">'analyst2'},
                {class="hl-string">'timestamp': class="hl-string">'2023-10-04T11:25:00Z', class="hl-string">'event': class="hl-string">'MATCH_RESOLVED', class="hl-string">'details': class="hl-string">'Match resolved as True Positive', class="hl-string">'user': class="hl-string">'analyst2'},
                {class="hl-string">'timestamp': class="hl-string">'2023-10-04T12:00:00Z', class="hl-string">'event': class="hl-string">'CASE_CLOSED', class="hl-string">'details': class="hl-string">'Case closed with matches', class="hl-string">'user': class="hl-string">'analyst2'}
            ]
        }
    else: class=class="hl-string">"hl-comment"># Simple class="hl-string">'Clear' case
        return {
            class="hl-string">'auditTrail': [
                {class="hl-string">'timestamp': class="hl-string">'2023-10-02T11:35:00Z', class="hl-string">'event': class="hl-string">'AUTOMATED_SCREENING', class="hl-string">'details': class="hl-string">'Screening performed', class="hl-string">'user': class="hl-string">'SYSTEM'},
                {class="hl-string">'timestamp': class="hl-string">'2023-10-02T11:36:00Z', class="hl-string">'event': class="hl-string">'CASE_CLOSED', class="hl-string">'details': class="hl-string">'Case closed as Clear', class="hl-string">'user': class="hl-string">'SYSTEM'}
            ]
        }

class=class="hl-string">"hl-comment"># --- Main Extraction Logic ---

def main():
    class="hl-string">"""Main function to run the extraction process."""
    class=class="hl-string">"hl-comment"># 1. Authenticate (real implementation)
    class=class="hl-string">"hl-comment"># token = get_wc_auth_token()
    token = class="hl-string">'mock_token' class=class="hl-string">"hl-comment"># Using a mock token for this example

    class=class="hl-string">"hl-comment"># 2. Get list of cases from World-Check
    cases = get_worldcheck_cases(token)
    if not cases:
        print(class="hl-string">'No cases found for the specified period.')
        return

    event_log = []

    class=class="hl-string">"hl-comment"># 3. Process each case from World-Check
    for case in cases:
        app_id = case.get(class="hl-string">'customReference')
        if not app_id:
            continue

        class=class="hl-string">"hl-comment"># Add class="hl-string">'Screening Request Created' event
        event_log.append({
            class="hl-string">'CustomerApplication': app_id,
            class="hl-string">'ActivityName': class="hl-string">'Screening Request Created',
            class="hl-string">'EventTime': case[class="hl-string">'creationDate'],
            class="hl-string">'ReviewerId': class="hl-string">'SYSTEM',
            class="hl-string">'DepartmentName': class="hl-string">'Compliance',
            class="hl-string">'RiskLevel': case.get(class="hl-string">'riskLevel')
        })

        details = get_worldcheck_case_details(case[class="hl-string">'caseSystemId'], token)
        for event in details.get(class="hl-string">'auditTrail', []):
            activity = None
            user = event.get(class="hl-string">'user', class="hl-string">'SYSTEM')
            department = class="hl-string">'Compliance' if user != class="hl-string">'SYSTEM' else class="hl-string">'System'
            
            class=class="hl-string">"hl-comment"># 4. Map audit trail events to activities
            if event[class="hl-string">'event'] == class="hl-string">'AUTOMATED_SCREENING':
                activity = class="hl-string">'Automated Screening Performed'
            elif event[class="hl-string">'event'] == class="hl-string">'MATCH_FOUND':
                activity = class="hl-string">'Potential Match Identified'
            elif event[class="hl-string">'event'] == class="hl-string">'REVIEW_STARTED':
                activity = class="hl-string">'Analyst Review Started'
            elif event[class="hl-string">'event'] == class="hl-string">'INFORMATION_REQUESTED':
                activity = class="hl-string">'Additional Information Requested'
            elif event[class="hl-string">'event'] == class="hl-string">'ESCALATED':
                activity = class="hl-string">'Case Escalated for Review'
            elif event[class="hl-string">'event'] == class="hl-string">'MATCH_RESOLVED' and class="hl-string">'False Positive' in event[class="hl-string">'details']:
                activity = class="hl-string">'False Positive Confirmed'
            elif event[class="hl-string">'event'] == class="hl-string">'MATCH_RESOLVED' and class="hl-string">'True Positive' in event[class="hl-string">'details']:
                activity = class="hl-string">'True Match Confirmed'
            elif event[class="hl-string">'event'] == class="hl-string">'CASE_CLOSED' and class="hl-string">'Clear' in event[class="hl-string">'details']:
                activity = class="hl-string">'Screening Completed - Clear'
            elif event[class="hl-string">'event'] == class="hl-string">'CASE_CLOSED' and class="hl-string">'matches' in event[class="hl-string">'details']:
                activity = class="hl-string">'Screening Completed - Match Found'

            if activity:
                event_log.append({
                    class="hl-string">'CustomerApplication': app_id,
                    class="hl-string">'ActivityName': activity,
                    class="hl-string">'EventTime': event[class="hl-string">'timestamp'],
                    class="hl-string">'ReviewerId': user,
                    class="hl-string">'DepartmentName': department,
                    class="hl-string">'RiskLevel': case.get(class="hl-string">'riskLevel')
                })
    
    class=class="hl-string">"hl-comment"># 5. Get events from source system
    application_ids = [case[class="hl-string">'customReference'] for case in cases if case.get(class="hl-string">'customReference')]
    source_events = get_source_system_events(application_ids)
    event_log.extend(source_events)

    class=class="hl-string">"hl-comment"># 6. Create and format DataFrame
    if not event_log:
        print(class="hl-string">'No events were generated.')
        return

    df = pd.DataFrame(event_log)
    df[class="hl-string">'EventTime'] = pd.to_datetime(df[class="hl-string">'EventTime'])
    df = df.sort_values(by=[class="hl-string">'CustomerApplication', class="hl-string">'EventTime'])

    class=class="hl-string">"hl-comment"># Add EventEndTime by shifting the EventTime of the next event
    df[class="hl-string">'EventEndTime'] = df.groupby(class="hl-string">'CustomerApplication')[class="hl-string">'EventTime'].shift(-1)
    
    class=class="hl-string">"hl-comment"># Add placeholder for non-extractable attribute
    df[class="hl-string">'SlaTargetDate'] = pd.NaT

    class=class="hl-string">"hl-comment"># 7. Finalize and Export
    output_columns = [
        class="hl-string">'CustomerApplication',
        class="hl-string">'ActivityName',
        class="hl-string">'EventTime',
        class="hl-string">'EventEndTime',
        class="hl-string">'ReviewerId',
        class="hl-string">'DepartmentName',
        class="hl-string">'RiskLevel',
        class="hl-string">'SlaTargetDate'
    ]
    class=class="hl-string">"hl-comment"># Ensure all required columns exist, even if empty
    for col in output_columns:
        if col not in df.columns:
            df[col] = None
    
    df = df[output_columns]

    output_filename = class="hl-string">'event_log_worldcheck.csv'
    df.to_csv(output_filename, index=False, date_format=class="hl-string">'%Y-%m-%dT%H:%M:%S.%fZ')
    print(fclass="hl-string">'Successfully exported event log to {output_filename}')

if __name__ == class="hl-string">'__main__':
    main()

Siap memulai?

Gunakan templat data ini untuk memulai process mining pada proses onboarding pelanggan KYC. Ikuti panduan ini untuk menemukan wawasan yang berguna dan meningkatkan operasional secara nyata.

Kembali ke panduan perbaikan

Unduh template

Optimalkan onboarding pelanggan KYC sekarang dan tingkatkan kepatuhan

Wujudkan onboarding pelanggan yang lancar dan persingkat proses hingga hanya 24 jam.

Mulai uji coba gratis

Tidak perlu kartu kredit. Nikmati akses gratis selama 14 hari.

Templat data onboarding pelanggan KYC Anda

Templat data onboarding pelanggan KYC Anda

Atribut onboarding pelanggan KYC

Aktivitas onboarding pelanggan KYC

Panduan ekstraksi

Ekspor kasus dan log audit Refinitiv World-Check One

Langkah

Konfigurasi

Contoh kueri sql

Skrip Python menggunakan Screening API World-Check One

Langkah

Konfigurasi

Contoh kueri python

Siap memulai?

Optimalkan onboarding pelanggan KYC sekarang dan tingkatkan kepatuhan