JP2005107605A - 金融機関における被仕向電文の処理方法及び処理システム - Google Patents

Abstract

【課題】 振込依頼に際して金融機関が受信する被仕向電文の処理を効率的に行える方法及びシステムを提供する。
【解決手段】 被仕向電文の仕向元である他の金融機関から受け取った被仕向電文に含まれる振込先の口座名義及び口座番号の情報を、口座名義及び口座番号の情報を予め格納したマスターファイルの情報とマッチングさせて振込処理の可否を判定する振込可否判定手段（被仕向電文処理部２６）と、振込不能と判定された場合に、前記被仕向電文から前記仕向元の金融機関に対する照会電文の出力要否を判別するための照会要否判別情報２２を抽出したかに基づいて、当該照会電文の出力要否を判別する照会電文出力要否判別手段（被仕向電文処理部２６）と、照会電文出力要と判別した場合に、振込不能と判定した理由を表示した照会電文を生成して前記仕向元金融機関に出力する通信電文送受信部２９とを備えた。
【選択図】 図２

Description

本発明は、金融機関において、他の金融機関から受付けた被仕向電文・照会電文等を効率的に処理する方法及びシステムに関する。

金融機関における主要業務の一つである為替取引に電信為替がある。この電信為替取引においては、主として仕向電文、照会電文、依頼・回答電文という３種の通信電文の処理が行われる。

仕向電文は、振込や送金の仕向（発信元）となる金融機関（以下「仕向機関」と言う）が生成して被仕向（発信先）の金融機関（以下「被仕向機関」と言う）に送信する通信電文である。この仕向電文は、受信した被仕向機関から見れば被仕向電文となる。被仕向機関は、この被仕向電文に含まれる口座番号、口座種別、口座名義の情報に基づいて資金の振込処理を行う。

また、照会電文は、被仕向機関で被仕向電文について口座名義の相違等の理由によって振込不能となった（振込エラーが発生した）場合に、口座番号等が正しいかを照会するために被仕向機関が生成し仕向機関に送信する通信電文である。この照会電文を受信した仕向機関は、照会内容を振込の依頼者（顧客）に電話等で確認する。そして、仕向機関が口座名義等を修正して被仕向機関に送信するのが依頼・回答電文である。

このような通信電文の処理方法として、例えば、以下の特許文献に開示された事項が参考となる。

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

ところで、前記通信電文は、国内のほとんどの銀行が加盟している全銀ネットを通じて送受信されている。この全銀ネットで規定されている通信電文は基本的にフリーフォーマットであり、電文に記載する文言も統一されていないため、受信した通信電文の処理は仕向機関、被仕向機関の双方にとって非常に煩雑な業務となっている。例えば、被仕向電文の処理においては、振込エラーが発生した場合に被仕向電文のどの情報が間違っていたのかを自動判定することができない。そのため、被仕向電文の受信票を全て印刷して担当者が電文に含まれている情報に基づいて振込エラーの原因を特定しなければならない。そして、このようにして特定した振込エラーの理由を被仕向機関が独自に定めた文言で記載した照会電文を作成して仕向機関に送信する。

また、被仕向電文の中には、振込エラーの場合に被仕向機関からの照会を受付けず、直ちに組戻（依頼の撤回による返金）を要求するものもある。このような組戻を要求する被仕向電文は、被仕向電文毎に設定されている場合があるため、金融機関毎等の画一的な処理はできない。そのため、この組戻しの要否も受信票を印刷して担当者が目視で判断している。

このように、通信電文の処理は全て人手に頼らざるを得ないため非効率で高コストの一因となっている。

一方、現金自動預払機（ＡＴＭ）を利用した振込や送金においては、被仕向機関では上記のような振込処理不能時の対応は発生しない。すなわち、顧客がＡＴＭに振込先の口座番号を入力すると対応する口座名義の情報や名義人相違等の理由がＡＴＭ画面上に直ちに表示されるようになっている。そのため、顧客が確認した正確な振込先の情報だけが被仕向機関に送信されることになり、被仕向機関で振込エラーが発生することはない。このようなＡＴＭを利用した振込等は、自行内に限らず、例えば都市銀行が提携するＢＡＮＣＳ（BANks Cash Service）や地方銀行が提携するＡＣＳ（All Chigin Service）のような個々の業態毎のシステムによって他の金融機関との間でも可能になっている。

しかしながら、提携外の他の金融機関への振込等は、従来通り店頭窓口で顧客が帳票に必要事項を記入し行員が帳票を事務センターにＦＡＸ等で送信する帳票方式で行うしかない。この帳票方式では、仕向機関は帳票の記載内容（仕向情報）を送信前に被仕向機関に確認することはしないため、上記のような被仕向電文の処理が日常的に行われている。

また、上記ＡＴＭからの振込は、入力された口座番号に対応した口座名義をＡＴＭ画面上に表示して依頼人の確認を促すようにしているためセキュリティ上の問題がある。すなわち、口座番号をランダムに入力した場合でも対応する口座名義が表示されてしまい、顧客情報の流出につながる。特に、インターネット上で振込等の依頼を受け付けるネットバンクでは、時間や場所の制約を受けずに振込を依頼できることから、ＡＴＭと同じように口座名義を表示して確認を促す様にすると、顧客情報を大量に不正取得されるおそれがある。

