IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ みずほ情報総研株式会社の特許一覧 ▶ 株式会社 みずほ銀行の特許一覧 ▶ 株式会社電通国際情報サービスの特許一覧

特開2022-103593与信管理システム、与信管理方法及び与信管理プログラム
<>
  • 特開-与信管理システム、与信管理方法及び与信管理プログラム 図1
  • 特開-与信管理システム、与信管理方法及び与信管理プログラム 図2
  • 特開-与信管理システム、与信管理方法及び与信管理プログラム 図3
  • 特開-与信管理システム、与信管理方法及び与信管理プログラム 図4
  • 特開-与信管理システム、与信管理方法及び与信管理プログラム 図5
  • 特開-与信管理システム、与信管理方法及び与信管理プログラム 図6
  • 特開-与信管理システム、与信管理方法及び与信管理プログラム 図7
  • 特開-与信管理システム、与信管理方法及び与信管理プログラム 図8
  • 特開-与信管理システム、与信管理方法及び与信管理プログラム 図9
  • 特開-与信管理システム、与信管理方法及び与信管理プログラム 図10
  • 特開-与信管理システム、与信管理方法及び与信管理プログラム 図11
  • 特開-与信管理システム、与信管理方法及び与信管理プログラム 図12
  • 特開-与信管理システム、与信管理方法及び与信管理プログラム 図13
  • 特開-与信管理システム、与信管理方法及び与信管理プログラム 図14
  • 特開-与信管理システム、与信管理方法及び与信管理プログラム 図15
  • 特開-与信管理システム、与信管理方法及び与信管理プログラム 図16
  • 特開-与信管理システム、与信管理方法及び与信管理プログラム 図17
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2022103593
(43)【公開日】2022-07-08
(54)【発明の名称】与信管理システム、与信管理方法及び与信管理プログラム
(51)【国際特許分類】
   G06Q 40/02 20120101AFI20220701BHJP
