> Cải tiến quy trình liên tục > Tiếp nhận khách hàng KYC > Refinitiv World Check > Mẫu dữ liệu

Mẫu dữ liệu onboarding khách hàng KYC

Refinitiv World-Check

Thuộc tính onboarding khách hàng KYC(19) Hoạt động onboarding khách hàng KYC(14) Hướng dẫn trích xuất(2)

Mẫu dữ liệu onboarding khách hàng KYC

Mẫu này hướng dẫn bạn thu thập dữ liệu cần thiết để phân tích quy trình onboarding khách hàng KYC. Mẫu nêu rõ các thuộc tính quan trọng cần ghi nhận, những hoạt động chính cần theo dõi và cách trích xuất thông tin từ hệ thống nguồn. Hãy dùng tài nguyên này để chuẩn bị đủ dữ liệu cho việc phân tích và cải tiến quy trình.

Các thuộc tính nên thu thập
Các hoạt động chính cần theo dõi
Hướng dẫn trích xuất

Chưa quen với nhật ký sự kiện? Tìm hiểu cách tạo nhật ký sự kiện cho process mining.

Tải mẫu xuống

Thuộc tính onboarding khách hàng KYC

Đây là các trường dữ liệu nên có trong nhật ký sự kiện để phân tích quy trình onboarding khách hàng KYC.

3 Bắt buộc 5 Nên có 11 Không bắt buộc

	Tên	Mô tả
	Đơn đăng ký khách hàng CustomerApplication	Mã định danh duy nhất cho đơn đăng ký tiếp nhận của một khách hàng, dùng làm mã hồ sơ chính.
Mô tả Mã đơn đăng ký khách hàng là mã hồ sơ trung tâm, dùng để nhóm tất cả sự kiện và hoạt động trong hành trình tiếp nhận một khách hàng. Mã này giúp theo dõi đầy đủ tiến trình của từng khách hàng theo thứ tự thời gian trong toàn bộ quy trình xác minh danh tính khách hàng (KYC), từ lúc gửi đơn ban đầu đến khi có quyết định cuối cùng. Trong phân tích process mining, thuộc tính này là nền tảng để tái dựng hành trình từ đầu đến cuối của từng đơn đăng ký. Thuộc tính này giúp trực quan hóa luồng quy trình, tính tổng thời gian xử lý và xác định các biến thể. Khi phân tích các hồ sơ được nhóm theo mã này, tổ chức có thể hiểu những lộ trình khác nhau mà một đơn đăng ký có thể đi qua, xác định điểm nghẽn và so sánh hiệu quả của các quy trình tiếp nhận khách hàng. Vì sao điều này quan trọng Đây là mã hồ sơ thiết yếu, liên kết mọi hoạt động liên quan để có thể phân tích quy trình tiếp nhận khách hàng từ đầu đến cuối. Lấy dữ liệu ở đâu Mã này thường là khóa chính trong bảng đơn đăng ký chính hoặc bảng quản lý hồ sơ của hệ thống Refinitiv World-Check hay CRM được tích hợp. Ví dụ APP-2023-00123APP-2023-00124APP-2023-00125
	Tên hoạt động ActivityName	Tên của một sự kiện kinh doanh hoặc tác vụ cụ thể diễn ra trong quy trình tiếp nhận khách hàng KYC.
Mô tả Tên hoạt động mô tả một bước hoặc sự kiện trong hành trình tiếp nhận khách hàng, chẳng hạn như 'Đã gửi đơn đăng ký', 'Bắt đầu chuyên viên phân tích xem xét' hoặc 'Hoàn tất sàng lọc, không có vấn đề'. Các hoạt động này tạo thành các nút trên sơ đồ quy trình, thể hiện chi tiết quy trình làm việc từ đầu đến cuối. Phân tích hoạt động là trọng tâm của process mining. Bằng cách theo dõi trình tự và tần suất của các hoạt động, chuyên viên phân tích có thể khám phá luồng quy trình thực tế, xác định các lộ trình phổ biến, phát hiện sai lệch so với quy trình chuẩn và tìm ra những bước gây chậm trễ hoặc phải làm lại. Thuộc tính này rất cần thiết để xây dựng sơ đồ quy trình và tính các chỉ số ở cấp hoạt động. Vì sao điều này quan trọng Thuộc tính này xác định từng bước riêng lẻ của quy trình, rất cần thiết để khám phá, trực quan hóa luồng quy trình và xác định điểm nghẽn. Lấy dữ liệu ở đâu Thông tin này thường có trong nhật ký sự kiện hoặc bảng dấu vết kiểm toán, thường gắn với các lần thay đổi trạng thái trong hồ sơ quản lý. Ví dụ Phát hiện trường hợp có khả năng trùng khớpBắt đầu chuyên viên phân tích xem xétXác nhận kết quả trùng khớp giảĐơn đăng ký được phê duyệt
	Thời điểm sự kiện EventTime	Dấu thời gian cho biết thời điểm một hoạt động hoặc sự kiện cụ thể diễn ra.
Mô tả Thời điểm sự kiện cho biết chính xác ngày giờ một hoạt động được ghi nhận. Dấu thời gian này làm cơ sở sắp xếp các sự kiện theo thứ tự để tái dựng lịch sử hồ sơ. Thuộc tính này rất quan trọng đối với mọi phân tích theo thời gian trong process mining. Thuộc tính được dùng để tính thời lượng giữa các hoạt động, gồm thời gian xử lý và thời gian chờ, đo tổng thời gian xử lý hồ sơ, phân tích hiệu suất quy trình theo thời gian và kiểm tra việc tuân thủ thỏa thuận mức dịch vụ (SLA). Nếu dấu thời gian không chính xác, bạn không thể hiểu hiệu suất quy trình hoặc xác định điểm nghẽn theo thời gian. Vì sao điều này quan trọng Dấu thời gian của từng hoạt động rất cần thiết để tính mọi chỉ số thời lượng, xác định trình tự quy trình và phân tích điểm nghẽn. Lấy dữ liệu ở đâu Đây là trường tiêu chuẩn trong mọi nhật ký sự kiện hoặc bảng dấu vết kiểm toán, thường có tên 'Timestamp', 'EventDate' hoặc 'CreationDate'. Ví dụ 2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T14:22:15Z
	Mã người xét duyệt ReviewerId	Mã định danh của người dùng, chuyên viên phân tích hoặc tác nhân tự động thực hiện hoạt động.
Mô tả Mã người xét duyệt, hay người dùng, cho biết ai đã thực hiện một tác vụ cụ thể trong quy trình KYC. Đó có thể là chuyên viên tuân thủ, nhân viên tiếp nhận khách hàng hoặc tài khoản hệ thống dùng cho hoạt động tự động. Theo dõi thông tin này giúp nắm rõ cách phân bổ khối lượng công việc và hiệu suất của từng người. Thuộc tính này rất cần thiết cho phân tích theo tài nguyên. Thuộc tính giúp tìm hiểu khác biệt về hiệu suất giữa người dùng hoặc các nhóm, xác định nhu cầu đào tạo và cân bằng khối lượng công việc. Đây cũng là thành phần quan trọng để phân tích việc bàn giao, mạng lưới tương tác và mức sử dụng tài nguyên tuân thủ. Vì sao điều này quan trọng Giúp phân tích cách phân bổ khối lượng công việc, hiệu suất người dùng và việc bàn giao giữa các phòng ban, từ đó hỗ trợ tối ưu tài nguyên. Lấy dữ liệu ở đâu Thường có trong nhật ký sự kiện hoặc dấu vết kiểm toán, với tên trường như 'UserID', 'PerformedBy' hoặc 'Owner'. Ví dụ analyst_jdoesystem_auto_screenermanager_bsmith
	Mức độ rủi ro RiskLevel	Phân loại rủi ro được tính cho đơn đăng ký của khách hàng, chẳng hạn như Thấp, Trung bình hoặc Cao.
