CN107615325A - 用于公司融资的海外信贷管理的银行系统、方法以及程序 - Google Patents

Abstract

用于公司融资的海外信贷管理的银行系统具备：第一储存单元，储存可被多个实体共有的客户信息；第二储存单元，储存与信贷交易的管理单位(Deal)有关的信息；批准单元，批准请示书中所记载的信贷交易的执行，并且具有请示书的制作时的客户信息以及Deal信息，在请示书的批准时生成第一信号；以及控制卡生成单元，响应于第一信号来生成控制卡，其中控制卡表示被批准的信贷交易的关联业务的进展状况。Deal信息具有一个或多个信贷行的信息以及一个或多个债务人的信息。债务人与客户信息建立关联。与客户信息以及信贷交易的管理单位有关的信息由第一实体来进行维护。

Description

用于公司融资的海外信贷管理的银行系统、方法以及程序

技术领域

本发明涉及一种用于公司融资(corporate finance)的海外信贷管理的银行 系统、方法以及程序。更详细而言，本发明涉及一种用于公司融资的海外信贷 管理的银行系统、方法以及程序，其具有可被多个实体共有的客户信息，并具 有与能处理一个或多个信贷行以及一个或多个债务人的信贷交易管理单位有关 的信息，且能识别信贷交易的关联业务的进展状况。

背景技术

近年来，随着海外的商业规模的扩大，银行中的海外信贷余额、债务人数 量以及债务人的所在国以及地域的数量增加。许多企业为了扩大商业机会而在 多个国以及地域设置子公司或者分行，并且/或建设工厂。在这样的状况下， 在国际上活动的大银行在与这样的企业进行交易时，多通过此银行的海外分行 或与此银行相关联的当地法人来给此企业进行融资。例如，某一企业可能会将 用于在欧州的A国建设工厂的资金的融资委托给此银行的A国的分行。另一企 业由于在东南亚的B国具有总公司，因此，可能向B国的此银行的分行进行融 资的委托，并从此银行的C国的分行领取用于在东南亚的C国建设工厂的资金。在这些案例中，通常不会仅通过进行融资的申请的国家的分行或当地法人来完 成信贷关联业务，而是由多个国家的分行、总部来共有信息并进行信贷关联业 务。银行的总部一般而言设于此银行的本国，但也可能在其他国家以及地域设 立总部。作为一例，一些大银行将世界划分为多个地域，并在各地域设立总部 (例如，欧州总部、亚洲大洋州总部、美洲总部、以及同样的总部)来管理此 地域内的各国的分行、当地法人。

如前所述，在与公司融资关联的信贷业务中，涉及到多个国家以及地域的 分行、当地法人、以及总部的案例增加。另一方面，银行除了公司融资以外， 也多会处理结构性融资(structured finance)。结构性融资不基于企业的信用度， 而是基于某一特定的事业的保有资产以及从其事业所产生的资金流(cash flow) 的融资(finance)，例如，能包含对由利益相关者所设立的有特殊目的公司(SPC： special purpose company)进行融资。SPC为由参与某一项目(例如，油田开发 等)的多个企业来出资并设立的纸上公司(paperCompany)，SPC成为该融资 的债务人。参与项目的多个企业作为利益相关者来参与此项目，但却不是债务 人。在国际上活动的银行中，这样的结构性融资的案件数量日益增加。

银行经过很多年开发出了各种银行系统。在作为客户的企业的活动地域仅 为国内的情况下，银行已经形成用于客户信息管理的系统、用于进行融资判断 的裁决系统、以及用于信贷管理的系统，这些系统被运用为国内用的银行系统。 如前所述，随着企业的活动扩大到全球范围，银行系统被要求要满足在全球活 动的企业的需求。对在全球开展商业的企业的公司融资的案件数量以及结构性 融资的案件数量增加，并且海外的总部、分行以及当地法人的数量增加的状况 下，银行需要构建一种能处理公司融资以及/或结构性融资、且可供银行内的 多个办公室参与的新系统。

专利文献1公开了一种仅在多个国家之间进行资金裁决的系统，专利文献2 公开了一种用于结构性融资的申请的系统。如此，在以往的银行系统中，只不 过公知有把重点放在海外业务的特定的业务上的系统，而并不存在一种用于进 行海外信贷中的客户信息管理、案件管理、以及融资判断等的系统。

在以往的银行系统中，在某一公司的业绩急剧恶化时，在提取与此公司建 立关联的融资案件时，相应地需要时间。在发生世界范围的金融危机(例如， 雷曼冲击)时，或某一项目产生巨大的损失时，在以往的银行系统，在提取受 到这样的事件的影响的企业时，相应地需要时间。在发生某一事件(例如，原 油价格的下跌)的情况下，在以往的银行系统，提取因这样的事件而企业业绩 恶化的企业是困难的。

现有技术文献

专利文献

专利文献1：日本特开2005-276012号公报

专利文献2：日本特开2002-352087号公报

发明内容

本发明的目的在于提供一种可供银行内的多个办公室参与的、用于公司融 资的海外信贷管理的银行系统，其能提供信贷关联业务的进展状况，并且能提 取与特定的客户建立关联的融资案件。

作为本发明的一方案的用于公司融资的海外信贷管理的银行系统具备：第 一储存单元，储存客户信息，其中所述客户信息可被多个实体共有；第二储存 单元，储存与信贷交易的管理单位有关的信息，其中与所述信贷交易的管理单 位有关的信息具有一个或多个信贷行的信息以及一个或多个债务人的信息，所 述债务人与所述客户信息建立有关联；批准单元，批准请示书中所记载的信贷 交易的执行，其中所述批准单元具有与所述请示书的制作时的所述客户信息以 及所述信贷交易的管理单位有关的信息，在所述请示书的批准时生成第一信号； 以及控制卡生成单元，响应于所述第一信号来生成控制卡，其中所述控制卡表 示所述被批准的信贷交易的关联业务的进展状况。与所述客户信息以及所述信贷交易的管理单位有关的信息由第一实体来进行维护。

作为本发明的另一方案的在用于公司融资的海外信贷管理的银行系统中所 执行的方法具备：更新客户信息的步骤，其中所述客户信息可被多个实体共有； 更新与信贷交易的管理单位有关的信息的步骤，其中与所述信贷交易的管理单 位有关的信息具有一个或多个信贷行的信息以及一个或多个债务人的信息，所 述债务人与所述客户信息建立有关联；响应于请示书的制作来取得与所述客户 信息以及所述信贷交易的管理单位有关的信息的步骤；响应于所述请示书中所 记载的信贷交易的批准来生成第一信号的步骤；以及响应于所述第一信号来生 成控制卡的步骤，其中所述控制卡表示所述被批准的信贷交易的关联业务的进 展状况。与所述客户信息以及所述信贷交易的管理单位有关的信息由第一实体 来进行维护。

根据本发明，银行系统基于业绩差的公司的客户ID来检索Deal信息或SL 信息，由此，能提取与此公司建立关联的融资案件。根据本发明，某一项目产 生巨大的损失时，银行系统能基于SL信息来识别相关当事人，并提取所识别到 的各相关当事人的融资案件。根据本发明，银行系统能提供信贷关联业务的进 展状况。

附图说明

本说明书中所公开的实施方式的详细理解能根据与附图关联地举例示出的 以下的说明来得到。

图1是表示银行系统和多个银行终端、以及将银行系统以及多个银行终端 可通信地连接的网络的图。

图2是对银行系统的系统结构进行说明的图。

