JP5952518B1 - コーポレートファイナンスの海外与信管理のための銀行システム、方法およびプログラム - Google Patents

Abstract

コーポレートファイナンスの海外与信管理のための銀行システムは、複数のエンティティによって共有可能な顧客情報を格納する第１の格納手段と、与信取引の管理単位（Ｄｅａｌ）についての情報を格納する第２の格納手段と、稟議書に記載された与信取引の実行を承認する承認手段であって、稟議書の作成時の顧客情報およびＤｅａｌ情報を有し、稟議書の承認時に第１のシグナルを生成する、承認手段と、第１のシグナルに応答してコントロールカードを生成するコントロールカード生成手段であって、コントロールカードは、承認された与信取引の関連業務の進捗状況を示す、コントロールカード生成手段を備える。Ｄｅａｌ情報は１または複数の与信店の情報および１または複数の債務者の情報を有する。債務者は顧客情報に関連付けられている。顧客情報および与信取引の管理単位についての情報は第１のエンティティによってメンテナンスされる。

Description

本発明は、コーポレートファイナンスの海外与信管理のための銀行システム、方法およびプログラムに関する。より詳細に言えば、本発明は、複数のエンティティによって共有可能な顧客情報を有し、１または複数の与信店および１または複数の債務者を扱うことができる与信取引の管理単位についての情報を有し、かつ与信取引の関連業務の進捗状況を識別することができる、コーポレートファイナンスの海外与信管理のための銀行システム、方法およびプログラムに関する。

近年、海外におけるビジネス規模が拡大するのに従って、銀行における海外与信残高、債務者数並びに債務者の所在国および地域の数は増加している。多くの企業は、ビジネス機会を拡大させるために複数の国および地域に子会社乃至支店を設置し、かつ／または工場を建設している。このような状況の下、国際的に活動する大手銀行は、そのような企業と取引をする際に、その銀行の海外支店またはその銀行に関連する現地法人を通してその企業に融資することが多い。例えば、ある企業は、欧州のＡ国に工場を建設するための資金の融資をその銀行のＡ国の支店に依頼するかもしれない。別の企業は、東南アジアのＢ国に本社を有しているため、Ｂ国にあるその銀行の支店に融資の依頼をし、東南アジアのＣ国に工場を建設するための資金をその銀行のＣ国の支店から受け取るかもしれない。これらのケースでは、通常、融資の申込が行われた国にある支店または現地法人のみで与信関連業務を完結せず、複数の国にある支店、本部が情報を共有し、与信関連業務を行う。銀行の本部は、一般的にその銀行の本国にあるが、他の国および地域に本部が設立されることも可能である。一例として、大手銀行のいくつかは、世界を複数の地域に分け、それぞれの地域に本部を設立して（例えば、欧州本部、アジア大洋州本部、米州本部、および同様のもの）、その地域内の国々にある支店や現地法人を管理している。

すでに述べたように、コーポレートファイナンスに関連する与信業務は、複数の国および地域にある支店、現地法人、および本部が関わるケースが増えてきている。一方、銀行は、コーポレートファイナンス以外にストラクチャードファイナンスを扱うことも多い。ストラクチャードファイナンスは、企業の信用力ではなく、ある特定の事業の保有資産およびその事業から生み出されるキャッシュフローに基づくファイナンスであり、例えば、利害関係者によって設立された特別目的会社（ＳＰＣ：special purpose company）に対して融資を行うことを含むことができる。ＳＰＣは、あるプロジェクト（例えば、油田開発など）に関与する複数の企業によって出資・設立されるペーパーカンパニーであり、ＳＰＣは当該融資の債務者となる。プロジェクトに関与する複数の企業は、利害関係者としてそのプロジェクトに関与するが、債務者ではない。国際的に活動する銀行において、そのようなストラクチャードファイナンスの件数が増えつつある。

銀行は、何年にもわたって各種の銀行システムを開発してきた。顧客である企業の活動地域が国内のみの場合、銀行は、顧客情報管理のためのシステム、融資判断を行うための決裁システム、および与信管理のためのシステムを既に作成しており、それらのシステムは、国内用の銀行システムとして運用されていた。すでに述べたように、企業の活動がグローバルに拡大するにつれて、銀行システムは、グローバルに活動する企業のニーズを満たすことを求められるようになってきている。ビジネスをグローバルに展開する企業に対するコーポレートファイナンスの件数およびストラクチャードファイナンスの件数が増え、かつ海外の本部、支店および現地法人の数が増える状況下で、銀行は、コーポレートファイナンスおよび／またはストラクチャードファイナンスを扱うことが可能であり、銀行内の複数のオフィスが関与することが可能な新たなシステムを構築する必要があった。

特許文献１は、単に複数の国の間で資金決裁を行うシステムを開示し、特許文献２は、ストラクチャードファイナンスの申込のためのシステムを開示している。このように、従来の銀行システムは、海外業務の特定の業務にフォーカスをあてたシステムが知られているにすぎず、海外与信における顧客情報管理、案件管理、および融資判断などを行うためのシステムは存在していなかった。

従来の銀行システムでは、ある会社の業績が急激に悪化した際、その会社に関連付けられた融資案件を抽出することに、相応に時間を要した。世界的な金融危機（例えば、リーマンショック）が発生した際、またはあるプロジェクトが多大な損失を発生した際、従来の銀行システムでは、そのようなイベントに影響を受ける企業を抽出することに、相応に時間を要した。あるイベント（例えば、原油価格の下落）が発生した場合、従来の銀行システムでは、そのイベントによって企業業績が悪化する企業を抽出することが困難であった。

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

本発明の目的は、銀行内の複数のオフィスが関与することが可能な、コーポレートファイナンスの海外与信管理のための銀行システムであって、与信関連業務の進捗状況を提供することができ、かつ特定の顧客に関連付けられた融資案件を抽出することができる銀行システムを提供することである。

本発明の一態様としてのコーポレートファイナンスの海外与信管理のための銀行システムは、顧客情報を格納する第１の格納手段であって、前記顧客情報は、複数のエンティティによって共有可能である、第１の格納手段と、与信取引の管理単位についての情報を格納する第２の格納手段であって、前記与信取引の管理単位についての情報は、１または複数の与信店の情報および１または複数の債務者の情報を有し、前記債務者は、前記顧客情報に関連付けられている、第２の格納手段と、稟議書に記載された与信取引の実行を承認する承認手段であって、前記承認手段は、前記稟議書の作成時の前記顧客情報および前記与信取引の管理単位についての情報を有し、前記稟議書の承認時に第１のシグナルを生成する、承認手段と、前記第１のシグナルに応答してコントロールカードを生成するコントロールカード生成手段であって、前記コントロールカードは、前記承認された与信取引の関連業務の進捗状況を示す、コントロールカード生成手段を備える。前記顧客情報および前記与信取引の管理単位についての情報は、第１のエンティティによってメンテナンスされる。

本発明の他の態様としてのコーポレートファイナンスの海外与信管理のための銀行システムにおいて実行される方法は、顧客情報を更新することであって、前記顧客情報は、複数のエンティティによって共有可能である、ことと、与信取引の管理単位についての情報を更新することであって、前記与信取引の管理単位についての情報は、１または複数の与信店の情報および１または複数の債務者の情報を有し、前記債務者は、前記顧客情報に関連付けられている、ことと、稟議書の作成に応答して、前記顧客情報および前記与信取引の管理単位についての情報を取得することと、前記稟議書に記載された与信取引の承認に応答して、第１のシグナルを生成することと、前記第１のシグナルに応答してコントロールカードを生成することであって、前記コントロールカードは、前記承認された与信取引の関連業務の進捗状況を示す、ことを備える。前記顧客情報および前記与信取引の管理単位についての情報は、第１のエンティティによってメンテナンスされる。

本発明によれば、銀行システムは、業績の悪い会社の顧客ＩＤに基づいてＤｅａｌ情報またはＳＬ情報を検索することにより、その会社に関連付けられた融資案件を抽出することができる。本発明によれば、あるプロジェクトが多大な損失を発生した際、銀行システムは、ＳＬ情報に基づいて関係当事者を識別し、識別されたそれぞれの関係当事者の融資案件を抽出することができる。本発明によれば、銀行システムは、与信関連業務の進捗状況を提供することができる。

本明細書において開示される実施形態の詳細な理解は、添付図面に関連して例示される以下の説明から得ることができる。
図１は、銀行システムおよび複数の銀行端末、並びに銀行システムおよび複数の銀行端末を通信可能に接続するネットワークを示す図である。 図２は、銀行システムのシステム構成を説明する図である。 図３は、顧客情報管理サブシステムの機能ブロック図である。 図４は、案件情報管理サブシステムの機能ブロック図である。 図５は、ユーザ管理サブシステムの機能ブロック図である。 図６は、決裁サブシステムの機能ブロック図である。 図７は、与信管理サブシステムの機能ブロック図である。 図８Ａは、第１のケースにおける与信関連業務の流れを示す図である。 図８Ｂは、第１のケースにおけるオペレーションの流れを詳細に説明するフロー図である。 図９Ａは、第２のケースにおける与信関連業務の流れを示す図である。 図９Ｂは、第２のケースにおけるオペレーションの流れを詳細に説明するフロー図である。 図１０Ａは、第３のケースにおける与信関連業務の流れを示す図である。 図１０Ｂは、第３のケースにおけるオペレーションの流れを詳細に説明するフロー図である。 図１１は、ストラクチャードファイナンスの一例を示す。 図１２は、銀行システム内で行われるアクセス制御の処理フローの一例を説明する。 図１３は、稟議書の例示的なフォーマットを示す。 図１４は、例示的なリスクファクターの登録画面を示す。 図１５は、コントロールカードの一例を示す。