Mô tả Mức độ rủi ro là thông tin quan trọng trong quy trình KYC, giúp xác định mức độ thẩm định cần thiết. Mức này thường được xác định dựa trên các yếu tố như loại khách hàng, khu vực địa lý và lĩnh vực kinh doanh. Phân loại rủi ro có thể ảnh hưởng đáng kể đến lộ trình xử lý đơn đăng ký. Trong phân tích quy trình, việc phân nhóm hồ sơ theo mức độ rủi ro là rất cần thiết. Cách này giúp giải thích sự khác biệt về thời gian xử lý và luồng quy trình. Ví dụ, đơn đăng ký có rủi ro cao có thể cần thêm bước và mất nhiều thời gian hơn. Thuộc tính này rất quan trọng đối với dashboard 'Tỷ lệ và lý do từ chối đơn đăng ký' và 'Thời gian bắt đầu kiểm tra lý lịch', giúp hiểu rủi ro ảnh hưởng thế nào đến kết quả và hiệu quả. Vì sao điều này quan trọng Phân nhóm quy trình theo mức độ rủi ro rất quan trọng để hiểu vì sao một số hồ sơ mất nhiều thời gian hơn hoặc đi theo lộ trình khác, đồng thời phân tích tỷ lệ từ chối. Lấy dữ liệu ở đâu Đây là dữ liệu cốt lõi trong hồ sơ đơn đăng ký hoặc hồ sơ khách hàng. Hãy kiểm tra mô-đun quản lý hồ sơ trong Refinitiv World-Check. Ví dụ ThấpTrung bìnhCao
	Ngày mục tiêu SLA SlaTargetDate	Ngày mục tiêu cần hoàn tất quy trình tiếp nhận khách hàng.
Mô tả Ngày mục tiêu SLA là hạn hoàn tất toàn bộ hồ sơ tiếp nhận khách hàng, theo thỏa thuận mức dịch vụ với khách hàng hoặc chính sách nội bộ. Đây là mốc để so sánh với thời gian hoàn tất thực tế. Thuộc tính này là nền tảng cho dashboard 'Mức độ đáp ứng SLA và phân tích vi phạm'. Thuộc tính được dùng để tính xem hồ sơ có hoàn tất đúng hạn hay không. Phân tích các trường hợp vi phạm SLA giúp xác định vấn đề mang tính hệ thống gây chậm trễ, từ đó tổ chức có thể khắc phục để hoàn tất đúng hạn và đáp ứng yêu cầu tuân thủ. Vì sao điều này quan trọng Đây là mốc để đo hiệu suất đúng hạn, đồng thời rất quan trọng khi tính tỷ lệ đáp ứng SLA và phân tích các trường hợp vi phạm. Lấy dữ liệu ở đâu Ngày này thường được tính dựa trên ngày gửi đơn và các quy tắc kinh doanh. Ngày có thể được lưu thành một trường trong hồ sơ. Ví dụ 2023-11-10T17:00:00Z2023-11-15T17:00:00Z2023-11-20T17:00:00Z
	Phòng ban DepartmentName	Phòng ban hoặc nhóm chức năng chịu trách nhiệm thực hiện hoạt động.
Mô tả Thuộc tính này cho biết đơn vị kinh doanh hoặc nhóm mà người dùng trực thuộc, chẳng hạn như 'Tiếp nhận khách hàng', 'Tuân thủ' hoặc 'Đảm bảo chất lượng'. Thuộc tính này cho phép phân tích ở cấp tổ chức thay vì chỉ ở cấp cá nhân. Phân tích theo phòng ban rất quan trọng để xác định điểm nghẽn giữa các phòng ban và đo thời gian bàn giao. Cách xem này giúp hình dung công việc luân chuyển giữa các nhóm và xác định những khâu chuyển tiếp gây chậm trễ. Đây là thông tin hữu ích để cải thiện phối hợp liên phòng ban và nâng cao hiệu quả chung của quy trình. Vì sao điều này quan trọng Cho phép phân tích hiệu suất quy trình theo phòng ban và giúp xác định chậm trễ khi bàn giao giữa các nhóm. Lấy dữ liệu ở đâu Thông tin này có thể được lưu trong hồ sơ người dùng của hệ thống hoặc hệ thống nhân sự liên quan. Có thể cần kết hợp thông tin này với dữ liệu sự kiện bằng mã người dùng. Ví dụ Nhóm tiếp nhận khách hàngBộ phận xét duyệt tuân thủBan quản lý cấp cao
	Thời điểm kết thúc sự kiện EventEndTime	Dấu thời gian cho biết thời điểm hoàn tất một hoạt động hoặc sự kiện cụ thể.
Mô tả Thời điểm kết thúc sự kiện đánh dấu lúc một hoạt động hoàn tất. Nhiều sự kiện có thể được mô hình hóa như diễn ra tức thời, khi thời điểm bắt đầu bằng thời điểm kết thúc. Một số hoạt động có thời lượng đo được, chẳng hạn như 'Bắt đầu chuyên viên phân tích xem xét' và 'Hoàn tất chuyên viên phân tích xem xét'. Có cả thời điểm bắt đầu và kết thúc giúp đo chính xác thời gian xử lý. Trong phân tích quy trình, thời điểm kết thúc rất cần thiết để tính chính xác thời gian xử lý hoạt động, khác với thời gian xử lý hồ sơ vốn bao gồm cả thời gian chờ. Nhờ đó, bạn có thể phân biệt thời gian hồ sơ được xử lý thực tế với thời gian nằm yên trong hàng đợi. Đây là yếu tố quan trọng để tối ưu tài nguyên và phân tích hiệu quả. Vì sao điều này quan trọng Giúp tính chính xác thời gian xử lý hoạt động, tách thời gian làm việc thực tế khỏi thời gian chờ để phân tích hiệu suất chính xác hơn. Lấy dữ liệu ở đâu Với hoạt động có thời lượng, thông tin này có thể được lưu trong một trường riêng như 'CompletionDate' hoặc 'EndDate' trong nhật ký sự kiện hoặc bảng dấu vết kiểm toán. Ví dụ 2023-10-26T10:45:00Z2023-10-26T12:00:00Z2023-10-27T15:00:00Z
	Hệ thống nguồn SourceSystem	Hệ thống trích xuất dữ liệu sự kiện, trong trường hợp này là Refinitiv World-Check.
