JP6559398B2 - 承認依頼方法、承認依頼プログラム及び銀行システム - Google Patents

Description

本発明は、承認依頼方法、承認依頼プログラム及び銀行システムに関する。

家族や知人の関係者を装って金銭の振込や手渡しを要求する、いわゆる振込詐欺が社会問題の一つとして挙げられる。かかる振り込め詐欺では、その金銭授受の方法は振り込みに限られず、指定場所へ現金を持参または郵送させたり、バイク便事業者等の代理人に現金を受け取らせたりなどのように多様化が進んでおり、「母さん助けて詐欺」等と他の呼び方がなされることもある。

振り込め詐欺を抑制する技術の一例として、次のような振り込み方法が提案されている。この振り込み方法では、口座所有者が自口座から金銭の振り込みをする際、第三者へメール等で振込の承認要求を通知し、第三者の承認を得られることを条件に、振込処理を完了させる。

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

しかしながら、上記の技術では、次のような理由から、第三者への承認依頼を適切に実施できない。

すなわち、上記の振り込み方法では、現金の振り込みが行われる度に第三者へ振り込みの承認が依頼される結果、第三者による承認作業に多大な負荷が生じる。例えば、現金自動預け払い機、いわゆるＡＴＭ（Automatic Teller Machine）やインターネットバンキングの場合、２４時間営業年中無休で利用できるので、第三者への承認依頼もそれに準じて実行されてしまう。そうであるからと言って、第三者の承認なしに振り込みを認めたのでは、振り込め詐欺の被害が無制限に拡大するおそれがある。例えば、金融機関の窓口で振り込みを行う場合、口座に預け入れられた金額の範囲内で取引を自由に行うことができるので、振り込め詐欺の被害に歯止めがきかなくなってしまう。

１つの側面では、本発明は、第三者への承認依頼を適切に実施できる承認依頼方法、承認依頼プログラム及び銀行システムを提供することを目的とする。

一態様の承認依頼方法は、現金自動預け払い機、窓口業務端末のいずれからも出金又は振込処理の依頼を受け可能な銀行システムに適用される方法である。コンピュータが、前記現金自動預け払い機と窓口業務端末のうち、出金又は振込処理の実行に先立って承認依頼先への承認依頼を送信するように設定された出金又は振込処理の依頼元種別に合致する依頼元から出金又は振込処理の依頼を受けると、前記承認依頼先へ承認依頼を送信する処理を実行する。

第三者への承認依頼を適切に実施できる。

図１は、実施例１に係る銀行システムの構成を示す図である。 図２は、実施例１に係る連携サーバの機能的構成を示すブロック図である。 図３は、対応関係情報の一例を示す図である。 図４は、承認者の属性情報の一例を示す図である。 図５は、承認依頼画面の一例を示す図である。 図６は、承認完了通知画面の一例を示す図である。 図７は、実施例１に係るフロントチャネル、連携サーバ及び承認者端末の間の制御シーケンスの一例を示す図である。 図８は、応用例を示す図である。 図９は、応用例を示す図である。 図１０は、実施例１及び実施例２に係る承認依頼プログラムを実行するコンピュータの一例について説明するための図である。

以下に添付図面を参照して本願に係る承認依頼方法、承認依頼プログラム及び銀行システムについて説明する。なお、この実施例は開示の技術を限定するものではない。そして、各実施例は、処理内容を矛盾させない範囲で適宜組み合わせることが可能である。

［システム構成］
図１は、実施例１に係る銀行システムの構成を示す図である。図１に示す銀行システム１は、銀行に口座を開設する利用者に対し、金銭に関する各種の取引、例えば残高照会、入金、出金、振込や振替などに関するサービスを提供するものである。なお、ここでは、銀行に適用されるシステムを例示するが、信用金庫、信用組合や労働金庫などの金融機関全般に適用できる。

図１に示すように、銀行システム１には、連携サーバ１０と、利用者端末２１と、ＡＴＭ２２と、窓口端末２３と、ＩＢサーバ３１と、ＡＴＭサーバ３２と、営業店サーバ３３と、勘定系システム４０と、承認者端末５０Ａ〜５０Ｃとが収容される。上記の「ＡＴＭ」は、「Automatic Teller Machine」の略称であり、また、上記の「ＩＢ」は、「Internet Banking」の略称である。なお、以下では、承認者端末５０Ａ〜５０Ｃを区別なく総称する場合に「承認者端末５０」と記載する場合がある。

これら各装置のうち、ＡＴＭ２２及び窓口端末２３と、連携サーバ１０との間は、専用線やＶＰＮ（Virtual Private Network）などの閉域網を介して、互いが通信可能に接続される。また、ＩＢサーバ３１、ＡＴＭサーバ３２及び営業店サーバ３３と、連携サーバ１０との間においても、専用線やＶＰＮなどの閉域網を介して、互いが通信可能に接続される。さらに、ＩＢサーバ３１、ＡＴＭサーバ３２及び営業店サーバ３３と、勘定系システム４０との間においても、専用線やＶＰＮなどの閉域網を介して、互いが通信可能に接続される。

一方、承認者端末５０Ａ〜５０Ｃと連携サーバ１０との間は、所定のネットワーク５を介して、互いが通信可能に接続される。かかるネットワーク５には、有線または無線を問わず、インターネット（Internet）、ＬＡＮ（Local Area Network）やＶＰＮなどの任意の種類の通信網を採用できる。なお、利用者端末２１と連携サーバ１０との間も、インターネット、ＬＡＮやＶＰＮなどの任意の種類の通信網を介して、互いが通信可能に接続される。

利用者端末２１は、銀行に口座を開設する利用者が使用する端末装置である。かかる利用者端末２１の一例としては、パーソナルコンピュータを採用できる。このような固定端末の他、スマートフォンを始め、携帯電話機、ＰＨＳ（Personal Handyphone System）やＰＤＡ（Personal Digital Assistants）などの移動体通信端末、さらには、スレート端末やタブレット端末などを採用することもできる。

