JP6896124B1 - 金融取引方法、金融取引システムおよび金融取引プログラム - Google Patents

Abstract

【課題】不正の口座照会を容易にかつ高い精度で判別する金融取引方法を提供する。【解決手段】金融取引システムにおいて、自行サーバ１０は、ユーザ端末４０より受信した口座情報を口座照会履歴情報データベース１２ａに格納し、口座情報を統合ＡＴＭサーバ２０へ送信する。統合ＡＴＭサーバは、受信した口座情報に対応する他行サーバ３０へ口座情報を送信する。他行サーバは、受信した口座情報の照会処理を行い、結果を返信する。統合ＡＴＭサーバは、受信した照会結果を自行サーバへ送信する。自行サーバは、受信した口座照会結果を同一の依頼番号の口座情報と共に口座照会履歴情報として口座照会履歴情報データベースに格納し、過去に同一ユーザによる口座照会がない場合、現在の口座照会履歴情報をもとに不正の口座照会であるか否かを判定し、ユーザ端末４０に口座照会結果を送信し、不正と判定された場合、依頼者の口座照会を停止する。【選択図】図２

Description

本発明は、金融取引方法、金融取引システムおよび金融取引プログラムに関する。

各金融機関をつなぐ金融取引方法として、統合ＡＴＭシステムが現在運用されている。統合ＡＴＭシステムを用いることで、各金融機関のＡＴＭ（Ａｕｔｏｍａｔｉｃ Ｔｅｌｌｅｒ Ｍａｃｈｉｎｅ）及びＣＤ（Ｃａｓｈ Ｄｉｓｐｅｎｓｅｒ）がネットワークで接続され、他行ＡＴＭを利用した現金支払い、残高照会、他行への振り込みを簡単に行うことができる。特許文献１には、統合ＡＴＭシステムを用いた振り込み方法について開示されている。統合ＡＴＭシステムを用いることにより、他行への振り込みを一括で処理できるため、ユーザの利便性が大きく向上する。

特開２０１２−５３６１５号公報

統合ＡＴＭシステムにおいて他行への振り込みを一括で処理する際には、振り込み処理前にあらかじめ口座情報を取得（口座照会）することが一般的に行われている。事前に口座情報を取得することができることにより利便性を有する一方で、口座情報が不正取得される恐れがある。また、口座照会される件数は膨大であり、一件ずつ不正の口座照会であるかをモニタリングすることは煩雑である。

また、口座照会を行う上で、金融機関全体において統合ＡＴＭシステムを利用可能にするためには規約の取り決め等に時間を要する場合がある。

このような課題に鑑み、本発明の目的の一つは、不正の口座照会を容易にかつ高い精度で判別することである。または、本発明の目的の一つは、迅速に不正の口座照会を判別することである。または、本発明の目的の一つは、金融機関間における迅速な口座照会を図ることである。

本発明の一実施形態によれば、第１金融機関サーバから送信された複数の口座情報の各々に対応する照会結果を含む口座照会履歴情報に基づいて不正の口座照会であるかを判定する、金融取引方法が提供される。

上記金融取引方法において、前記複数の口座情報は、ユーザの端末から送信され、前記ユーザの識別子に関連付けされてもよい。

上記金融取引方法において、前記複数の口座情報が所定の数以上であるときに、不正の口座照会であると判定してもよい。

上記金融取引方法において、前記複数の口座情報が、所定の数以上の連続する口座番号を含むときに、不正の口座照会であると判定してもよい。

上記金融取引方法において、前記複数の口座情報において、第１の数以上の連続する口座番号が順番に並んでいるときに、不正の口座照会であると判定してもよい。

上記金融取引方法において、前記複数の口座情報を含む口座情報データセットが第２の数以上であって、前記第２の数以上の口座情報データセットの各々において前記第１の数未満の連続する口座番号が順番に並んでいるときに、不正の口座照会であると判定してもよい。

上記金融取引方法において、前記複数の口座情報と前記第１金融機関サーバに格納された実際の口座情報とを照会し、第１の数以上の前記照会結果が不一致であるときに、不正の口座照会であると判定してもよい。

上記金融取引方法において、前記複数の口座情報を含む口座情報データセットが第２の数以上であって、前記第２の数以上の口座情報データセットの各々において前記複数の口座情報と前記第１金融機関サーバに格納された実際の口座情報とを照会し、前記第１の数未満の前記照会結果が不一致であるときに、不正の口座照会であると判定してもよい。

上記金融取引方法において、前記照会結果に基づいて前記口座情報を用いて振込処理を行う振込日が、前記口座情報に基づく振込予定日と所定の日数以上異なるとき、不正の口座照会であると判定してもよい。

上記金融取引方法において、前記不正の口座照会であると判定したときに、所定の情報をユーザの端末に通知してもよい。

本発明の一実施形態によれば、第１金融機関サーバから送信された複数の口座情報の各々に対応する照会結果を含む口座照会履歴情報を取得する口座照会履歴情報取得部と、前記取得された口座照会履歴情報に基づいて不正の口座照会であるかを判定する口座照会判定部と、を含む、金融取引システムが提供される。

上記金融取引システムにおいて、前記複数の口座情報は、ユーザの端末から送信され、前記ユーザの識別子に関連付けされてもよい。

上記金融取引システムにおいて、前記口座照会判定部は、前記複数の口座情報が所定の数以上であるときに、不正の口座照会であると判定してもよい。

上記金融取引システムにおいて、前記口座照会判定部は、前記複数の口座情報が所定の数以上の連続する口座番号を含むときに、不正の口座照会であると判定してもよい。

上記金融取引システムにおいて、前記口座照会判定部は、前記複数の口座情報において、第１の数以上の連続する口座番号が順番に並んでいるときに、不正の口座照会であると判定してもよい。

上記金融取引システムにおいて、前記複数の口座情報を含む口座情報データセットが第２の数以上であって、前記口座照会判定部は、前記第２の数以上の口座情報データセットの各々において前記第１の数未満の連続する口座番号が順番に並んでいるときに、不正の口座照会であると判定してもよい。

上記金融取引システムにおいて、前記口座照会判定部は、前記複数の口座情報と前記第１金融機関サーバに格納された実際の口座情報とを照会し、第１の数以上の前記照会結果が不一致であるときに、不正の口座照会であると判定してもよい。

上記金融取引システムにおいて、前記複数の口座情報を含む口座情報データセットが第２の数以上であって、前記口座照会判定部は、前記第２の数以上の口座情報データセットの各々において前記複数の口座情報と前記第１金融機関サーバに格納された実際の口座情報とを照会し、前記第１の数未満の前記照会結果が不一致であるときに、不正の口座照会であると判定してもよい。

上記金融取引システムにおいて、前記口座照会判定部は、前記照会結果に基づいて前記口座情報を用いて振込処理を行う振込日が、前記口座情報に基づく振込予定日と所定の日数以上異なるとき、不正の口座照会であると判定してもよい。

上記金融取引システムにおいて、前記口座照会判定部が前記不正の口座照会であると判定したときに、所定の情報をユーザの端末に通知する通知部を含んでもよい。

本発明の一実施形態によれば、コンピュータが、照会目的情報を含むユーザの口座照会要求情報を取得し、前記口座照会要求情報と、記憶装置に予め記憶された情報との関係が照会可能条件を満たすとき、前記口座照会要求情報に関連付けられた口座照会処理を指示する、金融取引方法が提供される。

上記金融取引方法において、前記予め記憶された情報は、口座照会が承諾されたユーザの承諾ユーザ情報または口座照会可能な照会目的情報を含んでもよい。

上記金融取引方法において、前記照会可能条件は、前記口座照会要求情報と、前記承諾ユーザ情報または口座照会可能な照会目的情報とが少なくとも一部において一致することを含んでもよい。

上記金融取引方法において、前記承諾ユーザ情報は、承諾ユーザ識別情報、および前記承諾ユーザ識別情報と関連付けられた承諾ユーザパラメータを含み、前記口座照会要求情報は、前記照会目的情報とは異なる口座照会パラメータをさらに含み、前記承諾ユーザパラメータと前記口座照会パラメータとの関係が、第２照会可能条件を満たすときに、前記口座照会要求情報に関連付けられた口座照会処理を指示してもよい。

上記金融取引方法において、前記口座照会要求情報は、前記照会目的情報とは異なる口座照会パラメータをさらに含み、前記照会目的情報と前記口座照会パラメータとの関係が第２照会可能条件を満たすとき、前記口座照会要求情報に関連付けられた口座照会処理を指示してもよい。

上記金融取引方法において、前記口座照会パラメータは、前記ユーザが属するグループパラメータを含んでもよい。

上記金融取引方法において、前記口座照会要求情報は、複数であって、前記コンピュータは、前記複数の口座照会要求情報に対する口座照会可否データと、前記口座照会パラメータとの関係が、所定の条件を満たすときに、前記口座照会要求情報に関連付けられた口座照会を停止してもよい。

上記金融取引方法において、前記コンピュータは、前記ユーザの端末に前記停止された口座照会要求情報の修正指示情報を送信してもよい。

上記金融取引方法において、前記コンピュータは、前記口座照会を停止されたユーザの承諾ユーザ情報を、前記記憶装置から消去してもよい。

本発明の一実施形態によれば、前記コンピュータに、上記金融取引方法を実行させる、金融取引プログラムが提供される。

本発明の一実施形態によれば、照会目的情報を含むユーザの口座照会要求情報を取得する口座照会要求情報取得部と、前記照会目的情報と、記憶装置に予め記憶された情報との関係が照会可能条件を満たすとき、前記口座照会要求情報に関連付けられた口座照会処理を指示する口座照会指示部とを含む、金融取引システムが提供される。

上記金融取引システムにおいて、前記予め記憶された情報は、口座照会が承諾されたユーザの承諾ユーザ情報または口座照会可能な照会目的情報を含んでもよい。

上記金融取引システムにおいて、前記照会可能条件は、前記口座照会要求情報と、前記承諾ユーザ情報または前記口座照会可能な照会目的情報とが少なくとも一部において一致することを含んでもよい。

