JP7183629B2 - 入金判定システム、入金判定装置、入金判定方法、および、プログラム - Google Patents

Description

本発明は、入金判定システム、入金判定装置、入金判定方法、および、プログラムに関する。

金融機関における振込電文において、振込電文に含まれる受取人名と、振込電文により示される受取人口座の受取人口座名義とが相違する場合、当該振込電文は名義人相違を理由に入金不能となる。入金不能となった振込電文の振込内容は印字され、印字された振込内容に対してオペレータが事務規定に従い読み替えや、口座属性により一致すべき箇所の一致の確認を行うことにより、入金可否が判定される。

上記の読替え、および入金可否の判定を自動的に行うシステムにおいても、事務規定で定められている読替え方法に従って読替えを行い、読替えの結果（一致不一致）に基づき入金可否が判定される。

このようなデータの一致不一致判定に関連する技術は、例えば特許文献１～３に開示されている。

下記特許文献１には、組織名、個人名からなるデータを比較し、部分的な一致によって、一致、不一致を判定する技術が開示されている。

また、下記特許文献２では、番地や号が省略されていても、町名や丁目が一致し、建物名が一致と見なせれば、住所が一致しているとみなす技術が開示されている。

また、下記特許文献３では、オペレータが設定した推論知識を蓄積する機械翻訳装置の技術が開示されている。

特開平９－２３１２３２号公報 特開２００３－１７３３４５号公報 特開平６－３２５０８３号公報

しかしながら、従来の技術では、振込電文に含まれる受取人名と、振込電文により示される受取人口座の受取人口座名義とが相違する場合における入金可否が、全ての文字列の一致不一致でしか自動判定することができなかった。

また、従来技術では、部分的な一致不一致に基づいて判定を行っているが、いずれも、入金判定の精度向上については考慮されていない。

そこで、本発明は、上記問題に鑑みてなされたものであり、本発明の目的とするところは、名義人相違が生じた振込の入金可否の自動判定の利便性をより向上させることが可能な入金判定システム、入金判定装置、入金判定方法、および、プログラムを提供することにある。

上記課題を解決するために、本発明のある観点によれば、受取人の口座番号および受取人名を少なくとも含む振込データを取得する振込データ取得部と、前記口座番号に対応する複数の文字列からなる口座名義を顧客マスタから取得する口座情報取得部と、前記受取人名と前記口座名義を比較し入金判定を行う入金判定部と、前記比較の結果が不一致となった振込データをオペレータに確認させる確認部と、前記口座名義の複数の文字列のうち、前記オペレータに選択され、前記オペレータによる一致判定に使用された、前記受取人名に含まれる文字列と一致する一致文字列の情報を、判定条件として前記口座番号に関連付けて記憶する記憶処理部と、を備える、入金判定システムが提供される。

前記確認部は、前記口座名義の複数の文字列を、それぞれの文字列毎に表示してもよい。
前記入金判定部は、前記振込データに含まれる前記口座番号に関連付けて記憶された前記判定条件が存在する場合、前記判定条件を参照して、前記受取人名と前記口座名義の一致不一致を判断してもよい。

前記入金判定部は、前記判定条件に基づいて、前記受取人名を形成する１以上の文字列のうち、前記オペレータによる一致判定に使用された一致文字列と一致する文字列が全て含まれている場合、前記受取人名が前記口座名義と一致すると判断してもよい。

前記振込データは、名義不一致を理由とする入金不能電文情報であってもよい。

また、上記課題を解決するために、本発明の別の観点によれば、受取人の口座番号および受取人名を少なくとも含む振込データを取得する振込データ取得部と、前記口座番号に対応する複数の文字列からなる口座名義を顧客マスタから取得する口座情報取得部と、前記受取人名と前記口座名義を比較し入金判定を行う入金判定部と、前記比較の結果が不一致となった振込データをオペレータに確認させる確認部と、前記口座名義の複数の文字列のうち、前記オペレータに選択され、前記オペレータによる一致判定に使用された、前記受取人名に含まれる文字列と一致する一致文字列の情報を、判定条件として前記口座番号に関連付けて記憶する記憶処理部と、を備える、入金判定装置が提供される。

