"오픈뱅킹"의 두 판 사이의 차이
leejia1222 (토론 | 기여) |
leejia1222 (토론 | 기여) |
||
73번째 줄: | 73번째 줄: | ||
* 사용자인증 API : 사용자인증 API는 6개의 서비스 API를 사용하기 위하여, 일반고객의 인증 및 동의를 얻고 계좌등록을 수행하는 기능을 제공한다. 이용기관은 계좌에 접근하기 위하여 먼저 이용기관이 응용프로그램과 사용자의 오픈뱅킹용 계좌를 연결해야 하며, 이때 사용자이용 API를 호출하여 사용자의 인증 여부를 물을 수 있다. 사용자는 오픈뱅킹에서 제공하는 연동페이지에서 인증하거나 이용기관이 자체적으로 제공하는 연동페이지에서 오픈팽킹 연동을 할 수 있다. 이러한 인증 절차는 대부분의 인터넷 서비스에서 실질적인 표준으로 작용하고 있는 오오스(OAuth) 인증절차를 준용하여 구현되었다. | * 사용자인증 API : 사용자인증 API는 6개의 서비스 API를 사용하기 위하여, 일반고객의 인증 및 동의를 얻고 계좌등록을 수행하는 기능을 제공한다. 이용기관은 계좌에 접근하기 위하여 먼저 이용기관이 응용프로그램과 사용자의 오픈뱅킹용 계좌를 연결해야 하며, 이때 사용자이용 API를 호출하여 사용자의 인증 여부를 물을 수 있다. 사용자는 오픈뱅킹에서 제공하는 연동페이지에서 인증하거나 이용기관이 자체적으로 제공하는 연동페이지에서 오픈팽킹 연동을 할 수 있다. 이러한 인증 절차는 대부분의 인터넷 서비스에서 실질적인 표준으로 작용하고 있는 오오스(OAuth) 인증절차를 준용하여 구현되었다. | ||
* 관리 API : 오픈플랫폼은 금융 업무를 처리하기 위한 5개의 서비스 API 이외에도 이용기관의 서비스 관리를 도와주는 관리 API를 제공한다. 관리 API는 오픈플랫폼 운영 과정에서 이용기관의 요구를 반영하여 추가될 수 있으며, 현재는 참가은행의 서비스 상태를 조회하는 참가은행상태조회 API를 제공한다. 이용기관은 참가은행상태조회 API를 호출하여 16개 참가은행의 서비스 상태를 한번에 조회할 수 있다. 참가은행의 서비스 상태는 거래가능(Y), 장애(D), 종료처리(E)로 정의된다. | * 관리 API : 오픈플랫폼은 금융 업무를 처리하기 위한 5개의 서비스 API 이외에도 이용기관의 서비스 관리를 도와주는 관리 API를 제공한다. 관리 API는 오픈플랫폼 운영 과정에서 이용기관의 요구를 반영하여 추가될 수 있으며, 현재는 참가은행의 서비스 상태를 조회하는 참가은행상태조회 API를 제공한다. 이용기관은 참가은행상태조회 API를 호출하여 16개 참가은행의 서비스 상태를 한번에 조회할 수 있다. 참가은행의 서비스 상태는 거래가능(Y), 장애(D), 종료처리(E)로 정의된다. | ||
+ | |||
+ | ===기대효과=== | ||
===한계=== | ===한계=== |
2019년 11월 27일 (수) 20:42 판
오픈뱅킹은 핀테크기업이 금융서비스를 편리하게 개발할 수 있도록 은행의 금융서비스를 표준화된 형태로 제공하는 인프라를 말한다. 스마트폰에 설치한 응용프로그램을 통해 모든 은행 계좌에서 결제를 비롯한 금융서비스를 실시간으로 이용할 수 있다. 2019년 10월 30일부터 10개 대형 은행이 시범 운영을 시작했으며, 2019년 12월 정식 가동될 예정이다. 정식 운영이 시작되면 일반은행 16곳과 인터넷전문은행 2곳까지 총 18개 은행에 접근이 가능하다.
목차
개요
오픈뱅킹은 오픈 API와 테스트베드로 구성된다. 오픈 API는 핀테크기업이 직접 응용프로그램과 서비스를 개발할 수 있도록 공개된 프로그램 도구로서, 6개의 서비스 API와 인증/관리 API를 제공한다. 테스트베드는 개발된 서비스가 금융전산망에서 정상적으로 작동하는지 시험해 볼 수 있는 인프라이다. 핀테크기업은 오픈 API와 테스트베드를 활용하여 기존 금융서비스에 새로운 IT기술을 접목시킨 다양한 핀테크 서비스를 빠르고 편리하게 출시할 수 있다.
은행권을 아우르는 핀테크 서비스 출시를 위해서는 은행 모두와 개별적으로 협약을 맺어야 하는 번거로움이 있다. 또한, 전산표준이 다른 복수 은행과의 호환에 어려움이 있을 수 있다. 이러한 어려움을 해결하고자 16개 시중은행이 자발적으로 참여하여 세계 최초로 참가은행과 핀테크기업이 서비스 개발 과정에서 서로 소통할 수 있는 통로인 오픈플랫폼이 구축되었으며, 제공기관 확대, 이용대상 확대 등 오픈플랫폼이 오픈뱅킹으로 전환됨에 따라 더욱 더 혁신적인 서비스 개발을 지원한다.
오픈뱅킹은 오픈뱅킹에 참여하여 자금이체, 조회 등의 서비스를 제공하는 참가은행과 은행권 공동으로 오픈뱅킹 시스템을 구축하고 운영하는 금융결제원인 오픈뱅킹 센터, 금융결제원과 오픈뱅킹 이용계약을 체결하고 이용승인을 받은 핀테크사업자 및 참가은행인 이용기관, 오픈뱅킹 서비스 이용신청을 통해 이용기관이 오픈뱅킹을 기반으로 제공하는 서비스를 사용하는 사용자인 일반고객으로 구성된다.
이용기관은 참신한 아이이디어와 기술을 가지고 금융 분야에 진출하여 다양한 핀테크 서비스를 제공할 수 있게 되고, 핀테크 서비스를 이용하는 고객은 금융에 대한 접근이 쉬워지고 선택권이 넓어지는 효과가 생기게 되며, 참가은행은 이용기관이 제공하는 다양한 서비스를 통하여 신규 고객과 만날 수 있게 됨으로써 새로운 수익기회를 얻을 수 있다.
등장배경
오픈뱅킹은 스마트폰과 태블릿PC가 등장하면서 윈도우와 IE외 다른 환경에서 금융거래를 하고 싶어하는 고객의 목소리를 은행을 비롯한 금융권이 주목하면서 싹을 틔웠다. 오픈뱅킹에 대한 의견이 나오기 전, 국내 인터넷 사용자의 95% 이상은 웹브라우저로 IE를 사용하고 있었다. 이런 상황에서 국내 은행들은 굳이 다른 웹브라우저나 OS를 지원할 필요성을 느끼지 못했다. 자연스레 국내 인터넷뱅킹 서비스는 윈도우 기반의 IE를 사용하는 고객에게 최적화된 환경을 지원했다.
인터넷뱅킹 서비스가 처음 시작될 당시 안전한 금융거래를 위해 128비트 이상의 암호화 통신을 적용해야 했다. 또한 사용자 인증과 자신이 거래한 증거를 부정하지 못하게 하는 부인방지 기능을 위해 인증서와 전자서명 처리 기능이 요구됐다. 문제는, 당시에는 위 기능들을 웹브라우저에서 구현할 수 없었다는 데 있다. 금융권을 비롯한 국내 기업은 별도의 플러그인 형식의 프로그램을 통해 보안 기능을 적용했다.
당시 국내 PC의 인터넷 이용 환경은 윈도우와 IE 점유율이 압도적이었고 이에따라 국내 기업은 IE의 플러그인 기술인 액티브X 컨트롤러를 바탕으로 보안 프로그램 플러그인을 만들었다. 그러나 스마트폰에 이어 태블릿PC가 등장하면서 인터넷뱅킹 서비스에서도 다양한 기기를 지원해야 하는 과제가 생겼다. 윈도우 이외의 OS를 활용하는 사용자도 늘어나기 시작했다. 웹브라우저 시장 점유율에서 IE가 50% 이하로 떨어지기도 했다. 결국 2010년, 국내 금융권에선 처음으로 우리은행이 액티브X 외 다른 수단을 도입해 오픈뱅킹 서비스를 선보였다.
특징
이용대상
- 이용대상
오픈뱅킹의 이용대상은 일반고객과 핀테크 사업자, 은행으로 나뉜다. 본인명의의 휴대폰을 소지하고 있는 고객은 본인확인을 받은 후 오픈뱅킹 서비스를 이용할 수 있다. 핀테크산업 분류업종 기업, 전자금융업자, 전자금융보조업자, 오픈뱅킹 운영기관 인정기업 또한 오픈뱅킹 이용대상이다. 핀테크 사업자 및 은행에 대한 자세한 설명은 다음과 같다.
- 핀테크 사업자 : 정보통신기술 또는 그 밖의 기술을 활용하여 금융회사의 업무 효율성을 증대 시키거나 이용자의 편의성 향상에 기여하는 금융관련 업무
- 은행 : 오픈뱅킹공동업무 제공자 역할을 수행하는 참가 금융회사
- 핀테크산업 분류업종 기업
- 시스템 소프트웨어 개발 및 공급업
- 컴퓨터 프로그래밍 서비스업
- 기타 정보기술 및 컴퓨터운영 관련 서비스업
- 포털 및 기타 인터넷 정보 매개 서비스업
- 기타 금융지원 서비스업
- 응용소프트웨어 개발 및 공급업
- 컴퓨터시스템 통합 자문 및 구축 서비스업
- 자료 처리업
- 데이터베이스 및 온라인정보 제공업
- 제외서비스
- 출금대행 : 지급인의 출금동의를 수취인을 통해 전달받아 제3자가 출금을 대행하거나 동 권리를 재판매하는 경우
- 납부서비스 : 수납하려는 주체가 고객에게 제공하는 재화나 용역의 대가로써 일정금액을 정기적·반복적으로 추심(예약)하는 경우
- 제외대상
- 「사행행위 등 규제 및 처벌 특례법」상사행행위기업, 부도기업
- 다단계 판매, 상조회사, 대부업(P2P연계대부업포함)
- 이용기관이 서비스하고자 하는 사업모델상 필요자격 미달기업
- 기타 소비자 피해 발생이 우려되는 기업 등
- 게임머니·아이템 중개 또는 가상화폐 관련 사업모델 기업
- 미풍양속 저해, 불법행위 사업모델 기업(자금세탁, 테러자금조달 등)
- 영업 행태에 금융질서 문란행위가 의심되는 기업
- 모듈 재판매 시 하위사업자에게도 동일기준 적용
협력기관
- 유관기관 : 금융위원회, 금융감독원, 은행연합회, 금융보안원, 핀테크지원센터
- 참가은행 : KDB산업은행, NH농협은행, 신한은행, 우리은행, SC젱리은행, IBK기업은행, KB국민은행, KEB하나은행, 씨티뱅크, 수협은행, 대구은행, BNK부산은행, 광주은행, 제주은행, 전북은행, BNK경남은행, 카카오뱅크, 케이뱅크
API
오픈뱅킹에서 이용기관은 6개의 서비스 API, 인증/관리 API를 이용할 수 있다.
- 서비스 API
- 잔액조회 API : 사용자가 이용기관이 제공하는 서비스를 통해 본인계좌에 대한 잔액 및 출금가능금액을 조회하는 기능을 제공한다.
- 거래내역조회 API : 사용자가 이용기관이 제공하는 서비스를 통해 본인계좌에 대한 잔액 및 거래내역을 조회하는 기능을 제공한다.
- 계좌실명조회 API : 이용기관이 자금을 수취할 수취인 또는 출금이체 신청을 한 사용자 계좌의 정상여부 및 실명을 실시간 조회하는 기능을 제공한다.
- 송금인 정보조회 API : 이용기관이 자금을 출금이체 신청을 한 사용자 계좌의 정상여부를 실시간 조회하는 기능을 제공한다.
- 입금이체 API : 이용기관의 지급계좌에서 자금을 인출하여 수취인 계좌로 실시간 입금하는 기능을 제공한다.
- 출금이체 API : 이용기관의 출금에 동의한 사용자 계좌에서 출금하여 이용기관의 수납계좌로 실시간 입금하는 기능을 제공한다.
- 인증/관리 API
- 사용자인증 API : 사용자인증 API는 6개의 서비스 API를 사용하기 위하여, 일반고객의 인증 및 동의를 얻고 계좌등록을 수행하는 기능을 제공한다. 이용기관은 계좌에 접근하기 위하여 먼저 이용기관이 응용프로그램과 사용자의 오픈뱅킹용 계좌를 연결해야 하며, 이때 사용자이용 API를 호출하여 사용자의 인증 여부를 물을 수 있다. 사용자는 오픈뱅킹에서 제공하는 연동페이지에서 인증하거나 이용기관이 자체적으로 제공하는 연동페이지에서 오픈팽킹 연동을 할 수 있다. 이러한 인증 절차는 대부분의 인터넷 서비스에서 실질적인 표준으로 작용하고 있는 오오스(OAuth) 인증절차를 준용하여 구현되었다.
- 관리 API : 오픈플랫폼은 금융 업무를 처리하기 위한 5개의 서비스 API 이외에도 이용기관의 서비스 관리를 도와주는 관리 API를 제공한다. 관리 API는 오픈플랫폼 운영 과정에서 이용기관의 요구를 반영하여 추가될 수 있으며, 현재는 참가은행의 서비스 상태를 조회하는 참가은행상태조회 API를 제공한다. 이용기관은 참가은행상태조회 API를 호출하여 16개 참가은행의 서비스 상태를 한번에 조회할 수 있다. 참가은행의 서비스 상태는 거래가능(Y), 장애(D), 종료처리(E)로 정의된다.
기대효과
한계
다양한 환경에서 서비스를 이용할 수 있게 만들겠다는 금융권의 시도는 좋았다. 각 은행들이 오픈뱅킹 서비스를 시작한 뒤 윈도우와 IE 환경이 아니어도 웹사이트에서 계좌 거래 등이 이뤄졌기 때문이다. 그러나 여기까지였다. 국내 기업이 선보이는 오픈뱅킹은 아직까지는 2% 부족한 서비스란 한계를 지니고 있다. 오픈뱅킹 서비스라 해도 윈도우와 IE 환경에서처럼 여전히 각종 보안 플러그인을 설치해야 하기 때문이다. 여기엔 까닭이 있다. 금융감독원은 지난 2010년 ‘전자금융거래시 공인인증서 사용의무 규제완화 방안’을 발표하면서, 금융기관 또는 전자금융업자는 공인인증서를 사용하지 않고도 다양한 전자금융 서비스를 제공할 수 있는 기회를 열었다. 문제는 이용자 인증, 서버 인증, 통신채널 암호화 요건 등 ‘공인인증서와 동등한 수준의 체제’를 요구하며 여타 방법을 인증하지 않은 데 있다.
그 결과 국내에서 인터넷뱅킹 서비스를 제공하려면 인터넷뱅킹 서버와 PC 사이의 통신을 암호화하는 플러그인, 공인인증서와 전자서명을 관리하고 생성하는 플러그인, 키보드 입력값은 암호화하는 플러그인, 악성 프로그램 탐지를 위한 백신과 방화벽을 제공하는 플러그인, 가상키보드 플러그인 등이 기본으로 탑재돼야 한다. 이들 플러그인을 설치하지 않으면 계좌조회나 자금이체 같은 금융거래가 제한된다. 오픈뱅킹을 선보이겠다고 나선 은행들은 IE에서만 쓸 수 있는 액티브X 기술이 아닌 다양한 웹브라우저에서 사용할 수 있는 자바 애플릿을 활용해 보안 플러그인을 구현했다. 오픈뱅킹이 아닌 플러그인 뱅킹 시대가 열린 셈이다.
해외 금융기관의 인터넷뱅킹 서비스는 OS나 웹브라우저에 따른 제약이 없다. PC와 태블릿PC, 스마트폰 등 웹브라우저가 설치된 그 어떤 기기에서 인터넷뱅킹 서비스를 이용할 수 있다. 웹브라우저가 제공하는 기능만 이용해 서비스를 제공하고 플러그인 형태의 프로그램을 적용하지 않기 때문이다. 오픈뱅킹이란 단어는 사실 특정 운영체제와 웹브라우저를 지지하는 국내에서 탄생한 특수한 용어인 셈이다. 사용자의 인증정보를 획득하기 위한 악성코드 등의 등장으로 미국과 영국 등 나라마다 플러그인 방식의 보안 프로그램 사용을 권고하는 곳도 있다. 그렇지만 이 역시 플러그인 형태의 자동 설치 방식이 아닌 독립 애플리케이션 형태로 배포돼 고객이 직접 설치할 수 있게끔 만들었다. 설치 몫을 고객 선택에 맡긴 것이다.
게다가 해외에는 공인인증서처럼 국가가 정해놓은 인증서가 없다. 대신 안전한 금융결제를 위해 일회용 비밀번호를 적용하고 있다. 그 결과 해외는 페이팔, 스퀘어 같은 다양한 결제수단을 활용해 금융거래 서비스를 누리고 있다. 데스크톱PC 기반의 금융거래 환경을 스마트폰이나 태블릿PC환경에서 접해도 아무런 문제가 없다. 특정 환경에 종속되지 않은 결제 환경이기에 가능한 일이다. 그 결과 페이팔은 PC를 비롯한 다양한 환경에서 사용자 아이디와 비밀번호만 입력해 결제하는 편리성을 갖추고 있다. IE 기반의 액티브X에 종속된 보안수단이나 인증수단에저 자유롭기 때문이다. 스마트폰에 신용카드 리더를 탑재해 결제를 돕는 스퀘어도 마찬가지다.
정부는 2007년 장애인차별금지법을 제정하며 웹접근성 준수를 법으로 의무화했다. 이에 따라 개인 웹사이트를 뺀 모든 웹사이트는 웹브라우저와 OS에 관계없이 웹사이트 주요 콘텐츠와 서비스에 접근할 수 있도록 보장해야 한다. 정부도 ‘차세대 웹표준 HTML5 확산 추진계획’을 발표했다. 웹브라우저로 공인인증서를 직접 불러 사용할 수 있도록 표준화를 추진한다는 계획이다. 웹사이트를 이용할 때 별도 플러그인을 설치할 필요 없이 웹표준 기술 기반으로 다양한 OS와 플랫폼, 기기에서 콘텐츠를 이용할 수 있게 만들겠다는 얘기다. 여기까지 들어보면 방송통신위원회가 사용자를 위해 합리적인 선택을 내렸다고 생각할 수 있다.
문제는 방송통신위원회가 ‘웹 기반 전자서명 기능’과 ‘인증서 관리 기술’에 대한 개발과 표준화 작업을 하겠다며 한 발 더 나아갔다는 점이다. 그러면서 액티브X 등 별도 프로그램이 필요없는 전자결제 서비스 지원을 위해 국내 민간 주도로 표준안을 제안했다. 이를 위해 월드와이드웹컨소시엄 웹 크립토(W3C Web Crypto) API 워킹그룹을 결성하고, 국내 웹 환경과의 적합성을 사전 테스트한 뒤 복수의 웹브라우저에서 공인인증서 내 전자서명 기술 타당성 검증에 나서겠다고 덧붙였다.
이에 대해 업계는 “정부가 나서서 오픈뱅킹을 주도할 것이라 아니라 시장 흐름에 오픈뱅킹을 맡겨야 한다”라고 맞서는 중이다. 국내에서 열린 인터넷 환경을 위한 운동을 진행중인 ‘오픈넷’은 “인터넷뱅킹 서비스의 호환성을 개선하기 위해서는 보안 플러그인 프로그램뿐만 아니라 기타 기능을 제공하는 플러그인이 같이 제거돼야 한다”라고 주장한다. 가장 널리 이용되는 플래시 플러그인도 호환성을 저해할 요인이 될 수 있으므로 HTML5나 CSS3 등 최신 웹표준 기술을 적용해 서비스를 구성하고 플러그인 기술을 최소화해야 한다는 게 이들 입장이다.
사례
규제 동향
- 유럽연합
- 유럽은행감독위원회(EBA)는 유럽연합 내 지급결제관련 서비스 및 서비스업체에 대한 규정인 지불 서비스 지침(Payment Services Directive, PSD)을 개정, 2015년 12월 지불 서비스 지침(PSD2)을 공식 발표하고 2년여의 준비기간을 거쳐 2018년 1월 13일 도입했다. 이를 위해 지불 서비스 지침에서는 두 가지 유형의 제3자 지급서비스 제공자(third party payment service providers, TTP)를 정의하고 규범을 제시했다. 한편 유럽연합은 개인정보보호를 강화하기 위해 모든 데이터에 GDPR(general data protection regulation)을 적용, 지불 서비스 지침 시행에 따른 개인정보 활용 문제점을 보완했다. 유럽은행감독위원회는 PDS2의 인증 및 인터페이스 관련 요건을 담은 규제기술표준을 2018년 3월 확정하였다. 규제기술표준에서는 인터페이스와 관련된 세부 표준을 제시하지 않고, 은행들이 자율적으로 결정하도록 남겨두었다. 이에 따라 API 표준과 관련된 권고한을 정하고 특정 API가 지불 서비스 지침에 부합하는지 평가하기 위해 2018년 1월 ‘API EG (application programming interface evaluation group)’를 구성하였다.
- 영국
- 지불 서비스 지침 시행에 따라 영국은 자체 오픈뱅킹 정책을 추진했다. 오픈뱅킹과 지불 서비스 지침는 제3자에게 데이터를 제공한다는 점에서 공통적이며 다음과 같은 차이점이 있었다.
오픈뱅킹 지불 서비스 지침 적용 CMA9(영국대형은행) 계좌 유럽연합 내 모든 지급결제 계좌 API 단일 API 시장 자율 규정준수 데드라인에 맞춰 진행 유예기간(18개월) 존재
- 2018년 9월 7일 영국 OBIE(open banking implementation entity)는 API 표준요건을 담은 오픈뱅킹스탠다드3.0(open banking standard 3.0)을 발표하였으며 핵심 구성요소는 기술사양, 보안, 고객 지침, 적합성 및 인증으로 이루어져 있다. 이 중 기술 ISO 20022와 같은 기술표준을 준용하여 RESTFul API를 설계원칙으로 제시하였으며 계좌 및 거래, 지급 개시, 자금 확인, 알림과 같이 각 분야별 기준을 마련하였다.
- 호주
- 2018년 2월 호주 재무부는 오픈뱅킹 구현에 관한 권고안 「Review into Open Banking in Australia」에 따라 오픈뱅킹을 추진하기로 했다. 이에 따라 호주 경쟁당국인 ACCC(The Australian Competition and Consumer Commission)는 ‘소비자정보권(the Consumer Data Right)’의 개념을 도입하고 대상이 되는 섹터를 결정하며, 연방종합연구소인 CSIRO에서는 데이터 표준을 정하기로 했다. 향후 예상되는 주요 추진일정은 다음과 같다.
- 2020년 07월 01일 : 4대 은행 신용카드 및 직불카드, 예금 및 계좌 정보 공유 시행
- 2020년 02월 01일 : 4대 은행 모기지 계좌 정보 공유 시행
- 2020년 07월 01일 : 4대 은행은 패럴리뷰에 담긴 전체 은행 상품에 대해 정보 공유를 시행
- 나머지 호주 은행들의 경우 4대 은행과 12개월 시차를 두고 시행한다. 호주의 오픈뱅킹은 경쟁법을 개정하는 방식으로 법제화를 진행하고 있다. 또한 패럴리뷰에서는 데이터 이전과 관련하여, 재정된 표준에 부합하는 API 사용을 권고하고 있다. 호주정부는 소비자정보권을 우선 은행산업에 적용하기 위해 오픈뱅킹 정책을 추진하고 있으며, 이러한 권리를 에너지, 통신 분야로도 확대해 나갈 계획이다.
해외은행
- 빌바오 비스카야 아르헨타리아 은행(BBVA)
- 빌바오 비스카야 아르헨타리아 은행은 개발자, 제휴사와 1년여의 준비기간을 거쳐 2017년 5월 API 마켓을 시장에 공개, 8종(사용자정보, 계좌, 카드, 지급, 대출, 알림 등)의 API를 출시했다. 빌바오 비스카야 아르헨타리아 은행 API 마켓은 현재 스페인, 미국, 멕시코 3개국에 서비스 중이며 실제 데이터에 대한 접근권한 수준에 따라 테스트 버전과 풀 버전 두 가지를 제공하고 있다. 특징적인 것은 API 이용자는 고객의 사회·경제 관련 정보(예상 가구 소득, 대출 한계 등)를 제공받아 맞춤형 서비스 개발이 가능하다는 것이다.
- 빌바오 비스카야 아르헨타리아 은행 카드와 빌바오 비스카야 아르헨타리아 은행 포스 단말기 거래내역으로 익명 수집된 통계데이터와 이를 토대로 소비 패턴, 인구 통계 등을 분석하여 가상지도를 제공하고 있다. 2017년 6월부터 빌바오 비스카야 아르헨타리아 은행는 알리페이의 자회사인 앤트파이낸셜(Ant Financial)과 제휴를 맺어 중국관광객이 스페인 내에서 알리페이를 자유롭게 사용할 수 있도록 서비스를 제공하고 있다.
- 피도르은행(Fidor Bank)
- 피도르은행은 2009년 독일에서 설립된 인터넷전문은행으로 고객이 참여하여 빠른 은행업무 및 지급서비스가 이뤄질 수 있는 자체플랫폼 피도르OS(Fidor OS)를 설계하고 전체 프로세스를 통합·제어할 수 있는 시스템을 구축했다.
- 씨티그룹(Citigroup)
- 씨티그룹은 2016년 11월 시티 개발자 포털(Citi developer portal)을 개설하여 계좌관리, 지급, 송금, 인증 등의 기능을 제공하고 있으며, 금융 및 핀테크사와 제휴해왔다. 씨티API는 샌드박스 및 테스트용 데이터가 제공되며 실제 서비스 출시를 원하는 이용자는 테스트 완료 후에 시티에 서비스제휴 제안이 가능하다.
- 씨티그룹은 호주 항공사인 콴타스 에어라인(Qantas Airline)과 제휴하여 신용카드를 출시하고, 계좌, 카드, 인증, 이체 등 70여개 API를 활용한 콴타스머니 애플리케이션을 제공하고 있다. 회게, 자산관리 등 금융전문 소프트웨어 개발사인 인튜이트(Intuit)는 고객에게 금융관련 데이터 제공방식을 개선하기 위해 씨티뱅크의 인증 API, 계좌조회 API를 활용하고 있다. 그 밖에 홍콩 시티은행은 2018년 5월 홍콩의 6개 기업과 제휴를 맺어 API를 통해 서비스를 제공할 것을 발표했다.
- 예스은행(Yes Bank)
- 2004년 설립된 인도의 예스은행은 은행의 역할을 고객의 금융관련 니즈를 충족하는 전략적 지원자로 설정하고, 금융서비스에 새로운 기술의 접목을 시도해왔다. 특히 인도계 은행 최초로 은행시스템과 고객사의 ERP시스템을 직접 연결하여 금융서비스를 제공하고 있다. 한편 2017년 1월에는 핀테크 엑셀러레이터인 예스핀테크(Yes Fintech)를 설치하여 핀테크사를 대상으로 혁신 금융서비스를 모집하였고, 우수기업을 지원하고 있다.
- 예스은행은 온라인 여행사 아크바(Akbar)의 ERP와 연계하여 거래내역 추적, 자동인증 등의 기능을 제공하고 있다. 대형금융사의 담보대출서비스에 예스은행 API를 접목하여 결제, 승인, 알림 등의 기능을 개발했으며, 대출금 지급 서비스도 개선하였다. 온라인쇼핑몰의 느린 환불 처리과정을 해결하기 위해 환불계정과 환불신청프로세스를 연결하고, API 호출을 통해 환불 신청 및 승인, 실시간으로 지급 처리하기도 한다.
- 미즈호은행(Mizuho Bank)
- 일본의 대형 금융사인 미즈호그룹(Mizuho Financial Group)은 디지털 환경 변화에 대응하기 위해 디지털 전환을 추진하고 있다. 미즈호 은행은 고객중심주의를 바탕으로 핀테크와 공동으로 서비스를 제공하는 모델을 추구한다. 2017년 6월 IBM API와 연계하여 IBM 클라우드 및 데이터파워게이트웨이(data power gateway)를 활용한 사물인터넷 결제 서비스 계획을 발표하였다.
평가
국내외 사례를 통해 보면, 은행에서 API를 구현하는 유형으로는 크게 내부연계형과 외부연계형으로 구분할 수 있다. 내부연계형의 경우 국내에서는 시한금융그룹의 ‘신나는 한판’, KB금융그룹의 ‘리브(Live)’ 등 관계회사 금융서비스를 그룹 통합 모바일 플랫폼에서 제공하기 위해 API를 활용하는 사례를 들 수 있다. 한편 최근 외부파트너와의 협력을 위한 생태계의 일부로서 외부연계형 API를 사용하는 케이스가 늘어나고 있다. 그러나 불특정 다수를 대상으로 앱 개발 플랫폼을 전면 개방하는 퍼블릭 API 모델은 국내 은행권에는 아직 없는 것으로 판단된다.
이에 따라 향후 국내은행은 오픈뱅킹 관련 전략을 수립·집행함에 있어 몇가지 점들을 고려하여 추진할 필요가 있다. 첫째, 국내에 마이데이터산업 도입 시 고객정보 제공을 위한 API의 구축이 요망되므로, 이와 관련된 API를 우선적으로 구축해야 할 것이다. 둘째, 이러한 규제적 동기 이외에도 자체 혁신을 위해서도 오픈뱅킹 활용은 유용하므로, 차제에 각행은 오픈 플랫폼 구축을 위한 장단기 로드맵을 수립할 필요가 있다. 셋째, API 개방을 확대해나감에 따라 예상되는 내부적 부작용을 최소화할 수 있도록 방안을 미리 마련할 필요가 있다. 넷째, 오픈뱅킹 전략의 성공은 결국 비즈니스 모델에 의해 판가름 나기 때문에 참신한 아이디어들이 지속적으로 제시될 수 있는 호나경을 조성하는 것이 중요하다. 마지막으로 외부에서 API를 활용하는 데 제약이 없도록 감독 당국과의 협의를 통해 규제 측면의 불확실성을 사전에 제거해 나가야 한다.
요컨데, 국내외 규제환경 변화 등을 감안할 때, 국내 은행사업이 오픈 이노베이션 환경 변화에 적절히 대응하지 못한다면 고객과의 접점을 잃고 계좌관리나 금융상품 제조자의 역할에 머물 수 밖에 없을 것이다. 따라서 국내은행은 오픈뱅킹 등 인프라 투자와 이를 적극 활용할 수 있는 인적 투자를 통해 외부의 혁신 모멘텀을 지속적으로 흡수할 수 있도록 해야 할 것이다.
각주
참고자료
같이 보기