WO2016157252A1 - 与信事務管理システムおよびその方法 - Google Patents

与信事務管理システムおよびその方法 Download PDF

Info

Publication number
WO2016157252A1
WO2016157252A1 PCT/JP2015/001866 JP2015001866W WO2016157252A1 WO 2016157252 A1 WO2016157252 A1 WO 2016157252A1 JP 2015001866 W JP2015001866 W JP 2015001866W WO 2016157252 A1 WO2016157252 A1 WO 2016157252A1
Authority
WO
WIPO (PCT)
Prior art keywords
credit
storage unit
control card
check
document
Prior art date
Application number
PCT/JP2015/001866
Other languages
English (en)
French (fr)
Inventor
清徳 宇賀神
和矢 池田
智生 山田
林　正人
雅登 加納
Original Assignee
株式会社三井住友銀行
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 株式会社三井住友銀行 filed Critical 株式会社三井住友銀行
Priority to CN201580078640.7A priority Critical patent/CN107430746B/zh
Priority to PCT/JP2015/001866 priority patent/WO2016157252A1/ja
Priority to JP2016516113A priority patent/JP5963998B1/ja
Priority to US15/563,244 priority patent/US20180122003A1/en
Publication of WO2016157252A1 publication Critical patent/WO2016157252A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/02—Banking, e.g. interest calculation or account maintenance
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/22—Payment schemes or models
    • G06Q20/24—Credit schemes, i.e. "pay after"
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/42—Confirmation, e.g. check or permission by the legal debtor of payment
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/03—Credit; Loans; Processing thereof