一実施形態として、利用者は、利用者端末２１上で動作するブラウザ等を通じて、インターネットバンキングに関するサービスの提供を受けることができる。例えば、利用者端末２１は、銀行がインターネット上に公開するログイン用のＵＲＬ（Uniform Resource Locator）にアクセスする。その上で、利用者端末２１は、図示しないユーザインタフェースを介して入力を受け付けたアカウント情報、例えばＩＤ（IDentifier）やパスワードなどをＩＢサーバ３１へ送信する。このアカウント情報を用いて、ＩＢサーバ３１によってログイン認証が本人認証として実行される。この結果、ログイン認証が成功した場合には、インターネットバンキングに関するサービスが利用者端末２１に開放される。かかるサービスの開放後、利用者端末２１は、各種のメニュー、例えば残高照会、振込や振替などの取引を連携サーバ１０及びＩＢサーバ３１を介して勘定系システム４０へ依頼することができる。

ＡＴＭ２２は、預金通帳またはキャッシュカードを用いて、入金、出金、振込や残高照会などの取引を実行する装置である。このＡＴＭ２２は、現金自動預け払い機とも呼ばれる。

一実施形態として、ＡＴＭ２２は、図示しないタッチパネル上に表示されたメニュー画面を介して取引の依頼を受け付ける前後に、ＡＴＭ２２に入力された暗証番号や生体情報を用いて、本人認証を実行する。

例えば、キャッシュカードを利用する場合、ＡＴＭ２２は、図示しない挿入口から挿入されたキャッシュカードに記録された口座情報、例えば金融機関コード、支店番号及び口座番号等を読み取る。その上で、ＡＴＭ２２は、上記のタッチパネルを介して入力された認証情報、例えば暗証番号等とともに、キャッシュカードから読み取られた口座情報をＡＴＭサーバ３２へ送信する。これを受けたＡＴＭサーバ３２によって、口座情報を検索キーとしてマスタ登録されている利用者の暗証番号が照会された上で両者の暗証番号が一致するか否かが照合される。暗証番号の照会は、ＡＴＭサーバ３２以外で行われても構わない。例えば、勘定系システム４０によって行われても構わない。このとき、暗証番号が一致する場合には、ＡＴＭ２２の使用者が口座の利用者本人であると認証できる。この場合には、ＡＴＭ２２は、本人認証の前に入力された取引の依頼を連携サーバ１０及びＡＴＭサーバ３２を介して勘定系システム４０へ依頼したり、本人認証の成功後にメニュー画面を介して入力された取引の依頼を勘定系システム４０へ通知したりする。なお、上記のＡＴＭ２２には、現金処理機が搭載されており、入金時には貨幣挿入口から挿入された貨幣を計数の上で所定の収納部へ収納したり、出金時には収納部に収納された貨幣を計数の上で貨幣取出口へ繰り出したりする能力を有する。

なお、ここでは、キャッシュカードが利用される場合を例示したが、暗証番号の代わりに指紋、虹彩や手のひら静脈などの生体情報を本人認証に用いることもできる。この場合、生体情報と併せて生年月日を入力させることによって、ＡＴＭ２２で入力された生体情報との間で１対Ｎ認証を実行する対象を生年月日を用いて絞り込ませることができる。これによって、ＡＴＭ２２の利用時に必ずしも口座情報を入力させずともよくなる。

窓口端末２３は、窓口の係員、いわゆるテラーによって使用される端末装置である。一実施形態として、窓口端末２３は、顧客によって記入された伝票にしたがって取引の種別や取引の金額などの入力を受け付けたり、当該取引に関するオンライン処理を連携サーバ１０及び営業店サーバ３３を介して勘定系システム４０へ依頼する。この窓口端末２３には、図示しないテラー用の現金処理機が接続されており、現金処理機の収納部に収納される貨幣の金額または金種別の枚数を記憶管理しつつ、窓口端末２３から受け付けた入金または出金の金額にしたがって貨幣を入出金することもできる。

このように、図１に示す銀行システム１には、ＩＢ、ＡＴＭ及び窓口に関する各サービスを実現する３つのチャネル系システムが収容される。これらのチャネル系システムでは、利用者端末２１、ＡＴＭ２２及び窓口端末２３をフロントチャネルとし、３種類の各チャネルから取引の依頼を受け付けることができる。以下では、利用者端末２１、ＡＴＭ２２及び窓口端末２３を区別なく総称する場合に「フロントチャネル２０」と記載する場合がある。

ＩＢサーバ３１は、インターネットバンキングに関するサービスを利用者端末２１に提供するサーバ装置である。また、ＡＴＭサーバ３２は、ＡＴＭサービスをＡＴＭ２２を介して提供するサーバ装置である。営業店サーバ３３は、営業店におけるテラーサービスを窓口端末２３を介して提供するサーバ装置である。これらチャネル系システムに含まれる各サーバ装置は、連携サーバ１０から取引の処理依頼を受け付けた場合に、当該取引に関する処理依頼の電文を勘定系サーバ４０へ回送する。

勘定系システム４０は、各種の取引に関する処理を実行する情報システムである。例えば、勘定系システム４０は、ＩＢサーバ３１、ＡＴＭサーバ３２または営業店サーバ３３から取引に関する処理依頼を受け付けた場合に、預金または貯金に関する総勘定元帳のマスタのうちフロントチャネル２０で受け付けた利用者の口座情報に対応する口座に対し、当該取引に対応する処理、例えば入金、出金、振込、振替や残高照会等を実行する。

