이상금융거래 탐지 시스템(FDS)

2001년, 어떤 해커가 PayPal 계정에 침투하여 여러 계정에서 소액을 이체해가는 사건이 발생합니다. 이 사건을 맡은 FBI는 대대적인 수사에 착수했지만 큰 성과를 내지는 못했습니다. 이에 PayPal은 스스로를 지켜야겠다는 판단 하에 보안탐지시스템을 구축했고, FDS가 세상에 나타나게 되었습니다. 이미 FDS는 알게 모르게 우리의 실 생활에 많이 적용되어 있습니다. 아래의 사진은 FDS란 무엇인가를 알려주는 대표적인 사례라 할 수 있겠습니다.


 

이미지 출처 : 금융보안연구원 FDS 세미나 신한 카드사 발표 자료





핀테크, 빅데이터등 새로운 금융과 IT융합 시장이커짐에 따라 금융 보안의 패러다임이 변화하고 있습니다.  국내의 보안 규제 완화 및 간편결제 확대등 이용자의 편의성 위주로 결제 및 금융 환경이 변화하면서 과거의 이상금융 거래를 Front-End와 전송구간에서 차단하던 것과는 달리 이제는 Back-End 블럭에서 단말기정보·거래내용 등을 종합적으로 분석하고 탐지하여 차단하는 시스템이 필요하게 된것입니다.

 


 이미지 출처 : 금융보안연구원 FDS 기술가이드






국내에서 이루어지는 주요 금융 거래 절차 3단계 및 FDS 4가지 주요 기능은 다음과 같으며, 금융거래 절차 3단계(파랑)과 FDS 기능 4가지(빨강)이 금융 거래에 개입되어 상호 연동되는것이 중요 합니다.

 

 이미지 출처 : 금융보안연구원 FDS 기술가이드



FDS 4가지 주요 기능

 이용자의 정보 및 행위에 대한 정보수집

    이상금융거래 탐지의 정확성을 위해 이용자 매체환경정보’  사고 유형 정보를 수집


 분석 및 탐지 기능

    수집된 정보를 이용하여 이용자 유형별거래 유형별 다양한 상관관계 분석 및 규칙검사 등을 통해 이상 행위를 탐지


 대응기

    분석된 정보가 이상금융거래 행위에 해당하는 경우 거래 차단, 추가인증 등의  대응


 모니터링 및 감사기

    수집·분석·대응 등의 종합적인 절차를 통합하여 관리하는 모니터링 기능과 해당 탐지 시스템을 침해하는 다양한 유형에 대한 감사 기능



금융 거래 절차 3단계

① 이용자 인증

    이용자 인증 후 ‘정보 수집 기능’ 을 이용하여 이용자 매체환경 정보를 금융회사의 수집 시스템으로 전달


② 거래지시

    매 거래 시 수집된 정보와 금융회사에서 자체 보유하고 있는 다양한 정보(접속 및 금융거래 정보 등)를 ‘분석 및 탐지기능’을 이용하여       이상금융거래 유무를 분석


③ 거래확정

    앞서 분석된 결과를 바탕으로 ‘대응 및 모니터링 기능’ 을 통해 거래 승인 또는 취소 여부를 결정





금융보안연구원이 2015년 발표한 '금융보안 IT․보안 10대 이슈'의 5번째 항목인 '이상금융거래 탐지시스템 전 금융권 도입 확대 및 기술적 고도화'에 따라 국내의 FDS 도입은 선택이 아닌 필수가 되었으며 시스템 구축후 다양한 도입효과가 나타나고 있습니다.


① 신한카드

    카드 회원이 직접 설정한 결제 기준에 맞춰 해외 부정거래를 차단할 수 있는  셀프FDS’

    - 회원에게 미리 해외 출입국 정보신청 및 활용 동의를 받아 출입국 관리소 조회 후 확인 처리 서비스


② 유안타증권

    - 홈페이지의 게시판에 보이스 피싱을 당했으나 유안타증권의 FDS덕분에 금융사기 피해를 보지 않았다는 게시 글이 게재

    - FDS 운영 2년 만에 94회의 실제금융사고를 탐지하였으며피해방지 액은 17억 원 가량


