JP5850546B1 - 国債元利金分配システム及びその方法 - Google Patents

Abstract

【課題】新日銀ネットに対応し、国債元利金分配の照合を効率的に行う。【解決手段】国債元利金分配システムは、日銀システム２０とのインターフェースとなるＲＴＧＳ決済管理システム１００と、債券取引管理システム２００と、複数の業務システム３００で構成される。このシステムにおいて、日銀システム２０から国債の償還日の所定期日に元利金配分の予定明細を取り込み、予定明細を債券取引管理システム２００及び業務システム３００との間でデータを照合する。利子配分先の変更が必要と判断された場合は、利子配分先変更データを作成し、日銀システム２０に送信する。日銀システム２０から国債の償還日の前日までに元利金配分の確定明細を取り込み、確定明細を債券取引管理システム２００と業務システム３００との間で再度照合する。照合の結果、データの不一致が検出された場合には、関連するデータを検索し詳細を提示する。【選択図】図１

Description

本発明は、国債の元利金を分配するためのシステム及びその方法に関する。

国債の売買取引においては、その取引が複雑に錯綜して起こることが日常的なことであるから、この複雑に交錯して起こる国債と資金が不足していないか、又はその勘定が一致しているかどうかを瞬時にかつ確実にチェックすることが必要である。このため、出願人は、特許文献１において、資金口座ファイル及び証券口座ファイルを備えると共に、前記両口座ファイルの各口座は、予定残高と実残高を有しており、約定情報により資金口座又は証券口座の予定残高確認情報を作成し、該予定残高確認情報により予定残高更新情報を作成し、該予定残高更新情報から国債決済依頼情報を作成して決済機関に送信して、前記決済機関から送信された決済完了通知情報により更新指示情報を作成する機能を備えることにより、国債と資金が不足していないか、又はその勘定が一致しているかどうかを瞬時にかつ確実にチェックすることを可能とするシステムを開示している。

特開２００５−２４２７１９号公報

ところで、国債の取引を行うためには、日本銀行が運営する日本銀行金融ネットワークシステム（以下、日銀ネットと呼ぶ）における国債決済システムを利用する必要があるが、現在、「新日銀ネット構築プロジェクト」が進行しており、その第２段階が２０１５年１０月に稼働することが予定されている。現行の日銀ネットにおける国債の振替は、元利金分配日の３営業日前までしか許容されていないが、新日銀ネットでは、原則、元利金分配日の前営業日（１５時）まで取引が可能となる。また、当事者間の合意があれば、上記の入力締切時刻以降も利子配分先の変更が可能となる。そのため、日銀が管理している元利金配分額明細と、銀行などの金融機関が管理している元利金配分予定明細との照合を、現在は２営業日かけて行っているが、今後は数時間で行う必要がある。しかも、銀行は、国債を様々な取引（銀行勘定での運用、担保取得、カストディ業務（投資家に代わって有価証券の管理を行うこと））を背景として保有しているため、複数の部署で管理する情報を基に照合を行わなければならない。

したがって、本発明では、上記のような課題に鑑み、新日銀ネットに対応し、複雑な国債元利金分配の照合を効率的に行うことが可能な国債元利金分配システムを提供することを目的とする。

上記課題を解決するため、本発明の国債元利金分配システムは、以下のような解決手段を提供する。

新日銀ネットに対応した金融機関における国債元利金分配システムであって、日銀システムから国債の償還日の所定期日に元利金配分の予定明細を取り込む予定明細照会手段と、前記予定明細を当該金融機関が扱っている債券の取引データを管理する債券取引管理システム及び債券の取引形態や運用ごとに顧客対応の処理を行う業務システムとの間でデータを照合する予定明細照合手段と、前記予定明細照合手段において、利子配分先の変更が必要と判断された場合は、利子配分先変更データを作成し、前記日銀システムに送信する利子配分先変更手段と、前記日銀システムから国債の償還日の前日までに元利金配分の確定明細を取り込む確定明細照会手段と、前記確定明細を前記債券取引管理システムと前記業務システムとの間で再度照合する確定明細照合手段と、を備え、前記確定明細照合手段において、データの不一致が検出された場合には、前記債券取引管理システムと前記業務システムに格納された関連するデータを検索し、詳細を提示することを特徴とする。

また、上記の国債元利金分配システムは、前記確定明細照合手段においてデータの不一致が検出された場合、前記不一致の原因の類型を発生頻度順に記憶した類型テーブルに基づいて、当該不一致の原因を関連部署に通知する通知手段をさらに備えることを特徴とする。

また、上記の国債元利金分配システムは、前記業務システムの構成を定義した業務システム構成テーブルを有し、前記利子配分先の配分明細表の送信先を前記業務システム構成テーブルに基づいて選択する配分額明細表作成部を備えることを特徴とする。