上記金融取引システムにおいて、前記承諾ユーザ情報は、承諾ユーザ識別情報と、前記承諾ユーザ識別情報と関連付けられた承諾ユーザパラメータを含み、前記口座照会要求情報は、前記照会目的情報とは異なる口座照会パラメータをさらに含み、前記口座照会指示部は、前記承諾ユーザパラメータと前記口座照会パラメータとの関係が、第２照会可能条件を満たすときに、前記口座照会要求情報に関連付けられた口座照会処理を指示してもよい。

上記金融取引システムにおいて、前記口座照会要求情報は、前記照会目的情報とは異なる口座照会パラメータをさらに含み、前記口座照会指示部は、前記照会目的情報と前記口座照会パラメータとの関係が第２照会可能条件を満たすとき、前記口座照会要求情報に関連付けられた口座照会処理を指示してもよい。

上記金融取引システムにおいて、前記口座照会パラメータは、前記ユーザが属するグループパラメータを含んでもよい。

上記金融取引システムにおいて、前記口座照会要求情報は、複数であって、前記複数の口座照会要求情報に対する口座照会可否データと、前記口座照会パラメータとの関係が、所定の条件を満たすときに、前記口座照会要求情報に関連付けられた口座照会を停止する口座照会停止部を含んでもよい。

上記金融取引システムにおいて、前記ユーザの端末に前記停止された口座照会要求情報の修正指示情報を送信する送信部を含んでもよい。

上記金融取引システムにおいて、前記口座照会停止部は、前記口座照会を停止されたユーザの照会要求ユーザ情報を、前記記憶装置から消去してもよい。

本発明の一実施形態を用いることにより、不正の口座照会を容易にかつ高い精度で判別することができる。または、本発明の一実施形態を用いることにより、迅速に不正の口座照会を判別することができる。または、本発明の一実施形態を用いることにより、金融機関間における迅速な口座照会を図ることができる。

本発明の第１実施形態に係る金融取引システムにおけるハードウェアの構成を示す図である。 本発明の第１実施形態に係る金融取引システムの各構成要素によって構成された機能ブロック図を示す。 口座照会履歴情報のデータ構造の一例である。 本発明の第１実施形態に係る金融取引方法のフロー図である。 口座情報の入力インタフェースの一例である。 本発明の第１実施形態に係る金融取引方法のフロー図である。 不正の口座照会を示す口座照会履歴情報のデータ構造の一例である。 不正の口座照会を示す口座照会履歴情報のデータ構造の一例である。 不正の口座照会を示す口座照会履歴情報のデータ構造の一例である。 不正の口座照会を示す口座照会履歴情報のデータ構造の一例である。 不正の口座照会を示す口座照会履歴情報のデータ構造の一例である。 本発明の第２実施形態に係る金融取引方法のフロー図である。 口座振込情報の入力インタフェースの一例である。 本発明の第２実施形態に係る金融取引方法のフロー図である。 本発明の第３実施形態に係る金融取引システムの各構成要素によって構成された機能ブロック図を示す。 口座照会要求情報のデータ構造の一例である。 業種コードのデータ構造の一例である。 金融機関情報のデータ構造の一例である。 承諾ユーザ情報のデータ構造の一例である。 本発明の第３実施形態に係る金融取引方法のフロー図である。 口座照会承諾要求情報の入力インタフェースの一例である。 本発明の第３実施形態に係る金融取引方法のフロー図である。 口座照会要求情報の入力インタフェースの一例である。 口座照会要求情報の判定結果のデータ構造の一例である。 本発明の第３実施形態に係る金融取引方法のフロー図である。 本発明の第３実施形態に係る金融取引方法のフロー図である。 口座照会要求情報のデータ構造の一例である。

以下、本発明の実施の形態を、図面等を参照しながら説明する。但し、本発明は多くの異なる態様で実施することが可能であり、以下に例示する実施の形態の記載内容に限定して解釈されるものではない。図面は説明をより明確にするため、模式的に表される場合があるが、あくまで一例であって、本発明の解釈を限定するものではない。

また、各要素に対する「第１」、「第２」と付記された文字は、各要素を区別するために用いられる便宜的な標識であり、特段の説明がない限りそれ以上の意味を有さない。なお、本実施形態で参照する図面において、同一部分または同様な機能を有する部分には同一の符号または類似の符号（数字ｘｘｘにＡ，Ｂまたは１，２などを付しただけの符号）を付し、その繰り返しの説明は省略する場合がある。また、構成の一部が図面から省略されたりする場合がある。その他、本発明の属する分野における通常に知識を有する者であれば認識できるものである場合、特段の説明を行わないものとする。

＜第１実施形態＞
本発明の第１実施形態に係る金融取引システムおよび金融取引方法について、図面を参照しながら詳細に説明する。

（１−１．金融取引システムのハードウェア構成）
図１に、金融取引システム１のハードウェア構成を示す。金融取引システム１の一部の構成において、口座情報に口座照会結果を加えた口座照会履歴情報を用いて不正の口座照会があるかの判定処理が容易にかつ高い精度で実行される。図１に示すように、金融取引システム１は、自行サーバ１０（第１金融機関サーバともいう）、統合ＡＴＭサーバ２０、及び他行サーバ３０（第２金融機関サーバともいう）およびユーザ端末４０を含む。自行サーバ１０は、ユーザ端末４０から送信された口座情報に対する不正口座照会監視用のデータベースおよびアプリケーションサーバとして機能する。統合ＡＴＭサーバ２０は、自行サーバ１０から処理要求された情報を他行サーバに送信するサーバとして機能する。他行サーバ３０（第２金融機関サーバともいう）は、口座情報に応じた口座照会、及び口座振込要求に応じた振り込み処理を行うサーバである。ユーザ端末４０は、口座照会要求及び口座振込要求を自行サーバ１０に対して行う端末である。図１において、他行サーバ３０は２つ（他行サーバ３０−１、他行サーバ３０−２）設けられているが、1つでもよいし、３つ以上設けられてもよい。説明の関係上、後の説明においては１つの他行サーバ３０として説明する。また、金融取引システム１は、自行サーバ１０、統合ＡＴＭサーバ２０、及び他行サーバ３０で構成されてもよい。次に、それぞれのハードウェアの構成について以下に説明する。

自行サーバ１０は、制御部１１、記憶部１２、通信部１３、および表示部１４を有する。制御部１１、記憶部１２、通信部１３、および表示部１４はバスを介して接続される。

制御部１１は、コンピュータの一つであり、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）、ＡＳＩＣ（Ａｐｐｌｉｃａｔｉｏｎ Ｓｐｅｃｉｆｉｃ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ）、ＦＰＧＡ（Ｆｉｅｌｄ Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙ）、またはその他の演算処理回路を用いて、金融取引、特に後述する不正口座照会監視用のソフトウェア（プログラム）に規定された命令に基づく処理を制御する。また、制御部１１からの命令によって、不正口座照会監視プログラムを実行するためのユーザインターフェースが表示部１４に提供されてもよい。

記憶部１２には、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）の半導体メモリ等のほか、磁気記録媒体（磁気テープ、磁気ディスク等）、光記録媒体、光磁気記録媒体、その他記憶可能な素子が用いられる。記憶部１２は、不正口座照会監視プログラムを記憶するとともに、不正口座照会監視プログラムで用いられる口座情報および口座照会結果を記憶した口座照会履歴情報を格納する口座照会履歴情報データベースとしての機能を有する。記憶部１２は、適宜自行サーバ１０と異なるサーバに設けられ、データベースとして機能してもよい。そのため、記憶部１２は記憶装置ともいうことができる。

通信部１３は、送受信機を有し、ネットワーク５０を介して統合ＡＴＭサーバ２０、ユーザ端末４０、及び他行サーバ３０と口座情報、口座振込情報およびその他関連する情報の通信を行う。通信部１３と、統合ＡＴＭサーバ２０、ユーザ端末４０、及び他行サーバ３０との通信には、インターネット（具体的にはＳＳＬ（Ｓｅｃｕｒｅ Ｓｏｃｋｅｔｓ Ｌａｙｅｒ）／ＴＬＳ（Ｔｒａｎｓｐｏｒｔ Ｌａｙｅｒ Ｓｅｃｕｒｉｔｙ）またはＶＰＮ（Ｖｉｒｔｕａｌ Ｐｒｉｖａｔｅ Ｎｅｔｗｏｒｋ））が用いられる。

統合ＡＴＭサーバ２０は、制御部２１、記憶部２２、通信部２３および表示部２４を有する。制御部２１、記憶部２２、通信部２３および表示部２４は、バスを介して接続される。

制御部２１は、コンピュータの一つであり、ＣＰＵ、ＡＳＩＣ、ＦＰＧＡ、またはその他の演算処理回路を用いて統合ＡＴＭサーバ２０で規定された命令に基づいた金融取引処理を制御する。制御情報は、表示部２４に表示されてもよい。

記憶部２２は、統合ＡＴＭサーバ２０における金融取引処理プログラムおよびその他関連する情報を記憶する。

通信部２３は、ネットワーク５０を介して自行サーバ１０、他行サーバ３０、およびユーザ端末４０との情報通信を行う。通信部２３と、自行サーバ１０、他行サーバ３０およびユーザ端末４０との通信には、インターネット（具体的にはＳＳＬ／ＴＬＳまたはＶＰＮ）が用いられる。

他行サーバ３０は、制御部３１、記憶部３２、通信部３３、および表示部３４を有する。制御部３１、記憶部３２、通信部３３、および表示部３４は、バスを介して接続される。

制御部３１は、コンピュータの一つであり、ＣＰＵ、ＡＳＩＣ、ＦＰＧＡ、またはその他の演算処理回路を用いて口座照会、振込処理、その他の金融取引プログラムで規定された命令に基づいて処理を制御するとともに、不正口座照会監視プログラムに関連するプログラムで規定された命令に基づいて各種処理を制御する。また、制御部３１からの命令によって、上記プログラムを実行するためのユーザインターフェースが表示部３４に表示されてもよい。

記憶部３２は、他行サーバ３０における振込処理プログラムおよび不正口座照会監視プログラムに関連する情報を記憶する。

通信部３３は、ネットワーク５０を介して自行サーバ１０、および統合ＡＴＭサーバ２０との情報通信を行う。通信部３３と、自行サーバ１０および統合ＡＴＭサーバ２０との通信には、インターネット（具体的にはＳＳＬ／ＴＬＳまたはＶＰＮ）が用いられる。

