JP2016015087A - 代行決済システム、管理サーバ、プログラム及びその方法 - Google Patents

Abstract

【課題】代行決済の出金処理を滞りなく実行可能な代行決済システム及びその方法を提供する。
【解決手段】代行決済システム１は、代行決済を委託する顧客の顧客端末２０と、金融機関の管理サーバ１１と、日銀ネットシステム３０とが接続されている。顧客端末２０は、前記顧客の資金決済口座における入金予定の入金データと出金予定の出金データとを入力する入力手段２３を備える。また、管理サーバ１１は、入金データ及び出金データを顧客端末２０から受信する入出金データ受信手段１５と、受信した入金データと出金データとを紐付けて決済させるための決済予定明細を顧客に作成させる決済予定明細作成手段１６と、決済予定明細における入金データの入金処理の完了を条件に、日銀ネットシステム３０に対して、入金データに紐付された出金データの出金処理を実行する出金処理手段１８とを備える。
【選択図】図１

Description

本発明は、日本銀行が提供するＲＴＧＳ（即時決済）システムと接続して、顧客の代行決済を行う代行決済システムに関する。

日本銀行には、当座預金等の即時決済（ＲＴＧＳ（Real Time Gross Settlement））を行うためにオンラインで決済ができるコンピュータシステムが備えられている。ＲＴＧＳとは、日本銀行が金融機関から振替指図を受信し次第、１件ずつ即座に決済するシステムである。

金融機関は、顧客から資金の決済代行の依頼を受任すると、顧客に代わって、上述した日本銀行のＲＴＧＳシステムと接続し、代行決済を行うＲＴＧＳ代行決済システムを利用する。このことは、例えば、特許文献１に詳細に記載されている。

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

ところで、現状のＲＴＧＳ代行決済システムは、取引の出金の当日、顧客によるシステム承認の入力（支払承認）を得てから、出金処理を実行する。しかしながら、当日の出金指定時刻に想定外の事情等で顧客の担当者が不在となった場合、支払承認が得られないため出金処理を実行できなくなる。

本発明は、このような課題に鑑みてなされたものであり、代行決済の出金処理を滞りなく実行可能な代行決済システム、管理サーバ、プログラム及びその方法を提供することを目的とする。

上記課題を解決するため、本発明の代行決済システム及びその方法は、以下のような解決手段を提供する。

本発明の第一の態様では、代行決済を委託する顧客の顧客端末と、金融機関の管理サーバと、日銀ネットシステムとが接続された代行決済システムであって、前記顧客端末は、前記顧客の資金決済口座における入金予定の入金データと出金予定の出金データとを入力する入力手段を備え、前記管理サーバは、前記入金データ及び前記出金データを前記顧客端末から受信する受信手段と、前記受信した入金データと前記出金データとを紐付けて決済させるための決済予定明細を前記顧客に作成させる決済予定明細作成手段と、前記決済予定明細における前記入金データの入金処理の完了を条件に、前記日銀ネットシステムに対して、前記入金データに紐付された出金データの出金処理を実行する出金処理手段と、を備えることを特徴とする。

また、上記の代行決済システムにおいて、前記決済予定明細作成手段は、少なくとも入金予定額、出金予定額、及び決済予定日時を含む条件が合致する入金データと出金データを顧客に選択させ、前記入金データと前記出金データとを紐付けた入出金データ紐付けテーブルを登録して前記決済予定明細を作成してもよい。

また、上記の代行決済システムにおいて、前記決済予定明細作成手段は、一つの前記入金データに対して、一又は複数の前記出金データを紐付けてもよい。

また、上記の代行決済システムにおいて、前記決済予定明細作成手段は、複数の前記入金データに対して、一つの前記出金データを紐付けてもよい。

また、上記の代行決済システムにおいて、前記決済予定明細作成手段は、複数の前記入金データに対して、複数の前記出金データを紐付けてもよい。

本発明の第二の態様では、代行決済を委託する顧客の顧客端末と、金融機関の管理サーバと、日銀ネットシステムとが接続された代行決済システムにおける前記管理サーバであって、入金データ及び出金データを前記顧客端末から受信する入出金データ受信手段と、前記受信した入金データと前記出金データとを紐付けて決済させるための決済予定明細を前記顧客に作成させる決済予定明細作成手段と、前記決済予定明細受信手段が受信した前記決済予定明細における前記入金データの入金処理の完了を条件に、前記日銀ネットシステムに対して、前記入金データに紐付された出金データの出金処理を実行する出金処理手段と、を備えることを特徴とする。

本発明の第三の態様では、代行決済を委託する顧客の顧客端末と、金融機関の管理サーバと、日銀ネットシステムとが接続された代行決済システムにおける前記管理サーバのプログラムであって、コンピュータに、入金データ及び出金データを前記顧客端末から受信する受信するステップと、前記受信した入金データと前記出金データとを紐付けて決済させるための決済予定明細を前記顧客に作成させるステップと、受信した前記決済予定明細における前記入金データの入金処理の完了を条件に、前記日銀ネットシステムに対して、前記入金データに紐付された出金データの出金処理を実行するステップと、を実行させることを特徴とする。

