KR102502364B1 - 금융 거래 처리 시스템 및 방법 - Google Patents

Abstract

본 발명은 금융 거래 처리 시스템 및 방법에 관한 것으로서, 더 상세하게는 후행 처리가 가능한 디퍼드(Deferred) 거래 처리를 위하여, 상기 시스템은, 사용자 단말로부터 거래 요청을 수신하고, 수신한 거래 요청에 대해 디퍼드 거래 처리 대상 여부를 판단하여, 거래 데이터를 송신하는 제1 서버, 제1 서버로부터 상기 거래 데이터를 수신하는 제1 큐 서버, 제1 큐 서버로부터 상기 거래 데이터를 수신하고, 제1 큐 서버로부터 수신한 거래 데이터에 대해 미리 정의된 판단기준에 따라 디퍼드 거래 처리를 수행하는 제2 서버; 및 하나 이상의 로그 테이블을 포함하고, 상기 제1 서버 및 상기 제2 서버의 요청에 의한 로그를 기록하는 데이터베이스를 포함한다.

Description

금융 거래 처리 시스템 및 방법{SYSTEM AND METHOD FOR PROCESSING FINANCIAL TRANSACTIONS}

본 발명은 금융 거래 처리 시스템 및 방법에 관한 것으로서, 더 상세하게는 후행 처리가 가능한 디퍼드(Deferred) 거래 처리를 위한 금융 거래 처리 시스템 및 방법에 관한 것이다.

최근 정보통신 기술의 지속적인 발전으로 사용자가 상시 휴대하는 스마트 기기들을 통해 뉴스, 검색, 컨텐츠 조회 등 다양한 서비스를 제공하는 형태로 발전하고 있으며, 이러한 고도화된 기술들이 금융 산업 전반에도 확대되고 있다.

금융 산업에 있어서, 모바일 뱅킹 및 온라인 뱅킹을 통한 비대면 업무가 활성화됨에 따라 금융 업무의 데이터 처리량 또한 지속적으로 증대되고 있다. 이러한 변화에 따라, 은행과 같은 금융 기관들은 더 빠르고 효율적인 업무 처리가 가능하도록 내부 처리 시스템을 구축하고 지속적으로 개선해 나가고 있는 실정이다.

한편, 은행과 같은 금융기관이 처리하는 다양한 금융 업무 중, 준 실시간으로 거래를 처리하는 디퍼드(Deferred) 거래 처리 업무가 있다. 이는 특정 대상, 즉 테이블 또는 파일을 주기적으로 감시하면서 대상 테이터가 입력되거나 대상 파일이 유입되었을 경우 주기적으로 후선 업무를 처리하는 것을 말한다. 후선 업무에서는 자체 업무로직을 처리하거나 온라인 서비스를 호출하여 처리할 수도 있다. 이러한 디퍼드 거래 처리는 거래의 정합성 보장을 위해 매일 일마감으로 처리하여, 특정 지점 또는 은행에서 다수 거래의 결과값이 정확한지를 점검해야하는 문제가 있다.

하지만 종래의 디퍼드 거래 처리 방식은, 원 거래가 함께 처리할 경우 거래 전체가 지연되는 문제점이 있고, 후행 처리 시에는 거래의 정합성 보장에 어려움이 있는 경우가 많아, 거래 처리 방식을 개선하기 위한 니즈가 존재하였다.

본 발명의 목적은 이와 같은 종래 기술의 문제점을 해결하기 위하여, 원 거래와 이면이 디퍼드 거래를 분리하여 처리할 수 있는 금융 거래 처리 시스템 및 방법을 제공하는 데 있다.

본 발명의 다른 목적은 디퍼드 거래 처리 대상을 필터링하고, 해당 거래를 효율적으로 처리함으로써 거래의 속도와 정합성을 보장할 수 있는 금융 거래 처리 시스템 및 방법을 제공하는 데 있다.

상기 목적을 달성하기 위하여, 본 발명의 일 측면은, 금융 거래 처리 시스템으로서, 사용자 단말로부터 거래 요청을 수신하고, 수신한 거래 요청에 대해 디퍼드 거래 처리 대상 여부를 판단하여, 거래 데이터를 송신하는 제1 서버; 상기 제1 서버로부터 상기 거래 데이터를 수신하는 제1 큐 서버; 상기 제1 큐 서버로부터 상기 거래 데이터를 수신하고, 제1 큐 서버로부터 수신한 거래 데이터에 대해 미리 정의된 판단기준에 따라 디퍼드 거래 처리를 수행하는 제2 서버; 및 하나 이상의 로그 테이블을 포함하고, 상기 제1 서버 및 상기 제2 서버의 요청에 의한 로그를 기록하는 데이터베이스를 포함하는 금융 거래 처리 시스템을 제안한다.

선택적으로 상기 금융 거래 처리 시스템은 상기 제2 서버로부터 재처리 요청 및 재처리 대상 거래 데이터를 수신하는 제2 큐 서버를 더 포함하고, 상기 제2 서버는 상기 제2 큐 서버에 포함된 재처리 대상 거래 데이터를 수신하여, 디퍼드 거래 처리를 재수행할 수 있다.

또한 제1 서버는, 상기 사용자 단말로부터 거래 요청을 수신하는 거래 수신부, 수신한 거래 요청에 대해 거래를 수행하고, 디퍼드 거래 처리 대상 여부를 판단하는 출금부 또는 입금부, 및 상기 출금부 또는 입금부로부터 디퍼드 거래 처리 대상의 거래 데이터를 수신하여 상기 제1 큐 서버에 전달하는 프로듀서를 포함할 수 있다. 출금부 또는 입금부는, 상기 거래 수신부로부터 거래 요청을 수신하여, 미리 정의된 필터와 상기 거래 요청의 파라미터 값을 비교하여 디퍼드 거래 처리 대상 여부를 판단할 수 있다. 제 2 서버는, 상기 제 1 큐 서버로부터 상기 거래 데이터를 수신하고, 상기 거래 데이터에 대해 미리 정의된 판단기준에 따라 디퍼드 거래 처리 여부를 판단하고, 디퍼드 거래를 발생시키는 컨슈머, 및 컨슈머에서 발생된 디퍼드 거래에 대응하는 업무 로직을 실행하는 업무 로직 실행부를 포함할 수 있다.

이 때, 판단기준은 처리 횟수에 대한 제1 판단기준, 원거래 완료 여부에 대한 제2 판단기준 및 에러로그 유무에 대한 제3 판단기준을 포함할 수 있다. 컨슈머는, 상기 제1 판단기준에 따라, 상기 처리 횟수가 미리 정의된 기준 횟수를 초과하는 경우 수동 처리되도록 분류할 수 있고, 상기 제2 판단기준에 따라, 거래로그의 유무를 판단하여 원거래 완료 여부를 판단하고, 원 거래 완료 시에는 상기 디퍼드 거래를 발생시키고, 원거래 미완료 시에는 상기 제3 판단요소에 따라 에러로그 유무를 판단할 수 있다. 나아가, 상기 제3 판단기준에 따라, 에러로그가 존재하는 경우 상기 거래 데이터의 상태값을 ‘대상 아님’으로 업데이트하여 데이터베이스에 기록하고, 에러로그가 존재하지 않는 경우, 재처리요청을 수신하는 제2 큐 서버에 상기 거래 데이터를 전달할 수 있다. 한편, 업무 로직 실행부는, 상기 디퍼드 거래에 대응하는 업무 로직을 실행하고, 실행 결과를 상기 데이터베이스의 테이블에 업데이트하는 것을 특징으로 한다.