图3是客户信息管理子系统的功能框图。

图4是案件信息管理子系统的功能框图。

图5是用户管理子系统的功能框图。

图6是裁决子系统的功能框图。

图7是信贷管理子系统的功能框图。

图8A是表示第一案例中的信贷关联业务的流程的图。

图8B是对第一案例中的操作的流程进行详细说明的流程图。

图9A是表示第二案例中的信贷关联业务的流程的图。

图9B是对第二案例中的操作的流程进行详细说明的流程图。

图10A是表示第三案例中的信贷关联业务的流程的图。

图10B是对第三案例中的操作的流程进行详细说明的流程图。

图11是表示结构性融资的一例的图。

图12是对在银行系统内进行的访问控制的处理流程的一例进行说明的图。

图13是表示请示书的例示性的格式的图。

图14是表示例示性的风险因素的登录画面的图。

图15是表示控制卡的一例的图。

具体实施方式

＜术语的定义＞

对本说明书中所使用的以下的术语的意思进行定义。

海外信贷：银行的海外分行或与此银行关联的当地法人对此银行的客户进 行的融资。作为与信贷相当的用语，存在贷款(facility)和敞口(Exposure)。 在指单个的信贷时使用前者，在指对客户的信贷的整体时使用后者。

海外信贷管理：在海外信贷中管理融资对象的企业的信用状况。

信贷行(Lending Office)：承担信贷的责任的分行或当地法人。在与多个 分行或当地法人为一个的客户交易的案例中，主信贷行(PLO：Primary Lending Office)是指集中管理客户信息并进行债务人评价的办公室(Office)，次级信 贷行(SLO：SecondaryLending Office)是指主信贷行以外的办公室(Office)。

全球企业：向多个地域开展业务的企业，且需要由多个信贷行进行管理的 企业。

SL(Specialized Lending)：与结构性融资(SF)大致同义。在本说明书中， SL和SF能交换使用。

在本说明书中，对在银行1中所进行的信贷管理方案以及用于执行此方案 的系统进行说明。银行1能在多个国以及地域具有分行以及与银行1建立关联 的当地法人。银行1能将世界划分为多个地域并在各个地域设立总部(例如， 欧州总部、亚洲大洋州总部、美洲总部、以及同样的总部)来管理此地域内的 各国的分行、当地法人。总部、分行、以及当地法人可以被称为“实体”。

图1是表示可由银行1所使用的银行系统10和多个银行终端20、以及将银 行系统10和多个银行终端20a、20b、···20n(在本说明书中，统称为“银 行终端20”)可通信地连接的银行内部网络或者互联网30(在本说明书中，称 为“网络30”)的图。银行系统10是能处理存款业务、贷款业务、国内汇兑业 务、国外汇兑业务、以及同类的业务的系统。为了达到说明的目的，在本说明 书中，对银行系统10的主要的功能中的与对在一个或多个国以及地域开展事业 的企业进行的信贷管理关联的功能以及处理进行说明。

银行终端20是经由网络30来访问银行系统10，并能利用由银行系统10所 提供的功能的终端。银行终端20可以是可供银行员利用的终端，但不作特别限 定。例如，银行终端20能包含个人计算机(PC)、笔记本电脑、平板电脑终端、 或者可在有线或无线环境下工作的其他任意类型的设备。网络30可以是包含互 联网、专用线路等的、可相互通信的公知的网络，不作特别限定。

图2是对银行系统10的系统结构进行说明的图。银行系统10能具备处理 器21、主存储装置22、辅助存储装置23、接口装置24以及输出装置25。装置 21至25可通过总线26等相互连接。

处理器21能进行银行系统10内的各组成部分(component)的控制以及数 据的运算，并能将储存在辅助存储装置23的各种程序读出至主存储装置22并 执行。主存储装置22能存储各种收发数据、计算机可执行命令、以及由该命令 来进行的运算处理后的数据。辅助存储装置23是HDD(Hard Disk Drive：硬盘 驱动器)或SSD(Solid State Drive：固态硬盘)等存储装置，能长期保存数据、 程序。

图2对将处理器21、主存储装置22、以及辅助存储装置23设于同一计算 机内的实施方式进行说明。在本发明的另一实施方式中，银行系统10也可以构 成为：使用多个处理器21、主存储装置22、以及辅助存储装置23，由此，通过 多台计算机实现并行分散处理。在本发明的另一实施方式中，也可以采用如下 实施方式：设置多台计算机来用于银行系统10，且多台计算机共有一个辅助存 储装置23。

接口装置24起到在与其他的系统、装置之间进行数据的收发时的接口的作 用。接口装置24能提供用于从系统操作员接收各种命令、输入数据(例如，各 种主文件(masterfile)的数据)的接口。输出装置25能显示由处理器21处理 后的数据以及/或者各种数据库、从文件读出的数据。输出装置25能提供用于 打印显示在显示器的数据的功能。

如图1所示，银行系统10能具备客户信息管理子系统11、案件信息管理子 系统12、用户管理子系统13、裁决子系统14、以及信贷管理子系统15。

子系统11至15能具备可通过总线等相互连接的处理器、主存储装置、辅 助存储装置、接口装置、以及输出装置，这些装置能具有与装置21至25相同 的功能。

客户信息管理子系统11用于管理信贷管理过程中所使用的客户信息。本发 明中所使用的客户信息不是按信贷行，而可以被银行内部的多个部门以及信贷 行利用，与以往的CIF(customer information file)中的客户信息不同。CIF中的 客户信息由各信贷行来制作并进行维护。在某一特定的企业与银行内部的多个 信贷行存在交易的情况下，由于各信贷行都制作并维护客户信息，因此，在银 行1内并未进行集中化的信息管理。在本说明书中，为了与以往的CIF区别， 将客户信息称为“公司卡(corporate card)”。

案件信息管理子系统12用于管理与融资有关的案件信息(Deal)。案件信 息管理子系统12能处理公司融资以及结构性融资这两方的Deal。Deal能包含作 为客户的企业的资金需求的背景和理由、以及资金的用途和融资期限等的事实 信息。

用户管理子系统13能提供控制可被登录用户访问的系统功能和数据的访问 控制功能、以及监控用户日志的检查功能。访问控制功能能实现：仅特定的用 户能访问特定的系统功能、数据。检查功能能对在银行系统10内所进行的用户 操作中的特定的操作的日志进行收集且储存。可预定应收集日志的特定的操作。

裁决子系统14是制作与海外信贷有关的请示书并提交给相关部门，并且从 裁决权限人得到批准的系统。裁决子系统14能预先保持审查请示书的内容的时 间点的公司卡以及Deal。所保持的公司卡以及Deal可以设为请示书的制作开始 时间点以及/或裁决时间点。裁决子系统14能在从某一实体向另一实体提交请 示书时生成并储存请示书的复本。

信贷管理子系统15能支持信贷业务管理，且能强化相关部门以及信贷行间 的协同和内部管理。信贷管理子系统15能提供核对融资执行前的业务、以及融 资执行后的业务是否被适当地执行的功能。

图3是客户信息管理子系统11的功能框图。客户信息管理子系统11能具 备客户信息31、财务信息32、财务分析33、信贷监控(monitoring)34、交易 银行35、以及竞争比较36。元素(element)31至36是在银行系统10内共有的 数据，可以统称为“公司卡”。由于公司卡能由多个部门以及信贷行共有，因 此，是与以往的CIF不同的客户信息。