本発明の第四の態様では、代行決済を委託する顧客の顧客端末と、金融機関の管理サーバと、日銀ネットシステムとが接続され、前記管理サーバが前記顧客端末の代行決済を行う方法であって、前記顧客端末において、前記顧客の資金決済口座における入金予定の入金データと出金予定の出金データとを入力するステップと、前記管理サーバにおいて、前記入金データ及び前記出金データを前記顧客端末から受信するステップと、前記受信した入金データと前記出金データとを紐付けて決済させるための決済予定明細を前記顧客に作成させるステップと、受信した前記決済予定明細における前記入金データの入金処理の完了を条件に、前記日銀ネットシステムに対して、前記入金データに紐付された出金データの出金処理を実行するステップと、を有することを特徴とする。

本発明によれば、代行決済の出金処理を滞りなく実行可能な代行決済システム、管理サーバ、プログラム及びその方法を提供することができる。

本発明の実施形態に係る代行決済システムの全体構成を示す図である。 本発明の実施形態に係る顧客端末の機能構成を示すブロック図である。 本発明の実施形態に係る管理サーバの機能構成を示すブロック図である。 一つの入金データに対して、複数の出金データを紐付ける入出金データテーブルと入出金データ紐付けテーブルを示す図である。 複数の入金データに対して、一つの出金データを紐付ける入出金データテーブルと入出金データ紐付けテーブルを示す図である。 本発明の実施形態に係る代行決済システムの処理動作を示すシーケンス図である。 本発明の実施形態に係る顧客端末で操作する決済予定明細作成画面の操作処理を示すフローチャートである。 本発明の実施形態に係る管理サーバの処理動作を示すフローチャートである。 一つの入金データに対して、複数の出金データを紐付けした場合の表示画面構成１を示す図である。 一つの入金データに対して、複数の出金データを紐付けした場合の表示画面構成２を示す図である。 一つの入金データに対して、複数の出金データを紐付けした場合の表示画面構成３を示す図である。 一つの入金データに対して、複数の出金データを紐付けした場合の表示画面構成４を示す図である。 複数の入金データに対して、複数の出金データを紐付けした場合の表示画面構成１を示す図である。 複数の入金データに対して、複数の出金データを紐付けした場合の表示画面構成２を示す図である。

以下、添付図面を参照して、本発明を実施するための形態（以下、実施形態という）について詳細に説明する。なお、実施形態の説明の全体を通して同じ要素には同じ番号を付している。

（実施形態の構成）
図１は、本実施形態に係る代行決済システムの全体の構成図である。代行決済とは、銀行等の金融機関が顧客の依頼に基づき、金融機関の日銀当座預金を利用して、顧客の資金決済を代行するサービスのことをいう。対象取引としては、コール取引の資金決済、ＣＤ（Certificate of Deposit）・ＣＰ（Commercial Paper）の資金決済、国債・一般債等のＤＶＰ（Delivery Versus Payment）資金決済、その他日銀当座預金を利用した資金決済がある。

図１に示すように、本実施形態に係る代行決済システム１は、金融機関のシステム１０と、銀行ネット専用回線４０を介して接続された代行決済を委託する委託者側に設置された顧客端末２０と、金融機関のシステム１０と日銀ネット専用回線５０を介して接続された日銀ネットシステム３０とから構成される。なお、ここでいう専用回線とは、物理的に隔離されたネットワークの他、論理的に隔離されたセキュアなネットワークを含む。

金融機関のシステム１０は、管理サーバ１１と、ＲＴＧＳ決済管理システム１２とを備えている。管理サーバ１１は、決済処理、貸越管理等を行うための専用プログラムが搭載されている制御手段１３と、少なくとも、決済明細を管理するプログラムで使用する資金情報を保存しているトランザクションＤＢ（データベース）１００と、顧客ごとの資金（預金）残高情報、貸越枠を保存している残高ＤＢ（データベース）２００と、顧客に関する会社情報、例えば、名称、住所、担当者名や銀行との契約情報等を管理するため情報を保存している顧客ＤＢ（データベース）３００とを含む。顧客は、本システムが提供するサービス（「日銀当座預金代行決済サービス」と呼ぶ）を利用するためには、資金化済の資金（Available Money)を区別するための決済口座を有する。決済口座は１つであってもよいが、決済口座を２つとし、決済口座１（営業店決済口座）を銀行の営業店に開設し、日銀当座預金にて決済する資金を管理するための決済口座２（ＲＴＧＳ専用口座）を本システム上に別途開設してもよい。この場合、決済口座２が基準となる「出金」は、日銀ネットを介した外部宛が主であるが、決済口座１宛に営業店振替で資金を戻す際も、決済口座２からの「出金」となる。残高ＤＢ２００は、特に、決済口座２の残高を顧客ごとに管理するデータベースである。

