CN108990424A - 银行系统以及由银行系统执行的方法 - Google Patents

Abstract

本发明提供一种基于请示书的批准条件和放款执行所需的条件的充足状态来使要登记到结算系统的信贷信息的一致性变得可靠的银行系统。银行系统响应于请示书数据被批准，来接收基于与请示书数据建立关联的Deal信息以及控制卡的状态信息生成的第一贷款信息。储存基于所接收到的第一贷款信息的第二贷款信息。银行系统判定登记到信贷额度的贷款数据是否与储存于第二贷款信息的贷款的明细信息具有一致性，并且判定储存于第二贷款信息的控制卡的状态信息是否适当。响应于肯定的判定结果，贷款数据被登记到信贷额度。

Description

银行系统以及由银行系统执行的方法

技术领域

本发明涉及一种银行系统以及由银行系统执行的方法。更详细而言，本发明涉及一种基于请示书的批准条件和放款执行所需的条件的充足状态来使要登记到结算系统的信贷信息的一致性变得可靠的银行系统以及由银行系统执行方法。

背景技术

金融机构的活动范围依赖于其企业规模以及企业方针。例如，一部分金融机构可能是在世界范围开展活动网点并进行国际活动的银行。进行国际活动的银行利用多种系统向客户提供银行业务。这样的系统并不是同时期构建的，例如，也有时是进入某一地区时新构建的系统，或者也有时是此地区的被收购的银行所使用的系统。进行国际活动的银行每几年对在多个国家、地区利用的系统整体进行重建，但在此之前常常将多种系统结合起来继续利用。

近年来，随着海外商业规模的扩大，银行的海外信贷余额正在增加。许多企业为了扩大商机而在多个国家以及地区设立子公司或者分店和/或建设工厂。这种状况下，在与这样的企业进行交易时，进行国际活动的银行常常会通过此银行的海外支行或与此银行关联的当地法人来对该企业进行融资。在这些案例中，通常，由于仅通过位于进行了融资申请的国家的支行或当地法人无法完成信贷相关业务，因此，位于多个国家的支行、总行会共享信息来进行信贷相关业务。

银行经过多年开发出各种银行系统。在作为客户的企业的活动地区仅为国内的情况下，银行通过用于客户信息管理的系统、用于进行融资判断的裁决系统、用于信贷管理的系统、以及结算系统等国内用的银行系统来支持客户企业的活动。随着企业的活动扩大至全球，要求银行系统满足在全球活动的企业的需求。

专利文献1仅公开了在多个国家之间进行资金裁决的系统。专利文献2公开了用于公司融资的海外信贷管理系统。如此，以往的银行系统只不过提供了专注于海外业务中的特定业务的系统以及仅对海外信贷管理进行了特殊化的系统。某些银行一直在运用管辖亚洲的结算系统以及管辖欧洲的结算系统以及同类的结算系统等多个结算系统。然而，以往的银行系统没有提供将各个结算系统与其他系统联合运用的结构、例如与多个结算系统联合来进行海外信贷管理的系统。针对将商业开展至全球的企业的公司融资的件数正在增加，并且海外的总行、支行、以及当地法人的数量正在增加。这种状况下，银行需要重新构建一种与能处理公司融资且能供银行内的多个办事处参与的海外信贷管理系统联合的结算系统，即，基于请示书的批准条件和放款执行所需的条件的充足状态来使要登记到结算系统的信贷信息的一致性变得可靠的结算系统。

现有技术文献

专利文献

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

专利文献2：日本专利第5952518号公报

发明内容

本发明的目的在于提供一种与能供银行内的多个办事处参与的海外信贷管理系统联合的结算系统，即，能基于请示书的批准条件和放款执行所需的条件的充足状态来使要登记到结算系统的信贷信息的一致性变得可靠的银行系统。

作为本发明的一方案的银行系统构成为：响应于请示书数据被批准，来接收基于与所述请示书数据建立关联的Deal信息以及控制卡的状态信息生成的第一贷款信息，所述第一贷款信息识别所关联的结算系统，并且被周期性地发送给所识别到的所述结算系统，储存基于所接收到的所述第一贷款信息的第二贷款信息，判定要登记到信贷额度的贷款数据是否与储存于所述第二贷款信息的贷款的明细信息具有一致性，并且判定储存于所述第二贷款信息的所述控制卡的所述状态信息是否适当，响应于肯定的判定结果，来执行所述贷款数据向所述信贷额度的登记。