＜用語の定義＞
本明細書において使用される以下の用語の意味について定義される。

海外与信：銀行の海外支店またはその銀行に関連する現地法人がその銀行の顧客に対して行う融資。与信に相当する語としてファシリティ（facility）とエクスポージャー（Exposure）がある。前者は、個々の与信を指す際に使用され、後者は、顧客に対する与信全体を指す際に使用される。
海外与信管理：海外与信において融資先の企業の信用状況を管理すること。
与信店（Lending Office）：与信の責任を持つ支店または現地法人。複数の支店または現地法人が１つの顧客と取引するケースでは、主たる与信店（ＰＬＯ：Primary Lending Office）は、顧客情報を一元的に管理し、債務者評価を行うオフィスをいい、従たる与信店（ＳＬＯ：Secondary Lending Office）は、主たる与信店以外のオフィスをいう。
グローバル企業：多くの地域へ業務展開している企業で、複数与信店が管理する必要がある企業。
ＳＬ（Specialized Lending）：ストラクチャードファイナンス（ＳＦ）と略同義である。本明細書では、ＳＬとＳＦは交換可能に使用されることができる。

本明細書では、銀行１において行われる与信管理スキームおよびそのスキームを実行するためのシステムが説明される。銀行１は、複数の国および地域に、支店および銀行１に関連付けられた現地法人を有することができる。銀行１は、世界を複数の地域に分け、それぞれの地域に本部を設立して（例えば、欧州本部、アジア大洋州本部、米州本部、および同様のもの）、その地域内の国々にある支店や現地法人を管理することができる。本部、支店および現地法人は、「エンティティ」と呼ばれることができる。

図１は、銀行１によって使用されうる銀行システム１０および複数の銀行端末２０、並びに銀行システム１０および複数の銀行端末２０ａ、２０ｂ、・・・２０ｎ（本明細書では、まとめて「銀行端末２０」と呼ぶ）を通信可能に接続する行内ネットワーク若しくはインターネット３０（本明細書では、「ネットワーク３０」と呼ぶ）を示す図である。銀行システム１０は、預金業務、貸付業務、内国為替業務、外国為替業務および同類のものを扱うことができるシステムである。説明の目的のため、本明細書では、銀行システム１０の主要な機能のうち、１または複数の国および地域で事業を展開する企業に対する与信管理に関連する機能および処理が説明される。

銀行端末２０は、ネットワーク３０を経由して銀行システム１０にアクセスし、銀行システム１０によって提供される機能を利用することができる端末である。銀行端末２０は、銀行員が利用可能な端末であってよく、特に限定されない。例えば、銀行端末２０は、パーソナルコンピュータ（ＰＣ）、ラップトップ、タブレット端末、あるいは有線または無線環境において動作可能な他の任意のタイプのデバイスを含むことができる。ネットワーク３０は、インターネット、専用線などを含む、相互通信可能な周知のネットワークであってよく、特に限定されない。

図２は、銀行システム１０のシステム構成を説明する図である。銀行システム１０は、プロセッサ２１、主記憶装置２２、補助記憶装置２３、インターフェース装置２４および出力装置２５を備えることができる。装置２１乃至２５は、バス２６などによって相互に接続されることが可能である。

プロセッサ２１は、銀行システム１０内の各コンポーネントの制御およびデータの演算を行い、補助記憶装置２３に格納されている各種プログラムを主記憶装置２２に読み出して実行することができる。主記憶装置２２は、各種の送受信データ、コンピュータ実行可能命令および当該命令による演算処理後のデータを記憶することができる。補助記憶装置２３は、ＨＤＤ（Hard Disk Drive）またはＳＳＤ（Solid State Drive）などの記憶装置であり、データやプログラムを長期的に保存することができる。

図２は、プロセッサ２１、主記憶装置２２および補助記憶装置２３を同一のコンピュータ内に設ける実施形態を説明する。本発明の他の実施形態において、銀行システム１０は、複数のプロセッサ２１、主記憶装置２２および補助記憶装置２３を使用することによって、複数のコンピュータで並列分散処理を実現するように構成されることも可能である。本発明の他の実施形態において、銀行システム１０のために複数のコンピュータが設置され、複数のコンピュータが一つの補助記憶装置２３を共有する実施形態を採用することも可能である。

インターフェース装置２４は、他のシステムや装置との間でデータを送受信する際のインターフェースの役割を果たす。インターフェース装置２４は、システムオペレータから各種コマンドや入力データ（例えば、様々なマスタファイルのデータ）を受信するためのインターフェースを提供することができる。出力装置２５は、プロセッサ２１によって処理されたデータおよび／または様々なデータベース、ファイルから読み出されたデータを表示することができる。出力装置２５は、ディスプレイに表示されたデータを印刷するための機能を提供することができる。

図１に示されるように、銀行システム１０は、顧客情報管理サブシステム１１、案件情報管理サブシステム１２、ユーザ管理サブシステム１３、決裁サブシステム１４、および与信管理サブシステム１５を備えることができる。

サブシステム１１乃至１５は、バスなどによって相互に接続されうるプロセッサ、主記憶装置、補助記憶装置、インターフェース装置および出力装置を備えることができ、これらの装置は、装置２１乃至２５と同様の機能を有することができる。

顧客情報管理サブシステム１１は、与信管理プロセスにおいて使用される顧客情報を管理するために使用される。本発明で使用される顧客情報は、与信店ごとではなく、銀行内の複数の部門および与信店によって利用可能であり、従来のＣＩＦ（customer information file）における顧客情報とは異なる。ＣＩＦにおける顧客情報は、それぞれの与信店によって作成され、メンテナンスされていた。ある特定の企業が銀行内の複数の与信店と取引がある場合には、それぞれの与信店が顧客情報を作成し、メンテナンスしていたため、銀行１内で一元化された情報管理が行われていなかった。本明細書では、従来のＣＩＦと区別するために顧客情報を「コーポレートカード（corporate card）」と呼ぶこととする。

案件情報管理サブシステム１２は、融資に関する案件情報（Ｄｅａｌ）を管理するために使用される。案件情報管理サブシステム１２は、コーポレートファイナンスおよびストラクチャードファイナンスの両方のＤｅａｌを扱うことができる。Ｄｅａｌは、顧客である企業の資金需要の背景および理由、並びに資金の用途および融資期間などの事実情報を含むことができる。

ユーザ管理サブシステム１３は、ログインユーザによってアクセス可能なシステム機能およびデータを制御するアクセス制御機能、並びにユーザログをモニタする検査機能を提供することができる。アクセス制御機能は、特定のユーザのみが特定のシステム機能やデータにアクセスすることを可能にする。検査機能は、銀行システム１０内で行われたユーザ操作のうち特定の操作のログを収集し、かつ格納することができる。ログを収集すべき特定の操作は、予め定められることが可能である。

決裁サブシステム１４は、海外与信についての稟議書を作成し、関係部門に回付し、かつ決裁権限者から承認を得るためのシステムである。決裁サブシステム１４は、稟議書の内容を審査する時点のコーポレートカードおよびＤｅａｌを保持しておくことができる。保持されるコーポレートカードおよびＤｅａｌは、稟議書の作成開始時点および／または決裁時点とすることができる。決裁サブシステム１４は、あるエンティティから別のエンティティに稟議書が回付される時に、稟議書のコピーを生成し、格納することができる。

与信管理サブシステム１５は、与信業務管理をサポートすることができ、かつ関係部門および与信店間の連携と内部管理を強化することができる。与信管理サブシステム１５は、融資実行前の業務、および融資実行後の業務が適切に実行されているかどうかをチェックする機能を提供することができる。

図３は、顧客情報管理サブシステム１１の機能ブロック図である。顧客情報管理サブシステム１１は、顧客情報３１、財務情報３２、財務分析３３、与信モニタリング３４、取引銀行３５、および競合比較３６を備えることができる。エレメント３１乃至３６は、銀行システム１０内で共有されるデータであり、まとめて「コーポレートカード」と呼ばれることもできる。コーポレートカードは、複数の部門および与信店によって共有されることができるので、従来のＣＩＦとは異なる顧客情報である。

顧客情報３１は、顧客のプロファイルであり、例えば、顧客ＩＤ、会社の名前、本社の場所、設立年、従業員数、工場および／または支店の場所（国および都市名）、株式情報、株主、グループ構造、経営史、銀行１との関係、キーパーソン、事業区分、地域別セグメント、主要顧客、主要サプライヤーなどの属性情報を含むことができる。

財務情報３２は、顧客の損益計算書、貸借対照表、キャッシュフロー計算書、およびそれらの財務情報の元データを含むことができる。財務情報３２は、複数の暦年のデータを含むことができる。財務情報３２は、実績および予測データを含むことができる。

財務分析３３は、財務情報３２に格納されている情報に基づく分析結果を含むことができる。財務分析は、銀行１の担当者によって行われ、その分析結果は、与信判断に利用されることができる。

与信モニタリング３４は、債務者の信用格付、債務者のステータス（優良、注意、など）、債務者のグレード（上位、中位、下位、など）などのモニタリング情報を含むことができる。モニタリング情報の内容は、銀行１によって定められた基準に基づいて決定されることができ、かつ／または格付け会社から取得された情報とすることができる。