また、上記課題を解決するために、本発明の別の観点によれば、プロセッサが、受取人の口座番号および受取人名を少なくとも含む振込データを取得することと、前記口座番号に対応する複数の文字列からなる口座名義を顧客マスタから取得することと、前記受取人名と前記口座名義を比較し入金判定を行うことと、前記比較の結果が不一致となった振込データをオペレータに確認させることと、前記口座名義の複数の文字列のうち、前記オペレータに選択され、前記オペレータによる一致判定に使用された、前記受取人名に含まれる文字列と一致する一致文字列の情報を、判定条件として前記口座番号に関連付けて記憶することと、を含む、入金判定方法が提供される。

また、上記課題を解決するために、本発明の別の観点によれば、コンピュータを、受取人の口座番号および受取人名を少なくとも含む振込データを取得する振込データ取得部と、前記口座番号に対応する複数の文字列からなる口座名義を顧客マスタから取得する口座情報取得部と、前記受取人名と前記口座名義を比較し入金判定を行う入金判定部と、前記比較の結果が不一致となった振込データをオペレータに確認させる確認部と、前記口座名義の複数の文字列のうち、前記オペレータに選択され、前記オペレータによる一致判定に使用された、前記受取人名に含まれる文字列と一致する一致文字列の情報を、判定条件として前記口座番号に関連付けて記憶する記憶処理部と、として機能させるための、プログラムが提供される。

以上説明した本発明によれば、名義人相違が生じた振込の入金可否の自動判定の利便性をより向上させることが可能となる。

本発明の実施形態による金融システムの構成を示した説明図である。 本発明の実施形態による管理サーバの構成を示す説明図である。 本発明の実施形態による受取人マスタＤＢのデータ構成の一例を示す図である。 本発明の実施形態によるクライアント端末に表示されるオペレータ向けのエントリ画面の一例を示す図である。 本発明の実施形態による文字列比較画面の一例を示す図である。 本発明の実施形態によるオペレータの判断による名義一致判定と記憶について説明する図である。 本発明の実施形態による判定マーク情報を用いた入金判定の一例（一致判定）について説明する図である。 本発明の実施形態による判定マーク情報を用いた入金判定の一例（不一致判定）について説明する図である。 本発明の実施形態による実施形態によるオペレータの判断による名義一致判定と記憶について説明する図である。 本発明の実施形態による判定マーク情報を用いた入金判定の一例（一致判定）について説明する図である。 本発明の実施形態による判定マーク情報を用いた入金判定の一例（不一致判定）について説明する図である。 本発明の実施形態による管理サーバ２２の動作を示すフローチャートである。

以下に添付図面を参照しながら、本発明の実施の形態について詳細に説明する。なお、本明細書及び図面において、実質的に同一の機能構成を有する構成要素については、同一の符号を付することにより重複説明を省略する。

また、本明細書及び図面において、実質的に同一の機能構成を有する複数の構成要素を、同一の符号の後に異なるアルファベットを付して区別する場合もある。ただし、実質的に同一の機能構成を有する複数の構成要素の各々を特に区別する必要がない場合、複数の構成要素の各々に同一符号のみを付する。

＜１．金融システムの概要＞
図１は、本発明の実施形態による金融システムの構成を示した説明図である。図１に示したように、本発明の実施形態による金融システムは、振込管理システム２０と、自行ホスト３０と、を備える。

（振込管理システム）
振込管理システム２０は、管理サーバ２２、およびクライアント端末２３を有する。管理サーバ２２は、受信した照会電文や訂正電文、入金不能電文などの各種電文を蓄積および処理する。クライアント端末２３は、オペレータによる操作に従って各種電文の作成を行う情報処理装置である。