作为本发明的另一方案的由银行系统执行方法具备：响应于请示书数据被批准，来接收基于与所述请示书数据建立关联的Deal信息以及控制卡的状态信息生成的第一贷款信息，所述第一贷款信息识别所关联的结算系统，并且被周期性地发送给所识别到的所述结算系统；储存基于所接收到的所述第一贷款信息的第二贷款信息；判定要登记到信贷额度的贷款数据是否与储存于所述第二贷款信息的贷款的明细信息具有一致性，并且判定储存于所述第二贷款信息的所述控制卡的所述状态信息是否适当；以及响应于肯定的判定结果，来执行所述贷款数据向所述信贷额度的登记。

本发明的银行系统能基于请示书的批准条件和放款执行所需的条件的充足状态来使要登记到结算系统的信贷信息的一致性变得可靠。

附图说明

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

图1表示包含信贷管理系统以及多个结算系统的银行系统的整体图。

图2表示信贷管理系统以及多个结算系统的系统构成的一部分。

图3表示请示书的示例性的格式。

图4是表示图4A与图4B的关系的图。

图4A表示能显示储存于控制卡的数据的控制卡编辑画面的一个例子。

图4B表示能显示储存于控制卡的数据的控制卡编辑画面的一个例子。

图5表示用于公司融资的案例中的信贷相关业务的流程。

图6对图5的案例中的主要操作的流程进行说明。

图7表示结算系统中用于登记信贷额度的额度登记画面。

图8对在结算系统中执行的流程进行详细说明。

具体实施方式

以下，参照附图，提供伴随本发明的示例性的实施方式的详细说明。本说明书所记载的示例性的实施方式仅作为用于研究的例子来使用，而不用于限定本发明。

＜术语的定义＞

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

海外信贷：银行的海外支行或与此银行关联的当地法人对此银行的客户进行的融资。作为相当于信贷的术语的贷款(facility)在指单个的信贷时使用。

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

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

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

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

图1是表示包含信贷管理系统10以及多个结算系统20的银行系统1的整体图。银行系统1是能处理存款业务、贷款业务、国内汇兑业务、国外汇兑业务、以及同类业务的系统。为了达到说明的目的，在本说明书中，对银行系统1的主要功能中的与针对在一个或多个国家以及地区开展事业的企业的海外信贷管理关联的功能以及处理进行说明。

在银行系统1中，信贷管理系统10以能通信的方式与多个结算系统20a、20b(在本说明书中，统称为“结算系统20”)连接。在图1中示出了两个结算系统20a、20b，但信贷管理系统10可以与三个以上的结算系统连接。

信贷管理系统10能储存信贷管理过程中使用的客户信息以及与融资有关的案件信息(Deal)。Deal是能包含作为客户的企业的资金需求的背景和理由、以及资金的用途和融资期限等事实信息的信息。

信贷管理系统10能支持如下功能：通过使用客户信息以及Deal来制作关于海外信贷的请示书并递交给相关部门，并且从裁决权限人获得批准。信贷管理系统10能支持各种信贷相关业务，并且能强化相关部门以及信贷行间的联合和内部管理。信贷管理系统10能提供核对融资执行前的业务、以及融资执行后的业务是否被适当执行的功能。信贷管理系统10能将被批准的信贷明细和控制卡的状态信息发送给与信贷明细建立关联的结算系统20。关于控制卡，将参照图2、图4A以及图4B在后文加以叙述。

结算系统20是构成银行系统1的系统之一，是执行账户和融资的余额管理、对存款额和融资额的利息计算等银行的结算处理的系统。结算系统20a、20b分别能规定所使用的国家、地区。例如，结算系统20a由亚洲地区的总行、支行、以及当地法人来利用，结算系统20b由欧美地区的总行、支行、以及当地法人来利用。