また、上記の国債元利金分配システムにおいて、前記予定明細照合手段は、前記利子配分先を登録した利子配分登録テーブルに基づいて、照合時の利子配分先が前記利子配分登録テーブルの利子配分先と不一致がある場合に、利子配分先の変更が必要であると判断することを特徴とする。

また、本発明の別の態様では、新日銀ネットに対応した金融機関における国債元利金分配方法であって、前記金融機関のシステムが、当該金融機関が扱っている債券の取引データを管理する債券取引管理システムと、債券の取引形態や運用ごとに顧客対応の処理を行う業務システムとを含んで構成され、前記金融機関のコンピュータが、日銀システムから国債の償還日の所定期日に元利金配分の予定明細を取り込むステップと、前記予定明細を前記債券取引管理システム及び前記業務システムとの間でデータを照合するステップと、前記予定明細を照合するステップにおいて、利子配分先の変更が必要と判断された場合は、利子配分先変更データを作成し、前記日銀システムに送信するステップと、前記日銀システムから国債の償還日の前日までに元利金配分の確定明細を取り込むステップと、前記確定明細を前記債券取引管理システムと前記業務システムとの間で再度照合するステップと、前記確定明細を再度照合するステップにおいて、データの不一致が検出された場合には、前記債券取引管理システムと前記業務システムに格納された関連するデータを検索し、詳細を提示するステップと、を実行することを特徴とする。

本発明によれば、新日銀ネットに対応し、複雑な国債元利金分配の照合を効率的に行うことが可能な国債元利金分配システムを提供することができる。

本発明の実施形態に係る銀行システム１０の基本構成を示す図である。 本発明の実施形態に係る銀行システム１０における事務フローを示す図である。 本発明の実施形態に係る銀行システム１０における事務フロー（続１）を示す図である。 本発明の実施形態に係る銀行システム１０における事務フロー（続２）を示す図である。 本発明の実施形態に係るＲＴＧＳ決済管理システム１００の機能構成を示す図である。 ＲＴＧＳ決済管理システム１００における配分額明細照会管理テーブル１１２と時点確定残高テーブル１０４のデータ項目を示す図である。 本発明の実施形態に係る債券取引管理システム２００の機能構成を示す図である。 債券取引管理システム２００の元利金データ管理部２１１の機能構成を示す図である。 債券取引管理システム２００の課税情報申告データ管理部２１２の機能構成を示す図である。 債券取引管理システム２００の元利金関連照会部２１４及びＲＴＧＳシステム連動管理部２１３の機能構成を示す図である。 国債元利金明細照会結果の画面表示例を示す図である。

以下、添付図面を参照して、本発明を実施するための形態（以下、実施形態）について詳細に説明する。以降の図においては、実施形態の説明の全体を通して同じ要素には同じ番号または符号を付している。また、機能構成の図において、機能ブロック間の矢印は、データの流れ方向、又は処理の流れ方向を表している。また、処理フロー図（フローチャート）においては、各処理ステップは、必ずしも図示した順序で行う必要はなく、各ステップのインプットとアウトプットの関係を損なわない限り、処理順序を入れ替えてもよい。

（基本構成）
図１は、本発明の実施形態に係る銀行システム１０の基本構成を示す図である。以下、本発明の国債元利金分配システムの一実施形態として銀行システム１０（以下、本システムとも呼ぶ）を取り上げて説明する。銀行システム１０は、図示するように、日銀システム２０と専用ネットワークで結ばれている。銀行システム１０は、内部的には、日銀システム２０とのＲＴＧＳ（Real Time Gross Settlement）、すなわち、即時グロス決済を管理するＲＴＧＳ決済管理システム１００と、債券取引データを管理する債券取引管理システム２００と、その他、債券の取引形態や運用ごとに顧客からの要求に直接対応するための処理を行う複数の業務システム３００ａ、３００ｂ、・・・とで構成される。なお、業務システムを個別に区別する必要がないときは、まとめて業務システム３００と呼ぶ。

ここで、ＲＴＧＳ決済管理システム１００は、日銀システム２０とのインターフェースとなり、債券取引管理システム２００と各業務システム３００との間のデータ連動を行う。業務システム３００は、例えば、投資家に代わって有価証券の管理を行う業務（カストディ業務）を扱うシステムであったり、債券に係る日銀資金決済代行の業務を行うシステムであったりする。一方、債券取引管理システム２００は、業務システム３００が行なうような顧客に直接対応する「業務」は行わず、銀行で保有する債券の取引データの全体を管理する。