（自行ホスト）
自行ホスト３０は、自行のホストコンピュータであり、仕向け側として動作する場合、振込電文を振込先の他行システム（不図示）に専用ネットワークを介して送信する。一方、自行ホスト３０は、被仕向け側として動作する場合、他行システムから受信された振込電文に従って指定口座へ資金を入金する。すなわち、自行ホスト３０は、仕向け側および被仕向け側のいずれとしても動作し得る。なお、図１においては、自行ホスト３０が、振込仕向店４０から振込電文を専用ネットワーク１２を介して受信し、被仕向け側として動作する場合について説明する。振込仕向店４０は、他行システムに含まれていてもよい。

（動作概要）
自行ホスト３０は、振込仕向店４０から送信された振込電文に含まれる受取人名と、振込電文に含まれる口座番号に対応する受取人口座名義とに相違がある場合、名義人相違を理由とする入金不能電文を振込管理システム２０の管理サーバ２２に送信する。

振込では、振込の受取人名と受取人口座の名義とが一致している必要があるが、不一致の場合でも、事務規定の許容される範囲の中で、オペレータによる読み替えや、口座属性（給与所得者、法人、個人商店等）に応じた必要な項目（姓名、法人名、代表者名等）が一致していれば入金できる。

従って、管理サーバ２２は、入金不能電文をクライアント端末２３に配信し、クライアント端末２３において、オペレータが事務規定に従って読み替え、若しくは、口座属性に応じた必要項目の確認を行い、当該受取人口座への入金判定が行われる。入金可能と判定された場合、管理サーバ２２は、当該受取人口座への入金電文を作成し、自行ホスト３０へ送信する。

従来、このようなオペレータの判断による口座属性に応じた必要項目の確認は、当該受取人口座への入金不能電文が発生する度に行われていた。

本発明の実施形態は、上記事情を一着眼点にして創作された発明であり、本発明の実施形態による管理サーバ２２は、オペレータによる判定の情報を記憶し、当該受取人口座への次回以降の振込に活用することで、名義人相違が生じた振込の入金可否の自動判定の利便性をより向上させることが可能である。

＜２．管理サーバの構成＞
図２は、本発明の実施形態による管理サーバ２２の構成を示す説明図である。図２に示したように、本発明の実施形態による管理サーバ２２は、電文受信部２５０、入金不能電文ＤＢ２５２（データベース）、受取人口座情報取得部２５４、受取人マスタ（顧客マスタ）ＤＢ２５６、入金判定部２５８、オペレータ確認部２６０、判定条件記憶処理部２６２、電文編集部２６４、および電文送信部２６６を有する。これら電文受信部２５０、入金不能電文ＤＢ２５２、受取人口座情報取得部２５４、受取人マスタＤＢ２５６、入金判定部２５８、オペレータ確認部２６０、判定条件記憶処理部２６２、電文編集部２６４、および電文送信部２６６などの機能は、ＣＰＵ（Central Processing Unit）、ＲＡＭ（Random Access Memory）、ＲＯＭ（Read Only Memory）および通信装置などのハードウェアとソフトウェアとの協働により実現され得る。

電文受信部２５０は、自行ホスト３０から入金不能電文を受信し、入金不能電文ＤＢ２５２に蓄積する。受取人口座情報取得部２５４は、入金不能電文ＤＢ２５２から入金不能電文を１つ取り出し、入金不能電文に設定されている入金不能理由が受取人口座名義相違の場合、店名、科目、口座番号等をキーに、受取人マスタＤＢ２５６から受取人の口座マスタ情報を検索する。

ここで、図３に、本実施形態による受取人マスタＤＢのデータ構成の一例を示す。図３に示すように、受取人マスタＤＢ２５６には、受取人の口座マスタ情報として、受取人口座情報（店名、口座）、受取人名義情報、および、後述する本実施形態による一致判定対象マーク情報が保有されている。一致判定対象マーク情報は、受取人名義の文字列を、所定の区切り文字（例えば、スペース、ピリオド、カンマ、コロン、セミコロン、括弧開き、括弧閉じ、等）で分割した１以上の文字列に対して、それぞれ、オペレータが名義一致の判定に使用したか否かを示す判定マークが付与された情報（初期値「０」、オペレータが判定に使用した場合「１」）である。本実施形態では、後述する判定条件記憶処理部２６２により、オペレータが名義一致の判定に使用した文字列の情報が、受取人マスタＤＢ２５６に保存され得る。

