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

Mẫu dữ liệu tiếp nhận khách hàng KYC

LexisNexis Risk Solutions

Thuộc tính của quy trình tiếp nhận khách hàng KYC(20) Các hoạt động trong quy trình tiếp nhận khách hàng KYC(14) Hướng dẫn trích xuất dữ liệu(1)

Mẫu dữ liệu tiếp nhận 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 tiếp nhận khách hàng KYC. Mẫu nêu rõ các thuộc tính cần thu thập, hoạt động chính cần theo dõi và cách trích xuất thông tin từ các hệ thống nguồn. Dùng tài nguyên này để tạo event log, từ đó hiểu sâu hơn về hành trình tiếp nhận khách hàng.

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 dữ liệu

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 của quy trình tiếp nhận khách hàng KYC

Đây là các trường dữ liệu nên có trong event log để phân tích và khám phá quy trình tiếp nhận khách hàng KYC.

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

	Tên	Mô tả
	Dấu thời gian sự kiện EventTimestamp	Ngày và giờ chính xác khi một hoạt động cụ thể bắt đầu.
Mô tả Dấu thời gian này ghi lại thời điểm bắt đầu hoạt động, qua đó xác định thứ tự thời gian của mọi sự kiện trong một hồ sơ. Đây là cơ sở cho mọi phân tích theo thời gian trong process mining. Dựa vào dấu thời gian sự kiện, bạn có thể tính thời lượng hoạt động, thời gian chờ giữa các hoạt động và tổng thời gian xử lý từ đầu đến cuối của quy trình đăng ký. Dữ liệu này rất cần thiết để xác định điểm nghẽn, theo dõi mức độ đáp ứng SLA và hiểu hiệu quả của quy trình. Vì sao điều này quan trọng Dấu thời gian này rất cần thiết để sắp xếp sự kiện theo trình tự thời gian và tính các chỉ số dựa trên thời gian, chẳng hạn như thời gian xử lý và điểm nghẽn. Lấy dữ liệu ở đâu Có trong nhật ký sự kiện hoặc bảng nhật ký kiểm tra, bên cạnh Tên hoạt động. Ví dụ 2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T14:15:00Z
	Đơn đăng ký khách hàng CustomerApplication	Mã định danh duy nhất cho từng đơn đăng ký khách hàng, được dùng làm mã hồ sơ chính.
Mô tả Đơn đăng ký khách hàng là mã định danh trung tâm, liên kết mọi hoạt động và dữ liệu liên quan đến hành trình đăng ký của một khách hàng. Mã này được tạo khi khách hàng gửi đơn và theo dõi hồ sơ cho đến khi hoàn tất hoặc bị từ chối. Trong process mining, thuộc tính này rất cần thiết để nhóm mọi sự kiện vào cùng một hồ sơ, giúp phân tích toàn bộ quy trình đăng ký từ đầu đến cuối. Nhờ đó, bạn có thể dựng lại toàn bộ luồng xử lý của từng người đăng ký. Đây là cơ sở để tính thời gian xử lý, phân tích các biến thể quy trình và theo dõi trạng thái đơn theo thời gian. Vì sao điều này quan trọng Đây là mã hồ sơ cốt lõi. Nếu không có mã này, bạn không thể theo dõi toàn bộ hành trình của đơn đăng ký khách hàng, khiến việc phân tích quy trình không thể thực hiện. Lấy dữ liệu ở đâu Đây là mã hồ sơ chính trong mô-đun quản lý hồ sơ của LexisNexis Risk Solutions. Ví dụ APP-2023-001234APP-2023-005678APP-2024-009101
	Tên hoạt động ActivityName	Tên tác vụ hoặc sự kiện cụ thể diễn ra tại một thời điểm trong quy trình đăng ký.
Mô tả Tên hoạt động mô tả một bước trong quy trình làm việc đăng ký KYC, chẳng hạn như 'Đã gửi đơn đăng ký', 'Đã rà soát tài liệu' hoặc 'Đã phê duyệt đơn đăng ký'. Mỗi hoạt động thể hiện một hành động hoặc cột mốc riêng trong quy trình. Thuộc tính này rất quan trọng để tạo sơ đồ quy trình, giúp trực quan hóa luồng hoạt động. Thuộc tính này cho phép phân tích các biến thể quy trình, điểm nghẽn giữa những bước cụ thể và tần suất xảy ra vòng lặp làm lại. Phân tích hoạt động là chìa khóa để hiểu quy trình đang diễn ra như thế nào. Vì sao điều này quan trọng Thuộc tính này là nền tảng của sơ đồ quy trình, giúp bạn trực quan hóa và phân tích thứ tự sự kiện trong hành trình đăng ký khách hàng. Lấy dữ liệu ở đâu Thường có trong nhật ký sự kiện hoặc bảng dấu vết kiểm toán của LexisNexis Risk Solutions, nơi ghi lại các bước trong quy trình. Ví dụ Đã gửi đơn đăng kýĐã thực hiện sàng lọc ban đầuĐã yêu cầu tài liệuĐã hoàn tất rà soát tuân thủ
	Mức độ rủi ro RiskLevel	Mức độ rủi ro được tính cho hồ sơ khách hàng, chẳng hạn như Thấp, Trung bình hoặc Cao.
Mô tả LexisNexis Risk Solutions chuyên đánh giá rủi ro. Thuộc tính này thể hiện kết quả đánh giá, phân loại từng hồ sơ theo mức độ rủi ro tiềm ẩn. Mức độ rủi ro thường quyết định phạm vi và thời lượng thẩm định cần thiết. Thuộc tính này là chiều phân tích chính trong bảng điều khiển “Mức độ rủi ro và thời gian tiếp nhận khách hàng”. Phân tích quy trình theo mức độ rủi ro giúp bạn biết hồ sơ rủi ro cao có mất nhiều thời gian hơn như dự kiến hay không, hoặc hồ sơ rủi ro thấp có bị chậm không cần thiết hay không. Qua đó, bạn có thể đánh giá và điều chỉnh chiến lược tiếp nhận khách hàng dựa trên mức độ rủi ro. Vì sao điều này quan trọng Rất quan trọng để phân tích theo mức độ rủi ro, giúp bạn hiểu hồ sơ rủi ro của khách hàng ảnh hưởng thế nào đến độ phức tạp, thời lượng và luồng xử lý. Lấy dữ liệu ở đâu Tham khảo tài liệu LexisNexis Risk Solutions hoặc hỏi quản trị viên hệ thống. Đây là kết quả chính từ các mô-đun đánh giá rủi ro. Ví dụ ThấpTrung bìnhCaoThuộc diện trừng phạt
	Ngày mục tiêu SLA SlaTargetDate	Ngày dự kiế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 xác định thời hạn hoàn tất hồ sơ theo thỏa thuận mức dịch vụ. Ngày này thường được xác định dựa trên loại hồ sơ, nhóm khách hàng hoặc khu vực pháp lý. Thuộc tính này rất cần thiết cho bảng điều khiển “Theo dõi mức độ đáp ứng mục tiêu SLA” và KPI “Tỷ lệ đáp ứng SLA”. Bằng cách so sánh ngày hoàn tất thực tế với Ngày mục tiêu SLA, tổ chức có thể đo lường mức độ đáp ứng cam kết, xác định hồ sơ có nguy cơ vi phạm SLA và tìm nguyên nhân gốc rễ gây chậm trễ. Vì sao điều này quan trọng Giúp đo lường hiệu suất so với thỏa thuận mức dịch vụ và phát hiện những điểm kém hiệu quả trong quy trình dẫn đến vi phạm SLA. Lấy dữ liệu ở đâu Tham khảo tài liệu LexisNexis Risk Solutions hoặc hỏi quản trị viên hệ thống. Ngày này có thể được lưu trong hồ sơ hoặc tính theo quy tắc nghiệp vụ. Ví dụ 2023-11-10T17:00:00Z2023-11-15T17:00:00Z2023-12-01T17:00:00Z
	Người dùng được giao AssignedUser	Mã định danh duy nhất của người dùng hoặc nhân viên phụ trách thực hiện hoạt động.
