JP2015125455A - 為替明細情報を利用した与信管理システムおよび方法 - Google Patents

Abstract

【課題】金融機関が取引先顧客に融資を行う際の与信判断を行う上で、当該取引先顧客の入出金情報を一元管理することは重要である。しかしながら、１つの取引先顧客における販売先および仕入先は１つずつとは限らず、また取り扱う口座も多数存在する場合があり、これらを管理することは容易でない。さらに、１つの取引先顧客が複数の口座を持つこともあり、当該複数の口座は情報として関連性を持たない。
【解決手段】為替明細データを利用し、取引先顧客の与信データを管理するシステムを提供する。当該システムは、取引先顧客の商流データを作成し、為替明細データに対して名寄せ処理を実行することにより、為替明細データにおける同一企業に係るデータを認識し、かつ同一商流に係るデータをサマリーし、商流為替明細データを作成する。さらに、商流為替明細データおよび倒産データに基づいて、取引先顧客のアラームデータを作成する。
【選択図】図１１

Description

本発明は、為替明細情報を利用した与信管理システムおよび方法に関する。

金融機関が取引先顧客に融資を行う際、当該取引先顧客に金銭的な信用を供与してよいか、およびどれだけの信用を供与してよいかといった判断、いわゆる与信判断が行われる。この判断を行う上で重要となるのが、取引先顧客の債権および債務、ならびに取引先顧客に対する販売先および仕入先などの情報を管理することである（これを与信管理という）。もし、この与信管理が適切に行われない場合、取引先顧客の販売先からの入金が滞っている、または販売先が倒産した、などの異常情報を把握することができず、リスクの高い融資を行ってしまうことになる（最悪の場合、融資に対する回収ができないこともある）。このため、取引先顧客の与信管理を行うシステムおよび方法が必要とされる。

しかしながら、１つの取引先顧客における販売先および仕入先は１つずつとは限らず、また取り扱う口座も多数存在する場合があり、これらを管理することは容易でない。さらに、１つの取引先顧客が複数の口座を持つこともあり、当該複数の口座は情報として関連性を持たないため、当該複数の口座に対する入出金を１つの取引先顧客の情報として一元管理することも容易でない。

もし、取引先顧客の入出金情報を一元管理することができれば、例えば、与信判断時に、販売先からの入金が滞っていることや、倒産したことなどの異常情報も把握することができ、適切な与信管理が行うことができるシステムおよび方法が求められている。また、取引先顧客の情報を一括して把握することにより、このような情報を、取引先顧客に対する営業推進に活用することも求められている。

本発明は、このような目的を達成するために、為替明細データを利用し、金融機関に対する取引先顧客の与信データを管理するシステムであって、前記システムは、
前記取引先顧客の販売先および仕入先データに基づいて、商流データを作成する手段と、
前記為替明細データに対して名寄せ処理を実行する手段であって、前記名寄せ処理は、前記為替明細データにおける同一商流に係るデータをサマリーするために、前記為替明細データに含まれる前記取引先顧客、前記販売先、および前記仕入先の各企業名に含まれる文字列を、所定の文字列に変換し、前記変換した文字列と企業属性データにおける企業名とを関連付けることにより、前記為替明細データにおける同一企業に係るデータを認識する処理である、手段と、
前記名寄せ処理を施した前記為替明細データから、前記取引先顧客の入出金データを抽出し、かつ同一商流に係るデータをサマリーし、商流為替明細データを作成する手段と
を備えたことを特徴とする。

また、前段落に記載の発明において、前記商流為替明細データおよび倒産データに基づいて、前記取引先顧客のアラームデータを作成する手段であって、前記アラームデータは、前記取引先顧客が倒産したこと、前記販売先が倒産したこと、前記仕入先が倒産したこと、および前記取引先顧客における入金が一定期間に所定の割合減ったこと、のうちの少なくとも１つを示すデータである、手段と、
前記作成したアラームデータを、クライアント端末に送信する手段と
をさらに備えたことを特徴とする。

さらに、前２段落に記載の発明において、前記為替明細データに含まれる前記各企業名は、前記取引先顧客、前記販売先、および前記仕入先の口座名義であり、
前記名寄せ処理の精度を向上させるために、前記名寄せ処理は、前記為替明細データに含まれる口座名義の金融機関および支店コードと、前記企業属性データにおける金融機関および支店コードとを突き合わせることを含む
ことを特徴とする。