客户信息31为客户的简况，例如可以包含客户ID、公司的名称、总公司的 所在地、设立年份、从业人数、工厂以及/或分行的所在地(国家以及城市名)、 股份信息、股东、集团结构、经营史、与银行1的关系、关键人物、业务划分、 按地域分部、主要客户、主要供应商等属性信息。

财务信息32可以包含客户的损益计算书、借贷对照表、资金流计算书、以 及这些财务信息的元数据。财务信息32能包含多年的数据。财务信息32能包 含实绩以及预测数据。

财务分析33能包含基于储存在财务信息32的信息的分析结果。财务分析 由银行1的负责人来进行，其分析结果能在信贷判断中被利用。

信贷监控34能包含债务人的信用评级、债务人的状态(优良、注意等)、 债务人的等级(高级、中级、低级等)等监控信息。监控信息的内容能基于由 银行1所规定的基准来决定，并且/或者能采用从评级公司所取得的信息。

交易银行35能包含债务人借入资金的所有的金融机构、以及各从金融机构 借入的金额等信息。竞争比较36能储存债务人的竞争公司的信息(例如，财务 信息)。竞争公司的选择基于相同事业领域的他的债务人的信息决定，或者由 银行1的负责人来决定。

对储存在元素31至36的信息进行的访问控制由用户管理子系统13来进行。 该访问控制在确定了所参照的信息后，依据以下内容来进行：访问用户的所属 组织、信贷职位以及职能的信息、管理客户数据的实体所在的国家以及地域的 合规(compliance)信息、以及客户是否同意其他实体参照客户数据的信息。客 户信息管理子系统11能具有客户是否同意共有储存在元素31至36的信息的信 息。实体能表示银行1的总部的各部门、分行、与银行1建立关联的当地法人。

图4是案件信息管理子系统12的功能框图。案件信息管理子系统12能处 理用于信贷交易的管理单位(Deal)的信息。案件信息管理子系统12能具备Deal 简况(DealProfile)41、信贷明细信息42、担保明细信息43、以及SL信息44。 元素41至44可以统称为“Deal信息”。案件信息管理子系统12与以往的银行 系统不同，可处理多个信贷行所参与的交易、以及/或多个债务人所参与的交 易。

Deal简况41能储存案件信息的简况。储存在Deal简况41的信息能使用案 件信息的标识符(Deal号码)来与储存在信贷明细信息42以及担保明细信息43 的信息建立关联。

Deal简况41能包含基本信息411(Deal号码、Deal名、Deal所有者、一个 或多个信贷行、一个或多个债务人)、Deal概要(summary)412、Deal背景 (background)413、放款结构(structure)414、以及支援分担415(未图示)。

基本信息411能包含用于识别Deal的Deal号码、表示Deal的名称、一个 或多个信贷行、以及一个或多个债务人的客户ID。Deal概要412能包含交易的 概要。例如，Deal概要412能包含以下信息：“融资的目的在于面向将总公司 设置在印度的事业公司的运转资金。放款期限为1年，融资额为1千万美金。 分别由新德里(NDL)以及新加坡(SNG)的信贷行各进行500万美金的融资”。

Deal背景413能包含进行该融资的背景事项以及理由。放款结构414能包 含对融资的方案进行说明的图、以及其说明文字。在多个金融机构进行融资的 案例的情况下，支援分担415能表示各金融机构的支援比例(例如，A银行40％、 B银行35％、C银行25％)。

信贷明细信息42能包含明细号码、债务人、信贷的种类、通货、放款金额 等融资的详细信息。担保明细信息43能包含该Deal的担保的详细信息。在多个 信贷行参与Deal的情况下，信贷明细信息42能表示将由各信贷行所设定的限额 加在一起的合计限额。信贷明细信息42以及担保明细信息43能包含多个债务 人的信息。

在融资的种类为结构性融资(例如，用于某一项目的对有特殊目的公司 (SPC)进行的融资)的情况下，SL信息44在SL(Specialized Lending)储存 特有的信息。在图11中示出结构性融资的一例。在图11中，执行用于火力发 电厂建设的项目的SPC由项目的相关当事人来设立。银行团对该SPC进行融资。 作为资助人的B公司以及C公司进行技术支持以及销售支持。作为电力的经销 商的D公司签订售电合同，并从火力发电厂购入电。作为燃料供给人的E公司 向火力发电厂供给燃料。作为发电厂的建设者的F公司建设火力发电厂。如图11所示，结构性融资是基于某一特定的事业的保有资产以及从其产业所产生的 资金流的融资，能供多个利益相关者参与。

SL信息44能包含SL号码421、资产(asset)简况422(项目概要、结构、 里程碑(milestone)等)、合同书号码423、财务信息424、以及一个或多个相 关当事人425(未图示)。

SL号码421是识别结构性融资的号码。资产简况422能包含项目的概要、 方案(结构)、计划(schedule)以及里程碑等信息。合同书号码423表示与结 构性融资建立关联的合同书的识别信息。财务信息424表示项目的财务信息(损 益计算书、借贷对照表、资金流计算书等)。

相关当事人425能包含项目的一个或多个利益相关者(stakeholder)，利益 相关者由客户信息31的客户ID来表示。相关当事人425能包含利益相关者在 项目中的职能。例如，职能能包含借方、保证人、资助人、原资产所有者、买 方、卖方、以及同样的职能。在可供多个当事人参与的结构性融资中，例如， 管辖SPC的信贷行能对SL信息44进行维护。能通过利用相关当事人425来识 别参与项目的一个或多个相关当事人。因此，在项目发生损害的情况下，可确 定受到影响的客户。

图5是用户管理子系统13的功能框图。作为数据库或文件，用户管理子系 统13能具备用户信息51、基于内部信息的访问控制52、对数据以及应用程序 进行的访问控制53、支行间的关系性54、基于信息类别的访问控制55、以及日 志数据56。作为处理组成部分，用户管理子系统13能具备用户信息生成部57 以及日志数据收集部58。

用户信息51能具备可在银行系统10内利用的用户信息以及访问控制信息。 用户信息51能包含用户ID521、所属组织522、信贷职位523、职能524、以及 系统操作权限525(未图示)。

用户ID521是用于识别使用银行系统10以及子系统11至15的用户的ID。 所属组织522表示用户的部门(例如，总部的审查部、新加坡分行的营业部等)。 信贷职位523是用于信贷判断的职位，表示集团经理、分行行长等职位。这些 职位基于正式的人事信息来决定。职能524表示在信贷关联业务中所发挥的职 能(例如前台、前中台、中后台、后台、审查部等)。

系统操作权限525能为了防止用户的不必要的操作而基于用户的部门以及 信贷职位等信息来定义可操作的业务应用程序。例如，在东南亚的某国进行的 融资的请示书被误提交给伦敦的审查部的案例中，由于所属于伦敦的审查部的 人不需要参照这样的请示书，因此，无法访问预定的地域以外的请示书数据。

基于内部信息的访问控制52能储存用于仅许可指定用户对计划合并和收购 (M&A)的企业的公司卡(元素31至36)等秘密信息的访问的设定信息。

关于存在多个债务人等的复杂的交易，对数据以及应用程序进行的访问控 制53能按客户信息管理子系统11内的信息31至36、Deal简况41、以及SL信 息44等信息来包含用户的可否访问信息。

支行间的关系性54能包含其他的部门、需要共有信贷行以及当地法人的客 户信息的部门、信贷行以及当地法人的信息。例如，美洲统括部需要参照与自 身所管理的实体(例如，美国内的分行)建立关联的客户信息。因此，支行间 的关系性54能包含进行参照的实体以及被参照的实体的信息。