Mô tả Thuộc tính này cho biết chính xác ai đã thực hiện một tác vụ, chẳng hạn như nhân viên tuân thủ rà soát tài liệu. Thông tin này giúp phân tích cách phân bổ công việc và hiệu suất của từng người. Trong phân tích, Người dùng được giao là trường dữ liệu chính của bảng điều khiển “Phân bổ nguồn lực và khối lượng công việc”. Bạn có thể lọc sơ đồ quy trình theo người dùng, so sánh hiệu suất giữa các thành viên trong nhóm và tìm cơ hội đào tạo hoặc cân bằng lại khối lượng công việc. Thuộc tính này cũng giúp xác định điểm nghẽn do một nhóm người dùng cụ thể gây ra. Vì sao điều này quan trọng Thuộc tính này rất quan trọng để phân tích hiệu suất và khối lượng công việc của nhân sự, đồng thời tìm cơ hội tự động hóa hoặc sử dụng nguồn lực hiệu quả hơn. Lấy dữ liệu ở đâu Tham khảo tài liệu LexisNexis Risk Solutions hoặc hỏi quản trị viên hệ thống. Thông tin này thường có trong nhật ký kiểm tra hoặc bảng quản lý tác vụ. Ví dụ j.doem.smithk.chen
	Phòng ban Department	Phòng ban hoặc nhóm nghiệp vụ của người dùng được giao.
Mô tả Thuộc tính Phòng ban cho biết nhóm chức năng phụ trách một hoạt động, chẳng hạn như “Tuân thủ”, “Vận hành tiếp nhận khách hàng” hoặc “Phòng chống gian lận”. Bạn có thể dùng thuộc tính này để phân tích quy trình theo phòng ban và xem công việc được chuyển giao giữa các nhóm ra sao. Đây là chiều phân tích chính trong bảng điều khiển “Phân bổ nguồn lực và khối lượng công việc”, giúp phát hiện tình trạng kém hiệu quả giữa các nhóm chức năng hoặc chậm trễ trong giao tiếp giữa các phòng ban. Vì sao điều này quan trọng Giúp phân tích việc bàn giao và hiệu suất quy trình theo từng bộ phận chức năng, qua đó phát hiện điểm nghẽn giữa các phòng ban. Lấy dữ liệu ở đâu Tham khảo tài liệu LexisNexis Risk Solutions hoặc hỏi quản trị viên hệ thống. Có thể cần kết hợp dữ liệu từ bảng thông tin người dùng hoặc nhân sự. Ví dụ ComplianceNhóm tiếp nhận khách hàngChuyên viên phân tích KYCHỗ trợ khách hàng
	Thời gian kết thúc EndTime	Ngày và giờ chính xác khi một hoạt động hoàn tất.
Mô tả Dấu thời gian này ghi nhận thời điểm hoạt động hoàn tất. Khoảng thời gian từ Thời gian bắt đầu đến Thời gian kết thúc của một sự kiện chính là thời gian xử lý sự kiện đó. Thời gian kết thúc giúp tính chính xác thời lượng của từng bước. Đây là dữ liệu đầu vào chính cho bảng điều khiển “Thời gian xử lý và chờ của hoạt động”. Thông tin này giúp phân biệt thời gian người phụ trách thực sự xử lý một tác vụ với thời gian hồ sơ chờ bước tiếp theo bắt đầu. 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ừ đó xác định các bước kém hiệu quả và phân tích khối lượng công việc của nhân sự. Lấy dữ liệu ở đâu Tham khảo tài liệu LexisNexis Risk Solutions hoặc hỏi quản trị viên hệ thống. Thông tin này thường có trong nhật ký sự kiện ghi lại cả thời điểm bắt đầu và kết thúc. Ví dụ 2023-10-26T10:45:10Z2023-10-26T11:55:30Z2023-10-28T09:05:00Z
	Trạng thái hồ sơ ApplicationStatus	Trạng thái hiện tại hoặc trạng thái cuối cùng của hồ sơ khách hàng.
Mô tả Thuộc tính này cho biết trạng thái tổng thể của hồ sơ tại một thời điểm nhất định hoặc kết quả cuối cùng. Các trạng thái thường gặp gồm “Đang xử lý”, “Đã phê duyệt”, “Bị từ chối” hoặc “Chờ bổ sung thông tin”. Trạng thái hồ sơ rất quan trọng để theo dõi kết quả của quy trình tiếp nhận khách hàng. Thuộc tính này được dùng trong các bảng điều khiển “Lý do và giai đoạn từ chối hồ sơ” và “Số hồ sơ xử lý mỗi ngày và trạng thái hồ sơ” để theo dõi tỷ lệ thành công và luồng vận hành. Phân tích sự thay đổi trạng thái theo thời gian giúp bạn hiểu vòng đời của hồ sơ. Vì sao điều này quan trọng Theo dõi kết quả của từng hồ sơ, giúp tính các KPI quan trọng như Tỷ lệ từ chối hồ sơ và giám sát số lượng hồ sơ được xử lý. Lấy dữ liệu ở đâu Tham khảo tài liệu LexisNexis Risk Solutions hoặc hỏi quản trị viên hệ thống. Trường này thường nằm trong đối tượng hồ sơ hoặc đơn đăng ký chính. Ví dụ Đang xử lýĐã phê duyệtBị từ chốiChờ thông tin từ khách hàng
	Được tự động hóa IsAutomated	Cờ cho biết hoạt động do hệ thống tự động thực hiện hay do người dùng thao tác thủ công.