また、前３段落に記載の発明において、前記販売先および前記仕入先データ、ならびに前記企業属性データを、外部サーバから受信する手段をさらに備えたことを特徴とする。

以上説明したように、本発明によれば、取引先顧客の債権および債務、ならびに取引先顧客に対する販売先および仕入先などの情報を一元管理し、与信判断時に異常情報を把握することができ、適切な与信管理を行うことができる。また、取引先顧客の情報を一括して把握することにより、このような情報を、取引先顧客に対する営業推進に活用することもできる。

本発明の一実施形態に係るシステム構成を示す図である。 本発明の一実施形態に係る販売先データ記憶部に格納されたデータを示す図である。 本発明の一実施形態に係る仕入先データ記憶部に格納されたデータを示す図である。 本発明の一実施形態に係る商流データ記憶部に格納されたデータを示す図である。 本発明の一実施形態に係る為替明細データ記憶部に格納されたデータを示す図である。 本発明の一実施形態に係る企業属性データ記憶部に格納されたデータを示す図である。 本発明の一実施形態に係る商流為替明細データ記憶部に格納されたデータを示す図である。 本発明の一実施形態に係る倒産データ記憶部に格納されたデータを示す図である。 本発明の一実施形態に係るアラームデータ記憶部に格納されたデータを示す図である。 本発明の一実施形態に係る名寄せ条件データ記憶部に格納されたデータを示す図である。 本発明の一実施形態に係る与信管理処理を示すフローチャートである。

以下、添付した図面を参照して、本発明の実施形態に係る与信管理システムを詳細に説明する。

まず始めに、与信管理システムの概要を説明する。図１は、本発明の一実施形態に係るシステム構成を示す図である。図１において、外部サーバ１００は、外部ネットワーク内に設置されたサーバである。データセンタなどに設置された与信管理サーバ１０１は、ネットワーク１０２（例えば、インターネット）を介して、外部サーバ１００と通信を行うように構成されている。また、与信管理サーバ１０１は、ネットワーク１０３（例えば、イントラネットやエクストラネット）を介して、１または複数のクライアント端末１０４ａ、・・・、１０４ｎ（以下、まとめて「クライアント端末１０４」という）と通信を行うように構成されている。クライアント端末１０４は、例えば、与信判断を行う金融機関担当者が使用する端末である。なお、図１において、与信管理サーバ１０１を単一のサーバとして示しているが、複数台のサーバによる分散システムとして構成することも可能である。

与信管理サーバ１０１は、外部サーバ１００から販売先データおよび仕入先データを受信し、かつ商流データを作成する。また、与信管理サーバ１０１は、作成した商流データに基づいて、為替明細データから商流為替明細データを作成する。この際、為替明細データのうち、口座名義が異なるため、別データ（レコード）として扱われる、本来は同一商流（取引先顧客と販売先とが実質的に同一、または取引先顧客と仕入先とが実質的に同一）のデータをサマリーする。そのため、与信管理サーバ１０１は、外部サーバ１００から企業属性データを受信し、かつ当該企業属性データに基づいて名寄せ処理を実行する。

次に、与信管理サーバ１０１の構成を詳細に説明する。なお、図１では、単一のコンピュータシステムを想定し、必要な機能構成だけを示している。

与信管理サーバ１０１は、ＣＰＵ１１０に、システムバス１１５を介してＲＡＭ１１１、入力装置１１２、出力装置１１３、通信制御装置１１４、および不揮発性記憶媒体（ＲＯＭやＨＤＤなど）で構成される記憶装置１１６が接続された構成を有する。記憶装置１１６は、与信管理システムの各機能を奏するためのソフトウェアプログラムを格納するプログラム格納領域と、当該ソフトウェアプログラムで取り扱うデータを格納するデータ格納領域とを備えている。以下に説明するプログラム格納領域の各手段は、実際は独立したソフトウェアプログラム、そのルーチンやコンポーネントなどであり、ＣＰＵ１１０によって記憶装置１１６から呼び出されＲＡＭ１１１のワークエリアに展開されて、データベースなどを適宜参照しながら順次実行されることで、各機能を奏するものである。