連携サーバ１０は、勘定系システム４０に各チャネル系システムに含まれる各サーバ装置を連携させる連携サービスを提供するサーバ装置である。一つの実装例として、連携サーバ１０は、上記の連携サービスを実現するＷｅｂサーバとして実装することとしてもよいし、また、連携サービスをアウトソーシングにより提供するクラウドとして実装することもできる。他の実装例としては、ＳＯＡ（Service Oriented Architecture）、パッケージソフトウェアやオンラインソフトウェアとして提供される連携プログラムを所望のコンピュータにプリインストール又はインストールさせることによっても実装できる。これらのうちいずれの形態で実装される場合においても、必ずしも勘定系システム４０の外部装置として実装されずともよく、勘定系システム４０に連携サービスを提供させることとしてもかまわない。

一実施形態として、連携サーバ１０は、チャネル系システムに含まれるフロントチャネル２０から取引に関する依頼を受け付けたからと言って直ちに当該取引に関する処理依頼を勘定系システム４０に回送するとは限らない。つまり、連携サーバ１０は、取引に関する依頼が振り込め詐欺に用いられるおそれのある種類、例えば出金や振込などに該当する場合、次のような承認プロセスを実行する。

すなわち、連携サーバ１０は、当該取引を依頼する利用者とは異なる第三者が使用する承認者端末５０に当該取引の承認を依頼する。ここで言う「第三者」とは、口座の利用者本人と関係があり善意の人物であることが確認されている人物を指し、例えば、利用者の家族、利用者の後見人などが挙げられる。この結果、連携サーバ１０は、承認者端末５０によって応答された承認結果が「承認」である場合に絞って当該取引に関する処理依頼の電文を勘定系システム４０へ回送する。これによって、例えば、振込や出金の金額、振込先などから第三者が疑義を持つ取引の実行を抑止できる結果、振り込め詐欺等の犯罪を抑制できる。

このとき、連携サーバ１０は、承認依頼を送信するあて先を１つまたは複数登録させておくことができる。さらに、連携サーバ１０は、承認依頼を送信するあて先として複数のあて先が登録されている場合、当該取引に関する処理依頼の電文を勘定系システム４０へ回送する条件として、任意の条件を設定することができる。例えば、連携サーバ１０は、複数の承認者のうち１人でも承認が得られた場合に取引の処理依頼を回送することとしてもよいし、承認者の全員から承認が得られた場合に始めて取引の処理依頼を回送することとしてもよい。また、連携サーバ１０は、全体に占める承認の割合が所定の閾値、例えば５０％以上である場合に、取引の処理依頼を回送することとしてもかまわない。なお、本実施例では、一例として、複数の承認者のうち１人でも承認が得られた場合に取引の処理依頼が回送される場合を想定して以下の説明を行う。

ここで、本実施例に係る連携サーバ１０は、フロントチャネル２０から取引に関する処理の依頼を受け付けた場合に、必ずしも上記の承認プロセスを無条件に実行する訳ではない。すなわち、本実施例に係る連携サーバ１０は、ＩＢ、ＡＴＭ及び窓口の３つのチャネルのうち特定のチャネルから出金又は振込の依頼を受けると承認者端末５０へ承認依頼を送信する。

このとき、連携サーバ１０は、承認者端末５０に承認依頼を送信する基準の一例として、各チャネルに設定された取引の限度額を用いることができる。すなわち、各チャネル系システムの間では、利用者と金融機関の間に介在するチャネルが異なり、利用者の本人確認を行う認証手段も違えば、取引の依頼を受け付ける間口が有人または無人であるのかも異なる。このことから、各チャネルには、異なる限度額が設定されるのが一般的である。

具体的には、「窓口」では、銀行の資金が安全性の高い営業店の金庫に収納されることから、他のチャネルに比べて高い取引の限度額が設定されることが多い。例えば、口座に預け入れられた金額の範囲内で取引を自由に行うことができる銀行もあれば、帯封の単位で取引を行うことができる銀行もある。一方、「ＡＴＭ」は、営業店の金庫に比べて多額の現金を収納することが安全や立地の面で困難であるから、窓口に比べて低い取引の限度額が設定されることが多い。例えば、２０万程度の出金や振込を認める銀行が多い。また、「ＩＢ」は、利用者端末２１がインタフェースとして機能することから振り込め詐欺の他にもフィッシング詐欺等のＷｅｂのセキュリティホールにもさらされるので、窓口に比べて低い取引の限度額が設定されることが多い。例えば、数十万、一例として５０万程度の出金や振込を認める銀行が多い。

このように、各チャネルの限度額は、現金の保安やＷｅｂのリスクなどを基準に設定されることが多いが、かかる基準は、振り込め詐欺を抑制するという観点から見た場合、必ずしも正しく機能するとは言えない場合がある。すなわち、振り込め詐欺によって利用者が明らかにだまされている場合でも、窓口の係員に取引を強制的に中止させることができない。このため、窓口で上記の承認プロセスを実行しない場合には、振り込め詐欺の被害に歯止めがきかなくなってしまうおそれが高い。

これらのことから、本実施例に係る連携サーバ１０は、一例として、出金又は振込の依頼を受け付けた依頼元の種別が「窓口」である場合、承認依頼を承認者端末５０へ送信する。これによって、振り込め詐欺の被害に歯止めをかけることができる。また、依頼元の種別が「ＡＴＭ」または「ＩＢ」である場合、上記の承認プロセスを経由せずに、勘定系システム４０に処理依頼を回送できる。このため、銀行の窓口の営業時間に準じて承認依頼が実行される結果、第三者による承認作業に多大な負荷を軽減できる。また、仮に振り込め詐欺の被害に遭ったとしても、限度額の設定が歯止めとなる結果、口座の残高の全てが被害に遭うという最悪の事態は抑制できる。したがって、本実施例に係る連携サーバ１０によれば、第三者への承認依頼を適切に実施できる。

なお、承認者端末５０には、上記の利用者端末２１と同様、パーソナルコンピュータの他、スマートフォンを始め、携帯電話機、ＰＨＳやＰＤＡなどの移動体通信端末、さらには、スレート端末やタブレット端末などを採用することもできる。

