KYC 고객 온보딩 데이터 템플릿
KYC 고객 온보딩 데이터 템플릿
- 수집 권장 속성
- 추적할 주요 활동
- 데이터 추출 안내
KYC 고객 온보딩 속성
| 이름 | 설명 | ||
|---|---|---|---|
| 고객 신청 CustomerApplication | 고객 온보딩 절차 하나를 식별하는 고유 식별자로, 기본 케이스 식별자 역할을 합니다. | ||
| 설명 고객 신청은 한 고객의 KYC 온보딩 프로세스와 관련된 모든 활동과 이벤트를 묶는 기준 식별자입니다. 신청서 제출부터 승인, 거부 또는 종료까지 전체 진행 과정을 추적할 수 있습니다. process mining에서 이 속성은 각 신청의 전체 진행 과정을 재구성하는 데 필수적입니다. 신청별 프로세스 흐름, 처리 시간, 편차와 병목을 분석해 개별 케이스가 어떻게 처리되는지 파악할 수 있습니다. 중요한 이유 관련 이벤트를 연결하는 필수 케이스 ID로, 고객 온보딩 프로세스 전체를 분석할 수 있게 합니다. 확보 방법 일반적으로 Fenergo의 핵심 케이스 관리 또는 고객 라이프사이클 관리 엔터티에서 기본 키로 사용됩니다. 예시 APP-2023-00123APP-2023-00124APP-2023-00125 | |||
| 시작 시간 EventStartTime | 활동 또는 이벤트가 공식적으로 시작된 시점을 나타내는 타임스탬프입니다. | ||
| 설명 이 속성은 특정 활동이 시작된 정확한 날짜와 시간을 기록합니다. 프로세스 흐름을 재구성하는 데 필요한 시간 순서를 제공하며, 시간 기반 분석에 필수적입니다. process mining에서는 시작 시간을 사용해 활동별 소요 시간, 활동 간 대기 시간, 케이스 전체 처리 시간을 계산합니다. 이벤트 로그의 시간 정보를 구성하는 기준이며, 성과와 병목 분석에 중요합니다. 중요한 이유 이 타임스탬프는 이벤트를 시간순으로 정렬하고 처리 시간과 소요 시간 등 시간 기반 지표를 계산하는 데 필수적입니다. 확보 방법 Fenergo의 감사 추적, 이벤트 로그 또는 워크플로 이력 테이블에서 확인할 수 있습니다. 'Timestamp', 'StartDate', 'CreationDate' 등의 이름으로 표시되는 경우가 많습니다. 예시 2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:15:00Z | |||
| 활동명 ActivityName | 온보딩 프로세스에서 특정 시점에 발생한 업무 이벤트 또는 작업의 이름입니다. | ||
| 설명 활동명은 고객 온보딩 과정의 개별 단계나 주요 시점을 나타냅니다. 예를 들어 '초기 심사 수행' 또는 '신청 승인'이 있습니다. 이러한 활동의 순서가 프로세스 맵의 기반이 됩니다. 이 속성을 분석하면 프로세스 흐름을 시각화하고, 일반 경로와 대체 경로를 파악하며, 각 단계의 발생 빈도를 측정할 수 있습니다. 어떤 작업이 어떤 순서로 수행되는지 이해하는 데 중요합니다. 중요한 이유 이 속성은 프로세스의 단계를 정의하며, 프로세스 맵을 작성하고 흐름과 편차를 분석하는 데 사용됩니다. 확보 방법 일반적으로 Fenergo의 워크플로 또는 감사 로그 테이블에서 확인할 수 있으며, 케이스 상태 변경이나 작업 완료 기록과 연결됩니다. 예시 데이터 및 서류 요청규정 준수 검토 시작신청 승인 | |||
| 소스 시스템 SourceSystem | 데이터를 추출한 기준 시스템입니다. | ||
| 설명 이 속성은 이벤트 데이터가 생성된 시스템을 식별합니다. 이 프로세스에서는 항상 Fenergo를 가리키지만, 여러 데이터가 결합된 데이터 세트에서는 데이터 출처를 구분하는 데 도움이 됩니다. 분석 시 특정 시스템의 데이터만 필터링하거나 데이터 출처를 확인하는 데 주로 사용됩니다. 여러 시스템의 데이터를 결합해 전체 프로세스를 파악하는 환경에서 데이터의 출처를 명확히 할 수 있습니다. 중요한 이유 데이터 출처를 식별합니다. 데이터 거버넌스와 검증에 중요하며, 올바른 소스를 바탕으로 분석이 이루어지도록 합니다. 확보 방법 일반적으로 데이터 추출 과정에서 레코드의 출처를 표시하기 위해 추가하는 고정값입니다. 예시 FenergoFenergo CLM | |||
| 최근 데이터 업데이트 LastDataUpdate | 이 프로세스의 데이터를 마지막으로 새로 고치거나 추출한 시점을 나타내는 타임스탬프입니다. | ||
| 설명 이 속성은 가장 최근 데이터 새로 고침의 날짜와 시간을 기록합니다. 분석 대상 데이터의 최신성을 파악하는 데 필요한 정보를 제공하며, 인사이트가 얼마나 시의성 있는지 판단하는 데 중요합니다. 대시보드와 보고서에서는 데이터가 얼마나 최신인지 사용자에게 알리는 데 사용됩니다. 분석 결과가 실시간 운영을 반영하는지, 과거 시점의 데이터인지 이해하는 데 도움이 됩니다. 중요한 이유 데이터의 최신성을 파악할 수 있어 사용자가 프로세스 분석 결과가 얼마나 현재 상황을 반영하는지 이해하는 데 도움이 됩니다. 확보 방법 데이터 추출 및 적재(ETL) 과정에서 데이터 세트에 생성 시각이 기록됩니다. 예시 2024-05-21T02:00:00Z2024-05-22T02:00:00Z | |||
| SLA 목표일 SlaTargetDate | 고객 온보딩 케이스를 완료해야 하는 기한입니다. | ||
| 설명 SLA 목표일은 고객 신청의 전체 온보딩 프로세스를 완료하기로 합의한 기한입니다. 실제 성과를 측정하는 기준으로 사용됩니다. 이 속성은 'SLA 준수 모니터링' 대시보드와 'SLA 준수율' KPI 계산에 필요합니다. SLA를 지키지 못할 위험이 있는 케이스를 미리 관리하고 업무 우선순위를 정하는 데 도움이 됩니다. 중요한 이유 목표 완료일을 정의합니다. SLA 준수 여부를 모니터링하고 기한이 지난 케이스의 우선순위를 정하는 데 중요합니다. 확보 방법 Fenergo의 SLA 관리 모듈에 설정된 업무 규칙과 신청서 제출일을 바탕으로 계산하는 경우가 많습니다. 예시 2023-11-15T23:59:59Z2023-12-01T23:59:59Z | |||
| 사용자 부서 UserDepartment | 수행 사용자가 속한 부서 또는 사업부입니다. | ||
| 설명 이 속성은 활동을 수행한 사용자의 조직상 소속을 나타냅니다. 예를 들어 '규정 준수', '온보딩 운영', '영업' 등이 있으며, 사용자 프로필 정보를 바탕으로 가져오는 경우가 많습니다. 부서 간 업무 인계를 분석하고 부서 간 병목을 파악하는 데 중요합니다. 팀 또는 부서 단위로 업무를 집계할 수 있어 '직원 활동 분포' 대시보드에도 활용됩니다. 중요한 이유 부서별 프로세스 성과를 분석해 부서 간 업무 인계, 지연, 업무량 분포를 파악할 수 있습니다. 확보 방법 'InitiatingUser' ID를 사용해 별도의 사용자 또는 HR 기준 데이터 테이블과 조인해야 할 수 있습니다. Fenergo 사용자 프로필에 저장되어 있을 수도 있습니다. 예시 Compliance고객 온보딩품질 보증 | |||
| 수행 사용자 InitiatingUser | 활동을 수행한 사람의 사용자 ID 또는 이름입니다. | ||
| 설명 이 속성은 특정 작업이나 이벤트를 수행한 직원 또는 시스템 사용자를 식별합니다. 고유 사용자 ID, 이름 또는 역할이 될 수 있습니다. 사용자별 분석을 통해 업무량 배분과 개인별 성과를 파악하고 교육이 필요한 부분을 찾을 수 있습니다. '직원 활동 분포' 대시보드의 주요 속성이며, 특정 개인이나 팀이 수행한 활동을 자세히 살펴보는 데 사용됩니다. 중요한 이유 작업을 수행한 사용자를 추적해 업무량 배분, 팀 성과, 리소스 할당을 분석할 수 있습니다. 확보 방법 일반적으로 이벤트 세부 정보와 함께 Fenergo 감사 로그 또는 작업 이력 테이블에 저장됩니다. 'UserID', 'UserName', 'ModifiedBy' 등의 이름으로 표시되는 경우가 많습니다. 예시 j.doea.smith시스템 | |||
| 신청 상태 ApplicationStatus | 고객 신청의 현재 상태 또는 최종 결과입니다. | ||
| 설명 이 속성은 프로세스 종료 시 신청 결과를 나타내며, 진행 중인 경우 현재 상태를 표시합니다. 일반적인 값으로는 '승인', '거부', '진행 중'이 있습니다. 결과 분석에 중요한 속성입니다. 최종 결과에 따라 프로세스 흐름을 필터링하고 비교할 수 있어 '신청 재작업 및 거부' 대시보드와 신청 거부율 같은 KPI 계산에 필요합니다. 중요한 이유 케이스 결과를 정의해 승인된 신청과 거부된 신청의 경로를 비교하고 성공률을 파악할 수 있습니다. 확보 방법 일반적으로 Fenergo 케이스 관리 시스템의 케이스 엔터티에 기록된 최종 상태입니다. 예시 승인거부규정 준수 검토 대기종료 | |||
| 위험 점수 RiskScore | 고객의 위험 수준을 수치로 나타낸 점수입니다. | ||
| 설명 위험 점수는 관할권, 업종, 심사 결과 등 여러 요인을 바탕으로 산출한 고객의 잠재적 위험을 수치화한 값입니다. 일반적으로 Fenergo의 규칙 엔진이 계산합니다. 이 속성을 사용하면 위험 수준과 프로세스 진행 양상의 관계를 분석할 수 있습니다. 예를 들어 고위험 고객의 처리 시간이 더 길거나 수작업이 더 많이 필요한지 확인할 수 있으며, '위험 및 규정 준수 검토 상세 분석' 대시보드에도 활용됩니다. 중요한 이유 고객 위험을 수치화해 위험 수준이 프로세스 기간, 재작업, 결과에 미치는 영향을 분석할 수 있습니다. 확보 방법 Fenergo의 고객 위험 평가 모듈에서 산출하는 주요 결과값으로, 케이스 또는 클라이언트 엔터티에 저장됩니다. 예시 154585 | |||
| 종료 시간 EventEndTime | 활동 또는 이벤트가 완료된 시점을 나타내는 타임스탬프입니다. | ||
| 설명 이 속성은 특정 활동이 끝난 정확한 날짜와 시간을 기록합니다. 시작 시간과 함께 작업의 실제 처리 시간을 산출하는 데 사용됩니다. process mining에서는 종료 시간과 시작 시간을 이용해 활동별 처리 시간을 계산합니다. 프로세스에서 시간이 가장 오래 걸리는 단계를 찾고 리소스 효율성을 분석하는 데 필요합니다. 중요한 이유 활동별 처리 시간을 계산할 수 있어 장시간 진행되는 작업과 성과 병목을 파악하는 데 도움이 됩니다. 확보 방법 Fenergo의 감사 추적 또는 워크플로 이력 테이블에서 확인할 수 있습니다. 'EndDate', 'CompletionDate'로 표시되거나 다음 이벤트의 시작 시간을 바탕으로 산출할 수 있습니다. 예시 2023-10-26T11:30:00Z2023-10-26T15:00:10Z2023-10-27T11:45:00Z | |||
| SLA 준수 여부 IsSlaCompliant | 케이스가 SLA 목표일까지 완료되었는지 나타내는 참/거짓 값입니다. | ||
| 설명 이 속성은 완료된 케이스의 SLA 성과를 이진 값으로 나타냅니다. 최종 종료 활동의 타임스탬프가 'SlaTargetDate'와 같거나 이전이면 'true', 그렇지 않으면 'false'로 설정됩니다. 이 계산 필드를 사용하면 SLA를 간편하게 모니터링하고 보고할 수 있습니다. 값을 집계해 전체 'SLA 준수율' KPI를 계산하거나, SLA 준수 케이스와 미준수 케이스의 프로세스 특성을 비교할 수 있습니다. 중요한 이유 SLA 성과를 직접 측정해 SLA 준수율 KPI를 쉽게 계산하고 미준수 케이스를 필터링할 수 있습니다. 확보 방법 최종 케이스 활동(예: '신청 승인', '신청 거부')의 타임스탬프를 'SlaTargetDate'와 비교해 산출합니다. 예시 truefalse | |||
| 거부 사유 RejectionReason | 신청이 거부된 이유를 설명하는 코드 또는 설명입니다. | ||
| 설명 신청의 최종 상태가 '거부'인 경우 이 속성에 구체적인 사유가 기록됩니다. 예를 들어 '배경 조사 실패', '서류 미비', '위험도 높음' 등이 있습니다. 신청 실패의 근본 원인을 분석하는 데 중요한 속성입니다. '신청 재작업 및 거부' 대시보드에서 실패 사유를 분류해 반복되는 문제를 찾고, 최초 검토 통과율을 높이기 위한 개선 조치를 마련할 수 있습니다. 중요한 이유 신청이 실패한 이유를 파악해 근본 원인을 분석하고 거부율을 낮추는 데 도움이 됩니다. 확보 방법 일반적으로 Fenergo 케이스 워크플로에서 최종 거부 상태와 연결된 사유 코드 또는 메모 필드에 기록됩니다. 예시 제재 대상 일치유효하지 않은 서류정책 위반고객 신청 철회 | |||
| 고객 ID CustomerId | 온보딩 대상 고객 또는 법인을 식별하는 고유 ID입니다. | ||
| 설명 고객 ID는 기준 데이터 시스템에서 클라이언트 엔터티를 식별하는 고유 참조값입니다. 신청 번호가 프로세스의 케이스 ID라면, 고객 ID는 온보딩 활동을 특정 고객과 연결합니다. 이 속성을 사용하면 한 고객이 여러 차례 온보딩을 진행한 경우와 같이 고객별 온보딩 이력을 분석할 수 있습니다. 프로세스 데이터를 다른 고객 관련 데이터와 결합해 더 폭넓은 업무 관점에서 분석할 수도 있습니다. 중요한 이유 온보딩 프로세스를 고유한 고객 엔터티와 연결해 고객 중심 분석과 데이터 보강을 지원합니다. 확보 방법 이 ID는 Fenergo의 클라이언트 또는 법인 레코드에 저장되며 온보딩 케이스와 연결됩니다. 예시 CUST-98765CUST-98766CUST-98767 | |||
| 고객 유형 CustomerType | 온보딩 대상 고객의 유형입니다. 개인, 법인, 신탁 등이 해당합니다. | ||
| 설명 이 속성은 법적 구조나 금융기관과의 관계에 따라 고객을 여러 유형으로 구분합니다. 고객 유형에 따라 온보딩 경로가 다르고, 절차의 복잡성이나 실사 요건도 달라질 수 있습니다. 고객 유형별로 프로세스를 분석하면 고객군 간 성과 차이를 파악할 수 있습니다. '신청 출처 및 유형별 효율성' 대시보드에서 처리 시간과 승인율을 비교하고, 유형별 프로세스 개선 방안을 마련하는 데 활용됩니다. 중요한 이유 복잡성과 SLA가 서로 다른 고객군 간 프로세스 성과를 비교할 수 있습니다. 확보 방법 일반적으로 Fenergo의 고객 또는 클라이언트 엔터티에 저장되며 신청 케이스와 연결됩니다. 예시 개인법인신탁파트너십 | |||
| 국가 Country | 고객 신청과 관련된 거주 국가 또는 관할권입니다. | ||
| 설명 이 속성은 고객과 관련된 국가를 지정합니다. 해당 국가에 따라 온보딩 프로세스에 적용되는 규제와 위험 요인이 달라지는 경우가 많습니다. 국가별 프로세스 분석을 통해 관할권에 따른 처리 시간, 위험 수준, 프로세스 복잡성을 비교할 수 있습니다. 지역별 차이가 운영 성과에 미치는 영향을 파악하고 현지 규정을 준수하는 데 도움이 됩니다. 중요한 이유 지역별로 프로세스를 구분해 규제 영향과 지역별 성과를 분석할 수 있습니다. 확보 방법 신청 과정에서 수집하는 기본 고객 데이터의 일부이며, Fenergo의 클라이언트 엔터티에 저장됩니다. 예시 USAGBRSGPDEU | |||
| 신청 채널 ApplicationChannel | 고객 신청서를 제출한 채널입니다. | ||
| 설명 이 속성은 온라인 포털, 영업점 또는 고객 담당자를 통한 신청 등 신청서가 접수된 경로를 식별합니다. 접수 경로에 따라 데이터 품질과 처리 요건이 달라질 수 있습니다. '신청 출처 및 유형별 효율성' 대시보드에서 채널별 성과를 비교하는 데 사용됩니다. 어떤 채널이 효율적인지, 어떤 채널의 프로세스를 개선해야 하는지 파악할 수 있습니다. 중요한 이유 신청이 접수된 경로를 식별해 채널별 효율성, 비용, 고객 경험을 분석할 수 있습니다. 확보 방법 Fenergo의 초기 데이터 입력 양식에서 수집하거나 상위 시스템에서 전달받을 수 있습니다. 예시 온라인 포털영업점고객 담당자모바일 앱 | |||
| 자동 수행 여부 IsAutomated | 활동을 사람이 아닌 시스템이 수행했는지 나타내는 참/거짓 값입니다. | ||
| 설명 이 속성은 시스템이 자동으로 수행한 작업(예: 초기 심사, 시스템 확인)과 사용자가 직접 수행한 작업을 구분합니다. 일반적으로 수행자가 시스템 계정 또는 서비스 계정인지 확인해 판단합니다. 이 값을 분석하면 프로세스의 자동화 수준을 파악할 수 있습니다. 자동화가 효율성, 비용, 처리 속도에 미치는 영향을 측정하고 추가 자동화 기회를 찾는 데 도움이 됩니다. 중요한 이유 사람이 수행한 활동과 시스템이 수행한 활동을 구분해 자동화 수준을 분석하고 리소스 비용을 파악할 수 있습니다. 확보 방법 일반적으로 'InitiatingUser' 필드를 바탕으로 산출합니다. 알려진 시스템 사용자 ID 목록을 사용해 이 값을 true로 설정합니다. 예시 truefalse | |||
| 재작업 여부 IsRework | 활동이 재작업 루프에 포함되는지 나타내는 참/거짓 값입니다. | ||
| 설명 이 속성은 프로세스가 이전 단계로 되돌아간 활동을 식별합니다. 예를 들어 '규정 준수 검토'가 시작된 뒤 '서류 검토'로 돌아가거나 '추가 정보 요청'이 발생한 경우입니다. 재작업을 식별하는 것은 프로세스의 비효율과 마찰을 파악하는 데 중요합니다. 이 값을 사용해 '재작업 루프 비율' KPI를 직접 계산하고, 프로세스 흐름에서 불필요하게 반복되는 단계의 영향을 시각화하고 측정할 수 있습니다. 중요한 이유 비효율적인 재작업 루프를 드러내 낭비를 측정하고 개선 영역을 찾아 최초 처리 성공률을 높이는 데 도움이 됩니다. 확보 방법 활동 순서를 분석하는 process mining 기법으로 산출합니다. 예를 들어 같은 케이스에서 '활동 A' 다음에 '활동 B'가 발생한 뒤 다시 '활동 A'가 나타나면, 두 번째 '활동 A'를 재작업으로 봅니다. 예시 truefalse | |||
| 추가 정보 요청 횟수 AdditionalInfoRequestCount | 신청 건별 추가 정보 요청 횟수입니다. | ||
| 설명 이 지표는 각 케이스에서 '추가 정보 요청' 활동이 발생한 횟수를 셉니다. 횟수가 많을수록 고객과의 추가 연락이 늘어나 프로세스가 지연되고 고객 경험이 나빠질 수 있습니다. 이 속성은 '추가 정보 요청이 있는 케이스' KPI를 직접 지원합니다. 요청이 지나치게 많은 신청을 찾아 초기 데이터 수집의 문제나 복잡한 케이스 요건을 파악할 수 있습니다. 이를 분석하면 정보 수집 절차를 간소화할 수 있습니다. 중요한 이유 초기 정보가 불완전해 발생하는 고객 불편과 프로세스 지연을 측정하고 데이터 수집 단계를 개선하는 데 도움이 됩니다. 확보 방법 계산 지표로, 각 'CustomerApplication' ID에 대해 '추가 정보 요청' 이벤트 수를 세어 산출합니다. 예시 013 | |||
| 케이스 담당자 CaseOwner | 신청의 전체 진행 과정에서 관리를 맡는 주 사용자 또는 팀입니다. | ||
| 설명 케이스 담당자는 온보딩 케이스의 주된 책임을 맡은 개인 또는 그룹입니다. 일반적으로 케이스를 기한 내에 성공적으로 완료할 책임이 있습니다. 이 속성을 사용해 케이스 관리자별 업무량과 성과를 분석할 수 있습니다. 특정 담당자의 처리 시간이 더 길거나 거부율이 높은지 확인해 교육 필요성이나 리소스 불균형을 파악할 수 있습니다. 중요한 이유 케이스의 책임자 또는 담당 팀을 식별해 케이스 관리자별 성과를 분석할 수 있습니다. 확보 방법 일반적으로 Fenergo의 기본 케이스 엔터티에 있는 케이스 배정 필드입니다. 예시 s.jonesonboarding_team_am.chen | |||
KYC 고객 온보딩 활동
| 활동 | 설명 | ||
|---|---|---|---|
| 규정 준수 검토 시작 | 중요하고 시간이 오래 걸리는 단계인 규정 준수 부서의 검토가 시작되는 시점입니다. 케이스가 규정 준수 업무 대기열에 배정되거나 상태가 '규정 준수 검토 대기'로 변경된 시점을 바탕으로 추정합니다. | ||
| 중요한 이유 '평균 규정 준수 검토 시간' KPI를 측정하기 위한 시작점입니다. 규정 준수 팀이 실제로 업무를 시작하기 전까지 케이스가 얼마나 대기하는지 파악할 수 있습니다. 확보 방법 Fenergo 케이스 감사 로그에서 상태가 '규정 준수 검토 중'으로 변경된 시각이나 케이스가 규정 준수 담당자 또는 팀에 배정된 시각을 확인해 추정합니다. 기록 '규정 준수 검토 중' 상태로 변경된 시각이나 배정 이벤트를 확인합니다. 이벤트 유형 inferred | |||
| 규정 준수 검토 완료 | 규정 준수 부서의 공식 승인을 나타내며, 모든 규제 요건이 충족된 상태입니다. 작업 완료나 상태가 '규정 준수 승인'으로 변경된 시점을 바탕으로 추정합니다. | ||
| 중요한 이유 전체 처리 시간에 영향을 주는 주요 단계입니다. 이 활동의 완료 시점은 '평균 규정 준수 검토 시간'을 측정하고 규정 준수 업무의 병목을 찾는 기준이 됩니다. 확보 방법 Fenergo 워크플로의 '규정 준수 검토' 작업 완료 시각이나 케이스 이력의 상태 변경 이벤트를 바탕으로 추정합니다. 기록 규정 준수 검토 작업의 완료 시각이나 상태 변경 시각을 사용합니다. 이벤트 유형 inferred | |||
| 서류 검토 완료 | 제출된 고객 서류의 진위와 정확성을 수동 또는 자동으로 확인하는 절차가 완료된 상태입니다. 일반적으로 워크플로 작업 완료나 Fenergo 상태 변경을 바탕으로 추정합니다. | ||
| 중요한 이유 지연이 자주 발생하는 중요한 단계입니다. 이 활동의 소요 시간과 결과를 분석하면 서류 처리 병목을 찾고 '최초 통과율'과 같은 KPI를 관리할 수 있습니다. 확보 방법 케이스 워크플로의 '서류 확인' 작업 완료 시각이나 케이스 이력 로그의 '서류 승인' 상태 변경을 바탕으로 추정합니다. 기록 서류 검토 작업의 완료 시각이나 관련 상태 변경 시각을 사용합니다. 이벤트 유형 inferred | |||
| 신청 거절 | 고객의 신청을 최종 거절하는 종료 이벤트입니다. 케이스 상태가 최종 '거절' 또는 '승인 거부' 상태로 변경된 시점을 바탕으로 추정합니다. | ||
| 중요한 이유 프로세스의 주요 종료 지점으로, '신청 거절률'을 계산하고 거절 사유를 분석하는 데 중요합니다. 거절이 자주 발생하는 지점을 찾아 신청서 품질을 개선할 수 있습니다. 확보 방법 케이스 감사 로그에서 최종 상태가 '거절'로 변경된 시각을 확인해 추정합니다. 거절 사유는 관련 필드에 저장되는 경우가 많습니다. 기록 최종 상태가 '거절'로 변경된 시각을 확인합니다. 이벤트 유형 inferred | |||
| 신청 승인 | 고객의 온보딩 신청을 최종 승인하는 활동입니다. 케이스 상태가 최종 '승인' 또는 '온보딩 승인' 상태로 변경된 시점을 바탕으로 추정합니다. | ||
| 중요한 이유 계정 활성화 전의 중요한 성공 단계입니다. 승인율을 계산하고 온보딩을 성공적으로 완료한 고객의 특성을 분석하는 데 필요합니다. 확보 방법 케이스 이력이나 감사 로그에서 최종 상태가 '승인' 또는 이에 해당하는 긍정적인 종료 상태로 변경된 시각을 확인해 추정합니다. 기록 최종 상태가 '승인'으로 변경된 시각을 확인합니다. 이벤트 유형 inferred | |||
| 위험 평가 완료 | 여러 요소를 바탕으로 고객의 위험 등급을 지정하는 내부 위험 분류 절차가 완료된 상태입니다. 상태 변경이나 위험 등급 필드 입력을 바탕으로 추정합니다. | ||
| 중요한 이유 이 단계는 이후 워크플로 경로를 결정하는 중요한 의사결정 시점입니다. 소요 시간을 분석하면 중요한 규정 준수 단계를 간소화하고 위험 평가의 일관성을 높일 수 있습니다. 확보 방법 케이스 이력 로그에서 '위험 평가 완료'와 같은 상태로 변경된 시점이나 최종 '고객 위험 등급' 필드에 값이 입력된 시점을 확인해 추정합니다. 기록 위험 등급 필드가 확정된 시각이나 관련 상태가 설정된 시각을 사용합니다. 이벤트 유형 inferred | |||
| 케이스 생성 | Fenergo에서 신규 고객 신청 건이 정식으로 생성되면 KYC 온보딩 프로세스가 시작됩니다. 일반적으로 케이스 기록을 처음 저장할 때 특정 시각과 함께 명시적인 이벤트로 기록됩니다. | ||
| 중요한 이유 시작 이벤트인 이 활동은 전체 온보딩 처리 시간과 처리량을 계산하는 데 필요합니다. 이후 모든 프로세스 측정과 SLA 추적의 기준점이 됩니다. 확보 방법 일반적으로 Fenergo의 기본 케이스 엔터티 생성 시각을 사용합니다. 해당 정보는 고객 온보딩 케이스나 워크플로 관련 테이블에서 확인할 수 있습니다. 기록 온보딩 케이스 기록의 생성 시각을 사용합니다. 이벤트 유형 explicit | |||
| 케이스 종료 | 이 활동은 Fenergo에서 온보딩 케이스가 행정적으로 종료되어 추가 조치가 필요하지 않음을 나타내는 마지막 단계입니다. 승인 및 거부된 신청 모두에 적용되며, 최종 상태가 '종료'로 기록된 경우를 기준으로 판단합니다. | ||
| 중요한 이유 이 활동은 전체 프로세스의 최종 종료 지점입니다. 결과와 관계없이 모든 케이스의 처리 시간을 정확히 계산하고 프로세스가 끝났음을 확인할 수 있습니다. 확보 방법 Fenergo 케이스 감사 로그에서 상태가 '종료', '완료' 또는 다른 최종 상태로 변경된 시점을 확인해 추정합니다. 기록 최종 상태가 '종료' 또는 '완료'로 변경된 시점을 확인합니다. 이벤트 유형 inferred | |||
| 계정 활성화 | 승인 후 핵심 뱅킹 시스템 또는 관련 후속 시스템에서 고객 계정이 정상적으로 생성되고 활성화되었음을 나타냅니다. Fenergo에서 승인 후 최종 상태가 업데이트된 기록을 바탕으로 추정할 수 있습니다. | ||
| 중요한 이유 이 활동은 온보딩 프로세스가 정상적으로 완료되어 고객이 활성 상태로 전환되었음을 확인합니다. 승인부터 계정 활성화까지 걸린 시간을 측정하면 운영 설정 과정의 지연을 파악할 수 있습니다. 확보 방법 '계정 활성' 또는 '온보딩 완료'와 같은 케이스 상태를 바탕으로 추정할 수 있습니다. 후속 시스템과의 연동 과정에서 명시적인 이벤트가 기록될 수도 있습니다. 기록 승인 후 상태 변경 기록이나 연동 성공 이벤트 로그를 확인합니다. 이벤트 유형 inferred | |||
| 데이터 및 서류 요청 | 시스템이나 온보딩 담당자가 고객에게 필요한 정보와 서류를 정식으로 요청한 이벤트입니다. 표준 안내문을 발송할 때 명시적인 이벤트로 기록되는 경우가 많습니다. | ||
| 중요한 이유 이 활동은 고객의 응답을 기다리는 단계의 시작을 나타냅니다. 이 시점부터 서류를 받기까지 걸리는 시간을 측정하면 고객 여정을 분석하고 안내 지연을 파악하는 데 도움이 됩니다. 확보 방법 고객 커뮤니케이션 이벤트 로그나 '서류 요청' 작업 완료 로그에서 확인합니다. '고객 정보 대기' 상태로 변경된 시각을 바탕으로 추정할 수도 있습니다. 기록 고객에게 연락한 이벤트 로그나 작업 완료 기록을 확인합니다. 이벤트 유형 explicit | |||
| 서류 접수 | 고객이 필요한 서류를 업로드하거나 제출해 Fenergo에서 검토할 수 있는 상태를 나타냅니다. 일반적으로 케이스 상태가 '서류 접수' 또는 '검토 대기'로 변경된 시점을 바탕으로 추정합니다. | ||
| 중요한 이유 고객의 대기 기간이 끝나고 내부 검토가 시작되는 시점입니다. 고객 응답 시간과 내부 처리 대기 시간을 측정하는 데 중요합니다. 확보 방법 케이스 감사 추적 기록에서 '서류 접수' 또는 이에 해당하는 상태로 변경된 시각을 확인해 추정합니다. 서류 업로드 이벤트와 연결할 수도 있습니다. 기록 '서류 접수' 또는 '검토 준비 완료' 상태로 변경된 시각을 확인합니다. 이벤트 유형 inferred | |||
| 신원 조회 시작 | 외부 신원 조회, AML 또는 신용 조회를 시작하는 시점입니다. 보통 타사 서비스와 연동할 때 기록되는 명시적 이벤트입니다. | ||
| 중요한 이유 이러한 조회의 시작과 완료를 추적하면 외부 의존성으로 인한 지연을 파악할 수 있습니다. 내부 처리 시간과 외부 응답 대기 시간을 구분하는 데 도움이 됩니다. 확보 방법 외부 심사 서비스로 전송한 API 호출을 기록하는 시스템 로그나 Fenergo 케이스에서 특정 '신원 조회' 작업이 생성된 기록을 확인합니다. 기록 외부 서비스 연동 로그나 '심사' 작업 생성 기록을 확인합니다. 이벤트 유형 explicit | |||
| 초기 심사 완료 | 기본 데이터 검증이나 제재 목록 확인 등 초기 자동 또는 수동 검사가 완료된 상태를 나타냅니다. Fenergo 케이스 워크플로의 상태 변경을 바탕으로 추정하는 경우가 많습니다. 예를 들어 상태가 '신규'에서 '심사 완료'로 바뀌는 경우입니다. | ||
| 중요한 이유 초기 단계의 이 시점을 추적하면 사전 자격 심사 단계에서 데이터 품질 문제와 병목을 파악하는 데 도움이 됩니다. 초기 자동 처리 단계와 이후의 집중적인 수동 검토 단계를 구분할 수 있습니다. 확보 방법 케이스 이력이나 감사 로그에서 심사 완료를 나타내는 상태로 변경된 시각을 확인해 추정합니다. 예를 들어 '심사 통과' 또는 '서류 대기' 상태가 이에 해당합니다. 기록 케이스 이력에서 '심사 완료' 또는 이에 해당하는 상태 변경을 확인합니다. 이벤트 유형 inferred | |||
| 추가 정보 요청 | 온보딩 팀이 고객에게 추가 설명이나 누락된 서류를 요청하는 재작업 반복을 나타냅니다. 일반적으로 고객에게 안내를 보낼 때 명시적인 이벤트로 기록됩니다. | ||
| 중요한 이유 이 활동은 프로세스 비효율과 좋지 않은 고객 경험을 보여 주는 주요 지표입니다. 발생 빈도를 추적하면 재작업의 근본 원인을 찾고 '재작업 반복률' KPI를 관리할 수 있습니다. 확보 방법 고객 커뮤니케이션 이벤트 로그나 '추가 정보 대기' 상태 변경을 확인합니다. 정확한 요청 시점을 파악하려면 커뮤니케이션 이벤트 로그를 사용하는 편이 좋습니다. 기록 기록된 고객 커뮤니케이션 이벤트나 '고객 응답 대기' 상태 변경을 확인합니다. 이벤트 유형 explicit | |||
데이터 추출 가이드
단계
- Reporting Module에 접속합니다: Reporting & Analytics module 사용 권한이 있는 계정으로 Fenergo 애플리케이션에 로그인합니다. 일반적으로 기본 애플리케이션 메뉴에서 해당 모듈을 찾을 수 있습니다.
- 새 보고서를 만듭니다: 새 사용자 지정 보고서 생성을 시작합니다. 목적을 분명히 알 수 있도록 이름과 설명을 지정합니다. 예를 들어 'KYC 온보딩 process mining 이벤트 로그'라고 입력할 수 있습니다.
- 기본 데이터 소스를 지정합니다: 케이스의 전체 진행 정보를 담은 핵심 데이터 객체나 뷰를 선택합니다. 미리 구성된
[CaseWorkflowHistory]또는[LifecycleEventsView]같은 뷰를 사용하는 경우가 많습니다. 이 객체에는 케이스 식별자, 이벤트 이름이나 상태, 타임스탬프가 포함되어야 합니다. - 보고서 열(속성)을 구성합니다: 보고서 작성 화면에서 열을 추가합니다. Fenergo 데이터 모델의 원본 필드를 필요한 이벤트 로그 속성에 매핑합니다. 예를 들어 Fenergo의
CaseID를CustomerApplication에,EventTimestamp를EventStartTime에,EventPerformer를InitiatingUser에 매핑합니다. - 활동 로직을 구성합니다: 가장 중요한 단계입니다. 보고서에서 필수 활동 14개 각각에 대해 별도의 행을 생성하도록 설정해야 합니다. 보고서 작성기에서 활동별 논리 블록이나 필터링된 데이터 집합을 만든 다음 UNION 또는 이에 해당하는 기능으로 결합합니다.
- '케이스 생성' 로직을 정의합니다: 첫 번째 블록을 만듭니다. 데이터 소스에서 최초 케이스 생성 이벤트를 필터링합니다. 케이스와 연결된 가장 이른 타임스탬프나 'Case Created'라는 이벤트 유형을 기준으로 삼을 수 있습니다.
CreationDate를EventStartTime에 매핑합니다. - 상태 기반 활동 로직을 정의합니다: '문서 접수', '신청 승인'처럼 상태 변경으로 추론하는 활동은 별도의 블록으로 만듭니다. 특정
Status필드 값을 기준으로 데이터 소스를 필터링하고StatusChangeDate를EventStartTime으로 사용합니다. - 작업 기반 활동 로직을 정의합니다: '규정 준수 검토 완료'처럼 워크플로 작업에 연결된 활동은
TaskName과TaskCompletionDate를 기준으로 필터링하는 블록을 만듭니다. 완료 날짜를EventStartTime으로 사용합니다. - 보고서 전체 필터를 설정합니다: 데이터 범위를 지정하도록 보고서 수준의 필터를 적용합니다. 내보내는 데이터가 지나치게 많아지지 않도록
EventStartTime의Date Range를 설정합니다. 초기 분석에는 3~6개월을 권장합니다. 'KYC 고객 온보딩'과 같은 특정 케이스 유형도 필터링합니다. - 보고서를 실행하고 미리 봅니다: Fenergo UI에서 보고서를 실행합니다. 처음 100~200개 행을 미리 보고 데이터 구조가 올바른지, 모든 열에 예상한 값이 있는지, 여러 활동이 포함되어 있는지 확인합니다.
- 데이터를 내보냅니다: 보고서 결과 전체를 CSV 또는 Excel 파일로 내보냅니다. 이 파일이 원시 이벤트 로그입니다.
- 데이터를 최종 준비합니다: 내보낸 CSV 파일을 엽니다. 보고서에서
SourceSystem과LastDataUpdate열을 직접 생성할 수 없다면 수동으로 추가합니다. 모든 행의SourceSystem에는 'Fenergo'를 입력하고,LastDataUpdate에는 내보낸 시각을 입력합니다.
구성
- 사전 요건: 사용자는 사용자 지정 보고서를 만들고 실행할 권한이 있는 Fenergo Reporting & Analytics 모듈에 액세스할 수 있어야 합니다.
- 주요 데이터 소스: 보고서는 주로 Fenergo의 케이스 관리 및 워크플로 이력 객체를 기반으로 작성해야 합니다. 일반적인 소스로는
[CaseDetails],[CaseStatusHistory],[WorkflowTaskHistory]가 있습니다. 정확한 이름은 Fenergo 구성에 따라 다를 수 있습니다. - 날짜 범위: 성능을 관리하려면 이벤트 타임스탬프에 날짜 범위 필터를 설정해야 합니다. 최근 3~6개월부터 시작하세요. 과거 데이터를 분석할 때는 분기별 또는 연도별로 나누어 보고서를 실행하세요.
- 주요 필터: 관련 없는 데이터를 제외하려면 'KYC Customer Onboarding'과 같은 특정 프로세스 또는 케이스 유형을 항상 필터링하세요. 분석 목적에 따라 법인 유형이나 관할 지역도 필터링해야 할 수 있습니다.
- 활동 정의: 각 활동은
상태,TaskName또는 전용EventType필드와 같은 필드의 구체적인 필터 기준으로 정의해야 합니다. 이러한 필드를 기준으로 삼아야 프로세스의 개별 이벤트를 구분할 수 있습니다. - 성능 고려 사항: 여러 데이터 소스를 결합하거나 넓은 날짜 범위를 조회하는 보고서는 실행 속도가 느릴 수 있습니다. 가능하면 사용량이 적은 시간대에 보고서를 실행하도록 예약하세요. 내보내기에 불필요한 열을 포함하면 처리 시간이 늘어나므로 제외하세요.
샘플 쿼리 sql
/*
This is a logical representation of the configuration needed in the Fenergo Reporting & Analytics module.
The module uses a graphical interface, but this query structure illustrates the required data sources, filters, and unions.
Fields like [CaseLifecycleData].[CaseID] are placeholders for actual Fenergo fields selected in the UI.
*/
-- Base data selection for common attributes
WITH CaseAttributes AS (
SELECT
C.CaseID AS CustomerApplication,
C.SlaTargetDate AS SlaTargetDate,
C.FinalRiskScore AS RiskScore,
C.CurrentStatus AS ApplicationStatus
FROM [CaseDetails] C
WHERE C.CaseType = 'KYC Customer Onboarding'
)
-- 1. Case Created
SELECT
A.CustomerApplication,
'Case Created' AS ActivityName,
L.CreationTimestamp AS EventStartTime,
L.CompletionTimestamp AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseLifecycleEvents] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.EventType = 'CASE_CREATED'
AND L.CreationTimestamp >= '[StartDate]' AND L.CreationTimestamp <= '[EndDate]'
UNION ALL
-- 2. Initial Screening Performed
SELECT
A.CustomerApplication,
'Initial Screening Performed' AS ActivityName,
L.CompletionTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseLifecycleEvents] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.TaskName = 'Initial Screening' AND L.TaskStatus = 'Completed'
AND L.CompletionTimestamp >= '[StartDate]' AND L.CompletionTimestamp <= '[EndDate]'
UNION ALL
-- 3. Data & Documents Requested
SELECT
A.CustomerApplication,
'Data & Documents Requested' AS ActivityName,
L.CreationTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseLifecycleEvents] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.EventType = 'CUSTOMER_COMMUNICATION' AND L.TemplateName = 'Initial Document Request'
AND L.CreationTimestamp >= '[StartDate]' AND L.CreationTimestamp <= '[EndDate]'
UNION ALL
-- 4. Documents Received
SELECT
A.CustomerApplication,
'Documents Received' AS ActivityName,
L.StatusChangeTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseStatusHistory] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.NewStatus = 'Pending Review'
AND L.StatusChangeTimestamp >= '[StartDate]' AND L.StatusChangeTimestamp <= '[EndDate]'
UNION ALL
-- 5. Document Review Completed
SELECT
A.CustomerApplication,
'Document Review Completed' AS ActivityName,
L.CompletionTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseLifecycleEvents] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.TaskName = 'Document Verification' AND L.TaskStatus = 'Completed'
AND L.CompletionTimestamp >= '[StartDate]' AND L.CompletionTimestamp <= '[EndDate]'
UNION ALL
-- 6. Background Checks Initiated
SELECT
A.CustomerApplication,
'Background Checks Initiated' AS ActivityName,
L.CreationTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseLifecycleEvents] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.EventType = 'EXTERNAL_CHECK_INITIATED'
AND L.CreationTimestamp >= '[StartDate]' AND L.CreationTimestamp <= '[EndDate]'
UNION ALL
-- 7. Risk Assessment Completed
SELECT
A.CustomerApplication,
'Risk Assessment Completed' AS ActivityName,
L.CompletionTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseLifecycleEvents] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.TaskName = 'Risk Assessment' AND L.TaskStatus = 'Completed'
AND L.CompletionTimestamp >= '[StartDate]' AND L.CompletionTimestamp <= '[EndDate]'
UNION ALL
-- 8. Compliance Review Initiated
SELECT
A.CustomerApplication,
'Compliance Review Initiated' AS ActivityName,
L.StatusChangeTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseStatusHistory] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.NewStatus = 'Pending Compliance Review'
AND L.StatusChangeTimestamp >= '[StartDate]' AND L.StatusChangeTimestamp <= '[EndDate]'
UNION ALL
-- 9. Additional Information Requested
SELECT
A.CustomerApplication,
'Additional Information Requested' AS ActivityName,
L.CreationTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseLifecycleEvents] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.EventType = 'CUSTOMER_COMMUNICATION' AND L.TemplateName = 'Additional Information Request'
AND L.CreationTimestamp >= '[StartDate]' AND L.CreationTimestamp <= '[EndDate]'
UNION ALL
-- 10. Compliance Review Completed
SELECT
A.CustomerApplication,
'Compliance Review Completed' AS ActivityName,
L.CompletionTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseLifecycleEvents] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.TaskName = 'Compliance Review' AND L.TaskStatus = 'Completed'
AND L.CompletionTimestamp >= '[StartDate]' AND L.CompletionTimestamp <= '[EndDate]'
UNION ALL
-- 11. Application Approved
SELECT
A.CustomerApplication,
'Application Approved' AS ActivityName,
L.StatusChangeTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseStatusHistory] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.NewStatus = 'Approved'
AND L.StatusChangeTimestamp >= '[StartDate]' AND L.StatusChangeTimestamp <= '[EndDate]'
UNION ALL
-- 12. Application Rejected
SELECT
A.CustomerApplication,
'Application Rejected' AS ActivityName,
L.StatusChangeTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseStatusHistory] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.NewStatus = 'Rejected'
AND L.StatusChangeTimestamp >= '[StartDate]' AND L.StatusChangeTimestamp <= '[EndDate]'
UNION ALL
-- 13. Account Activated
SELECT
A.CustomerApplication,
'Account Activated' AS ActivityName,
L.StatusChangeTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseStatusHistory] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.NewStatus = 'Active'
AND L.StatusChangeTimestamp >= '[StartDate]' AND L.StatusChangeTimestamp <= '[EndDate]'
UNION ALL
-- 14. Case Closed
SELECT
A.CustomerApplication,
'Case Closed' AS ActivityName,
L.StatusChangeTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseStatusHistory] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.NewStatus = 'Closed'
AND L.StatusChangeTimestamp >= '[StartDate]' AND L.StatusChangeTimestamp <= '[EndDate]' 시작할 준비가 되셨나요?
이 데이터 템플릿을 활용하면 Fenergo의 KYC 고객 온보딩 프로세스에서 비효율을 찾아내고 업무를 간소화하는 데 한 걸음 더 다가갈 수 있습니다. 지금 운영 최적화와 고객 만족도 향상을 시작하세요.
KYC 고객 온보딩을 간소화하고 승인 속도를 높이세요
온보딩 시간을 24시간으로 단축하는 기업들과 함께하세요.
신용카드 없이 몇 분 만에 시작할 수 있습니다.