記憶装置１１６におけるデータ格納領域は、本発明に関連するものだけを列挙すると、販売先データ記憶部１３１、仕入先データ記憶部１３２、商流データ記憶部１３３、為替明細データ記憶部１３４、企業属性データ記憶部１３５、商流為替明細データ記憶部１３６、倒産データ記憶部１３７、アラームデータ記憶部１３８、および名寄せ条件データ記憶部１３９を備える。いずれも、記憶装置１１６内に確保された一定の記憶領域である。

販売先データ記憶部１３１は、取引先顧客に対する販売先のデータを格納する。図２は、本発明の一実施形態に係る販売先データ記憶部１３１に格納されたデータを示す図である。図２における販売先データは、取引先顧客を一意に示す「企業番号」、取引先顧客に対する販売先を一意に示す「販売先企業番号」、およびデータの登録（更新）日を示す「更新日」を含む。なお、「企業番号」および「販売先企業番号」は同一フォーマットであり得、取引先顧客が、別の取引先顧客に対する販売先であることもある。また、外部サーバ１００が複数存在する場合、各々のサーバから販売先データが連携される場合があり、この場合、「企業番号」および「販売先企業番号」は各々のサーバが保持するＤＢでユニークな番号となる。そのため、例えば、図２における「企業番号」に代えて、同一の企業を示す場合であっても、「第１の企業番号」および「第２の企業番号」と複数保持することになる（すなわち、企業Ａを示す企業番号であっても、第１の企業番号では「11111111」であり、第２の企業番号では「9999999999」であるというケースが起こり得る）。この考え方は、「販売先企業番号」についても適用され得る。

仕入先データ記憶部１３２は、取引先顧客に対する仕入先のデータを格納する。図３は、本発明の一実施形態に係る仕入先データ記憶部１３２に格納されたデータを示す図である。図３における仕入先データは、取引先顧客を一意に示す「企業番号」、取引先顧客に対する仕入先を一意に示す「仕入先企業番号」、およびデータの登録（更新）日を示す「更新日」を含む。なお、「企業番号」および「仕入先企業番号」は同一フォーマットであり得、取引先顧客が、別の取引先顧客に対する仕入先であることもある。また、「仕入先企業番号」についても、前項で説明した、「第１の企業番号」および「第２の企業番号」の考え方は適用され得る。

商流データ記憶部１３３は、取引先顧客に対する商流データを格納する。図４は、本発明の一実施形態に係る商流データ記憶部１３３に格納されたデータを示す図である。図４における商流データは、取引先顧客を一意に示す「企業番号」、取引先顧客に対する販売先または仕入先を一意に示す「取引先企業番号」、取引先企業番号によって示される企業が販売先か仕入先かを示す「商流区分」、およびデータの登録（更新）日を示す「更新日」を含む。ここで、「商流区分」は、例えば、取引先企業番号によって示される企業が販売先である場合は「１」であり、仕入先の場合は「２」である。また、取引先顧客（企業Ａとする）と、その取引先企業（企業Ｂとする）との間には各々商流が存在し、企業Ａに対する販売先が企業Ｂである場合、企業Ｂに対する仕入先は企業Ａという関係が成立する。そのため、原則として、商流データには、企業間の取引に対して、２レコード分のデータが存在することになる。

為替明細データ記憶部１３４は、取引先顧客に対する入出金を示す為替明細データを格納する。図５は、本発明の一実施形態に係る為替明細データ記憶部１３４に格納されたデータを示す図である。図５における為替明細データは、代金を支払う側（債務者）である発信者の金融機関データおよび口座データ、ならびに代金を受け取る側（債権者）である受信者の金融機関データおよび口座データ、取引された金額を示す「取引額」、および取引された日付を示す「取引日」を含む。

企業属性データ記憶部１３５は、販売先および仕入先を含む取引先企業のデータを格納する。図６は、本発明の一実施形態に係る企業属性データ記憶部１３５に格納されたデータを示す図である。図６における企業属性データは、取引先企業を一意に示す「企業番号」、企業名のカタカナ表記である「企業名カナ」、法人格（株式会社、有限会社）が何であるかを示す「法人格コード」、法人格が企業名の前後のいずれかに表示されるかを示す「法人格前後表示」、ならびに取引先企業の金融機関データおよび口座データを含む。ここで、「法人格コード」は、例えば、取引先企業が株式会社である場合は「０１」であり、有限会社の場合は「０２」である。また、「法人格前後表示」は法人格が企業名の前に表示される場合（例えば、株式会社特許商事）は「０１」、後に表示される場合（例えば、ＡＢＣ株式会社）は「０２」である。図６における「金融機関コード」および「支店コード」は、取引先企業が１〜３の３種類の金融機関および支店の組み合わせを有し得ることを意味している。他の実施形態では、「金融機関コード」および「支店コード」を３種類以上有し得るように項目数を増やすこともできるし、また１レコード１種類とし複数レコード持つこともできる。