银行系统1能经由网络40以能通信的方式与多个银行终端30a、30b、……、30n(在本说明书中，统称为“银行终端30”)连接。银行终端30能分别访问信贷管理系统10以及结算系统20。银行终端30分别能由利用银行系统1的银行的总行、支行、以及当地法人来使用。银行终端30可以是能供银行职员利用的终端，不限定于特定的设备。例如，银行终端30可以包含个人计算机(PC)、笔记本电脑、平板型终端、便携信息终端(PDA)、用户设备(UE)、移动站、蜂窝电话机、智能手机、或者能在有线或无线环境中工作的其他任意类型的设备，但不限定于这些。网络40可以是包含互联网、专用线路等的能相互通信的公知的网络，并不特别限定。

图2表示信贷管理系统10以及多个结算系统20的系统构成的一部分。信贷管理系统10能具备处理器11、内存(memory)12、连接接口(IF)13、网络接口(IF)14、输出装置15、以及存储器(storage)16。各部件11～16以能经由总线19相互通信的方式连接。

处理器11控制信贷管理系统10内的各设备以及各电路，并进行运算以及数据处理。处理器11能将储存于存储器16的各种程序读出至内存12并执行。

内存12是暂时存储区域，在由处理器11进行运算执行时使用。内存12能存储各种数据、计算机可执行命令、以及基于该命令的运算处理后的数据。

连接IF13是用于将各种设备连接于信贷管理系统10的接口。例如，显示器、键盘、鼠标、外部存储装置等能经由连接IF13而连接于信贷管理系统10。

网络IF14起到在与其他系统、装置之间收发数据时的接口的作用。处理器11通过网络IF14与网络40以及多个结算系统20进行数据通信。

输出装置15能提供用于将由处理器11处理后的数据和/或从各种数据库、文件中读出的数据显示于显示器，并且打印显示于显示器的数据的功能。

存储器16是储存各种程序以及数据的存储区域。存储器16例如由HDD(Hard DiskDrive：硬盘驱动器)、SSD(Solid State Drive：固态硬盘)等构成，能长期保存各种数据、程序。基于处理器11的控制，从存储器16中读取一个或多个数据，并向存储器16中写入一个或多个数据。

此外，结算系统20也能具备相当于处理器11、内存12、连接接口(IF)13、网络接口(IF)14、输出装置15、以及存储器16的处理器、内存、连接IF、网络IF、输出装置、以及存储器。各部件的功能与上述的功能11～16相同。

图2对将处理器11、内存12、以及存储器16设于同一计算机内的实施方式进行说明。在本发明的其他实施方式中，信贷管理系统10也能构成为：通过使用多个处理器11、内存12、以及存储器16，利用多个计算机来实现并行分布式处理。在本发明的其他实施方式中，也能采用为信贷管理系统10设置多个计算机且多个计算机共用一个存储器16的实施方式。

对储存于存储器16的数据库、表(table)和/或文件的例子进行说明。存储器16能具备客户信息161、公司卡162、Deal简况(Deal Profile)163、Deal信息164、用户信息165、请示书166、合同信息167、控制卡168、以及贷款信息169。

客户信息161能储存在信贷管理过程中使用的客户信息。客户信息161是客户的简况，例如，能包含客户ID、公司的名称、总公司的所在地、设立年份、从业人数、工厂和/或分店的所在地(国家以及城市名)、股份信息、股东、集团结构、经营史、与银行的关系、关键人物、事业划分、按地区分部(segment)、主要客户、主要供应商等属性信息。客户信息161能包含客户的损益计算书、借贷对照表、资金流计算书、及这些财务信息的原始数据、以及基于财务信息的分析结果。财务分析由银行职员来进行，其分析结果能在信贷判断中被利用。

客户信息161是在银行系统1内共用的数据，并且能由银行内的多个部门以及信贷行共用，因此，是与以往的CIF(customer information file：客户信息文件)不同的客户信息。CIF中的客户信息由各个信贷行来制作并维护。在某一特定企业与银行内的多个信贷行进行交易的情况下，由各个信贷行制作CIF并维护，因此，在银行内并未进行集中化的信息管理。