Mô tả Thuộc tính dạng đúng/sai này phân biệt tác vụ do hệ thống tự động thực hiện, chẳng hạn như bước sàng lọc ban đầu, với tác vụ cần người xử lý, chẳng hạn như rà soát tài liệu thủ công. “Được tự động hóa” được dùng để tính KPI “Tỷ lệ hoạt động thủ công” và phân tích hiệu quả của các sáng kiến tự động hóa. Trên sơ đồ quy trình, thuộc tính này giúp nhận diện điểm chuyển tiếp giữa các bước tự động và thủ công, từ đó tìm cơ hội tự động hóa thêm để giảm chi phí và thời gian xử lý. Vì sao điều này quan trọng Phân biệt tác vụ thủ công với tác vụ tự động, giúp xác định cơ hội tự động hóa và đo lường tác động của chúng. Lấy dữ liệu ở đâu Tham khảo tài liệu LexisNexis Risk Solutions hoặc hỏi quản trị viên hệ thống. Đây có thể là một cờ trong nhật ký sự kiện hoặc được suy ra từ “AssignedUser” (chẳng hạn người dùng “system”). Ví dụ truefalse
	Hệ thống nguồn SourceSystem	Hệ thống hoặc ứng dụng nơi dữ liệu sự kiện được tạo ra.
Mô tả Thuộc tính này cho biết hệ thống nguồn tạo ra dữ liệu sự kiện, chẳng hạn như LexisNexis Risk Solutions hoặc một công cụ bên thứ ba được tích hợp. Trong môi trường phức tạp, dữ liệu của một quy trình có thể đến từ nhiều hệ thống. Biết hệ thống nguồn sẽ giúp bạn xác thực dữ liệu, xử lý sự cố và phân tích những khác biệt trong quy trình có thể chỉ xuất hiện ở một hệ thống cụ thể. Thông tin này giúp đảm bảo tính toàn vẹn của dữ liệu, đồng thời cho biết hoạt động được ghi nhận ở đâu và bằng cách nào. Vì sao điều này quan trọng Cho biết dữ liệu bắt nguồn từ đâu. Đây là thông tin quan trọng để quản trị và xác thực dữ liệu, cũng như hiểu cách quy trình được thực hiện trên các hệ thống CNTT khác nhau. Lấy dữ liệu ở đâu Thông tin này có thể được lưu dưới dạng giá trị cố định hoặc trong một trường cụ thể của tệp xuất dữ liệu hay phản hồi API. Ví dụ LexisNexis Risk SolutionsThreatMetrixBridger Insight XG
	Kênh Channel	Kênh gửi hồ sơ, chẳng hạn như “Web”, “Di động” hoặc “Tại chi nhánh”.
Mô tả Thuộc tính Kênh cho biết hồ sơ được gửi từ đâu. Kênh có thể ảnh hưởng đến chất lượng dữ liệu, hành vi khách hàng và các vấn đề phát sinh trong quá trình tiếp nhận. Bạn có thể dùng thuộc tính này để so sánh hiệu suất quy trình giữa các kênh. Ví dụ, lọc bảng điều khiển “Tỷ lệ chuyển đổi qua phễu tiếp nhận khách hàng” theo kênh để xem tỷ lệ khách hàng bỏ dở trên di động có cao hơn trên web hay không. Kết quả giúp bạn cải thiện quy trình phù hợp với từng kênh. Vì sao điều này quan trọng Giúp phân tích hiệu suất quy trình theo kênh gửi hồ sơ, phát hiện khác biệt để điều chỉnh chiến lược kênh và cải thiện trải nghiệm người dùng. Lấy dữ liệu ở đâu Tham khảo tài liệu LexisNexis Risk Solutions hoặc hỏi quản trị viên hệ thống. Thông tin này thường được ghi nhận khi bắt đầu quy trình gửi hồ sơ. Ví dụ Cổng thông tin webỨng dụng di độngTại chi nhánhAPI
	Là công việc làm lại IsRework	Cờ đánh dấu các hoạt động thuộc một vòng lặp làm lại.
Mô tả Cờ dạng đúng/sai này được đặt thành true khi một hoạt động lặp lại trong cùng một hồ sơ. Ví dụ, hoạt động “Đã rà soát tài liệu” diễn ra lần thứ hai sau khi có yêu cầu bổ sung thông tin. Điều này cho thấy quy trình đã quay lại bước trước. “Là công việc làm lại” rất quan trọng đối với bảng điều khiển “Phân tích công việc làm lại và lặp lại” và KPI “Tỷ lệ vòng lặp làm lại”. Thuộc tính này giúp định lượng công sức bị lãng phí và tìm nguyên nhân gốc rễ, chẳng hạn như hướng dẫn chưa rõ hoặc dữ liệu kém chất lượng, để cải tiến quy trình đúng trọng tâm. Vì sao điều này quan trọng Định lượng trực tiếp tình trạng kém hiệu quả và công sức lãng phí trong quy trình, làm rõ những hoạt động thường phải lặp lại và khiến chi phí, thời gian xử lý tăng lên. Lấy dữ liệu ở đâu Đây là thuộc tính được tính toán, thường do công cụ process mining xác định bằng cách phát hiện các chuỗi hoạt động lặp lại trong một hồ sơ. 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 làm mới hoặc trích xuất từ hệ thống nguồn.
Mô tả Thuộc tính này ghi lại thời điểm bộ dữ liệu được cập nhật gần nhất. Thông tin thường được gắn cho toàn bộ bộ dữ liệu trong quá trình trích xuất và tải dữ liệu. Người dùng bảng điều khiển cần biết dữ liệu đang phân tích có mới hay không. Thông tin này giúp họ đưa ra quyết định dựa trên dữ liệu cập nhật ở mức cần thiết và hiểu rõ mức độ kịp thời của các kết quả phân tích. Vì sao điều này quan trọng Cho biết dữ liệu mới đến đâu, giúp đảm bảo kết quả phân tích còn phù hợp và quyết định không dựa trên thông tin đã lỗi thời. Lấy dữ liệu ở đâu Thông tin này thường được tạo và gắn vào bộ dữ liệu trong quá trình ETL (Trích xuất, Chuyển đổi, Tải). Ví dụ 2024-01-15T02:00:00Z2024-01-16T02:00:00Z2024-01-17T02:00:00Z
	Loại hồ sơ ApplicationType	Loại hồ sơ khách hàng, chẳng hạn như “Cá nhân” hoặc “Doanh nghiệp”.
Mô tả Thuộc tính này phân loại hồ sơ theo loại khách hàng đang được tiếp nhận. Mỗi loại hồ sơ thường có luồng xử lý, mức độ rủi ro và mục tiêu SLA riêng. Phân tích quy trình theo Loại hồ sơ giúp chia dữ liệu thành từng nhóm để so sánh hiệu quả và độ phức tạp khi tiếp nhận các nhóm khách hàng khác nhau. Đây là bộ lọc thường dùng trong hầu hết các bảng điều khiển, giúp bạn xem hiệu suất chi tiết hơn. Vì sao điều này quan trọng Giúp chia quy trình thành các nhóm để thấy cách xử lý từng loại hồ sơ và xác định điểm nghẽn riêng của mỗi loại. Lấy dữ liệu ở đâu Tham khảo tài liệu LexisNexis Risk Solutions hoặc hỏi quản trị viên hệ thống. Trường này thường nằm trong đối tượng hồ sơ hoặc đơn đăng ký chính. Ví dụ Cá nhânDoanh nghiệpCá nhân có tài sản ròng caoQuỹ tín thác
	Lý do từ chối RejectionReason	Mã hoặc mô tả giải thích lý do hồ sơ bị từ chối.
