.svg)
AI 솔루션 문의하기
1원 계좌 인증 업체 추가 도입은 왜 하나 더 붙이는지를 먼저 정한 뒤, 그 이유에 맞는 기준으로 업체를 고르는 순서로 진행합니다. 이유가 정해지지 않으면 비교 기준이 흔들리고 견적 금액만 보고 고르게 됩니다. 이 글은 업체 선정과 비용을 다룹니다. 한 업체에 장애가 났을 때 다른 업체로 우회하는 구조는 1원 인증 이중화 글에서 다룹니다.
추가 도입의 이유는 보통 아래 네 가지 가운데 하나이고, 이유에 따라 먼저 볼 기준이 달라집니다.
1원 인증은 고객이 입력한 계좌로 1원을 보내고, 고객이 입금 내역에 표시된 인증 문구를 입력하게 해 그 계좌를 실제로 쓰는 사람인지 확인합니다. 여기에 입력한 계좌의 예금주명과 가입자명을 비교하는 명의 확인을 더하면 "계좌 소유자가 가입자 본인인가"를 확인하는 구조가 됩니다. 신분증 확인이나 얼굴 대조와는 다른 종류의 확인 수단이어서, 비대면 본인확인에서 다른 수단과 함께 조합해 씁니다. 1원 인증을 적용하는 방식은 1원 계좌 인증 eKYC 적용 사례 글에 정리해 두었습니다.
1원 계좌 인증 업체는 지원 은행 범위, 연결 방식, 응답 속도·성공률, 예금주 명의 확인, 과금과 실패 건 과금, 연동 기간 여섯 가지 기준으로 비교합니다. 서비스 설명이나 평판이 아니라 계약과 운영에서 실제로 달라지는 항목으로 비교해야 견적과 테스트로 확인할 수 있습니다.
고객 리뷰나 지원 시간에 대한 평가는 업체마다 기준이 달라 비교 기준으로 쓰기 어렵습니다. 대신 문서로 확인할 수 있는 항목으로 바꿔 묻습니다. 장애가 났을 때 공지하는 방식과 시점, 문의 채널, 응답 시간의 기준, 은행 점검 일정을 사전에 알려주는지가 해당합니다. 이 항목은 견적 요청서에 같은 질문으로 넣어 업체별 답을 받습니다.
오픈뱅킹과 펌뱅킹은 지원 은행 범위, 은행별 약정과 연동 부담, 점검과 장애의 영향 범위를 가릅니다. 업체가 어느 방식으로 은행과 연결하는지에 따라 같은 1원 인증이라도 지원 범위와 운영 방식이 달라집니다. 아래 설명은 일반적인 구분이며, 업체별 구성은 확인이 필요합니다.
공동으로 운영되는 인프라를 통해 여러 은행에 연결하는 방식입니다. 한 번의 연동으로 여러 은행에 접근하는 구조이므로, 지원 은행의 범위와 이용 조건은 그 공동 인프라가 제공하는 범위를 따릅니다. 은행을 하나씩 따로 연결하지 않아도 되는 점이 장점으로 꼽히지만, 공동 인프라가 지원하지 않는 기능이나 은행은 이 방식으로 처리하기 어렵습니다.
기업이나 제공 업체가 은행과 직접 연결하는 방식입니다. 은행별로 약정과 연동이 따로 필요한 경우가 많고, 연결한 은행에 한해 지원합니다. 은행과 직접 연결하므로 은행 단위로 대응할 수 있는 점이 장점이 될 수 있습니다. 반면 지원 은행을 늘리려면 은행마다 약정과 연동을 반복해야 합니다.
연동 기간은 방식, 지원 은행의 수, 은행별 약정과 심사, 테스트할 은행의 수, 사내 시스템 연동 범위에 따라 달라집니다. 이 글에서는 기간을 숫자로 제시하지 않습니다. 업체마다 은행별 일정이 다르므로, 두 방식이 은행별로 섞여 있는 업체라면 은행마다 일정을 따로 확인합니다. 연동 일정을 맞추려면 고객이 많이 쓰는 은행부터 먼저 연동하는 순서도 함께 정합니다.
은행마다 정해진 점검 시간이 있어 그 시간에는 조회나 송금이 제한될 수 있습니다. 공동 인프라의 점검과 개별 은행의 점검이 서비스에 미치는 범위가 다르므로, 점검 일정을 사전에 알려주는지, 점검 중에 들어온 요청을 실패로 돌려주는지 대기시키는지를 확인합니다. 어느 방식이든 점검 시간대에 고객이 보는 화면이 어떻게 되는지는 서비스 쪽에서 설계해야 합니다.
알체라 eKYC 1원 인증은 오픈뱅킹과 펌뱅킹 방식을 모두 지원합니다. 앞에서 본 것처럼 필요한 은행 범위와 연동 구조에 따라 맞는 방식이 달라지므로, 방식이 한 가지뿐인 업체는 서비스 구조에 맞지 않을 때 선택지가 없습니다. 알체라 eKYC 1원 인증은 고객이 입력한 본인 명의 계좌로 1원을 보내고, 입금 내역의 인증 문구를 입력하게 해 그 계좌의 실제 소유자인지를 확인합니다. 지원 은행 목록, 방식별 연동 조건, 과금 방식과 금액은 현재 쓰는 업체와 같은 항목표로 견적 단계에서 확인해 비교하면 됩니다.
세 가지 모두 업체의 설명으로 판단하지 않고 자사 환경에서 테스트하고 견적서 항목으로 확인합니다. 같은 1원 인증이라도 고객이 쓰는 은행과 가입자 구성에 따라 결과가 달라지기 때문입니다.
테스트 요청은 고객이 많이 쓰는 은행의 계좌를 목록으로 만들어 은행별로 보냅니다. 정상 계좌, 계좌번호가 틀린 경우, 은행 점검 시간대 요청을 모두 포함해야 업체의 처리 방식을 비교할 수 있습니다. 같은 조건으로 현재 업체와 후보 업체를 비교하고, 은행별로 어느 쪽 결과가 좋은지 표로 정리합니다. 업체가 제시하는 성공률 수치는 측정 조건이 다르므로 참고만 하고, 선정 근거는 자사 테스트 결과로 삼습니다.
예금주명과 가입자명을 비교할 때는 이름 표기 차이가 실패 원인이 됩니다. 띄어쓰기, 한글과 영문 표기, 개명, 법인이나 개인사업자 계좌, 외국인 이름의 표기 순서가 해당합니다. 업체가 이런 차이를 어떤 기준으로 일치로 판단하는지, 일치 판정 기준을 서비스에서 조정할 수 있는지 확인합니다. 가입자명을 고객이 입력한 값이 아니라 신분증에서 읽은 이름으로 쓰면 "신분증 명의와 계좌 예금주가 같은가"를 확인하는 구조가 됩니다. 이 연결을 업체 기능으로 제공하는지, 서비스에서 구현해야 하는지도 확인합니다. 예금주 확인 방식은 계좌 소유 확인 API 글에서 자세히 다뤘습니다.
실패라고 해도 사유에 따라 과금 여부가 다를 수 있으므로 하나씩 확인합니다.
사유별로 건수에 포함되는지 확인하고, 1원 송금 원금과 수수료를 누가 부담하는지도 견적서에서 따로 확인합니다. 송금 건수가 많으면 이 항목도 비용에서 비중이 생길 수 있습니다.
1원 인증 비용은 건수 분배, 재시도 정책, 다른 인증과의 묶음 계약으로 줄입니다. 세 방법 모두 단가를 낮추는 것이 아니라 불필요한 호출을 줄이거나 계약 조건을 서비스에 맞추는 방식입니다.
평시에 요청을 두 업체에 나눠 보내는 방법입니다. 은행별로 성공률이 높은 업체에 보내거나, 주 업체에 대부분을 보내고 보조 업체에 일부를 보내는 방식이 있습니다. 은행별로 성공률이 높은 쪽으로 보내면 실패와 재시도가 줄어 호출이 줄어듭니다.
다만 분배가 항상 비용을 줄이는 것은 아닙니다. 건수 구간이 높을수록 단가가 낮아지는 구조라면, 한 업체에 몰았을 때보다 분산했을 때 각 업체의 구간이 낮아져 단가가 올라갈 수 있습니다. 두 업체의 구간 구조를 놓고 몰아줄 때와 나눌 때의 총액을 같은 건수 가정으로 계산해 본 뒤 정합니다.
재시도 정책은 호출 건수에 직접 영향을 줍니다.
신분증 OCR, 사본판별, 얼굴 인증과 1원 인증을 한 업체에 묶으면 비대면 인증의 연동이 한 곳으로 정리되고, 건수를 합산하는 구간이나 계약 일원화를 협의할 여지가 생깁니다. 묶음을 검토할 때는 아래를 함께 확인합니다.
.png)
.svg)
.svg)