③ 부산은행

    - 2016년 10월 17일 발생한 파밍 수법의 전자금융사기가 발생했고 A고객의 평소 거래와 다른 패턴을 실시간으로 탐지하고

      해당거래를 즉시 차단하여 5억 4천만 원의 금융사기로부터 보호

    - FDS의 적용범위를 기존인터넷뱅킹스마트뱅킹텔레뱅킹에서 ATM까지 확대하고 빅데이터 분석을 통해 10월 150건 이상 금융사기         피해 예방




저도 개발자이다 보니 FDS의 구현방법에 대해서도 조사를 하던 중 한장의 그림으로 가장 잘 표현한것 같은 이미지를 하나 첨부합니다. 아마 대부분의 FDS 시스템은 아래와 유사한 모습을 하고 있지 않을까 생각합니다.



 

이미지 출처 : Big Data – Banking’s New Weapon In War Against Financial Crime





비록 FDS를 통해 이미 많은 금융사기범죄가 예방이 되었지만 아직도 한계점은 있습니다. FDS 운영의 핵심은 탐지력 강화와 신속 대응이며 구축한 이후에도 지속적인 분석이 필요 합니다. 최근에 Machine Learning, Deep Learning 등의 발전으로 인해 많은 부분에서 자동화 처리가 가능하지만 사기의 수법 또한 갈수록 진화하고 있습니다. 이를 효율적으로 방어하기 위해서는 각 업계간의 패턴공유등을 활발하게 진행하고 분석능력을 강화 하기 위한 전담자를 두어 지속적인 운영이 가능하도록 해야 할 것입니다.






 


New Multi-Channel Dynamic CMS

핀테크 오픈플랫폼 구축 방안

금융위원회는 2015년 7월 핀테크 산업 발전을 위한 인프라 구축의 필요성을 느끼고 금융권과 핀테크 기업의 의견을 수렴하여 금융권 공동 핀테크 오픈 플랫폼 구축 계획을 발표합니다.


[핀테크 오픈 플랫폼 개념도]


창조경제를 지향하며 금융 서비스 활성화 및 핀테크 기업의 사업 활성화 방안으로 핀테크 오픈플랫폼 구축 사업을 계획하고 시작하였습니다.

계획대로 올해 핀테크 오픈 플랫폼 서비스를 시작한다면 세계 최초의 금융 오픈 플랫폼을 운영하는 나라가 된다고 합니다.
OPEN API 방식으로 핀테크 오픈 플랫폼이 구축되면 , API 방식으로 서비스를 구축하고 이용할 수 있어서
새로운 금융 서비스를 손쉽게 개발하고 이용자들이 그 서비스를 보다 빠르게 접해볼 수 있는 이점이 있어서 핀테크 관련 업체나 일반 사용자 모두에게 이익을 가져다 주는 사업입니다.



[ OPEN API를 활용하 핀테크 서비스 예시 : 가계부 앱]



하지만  일반적으로 금융회사의 내부 로직은 매우 복잡하므로 이것을 외부 시스템에서 이용할 수 있도록 OPEN API 시스템을 구축하기 현실적으로 쉽지 않은 프로젝트입니다.

각 금융권 기업 입장에서 핀테크 오픈플랫폼을 구출할 경우 대부분 다음과 같은 몇 가지의 현실적인 문제에 직면하게 될 것입니다.

핀테크 오픈 플랫폼이 정착되고 성공적으로 완성되기 위해 꼭 해결되어야 할 이러한 문제점들이 무엇이며 이것을 처리하기 위해서 어떠한 솔루션이 있는지 알아보도록 하겠습니다.


Legacy 시스템 연계

금융권 내부 업무 시스템은 다양한 Legacy 시스템 연계를 필요로 합니다. 일반적인 DBMS뿐만 아니라 MCI 서버 또는 Tuxedo 및 Tmax와 같은 TP 모니터 시스템등 다양한 Legacy 와 연계가 필요하며 각 시스템 연계를 위한 어댑터 및 Protocol 분석 능력이 필요합니다.
이러한 내부 로직을 OPEN API 형태로 변환하고 매핑하기 위해서는 일반적으로 많은 작업이 필요합니다.
또한 이러한 API들은 기존 Legacy  시스템과 별도로 운영되고 관리가 필요합니다. 따라서 업무적으로는 내부 다양한 시스템과  강결합(tightly coupled) 상태이지만, 운영적인 측면에서는 약결합(loosely coupled) 상태를 유지해야 됩니다.
이러한 내부 시스템  Protocol을 외부 OPEN API로 변환 노출하기 위해서는 많은 know-how를 필요로 합니다.