본 발명의 다른 측면은, 하나 이상의 서버, 큐 서버 및 데이터베이스를 포함하는 금융 거래 처리 시스템에 의해 수행되는, 금융 거래 처리 방법으로서, 사용자 단말로부터 거래 요청을 수신하는 단계; 거래 요청에 대해 미리 정의된 필터를 이용하여 디퍼드 거래 처리 대상 여부를 판단하는 단계; 디퍼드 거래 처리 대상으로 판단된 경우, 거래 데이터를 상기 큐 서버에 전달하는 단계; 및 큐 서버의 상기 거래 데이터를 수신하여, 상기 거래 데이터에 대해 미리 정의된 판단기준에 따라 디퍼드 거래 처리를 수행하는 단계를 포함한다.

여기서, 디퍼드 거래 처리 대상 여부를 판단하는 단계는, 미리 정의된 필터와 상기 거래 요청의 파라미터 값을 비교하여 디퍼드 거래 처리 대상 여부를 판단하고, 디퍼드 거래 처리 단계를 수행하는 단계는, 상기 큐 서버로부터 상기 거래 데이터를 수신하는 단계, 상기 판단기준에 따라 디퍼드 거래 처리 여부를 판단하여, 디퍼드 거래를 발생시키는 단계, 및 발생된 디퍼드 거래에 대응하는 업무 로직을 실행하는 단계를 포함할 수 있다.

본 발명의 금융 거래 처리 시스템에 의하면, 디퍼드 거래 처리 대상으로 판별된 거래에 대해, 디퍼드 거래를 원 거래와 분리하여 별도 처리함으로써 거래의 신속성과 무결성, 정합성을 보장할 수 있는 효과가 있다.

본 발명에 의하면, 특정 거래를 분리하여 후행 처리(지연 처리)하기 위한 후처리 필터를 설정함으로써, 상시 감사가 필요한 고액거래 등 특정 거래를 용이하게 필터링할 수 있고, 대량 처리 시에도 지연 시간을 최소화할 수 있다.

또한 본 발명에 의하면, 디퍼드 거래 처리의 상태 및 결과를 세분화하여 판단기준을 설정함으로써, 디퍼드 거래 처리의 실패를 최소화하고, 원 거래와의 정합성을 보장할 수 있다는 이점이 있다.

도 1은 본 발명의 일 실시예에 따른 금융 거래 시스템을 설명하기 위한 개요도이다.
도 2는 본 발명의 일 실시예에 따른 금융 거래 처리 시스템의 구성요소를 설명하기 위한 블록도이다.
도 3은 본 발명의 일 실시예에 따른 금융 거래 처리 방법의 일례를 도시한 것이다.
도 4는 본 발명의 일 실시예에 따라 디퍼드 거래 처리 대상을 판별하는 방법을 설명하기 위한 도면이다.
도 5는 본 발명의 일 실시예에 따른 디퍼드 거래 처리 방법을 설명하기 위한 순서도이다.
도 6은 본 발명의 일 실시예에 따른 거래 요청 데이터의 일례를 도시한 것이다.
도 7은 본 발명의 일 실시예에 따른 후처리 필터의 일례를 도시한 것이다.
도 8은 본 발명의 일 실시예에 따른 디퍼드 로그의 일례를 설명하기 위해 도시한 것이다.

본 명세서에 개시되어 있는 본 발명의 개념에 따른 실시 예들에 대해서 특정한 구조적 또는 기능적 설명은 단지 본 발명의 개념에 따른 실시 예들을 설명하기 위한 목적으로 예시된 것으로서, 본 발명의 개념에 따른 실시 예들은 다양한 형태들로 실시될 수 있으며 본 명세서에 설명된 실시예들에 한정되지 않는다.

본 발명의 개념에 따른 실시 예들은 다양한 변경들을 가할 수 있고 여러 가지 형태들을 가질 수 있으므로 실시 예들을 도면에 예시하고 본 명세서에서 상세하게 설명하고자 한다. 그러나, 이는 본 발명의 개념에 따른 실시 예들을 특정한 개시 형태들에 대해 한정하려는 것이 아니며, 본 발명의 사상 및 기술 범위에 포함되는 모든 변경, 균등물, 또는 대체물을 포함한다.

제1 또는 제2 등의 용어는 다양한 구성 요소들을 설명하는데 사용될 수 있지만, 상기 구성 요소들은 상기 용어들에 의해 한정되어서는 안 된다. 상기 용어들은 하나의 구성 요소를 다른 구성 요소로부터 구별하는 목적으로만, 예컨대 본 발명의 개념에 따른 권리 범위로부터 벗어나지 않은 채, 제1구성 요소는 제2구성 요소로 명명될 수 있고 유사하게 제2구성 요소는 제1구성 요소로도 명명될 수 있다.

어떤 구성 요소가 다른 구성 요소에 "연결되어" 있다거나 "접속되어" 있다고 언급된 때에는, 그 다른 구성 요소에 직접적으로 연결되어 있거나 또는 접속되어 있을 수도 있지만, 중간에 다른 구성 요소가 존재할 수도 있다고 이해되어야 할 것이다. 반면에, 어떤 구성 요소가 다른 구성 요소에 "직접 연결되어" 있다거나 "직접 접속되어" 있다고 언급된 때에는 중간에 다른 구성 요소가 존재하지 않는 것으로 이해되어야 할 것이다. 구성 요소들 간의 관계를 설명하는 다른 표현들, 즉 "~사이에"와 "바로 ~사이에" 또는 "~에 이웃하는"과 "~에 직접 이웃하는" 등도 마찬가지로 해석되어야 한다.

본 명세서에서 사용한 용어는 단지 특정한 실시 예를 설명하기 위해 사용된 것으로서, 본 발명을 한정하려는 의도가 아니다. 단수의 표현은 문맥상 명백하게 다르게 뜻하지 않는 한, 복수의 표현을 포함한다. 본 명세서에서, "포함하다" 또는 "가지다" 등의 용어는 본 명세서에 기재된 특징, 숫자, 단계, 동작, 구성 요소, 부분품 또는 이들을 조합한 것이 존재함을 지정하려는 것이지, 하나 또는 그 이상의 다른 특징들이나 숫자, 단계, 동작, 구성 요소, 부분품 또는 이들을 조합한 것들의 존재 또는 부가 가능성을 미리 배제하지 않는 것으로 이해되어야 한다.

다르게 정의되지 않는 한, 기술적이거나 과학적인 용어를 포함해서 여기서 사용되는 모든 용어들은 본 발명이 속하는 기술 분야에서 통상의 지식을 가진 자에 의해 일반적으로 이해되는 것과 동일한 의미를 나타낸다. 일반적으로 사용되는 사전에 정의되어 있는 것과 같은 용어들은 관련 기술의 문맥상 가지는 의미와 일치하는 의미를 갖는 것으로 해석되어야 하며, 본 명세서에서 명백하게 정의하지 않는 한, 이상적이거나 과도하게 형식적인 의미로 해석되지 않는다.

이하에서는, 도 1 내지 도 8을 참조하여 본 발명의 실시예에 따른 금융 거래 처리 시스템 및 방법에 대해 자세히 설명하도록 한다.

도 1은 본 발명의 일 실시예에 따른 금융 거래 시스템을 설명하기 위한 개요도이다. 본 발명의 일 실시예에 따른 금융 거래 처리 시스템(100)은 통신망(200)을 통해 다수의 사용자 단말(310 내지 320)과 접속되어 금융 거래 처리를 수행할 수 있다.

금융 거래 처리 시스템(100)은 통신망(200)을 통해 접속한 사용자에게 금융 서비스를 제공하기 위한 시스템으로서, 인증, 금융 업무 처리 등 다양한 금융 서비스를 수행하는 다수의 서버와 데이터베이스 등 하드웨어, 소프트웨어 구성요소를 포함할 수 있다고, 소프트웨어 플랫폼에 설치된 프레임워크를 포함한다. 금융 거래 처리 시스템(100)의 구성에 대해서는 도 2를 참조하여 더 상세히 설명하도록 한다.