ユーザ端末４０は、表示部４１、制御部４２、記憶部４３、操作部４４および通信部４５を有する。表示部４１、制御部４２、記憶部４３、操作部４４および通信部４５はバスを介して接続される。ユーザ端末４０は、スマートフォン、携帯電話（フィーチャーフォン）、タブレット型端末、ノート型ＰＣ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ）、デスクトップ型ＰＣ、ＩｏＴ（Ｉｎｔｅｒｎｅｔ ｏｆ Ｔｈｉｎｇｓ）デバイス（例えば、電源機構、通信機能および情報記憶機構を備えた機器）などでもよく、ネットワークを通じて自行サーバ１０と通信可能なものであれば適用可能である。ユーザ端末４０を使用するユーザとして、例えば損害保険会社、生命保険会社、クレジットカード会社などが挙げられる。

表示部４１は、液晶ディスプレイまたは有機ＥＬ（Ｅｌｅｃｔｒｏ Ｌｕｍｉｎｅｓｃｅｎｃｅ）ディスプレイなどの表示デバイスであって、制御部４２から入力される信号により表示内容が制御される。

制御部４２は、コンピュータの一つであり、ＣＰＵ、ＡＳＩＣ、ＦＰＧＡ、またはその他の演算処理回路を備える。制御部４２は、表示部４１および操作部４４の操作に基づいてメモリなどの記憶部４３に記憶されたプログラムを実行させる。また、制御部４２は、自行サーバ１０の記憶部１２に記憶された不正口座照会監視プログラムに関連する処理の実行を指示するための情報を送信する。

操作部４４は、コントローラー、ボタン、またはスイッチを含む。ユーザから操作部４４を用いて上下左右への移動、押圧、または回転などの動作がなされることにより、その動作に基づく情報が制御部４２に入力される。なお、タッチセンサを有する表示装置（タッチパネル）であれば、表示部４１と操作部４４とが、同じ場所に配置されてもよい。

通信部４５は、自行サーバ１０と送受信する機能を有する。例えば、通信部４５には、ＬＡＮを介した送受信機が用いられる。なお、通信部４５は、ＬＡＮを介した送受信機に限定されず、携帯端末用通信（例えばＬＴＥ通信）用の送受信機が設けられてもよいし、近距離無線通信用の送受信機が設けられてもよい。ユーザ端末４０は、ネットワーク５０を介して自行サーバ１０と接続される。

（１−２．不正口座照会監視制御部１００の構成）
図２は、金融取引システム１の各構成要素によって構成された機能ブロック図を示す。

自行サーバ１０は、不正口座照会監視機能を実現させるプログラム（不正口座照会監視プログラム）を制御する不正口座照会監視制御部１００を有する。不正口座照会監視制御部１００は、口座照会履歴情報取得部１１０、口座照会判定部１２０、および通知部１３０を含む。

口座照会履歴情報取得部１１０は、ユーザ端末４０から送信された識別子に関連付けされた照会対象となる複数の口座情報口座情報と、他行サーバから送信された複数の口座情報の各々に対応する照会結果とを、口座照会履歴情報として取得する機能を有する。口座照会履歴情報取得部１１０で取得した情報は自行サーバ１０の記憶部１２の口座照会履歴情報データベース１２ａにそれぞれ格納される。

図３は、記憶部１２のうち口座照会履歴情報データベース１２ａに記憶された口座照会履歴情報１１１のデータ構造の一例である。口座照会履歴情報１１１は、口座情報１１３、および照会結果１１５を含む。依頼者１１２ａ、依頼者識別番号１１２ｂ、口座照会用の依頼ファイル１１２ｃ、および口座情報１１３は、ユーザ端末４０で入力された情報である。この例では、口座情報１１３として、依頼番号１１３ａ、目的コード１１３ｂ、金融機関名１１３ｃ、支店名１１３ｄ、預金種別１１３ｅ、口座番号１１３ｆ、口座名義人１１３ｇが含まれる。

依頼者１１２ａは、口座照会を依頼するユーザをいう。この場合のユーザは、ユーザ端末４０を使用するユーザである。例えば、ユーザは、損害保険会社、生命保険会社、クレジットカード会社などの法人が挙げられる。なお、法人に限定されず、自然人であってもよい。

口座照会を要する複数の口座情報１１３は、依頼ファイル１１２ｃ（口座情報データセットともいう）内に設けられる。この例では、１０個の口座情報は、１個の依頼ファイル名がＡ００１の依頼ファイル１１２ｃ内に設けられる。

依頼番号１１３ａ（取引通番ともいう）は、各々の口座情報に紐づけられた識別子である。この例では、依頼番号１１３ａは、アルファベットおよび数字を含む７文字からなり、上から順に並んでいる。なお、依頼番号１１３ａは、さらに年月日と組み合わせてもよい。

目的コード１１３ｂは、口座照会の目的を示すものである。例えば、口座照会のみを目的とする場合には、目的コード１１３ｂには、照会のみ（０Ａ）と記載される。口座照会後に振り込みを行う場合には、照会＋振込（１Ａ１Ｗ）などと記載される。より具体的には、口座照会後一日後に振込を行う場合には１Ａ０１，口座照会後一週間後に振込を行う場合には１Ａ１Ｗ，口座照会後一月後に振込を行う場合には１Ａ１Ｍ，口座照会後１２月後に振込を行う場合には１Ａ１２Ｍと記載される。

照会結果１１５は、各口座情報１１３に対応して口座照会した結果が記載される。この例では、口座情報に記載された各情報のうち他行サーバ３０に記録されている口座情報と完全に一致しているか否かによって、一致または不一致を判定する。この場合、一文字でも異なった場合には不一致と判定される。なお、不一致の場合の記載として口座番号相違、口座名義人相違、または預金種別相違など具体的に記載してもよい。

口座照会判定部１２０は、口座照会履歴情報に基づいて不正の口座情報であるかを判定する機能を有する。口座照会判定部１２０は、口座照会履歴情報が所定の条件に該当する場合には、不正の口座照会であると判定する。

通知部１３０は、口座照会判定部１２０がユーザ端末４０から送信された口座情報が不正の口座照会であると判定したときに、ユーザの識別番号（識別子）に対応する口座照会を停止することをユーザ端末４０に通知する機能を有する。

統合ＡＴＭサーバ２０は、記憶部２２に記憶された金融取引処理プログラムで規定された命令に基づいて他行サーバ３０に金融取引処理を実行させるために指示するとともに不正口座照会監視プログラムに関連するプログラムで規定された命令に基づいて処理を実行する。統合ＡＴＭサーバ２０は、機能部として受信部２１０および送信部２２０を含む。受信部２１０は、自行サーバ１０から送信される金融取引依頼情報（この例では、口座情報または振込依頼情報）を受信する。送信部２２０は、金融取引依頼情報を他行サーバ３０に送信する。

他行サーバ３０は、記憶部３２に記憶された金融取引処理プログラムで規定された命令に基づいて口座照会処理および振込処理を実行するとともに不正口座照会監視プログラムに関連するプログラムで規定された命令に基づいて処理を実行する。他行サーバ３０は、機能部として受信部３１０、口座照会処理部３２０、振込処理部３３０、および送信部３４０を含む。受信部３１０は、統合ＡＴＭサーバ２０から送信される金融取引依頼情報（この例では、口座情報または振込依頼情報）を受信する。口座照会処理部３２０は、口座情報に基づき口座照会処理を実行する。振込処理部３３０は、振込依頼情報に基づき所定の口座への振込（送金）処理を実行する。送信部３４０は、金融取引情報（この例では、口座照会結果または振込完了情報）を統合ＡＴＭサーバ２０に送信する。

ユーザ端末４０は、記憶部４３に記憶された金融取引処理または不正口座照会監視制御プログラムに関連するプログラムに規定された処理を実行する。ユーザ端末４０は、機能部としてそれぞれ受信部４１０、および送信部４２０を有する。受信部４１０は、自行サーバ１０から口座照会結果を含む各種取引情報を受信する機能を有する。送信部４２０は、自行サーバ１０に対して各種依頼情報を送信する機能を有する。

（１−３．金融取引方法）
次に、不正口座照会監視制御部１００における不正口座照会監視プログラムによる命令に基づいた金融取引方法について説明する。本実施形態では、口座照会のみを行う場合の不正口座照会をモニタリング方法について説明する。

図４および図６は、金融取引方法のフロー図である。図４に示すように、まずユーザ端末４０において、口座照会の対象となる口座情報が入力される（Ｓ１０１）。口座情報の入力は、ユーザ端末４０の表示部４１に表示された自行のインターネットバンキングの入力画面において行われる。

図５は、口座照会の対象となる口座情報入力用のユーザインターフェースの一例である。ユーザは、依頼者１１２ａ、依頼者識別番号１１２ｂ、目的コード１１３ｂ、金融機関名１１３ｃ、支店名１１３ｄ、預金種別１１３ｅ、口座番号１１３ｆ、口座名義人１１３ｇを入力する。複数の口座照会要求を行う場合には、追加ボタン１１７を押すことにより、次の口座情報を入力することができる。入力がすべて完了した場合には、入力完了ボタン１１９を押すことにより、各口座情報に対して依頼番号が設定される。また、連続して口座情報を入力した場合には、複数の口座情報を含む口座情報データセットとして依頼ファイル番号が設定される。

口座情報の入力が完了した後、ユーザ端末４０の送信部４２０から自行サーバ１０に対して照会対象となる口座情報がリクエスト電文として送信される（Ｓ１０３）。なお、照会対象となる口座情報が複数の場合には、データファイルをあらかじめユーザ端末内４０で生成・格納し、その情報をネットワーク経由で自行サーバ１０にアップロードしてもよい。自行サーバ１０が口座情報を受信すると、当該口座情報は、口座照会履歴情報データベース１２ａに格納される（Ｓ１０５）。

次に、自行サーバ１０は、口座情報を統合ＡＴＭサーバ２０に送信する（Ｓ１０７）。統合ＡＴＭサーバ２０は、口座情報を受信すると（Ｓ１０９）、口座情報に対応する他行サーバ３０に対して、口座情報を送信する（Ｓ１１１）。