本発明は上記の課題を鑑みてなされたもので、資金の振込依頼に際して金融機関が受信する被仕向電文の処理を効率的に行える方法及びシステムを提供することを目的とする。

本発明の第１の主要な観点によれば、金融機関の特定の口座に対する他の金融機関からの資金の振込依頼に際して、当該他の金融機関から受け取った振込先の口座名義及び口座番号の情報を含む被仕向電文をコンピュータシステムによって処理する方法であって、
前記被仕向電文に含まれる振込先の口座名義及び口座番号の情報を、口座名義及び口座番号の情報を予め格納したマスターファイルの情報とマッチングさせて振込処理の可否を判定する振込可否判定工程と、振込不能と判定された場合に、前記被仕向電文から所定の判別情報を抽出したかに基づいて、前記他の金融機関に対して口座名義及び／若しくは口座番号が正しいかを照会するための照会電文の出力要否を判別する照会電文出力要否判別工程と、照会電文の出力要と判別した場合に、前記振込不能と判定した理由を含む照会電文を生成して前記他の金融機関に出力する照会電文出力工程とを備えたことを特徴とする方法が提供される。

このような構成によれば、被仕向電文の振込処理の可否の判断、振込不能の場合の照会電文の生成要否の判断、及び照会電文生成要の場合の照会電文の出力までを人手を介さずに一連の処理で実行するようにした。例えば、被仕向電文の中で振込処理可能なものは振込処理を実行させ、振込不能なもののうち照会電文を送信する必要があるものは照会電文を生成して仕向機関に送信し、送信する必要がないものは受信票を出力して担当者の目視による判断に移行するといった処理が可能になる。これにより、被仕向機関が受信した全ての被仕向電文を自動処理できるようになる。

また、本発明の第２の主要な観点によれば、金融機関の特定の口座に対する他の金融機関からの資金の振込依頼に際して、当該他の金融機関から受け取った振込先の口座名義及び口座番号の情報を含む被仕向電文を処理するシステムであって、前記被仕向電文に含まれる振込先の口座名義及び口座番号の情報を、口座名義及び口座番号の情報を予め格納したマスターファイルの情報とマッチングさせて振込処理の可否を判定する振込可否判定手段と、振込不能と判定された場合に、前記被仕向電文から所定の判別情報を抽出したかに基づいて、前記他の金融機関に対して口座名義及び／若しくは口座番号が正しいかを照会するための照会電文の出力要否を判別する照会電文出力要否判別手段と、照会電文の出力要と判別した場合に、前記振込不能と判定した理由を含む照会電文を生成して前記他の金融機関に出力する照会電文出力手段とを備えたことを特徴とするシステムが提供される。

このような構成によれば、上記した第１の主要な観点における被仕向電文の処理方法を好適に実行できるシステムを得ることができる。

本発明によれば、被仕向機関が受信した全ての被仕向電文を人手を介さずに自動判定できるようになるので、被仕向電文の処理効率を飛躍的に向上させることができる。また、従来は照会電文の送信要否等も担当者が判断していたため、判断結果を上司や専門の担当者等が精査する必要があり、業務効率を一層低下させていた。これに対して本発明は、照会要否や受信票の出力要否に際して人の判断を最小限にできるため、判断結果の精査も低減できる。その結果、人的負荷をさらに軽減でき、業務効率のより一層の向上とコストダウンを達成できることになる。

なお、この発明の他の特徴と顕著な効果は、次の発明を実施するための最良の形態の項の記載と添付した図面とを参照することで、より明確に理解される。

以下、本発明を実施するための最良の形態を図面に基づき説明する。この実施形態は、顧客が自己の口座から他の金融機関の特定の口座に振込を依頼する場合の例である。

図１は、銀行２に設置された電文処理システム１の概略構成を示す図である。この電文処理システム１は、顧客３から振込を依頼された他の銀行４の通信端末５から、全銀ネットＢＮの専用回線を通じて被仕向電文を受付け、顧客情報マスターファイル６に登録された口座番号等に基づいて振込可否を判断し、勘定系システム７に入金を指示するものである。また、振込不能の場合には、前記他の銀行４に対する照会電文を生成して送信するものである。

前記電文処理システム１は、銀行２内に設置された１又は２台以上のコンピュータシステム（サーバ）によって構成されており、ＦＥ（Frontend）サーバ８、図示しないファイアウォールやルータを介して前記全銀ネットＢＮ上に公開されている。なお、この銀行２内には前記電文処理システム１や勘定系システム７以外に種々の業務処理システムが設置され、ＬＡＮ、ＷＡＮ等によって相互に接続されているが、これらのシステムの詳細説明は省略する。また、以下の説明においては、便宜上、顧客３が口座を保有する他の銀行４を仕向機関、振込先の口座がある銀行２を被仕向機関と称する。

次に、電文処理システム１の具体的な構成を、図２〜図７を参照して説明する。

図２に示すように、この電文処理システム１は、ＣＰＵ１０、ＲＡＭ１１、モデム等の通信デバイス１２、入出力装置１３が接続されたバス１４に、データ格納部１５とプログラム格納部１６とを備えて構成されている。

データ格納部１５は、電文情報格納部１８と判定情報テーブル１９とを備えている。

