.svg)
AI 솔루션 문의하기
계좌 실명 조회 API는 고객이 등록한 계좌의 명의가 고객과 같은지 확인하는 API로, 판매자 정산, 대출금 지급, 출금 계좌 등록, 보험금 지급처럼 서비스가 고객 계좌로 돈을 보내는 업무에 활용합니다. 같은 API라도 업종에 따라 확인하는 시점과 조회 결과를 쓰는 방법이 다릅니다. 판매자 정산은 사업자 계좌 확인이 중요하고, 대출금 지급은 지급 직전 확인이 중요하며, 출금 계좌 등록은 반복 시도를 막는 것이 중요합니다. 이 글은 업종별로 계좌 실명 조회 API를 어디에 두고, 조회 결과를 어떻게 활용하는지 기업 담당자 기준으로 정리합니다.
계좌 실명 조회 API는 업종마다 계좌를 등록받는 대상과 돈이 나가는 시점이 달라, 확인 위치도 달라집니다.
마켓플레이스는 판매자가 입점할 때 정산 계좌를 등록받습니다. 개인 판매자는 생년월일로, 사업자 판매자는 사업자등록번호로 계좌 명의를 대조해 입점 정보와 같은지 확인합니다. 정산 계좌가 입점 정보와 다른 명의라면 등록을 보류하고, 판매자에게 본인 또는 사업자 명의 계좌를 등록하도록 안내합니다. 고객 환불 계좌를 받는 커머스라면 환불 요청 단계에서도 같은 방식으로 확인합니다. 판매자가 정산 계좌를 바꾸는 요청은 정산금이 다른 사람에게 넘어갈 수 있는 시점이므로, 처음 등록할 때보다 한 단계 더 확인하는 기준을 둡니다.
대출·캐피탈 서비스는 대출금을 지급하기 전에 지급 계좌가 차주 명의인지 확인합니다. 신청 단계에서 한 번 확인하더라도, 심사 기간 중 계좌가 바뀌었을 수 있으므로 지급 직전에 다시 조회하는 구성이 안전합니다. 지급액이 크기 때문에 명의 확인 뒤에 1원 인증으로 차주가 그 계좌를 직접 쓰는지까지 확인하는 경우가 많습니다.
간편결제나 포인트·예치금 출금 서비스는 고객이 결제 수단이나 출금 계좌로 은행 계좌를 등록합니다. 고객이 여러 계좌를 등록할 수 있는 서비스라면 계좌를 추가할 때마다 조회하고, 같은 계정에서 짧은 시간 안에 여러 계좌를 등록하려는 시도에는 횟수 제한을 둡니다.
배달, 대리운전, 프리랜서 플랫폼처럼 일한 대가를 정기적으로 지급하는 서비스는 작업자의 지급 계좌를 등록받습니다. 지급 주기가 짧고 건수가 많아, 등록할 때 한 번 정확히 확인해 두면 이후 지급 업무에서 계좌 오류로 생기는 재지급과 문의를 줄일 수 있습니다. 작업자가 가족 명의 계좌로 수익을 받고 싶어 하는 경우도 있어, 본인 명의 계좌만 받을지 예외를 둘지 플랫폼 정책을 먼저 정하고 그에 맞게 조회 결과를 처리합니다.
보험금 청구를 비대면으로 받는 경우, 고객이 입력한 지급 계좌가 수익자 명의인지 확인합니다. 수익자와 계약자가 다른 경우가 있으므로, 누구 명의 계좌로 지급해야 하는지 업무 기준을 먼저 정해 두고 그 기준으로 대조합니다. 지급 계좌가 수익자 명의가 아니라면 지급을 보류하고, 수익자 본인 계좌로 다시 등록하도록 안내합니다.
계좌 실명 조회 API의 결과는 계좌 등록을 승인할지 판단하는 데 그치지 않고, 이후 지급과 이상 거래 대응에도 활용합니다.
명의가 일치하면 계좌 등록을 승인하거나, 업무에 따라 1원 인증 단계로 넘깁니다. 일치 결과와 확인 일시는 계정에 연결해 저장해, 이후 지급할 때 확인 결과가 있는 계좌인지 바로 판단할 수 있게 합니다.
명의가 맞지 않으면 등록을 보류하고 본인 명의 계좌인지 확인하라고 안내합니다. 이미 등록된 계좌를 다시 조회했을 때 불일치가 나왔다면 해당 계좌로의 지급을 멈추고 담당자 확인으로 넘깁니다. 어떤 항목이 틀렸는지 구체적으로 알려주지 않아야 정보를 바꿔 가며 반복 조회하는 시도를 막을 수 있습니다.
해지된 계좌나 거래가 제한된 계좌처럼 조회 자체가 되지 않는 경우가 있습니다. 불일치와 구분해 처리하고, 고객에게는 다른 계좌를 등록하도록 안내합니다. 은행 점검이나 일시 오류로 결과를 받지 못한 경우는 잠시 후 다시 시도하게 합니다.
조회 결과를 모아 보면 이상 신호를 찾을 수 있습니다. 같은 계좌가 여러 계정에 등록되거나, 한 계정에서 불일치가 반복되거나, 가입 직후 계좌를 여러 번 바꾸는 경우는 명의 도용이나 부정 이용 신호일 수 있습니다. 이런 패턴에 해당하면 1원 인증을 추가로 요청하거나 담당자 검토로 넘깁니다.
정산이나 지급 분쟁이 생기면 어떤 계좌를 언제 어떤 결과로 확인했는지 제시해야 합니다. 계좌번호와 생년월일 원본 대신 확인 결과와 일시를 저장하고, 계좌번호는 일부를 가려 보관하면 개인정보 부담을 줄이면서 기록을 남길 수 있습니다.
조회 결과를 업무별로 모아 일치율, 불일치율, 조회 불가 비율을 주기적으로 봅니다. 특정 화면에서 불일치가 많다면 입력 화면의 안내가 부족하거나 은행 선택 목록이 헷갈리게 구성됐을 수 있습니다. 특정 시간대에 조회 불가가 몰린다면 은행 점검 시간과 겹치는지 확인하고, 그 시간에는 미리 안내 문구를 보여주는 방식으로 고객 문의를 줄입니다.
계좌 실명 조회 API는 고객 본인 확인을 마친 뒤, 그 고객의 계좌를 확인하는 단계에 둡니다.
먼저 신분증으로 고객이 누구인지 확인하고, 확인된 이름과 생년월일로 계좌 명의를 대조한 뒤, 1원 인증으로 고객이 그 계좌를 실제로 쓰는지 확인합니다. 이 순서로 두면 앞 단계에서 확인된 값을 다음 단계의 기준으로 쓸 수 있어, 고객이 같은 정보를 여러 번 입력하지 않아도 됩니다. 계좌 소유 확인 방식 전체는 계좌 소유주 확인 API 가이드에서도 다룹니다.
계좌 명의를 대조할 때 고객이 계좌 등록 화면에서 새로 입력한 이름과 생년월일을 기준으로 삼으면, 다른 사람의 정보를 입력해 그 사람 계좌를 등록하는 시도를 막을 수 없습니다. 가입 단계에서 신분증으로 확인한 이름과 생년월일을 기준값으로 저장해 두고, 계좌 실명 조회는 그 값과 대조합니다. 이렇게 하면 신분증 확인과 계좌 확인이 같은 사람을 기준으로 이어집니다.
알체라 eKYC는 1원 인증을 API로 제공하고, 신분증 확인과 얼굴 매칭까지 같은 흐름으로 구성할 수 있습니다. 계좌 실명 조회로 명의를 확인한 뒤 1원 인증으로 실제 사용 여부를 확인하는 단계를 정산 계좌 등록, 대출금 지급, 출금 계좌 등록 화면에 그대로 붙일 수 있습니다. 알체라 eKYC는 고객사 110곳, 누적 1,430만 회 인증, 제1금융권 70%가 사용하고 있습니다.
모든 업무에 같은 강도로 확인하면 고객 이탈이 늘고, 너무 약하게 확인하면 잘못된 지급이 생깁니다. 다음 세 가지 기준으로 업무별 강도를 정합니다.
금액이 큰 지급은 명의 확인과 1원 인증을 모두 거치고, 소액이지만 자주 지급하는 업무는 등록할 때 정확히 확인한 뒤 계좌 변경 시점에만 다시 확인합니다.
대출금처럼 한 번 나가면 회수하기 어려운 지급은 확인 강도를 높입니다. 환불처럼 금액이 작고 고객이 직접 입력 오류를 바로잡을 수 있는 업무는 계좌 실명 조회만으로도 충분한 경우가 많습니다.
확인 단계가 늘어날수록 중간에 그만두는 고객도 늘어납니다. 위험이 큰 업무에만 1원 인증을 더하고, 이미 확인한 계좌는 정해진 기간 안에 다시 확인하지 않는 기준을 두면 확인 강도와 고객 경험을 함께 맞출 수 있습니다.
.png)
.svg)
.svg)