ＲＴＧＳ決済管理システム１２（以下、本システムという）は、金融機関（以下、銀行とする）のシステム１０内に設置されるシステムであり、日銀ネットシステム３０と日銀ネット専用回線５０を介して接続されており、日銀ネットシステム３０に対する各種の電文の送受信、流動性資金の管理を行うためのプログラムが搭載されている。本システムは、顧客の上記の決済口座１と決済口座２を使って、銀行の日銀口座及び顧客の取引先の日銀取引口座間で資金決済を代行するサービスを提供する。

顧客端末２０は、代行決済を委託する顧客（委託者）側に設置された端末であり、パーソナルコンピュータやワークステーションなどの汎用のコンピュータであってもよい。顧客端末２０は、例えば、ブラウザ又は専用ソフトから管理サーバ１１にアクセスして、後述する決済予定明細作成のための入金データ及び出金データを入力し、承認後の決済予定明細に基づいて、入金データに紐付けられた出金データの決済の指図を行う。ここで、決済予定明細とは、予定された特定の入金があったことを条件に同じ決済日の特定の出金を行うように指図するための入金データと出金データを紐付けた情報であるが、詳しくは後述する。また、顧客社内システム６０は、顧客が独自に保有する社内処理システムであり、日々の入出金のデータを管理している。顧客端末２０は、顧客社内システム６０と必ずしも接続されている必要はなく、顧客社内システム６０からＦＤ等の記録媒体にデータを切り出し、顧客端末２０に取り込むこと、あるいは、顧客端末２０の操作者がそのデータを目視確認し、手入力することも可能である。

（顧客端末２０の構成）
図２は、本実施形態に係る顧客端末の機能構成を示すブロック図である。図２に示すように、顧客端末２０は、通信手段２１と、記憶手段２２と、入力手段２３と、表示手段２４と、制御手段２５とから構成される。

通信手段２１は、管理サーバ１１との通信を行う際の通信インターフェースを司り、銀行ネット専用回線４０が採用するプロトコルに準拠した通信を行う。

記憶手段２２は、書き換え可能な、例えば、フラッシュメモリで構成され、制御手段２５が実行するプログラムや各種データが格納されている。各種データの一つとして、入出金データ４００が格納されている。入出金データ４００とは、顧客の資金決済に関する入金予定及び出金予定の明細情報（入金・出金の予定日及び予定時刻、入金・出金の予定金額、入金元の情報、出金先の情報等）であり、決済予定明細を作成する際には、顧客の指示に基づいて、主に代行決済の対象となる入出金データが通信手段２１を介して、管理サーバ１１に送信される。

入力手段２３は、例えば、キーボードやマウス等の入力機器であり、入出金データを記憶手段２２に格納する操作入力、記憶手段２２に格納された入出金データを管理サーバ１１に送信する操作入力、あるいは管理サーバ１１が提供する所定の入力画面から入出金データを手操作で入力させる手段を提供する。記憶手段２２に入出金データを格納する手段としては、顧客社内システム６０からダウンロードする方法、又はＦＤ等の記録媒体に出力されたデータを記憶手段２２に格納するようにしてもよい。

表示手段２４は、管理サーバ１１からの各種の画面を表示する機器であり、例えば、ＬＣＤ（Liquid Crystal Display）や有機ＥＬ（Organic Electro-Luminescence）などのディスプレイである。なお、入力手段２３と表示手段２４は、入力機能と表示機能を合わせ持つタッチパネルで構成してもよい。

制御手段２５は、ＣＰＵ（マイクロプロセッサ）が記憶手段２２に記憶されたプログラムを逐次読み出し実行することにより、顧客の資金決済口座における入金予定の入金データと出金予定の出金データとを紐付けた決済予定明細を管理サーバ１１が用意した入出金紐付作成画面から作成し、作成された決済予定明細が顧客内で承認された後に、管理サーバ１１へ送信して決済代行処理を要求する。詳細については後述する。

（管理サーバ１１の構成）
図３は、本実施形態に係る管理サーバ１１の機能構成を示すブロック図である。図３に示すように、管理サーバ１１は、一例として、制御手段１３と、トランザクションＤＢ１００と、残高ＤＢ２００と、顧客ＤＢ３００とから構成される。

制御手段１３は、顧客端末２０により入力された入出金データを受信し、入力データと出力データを紐付けた予定決済明細を顧客に作成させ、その予定決済明細が決済可能か否かの判定を行い、決済可能であれば、決済代行に伴う出金処理を行う一連の流れを制御する。そのため、制御手段１３は、通信手段１４と、入出金データ受信手段１５と、決済予定明細作成手段１６と、判定手段１７と、出金処理手段１８とを含む。

通信手段１４は、顧客端末２０及び日銀ネットシステム３０と通信を行う際の通信インターフェースを司る。実際には、顧客端末２０と日銀ネットシステム３０とは、別々の通信インターフェースが用いられるが、ここでは一つにまとめて記載している。