이하에서, 본 명세서에서는 금융 거래 처리 시스템(100)이 디퍼드 거래 처리를 수행하는 실시예를 위주로 설명하지만, 이에 한정되는 것은 아니며, 다양한 금융 거래 관련 정보들의 처리, 저장 및 관리를 수행할 수 있다. 또한 다수의 금융 서비스 처리를 위한 서버들로 구성되거나 연동하여 동작할 수 있다

본 발명의 일 실시예에 따른 금융 거래 처리 방법은 다양한 금융 거래 처리 중 디퍼드(지연 처리 업무) 거래 처리에 관한 것으로, 금융 거래 처리 시스템(100)은 사용자(310)가 요청한 금융 거래가 디퍼드 거래에 해당하는지 판단하여, 디퍼드 거래 처리를 수행하는 역할을 한다. 이 때, 금융 거래 처리 시스템(100)은 디퍼드 거래 처리 대상이 된 거래들을 큐 방식으로 큐 서버에 대기하도록 한 뒤, 거래 처리를 위한 서버의 쓰레드로 할당하여 처리되도록 한다. 금융 거래 처리 시스템(100)은 원 거래와의 정합성을 보장하기 위해, 원거래의 정상종료 여부, 에러로그의 유무 등을 확인할 수 있고, 처리가 미완료된 건은 재처리를 시도하거나 수동 처리가 가능하도록 지원함으로써, 효율적인 디퍼드 거래 처리를 수행한다.

이처럼, 금융 거래 처리 시스템(100)은 기존의 디퍼드 거래 처리 방식과는 달리, 사용자 간의 거래와 금융 거래 처리 시스템(100)에서의 거래 처리를 분리하여 처리하도록 함으로써, 사용자 간 거래의 신속성과 신뢰성을 향상시킬 수 있다. 금융 거래 처리 시스템(100)의 구체적인 처리 방법에 대해서는 도 2 내지 8을 참조하여 더 상세히 설명한다.

사용자 단말(310 또는 320)은 금융 서비스를 제공하는 모바일 뱅킹 어플리케이션을 설치 및 구동할 수 있는 단말을 말하고, 다양한 형태의 컴퓨팅 디바이스(휴대폰, 스마트 폰(smart phone), 스마트 패드(smart pad), 노트북 컴퓨터(notebook computer), 디지털방송용 단말기, PDA(Personal Digital Assistants), PMP(Portable Multimedia Player), 네비게이션, 태블릿 PC 및 스마트 워치, 스마트 밴드와 같은 다양한 웨어러블 디바이스 등)를 포함한다.

이하 본 명세서에서 사용자 단말은 스마트폰을 위주로 설명하였으나, 이에 한정되는 것은 아니다. 또한, 발명의 이해를 돕기 위하여 하나의 사용자 단말(310)과 시스템(100) 간의 거래 처리 방법의 예시를 주로 설명하지만, 이에 한정되는 것은 아니며 다수 사용자 단말 간의 거래에도 본 발명의 실시예가 적용될 수 있다.

본 발명의 일 실시예에 따른 사용자 단말(310, 320)은 금융기관에서 제공하는 모바일 뱅킹 어플리케이션을 통해 금융 서비스를 이용할 수 있고, 일례로 금융상품 가입, 이체, 신용정보 확인 등 다양한 금융 서비스를 제공받는다. 일 실시예로서, 사용자 단말(310, 320)은 개인 간 이체 거래가 가능하여, 모바일 뱅킹 어플리케이션을 실행하여 이체 기능을 통해 본인의 소유 계좌에서 소정의 금액이 출금되고, 수취인에게 입금되도록 할 수 있다. 이 때, 사용자 단말(310, 320)을 이용하는 사용자(송금인)는 모바일 뱅킹 어플리케이션이 제공하는 사용자 인터페이스를 통해 이체 상황, 인증 화면 등을 확인할 수 있고, 이체 결과 본인의 계좌에서 이체 금액이 인출된 계좌 잔액을 확인할 수 있다. 반대로, 수취인은 사용자 단말(310, 320)에서 이체 금액이 입금된 계좌 잔액을 확인할 수 있다.

이처럼, 사용자 간의 금융 거래 시 사용자 단말(310, 320)에서는 거래를 위해 정보를 입력하거나 인증을 수행하는 거래 진행 화면이 출력되고, 거래가 완료된 결과로서 사용자 소유 계좌의 잔액과 입출금된 금액 등을 확인할 수 있다. 즉, 사용자 단말(310, 320)을 사용하는 사용자는 원 거래 실행 후에, 본 발명의 금융 거래 처리 시스템(100)이 수행하는 디퍼드 거래 처리에는 관여하지 않으며, 원 거래가 정상 종료되었는지 여부만을 확인할 수 있다.

한편, 통신망(200)은 사용자 단말(310)과 금융 거래 처리 시스템(100)를 연결하는 유무선 네트워크를 의미하고, 금융 거래 처리를 위한 데이터를 송수신할 수 있는 경로 역할을 한다. 예컨대, 통신망(200)은 LANs(Local Area Networks), WANs(Wide Area Networks), MANs(Metropolitan Area Networks), ISDNs(Integrated Service Digital Networks) 등의 유선 네트워크나, 무선 LANs, CDMA, 블루투스, 위성 통신 등의 무선 네트워크를 포함하고, 본 발명의 통신망 범위가 이에 한정되는 것은 아니다.

도 2는 본 발명의 일 실시예에 의한 금융 거래 처리 시스템(100)의 구성요소를 설명하기 위한 블록도이다. 도 2를 참조하면, 금융 거래 처리 시스템(100)은 제1 서버(110), 제2 서버(120), 큐 서버(130) 및 데이터베이스(DB, 140)를 포함할 수 있다.

제1 서버(110)는 사용자로부터 거래 요청을 수신하여, 디퍼드 거래 처리 대상인지 여부를 판단하는 서버이다. 도 2에 도시된 것처럼, 제1 서버(110)는 사용자로부터 거래를 수신하는 거래 수신부(111), 거래에 따라 입금 및/또는 출금을 처리하는 입금부(113), 출금부(112), 및 프로듀서(114)를 포함할 수 있다. 여기서, 각각의 구성요소(111 내지 114)는 해당 기능을 수행하는 프로그램 형태로 구현되어 기록매체에 저장될 수 있고, 제1 서버(110)에 구비된 프로세서에 의해 각각의 기능을 수행되도록 동작할 수 있다. 또한 제1 서버(110)의 구성은 도 2에 도시된 구성요소에 한정되는 것은 아니며 하나 이상의 구성요소가 병합된 형태로 구현되거나 서버의 동작에 필요한 구성요소를 더 포함할 수 있다.

일 실시예로서, 제1 사용자(310)와 제2 사용자 간의 이체 거래 시, 금융 거래 처리 시스템(100)은 제1 사용자(310)의 계좌에서는 출금 거래를 진행하고, 제2 사용자(320)의 계좌에서는 입금 거래를 진행한다. 이 때, 제1 사용자(310)로부터 출금 거래를 진행하는 경우, 제1 서버(110)는 사용자 단말(310)로부터 출금 거래에 관한 요청을 수신하고, 디퍼드 거래인지 여부를 판단할 수 있다. 또한 제1 서버(110)는 출금 거래 요청에 따른 출금 실행 후 출금 거래의 디퍼드 처리를 요청하고, 입금 거래 요청에 따른 입금을 실행한 후 입금 거래의 디퍼드 처리를 요청할 수 있다. 이러한 일련의 과정은 정해진 순서 및 선후 관계에 의해서만 수행되는 것은 아니며, 제1 거래가 실행된 후 디퍼드 거래 처리가 실행되는 동안 제2 거래가 실행되는 방식으로, 거의 실시간으로 또는 동시에, 거래 실행과 디퍼드 거래 처리가 일어날 수 있다.

