JP5934850B1 - アクセス制御装置、方法、およびプログラム - Google Patents

Abstract

複数の国に拠点を置く銀行にとって、各拠点にいる行員が、それぞれの拠点が有する情報を共有することが可能なシステムを構築することは非常に有用である。従来、そのような全拠点の行員が利用可能なシステムにおいて、国ごとに異なる法規制を順守しつつ、適切なアクセス制御を行い適切な人に適切な情報を公開するシステムは存在していなかった。複数の国にいる従業員が、各国の法規制を順守しつつ、かつ、その従業員の職務に応じて、共有された情報にアクセスすることができるシステム、方法、およびプログラムを提供する。

Description

本発明は、アクセス制御に関する。より詳細には、複数の国に営業の拠点がある銀行の各拠点にいる行員間で情報を共有する際に、国ごとに異なる法規制を順守しつつ、その行員の職務に応じたアクセス制御を提供することに関する。

近年、経済のグローバル化に伴い、多くの企業が海外に進出している。各銀行は、海外へ進出する企業を支援するために、アジア、オセアニア、米州、欧州などに営業の拠点を置いている。

銀行の融資の形態として、特定の企業に対して融資するコーポレートファイナンス、および特定のプロジェクトのキャッシュフローを分析して収益を予想し、そのプロジェクトの資産価値を担保として融資するプロジェクトファイナンスがある。特に、国内の企業のみならず複数の外国の企業が関わるプロジェクトファイナンスに対しては、銀行は、複数の国にまたがる債務者、スポンサー（そのプロジェクトのための特定目的会社に出資する企業）およびオフテイカー（そのプロジェクトによって生み出されるものを購入する企業）など（以下、まとめて「関係当事者」と呼ぶ）の信用リスクを検証し、与信判断する必要がある。また、複数の国に業務を展開しているグローバルな企業に対する融資の与信判断においても、銀行内の複数の拠点の行員が情報を共有する必要がある。

しかしながら、顧客情報の取り扱いに関する法規制は、各国によって異なる。海外の支店では、その国の法規制を順守しつつ、顧客情報を管理しなければならない。そのため、取り扱われる情報の多くは支店ごとに管理され、支店間での情報共有が十分に行われない場合もあった。例えば、上述したような与信判断においては、顧客の経営陣、事業内容、財務状況、与信状況に基づいて総合的に判断する必要があるが、複数の国にまたがる拠点間で情報共有が十分に行われていないケースもあった。

さらに、銀行は、公共性の極めて高い企業であり、事業を営むうえでの法律や規則などの法令を守るだけでなく、社会的規範や企業倫理を守ることが求められる。特にメガバンクでは、コンプライアンスに対する特段の配慮が求められ、実効性の高いコンプライアンス組織体制の整備が必要不可欠になっている。例えば、日本では、内部統制および個人情報保護の観点から、銀行内部で機密性の高い文書を取り扱うことへの高い配慮が求められている。特に、上述したような、複数の国に拠点を置くメガバンクにおいては、国ごとに順守すべき法律の内容や基準が異なるため、より一層の配慮が求められる。

さらに、銀行で取り扱われる情報には種々多様な情報が存在するため、インサイダー情報へのアクセスを配慮する必要がある。例えば、Ｍ＆Ａ情報などが世間に公開される前にアクセス可能であるとインサイダー取引を招く危険がある。共有する情報を各パーツに区分して、情報の公開／非公開を設定可能とする必要がある。

複数の国に拠点を置く銀行にとって、各拠点にいる行員が、それぞれの拠点が有する情報を共有することが可能なシステムを構築することは非常に有用である。従来、そのような全拠点の行員が利用可能なシステムにおいて、国ごとに異なる法規制を順守しつつ、適切なアクセス制御を行い適切な人に適切な情報を公開するシステムは存在していなかった。

そこで、本発明は、複数の国に拠点を置く銀行の各拠点にいる行員が情報を共有することができ、かつ、各国の法規制に反することなく、権限のない行員が共有された情報へアクセスすることを防ぐことを目的とする。

このような目的を達成するために、本発明は、グローバル与信管理システムによって実行される、情報へのアクセス制御方法であって、ユーザーのログインＩＤを受信するステップと、前記ログインＩＤに関連づけられた職務および前記ユーザーの所属するエンティティを判定するステップと、前記ユーザーがアクセスを試みる情報に対するアクセス可否を判定するステップであって、前記アクセス可否の判定は、ａ）前記ユーザーがアクセスを試みる情報を管理するエンティティを判定するステップと、ｂ）前記ユーザーがアクセスを試みる情報を管理するエンティティに関連づけられた、法規制に基づくアクセス制御パターンを判定するステップと、ｃ）前記ユーザーの所属するエンティティと前記ユーザーがアクセスを試みる情報を管理するエンティティとの関係に基づき、前記法規制に基づくアクセス制御パターンを満たしているか判定するステップと、ｄ）前記ログインＩＤに関連づけられた職務で前記ユーザーがアクセスを試みる情報にアクセス可能か判定するステップと、に基づいて行われる、ステップとを有する。

本発明によれば、複数の国にいる従業員が、各国の法規制を順守しつつ、かつ、その従業員の職務に応じて、共有された情報にアクセスすることができる。

本発明に係るグローバル与信管理システムと各エンティティグループに属する各エンティティとの関係を概念的に説明する図である。 本発明の一実施形態に係る、グローバル与信管理システムの機能ブロック図である。 図３Ａと図３Ｂの関係を示す図である。 本発明の一実施形態に係る、銀行内部の与信業務に関する業務フローを示す図である。 本発明の一実施形態に係る、銀行内部の与信業務に関する業務フローを示す図である。 本発明の一実施形態に係る、ユーザー情報連携データベースに登録されるユーザー情報に関するデータ構造の一例を示す。 本発明の一実施形態に係る、ユーザー情報連携データベース（またはその他のデータベース）に登録されるエンティティ情報に関するデータ構造の一例を示す。 本発明の一実施形態に係る、顧客情報管理データベースに登録される、顧客情報に関するデータ構造の一例を示す。 図７Ａと図７Ｂと図７Ｃの関係を示す図である。 本発明の一実施形態に係る、顧客情報管理データベースまたはその他のデータベースに登録される、顧客情報の種別ごとのアクセス権限テーブルに関するデータ構造の一例を示す。 本発明の一実施形態に係る、顧客情報管理データベースまたはその他のデータベースに登録される、顧客情報の種別ごとのアクセス権限テーブルに関するデータ構造の一例を示す。 本発明の一実施形態に係る、顧客情報管理データベースまたはその他のデータベースに登録される、顧客情報の種別ごとのアクセス権限テーブルに関するデータ構造の一例を示す。 本発明の一実施形態に係る、顧客情報管理データベースまたはその他のデータベースに登録される、顧客情報に関する各国法規制の類型情報に関するデータ構造の一例を示す。 本発明の一実施形態に係る、各国法規制の第１の類型における例示的な実施形態の全体像を説明する図である。 本発明の一実施形態に係る、本発明に係わるシステムにおいて行われる処理の流れを説明するフローチャートである。 本発明の一実施形態に係る、図９の事例における、第３国の審査部に所属するユーザーに対するアクセス制御処理の流れを説明するフローチャートである。 本発明の別の実施形態に係る、ストラクチャードファイナンスにおける例示的な実施形態の全体像を説明する図である。 図１３Ａと図１３Ｂの関係を示す図である。 本発明の別の実施形態に係る、ストラクチャードファイナンスにおける例示的な業務フローを示す図である。 本発明の別の実施形態に係る、ストラクチャードファイナンスにおける例示的な業務フローを示す図である。 本発明の別の実施形態に係る、本発明において行われる処理の流れを説明するフローチャートである。 本発明の一実施形態に係る、金融機関システムとグローバル与信管理システムの構成の一例を示す。

