JP7013558B1 - 与信管理システム、与信管理方法及び与信管理プログラム - Google Patents

Abstract

【課題】効率的かつ的確に信用リスクエクスポージャを計算して管理するための与信管理システム、与信管理方法及び与信管理プログラムを提供する。【解決手段】管理サーバ２０の制御部２１が、フロントシステム１０から、オンラインで取引情報を取得し、当日取引区分に関連付けて取引情報記憶部２３に記録する。そして、フロントシステム１０からリコンサイルファイルを取得し、リコンサイルファイルと取引情報記憶部２３に記録された取引情報とを照合する。リコンサイルファイル及び取引情報記憶部２３の双方に存在する取引情報であって、当日取引区分が新規の場合には、取引情報記憶部２３に記録された取引情報をリコンサイルファイルの取引情報で置換し、当日取引区分が変更の場合には取引情報記憶部２３に記録された取引情報を維持する。そして、取引情報記憶部２３に記録された取引情報を用いて、信用リスクエクスポージャを計算する。【選択図】図１

Description

本発明は、信用リスクエクスポージャを管理するための与信管理システム、与信管理方法及び与信管理プログラムに関する。

金融機関においては、与信相当額である信用リスクエクスポージャ（以下、エクスポージャ）を評価し、例えば、ヘッジ取引等のリスクヘッジを行なう。ここで、エクスポージャは、金融資産（ポートフォリオ）の中で、市場の価格変動のリスクがある資産の度合い（割合）である。また、自己資本比率規制に係るリスク計測関連規制の一つとして、デリバティブ取引の取引先（カウンターパーティ）に対する与信相当額を計算する。このため、金融機関のデリバティブ取引における取引先の与信相当額を計測するリスク管理システムが検討されている（例えば、特許文献１を参照）。この文献に記載された技術では、ＰＦＥ（Potential Future Exposure）及び再構築コスト（ＲＣ）を算出して、ＰＦＥとＲＣに基づいて与信相当額（ＥＡＤ）を算出する。

国際公開第２０１７／２１２６５１号

取引を管理するフロントシステムに対して、エクスポージャを算出するためのバックエンドシステムを用いることがある。このバックエンドシステムでは、フロントシステムから取引情報を取得する、しかしながら、状況に応じて、バックエンドシステムで保有する取引情報と、フロントシステムで保有する取引情報とで差異が生じることがあり、それぞれの取引情報の突合作業の負担が大きい。また、エクスポージャを計量するための計算方式は複数種類あり、計算方式によって計算負荷が異なる。また、取引を行なう両当事者間で、債権（正の市場価値）と債務（負の市場価値）を差し引き計算（ネット・アウト）して、１本の債権（または債務）とするネッティング契約を結ぶこともある。この場合、取引当事者はネッティングによってエクスポージャを削減できる。このネッティングを考慮しなければ、的確なリスク管理が困難である。

上記課題を解決する与信管理システムは、取引情報を記録する取引情報記憶部と、信用リスクエクスポージャを管理する制御部とを備える。そして、前記制御部が、フロントシステムから、オンラインで取引情報を取得し、当日取引区分に関連付けて前記取引情報記憶部に記録し、前記フロントシステムからリコンサイルファイルを取得し、前記リコンサイルファイルと前記取引情報記憶部に記録された取引情報とを照合し、前記リコンサイルファイル及び前記取引情報記憶部の双方に存在する取引情報であって、当日取引区分が新規の場合には、前記取引情報記憶部に記録された取引情報をリコンサイルファイルの取引情報で置換し、当日取引区分が変更の場合には前記取引情報記憶部に記録された取引情報を維持し、前記取引情報記憶部に記録された取引情報を用いて、信用リスクエクスポージャを計算する。

本発明によれば、効率的かつ的確に信用リスクエクスポージャを計算して管理することができる。

実施形態のシステム概略図。 実施形態のハードウェア構成例の説明図。 実施形態の処理手順の説明図。 実施形態の処理手順の説明図。 実施形態のエクスポージャの計算例の説明図。 実施形態の処理手順の説明図。 実施形態のエクスポージャの計算例の説明図。 実施形態の処理手順の説明図。 実施形態のエクスポージャの計算例の説明図。 実施形態の処理手順の説明図。 実施形態の処理手順の説明図。 実施形態の処理手順の説明図。 実施形態のエクスポージャの計算例の説明図。 実施形態の処理手順の説明図。 実施形態のエクスポージャの計算例の説明図。 実施形態の処理手順の説明図。 実施形態のエクスポージャの計算例の説明図。

以下、図１～図１７に従って、与信管理システム、与信管理方法及び与信管理プログラムを具体化した一実施形態を説明する。本実施形態では、バーゼル規制対応で適用している内部モデル方式としてＰＦＥ計量モデルを用いる。なお、内部モデル方式を用いない金融商品については、カレントエクスポージャ方式（ＣＥ方式）を適用する。

ＰＦＥ計量モデルでは、ネッティングした単位で、基準日（ｔ＝０）の時間を基点として、モンテカルロ方式で将来の時価分布をシミュレートする。そして、ｔ＝０から満期までの各ｔ時点で上位９５パーセンタイルの値を算出する。

また、ＣＥ方式では、ネッティングセット「ｉ」毎に、ＭｔＭ値のネッティング及びＮＧＲ値によるアドオン値の調整が行なわれる。
〔ＣＥ〕＝max［Σi〔MtM〕＋Σi〔Add-On〕×Ｚ，０］
〔Add-On〕＝〔想定元本（受取側）〕×〔ＲＷＦ〕
Ｚ＝0.4＋0.6×〔ＮＧＲ〕

〔MtM〕（Mark to Market）は、各種金融商品の取引において、現在保有している資産（ポジション）を実際の市場価格（市場レート）で計算した時価（現在価値）である。
〔ＲＷＦ〕（Risk Weighting Factor）は、各商品、通貨、期間毎のリスク掛け目である。
〔ＮＧＲ〕（net-to-gross ratio）は、ネット再構築コストとグロス再構築コストの比率であり、下記のＮＧＲ計算式により算出される。
〔ＮＧＲ〕＝max［Σi〔MtM〕，０］／Σi max（〔MtM〕，０）

図１に示すように、本実施形態では、ネットワークを介して接続されたフロントシステム１０、管理端末１５、管理サーバ２０を用いる。

（ハードウェア構成例）
図２は、フロントシステム１０、管理端末１５、管理サーバ２０等として機能する情報処理装置Ｈ１０のハードウェア構成例である。

情報処理装置Ｈ１０は、通信装置Ｈ１１、入力装置Ｈ１２、表示装置Ｈ１３、記憶部Ｈ１４、プロセッサＨ１５を有する。なお、このハードウェア構成は一例であり、他のハードウェアを有していてもよい。

通信装置Ｈ１１は、他の装置との間で通信経路を確立して、データの送受信を実行するインターフェースであり、例えばネットワークインターフェースや無線インターフェース等である。

入力装置Ｈ１２は、ユーザの入力を受け付ける装置であり、例えばマウスやキーボード等である。
表示装置Ｈ１３は、各種情報を表示するディスプレイやタッチパネル等である。