前記電文情報格納部１８は、受信した通信電文や後述する修正候補２０のデータを、仕向機関４が発行した発信番号２１に関連付けて登録するものである。この発信番号２１は、仕向機関４が被仕向電文を生成・発信する時に採番したユニークな番号であり、被仕向電文に含められるものである。被仕向機関２が被仕向電文を受信した場合に発行する受信番号に関連付けて登録しても良い。

前記判定情報テーブル１９は、被仕向電文について振込エラーが発生した時に仕向機関４に照会電文を送信するかを判別するための照会要否判別情報２２と、照会要の場合に口座番号や口座名義を自動修正するための誤記修正パターン２３と、仕向機関４において照会電文の照会理由を判定するための照会理由判定情報２４とを登録するものである。

ここで、照会要否判別情報２２としては、例えば「ショウカイフノウ」「アツカイ」「クミモドシ」などの特定の文字列が含まれる。仕向機関４の中には、被仕向機関２で振込エラーが発生した場合に口座名義等の照会を受付けず、直ちに振込依頼に係る資金の返金（組戻）を要請する場合がある。これは、仕向機関４が顧客３への照会業務を省略したり、また複数の銀行や支店、企業等からの振込依頼を一括処理する処理センターからの通信電文については、処理センターでは照会電文に対する回答ができないことから、照会の受付を拒否するメッセージが記入される場合がある。そのため、被仕向電文のフリーフォームの欄（備考等）に、「ショウカイフノウノ バアイハ クミモドシ コウ」「○○シテン アツカイ」と記載されている場合には、上記登録文字列を含んでいるため、照会電文は生成されない。このような電文の文章は、銀行や前記処理センター毎に予め決められていることがほとんどであるため、このような電文のパターンを銀行等の識別情報に関連付けて登録しておく。これにより、照会要否の判定精度を高めることができる。

また、この照会要否判別情報２２は、被仕向機関２において仕向機関４からの依頼・回答電文について入金処理の可否を判別する入金可否判別情報としても利用される。すなわち、依頼・回答電文に上記の文言が含まれている場合には、仕向機関４が顧客３に照会理由を通知できなかったり、顧客３が振込依頼を撤回したと判断し、組戻し等の処理を実行する。

前記口座名義・番号誤記修正パターン２３のうち、口座番号の誤記修正パターンとしては、「正規の7桁の口座番号の先頭のｎ桁の数字を削除する」という修正ルールが登録されている。このｎ桁の数字は支店番号や銀行の識別番号を考慮して決定できる。例えば、支店番号であれば通常は３桁であるが、振込先がネットバンクの口座であると本店・支店の区別がなく一律００１であることが多いため、口座番号の先頭に１を追加される場合がある。そのため、この誤記修正パターンとしては、「被仕向電文の口座番号が８桁か１０桁になっている場合に先頭のｎ桁（１桁か３桁）を削除する」というルールが登録される。また、「数字以外の情報（／−：などの記号や文字、空白等）を削除する」というルールを登録しておいても良い。

次に、口座名義の誤記修正パターンとしては、例えば図３に示すように、口座名義の末尾の「サマ」「アテ」「ドノ」「オンチュウ」の削除、先頭若しくは末尾の数字・記号の削除、長音表記の相互修正（オーとオオ）、「ジ」と「ヂ」、「ズ」と「ヅ」、「シブ」と「シテン」と「エイギョウショ」の相互修正等の複数のパターンが登録されている。

前記照会理由判定情報２４としては、例えば図４に示すように、照会理由、すなわち振込不能理由毎に判別情報が登録されている。例えば、照会電文のフリーフォームの欄に「メイギソウイ」や「メイソウ」の文字列が含まれていれば、照会理由は「口座名義の相違」であると判別される。

前記プログラム格納部１６は、メインプログラム２５の他、主として、被仕向機関２における電文処理を実行する被仕向電文処理部２６及び依頼・回答電文処理部２７と、仕向機関４における電文処理を実行する照会電文処理部２８と、両者に共通する処理を実行する通信電文送受信部２９、受信票出力部３０及び入出金処理部３１とを備えている。以下においては、まず共通する機能部を説明し、次に被仕向電文処理部２６、依頼・回答電文処理部２７、照会電文処理部２８を順に説明する。なお、仕向機関４における仕向電文の生成部等の本実施形態に関連しない機能部は図示及び説明を省略する。

前記通信電文送受信部２９は、全銀ネットＢＮを通じて他の金融機関（仕向機関４及び被仕向機関２）との間で通信電文を送受信し、また受信した通信電文を前記電文情報格納部１８に発信番号に関連付けて格納する機能を有する。受信票出力部３０は、通信電文について所定の処理を実行した後で、オペレータの確認用若しくは保存用に図１１及び図１２に示すような受信票を印刷したり電子メールに添付して送信する機能を奏する。この受信票については後述する。入出金処理部３１は、勘定系システム７への入金指示や別段預金口座への入出金処理を実行するものである。

ここで、前記通信電文送受信部２９は、仕向機関４において仕向電文を発信する際に、例えば顧客３の口座番号をスクランブルして生成したユニークな発信番号をこの電文に組み込む機能も備えている。また通信電文送受信部２９は、受信した通信電文の種別を判別し、この種別に応じて前記各電文処理部２６〜２８に電文の情報を受け渡すものである。