次に、他行サーバ３０が口座情報を受信すると（Ｓ１１３）、口座照会処理を実行する（Ｓ１１５）。具体的には、口座情報に記載された各情報のうち他行サーバ３０に記録されている口座情報と完全に一致しているか否かによって、一致または不一致を判定する。この場合、一文字でも異なった場合には不一致として処理される。照会結果は、依頼番号に紐づけて入力される。照会結果が不一致の場合、不一致、ＮＧなどのように単純な入力でもよいし、口座番号相違（口座なし）、口座名義人相違、または預金種別相違など具体的に入力されてもよい。口座照会完了後、他行サーバ３０は、統合ＡＴＭサーバ２０に口座照会結果を送信する（Ｓ１１７）。

次に、統合ＡＴＭサーバ２０が口座照会結果を受信すると（Ｓ１１９）、口座照会結果に対応する依頼番号に基づいて、自行サーバ１０に口座照会結果を送信する（Ｓ１２１）。

次に、自行サーバ１０の口座照会履歴情報取得部１１０は、口座照会結果を受信すると（Ｓ１２３）、図６に示すように、口座照会結果を同一の依頼番号に紐づけられた口座情報とともに口座照会履歴情報として口座照会履歴情報データベース１２ａに格納する（Ｓ２０１）。

口座照会履歴情報が格納されると、口座照会判定部１２０は、要求された口座照会が不正の口座照会であるか否かを判定する（Ｓ２０３）。このとき、口座照会判定部１２０は、過去に同一ユーザが口座照会を行ったかを判定する（Ｓ２０５）。過去に同一ユーザによる口座照会がない場合（Ｓ２０５；Ｎｏ）、現在の口座照会履歴情報をもとに不正の口座照会であるか否かを判定する。過去に同一ユーザが口座照会を行った場合（Ｓ２０５；Ｙｅｓ）、過去の口座照会履歴情報と組み合わせて判定してもよい（Ｓ２０６）。例えば、今回の判定の直前に同一ユーザが所定の数（具体的には３個）の依頼ファイルを用いて口座照会をしていた場合が挙げられる。

口座照会判定部１２０は、口座照会履歴情報が所定に条件に該当するかを判定する。以下に、口座照会のみが目的の場合の不正の口座照会の判定方法について説明する。

図７は、不正の口座照会の一例である。図７の口座照会履歴情報の場合、同一の依頼ファイル内の口座照会要求履歴情報において連続した口座番号が所定の数以上（この例では合計１０件）順番に並んで照会されている。この場合、１０件のうち１件において口座照会が一致したとしても依頼者ｘｘｘｘｘの口座照会要求が不正の口座照会であると判定される。

図８は、不正の口座照会の一例である。図８の口座照会履歴情報の場合、同一の依頼ファイル内の口座照会要求履歴情報において連続した口座番号が所定の数以上（この例では合計１０件）存在するように照会されている。この場合、依頼ファイル内の一部の口座照会が一致したとしても依頼者ｘｘｘｘｘの口座照会要求が不正の口座照会であると判定される。

図９は、不正の口座照会の一例である。図９の口座照会履歴情報の場合、同一の依頼ファイル（口座情報データセット）Ａ００１）内の口座照会要求履歴情報において、所定の数以上（この例では合計１０件）の口座照会の不一致が存在する。この場合、依頼者ｘｘｘｘｘの口座照会要求が不正の口座照会であると判定される。

図１０は、不正の口座照会の一例である。図１０の口座照会履歴情報は、同一の依頼者による所定の数（第２の数ともいう、この例では３個）の依頼ファイル（口座情報データセット）Ａ００１、Ａ００２、およびＡ００３を含む。このとき、依頼ファイルＡ００１、依頼ファイルＡ００２、および依頼ファイルＡ００３の口座情報において連続した口座番号が１０件未満連続で照会されている。この場合、図７の場合と異なり、一つの依頼ファイル内で連続した口座番号が所定の数（第１の数ともいう、この例では合計１０件）未満照会されていたとしても、依頼者ｘｘｘｘｘの口座照会要求が不正の口座照会であると判定される。

図１１は、不正の口座照会の一例である。図１０の口座照会履歴情報は、同一の依頼者による所定の数（第２の数ともいう、この例では１０個）の依頼ファイル（口座情報データセット）Ａ００１〜Ａ０１０を含む。このとき、依頼ファイルＡ００１〜Ａ０１０の口座情報において口座番号が１０件未満の口座照会の不一致と１件の口座照会の一致が存在する。この場合、図９の場合と異なり、１つの依頼ファイル内で口座番号が所定の数（第１の数ともいう、この例では合計１０件）未満の口座照会の不一致であっても、依頼者ｘｘｘｘｘの口座照会要求が不正の口座照会であると判定される。

また、上記以外に同一の依頼者からの照会対象となる口座情報の数があらかじめ規定された数を超えた場合においても、不正の口座照会であると判定されてもよい。

口座照会履歴情報が、上記のいずれの場合にも該当しない場合、口座照会判定部１２０は、依頼者ｘｘｘｘｘの口座照会要求が正当な口座照会であると判定する（Ｓ２０７；Ｎｏ）。このとき、自行サーバ１０は、ユーザ端末４０に口座照会結果を送信する（Ｓ２０９）。ユーザ端末４０は、口座照会結果を受信したとき（Ｓ２１１）、口座照会結果を受信したことを表示部４１に表示してもよい。

一方、口座照会履歴情報が、上記のいずれかの場合に該当する場合、口座照会判定部１２０は、依頼者ｘｘｘｘｘの口座照会要求が不正の口座照会であると判定する（Ｓ２０７；Ｙｅｓ）。このとき、自行サーバ１０の口座照会判定部１２０は、依頼者ｘｘｘｘｘ（識別番号１２３４５）による口座照会を停止する（アカウントを停止する）（Ｓ２１３）。

口座照会停止処理が完了すると、通知部１３０は、ユーザ端末４０に対して、依頼者ｘｘｘｘｘによる口座照会を停止したことを通知するための電文を送信する（Ｓ２１５）。ユーザ端末４０は、口座照会停止の電文を受信した後（Ｓ２１７）、依頼者ｘｘｘｘｘによる口座照会要求ができない状態となる。

本実施形態を用いることにより、膨大な数の口座照会要求があった場合においても容易にかつ高い精度で不正の口座照会を判別することができる。

＜第２実施形態＞
本実施形態では、口座照会と合わせて振込処理を行う場合の不正口座照会をモニタリング方法について説明する。なお、本実施形態では、口座照会の段階では正当な口座照会と判定され、ユーザ端末４０が口座照会結果を受信した（Ｓ２１１）以降のフローについて説明する。

図１２及び図１３は、金融取引方法のフロー図である。図１２に示すように、受信した口座照会結果をもとに、ユーザ端末４０において、口座振込の対象となる口座振込情報が入力される（Ｓ３０１）。口座情報の入力は、ユーザ端末４０の表示部４１に表示された自行のインターネットバンキングの入力画面において行われる。

図１３は、口座振込情報入力用のユーザインターフェースの一例である。ユーザは、口座振込情報３１３に依頼者３１２ａ、依頼者識別番号３１２ｂ、目的コード３１３ｂ、金融機関名３１３ｃ、支店名３１３ｄ、預金種別３１３ｅ、口座番号３１３ｆ、口座名義人３１３ｇおよび振込日３１３ｈを入力する。複数の口座振込を要求する場合には、追加ボタン３１７を押すことにより、次の口座振込情報を入力することができる。口座振込情報の入力がすべて完了した場合には、入力完了ボタン３１９を押すことにより、各口座振込情報に対して依頼番号が設定される。また、連続して口座振込情報を入力した場合には、口座振込情報データセットとして依頼ファイル番号が設定される。

口座振込情報の入力が完了した後、ユーザ端末４０の送信部４２０から自行サーバ１０に対して口座振込情報がリクエスト電文として送信される（Ｓ３０３）。なお、口座振込情報が複数の場合には、データファイルをあらかじめユーザ端末内４０で生成・格納し、その情報をネットワーク５０経由で自行サーバ１０にアップロードしてもよい。自行サーバ１０が口座振込情報を受信すると、当該口座振込情報は、口座照会履歴情報データベース１２ａに格納されてもよい（Ｓ３０５）。

口座振込情報が格納された後、口座照会判定部１２０は、口座振込情報が所定の条件に該当するかを判定する。具体的には、口座振込情報に含まれる振込日と、口座情報に含まれる振込予定日とを比較する（Ｓ３０７）。口座振込情報に含まれる振込日と、口座情報に含まれる振込予定日とが、一致する又は所定の期日（例えば５営業日）以内である場合、口座照会判定部１２０は、口座振込情報が正当な口座照会に基づくものと判定し（Ｓ３０９；Ｎｏ）、統合ＡＴＭサーバ２０および他行サーバ３０に口座振込情報を送信するとともに、振込処理を実行する（Ｓ３１１）。

一方、口座振込情報に含まれる振込日が、口座情報に含まれる振込予定日と、所定の期日（例えば５営業日）以上異なる（経過する）場合、口座照会判定部１２０は、口座振込情報が不正の口座照会に基づくものと判定する（Ｓ３０９；Ｙｅｓ）。このとき、口座照会判定部１２０は、ユーザ端末４０に対して、口座振込情報に含まれる振込日が、口座情報に含まれる振込予定日と、所定の期日（例えば５営業日）以上異なる理由についての回答情報を入力するための指示情報（回答入力指示情報）を生成し（Ｓ３１３）、送信してもよい（Ｓ３１５）。ユーザ端末４０の受信部４１０が、回答入力指示情報を受信し（Ｓ３１７）、回答情報が入力されると（Ｓ３１９）、ユーザ端末４０の送信部４２０は、自行サーバ１０に対して回答情報を送信する（Ｓ３２１）。自行サーバ１０が回答情報を受信したとき（Ｓ３２３）、口座照会判定部１２０は、回答情報の内容に基づいて不正口座照会であるかを再度判定してもよい（Ｓ３２５）。正当な口座照会であると判定された場合（Ｓ３２５；Ｎｏ）、振込処理が行われる（Ｓ３２７）。不正口座照会であると、再度判定された場合（Ｓ３２５；Ｙｅｓ）、自行サーバ１０の口座照会判定部１２０は、依頼者ｘｘｘｘｘ（識別番号１２３４５）による口座照会を停止する（アカウントを停止する）（Ｓ３２９）。なお、口座照会判定部１２０は、回答情報を入力するための指示情報（回答入力指示情報）を必ずしも送信しなくてもよい。