在基于信息类别的访问控制55中，可公开的范围根据信息的种类而不同， 因此，能表示与信息的种类对应的公开范围。例如，信息的公开范围根据客户 对信息公开的同意/不同意、管理信息的实体的所在国等而不同，因此，基于 信息类别的访问控制55能包含与客户的同意、实体的所在国有关的信息。

用户信息生成部57能从在银行系统10内利用的人事信息系统提取各用户 的人事信息(所属组织、职位、职能等)，将所提取的人事信息与储存在未图 示的职位表以及变更信息表的信息进行匹配，并生成用户信息51。职位表按各 支行的职务来定义对系统的访问权限，变更信息表定义根据人事的职位来设定 的对默认权限进行变更后的访问权限信息。

日志数据收集部58能收集在银行系统10内进行的用户操作中的特定的操 作的日志。可预先指定应收集日志的特定的操作。例如，当在客户信息管理子 系统11内的客户信息31储存有更新数据时，通过客户信息管理子系统11向用 户管理子系统13发送与此操作有关的日志数据，例如用户的ID、操作时间、操 作终端、操作的种类(增加、修改、删除等)、操作前数据、以及操作后数据。 日志数据收集部58能将所发送的日志数据储存在日志数据56。

参照图12对在银行系统10内进行的访问控制的处理流程的一例进行说明。

在1201中，用户管理子系统13基于登录用户的用户ID521来取得所属组 织522、信贷职位523、职能524、以及系统操作权限525。

在1202中，用户使用银行终端20来尝试访问某一特定的信息。

在1203中，用户管理子系统13确认对被参照的信息进行管理的信贷行所 在的国家或地域的法规制度。例如，在对被参照的信息进行管理的信贷行处于 新加坡的情况下，用户管理子系统13读取被保持在子系统13内的各国的法规 制度中的新加坡的法规制度。法规制度例如存在以下的三个模式。

表1

表1各国的法规制度

如果得到了与信息共有有关的客户同意，则在模式1至3的所有国家都可 跨国家/法人来进行信息共有。在未得到与信息共有有关的客户同意的情况下， 在模式1的国家，仅可进行此国家以及此法人内的信息共有，在模式2的国家， 仅可进行此法人内的信息共有。即使未得到与信息共有有关的客户同意，在模 式3的国家，也可超国家/法人进行信息共有。

在1204中，用户管理子系统13向客户信息管理子系统11进行询问，判定 客户是否同意对被参照的信息进行共有。在存在客户的同意的情况下，处理进 入步骤1206。在不存在客户的同意的情况下，处理进入步骤1205。

在1205中，用户管理子系统13判定对被参照的信息进行管理的信贷行所 在的国家的法规制度的模式。在所判定出的模式为模式3的情况下，处理进入 步骤1206。在所判定出的模式为模式1或模式2的情况下，处理进入步骤1208。

在1206中，用户管理子系统13判定用户是否为了访问信息而具有适当的 职位以及职能。在具有适当的职位以及职能的情况下，处理进入步骤1207。在 不具有适当的职位以及职能的情况下，处理进入步骤1208。

在1207中，用户能访问此信息，并能参照信息。在1208中，用户对此信 息的访问受到限制或者无法访问信息。

在图12中，对基于储存在用户信息51的信息的访问控制进行了说明，但 本发明的访问控制也可以是其他的实施方式。在其他的实施方式中，能安装使 用用户信息51、基于内部信息的访问控制52、对数据以及应用程序进行的访问 控制53、支行的关系性54、以及基于信息类别的访问控制55中的一个或多个 所使用的访问控制。

图6是裁决子系统14的功能框图。作为数据库或文件，裁决子系统14能 具备公司卡61、Deal信息62、请示书63、静态信息64以及合同书65。作为处 理组成部分，裁决子系统14能具备信息取得部66、静态信息生成部67以及送 出部68。

公司卡61能储存起草请示书的时间点的“公司卡”的信息，即客户信息31、 财务信息32、财务分析33、信贷监控34、交易银行35、以及竞争比较36的信 息的复本。

Deal信息62能储存起草请示书的时间点的“Deal信息”，即Deal简况41、 信贷明细信息42、担保明细信息43、以及SL信息44的信息的复本。Deal信息 62可包含状态信息，在请示书被裁决前，状态信息表示为“Pending(未决)”， 裁决后表示为“Fixed(已决)”。

请示书63能储存请示书的数据。请示书能包含请示书ID、图13所示的内 容、以及状态(status)。请示书ID表示请示书的标识符，状态表示审查的状况 (例如，“裁决前”、“已裁决”)。请示书能与公司卡61以及Deal信息62 建立关联。例如，请示书能具有与请示书ID和请示书ID建立关联的公司卡61 的标识符以及Deal信息62的标识符，因此，请示书能与公司卡61以及Deal 信息62建立关联。图13表示请示书的举例示出的格式(format)。该格式能包 含案件的摘要以及结论、融资的期限以及条件的摘要、保证以及担保、收益性、 敞口以及保全状况、Deal简况41以及SL信息44、公司卡61、还款可能性、以 及关键的风险因素的总览。

风险因素表示能影响客户的经营的风险要因(例如原油行情、中东形势、 协作企业、特定的项目等)。银行系统10能利用登记到公司卡、Deal信息的类 型化的风险因素来识别受到影响的Deal以及与此Deal建立关联的客户。

如图13所示，风险因素可被附加在请示书中的债务人评价、案件评价的主 要部分。该格式内的“10.关键风险因素(Key Risk Factor)”能显示所附加的 风险因素。图14表示举例示出的风险因素的登录画面。风险因素的登录画面能 包含风险的类型(例如Commodity)、可成为风险因素的指标(例如WTI)、 考虑到债务人的财务状况以及风险减轻策略的风险程度(例如， High-Middle-Low)、与对风险的内容以及风险的减轻策略有关的信息。

静态信息64能在请示书被某一实体的上司批准后且被送出至其他的实体 前，储存批准时的请示书的静态信息。静态信息可以是PDF数据等。合同书65 能储存在请示书的裁决后制作并签字的合同书的数据。

信息取得部66能从客户信息管理子系统11以及案件信息管理子系统12取 得起草请示书的时间点的“公司卡”以及“Deal信息”。

静态信息生成部67能在请示书被某一部门的上司批准后且被送出至其他的 部门前，生成批准时的请示书的静态信息。更详细而言，在为了批准请示书而 按下批准按钮时，生成请示书的静态信息。所生成的静态信息被储存在静态信 息67。

送出部68能向由请示书的起草者所选择的确认者以及裁决权者通知存在应 该进行确认的请示书。收到通知的确认者以及裁决权者参照储存在请示书63的 请示书的内容，通过任意选择来输入评述(comment)，且登记批准或否认。起 草者能代替确认者以及裁决权者、或者除确认者以及裁决权者以外还选择实体 的名称。在部门的名称被选择的情况下，接收到请示书的部门能选择请示书的 确认者以及批准者。

在本发明的一实施方式中，裁决子系统14也可取得请示书被裁决的时间点 的公司卡的信息以及/或Deal信息。由于公司卡的信息以及/或Deal信息与时 间一同被更新(update)，因此，裁决子系统14能追加取得并保持从请示书的 起草时至裁决时为止的变更信息。