以下、図面を参照しながら本発明の実施形態について詳細に説明する。

本明細書において、エンティティグループとは、ある１つの銀行の組織に属するグループ（例えば、法人化された企業）のことをいう。すなわち、各エンティティグループは、例えば、日本で法人化された銀行、あるいは、その銀行に関連する別法人（例えば、現地法人）を表す。日本で法人化された銀行に対して、経営、運営を別とする、外国で法人化された複数の子会社が存在する。お互いに関連する法人であっても、別法人として法規制が適用されるため、各法人は、異なるアクセス制御を用いる必要性がある。そのため、本発明においては、複数のエンティティグループを識別し、エンティティグループごとに適切なアクセス制御をもたらすことを可能とする。また、本明細書において、エンティティとは、エンティティグループに属する営業の拠点（支店や出張所など）のことをいう。

図１は、本発明に係るグローバル与信管理システム１０００と各エンティティグループに属する各エンティティとの関係を概念的に説明する図である。

顧客１１０１は、第１国 １１００に設立された企業である。第１国 １１００には、エンティティグループＡ １１１０に属するエンティティＡ１ １１１１とエンティティＡ２ １１１２が存在する。エンティティＡ１ １１１１は、顧客１１０１から融資の相談を受けて、顧客１１０１の情報を管理するエンティティ（以下、顧客の情報を管理するエンティティを「所管店」という）である。なお、本明細書において、「顧客の情報を管理する」とは、いずれかの場所（所管店の所在国でもよいし、所管店の所在国以外の国でもよい）に配置されたサーバーに格納される顧客の情報を、主として作成・更新する責任を負うことを表し、所管店が、所管店の敷地内に、顧客の情報を格納するためのサーバーを配置する必要は必ずしもない。さらに、第１国 １１００には、エンティティグループＢ １１２０（エンティティグループＢは、エンティティグループＡに関連する法人であるが、エンティティグループＡとは別法人である）に属するエンティティＢ１ １１２１が存在する。

第２国 １２００は、第１国 １１００とは異なる国である。第２国 １２００には、エンティティグループＡ １１１０に属するエンティティＡ３ １１１３が存在する。さらに、第２国 １２００には、エンティティグループＢ １１２０に属するエンティティＢ２ １１２２が存在する。

このように、本発明は、同一の情報に対する、５種類のエンティティに所属する行員からのアクセスを制御する。５種類のエンティティは、当該情報を管理する所管店（すなわち、エンティティＡ１ １１１１）、所管店と同一のエンティティグループに属する国内の別のエンティティ（すなわち、エンティティＡ２ １１１２）、所管店とは別のエンティティグループに属するが所管店と同一の国に存在するエンティティ（すなわち、エンティティＢ１ １１２１）、所管店と同一のエンティティグループに属するが所管店とは別の国に存在するエンティティ（すなわち、エンティティＡ３ １１１３）、所管店とは別のエンティティグループに属し所管店とは別の国に存在するエンティティ（すなわち、エンティティＢ２ １１２２）である。

図２は、本発明の一実施形態に係る、グローバル与信管理システム１０００の機能ブロック図である。

グローバル与信管理システム１０００は、エンティティまたはエンティティグループごとに異なる（または共通の）銀行システム１５００（図１５を参照しながら後述する）と連携し、グローバルな与信管理を行うためのシステムである。グローバル与信管理システム１０００は、ユーザー情報連携およびアクセス可否判定部２１０と、顧客情報管理部２２０と、案件情報管理部２３０と、複数当事者案件情報管理部２４０と、与信事務管理部２５０とを有する。グローバル与信管理システム１０００は、プロセッサおよびメモリを含むコンピュータである。また、グローバル与信管理システム１０００は、ユーザー情報連携およびアクセス可否判定部２１０と、顧客情報管理部２２０と、案件情報管理部２３０と、複数当事者案件情報管理部２４０と、与信事務管理部２５０とを動作させるためのプログラム、または、後述する処理フローを実行するためのプログラム、を格納した記憶媒体を含む。

ユーザー情報連携およびアクセス可否判定部２１０は、銀行システム１５００にログインしたユーザーの情報を、グローバル与信管理システム１０００内で管理するユーザーの情報と紐付ける役割を担う。本発明は、世界中のエンティティに所属する行員を、全世界で統一された「職務」に基づいて区分けし、その行員の「職務」に応じたアクセス制御を提供する。一例であって、限定的に解釈されるべきではないが、例えば、職務として、フロント、フロントミドル、ミドルバック、バック、審査部などの種別を含む。各職務の行員は、それぞれの職務に対してアクセスが許容された情報に、アクセスすることが可能である。ユーザー情報連携およびアクセス可否判定部２１０は、銀行システム１５００にログインする際に用いられたユーザーＩＤに関連づけられた職務を、ユーザー情報連携データベース２１１内のユーザー情報４００（後述する）から読み出すことができる。また、グローバル与信管理システム１０００は、読み出した職務に基づいて、そのユーザＩＤが情報にアクセス可能な権限を有するか否かを判定することができる（詳細については、後述する）。

顧客情報管理部２２０は、拠点間で共通のフォームおよびフォーマットを用いて、与信管理プロセスの中で必要とされる顧客情報を整備する役割を担う。拠点間で連携が取られていないと、拠点ごとに異なるルールで顧客情報が作成および更新され、機密性・完全性・可用性に欠く場合がある。グローバルな企業などに対する与信業務は、拠点をまたがって業務管理を行う必要性があるため、共通の枠組みの中で顧客情報を管理する仕組みが求められる。そこで、顧客情報管理部２２０は、与信判断に必要となる、顧客に関する全データを全世界共通のフォーマットで管理する。顧客情報管理部２２０は、外部調査機関から入手した企業情報や他のシステムから入手した顧客情報を、登録および更新してもよい。顧客情報管理部２２０は、さらに、顧客の本店所在国や業種情報などの基本情報、債務者格付などのモニタリング情報、主要株主や企業沿革などの経営情報、主要取引先などの営業情報といった、企業情報を格納して管理する。顧客情報管理部２２０は、また、企業情報および財務情報について、主要な項目に絞ったサマリを表示する機能や、顧客の競合企業についての主要な財務情報や業種固有の情報を比較可能な形で表示する機能を有していてもよい。財務情報のサマリには、担当者や審査役が入力するコメントと、各種科目を紐づけるための文字を科目単位で登録することを可能とし、コメントの対象となっている科目特定をサポートする。顧客情報管理部２２０はさらに、企業の借入について、任意の基準日時点での借入先単位の借入残高を登録し、表示する機能を提供する。