入出金データ受信手段１５は、顧客端末２０から顧客の資金決済口座における入金予定の入金データと出金予定の出金データとを受信し、データになんらかのエラーがないかをチェック後、決済予定明細作成手段１６へ引き渡す。データにエラーがあれば、その旨を顧客端末２０に返信し、正しい入出金データの送信を要求する。

決済予定明細作成手段１６は、顧客端末２０から入力された入金データと出金データを顧客に紐付けさせる画面を作成し、顧客端末２０に送信する。顧客は、この画面から紐付する入金データと出金データを選択する。画面の具体例については後述する。そして、顧客が紐付けた情報に基づいて、入金データと出金データを紐付けて決済するための明細である決済予定明細を作成する。具体的には、後述の入出金データテーブル１１０に基づいて、入出金データ紐付けテーブル１２０を作成する。ここで、入金データと出金データの紐付は、１：１に限らず、一つの入金データに対して、一又は複数の出金データを紐付けした１：Ｎ紐付け、複数の入金データに対して、一つの出金データを紐付けしたＮ：１紐付け、複数の入金データに対して、複数の出金データを紐付けしたＮ：Ｍ紐付け（ただし、Ｎ：Ｍは自然数）であってもよい。

判定手段１７は、決済予定明細作成手段１６が作成した決済予定明細における入金データとその入金データに紐付けられた出金データが条件に合致しているか否かを判定する。具体的には、作成した決済予定明細の予定した入金金額と予定した出金金額とを参照し、出金金額の合計が入金額≧出金額であり、かつ入金処理よりも出金処理の決済予定時刻が遅いことを判定する。すなわち、特定の入金が、入金より後であって、その入金に紐付けられた出金の原資となり得るかどうかを判定する。そして、判定手段１７は、決済日当日に、上記の判定結果がＯＫであることを確認し、実際のその特定の入金が予定どおりに行われたことを条件に、その入金に紐付けられた出金を実行するために出金処理手段１８を起動する。

出金処理手段１８は、判定手段１７によって、入金データの入金処理の完了を確認されたことを条件（契機）に、日銀ネットシステム３０に対して入金データに紐付けられた出金データの出金処理を実行する。

トランザクションＤＢ１００は、顧客ごとの所定期間の入出金情報を格納する入出金データテーブル１１０と、入出金データテーブル１１０の顧客の承認済みの入出金データが紐付けられた情報を格納する入出金データ紐付けテーブル１２０とが割り付けられ記憶される。以下、入出金データテーブル１１０と、入出金データ紐付けテーブル１２０の具体例を示す。

図４（ａ）に示すように、入出金データテーブル１１０は、少なくとも受託者を管理するためのユニークな番号である受託者受付番号と、入金、出金の判別をする入出金区分と、決済に伴う金額を表示する決済金額のデータ項目を含む。

また、入出金データ紐付けテーブル１２０は、少なくとも入金と出金とに区別された受託者受付番号と、入金と出金とに区別された決済金額のデータ項目を含み、受託者受付番号をキーとして、入金データと出金データを紐付ける。

入出金データの紐付けは、例えば、図４（ａ）に示すように、入出金データテーブル１１０には、決済予定の入出金情報が格納されており、紐付け前は入出金データ紐付けテーブル１２０のテーブルは空となっている。そして、顧客によって、入出金情報の紐付けが行なわれると、図４（ｂ）に示すように、入出金データを紐付けた件数分のレコードが作成され、入金データの入金金額１，０００に対して、複数（本説明では３件）の出金データが紐付けされる（１：Ｎ紐付け）。また、紐付け完了後は、図４（ｃ）に示すように、紐付けられたレコードは削除され、空の状態となる。詳細は、後述する。

また、複数の入金データに対して、一つの出金データの紐付け（Ｎ：１紐付け）を行う場合は、例えば、図５（ａ）に示すように、入出金データテーブル１１０には、決済予定の入出金情報が格納されており、紐付け前は入出金データ紐付けテーブル１２０のテーブルは空となっている。そして、顧客によって、入出金情報の紐付けが行なわれると、図５（ｂ）に示すように、入出金データを紐付けた件数分、レコードが作成され、出金データの入金金額２，０００に対して、複数（本説明では３件）の入金データが紐付けされる（Ｎ：１紐付け）。また、紐付け完了後は、図５（ｃ）に示すように、紐付けられたレコードは削除され、空の状態となる。詳細は、後述する。図示は省略するが、Ｎ：Ｍ紐付けの場合も同様である。

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

（代行決済システム１の処理動作）
図６は、本実施形態に係る代行決済システム１の処理動作を示すシーケンス図である。図６に示すように、顧客端末２０は、資金の決済代行を行う場合に、まず、顧客の資金決済口座における入金予定の入金データと出金予定の出金データとを入力し（ステップＳ１０１）、その情報を管理サーバ１１へ送信する。

管理サーバ１１は、顧客端末２０から顧客の資金決済口座における入金予定の入金データと出金予定の出金データとを受信する（ステップＳ１０２）。そして、受信した入金データと出金データとを紐付けて決済させるための決済予定明細を顧客に作成させる（ステップＳ１０３）。