以下、本システムの処理の概略を丸数字の順に従って説明する。まず、ステップ１として、日銀システム２０に対して、日銀の定める所定期日、通常は、国債の償還日の２営業日前に、元利金配分の予定明細を照会し、そのデータを取り込む（予定明細照会手段）。ＲＴＧＳ決済管理システム１００は、次に、ステップ２として、取り込んだ明細データをシステム間で連携するために債券取引管理システム２００及び各業務システム３００に送信する。そして、ステップ３として、２営業日前〜前営業日において、各システムとの間でデータの照合を行う（予定明細照合手段）。このデータの照合時、利子配分先の変更が必要であると判断した場合は、配布先の変更データを入力させ、日銀ネットに送信する利子配分先変更手段を有する。すなわち、その配分先の変更データを業務システム３００から債券取引管理システム２００に前営業日までに取込む（ステップ３’）。債券取引管理システム２００は、取り込んだ配分先の変更データに基づき、利子配分先変更データを作成（ステップ３”）し、利子配分先変更データをＲＴＧＳ決済管理システム１００の電文送信機能を介して、日銀システム２０に送信する（ステップＳ３”’）。

前営業日（前日）には、ＲＴＧＳ決済管理システム１００は、日銀システム２０から、元利金配分の確定明細を照会（確定明細照会手段）し、その明細を取り込み（ステップ４）、元利配分確定明細を債券取引管理システム２００に送信する（ステップ４’）。一方、同じく前営業日に、業務システム３００から債券取引管理システム２００に対して、銀行内部での確認結果のデータが送信される（ステップ４”）。債券取引管理システム２００は、取り込んだ元利金データの取込と照合（確定明細照合手段）を行い（ステップ５）、このとき不一致があることを検出した場合、各システム間で連動して（債券取引管理システム２００と業務システム３００に格納された関連するデータを検索し）、詳細を提示し、確認する処理を行う（ステップ５’）。そして、全ての照合が完了後（承認後）、ＲＴＧＳ決済管理システム１００と債券取引管理システム２００とで元利金入金データの連動を行う（ステップ６）。償還日（当日）には、日銀システム２０から入金通知と、利子及び元金の配分済通知がなされ（ステップＳ７）、ＲＴＧＳ決済管理システム１００に決済データとして保存される。

図２（図２Ａ，図２Ｂ，図２Ｃ）は、本発明の実施形態に係る銀行システム１０における事務フローを示す図である。これらの図では、日銀システム２０、ＲＴＧＳ決済管理システム１００、債券取引管理システム２００、及び業務システム３００の処理の流れを示している。関連部署とバックエンド部署（バック取引担当部署）では、手作業が発生するが、いずれも債券取引管理システム２００又は業務システム３００のコンピュータ画面上での作業である。以下では、逐次説明は省略するが、図２のフローチャートを図１のシステムの処理と対比して説明する。

図２ＡのＳ１０〜Ｓ１３の処理は、図１のステップ１、（元利金予定明細の照会）、ステップ２（元利金予定明細の取込）、ステップ３（システム間での照合）に対応する。また、Ｓ１４〜Ｓ１９の処理は、図１のステップ３'、ステップ３”、ステップ３”’（利子配分先の変更が必要な場合の処理）に対応する。また、図２ＢのＳ２０〜Ｓ２７の処理は、図１のステップ４、ステップ４’、ステップ４”、ステップ５（元利金確定明細の照会、取込、照合）に対応する。ここで、Ｓ２４で国債元利金照合要求を出し、Ｓ２５で債券取引管理システム２００が元利金受領データの照合を行い、Ｓ２６では、その照合の結果である元利金照会結果の確認を行う。また、日銀から受領した日銀データについては、Ｓ２７で日銀元利データの照会画面で確認できる。

図２ＢのＳ２８〜Ｓ３２の処理は、図１のステップ５’（照合結果が不一致の場合の処理）に対応する。このステップにおいては、元利金照合結果が不一致となり、元利金受領データの修正が必要な場合は、元利受領データを銀行システム内で修正版の再取込を行う（Ｓ２８，Ｓ２９）。そして、取り込んだ元利金受領データの再照合を行い（Ｓ３０，Ｓ３１）、再照合結果の確認を行い、照合が一致しているかどうかを確認し（Ｓ３２）、この処理を不一致がなくなるまで繰り返す。

Ｓ３３〜Ｓ３５の処理は、図１のステップ６（元利金入金データのシステム内の連動）の処理に対応する。バックエンド部署の権限者は、最終的に不一致がなくなったことを確認し、元利金承認を行い（Ｓ３３）、最終的な元利金入金データのシステム間での連動処理を行う（Ｓ３４、Ｓ３５）。

図２ＣのＳ３６、Ｓ３７の処理は、図１のステップ７（償還日当日の処理）に対応する。利払日・償還日には、日銀システム２０より当座勘定入金通知、国債振替決済利子配分済通知、国債振替決済元金配分済通知が送信され（Ｓ３６）、これらの通知の受信後、元利金決済データがＲＴＧＳ決済管理システム１００に格納される（Ｓ３７）。なお、「ＲＴＧＳ」（Real Time Gross Settlement）又は「即時グロス決済」とは、日本銀行が金融機関からの振替指図を１件ずつ即時に決済する手法のことである。