上記羅列された情報項目は、一例であって限定されるべきではないが、顧客情報管理部２２０は、顧客に関する種々多様な慎重に扱うべき情報を管理する。そのため、各国の法規制に則りかつ適切な職務にあたる行員のみが情報の閲覧を可能とする、アクセス制御を実装することが求められる。顧客情報管理部２２０は、各拠点から与信判断に必要とされる情報の参照要求を受信すると、当該参照要求に関わるデータを、顧客情報管理データベース２２１から抽出して提供する。

例えば、関係当事者が複数存在するプロジェクトファイナンスに対する融資判断に関しては、債務者のみならず、ステークホルダーや保証人などの情報の参照要求が想定され得る。顧客情報管理部２２０は、当該プロジェクトファイナンスに関わる、ステークホルダーや保証人に関わる顧客情報の参照要求を受信すると、後述する複数当事者案件情報管理部２４０と連携のうえ、顧客情報管理データベース２２１から情報を抽出して提供する。この際、ステークホルダーや保証人ごとに異なるアクセス制限を割り当ててもよい。例えば、ステークホルダーＡに関する顧客情報に対しては、職務よるアクセス制限を指定せず、どのような職務の者に対してもアクセスを許容する。一方、保証人Ｂに関する顧客情報に対しては、アクセスを許容する職務を指定し、指定された職務の者にしかアクセスを許容しないように構成してもよい。

また、顧客情報管理部２２０は、情報項目を細分化し、各情報項目ごとに異なるアクセス制限を割り当ててもよい。例えば、顧客の情報中、交渉中のＭ＆Ａなどの情報については、最上位のアクセス制限を付け、特定の職務の者にしか情報開示の許可を与えないように構成してもよい。一方、顧客の基本情報に対しては、広範な種類の職務を指定して、より広範な種類の職務の者にアクセスを許容してもよい。さらに、顧客の情報を細分化し、そのそれぞれに対して種々多様なアクセス制限を関連づけてもよい。

顧客情報管理部２２０は、参照要求を受けると、顧客情報管理データベース２２１から情報を抽出する際に、当該要求に関わる情報を参照するために必要な「職務」を、顧客情報管理データベース２２１から読出し、ユーザー情報連携およびアクセス可否判定部２１０に対して提供することができる。

案件情報管理部２３０は、与信の取引（案件）ごとに情報を管理する役割を担う。案件情報管理データベース２３１は、融資案件に関わる、プロファイル（採り上げ背景、資金調達、支援分担、貸出ストラクチャなど）、与信明細、極度額、担保明細などの情報を保持する。例えば、顧客からある特定のプロジェクトに対する融資の相談を受けたエンティティは、当該プロジェクトに関する情報を案件情報管理データベース２３１に登録する。その後、当該プロジェクト案件に関わる、与信稟議作成、与信稟議承認、融資実行などの際に、案件情報管理データベース２３１に登録された案件情報を参照し、当該プロジェクトに対するリスク判断などを行うことが可能となる。案件情報管理部２３０は、顧客情報管理部２２０および複数当事者案件情報管理部２４０と連携のうえ、案件情報に関連づけられた情報を、提供する機能を有していてもよい。

複数当事者案件情報管理部２４０は、ストラクチャードファイナンス案件などにおける、スポンサーやオフテイカーなど関係当事者の信用リスクを検証し与信判断するための情報を管理する。ある特定のプロジェクトに対して行う融資については、与信判断を行う際に、プロジェクトに関与するスポンサーやオフテイカーなど関係当事者の信用リスクを検証することは非常に重要である。しかしながら、スポンサーやオフテイカーなどが、異なる国に存在し、各スポンサーやオフテイカーの情報を管理する拠点が異なる場合がある。したがって、各スポンサーやオフテイカーの情報を統一した形態で保有するとともに、それらの情報を管理する拠点（すなわち、所管店）に応じたそれぞれ異なるアクセス制御が必要となる。複数当事者案件情報データベース２４１には、プロジェクトのサマリ、ストラクチャ、マイルストーンといったアセットプロファイルや、関係当事者の情報が格納される。例えば、複数当事者案件情報管理部２４０は、以下の表のように、与信取引における関係者をそのプロジェクトに係わる役割に応じて分類して管理する。本システムにおいては、下記関係者の登録された種別に基づきアクセス制御を行う構成としてもよい。

与信事務管理部２５０は、銀行内における与信業務について、全世界的に共通の枠組みの中で、効率的に管理・運営する役割を担う。

例えば、図３は金融機関内部の与信業務に関する業務フローを示す図である。フロントとは、「フロントオフィス」の略称であり、主に、顧客と直接連絡をとるなどして、融資取引の条件を決定し、契約を（仮）締結し、与信稟議書を作成する。フロントミドルは、主に、顧客とフロントとの間での締結された（仮）契約についての与信稟議書を形式的に点検し、必要書類・手続などの内容確認を行う。ミドルバックは、主に、承認済稟議書と契約書類の確認など定型的なチェック作業を行う。本部（審査部）は、与信稟議書を承認または条件などを付与する。与信稟議書が承認されると、フロントおよびフロントミドルが契約書を作成し、ミドルバックは、作成された契約書をチェックし、枠登録を行い、さらに、バックは、締結された契約書に基づく入金処理を行う。

このように、１つの与信業務に係わる業務は細分化され、その細分化された業務に複数の部署が関与し、その複数の部署は複数国および／または複数のエンティティグループをまたがる可能性がある。銀行内の与信業務は、各拠点、各部署および／または複数のエンティグループにまたがることでより一層複雑化する。そこで、各拠点および各部署の役割分担を明確化し、共通の枠組みの中で共通のフォーマットで実行するための仕組みが与信事務管理部２５０によって提供される。与信事務管理データベース２５１に、与信業務に必要な情報が全世界共通のフォーマットで格納され、各業務工程の実行時に各拠点からアクセスされる。与信業務管理を全世界共通のフォーマットで標準化・可視化することにより、ある与信業務がどの段階にあり、どの部署に責任が所在するのか明確になる。与信事務管理部２５０においては、主に、契約前の準備、実行準備、期中管理の大きく３つの工程に分類して管理を行う。

与信事務管理データベース２５１には、上記３つの工程を実行するために必要な情報が格納される。例えば、契約前の準備工程においては、契約内容点検（署名前の点検）、署名前に必要な徴求物（各種ドキュメント）・付随プロセス、審査部条件、署名前の担保・保証の充足などに関する情報がチェックされ格納される。実行準備工程においては、事後徴求物（各種書類）、事後の担保・保証の充足などに関する情報がチェックされ格納される。期中管理工程においては、勘定実行可能な状態での事後徴求物（各種書類）、審査部条件、勘定実行可能な状態での事後の担保・保証の充足などに関する情報がチェックされ格納される。