入金判定部２５８は、取得した受取人の口座マスタ情報に基づいて、入金可否の判定処理を行う。具体的には、入金判定部２５８は、既にオペレータによる名義一致の判定が判定マーク情報として記録されている場合は、振込電文の受取人名のうち、必要な文字列が一致しているか否かに基づいて（名義比較による名義一致判断）、入金可否を自動判定することが可能となる。本実施形態では、オペレータの判断による名義一致の判定を判定マーク情報（一致判定条件）として記録しておくことで、このように、次回以降の同名義人口座の名義一致の自動判定に活用することが可能となり、入金判定システムの利便性を向上させることができる。

一方、まだオペレータ判断による名義一致の判定が行われておらず、判定マーク情報が記録されていない場合、オペレータ確認部２６０により、クライアント端末２３に入金不能電文が配信される。

ここで、図４に、クライアント端末２３に表示されるオペレータ向けのエントリ画面の一例を示す。図４のエントリ画面２３１には、入金不能電文情報、受取人口座のホスト照会結果（元帳照会、照会結果）、回答／依頼
突合エントリ等が表示されている。元帳照会の画面には、受取人口座の口座属性（給与所得者、法人、個人商店等）が示され、照会結果の画面では、入金不能理由が示されている。なお図４に示す画面例は一例であって、本実施形態による画面構成はこれに限定されない。

オペレータは、入金不能理由が受取人口座名義相違の場合、画面中の「受取人名義確認」ボタン２３５を選択し、名義の文字列比較の画面を表示させる。図５に、本実施形態による文字列比較画面の一例を示す。

図５に示すように、文字列比較画面２３８では、入金不能電文の受取人名（「振込電文の受取人名」）を区切り文字で分割した文字列の表示と、受取人口座名義を区切り文字で分割した文字列の表示が含まれる。なお図５に示す画面例は一例であって、本実施形態による画面構成はこれに限定されない。

オペレータは、受取人口座のホスト照会結果で示される口座属性を参照し、口座属性と事務規定から、確認すべき項目（法人名、代表者、姓名等）が、振込電文の受取人名の文字列にあり、かつ、一致していることを確認する。

事務規定では、口座属性に応じた、名義一致判定において確認すべき項目が定められており、オペレータは、かかる事務規定を把握しているものとする。なお、事務規定の情報は、必要に応じて、エントリ画面や、文字列比較画面に表示したり、オペレータの操作に応じて表示したりするようにしてもよい。

事務規定の一例として、例えば、口座属性が「法人」である場合は「法人名」が一致していればよく、また、「法人格」は、一致していればその位置は無視する（すなわち、後株、前株のいずれであってもよい）、といった取り決めが定められている。したがって、例えば振込電文の受取人名に、「法人名」と「法人格」の他、社長や担当者の氏名も記載されてしまっているため名義人不一致となった場合でも、オペレータは、事務規定に従って、「法人名」と「法人格」の文字列が受取人口座名義と一致していれば、入金可能と判定する。

確認すべき項目が全て一致している場合、オペレータは、受取人口座名義の該当する文字列の判定マークにチェックを付け、「登録」ボタンを選択する。また、オペレータは、エントリ画面２３１において、エントリ結果として「入金」の処理選択を行い、管理サーバ２２に登録する。

一方、確認すべき項目が一致していないものがある場合、オペレータは、文字列比較画面２３８の「戻る」ボタンを選択し、エントリ画面２３１において、エントリ結果として「照会」または「返却」の処理選択を行い、管理サーバ２２に登録する。