取引銀行３５は、債務者が資金を借りている全ての金融機関、および各金融機関からの借入金額などの情報を含むことができる。競合比較３６は、債務者の競合会社の情報（例えば、財務情報）を格納することができる。競合会社の選択は、同じ事業分野の他の債務者の情報に基づいて、あるいは銀行１の担当者によって決定される。

エレメント３１乃至３６に格納されている情報に対するアクセス制御は、ユーザ管理サブシステム１３によって行われる。このアクセス制御は、参照される情報が特定された後、アクセスユーザの所属組織、与信職位および役割の情報、顧客データを管理しているエンティティのある国および地域のコンプライアンス情報、および他のエンティティが顧客データを参照することに対して顧客が同意したかどうかの情報にしたがって行われる。顧客情報管理サブシステム１１は、顧客が、エレメント３１乃至３６に格納されている情報が共有されることを同意しているか否かの情報を有することができる。エンティティは、銀行１の本部の各部門、支店、銀行１に関連付けられた現地法人を示すことができる。

図４は、案件情報管理サブシステム１２の機能ブロック図である。案件情報管理サブシステム１２は、与信取引の管理単位（Ｄｅａｌ）のための情報を扱うことができる。案件情報管理サブシステム１２は、Ｄｅａｌ Ｐｒｏｆｉｌｅ４１、与信明細情報４２、担保明細情報４３およびＳＬ情報４４を備えることができる。エレメント４１乃至４４は、まとめて「Ｄｅａｌ情報」と呼ばれることもできる。案件情報管理サブシステム１２は、従来の銀行システムと異なり、複数の与信店が関与する取引、および／または複数の債務者が関与する取引を扱うことが可能である。

Ｄｅａｌ Ｐｒｏｆｉｌｅ４１は、案件情報のプロファイルを格納することができる。Ｄｅａｌ Ｐｒｏｆｉｌｅ４１に格納されている情報は、案件情報の識別子（Ｄｅａｌ番号）を用いて与信明細情報４２および担保明細情報４３に格納される情報に関連付けられることができる。

Ｄｅａｌ Ｐｒｏｆｉｌｅ４１は、基本情報４１１（Ｄｅａｌ番号、Ｄｅａｌ名、Ｄｅａｌオーナー、１または複数の与信店、１または複数の債務者）、Ｄｅａｌサマリー４１２、Ｄｅａｌバックグラウンド４１３、貸出ストラクチャ４１４、支援分担４１５（図示せず）を含むことができる。

基本情報４１１は、Ｄｅａｌを識別するためのＤｅａｌ番号、Ｄｅａｌを示す名前、１または複数の与信店、および１または複数の債務者の顧客ＩＤを含むことができる。Ｄｅａｌサマリー４１２は、取引の概要を含むことができる。例えば、Ｄｅａｌサマリー４１２は、「融資の目的は、インドに本社を置く事業会社向けの運転資金である。貸出期間は１年、融資額は１千万ドルである。ニューデリー（ＮＤＬ）およびシンガポール（ＳＮＧ）の与信店がそれぞれ５００万ドルずつ融資を行う」という情報を含むことができる。

Ｄｅａｌバックグラウンド４１３は、この融資を行う背景事情および理由を含むことができる。貸出ストラクチャ４１４は、融資のスキームを説明する図、およびその説明文を含むことができる。支援分担４１５は、複数の金融機関が融資を行うケースの場合に、それぞれの金融機関の支援割合（例えば、Ａ銀行４０％、Ｂ銀行３５％、Ｃ銀行２５％）を示すことができる。

与信明細情報４２は、明細番号、債務者、与信の種類、通貨、貸出金額などの融資の詳細情報を含むことができる。担保明細情報４３は、このＤｅａｌの担保の詳細情報を含むことができる。複数の与信店がＤｅａｌに関与する場合、与信明細情報４２は、それぞれの与信店で設定された極度を合わせた合算極度を示すことができる。与信明細情報４２および担保明細情報４３は、複数の債務者の情報を含むことができる。

ＳＬ情報４４は、融資の種類がストラクチャードファイナンス（例えば、あるプロジェクトのための特別目的会社（ＳＰＣ）に対する融資）の場合に、ＳＬ（Specialized Lending）に特有の情報を格納する。ストラクチャードファイナンスの一例は、図１１に示される。図１１では、火力発電所建設のためのプロジェクトを実行するＳＰＣがプロジェクトの関係当事者によって設立される。銀行団は、このＳＰＣに対して融資を行う。スポンサーであるＢ社およびＣ社は、技術支援および販売支援を行う。電力の販売先であるＤ社は、売電契約を締結し、火力発電所から電気を購入する。燃料供給者であるＥ社は、火力発電所に燃料を供給する。発電所の建設者であるＦ社は、火力発電所を建設する。図１１に示したように、ストラクチャードファイナンスは、ある特定の事業の保有資産およびその事業から生み出されるキャッシュフローに基づくファイナンスであり、複数の利害関係者が関与することができる。

ＳＬ情報４４は、ＳＬ番号４２１、アセットプロファイル４２２（プロジェクトサマリ、ストラクチャ、マイルストーンなど）、契約書番号４２３、財務情報４２４、１または複数の関係当事者４２５（図示せず）を含むことができる。

ＳＬ番号４２１は、ストラクチャードファイナンスを識別する番号である。アセットプロファイル４２２は、プロジェクトのサマリー、スキーム（ストラクチャ）、並びにスケジュールおよびマイルストーンなどの情報を含むことができる。契約書番号４２３は、ストラクチャードファイナンスに関連付けられた契約書の識別情報を示す。財務情報４２４は、プロジェクトの財務情報（損益計算書、貸借対照表、キャッシュフロー計算書など）を示す。

関係当事者４２５は、プロジェクトの１または複数のステークホルダーを含むことができ、ステークホルダーは、顧客情報３１の顧客ＩＤによって示される。関係当事者４２５は、ステークホルダーのプロジェクトにおける役割を含むことができる。例えば、役割は、借り手、保証人、スポンサー、原資産所有者、買い手、売り手、および同様のものを含むことができる。複数の当事者が関与することが可能なストラクチャードファイナンスにおいては、例えば、ＳＰＣを管轄する与信店がＳＬ情報４４をメンテナンスすることができる。関係当事者４２５を利用することにより、プロジェクトに関与する１または複数の関係当事者が識別されることができる。このため、プロジェクトに損害が発生する場合に、影響を受ける顧客を特定することが可能となる。

図５は、ユーザ管理サブシステム１３の機能ブロック図である。ユーザ管理サブシステム１３は、データベースまたはファイルとして、ユーザ情報５１、インサイダー情報に基づくアクセス制御５２、データおよびアプリケーションに対するアクセス制御５３、部店間の関係性５４、情報カテゴリに基づくアクセス制御５５およびログデータ５６を備えることができる。ユーザ管理サブシステム１３は、処理コンポーネントとしてユーザ情報生成部５７およびログデータ収集部５８を備えることができる。

ユーザ情報５１は、銀行システム１０内で利用可能なユーザ情報およびアクセス制御情報を備えることができる。ユーザ情報５１は、ユーザＩＤ５２１、所属組織５２２、与信職位５２３、役割５２４、およびシステム操作権限５２５（図示せず）を含むことができる。

ユーザＩＤ５２１は、銀行システム１０およびサブシステム１１乃至１５を使用するユーザを識別するためのＩＤである。所属組織５２２は、ユーザの部門（例えば、本部の審査部、シンガポール支店の営業部、など）を示す。与信職位５２３は、与信判断のための職位であり、グループマネージャ、支店の長などの職位を示す。これらの職位は、正式な人事情報に基づいて決定される。役割５２４は、与信関連業務において果たす役割（例えば、フロント、フロントミドル、ミドルバック、バック、審査部など）を示す。

システム操作権限５２５は、ユーザの不要な操作を防止するために、ユーザの部門および与信職位などの情報に基づいて操作可能な業務アプリケーションを定義することができる。例えば、東南アジアのある国において行われる融資の稟議書が誤ってロンドンの審査部に回付されるケースでは、ロンドンの審査部に所属する人は、そのような稟議書を参照する必要はないので、予め定められた地域以外の稟議書データにはアクセスすることができない。

インサイダー情報に基づくアクセス制御５２は、合併と買収（Ｍ＆Ａ）を計画している企業のコーポレートカード（エレメント３１乃至３６）などの秘密情報に対して指定ユーザのみのアクセスを許可するための設定情報を格納することができる。

データおよびアプリケーションに対するアクセス制御５３は、複数の債務者が存在するなどの複雑な取引について、顧客情報管理サブシステム１１内の情報３１乃至３６、Ｄｅａｌ Ｐｒｏｆｉｌｅ４１、ＳＬ情報４４などの情報ごとにユーザのアクセス可否情報を含むことができる。

部店間の関係性５４は、他の部門、与信店および現地法人の顧客情報を共有する必要がある部門、与信店および現地法人の情報を含むことができる。例えば、米州統括部は、自らが管理しているエンティティ（例えば、米国内の支店）に関連付けられた顧客情報を参照する必要がある。このため、部店間の関係性５４は、参照するエンティティおよび参照されるエンティティの情報を含むことができる。

情報カテゴリに基づくアクセス制御５５は、情報の種類に従って公開可能な範囲が異なってくるので、情報の種類に応じた公開範囲を示すことができる。例えば、情報開示に対する顧客の同意／不同意、情報を管理するエンティティの所在国などによって情報の公開範囲が異なるため、情報カテゴリに基づくアクセス制御５５は、顧客の同意、エンティティの所在国についての情報を含むことができる。