在请示书起草后(例如，按下保存按钮后)，裁决子系统14能向信贷管理 子系统15发送表示请示书的制作的信号。该信号是生成控制卡的触发器 (trigger)。

图7是信贷管理子系统15的功能框图。作为数据库或文件，信贷管理子系 统15能具备公司卡71、Deal信息72、请示书73、合同信息74、以及控制卡75。 作为处理组成部分，信贷管理子系统15能具备信息取得部76以及控制卡(C/ C)生成部77。

信贷管理子系统15能表示需要被执行的信贷业务的进展状况。能基于Deal 信息以及请示书的路线(route)信息来决定进行需要被执行的信贷业务的内容 以及信贷业务的负责部门(职能)。进行信贷业务的负责部门能依据所被分配 的职能来进行信贷业务，并能将其结果输入信贷管理子系统15。

公司卡71以及Deal信息72仅包含公司卡61以及Deal信息62中所含的信 息的一部分。合同信息74能包含与合同书65中所含的信息相同的信息。请示 书73能包含与请示书63的内容相同的内容。

信息取得部66能响应于接收到表示请示书的制作的信号来从公司卡61以 及Deal信息62提取预定的信息，并将所提取到的信息分别储存到公司卡71以 及Deal信息72。信息提取的基准是：是否为信贷业务所需的信息。例如，在信 贷业务的核对所不需要的、融资的背景、企业业绩等信息就不会被储存到公司 卡71以及Deal信息72。

控制卡生成部77响应于从裁决子系统14接收表示请示书的制作的信号、 以及表示请示书的批准的信号来生成控制卡。控制卡生成部77能基于表示请示 书的制作的信号来生成包含在请示书的裁决前进行的信贷业务的控制卡。控制 卡生成部77能基于表示请示书的批准的信号来生成包含在请示书的裁决后进行 的信贷业务的控制卡。所生成的各控制卡可被结合而作为一个控制卡来使用。 在另一实施方式中，控制卡生成部77能响应于表示请示书的制作的信号来生成 一个控制卡，且能根据请示书的批准状况来增加一个控制卡内的确认项目。

控制卡能包含进行需要被执行的信贷业务的内容以及信贷业务的负责部门 (职能)。能基于Deal信息以及请示书的路线信息来决定进行需要被执行的信 贷业务的内容以及信贷业务的负责部门(职能)。例如，在对在美国进行的项 目进行的融资和对在印度具有总公司的事业公司进行的融资中，由于需要被执 行的信贷业务以及负责部门、分行不同，因此，使用不同的控制卡。控制卡在 本说明书中能被称为“C/C”。

图15表示控制卡1500的一例。控制卡1500能包含控制卡号码1501、负责 实体以及职能1502、文档列表(Document list)1503、状态变更按钮1504、以 及信贷业务1505。控制卡1500还能具有关联的请示书ID、公司卡71的标识符、 以及Deal信息72的标识符。

控制卡号码1501是识别控制卡的号码。负责实体以及职能1502能表示应 该承担信贷业务的责任的实体(部门、分行等)以及职能。负责实体以及职能 1502还能表示用户ID以及用户名。

当被用户选择时，文档列表1503会显示与控制卡建立关联的合同书以及关 系文件的列表。当从列表内选择了所希望的数据时，信贷管理子系统15能显示 所选择的数据。

状态变更按钮1504用于在需要被执行的所有的信贷业务都表示为“完成” 的情况下，移至下一个状态。状态能包含“从合同前的准备至合同(Pre-Signing)”、 “执行准备(Post-Signing)”、以及“执行准备完成(Available to Drawdown)”。

在状态为“从合同前的准备至合同(Pre-Signing)”的期间，可能进行合同 内容的检查(或签字前的检查)、签字前所需的征求物(各种文档)以及附带 过程(process)、审查部条件的管理、签字前的担保以及保证的充足确认。

在状态为“执行准备(Post-Signing)”的期间，可能进行事后征求物(各 种文件)的管理、事后的担保以及保证的补充(充足)管理。

在状态为“执行准备完成(Available to Drawdown)”的期间，可进行可执 行结账的状态下的事后征求物(各种文件)的管理、审查部条件的管理、可执 行结账的状态下的事后的担保以及保证的补充管理。

如图15所示，控制卡1500能包含按贷款来区分的的信贷业务，且能表示 各项信贷业务是否完成。具体而言，控制卡1500能包含两项贷款。在图15中， 贷款号码“X111”表示：融资的申请在新加坡进行、处于“从合同前的准备至 合同(Pre-Signing)”阶段、以及融资的名称为“364天内的一连串融资”。作 为与各项贷款关联的信贷业务，控制卡1500能包含“案件(Application)”、 “条件(Condition)”、“期限核对(Terms Check)”、“担保以及保证(Guarantee /Collateral)”、“文档(Document)”、以及“附带过程(Ancillary Process)”。

信贷业务“案件(Application)”表示请示书的形式检查、以及/或请示书 的裁决是否完成。信贷业务“条件(Condition)”表示是否对在请示书的裁决 时由审查部所赋予的条件完成了对应。“期限核对(Terms Check)”表示合同 书中所记载的合同内容的检查是否完成。信贷业务“担保以及保证(Guarantee /Collateral)”表示保证以及/或担保是否充足。信贷业务“文档(Document)” 表示需要的征求物(各种文档)是否已到位。信贷业务“附带过程(Ancillary Process)”表示签字前所需的附带过程是否完成。

如上所述，信贷管理子系统15能具有与各请示书有关的控制卡，控制卡能 表示需要被执行的所有的信贷业务的进展状况。图15所示的控制卡1500仅为 一例，控制卡1500能包含本说明书中所示出的信贷业务以外的内容。

以下，对于使用银行系统10以及子系统11至15来进行的信贷关联业务有 关的多个案例进行说明。这些案例对公司融资以及结构性融资的例进行说明。 在这些案例中，为了便于说明，示出了“前台”、“前中台”、“中后台”、 “后台”、以及“审查部”来作为储存在用户信息51的职能524的一例。如上 所述，用户信息51能包含用户ID521、所属组织522、信贷职位523、职能524、 以及系统操作权限525。

用户信息51的具体例如下所示。例如，某人的所属组织以及职位为新加坡 分行的营业部门的副经理(assistant manager)，此人的职能在从事营业的事务 的工作，因此为前中台。例如，另一人的所属组织以及职位为新加坡分行的融 资事务部门的高级职员(senior staff)，此人的职能在从事融资事务，因此为中 后台。本说明书中所使用的职能以及职位如表2所示，但银行1内的职能以及 职位并不限定于这些。

表2

表2 职能、职位以及工作内容的一例

以下，参照图8A至图10B对用于公司融资的第一以及第二案例和用于结构 性融资的第三案例进行说明。

(第一案例)

参照图8A以及图8B对用于公司融资的第一案例进行说明。第一案例对信 贷关联业务在银行1的仅一个实体(例如，新加坡分行)内完成的情况进行了 例证。在本说明书以及附图中，新加坡也可以简略表示为“SNG”。

图8A是表示第一案例中的信贷关联业务的流程的图。

(1)新加坡的客户ABC法人团体(corporation)在银行1的新加坡分行申 请融资。

(2)新加坡分行的前台响应于受理融资的申请，来维护公司卡，并生成 Deal信息，制作请示书。新加坡分行的前中台检查请示书的形式，确认需要文 件以及需要的手续。新加坡分行的前中台在检查以及确认之后更新控制卡。新 加坡分行的前中台向新加坡分行的亚洲审查部请求请示书的裁决。亚洲审查部 审核(review)请示书，决定放款条件并批准融资。