Mô tả Khi trạng thái cuối cùng của hồ sơ là “Bị từ chối”, thuộc tính này cho biết lý do cụ thể. Ví dụ: “Không xác minh được danh tính”, “Trùng khớp danh sách trừng phạt” hoặc “Thiếu giấy tờ”. Dữ liệu này là đầu vào chính cho bảng điều khiển “Lý do và giai đoạn từ chối hồ sơ”. Phân tích lý do từ chối giúp tìm ra những khâu thường khiến hồ sơ không đạt yêu cầu. Từ đó, bạn có thể cải thiện hướng dẫn nộp hồ sơ, cách trao đổi với khách hàng hoặc tiêu chí rà soát nội bộ. Hiểu rõ lý do hồ sơ bị từ chối là bước quan trọng để tăng tỷ lệ phê duyệt. Vì sao điều này quan trọng Cho biết trực tiếp lý do hồ sơ không hoàn tất quy trình tiếp nhận khách hàng, giúp bạn cải thiện đúng trọng tâm để tăng tỷ lệ phê duyệt. Lấy dữ liệu ở đâu Tham khảo tài liệu LexisNexis Risk Solutions hoặc hỏi quản trị viên hệ thống. Trường này thường được điền khi Trạng thái hồ sơ chuyển thành “Bị từ chối”. Ví dụ Trùng khớp danh sách trừng phạtThiếu giấy tờKhông xác minh được danh tínhHồ sơ rủi ro cao
	Người rà soát tuân thủ ComplianceReviewer	Người dùng hoặc nhân viên được giao phụ trách các hoạt động rà soát tuân thủ.
Mô tả “AssignedUser” ghi nhận người dùng thực hiện bất kỳ hoạt động nào, còn thuộc tính này chỉ rõ chuyên viên tuân thủ tham gia các bước rà soát quan trọng. Nhờ đó, bạn có thể phân tích riêng chức năng tuân thủ. Thuộc tính này là dữ liệu chính cho bảng điều khiển “Thời gian rà soát tuân thủ và hồ sơ tồn đọng”. Bạn có thể phân tích khối lượng công việc và hiệu suất của nhóm tuân thủ, xác định một số người rà soát có đang trở thành điểm nghẽn hay cả nhóm đang thiếu nguồn lực. Vì sao điều này quan trọng Giúp phân tích riêng chức năng tuân thủ, từ khối lượng công việc đến hiệu suất của người rà soát trong giai đoạn quan trọng thường bị chậm trễ này. Lấy dữ liệu ở đâu Tham khảo tài liệu LexisNexis Risk Solutions hoặc hỏi quản trị viên hệ thống. Có thể xác định thuộc tính này bằng cách lọc “AssignedUser” theo các hoạt động liên quan đến tuân thủ. Ví dụ c.joness.patelsystem_escalation
	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 quốc gia của khách hàng. Đây là yếu tố quan trọng trong KYC vì quy định quốc tế và mức độ rủi ro khác nhau giữa các khu vực pháp lý. Phân tích quy trình theo Quốc gia của khách hàng có thể cho thấy sự khác biệt đáng kể về thời gian xử lý và độ phức tạp. Ví dụ, hồ sơ từ khu vực có rủi ro cao có thể cần thêm bước kiểm tra tuân thủ, khiến thời gian xử lý kéo dài. Phân tích này giúp lập kế hoạch nguồn lực và đặt mục tiêu SLA phù hợp cho từng khu vực. Vì sao điều này quan trọng Giúp phân tích theo khu vực pháp lý, từ đó hiểu rõ quy định và yếu tố rủi ro tại từng vùng ảnh hưởng thế nào đến hiệu suất quy trình. Lấy dữ liệu ở đâu Tham khảo tài liệu LexisNexis Risk Solutions hoặc hỏi quản trị viên hệ thống. Đây là trường dữ liệu tiêu chuẩn trong hồ sơ khách hàng chính. Ví dụ USAGBRDEUSGP
	Thời gian xử lý toàn trình CycleTime	Tổng thời gian từ lúc khách hàng gửi hồ sơ đến khi có quyết định cuối cùng.
Mô tả Thời gian xử lý toàn trình đo tổng thời gian từ sự kiện đầu tiên, chẳng hạn “Đã gửi hồ sơ”, đến sự kiện cuối cùng, chẳng hạn “Hoàn tất tiếp nhận khách hàng” hoặc “Hồ sơ bị từ chối”, cho một hồ sơ. Đây là KPI chính để đo lường tình trạng chung của quy trình, được thể hiện trong bảng điều khiển “Thời gian xử lý toàn trình khi tiếp nhận khách hàng”. Theo dõi thời gian xử lý trung bình giúp tổ chức đánh giá tác động của các cải tiến quy trình và xác định những yếu tố như mức độ rủi ro hoặc loại hồ sơ ảnh hưởng thế nào đến trải nghiệm khách hàng. Vì sao điều này quan trọng Đây là chỉ số hiệu suất quan trọng, đo tổng thời gian khách hàng chờ nhận được giá trị, ảnh hưởng trực tiếp đến mức độ hài lòng của khách hàng và hiệu quả vận hành. Lấy dữ liệu ở đâu Đây là chỉ số được tính bằng cách lấy dấu thời gian của sự kiện đầu tiên trừ khỏi dấu thời gian của sự kiện cuối cùng trong từng hồ sơ. Ví dụ 5 ngày 4 giờ22 ngày 8 giờ1 ngày 2 giờ
	Trạng thái SLA SlaStatus	Cho biết hồ sơ đã hoàn tất có đáp ứng mục tiêu SLA hay không.
Mô tả Thuộc tính này phân loại từng hồ sơ đã hoàn tất dựa trên mức độ đáp ứng “SlaTargetDate”. Các giá trị thường gặp là “Đạt” hoặc “Vi phạm”. Trường được tính toán này là nền tảng cho bảng điều khiển “Theo dõi mức độ đáp ứng mục tiêu SLA” và KPI “Tỷ lệ đáp ứng SLA”. Thuộc tính này cung cấp cái nhìn tổng quan rõ ràng về hiệu suất so với cam kết dịch vụ, đồng thời cho phép phân tích sâu hơn để tìm đặc điểm chung của các hồ sơ vi phạm SLA. Vì sao điều này quan trọng Cho biết rõ hồ sơ có đáp ứng SLA hay không, giúp bạn dễ theo dõi, báo cáo và phân tích mức độ tuân thủ mục tiêu dịch vụ. Lấy dữ liệu ở đâu Đây là thuộc tính được tính toán bằng cách so sánh dấu thời gian của hoạt động cuối cùng với “SlaTargetDate” của từng hồ sơ. Ví dụ ĐạtVi phạmCó nguy cơ trễ hạn

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