記憶部Ｈ１４は、フロントシステム１０、管理端末１５、管理サーバ２０の各種機能を実行するためのデータや各種プログラムを格納する記憶装置である。記憶部Ｈ１４の一例としては、ＲＯＭ、ＲＡＭ、ハードディスク等がある。

プロセッサＨ１５は、記憶部Ｈ１４に記憶されるプログラムやデータを用いて、フロントシステム１０、管理端末１５、管理サーバ２０における各処理を制御する。プロセッサＨ１５の一例としては、例えばＣＰＵやＭＰＵ等がある。このプロセッサＨ１５は、ＲＯＭ等に記憶されるプログラムをＲＡＭに展開して、各種処理に対応する各種プロセスを実行する。例えば、プロセッサＨ１５は、フロントシステム１０、管理端末１５、管理サーバ２０のアプリケーションプログラムが起動された場合、後述する各処理を実行するプロセスを動作させる。

プロセッサＨ１５は、自身が実行するすべての処理についてソフトウェア処理を行なうものに限られない。例えば、プロセッサＨ１５は、自身が実行する処理の少なくとも一部についてハードウェア処理を行う専用のハードウェア回路（例えば、特定用途向け集積回路：ＡＳＩＣ）を備えてもよい。すなわち、プロセッサＨ１５は、（１）コンピュータプログラム（ソフトウェア）に従って動作する１つ以上のプロセッサ、（２）各種処理のうち少なくとも一部の処理を実行する１つ以上の専用のハードウェア回路、或いは（３）それらの組み合わせ、を含む回路（circuitry）として構成し得る。プロセッサＨ１５は、ＣＰＵ並びに、ＲＡＭ及びＲＯＭ等のメモリを含み、メモリは、処理をＣＰＵに実行させるように構成されたプログラムコード又は指令を格納している。メモリすなわちコンピュータ可読媒体は、汎用又は専用のコンピュータでアクセスできるあらゆる利用可能な媒体を含む。

（各情報処理装置の構成）
図１を用いて、フロントシステム１０、管理端末１５、管理サーバ２０の構成を説明する。

フロントシステム１０は、デリバティブ等の各種取引を行なう銀行（金融機関）の各拠点のコンピュータシステムである。フロントシステム１０は、取引データ記憶部１２を備える。

取引データ記憶部１２には、フロントシステム１０に入力された取引についての新規約定、取引修正、取引削除に関するデータが記録される。
フロントシステム１０は、新規約定、取引修正、取引削除等が発生した時に、取引明細を含めたＩ／Ｆデータ（取引情報）を生成し、リアルタイムで管理サーバ２０に送信する。

そして、フロントシステム１０は、営業日の日締め処理後に、リコンサイルファイル、ＰＦＥ計量用データを生成し、管理サーバ２０に送信する。リコンサイルファイルには、フロントシステム１０の取引データ記憶部１２に記録された当日の取引に関するデータ（新規、修正、削除）に関する取引明細が含まれる。また、ＰＦＥ計量用データには、ＰＦＥ計量に必要となる項目に関するデータが含まれる。

管理端末１５は、管理サーバ２０の担当者が用いるコンピュータ端末である。この管理端末１５を用いて、通常の新規取引の他、与信枠確保取引や事前入力取引等を入力する。

管理サーバ２０は、与信管理を行なうコンピュータシステムである。フロントシステム１０・管理サーバ２０間の取引インターフェースは、新規取引の入力、修正及び削除時のみに実施される。このため、Ｉ／Ｆエラーの発生や管理サーバ２０上での取引修正の場合には、フロントシステム１０・管理サーバ２０間のデータに不整合が生じる。データの整合性を担保するため、管理サーバ２０で管理する取引情報を日次での置き換えを実施する。
この管理サーバ２０は、制御部２１、商品情報記憶部２２、取引情報記憶部２３、与信情報記憶部２４、断面情報記憶部２５を備える。

制御部２１は、与信管理プログラムを実行することにより、取得部２１１、照合部２１２、計算部２１３として機能する。
取得部２１１は、フロントシステム１０、管理端末１５から、与信管理のための各種データを取得する処理を実行する。
照合部２１２は、フロントシステム１０から取得したリコンサイルファイルを用いて、取引情報記憶部２３に記録された取引情報と照合する処理を実行する。そして、照合部２１２は、照合結果に応じて、取引情報記憶部２３に記録された情報を更新する処理を実行する。
計算部２１３は、エクスポージャを管理するための計算処理を実行する。

商品情報記憶部２２には、取引種別毎に計算方針についての商品管理レコードが記録される。商品管理レコードは、取引種別に応じた計算方針が登録された場合に記録される。この商品管理レコードには、取引種別、計算方針に関するデータが記録される。

取引種別データ領域には、取引の種類を特定するための識別子に関するデータが記録される。取引種別としては、例えば、金利スワップ取引、通貨スワップ取引、ＦＸ取引（外国為替証拠金取引）、レポ取引等を用いる。

計算方針データ領域には、エクスポージャを算出するための計算方式を特定するための識別子に関するデータが記録される。本実施形態では、計算方式として、「ＰＦＥ」及び「ＣＥ」の何れかを用いる。

取引情報記憶部２３には、エクスポージャを計算するために必要な取引明細についての取引管理レコードからなる取引情報テーブルが記録される。本実施形態では、フロントシステム１０から取得したＩ／Ｆデータ、管理端末１５から取得した画面入力データが記録される。取引管理レコードには、取引識別子、取引日、拠点、商品種別、想定元本、ネッティングセット、当日取引区分、発生タイミングに関するデータが記録される。

取引識別子データ領域には、各取引を特定するための識別子に関するデータが記録される。
取引日データ領域には、この取引が行なわれた年月日に関するデータが記録される。

拠点データ領域には、この取引が行なわれた拠点を特定するための識別子に関するデータが記録される。
商品種別データ領域には、この取引の商品種別を特定するための識別子に関するデータが記録される。

想定元本データ領域には、この取引で実際に受け渡しするキャッシュ・フローを計算するために必要な想定元本（契約額）に関するデータが記録される。
ネッティングセットデータ領域には、ネッティングを行なう取引を特定するためのネッティング条件を特定するための識別子に関するデータが記録される。

当日取引区分データ領域には、この取引のステータスを特定するためのフラグが記録される。当日取引区分としては、「既存」、「新規」、「既存修正」、「修正」、「削除」等がある。「既存」は約定済みの取引を示す。「新規」は取引の新規入力を示す。「既存修正」は修正前の既存取引（約定済み）を示す。「修正」、「削除」は、それぞれ、修正、削除された取引を示す。

発生タイミングデータ領域には、管理サーバ２０に入力されるタイミングと、締め時刻との関係を特定するためのフラグが記録される。発生タイミングとしては、「インタイム」、「アフター」がある。「インタイム」はフロントシステムのシステムオープンから日締め処理の実施までを示す。「アフター」は日締め処理の実施後から次のシステムオープンまでを示す。