商流為替明細データ記憶部１３６は、為替明細データにおける同一名義人に対し名寄せ処理を施し、サマリーした商流為替明細データを格納する。図７は、本発明の一実施形態に係る商流為替明細データ記憶部１３６に格納されたデータを示す図である。図７における商流為替明細データは、代金を支払う側（債務者）である発信者を一意に示す「発信者企業番号」および「発信者名」、ならびに代金を受け取る側（債権者）である受信者を一意に示す「受信者企業番号」および「受信者名」、取引された金額の合計額を示す「取引額計」、および取引された月を示す「取引月」を含む。なお、図７における商流為替明細データは、図５における為替明細データに対し、取引月単位でサマリーしたものを想定しているため、「取引額計」は、為替明細データにおける同一名義人における「取引月」単位の「取引額」の合計である。

倒産データ記憶部１３７は、倒産した企業のデータを格納する。図８は、本発明の一実施形態に係る倒産データ記憶部１３７に格納されたデータを示す図である。図８における倒産データは、倒産した企業の「企業番号」、および倒産した日を示す「倒産日」格納する。

アラームデータ記憶部１３８は、取引先顧客ごとのアラームデータを格納する。図９は、本発明の一実施形態に係るアラームデータ記憶部１３８に格納されたデータを示す図である。図９におけるアラームデータは、取引先顧客を一意に示す「企業番号」、各アラームデータを格納する。各アラームデータは、一実施形態では、取引先顧客が倒産したことを示す「倒産」、取引先顧客に対する販売先または仕入先が倒産したことを示す「商流倒産」、および取引先顧客における入金が一定期間に所定の割合減ったことを示す「入金減」である。なお、この場合、例えば、各データは「０」がアラームとして非該当、「１」が該当することを示すＯＮ／ＯＦＦフラグとして使用することができる。しかしながら、「商流倒産」の場合は、「０」が非該当、「１」が販売先倒産、「２」が仕入先倒産、ならびに「３」が販売先および仕入先倒産として使用することができる。また、「入金減」については、小幅減から大幅減などと段階分けし、各々を示す数値を割り当てることもできる。これにより、より細かいアラームデータを示すことができる。

名寄せ条件データ記憶部１３９は、名寄せ処理に用いる変換データを格納する。図１０は、本発明の一実施形態に係る名寄せ条件データ記憶部１３９に格納されたデータを示す図である。図１０における名寄せ条件データは、変換前の文字列を示す「変換元」、および変換後の文字列を示す「変換先」格納する。なお、「変換先」が空白の場合は、「変換元」が示す文字列を単に削除するという意味である。また、他の実施形態では、削除文字列のみをデータとして保持することができる。この場合は、名寄せ条件データとして、変換用のデータと、削除用のデータの２つに基づいて、名寄せ処理を実施することになる。さらに他の実施形態では、変換および削除条件をプログラム上に記述する（いわゆるハードコーディング）場合は、名寄せ処理に用いる変換データは不要となるため名寄せ条件データ記憶部１３９も不要となる。

次に、記憶装置１１６におけるプログラム格納領域に格納されているソフトウェアプログラムは、本発明に関連するものだけを列挙すると、データ送受信手段１２０、商流データ作成手段１２１、商流為替明細データ作成手段１２２、名寄せ手段１２３、および異常値捕捉手段１２４を備えている。これらの手段１２０−１２４は、ＣＰＵ１１０によって実行される。

データ送受信手段１２０は、外部サーバ１００から販売先データ、仕入先データ、企業属性データ、および倒産データなどを受信し、それぞれ、販売先データ記憶部１３１、仕入先データ記憶部１３２、企業属性データ記憶部１３５、および倒産データ記憶部１３７に記憶する。また、データ送受信手段１２０は、アラームデータをクライアント端末１０４に送信する。