ユーザ情報生成部５７は、銀行システム１０内で利用される人事情報システムから各ユーザの人事情報（所属組織、職位、役割など）を抽出し、抽出された人事情報と、不図示の職位テーブルおよび変更情報テーブルに格納されている情報をマッチングし、ユーザ情報５１を生成することができる。職位テーブルは、各部店の役職ごとにシステムへのアクセス権限を定義し、変更情報テーブルは、人事の職位から設定されるデフォルト権限を変更したアクセス権限情報を定義する。

ログデータ収集部５８は、銀行システム１０内で行われたユーザ操作のうち特定の操作のログを収集することができる。ログを収集すべき特定の操作は、予め定められることが可能である。例えば、顧客情報管理サブシステム１１内の顧客情報３１に更新データが格納されると、その操作に関するログデータ、例えば、ユーザのＩＤ、操作日時、操作端末、操作の種類（追加、修正、削除など）、操作前データおよび操作後データが顧客情報管理サブシステム１１によってユーザ管理サブシステム１３に送信される。ログデータ収集部５８は、送信されたログデータをログデータ５６に格納することができる。

図１２を参照しながら、銀行システム１０内で行われるアクセス制御の処理フローの一例が説明される。

１２０１において、ユーザ管理サブシステム１３は、ログインユーザのユーザＩＤ５２１に基づいて所属組織５２２、与信職位５２３、役割５２４、およびシステム操作権限５２５を取得する。

１２０２において、ユーザが銀行端末２０を使用して、ある特定の情報へのアクセスを試みる。

１２０３において、ユーザ管理サブシステム１３は、参照された情報を管理する与信店がある国または地域の法規制を確認する。例えば、参照された情報を管理する与信店がシンガポールにある場合、ユーザ管理サブシステム１３は、サブシステム１３内に保持されている各国の法規制のうちのシンガポールの法規制を読み取る。法規制は、例えば、以下の３つのパターンでありうる。

情報共有についての顧客同意が得られていれば、パターン１乃至３の全ての国では、国／法人を超えて情報共有することが可能である。情報共有についての顧客同意が得られていない場合、パターン１の国では、その国およびその法人内でのみ情報共有することが可能であり、パターン２の国では、その法人内でのみ情報共有することが可能である。情報共有についての顧客同意が得られていないとしても、パターン３の国では、国／法人を超えて情報共有することが可能である。

１２０４において、ユーザ管理サブシステム１３は、顧客情報管理サブシステム１１に問い合わせを行い、参照された情報が共有されることを顧客が同意しているかどうかを判定する。顧客の同意がある場合、ステップ１２０６に処理が進む。顧客の同意がない場合、ステップ１２０５に処理が進む。

１２０５において、ユーザ管理サブシステム１３は、参照された情報を管理する与信店がある国の法規制のパターンを判定する。判定されたパターンがパターン３の場合、ステップ１２０６に処理が進む。判定されたパターンがパターン１またはパターン２の場合、ステップ１２０８に処理が進む。

１２０６において、ユーザ管理サブシステム１３は、ユーザが情報にアクセスするために適切な職位および役割を有しているかどうかを判定する。適切な職位および役割を有している場合、ステップ１２０７に処理が進む。適切な職位および役割を有していない場合、ステップ１２０８に処理が進む。

１２０７において、ユーザはその情報へアクセスすることができ、情報を参照することができる。１２０８において、ユーザはその情報への限られたアクセスを有するか、あるいは情報へアクセスすることができない。

図１２では、ユーザ情報５１に格納されている情報に基づくアクセス制御を説明したが、本発明のアクセス制御は他の実施形態も可能である。他の実施形態では、ユーザ情報５１、インサイダー情報に基づくアクセス制御５２、データおよびアプリケーションに対するアクセス制御５３、部店間の関係性５４、および情報カテゴリに基づくアクセス制御５５の１つまたは複数の使用するアクセス制御が実装されることができる。

図６は、決裁サブシステム１４の機能ブロック図である。決裁サブシステム１４は、データベースまたはファイルとして、コーポレートカード６１、Ｄｅａｌ情報６２、稟議書６３、静態情報６４および契約書６５を備えることができる。決裁サブシステム１４は、処理コンポーネントとして情報取得部６６、静態情報生成部６７および送付部６８を備えることができる。

コーポレートカード６１は、稟議書を起案する時点での「コーポレートカード」の情報、すなわち、顧客情報３１、財務情報３２、財務分析３３、与信モニタリング３４、取引銀行３５、および競合比較３６の情報のコピーを格納することができる。

Ｄｅａｌ情報６２は、稟議書を起案する時点での「Ｄｅａｌ情報」、すなわち、Ｄｅａｌ Ｐｒｏｆｉｌｅ４１、与信明細情報４２、担保明細情報４３およびＳＬ情報４４の情報のコピーを格納することができる。Ｄｅａｌ情報６２は、ステータス情報を含むことが可能であり、ステータス情報は、稟議書が決裁される前は「Ｐｅｎｄｉｎｇ」を示し、決裁後は「Ｆｉｘｅｄ」を示す。

稟議書６３は、稟議書のデータを格納することができる。稟議書は、稟議書ＩＤ、図１３に示される内容、およびステータスを含むことができる。稟議書ＩＤは、稟議書の識別子を示し、ステータスは審査の状況（例えば、「決裁前」、「決裁済み」）を示す。稟議書は、コーポレートカード６１およびＤｅａｌ情報６２に関連付けられることができる。例えば、稟議書は、稟議書ＩＤと、稟議書ＩＤに関連付けられたコーポレートカード６１の識別子およびＤｅａｌ情報６２の識別子を有することができるため、稟議書は、コーポレートカード６１およびＤｅａｌ情報６２と関連付けられることができる。図１３は、稟議書の例示的なフォーマットを示す。このフォーマットは、案件の要約および結論、融資の期間および条件の要約、保証および担保、採算性、エクスポージャーおよび保全状況、Ｄｅａｌ Ｐｒｏｆｉｌｅ４１およびＳＬ情報４４、コーポレートカード６１、返済可能性、および主要なリスクファクターの一覧を含むことができる。

リスクファクターは、顧客の経営に影響を与え得るリスク要因（例えば、原油相場、中東情勢、提携企業、特定のプロジェクトなど）を示す。銀行システム１０は、コーポレートカードやＤｅａｌ情報に登録されている類型化されたリスクファクターを利用して影響を受けるＤｅａｌ、およびそのＤｅａｌに関連付けられる顧客を識別することができる。

図１３に示すように、リスクファクターは、稟議書における債務者評価・案件評価の主要部分に付加されることが可能である。このフォーマット内の「10. Key Risk Factor」は、付加されたリスクファクターを表示することができる。図１４は、例示的なリスクファクターの登録画面を示す。リスクファクターの登録画面は、リスクのタイプ（例えば、Ｃｏｍｍｏｄｉｔｙ）、リスクファクターとなりうる指標（例えば、ＷＴＩ）、債務者の財務状況およびリスク軽減策を考慮したリスク度合い（例えば、Ｈｉｇｈ−Ｍｉｄｄｌｅ−Ｌｏｗ）、リスクの内容およびリスクに対する軽減策についての情報を含むことができる。

静態情報６４は、稟議書があるエンティティの長によって承認された後、他のエンティティに送付される前に承認時の稟議書の静態情報を格納することができる。静態情報は、ＰＤＦデータなどであってよい。契約書６５は、稟議書の決裁後に作成され、署名された契約書のデータを格納することができる。

情報取得部６６は、稟議書を起案する時点での「コーポレートカード」および「Ｄｅａｌ情報」を顧客情報管理サブシステム１１および案件情報管理サブシステム１２から取得することができる。

静態情報生成部６７は、稟議書がある部門の長によって承認された後、他の部門に送付される前に承認時の稟議書の静態情報を生成することができる。より詳細に言えば、稟議書を承認するために承認ボタンが押下された時、稟議書の静態情報が生成される。生成された静態情報は、静態情報６７に格納される。

送付部６８は、稟議書の起案者によって選択された確認者および決裁権者に対して確認すべき稟議書があることを通知することができる。通知を受けた確認者および決裁権者は、稟議書６３に格納されている稟議書の内容を参照し、任意選択でコメントを入力し、かつ承認または否認を登録する。起案者は、確認者および決裁権者の代わりに、あるいは確認者および決裁権者に加えて、エンティティの名前を選択することができる。部門の名前が選択された場合、稟議書を受信した部門が、稟議書の確認者および承認者を選択することができる。

本発明の一実施形態では、決裁サブシステム１４は、稟議書が決裁された時点のコーポレートカードの情報および／またはＤｅａｌ情報を取得することも可能である。コーポレートカードの情報および／またはＤｅａｌ情報は、時間と共にアップデートされうるため、決裁サブシステム１４は、稟議書の起案時から決裁時までの変更情報を追加として取得し、保持することができる。

決裁サブシステム１４は、稟議書が起案された後（例えば、保存ボタンが押下された後）、与信管理サブシステム１５に稟議書の作成を示すシグナルを送信することができる。このシグナルは、コントロールカードを生成するトリガである。

図７は、与信管理サブシステム１５の機能ブロック図である。与信管理サブシステム１５は、データベースまたはファイルとして、コーポレートカード７１、Ｄｅａｌ情報７２、稟議書７３、契約情報７４、およびコントロールカード７５を備えることができる。与信管理サブシステム１５は、処理コンポーネントとして、情報取得部７６およびコントロールカード（Ｃ／Ｃ）生成部７７を備えることができる。