公司卡162能储存在某一时间点从客户信息161中提取出的信息。客户信息161储存经时变化的信息，但公司卡162储存起草请示书的时间点的客户信息161的信息。在其他实施方式中，公司卡162能储存结算请示书的时间点的客户信息161的信息。

Deal简况163能储存与融资有关的案件信息(Deal)。Deal是信贷交易的管理单位。Deal能包含作为客户的企业的资金需求的背景和理由、以及资金的用途和融资期限等事实信息。Deal能表示多个信贷行参与的交易、和/或多个债务人参与的交易的信息。

Deal简况163能包含基本信息、Deal概要(Deal summary)、Deal背景(background)、放款结构(structure)、支援分担、信贷明细信息、以及担保明细信息。

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

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

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

Deal信息164能储存在某一时间点从Deal简况163中提取出的信息。Deal简况163储存经时变化的信息，但Deal信息164储存起草请示书的时间点的Deal简况163的信息。Deal信息164能包含状态信息。状态信息能在请示书被裁决前表示“Pending(未决)”，在裁决后表示“Fixed(已决)”。

Deal信息164能包含一个或多个贷款信息。例如，在Deal与工厂建设关联的情况下，最初进行用于获取土地的融资，接着进行用于建设工厂的融资。在这样的案例中，一个Deal能包含多个贷款信息。

用户信息165能储存利用银行系统1的用户信息。用户信息165能具备用户ID、所属组织、信贷职位、以及职能。用户ID是用于识别使用银行系统1的用户的ID。所属组织表示用户的所属部门(例如，总行的审查部、新加坡支行的营业部等)。信贷职位是用于信贷判断的职位，表示集团经理(group manager)、支行长等职位。这些职位基于正式的人事信息来决定。职能表示在信贷相关业务中所发挥的职能(例如，前台、前中台、中后台、后台、审查部等)。在表1中示出职能、职位、以及工作内容的一个例子。

[表1]

表1职能、职位以及工作内容的一个例子

请示书166能储存请求对融资的执行的批准的请示书数据。请示书针对各Deal而制作。图3表示请示书的示例性的格式。该格式能包含信贷案件的信息、批准流程、敞口(exposure)和保全状况、收益性、各实体对信贷案件的结论、债务人列表以及同样的内容。请示书166能包含请示书ID、图3所示的内容、以及状态。请示书ID表示请示书的标识符，状态表示审查的状况(例如，“裁决前”、“已裁决”)。请示书166的各请示书数据能与公司卡162以及Deal信息164所对应的数据建立关联。

合同信息167在请示书的裁决后制作，能储存签字后的合同书的数据。合同信息167能储存对应的Deal信息的标识符、以及对应的请示书数据的请示书ID。

控制卡168能包含需要执行的信贷业务的内容以及进行信贷业务的负责部门(职能)的信息。此外，控制卡能表示需要执行的所有信贷业务的进展状况。储存于控制卡168的信息分别按对应的Deal来生成。储存于控制卡168的信息分别与对应的Deal以及对应的请示书的数据建立关联。需要执行的信贷业务的内容以及进行信贷业务的负责部门(职能)能基于Deal信息以及请示书的批准流程信息来决定。例如，针对在美国进行的项目的融资和针对在印度具有总公司的事业公司的融资中，需要执行的信贷业务以及负责部门、支行不同，因此，使用不同的控制卡。进行信贷业务的负责部门能按照被分配的职能来进行信贷业务，并将其结果输入至信贷管理系统10。

图4A以及图4B表示能显示储存于控制卡168的数据的控制卡编辑画面400的一个例子。控制卡编辑画面400能包含控制卡编号401、负责实体以及职能402、Deal信息403、文档列表(Document list)404、状态变更按钮405、以及信贷业务406。控制卡编辑画面400还能进一步具有关联的请示书ID、公司卡162的标识符。

控制卡编号401是识别控制卡的标识符。负责实体以及职能402能表示应承担信贷业务的责任的实体(部门、支行等)以及职能。负责实体以及职能402还能进一步表示用户ID以及用户名。

Deal信息403能表示储存于Deal信息164的对应的Deal信息。例如，图4A能显示信贷案件编号、Deal名、以及债务人。

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

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

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

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

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