図４は、本発明の一実施形態に係る、ユーザー情報連携データベース２１１に登録されるユーザー情報４００に関するデータ構造の一例を示す。ユーザー情報４００は、ユーザーのログインＩＤを表すユーザーＩＤと、ユーザーの所属エンティティグループＩＤと、所属エンティティＩＤと、職務などを含む。「ユーザＩＤ」は、行員が銀行システム１５００にログインする際に用いるログインＩＤである。「所属エンティティグループＩＤ」は、その行員が所属するエンティティが属するエンティティグループのＩＤである。エンティティグループＩＤは、エンティティグループを一意に識別するためのＩＤである。「所属エンティティＩＤ」は、その行員が所属するエンティティのＩＤである。エンティティＩＤは、あるエンティティグループに属するエンティティ（例えば、支店または出張所）を一意に識別するためのＩＤである。「職務」は、全世界で統一された「職務」（フロント（Ｆ）、フロントミドル（ＦＭ）、ミドルバック（ＭＢ）、バック（Ｂ）など）の種別を識別するためのＩＤである。グローバル与信管理システム１０００を、拠点ごとに異なる（または共通の）銀行システム１５００と連携させるために、ユーザー情報４００は、銀行システム１５００で使用されるユーザーＩＤに関連づけて、所属エンティティグループＩＤ、所属エンティティＩＤと、職務についての情報を含む。

図５は、本発明の一実施形態に係る、ユーザー情報連携データベース２１１（またはその他のデータベース）に登録されるエンティティ情報５００に関するデータ構造の一例を示す。エンティティ情報５００は、世界各国に配置されるエンティティについて、エンティティ名と、エンティティＩＤと、所属エンティティグループＩＤと、所在国などを含む。「エンティティ名」は、そのエンティティの支店名、出張所名などである。「エンティティＩＤ」は、そのエンティティのＩＤである。「所属エンティティグループＩＤ」は、そのエンティティが属するエンティティグループのＩＤである。「所在国」は、そのエンティティが存在する国を表す。

図６は、本発明の一実施形態に係る、顧客情報管理データベース２２１に登録される、顧客情報６００に関するデータ構造の一例を示す。顧客情報６００は、顧客ＩＤ、顧客情報を管理するエンティティ（すなわち、所管店）のエンティティＩＤ、情報種別、情報項目ＩＤ、情報種別詳細、情報、顧客同意の有無などの情報を含む。「顧客ＩＤ」は、顧客を一意に識別するためのＩＤである。「所管店エンティティＩＤ」は、その顧客についての情報を管理するエンティティのエンティティＩＤである。「情報種別」は、顧客情報の種類である。「情報項目ＩＤ」、「情報種別詳細」、「情報」は、各情報種別をさらに詳細に区分けしたものである。情報種別は、図６で、一例として３つの例（基本情報、取引係数、営業情報）を挙げて説明したが、より細分化した情報種別を用いてもよいことは言うまでもない。「顧客同意」は、顧客が、その情報を、所管店が存在する国の法律で許容されている、情報を共有できる範囲（例えば、国内の同一法人内で共有可能、あるいは、国内外の同一法人内で共有可能）外に開示することを同意しているか否かを表す。

図７は、本発明の一実施形態に係る、顧客情報管理データベース２２１またはその他のデータベースに登録される、顧客情報の種別ごとのアクセス権限テーブル７００に関するデータ構造の一例を示す。アクセス権限テーブル７００は、顧客情報の種別ごとに、閲覧者（すなわち、ユーザーＩＤを用いてログインして情報にアクセスする行員）の所属エンティティと顧客情報を管理するエンティティとの関係に基づき、顧客情報にアクセスできる職務を判定するために参照される。アクセス権限テーブル７００において、「自部店」とは、閲覧者の所属するエンティティが顧客の情報を管理することを意味し、「他部店」とは、閲覧者と同一エンティティグループに属する他のエンティティが顧客の情報を管理することを意味する。例えば、基本情報のうち、顧客名、顧客の国に関する情報は、顧客の情報を管理するエンティティに所属する行員のうち、職務がＦ（フロント）、ＭＢ（ミドルバック）、バック（Ｂ）である行員であれば閲覧が許容されることを示す。さらに、顧客がプロジェクトにおいてどのような役割を果たすかによっても異なるアクセス権限を付与してもよい。例えば、ストラクチャードファイナンスに関与する顧客については、債務者、実質同一債務者、関連与信先、関係当事者、その他、などで分類される関係者の登録種別を用いて顧客を識別し、顧客がプロジェクトにおいてどの役割を担うかによって、異なるアクセス制御を行ってもよい。

図８は、本発明の一実施形態に係る、顧客情報管理データベース２２１またはその他のデータベースに登録される、顧客情報に関する各国法規制の類型情報８００に関するデータ構造の一例を示す。本実施形態においては、一例として、各国の法規制を３つの類型に分類する。例えば、類型１は、アクセスを要求するユーザー（すなわち、情報を閲覧する行員）の所属するエンティティと、顧客情報を管理するエンティティとが、同一エンティティグループ（例えば、同一法人）に属していても、それぞれのエンティティの所在国が異なるエンティティ同士で情報を共有するには顧客の同意を必要とする。類型２は、アクセスを要求するユーザーの所属するエンティティと、顧客情報を管理するエンティティの、所在国が異なっていても同一のエンティティグループに属するのであれば、所在国が異なるエンティティ同士で情報を共有することが（顧客の同意無しで）可能である。類型３は、情報共有の法規制がなく、アクセスを要求するユーザーの所属するエンティティと、顧客情報を管理するエンティティとが、同一エンティティグループに属さず、所在国が異なっていても共有を認める。また、類型ごとに、その類型の法規制を採用する国名が登録される（図示せず）。また、各類型は、閲覧する顧客情報の所管店の所在国の法規制が適用される。

図９は、本発明の一実施形態に係る、各国法規制の第１の類型における例示的な実施形態の全体像を説明する図である。本実施形態において、第１国 ９１００に本社、第２国 ９２００に支社を置く顧客（事業会社Ｘ）に対する融資の実行を例に挙げて説明する。事業会社Ｘは、本社９１１０がある第１国 ９１００と支社９２１０がある第２国 ９２００でそれぞれ融資が実行されることを希望している。したがって、顧客（本社）９１１０は、第１国に配置される第１国エンティティ９１０１に融資の相談をする。また、顧客（支社）９２１０は、第２国に配置される第２国エンティティ９２０１（第２国エンティティ９２０１は、第１国エンティティ９１０１と同一のエンティティグループに属する）に融資の相談をする。なお、事業会社Ｘの顧客情報は、第１国に配置される第１国エンティティ９１０１によって管理されるものとする（すなわち、第１国エンティティ９１０１は所管店である）。つまり、第１国エンティティ９１０１は、事業会社Ｘの顧客情報を作成または更新し、案件情報および与信稟議書を作成し、リスク登録などの手続きを行う。そして、第２国エンティティ９２０１は、第１国エンティティ９１０１で作成または更新された、事業会社Ｘの顧客情報、案件情報、および与信稟議書を参照する。