商流データ作成手段１２１は、外部サーバ１００から受信した販売先データおよび仕入先データに基づいて、図４に示すような商流データを作成し、商流データ記憶部１３３に記憶する。なお、他の実施形態において、外部サーバ１００が既に図４に示すような商流データの形でデータを保持し、かつ与信管理サーバ１０１に連携される場合、本手段は当然ながら必要ない。

商流為替明細データ作成手段１２２は、商流データおよび企業属性データに基づいて、為替明細データから取引先顧客の入出金データを抽出し、例えば取引月ごとにサマリーし、図７に示すような商流為替明細データを作成し、かつ商流為替明細データ記憶部１３６に記憶する。

名寄せ手段１２３は、商流為替明細データを作成する際、企業属性データおよび名寄せ条件データに基づいて、名寄せ処理を実行する。

異常値捕捉手段１２４は、商流為替明細データおよび倒産データに基づいて、取引先顧客のアラームデータを作成する。

次に、図１１のフローチャート、ならびに図２−１０の表を参照して、本発明の一実施形態に係る与信管理処理を流れに沿って説明する。

図１１は、本発明の一実施形態に係る与信管理処理を示すフローチャートである。なお、図１１のフローチャートは一連の処理を連続して記載しているが、必ずしも連続して処理する必要はない。処理のタイミングおよび周期は、任意設定することができる。特に、ステップ１１０１−１１０２の商流データ作成処理、ならびにステップ１１０３以降の商流為替明細データ作成および異常値捕捉処理は、例えば、商流データ作成処理を予めしておいて、１日１回の夜間バッチなどで当該商流データに基づいて、為替明細データから商流為替明細データ作成し、異常値捕捉処理を実行することが想定される。また、商流為替明細データを作成する際、該当する商流データが存在しない場合も想定できるため、この場合は、商流為替明細データを作成するタイミングで、該当の商流データを作成することになる。

図１１のフローチャートについて詳細に説明する。まず、ステップ１１０１にて、データ送受信手段１２０が、外部サーバ１００から、販売先データ（図２）および仕入先データ（図３）を受信し、各々、販売先データ記憶部１３１および仕入先データ記憶部１３２に格納する。販売先データおよび仕入先データは各々、取引先顧客（「企業番号」が示す企業）と、販売先および取引先企業との関係を示すデータである。なお、外部サーバ１００は、例えば、外部ネットワーク内に設置されたサーバである。本ステップの処理は、外部ＤＢから、販売先および仕入先の商流データを取得することを意味する。そのため、販売先データおよび仕入先データを複数の外部ＤＢから取得する場合、販売先データおよび仕入先データは、各々、複数存在することになる。また、各データのデータ項目である「企業番号」、「販売先企業番号」、および「仕入先企業番号」は、各外部ＤＢでユニークであればよい（管理元が各々異なるため、データフォーマットの統一は実質不可能）。そのため、与信管理システムで扱う場合、例えば、「企業番号」は、各々、「第１の企業番号」、「第２の企業番号」などと別項目として管理する必要がある。この場合、「第１の企業番号」および「第２の企業番号」が同一の企業であることを示すために、与信管理システムはマッピングテーブルなどにより、両番号の関連付けを行う。

次に、受信した販売先データおよび仕入先データに基づいて、商流データ作成手段１２１は商流データ（図４）を作成し、商流データ記憶部１３３に格納する（ステップ１１０２）。商流データは、取引先顧客（「企業番号」が示す企業）と、その取引先企業（「取引先企業番号」が示す企業）と関係を示すデータである。本実施形態では、「商流区分」が「１」の場合、取引先企業は取引先顧客に対する販売先企業であり、「２」の場合、仕入先企業である。「商流区分」は、商流データを作成する際のデータの取得元が、販売先データであるか、仕入先データであるかで決定することができる。なお、商流データは、企業間の振込実績などから作成することもできる。これは、例えば企業Ａに対し、企業Ｂから一定期間（３ヵ月など）に継続して複数回行われた場合、当該企業Ｂは当該企業Ａの販売先である（他方で企業Ａは企業Ｂの仕入先である）と判定することができ、各々、商流データを作成することができる。また、別の実施形態では、取引形態が手形取引である場合は、１回でもこれが発生した場合、両者が相互に取引先であると判定することができる。また、さらに別の実施形態では、外部サーバ１００から連携されてくるデータが、既に図４のようなフォーマットの商流データである場合、ステップ１１０１および１１０２は、単にこれを受信し、商流データ記憶部１３３に格納するだけである。なお、ステップ１１０２後、ステップ１１０３以降に進まずに、処理を終了することもできる。この場合、ステップ１１０３以降は別処理として実行される。