如图4A以及图4B所示，控制卡编辑画面400包含每个贷款的信贷业务，并且能表示各信贷业务是否完成。具体而言，控制卡编辑画面400能包含两个贷款。在图4A以及图4B中，贷款编号“X111”表示在新加坡进行融资的申请、处于“Pre-Signing”阶段、以及融资的名称为“364天的桥式融资”。作为“Pre-Signing”阶段的信贷业务，控制卡编辑画面400能包含“申请(Application)”、“条件(Condition)”、“条款核对(Terms Check)”、“担保/保证(Guarantee/Collateral)”、“文档(Document)”、以及“附带过程(Ancillary Process)”。

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

如上所述，信贷管理系统10能具有关于各请示书的控制卡，控制卡能表示需要执行的所有信贷业务的进展状况。图4A以及图4B所示的控制卡168的信息只不过是一个例子，控制卡编辑画面400还能显示本说明书中示出的信贷业务以外的内容。

再次参照图2，贷款信息169能储存要登记到结算系统20的各信贷的信息。信贷管理系统10能生成贷款信息169，并将各个贷款信息分别发送给与此贷款信息建立关联的结算系统20a、20b。贷款信息被以预定的周期发送给所关联的结算系统20。

结算系统20a能具备贷款信息201a以及信贷额度202a，结算系统20b能具备贷款信息201b以及信贷额度202b。贷款信息201a以及贷款信息201b包含相同的信息，因此，可以统称为“贷款信息201”。贷款信息201能包含基于从信贷管理系统10接收到的贷款信息169来生成或更新的信息。信贷额度202a以及信贷额度202b能包含分别登记到结算系统20a以及结算系统20b的信贷额度的数据。

图7表示结算系统20中用于登记信贷额度的额度登记画面700。银行终端30能访问结算系统20并调出额度登记画面700。当在额度登记画面700中指定信贷案件编号(贷款ID)时，结算系统20能从贷款信息201中提取与所指定的信贷案件编号建立关联的信息并显示于额度登记画面700。当按下额度登记画面700的登记按钮时，结算系统20能核对显示于额度登记画面700的信息是否与储存于贷款信息201的信息吻合、以及储存于贷款信息201的控制卡的状态信息是否适当，并在肯定的判定结果的情况下登记到信贷额度202。

像本说明书中所说明的那样，贷款信息201基于请示被批准的信贷明细信息而生成。显示于额度登记画面700的信息是从贷款信息201中提取的，因此，额度登记画面700能仅显示请示被批准的信贷明细信息。

参照图5以及图6，对海外信贷管理的操作的一个例子进行说明。图5表示用于公司融资的案例中的信贷相关业务的流程。该案例表示由银行的多个实体(例如，新加坡支行、河内支行、东京的总行的审查部)来进行信贷相关业务。在本说明书以及附图中，新加坡可以缩写为“SNG”，河内可以缩写为“HNI”，并且东京可以缩写为“TKY”。

示出对图5所示的符号(1)～(4)的说明。

(1)位于新加坡(SNG)的客户XYZ公司向银行的新加坡支行申请融资。

(2)新加坡支行的前台响应于收到融资的申请，更新客户信息161以及Deal简况163，并制作请示书。响应于请示书的制作，来生成公司卡162、Deal信息164、以及控制卡168。新加坡支行的前中台检查请示书的形式，确认所需文件以及所需的手续。新加坡支行的前中台在检查以及确认后更新控制卡168。新加坡支行的前中台向审查部请求请示书的裁决。审查部审核(review)请示书，决定放款条件，并批准融资。

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

(4)河内支行的中后台在审核后对河内支行内的XYZ公司的账户设定信贷额度。信贷额度是指对客户设定的信贷(即，融资)的限额。之后，河内支行的后台向XYZ公司的账户打款。

表2表示上述每个职能的信贷业务的例子，但信贷业务不限定于这些业务。

[表2]

表2每个职能的信贷业务的例子

图6对图5的案例中的主要操作的流程进行说明。S602以及S603能并行执行。

