서비스형뱅킹 (Banking as a Service (BaaS))
쉽게 풀면
은행 면허가 없는 일반 기업도 인가받은 은행의 시스템을 빌려서 자기 이름을 건 은행 서비스를 만들 수 있게 해주는 구조다. 뒤에서는 진짜 은행이 인프라를 제공하고 있는 것이다.
왜 중요한가
항공사나 유통기업이 은행업 인가 없이도 자체 브랜드의 카드나 계좌 상품을 출시할 수 있게 해주는 사업모델로, 임베디드 파이낸스 확산의 핵심 기반으로 최근 핀테크 산업구조 변화를 설명하는 데 활용됩니다. 감독당국은 최근 후원은행이 다수의 BaaS 제휴사를 동시에 관리하며 개별 제휴사에 대한 실사와 감시 소홀 문제가 반복되자, 후원은행의 제휴사 관리 책임을 강화하는 방향으로 규제를 정비하고 있다.
핵심 정리
- 서비스형뱅킹(BaaS)은 은행업 인가를 가진 은행이 예금계좌, 대출, 카드 같은 상품을 비은행 파트너(대개 핀테크나 일반 기업)를 통해 고객에게 제공하게 하는 구조입니다.
- 참여자는 보통 셋으로 그려집니다. (1) 인가를 가지고 자본·유동성·신용 위험을 관리하는 은행, (2) 자기 앱과 브랜드로 고객을 만나고 API로 은행 시스템에 접속하는 파트너, (3) 둘 사이를 잇는 미들웨어 사업자입니다. 미들웨어를 따로 두는 3층 모형은 Chris Skinner가 제시한 것으로 소개됩니다.
- 고객 접점은 파트너가 맡고, 규제 책임은 인가받은 은행에 남습니다. 미국에서는 은행이 제3자 파트너의 법규 준수, 소비자 보호, 자금세탁방지를 감독할 책임을 집니다.
- 2024년 4월 미들웨어 사업자 Synapse가 파산 보호를 신청하면서 여러 BaaS 플랫폼의 서비스가 중단되고 이용자 자금 손실 문제가 생겼고, 기록 관리와 파트너 감독을 더 엄격히 보자는 논의로 이어졌습니다.
예시로 보기
가상의 사례입니다. 한 항공사가 자사 마일리지와 연동된 체크카드 계좌를 내놓고 싶지만 은행업 인가는 없습니다.
- 항공사는 인가받은 은행과 제휴하고, 필요하면 미들웨어를 통해 계좌 개설·결제 기능을 API로 연결합니다.
- 고객은 항공사 앱에서 계좌를 열고 카드를 받습니다. 겉으로는 항공사 서비스입니다.
- 그러나 예금은 제휴 은행의 장부에 있고 인가와 감독 책임도 은행에 있습니다. 문제가 생기면 항공사, 미들웨어, 은행 사이에 책임이 갈리므로 계약 구조가 중요해집니다.
배경이 되는 핀테크 문헌으로는 핀테크를 개관한 Puschmann(2017), 핀테크 스타트업의 혁신 메커니즘을 다룬 Gozman 외(2018), 은행과 핀테크의 개방형 은행업 접근을 다룬 Omarini(2018)가 있습니다.
자주 하는 오해
| 오해 | 바로잡기 |
|---|---|
| BaaS를 쓰면 핀테크가 은행이 된다. | 핀테크는 브랜드와 고객 경험을 맡을 뿐, 인가와 최종 규제 책임은 은행에 남습니다. |
| 단순한 시스템 위탁(아웃소싱)과 같다. | 시스템을 맡기는 것에 그치지 않고 금융 상품 제공의 법적 주체와 고객 접점이 분리됩니다. |
| BaaS는 규제 부담이 없는 우회로다. | 미국에서는 은행이 파트너를 감독할 책임을 지고, 감독당국이 관련 지침과 제재를 내놓았습니다. 파트너가 많을수록 은행의 관리 부담도 커집니다. |
| 미들웨어는 필수 구성이다. | 미들웨어를 두는 모형이 소개되지만, 은행이 파트너와 직접 API로 연결하는 구조도 설명됩니다. 사례마다 구조를 확인해야 합니다. |
논문에서는 이렇게 쓰입니다
실제 논문에서
이 용어를 직접 쓴 국내 논문 문장을 아직 수집하지 못했습니다. 수집되는 대로 출처와 함께 싣겠습니다.
예시 문장
아래는 용어의 쓰임을 보여 주려고 만든 예시로, 실제 논문에서 가져온 문장이 아닙니다.
푸쉬만은 은행이 자신의 규제 라이선스와 인프라를 서비스 형태로 제공하는 새로운 사업모델이 등장한 배경을 정리하며, 이것이 은행업의 가치사슬을 라이선스 제공자와 고객 접점 제공자로 분리시키는 구조 변화의 핵심임을 설명했다.
서비스형뱅킹은 규제된 은행의 라이선스와 인프라를 API로 개방함으로써, 비금융기업이 자체 은행업 인가 없이 금융서비스를 자사 브랜드로 제공할 수 있게 한다.
조금 더 깊게 보면
BaaS는 비금융기업에 금융기능을 개방하지만 실제 규제책임과 라이선스는 여전히 제휴은행에 있으므로, 최종 이용자 보호나 리스크 관리의 책임소재가 복잡해질 수 있다는 점이 감독당국의 주요 관심사입니다. BaaS 구조에서는 브랜드를 내세우는 비금융기업, 실제 인가를 보유한 후원은행, 결제망 연동을 담당하는 미들웨어 사업자까지 최소 세 층의 참여자가 관여하는 경우가 많아, 사고 발생 시 책임 소재를 가리기 위한 계약 구조가 특히 중요하다.
주의할 점
단순한 시스템 위탁이나 아웃소싱과는 다르며, 서비스형뱅킹은 규제상 최종 책임과 금융 라이선스가 여전히 인가받은 은행에 남아 있는 상태에서 브랜드와 고객 경험만 제3자에게 위임하는 구조라는 규제상의 구분이 중요하다.
헷갈리기 쉬운 용어
비슷한 맥락에서 함께 쓰이는 용어입니다.
| 용어 | 한 줄 설명 |
|---|---|
| 서비스형뱅킹 | 은행이 인가와 인프라를 비은행 파트너가 쓰도록 여는 구조 |
| API뱅킹 | 은행 기능을 API로 외부에 개방하는 방식 |
| 임베디드파이낸스 | 비금융 서비스 안에 금융 기능이 내장되는 현상 |
| 네오뱅크 | 디지털 채널 중심으로 운영되는 신생 은행 서비스 |
참고 문헌
- Puschmann, T. (2017). Fintech. Business & Information Systems Engineering, 59(1), 69–76.
- Gozman, D., Liebenau, J., & Mangan, J. (2018). The innovation mechanisms of fintech start-ups: Insights from SWIFT's Innotribe competition. Journal of Management Information Systems, 35(1), 145–179.
- Omarini, A. E. (2018). Banks and fintechs: How to develop a digital open banking approach for the bank's future. International Business Research, 11(9).
표의 기준값은 위 문헌에 근거한 관례이며, 분야·학술지마다 다른 기준을 쓸 수 있습니다.