次に、予め為替明細データ記憶部１３４に格納された為替明細データ（図５）に対して、名寄せ手段１２３が、企業属性データ（図６）および名寄せ条件データ（図１０）に基づいて名寄せ処理を実行する（ステップ１１０３）。為替明細データは、入出金データであり、発信者（代金を支払う側）および受信者（代金を受け取る側）の金融機関および口座データ、ならびに取引額などを含む。しかしながら、各企業は、複数の口座を持つことがあり、同一の取引先企業との取引にも、複数の口座を利用することがある。そのため、為替明細データにおいて、口座名義が異なるため、別データ（レコード）として扱われる、本来は同一商流（取引先顧客と販売先とが実質的に同一、または取引先顧客と仕入先とが実質的に同一）に係るデータをサマリーするために、名寄せ処理を実行する。なお、名寄せ対象となる各口座は、同一の金融機関のものに限られず、異なる金融機関間の口座とすることもできる。

名寄せ処理は、為替明細データの口座名義に対し、所定の文字列を、削除したり、別の文字列に変換したりすることにより行われる。図５の為替明細データを例とすると、１レコード目から４レコード目の「受信口座名義」が示す、「ユウゲンガイシャトレードマークデザイン」および「（ユウ）トレードマークデザイン」は、全て同一の企業（図６の企業属性データの９レコード目が示す企業番号「999999999」の「ユウゲンガイシャトレードマークデザイン」）である。しかしながら、データ上、当該文字列は異なるものと判断されるため、図１０のような名寄せ条件データを用いて、データ変換を行う。例えば、図１０の名寄せ条件データの６レコード目は、文字列「（ユウ）」を文字列「ユウゲンガイシャ」に変換することを示す。これにより、「（ユウ）トレードマークデザイン」は、「ユウゲンガイシャトレードマークデザイン」に変換され、図５の１レコード目から４レコード目の「受信口座名義」は全て、図６の企業属性データの９レコード目と関連付けることができ、同一の企業であると判断することができる。なお、この際、さらに図６の企業属性データにおける金融機関コードおよび支店コードの各組み合わせと、為替明細データにおける金融機関コードおよび支店コードを突き合わせることにより、名寄せ処理の精度を向上させることができる。

また、図１０において「変換先」が空白であるものは、「変換元」を空白で変換する、すなわち「変換元」の文字列を削除することを意味する。なお、名寄せ条件データは、文字列の変換および削除用に、各々別のデータとして持つこともできる。

一方、「変換元」が示す文字列が重複する場合、例えば、図１０の１レコード目の「（カブ）」および２レコード目の「カブ）」は、口座名義の文字列が「（カブ）トッキョショウジ」の場合、どちらも該当することになる。しかしながら、２レコード目の「カブ）」を用いて変換を行うと、「（カブシキガイシャトッキョショウジ」と、「（」が残ってしまうことも考えられる。そのため、図１０の名寄せ条件データに、優先順位を持たせたり（図示しないが、優先順位を示す数値など）、図６に示されるように企業属性データが「法人格前後表示」を持つ場合はこれを利用したりすることができる。例えば、「法人格前後表示」が「０１」であり前表示を示す場合、口座名義の文字列「（カブ）トッキョショウジ」を前（左）から１文字ずつチェックすると、変換すべき文字列は「カブ）」ではなく、「（カブ）」であると判断することができる。

次に、商流為替明細データ作成手段１２２は、ステップ１１０３にて名寄せ処理を施した為替明細データから、商流データ（図４）および企業属性データ（図６）に基づいて、取引先顧客の入出金データを抽出し、商流為替明細データ（図７）を作成し、かつ商流為替明細データ記憶部１３６に記憶する（ステップ１１０４）。一実施形態では、商流データの企業番号が示す取引先顧客ごとに、取引月ごとにサマリーし、かつ時系列にソートし、商流為替明細データを作成する。