（機能構成）
図３は、本発明の実施形態に係るＲＴＧＳ決済管理システム１００の機能構成を示す図である。また、図４は、ＲＴＧＳ決済管理システム１００における配分額明細照会管理テーブル１１２と時点確定残高テーブル１０４のレコード（データ項目）を示す図である。以下、これらの図を参照しながら各機能（サービス）について説明する。

ＲＴＧＳ決済管理システム１００は、各処理の開始トリガーとなるタイマー部１０１とジョブネット受付部１０２を含んでいる。タイマー部１０１は一定時間間隔又は所定の時間になると、配分額明細照会部１０５を呼び出す。ジョブネット受付部１０２は、システムのユーザからのリクエストを受け、必要なサービスを処理する処理部を呼び出す。ジョブネットが呼び出す処理部としては、国債残高照会部１０３、配分額明細照会部１０５、配分額明細表作成部１１３がある。

国債残高照会部１０３は、当銀行が扱っている口座における国債のその時点で確定している残高を日銀システム２０に照会し、時点確定残高テーブル１０４に反映する処理を行う。

図４下段で図示するように、時点確定残高テーブル１０４のレコードは、国債振替決済の参加者口座の口座番号、銘柄コード、残高、償還日を含んでいる。ここで、口座番号の５〜６桁目は参加者識別コードであり、口座番号の７〜８桁目は口座区分である。参加者種別コードとは、国債振替決済の参加者口座の参加者の種別を示すコードであり、例えば、「００」（種別名なし）、「０１」（信託口１）、「３２」（供託口）等がある。また、口座区分は、国債振替決済の参加者口座の区分を示すコードであり、例えば、「０１」（自己口１）[非課税口]、「０３」（自己口３）[課税口]等がある。

残高を時点確定残高テーブル１０４に反映する処理を行うとき、日銀システム２０に送る電文を送信電文テーブル１０６に格納し、電文送信部１０７が、定められたフォーマットの標準電文を日銀システム２０に送信する。日銀システム２０からは、ＥＸ電文（Exchange電文）と呼ばれる電文を受信し、日銀電文受信部１０８が、受信した電文を振り分ける（より詳しくは、ＥＸ電文には、照会に対する応答であるＥＸ応答電文、日銀から一方的に通知されるＥＸ一方通知電文、日銀から一斉に送信される一斉送信電文の３種類がある）。

このとき受信した日銀電文は、後続の配分額明細表リコンサイル部１１１の処理に必要な項目のみを抽出し、日銀受信電文テーブル１０９に格納される。また、日銀から受信したオリジナルの電文（主として、ＸＭＬ：Extensible Markup Language形式）は、日銀オリジナル受信電文テーブル１１０に格納される。国債残高照会の場合は、国債残高照会部１０３に電文の必要な個所が返信される。

配分額明細照会部１０５は、タイマー部１０１のタイマー機能、及びユーザの手動によりジョブネット受付部１０２からのリクエストにより実行される。すなわち、一定間隔または本システムのユーザの操作に基づき、配分額明細を前記日銀システムに照会する。配分額明細照会部１０５は、照会対象銘柄に関する残高照会が常に時点確定残高に保持されているように処理を行う。具体的には、まず、配分額明細照会管理テーブル１１２（図４の上段参照）の全レコードを削除する。なお、配分額明細照会管理テーブル１１２とは、配分額明細照会の照会を管理するために設けられたテーブルであり、常に最新の配分額明細照会の状況を保持する。

配分額明細照会部１０５は、次に、時点確定残高テーブル１０４（図４の下段参照）から、「７４４１−００５０Ｘ：元金配分額明細」電文の送信時に設定する照会対象銘柄を取得する。このときの取得条件は、１）口座番号の５〜６桁目が別途定義された照会対象識別コードに合致すること、２）残高内訳区分＝「国債日銀ネット残高」、かつ、時点確定残高＞０であること、３）償還期日が２営業日後（償還期日が翌営業日であるものを含んでいてもよい）である照会対象銘柄であること、とする。

配分額明細照会部１０５は、照会対象銘柄の時点確定レコードごとに、「７４４１−００５０Ｘ：元金配分額明細」と「７４４１−００６００：利子配分額明細」の電文を作成し、送信電文テーブル１０６に書き出す。ここでの９桁の記号は新日銀ネットにおいて拡張された帳票コードで、以下日銀帳票コードと呼ぶ。そして、配分額明細照会部１０５は、この書き出しと共に、配分額明細照会管理テーブル１１２にもレコードを作成する。なお、配分額明細照会管理テーブル１１２には、図４上段で図示するように、「電文分割総数」、「受信済分割数」、及び「配分額明細照会ステータス」を格納している。「電文分割総数」は、現時点では、国債振替決済利子配分額明細表（７４４１−００６００）以外では１である。分割電文のうちの受信済の電文数が「受信済分割数」に格納される。また、「配分額明細照会ステータス」は、電文が日銀システム２０に送信されたとき、「送信済」となり、日銀システム２０から照会結果を受信したとき、「受信済」となる。