거래 수신부(111)는 사용자 단말(310)로부터 거래를 수신하여 전달하는 역할을 한다. 예컨대, 거래 수신부(111)는 제1 서버(110)의 프로세서에 의해 동작하는 계좌 이체 프로그램(Account Transfer Program) 형태로 구현될 수 있다. 거래 수신부(111)는 해당 금융 거래의 종류를 파악하여 출금부(112) 또는 입금부(113)로 거래 요청을 전달할 수 있다.

출금부(112)는 거래 수신부(111)로부터 수신한 거래 데이터의 전처리, 후처리를 수행하고, 미리 저장된 조건문과 비교하여 디퍼드 거래 대상인지 여부를 판단하는 역할을 수행한다. 일 실시예로서, 출금부(112)는 출금 거래 프로그램 및 프레임워크가 제공하는 후처리 필터를 포함할 수 있고, 출금 거래 프로그램에 의해 출금 거래를 실행하고, 후처리 필터를 통해 디퍼드 거래 대상 여부를 확인할 수 있다.

마찬가지로, 입금부(113)는 요청된 입금 거래를 수행하는 입금 거래 프로그램과 디퍼드 거래 대상인지 여부를 판단하는 후처리 필터를 포함할 수 있다. 출금부(112)와 입금부(113)는 수신한 거래 데이터의 전처리, 후처리를 수행하고, 후처리 시에 디퍼드 거래 대상인지를 판단한다.

일 실시예로서, 출금부(112)는 전처리 시에, 거래 수신부(111)로부터 표준 전문 형태의 거래 데이터를 수신하여 이체 거래 요청 데이터의 포맷을 생성한 후, 출금 거래 요청 데이터 및 입금 거래 요청 데이터의 파라미터 값을 설정하여 각각의 데이터를 생성할 수 있다(도 6 참조). 이후에 거래 데이터에 따른 본 거래를 실행한다. 다음으로, 후처리 시 거래로그를 생성하여 DB(140)에 전달하고, 디퍼드 거래 처리 대상 여부를 확인하여 프로듀서(114)에 대상 거래 데이터를 송신할 수 있다.

프로듀서(114)는 출금부(112) 또는 입금부(113)로부터 디퍼드 처리 대상 거래 데이터을 큐 서버(130)에 전달하는 역할을 한다. 즉, 제1 서버(110)는 디퍼드 거래 대상을 필터링하여 큐 서버(130)에 해당 거래를 전달하는 역할을 하며, 거래 수신부(111), 출금부(112), 프로듀서(114)를 통해 요청(request)을 전달한다. 본 발명에 의하면, 디퍼드 거래 처리 시 큐 서버(130)를 이용한 큐 방식을 취함에 따라, 디퍼드 거래 처리 요청을 큐 서버(130)에 송신한 후, 응답을 기다리지 않고, 후속 프로세스(예컨대, 입금 거래 처리)를 진행한다. 이러한 거래 처리 방법에 의하면, 신규 디퍼드 거래 처리 시마다 응답을 대기하거나 모니터링할 필요가 없어, 거래 처리가 지연되는 문제점을 해결할 수 있고, 시스템의 처리 부하를 줄일 수 있는 이점이 있다.

큐 서버(130)는 프로듀서(114)로부터 전달받은 디퍼드 거래 처리 대상들을 제2 서버로 전달하기 전에 대기 큐(Queue)로 관리하는 역할을 한다. 큐 서버(130)는 도 3에 도시한 것처럼, 본 거래를 제2 서버(120)에 바로 전달하는 제1 큐 서버(131) 및 재처리 요청에 의한 큐를 관리하는 제2 큐 서버(132)를 포함할 수 있다.

한편, 제2 서버(120)는 큐 서버(130)로부터 할당된 대상 거래를 처리하는 서버로서, 거래 데이터를 감지하고 디퍼드 거래 처리 여부를 판단하는 컨슈머(121) 및 디퍼드 거래 처리를 위해 업무 로직을 실행하는 업무 로직 실행부(122)를 포함할 수 있다.

컨슈머(121)는 큐 서버(130)로부터 거래를 감지하고(listen), 거래 데이터를 가져오고, 원 거래가 정상종료되었는지를 확인한다. 컨슈머(121)는 큐 서버로부터 거래 정보를 가져오고, 거래 정보 당 하나의 쓰레드를 발생시켜, 해당 쓰레드 안에서 프로그램을 실행할 수 있다. 컨슈머(121)는 가져온 거래 정보에 대해 원 거래의 정상종료 여부를 확인하여 디퍼드 거래 처리 여부를 판단한다. 이 때, 컨슈머(121)는 거래로그에 대한 시퀀스 넘버를 통해 거래 로그의 정상 종료 여부를 판단한다.

일 실시예로서, 컨슈머(121)는 제1 판단요소로서, 수신한 디퍼드 거래 처리 대상의 처리 횟수가 기준 횟수(예컨대, 3회)를 초과하는지 판단할 수 있다. 디퍼드 거래 처리 대상은 재처리 프로세스에 의해 다시 수행되는 경우도 있으나, 무한 번 재처리를 수행할 수 없으므로, 처리 횟수가 기준 횟수 이상인 경우에는 관리자에 의한 수동 처리가 가능하도록 분류한다. 즉, 디퍼드 거래 처리 대상이 3회 이상 처리를 시도한 건이라면, 본 시스템에 의한 디퍼드 거래 처리가 어려운 대상이라고 판단하고 어드민 계정에 의해 수동 처리되도록 한다.

만약, 처리 횟수가 기준 횟수 이하인 경우에는, 컨슈머(121)는 제2 판단요소로서 거래 로그와 에럴로그를 확인하여 원거래의 완료 여부를 확인한다. 컨슈머(121)는 원거래 완료 여부 확인 시, 원 거래가 정상적으로 완료된 경우에는 디퍼드 거래 처리를 수행하고, 그 결과를 총 계정 원장에 반영할 수 있다. 여기서, 원거래의 완료 여부는, 거래로그의 유무를 통해 확인할 수 있다.

이 때 거래로그가 존재하지 않거나 원 거래가 미완료 된 경우에는 에러로그의 유무를 확인하고, 만약 에러로그가 존재한다면, 이는 디퍼드 처리 대상으로 판단하기에는 오류가 있는 상태이므로, 디퍼드 로그 테이블에 대상 거래의 상태값을 “대상 아님”으로 업데이트 할 수 있다. 반면, 에러로그가 없는 경우에는, 디퍼드 거래 처리를 재시도하기 위해 제2 큐 서버(132)에 재처리 요청을 송신한다.

일 실시예로서, 컨슈머(121)는 디퍼드 거래 처리를 결정하면, 디퍼드 처리를 위한 거래를 발생시켜 업무 로직 실행부(122)에 전달한다. 일 실시예로서, 이체 거래의 경우, 컨슈머(121)가 출금 또는 입금 거래에 대해 총 계정 원장에 반영하는 디퍼드 처리 거래를 발생시켜 업무 로직 실행부(122)에 전달할 수 있다.

업무 로직 실행부(122)는 컨슈머(121)가 발생시킨 디퍼드 처리 거래에 따라, 업무 로직(business logic)을 실행하여 해당 거래를 처리하는 역할을 한다. 예를 들어, 업무 로직 실행부(122)는 디퍼드 처리 거래의 대상이 되는, 업무 로직을 호출하여 실행되도록 한다. 해당 로직의 실행이 완료되면 실행 결과에 대한 로그를 남길 수 있다.