判定条件記憶処理部２６２は、オペレータによる判定の情報を、受取人マスタＤＢ２５６に記憶する処理を行う。具体的には、判定条件記憶処理部２６２は、オペレータにより口座名義一致判定に用いられた文字列の情報、すなわち、図５に示す文字列比較画面２３８において、判定マークにチェックを入れた文字列の情報（一致判定対象マーク情報）を、当該口座名義の名義一致判定条件として、受取人マスタＤＢ２５６に記憶する。

電文編集部２６４は、入金判定部２５８による判定結果またはオペレータ確認部２６０によるオペレータ確認結果（エントリ結果）に従い、電文を編集し、電文送信部２６６により自行ホスト３０へ送信する。具体的には、電文編集部２６４は、判定結果またはエントリ結果が「入金」の場合、入金電文を編集し、「照会」または「返却」の場合、照会電文または付替電文を編集する。

＜３．具体例＞
以上説明したように、本実施形態による管理サーバ２２は、オペレータの判断による口座名義一致判定の情報を記録し、次回以降の同口座名義の自動判定に活用することで、名義人相違が生じた振込の入金可否の自動判定の利便性を、より向上させることが可能となる。

このようなオペレータの判断による口座名義一致判定の情報の記録と、次回以降の同口座名義の自動判定への活用に関し、具体的な事務規定と共に、説明する。

（口座属性が「個人商店」の場合）
まず、受取人の口座の口座属性が「個人商店」の場合について、図６～図８を参照して説明する。

図６は、本実施形態によるオペレータの判断による名義一致判定と記憶について説明する図である。図６の上段に示すように、例えば、振込電文の受取人名が「ナラ シカオ」、受取人口座名義が「ナラショウテン ナラ シカオ」の場合、自行ホスト３０から、名義不一致による入金不能電文が送信される。

口座を照会した結果、口座属性が『個人商店』であることが解ったため、オペレータは、事務規定「個人商店の場合は代表者が一致していれば入金可」に従って、代表者名が一致しているか否かを判断する。具体的には、図６の中段に示すように、代表者氏名「ナラ」「シカオ」の文字列がそれぞれ一致している場合、オペレータは、名義が一致すると判断し、「入金」登録する。

この際、オペレータは、クライアント端末２３において、どの文字列で一致判定をしたかを入力する（判定マークの登録）。管理サーバ２２は、オペレータにより入力された判定情報を、口座名義情報として受取人マスタＤＢ２５６に記録する。具体的には、図６の下段に示すように、区切り文字で区切った口座名義の文字列毎に、初期値「０」が設定されているところ、オペレータが判定に使用した文字列の値は、「１」に更新する。ここでは、口座名義人文字列「ナラショウテン」「ナラ」「シカオ」のうち、「ナラ」と「シカオ」の判定マークの値が、「１」となる。

続いて、このように登録したオペレータの判定情報を、当該口座の次回判定時に利用する場合について、図７および図８を参照して説明する。

図７は、本実施形態による判定マーク情報を用いた入金判定の一例（一致判定）について説明する図である。図７の上段に示すように、例えば、振込電文の受取人名が「ナラ シカオ」の場合、入金判定部２５８は、受取人口座名義のうち判定マークがついている文字列のみ（「ナラ」「シカオ」）を、振込電文の受取人名（「ナラ」「シカオ」）と比較する。この場合、比較した文字列が全て一致するため、入金判定部２５８は、図７の下段に示すように、「入金」の判定を行う。

一方、図８の上段に示すように、例えば、振込電文の受取人名が「ナラショウテン」の場合、入金判定部２５８は、受取人口座名義のうち判定マークがついている文字列のみ（「ナラ」「シカオ」）を、振込電文の受取人名（「ナラショウテン」）と比較する。この場合、比較した文字列が一致しないため、入金判定部２５８は、図８の下段に示すように、「照会」または「返却」の判定を行う。

（口座属性が「法人」の場合）
次に、受取人の口座の口座属性が「法人」の場合について、図９～図１１を参照して説明する。