詳細には、図７に示す顧客端末２０で操作する決済予定明細作成画面の操作処理を示すフローチャートにて説明する。図７に示すように、顧客端末２０は、銀行ネット専用回線４０に接続し、予めインストールされているブラウザを起動する（ステップＳ２０１）。顧客は、ブラウザを起動すると、画面上にユーザ認証が表示され、ユーザＩＤとパスワードを入力する。管理サーバ１１は、顧客ＤＢ３００から顧客情報を参照し、そのユーザ認証情報が一致した場合、ログイン許可を送信することでブラウザが起動される。ブラウザが起動すると、残高ＤＢ２００及び顧客ＤＢ３００から、ログインした顧客の顧客情報が反映される。

ブラウザを起動すると、所定のメニュー画面が表示され、顧客がこのメニュー画面から予定決済明細作成を選択すると、例えば、図９に示す予定決済明細画面が表示される。顧客は、表示された予定決済明細画面に入力手段２３で操作することにより、決済予定の入出金情報の検索を行うことができる（ステップＳ２０２）。管理サーバ１１の制御手段２５は、この検索要求を受信すると、管理サーバ１１に格納されているトランザクションＤＢ１００の入出金データテーブル１１０を参照し、表示手段２４に入出金情報を表示する（ステップＳ２０３）。そして、顧客が、表示された入出金情報を参照し、入出金情報の紐付け操作を行う（ステップＳ２０４）と、入出金データが紐付けられ、管理サーバ１１の入出金データ紐付けテーブル１２０に記憶されるとともに、顧客端末２０の表示手段２４に表示される。

そして、決済予定明細作成手段１６は、入出金情報の紐付けを行うと、紐付け処理に問題があるか否か判定を行う（ステップＳ２０５）。すなわち、入金データに紐付け可能な出金データが、「紐付け対象入金データ決済金額 ≧ 既に紐付け済みの出金データ決済金額累計 ＋ 今回の紐付け対象出金データの決済金額」であるか判定を行う。複数の入金データと複数の出金データが紐付けられている場合は、入金額、出金額がそれぞれの合計額が比較される。決済予定明細作成手段１６は、入金額と出金額の比較の判定結果がＯＫの場合（ステップＳ２０５“ＹＥＳ”）、顧客端末２０の画面に決済予定明細の承認要求を行う。例えば、ポップアップ画面に承認ボタンを表示し、顧客がそのボタン押下することによって決済予定明細の承認が完了する（ステップＳ２０６）。そして、承認済みの決済予定明細を管理サーバ１１に送信し、定められた決済日に決済代行処理要求を行う（ステップＳ２０７）。なお、判定結果がＮＧの場合（ステップＳ２０５“ＮＯ”）、決済予定明細作成手段１６は、表示手段２４を介して、画面に警告メッセージ（例えば、ポップアップ画面に表示）を表示し（ステップＳ２０８）、再度ステップＳ２０３の処理に戻る。

図６に戻り、決済日前日及び当日において、管理サーバ１１の判定手段１７は、受信した決済予定明細の内容が決済可能か判定する。判定処理は、決済前日までに判定を行なう処理（ステップＳ１０４）と、決済日当日に判定を行う処理（ステップＳ１０５）に分けられる。そして、管理サーバ１１は、決済予定明細における入金データの入金処理の完了を条件に、日銀ネットシステム３０に対して、入金データに紐付された出金データの出金処理を実行する（ステップＳ１０６）。

詳細には、図８に示す管理サーバ１１の処理動作を示すフローチャートにて説明する。図８に示すように、管理サーバ１１の入出金データ受信手段１５は、顧客端末２０から前記顧客の資金決済口座における入金予定の入金データと出金予定の出金データとを受信する（ステップＳ３０１）。受信した入金データ又は出金データに何らかのエラーがあれば、そのエラーを通知し、再度入力を行うように促す。そして、決済予定明細作成手段１６は、受信した入金データと出金データとを紐付けた決済予定明細を前述の決済予定入力画面を使って顧客に作成させる（ステップＳ３０２）。

管理サーバ１１の判定手段１７は、顧客端末２０から決済代行処理要求を受信すると、作成された決済予定明細の判定を行う。その判定内容は、決済前日までに、少なくとも、当日の入金予定金額が出金予定金額より多いか否か（ステップＳ３０３）、決済処理予定が、入金時刻より出金時刻の方が遅いか否か（ステップＳ３０４）の判定を行う。そして、決済当日には、入金データの入金処理が予定時間までに入金されたか否か（ステップＳ３０５）の判定を行う。判定条件（実際の入金額が予定入金額と相違していないか、かつ入金の時刻がその入金に紐付けられた出金の予定時刻よりも前であるか等）を満たしていればステップＳ３０５“ＹＥＳ”に進み、出金処理手段１８は、日銀ネットシステム３０に対して、入金データに紐付された出金データの出金処理を実行する（ステップＳ３０６）。そして、出金処理完了後、出金処理手段１８は、通信手段１４を介して、顧客端末２０へ決済代行終了通知を行う（ステップＳ３０７）。