第１国エンティティ９１０１と、第２国エンティティ９２０１において、図３の業務フローに沿った、各職務に応じた業務が発生する。フロントの役割を有する者によって、顧客の顧客情報および稟議書が作成され、第３国 ９３００にあるエンティティ（審査部）９１０３において稟議書の決裁がなされる。その後、第１国エンティティ９１０１と、第２国エンティティ９２０１において、フロントで契約書の作成がなされ、ミドルバックで徴求書類のチェックおよび枠の登録が行われ、全ての手続きが円滑に進めば、バックで最後に貸出の実行処理が行われる。この際、各職務に応じた権限を有する者が、割り当てられた職務を遂行するにあたり、案件情報や事業会社Ｘの顧客情報を参照する必要がある。事業会社Ｘの顧客情報は、第１国エンティティ９１０１によって管理されているため、所管店が存在する第１国 ９１００の法規制（第１の類型とする）に沿ったアクセス制御が必要となる。例えば、第２国エンティティ９２０１に属する、職務がフロントであるユーザーに対するアクセス制御を例に挙げて次の図で説明する。

図１０は、本発明の一実施形態に係る、本発明に係わるシステムにおいて行われる処理の流れを説明するフローチャートである。上記で説明したように、図９の事例に基づき、第２国に配置される第２国エンティティ９２０１に属する、職務がフロントであるユーザー（ユーザーＩＤ：Ｕ０００１）が、第１国に配置される第１国エンティティ９１０１が管理する顧客情報にアクセスする際のアクセス制御を例に挙げて説明する。

ステップ１００１において、ユーザーが自身の所属するエンティティグループの銀行システム１５００にログインする。例えば、ログインする銀行システム１５００は、グローバル与信管理システム１０００と連携がなされてさえいれば、全てのエンティティグループで共通のシステムでもよいし、国ごとやエンティティグループごとに分離されたシステムであっても良い。

ステップ１００２において、ユーザー情報連携およびアクセス可否判定部２１０は、ユーザー情報４００を参照して、ログインで用いられたユーザーＩＤに対応する、職務、所属エンティティＩＤ、所属エンティティグループＩＤを判定する。本例においては、ユーザー情報４００に基づき、ユーザー（ユーザーＩＤ：Ｕ０００１）は、エンティティグループＩＤ：ＯＧ００１に属するエンティティＩＤ：ＯＧ０００１−０００３に所属する、フロントの職務を担当するユーザーであることが判定される。

ステップ１００３において、ユーザー（ユーザーＩＤ：Ｕ０００１）は、与信条件などを判断し、与信稟議書を作成するために、顧客情報（本例においては、事業会社Ｘの情報）にアクセスする。本ステップにおいて、ユーザー情報連携およびアクセス可否判定部２１０は、顧客情報６００を参照して、アクセスすることを要求されている顧客情報を管理するエンティティを判定する。本例においては、顧客情報６００を参照して、エンティティＩＤ：ＯＧ００１−００２が、当該アクセスに係わる顧客情報を管理するエンティティであることが判定される。さらに、本ステップにおいて、ユーザー情報連携およびアクセス可否判定部２１０は、顧客情報６００を参照して、アクセスすることを要求されている顧客情報の情報種別および情報項目ＩＤを判定する。なお、本ステップまたは以下のステップにおいて、ユーザー情報連携およびアクセス可否判定部２１０が、顧客情報６００等を参照する構成ではなく、顧客情報管理部２２０に要求を提出して、顧客情報管理部２２０が顧客情報６００等を参照する構成を採用してもよい。

ステップ１００４において、ユーザー情報連携およびアクセス可否判定部２１０は、各国法規制の類型情報８００およびエンティティ情報５００を参照して、顧客情報を管理するエンティティの所在国における法規制類型を判定する。本例においては、当該アクセスすることを要求されている顧客情報を管理するエンティティの法規制の類型は１であるとする。

ステップ１００５において、ユーザー情報連携およびアクセス可否判定部２１０は、アクセスを試みるユーザー（ユーザーＩＤ：Ｕ０００１）の所属するエンティティと顧客情報を管理するエンティティとの関係に基づき、各国法規制の要件をクリアしているか判定する。本例において、ステップ１００４において判定された法規制類型によれば、ログインユーザーの所属するエンティティが、顧客情報を管理するエンティティと、ｉ）同一のエンティティグループに属し、かつ、ｉｉ）同一の国に所在することが求められる。ユーザー（ユーザーＩＤ：Ｕ０００１）の所属する第２国エンティティ９２０１は、顧客情報を管理する第１国エンティティ９１０１と、同一のエンティティグループに属するが（上記ｉ）条件はクリア）、一方で、同一の国には属さない（上記ｉｉ）条件はクリアしない）。したがって、ＮＯに分岐し、ステップ１００６に遷移する。

ステップ１００６において、ユーザー情報連携およびアクセス可否判定部２１０は、事業会社Ｘから事業会社Ｘの顧客情報の開示について、同意を得ているか判定する。顧客同意については、顧客情報を収集する際に予め顧客に確認し、同意の有無を顧客情報６００に格納していてもよい。顧客の同意に関しては、当該顧客の全顧客情報に対する包括的な同意でもよいし、情報種別ごとの同意、または情報項目ごとの同意であってもよいことは言うまでもない。同意が得られていない場合、ステップ１００７においてアクセス拒否判定がなされ、処理が終了する。

ステップ１００８において、ユーザー情報連携およびアクセス可否判定部２１０は、顧客情報の種別ごとのアクセス権限テーブル７００を参照して、ユーザーのログインＩＤに関連づけられた職務で、顧客情報にアクセス可能か否かを判定する。本例においては、アクセスを試みるユーザー（ユーザーＩＤ：Ｕ０００１）の所属する第２国エンティティ９２０１は、顧客情報を管理する第１国エンティティ９１０１と、同一のエンティティグループに属する。そして、例えば、アクセスを試みる情報種別が基本情報（情報項目ＩＤ：Ｂ０００３）であって、事業会社Ｘは第２国エンティティ９２０１にとっては、他のエンティティが管理する取引先（他部店）であるとする。ユーザー情報連携およびアクセス可否判定部２１０は、アクセス権限テーブル７００を参照して、フロントの職務を有するユーザー（ユーザーＩＤ：Ｕ０００１）のアクセスが（関係者の役割が「債務者」の場合に）許容されることを判定する。

ステップ１００９において、ステップ１００８でアクセスが許容されることが判定されると、顧客情報が開示され処理は終了する。