［連携サーバ１０の構成］
図２は、実施例１に係る連携サーバ１０の機能的構成を示すブロック図である。図２に示すように、連携サーバ１０は、通信Ｉ／Ｆ（InterFace）部１１と、対応関係記憶部１２と、承認者属性情報記憶部１３と、受付部１４と、承認送信部１５と、処理依頼部１６と、応答部１７とを有する。なお、連携サーバ１０は、図２に示した機能部以外にも既知のコンピュータが有する各種の機能部、例えば各種の入出力デバイス、音声出力デバイスや撮像デバイスなどの機能部を有することとしてもかまわない。

このうち、通信Ｉ／Ｆ部１１は、他の装置、例えば各チャネル系システムに含まれるフロントチャネル２０や各サーバ装置との間で通信制御を行うインタフェースである。かかる通信Ｉ／Ｆ部１１の一態様としては、ＬＡＮカードなどのネットワークインタフェースカードを採用できる。例えば、通信Ｉ／Ｆ部１１は、フロントチャネル２０から取引に関する処理の依頼を受け付けたり、あるいは取引に関する処理結果をフロントチャネル２０へ応答したりする。また、通信Ｉ／Ｆ部１１は、出金又は振込に関する承認依頼を承認者端末５０へ送信したり、あるいは承認者端末５０から承認結果を受け付けたりする。

対応関係記憶部１２は、利用者および承認者の対応関係に関する情報を記憶する記憶部である。かかる対応関係情報の一例として、利用者の口座番号および承認者の承認者ＩＤなどの対応関係が規定されたデータを採用できる。ここでは、口座番号および承認者ＩＤの対応関係を用いて利用者に紐付く承認者を特定する場合を例示するが、利用者および承認者を紐付けることができる項目であれば任意の項目を対応関係の規定に用いることができる。

図３は、対応関係情報の一例を示す図である。図３に示す１番目のレコードの例では、口座番号「123456789」の利用者が出金又は振込を行う場合、承認者ＩＤ「N201」、「N202」及び「N204」の承認者のうちいずれかの承認者から承認を得ることによって出金又は振込に関する処理が実行されることを意味する。この対応関係の意味合いは、図３に示す２番目及び３番目のレコードの例においても同様である。なお、図３には、１人の利用者に複数の承認者を対応付ける場合を例示したが、必ずしも承認者は複数人でなくともよく、利用者および承認者を一対一で対応付けることもできる。また、図３には、データがテーブル形式である場合を例示したが、他のデータ形式、例えばタグまたはカンマによって記述されるデータ形式であってもかまわない。

承認者属性情報記憶部１３は、承認者に関する属性情報を記憶する記憶部である。かかる属性情報には、一例として、承認者の氏名や連絡先を含めることができる。かかる承認者の属性情報の一例としては、承認者ＩＤ、氏名及び連絡先が対応付けられたデータを採用できる。ここで言う「連絡先」とは、承認者の承認者端末５０に対し、通知が可能なアドレスを指し、例えば、電子メールのアドレスの他、ＩＰアドレスやＭＡＣアドレスなどのネットワークアドレスを採用することもできる。

図４は、承認者の属性情報の一例を示す図である。図４に示す１番目のレコードの例では、承認者ＩＤ「N201」の承認者の氏名が「Ａさん」であり、Ａさんのメールアドレスが「AAA@**.ne.jp」であることを意味する。この対応関係の意味合いは、図４に示す２番目及び３番目のレコードの例においても同様である。なお、図４には、１人の承認者に１つの連絡先を対応付ける場合を例示したが、必ずしも１人の承認者に対応付ける連絡先は１つでなくともよく、複数の連絡先を対応付けることもできる。また、図４には、データがテーブル形式である場合を例示したが、他のデータ形式、例えばタグまたはカンマによって記述されるデータ形式であってもかまわない。

受付部１４は、取引に関する処理依頼を受け付ける処理部である。一実施形態として、受付部１４は、各チャネル系システムに含まれるフロントチャネル２０、例えば利用者端末２１、ＡＴＭ２２または窓口端末２３から各種の取引に関する処理依頼を受け付ける。なお、ここでは、出金又は振込以外の取引については既存の技術と同様にして処理を実行できるので、以下では受付部１４が受け付ける取引の種別が出金又は振込である場合を想定して以下の説明を行う。

承認送信部１５は、承認者端末５０への承認依頼の送信を制御する処理部である。一側面として、承認送信部１５は、ＡＴＭ２２と窓口端末２３のうち、出金又は振込処理の実行に先立って承認依頼先への承認依頼を送信するように設定された出金又は振込処理の依頼元種別に合致する依頼元から出金又は振込処理の依頼を受けると、承認依頼先へ承認依頼を送信する。

一実施形態として、承認送信部１５は、受付部１４が処理依頼を受け付けた取引が出金または振込である場合、当該出金又は当該振込の依頼を受け付けたフロントチャネル２０の種別が「窓口」であるか否かを判定する。このとき、承認送信部１５は、フロントチャネルの種別が「窓口」である場合、当該出金又は当該振込の依頼を行う利用者に承認者が設定されているか否かをさらに判定する。例えば、承認送信部１５は、当該出金又は当該振込の依頼を行う利用者の口座情報、すなわち口座番号を持つエントリが対応関係記憶部１２に存在するか否かを判定する。そして、承認送信部１５は、利用者の口座番号を持つエントリが存在する場合に、承認依頼を承認者端末５０へ送信する。例えば、承認送信部１５は、対応関係記憶部１２に記憶された承認者ＩＤのうち当該利用者の口座番号に対応付けられた承認者ＩＤを検索した上で当該承認者ＩＤに対応する連絡先を承認者属性情報記憶部１３から抽出する。そして、承認送信部１５は、先のようにして抽出された連絡先に対し、承認依頼を送信する。このとき、承認送信部１５は、承認依頼を通知する場合に、出金又は振込の依頼元に関する情報、例えば口座番号や名義人などを含めたり、取引に関する情報、例えば取引の種別、出金又は振込の金額、振込先の口座番号や受取名義人などを含めたりすることができる。

