을의 Digital Finance 블로그(16)
금융기관의 Eco(API, BaaS) 신기술 전략방향
ABCDE 디지털 신기술 중 생태계에 미치는 영향이 큰 기술 중 하나가 Eco(API, BaaS) 영역이다. 금융기관내에 이미 만들어 놓은 정보와 기능을 재사용한다는 점에서 IT측면에서 효과적이지만, 새로운 협업과 비즈니스 모델의 확장을 가능하게 한다는 점에서 비즈니스 측면에서도 흥미로운 영역이다. API를 이용하여 금융기관이 자체 보유한 비즈니스 자산(상품, 정보, 서비스)을, 이커머스와 같은 다양한 파트너의 디지털 애플리케이션(모바일, 웹)을 통해 최종 고객에게 제공할 수 있게 한다. 본질적으로 금융기관이 상대방 파트너에게 제공하는 비즈니스 자산이 가치가 없다면, API, BaaS는 성공하지 못한다. 확대되는 디지털 경제에서 API는 기업을 연결하는 접착제 역할을 하며, API를 통해 새로운 밸류체인을 제공할 수 있는 가치있는 전략적인 기회를 발견할 수 있게 해 준다.
API (Application Programming Interface)는 디지털 신기술이라고는 할 수 없지만, 클라우드와 오픈환경으로 변화하면서 더욱 주목받게 되었다. 과거에는 금융기관과 기업을 연결하려면, 보안이 보장되는 X.25와 같은 특수한 전용 네트워크 프로토콜을 사용해야 했다. 또 금융기관 시스템도 폐쇄적인 메인프레임을 사용하고 있어서 외부의 TCP/IP통신을 내부적으로는 SNA 통신으로 변환해야 했다. 이제는 금융기관과 기업의 모든 시스템들이 오픈 환경, 클라우드 환경으로 급격히 변화해 가면서, 상호 연결이 보다 용이해져가고 있다. 최근에는 Cloud Native 기술이 확산되면서, 기존 폐쇄환경의 레거시 Application이 마이크로서비스와 이를 연계하는 API로 현대화되어 가는 추세이다. 이러한 변화를 통해 기존 API가 BaaS형 API로 전환되면서, 기업 간의 연계를 더욱 쉽게 한다. 물론 외부 web site에서 데이터를 읽어 불러오는 방식으로 Screen Scraping 방식이 아직도 활용되고 있기는 하다. 하지만 web site 화면의 좌표를 읽어오는 방식이어서, 해당 web site가 변경되면 이에 맞추어 읽어오는 프로그램도 변경해주어야 해서 서비스 안정성이 떨어지고 보안성도 취약하다. 그리고 상호 간에 데이터를 주고받지도 못하고, 파트너에 제대로 된 BaaS를 제공해 줄 수 도 없다.
우리나라 금융기관들도 Open API포탈 등을 통해, 조회, 입금, 지급 등 각종 수백 개의 API를 외부에 오픈하고 있다. 주로 핀테크 회사나 기업들이 해당 금융기관의 Open API를 활용할 수 있도록 지원하고 있다. 국내에서는 특히 정부주도하에 오픈뱅킹, 마이데이터 등 제도적으로 API를 표준화하여, 타 금융기관, 핀테크, 빅테크 등 외부 마이데이터 사업자들에 제공하게 하고 있다. 다른 어떤 나라보다도 제도적인 측면에서는 빠르다고 볼 수 있다. 제도 정비와 실행을 정부, 규제기관 중심으로 진행하다 보니, 부작용도 적지 않았지만 속도 측면에서는 탁월했다고 생각한다. 아직 오픈뱅킹, 마이데이터를 이용한 킬러 서비스가 나오지는 않았지만, 오픈 API를 통한 공통의 기초는 든든하게 다져졌다고 보인다.
반면에 글로벌 금융기관들은 핀테크, 유통업체 등과 제휴하여 다양한 임베디드 뱅킹, BaaS(서비스형 뱅킹)를 제공하고 있다고 보인다. 유통업체 플랫폼을 통해 결제서비스, 대출서비스를 제공해 주거나, 나아가 개인 대상 또는 공급망 기업대상으로 BNPL(Buy Now Pay Later) 서비스를 제공하는 등 다양한 사례들이 있다.
국내에도 BaaS를 통해 새로운 고객경험과 서비스를 제공하는 사례가 많이 등장할 것으로 생각된다. 새로운 서비스와 비즈니스 모델은 결국 정부, 규제기관 주도가 아닌 금융기관과 기업 간의 협업에서 탄생한다는 측면에서 보다 활발한 협업 논의를 기대해 본다. 개인적으로 e-business가 시작된 2000년대부터 국내 대기업들 간의 협업은 속도가 잘 나지 않았다. 새로운 비즈니스 모델에 대한 상상력 부족, 상생과 협업을 지향하는 상호 win-win 협상안 도출의 어려움, 대기업 특유의 보고과 관리 문화로 인한 의사결정 지연 등 여러 가지 이유가 있었다고 생각된다. 마이데이터 등 API경제를 위한 기반이 마련된 만큼, 금융기관과 기업 간에 더 많은 파트너십이 체결되고 새롭고 다양한 혁신 금융 사례가 많이 나오기를 기대해 본다.
국내 은행들은 기존에도 기업대상으로 CMS(Cash Management Service), 공급망 금융등을 제공해 주고 있었으나, 새로운 방식의 BaaS 모델을 적용하기 위해서는 금융기관과 파트너사간에 보다 많은 협의가 필요하다. 여기서 BaaS를 위한 구체적인 추진과제로, A은행과 B유통사간의 진행된 전형적인 사업자대출 서비스 추진 사례를 살펴보고자 한다. B유통사의 강력한 디지털 플랫폼을 통해, (개인)사업자가 각종 다양한 상품을 개인고객에게 판매하고 있는 상황을 상정해 보자. B유통사는 (개인) 사업자의 기본정보뿐만이 아니라, 온라인상의 최신 판매정보를 보유하고 있어 정확한 신용평가시스템(Credit Scoring System)을 위한 가치있는 정보들를 보유하고 있다. A은행과 B유통사는 협의를 통해, 새로운 CSS를 구축하고 (개인) 사업자가 상시 사용하는 B유통사의 디지털 플랫폼을 통해 한도와 금리면에서 매력적인 사업자 대출을 출시하기로 논의를 시작했다. 협의 과정에서는 기술적인 시스템 구현 이슈 보다도 , 상호 간에 협의해야 할 비즈니스 모델 이슈, 고객정보 보호 이슈, CSS 모델 이슈, 금융상품 판매를 위한 규제 이슈 등 많은 이슈들이 도출된다. 무엇보다 (개인) 사업자는 개인으로 취급되어 개인정보를 활용하려면 고객정보 동의를 받아야 한다. B유통사와 (개인) 사업자 간의 동의는 이미 존재하지만, A은행이 (개인) 사업자 정보를 활용하려면 추가적인 동의가 필요한 상황이 된다. 이상적으로는 (개인) 사업자의 정보활용동의를 추가적으로 받고, 이 정보를 A은행의 기존 CSS시스템에 활용하여 보다 정교한 신용평가를 진행하는 것이 바람직해 보인다. 이 경우 (개인) 사업자는 이 대출상품을 A은행의 사업자 대출상품으로 인식하고, 연체 등 부실이 발생할 경우 A은행이 전적으로 책임지는 구조가 된다. B유통사 디지털 플랫폼은 판매채널로 활용되는데 규제기관으로 부터 "금융상품판매 중개대리인"으로 인정받아야 한다. 그러나 현실적으로는 고객동의를 추가적으로 받는 것도 어렵고, B유통사가 향후 공급망 금융 등 Fintech 업무로도 진출하려는 의도가 있어 협의는 쉽지 않았다. B유통사 자체 정보를 기준으로 자체 CSS을 구축하고, A은행이 산정한 CSS모델과 비교하여 대출을 진행하는 방안도 상정되었었다. 이와 같이 실제 BaaS 모델을 구현하는 데 정말 많은 복잡한 요소를 고려해야 한다.
이하에서는 이러한 BaaS(서비스형 뱅킹)을 통한 비즈니스 모델 변화를 기획할 때 우선적으로 고려할 사항에 대해서 고민해 보고자 한다.
첫째, 금융기관 자체적으로 어떤 고객에게 어떤 서비스를, 어떤 파트너 플랫폼을 통해 제공할 것인가에 대해서 명확히 해야 한다. 금융기관은 유통 등 비금융회사의 새로운 디지털 채널을 통해, 새로운 고객을 확보하거나 기존 고객에게 차별화된 서비스를 제공할 수 있다. 무엇보다 최종 고객, 최종 사용자의 시각에서 어떤 새로운 고객경험과 서비스를 제공할 수 있는지 살펴봐야 한다. 유통회사를 파트너를 고려할 경우, 유통회사 디지털 플랫폼의 최종 개인고객과 (개인) 사업자에게 어떤 금융 서비스를 제공할 수 있을까가 핵심이 된다. 예를 들어 자금과 대출수요가 있는 (개인) 사업자를 대상으로 한도와 금리 측면에서도 매력적이고, 실시간 유통정보를 활용하여 대출 사후관리도 효과적으로 진행할 수 있을 것이다. 어떤 파트너를 대상으로 할 것인가는 중요한 주제가 된다. Fintech회사인지, 온라인 쇼핑몰과 같은 회사인지 파트너 Profile을 조사하고 리스트업 하여 우선순위를 정의한다. 어떤 서비스를 대상으로 할 것인지도 중요한 주제이다. 결제, 대출, WM(Wealth Management), 투자정보제공, 운영 등 어떤 Financial Category의 서비스를 제공할 수 있을지 고민해 봐야 한다.
예를 들어 국내 모 중소 보험회사의 경우, Insurtech 회사의 디지털 채널에 보험사의 약관대출신청 서비스를 탑재하여, 약관대출 증대 효과를 보기도 하였다. 중소 보험사인 관계로 자체 모바일 채널의 MAU가 적었고, Insurtech의 디지털 플랫폼이 보유한 고객들에게 쉽게 접근하여, 대출수요를 파악하고 자사 약관대출로 유도할 수 있었다. 서로 Win-win 효과를 거두었다고 보여진다.
둘째, 상대방 파트너 입장에서, 무엇을 주고받을 것인지 분명히 해야 한다. 기술적으로 주고받는 것은, API를 통해 데이터와 기능을 주고받는 것에 불과하다. 중요한 것은 비즈니스 적으로 주고받을 사항과 상호역할 분담이 분명해야 한다. 고객정보는 누가 책임질 것인지, 누가 고객경험을 주관할 것인지 등 명확히 해야 할 사항이 많다. 누가 고객경험을 주도하고 책임질 것인가에 따라서, 디지털 플랫폼을 소유한 기업은 통상 자체의 UI/UX 원칙이 있고 이를 일관성 있게 적용하려고 한다. 하지만 개발자가 부족한 파트너의 경우에는, 신속한 전개를 위해 화면 API방식으로 전달받기를 원할 수 있다.
셋째, API를 제공하는 것은 IT 부서만의 문제가 아니다. API는 금융기관 비즈니스를 확장할 수 있는 전략을 개발할 수 있게 해 주며, 고객 중심 전략을 외부 파트너로 확장하여 실행할 수 있게 해 준다. 비즈니스 조직과 IT가 API를 잘 정의하면, 금융기관 IT시스템의 복잡성과 내부조직의 복잡성을 노출시키지 않으면서 파트너와 협업할 수 있는 기반을 마련할 수 있다.
BaaS를 구현하고 운영하는 과정에서 추가적으로 고려할 사항들은 다음과 같다.
첫째, 최종적으로 파트너사가 제공하는 서비스의 품질과 안정성에 대해서도 깊이 고민해야한다. 파트너가 얼마나 신뢰할 만 한지, 파트너가 얼마나 IT역량을 보유하고 있는지 등을 잘 살펴봐야 한다. 파트너가 제공하는 서비스에 품질 문제가 발생할 경우, 사용자는 파트너가 아닌 금융기관에 컴플레인할 수 도 있다. 파트너의 IT 역량이 부족할 경우, 보안위협에 대한 적절한 대웅, API 구현과 안정적인 운영에도 영향을 미치게 된다. 서비스 품질과 안정성에도 문제가 발생할 수 있는데, 이에 대한 대비책 또한 필요하다. 예를 들면 구글도 API를 제공하지만, 제공하는 API를 변경할 경우 미리 공지해 준다. 상용인 경우에는 이메일로 담당자에게 공지를 해 주기도 하지만, 종종 사용하는 측에서 구글 공지를 인지하지 못하는 경우도 발생하고, 이에 따라 갑작스러운 서비스 중단이 발생할 수 있다. 중요한 것은 금융기관과 파트너 상호 간의 긴밀한 협업이다.
둘째, 제공하는 서비스에 따라서 규제기관의 승인을 받아야 하는 경우도 많다. 비금융 디지털 플랫폼에 대출상품을 탑재할 경우, "금융상품 판매중개 대리인"으로 보고 사전에 상당한 승인 절차를 밟아야 하는 경우도 있다. 앞서의 예에서 B유통사 플랫폼상에서 (개인) 사업자가 대출서비스를 받기 위해 우선 해당 금융기관에 계좌를 개설해야 할 경우, 계좌개설은 은행고유의 업무로 정의되어 있다. 이 경우 계좌개설, 상품가입 전에는 API로 서로 커뮤니케이션하면 되지만, 특정 시점부터는 은행 업무처리로 정의되어 시작되어야 한다. 규제관점에서 프로세스를 설계하고, 운영하는 데 세심한 주의를 기울여야 한다.
셋째, 처음부터 Open API 즉 Public API를 제공할 필요는 없다. 금융기관 내부용도의 Internal API도 있고, 보안 이슈를 고려할 때 제한적인 파트너에게만 제공하는 Partner API를 제공하는 것에 우선 순위를 두는 것도 바람직하다. Open API의 경우 API포탈등을 통해 API를 잘 알리는 방법도 고민해봐야 한다. 현실적으로 대고객 신뢰를 중요시하는 금융기관은 대부분 파트너 API 방식을 고려할 수 밖에 없고, 불특정 다수를 대상으로 하는 API 포탈이 그렇게 효과적인 것은 아닐 수도 있다, 하지만 API 포탈을 통해 홍보 효과도 거둘 수 있고, API포탈을 통해 소규모 핀테크 회사들에게 개발자 환경과 플랫폼을 제공해 줄 수도 있을 것이다.
넷째, 마지막 기술적인 측면에서 API 추진과제는 금융기관 내부 시스템의 아키택쳐를 한 단계 더 발전시키는 지속적으로 수행해야 하는 작업으로도 이해해야 한다. 금융기관 내부의 API를 BaaS형 API로 지속적으로 변환해 가는 과정을 통해, 금융기관 시스템을 더 유연한 시스템, 더 고객 중심적인 시스템으로 고도화할 수 있다. 이를 위해서는 파트너들과 고객들과 개발자들에게 더 귀를 기울여야 한다. 추진방법 또한 일회성 SI프로젝트로 진행하는 것이 아니라, 중장기적인 관점에서 API GW 내재화 과제도 검토하며, 이를 추진하기 위한 충분한 내부개발인력도 준비해 가야 한다.