(3)裁决后，新加坡分行的前台将条件管理以及事务手续委托给新加坡分 行的中后台。新加坡分行的中后台审核被批准的请示书以及合同书。审核后， 新加坡分行的中后台更新控制卡。

(4)审核后，新加坡分行的中后台对新加坡分行内的ABC法人团体的账 户设定信贷限度额。信贷限度额意味着对客户设定的信贷(即，融资)的限度 额。此后，新加坡分行的后台向ABC法人团体的账户打款。

表3表示按上述职能来区分的信贷业务的例，但信贷业务并不限定于这些 业务。

表3

表3 按职能来区分的信贷业务的例子

图8B是对第一案例中的操作的流程进行详细说明的流程图。

在S801中，银行1的新加坡分行的前台能响应于从ABC法人团体受理融 资的申请，来经由银行终端20向客户信息管理子系统11输入最新的客户信息。 客户信息管理子系统11能提供用于输入客户信息的应用程序。所输入的客户信 息可依据信息的内容而被储存在客户信息31、财务信息32、财务分析33、信贷 监控34、交易银行35、以及竞争比较36。

新加坡分行的前台能向案件信息管理子系统12输入ABC法人团体所希望 的融资的概要。案件信息管理子系统12能提供用于输入融资的概要的应用程序。 所输入的信息可依据信息的内容而被储存在Deal简况41、信贷明细信息42、以 及担保明细信息43。储存在信贷明细信息42以及担保明细信息43的信息在被 批准进行该融资前都为挂起(pending)状态。第一案例以公司融资为对象，因 此，未使用到SL信息44。

在S802中，新加坡分行的前台经由银行终端20访问裁决子系统14，制作 请示书。新加坡分行的前台能任意地为公司卡以及Deal信息设定风险因素。裁 决子系统14的信息取得部66能从客户信息管理子系统11取得与此请示书建立 关联的、储存在客户信息31、财务信息32、财务分析33、信贷监控34、交易 银行35、以及竞争比较36的最新数据。所取得的数据被储存在裁决子系统14 内的公司卡61。裁决子系统14的信息取得部66能从案件信息管理子系统12取 得与此请示书建立关联的、储存在Deal简况41、信贷明细信息42、以及担保明 细信息43的最新数据。所取得的数据被储存在裁决子系统14内的Deal信息62。 通过这些处理，裁决子系统14能使请示书的制作时间点的客户的信息以及融资 案件的信息与请示书建立关联。

当请示书的制作完成时(例如，按下保存按钮后)，裁决子系统14能向信 贷管理子系统15发送表示请示书的制作的信号。当该信号由信贷管理子系统15 被接收时，生成包含在请示书的裁决前进行的信贷业务的控制卡。

新加坡分行的前台在裁决子系统14上选择审查所制作的请示书的部门以及 /或人的路线(顺序)。裁决子系统14能与请示书建立关联地记录所选择的路 线并按照路线来转发请示书。新加坡分行的前中台检查请示书的形式，如果完 成了内容的确认，则能在裁决子系统14上登记确认的完成。在请示书被裁决后， 控制卡中的项目“Application”和“Condition”自动地从“未完成”更新为“完 成”。

在S803中，新加坡分行的亚洲审查部能经由银行终端20访问裁决子系统 14并批准所提交的请示书。裁决子系统14能响应于请示书的批准来向信贷管理 子系统15发送表示批准的信号。信贷管理子系统15能响应于接收到该信号来 从裁决子系统14取得客户的信息并储存到公司卡71，并且从案件信息管理子系 统12取得与融资的内容关联的信息并储存到Deal信息72。信贷管理子系统15 能依据被批准的请示书的内容(例如，放款条件等)来动态地生成包含在请示 书的裁决后进行的信贷业务的控制卡，并将所生成的控制卡储存到控制卡75。 在请示书的批准后，新加坡分行的前台依据请示书的内容来制作合同书。所制 作出的合同书在得到签字后被储存到裁决子系统14的合同书65。裁决子系统 14响应于合同书被储存到合同书65来将合同内容发送给信贷管理子系统15， 所发送的合同内容的信息被储存到合同信息74。在被储存到合同信息74的信息 中，只有信贷业务的核对所需的信息可被各职能参照。

在S804中，新加坡分行的中后台审核被批准的请示书以及所制作出的合同 书，判定预定的核对项目是否充足。新加坡分行的中后台访问信贷管理子系统 15的控制卡75，将判定为充足的核对项目的状态从“未完成”更新为“完成”。 新加坡分行的中后台能在合同书的审核后对新加坡分行内的ABC法人团体的账 户设定信贷限度额。该信贷限度额可基于合同书中所记载的放款条件来决定。

在S805中，新加坡分行的后台依据所设定的信贷限度额以及合同书的打款 时间等信息，经由银行终端20在银行系统10上进行打款操作。基于信贷限度 额的资金被打入ABC法人团体的账户。

(第二案例)

参照图9A以及图9B对用于公司融资的第二案例进行说明。第二案例对通 过银行1的多个实体(例如，新加坡分行、河内分行、东京的总部的审查部) 来进行信贷关联业务的情况进行例证。在本说明书以及附图中，河内也可以简 略表示为“HNI”，且东京也可以简略表示为“TKY”。

图9A是表示第二案例中的信贷关联业务的流程的图。

(1)新加坡(SNG)的客户XYZ法人团体向银行1的新加坡分行申请融 资。

(2)新加坡分行的前台响应于受理融资的申请来维护公司卡，并生成Deal 信息，制作请示书。新加坡分行的前中台检查请示书的形式，确认需要文件以 及需要的手续。新加坡分行的前中台在检查以及确认之后更新控制卡。新加坡 分行的前中台向总部的审查部要求请示书的裁决。总部的审查部审核请示书， 决定放款条件，并批准融资。

(3)裁决后，新加坡分行的前台将条件管理以及事务手续委托给越南的河 内分行的中后台。河内分行的中后台审核被批准的请示书以及合同书。审核后， 河内分行的中后台更新控制卡。

(4)审核后，河内分行的中后台对河内分行内的XYZ法人团体的账户设 定信贷限度额。信贷限度额意味着对客户设定的信贷(即，融资)的限度额。 此后，河内分行的后台向XYZ法人团体的账户打款。

图9B是对第二案例中的操作的流程进行详细说明的流程图。

在S901中，银行1的新加坡分行的前台能响应于从XYZ法人团体受理融 资的申请，经由银行终端20向客户信息管理子系统11输入最新的客户信息。 客户信息管理子系统11能提供用于输入客户信息的应用程序。所输入的客户信 息可依据信息的内容而被储存在客户信息31、财务信息32、财务分析33、信贷 监控34、交易银行35、以及竞争比较36。

新加坡分行的前台能向案件信息管理子系统12输入XYZ法人团体所希望 的融资的概要。案件信息管理子系统12能提供用于输入融资的概要的应用程序。 所输入的信息可依据信息的内容而被储存在Deal简况41、信贷明细信息42、以 及担保明细信息43。储存在信贷明细信息42以及担保明细信息43的信息在被 批准进行该融资之前都为挂起状态。第二案例以公司融资为对象，因此，未使 用到SL信息44。