次に、被仕向電文処理部２６は、被仕向機関２において、前記通信電文送受信部２９が仕向機関４から被仕向電文を受信した場合に所定の処理を実行するものである。

具体的には、図５に示すように、この被仕向電文処理部２６は、被仕向電文と前記顧客情報マスターファイル６とをマッチングさせて振込の可否を判定する入金可否判定部３５と、被仕向電文から前記照会要否判別情報２２を抽出したかに基づいて仕向機関４への照会要否を判別する照会要否判別部３６と、振込不能の場合に前記口座名義・番号誤記修正パターン２３を適用して口座番号及び口座名義を修正する口座番号／口座名義・番号修正処理部３７と、図３に示す判定条件に従って振込不能の理由を判定する振込不能理由判定部３８と、振込不能理由を表示した照会電文を生成して仕向機関４に送信する照会電文生成部３９と、この照会電文に係る口座番号で前記顧客情報マスターファイル６を検索して対応する口座名義を抽出し、前記発信番号２１に関連付けて電文情報格納部１８に登録する修正候補登録部４０とを有する。

ここで、前記入金可否判定部３５は、前記口座名義・番号修正処理部３７が修正した被仕向情報に基づいて繰り返し入金可否を判定するものである。例えば、入金不能の場合に、口座番号の桁数を調整した時点で再度入金可否を判定し、それでも入金不能の場合に、口座名義の「サマ」「アテ」を削除した時点で３度目の入金可否判定を行い、それでも入金不能の場合に、口座名義の先頭若しくは末尾の数字や記号を削除した時点で４度目の入金可否判定を行う。修正処理の優先順位は、誤記が発生する頻度（確率）や処理速度に基づいて決定するのが好ましい。例えば、処理速度を優先する場合には、文字列の解析・修正よりも数字の検索・修正の方が高速に処理できることから、まず口座番号の桁数の修正を行ってから口座名義の修正を行うことになる。また、この優先順位は、被仕向電文に含まれる仕向機関４の識別番号や支店名に基づいて仕向機関４が顧客３からの振込依頼を受け付けたチャンネルがネットバンキングか窓口かを判別し、判別結果に基づいて変更しても良い。または、仕向機関４毎に優先順位を変更することもできる。これにより、修正の精度の向上と処理の高速化が期待できる。

次に、前記依頼・回答電文処理部２７は、被仕向機関２において、後述する依頼・回答電文生成部４９から送信された依頼・回答電文を前記通信電文送受信部２９が受信した場合に所定の処理を実行するものである。

具体的には、この依頼・回答電文処理部２７は、図６に示すように、受信した依頼・回答電文の発信番号２１に基づいて電文情報格納部１８から照会理由を抽出して照会理由を判定する照会理由判定部４１と、依頼・回答電文から前記照会要否判別情報を抽出したかに基づいて入金処理の要否を判別する入金処理要否判別部４２と、前記発信番号２１に基づいて電文情報格納部１８から修正候補２０を抽出する修正候補抽出部４３とを備えている。

ここで、前記照会理由判定部４１は、照会理由が「口座名義相違」である場合に入金処理要否判別部４２を起動させるものである。これは、照会理由が「名義相違」以外（該当口座なし等）である場合には、前記修正候補２０とマッチングさせても入金処理が不能になることが確実であることから、受信票を印刷してオペレータの判断に委ねる趣旨である。なお、被仕向電文について上記口座番号若しくは口座名義の修正処理を行わずに照会電文を送信した場合には、照会理由に拘らず、この時点で口座番号等の自動修正を行って入金可否を判定するようにしても良い。

また、前記照会電文処理部２８は、仕向機関４において、被仕向機関２の照会電文生成部３９から送信された照会電文を前記通信電文送受信部２９が受信した場合に所定の処理を実行するものである。

具体的には、この照会電文処理部２８は、図７に示すように、受信した照会電文から前記照会理由判定情報２４を抽出したかに基づいて振込不能理由を判定する振込不能理由判定部４５と、照会理由判定情報２４を抽出できなかった場合に所定の入力インタフェースを生成・表示してオペレータが判定した不能理由の入力を受付ける振込不能理由受付部４６と、振込不能理由判定部４５若しくは振込不能理由受付部４６から取得した振込不能理由を表示した仕向情報確認メッセージを作成して顧客３に通知する振込不能理由出力部４７と、顧客３から修正情報を取得する修正情報取得部４８と、修正情報を備考欄等に記載した依頼・回答電文を生成する依頼・回答電文生成部４９とを備えている。

ここで、顧客３とのメッセージや修正情報の受け渡しは、電子メール、ＦＡＸ、ＷＥＢ上の顧客専用ページ等の何れを利用しても良い。

上記の各構成要素は、実際にはコンピュータシステムの記憶媒体に確保された一定の領域及びこの領域にインストールされたプログラムであり、前記ＣＰＵ１０によってＲＡＭ１１上に呼び出されて実行されることで、ＯＳ（オペレーションシステム）と協働してこの発明の機能を奏するようになっている。

次に、電文処理システム１の詳細な機能を実際の動作と共に、図８〜図１０を参照して説明する。なお、これらの図のＳ１〜Ｓ３９は処理順序を示す符号であり、以下の説明のステップＳ１〜Ｓ３９に対応する。

まず、図８に示す被仕向電文の処理工程を説明する。この処理は、主として前記被仕向電文処理部２６によって実行されるものである。