図５は、承認依頼画面の一例を示す図である。図５には、○×銀行から承認者へ送信された承認依頼画面が一例として示されている。図５に示す承認依頼画面２００によれば、承認者は、利用者「フジツウ タロウ」が振込先の名義人「フリコミ シロウ」へ金額「￥５００，０００」を振り込もうとしていることがわかる。この承認依頼画面２００上にある承認ボタン２１０を押下することによって振込を承認し、また、却下ボタン２２０を押下することによって振込を却下できる。このようにして承認ボタン２１０または却下ボタン２２０のいずれかのボタンが押下された場合には、承認者端末５０上で動作する犯罪被害抑制用のアプリケーションプログラムによって承認結果が連携サーバ１０へ通知される。なお、上記の承認依頼画面２００に記載がある通り、承認依頼の返信には、制限時間、例えば１時間が設定されており、承認依頼を受信してから制限時間内に承認ボタン２１０の押下がなされなかった場合には、連携サーバ１０によって却下とみなされる。また、上記の承認依頼画面２００には、承認依頼が送信される承認者の一覧をさらに含めることもできる。

図５に示す承認依頼画面２００に記載の振込先の名義人を見れば、承認者は、次のような判断を行うことができる。例えば、振込先の名義人が利用者の知人等である場合には、当該振込に承認の余地があることがわかる。また、利用者本人を知る承認者から見ても振込先の名義人に覚えがない場合には、利用者から事情を聴取する等の調査を行った上で認否を判断した方がよいと判断できる。また、行政庁や金融機関等がリストアップするブラックリスト等に登載されている場合には、振込の否認を始め、警察等への告発を行った方がよいと判断できる。さらに、図５に示す承認依頼画面２００に記載の振込の金額を見れば、承認者は、次のような判断を行うことができる。例えば、振込の金額が習慣的に行われているパターン、例えば家賃や光熱費等の金額から逸脱する金額である場合には、利用者から事情を聴取する等の調査を行った上で認否を判断した方がよいと判断できる。また、振込の金額が過度に高額である場合には、振込の否認を始め、警察等への告発を行った方がよいと判断できる。

処理依頼部１６は、取引に関する処理依頼を勘定系システム４０に回送する処理部である。

一実施形態として、処理依頼部１６は、フロントチャネル２０の種別が「窓口」以外である場合、すなわち「ＩＢ」または「ＡＴＭ」である場合、受付部１４が受け付けた出金又は振込の処理依頼の電文を勘定系システム４０に回送する。さらに、処理依頼部１６は、利用者の口座番号を持つエントリが存在しない場合にも、受付部１４が受け付けた出金又は振込の処理依頼の電文を勘定系システム４０に回送する。一方、処理依頼部１６は、承認送信部１５によって承認依頼が承認者端末５０に送信された場合には、承認者端末５０からの承認結果の返信を待機する。そして、処理依頼部１６は、制限時間内に１つの承認端末５０からでも承認結果として「承認」が返信された場合には、承認完了の通知を各承認者端末５０に送信するとともに、受付部１４が受け付けた出金又は振込の処理依頼の電文を勘定系システム４０に回送する。

図６は、承認完了通知画面の一例を示す図である。図６に示す承認完了通知画面によれば、承認者のうち承認者「Ａさん」が図５に示された承認依頼画面２００で通知された振込を承認したことがわかる。これによって、誰が振込の承認を行ったのかを各承認者の間で共有できる。例えば、未返信の承認者は、自分が承認結果を返信せずともよい旨を把握することができ、また、振込を却下した承認者は、振込を却下した承認者に対し、事情を問い合わせることができる。

なお、処理依頼部１６は、制限時間内に承認端末５０から１つも承認結果として「承認」が返信されなかった場合には、受付部１４が受け付けた出金又は振込の処理依頼の電文は勘定系システム４０に回送しない。このケースには、全ての承認者端末５０から承認結果として「却下」が返信されたケースや制限時間内に返信があった承認結果の中に「承認」がなかったケースが含まれる。

応答部１７は、受付部１４が受け付けた出金又は振込の依頼に関する処理結果をフロントチャネル２０に応答する処理部である。一実施形態として、応答部１７は、勘定系システム４０によって出金又は振込の処理が実行された場合には、出金又は振込の実行結果をフロントチャネル２０へ送信する。また、応答部１７は、勘定系システム４０によって出金又は振込の処理が実行されなかった場合には、当該出金又は当該振込の中止、さらには、中止になった原因、すなわち承認者による「却下」を通知する。

なお、上記の受付部１４、承認送信部１５、処理依頼部１６及び応答部１７は、ＣＰＵ（Central Processing Unit）やＭＰＵ（Micro Processing Unit）などに連携プログラムを実行させることによって実現できる。また、上記の各機能部は、ＡＳＩＣ（Application Specific Integrated Circuit）やＦＰＧＡ（Field Programmable Gate Array）などのハードワイヤードロジックによっても実現できる。

また、上記の対応関係記憶部１２及び承認者属性情報記憶部１３には、一例として、半導体メモリ素子を採用できる。例えば、半導体メモリ素子の一例としては、ＶＲＡＭ（Video Random Access Memory）、ＲＡＭ（Random Access Memory)、ＲＯＭ（Read Only Memory）やフラッシュメモリ（flash memory）などが挙げられる。また、内部メモリの代わりに、ハードディスク、光ディスクなどの記憶装置を採用することとしてもよい。

［処理の流れ］
図７は、実施例１に係るフロントチャネル２０、連携サーバ１０及び承認者端末５０の間の制御シーケンスの一例を示す図である。図７には、フロントチャネル２０で本人認証が実行されることを契機に処理が起動する場合を例示するが、メニュー画面等で取引が選択されたことを契機に処理が起動することとしてもかまわない。

