JP4549496B2

JP4549496B2 - 代行支払システム

Info

Publication number: JP4549496B2
Application number: JP2000222885A
Authority: JP
Inventors: 義浩國光; 隆寛田中; 洋川上; 茂林
Original assignee: Sumitomo Mitsui Banking Corp
Current assignee: Sumitomo Mitsui Banking Corp
Priority date: 2000-07-24
Filing date: 2000-07-24
Publication date: 2010-09-22
Anticipated expiration: 2020-07-24
Also published as: JP2002041785A

Description

【０００１】
【発明の属する技術分野】
本発明は、日本銀行が提供するＲＴＧＳ（即時決済）システムなどと接続して、顧客の代行決済を行なう代行支払システムに関する。
【０００２】
【従来の技術】
日本銀行では、当座預金等の即時決済（ＲＴＧＳ）を行なうためにオンラインで決済ができるコンピュータシステムの開発を発表し、実施を目指している。これに関して民間の銀行でも、上記コンピュータと接続し、顧客に代わり、日銀のＲＴＧＳシステムと接続して、代行決済を行なうＲＴＧＳ代行システムの開発を余儀なくされている。
【０００３】
【発明が解決しようとする課題】
この代行決済システムとしては、従来は代金の振込み、振替などを行うコンピュータシステムが知られているが、即時決済は取り扱う金額も大きく、そのコンピュータシステムをそのまま使用するわけにはいかない。
【０００４】
そこで、本発明の目的は、上述の点に鑑みて、決済金額が大きい場合に適した代行支払システムを提供することにある。
【０００５】
【課題を解決するための手段】
このような目的を達成するために、請求項１の発明は、第１の銀行に対する支払を代行する第２の銀行で、支払者の第１の端末から、支払金額および第２の銀行での預金口座を示す決済予定明細を受け付け、前記第１の銀行への支払に関連して、前記支払者の預金口座から代行して支払った金額を引き落とす決済代行システムにおいて、
前記決済予定明細を前記支払者の第１の端末から入力した後、該第１の端末から前記決済予定明細の示す金額の前記第１の銀行に対する代行支払の承認を前記第１の支払者の端末から入力し、当該入力された決済予定明細および代行支払の承認を受け付ける通信手段と、
前記支払者の預金口座の預金情報を複数の支払者について記憶したデータベースと、
前記第１の銀行のコンピュータシステムと接続し、前記決済予定明細に基づき代行支払に関する情報を入力することにより前記第１の銀行に対する支払を行なう第２の端末と
前記第１の端末から代行支払の承認を前記通信手段により受け付けた後、前記データベースの該当する預金口座から代行支払金額を引き落とす第１の情報処理手段と、
第１の銀行のコンピュータシステムと接続して前記第１の銀行からの、前記支払者の預金口座に対する入金を受付ける入金用通信手段と、
当該受け付けた入金のために前記データベースの該当する預金口座の残高を更新する第２の情報処理手段と
を具え、
前記データベースは前記複数の支払者について預金口座の預金情報および有担保の貸付枠および無担保の貸付枠を記憶する第１のデータベースと、前記複数の支払者全体で使用する無担保の貸越枠としての共通枠を記憶する第２のデータベースを有し、
共有枠の限度額以内で、前記複数の支払者に対して前記支払に対する貸越が許容され、
前記有担保の貸付枠および／または無担保の貸付枠を使用するかは予め定められており、前記無担保の貸付枠を使用することが予め定められている場合に、前記第１の情報処理手段は、前記預金口座に代行支払金額を引き落とすだけの資金残高がないときに、前記支払者個人の無担保の貸付枠および前記共通枠をチェックし、前記無担保の貸付枠および前記共通枠の双方に余裕がある場合に前記代行支払い金額の支払い処理を実行し、前記無担保の貸付枠および前記共通枠の残高を更新することを特徴とする。
【０００６】
請求項２の発明は、請求項１に記載の代行支払システムにおいて、前記通信手段により代行支払の承認を受け付けた後に手動または自動で前記第１の銀行に対して前記代行支払に関する情報を前記第２の端末から入力することを特徴とする。
【０００７】
請求項３の発明は、請求項２に記載の代行支払システムにおいて、前記データベースには、支払者の預金口座には仮更新残高を記載する仮更新残高欄を有しており、前記第１の銀行に対する代行支払の終了前までは、前記データベースの仮更新残高欄に代行支払金額を引き落とした預金残高を記載することにより預金残高を仮更新することを特徴とする。
【０００８】
請求項４の発明は、請求項３に記載の代行支払システムにおいて、前記第１の銀行に対する支払終了後、手動または自動の指示で、前記仮更新残高欄に記載された預金残高で、前記データベースの支払者の預金残高記載欄の残高を更新することを特徴とする。
【０００９】
請求項５の発明は、請求項３に記載の代行支払システムにおいて、前記データベースの仮更新残高記載欄に記載された残高を前記支払者の第１の端末で閲覧可能であることを特徴とする。
【００１０】
請求項７の発明は、請求項１に記載の代行支払システムにおいて、前記第２の銀行に設置され、前記支払者から前記決済予定明細の形態で依頼された支払についての第２の銀行側の支払承認を入力する支払承認入力手段と、前記第２の銀行に設置され、前記決済予定明細および前記第２の銀行側の支払承認を互いに関連付けて表示する表示手段とをさらに具えたことを特徴とする。
【００１１】
請求項８の発明は、請求項１に記載の代行支払システムにおいて、前記第１の銀行側からの入金の内容を示す入金情報を入力する入金情報入力手段と、
入金予定の内容を示す入金予定情報を入力する入金予定情報入力手段と、
当該入力された入金情報と、入金予定情報とを同じ情報内容について照合する照合手段と、
該照合の結果、不一致の情報内容があった場合には、その旨を示すアンマッチ情報を前記支払者の端末に前記通信手段を介して通知することを特徴とする。
【００１２】
請求項８の発明は、請求項１に記載の代行支払システムにおいて、前記第１の銀行側からの支払終了通知情報を入力する支払終了通知情報入力手段と当該入力された支払通知情報と、前記決済予定明細の示す情報とを同じ情報内容について照合する照合手段と、該照合の結果、不一致の情報内容が合った場合には、その旨を示すアンマッチ情報を前記支払者の端末に前記通信手段を介して通知することを特徴とする。
【００１３】
請求項９の発明は、請求項１に記載の代行支払システムにおいて、前記決済予定明細の示す支払金額について前記預金口座から引き落とし可能であるか否の判定を行なう判定手段と、該判定の結果を出力する出力手段をさらに具えたことを特徴とする。
【００１４】
請求項１０の発明は、請求項１に記載の代行支払システムにおいて、前記決済予定明細書の示す支払先が前記第２の銀行に預金口座を有する場合には、前記データベース上の前記支払者の預金口座から支払先の預金口座に行内振替を行なうことを特徴とする。
【００１５】
請求項１１の発明は、請求項１に記載の代行支払システムにおいて、貸越に限度額を有する共有枠が予め定められており、該共有枠の限度額以内で、複数の支払者に対して前記支払に対する貸越が許容されることを特徴とする。
【００１６】
請求項１２の発明は、請求項１に記載の代行支払システムにおいて、前記支払者の第１の端末から入力される決済予定明細には前記第１の銀行に対する決済時刻の指示が含まれていることを特徴とする
【００１７】
【発明の実施の形態】
以下、図面を参照して本発明の実施形態を詳細に説明する。
【００１８】
図１は本発明を適用した代行決済（支払代行）システムを示す。図１において、１０は顧客（支払委託者、以下、単に委託者と略記する）が独自に保有する社内処理システムである。
【００１９】
２０は委託者側に設置されたクライアント（以下、委託者端末２０と称す）であり、パーソナルコンピューターやワークステーションなどの汎用のコンピュータを使用することができる。委託者端末２０には決済予定明細（後述）を入力したり、決済指図を指示したり、決済状況を表示するための専用プログラムが搭載されている。
【００２０】
３０はフレームリレー網（以下、ＦＲ網３０と称す）と呼ばれる通信回線網であり、複数の委託者端末２０、後述するＤＢサーバ５０が接続される。
【００２１】
４０は受託者側に設置されるクライアント（以下、受託者端末４０と称す）であり、委託者端末２０で装備される機能に加え、受託者が決済処理、貸越管理等を行うための専用プログラムが搭載されている。
【００２２】
５０は、決済明細管理、残高管理、貸越管理等以下に述べる情報処理を行うためのデータベース（ＤＢ）５１〜５４を内蔵するＤＢサーバである。
【００２３】
５１〜５４は本発明のデータベースを構成する個別データベースであり、データベース５１（以下、トランザクションＤＢ５１と称す）は決済明細を管理するプログラム（サーバ５０が実行）で使用する資金情報を保存している。データベース５２（以下、残高ＤＢ５２と称す）は委託者毎の資金（預金）残高情報、貸越枠、仮更新残高をそれぞれの記載欄いわゆるフィールドに保存している。ここで、仮更新残高は、本実施形態で初めて導入された新しい情報である。
【００２４】
データベース５３（以下、共有枠ＤＢ５３と称す）は委託者全体で使用する貸越枠（「共有枠」）の使用状況を保存している。データベース５４（以下、顧客ＤＢと称す）は委託者に関する会社情報、たとえば、名称、住所、担当者名等を管理するため情報を保存している。
６０は受託銀行内に設置されるＲＴＧＳ決済用システム（以下、ＲＴＧＳシステム６０と称す）であり、日本銀行（本発明の第１の銀行）の決済システム８０（以下、日銀ネットシステム８０と称す、）と専用回線７０（以下、日銀ネット専用回線７０）を介して接続されており、資金決済情報の送受信、決済状況の管理を行うためのプログラムが搭載されている。
【００２５】
このようなシステム構成において、委託者は委託者端末２０（本発明の第１の端末）を使用して図２示すような表示画面に表示される決済予定入力画面１０００で決済予定明細を入力する。その際、委託者の社内システム１０で複数の決済予定明細をフロッピーディスクに排出して、クライアント２０に決済予定明細を一括入力することも可能である。決済予定明細には少なくとも、支払先の銀行およびその預金口座番号、自己の預金口座番号、決済金額（支払金額）などが含まれる。本実施形態では、さらに決済時刻を指示する。また、この画面には実際に日本銀行で再処理された時刻が専用の表示欄に表示される。
【００２６】
＜支払承認・仮残更新＞
委託者が委託者端末２０に入力した決済予定明細は、ＦＲ網３０を介してＤＢサーバ５０（本発明の通信手段および情報処理手段として機能する）によりトランザクションＤＢ５１に格納される。格納された決済予定明細は、受託者端末４０に付属するプリンターから自動印刷される。受託銀行の担当者は出力された明細を銀行内のＲＴＧＳシステム６０に入力し、決済予定の管理を行う。
【００２７】
支払委託者は、図２の画面で複数組の決済予定明細を作成し、トランザクションデータベース５１に登録することができる。また、登録された決済予定明細（委託者の承認前）を委託者端末２０で閲覧することができる。この閲覧画面を図３に示す。
【００２８】
図３の画面は委託者端末２０に表示される、支払指図を行い、決済状況、（仮更新残高状況を表示する画面を示す。この画面２０００では、図１の画面で入力された決済明細複数組がリスト（表）の形態で表示される。この画面に表示される残高情報は、委託者が図３の「Refresh」ボタン２００２を押下することにより、残高ＤＢ５２で保存されている最新残高に更新される。また、この画面に表示される決済状況はトランザクションＤＢ５１で保存されている最新の状況をＤＢサーバ５０から自動配信されて表示される。
【００２９】
図３で表示される「支払可能残高」の範囲内であれば、明細行に表示されている未決済の支払予定をマウス等で選択して、「支払承認」ボタン２００１を押下することにより、ＤＢサーバ５０に支払を指示することができる。なお、「支払承認」ボタン２００１を押下する人間は決済委託者側の責任者であることが望ましい。
【００３０】
本実施形態では、支払予定明細を予め銀行側の決済代行システムに送っておき、後で、その支払予定明細について承認を送信することで、委託者および代行支払を行なう銀行側の大口の支払に対するセキュリティを確保する。
【００３１】
このような画面を使用して支払承認が送信された場合のサーバ５０は図６の処理を実行する。委託者により図３の支払承認ボタン２００１が押下される（図６のステップＳ５０１）と、残高ＤＢ５２の情報により該当金額の支払が可能かどうかの判定がなされる（図６のステップＳ５０２）。判定がＹＥＳである場合は、残高ＤＢ５２の「仮更新残高」が書き換えられ、該当金額分だけ引き落としされる（図６のステップＳ５０３）。仮残高引き落とし後、受託銀行端末４０に付属するプリンターから、該当のデータ明細のプルーフシート（図６のステップＳ５０４）が自動出力されるので、受託銀行の担当者はＲＴＧＳシステム（本発明の第２の端末）６０を使用して日本銀行当座預金での資金決済を行う。日銀ネットシステム８０での決済結果は、日銀ネット専用回線７０を介してＲＴＧＳシステム６０に還元されるので、ＲＴＧＳシステム６０に表示される画面または、出力される帳票によってその結果を確認する（図６のステップＳ５０５）。確認された結果に基づき受託端末４０の画面より該当明細に対し図４の処理時刻入力ボタン３００１で日本銀行での決済時刻を入力し決済済みの入力を行うことにより、トランザクションＤＢ５１が決済済みに更新されるとともに、残高ＤＢ５２の本残が更新される（図６のステップＳ５０６）。
【００３２】
仮残高更新のステップＳ５０３と本残更新のステップＳ５０６との間には、時間差が生じるため、委託者は図２の残高照会・支払承認画面の「Refresh」ボタンを押下して残高更新を行うことにより、支払承認を行ったもののまだ日本銀行での決済が完了していない金額、および支払予定明細が複数ある場合にあとどれだけの金額が支払可能であるかの判断を行うための「支払可能残高」の把握を随時行うことが可能となる。
【００３３】
＜アンマッチ入金処理の説明＞
次に図７を参照して入金処理について説明する。委託者が委託者端末２０で行う決済予定データの送信と受託者が行うＲＴＧＳシステム６０への予定データの入力までの処理は上述した資金払いの処理フローと同様である。
【００３４】
委託先への入金は、まず日銀ネットシステム８０より日銀ネット専用回線７０を介して受託銀行のＲＴＧＳシステム６０に通知される。入金内容は受託銀行の担当者がＲＴＧＳシステム６０の画面表示もしくは出力帳票にて認知することができるので、その内容をもとに、受託者端末４０にて図４の画面を表示させて該当明細の有無を検索する（ステップＳ５１１）。トランザクションＤＢ５１に該当明細が存在すれば、受託者端末４０に承認記帳を入力することにより、残高ＤＢ５２の本残（従来の預金口座の残高、上述の仮更新残高とは別個である点に注意）が更新される（図７のステップＳ５１２）。
【００３５】
委託者の入金予定未入力、入金予定入力相違等の事由によりトランザクションＤＢ５１に該当（支払金額等の明細項目の情報内容が一致）する決済予定明細が存在しない場合には、ＲＴＧＳシステム６０に表示された明細を、本発明のアンマッチ情報の一部として受託者端末４０の画面４のアンマッチ処理ボタン３００２を押下することにより入力しトランザクションＤＢ５１に該当明細を作成する（図４のステップＳ５１３）。ここで作成された明細に対してはトランザクションＤＢ５１内で自動的に「アンマッチフラグ」が付加され（図４のステップＳ５１４）る。図３の画面のアンマッチのフィールド欄の色が変わり、受託者端末にて入力された不一致（アンマッチ）入金情報であることが判別できる。本実施形態では、色の変化でアンマッチの通知を行なう。
【００３６】
アンマッチフラグが付された明細は、ＤＢサーバ５０から委託者端末２０に自動配信され、委託者端末２０の残高照会・支払承認画面（図３参照）の明細行に自動表示される（図７のステップＳ５１５）。その際、図７の「Refresh」ボタン２００２の押下は不要であるので、委託者は画面表示の変化をみておくだけで、自己の入金状況を容易に認知することが可能である。
【００３７】
＜行内振替処理＞
上述した処理は日銀ネットシステム８０を使用した決済処理であるが、委託者から送信される決済予定の中には、日銀ネットシステム８０及びＲＴＧＳシステム６０を使用することなく、決済処理を完了させることができる明細も存在する。即ち、決済の当事者が委託者と受託銀行自身である場合、及び同一の受託銀行に決済口座を有する委託者同士である場合である（このような場合を以下、「行内振替」と称する）。
【００３８】
行内振替に該当する処理を図８を用いて説明する。
【００３９】
委託者が委託者端末２０より決済予定を入力し、ＦＲ網３０を介してトランザクションＤＢ５１に明細が書き込まれる際、決済明細判定プログラムにより、予定明細の決済相手口座情報を識別して「行内振替」対象の明細に対しては、「行内振替フラグ」を付加する（図８のステップＳ５２１）。
【００４０】
資金を支払う側の委託者が、委託者端末２０の「支払承認・残高照会」画面（図２）にて、支払承認記帳を行い、仮残更新が行われる際（前述、図６のステップＳ５０３）に、行内振替処理プログラム（ＤＢサーバ５０が実行）により、トランザクションＤＢ５１に保存されている入金側の決済予定明細の有無を検索（図８のステップＳ５２２）し、該当の入金明細が存在すれば、該当する入金側の決済予定明細に「入金確定」のフラグを付与する（図８のステップＳ５２３）。
【００４１】
なお、入金確定フラグが付された明細は、ＤＢサーバ５０から入金側の委託者クライアント２０の「残高照会・支払承認」画面に自動通知される。これにより入金側の委託者は、当該入金が確実に履行されることを容易に認識できる。
【００４２】
ステップＳ５２２の自動検索にて、該当の入金明細がトランザクションＤＢ５１に存在しない場合は、行内振替処理プログラムにより、支払承認された出金明細をもとに入金明細がトランザクションＤＢ５１に自動作成され（図８のステップＳ５２６）、入金確定フラグが付されるとともに、ＤＢサーバ５０から入金側の委託者クライアント２０の「残高照会・支払承認」画面に自動通知される。
【００４３】
受託銀行の担当者が、決済予定明細にて受領した「決済予定時刻」に受託者端末４０の行内振替処理画面（図６）で「振替処理」ボタンを押下することにより（図８のステップＳ５２４）、該当する入金、出金それぞれの明細が決済済みとなり、本残が更新される。なお、同一の決済予定時刻に複数の決済予定明細が存在する場合には、１回の振替処理により該当するすべての明細が同時に決済済みとなるため、事務の効率化を図ることが可能となる。
【００４４】
上述の実施形態に加え、次の形態を実施できる。
【００４５】
（第１の他の形態）
＜共有枠管理＞
資金支払の場合、図６のステップＳ５０２で委託者の支払可能残高により、支払の可否が判定されるが、その判定の際に受託銀行により「貸越」を許容する場合がある。
【００４６】
残高ＤＢ５２は、有担保、無担保での貸越枠が受託者により設定される。貸越枠のうち、無担保での貸越枠は、委託者全体で使用する枠として共有枠ＤＢ５３で保存される「共有枠」の範囲内で運営されるものである。委託者毎の貸越枠と共有枠との関係を図９に示す。委託者毎の貸越枠の使用状況及び全体での共有枠の使用状況は、受託銀行クライアント４０で提供される「残高照会・支払承認画面（受託者）」（図３参照）の「Refresh」ボタン２００２を押下することにより、リアルタイムでの管理が可能になる。
【００４７】
その処理要領を図９を用いて次に示す。
【００４８】
委託者が委託者端末２０の「残高照会・支払承認」画面より「支払承認」ボタン２００１を押下するとＤＢサーバ５０の残高ＤＢ５２の支払可能残高のうち、支払判定プログラムによりまず資金部分の残高がチェックされる（図１０のステップＳ５３１）。資金残高の判定がＮＯの場合残高ＤＢ５２の貸越枠の設定がある委託者の場合は、残高ＤＢ５２の貸越枠の使用状況がチェックされる（図１０のステップＳ５３２）。その際、無担保貸越枠を使用する場合には、「共有枠」の使用状況が合わせてチェックされる（図１０のステップＳ５３３）。無担保貸越枠及び共有枠に余裕があれば（図１０のステップＳ５３３で「余裕あり」の判定）、残高ＤＢ５２の無担保貸越枠の仮残及び共有枠ＤＢ５３の共有枠の使用残高がそれぞれ更新される。
【００４９】
＜第２の他の形態＞
本実施形態では、銀行側のセキュリティを向上させるためにさらに、委託者側から委託された決済予定明細で委託者の承認が行なわれた案件については銀行側の責任者が承認を与える。このための画面を図５に示す。責任者は、受託者端末４０から図画面を呼び出す。図５の画面で検索条件を入力して、代行決済を承認すべき決済予定明細をトランザクションＤＢ５１から取り出して受託端末４０に表示させる。表示された決済予定明細（図５では不図示）の中の所望の明細をマウス等で選択した後、承認ボタン４００１を操作する。この操作に応じて、トランザクションＤＢ５１上の決済予定明細に関連付けるためにこの明細内の承認欄に承認の旨の情報がＤＢサーバ５０により書き込まれる。また、銀行側では、トランザクションＤＢ５１の決済予定明細を表示させるときにこの承認の有無を表示させる。なお、委託者端末２０に対して銀行側の責任者の承認の有無を表示させてもよいし、表示させないようにしてもよい。
【００５０】
このようにして銀行側でも日銀システムへの代行決済について責任者が承認を与えることで、代行支払に関するセキュリティを高めることができる。
【００５１】
以上述べた実施形態の他に、さらに次の形態を実施できる。
１）図１のフレームリレー網３０に変わり、周知の通信ネットワークを使用することができる。
２）上述の実施形態では、受託者端末４０とＲＴＧＳシステムとの間はオフラインで情報転送を行なっているが、オンラインで接続して情報転送を行なってもよい。さらに上述のアンマッチの有無のための照合を、受託者端末４０またはＤＢサーバ５０のいずれかで行なって、アンマッチを委託者端末２０に通知してもよいこと勿論である。
【００５２】
【発明の効果】
以上、説明したように、請求項１の発明によれば、予め代行支払に関する明細を支払者から受け取っておき、その後、支払者の承認を受けることにより、情報入力の誤りや、不正行為を未然に阻止することができる。また、決済予定明細と受付時点と承認受け取り時点の間には時間差ができるので、その間に銀行側では、残高確認を行なうことができる。また、支払いの代行だけでなく、支払い者の預金口座に対する他の銀行からの入金をも受け付けることができる。
【００５３】
請求項２の発明によれば、支払者の承認を得た後、第１の銀行に支払を行なうので、決済に関するセキュリティが保たれる。
【００５４】
請求項３の発明によれば、仮更新残高情報をデータベースに設けることで、支払者が、決済予定明細を入力した後、第１の銀行に支払を行なう前でも、支払者は残りの預金算高を知ることができる。
【００５５】
請求項４の発明によれば、第１の銀行に対する支払が終了した後、支払者の預金残高が正式に更新されるので、第１の銀行に対する支払にトラブルが生じた場合に、支払者の預金残高が影響を受けることはない。
【００５６】
請求項５の発明によれば、支払者側の端末で、仮更新残高が閲覧できるので、支払者が入力した決済予定明細がただしく処理されているか、および、後どれくらい預金残高が残っているかを確認することができる。
【００５７】
請求項６の発明によれば、支払の完了を同じ支払者の（第１）の端末に通知するるので、郵便、ＦＡＸ等よりも情報伝達を早くすることができる。
【００５８】
請求項７の発明によれば、銀行側で代行支払に関する承認を与えることで、代行支払に関するセキュリティ性が高まる。
【００５９】
請求項８の発明によれば、支払者の預金口座への入金のための情報転送に関する誤りを検出することができるので、システムの信頼性を高めることができる。
【００６０】
請求項９の発明によれば、支払者の残高不足を検知して、出力することにより、残高不足状態での代行支払が行なわれることはない。
【００６１】
請求項１０の発明によれば、同一銀行内での決済に関しても請求項１の発明を利用することができる。
【００６２】
請求項１１の発明によれば、複数の支払者に対して限度はあるものの、貸越を行なうことができる。
【００６３】
請求項１２の発明によれば、支払者は事前に決予定明細を入力しても第２の銀行側に決済時刻の指定を行うことができる。
【図面の簡単な説明】
【図１】本発明実施形態のシステム構成を示すブロック図である。
【図２】委託者側の端末での決済予定明細の入力用画面を示す説明図である。
【図３】委託者側の端末での残高照会、支払承認のための表示画面を示す説明図である。
【図４】受託者端末での表示画面の内容を示す説明図である。
【図５】受託者端末での承認用画面の内容を示す説明図である。
【図６】支払承認処理手順を示すフローチャートである。
【図７】入金処理手順を示すフローチャートである。
【図８】行内振替処理手順を示すフローチャートである。
【図９】貸越枠を説明するための説明図である。
【図１０】共有枠を説明するための説明図である。
【符号の説明】
１０：委託者側社内システム
２０：委託者端末
３０：フレームリレー網
４０：受託者端末
５０：ＤＢサーバ
６０：ＲＴＧＳシステム
７０：日銀ネット専用回線
８０：日銀ネットシステム
５１：トランザクションＤＢ
５２：残高ＤＢ
５３：共有枠ＤＢ
５４：顧客ＤＢ