Mô tả Thuộc tính này xác định nguồn gốc của dữ liệu quy trình. Trong trường hợp chỉ trích xuất từ một nguồn, giá trị có thể không đổi. Nhưng khi kết hợp dữ liệu từ nhiều hệ thống, chẳng hạn CRM và World-Check, thuộc tính này rất quan trọng để tạo cái nhìn tổng thể về quy trình. Trong phân tích, thuộc tính này hỗ trợ quản trị dữ liệu, xử lý sự cố và làm rõ bối cảnh dữ liệu. Ví dụ, hoạt động được ghi trong hệ thống sàng lọc cốt lõi có thể có đặc điểm hoặc mức độ chi tiết khác với hoạt động từ hệ thống phụ trợ. Thuộc tính này giúp xác định rõ nguồn gốc dữ liệu và hỗ trợ kiểm toán. Vì sao điều này quan trọng Xác định nguồn gốc dữ liệu, rất quan trọng cho việc quản trị, xác thực và hợp nhất dữ liệu từ nhiều nguồn. Lấy dữ liệu ở đâu Đây thường là giá trị tĩnh được thêm trong quá trình trích xuất, chuyển đổi và tải dữ liệu (ETL) để gắn nhãn cho tập dữ liệu. Ví dụ Refinitiv World-CheckWorldCheckOne
	Kênh đăng ký ApplicationChannel	Kênh khách hàng dùng để gửi đơn đăng ký, chẳng hạn như cổng thông tin trực tuyến, tại chi nhánh hoặc ứng dụng di động.
Mô tả Kênh đăng ký cho biết nguồn gửi đơn của khách hàng. Mỗi kênh có thể khác nhau về mức độ đầy đủ và chất lượng dữ liệu cũng như đặc điểm nhân khẩu học của khách hàng, từ đó ảnh hưởng đến các bước tiếp theo trong quy trình. Thuộc tính này rất cần thiết cho dashboard 'Số lượng đơn đăng ký theo kênh'. Bằng cách phân tích số lượng, thời gian xử lý và kết quả của đơn đăng ký từ từng kênh, tổ chức có thể xác định kênh nào hiệu quả nhất và kênh nào cần cải tiến quy trình. Phân tích này hỗ trợ quyết định về phân bổ tài nguyên và đầu tư vào kênh. Vì sao điều này quan trọng Giúp phân tích hiệu suất và hiệu quả của từng kênh gửi đơn, hỗ trợ quyết định chiến lược về công nghệ và trải nghiệm khách hàng. Lấy dữ liệu ở đâu Thông tin này thường được thu thập khi quy trình bắt đầu và lưu thành thuộc tính trong hồ sơ đơn đăng ký. Ví dụ Cổng thông tin trực tuyếnỨng dụng di độngTại chi nhánhChuyên viên quản lý quan hệ khách hàng
	Là làm lại IsRework	Cờ cho biết một hoạt động có được thực hiện lần thứ hai trở đi trong cùng một hồ sơ hay không.
Mô tả IsRework là thuộc tính boolean được tính toán để xác định hoạt động nào lặp lại trong cùng một hồ sơ đăng ký của khách hàng. Ví dụ, nếu “Đã thực hiện đánh giá rủi ro” xuất hiện nhiều lần trong một đơn đăng ký, các lần tiếp theo sẽ được đánh dấu là làm lại. Thuộc tính này rất quan trọng để phát hiện quy trình kém hiệu quả, vòng lặp và những lần lặp lại không cần thiết. Thuộc tính hỗ trợ trực tiếp dashboard “Phân tích làm lại và hiệu quả đánh giá rủi ro” cùng KPI “Tỷ lệ làm lại đánh giá rủi ro”. Phân tích các lần làm lại giúp phát hiện vấn đề về chất lượng, độ rõ ràng của thông tin hoặc quá trình ra quyết định, vốn gây lãng phí công sức và kéo dài thời gian xử lý. Vì sao điều này quan trọng Đánh dấu các hoạt động lặp lại để phát hiện điểm kém hiệu quả trong quy trình, từ đó phân tích vòng lặp làm lại, nâng cao chất lượng và rút ngắn thời gian xử lý. Lấy dữ liệu ở đâu Giá trị này được tính trong bước chuyển đổi dữ liệu bằng cách phân tích thứ tự hoạt động trong từng hồ sơ và đánh dấu mọi lần xuất hiện không phải lần đầu của một hoạt động. Ví dụ truefalse
	Là tự động IsAutomated	Cờ cho biết hoạt động do hệ thống thực hiện (true) hay do người thực hiện (false).
Mô tả Thuộc tính boolean này phân biệt tác vụ tự động của hệ thống với hoạt động thủ công do người dùng thực hiện. Ví dụ, “Đã thực hiện sàng lọc tự động” được đánh dấu là tự động, còn “Bắt đầu chuyên viên phân tích rà soát” được đánh dấu là thủ công. Phân biệt này rất quan trọng khi phân tích tự động hóa. Thuộc tính giúp đo lường tác động của tự động hóa đến hiệu quả quy trình, xác định tác vụ thủ công nào có thể tự động hóa trong tương lai và hiểu cách con người tương tác với hệ thống. Nhờ đó, bạn có thể tách riêng thời gian xử lý của hệ thống và thời gian thao tác thủ công. Vì sao điều này quan trọng Phân biệt hoạt động do hệ thống và con người thực hiện, giúp đo lường tác động của tự động hóa và tìm cơ hội tự động hóa mới. Lấy dữ liệu ở đâu Thông tin này thường được xác định dựa trên tên hoạt động hoặc ID người dùng gắn với sự kiện, chẳng hạn khi người dùng là tài khoản “system”. Ví dụ truefalse
	Lần cập nhật dữ liệu gần nhất LastDataUpdate	Dấu thời gian cho biết lần gần nhất dữ liệu của sự kiện này được làm mới hoặc trích xuất từ hệ thống nguồn.
Mô tả Thuộc tính này cho biết dữ liệu còn mới đến mức nào. Thuộc tính ghi lại ngày giờ lần gần nhất dữ liệu được lấy từ Refinitiv World-Check. Thông tin này giúp bạn hiểu dữ liệu trong dashboard và các phân tích process mining được cập nhật đến thời điểm nào. Trong phân tích, thuộc tính này giúp người dùng biết họ đang xem dữ liệu gần thời gian thực hay ảnh chụp dữ liệu tại một thời điểm cụ thể. Đây là thông tin thiết yếu cho việc quản trị dữ liệu và giúp người dùng hiểu rõ mức độ cập nhật của các thông tin phân tích. Vì sao điều này quan trọng Cung cấp bối cảnh quan trọng về độ mới của dữ liệu, giúp người dùng biết phân tích quy trình được cập nhật đến thời điểm nào. Lấy dữ liệu ở đâu Dấu thời gian này được tạo và thêm trong quá trình trích xuất dữ liệu (ETL). Ví dụ 2023-11-01T02:00:00Z2023-11-02T02:00:00Z
	Loại khách hàng CustomerType	Phân loại khách hàng, chẳng hạn như Cá nhân, Doanh nghiệp hoặc Quỹ tín thác.