図１１は、本発明の一実施形態に係る、図９の事例における、第３国の審査部に属するユーザー（ユーザーＩＤ：Ｕ０００２）に対するアクセス制御処理の流れを説明するフローチャートである。

ステップ１１０１において、第３国 ９３００に配置される審査部に属する、担当職務および権限が審査部であるユーザー（ユーザーＩＤ：Ｕ０００２）がログインを行う。

ステップ１１０２において、ユーザー情報連携およびアクセス可否判定部２１０は、ユーザー情報４００を参照して、ログインで用いられたユーザーＩＤに対応する、職務、所属エンティティＩＤ、所属エンティティグループＩＤを判定する。本例においては、ユーザー情報４００に基づき、ユーザー（ユーザーＩＤ：Ｕ０００２）は、エンティティグループＩＤ：ＯＧ００１に属する、エンティティＩＤ：ＯＧ０００１−０００４に所属する、審査部（ＥＸ）の職務を担当するユーザーであることが判定される。

ステップ１１０３において、ユーザー（ユーザーＩＤ：Ｕ０００２）は、与信条件などを判断するために、顧客情報（本例においては、事業会社Ｘの情報）にアクセスする。本ステップにおいて、ユーザー情報連携およびアクセス可否判定部２１０は、顧客情報６００を参照して、アクセスすることを要求されている顧客情報を主に管理するエンティティを判定する。さらに、本ステップにおいて、ユーザー情報連携およびアクセス可否判定部２１０は、顧客情報６００を参照して、アクセスすることを要求されている顧客情報の情報種別および情報項目ＩＤを判定する。なお、本ステップまたは以下のステップにおいて、ユーザー情報連携およびアクセス可否判定部２１０が、顧客情報６００等を参照する構成ではなく、顧客情報管理部２２０に要求を提出して、顧客情報管理部２２０が顧客情報６００等を参照する構成を採用してもよい。

ステップ１１０４において、ユーザー情報連携およびアクセス可否判定部２１０は、顧客情報を管理するエンティティと、アクセスを試みるユーザー（ユーザーＩＤ：Ｕ０００２）の所属するエンティティが同一エンティティグループに所属するか判定する。本例において、当該アクセスに係わる顧客情報を管理する第１国エンティティ９１０１と、ユーザー（ユーザーＩＤ：Ｕ０００２）の所属する第３国のエンティティ９１０３とがエンティティグループが同一であるとすると、ステップ１１０６に遷移する。なお、本実施形態において、顧客情報を管理するエンティティと、アクセスを試みるユーザーの所属するエンティティが同一エンティティグループに属することを要件として説明した。しかしながら、顧客情報を管理するエンティティと、アクセスを試みるユーザーの所属するエンティティが、同一地域（例えば、アジア、欧州など）に属すること、または、同一の法規制の類型を有することなどを要件としてもよい。

ステップ１１０４において、要件を満たさないと判定されると、ステップ１１０５に遷移し、ユーザー情報連携およびアクセス可否判定部２１０は、事業会社Ｘから事業会社Ｘの顧客情報の開示について、同意を得ているか判定する。同意が得られていない場合、ステップ１１０８においてアクセス拒否判定がなされ、処理が終了する。

ステップ１１０５において、ユーザー情報連携およびアクセス可否判定部２１０は、顧客の同意があることを確認すると、ステップ１１０６に遷移する。

ステップ１１０６において、ユーザー情報連携およびアクセス可否判定部２１０は、顧客情報の種別ごとのアクセス権限テーブル７００を参照して、ログインユーザーのＩＤに関連づけられた職務で、顧客情報にアクセス可能か判定する。本例においては、アクセスを試みるユーザー（ユーザーＩＤ：Ｕ０００２）の所属するエンティティは、同一のエンティティグループに属する。そして、例えば、アクセスを試みる顧客情報の種別が基本情報であって、事業会社Ｘは他のエンティティによって情報を管理される他部店であるとする。ユーザー情報連携およびアクセス可否判定部２１０は、顧客情報の種別ごとのアクセス権限テーブル７００を参照して、審査部の担当職務及び権限を有するユーザー（ユーザーＩＤ：Ｕ０００２）のアクセスが許容されることを判定する（審査部に所属する行員は、インサイダー情報を除くすべての情報を閲覧可能とする）。

ステップ１１０７において、ステップ１１０６でアクセスが許容されることが判定されると、顧客情報が開示され処理は終了する。

図１２は、本発明の別の実施形態に係る、ストラクチャードファイナンスにおける例示的な実施形態の全体像を説明する図である。本実施形態において、下記の関連当事者を含むプロジェクト融資の実行を例に挙げて説明する。
債務者：ロンドンに本社を置く特定目的会社Ａ １２０１
スポンサー（出資比率５０％以上：実質同一債務者）：ニューヨークに本社を置くＢ社 １２０２
建設業者（関連与信先）：東京に本社を置くＣ社 １２０３
販売先（関連与信先）：ニューデリーに本社を置くＤ社 １２０４
債務者であるＡ社 １２０１により、第１国である英国に配置される、第１国のエンティティ１２１０に融資の相談がされる。なお、ニューヨークに本社を置くＢ社１２０２の顧客情報は、第２国である米国に配置される第２国エンティティ１２４０により管理されている。Ｃ社１２０３の顧客情報は、第３国である日本に配置される第３国第２のエンティティ１２３０により管理されている。そして、Ｄ社１２０４の顧客情報は、第４国であるインドに配置される第４国エンティティ１２５０により管理されているものとする。そして、稟議書の決裁は、第３国である日本に配置される第３国第１のエンティティ１２２０で行われる。

図１３は、本発明の別の実施形態に係る、ストラクチャードファイナンスにおける例示的な業務フローを示す図である。

第１国のエンティティ１２１０、第２国エンティティ１２４０、第３国第２のエンティティ１２３０、第４国エンティティ１２５０において、図１２の業務フローに沿った、各役割に応じた業務が発生する。第１国のエンティティ１２１０のフロントの役割を有する者によって、特定目的会社Ａ１２０１の顧客情報の作成または更新、案件情報および複数当事者案件情報の作成、リスクファクター登録、および稟議書が作成され、第３国第１のエンティティ１２２０において稟議書の決裁がなされる。その後、第１国のエンティティ１２１０において、契約書の作成がなされ、ミドルバックの役割を有する者によって、徴求書類のチェックおよび枠の登録が行われ、全ての手続きが円滑に進めば、バックの役割を有する者によって最後に貸出が実行される。この際、各職務に応じた権限を有する者が、割り当てられた職務を遂行するにあたり、顧客情報を参照する必要がある。あるストラクチャードファイナンス型の融資については、与信判断を行う際に、各拠点におけるフロント、ミドルバックなどの担当職務及び権限を有する者は、案件情報管理データベース２３１に登録された案件情報を参照し、さらに、当該案件情報に関連づけられた関係当事者情報を参照する必要がある。

