用于结构性融资的信贷管理的银行系统、方法以及程序与流程

本发明涉及一种用于结构性融资的信贷管理的银行系统、方法以及程序。更详细而言，本发明涉及一种用于结构性融资的信贷管理的银行系统、方法以及程序，其具有可被多个实体共有的客户信息，具有与能处理一个或多个信贷行以及一个或多个债务人的信贷交易的管理单位有关的信息，能提取与特定的融资案件建立关联的一个或多个相关当事人，且能识别信贷交易的关联业务的进展状况。

背景技术：

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

如前所述，在与公司融资关联的信贷业务中，涉及到多个国家以及地域的分行、当地法人、以及总部的案例增加。另一方面，银行除了公司融资以外，也多会处理结构性融资(structuredfinance)。结构性融资不基于企业的信用度，而是基于某一特定的事业的保有资产以及从其事业所产生的资金流(cashflow)的融资(finance)，例如，能包含对由利益相关者所设立的有特殊目的公司(spc：specialpurposecompany)进行融资。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)。在指单个的信贷时使用前者，在指对客户的信贷的整体时使用后者。

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

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

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

sl(specializedlending)：与结构性融资(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(harddiskdrive：硬盘驱动器)或ssd(solidstatedrive：固态硬盘)等存储装置，能长期保存数据、程序。

图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(customerinformationfile)中的客户信息不同。cif中的客户信息由各信贷行来制作并进行维护。在某一特定的企业与银行内部的多个信贷行存在交易的情况下，由于各信贷行都制作并维护客户信息，因此，在银行1内并未进行集中化的信息管理。在本说明书中，为了与以往的cif区别，将客户信息称为“公司卡(corporatecard)”。

案件信息管理子系统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(specializedlending)储存特有的信息。在图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.关键风险因素(keyriskfactor)”能显示所附加的风险因素。图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、文档列表(documentlist)1503、状态变更按钮1504、以及信贷业务1505。控制卡1500还能具有关联的请示书id、公司卡71的标识符、以及deal信息72的标识符。

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

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

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

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

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

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

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

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

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

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

用户信息51的具体例如下所示。例如，某人的所属组织以及职位为新加坡分行的营业部门的副经理(assistantmanager)，此人的职能在从事营业的事务的工作，因此为前中台。例如，另一人的所属组织以及职位为新加坡分行的融资事务部门的高级职员(seniorstaff)，此人的职能在从事融资事务，因此为中后台。本说明书中所使用的职能以及职位如表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。

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