与信管理サブシステム１５は、実行される必要がある与信業務の進捗状況を示すことができる。実行される必要がある与信業務の内容および与信業務を行う担当部門（役割）は、Ｄｅａｌ情報および稟議書のルート情報に基づいて決定されることができる。与信業務を行う担当部門は、割り当てられた役割に従って与信業務を行い、その結果を与信管理サブシステム１５に入力することができる。

コーポレートカード７１およびＤｅａｌ情報７２は、コーポレートカード６１およびＤｅａｌ情報６２に含まれる情報の一部のみを含む。契約情報７４は、契約書６５に含まれる情報と同じ情報を含むことができる。稟議書７３は、稟議書６３の内容と同じ内容を含むことができる。

情報取得部６６は、稟議書の作成を示すシグナルを受信したことに応答してコーポレートカード６１およびＤｅａｌ情報６２から予め定められた情報を抽出し、抽出された情報をコーポレートカード７１およびＤｅａｌ情報７２のそれぞれに格納することができる。情報抽出の基準は、与信業務に必要な情報であるかどうかである。例えば、与信業務のチェックに必要ない、融資の背景、企業業績などの情報は、コーポレートカード７１およびＤｅａｌ情報７２に格納されない。

コントロールカード生成部７７は、決裁サブシステム１４から稟議書の作成を示すシグナル、および稟議書の承認を示すシグナルを受信したことに応答してコントロールカードを生成することができる。コントロールカード生成部７７は、稟議書の作成を示すシグナルに基づいて稟議書の決裁前に行われる与信業務を含むコントロールカードを生成することができる。コントロールカード生成部７７は、稟議書の承認を示すシグナルに基づいて稟議書の決裁後に行われる与信業務を含むコントロールカードを生成することができる。生成されたコントロールカードのそれぞれは、結合されて１つのコントロールカードとして使用されることが可能である。他の実施形態では、コントロールカード生成部７７は、稟議書の作成を示すシグナルに応答して１つのコントロールカードを生成することができ、かつ稟議書の承認状況に応じて１つのコントロールカード内の確認項目を増やすことができる。

コントロールカードは、実行される必要がある与信業務の内容および与信業務を行う担当部門（役割）を含むことができる。実行される必要がある与信業務の内容および与信業務を行う担当部門（役割）は、Ｄｅａｌ情報および稟議書のルート情報に基づいて決定されることができる。例えば、米国で行われるプロジェクトに対する融資と、インドに本社を有する事業会社に対する融資とでは、実行される必要がある与信業務および担当部門、支店は異なるので、異なるコントロールカードが使用される。コントロールカードは、本明細書において「Ｃ／Ｃ」と呼ばれることができる。

図１５は、コントロールカード１５００の一例を示す。コントロールカード１５００は、コントロールカード番号１５０１、担当エンティティおよび役割１５０２、ドキュメントリスト１５０３、ステータス変更ボタン１５０４、および与信業務１５０５を含むことができる。コントロールカード１５００は、関連する稟議書ＩＤ、コーポレートカード７１の識別子およびＤｅａｌ情報７２の識別子をさらに有することができる。

コントロールカード番号１５０１は、コントロールカードを識別する番号である。担当エンティティおよび役割１５０２は、与信業務の責任を負うべきエンティティ（部門、支店など）および役割を示すことができる。担当エンティティおよび役割１５０２は、ユーザＩＤおよびユーザ名をさらに示すこともできる。

ドキュメントリスト１５０３は、ユーザによって選択されると、コントロールカードに関連付けられた契約書および関係書類のリストを表示する。リスト内から所望のデータが選択されると、与信管理サブシステム１５は選択されたデータを表示することができる。

ステータス変更ボタン１５０４は、実行される必要がある全ての与信業務が「Complete」を示す場合に、次のステータスに移行するために使用される。ステータスは、「契約前の準備から契約（Pre-Signing）」、「実行準備（Post-Signing）」および「実行準備完了（Available to Drawdown）」を含むことができる。

ステータスが「契約前の準備から契約（Pre-Signing）」である間、契約内容の点検（または署名前の点検）と、署名前に必要な徴求物（各種ドキュメント）および付随プロセスと、審査部条件の管理と、署名前の担保および保証の充足確認が行われうる。

ステータスが「実行準備（Post-Signing）」である間、事後徴求物（各種書類）の管理と、事後の担保および保証の充足管理とが行われうる。

ステータスが「実行準備完了（Available to Drawdown）」である間、勘定実行可能な状態での事後徴求物（各種書類）の管理と、審査部条件の管理と、勘定実行可能な状態での事後の担保および保証の充足管理とが行われうる。

図１５に示されるように、コントロールカード１５００は、貸付ごとの与信業務を含み、かつ与信業務のそれぞれが完了しているかどうかを示すことができる。具体的に言えば、コントロールカード１５００は、２つの貸付を含むことができる。図１５において、貸付番号「X111」は、融資の申込がシンガポールで行われたこと、「契約前の準備から契約（Pre-Signing）」段階にあること、および融資の名称が「３６４日間のつなぎ融資」であることを示す。コントロールカード１５００は、それぞれの貸付に関連する与信業務として、「Ａｐｐｌｉｃａｔｉｏｎ」、「Ｃｏｎｄｉｔｉｏｎ」、「Ｔｅｒｍｓ Ｃｈｅｃｋ」、「Ｇｕａｒａｎｔｅｅ／Ｃｏｌｌａｔｅｒａｌ」、「Ｄｏｃｕｍｅｎｔ」および「Ａｎｃｉｌｌａｒｙ Ｐｒｏｃｅｓｓ」を含むことができる。

与信業務「Ａｐｐｌｉｃａｔｉｏｎ」は、稟議書の形式点検、および／または稟議書の決裁が完了したかどうかを示す。与信業務「Ｃｏｎｄｉｔｉｏｎ」は、稟議書の決裁時に審査部が付与した条件に対し、対応が完了したかどうかを示す。「Ｔｅｒｍｓ Ｃｈｅｃｋ」は、契約書に記載されている契約内容の点検が完了したかどうかを示す。与信業務「Ｇｕａｒａｎｔｅｅ／Ｃｏｌｌａｔｅｒａｌ」は、保証および／または担保が充足されているかどうかを示す。与信業務「Ｄｏｃｕｍｅｎｔ」は、必要な徴求物（各種ドキュメント）が到着したかどうかを示す。与信業務「Ａｎｃｉｌｌａｒｙ Ｐｒｏｃｅｓｓ」は、署名前に必要な付随プロセスが完了したかどうかを示す。

上述したように、与信管理サブシステム１５は、それぞれの稟議書についてのコントロールカードを有することができ、コントロールカードは、実行される必要がある全ての与信業務の進捗状況を示すことができる。図１５に示されたコントロールカード１５００は一例にすぎず、コントロールカード１５００が本明細書で示した与信業務以外を含むこともできる。

以下、銀行システム１０およびサブシステム１１乃至１５を使用して行われる与信関連業務に関する複数のケースが説明される。これらのケースは、コーポレートファイナンスおよびストラクチャードファイナンスの例を説明する。これらのケースでは、ユーザ情報５１に格納されている役割５２４の一例として、「フロント」、「フロントミドル」、「ミドルバック」、「バック」および「審査部」が説明のために示される。上述したように、ユーザ情報５１は、ユーザＩＤ５２１、所属組織５２２、与信職位５２３、役割５２４、およびシステム操作権限５２５を含むことができる。

ユーザ情報５１の具体例は以下の通りである。例えば、ある人の所属組織および職位は、シンガポール支店の営業部門のアシスタントマネージャであり、その人の役割は、営業の事務の仕事に従事しているのでフロントミドルである。例えば、別の人の所属組織および職位は、シンガポール支店の融資事務部門のシニアスタッフであり、その人の役割は、融資事務に従事しているのでミドルバックである。本明細書で使用される役割および職位は、表２に示されるが、銀行１内の役割および職位がこれらに限定されることはない。

以下、コーポレートファイナンスのための第１および第２のケース、並びにストラクチャードファイナンスのための第３のケースが図８Ａ乃至図１０Ｂを参照して説明される。

（第１のケース）
図８Ａおよび図８Ｂを参照して、コーポレートファイナンスのための第１のケースが説明される。第１のケースは、銀行１のただ一つのエンティティ（例えば、シンガポール支店）内で与信関連業務が完結することを例証する。本明細書および図面において、シンガポールは、「ＳＮＧ」と略されてもよい。

図８Ａは、第１のケースにおける与信関連業務の流れを示す図である。
（１）シンガポールにある顧客ＡＢＣコーポレーションが、銀行１のシンガポール支店において融資を申し込む。
（２）シンガポール支店のフロントは、融資の申込を受けたことに応答して、コーポレートカードをメンテナンスし、Ｄｅａｌ情報を生成し、稟議書を作成する。シンガポール支店のフロントミドルは、稟議書の形式を点検し、必要書類および必要な手続きを確認する。シンガポール支店のフロントミドルは、点検および確認の後、コントロールカードをアップデートする。シンガポール支店のフロントミドルは、シンガポール支店のアジア審査部に稟議書の決裁を求める。アジア審査部は、稟議書をレビューし、貸出条件を決定し、融資を承認する。
（３）決裁後、シンガポール支店のフロントは、シンガポール支店のミドルバックに条件管理および事務手続を依頼する。シンガポール支店のミドルバックは、承認された稟議書および契約書をレビューする。レビュー後、シンガポール支店のミドルバックは、コントロールカードをアップデートする。
（４）シンガポール支店のミドルバックは、レビュー後、シンガポール支店内のＡＢＣコーポレーションの口座に与信限度額を設定する。与信限度額は、顧客に対して設定する与信（すなわち、融資）の限度額を意味する。その後、シンガポール支店のバックは、ＡＢＣコーポレーションの口座に入金する。