なお、判定手段１７は、判定条件の一つでも満たさない場合は、ステップＳ３０８に進み、通信手段１４を介して、顧客端末２０に決済代行不可通知を送信する（ステップＳ３０８）。

更なる詳細を図９〜図１２に示す端末表示画面を参照して説明する。まず、図９に示す画面は、入力が完了し承認済みの入金データ及び出金データを検索し、入金と出金を紐付け決済予定明細を作成するための入力画面（以下、決済予定入力画面と呼ぶ）である。この画面には、「委託先」、「決済予定日」、「検索条件」、「入金データ」、「出金データ」の各表示項目を有する。また、検索及び紐付けを実行するための「Ｓｅａｒｃｈ」ボタン、「Ｃｌｅａｒ」ボタン、「紐付」ボタンが一部領域に割り当てられている。

図９の画面最上部の「委託先」には、代行決済を委託した金融機関の番号と金融機関名を選択する。「決済予定日」には、検索対象の決済日の範囲を入力する。「検索条件」の項目には、「商品区分」、「決済ステータス」、「約定相手」、「入力区分」、「決済予定時刻」、「受託者受付番号」、「委託先約定番号」、「決済金額」等が含まれる。「決済ステータス」は、現在の決済状況を示し、例えば、「予定データ」、「入力承認データ」、「支払承認データ」等が登録されている。「入力区分」とは、大項目の分類を表し、「当座振替」と「国債ＤＶＰ」に分けられる。「商品区分」とは、決済対象の商品種別を表し、「コール取引」、「ＣＤ」、「ＣＰ」等が登録されるが、便宜上、「営業店振替」を含むものとする。また、「約定相手」には、顧客の取引相手である約定先が登録されており、約定先の名称又は約定先の識別番号が登録されている。「委託先約定番号」は、顧客が自ら定めた約定先ごとのユニークな番号である。また、「入金データ（入金承認済み）」の欄の「受託者受付番号」とは、各決済の受付時に決められた番号であり、入出金ごとにユニークな番号が割り当てられる。

画面上部の「Ｓｅａｒｃｈ」ボタンが押下されると、入出金データテーブル１１０から、「委託先」、「決済予定日」のデータ項目に入力した条件に合致する入金データを取得し、検索条件に合致するレコードを「入力データ」に表示する。また、「Ｃｌｅａｒ」ボタンが押下されると、入力した検索条件のクリア処理を行う。また、「紐付」ボタンが押下されると、入出金データテーブル１１０、入出金データ紐付けテーブル１２０から、選択した入金データに紐付けられた出金データと、まだ紐付けされていない出金データとを取得して図１０に示す詳細画面を表示する。詳細画面については後述する。

顧客は、上記した決済予定入力画面を使用して、「委託先」及び「決済予定日」を入力し、「検索条件」にある検索内容を入力して「Ｓｅａｒｃｈ」ボタンを押下すると、「入金データ」に、該当する入金データが表示される。次に、「入金データ」に表示された項目をマウス等で選択すると、その項目が範囲指定され、顧客が、「入金データ」の最上部に表示されている項目を選択して「紐付」ボタンを押下することで、図１０に示す検索画面に遷移する。

図１０の検索画面によれば、画面上段に、選択された入金データの情報が表示され、画面下段に、同日の紐付け候補出金データが一覧表示される。「紐付け候補出金データ」には、入金データと同様の項目が割り振られ、さらに顧客による候補選択のためのチェックボックスが割り当てられている。「紐付け候補出金データ」の「受託者受付番号」の欄にチェックを入れると、全ての項目が選択される。

なお、検索画面の一部領域には、「ａｄｄ」ボタンと「ｒｅｍｏｖｅ」ボタンが割り当てられる。「ａｄｄ」ボタンは、選択中の出金データを紐付けデータとして登録する機能を有し、「ｒｅｍｏｖｅ」ボタンは、選択中のデータの紐付を解除する機能を有する。

顧客は、検索画面に表示される「紐付け候補出金データ」の中からチェックボックスを使用して紐付けを行う出金データを選択し、「ａｄｄ」ボタンを押下すると、図１１に示す検索画面（２）に遷移する。検索画面（２）には、「出金データ」に、選択した出金データが表示され、このことにより紐付け操作が完了する。ここでは、１件の入金データに対して複数の出金データが紐付けられている。そして、図１２の入力承認画面に示すように、紐付けられた入出金データを選択すると、紐付けられた出金データが出金データ上に表示される。

次に、複数の入金データに対して、複数の出金データを紐付ける場合（Ｎ：Ｍ紐付け）の例を図１３及び図１４を参照して説明する。上述した一つの入金データに対して、複数の出金データを紐付ける例との差異のみを説明する。

