[금융 IT] 보험사 IT 시스템

junghan·2023년 10월 9일
1

금융IT의 모든 것

목록 보기
1/1
post-thumbnail

보험사 IT 시스템은 금융 IT 회사 내에서 독특한 특징과 업무 흐름을 가지고 있으며, 각 계와 도메인 별로 다양한 구조와 기능을 제공합니다. 이 블로그에서는 보험사 IT 시스템의 주요 특징, 업무 흐름, 구조, 각 계 및 도메인 별 상세 설명을 다루겠습니다.

금융 IT 시스템 구조

먼저 기본적인 금융 IT 시스템의 틀을 우선적으로 살펴보려합니다.


계정계 (Core Banking)

고객의 거래 데이터를 처리하는 핵심 시스템

우리는 은행에서 거래할 때, 통장 정보를 필수로 입력해야 합니다.

이처럼 거래의 핵심요소인 통장을 계좌, 계정이라고도 부르는데 이러한 계정을 관리하는 시스템을 모아 '계정계' 라고 합니다.

한 사람 당 여러 계좌를 갖고 있기도 하고, 돌아가신 분의 계좌가 있을 수도 있고, 각 계좌의 거래 데이터도 여러 건이 될테니 그 데이터량은 1억 건도 가뿐히 넘는다고 합니다.

개인/법인/기타 고객의 통장 정보를 가지는 입금·출금·계좌이체·신규 개설 및 폐쇄 등의 전반적인 핵심업무가 계정계에 해당됩니다.

→ 계정계 시스템 : 공통, 수신, 여신, 신탁, 보험, 카드, 외환, 대행업무 등으로 구성

한 눈에 봐도 매우 중요한 시스템으로 보이는데, 이런 계정계에 장애가 생기면 바로 금전적 손실로 이어지기 때문에 매우 보수적으로 운영됩니다.

초기에는 IBM Mainframe을 주로 사용했는데, 2000년대로 들어오면서 대부분의 은행권이 Unix 환경으로 이어졌다고 합니다.

요약하자면, 계정계는 금융 제품과 서비스를 관리하고 금융 거래의 정확성과 신속성을 보장하는 역할을 하기 때문에 대규모 트랜잭션 처리와 높은 가용성을 요구하며, 데이터 보안도 매우 중요하게 처리해야 합니다.


정보계

거래의 기록을 관리하고 통계 처리하는 시스템

계정계에서 얻은 데이터를 바탕으로 거래 활동 및 성과를 측정하고 분석하는 업무를 처리합니다.

기업의 경영지표나 소비자 분석, 정보 연계 등을 목적으로 쓰이기 때문에 계정계만큼 필수적인 시스템이고, 데이터에 접근하는 속도가 중요시됩니다.

DW(Data Warehouse)를 기반으로 하는 수익 관리·고객관계관리·성과관리·위험관리 등의 시스템이 있습니다.

계정계가 외부 고객과 접점이 깊은 시스템이면, 정보계는 내부 현업과 접점이 깊다고 느껴집니다.

요약하자면, 비즈니스 인텔리전스(Business Intelligence) 및 데이터 웨어하우스와 연계하여 의사 결정에 필요한 데이터를 분석하고 제공합니다.


대외계

각 금융기관의 대내외 망을 연결하는 시스템

은행 외부기관과의 연계업무를 위해 구축하는 시스템으로,은행 공동망, 제휴 기관, 금융 결제원 등 각종 대외 기관과의 연결 프로토콜을 관리합니다.

예를 들어, 은행에서 외부 보험상품을 판매하기 위해서는 해당 보험사와 실시간 정보 공유를 해야 하지만 보안을 이유로 내부 시스템과 직접 통신이 아닌 대외계 시스템을 거쳐 주고받는 프로세스라고 보면 됩니다.

요약하자면, 외부 업체 및 금융 기관과 연결되는 시스템으로 네트워크(프로토콜) 통신을 중점으로 안정성과 정확성을 민감하게 처리하여 신뢰성 있는 데이터 교환을 보장해야 합니다.


채널계

대외계 시스템 및 다양한 비대면 채널들을 관리하는 시스템

End User (사용자)가 접속하는 다양한 채널의 데이터를 관리하는 시스템입니다.

어렵게 설명했는데 그냥 모바일 뱅킹, 인터넷 뱅킹, ATM 기기, 현업의 단말기 데이터 등 고객이 은행 거래를 위해 접근하는 수단을 채널이라고 이해하면 됩니다.

채널이 다양해지면서 채널계의 중요도도 높아졌다고 합니다.

고객이 거래 관련된 내용으로 문의하는 콜센터도 채널계에 속하고, 흔히 정보를 받기 위한 목적으로 접근하는 '카카오톡 채널'로도 비유를 들 수 있을 것 같습니다.

채널계의 주요과제는 멀티채널 관리와 사용자 경험 최적화입니다.


운영계

안정적인 서비스 운영을 위한 유지보수, 통합관제, 모니터링 등의 시스템