図７に示すように、利用者の本人認証が成功すると（ステップＳ１０１）、フロントチャネル２０は、図示しないメニュー画面から取引の種別、例えば出金又は振込の選択を受け付け（ステップＳ１０２）、出金又は振込の処理依頼を連携サーバ１０へ送信する（ステップＳ１０３）。

一方、受付部１４がフロントチャネル２０から処理依頼を受け付けた取引が出金または振込である場合、承認送信部１５は、当該出金又は当該振込の依頼を受け付けたフロントチャネル２０の種別が「窓口」であるか否かを判定する（ステップＳ１０４）。

このとき、フロントチャネルの種別が「窓口」である場合（ステップＳ１０４Ｙｅｓ）には、承認送信部１５は、当該出金又は当該振込の依頼を行う利用者の口座情報、すなわち口座番号を持つエントリが対応関係記憶部１２に存在するか否かを判定する（ステップＳ１０５）。なお、上記の口座情報は、チャネルによって採取される方法は異なる。例えば、ＡＴＭや窓口の場合には、キャッシュカードや通帳から口座情報を読み取ることができ、また、ＩＢの場合には、ログイン時のアカウントに紐付けられた口座情報を呼び出すことができる。

そして、利用者の口座番号を持つエントリが存在する場合（ステップＳ１０５Ｙｅｓ）には、承認送信部１５は、承認依頼を承認者端末５０へ送信する（ステップＳ１０６）。その後、処理依頼部１６は、承認者端末５０からの承認結果の返信を待機する（ステップＳ１０７）。

一方、上記のステップＳ１０６で承認依頼が送信された承認者端末５０は、承認結果、例えば「承認」または「却下」などの入力を受け付け（ステップＳ１０８）、ステップＳ１０８で受け付けた承認結果を連携サーバ１０へ返信する（ステップＳ１０９）。

ここで、制限時間内に１つの承認端末５０からでも承認結果として「承認」が返信された場合（ステップＳ１１０Ｙｅｓ）には、処理依頼部１６は、次のような処理を実行する。すなわち、処理依頼部１６は、承認完了の通知を各承認者端末５０に送信するとともに、受付部１４が受け付けた出金又は振込の処理依頼の電文を勘定系システム４０に回送する（ステップＳ１１１及びステップＳ１１２）。なお、上記のステップＳ１１１の処理を受けて、承認者端末５０では、承認完了の通知が表示または音声などによって出力される（ステップＳ１１３）。なおここで、ステップＳ１１１では、全ての承認者端末５０に承認完了通知を送信するのではなく、制限時間以内に承認結果として「承認」を返信してこなかった承認者端末５０と承認が最先でなかった承認者端末５０とに対してのみ承認完了通知を送信してもよい。

一方、制限時間内に承認端末５０から１つも承認結果として「承認」が返信されなかった場合（ステップＳ１１０Ｎｏ）には、受付部１４が受け付けた出金又は振込の処理依頼の電文は勘定系システム４０に回送されない。この場合には、ステップＳ１１１〜ステップＳ１１３の処理をとばし、ステップＳ１１４の処理へ移行する。

また、フロントチャネル２０の種別が「窓口」以外である場合、あるいは利用者の口座番号を持つエントリが存在しない場合（ステップＳ１０４ＮｏまたはステップＳ１０５Ｎｏ）には、ステップＳ１０７〜ステップＳ１１１の処理、すなわち承認プロセスをとばし、受付部１４が受け付けた出金又は振込の処理依頼の電文が勘定系システム４０に回送される（ステップＳ１１２）。

その後、応答部１７は、受付部１４が受け付けた出金又は振込の依頼に関する処理結果、例えば出金又は振込の実行結果、あるいは出金又は振込の中止をフロントチャネル２０に応答する（ステップＳ１１４）。これを受けて、フロントチャネル２０では、ステップＳ１１４で送信された処理結果を表示または音声などによって出力する（ステップＳ１１５）。

［実施例１の効果］
上述してきたように、本実施例に係る連携サーバ１０は、ＩＢ、ＡＴＭ及び窓口の３つのチャネルのうち特定のチャネルから出金又は振込の依頼を受けると承認者端末５０へ承認依頼を送信する。例えば、出金又は振込の依頼を受け付けた依頼元の種別が「窓口」である場合、承認依頼を承認者端末５０へ送信する。これによって、振り込め詐欺の被害に歯止めをかけることができる。また、依頼元の種別が「ＡＴＭ」または「ＩＢ」である場合、上記の承認プロセスを経由せずに、勘定系システム４０に処理依頼を回送できる。このため、銀行の窓口の営業時間に準じて承認依頼が実行される結果、第三者による承認作業に多大な負荷を軽減できる。また、仮に振り込め詐欺の被害に遭ったとしても、限度額の設定が歯止めとなる結果、口座の残高の全てが被害に遭うという最悪の事態は抑制できる。したがって、本実施例に係る連携サーバ１０によれば、第三者への承認依頼を適切に実施できる。

さて、これまで開示の装置に関する実施例について説明したが、本発明は上述した実施例以外にも、種々の異なる形態にて実施されてよいものである。そこで、以下では、本発明に含まれる他の実施例を説明する。

［承認依頼の送信制御１］
例えば、連携サーバ１０は、依頼元種別と承認依頼の要否とが対応付けられた承認依頼テーブルを用いて、承認依頼先へ承認依頼を送信するかどうかを制御することもできる。図８は、応用例を示す図である。図８に示す承認依頼テーブルを用いる場合、依頼元種別が「ＩＢ」または「ＡＴＭ」である場合、すなわち利用者端末２１またはＡＴＭ２２から出金又は振込の処理依頼を受け付けた場合には、承認依頼は送信されない。一方、依頼元種別が「窓口」である場合、すなわち窓口端末２３から出金又は振込の処理依頼を受け付けた場合には、承認送信部１５は、処理依頼を承認者端末５０へ送信する。このように、承認送信部１５は、承認依頼テーブルを用いて、フロントチャネル２０の種別から承認依頼の要否を検索することによって承認依頼の送信制御を実行することもできる。

