図1は、本発明の一実施形態にかかる融資管理システムのシステム構成を示す。
図1に示された融資管理システム20は、例えば或る一つの銀行(金融機関)で利用され、その銀行の勘定系のホストコンピュータ(以下、「ホスト」という)10と通信可能に接続されている。融資管理システム20とホストコンピュータ10との間の通信は、ホスト連携サーバ21によって仲介される。ホスト10は、顧客の預金口座及び金銭の出入り等を制御するものであり、通信ネットワーク11を介して、この銀行の様々な店舗やその他の場所に置かれたATMやその他の勘定系処理に利用可能な端末12、12、…と接続されている。
ホスト10から融資管理システム20へは、例えば、ホスト10が用いている顧客のID(ホスト顧客ID)や、顧客の預金、貸金及び返済等に関する情報が提供される。また、融資管理システム20からホスト10へは、例えば、案件審査の結果である融資実行の決定に関する情報が送られる。
融資管理システム20は、例えば、複数のWEBサーバ22、22、…及び複数のアプリケーションサーバ23、23、…から構成される融資業務サーバ組織24を有する。さらに、融資管理システム20は、融資関連データベース27を管理する融資データベースサーバ26を有する。融資業務サーバ組織24と融資データベースサーバ26は通信可能に接続されている。また、この銀行の本店や営業店等のオフィスに置かれた融資業務に利用可能な端末29、29、…が、通信ネットワーク28を介して、この融資管理システム20に通信可能に接続されている。
融資業務サーバ組織24のWEBサーバ22、22、…は、端末29、29、…に対して融資業務の様々なサービスを行なうために多種多様なグラフィカルユーザインタフェースを提供する。アプリケーションサーバ23、23、…は、端末29、29、…に表示された上記グラフィカルユーザインタフェースを用いたオペレータによるデータ入力やその他の様々な操作に応答して、融資業務の様々なサービスを実行するための様々なオペレーションを実行する。複数のWEBサーバ22、22、…間で、及び複数のアプリケーションサーバ23、23、…間で、それぞれ、処理負荷ができるだけ均等に配分されるよう、ロードバランス制御を行なうことができる。
融資関連の様々なデータが、融資関連データベース27に蓄積され、融資データベースサーバ26によって管理されている。アプリケーションサーバ23、23、…は、融資関連データベース27内の融資関連データを用いて、融資業務の様々なサービスを進めるための様々なオペレーションを実行する。
さらに、融資管理システム20は、集配信サーバ32と通信ネットワーク30を介して、幾つかの外部コンピュータシステム31、31、…にも接続されている。外部システム31、31、…には、例えば、企業に関する様々な基礎的及びアップデートなデータを提供する企業情報システムや、企業から公表された財務データ(決算書類など)を提供する財務データシステムや、不動産の担保価値としての評価データを提供する不動産評価システムや、建築物等の火災保険の証書データを提供する火災保険データシステムや、手形に関するデータを提供する手形管理システムなどが含まれ得る。
図2は、融資管理システム20によって実現される融資業務の様々なサービス間の連携の概要を示している。
図2に示すように、融資管理システム20によると、融資業務は目的の異なる4種類のサービスに大別される。第1のサービスは情報収集50であり、これは、融資業務に必要又は有用な様々な情報を収集する様々なジョブの集合である。情報収集50で収集される情報には、例えば、顧客の基本的情報、顧客との交渉の履歴、顧客の預金・貸金の情報、各種の期日の情報、各種プロセスの進捗の情報、担保の情報などがある。
第2のサービスは、企業審査・自己査定60であり、これはさらに、企業審査と自己査定の2つのサブサービスに分けることができる。企業審査は、個々の顧客(企業又は個人)の信用リスクを評価して、その顧客の信用格付け、債務者区分及び融資方針を決定するサービスである。
企業審査は、例えば、顧客の決算月が来て決算書類が出た時点、又は顧客の信用リスクを見直す必要があるような格別の事象(例えば、業務状況の急変、延滞長期化の兆候、倒産、など)が発生した時点などに行なわれる。企業審査には、財務データ(決算書類)に対する定量評価、財務データ以外の情報(例えば、業界状況、立地条件、経営方針、資本金、株価、業種、株主、など)に対する定性評価、これらの評価結果に基づく信用格付、債務者区分の決定、融資方針の策定などのプロセスが含まれる。
一方、自己査定は、銀行が自己の資産を自ら評価するものであるが、そこでは、銀行が自己の債権(典型的には顧客への貸出金)の回収可能性を、個々の顧客ごとに評価して損失金額を算定し、これに基づき償却・貸倒引当金を算出する(この実施形態では、償却・引当額の算定までを融資管理システム20で行ない、引当金の計上をホスト10で行う)。自己査定は、金融庁の「金融検査マニュアル」の規程に従い、少なくとも年2回(典型的には、銀行の3月と9月の決算月に)行なわれる。自己査定では、企業審査の結果が利用されるが、更に、企業審査の実施時期から自己査定の実施時期までの間に発生した関係事象に関するアップデートな情報をも加味される。
第3のサービスは案件審査70であり、これは、顧客から融資の申込みを受け付け、申し込まれた融資を実行するか否かを判断し、実行する場合には融資条件を決定する仕事である。案件審査70には、案件(融資申込み)受付、案件審査資料の作成、融資を実行するか否かの稟議、融資実行の決定、顧客から預かった書類や物品(重要物)の管理などのプロセスが含まれる。
第4のサービスは債権管理80であり、これは、実行した融資に係る債権の状態を管理し、保守し、実行する仕事である。債権管理80には、正常債権の管理、延滞債権の管理、訴訟の管理、整理貸付先の管理、回収不能債権の償却、各種期限の管理などが含まれる。
融資管理システム20では、前述したアプリケーションサーバ23、23、…が融資関連データベース27を利用しながら行なう様々なオペレーションによって、上述した4種類のサービス50、60、70、80間の連携が実現される。図2において、4種類のサービス50、60、70、80間に示された太い矢印は、特にそれらサービス50、60、70、80間の情報の連携(情報の流れ)の主要なものを示している。これらの矢印に示されるように、情報収集50によって収集された様々な情報(例えば、顧客の基本情報、業務状況、交渉履歴、預金・貸金情報、返済延滞情報、担保情報、悪化事象の情報など)は、その顧客に関する企業審査・自己査定50、案件審査70及び債権管理80で活用される。また、企業審査・自己査定50の結果得られた情報(例えば、顧客の信用格付け、債務者区分、融資方針など)が、その顧客が申し込んだ融資の案件審査70で活用される。また、案件審査70において得られた情報(例えば、顧客から提供された担保(取入担保)の情報、保証人の情報、重要物の情報など)は、その顧客の債権に関する債権管理80で利用される。また、債権管理80で得られた情報(例えば、顧客との交渉結果、次回交渉期日、整理貸付先の登録、償却債権の登録など)は、情報収集50で収集された情報に反映される。さらに、図2には示された主要な情報連携以外にも、様々な情報連携や処理タイミングの制御が上記4種類のサービス50、60、70、80間に存在し、それらは以下の説明で明らかにされる。
図3は、融資管理システム20(特に、図1に示したアプリケーションサーバ23、23、…)が持つ様々な処理コンポーネントを、融資業務を構成する上記4種類のサービス50、60、70、80毎に分類して示したものである。
図3に示すように、融資管理システム20は、例えば9個のサブシステム100〜900、すなわち、顧客管理サブシステム100、企業審査サブシステム200、自己査定サブシステム300、案件審査サブシステム400、担保管理サブシステム500、債権管理サブシステム600、ワークフローサブシステム700、進捗管理サブシステム800、重要物管理サブシステム900から構成される。
顧客管理サブシステム100は、主に顧客に関する情報を管理するためのものであり、そこには、顧客情報処理110、交渉経過処理120及び預貸(預金と貸金)情報処理130などの処理コンポーネントが含まれる。
企業審査サブシステム200は、主に企業審査を行なうためのものであり、そこには、金融取引情報処理210、定性評価処理220、審査管理処理230、公表財務処理240、実態財務処理250、抽出区分処理160、信用格付処理270、債務者区分処理280及び融資方針処理290などの処理コンポーネントが含まれる。
自己査定サブシステム300は、主に自己査定を行なうためのものであり、そこには、自己査定管理処理310、抽出区分処理320、保全情報処理330、債務者区分処理340及び分類額処理350などの処理コンポーネントが含まれる。
案件審査サブシステム400は、主に案件審査を行なうためのものであり、そこには、案件受付処理410、案件登録処理420、タスク管理処理430、案件協議処理440、案件稟議処理450及び案件実行処理460などの処理コンポーネントが含まれる。
担保管理サブシステム500は、主に取入担保及び保証人の情報を管理するためのものであり、そこには、担保・保険データ処理510、担保処理540及び保証人処理550などの処理コンポーネントが含まれる。
債権管理サブシステム600は、主に、実行された融資に関わる債権を管理するためのものであり、そこには、悪化事象処理610、再審査処理620、延滞先処理630、訴訟処理640、仮払金処理650、取立益処理660、整理貸付先処理670及び償却引当先処理680などの処理コンポーネントが含まれる。
ワークフローサブシステム700は、主に稟議や協議などでの異なる人々間のワークフローを制御するためのものであり、そこには、審査決裁処理710、案件協議処理720及び案件決裁処理730などの処理コンポーネントが含まれる。
進捗管理サブシステム800は、主に、様々な期日を管理して時期を失した手続きが発生しないようにするためのもので、そこには、決算期日処理810及び事件期日処理820などの処理コンポーネントが含まれる。進捗管理サブシステム800が提供する機能には、期日管理機能及びお知らせ機能がある。期日管理とは現在未実施の作業に対して作業の期限が迫っていることを通知するものである。通知される期限には、例えば、決算期日、訴訟期日、重要物書類有効期限、案件協議期限、交渉経過次回交渉予定日、時効完成予定日、担保評価期限日、案件実行予定日などがある。お知らせ機能は、システムに対して何らかの事項が登録が行われると、それを即刻に必要な部署やユーザに対して通知する機能である。通知される登録事項には、例えば、監査報告通知、悪化事象報告、整理貸付先指定・解除などがある。さらに、進捗管理サブシステム800が、企業審査のプロセスや案件審査のプロセスの進捗管理機能(例えば、企業審査又は案件審査のプロセスで既に始まったタスクの進捗状況に応じて画面上に進捗の進行を促す情報を出力したりする機能)も提供するようにしてもよい(本明細書の以下の説明では、上述した企業審査サブシステム200及び案件審査サブシステム400でそれぞれ行なうように説明されている)。
重要物管理サブシステム900は、顧客から預かった重要書類や物品の情報を管理するためのもので、そこには、重要物処理910という処理コンポーネントが含まれる。
図3に示すように、上述した9つのサブシステム100〜900に含まれる多数の処理コンポーネントは、融資業務を構成する4種類のサービス、すなわち、情報収集、企業審査・自己査定、案件審査及び債権管理をそれぞれ行なうための4つのグループ50、60、70、80に分類することができる。
例えば、顧客管理サブシステム100の顧客情報処理110、交渉経過処理120及び預貸(預金と貸金)情報処理130、企業審査サブシステム200の金融取引情報処理210及び定性評価処理220、担保管理サブシステム500の担保・保険データ処理510、並びに債権管理サブシステム600の悪化事象処理610及び再審査処理620などは、情報収集のためのグループ50に分類することができる。
また、例えば、企業審査サブシステム200の審査管理処理230、公表財務処理240、実態財務処理250、抽出区分処理160、信用格付処理270、債務者区分処理280及び融資方針処理290、自己査定サブシステム300の自己査定管理処理310、抽出区分処理320、保全情報処理330、債務者区分処理340及び分類額処理350、ワークフローサブシステム700の審査決裁処理710、並びに進捗管理サブシステム800の決算期日処理810などは、企業審査・自己査定のためのグループ60に分類することができる。
また、例えば、案件審査サブシステム400の案件受付処理410、案件登録処理420、タスク管理処理430、案件協議処理440、案件稟議処理450及び案件実行処理460、担保管理サブシステム500の担保処理540及び保証人処理550、ワークフローサブシステム700の案件協議処理720及び案件決裁処理730、並びに重要物管理サブシステム900の重要物処理910などは、案件審査のためのグループ70に分類することができる。
さらに、例えば、債権管理サブシステム600の延滞先処理630、訴訟処理640、仮払金処理650、取立益処理660、整理貸付先処理670及び償却引当先処理680、並びに進捗管理サブシステム800の事件期日処理820などは、債権管理のためのグループ80に分類することができる。
なお、上述した処理コンポーネントの中には、異なるグループの何れにも所属可能な類のものが幾つかあるが、そのような類の処理コンポーネントは、説明の都合により何れか一つのグループに分類してある。例えば、公表財務処理240は、情報収集のためのグループ50にも企業審査・自己査定のためのグループ60にも所属類可能であろうが、図3では一応、企業審査・自己査定のためのグループ60に分類されている。また、例えば、重要物処理910は、情報収集のためのグループ50にも案件審査のためのグループ70にも所属可能であろうが、図3では一応、案件審査のためのグループ70に分類されている。このように、図3に示すサービス別の分類の仕方は(及び、これを踏襲した後述の図4〜図8に示す分類も)便宜的な例示にすぎないものであり、それ以外の分類の仕方を排除するような制限的なものではない。
以下、上述した4つのサービス間の連携を明らかにするために、図4〜図7を参照して、図3に示した処理コンポーネントが行なう具体的なオペレーション又は機能と、それに関連するデータの流れを説明する。
図4は、図3において情報収集のグループ50に分類された処理コンポーネントの具体的なオペレーション又は機能と、それに関連するデータの流れを示す。図5は、図3において企業審査・自己査定のグループ60に分類された処理コンポーネントの具体的なオペレーション又は機能と、それに関連するデータの流れを示す。図6は、図3において案件審査のグループ70に分類された処理コンポーネントの具体的なオペレーション又は機能と、それに関連するデータの流れを示す。図5は、図3において債権管理のグループ80に分類された処理コンポーネントの具体的なオペレーション又は機能と、それに関連するデータの流れを示す。
なお、図4〜図7に示された各ブロックと図3に示された処理コンポーネントとで互いに対応するものには、上位2桁値で共通する参照番号を付してある。また、図4〜図7に示されたデータベースのシンボル形のブロックは、図1に示した融資関連データベース27内に設けられた情報種類別の記憶部(例えば、データテーブル、ファイル、リストなど)を意味する。
図4を参照して、情報収集のサービスに関わる処理コンポーネントの具体的なオペレーション又は機能、及びそれに関連するデータ流れを以下に説明する。
まず、図4に示された顧客管理サブシステム100の処理コンポーネントに関して説明する。
顧客情報登録処理111は、顧客に関する様々な情報(顧客情報)の入力を受け、入力された顧客情報を顧客情報記憶部112に格納する。なお、顧客には個人もいれば企業もいるが、以下では、特に企業顧客を例にとり説明する(その説明から、個人顧客の場合の処理も自ずと理解できる筈である)。
顧客情報記憶部112に記録される顧客情報の項目には、例えば、基本情報(例えば、顧客ID、名称、所在地など顧客を特定する事項)、決算月、企業概要(例えば、業種、立地条件、資本金、株価、株主、役員、仕入先・販売先など)、信用情報(例えば、倒産情報、外部機関による信用格付けデータ、事故履歴など)、及びその顧客の銀行内担当情報(例えば、担当者、取引店(主管店、関係店))などがある。顧客情報の全項目は、権限をもったログオンユーザが端末から手作業で入力することができるが、一部の項目(例えば企業概要や信用情報など)は、企業情報システムや企業信用格付けシステムなどの外部システムから電子データの形で受け取り自動的に入力することもできる。
顧客情報記憶部112に記録された顧客情報は、融資業務のあらゆる側面で利用されることになる。例えば、各企業の企業概要は、定性評価登録処理221によって、その顧客の信用リスクの定性評価を行なう際に、顧客情報記憶部112から読み出されて端末画面に表示され得る。また、例えば、各顧客の決算月は、データ流れA1に示すように、図5に示された決算月記憶部812に送られて記録され、決算月処理811によって、その顧客の財務データを取得して入力する作業の開始時期の制御に利用される。また、例えば、各顧客の銀行内担当情報は、図示してないが、その顧客の所定情報にアクセスしたり、その顧客について企業審査、自己査定又は案件審査を行なったりすることができる店部署又はユーザを制限するために利用される。
顧客ID連携処理113は、ホスト10側が使用している全顧客の顧客ID(以下、「ホスト顧客ID」という)(例えば、CIFと略称される一般顧客IDと、LIFと略称される融資顧客IDである)をホスト10から自動的に受信して、ホスト顧客ID記憶部114に自動的に格納する。さらに、顧客ID連携処理113は、ホスト顧客ID記憶部114に格納されたホスト顧客IDを、前述した顧客情報記憶部112に格納された顧客ID(これは、融資管理システム20が内部的に使用する顧客IDであり、以下、「内部顧客ID」という)に、ユーザの手動操作によって又は自動的に紐付ける。このホスト顧客IDと内部顧客ID間の紐付けにより、ホスト10が識別する顧客報と融資管理システム20が識別する顧客とが対応付けられる。
交渉経過登録処理121は、ログオンユーザをして、顧客に対して行なった各種交渉の経過情報((以下、「交渉履歴」という)を随時に端末に入力する(例えばテキスト形式のコメントとして入力する)ことを可能にならしめ、そして、入力された交渉履歴を交渉履歴記憶部122に格納する。また、交渉経過登録処理121は、顧客との交渉履歴を交渉履歴記憶部122から読み出して端末画面に表示する。交渉経過登録処理121は、交渉履歴記憶部122内の交渉履歴を内部顧客IDで顧客ごとに管理する。
交渉経過登録処理121は、顧客との交渉履歴を入力することができる権限を、顧客毎に予め定まった特定の店、部署又はユーザにのみ制限することができる。また、交渉経過登録処理121は、任意の内部顧客IDを指定することで、任意の顧客の交渉履歴を端末画面で参照することを、何れのログオンユーザにも許可することができる。よって、記録された交渉履歴は営業報告にも利用できる。
データ流れB1、B2に示すように、図7に示す延滞先管理処理631も、ログオンユーザをして、顧客(主に、返済が延滞している顧客であり、以下「延滞先」という)に対する交渉の履歴(例えば、返済督促交渉の経過、返済約束、返済予定日、次回の督促訪問予定日など)を端末に入力することを可能にならしめ、そして、入力された交渉履歴を交渉履歴記憶部122に格納し、また、任意の延滞先に関する交渉履歴を交渉履歴記憶部122から読み出して端末画面に表示することができる。
預貸(預金・貸金)データ連携処理131は、ホスト10が管理している全顧客の預貸情報(預金の明細情報と貸金の明細情報)及び延滞情報(返済延滞の明細情報(例えば、貸出元金、残金、延滞日数、延滞額、その内訳など))の最新データを、ホスト10から実質的に実時間で(例えば、毎日4回)定期的に且つ自動的に受信する。受信の頻度は例えば毎日4回であり、よって、受信した情報は、顧客の実際の預貸及び延滞の状態を実質的に実時間で表している。そして、預貸データ連携処理131は、受信した預貸情報を預貸記憶部132に格納し、受信した返済延滞情報は延滞記憶部133に格納する。記録された預貸情報及び延滞情報は、企業審査、自己査定、案件審査及び債権管理などで活用される。
次に、図4に示された企業審査サブシステム200の処理コンポーネントに関して説明する。
金融取引明細登録処理211は、ログオンユーザをして、顧客が他の金融機関と行なった金融取引の明細情報(例えば、顧客から申告されたもの)(以下、「金融取引明細情報」という)を端末に入力することを可能にならしめ、そして、入力された金融取引明細情報を金融取引明細記憶部212に格納する。データ流れE1に示すように、金融取引明細記憶部212に格納された金融取引明細は、図5に示されたた企業審査における抽出区分処理261により利用される。
定性評価登録処理221は、ログオンユーザをして、各顧客の信用リスクに関する定性評価の結果を端末に入力することを可能にならしめ、そして、入力された定性評価結果を定性評価記憶部222に格納する。ここで、定性評価とは、財務データ以外で顧客の信用リスクに影響する所定の情報項目を評価することである。定性評価の対象となる情報項目には、例えば、業種、立地条件、業界内競争力、商品、サービス、技術力、管理能力、設備状況、役員、仕入先、販売先などがあり得る。定性評価を支援するために、定性評価登録処理221は、定性評価結果の入力を受付ける際に、定性評価の判断材料となる顧客情報(特に、上述した企業概要や信用情報など)を顧客情報記憶部112から読み出して端末画面に表示したり、或いは、預貸情報を預貸情報記憶部132から読み出して端末画面に表示したりすることができる。
データ流れF1〜F3に示すように、定性評価記憶部222に記録された定性評価結果は、図5に示された企業審査及び自己査定のサービスで利用される。特に、データ流れF2に示すように、定性評価結果は、企業審査における信用格付け処理271により顧客の信用格付けを決めるために利用される。
定性評価登録処理221は、図5に示された企業審査のプロセスの中ではなく、顧客情報登録処理111(特に企業概況のような定性評価の材料となる情報の登録)に付随して実行されるようになっている。このように定性評価を企業審査のプロセスから切り離すことで、企業審査を行なっているユーザの恣意の影響を受けないようになり、適正な定性評価結果が得易くなる。
次に、図4に示された担保管理サブシステム500の処理コンポーネントに関して説明する。
不動産担保データ連携処理511は、特定の不動産(典型的には、図6に示された案件審査における担保登録処理541により取入担保として担保記憶部542に登録された不動産)に関する担保価値評価を外部の不動産評価システムに依頼して、その不動産評価システムから提供される当該取入不動産担保の担保価値評価データを受け取り入力して、入力された担保価値評価データを不動産担保記憶部512に格納する。
火災保険データ連携処理513は、特定の不動産(典型的には、上述した取入不動産担保)に関する火災保険証書のデータを外部の火災保険データシステムに依頼して、その火災保険データシステムから提供される当該不動産の火災保険証書データを受け取り入力して、入力された火災保険証書データを火災保険記憶部514に格納する。
手形データ連携処理515は、特定の手形(典型的には、図6に示された案件審査における担保登録処理541により取入担保として担保記憶部542に登録された手形)の照会を外部の手形管理システムに対して行なって、その手形管理システムから提供される当該取入手形のデータを受け取り入力して、入力された手形管理データを手形記憶部516に格納する。
データ流れG1、H1、I1に示すように、不動産担保記憶部512、火災保険記憶部514及び手形記憶部516にそれぞれ格納された不動産担保評価データ、火災保険証書データ及び手形データは、図6に示される案件審査における担保紐付処理543により、担保記憶部542内の対応する不動産担保及び手形のデータにそれぞれ紐付けられる。
また、データ流れG2、H2、I2に示すように、上述の不動産担保評価データ、火災保険証書データ及び手形明細データ(特に、担保評価の有効期限、保険契約の有効期限、手形の期限などの期日データ)は、図7に示される債権管理における事件期日記憶部822に送られて記録され、事件期日処理821によりそれらの期日の管理に利用される。
また、データ流れG3、H3、I3に示すように、上述の不動産担保評価データ、火災保険証書データ及び手形明細データは、図6に示される案件審査のサービスでも利用される。
次に、図4に示された債権管理サブシステム600の処理コンポーネントに関して説明する。
悪化事象登録処理611は、ログオンユーザをして、顧客の事業状況の悪化に関わる事象(以下「悪化事象」という)に関する情報(例えば、事象区分コードと情報源コードとテキスト形式の事象説明文のセット)を端末に入力することを可能にならしめ、そして、入力された悪化事象情報を、悪化事象の発生日時及び入力日時の情報とともに、悪化事象記憶部612に格納する。悪化事象登録処理611は、顧客情報記憶部112に登録されている内部顧客IDで顧客毎に悪化事象を管理する。悪化事象の区分には、例えば、事業状況の急激悪化、事故発生の兆候、債権保全状況の悪化、処罰・処分、死亡、延滞長期化見込み、他債権者からの法的請求、実質的な倒産、整理手続開始、不渡り、取引停止処分などがあり得る。悪化事象の情報源には、例えば、債務者、保証人、家族、従業員、取引先、同業者、手形交換所、裁判所、弁護士、登記簿謄本、マスメディアなどがあり得る。
再審査処理621は、悪化事象記憶部612に登録された顧客の悪化事象を読み出し、銀行内の然るべき特定の部署(例えば、審査部)に属するログオンユーザの端末画面に表示して、その顧客について再度の企業審査(以下、「再審査」という)を実行するべきか否かの判断材料をそのログオンユーザに提供する。そして、再審査処理621は、その特定部署のログオンユーザをして、再審査を行なうか否かの判断結果を端末に入力することを可能にならしめる。そして、再審査処理621は、再審査を行なうという判断結果が入力された場合には、データ流れJ1に示すように、図5に示された企業審査における企業審査管理記憶部232に、その顧客についての再審査の実行指示を登録する。この指示は、その顧客を担当するログオンユーザが所属する店又は部署の端末に表示され、そのログオンユーザをして、再審査を実行することを可能にならしめる。また、データ流れJ2、J3に示すように、その顧客の悪化事象をその顧客についての企業審査(特に、再審査)及び自己査定に反映させるために、少なくとも再審査の実行指示が出た悪化事象情報(特に、事象区分コード)(さらに、再審査実行指示が出ていない悪化事象情報を含めても良い)は、再審査処理621を通じて、図5に示された企業審査における抽出区分処理261、及び自己査定における自己査定管理処理311に利用される。
次に、図5を参照して、企業審査・自己査定のグループ60に分類された処理コンポーネントのオペレーション又は機能と、それに関連するデータ流れについて説明する。
まず、図5に示された進捗管理サブシステム800の処理コンポーネントに関して説明する。
決算期日記憶部812には、既に説明したように、図4に示された顧客情報記憶部112内の顧客の決算期日のデータが送られてきてここに格納されている。決算月処理811は、決算期日記憶部812から、決算月が来た顧客を検索して、検索された顧客についての決算月到来情報を、企業審査サブシステム200の企業審査管理記憶部232に登録する。
次に、図5に示された企業審査サブシステム200の処理コンポーネントに関して説明する。
審査管理処理231は、企業審査管理記憶部232に登録された様々な顧客についての決算月到来情報に基いて、それら決算月の到来した顧客のリストをログオンユーザの端末画面に表示する。なお、各ログオンユーザの端末画面に表示された顧客リストには、そのログオンユーザが担当する顧客、又はそのログオンユーザが所属する店又は部署が担当する顧客だけに絞られている。各ログオンユーザの端末画面に表示された決算月の到来した顧客のリストは、そのログオンユーザに対して、それら顧客の財務データを取得して入力することを促す意味がある。
また、審査管理処理231は、各顧客についての企業審査の進捗を管理する。審査管理処理231は、まず、後述する財務データ連携処理241若しくは財務データ手入力242、又は図4に示した再審査処理621によって企業審査管理記憶部232に登録された様々な顧客についての企業審査又は再審査の実行指示を読む。そして、審査管理処理231は、その企業審査又は再審査の実行指示の対象となった顧客のリストを、ログオンユーザの端末画面に表示する。なお、各ログオンユーザの端末画面に表示された審査対象の顧客のリストには、そのログオンユーザが担当する顧客、又はそのログオンユーザが所属する店又は部署が担当する顧客だけに絞られている。
ログオンユーザが上記審査対象の顧客のリストの中から任意の顧客を選択すると、それに応答して、審査管理処理231は、ログオンユーザをして、その選択された顧客について企業審査又は再審査を開始することを可能にならしめる。これにより、各顧客の財務データ(決算書類)が入力された時(つまり、決算月が終わった時)、又は、その顧客の事業に関して何らの悪化事象が発生した時に、タイムリーにその顧客の企業審査又は再審査が実施できることになる。
ただし、審査管理処理231は、上記選択された顧客について企業審査又は再審査を実際に開始する前に、データ流れF1に示すように、図4に示した定性評価記憶部222にその顧客の当期の定性評価結果が登録済みであるか否かをチェックする。もし、その顧客の当期の定性評価結果が未だ登録されていなければ、審査管理処理231は、先に定性評価を行なうよう要求する警告メッセージを、ログオンユーザの端末画面に表示する。ログオンユーザは、図4に示した定性評価登録処理221を起動して、定性評価を行なうことができる。これにより、必ず当期の最近の情報に基づいた定性評価の結果が、企業審査又は再審査に反映されることになる。
さらに、審査管理処理231は、上記選択された顧客について企業審査又は再審査を実際に開始する前に、企業審査管理記憶部232に、その顧客の最近決算による財務データが登録済であるか否かもチェックする。もし、最近決算による財務データが未だ登録されていなければ、審査管理処理231は、財務データを登録するよう要求する警告メッセージを、ログオンユーザの端末画面に表示する。財務データは、後述する財務データ連携処理241又は財務データ手入力処理242によって、企業審査管理記憶部232に登録することができる。
従って、審査管理処理231は、上記選択された顧客について当期の定性評価が終わっており且つ当期の財務データが登録済みである場合に限り、その顧客についての企業審査又は再審査を開始することを許可する。
企業審査が開始されると、審査管理処理231は、その開始時の日時の情報を企業審査管理記憶部232に格納するとともに、企業審査のプロセスを構成する複数のタスク処理、すなわち、後述する財務計算処理244、実態データ登録処理251、抽出区分処理261、信用格付処理271、債務者区分登録処理281及び融資方針登録処理291が、この順序で逐次に実行されるよう、それらタスクの処理順序を制御する。よって、前のタスクが完了しない限り、次のタスクに進めない。このようなタスクの処理順序制御により、誰が企業審査を行なっても、必要な全てのタスクを適切な順序で実行することになるので、企業審査の精度が向上する。
特に、抽出区分処理261が企業審査のプロセスで実行されるようになっていて、しかも、抽出区分処理261が信用格付処理271、債務者区分登録処理281及び融資方針登録処理291の前に実行されることは、注目に値する。後述するように、抽出区分処理261は、企業の健康状態を示すカルテ又はバロメータのようなものであり、元来は、後述する自己査定において、自己査定の対象となる顧客を抽出するために用いられるものである。抽出区分処理261が企業審査のプロセスで行なわれるということは、顧客の健康状態のチェックが銀行の日常的な業務の中でチェックされ把握されていることを意味する。しかも、それが、信用格付処理271、債務者区分登録処理281及び融資方針登録処理291の前に実行されるということは、その顧客の健康状態のカルテ又はバロメータが考慮に入れられて、その顧客の信用格付、債務者区分及び融資方針が決定され得ることを意味する。結果として、企業審査の精度が向上する。
他方、再審査が開始された場合には、審査管理処理231は、最近に行なわれた企業審査での実態データ登録処理251で実態データが登録された状態から再度の企業審査を開始して、実態データ登録処理251以降の抽出区分処理261などのタスクを上記の順序で再度実行するように、制御を行なう(ただし、実態データ登録処理251において、実態データを再作成することもできる)。毎年定期に到来する決算月と異なり、悪化事象は随時に生じるのであるが、これをトリガとして且つこれを考慮に入れて、企業審査が再度行なわれることにより、企業審査の精度が向上し、企業審査の結果は顧客のアップデートな状態を反映したものとなり、そして、その企業審査の結果を自己査定や案件審査に利用して自己査定や案件審査の精度と能率を高めることが可能になる。
さらに、企業審査又は再審査のプロセスが終わると、その審査結果の稟議の制御も行なう。この稟議の制御については、後に審査決裁処理711を説明するときに一緒に行なう。稟議により審査結果が承認されて正式に確定すると、審査管理処理231は、その確定時の日時の情報を企業審査管理記憶部232に格納する。
財務データ連携処理241は、ログオンユーザが所望するときに起動されて、企業財務データ提供システムのような外部システムから、決算月の来た顧客の財務データ(貸借対照表及び損益計算書などの決算書類のデータ)を自動的に入力し、そして、入力された財務データを、その財務データの日付の情報や、その財務データの入力時の日時の情報などとともに、企業財務記憶部243に格納する。他方、財務データ手入力処理部242は、ログオンユーザが所望するときに起動されて、そのログオンユーザをして、任意の顧客の財務データを端末から入力することを可能にならしめ、そして、入力された財務データを企業財務記憶部243に格納する。各ログオンユーザは、そのログオンユーザの端末画面に表示された上述の決算月の到来した顧客のリストを参照することで、どの顧客の決算月が到来したかが分かるから、それに基いて、財務データ連携処理241を起動してその顧客の財務データを外部システムから自動的に入力するか、又は、手作業でその顧客の決算書類を入手してその財務データを財務データ手入力処理部242により入力することができる。顧客に応じて、財務データ連携処理241と財務データ手入力処理部242の何れを用いるかを使い分けることができる。財務データ連携処理241又は財務データ手入力処理部242は、顧客の財務データが入力されると、上記の決算月の到来した顧客のリストの中からその顧客のデータを削除するとともに、その顧客についての企業審査の実行指示を作成して企業審査管理記憶部232に登録する。既に述べたように、顧客についての企業審査実行指示が企業審査管理記憶部232に登録された場合に、企業審査管理処理231が、その顧客の企業審査プロセスを開始することになる。
なお、財務データ連携処理241又は財務データ手入力処理部242によって登録された顧客の財務データは、その顧客により自発的に公表されたものであり、これを以下「公表財務データ」と呼ぶ。
実態データ登録処理251は、企業財務記憶部243に格納された顧客の公表財務データを読み出してログオンユーザの端末画面に表示し、そして、そのログオンユーザをして、その公表財務データをその顧客の実際の業務状況に出来るだけ適合するように修正することを可能にならしめる。例えば、そのログオンユーザは、顧客に関する自己知識に基づいて、公表財務データ上の各勘定科目の資産性の有無や、各科目の内訳明細を、実態データ登録処理251で追加的に登録することにより、公表財務データを顧客の業務実態に合った内容に修正することができる。実態データ登録処理251は、ログオンユーザによって修正された財務データ(以下、「実態財務データ」という)を、その時の日時の情報と共に、企業財務記憶部243に格納する。企業財務記憶部243に格納された実態財務データは、企業審査の後続のタスクで利用されるだけでなく、データ流れL1に示すように、企業財務記憶部243に格納された実態財務データは、図6に示された案件審査のプロセスでも利用され得る。
財務計算処理244は、企業財務記憶部243に格納された顧客の実態財務データを読み込み、自動的に所定の1又は複数種類の財務分析方法を用いて所定の複数種類の財務比率を計算し、そして、計算された財務比率のデータを財務比率記憶部242に格納する。財務比率記憶部242に格納された顧客の財務比率データは、例えばプリントアウトの形で出力されて、その顧客に対する経営アドバイスサービスに活用され得る。
抽出区分処理261は、顧客の業務状況が、所定の多数の自己査定抽出区分の各々に該当するか否かを、所定のロジックを用いて自動的に判定する。ここで、自己査定抽出区分とは、多数の顧客の中から自己査定の対象を抽出するための重要なチェック項目であり、例えば、大口先、延滞先、赤字先、経常利益の赤字、当期利益の赤字、繰越利益の赤字、無配当、株価額面割れ、前回の債務者区分が正常先以外、などがあり得る。このような自己査定抽出区分のどれに該当するかという判定結果は、要するに、企業の健康状態のカルテに相当する。顧客がいずれかの自己査定抽出区分に該当すれば、不健康要因を有することになり、そのような顧客は、後述する自己査定のプロセスにおいて、査定対象として抽出されることになる。一方、何れの自己査定抽出区分にも該当しない顧客は、健康であるということであり、原則として、後述する自己査定のプロセスにおいて、査定対象から外されることになる(但し、そうであっても、後の自己査定プロセスで行われる抽出区分処理の結果、何れかの抽出区分に該当することになった場合には、査定対象に組み込まれることになる)。
抽出区分処理261が上記自動判定に用いる材料は、データ流れA9で示されるような顧客情報記憶部112に記録された顧客情報データ、企業財務記憶部243に記録された公表財務データ及び実態財務データ、データ流れC1で示されるような預貸記憶部132に記録された預金残高及び貸金残高、データ流れD1で示されるような延滞記憶部133(図4)に記録された延滞情報、データ流れE1で示されるような金融取引明細記憶部212(図4)に記録された金融取引明細情報、及び、データ流れJ2で示されるような再審査処理621から通知された悪化事象情報(特に、悪化事象区分)などである。
さらに、抽出区分処理261は、上記材料に基づいて自動判定した結果をログオンユーザの端末画面に表示するとともに、そのログオンユーザをして、表示された自動判定の結果を、必要あれば修正した上で、最終判定結果として確定することを可能にならしめる。そして、抽出区分処理261は、上記自動判定の結果と、確定された最終判定結果とを、この処理が実施された日時の情報と共に、抽出区分記憶部262に格納する。抽出区分記憶部262に格納された企業の抽出区分判定結果は、その企業の自己査定に利用される。また、抽出区分判定結果は、企業審査のプロセスの中で後述する債務者区分登録処理281でも利用され、自己査定プロセスの中の抽出区分処理321でも利用され、さらに、データ流れL2に示すように、抽出区分判定結果は図6に示される案件審査のプロセスでも利用され得る。
信用格付処理271は、企業財務記憶部243から顧客の実態財務データを読み込み、データ流れC2で示すように図4に示された預貸記憶部132からその顧客の預貸情報を読み込み、そして、その実態財務データ及び預貸情報を所定の分析・評価ロジックを用いて自動的に評価して、その顧客の実態財務データ及び預貸情報に基づく信用度を点数として算出する(以下、財務データや預貸情報などの定量化データに基づく評価を「定量評価」といい、この定量評価に基づく点数を「定量評価点」という)。また、信用格付処理271は、データ流れF2で示すように、図4に示された定性評価記憶部222から定性評価結果を読み込み、定性評価の各項目に予め割り当てられている点数を定性評価結果に従って自動的に合算して、その顧客の定性評価に基づく信用度を点数(以下、「定性評価点」という)として算出する。そして、信用格付処理271は、上記定量評価点と定性評価点とを所定の演算式を用いて合計することで、顧客の総合的な信用度を表した評価点(以下、「総合評価点」という)を演算し、その上記総合評価点に所定のロジックを適用して、その顧客の信用格付(例えば、AランクからEランクまで12段階がある)を自動的に決定する。
さらに、信用格付処理271は、上述のように自動計算した定量評価点、定性評価点、総合評価点及び信用格付を、ログオンユーザの端末画面に表示するとともに、そのログオンユーザをして、表示された総合評価点を必要に応じて修正することを可能にならしめる。前述したように、信用格付処理271を行なう前に抽出区分処理261が行なわれているため、ログオンユーザは抽出区分判定結果を既に知っている。抽出区分判定結果はその企業の健康状態を示すカルテ又はバロメータのようなものであるから、これに対する知識を基に、ログオンユーザは、上記自動的に計算された評価点を修正することができる。例えば、赤字のような要注意の区分に該当していた場合、上記自動的に計算された評価点がかなり高かったとしても、ログオンユーザは、その高い評価点をより低く修正するかもしれない。ログオンユーザが総合評価点を修正した場合には、信用格付処理271は、修正後の総合評価点を用いて信用格付を計算しなおして、その表示を修正する。信用格付処理271は、ログオンユーザをして、表示されている定量評価点、定性評価点、総合評価点及び信用格付を最終的な格付結果として確定することを可能にならしめる。最終的な格付結果が確定されると、信用格付処理271は、確定された最終的な格付結果(定量評価点、定性評価点、総合評価点及び信用格付)を、その確定時の日時の情報と共に、信用格付記憶部272に格納する。信用格付処理271は、さらに、信用格付記憶部272に格納されている過去の格付け履歴も、端末画面に表示することができる。
信用格付記憶部272に格納された顧客の最終的な格付結果は、融資方針登録処理291で利用され、自己査定プロセスの中の抽出区分処理321でも利用され、さらに、データ流れL2、L3で示すように、図6に示される案件審査のプロセスでも利用され得る。
債務者区分登録処理281は、顧客の債務者区分を決定するための処理である。ここで、債務者区分とは、借金の返済能力の程度に応じた区分であって、例えば、正常先、要注意先、破綻懸念先、実質破綻先、及び破綻先などの区分があり得る。まず、債務者区分登録処理281は、企業財務記憶部243に格納されている顧客の財務データ、データ流れC3で示されるような預貸記憶部132(図4)に格納されている預貸情報(預金と貸金の明細など)、及びデータ流れD1で示されるような延滞記憶部133(図4)に記録された延滞情報などを、ログオンユーザの端末画面に表示することができる。また、債務者区分登録処理281は、その顧客の財務データ、預貸情報、延滞情報、又は、抽出区分記憶部262に記憶されているその顧客の抽出区分判定結果に基いて、その顧客の債務者区分を自動的に又はユーザの手動により選択する。例えば、抽出区分判定結果において赤字のような所定の要注意の区分に該当していたならば、要注意先を選択するというようにである。さらに、債務者区分登録処理281は、ログオンユーザをして、表示されたその顧客の財務状況、預貸情報、延滞情報、資金繰り、収益力、事業状況(現況、将来見通し)などに基づいて、その顧客の自動選択された債務者区分を端末上で変更したり、その理由のコメントを入力したりして、その債務者区分を確定させることを可能ならしめる。債務者区分が確定されると、債務者区分登録処理281は、確定された債務者区分を端末画面に表示し、そして、債務者区分記憶部282に格納する。債務者区分登録処理281は、また、債務者区分記憶部282に格納されている過去の債務者区分の履歴も、端末画面に表示することができる。
債務者区分記憶部282に格納された顧客の債務者区分は、融資方針登録291で利用され、自己査定プロセスの中の抽出区分処理321でも利用され、さらに、データ流れL5に示すように、顧客の債務者区分は、図6に示された案件審査のプロセスでも利用され得る。
融資方針登録部291は、信用格付記憶部272に格納されている顧客の信用格付、及び債務者区分記憶部282に格納されているその顧客の債務者区分などを、ログオンユーザの端末画面に表示する。また、融資方針登録部291は、その顧客の信用格付と保全率(現在の貸出額に対する担保額の割合)に基づいてその顧客に対する貸付の基準金利を自動的に計算して、その基準金利も端末画面に表示する。そして、端融資方針登録部291は、ログオンユーザをして、その顧客の信用格付、債務者区分、事業状況(現況、将来見通し)、保全率、基準金利などに基づいて、その顧客に対する具体的な適用金利を決定して端末に入力することを可能にならしめる。適用金利が入力されると、融資方針登録部291は、その顧客の信用格付、及び基準金利と適用金利との差などに基づいて、所定の判定ロジック(例えば、予めプログラムされている判定テーブル)を用いて、その顧客に対する適用金利での融資方針区分を自動的に判定し、そして、融資方針登録部291は、自動判定された融資方針区分を、適用金利とともに、端末画面に表示する。ここで、融資方針区分には、例えば、積極方針、前向き方針、やや前向き方針、現状維持方針、消極方針、撤退方針などがあり得る。さらに、融資方針登録部291は、ログオンユーザをして、適用金利と融資方針区分を、必要あれば修正した上で、最終的な融資方針として確定することを可能にならしめる。最終的な融資方針が確定すると、融資方針登録部291は、確定された最終的な融資方針を、その確定時の日時の情報とともに、融資方針記憶部292に格納する。
データ流れL6、L7に示すように、融資方針記憶部292に格納された顧客に対する融資方針は、図6に示された案件審査のプロセスで利用される。
上述した企業審査のプロセスで決定された顧客の信用格付、債務者区分及び融資方針などの審査結果のデータは、進捗管理サブシステム712の審査結果記憶部712にも送られて記録される。審査結果記憶部712に記録された審査結果は、次に説明する審査結果の稟議の手続で用いられる。
次に、図5に示されたワークフロー700の処理コンポーネントに関して説明する。
既に述べたように、審査結果記憶部712には企業審査の結果が記録される。ところで、企業審査のプロセスは、顧客を担当する支店で行なわれる一次審査と、審査部のような上位の部署で行なわれる二次審査の2つのサブプロセスから構成される(更に、二次審査の結果に対する監査のサブプロセスが加わることもできる、これについての説明は省略する)。一次審査では、既に説明した財務計算処理244から融資方針登録処理291までのタスクが支店の担当者によって逐次に行なわれて、その審査結果(例えば、信用格付、債務者区分及び融資方針など)が審査結果記憶部712に格納される。
すると、審査決裁処理711が、審査結果記憶部712に格納された一次審査の結果を、二次審査を行なうべき部署に所属するログオンユーザの端末画面に表示して、そのログオンユーザをして、一次審査の結果を承認するか否かを判断して判断結果を端末に入力することを、可能にならしめる。二次審査を行なうログオンユーザによって入力された判断が、一次審査結果の承認であれば、審査決裁処理711は、一次審査が承認された旨を、企業審査サブシステム200の審査管理処理231に通知する。すると、審査管理処理231は、抽出区分処理261、信用格付処理271、債務者区分登録処理281及び融資方針登録処理291などを制御して、一次審査のプロセスで抽出区分記憶部262、信用格付記憶部272、債務者区分記憶部282及び融資方針記憶部292などに格納された抽出区分判定結果、信用格付、債務者区分及び融資方針などを、その企業の正式な最終的な企業審査結果として確定する。確定した企業審査結果は、後に行われる自己査定プロセスの抽出区分処理321で利用される。
他方、二次審査を行なうログオンユーザが、一次審査のプロセスをレビューすることを要求した場合には、審査決裁処理711は、企業審査サブシステム200の審査管理処理231にその旨を通知する。審査管理処理231は、二次審査を行なうログオンユーザの端末画面に、一次審査で行なわれた上記一連のタスクの履歴を表示し、そして、そのログオンユーザをして、一次審査で行なわれた各タスクの結果(信用格付記憶部272、債務者区分記憶部282及び融資方針記憶部292などに格納されている信用格付、債務者区分及び融資方針など)を修正することを、可能にならしめる(二次審査では抽出区分判定結果を修正することはできない)。そして、このようにして修正された抽出区分判定結果、信用格付、債務者区分及び融資方針などが、抽出区分記憶部262、信用格付記憶部272、債務者区分記憶部282及び融資方針記憶部292などにそれぞれ格納されて、これらのデータが、その企業の正式な最終的な企業審査結果として確定する。
以上のようにして最終的な企業審査結果が承認されて確定すると、最終的な企業審査結果が確定したことを示す情報、及びその確定時の日時を示す情報が、審査管理処理231により、企業審査管理記憶部232に格納される。
次に、図5に示された自己査定サブシステム300の処理コンポーネントに関して説明する。
自己査定とは、既に述べたように、金融庁の「金融検査マニュアル」の規程に従い、少なくとも年2回の基準日(例えば、3月末日と9月末日)について、銀行が自己の債権(貸出金)について回収不可能な損失額を予測して、予測された損失額についての手当て(貸倒引当金の計上)を行なうプロセスである。自己査定は少なくとも年2回(銀行の決算月である3月と9月)に行なうことが義務付けられている。自己査定の基準日(例えば、3月末日と9月末日)は、上述した企業審査の日とは異なる。自己査定の手順は、次のようなものである。まず、債務者(融資顧客)を、その財務内容等をもとに、正常先、要注意先、破綻懸念先、実質破綻先、破綻先の5つの債務者区分に分類する。さらに、債務者区分ごとの貸出債権額を、担保や保証、返済能力など、回収の可能性に応じて4段階(非分類、II分類、III分類、IV分類)に分類する。このように分類された債権額を「分類額」という。こうして分類された債権額に基づいて、貸倒引当金を計上するか又は債権の償却を行なう。なお、この実施形態では、融資管理システム20は、自己査定のプロセスでは、債権者ごとの分類額の算出までを行い、債権管理サブシステム600が償却引当の算出を行う。それ以降の処理(例えば、引当金の計上など)はホスト10が行なうことになっている。
自己査定は、上述した企業審査の結果を活用して行なわれるようになっている。ただし、自己査定の基準日(例えば、3月末日と9月末日)は、上述した企業審査が実施された時期とは異なるため、その間に発生した最新の情報も考慮に入れて自己査定を行なうようになっている。以下、図5を参照して具体的に説明する。
自己査定管理処理311は、自己査定の進捗を管理するものである。自己査定管理処理311は、自己査定のプロセスを構成する複数のタスク、すなわち、抽出区分処理321、保全情報登録処理331、債務者区分登録処理341及び分類額算出処理351が、この順序で逐次に実行されるように制御する。自己査定のプロセスは、一次査定と二次査定と監査の3つのサブプロセスから構成される。自己査定管理処理311は、一次査定で上記の複数タスクが上記の順序で逐次に実行され、その後、二次査定で再び上記の複数タスクが上記の順序で逐次に実行され、さらにその後、監査で再び上記の複数タスクが上記の順序で逐次に実行されるように、一次査定、二次査定及び監査の進捗の制御を行なう。
一次査定の開始に当たり、自己査定管理処理311は、全ての顧客について、既に得られている抽出区分判定結果、信用格付及び債務者区分等のデータを読み込む(参照する)。その際、企業審査、自己査定の両方で作成されるデータ(抽出区分、債務者区分等)については、自己査定管理処理311は、前回の自己査定以後に企業審査が行われて承認されている顧客については、上述した抽出区分記憶部262及び債務者区分記憶部282に記録されているに直近の企業審査で決定された抽出区分判定結果及び債務者区分等を読み込み(参照し)、一方、それ以外の顧客については、前回の自己査定の結果を読み込む(参照する)。また、信用格付(企業審査でのみ作成される)については、自己査定管理処理311は、全ての顧客について、上述した信用格付記憶部272に記憶されている直近の企業審査で決定された信用格付のデータを読み込む(参照する)。また、自己査定管理処理311は、今回の自己査定の基準日を把握し、また、企業審査管理記憶部232に記憶されている各顧客の前回の企業審査が行なわれた日時の情報(例えば、企業審査の開始日時又確定(終了)日時、又は企業審査の各タスクの実行日時など)(又は、前回の企業審査の後に前回の自己査定が行なわれている場合には、その前回の自己査定の基準日)を把握する。そして、自己査定管理処理311は、前回の企業審査の日時(又は前回の自己査定の基準日)から今回の自己査定の基準日までの間に発生した、再審査要求の原因となった悪化事象情報を、データ流れJ3に示すように、図4に示された再審査処理621から読み込む。さらに、自己査定管理処理311は、最近の預貸情報、延滞情報及び定性評価結果を、データ流れC4、D4、F3及びJ3に示すように、図4に示された預貸情報記憶部132、延滞情報記憶部133、定性評価記憶部222及び再審査処理621から読み込む。さらに、自己査定管理処理311は、データ流れM1に示すように、図6に示された案件審査における担保記憶部542から、顧客から取得している担保の情報(及び、それに紐付けられた不動産担保評価データや手形明細データなど)を読み込む。
こうして読み込まれた各種データのうち、前回の企業審査による債務者区分は債務者区分記憶部342に格納され、担保情報は保全記憶部332に格納され、それ以外のデータ(前回の企業審査による信用格付け、最近の預貸情報、延滞情報、定性評価結果及び悪化事象など)は自己査定管理記憶部312に格納される。
この後、自己査定管理処理311は、一次査定を行なう権限をもつログオンユーザの端末画面に、そのログオンユーザが担当する債務者(預貸情報記憶部132に記録された基準日における貸金額がゼロではない顧客)全員のリストを自動的に表示することができる。
上記債務者リストの中からログオンユーザが特定の顧客を選択すると、自己査定管理処理311は、その選択された顧客についての一次査定のサブプロセスを開始する。前述したように、一次査定のサブプロセスでは、抽出区分処理321、保全情報登録処理331及び分類額算出処理351が、この順序で逐次に実行される。
抽出区分処理321は、上記選択された顧客について、自己査定の基準日において所定の抽出区分に該当するか否かを判定する処理である。すなわち、抽出区分処理321は、最新の決算よる財務データや自己査定管理記憶部312に格納されている顧客の最新の預貸情報、延滞情報、定性評価結果及び悪化事象情報などをチェックして、それらの情報の中に、この判定に影響するような格別の変化があるかどうかを判断する。抽出区分処理321は、最近過去に行われた抽出区分処理(これは、今回の自己査定の時期に応じて、最後の企業審査プロセスで行われた抽出区分処理である場合と、前回の自己査定プロセスで行われた抽出区分処理である場合とがある)の判定結果を基礎にして、そして、上述した判断の結果格別の変化がある場合には、その格別の変化があった最新の情報を加味して、今回の抽出区分判定結果を得る。例えば、所定の長期にわたる延滞が新たに生じている場合には、それに対応する抽出区分に新たに該当することになる。そして、抽出区分処理321は、前回と今回の抽出区分判定結果を、ログオンユーザの端末画面に表示する。
さらに、抽出区分処理321は、ログオンユーザをして、上記のように自動的に求まった今回の抽出区分判定結果を基に、必要あれば修正を追加入力した上で、基準日における最終的な抽出区分判定結果として確定することを、可能にならしめる。最終的な抽出区分判定結果が確定すると、抽出区分処理321は、今回の自動的に求めた抽出区分判定結果と、最終的な抽出区分判定結果とを、抽出区分記憶部322に格納する。さらに、抽出区分処理321は、最終的な抽出区分判定結果が、その顧客がどの抽出区分にも全く該当しないことを示しているか、1以上の抽出区分に該当することを示しているかの区別を表した抽出区分フラグ情報を、自己査定管理記憶部312に書き込む。
自己査定管理処理311は、ログオンユーザに例えば債務者区分、与信残高又は延滞期間などの項目に関する絞り込み条件を指定させて、その指定された絞込み条件に該当する顧客だけを上記債務者リストの中から検索して、その絞り込まれた債務者のリストを端末画面に表示することもできる。これにより、ログオンユーザは、自己査定の対象を所望の条件に合致する顧客だけに絞り込むことができる。例えば、(1)前回の債務者区分が正常先以外であった顧客、(2)今回の債務者区分が正常先以外であった顧客、又は(3)1以上の抽出区分に該当する顧客、又は(4)前回の自己査定基準日以降に悪化事象が発生したが、未だ再審査が完了してない顧客、などに、査定対象を絞り込むことができる。そして、自己査定管理処理311は、上記絞り込まれた査定対象の中からログオンユーザが任意に選んだ顧客について、保全情報登録処理331を起動することができる。
保全情報登録処理331は、上述した自動的なデータ読み込みによって保全記憶部332及び自己査定管理記憶部312にそれぞれ格納された顧客の担保情報及び預貸情報を、ログオンユーザの端末画面に表示して、顧客の与信残高や保全額などをログオンユーザに確認させる。また、保全情報登録処理331は、ログオンユーザをして、表示された担保情報又は預貸情報を必要に応じて修正したり、又は、上記自動データ読み込みでは得られなかった担保情報があれば、それを追加登録したりした上で、自己査定の基準日における最終的な保全情報を確定させることを、可能にならしめる。最終的な保全情報が確定すると、保全情報登録処理331は、その最終的な保全情報を保全記憶部332に格納する。
債務者区分登録処理341は、自己査定の基準日における顧客の債務者区分を決定する処理である。すなわち、債務者区分登録処理341は、債務者区分記憶部342に格納されている前回の債務者区分をログオンユーザの端末画面に表示し、そして、そのログオンユーザをして、表示された前回の債務者区分を基に、必要あれば修正を追加入力した上で、基準日における最終的な債務者区分として確定することを、可能にならしめる。基準日における債務者区分が確定すると、債務者区分登録処理341は、その基準日における債務者区分を、債務者区分記憶部342に格納し、さらに、自己査定管理記憶部312にも書き込む。
顧客の基準日における債務者区分が自己査定管理記憶部312に書き込まれると、自己査定管理処理311が、その顧客の基準日における債務者と、上述したフラグ情報に基づいて、その顧客について分類額算出処理351を行なうか否かの判断を行なう。すなわち、自己査定管理処理311は、債務者区分が正常先以外(つまり、要注意先、破綻懸念先、実質破綻先、又は破綻先)であって、且つ、1以上の抽出区分に該当した顧客のみを、分類額算出の対象として抽出する。そして、自己査定管理処理311は、その顧客が分類額算出の対象として抽出された場合には、分類額算出処理351を起動する。
分類額算出処理351は、まず、債務者区分記憶部342に格納されているその顧客の基準日における債務者区分に応じて、分類額算出のための計算式を選択する。そして、分類額算出処理351は、保全記憶部332及び自己査定管理記憶部312にそれぞれ格納されているその顧客の基準日における保全情報及び預貸情報に、上記選択された計算式を適用して、その顧客についての分類額を自動的に計算する。そして、分類額算出処理351は、自動計算した分類額と、その算定の基礎になった顧客の基準日における保全情報及び預貸情報を、ログオンユーザの端末画面に表示する。
さらに、分類額算出処理351は、そのログオンユーザをして、自動計算された分類額を、必要あれば修正した上で、基準日における最終的な分類額として確定させることを、可能にならしめる。基準日における分類額が確定すると、分類額算出処理351は、その基準日における分類額を、分類額記憶部352に格納する。
以上で一次審査のサブプロセスが終わる。その後、自己査定管理処理311は、二次審査及び監査のサブプロセスの進捗を、上記と同様のタスクが行なわれるように、制御する。但し、二次審査及び監査の各タスクは、前のサブプロセスの同じタスクで行なった結果を引き継いで、それを単に承認するか又は必要に応じて修正するだけの、単純な処理で行なうことができる。監査が完了すると、その時に抽出区分記憶部322、保全記憶部332、債務者区分記憶部342及び分類額記憶部352に記録されている基準日における抽出区分判断結果、保全情報、債務者区分及び分類額が、自己査定の正式な結果として確定する。
以上のように、自己査定のプロセスは、企業審査の結果を活用して行なわれるため、従来に比較して、より簡単な作業で完遂することができる。そのため、義務付けられた銀行の決算期(3月と9月)だけでなく、より頻繁に、例えば四半期ごとに(3月、6月、9月、12月)に、自己査定を行なうことが可能である。そのようにすると、銀行にとって非常に忙しい3月と9月の決算月には、破綻懸念先、実質破綻先及び破綻先などの状況の悪い債権者だけに絞って自己査定を実施し、他の債権者については、格別の変化が無い限り、直前の6月又は12月に行なった自己査定の結果を流用することができる。これにより、自己査定のサービスがかなり効率化する。
次に、図6を参照して、案件審査のグループ70に分類された処理コンポーネントのオペレーション又は機能と、それに関連するデータ流れについて説明する。
まず、図6に示された案件審査サブシステム400の処理コンポーネントに関して説明する。
案件受付処理411は、任意のログオンユーザをして、融資案件の申込みを顧客から受けた時に、顧客を特定した上で、その案件の概要(例えば、受付日、申込み概要、借り入れ理由など)を端末に入力することを、可能にならしめ、そして、入力された案件概要を案件受付記憶部412に格納する。
案件登録処理421は、融資申込みを行なった顧客を担当する店又は部署に所属するログオンユーザをして、案件受付記憶部412に登録された案件情報に基づいて、その案件の詳細情報を端末に入力することを可能にならしめ、そして、入力された案件の基本情報を案件記憶部422に登録する。ここで登録される基本情報には、受付種類(例えば、融資、融資条件変更、外為、外為条件変更など)、案件種別(融資であれば、例えば、新規貸出、極度額内貸出、継続貸出、継続極度額内貸出など)、科目(例えば、証書貸付、手形貸付、手形割引(商業手形、銀行引受手形、荷為替手形)、代理支払など)、融資希望金額、及び融資実行予定日などがあり得る。さらに、案件登録処理421は、データ流れL2、L3、L5、L6に示すように、その案件を申込んだ顧客の抽出区分判定結果、信用格付、債務者区分及び融資方針を、図5に示した企業審査における抽出区分記憶部262、信用格付記憶部272、債務者区分記憶部282及び融資方針記憶部292から読み込んで、これらの情報を、入力されて案件基本情報と共に、そのログオンユーザの端末画面に表示し、かつ、案件記憶部422に格納する。
このようにして案件の基本情報が登録されると、タスク管理処理431が、案件記憶部422に格納されたその案件の種別と科目に応じて、その案件の案件審査に必要なタスクのセットを、予め用意されている多数のタスク(図示省略)の中から、所定の規則に従って自動的に選定する。予め用意されているタスクには、例えば、貸出条件の登録、手形の信用照会、資金使途明細の登録、返済条件の登録、保証人契約の登録、取入担保の登録、担保価格の算出、融資条件変更先の判定、営業店意見の登録、賞与資金用融資の状況登録、協議・稟議用附属資料データの添付、申込書受理の登録、保証協会等への申込書送付、保証会社による承認日の登録、契約書の受理日の登録、信用情報の確認などがあり得る。これらのタスクの中から、案件の種別と科目に応じて、必要なタスクだけが自動的に選定される。タスクの自動選定の方法としては、例えば、案件の種別及び科目の様々な組み合わせと、様々なタスクとの間の対応関係を定義したタスク選択テーブルが予め用意されていて、そのタスク選択テーブルを参照することにより、与えられた案件の種別と科目に対応したタスクを把握するという方法を採用することができる。
タスク管理処理431は、選定されたタスクを所定の順序で逐次に実行するようにタスクの実行を制御する。それにより、ログオンユーザは、どのような種別と科目の案件であっても、その審査に必要なタスクを全て漏れなく実行することが可能である。
各タスクは、その実行時に、そのタスクのためのGUIがログオンユーザの端末画面に表示する。また、各タスクは、その実行時に、必要に応じて、預貸記憶部132に格納されている融資申込み者の預貸情報(データ流れC5)、延滞記憶部133に格納されている融資申込み者の延滞情報(データ流れD5)、担保記憶部542に記憶されている融資申込み者からの取入担保(不動産、手形など)のデータ、不動産担保記憶部512に格納されている融資申込み者からの取入不動産担保の評価データ(データ流れG4)、火災保険記憶部514に記憶されている融資申込み者からの取入不動産担保の火災保険証書データ(データ流れH4)、手形記憶部516に記憶されている融資申込み者からの取入手形のデータ(データ流れI4)、保証人契約記憶部552に格納されている融資申込み者の保証人の保証人契約データ、企業財務記憶部243に記憶されている融資申込み者の財務データ(データ流れL1)、信用格付記憶部243又は342に記憶されている融資申込み者の信用格付データ(データ流れL4又はN1)、又は、融資方針記憶部292に記憶されている融資申込み者に対する融資方針(データ流れL7)を読み込み、そして、読み込んだデータを端圧画面上のGUIに表示したり、或いは、読み込んだデータに対して所定の処理を行なってその処理結果をGUIに表示したりする。例えば、上記の協議・稟議用附属資料添付タスクは、上述した各種の読み込みデータを用いて、協議又は稟議用の附属資料データを作成して、その附属資料データを、後述する協議書データ又は稟議書データに添付する。各タスクは、上記の読み込みデータ及び処理結果データを、案件記憶部422に格納する。
案件協議処理441は、ログオンユーザをして、案件審査のプロセス中の任意の段階で、必要に応じ、当該案件について他の者と端末画面を通じて協議を行なうことを、可能にせしめる。すなわち、案件協議処理441は、ログオンユーザから端末に、協議相手の指定を含む協議要求が入力されると、協議書データを作成する。この協議書データには、上述した協議用の附属使用データが添付される。協議用の附属資料データは、上述したように、融資申込み者についての預貸情報(データ流れC5)、延滞情報(データ流れD5)、取入担保(不動産、手形など)データ、取入不動産担保の評価データ(データ流れG4)、取入不動産担保の火災保険証書データ(データ流れH4)、取入手形のデータ(データ流れI4)、保証人契約データ、財務データ(データ流れL1)、又は信用格付データ(データ流れL4又はN1)などに基づいて作成される。案件協議処理441は、作成された協議書データ及び添付された協議用の附属資料データ(以下、これらを併せて「協議書類セット」という)を、ワークフローサブシステム700の案件協議記憶部732に格納する。案件協議記憶部732に格納された協議書類データは、ワークフローサブシステム700の案件協議処理731によって、案件協議のために、指定された協議相手の端末に送信される。この案件協議処理731については後述する。
案件稟議処理451は、ログオンユーザをして、案件審査のプロセスが完了した段階で、その案件審査の結果を、端末画面を通じて、案件決裁者の稟議に供することを、可能にせしめる。すなわち、案件稟議処理451は、ログオンユーザから端末に、案件決裁者の指定を含んだ稟議要求が入力されると、案件記憶部422に格納されている案件審査の結果(上記諸タスクの実行結果)を使用して稟議書データを作成する。稟議書データには、前述したように、稟議用の附属資料データが添付される。稟議用の附属資料データは、前述したように、融資申込み者についての預貸情報(データ流れC5)、延滞情報(データ流れD5)、取入担保(不動産、手形など)データ、取入不動産担保の評価データ(データ流れG4)、取入不動産担保の火災保険証書データ(データ流れH4)、取入手形のデータ(データ流れI4)、保証人契約データ、財務データ(データ流れL1)、又は信用格付データ(データ流れL4又はN1)、並びに、案件審査の結果のデータ(上記諸タスクの実行結果のデータ)等を使用して作成される。案件稟議処理451は、稟議書データ及び添付された附属資料データを(以下、これらを併せて「稟議書類セット」という)、ワークフローサブシステム700の案件稟議記憶部742に格納する。案件稟議記憶部742に格納された稟議書類セットは、ワークフローサブシステム700の案件決裁処理741によって、案件稟議のために、指定された案件決裁者の端末に電子的に送信される。この案件決裁処理741については後述する。
案件実行処理461は、案件決裁者から融資実行の決裁が出た場合に、その融資の実行をホスト10に要求する処理である。すなわち、案件実行処理461は、ワークフローサブシステム700の案件決裁処理741から案件の決裁データを読み込み、その決裁データが融資実行を示している場合には、案件記憶部422及び重要物記憶部912に格納されているその案件に関する諸データを読み込み、それら読み込んだデータを用いてその案件についての融資実行要求メッセージデータを作成し、そして、その融資実行要求メッセージデータをホスト10に送信する。そのとき、案件実行処理461は、案件記憶部422及び重要物記憶部912から読み込んだデータを調べて、案件実行に必要なデータに漏れが無いかどうかチェックする。そのチェックの結果、必要な全データが完備されている場合にのみ、案件実行処理461は、融資実行要求メッセージデータを作成する。他方、上記チェックの結果、必要なデータの何かが不足している場合には、案件実行処理461は、案件審査を行なったログオンユーザの端末画面に警告を表示し、そして、そのログオンユーザをして、不足したデータを完備するために必要なタスクを実行することを、可能にならしめる。
以上のことから分かるように、案件審査は、企業審査又は自己査定で決められた顧客の信用格付、債務者区分、融資方針(適用金利及び融資方針区分など)に基づいて行なわれる。さらに、決裁者は、上述した様々な稟議書及び添付された附属資料とを参照して、案件審査の結果が企業審査又は自己査定の結果と整合しているか否か判断することができる。結果として、案件審査が適正化される。
次に、図6に示されたワークフローサブシステム700の処理コンポーネントについて説明する。
前述したように、案件協議記憶部732には、案件審査サブシステム400の案件協議処理441から送り込まれた協議書類セット(協議書データ及び添付された附属資料データ)が格納されている。ワークフローサブシステム700の案件協議処理731は、案件協議記憶部732に格納された協議書類セットに基づいて、指定された協議相手の端末画面に、その人が処理すべき協議事項のリストを表示する。そして、その協議相手が表示された協議事項リスト中から或る協議事項を選択すると、案件協議処理731は、その選択された事項についての協議書類セットの内容を、その協議相手の端末画面に表示し、そして、その協議相手をして、その協議事項について承認するか否かの承認結果を端末に入力することを、可能にならしめる。協議相手から承認結果が入力されると、案件協議処理731は、入力された承認結果を案件協議記憶部731に格納する。案件協議記憶部731に格納された協議相手の承認結果は、案件審査サブシステム400の案件協議処理441によって読み込まれ、案件審査を行なっているログオンユーザの端末画面に表示される、そのログオンユーザは、その承認結果に基づいて案件審査を更に進めるか否か判断できる。
前述したように、案件稟議記憶部742には、案件審査サブシステム400の案件稟議処理451から送り込まれた稟議書類セット(稟議書データ及び添付された附属資料データ)が格納されている。ワークフローサブシステム700の案件決裁処理741は、案件稟議記憶部742に格納された稟議書類セットに基づいて、指定された決裁者の端末画面に、その人が処理すべき稟議案件のリストを表示する。そして、その決裁者が表示された稟議案件リスト中から或る稟議案件を選択すると、案件決裁処理741は、その選択された案件についての稟議書類セットの内容を、その決裁者の端末画面に表示し、そして、その決裁者をして、その稟議案件について融資実行を承認するか否かの決裁結果を端末に入力することを、可能にならしめる。決裁者から決裁結果が入力されると、案件決裁処理741は、入力された決裁結果を案件稟議記憶部741に格納する。案件稟議記憶部741に格納された決裁結果は、案件審査サブシステム400の案件実行処理461によって読み込まれる。その承認結果に基づいて、案件実行処理461は、ホスト10に対して融資実行を要求するか否か判断する。
次に、図6に示された担保管理サブシステム500の処理コンポーネントに関し説明する。
担保登録処理541は、前述した案件審査のプロセス中の取入担保登録タスクに含まれる処理である。すなわち、担保登録処理541は、上述の取入担保登録タスクにおいてログオンユーザから端末に入力された取入担保(例えば、不動産及び手形など)のデータを、担保記憶部542に格納する。
担保記憶部542に格納された取入不動産担保のデータは、担保紐付処理5433によって自動的に、図4に示された不動産担保記憶部512及び火災保険記憶部513内の当該不動産の評価データ及び火災保険証書データと紐付けられ(データ流れG1、H1)、さらに、図4に示された顧客情報記憶部112内の対応する顧客の顧客情報とも内部顧客IDによって紐付けられる(データ流れA1)。また、担保記憶部542に格納された取入手形のデータは、担保紐付処理543によって自動的に、図4に示された手形記憶部516内の当該手形のデータと紐付けられ(データ流れI1)、さらに、図4に示された顧客情報記憶部112内の対応する顧客の顧客情報とも内部顧客IDによって紐付けられる(データ流れA1)。
担保記憶部542内の取入担保のデータ、及びこれに紐付けられた不動産評価データ、火災保険証書データ又は手形データは、データ流れM1に示すように、図5に示された自己査定における保全情報登録処理331でも利用される。
保証人登録処理551は、前述した案件審査のプロセス中の保証人契約登録タスクに含まれる処理である。すなわち、保証人登録処理551は、上述の保証人契約登録タスクにおいてログオンユーザから端末に入力された保証人契約のデータを、保証人記憶部542に格納する。また、保証人登録処理551は、保証人記憶部542内の保証人契約データを、データ流れA3に示すように、図4に示された顧客情報記憶部112内の対応する顧客の顧客情報と内部顧客IDによって紐付ける。
上述した担保記憶部542内の担保データには、その担保の有効期限のような期日に関するデータが含まれている。また、上述した保証人契約記憶部552内の保証人契約データには、その契約の有効期限のような期日に関するデータが含まれている。これらの期日データは、データ流れQ1、Q2に示すように、図7に示された事件期日記憶部822に送られて格納される。
次に、図6に示された重要物管理サブシステム500の処理コンポーネントに関し説明する。
重要物登録処理911は、ログオンユーザをして、融資申込者から受け取って保管している重要物(例えば、印鑑証明書や戸籍謄本や手形などの重要書類)に関する情報(例えば、重要物の種類、保管場所、有効期限、明細など)を端末から入力することを、可能にならしめ、そして、入力された重要物情報を融資案件及び顧客に紐付けて重要物記憶部912に格納する。
重要物記憶部912に格納された重要物情報は、前述した案件審査サブシステム400の案件実行処理461によって、融資を実行するのに必要な書類が全部揃っているかどうかのチェックなどに利用される。また、データ流れK1に示すように、重要物情報に含まれるその重要物の有効期限のような期日に関する情報は、図7に示された事件期日記憶部822に送られて格納される。
次に、図7を参照して、債権管理のグループ80分類された処理コンポーネントのオペレーション又は機能と、それに関連するデータ流れについて説明する。
まず、図7に示された債権管理サブシステム600の処理コンポーネントに関して説明する。
延滞先管理処理631は、図4に示された延滞記憶部133内の最新の延滞情報を自動的に読み込み(データ流れD1)、読み込んだ延滞情報に基づいて、延滞先のリストをログオンユーザの端末画面に表示する。表示された延滞先リストには、延滞先ごとに顧客情報の概要(例えば、顧客名、債務者区分、担当店名など)及び延滞情報の概要(例えば、延滞金額、延滞日数、融資種類など)が示される。ログオンユーザが延滞先リスト中から或る延滞先を選択すると、延滞先管理処理631は、選択された延滞先について延滞情報の詳細(例えば、貸出残高、延滞元金、利息、当初貸出額、貸出日、返済パターン、返済約定日、担保など)をログオンユーザの端末画面に表示する。ログオンユーザは、これらの表示された情報に基づいて(例えば、延滞日数が短期か、中期か、長期か等に応じて)、延滞先に対する対処の方法(例えば、返済督促をする、整理貸付先に登録するなど)を判断することができる。
また、延滞先管理処理631は、延滞先リスト中から選択された延滞先について、今までの交渉履歴を図4に示された交渉履歴記憶部122から読み出して(データ流れB2)、読み出された交渉履歴をログオンユーザの端末画面に表示することもできる。さらに、延滞先管理処理631は、そのログオンユーザをして、選択された延滞先に対して実施した交渉の履歴((例えば、返済督促交渉の経過、返済督促日、返済約束、返済予定日、次回の督促訪問予定日など)を端末に入力することを可能にならしめ、そして、入力された交渉履歴を図4に示された交渉履歴記憶部122に格納する(データ流れB1)。さらに、延滞先管理処理631は、延滞情報に含まれる延滞開始日や、交渉履歴に含まれる返済督促日や返済予定日や次回の督促訪問予定日のような期日に関するデータを、進捗管理サブシステム800の事件期日記憶部822に格納する。
訴訟登録処理641は、ログオンユーザをして、内部顧客IDで顧客を特定した上で(データ流れA4)、その顧客に対して銀行が提起した又はその顧客から銀行が訴えられた訴訟に関する諸情報(例えば、訴訟番号、当事者、訴訟経過、各種手続の実行日及び実行期限、仮払金、など)を端末に入力することを可能にならしめ、そして、入力された訴訟情報を訴訟記憶部642に格納する。また、訴訟登録処理641は、入力された訴訟情報のうち、各種手続の実行日及び次の手続の期限のような期日に関するデータを、進捗管理サブシステム800の事件期日記憶部822に格納する。また、訴訟登録処理641は、訴訟記憶部642に格納されている訴訟情報を、ログオンユーザにより指定された検索条件で検索して、検索された情報をログオンユーザの端末画面に表示することもできる。
仮払金データ連携処理651は、ホスト10から、債権者毎の仮払金(その債権者に係る訴訟の費用であって、その債権者に代わって銀行が立て替えて支払った費用)のデータを自動的に受信して、これを債務者別に分類して仮払金記憶部652に格納する。顧客マスタ紐付処理653は、仮払金記憶部652に格納された顧客毎の仮払金データを、図4に示された顧客情報記憶部112内の対応する内部顧客IDに紐付ける(データ流れA5)。
取立益データ連携処理661は、ホスト10から、債権毎の償却債権取立益(その債権を既に償却扱いにした後に債権者から入金された返済金)のデータを自動的に受信して、それを債務者別に分類して取立益記憶部662に格納する。顧客マスタ紐付処理663は、取立益記憶部662に格納された顧客毎の取立益データを、対応する顧客の償却債権別に、図4に示された顧客情報記憶部112内の対応する内部顧客IDに紐付ける(データ流れA6)。
整理貸付先登録処理671は、整理貸付先を登録する権限をもったログオンユーザをして、特定の顧客に対する整理貸付先の指定又はその指定の解除を端末に入力することを可能にならしめ、そして、入力されたその顧客に対する整理貸付先の指定又はその指定の解除を示すデータを、図4に示された顧客情報記憶部112に登録する(データ流れA7)。また、その顧客に対して整理貸付先の指定又はその指定の解除がなされたとき、整理貸付先登録処理671は、その顧客を担当する店又は部署の端末に、その指定又はその指定解除の通知を自動的に送信する。さらに、整理貸付先登録処理671は、整理貸付先として指定されている顧客の情報を、図4に示された顧客情報記憶部112から検索して、ログオンユーザの端末画面を表示することができる。
償却引当先処理681は、図5に示された自己査定サブシステム300の債務者区分記憶部342及び分類額記憶部352に格納されている債務者区分情報及び分類額情報に基づいて、償却引当の対象となる債権(以下、「償却引当対象先」を自動的に抽出して、抽出された償却引当対象先の情報を、償却引当を行なう権限をもつログオンユーザの端末画面に表示する。そして、償却引当先処理681は、そのログオンユーザをして、自動抽出された償却引当対象先を正式に償却引当先とするか否か判断して判断結果を確定することを可能にならしめ、そして、或る債権が償却引当先として確定した場合、その旨のデータを図4に示される顧客情報記憶部112に登録する。さらに、償却引当先処理681は、その償却引当先に対する貸倒引当金及び直接償却額を所定のロジックで算出して、顧客情報記憶部112に登録することもできる。
次に、図7に示された進捗管理サブシステム800の処理コンポーネントに関して説明する。
前述したように、事件期日記憶部822には、図4に示された不動産担保記憶部512、火災保険記憶部514及び手形記憶部516からそれぞれ提供された(データ流れG2、H2、I2)不動産担保評価データの有効期限、火災保険契約の有効期限及び手形データの有効期限などの期日データが格納されている。また、事件期日記憶部822には、図6に示された担保記憶部542、保証人契約記憶部及び重要物記憶部912からそれぞれ提供された(データ流れQ1、Q2、K1)担保の有効期限、保証人契約の有効期限及び重要物の有効期限などの期日データも格納されている。さらに、事件期日記憶部822には、延滞先管理処理631により書き込まれた延滞開始日や返済予定日や次回督促訪問予定日や支払督促日などの期日データも格納されている。またさらに、事件期日記憶部822には、訴訟登録処理641により書き込まれた訴訟における諸手続の実行日や次の手続の期限のような期日データも格納されている。
事件期日処理821は、事件期日記憶部822に格納されている各種の期日データに基づいて、支払督促や訴訟手続等の各種手続の実行スケジュール、及び債権の消滅時効や時効の中断などの時効を管理する。すなわち、事件期日処理821は、例えば、本日から所定期間以内に来る各種手続の期限を事件期日記憶部822を検索して、検索された手続期限をそれぞれの手続を扱うべきログオンユーザの端末画面に表示することができる。また、事件期日処理821は、例えば、延滞債権の消滅時効の到来日を自動計算して、それぞれの延滞債権を扱うべきログオンユーザの端末画面に表示することができる。これにより、債権管理に関わる様々な手続を、時期を失することなく好機に実行することができるようになる。
以上、図4〜図7を参照して、情報収集、企業審査・自己査定、案件審査及び債権管理4種類のサービスごとに、それぞれのサービスのための処理コンポーネントの機能と処理コンポーネント間のデータ流れを詳細に説明した。
図8は、図4〜図7を参照して詳細に説明した内容を要約し整理して、この融資管理システム20のもつ処理機能の全体像を分かりやすく示したものである。以下、図8を参照して、この融資管理システム20のオペレーションの主要なものを説明する。
図8において、情報収集のサービス(グループ50)では、以下のようなオペレーションが行なわれる。
顧客情報入力処理115により、顧客の基本情報や企業概要情報などが手動で又は自動的に入力されて、顧客情報記憶部116に格納される。また、実質的に常時に、預貸情報入力処理134により、顧客の預貸及び延滞の現況を実質的に実時間で表した最新の預貸情報及び延滞情報が、ホスト10から自動的に入力されて預貸情報記憶部135に格納される。また、顧客の業務に悪化事象が発生したときには、その都度、悪化事象登録処理613により、悪化事象情報が入力されて悪化事象記憶部614に格納される。さらに、顧客に対する交渉が行なわれたときには、その都度、交渉管理処理123により、その交渉の履歴情報が交渉履歴記憶部124に格納される。
顧客情報記憶部116に格納された顧客情報のうち、顧客の決算期日(決算月)の情報は、決算期日記憶部813に格納される。そして、決算月処理814により、決算期日記憶部813内の決算期日の情報に基づいて、顧客の決算月が来たか否かが自動的にチェックされる。顧客の決算月が来たことが決算月処理814により検出されると、その旨が審査進捗管理処理232に通知される。審査進捗管理処理232は、その通知に基いて、その決算月の到来した顧客を表示して、その顧客の財務データを取得して入力するようにログオンユーザを促す。そして、ログオンユーザにより顧客の財務データが入力されると、そのことが審査進捗管理処理232に通知され、審査進捗管理処理232は、その通知を、その顧客の企業審査を開始するトリガとして使用する。
また、悪化事象記憶部614に格納された顧客の悪化事象情報が、再審査処理622により、然るべき判断者にタイムリーに通知されて、その顧客について再度の企業審査を行なうか否かの判断の機会がその判断者にタイムリーに提供される。そして、再審査を行なうという判断結果が入力されると、再審査処理622により、その判断結果が審査進捗管理処理232に通知され、審査進捗管理処理232は、その通知を、その顧客についての再審査を開始するトリガとして使用する。
このようにして、顧客についての財務データの入力(換言すれば、決算月の到来)と悪化事象の発生は、その顧客の企業審査を実行するタイミングの制御に利用され、その結果、タイムリーに企業審査を実行することができる。
また、顧客情報記憶部116内の顧客情報のうち、業界、立地条件、資本金、役員、株主、取引先などのような顧客の事業能力に関連する諸情報、及び、預貸情報記憶部135内の最新の預貸及び延滞の情報は、定性評価処理223により、その顧客の信用度に関する定性評価を行なう際に、評価材料として使用される。そして、その定性評価の結果は、定性評価記憶部224に格納される。定性評価記憶部224に格納された定性評価結果は、企業審査における顧客の格付けに利用され、また、企業審査及び自己査定におけるその顧客を自己査定の対象として抽出するか否かの判断(抽出区分判定)にも利用されることになる。
また、預貸情報記憶部135内の顧客の最新の預貸及び延滞の情報は、企業審査における信用格付けや債務者区分の判断、自己査定における債務者区分の判断や分類額の算定などに利用されることになる。
また、悪化事象記憶部614内の顧客の悪化事象情報は、企業審査及び自己査定におけるその顧客を自己査定の対象として抽出するか否かの判断(抽出区分判定)に利用される。
また、顧客情報記憶部116内の顧客情報、預貸情報記憶部135内の顧客の最新の預貸及び延滞の情報、及び、悪化事象記憶部614内の顧客の悪化事象情報は、その顧客が申し込んだ融資の案件審査において、融資実行を許可するか否かの判断に利用されることになる。
さらに、交渉履歴記憶部124内の顧客に対する交渉履歴は、その顧客の債権管理に利用されることになる。
企業審査・自己査定のサービス(グループ60)では、以下のようなオペレーションが行なわれる。
案件審査進捗管理処理232により、決算月処理814又は再審査処理622からの通知をトリガとして、顧客の決算月が来たか、又は顧客に格別の悪化事象が生じた場合に、その顧客の企業審査がタイムリーに開始される。案件審査進捗管理処理232による制御によって、企業審査のプロセスは、財務データ処理144、定量評価処理252、総合評価処理273及び審査稟議処理713の順序で実行される。
財務データ処理144により、その顧客の財務データ(決算書データ)が自動的に又は手動で入力され、企業財務記憶部145に格納される。企業審査を開始しようとするときに、その顧客の当期の財務データが未だ入力されていない場合には、案件審査進捗管理処理232からユーザに対して、財務データ処理144を行なうよう警告がなされる。また、企業審査を開始しようとするときに、その顧客の当期の定性評価結果が未だ入力されていない場合には、案件審査進捗管理処理232からユーザに対して、定性評価処理223を行なうよう警告がなされる。
定量評価処理252により、企業財務記憶部145内の顧客の財務データに基づいて、その顧客の信用度に関する定量評価が行なわれ、定量評価の結果が定量評価記憶部252に格納される。
総合評価処理273により、定性評価記憶部224内の顧客の定性評価結果と、定量評価記憶部253内の定量評価結果とが総合的に処理されて、その顧客の信用格付が決定される。さらに、決定された顧客の信用格付けと、預貸情報記憶部135内の預貸及び延滞の情報に基づいて、その顧客の債務者区分が決定される。さらに、その顧客の信用格付と債務者区分と預貸及び延滞の情報などに基づいて、その顧客に対する融資方針が決定される。さらに、定性評価結果、悪化事象、財務データ、預貸情報、延滞情報、顧客情報などに基づいて、その顧客を自己査定の対処とするか否かの判断材料となる抽出区分判定も行なわれる。こうして得られた顧客の信用格付、債務者区分、融資方針及び抽出区分判定結果などの企業審査結果は、企業審査結果記憶部713に格納される。
企業審査結果記憶部713に格納された企業審査結果は、審査稟議処理713により、上位者への稟議に提供され、上位者によって承認されることによって確定する。
査定進捗管理処理313による制御により、定期的に、例えば毎年3月と9月、或いは四半期ごとに、自己査定が実施される。査定進捗管理処理313による制御により、自己査定のプロセス314は、一次査定315、二次査定316及び監査317の順序で行なわれる。一次査定315のプロセスは、企業審査結果記憶部274内の顧客の企業審査結果(特に、抽出区分判定結果、信用格付、債務者区分)を読み込み、この企業審査結果を基礎にして、さらに顧客の最新の情報を加味して行なわれる。すなわち、企業審査の実施日から自己査定の基準日までの間に発生したその顧客の最新の預貸及び延滞の情報、悪化事象、並びに取入担保に基づく保全情報などの最新情報に基づいて、自己査定の基準日における抽出区分判定結果が求められる。また、上記の最新情報に基づいて、企業審査結果の債務者区分が補正されて、自己査定の基準日における債務者区分が求められる。そして、自己査定の基準日における抽出区分判定結果と債務者区分とに基づいて、その顧客を自己査定の対象として抽出するかが決定される。その顧客が自己査定の対象として抽出された場合には、さらに、その顧客の債権の最新の預貸情報(特に、自己査定の基準日における債権額及び保全情報など)に基づいて、その顧客の債権の分類額が算定される。こうして求まった顧客の抽出区分判定結果、債務者区分及び分類額などの自己査定結果は、自己査定結果記憶部318に格納される。二次査定316及び監査317では、ぞれぞれ、一次査定及び二次査定の履歴と結果が参照され、前の自己査定結果が承認され、或いは、一次査定と同様の処理が繰り返されて前の自己査定結果が修正され、修正された自己査定結果が自己査定結果記憶部318に格納される。監査で承認されたに自己査定結果が、最終的な自己査定結果として確定する。
企業審査結果記憶部274内の顧客の企業審査結果、及び、自己査定結果記憶部318内の顧客の自己査定結果は、その顧客が申し込んだ融資案件の案件審査で、融資の実行を許可するか否かの判断に利用されることになる。
また、自己査定結果記憶部318内の顧客の自己査定結果(例えば、債務者区分や分類額)は、その顧客の債権の債権管理(例えば、償却債権を決める処理など)で利用されることになる。
案件審査のサービス(グループ70)では、以下のようなオペレーションが行なわれる。
案件受付・登録処理423により、顧客から申込まれた融資案件の基本情報が入力され、案件記憶部424に登録される。
案件審査・稟議処理432により、案件記憶部424に登録された案件の基本情報が読み込まれ、その基本情報を使用して案件審査のプロセスが開始される。案件審査のプロセスは、所定の多数のタスクから構成される。案件審査・稟議処理432による制御により、それらのタスクが所定の順序で逐次に実行される。案件審査の各タスクでは、そのタスクに必要な情報が、顧客情報記憶部116、預貸情報記憶部135、企業財務記憶部245、定量評価記憶部253、企業審査結果記憶274又は自己査定結果記憶部318から読み込まれ、読み込まれた情報に基づいてそのタスクが実行され、そのタスクの処理結果は案件記憶部424に格納される。そして、顧客情報記憶部116、預貸情報記憶部135、企業財務記憶部245、定量評価記憶部253、企業審査結果記憶274及び自己査定結果記憶部318から読み込まれた情報に基づいて、案件稟議のための附属資料データが作成される。それらのタスクが全て終わると、案件審査・稟議処理432により、案件審査の結果を記述した稟議書データと上記附属資料データが、案件稟議記憶部743に格納され、案件稟議記憶部743に格納された稟議書データと上記附属資料データは、所定の決裁者により参照可能となって決裁の判断に使用される。
決裁者により融資実行を承認する旨の決裁結果が入力されると、案件審査・稟議処理432は案件実行処理462に決裁結果を伝える。案件実行処理462により、案件記憶部424及び重要物記憶部914内のその案件のデータが調べられる。案件実行処理462は、その案件について融資実行に必要な全てのデータが案件記憶部424及び重要物記憶部914内に揃っていることを確認した後、ホスト10に、その案件についての融資の実行依頼を送る。
担保管理処理543により、案件審査のプロセスで入力された取入担保及び保証人契約の情報が、担保・保証人記憶部544に格納される。担保・保証人記憶部544に格納された取入担保及び保証人契約の情報は、前述した自己査定において、その顧客の債務者区分の判断のためにその顧客に対する債権額の保全状態を把握するために使用されることになる。また、上記取入担保及び保証人契約の情報のうち、特に、担保価値評価額の有効期限や保証人契約の有効期限や手形の期限などの期日に関する情報は、債権管理における期日管理に利用されることになる。
重要物管理処理913により、案件審査に関連して顧客から預かった重要物(例えば、印鑑証明や戸籍謄本や手形など重要書類)に関する情報が入力され、重要物記憶部914に格納される。重要物管理処理913により、重要物記憶部914に格納された重要物の情報はいつでも参照することができる。重要物記憶部914内の重要物の情報のうち、特に重要物の有効期限などの期日に関する情報は、債権管理における期日管理に利用されることになる。
債権管理のサービス(グループ80)では、以下のようなオペレーションが行なわれる。
債権管理処理632により、預貸情報記憶部135内の延滞情報に基づいて、延滞先が抽出され、その延滞先の情報(例えば、顧客情報記憶部116内の顧客情報、及び自己査定結果記憶部318内の債務者区分など)が表示され、その延滞先の情報が債権記憶部633に格納される。ユーザは、その延滞先の情報に基づいて、その延滞先に対する対応策を検討することができる。また、債権管理処理632により、交渉履歴記憶部124内の延滞先に対する過去の交渉の履歴が読み込まれ表示され、また、その延滞先に対して新たに行なった交渉の経緯の情報が入力され、交渉履歴記憶部124に格納される。さらに、債権管理処理632により、選択された顧客について整理貸付先としての指定が入力され、或いは、選択された債権について償却引当先としての指定が入力され、入力された整理貸付先の指定や償却引当先の指定は、顧客情報記憶部116に格納される。顧客情報記憶部116に格納された整理貸付先指定及び償却引当先指定は、ホスト10に通知され、勘定処理に利用されることになる。また、顧客情報記憶部116内の顧客の整理貸付先指定及びその顧客に対する債権の償却引当先指定は、その顧客の企業審査、自己査定及び案件審査でも利用されることになる。
訴訟管理処理642により、顧客と銀行間で生じた訴訟の情報が入力され、訴訟記憶部642に格納される。入力された訴訟情報のうち、特に手続期日のような期日に関する情報は、事件期日記憶部824にも格納される。
期日管理処理823により、事件期日記憶部824に格納された各種の期日情報に基づいて、各種の手続の期日管理及び各種の時効の管理が行なわれる。
以上のように、この融資管理システム20がもつ様々な処理機能とそれら処理機能間のデータ連携により、融資業務を構成する情報収集、企業審査・自己査定、案件審査及び債権管理の4種類のサービスが有機的な連携をもって実施されることになる。従って、融資業務を適正に且つ効率的に行なうことが容易である。
以下では、上述した融資管理システム20で行われる企業審査と自己査定のプロセスの制御方法に関し具体的な説明を補足する。
図9は、融資管理システム20がもつ企業審査のプロセスを制御するためのコンピュータプログラムの機能的構成を示すブロック図である。
図9に示すように、顧客管理サブシステム100と企業審査サブシステム200は、別個のコンピュータプログラムとして構成されている。そして、定性評価登録処理221のタスクは、(前述した図4では、説明の便宜上、企業審査サブシステム200の一部として説明されたが、)プログラムの構成上は、顧客管理サブシステム(すなわち顧客管理プログラム)100に組み込まれており、よって、企業審査サブシステム(すなわち企業審査プログラム)200内でこれを実行することはできない。定性評価登録処理221が企業審査プログラム200内で行えないようにした理由は、企業審査を行うログオンユーザが、自己の恣意で定性評価の結果を出すことを防止して、客観的な定性評価結果が企業審査で用いられるようにするためである。
顧客管理プログラム100は、前述したように、顧客情報登録111(図4)を始めとする顧客に関する各種情報を管理するための各種タスクを行うことができるとともに、顧客情報登録111で登録された個々の顧客の顧客情報に基づいて、個々の顧客の定性評価登録処理221を行うことができる。ここで、定性評価登録110で用いられる顧客情報には、企業概要(例えば、業種、立地条件、資本金、株価、株主、役員、仕入先・販売先など)や信用情報(例えば、倒産情報、外部機関による信用格付けデータ、事故履歴など)などがある。定性評価登録処理221では、例えば、業種、立地条件、業界内競争力、商品、サービス、技術力、管理能力、設備状況、役員、仕入先、販売先などの各種の評価項目について、予め点数化されて用意された複数のレベルの中から、各顧客に最適なレベルがログオンユーザにより選択され、それら選択されたレベルの点数に基づいて、例えばそれら点数を合計するなどの方法で、各顧客の定性評価値が決定される。
定性評価登録処理221のタスクは、顧客毎の定性評価データ1000を定性評価記憶部222に登録する。定性評価データ1000は、例えば、顧客識別情報1002と、上述した定性評価値1004と、更新日情報1006とを含んで構成される。顧客識別情報1002とは、各顧客を他の顧客と区別し特定するための情報であり、例えば、顧客名称、顧客管理コード等が該当する。更新日情報1006は、定性評価値の作成された日時(年月日及び時刻)を示す。
定性評価記憶部222に登録された定性評価データ1000は、企業審査プログラム200内の信用格付処理271で利用される。しかし、企業審査プログラム200内の実態データ登録処理251では、定性評価データ1000を参照することができない。その逆も同様に、定性評価登録処理221では、企業審査プログラム200内の財務データ連携・手入力処理241、242及び実態データ登録処理251により登録された公表財務データや実態財務データを参照することができない。即ち、定性評価と定量評価とは、それぞれ別々のプログラム内に設けられ、切り離されている。これにより、定性評価及び定量評価をそれぞれ独立して行うことができ、両者が互いに与えうる影響を未然に排除し、客観性を担保している。
企業審査プログラム200は、既に説明したように、審査管理処理300による進捗制御の下で、個々の顧客について、財務データ連携・手入力処理241又は242、実態データ登録処理251、抽出区分処理261、信用格付処理271、債務者区分処理281及び融資方針登録処理291という一連のタスクをこの順序で行う。
審査管理処理300は、進捗管理テーブル1010を用いて、上述した一連のタスク241〜291が上述の順序で実行されるように管理する。進捗管理テーブル1010には、タスク241〜291の各々の処理順序を示す順序情報1012と、各タスクの識別情報1014と、各タスクが実行されたか否かを示すステータス情報1016が記録されている。
審査管理処理231は、タスク241〜291のステータスを把握し、それを進捗管理テーブル1010のステータス情報1016に記録する。そして、審査管理処理231は、タスク241〜291のステータス情報1016を検査し、処理順序情報1012に基づいて、より前順位のタスクのステータスが処理済みであることを条件として、より後順位のタスクの起動を許可する。よって、処理順序情報1012に規定されたよ順序に従ってタスク241〜291が実行される。この順序制御により、全てのタスクが漏れなく且つ適正な順序で行われるから、ログオンユーザのミスにより誤った企業審査結果が出る可能性が減る。
なお、このように一連のタスクの順序情報とステータス情報とを用いて、それら一連のタスクが規定の順序で実行されるようにする順序制御は、自己審査プロセス及び案件審査プロセスでも採用される。
ある顧客の企業審査プロセスにおいて、抽出区分処理261が終了した段階で信用格付処理271が起動可能となる。この段階において、ログオンユーザが信用格付処理271を起動しようとした場合、審査管理処理231は、定性評価記憶部222内の当該顧客の定性評価データ1000の更新日情報1006をチェックして、その定性評価データ1000の作成日(更新日)が最近過去所定期間(例えば、信用格付処理を行う日から起算して最近過去1ヶ月)以内に作成(更新)であるか否かを判定する。その結果、その定性評価データ1000の作成日(更新日)が最近過去所定期間以内であるならば、審査管理処理231は、信用格付処理271を起動する。しかし、その定性評価データ1000が最近過去所定期間より古いものである(つまり、その期間内の定性評価が行われてない)場合には、審査管理処理231は、信用格付処理271を起動せずに、ログオンユーザに対して警告1018を発する。警告1018は、例えば、「定性評価を行って下さい。」等の警告メッセージを端末の画面に表示することにより行われる。このようにして、定性評価が企業審査プログラムとは別の顧客管理プログラム100で行われるようになっていても、企業審査が行われる時期には必ず定性評価も行われるように制御される。。
図10は、自己査定プロセスの制御の流れを示すフローチャートである。
既に説明したように、自己査定プロセスは、年間に複数回定期的に行われる。自己査定プロセスでは、自己査定の処理量を軽減すると共に自己査定の精度を向上させるために、企業審査の審査結果を自己査定で活用するように制御が行われる。この制御の流れの一例を、図10を参照して説明する。
図10に示すように、ステップ1020で、預貸情報記憶部132に基づいて、ログオンユーザが担当する顧客の中で、自己査定の基準日において貸金がゼロでない顧客(すなわち債務者)が抽出されて、その債務者リストがログオンユーザの端末の画面に表示される。ステップ1022では、その債務者リストからログオンユーザにより各顧客が選択されることにより、選択された各顧客について、ステップ1024の抽出区分処理が開始される。
抽出区分処理では、ステップ1026で、抽出区分の自動判定が行われる。この自動判定は、前回の抽出区分処理の判定結果のデータを基礎にして行われる。ここで、前回の抽出区分処理とは、最近過去に行われた企業審査プロセスおよび自己査定プロセスのうちの遅い方のプロセスで行われた抽出区分処理を意味する。前回の抽出区分処理が企業審査プロセスで行われた場合には、前回の抽出区分判定結果データは図5に示した抽出区分記憶部262から得られ、一方、前回の抽出区分処理が自己査定プロセスで行われた場合には、前回の抽出区分判定結果データは図5に示した抽出区分記憶部322から得られる。
ステップ1026の自動判定では、抽出区分記憶部262又は322から得られた前回の抽出区分判定結果データの中から、所定の複数の抽出区分に関する結果データが抽出され、これがそのまま流用されて今回の当該抽出区分の判定結果とされる。この点について具体例を挙げて説明すると、図11には、多数ある抽出区分のうちの一部が例示されているが、ここに例示された抽出区分のうち、「利息貸出」(利息貸出があること)、「条件変更先」(返済負担軽減を目的として貸出条件を変更したこと)、「複数店取引先」(複数店で取引していること)、「関連会社」(その銀行のの関連会社であること)、「土地関連融資先」(国土利用計画法に基づく監視区域の届出対象土地取引に係る融資であること)、「長期貸出先」(極端に長期の返済契約がなされていること)などの抽出区分については、前回の抽出区分判定結果データがそのまま今回の当該抽出区分の自動判定結果として流用される。これらの抽出区分は、短期では変動しない性質がある(固定的な性質をもつ)属性であるからである。このように、固定的な傾向をもつ所定の抽出区分について、前回の判定結果を流用することで、処理負担が軽減される。なお、企業審査プロセスでの抽出区分処理では、上記の固定的な性質をもつ抽出区分についても、前回の結果は流用されずに、その審査時点での関連情報に基づいて改めて判定がなされる。
ステップ1026の自動判定では、残りの抽出区分については、前回の抽出区分の判定結果だけでなく、前回の債務者区分データ(すなわち、最近過去に行われた企業審査プロセス又は自己査定プロセスの抽出うちの遅い方で行われた債務者処理で決定された債務者区分)、前回の信用格付けデータ(すなわち、最近過去に行われた企業審査プロセスで行われた信用格付処理で決定された信用格付)、財務(公表、実態)データ(つまり、最近過去に行われた企業審査プロセスで登録された公表財務及び実態財務データ)、預貸データ、延滞データ、悪化事象データなどに基づき判定が行われる。
例えば、図11に例示された抽出区分のうち、「赤」(自己査定基準日直前期の決算において、経常損益または当期損益で赤字となっていること、または、繰越欠損のある先及び債務超過となっていること)や「無配」(上場または店頭取引のある顧客であって、無配となっていること)の判定では、企業財務記憶部243に記録された公表財務データ及び実態財務データが用いられる。この公表財務データ及び実態財務データも、企業審査プロセスで登録済みであるため、自己査定プロセスでこれら財務データを登録したり修正する必要は無く、その分、自己査定の負担が軽減される。
また、図11に例示された抽出区分のうち、「要管理先」(所定の問題事項を有していること)については、信用格付記憶部272に記録されている前回の(最近過去の企業審査で決定された)信用格付データ、債務者区分記憶部272又は342に記録されている前回の債務者区データ、悪化事象記憶部612に記録されている最近過去の企業審査日又は自己査定基準日から今回の自己査定基準日までに発生した悪化事象のデータ、延滞情報記憶部133に記録されている延滞情報データなどに基づいて、判定が行われる。例えば、前回の信用格付がDランク以下であったり、前回の債務者区分が破綻先であったり、返済延滞が3ヶ月以上であったり、或いは自己査定基準日が悪化事象が発生してから3ヶ月以内である場合、「要管理先」に該当するというように判断される。ここで、判断材料である前回の信用格付データや前回の債務者区分区データなどは、企業審査で決定されているので、その分、自己査定の負担が軽減する。また、悪化事象については、最新の情報が加味されるので、判定の精度が高い。
以上の自動判定が行われた後、ステップ1028で、今回の自動判定の結果が、前回の判定結果と一緒に、対比可能な形で、ログオンユーザの端末に表示される。図11は、その画面例を示している。ログオンユーザは、前回と今回の抽出区分判定結果を対比して見ることで、特に、前回から今回で変化した抽出区分が何であるかを容易に把握でき、それにより、自動判定結果の妥当性を判断し易くなる。
ステップ1030では、図11に例示した画面上で、ログオンユーザが、必要に応じて、今回の自動判定結果を修正し、それにより、抽出区分の最終判定結果を決定する。この最終判定結果は抽出区分記憶部322に日付と共に記録される。
その後、ステップ1032で、今回の最終判定結果に基づいて、その顧客が少なくとも一つの抽出区分に該当するか否かが判断される。その結果、いずれの抽出区分にも該当しない場合には、制御はステップ1042に進み、その顧客についての自己査定の処理は終了する。一方、その顧客が何らかの抽出区分に該当した場合には、その顧客について、ステップ1034の保全登録処理が行われ、そして、ステップ1036にて、保全登録処理の結果に基づいて、その顧客の債務者区分が改めて決定されて、その債務者区分が債務者区分記憶部342に登録される。
その後、ステップ1038で、改めて決定されたその顧客の債務者区分が要注意先以下であるか(つまり、正常先以外であるか否か)が判断される。その結果、正常先であれば、制御はステップ1042に進み、その顧客についての自己査定の処理は終了する。一方、その顧客が要注意先以下である場合には、制御はステップ1040へ進み、その顧客について分類額1040の算出が行われ、計算された分類額が分類額記憶部352に登録される。
以上のように、自己査定のプロセスは、その前に行われた企業審査プロセスの抽出符号処理や信用格付処理や債務者区分処理の結果を利用することにより、小さい処理量で十分な精度の結果が得られるように効率的に行われる。
以上、本発明の実施形態を説明したが、これは本発明の説明のための例示であり、この実施形態のみに本発明の範囲を限定する趣旨ではない。従って、本発明は、その要旨を逸脱することなく、他の様々な形態で実施することが可能である。