일 실시예로서, 업무 로직 실행부(122)는 출금부(112)의 디퍼드 필터 갯수에 대응되도록 구성될 수 있다. 예컨대, 디퍼드 필터가 상시 감사 및 이체 처리 2가지의 필터로 구성될 경우, 업무 로직 실행부(122)도 상시 감사의 업무 로직을 실행시키는 업무 로직 실행부와 이체 처리 업무 로직을 실행시키는 업무 로직 실행부로 구성되어 2개의 업무 로직 실행부를 포함하도록 구현될 수 있다.

일 실시예로서, 업무 로직 실행부(122)는 디퍼드 거래가 정상으로 종료되면, DB(140)의 디퍼드 로그 테이블에 대상 거래의 상태값을 ‘완료’로 업데이트한다. 만약 디퍼드 거래가 정상 종료되지 못한 경우에는, 디퍼드 로그 테이블에 대상 거래의 상태값을 ‘실패’로 업데이트하고, 재처리(S41)를 시도할 수 있다. 다른 예로, 디퍼드 거래에 실패한 경우 수동 처리(530 단계)로 분류되도록 구현할 수도 있다.

이와 같이, 본 발명에 의하면, 디퍼드 거래 처리의 상태 및 결과를 세분화하여 판단함으로써, 디퍼드 거래 처리의 실패를 최소화하고, 원 거래와의 정합성을 보장할 수 있다.

DB(140)는 데이터 로그 기록을 위해 하나 이상의 테이블을 포함한 데이터베이스로서, 본 발명의 일 실시예에 따라 거래 처리 테이블, 거래 로그 테이블, 원장 테이블, 디퍼드로그 테이블을 포함할 수 있다. 거래 처리 테이블은 입금 또는 출금 처리 시 실행내역 또는 결과를 기록하고, 거래 로그 테이블은 출금부(112) 또는 입금부(113)에서 생성한 출금 또는 입금 거래 로그를 저장하고, 원장 테이블은 디퍼드 거래 처리 결과를 총 계정 원장에 반영하여 기록하는 테이블을 말한다. 또한 디퍼드로그 테이블은 디퍼드 대상 거래 처리를 기록하는 테이블을 말한다. 본 명세서에서는 DB(140)가 위에서 설명한 테이블을 이용하여 로그를 기록하고, 관리하는 것으로 설명하였으나, 이에 한정되는 것은 아니며, 본 발명의 실시에 필요한 다른 데이터와 테이블을 기록하고 관리할 수도 있다.

이하에서는, 도 3 내지 8을 참조하여 본 발명의 일 실시예에 의한 디퍼드 거래 처리 방법에 대해 더 상세히 설명하도록 한다.

도 3은 본 발명의 일 실시예에 의한 금융 거래 처리 방법의 일례를 도시한 것으로, 사용자의 이체 거래 시 송금인의 출금 거래에 대해 설명한다. 본 도면을 참조하여, 이체 거래의 예시를 위주로 설명하였으나, 이는 일 실시예에 불과하고, 특정 거래 또는 업무 처리 시에 본 금융 거래 처리 방법이 활용될 수 있다.

먼저, 사용자 단말기(310)에서 동작하는 모바일 뱅킹 어플리케이션을 통해 이체 거래 시, 송금인의 사용자 단말기(310)는 사용자 계좌에서의 출금 요청을 송신할 수 있다(S31). 이때, 표면적으로는 송금인과 수취인 간의 이체 거래(이하, ‘원 거래’라고 함)가 발생하는 것으로 보이지만, 이면에 송금인 계좌에서의 출금 거래, 수취인 계좌에서의 입금 거래가 발생하게 된다.

그러나 원 거래와 이면 거래를 동시에 수행하거나 폴링 방식으로 처리하는 경우 거래 처리의 신속성이 떨어지고 처리 부하가 높다는 문제점이 있다. 따라서, 본 발명은 일정한 조건을 만족하는 거래에 대해, 이러한 이면 거래를 원 거래와 분리하여 후선 업무로 별도 처리함으로써 거래의 신속성과 무결성을 보장하고자 한다. 예를 들어, 본 발명의 디퍼드 거래 처리 대상은 준 실시간 거래로서 부하가 발생하는 거래, 회계 처리, 고액 거래와 같은 상시 감사 등이 적용되어 필터링이 필요한 거래 등이 포함될 수 있다.

다음으로, 거래 수신부(111)는 사용자 단말(310)로부터 출금 거래 요청을 수신하여 출금부(112)에 전달할 수 있다(S32). 이 때, 출금부(112)는 출금 거래 요청을 수신하면, 미리 정해진 요건에 따라 데이터의 전처리, 후처리 등을 실시할 수 있다.

본 발명의 일 실시예에 의하면, 출금부(112)는 제1 서버(110)의 프로세서에 의해 동작하는 출금 거래 프로그램과 프레임워크가 연동된 형태로 구현될 수 있다. 출금부(112)는 출금 거래 프로그램을 이용하여 거래 수신부(111)로부터 수신한 표준 전문 형태의 출금 거래 데이터를 수신하고, 이체 거래 요청 데이터 포맷으로 데이터를 가공할 수 있다. 또한 출금부(112)는 이체 거래 요청 데이터로부터 출금 거래 요청 데이터 및 입금 거래 요청 데이터를 생성할 수 있고, 해당 데이터 내에 파라미터 값을 설정하는 전처리 과정을 수행할 수 있다.

다음으로, 출금부(112)는 전처리에서 설정된 파라미터 값을 이용하여 후처리 시 디퍼드 거래 대상인지 여부를 판단할 수 있다(S35). 여기서, 디퍼드 거래 대상 여부를 체크하는 후처리 필터는, 미리 정의된 조건문 형태로 구현될 수 있고, 요청된 거래와 조건문을 비교하여 디퍼드 대상 여부를 판단할 수 있다. 이러한 후처리 필터에 대해서는 도 4를 참조하여 더 자세히 설명하도록 한다.

한편, 출금부(112)는 전처리, 후처리 시에 출금 처리 로그 및/또는 출금 거래 로그를 생성하고, DB(140)에 저장할 수 있다(S33, S34). 이러한 로그는 미리 정해진 기준에 따라 가공되어 생성될 수 있고, DB(140)의 거래 처리 테이블, 거래 로그 테이블에 저장될 수 있다.

다음으로, 출금부(112)는 디퍼드 거래 처리 대상으로 판단되면, 프로듀서(114)에 원장 반영이 요청되고(S36), 해당 요청은 제1 큐 서버(131)로 전달된다(S36, S37). 일 실시예로서, 본 발명의 큐 서버(130)는 디퍼드 거래 처리 대상들을 제1 서버(110)로부터 수신하는 제1 큐 서버(131) 및 디퍼드 거래 처리 수행 후 재처리 대상이 된 거래들을 제2 서버(120)로부터 수신하는 제2 큐 서버(132)를 포함한다.

제1 큐 서버(131)에 처리할 요청들이 적재될 때, 제2 서버(120)의 컨슈머(121)가 이를 모니터링하여, 처리할 거래를 감지하여 가져올 수 있다(S38). 여기서, 컨슈머(121)는 개별 거래를 가져와 쓰레드를 발생시켜 실행하는 디퍼드 프로세서 및 인스턴스별 컨슈머를 포함하고, 디퍼드 거래 여부를 판단하고 디퍼드 처리 거래를 발생시키는 프레임워크를 포함하여 동작하도록 구현될 수 있다.

제1 큐 서버(131)에 있던 거래 요청들은 랜덤하게 또는 미리 정의된 기준에 따라 컨슈머(121)에 전달되고, 수신된 요청에 대해 디퍼드 거래 처리 여부를 판단한 후 디퍼드 거래로 처리하기 위한 ‘디퍼드 거래’를 발생시킬 수 있다(S39). 즉, 컨슈머(121)는 거래 요청을 수신하여, 처리 횟수, 원 거래의 완료 여부, 에러 로그 유무 등 판단 요소들을 확인하고, 미리 정의된 기준을 만족하는 경우 디퍼드 거래를 발생시킬 수 있다.