この処理は、前記通信電文送受信部２９が仕向機関４から被仕向電文を受信することによって開始される。まず、入金可否判定部３５が前記被仕向電文から口座番号・口座名義の情報を抽出し（ステップＳ１）、前記顧客情報マスターファイル６とマッチングさせることで入金可否を判定する（ステップＳ２）。入金可能と判定されると（ステップＳ２のＹｅｓ）、前記入出金処理部３１が被仕向電文の情報を前記勘定系システム７に伝送して自動入金処理を実行する（ステップＳ３）。以降の説明における「自動入金処理」も同様に行われる。

一方、入金処理不能と判定された場合（ステップＳ２のＮｏ）、前記入出金処理部３１によって被仕向電文に係る資金が被仕向機関２の別段預金口座に一旦入金された後（ステップＳ４）、前記照会要否判別部３６が起動し被仕向電文から照会要否判別情報２２の文字列を抽出したかに基づいて照会要否を判別する（ステップＳ５）。ここで照会要と判定されると（ステップＳ５のＮｏ）、前記口座番号・口座名義・番号修正処理部３７が起動して、まず前記口座番号の誤記修正パターン（２３）を適用して口座番号を修正する（ステップＳ６、Ｓ７）。具体的には、口座番号が８桁若しくは１０桁である場合に、先頭の１桁若しくは３桁の数字を削除して口座番号を７桁に修正する。

次いで、前記振込不能理由判定部３８が起動し、顧客情報マスターファイル６から修正された７桁の口座番号を検索し、該当する口座が検索されない場合には（ステップＳ８のＮｏ）、振込不能理由を「該当口座なし」と判定する（ステップＳ９）。該当する口座が検索された場合には（ステップＳ８のＹｅｓ）、前記入金可否判定部３５が再度入金可否を判定する（ステップＳ１０）。ここで再度入金処理不能と判定された場合には（ステップＳ１０のＮｏ）、前記口座名義・番号修正処理部３７が口座名義の誤記修正パターン（２３）を適用して口座名義の修正を実行する（ステップＳ１１、Ｓ１２）。前記のように、口座名義の誤記修正パターンは複数登録されており、全ての修正パターンについて修正処理が実行されたかに基づいて口座名義の修正可否が判断される（ステップＳ１１）。このルーチン内で入金可と判定された時点で前記ステップＳ３と同様に自動入金処理が実行される（ステップＳ１３）。また、このような修正処理によっても入金不能と判定された場合は、前記振込不能理由判定部３８によって振込不能理由が「名義相違」と判定される（ステップＳ１４）。

一方、ステップＳ５で「ニュウキンフノウ」「クミモドシ」等の文字列を抽出し照会不要と判別されると（ステップＳ５のＹｅｓ）、、受信票出力部３０によって振込不能理由（「該当口座なし」「名義人相違」等）が表示された受信票が印刷される（ステップＳ１５）。印刷された受信票についてオペレータが被仕向電文の内容・振込不能理由・照会要否等を目視で確認し、所定の処理を行う。この場合の受信票を図１１に示す。

上記の処理によって振込不能理由が判定されると、前記照会電文生成部３９が振込不能理由を表示した照会電文を生成して仕向機関４に送信する（ステップＳ１６）。また、この照会電文生成部３９は、送信した照会電文を前記電文情報格納部１８に格納する（ステップＳ１７）。

ついで、前記修正候補登録部４０が起動し、照会電文に係る口座番号若しくは口座名義で前記顧客情報マスターファイル６を検索して対応する口座名義若しくは口座番号を抽出し、修正候補２０として前記電文情報格納部１８に登録しておく（ステップＳ１８）。例えば、「名義相違」を理由に仕向機関に照会電文を送信した場合は、口座番号は正しいものと推定して、この番号に対応する口座名義の情報を顧客情報マスターファイル６から抽出する。また、「該当口座なし」を理由に照会電文を送信した場合は、顧客情報マスターファイル６に該当する口座名義が登録されていれば、この口座名義が正し喪能登推定して、該当する口座番号を修正候補として登録する。さらに、各桁の数字が１字違いの口座番号についても修正候補として登録するようにしても良い。このような修正候補を複数登録しておくことにより、後述する依頼・回答電文の自動処理（自動入金処理）の精度をより向上させることができるようになる。

次に、図９の照会電文の処理工程を説明する。この処理は、主として前記照会電文処理部２８（図７）によって実行されるものである。

まず、前記通信電文送受信部２９が被仕向機関２から照会電文を受信すると（ステップＳ２０）、前記振込不能理由判定部が起動して照会電文から照会理由判定情報２４の文字列を抽出して振込不能理由を判定する（ステップＳ２１、Ｓ２２）。判定された理由が１つであれば（ステップＳ２３のｎ＝１）、その理由をそのまま振込不能理由であると判断する（ステップＳ２４）。

判定された理由が２つの場合（ステップＳ２３のｎ＝２）、その理由の中に「該当口座なし」を含むかを判別し（ステップＳ２５）、含む場合はそれ以外の例えば「名義相違」等を振込不能理由を判断する（ステップＳ２６）。これに対して、不能理由が３つ以上の場合（ステップＳ２３のｎ≧３）及び、「該当口座なし」以外の振込不能理由が複数含まれている場合は（ステップＳ２５のＮｏ）、前記振込不能理由判定部４５は、判定不能と判断してオペレータによる処理に移行する。前記ステップＳ２１で判定情報を抽出できなかった場合（ステップＳ２１のＮｏ）も同様である。