【FI】
G06Q40/02 300
【審査請求】有
【請求項の数】6
【出願形態】OL
(21)【出願番号】P 2020218325
(22)【出願日】2020-12-28
(11)【特許番号】
(45)【特許公報発行日】2022-01-31
(71)【出願人】
【識別番号】592131906
【氏名又は名称】みずほリサーチ&テクノロジーズ株式会社
(71)【出願人】
【識別番号】592052416
【氏名又は名称】株式会社 みずほ銀行
(71)【出願人】
【識別番号】397073201
【氏名又は名称】株式会社電通国際情報サービス
(74)【代理人】
【識別番号】100105957
【弁理士】
【氏名又は名称】恩田 誠
(74)【代理人】
【識別番号】100068755
【弁理士】
【氏名又は名称】恩田 博宣
(72)【発明者】
【氏名】鎌田 康太郎
(72)【発明者】
【氏名】藤本 典子
(72)【発明者】
【氏名】齋木 直也
(72)【発明者】
【氏名】小林 裕史
【テーマコード(参考)】
5L055
【Fターム(参考)】
5L055BB01
(57)【要約】
【課題】効率的かつ的確に信用リスクエクスポージャを計算して管理するための与信管理システム、与信管理方法及び与信管理プログラムを提供する。
【解決手段】管理サーバ20の制御部21が、フロントシステム10から、オンラインで取引情報を取得し、当日取引区分に関連付けて取引情報記憶部23に記録する。そして、フロントシステム10からリコンサイルファイルを取得し、リコンサイルファイルと取引情報記憶部23に記録された取引情報とを照合する。リコンサイルファイル及び取引情報記憶部23の双方に存在する取引情報であって、当日取引区分が新規の場合には、取引情報記憶部23に記録された取引情報をリコンサイルファイルの取引情報で置換し、当日取引区分が変更の場合には取引情報記憶部23に記録された取引情報を維持する。そして、取引情報記憶部23に記録された取引情報を用いて、信用リスクエクスポージャを計算する。
【選択図】図1
【特許請求の範囲】
【請求項1】
取引情報を記録する取引情報記憶部と、
信用リスクエクスポージャを管理する制御部とを備えた与信管理システムであって、
前記制御部が、
フロントシステムから、オンラインで取引情報を取得し、当日取引区分に関連付けて前記取引情報記憶部に記録し、
前記フロントシステムからリコンサイルファイルを取得し、
前記リコンサイルファイルと前記取引情報記憶部に記録された取引情報とを照合し、
前記リコンサイルファイル及び前記取引情報記憶部の双方に存在する取引情報であって、当日取引区分が新規の場合には、前記取引情報記憶部に記録された取引情報をリコンサイルファイルの取引情報で置換し、当日取引区分が変更の場合には前記取引情報記憶部に記録された取引情報を維持し、
前記取引情報記憶部に記録された取引情報を用いて、信用リスクエクスポージャを計算することを特徴とする与信管理システム。
【請求項2】
前記信用リスクエクスポージャの計算には、商品に応じて、カレントエクスポージャ方式と内部モデル方式が定められており、
前記制御部が、
前記フロントシステムからオンラインで、当日取引区分が新規の取引情報を取得した場合には、前記カレントエクスポージャ方式により前記信用リスクエクスポージャを計算して積み上げ、
オンライン終了後のバッチ処理で、前記内部モデル方式の商品種別について、前記内部モデル方式により、前記信用リスクエクスポージャを再計算して積み上げることを特徴とする請求項1に記載の与信管理システム。
【請求項3】
前記制御部が、
前記フロントシステムからオンラインで、当日取引区分が修正の取引情報を取得した場合には、前記カレントエクスポージャ方式により前記信用リスクエクスポージャを計算して積み上げ、
前記オンラインの終了後のバッチ処理で、前記内部モデル方式の商品種別について、修正されていない取引情報を用いて前記内部モデル方式により、信用リスクエクスポージャを計算するとともに、修正された取引情報を用いて前記カレントエクスポージャ方式により前記信用リスクエクスポージャを再計算して積み上げることを特徴とする請求項2に記載の与信管理システム。
【請求項4】
前記制御部が、
前記フロントシステムからオンラインで、当日取引区分が削除の取引情報を取得した場合には、前記カレントエクスポージャ方式の商品種別についてのみ削除し、
オンライン終了後のバッチ処理で、前記内部モデル方式の商品種別について、前記内部モデル方式により、前記信用リスクエクスポージャを再計算して積み上げることを特徴とする請求項2又は3に記載の与信管理システム。
【請求項5】
取引情報を記録する取引情報記憶部と、
信用リスクエクスポージャを管理する制御部とを備えた与信管理システムを用いて、与信管理を行なう方法であって、
前記制御部が、
フロントシステムから、オンラインで取引情報を取得し、当日取引区分に関連付けて前記取引情報記憶部に記録し、
前記フロントシステムからリコンサイルファイルを取得し、
前記リコンサイルファイルと前記取引情報記憶部に記録された取引情報とを照合し、
前記リコンサイルファイル及び前記取引情報記憶部の双方に存在する取引情報であって、当日取引区分が新規の場合には、前記取引情報記憶部に記録された取引情報をリコンサイルファイルの取引情報で置換し、当日取引区分が変更の場合には前記取引情報記憶部に記録された取引情報を維持し、
前記取引情報記憶部に記録された取引情報を用いて、信用リスクエクスポージャを計算することを特徴とする与信管理方法。
【請求項6】
取引情報を記録する取引情報記憶部と、
信用リスクエクスポージャを管理する制御部とを備えた与信管理システムを用いて、与信管理を行なうためのプログラムであって、
前記制御部を、
フロントシステムから、オンラインで取引情報を取得し、当日取引区分に関連付けて前記取引情報記憶部に記録し、
前記フロントシステムからリコンサイルファイルを取得し、
前記リコンサイルファイルと前記取引情報記憶部に記録された取引情報とを照合し、
前記リコンサイルファイル及び前記取引情報記憶部の双方に存在する取引情報であって、当日取引区分が新規の場合には、前記取引情報記憶部に記録された取引情報をリコンサイルファイルの取引情報で置換し、当日取引区分が変更の場合には前記取引情報記憶部に記録された取引情報を維持し、
前記取引情報記憶部に記録された取引情報を用いて、信用リスクエクスポージャを計算する手段として機能させることを特徴とする与信管理プログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、信用リスクエクスポージャを管理するための与信管理システム、与信管理方法及び与信管理プログラムに関する。
【背景技術】
【0002】
金融機関においては、与信相当額である信用リスクエクスポージャ(以下、エクスポージャ)を評価し、例えば、ヘッジ取引等のリスクヘッジを行なう。ここで、エクスポージャは、金融資産(ポートフォリオ)の中で、市場の価格変動のリスクがある資産の度合い(割合)である。また、自己資本比率規制に係るリスク計測関連規制の一つとして、デリバティブ取引の取引先(カウンターパーティ)に対する与信相当額を計算する。このため、金融機関のデリバティブ取引における取引先の与信相当額を計測するリスク管理システムが検討されている(例えば、特許文献1を参照)。この文献に記載された技術では、PFE(Potential Future Exposure)及び再構築コスト(RC)を算出して、PFEとRCに基づいて与信相当額(EAD)を算出する。
【先行技術文献】
【特許文献】
【0003】
【特許文献1】国際公開第2017/212651号
【発明の概要】
【発明が解決しようとする課題】
【0004】
取引を管理するフロントシステムに対して、エクスポージャを算出するためのバックエンドシステムを用いることがある。このバックエンドシステムでは、フロントシステムから取引情報を取得する、しかしながら、状況に応じて、バックエンドシステムで保有する取引情報と、フロントシステムで保有する取引情報とで差異が生じることがあり、それぞれの取引情報の突合作業の負担が大きい。また、エクスポージャを計量するための計算方式は複数種類あり、計算方式によって計算負荷が異なる。また、取引を行なう両当事者間で、債権(正の市場価値)と債務(負の市場価値)を差し引き計算(ネット・アウト)して、1本の債権(または債務)とするネッティング契約を結ぶこともある。この場合、取引当事者はネッティングによってエクスポージャを削減できる。このネッティングを考慮しなければ、的確なリスク管理が困難である。
【課題を解決するための手段】
【0005】
上記課題を解決する与信管理システムは、取引情報を記録する取引情報記憶部と、信用リスクエクスポージャを管理する制御部とを備える。そして、前記制御部が、フロントシステムから、オンラインで取引情報を取得し、当日取引区分に関連付けて前記取引情報記憶部に記録し、前記フロントシステムからリコンサイルファイルを取得し、前記リコンサイルファイルと前記取引情報記憶部に記録された取引情報とを照合し、前記リコンサイルファイル及び前記取引情報記憶部の双方に存在する取引情報であって、当日取引区分が新規の場合には、前記取引情報記憶部に記録された取引情報をリコンサイルファイルの取引情報で置換し、当日取引区分が変更の場合には前記取引情報記憶部に記録された取引情報を維持し、前記取引情報記憶部に記録された取引情報を用いて、信用リスクエクスポージャを計算する。
【発明の効果】
【0006】
本発明によれば、効率的かつ的確に信用リスクエクスポージャを計算して管理することができる。
【図面の簡単な説明】
【0007】
図1】実施形態のシステム概略図。
図2】実施形態のハードウェア構成例の説明図。
図3】実施形態の処理手順の説明図。
図4】実施形態の処理手順の説明図。
図5】実施形態のエクスポージャの計算例の説明図。
図6】実施形態の処理手順の説明図。
図7】実施形態のエクスポージャの計算例の説明図。
図8】実施形態の処理手順の説明図。
図9】実施形態のエクスポージャの計算例の説明図。
図10】実施形態の処理手順の説明図。
図11】実施形態の処理手順の説明図。
図12】実施形態の処理手順の説明図。
図13】実施形態のエクスポージャの計算例の説明図。
図14】実施形態の処理手順の説明図。
図15】実施形態のエクスポージャの計算例の説明図。
図16】実施形態の処理手順の説明図。
図17】実施形態のエクスポージャの計算例の説明図。
【発明を実施するための形態】
【0008】
以下、図1図17に従って、与信管理システム、与信管理方法及び与信管理プログラムを具体化した一実施形態を説明する。本実施形態では、バーゼル規制対応で適用している内部モデル方式としてPFE計量モデルを用いる。なお、内部モデル方式を用いない金融商品については、カレントエクスポージャ方式(CE方式)を適用する。
【0009】
PFE計量モデルでは、ネッティングした単位で、基準日(t=0)の時間を基点として、モンテカルロ方式で将来の時価分布をシミュレートする。そして、t=0から満期までの各t時点で上位95パーセンタイルの値を算出する。
【0010】
また、CE方式では、ネッティングセット「i」毎に、MtM値のネッティング及びNGR値によるアドオン値の調整が行なわれる。
〔CE〕=max[Σi〔MtM〕+Σi〔Add-On〕×Z,0]
〔Add-On〕=〔想定元本(受取側)〕×〔RWF〕
Z=0.4+0.6×〔NGR〕
【0011】
〔MtM〕(Mark to Market)は、各種金融商品の取引において、現在保有している資産(ポジション)を実際の市場価格(市場レート)で計算した時価(現在価値)である。
〔RWF〕(Risk Weighting Factor)は、各商品、通貨、期間毎のリスク掛け目である。
〔NGR〕(net-to-gross ratio)は、ネット再構築コストとグロス再構築コストの比率であり、下記のNGR計算式により算出される。
〔NGR〕=max[Σi〔MtM〕,0]/Σi max(〔MtM〕,0)
【0012】
図1に示すように、本実施形態では、ネットワークを介して接続されたフロントシステム10、管理端末15、管理サーバ20を用いる。
【0013】
(ハードウェア構成例)
図2は、フロントシステム10、管理端末15、管理サーバ20等として機能する情報処理装置H10のハードウェア構成例である。
【0014】
情報処理装置H10は、通信装置H11、入力装置H12、表示装置H13、記憶部H14、プロセッサH15を有する。なお、このハードウェア構成は一例であり、他のハードウェアを有していてもよい。
【0015】
通信装置H11は、他の装置との間で通信経路を確立して、データの送受信を実行するインターフェースであり、例えばネットワークインターフェースや無線インターフェース等である。
【0016】
入力装置H12は、ユーザの入力を受け付ける装置であり、例えばマウスやキーボード等である。
表示装置H13は、各種情報を表示するディスプレイやタッチパネル等である。
【0017】
記憶部H14は、フロントシステム10、管理端末15、管理サーバ20の各種機能を実行するためのデータや各種プログラムを格納する記憶装置である。記憶部H14の一例としては、ROM、RAM、ハードディスク等がある。
【0018】
プロセッサH15は、記憶部H14に記憶されるプログラムやデータを用いて、フロントシステム10、管理端末15、管理サーバ20における各処理を制御する。プロセッサH15の一例としては、例えばCPUやMPU等がある。このプロセッサH15は、ROM等に記憶されるプログラムをRAMに展開して、各種処理に対応する各種プロセスを実行する。例えば、プロセッサH15は、フロントシステム10、管理端末15、管理サーバ20のアプリケーションプログラムが起動された場合、後述する各処理を実行するプロセスを動作させる。
【0019】
プロセッサH15は、自身が実行するすべての処理についてソフトウェア処理を行なうものに限られない。例えば、プロセッサH15は、自身が実行する処理の少なくとも一部についてハードウェア処理を行う専用のハードウェア回路(例えば、特定用途向け集積回路:ASIC)を備えてもよい。すなわち、プロセッサH15は、(1)コンピュータプログラム(ソフトウェア)に従って動作する1つ以上のプロセッサ、(2)各種処理のうち少なくとも一部の処理を実行する1つ以上の専用のハードウェア回路、或いは(3)それらの組み合わせ、を含む回路(circuitry)として構成し得る。プロセッサH15は、CPU並びに、RAM及びROM等のメモリを含み、メモリは、処理をCPUに実行させるように構成されたプログラムコード又は指令を格納している。メモリすなわちコンピュータ可読媒体は、汎用又は専用のコンピュータでアクセスできるあらゆる利用可能な媒体を含む。
【0020】
(各情報処理装置の構成)
図1を用いて、フロントシステム10、管理端末15、管理サーバ20の構成を説明する。
【0021】
フロントシステム10は、デリバティブ等の各種取引を行なう銀行(金融機関)の各拠点のコンピュータシステムである。フロントシステム10は、取引データ記憶部12を備える。
【0022】
取引データ記憶部12には、フロントシステム10に入力された取引についての新規約定、取引修正、取引削除に関するデータが記録される。
フロントシステム10は、新規約定、取引修正、取引削除等が発生した時に、取引明細を含めたI/Fデータ(取引情報)を生成し、リアルタイムで管理サーバ20に送信する。
【0023】
そして、フロントシステム10は、営業日の日締め処理後に、リコンサイルファイル、PFE計量用データを生成し、管理サーバ20に送信する。リコンサイルファイルには、フロントシステム10の取引データ記憶部12に記録された当日の取引に関するデータ(新規、修正、削除)に関する取引明細が含まれる。また、PFE計量用データには、PFE計量に必要となる項目に関するデータが含まれる。
【0024】
管理端末15は、管理サーバ20の担当者が用いるコンピュータ端末である。この管理端末15を用いて、通常の新規取引の他、与信枠確保取引や事前入力取引等を入力する。
【0025】
管理サーバ20は、与信管理を行なうコンピュータシステムである。フロントシステム10・管理サーバ20間の取引インターフェースは、新規取引の入力、修正及び削除時のみに実施される。このため、I/Fエラーの発生や管理サーバ20上での取引修正の場合には、フロントシステム10・管理サーバ20間のデータに不整合が生じる。データの整合性を担保するため、管理サーバ20で管理する取引情報を日次での置き換えを実施する。
この管理サーバ20は、制御部21、商品情報記憶部22、取引情報記憶部23、与信情報記憶部24、断面情報記憶部25を備える。
【0026】
制御部21は、与信管理プログラムを実行することにより、取得部211、照合部212、計算部213として機能する。
取得部211は、フロントシステム10、管理端末15から、与信管理のための各種データを取得する処理を実行する。
照合部212は、フロントシステム10から取得したリコンサイルファイルを用いて、取引情報記憶部23に記録された取引情報と照合する処理を実行する。そして、照合部212は、照合結果に応じて、取引情報記憶部23に記録された情報を更新する処理を実行する。
計算部213は、エクスポージャを管理するための計算処理を実行する。
【0027】
商品情報記憶部22には、取引種別毎に計算方針についての商品管理レコードが記録される。商品管理レコードは、取引種別に応じた計算方針が登録された場合に記録される。この商品管理レコードには、取引種別、計算方針に関するデータが記録される。
【0028】
取引種別データ領域には、取引の種類を特定するための識別子に関するデータが記録される。取引種別としては、例えば、金利スワップ取引、通貨スワップ取引、FX取引(外国為替証拠金取引)、レポ取引等を用いる。
【0029】
計算方針データ領域には、エクスポージャを算出するための計算方式を特定するための識別子に関するデータが記録される。本実施形態では、計算方式として、「PFE」及び「CE」の何れかを用いる。
【0030】
取引情報記憶部23には、エクスポージャを計算するために必要な取引明細についての取引管理レコードからなる取引情報テーブルが記録される。本実施形態では、フロントシステム10から取得したI/Fデータ、管理端末15から取得した画面入力データが記録される。取引管理レコードには、取引識別子、取引日、拠点、商品種別、想定元本、ネッティングセット、当日取引区分、発生タイミングに関するデータが記録される。
【0031】
取引識別子データ領域には、各取引を特定するための識別子に関するデータが記録される。
取引日データ領域には、この取引が行なわれた年月日に関するデータが記録される。
【0032】
拠点データ領域には、この取引が行なわれた拠点を特定するための識別子に関するデータが記録される。
商品種別データ領域には、この取引の商品種別を特定するための識別子に関するデータが記録される。
【0033】
想定元本データ領域には、この取引で実際に受け渡しするキャッシュ・フローを計算するために必要な想定元本(契約額)に関するデータが記録される。
ネッティングセットデータ領域には、ネッティングを行なう取引を特定するためのネッティング条件を特定するための識別子に関するデータが記録される。
【0034】
当日取引区分データ領域には、この取引のステータスを特定するためのフラグが記録される。当日取引区分としては、「既存」、「新規」、「既存修正」、「修正」、「削除」等がある。「既存」は約定済みの取引を示す。「新規」は取引の新規入力を示す。「既存修正」は修正前の既存取引(約定済み)を示す。「修正」、「削除」は、それぞれ、修正、削除された取引を示す。
【0035】
発生タイミングデータ領域には、管理サーバ20に入力されるタイミングと、締め時刻との関係を特定するためのフラグが記録される。発生タイミングとしては、「インタイム」、「アフター」がある。「インタイム」はフロントシステムのシステムオープンから日締め処理の実施までを示す。「アフター」は日締め処理の実施後から次のシステムオープンまでを示す。
【0036】
与信情報記憶部24には、エクスポージャを計算した与信管理レコードが記録される。
与信管理レコードには、取引識別子、PFE値、CE値、計算方針に関するデータが記録される。
【0037】
取引識別子データ領域には、各取引を特定するための識別子に関するデータが記録される。
PFE値データ領域には、PFE計量モデルにより算出したエクスポージャに関するデータが記録される。
【0038】
CE値データ領域には、CE計量モデルにより算出したエクスポージャに関するデータが記録される。
計算方針データ領域には、エクスポージャを算出する計算方式を特定するためのフラグが記録される。このデータ領域には、「PFE」、「CE」、「CE(PFE対象)」の何れかのフラグが記録される。ここで、「CE(PFE対象)」は、本来、PFE計量モデルを用いて計算する商品種別において、CE計量モデルにより算出したことを示す。
【0039】
断面情報記憶部25には、営業日毎に断面ファイルが記録される。断面ファイルは、日次バッチ処理を行なった場合に記録される。この断面ファイルには、日次バッチ処理時のエクスポージャのイメージデータが記録される。
【0040】
次に、上述したシステムを用いた情報処理を説明する。本実施形態では、与信管理処理の概要、オンライン処理(新規、修正、削除)、リコンサイル処理、置換処理、日次バッチ処理(新規、修正、既存削除)の順番に説明する。
【0041】
(与信管理処理の概要)
図3を用いて、与信管理処理の概要を説明する。
まず、管理サーバ20の制御部21は、オンライン処理を実行する(ステップS101)。このオンライン処理は、管理サーバ20のシステムオープンからクローズまでの「オンライン中」に行なわれる。そして、オンライン当日を「T日」、システムクローズ~日締め処理後のシステムオープンまでを「T+1日」と呼ぶ。具体的には、制御部21の取得部211は、フロントシステム10に取引情報が記録された場合、I/Fデータを取得し、取引情報記憶部23に記録する。また、管理サーバ20は、管理端末15から画面入力データを取得した場合にも、取引情報記憶部23に記録する。そして、リアルタイムでエクスポージャの計算を行なう。詳細は、図4図6を用いて説明する。
【0042】
そして、締め時刻が到来した場合、管理サーバ20の制御部21は、日次バッチ処理を実行する(ステップS102)。具体的には、制御部21の取得部211は、締め時刻になった場合、フロントシステム10からリコンサイルファイル、PFE計量用データを取得する。そして、差異明細を特定し、エクスポージャの再計算を行なう。詳細は、図7図11を用いて説明する。
【0043】
(オンライン処理(新規取引))
次に、図4を用いて、オンライン処理(新規取引)を説明する。ここでは、フロントシステム10において、新規取引についての取引情報が取引データ記憶部12に記録された場合を想定する。この処理は、締め時刻のインタイム及びアフターで共通する。
【0044】
ここでは、管理サーバ20の制御部21は、新規取引情報の取得処理を実行する(ステップS201)。具体的には、制御部21の取得部211は、フロントシステム10から、新規取引についてのI/Fデータを取得する。
【0045】
次に、管理サーバ20の制御部21は、ネッティング対象があるかどうかについての判定処理を実行する(ステップS202)。具体的には、制御部21の計算部213は、I/Fデータの取引明細のネッティングセット(ネッティング条件)を特定する。そして、ネッティングセットが一致する取引が取引情報記憶部23に記録されているかどうかを確認する。
【0046】
ネッティングセットが一致する取引が、取引情報記憶部23に記録されており、ネッティング対象があると判定した場合(ステップS202において「YES」の場合)、管理サーバ20の制御部21は、NGR計算済かどうかについての判定処理を実行する(ステップS203)。具体的には、制御部21の計算部213は、ネッティングセットに関連付けられて、日次バッチ処理で計算されたNGR値が断面情報記憶部25に記録されているかどうかを確認する。断面情報記憶部25に、ネッティングセットに関連付けられたNGR値が記録されている場合には、NGR計算済と判定する。
NGR計算済と判定した場合(ステップS203において「YES」の場合)、管理サーバ20の制御部21は、NGR取得処理を実行する(ステップS204)。具体的には、制御部21の計算部213は、断面情報記憶部25に記録されたNGR値を取得する。
【0047】
一方、NGR計算済でないと判定した場合(ステップS203において「NO」の場合)、管理サーバ20の制御部21は、NGR計算処理を実行する(ステップS205)。具体的には、制御部21の計算部213は、ネッティングセットに属する取引情報を取得する。そして、計算部213は、取得した取引情報を、NGR計算式に適用して、NGR値を算出する。
なお、ネッティングセットが一致する取引が、取引情報記憶部23に記録されておらず、ネッティング対象がないと判定した場合(ステップS202において「NO」の場合)、管理サーバ20の制御部21は、ステップS203~S205をスキップする。この場合には、「NGR=1」を用いることにより、ネッティングの影響を排除する。
【0048】
次に、管理サーバ20の制御部21は、CE計算処理を実行する(ステップS206)。具体的には、制御部21の計算部213は、いずれの商品種別についても、CE計量モデルを用いて、エクスポージャを算出する。このCE計量モデルでは、ネッティングセット「i」毎に、MtM値のネッティング及びNGR値によるアドオン値の調整が行なわれる。
【0049】
次に、管理サーバ20の制御部21は、エクスポージャ積上処理を実行する(ステップS207)。具体的には、制御部21の計算部213は、算出したCE値を含めた与信管理レコードを生成し、与信情報記憶部24に記録する。ここで、商品情報記憶部22において、計算方式として「PFE」が記録されている場合には、与信管理レコードの計算方針データ領域に「CE(PFE対象)」を記録する。この場合、計算部213は、与信情報記憶部24に記録された与信管理レコードのPFE値、CE値を、それぞれ合計して、エクスポージャを算出する。
【0050】
図5に示すように、取引識別子「3」、「4」の新規取引についての取引管理レコード230が取引情報記憶部23に記録された場合、CE計量モデルにより算出されたCE値を含む与信管理レコード240を生成する。
【0051】
(オンライン処理(取引修正))
次に、図6を用いて、オンライン処理(取引修正)を説明する。フロントシステム10において、既存取引の修正情報が取引データ記憶部12に記録された場合を想定する。この処理は、締め時刻のインタイム及びアフターで共通する。
【0052】
ここでは、管理サーバ20の制御部21は、修正情報の取得処理を実行する(ステップS301)。具体的には、制御部21の取得部211は、フロントシステム10から、取引の修正についてのI/Fデータを取得する。
【0053】
次に、管理サーバ20の制御部21は、ステップS202と同様に、ネッティング対象があるかどうかについての判定処理を実行する(ステップS302)。
ネッティング対象がないと判定した場合(ステップS302において「NO」の場合)、管理サーバ20の制御部21は、ステップS205と同様に、NGR計算処理を実行する(ステップS303)。
【0054】
一方、ネッティング対象があると判定した場合(ステップS302において「YES」の場合)、管理サーバ20の制御部21は、NGR計算処理(ステップS303)をスキップする。この場合には、日次バッチ処理で計算したNGR値を使用する。また、新規取引がネッティング対象でない場合には、「NGR=1」を用いる。
【0055】
次に、管理サーバ20の制御部21は、CE計算対象かどうかについての判定処理を実行する(ステップS304)。具体的には、制御部21の計算部213は、商品情報記憶部22を用いて、I/Fデータの取引明細の商品種別に応じて計算方法を特定する。
【0056】
CE計算対象と判定した場合(ステップS304において「YES」の場合)、管理サーバ20の制御部21は、CE修正計算処理を実行する(ステップS305)。具体的には、制御部21の計算部213は、I/Fデータにおいて修正された想定元本を用いて、CE計量モデルにより、CE値を算出する。次に、計算部213は、I/Fデータの取引識別子が記録された与信管理レコードを与信情報記憶部24から取得する。そして、計算部213は、与信管理レコードに記録されたCE値を、新たに算出したCE値に更新する。
【0057】
一方、CE計算対象でないと判定した場合(ステップS304において「NO」の場合)、管理サーバ20の制御部21は、CE計算処理を実行する(ステップS306)。具体的には、制御部21の計算部213は、PFE計算対象について、I/Fデータにおいて修正された想定元本を用いて、CE計量モデルにより、CE値を計算する。
【0058】
次に、管理サーバ20の制御部21は、エクスポージャ積上処理を実行する(ステップS307)。具体的には、制御部21の計算部213は、新たに算出したCE値を記録した与信管理レコードを生成し、与信情報記憶部24に記録する。従って、PFE対象の場合、日次バッチ処理で算出した前日PFE値にCE値を加算することになる。
【0059】
図7に示すように、PFE対象の商品種別の取引識別子「2」、「3」の取引についての修正情報を取得した場合、取引識別子「2’」、「3’」の取引管理レコード230を生成する。この場合、与信管理レコード240において、これらのPFE値はそのまま維持される。更に、取引識別子「2’」、「3’」について、CE計量モデルにより算出されたCE値を含む与信管理レコード240を生成する。また、CE対象の商品種別の取引識別子「4」の取引についての修正情報を取得した場合、与信管理レコード240において、CE計量モデルにより算出されたCE値に修正する。
【0060】
(オンライン処理(取引削除))
次に、図8を用いて、オンライン処理(取引削除)を説明する。フロントシステム10において、既存取引の削除情報が取引データ記憶部12に記録された場合を想定する。この処理は、締め時刻のインタイム及びアフターで共通する。
【0061】
ここでは、管理サーバ20の制御部21は、削除情報の取得処理を実行する(ステップS401)。具体的には、制御部21の計算部213は、フロントシステム10から、既存取引の削除についてのI/Fデータを取得する。
【0062】
次に、管理サーバ20の制御部21は、ステップS304と同様に、CE計算対象かどうかについての判定処理を実行する(ステップS402)。
CE計算対象と判定した場合(ステップS402において「YES」の場合)、管理サーバ20の制御部21は、削除処理を実行する(ステップS403)。具体的には、制御部21の計算部213は、I/Fデータの取引識別子が記録された与信管理レコードを与信情報記憶部24から取得する。そして、計算部213は、与信情報記憶部24から、与信管理レコードを削除する。
【0063】
一方、CE計算対象でないと判定した場合(ステップS402において「NO」の場合)、管理サーバ20の制御部21は、削除処理(ステップS403)をスキップする。この場合、日次バッチ処理のタイミングで、この取引のエクスポージャを「0」にする。
【0064】
図9に示すように、PFE対象の商品種別の取引識別子「2」~「4」の取引についての削除情報を取得した場合、与信管理レコード240において、これらのPFE値はそのまま維持される。一方、取引識別子「5」について、CE計量モデルにより算出されたCE値を含む与信管理レコード240を生成する。また、CE対象の商品種別の取引識別子「5」の取引についての削除情報を取得した場合、与信管理レコード240においてCE値を削除する。ここで、「10※」は削除を意味する。
【0065】
(リコンサイル処理)
図10を用いて、リコンサイル処理を説明する。この処理は、フロントシステム10の日締め処理後に行なわれる。
【0066】
ここでは、管理サーバ20の制御部21は、締め時情報の取得処理を実行する(ステップS501)。具体的には、制御部21の取得部211は、フロントシステム10からリコンサイルファイル、PFE計量用データを取得する。
【0067】
次に、管理サーバ20の制御部21は、取引情報テーブルの取得処理を実行する(ステップS502)。具体的には、制御部21の照合部212は、取引情報記憶部23から、当日の取引情報テーブルを取得する。
【0068】
次に、管理サーバ20の制御部21は、リコンサイルファイルとの差異の特定処理を実行する(ステップS503)。具体的には、制御部21の照合部212は、フロントシステム10から取得したリコンサイルファイルの取引明細と、取引情報テーブルの取引明細とを比較する。そして、照合部212は、差異明細を特定する。差異明細が生じる場合としては、(a)リコンサイルファイルと取引情報テーブルとの双方に取引情報が存在する場合、(b)取引情報テーブルにのみ取引情報が存在する場合、(c)リコンサイルファイルにのみ取引情報が存在する場合がある。
【0069】
次に、管理サーバ20の制御部21は、置換処理を実行する(ステップS504)。この処理については、図11を用いて説明する。
次に、管理サーバ20の制御部21は、当日取引区分の更新処理を実行する(ステップS505)。具体的には、制御部21の照合部212は、取引情報記憶部23に記録された取引情報テーブルの当日取引区分として「なし」を記録する。
【0070】
次に、管理サーバ20の制御部21は、計量処理を実行する(ステップS506)。具体的には、制御部21の計算部213は、取引情報記憶部23に記録された取引情報を用いてエクスポージャを算出する。この処理については、図12図17を用いて説明する。
【0071】
次に、管理サーバ20の制御部21は、断面情報反映処理を実行する(ステップS507)。具体的には、制御部21の計算部213は、取引情報記憶部23及び与信情報記憶部24の断面ファイルを生成し、当日日付に関連付けて、断面情報記憶部25に記録する。更に、計算部213は、日次バッチ処理で計算したNGR値を、ネッティングセットに関連付けて断面情報記憶部25に記録する。
【0072】
(置換処理)
次に、図11を用いて、置換処理を説明する。この処理は、各取引情報を処理対象として特定して、順次、繰り返す。
【0073】
ここでは、管理サーバ20の制御部21は、場合分け処理を実行する(ステップS601)。具体的には、制御部21の照合部212は、上述したように、差異明細を以下の3つに場合分けを行なう。
(a)リコンサイルファイルと取引情報テーブルとの双方に取引情報が存在する場合
(b)取引情報テーブルにのみ取引情報が存在する場合
(c)リコンサイルファイルにのみ取引情報が存在する場合
【0074】
ステップS601において、「(a)双方に存在する」と判定した場合、管理サーバ20の制御部21は、当日取引区分が置換対象かどうかについての判定処理を実行する(ステップS602)。具体的には、制御部21の照合部212は、取引情報テーブルの当日取引区分を確認する。そして、当日取引区分が「なし」又は「新規」の場合には、置換対象と判定する。一方、当日取引区分が変更(「修正」又は「削除」)の場合には、置換対象でないと判定する。
【0075】
置換対象と判定した場合(ステップS602において「YES」の場合)、管理サーバ20の制御部21は、リコンサイルファイルによる置換処理を実行する(ステップS603)。具体的には、制御部21の照合部212は、取引情報記憶部23に記録された取引情報テーブルの取引情報を、リコンサイルファイルに記録された取引情報で置き換える。
【0076】
一方、置換対象でないと判定した場合(ステップS602において「NO」の場合)、管理サーバ20の制御部21は、リコンサイルファイルによる置換処理(ステップS603)をスキップする。この場合、取引情報記憶部23に記録された取引情報テーブルの取引情報をそのまま維持する。
【0077】
ステップS601において、「(b)取引情報テーブルのみに存在する」と判定した場合、管理サーバ20の制御部21は、当日取引区分が置換対象かどうかについての判定処理を実行する(ステップS604)。具体的には、制御部21の照合部212は、取引情報テーブルの当日取引区分を確認する。そして、当日取引区分が「なし」の場合には、置換対象と判定する。一方、当日取引区分が「新規」、「修正」、「削除」の何れかの場合には、置換対象でないと判定する。
【0078】
当日取引区分が置換対象と判定した場合(ステップS604において「YES」の場合)、管理サーバ20の制御部21は、ステップS603と同様に、リコンサイルファイルによる置換処理を実行する(ステップS605)。具体的には、制御部21の照合部212は、取引情報テーブルのみに記録されている取引情報を、リコンサイルファイルの取引情報で置き換える。これにより、リコンサイルファイルと同様に、取引情報が存在しない状態、すなわち取引情報の削除を行なう。
【0079】
一方、当日取引区分が置換対象でないと判定した場合(ステップS604において「NO」の場合)、管理サーバ20の制御部21は、リコンサイルファイルによる置換処理(ステップS605)をスキップする。この場合も、取引情報記憶部23に記録された取引情報テーブルの取引情報をそのまま維持する。
【0080】
ステップS601において、「(c)リコンサイルファイルのみに存在する」と判定した場合、管理サーバ20の制御部21は、当日取引区分が置換対象かどうかについての判定処理を実行する(ステップS606)。具体的には、制御部21の照合部212は、取引情報テーブルの当日取引区分を確認する。そして、当日取引区分が「新規」又は「修正」の場合には、置換対象と判定する。一方、当日取引区分が「削除」の場合には、置換対象でないと判定する。
【0081】
置換対象と判定した場合(ステップS606において「YES」の場合)、管理サーバ20の制御部21は、ステップS603と同様に、リコンサイルファイルによる置換処理を実行する(ステップS607)。
【0082】
一方、置換対象でないと判定した場合(ステップS606において「NO」の場合)、管理サーバ20の制御部21は、リコンサイルファイルによる置換処理(ステップS607)をスキップする。この場合、取引情報記憶部23に記録された取引情報テーブルの取引情報をそのまま維持する。すなわち、当日取引区分が「削除」の場合、取引情報テーブルがそのまま維持される。
以上の処理を、すべての取引について繰り返す。
【0083】
(日次バッチ処理(新規取引))
次に、図12を用いて、日次バッチで行なわれる日次バッチ処理(新規取引)を説明する。
【0084】
まず、ネッティングセット毎に、処理対象のネッティングセットを特定し、以下の処理を繰り返す。
ここでは、管理サーバ20の制御部21は、グループに属する取引情報の特定処理を実行する(ステップS701)。具体的には、制御部21の計算部213は、取引情報記憶部23の取引情報テーブルを用いて、処理対象のネッティングセットが記録された取引管理レコードを特定する。
【0085】
次に、管理サーバ20の制御部21は、インタイムかどうかについての判定処理を実行する(ステップS702)。具体的には、制御部21の計算部213は、取引管理レコードの発生タイミング情報により、インタイム又はアフターの何れかを判定する。
【0086】
インタイムと判定した場合(ステップS702において「YES」の場合)、管理サーバ20の制御部21は、PFE対象かどうかについての判定処理を実行する(ステップS703)。具体的には、制御部21の計算部213は、取引管理レコードの商品種別について、商品情報記憶部22を用いて計算方針を特定する。
【0087】
計算方針が「PFE」と判定した場合(ステップS703において「YES」の場合)、管理サーバ20の制御部21は、既存取引を含めてPFE計算処理を実行する(ステップS704)。具体的には、制御部21の計算部213は、同じネッティングセットに属する取引情報及びPFE計量用データを、PFE計量モデルに適用してPFE値を算出する。
【0088】
発生タイミングが「アフター」であり、インタイムでないと判定した場合や、PFE対象でないと判定した場合(ステップS702,S703において「NO」の場合)、管理サーバ20の制御部21は、ステップS205と同様に、NGR計算処理を実行する(ステップS705)。
次に、管理サーバ20の制御部21は、ステップS206と同様に、CE計算処理を実行する(ステップS706)。
【0089】
次に、管理サーバ20の制御部21は、当日取引区分変更処理を実行する(ステップS707)。具体的には、制御部21の計算部213は、取引情報記憶部23の取引情報テーブルの取引管理レコードの当日取引区分を、「新規」を「既存」に更新する。
以上の処理を、すべてのネッティングセットについて終了するまで繰り返す。
【0090】
次に、管理サーバ20の制御部21は、ステップS207と同様に、エクスポージャ積上処理を実行する(ステップS708)。
【0091】
図13に示すように、取引識別子「3」、「4」の取引管理レコード230の当日取引区分を「既存」に変更する。そして、PFE対象の商品種別の取引識別子「3」は、ネッティングセット「a」に基づいて、PFE計量モデルにより、PFE値が再計算されて、与信管理レコード240のPFE値を更新する。また、CE対象の商品種別の取引識別子「4」の取引の与信管理レコード240について、CE計量モデルにより算出されたCE値を記録する。
【0092】
(日次バッチ処理(取引修正))
次に、図14を用いて、日次バッチで行なわれる日次バッチ処理(取引修正)を説明する。
【0093】
まず、ネッティングセット毎に、処理対象のネッティングセットを特定し、以下の処理を繰り返す。
そして、管理サーバ20の制御部21は、ステップS701、S702と同様に、グループに属する取引情報の特定処理(ステップS801)、インタイムかどうかについての判定処理(ステップS802)を実行する。
【0094】
インタイムと判定した場合(ステップS802において「YES」の場合)、管理サーバ20の制御部21は、ステップS703と同様に、PFE対象かどうかについての判定処理を実行する(ステップS803)。
【0095】
PFE対象と判定した場合(ステップS803において「YES」の場合)、管理サーバ20の制御部21は、修正がない取引情報を用いて、PFE計算処理を実行する(ステップS804)。具体的には、制御部21の計算部213は、ネッティングセットに属し、修正情報が記録されていない取引情報及びPFE計量用データを、PFE計量モデルに適用してPFE値を算出する。
【0096】
次に、管理サーバ20の制御部21は、修正された取引情報を用いて、NGR計算処理を実行する(ステップS805)。具体的には、制御部21の計算部213は、修正された取引情報を、NGR計算式に適用してNGR値を算出する。
【0097】
次に、管理サーバ20の制御部21は、修正された取引情報を用いて、CE計算処理を実行する(ステップS806)。具体的には、制御部21の計算部213は、修正された取引情報、ステップS805において算出したNGR値を、CE計量モデルに適用してCE値を算出する。
【0098】
次に、管理サーバ20の制御部21は、当日取引区分変更処理を実行する(ステップS807)。具体的には、制御部21の計算部213は、取引情報記憶部23の取引情報テーブルの当日取引区分の「修正」を「既存」に更新する。
【0099】
インタイムでないと判定した場合や、PFE対象でないと判定した場合(ステップS802,S803において「NO」の場合)、管理サーバ20の制御部21は、NGR計算処理を実行する(ステップS808)。具体的には、制御部21の計算部213は、ネッティングセットに属する取引情報を、NGR計算式に適用して、NGR値を算出する。
【0100】
次に、管理サーバ20の制御部21は、CE計算処理を実行する(ステップS809)。具体的には、制御部21の計算部213は、ネッティングセットに属する取引情報、ステップS808において算出したNGR値を、CE計量モデルに適用して、エクスポージャを算出する。
以上の処理を、すべてのネッティングセットについて終了するまで繰り返す。
【0101】
次に、管理サーバ20の制御部21は、ステップS207と同様に、エクスポージャ積上処理を実行する(ステップS810)。
【0102】
図15に示すように、取引識別子「2’」、「3’」の取引管理レコード230の当日取引区分を「既存」に変更する。そして、PFE対象の商品種別の取引識別子「2」、「3」を除いて、ネッティングセット「a」に基づいて、PFE計量モデルにより、PFE値が再計算されて、与信管理レコード240のPFE値に更新する。この場合、取引識別子「2’」、「3’」について、CE計量モデルにより算出されたCE値を含む与信管理レコード240を記録する。また、CE対象の商品種別の取引識別子「4’」の取引の与信管理レコード240について、CE計量モデルにより算出されたCE値を記録する。
【0103】
(日次バッチ処理(取引削除))
次に、図16を用いて、日次バッチで行なわれる日次バッチ処理(取引削除)を説明する。
【0104】
ここでは、管理サーバ20の制御部21は、削除処理を実行する(ステップS901)。具体的には、制御部21の計算部213は、取引情報記憶部23の取引情報テーブルに記録された取引管理レコードを削除する。
【0105】
まず、削除した取引情報が属するネッティングセット毎に、処理対象グループを特定し、以下の処理を繰り返す。
ここでは、管理サーバ20の制御部21は、ステップS701,S703と同様に、グループに属する取引情報の特定処理(ステップS902)、PFE対象かどうかについての判定処理(ステップS903)を実行する。
【0106】
PFE対象と判定した場合(ステップS903において「YES」の場合)、管理サーバ20の制御部21は、PFE計算処理を実行する(ステップS904)。具体的には、制御部21の計算部213は、ネッティングセットに属し、削除されていない取引情報及びPFE計量用データを、PFE計量モデルに適用してエクスポージャを算出する。
【0107】
一方、PFE対象でないと判定した場合(ステップS903において「NO」の場合)、管理サーバ20の制御部21は、NGR計算処理を実行する(ステップS905)。具体的には、制御部21の計算部213は、取引情報テーブルに残っている取引情報を、NGR計算式に適用してNGR値を算出する。
【0108】
次に、管理サーバ20の制御部21は、残っている取引情報を用いて、CE再計算処理を実行する(ステップS906)。具体的には、制御部21の計算部213は、取引情報テーブルに残っている取引情報、ステップS905で算出したNGR値を、CE計量モデルに適用してエクスポージャを算出する。
以上の処理を、削除を含むすべてのネッティングセットについて終了するまで繰り返す。
【0109】
次に、管理サーバ20の制御部21は、ステップS207と同様に、エクスポージャ積上処理を実行する(ステップS907)。
【0110】
図17に示すように、PFE対象の商品種別の取引識別子「2」、「3」を除いて、ネッティングセット「a」に基づいて、PFE計量モデルにより、PFE値が再計算されて、与信管理レコード240のPFE値を更新する。PFE対象の商品種別のネッティングセット「b」に属する取引識別子「4」の取引の与信管理レコード240のPFE値を削除する。また、CE対象の商品種別の取引識別子「5」の取引の与信管理レコード240のCE値も削除する。
【0111】
本実施形態によれば、以下のような効果を得ることができる。
(1)本実施形態では、オンライン処理(新規取引)において、管理サーバ20の制御部21は、CE計算処理を実行する(ステップS206)。PFE計量は計算負荷が大きいが、オンライン処理において、CE計量モデルを用いることにより、迅速にエクスポージャを計算することができる。この場合、管理サーバ20の制御部21は、NGR計算処理を実行する(ステップS205)。これにより、ネッティングによるエクスポージャの低減を図ることができる。
【0112】
(2)本実施形態では、オンライン処理(取引修正)において、CE計算対象と判定した場合(ステップS304において「YES」の場合)、管理サーバ20の制御部21は、CE修正計算処理を実行する(ステップS305)。これにより、迅速にエクスポージャを修正することができる。
【0113】
一方、CE計算対象でないと判定した場合(ステップS304において「NO」の場合)、管理サーバ20の制御部21は、CE計算処理を実行する(ステップS306)。これにより、PFE計量の計算負荷が大きく、時間的に実行できない場合にも、CE計量により、エクスポージャを算出することができる。
【0114】
(3)本実施形態では、オンライン処理(取引削除)において、CE計算対象と判定した場合(ステップS402において「YES」の場合)、管理サーバ20の制御部21は、削除処理を実行する(ステップS403)。これにより、迅速にエクスポージャを修正することができる。一方、CE計算対象でないと判定した場合(ステップS402において「NO」の場合)、管理サーバ20の制御部21は、削除処理(ステップS403)をスキップする。これにより、PFE計量を時間的に実行できない場合にも、日中はエクスポージャを維持することができる。
【0115】
(4)本実施形態では、リコンサイル処理において、管理サーバ20の制御部21は、リコンサイルファイルとの差異の特定処理を実行する(ステップS503)。これにより、通信エラーや、管理端末15での入力が行なわれた場合にも、リアルタイムで受信するI/Fデータとの相違を特定することができる。
【0116】
(5)本実施形態では、置換処理において、「(a)双方に存在する」と判定した場合であって、置換対象と判定した場合(ステップS602において「YES」の場合)、管理サーバ20の制御部21は、リコンサイルファイルによる置換処理を実行する(ステップS603)。これにより、リコンサイルファイルを正として、取引情報テーブルを修正することができる。
【0117】
一方、当日取引区分が「修正」又は「削除」であり、置換対象でないと判定した場合(ステップS602において「NO」の場合)、管理サーバ20の制御部21は、リコンサイルファイルによる置換処理(ステップS603)をスキップする。アフターで修正された場合、I/Fデータを受信しないため、一律にリコンサイルファイルに置き換えた場合、修正が反映されていない状態となってしまう。置換処理をスキップすることにより、このような状態の発生を抑制することができる。
【0118】
(6)本実施形態では、「(b)取引情報テーブルのみに存在する」と判定した場合であって、当日取引区分が置換対象と判定した場合(ステップS604において「YES」の場合)、管理サーバ20の制御部21は、リコンサイルファイルによる置換処理を実行する(ステップS605)。これにより、リコンサイルファイルを正として、取引情報テーブルを修正することができる。
【0119】
一方、当日取引区分が「新規」、「修正」、「削除」であり、当日取引区分が置換対象でないと判定した場合(ステップS604において「NO」の場合)、管理サーバ20の制御部21は、リコンサイルファイルによる置換処理(ステップS605)をスキップする。これにより、拠点の締め後に管理端末15に入力されたアフター取引等、リコンサイルファイルに存在しない取引情報を保持することができる。また、PFE計量用データはアフター取引の情報が反映されていないため、アフター取引による修正が発生した場合、的確な計量ができない状態を抑制できる。また、管理サーバ20は、フロントシステム10の当日業務の締め時を特定できず、インタイム取引とアフター取引を区別することが困難な場合にも、取引情報テーブルにおける取引情報を維持することができる。
【0120】
(7)本実施形態では、「(c)リコンサイルファイルのみに存在する」と判定した場合であって、当日取引区分が「新規」又は「修正」であり、置換対象と判定した場合(ステップS606において「YES」の場合)、管理サーバ20の制御部21は、リコンサイルファイルによる置換処理を実行する(ステップS607)。これにより、リコンサイルファイルを正として、取引情報テーブルを修正することができる。
【0121】
一方、当日取引区分が「削除」であり、置換対象でないと判定した場合(ステップS606において「NO」の場合)、管理サーバ20の制御部21は、リコンサイルファイルによる置換処理(ステップS607)をスキップする。インタイム取引とアフター取引を区別することが困難な場合にも、取引情報テーブルにおける取引情報を維持することができる。
【0122】
(8)本実施形態では、日次バッチ処理(新規取引)において、計算方針が「PFE」と判定した場合(ステップS703において「YES」の場合)、管理サーバ20の制御部21は、既存取引を含めてPFE計算処理を実行する(ステップS704)。これにより、時間的に余裕があるバッチ処理において、PFE対象の取引情報についてPFE計量を行なうことができる。
【0123】
また、発生タイミングが「アフター」であり、インタイムでないと判定した場合や、PFE対象でないと判定した場合(ステップS702、S703において「NO」の場合)、管理サーバ20の制御部21は、NGR計算処理(ステップS705)、CE計算処理(ステップS706)を実行する。これにより、フロントシステム10から取得するPFE計量用データに反映されていない取引情報を、PFE計量から外してCE計量によりエクスポージャを算出することができる。
【0124】
(9)本実施形態では、日次バッチ処理(取引修正)において、PFE対象と判定した場合(ステップS803において「YES」の場合)、管理サーバ20の制御部21は、修正がない取引情報を用いて、PFE計算処理を実行する(ステップS804)。時間的に余裕があるバッチ処理において、PFE対象の取引情報についてPFE計量を行なうことができる。
【0125】
また、管理サーバ20の制御部21は、修正された取引情報を用いて、CE計算処理を実行する(ステップS806)。既存取引の修正の場合、取引情報に含まれる値の発生タイミングを正確に特定できないため、修正取引情報はアフター取引と判定して、CE計量により、エクスポージャを算出することができる。
【0126】
また、インタイムでないと判定した場合や、PFE対象でないと判定した場合(ステップS802、S803において「NO」の場合)、管理サーバ20の制御部21は、NGR計算処理(ステップS808)、CE計算処理(ステップS809)を実行する。これにより、フロントシステム10から取得するPFE計量用データに反映されていない取引情報を、PFE計量から外してCE計量によりエクスポージャを算出することができる。
【0127】
(10)本実施形態では、日次バッチ処理(取引削除)において、PFE対象と判定した場合(ステップS903において「YES」の場合)、管理サーバ20の制御部21は、PFE計算処理を実行する(ステップS904)。一方、PFE対象でないと判定した場合(ステップS903において「NO」の場合)、管理サーバ20の制御部21は、NGR計算処理(ステップS905)、残っている取引情報を用いて、CE再計算処理(ステップS906)を実行する。これにより、削除された取引情報をエクスポージャに反映させることができる。
【0128】
本実施形態は、以下のように変更して実施することができる。本実施形態及び以下の変更例は、技術的に矛盾しない範囲で互いに組み合わせて実施することができる。
・上記実施形態では、日次バッチ処理を行なったが、バッチ処理のタイミングは、日次に限定されるものではない。例えば、週次で行なうようにしてもよい。
【0129】
・上記実施形態では、与信管理システムとして、フロントシステム10、管理端末15、管理サーバ20を用いるが、ハードウェア構成はこれらに限定されるものではない。
【符号の説明】
【0130】
10…フロントシステム、12…取引データ記憶部、15…管理端末、20…管理サーバ、21…制御部、211…取得部、212…照合部、213…計算部、22…商品情報記憶部、23…取引情報記憶部、24…与信情報記憶部、25…断面情報記憶部。
図1
図2
図3
図4
図5
図6
図7
図8
図9
図10
図11
図12
図13
図14
図15
図16
図17