口座照会停止処理が完了すると、通知部１３０は、ユーザ端末４０に対して、依頼者ｘｘｘｘｘによる口座照会を停止したことを通知するための電文を送信する（Ｓ３３１）。ユーザ端末４０は、口座照会停止の電文を受信した後（Ｓ３３３）、依頼者ｘｘｘｘｘによる口座照会要求ができない状態となる。

本実施形態を用いることにより、膨大な数の口座照会要求があった場合においても容易にかつ高い精度で不正の口座照会を判別することができる。

＜第３実施形態＞
本実施形態では、第１実施形態とは異なる口座照会のモニタリング方法について説明する。具体的には、口座照会要求情報の取得時に口座照会のモニタリングを行う例について説明する。なお、第１実施形態と重複する構成については適宜説明を省略する。

（３−１．不正口座照会監視制御部１００Ａの構成）
図１５は、金融取引システム１Ａの各構成要素によって構成された機能ブロック図を示す。

図１５に示すように、自行サーバ１０Ａは、不正口座照会監視機能を実現させるプログラム（不正口座照会監視プログラム）を制御する不正口座照会監視制御部１００Ａを有する。不正口座照会監視制御部１００Ａは、口座照会要求情報取得部１０１０、識別情報取得部１０２０、口座照会判定部１０３０、口座照会指示部１０４０、口座照会停止部１０５０、通知部１０６０および送信部１０７０を含む。

口座照会要求情報取得部１０１０は、ユーザ端末４０から照会目的情報、金融機関情報およびユーザ情報を含む口座照会要求情報を取得する機能を有する。口座照会要求情報取得部１０１０で取得した情報は自行サーバ１０Ａ（金融機関サーバ）の記憶部１２Ａの口座照会情報データベース１２Ａａにそれぞれ格納される。

図１６は、記憶部１２Ａのうち口座照会情報データベース１２Ａａに記憶された口座照会要求情報６００のデータ構造の一例である。口座照会要求情報６００は、ユーザ情報６０１（照会要求ユーザ情報ともいう）および口座照会要求データ６０２（口座照会金融機関情報ともいう）を含む。ユーザ情報６０１は、ユーザ名６０１ａ、ユーザコード６０１ｂおよび業種コード６０１ｃを含む。

ユーザ名６０１ａは、口座照会を要求するユーザである。この場合のユーザは、ユーザ端末４０を使用するユーザである。例えば、ユーザは、損害保険会社、生命保険会社、クレジットカード会社、株式会社、スーパー・小売り等の流通会社、官公庁、地方公共団体、または独立行政法人などの各種法人または、上記法人から業務委託を受けた法人が挙げられる。なお、法人に限定されず、自然人であってもよい。

ユーザコード（ユーザ識別情報、または加盟店コードともいう）６０１ｂは、口座照会を要求するユーザそれぞれに紐づけられた番号を情報いう。この例では、ユーザコード６０１ｂは、１０桁の番号からなる。または、ユーザコード６０１ｂは、９桁の連番からなり、残りの一桁をチェック用として用いてもよい。この場合、ユーザコード６０１ｂは、ｍｏｄｕｌｕｓ１０で構成される。

また、業種コード６０１ｃは、ユーザの業種ごとに割り当てられた番号をいう。業種コード６０１ｃは、ユーザが属するグループパラメータともいうことができる。この例では、業種コードとして保険会社（０２）が表記されている。図１７は、業種コード６０１ｃのデータ構造である。業種コード６０１ｃは、業種名６０１ｃ１および業種コード６０１ｃ２を含む。図１７に示すように、業種ごとに決められた業種コードが割り当てられる。なお、業種コード６０１ｃは、新たに設けられなくてもよい。この場合、１０桁の番号のうち、１０桁目の番号は業種ごとに割り振られたものであってもよい。

口座照会要求データ６０２は、口座照会依頼番号６０２ａ、目的コード６０２ｂ、金融機関名６０２ｃ、金融機関コード６０２ｄ（金融機関識別番号）、支店名６０２ｅ、預金種別６０２ｆ、口座番号６０２ｇ、および口座名義人６０２ｈを含む。目的コード６０２ｂは、照会目的情報ともいう。口座照会要求情報のうち、業種コード６０１ｃ、金融機関名６０２ｃ、金融機関コード６０２ｄ、支店名６０２ｅ、預金種別６０２ｆ、口座番号６０２ｇ、および口座名義人６０２ｈは口座照会パラメータともいう。

口座照会を要求する口座照会要求データ６０２は、この例では、１０個の口座照会情報を一つのデータセット（依頼ファイル）としている。

依頼番号６０２ａ（取引通番ともいう）は、各々の口座照会要求データに紐づけられた識別子である。この例では、依頼番号６０２ａは、アルファベットおよび数字を含む７文字からなり、上から順に並んでいる。なお、依頼番号６０２ａは、さらに年月日と組み合わせてもよい。

目的コード６０２ｂ（照会目的情報）は、口座照会の目的を示すものである。例えば、公的な口座振り込みを行う前の事前確認を目的とした場合の目的コードには、「１．公的用」と表記される。一方、民間（商業用）口座振り込みを行う前の事前確認を目的とした場合の目的コードには「２．商業用」が表記される。口座照会要求情報６００が目的コード６０２ｂを含む場合に、後述するように口座照会判定部１０３０による判定処理がなされる。一方、口座照会要求情報６００内に目的コード６０２ｂがない場合、照会目的が不明であるとして口座照会判定部１０３０により判定処理がなされなくてもよい。または口座照会情報ＤＢ１２Ａａに目的コードが登録されていない場合には、口座照会判定部１０３０により不正照会要求であると判定されてもよい。

金融機関コード（金融機関識別情報）６０２ｄは、金融機関名に対応付けられた番号である。この例では、金融機関コード６０２ｄは、４桁の番号からなる。

識別情報取得部１０２０は、口座照会可能な金融機関情報、口座照会が承諾されたユーザの承諾ユーザ情報、口座照会可能な目的情報を取得する機能を有する。口座照会可能な目的情報（目的コード）は、例えば「１．公的用（口座照会）」という情報である。

図１８は、記憶部１２Ａのうち口座照会情報データベース１２Ａａに記憶された金融機関情報６１０のデータ構造の一例である。この例では、金融機関情報６１０は、金融機関名６１０ａ、および口座照会対応金融機関コード６１０ｂを含む。金融機関名６１０ａ、および口座照会対応金融機関コード６１０ｂは、他行サーバ３０から送信された情報に基づいて登録される。

金融機関名６１０ａは、自行との間で口座照会が可能な金融機関をいう。口座照会対応金融機関コード６１０ｂは、金融機関名６１０ａに紐づけられた固有の識別情報である。この例では、口座照会対応金融機関コード６１０ｂは、４桁の番号である。図１８のデータ構造に含まれていない金融機関は、原則として口座照会指示を受けることができない。

図１９は、記憶部１２Ａのうち口座照会情報データベース１２Ａａに記憶された承諾ユーザ情報６２０のデータ構造の一例である。この例では、承諾ユーザ情報６２０は、承諾ユーザ名６２０ａ、承諾ユーザコード（承諾ユーザ識別情報ともいう）６２０ｂ、業種コード６２０ｃ、関連法人数６２０ｄ、および信頼度６２０ｅを含む。承諾ユーザ名６２０ａ、承諾ユーザコード６２０ｂ、業種コード６２０ｃ、関連法人数６２０ｄ、および信頼度６２０ｅは、ユーザ端末４０から送信された情報に基づいて登録される。業種コード６２０ｃ、関連法人数６２０ｄ、および信頼度６２０ｅの各データは、承諾ユーザパラメータともいう。

承諾ユーザ名６２０ａは、口座照会を承諾されたユーザ名を示す。承諾ユーザコード６２０ｂは、承諾ユーザ名６２０ａに紐づけられた固有の識別情報である。この例では、承諾ユーザコード６２０ｂは、１０桁の番号である。

業種コード６２０ｃは、承諾ユーザの業種ごとに割り当てられたグループ情報をいう。

関連法人数６２０ｅは、承諾ユーザについての関連法人数をいう。関連法人とは、ユーザと業務または資本等において法人を運営するうえで関連する法人（グループ法人）をいう。例えば、関連法人数が「０」の場合、単独の法人であることを意味する。関連法人数「５」の場合、承諾ユーザと関連するグループ法人が５つあることを示す。関連法人数が大きいほど、多くの法人と連結しているということができる。

信頼度６２０ｅは、承諾ユーザの信頼度を意味する。信頼度６２０ｅは、業種コードおよび関連法人数に基づいて設定されてもよい。例えば、信頼度は、１０段階で設定してもよい。業種が地方公共団体の場合には、信頼度は高く設定されてもよい。一方、関連法人数が多いと、関連法人への情報の漏洩の観点から信頼度が低く設定されてもよい。

口座照会判定部１０３０は、口座照会要求情報に基づいて口座照会の可否を判定する機能を有する。この例では、口座照会判定部１０３０は、照会目的情報が記憶部１２Ａに記憶された口座照会可能な照会目的情報と一致しているか、口座照会要求情報のユーザコードが記憶部１２Ａに記憶された承諾ユーザ情報の承諾ユーザコードとが一致しているか、または口座照会要求情報の金融機関コードが記憶部１２Ａに記憶された口座照会可能な金融機関コードと一致しているかによって口座照会が可能であるかどうかを判定する。

口座照会指示部１０４０は、口座照会要求情報と、記憶部１２Ａ（記憶装置）にあらかじめ記憶された情報との関係が所定の口座照会可能条件を満たすときに口座照会要求情報に関連付けられた口座照会処理を指示する機能を有する。

口座照会停止部１０５０は、口座照会要求情報に関連付けられた口座照会を停止する機能を有する。この例では、複数の口座照会要求情報に対する口座照会可否データと、口座照会要求パラメータとの関係が、所定の条件を満たすときに、口座照会要求情報に関連付けられた口座照会を停止する。具体的には、業種コードは関連法人数に合わせて口座照会可能率の設定値を設け、設定値を超えた場合には口座照会を停止する。