図９は、本実施形態によるオペレータの判断による名義一致判定と記憶について説明する図である。図９の上段に示すように、例えば、振込電文の受取人名が「カ）ニホンシヨウジ エイギヨウブ タナカ」、受取人口座名義が「ニホンシヨウジ（カ ダイヒヨウ ヤマダ タロウ」の場合、自行ホスト３０から、名義不一致による入金不能電文が送信される。

口座を照会した結果、口座属性が『法人』であることが解ったため、オペレータは、事務規定「法人の場合は法人名が一致していれば入金可、法人格は同じであれば位置は無視する（後株・前株は同じ）」に従って、必要な項目（法人名、法人格）が一致しているか否かを判断する。具体的には、図９の中段に示すように、代表者氏名「カ」「ニホンシヨウジ」の文字列がそれぞれ一致している場合、オペレータは、名義が一致すると判断し、「入金」登録する。

この際、オペレータは、クライアント端末２３において、どの文字列で一致判定をしたかを入力する（判定マークの登録）。管理サーバ２２は、オペレータにより入力された判定情報を、口座名義情報として受取人マスタＤＢ２５６に記録する。具体的には、図９の下段に示すように、区切り文字で区切った口座名義の文字列毎に、初期値「０」が設定されているところ、オペレータが判定に使用した文字列の値は、「１」に更新する。ここでは、口座名義人文字列「ニホンシヨウジ」「カ」「ダイヒヨウ」「ヤマダ」「タロウ」のうち、「ニホンシヨウジ」と「カ」の判定マークの値が、「１」となる。

続いて、このように登録したオペレータの判定情報を、当該口座の次回判定時に利用する場合について、図１０および図１１を参照して説明する。

図１０は、本実施形態による判定マーク情報を用いた入金判定の一例（一致判定）について説明する図である。図１０の上段に示すように、例えば、振込電文の受取人名が「ニホンシヨウジ（カ」の場合、入金判定部２５８は、受取人口座名義のうち判定マークがついている文字列のみ（「ニホンシヨウジ」「カ」）を、振込電文の受取人名（「ニホンシヨウジ」「カ」）と比較する。この場合、比較した文字列が全て一致するため、入金判定部２５８は、図１０の下段に示すように、「入金」の判定を行う。

一方、図１１の上段に示すように、例えば、振込電文の受取人名が「ニホンシヨウジ ダイヒョウ ヤマダ タロウ」の場合、入金判定部２５８は、受取人口座名義のうち判定マークがついている文字列のみ（「ニホンシヨウジ」「カ」）を、振込電文の受取人名（「ニホンシヨウジ」「ダイヒョウ」「ヤマダ」「タロウ」）と比較する。この場合、比較した文字列が一致しないため（法人格を示す「カ」が無い）、入金判定部２５８は、図１１の下段に示すように、「照会」または「返却」の判定を行う。

＜４．動作処理＞
以上、本発明の実施形態による管理サーバ２２の構成を説明した。続いて、図１２を参照し、本発明の実施形態による管理サーバ２２の動作を整理する。

図１２は、本発明の実施形態による管理サーバ２２の動作を示すフローチャートである。図１２に示したように、まず、電文受信部２５０は、名義人相違により入金不能となった入金不能電文を、自行ホスト３０から受信する（Ｓ１０３）。

次に、電文受信部２５０は、入金不能電文を入金不能電文ＤＢ２５２に格納する（Ｓ１０６）。

次いで、受取人口座情報取得部２５４は、入金不能電文を入金不能電文ＤＢ２５２から１件取得し（Ｓ１０９）、入金不能理由が受取人口座名義の相違の場合（Ｓ１１２／Ｙｅｓ）、受取人の口座マスタ情報を受取人マスタＤＢ２５６から検索する（Ｓ１１５）。

次に、受取人の口座マスタ情報が登録されている場合（Ｓ１１８／Ｙｅｓ）、入金判定部２５８は、入金判定を行う（Ｓ１２１）。具体的には、入金判定部２５８は、口座マスタ情報に含まれる判定マークを参照し、入金判定として、口座名義の一致判定を行う。

