JP2002515991A - 信用貸し及び債務申請のオンライン審査及び承認を行うシステムと方法 - Google Patents

Abstract

(57)【要約】 リアルタイムで動作して金融機関によって申し出される商品及びサービスの申請を処理するオンラインコンピュータ化システムである。このシステムは信用貸し、債務の審査及び承認プロセスを自動化し、申請人（１０）の信用貸しスコア（２８）、金融情報及び金融機関との新規の及び既存の取引（５２）に基づいて経歴の信用力の評価を実行し、信用貸し要件の初期基準を越えた申請人（１０）に、所定限度申し出額で指定のクレジット商品を勧める。このシステムは、申請人（１０）の信用調査所の経歴（３０、３２、３４）及び自動化信用貸しスコアリング（２８）を迅速に分析し、これらの結果をＬＢＲ（１２）に送出する。このシステムは、要求された照会にしたがって、（信用調査所の経歴、信用貸しスコア、債務及び申請人の新規な又は既存の預金の体系的な評価に基づいて）申請人にアップフロント条件付き承認を供給することができる。本発明は、申請人に信用力があるが該申請人が要求していない他のサービス／商品を指定し、ＬＢＲ（１２）に伝達することもできる。ＬＢＲ（１２）は、単に要求されたもの以外に、パッケージ商品、強化（階層プライシング）及びサービスを申請人に申し出ることができる。信用貸し基準を越えた申請人（１０）に対して、本システムは特定のクレジット商品を所定の信用限度申し出額で推薦することができる。同じ申請人に対する処理が中断され、後日同じ又は異なるＬＢＲ（１２）によって継続され得る。

Description

