.svg)
AI 솔루션 문의하기
암호화폐 거래소는 계좌 개설부터 거래와 자산 관리까지 대부분의 과정이 온라인에서 이뤄지는 만큼 이용자 정보와 실제 계정 사용 주체를 확인하는 체계가 서비스 운영의 한 부분을 차지합니다. 회원가입 당시 확인한 정보가 이후에도 동일하게 유지된다고 단정하기 어려워 고객정보 변경이나 새로운 서비스 이용처럼 다시 확인이 필요한 상황도 발생합니다. eKYC 구축에서는 한 번의 본인확인 기능만 구현하기보다 고객확인 결과가 거래소의 회원관리와 서비스 이용 상태에 이어지는 구조를 설계하는 것이 핵심입니다.
신규 이용자가 거래소에 가입하면 이름과 생년월일 등 기본정보를 입력하고 신분증 확인 등의 절차를 거쳐 고객정보가 만들어집니다. 이때 입력정보와 확인된 정보가 서로 다를 경우 단순 오타인지 추가적인 확인이 필요한 상황인지 판단해야 합니다. 처음 만들어지는 고객정보를 이후 인증과 거래 과정에서 참조할 수 있는 기준정보로 관리하는 작업도 중요합니다. 신분증에서 추출한 정보와 인증 결과를 별도로 보관하더라도 어느 고객의 어느 신청에서 생성된 자료인지 연결관계를 명확하게 남겨야 합니다.
이러한 정보를 하나의 고객 식별체계 아래 연결해두면 회원관리 시스템과 인증 시스템이 서로 다른 상태를 보여주는 문제를 줄일 수 있습니다.
거래소에서는 회원가입과 실제 거래 서비스 이용이 동일한 단계로 진행되지 않을 수 있습니다. 가입이 완료된 이후에도 특정 기능을 사용하기 위해 별도의 확인 절차가 요구될 수 있기 때문입니다. 따라서 고객확인 완료 여부와 각각의 서비스 이용 가능 상태를 구분해 관리하는 구조가 필요합니다. 예를 들어 기본적인 회원 기능과 거래·자산 관련 기능에 적용되는 확인 조건이 다르다면 각 서비스가 참조해야 할 인증 상태도 달라집니다. 이런 상태를 명확하게 나누면 인증 시스템에서 모든 거래 요청을 직접 판단하지 않고 필요한 결과만 거래소 서비스에 전달할 수 있습니다.
이용자가 등록된 휴대전화번호나 주요 고객정보를 변경하는 경우에는 최초 가입 당시 확인했던 정보와 현재 정보 사이의 관계를 다시 살펴봐야 합니다. 특히 신원정보와 연결된 주요 항목이 변경됐을 때 기존 고객확인 결과를 그대로 유지할 것인지에 대한 기준이 필요합니다. 단순한 연락처 변경과 핵심 신원정보 변경을 동일하게 처리할 이유도 없습니다. 변경 항목의 성격에 따라 별도 인증을 요구하거나 기존 고객정보를 갱신하는 등 서로 다른 흐름을 구성할 수 있습니다.
오랫동안 거래소를 이용하지 않은 계정은 가입 당시 확인된 정보와 현재 이용환경 사이에 차이가 생겼을 가능성을 고려해야 합니다. 연락처나 인증수단이 변경됐거나 고객정보가 최신 상태가 아닐 수도 있기 때문입니다. 이 경우 마지막 고객확인 시점과 현재 요청 사이의 기간을 인증상태 관리에 활용하는 방식을 검토할 수 있습니다. 일정 조건에 해당하는 계정에서 추가 확인을 진행하도록 하면 모든 이용자에게 동일한 절차를 반복하지 않고 필요한 경우에만 재확인을 요청하는 구조를 만들 수 있습니다.
eKYC 과정에서 발생하는 실패는 원인에 따라 대응 방식이 달라져야 합니다. 신분증 촬영이 제대로 되지 않았거나 이미지 판독에 문제가 생긴 경우에는 재촬영으로 해결될 수 있지만, 확인된 정보와 기존 고객정보가 서로 맞지 않는 경우에는 다른 검토 절차가 필요할 수 있습니다. 따라서 시스템에서 단순히 성공과 실패 두 가지 상태만 제공하기보다 재시도 가능, 추가확인 필요, 정보 불일치 등 처리 단계를 구분하는 방식이 활용됩니다. 반복적인 실패가 발생한 고객은 이전 시도 결과와 현재 신청을 함께 확인할 수 있도록 이력을 연결해두는 편이 운영에도 유리합니다.
eKYC 구축에서는 신원확인을 위해 사용한 원본정보와 최종적으로 거래소가 참조하는 인증결과를 같은 범위에서 관리할 필요가 있는지 검토해야 합니다. 인증 완료 여부와 처리 시점 같은 결과정보와 신분증 이미지·얼굴정보 같은 원본자료는 성격이 다르기 때문입니다. 업무에 필요한 결과만 회원관리 시스템에 전달하고 원본자료는 별도의 접근권한과 보관기준을 적용하는 구조도 고려할 수 있습니다. 시스템을 여러 개 운영하는 거래소라면 어떤 개인정보가 어느 시스템까지 전달되는지도 함께 관리해야 합니다.
eKYC 이력은 단순한 인증 성공 여부보다 어떤 방식으로 확인이 진행됐고 어느 시점에 현재 상태가 만들어졌는지를 추적할 수 있는 형태가 적합합니다. 최초 인증과 재인증을 구분하고, 인증 실패 후 다시 시도한 과정도 필요한 범위에서 연결할 수 있습니다. 고객센터에서 인증 상태를 확인하거나 내부 운영자가 예외 상황을 처리할 때 이러한 이력이 활용됩니다. 특히 고객정보가 변경된 경우에는 변경 전후의 확인 상태가 뒤섞이지 않도록 각각의 처리 건을 구분하는 관리 방식이 요구됩니다.
eKYC 결과는 인증 서비스 안에만 남아서는 실제 거래소 업무에 활용하기 어렵습니다. 회원관리 시스템에서 현재 고객확인 상태를 조회하고 거래 관련 서비스가 필요한 인증조건을 참조할 수 있도록 연결하는 구조가 필요합니다. 인증이 완료된 고객에게는 해당 상태가 서비스에 반영되고, 재확인이 필요한 고객에게는 필요한 절차를 안내할 수 있어야 합니다. 인증 결과를 여러 시스템에 복제하는 방식보다 기준이 되는 상태를 명확히 정하고 각 서비스가 이를 참조하도록 구성하면 정보 불일치 문제도 관리하기 수월해집니다.
암호화폐 거래소에서는 새로운 거래 기능이나 고객 편의 기능이 추가되면서 기존에 없던 인증 요구사항이 생길 수 있습니다. 따라서 eKYC를 최초 구축한 뒤 고정된 절차로 운영하기보다 새로운 서비스가 추가될 때 어떤 고객확인 상태를 요구할 것인지 함께 정의하는 운영체계가 필요합니다. 실제 이용 과정에서 반복되는 인증 실패나 재확인 요청도 분석 대상이 됩니다. 이를 바탕으로 인증 단계와 예외처리 기준을 조정하면 거래소의 서비스 구조가 바뀌더라도 고객확인 체계를 함께 유지할 수 있습니다.
.svg)
.svg)