このオペレータによる処理は、まず、前記受信票出力部３０が照会電文を印刷し（ステップＳ２７）、ついで振込不能理由受付部４６が振込不能理由入力用インタフェースを生成してオペレータの端末に表示させる（ステップＳ２９）。また、この振込不能理由受付部４６は、印刷された受信票についてオペレータが判断した振込不能理由をこの入力インタフェースを通じて取得する（ステップＳ３０）。

このようにして、全ての照会電文について振込不能理由を取得すると、前記振込不能理由出力部４７が起動してこの振込不能理由を顧客３に通知する（ステップＳ３１）。また、顧客３からの回答（口座名義の修正や組戻しの依頼等）は前記修正情報取得部４８が受付けて依頼・回答電文生成部４９に受け渡す。依頼・回答電文生成部４９は、照会電文に含まれる仕向情報と顧客から取得した修正情報、発信番号等を結合して依頼・回答電文を生成して前記通信電文送受信部２９に受け渡し、被仕向機関２に送信する（ステップＳ３３）。

次に、図１０を参照して依頼・回答電文の処理工程を説明する。この処理は、主として前記依頼・回答電文処理部２７によって実行されるものである。

まず、前記通信電文送受信部２９が仕向機関４から依頼・回答電文を受信すると（ステップＳ３４）、前記入金処理要否判別部４２が所定の文字列をこの電文から抽出したかに基づいて入金処理の要否を判別する（ステップＳ３５）。所定の文字列は、前記判定情報テーブル１９に登録された照会要否判別情報２２を利用できる。依頼・回答電文から「クミモドシ」などの所定の文字列を抽出した場合は、この入金処理要否判別部４２は自動入金処理不能と判定して、前記受信票出力部３０に受信票の印刷を指示する（ステップＳ３６）。印刷された受信票に基づいてオペレータが個別処理を行う。

また、入金処理要と判別した場合（ステップＳ３５のＹｅｓ）、前記被仕向電文処理部２６の入金可否判定部３５が起動して、依頼・回答電文から口座番号・振込金額及び修正された口座名義を抽出して入金可否を判定する（ステップＳ３７〜Ｓ３９）。この時、前記修正候補抽出部４３がこの電文の発信番号に基づいて前記電文情報格納部１８から修正候補２０を抽出して入金可否判定部３５に受け渡す（ステップＳ３８）。入金処理可能と判定された場合は（ステップＳ３９のＹｅｓ）、自動入金処理に移行する。ここで、依頼・回答電文に含まれる回答は被仕向電文以上に記載形式が多様であるため、この電文から修正された口座番号等の所望の情報を確実に抽出することが困難である場合も予想される。そこで、入金処理可能と判定した場合でも、直ちに自動入金処理を実行せず、「自動入金処理可」と表示した受信票を印刷してオペレータが個別に確認するようにしても良い。この場合の受信票の例を図１２に示す。

前記ステップＳ３９で入金処理不能と判定された場合は、前記ステップＳ３６で受信票を印刷してオペレータによる個別処理に移行する。なお、電文情報格納部１８に修正候補２５が複数登録されている場合には、入金処理可能と判定されるまでステップＳ３８、Ｓ３９の処理を繰返し実行する。この場合、複数の修正候補２５を照会理由（「名義相違」や「該当口座なし」等）に関連付けて登録しておき、前記照会理由判定部４１で判定した照会理由に基づいて１又は２以上の修正候補を抽出するようにしても良い。これにより、種々の修正パターン毎に修正候補２５を登録しておいた場合でも、依頼・回答電文の情報を全ての修正候補とマッチングさせる必要がなく、入金処理可否の判定を素早く行うことができる。従って、自動入金処理の精度向上と高速処理とを同時に実現できる。

ここで、上記実施形態で出力される受信票について、図１１及び図１２を参照して簡単に説明する。

まず図１１は、前記図８のステップＳ１５で出力される被仕向電文の受信票の例であり、被仕向電文から照会不要と判別される文字列を抽出した場合に出力される。図中に破線で示した部分がフリーフォームの欄５０であり、ここに「ニュウキンフノウ」の文字列５１の記載されている。このような文字列を抽出した場合は、上記した様に、口座名義や口座番号の修正、照会電文の生成等を行わずに、「補足情報（自動処理結果）」の欄５２に「対象外」、「自動判定表示」の欄５３に「名義相違」を夫々表示した受信票が自動出力されてオペレータに回付される。

次に、図１２は、図１０のステップＳ３９で「自動処理可」と判定された場合、すなわち被仕向電文では自動処理できなかったが、仕向機関からの修正情報によって振込の自動処理が可能になった場合の依頼・回答電文の受信票の例である。この例では、当初の振込先が、「補足情報（受取人）」の欄５４及び「原電文受信日 原電文口座番号」の欄５５に表示されているように、「口座名義：（カ）マンチェスターユナイテッド」「口座番号：フ７０１００３３」であったものを、この依頼・回答電文の「受取人名」の欄５６に記載されているように、口座番号はそのままで、口座名義を「（カ）レアルマドリード」に訂正するよう指示されている。このような訂正依頼の文字列は、フリーフォームの欄５０のどこに記載されていても抽出され、同様に処理される。また、この例では、照会電文を送信する際に、原電文口座番号に対応する口座名義として「カ.レアルマドリード」が前記顧客情報マスターファイル６から検索された修正候補２０が、「補正口座番号 補正口座カナ名」の欄５７に表示されている。これにより、前記入金可否判定部３５が依頼・回答電文の情報と修正候補２０とをマッチングさせて入金可と判定した結果をオペレータが目視で検証する際の有益な情報を提供できる。