入金判定部２５８により不一致（入金不能）と判定された場合（Ｓ１２４／Ｎｏ）、または、受取人の口座マスタ情報（より具体的には、判定マーク）がまだ登録されていなかった場合（Ｓ１１８／Ｎｏ）、オペレータ確認部２６０は、クライアント端末２３に、入金不能電文を配信する（Ｓ１２７）。

なお、入金不能理由が受取人口座名義の相違ではなかった場合も（Ｓ１１２／Ｎｏ）、クライアント端末２３に入金不能電文が配信される（Ｓ１２７）。受取人口座名義の相違以外での入金不能理由としては、例えば、「受取人口座番号無し」といったことも挙げられる。「受取人口座番号無し」は、例えば受取人側の店舗統廃合が原因で発生している場合があり、店舗統廃合情報を参照してオペレータ判断により入金判定が行われることも想定される。

次いで、クライアント端末２３で行われたオペレータ判断による入金判定結果を取得し、その結果が一致判定の場合（Ｓ１３０／一致）、判定条件記憶処理部２６２は、オペレータ判断に用いられた文字列の情報（判定条件）を受取人マスタＤＢ２５６に記録する（Ｓ１３３）。

そして、オペレータにより一致判定された場合、電文編集部２６４により入金電文を編集し（Ｓ１３６）、電文送信部２６６により入金電文が自行ホスト３０に送信される（Ｓ１３９）。

また、入金判定部２５８により一致（入金可能）と判定された場合も（Ｓ１２４／Ｙｅｓ）、電文編集部２６４により入金電文を編集し（Ｓ１３６）、電文送信部２６６により入金電文が自行ホスト３０に送信される（Ｓ１３９）。

一方、オペレータ判断による入金判定結果が不一致判定の場合（Ｓ１３０／不一致）、電文編集部２６４により付替または照会電文を編集し（Ｓ１４２）、電文送信部２６６により付替または照会電文を自行ホスト３０に送信する（Ｓ１４５）。付替または照会電文は、自行ホスト３０を介して振込仕向店４０へ送信され得る。

＜５．作用効果＞
以上説明した本発明の実施形態によれば、多様な作用効果が得られる。

名義一致の自動判定の場合、口座属性により受取人口座名義の中のチェックすべき項目を判定するためには、文字列の意味をプログラムで解釈する必要があり困難であった。しかし、本発明の実施形態による管理サーバ２２は、受取人口座単位にオペレータが判定に使用した文字列を（判定マークの付与により）記憶させることで、次回以降の当該受取人口座への振込に関しては、事務規定に基づく、口座属性を考慮した必要項目のチェックや判定ルールを適用した入金判定が可能となる。これにより、名義人相違が生じた振込の入金可否の自動判定の利便性をより向上させることができる。

＜６．補足＞
なお、添付図面を参照しながら本発明の好適な実施形態について詳細に説明したが、本発明はかかる例に限定されない。本発明の属する技術の分野における通常の知識を有する者であれば、特許請求の範囲に記載された技術的思想の範疇内において、各種の変更例または修正例に想到し得ることは明らかであり、これらについても、当然に本発明の技術的範囲に属するものと了解される。

例えば、本明細書の情報処理システムの処理における各ステップは、必ずしもフローチャートとして記載された順序に沿って時系列に処理する必要はない。例えば、情報処理システムの処理における各ステップは、フローチャートとして記載した順序と異なる順序で処理されても、並列的に処理されてもよい。

また、管理サーバ２２に内蔵されるＣＰＵ、ＲＯＭおよびＲＡＭなどのハードウェアに、上述した管理サーバ２２の各構成と同等の機能を発揮させるためのコンピュータプログラムも作成可能である。また、該コンピュータプログラムを記憶させた記憶媒体も提供される。