本例においては、Ａ社からＤ社の顧客の情報はそれぞれ、第１国のエンティティ１２１０、第２国エンティティ１２４０、第３国第２のエンティティ１２３０、第４国エンティティ１２５０によって管理されている。そのため、第１国のエンティティ１２１０に所属するフロント職位のユーザーは、他店（第２国エンティティ１２４０、第３国第２のエンティティ１２３０、および第４国エンティティ１２５０）で管理される顧客情報（本例においては関係当事者情報）をチェックのうえ、稟議書などの作成を行わなければならない。一方、第２国エンティティ１２４０、第３国第２のエンティティ１２３０、および第４国エンティティ１２５０に所属するフロント職位のユーザーは、それぞれの顧客情報を更新し、その情報を関連当事者登録に反映させなければならない。関係当事者情報と顧客情報は連携が取られているため、各エンティティによって顧客情報が更新されると、関係当事者情報も更新される。また逆に、各エンティティによって関係当事者情報が更新されると、対応する顧客情報も更新される。

第１国のエンティティ１２１０に属する、フロントの職位を有するユーザーに対するアクセス制御フローを例に挙げて次の図で説明する。

図１４は、本発明の別の実施形態に係る、本発明において行われる処理の流れを説明するフローチャートである。先に述べたように、図１２の事例に基づき、第１国に配置される第１国のエンティティ１２１０に所属する、フロントの職位を有するユーザーが、他店（第２国エンティティ１２４０、第３国第２のエンティティ１２３０、および第４国エンティティ１２５０）で管理される顧客情報にアクセスする際のアクセス制御フローを例に挙げて説明する。

ステップ１４０１において、ユーザーが自身の所属するエンティティグループの銀行システム１５００にログインする。例えば、ログインする銀行システム１５００は、グローバル与信管理システム１０００と連携がなされてさえいれば、全てのエンティティグループで共通のシステムでもよいし、国ごとやエンティティグループごとに分離されたシステムであっても良い。

ステップ１４０２において、ユーザー情報連携およびアクセス可否判定部２１０は、ユーザー情報４００を参照して、ログインで用いられたユーザーＩＤに対応する、職務、所属エンティティＩＤ、所属エンティティグループＩＤを判定する。

ステップ１４０３において、ユーザーは、与信条件などを判断し、与信稟議書を作成するために、案件情報管理データベース２３１に登録された案件情報、当該案件情報に関連づけられた関係当事者情報（本例においては、Ａ社からＤ社の情報）にアクセスする。本ステップにおいて、ユーザー情報連携およびアクセス可否判定部２１０は、顧客情報管理部２２０、案件情報管理部２３０、複数当事者案件情報管理部２４０と連携して、当該顧客情報（Ａ社からＤ社の情報）を主に管理するエンティティおよび関係者の登録種別を判定する。本例において、例えば、Ｄ社１２０４の顧客情報を参照するものとして説明する。ユーザー情報連携およびアクセス可否判定部２１０は、顧客情報６００を参照して、当該アクセスに係わる顧客情報を管理するエンティティを判定する。また、ユーザー情報連携およびアクセス可否判定部２１０は、関係者の登録種別（本例においては、関連与信先とする）を判定する。さらに、ユーザー情報連携およびアクセス可否判定部２１０は、顧客情報６００を参照して、アクセスすることを要求されている顧客情報の情報種別および情報項目ＩＤを判定する。なお、本ステップまたは以下のステップにおいて、ユーザー情報連携およびアクセス可否判定部２１０が、顧客情報６００等を参照する構成ではなく、顧客情報管理部２２０等に要求を提出して、顧客情報管理部２２０等が顧客情報６００等を参照する構成を採用してもよい。

ステップ１４０４において、ユーザー情報連携およびアクセス可否判定部２１０は、各国法規制の類型情報８００およびエンティティ情報５００を参照して、顧客情報を管理するエンティティの法規制類型を判定する。本例においては、当該アクセスすることを要求されている顧客情報を管理するエンティティの法規制の類型は１であるとする。

ステップ１４０５において、アクセスを試みるユーザーの所属するエンティティと顧客情報を管理するエンティティとの関係に基づき、各国法規制の要件をクリアしているか判定する。本例において、ステップ１４０４において判定された法規制類型によれば、ログインユーザーの所属するエンティティが、顧客情報を管理するエンティティと、ｉ）同一のエンティティグループに属し、且つ、ｉｉ）同一の国に所在することが求められる。ユーザーの所属する第１国第１のエンティティ１２１０は、顧客情報を管理する第４国エンティティ１２５０と、同一のエンティティグループに属するが（上記ｉ）条件クリア）、一方で、同一の国には属さない（上記ｉｉ）条件はクリアしない）。したがって、ステップ１４０６に遷移する。

ステップ１４０６において、ユーザー情報連携およびアクセス可否判定部２１０は、顧客Ｄ１２０４から顧客情報の開示について、同意を得ているか判定する。顧客の同意に関しては、全顧客情報に対する包括的な同意でもよいし、情報種別ごとの同意、または情報項目ごとの同意であってもよいことは言うまでもない。同意が得られていない場合、ステップ１４０７においてアクセス拒否判定がなされ、処理が終了する。

ステップ１４０８において、ユーザー情報連携およびアクセス可否判定部２１０は、顧客情報の種別ごとのアクセス権限テーブル７００を参照して、ログインユーザーＩＤに関連づけられた職務で、顧客情報にアクセス可能か判定する。本例においては、アクセスを試みるユーザーの所属する第１国のエンティティ１２１０は、顧客情報を管理する第４国エンティティ１２５０と、同一のエンティティグループに属する。そして、例えば、アクセスを試みる顧客情報種別が基本情報（情報項目ＩＤ：Ｂ０００１）であって、顧客Ｄ１２０４の関連者の登録種別は関連与信先であるとする。ユーザー情報連携およびアクセス可否判定部２１０は、顧客情報の種別ごとのアクセス権限テーブル７００における同一エンティティグループの他部店の関係与信先欄を参照する。そして、ユーザー情報連携およびアクセス可否判定部２１０は、フロントの職務を有するユーザーのアクセスが許容されることを判定する。

ステップ１４０９において、ステップ１４０８でアクセスが許容されることが判定されると、顧客情報が開示され処理は終了する。

さらに、変形例として、ユーザーが、顧客Ｂ社１２０２（関係当事者情報）を参照する例をさらに説明する。ステップ１４０３までは同じである。ステップ１４０４において、ユーザー情報連携およびアクセス可否判定部２１０は、各国法規制の類型情報８００およびエンティティ情報５００を参照し、顧客Ｂ社１２０２の顧客情報を管理する第２国エンティティ１２４０の所在国の法規制の類型は３であると判定したとする。

ステップ１４０５において、ユーザー情報連携およびアクセス可否判定部２１０は、アクセスを試みるユーザーの所属するエンティティと顧客情報を管理するエンティティとの関係に基づき、各国法規制の要件をクリアしているか判定する。本例において、ステップ１４０４において判定された法規制類型によれば、エンティティグループおよび国を超えて共有可であるため、ステップ１４０８に遷移する。

