LEI 갱신 지연을 기업 폐업으로 읽는 비용

요약

LEI의 LAPSED는 등록을 제때 갱신하지 않았다는 뜻이다. 기업이 활동을 중단했는지는 별도 항목이며, 공식 정의는 두 판단을 섞지 않는다.
갱신, 모회사 정보 신고, 거래별 수용 조건을 구분해야 문제를 고칠 주체도 드러난다. 매일 받는 데이터 파일이 기업 정보를 매일 재확인했다는 증거는 아니다.

거절 사유가 정확하면 다음 전화의 수신인이 정해진다. “등록 갱신이 필요하다”면 해당 기업과 발급기관이 처리할 일이다. “모회사 정보가 부족하다”면 관계 신고를 살펴야 한다. 그런데 모두 “기업 식별 실패”라고 뭉뚱그리면 고객은 여러 창구를 돌고, 각 창구는 똑같은 빨간 표시를 보여 준다. 화면은 간단해졌고 일은 늘었다.

법인 식별기호인 LEI는 20자리 코드로 법적 실체를 식별한다. 여기에 붙는 이름과 등록정보, 상태, 날짜는 같은 상대를 알아보고 자료의 시점을 판단하는 데 쓰인다. 문제는 자료를 받는 쪽이 상태 하나를 골라 기업 전체에 대한 판결로 바꿀 때 생긴다. 그 대표적인 함정이 LAPSED다.

빨간 표시에도 서로 다른 이유가 있다

GLEIF의 LEI-CDF 3.1 규격에는 EntityStatus와 RegistrationStatus가 따로 있다. 앞의 항목은 법적 실체의 상태, 뒤의 항목은 관리 발급기관에 등록된 LEI의 상태를 다룬다.

EntityStatus의 ACTIVE는 마지막 보고나 갱신 시점에 해당 실체가 적법하게 등록되어 활동 중이라고 보고했다는 의미다. INACTIVE는 폐업이나 합병 등의 사유로 더 이상 적법하게 등록되어 있지 않거나 활동하지 않는다고 확인된 경우다. 시간 조건은 녹색 표시 뒤에서도 사라지지 않는다.

RegistrationStatus의 LAPSED는 다음 갱신일까지 갱신이 이뤄지지 않았고, 공개 자료상 활동을 중단한 것으로 알려지지 않은 등록을 가리킨다. 기한을 넘긴 서류를 기업의 사망진단서로 쓸 근거가 여기에 어디 있는가. RETIRED는 합병 없이 활동을 끝낸 실체의 등록, DUPLICATE는 더 이상 쓰지 않아야 할 중복 등록, ANNULLED는 발급 후 오류나 무효가 확인된 등록이다. 결과 화면에서 이들을 모두 같은 실패로 표시하더라도, 처리 과정에서는 각각의 이유가 살아 있어야 한다.

ISSUED에도 마지막 갱신 시점에 활동하던 실체라는 조건이 붙는다. 이 코드와 ACTIVE는 현재의 지급 능력이나 계약 이행 능력을 대신 평가해 주지 않는다. 회사의 존재, 정보의 최신성, 거래 상대방으로서의 적합성은 근거가 다른 질문이다.

데이터가 오늘 도착했다는 사실

GLEIF가 설명하는 품질 관리 과정은 기업의 정확한 자기 신고에서 시작한다. 발급기관은 국가 기업등록부 같은 현지의 권위 있는 원천과 대조해 확인한다. 기업은 변경 사항을 관리기관에 알려야 하며, 연례 갱신을 통해 양측은 적어도 매년 한 번 정보를 검토하고 재확인한다.

파일의 배포 속도는 더 빠르다. 발급기관은 관리 기록을 매일 공개하고, GLEIF도 통합 파일 등을 매일 배포하며 자동 품질 검사를 매일 수행한다. 매일 운행하는 배송차가 싣고 온 내용이 전부 그날 조사된 사실일 수는 없다. 일일 배포를 연례 확인과 혼동하면 오래된 사실에 오늘 날짜의 포장만 씌우게 된다.