［承認依頼の送信制御２］
また、連携サーバ１０は、フロントチャネル２０の限度額によって承認依頼の送信制御を実行することもできる。例えば、承認送信部１５は、出金又は振込の処理依頼を通知するフロントチャネル２０の限度額が所定の閾値以上であるか否かを判定する。かかる閾値には、銀行システムの設計者、連携サービスのユーザである銀行関係者等が振り込め詐欺の被害で歯止めをかけたい金額を設定することができ、ここでは、一例として、承認依頼の送信を省略する閾値として予め１００万円が設定されていることとする。この場合には、「窓口」以外のチャネルの限度額は閾値未満と判定される一方で、「窓口」の限度額が閾値以上であると判定される。このように、限度額が閾値以上である窓口から出金又は振込の処理依頼が通知された場合に絞って承認依頼が承認者端末５０へ送信させることができる。

［承認依頼の送信制御３］
上記の承認依頼の送信制御２では、フロントチャネル２０の限度額によって承認依頼の送信制御を実行する場合を例示したが、各フロントチャネル２０ごとに出金又は振込に関する承認依頼の実行可否を判定する閾値を設定することもできる。図９は、応用例を示す図である。図９には、ＩＢの限度額が「数十万円」であり、窓口の限度額が「１００万円」であり、また、ＡＴＭの限度額が「２０万円」である場合が例示されている。図９に示すテーブルを用いた場合には、フロントチャネル２０の依頼元種別が「ＩＢ」である場合には、出金又は取引の金額が２０万円以上である場合に絞って承認依頼が承認者端末５０へ送信される。また、フロントチャネル２０の依頼元種別が「窓口」である場合には、出金又は取引の金額が５０万円以上である場合に絞って承認依頼が承認者端末５０へ送信される。さらに、フロントチャネル２０の依頼元種別が「ＡＴＭ」である場合には、出金又は取引の金額が１０万円以上である場合に絞って承認依頼が承認者端末５０へ送信される。このように、フロントチャネル２０別に承認依頼の送信可否を制御する閾値を設定することによって、振り込め詐欺の被害に歯止めをかける基準を多様化されるチャネルに合わせて変えることができる。

［承認依頼の制限時間］
例えば、連携サーバ１０は、出金の承認依頼に関する制限時間と、振込の承認依頼に関する制限時間との間でその時間長を変えることができる。一例として、出金の承認依頼に関する制限時間よりも振込の承認依頼に関する制限時間を長く設定することができる。これによって、利用者に現金が渡されるまで利用者が窓口で待機する「出金」の場合には、承認者に「振込」よりも短い時間で回答させる一方で、利用者が振込を窓口の係員に依頼した段階で利用者が窓口を離れることも可能な「振込」の場合には、承認者に「出金」よりも長い時間を回答に用意できる。他の一例として、振込の承認依頼に関する制限時間よりも出金の承認依頼に関する制限時間を長く設定することもできる。

［分散及び統合］
また、図示した各装置の各構成要素は、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。例えば、受付部１４、承認送信部１５、処理依頼部１６または応答部１７を連携サーバ１０の外部装置としてネットワーク経由で接続するようにしてもよい。また、受付部１４、承認送信部１５、処理依頼部１６または応答部１７を別の装置がそれぞれ有し、ネットワーク接続されて協働することで、上記の連携サーバ１０の機能を実現するようにしてもよい。

［承認依頼プログラム］
また、上記の実施例で説明した各種の処理は、予め用意されたプログラムをパーソナルコンピュータやワークステーションなどのコンピュータで実行することによって実現することができる。そこで、以下では、図１０を用いて、上記の実施例と同様の機能を有する承認依頼プログラムを実行するコンピュータの一例について説明する。

図１０は、実施例１及び実施例２に係る承認依頼プログラムを実行するコンピュータの一例について説明するための図である。図１０に示すように、コンピュータ１００は、操作部１１０ａと、スピーカ１１０ｂと、カメラ１１０ｃと、ディスプレイ１２０と、通信部１３０とを有する。さらに、このコンピュータ１００は、ＣＰＵ１５０と、ＲＯＭ１６０と、ＨＤＤ１７０と、ＲＡＭ１８０とを有する。これら１１０〜１８０の各部はバス１４０を介して接続される。

ＨＤＤ１７０には、図１０に示すように、上記の実施例１で示した承認送信部１５と同様の機能を発揮する承認依頼プログラム１７０ａが予め記憶される。ここでは、最小限の処理単位を実行する承認プログラムが記憶される場合を例示したが、受付部１４、承認送信部１５、処理依頼部１６及び応答部１７と同様の機能を発揮する連携プログラムをＨＤＤ１７０に記憶されることとしてもかまわない。この承認依頼プログラム１７０ａについては、図２に示した各構成要素と同様、適宜統合又は分離しても良い。すなわち、ＨＤＤ１７０に格納される各データは、常に全てのデータがＨＤＤ１７０に格納せずともよく、処理に用いるデータのみがＨＤＤ１７０に格納されれば良い。

そして、ＣＰＵ１５０が、承認依頼プログラム１７０ａをＨＤＤ１７０から読み出してＲＡＭ１８０に展開する。これによって、図１０に示すように、承認依頼プログラム１７０ａは、承認依頼プロセス１８０ａとして機能する。この承認依頼プロセス１８０ａは、ＨＤＤ１７０から読み出した各種データを適宜ＲＡＭ１８０上の自身に割り当てられた領域に展開し、この展開した各種データに基づいて各種処理を実行する。なお、承認依頼プロセス１８０ａは、図２に示した承認送信部１５にて実行される処理、例えば図７に示す処理を含む。また、ＣＰＵ１５０上で仮想的に実現される各処理部は、常に全ての処理部がＣＰＵ１５０上で動作する必要はなく、処理に必要な処理部のみが仮想的に実現されれば良い。