ステップ１４０８において、ユーザー情報連携およびアクセス可否判定部２１０は、顧客情報の種別ごとのアクセス権限テーブル７００を参照して、ログインユーザーＩＤに関連づけられた職務で、顧客情報にアクセス可能か判定する。本例においては、アクセスを試みるユーザーの所属する第１国のエンティティ１２１０は、顧客情報を管理する第２国エンティティ１２４０と、同一のエンティティグループに属する。そして、例えば、アクセスを試みる顧客情報種別が基本情報（情報項目ＩＤ：Ｂ０００１）であって、顧客Ｂ社１２０２は、当該プロジェクトにおける、関係者の登録種別は、実質同一債務者である。したがって、ユーザー情報連携およびアクセス可否判定部２１０は、顧客情報の種別ごとのアクセス権限テーブル７００の、同一エンティティグループ取引先の他部店の実質同一債務者欄を参照する。そして、ユーザー情報連携およびアクセス可否判定部２１０は、フロントの職務を有するユーザーのアクセスが許容されることを判定する。

このように、本発明は、顧客ごとに管理された顧客情報に限らず、案件ごとに管理された案件情報を閲覧する際のアクセス制御に適用することも可能である。

図１５は、本発明の一実施形態に係る、銀行システム１５００とグローバル与信管理システム１０００の構成の一例を示す。

各拠点における銀行システム１５００は、認証サーバー１５３０と、業務サーバー１５２０と、行員が各業務に使用する端末１５４０などを有する。これらのサーバーおよび端末は例示であって、その他種々多様なサーバー、端末群が存在していてもよいことは言うまでもない。銀行システム１５００は、国ごと、エンティティグループごとに異なっていてもよいし、統一されたシステムでも良い。また、本例においては、銀行システム１５００とグローバル与信管理システム１０００を別のシステムとして説明したが、統一された同一のシステムとして設計してもよいことは言うまでもない。銀行システム１５００とグローバル与信管理システム１０００は、行内ネットワークまたはインターネット１５５０を介して接続される。グローバル与信管理システム１０００は、１または複数のサーバーコンピューターおよびデータベースなどで構成される。

銀行システム１５００およびグローバル与信管理システム１０００を構成する、各端末１５４０、サーバーコンピューターは、ＲＯＭ１５０１、ＲＡＭ１５０２、記憶部１５０３（磁気ストレージデバイス、またはその他あらゆる媒体であって、情報を保存することに用いられ、且つ、アクセスされ得る媒体）、通信部１５０４、入力部１５０５、表示部１５０６、及びＣＰＵ１５０７などを備える。これに限られず、本技術分野で知られた様々なハードウェアを内蔵あるいは接続することができる。また、端末１５４０や各種サーバーには、ＯＳや様々なドライバーまたはアプリケーションがインストールされ、本発明における実施形態の様々の処理を全体として実行する。

本明細書および図面において開示される実施形態は一例にすぎず、本発明の技術的範囲を定める際に、本開示の内容に限定して解釈されるべきではない。説明のため、各処理部を、それぞれ分けて記載したが、それぞれの機能を統合、連携させ、それぞれが有する機能の一部または全部を他方に持たせてもよい。本実施形態で開示されるデータベース群も、それぞれが有するデータの一部または全部を他方に持たせ、統合、連携さてもよい。

以上説明したように、本発明によれば、全拠点の行員が共通利用可能なシステムにおいて、共通の枠組みの中で情報を連携し、国ごとに異なる法規制を順守しつつ、適切なアクセス制御を行い適切な人に適切な情報を公開することが可能になる。

Claims (8)

1. グローバル与信管理システムによって実行される、情報へのアクセス制御方法であって、
   ユーザーのログインＩＤを受信するステップと、
   前記ログインＩＤに関連づけられた職務および前記ユーザーの所属するエンティティを判定するステップと、
   前記ユーザーがアクセスを試みる情報に対するアクセス可否を判定するステップであって、前記アクセス可否の判定は、
   ａ）前記ユーザーがアクセスを試みる情報を管理するエンティティを判定するステップと、
   ｂ）前記ユーザーがアクセスを試みる情報を管理するエンティティに関連づけられた、法規制に基づくアクセス制御パターンを判定するステップと、
   ｃ）前記ユーザーの所属するエンティティと前記ユーザーがアクセスを試みる情報を管理するエンティティとの関係に基づき、前記法規制に基づくアクセス制御パターンを満たしているか判定するステップと、
   ｄ）前記ログインＩＤに関連づけられた職務で前記ユーザーがアクセスを試みる情報にアクセス可能か判定するステップと、
   に基づいて行われる、ステップと
   を有するアクセス制御方法。
2. 前記情報は、前記情報の内容に基づいて区分けされ、前記区分けされた情報ごとにアクセス可能な職務が割り当てられている、請求項１のアクセス制御方法。
3. 前記ユーザーの所属するエンティティと前記情報を管理するエンティティとの関係に基づき、前記法規制に基づくアクセス制御パターンを満たしているか判定する前記ステップｃ）は、
   ｃ−１）前記ユーザーの所属するエンティティが、前記情報を管理するエンティティと、同一のエンティティグループに属し且つ同一の国に所在する場合のみアクセス可能と判定することと、
   ｃ−２）前記ユーザーの所属するエンティティが、前記情報を管理するエンティティと、同一のエンティティグループに属する場合のみアクセス可能と判定することと、
   
   ｃ−３）前記ｃ−１）ないしｃ−２）のいずれかに該当しても、顧客の同意があればアクセス可能と判定することと、
   のうちいずれか１つを有する、請求項１または２のアクセス制御方法。
4. 前記情報は、顧客の顧客情報および前記顧客に関する与信の案件情報のうちの少なくとも一方を含む請求項１ないし３のいずれか１項に記載のアクセス制御方法。
5. ストラクチャードファイナンス型の融資についての与信判断に際し、
   前記ユーザーがアクセスを試みる情報は、前記ストラクチャードファイナンス型の融資に係わる関係者登録された顧客情報であって、
   前記ユーザーがアクセスを試みる顧客情報に対するアクセス可否を判定するステップにおいてさらに、
   前記ユーザーがアクセスを試みる顧客情報の前記ストラクチャードファイナンス型の融資に係わる関係者登録種別を判定するステップと、
   前記判定された関係者登録種別に割り当てられた職務を判定するステップと、
   前記ログインＩＤに関連づけられた職務は、前記判定された関係者登録種別に割り当てられた職務を満たすか判定するステップと、
   を有する、請求項１のアクセス制御方法。
6. 前記関係者の登録種別は、少なくとも、債務者、実質同一債務者、関連与信先、関連当事者から構成される、請求項５のアクセス制御方法。
7. 請求項１ないし６のいずれか１項に記載の方法を実行するサーバーコンピューターを備えたグローバル与信管理システム。
8. グローバル与信管理システムのサーバーコンピューターに、請求項１ないし６のいずれか１項に記載の方法を実行させるためのプログラムを有するプログラム記憶媒体。

Images