与信情報記憶部２４には、エクスポージャを計算した与信管理レコードが記録される。
与信管理レコードには、取引識別子、ＰＦＥ値、ＣＥ値、計算方針に関するデータが記録される。

取引識別子データ領域には、各取引を特定するための識別子に関するデータが記録される。
ＰＦＥ値データ領域には、ＰＦＥ計量モデルにより算出したエクスポージャに関するデータが記録される。

ＣＥ値データ領域には、ＣＥ計量モデルにより算出したエクスポージャに関するデータが記録される。
計算方針データ領域には、エクスポージャを算出する計算方式を特定するためのフラグが記録される。このデータ領域には、「ＰＦＥ」、「ＣＥ」、「ＣＥ（ＰＦＥ対象）」の何れかのフラグが記録される。ここで、「ＣＥ（ＰＦＥ対象）」は、本来、ＰＦＥ計量モデルを用いて計算する商品種別において、ＣＥ計量モデルにより算出したことを示す。

断面情報記憶部２５には、営業日毎に断面ファイルが記録される。断面ファイルは、日次バッチ処理を行なった場合に記録される。この断面ファイルには、日次バッチ処理時のエクスポージャのイメージデータが記録される。

次に、上述したシステムを用いた情報処理を説明する。本実施形態では、与信管理処理の概要、オンライン処理（新規、修正、削除）、リコンサイル処理、置換処理、日次バッチ処理（新規、修正、既存削除）の順番に説明する。

（与信管理処理の概要）
図３を用いて、与信管理処理の概要を説明する。
まず、管理サーバ２０の制御部２１は、オンライン処理を実行する（ステップＳ１０１）。このオンライン処理は、管理サーバ２０のシステムオープンからクローズまでの「オンライン中」に行なわれる。そして、オンライン当日を「Ｔ日」、システムクローズ～日締め処理後のシステムオープンまでを「Ｔ＋１日」と呼ぶ。具体的には、制御部２１の取得部２１１は、フロントシステム１０に取引情報が記録された場合、Ｉ／Ｆデータを取得し、取引情報記憶部２３に記録する。また、管理サーバ２０は、管理端末１５から画面入力データを取得した場合にも、取引情報記憶部２３に記録する。そして、リアルタイムでエクスポージャの計算を行なう。詳細は、図４～図６を用いて説明する。

そして、締め時刻が到来した場合、管理サーバ２０の制御部２１は、日次バッチ処理を実行する（ステップＳ１０２）。具体的には、制御部２１の取得部２１１は、締め時刻になった場合、フロントシステム１０からリコンサイルファイル、ＰＦＥ計量用データを取得する。そして、差異明細を特定し、エクスポージャの再計算を行なう。詳細は、図７～図１１を用いて説明する。

（オンライン処理（新規取引））
次に、図４を用いて、オンライン処理（新規取引）を説明する。ここでは、フロントシステム１０において、新規取引についての取引情報が取引データ記憶部１２に記録された場合を想定する。この処理は、締め時刻のインタイム及びアフターで共通する。

ここでは、管理サーバ２０の制御部２１は、新規取引情報の取得処理を実行する（ステップＳ２０１）。具体的には、制御部２１の取得部２１１は、フロントシステム１０から、新規取引についてのＩ／Ｆデータを取得する。

次に、管理サーバ２０の制御部２１は、ネッティング対象があるかどうかについての判定処理を実行する（ステップＳ２０２）。具体的には、制御部２１の計算部２１３は、Ｉ／Ｆデータの取引明細のネッティングセット（ネッティング条件）を特定する。そして、ネッティングセットが一致する取引が取引情報記憶部２３に記録されているかどうかを確認する。

ネッティングセットが一致する取引が、取引情報記憶部２３に記録されており、ネッティング対象があると判定した場合（ステップＳ２０２において「ＹＥＳ」の場合）、管理サーバ２０の制御部２１は、ＮＧＲ計算済かどうかについての判定処理を実行する（ステップＳ２０３）。具体的には、制御部２１の計算部２１３は、ネッティングセットに関連付けられて、日次バッチ処理で計算されたＮＧＲ値が断面情報記憶部２５に記録されているかどうかを確認する。断面情報記憶部２５に、ネッティングセットに関連付けられたＮＧＲ値が記録されている場合には、ＮＧＲ計算済と判定する。
ＮＧＲ計算済と判定した場合（ステップＳ２０３において「ＹＥＳ」の場合）、管理サーバ２０の制御部２１は、ＮＧＲ取得処理を実行する（ステップＳ２０４）。具体的には、制御部２１の計算部２１３は、断面情報記憶部２５に記録されたＮＧＲ値を取得する。

一方、ＮＧＲ計算済でないと判定した場合（ステップＳ２０３において「ＮＯ」の場合）、管理サーバ２０の制御部２１は、ＮＧＲ計算処理を実行する（ステップＳ２０５）。具体的には、制御部２１の計算部２１３は、ネッティングセットに属する取引情報を取得する。そして、計算部２１３は、取得した取引情報を、ＮＧＲ計算式に適用して、ＮＧＲ値を算出する。
なお、ネッティングセットが一致する取引が、取引情報記憶部２３に記録されておらず、ネッティング対象がないと判定した場合（ステップＳ２０２において「ＮＯ」の場合）、管理サーバ２０の制御部２１は、ステップＳ２０３～Ｓ２０５をスキップする。この場合には、「ＮＧＲ＝１」を用いることにより、ネッティングの影響を排除する。

次に、管理サーバ２０の制御部２１は、ＣＥ計算処理を実行する（ステップＳ２０６）。具体的には、制御部２１の計算部２１３は、いずれの商品種別についても、ＣＥ計量モデルを用いて、エクスポージャを算出する。このＣＥ計量モデルでは、ネッティングセット「ｉ」毎に、ＭｔＭ値のネッティング及びＮＧＲ値によるアドオン値の調整が行なわれる。

次に、管理サーバ２０の制御部２１は、エクスポージャ積上処理を実行する（ステップＳ２０７）。具体的には、制御部２１の計算部２１３は、算出したＣＥ値を含めた与信管理レコードを生成し、与信情報記憶部２４に記録する。ここで、商品情報記憶部２２において、計算方式として「ＰＦＥ」が記録されている場合には、与信管理レコードの計算方針データ領域に「ＣＥ（ＰＦＥ対象）」を記録する。この場合、計算部２１３は、与信情報記憶部２４に記録された与信管理レコードのＰＦＥ値、ＣＥ値を、それぞれ合計して、エクスポージャを算出する。

図５に示すように、取引識別子「３」、「４」の新規取引についての取引管理レコード２３０が取引情報記憶部２３に記録された場合、ＣＥ計量モデルにより算出されたＣＥ値を含む与信管理レコード２４０を生成する。

（オンライン処理（取引修正））
次に、図６を用いて、オンライン処理（取引修正）を説明する。フロントシステム１０において、既存取引の修正情報が取引データ記憶部１２に記録された場合を想定する。この処理は、締め時刻のインタイム及びアフターで共通する。