업무 로직 실행부(122)는 발생된 디퍼드 거래에 따라 해당 업무 로직을 호출하여 실행하는 역할을 한다. 예컨대, 발생된 디퍼드 거래가 이체 시 출금 거래에 관한 것인 경우, 이를 총 계정 원장에 반영하기 위한 업무 로직을 호출하여 실행함으로써, 원장 테이블에 거래를 반영하는 로그가 기록되도록 하고, DB(140)의 디퍼드 로그 테이블에 대상 거래의 상태값을 ‘완료’로 업데이트할 수 있다(S40).

한편, 컨슈머(121)는 디퍼드 거래 처리에 실패하거나 원거래가 미처리된 경우에 재처리를 수행하도록 할 수 있다(S41). 재처리 대상이 된 거래는 제2 큐 서버(132)에 재처리 요청이 되고, 제2 큐 서버(132)에 대기 후 다시 디퍼드 거래 처리를 시도한다(S42). 이와 같은 디퍼드 거래 처리 방식에 대해서는 도 5를 참조하여 더 상세히 설명하도록 한다.

이처럼, 본 발명에 의한 거래 처리 시스템은 큐 서버를 활용한 큐 방식의 디퍼드 거래 처리를 수행함으로써, 원거래의 거래 속도를 향상시키면서도, 거래의 정합성과 신뢰성을 보장할 수 있다.

도 4는 본 발명의 일 실시예에 따라 디퍼드 거래 처리 대상을 판별하는 방법을 설명하기 위한 도면이다. 도 3에서 설명한 것처럼, 제1 서버(110)는 사용자 단말(310)로부터 입금 또는 출금 등 거래 요청 데이터를 수신한다(410 단계). 거래 수신부(111)가 거래 요청 데이터를 수신하면, 출금부(112) 또는 입금부(113)에 이를 전달하여 데이터의 전처리 및 후처리를 진행한다.

도 4를 참조하면, 제1 서버(110)의 출금부(112)는 거래 요청 데이터의 전처리를 수행한다(420 단계). 이 때, 거래 요청 데이터는 도 6의 이체거래요청 데이터(610)에 도시된 것처럼, GUID, LOG, SRVC_ID와 같은 파라미터 값들을 포함할 수 있다. 이체 거래 시에는 특정 계좌에서의 출금과 입금이 수반되어야 하므로, 송금인의 계좌에 대해서는 출금 거래 요청 데이터(620)가 생성되고, 수취인의 계좌에 대해서는 입금 거래 요청 데이터(630)가 생성될 수 있다.

도 6을 참조하면, 이체 거래 요청 데이터(610)는 상술한 것처럼 표준 전문으로부터 값을 추출하여 소정의 파라미터 값이 설정된 포맷으로 구성될 수 있고, 출금 거래 요청 데이터(620) 및 입금 거래 요청 데이터(630)는 일부 공통 파라미터 값(예컨대, GUID, LOG_DT)을 갖되, SRVC_ID등 일부 값은 각각 별도 할당될 수 있고, 기타 값(예컨대, ANTT_YN, DEFERRED_YN)은 후처리를 위해 추가될 수 있다. 다만, 본 도면에 도시된 파라미터 값에 한정되는 것은 아니며, 서비스에 필요한 파라미터 값들이 더 포함될 수 있다.

한편, 거래 요청 데이터의 전처리가 완료되면 해당 거래를 진행한다(430 단계). 예컨대, 이체 거래의 경우, 출금 거래 프로그램에 의해 수취인 계좌에서는 출금 처리가 일어나도록 처리하고 로그를 생성하여 DB(140)에 반영될 수 있다.

일 실시예로서, 이체 거래의 경우, 출금과 입금 거래가 수행되어야 하므로, 출금 처리(410 내지 430 단계)가 수행된 후, 후처리 필터에 의해 대상여부로 판단되면 큐 서버에 송신하는 프로세스(440 내지 460 단계)가 수행되고, 후속으로, 거래 수신부(111)로 돌아와 입금부(1130)를 통해 입금 처리(410 내지 430 단계) 및 디퍼드 거래 대상 판단(440 내지 460 단계) 프로세스를 진행할 수 있다. 이처럼, 본 발명의 금융 거래 처리 방법은 큐 서버를 이용한 방식을 취하는 바, 디퍼드 거래를 큐 서버에 전달한 후 응답을 기다릴 필요없이 후속 프로세스를 진행할 수 있어 거래 신속성을 보장하고, 처리 부하를 낮출 수 있다.

다음으로, 거래 진행이 완료되면, 거래 요청 데이터를 이용하여 후처리 필터에 의해 후속 처리를 수행한다(440 단계). 본 발명의 일 실시예에 의하면, 후처리 필터에 디퍼드 거래 여부를 체크하는 필터를 추가함에 따라, 전처리에서 생성된 출금 거래 요청 데이터(도 6의 620) 및 입금 거래 요청 데이터(도 6의 630)의 디퍼드 거래 처리 대상인지 여부를 판단할 수 있다. 상술한 것처럼, 디퍼드 거래 처리 대상이 되는 거래는, 준실시간으로 처리되는 거래이지만 부하가 발생하는 경우로 설정될 수 있고, 해당 디퍼드 거래를 원 거래와 분리시켜 업무 처리가 가능하도록 구현할 수 있다.

일 실시예로서, 디퍼드 대상 확인을 위한 후처리 필터는 미리 정의된 필터 조건문 형태로 구현되고, 조건문에 설정된 조건들과 거래 요청 데이터의 파라미터값을 비교하게 된다(450 단계). 거래 요청 데이터가 미리 정의된 조건문에 부합할 경우 디퍼드 대상으로 판단하여 디퍼드 거래 처리를 위해 큐 서버로 송신되고(460 단계), 조건문에 부합하지 않는 경우에는 디퍼드 거래 대상이 아닌 것으로 판단하여, 디퍼드 거래 처리를 실시하지 않는다(470 단계).

여기서, 디퍼드 대상 확인을 위한 후처리 필터는 도 7에 도시된 조건문(720) 형태로 구현될 수 있다. 관리자는 디퍼드 거래 처리를 위해 필터링을 위한 조건문을 등록할 수 있고, 디퍼드 조건문은 데이터(620, 630)에 포함된 하나이상의 파라미터 값을 체크하는 방식으로 설정될 수 있다. 도 7을 참조하면, 일 실시예로서, 조건문(720)은 SPEL(Spring Expression Language)로 표현될 수 있고, dataSet.Account_AMT 파라미터의 값이 0이 아닌 제1 조건, ANTT_YN 파라미터의 값은 Y인 제2 조건, DEFERRED_YN 파라미터의 값은 Y가 아닌 제3 조건을 포함한다.

출금부(112)는 후처리 시에 출금 거래 요청 데이터(620) 및 입금 거래 요청 데이터(630)를 확인하여, 제1 내지 제3 조건을 만족하면 디퍼드 거래 처리 대상으로 보고 디퍼드 거래 처리의 후속 프로세스를 수행한다. 반대로, 출금부(112)가 출금 거래 요청 데이터(620) 및 입금 거래 요청 데이터(630)를 확인하여, 제1 내지 제3 조건을 만족하지 않는 것으로 판단한 경우에는, 디퍼드 거래 처리 대상이 아닌 것으로 판단하고, 후속 프로세스를 수행하지 않는다.

이처럼, 본 발명에 의한 거래 처리 방법은, 특정 거래를 분리하여 후행처리(지연처리)하기 위한 후처리 필터를 설정함으로써, 상시 감사가 필요한 고액거래 등 원하는 거래를 용이하게 필터링할 수 있고, 대량 처리 시에도 지연 시간을 최소화할 수 있다.

