KYC 고객 온보딩 데이터 템플릿
KYC 고객 온보딩 데이터 템플릿
- 수집 권장 속성
- 추적할 주요 활동
- 데이터 추출 안내
KYC 고객 온보딩 속성
| 이름 | 설명 | ||
|---|---|---|---|
|
고객 신청
CustomerApplication
|
고객 온보딩 신청 건마다 부여되는 고유 식별자로, 기본 케이스 ID로 사용됩니다. | ||
|
설명
고객 신청은 한 고객의 온보딩 여정에 관련된 모든 활동과 데이터를 연결하는 중심 식별자입니다. 신청서가 제출되면 시작되고, 완료되거나 반려될 때까지 케이스를 추적합니다. process mining에서는 모든 이벤트를 하나의 케이스로 묶는 데 필요한 속성입니다. 이를 통해 신청자별 전체 프로세스 흐름을 재구성할 수 있으며, 온보딩 수명 주기의 처리 시간 계산, 프로세스 변형 분석, 신청 상태 추적에 활용됩니다.
중요한 이유
이 값은 기본 케이스 ID입니다. 이 값이 없으면 고객 신청의 전체 여정을 추적할 수 없어 프로세스 분석이 불가능합니다.
확보 방법
LexisNexis Risk Solutions의 케이스 관리 모듈에서 사용하는 기본 케이스 식별자입니다.
예시
APP-2023-001234APP-2023-005678APP-2024-009101
|
|||
|
이벤트 타임스탬프
EventTimestamp
|
특정 활동이 시작된 정확한 날짜와 시간입니다. | ||
|
설명
이 타임스탬프는 활동의 시작 시점을 나타내며 케이스 내 모든 이벤트의 시간 순서를 정하는 기준이 됩니다. process mining의 시간 기반 분석은 이 값을 바탕으로 합니다. 이벤트 타임스탬프를 사용하면 활동 소요 시간과 활동 사이의 대기 시간, 온보딩 프로세스의 전체 처리 시간을 계산할 수 있습니다. 병목 파악, SLA 준수 모니터링, 프로세스 효율 분석에도 필요한 데이터입니다.
중요한 이유
이 타임스탬프는 이벤트를 시간순으로 정렬하고 처리 시간이나 병목 등 시간 기반 지표를 계산하는 데 필요합니다.
확보 방법
활동 이름과 함께 이벤트 로그 또는 감사 추적 테이블에 저장됩니다.
예시
2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T14:15:00Z
|
|||
|
활동명
ActivityName
|
온보딩 프로세스 중 특정 시점에 발생한 작업이나 이벤트의 이름입니다. | ||
|
설명
활동명은 KYC 온보딩 워크플로의 단계를 나타냅니다. 예를 들어 '신청 접수', '서류 검토 완료', '신청 승인' 등이 있습니다. 각 활동은 프로세스에서 구분되는 작업이나 이정표를 의미합니다. 이 속성은 활동 흐름을 시각적으로 보여주는 프로세스 맵을 구성하는 데 필요합니다. 프로세스 변형, 특정 단계 사이의 병목, 재작업 반복 횟수를 분석할 수 있습니다. 활동을 분석하면 프로세스에서 실제로 어떤 일이 일어나는지 파악할 수 있습니다.
중요한 이유
이 속성을 바탕으로 프로세스 맵을 구성하고 고객 온보딩 여정의 이벤트 순서를 시각화해 분석할 수 있습니다.
확보 방법
일반적으로 LexisNexis Risk Solutions에서 프로세스 단계를 추적하는 이벤트 로그나 감사 추적 테이블에 있습니다.
예시
신청 접수초기 심사 완료서류 요청규정 준수 검토 완료
|
|||
|
SLA 목표일
SlaTargetDate
|
고객 온보딩 프로세스를 완료할 예정인 날짜입니다. | ||
|
설명
SLA 목표일은 신청 처리에 적용되는 서비스 수준 계약의 완료 기한을 나타냅니다. 신청 유형, 고객 세그먼트, 관할 지역 등의 요인에 따라 날짜가 정해지는 경우가 많습니다. 이 속성은 'SLA 목표 준수 모니터링' 대시보드와 'SLA 준수율' KPI에 필요합니다. 실제 완료일과 SLA 목표일을 비교하면 약속한 서비스 수준에 대한 성과를 측정하고, SLA 위반 위험이 있는 케이스를 찾으며, 지연의 근본 원인을 조사할 수 있습니다.
중요한 이유
서비스 수준 계약에 따른 성과를 측정하고 SLA 위반을 일으키는 프로세스 비효율을 파악할 수 있습니다.
확보 방법
LexisNexis Risk Solutions 문서나 시스템 관리자에게 문의하세요. 케이스에 저장되어 있거나 업무 규칙에 따라 계산될 수 있습니다.
예시
2023-11-10T17:00:00Z2023-11-15T17:00:00Z2023-12-01T17:00:00Z
|
|||
|
담당 사용자
AssignedUser
|
활동을 수행한 사용자 또는 담당자를 식별하는 고유 ID입니다. | ||
|
설명
이 속성은 문서 검토를 수행한 규정 준수 담당자처럼 작업을 처리한 사람을 식별합니다. 업무량 배분과 개인별 성과를 분석하는 데 도움이 됩니다. 분석에서 담당 사용자는 '리소스 배분 및 업무량' 대시보드의 주요 기준입니다. 사용자별로 프로세스 맵을 필터링하고 팀원 간 성과를 비교하며, 교육이나 업무량 재조정이 필요한 부분을 찾을 수 있습니다. 특정 사용자 그룹으로 인해 발생하는 병목을 파악하는 데도 활용할 수 있습니다.
중요한 이유
리소스 성과와 업무량 배분을 분석하고 자동화 또는 리소스 최적화 기회를 찾는 데 중요한 속성입니다.
확보 방법
LexisNexis Risk Solutions 문서나 시스템 관리자에게 문의하세요. 감사 추적 또는 작업 관리 테이블에서 확인할 수 있습니다.
예시
j.doem.smithk.chen
|
|||
|
부서
Department
|
담당 사용자가 속한 사업 부서 또는 팀입니다. | ||
|
설명
부서 속성은 '규정 준수', '온보딩 운영', '사기 방지'처럼 활동을 담당하는 기능 조직을 나타냅니다. 이 속성을 사용하면 부서별로 프로세스를 분석하고 팀 간 업무 인계를 살펴볼 수 있습니다. '리소스 배분 및 업무량' 대시보드의 주요 분석 기준이며, 부서 간 비효율이나 소통 지연을 찾는 데 도움이 됩니다.
중요한 이유
기능 조직별 업무 인계와 성과를 분석해 부서 간 병목을 찾는 데 도움이 됩니다.
확보 방법
LexisNexis Risk Solutions 문서나 시스템 관리자에게 문의하세요. 사용자 또는 인사 마스터 데이터 테이블의 정보를 조인해야 할 수 있습니다.
예시
Compliance온보딩 팀KYC 분석가고객 지원
|
|||
|
신청 상태
ApplicationStatus
|
고객 신청의 현재 상태 또는 최종 상태입니다. | ||
|
설명
이 속성은 특정 시점의 케이스 전체 상태나 최종 결과를 나타냅니다. 일반적인 상태로는 '진행 중', '승인', '거절', '정보 대기'가 있습니다. 신청 상태는 온보딩 프로세스의 결과를 추적하는 데 중요합니다. '신청 거절 사유 및 단계'와 '일별 처리량 및 신청 상태' 대시보드에서 성공률과 운영 흐름을 모니터링하는 데 사용됩니다. 시간에 따른 상태 변화를 분석하면 케이스의 진행 과정을 파악할 수 있습니다.
중요한 이유
각 신청의 결과를 추적합니다. 신청 거절률과 같은 주요 KPI를 계산하고 처리량을 모니터링하는 데 필요합니다.
확보 방법
LexisNexis Risk Solutions 문서나 시스템 관리자에게 문의하세요. 일반적으로 주요 케이스 또는 신청 객체의 필드로 제공됩니다.
예시
진행 중승인거절고객 정보 대기
|
|||
|
위험 수준
RiskLevel
|
고객 신청의 산출된 위험 수준입니다. 예를 들어 낮음, 중간, 높음으로 표시됩니다. | ||
|
설명
LexisNexis Risk Solutions는 위험 평가를 전문으로 합니다. 이 속성은 평가 결과를 나타내며, 잠재적 위험 프로필에 따라 각 신청을 분류합니다. 위험 수준에 따라 실사에 필요한 강도와 기간이 달라지는 경우가 많습니다. 이 속성은 '위험 수준별 온보딩 소요 시간' 대시보드의 주요 분석 기준입니다. 위험 수준별로 프로세스를 분석하면 고위험 신청에 예상보다 훨씬 오래 걸리는지, 저위험 신청이 불필요하게 지연되는지 확인할 수 있습니다. 위험 기반 온보딩 전략을 검증하고 개선하는 데 도움이 됩니다.
중요한 이유
위험 기반 분석에 중요하며, 고객의 위험 프로필이 프로세스의 복잡도와 소요 시간, 진행 경로에 미치는 영향을 파악할 수 있습니다.
확보 방법
LexisNexis Risk Solutions 문서나 시스템 관리자에게 문의하세요. 위험 평가 모듈에서 산출하는 주요 결과값입니다.
예시
낮음중간높음제재 대상
|
|||
|
종료 시각
EndTime
|
활동이 완료된 정확한 날짜와 시각입니다. | ||
|
설명
이 타임스탬프는 활동이 완료된 시각을 나타냅니다. 이벤트의 종료 시각에서 시작 시각을 빼면 처리 시간이 계산됩니다. 종료 시각은 각 단계에 걸리는 시간을 정확히 계산하는 데 필요하며, '활동 처리 및 대기 시간' 대시보드의 주요 입력값입니다. 리소스가 작업을 실제로 처리한 시간과 다음 단계가 시작되기를 기다린 시간을 구분하는 데 도움이 됩니다.
중요한 이유
활동 처리 시간을 정확히 계산할 수 있어 비효율적인 단계를 찾고 리소스 업무량을 분석하는 데 도움이 됩니다.
확보 방법
LexisNexis Risk Solutions 문서나 시스템 관리자에게 문의하세요. 시작 및 종료 이벤트를 모두 기록하는 이벤트 로그에서 확인할 수 있는 경우가 많습니다.
예시
2023-10-26T10:45:10Z2023-10-26T11:55:30Z2023-10-28T09:05:00Z
|
|||
|
SLA 상태
SlaStatus
|
완료된 신청이 SLA 목표를 준수했는지 나타냅니다. | ||
|
설명
이 속성은 완료된 각 케이스가 'SlaTargetDate'를 준수했는지에 따라 분류합니다. 일반적인 값은 '준수' 또는 '위반'입니다. 이 계산 필드는 'SLA 목표 준수 모니터링' 대시보드와 'SLA 준수율' KPI의 기반입니다. 서비스 약속에 대한 성과를 한눈에 보여주며, SLA를 위반한 케이스의 공통 특성을 파악하도록 상세 분석을 지원합니다.
중요한 이유
SLA 성과를 준수 또는 위반으로 명확히 구분해 서비스 수준 목표의 규정 준수를 쉽게 추적하고 보고하며 분석할 수 있습니다.
확보 방법
케이스별 최종 활동의 타임스탬프와 'SlaTargetDate'를 비교해 산출하는 계산 속성입니다.
예시
준수위반위험
|
|||
|
거절 사유
RejectionReason
|
신청이 거절된 이유를 설명하는 코드 또는 내용입니다. | ||
|
설명
신청의 최종 상태가 '거절'인 경우 이 속성에 구체적인 사유가 기록됩니다. 예를 들면 '신원 확인 실패', '제재 목록 일치', '서류 미비' 등이 있습니다. 이 데이터는 '신청 거절 사유 및 단계' 대시보드의 주요 입력값입니다. 거절 사유를 분석하면 프로세스에서 자주 실패하는 지점을 찾아 신청 안내, 고객 커뮤니케이션 또는 내부 검토 기준을 개선할 수 있습니다. 신청이 거절되는 이유를 파악하는 것은 전체 승인율을 높이는 데 중요합니다.
중요한 이유
온보딩이 실패하는 이유를 직접 파악해 신청 승인율을 높이기 위한 개선에 활용할 수 있습니다.
확보 방법
LexisNexis Risk Solutions 문서나 시스템 관리자에게 문의하세요. 신청 상태가 '거절'로 설정될 때 값이 입력되는 필드에서 확인할 수 있는 경우가 많습니다.
예시
제재 목록 일치서류 미비신원 확인 실패고위험 프로필
|
|||
|
고객 국가
CustomerCountry
|
고객의 거주 국가 또는 법인 설립 국가입니다. | ||
|
설명
이 속성은 고객의 국가를 나타냅니다. 국가와 관할 지역마다 규정과 위험 수준이 다르므로 KYC에서 중요한 요소입니다. 고객 국가별로 프로세스를 분석하면 처리 시간과 복잡도의 차이를 확인할 수 있습니다. 예를 들어 고위험 관할 지역의 신청은 추가 규정 준수 검토가 필요해 처리 시간이 길어질 수 있습니다. 이 분석은 리소스 계획을 세우고 지역별로 현실적인 SLA를 설정하는 데 도움이 됩니다.
중요한 이유
관할 지역별 분석을 통해 지역 규정과 위험 요인이 프로세스 성과에 미치는 영향을 파악할 수 있습니다.
확보 방법
LexisNexis Risk Solutions 문서나 시스템 관리자에게 문의하세요. 고객 마스터 데이터에 일반적으로 포함되는 필드입니다.
예시
USAGBRDEUSGP
|
|||
|
규정 준수 검토자
ComplianceReviewer
|
규정 준수 검토 활동을 담당하도록 지정된 사용자 또는 담당자입니다. | ||
|
설명
'AssignedUser'는 모든 활동의 담당자를 기록하지만, 이 속성은 주요 검토 단계에 참여한 규정 준수 전문가를 별도로 식별합니다. 이를 통해 규정 준수 업무를 집중적으로 분석할 수 있습니다. 이 속성은 '규정 준수 검토 소요 시간 및 적체' 대시보드의 주요 기준입니다. 규정 준수 팀의 업무량과 성과를 분석해 특정 검토자가 병목인지, 팀 전체의 리소스가 부족한지 파악할 수 있습니다.
중요한 이유
규정 준수 업무를 집중적으로 살펴보고, 지연이 자주 발생하는 주요 프로세스 단계에서 검토자의 업무량과 성과를 자세히 분석할 수 있습니다.
확보 방법
LexisNexis Risk Solutions 문서나 시스템 관리자에게 문의하세요. 규정 준수 관련 활동을 기준으로 'AssignedUser'를 필터링해 산출할 수 있습니다.
예시
c.joness.patelsystem_escalation
|
|||
|
소스 시스템
SourceSystem
|
이벤트 데이터가 생성된 시스템 또는 애플리케이션입니다. | ||
|
설명
이 속성은 LexisNexis Risk Solutions나 연동된 타사 도구처럼 이벤트 데이터를 생성한 소스 시스템을 식별합니다. 복잡한 환경에서는 하나의 프로세스 데이터가 여러 시스템에서 수집될 수 있습니다. 소스 시스템을 파악하면 데이터를 검증하고 문제를 해결하며, 특정 시스템에서만 나타나는 프로세스 차이를 분석하는 데 도움이 됩니다. 데이터 무결성을 확인하고 활동이 어떤 시스템에서 어떻게 기록되었는지 이해할 수 있습니다.
중요한 이유
데이터의 출처를 식별합니다. 데이터 거버넌스와 검증, 여러 IT 시스템에서 프로세스가 실행되는 방식을 파악하는 데 중요합니다.
확보 방법
이 정보는 고정값으로 저장되거나 데이터 내보내기 파일 또는 API 응답의 특정 필드에 포함될 수 있습니다.
예시
LexisNexis Risk SolutionsThreatMetrixBridger Insight XG
|
|||
|
신청 유형
ApplicationType
|
'개인' 또는 '기업'과 같은 고객 신청 유형입니다. | ||
|
설명
이 속성은 온보딩 대상인 주체의 유형에 따라 신청을 분류합니다. 신청 유형마다 프로세스 경로와 위험 프로필, SLA 목표가 다를 수 있습니다. 신청 유형별로 프로세스를 분석하면 고객 유형에 따른 온보딩 효율과 복잡도를 비교할 수 있습니다. 대부분의 대시보드에서 자주 사용하는 필터로, 성과를 더 세분화해 살펴볼 수 있습니다.
중요한 이유
신청 유형별 처리 방식과 병목을 파악할 수 있도록 프로세스를 세분화해 분석합니다.
확보 방법
LexisNexis Risk Solutions 문서나 시스템 관리자에게 문의하세요. 일반적으로 신청 또는 케이스 객체의 주요 필드입니다.
예시
개인기업고액 자산가 개인신탁
|
|||
|
신청 채널
Channel
|
'웹', '모바일', '영업점'과 같이 신청서를 제출한 채널입니다. | ||
|
설명
신청 채널 속성은 신청서가 접수된 경로를 식별합니다. 채널에 따라 데이터 품질과 고객 행동, 온보딩 중 발생하는 문제 유형이 달라질 수 있습니다. 이 속성을 사용하면 채널별 프로세스 성과를 비교할 수 있습니다. 예를 들어 '온보딩 퍼널 전환율' 대시보드를 채널별로 필터링해 모바일 신청자의 이탈률이 웹 신청자보다 높은지 확인하고, 채널에 맞는 프로세스 개선 방안을 마련할 수 있습니다.
중요한 이유
신청 채널별 프로세스 성과를 분석해 채널 전략과 사용자 경험 개선에 참고할 차이를 파악할 수 있습니다.
확보 방법
LexisNexis Risk Solutions 문서나 시스템 관리자에게 문의하세요. 일반적으로 신청 프로세스가 시작될 때 기록됩니다.
예시
웹 포털모바일 앱영업점API
|
|||
|
자동화 여부
IsAutomated
|
활동을 시스템이 자동으로 수행했는지 사용자가 직접 수행했는지 나타내는 플래그입니다. | ||
|
설명
이 불리언 속성은 시스템 자동화로 처리된 작업(예: 초기 선별 검사)과 사람의 개입이 필요한 작업(예: 수동 서류 검토)을 구분합니다. '자동화 여부'는 '수동 활동 비율' KPI를 계산하고 자동화 도입의 효과를 분석하는 데 사용됩니다. 프로세스 맵에서 자동화 단계와 수동 단계가 이어지는 지점을 확인해 비용과 처리 시간을 줄일 수 있는 추가 자동화 기회를 찾을 수 있습니다.
중요한 이유
수동 작업과 자동화된 작업을 구분해 자동화 기회를 찾고 그 효과를 측정하는 데 도움이 됩니다.
확보 방법
LexisNexis Risk Solutions 문서나 시스템 관리자에게 문의하세요. 이벤트 로그의 플래그일 수도 있고, 'AssignedUser'가 'system' 사용자로 지정되었는지 등을 기준으로 추론할 수도 있습니다.
예시
truefalse
|
|||
|
재작업 여부
IsRework
|
재작업이 반복되는 구간에 포함된 활동을 식별하는 플래그입니다. | ||
|
설명
이 불리언 플래그는 같은 케이스에서 활동이 반복될 때 true로 설정됩니다. 예를 들어 '추가 정보 요청' 이후 '서류 검토 완료'가 다시 발생하는 경우입니다. 이는 프로세스가 이전 단계로 되돌아갔음을 나타냅니다. '재작업 여부'는 '재작업 및 반복 분석' 대시보드와 '재작업 반복 비율' KPI에 중요합니다. 낭비되는 작업량을 수치화하고, 안내가 불명확하거나 데이터 품질이 낮은 등 재작업의 근본 원인을 찾아 개선할 수 있습니다.
중요한 이유
프로세스의 비효율과 낭비되는 작업량을 직접 측정해 반복이 잦고 비용과 처리 시간을 늘리는 활동을 파악할 수 있습니다.
확보 방법
계산된 속성으로, 일반적으로 process mining 도구에서 케이스 내 활동 순서의 반복을 감지해 산출합니다.
예시
truefalse
|
|||
|
전체 처리 시간
CycleTime
|
고객 신청을 제출한 시점부터 최종 결정까지 걸리는 전체 시간입니다. | ||
|
설명
전체 처리 시간은 단일 케이스에서 첫 이벤트(예: '신청 제출')부터 마지막 이벤트(예: '고객 온보딩 완료' 또는 '신청 거절')까지 경과한 시간을 측정합니다. 전체 처리 시간은 프로세스 전반의 상태를 측정하는 주요 KPI이며, '온보딩 전체 처리 시간' 대시보드에서 확인할 수 있습니다. 평균 처리 시간을 추적하면 프로세스 개선의 효과를 모니터링하고 위험 수준이나 신청 유형 같은 요인이 전체 고객 경험에 미치는 영향을 파악할 수 있습니다.
중요한 이유
고객이 가치를 얻기까지 걸리는 전체 시간을 측정하는 주요 성과 지표입니다. 고객 만족도와 운영 효율에 직접 영향을 줍니다.
확보 방법
케이스별 마지막 이벤트의 타임스탬프에서 첫 이벤트의 타임스탬프를 빼서 계산합니다.
예시
5일 4시간22일 8시간1일 2시간
|
|||
|
최근 데이터 업데이트
LastDataUpdate
|
소스 시스템에서 데이터를 새로 고치거나 추출한 가장 최근 시각을 나타내는 타임스탬프입니다. | ||
|
설명
이 속성은 데이터 세트가 마지막으로 업데이트된 시각을 기록합니다. 일반적으로 데이터 추출 및 적재 과정에서 데이터 세트 전체에 적용됩니다. 대시보드 사용자는 이 정보를 통해 분석 중인 데이터가 얼마나 최신인지 확인할 수 있습니다. 필요한 최신성이 확보된 데이터를 바탕으로 의사결정을 내리고, 분석 결과가 어느 시점의 데이터를 반영하는지 파악하는 데 도움이 됩니다.
중요한 이유
데이터의 최신성을 파악하는 데 필요한 정보를 제공해 분석 결과의 적시성을 확인하고, 오래된 데이터를 근거로 의사결정하는 일을 방지합니다.
확보 방법
일반적으로 ETL(추출, 변환, 적재) 과정에서 생성되어 데이터 세트에 기록됩니다.
예시
2024-01-15T02:00:00Z2024-01-16T02:00:00Z2024-01-17T02:00:00Z
|
|||
KYC 고객 온보딩 활동
| 활동 | 설명 | ||
|---|---|---|---|
|
고객 온보딩 완료
|
이 이벤트는 고객 계정이 완전히 활성화되었음을 확인하며 전체 온보딩 프로세스의 성공적인 종료를 나타냅니다. 최종 상태로 명시되거나 '계정 활성화' 이벤트를 통해 추정할 수 있습니다. | ||
|
중요한 이유
성공 상태를 나타내는 대표적인 종료 이벤트입니다. 온보딩을 성공적으로 마친 모든 고객의 전체 처리 시간을 계산하는 데 필요합니다.
확보 방법
'계정 활성화' 타임스탬프를 통해 추정하거나 케이스 파일의 '온보딩 완료'와 같은 최종 종료 상태에서 확인할 수 있습니다.
기록
계정 활성화와 같은 마지막 주요 성공 이벤트나 최종 상태 업데이트를 통해 추정할 수 있습니다.
이벤트 유형
inferred
|
|||
|
규정 준수 검토 시작
|
일반적으로 위험도가 높은 신청 건을 규정 준수 담당자나 팀에 배정해 수동으로 검토합니다. '규정 준수 검토 대기' 상태로의 변경이나 작업 배정 로그를 통해 확인할 수 있습니다. | ||
|
중요한 이유
수동으로 진행되며 시간이 오래 걸리는 경우가 많은 검토 단계의 시작을 나타냅니다. 이 시점부터 완료까지의 시간을 측정하면 규정 준수 관련 병목을 파악할 수 있습니다.
확보 방법
작업 배정 로그, 케이스 담당 팀의 규정 준수 팀으로의 변경 또는 케이스 이력의 상태 업데이트에서 확인할 수 있습니다.
기록
'규정 준수 검토 중'과 같은 상태 변경이나 규정 준수 담당자 대기열에 케이스가 배정된 기록을 통해 추정할 수 있습니다.
이벤트 유형
inferred
|
|||
|
규정 준수 검토 완료
|
규정 준수 담당자가 검토와 권고를 마치고 케이스를 다음 단계로 넘깁니다. 작업이 '완료'로 표시될 때 명시적으로 기록하거나, '규정 준수 대기'에서 다른 상태로 바뀌는 것을 통해 추정할 수 있습니다. | ||
|
중요한 이유
중요하고 수동으로 진행되는 경우가 많은 프로세스 단계의 완료를 나타내는 주요 이정표입니다. 규정 준수 검토 시간을 측정하는 종료점으로 사용됩니다.
확보 방법
규정 준수 작업의 완료 타임스탬프나 '규정 준수 검토 중' 상태에서 벗어나는 상태 변경을 통해 확인할 수 있습니다.
기록
'승인', '반려' 또는 '최종 결정'으로의 변경처럼 검토가 끝났음을 나타내는 상태 변경을 통해 추정할 수 있습니다.
이벤트 유형
inferred
|
|||
|
서류 접수
|
고객이 필요한 서류를 시스템에 업로드하거나 제출했음을 확인합니다. 일반적으로 서류 제출 포털에서 이벤트가 생성되거나 담당자가 직접 입력합니다. | ||
|
중요한 이유
이 활동으로 대기 시간이 끝나고 후속 검토가 시작됩니다. 데이터 수집 단계의 주요 이정표입니다.
확보 방법
문서 관리 시스템 로그나 새 서류가 첨부될 때 신청 케이스 파일에 기록되는 타임스탬프에서 확인할 수 있습니다.
기록
서류가 성공적으로 업로드되거나 시스템에서 담당자가 수령 완료로 표시하면 이벤트가 기록됩니다.
이벤트 유형
explicit
|
|||
|
신청 반려
|
고객 신청의 최종 반려 결정이 기록됩니다. 프로세스의 종료 이벤트이며 시스템의 확정적인 상태 변경으로 확인할 수 있습니다. | ||
|
중요한 이유
실패 상태를 나타내는 대표적인 종료 이벤트입니다. 반려가 발생한 단계와 관련 사유를 분석하면 프로세스를 개선하는 데 도움이 됩니다.
확보 방법
신청 레코드의 최종 상태가 '반려', '거절' 또는 이에 준하는 종료 상태로 설정되었는지 확인합니다.
기록
주요 신청 테이블이나 케이스 테이블의 최종 상태 변경으로 기록됩니다.
이벤트 유형
explicit
|
|||
|
신청 승인
|
고객 신청의 최종 승인 결정이 내려져 시스템에 기록됩니다. 중요한 업무 결과이며 거의 항상 명시적인 상태 변경으로 남습니다. | ||
|
중요한 이유
이 이정표는 의사결정 프로세스가 성공적으로 끝났음을 나타냅니다. 승인으로 이어진 경로를 분석하면 모범 사례를 찾을 수 있습니다.
확보 방법
신청 케이스 레코드의 최종 상태가 '승인' 또는 이에 준하는 종료 상태로 설정되었는지 확인합니다.
기록
주요 신청 테이블이나 케이스 테이블의 최종 상태 변경으로 기록됩니다.
이벤트 유형
explicit
|
|||
|
신청 접수
|
고객 신청이 시스템에 처음 접수되면서 KYC 온보딩 프로세스가 시작됩니다. 일반적으로 LexisNexis와 연동된 고객 포털이나 내부 데이터 입력 시스템에서 신청서를 제출할 때 이 이벤트가 명시적으로 기록됩니다. | ||
|
중요한 이유
이 이벤트는 프로세스의 기본 시작점입니다. 이 활동부터 완료까지 걸린 시간을 분석하면 전체 처리 시간과 SLA 준수 여부를 측정할 수 있습니다.
확보 방법
새 고객 신청 레코드의 최초 생성 타임스탬프를 기록하는 시스템 로그나 신청 테이블에서 확인할 수 있습니다.
기록
새 신청 케이스가 생성되거나 핵심 신청 테이블에 항목이 추가될 때 이벤트가 기록됩니다.
이벤트 유형
explicit
|
|||
|
위험 평가 완료
|
시스템은 수집한 정보와 확인 결과를 바탕으로 고객의 위험 점수를 계산합니다. 이는 LexisNexis의 주요 기능이며 케이스 이력에 자동화 이벤트로 명시되는 경우가 많습니다. | ||
|
중요한 이유
평가 결과에 따라 강화된 고객 확인 절차가 필요한지 등 후속 프로세스 경로가 결정되는 경우가 많습니다. 워크플로에서 중요한 의사결정 지점입니다.
확보 방법
위험 점수 산정이나 평가 모듈의 완료를 기록한 애플리케이션 감사 로그 또는 워크플로 이력을 확인합니다.
기록
위험 엔진이 분석을 마치고 위험 프로필이나 점수를 부여하면 특정 이벤트가 기록됩니다.
이벤트 유형
explicit
|
|||
|
계정 활성화
|
승인 후 고객 계정이 핵심 뱅킹 또는 서비스 플랫폼에 정식으로 생성되고 활성화됩니다. 감사 추적에 기록되거나 계정 생성일을 통해 확인할 수 있습니다. | ||
|
중요한 이유
고객에게 가치를 제공하는 마지막 단계입니다. '신청 승인'부터 이 단계까지 지연이 발생하면 시스템 연동 문제일 수 있습니다.
확보 방법
계정 생성 로그, 다른 시스템에 대한 API 호출 또는 계정 레코드 자체의 생성 타임스탬프에서 확인할 수 있습니다.
기록
승인 후 별도 이벤트로 기록되거나 고객 레코드에 활성화 타임스탬프가 있는지 확인해 파악할 수 있습니다.
이벤트 유형
explicit
|
|||
|
서류 검토 완료
|
사용자나 자동화 도구가 제출된 서류의 진위, 유효성, 완전성을 검토합니다. '서류 접수'에서 '검토 완료'로 상태가 바뀌거나 명시적인 로그가 남으면 이 활동을 확인할 수 있습니다. | ||
|
중요한 이유
이 단계는 병목과 재작업이 자주 발생하는 구간입니다. 처리 시간과 반복 횟수를 분석하면 효율을 높이고 자동화 기회를 찾을 수 있습니다.
확보 방법
'서류 접수' 상태부터 '검증 통과' 또는 '추가 정보 필요'와 같은 후속 상태까지의 시간을 추적해 추정할 수 있습니다.
기록
서류 접수 이벤트와 검토 완료를 나타내는 이벤트 사이의 시간으로 계산합니다.
이벤트 유형
inferred
|
|||
|
서류 요청
|
시스템이나 사용자가 운전면허증, 공과금 고지서 등 필요한 서류를 고객에게 요청합니다. 시스템에서 생성한 커뮤니케이션 로그나 서류 대기 상태로의 변경을 통해 이 이벤트를 확인할 수 있습니다. | ||
|
중요한 이유
이 활동으로 프로세스에 대기 시간이 크게 늘어나는 경우가 많습니다. 발생 빈도와 소요 시간을 분석하면 고객 응답으로 인한 지연을 파악할 수 있습니다.
확보 방법
고객에게 발송한 커뮤니케이션 로그의 이벤트나 신청 상태 변경을 확인합니다. 예를 들어 '고객 서류 대기' 상태가 이에 해당합니다.
기록
'서류 대기' 상태로의 변경이나 고객에게 발송한 커뮤니케이션 로그의 타임스탬프를 통해 추정할 수 있습니다.
이벤트 유형
inferred
|
|||
|
신원 확인 시작
|
시스템이 데이터베이스 대조 등 LexisNexis 서비스를 이용해 본격적인 신원 확인을 시작하는 시점입니다. 확인 서비스가 호출될 때 이벤트 로그에 명시적으로 기록되는 경우가 많습니다. | ||
|
중요한 이유
이 활동은 중요하고 시간이 오래 걸리는 하위 프로세스의 시작을 나타냅니다. 소요 시간을 추적하면 신원 확인과 관련된 병목을 따로 파악할 수 있습니다.
확보 방법
신원 확인 모듈에 대한 API 호출 로그나 확인 작업의 시작을 보여주는 감사 추적 항목에서 확인할 수 있습니다.
기록
신청 건에 대해 시스템의 신원 확인 모듈이나 API가 실행되면 이벤트가 기록됩니다.
이벤트 유형
explicit
|
|||
|
초기 심사 완료
|
신청 직후 시스템이 기본 데이터의 완전성을 확인하고 사전 검사를 수행합니다. 이 활동은 프로세스 워크플로 이력에 자동화 단계로 명시되는 경우가 많습니다. | ||
|
중요한 이유
초기 단계에서 탈락하는 신청을 파악해 데이터 품질 문제를 확인할 수 있습니다. 또한 프로세스에서 처음으로 자동화된 부가가치 활동이 수행된 시점을 나타냅니다.
확보 방법
초기 심사 완료를 나타내는 자동 규칙 실행 로그나 신청 워크플로 이력의 상태 변경을 확인합니다.
기록
완료된 자동화 작업이나 케이스 이력의 특정 상태 변경으로 기록됩니다.
이벤트 유형
explicit
|
|||
|
추가 정보 요청
|
규정 준수 담당자나 검토자가 고객에게 추가 정보나 설명을 요청합니다. 재작업의 주요 원인이 되는 활동으로, 상태 변경이나 커뮤니케이션 로그에 명시적으로 기록되는 경우가 많습니다. | ||
|
중요한 이유
이 활동으로 재작업이 발생해 온보딩 처리 시간이 늘어날 수 있습니다. 발생 빈도를 추적하면 요구사항이 불명확하거나 신청서에 자주 누락되는 항목이 있는지 파악할 수 있습니다.
확보 방법
'고객 정보 대기' 상태로의 변경이나 발신 커뮤니케이션 이벤트 로그를 확인합니다. 담당자가 직접 실행하는 경우가 많습니다.
기록
담당자가 '정보 요청' 기능을 사용하면 기록됩니다. 이때 케이스 상태가 변경되고 커뮤니케이션 이벤트가 남을 수 있습니다.
이벤트 유형
explicit
|
|||
데이터 추출 가이드
시작할 준비가 되셨나요?
이 템플릿으로 KYC 고객 온보딩 process mining을 시작해 보세요. 지금 데이터를 실행 가능한 인사이트로 전환할 수 있습니다.
KYC 온보딩을 개선해 고객 이탈을 줄이세요
온보딩 절차를 간소화하고 처리 시간을 24시간으로 단축하세요.
신용카드 없이 시작할 수 있습니다. 지금 프로세스 개선을 시작하세요.