在S902中，新加坡分行的前台经由银行终端20访问裁决子系统14，制作 请示书。新加坡分行的前台能任意地为公司卡以及Deal信息设定风险因素。裁 决子系统14的信息取得部66能从客户信息管理子系统11取得与此请示书建立 关联的、储存在客户信息31、财务信息32、财务分析33、信贷监控34、交易 银行35、以及竞争比较36的最新数据。所取得的数据被储存在裁决子系统14 内的公司卡61。裁决子系统14的信息取得部66能从案件信息管理子系统12取 得与此请示书建立关联的、储存在Deal简况41、信贷明细信息42、以及担保明 细信息43的最新数据。所取得的数据被储存在裁决子系统14内的Deal信息62。 通过这些处理，裁决子系统14能使请示书的制作时间点的客户的信息以及融资 案件的信息与请示书建立关联。

当请示书的制作完成时(例如，按下保存按钮后)，裁决子系统14能向信 贷管理子系统15发送表示请示书的制作的信号。当该信号由信贷管理子系统15 接收时，生成包含在请示书的裁决前进行的信贷业务的控制卡。

新加坡分行的前台在裁决子系统14上选择审查所制作的请示书的部门以及 /或人的路线(顺序)。裁决子系统14能与请示书建立关联地记录所选择的路 线并按照路线来转发请示书。新加坡分行的前中台检查请示书的形式，如果完 成了内容的确认，则能在裁决子系统14上登记确认的完成。在请示书被裁决后， 控制卡中的项目“Application”和“Condition”自动地从“未完成”更新为“完 成”。

在S903中，总部的审查部能经由银行终端20访问裁决子系统14并批准所 提交的请示书。裁决子系统14能响应于请示书的批准来向信贷管理子系统15 发送表示批准的信号。信贷管理子系统15能响应于接收到该信号来从裁决子系 统14取得客户的信息并储存到公司卡71，且从案件信息管理子系统12取得与 融资的内容关联的信息并储存到Deal信息72。信贷管理子系统15能依据被批 准的请示书的内容(例如，放款条件等)来动态地生成包含在请示书的裁决后 进行的信贷业务的控制卡，并将所生成的控制卡储存到控制卡75。在请示书的 批准后，新加坡分行的前台依据请示书的内容来制作合同书。所制作的合同书在得到签字后被储存到裁决子系统14的合同书65。裁决子系统14响应于合同 书被储存到合同书65来将合同内容发送给信贷管理子系统15，所发送的合同内 容的信息被储存到合同信息74。在被储存到合同信息74的信息中，只有信贷业 务的核对所需的信息可被各职能参照。

在S904中，河内分行的中后台审核被批准的请示书以及所制作出的合同书， 判定预定的核对项目是否充足。河内分行的中后台访问信贷管理子系统15的控 制卡75，将判定为充足的核对项目的状态从“未完成”更新为“完成”。河内 分行的中后台能在合同书的审核后对河内分行内的XYZ法人团体的账户设定信 贷限度额。该信贷限度额可基于合同书中所记载的放款条件来决定。

在S905中，河内分行的后台依据所设定的信贷限度额以及合同书的打款时 间等信息，经由银行终端20在银行系统10上进行打款操作。基于信贷限度额 的资金被打入XYZ法人团体的账户。

(第三案例)

参照图10A以及图10B对用于结构性融资的第三案例进行说明。第三案例 对通过银行1的多个实体(例如，伦敦分行、纽约分行、东京分行、迪拜分行、 东京的总部的审查部)来进行信贷关联业务的情况进行例证。在本说明书以及 附图中，伦敦也可以简略表示为“LDN”，纽约也可以简略表示为“NYC”， 并且迪拜也可以简略表示为“DBI”。

图10A是表示第三案例中的信贷关联业务的流程的图。第三案例以对天然 气精制设备建设项目进行的融资为例进行说明。作为项目的资助人的B公司为 纽约分行的客户，作为建设者的C公司为东京分行的客户，作为经销商的D公 司为迪拜分行的客户。A法人团体是由B公司、C公司以及D公司为了此项目 而设立的SPC，为伦敦分行的客户。在此项目中，A法人团体为债务人。

(1)伦敦(LDN)的A法人团体向银行1的伦敦分行申请融资。伦敦分行 的前台更新A法人团体的公司卡，并生成Deal信息。将存在融资的申请的情况 通知给负责作为此项目的相关当事人的B公司、负责C公司以及D公司的纽约 分行、东京分行、以及迪拜分行。纽约分行、东京分行、以及迪拜分行的各前 台更新B公司、C公司、以及D公司的公司卡。

(2)伦敦分行的前台响应于受理融资的申请来制作请示书。伦敦分行的前 中台检查请示书的形式，确认需要文件以及需要的手续。伦敦分行的前中台在 检查以及确认之后更新控制卡。伦敦分行的前中台向东京的总部的审查部请求 请示书的裁决。总部的审查部审核请示书，决定放款条件，并批准融资。

(3)裁决后，伦敦分行的前台将条件管理以及事务手续委托给伦敦分行的 中后台。伦敦分行的中后台审核被批准的请示书以及合同书。审核后，伦敦分 行的中后台更新控制卡。

(4)审核后，伦敦分行的中后台对伦敦分行内的A法人团体的账户设定信 贷限度额。信贷限度额意味着对客户设定的信贷(即，融资)的限度额。此后， 伦敦分行的后台向A法人团体的账户打款。

图10B是对第三案例中的操作的流程进行详细说明的流程图。

在S1001中，银行1的伦敦分行的前台能响应于从A法人团体受理融资的 申请，经由银行终端20向客户信息管理子系统11输入最新的客户信息。客户 信息管理子系统11能提供用于输入客户信息的应用程序。所输入的A法人团体 的客户信息可依据信息的内容而被储存在客户信息31、财务信息32、财务分析 33、信贷监控34、交易银行35、以及竞争比较36。

伦敦分行的前台能向案件信息管理子系统12输入A法人团体所希望的融资 的概要。案件信息管理子系统12能提供用于输入融资的概要的应用程序。所输 入的信息可依据信息的内容而被储存在Deal简况41、信贷明细信息42、担保明 细信息43、以及SL信息44。储存在信贷明细信息42以及担保明细信息43的 信息在被审批进行该融资之前都为挂起状态。第三案例以结构性融资为对象， 因此，使用了SL信息44。在SL信息44存储有作为此项目的利益相关者的B 公司、C公司、以及D公司的标识符。

案件信息管理子系统12能将存在融资的申请的情况通知给负责作为此项目 的相关当事人的B公司、C公司以及D公司的纽约分行、东京分行、以及迪拜 分行。纽约分行、东京分行、以及迪拜分行的各前台能响应于此通知，经由银 行终端20访问客户信息管理子系统11，分别输入B公司、C公司、以及D公 司的最新的客户信息。所输入的B公司、C公司、以及D公司的客户信息可依 据信息的内容而被储存在客户信息31、财务信息32、财务分析33、信贷监控 34、交易银行35、以及竞争比较36。

在S1002中，伦敦分行的前台经由银行终端20访问裁决子系统14，制作请 示书。伦敦分行的前台能任意地为公司卡以及Deal信息设定风险因素。裁决子 系统14的信息取得部66能从客户信息管理子系统11取得与此请示书建立关联 的、储存在客户信息31、财务信息32、财务分析33、信贷监控34、交易银行 35、以及竞争比较36的最新数据。所取得的数据被储存在裁决子系统14内的 公司卡61。裁决子系统14的信息取得部66能从案件信息管理子系统12取得与 此请示书建立关联的、储存在Deal简况41、信贷明细信息42、担保明细信息 43、以及SL信息44的最新数据。所取得的数据被储存在裁决子系统14内的 Deal信息62。通过这些处理，裁决子系统14能使请示书的制作时间点的客户的 信息以及融资案件的信息与请示书建立关联。