なお、この発明は上記の実施形態に限定されるものではなく、発明の要旨を変更しない範囲で種々変形可能である。

例えば、上記実施形態においては、振込処理を例に取って説明したが、本発明は振込取引に際して送受信される他の通信電文の処理にも適用できるものである。また通信電文の種別に応じた判別情報や誤記修正パターンを電文情報格納部１８に登録しておき、受信した通信電文で指示された処理を実行できない場合に、夫々の判定情報に基づいて照会要否等を判定するようにするのが好ましい。

また、仕向機関４および被仕向機関２は、何れも、ＷＥＢ上で顧客３からの振込依頼を直接受付け可能なネットバンク（専業・兼業）であっても良い。この場合に、自行内の口座への振込を受付ける場合に本システム１の機能を利用できる。例えば、顧客３の通信端末から入力された口座番号および／若しくは口座名義が間違っている場合に、前記口座名義・番号誤記修正パターン２３を適用して修正した情報を顧客３の通信端末に返信することができる。また、「該当する口座がありません」といったメッセージを出力すると共に、前記修正候補登録部４０がマスターファイル６から口座番号で検索した修正候補を登録しておき、この修正候補を利用することで顧客３から再入力された情報とのマッチングを瞬時に実行できる。

また、仕向機関４がネットバンキングで振込を受け付けた場合は、被仕向機関２からの照会電文について顧客３への情報照会・回答の受領を全てネット上で行えるため、照会電文の処理を効率的かつ瞬時に行えるようになる。また、ネットバンキングの場合は、現金振込はあり得ず、全て自行の口座からの振込であるため、振込不能の場合の組戻に際して顧客口座を特定する工程が不要で返金処理を効率的かつ瞬時に行えることになる。

本発明の実施形態に係る電文処理の概要を示す図。 同、電文処理装置の構成を示すブロック図。 口座名義の誤記修正パターンの一例を示す図。 照会理由判定情報の一例を示す図。 被仕向電文処理部の構成を示すブロック図。 依頼・回答電文処理部の構成を示すブロック図。 照会電文処理部の構成を示すブロック図。 被仕向電文の処理工程を示すフローチャート。 照会電文の処理工程を示すフローチャート。 依頼・回答電文の処理工程を示すフローチャート。 出力される被仕向電文の受信票の例を示す図。 出力される依頼・回答電文の受信票の例を示す図。

符号の説明

１…電文処理システム
２…銀行（被仕向機関）
３…顧客
４…銀行（仕向機関）
５…通信端末
６…顧客情報マスターファイル
７…勘定系システム
８…ＦＥサーバ
１５…データ格納部
１６…プログラム格納部
１８…電文情報格納部
１９…判定情報テーブル
２０…修正候補
２１…発信番号
２２…照会要否判別情報
２３…口座名義・番号誤記修正パターン
２４…照会理由判定情報
２５…メインプログラム
２６…被仕向電文処理部
２７…依頼・回答電文処理部
２８…照会電文処理部
２９…通信電文送受信部
３０…受信票出力部
３１…入出金処理部
３５…入金可否判定部
３６…照会要否判別部
３７…口座名義・番号修正処理部
３８…振込不能理由判定部
３９…照会電文生成部
４０…修正候補登録部
４１…照会理由判定部
４２…入金処理要否判別部
４３…修正候補抽出部
４５…振込不能理由判定部
４６…振込不能理由受付部
４７…振込不能理由出力部
４８…修正情報取得部
４９…依頼・回答電文生成部
５０…フリーフォームの欄
５１…文字列（照会要否判別情報）
５２…「補足情報（自動処理結果）」の欄
５３…「自動判定表示」の欄
５４…「補足情報（受取人）」の欄
５５…「原電文受信日 原電文口座番号」の欄
５６…「受取人名」の欄
５７…「補正口座番号 補正口座カナ名」の欄

Claims (13)

1. 金融機関の特定の口座に対する他の金融機関からの資金の振込依頼に際して、当該他の金融機関から受け取った振込先の口座名義及び口座番号の情報を含む被仕向電文をコンピュータシステムによって処理する方法であって、
   前記被仕向電文に含まれる振込先の口座名義及び口座番号の情報を、口座名義及び口座番号の情報を予め格納したマスターファイルの情報とマッチングさせて振込処理の可否を判定する振込可否判定工程と、
   振込不能と判定された場合に、前記被仕向電文から所定の判別情報を抽出したかに基づいて、前記他の金融機関に対して口座名義及び／若しくは口座番号が正しいかを照会するための照会電文の出力要否を判別する照会電文出力要否判別工程と、
   照会電文の出力要と判別した場合に、前記振込不能と判定した理由を含む照会電文を生成して前記他の金融機関に出力する照会電文出力工程と
   を備えたことを特徴とする方法。