위의 설명한 시스템들이 올라간 서버를 기준으로 IT 인프라(H/W, S/W), 네트워크, 보안 영역을 운영하는 업무입니다.

해당 시스템들에 대해 주기적으로 점검해서 미리 예방하거나, 실시간 모니터링을 통해 시스템 장애 영향을 최소화 합니다.

즉 운영계는 IT 인프라와 시스템 관리에 중점을 둡니다.


기간계

기존에 사용하던 시스템

Legacy 시스템이라고도 하며, 고도화된 시점을 기준으로 구 시스템을 기간계라고 칭합니다.



보험사 IT 시스템 구조



신계약 가입설계 업무 프로세스

실 보험사의 전체적인 Process 호름은 더 세분화 되고 하나하나의 단계마다 보험회사 업무 영역별로 특유의 다양한 BIZ Domain이 존재한다고 합니다. 먼저 큰 흐름을 파악하는 것이 중요하므로 전체 Process를 정리하고 세부적인 부분은 추후 정리해보겠습니다. 해당 예제에서는 장기 보험 신계약을 대상으로 합니다.

보험 회사에서 설계사가 고객과 접촉하고 해당 고객으로부터 계약을 성립시키기까지 다양한 업무 영역이 관여가 됩니다. 위의 흐름에서 고객파트, 상품파트, 영업인사파트는 청약 업무와 관련은 있으나 상품을 제외하고 신계약 업무에 직접적으로 노출이 되지 않아 표시하지 않았습니다. 위의 장표를 토대로 세부설명을 할 것이지만 아래의 프로세스를 참고하면 고객과 회사의 관계에서 체결되는 계약에 대한 프로세스를 좀 더 자세하게 이해할 수 있습니다.

상품

보험회사 상품은 상품을 구성하는 다양한 항목이 존재하지만 그 중 조금 더 가장 중요하게 판단되는 항목은 목적물, 담보, 정보항목, 요율정보입니다.

  • 목적물(Insured/Object) : 목적물은 보험의 보장 대상이 되는 물건을 의미합니다. 일반적으로 생명보험의 경우 사람만이 대상이기 때문에 피보험자라 지칭하지만 화재의 경우 건물,주택등이 대상이 될 수 있기 때문에 목적물이라고 명칭합니다.

  • 담보 (Coverage): 보험의 보장 항목을 의미합니다. 보통 주계약 담보가 존재 하고 주계약 이외에 추가로 보장되는 항목이 추가됩니다. 담보는 담보당 보장기간,납입기간,가입금액,보험료등의 항목정보를 가집니다.

  • 정보 항목 : 설계 혹은 계약을 구성하는 정보값으로 계약 전체의 정보항목(납입기간,보장기간,납입방법등)이 있고 목적물의 정보 항목(피보험자 나이, 성별, 직업, 건물업종정보등)이 있다.

  • 요율(rate) : 보험료 산정의 기준이 되는 이율로 예정이율, 공시이율, 사업비율, 사망율등이 있어 상품별로 약관에 정의 되어 있다 (사업비의 경우 보험회사에서 공개하지 않음)


가입설계

상품이 출시가 되고 설계사들이 고객을 만나 판매를 시작하는 단계로 일반적으로 고객에 제공할 보장담보를 구성하고 보험료를 산출하여 고객에게 보장내역과 보험료등을 포함하는 가입설계서를 출력, 고객에게 제공하는 단계인데 연금과 일반 보험상품간에 보험료 산출에 차이가 있습니다. 연금의 경우 고객이 지급하는 보험료를 기준으로 연금 수급 기간에 받게 되는 보험금을 계산을 하게 되고 일반 보험 상품의 경우 고객이 보장을 받을 보험금에 대해 지급해야 하는 보험료를 계산하게 됩니다. (보험료(Premium) : 고객이 회사에 보장에 대한 댓가로 입금하는 금액, 보험금(Insurance) : 보험회사가 고객에게 보장으로 제공하는금액)

가입설계 수행의 주체는 일반적으로 설계사라고 하는 보험 판매사들이 고객과 접촉하기 전에 수행을 합니다. 최근 보험회사의 판매 사이트에서 고객이 직접 설계하는 경우도 있습니다. 자동차 보험이 대부분이며 일부 장기 상품도 판매되고 있습니다. 가입설계는 앞서 기술 했듯이 보험료를 산출하는 단계로 아래와 같은 순서로 진행합니다.

1. 상품의 선택

장기 보험의 경우 선택할 수 있는 목적물에 따라 인보험, 물보험이 있으며 인+물(목적물에 사람과 건물이 동시에 존재) 상품이 있습니다.

2. 계약 정보 입력 : 계약을 구성하는 전체 정보

  1. 상품 계약 기본 정보 : 납입기간, 보장기간, 계약 형태(개인형/부부형/단체형등)등
  2. 납입정보 : 납입방법(자동이체/방문수금등), 납입주기(월납/3월납/6월납/연납/일시납)등
  3. 기타 계약 정보

