被仕向送金受取システム及びその受取方法
【課題】外為処理業務において被仕向送金の受取側の迅速な処理及び事務負荷を軽減するシステムを提供する。
【解決手段】ネットバンキング受付用コンピュータは、被仕向送金を受け取る顧客の顧客端末からインターネットを介して被仕向送金に対応する着金予約情報を受付ける。外為処理ホストコンピュータは、ネットバンキング受付用コンピュータが受付けた着金予約情報を受信し、着金予約ＤＢに予約データとして登録する。一方、外為処理ホストコンピュータは、海外から受信した送金電文を解析し、所定の項目ごとに送金電文データにマッピングする。更に外為処理ホストコンピュータは、送金電文データと着金予約ＤＢに登録された予約データを比較し、その一致又は不一致を判定し、予約データと一致すると判定した送金電文データに含まれる送金額を、予約データに含まれる受取人口座に入金させるための入金要求を勘定系ホストコンピュータに送信する。
【解決手段】ネットバンキング受付用コンピュータは、被仕向送金を受け取る顧客の顧客端末からインターネットを介して被仕向送金に対応する着金予約情報を受付ける。外為処理ホストコンピュータは、ネットバンキング受付用コンピュータが受付けた着金予約情報を受信し、着金予約ＤＢに予約データとして登録する。一方、外為処理ホストコンピュータは、海外から受信した送金電文を解析し、所定の項目ごとに送金電文データにマッピングする。更に外為処理ホストコンピュータは、送金電文データと着金予約ＤＢに登録された予約データを比較し、その一致又は不一致を判定し、予約データと一致すると判定した送金電文データに含まれる送金額を、予約データに含まれる受取人口座に入金させるための入金要求を勘定系ホストコンピュータに送信する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、被仕向送金受取システム及びその受取方法に係り、特に、金融機関の外為取引業務において、顧客からの依頼に基づいて被仕向送金を受け取る側の受取システム及びその受取方法に関する。
【背景技術】
【０００２】
従来から、顧客からの依頼に基づいて行う商品・サービスの決済等の金融機関の外国為替業務における外国送金（仕向送金）を省力化するため、様々な処理システムや処理方法が提案されている。例えば、特許文献１には、翌営業日に実行を予定している仕向送金取引の中から、決済金額が取引実行日の外国為替相場の影響が受けない取引（対価区分が「コント」又は「ノーエックス」の取引）を抽出し、これらの処理を送金実行日前日の夜間に行うことでシステムの処理負荷を平滑する外国為替取引装置等が記載されている。
【０００３】
また、特許文献２には、ユーザと商品・サービスの提供業者との間の契約の締結から履行までの間におけるキャンセル発生時等の不都合を回避するために、ユーザが入力した情報にしたがって、所定送金日に所定額（預託金）を所定送金先へ送金することを内容とする送金予約レコードをデータベースに格納すると共に、ユーザの口座残高レコードの中の引出し可能残高から当該所定額を減額し、所定送金日になると送金予約レコードにしたがって所定額を所定送金先口座に送金する予約送金方法が記載されている。
【０００４】
また、特許文献３には、被仕向送金の事務負担を軽減するために、外為処理サーバが、事前設定された振替条件及び振替元口座の残高の口座情報を参照して仕向送金データを生成し、顧客は希望レートを入力して為替依頼内容を設定し、外国為替相場が希望レートになると、為替予約が締結された後、外為処理サーバが被仕向金融機関に仕向電文を発信する外国仕向送金取引処理システム等が記載されている。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００２−２９７９１４号公報
【特許文献２】ＷＯ２００３／０８３７４３号公報
【特許文献３】特開２００６−９２４４７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
近年、海外取引が増えるにつれて、金融機関の外国為替業務システムにも負荷がますます増大する傾向がある。上記の特許文献１〜３に記載されたシステムや方法は、いずれも海外への仕向送金における仕向送金側（送金側）のシステムの省力化を目的としたものであるが、被仕向送金側（受取側）のシステムの省力化を目指したものではない。しかしながら、被仕向送金側においても以下に述べるように事務負担が大きく、システムの効率化が望まれている。
【０００７】
図１は、従来行われている被仕向送金受取システムでの業務フローの概略を示した図である。すなわち、受取人は、まず送金依頼（請求書等）を送金人にメール等で送り、送金人から送金予定通知を受け取った後はその入金を待つ。送金人は、送金依頼書を送金人の取引銀行に送り、送金側銀行（取引銀行とは別の銀行である場合もある）では、送金依頼書に基づいて、送金内容を記載した送金電文（仕向電文ともいう。具体例は図２の１００参照）を生成し、受取側銀行本店に対してこの送金電文を発信する。
【０００８】
受取側銀行の本店（外為処理ホストコンピュータ）では、送金電文を受け取ったら、送金電文中の送金額の情報１０１、送金人の情報１０２、受取人の情報１０３等の内容を解析し、受取側銀行内システムにのせるため送金電文の内容をシステム上で対応する項目に入力（マッピング）する。そして各項目の内容を確認しながらデータベースに記帳（登録）し、受取人（受取人の口座番号や受取人指名）を確認した後、該当顧客の口座のある同じ銀行内の支店に送金電文の内容を通知する。この通知を受けた受取側銀行の支店では、送金があったことを受取人である顧客に連絡し、受取人から入金に関する指示を受け取り、受取側銀行の本店に連絡する。受取側銀行の本店では、この指示に受け取った後にはじめて入金処理を行う。
【０００９】
このように、受取側銀行での業務は煩雑である上、顧客にタイムリーに連絡が付かないと入金処理が実行されるまで時間がかかることになる。送金があるたびに顧客にその都度連絡を取る必要があるのは、実際の外国為替取引の依頼は、定期的・定額の仕向送金よりも、都度異なる時期・金額でなされるケースが大半であること、また、為替相場などによって顧客が受取方法をその都度変更する可能性がある、などの理由による。したがって、本発明では、上記のような課題に鑑み、金融機関の外為処理業務における被仕向送金の受取側の迅速な処理及び事務負荷を軽減するシステムを提供することを目的とする。
【課題を解決するための手段】
【００１０】
上記課題を解決するため、本発明の被仕向送金受取システムは、以下のような解決手段を提供する。
【００１１】
金融機関の外国為替業務における被仕向送金受取システムであって、外為処理ホストコンピュータとネットバンキング受付用コンピュータと勘定系ホストコンピュータとがデータ交信可能に接続されており、前記ネットバンキング受付用コンピュータは、被仕向送金を受け取る顧客の顧客端末からインターネットを介して被仕向送金に対応する着金予約情報を受付ける着金予約受付部を備え、前記外為処理ホストコンピュータは、前記ネットバンキング受付用コンピュータから前記受付けた着金予約情報を受信し、着金予約ＤＢに予約データとして登録する着金予約登録部と、送金電文を海外の送金側システムから受信する電文受信部と、前記受信した送金電文を解析し、所定の項目ごとに送金電文データにマッピングする接受記録・検証部と、前記送金電文データと着金予約ＤＢに登録された前記予約データを比較し、一致又は不一致を判定する電文マッチング部と、前記電文マッチング部によって前記予約データと一致すると判定した前記送金電文データに含まれる送金額を、前記予約データに含まれる受取人口座に入金させるための入金要求を前記勘定系ホストコンピュータに送信する入金処理部を備える、ことを特徴とする。
【００１２】
すなわち、本発明の被仕向送金受取システム（以下、本システムと呼ぶ）においては、複数のコンピュータから構成され、ネットバンキング受付用コンピュータは、被仕向送金を受け取る顧客の顧客端末からインターネットを介して被仕向送金に対応する着金予約情報を受付ける。外為処理ホストコンピュータは、ネットバンキング受付用コンピュータが受付けた着金予約情報を受信し、着金予約ＤＢに予約データとして登録する。外為処理ホストコンピュータは、一方では、海外の送金側システムから受信した送金電文を解析し、所定の項目ごとに送金電文データにマッピングしておく。そして、送金電文データと着金予約ＤＢに登録された予約データを比較し、その一致（必ずしも完全一致ではない）、又は不一致を判定し、予約データと一致すると判定した送金電文データに含まれる送金額を、予約データに含まれる受取人口座に入金させるための入金要求を顧客の口座を管理する勘定系ホストコンピュータに向けて送信する。
【００１３】
このように構成することによって、図１で説明した従来システムのように、受取側銀行本店から顧客の口座のある同じ銀行の支店に連絡し、連絡を受けた支店が更にその顧客に連絡して、その都度顧客からの指示を受けて本店に返信するような手間を省きスピーディに入金処理を行うことができる。
【００１４】
また、本システムは下記のような特徴を兼ね備えるように構成してもよい。
前記外為処理ホストコンピュータは、前記送金電文が、前記予約データに含まれた支払指定日よりも遅れて到着した場合には、前記顧客の指定により遅延通知を前記顧客端末に送信する、ことを特徴とする。
【００１５】
このように構成することによって、送金人から送金予定通知を受け、受取人が予約データを登録したが、なんらかの事情により、送金人が通知した支払指定日（送金日）よりも遅れて送金電文が到着した場合は、遅延通知を顧客側に送信して知らせることができる。送金が遅れた事実は、この通知によって記録され今後の取引の参考として扱うこともできる。もちろん、送金電文が届かなかった場合も同様である。
【００１６】
また、本システムは下記のような特徴を兼ね備えるように構成してもよい。
前記電文マッチング部は、前記送金電文データに含まれる送金額が前記予約データに含まれる送金額よりも少ない場合であっても、その差額が前記顧客の指定した許容範囲内であれば前記入金を実行させる、ことを特徴とする。
【００１７】
このように構成することによって、送金額が通知を受けた送金額よりも少ない場合であっても、その差額が手数料程度の許容額である場合には、その送金電文の内容でそのまま入金処理にまわすようにするので、顧客から不要な問い合わせ等が発生することを事前に取り除くことができる。
【００１８】
また、本システムは下記のような特徴を兼ね備えるように構成してもよい。
前記着金予約情報には、取引毎に変動する変動項目と取引毎に変動しない非変動項目に分けて前記顧客が前記着金予約情報の項目を登録する手段を有する、ことを特徴とする。
【００１９】
このように構成することによって、顧客が送金通知を受け取るごとに同じデータ（非変動項目)を、着金予約するために毎回入力する手間を軽減することができる。
【００２０】
また、本システムは下記のような特徴を兼ね備えるように構成してもよい。
前記顧客が特定の商品又はサービスの代金請求の際に、複数の送金人に対して、一定の送金額を一の受取人口座宛に受け取ることを請求する場合において、前記着金予約登録部は、一の前記予約データを前記複数の送金人からの複数の送金電文データに対応付けできる情報（フラグ等）を付加し、前記着金予約ＤＢに格納することを特徴とする。
【００２１】
このように構成することによって、例えば、一つの商品を複数の相手に同時期に販売し、その複数の相手から同じ代金の送金を同一通貨で、受取人の決まった口座に受けるような場合には、一つの予約データを作成するだけでよく、複数の送金電文ごとに予約データをいちいち登録する手間が大幅に省ける。
【００２２】
上記の場合においては、下記のような特徴をさらに有するように構成することが望ましい。
電文マッチング部は、前記複数の送金人からの送金電文データを前記一の予約データに対応させる場合において、前記送金電文データ及び前記予約データに含まれる送金人口座が仮想送金人口座であると判断した場合、前記仮想送金人口座が同一である複数の送金電文データを前記予約データの比較対象とし、送金人口座の一致又は不一致を判定する、ことを特徴とする。
【００２３】
このように構成することにより、上記のように同じ商品代金に対して複数の送金が送られてくる場合、送金電文に含まれる送金人口座は通常はまちまちであるが、受取人はシステムが発行した仮想送金人口座番号を送金人全員に知らせ、送金電文にもその仮想送金人口座番号を記入してもらうことで、送金電文と予約データのＮ対１の対応付けが容易になり電文チェックの処理が軽減できる。
【００２４】
また、本発明は、「物の発明」であるシステムとしてだけでなく、金融機関における複数のコンピュータ（ハードウェア）とコンピュータプログラム（ソフトウェア）が協業して、下記のステップを実行することで、上記のシステムと同様の作用効果を奏する「方法の発明」として捉えることもできる。
【００２５】
データ交信可能に接続された複数のコンピュータで構成された金融機関の外国為替業務システムにおける被仕向送金受取方法であって、前記複数のコンピュータのうちのいずれかのコンピュータが、被仕向送金を受け取る顧客の顧客端末からインターネットを介して被仕向送金に対する着金予約情報を受付けるステップと、前記受付けた着金予約情報を受信し、着金予約ＤＢに予約データとして登録するステップと、送金電文を海外の送金側システムから受信するステップと、前記受信した送金電文を解析し、所定の項目ごとに送金電文データにマッピングするステップと、前記送金電文データと着金予約ＤＢに登録された前記予約データを比較し、一致又は不一致を判定するステップと、前記判定するステップによって前記予約データと一致すると判定した前記送金電文データに含まれる送金額を、前記予約データに含まれる受取人口座に入金させるための処理を実行するステップとを実行する、ことを特徴とする。
【発明の効果】
【００２６】
本発明によれば、金融機関の外為処理業務における被仕向送金の受取側の迅速な入金処理及び事務負荷を軽減するシステムを提供することができる。
【図面の簡単な説明】
【００２７】
【図１】従来行われている被仕向送金受取システムでの業務フローの概略を示した図である。
【図２】送金電文の原文の具体例を示した図である。
【図３】本発明の被仕向送金受取システムでの業務フローの概略を示した図である。
【図４】本発明の被仕向送金受取システムの好適な実施形態であるシステム構成を示した図である。
【図５】本発明の好適な実施形態における着金予約情報登録画面の一例を示した図である。
【図６】本発明の好適な実施形態における着金予約情報登録画面の一例（続）を示した図である。
【図７】本発明の好適な実施形態における外為処理ホストコンピュータ１０のメイン処理フローを示した図である。
【図８】本発明の好適な実施形態における外為処理ホストコンピュータ１０の電文マッチング処理フローを示した図である。
【発明を実施するための形態】
【００２８】
以下、添付図面を参照して、本発明を実施するための形態（以下、実施形態）について詳細に説明する。なお、実施形態の説明の全体を通して同じ要素には同じ番号を付している。
【００２９】
図３は、本発明の被仕向送金受取システムでの業務フローの概略を示した図である。受取人が、まず送金依頼（請求書等）を送金人にメール等で送り、送金人から送金予定通知を受け取ること、送金人が、送金依頼書を送金人の取引銀行に送ること、送金側銀行が、送金依頼書に基づいて送金内容を記載した送金電文を生成し、受取側銀行本店に対して送金電文を発信することは、従来のシステムと同様である。ただし、受取人は、送金予定通知を受け取った時点で、受取人側銀行に設けられた着金予約ＤＢに、海外からの送金があることを予約するため、送金額、送金人の口座情報、及び受取人の口座番号等の情報を登録する。この登録内容について具体的には後述する。通常、被仕向送金の場合は送金側と受取側で送金内容が決まっていることが多い点に着目して、送信側でなく受取側で送金内容を予約データとしてデータベースに登録させるようにしたことが本システムの特徴である。
【００３０】
一方、着金予約とは別に、受取側銀行の本店（外為処理用ホストコンピュータ）では、海外の送金側銀行から送金電文を受け取ったら、送金電文の内容を解析し、銀行内システムの対応する項目にマッピングする。そして内容を検証（例えば、受取人側の口座の実在チェック、送金目的からマネーロンダリング（資金洗浄）等の不正取引の可能性をチェックし、所定のデータベースに記帳（登録）し、送金電文の予約データが着金予約ＤＢに登録されているかどうかを検索する。着金予約ＤＢに送金電文の取引内容と一致する（顧客の指定によって必ずしも完全一致しなくともよい）予約データが見つかれば、そのまま支店や受取側の顧客に連絡することなく、着金予約ＤＢに指定された顧客の受取人口座に対して入金処理を行う。もちろん、その際に入金が完了したことを顧客に通知するようにしてもよい。
【００３１】
このようにすることで、受取側銀行本店システムから顧客の口座のある支店に連絡し、連絡を受けた支店が更にその顧客に連絡して、その都度顧客からの指示を受けて本店に返信するような手間を省き、スピーディに入金処理を行うことができる。また、後述するように、送金電文原文には含まれない受取人である顧客の指定を、着金予約ＤＢにも登録することができるので、送金を受ける都度返答することに比べれば顧客側の負担も減らすことができる。
【００３２】
図４は、本発明の被仕向送金受取システムの好適な実施形態であるシステム構成を示した図である。図示するように、本発明の被仕向送金受取システム１（以下、単に本システム）は、銀行システムを構成する処理コンピュータとして、外為処理ホストコンピュータ１０と、勘定系ホストコンピュータ２０と、ネットバンキング受付用コンピュータ３０とが、銀行内ネットワーク４０（イントラネット）によってそれぞれ通信可能に接続されている。
【００３３】
外為処理ホストコンピュータ１０は、外為取引処理を行う際の中核となるコンピュータであり、本発明に関する部分としては、海外の送金側銀行コンピュータシステム５０から、金融機関間の世界的な専用ネットワーク６０を介して送金電文を受信し、その送金が適切なものであれば、受取人の口座への入金処理要求を勘定系ホストコンピュータ２０に対して行う。
【００３４】
勘定系ホストコンピュータ２０は、口座取引情報ＤＢを備え、顧客の銀行口座おける取引を管理し、外為処理ホストコンピュータ１０からの要求を受付け、各入出金のトランザクションを実行する。
【００３５】
ネットバンキング受付用コンピュータ３０は、いわゆるネットバンキングサーバであり、インターネット８０を介して顧客端末７０からの認証や各種要求の受付処理（前処理）を行う。特に本発明の実施形態では、被仕向送金を受け取る顧客側の端末である顧客端末７０から着金予約情報（詳しくは後述）を受付ける着金予約受付部３１を備えている。
【００３６】
なおここで、顧客端末７０とは、ＰＣ(Personal Computer)や携帯電話・スマートフォン等、顧客の所持する端末のみならず、顧客の依頼を受けて銀行員が操作する銀行内の端末を含むものとする。これらのホストコンピュータ又はサーバは、典型的な銀行のオンラインシステムを構成するものであり、本発明は、必要な機能を実行させるコンピュータ・プログラムと、処理に必要な各種情報を格納したデータべースをこれらのコンピュータに装備することで実現されるので、既存のハードウェアをそのまま使用できる。
【００３７】
外為処理ホストコンピュータ１０は、本発明の中核となるコンピュータであり、データベースとして、到着案内情報ＤＢ１７と着金予約ＤＢ１８を備えており、機能部として、電文受信部１１，接受記帳・検証部１２，電文マッチング部１３，入金処理部１４，着金予約登録部１５，着金予約ＤＢ監視部１６を含んで構成される。上記の各機能部について以下順に説明する。
【００３８】
到着案内情報ＤＢ１７は、送金電文を海外の銀行システムから受信して格納するためのデータベースである。着金予約ＤＢ１８は、送金人から送金予定通知を受け取った受取人である顧客が、その送金内容を予約データとして予め登録するためのデータベースである。登録する予約データには、送金人口座番号，送金通貨，送金額，支払指定日（送金日），送金目的，受取人口座番号等が含まれる他、顧客の指定する各種条件（後述）が含まれる。
【００３９】
電文受信部１１は、送金側銀行コンピュータシステム５０からの送金電文を専用ネットワーク６０を介して受信する役割を果す。接受記帳・検証部１２は、受信（接受）した送金電文の原文をいったん保存し、送金電文原文の内容を検証し、到着情報として到着案内情報ＤＢ１７に登録（記帳）する役割を果す。また、送金目的や送金人、受取人の情報などから資金洗浄（マネーロンダリング）のチェック等もここで行う。
【００４０】
電文マッチング部１３は、到着案内情報ＤＢ１７に登録された検証済みの送金電文の内容（以下、送金電文データ）と、着金予約ＤＢ１８に登録された予約データとを比較し、一致する予約データを検出する役割を果す。このとき両データは完全一致でなくともよく、顧客の指定により、一部が許容範囲内であれば異なっていてもよい。例えば、送金された金額が手数料程度のマイナスがあってもそれを許容範囲とし予約データと一致した電文内容データとみなす。また、着金予約ＤＢに登録した予約データは、入金完了前までなら修正が可能とし、例えば入金先の受取人口座を急遽変更したいなど、顧客の急な要求にも受取側だけで柔軟に対応することができる。この場合、送金電文原文と予約データに相違が生じることになるが予約データが優先される。
【００４１】
入金処理部１４は、電文マッチングの結果、一致する予約データがあれば、勘定系ホストコンピュータ２０と交信して、送金電文テータに含まれた送金額（予約データと相違がある場合は送金電文データが優先される）を、指定された通貨で顧客の銀行口座に入金させる（振込要求を勘定系ホストコンピュータ２０に送信して完了を受け取る）役割を果す。
【００４２】
着金予約登録部１５は、顧客端末７０からネットバンキング受付用コンピュータ３０が受付けた顧客の着金予約情報を検証し予約データとして着金予約ＤＢ１８に格納し、顧客の求めに応じて更新したり削除したりする役割を果す。
【００４３】
着金予約ＤＢ監視部１６は、着金予約ＤＢ１８を定期的（少なくとも毎営業日）に検査し、処理の終了した不要なデータを削除したり、指定支払日を過ぎても所定の期間、送金電文が届かない予約データに対して、その旨の警告を揚げるなどの処理を行う。警告を受けた顧客は、送金人に督促を行う等の処理を行うことになるが、警告後一定期間送金が実行されない場合は、システムが強制的に予約データの削除を行う。
【００４４】
上記した本システムの機能構成は、あくまで一例であり、各コンピュータ（サーバ）は、それぞれ一台であってもよいし、複数台で構成してもよいのはいうまでもない。また、各コンピュータ内においては、一つの機能部を更に分割したり、複数の機能部をまとめて一つの機能部として構成してもよい。各機能部は、コンピュータに内蔵されたＣＰＵ(Central Processing Unit)が、ＲＯＭ（Read Only Memory）またはハードディスク等の記憶装置に格納されたコンピュータ・プログラムを読み出し、ＣＰＵにより実行されたコンピュータ・プログラムが、記憶装置に格納されたデータベース（ＤＢ;Data Base)やメモリ上の記憶領域からテーブル等の必要なデータを読み書きし、場合によっては、関連するハードウェア（例えば、入出力装置、表示装置、通信インターフェース装置）を制御することによって実現される。また、本発明の実施形態におけるデータベース（ＤＢ）は、商用データベースであってよいが、単なるテーブルやファイルの集合体をも意味し、データベースの内部構造自体は問わない。
【００４５】
図５、図６は、本発明の好適な実施形態における着金予約情報登録画面の一例を示した図である。図５の着金予約情報登録画面２００（以下、画面２００）は、顧客が本システムを利用して被仕向送金の受取を予約するために、ネットバンキング受付用コンピュータ３０にアクセスして所定のログイン操作が完了した後、顧客端末７０に表示される画面である。本システムの登録には同じ銀行内に預金口座を持っていることが条件となるが、顧客の過去の取引実績に応じて利用できる範囲に制限を設けたり（例えば、予約データの更新た削除など）、場合によっては登録が拒否されるようにしてもよい。本システムの利用には顧客のある程度の信用度が要求されるからである。
【００４６】
画面２００では、顧客は、送金人口座番号２０１（送金口座），送金通貨２０２（ＪＰＹ，ＵＳＤ，ＥＵＲ等），送金額２０３（取引額），為替レート指定２０３ａ，支払指定日２０４（送金予定日），送金目的２０５，受取人口座番号２０６（受取口座），遅延通知指定２０７，金額マイナス許容指定２０８等を入力する。特に為替レート指定２０３ａは、送金電文受信時の為替レートがここで指定したレート以下の場合は、着金予約をそのまま実行せず、別途指定する方法（例えば、日本円に換金せず外貨預金にそのまま入れる等）で入金を行うことを示す。顧客は上記の項目を入力後、登録ボタン２１０押すことによって本システムへの登録を要求する。入力したデータを取り消す場合は、取消ボタン２１１を押す。
【００４７】
送金目的２０５は、マネーロンダリングのチェック、貿易か貿易でないかのチェック（貿易の場合、金額に応じて国に報告書を提出する必要がある）のために参照される。遅延通知指定２０７は、支払指定日に実際に送金が行われなかった場合に、顧客にメール等で通知する必要がある場合には、「あり」を選択する。遅延通知指定２０７を「なし」と指定すると、支払指定日を過ぎても通知はなく、その後に送金電文が到着しても入金処理は正常に行われることになる。支払指定日に対して送金日がある程度の遅延を許容する場合は、許容時間（例えば時差想到時間）を入力させるようにしてもよい。金額マイナス許容指定２０８は、送金額にある程度のマイナス（手数料程度）を許容するか否かを選択する。許容金額を明示的に入力するようにしてもよい。金額マイナス許容指定２０８を「なし」と選択すると、登録した予約データと送金電文データの送金額が完全に一致する必要がある。なお、図示していないが、ここで例示した項目以外にも顧客は様々な指定を登録することができる。例えば、支払指定日前に送金電文が到着した場合、そのことを通知するか否か、当該予約データに複数の送金電文データを対応付け可能とするか否か、などである。
【００４８】
同じ送金元と頻繁に取引するような場合には、次回入力画面起動時には、支払指定日２０４など毎回変動する項目を除き、前回の入力結果を画面２００に表示するようにしてもよい。また、例えば、同じ商品やサービスの代金を日本円で複一つの受取入金口座に受け取るような場合には、図示するように、送金人口座番号２０１と支払指定日２０４を変動項目とし、他は非変動項目として定義できるようにしてもよい。このため、画面２００の各項目には、変動項目と非変動項目の指定ができるチェックボックス２０９が設けられている。また、このような場合、多数の送金人からの送金予定通知に対して、顧客がそれぞれの予約データをいちいち登録する手間を低減するため、送金人口座番号２０１を仮想送金人口座番号とし、支払指定日２０４をある程度の期間（例えば、2011/02/04〜2011/02/28など）として指定できるようにすることが望ましい。
【００４９】
この仮想送金人口座番号を用いて、一度の予約データの登録で多数の送金電文に対応させることもできる。通常、仮想口座番号は、送金人又は受取人が自分の口座番号を相手側に通知せずに取引を行う場合に主に使用されるが、本システムでは仮想送金人口座番号は、一人の受取人に対して多数の送金人がいる場合に、送金人を一つのグループとしてみなして取り扱うためのグループ口座番号として使用される。この仮想送金人口座番号は、通常の銀行口座の口座番号とは異なった形式で発番されるので、システムが容易に区別できる。ある仮想送金人口座番号を指定した予約データには、同じ仮想送金人口座番号を含んだ複数の送金電文データを対応づけられることを示すため、格納着金予約登録部１５は、必要な情報（顧客指定に基づくフラグ等）を着金予約ＤＢ１８に格納する。
【００５０】
なお、仮想送金人口座番号は、電文マッチングの際だけに利用され、送金人側で仮想送金人口座番号に実口座番号を紐付けて引き落としに利用されることはない。また、仮想送金人口座番号は、本システム中に所定のメニューを用意し、システムがワンタイム番号を自動発行して顧客に提示する手段を設けることによって提供する。顧客は、この発行された仮想送金人口座番号を前もって送金人にも伝えておくことはいうまでもない。
【００５１】
このようにすることで、特定の商品やサービスの取引において複数の相手からの代金を送金してもらう際に、着金予約情報を一括して登録することができる。この場合、着金予約ＤＢ１８には一つの予約データに対して複数の送金電文が対応することになるので、少なくとも指定された支払指定期間中は、この予約データが着金予約ＤＢ１８に保持される。また、送金電文が到着するごとに各送金人の情報をＤＢに保持するようにしてもよい。
【００５２】
図６の上段は、着金予約情報登録が無事に完了したときに表示される着金予約情報登録完了画面３００であり、登録番号（予約番号）が表示される。図６の下段は、着金予約登録情報確認画面４００（以下、画面４００）であり、登録済みの予約データを確認したり、変更したり、削除したりするための画面である。
【００５３】
画面４００には、登録済みの予約データの一覧４０１が表示される。表示される順序は、デフォルトでは登録日の古いものから順に表示されるものとするが、支払指定日の近い順に表示したり、送金人で取引の件数が多いものから順に表示したり、送金額の大きいものから順に表示できるようにしてもよい。顧客は、予約データの一覧４０１から操作すべき予約データの行を選択して更新ボタン４０２を押すと、図５で示した画面２００と同様な画面が表示され、各項目を変更することができる。もちろん、変更時期や変更内容によって変更不可の項目も存在する。例えば、支払指定日を過去の日付に変更したり、顧客名義以外の口座番号を受取口座として変更することはできない。また、予約データを取り消す場合には、該当する行を選択して削除ボタン４０３を押す。また、一つの予約データに複数の送金電文が対応する場合には、その旨が予約データに含まれて表示されることが望ましい。
【００５４】
図７は、本発明の好適な実施形態における外為処理ホストコンピュータ１０のメイン処理フローを示した図である。外為処理ホストコンピュータ１０は、まずステップＳ１０において、送金電文を受信したら原文のまま到着案内情報ＤＢ１７に保存する（接受記帳）。
【００５５】
次に、接受した電文を接受検証を行う（ステップＳ１１）。接受検証では、受取受取人口座番号の実在確認、受取人氏名の確認、送金目的にＮＧワードが含まれていないか、送金人口座番号の情報から過去にマネーロンダリング等の不正取引に使われた履歴がないかどうかのチェックが自動的または半自動で行われる。システムで判断できないものは、システムのオペレータ等に通知される。
【００５６】
接受検証が終了すると、ステップＳ１２において、着金予約ＤＢの予約データの未処理のものを読み出す。そしてステップＳ１３において、記帳した送金電文データと一致する予約データがあるかを探索する。電文マッチングの処理手順はの詳細は後述の図８に示す。電文マッチング処理の結果、一致する予約データが存在した場合には（ステップＳ１４；Ｙｅｓ）、予約データに含まれた受取人の指定口座に入金処理を行う。具体的には、外為処理ホストコンピュータ１０は、勘定系ホストコンピュータ２０に対して、指定された口座へ送金電文データで指定された送金額を振り込むように振込要求を送信する。
【００５７】
ステップＳ１５において、入金処理が完了すると、ステップＳ１６に移り、送金日が予約データで指定された支払指定日より遅れているかどうかをチェックする。ここで、実際の送金日が支払指定日以降であっても、顧客指定により遅延が許容範囲内であればステップＳ１５の電文マッチング処理では一致とされ、入金自体は処理されるものとする。遅延がある場合（ステップＳ１６；Ｙｅｓ）、予約データに遅延通知がある場合に（ステップＳ１７；Ｙｅｓ）は、予め指定された顧客の通知先にその旨のメッセージを発行する（ステップＳ１８）。遅延がない場合（ステップＳ１６；Ｎｏ）は、ステップＳ１３の電文マッチング処理に戻す（実際には図８のステップＳ２４からの処理を継続させる）。なお、遅延通知の発行については、送金電文の到着をトリガーとして、電文マッチング部１３が検出した遅延に基づいて行われる場合の他、着金予約ＤＢ監視部１６が定期的に着金予約ＤＢ１８を検査することにより検出した遅延に基づく場合がある。
【００５８】
ステップＳ１４に戻って、電文マッチングの結果、一致した予約データがない場合（ステップＳ１４；Ｎｏ）には、ステップＳ１９に移り、未チェックの予約データの探索を続ける。予約データをずべてチェックし終えたらメイン処理は終了する。なお、すべての予約データをチェックしても一致するものがない送金電文データに対しては、従来どおりの方法で入金処理を行うものとする。
【００５９】
図８は、本発明の好適な実施形態における外為処理ホストコンピュータ１０の電文マッチング処理フローを示した図である。図８では、前図ステップＳ１３の電文マッチングの詳細を示したものである。
【００６０】
外為処理ホストコンピュータ１０の電文マッチング部１３は、まずステップＳ２０において、送金電文データと予約データの受取人口座を比較し一致するかどうかを調べる。一致する場合は、ステップＳ２１に進むが、一致しない場合は、ステップＳ２８に移り、「予約データ不一致」と判定して処理を終了する。なお、送金電文発行後に受取人口座を急遽変更したい場合も考えられるので、直前の旧受取人口座と新受取人口座を共に予約着金ＤＢ１８に保存しておき、受取人口座が一致しない場合であっても予約データ中の新受取人口座を旧受取人口座に置き換えて判定するようにしてもよい。
【００６１】
次にステップＳ２１においては、送金人口座番号が一致するかどうかを調べる。一致する場合は、次のステップＳ２２に進むが、一致しない場合は、やはりステップＳ２８に移り、「予約データ不一致」と判定して処理を終了する。送金人口座番号は仮想送金人口座番号であってもよいのは既に説明したとおりであるが、この場合、一つの予約データに複数の送金電文が対応することに注意する必要がある。
【００６２】
電文マッチング部１３は、次にステップＳ２２において、予約データの支払指定日と今回の電文の処理日を比較し、処理日が支払指定日前の場合は、予約データで指定された前の送金であるとして、やはりステップＳ２８に移り、「予約データ不一致」と判定して処理を終了する。したがって、この電文の処理はいったん保留され、後日、支払指定日にまた処理対象となる。もっとも顧客指定により、指定日前の送金を受付けるようにしてもよい。その場合は、ステップＳ２２の処理を省略するようにする。
【００６３】
受取人及び送金人が予約データと一致すると、ステップＳ２３に移り、支払指定日と現在の処理日の関係を調べる。支払指定日より処理日が遅い場合は、遅延とするが、顧客指定によりその遅延が時差等による許容範囲にある場合にはステップＳ２４に進む。許容範囲にない遅延の場合は、ステップＳ２８でいったん予約データ不一致と判定され、メイン処理に戻る。メイン処理では、この場合、いったん処理を保留し、遅延通知指定がある場合には、顧客にその旨通知する。遅延通知指定がない場合は、既に説明したように、電文マッチング処理のステップＳ２４に処理を戻す。
【００６４】
ステップＳ２４では、予約データ中の顧客指定により、金額マイナス許容指定があるかどうかが調べられる。金額マイナス許容指定がある場合（ステップＳ２４；Ｙｅｓ）、たとえ送金額が予約データと不一致であっても、顧客が指定した許容範囲内であれば（ステップＳ２５；Ｙｅｓ）、ステップＳ２６に移り、「予約データ一致」と判定される。金額マイナス許容指定がない場合（ステップＳ２４；Ｎｏ）、ステップＳ２７において、送金額が予約データと完全一致しているかどうかが調べられる。完全一致していれば、ステップＳ２６の「一致判定」が、完全一致していなければステップＳ２８の「不一致判定」がなされる。
【００６５】
なお、上記のフローチャートは、受取人口座、送金人口座、支払指定日と処理日、遅延と遅延許容範囲、金額マイナス許容指定の順に比較処理したが、このような比較順序に限定されるものではない。例えば、支払指定日と処理日の比較を最初のステップＳ２０で行えば、支払指定日前の予約データは電文チェックの対象から最初にはずれるので以後のチェックにかかる時間を短縮できるようにも見える。ただし、支払指定日前の入金処理を許容する顧客指定が増えると、そのチェックも必要となる。したがって、上記の処理順序は、実際の予約データの一致、不一致の傾向によって柔軟に変更でき最適な比較順序を行えるようにすることが望ましい。
【００６６】
既に説明したとおり、従来の仕向送金システムは送金側に着目したものであったが、受取側に着目されることは少なかった。通常外国仕向送金の場合は、送金側と受取側で送金内容が決まっていることが多いため、本発明では、送信側でなく受取側で送金内容を予約データベースに登録させることができる点に着目し、新たな省力化のためのシステムを構築可能とした。なお、本発明では外国為替取引の省力化を主眼としたが、送金内容が予め送金人と受取人で決まっている取引であれば、国内取引であってもその決済に本発明を応用することは可能である。例えば、顧客と業者が通知し合い、予め送金額や取引情報を定めることができる取引であって、非定期、非定額が多い取引の決済や、献金額が事前に決まっている政治献金の受取システムなどが考えられる。
【００６７】
以上、実施形態を用いて本発明を説明したが、本発明の技術的範囲は上記実施形態に記載の範囲には限定されないことは言うまでもない。上記実施形態に、多様な変更または改良を加えることが可能であることが当業者に明らかである。またその様な変更または改良を加えた形態も本発明の技術的範囲に含まれ得ることが、特許請求の範囲の記載から明らかである。
【符号の説明】
【００６８】
１ 被仕向送金受取システム
１０ 外為処理ホストコンピュータ
１１ 電文受信部
１２ 電文記帳・検証部
１３ 電文マッチング部
１４ 入金処理部
１５ 着金予約登録部
１６ 着金予約ＤＢ監視部
１７ 到着案内情報ＤＢ
１８ 着金予約ＤＢ
２０ 勘定系ホストコンピュータ
３０ ネットバンキング受付用コンピュータ（ネットバンキングサーバ）
３１ 着金予約受付部
４０ 銀行内ネットワーク（イントラネット）
５０ 送金側銀行コンピュータシステム
６０ 専用ネットワーク
７０ 顧客端末
８０ インターネット
１００ 送金電文（仕向電文）
２００ 着金予約情報登録画面
３００ 着金予約情報登録完了画面
４００ 着金予約登録情報確認画面
【技術分野】
【０００１】
本発明は、被仕向送金受取システム及びその受取方法に係り、特に、金融機関の外為取引業務において、顧客からの依頼に基づいて被仕向送金を受け取る側の受取システム及びその受取方法に関する。
【背景技術】
【０００２】
従来から、顧客からの依頼に基づいて行う商品・サービスの決済等の金融機関の外国為替業務における外国送金（仕向送金）を省力化するため、様々な処理システムや処理方法が提案されている。例えば、特許文献１には、翌営業日に実行を予定している仕向送金取引の中から、決済金額が取引実行日の外国為替相場の影響が受けない取引（対価区分が「コント」又は「ノーエックス」の取引）を抽出し、これらの処理を送金実行日前日の夜間に行うことでシステムの処理負荷を平滑する外国為替取引装置等が記載されている。
【０００３】
また、特許文献２には、ユーザと商品・サービスの提供業者との間の契約の締結から履行までの間におけるキャンセル発生時等の不都合を回避するために、ユーザが入力した情報にしたがって、所定送金日に所定額（預託金）を所定送金先へ送金することを内容とする送金予約レコードをデータベースに格納すると共に、ユーザの口座残高レコードの中の引出し可能残高から当該所定額を減額し、所定送金日になると送金予約レコードにしたがって所定額を所定送金先口座に送金する予約送金方法が記載されている。
【０００４】
また、特許文献３には、被仕向送金の事務負担を軽減するために、外為処理サーバが、事前設定された振替条件及び振替元口座の残高の口座情報を参照して仕向送金データを生成し、顧客は希望レートを入力して為替依頼内容を設定し、外国為替相場が希望レートになると、為替予約が締結された後、外為処理サーバが被仕向金融機関に仕向電文を発信する外国仕向送金取引処理システム等が記載されている。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００２−２９７９１４号公報
【特許文献２】ＷＯ２００３／０８３７４３号公報
【特許文献３】特開２００６−９２４４７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
近年、海外取引が増えるにつれて、金融機関の外国為替業務システムにも負荷がますます増大する傾向がある。上記の特許文献１〜３に記載されたシステムや方法は、いずれも海外への仕向送金における仕向送金側（送金側）のシステムの省力化を目的としたものであるが、被仕向送金側（受取側）のシステムの省力化を目指したものではない。しかしながら、被仕向送金側においても以下に述べるように事務負担が大きく、システムの効率化が望まれている。
【０００７】
図１は、従来行われている被仕向送金受取システムでの業務フローの概略を示した図である。すなわち、受取人は、まず送金依頼（請求書等）を送金人にメール等で送り、送金人から送金予定通知を受け取った後はその入金を待つ。送金人は、送金依頼書を送金人の取引銀行に送り、送金側銀行（取引銀行とは別の銀行である場合もある）では、送金依頼書に基づいて、送金内容を記載した送金電文（仕向電文ともいう。具体例は図２の１００参照）を生成し、受取側銀行本店に対してこの送金電文を発信する。
【０００８】
受取側銀行の本店（外為処理ホストコンピュータ）では、送金電文を受け取ったら、送金電文中の送金額の情報１０１、送金人の情報１０２、受取人の情報１０３等の内容を解析し、受取側銀行内システムにのせるため送金電文の内容をシステム上で対応する項目に入力（マッピング）する。そして各項目の内容を確認しながらデータベースに記帳（登録）し、受取人（受取人の口座番号や受取人指名）を確認した後、該当顧客の口座のある同じ銀行内の支店に送金電文の内容を通知する。この通知を受けた受取側銀行の支店では、送金があったことを受取人である顧客に連絡し、受取人から入金に関する指示を受け取り、受取側銀行の本店に連絡する。受取側銀行の本店では、この指示に受け取った後にはじめて入金処理を行う。
【０００９】
このように、受取側銀行での業務は煩雑である上、顧客にタイムリーに連絡が付かないと入金処理が実行されるまで時間がかかることになる。送金があるたびに顧客にその都度連絡を取る必要があるのは、実際の外国為替取引の依頼は、定期的・定額の仕向送金よりも、都度異なる時期・金額でなされるケースが大半であること、また、為替相場などによって顧客が受取方法をその都度変更する可能性がある、などの理由による。したがって、本発明では、上記のような課題に鑑み、金融機関の外為処理業務における被仕向送金の受取側の迅速な処理及び事務負荷を軽減するシステムを提供することを目的とする。
【課題を解決するための手段】
【００１０】
上記課題を解決するため、本発明の被仕向送金受取システムは、以下のような解決手段を提供する。
【００１１】
金融機関の外国為替業務における被仕向送金受取システムであって、外為処理ホストコンピュータとネットバンキング受付用コンピュータと勘定系ホストコンピュータとがデータ交信可能に接続されており、前記ネットバンキング受付用コンピュータは、被仕向送金を受け取る顧客の顧客端末からインターネットを介して被仕向送金に対応する着金予約情報を受付ける着金予約受付部を備え、前記外為処理ホストコンピュータは、前記ネットバンキング受付用コンピュータから前記受付けた着金予約情報を受信し、着金予約ＤＢに予約データとして登録する着金予約登録部と、送金電文を海外の送金側システムから受信する電文受信部と、前記受信した送金電文を解析し、所定の項目ごとに送金電文データにマッピングする接受記録・検証部と、前記送金電文データと着金予約ＤＢに登録された前記予約データを比較し、一致又は不一致を判定する電文マッチング部と、前記電文マッチング部によって前記予約データと一致すると判定した前記送金電文データに含まれる送金額を、前記予約データに含まれる受取人口座に入金させるための入金要求を前記勘定系ホストコンピュータに送信する入金処理部を備える、ことを特徴とする。
【００１２】
すなわち、本発明の被仕向送金受取システム（以下、本システムと呼ぶ）においては、複数のコンピュータから構成され、ネットバンキング受付用コンピュータは、被仕向送金を受け取る顧客の顧客端末からインターネットを介して被仕向送金に対応する着金予約情報を受付ける。外為処理ホストコンピュータは、ネットバンキング受付用コンピュータが受付けた着金予約情報を受信し、着金予約ＤＢに予約データとして登録する。外為処理ホストコンピュータは、一方では、海外の送金側システムから受信した送金電文を解析し、所定の項目ごとに送金電文データにマッピングしておく。そして、送金電文データと着金予約ＤＢに登録された予約データを比較し、その一致（必ずしも完全一致ではない）、又は不一致を判定し、予約データと一致すると判定した送金電文データに含まれる送金額を、予約データに含まれる受取人口座に入金させるための入金要求を顧客の口座を管理する勘定系ホストコンピュータに向けて送信する。
【００１３】
このように構成することによって、図１で説明した従来システムのように、受取側銀行本店から顧客の口座のある同じ銀行の支店に連絡し、連絡を受けた支店が更にその顧客に連絡して、その都度顧客からの指示を受けて本店に返信するような手間を省きスピーディに入金処理を行うことができる。
【００１４】
また、本システムは下記のような特徴を兼ね備えるように構成してもよい。
前記外為処理ホストコンピュータは、前記送金電文が、前記予約データに含まれた支払指定日よりも遅れて到着した場合には、前記顧客の指定により遅延通知を前記顧客端末に送信する、ことを特徴とする。
【００１５】
このように構成することによって、送金人から送金予定通知を受け、受取人が予約データを登録したが、なんらかの事情により、送金人が通知した支払指定日（送金日）よりも遅れて送金電文が到着した場合は、遅延通知を顧客側に送信して知らせることができる。送金が遅れた事実は、この通知によって記録され今後の取引の参考として扱うこともできる。もちろん、送金電文が届かなかった場合も同様である。
【００１６】
また、本システムは下記のような特徴を兼ね備えるように構成してもよい。
前記電文マッチング部は、前記送金電文データに含まれる送金額が前記予約データに含まれる送金額よりも少ない場合であっても、その差額が前記顧客の指定した許容範囲内であれば前記入金を実行させる、ことを特徴とする。
【００１７】
このように構成することによって、送金額が通知を受けた送金額よりも少ない場合であっても、その差額が手数料程度の許容額である場合には、その送金電文の内容でそのまま入金処理にまわすようにするので、顧客から不要な問い合わせ等が発生することを事前に取り除くことができる。
【００１８】
また、本システムは下記のような特徴を兼ね備えるように構成してもよい。
前記着金予約情報には、取引毎に変動する変動項目と取引毎に変動しない非変動項目に分けて前記顧客が前記着金予約情報の項目を登録する手段を有する、ことを特徴とする。
【００１９】
このように構成することによって、顧客が送金通知を受け取るごとに同じデータ（非変動項目)を、着金予約するために毎回入力する手間を軽減することができる。
【００２０】
また、本システムは下記のような特徴を兼ね備えるように構成してもよい。
前記顧客が特定の商品又はサービスの代金請求の際に、複数の送金人に対して、一定の送金額を一の受取人口座宛に受け取ることを請求する場合において、前記着金予約登録部は、一の前記予約データを前記複数の送金人からの複数の送金電文データに対応付けできる情報（フラグ等）を付加し、前記着金予約ＤＢに格納することを特徴とする。
【００２１】
このように構成することによって、例えば、一つの商品を複数の相手に同時期に販売し、その複数の相手から同じ代金の送金を同一通貨で、受取人の決まった口座に受けるような場合には、一つの予約データを作成するだけでよく、複数の送金電文ごとに予約データをいちいち登録する手間が大幅に省ける。
【００２２】
上記の場合においては、下記のような特徴をさらに有するように構成することが望ましい。
電文マッチング部は、前記複数の送金人からの送金電文データを前記一の予約データに対応させる場合において、前記送金電文データ及び前記予約データに含まれる送金人口座が仮想送金人口座であると判断した場合、前記仮想送金人口座が同一である複数の送金電文データを前記予約データの比較対象とし、送金人口座の一致又は不一致を判定する、ことを特徴とする。
【００２３】
このように構成することにより、上記のように同じ商品代金に対して複数の送金が送られてくる場合、送金電文に含まれる送金人口座は通常はまちまちであるが、受取人はシステムが発行した仮想送金人口座番号を送金人全員に知らせ、送金電文にもその仮想送金人口座番号を記入してもらうことで、送金電文と予約データのＮ対１の対応付けが容易になり電文チェックの処理が軽減できる。
【００２４】
また、本発明は、「物の発明」であるシステムとしてだけでなく、金融機関における複数のコンピュータ（ハードウェア）とコンピュータプログラム（ソフトウェア）が協業して、下記のステップを実行することで、上記のシステムと同様の作用効果を奏する「方法の発明」として捉えることもできる。
【００２５】
データ交信可能に接続された複数のコンピュータで構成された金融機関の外国為替業務システムにおける被仕向送金受取方法であって、前記複数のコンピュータのうちのいずれかのコンピュータが、被仕向送金を受け取る顧客の顧客端末からインターネットを介して被仕向送金に対する着金予約情報を受付けるステップと、前記受付けた着金予約情報を受信し、着金予約ＤＢに予約データとして登録するステップと、送金電文を海外の送金側システムから受信するステップと、前記受信した送金電文を解析し、所定の項目ごとに送金電文データにマッピングするステップと、前記送金電文データと着金予約ＤＢに登録された前記予約データを比較し、一致又は不一致を判定するステップと、前記判定するステップによって前記予約データと一致すると判定した前記送金電文データに含まれる送金額を、前記予約データに含まれる受取人口座に入金させるための処理を実行するステップとを実行する、ことを特徴とする。
【発明の効果】
【００２６】
本発明によれば、金融機関の外為処理業務における被仕向送金の受取側の迅速な入金処理及び事務負荷を軽減するシステムを提供することができる。
【図面の簡単な説明】
【００２７】
【図１】従来行われている被仕向送金受取システムでの業務フローの概略を示した図である。
【図２】送金電文の原文の具体例を示した図である。
【図３】本発明の被仕向送金受取システムでの業務フローの概略を示した図である。
【図４】本発明の被仕向送金受取システムの好適な実施形態であるシステム構成を示した図である。
【図５】本発明の好適な実施形態における着金予約情報登録画面の一例を示した図である。
【図６】本発明の好適な実施形態における着金予約情報登録画面の一例（続）を示した図である。
【図７】本発明の好適な実施形態における外為処理ホストコンピュータ１０のメイン処理フローを示した図である。
【図８】本発明の好適な実施形態における外為処理ホストコンピュータ１０の電文マッチング処理フローを示した図である。
【発明を実施するための形態】
【００２８】
以下、添付図面を参照して、本発明を実施するための形態（以下、実施形態）について詳細に説明する。なお、実施形態の説明の全体を通して同じ要素には同じ番号を付している。
【００２９】
図３は、本発明の被仕向送金受取システムでの業務フローの概略を示した図である。受取人が、まず送金依頼（請求書等）を送金人にメール等で送り、送金人から送金予定通知を受け取ること、送金人が、送金依頼書を送金人の取引銀行に送ること、送金側銀行が、送金依頼書に基づいて送金内容を記載した送金電文を生成し、受取側銀行本店に対して送金電文を発信することは、従来のシステムと同様である。ただし、受取人は、送金予定通知を受け取った時点で、受取人側銀行に設けられた着金予約ＤＢに、海外からの送金があることを予約するため、送金額、送金人の口座情報、及び受取人の口座番号等の情報を登録する。この登録内容について具体的には後述する。通常、被仕向送金の場合は送金側と受取側で送金内容が決まっていることが多い点に着目して、送信側でなく受取側で送金内容を予約データとしてデータベースに登録させるようにしたことが本システムの特徴である。
【００３０】
一方、着金予約とは別に、受取側銀行の本店（外為処理用ホストコンピュータ）では、海外の送金側銀行から送金電文を受け取ったら、送金電文の内容を解析し、銀行内システムの対応する項目にマッピングする。そして内容を検証（例えば、受取人側の口座の実在チェック、送金目的からマネーロンダリング（資金洗浄）等の不正取引の可能性をチェックし、所定のデータベースに記帳（登録）し、送金電文の予約データが着金予約ＤＢに登録されているかどうかを検索する。着金予約ＤＢに送金電文の取引内容と一致する（顧客の指定によって必ずしも完全一致しなくともよい）予約データが見つかれば、そのまま支店や受取側の顧客に連絡することなく、着金予約ＤＢに指定された顧客の受取人口座に対して入金処理を行う。もちろん、その際に入金が完了したことを顧客に通知するようにしてもよい。
【００３１】
このようにすることで、受取側銀行本店システムから顧客の口座のある支店に連絡し、連絡を受けた支店が更にその顧客に連絡して、その都度顧客からの指示を受けて本店に返信するような手間を省き、スピーディに入金処理を行うことができる。また、後述するように、送金電文原文には含まれない受取人である顧客の指定を、着金予約ＤＢにも登録することができるので、送金を受ける都度返答することに比べれば顧客側の負担も減らすことができる。
【００３２】
図４は、本発明の被仕向送金受取システムの好適な実施形態であるシステム構成を示した図である。図示するように、本発明の被仕向送金受取システム１（以下、単に本システム）は、銀行システムを構成する処理コンピュータとして、外為処理ホストコンピュータ１０と、勘定系ホストコンピュータ２０と、ネットバンキング受付用コンピュータ３０とが、銀行内ネットワーク４０（イントラネット）によってそれぞれ通信可能に接続されている。
【００３３】
外為処理ホストコンピュータ１０は、外為取引処理を行う際の中核となるコンピュータであり、本発明に関する部分としては、海外の送金側銀行コンピュータシステム５０から、金融機関間の世界的な専用ネットワーク６０を介して送金電文を受信し、その送金が適切なものであれば、受取人の口座への入金処理要求を勘定系ホストコンピュータ２０に対して行う。
【００３４】
勘定系ホストコンピュータ２０は、口座取引情報ＤＢを備え、顧客の銀行口座おける取引を管理し、外為処理ホストコンピュータ１０からの要求を受付け、各入出金のトランザクションを実行する。
【００３５】
ネットバンキング受付用コンピュータ３０は、いわゆるネットバンキングサーバであり、インターネット８０を介して顧客端末７０からの認証や各種要求の受付処理（前処理）を行う。特に本発明の実施形態では、被仕向送金を受け取る顧客側の端末である顧客端末７０から着金予約情報（詳しくは後述）を受付ける着金予約受付部３１を備えている。
【００３６】
なおここで、顧客端末７０とは、ＰＣ(Personal Computer)や携帯電話・スマートフォン等、顧客の所持する端末のみならず、顧客の依頼を受けて銀行員が操作する銀行内の端末を含むものとする。これらのホストコンピュータ又はサーバは、典型的な銀行のオンラインシステムを構成するものであり、本発明は、必要な機能を実行させるコンピュータ・プログラムと、処理に必要な各種情報を格納したデータべースをこれらのコンピュータに装備することで実現されるので、既存のハードウェアをそのまま使用できる。
【００３７】
外為処理ホストコンピュータ１０は、本発明の中核となるコンピュータであり、データベースとして、到着案内情報ＤＢ１７と着金予約ＤＢ１８を備えており、機能部として、電文受信部１１，接受記帳・検証部１２，電文マッチング部１３，入金処理部１４，着金予約登録部１５，着金予約ＤＢ監視部１６を含んで構成される。上記の各機能部について以下順に説明する。
【００３８】
到着案内情報ＤＢ１７は、送金電文を海外の銀行システムから受信して格納するためのデータベースである。着金予約ＤＢ１８は、送金人から送金予定通知を受け取った受取人である顧客が、その送金内容を予約データとして予め登録するためのデータベースである。登録する予約データには、送金人口座番号，送金通貨，送金額，支払指定日（送金日），送金目的，受取人口座番号等が含まれる他、顧客の指定する各種条件（後述）が含まれる。
【００３９】
電文受信部１１は、送金側銀行コンピュータシステム５０からの送金電文を専用ネットワーク６０を介して受信する役割を果す。接受記帳・検証部１２は、受信（接受）した送金電文の原文をいったん保存し、送金電文原文の内容を検証し、到着情報として到着案内情報ＤＢ１７に登録（記帳）する役割を果す。また、送金目的や送金人、受取人の情報などから資金洗浄（マネーロンダリング）のチェック等もここで行う。
【００４０】
電文マッチング部１３は、到着案内情報ＤＢ１７に登録された検証済みの送金電文の内容（以下、送金電文データ）と、着金予約ＤＢ１８に登録された予約データとを比較し、一致する予約データを検出する役割を果す。このとき両データは完全一致でなくともよく、顧客の指定により、一部が許容範囲内であれば異なっていてもよい。例えば、送金された金額が手数料程度のマイナスがあってもそれを許容範囲とし予約データと一致した電文内容データとみなす。また、着金予約ＤＢに登録した予約データは、入金完了前までなら修正が可能とし、例えば入金先の受取人口座を急遽変更したいなど、顧客の急な要求にも受取側だけで柔軟に対応することができる。この場合、送金電文原文と予約データに相違が生じることになるが予約データが優先される。
【００４１】
入金処理部１４は、電文マッチングの結果、一致する予約データがあれば、勘定系ホストコンピュータ２０と交信して、送金電文テータに含まれた送金額（予約データと相違がある場合は送金電文データが優先される）を、指定された通貨で顧客の銀行口座に入金させる（振込要求を勘定系ホストコンピュータ２０に送信して完了を受け取る）役割を果す。
【００４２】
着金予約登録部１５は、顧客端末７０からネットバンキング受付用コンピュータ３０が受付けた顧客の着金予約情報を検証し予約データとして着金予約ＤＢ１８に格納し、顧客の求めに応じて更新したり削除したりする役割を果す。
【００４３】
着金予約ＤＢ監視部１６は、着金予約ＤＢ１８を定期的（少なくとも毎営業日）に検査し、処理の終了した不要なデータを削除したり、指定支払日を過ぎても所定の期間、送金電文が届かない予約データに対して、その旨の警告を揚げるなどの処理を行う。警告を受けた顧客は、送金人に督促を行う等の処理を行うことになるが、警告後一定期間送金が実行されない場合は、システムが強制的に予約データの削除を行う。
【００４４】
上記した本システムの機能構成は、あくまで一例であり、各コンピュータ（サーバ）は、それぞれ一台であってもよいし、複数台で構成してもよいのはいうまでもない。また、各コンピュータ内においては、一つの機能部を更に分割したり、複数の機能部をまとめて一つの機能部として構成してもよい。各機能部は、コンピュータに内蔵されたＣＰＵ(Central Processing Unit)が、ＲＯＭ（Read Only Memory）またはハードディスク等の記憶装置に格納されたコンピュータ・プログラムを読み出し、ＣＰＵにより実行されたコンピュータ・プログラムが、記憶装置に格納されたデータベース（ＤＢ;Data Base)やメモリ上の記憶領域からテーブル等の必要なデータを読み書きし、場合によっては、関連するハードウェア（例えば、入出力装置、表示装置、通信インターフェース装置）を制御することによって実現される。また、本発明の実施形態におけるデータベース（ＤＢ）は、商用データベースであってよいが、単なるテーブルやファイルの集合体をも意味し、データベースの内部構造自体は問わない。
【００４５】
図５、図６は、本発明の好適な実施形態における着金予約情報登録画面の一例を示した図である。図５の着金予約情報登録画面２００（以下、画面２００）は、顧客が本システムを利用して被仕向送金の受取を予約するために、ネットバンキング受付用コンピュータ３０にアクセスして所定のログイン操作が完了した後、顧客端末７０に表示される画面である。本システムの登録には同じ銀行内に預金口座を持っていることが条件となるが、顧客の過去の取引実績に応じて利用できる範囲に制限を設けたり（例えば、予約データの更新た削除など）、場合によっては登録が拒否されるようにしてもよい。本システムの利用には顧客のある程度の信用度が要求されるからである。
【００４６】
画面２００では、顧客は、送金人口座番号２０１（送金口座），送金通貨２０２（ＪＰＹ，ＵＳＤ，ＥＵＲ等），送金額２０３（取引額），為替レート指定２０３ａ，支払指定日２０４（送金予定日），送金目的２０５，受取人口座番号２０６（受取口座），遅延通知指定２０７，金額マイナス許容指定２０８等を入力する。特に為替レート指定２０３ａは、送金電文受信時の為替レートがここで指定したレート以下の場合は、着金予約をそのまま実行せず、別途指定する方法（例えば、日本円に換金せず外貨預金にそのまま入れる等）で入金を行うことを示す。顧客は上記の項目を入力後、登録ボタン２１０押すことによって本システムへの登録を要求する。入力したデータを取り消す場合は、取消ボタン２１１を押す。
【００４７】
送金目的２０５は、マネーロンダリングのチェック、貿易か貿易でないかのチェック（貿易の場合、金額に応じて国に報告書を提出する必要がある）のために参照される。遅延通知指定２０７は、支払指定日に実際に送金が行われなかった場合に、顧客にメール等で通知する必要がある場合には、「あり」を選択する。遅延通知指定２０７を「なし」と指定すると、支払指定日を過ぎても通知はなく、その後に送金電文が到着しても入金処理は正常に行われることになる。支払指定日に対して送金日がある程度の遅延を許容する場合は、許容時間（例えば時差想到時間）を入力させるようにしてもよい。金額マイナス許容指定２０８は、送金額にある程度のマイナス（手数料程度）を許容するか否かを選択する。許容金額を明示的に入力するようにしてもよい。金額マイナス許容指定２０８を「なし」と選択すると、登録した予約データと送金電文データの送金額が完全に一致する必要がある。なお、図示していないが、ここで例示した項目以外にも顧客は様々な指定を登録することができる。例えば、支払指定日前に送金電文が到着した場合、そのことを通知するか否か、当該予約データに複数の送金電文データを対応付け可能とするか否か、などである。
【００４８】
同じ送金元と頻繁に取引するような場合には、次回入力画面起動時には、支払指定日２０４など毎回変動する項目を除き、前回の入力結果を画面２００に表示するようにしてもよい。また、例えば、同じ商品やサービスの代金を日本円で複一つの受取入金口座に受け取るような場合には、図示するように、送金人口座番号２０１と支払指定日２０４を変動項目とし、他は非変動項目として定義できるようにしてもよい。このため、画面２００の各項目には、変動項目と非変動項目の指定ができるチェックボックス２０９が設けられている。また、このような場合、多数の送金人からの送金予定通知に対して、顧客がそれぞれの予約データをいちいち登録する手間を低減するため、送金人口座番号２０１を仮想送金人口座番号とし、支払指定日２０４をある程度の期間（例えば、2011/02/04〜2011/02/28など）として指定できるようにすることが望ましい。
【００４９】
この仮想送金人口座番号を用いて、一度の予約データの登録で多数の送金電文に対応させることもできる。通常、仮想口座番号は、送金人又は受取人が自分の口座番号を相手側に通知せずに取引を行う場合に主に使用されるが、本システムでは仮想送金人口座番号は、一人の受取人に対して多数の送金人がいる場合に、送金人を一つのグループとしてみなして取り扱うためのグループ口座番号として使用される。この仮想送金人口座番号は、通常の銀行口座の口座番号とは異なった形式で発番されるので、システムが容易に区別できる。ある仮想送金人口座番号を指定した予約データには、同じ仮想送金人口座番号を含んだ複数の送金電文データを対応づけられることを示すため、格納着金予約登録部１５は、必要な情報（顧客指定に基づくフラグ等）を着金予約ＤＢ１８に格納する。
【００５０】
なお、仮想送金人口座番号は、電文マッチングの際だけに利用され、送金人側で仮想送金人口座番号に実口座番号を紐付けて引き落としに利用されることはない。また、仮想送金人口座番号は、本システム中に所定のメニューを用意し、システムがワンタイム番号を自動発行して顧客に提示する手段を設けることによって提供する。顧客は、この発行された仮想送金人口座番号を前もって送金人にも伝えておくことはいうまでもない。
【００５１】
このようにすることで、特定の商品やサービスの取引において複数の相手からの代金を送金してもらう際に、着金予約情報を一括して登録することができる。この場合、着金予約ＤＢ１８には一つの予約データに対して複数の送金電文が対応することになるので、少なくとも指定された支払指定期間中は、この予約データが着金予約ＤＢ１８に保持される。また、送金電文が到着するごとに各送金人の情報をＤＢに保持するようにしてもよい。
【００５２】
図６の上段は、着金予約情報登録が無事に完了したときに表示される着金予約情報登録完了画面３００であり、登録番号（予約番号）が表示される。図６の下段は、着金予約登録情報確認画面４００（以下、画面４００）であり、登録済みの予約データを確認したり、変更したり、削除したりするための画面である。
【００５３】
画面４００には、登録済みの予約データの一覧４０１が表示される。表示される順序は、デフォルトでは登録日の古いものから順に表示されるものとするが、支払指定日の近い順に表示したり、送金人で取引の件数が多いものから順に表示したり、送金額の大きいものから順に表示できるようにしてもよい。顧客は、予約データの一覧４０１から操作すべき予約データの行を選択して更新ボタン４０２を押すと、図５で示した画面２００と同様な画面が表示され、各項目を変更することができる。もちろん、変更時期や変更内容によって変更不可の項目も存在する。例えば、支払指定日を過去の日付に変更したり、顧客名義以外の口座番号を受取口座として変更することはできない。また、予約データを取り消す場合には、該当する行を選択して削除ボタン４０３を押す。また、一つの予約データに複数の送金電文が対応する場合には、その旨が予約データに含まれて表示されることが望ましい。
【００５４】
図７は、本発明の好適な実施形態における外為処理ホストコンピュータ１０のメイン処理フローを示した図である。外為処理ホストコンピュータ１０は、まずステップＳ１０において、送金電文を受信したら原文のまま到着案内情報ＤＢ１７に保存する（接受記帳）。
【００５５】
次に、接受した電文を接受検証を行う（ステップＳ１１）。接受検証では、受取受取人口座番号の実在確認、受取人氏名の確認、送金目的にＮＧワードが含まれていないか、送金人口座番号の情報から過去にマネーロンダリング等の不正取引に使われた履歴がないかどうかのチェックが自動的または半自動で行われる。システムで判断できないものは、システムのオペレータ等に通知される。
【００５６】
接受検証が終了すると、ステップＳ１２において、着金予約ＤＢの予約データの未処理のものを読み出す。そしてステップＳ１３において、記帳した送金電文データと一致する予約データがあるかを探索する。電文マッチングの処理手順はの詳細は後述の図８に示す。電文マッチング処理の結果、一致する予約データが存在した場合には（ステップＳ１４；Ｙｅｓ）、予約データに含まれた受取人の指定口座に入金処理を行う。具体的には、外為処理ホストコンピュータ１０は、勘定系ホストコンピュータ２０に対して、指定された口座へ送金電文データで指定された送金額を振り込むように振込要求を送信する。
【００５７】
ステップＳ１５において、入金処理が完了すると、ステップＳ１６に移り、送金日が予約データで指定された支払指定日より遅れているかどうかをチェックする。ここで、実際の送金日が支払指定日以降であっても、顧客指定により遅延が許容範囲内であればステップＳ１５の電文マッチング処理では一致とされ、入金自体は処理されるものとする。遅延がある場合（ステップＳ１６；Ｙｅｓ）、予約データに遅延通知がある場合に（ステップＳ１７；Ｙｅｓ）は、予め指定された顧客の通知先にその旨のメッセージを発行する（ステップＳ１８）。遅延がない場合（ステップＳ１６；Ｎｏ）は、ステップＳ１３の電文マッチング処理に戻す（実際には図８のステップＳ２４からの処理を継続させる）。なお、遅延通知の発行については、送金電文の到着をトリガーとして、電文マッチング部１３が検出した遅延に基づいて行われる場合の他、着金予約ＤＢ監視部１６が定期的に着金予約ＤＢ１８を検査することにより検出した遅延に基づく場合がある。
【００５８】
ステップＳ１４に戻って、電文マッチングの結果、一致した予約データがない場合（ステップＳ１４；Ｎｏ）には、ステップＳ１９に移り、未チェックの予約データの探索を続ける。予約データをずべてチェックし終えたらメイン処理は終了する。なお、すべての予約データをチェックしても一致するものがない送金電文データに対しては、従来どおりの方法で入金処理を行うものとする。
【００５９】
図８は、本発明の好適な実施形態における外為処理ホストコンピュータ１０の電文マッチング処理フローを示した図である。図８では、前図ステップＳ１３の電文マッチングの詳細を示したものである。
【００６０】
外為処理ホストコンピュータ１０の電文マッチング部１３は、まずステップＳ２０において、送金電文データと予約データの受取人口座を比較し一致するかどうかを調べる。一致する場合は、ステップＳ２１に進むが、一致しない場合は、ステップＳ２８に移り、「予約データ不一致」と判定して処理を終了する。なお、送金電文発行後に受取人口座を急遽変更したい場合も考えられるので、直前の旧受取人口座と新受取人口座を共に予約着金ＤＢ１８に保存しておき、受取人口座が一致しない場合であっても予約データ中の新受取人口座を旧受取人口座に置き換えて判定するようにしてもよい。
【００６１】
次にステップＳ２１においては、送金人口座番号が一致するかどうかを調べる。一致する場合は、次のステップＳ２２に進むが、一致しない場合は、やはりステップＳ２８に移り、「予約データ不一致」と判定して処理を終了する。送金人口座番号は仮想送金人口座番号であってもよいのは既に説明したとおりであるが、この場合、一つの予約データに複数の送金電文が対応することに注意する必要がある。
【００６２】
電文マッチング部１３は、次にステップＳ２２において、予約データの支払指定日と今回の電文の処理日を比較し、処理日が支払指定日前の場合は、予約データで指定された前の送金であるとして、やはりステップＳ２８に移り、「予約データ不一致」と判定して処理を終了する。したがって、この電文の処理はいったん保留され、後日、支払指定日にまた処理対象となる。もっとも顧客指定により、指定日前の送金を受付けるようにしてもよい。その場合は、ステップＳ２２の処理を省略するようにする。
【００６３】
受取人及び送金人が予約データと一致すると、ステップＳ２３に移り、支払指定日と現在の処理日の関係を調べる。支払指定日より処理日が遅い場合は、遅延とするが、顧客指定によりその遅延が時差等による許容範囲にある場合にはステップＳ２４に進む。許容範囲にない遅延の場合は、ステップＳ２８でいったん予約データ不一致と判定され、メイン処理に戻る。メイン処理では、この場合、いったん処理を保留し、遅延通知指定がある場合には、顧客にその旨通知する。遅延通知指定がない場合は、既に説明したように、電文マッチング処理のステップＳ２４に処理を戻す。
【００６４】
ステップＳ２４では、予約データ中の顧客指定により、金額マイナス許容指定があるかどうかが調べられる。金額マイナス許容指定がある場合（ステップＳ２４；Ｙｅｓ）、たとえ送金額が予約データと不一致であっても、顧客が指定した許容範囲内であれば（ステップＳ２５；Ｙｅｓ）、ステップＳ２６に移り、「予約データ一致」と判定される。金額マイナス許容指定がない場合（ステップＳ２４；Ｎｏ）、ステップＳ２７において、送金額が予約データと完全一致しているかどうかが調べられる。完全一致していれば、ステップＳ２６の「一致判定」が、完全一致していなければステップＳ２８の「不一致判定」がなされる。
【００６５】
なお、上記のフローチャートは、受取人口座、送金人口座、支払指定日と処理日、遅延と遅延許容範囲、金額マイナス許容指定の順に比較処理したが、このような比較順序に限定されるものではない。例えば、支払指定日と処理日の比較を最初のステップＳ２０で行えば、支払指定日前の予約データは電文チェックの対象から最初にはずれるので以後のチェックにかかる時間を短縮できるようにも見える。ただし、支払指定日前の入金処理を許容する顧客指定が増えると、そのチェックも必要となる。したがって、上記の処理順序は、実際の予約データの一致、不一致の傾向によって柔軟に変更でき最適な比較順序を行えるようにすることが望ましい。
【００６６】
既に説明したとおり、従来の仕向送金システムは送金側に着目したものであったが、受取側に着目されることは少なかった。通常外国仕向送金の場合は、送金側と受取側で送金内容が決まっていることが多いため、本発明では、送信側でなく受取側で送金内容を予約データベースに登録させることができる点に着目し、新たな省力化のためのシステムを構築可能とした。なお、本発明では外国為替取引の省力化を主眼としたが、送金内容が予め送金人と受取人で決まっている取引であれば、国内取引であってもその決済に本発明を応用することは可能である。例えば、顧客と業者が通知し合い、予め送金額や取引情報を定めることができる取引であって、非定期、非定額が多い取引の決済や、献金額が事前に決まっている政治献金の受取システムなどが考えられる。
【００６７】
以上、実施形態を用いて本発明を説明したが、本発明の技術的範囲は上記実施形態に記載の範囲には限定されないことは言うまでもない。上記実施形態に、多様な変更または改良を加えることが可能であることが当業者に明らかである。またその様な変更または改良を加えた形態も本発明の技術的範囲に含まれ得ることが、特許請求の範囲の記載から明らかである。
【符号の説明】
【００６８】
１ 被仕向送金受取システム
１０ 外為処理ホストコンピュータ
１１ 電文受信部
１２ 電文記帳・検証部
１３ 電文マッチング部
１４ 入金処理部
１５ 着金予約登録部
１６ 着金予約ＤＢ監視部
１７ 到着案内情報ＤＢ
１８ 着金予約ＤＢ
２０ 勘定系ホストコンピュータ
３０ ネットバンキング受付用コンピュータ（ネットバンキングサーバ）
３１ 着金予約受付部
４０ 銀行内ネットワーク（イントラネット）
５０ 送金側銀行コンピュータシステム
６０ 専用ネットワーク
７０ 顧客端末
８０ インターネット
１００ 送金電文（仕向電文）
２００ 着金予約情報登録画面
３００ 着金予約情報登録完了画面
４００ 着金予約登録情報確認画面
【特許請求の範囲】
【請求項１】
金融機関の外国為替業務における被仕向送金受取システムであって、
外為処理ホストコンピュータとネットバンキング受付用コンピュータと勘定系ホストコンピュータとがデータ交信可能に接続されており、
前記ネットバンキング受付用コンピュータは、被仕向送金を受け取る顧客の顧客端末からインターネットを介して被仕向送金に対応する着金予約情報を受付ける着金予約受付部を備え、
前記外為処理ホストコンピュータは、
前記ネットバンキング受付用コンピュータから前記受付けた着金予約情報を受信し、着金予約ＤＢに予約データとして登録する着金予約登録部と、
送金電文を海外の送金側システムから受信する電文受信部と、
前記受信した送金電文を解析し、所定の項目ごとに送金電文データにマッピングする接受記録・検証部と、
前記送金電文データと着金予約ＤＢに登録された前記予約データを比較し、一致又は不一致を判定する電文マッチング部と、
前記電文マッチング部によって前記予約データと一致すると判定した前記送金電文データに含まれる送金額を、前記予約データに含まれる受取人口座に入金させるための入金要求を前記勘定系ホストコンピュータに送信する入金処理部を備える、
ことを特徴とする被仕向送金受取システム。
【請求項２】
前記外為処理ホストコンピュータは、前記送金電文が、前記予約データに含まれた支払指定日よりも遅れて到着した場合には、前記顧客の指定により遅延通知を前記顧客端末に送信する、ことを特徴とする請求項１に記載の被仕向送金受取システム。
【請求項３】
前記電文マッチング部は、前記送金電文データに含まれる送金額が前記予約データに含まれる送金額よりも少ない場合であっても、その差額が前記顧客の指定した許容範囲内であれば前記入金を実行させる、ことを特徴とする請求項１に記載の被仕向送金受取システム。
【請求項４】
前記着金予約情報には、取引毎に変動する変動項目と取引毎に変動しない非変動項目に分けて前記顧客が前記着金予約情報の項目を登録する手段を有する、ことを特徴とする請求項１に記載の被仕向送金受取システム。
【請求項５】
前記顧客が特定の商品又はサービスの代金請求の際に、複数の送金人に対して、一定の送金額を一の受取人口座宛に受け取ることを請求する場合において、前記着金予約登録部は、一の前記予約データを前記複数の送金人からの複数の送金電文データに対応付けできる情報を付加し、前記着金予約ＤＢに格納することを特徴とする、請求項１に記載の被仕向送金受取システム。
【請求項６】
電文マッチング部は、前記複数の送金人からの送金電文データを前記一の予約データに対応させる場合において、前記送金電文データ及び前記予約データに含まれる送金人口座を仮想送金人口座であると判断した場合、前記仮想送金人口座が同一である複数の送金電文データを前記予約データの比較対象とし、送金人口座の一致または不一致を判定する、ことを特徴とする請求項５に記載の被仕向送金受取システム。
【請求項７】
データ交信可能に接続された複数のコンピュータで構成された金融機関の外国為替業務システムにおける被仕向送金受取方法であって、
前記複数のコンピュータのうちのいずれかのコンピュータが、
被仕向送金を受け取る顧客の顧客端末からインターネットを介して被仕向送金に対応する着金予約情報を受付けるステップと、
前記受付けた着金予約情報を受信し、着金予約ＤＢに予約データとして登録するステップと、
送金電文を海外の送金側システムから受信するステップと、
前記受信した送金電文を解析し、所定の項目ごとに送金電文データにマッピングするステップと、
前記送金電文データと着金予約ＤＢに登録された前記予約データを比較し、一致又は不一致を判定するステップと、
前記判定するステップによって前記予約データと一致すると判定した前記送金電文データに含まれる送金額を、前記予約データに含まれる受取人口座に入金させるための処理を実行するステップとを実行する、
ことを特徴とする被仕向送金受取方法。
【請求項１】
金融機関の外国為替業務における被仕向送金受取システムであって、
外為処理ホストコンピュータとネットバンキング受付用コンピュータと勘定系ホストコンピュータとがデータ交信可能に接続されており、
前記ネットバンキング受付用コンピュータは、被仕向送金を受け取る顧客の顧客端末からインターネットを介して被仕向送金に対応する着金予約情報を受付ける着金予約受付部を備え、
前記外為処理ホストコンピュータは、
前記ネットバンキング受付用コンピュータから前記受付けた着金予約情報を受信し、着金予約ＤＢに予約データとして登録する着金予約登録部と、
送金電文を海外の送金側システムから受信する電文受信部と、
前記受信した送金電文を解析し、所定の項目ごとに送金電文データにマッピングする接受記録・検証部と、
前記送金電文データと着金予約ＤＢに登録された前記予約データを比較し、一致又は不一致を判定する電文マッチング部と、
前記電文マッチング部によって前記予約データと一致すると判定した前記送金電文データに含まれる送金額を、前記予約データに含まれる受取人口座に入金させるための入金要求を前記勘定系ホストコンピュータに送信する入金処理部を備える、
ことを特徴とする被仕向送金受取システム。
【請求項２】
前記外為処理ホストコンピュータは、前記送金電文が、前記予約データに含まれた支払指定日よりも遅れて到着した場合には、前記顧客の指定により遅延通知を前記顧客端末に送信する、ことを特徴とする請求項１に記載の被仕向送金受取システム。
【請求項３】
前記電文マッチング部は、前記送金電文データに含まれる送金額が前記予約データに含まれる送金額よりも少ない場合であっても、その差額が前記顧客の指定した許容範囲内であれば前記入金を実行させる、ことを特徴とする請求項１に記載の被仕向送金受取システム。
【請求項４】
前記着金予約情報には、取引毎に変動する変動項目と取引毎に変動しない非変動項目に分けて前記顧客が前記着金予約情報の項目を登録する手段を有する、ことを特徴とする請求項１に記載の被仕向送金受取システム。
【請求項５】
前記顧客が特定の商品又はサービスの代金請求の際に、複数の送金人に対して、一定の送金額を一の受取人口座宛に受け取ることを請求する場合において、前記着金予約登録部は、一の前記予約データを前記複数の送金人からの複数の送金電文データに対応付けできる情報を付加し、前記着金予約ＤＢに格納することを特徴とする、請求項１に記載の被仕向送金受取システム。
【請求項６】
電文マッチング部は、前記複数の送金人からの送金電文データを前記一の予約データに対応させる場合において、前記送金電文データ及び前記予約データに含まれる送金人口座を仮想送金人口座であると判断した場合、前記仮想送金人口座が同一である複数の送金電文データを前記予約データの比較対象とし、送金人口座の一致または不一致を判定する、ことを特徴とする請求項５に記載の被仕向送金受取システム。
【請求項７】
データ交信可能に接続された複数のコンピュータで構成された金融機関の外国為替業務システムにおける被仕向送金受取方法であって、
前記複数のコンピュータのうちのいずれかのコンピュータが、
被仕向送金を受け取る顧客の顧客端末からインターネットを介して被仕向送金に対応する着金予約情報を受付けるステップと、
前記受付けた着金予約情報を受信し、着金予約ＤＢに予約データとして登録するステップと、
送金電文を海外の送金側システムから受信するステップと、
前記受信した送金電文を解析し、所定の項目ごとに送金電文データにマッピングするステップと、
前記送金電文データと着金予約ＤＢに登録された前記予約データを比較し、一致又は不一致を判定するステップと、
前記判定するステップによって前記予約データと一致すると判定した前記送金電文データに含まれる送金額を、前記予約データに含まれる受取人口座に入金させるための処理を実行するステップとを実行する、
ことを特徴とする被仕向送金受取方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【公開番号】特開２０１３−３３４０８（Ｐ２０１３−３３４０８Ａ）
【公開日】平成２５年２月１４日（２０１３．２．１４）
【国際特許分類】
【出願番号】特願２０１１−１６９６１１（Ｐ２０１１−１６９６１１）
【出願日】平成２３年８月２日（２０１１．８．２）
【出願人】（３０２０６４７６２）株式会社日本総合研究所 (367)
【公開日】平成２５年２月１４日（２０１３．２．１４）
【国際特許分類】
【出願日】平成２３年８月２日（２０１１．８．２）
【出願人】（３０２０６４７６２）株式会社日本総合研究所 (367)
[ Back to top ]