図１３に示すように、「入金データ」には、顧客による候補選択のためのチェックボックスが割り当てられている。顧客は、「委託先」及び「決済予定日」を入力し、検索条件欄にある項目を入力し、「Ｓｅａｒｃｈ」ボタンを押下すると、「入金データ」に、該当する入金データが表示される。紐付けを行う「入金データ」の項目をチェックボックスで選択する。ここでは「出金データ」のチェックボックスには、選択は不要である。本説明では検索された入金データから３項目をチェックしたものとし、図１４に示す画面に遷移する。

図１４は、選択された入金データの明細が３件、出金データの紐付候補の明細が６件あったとして、この入金データ３件を出金データの２件の明細に紐付ける場合（すなわち、３：２紐付）の例を示している。この例では、図示するように、入金データと出金データが紐付けられた詳細内容が画面上部に表示される。詳細内容として、入金データの一覧が、決済予定時刻の早い順に表示される他、「最終決済予定時刻」、「決済金額計」、「紐付済金額」、「残金（紐付余力）」が表示される。「最終決済予定時刻」、は、選択された入金データのうち決済予定時刻が最も遅い時刻を示し、この例では、１０：３０となる。このとき、検索条件の「決済予定時刻」にも、この１０：３０が自動入力又は手動入力（所定のボタン押下で最終決済予定時刻を「決済予定時刻」欄に転記入力）される。「決済金額計」は、選択されない入金データも含めた決済金額の合計を示し、この例では、９００となる。「紐付済金額」は、選択された入金に対して紐付けられた出金の決済金額の合計を示し、この例では、４００となる。「残金（紐付余力）」は、「決済金額合計」から「紐付済金額」を差し引いたもので、紐付けられていない入金データの決済金額の合計、すなわち、紐付余力がまだ５００あることを示している。

顧客は、選択された「入金データ」の項目内で決済可能な出金データが「紐付け候補出金データ」に表示され、どの出金データを紐付けるか選択する。この例では、「紐付け候補出金データ」に表示された項目のうち、２つを選択している。顧客は、出金データを選択し、「ａｄｄ」ボタンを押下することで、紐付けが行われる。紐付け内容を変更する場合には、「紐付解除ボタン」を押下することで、紐付けが解除される。このとき画面上部の右側の数字も自動計算される。また、「一括選択（残額範囲内）」のボタンを押下すると、表示された「紐付け候補出金データ」の中から、決済予定時刻の早い順に、「残高（紐付余力）」の範囲内で、複数の入金データ及び出金データが再選択される。すなわち、紐付余力一杯まで入金データと出金データを自動的に選択し直すことができる。

なお、上述の画面では、顧客が入金と出金を個々に選択し、紐付けを行うようにしたが、特に、Ｎ：Ｍ紐付けの場合は、紐付けられる入金と出金の組み合わせが多数になるので、その組合せの候補の一覧を予定決済明細作成時に提示するようにし、顧客がその一覧の中から最適と思われる組合せを選択するようにしてもよい。

（実施形態の効果）
代行決済システム１の実施形態によれば、顧客端末２０に、前記顧客の資金決済口座における入金予定の入金データと出金予定の出金データとを入力する入力手段２３を備え、管理サーバ１１に、入金データ及び出金データを顧客端末２０から受信する入出金データ受信手段１５と、受信した入金データと出金データとを紐付けた決済予定明細を顧客に作成させる決済予定明細作成手段１６と、決済予定明細における入金データの入金処理の完了を条件に、日銀ネットシステムに対して、入金データに紐付された出金データの出金処理を実行する出金処理手段１８を備える。このようにすることで、決済日の入金データと出金データを紐付けた決済予定明細を作成し、資金決済の承認を事前に行えるため、代行決済の出金処理を滞りなく実行が可能となる。

また、決済予定明細作成手段１６は、少なくとも入金予定額、出金予定額、決済予定日時を含む条件が合致する入金データと出金データを顧客に選択させ、入金データと出金データとを紐付けた入出金データ紐付けテーブル１２０を登録して決済予定明細を作成する。このようにすることで、入出金データの不適切な紐付がないかをシステム側で確認することができる。

また、入金データと出金データの紐付は、１：１に限らず、一つの入金データに対して、一又は複数の出金データを紐付けした１：Ｎ紐付け、複数の入金データに対して、一つの出金データを紐付けしたＮ：１紐付け、複数の入金データに対して、複数の出金データを紐付けしたＮ：Ｍ紐付けが可能となる。複数の入金をまとめて、一又は複数の出金に紐付けられるので、紐付け操作が簡略化でき、また、複数の入金を合算して一又は複数の出金の原資とすることができる。

なお、本実施形態では、管理サーバ１１に決済予定明細の作成するための画面を生成するプログラムを搭載し、顧客端末２０からネットワーク経由でアクセスし、決済予定明細の作成を行う説明をしたが、顧客端末２０に決済予定明細の作成をするための専用プログラムを搭載し、顧客端末２０側で管理サーバ１１と交信しながら決済予定明細を作成してもよい。