2. 請求項１記載の方法であって、
   前記照会電文出力要否判別工程は、金融機関毎に予め設定された所定の判別情報を抽出したかに基づいて照会電文の出力要否を判別するものである
   ことを特徴とする方法。
3. 請求項２記載の方法であって、
   前記照会電文出力要否判別工程は、予め複数の金融機関毎の所定の判別情報を格納した判別情報テーブルから前記他の金融機関について登録されている判別情報を検索し、検索された判別情報を前記被仕向電文から抽出したかに基づいて、照会電文の出力要否を判別するものである
   ことを特徴とする方法。
4. 請求項１記載の方法であって、
   さらに、前記照会電文出力要否判別工程で照会電文の出力不要と判別した場合に、前記振込不能と判定した理由を表示した被仕向電文受信票を出力する受信票出力工程を備えた
   ことを特徴とする方法。
5. 請求項１記載の方法であって、
   さらに、前記振込可否判定工程で振込不能と判定された場合に、被仕向電文に含まれる口座名義及び／若しくは口座番号を所定の修正パターンに従って修正する口座名義／口座番号修正工程を備え、
   この振込可否判定工程は、前記修正済みの口座名義及び／若しくは口座番号の情報を前記マスターファイルの情報とマッチングさせて振込処理の可否を再度判定するものである
   ことを特徴とする方法。
6. 請求項５記載の方法であって、
   前記口座名義／口座番号修正工程は、被仕向電文に含まれる口座番号が所定の桁数を越えている場合に、口座番号の先頭のｎ桁の数字を削除して口座番号を修正する口座番号修正工程を備えた
   ことを特徴とする方法。
7. 請求項５記載の方法であって、
   前記口座名義／口座番号修正工程は、前記被仕向電文に含まれる口座名義が、被仕向電文に含まれる口座番号についてマスターファイルに登録されている口座名義と相違する場合に、当該被仕向電文に含まれる口座名義を所定の口座名義誤記修正パターンに従って修正する口座名義修正工程を備えた
   ことを特徴とする方法。
8. 請求項６及び７記載の方法であって、
   前記口座名義修正工程は、被仕向電文に含まれる口座名義が、前記口座番号修正工程で桁数を修正した口座番号について前記マスターファイルに登録されている口座名義と相違する場合に、当該被仕向電文に係る口座名義を所定の口座名義誤記修正パターンに従って修正するものである
   ことを特徴とする方法。
9. 請求項５記載の方法であって、
   前記口座名義／口座番号修正工程は、異なる修正パターンに従って口座名義及び／若しくは口座番号の修正を複数回実行するものであり、
   前記振込可否判定工程は、口座名義及び／若しくは口座番号の修正が実行される度に当該修正された口座名義及び口座番号に基づいて振込処理の可否を判定するものである
   ことを特徴とする方法。
10. 請求項１記載の方法であって、
    さらに、前記照会電文を出力した他の金融機関から、修正された口座名義及び／若しくは口座番号を含む回答電文を受信した場合に、この回答電文に含まれる口座名義及び口座番号の情報を抽出する口座名義・口座番号抽出工程を備え、
    前記振込可否判定工程は、前記回答電文から抽出した情報に基づいて振込処理の可否を判定するものである
    ことを特徴とする方法。
11. 請求項１０記載の方法であって、
    さらに、前記照会電文出力要否判別工程で照会電文の出力要と判別した場合に、前記被仕向電文に含まれる口座番号で前記マスターファイルを検索してこの口座番号に対応する口座名義の情報を修正候補として修正候補テーブルに登録する修正候補登録工程を備え、
    前記振込可否判定工程は、前記口座名義・口座番号抽出工程で抽出した口座名義及び口座番号の情報を前記修正候補テーブルに登録された修正候補とマッチングさせて振込処理の可否を判定するものである
    ことを特徴とする方法。
12. 請求項１記載の方法であって、
    さらに、被仕向電文に含まれる他の金融機関の識別情報若しくは支店名の情報に基づいて、この金融機関がネットバンキングによって顧客からの振込依頼を受付けたかを判別する工程を備え、
    前記照会電文出力要否判別工程は、他の金融機関がネットバンキングで顧客から振込依頼を受付けたかに基づいて前記抽出すべき所定の判別情報を特定する工程を備えた
    ことを特徴とする方法。
13. 金融機関の特定の口座に対する他の金融機関からの資金の振込依頼に際して、当該他の金融機関から受け取った振込先の口座名義及び口座番号の情報を含む被仕向電文を処理するシステムであって、
    前記被仕向電文に含まれる振込先の口座名義及び口座番号の情報を、口座名義及び口座番号の情報を予め格納したマスターファイルの情報とマッチングさせて振込処理の可否を判定する振込可否判定手段と、
    振込不能と判定された場合に、前記被仕向電文から所定の判別情報を抽出したかに基づいて、前記他の金融機関に対して口座名義及び／若しくは口座番号が正しいかを照会するための照会電文の出力要否を判別する照会電文出力要否判別手段と、
    照会電文の出力要と判別した場合に、前記振込不能と判定した理由を含む照会電文を生成して前記他の金融機関に出力する照会電文出力手段と
    を備えたことを特徴とするシステム。
    

Images