Claims

第１の銀行に対する支払を代行する第２の銀行で、支払者の第１の端末から、支払金額および第２の銀行での預金口座を示す決済予定明細を受け付け、前記第１の銀行への支払に関連して、前記支払者の預金口座から代行して支払った金額を引き落とす決済代行システムにおいて、
前記決済予定明細を前記支払者の第１の端末から入力した後、該第１の端末から前記決済予定明細の示す金額の前記第１の銀行に対する代行支払の承認を前記第１の支払者の端末から入力し、当該入力された決済予定明細および代行支払の承認を受け付ける通信手段と、
前記支払者の預金口座の預金情報を複数の支払者について記憶したデータベースと、
前記第１の銀行のコンピュータシステムと接続し、前記決済予定明細に基づき代行支払に関する情報を入力することにより前記第１の銀行に対する支払を行なう第２の端末と
前記第１の端末から代行支払の承認を前記通信手段により受け付けた後、前記データベースの該当する預金口座から代行支払金額を引き落とす第１の情報処理手段と、
前記第１の銀行のコンピュータシステムと接続して前記第１の銀行からの、前記支払者の預金口座に対する入金を受付ける入金用通信手段と、
当該受け付けた入金のために前記データベースの該当する預金口座の残高を更新する第２の情報処理手段と
を具え、
前記データベースは前記複数の支払者について預金口座の預金情報および有担保の貸付枠および無担保の貸付枠を記憶する第１のデータベースと、前記複数の支払者全体で使用する無担保の貸越枠としての共通枠を記憶する第２のデータベースを有し、
共有枠の限度額以内で、前記複数の支払者に対して前記支払に対する貸越が許容され、
前記有担保の貸付枠および／または無担保の貸付枠を使用するかは予め定められており、前記無担保の貸付枠を使用することが予め定められている場合に、前記第１の情報処理手段は、前記預金口座に代行支払金額を引き落とすだけの資金残高がないときに、前記支払者個人の無担保の貸付枠および前記共通枠をチェックし、前記無担保の貸付枠および前記共通枠の双方に余裕がある場合に前記代行支払い金額の支払い処理を実行し、前記無担保の貸付枠および前記共通枠の残高を更新することを特徴とする代行支払システム。
請求項１に記載の代行支払システムにおいて、前記通信手段により代行支払の承認を受け付けた後に手動または自動で前記第１の銀行に対して前記代行支払に関する情報を前記第２の端末から入力することを特徴とする代行支払システム。
請求項２に記載の代行支払システムにおいて、前記データベースには、支払者の預金口座には仮更新残高を記載する仮更新残高欄を有しており、前記第１の銀行に対する代行支払の終了前までは、前記データベースの仮更新残高欄に代行支払金額を引き落とした預金残高を記載することにより預金残高を仮更新することを特徴とする代行支払システム。
請求項３に記載の代行支払システムにおいて、前記第１の銀行に対する支払終了後、手動または自動の指示で、前記仮更新残高欄に記載された預金残高で、前記データベースの支払者の預金残高記載欄の残高を更新することを特徴とする代行支払システム。
請求項３に記載の代行支払システムにおいて、前記データベースの仮更新残高記載欄に記載された残高を前記支払者の第１の端末で閲覧可能であることを特徴とする代行支払システム。
請求項１に記載の代行支払システムにおいて、前記第１の銀行に対する支払の終了の旨を示す支払通知情報を入力する支払通知入力手段とを具え、該支払通知入力手段から入力された支払通知情報を前記通信手段を介して前記支払者の第１の端末に対して通知することを特徴とする代行支払システム。
請求項１に記載の代行支払システムにおいて、前記第２の銀行に設置され、前記支払者から前記決済予定明細の形態で依頼された支払についての第２の銀行側の支払承認を入力する支払承認入力手段と、前記第２の銀行に設置され、前記決済予定明細および前記第２の銀行側の支払承認を互いに関連付けて表示する表示手段とをさらに具えたことを特徴とする代行支払システム。
請求項１に記載の代行支払システムにおいて、前記第１の銀行側からの入金の内容を示す入金情報を入力する入金情報入力手段と、
入金予定の内容を示す入金予定情報を入力する入金予定情報入力手段と、
当該入力された入金情報と、入金予定情報とを同じ情報内容について照合する照合手段と、
該照合の結果、不一致の情報内容があった場合には、その旨を示すアンマッチ情報を前記支払者の端末に前記通信手段を介して通知することを特徴とする代行支払システム。
請求項１に記載の代行支払システムにおいて、前記決済予定明細の示す支払金額について前記預金口座から引き落とし可能であるか否の判定を行なう判定手段と、該判定の結果を出力する出力手段をさらに具えたことを特徴とする代行支払システム。
請求項１に記載の代行支払システムにおいて、前記決済予定明細書の示す支払先が前記第２の銀行に預金口座を有する場合には、前記データベース上の前記支払者の預金口座から支払先の預金口座に行内振替を行なうことを特徴とする代行支払システム。
請求項１に記載の代行支払システムにおいて、前記支払者の第１の端末から入力される決済予定明細には前記第１の銀行に対する決済時刻の指示が含まれていることを特徴とする代行支払システム。