在S601中，信贷管理系统10能向银行终端30提供用于输入并更新客户信息161的应用程序。新加坡支行的前台能响应于从XYZ公司收到融资的申请，经由银行终端30以及该应用程序来访问信贷管理系统10，并输入或更新客户信息161。

信贷管理系统10能向银行终端30提供用于输入或更新Deal简况163的应用程序。新加坡支行的前台能经由银行终端30以及该应用程序来向Deal简况163输入针对XYZ公司的融资的信息。

在S602中，新加坡支行的前台能经由银行终端30访问信贷管理系统10，并起草请示书。请示书的起草人能选择确认请示书的确认人以及批准请示书的批准人。作为代替，起草人能替代确认人以及裁决权人而选择实体(例如，审查部等一个或多个部门)的名字，或者除了确认人以及裁决权人之外还选择实体(例如，审查部等一个或多个部门)的名字。在选择了实体的名字的情况下，接收到请示书的实体能选择请示书的确认人以及批准人。信贷管理系统10响应于请示书数据的生成，从客户信息161中提取与此请示书数据建立关联的客户信息并储存至公司卡162，并且从Deal简况163中提取与此请示书数据建立关联的Deal信息并储存至Deal信息164。通过这些处理，信贷管理系统10能将请示书的制作时间点的客户信息以及融资案件的信息与请示书数据建立关联。

信贷管理系统10能按照请示书数据中指定的批准途径，将请示书数据转递给确认请示书的确认人以及批准请示书的批准人。能向确认人以及批准人通知需要由他们确认的请示书的识别信息。确认人例如能在检查请示书的形式并完成内容的确认后，经由银行终端30将表示确认的完成的信号发送给信贷管理系统10。在请示书被批准人批准后，信贷管理系统10能将对应的控制卡中的项目“Application”和“Condition”从“未完成(Incomplete)”更新为“完成(Complete)”。

在S603中，信贷管理系统10能响应于请示书数据的生成，生成与此请示书数据建立关联的控制卡的数据，并将所生成的数据储存至控制卡168。所生成的控制卡的状态为“Pre-Signing”。如上所述，所生成的控制卡中包含的信贷业务以及负责部门(职能)依赖于对应的Deal信息以及对应的请示书的批准流程信息。所生成的控制卡也能包含在请示书的批准后进行的信贷业务。信贷管理系统10能响应于发生与控制卡中包含的信贷业务建立关联的事件，来将此信贷业务从“Incomplete”更新为“Complete”。例如，在从客户提交征求物且此征求物数据被登记后，信贷管理系统10能将对应的信贷业务从“Incomplete”更新为“Complete”。

在S604中，请示书被批准人批准。在请示书的批准后，新加坡支行的前台按照请示书的内容来制作合同书。所制作的合同书由当事人签字。信贷管理系统10能接收签字后的合同书数据并储存至合同信息167。信贷管理系统10能响应于合同书数据的储存，来将控制卡的状态更新为“Post-Signing”。

在S605中，信贷管理系统10能在请示书的批准后周期性地生成贷款信息169。贷款信息169能具备关于与批准后的请示书建立关联的各贷款的控制卡的状态信息、以及贷款的明细信息。贷款的明细信息能根据公司卡162、Deal信息164、请示书166、以及合同信息167的一个或多个来生成。

在S606中，信贷管理系统10能将各贷款信息169的数据周期性地发送给与各贷款信息建立关联的结算系统20的每一个。结算系统20能基于所接收的贷款信息169的数据来更新贷款信息201。如上所述，贷款的明细信息能根据Deal信息164来生成，Deal信息164具有信贷行或主信贷行(PLO)的信息。信贷行或PLO的信息能识别所关联的结算系统20。例如，在新加坡支行为信贷行或PLO的情况下，所使用的结算系统20是管辖亚洲地区的结算系统20。

在S607中，结算系统20能向银行终端30提供用于在结算系统中登记信贷额度的额度登记画面700。当在额度登记画面700中指定信贷案件编号时，结算系统20能从贷款信息201中提取与所指定的信贷案件编号建立关联的信息并显示于额度登记画面700。当由用户输入或更新信息且按下额度登记画面700的登记按钮(未图示)时，结算系统20能核对显示于额度登记画面700的信息是否与储存于贷款信息201的信息吻合。