Mô tả Loại khách hàng phân loại đối tượng đang được tiếp nhận. Mỗi loại khách hàng thường có yêu cầu tiếp nhận, hồ sơ rủi ro và nghĩa vụ pháp lý khác nhau. Ví dụ, tiếp nhận một doanh nghiệp thường phức tạp hơn tiếp nhận một cá nhân. Thuộc tính này được dùng để phân tích theo nhóm, đặc biệt trong dashboard 'Hiệu suất KYC theo loại khách hàng'. Thuộc tính cho phép so sánh hiệu quả quy trình, thời gian xử lý và tỷ lệ từ chối giữa các nhóm khách hàng. Nhờ đó, tổ chức có thể điều chỉnh và tối ưu trải nghiệm tiếp nhận cho từng loại khách hàng. Vì sao điều này quan trọng Cho phép so sánh hiệu suất giữa các nhóm khách hàng, giúp điều chỉnh và tối ưu quy trình tiếp nhận cho từng loại. Lấy dữ liệu ở đâu Đây là thuộc tính cơ bản được lưu trong hồ sơ khách hàng hoặc đơn đăng ký của hệ thống nguồn. Ví dụ Cá nhânDoanh nghiệpTổ chức phi lợi nhuậnQuỹ tín thác
	Lý do từ chối RejectionReason	Lý do cụ thể được đưa ra khi từ chối đơn đăng ký của khách hàng.
Mô tả Khi đơn đăng ký bị từ chối, Lý do từ chối cho biết nguyên nhân dẫn đến quyết định đó. Các lý do có thể gồm 'Trùng khớp với danh sách trừng phạt', 'Thiếu giấy tờ' hoặc 'Hồ sơ rủi ro cao'. Thông tin này cung cấp phản hồi có cấu trúc về chất lượng đơn đăng ký đầu vào và hiệu quả của quy trình sàng lọc. Thuộc tính này là dữ liệu chính cho dashboard 'Tỷ lệ và lý do từ chối đơn đăng ký'. Phân tích lý do từ chối giúp xác định nguyên nhân gốc rễ, từ đó cải tiến quy trình, trao đổi rõ ràng hơn với người đăng ký và có thể giảm các trường hợp từ chối không cần thiết. Thuộc tính này bổ sung bối cảnh định tính cho KPI về tỷ lệ từ chối. Vì sao điều này quan trọng Cho biết nguyên nhân gốc rễ khiến đơn đăng ký bị từ chối, giúp xác định những điểm cần cải thiện trong quy trình tiếp nhận khách hàng để giảm tỷ lệ từ chối. Lấy dữ liệu ở đâu Thông tin này được ghi nhận khi xảy ra sự kiện 'Đơn đăng ký bị từ chối', có thể dưới dạng một trường trong hồ sơ khách hàng hoặc đơn đăng ký. Ví dụ Trùng khớp với PEPCó tên trong danh sách trừng phạtKhông xác minh được giấy tờThông tin bất lợi trên truyền thông
	Mã khách hàng CustomerId	Mã định danh duy nhất của khách hàng đang được tiếp nhận.
Mô tả Mã khách hàng là mã định danh duy nhất của hồ sơ khách hàng. Mã này khác với mã đơn đăng ký khách hàng, vì một khách hàng có thể gửi nhiều đơn theo thời gian. Thuộc tính này liên kết quy trình tiếp nhận với hồ sơ khách hàng chính. Trong phân tích, mã khách hàng giúp theo dõi các đơn đăng ký lặp lại của cùng một khách hàng và bổ sung dữ liệu quy trình bằng các thuộc tính khách hàng khác từ CRM hoặc hệ thống dữ liệu chủ. Nhờ đó, bạn có thể xem hành trình khách hàng rộng hơn thay vì chỉ một lần tiếp nhận. Vì sao điều này quan trọng Liên kết hồ sơ tiếp nhận với một khách hàng cụ thể, giúp phân tích các đơn đăng ký lặp lại và bổ sung dữ liệu từ hồ sơ khách hàng chính. Lấy dữ liệu ở đâu Đây là trường quan trọng trong hồ sơ đơn đăng ký hoặc hồ sơ khách hàng, liên kết hồ sơ đó với dữ liệu khách hàng chính. Ví dụ CUST-98765CUST-98766CUST-98767
	Mã trường hợp trùng khớp MatchId	Mã định danh duy nhất của trường hợp có khả năng trùng khớp được phát hiện trong quá trình sàng lọc World-Check.
Mô tả Khi quy trình sàng lọc tự động phát hiện khả năng trùng khớp với danh sách trừng phạt, danh sách PEP hoặc tin tức bất lợi, hệ thống thường tạo Match ID để theo dõi kết quả cụ thể. ID này liên kết hồ sơ đăng ký với bản ghi tương ứng trong cơ sở dữ liệu World-Check đã kích hoạt cảnh báo. Thuộc tính này hữu ích khi phân tích chi tiết việc tuân thủ. Chuyên viên phân tích có thể tìm hiểu bản chất của các kết quả trùng khớp, theo dõi cách xử lý từng cảnh báo (ví dụ: xác nhận kết quả dương tính giả hoặc trùng khớp thực sự) và biết loại cảnh báo nào phổ biến nhất hoặc mất nhiều thời gian xử lý nhất. Thuộc tính này cung cấp thêm chi tiết về hoạt động “Phát hiện khả năng trùng khớp”. Vì sao điều này quan trọng Liên kết chi tiết đến kết quả sàng lọc cụ thể, giúp phân tích sâu hơn thời gian xử lý và loại cảnh báo. Lấy dữ liệu ở đâu World-Check screening engine thường tạo ID này và ghi nhận vào hồ sơ đăng ký khi phát hiện khả năng trùng khớp. Ví dụ WC-MATCH-459021WC-MATCH-459022WC-MATCH-459023
	Quốc gia của khách hàng CustomerCountry	Quốc gia nơi khách hàng cư trú hoặc đăng ký thành lập.
Mô tả Thuộc tính này cho biết vị trí địa lý của khách hàng. Quốc gia là yếu tố quan trọng trong đánh giá rủi ro và xác định yêu cầu pháp lý của quy trình KYC. Mỗi khu vực pháp lý có quy định riêng, có thể ảnh hưởng đến luồng và thời lượng quy trình. Phân tích quy trình theo quốc gia giúp tổ chức so sánh hiệu suất giữa các khu vực, xác định điểm nghẽn tại từng địa phương và bảo đảm tuân thủ quy định sở tại. Thuộc tính này bổ sung góc nhìn địa lý cho phân tích quy trình, qua đó làm rõ những khác biệt quan trọng trong vận hành. Vì sao điều này quan trọng Cho phép phân tích quy trình theo khu vực địa lý, giúp xác định khác biệt giữa các vùng về hiệu suất, rủi ro và yêu cầu tuân thủ. Lấy dữ liệu ở đâu Đây là trường tiêu chuẩn trong hồ sơ khách hàng hoặc biểu mẫu đăng ký. Ví dụ USAGBRSGPDEU
	Vi phạm SLA SlaBreached	Cờ boolean cho biết hồ sơ onboarding có hoàn tất sau ngày mục tiêu SLA hay không.