OPEN API의 이해

 OPEN API는 기본적으로 HTTP 웹 기반의 Restful 방식을 통해서 API를 이용할 수 있도록 하여야 합니다.  API 를 운영하기 위해서는 Restful에 대한 이해와 session 관리 보안등 단순히 외부에서 API를 쓸 수 있게 만드는 것 이상으로 고려되어야 할 사항이 많습니다.

업무에 대한 이해

증권내부 시스템만 보더라도 주문 및 계좌 조회를 하기 위해서는 기술적인 지식 뿐만 아니라 업무적인 이해가 필요합니다. 다양한 주문 옵션 정보 및 속성값에 대한 이해가 필요하며 그 업무가 외부로 노출되었을 때 여러 가지 영향도 판단이 필요합니다.

API 운영에 대한 유지보수

금융권 내부 시스템은 항상 그대로 있는것이 아니라 업무가 변경되거나 기술적인 변화가 자주 일어나는 시스템입니다. 이러한 내부 시스템이 OPEN API 로 서비스 될때 손쉽게 변경이 가능하거나 API 의 버전업 및 History 관리가 될 수 있도록 하여야 합니다.



위와 같은 문제점을 해결하기 위해서는 어떠한 방법이 있는지 알아보도록 하겠습니다.

API 관리 솔루션 기반의 시스템 구축


일반적으로 API 서비스 구축은 어려운 작업이 아닐 수 있습니다.  내부에서 사용하고 있는 로직을 단지 외부로 OPEN API 형태로 서비스를 생각한다면 JSON 및 XML 방식의 RestFul 형태로 OPEN API 를 노출시키기만 하면 되니깐요.

API 하나의 운영되기 까지 API의 Life Cycle 관리부터 ,보안,통계정보, 문제 발생시 Fail over등 다양한 상황에 대한 고려가 필요합니다.

이러 것을 하나하나 고민하면서 별도로 구축하기 까지는 시간과 비용이 많이 소비되며, 성공적으로 구축하기도 힘든 상황이 됩니다.
따라서 전문적으로 API를 관리 할 수 있는 솔루션 기반으로 구축되어야 합니다. 그렇지 않은 경우 여러 문제에 대한 대비책을 마련하여야 하며, 그렇지 않다면 여러 문제점이 야기될 수 있습니다.

API 사용에 대한 통계 정보 

OPEN API 서비스를 한다는 것은 다양한 사용자가 다양한 방법으로 API를 사용한다는 의미합니다. 내부적으로만 사용되는 경우 어느 정도 통제가 가능하지만 OPEN 된 API는 내부 사용보다 정말 방식으로 이용될 수 있습니다. 이런 경우 각종 통계정보를 정확하게 남기지 않는 다면 운영시 엄청난 관리 부담이 될 수 있습니다. 잘못된 호출로 인한 오류가 많이 발생될 수 있으면 그 원인을 빠르게 밝힐 수 있어야 합니다. 또한 사용량에 따른 과금이나 사용량 조절을 하기 위해서는 API사용에 대한 정확한 통계 정보를 유지해야합니다.

보안문제

일반적으로 핀테크 오픈 플랫폼 규약에서는 HTTPS기반 API 사용 또는 TLS기반의 Socket 방식을 제안하고 있습니다. 사실 Socket 방식의 구현은 확장성도 없으며 , 표준적인 방법도 아닙니다. 또한 웹기반 HTTPS 통신만으로 모든 보안 문제를 해결할 수 없기때문에  다양한 인증/보안 방식으로 통해 해결해야 합니다.

핀테크 오픈 플랫폼 서비스의 성공적인 구축을 위해선 여러 문제점을 효과적으로 해결하고, 다양한 시스템과의 손쉬운 연계 기능을 제공하며, 유연한 확장기능을 보장하는 API 솔루션 제품이 반드시 필요합니다.

이에 CyberImagination에서는 이러한 OPEN API 서비스 구축에 최적화된 DBridge API Server 솔루션 제공하고 있습니다.

좀더 자세한 정보가 원하시면 아래 URL 을 확인해 보시기 바랍니다.




New Multi-Channel Dynamic CMS