3. 목적물 선택 및 목적물 정보 입력

  1. 인보험 : 직업, 나이, 성별, 운전여부등으로 목적물의 직업에 따라 상해급수가 결정이 되어 나이, 성별과 함께 보험료가 달라집니다.

  2. 물보험 : 목적물 건물 유형(철근, 콘크리트, 초가집등 건물을 구성하는 건물 구조) , 건물업종(사무실,노래방,세탁소 등 건물에서 취급하는 업종 정보)등으로 건물의 구조, 취급업종에 따라 건물급수가 결정되어 보험료가 달라집니다.

4. 담보 선택 및 담보 정보 입력

  1. 인보험 : 목적물이 선택되면 담보를 선택 할 수 있습니다. 목적물의 성별,나이,직업에 따라 가입 가능한 담보가 제한이 되고 담보간에도 정합성이 존재합니다.

  2. 물보험 : 목적물 선택 후 담보의 선택은 인보험과 동일하나 물보험의 경우 담보에 따라 목적물 정보를 추가로 입력해야 하는 경우가 발생합니다. 대표적인 경우로 주차장 관련 담보를 추가 했을 경우 대상 목적물의 주차장과 관련된 정보를 추가로 입력해야 보험료 산출이 가능합니다.

5. 1회 보험료 입력 : 적립보험료가 없는 상품의 경우 1회 보험료를 입력하지 않는다.

  1. 1회 보험료 : 납입하고자 하는 보험료로 보장보험료를 제외한 금액은 적립보험료로 적립됩니다.
  2. 적용 보험료 : 할인이 적용된 (자동이체 할인, 선납할인등) 보험료로 실 입금하는 보험료
  3. 적립 보험료 : 보장보험료를 제외하고 만기 혹은 약관에 따라 환급받는 보험료
  4. 보장 보험료 : 담보의 순수 보장보험료 합계

6. 보험료 계산 수행

시스템 내부적으로 보험료 계산 수행 시 목적물 및 계약 기본 정보, 담보간의 관계등 계산 정합성을 수행하고 정합성이 통과되는 경우 설계 번호를 채번하고 설계를 저장합니다.


청약정보 입력

보험료가 산출되고 설계 번호가 채번되었을 경우 설계사는 보장사항, 산출된 보험료가 표시된 가입설계서를 출력하여 고객과 접촉합니다. 해당 설계가 계약으로 반영 되기 위해서 보험료 산출을 위한 정보 외에 목적물(인보험만 해당)에 대한 고지(알릴)사항 및 목적물의 상병 여부를 추가로 입력 받아야 합니다. 고지 및 상병 정보는 꼭 고객이 입력해야 하며 이 정보를 사실과 다르게 입력 했을 경우 보험 사고의 발생 여부와 관련없이 보험사는 계약을 해지 할 수 있습니다. 단 보험사가 고지의무 위반 사실을 알고 1개월내에 조치를 취하지 않았거나 2년이 경과한 계약은 계약을 해지 할 수 없습니다.

  • 고지(알릴)사항 : 보험사에서 목적물과 관련된 정보를 입력 받는것으로 운전여부, 건강상태, 흡연,음주여부, 위험취미 활동등을 입력받는다.

  • 상병이력 : 과거 질병 및 상해로 병원에서 진단 받은 이력 및 완치여부를 입력 받는다.

  • 계약자 추가 사항 : 보험료 산출 및 보장의 대상은 목적물이지만 보험계약의 성립주체는 계약자이므로 계약자와 관련된 계약자주소, 보험 수익자 정보, 환급계좌정보, 질권정보등을 입력 받는다.

  • 설계완료 : 고지 사항 및 상병 정보등 추가로 입력 받은 정보에 대한 정합성을 수행한다. 목적물의 고지 사항 및 상병 정보, 보장담보 정보를 기준으로 설계완료 정합성을 수행한다. 이 단계가 완료 되었을 경우 일단 보험 청약과 관련된 설계는 종료가 되며 이후 설계 정보와 해당 고객의 기존 보험 계약 정보를 바탕으로 설계 승인 여부를 심사하게 된다.



정리하며

모든 업종이 다 그렇겠지만 보험 SI의 경우 기본적인 업무 지식이 바탕이 된 상태가 아닌 경우 고객과의 업무 협의에서 동일한 Biz에 대해 고객이 의도하지 않은 엉뚱한 결과를 도출하기도 하며 특히 고객과의 의사소통에서 보험업무에 대한 기본 지식이 있는것과 없는것의 차이는 고객이 개발자를 대하는 태도에서 많이 차이가 있다고 합니다. 선배님들의 경험이 녹아든 블로그를 짜집기하며 보험사 IT 직무의 전체적인 프로세스에 대해 이해할 수 있었습니다. 다시 한번 감사드립니다.



출처:
https://smallrich.tistory.com/79
https://www.slideshare.net/ssuser1cbe1b/it-2-251010950
https://www.nextree.co.kr/p3736/

profile
42seoul, blockchain, web 3.0

0개의 댓글