Mô tả Thuộc tính này là cờ được tính toán để cho biết hồ sơ có vi phạm Thỏa thuận mức dịch vụ hay không. Hệ thống xác định bằng cách so sánh dấu thời gian của hoạt động hoàn tất cuối cùng (ví dụ: “Đã phê duyệt đơn đăng ký” hoặc “Đã từ chối đơn đăng ký”) với “SlaTargetDate” của hồ sơ. Cờ này là cơ sở cho dashboard “Phân tích mức độ đáp ứng và vi phạm SLA” và KPI “Tỷ lệ đáp ứng SLA”. Cờ giúp đơn giản hóa việc phân tích, cho phép người dùng nhanh chóng lọc tất cả hồ sơ vi phạm. Khi phân tích đặc điểm quy trình của các hồ sơ này, tổ chức có thể tìm ra nguyên nhân gốc rễ gây chậm trễ và tập trung cải tiến đúng chỗ. Vì sao điều này quan trọng Đo trực tiếp mức độ tuân thủ thỏa thuận mức dịch vụ, giúp dễ dàng lọc hồ sơ chậm trễ và phân tích nguyên nhân gốc rễ. Lấy dữ liệu ở đâu Giá trị này được tính trong bước chuyển đổi dữ liệu bằng cách so sánh dấu thời gian của hoạt động cuối cùng trong hồ sơ với trường SlaTargetDate. Ví dụ truefalse

Bắt buộc Nên có Không bắt buộc

Hoạt động onboarding khách hàng KYC

Đây là các bước và cột mốc chính cần ghi nhận trong nhật ký sự kiện để khám phá quy trình chính xác.

8 Nên có 6 Không bắt buộc

	Hoạt động	Mô tả
	Bắt đầu chuyên viên phân tích xem xét	Chuyên viên tuân thủ bắt đầu điều tra thủ công các trường hợp có khả năng trùng khớp với đơn đăng ký của khách hàng. Họ đối chiếu thông tin về các trường hợp này với thông tin khách hàng để xác định có liên quan hay không.
Vì sao điều này quan trọng Đây là lúc bắt đầu bước xem xét tuân thủ thủ công, vốn thường là điểm nghẽn. Đo thời gian từ lúc phát hiện trường hợp có khả năng trùng khớp đến bước này giúp nhận biết thời gian chờ trong hàng đợi. Thời lượng xem xét cho biết hiệu suất của chuyên viên phân tích. Lấy dữ liệu ở đâu Có thể suy ra sự kiện này khi chuyên viên phân tích nhận xử lý hoặc mở hồ sơ từ hàng đợi xem xét. Hệ thống cũng có thể ghi rõ sự kiện trong dấu vết kiểm toán khi trạng thái hồ sơ chuyển thành 'Đang xem xét' hoặc hồ sơ được giao cho một người dùng cụ thể. Thu thập Được suy ra từ việc trạng thái hồ sơ chuyển thành 'Đang được xem xét' hoặc hồ sơ được giao cho chuyên viên phân tích. Loại sự kiện inferred
	Đã gửi hồ sơ	Hoạt động này đánh dấu thời điểm bắt đầu quy trình tiếp nhận khách hàng KYC, khi khách hàng gửi hồ sơ. Sự kiện thường được ghi nhận trong CRM hoặc hệ thống quản lý hồ sơ chính, sau đó kích hoạt quy trình sàng lọc trong Refinitiv World-Check.
Vì sao điều này quan trọng Đây là sự kiện bắt đầu chính của toàn bộ quá trình tiếp nhận khách hàng. Phân tích thời gian từ thời điểm này đến khi hoàn tất giúp xác định tổng thời gian xử lý, yếu tố quan trọng để đo lường trải nghiệm khách hàng và mức độ đáp ứng SLA. Lấy dữ liệu ở đâu Sự kiện này không có sẵn trong World-Check. Bạn cần lấy dữ liệu từ một hệ thống đầu vào, chẳng hạn như CRM hoặc nền tảng quản lý tài khoản khách hàng, rồi đối chiếu theo Customer Application ID. Thu thập Sự kiện được ghi vào hệ thống ứng dụng nguồn khi khách hàng gửi hồ sơ lần đầu. Loại sự kiện explicit
	Đã tạo yêu cầu sàng lọc	Một hồ sơ sàng lọc mới được tạo chính thức cho hồ sơ khách hàng trong hệ thống Refinitiv World-Check. Việc này được kích hoạt qua lệnh gọi API hoặc nhập thủ công từ một hệ thống đầu vào, đánh dấu thời điểm bắt đầu kiểm tra thông tin rủi ro.
Vì sao điều này quan trọng Đây là thời điểm chính thức bắt đầu quy trình con sàng lọc. Khoảng thời gian từ lúc gửi đơn đến hoạt động này cho thấy việc bàn giao giữa hệ thống nghiệp vụ và bộ phận tuân thủ có bị chậm trễ hay không. Lấy dữ liệu ở đâu Thông tin được ghi trong nhật ký quản lý hồ sơ hoặc dấu vết kiểm toán của World-Check. Sự kiện tạo hồ sơ và dấu thời gian tương ứng được dùng cho mã hồ sơ hoặc mã thực thể cụ thể. Thu thập Hệ thống tự động ghi nhận khi tạo hồ sơ sàng lọc mới. Loại sự kiện explicit
	Đơn đăng ký bị từ chối	Đơn đăng ký của khách hàng chính thức bị từ chối, thường do World-Check phát hiện trùng khớp hoặc do các yếu tố rủi ro khác. Đây là kết quả cuối cùng không đạt yêu cầu của quy trình tiếp nhận khách hàng.
Vì sao điều này quan trọng Đây là điểm kết thúc chính của quy trình khi hồ sơ không được chấp thuận. Phân tích các trường hợp bị từ chối, đặc biệt là lý do và những hoạt động diễn ra trước đó, rất quan trọng để cải tiến quy trình và giảm các trường hợp từ chối không cần thiết. Lấy dữ liệu ở đâu Quyết định kinh doanh cuối cùng này được ghi trong CRM hoặc hệ thống ứng dụng cốt lõi ở bước trước, không phải trong World-Check. Cần lấy dữ liệu từ hệ thống đó. Thu thập Sự kiện được ghi trong hệ thống ứng dụng nguồn, thường kèm mã lý do từ chối. Loại sự kiện explicit
	Hoàn tất sàng lọc, không có vấn đề	Hồ sơ sàng lọc chính thức được đóng với kết quả 'Không có vấn đề', nghĩa là không phát hiện trường hợp trùng khớp thực sự nào. Quyết định này được gửi lại hệ thống khởi tạo để quy trình tiếp nhận khách hàng tiếp tục.
Vì sao điều này quan trọng Hoạt động này đánh dấu quy trình sàng lọc hoàn tất thành công theo lộ trình thông thường. Đây là mốc quan trọng để đo thời gian xử lý các đơn đăng ký tiêu chuẩn, có rủi ro thấp. Lấy dữ liệu ở đâu Có thể suy ra từ trạng thái cuối cùng của hồ sơ chuyển thành 'Không có vấn đề', 'Hoàn tất' hoặc 'Đã đóng, không trùng khớp'. Dấu thời gian của lần đổi trạng thái cuối cùng được sử dụng. Thu thập Được xác định từ dấu thời gian của trạng thái hồ sơ cuối cùng cho biết kết quả không có vấn đề. Loại sự kiện inferred
	Hoàn tất sàng lọc, phát hiện trùng khớp	Hồ sơ sàng lọc chính thức được đóng với kết quả 'Phát hiện trùng khớp', cho biết đã xác định được rủi ro. Quyết định này sẽ kích hoạt quy trình tiếp theo khác, chẳng hạn như thẩm định tăng cường hoặc từ chối đơn đăng ký.
