.svg)
AI 솔루션 문의하기
계좌실명조회 API는 고객이 입력한 계좌번호와 실명 정보(개인은 생년월일, 사업자는 사업자등록번호)를 보내 그 계좌의 명의가 고객과 일치하는지 확인하는 API입니다. 이름만 비교하는 예금주 조회보다 정확하게 고객 명의 계좌인지 가려낼 수 있어, 정산·환불·대출금 지급처럼 돈이 고객에게 나가는 서비스에서 계좌 등록 단계에 많이 씁니다. 다만 계좌실명조회는 명의를 확인할 뿐, 계좌를 등록한 사람이 그 계좌를 실제로 쓰는지는 확인하지 않습니다. 서비스에 계좌 확인을 붙이려는 기업 담당자라면 계좌실명조회가 어디까지 확인하고, 어디부터 다른 확인이 필요한지 먼저 나눠 두어야 합니다.
기업이 고객 계좌를 확인하는 방식은 예금주 조회, 계좌실명조회, 1원 인증의 세 가지로 나뉘며, 확인하는 범위가 서로 다릅니다.
예금주 조회는 은행과 계좌번호를 보내면 예금주 성명을 돌려받는 방식입니다. 확인되는 것이 이름뿐이라 동명이인의 계좌를 걸러낼 수 없습니다. 계좌실명조회는 이름 대신 생년월일이나 사업자등록번호까지 대조하기 때문에, 같은 이름의 다른 사람 계좌를 등록한 경우도 불일치로 걸러집니다. 예금주 조회를 도입할 때 확인할 점은 계좌 예금주 조회 API 도입 전 반드시 확인할 사용법 가이드에서 더 자세히 다룹니다.
1원 인증은 고객 계좌로 1원을 보내고, 입금자명에 담긴 인증 코드를 고객이 직접 입력하게 해 그 계좌를 실제로 쓰는 사람인지 확인하는 방식입니다. 계좌실명조회는 계좌번호와 생년월일만 알면 본인이 아니어도 통과할 수 있지만, 1원 인증은 계좌의 입출금 내역을 볼 수 있는 사람만 통과합니다. 즉 계좌실명조회는 "누구 명의의 계좌인가"를, 1원 인증은 "지금 등록하는 사람이 그 계좌를 쓰는가"를 확인합니다.
계좌 확인을 여러 단계로 나눠 쓰는 서비스는 빠르고 간단한 확인을 앞에 두고 1원 인증을 마지막에 둡니다. 먼저 계좌실명조회로 명의가 고객과 같은지 확인하고, 명의가 맞는 계좌에만 1원을 보내 실제 사용 여부를 확인하는 순서입니다. 명의가 다른 계좌에는 1원을 보내지 않으므로 불필요한 송금과 고객 대기 시간이 함께 줄어듭니다. 계좌 소유 확인 방식 전체는 계좌 소유주 확인 API 가이드에서도 정리하고 있습니다.
계좌실명조회 API는 고객이 등록한 계좌로 돈이 나가는 업무에서, 잘못된 계좌로 지급하는 일을 막기 위해 씁니다.
마켓플레이스나 플랫폼은 판매자와 파트너가 정산 계좌를 등록할 때 계좌실명조회로 명의를 확인합니다. 개인 판매자는 생년월일로, 사업자 판매자는 사업자등록번호로 대조해 가입 정보와 계좌 명의가 같은지 봅니다. 정산 계좌가 다른 사람 명의라면 등록 단계에서 바로 다시 입력하도록 안내합니다.
환불 계좌를 고객이 직접 입력하는 서비스는 오타 하나로 다른 사람에게 환불금이 나갈 수 있습니다. 계좌실명조회로 고객 명의 계좌인지 확인하면, 잘못된 계좌로 환불하고 다시 돌려받는 업무를 줄일 수 있습니다.
대출·캐피탈 서비스는 대출금을 지급하기 전에 지급 계좌가 차주 명의인지 계좌실명조회로 확인합니다. 지급액이 크고 되돌리기 어려운 업무이므로, 명의 확인에 더해 1원 인증으로 차주가 그 계좌를 직접 쓰는지까지 확인하는 구성이 많습니다.
이미 등록된 계좌를 바꾸는 시점은 명의 도용이 생기기 쉬운 단계입니다. 계좌 변경 요청이 들어오면 새 계좌에 대해 계좌실명조회를 다시 진행하고, 변경 직후 첫 지급 전에는 1원 인증을 함께 요청하는 기준을 둡니다.
계좌실명조회 API 연동은 준비, 입력 화면, 요청과 결과 판정, 결과 저장, 1원 인증 연결 순서로 진행합니다. 구체적인 요청 항목과 응답 형식은 제공사의 연동 문서를 따릅니다.
제공사에서 발급받은 API 키는 서버에만 보관하고, 앱이나 웹 화면 코드에 넣지 않습니다. 테스트용과 운영용 키와 요청 주소를 나눠 관리하고, 모든 요청은 암호화된 구간에서 주고받습니다. 연동 문서에서 일치·불일치·조회 불가가 각각 어떤 값으로 오는지, 은행 점검이나 서버 오류는 어떤 코드로 구분되는지 먼저 정리해 둡니다.
고객에게 은행, 계좌번호, 생년월일(사업자는 사업자등록번호)을 입력받습니다. 이미 가입 단계에서 확인한 이름과 생년월일이 있다면 다시 입력받지 않고 그 값을 기준으로 대조합니다. 계좌번호는 숫자만 입력되게 하고, 하이픈을 넣어도 자동으로 지우도록 만들면 입력 실패가 줄어듭니다.
서버에서 계좌실명조회를 요청하고, 일치로 나온 경우에만 다음 단계로 넘깁니다. 불일치가 나오면 1원 인증으로 넘기지 않고 계좌를 다시 확인하라고 안내합니다. 판정 규칙은 코드 여러 곳에 흩어 두지 말고 한 곳에서 관리해야, 나중에 기준을 바꿀 때 빠뜨리는 곳이 생기지 않습니다.
요청마다 고유번호를 붙이고, 그 아래 조회 결과와 처리 일시를 저장합니다. 계좌번호와 생년월일은 암호화하거나 일부를 가려 저장하고, 서비스에는 "명의 확인 완료"와 확인 일시를 남기는 방식이 개인정보 처리 면에서 유리합니다. 정산이나 환불 분쟁이 생겼을 때 어떤 계좌를 언제 확인했는지 바로 찾을 수 있게 계정이나 거래 건과 연결해 둡니다.
명의가 확인된 계좌로 1원 인증을 요청해, 고객이 그 계좌를 실제로 쓰는지 확인합니다. 고객은 은행 앱에서 1원 입금 건의 입금자명을 확인해 인증 코드를 입력하고, 코드가 맞으면 계좌 등록을 완료합니다. 1원 인증 연동 단계는 계좌조회 API 연동 방법에서 더 자세히 다룹니다.
알체라 eKYC는 1원 인증을 API로 제공해, 계좌실명조회로 명의를 확인한 뒤 계좌 등록·환불 계좌 등록·대출금 지급 계좌 확인 단계에 그대로 붙일 수 있습니다. 신분증 확인과 얼굴 매칭까지 같은 흐름으로 이어서 구성할 수 있어, 가입 단계의 본인 확인과 계좌 확인을 따로 연동하지 않아도 됩니다. 알체라 eKYC는 고객사 110곳, 누적 1,430만 회 인증, 제1금융권 70%가 사용하고 있습니다.
계좌실명조회의 실패는 고객이 다시 입력하면 해결되는 경우와, 고객이 할 수 있는 일이 없는 시스템 문제로 먼저 나눠 처리합니다.
입력한 생년월일이나 계좌번호가 틀렸거나, 다른 사람 명의 계좌를 입력한 경우입니다. "입력하신 정보와 계좌 명의가 맞지 않아요. 본인 명의 계좌인지 확인해 주세요"처럼 고칠 방법을 안내합니다. 어떤 항목이 맞지 않는지는 구체적으로 알려주지 않아야, 정보를 바꿔 가며 반복해서 조회하는 경우를 막을 수 있습니다.
은행 정기 점검 시간이나 일시적인 장애로 조회 결과를 받지 못하는 경우입니다. 고객에게는 잠시 후 다시 시도하라고 안내하고 입력한 정보는 유지합니다. 응답이 늦을 때 같은 요청을 바로 다시 보내지 말고, 요청 고유번호로 처리 결과를 먼저 확인합니다.
해지된 계좌나 거래가 제한된 계좌처럼 조회 자체가 되지 않는 경우가 있습니다. 결과 값이 불일치와 다르게 오는지 연동 문서에서 확인하고, 고객에게는 다른 계좌를 등록하도록 안내합니다.
같은 계정에서 여러 계좌를 짧은 시간 안에 계속 조회하거나, 같은 계좌를 여러 계정에서 등록하려는 시도는 명의 도용 신호일 수 있습니다. 계정별·계좌별 조회 횟수에 제한을 두고, 넘기면 담당자 검토로 넘깁니다. 검토 결과는 사유와 함께 남겨 이후 기준을 조정하는 근거로 씁니다.
.png)
.svg)
.svg)