Các hoạt động trong quy trình tiếp nhận khách hàng KYC

Đây là các bước và mốc chính cần ghi lại trong event log để khám phá quy trình và phân tích hiệu suất chính xác.

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

	Hoạt động	Mô tả
	Đã bắt đầu rà soát tuân thủ	Hồ sơ được giao cho nhân viên hoặc nhóm phụ trách tuân thủ để rà soát thủ công, thường áp dụng với đơn có rủi ro cao. Có thể suy ra bước này từ thay đổi trạng thái thành 'Pending Compliance Review' hoặc từ nhật ký phân công tác vụ.
Vì sao điều này quan trọng Đây là thời điểm bắt đầu bước rà soát thủ công, thường kéo dài. Đo thời gian từ lúc này đến khi hoàn tất giúp xác định mức độ ảnh hưởng của điểm nghẽn liên quan đến tuân thủ. Lấy dữ liệu ở đâu Dữ liệu được lấy từ nhật ký phân công tác vụ, thay đổi người phụ trách hồ sơ sang nhóm tuân thủ hoặc cập nhật trạng thái trong lịch sử hồ sơ. Thu thập Có thể suy ra từ thay đổi trạng thái như 'Under Compliance Review' hoặc khi hồ sơ được giao vào hàng đợi của người dùng phụ trách tuân thủ. Loại sự kiện inferred
	Đã gửi đơn đăng ký	Đánh dấu thời điểm bắt đầu quy trình đăng ký KYC, khi hệ thống nhận được đơn đăng ký của khách hàng. Sự kiện này thường được ghi nhận rõ ràng khi khách hàng gửi biểu mẫu qua cổng thông tin hoặc hệ thống nhập liệu nội bộ được kết nối với LexisNexis.
Vì sao điều này quan trọng Đây là sự kiện bắt đầu chính của quy trình. Phân tích thời gian từ hoạt động này đến khi hoàn tất là điều cần thiết để đo thời gian xử lý từ đầu đến cuối và mức độ đáp ứng SLA. Lấy dữ liệu ở đâu Dữ liệu được lấy từ nhật ký hệ thống hoặc bảng đơn đăng ký có ghi dấu thời gian tạo hồ sơ khách hàng mới. Thu thập Sự kiện được ghi lại khi tạo hồ sơ đăng ký mới hoặc thêm bản ghi vào bảng đơn đăng ký chính. Loại sự kiện explicit
	Đã hoàn tất đăng ký khách hàng	Sự kiện này đánh dấu toàn bộ quy trình đăng ký đã kết thúc thành công và xác nhận khách hàng đã được kích hoạt đầy đủ. Sự kiện có thể được ghi rõ là trạng thái cuối cùng hoặc suy ra từ sự kiện 'Account Activated'.
Vì sao điều này quan trọng Đây là sự kiện kết thúc chính, đánh dấu trạng thái thành công. Sự kiện này rất cần thiết để tính thời gian xử lý từ đầu đến cuối cho tất cả khách hàng đăng ký thành công. Lấy dữ liệu ở đâu Có thể suy ra từ dấu thời gian 'Account Activated' hoặc lấy từ trạng thái cuối cùng trong hồ sơ, chẳng hạn như 'Onboarding Complete'. Thu thập Có thể suy ra từ sự kiện tích cực quan trọng cuối cùng, chẳng hạn như kích hoạt tài khoản, hoặc từ cập nhật trạng thái cuối cùng. Loại sự kiện inferred
	Đã hoàn tất rà soát tuân thủ	Nhân viên phụ trách tuân thủ hoàn tất việc rà soát và đưa ra đề xuất, chuyển hồ sơ sang giai đoạn tiếp theo. Có thể ghi nhận rõ ràng khi tác vụ được đánh dấu 'complete' hoặc suy ra từ việc trạng thái chuyển từ 'Pending Compliance' sang trạng thái khác.
Vì sao điều này quan trọng Đây là cột mốc quan trọng, kết thúc một phần then chốt và thường được thực hiện thủ công trong quy trình. Mốc này dùng để đo thời lượng rà soát tuân thủ. Lấy dữ liệu ở đâu Dữ liệu được lấy từ dấu thời gian hoàn tất tác vụ tuân thủ hoặc thay đổi trạng thái rời khỏi 'Under Compliance Review'. Thu thập Có thể suy ra từ thay đổi trạng thái cho biết việc rà soát đã kết thúc, chẳng hạn chuyển sang 'Approved', 'Rejected' hoặc 'Final Decision'. Loại sự kiện inferred
	Đã nhận tài liệu	Xác nhận khách hàng đã tải lên hoặc cung cấp các tài liệu cần thiết cho hệ thống. Sự kiện này thường được tạo rõ ràng bởi cổng gửi tài liệu hoặc do nhân viên nhập thủ công.
Vì sao điều này quan trọng Hoạt động này kết thúc một khoảng thời gian chờ và kích hoạt các bước rà soát tiếp theo. Đây là cột mốc quan trọng trong giai đoạn thu thập dữ liệu. Lấy dữ liệu ở đâu Dữ liệu được lấy từ nhật ký hệ thống quản lý tài liệu hoặc mục có dấu thời gian trong hồ sơ đơn đăng ký khi tài liệu mới được đính kèm. Thu thập Sự kiện được ghi lại khi tài liệu tải lên thành công hoặc được đánh dấu thủ công là đã nhận trong hệ thống. Loại sự kiện explicit
	Đã phê duyệt đơn đăng ký	Quyết định cuối cùng về việc phê duyệt đơn đăng ký của khách hàng được đưa ra và ghi lại trong hệ thống. Đây là kết quả kinh doanh quan trọng và hầu như luôn được ghi nhận rõ ràng qua thay đổi trạng thái.
Vì sao điều này quan trọng Cột mốc này đánh dấu quá trình ra quyết định đã kết thúc thành công. Phân tích các luồng dẫn đến phê duyệt giúp xác định cách làm hiệu quả. Lấy dữ liệu ở đâu Tìm cập nhật trạng thái cuối cùng trong hồ sơ đơn đăng ký, trong đó trạng thái được đặt thành 'Approved' hoặc trạng thái kết thúc tương tự. Thu thập Được ghi lại dưới dạng thay đổi trạng thái cuối cùng, xác định rõ trong bảng đơn đăng ký hoặc hồ sơ chính. Loại sự kiện explicit
	Đã thực hiện đánh giá rủi ro	Dựa trên thông tin thu thập được và các bước kiểm tra đã thực hiện, hệ thống tính điểm rủi ro cho khách hàng. Đây là tính năng cốt lõi của LexisNexis và thường được ghi lại rõ ràng dưới dạng sự kiện tự động trong lịch sử hồ sơ.