Vì sao điều này quan trọng Đây là điểm kết thúc chính của lộ trình không đạt yêu cầu trong quy trình sàng lọc. Phân tích các hồ sơ này giúp hiểu rõ hồ sơ rủi ro và hiệu quả của các biện pháp kiểm soát sàng lọc. Lấy dữ liệu ở đâu Có thể suy ra từ trạng thái cuối cùng của hồ sơ chuyển thành 'Phát hiện trùng khớp', 'Đã xác định rủi ro' hoặc 'Đã đóng, kết quả dương tính'. Dấu thời gian của lần đổi trạng thái cuối cùng được sử dụng. Thu thập Được xác định từ dấu thời gian của trạng thái hồ sơ cuối cùng cho biết đã xác nhận trùng khớp. Loại sự kiện inferred
	Kích hoạt tài khoản	Tài khoản khách hàng được tạo và kích hoạt trong hệ thống cốt lõi, hoàn tất hành trình tiếp nhận khách hàng. Bước này diễn ra sau khi đơn đăng ký được phê duyệt cuối cùng và giúp tài khoản sẵn sàng sử dụng.
Vì sao điều này quan trọng Đây là bước cuối cùng tạo giá trị trong quy trình. Thời gian từ lúc gửi đơn đến khi kích hoạt tài khoản là chỉ số quan trọng để đánh giá hiệu quả vận hành và mức độ hài lòng của khách hàng. Lấy dữ liệu ở đâu Sự kiện này không được ghi nhận trong World-Check. Sự kiện được lưu trong hệ thống ngân hàng cốt lõi hoặc hệ thống tài khoản khách hàng và cần được đối chiếu bằng mã đơn đăng ký của khách hàng. Thu thập Sự kiện được ghi trong hệ thống tài khoản cốt lõi khi tài khoản được kích hoạt. Loại sự kiện explicit
	Xác nhận trùng khớp thực sự	Chuyên viên phân tích xác nhận trường hợp có khả năng trùng khớp chính là khách hàng đang được sàng lọc, qua đó phát hiện rủi ro tiềm ẩn. Đây là mốc quan trọng, thường dẫn đến việc thẩm định bổ sung hoặc từ chối đơn đăng ký.
Vì sao điều này quan trọng Đây là kết quả quan trọng giúp giảm thiểu rủi ro và là bước ngoặt trong quy trình. Kết quả này ảnh hưởng trực tiếp đến quyết định cuối cùng về đơn đăng ký của khách hàng, đồng thời rất cần thiết cho việc báo cáo và phân tích tuân thủ. Lấy dữ liệu ở đâu Đây là thao tác cụ thể của người dùng, khi chuyên viên phân tích phân loại một trường hợp trùng khớp là 'Trùng khớp thực sự' hoặc 'Đã xác nhận trùng khớp'. Sự kiện này được ghi trong dấu vết kiểm toán của hồ sơ. Thu thập Được ghi nhận khi chuyên viên phân tích chính thức xác nhận trường hợp trùng khớp trong hệ thống. Loại sự kiện explicit
	Chuyển hồ sơ lên cấp cao hơn để xem xét	Chuyên viên phân tích cấp một chuyển hồ sơ phức tạp hoặc có rủi ro cao cho chuyên viên cấp cao hoặc quản lý để đưa ra quyết định cuối cùng. Đây là điểm bàn giao quan trọng trong nhóm tuân thủ.
Vì sao điều này quan trọng Việc chuyển cấp thường tạo ra điểm nghẽn và kéo dài thời gian xử lý. Phân tích tần suất và lý do chuyển cấp có thể giúp xác định nhu cầu đào tạo cho chuyên viên mới hoặc những điểm chưa rõ trong chính sách xét duyệt. Lấy dữ liệu ở đâu Được ghi nhận dưới dạng thao tác cụ thể trong quy trình làm việc của hồ sơ hoặc dấu vết kiểm toán. Cũng có thể suy ra từ việc thay đổi người được giao xử lý hồ sơ, nhất là khi hồ sơ được giao cho người dùng có quyền cao hơn. Thu thập Được ghi nhận khi người dùng nhấn nút 'Chuyển cấp' hoặc thực hiện thao tác tương ứng trong quy trình làm việc của hồ sơ. Loại sự kiện explicit
	Đã thực hiện sàng lọc tự động	Hệ thống World-Check tự động đối chiếu thông tin khách hàng với cơ sở dữ liệu tình báo rủi ro. Hệ thống thực hiện bước này và trả về kết quả ban đầu, chẳng hạn như các trường hợp có khả năng trùng khớp hoặc trạng thái không có vấn đề.
Vì sao điều này quan trọng Đây là bước đầu tiên tạo giá trị trong quy trình sàng lọc. Nếu có chậm trễ trước bước này, nguyên nhân có thể nằm ở hệ thống hoặc dữ liệu chưa sẵn sàng. Kết quả của bước này quyết định khối lượng công việc cần xử lý thủ công tiếp theo. Lấy dữ liệu ở đâu Sự kiện này có thể được ghi rõ trong dấu vết kiểm toán của hồ sơ, hoặc được suy ra từ dấu thời gian khi kết quả sàng lọc ban đầu có sẵn. Thu thập Mục nhật ký hệ thống được tạo sau khi hoàn tất quét cơ sở dữ liệu tự động. Loại sự kiện explicit
	Đơn đăng ký được phê duyệt	Đơn đăng ký của khách hàng được phê duyệt đầy đủ sau khi hoàn tất sàng lọc KYC thành công và các bước kiểm tra bắt buộc khác. Sự kiện này thường xảy ra trong hệ thống nguồn sau khi nhận kết quả 'Không có vấn đề' từ World-Check.
Vì sao điều này quan trọng Đây là kết quả kinh doanh thành công của quy trình tiếp nhận khách hàng. Theo dõi thời gian từ lúc gửi đơn đến mốc này cho biết tổng thời gian để phê duyệt khách hàng mới. Lấy dữ liệu ở đâu Sự kiện này không có sẵn trong World-Check. Cần lấy dữ liệu từ CRM hoặc hệ thống ứng dụng cốt lõi ở bước trước, nơi đưa ra quyết định kinh doanh cuối cùng. Thu thập Sự kiện được ghi trong hệ thống ứng dụng nguồn khi đơn đăng ký được phê duyệt cuối cùng. Loại sự kiện explicit
	Phát hiện trường hợp có khả năng trùng khớp	Quy trình sàng lọc tự động phát hiện một hoặc nhiều trường hợp có khả năng trùng khớp cần chuyên viên phân tích xem xét thủ công. Sự kiện này chuyển hồ sơ từ trạng thái tự động sang hàng đợi điều tra thủ công.