在S608中，结算系统20判定要登记到信贷额度202的信息是否与储存于贷款信息201的贷款的明细信息具有一致性。贷款信息201基于贷款信息169来更新，因此，能具备控制卡的状态信息和贷款的明细信息。在请示书的批准后，根据公司卡162、Deal信息164、请示书166、以及合同信息167的一个或多个来生成贷款的明细信息。因此，在判定为不具有一致性的情况下，要登记到信贷额度202的信息与被批准的贷款的明细信息不一致。在判定为不具有一致性的情况下，结算系统20经由额度登记画面700来显示消息，表示不具有一致性。在这样的情况下，在S607中，通过额度登记画面700来进行数据的重新输入。

在S608中，结算系统20进一步判定储存于贷款信息201的控制卡的状态信息是否为适当的状态。在状态信息不适当的情况下，结算系统20显示促使在所需的信贷业务充足之后进行信贷额度的登记的消息。在S609中，结算系统20能经由额度登记画面700将所输入的信息登记到信贷额度202。

如上所述，贷款信息201的数据是基于贷款信息169的数据，所述贷款信息169是基于储存于信贷管理系统10的数据生成的，因此，本发明能使被批准的Deal信息与应登记到结算系统20的信贷信息的一致性变得可靠。

图8对在结算系统20中执行的流程进行详细说明。以开始图8的流程为前提，结算系统20基于从信贷管理系统10接收到的贷款信息169的数据来更新贷款信息201的数据。在S801中，结算系统20能向银行终端30提供如图7所示的额度登记画面700。向输入项目“英国贷款ID(GBR Facility ID)”输入信贷案件编号，并按下显示于额度登记画面700的检索按钮(未图示)。结算系统20能响应于从银行终端30接收到信贷案件编号，从结算系统20内的贷款信息201中读出与所指定的信贷案件编号对应的数据并显示于额度登记画面700。

在S802中，河内支行的中后台能在额度登记画面700上输入更新信息和/或追加信息。例如，河内支行的中后台能在合同书的审核后访问结算系统20，对河内支行内的XYZ公司的账户设定贷款限额。该贷款限额能基于合同书中记载的放贷条件来决定。当按下显示于额度登记画面700的登记按钮(未图示)时，结算系统20能经由额度登记画面700来核对要登记到信贷额度202的数据是否与储存于贷款信息201的贷款的明细信息具有一致性。结算系统20能进一步判定储存于贷款信息201的控制卡的状态信息是否表示适当的状态。

在S803中，在要登记到信贷额度202的数据与储存于贷款信息201的贷款的明细信息具有一致性，并且储存于贷款信息201的控制卡的状态信息表示适当的状态的情况下，该处理流程进入S804的处理。否则，结算系统20能在银行终端30显示消息，返回S802并促使重新输入。

在S804中，结算系统20能将经由额度登记画面700输入的数据储存至信贷额度202。储存于信贷额度202的数据与被批准的贷款的明细信息具有一致性。

在S805中，结算系统20能向银行终端30提供用于进行提款执行的登记的画面。当从银行终端30接收到信贷额度202的特定的贷款的提款执行的指示时，结算系统20读出储存于信贷额度202的该信息并显示在用于进行提款执行的登记的画面上。响应于接收到提款执行的登记命令，结算系统20判定所显示的信息是否与储存于贷款信息201的贷款的明细信息具有一致性，并且判定储存于贷款信息201的控制卡的状态信息是否表示适当的状态。例如，在状态信息表示“Available to Drawdown”的情况下，结算系统20能判定为要进行提款执行的信息有效。例如，河内支行的后台能确认所设定的贷款限额以及合同书的打款日期和时刻等信息，并经由银行终端30将能否进行所登记的贷款的提款入账登记到结算系统20。贷款限额所示的资金被打入XYZ公司的账户。

在S806中，在S805的判定结果为肯定的结果的情况下，该处理流程的处理进入S807。在S805的判定结果不是肯定的情况下，结算系统20能在银行终端30显示消息，返回S805并促使提款执行的重新登记。在S807中，结算系统20能对该贷款进行提款入账。在图5的案例中，提款入账可以是指，向XYZ公司的账户打款。