図３に戻り、配分額明細表作成部１１３は、ユーザの手動によるジョブネットから実行され、事前に配分額明細照会部１０５が実行され、配分額明細照会管理テーブル１１２に配分額明細電文の情報が保持されていることを前提とする。配分額明細表作成部１１３は、具体的には以下の処理（１）〜（３）を行う。

（１）配分額明細電文の受領確認：
配分額明細照会管理テーブル１１２の全レコードの照会ステータスが「受信済」となっているかを一定間隔でチェックする。全てのレコードの照会ステータスが「受信済」となっていた場合は、次の（２）の処理へ移行する。

（２）受信電文のＸＭＬ抽出：
日銀オリジナル受信電文テーブル１１０から、送信電文通番（ＩＤ）が配分額明細照会管理テーブル１１２に存在するレコードを全件抽出する。そして、抽出した受信電文通番をキーに、日銀オリジナル受信電文テーブル１１０のレコードを抽出する。

（３）ＸＭＬファイル作成：
日銀オリジナル受信電文は、帳票コードごと、参加者種別コードごとにマージされ、最終的には、利子配分明細、元金配分（源泉徴収対象）、元金配分（源泉対象外）の３つのファイルにマージされる。その際、各電文の日銀メッセージフォーマットに合わせてマージ・成型し、債券取引管理システム２００へデータ連動のためにＸＭＬファイルとして送信する。対象となる日銀帳票コードは、現時点では、７４４１−００５００：国債振替決済元金配分額明細表（償還時源泉徴収対象銘柄以外）、７４４１−００５０１：国債振替決済元金配分額明細表（償還時源泉徴収対象銘柄）、及び７４４１−００６００：国債振替決済利子配分額明細表の３つである。

図１で示したように、現在の銀行システム１０（国債元利金分配システム）は、ＲＴＧＳ決済管理システム１００、債券取引管理システム２００、及び複数の業務システム３００で構成している。しかし、将来は、環境や業務の変化に応じて、より柔軟なシステム構成に統合又は分散していく可能性がある。そのため、日銀システム２０とのインターフェースとなるＲＴＧＳ決済管理システム１００、特に、配分額明細表作成部１１３には、業務システムの構成の変更に備え、業務システムの構成を定義した業務システム構成テーブル１１３ａを有し、元利金の利子配分先の配分明細表の送信先を業務システム構成テーブルに基づいて選択するようにしてもよい。

配分額明細表リコンサイル部１１１（又は単にリコンサイル部）は、日銀システム２０から上記（３）のＥＸ電文を受信した後にリコンサイルエンジンから呼び出される。リコンサイルとは、一般的には、リスク管理の手法の一つであり、営業部門（フロントオフィス）と事務管理部門（バックオフィス）との、お互いが持っている取引データを突合し、誤差等の原因究明を行う作業を言うが、ここでは、電文ごとの所定の処理を行うプログラムを呼出すことを意味する、このために、リコンサイルのマッチングルールを定義し、日銀受信電文テーブル１０９を読出し、マッチングルールに従って適切な処理プログラムを呼び出す。

配分額明細表リコンサイル部１１１は、受信電文の受信電文ステータスを「リコンサイル不要処理済（照会処理のみ）」に更新し、受信電文の送信電文通番をキーに、配分額明細照会管理レコードを検索する。そして、受信電文の日銀帳票コードを判断し、７４４１−００５０１又は７４４１−００５０２の場合は、配分額明細照会管理テーブル１１２の「電文分割総数」と「受信済分割数」を「１」とし、照会ステータスを「受信済」に更新する。日銀帳票コードが７４４１−００６００の場合は、受信電文のメッセージ分割表示区分コードが１（「続きあり表示あり」）の場合は、電文分割総数は更新しないが、受信電文のメッセージ分割表示区分コードが２（「終了表示あり」）の場合、電文分割総数を、受信した電文の分割番号に更新する。そして、受信済分割数を１プラスする。

また、「照会ステータス」は、電文分割総数が受信済分割数に等しくない場合は、更新しないが、電文分割総数が受信済分割数に等しい場合には「受信済」に更新する。

図５は、本発明の実施形態に係る債券取引管理システム２００の機能構成を示す図である。債券取引管理システム２００は、大きく分けて、元利金処理サブシステム２１０、残高管理サブシステム２２０、顧客情報サブシステム２３０、債券情報サブシステム２４０、及び担保管理サブシステム２５０のサブシステムで構成され、国債以外にも一般債の取引全体をも管理するシステムである。元利金処理サブシステム２１０は、さらに、元利金データ管理部２１１、課税情報申告データ管理部２１２、ＲＴＧＳシステム連動管理部２１３、元利金関連照会部２１４、及び関連するデータベース２１５〜２１９で構成される。以下では、元利金処理サブシステム２１０を中心に債券取引管理システム２００の処理を説明する。