ここでは、管理サーバ２０の制御部２１は、修正情報の取得処理を実行する（ステップＳ３０１）。具体的には、制御部２１の取得部２１１は、フロントシステム１０から、取引の修正についてのＩ／Ｆデータを取得する。

次に、管理サーバ２０の制御部２１は、ステップＳ２０２と同様に、ネッティング対象があるかどうかについての判定処理を実行する（ステップＳ３０２）。
ネッティング対象がないと判定した場合（ステップＳ３０２において「ＮＯ」の場合）、管理サーバ２０の制御部２１は、ステップＳ２０５と同様に、ＮＧＲ計算処理を実行する（ステップＳ３０３）。

一方、ネッティング対象があると判定した場合（ステップＳ３０２において「ＹＥＳ」の場合）、管理サーバ２０の制御部２１は、ＮＧＲ計算処理（ステップＳ３０３）をスキップする。この場合には、日次バッチ処理で計算したＮＧＲ値を使用する。また、新規取引がネッティング対象でない場合には、「ＮＧＲ＝１」を用いる。

次に、管理サーバ２０の制御部２１は、ＣＥ計算対象かどうかについての判定処理を実行する（ステップＳ３０４）。具体的には、制御部２１の計算部２１３は、商品情報記憶部２２を用いて、Ｉ／Ｆデータの取引明細の商品種別に応じて計算方法を特定する。

ＣＥ計算対象と判定した場合（ステップＳ３０４において「ＹＥＳ」の場合）、管理サーバ２０の制御部２１は、ＣＥ修正計算処理を実行する（ステップＳ３０５）。具体的には、制御部２１の計算部２１３は、Ｉ／Ｆデータにおいて修正された想定元本を用いて、ＣＥ計量モデルにより、ＣＥ値を算出する。次に、計算部２１３は、Ｉ／Ｆデータの取引識別子が記録された与信管理レコードを与信情報記憶部２４から取得する。そして、計算部２１３は、与信管理レコードに記録されたＣＥ値を、新たに算出したＣＥ値に更新する。

一方、ＣＥ計算対象でないと判定した場合（ステップＳ３０４において「ＮＯ」の場合）、管理サーバ２０の制御部２１は、ＣＥ計算処理を実行する（ステップＳ３０６）。具体的には、制御部２１の計算部２１３は、ＰＦＥ計算対象について、Ｉ／Ｆデータにおいて修正された想定元本を用いて、ＣＥ計量モデルにより、ＣＥ値を計算する。

次に、管理サーバ２０の制御部２１は、エクスポージャ積上処理を実行する（ステップＳ３０７）。具体的には、制御部２１の計算部２１３は、新たに算出したＣＥ値を記録した与信管理レコードを生成し、与信情報記憶部２４に記録する。従って、ＰＦＥ対象の場合、日次バッチ処理で算出した前日ＰＦＥ値にＣＥ値を加算することになる。

図７に示すように、ＰＦＥ対象の商品種別の取引識別子「２」、「３」の取引についての修正情報を取得した場合、取引識別子「２’」、「３’」の取引管理レコード２３０を生成する。この場合、与信管理レコード２４０において、これらのＰＦＥ値はそのまま維持される。更に、取引識別子「２’」、「３’」について、ＣＥ計量モデルにより算出されたＣＥ値を含む与信管理レコード２４０を生成する。また、ＣＥ対象の商品種別の取引識別子「４」の取引についての修正情報を取得した場合、与信管理レコード２４０において、ＣＥ計量モデルにより算出されたＣＥ値に修正する。

（オンライン処理（取引削除））
次に、図８を用いて、オンライン処理（取引削除）を説明する。フロントシステム１０において、既存取引の削除情報が取引データ記憶部１２に記録された場合を想定する。この処理は、締め時刻のインタイム及びアフターで共通する。

ここでは、管理サーバ２０の制御部２１は、削除情報の取得処理を実行する（ステップＳ４０１）。具体的には、制御部２１の計算部２１３は、フロントシステム１０から、既存取引の削除についてのＩ／Ｆデータを取得する。

次に、管理サーバ２０の制御部２１は、ステップＳ３０４と同様に、ＣＥ計算対象かどうかについての判定処理を実行する（ステップＳ４０２）。
ＣＥ計算対象と判定した場合（ステップＳ４０２において「ＹＥＳ」の場合）、管理サーバ２０の制御部２１は、削除処理を実行する（ステップＳ４０３）。具体的には、制御部２１の計算部２１３は、Ｉ／Ｆデータの取引識別子が記録された与信管理レコードを与信情報記憶部２４から取得する。そして、計算部２１３は、与信情報記憶部２４から、与信管理レコードを削除する。

一方、ＣＥ計算対象でないと判定した場合（ステップＳ４０２において「ＮＯ」の場合）、管理サーバ２０の制御部２１は、削除処理（ステップＳ４０３）をスキップする。この場合、日次バッチ処理のタイミングで、この取引のエクスポージャを「０」にする。

図９に示すように、ＰＦＥ対象の商品種別の取引識別子「２」～「４」の取引についての削除情報を取得した場合、与信管理レコード２４０において、これらのＰＦＥ値はそのまま維持される。一方、取引識別子「５」について、ＣＥ計量モデルにより算出されたＣＥ値を含む与信管理レコード２４０を生成する。また、ＣＥ対象の商品種別の取引識別子「５」の取引についての削除情報を取得した場合、与信管理レコード２４０においてＣＥ値を削除する。ここで、「１０※」は削除を意味する。

（リコンサイル処理）
図１０を用いて、リコンサイル処理を説明する。この処理は、フロントシステム１０の日締め処理後に行なわれる。

ここでは、管理サーバ２０の制御部２１は、締め時情報の取得処理を実行する（ステップＳ５０１）。具体的には、制御部２１の取得部２１１は、フロントシステム１０からリコンサイルファイル、ＰＦＥ計量用データを取得する。

次に、管理サーバ２０の制御部２１は、取引情報テーブルの取得処理を実行する（ステップＳ５０２）。具体的には、制御部２１の照合部２１２は、取引情報記憶部２３から、当日の取引情報テーブルを取得する。

次に、管理サーバ２０の制御部２１は、リコンサイルファイルとの差異の特定処理を実行する（ステップＳ５０３）。具体的には、制御部２１の照合部２１２は、フロントシステム１０から取得したリコンサイルファイルの取引明細と、取引情報テーブルの取引明細とを比較する。そして、照合部２１２は、差異明細を特定する。差異明細が生じる場合としては、（ａ）リコンサイルファイルと取引情報テーブルとの双方に取引情報が存在する場合、（ｂ）取引情報テーブルにのみ取引情報が存在する場合、（ｃ）リコンサイルファイルにのみ取引情報が存在する場合がある。

次に、管理サーバ２０の制御部２１は、置換処理を実行する（ステップＳ５０４）。この処理については、図１１を用いて説明する。
次に、管理サーバ２０の制御部２１は、当日取引区分の更新処理を実行する（ステップＳ５０５）。具体的には、制御部２１の照合部２１２は、取引情報記憶部２３に記録された取引情報テーブルの当日取引区分として「なし」を記録する。