通知部１０６０は、口座照会判定部１０３０がユーザ端末４０から送信された口座照会要求情報が不正の口座照会であると判定したときに、ユーザ識別番号（識別子）に対応する口座照会を停止することをユーザ端末４０に通知する機能を有する。

送信部１０７０は、統合ＡＴＭサーバ２０、他行サーバ３０、およびユーザ端末４０に各種情報を送信する機能を有する。さらに、送信部１０７０は、ユーザ端末４０に停止された口座照会要求情報の修正指示情報を送信する機能を有してもよい。

（３−２．金融取引方法）
次に、不正口座照会監視制御部１００Ａにおける不正口座照会監視プログラムによる命令に基づいた金融取引方法について説明する。

図２０、図２２，図２５および図２６は、金融取引方法のフロー図である。金融取引方法は、第１金融取引制御方法Ｓ１１００、第２金融取引制御方法Ｓ１２００および第３金融取引制御方法Ｓ１３００を含む。第１金融取引制御方法Ｓ１１００は、金融機関間口座照会承諾情報の生成、受信および格納処理、並びに口座照会承諾情報の生成および格納処理を含む。第２金融取引制御方法Ｓ１２００は、口座照会要求情報の取得、判定、口座照会指示処理を含む。第３金融取引制御方法Ｓ１３００は、口座照会処理、および口座照会判定を含む。以下に詳細に説明する。

第１金融取引制御方法Ｓ１１００において、まず自行サーバ１０Ａは、図２０に示すように、金融機関間口座照会承諾要求情報を生成する（Ｓ１１０１）。金融機関間口座照会承諾要求情報は、端末から入力された情報に基づいて生成されてもよい。自行サーバ１０Ａは、生成された金融機関間口座照会承諾要求情報をリクエスト電文として他行サーバ３０に対して送信する（Ｓ１１０３）。

他行サーバ３０は、金融機関間口座照会承諾要求情報を受信すると（Ｓ１１０５）、金融機関間口座照会承諾情報を生成する（Ｓ１１０７）。金融機関間口座照会承諾情報は口座照会可能な金融機関コードを含む。他行サーバ３０は、生成された金融機関間口座照会承諾情報をリクエスト電文として自行サーバ１０Ａに送信する（Ｓ１１０９）。

自行サーバ１０Ａの識別情報取得部１０２０は、金融機関間口座照会承諾情報を受信したのち、口座照会情報ＤＢ１２Ａａに格納する（Ｓ１１１１）。上記のＳ１１０１からＳ１１１１までの処理は、各金融機関からの口座照会の要求に合わせて繰り返し実行されてもよい。これにより、図１８に示した金融機関情報６１０のデータ構造が生成される。

一方で、ユーザ端末４０が口座照会承諾要求情報を生成する（Ｓ１１１３）。口座照会承諾要求情報の生成は、ユーザ端末４０の表示部４１に表示された自行のインターネットバンキングのユーザインターフェースにおいて行われる。図２１は、口座照会承諾要求情報生成用のユーザインターフェース６４０の一例である。図２１に示すように、口座照会承諾要求ユーザインターフェース６４０は、ユーザ名６４０ａ、法人種別６４０ｂ、関連法人有無６４０ｃ、および関連法人数６４０ｄを含む。法人種別６４０ｂは、ユーザの業種を示し、表示されたリストから選択することができる。関連法人有無６４０ｃおよび関連法人数６４０ｄは、ユーザに関連する法人の有無、およびグループ企業の数を記載することができる。口座情報の入力が完了したときは入力完了ボタン６４２を押下し、閉じるボタン６４４を押下する。これにより、ユーザ端末４０の送信部４２０から自行サーバ１０Ａに対して口座照会承諾要求情報がリクエスト電文として送信される（Ｓ１１１５）。

自行サーバ１０Ａは、口座照会承諾要求情報を受信すると（Ｓ１１１７）、口座照会承諾要求情報に基づいて口座照会承諾情報および承諾ユーザ情報を生成し、口座照会情報ＤＢ１２Ａａに格納する（Ｓ１１１９）。自行サーバ１０Ａは、生成された口座照会承諾情報をユーザ端末４０に送信する（Ｓ１１２１）。

ユーザ端末４０は、口座照会承諾情報を受信する（Ｓ１１２３）。上記Ｓ１１１３〜Ｓ１１２３の処理は、複数のユーザから口座照会の要求があるたびに繰り返し実行される。これにより、図１９に示した複数の承諾ユーザの情報を含むデータ構造が生成される。なお、図１９に示す承諾されたユーザの信頼度は、口座照会承諾情報とは異なるタイミングで生成されてもよい。また、口座照会承諾要求情報の生成と、金融機関間口座照会承諾要求情報の生成の順番は異なってもよい。以上により、第１金融取引制御方法Ｓ１１００が終了となる。第１金融取引制御方法により、口座照会可能な金融機関情報、および口座照会が承諾されたユーザの承諾ユーザ情報を記憶部１２Ａ（記憶装置）にあらかじめ格納することができる。

なお、上述において金融機関間口座照会承諾情報が生成されたのちに口座照会承諾情報が生成される例を示したが、これに限定されない。金融機関間口座照会承諾情報および口座照会承諾情報は、それぞれ並列で生成されてもよい。また、口座照会可能な照会目的情報を含む各種情報はあらかじめ口座照会情報ＤＢ１２Ａａに格納されてもよいし、ユーザ端末４０から送信された要求情報を含む電文に基づいて生成されてもよい。

次に、第２金融取引制御方法Ｓ１２００について説明する。第２金融取引制御方法Ｓ１２００は、第１金融取引制御方法Ｓ１１００の終了をきっかけに開始する。なお、第１金融取引制御方法Ｓ１１００と第２金融取引制御方法Ｓ１２００とが順番に行われなくてもよく、適宜並列に処理されてもよい。

まず、図２２に示すように、ユーザ端末４０は、口座照会要求情報を生成する（Ｓ１２０１）。図２３は、口座照会要求情報を生成するためにユーザが入力するための口座照会要求ユーザインターフェース６５０の一例である。図２３に示すように、ユーザは、口座照会要求ユーザインターフェース６５０に対して、ユーザ名６５１ａ、ユーザコード６５１ｂ、目的コード６５１ｃ、金融機関名６５１ｄ、金融機関コード６５１ｅ、支店名６５１ｆ、預金種別６５１ｇ、口座番号６５１ｈ、および口座名義人６５１ｉを入力する。複数の口座照会を要求する場合には、追加ボタン６５３を押すことにより、次の口座振込情報を入力することができる。口座振込情報の入力がすべて完了した場合には、入力完了ボタン６５５を押すことにより、各口座照会要求情報に対して依頼番号が設定される。また、連続して口座照会要求情報を入力した場合には、口座照会要求情報データセットとして依頼ファイル番号が設定される。ユーザ端末４０は、生成された口座照会要求情報をリクエスト電文として自行サーバ１０Ａに送信する（Ｓ１２０３）。

自行サーバ１０Ａは、口座照会要求情報を受信（取得）すると、口座照会情報ＤＢ１２Ａａに口座照会要求情報を格納する（Ｓ１２０５）。なお、照会対象となる口座情報が複数の場合には、データファイルをあらかじめユーザ端末内４０で生成・格納し、ユーザ端末４０はそのデータファイルをネットワーク経由で自行サーバ１０Ａにアップロードしてもよい。自行サーバ１０Ａが口座照会要求情報を受信すると、当該口座照会要求情報は、口座照会情報データベース１２Ａａに格納される。

次に、自行サーバ１０Ａの口座照会判定部１０３０は、受信した口座照会要求情報が所定の照会可能条件を満たす（適合する）ものであるか判定する（Ｓ１２０７）。このとき、受信した口座照会要求情報のうちの少なくとも一部と口座照会情報ＤＢ１２Ａａに格納された情報のうちの少なくとも一部とが一致する場合に口座照会情報が所定の照会可能条件を満たすと判定される。具体的には、図１６に示す口座照会要求情報６００に含まれる目的コード６０２ｂと、口座照会情報ＤＢ１２Ａａに格納された口座照会可能な目的コードが一致するかどうかを判定する。このとき、口座照会要求情報６００内に目的コード６０２ｂがあるかどうかを判定してもよい。同様に、口座照会情報ＤＢ１２Ａａに口座照会可能な目的コードが格納（登録）されているかどうかを判定してもよい。口座照会要求情報６００内に目的コード６０２ｂがない場合、または口座照会情報ＤＢ１２Ａａに目的コードが登録されていない場合には、口座照会判定部１０３０は不正照会要求であると判定してもよい。

または、口座照会判定部１０３０は、図１６に示す口座照会要求情報に含まれるユーザコード６０１ｂと図１９に示す口座照会情報ＤＢ１２Ａａに格納された口座照会が承諾されたユーザの承諾ユーザコード６２０ｂとを照合し、一致するかどうかを判定してもよい。また、口座照会判定部１０３０は、図１６に示す口座照会要求情報６００に含まれる金融機関コード６０２ｄと、図１８に示す口座照会情報ＤＢ１２Ａａに格納された口座照会可能な金融機関コード６１０ｂとを照合し、一致するかどうか判定してもよい。さらに、口座照会判定部１０３０は、図１６に示す口座照会要求情報６００に含まれる業種コード６０１ｃと、図１９に示す口座照会情報ＤＢ１２Ａａに格納された口座照会が承諾されたユーザの業種コード６２０ｃを照合し、一致するかどうか判定してもよい。

ここで、受信した口座照会要求情報のうち目的コード６０２ｂと口座照会情報ＤＢ１２Ａａに格納された情報のうち口座照会可能な目的コードが一致する場合には（Ｓ１２０９；Ｙｅｓ）、自行サーバ１０Ａは、口座照会要求情報に応じた口座照会指示情報を生成する（Ｓ１２１１）。つまり、本実施形態では、口座照会要求情報と、記憶装置に予め記憶された情報との関係が照会可能条件を満たすとき、口座照会要求情報に関連付けられた口座照会処理を指示するということができる。