Vì sao điều này quan trọng Kết quả đánh giá thường quyết định luồng xử lý tiếp theo, chẳng hạn như có cần thẩm định tăng cường hay không. Đây là điểm ra quyết định quan trọng trong quy trình làm việc. Lấy dữ liệu ở đâu Tìm sự kiện trong nhật ký kiểm toán hoặc lịch sử quy trình làm việc của đơn đăng ký, ghi lại thời điểm mô-đun chấm điểm hoặc đánh giá rủi ro hoàn tất. Thu thập Một sự kiện cụ thể được ghi lại khi công cụ đánh giá rủi ro hoàn tất phân tích và gán hồ sơ hoặc điểm rủi ro. Loại sự kiện explicit
	Đã từ chối đơn đăng ký	Quyết định cuối cùng về việc từ chối đơn đăng ký của khách hàng được ghi lại. Đây là sự kiện kết thúc và được ghi nhận qua thay đổi trạng thái xác định rõ trong hệ thống.
Vì sao điều này quan trọng Đây là sự kiện kết thúc chính, đánh dấu trạng thái không thành công. Phân tích các giai đoạn xảy ra việc từ chối và lý do liên quan là điều cần thiết để cải tiến quy trình. Lấy dữ liệu ở đâu Dữ liệu được lấy từ trường trạng thái cuối cùng của hồ sơ đơn đăng ký, khi trạng thái được đặt thành 'Rejected', 'Declined' hoặc trạng thái kết thúc tương tự. Thu thập Được ghi lại dưới dạng thay đổi trạng thái cuối cùng, xác định rõ trong bảng đơn đăng ký hoặc hồ sơ chính. Loại sự kiện explicit
	Đã bắt đầu xác minh danh tính	Đánh dấu thời điểm hệ thống bắt đầu bước xác minh danh tính chính bằng các dịch vụ của LexisNexis, chẳng hạn như đối chiếu với cơ sở dữ liệu. Thông thường, nhật ký sự kiện ghi lại rõ ràng thời điểm dịch vụ xác minh được gọi.
Vì sao điều này quan trọng Hoạt động này đánh dấu thời điểm bắt đầu một quy trình con quan trọng, thường tốn nhiều thời gian. Theo dõi thời lượng giúp xác định riêng các điểm nghẽn liên quan đến việc kiểm tra danh tính. Lấy dữ liệu ở đâu Dữ liệu được lấy từ nhật ký API gọi mô-đun xác minh danh tính hoặc mục trong dấu vết kiểm toán ghi lại thời điểm bắt đầu tác vụ xác minh. Thu thập Sự kiện được ghi lại khi mô-đun hoặc API xác minh danh tính của hệ thống được kích hoạt cho đơn đăng ký. Loại sự kiện explicit
	Đã kích hoạt tài khoản	Sau khi được phê duyệt, tài khoản khách hàng được tạo chính thức và kích hoạt trên nền tảng ngân hàng hoặc dịch vụ cốt lõi. Hoạt động này thường được ghi lại trong dấu vết kiểm toán hoặc suy ra từ ngày tạo tài khoản.
Vì sao điều này quan trọng Đây là bước cuối cùng mang lại giá trị cho khách hàng. Chậm trễ giữa 'Application Approved' và bước này có thể cho thấy vấn đề khi kết nối các hệ thống. Lấy dữ liệu ở đâu Dữ liệu được lấy từ nhật ký tạo tài khoản, lệnh gọi API đến hệ thống khác hoặc dấu thời gian tạo bản ghi tài khoản. Thu thập Được ghi lại như một sự kiện riêng sau khi phê duyệt hoặc xác định qua dấu thời gian kích hoạt trên hồ sơ khách hàng. Loại sự kiện explicit
	Đã rà soát tài liệu	Người dùng hoặc công cụ tự động rà soát tài liệu đã gửi để kiểm tra tính xác thực, hiệu lực và mức độ đầy đủ. Có thể suy ra hoạt động này từ thay đổi trạng thái từ 'Documents Received' sang 'Review Complete' hoặc từ mục nhật ký được ghi rõ.
Vì sao điều này quan trọng Đây là nguyên nhân phổ biến gây ra điểm nghẽn và việc làm lại. Phân tích thời gian xử lý và số lần lặp lại là yếu tố then chốt để nâng cao hiệu quả và tìm cơ hội tự động hóa. Lấy dữ liệu ở đâu Có thể suy ra hoạt động này bằng cách theo dõi thời gian từ trạng thái 'Documents Received' đến trạng thái tiếp theo như 'Verification Passed' hoặc 'Additional Info Required'. Thu thập Được tính bằng thời gian từ sự kiện nhận tài liệu đến sự kiện đánh dấu hoàn tất việc rà soát. Loại sự kiện inferred
	Đã thực hiện sàng lọc ban đầu	Ngay sau khi nhận đơn, hệ thống tự động kiểm tra để xác nhận dữ liệu cơ bản đã đầy đủ và thực hiện các bước kiểm tra sơ bộ. Hoạt động này thường được ghi lại rõ ràng như một bước tự động trong lịch sử quy trình làm việc.
Vì sao điều này quan trọng Hoạt động này xác định các đơn không đạt yêu cầu ngay từ bước đầu, giúp tìm hiểu vấn đề về chất lượng dữ liệu. Đây cũng là bước đầu tiên trong quy trình tạo ra giá trị tự động. Lấy dữ liệu ở đâu Tìm nhật ký thực thi quy tắc tự động hoặc thay đổi trạng thái trong lịch sử quy trình làm việc của đơn, cho biết bước sàng lọc ban đầu đã hoàn tất. Thu thập Được ghi lại dưới dạng tác vụ tự động đã hoàn tất hoặc cập nhật trạng thái cụ thể trong lịch sử hồ sơ. Loại sự kiện explicit
	Đã yêu cầu tài liệu	Hệ thống hoặc người dùng yêu cầu khách hàng cung cấp tài liệu cụ thể, chẳng hạn như giấy phép lái xe hoặc hóa đơn điện nước. Có thể lấy sự kiện này từ nhật ký liên lạc do hệ thống tạo hoặc thay đổi trạng thái cho biết hồ sơ đang chờ tài liệu.
Vì sao điều này quan trọng Hoạt động này thường làm tăng đáng kể thời gian chờ trong quy trình. Phân tích tần suất và thời lượng giúp xác định chậm trễ do khách hàng phản hồi. Lấy dữ liệu ở đâu Kiểm tra nhật ký liên lạc gửi cho khách hàng hoặc thay đổi trạng thái đơn đăng ký, chẳng hạn như 'Pending Customer Documents'. Thu thập Suy ra từ thay đổi trạng thái thành 'Awaiting Documents' hoặc dấu thời gian trong nhật ký liên lạc gửi đi. Loại sự kiện inferred
	Đã yêu cầu thông tin bổ sung	Nhân viên phụ trách tuân thủ hoặc người rà soát yêu cầu khách hàng cung cấp thêm thông tin hoặc giải thích. Đây là nguyên nhân chính dẫn đến việc làm lại và thường được ghi nhận rõ ràng qua thay đổi trạng thái hoặc mục nhật ký liên lạc.