元利金処理サブシステム２１０の元利金データ管理部２１１は、残高管理サブシステム２２０から債券の残高情報を読み出し、顧客情報サブシステム２３０から円決済情報を読み出し、債券情報サブシステム２４０から債券の銘柄情報を読み出す。また、元利金データ管理部２１１は、債券元利払対象残高２１５、債券課税情報申告データ２１６、元利金データ２１７、日銀元利金情報２１８、債券元利金決済予定通知２１９等のデータベースを介して、課税情報申告データ管理部２１２、ＲＴＧＳシステム連動管理部２１３、及び元利金関連照会部２１４、並びにＲＴＧＳ決済管理システム１００及び業務システム３００とデータ連動を行う。

例えば、元利金処理サブシステム２１０は、ＲＴＧＳ決済管理システム１００を介して、日銀システム２０から取得した日銀元利情報を日銀元利金情報２１８に格納し、業務システム３００から元利金請求データや元利払対象残高を取得し、債券元利金決済予定通知２１９をＲＴＧＳ決済管理システム１００に送信する。また、課税情報を申告するためのデータを作成する課税情報申告データ管理部２１２とは、債券課税情報申告データ２１６のデータベースを介してデータを連動する。また、元利金関連の各種の照会機能を有する元利金関連照会部２１４とは、債券元利払対象残高２１５、元利金データ２１７、日銀元利金情報２１８等のデータベースを介してデータを連動する。

なお、図示は省略しているが、債券取引管理システム２００は、確定明細照合手段においてデータの不一致が検出された場合、不一致の原因の類型を記憶した「類型テーブル」に基づいて、当該不一致の原因を関連部署に通知する通知手段をさらに備えてもよい。

具体的には、発生頻度の高いエラー（例えば、（１）元利金配分先変更が反映されていない、（２）業務システムから前回のデータが送信されてきた、（３）税額計算に誤りがある等）の類型を、ユーザが登録、若しくはシステムが分析することによって、エラー頻度が高い順に順位付けして類型テーブルに記憶しておく。そして、エラーが発生したデータについて、類型テーブルのどの類型に該当するかを頻度の高い順から、推定していく。そして、（１）の類型であれば、元利金分配先変更のデータとエラーが発生したデータの差分を比較する、（２）の類型であれば、前回データと比較する、（３）の類型であり、例えば税引前利益が一致するが税引後の利益が不一致となる場合は、課税情報申告データ管理部２１２の「税額計算テーブル」を比較する、等の処理を行う。通知手段は、このようにしてエラーの原因が推定できればその原因を、原因を推定できなければその旨を関連部署に通知する。

このようにすることで、照合結果に不一致があった場合でも、迅速にその原因を調べ、解決に向かわせることができる。特に、発明の課題でも挙げたように、日銀で管理している元利金分配明細と銀行内で管理している元利金分配明細との照合を、今後は数時間で行う必要があるという状況を考えれば、このような通知手段が重要となる。

図６は、元利金データ管理部２１１のより詳細な機能構成を示す図である。細かい説明は省略するが、元利金データ管理部２１１は、元利金データ２１７を中心にデータの作成と更新を行い、各システム又はサブシステムからの様々な照会に対して、元利金データ２１７等のデータを元に、照会結果を作成し返信する。

元利金データ管理部２１１は、このデータの照合時、利子配分先の変更が必要であると判断した場合は、配布先の変更データを入力させ、日銀ネットに送信する利子配分先変更手段２１１ａを有する。利子配分先変更手段２１１ａは、利子配分先を登録した「利子配分登録テーブル」（データベース）を備え、この利子配分登録テーブルに基づいて、照合時の利子配分先が利子配分登録テーブルの利子配分先と不一致がある場合に、利子配分先の変更が必要であると判断してもよい。また、債券取引管理システム２００で管理している情報と予定明細の情報を比較し、その差異から利子配分先データを作成するようにしてもよい。このため、図示は省略するが、債券元利払対象残高２１５や元利金データ２１７等の主要なデータベースやテーブルには、履歴管理、状況管理のためにデータ更新ライブラリ２１５ａ、２１７ａ等が設けられている。また、上記の利子配分登録テーブルにも同様なデータ更新ライブラリを設けてもよい。

元利金データ２１７には、詳細には、債券元利金情報、債券元利金承認情報、及び業務システム３００から取り込んだ国債元利金情報が含まれる。また、元利金データ管理部２１１は、債券元利払対象残高２１５を、債券残高情報や債券銘柄情報を参照して常に最新の情報に更新する。

