.svg)
AI 솔루션 문의하기
금융회사가 법인고객과 거래를 시작하거나 기존 고객의 정보를 갱신할 때는 법인의 기본정보와 대표자, 실제소유자, 거래 목적 등을 확인하는 절차가 진행될 수 있습니다. 특히 실제소유자가 복잡한 법인이라면 담당자가 수집한 자료를 검토하고 상위 결재자가 최종 판단을 내리는 과정이 추가될 수 있습니다.
이때 결과값만 저장하면 나중에 해당 판단이 누가, 언제, 어떤 자료를 근거로 내려졌는지 확인하기 어려워집니다. KYB 결재 이력 관리는 고객확인 결과와 함께 검토 과정 자체를 기록하는 방식으로 볼 수 있습니다.
법인 KYB 업무에서는 자료를 수집하고 입력하는 직원과 최종적으로 검토하는 직원의 역할이 다르게 설정될 수 있습니다. 담당자가 법인등기나 주주관계 자료를 확인한 뒤 결재자에게 검토를 요청하고, 결재자가 내용을 살펴 승인 또는 보완 요청을 내리는 방식입니다.
따라서 시스템에서도 작성자와 검토자, 승인자를 하나의 사용자 정보로 처리하기보다 각각의 역할을 구분해 기록하는 구조가 유용합니다. 담당자가 입력한 정보가 이후 수정됐더라도 최초 입력자와 최종 승인자를 별도로 확인할 수 있어야 이력의 의미가 유지됩니다.
금융정보분석원은 고객확인제도를 통해 금융회사가 고객의 신원과 실제소유자, 거래 목적, 자금 원천 등을 확인하는 체계를 설명하고 있습니다. 법인 고객의 경우 일정한 지분 보유자를 확인하고, 해당 기준으로 실제소유자를 특정하기 어려운 경우 다른 지배관계를 거쳐 확인하는 방식이 적용됩니다.
이 과정에서 중요한 것은 최종적으로 등록된 실제소유자 이름만 남기는 것이 아니라 해당 결과가 어떤 소유구조와 자료를 바탕으로 결정됐는지를 함께 연결하는 것입니다. 결재 이력에는 당시 확인된 주주관계와 검토자료의 버전, 판단 결과를 연결해 두는 방식이 활용될 수 있습니다.
법인정보는 한 번 확인한 뒤 계속 같은 상태로 유지되는 데이터가 아닙니다. 대표자나 주주가 바뀌거나 합병·분할이 발생하면 기존 KYB 정보도 다시 검토해야 하는 상황이 생깁니다.
자동화된 이력 관리에서는 변경 전 값과 변경 후 값, 수정한 사용자, 수정 시점, 변경 사유를 하나의 기록으로 묶을 수 있습니다. 이를 통해 현재 정보만 조회하는 화면에서도 과거 심사 당시의 상태를 별도로 확인할 수 있습니다.
특히 실제소유자 정보가 변경된 경우에는 기존 결재 결과와 현재 데이터를 구분해야 합니다. 같은 법인이라도 심사 시점에 따라 서로 다른 소유구조가 존재할 수 있기 때문입니다.
KYB 심사가 여러 부서에 걸쳐 진행되면 한 건의 고객확인에도 다양한 처리 상태가 생깁니다. 담당자 검토가 끝난 뒤 준법 담당자가 추가 확인을 하고, 필요한 경우 책임자 승인을 거치는 방식도 가능합니다.
이때 시스템이 모든 상태를 자유로운 텍스트로 저장하면 진행 상황을 파악하기 어려워집니다. 검토 요청, 보완 요청, 재검토, 승인, 반려 등 업무 단계별 상태를 정형화하는 방식이 관리 효율을 높일 수 있습니다. 상태가 변경될 때마다 변경자와 시간을 자동으로 남기면 담당자가 별도로 이력을 작성하는 부담도 줄어듭니다.
법인 KYB에서는 어떤 자료를 사용했는지도 중요하지만 그 자료가 어느 시점의 정보였는지도 함께 살펴볼 필요가 있습니다. 주주명부나 기업정보가 심사 도중 변경되면 담당자가 처음 확인한 내용과 최종 결재 시점의 정보가 달라질 수 있기 때문입니다.
자동화 시스템에서는 결재 당시 사용한 증빙자료의 식별정보와 제출·조회 시점, 자료 버전 등을 심사 기록에 연결하는 구조를 고려할 수 있습니다. 이후 고객정보가 업데이트되더라도 과거 결재 당시의 근거를 별도로 확인할 수 있게 됩니다.
모든 KYB 심사가 한 번에 끝나는 것은 아닙니다. 소유구조가 복잡하거나 제출자료 사이에 차이가 있으면 담당자에게 추가 자료를 요청하거나 결재자가 보완을 요구하는 과정이 발생할 수 있습니다.
이때 보완 요청을 단순한 메모로 남기기보다 요청 사유와 요청자, 대상 자료, 고객 측 회신, 재검토 결과를 하나의 심사 건에 연결하는 방식이 효과적입니다. 같은 법인에 대해 여러 차례 보완이 진행되더라도 각각의 검토 흐름을 시간순으로 확인할 수 있습니다.
KYB 자동화가 모든 결재 판단을 시스템에 맡기는 형태로 설계되는 것은 아닙니다. 법인정보와 기존 데이터를 자동으로 대조하거나 누락된 자료를 찾아내는 부분은 시스템이 처리할 수 있지만 복잡한 소유관계나 자료 간 불일치처럼 판단이 필요한 영역은 담당자 검토가 이어질 수 있습니다.
따라서 자동화의 핵심은 사람의 판단을 없애는 데 있기보다 반복적인 확인과 이력 기록을 시스템이 담당하고 사람이 판단한 내용을 구조화해 남기는 것에 있습니다.
1. 검토 요청 법인
담당자가 법인 기본정보와 관련 자료를 입력하고 KYB 검토를 요청한 상태입니다. 아직 최종 결재가 내려지지 않았으므로 현재 입력된 정보와 제출자료를 기준으로 심사가 진행됩니다.
2. 보완 심사 법인
자료 간 불일치나 추가 확인 사항이 발생해 추가 자료 또는 재검토가 진행되는 법인입니다. 최초 검토와 보완 검토를 별도 이력으로 연결하면 같은 사안이 반복해서 확인되는 과정을 추적하기 쉽습니다.
3. 결재 완료 법인
필요한 검토와 보완 절차를 거쳐 승인 또는 반려 등 최종 결재 결과가 기록된 법인입니다. 결과와 함께 결재자, 처리 시점, 당시 사용한 자료를 연결하면 사후 확인에 활용할 수 있습니다.
금융권의 고객확인 업무에서는 고객정보뿐 아니라 고객을 확인하고 관리한 과정에서 생성되는 기록의 추적성도 중요한 관리 요소가 됩니다. 특히 전자적으로 처리되는 금융업무에서는 관련 기록을 일정 기간 보존하도록 규정된 영역도 존재합니다. 전자금융거래법 시행령은 전자금융거래의 신청 및 조건 변경 등에 관한 기록을 포함한 일부 전자금융거래기록을 5년간 보존하도록 정하고 있습니다.
다만 KYB 결재 이력 전체가 이 규정에 일률적으로 동일한 보존기간을 적용받는다고 볼 수는 없습니다. 각 기록의 법적 성격과 적용 법령, 내부 보존정책을 구분해 관리하는 설계가 필요합니다.
KYB 이력에는 법인과 관계인의 정보가 포함될 수 있기 때문에 누가 어떤 기록을 조회하거나 변경할 수 있는지도 관리 대상이 됩니다. 특히 승인 이후 과거 기록이 임의로 수정되면 심사 과정의 신뢰성이 떨어질 수 있습니다.
이를 위해 승인 완료 기록은 수정 대신 변경 이력을 추가하는 방식을 활용하고, 사용자별 접근권한과 변경 권한을 분리하는 방식을 고려할 수 있습니다. 조회·수정·승인 행위 자체를 로그로 남기는 구조도 함께 활용됩니다.
KYB 결재 이력은 신규 법인을 심사할 때만 사용되는 데이터가 아닙니다. 기존 고객의 주주구조나 대표자 정보가 변경되거나 위험평가 결과가 달라지면 이전 심사 결과와 현재 상태를 비교하면서 재검토 범위를 정하는 데 활용할 수 있습니다.
과거 결재 기록이 구조화돼 있다면 담당자는 이전에 어떤 자료를 확인했고 어떤 사유로 승인을 받았는지 확인한 뒤 변경된 부분에 집중할 수 있습니다. 이 방식은 고객정보를 처음부터 다시 확인하는 업무와 구분됩니다.
법인 KYB에서 자동화의 대상은 고객정보 입력이나 서류 판독에만 한정되지 않습니다. 검토 요청부터 보완, 재심사, 최종 결재까지 이어지는 업무 흐름을 데이터로 남기는 것 역시 자동화 범위에 포함될 수 있습니다.
금융회사는 법인고객의 기본정보와 실제소유자 정보를 관리하면서 동시에 누가 어떤 자료를 바탕으로 판단했는지 확인해야 하는 상황을 마주하게 됩니다. 이때 결재 이력을 고객정보와 분리된 메모로 관리하기보다 심사 건, 증빙자료, 담당자, 결재 결과, 변경 이력을 서로 연결된 구조로 관리하면 이후 재심사와 내부통제, 감사 대응에서 활용할 수 있는 데이터가 만들어집니다.
.svg)
.svg)
