.svg)
AI 솔루션 문의하기
금융결제원 계좌실명조회 API는 금융결제원이 운영하는 오픈뱅킹 API 중 하나로, 계좌번호와 생년월일 또는 사업자등록번호를 보내 계좌 명의를 확인하는 데 씁니다. 기업이 이 API를 직접 쓰려면 금융결제원의 이용기관 절차를 거쳐야 하므로, 직접 연동할지 계좌 확인 기능을 제공하는 인증 서비스를 이용할지 먼저 정해야 합니다. 두 방식은 준비해야 할 것, 운영 중에 맡아야 할 일, 함께 붙일 수 있는 기능 범위가 다릅니다. 이 글은 계좌 명의 확인을 서비스에 붙이려는 기업 담당자가 두 방식을 비교할 때 볼 기준을 정리합니다. 세부 이용 조건과 절차는 바뀔 수 있으므로 금융결제원의 공식 안내를 함께 확인하세요.
금융결제원 계좌실명조회 API는 계좌의 명의가 누구인지를 확인하며, 계좌를 등록하는 사람이 그 계좌를 실제로 쓰는지는 확인하지 않습니다.
일반적으로 은행 코드, 계좌번호, 그리고 예금주를 확인할 수 있는 정보(개인은 생년월일, 사업자는 사업자등록번호)를 함께 보냅니다. 기업 서비스에서는 고객이 계좌 등록 화면에서 은행과 계좌번호를 입력하고, 생년월일은 가입 단계에서 확인한 값을 쓰는 방식이 많습니다. 고객이 계좌 등록 화면에서 생년월일을 새로 입력하게 하면 다른 사람의 정보로 그 사람 계좌를 등록하는 시도를 막기 어렵기 때문입니다.
보낸 정보가 계좌 명의와 맞으면 예금주 성명 같은 확인 결과를 받고, 맞지 않거나 조회할 수 없는 계좌라면 그에 해당하는 결과 코드를 받습니다. 결과 코드의 종류와 의미는 연동 문서에서 먼저 정리해 두어야 불일치, 조회 불가, 시스템 오류를 구분해 처리할 수 있습니다.
계좌실명조회는 계좌번호와 생년월일을 알고 있다면 본인이 아니어도 통과할 수 있습니다. 정산금이나 대출금처럼 고객 계좌로 돈을 보내는 업무에서는, 명의 확인과 별도로 고객이 그 계좌를 직접 쓰는지 확인하는 단계가 필요합니다. 예금주 성명만 확인하는 방식과의 차이는 계좌 예금주 조회 API 도입 전 반드시 확인할 사용법 가이드에서 다룹니다.
금융결제원 계좌실명조회 API를 직접 연동하려면 개발 작업 외에도 이용 절차와 운영 체계를 갖춰야 합니다.
금융결제원 오픈뱅킹 API는 정해진 이용기관 절차를 거친 기업만 쓸 수 있습니다. 신청 자격, 필요한 서류, 심사 항목은 금융결제원 안내에 따라 달라지므로, 개발 일정을 잡기 전에 우리 회사가 신청 대상인지와 준비할 항목부터 확인합니다.
일반적으로 테스트 환경에서 연동을 개발하고 점검한 뒤 운영 환경으로 전환합니다. 테스트 단계에서 정상 조회뿐 아니라 불일치, 조회 불가, 인증 오류 같은 실패 결과가 어떻게 오는지 모두 확인해 두어야 운영에서 예외 처리를 빠뜨리지 않습니다.
API 호출에 쓰는 인증 정보는 서버에만 보관하고, 만료 시점과 갱신 절차를 관리해야 합니다. 계좌번호와 생년월일 같은 민감한 정보를 다루므로 저장 방식, 접근 권한, 보관 기간에 대한 내부 기준도 함께 마련합니다.
은행별 점검 시간, 일시적인 장애, 결과 코드 변경 같은 상황에 대응할 담당자와 절차가 필요합니다. 조회 실패가 몰리는 시간대를 파악해 고객에게 미리 안내하고, 장애가 생기면 알림을 받아 바로 확인할 수 있게 해 둡니다.
조회 요청마다 고유번호를 붙이고, 그 아래 결과 코드와 처리 일시를 저장합니다. 계좌번호와 생년월일은 암호화하거나 일부를 가려 저장하고, 서비스에는 "명의 확인 완료"와 확인 일시를 남기는 방식이 개인정보 처리 면에서 유리합니다. 정산이나 환불 분쟁이 생겼을 때 어떤 계좌를 언제 확인했는지 바로 찾을 수 있도록 계정이나 거래 건과 연결해 둡니다.
계좌 명의 확인을 서비스에 붙이는 방법은 금융결제원 API를 직접 연동하는 방식과, 계좌 확인 기능을 제공하는 인증 서비스를 이용하는 방식으로 나뉩니다. 아래 항목별로 우리 회사 상황에 맞는 쪽을 고릅니다.
직접 연동은 이용기관 절차, 보안 기준, 테스트와 운영 전환을 모두 회사가 맡습니다. 인증 서비스를 이용하면 이런 준비를 서비스 제공사가 맡고, 회사는 제공사의 API와 연동하는 작업에 집중할 수 있습니다.
직접 연동은 계좌 명의 확인에 집중됩니다. 고객 본인 확인을 위한 신분증 확인이나 얼굴 매칭, 계좌 실사용 확인을 위한 1원 인증까지 필요하다면 각각 따로 연동해야 합니다. 인증 서비스 중에는 이런 기능을 하나의 흐름으로 묶어 제공하는 곳이 있어, 가입 단계와 계좌 등록 단계를 한 번에 설계할 수 있습니다.
직접 연동하면 은행 점검 대응, 결과 코드 관리, 장애 모니터링을 회사가 맡습니다. 인증 서비스를 이용하면 이런 부분을 제공사와 나눠 맡지만, 제공사의 장애 대응 범위와 안내 방식을 계약 전에 확인해 두어야 합니다.
직접 연동은 이용 수수료 외에도 이용기관 절차 준비, 보안 점검, 운영 인력에 드는 내부 비용을 함께 따져야 합니다. 인증 서비스는 호출 건당 과금처럼 사용량에 따라 비용이 정해지는 경우가 많아, 예상 월 조회 건수와 함께 쓰는 기능 범위를 정리한 뒤 비교하면 판단이 쉬워집니다.
계좌 명의 확인만 필요하고, 이용기관 절차와 운영 인력을 갖출 수 있는 기업은 직접 연동을 검토할 수 있습니다. 신분증 확인, 얼굴 매칭, 1원 인증까지 함께 필요하거나 빠르게 서비스에 붙여야 하는 기업은 여러 기능을 묶어 제공하는 인증 서비스가 맞는 경우가 많습니다. 처음에는 인증 서비스로 시작하고, 조회 건수가 크게 늘어 직접 운영할 여력이 생겼을 때 직접 연동을 다시 검토하는 방법도 있습니다. 어느 쪽을 고르든 결과 저장 구조와 실패 안내 기준은 회사가 정해야 하므로, 이 부분은 방식과 상관없이 먼저 설계해 둡니다.
계좌 명의를 확인한 뒤, 돈이 나가는 업무라면 고객이 그 계좌를 실제로 쓰는지 확인하는 1원 인증을 더합니다.
1원 인증은 고객 계좌로 1원을 보내고, 입금자명에 담긴 인증 코드를 고객이 직접 입력하게 하는 방식입니다. 계좌의 입출금 내역을 볼 수 있는 사람만 코드를 알 수 있으므로, 계좌번호와 생년월일만 알고 다른 사람 계좌를 등록하는 시도를 막을 수 있습니다. 명의가 맞는 계좌에만 1원을 보내면 불필요한 송금도 줄어듭니다. 계좌 소유 확인 방식 전체는 계좌 소유주 확인 API 가이드에서도 정리하고 있습니다.
계좌 등록 화면에서는 은행과 계좌번호를 입력받아 먼저 명의를 확인하고, 명의가 맞으면 바로 1원 인증 화면으로 넘깁니다. 1원 인증 화면에는 "은행 앱의 입출금 내역에서 1원 입금 건의 입금자명을 확인하세요"처럼 어디를 보면 되는지 알려주고, 인증 코드 입력 시간이 얼마나 남았는지 함께 보여줍니다. 명의가 맞지 않으면 1원 인증으로 넘기지 않고 본인 명의 계좌인지 다시 확인하라고 안내합니다.
알체라 eKYC는 1원 인증을 API로 제공해, 계좌 명의를 확인한 뒤 정산 계좌 등록·환불 계좌 등록·대출금 지급 계좌 확인 단계에 그대로 붙일 수 있습니다. 가입 단계의 신분증 확인과 얼굴 매칭까지 같은 흐름으로 구성할 수 있어, 고객 본인 확인과 계좌 확인을 따로 연동하지 않아도 됩니다. 알체라 eKYC는 고객사 110곳, 누적 1,430만 회 인증, 제1금융권 70%가 사용하고 있습니다.
.png)
.svg)
.svg)