Definitions

  • the present invention relates to a credit administration system and method. More specifically, the present invention uses the control card that enables the secretariat to visualize the matters to be checked at each stage and the progress status in the credit workflow, thereby enabling the entire credit business to be visualized.
  • the present invention relates to a system and method for improving efficiency and strengthening an internal management system.
  • a sales department person in charge of a specific branch negotiates with a customer, and creates an approval document based on the customer negotiation.
  • the sales clerk at the same branch checks the format of the approval document created by the sales clerk and checks the contents of necessary documents.
  • the person in charge of the examination department at the head office approves the approval document created by the person in charge of the sales department.
  • the sales department and the credit office staff at the same branch confirm the satisfaction of the loan conditions, such as matching the approved approval document and contract documents.
  • the sales department, the credit administration department, and the account department in charge of the branch carry out the lending execution.
  • Patent Document 1 includes a customer information database that centrally manages information related to customers subject to loan examination, and a plurality of tasks for processing a series of tasks necessary for loan examination using the customer information database.
  • a loan screening system is disclosed that includes processing means and processing status management means for displaying the processing status of each business processing means in a list.
  • the status of each business of loan screening is managed in a database according to the processing order, so that employees at the head office and each branch can share information.
  • the sales department person in charge of the branch a in Country A negotiates with the customer and prepares the approval document.
  • the sales department clerk belonging to the branch a confirms the contents of the approval document.
  • the person in charge of the examination department belonging to the b branch in Country B approves the approval document.
  • the credit office staff member who belongs to the c branch in country C confirms the approved approval document and the contract documents, and finally the account office staff member who belongs to the c branch office performs the lending process. Is assumed.
  • Patent Document 1 the process of creating the approval document, which is a process upstream of the credit service, is subdivided and the processing status is managed, and the history up to the approval document draft is in charge, other employees in the branch, branch manager The staff of the head office examination department can confirm.
  • the process performed by the credit clerk who follows the credit operation does not mention the necessity of management and the advantage of promoting the visualization of check items.
  • the object of the present invention is to provide a credit card by using a control card that makes it possible to visualize matters to be checked at each stage and their progress in the credit flow. It is to provide a system and method for improving the efficiency of the entire business and strengthening the internal management system.
  • a credit administration system includes an approval document code, a scheduled signature date, a scheduled credit execution date, a status, and a check completion flag for a plurality of in-line rule items for each predetermined period in association with a control card code.
  • the approval code the conditions when the approval document is approved with conditions, the approval condition part including the deadline, and the loan condition part including the conditions necessary for lending
  • a control card creation unit for registering a record in the control card storage unit, wherein, based on the approval condition part and the lending condition part, an item to be checked is not checked among the plurality of in-line rule items.
  • a control card creation unit for storing a value indicating completion.
  • a credit administration method in accordance with a control card code, an approval code, a scheduled signature date, a scheduled credit execution date, a status, and a check completion flag for a plurality of in-line rule items for each predetermined period.
  • the credit card management system having a control card storage unit for storing the credit card management system includes a approval card code, a condition when the approval document is approved with a condition, and a deadline Receiving a deliberation condition part and a lending condition part including conditions necessary for lending, and a step in which the control card creating unit registers a record in the control card storage unit based on the received information.
  • the approval condition part and the lending condition part Of the inner regulations item, it stores a value indicating the unfinished items to be checked, to perform the steps.
  • control card that allows the administrative department to visualize the matters to be checked at each stage and the progress status thereof, double management of local regulations items and regions It can avoid situations that lead to deterioration in business efficiency, such as responding to regulatory inquiries, and can improve the overall efficiency of credit operations and strengthen the internal management system.
  • FIG. 1 shows an exemplary overall network configuration according to the present invention.
  • FIG. 2 shows a system configuration of an exemplary credit business management system according to the present invention.
  • FIG. 3 is a functional block diagram of an exemplary credit business management system according to the present invention.
  • FIG. 4 shows an example of information stored in an exemplary person-in-charge DB according to the present invention.
  • FIG. 5 shows an example of information stored in the exemplary approval document DB according to the present invention.
  • FIG. 6A shows an example of information stored in an exemplary control card DB according to the present invention.
  • FIG. 6B shows an example of information stored in an exemplary control card DB according to the present invention.
  • FIG. 6C shows an example of information stored in an exemplary control card DB according to the present invention.
  • FIG. 1 shows an exemplary overall network configuration according to the present invention.
  • FIG. 2 shows a system configuration of an exemplary credit business management system according to the present invention.
  • FIG. 3 is a functional block diagram of an exemplary credit
  • FIG. 6D shows an example of information stored in an exemplary control card DB according to the present invention.
  • FIG. 6E shows an example of information stored in an exemplary control card DB according to the present invention.
  • FIG. 7 shows an example of information stored in an exemplary regional regulation DB according to the present invention.
  • FIG. 8 shows an example of information stored in the exemplary contract condition check DB according to the present invention.
  • FIG. 9 shows an example of information stored in the exemplary collateral / guarantee check DB according to the present invention.
  • FIG. 10 shows an example of information stored in an exemplary document check DB according to the present invention.
  • FIG. 11 shows a processing flow for creating a control card.
  • FIG. 12 shows an example of a control card screen displayed on the client computer.
  • FIG. 13 shows an example of a contract check screen displayed on the client computer.
  • FIG. 14 shows an example of a control card screen displayed on the client computer.
  • control card is used to describe a group of information that enables the secretariat to visualize the matters to be checked at each stage and the progress status in the credit workflow.
  • FIG. 1 shows an exemplary overall network configuration according to the present invention.
  • a credit management system 100 a client computer 111 installed in a branch in country A, a client computer 112 installed in a branch in country B, and a client computer 113 installed in a branch in country C are shown.
  • And are communicably connected via an in-line network or the Internet 120.
  • the credit administration system 100 includes a person-in-charge database (DB) 101 that stores information related to bankers belonging to the bank 1, an approval document database (DB) 102 that stores approval documents, and a contract database (DB) that stores contracts. 103 and a control card database (DB) 104, and manages credit operations processed between branches around the world.
  • DB person-in-charge database
  • DB approval document database
  • DB contract database
  • DB contract database
  • DB control card database
  • the client computer 111 is a client computer installed in the country A branch office.
  • the person in charge at the branch a can access the credit administration system 100 via the client computer 111 and store the created approval document in the approval document DB 102.
  • the person in charge of the branch a can access the credit administration system 100 via the client computer 111 and store the created contract in the contract DB 103.
  • the client computer 112 is a client computer installed at a branch b in Country B.
  • the person in charge of the examination department of the branch b can access the credit administration system 100 via the client computer 112 and browse the approval document stored in the approval document DB 102.
  • the client computer 113 is a client computer installed in the c branch in country C.
  • the person in charge of middle back at branch c can access the credit administration system 100 via the client computer 113 and update the information in the control card DB 104.
  • FIG. 2 shows the system configuration of the credit administration system 100.
  • the credit office management system 100 includes a CPU 201, a RAM 202, a ROM 203, a storage 204, a connection interface 205, and a network interface 206.
  • the components 201 to 206 are connected via a bus 210 so that they can communicate with each other.
  • the connection interface 205 is an interface for connecting various devices to the credit office management system 100.
  • a display, a keyboard, a mouse, an external storage device, and the like can be connected to the credit office management system 100 via the connection interface 205.
  • the network interface 206 is connected to the local network or the Internet 120 through a communication line.
  • the network interface 206 controls data input / output between the intra-bank network or the Internet 120 and the credit administration system 100 based on the control of the CPU 201.
  • the connection between the network interface 206 and the in-line network or the Internet 120 may be a wired connection or a wireless connection.
  • FIG. 3 is a functional block diagram of the credit administration system 100.
  • the credit administration system 100 includes a person-in-charge DB 101, an approval document DB 102, a contract document DB 103, a control card DB 104, a regional regulation DB 301, a contract condition check DB 302, a collateral / guarantee check DB 303, a document check DB 304, a document DB 305, and an approval document data management unit.
  • 310 a control card creation unit 311, a contract condition setting unit 312, a collateral / guarantee setting unit 313, and a document setting unit 314.
  • the person-in-charge DB 101 stores information on bank employees belonging to the bank 1.
  • the person-in-charge DB 101 includes a person-in-charge code, a person-in-charge name, an affiliated branch code, an affiliated branch name, and a role (“0: Other”, “1: Front”, “2: Screening Department”, “3: Middle Back”, “4: Back”) are stored.
  • the approval document DB 102 stores information related to the approval document.
  • the approval document DB 102 stores information on the person in charge (responsible branch code, person code) who created the approval document in association with the approval document code that uniquely identifies the approval document.
  • a plurality of parts including information constituting the approval document (approval condition part, loan condition part, credit information part, case summary part, and market part), approval flag ("0: before approval", "1: approved”) ) And an electronic approval document file are stored.
  • each part stores a structured document such as XML.
  • XML structured document
  • the approval condition part includes the conditions when the approval document is approved under certain conditions, the answer written when the conditions are satisfied, and the expiration date.
  • the lending condition part includes conditions necessary for lending such as obligor information, credit type, credit amount, credit execution date, credit execution country, collateral / guarantee.
  • the credit information part includes the credit information of the debtor.
  • the case summary part includes credit transaction history information.
  • the market part includes market information related to credit transactions.
  • the contract DB 103 stores an electronic contract file in association with a contract code that uniquely identifies the contract.
  • the contract document DB 103 is not provided, and an electronic contract document file can be stored in a document DB 305 described later.
  • Approval approval identifies whether the approval request has been approved by the Examining Department.
  • the credit administration system 100 stores “1: Complete” in the approval document approval.
  • the contract check identifies whether the consistency check between the finalized approval document and the contract has been completed.
  • the credit administration system 100 stores “1: Complete” in the contract check.
  • the document identifies whether the document has been requested.
  • the credit administration system 100 sets the document as one of a pre-signature document, a post-signature document, or a post-credit execution document according to the document acquisition deadline set in the document check DB 304. To do. Thereafter, in this embodiment, when the document check DB 304 described later confirms the collection of all the documents for which the acquisition deadline is set for a predetermined period (before signature, after signature, or after execution of credit), the credit administration system 100 Stores “1: Complete” in a document for a predetermined period.
  • Local regulations identify whether local regulatory items have been observed.
  • the credit administration system 100 stores “1: Complete” in the regional regulations.
  • the signature identifies whether the contracting party has signed the contract. In the present embodiment, when all the signatures are confirmed in the contract condition check DB 302 described later, the credit administration system 100 stores “1: Complete” in the signature.
  • the contract condition check DB 302 stores check items set based on the lending conditions of the approval document.
  • the contract condition check DB 302 includes the obligor information, the guarantor information, the credit type, the credit amount, the credit execution date, the credit in association with the loan code of the control card DB 104.
  • Execution country and signature information are stored.
  • the signature information the signer name or “1: confirmed” is stored, and in each check item excluding the signature information, “0: unconfirmed” or “1: confirmed” is stored.
  • the credit office management system 100 stores “1: confirmed” in the check item.
  • the collateral / guarantee check DB 303 stores collateral / guarantee information included in the lending conditions of the proposal.
  • the collateral / guarantee check DB 303 includes a collateral / guarantee name, a confirmation flag (“0: unconfirmed”, “1: confirmed”) associated with the loan code of the control card DB 104. )) And the fulfillment deadline are stored.
  • the credit office management system 100 stores “1: confirmed” in the confirmation flag.
  • the document check DB 304 stores information on collected documents.
  • the document check DB 304 includes a collection document name, a confirmation flag (“0: unconfirmed”, “1: confirmed”) associated with the loan code of the control card DB 104, And the acquisition deadline is stored.
  • the credit administration system 100 upon receiving a document confirmation instruction from the client computer 111 or the like, stores “1: confirmed” in the confirmation flag.
  • the approval document data management unit 310 also transmits the approval document code, the approval condition part, the lending condition part, and the designation information of the related department to the control card creation unit 311.
  • the control card creation unit 311 registers a record in the control card DB 104 in response to receiving the approval document code, the approval condition part, the lending condition part, and the related department designation information from the approval document data management unit 310.
  • the control card creation unit 311 refers to the credit execution country included in the lending condition part and registers the number of records corresponding to the number of credit execution countries. For example, when there is one credit execution country, one record is registered, and when there are two credit execution countries, two records are registered. When registering a record, the control card creation unit 311 generates and stores a control card code corresponding to the approval document code and a loan code that can uniquely identify a plurality of loans in the same control card code.
  • control card creation unit 311 stores the received approval code, the middle back branch code included in the designated information of the related department, the credit execution country, the expected signature date, and the expected credit execution date included in the loan condition part, respectively. To do. About the person-in-charge code, the control card creation unit 311 can set based on debtor information included in the lending condition part.
  • the control card creation unit 311 sets a symbol (“ ⁇ ”) for the satisfaction of the condition that does not match the expiration date based on the received approval condition part. When the conditions for approval of approval are not set, the control card creation unit 311 sets a symbol (“-”) for all the condition satisfaction.
  • the control card creation unit 311 sets a symbol (“ ⁇ ”) for the collateral / guarantee that does not match the fulfillment deadline based on the collateral / guarantee included in the received lending condition part.
  • the control card creation unit 311 After registering the record in the control card DB 104, the control card creation unit 311 sets the contract code in the record of the control card DB 104 in response to receiving the contract creation data.
  • the contract document creation data includes a loan code and a contract code.
  • the contract condition setting unit 312 registers a record in the contract condition check DB 302 based on the lending condition part.
  • the contract condition setting unit 312 registers a record in association with the loan code created by the control card creation unit 311.
  • the contract condition setting unit 312 sets “0: unconfirmed” for the item included in the lending condition part, and sets the symbol “ ⁇ ” for the item not included in the lending condition part.
  • the contract condition setting unit 312 sets the party name of the contract specified in the lending condition part.
  • the collateral / guarantee setting unit 313 registers a record in the collateral / guarantee check DB 303 based on the collateral / guarantee included in the lending condition part.
  • the collateral / guarantee setting unit 313 registers a record based on the collateral / guarantee name and the fulfillment deadline included in the lending condition part in association with the loan code created by the control card creation unit 311. At this time, “0: unconfirmed” is set as an initial value in the confirmation flag.
  • the collateral / guarantee setting unit 313 determines whether different collateral / guarantees are set for each loan to each credit execution country. When different collateral / guarantee is set, the collateral / guarantee setting unit 313 registers a corresponding collateral / guarantee record for each loan code corresponding to the loan to each credit executing country.
  • the collateral / guarantee setting unit 313 registers a collateral / guarantee record only for any one loan code.
  • the selection of the loan code can be performed by any method, for example, giving priority to the loan code handled by the middle back of the same branch code as the front or depending on the size of the branch designated as the middle back. .
  • the collateral / guarantee setting unit 313 registers a corresponding collateral / guarantee record for each loan code corresponding to a loan to each credit executing country. To do. After that, on the collateral / guarantee check screen described later, the person in charge in any one of the multiple credit execution countries sends a satisfaction confirmation instruction by selecting the check field via the client computer 111 or the like. In response to this, the credit administration system 100 stores “1: confirmed” in the confirmation flag of the collateral / guarantee check DB 303 for all of a plurality of credit executing countries for which the same collateral / guarantee is set. . Thereby, in all the plurality of credit execution countries, the result registered by the person in charge of any one of the plurality of credit execution countries can be shared.
  • the document setting unit 314 registers a record in the document check DB 304 in response to receiving the document list update data from the client computer 111 or the like.
  • the document list update data includes a loan code, a collection document name, and an acquisition deadline.
  • the document setting unit 314 registers a record based on the document list update data. At this time, “0: unconfirmed” is set as an initial value in the confirmation flag.
  • the document setting unit 314 also sets “0: Incomplete” to the document of the control card record that matches the acquisition deadline based on the document list update data.
  • Control card creation process The control card creation process will be described with reference to FIG. FIG. 11 shows a processing flow for creating a control card. Assume that the person-in-charge DB 101 of the credit administration system 100 stores the records shown in FIG. It is assumed that the record shown in FIG. 7 is also stored in the regional regulation DB 301 of the credit administration system 100.
  • the approval document data management unit of the credit administration system 100 registers a record in the approval document DB 102 in S1102 in response to receiving the approval document related data from the client computer 111 or the like.
  • the branch code to which the person in charge of creating the approval document belongs the person in charge code, information constituting the approval document divided into a plurality of parts, and all information constituting the approval document are used.
  • the agenda data management section 310 Upon receiving the agenda-related data including the electronic agenda file created and the designated information (examination department, middle back, back) of the related departments related to the target award, the agenda data management section 310 receives the agenda data.
  • a book code (3333333) is created, and a record is registered in the approval document DB 102. At this time, “0: before approval” is set as an initial value in the approval flag.
  • control card creation unit 311 registers a record in the control card DB 104 based on the information received from the approval document data management unit 310.
  • the control card creation unit 311 receives the approval code (3333333) and the middle information included in the designation information of the related department.
  • 3333333 One record based on back branch code (333), credit execution country (country C) included in the loan condition part, signature date (April 10, 2015), credit execution date (April 24, 2015) sign up.
  • control card creation unit 311 When registering a record, the control card creation unit 311 generates and stores a control card code (C3333333) and a loan code (C3333) corresponding to the approval code.
  • the control card creation unit 311 sets the person-in-charge code (333-22222) based on the obligor information included in the lending condition part, and sets the status to “0: before signature” as the initial value.
  • control card creation unit 311 sets a symbol (“-”) for the condition satisfaction that does not match the satisfaction deadline based on the received approval condition part.
  • control card creation unit 311 displays a symbol (“-”) in the satisfaction condition before the signature and the satisfaction condition after the execution of credit. ) Is set.
  • control card creation unit 311 sets a symbol (“ ⁇ ”) for the condition fulfillment that does not match the fulfillment deadline based on the collateral / guarantee included in the received lending condition part.
  • control card creation unit 311 searches the regional regulation DB 301 based on the credit execution country included in the received lending condition part, and sets the symbol “-” in the regional regulation when there is no regional regulation item. .
  • the contract condition setting unit 312 of the credit office management system 100 registers a record in the contract condition check DB 302 based on the lending condition part.
  • the contract condition setting unit 312 registers the record shown in FIG. 8 in association with the loan code (C3333) created by the control card creation unit 311.
  • C3333 loan code
  • a lending condition part that does not include guarantor information is received, and the symbol “-” is set in the guarantor information.
  • signature information signature 1, signature 2, signature 3
  • the contract condition setting unit 312 sets the signer 1 to the signature 1. Then, the sign “ ⁇ ” is set for the signature 2 and the signature 3.
  • the collateral / guarantee setting unit 313 of the credit administration system 100 registers a record in the collateral / guarantee check DB 303 based on the collateral / guarantee included in the lending condition part.
  • the document setting unit 314 of the credit administration system 100 registers a record in the document check DB 304 in response to receiving the document list update data from the client computer 111 or the like. Subsequently, in S1110, the document setting unit 314 sets “0: Incomplete” to the document of the control card record that matches the fulfillment deadline based on the document list update data.
  • the document setting unit 314 receives the document list update data including the loan code (C3333), the collection document name (document 6), and the expiration date before signature (2015/4/9). Assume that the indicated record has been registered. Subsequently, it is assumed that the document setting unit 314 sets “0: Incomplete” to the document before the signature of the control card record based on the document list update data.
  • control card creation unit 311 sets the contract code in the record of the control card DB 104 in response to receiving the contract creation data.
  • the contract card creation data 311 including the loan code (C3333) and the contract code (32345) is received, and the control card creation unit 311 sets the contract code of the control card DB 104.
  • FIGS. 12 and 14 show examples of control card screens displayed on the client computer.
  • FIG. 13 shows an example of a contract check screen displayed on the client computer.
  • the person-in-charge DB 101, the approval document DB 102, the control card DB 104, the regional regulation DB 301, the contract check DB 302, the collateral / guarantee check DB 303, and the document check DB 304 of the credit administration system 100 are respectively shown in FIGS. 4, 5, and 6A. Assume that the records shown in FIGS. 7, 8, 9, and 10 are stored.
  • the person in charge 2 transmits authentication information including a person-in-charge code (111-22222) and a password to the credit administration system 100 via the client computer 111 and succeeds in authentication based on the authentication information.
  • the credit management system 100 can display a list of control cards handled by the person who succeeds in the authentication based on the control card DB 104.
  • the credit administration system 100 provides the client computer 111 with a list including two control cards handled by the person in charge (person in charge 2) who has been successfully authenticated, and is specified by the loan code (X1111). 12 is received from the client computer 111, and the control card screen shown in FIG. 12 is provided to the client computer 111.
  • a document list related to the control card is displayed.
  • the front person in charge can upload a document in association with a loan code at any timing after the creation of the control card record, and can view the uploaded document from the document list.
  • the approval document approval in the column 1201 is stored in the approval flag of the record specified by the approval document code (2222222) of the approval document DB 102 shown in FIG. Thus, “1: Complete” is already stored.
  • the credit administration system 100 displays the approval document screen ( (Not shown) can be provided.
  • the provided approval request screen is displayed by selecting some or all of the plurality of parts constituting the approval request in accordance with the role of the person in charge who has logged in. For example, when the front person in charge who created the approval document is logged in, a screen including all the parts constituting the approval document is displayed. On the other hand, when the person in charge of middle back is logged in, only the parts necessary for credit affairs are selected and displayed.
  • the credit administration system 100 displays the approval document condition screen (FIG. Not shown).
  • the approval document condition screen includes information on the approval condition part.
  • the contract check in the column 1201 stores “0: Incomplete” as shown in FIG.
  • the person in charge 2 selects the contract check (“0: Incomplete”) in the column 1201 shown in FIG. 12 via the client computer 111
  • the credit administration system 100 is shown in FIG.
  • a contract condition check screen as shown in FIG. 13 can be provided.
  • Person in charge 2 confirms the consistency between the contents displayed in the approval document-lending conditions on the contract condition check screen and the contents of the contract.
  • the person in charge 2 selects, for example, the document list 1203 on the control card screen displayed in FIG. 12 via the client computer 111 and selects a contract from the document list. Check the consistency while browsing the stored electronic contract file.
  • the credit administration system 100 when the person in charge 2 transmits a consistency confirmation instruction by selecting a check column via the client computer 111, the credit administration system 100 adds “1” to the corresponding check item in the contract condition check DB 302. : Confirmed ”is stored. As described above, in the present embodiment, when the consistency of all the contract conditions except for the signature information is confirmed in the contract condition check DB 302, the credit administration system 100 performs “1” for the contract check in the control card DB 104. : Complete ”is stored.
  • the document check screen includes a request document name and a check field, and the person in charge 2 displays the document list displayed when the request document displayed on the document check screen is selected as the document list 1203 on the control card screen. To make sure that it is present within.
  • the credit administration system 100 when the person in charge 2 transmits a request for confirming the selection by selecting the check column via the client computer 111, the credit administration system 100 sets “1: Confirmation” to the corresponding check item in the document check DB 304. "Completed” is stored. As described above, in this embodiment, when the document check DB 304 confirms the collection of all the documents whose acquisition deadlines are set for a predetermined period (before signature, after signature, or after execution of credit), the credit administration system 100 stores “1: Complete” in the document for a predetermined period in the control card DB 104.
  • the area regulation in the column 1201 stores “0: Incomplete” as shown in FIG.
  • the credit administration system 100 displays the regional regulation check screen (FIG. Not shown).
  • the region regulation check screen includes a region regulation item name and a check column, and the person in charge 2 confirms that the contract contents comply with the region regulation item displayed on the region regulation check screen.
  • the credit administration system 100 sets “1: Complete” as the regional regulation of the control card DB 104. Store.
  • the control card record specified by the loan code (X1111) in the control card DB 104 has all the in-line rule items before signature as “1: Complete” as shown in FIG. 6B.
  • the person in charge 2 presses the status change button 1204 on the screen of the control card shown in FIG.
  • the status of the control card record specified by the loan code (X1111) is updated from “0: before signature” to “1: after signature” as shown in FIG. 6C.
  • the credit administration system 100 when the status of the control card record is updated from “0: before signature” to “1: after signature”, the credit administration system 100, as shown in FIG.
  • the client computer 111 is provided with a screen of the control card including the later in-line rule items.
  • the signature in the column 1401 stores “0: Incomplete” as shown in FIG.
  • the person in charge 2 selects the signature (“0: Incomplete”) in the column 1201 shown in FIG. 14 via the client computer 111
  • the credit administration system 100 will receive the contract conditions shown in FIG. 8.
  • a signature check screen (not shown) can be provided.
  • the signature check screen includes a signer name and a check field
  • the person in charge 2 confirms that any number of signers displayed on the signature check screen have signed the contract.
  • the person in charge 2 selects, for example, the document list 1203 on the control card screen displayed in FIG. 14 via the client computer 111 and selects a contract from the document list. Confirm the signature by browsing the stored electronic contract file.
  • the credit administration system 100 when the person in charge 2 transmits a signature confirmation instruction by selecting a check column via the client computer 111, the credit administration system 100 adds “1:” to the corresponding check item in the contract condition check DB 302. “Confirmed” is stored. As described above, in this embodiment, when all the book titles are confirmed in the contract condition check DB 302, the credit office management system 100 stores “1: Complete” in the signature of the control card DB 104.
  • the collateral / guarantee after signature in the column 1401 stores “0: Incomplete” as shown in FIG.
  • the credit administration system 100 displays A collateral / guarantee check screen (not shown) can be provided based on the collateral / guarantee check DB 303 shown in FIG.
  • the collateral / guarantee check screen includes a collateral / guarantee name and a check column, and the person in charge 2 confirms that the collateral / guarantee displayed on the collateral / guarantee check screen is satisfied.
  • the credit administration system 100 sets “1” in the corresponding confirmation flag of the collateral / guarantee check DB 303. : Confirmed ”is stored.
  • the collateral / guarantee check DB 303 confirms the satisfaction of all the collateral / guarantees for which the fulfillment deadline is set for a predetermined period (before signing, after signing, or after executing credit)
  • the credit office management system 100 stores “1: Complete” in the collateral / guarantee for a predetermined period in the control card DB 104.
  • the control card record specified by the loan code (X1111) in the control card DB 104 has all in-line rule items “1: Complete” as shown in FIG. 6D.
  • the status change button 1402 on the screen of the control card shown in FIG. 14 through the client computer 111 in a state where all the in-line rule items are “1: Complete” As shown in FIG. 6E, the status of the control card record specified by the loan code (X1111) is updated from “1: after signature” to “2: business completion”.
  • control card that enables the administrative department to visualize the matters to be checked at each stage and the progress status thereof, double management of the in-line rule items that have conventionally occurred It can avoid situations that lead to deterioration in business efficiency, such as responding to inquiries and local regulations, and can improve the efficiency of the entire credit business and strengthen the internal management system.
  • the product-specific regulations identify whether or not the in-line rules to be checked have been observed according to the products (contract type) provided by the bank 1.
  • the credit administration system 100 stores “1: Complete” in the product-specific regulations.
  • the credit office management system 100 further includes a product-specific check DB 306 and a product-specific setting unit 315.
  • the product-specific check DB 306 stores information on items to be checked for specific products based on the lending conditions of the approval document.
  • the item-specific check DB 306 stores an item name and a confirmation flag (“0: unconfirmed”, “1: confirmed”) in association with the loan code in the control card DB 104.
  • the credit administration system 100 upon receiving a confirmation instruction from the client computer 111 or the like, stores “1: confirmed” in the confirmation flag.
  • the product-specific setting unit 315 registers a record in the product-specific check DB 303 based on the lending condition part.
  • the product-specific setting unit 313 associates the loan code created by the control card creation unit 311 with the item to be checked in the product to which the contract corresponds and registers the record.
  • “0: unconfirmed” is set as an initial value in the confirmation flag.
  • the product-specific setting unit 315 can set the implementation of an environmental assessment as an item to be checked in the product to which the contract corresponds.
  • the present invention can take an embodiment as, for example, a system, apparatus, method, program, or storage medium.

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Engineering & Computer Science (AREA)
  • Finance (AREA)
  • Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Technology Law (AREA)
  • Development Economics (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

　コントロールカードコードに関連付けて稟議書コード、署名予定日、与信実行予定日、ステータス、および所定期間ごとに複数の行内規程項目のチェック完了フラグを格納するコントロールカード記憶部と、稟議書コード、条件付きで稟議書が決裁される場合の条件、および充足期限を含む稟議条件パート、および貸出に必要な条件を含む貸出条件パートを受信することに応答して、前記コントロールカード記憶部にレコードを登録するコントロールカード作成部であって、前記稟議条件パートおよび前記貸出条件パートに基づいて、前記複数の行内規程項目のうち、チェックすべき項目に未完了を示す値を格納する、コントロールカード作成部とを備えた与信事務管理システム。

Description

与信事務管理システムおよびその方法
　本発明は、与信事務管理システムおよびその方法に関する。より詳細に言えば、本発明は、与信業務フローにおいて、事務部が各段階でチェックすべき事項とその進捗状況とを可視化することを可能としたコントロールカードを使用することによって、与信業務全体の効率化と内部管理体制の強化を図るシステムおよびその方法に関する。
　近年、優れた商品・サービスを武器に世界各地で活動を行うグローバル企業が増えている。グローバル企業の多くは、複数の国に拠点を有する。銀行もまた、世界各地の顧客ニーズに対応すべく、世界各地に支店を設置し、金融サービスを提供している。
　従来、銀行における与信業務は、特定の支店で完結するケースが多かった。具体的には、まず、特定の支店の営業部担当者が顧客折衝を行い、顧客折衝に基づいて稟議書の作成を行う。次に、同支店の営業部事務担当者が、営業部担当者が作成した稟議書の形式点検、必要書類などの内容確認を行う。その後、本店の審査部担当者が、営業部担当者が作成した稟議書の決裁を行う。続いて、営業部と同支店の与信事務部担当者が、決裁済稟議書と契約書類の突合等、貸出条件充足の確認を行う。最後に、営業部および与信事務部と同支店の勘定事務部担当者が、貸出実行の事務処理を行う。
　特許文献１には、融資審査の対象となる顧客に関する情報を一元的に管理する顧客情報データベースと、顧客情報データベースを利用して融資審査に必要な一連の業務をそれぞれ処理するための複数の業務処理手段と、各業務処理手段による処理状況を一覧で表示する処理状況管理手段とを備えた融資審査システムが開示されている。特許文献１に記載の融資審査システムでは、融資審査の各業務のステータスを処理順序に従ってデータベースで管理することで、本店および各支店の行員が情報を共有することができる。
　今日、企業のグローバル化に伴い、与信業務は、世界各地の支店間で処理される形態へと変化してきた。例えば、一例として、Ａ国に本社を持つＸ社が、出張所を有するＣ国で融資実行を希望するケースがあげられる。
　この場合、銀行における与信業務において、まず、Ａ国のａ支店に所属する営業部担当者が顧客折衝を行い、稟議書の作成を行う。次に、ａ支店に所属する営業部事務担当者が稟議書の内容確認を行う。その後、Ｂ国のｂ支店に所属する審査部担当者が稟議書の決裁を行う。続いて、Ｃ国のｃ支店に所属する与信事務部担当者が決裁済稟議書と契約書類の確認を行い、最後にｃ支店に所属する勘定事務部担当者が貸出実行の事務処理を行うことが想定される。
　特許文献１では、与信業務の上流の一工程である稟議書作成の処理について、細分化して処理状況を管理し、稟議書起票までの履歴を担当者、支店内の他の行員、支店長、本店審査部の行員等が確認することができる。しかしながら、与信業務の後続の与信事務部担当者が行う工程については、管理の必要性やチェック項目の可視化を推進する利点について言及していない。
　与信業務が世界各地の支店間で処理される場合、顧客と折衝する営業部と貸出実行を行う事務部の業務は、同一国内の支店間で処理される場合と比較して一層複雑化し、両者の連携強化が求められることとなる。具体的には、まず第１に、与信業務を行うにあたり、銀行は行内規程を遵守する必要がある。そのため、与信業務では、行内規程遵守のために確認すべき項目を漏れなく抽出し、適切な部署が項目のチェックを行う必要がある。しかしながら、関係部署が異なる国にある場合、両者の連携をとることが難しく、行内規程項目の二重管理や責任の所在が不明確となる事態も散見された。
　第２に、与信業務では、すべての与信取引に対して世界共通でチェックすべき行内規程項目とは別に、貸出実行がなされる地域ごとに遵守すべき地域規制項目が存在する。関係部署が異なる国にある場合、Ａ国の営業部担当者がＣ国の地域規制項目を漏れなく抽出することは、同一国内の支店間で処理される場合と比較して一層難しく、地域規制の照会対応等に時間を要し、業務効率の悪化につながっていた。
　第３に、与信業務では、顧客の様々な情報を取り扱うこととなるが、銀行はその情報の取り扱いに十分に注意しなければならない。例えば、顧客と折衝を行う営業部は原則としてすべての顧客情報を閲覧する権限が与えられるが、事務部は、担当する業務遂行のために必要最低限の顧客情報を閲覧する権限が与えられるべきである。関係部署が異なる国にある場合、顧客情報に関するアクセス制御を徹底することは、同一国内の支店間で処理される場合と比較して一層難しく、Ａ国の営業部担当者が、何らアクセス制御がされていない電子文書をＣ国の事務部に転送してしまうことも想定される。
特開２００５－１３４９３７号公報
　本発明の目的は、このような状況に鑑み、与信業務フローにおいて、事務部が各段階でチェックすべき事項とその進捗状況とを可視化することを可能としたコントロールカードを使用することによって、与信業務全体の効率化と内部管理体制の強化を図るシステムおよびその方法を提供することである。
　本発明の一態様としての、与信事務管理システムは、コントロールカードコードに関連付けて稟議書コード、署名予定日、与信実行予定日、ステータス、および所定期間ごとに複数の行内規程項目のチェック完了フラグを格納するコントロールカード記憶部と、稟議書コード、条件付きで稟議書が決裁される場合の条件、および充足期限を含む稟議条件パート、および貸出に必要な条件を含む貸出条件パートを受信することに応答して、前記コントロールカード記憶部にレコードを登録するコントロールカード作成部であって、前記稟議条件パートおよび前記貸出条件パートに基づいて、前記複数の行内規程項目のうち、チェックすべき項目に未完了を示す値を格納する、コントロールカード作成部とを備える。
　本発明の他の態様としての、与信事務管理方法は、コントロールカードコードに関連付けて稟議書コード、署名予定日、与信実行予定日、ステータス、および所定期間ごとに複数の行内規程項目のチェック完了フラグを格納するコントロールカード記憶部を備えた与信事務管理システムにおいて、前記与信事務管理システムのコントロールカード作成部が、稟議書コード、条件付きで稟議書が決裁される場合の条件、および充足期限を含む稟議条件パート、および貸出に必要な条件を含む貸出条件パートを受信するステップと、前記コントロールカード作成部が、前記受信した情報に基づいて、前記コントロールカード記憶部にレコードを登録するステップであって、前記稟議条件パートおよび前記貸出条件パートに基づいて、前記複数の行内規程項目のうち、チェックすべき項目に未完了を示す値を格納する、ステップとを実行する。
　本発明によれば、事務部が各段階でチェックすべき事項とその進捗状況とを可視化することを可能としたコントロールカードを使用することによって、従来起きていた行内規程項目の二重管理や地域規制の照会対応等、業務効率の悪化につながる事態を回避し、与信業務全体の効率化と内部管理体制の強化を図ることができる。
　さらに、本発明によれば、与信業務に関わる担当者の所属支店および役割に応じて、必要最小限の情報開示を提供することで、顧客情報に関するアクセス制御を徹底することができる。
図１は、本発明に係る例示的な全体ネットワーク構成を示す。 図２は、本発明に係る例示的な与信事務管理システムのシステム構成を示す。 図３は、本発明に係る例示的な与信事務管理システムの機能ブロック図である。 図４は、本発明に係る例示的な担当者ＤＢに格納された情報の一例を示す。 図５は、本発明に係る例示的な稟議書ＤＢに格納された情報の一例を示す。 図６Ａは、本発明に係る例示的なコントロールカードＤＢに格納された情報の一例を示す。 図６Ｂは、本発明に係る例示的なコントロールカードＤＢに格納された情報の一例を示す。 図６Ｃは、本発明に係る例示的なコントロールカードＤＢに格納された情報の一例を示す。 図６Ｄは、本発明に係る例示的なコントロールカードＤＢに格納された情報の一例を示す。 図６Ｅは、本発明に係る例示的なコントロールカードＤＢに格納された情報の一例を示す。 図７は、本発明に係る例示的な地域規制ＤＢに格納された情報の一例を示す。 図８は、本発明に係る例示的な契約条件チェックＤＢに格納された情報の一例を示す。 図９は、本発明に係る例示的な担保・保証チェックＤＢに格納された情報の一例を示す。 図１０は、本発明に係る例示的なドキュメントチェックＤＢに格納された情報の一例を示す。 図１１は、コントロールカードを作成する処理フローを示す。 図１２は、クライアントコンピューターに表示される、コントロールカードの画面の一例を示す。 図１３は、クライアントコンピューターに表示される、契約書チェック画面の一例を示す。 図１４は、クライアントコンピューターに表示される、コントロールカードの画面の一例を示す。
　以下、添付した図面を参照して、本発明の実施形態に係る与信事務管理システム、およびその方法を詳細に説明する。
　本明細書では、行内規程・地域規制遵守のために確認すべき項目のうち、すべての与信取引に対して世界共通でチェックすべき項目を用語「行内規程項目」を用いて説明する。
　本明細書では、行内規程・地域規制遵守のために確認すべき項目のうち、貸出実行がなされる地域ごとに遵守すべき項目を用語「地域規制項目」を用いて説明する。
　本明細書では、顧客と折衝を行う営業部を用語「フロント」、与信事務部を用語「ミドルバック」、勘定事務部を用語「バック」を用いて説明する。
　本明細書では、与信業務フローにおいて、事務部が各段階でチェックすべき事項とその進捗状況とを可視化することを可能とした情報群を用語「コントロールカード」を用いて説明する。
　以降の実施形態では、Ａ国にａ支店、Ｂ国にｂ支店、Ｃ国にｃ支店を有する銀行１を例に用いて説明する。
　図１は、本発明に係る例示的な全体ネットワーク構成を示す。図１において、与信事務管理システム１００、Ａ国のａ支店に設置されたクライアントコンピューター１１１、Ｂ国のｂ支店に設置されたクライアントコンピューター１１２、およびＣ国のｃ支店に設置されたクライアントコンピューター１１３が、行内ネットワークまたはインターネット１２０を介して通信可能に接続される。
　与信事務管理システム１００は、銀行１に所属する行員に関する情報を格納する担当者データベース（ＤＢ）１０１、稟議書を格納する稟議書データベース（ＤＢ）１０２、契約書を格納する契約書データベース（ＤＢ）１０３、およびコントロールカードデータベース（ＤＢ）１０４を備え、世界各地の支店間で処理される与信業務を管理する。与信事務管理システム１００は、各国の行員がクライアントコンピューター１１１等を介して与信事務管理システム１００に接続してきた際、担当者ＤＢ１０１に格納された行員の所属支店および役割に応じて、稟議書ＤＢ１０２、契約書ＤＢ１０３、コントロールカードＤＢ１０４の情報を制御して公開する。
　クライアントコンピューター１１１は、Ａ国ａ支店に設置されたクライアントコンピューターである。例えば、ａ支店のフロント担当者は、クライアントコンピューター１１１を介して与信事務管理システム１００にアクセスし、作成した稟議書を稟議書ＤＢ１０２に格納することができる。また、ａ支店のフロント担当者は、クライアントコンピューター１１１を介して与信事務管理システム１００にアクセスし、作成した契約書を契約書ＤＢ１０３に格納することができる。
　クライアントコンピューター１１２は、Ｂ国のｂ支店に設置されたクライアントコンピューターである。例えば、ｂ支店の審査部担当者は、クライアントコンピューター１１２を介して与信事務管理システム１００にアクセスし、稟議書ＤＢ１０２に格納された稟議書を閲覧することができる。
　クライアントコンピューター１１３は、Ｃ国のｃ支店に設置されたクライアントコンピューターである。例えば、ｃ支店のミドルバック担当者は、クライアントコンピューター１１３を介して与信事務管理システム１００にアクセスし、コントロールカードＤＢ１０４の情報を更新することができる。
　図２は、与信事務管理システム１００のシステム構成を示す。与信事務管理システム１００は、ＣＰＵ２０１、ＲＡＭ２０２、ＲＯＭ２０３、ストレージ２０４、接続インターフェース２０５およびネットワークインターフェース２０６を備える。各コンポーネント２０１～２０６は、バス２１０を介して相互に通信可能に接続される。
　ＣＰＵ２０１は、デバイスおよび回路のそれぞれを制御し、並びに演算およびデータ処理を行う。ＲＡＭ２０２は一時記憶領域であり、ＣＰＵ２０１による演算実行時に使用される。ＲＯＭ２０３は、種々のプログラムを格納する記憶領域である。ストレージ２０４は、例えばＨＤＤ（Hard Disk Drive）、ＳＳＤ（Solid State Drive）などにより構成され、様々なデータを格納する。ＣＰＵ２０１の制御に基づいて、データがストレージ２０４から読み取られ、およびデータがストレージ２０４に書き込まれる。
　接続インターフェース２０５は、与信事務管理システム１００に種々のデバイスを接続するためのインターフェースである。例えば、接続インターフェース２０５を介して、ディスプレイ、キーボード、マウス、外部記憶装置等を与信事務管理システム１００に接続することができる。
　ネットワークインターフェース２０６は、通信回線を通じて行内ネットワークまたはインターネット１２０に接続される。そして、ネットワークインターフェース２０６は、ＣＰＵ２０１の制御に基づいて行内ネットワークまたはインターネット１２０および与信事務管理システム１００の間のデータの入出力を制御する。ネットワークインターフェース２０６と行内ネットワークまたはインターネット１２０との間の接続は、有線接続および無線接続のいずれであってもよい。
　図３は、与信事務管理システム１００の機能ブロック図である。与信事務管理システム１００は、担当者ＤＢ１０１、稟議書ＤＢ１０２、契約書ＤＢ１０３、コントロールカードＤＢ１０４、地域規制ＤＢ３０１、契約条件チェックＤＢ３０２、担保・保証チェックＤＢ３０３、ドキュメントチェックＤＢ３０４、ドキュメントＤＢ３０５、稟議書データ管理部３１０、コントロールカード作成部３１１、契約条件設定部３１２、担保・保証設定部３１３、およびドキュメント設定部３１４を備える。
　担当者ＤＢ１０１は、銀行１に所属する行員に関する情報を格納する。一実施形態では、図４に示されるように、担当者ＤＢ１０１には、担当者コード、担当者名、所属支店コード、所属支店名、および役割（「０：その他」、「１：フロント」、「２：審査部」、「３：ミドルバック」、「４：バック」）が格納される。
　稟議書ＤＢ１０２は、稟議書に関する情報を格納する。一実施形態では、図５に示されるように、稟議書ＤＢ１０２には、稟議書を一意に識別する稟議書コードに関連付けて、稟議書を作成した担当者情報（担当支店コード、担当者コード）、稟議書を構成する情報を含む複数のパート（稟議条件パート、貸出条件パート、信用情報パート、案件概要パート、および市場パート）、決裁フラグ（「０：決裁前」、「１：決裁済み」）および電子稟議書ファイルが格納される。
　本実施形態では、各パートには、例えばＸＭＬなど、構造化文書が格納される。以下、各パートについて説明する。
　稟議条件パートには、条件付きで稟議書が決裁される場合の条件、条件が充足した際に記述される回答、および充足期限が含まれる。貸出条件パートには、債務者情報、与信の種類、与信金額、与信実行日、与信実行国、担保・保証など、貸出に必要な条件が含まれる。信用情報パートには、債務者の信用情報が含まれる。案件概要パートには、与信取引の経緯情報が含まれる。市場パートには、与信取引に関連する市場情報が含まれる。
　契約書ＤＢ１０３は、契約書を一意に識別する契約書コードに関連付けて、電子契約書ファイルを格納する。別の実施形態では、契約書ＤＢ１０３を設けず、後述のドキュメントＤＢ３０５に電子契約書ファイルを格納することもできる。
　コントロールカードＤＢ１０４は、コントロールカードに関する情報を格納する。一実施形態では、図６Ａ～図６Ｅに示されるように、コントロールカードＤＢ１０４には、コントロールカードを一意に識別可能なコントロールカードコード、貸付コード、稟議書ＤＢ１０２の稟議書コード、契約書ＤＢ１０３の契約書コード、ミドルバック支店コード、ミドルバック担当者コード、与信実行国、署名予定日、与信実行予定日、ステータス（「０：署名前」、「１：署名後」、「２：業務完了」）、署名前に確認すべき複数の行内規程項目（稟議書決裁、条件充足、契約書チェック、担保・保証、ドキュメント、地域規制）、署名後かつ与信実行前に確認すべき複数の行内規程項目（署名、担保・保証、ドキュメント）、および与信実行後に確認すべき複数の行内規程項目（条件充足、担保・保証、ドキュメント）が格納される。
　各行内規程項目には、「０：Incomplete」または「１：Complete」が格納される。以下、各行内規程項目について説明する。
　稟議書決裁は、稟議書が審査部によって決裁されたかどうかを識別する。本実施形態では、稟議書ＤＢ１０２の決裁フラグに「１：決裁済み」が格納されると、与信事務管理システム１００は、稟議書決裁に「１：Complete」を格納する。
　条件充足は、稟議書が条件付きで決裁された場合に、当該条件が充足したかどうかを識別する。本実施形態では、稟議条件パートに含まれる充足期限に応じて、与信事務管理システム１００は、稟議条件を、署名前の条件充足、または署名後の条件充足のいずれかに設定する。その後、本実施形態では、稟議条件パートに回答が記述されると、与信事務管理システム１００は、条件充足に「１：Complete」を格納する。
　契約書チェックは、決裁済稟議書と契約書の整合性のチェックが完了したかどうかを識別する。本実施形態では、後述の契約条件チェックＤＢ３０２において、署名情報を除くすべての契約条件の整合性が確認されると、与信事務管理システム１００は、契約書チェックに「１：Complete」を格納する。
　担保・保証は、担保・保証が充足したかどうかを識別する。本実施形態では、稟議書の貸出条件パートに含まれる担保・保証の充足期限に応じて、与信事務管理システム１００は、担保・保証を、署名前の担保・保証、署名後の担保・保証または与信実行後の担保・保証のいずれかに設定する。その後、本実施形態では、後述の担保・保証チェックＤＢ３０３において所定期間（署名前、署名後、または与信実行後）に充足期限が設定されたすべての担保・保証の充足が確認されると、与信事務管理システム１００は、所定期間の担保・保証に「１：Complete」を格納する。
　ドキュメントは、書類が徴求されたかどうかを識別する。本実施形態では、ドキュメントチェックＤＢ３０４で設定されたドキュメントの入手期限に応じて、与信事務管理システム１００は、ドキュメントを、署名前のドキュメント、署名後のドキュメントまたは与信実行後のドキュメントのいずれかに設定する。その後、本実施形態では、後述のドキュメントチェックＤＢ３０４において所定期間（署名前、署名後、または与信実行後）に入手期限が設定されたすべてのドキュメントの徴求が確認されると、与信事務管理システム１００は、所定期間のドキュメントに「１：Complete」を格納する。
　地域規制は、地域規制項目が遵守されたかどうかを識別する。本実施形態では、クライアントコンピューター１１１等から遵守確認指示を受信すると、与信事務管理システム１００は、地域規制に「１：Complete」を格納する。
　署名は、契約の当事者が契約書に署名を付与したかどうかを識別する。本実施形態では、後述の契約条件チェックＤＢ３０２においてすべての署名の確認がなされると、与信事務管理システム１００は、署名に「１：Complete」を格納する。
　地域規制ＤＢ３０１は、地域規制項目を格納する。一実施形態では、図７に示されるように、地域規制ＤＢ３０１には、地域コード、地域名、項目コード、および項目名が格納される。
　契約条件チェックＤＢ３０２は、稟議書の貸出条件に基づいて設定されるチェック項目を格納する。一実施形態では、図８に示されるように、契約条件チェックＤＢ３０２には、コントロールカードＤＢ１０４の貸付コードに関連付けて、債務者情報、保証人情報、与信の種類、与信金額、与信実行日、与信実行国、および署名情報が格納される。署名情報には、署名者名または「１：確認済み」が格納され、署名情報を除く各チェック項目には、「０：未確認」または「１：確認済み」が格納される。本実施形態では、クライアントコンピューター１１１等から整合性確認指示を受信すると、与信事務管理システム１００は、チェック項目に「１：確認済み」を格納する。
　担保・保証チェックＤＢ３０３は、稟議書の貸出条件に含まれる担保・保証の情報を格納する。一実施形態では、図９に示されるように、担保・保証チェックＤＢ３０３には、コントロールカードＤＢ１０４の貸付コードに関連付けて、担保・保証名、確認フラグ（「０：未確認」、「１：確認済み」）、および充足期限が格納される。本実施形態では、クライアントコンピューター１１１等から充足確認指示を受信すると、与信事務管理システム１００は、確認フラグに「１：確認済み」を格納する。
　ドキュメントチェックＤＢ３０４は、徴求書類の情報を格納する。一実施形態では、図１０に示されるように、ドキュメントチェックＤＢ３０４には、コントロールカードＤＢ１０４の貸付コードに関連付けて、徴求書類名、確認フラグ（「０：未確認」、「１：確認済み」）、および入手期限が格納される。本実施形態では、クライアントコンピューター１１１等からドキュメント確認指示を受信すると、与信事務管理システム１００は、確認フラグに「１：確認済み」を格納する。
　ドキュメントＤＢ３０５は、電子ファイルを格納する。一実施形態では、ドキュメントＤＢ３０５には、コントロールカードＤＢ１０４の貸付コードに関連付けて、与信取引に関連する電子ファイルを格納する。
　稟議書データ管理部３１０は、クライアントコンピューター１１１等から稟議書関連データを受信することに応答して、稟議書ＤＢ１０２にレコードを登録する。本実施形態では、稟議書関連データには、稟議書を作成する担当者が所属する担当支店コード、担当者コード、複数のパートに区分された稟議書を構成する情報、稟議書を構成するすべての情報を用いて作成される電子稟議書ファイル、および対象の稟議書に関わる関係部署の指定情報（審査部、ミドルバック、バック）が含まれる。稟議書データ管理部３１０は、稟議書コードを作成し、稟議書関連データに含まれる担当支店コード、担当者コード、複数のパートに区分された稟議書を構成する情報、および電子稟議書ファイルに基づいて、稟議書ＤＢ１０２にレコードを登録する。この際、決裁フラグには初期値として「０：決裁前」が設定される。
　稟議書データ管理部３１０は、また、稟議書コード、稟議条件パート、貸出条件パート、および関係部署の指定情報をコントロールカード作成部３１１に送信する。
　コントロールカード作成部３１１は、稟議書データ管理部３１０から稟議書コード、稟議条件パート、貸出条件パート、および関係部署の指定情報を受信することに応答して、コントロールカードＤＢ１０４にレコードを登録する。
　具体的には、本実施形態では、コントロールカード作成部３１１は、貸出条件パートに含まれる与信実行国を参照して、与信実行国の数に応じた数のレコードを登録する。例えば、与信実行国が１つである場合は、１つのレコードを登録し、与信実行国が２つである場合は、２つのレコードを登録する。レコードの登録に際し、コントロールカード作成部３１１は、稟議書コードに対応するコントロールカードコード、および同一コントロールカードコード内の複数の貸付を一意に識別し得る貸付コードを生成し、格納する。
　また、コントロールカード作成部３１１は、受信した稟議書コード、関係部署の指定情報に含まれるミドルバックの支店コード、貸出条件パートに含まれる与信実行国、署名予定日、与信実行予定日をそれぞれ格納する。担当者コードについては、コントロールカード作成部３１１は、貸出条件パートに含まれる債務者情報に基づいて設定することができる。
　ステータスには初期値として「０：署名前」が設定され、ドキュメントを除く署名前・署名後・与信実行後の行内規程項目には初期値として「０：Incomplete」が設定され、ドキュメントには初期値として記号「－」が設定される。本明細書では、記号「－」は、「未設定」を意味する。
　コントロールカード作成部３１１は、受信した稟議条件パートに基づいて、充足期限に一致しない条件充足に記号（「－」）を設定する。稟議書決裁の条件が設定されていない場合、コントロールカード作成部３１１は、すべての条件充足に記号（「－」）を設定する。
　コントロールカード作成部３１１は、受信した貸出条件パートに含まれる担保・保証に基づいて、充足期限に一致しない担保・保証に記号（「－」）を設定する。
　コントロールカード作成部３１１は、さらに、受信した貸出条件パートに含まれる与信実行国に基づいて地域規制ＤＢ３０１を検索して、地域規制項目が存在しない場合、地域規制に記号「－」を設定する。
　コントロールカードＤＢ１０４にレコードを登録した後、コントロールカード作成部３１１は、契約書作成データを受信することに応答して、コントロールカードＤＢ１０４のレコード内の契約書コードを設定する。本実施形態では、契約書作成データには、貸付コード、契約書コードが含まれる。
　契約条件設定部３１２は、貸出条件パートに基づいて、契約条件チェックＤＢ３０２にレコードを登録する。本実施形態では、契約条件設定部３１２は、コントロールカード作成部３１１が作成した貸付コードに関連付けて、レコードを登録する。契約条件設定部３１２は、貸出条件パートに含まれる項目に「０：未確認」を設定し、貸出条件パートに含まれない項目には記号「－」を設定する。署名情報（署名１、署名２、署名３）については、契約条件設定部３１２は、貸出条件パートに指定された契約の当事者名を設定する。
　担保・保証設定部３１３は、貸出条件パートに含まれる担保・保証に基づいて、担保・保証チェックＤＢ３０３にレコードを登録する。本実施形態では、担保・保証設定部３１３は、コントロールカード作成部３１１が作成した貸付コードに関連付けて、貸出条件パートに含まれる担保・保証名および充足期限に基づいてレコードを登録する。この際、確認フラグには初期値として「０：未確認」が設定される。
　本実施形態では、貸出条件パートに複数の与信実行国が含まれる場合、担保・保証設定部３１３は、各与信実行国に対する貸付ごとに異なる担保・保証が設定されているか否かを判定する。異なる担保・保証が設定されている場合、担保・保証設定部３１３は、各与信実行国に対する貸付に対応する貸付コードごとに、対応する担保・保証のレコードを登録する。
　一方、同一の担保・保証が設定されている場合、担保・保証設定部３１３は、いずれか１つの貸付コードに対してのみ、担保・保証のレコードを登録する。貸付コードの選択は、例えば、フロントと同一の支店コードのミドルバックが担当する貸付コードを優先する、または、ミドルバックとして指定された支店の規模に応じてなど、任意の方法で行うことができる。
　別の実施形態では、同一の担保・保証が設定されている場合も、担保・保証設定部３１３は、各与信実行国に対する貸付に対応する貸付コードごとに、対応する担保・保証のレコードを登録する。その後、後述の担保・保証チェック画面において、複数の与信実行国のうちのいずれか１つの与信実行国の担当者が、クライアントコンピューター１１１等を介してチェック欄を選択することにより充足確認指示を送信することに応答して、与信事務管理システム１００は、同一の担保・保証が設定されている複数の与信実行国すべてについて、担保・保証チェックＤＢ３０３の確認フラグに「１：確認済み」を格納する。これにより、複数の与信実行国すべてにおいて、複数の与信実行国のうちのいずれか１つの与信実行国の担当者が登録した結果を共有することができる。
　ドキュメント設定部３１４は、クライアントコンピューター１１１等からドキュメントリストアップデータを受信することに応答して、ドキュメントチェックＤＢ３０４にレコードを登録する。本実施形態では、ドキュメントリストアップデータには、貸付コード、徴求書類名、入手期限が含まれる。ドキュメント設定部３１４は、ドキュメントリストアップデータに基づいて、レコードを登録する。この際、確認フラグには初期値として「０：未確認」が設定される。
　ドキュメント設定部３１４は、また、ドキュメントリストアップデータに基づいて、入手期限に一致するコントロールカードレコードのドキュメントに「０：Incomplete」を設定する。
　（コントロールカード作成処理）
　図１１を参照して、コントロールカード作成処理について説明する。図１１は、コントロールカードを作成する処理フローを示す。与信事務管理システム１００の担当者ＤＢ１０１には、図４に示されるレコードが格納されているものとする。与信事務管理システム１００の地域規制ＤＢ３０１にも、図７に示されるレコードが格納されているものとする。
　Ｓ１１０１において、与信事務管理システム１００の稟議書データ管理部は、クライアントコンピューター１１１等から稟議書関連データを受信することに応答して、Ｓ１１０２において、稟議書ＤＢ１０２にレコードを登録する。
　本実施形態では、Ｓ１１０１において、稟議書を作成する担当者が所属する担当支店コード、担当者コード、複数のパートに区分された稟議書を構成する情報、稟議書を構成するすべての情報を用いて作成される電子稟議書ファイル、および対象の稟議書に関わる関係部署の指定情報（審査部、ミドルバック、バック）を含む稟議書関連データを受信して、稟議書データ管理部３１０は、稟議書コード（3333333）を作成し、稟議書ＤＢ１０２にレコードを登録する。この際、決裁フラグには初期値として「０：決裁前」が設定される。
　Ｓ１１０２において、稟議書データ管理部３１０は、稟議書コード、稟議条件パート、貸出条件パート、および関係部署の指定情報を与信事務管理システム１００のコントロールカード作成部３１１に送信する。
　Ｓ１１０３において、コントロールカード作成部３１１は、稟議書データ管理部３１０から受信した情報に基づいて、コントロールカードＤＢ１０４にレコードを登録する。
　本実施形態では、与信実行国にＣ国のみが指定された貸出条件パートを受信したものとし、コントロールカード作成部３１１は、受信した稟議書コード（3333333）、関係部署の指定情報に含まれるミドルバックの支店コード（333）、貸出条件パートに含まれる与信実行国（Ｃ国）、署名予定日（2015/4/10）、与信実行予定日（2015/4/24）に基づく１つのレコードを登録する。
　レコードの登録に際し、コントロールカード作成部３１１は、稟議書コードに対応するコントロールカードコード（C3333333）、および貸付コード（C3333）を生成し、格納する。
　また、コントロールカード作成部３１１は、貸出条件パートに含まれる債務者情報に基づいて、担当者コード（333-22222）を設定し、ステータスには初期値として「０：署名前」を設定したものとする。
　Ｓ１１０４において、コントロールカード作成部３１１は、受信した稟議条件パートに基づいて、充足期限に一致しない条件充足に記号（「－」）を設定する。
　本実施形態では、稟議書決裁の条件が設定されていない稟議条件パートを受信したものとし、コントロールカード作成部３１１は、署名前の充足条件、および与信実行後の充足条件に記号（「－」）を設定する。
　Ｓ１１０５において、コントロールカード作成部３１１は、受信した貸出条件パートに含まれる担保・保証に基づいて、充足期限に一致しない条件充足に記号（「－」）を設定する。
　本実施形態では、署名前の充足期限（2015/4/9）が設定された担保・保証が設定された貸出条件パートを受信したものとし、コントロールカード作成部３１１は、署名後および与信実行後の担保・保証に記号（「－」）を設定する。
　Ｓ１１０６において、コントロールカード作成部３１１は、受信した貸出条件パートに含まれる与信実行国に基づいて地域規制ＤＢ３０１を検索して、地域規制項目が存在しない場合、地域規制に記号「－」を設定する。
　本実施形態では、与信実行国（Ｃ国）を含む貸出条件パートを受信したものとし、コントロールカード作成部３１１は、図７に示される地域規制ＤＢ３０１を検索して、Ｃ国に対応する地域規制項目が存在するので、次の処理へ進む。
　Ｓ１１０７において、与信事務管理システム１００の契約条件設定部３１２は、貸出条件パートに基づいて、契約条件チェックＤＢ３０２にレコードを登録する。
　本実施形態では、契約条件設定部３１２は、コントロールカード作成部３１１が作成した貸付コード（C3333）に関連付けて、図８に示すレコードを登録したものとする。図８に示されるように、本実施形態では、保証人情報を含まない貸出条件パートを受信し、保証人情報には記号「－」が設定される。署名情報（署名１、署名２、署名３）については、本実施形態では、署名者１のみを含む貸出条件パートを受信したものとし、契約条件設定部３１２は、署名１に署名者１を設定し、署名２および署名３には記号「－」を設定する。
　Ｓ１１０８において、与信事務管理システム１００の担保・保証設定部３１３は、貸出条件パートに含まれる担保・保証に基づいて、担保・保証チェックＤＢ３０３にレコードを登録する。
　本実施形態では、担保・保証設定部３１３は、コントロールカード作成部３１１が作成した貸付コード（C3333）に関連付けて、図９に示すレコードを登録したものとする。
　Ｓ１１０９において、与信事務管理システム１００のドキュメント設定部３１４は、クライアントコンピューター１１１等からドキュメントリストアップデータを受信することに応答して、ドキュメントチェックＤＢ３０４にレコードを登録する。続いて、Ｓ１１１０において、ドキュメント設定部３１４は、ドキュメントリストアップデータに基づいて、充足期限に一致するコントロールカードレコードのドキュメントに「０：Incomplete」を設定する。
　本実施形態では、貸付コード（C3333）、徴求書類名（書類６）、署名前の充足期限（2015/4/9）を含むドキュメントリストアップデータを受信して、ドキュメント設定部３１４は、図１０に示されるレコードを登録したものとする。続いて、ドキュメント設定部３１４は、ドキュメントリストアップデータに基づいて、コントロールカードレコードの署名前のドキュメントに「０：Incomplete」を設定したものとする。
　Ｓ１１１１において、コントロールカード作成部３１１は、契約書作成データを受信することに応答して、コントロールカードＤＢ１０４のレコード内の契約書コードを設定する。
　本実施形態では、貸付コード（C3333）、契約書コード（32345）を含む契約書作成データを受信して、コントロールカード作成部３１１は、コントロールカードＤＢ１０４の契約書コードを設定する。
　（コントロールカード更新処理）
　次に、図１２～１４を参照して、コントロールカード更新処理について説明する。図１２、１４は、クライアントコンピューターに表示される、コントロールカードの画面の一例を示す。図１３は、クライアントコンピューターに表示される、契約書チェック画面の一例を示す。与信事務管理システム１００の担当者ＤＢ１０１、稟議書ＤＢ１０２、コントロールカードＤＢ１０４、地域規制ＤＢ３０１、契約書チェックＤＢ３０２、担保・保証チェックＤＢ３０３、およびドキュメントチェックＤＢ３０４には、それぞれ、図４、図５、図６Ａ、図７、図８、図９、および図１０に示されるレコードが格納されているものとする。
　本実施形態では、Ａ国ａ支店に所属する担当者２が、クライアントコンピューター１１１を介して、貸付コード（X1111）により特定されるコントロールカードの情報を更新する処理について説明する。
　担当者２が、クライアントコンピューター１１１を介して担当者コード（111-22222）およびパスワードなどを含む認証情報を与信事務管理システム１００に送信し、認証情報に基づいて、認証に成功したものとする。認証に成功した場合、与信事務管理システム１００は、コントロールカードＤＢ１０４に基づいて、認証に成功した担当者が担当するコントロールカードの一覧を表示することができる。
　本実施形態では、与信事務管理システム１００は、認証に成功した担当者（担当者２）が担当する２件のコントロールカードを含む一覧がクライアントコンピューター１１１に提供し、貸付コード（X1111）により特定されるコントロールカードを選択する指示をクライアントコンピューター１１１から受信して、図１２に示されるコントロールカードの画面をクライアントコンピューター１１１に提供したものとする。
　図１２に示されるように、特定のコントロールカードコードに複数の貸付コードが関連付けられている場合、コントロールカードの画面には、特定のコントロールカードコードに関連付けられた複数の貸付コードの情報が表示される。ただし、担当者は、自身が担当する貸付コードに関するコンプライアンス項目のみ更新することができる。
　具体的には、コントロールカードコード（X2222222）に関連付けられた貸付コード（A1111）および貸付コード（X2222）により特定される複数の列１２０１、１２０２が表示されるが、担当者２は、自身が担当する１２０１のコンプライアンス項目のみ更新することができる。
　図１２のドキュメントリスト１２０３を選択すると、当該コントロールカードに関連するドキュメントリストが表示される。本実施形態では、コントロールカードレコード作成後の任意のタイミングで、フロント担当者は、貸付コードに関連付けてドキュメントをアップロードすることができ、アップロードされたドキュメントをドキュメントリストから閲覧することができる。
　ドキュメントリストは、ログインしている担当者の役割に応じて、コントロールカードに関連するドキュメントのうち一部または全部が選択されて表示される。例えば、稟議書を作成したフロント担当者がログインしている場合は、コントロールカードに関連するすべてのドキュメントを含むリストが表示される。一方、ミドルバック担当者である担当者２がログインしている場合は、自身が担当する１２０１の貸付コードに関連するドキュメントのリストが選択して表示される。
　列１２０１の稟議書決裁は、図５に示される稟議書ＤＢ１０２の稟議書コード（2222222）により特定されるレコードの決裁フラグに「１：決裁済み」が格納されているので、与信事務管理システム１００により、既に「１：Complete」が格納されている。
　本実施形態では、担当者２が、クライアントコンピューター１１１を介して、図１２に示される列１２０１の稟議書決裁（「１：Complete」）を選択すると、与信事務管理システム１００は、稟議書画面（図示せず）を提供することができる。提供される稟議書画面は、ログインしている担当者の役割に応じて、稟議書を構成する複数のパートのうち一部または全部が選択されて表示される。例えば、稟議書を作成したフロント担当者がログインしている場合は、稟議書を構成するすべてのパートを含む画面が表示される。一方、ミドルバック担当者がログインしている場合は、与信事務に必要なパートのみが選択されて表示される。
　列１２０１の条件充足は、稟議条件パートに回答が記述されたことに基づいて、与信事務管理システム１００により、既に「１：Complete」が格納されている。
　本実施形態では、担当者２が、クライアントコンピューター１１１を介して図１２に示される列１２０１の条件充足（「１：Complete」）を選択すると、与信事務管理システム１００は、稟議書条件画面（図示せず）を提供することができる。稟議書条件画面には、稟議条件パートの情報が含まれる。
　列１２０１の契約書チェックは、図１２に示されるように「０：Incomplete」が格納されている。本実施形態では、担当者２が、クライアントコンピューター１１１を介して図１２に示される列１２０１の契約書チェック（「０：Incomplete」）を選択すると、与信事務管理システム１００は、図８に示される契約条件チェックＤＢ３０２に基づいて、図１３に示されるような契約条件チェック画面を提供することができる。
　担当者２は、契約条件チェック画面の稟議書－貸出条件に表示される内容と、契約書の内容の整合性を確認する。担当者２は、クライアントコンピューター１１１を介して、例えば図１２に表示されるコントロールカードの画面のドキュメントリスト１２０３を選択して、ドキュメントリストの中から契約書を選択すること等により、契約書ＤＢ１０３に格納されている電子契約書ファイルを閲覧しながら整合性を確認する。
　本実施形態では、担当者２が、クライアントコンピューター１１１を介してチェック欄を選択することにより整合性確認指示を送信すると、与信事務管理システム１００は、契約条件チェックＤＢ３０２の該当のチェック項目に「１：確認済み」を格納する。前述したように、本実施形態では、契約条件チェックＤＢ３０２において、署名情報を除くすべての契約条件の整合性が確認されると、与信事務管理システム１００は、コントロールカードＤＢ１０４の契約書チェックに「１：Complete」を格納する。
　列１２０１のドキュメントは、図１２に示されるように「０：Incomplete」が格納されている。本実施形態では、担当者２が、クライアントコンピューター１１１を介して図１２に示される列１２０１のドキュメント（「０：Incomplete」）を選択すると、与信事務管理システム１００は、図１０に示されるドキュメントチェックＤＢ３０４に基づいて、ドキュメントチェック画面（図示せず）を提供することができる。
　一実施形態では、ドキュメントチェック画面は、徴求書類名およびチェック欄を含み、担当者２は、ドキュメントチェック画面に表示された徴求書類が、コントロールカードの画面のドキュメントリスト１２０３選択時に表示されるドキュメントリスト内に間違いなく存在することを確認する。
　本実施形態では、担当者２が、クライアントコンピューター１１１を介してチェック欄を選択することにより徴求確認指示を送信すると、与信事務管理システム１００は、ドキュメントチェックＤＢ３０４の該当のチェック項目に「１：確認済み」を格納する。前述したように、本実施形態では、ドキュメントチェックＤＢ３０４において所定期間（署名前、署名後、または与信実行後）に入手期限が設定されたすべてのドキュメントの徴求が確認されると、与信事務管理システム１００は、コントロールカードＤＢ１０４の所定期間のドキュメントに「１：Complete」を格納する。
　列１２０１の地域規制は、図１２に示されるように「０：Incomplete」が格納されている。本実施形態では、担当者２が、クライアントコンピューター１１１を介して図１２に示される列１２０１の地域規制（「０：Incomplete」）を選択すると、与信事務管理システム１００は、地域規制チェック画面（図示せず）を提供することができる。
　一実施形態では、地域規制チェック画面は、地域規制項目名およびチェック欄を含み、担当者２は、地域規制チェック画面に表示された地域規制項目を契約内容が遵守していることを確認する。
　本実施形態では、担当者２が、クライアントコンピューター１１１を介してチェック欄を選択することにより遵守確認指示を送信すると、与信事務管理システム１００は、コントロールカードＤＢ１０４の地域規制に「１：Complete」を格納する。
　上述した操作により、コントロールカードＤＢ１０４内の貸付コード（X1111）により特定されるコントロールカードレコードは、図６Ｂに示されるように、署名前の行内規程項目がすべて「１：Complete」となる。このように、署名前の行内規程項目がすべて「１：Complete」となった状態で、担当者２が、クライアントコンピューター１１１を介して、図１２に示されるコントロールカードの画面のステータス変更ボタン１２０４を押下すると、図６Ｃに示されるように、貸付コード（X1111）により特定されるコントロールカードレコードのステータスが「０：署名前」から「１：署名後」へ更新される。
　本実施形態では、与信事務管理システム１００は、コントロールカードレコードのステータスが「０：署名前」から「１：署名後」へ更新されると、図１４に示されるように、署名後および与信実行後の行内規程項目を含むコントロールカードの画面をクライアントコンピューター１１１に提供する。
　列１４０１の署名は、図１４に示されるように「０：Incomplete」が格納されている。本実施形態では、担当者２が、クライアントコンピューター１１１を介して図１４に示される列１２０１の署名（「０：Incomplete」）を選択すると、与信事務管理システム１００は、図８に示される契約条件チェックＤＢ３０２に基づいて、署名チェック画面（図示せず）を提供することができる。
　一実施形態では、署名チェック画面は、署名者名およびチェック欄を含み、担当者２は、署名チェック画面に表示された任意の数の署名者が、契約書に署名を付与したことを確認する。担当者２は、クライアントコンピューター１１１を介して、例えば図１４に表示されるコントロールカードの画面のドキュメントリスト１２０３を選択して、ドキュメントリストの中から契約書を選択すること等により、契約書ＤＢ１０３に格納されている電子契約書ファイルを閲覧しながら署名の付与を確認する。
　本実施形態では、担当者２が、クライアントコンピューター１１１を介してチェック欄を選択することにより署名確認指示を送信すると、与信事務管理システム１００は、契約条件チェックＤＢ３０２の該当のチェック項目に「１：確認済み」を格納する。前述したように、本実施形態では、契約条件チェックＤＢ３０２においてすべての書名の確認がなされると、与信事務管理システム１００は、コントロールカードＤＢ１０４の署名に「１：Complete」を格納する。
　列１４０１の署名後の担保・保証は、図１４に示されるように「０：Incomplete」が格納されている。本実施形態では、担当者２が、クライアントコンピューター１１１を介して図１４に示される列１４０１の署名後の担保・保証（「０：Incomplete」）を選択すると、与信事務管理システム１００は、図９に示される担保・保証チェックＤＢ３０３に基づいて、担保・保証チェック画面（図示せず）を提供することができる。
　一実施形態では、担保・保証チェック画面は、担保・保証名およびチェック欄を含み、担当者２は、担保・保証チェック画面に表示された担保・保証が、充足したことを確認する。
　本実施形態では、担当者２が、クライアントコンピューター１１１を介してチェック欄を選択することにより充足確認指示を送信すると、与信事務管理システム１００は、担保・保証チェックＤＢ３０３の該当の確認フラグに「１：確認済み」を格納する。前述したように、本実施形態では、担保・保証チェックＤＢ３０３において所定期間（署名前、署名後、または与信実行後）に充足期限が設定されたすべての担保・保証の充足が確認されると、与信事務管理システム１００は、コントロールカードＤＢ１０４の所定期間の担保・保証に「１：Complete」を格納する。
　列１４０１の署名後および与信実行後のドキュメント、与信実行後の条件充足、与信実行後の担保・保証については、既に説明した行内規程項目についての説明と重複するため、省略する。
　上述した操作により、コントロールカードＤＢ１０４内の貸付コード（X1111）により特定されるコントロールカードレコードは、図６Ｄに示されるように、行内規程項目がすべて「１：Complete」となる。このように、行内規程項目がすべて「１：Complete」となった状態で、担当者２が、クライアントコンピューター１１１を介して、図１４に示されるコントロールカードの画面のステータス変更ボタン１４０２を押下すると、図６Ｅに示されるように、貸付コード（X1111）により特定されるコントロールカードレコードのステータスが「１：署名後」から「２：業務完了」へ更新される。
　以上、本発明によれば、事務部が各段階でチェックすべき事項とその進捗状況とを可視化することを可能としたコントロールカードを使用することによって、従来起きていた行内規程項目の二重管理や地域規制の照会対応等、業務効率の悪化につながる事態を回避し、与信業務全体の効率化と内部管理体制の強化を図ることができる。
　さらに、本発明によれば、与信業務に関わる担当者の所属支店および役割に応じて、必要最小限の情報開示を提供することで、顧客情報に関するアクセス制御を徹底することができる。
　（追加の実施形態）
　追加の実施形態では、コントロールカードＤＢ１０４は、行内規程項目として、さらに商品別規制を格納することができる。
　商品別規制は、銀行１が提供する商品（契約の種類）に応じて、チェックすべき行内規定項目が遵守されたかどうかを識別する。本実施形態では、後述の商品チェックＤＢ３０６においてすべての項目のチェックが確認されると、与信事務管理システム１００は、商品別規制に「１：Complete」を格納する。
　与信事務管理システム１００は、さらに、商品別チェックＤＢ３０６、および商品別設定部３１５を備える。
　商品別チェックＤＢ３０６は、稟議書の貸出条件に基づいて、特定の商品においてチェックすべき項目の情報を格納する。一実施形態では、商品別チェックＤＢ３０６には、コントロールカードＤＢ１０４の貸付コードに関連付けて、項目名、および確認フラグ（「０：未確認」、「１：確認済み」）が格納される。本実施形態では、クライアントコンピューター１１１等から確認指示を受信すると、与信事務管理システム１００は、確認フラグに「１：確認済み」を格納する。
　商品別設定部３１５は、貸出条件パートに基づいて、商品別チェックＤＢ３０３にレコードを登録する。本実施形態では、商品別設定部３１３は、コントロールカード作成部３１１が作成した貸付コードに関連付けて、当該契約が該当する商品においてチェックすべき項目を特定してレコードを登録する。この際、確認フラグには初期値として「０：未確認」が設定される。例えば、油田開発等、環境に影響を及ぼす事業に対する契約の場合、商品別設定部３１５は、当該契約が該当する商品においてチェックすべき項目として、環境アセスメントの実施を設定することができる。
　以上、本発明によれば、コントロールカードに、商品に応じてチェックすべき行内規定項目を含めることによって、更なる与信業務全体の効率化と内部管理体制の強化を図ることができる。
　以上、例示的な実施形態を参照しながら本発明の原理を説明したが、本発明の要旨を逸脱することなく、構成および細部において変更する様々な実施形態を実現可能であることを当業者は理解するだろう。すなわち、本発明は、例えば、システム、装置、方法、プログラムもしくは記憶媒体等としての実施態様をとることが可能である。

Claims (16)

  1. 　コントロールカードコードに関連付けて稟議書コード、署名予定日、与信実行予定日、ステータス、および所定期間ごとに複数の行内規程項目のチェック完了フラグを格納するコントロールカード記憶部と、
    　稟議書コード、条件付きで稟議書が決裁される場合の条件、および充足期限を含む稟議条件パート、および貸出に必要な条件を含む貸出条件パートを受信することに応答して、前記コントロールカード記憶部にレコードを登録するコントロールカード作成部であって、前記稟議条件パートおよび前記貸出条件パートに基づいて、前記複数の行内規程項目のうち、チェックすべき項目に未完了を示す値を格納する、コントロールカード作成部と
    　を備えた、与信事務管理システム。
  2. 　前記コントロールカード記憶部は、貸付コードおよび与信実行国をさらに格納し、
    　前記コントロールカード作成部は、前記貸出条件パートに含まれる与信実行国を参照して、与信実行国の数に応じた数のレコードを前記コントロールカード記憶部に登録する、請求項１の与信事務管理システム。
  3. 　貸出実行がなされる地域ごとに遵守すべき項目を格納する地域規制記憶部をさらに備え、
    　前記コントロールカード作成部は、前記貸出条件パートに含まれる与信実行国に基づいて前記地域規制記憶部を検索して、前記複数の行内規程項目に含まれる地域規制項目を設定する、請求項１または２の与信事務管理システム。
  4. 　稟議書コードに関連付けて、稟議書を構成する情報を含む複数のパートを格納する稟議書記憶部と
    　役割を含む担当者情報を格納する担当者記憶部と
    　をさらに備え、
    　前記与信事務管理システムは、前記担当者記憶部の前記役割に応じて、前記複数のパートの一部または全部を選択して提供する、請求項１乃至３のいずれかに記載の与信事務管理システム。
  5. 　稟議書の貸出条件に基づいて設定されるチェック項目を格納する契約条件チェック記憶部と、
    　前記貸出条件パートに基づいて、前記契約条件チェック記憶部にレコードを登録する契約条件設定部と
    　をさらに備え
    　前記与信事務管理システムは、前記契約条件チェック記憶部において設定された、決裁済稟議書と契約書の整合性を確認するためのすべてのチェック項目の整合性が確認されると、前記コントロールカード記憶部の契約書チェックに関する行内規程項目に完了を示す値を格納する、請求項１乃至４のいずれかに記載の与信事務管理システム。
  6. 　稟議書の貸出条件に含まれる担保・保証の充足情報を格納する担保・保証チェック記憶部と、
    　前記貸出条件パートに基づいて、前記担保・保証チェック記憶部にレコードを登録する担保・保証設定部と
    　をさらに備え、
    　前記与信事務管理システムは、前記担保・保証チェック記憶部において所定期間に充足期限が設定されたすべての担保・保証の充足が確認されると、前記コントロールカード記憶部の当該所定期間の担保・保証に関する行内規程項目に完了を示す値を格納する、請求項１乃至５のいずれかに記載の与信事務管理システム。
  7. 　徴求書類の情報を格納するドキュメントチェック記憶部と、
    　徴求書類の情報を含むドキュメントリストアップデータに基づいて、前記ドキュメントチェック記憶部にレコードを登録するドキュメント設定部と
    　をさらに備え、
    　前記与信事務管理システムは、前記ドキュメントチェック記憶部において所定期間に入手期限が設定されたすべてのドキュメントの存在が確認されると、前記コントロールカード記憶部の当該所定期間のドキュメントに関する行内規程項目に完了を示す値を格納する、請求項１乃至６のいずれかに記載の与信事務管理システム。
  8. 　特定の商品においてチェックすべき項目の情報を格納する商品別チェック記憶部と、
    　前記貸出条件パートに基づいて、前記商品別チェック記憶部にレコードを登録する商品別設定部と
    　をさらに備え、
    　前記与信事務管理システムは、前記商品別チェック記憶部において設定されたすべての項目のチェックが確認されると、前記コントロールカード記憶部の商品別に関する行内規定項目に完了を示す値を格納する、請求項１乃至７のいずれかに記載の与信事務管理システム。
  9. 　コントロールカードコードに関連付けて稟議書コード、署名予定日、与信実行予定日、ステータス、および所定期間ごとに複数の行内規程項目のチェック完了フラグを格納するコントロールカード記憶部を備えた与信事務管理システムにおいて、
    　前記与信事務管理システムのコントロールカード作成部が、稟議書コード、条件付きで稟議書が決裁される場合の条件、および充足期限を含む稟議条件パート、および貸出に必要な条件を含む貸出条件パートを受信するステップと、
    　前記コントロールカード作成部が、前記受信した情報に基づいて、前記コントロールカード記憶部にレコードを登録するステップであって、前記稟議条件パートおよび前記貸出条件パートに基づいて、前記複数の行内規程項目のうち、チェックすべき項目に未完了を示す値を格納する、ステップと
    　を実行する、方法。
  10. 　前記コントロールカード記憶部は、貸付コードおよび与信実行国をさらに格納し、
    　前記登録するステップは、前記貸出条件パートに含まれる与信実行国を参照するステップを含み、与信実行国の数に応じた数のレコードを前記コントロールカード記憶部に登録する、請求項９の方法。
  11. 　前記与信事務管理システムは、貸出実行がなされる地域ごとに遵守すべき項目を格納する地域規制記憶部をさらに備え、
    　前記登録するステップは、前記貸出条件パートに含まれる与信実行国に基づいて前記地域規制記憶部を検索するステップと、前記複数の行内規程項目に含まれる地域規制項目を設定するステップとをさらに含む、請求項９または１０の方法。
  12. 　前記与信事務管理システムは、
    　稟議書コードに関連付けて、稟議書を構成する情報を含む複数のパートを格納する稟議書記憶部と
    　役割を含む担当者情報を格納する担当者記憶部と
    　をさらに備え、
    　前記与信事務管理システムが、前記担当者記憶部の前記役割に応じて、前記複数のパートの一部または全部を選択して提供するステップをさらに実行する、請求項９乃至１１のいずれかに記載の方法。
  13. 　前記与信事務管理システムは、稟議書の貸出条件に基づいて設定されるチェック項目を格納する契約条件チェック記憶部をさらに備え、
    　前記与信事務管理システムの契約条件設定部が、前記貸出条件パートに基づいて、前記契約条件チェック記憶部にレコードを登録するステップと、
    　前記契約条件チェック記憶部において設定された、決裁済稟議書と契約書の整合性を確認するためのすべてのチェック項目の整合性が確認されると、前記与信事務管理システムが、前記コントロールカード記憶部の契約書チェックに関する行内規程項目に完了を示す値を格納するステップと
    　をさらに実行する、請求項９乃至１２のいずれかに記載の方法。
  14. 　前記与信事務管理システムは、稟議書の貸出条件に含まれる担保・保証の充足情報を格納する担保・保証チェック記憶部をさらに備え、
    　前記与信事務管理システムの担保・保証設定部が、前記貸出条件パートに基づいて、前記担保・保証チェック記憶部にレコードを登録するステップと、
    　前記担保・保証チェック記憶部において所定期間に充足期限が設定されたすべての担保・保証の充足が確認されると、前記与信事務管理システムが、前記コントロールカード記憶部の当該所定期間の担保・保証に関する行内規程項目に完了を示す値を格納するステップと
    　をさらに実行する、請求項９乃至１３のいずれかに記載の方法。
  15. 　前記与信事務管理システムは、徴求書類の情報を格納するドキュメントチェック記憶部をさらに備え、
    　前記与信事務管理システムのドキュメント設定部が、徴求書類の情報を含むドキュメントリストアップデータに基づいて、前記ドキュメントチェック記憶部にレコードを登録するステップと、
    　前記ドキュメントチェック記憶部において所定期間に入手期限が設定されたすべてのドキュメントの存在が確認されると、前記与信事務管理システムが、前記コントロールカード記憶部の当該所定期間のドキュメントに関する行内規程項目に完了を示す値を格納するステップと
    　をさらに実行する、請求項９乃至１４のいずれかに記載の方法。
  16. 　前記与信事務管理システムは、特定の商品においてチェックすべき項目の情報を格納する商品別チェック記憶部をさらに備え、
    　前記与信事務管理システムの商品別設定部が、前記貸出条件パートに基づいて、前記商品別チェック記憶部にレコードを登録するステップと、
    　前記ドキュメントチェック記憶部において設定されたすべての項目のチェックが確認されると、前記与信事務管理システムが、前記コントロールカード記憶部の商品別に関する行内規定項目に完了を示す値を格納するステップと
    　をさらに実行する、請求項９乃至１５のいずれかに記載の方法。
PCT/JP2015/001866 2015-03-31 2015-03-31 与信事務管理システムおよびその方法 WO2016157252A1 (ja)

Priority Applications (4)

Application Number Priority Date Filing Date Title
CN201580078640.7A CN107430746B (zh) 2015-03-31 2015-03-31 信贷事务管理系统及其方法
PCT/JP2015/001866 WO2016157252A1 (ja) 2015-03-31 2015-03-31 与信事務管理システムおよびその方法
JP2016516113A JP5963998B1 (ja) 2015-03-31 2015-03-31 与信事務管理システムおよびその方法
US15/563,244 US20180122003A1 (en) 2015-03-31 2015-03-31 Credit administration management system and method therefor

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2015/001866 WO2016157252A1 (ja) 2015-03-31 2015-03-31 与信事務管理システムおよびその方法

Publications (1)

Publication Number Publication Date
WO2016157252A1 true WO2016157252A1 (ja) 2016-10-06

Family

ID=56558021

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2015/001866 WO2016157252A1 (ja) 2015-03-31 2015-03-31 与信事務管理システムおよびその方法

Country Status (4)

Country Link
US (1) US20180122003A1 (ja)
JP (1) JP5963998B1 (ja)
CN (1) CN107430746B (ja)
WO (1) WO2016157252A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP6356362B1 (ja) * 2017-03-30 2018-07-11 株式会社三井住友銀行 銀行システムおよび銀行システムによって実行される方法

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109146665A (zh) * 2018-08-03 2019-01-04 中国电力财务有限公司 一种信息处理方法及装置

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002157422A (ja) * 2000-11-20 2002-05-31 Fujitsu Ltd 与信方法および記録媒体
JP2003248754A (ja) * 2002-02-22 2003-09-05 Hachijuni Bank Ltd 資産査定支援システム
JP2003296572A (ja) * 2002-03-29 2003-10-17 Japan Research Institute Ltd 融資支援システム、情報端末装置、融資支援方法およびその方法をコンピュータに実行させるプログラム
US7742980B1 (en) * 2002-11-15 2010-06-22 Imx, Inc. Automated loan approval system

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6088686A (en) * 1995-12-12 2000-07-11 Citibank, N.A. System and method to performing on-line credit reviews and approvals
US5933816A (en) * 1996-10-31 1999-08-03 Citicorp Development Center, Inc. System and method for delivering financial services
US8489498B1 (en) * 2003-12-01 2013-07-16 Fannie Mae System and method for processing a loan
US7636742B1 (en) * 2004-04-01 2009-12-22 Intuit Inc. Automated data retrieval
US10395264B2 (en) * 2007-04-30 2019-08-27 Visa U.S.A. Inc. Payment account processing which conveys financial transaction data and non financial transaction data
CN101923695A (zh) * 2010-02-09 2010-12-22 苏州德融嘉信信用管理技术有限公司 基于熟人社会模式的融资服务方法
EP2710545A4 (en) * 2011-05-18 2014-12-31 Credibility Corp SYSTEM AND METHODS FOR CREATING A FEEDBACK LOOP FOR CREDIT
CN102903056A (zh) * 2011-07-27 2013-01-30 刘金衢 一种基于电子商务平台的借贷担保方法及系统
US8996447B2 (en) * 2012-05-22 2015-03-31 Sap Se Decision service manager
CN103942718A (zh) * 2014-04-14 2014-07-23 中国人民银行征信中心 企业信贷信息采集整合方法

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002157422A (ja) * 2000-11-20 2002-05-31 Fujitsu Ltd 与信方法および記録媒体
JP2003248754A (ja) * 2002-02-22 2003-09-05 Hachijuni Bank Ltd 資産査定支援システム
JP2003296572A (ja) * 2002-03-29 2003-10-17 Japan Research Institute Ltd 融資支援システム、情報端末装置、融資支援方法およびその方法をコンピュータに実行させるプログラム
US7742980B1 (en) * 2002-11-15 2010-06-22 Imx, Inc. Automated loan approval system

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP6356362B1 (ja) * 2017-03-30 2018-07-11 株式会社三井住友銀行 銀行システムおよび銀行システムによって実行される方法
WO2018179290A1 (ja) * 2017-03-30 2018-10-04 株式会社三井住友銀行 銀行システムおよび銀行システムによって実行される方法
CN108990424A (zh) * 2017-03-30 2018-12-11 株式会社三井住友银行 银行系统以及由银行系统执行的方法

Also Published As

Publication number Publication date
US20180122003A1 (en) 2018-05-03
CN107430746A (zh) 2017-12-01
JPWO2016157252A1 (ja) 2017-04-27
CN107430746B (zh) 2022-03-18
JP5963998B1 (ja) 2016-08-03

Similar Documents

Publication Publication Date Title
US10372733B2 (en) Systems and methods for secure storage of user information in a user profile
US20070067234A1 (en) Mortgage loan system and method
US20160343072A1 (en) Method and system for business customer on-boarding
JP6188655B2 (ja) 情報管理システムおよびコンピュータプログラム
US20080183627A1 (en) Filtered healthcare payment card linked to tax-advantaged accounts
WO2018063659A1 (en) Systems and methods for generating customized reports based on operational stage rules
US9582785B2 (en) Mindmap illustrator
US20140244346A1 (en) Real estate transaction management platform
JP5963998B1 (ja) 与信事務管理システムおよびその方法
US20180197240A1 (en) Banking system, method and computer-readable storage medium for credit management for structured finance
US8832120B2 (en) Methods and systems for analyzing weirdness of variables
US20190392018A1 (en) Displaying Data Using Enhanced Functionality
US20160307161A1 (en) Benefits enrollment server system and method
US20180197160A1 (en) Dashboard patient self service product enhancement
JP2009070028A (ja) 投資契約支援装置、投資契約支援プログラム
JP6750080B1 (ja) 運用支援装置及び運用支援プログラム
JP6898384B2 (ja) 保険契約管理システム、保険契約管理方法、及びプログラム
JP6670780B2 (ja) 取引先名称確認装置、取引先名称確認方法及びプログラム
JP5646097B1 (ja) 情報管理システムおよび情報管理方法
Tuncer et al. Bridging pre-trade and post-trade processes with the Legal Entity Identifier for a more efficient trade and client life-cycle management
WO2023137289A2 (en) Digital consolidation
CA3139311A1 (en) System and method for ledger analytics and application of digital tax stamps
Abdullah et al. Data Mining Driven Rule Based Expert System for Medical Billing Compliance: A Case Study
National Research Council Social security administration electronic service provision: a strategic assessment
Guyton et al. Transforming the revenue cycle: tighter accountability, reduced variability, better information management, and more comprehensive integration will fuel the transformation

Legal Events

Date Code Title Description
ENP Entry into the national phase

Ref document number: 2016516113

Country of ref document: JP

Kind code of ref document: A

121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 15887409

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 15563244

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 15887409

Country of ref document: EP

Kind code of ref document: A1