本実施形態を用いることにより、口座照会要求情報の目的コードと口座照会情報ＤＢ１２Ａａの口座照会可能な目的コードが一致した場合、例えば目的コードが「１．公的用」の場合には、地方公共団体から業務を受けた法人の場合のように、口座照会要求情報の金融機関コードおよびユーザコードが口座照会情報ＤＢ１２Ａａに格納されたデータと一致しなくても口座照会を指示することができる。

また、口座照会判定部１０３０は、口座照会要求情報の業種コード６０１ｃ、目的コード６０２ｂおよび承諾ユーザ情報の業種コード６２０ｃに基づいて、口座照会を指示してもよい。例えば、業種コード６０１ｃまたは業種コード６２０ｃが「（０３）地方公共団体」であり、目的コードが「１．公的用」となっている場合には、図１６に示す口座照会要求情報に含まれる金融機関コード６０２ｄと、図１８に示す口座照会情報ＤＢ１２Ａａに格納された口座照会可能な金融機関コード６１０ｂとが一致していない場合においても口座照会を指示してもよい。これにより、従来であれば金融機関間の口座照会の契約・取決めが未完のために口座照会を指示できない場合であっても緊急時の例外処理として口座照会を指示することができる。

一方で、ユーザコード及び金融機関コードが適合しない場合には（Ｓ１２０９；Ｎｏ）、不正な口座照会要求と判定し、自行サーバ１０Ａの口座照会停止部１０６０は口座照会要求情報の一部または全部に対して口座照会停止処理を行ってもよい（Ｓ１２１３）。例えば、口座照会要求情報６００に目的コード６０２ｂが含まれていない場合には、口座照会停止部１０６０は、口座照会停止処理を実行してもよい。

図２４は、複数の口座照会要求情報の判定結果のデータ構造の一例である。図２４に示すように、複数の口座照会要求データ６０２の各々に対して口座照会可否データ６０２ｉが生成される。このとき、口座照会要求情報データセット全体のうち口座照会可能な口座照会要求情報の比率（口座照会可能率６０２ｊ）を算出してもよい。この例では、口座照会可能率は、「６０％」と表示される。

また、ユーザコードが一致する場合に、図１９に示す承諾ユーザ情報の関連法人数６２０ｄに対する口座照会要求情報の口座照会可能率６０２ｊが設定値に達したときに、口座照会停止部１０５０は、口座照会停止処理を実行してもよい。関連法人数が多くなると、グループ法人から要求された情報に基づいて口座照会要求情報が生成され、金融機関コードの不一致となる可能性が高まることが想定される。その場合、不正アクセスであると判断される可能性が高まるためである。

例えば、業種コードが保険会社（０２）であり、口座照会可能率が８０％以上であるとき、口座照会要求情報のうち該当するものに対して口座照会停止処理を行ってもよい。例えば、業種コードが保険会社（０２）であり、口座照会可能率が５０％であるとき、口座照会要求情報に含まれるすべての口座照会に対して停止処理を行ってもよい。さらに、業種コードが保険会社（０２）であり、口座照会可能率が４０％以下の場合は、口座照会を停止されたユーザの承諾ユーザ情報を記憶部１２Ａの口座照会情報ＤＢ１２Ａａから消去してもよい。

口座照会停止処理が実行された後、自行サーバ１０Ａは口座照会が停止となったことを、電文を介してユーザ端末４０に通知する（Ｓ１２１５）。ユーザ端末４０は、口座照会停止通知を受信したとき（Ｓ１２１７）、第２金融取引制御方法Ｓ１２００は終了となる。

なお、自行サーバ１０Ａは、ユーザ端末４０に口座照会停止通知とともに口座照会停止処理された口座照会要求情報についての修正指示情報を送信してもよい。これにより、ユーザは口座照会要求情報の誤りを迅速に修正することができる。

第３金融取引制御方法（Ｓ１３００）は、口座照会指示情報の生成（Ｓ１２１１）をきっかけに開始する。図２５に示すように、まず、自行サーバ１０Ａは、口座照会指示情報を統合ＡＴＭサーバ２０に送信する（Ｓ１３０１）。統合ＡＴＭサーバ２０は、口座照会指示情報を受信すると（Ｓ１３０３）、口座照会指示情報に対応する口座照会可能な金融機関（他行サーバ３０）に口座照会指示情報を送信する（Ｓ１３０５）。

他行サーバ３０は、口座照会指示情報を受信すると（Ｓ１３０７）、口座照会処理を実行する（Ｓ１３０９）。具体的には、口座情報に記載された各情報のうち他行サーバ３０に記録されている口座情報と完全に一致しているか否かによって、一致または不一致を判定する。この場合、一文字でも異なった場合には不一致として処理される。照会結果は、依頼番号に紐づけて入力される。照会結果が不一致の場合、不一致、ＮＧなどのように単純な入力でもよいし、口座番号相違（口座なし）、口座名義人相違、または預金種別相違など具体的に入力されてもよい。他行サーバは、口座照会が完了したのち、口座照会結果を統合ＡＴＭサーバ２０に送信する（Ｓ１３１１）。

統合ＡＴＭサーバ２０は、口座照会結果を受信すると（Ｓ１３１３）、自行サーバ１０Ａに対して口座照会結果を送信する（Ｓ１３１５）。

自行サーバ１０Ａは、口座照会結果を受信したとき（Ｓ１３１７）、図２６に示すように口座照会結果について判定を行ってもよい（Ｓ１３１９）。このとき、口座照会判定部１０３０は、口座照会不一致率と、目的コード、業種コードまたは関連法人数に基づいて不正口座照会であるかどうか判定を行う。具体的には、ユーザの業種コードが地方公共団体、目的コードが公的用の場合には、口座不一致率が５０％以上であっても、不正口座照会ではないと判定してもよい。または関連法人数が５以上で、口座不一致率が２０％以上である場合には、不正口座照会であると判定してもよい。

不正口座照会ではないと判定した場合（Ｓ１３２１；Ｎｏ）、自行サーバ１０Ａは口座照会結果をユーザ端末４０に送信する（Ｓ１３２３）。ユーザ端末４０は、口座照会結果を受信すると（Ｓ１３２５）、口座情報の修正が必要かどうかを判定する（Ｓ１３２７）。口座情報の修正の判定は、ユーザからの入力に基づいてなされてもよい。口座情報の修正が必要な場合には（Ｓ１３２７；Ｙｅｓ）、照会対象の口座情報入力に戻ってもよい（Ｓ１２０１）。口座情報の修正が不要の場合には（Ｓ１３２７；Ｎｏ）、第３金融取引制御方法Ｓ１３００は終了となる。第３金融取引制御方法Ｓ１３００の後で、口座振込処理を指示してもよい。

一方、不正な口座照会であると判定した場合（Ｓ１３２１；Ｙｅｓ）、当該ユーザによる今後の口座照会要求情報の生成を停止する（アカウントを停止する）（Ｓ１３２９）。

口座照会停止処理が完了すると、自行サーバ１０Ａの通知部１０５０は、ユーザ端末４０に対して、ユーザによる口座照会を停止したことを通知するための電文を送信する（Ｓ１３３１）。ユーザ端末４０は、口座照会停止の電文を受信した後（Ｓ１３３３）、ユーザによる口座照会要求ができない状態となる。以上により、第３金融取引制御方法Ｓ１３００が終了となる。

本実施形態を用いることにより、膨大な数の口座照会要求があった場合においても容易にかつ高い精度で不正の口座照会を判別することができる。また、口座照会処理を実行する前にモニタリングを行うことができるために、システム上の負担を軽減することができる。

なお、本実施形態では、業種コード、関連法人数、信頼度を含む例を示したが、必ずしも設ける必要はない。

また、本実施形態では、グループパラメータとして、業種コードを用いた例を示したが、ユーザを分類できるものであれば、特に限定されない。

また、本実施形態において、照合に用いられた各データから算出された一致率をもとに、判定結果を決定してもよい。例えば、口座照会要求情報に誤りが含まれている場合には、一致率から判定することができる。

また、本実施形態では、口座照会要求情報のうちの少なくとも一部と口座照会情報ＤＢ１２Ａａに格納された情報のうちの少なくとも一部とが一致する場合に口座照会情報が所定の照会可能条件を満たす場合に、口座照会指示情報を生成する例を示したが、これに限定されない。例えば、口座照会要求情報６００に含まれる目的コード６０２ｂと、業種コード６０１ｃとの組み合わせが所定の条件を満たすときに、優先照会用のフラグデータを生成してもよい。具体的には、業種コード６０１ｃが「（０３）地方公共団体」」または「（０６）官公庁」であり、目的コードが「１．公的用」である場合には、図２７に示すように、優先照会用のフラグデータ６０２ｋが生成されてもよい。口座照会情報ＤＢ１２Ａａには、優先照会用のフラグデータが生成された口座照会要求情報に対しては、口座照会を可能とする指示情報を格納してもよい。口座照会判定部１０３０は、優先照会用のフラグデータを含む口座照会要求情報について、口座照会情報ＤＢ１２Ａａに格納された指示情報をもとに、口座照会指示情報を生成することができる。したがって、口座照会可能な金融機関コード、または口座照会を承諾されたユーザコード等を取得していない場合においても、業種コード・目的コードを用いることで口座照会を迅速に処理することができる。

また、本実施形態では、業種コードに対する口座照会可能率が設定値に基づいて口座照会を停止する例を示したが、これに限定されない。例えば、関連法人数に対する口座照会可能率を設定してもよい。

（変形例）
本発明の思想の範疇において、当業者であれば、各種の変更例および修正例に想到し得るものであり、それら変更例および修正例についても本発明の範囲に属するものと了解される。例えば、前述の各実施形態に対して、当業者が適宜、構成要素の追加、削除若しくは設計変更を行ったもの、又は、処理の追加、省略若しくは条件変更を行ったものも、本発明の要旨を備えている限り、本発明の範囲に含まれる。

本発明の第１実施形態では、口座照会が他行サーバで行われる例を示したが、これに限定されない。例えば、口座照会は、統合ＡＴＭサーバ２０内で行われてもよい。また、不正口座判定は、自行サーバ１０に限定されず、統合ＡＴＭサーバで行われてもよいし、その他のサーバで行われてもよい。