表３は、上述した役割ごとの与信業務の例を示すが、与信業務がこれらの業務に限定されることはない。

図８Ｂは、第１のケースにおけるオペレーションの流れを詳細に説明するフロー図である。

Ｓ８０１にて、銀行１のシンガポール支店のフロントは、ＡＢＣコーポレーションから融資の申込を受けたことに応答して、銀行端末２０を介して顧客情報管理サブシステム１１に最新の顧客情報を入力することができる。顧客情報管理サブシステム１１は、顧客情報を入力するためのアプリケーションを提供することができる。入力された顧客情報は、情報の内容に従って、顧客情報３１、財務情報３２、財務分析３３、与信モニタリング３４、取引銀行３５および競合比較３６に格納されることが可能である。

シンガポール支店のフロントは、ＡＢＣコーポレーションが望む融資の概要を案件情報管理サブシステム１２に入力することができる。案件情報管理サブシステム１２は、融資の概要を入力するためのアプリケーションを提供することができる。入力された情報は、情報の内容に従って、Ｄｅａｌ Ｐｒｏｆｉｌｅ４１、与信明細情報４２および担保明細情報４３に格納されることが可能である。与信明細情報４２および担保明細情報４３に格納された情報は、この融資を行うことが承認されるまでは、ペンディング状態である。第１のケースは、コーポレートファイナンスを対象にするので、ＳＬ情報４４は使用されない。

Ｓ８０２にて、シンガポール支店のフロントは、銀行端末２０を介して決裁サブシステム１４にアクセスし、稟議書を作成する。シンガポール支店のフロントは、任意に、コーポレートカードおよびＤｅａｌ情報にリスクファクターを設定することができる。決裁サブシステム１４の情報取得部６６は、その稟議書に関連付けられる、顧客情報３１、財務情報３２、財務分析３３、与信モニタリング３４、取引銀行３５および競合比較３６に格納されている最新データを顧客情報管理サブシステム１１から取得することができる。取得されたデータは、決裁サブシステム１４内のコーポレートカード６１に格納される。決裁サブシステム１４の情報取得部６６は、その稟議書に関連付けられる、Ｄｅａｌ Ｐｒｏｆｉｌｅ４１、与信明細情報４２および担保明細情報４３に格納されている最新データを案件情報管理サブシステム１２から取得することができる。取得されたデータは、決裁サブシステム１４内のＤｅａｌ情報６２に格納される。これらの処理を通じて、決裁サブシステム１４は、稟議書の作成時点の顧客の情報および融資案件の情報を稟議書に関連付けることができる。

稟議書の作成が完了すると（例えば、保存ボタンが押下された後）、決裁サブシステム１４は、与信管理サブシステム１５に稟議書の作成を示すシグナルを送信することができる。このシグナルが与信管理サブシステム１５によって受信されると、稟議書の決裁前に行われる与信業務を含むコントロールカードが生成される。

シンガポール支店のフロントは、作成された稟議書を審査する部門および／または人のルート（順序）を決裁サブシステム１４上で選択する。決裁サブシステム１４は、選択されたルートを稟議書に関連付けて記録し、ルートに従って稟議書を転送することができる。シンガポール支店のフロントミドルは、稟議書の形式を点検し、内容の確認を完了したら、確認の完了を決裁サブシステム１４上で登録することができる。稟議書が決裁された後、コントロールカードにおける項目「Application」と「Condition」は、自動的に「Incomplete」から「Complete」に更新される。

Ｓ８０３にて、シンガポール支店のアジア審査部は、銀行端末２０を介して決裁サブシステム１４にアクセスし、回付された稟議書を承認することができる。決裁サブシステム１４は、稟議書の承認に応答して、与信管理サブシステム１５に承認を示すシグナルを送信することができる。与信管理サブシステム１５は、このシグナルを受信したことに応答して、決裁サブシステム１４から顧客の情報を取得してコーポレートカード７１に格納し、かつ案件情報管理サブシステム１２から融資の内容に関連する情報を取得してＤｅａｌ情報７２に格納することができる。与信管理サブシステム１５は、承認された稟議書の内容（例えば、貸出条件など）に従って、稟議書の決裁後に行われる与信業務を含むコントロールカードを動的に生成し、生成したコントロールカードをコントロールカード７５に格納することができる。稟議書の承認後、シンガポール支店のフロントは、稟議書の内容に従って契約書を作成する。作成された契約書は署名された後、決裁サブシステム１４の契約書６５に格納される。決裁サブシステム１４は、契約書が契約書６５に格納されたことに応答して、契約内容を与信管理サブシステム１５に送信し、送信された契約内容の情報は、契約情報７４に格納される。契約情報７４に格納された情報は、与信業務のチェックに必要な情報のみがそれぞれの役割によって参照され得る。

Ｓ８０４にて、シンガポール支店のミドルバックは、承認された稟議書および作成された契約書をレビューし、予め定められたチェック項目が充足されているかどうかを判定する。シンガポール支店のミドルバックは、与信管理サブシステム１５のコントロールカード７５にアクセスし、充足されていると判定されたチェック項目のステータスを「Incomplete」から「Complete」にアップデートする。シンガポール支店のミドルバックは、契約書のレビュー後、シンガポール支店内のＡＢＣコーポレーションの口座に与信限度額を設定することができる。この与信限度額は、契約書に記載された貸出条件に基づいて決定されることが可能である。

Ｓ８０５にて、シンガポール支店のバックは、設定された与信限度額および契約書の入金日時などの情報に従って、銀行端末２０を介して銀行システム１０上で入金オペレーションを行う。与信限度額に基づく資金は、ＡＢＣコーポレーションの口座に入金される。

（第２のケース）
図９Ａおよび図９Ｂを参照して、コーポレートファイナンスのための第２のケースが説明される。第２のケースは、銀行１の複数のエンティティ（例えば、シンガポール支店、ハノイ支店、東京の本部の審査部）によって与信関連業務が行われることを例証する。本明細書および図面において、ハノイは「ＨＮＩ」と略されてもよく、かつ東京は「ＴＫＹ」と略されてもよい。

図９Ａは、第２のケースにおける与信関連業務の流れを示す図である。
（１）シンガポール（ＳＮＧ）にある顧客ＸＹＺコーポレーションが、銀行１のシンガポール支店に融資を申し込む。
（２）シンガポール支店のフロントは、融資の申込を受けたことに応答して、コーポレートカードをメンテナンスし、Ｄｅａｌ情報を生成し、稟議書を作成する。シンガポール支店のフロントミドルは、稟議書の形式を点検し、必要書類および必要な手続きを確認する。シンガポール支店のフロントミドルは、点検および確認の後、コントロールカードをアップデートする。シンガポール支店のフロントミドルは、本部の審査部に稟議書の決裁を求める。本部の審査部は、稟議書をレビューし、貸出条件を決定し、融資を承認する。
（３）決裁後、シンガポール支店のフロントは、ベトナムのハノイ支店のミドルバックに条件管理および事務手続を依頼する。ハノイ支店のミドルバックは、承認された稟議書および契約書をレビューする。レビュー後、ハノイ支店のミドルバックは、コントロールカードをアップデートする。
（４）ハノイ支店のミドルバックは、レビュー後、ハノイ支店内のＸＹＺコーポレーションの口座に与信限度額を設定する。与信限度額は、顧客に対して設定する与信（すなわち、融資）の限度額を意味する。その後、ハノイ支店のバックは、ＸＹＺコーポレーションの口座に入金する。

図９Ｂは、第２のケースにおけるオペレーションの流れを詳細に説明するフロー図である。

Ｓ９０１にて、銀行１のシンガポール支店のフロントは、ＸＹＺコーポレーションから融資の申込を受けたことに応答して、銀行端末２０を介して顧客情報管理サブシステム１１に最新の顧客情報を入力することができる。顧客情報管理サブシステム１１は、顧客情報を入力するためのアプリケーションを提供することができる。入力された顧客情報は、情報の内容に従って、顧客情報３１、財務情報３２、財務分析３３、与信モニタリング３４、取引銀行３５および競合比較３６に格納されることが可能である。

シンガポール支店のフロントは、ＸＹＺコーポレーションが望む融資の概要を案件情報管理サブシステム１２に入力することができる。案件情報管理サブシステム１２は、融資の概要を入力するためのアプリケーションを提供することができる。入力された情報は、情報の内容に従って、Ｄｅａｌ Ｐｒｏｆｉｌｅ４１、与信明細情報４２および担保明細情報４３に格納されることが可能である。与信明細情報４２および担保明細情報４３に格納された情報は、この融資を行うことが承認されるまでは、ペンディング状態である。第２のケースは、コーポレートファイナンスを対象にするので、ＳＬ情報４４は使用されない。