より具体的には、商流データ（図４）の「企業番号」および「取引先企業番号」を検索キーとして、企業属性データ（図６）から各々の「企業名カナ」を特定する（すなわち、企業番号が示す企業名カナと、取引先企業番号が示す企業名カナを取得する）。次に特定された各々の「企業名カナ」を検索キー（ＡＮＤ条件）として、名寄せ処理を施した為替明細データから、対象レコードを抽出する。この際、商流データ（図４）の「商流区分」によって、検索キー（企業番号が示す企業名カナおよび取引先企業番号が示す企業名カナ）と突き合わせる、名寄せ処理を施した為替明細データにおけるデータ項目は変わる。例えば、「商流区分」が「１」（販売先）である場合、取引先企業番号が示す企業が「販売先」である。そのため、取引先企業番号が示す企業は、為替明細データにおける発信者（代金を支払う側）となり、企業番号が示す企業は、受信者（代金を受け取る側）となる。一方で、「商流区分」が「２」（仕入先）である場合、取引先企業番号が示す企業は「仕入先」であり、かつ受信者（代金を受け取る側）となり、企業番号が示す企業が発信者（代金を支払う側）となる。したがって、「商流区分」によって、いずれの「企業名カナ」を、名寄せ処理を施した為替明細データにおける「発信者口座名義」および「受信者口座名義」と突き合わせるかが変わる。

企業番号および取引先企業が示す企業の各企業名カナと、「発信者口座名義」および「受信者口座名義」とを突き合わせ、為替明細データを取得した後、当該為替明細データにおける「取引日」を、例えば取引月ごとにサマリーし、時系列にソートすることで、図７に示すような商流為替明細データ（図７）を作成する。ここで、取引月ごとにサマリーする際、為替明細データの「取引額」を合計することで、商流為替明細データの「取引額計」を算出する。

次に、異常値捕捉手段１２４は、商流為替明細データ（図７）および倒産データ（図８）に基づいて、取引先顧客のアラームデータを作成する（ステップ１１０６）。本ステップは、アラームの種類ごとに処理される。アラームの種類ごとの処理する順番は不同である。アラームの種類ごとに処理を説明する。

取引先顧客が倒産したことを示す「倒産」アラームは、倒産データ（図８）における「倒産日」が一定期間内（例えば、直近２週間以内）の企業番号が示す企業が取引先顧客である場合に挙げるものである。該当する場合、図９のアラームデータに示すように「倒産」が「１」（倒産アラームＯＮ）となる。

取引先顧客に対する販売先または仕入先が倒産したことを示す「商流倒産」アラームは、「倒産」アラーム同様、倒産データ（図８）における「倒産日」が一定期間内の企業番号が示す企業が販売先および／または仕入先である場合に挙げるものである。可能性として販売先および仕入先が同時期に倒産することもあるため、一実施形態において、図９のアラームデータにおける「商流倒産」アラームは、販売先が倒産の場合に「１」、仕入先が倒産の場合に「２」、いずれも倒産の場合は「３」となる。

取引先顧客における入金が一定期間に所定の割合減ったことを示す「入金減」アラームは、商流為替明細データ（図７）において、受信者企業番号が示す企業を取引先顧客とした場合、発信者企業番号が示す企業、すなわち、販売先企業からの取引額計（入金額計）が前月の取引月と比較し、所定の割合減っている場合に挙げるものである。該当する場合、図９のアラームデータに示すように「入金減」が「１」（入金減アラームＯＮ）となる。また、別の実施形態では、「入金減」を非該当、小幅減、大幅減などと段階分けして各々を数値で示すことにより、より細かいアラームデータを示すことができる。

次に、データ送受信手段１２０は、作成したアラームデータをクライアント端末１０４に送信する（ステップ１１０７）。ステップ１１０７の後、本処理は終了する。その後、クライアント端末１０４において、アラームデータはＷｅｂ画面を通じて一覧表示したり、メールやインスタントメッセージで通知したりすることにより、金融機関担当者は取引先顧客の与信判断を行うことができる。

また、他の実施形態では、企業属性データ（図６）、商流為替明細データ（図７）、および倒産データ（図８）から、取引先顧客の商流捕捉およびニーズ分析することにより、営業推進に活用することもできる。これは、取引先顧客に対する入出金情報、取引先顧客ならびにその販売先および仕入先の倒産情報を所定の条件に基づいて定期的に捕捉する。捕捉した情報はクライアント端末１０４に送信され、クライアント端末１０４において一覧表示させることで、金融機関担当者は取引先顧客の動向およびニーズなどを判断することができる。例えば、取引先顧客に対し、ベンチャーキャピタル（ＶＣ）から入金があった場合、当該取引先顧客は出資受け入れのニーズがある、と判断することができる。また、取引先顧客の販売先が倒産してしまった場合、売掛金の回収のためファクタリング（売掛債権保証）のニーズがあると、判断することができる。さらに、取引先顧客から監査法人に対する出金があった場合、当該取引先顧客にはＩＰＯ（株式公開）のニーズがあると判断することができる。