次に、管理サーバ２０の制御部２１は、計量処理を実行する（ステップＳ５０６）。具体的には、制御部２１の計算部２１３は、取引情報記憶部２３に記録された取引情報を用いてエクスポージャを算出する。この処理については、図１２～図１７を用いて説明する。

次に、管理サーバ２０の制御部２１は、断面情報反映処理を実行する（ステップＳ５０７）。具体的には、制御部２１の計算部２１３は、取引情報記憶部２３及び与信情報記憶部２４の断面ファイルを生成し、当日日付に関連付けて、断面情報記憶部２５に記録する。更に、計算部２１３は、日次バッチ処理で計算したＮＧＲ値を、ネッティングセットに関連付けて断面情報記憶部２５に記録する。

（置換処理）
次に、図１１を用いて、置換処理を説明する。この処理は、各取引情報を処理対象として特定して、順次、繰り返す。

ここでは、管理サーバ２０の制御部２１は、場合分け処理を実行する（ステップＳ６０１）。具体的には、制御部２１の照合部２１２は、上述したように、差異明細を以下の３つに場合分けを行なう。
（ａ）リコンサイルファイルと取引情報テーブルとの双方に取引情報が存在する場合
（ｂ）取引情報テーブルにのみ取引情報が存在する場合
（ｃ）リコンサイルファイルにのみ取引情報が存在する場合

ステップＳ６０１において、「（ａ）双方に存在する」と判定した場合、管理サーバ２０の制御部２１は、当日取引区分が置換対象かどうかについての判定処理を実行する（ステップＳ６０２）。具体的には、制御部２１の照合部２１２は、取引情報テーブルの当日取引区分を確認する。そして、当日取引区分が「なし」又は「新規」の場合には、置換対象と判定する。一方、当日取引区分が変更（「修正」又は「削除」）の場合には、置換対象でないと判定する。

置換対象と判定した場合（ステップＳ６０２において「ＹＥＳ」の場合）、管理サーバ２０の制御部２１は、リコンサイルファイルによる置換処理を実行する（ステップＳ６０３）。具体的には、制御部２１の照合部２１２は、取引情報記憶部２３に記録された取引情報テーブルの取引情報を、リコンサイルファイルに記録された取引情報で置き換える。

一方、置換対象でないと判定した場合（ステップＳ６０２において「ＮＯ」の場合）、管理サーバ２０の制御部２１は、リコンサイルファイルによる置換処理（ステップＳ６０３）をスキップする。この場合、取引情報記憶部２３に記録された取引情報テーブルの取引情報をそのまま維持する。

ステップＳ６０１において、「（ｂ）取引情報テーブルのみに存在する」と判定した場合、管理サーバ２０の制御部２１は、当日取引区分が置換対象かどうかについての判定処理を実行する（ステップＳ６０４）。具体的には、制御部２１の照合部２１２は、取引情報テーブルの当日取引区分を確認する。そして、当日取引区分が「なし」の場合には、置換対象と判定する。一方、当日取引区分が「新規」、「修正」、「削除」の何れかの場合には、置換対象でないと判定する。

当日取引区分が置換対象と判定した場合（ステップＳ６０４において「ＹＥＳ」の場合）、管理サーバ２０の制御部２１は、ステップＳ６０３と同様に、リコンサイルファイルによる置換処理を実行する（ステップＳ６０５）。具体的には、制御部２１の照合部２１２は、取引情報テーブルのみに記録されている取引情報を、リコンサイルファイルの取引情報で置き換える。これにより、リコンサイルファイルと同様に、取引情報が存在しない状態、すなわち取引情報の削除を行なう。

一方、当日取引区分が置換対象でないと判定した場合（ステップＳ６０４において「ＮＯ」の場合）、管理サーバ２０の制御部２１は、リコンサイルファイルによる置換処理（ステップＳ６０５）をスキップする。この場合も、取引情報記憶部２３に記録された取引情報テーブルの取引情報をそのまま維持する。

ステップＳ６０１において、「（ｃ）リコンサイルファイルのみに存在する」と判定した場合、管理サーバ２０の制御部２１は、当日取引区分が置換対象かどうかについての判定処理を実行する（ステップＳ６０６）。具体的には、制御部２１の照合部２１２は、取引情報テーブルの当日取引区分を確認する。そして、当日取引区分が「新規」又は「修正」の場合には、置換対象と判定する。一方、当日取引区分が「削除」の場合には、置換対象でないと判定する。

置換対象と判定した場合（ステップＳ６０６において「ＹＥＳ」の場合）、管理サーバ２０の制御部２１は、ステップＳ６０３と同様に、リコンサイルファイルによる置換処理を実行する（ステップＳ６０７）。

一方、置換対象でないと判定した場合（ステップＳ６０６において「ＮＯ」の場合）、管理サーバ２０の制御部２１は、リコンサイルファイルによる置換処理（ステップＳ６０７）をスキップする。この場合、取引情報記憶部２３に記録された取引情報テーブルの取引情報をそのまま維持する。すなわち、当日取引区分が「削除」の場合、取引情報テーブルがそのまま維持される。
以上の処理を、すべての取引について繰り返す。

（日次バッチ処理（新規取引））
次に、図１２を用いて、日次バッチで行なわれる日次バッチ処理（新規取引）を説明する。

まず、ネッティングセット毎に、処理対象のネッティングセットを特定し、以下の処理を繰り返す。
ここでは、管理サーバ２０の制御部２１は、グループに属する取引情報の特定処理を実行する（ステップＳ７０１）。具体的には、制御部２１の計算部２１３は、取引情報記憶部２３の取引情報テーブルを用いて、処理対象のネッティングセットが記録された取引管理レコードを特定する。

次に、管理サーバ２０の制御部２１は、インタイムかどうかについての判定処理を実行する（ステップＳ７０２）。具体的には、制御部２１の計算部２１３は、取引管理レコードの発生タイミング情報により、インタイム又はアフターの何れかを判定する。

インタイムと判定した場合（ステップＳ７０２において「ＹＥＳ」の場合）、管理サーバ２０の制御部２１は、ＰＦＥ対象かどうかについての判定処理を実行する（ステップＳ７０３）。具体的には、制御部２１の計算部２１３は、取引管理レコードの商品種別について、商品情報記憶部２２を用いて計算方針を特定する。

計算方針が「ＰＦＥ」と判定した場合（ステップＳ７０３において「ＹＥＳ」の場合）、管理サーバ２０の制御部２１は、既存取引を含めてＰＦＥ計算処理を実行する（ステップＳ７０４）。具体的には、制御部２１の計算部２１３は、同じネッティングセットに属する取引情報及びＰＦＥ計量用データを、ＰＦＥ計量モデルに適用してＰＦＥ値を算出する。