図７は、元利金処理サブシステム２１０内の課税情報申告データ管理部２１２の機能構成を示す図である。詳細説明は省略するが、課税情報申告データ管理部２１２は、債券情報サブシステム２４０からの債券銘柄情報、元利金データ２１７の債券元利金情報、債券元利払対象残高２１５等を参照して生成した債券課税情報申告データ２１６から、課税情報申告データファイルを作成して、業務システム３００ａに送信し、保振端末３０ａに対してはＣＳＶファイルを送信し、最終的に保振（証券保管振替機構）システム３０に課税申告データを送信する。また、送信した内容は、保振システム３０から申告したデータの入力処理内容通知を受け取ると、そのファイルを取込み、照合して、課税情報申告照合結果に格納する。

図８は、元利金処理サブシステム２１０内の元利金関連照会部２１４及びＲＴＧＳシステム連動管理部２１３の機能構成を示す図である。元利金関連照会部２１４は、各サブシステムからの元利金関連の照会、例えば、保有債券の償還銘柄予定の照会、元利金明細の照会、担保利金の償還予定の照会、元利払対象予定残高の照会等に対してその照会結果を返信する機能を有する。

ＲＴＧＳシステム連動管理部２１３は、ＲＴＧＳ決済管理システム１００とのデータ連動のためのインターフェースを司る。ここで連動するデータは、一般債と国債に分かれるが、業務システム３００ａから取得した一般債及び国債の債券元利金予定通知２１９ａ、２１９ｂに従い（図６参照）、元利金連動指示をＲＴＧＳ決済管理システム１００に送信する機能を有する。

以上説明した本システムの機能構成は、あくまで一例であり、一つの機能ブロック（サブシステム、サブシステム内の機能処理部、及び各データベース）を分割したり、複数の機能ブロックをまとめて一つの機能ブロックとして構成したりしてもよい。各機能処理部は、装置に内蔵されたＣＰＵ（Central Processing Unit）が、ＲＯＭ（Read Only Memory）又はハードディスク等の記憶装置に格納されたコンピュータ・プログラムを読み出し、ＣＰＵにより実行されたコンピュータ・プログラムによって実現される。すなわち、各機能処理部は、このコンピュータ・プログラムが、記憶装置に格納されたデータベース（ＤＢ;Data Base)やメモリ上の記憶領域からテーブル等の必要なデータを読み書きし、場合によっては、関連するハードウェア（例えば、入出力装置、表示装置、通信インターフェース装置）を制御することによって実現される。また、本発明の実施形態におけるデータベース（ＤＢ）は、商用データベースであってよいが、単なるテーブルやファイルの集合体をも意味し、データベースの内部構造自体は問わないものとする。

（照会画面例）
図９は、国債元利金明細照会結果の画面表示例を示す図である。この照会結果画面は、債券取引管理システム２００が生成し、関連部署またはバックエンド部署の担当者が照会結果を確認するための画面である。

図示するように、銘柄ごとに、利払日（償還日）、銘柄コード（ＩＳＩＮ：International Securities Identification Numberコードとも呼ぶ）、銘柄略称、口座区分が表示され、さらに、照会項目として、償還金、税引前利金、所得税額、税引後利金が、Ａ（当銀行を表す）とＢ（日銀を表す）に分けて表示される。照合項目はこれに限らず他の情報、例えば、銀行内で内部的に管理している銘柄コード等を含ませることが可能である。

この画面からもわかるように、銀行内のシステムによって算出した各項目Ａと日銀から取得した各項目Ｂとが完全に一致したときに、照合結果は「ＯＫ」となり、一つでも一致しないときは、照合結果は「ＮＧ」となる。図の例では、償還金以外の項目で数値が一致していないため、一致しない項目がグレー表示されている。

このような不一致（ＮＧ）が発生した場合には、図示するような、「詳細情報ボタン」が画面上に表示される。このボタンを押下すると、不一致の原因が前述した類型テーブルから推定できる場合は、その原因を表示する。また、原因が類型テーブルからでは推定できない場合は、不一致を起こしたデータに関連するデータ入力の履歴等の詳細データを表示する。この履歴情報の取得の際には、データベースの履歴や更新状況を管理する前述のデータ更新ライブラリ２１５ａ、２１７ａ等を利用してもよい。そして、その詳細データを参照して、関係部署に通知する通知ボタンを表示するようにしてもよい。このようにすることで、本システムのデータ連動により、不一致が起きた場合の詳細及び原因を迅速に調べることができる。

（実施形態の効果）
本システムによれば、新日銀ネットに対応し、複雑な国債元利金分配の照合を効率的に行うことが可能な国債元利金分配システムを提供することができる。特に、債券取引管理システム２００と業務システム３００をデータ連動させることにより、従来は２営業日かけて行っていた照合を数時間で行えるようになる。また、照合結果に不一致があった場合でもその原因を推定し、関係部署に通知することができる。また、将来の業務システムの再構成にも柔軟に対応できる。また、利子配分先に変更があった場合でも、それを速やかに検出し、対処することができる。