Claims (6)

1. 為替明細データを利用し、金融機関に対する取引先顧客の与信データを管理するシステムであって、前記システムは、
   前記取引先顧客の販売先および仕入先データに基づいて、商流データを作成する手段と、
   前記為替明細データに対して名寄せ処理を実行する手段であって、前記名寄せ処理は、前記為替明細データにおける同一商流に係るデータをサマリーするために、前記為替明細データに含まれる前記取引先顧客、前記販売先、および前記仕入先の各企業名に含まれる文字列を、所定の文字列に変換し、前記変換した文字列と企業属性データにおける企業名とを関連付けることにより、前記為替明細データにおける同一企業に係るデータを認識する処理である、手段と、
   前記名寄せ処理を施した前記為替明細データから、前記取引先顧客の入出金データを抽出し、かつ同一商流に係るデータをサマリーし、商流為替明細データを作成する手段と
   を備えたことを特徴とするシステム。
2. 前記商流為替明細データおよび倒産データに基づいて、前記取引先顧客のアラームデータを作成する手段であって、前記アラームデータは、前記取引先顧客が倒産したこと、前記販売先が倒産したこと、前記仕入先が倒産したこと、および前記取引先顧客における入金が一定期間に所定の割合減ったこと、のうちの少なくとも１つを示すデータである、手段と、
   前記作成したアラームデータを、クライアント端末に送信する手段と
   をさらに備えたことを特徴とする請求項１に記載のシステム。
3. 前記為替明細データに含まれる前記各企業名は、前記取引先顧客、前記販売先、および前記仕入先の口座名義であり、
   前記名寄せ処理の精度を向上させるために、前記名寄せ処理は、前記為替明細データに含まれる口座名義の金融機関および支店コードと、前記企業属性データにおける金融機関および支店コードとを突き合わせることを含む
   ことを特徴とする請求項１または２に記載のシステム。
4. 前記販売先および前記仕入先データ、ならびに前記企業属性データを、外部サーバから受信する手段をさらに備えたことを特徴とする請求項１乃至３のいずれか１つに記載のシステム。
5. 為替明細データを利用し、金融機関に対する取引先顧客の与信データを管理する方法であって、前記方法は、
   前記取引先顧客の販売先および仕入先データに基づいて、商流データを作成するステップと、
   前記為替明細データに対して名寄せ処理を実行するステップであって、前記名寄せ処理は、前記為替明細データにおける同一商流に係るデータをサマリーするために、前記為替明細データに含まれる前記取引先顧客、前記販売先、および前記仕入先の各企業名に含まれる文字列を、所定の文字列に変換し、前記変換した文字列と企業属性データにおける企業名とを関連付けることにより、前記為替明細データにおける同一企業に係るデータを認識する処理である、ステップと、
   前記名寄せ処理を施した前記為替明細データから、前記取引先顧客の入出金データを抽出し、かつ同一商流に係るデータをサマリーし、商流為替明細データを作成するステップと
   を備えたことを特徴とする方法。
6. 為替明細データを利用し、金融機関に対する取引先顧客の与信データを管理する方法を実行するためのコンピュータ実行可能命令を有するコンピュータプログラムであって、前記方法は、
   前記取引先顧客の販売先および仕入先データに基づいて、商流データを作成するステップと、
   前記為替明細データに対して名寄せ処理を実行するステップであって、前記名寄せ処理は、前記為替明細データにおける同一商流に係るデータをサマリーするために、前記為替明細データに含まれる前記取引先顧客、前記販売先、および前記仕入先の各企業名に含まれる文字列を、所定の文字列に変換し、前記変換した文字列と企業属性データにおける企業名とを関連付けることにより、前記為替明細データにおける同一企業に係るデータを認識する処理である、ステップと、
   前記名寄せ処理を施した前記為替明細データから、前記取引先顧客の入出金データを抽出し、かつ同一商流に係るデータをサマリーし、商流為替明細データを作成するステップと
   を備えたことを特徴とするコンピュータプログラム。

Images