Vì sao điều này quan trọng Hoạt động này tạo ra các vòng lặp làm lại, kéo dài thời gian xử lý hồ sơ. Theo dõi tần suất giúp xác định yêu cầu chưa rõ hoặc những thiếu sót thường gặp trong đơn đăng ký. Lấy dữ liệu ở đâu Tìm thay đổi trạng thái thành 'Pending Customer Information' hoặc sự kiện trong nhật ký liên lạc gửi đi. Thường người dùng sẽ chủ động thực hiện thao tác này. Thu thập Được ghi lại khi nhân viên dùng tính năng 'Request Information', làm thay đổi trạng thái hồ sơ và có thể tạo mục nhật ký liên lạc. Loại sự kiện explicit

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

Hướng dẫn trích xuất dữ liệu

Cách lấy dữ liệu từ LexisNexis Risk Solutions

Các bước

Chuẩn bị môi trường Python: Cài Python 3.8 trở lên trên hệ thống. Mở terminal hoặc dấu nhắc lệnh, rồi cài các thư viện cần thiết bằng lệnh pip install requests pandas.
Lấy thông tin xác thực API: Liên hệ quản trị viên LexisNexis Risk Solutions hoặc đại diện tài khoản để lấy thông tin xác thực API. Bạn cần API Key, API Secret và Base URL cho các điểm cuối API.
Cấu hình tập lệnh Python: Mở tập lệnh Python được cung cấp bằng trình soạn thảo văn bản. Tìm phần cấu hình ở đầu tệp và thay các giá trị giữ chỗ của API_KEY, API_SECRET và BASE_URL bằng thông tin xác thực thực tế của bạn.
Đặt thông số trích xuất: Trong cùng phần cấu hình, xác định khoảng thời gian trích xuất dữ liệu bằng cách đặt các biến START_DATE và END_DATE. Định dạng ngày là 'YYYY-MM-DD'. Bạn nên bắt đầu với khoảng thời gian ngắn, chẳng hạn một tháng, để thử trích xuất.
Kiểm tra ánh xạ hoạt động: Xem từ điển ACTIVITY_MAP trong tập lệnh. Từ điển này ánh xạ các loại sự kiện trong phản hồi API LexisNexis sang tên hoạt động chuẩn dùng trong event log. Bạn có thể cần điều chỉnh các khóa, tức các giá trị bên trái, theo tên sự kiện trong cấu hình LexisNexis của mình. Hãy xem phản hồi API mẫu để tìm các tên này.
Chạy tập lệnh: Chạy tập lệnh từ terminal bằng lệnh python your_script_name.py. Tập lệnh sẽ xác thực, lấy danh sách đơn đăng ký khách hàng trong khoảng ngày đã chọn, rồi truy xuất lịch sử sự kiện của từng đơn.
Theo dõi tiến trình: Tập lệnh sẽ in thông báo tiến độ ra bảng điều khiển, chẳng hạn số đơn đăng ký đang được xử lý. Hãy chú ý các thông báo lỗi, vì chúng có thể cho biết vấn đề về thông tin xác thực, điểm cuối API hoặc giới hạn tần suất gọi.
Lấy tệp đầu ra: Khi chạy xong, tập lệnh sẽ tạo tệp lexisnexis_event_log.csv trong cùng thư mục. Tệp này chứa event log đã trích xuất.
Chuẩn bị tải lên: Trước khi tải lên công cụ process mining, hãy mở tệp CSV và kiểm tra các cột cần có: CustomerApplication, ActivityName, EventTimestamp và các cột khác. Xác nhận dữ liệu chính xác và nhất quán.
Tải lên ProcessMind: Tải tệp lexisnexis_event_log.csv vừa tạo lên ứng dụng process mining, rồi ánh xạ các cột tương ứng với trường mã hồ sơ, hoạt động và dấu thời gian.

Cấu hình

Thông tin xác thực API: Cần API Key và Secret hợp lệ để xác thực. Hãy xin thông tin này từ quản trị viên LexisNexis và giữ bí mật.
Điểm cuối API: Tập lệnh phải được cấu hình đúng Base URL cho REST API của LexisNexis. Mã tập lệnh xác định các điểm cuối cụ thể để lấy đơn đăng ký và lịch sử sự kiện.
Khoảng ngày: Các tham số START_DATE và END_DATE xác định khoảng thời gian trích xuất. Để đảm bảo hiệu suất và tránh chạm giới hạn tần suất gọi API, bạn nên trích xuất theo từng đợt từ 3 đến 6 tháng.
Ánh xạ hoạt động: Từ điển ACTIVITY_MAP là phần cấu hình quan trọng. Hãy xác nhận tên sự kiện nguồn từ API, được dùng làm khóa trong từ điển, khớp với tên do hệ thống của bạn tạo ra. Sự kiện không được ánh xạ sẽ bị bỏ qua.
Giới hạn tần suất gọi: Tập lệnh có khoảng nghỉ cơ bản giữa các lần gọi API để đáp ứng giới hạn tần suất có thể áp dụng. Với tập dữ liệu rất lớn, bạn có thể cần điều chỉnh giá trị API_CALL_DELAY_SECONDS hoặc triển khai cơ chế chờ tăng dần phù hợp hơn.
Điều kiện cần có: Phương pháp này yêu cầu hệ thống đã cài Python 3.x cùng các thư viện requests và pandas. Người dùng hoặc tài khoản dịch vụ chạy tập lệnh phải có đủ quyền truy cập API LexisNexis.

Truy vấn mẫu python

import requests
import pandas as pd
import time
import json
from datetime import datetime

class=class="hl-string">"hl-comment"># --- Configuration Section --- #
class=class="hl-string">"hl-comment"># Replace with your actual LexisNexis API credentials and endpoints
API_KEY = class="hl-string">'[Your_API_Key]'
API_SECRET = class="hl-string">'[Your_API_Secret]'
BASE_URL = class="hl-string">'[https://api.example.lexisnexis.com/v1]' class=class="hl-string">"hl-comment"># e.g., your specific API gateway URL

class=class="hl-string">"hl-comment"># Set the date range for the extraction
START_DATE = class="hl-string">'2023-01-01'
END_DATE = class="hl-string">'2023-06-30'

class=class="hl-string">"hl-comment"># Delay between API calls to avoid rate limiting
API_CALL_DELAY_SECONDS = 0.5