Vì sao điều này quan trọng Đây là điểm rẽ nhánh quan trọng trong quy trình. Hồ sơ có khả năng trùng khớp sẽ đi theo lộ trình dài và phức tạp hơn. Theo dõi bước này giúp lập kế hoạch tài nguyên và phân tích điểm nghẽn trong nhóm xét duyệt. Lấy dữ liệu ở đâu Có thể suy ra sự kiện này khi trạng thái hồ sơ trong mô-đun quản lý hồ sơ World-Check chuyển thành 'Cần xem xét', 'Có khả năng trùng khớp' hoặc trạng thái tương tự. Thu thập Được suy ra từ thay đổi trạng thái hồ sơ cho biết cần xem xét thủ công. Loại sự kiện inferred
	Xác nhận kết quả trùng khớp giả	Chuyên viên phân tích kết luận rằng trường hợp có khả năng trùng khớp không phải là khách hàng đang được sàng lọc. Họ bác bỏ kết quả trùng khớp và kết thúc việc xử lý cảnh báo cụ thể đó.
Vì sao điều này quan trọng Đây là kết quả thường gặp của bước xem xét. Thời gian xử lý các trường hợp trùng khớp giả giúp đánh giá hiệu suất của chuyên viên phân tích và độ chính xác của logic sàng lọc tự động. Lấy dữ liệu ở đâu Đây là thao tác cụ thể của người dùng, khi chuyên viên phân tích phân loại một trường hợp trùng khớp là 'Trùng khớp giả' hoặc 'Không trùng khớp'. Thao tác này thường được ghi trong lịch sử hồ sơ. Thu thập Được ghi nhận khi chuyên viên phân tích chính thức bác bỏ trường hợp có khả năng trùng khớp trong hệ thống. Loại sự kiện explicit
	Yêu cầu bổ sung thông tin	Chuyên viên phân tích xác định cần thêm thông tin để xử lý trường hợp có khả năng trùng khớp và yêu cầu đơn vị kinh doanh cung cấp. Hồ sơ sẽ ở trạng thái chờ cho đến khi nhận được thông tin.
Vì sao điều này quan trọng Hoạt động này xảy ra thường xuyên cho thấy dữ liệu ban đầu dùng để sàng lọc có thể chưa đạt chất lượng. Hoạt động này gây chậm trễ đáng kể vì phụ thuộc vào các nhóm bên ngoài, đồng thời là nguyên nhân chính khiến thời gian xử lý kéo dài. Lấy dữ liệu ở đâu Đây có thể là thao tác của người dùng được ghi trong ghi chú hồ sơ hoặc nhật ký kiểm toán. Ngoài ra, có thể suy ra từ việc trạng thái hồ sơ chuyển thành 'Chờ thông tin' hoặc 'Yêu cầu cung cấp thông tin'. Thu thập Được ghi nhận khi chuyên viên phân tích dùng tính năng để đánh dấu hồ sơ cần bổ sung thông tin. Loại sự kiện explicit

Nên có Không bắt buộc

Hướng dẫn trích xuất

Cách lấy dữ liệu từ Refinitiv World-Check

Các bước

Đăng nhập World-Check One: Truy cập cổng Refinitiv World-Check One bằng thông tin đăng nhập của bạn.
Mở Case Management: Vào mục Case Management, nơi lưu trữ và quản lý tất cả hồ sơ sàng lọc.
Chuẩn bị xuất báo cáo hồ sơ: Mở tính năng báo cáo hoặc xuất dữ liệu trong Case Management. Tính năng này có thể có tên “Export Cases” hoặc “Case Report”.
Cấu hình báo cáo hồ sơ: Chọn các cột cần xuất. Hãy chọn những trường tương ứng với Case ID (CustomerApplication), ngày tạo, ngày xử lý, trạng thái hồ sơ (ví dụ: Clear, Match Found) và mức độ rủi ro.
Xuất dữ liệu Case Management: Chọn khoảng thời gian, thường là 3 đến 6 tháng gần nhất. Áp dụng bộ lọc cần thiết, chẳng hạn theo nhóm người dùng hoặc loại hồ sơ. Xuất dữ liệu thành tệp CSV và đặt tên là case_report.csv.
Chuẩn bị xuất nhật ký kiểm tra: Mở mục nhật ký kiểm tra hoặc báo cáo audit log trong World-Check One. Mục này chứa lịch sử sự kiện chi tiết của từng hồ sơ.
Cấu hình và xuất nhật ký kiểm tra: Chọn tất cả các cột liên quan, gồm Case ID, tên hoặc mô tả sự kiện, dấu thời gian sự kiện và người thực hiện thao tác. Xuất dữ liệu trong cùng khoảng thời gian với báo cáo hồ sơ. Lưu tệp với tên audit_trail.csv.
Lấy dữ liệu về các bước quy trình bên ngoài: Thu thập dữ liệu cho các hoạt động diễn ra ngoài World-Check, chẳng hạn Application Submitted, Application Approved, Account Activated và Application Rejected. Dữ liệu này thường đến từ CRM hoặc hệ thống ngân hàng lõi. Xuất dữ liệu cùng ID CustomerApplication và các dấu thời gian liên quan.
Kết hợp và chuyển đổi dữ liệu: Tải các tệp CSV đã xuất (case_report.csv, audit_trail.csv và dữ liệu từ hệ thống bên ngoài) vào công cụ hoặc tập lệnh chuẩn bị dữ liệu.
Ánh xạ sự kiện kiểm tra thành hoạt động: Xử lý tệp audit_trail.csv. Ánh xạ mô tả sự kiện thô trong nhật ký kiểm tra sang các giá trị ActivityName đã chuẩn hóa. Ví dụ, mục nhật ký “Case Assigned to Analyst” được chuyển thành “Bắt đầu chuyên viên phân tích rà soát”.
Ánh xạ thay đổi trạng thái hồ sơ thành hoạt động: Xử lý tệp case_report.csv để tạo hoạt động dựa trên các lần đổi trạng thái. Dùng ngày xử lý hồ sơ và trạng thái cuối cùng để tạo sự kiện “Hoàn tất sàng lọc, không có kết quả” hoặc “Hoàn tất sàng lọc, phát hiện trùng khớp”.
Tạo nhật ký sự kiện cuối cùng: Gộp dữ liệu đã xử lý từ các tệp nguồn thành một tệp CSV. Đảm bảo tệp cuối có các cột bắt buộc: CustomerApplication, ActivityName và EventTime, cùng mọi thuộc tính được đề xuất. Lưu tệp để tải lên công cụ process mining.

Cấu hình

Loại báo cáo: Bạn cần tạo ít nhất hai báo cáo riêng: báo cáo tổng hợp Case Management và báo cáo chi tiết Audit Trail.
Khoảng thời gian: Để phân tích ban đầu, hãy chọn khoảng thời gian ít nhất 3 đến 6 tháng để có đủ hồ sơ đã hoàn tất và đang xử lý. Đảm bảo các tệp xuất dùng cùng một khoảng thời gian.
Định dạng xuất: Chọn CSV (Comma Separated Values) để dễ xử lý.
Các cột chính (báo cáo hồ sơ): Đảm bảo tệp xuất hồ sơ có Case ID, dấu thời gian tạo, dấu thời gian xử lý, trạng thái cuối cùng, chuyên viên phân tích được giao và mức độ rủi ro.
Các cột chính (báo cáo Audit Trail): Đảm bảo tệp xuất nhật ký kiểm tra có Case ID, mô tả sự kiện, dấu thời gian sự kiện và User ID.
Điều kiện cần: Bạn cần quyền truy cập cổng World-Check One, với quyền xem và xuất dữ liệu Case Management và nhật ký kiểm tra. Có thể cần quyền cao hơn vai trò chuyên viên phân tích thông thường.