도 5는 본 발명의 일 실시예에 의한 디퍼드 거래 처리 방법을 설명하기 위한 순서도이다. 본 도면을 참조하여 설명하는 디퍼드 거래 처리 방법은, 제2 서버(120)가 제1 큐 서버(131)로부터 디퍼드 거래 처리 대상을 수신하여 디퍼드 거래를 처리하는 방법에 관한 것이다.

먼저, 제1 큐 서버(131)에서 대기중인 디퍼드 거래 처리 대상은 컨슈머(121)로 전달되고(510 단계), 컨슈머(121)가 디퍼드 거래 처리를 수행할지 여부를 판단한다. 일 실시예로서, 컨슈머(121)가 제1 큐 서버(131) 또는 제2 큐 서버(132)로부터 디퍼드 처리 대상을 가져오고, 프레임워크 서비스를 통해 해당 처리 대사에 대해 디퍼드 거래 처리를 수행할지 판단할 수 있다. 이하에서는, 컨슈머(121)가 디퍼드 거래 처리 여부를 판단하는 방법 및 판단 기준에 대해 더 상세히 설명하도록 한다.

먼저, 컨슈머(121)는 수신한 디퍼드 거래 처리 대상의 처리 횟수가 기준 횟수(예컨대, 3회)를 초과하는지 판단할 수 있다(520 단계). 디퍼드 거래 처리 대상은 재처리 프로세스에 의해 다시 수행되는 경우도 있으나, 무한 번 재처리를 수행할 수 없으므로, 처리 횟수가 기준 횟수 이상인 경우에는 어드민(admin) 계정에 의한 수동 처리가 가능하도록 분류한다(530 단계). 즉, 디퍼드 거래 처리 대상이 3회 이상 처리를 시도한 건이라면, 본 시스템에 의한 디퍼드 거래 처리가 어려운 대상이라고 판단하고 어드민 계정에 의해 수동 처리되도록 할 수 있다. 다른 실시예로서, 거래 대상이 기준 횟수 이상인 경우, 해당 거래를 별도 분류하여 다른 처리가 수행되도록 구현할 수 있다.

다음으로, 처리 횟수가 기준 횟수 이하인 경우에는, 거래로그의 유무를 확인하여 원거래의 정상종료 여부를 확인한다(540 단계). 이 때 거래로그는 DB(140)의 거래 로그 테이블에 저장된 로그를 말한다. 일 실시예로서, 거래로그가 존재하지 않거나 원 거래가 미완료 된 경우에는 에러로그의 유무를 확인할 수 있다(560 단계).

이 때, 에러로그가 존재한다면, 이는 디퍼드 처리 대상으로 판단하기에는 오류가 있는 상태이므로, 디퍼드 처리에 적합하지 않다고 판단하여 DB(140)의 디퍼드로그 테이블에 대상 거래의 상태값을 “대상 아님”으로 업데이트한다(565 단계). 반면, 에러로그가 없는 경우에는, 원거래가 종료되지 않은 것으로 판단하고 디퍼드 거래 처리를 재시도하기 위해 제2 큐 서버(132)에 재처리 요청을 송신할 수 있다(S41).

한편, 원거래 완료 여부 확인 단계(540 단계)에서, 원 거래가 완료된 경우에는 디퍼드 거래 처리를 수행하고, 그 결과 디퍼드 거래를 발생시켜 해당 업무 로직(business logic)이 실행되도록 할 수 있다(550 단계). 컨슈머(121)는 디퍼드 거래 처리를 결정하면, 디퍼드 처리를 위한 거래를 발생시켜 업무 로직 실행부(122)에 전달한다.

업무 로직 실행부(122)는 컨슈머(121)가 발생시킨 디퍼드 처리 거래에 따라, 업무 로직(business logic)을 실행하여 해당 거래를 처리하는 역할을 한다. 예를 들어, 업무 로직 실행부(122)는 디퍼드 처리 거래의 대상이 되는, 업무 로직을 호출하여 실행되도록 한다. 해당 로직의 실행이 완료되면 실행 결과에 대한 로그를 남길 수 있다.

일 실시예로서, 이체 거래의 경우, 컨슈머(121)가 출금 또는 입금 거래에 대해 총 계정 원장에 반영하는 디퍼드 처리 거래를 발생시켜 업무 로직 실행부(122)에 전달할 수 있다. 업무 로직 실행부(122)는 업무 로직을 실행한 후 DB(140)의 원장 테이블(총 계정 원장)에 디퍼드 처리된 거래를 갱신함으로써, 디퍼드 거래 처리 결과를 반영할 수 있다.

다음으로, 디퍼드 거래가 정상으로 종료되면, DB(140)의 디퍼드 로그 테이블에 대상 거래의 상태값을 ‘완료’로 업데이트한다(570, 580 단계). 도 8을 참조하면, 특정 로그(810)의 세부정보가 처리 횟수, 처리 상태를 포함할 수 있고, 완료 시에는 처리 상태 값이 S(성공, Success)로 기록될 수 있다(820). 만약 디퍼드 거래가 정상 종료되지 못한 경우에는, 디퍼드 로그 테이블에 대상 거래의 상태값을 ‘실패’로 업데이트하고, 재처리(S41)를 시도할 수 있다(590 단계). 다른 예로, 디퍼드 거래에 실패한 경우 수동 처리(530 단계)로 분류되도록 구현할 수도 있다.

이와 같이, 본 발명에 의하면, 디퍼드 거래 처리의 상태 및 결과를 세분화하여 판단함으로써, 디퍼드 거래 처리의 실패를 최소화하고, 원 거래와의 정합성을 보장할 수 있다.

본 명세서는 본 발명의 기술 사상을 예시적으로 설명한 것에 불과한 것으로서, 본 실시예가 속하는 기술 분야에서 통상의 지식을 가진 자라면 본 실시예의 본질적인 특성에서 벗어나지 않는 범위에서 다양한 수정 및 변형이 가능하다는 점을 이해할 것이다. 따라서, 본 실시예의 보호 범위는 이러한 실시예에 의하여 본 실시예의 기술 사상의 범위가 한정되는 것은 아니다. 본 실시예의 보호 범위는 아래의 청구범위에 의하여 해석되어야 하며, 그와 동등한 범위 내에 있는 모든 기술 사상은 본 실시예의 권리범위에 포함되는 것으로 해석되어야 할 것이다.

100: 금융 거래 처리 시스템 110: 제1 서버
111: 거래 수신부 112: 출금부
113: 입금부 114: 프로듀서
120: 제 2서버 121: 컨슈머
122: 업무 로직 실행부 130: 큐 서버
131: 제1 큐 서버 132: 제2 큐 서버
140: 데이터베이스(DB) 200: 네트워크
310, 320 : 사용자 단말

Claims (18)

1. 사용자 단말로부터 거래 요청을 수신하고, 수신한 거래 요청에 대해 디퍼드 거래 처리 대상 여부를 판단하여, 상기 거래 요청에 기초하여 생성된 거래 데이터를 송신하는 제1 서버;
   상기 제1 서버로부터 상기 거래 데이터를 수신하여, 대기 상태로 관리하는 제1 큐 서버;
   상기 제1 큐 서버로부터 대기 상태인 상기 거래 데이터를 수신하고, 제1 큐 서버로부터 수신한 거래 데이터에 대해 미리 정의된 판단기준에 따라 원 거래의 정상종료 여부를 확인하여 디퍼드 거래 처리를 수행하는 제2 서버; 및
   하나 이상의 로그 테이블을 포함하고, 상기 제1 서버로부터 수신한 원 거래에 대한 거래로그 및 상기 제2 서버로부터 수신한 상기 디퍼드 거래 처리에 대한 상태값을 나타내는 디퍼드로그를 각각의 로그 테이블에 기록하는 데이터베이스를 포함하는, 금융 거래 처리 시스템.