LastUpdateDate는 관리 발급기관이 정보를 마지막으로 바꾼 시점이다. NextRenewalDate는 실체가 다음으로 갱신하고 다시 확인해야 할 날짜다. 원래 등록기관의 코드와 해당 기관에서 부여한 실체 번호도 확인 경로를 제공한다. 법인 관련 사건의 법적 효력 발생일과 기록일을 구분할 수 있는 항목 역시 있다. 이런 차이는 화면 장식이 아니라, 새 사실이 들어왔을 때 판단을 되돌릴 단서다.

갱신했는데 왜 여전히 비준수인가

등록 갱신만으로 모든 상태가 정리되는 것도 아니다. Policy Conformity Flag의 공식 설명은 적시 갱신에 더해 직접 모회사와 최종 모회사에 관한 신고, 또는 인정되는 미신고 사유를 요구한다. 이 조건들을 충족해야 conforming으로 표시된다.

따라서 non-conforming이면 갱신이나 정보 보완 가운데 무엇이 필요한지 찾아야 한다. 관계 신고에 문제가 있는데 갱신만 계속 요구하면, 고객은 해결되지 않는 숙제를 반복하게 된다. 반대로 인정되는 미신고 사유가 있는 기록을 보고 소유관계를 숨겼다고 단정하면, 수용기관이 원래 제도에도 없는 혐의를 보태는 셈이다.

GLEIF는 이 표시가 기술적 데이터 품질 지표와도 다르다고 설명한다. 파일 형식과 상태 변화 규칙의 준수, 특정 정책상 신고 조건의 충족, 기업의 신용은 한 줄로 줄 세울 수 있는 정보가 아니다. 원천에서 구분해 놓은 것을 이용 단계에서 다시 합쳐 버리면, 정교한 자료를 사소한 오해로 낭비하게 된다.

거래를 막았다면 무엇이 부족한지 말해야 한다

공식 LEI 검색 안내는 1단계 자료의 LAPSED를 기업의 비활동 상태로 읽지 말라고 설명한다. 2단계 관계 자료의 갱신 지연도 관계의 종료를 뜻하지 않는다. 이용자는 용도에 따라 허용할 상태를 결정하며, ISSUED 등록이나 PUBLISHED 관계만 받아들이는 경우도 있다.

어떤 거래에 현재 유효한 갱신 상태가 요구된다면 그 조건을 적용하면 된다. 다만 “이 거래에 필요한 갱신이 완료되지 않았다”는 설명과 “그 기업은 없어졌다”는 설명은 다르다. 전자는 누락된 확인을 채우는 작업으로 이어지고, 후자는 기존 거래처 기록을 닫거나 새로 만드는 작업으로 번질 수 있다. 멈추는 순간이 같아도 다시 움직이는 비용은 달라진다.

가령 구매 시스템이 LAPSED만 보고 공급업체의 기존 식별 연결을 끊는다고 가정하자. 업체가 갱신을 마쳐도 과거 발주, 계약, 대금 기록을 새 계정과 다시 연결해야 한다. 이는 가상의 사례지만 비용의 발생 지점은 분명하다. 갱신 지연에 더해 구매자의 분류 규칙이 복구 작업을 만든다. 외부 데이터를 썼다는 이유로 모든 비용을 외부 기관 탓으로 돌릴 수 없다.

실제 손실 규모를 계산하려면 거절된 거래와 정정 기록이 필요하다. 지금 확인되는 것은 잘못 묶인 질문이 잘못된 업무를 만든다는 구조다. 이유를 분리하면 갱신, 신고 보완, 원자료 정정, 내부의 오래된 판정 수정 가운데 어떤 조치가 필요한지 좁혀진다.

공개 검색은 무료이며 가입도 필요 없다. 변경 이력을 확인할 수 있고, 근거가 있는 사람은 자료에 이의를 제기할 수 있다. 이의는 발급기관으로 전달되어 해당 실체와 수정 필요성을 검토한다. 이용기관이 날짜와 근거를 버리고 최종 색깔만 저장하면, 그런 정정 통로를 스스로 활용하기 어렵게 만든다.

LEI를 이용하는 이유는 같은 상대를 매번 처음부터 알아보는 수고를 줄이기 위해서다. 정보 갱신을 요구하면서도 그 상대의 이력은 유지할 수 있다. 기한 하나를 잘못 읽은 뒤 익숙한 거래처를 낯선 사람으로 만드는 일은, 디지털화라는 이름으로 포장해도 여전히 헛수고다.