発生タイミングが「アフター」であり、インタイムでないと判定した場合や、ＰＦＥ対象でないと判定した場合（ステップＳ７０２，Ｓ７０３において「ＮＯ」の場合）、管理サーバ２０の制御部２１は、ステップＳ２０５と同様に、ＮＧＲ計算処理を実行する（ステップＳ７０５）。
次に、管理サーバ２０の制御部２１は、ステップＳ２０６と同様に、ＣＥ計算処理を実行する（ステップＳ７０６）。

次に、管理サーバ２０の制御部２１は、当日取引区分変更処理を実行する（ステップＳ７０７）。具体的には、制御部２１の計算部２１３は、取引情報記憶部２３の取引情報テーブルの取引管理レコードの当日取引区分を、「新規」を「既存」に更新する。
以上の処理を、すべてのネッティングセットについて終了するまで繰り返す。

次に、管理サーバ２０の制御部２１は、ステップＳ２０７と同様に、エクスポージャ積上処理を実行する（ステップＳ７０８）。

図１３に示すように、取引識別子「３」、「４」の取引管理レコード２３０の当日取引区分を「既存」に変更する。そして、ＰＦＥ対象の商品種別の取引識別子「３」は、ネッティングセット「ａ」に基づいて、ＰＦＥ計量モデルにより、ＰＦＥ値が再計算されて、与信管理レコード２４０のＰＦＥ値を更新する。また、ＣＥ対象の商品種別の取引識別子「４」の取引の与信管理レコード２４０について、ＣＥ計量モデルにより算出されたＣＥ値を記録する。

（日次バッチ処理（取引修正））
次に、図１４を用いて、日次バッチで行なわれる日次バッチ処理（取引修正）を説明する。

まず、ネッティングセット毎に、処理対象のネッティングセットを特定し、以下の処理を繰り返す。
そして、管理サーバ２０の制御部２１は、ステップＳ７０１、Ｓ７０２と同様に、グループに属する取引情報の特定処理（ステップＳ８０１）、インタイムかどうかについての判定処理（ステップＳ８０２）を実行する。

インタイムと判定した場合（ステップＳ８０２において「ＹＥＳ」の場合）、管理サーバ２０の制御部２１は、ステップＳ７０３と同様に、ＰＦＥ対象かどうかについての判定処理を実行する（ステップＳ８０３）。

ＰＦＥ対象と判定した場合（ステップＳ８０３において「ＹＥＳ」の場合）、管理サーバ２０の制御部２１は、修正がない取引情報を用いて、ＰＦＥ計算処理を実行する（ステップＳ８０４）。具体的には、制御部２１の計算部２１３は、ネッティングセットに属し、修正情報が記録されていない取引情報及びＰＦＥ計量用データを、ＰＦＥ計量モデルに適用してＰＦＥ値を算出する。

次に、管理サーバ２０の制御部２１は、修正された取引情報を用いて、ＮＧＲ計算処理を実行する（ステップＳ８０５）。具体的には、制御部２１の計算部２１３は、修正された取引情報を、ＮＧＲ計算式に適用してＮＧＲ値を算出する。

次に、管理サーバ２０の制御部２１は、修正された取引情報を用いて、ＣＥ計算処理を実行する（ステップＳ８０６）。具体的には、制御部２１の計算部２１３は、修正された取引情報、ステップＳ８０５において算出したＮＧＲ値を、ＣＥ計量モデルに適用してＣＥ値を算出する。

次に、管理サーバ２０の制御部２１は、当日取引区分変更処理を実行する（ステップＳ８０７）。具体的には、制御部２１の計算部２１３は、取引情報記憶部２３の取引情報テーブルの当日取引区分の「修正」を「既存」に更新する。

インタイムでないと判定した場合や、ＰＦＥ対象でないと判定した場合（ステップＳ８０２，Ｓ８０３において「ＮＯ」の場合）、管理サーバ２０の制御部２１は、ＮＧＲ計算処理を実行する（ステップＳ８０８）。具体的には、制御部２１の計算部２１３は、ネッティングセットに属する取引情報を、ＮＧＲ計算式に適用して、ＮＧＲ値を算出する。

次に、管理サーバ２０の制御部２１は、ＣＥ計算処理を実行する（ステップＳ８０９）。具体的には、制御部２１の計算部２１３は、ネッティングセットに属する取引情報、ステップＳ８０８において算出したＮＧＲ値を、ＣＥ計量モデルに適用して、エクスポージャを算出する。
以上の処理を、すべてのネッティングセットについて終了するまで繰り返す。

次に、管理サーバ２０の制御部２１は、ステップＳ２０７と同様に、エクスポージャ積上処理を実行する（ステップＳ８１０）。

図１５に示すように、取引識別子「２’」、「３’」の取引管理レコード２３０の当日取引区分を「既存」に変更する。そして、ＰＦＥ対象の商品種別の取引識別子「２」、「３」を除いて、ネッティングセット「ａ」に基づいて、ＰＦＥ計量モデルにより、ＰＦＥ値が再計算されて、与信管理レコード２４０のＰＦＥ値に更新する。この場合、取引識別子「２’」、「３’」について、ＣＥ計量モデルにより算出されたＣＥ値を含む与信管理レコード２４０を記録する。また、ＣＥ対象の商品種別の取引識別子「４’」の取引の与信管理レコード２４０について、ＣＥ計量モデルにより算出されたＣＥ値を記録する。

（日次バッチ処理（取引削除））
次に、図１６を用いて、日次バッチで行なわれる日次バッチ処理（取引削除）を説明する。

ここでは、管理サーバ２０の制御部２１は、削除処理を実行する（ステップＳ９０１）。具体的には、制御部２１の計算部２１３は、取引情報記憶部２３の取引情報テーブルに記録された取引管理レコードを削除する。

まず、削除した取引情報が属するネッティングセット毎に、処理対象グループを特定し、以下の処理を繰り返す。
ここでは、管理サーバ２０の制御部２１は、ステップＳ７０１，Ｓ７０３と同様に、グループに属する取引情報の特定処理（ステップＳ９０２）、ＰＦＥ対象かどうかについての判定処理（ステップＳ９０３）を実行する。

ＰＦＥ対象と判定した場合（ステップＳ９０３において「ＹＥＳ」の場合）、管理サーバ２０の制御部２１は、ＰＦＥ計算処理を実行する（ステップＳ９０４）。具体的には、制御部２１の計算部２１３は、ネッティングセットに属し、削除されていない取引情報及びＰＦＥ計量用データを、ＰＦＥ計量モデルに適用してエクスポージャを算出する。

一方、ＰＦＥ対象でないと判定した場合（ステップＳ９０３において「ＮＯ」の場合）、管理サーバ２０の制御部２１は、ＮＧＲ計算処理を実行する（ステップＳ９０５）。具体的には、制御部２１の計算部２１３は、取引情報テーブルに残っている取引情報を、ＮＧＲ計算式に適用してＮＧＲ値を算出する。

次に、管理サーバ２０の制御部２１は、残っている取引情報を用いて、ＣＥ再計算処理を実行する（ステップＳ９０６）。具体的には、制御部２１の計算部２１３は、取引情報テーブルに残っている取引情報、ステップＳ９０５で算出したＮＧＲ値を、ＣＥ計量モデルに適用してエクスポージャを算出する。
以上の処理を、削除を含むすべてのネッティングセットについて終了するまで繰り返す。