なお、上記の承認依頼プログラム１７０ａについては、必ずしも最初からＨＤＤ１７０やＲＯＭ１６０に記憶させておく必要はない。例えば、コンピュータ１００に挿入されるフレキシブルディスク、いわゆるＦＤ、ＣＤ−ＲＯＭ、ＤＶＤディスク、光磁気ディスク、ＩＣカードなどの「可搬用の物理媒体」に各プログラムを記憶させる。そして、コンピュータ１００がこれらの可搬用の物理媒体から各プログラムを取得して実行するようにしてもよい。また、公衆回線、インターネット、ＬＡＮ、ＷＡＮなどを介してコンピュータ１００に接続される他のコンピュータまたはサーバ装置などに各プログラムを記憶させておき、コンピュータ１００がこれらから各プログラムを取得して実行するようにしてもよい。

１ 銀行システム
１０ 連携サーバ
１１ 通信Ｉ／Ｆ部
１２ 対応関係記憶部
１３ 承認者属性情報記憶部
１４ 受付部
１５ 承認送信部
１６ 処理依頼部
１７ 応答部
２０ フロントチャネル
２１ 利用者端末
２２ ＡＴＭ
２３ 窓口端末
３１ ＩＢサーバ
３２ ＡＴＭサーバ
３３ 営業店サーバ
４０ 勘定系システム
５０Ａ，５０Ｂ，５０Ｃ 承認者端末

Claims (5)

1. 現金自動預け払い機、窓口業務端末のいずれからも出金又は振込処理の依頼を受け可能な銀行システムにおいて、
   コンピュータが、
   前記現金自動預け払い機又は前記窓口業務端末のいずれかにおいて受け付けた出金又は振込処理の依頼元が、出金又は振込処理の実行に先立って口座ごとに登録された承認依頼先の複数の情報処理端末へ承認依頼を送信するように設定された出金又は振込処理の依頼元種別に合致すると判定した場合、前記承認依頼先の複数の情報処理端末へ承認依頼を送信し、
   前記承認依頼先の複数の情報処理端末のうちいずれか１つの承認依頼先の情報処理端末から承認結果として承認の通知を受信した場合、前記出金又は前記振込処理を実行するとともに、前記承認結果を送信した情報処理端末の情報を含む完了通知を前記複数の情報処理端末へ送信し、全ての承認依頼先の情報処理端末から承認結果として却下の通知を受信した場合、前記出金又は前記振込処理を却下処理する、
   処理を実行することを特徴とする承認依頼方法。
2. 出金又は振込処理の実行に先立って口座ごとに登録された承認依頼先の複数の情報処理端末へ承認依頼を送信するように設定された出金又は振込処理の依頼元種別は、窓口業務端末である、
   ことを特徴とする請求項１記載の承認依頼方法。
3. 出金又は振込処理の限度額が異なる複数種類の端末から前記出金又は前記振込処理の依頼を受け可能な銀行システムにおいて、
   コンピュータが、
   現金自動預け払い機又は窓口業務端末のいずれかにおいて受け付けた出金又は振込処理の依頼元が、出金又は振込処理の実行に先立って口座ごとに登録された承認依頼先の複数の情報処理端末へ承認依頼を送信するように設定された出金又は振込処理の依頼元種別に合致すると判定した場合、前記承認依頼先の複数の情報処理端末へ承認依頼を送信し、
   前記承認依頼先の複数の情報処理端末のうちいずれか１つの承認依頼先の情報処理端末から承認結果として承認の通知を受信した場合、前記出金又は前記振込処理を実行するとともに、前記承認結果を送信した情報処理端末の情報を含む完了通知を前記複数の情報処理端末へ送信し、全ての承認依頼先の情報処理端末から承認結果として却下の通知を受信した場合、前記出金又は前記振込処理を却下処理する、
   処理を実行することを特徴とする承認依頼方法。
4. 現金自動預け払い機、窓口業務端末のいずれからも出金又は振込処理の依頼を受け可能な銀行システムにおいて、
   コンピュータに、
   前記現金自動預け払い機又は前記窓口業務端末のいずれかにおいて受け付けた出金又は振込処理の依頼元が、出金又は振込処理の実行に先立って口座ごとに登録された承認依頼先の複数の情報処理端末へ承認依頼を送信するように設定された出金又は振込処理の依頼元種別に合致すると判定した場合、前記承認依頼先の複数の情報処理端末へ承認依頼を送信し、
   前記承認依頼先の複数の情報処理端末のうちいずれか１つの承認依頼先の情報処理端末から承認結果として承認の通知を受信した場合、前記出金又は前記振込処理を実行するとともに、前記承認結果を送信した情報処理端末の情報を含む完了通知を前記複数の情報処理端末へ送信し、全ての承認依頼先の情報処理端末から承認結果として却下の通知を受信した場合、前記出金又は前記振込処理を却下処理する、
   処理を実行させることを特徴とする承認依頼プログラム。
5. 現金自動預け払い機、窓口業務端末のいずれからも出金又は振込処理の依頼を受け可能な銀行システムにおいて、
   前記現金自動預け払い機又は前記窓口業務端末のいずれかにおいて受け付けた出金又は振込処理の依頼元が、出金又は振込処理の実行に先立って口座ごとに登録された承認依頼先の複数の情報処理端末へ承認依頼を送信するように設定された出金又は振込処理の依頼元種別に合致すると判定した場合、前記承認依頼先の複数の情報処理端末へ承認依頼を送信する承認依頼送信部と、
   前記承認依頼先の複数の情報処理端末のうちいずれか１つの承認依頼先の情報処理端末から承認結果として承認の通知を受信した場合、前記出金又は前記振込処理を実行するとともに、前記承認結果を送信した情報処理端末の情報を含む完了通知を前記複数の情報処理端末へ送信し、全ての承認依頼先の情報処理端末から承認結果として却下の通知を受信した場合、前記出金又は前記振込処理を却下処理する処理実行部と、
   を有することを特徴とする銀行システム。

Images