以上、実施形態を用いて本発明を説明したが、本発明の技術的範囲は上記実施形態に記載の範囲には限定されないことは言うまでもない。特に、本発明の実施形態を銀行システム１０として説明したが、他の金融機関にも応用が可能である。上記実施形態に、多様な変更または改良を加えることが可能であることが当業者に明らかである。またその様な変更または改良を加えた形態も本発明の技術的範囲に含まれ得ることが、特許請求の範囲の記載から明らかである。なお、上記実施形態の国債元利金分配システムは、国債元利金分配方法の発明と捉えることも可能である。

１０ 銀行システム（国債元利金分配システム）
２０ 日銀システム
３０ 保振システム
３０ａ 保振端末
１００ ＲＴＧＳ決済管理システム
２００ 債券取引管理システム
２１０ 元利金処理サブシステム
２１１ 元利金データ管理部
２１１ａ 利子配分先変更手段
２１２ 課税情報申告データ管理部
２１３ ＲＴＧＳシステム連動管理部
２１４ 元利金関連照会部
２１５ 債券元利払対象残高
２１６ 債券課税情報申告データ
２１７ 元利金データ
２１８ 日銀元利金情報
２１９ 債券元利金決済予定通知
２１９ａ 一般債元利金決済予定通知
２１９ｂ 国債元利金決済予定通知
２２０ 残高管理サブシステム
２３０ 顧客情報サブシステム
２４０ 債券情報サブシステム
２５０ 担保管理サブシステム
３００、３００ａ、３００ｂ、・・・ 業務システム

Claims (5)

1. 新日銀ネットに対応した金融機関における国債元利金分配システムであって、
   日銀システムから国債の償還日の所定期日に元利金配分の予定明細を取り込む予定明細照会手段と、
   前記予定明細を当該金融機関が扱っている債券の取引データを管理する債券取引管理システム及び債券の取引形態や運用ごとに顧客対応の処理を行う業務システムとの間でデータを照合する予定明細照合手段と、
   前記予定明細照合手段において、利子配分先の変更が必要と判断された場合は、利子配分先変更データを作成し、前記日銀システムに送信する利子配分先変更手段と、
   前記日銀システムから国債の償還日の前日までに元利金配分の確定明細を取り込む確定明細照会手段と、
   前記確定明細を前記債券取引管理システムと前記業務システムとの間で再度照合する確定明細照合手段と、を備え、
   前記確定明細照合手段において、データの不一致が検出された場合には、前記債券取引管理システムと前記業務システムに格納された関連するデータを検索し、詳細を提示することを特徴とする国債元利金分配システム。
2. 前記確定明細照合手段においてデータの不一致が検出された場合、前記不一致の原因の類型を発生頻度順に記憶した類型テーブルに基づいて、当該不一致の原因を関連部署に通知する通知手段をさらに備えることを特徴とする請求項１に記載の国債元利金分配システム。
3. 国債元利金分配システムは、前記業務システムの構成を定義した業務システム構成テーブルを有し、前記利子配分先の配分明細表の送信先を前記業務システム構成テーブルに基づいて選択する配分額明細表作成部を備えることを特徴とする請求項１に記載の国債元利金分配システム。
4. 前記予定明細照合手段は、前記利子配分先を登録した利子配分登録テーブルに基づいて、照合時の利子配分先が前記利子配分登録テーブルの利子配分先と不一致がある場合に、利子配分先の変更が必要であると判断することを特徴とする請求項１に記載の国債元利金分配システム。
5. 新日銀ネットに対応した金融機関における国債元利金分配方法であって、
   前記金融機関のシステムが、
   当該金融機関が扱っている債券の取引データを管理する債券取引管理システムと、
   債券の取引形態や運用ごとに顧客対応の処理を行う業務システムとを含んで構成され、
   前記金融機関のシステムのコンピュータが、
   日銀システムから国債の償還日の所定期日に元利金配分の予定明細を取り込むステップと、
   前記予定明細を前記債券取引管理システム及び前記業務システムとの間でデータを照合するステップと、
   前記予定明細を照合するステップにおいて、利子配分先の変更が必要と判断された場合は、利子配分先変更データを作成し、前記日銀システムに送信するステップと、
   前記日銀システムから国債の償還日の前日までに元利金配分の確定明細を取り込むステップと、
   前記確定明細を前記債券取引管理システムと前記業務システムとの間で再度照合するステップと、
   前記確定明細を再度照合するステップにおいて、データの不一致が検出された場合には、前記債券取引管理システムと前記業務システムに格納された関連するデータを検索し、詳細を提示するステップと、
   を実行することを特徴とする国債元利金分配方法。