如上所述，要提款入账的贷款数据的一致性基于储存于结算系统20的贷款信息201的数据来核对。贷款信息201基于被批准的Deal信息来生成，因此，本发明能使被批准的Deal信息与应登记到结算系统20的信贷信息的一致性变得可靠。

以上，参照示例性的实施方式对本发明的原理进行了说明，但本领域技术人员应当理解，在不脱离本发明的主旨的范围内，可以实现在构成以及细节进行变更的各种实施方式。本发明可以采用例如作为系统、装置、方法、程序、或存储介质等的实施方案。

Claims (10)

1.一种银行系统，具备处理器，所述处理器构成为：

响应于请示书数据被批准，来接收基于与所述请示书数据建立关联的Deal信息以及控制卡的状态信息生成的第一贷款信息，所述第一贷款信息识别所关联的结算系统，并且被周期性地发送给所识别到的所述结算系统，

储存基于所接收到的所述第一贷款信息的第二贷款信息，

判定要登记到信贷额度的贷款数据是否与储存于所述第二贷款信息的贷款的明细信息具有一致性，并且判定储存于所述第二贷款信息的所述控制卡的所述状态信息是否适当，

响应于肯定的判定结果，来执行所述贷款数据向所述信贷额度的登记。

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

所述处理器进一步构成为：

响应于接收到针对登记到所述信贷额度的所述贷款数据、即由用户指定的所述贷款数据的提款执行的登记命令，来判定所述贷款数据是否与储存于所述第二贷款信息的贷款的明细信息具有一致性，并且判定储存于所述第二贷款信息的控制卡的状态信息是否表示适当的状态，

响应于肯定的判定结果，来进行针对所述贷款数据的提款执行。

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

所述银行系统具备海外信贷管理系统以及多个结算系统，所述第一贷款信息储存于所述海外信贷管理系统，所述第二贷款信息储存于多个所述结算系统的每一个。

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

在储存于所述第二贷款信息的控制卡的状态信息表示执行准备完成的情况下，判定为所述贷款数据有效。

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

所述第二贷款信息基于周期性地接收到的所述第一贷款信息来更新，

要登记到所述信贷额度的所述贷款数据从更新后的所述第二贷款信息中提取。

6.一种方法，是由银行系统执行的方法，其具备：

响应于请示书数据被批准，来接收基于与所述请示书数据建立关联的Deal信息以及控制卡的状态信息生成的第一贷款信息，所述第一贷款信息识别所关联的结算系统，并且被周期性地发送给所识别到的所述结算系统；

储存基于所接收到的所述第一贷款信息的第二贷款信息；

判定要登记到信贷额度的贷款数据是否与储存于所述第二贷款信息的贷款的明细信息具有一致性，并且判定储存于所述第二贷款信息的所述控制卡的所述状态信息是否适当；以及

响应于肯定的判定结果，来执行所述贷款数据向所述信贷额度的登记。

7.根据权利要求6所述的方法，进一步具备：

响应于接收到针对登记到所述信贷额度的所述贷款数据、即由用户指定的所述贷款数据的提款执行的登记命令，来判定所述贷款数据是否与储存于所述第二贷款信息的贷款的明细信息具有一致性，并且判定储存于所述第二贷款信息的控制卡的状态信息是否表示适当的状态；以及

响应于肯定的判定结果，来进行针对所述贷款数据的提款执行。

8.根据权利要求7所述的方法，其中，

所述银行系统具备海外信贷管理系统以及多个结算系统，所述第一贷款信息储存于所述海外信贷管理系统，所述第二贷款信息储存于多个所述结算系统的每一个。

9.根据权利要求7所述的方法，其中，

在储存于所述第二贷款信息的控制卡的状态信息表示执行准备完成的情况下，判定为所述贷款数据有效。

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

所述第二贷款信息基于周期性地接收到的所述第一贷款信息来更新，

要登记到所述信贷额度的所述贷款数据从更新后的所述第二贷款信息中提取。