１２ 専用ネットワーク
２０ 振込管理システム
２２ 管理サーバ
２３ クライアント端末
３０ 自行ホスト
４０ 振込仕向店
２３１ エントリ画面
２３８ 文字列比較画面
２５０ 電文受信部
２５２ 入金不能電文ＤＢ
２５４ 受取人口座情報取得部
２５６ 受取人マスタＤＢ
２５８ 入金判定部
２６０ オペレータ確認部
２６２ 判定条件記憶処理部
２６４ 電文編集部
２６６ 電文送信部

Claims (8)

1. 受取人の口座番号および受取人名を少なくとも含む振込データを取得する振込データ取得部と、
   前記口座番号に対応する複数の文字列からなる口座名義を顧客マスタから取得する口座情報取得部と、
   前記受取人名と前記口座名義を比較し入金判定を行う入金判定部と、
   前記比較の結果が不一致となった振込データをオペレータに確認させる確認部と、
   前記口座名義の複数の文字列のうち、前記オペレータに選択され、前記オペレータによる一致判定に使用された、前記受取人名に含まれる文字列と一致する一致文字列の情報を、判定条件として前記口座番号に関連付けて記憶する記憶処理部と、
   を備える、入金判定システム。
2. 前記確認部は、前記口座名義の複数の文字列を、それぞれの文字列毎に表示する、請求項１に記載の入金判定システム。
3. 前記入金判定部は、
   前記振込データに含まれる前記口座番号に関連付けて記憶された前記判定条件が存在する場合、前記判定条件を参照して、前記受取人名と前記口座名義の一致不一致を判断する、請求項１または２に記載の入金判定システム。
4. 前記入金判定部は、
   前記判定条件に基づいて、前記受取人名を形成する１以上の文字列のうち、前記オペレータによる一致判定に使用された一致文字列と一致する文字列が全て含まれている場合、前記受取人名が前記口座名義と一致すると判断する、請求項３に記載の入金判定システム。
5. 前記振込データは、名義不一致を理由とする入金不能電文情報である、請求項１～４のいずれか１項に記載の入金判定システム。
6. 受取人の口座番号および受取人名を少なくとも含む振込データを取得する振込データ取得部と、
   前記口座番号に対応する複数の文字列からなる口座名義を顧客マスタから取得する口座情報取得部と、
   前記受取人名と前記口座名義を比較し入金判定を行う入金判定部と、
   前記比較の結果が不一致となった振込データをオペレータに確認させる確認部と、
   前記口座名義の複数の文字列のうち、前記オペレータに選択され、前記オペレータによる一致判定に使用された、前記受取人名に含まれる文字列と一致する一致文字列の情報を、判定条件として前記口座番号に関連付けて記憶する記憶処理部と、
   を備える、入金判定装置。
7. プロセッサが、
   受取人の口座番号および受取人名を少なくとも含む振込データを取得することと、
   前記口座番号に対応する複数の文字列からなる口座名義を顧客マスタから取得することと、
   前記受取人名と前記口座名義を比較し入金判定を行うことと、
   前記比較の結果が不一致となった振込データをオペレータに確認させることと、
   前記口座名義の複数の文字列のうち、前記オペレータに選択され、前記オペレータによる一致判定に使用された、前記受取人名に含まれる文字列と一致する一致文字列の情報を、判定条件として前記口座番号に関連付けて記憶することと、
   を含む、入金判定方法。
8. コンピュータを、
   受取人の口座番号および受取人名を少なくとも含む振込データを取得する振込データ取得部と、
   前記口座番号に対応する複数の文字列からなる口座名義を顧客マスタから取得する口座情報取得部と、
   前記受取人名と前記口座名義を比較し入金判定を行う入金判定部と、
   前記比較の結果が不一致となった振込データをオペレータに確認させる確認部と、
   前記口座名義の複数の文字列のうち、前記オペレータに選択され、前記オペレータによる一致判定に使用された、前記受取人名に含まれる文字列と一致する一致文字列の情報を、判定条件として前記口座番号に関連付けて記憶する記憶処理部と、
   として機能させるための、プログラム。

Images