本発明の第１実施形態では、口座情報に基づいて口座照会がなされ、不正口座照会であるかを判定する例を示したが、これに限定されない。例えば、口座情報を自行サーバ１０が取得した時点で、不正口座照会であるかを判定してもよい。

本発明の第１実施形態では、不正口座照会監視制御部１００が、通知部１３０を有する例を示したが、必ずしも設けなくてもよい。この場合、口座情報の入力がロックされてもよい。

本発明の第１実施形態では、不正口座照会監視制御部１００が、自行サーバ１０内に設けられる例を示したが、これに限定されない。例えば、不正口座照会監視制御部１００が、統合ＡＴＭサーバ２０内に設けられてもよい。

本発明の第１実施形態では、自行サーバ１０が口座情報を先に取得して、その後に照会結果を受信する例を示したが、これに限定されない。例えば、口座情報および当該口座情報を同時に口座照会履歴情報として取得してもよい。

本発明の第１実施形態では、通知部１３０は、ユーザ端末４０に口座照会停止通知を行う際に、電文として文字情報（例えばプッシュ通知）として送信することができる。なお、口座照会停止通知は、画像情報でもよいし、音声情報でもよい。

本発明の第１実施形態では、同一の依頼者から追加の口座照会要求がある場合について示したが、これに限定されない。例えば、同一の依頼者ではなくても複数の口座情報において関連あると判定された場合には、合わせて口座照会判定を行ってもよい。

本発明の第１実施形態では口座照会判定の直前に同一ユーザが所定の数（具体的には３個）の依頼ファイルを用いて口座照会をした場合に、過去の口座照会履歴情報を組み合わせて判定する例について説明したが、これに限定されない。例えば、同一ユーザが所定の期間内（具体的には１か月以内）に複数の依頼ファイルを用いて口座照会をしていた場合、所定期間内の同一ユーザによる口座照会履歴情報を組み合わせて判定してもよい。また、この場合、所定の期間が経過後、過去の口座照会履歴を削除してもよい。

また、不正の口座照会であるかを判定する際に、依頼者の信用度または振り込み実績に基づいて判定条件を変更してもよい。判定条件を変更する場合、ユーザ端末４０に問い合わせ情報（ヒアリング情報）を送信してもよい。

また、本発明の第３実施形態では、承諾ユーザ情報の業種コードと、口座照会要求情報の目的コードとの関係に基づいて、口座照会要求を指示する例を示したが、これに限定されない。口座照会判定部１０３０は、承諾ユーザ情報の関連法人数と、口座照会要求情報の口座照会可能率との関係に基づいて、口座照会要求を指示してもよい。例えば、関連法人数が低く（例えば「１」）、口座照会可能率が高い（例えば８０％）場合には、口座照会を指示してもよい。

また、本発明の第３実施形態では、自行サーバ１０Ａが各種処理を行う例を示したが、これに限定されない。他のサーバ、コンピュータ、または情報処理装置が各種処理を行ってもよい。

１・・・金融取引システム，１０・・・自行サーバ，１１・・・制御部，１２・・・記憶部，１２ａ・・・口座照会履歴情報データベース，１３・・・通信部，１４・・・表示部，２０・・・サーバ，２１・・・制御部，２２・・・記憶部，２３・・・通信部，３０・・・他行サーバ，３１・・・制御部，３２・・・記憶部，３３・・・通信部，３４・・・表示部，４０・・・ユーザ端末，４１・・・表示部，４２・・・制御部，４３・・・記憶部，４４・・・操作部，４５・・・通信部，５０・・・ネットワーク，１００・・・不正口座照会監視制御部，１１０・・・口座照会履歴情報取得部，１１１・・・口座照会履歴情報，１１２ａ・・・依頼者，１１２ｂ・・・依頼者識別番号，１１２ｃ・・・依頼ファイル，１１３・・・口座情報，１１３ａ・・・依頼番号，１１３ｂ・・・目的コード，１１３ｃ・・・金融機関名，１１３ｄ・・・支店名，１１３ｅ・・・預金種別，１１３ｇ・・・口座名義人，１１５・・・照会結果，１１７・・・追加ボタン，１１９・・・入力完了ボタン，１２０・・・口座照会判定部，１３０・・・通知部，２１０・・・受信部，２２０・・・送信部，３１０・・・受信部，３１２ａ・・・依頼者，３１２ｂ・・・依頼者識別番号，３１３ｂ・・・目的コード，３１３ｃ・・・金融機関名，３１３ｄ・・・支店名，３１３ｅ・・・預金種別，３１３ｆ・・・口座番号，３１３ｇ・・・口座名義人，３１３ｈ・・・振込日，３１７・・・追加ボタン，３１９・・・入力完了ボタン，３２０・・・口座照会処理部，３３０・・・振込処理部，３４０・・・送信部，４１０・・・受信部，４２０・・・送信部，６００・・・口座照会要求情報，６０１・・・ユーザ情報，６０２・・・口座照会要求データ，６１０・・・金融機関情報，６２０・・・承諾ユーザ情報，６４０・・・口座照会承諾要求ユーザインターフェース，６５０・・・口座照会要求ユーザインターフェース，１０１０・・・口座照会要求情報取得部，１０２０・・・識別情報取得部，１０３０・・・口座照会判定部，１０４０・・・口座照会指示部，１０５０・・・口座照会停止部，１０６０・・・通知部，１０７０・・・送信部

Claims (20)

1. 第１金融機関サーバが、
   第２金融機関サーバから送信された複数の口座情報の各々に対応する照会結果を含む口座照会履歴情報のうち不一致の照会結果に基づいて不正の口座照会であるかを判定する、金融取引方法。
2. 前記複数の口座情報は、ユーザの端末から前記第１金融機関サーバに送信され、前記ユーザの識別子に関連付けされる、
   請求項１に記載の金融取引方法。
3. 前記複数の口座情報が所定の数以上であるときに、不正の口座照会であると判定する、
   請求項１または２に記載の金融取引方法。
4. 前記複数の口座情報が、所定の数以上の連続する口座番号を含むときに、不正の口座照会であると判定する、
   請求項１または２に記載の金融取引方法。
5. 前記複数の口座情報において、第１の数以上の連続する口座番号が順番に並んでいるときに、不正の口座照会であると判定する、
   請求項４に記載の金融取引方法。
6. 前記複数の口座情報を含む口座情報データセットが第２の数以上であって、
   前記第２の数以上の口座情報データセットの各々において前記第１の数未満の連続する口座番号が順番に並んでいるときに、不正の口座照会であると判定する、
   請求項５に記載の金融取引方法。
7. 前記複数の口座情報と前記第１金融機関サーバに格納された実際の口座情報とを照会し、第１の数以上の前記照会結果が不一致であるときに、不正の口座照会であると判定する、
   請求項１または２に記載の金融取引方法。
8. 前記複数の口座情報を含む口座情報データセットが第２の数以上であって、
   前記第２の数以上の口座情報データセットの各々において前記複数の口座情報と前記第１金融機関サーバに格納された実際の口座情報とを照会し、前記第１の数未満の前記照会結果が不一致であるときに、不正の口座照会であると判定する、
   請求項７に記載の金融取引方法。
9. 前記口座情報は、口座番号、および前記口座番号に対応付けられた振込予定日を含み、
   前記照会結果に基づいて前記口座番号を用いて振込処理を行う振込日が、前記口座番号に対応付けられた前記振込予定日と所定の日数以上異なるとき、不正の口座照会であると判定する、
   請求項１に記載の金融取引方法。
10. 前記不正の口座照会であると判定したときに、所定の情報をユーザの端末に通知する、
    請求項１乃至９のいずれか一項に記載の金融取引方法。
11. 第１金融機関サーバが、
    第２金融機関サーバから送信された複数の口座情報の各々に対応する照会結果を含む口座照会履歴情報を取得する口座照会履歴情報取得部と、
    前記取得された口座照会履歴情報のうち不一致の照会結果に基づいて不正の口座照会であるかを判定する口座照会判定部と、を含む、
    金融取引システム。
12. 前記複数の口座情報は、ユーザの端末から前記第１金融機関サーバに送信され、前記ユーザの識別子に関連付けされる、
    請求項１１に記載の金融取引システム。
13. 前記口座照会判定部は、前記複数の口座情報が所定の数以上であるときに、不正の口座照会であると判定する、
    請求項１１または１２に記載の金融取引システム。
14. 前記口座照会判定部は、前記複数の口座情報が所定の数以上の連続する口座番号を含むときに、不正の口座照会であると判定する、
    請求項１１または１２に記載の金融取引システム。
15. 前記口座照会判定部は、前記複数の口座情報において、第１の数以上の連続する口座番号が順番に並んでいるときに、不正の口座照会であると判定する、
    請求項１４に記載の金融取引システム。
16. 前記複数の口座情報を含む口座情報データセットが第２の数以上であって、
    前記口座照会判定部は、前記第２の数以上の口座情報データセットの各々において前記第１の数未満の連続する口座番号が順番に並んでいるときに、不正の口座照会であると判定する、
    請求項１３に記載の金融取引システム。
17. 前記口座照会判定部は、前記複数の口座情報と前記第１金融機関サーバに格納された実際の口座情報とを照会し、第１の数以上の前記照会結果が不一致であるときに、不正の口座照会であると判定する、
    請求項１１または１２に記載の金融取引システム。
18. 前記複数の口座情報を含む口座情報データセットが第２の数以上であって、
    前記口座照会判定部は、前記第２の数以上の口座情報データセットの各々において前記複数の口座情報と前記第１金融機関サーバに格納された実際の口座情報とを照会し、前記第１の数未満の前記照会結果が不一致であるときに、不正の口座照会であると判定する、
    請求項１７に記載の金融取引システム。
19. 前記口座情報は、口座番号、および前記口座番号に対応付けられた振込予定日を含み、
    前記口座照会判定部は、前記照会結果に基づいて前記口座番号を用いて振込処理を行う振込日が、前記口座番号に対応付けられた前記振込予定日と所定の日数以上異なるとき、不正の口座照会であると判定する、
    請求項１１または１２に記載の金融取引システム。
20. 前記口座照会判定部が前記不正の口座照会であると判定したときに、所定の情報をユーザの端末に通知する通知部を含む、
    請求項１１乃至１９のいずれか一項に記載の金融取引システム。

Images