【発明の詳細な説明】 信用貸し及び債務申請のオンライン審査及び承認を行うシステムと方法発明の分野 本発明は概して、信用貸し及び債務申請の審査及び承認を行うシステムと方法 に関し、より詳細には、信用貸し及び債務申請の自動リアルタイムオンライン審 査を行うシステムと方法に関する。発明の背景 信用貸し（クレジット）又は債務商品の申請プロセスは、通常申請人が信用貸 し又は債務商品のどちらかを請求することにより開始する；信用貸し要請の場合 は、通常申請人は信用貸しを単独の信用商品に基づいて申請する。本明細書中で 使用されているように、申請人は既存の顧客又は顧客になりそうな人のどちらで もよいし、一個人、複数の個人、又は法人、合名会社、団体等の企業実体でもよ い。どちらであろうとも、申請人とは単に信用貸し及び債務商品を求めて金融機 関に申請書を提出する個人又は企業実体のことを指す。申請人が金融機関が提供 する何かの信用貸し又は債務商品を申請するために金融機関を訪れると、地方支 店代理（ＬＢＲ）は申請人に申請書に記入するよう要請し、それからその申込書 をバックオフィス（事務処理担当部）に通常転送し、そこでその申込書は審査さ れ、要請されている信用貸しを提供するか否か、又は要請されている債務口座を 開くか否かを決定する。 大半の金融機関は、申請人が要請する特定の信用商品に対する信用力があるか 否かを決定するためにいくつかの基準を適用し、金融機関の中には、要求払預金 口座（銀行債務）を開くためのどの要請が認められるべきかを決定するためのい くつかの基準を適用するものもある。通常各商品の基準の区別は損失の危険性と 許容レベルに基づく。 あいにく全体の内の大部分が、あれやこれやの理由でこの初期審査基準で失 格となる。更に悪いことには、ＬＢＲは信用力を有する申請人をそうでない申請 人から即座には区別できない。このことによりＬＢＲはある申請人にかなりの時 間を費やさなければならず、結局それらの申請人がその金融機関の基準に適合し ていないと決定するだけである。このことは貸し出しプロセスを非能率にする； 信用貸し又は債務商品に最も値する顧客は、ＬＢＲが、中にはどの信用貸し又は 債務商品にも資格がない可能性がある申請人がいるのに全ての申請人に長時間の 販売時間を費やす間、所望する商品を得るためにより長く待たなくてはならない 。これらの非能率のせいで顧客サービスは不満足なものになり、全ての申請人に 、より高額の手数料を払わせることになる。 従って本発明は信用貸しおよび債務審査を行う方法とシステムを開発する際の 問題に関し、これらは：（１）信用力を有する申請人を識別、又は申請している 特定の商品に対する信用力を申請人がおそらく有していないことの指摘を申請時 にただちにＬＢＲに示す（従って販売セッション全てを行う必要を省く）；（２ ）系統的な照会要件を提供する；（３）金融機関のために債務審査（要求払預金 審査）を行う；（４）指定商品には階層により金利の決定を行う；（５）バンク カード商品を供給するためのインターフェイスを提供する；（６）最大資金負担 申し出（提供）論理を可能にする；そして（７）申請ペンディング機能性を提供 する。発明の概要 本発明はユーザーフレンドリー（使い易い）オンラインコンピューター化シス テムを提供することによってこの問題を解決し、このシステムは金融機関が提供 する商品やサービスに対する申請の処理を能率化し、審査及び承認プロセスにお ける多くの工程を自動化し、申請人の信用（クレジット）スコア、財務情報、及 び該金融機関との新規の又は既存の取引関係があればそれらに基づく過去の信用 力比較を行い、信用約因指定信用商品のための初期基準を超える申請人に所定の 信用限定申し出額を推薦し、必要な運用（信用貸し／債務）ポリシーが適切に完 了していることを確実にする。 本発明によると、特に信用貸し要請のために、このシステムは申請人の信用 調査所経歴、自動化された信用スコア、クレジット（信用貸し）・ポリシー、及 び申請人の該金融機関との新規の又は既存の取り引き関係があればそれらを即座 に分析し、この結果を要約した書式でＬＢＲに提供する。この機能のおかげでＬ ＢＲは必要な照会を条件として、アップフロント(前払い)自動条件付承認を提供 する能力を得ることができる。 本発明のこのシステムと方法は、要請される商品に基づいて金融機関が信用貸 し及び／又は債務商品を提供したい、又はそれ以上のサービスや別の信用貸し及 び／又は債務商品を提供したい申請人を識別する能力を提供することによって、 貸方の時間のロスという問題を軽減する。例えば、申請人が請求していない様々 な他の商品に対する信用力を潜在的に有する申請人を識別することによって、Ｌ ＢＲはより魅力的なパッケージ商品を申請人に提供し、サービスを高め、提供さ れている金利を有利なものにする可能性がある。この機能のおかげでＬＢＲは、 申請人が要請したものに加えて全範囲のサービスと便宜を該金融機関が提供する ことができる申請人に、努力の的を絞ることができる。 本発明のシステム及び方法を導入すると得られるもう一つの利点は、信用要件 特定商品のための初期基準を超える申請人に所定の信用限度申し出額を推薦でき ることである。 本発明のシステム及び方法を導入すると得られるもう一つの利点は、信用貸し を要請している申請人に、見積り支払額が商品規格パラメータを超えない信用貸 しやローン額の最大許容限度を提供できることである。従って、本発明のシステ ムと方法は、申請人の信用貸し要請に関するアップセルやカウンター・オファー を生じさせる自動応答処理に組み込む能力を提供する。本発明の結果、これまで 可能ではなかったこの能力は現在地方支店で利用できる。 本発明のシステム及び方法を導入すると得られるもう一つの利点は、金融機関 が以前もしかすると別のＬＢＲで開始されれた申請の処理を継続できることであ る。以前は、各信用貸し又は債務の申請を新しくやり直していた。例えば本発明 以前は、申請人が信用貸し又は債務商品を申請するため金融機関を訪れ、その申 請人が最初の情報を提供したが何かの理由で（時間の制約のため等）離れてしま うと、完了しなかった申請は廃棄され、その破棄された申請と共にＬ ＢＲの時間も無駄になってしまった。時間は今日の競争的環境において価値のあ る商品であるのに。本発明の結果、どのＬＢＲも自分の支店又は他のどんなＬＬ ＢＲで始められた以前の申請の処理を継続でき、従って申請人が以前供給したデ ータを全て繰り返さなければならないことを省くだけではなく、前に費やした時 間を利用することができる。 伝統的に、信用貸し申請やそれに続く条件付承認が完全に審査された後、照会 要件が発生又は生成される。本発明を導入すると得られるもう一つの利点は、提 供される額と受領される額に基づき系統的になされる照会範疇がフロントエンド プロセス中で詳しく述べられ、ＬＢＲのためにあらゆるそして全ての照会要件を 確認し、それにより申請人が利用できる情報（例えば身分証明、電話、職業、収 入等）を有していれば初期セッション中に必要な照会を遂行することができる。 このことで照会要件に従っていることを確実にすることの助けになり、不正支給 の可能性を避けることができるだけでなく、支店と申請人との間でよく起こる「 書類の追跡」を省くことができる。 本発明は、該金融機関が必要とするクレジット・ポリシーが適切に完了してい ることを保証し、ポートフォリオ（運用資産）に対する危険性を制限すると共に 、消費者小売り（個人客向け）支店が資格のある申請人の信用貸し要請（例えば 無担保及び不動産担保）に対し即座の信用貸し評価応答（条件付承認、必要な照 会をペンディングするアップセル及び／又はカウンター・オファー）を提供でき る迅速な方法を提供する。 更に本発明のもう一つの利点は、必要な照会を系統的に完了することで、信用 貸し要請とそれに続く資金の支給を現場で承認することができることである。そ れに加えて、必要な照会をＬＢＲに系統的に提出することによって、申請が完了 する前にどの指定された照会が必要なのかをＬＢＲが継続的に算出及び再算出す る必要がなくなり、時間と文書業務を大幅に削減できる。 本発明の導入がもたらすもう一つの利点は、階層による取引先向けプライシン グである。階層による取引先向けプライシングは、信用貸しを要請している新規 の又は既存の顧客に、該顧客の該金融機関との全取引関係（即ち、預金残高）に 基づく最低貸し出し（ローン）金利を提供する。適切な金利を選択する のがオートメーション化したことで、金利に多くの選択肢があることや顧客の金 融機関との取引関係が深く複雑なことにより込み入っている環境で正しい金利を 選ぶという問題を解決する。 本発明を導入して得られる利点によると、本発明は申請人の社会保障番号を系 統的に分析し、申請人の当座預金口座と信用調査所の経歴を審査し、申請人に当 座預金（要求払預金）型の取引関係を提供するべきか否かを決定する。この評価 は系統的なものであり、金融機関に不正による損失率を押さえる可能性と同時に 、当座預金の候補者となる可能性がある人を篩い分ける能率的な方法である。 更に、本発明を導入して得られる別の利点は、バンクカード取得プロセスを、 支店で始められたバンクカード申請のオンライン処理と系統的に連結させること である。 本発明の前述の目的は本システム及び方法で達成されうるものを例示しており 、前述の目的は完全ではなく他に可能な目的を制約するものではない。従って、 本発明のこれらの及び他の目的は、通常の技術を有する当業者に明らかになりう る変形を考慮して修正されて示される実施の形態として、本明細書中に述べられ た説明から明らかになるだろうし、本発明を実行することから知ることができる 。本発明は明細書中で示され説明される新規なシステム、方法、装置、及びそれ らの組み合わせにある。 本発明の前述の及び他の目的及び利点は次の説明から明らかになるが、そこで は伴う図面が参照され、その図面は参照文献の一部を形成し、図面中にはそれに 限られてはいないが例示として、本発明の好適な実施の形態が示される。図面の説明 図１は本発明のシステムと方法のブロック図である。 図２は本発明のシステムと方法で用いられる信用貸し申請信用状態（ステイタ ス）コード、信用スコア応答コード、及び信用貸し決定メッセージを示す図であ る。 図３は本発明のシステムと方法により用いられる信用商品定義保守スクリー ンを示す図である。 図４Ａ乃至Ｃはそれぞれ本発明のシステムと方法により用いられる信用決定処 理データ要素を示す図である。 図５は本発明のシステムと方法で用いられる信用商品定義保守スクリーンを示 す図である。 図６Ａ乃至Ｅはそれぞれ本発明のシステムと方法で用いられる信用決定処理デ ータ要素を示す図である。 図７は本発明のシステムと方法で用いられる信用商品定義保守スクリーンを示 す図である。 図８は本発明のシステムと方法で用いられる信用決定処理データ要素を示す図 である。 図９は本発明のシステムと方法で用いられる信用商品決定保守スクリーンを示 す図である。 図１０Ａ乃至Ｈはそれぞれ本発明のシステムと方法で用いられる信用決定処理 データ要素を示す図である。 図１１は本発明のシステムと方法で用いられる取引先向けプライシングプロフ ァイルマトリックスを示す図である。 図１２は本発明のシステムと方法で用いられる取引関係基準コード及び連結規 則を示す図である。 図１３Ａ乃至Ｂはそれぞれ本発明のシステムと方法で用いられる信用決定処理 データ要素を示す図である。 図１４は本発明のシステムと方法で用いられる商品プロファイル保守スクリー ンを示す図である。 図１５は本発明のシステムと方法で用いられる信用決定処理データ要素を示す 図である。 図１６は本発明のシステムと方法で用いられる信用決定処理照会要件を示す図 である。 図１７Ａ乃至Ｅはそれぞれ本発明のシステムと方法で用いられる信用決定処理 データ要素を示す図である。 図１８は本発明のシステムと方法で用いられる申請人製品及び保険情報スクリ ーンを示す図である。 図１９は本発明のシステムと方法で用いられる信用決定評価データ要素を示す 図である。 図２０は本発明のシステムと方法で用いられる申請人収入情報スクリーンを示 す図である。 図２１は本発明のシステムと方法で用いられる信用決定評価データ要素スクリ ーンを示す図である。 図２２は本発明のシステムと方法で用いられる信用商品決定定義保守スクリー ンを示す図である。 図２３は本発明のシステムと方法で用いられる信用決定及び信用資格授与プロ セスのためのデータ要素を示す図である。 図２４は本発明のシステムと方法で用いられる信用決定及び信用資格授与プロ セスのためのデータ要素を示す図である。 図２５は本発明のシステムと方法により用いられる信用資格授与パネルを示す 図である。 図２６乃至２９はそれぞれ本発明のシステムと方法で用いられる信用決定及び 信用資格授与プロセスのためのデータ要素を示す図である。 図３０は本発明のシステムと方法で用いられる申請人情報パネルを示す図であ る。 図３１乃至３３は本発明のシステムと方法で用いられる信用決定及び信用資格 オファープロセスのためのデータ要素を示す図である。 図３４は本発明のシステムと方法において用いられる計算式を示す図である。 図３５乃至３８はそれぞれ本発明のシステムと方法で用いられる最大資金負担 申し出計算を示す図である。 図３９は本発明のシステムと方法で用いられる申請工程状態優先順位表を示す 図である。 図４０は本発明のシステムと方法のためのシステム初期設定ダイアグラムを示 す図である。 図４１は本発明のシステムと方法で用いられる審査前及び災害審査手順を示す 図である。 図４２は本発明のシステムと方法で用いられる第一申請スコア評価を示す図で ある。 図４３は本発明のシステムと方法によるバンクカード申請のための処理を示す 図である。 図４４は本発明のシステムと方法で用いられる信用限度及び最大資金負担申し 出割り当てのダイアグラムを示す図である。 図４５は本発明のシステムと方法で用いられる付加的基準評価を示す図である 。 図４６は本発明のシステムと方法により生成される申請人要求照合及び自動応 答生成を示す図である。 図４７は本発明のシステムと方法による担保付き信用商品の特別な取り扱いを 示す図である。 図４８は本発明のシステムと方法による申請人申し出提供及び応答評価プロセ スを示す図である。 図４９は本発明のシステムと方法によるより低額の信用額プロセスのためのカ ウンター・オファー・ダウンセル・オファーを示す図である。 図５０は本発明のシステムと方法によるアップセル・オファー又はより高額の 信用オファープロセスを示す図である。 図５１は本発明のシステムと方法による終了共通プロセスを示す図である。詳細な説明 本発明のシステムと方法（図１）は、リアルタイムでの申請のオンライン処理 を提供し、それにより条件付で承認し、必要な照会をペンディングする。多くの 貸し手はオンラインシステムを介して申請を処理するが、大半は申請人の信用調 査所経歴（ブロック２８、３０、３２、及び３４）の分析結果を即時に審査する フロントエンド処理システム（ブロック１４及び１６）のシステム能力を提供し ない。本発明のシステムと方法は、新規又は既存の顧客の取引関係 （ブロック１８、２０、及び２２）を独自に処理し、信用決定要請に係わらせる 。この機能は、必要な照会を前提とした（信用調査所経歴、信用スコア、資金負 担、信用ポリシー及び顧客の金融機関との取引関係の系統的評価に基づく）アッ プフロント条件付承認を新規又は既存の顧客（ブロック１０）に提供する能力を 可能にする。 本発明は商業的に利用可能なクレジット処理システムＡＣＰＳ（ブロック２ ６）と結びつく。 本発明による処理は信用貸し及び偵務申請／承認プロセスを能率化し、その 結果、より適時に決定できる。このプロセスは、従来書類に集約されていた信用 貸し／債務申請及び承認プロセスにおける多くの工程を自動化することにより、 支店の能率と生産性を高める。 信用貸し申請処理に加えて、この導入は申請人の信用調査所情報、金融機関 、新規又は既存の顧客の金融機関との取引関係のいづれかがもしあればそれらに 基づいて、信用貸し以外の申請処理（要求払口座を開くなど）のために経歴信用 力評価も行う。これらの評価は、申請人１０が信用貸しの資格があるということ を示す結果となる決定をすることがある。これらの指摘は、ＬＢＲ１２にどの申 請人が信用承認のための初期基準を超えるかを示し、より魅力的な信用商品の機 会を与えるために申請人を識別するだけでなく、所定の信用限度申し出額を有す る特定の信用商品を勧める場合がある。解決する実務問題 クレジット応答 本発明は、消費者窓口支店が信用評価応答（条件付承認、アップセル及び／又 は必要な照会をペンディングするカウンター・オファー）を適格な（資格のある ）申請人のクレジット要求（例えば無担保の財産及び担保付不動産）に即座に提 供することができるとともに、金融機関が必要とするクレジットポリシーが適切 に完了して運用資産（ポートフォリオ）に対するリスクを潜在的に制限するよう な、迅速な方法を提供する。 全ての確立された商品プログラムの必要条件（画面（フロントエンド）審査、 災害審査、クレジットスコア、資金負担）、及び新しい又は既存の顧客の預金残 高の考察は、数秒のうちに体系的に完了してランク（Ａ、Ｂ、Ｃ、Ｄ）付けされ る。これにより、ＬＢＲ１２は信用評価状況（承認推奨、条件付承認、アップセ ル、カウンターオファー、拒絶推奨）を申請人１０に即座に送ることが可能とな る。Ａ、Ｂ、Ｃ、Ｄのステイタス（状況）ランキングはＬＢＲ１２に対して販売 セッションの間に取るべき方向を示す（即ち、体系的に提供されたランキングは 高い信用リスクと低い信用リスクを識別する）。迅速なバックオフィス処理のた めに（ブロック４４）、これらのランキングはどのクレジット要求を即時要求の ために処理するかも記述し、即座に予約するか又は即座に拒絶行動をとる。これ により、ＬＢＲ１２は金融機関にとって非常に利益のある申請人を即座に識別す ることができる。 本発明のシステム及び方法において使用される様々な応答に関連するアクショ ンを詳細に記載した以下のチャートを参照する。 商品プロファイル要件の表は、１つの領域の中の商品タイプによって、信用評 価処理（例えば画面上審査、災害審査、クレジットスコア、資金負担及び債務残 高）のパラメータを詳細に表わす。これらのパラメータは、申請が画面上の処理 システム（ブロック１４及び１６）を介して送信したとき又はＡＣＡＰＳ２６に 入れられたときに、体系的に評価される。 以前確立された承認基準の評価は、２つのセグメント（即ち２つのサブコード ；クレジット決定及び銀行債務決定）に分割される。リスク評価要素（例えば画 面上の審査、災害審査、クレジットスコア、及び資金負担）の中で、様々な条件 には特定のＡ，Ｂ，Ｃ，Ｄの応答コードランキングが割り当てられる。クレジッ ト決定を考慮中に、全ての要素のうちの最低（ＢはＡより悪く、ＣはＢより悪い 等）αランキングがクレジット決定サブコードとして選択される。クレジット決 定サブコード及び債務決定サブコードを比較し、応答コードを決定するために２ つのサブコードのうち良いほう（ＡはＢより良く、ＢはＣよリ良いなど）が選択 され、画面（ブロック１４及び１６）を介してＬＢＲ１２に逆送される。評価及 び転送には平均してほんの数秒しかかからず、毎日使用可能である。これにより 、ＬＢＲ１２はほとんど瞬時に（現場で）申請人のクレジット要求に応答するこ とが可能となる。無担保商品（例えば分割ローン）の場合、支店でクレジット要 求の交渉を済ませる能力はまた、最初のセッションの間に支店で要求を満たす機 会をＬＢＲに与える。 本発明の応答ロジックは地域及び商品に特定的であり、地域的なポートフォリ オ条件の変化や経済の変化等に対応して許容可能な信用リスクの公開を行うため に適切に調整される柔軟な信用評価基準が可能になる。本明細書に使用する「ロ ケーション」は特定の地域（即ち州等）をさす。最大資金負担の申し出 最大資金負担の申し出は、クレジット（リボルビング又はクローズド・エンド ）を要求する申請人にクレジット額又はローン額の最高限度額を提供する。要求 された商品に対する申請人の予測支払いは、全ての債務要求支払いに加え て（賃借代又は抵当権支払い、申請人が申告した債務、及び信用調査所が提示し た支払を含む）、最大で４５％等の指定抑制資金負担までの商品指定パラメータ （限度額割り当て表）を超えないようにする。この結果のアップセル又はカウン ター・オファーは、申請人のクレジット要求に関するので、本発明の応答処理の 中に取り入れられる。従って、このセッションの中で申請人１０と話し合うため にＬＢＲ（ブロック１２）で使用することができる。 最大資金負担の申し出は、申請人のクレジット要求が指定額（ロケーション及 び商品によって異なる）を超えたときに生じる。ＡＣＡＰＳ２６は以下の要素を 体系的に評価した後、以下の要素を評価した後にアップセルするかカウンター・ オファーするかを決める。 クレジット要求が送信されると、申請人の信用度、月収及び月々の債務要求の 支払（新しく要求された債務に関連する月額支払い予定額を含む）が体系的に評 価され、ＬＢＲ１２及び申請人１０に、その商品プログラムが審査判断を行う前 に許す最大開示知識が提供される。このプロセスは主に、抵当借入金支払いを含 む毎月の信用調査所情報を使用し、申請人１０が提供する情報がなくても最大資 金負担の申し出ができる。結局、本発明のプロセスは、信用評価／処理時間の削 減及び単位コスト処理の実質的な低減（即ち６５％の減少）を提供し、且つ営業 会話における上品さ、及び許可及び拒絶の迅速な（対人又は電話による応答にお ける）判断を提供する。システム照会 システム照会は、申し出され且つ許可された金額に基づいて必要な照会分類（ 商品プログラム）の体系的な識別を１ＢＲ１２に提供し、この識別は画面上に表 示される（ブロック１４及び１６）。画面はピックリスト形式で必要な照会を提 供し、ＬＢＲ１２が必要な照会を完了する方法を選択できるようにし、次にこれ をＡＣＡＰＳ２６に転送する。このシステムにより、ＬＢＲは、申請人に指示さ れたときに、申し出が行われた後いつでも申し出限度額又はローン金額を許可す ることが可能となる。こうして、申請、金融機関の決定、申請人への申し出、申 し出の受入れ、及び場合によっては資金の提供や必要な照会のペンディングを含 む、申請サイクルを完了する。しかし、満たされない照会要件がある場合、シス テムは続く新しい口座開設機能（即ち予約）が自動的に行われるのを阻止する。 システムは、後続の新しい口座開設機能を自動的に行わせるためには、全ての照 会要件が満たされてた後で“受入れ”処理を行うことを必要とし、これによって 照会要件を遵守し、不正な支給を潜在的に避ける。 必要な照会を体系的に完了することによって、クレジット要求のその場での受 入れ、及びその後の例えば分割ローン等の指定商品に対する資金提供が可能にな る。ＡＣＡＰＳ２６システムは必要な照会プロファイル（図１６〜図１７Ｅ）を 各製品分類に組み込む。これらのプロファイルはそれぞれ、要求額に基づいてど のタイプの照会が必要かを示し、最終的には申請人１０によってこの額が受け入 れられられる。必要な照会を体系的に表示することによって、申請が完了する前 にどの指定の照会が必要かをＬＢＲ１２が常に計算及び再計算を行う必要がなく なる。必要な照会タイプをＡＣＡＰＳ２６が自動的に表示するのに加え、このシ ステムはまた、画面上の処理システム（ブロック１４及び１６）には必要な照会 タイプのリストも提供し、この照会は照会要件を満たすように実行される。この リストは必要な照会選択肢のピックリストに変換され、必要な照会手順をＬＢＲ １２が迅速に完了することが簡単になる。 ＡＣＡＰ２６は、領域及び商品によってテーブル駆動される照会要件を維持し 、これらの要件は指定された申し出及び受け入れ信用金額によってどのタイ プの照会（例えば身分証明ＩＤ、電話番号、職業、収入など）が必要であるかを 適格に識別し、その後で、システムはその信用の申請を受け入れることができる 。商品タイプによって差異化することにより、ＡＣＡＰＳ２６は、支店又はバッ クオフィスが作成した要求のため及び異なる商品タイプ（例えば無担保／担保付 不動産）のために適切な照会要件を確立することができる。支店の画面システム （ブロック１４及び１６）は身分証明照会を処理させるが、バックオフィスの要 求（ブロック４４）は異なる方法で身分証明照会を必要とする。階層による取り引き（関係）プライシング 処理に関わる多くのシステム（ブロック５２）のオンラインによるリアルタイ ムの統合を介して、申請セッションの間にその顧客の全ての既存口座が体系的且 つ自動的に審査され、総残高が決定され、要求された信用商品に対してその顧客 １０に申し出される最も良い金額が提示される。金額には固定金利及び様々な金 利（例えば優遇貸出金利＋証拠金等のインデックスレート）価格決定されたロー ンタイプの両方の処理を含む。 階層による取り引き価格決定（プライシング）により、申請人の金融機関との 総取り引き（即ち預金残高）に基づいて、ローン申請人１０（即ちこの場合は新 規の又は既存の顧客）に最低貸出金利を提供する。また、この価格決定により、 金融機関の従業員は、その金融機関とのその申請人の取り引きを考慮してそのロ ーンタイプの適正な利率を提供する。本発明に従って、システムは自動的に申請 人の既存の口座及び新しく預けられた資金を調査する。適切な利率選択の自動化 により、利率選択肢の多さ及び申請人の既存又は新しく確立されたその金融機間 との取り引きの深さ及び複雑さによって複雑化した状況において正確な利率を選 択する問題が解決される。１つのローン商品のタイプ（無担保の極度貸付枠等） の範囲内でも、申請人１０にクオートされる利率が４つもある。複数の商品にわ たると、数十個の価格ポイントがあり、ＬＢＲ１２及び申請人１０が簡単且つ正 確に覚えるには多すぎる。更に、価格ポイントは、その金融機関に預けている総 預金額（この預金額は複数の口座に入っている個々の残高の合計である）を含む 幾つかの信用性要因から決められる。 申請書処理システムにおける一連の表（ＡＣＡＰＳ２６）は、複数の価格（プ ライス）ポイントを有する各商品毎の価格ポイントを含む。またこの表は、特徴 の名前（残高等）、ブレークポイント($1,500未満、$1,500又は$1,500より多い 等）、及び最終的な価格も提供する。ＡＣＡＰ２６の中の他のテーブル値は、自 動価格決定ルーチンが使用されるべきか否かを決定する。ルーチンが使用される とすると、ＡＣＡＰＳ２６は他のバンクシステム（ブロック５２）を呼び出し、 このシステムはその顧客の全ての残高を総合して総合残高を計算し、価格決定表 と共にこの総合残高を使用してその申請人１０に申し出る金額を決定する。この ようにして決定された価格は、他のバンクシステムに一貫して流され、最終的に 新しいローンを回避する。画面上のペンディングプロセス 本発明の画面上のペンディングプロセスは、開始されたがある理由または他の 理由のために完了することができない申請書提出セッションの問題に解決策を提 供する。例えば、申請人が重要な情報を落としたり、申請人（彼／彼女）がもう そのセッションを（時間がないため等の理由により）続けたくないと決める場合 もある。本発明ができる前は、申請を開始した労力は無駄になっていた（廃棄さ れていた）。申請人１０が戻ってきたときにはこのプロセスを最初から始める必 要があった。本発明のペンディングプロセスは、申請が完了していないことが分 かった場合に入力されたあらゆる情報を格納する手段を生成する。申請人１０が いて申請を完了する準備が整ったときに、その申請書を完了させるために、格納 されたデータに簡単にアクセスすることができる。 更に、容易に使用できるファイル及びプロセスにより、格納ができ、及び部分 的に完了した申請書からデータを再利用することが可能となる。ＬＢＲ１２が未 完成の申請書を呼び出してフォローアップするのを手助けする、ペンディングプ ロセスの周囲の更なるプロセスが構築される。ペンディング処理中の未完成の申 請書は、適切なフォローアップ（営業又は規則に従って）を保証するために保持 される。 本発明のペンディングプロセスにより、ＬＢＲ１２はメニューオプション“格 納してファイルをペンディングする（Save to Pending File）”（このセッショ ンの間に入力された全てのデータを保存する）をハイライトして選択するだけで よくなる。この時点で、データは画面上の環境（ブロック１４及び１６）の中に 格納され、その申請書が将来完了され得る時まで待つ。申請人１０が戻ってきた ときに、その金融機関の中のどのＬＢＲ１２でも、メニューオプション“ペンデ ィング／条件付き（Pending/Conditional）”を介して未完成の申請書を簡単に 呼び出し、あらゆる欠けていた情報を加えてその申請書を申請書処理システム（ ＡＣＡＰＳ２６）に送信することができる。要求支払預金口座（ＤＤＡ） 金融機関は、申請人の信用調査所（ブロック２８，３０，３２及び３４）の経 歴を体系的に調査して彼らに当座預金（要求支払預金口座）型の取り引きを申し 出るか否かを決定する。この評価は完全に体系的であり、潜在的な当座預金の候 補を審査する一方、不正な損害率を低く抑える効率的な方法を金融機関に与える 。 当座預金（要求支払預金口座）のための全ての要求は、体系的な社会保障番号 検索、組み合わせされた金融機関のデータベース情報検索、及び災害審査を介し て提出される。これにより、即座に信用力の評価が可能になる。この特徴により 、ＬＢＲが無効にするように適切に権利が与えられない限り、社会保障番号が一 致しない又は存在しない社会保障番号である、又は信用力を傷つけるような行い 、などの理由によりＬＢＲ１２が当座預金を申し出るべきではない申請人１０を 識別する、効率的な方法をＬＢＲ１２に提供する。 画面上のシステムに現れるメッセージ（ブロック１４及び１６）は、信用評価 の結果を示す。適格な申請の場合は、ＬＢＲ１２は即座に当座預金の開設を許可 する。不適格な申請の場合は、体系的な信用基準に基づいて、適切な表示又は拒 絶選択を有する無効画面（指定変更）がＬＢＲ１２に提供される。ＡＣＡＰＳ／バンクカード処理 本発明のこの特徴は、支店がもとになっているバンクカード申請のオンライ ン処理のためのバンクカード取得プロセス（ブロック４０）への体系的なリンク を提供する。先述のクレジット申請処理のように、支店が受けたバンクカード申 請は、最大資金負担申し出及び照会要件と共に、信用応答を反映する応答コード （Ａ，Ｂ，Ｃ，Ｄ）を必要とする。 このプロセスは、バンクカード取得システム（ブロック４０）と体系的にイン ターフェースし、クレジット応答（ＡＣＡＰＳ２６上で行われる標準的な災害審 査及び自動化された信用スコア、及びバンクカードシステム４０上で行われる不 正審査、重複氏名の処理、及び既存のカードメンバー審査を含む）に対してほぼ 瞬時に応答する。システム的な処理の結果、申請要求の回転時間及びクレジット カードの納入をより速くすることが可能となり、また、以前の紙を大量に使用す るバンクカード申請処理を無くすることにより大きな利益が可能となる。 体系的処理は、この処理が、既存のカードメンバー、不正、ＳＳＮ検索、及び 重複申請のためのバンクカード取得システム（ブロック４０）に属する場合でも 、又はバンクカードの信用評価プロセス（例えば災害審査、クレジットスコア等 ）を有するＡＣＡＰＳ２６に属する場合でも、必要な信用評価処理を介して支店 が元となる全てのバンクカード申請を管理する。肯定的な応答が生成される場合 、支店に戻されるメッセージは条件付承認（特定額のクレジットの“受け入れ” によって満たされる）を含み、この承認は次に、予約のためにバンクカードサー ビスシステム（ブロック４２，６２及び４０）に体系的に運ばれる。拒絶決定は 、断りのレターを発行するためにバンクカード取得システム４０に適切な処理情 報を送る。またこのシステムは、バックオフィス（ブロック４４）がアピール状 況に介在することを可能とする。クレジット評価 この特徴により、（フラッグ／ライト／申し出額のいずれかによって）どの申 請人１０が最初の信用評価審査（例えば災害審査、クレジットスコア）を超える かをＬＢＲ１２が識別できるような“信用評価”の体系的な処理を提供する。こ れにより、最初の体系的な評価が、申請人１０には信用力があるがまだ 必要な照合に委ねられていることを示したため、ＬＢＲ１２が営業力を相互売り 込みの追加的な信用商品に最大限そそげるようにする。この体系的な“信用評価 ”プロセスは、申請人が信用商品を申し込んでいない場合であっても自動的に発 生する。従って、預金口座を開設するために金融機関にやってきた申請人は、Ｌ ＢＲが信用評価見込みを識別できるように、“信用評価”プロセスによって評価 される。 画面上の処理システムへのＡＣＡＰＳリンクを介して体系的信用評価は“信用 力のある”申請人を即座に識別し、これによりＬＢＲ１２は最初の信用基準を超 過したこれらの申請人１０を即座に識別することができる。こうしてＬＢＲ１２ はこれらの申請人への相互売り込みの機会を最大限に活用することができる。 信用評価基準（例えば災害審査、クレジットスコア等）は申請人の信用力を評 価し、次に画面システムに“信用評価”のマーカーを表示するかどうかを決める 。このマーカーは“信用評価”金額を示してもよいし、又は信用商品に関係する 延長販売セッションが必要かどうかを示す最初の信用基準審査を申請人１０が超 過したことをＬＢＲ１２に単に示してもよい。また、システムは申請セッション の間に申請人から得た情報の要素に基づいて、及びマネジメントによって選択さ れた商品を含む表に基づいて、特定商品を推奨する。このシステムは、申請人１ ０が“信用評価”としての申し出金額よりも多くのクレジットを望んだ場合、“ 信用評価”申し出を“クレジット要求”に変換させるように設計された。“クレ ジット要求”に再ラベル付けするシステム的な切り替えは、標準クレジット要求 に関連する全ての必要な信用評価基準（例えば災害審査、クレジットスコア、資 金負担等）、及び申請人１０がクレジット要求基準に合わない場合は、拒絶行為 理由の適切な認識を、要求し及び呼び出す。一番近いコンペティタ 本発明のクレジット処理は、識別のユニークポイントである。金融機関の債務 及び信用審査／承認プロセスはより広範囲にわたり、他のオンライン処理に比べ て迅速なサービスを提供する。本発明は、紙の申請書を使う必要なく無担 保の債務及びクレジット要求をシステム上に直接入力するためのオンライン処理 を、ＬＢＲ１２及び彼らの申請人１０に提供する。担保付申請は、紙面で受け取 る前に、条件付き承認（必要な照会及び承認を条件とする）を受け取る場合もあ る。 １ステップの取り引き口座開設と併せて、申請人１０は分割ローン、極度貸付 枠、及びチェックオーバー−手形保護を含む全ての銀行取り引きを即座に開設す ることができる。 システムの概説 本発明のシステムは、フロントエンド処理通信システム１６に結合した金融ネ ットワーク端末１４を含み、このシステム１６は、全ての既存の顧客に関する情 報を含むデータベース１７にアクセスできる。フロントエンド処理通信システム １６は、金融機関外の社会保障番号及び小切手の筆跡データベース（チエックス システムズ（Chexsystems）として既知である）ならびにＡＣＡＰＳ処理システ ム２６に接続されており、これはいくつかの他のシステムにアクセスする。これ らのシステムには、オンラインバンクデータアクセスシステム２４、信用調査所 システム２８、データアクセスシステム３６、バンクカード口座履行システム４ ０、及び申請人ルーティング／情報登録システム４２が含まれる。 信用調査所システムは、少なくとも３つの主な信用（クレジット）データベー ス、即ちエキファックス（Equifax）３０、トランスユニオン（Trans Union）３ ２及びＴＲＷ３４に通じるリンクを含む。 ＡＣＡＰＳ処理システム２６はデータベース２７を含み、これは、例えば処理 中の申請書、完了した照会要件及び審査中の信用限度申し出など、既存の顧客の 情報を記憶する。 オンライン信用貸し（クレジット）決定後の処理は、マニュアルバックオフィ ス審査と共に、申請書ルーティング／情報登録システムによって行われる。 バンクカード口座履行システム４０は、バンクカードの申請を処理するために 使用される。 データアクセスシステム３６は、バンクカード申請の処理の際に既存のバン クカードデータを得るために使用される。 オンラインバンクデータアクセスシステム２４は、既存の顧客に関する情報を 得るために使用される。これは、４つのデータベース、即ちグローバル顧客情報 ファイル１７、リアルタイム口座取引／現在の残高データ記憶装置１８、顧客情 報人口統計データベース２０及び付加的な銀行取引データベース２２を含む。 オンライン信用貸し審査及び承認を行うシステム及び方法は、図４０のブロッ ク２０００で始まるフローチャートに象徴的に示されている。フロントエンド処 理システム（図１のブロック１４及び１６）にアクセスし、以下をデータ入力ス クリーンに入力する：(１)申請人１０の要請する信用貸し商品の情報；（２）処 理中（ペンディング）の申請書；又は（３）申請人１０のための信用限度申し出 。これらを、ＡＣＡＰＳ顧客情報ファイル記憶装置（図１のブロック２７）から 起動して、信用貸し決定処理を行うことができる（ブロック２００２）。 入力データ（ブロック２００２）を、強化ＡＣＡＰＳ２６に転送する（ブロッ ク２００４）。この転送により、オンライン審査及び承認決定処理が開始される 。システムは経歴照合処理を行い、信用限度申し出を割り当てるために申請人の 更なる信用力を確認する（ブロック２００５）。 申請人１０の情報を用いて、商品保守（Product Maintenance）−４スクリー ンの関係プロファイル（Relationship Profile）パラメータ（図７のエレメント ２０）によって定義されるような検索を、銀行のオンラインデータシステムにお いて行う（ブロック２００６）。銀行のオンラインシステムは、リアルタイムの 口座取引及び現在の残高記憶装置（図１のブロック１８）、既存の顧客の人口統 計データベース（ブロック２０）及び更なる取引データベース（ブロック２２） からなる。これらの既存の銀行データシステムへの検索アクセスは、オンライン アクセスシステム（ブロック２４）によって行われる。より多くのより完全な既 存の顧客の関係（取引）データが、グローバル顧客情報ファイル（ブロック１７ ）からも検索される。これらのシステムから集められた情報には、既存の顧客の 金融機関との関係の長さ（月単位）、資産口座の総数及びド ル額ならびに債務口座の総数及びドル額が含まれる。顧客との関係が存在する場 合（ブロック２００８からのＹＥＳブランチ）、図１２に概略的に示される連結 規則を用いて、顧客関係データから関係基準コードを生成する（ブロック２０１ ０）。次に、（図１１に示される）商品が割り当てられた関係プライシングプロ ファイル（Relationship Pricing Profile）において関係コードを検索キーとし て使用し、各顧客の既存の金融機関との関係に基づいて価格の申し出を行う際に アクセスする（図１４に示される）商品プロファイル（Product Profile）表を 決定する。 関係が存在しなかった場合（ブロック２００８からのＮＯブランチ）、割リ当 てられたデフォルト商品プロファイル（図１４）にアクセスして価格の申し出を 提供する（ブロック２０１４）。 全てのデータを入力した後、商品保守−１（ＰＭ１）表（図３に示される）に おいて構成されるように、最小年齢、最低所得（収入）、不正及び二重申請に関 するフロントエンド事前審査を行う（図４１のブロック２０２０）。申請が事前 審査のパラメータを満たさなかった場合（ブロック２０２２のＹＥＳブランチ） 、これをバックオフィスに送り、（図３９に示される）ＣＣＨ優先表から最優先 に割り当てられたルート状態を用いて更に審査する（ブロック２０２４）。バッ クオフィス審査の際、情報ディスプレイとして、保険業者又は審査員によって商 品及び保険情報（Product and Insurance Information）(ＰII)（図１８）なら びに所得情報（Income Information）(ＩＮＣ)（図２０）を示すスクリーンにア クセスし、バックオフィス信用貸し決定プロセスを助けることができる。申請は “ＥＮ”（処理中）の状態を維持し、審査が進行中であることを申請人１０に通 知する（ブロック２０２６）。ここで、本発明の処理は完了セッションプロセス に分かれる（ブロック２０２８）。 システムは申請人１０に対して生じた任意の信用限度申し出を提供し、ここで ＬＢＲ１２は申請人１０とこれらの申し出について話し合うことができる（図５ １のブロック２２５２）。申請人がこれらのうちの任意の申し出の受諾を希望す る場合、信用限度を信用貸し要請に変更し、最終決定割り当てのためのオンライ ン信用貸し処理が必要となる（ブロック２２５６）。申請人が申し 出を受諾しないことを決定したか（ブロック２２５４からのＮＯブランチ）、又 は申し出を要請に変更する処理が完了した場合、ＡＣＡＰＳ顧客情報ファイル（ 図１のブロック２７）を更新して全ての信用貸し申請、信用限度申し出及び入力 された申請人照会情報を記憶する（ブロック２２５８）。この情報の記憶及びこ の情報へのアクセスは、信用評価パネル(Credit Qualification Panel)（ＱＵＡ ）(図２５)及び顧客情報パネル（Customer Information Panel）(ＣＩＦ)(図３ ０)に示されている。商品保守−９（ＰＭ９）スクリーン（図２２）によって定 められるように、この情報の使用及び限度申し出へのアクセスは、割り当てられ た満期まで利用可能である。更新が完了すると、処理は終了する（ブロック２２ ６０）。 事前審査を通過した場合（２０２２からのＮＯブランチ）、構成された不正照 会を行う（ブロック２０３０）。申請がこの照会要件を満たさなかった場合（ブ ロック２０３０からのＹＥＳブランチ）、前述（ブロック２０２４及び２０２６ ）のように申請書のルーティング及び申請人への通知を行い、ここで処理は前述 の図５１に示される完了セッションプロセスに分かれる（ブロック２０２８）。 不正照会要件を満たした場合（ブロック２０３０からのＮＯブランチ）、図１ のブロック２８，３０，３２及び３４に示されるような信用調査所の報告を集め る（ブロック２０３２）。 構成される災害／ポリシー審査を通過しなかった場合（ブロック２０３４から のＹＥＳブランチ）、申請ステイタスを“ＲＴ”（拒絶推奨）に変更し（ブロッ ク２０３６）、前述のようにバックオフィス審査に送る（ブロック２０４８）。 次に、前述のように、処理は図５１に示される完了セッションプロセスに分かれ る（ブロック２０２８）。災害／ポリシー審査を通過した場合（ブロック２０３ ４からのＮＯブランチ）、災害応答コードを決定し、申請に割り当てる（ブロッ ク２０３８）。 資金負担照会要件を満たさなかった場合（ブロック２０４０からのＹＥＳブラ ンチ）、申請ステイタスを“ＤＢ”（資金負担審査）に変更し（ブロック２０４ ２）、前述のようにバックオフィス審査に送る（ブロック２０４８）。次 に、前述のように、処理は図５１に示される完了セッションプロセスに分かれる （ブロック２０２８）。資金負担照会要件を満たした場合（ブロック２０４０か らのＮＯブランチ）、資金負担応答コードを決定し、申請に割り当てる（ブロッ ク２０４４）。 （図９に示される）商品保守−８（ＰＭ８）において構成されるパラメータ及 び規則を用いて、スコアリング応答コードを申請に割り当てる（図４２のブロッ ク２０５２）。このスコアが拒絶カットオフ値以下である場合（ブロック２０５ ４からのＹＥＳブランチ）、申請ステイタスを“ＲＴ”（拒絶推奨）に変更し（ ブロック２０６２）、前述のようにバックオフィス審査に送る（ブロック２０７ ２）。次に、審査が進行中であることを申請人１０に通知し（ブロック２０７４ ）、前述のように、処理は図５１に示されるような完了セッションプロセスに分 かれる（ブロック２０７６）。 申請のスコアが拒絶カットオフ値よりも大きく、調査値よりも小さい場合(ブ ロック２０５６からのＹＥＳブランチ)、調査２ルーテイング（Investigate 2 R outing）を申請に割り当て（ブロック２０６４）、申請ステイタスを“ＲＴ”（ 拒絶推奨）に変更し（ブロック２０６２）、前述のようにバックオフィス審査に 送る（ブロック２０７２）。次に、審査が進行中であることを申請人１０に通知 し（ブロック２０７４）、前述のように、処理は図５１に示されるような完了セ ッションプロセスに分かれる（ブロック２０７６）。 申請のスコアが調査値以上であり、承認カットオフ値未満である場合（ブロッ ク２０５８からのＹＥＳブランチ）、調査１ルーティングを申請に割り当てる（ ブロック２０６４）。商品が担保付きである場合（ブロック２０６８からのＹＥ Ｓブランチ）、申請ステイタスを“ＣＡ”（条件付き承認）に変更する（ブロッ ク２０７０）。そうでない場合（ブロック２０７８からのＮＯブランチ）、申請 ステイタスを“ＲＴ”（拒絶推奨）に変更する（ブロック２０６２）。ここで、 前述のようにバックオフィス審査に送る（ブロック２０７２）。次に、審査が進 行中であることを申請人１０に通知し（ブロック２０７４）、前述のように、処 理は図５１に示されるような完了セッションプロセスに分かれる(ブロック２０ ７６)。 上記３つのテストに合格しなかった場合（ブロック２０５４，２０５６及び２ ０５８からのＮＯブランチ）、申請のスコアは承認カットオフ値以上であると決 定する（ブロック２０６０）。商品が担保付きである場合（ブロック２０７８か らのＹＥＳブランチ）、申請ステイタスを“ＣＡ”（条件付き承認）に変更する （ブロック２０８０）。そうでない場合（ブロック２０７８からのＮＯブランチ ）、申請ステイタスを“ＲＡ”（承認推奨）に変更する（ブロック２０８２）。 商品がバンクカードである場合（ブロック２０８４からのＹＥＳブランチ）、 バッチデータ保管所にアクセスし、申請人１０の追加のバンクカード情報を検索 する（図４３のブロック２０９２）。入力された全てのデータ、ならびに電子的 に収集された申請人の情報及び要請された商品の情報を、バンクカード処理シス テムにおける承認のためにバンクカード口座履行システム（図１のブロック４０ に示される）に転送する（ブロック２０９４）。申請がバンクカード口座履行シ ステム４０から「合格」の指示を受けなかった場合（ブロック２０９６からのＮ Ｏブランチ）、申請ステイタスを“ＢＡ”（バンクカード推薦）に変更し（ブロ ック２１００）、次に承認ルーティング状態を割り当て（ブロック２１０２）、 前述のようにバックオフィス審査に送る（ブロック２１０４）。次に、審査が進 行中であることを申請人１０に通知し（ブロック２１０６）、前述のように、処 理は図５１に示されるような完了セッションプロセスに分かれる（ブロック２１ ０８）。 審査及び承認プロセスにおいてまだ継続中である申請の場合、申請の信用のス コア及び申請人の所得、又は申請人の銀行との関係金額及び所得に基づいた信用 限度額を要請される商品に割り当てる（図４４のブロック２１１２）。 推奨される限度割り当て額が、資金負担審査用の商品保守−３（ＰＭ３、図５ ）に示される範囲内である場合（ブロック２２１４からのＹＥＳブランチ）、図 ３４と、その使用例を図３５、図３６、図３７及び図３８に示すように、最大資 金負担申し出（ＭＤＢＯ）を計算する（ブロック２１１６）。ＰＭ１（図３）の 使用割り当て限度パラメータが“Ｙ”に設定されている場合（ブロック２１１８ からのＹＥＳブランチ）、最終的な限度額割り当ては推奨される信用 限度額及びＭＤＢＯ額のうち金額の少ない方である（ブロック２１２０）。ＰＭ １（図３）の使用割り当て限度パラメータが“Ｎ”に設定されている場合（ブロ ック２１２２からのＹＥＳブランチ）、最終的な限度額割り当ては要請されるロ ーン額及びＭＤＢＯ額のうち金額の少ない方である（ブロック２１２４）。ＰＭ １（図３）の使用割り当て限度パラメータが“Ｘ”に設定されている場合（ブロ ック２１２６からのＹＥＳブランチ）、最終的な限度額割り当ては商品の最大許 容額及びＭＤＢＯ額のうち金額の少ない方である(ブロック２１２８)。 申請人１０が学生、非居住外国人又は自営業者であり、ＰＭ３（図５）の例外 パラメータを満たす場合(図４５のブロック２１３６からのＹＥＳブランチ)、申 請ステイタスを更新せず（ブロック２１４０）、例外審査ルーティング状態を割 り当て（ブロック２１４２）、前述のバックオフィス審査に送る（ブロック２１ ４４）。次に、審査が進行中であることを申請人１０に通知し（ブロック２１４ ６）、前述のように、処理は図５１に示されるような完了セッションプロセスに 分かれる（ブロック２１４８）。 申請人１０が上記パラメータに適合しない場合（ブロック２１３６からのＮＯ ブランチ）、申請処理を続行する。既存の顧客の照会データ（図３０の顧客情報 パネルに示されるようなＡＣＡＰＳ顧客情報ファイルに記憶されている）を検索 し、商品保守−９スクリーン（ＰＭ９、図２２）に設定された満期を比較するこ とによって使用を有効にする。最終的な限度額割り当て／信用貸し申し出及び商 品に割り当てられた照会プロファイル(Verification Profile)（図１６に示され る）を使用して、必要な照会を決定する（図４６のブロック２１５２）。 次に、銀行債務残高応答コードを割り当てる（ブロック２１５４）。続いて、 信用貸し応答コードで最も悪いものを選択する（ブロック２１５６）。債務残高 コード及び信用貸し応答コードのうち良い方を選択することにより、最終的な応 答コードを申請に割り当てる（ブロック２１５８）。 申請のスコア、申請人１０のデータの自動審査及び割り当てられた応答コード に基づいて、自動の信用貸し申し出決定を提供する（ブロック２１６０）。この 信用貸し申し出決定は、図２に示される決定及びランキングコードチャー トからの、表に基づいた応答である。商品が担保付きである場合、“ＲＴ”（拒 絶推奨）又は“ＣＡ”（条件付き承認）（必要な照会及びペーパーワークのペン ディング）の決定を割り当てる。商品が無担保である場合、以下の決定を割り当 てることができる：“ＲＴ”（拒絶推奨）、“ＲＡ”（承認推奨）、“ＣＡ”（ 条件付き承認）又は“ＣＯ”（カウンターオファー）。 商品が担保付きである場合（図４７のブロック２１６６からのＹＥＳブランチ ）、割り当てられるステイタスを吟味する（ブロック２１６８）。申請ステイタ スが“ＣＡ”に設定されている場合（ブロック２１６８からのＹＥＳブランチ） 、条件付き承認であり、申請の最終処理が進行中であることを申請人１０に通知 する（ブロック２１７０）。ステイタスが“ＲＴ”である場合（ブロック２１６ ８からのＮＯブランチ）、申請を更に審査することが必要であり、審査が進行中 であることを申請人１０に通知する（ブロック２１７２）。そして、申請をバッ クオフィスに送り、最終処理及び審査を行う（ブロック２１７４）。前述のよう に、処理は図５１に示されるような完了セッションプロセスに分かれる（ブロッ ク２１７６）。 商品が無担保である場合（ブロック２１６６からのＮＯブランチ）、申請ステ イタスを吟味する（図４８のブロック２１８２、２１９０、２１９８及び２２０ ２）。ステイタスが“ＲＴ”である場合（ブロック２１８２のＹＥＳブランチ） 、前述のように申請をバックオフィス審査に送る（ブロック２１８４）。そして 、審査が進行中であることを申請人１０に通知する（ブロック２１８６）。前述 のように、処理は図５１に示されるような完了セッションプロセスに分かれる（ ブロック２１８８）。 ステイタスが“ＲＡ”である場合（ブロック２１９０からのＹＥＳブランチ） 、ローンの申し出を申請人１０に提供し、この申し出を受諾するか又は拒否する かを尋ねる（ブロック２１９２）。申請人１０がローンの申し出を受諾した場合 （ブロック２１９２からのＹＥＳブランチ）、申請ステイタスを“ＡＰ”（ペン ディング予約承認）に更新する（ブロック２１９４）。そうでない場合（ブロッ ク２１９２からのＮＯブランチ）、ステイタスを“ＡＷ”（申請取り消し）に更 新する（ブロック２１９６）。ここで、前述のように、処理は図５１に示 されるような完了セッションプロセスに分かれる（ブロック２１８８）。 ステイタスが“ＣＯ”である場合（ブロック２１９８からのＹＥＳブランチ） 、カウンターオファーダウンセルのより少額の信用額を申請人１０に通知する（ 図４９のブロック２２０８）。申請人１０がダウンセルローン額を受諾した場合 （ブロック２２１０からのＹＥＳブランチ）、完全にするために必要な照会を行 う（ブロック２２１２）。照会要件が完全であった場合（ブロック２２１２から のＹＥＳブランチ）、申請ステイタスを“ＡＰ”（ペンディング予約承認）に更 新する（ブロック２２１４）。必要な照会が不完全であった場合（ブロック２２ １２からのＮＯブランチ）、申請ステイタスを“ＣＯ”（カウンターオファー（ 必要な照会のペンディング）に更新する（ブロック２２１６）。申請人１０が申 し出を拒否した場合（ブロック２２１０からのＮＯブランチ）、申請人は参照審 査を依頼することができる（ブロック２２１８）。申請人が審査を希望しない場 合（ブロック２２１８からのＮＯブランチ）、申請ステイタスを“ＮＯ”（ダウ ンセル申し出拒否）に更新する（ブロック２２２０）。申請人が審査を希望する 場合（ブロック２２１８からのＹＥＳブランチ）、申請ステイタスを“ＣＯ”（ カウンターオファー）（審査のペンディング）に更新する（ブロック２２２２） 。次に申請をバックオフィスに送り、申請人１０が要請した審査を行う（ブロッ ク２２２４）。ここで、前述のように、処理は図５１に示されるような完了セッ ションプロセスに分かれる(ブロック２２２６)。 申請ステイタスを“ＣＡ”に決定する（ブロック２１８２，２１９０及び２１ ９８からのＮＯブランチ）。条件付き承認であることを申請人１０に通知する（ 図５０のブロック２２３０）。より多額のアップセル信用貸し申し出がある場合 （ブロック２２３２からのＹＥＳブランチ）、より多額の申し出を申請人１０に 提供する（ブロック２２３４）。ここで、初めの要請から承認された申し出まで の範囲の額のローン申し出を受諾するか否かを申請人１０に尋ねる。申請人１０ が申し出を受諾する場合（ブロック２２３６からのＹＥＳブランチ）完全にする ために必要な照会を行う（ブロック２２４０）。必要な照会が完全である場合（ ブロック２２４０からのＹＥＳブランチ）、申請ステイタスを“ＡＰ”（ペンデ ィング予約承認）に更新する（ブロック２２４２）。必要な照会 が不完全である場合（ブロック２２４０からのＮＯブランチ）、申請ステイタス を“ＣＡ”（条件付き承認）(必要な照会のペンディング)のままにする（ブロッ ク２２４４）。申請人１０が申し出を拒否した場合（ブロック２２３６からのＮ Ｏブランチ）、申請ステイタスを“ＡＷ”（申請取り消し）に更新する（ブロッ ク２２３８）。ここで、前述のように、処理は図５１に示されるような完了セッ ションプロセスに分かれる（ブロック２２４８）。 好適な実施の形態を特に参照して本発明を詳細に説明したが、本発明を他の及 び異なるタスクに実施できることを容易に理解すべきである。当業者には容易に 明らかであるように、本発明の趣意及び範囲内で変形及び変更を生じることがで きる。従って、前述の開示及び図面は例示のみの目的であり、請求の範囲によっ て画定される本発明を制限するものではない。

───────────────────────────────────────────────────── フロントページの続き (81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＤＥ， ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，ＩＴ，Ｌ Ｕ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ，ＣＦ ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＭＬ，ＭＲ，ＮＥ， ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＫＥ，ＬＳ，ＭＷ，ＳＤ，Ｓ Ｚ，ＵＧ)，ＥＡ(ＡＭ，ＡＺ，ＢＹ，ＫＧ，ＫＺ，ＭＤ ，ＲＵ，ＴＪ，ＴＭ)，ＡＬ，ＡＭ，ＡＴ，ＡＵ，ＡＺ ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，ＣＡ，ＣＨ，ＣＮ，ＣＺ， ＤＥ，ＤＫ，ＥＥ，ＥＳ，ＦＩ，ＧＢ，ＧＥ，ＨＵ，Ｉ Ｌ，ＩＳ，ＪＰ，ＫＥ，ＫＧ，ＫＰ，ＫＲ，ＫＺ，ＬＫ ，ＬＲ，ＬＳ，ＬＴ，ＬＵ，ＬＶ，ＭＤ，ＭＧ，ＭＫ， ＭＮ，ＭＷ，ＭＸ，ＮＯ，ＮＺ，ＰＬ，ＰＴ，ＲＯ，Ｒ Ｕ，ＳＤ，ＳＥ，ＳＧ，ＳＩ，ＳＫ，ＴＪ，ＴＭ，ＴＲ ，ＴＴ，ＵＡ，ＵＧ，ＵＺ，ＶＮ (72)発明者 サスマン、ローレンス ジェイ. アメリカ合衆国 10016 ニューヨーク州 ニューヨーク イースト サーティーエ イス ストリート 330 アパートメント 43キュー (72)発明者 メイア、モナ アメリカ合衆国 60565 イリノイ州 ネ イパービル ゴルフ ドライブ 1849 (72)発明者 ディーン、チャールズ ジー．ジュニア. アメリカ合衆国 60181 イリノイ州 ヴ ィラ パーク ハーバード 435 (72)発明者 セイブ、デニス アメリカ合衆国 63376 ミズーリ州 セ ント ピータース ワイアット ドライブ 596 (72)発明者 マサイ、リチャード アメリカ合衆国 27615 ノース カロラ イナ州 ローリ ホワイト チャペル ウ ェイ 3712 【要約の続き】 商品、強化（階層プライシング）及びサービスを申請人 に申し出ることができる。信用貸し基準を越えた申請人 （１０）に対して、本システムは特定のクレジット商品 を所定の信用限度申し出額で推薦することができる。同 じ申請人に対する処理が中断され、後日同じ又は異なる ＬＢＲ（１２）によって継続され得る。

Claims (1)

1. 【特許請求の範囲】 １．金融機関によって申し出される商品又はサービスに対する申請人の申請の自 動オンライン審査をリアルタイムで実行する方法であり、 ａ）データの第１のセットをデータ処理通信システムに入力するステップを 有し、前記データは前記申請人によって提供される情報に関連し、 ｂ）データの第２のセットを前記データ処理通信システムに入力するステッ プを有し、前記データの第２のセットは、前記申請人によって要求される商品又 はサービスに関連し、 ｃ）前記第１のデータを使用してリアルタイムベースで前記申請人との関係 プロファイルを特定するステップを有し、前記関係プロファイルは、前記申請人 の金融機関に対する資産及び債務の額に基づく、 自動オンライン審査実行方法。 ２．ｄ）前記関係プロファイルを表すカテゴリーを形成するステップを有し、 ｅ）前記カテゴリーを使用して商品プロファイル表からカテゴリーに基づい たプライシング方式を抽出するステップを有し、前記表は、金融機関によって申 し出される商品又はサービスの価格に関する情報を含む、請求項１記載の方法。 ３．ｆ）前記第１のデータ及び前記関係プロファイルを、予備審査基準に対して 比較し、前記予備審査基準を満たすか否かを決定するステップを有し、前記予備 審査基準は前記顧客の収入を含み、 ｇ）前記予備審査基準を満たさなかった申請人の申請をマニュアル審査に送 るステップを有する、請求項２記載の方法。 ４．ｄ）前記データの第１のセットに不正照会を実行するステップを有し、 ｅ）前記データの第１のセットを使用して少なくとも一つの信用調査所から クレジットレポートを収集し、前記クレジット報告を最低限度の災害／ポリシー 基準に対して比較するステップを有する、請求項１記載の方法。 ５．ｄ）社会保障データベースにアクセスし、第１のセットからの情報を使用し て社会保障番号審査を実行するステップを有し、 ｅ）前記データの第１のセットを使用して信用調査所にアクセスするステッ プを有し、 ｆ）データの第１のセット及び第２のセットに対して最低限度の災害／ポリ シー基準を適用するステップを有する、請求項１記載の方法。 ６．ｆ）前記災害／ポリシー基準を満たさなかった申請人の申請をマニュアル審 査に送るステップを有する、請求項４記載の方法。 ７．ｅ）災害応答コードを前記データの第１のセットに割り当てるステップを有 し、 ｆ）前記クレジット報告及び前記データの第１のセットに基づいて資金負担 額を用意するステップを有し、 ｇ）前記資金負担額を資金負担表のパラメータと比較するステップを有する 、請求項４記載の方法。 ８．ｅ）資金負担コードを決定し、前記コードを前記申請人の申請に割り当て、 スコアリング応答コードを前記申請人の申請に割り当てるステップを有し、 ｆ）前記スコアリング応答コードと、拒絶カットオフ値とを比較するステッ プを有する、請求項４記載の方法。 ９．ｅ）前記申請人の申請のスコアと、承認カットオフ値とを比較するステップ を含み、 ｆ）前記承認カットオフ値を満たさない申請人の申請をマニュアル審査に委 託するステップを有する、請求項４記載の方法。 １０．ｄ）信用貸し限度額を前記申請人に割り当てるステップを有し、 ｅ）要求されたローン額が商品維持ファイルの制限内であるかどうか決定 するステップを有し、 ｆ）資金の支払いを前記申請人に承認するステップを有する、請求項１記 載の方法。 １１．金融機関によって申し出される商品又はサービスに対する申請人による申 請を処理するコンピュータシステムであって、以下のプロセスを実行するプログ ラミングを含み、前記プロセスは、 ａ）所定の営業ポリシーによって申請を評価し、申請を所定のスコアリ ングによってランク付けし、評価状態を地方支店代理に迅速に伝達し、 ｂ）特定の商品の要求に応じて、申請の信用貸しの最大許容額を地方支店 代理に送出し、ここで、申請人が提供した債務及び信用調査所が提供した債務を 含む、申請人の全ての公知の債務を加えた特定の商品に対する見積額は、格納さ れた商品の特定のパラメータを越えず、 ｃ）地方支店代理に、申し出され受理された額に応じて要求された照会カ テゴリーの体系的な識別手段を送出し、地方支店代理が要求された照会を完了す る方法を選択することを可能とし、全ての要求された照会が完了する前に申請を 予約することを防ぎ、 ｄ）信用を審査して申請人に要求された商品を提供する最高価格を生じさ せる総残高額を決定する場合、申請人の預金全てを自動的に審査し、前記コンピ ュータは前記決定を実行するための各商品に対する複数の価格ポイントを含む一 連の表を含み、 ｅ）申請の完了が後日任意の地方支店代理によって可能となるフォーマッ トで、システムに未完了な申請を保持し、地方支店代理に、未完了申請の自動的 経年に基づいて未完了な申請の追跡を促進する、 コンピュータシステム。 １２．ｆ）申請人の信用貸しの経歴の審査を実行し、申請人に要求支払預金口座 型の取引を申し出るかどうかを決定する、請求項１１記載のシステム。 １３．前記プログラミングは、 ｆ）バンクカード申請のオンライン処理のためのバンクカード獲得プロセ スへのリンクを提供するプロセスをさらに含む、請求項１１記載のシステム。 １４．前記プログラミングは、 ｆ）信用貸しの資格を有する申請人を地方支店代理に通知するプロセスを 有し、ここで信用貸しの資格を有する申請人は初期信用評価審査を通過した申請 人である、請求項１１記載のシステム。 １５．前記照会カテゴリーは、身分証明書、電話番号、職業及び所得からなる群 から選択される少なくとも一つを含む、請求項１１記載のシステム。 １６．前記照会カテゴリーは、申請人の返済能力、地位、担保及び信用に関連す る申請人に関する情報を含む、請求項１１記載のシステム。 １７．金融機関によって申し出される商品又はサービスの申請を処理する装置で あって、 ａ）複数の第１のデータリンクを含む処理システムを含み、前記処理シス テムは、複数の第１のデータリンクのうちの一つを介して金融機関の外部の複数 のオンライン信用調査所にアクセスし、第１の複数のデータリンクのうちの一つ を介して金融機関の外部のバンクカード処理システムにアクセスし、前記複数の 第１のデータリンクのうちの一つを介して、既存のバンクカードに関する情報を 格納する、金融機関の外部のバンクカードデータアクセスシステムにアクセスし 、処理中の信用貸し申請、完了し照会した信用貸し申請、ペンディング中の信用 貸しの申し出を格納し、 ｂ）フロントエンド処理通信システムを含み、該フロントエンド処理通信 システムは、申請人に関するデータを入力するための端末を含み、前記複数の第 １のデータリンクのうちの一つを介して前記信用貸し処理システムとリンクし、 第１の専用データリンクを有し、 ｃ）オンラインデータアクセスシステムを含み、該オンラインデータアク セスシステムは、前記複数の第１のデータリンクのうちの一つを介して前記処理 システムにリンクし、前記第１の専用データリンクを介して前記フロントエンド 処理通信システムにリンクし、金融機関の全ての申請人に関する情報、口座情報 、申請人人口情報及び金融取引に関する情報を格納する複数のデータベースを含 み、 ｄ）決定申請処理システムを含み、該決定申請処理システムは、前記複数 の第１のデータリンクのうちの一つを介して前記処理システムにリンクし、バン クカード処理システムにアクセスするための第２の専用データリンクを含み、装 置による申請の拒絶の際に信用貸し申請をマニュアル審査に送る、 申請処理装置。 １８．前記処理システムは、所定の信用貸しポリシーにしたがって申請を評価し 、所定のスコアリングによって申請をランク付けし、信用評価状態を、地方支店 代理に端末で表示するためにフロントエンド処理通信システムに即座に伝達する 、請求項１７記載の装置。 １９．前記処理システムは、地方支店代理に端末で表示するためのフロントエン ド処理システムに、特定の商品の要求に応じた申請に対する信用貸しの最大許容 可能な額を送出し、ここで申請人の全ての公知の債務と特定の商品に対する見積 もり支払い額は、指定された抑制資金負担までの格納された商品指定パラメータ を越えない、請求項１７記載の装置。 ２０．前記処理システムは、地方支店代理に端末で表示するためのフロントエン ド処理システムに、申し出され承認された額に応じて要求される照会カテゴリー の体系的な識別手段を送出し、地方支店代理が要求された照会を完了する方法を 選択することができ、全ての要求された照会が完了する前に申請の予約をするこ とを防ぐことができる、請求項１７記載の装置。 ２１．前記要求された照会は、身分証明書、電話番号、職業及び所得から成る群 から選択された少なくとも一つを含む請求項２０記載の装置。 ２２．前記要求された照会は、信用貸しの申請人の返済能力、地位及び担保及び 信用に関する信用貸し申請人に関する情報を含む、請求項２０記載の装置。 ２３．前記処理システムは、既存の及び新規に成立した口座を含む申請人の口座 の全てを自動的に審査し、申請を審査して申請人に要求された商品を提供する最 高価格を生じさせる総残高額を決定する場合、及び前記審査中、複数の価格ポイ ントを含む一連の表にアクセスして前記決定を実行し、前記フロントエンド処理 通信システムに、前記端末で地方支店代理に表示するための前記最高価格を送出 する、請求項１９記載の装置。 ２４．前記処理システムは、未完了な申請を、後日に申請の完了を可能とするフ ォーマットで維持し、前記未完了な申請を、前記フロントエンド処理通信システ ムからの要求に応じて、前記フロントエンド処理通信システ ムに送出する、請求項１９記載の装置。 ２５．前記処理システムは、未完了な申請の自動的経時に応じて未完了な申請の 追跡を促進するためのプロンプトを、端末で地方支店代理に表示するためのフロ ントエンド処理通信システムに送出する、請求項２４記載の装置。