次に、管理サーバ２０の制御部２１は、ステップＳ２０７と同様に、エクスポージャ積上処理を実行する（ステップＳ９０７）。

図１７に示すように、ＰＦＥ対象の商品種別の取引識別子「２」、「３」を除いて、ネッティングセット「ａ」に基づいて、ＰＦＥ計量モデルにより、ＰＦＥ値が再計算されて、与信管理レコード２４０のＰＦＥ値を更新する。ＰＦＥ対象の商品種別のネッティングセット「ｂ」に属する取引識別子「４」の取引の与信管理レコード２４０のＰＦＥ値を削除する。また、ＣＥ対象の商品種別の取引識別子「５」の取引の与信管理レコード２４０のＣＥ値も削除する。

本実施形態によれば、以下のような効果を得ることができる。
（１）本実施形態では、オンライン処理（新規取引）において、管理サーバ２０の制御部２１は、ＣＥ計算処理を実行する（ステップＳ２０６）。ＰＦＥ計量は計算負荷が大きいが、オンライン処理において、ＣＥ計量モデルを用いることにより、迅速にエクスポージャを計算することができる。この場合、管理サーバ２０の制御部２１は、ＮＧＲ計算処理を実行する（ステップＳ２０５）。これにより、ネッティングによるエクスポージャの低減を図ることができる。

（２）本実施形態では、オンライン処理（取引修正）において、ＣＥ計算対象と判定した場合（ステップＳ３０４において「ＹＥＳ」の場合）、管理サーバ２０の制御部２１は、ＣＥ修正計算処理を実行する（ステップＳ３０５）。これにより、迅速にエクスポージャを修正することができる。

一方、ＣＥ計算対象でないと判定した場合（ステップＳ３０４において「ＮＯ」の場合）、管理サーバ２０の制御部２１は、ＣＥ計算処理を実行する（ステップＳ３０６）。これにより、ＰＦＥ計量の計算負荷が大きく、時間的に実行できない場合にも、ＣＥ計量により、エクスポージャを算出することができる。

（３）本実施形態では、オンライン処理（取引削除）において、ＣＥ計算対象と判定した場合（ステップＳ４０２において「ＹＥＳ」の場合）、管理サーバ２０の制御部２１は、削除処理を実行する（ステップＳ４０３）。これにより、迅速にエクスポージャを修正することができる。一方、ＣＥ計算対象でないと判定した場合（ステップＳ４０２において「ＮＯ」の場合）、管理サーバ２０の制御部２１は、削除処理（ステップＳ４０３）をスキップする。これにより、ＰＦＥ計量を時間的に実行できない場合にも、日中はエクスポージャを維持することができる。

（４）本実施形態では、リコンサイル処理において、管理サーバ２０の制御部２１は、リコンサイルファイルとの差異の特定処理を実行する（ステップＳ５０３）。これにより、通信エラーや、管理端末１５での入力が行なわれた場合にも、リアルタイムで受信するＩ／Ｆデータとの相違を特定することができる。

（５）本実施形態では、置換処理において、「（ａ）双方に存在する」と判定した場合であって、置換対象と判定した場合（ステップＳ６０２において「ＹＥＳ」の場合）、管理サーバ２０の制御部２１は、リコンサイルファイルによる置換処理を実行する（ステップＳ６０３）。これにより、リコンサイルファイルを正として、取引情報テーブルを修正することができる。

一方、当日取引区分が「修正」又は「削除」であり、置換対象でないと判定した場合（ステップＳ６０２において「ＮＯ」の場合）、管理サーバ２０の制御部２１は、リコンサイルファイルによる置換処理（ステップＳ６０３）をスキップする。アフターで修正された場合、Ｉ／Ｆデータを受信しないため、一律にリコンサイルファイルに置き換えた場合、修正が反映されていない状態となってしまう。置換処理をスキップすることにより、このような状態の発生を抑制することができる。

（６）本実施形態では、「（ｂ）取引情報テーブルのみに存在する」と判定した場合であって、当日取引区分が置換対象と判定した場合（ステップＳ６０４において「ＹＥＳ」の場合）、管理サーバ２０の制御部２１は、リコンサイルファイルによる置換処理を実行する（ステップＳ６０５）。これにより、リコンサイルファイルを正として、取引情報テーブルを修正することができる。

一方、当日取引区分が「新規」、「修正」、「削除」であり、当日取引区分が置換対象でないと判定した場合（ステップＳ６０４において「ＮＯ」の場合）、管理サーバ２０の制御部２１は、リコンサイルファイルによる置換処理（ステップＳ６０５）をスキップする。これにより、拠点の締め後に管理端末１５に入力されたアフター取引等、リコンサイルファイルに存在しない取引情報を保持することができる。また、ＰＦＥ計量用データはアフター取引の情報が反映されていないため、アフター取引による修正が発生した場合、的確な計量ができない状態を抑制できる。また、管理サーバ２０は、フロントシステム１０の当日業務の締め時を特定できず、インタイム取引とアフター取引を区別することが困難な場合にも、取引情報テーブルにおける取引情報を維持することができる。

（７）本実施形態では、「（ｃ）リコンサイルファイルのみに存在する」と判定した場合であって、当日取引区分が「新規」又は「修正」であり、置換対象と判定した場合（ステップＳ６０６において「ＹＥＳ」の場合）、管理サーバ２０の制御部２１は、リコンサイルファイルによる置換処理を実行する（ステップＳ６０７）。これにより、リコンサイルファイルを正として、取引情報テーブルを修正することができる。

一方、当日取引区分が「削除」であり、置換対象でないと判定した場合（ステップＳ６０６において「ＮＯ」の場合）、管理サーバ２０の制御部２１は、リコンサイルファイルによる置換処理（ステップＳ６０７）をスキップする。インタイム取引とアフター取引を区別することが困難な場合にも、取引情報テーブルにおける取引情報を維持することができる。

（８）本実施形態では、日次バッチ処理（新規取引）において、計算方針が「ＰＦＥ」と判定した場合（ステップＳ７０３において「ＹＥＳ」の場合）、管理サーバ２０の制御部２１は、既存取引を含めてＰＦＥ計算処理を実行する（ステップＳ７０４）。これにより、時間的に余裕があるバッチ処理において、ＰＦＥ対象の取引情報についてＰＦＥ計量を行なうことができる。

また、発生タイミングが「アフター」であり、インタイムでないと判定した場合や、ＰＦＥ対象でないと判定した場合（ステップＳ７０２、Ｓ７０３において「ＮＯ」の場合）、管理サーバ２０の制御部２１は、ＮＧＲ計算処理（ステップＳ７０５）、ＣＥ計算処理（ステップＳ７０６）を実行する。これにより、フロントシステム１０から取得するＰＦＥ計量用データに反映されていない取引情報を、ＰＦＥ計量から外してＣＥ計量によりエクスポージャを算出することができる。