当请示书的制作完成时(例如，按下保存按钮后)，裁决子系统14能向信 贷管理子系统15发送表示请示书的制作的信号。当该信号由信贷管理子系统15 接收时，生成包含在请示书的裁决前进行的信贷业务的控制卡。

伦敦分行的前台在裁决子系统14上选择审查所制作出的请示书的部门以及 /或人的路线(顺序)。裁决子系统14能与请示书建立关联地记录所选择的路 线，并按照路线来转发请示书。伦敦分行的前中台检查请示书的形式，如果完 成了内容的确认，则能在裁决子系统14上登记确认的完成。在请示书被裁决后， 控制卡中的项目“Application”和“Condition”自动地从“未完成”更新为“完 成”。

在S1003中，总部的审查部能经由银行终端20访问裁决子系统14并批准 所提交的请示书。裁决子系统14能响应于请示书的批准来向信贷管理子系统15 发送表示批准的信号。信贷管理子系统15能响应于接收到该信号来从裁决子系 统14取得客户的信息并储存到公司卡71，且从案件信息管理子系统12取得与 融资的内容关联的信息并储存到Deal信息72。信贷管理子系统15能依据被批 准的请示书的内容(例如，放款条件等)来动态地生成包含在请示书的裁决后 进行的信贷业务的控制卡，并将所生成的控制卡储存到控制卡75。在请示书的 批准后，伦敦分行的前台依据请示书的内容来在制作合同书。所制作出的合同书在得到签字后被储存到裁决子系统14的合同书65。裁决子系统14响应于合 同书被储存到合同书65来将合同内容发送给信贷管理子系统15，所发送的合同 内容的信息被储存到合同信息74。在被储存到合同信息74的信息中，只有信贷 业务的核对所需的信息可被各职能参照。

在S1004中，伦敦分行的中后台审核被批准的请示书以及所制作出的合同 书，判定预定的核对项目是否充足。伦敦分行的中后台访问信贷管理子系统15 的控制卡75，将判定为充足的核对项目的状态从“未完成”更新为“完成”。 伦敦分行的中后台能在合同书的审核后对伦敦分行内的A法人团体的账户设定 信贷限度额。该信贷限度额可基于合同书中所记载的放款条件来决定。

在S1005中，伦敦分行的后台依据所设定的信贷限度额以及合同书的打款 时间等的信息，经由银行终端20在银行系统10上进行打款操作。基于信贷限 度额的资金被打入A法人团体的账户。

根据本发明，银行系统10基于业绩差的公司的客户ID来检索Deal信息或 SL信息，由此，能提取与此公司建立关联的融资案件。根据本发明，在某一项 目发生巨大的损失时，银行系统10能基于SL信息来识别相关当事人，并提取 所识别出的各相关当事人的融资案件。根据本发明，银行系统10能提供信贷关 联业务的进展状况，因此，能进行更高效的信贷管理。

以上，参照举例示出的实施方式对本发明的原理进行了说明，但本领域技 术人员应当理解，只要不脱离本发明的主旨，就可实现在构成以及细节进行变 更的各种实施方式。在本说明书中，对银行系统10包含子系统11至15的实施 方式进行了说明，但本发明也可应用于其他的实施方式。例如，如果银行系统 10具有子系统11至15的功能以及数据库/文件，则也可以不使用子系统11至 15。

本发明可作为例如系统、装置、方法、程序或存储介质等的实施方案来实 现。

Claims (15)

1.一种银行系统，用于公司融资的海外信贷管理，具备：

第一储存单元，储存客户信息，其中所述客户信息能被多个实体共有；

第二储存单元，储存与信贷交易的管理单位有关的信息，其中与所述信贷交易的管理单位有关的信息具有一个或多个信贷行的信息以及一个或多个债务人的信息，所述债务人与所述客户信息建立关联；

批准单元，批准请示书中所记载的信贷交易的执行，其中所述批准单元具有所述请示书的制作时的所述客户信息以及与所述信贷交易的管理单位有关的信息，在所述请示书的批准时生成第一信号；以及

控制卡生成单元，响应于所述第一信号来生成控制卡，其中所述控制卡表示所述被批准的信贷交易的关联业务的进展状况，

与所述客户信息以及所述信贷交易的管理单位有关的信息由第一实体来进行维护。

2.根据权利要求1所述的银行系统，其中，

所述批准单元在所述请示书的制作时生成第二信号，

所述控制卡生成单元响应于所述第二信号来生成第二控制卡，所述第二控制卡能与所述控制卡结合。

3.根据权利要求1所述的银行系统，其中，

所述控制卡由第二实体来更新，

所述第一实体具有第一职能，所述第二实体具有第二职能。

4.根据权利要求3所述的银行系统，其中，

所述第一职能为前台，所述第二职能为中后台。

5.根据权利要求1所述的银行系统，其中，

所述控制卡由第一实体来更新，

所述第一实体具有第一职能以及第二职能。

6.根据权利要求5所述的银行系统，其中，

所述第一职能为前台，所述第二职能为中后台。

7.根据权利要求1所述的银行系统，其中，

所述第一实体为主信贷行(PLO)。

8.根据权利要求1所述的银行系统，还具备：

访问控制单元，对所述客户信息、与所述信贷交易的管理单位有关的信息、以及所述控制卡进行访问控制，

所述访问控制至少基于用户的所属实体、信贷职位以及职能来进行。

9.根据权利要求1所述的银行系统，其中，

所述请示书包含一个或多个风险因素，

所述银行系统还具备：提取单元，提取与所述风险因素建立关联的信贷交易。

10.一种方法，在用于公司融资的海外信贷管理的银行系统中执行，所述方法具备：

更新客户信息的步骤，其中所述客户信息能被多个实体共有；

更新与信贷交易的管理单位有关的信息的步骤，其中与所述信贷交易的管理单位有关的信息具有一个或多个信贷行的信息以及一个或多个债务人的信息，所述债务人与所述客户信息建立关联；

响应于请示书的制作来取得与所述客户信息以及所述信贷交易的管理单位有关的信息的步骤；

响应于所述请示书中所记载的信贷交易的批准来生成第一信号的步骤；以及

响应于所述第一信号来生成控制卡的步骤，其中所述控制卡表示所述被批准的信贷交易的关联业务的进展状况，

与所述客户信息以及所述信贷交易的管理单位有关的信息由第一实体来进行维护。

11.根据权利要求10所述的方法，还具备：

响应于所述请示书的制作来生成第二信号的步骤；以及

响应于所述第二信号来生成第二控制卡的步骤，其中所述第二控制卡能与所述控制卡结合。

12.根据权利要求10所述的方法，其中，

所述控制卡由第二实体来进行更新，

所述第一实体具有第一职能，所述第二实体具有第二职能。

13.根据权利要求10所述的方法，其中，

所述控制卡由第一实体来进行更新，

所述第一实体具有第一职能以及第二职能。

14.根据权利要求10所述的方法，还具备：

对所述客户信息、与所述信贷交易的管理单位有关的信息、以及所述控制卡进行访问控制的步骤，其中所述访问控制至少基于用户的所属实体、信贷职位以及职能来进行。

15.一种程序，在通过处理器来执行时，使计算机执行权利要求10至14中任一项所述的方法。