2. 제 1 항에 있어서,
   상기 제2 서버로부터 재처리 요청 및 재처리 대상 거래 데이터를 수신하는 제2 큐 서버를 더 포함하고,
   상기 제2 서버는 상기 제2 큐 서버에 포함된 재처리 대상 거래 데이터를 수신하여, 디퍼드 거래 처리를 재수행하는 것을 특징으로 하는, 금융 거래 처리 시스템.
3. 제 1 항에 있어서,
   상기 제1 서버는,
   상기 사용자 단말로부터 거래 요청을 수신하는 거래 수신부,
   수신한 거래 요청에 대해 원 거래를 수행하고, 상기 거래 요청을 기초로 생성한 거래 데이터의 전처리 및 후처리를 수행하고, 디퍼드 거래 처리 대상 여부를 판단하는 출금부 또는 입금부, 및
   상기 출금부 또는 입금부로부터 디퍼드 거래 처리 대상의 거래 데이터를 수신하여 상기 제1 큐 서버에 전달하는 프로듀서를 포함하는, 금융 거래 처리 시스템.
4. 제 3 항에 있어서,
   상기 출금부 또는 입금부는,
   상기 거래 수신부로부터 거래 요청을 수신하여, 상기 거래 데이터를 생성하고, 미리 정의된 필터와 상기 거래 데이터의 파라미터 값을 비교하여 디퍼드 거래 처리 대상 여부를 판단하는 것을 특징으로 하는, 금융 거래 처리 시스템.
5. 제 1 항에 있어서,
   상기 제 2 서버는,
   상기 제 1 큐 서버로부터 상기 거래 데이터를 수신하고, 상기 거래 데이터에 대해 미리 정의된 판단기준에 따라 디퍼드 거래 처리 여부를 판단하고, 디퍼드 거래를 발생시키는 컨슈머, 및
   상기 컨슈머에서 발생된 디퍼드 거래에 대응하는 업무 로직을 실행하는 업무 로직 실행부를 포함하는, 금융 거래 처리 시스템.
6. 제 5 항에 있어서,
   상기 판단기준은 처리 횟수에 대한 제1 판단기준, 원거래 완료 여부에 대한 제2 판단기준 및 에러로그 유무에 대한 제3 판단기준을 포함하는 것을 특징으로 하는, 금융 거래 처리 시스템.
7. 제 6 항에 있어서,
   상기 컨슈머는, 상기 제1 판단기준에 따라, 상기 처리 횟수가 미리 정의된 기준 횟수를 초과하는 경우 수동 처리되도록 분류하는 것을 특징으로 하는, 금융 거래 처리 시스템.
8. 제 6 항에 있어서,
   상기 컨슈머는, 상기 제2 판단기준에 따라, 거래로그의 유무를 판단하여 원거래 완료 여부를 판단하고, 원 거래 완료 시에는 상기 디퍼드 거래를 발생시키고, 원거래 미완료 시에는 상기 제3 판단기준에 따라 에러로그 유무를 판단하는 것을 특징으로 하는, 금융 거래 처리 시스템.
9. 제 6 항에 있어서,
   상기 컨슈머는, 상기 제3 판단기준에 따라, 에러로그가 존재하는 경우 상기 거래 데이터의 상태값을 ‘대상 아님’으로 업데이트하여 데이터베이스에 기록하고, 에러로그가 존재하지 않는 경우, 재처리요청을 수신하는 제2 큐 서버에 상기 거래 데이터를 전달하는 것을 특징으로 하는, 금융 거래 처리 시스템.
10. 제 5 항에 있어서,
    상기 업무 로직 실행부는, 상기 디퍼드 거래에 대응하는 업무 로직을 실행하고, 실행 결과를 상기 데이터베이스의 테이블에 업데이트하는 것을 특징으로 하는, 금융 거래 처리 시스템.
11. 하나 이상의 서버, 큐 서버 및 데이터베이스를 포함하는 금융 거래 처리 시스템에 의해 수행되는, 금융 거래 처리 방법으로서,
    사용자 단말로부터 거래 요청을 수신하는 단계;
    상기 거래 요청에 기초하여 생성된 거래 데이터에 대해, 미리 정의된 필터를 이용하여 디퍼드 거래 처리 대상 여부를 판단하는 단계;
    디퍼드 거래 처리 대상으로 판단된 경우, 상기 거래 데이터를 상기 큐 서버에 전달하는 단계; 및
    상기 큐 서버에 대기 상태인 상기 거래 데이터를 수신하여, 상기 거래 데이터에 대해 미리 정의된 판단기준에 따라 원 거래의 정상종료 여부를 확인하여 디퍼드 거래 처리를 수행하는 단계를 포함하고,
    상기 데이터베이스는 하나 이상의 로그 테이블을 포함하고, 상기 거래 요청에 대해 처리된 원 거래에 대한 거래로그 및 상기 디퍼드 거래 처리에 대한 상태값을 나타내는 디퍼드로그를 각각의 로그 테이블에 기록하는, 금융 거래 처리 방법.
12. 제 11 항에 있어서,
    상기 디퍼드 거래 처리 대상 여부를 판단하는 단계는, 미리 정의된 필터와 상기 거래 요청의 파라미터 값을 비교하여 디퍼드 거래 처리 대상 여부를 판단하는 것을 특징으로 하는, 금융 거래 처리 방법.
13. 제 11 항에 있어서,
    상기 디퍼드 거래 처리 단계를 수행하는 단계는,
    상기 큐 서버로부터 상기 거래 데이터를 수신하는 단계, 상기 판단기준에 따라 디퍼드 거래 처리 여부를 판단하여, 디퍼드 거래를 발생시키는 단계, 및 발생된 디퍼드 거래에 대응하는 업무 로직을 실행하는 단계를 포함하는 것을 특징으로 하는, 금융 거래 처리 방법.
14. 제 13 항에 있어서,
    상기 판단기준은 처리 횟수에 대한 제1 판단기준, 원거래 완료 여부에 대한 제2 판단기준 및 에러로그 유무에 대한 제3 판단기준을 포함하는 것을 특징으로 하는, 금융 거래 처리 방법.
15. 제 14 항에 있어서,
    상기 디퍼드 거래 처리를 수행하는 단계는, 상기 제1 판단기준에 따라, 상기 처리 횟수가 미리 정의된 기준 횟수를 초과하는 경우 수동 처리되도록 분류하는 것을 특징으로 하는, 금융 거래 처리 방법.
16. 제 14 항에 있어서,
    상기 디퍼드 거래 처리를 수행하는 단계는, 상기 제2 판단기준에 따라, 거래로그의 유무를 판단하여 원거래 완료 여부를 판단하고, 원 거래 완료 시에는 상기 디퍼드 거래를 발생시키고, 원거래 미완료 시에는 상기 제3 판단기준에 따라 에러로그 유무를 판단하는 것을 특징으로 하는, 금융 거래 처리 방법.
17. 제 14 항에 있어서,
    상기 디퍼드 거래 처리를 수행하는 단계는, 상기 제3 판단기준에 따라, 에러로그가 존재하는 경우 상기 거래 데이터의 상태값을 ‘대상 아님’으로 업데이트하여 데이터베이스에 기록하고, 에러로그가 존재하지 않는 경우, 재처리요청을 수신하는 제2 큐 서버에 상기 거래 데이터를 전달하는 것을 특징으로 하는, 금융 거래 처리 방법.
18. 제 13 항에 있어서,
    상기 업무 로직을 실행하는 단계는, 상기 디퍼드 거래에 대응하는 업무 로직을 실행하고, 실행 결과를 상기 데이터베이스의 테이블에 업데이트하는 것을 특징으로 하는, 금융 거래 처리 방법.

Images