（９）本実施形態では、日次バッチ処理（取引修正）において、ＰＦＥ対象と判定した場合（ステップＳ８０３において「ＹＥＳ」の場合）、管理サーバ２０の制御部２１は、修正がない取引情報を用いて、ＰＦＥ計算処理を実行する（ステップＳ８０４）。時間的に余裕があるバッチ処理において、ＰＦＥ対象の取引情報についてＰＦＥ計量を行なうことができる。

また、管理サーバ２０の制御部２１は、修正された取引情報を用いて、ＣＥ計算処理を実行する（ステップＳ８０６）。既存取引の修正の場合、取引情報に含まれる値の発生タイミングを正確に特定できないため、修正取引情報はアフター取引と判定して、ＣＥ計量により、エクスポージャを算出することができる。

また、インタイムでないと判定した場合や、ＰＦＥ対象でないと判定した場合（ステップＳ８０２、Ｓ８０３において「ＮＯ」の場合）、管理サーバ２０の制御部２１は、ＮＧＲ計算処理（ステップＳ８０８）、ＣＥ計算処理（ステップＳ８０９）を実行する。これにより、フロントシステム１０から取得するＰＦＥ計量用データに反映されていない取引情報を、ＰＦＥ計量から外してＣＥ計量によりエクスポージャを算出することができる。

（１０）本実施形態では、日次バッチ処理（取引削除）において、ＰＦＥ対象と判定した場合（ステップＳ９０３において「ＹＥＳ」の場合）、管理サーバ２０の制御部２１は、ＰＦＥ計算処理を実行する（ステップＳ９０４）。一方、ＰＦＥ対象でないと判定した場合（ステップＳ９０３において「ＮＯ」の場合）、管理サーバ２０の制御部２１は、ＮＧＲ計算処理（ステップＳ９０５）、残っている取引情報を用いて、ＣＥ再計算処理（ステップＳ９０６）を実行する。これにより、削除された取引情報をエクスポージャに反映させることができる。

本実施形態は、以下のように変更して実施することができる。本実施形態及び以下の変更例は、技術的に矛盾しない範囲で互いに組み合わせて実施することができる。
・上記実施形態では、日次バッチ処理を行なったが、バッチ処理のタイミングは、日次に限定されるものではない。例えば、週次で行なうようにしてもよい。

・上記実施形態では、与信管理システムとして、フロントシステム１０、管理端末１５、管理サーバ２０を用いるが、ハードウェア構成はこれらに限定されるものではない。

１０…フロントシステム、１２…取引データ記憶部、１５…管理端末、２０…管理サーバ、２１…制御部、２１１…取得部、２１２…照合部、２１３…計算部、２２…商品情報記憶部、２３…取引情報記憶部、２４…与信情報記憶部、２５…断面情報記憶部。

Claims (6)

1. 取引情報を記録する取引情報記憶部と、
   信用リスクエクスポージャを管理する制御部とを備えた与信管理システムであって、
   前記制御部が、
   フロントシステムから、オンラインで取引情報を取得し、当日取引区分に関連付けて前記取引情報記憶部に記録し、
   前記フロントシステムからリコンサイルファイルを取得し、
   前記リコンサイルファイルと前記取引情報記憶部に記録された取引情報とを照合し、
   前記リコンサイルファイル及び前記取引情報記憶部の双方に存在する取引情報であって、当日取引区分が新規の場合には、前記取引情報記憶部に記録された取引情報をリコンサイルファイルの取引情報で置換し、当日取引区分が変更の場合には前記取引情報記憶部に記録された取引情報を維持し、
   前記取引情報記憶部に記録された取引情報を用いて、信用リスクエクスポージャを計算することを特徴とする与信管理システム。
2. 前記信用リスクエクスポージャの計算には、商品に応じて、カレントエクスポージャ方式と内部モデル方式が定められており、
   前記制御部が、
   前記フロントシステムからオンラインで、当日取引区分が新規の取引情報を取得した場合には、前記カレントエクスポージャ方式により前記信用リスクエクスポージャを計算して積み上げ、
   オンライン終了後のバッチ処理で、前記内部モデル方式の商品種別について、前記内部モデル方式により、前記信用リスクエクスポージャを再計算して積み上げることを特徴とする請求項１に記載の与信管理システム。
3. 前記制御部が、
   前記フロントシステムからオンラインで、当日取引区分が修正の取引情報を取得した場合には、前記カレントエクスポージャ方式により前記信用リスクエクスポージャを計算して積み上げ、
   前記オンラインの終了後のバッチ処理で、前記内部モデル方式の商品種別について、修正されていない取引情報を用いて前記内部モデル方式により、信用リスクエクスポージャを計算するとともに、修正された取引情報を用いて前記カレントエクスポージャ方式により前記信用リスクエクスポージャを再計算して積み上げることを特徴とする請求項２に記載の与信管理システム。
4. 前記制御部が、
   前記フロントシステムからオンラインで、当日取引区分が削除の取引情報を取得した場合には、前記カレントエクスポージャ方式の商品種別についてのみ削除し、
   オンライン終了後のバッチ処理で、前記内部モデル方式の商品種別について、前記内部モデル方式により、前記信用リスクエクスポージャを再計算して積み上げることを特徴とする請求項２又は３に記載の与信管理システム。
5. 取引情報を記録する取引情報記憶部と、
   信用リスクエクスポージャを管理する制御部とを備えた与信管理システムを用いて、与信管理を行なう方法であって、
   前記制御部が、
   フロントシステムから、オンラインで取引情報を取得し、当日取引区分に関連付けて前記取引情報記憶部に記録し、
   前記フロントシステムからリコンサイルファイルを取得し、
   前記リコンサイルファイルと前記取引情報記憶部に記録された取引情報とを照合し、
   前記リコンサイルファイル及び前記取引情報記憶部の双方に存在する取引情報であって、当日取引区分が新規の場合には、前記取引情報記憶部に記録された取引情報をリコンサイルファイルの取引情報で置換し、当日取引区分が変更の場合には前記取引情報記憶部に記録された取引情報を維持し、
   前記取引情報記憶部に記録された取引情報を用いて、信用リスクエクスポージャを計算することを特徴とする与信管理方法。
6. 取引情報を記録する取引情報記憶部と、
   信用リスクエクスポージャを管理する制御部とを備えた与信管理システムを用いて、与信管理を行なうためのプログラムであって、
   前記制御部を、
   フロントシステムから、オンラインで取引情報を取得し、当日取引区分に関連付けて前記取引情報記憶部に記録し、
   前記フロントシステムからリコンサイルファイルを取得し、
   前記リコンサイルファイルと前記取引情報記憶部に記録された取引情報とを照合し、
   前記リコンサイルファイル及び前記取引情報記憶部の双方に存在する取引情報であって、当日取引区分が新規の場合には、前記取引情報記憶部に記録された取引情報をリコンサイルファイルの取引情報で置換し、当日取引区分が変更の場合には前記取引情報記憶部に記録された取引情報を維持し、
   前記取引情報記憶部に記録された取引情報を用いて、信用リスクエクスポージャを計算する手段として機能させることを特徴とする与信管理プログラム。

Images