class=class="hl-string">"hl-comment"># Mapping from LexisNexis event types to standard activity names
class=class="hl-string">"hl-comment"># CRITICAL: The keys of this dictionary must be adjusted to match the event names
class=class="hl-string">"hl-comment"># returned by your specific LexisNexis API endpoint.
ACTIVITY_MAP = {
    class="hl-string">'application.submitted': class="hl-string">'Application Submitted',
    class="hl-string">'screening.initial.performed': class="hl-string">'Initial Screening Performed',
    class="hl-string">'verification.identity.initiated': class="hl-string">'Identity Verification Initiated',
    class="hl-string">'documents.requested': class="hl-string">'Documents Requested',
    class="hl-string">'documents.received': class="hl-string">'Documents Received',
    class="hl-string">'review.document.performed': class="hl-string">'Document Review Performed',
    class="hl-string">'assessment.risk.performed': class="hl-string">'Risk Assessment Performed',
    class="hl-string">'review.compliance.initiated': class="hl-string">'Compliance Review Initiated',
    class="hl-string">'information.additional.requested': class="hl-string">'Additional Information Requested',
    class="hl-string">'review.compliance.completed': class="hl-string">'Compliance Review Completed',
    class="hl-string">'application.approved': class="hl-string">'Application Approved',
    class="hl-string">'account.activated': class="hl-string">'Account Activated',
    class="hl-string">'onboarding.completed': class="hl-string">'Customer Onboarding Completed',
    class="hl-string">'application.rejected': class="hl-string">'Application Rejected'
}

def get_auth_token():
    class="hl-string">"""Handles authentication and returns an access token."""
    class=class="hl-string">"hl-comment"># This is a placeholder for the actual authentication mechanism.
    class=class="hl-string">"hl-comment"># Adjust according to LexisNexis API documentation (e.g., OAuth2).
    class=class="hl-string">"hl-comment"># For simplicity, we assume the API Key can be used directly in a header.
    class=class="hl-string">"hl-comment"># In a real scenario, you might POST to a token endpoint.
    print(class="hl-string">"Authentication successful (simulated).")
    return fclass="hl-string">'Bearer {API_KEY}' class=class="hl-string">"hl-comment"># Simplified for example purposes

def main():
    class="hl-string">"""Main function to orchestrate the data extraction process."""
    auth_token = get_auth_token()
    if not auth_token:
        print(class="hl-string">"Failed to authenticate. Exiting.")
        return

    headers = {
        class="hl-string">'Authorization': auth_token,
        class="hl-string">'Content-Type': class="hl-string">'application/json'
    }

    print(fclass="hl-string">"Fetching applications from {START_DATE} to {END_DATE}...")
    
    class=class="hl-string">"hl-comment"># 1. Fetch all application IDs within the date range
    try:
        applications_endpoint = fclass="hl-string">'{BASE_URL}/applications'
        params = {class="hl-string">'startDate': START_DATE, class="hl-string">'endDate': END_DATE}
        response = requests.get(applications_endpoint, headers=headers, params=params)
        response.raise_for_status()
        applications = response.json().get(class="hl-string">'applications', [])
        print(fclass="hl-string">"Found {len(applications)} applications to process.")
    except requests.exceptions.RequestException as e:
        print(fclass="hl-string">"Error fetching applications: {e}")
        return

    all_events = []

    class=class="hl-string">"hl-comment"># 2. For each application, fetch its detailed event history
    for i, app in enumerate(applications):
        app_id = app.get(class="hl-string">'customerApplicationId')
        if not app_id:
            continue

        print(fclass="hl-string">"Processing application {i+1}/{len(applications)}: {app_id}")
        try:
            events_endpoint = fclass="hl-string">'{BASE_URL}/applications/{app_id}/events'
            event_response = requests.get(events_endpoint, headers=headers)
            event_response.raise_for_status()
            events_data = event_response.json().get(class="hl-string">'events', [])
            
            class=class="hl-string">"hl-comment"># 3. Parse events and map them to the event log format
            for event in events_data:
                event_type = event.get(class="hl-string">'eventType')
                if event_type in ACTIVITY_MAP:
                    activity_name = ACTIVITY_MAP[event_type]
                    
                    class=class="hl-string">"hl-comment"># Extract attributes, using .get() to handle missing data gracefully
                    record = {
                        class="hl-string">'CustomerApplication': app_id,
                        class="hl-string">'ActivityName': activity_name,
                        class="hl-string">'EventTimestamp': event.get(class="hl-string">'eventTimestamp'),
                        class="hl-string">'EndTime': event.get(class="hl-string">'eventCompletionTimestamp', None), class=class="hl-string">"hl-comment"># Optional
                        class="hl-string">'AssignedUser': event.get(class="hl-string">'userId', class="hl-string">'System'),
                        class="hl-string">'Department': event.get(class="hl-string">'userDepartment', None),
                        class="hl-string">'ApplicationStatus': event.get(class="hl-string">'applicationStatusAfterEvent'),
                        class="hl-string">'RiskLevel': event.get(class="hl-string">'riskAssessment', {}).get(class="hl-string">'level', None),
                        class="hl-string">'SlaTargetDate': app.get(class="hl-string">'slaTargetDate', None)
                    }
                    all_events.append(record)

        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">"Could not fetch events for application {app_id}: {e}")
        
        time.sleep(API_CALL_DELAY_SECONDS)

    if not all_events:
        print(class="hl-string">"No events were extracted. The output file will be empty.")
        return

    class=class="hl-string">"hl-comment"># 4. Create a DataFrame and save to CSV
    df = pd.DataFrame(all_events)
    df[class="hl-string">'EventTimestamp'] = pd.to_datetime(df[class="hl-string">'EventTimestamp'])
    df.sort_values(by=[class="hl-string">'CustomerApplication', class="hl-string">'EventTimestamp'], inplace=True)
    
    output_filename = class="hl-string">'lexisnexis_event_log.csv'
    df.to_csv(output_filename, index=False, date_format=class="hl-string">'%Y-%m-%d %H:%M:%S')
    print(fclass="hl-string">"Extraction complete. Event log saved to {output_filename}")

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

Bắt đầu ngay?

Dùng mẫu này để bắt đầu hành trình process mining cho quy trình tiếp nhận khách hàng KYC. Hãy chuyển dữ liệu của bạn thành thông tin hữu ích ngay hôm nay.

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

Tải mẫu xuống

Cải thiện quy trình tiếp nhận KYC, giảm tình trạng bỏ dở ngay hôm nay

Giúp khách hàng hoàn tất quy trình tiếp nhận dễ dàng hơn, 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. Bắt đầu cải thiện quy trình ngay hôm nay.

Mẫu dữ liệu tiếp nhận khách hàng KYC

Mẫu dữ liệu tiếp nhận khách hàng KYC

Thuộc tính của quy trình tiếp nhận khách hàng KYC

Các hoạt động trong quy trình tiếp nhận khách hàng KYC

Hướng dẫn trích xuất dữ liệu

Trích xuất dữ liệu LexisNexis qua API bằng tập lệnh Python

Các bước

Cấu hình

Truy vấn mẫu python

Bắt đầu ngay?

Cải thiện quy trình tiếp nhận KYC, giảm tình trạng bỏ dở ngay hôm nay