Ｓ９０２にて、シンガポール支店のフロントは、銀行端末２０を介して決裁サブシステム１４にアクセスし、稟議書を作成する。シンガポール支店のフロントは、任意に、コーポレートカードおよびＤｅａｌ情報にリスクファクターを設定することができる。決裁サブシステム１４の情報取得部６６は、その稟議書に関連付けられる、顧客情報３１、財務情報３２、財務分析３３、与信モニタリング３４、取引銀行３５および競合比較３６に格納されている最新データを顧客情報管理サブシステム１１から取得することができる。取得されたデータは、決裁サブシステム１４内のコーポレートカード６１に格納される。決裁サブシステム１４の情報取得部６６は、その稟議書に関連付けられる、Ｄｅａｌ Ｐｒｏｆｉｌｅ４１、与信明細情報４２および担保明細情報４３に格納されている最新データを案件情報管理サブシステム１２から取得することができる。取得されたデータは、決裁サブシステム１４内のＤｅａｌ情報６２に格納される。これらの処理を通じて、決裁サブシステム１４は、稟議書の作成時点の顧客の情報および融資案件の情報を稟議書に関連付けることができる。

稟議書の作成が完了すると（例えば、保存ボタンが押下された後）、決裁サブシステム１４は、与信管理サブシステム１５に稟議書の作成を示すシグナルを送信することができる。このシグナルが与信管理サブシステム１５によって受信されると、稟議書の決裁前に行われる与信業務を含むコントロールカードが生成される。

シンガポール支店のフロントは、作成された稟議書を審査する部門および／または人のルート（順序）を決裁サブシステム１４上で選択する。決裁サブシステム１４は、選択されたルートを稟議書に関連付けて記録し、ルートに従って稟議書を転送することができる。シンガポール支店のフロントミドルは、稟議書の形式を点検し、内容の確認を完了したら、確認の完了を決裁サブシステム１４上で登録することができる。稟議書が決裁された後、コントロールカードにおける項目「Application」と「Condition」は、自動的に「Incomplete」から「Complete」に更新される。

Ｓ９０３にて、本部の審査部は、銀行端末２０を介して決裁サブシステム１４にアクセスし、回付された稟議書を承認することができる。決裁サブシステム１４は、稟議書の承認に応答して、与信管理サブシステム１５に承認を示す信号をシグナルすることができる。与信管理サブシステム１５は、このシグナルを受信したことに応答して、決裁サブシステム１４から顧客の情報を取得してコーポレートカード７１に格納し、かつ案件情報管理サブシステム１２から融資の内容に関連する情報を取得してＤｅａｌ情報７２に格納することができる。与信管理サブシステム１５は、承認された稟議書の内容（例えば、貸出条件など）に従って、稟議書の決裁後に行われる与信業務を含むコントロールカードを動的に生成し、生成したコントロールカードをコントロールカード７５に格納することができる。稟議書の承認後、シンガポール支店のフロントは、稟議書の内容に従って契約書を作成する。作成された契約書は署名された後、決裁サブシステム１４の契約書６５に格納される。決裁サブシステム１４は、契約書が契約書６５に格納されたことに応答して、契約内容を与信管理サブシステム１５に送信し、送信された契約内容の情報は、契約情報７４に格納される。契約情報７４に格納された情報は、与信業務のチェックに必要な情報のみがそれぞれの役割によって参照され得る。

Ｓ９０４にて、ハノイ支店のミドルバックは、承認された稟議書および作成された契約書をレビューし、予め定められたチェック項目が充足されているかどうかを判定する。ハノイ支店のミドルバックは、与信管理サブシステム１５のコントロールカード７５にアクセスし、充足されていると判定されたチェック項目のステータスを「Incomplete」から「Complete」にアップデートする。ハノイ支店のミドルバックは、契約書のレビュー後、ハノイ支店内のＸＹＺコーポレーションの口座に与信限度額を設定することができる。この与信限度額は、契約書に記載された貸出条件に基づいて決定されることが可能である。

Ｓ９０５にて、ハノイ支店のバックは、設定された与信限度額および契約書の入金日時などの情報に従って、銀行端末２０を介して銀行システム１０上で入金オペレーションを行う。与信限度額に基づく資金は、ＸＹＺコーポレーションの口座に入金される。

（第３のケース）
図１０Ａおよび図１０Ｂを参照して、ストラクチャードファイナンスのための第３のケースが説明される。第３のケースは、銀行１の複数のエンティティ（例えば、ロンドン支店、ニューヨーク支店、東京支店、ドバイ支店、東京の本部の審査部）によって与信関連業務が行われることを例証する。本明細書および図面において、ロンドンは「ＬＤＮ」と略されてもよく、ニューヨークは「ＮＹＣ」と略されてもよく、かつドバイは「ＤＢＩ」と略されてもよい。

図１０Ａは、第３のケースにおける与信関連業務の流れを示す図である。第３のケースは、例として、天然ガス精製設備建設プロジェクトに対する融資を説明する。プロジェクトのスポンサーであるＢ社はニューヨーク支店の顧客であり、建設業者であるＣ社は東京支店の顧客であり、販売先であるＤ社はドバイ支店の顧客である。Ａコーポレーションは、そのプロジェクトのためにＢ社、Ｃ社およびＤ社によって設立されたＳＰＣであり、ロンドン支店の顧客である。そのプロジェクトでは、Ａコーポレーションが債務者である。
（１）ロンドン（ＬＤＮ）にあるＡコーポレーションが、銀行１のロンドン支店に融資を申し込む。ロンドン支店のフロントは、Ａコーポレーションのコーポレートカードを更新し、Ｄｅａｌ情報を生成する。融資の申込があったことは、そのプロジェクトの関係当事者であるＢ社、Ｃ社およびＤ社を担当するニューヨーク支店、東京支店およびドバイ支店に通知される。ニューヨーク支店、東京支店およびドバイ支店の各フロントは、Ｂ社、Ｃ社およびＤ社のコーポレートカードを更新する。
（２）ロンドン支店のフロントは、融資の申込を受けたことに応答して稟議書を作成する。ロンドン支店のフロントミドルは、稟議書の形式を点検し、必要書類および必要な手続きを確認する。ロンドン支店のフロントミドルは、点検および確認の後、コントロールカードをアップデートする。ロンドン支店のフロントミドルは、東京の本部の審査部に稟議書の決裁を求める。本部の審査部は、稟議書をレビューし、貸出条件を決定し、融資を承認する。
（３）決裁後、ロンドン支店のフロントは、ロンドン支店のミドルバックに条件管理および事務手続を依頼する。ロンドン支店のミドルバックは、承認された稟議書および契約書をレビューする。レビュー後、ロンドン支店のミドルバックは、コントロールカードをアップデートする。
（４）ロンドン支店のミドルバックは、レビュー後、ロンドン支店内のＡコーポレーションの口座に与信限度額を設定する。与信限度額は、顧客に対して設定する与信（すなわち、融資）の限度額を意味する。その後、ロンドン支店のバックは、Ａコーポレーションの口座に入金する。

図１０Ｂは、第３のケースにおけるオペレーションの流れを詳細に説明するフロー図である。

Ｓ１００１にて、銀行１のロンドン支店のフロントは、Ａコーポレーションから融資の申込を受けたことに応答して、銀行端末２０を介して顧客情報管理サブシステム１１に最新の顧客情報を入力することができる。顧客情報管理サブシステム１１は、顧客情報を入力するためのアプリケーションを提供することができる。入力されたＡコーポレーションの顧客情報は、情報の内容に従って、顧客情報３１、財務情報３２、財務分析３３、与信モニタリング３４、取引銀行３５および競合比較３６に格納されることが可能である。

ロンドン支店のフロントは、Ａコーポレーションが望む融資の概要を案件情報管理サブシステム１２に入力することができる。案件情報管理サブシステム１２は、融資の概要を入力するためのアプリケーションを提供することができる。入力された情報は、情報の内容に従って、Ｄｅａｌ Ｐｒｏｆｉｌｅ４１、与信明細情報４２、担保明細情報４３およびＳＬ情報４４に格納されることが可能である。与信明細情報４２および担保明細情報４３に格納された情報は、この融資を行うことが承認されるまでは、ペンディング状態である。第３のケースは、ストラクチャードファイナンスを対象にするので、ＳＬ情報４４が使用される。ＳＬ情報４４には、そのプロジェクトのステークホルダーであるＢ社、Ｃ社およびＤ社の識別子が記憶される。

案件情報管理サブシステム１２は、融資の申込があったことを、そのプロジェクトの関係当事者であるＢ社、Ｃ社およびＤ社を担当するニューヨーク支店、東京支店およびドバイ支店に通知することができる。その通知に応答して、ニューヨーク支店、東京支店およびドバイ支店の各フロントは、銀行端末２０を介して顧客情報管理サブシステム１１にアクセスし、それぞれ、Ｂ社、Ｃ社およびＤ社の最新の顧客情報を入力することができる。入力されたＢ社、Ｃ社およびＤ社の顧客情報は、情報の内容に従って、顧客情報３１、財務情報３２、財務分析３３、与信モニタリング３４、取引銀行３５および競合比較３６に格納されることが可能である。

Ｓ１００２にて、ロンドン支店のフロントは、銀行端末２０を介して決裁サブシステム１４にアクセスし、稟議書を作成する。ロンドン支店のフロントは、任意に、コーポレートカードおよびＤｅａｌ情報にリスクファクターを設定することができる。決裁サブシステム１４の情報取得部６６は、その稟議書に関連付けられる、顧客情報３１、財務情報３２、財務分析３３、与信モニタリング３４、取引銀行３５および競合比較３６に格納されている最新データを顧客情報管理サブシステム１１から取得することができる。取得されたデータは、決裁サブシステム１４内のコーポレートカード６１に格納される。決裁サブシステム１４の情報取得部６６は、その稟議書に関連付けられる、Ｄｅａｌ Ｐｒｏｆｉｌｅ４１、与信明細情報４２、担保明細情報４３およびＳＬ情報４４に格納されている最新データを案件情報管理サブシステム１２から取得することができる。取得されたデータは、決裁サブシステム１４内のＤｅａｌ情報６２に格納される。これらの処理を通じて、決裁サブシステム１４は、稟議書の作成時点の顧客の情報および融資案件の情報を稟議書に関連付けることができる。