以上、実施形態を用いて本発明を説明したが、本発明の技術的範囲は上記実施形態に記載の範囲には限定されないことは言うまでもない。上記実施形態に、多様な変更または改良を加えることが可能であることが当業者に明らかである。またその様な変更または改良を加えた形態も本発明の技術的範囲に含まれ得ることが、特許請求の範囲の記載から明らかである。なお、上記の実施形態では、本発明を物の発明として代行決済システムについて説明したが、本発明は、方法の発明としても捉えることもできる。

１ 代行決済システム
１０ 金融機関のシステム
１１ 管理サーバ
１２ ＲＴＧＳ決済管理システム
１３ 制御手段（管理サーバ側）
１４ 通信手段（管理サーバ側）
１５ 入出金データ受信手段
１６ 決済予定明細作成手段
１７ 判定手段
１８ 出金処理手段
２０ 顧客端末
２１ 通信手段（顧客端末側）
２２ 記憶手段（顧客端末側）
２３ 入力手段
２４ 表示手段
２５ 制御手段
３０ 日銀ネットシステム
４０ 銀行ネット専用回線
５０ 日銀ネット専用回線
６０ 顧客社内システム
１００ トランザクションＤＢ（トランザクションデータベース）
１１０ 入出金データテーブル
１２０ 入出金データ紐付けテーブル
２００ 残高ＤＢ（残高データベース）
３００ 顧客ＤＢ（顧客データベース）
４００ 入出金データ

Claims (8)

1. 代行決済を委託する顧客の顧客端末と、金融機関の管理サーバと、日銀ネットシステムとが接続された代行決済システムであって、
   前記顧客端末は、
   前記顧客の資金決済口座における入金予定の入金データと出金予定の出金データとを入力する入力手段を備え、
   前記管理サーバは、
   前記入金データ及び前記出金データを前記顧客端末から受信する入出金データ受信手段と、
   前記受信した入金データと前記出金データとを紐付けて決済させるための決済予定明細を前記顧客に作成させる決済予定明細作成手段と、
   前記決済予定明細における前記入金データの入金処理の完了を条件に、前記日銀ネットシステムに対して、前記入金データに紐付された前記出金データの出金処理を実行する出金処理手段と、
   を備えることを特徴とする代行決済システム。
2. 前記決済予定明細作成手段は、少なくとも入金予定額、出金予定額、及び決済予定日時を含む条件が合致する入金データと出金データを顧客に選択させ、前記入金データと出金データとを紐付けた入出金データ紐付けテーブルを登録して前記決済予定明細を作成することを特徴とする請求項１に記載の代行決済システム。
3. 前記決済予定明細作成手段は、一つの前記入金データに対して、一又は複数の前記出金データを紐付けることを特徴とする請求項１又は２に記載の代行決済システム。
4. 前記決済予定明細作成手段は、複数の前記入金データに対して、一つの前記出金データを紐付けることを特徴とする請求項１又は２に記載の代行決済システム。
5. 前記決済予定明細作成手段は、複数の前記入金データに対して、複数の前記出金データを紐付けることを特徴とする請求項１又は２に記載の代行決済システム。
6. 代行決済を委託する顧客の顧客端末と、金融機関の管理サーバと、日銀ネットシステムとが接続された代行決済システムにおける前記管理サーバであって、
   入金データ及び出金データを前記顧客端末から受信する入出金データ受信手段と、
   前記受信した入金データと前記出金データとを紐付けて決済させるための決済予定明細を前記顧客に作成させる決済予定明細作成手段と、
   前記入出金データ受信手段が受信した前記決済予定明細における前記入金データの入金処理の完了を条件に、前記日銀ネットシステムに対して、前記入金データに紐付された出金データの出金処理を実行する出金処理手段と、を備えることを特徴とする管理サーバ。
7. 代行決済を委託する顧客の顧客端末と、金融機関の管理サーバと、日銀ネットシステムとが接続された代行決済システムにおける前記管理サーバのプログラムであって、
   コンピュータに、
   入金データ及び出金データを前記顧客端末から受信する受信するステップと、
   前記受信した入金データと前記出金データとを紐付けて決済させるための決済予定明細を前記顧客に作成させるステップと、
   受信した前記決済予定明細における前記入金データの入金処理の完了を条件に、前記日銀ネットシステムに対して、前記入金データに紐付された出金データの出金処理を実行するステップと、
   を実行させることを特徴とするプログラム。
8. 代行決済を委託する顧客の顧客端末と、金融機関の管理サーバと、日銀ネットシステムとが接続され、前記管理サーバが前記顧客端末の代行決済を行う方法であって、
   前記顧客端末において、
   前記顧客の資金決済口座における入金予定の入金データと出金予定の出金データとを入力するステップと、
   前記管理サーバにおいて、
   前記入金データ及び前記出金データを前記顧客端末から受信するステップと、
   前記受信した入金データと前記出金データとを紐付けて決済させるための決済予定明細を前記顧客に作成させるステップと、
   受信した前記決済予定明細における前記入金データの入金処理の完了を条件に、前記日銀ネットシステムに対して、前記入金データに紐付された出金データの出金処理を実行するステップと、
   を有することを特徴とする方法。