Truy vấn mẫu 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'

Các bước

Điều kiện cần và thiết lập: Đảm bảo bạn đã cài Python 3.6 trở lên cùng các thư viện requests và pandas. Lấy API Key và API Secret của World-Check One từ đại diện Refinitiv hoặc cổng dành cho nhà phát triển. Lưu an toàn thông tin xác thực này.
Xây dựng logic xác thực: Trong tập lệnh Python, tạo hàm gửi yêu cầu POST đến endpoint xác thực của World-Check One. Dùng API Key và Secret để lấy bearer token tạm thời, cần thiết cho các lệnh gọi API tiếp theo.
Xác định dữ liệu từ hệ thống nguồn: Quy trình bắt đầu và kết thúc bên ngoài World-Check. Xác định hệ thống nguồn, chẳng hạn CRM hoặc nền tảng ngân hàng lõi, lưu dữ liệu đăng ký ban đầu. Bạn cần trích xuất các sự kiện như Application Submitted, Application Approved, Account Activated và Application Rejected từ hệ thống này. Có thể thực hiện qua truy vấn cơ sở dữ liệu hoặc API khác.
Lấy hồ sơ World-Check: Dùng token đã xác thực để gửi yêu cầu GET đến endpoint /cases của World-Check One API. Dùng tham số truy vấn để lọc hồ sơ theo khoảng thời gian cụ thể, chẳng hạn dựa trên ngày tạo hoặc ngày sửa đổi.
Xử lý phân trang API: Phản hồi từ World-Check API được chia thành nhiều trang. Tập lệnh cần kiểm tra thông tin phân trang trong phản hồi và lặp qua tất cả các trang để lấy đầy đủ danh sách hồ sơ trong khoảng thời gian đã chọn.
Lấy chi tiết và lịch sử hồ sơ: Với mỗi Case ID đã lấy, gửi thêm yêu cầu GET đến các endpoint như /cases/{case_system_id} và /cases/{case_system_id}/audit-trail. Các endpoint này cung cấp thông tin chi tiết về thay đổi trạng thái, kết quả xử lý và thao tác của người dùng liên quan đến hồ sơ.
Ánh xạ dữ liệu thô thành hoạt động: Đây là bước chuyển đổi quan trọng. Viết logic để duyệt dữ liệu phản hồi API (chi tiết hồ sơ, nhật ký kiểm tra) của từng hồ sơ. Ánh xạ các thay đổi trạng thái, mã kết quả và sự kiện kiểm tra cụ thể thành hoạt động nghiệp vụ tương ứng. Ví dụ, sự kiện tạo hồ sơ được chuyển thành Screening Request Created, còn kết quả xử lý False Positive được chuyển thành False Positive Confirmed.
Kết hợp các nguồn dữ liệu: Gộp dữ liệu lấy từ World-Check với dữ liệu từ hệ thống nguồn ở bước 3. Dùng ID CustomerApplication làm khóa chung để tạo nhật ký sự kiện đầu cuối cho từng khách hàng.
Sắp xếp và bổ sung dữ liệu: Tập hợp tất cả sự kiện đã ánh xạ thành một danh sách bản ghi. Đảm bảo mỗi bản ghi có đủ thuộc tính bắt buộc (CustomerApplication, ActivityName, EventTime) và các thuộc tính được đề xuất. Khi có thể, hãy tính EventEndTime, chẳng hạn dùng dấu thời gian của sự kiện tiếp theo trong cùng hồ sơ.
Xuất sang CSV: Chuyển danh sách bản ghi sự kiện cuối cùng thành pandas DataFrame. Sắp xếp lại các cột theo định dạng yêu cầu rồi xuất DataFrame sang tệp CSV. Đảm bảo tệp dùng mã hóa UTF-8 để tương thích với ProcessMind.

Cấu hình

Thông tin xác thực API: Cần có API Key và API Secret hợp lệ cho World-Check One Screening API. Các thông tin này phải được cấp quyền đọc dữ liệu hồ sơ và nhật ký kiểm tra.
API Base URL: Cấu hình tập lệnh với base URL chính xác cho môi trường World-Check API của bạn, ví dụ: https://api.world-check.com/v2/.
Khoảng thời gian: Thêm tham số start_date và end_date vào tập lệnh để xác định khoảng thời gian trích xuất. Với lần phân tích đầu tiên, nên chọn khoảng từ 3 đến 6 tháng. Để theo dõi liên tục, hãy chạy tập lệnh theo từng khoảng ngắn hơn, chẳng hạn ngày hoặc tuần trước đó.
Kết nối hệ thống nguồn: Cần thông tin kết nối đến các hệ thống đầu vào và đầu ra (ví dụ: CRM, nền tảng ngân hàng lõi) để lấy các sự kiện không thuộc hoạt động sàng lọc. Thông tin này có thể là chuỗi kết nối cơ sở dữ liệu hoặc endpoint API cùng thông tin xác thực.
Xử lý phân trang: Khi gọi API để liệt kê hồ sơ, tập lệnh cần chỉ định kích thước trang, thường gọi là limit. Giá trị từ 50 đến 100 thường cho hiệu quả tốt. Logic phải xử lý đúng việc lấy dữ liệu từ tất cả các trang.

Truy vấn mẫu 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()

Bạn đã sẵn sàng bắt đầu chưa?

Dùng mẫu dữ liệu này để bắt đầu hành trình process mining cho quy trình onboarding khách hàng KYC. Làm theo hướng dẫn để tìm ra thông tin hữu ích và cải thiện đáng kể hoạt động vận hành.

Quay lại hướng dẫn cải tiến

Tải mẫu xuống

Tối ưu onboarding khách hàng KYC ngay hôm nay, tăng cường tuân thủ

Giúp khách hàng hoàn tất onboarding thuận lợi và rút ngắn thời gian xuống còn 24 giờ.

Bắt đầu dùng thử miễn phí

Không cần thẻ tín dụng. Dùng miễn phí trong 14 ngày.

Mẫu dữ liệu onboarding khách hàng KYC

Mẫu dữ liệu onboarding khách hàng KYC

Thuộc tính onboarding khách hàng KYC

Hoạt động onboarding khách hàng KYC

Hướng dẫn trích xuất

Xuất hồ sơ và nhật ký kiểm tra Refinitiv World-Check One

Các bước

Cấu hình

Truy vấn mẫu sql

Tập lệnh Python dùng World-Check One Screening API

Các bước

Cấu hình

Truy vấn mẫu python

Bạn đã sẵn sàng bắt đầu chưa?

Tối ưu onboarding khách hàng KYC ngay hôm nay, tăng cường tuân thủ