稟議書の作成が完了すると（例えば、保存ボタンが押下された後）、決裁サブシステム１４は、与信管理サブシステム１５に稟議書の作成を示すシグナルを送信することができる。このシグナルが与信管理サブシステム１５によって受信されると、稟議書の決裁前に行われる与信業務を含むコントロールカードが生成される。

ロンドン支店のフロントは、作成された稟議書を審査する部門および／または人のルート（順序）を決裁サブシステム１４上で選択する。決裁サブシステム１４は、選択されたルートを稟議書に関連付けて記録し、ルートに従って稟議書を転送することができる。ロンドン支店のフロントミドルは、稟議書の形式を点検し、内容の確認を完了したら、確認の完了を決裁サブシステム１４上で登録することができる。稟議書が決裁された後、コントロールカードにおける項目「Application」と「Condition」は、自動的に「Incomplete」から「Complete」に更新される。

Ｓ１００３にて、本部の審査部は、銀行端末２０を介して決裁サブシステム１４にアクセスし、回付された稟議書を承認することができる。決裁サブシステム１４は、稟議書の承認に応答して、与信管理サブシステム１５に承認を示すシグナルを送信することができる。与信管理サブシステム１５は、このシグナルを受信したことに応答して、決裁サブシステム１４から顧客の情報を取得してコーポレートカード７１に格納し、かつ案件情報管理サブシステム１２から融資の内容に関連する情報を取得してＤｅａｌ情報７２に格納することができる。与信管理サブシステム１５は、承認された稟議書の内容（例えば、貸出条件など）に従って、稟議書の決裁後に行われる与信業務を含むコントロールカードを動的に生成し、生成したコントロールカードをコントロールカード７５に格納することができる。稟議書の承認後、ロンドン支店のフロントは、稟議書の内容に従って契約書を作成する。作成された契約書は署名された後、決裁サブシステム１４の契約書６５に格納される。決裁サブシステム１４は、契約書が契約書６５に格納されたことに応答して、契約内容を与信管理サブシステム１５に送信し、送信された契約内容の情報は、契約情報７４に格納される。契約情報７４に格納された情報は、与信業務のチェックに必要な情報のみがそれぞれの役割によって参照され得る。

Ｓ１００４にて、ロンドン支店のミドルバックは、承認された稟議書および作成された契約書をレビューし、予め定められたチェック項目が充足されているかどうかを判定する。ロンドン支店のミドルバックは、与信管理サブシステム１５のコントロールカード７５にアクセスし、充足されていると判定されたチェック項目のステータスを「Incomplete」から「Complete」にアップデートする。ロンドン支店のミドルバックは、契約書のレビュー後、ロンドン支店内のＡコーポレーションの口座に与信限度額を設定することができる。この与信限度額は、契約書に記載された貸出条件に基づいて決定されることが可能である。

Ｓ１００５にて、ロンドン支店のバックは、設定された与信限度額および契約書の入金日時などの情報に従って、銀行端末２０を介して銀行システム１０上で入金オペレーションを行う。与信限度額に基づく資金は、Ａコーポレーションの口座に入金される。

本発明によれば、銀行システム１０は、業績の悪い会社の顧客ＩＤに基づいてＤｅａｌ情報又はＳＬ情報を検索することにより、その会社に関連付けられた融資案件を抽出することができる。本発明によれば、あるプロジェクトが多大な損失を発生した際、銀行システム１０は、ＳＬ情報に基づいて関係当事者を識別し、識別されたそれぞれの関係当事者の融資案件を抽出することができる。本発明によれば、銀行システム１０は、与信関連業務の進捗状況を提供することができるので、より効率的な与信管理を行うことができる。

以上、例示的な実施形態を参照しながら本発明の原理を説明したが、本発明の要旨を逸脱することなく、構成および細部において変更する様々な実施形態を実現可能であることを当業者は理解するだろう。本明細書では、銀行システム１０がサブシステム１１乃至１５を含む実施形態を説明したが、本発明はその他の実施形態に適用可能である。例えば、銀行システム１０がサブシステム１１乃至１５の機能およびデータベース／ファイルを有すれば、サブシステム１１乃至１５は使用されなくてもよい。

本発明は、例えば、システム、装置、方法、プログラムもしくは記憶媒体等としての実施態様をとることが可能である。

Claims (15)

1. コーポレートファイナンスの海外与信管理のための銀行システムであって、
   顧客情報を格納する第１の格納手段であって、前記顧客情報は、複数のエンティティによって共有可能であり、前記複数のエンティティは、複数国の支店および／または現地法人を含む、第１の格納手段と、
   与信取引の管理単位についての情報を格納する第２の格納手段であって、前記与信取引の管理単位についての情報は、１または複数の与信店の情報および１または複数の債務者の情報を有し、前記債務者は、前記顧客情報に関連付けられている、第２の格納手段と、
   稟議書に記載された与信取引の実行を承認する承認手段であって、前記承認手段は、前記稟議書の作成時の前記顧客情報および前記与信取引の管理単位についての情報を有し、前記稟議書の承認時に第１のシグナルを生成する、承認手段と、
   前記第１のシグナルに応答してコントロールカードを生成するコントロールカード生成手段であって、前記コントロールカードは、前記承認された与信取引の関連業務の進捗状況を示す、コントロールカード生成手段と
   を備え、
   前記顧客情報および前記与信取引の管理単位についての情報は、第１のエンティティによってメンテナンスされる、
   銀行システム。
2. 前記承認手段は、前記稟議書の作成時に第２のシグナルを生成し、
   前記コントロールカード生成手段は、前記第２のシグナルに応答して第２のコントロールカードを生成し、前記第２のコントロールカードは、前記コントロールカードに結合されうる、請求項１の銀行システム。
3. 前記コントロールカードは、第２のエンティティによって更新され、
   前記第１のエンティティは、第１の役割を有し、前記第２のエンティティは、第２の役割を有する、請求項１の銀行システム。
4. 前記第１の役割はフロントであり、前記第２の役割はミドルバックである、請求項３の銀行システム。
5. 前記コントロールカードは、第１のエンティティによって更新され、
   前記第１のエンティティは、第１の役割および第２の役割を有する、請求項１の銀行システム。
6. 前記第１の役割はフロントであり、前記第２の役割はミドルバックである、請求項５の銀行システム。
7. 前記第１のエンティティは主たる与信店（ＰＬＯ）である、請求項１の銀行システム。
8. 前記顧客情報、前記与信取引の管理単位についての情報、および前記コントロールカードへのアクセス制御を行うアクセス制御手段をさらに備え、
   前記アクセス制御は、ユーザの所属エンティティ、与信職位および役割に少なくとも基づいて行われる、請求項１の銀行システム。
9. 前記稟議書は、１または複数のリスクファクターを含み、
   前記リスクファクターに関連付けられた与信取引を抽出する抽出手段をさらに備えた、請求項１の銀行システム。
10. コーポレートファイナンスの海外与信管理のための銀行システムにおいて実行される方法であって、前記方法は、
    顧客情報を更新することであって、前記顧客情報は、複数のエンティティによって共有可能であり、前記複数のエンティティは、複数国の支店および／または現地法人を含む、ことと、
    与信取引の管理単位についての情報を更新することであって、前記与信取引の管理単位についての情報は、１または複数の与信店の情報および１または複数の債務者の情報を有し、前記債務者は、前記顧客情報に関連付けられている、ことと、
    稟議書の作成に応答して、前記顧客情報および前記与信取引の管理単位についての情報を取得することと、
    前記稟議書に記載された与信取引の承認に応答して、第１のシグナルを生成することと、
    前記第１のシグナルに応答してコントロールカードを生成することであって、前記コントロールカードは、前記承認された与信取引の関連業務の進捗状況を示す、ことと
    を備え、
    前記顧客情報および前記与信取引の管理単位についての情報は、第１のエンティティによってメンテナンスされる、
    方法。
11. 前記稟議書の作成に応答して、第２のシグナルを生成することと、
    前記第２のシグナルに応答して第２のコントロールカードを生成することであって、前記第２のコントロールカードは、前記コントロールカードに結合されうる、ことと
    をさらに備える、請求項１０の方法。
12. 前記コントロールカードは、第２のエンティティによって更新され、
    前記第１のエンティティは、第１の役割を有し、前記第２のエンティティは、第２の役割を有する、請求項１０の方法。
13. 前記コントロールカードは、第１のエンティティによって更新され、
    前記第１のエンティティは、第１の役割および第２の役割を有する、請求項１０の方法。
14. 前記顧客情報、前記与信取引の管理単位についての情報、および前記コントロールカードへのアクセス制御を行うことであって、前記アクセス制御は、ユーザの所属エンティティ、与信職位および役割に少なくとも基づいて行われる、ことをさらに備える、請求項１０の方法。
15. プロセッサによって実行される時に、請求項１０乃至１４のいずれか一項に記載の方法をコンピュータに実行させるプログラム。

Images