JP2006285589A - System for supporting agent service of syndicate loan - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a system for supporting agent service of a syndicate loan. <P>SOLUTION: The agent service support system 100 is provided with a server 110 capable of carrying out communication via a network 20, an agent service management system 120 providing various services via the server 110, and a database group 130 storing various data related to agent service. A common platform can be provided to concerned parties with different roles in regard to a plurality of issues. By providing a tranche management database managing sub transactions, even a transaction that is plurally divided to be carried out such as a commitment line can be flexibly coped with. Notification and confirmation of permission with respect to each event of the transaction is automatically carried out. By providing interlocking with an accounting system of a settlement account, deposit confirmation of funds such as financing, payment, and fees is automated. <P>COPYRIGHT: (C)2007,JPO&INPIT

Description

  The present invention relates to a system for supporting an agent service of a syndicated loan.

  Syndicated loan (co-financing) refers to borrowers who require large-scale fund procurement, and multiple financial institutions form a co-financing group (syndicated group) and lend under the same conditions based on a single loan agreement This is a loan form. In general, the party who plays the core role of a syndicated loan is called an arranger. The arranger recruits investors such as financial institutions, and as the secretary of the syndicate group, identifies the needs of both the borrower and the investor, sets the loan conditions, creates the syndicate group, prepares and adjusts the contract. The agent of the syndicate is called the agent, and the financial institution serves as the investor's window to notify the principal and interest of the borrower, various fees, etc. Helps to disclose information to the home.

  In syndicated loans, first, arrangers form syndicates to negotiate contract terms according to the borrower's funding needs. Contract terms mainly include term loans, commitment lines and term loans with commitment terms. A term loan (certificate loan) is usually a certificate loan contract with a medium to long loan period. Commitment line (financial facility) means to repeatedly provide loans within a certain range of conditions such as the maximum amount and period (usually within one year) of the loan set in advance between the borrower and the financial institution. A contract to commit. A term loan with a commitment line term is a term loan that is divided into a certain period (usually one year) from the time of contract and is granted a commitment period that promises to be financed. It is similar to the commitment line in that the loan is executed by dividing it within a predetermined frame, but it differs from the commitment line in that the extreme frame is not restored by repayment of the loan.

  When the contents and conditions of the loan are collected and a contract is concluded, the agent takes over the work of the syndicate team and the loan is executed according to the contract. Specifically, first, upon receipt of the borrower's application for borrowing, the agent calculates the cash flow related to the loan, including the allocation of the loan amount to the arranger and the investor, the applicable interest rate, and the commission based on the contract conditions. And notify each party. Next, based on this cash flow, funds are deposited from the investor to the settlement account managed by the agent on the day of the loan. When payment of the loan amount of the day is confirmed in this settlement account, funds are transferred from the settlement account to the borrower's designated account, and the borrower's fund procurement is completed. The agent notifies each party and borrower of the syndicate to complete the loan.

  At the time of loan repayment, according to the repayment application by the borrower or the repayment schedule decided in advance, the agent calculates the cash flow related to the repayment including the allocation of principal and interest repayment amount to each party of the syndicate team and the fee , Notify each party. Next, based on this cash flow, funds are deposited from the borrower into the agent's settlement account on the day of repayment. Once the payment is confirmed in the settlement account, the funds are transferred from the settlement account to each investor's designated account, and the syndication team is notified of the completion of the repayment. To do. Patent Document 1 describes the composition of a syndicate group by a plurality of securities companies related to a procedure for issuing bonds.

JP 2002-149982 A

  Traditionally, agents are often assigned as arrangers, who are the secretaries of the syndicate team, and different financial institutions are in charge of different projects. In addition, many of the investors in the syndicate are financial institutions, and often have multiple roles such as arrangers, agents, and investors for multiple projects. However, even if the projects are different, the co-financing agent service has many parts that are common in terms of procedures, and by using a common system, significant time and cost reductions are expected. Therefore, it is desirable not only to systemize agent operations but also to systematically provide different services according to the roles of each party for each item on a common platform.

  In addition, financing and repayment of each project may be executed by dividing it into a plurality of transactions (child transactions) within a contract framework like a commitment line. Therefore, the agent must manage these child transactions and adjust the transactions so that the transactions are executed normally for each event of the child transactions. Also, depending on the situation, the contents of these child transactions may be changed. In such a case, notification of the changed contents to each party and confirmation from each party must be performed. As described above, it is desired that various loan projects can be flexibly handled and that each event is notified and confirmed to each party accurately.

  Furthermore, it is desirable that the payment of funds related to financing or repayment in the settlement account managed by the agent is automatically confirmed, and the notification and confirmation work for each party is automated.

  The present invention has been made in view of such problems, and the object of the present invention is to provide a flexible and efficient system for supporting an agent service by systemizing the agent service in a syndicated loan. There is to do.

  In order to achieve the above object, the present invention provides a borrower that borrows a syndicated loan, an arranger that forms a syndicate group for the borrower, and the syndicated group. A system for supporting the agent business of a syndicated loan that can be accessed by an investor participating in the above and an agent that organizes and executes the work of the syndicate team, from agents, arrangers, borrowers and investors Type information indicating the type of a party, a management number for uniquely identifying each party, database means for storing transaction contents of the syndicated loan associated with the management number, and according to the type information, A dedicated web that presents the transaction contents associated with the parties in a predetermined format. Characterized in that a web site generating means for generating a site from the database.

  The invention described in claim 2 is a borrower that borrows a syndicated loan, an arranger that collects a syndicated loan contract for the borrower, an investor who participates in the syndicated loan contract, and the syndicated loan. A system for supporting the agent business of a syndicated loan that can be accessed by an agent acting on behalf of the office of the company, and a management number that uniquely identifies each of the parties consisting of the agent, arranger, borrower, and investor, Database means storing the conditions of the syndicated loan contract associated with the management number, and accepting a request for a child transaction from the authorized party, and the child transaction is within the conditions of the syndicated loan contract Verify whether the database A child transaction registration means for registering, and a transaction confirmation means for receiving an input as to whether or not the child transaction registered by the child transaction registration means has been executed and recording the result in the database. To do.

  The invention described in claim 3 includes a borrower who borrows a syndicated loan, an arranger who forms a syndicate group for the borrower, an investor who participates in the syndicate group, and an office work of the syndicate group A system for supporting the agent operation of a syndicated loan that can be accessed by an agent acting on behalf of the agent, a management number for uniquely identifying each of the parties consisting of the agent, arranger, borrower and investor, and the management Database means for storing notification event information associated with a number, and event notification means for making a predetermined notification to each party based on the occurrence of an event registered in the notification event information And

  The invention described in claim 4 includes a borrower who borrows a syndicated loan, an arranger who forms a syndicate group for the borrower, an investor who participates in the syndicate group, and an office work of the syndicate group A system for supporting the agent operation of a syndicated loan that can be accessed by an agent acting on behalf of the agent, a management number for uniquely identifying each of the parties consisting of the agent, arranger, borrower and investor, and the management A database means for storing a transaction amount associated with a number, a transaction date and a transaction content including a transaction account, and an access to a bank account system that records the deposit and withdrawal of funds to and from the transaction account. Transfer of the transaction amount to the transaction account of the account system on the due date And account monitoring means for monitoring whether a, characterized by comprising a database update means for recording the result in the database when there is movement of the transaction amount by the account monitoring means.

  According to the present invention, by constructing a system that can be commonly used by each party regarding the agent business of a syndicated loan, it is possible to significantly reduce a lot of human labor and time related to the syndicated loan. This makes it possible to process syndicated loans at low cost. In addition, the systemization automates the calculation of cash flows such as the allocation of funds at the time of financing and repayment, the applicable interest rate, and commissions, thereby reducing accidents due to human error. In addition, it becomes possible to flexibly cope with changes in conditions for loans and repayments. Furthermore, the time management of each event at the time of transaction execution is automated, which contributes to accurate execution of financing and repayment.

  Hereinafter, embodiments of the present invention will be described in detail with reference to the drawings.

  FIG. 1 is a schematic diagram illustrating a use environment of a system for supporting an agent service of a syndicated loan according to the present invention. The agent task support system 100 includes a server 110 that can communicate via the network 20 such as the Internet, an agent task management system 120 that manages the agent task and provides services via the server 110, and an agent task. And a database group 130 for storing such various data.

  The agent 30A and the arranger 40A related to the case A of the syndicated loan can receive the service of the agent task management system 120 by communicating with the server 110 via the network 20 from a terminal (not shown). Similarly, the agents 30B and 30C and the arrangers 40B and 40C related to the syndicated loan projects B and C communicate with the server 110 via the network 20 from the terminals 31B and 31C, respectively. Can receive. In addition, the investors 50A-1 to N (N represents an arbitrary integer) and the borrower 60A related to the syndicated loan item A also communicate with the server 110 via the network 20 from the terminal (not shown). The service of the business management system 120 can be received. Similarly, investors 50B-1 to M and 50C-1 to L (M and L represent arbitrary integers) relating to syndicated loan projects B and C and borrowers 60B and 60C are respectively terminals (see FIG. The service of the agent task management system 120 can be received by communicating with the server 110 via the network 20 from (not shown).

  The service provided by the agent business support system 100 includes, for example, each party of a syndicated loan obtaining necessary information by accessing the server 110 using a web browser or the like (not shown). For example, the business management system 120 may provide information to each party via an e-mail or the like via the server 110. As described above, the agent business support system 100 according to the present invention can simultaneously provide services on a common platform for a plurality of syndicated loan projects.

(Database configuration)
FIG. 2 shows an example of the configuration of the agent business management system and database group in the agent business support system according to the present invention. As described above, the agent task support system 100 according to the present invention includes a server 110 that provides an interface with each party, an agent task management system 120 that manages the entire system, and a database group 130 that stores various data. It has. As shown in the figure, the agent task management system 120 manages a database group 130 having a plurality of databases.

  This database group 130 includes a party-specific management database 140 for registering information on each party of a syndicated loan, a case number management database 150 for allocating a unique number for each case, and a transaction content based on a contract for each case. The case information management database 160 to be defined, the time management database 170 that performs time management of events that occur for each case, and the agent-specific Temp management database 180 that performs time management of agent work for each agent.

  The party-specific management database 140 includes an agent management database 143 for registering agent information, an arranger management database 144 for registering arranger information, an investor management database 145 for registering investor information, and borrower information. And a borrower management database 146 to be registered. These databases store attribute information commonly used for each case in the agent business support system 100, and an example of the data structure is shown in FIG.

  FIG. 3A shows an example of the data structure of the agent management database. The agent management database 143 is registered as an investor, an agent management number field 143a for uniquely identifying an agent, a customer name field 143b for registering an agent name, an arranger management number field 143c when registered as an arranger, and an investor. Investor management number field 143d when registered as a borrower, Borrower management number field 143e when registered as a borrower, Dedicated website information field 143f where a dedicated website is registered, name of person in charge, address An individual attribute information field 143g for registering individual information such as a telephone number and an e-mail address.

  FIG. 3B shows an example of the data structure of the arranger management database. The arranger management database 144 has an arranger management number field 144a for uniquely identifying the arranger, a customer name field 144b for registering the name of the arranger, an agent management number field 144c when registered as an agent, and registered as an investor. Investment management number field 144d when registered as a borrower, borrower management number field 144e when registered as a borrower, dedicated website information field 144f where a dedicated website is registered, name of the person in charge, address And an individual attribute information field 144g for registering individual information such as a telephone number and an e-mail address.

  FIG. 3C shows an example of the data structure of the investor management database. The investor management database 145 includes an investor management number field 145a for uniquely identifying an investor, a customer name field 145b for registering an investor name, an agent management number field 145c when registered as an agent, Arranger management number field 145d when registered as an arranger, Borrower management number field 145e when registered as a borrower, Dedicated website information field 145f where a dedicated website is registered, and person in charge And an individual attribute information field 145g for registering individual information such as name, address, telephone number, and e-mail address.

  FIG. 3D shows an example of the data structure of the borrower database. The borrower management database 146 includes a borrower management number field 146a for uniquely identifying a borrower, a customer name field 146b for registering the name of the borrower, an agent management number field 146c when registered as an agent, Arranger management number 146d when registered as an arranger, investor management number field 146e when registered as an investor, dedicated website information field 146f where a dedicated website is registered, and the name of the person in charge An individual attribute information field 146g for registering individual information such as an address, a telephone number, and an e-mail address.

  According to an embodiment of the present invention, registration / deletion of entries in these databases is performed via the agent task management system 120. For example, an authorized person such as an agent can access the agent business management system 120 from the terminal 31 via the network 20 and register / delete an entry in the party-specific management database 140.

  For example, when registering a new case of a syndicated loan, if an authorized agent requests an entry from the terminal 31 to the agent business management system 120, the management number is automatically assigned in the case number management database 150, and the management database for each party A party corresponding to the new case can be selected from 140. For a party not registered in the management database for each party 140, when an entry for a new party is requested, a management number is automatically assigned, and information such as a customer name and individual attributes can be registered.

  According to one embodiment of the present invention, the case number management database 150 includes a case number database 151 and a settlement account management database 152. The case management number database 150 associates a specific case with a party management number of a party related to the case, and an example of the data structure is shown in FIG. Further, the settlement account management database 152 associates a specific case with an account number of a settlement account related to financing or repayment of the case, and an example of the data structure is shown in FIG.

  As shown in FIG. 4A, in the case number database 151, the case number field 151a for uniquely specifying the case, the party identification field 151b indicating the role of the party, and the party management number of the party-specific management database 140 are transferred. Party management number 151c. In this database, when there is a registration request for a new case, the case number 151a is automatically assigned, and by selecting a party from the party-specific management database 150, a party identification 151b is added according to the role of the party. The management number 151c is transcribed from the party-specific management database 140.

  As shown in FIG. 4B, the settlement account management database 152 includes a case number field 152a that uniquely identifies a case, a payment method field 152b that indicates whether a payment account can be automatically confirmed, and a payment account. A financial institution code field 152c indicating the financial institution, an account type field 152d indicating the account type of the settlement account, and an account number field 152e indicating the account number of the settlement account. In this database, when a new case is registered in the case number database 151, the case number is automatically transferred from the case number database 151, and an authorized agent can set the settlement method, financial institution code, account type, and account number for the case. Register.

  Next, the authorized agent registers item information in the item information management database 160 for the registered new item based on the contract contents of the item. The case information management database 160 includes a case information database 161 for registering contract contents related to a syndicated loan, and a tranche information database 162 for setting a child transaction based on the contract contents.

  FIG. 5A shows an example of the data structure of the case information database 161. The case information database 161 includes a case number field 161a that uniquely specifies a case, a transaction type field 161b that indicates the type of transaction, a transaction period field 161c that indicates a period related to the transaction, and a transaction amount field that indicates the loan amount of the transaction 161d, an interest rate information field 161e indicating an interest rate applied to the transaction, and fee information 161f indicating a fee calculation method for each party. In this database, when a new case is registered in the case number database 151, the case number is automatically posted from the case number database 151, and an authorized agent can determine the transaction type, transaction period, transaction amount, interest rate information, Register fee information.

  Examples of the transaction type 161b include a term loan, a commitment line, and a term loan with a commitment term. In the transaction period 161c, a loan execution date and a repayment deadline are registered for a term loan and a term loan with a commitment term, and a loan handling start date and a handling last date are registered for a commitment line. In the transaction amount 161d, a loan amount is registered in the case of a term loan, and a credit line is registered in the case of a term loan with a commitment line and a commitment term. The interest rate and the calculation method are registered in the interest rate information 161e. Information indicating the type of fee and its calculation method is registered in the fee information 161f. Here, the types of fees include, for example, arranger fee, agent fee, and commitment fee. Arranger fee is a fee paid by the borrower to the arranger. The agent fee is a fee paid by the borrower to the agent, and the commitment fee is a fee paid by the borrower to the investor.

  FIG. 5B shows an example of the data structure of the tranche management database 162. The tranche management database 162 indicates a case number field 162a for uniquely specifying a case, a tranche number 162b for uniquely specifying a child transaction, a child transaction amount field 162c indicating a loan amount of the child transaction, and a type of the child transaction. Child transaction type field 162d, child transaction period 162e indicating the period of the child transaction, interest rate information field 162f indicating the interest rate applied to the child transaction, ValueDate field 162g indicating the repayment date of the child transaction, and the child transaction of the agent An agent approach confirmation field 162h indicating whether or not to accept, an arranger approach confirming field 162i indicating whether or not to accept an arranger child transaction, and investor approach confirmation fields 162j and 162k indicating whether or not an investor accepts a child transaction. ing.

  In this database, the contents of a child transaction desired by the borrower can be registered within a framework of the contract for a certain project. Specifically, when registration of a child transaction is requested for a case with a borrower or an authorized agent, the case number is automatically transferred from the case number database 151, and the tranche number 162b is automatically assigned. The authorized agent registers the child transaction amount 162c, the child transaction type 162d, the child transaction period 162e, the child transaction interest rate information 162f, and the ValueDate 162g related to the child transaction. However, in the case of a term loan, since transactions are performed in a lump, the details of the case information database 161 are directly transferred to the corresponding fields of the tranche management database 162. These details are compared with the contents of the matter information database and other tranche management databases with the same matter number, and whether or not they are within the agreed contract range is automatically verified. Will be notified. The action confirmations 162h to k record the confirmation status as to whether or not each party has accepted the child transaction, as will be described later.

  Next, based on the contents of the tranche management database 162, a time management database 170 is generated. The time management database 170 includes a principal and interest cash flow database 172 indicating a loan and a repayment schedule of a transaction, a cash flow database 173 indicating a fee for each transaction, and a notification event database 174 for recording a notification event with each party. ing.

  FIG. 6A shows an example of the data structure of the principal and interest cash flow database 172. The principal and interest cash flow database 172 includes a tranche number field 172a that uniquely identifies a child transaction, a principal and interest number field 172b that uniquely identifies principal and interest, a division field 172c that indicates principal or interest, and a principal and interest Fund transfer date field 172d indicating the transfer date of funds, an amount field 172e indicating the amount of principal and interest, a side field 172f indicating the transfer direction (receipt / payment) of funds related to principal and interest, and whether transfer of funds is completed And a completed flag field 172g. This database is automatically generated when the tranche management database 162 is created. Specifically, the principal and interest are automatically calculated from the sub-transaction amount, sub-transaction type, sub-transaction period, sub-transaction interest rate information, and information registered in ValueDate in the tranche management database 162, and cash flow data is generated. The principal and interest number is automatically assigned to each principal and interest on the cash flow, and the fields of the category 172c, fund transfer date 172d, amount 172e, and side 172f are filled.

  FIG. 6B shows an example of the data structure of the fee cash flow database 173. The fee cash flow database 173 indicates a tranche number field 173a for uniquely identifying a case, a fee number field 173b for uniquely identifying a fee, a classification field 173c indicating a type of fee, and a transfer date of funds related to the fee. A fund transfer date field 173d, an amount field 173e indicating the amount of the fee, a side field 173f indicating the transfer direction (receipt / payment) of the funds related to the fee, and a completed flag field 173g indicating whether or not the transfer of funds is completed I have. This database is automatically generated when the case information database 161 is created. Specifically, a fee for each party is automatically calculated from information registered in the transaction type, transaction period, transaction amount, and fee information in the case information database 161, and cash flow data is generated. A commission number is automatically assigned to each commission on the cash flow, and fields of a division 173c, a fund transfer date 173d, an amount 173e, and a side 173f are filled.

  FIG. 6C shows an example of the data structure of the notification event database 174. The notification event database 174 records a case number field 174a for uniquely specifying a case number, a tranche number 174b for uniquely specifying a tranche number, a notification event number field 174c for uniquely specifying a notification event, and a notification type. A notification type field 174d for recording, a notification destination field 174e for recording a notification destination, a notification status field 174f indicating a notification status, a transmission time field 174g indicating a transmission time, and an elapsed time indicating an elapsed time after the transmission It includes a field 174h, a retransmission number field 174i indicating the number of retransmissions after the first transmission, and a reply time field 174j indicating a reply time for the transmission. This database is automatically generated when the case information management database 160 and the cash flow databases 172 and 173 are created, and the case number and the tranche number are automatically transferred from the tranche management database 162.

  In the notification type field 174d, the type of notification made to the party is registered. Specifically, a borrowing application notice, a cash flow confirmation notice, a loan schedule notice, a repayment notice, etc. are registered. In the notification destination field 174e, the party management number of the party that made the notification is recorded. The notification status field 174f indicates the status of whether or not a notification has been transmitted, whether or not receipt of the transmitted notification has been confirmed, and whether or not there has been a response to a notification that requires approval or disapproval.

  Next, an agent-specific Temp management database 180 is generated based on the contents of the principal and interest cash flow database 172 and the fee cash flow database 174. The agent-specific Temp management database 180 is generated for each agent and includes contents indicating the events of the day of each agent.

  FIG. 7 shows an example of the data structure of the agent-specific Temp database 180. The Temp database 180 for each agent includes a case number field 180a for uniquely specifying a case, a tranche number field 180b for uniquely specifying a tranche, a notification event number field 180c for uniquely specifying a notification event, and parties related to the case. A party control number field 180d to be specified, a schedule notification flag field 180e for storing the result of the agent confirming the event of the day, a day processing compliance flag field 180f for storing the result of acceptance / rejection for the event of the party, and a later-described A settlement method field 180g indicating whether or not automatic confirmation of a settlement account is possible, a side field 180h indicating a transfer direction (receipt / payment) of funds related to principal and interest, and a classification field 180i for identifying principal, interest or fee. , A management number field 180j to identify the principal and interest number or fee number, automatic confirmation of settlement account and a settlement account balance field 180k indicating the account balance in the case of the variable. This database is automatically created by extracting events that occur on the day from the principal and interest cash flow database 172 and the commission cash flow database 173. This event is notified to each party via the notification event database 174, and confirmation of receipt and confirmation of acceptance / rejection are also performed via the notification event database. Specifically, the event of the day is posted in the notification event database and notified to each party. The receipt confirmation of the notification from each party is recorded in the notification status 174f of the notification event database. For notifications that require approval / disapproval, the approval / disapproval from the agent is recorded in the notification status database 174 f and also in the scheduled notification flag 180 e of the agent-specific Temp database. The notification status 174f is recorded in the same day processing acceptance flag 180f of the Temp database for each agent.

(Processing flow)
Next, the flow of processing according to an embodiment of the agent business support system according to the present invention will be described. First, the management number and attribute information of a party are registered in the management database 140 for each party. The flow of this process is shown in FIG. This process is performed by an authorized agent accessing the agent task management system 120 from the terminal 31 via the server 110. The agent selects registration of a new party on the system 120 (step S802), and confirms whether the party to be registered is already registered (step S804). This can be confirmed by displaying a list of the party-specific management database 140 or searching the customer name field by the name of the party. If the party has not been registered, the type of the party to be registered is selected (step S806). Depending on the type of the selected party, the management number is automatically assigned by the system 120 on the management database 140 for each party (step S808), and the agent registers the customer name and individual attribute information from the terminal 31 to the database 140 (step S808). S810). If the party has already been registered, the type of the party is selected (step S812), and if the party has already been registered with that type, the process ends, and if not registered, A management number is automatically assigned (step S814), and the process ends.

  When a management number is automatically assigned to a party, a dedicated website is opened. The flow of this process is shown in FIG. This process is automatically performed by the system 120 for newly registered parties. First, a newly registered management number is extracted (step S902). Next, in accordance with the type of party (step S904), a dedicated website is opened on the server 110 in accordance with each fixed format (steps S906 to S912). Thereafter, various notifications and information for each party can be provided on this dedicated website.

  When a new party is registered, a notification of registration completion is sent to each party. The flow of this process is shown in FIG. This process is a process in which the system 120 automatically performs a notification process for each party, and is applied not only to the registration completion notification but also to various other notifications. First, the management number of the party requiring notification is extracted (step S1002). Next, according to the type of the party (step S1004), a notification regarding registration is created in accordance with each fixed format (steps S1006 to S1012). This notification can include notification contents such as registration on the system and establishment of a dedicated website. These notices can be sent to each party by means of mail, e-mail, a dedicated website, etc. based on the contents registered in the party-specific management database 140 (step S1014).

  Next, processing for registering a syndicated loan item will be described. The flow of this process is shown in FIG. A dedicated website is assigned to the agent registered in the agent management database 143 of the party-specific management database 140. For example, a new case can be registered from the website. When the agent logs in to the dedicated website and selects registration of a new case, the system 120 automatically assigns a case number on the case number database 151 (step S1102). If the party has already been registered in the management database 140 for each party with respect to the assigned project number, the party is selected. Otherwise, the party is registered in the database 140 according to the processing flow of FIG. Step S1104). Next, by setting transaction conditions such as transaction type, transaction period, amount, interest rate information, and the like based on the contract content of the new case, these contents are registered in the case information database 161 (step S1106). Further, by inputting information related to the settlement account, the contents are registered in the settlement account management database 152 (step S1108). The registered case number, case information, and settlement account information are notified to each party by e-mail or the like in a predetermined format according to the processing flow of FIG. 10 (step S1110).

  Next, with respect to the registered case, a process until the loan is completed will be described with reference to FIGS. 12 and 13. FIG. 12 shows the flow of processing from the borrower's application until the application is accepted. First of all, in the case of a commitment line, a borrower can apply for a child transaction within the framework of the contract content. In this case, the borrower logs in to his / her own dedicated website, designates the case number, and sets up the contents of the child transaction to apply for the child transaction (step S1202). The contents of this application are registered in the tranche management database 162 and notified to the agent who is in charge of the matter by e-mail or the like (step S1204). When the agent receives the application notification, the reception is notified to the borrower who made the application (step S1206). If the receipt is not notified within a predetermined time, the application is automatically re-notified to the agent. If a receipt is not notified after a predetermined number of re-notifications, a timeout occurs. These notification events are all recorded in the notification event database 174. If there is no problem with this application, the agent confirms compliance (step S1208). If the application from the borrower does not match the syndicated loan contract, the agent notifies the borrower that the contract condition does not match (step S1210), and the process ends. This notification of compliance or agreement mismatch is recorded in the approach confirmation 162h of the tranche management database 162.

  When the agent accepts the application, the process branches for each party (step S1212). If the agent and the arranger are not the same, the application content is notified to the arranger by e-mail or the like. When the arranger receives the application notification, the agent is notified of the receipt (step S1214). If the receipt notification is not made within a predetermined time, the re-notification of the application contents is automatically performed to the arranger. If no notification of receipt is made after a predetermined number of re-notifications, a timeout occurs. These notification events are all recorded in the notification event database 174. The arranger confirms acceptance or rejection of the application contents (step S1216). This acceptance or rejection is recorded in the approach confirmation 162i of the tranche management database 162.

  On the other hand, in step S1212, the application contents are notified to the investors in parallel by e-mail or the like. When the investor receives the notification of application, the agent is notified of the receipt (step S1218). If the receipt is not notified within a predetermined time, the application is automatically re-notified to the investor. If no notification of receipt is made after a predetermined number of re-notifications, a timeout occurs. These notification events are all recorded in the notification event database 174. The investor confirms acceptance or rejection of the contents of the application (step S1220). This acceptance or rejection is recorded in the action confirmation 162j of the tranche management database 162.

  When notification of refusal is made from either the arranger or the investor, the agent notifies the borrower of refusal (step S1210). On the other hand, upon receiving notification of compliance from all parties of the arranger and the investor, compliance notification is sent from the agent to the borrower (step S1222). When the child transaction is accepted in this way, the principal and interest cash flow database 172 and the fee cash flow database 173 are generated according to the transaction contents, and from each cash flow database, an agent-specific Temp is generated according to the event of the day. A database 180 is generated. In the above description, the case of a commitment line has been described as an example. However, in the case of a term loan, since transactions are performed in a lump, step S1202 is skipped, and the system automatically notifies the agent in step S1404. .

  Next, a process until financing is performed based on the agent-specific Temp database will be described. The flow of this process is shown in FIG. First, based on the Temp database for each agent, the loan schedule for the day is extracted (step S1302). The extracted loan schedule is notified to the agent who is in charge of the matter by e-mail or the like (step S1304). When the agent receives the notification (step S1306), the notification status 174f of the notification event database 174 is updated. When the agent accepts the loan schedule (step S1308), the schedule notification flag 180e of the agent Temp database 180 is set, and the process proceeds to step S1310. When the agent refuses the loan schedule (step S1308), the process proceeds to step S1316, and the party is notified of the failure of the loan. In step S1310, the other parties (arranger, investor and borrower) are notified of the loan schedule. When the other party receives the notification (step S1312) and accepts the loan schedule (step S1314), the current day processing compliance flag of the agent Temp database 180 is set. If the loan schedule is rejected by any of the other parties or if the loan schedule is not accepted within a predetermined time, the party is notified of the failure of the loan (step S1316). When the loan schedule is accepted from all of the other parties, the agent confirms payment to the settlement account from the investor (step S1318). If payment is not confirmed by the deadline (step S1320), the agent is notified of the failure of the loan (step S1316). When payment of a predetermined fund from the investor to the settlement account is confirmed (step S1320), all parties are notified of the completion of the loan (step S1322).

  Next, with respect to the case where the loan has been made, a process until the repayment is completed will be described with reference to FIGS. 14 and 15. FIG. 14 shows the flow of processing from the application for repayment by the borrower until the application is accepted. First, in the case of a commitment line, the borrower can apply for repayment within the scope specified in the contract. In this case, the borrower logs in to his / her own website, designates the case number, and sets the repayment content, thereby applying for repayment (step S1402). The contents of this application are registered in the tranche management database 162 and notified to the agent who is in charge of the matter by e-mail or the like (step S1404). When the agent receives the application notification, the reception is notified to the borrower who made the application (step S1406). If the receipt is not notified within a predetermined time, the application is automatically re-notified to the agent. If a receipt is not notified after a predetermined number of re-notifications, a timeout occurs. These notification events are all recorded in the notification event database 174. If there is no problem with this application, the agent confirms compliance (step S1408). If the application from the borrower has a mismatch with the syndicated loan contract, the agent notifies the borrower of the mismatch of the contract conditions (step S1410), and the process ends. This notification of compliance or agreement mismatch is recorded in the approach confirmation 162h of the tranche management database 162.

  When the agent accepts the application, the process branches for each party (step S1412). If the agent and the arranger are not the same, the application content is notified to the arranger by e-mail or the like. When the arranger receives the application notification, the agent is notified of the receipt (step S1414). If the receipt notification is not made within a predetermined time, the re-notification of the application contents is automatically performed to the arranger. If no notification of receipt is made after a predetermined number of re-notifications, a timeout occurs. These notification events are all recorded in the notification event database 174. The arranger confirms acceptance or rejection of the application contents (step S1416). This acceptance or rejection is recorded in the approach confirmation 162i of the tranche management database 162.

  On the other hand, in step S1412, the application contents are notified to the investors in parallel by e-mail or the like. When the investor receives the notification of application, the agent is notified of the receipt (step S1418). If the receipt is not notified within a predetermined time, the application is automatically re-notified to the investor. If no notification of receipt is made after a predetermined number of re-notifications, a timeout occurs. These notification events are all recorded in the notification event database 174. The investor confirms acceptance or rejection of the contents of the application (step S1420). This acceptance or rejection is recorded in the action confirmation 162j of the tranche management database 162.

  When notification of refusal is given from either the arranger or the investor, the agent notifies the borrower of refusal (step S1410). On the other hand, upon receipt of a compliance notice from all parties of the arranger and the investor, a compliance notice is sent from the agent to the borrower (step 1420). When the repayment is accepted in this way, the principal and interest cash flow database 172 and the fee cash flow database 173 are generated according to the transaction contents, and from these cash flow databases, the Temp database for each agent according to the event of the day 180 is generated. In the above description, the commitment line is taken as an example. However, in the case of a term loan, repayment is performed in a lump. Therefore, step S1202 is skipped, and the system automatically notifies the agent in step S1404. .

  Next, processing until repayment is performed based on the Temp database for each agent will be described. The flow of this process is shown in FIG. First, the repayment schedule of the day is extracted based on the Temp database for each agent (step S1502). The extracted repayment schedule is notified to the agent in charge of the matter by e-mail or the like (step S1504). When the agent receives the notification (step S1506), the notification status 174f of the notification event database 174 is updated. When the agent accepts the repayment schedule (step S1508), the schedule notification flag 180e of the agent Temp database 180 is set, and the process proceeds to step S1510. If the agent refuses the repayment schedule (step S1508), the process proceeds to step S1516, and the parties are notified of the repayment failure. In step S1510, the other parties (arranger, investor and borrower) are notified of the repayment schedule. When the other party receives the notification (step S1512) and accepts the repayment schedule (step S1514), the current day processing compliance flag of the agent Temp database 180 is set. If the repayment schedule is rejected from any of the other parties, or if the repayment schedule is not approved within a predetermined period, the party is notified of the repayment failure (step S1516). When the repayment schedule is accepted from all of the other parties, the agent confirms payment from the borrower to the settlement account (step S1518). If the payment is not confirmed by the time limit (step S1520), the agent is notified of the failure of repayment (step S1516). When payment of the predetermined funds from the borrower to the settlement account is confirmed (step S1520), notification of completion of repayment is made to all parties (step S1522).

  In one embodiment of the agent business support system according to the present invention, it is also possible to automatically confirm the payment to the settlement account from the investor at the time of financing or the payment to the settlement account from the borrower at the time of repayment. This is realized by linking the agent operation management system 120 with the accounting system 200 as shown in FIG. The flow of this process is shown in FIG. First, when it is confirmed in the payment method field 180g of the Temp database for each agent that the payment method is automatic (step S1602), payment is made to the payment account of the account system 200 specified in the payment account management database 152. Is confirmed (step S1604). If the amount recorded in the amount field (172e or 173e) of the principal and interest cash flow database 172 or the fee cash flow database 173 has not been deposited (step S1606), the process returns to the deposit confirmation process. When the payment is confirmed (step S1606), the party is notified of the payment completion (step S1608).

  In addition, when the payment to the settlement account is performed manually instead of automatically, it is as follows. That is, when it is confirmed in the payment method field 180g of the Temp database for each agent that the payment method is manual, the party who performs the deposit process for the payment account specified in the payment account management database 152 (usually the loan (In the case of investors, borrowers in the case of repayments) update the database through the dedicated website regarding the status of payment processing to the settlement account. As a result, the other parties are notified about the payment of the settlement account and can check the situation.

(Dedicated website)
Next, a dedicated website for each party in an embodiment of the agent business support system according to the present invention will be described. As described with reference to FIG. 9, when a new party is additionally registered, a dedicated website is created for each party. Each party can access specific information stored in the database group 130 through this dedicated website.

  FIG. 17A shows an example of a menu screen of the agent dedicated website. From this menu screen, the agent can search for a case in charge, or search for an event that occurs on a specified date. Agents also have access to information such as scheduled fund transfers for the day, other notifications from agents to agents, and administrative materials. The management material is provided, for example, in Excel format that can be easily handled offline.

  As an example, when the event search of FIG. 17A is executed, the event information screen shown in FIG. Here, various events scheduled for the specified date are displayed in a list. When the item number in this list is clicked, the details of the item recorded in the item information management database 160 are displayed as shown in FIG. Further, when the details button of the party-specific details is clicked, details of the parties related to the matter recorded in the party-specific management database 140 are displayed. When the settlement account monitor button is clicked, together with the account information of the settlement account management database 152, the history of funds transfer of the settlement account is displayed based on the cash flow information database 171.

  Clicking on the funds transfer information for the current day in FIG. 17 (a) changes to the screen for funds transfer information for the day shown in FIG. 17 (c). Here, a list of events on the current day of the case in which the agent is involved is displayed. When the item number in this list is clicked, the details of the item recorded in the item information management database 160 are displayed as shown in FIG. In addition, the settlement account balance is automatically updated when the payment of the settlement account is automatically confirmed.

  FIG. 18A shows an example of a menu screen of the borrower's dedicated website. From this menu screen, the borrower can search his / her case, search for events that occur on a specified date, and the like. Borrowers can also access information such as agent notifications, investor notifications, and administrative materials. The management material is provided, for example, in Excel format that can be easily handled offline.

  As an example, when the item search in FIG. 18A is executed, the screen changes to the item details screen shown in FIG. Here, the matter details such as the matter number, the list of parties, and the contract contents are displayed. For example, when one of the parties is clicked, the contact information of the party recorded in the management database for each party 140 is displayed. When the event search in FIG. 18A is executed, various events scheduled on the specified date are displayed in a list as shown in FIG. When the item number in this list is clicked, the item details recorded in the item information management database 160 are displayed.

  When the notification from the agent in FIG. 18A is clicked, the screen changes to a notification list screen from the agent shown in FIG. Here, notifications from the agent are displayed in a list with respect to the matters involving the borrower. When the item number in this list is clicked, the item details recorded in the item information management database 160 are displayed. When a notifier in this list is clicked, the notification content from the notifier is displayed.

  The present invention has been described above based on specific embodiments. However, in view of many possible embodiments to which the principles of the present invention can be applied, the embodiments described herein are merely examples, and It is not intended to limit the scope of the invention. The embodiments illustrated here can be modified in configuration and details without departing from the spirit of the present invention. Further, the components for explanation may be changed, supplemented, or changed in order without departing from the spirit of the present invention.

It is a schematic diagram which shows an example of the usage environment of the agent operation | work support system by this invention. It is the schematic which shows an example of a structure of the agent business management system and database group in the agent business support system by this invention. FIG. 3A shows an example of the data structure of the agent management database, and FIG. 3B shows an example of the data structure of the arranger management database. FIG. 3C shows an example of the data structure of the investor management database, and FIG. 3D shows an example of the data structure of the borrower management database. FIG. 4A shows an example of the data structure of the case number database, and FIG. 4B shows an example of the data structure of the settlement account management database. FIG. FIG. 5A shows an example of the data structure of the case information database, and FIG. 5B shows an example of the data structure of the tranche information database. FIG. 6 shows an example of the data structure of the timed management database according to the present invention, FIG. 6A shows an example of the data structure of the principal and interest cash flow database, and FIG. 6B shows an example of the data structure of the fee cash flow database. FIG. 6C shows an example of the data structure of the notification event database. It is a figure which shows an example of the data structure of Temp database classified by agent by this invention. It is a flowchart which shows an example of the process which registers the management number and attribute information of the party in the management database classified by party by this invention. It is a flowchart which shows an example of the process which opens the exclusive website according to the party by this invention. It is a flowchart which shows an example of the process which produces the notice according to the party by this invention. It is a flowchart which shows an example of the process which registers the case of the syndicated loan by this invention. It is a flowchart which shows an example of a process from the application of a borrower's loan by this invention until the acceptance or rejection of the application is confirmed. It is a flowchart which shows an example of a process until a loan is performed based on the Temp database classified by agent by this invention. It is a flowchart which shows an example of a process from the application of a borrower's repayment by this invention until the acceptance / rejection of the application is confirmed. It is a flowchart which shows an example of a process until repayment is performed based on the Temp database classified by agent by this invention. It is a flowchart which shows an example of the process which performs confirmation of the payment to the payment account by this invention automatically. FIG. 17 (a) shows an example of a menu screen, FIG. 17 (b) shows an example of an event information screen, and FIG. 17 (c) shows that day. FIG. 17D is a diagram showing an example of the item detail screen. FIG. 18 (a) shows an example of a menu screen, FIG. 18 (b) shows an example of a case details screen, and FIG. 18 (c) shows an example of a borrower-only website according to the present invention. An example of an event information screen is shown, and FIG. 18D is a diagram showing an example of a notification list screen.

Explanation of symbols

20 Network 30A, 30B, 30C Agent 40A, 40B, 40C Arranger 50A-1 to N, 50B-1 to M, 50C-1 to L Investor 60A, 60B, 60C Borrower 100 Agent business support system 110 Server 120 Agent business Management system 130 Database group 140 Party-specific management database 143 Agent management database 144 Arranger management database 145 Investor management database 146 Borrower management database 150A Case number management database 151A Case number database 152A Settlement account management database 160A Case information management database 161A Case information Database 162A Tranche Information Database 170A Timed Management Database 171 Cash flow information database 172A principal and interest cash flow database 173A commission cash flow database 174A notification event management database 180 by Agent Temp management database 180A, 180B, 180C, 180D agent Temp database 200 accounting system

Claims (4)

Access by a borrower who borrows a syndicated loan, an arranger that forms a syndicate group for the borrower, an investor who participates in the syndicate group, and an agent that organizes and executes the operations of the syndicate group A system for supporting syndicated loan agent business,
Database means for storing type information indicating types of parties consisting of agents, arrangers, borrowers and investors, a management number for uniquely identifying each party, and transaction contents of the syndicated loan associated with the management number When,
A system comprising: a website generating means for generating, from the database, a dedicated website for presenting the transaction contents associated with each party in a predetermined format according to the type information. A borrower who borrows a syndicated loan, an arranger who organizes a syndicated loan contract for the borrower, an investor who participates in the syndicated loan contract, and an agent who acts on behalf of the syndicated loan. A system for supporting syndicated loan agent business,
Database means for storing a management number that uniquely identifies each of the parties comprising an agent, an arranger, a borrower, and an investor, and the conditions of the syndicated loan agreement associated with the management number;
A child transaction registration means for accepting a request for a child transaction from the authorized party, verifying whether the child transaction is within the conditions of the syndicated loan contract and registering it in the database;
A system comprising: transaction confirmation means for accepting an input as to whether or not the child transaction registered by the child transaction registration means has been executed and recording the result in the database. A borrower who borrows a syndicated loan, an arranger who forms a syndicate group for the borrower, an investor who participates in the syndicate group, and an agent acting on behalf of the syndicate group can access A system for supporting syndicated loan agent business,
A database means for storing a management number that uniquely identifies each of the parties comprising an agent, an arranger, a borrower, and an investor, and notification event information associated with the management number;
A system comprising: event notification means for performing predetermined notification to each party based on the occurrence of an event registered in the notification event information. A borrower who borrows a syndicated loan, an arranger who forms a syndicate group for the borrower, an investor who participates in the syndicate group, and an agent acting on behalf of the syndicate group can access A system for supporting syndicated loan agent business,
A database means for storing a management number uniquely identifying each of the parties consisting of an agent, an arranger, a borrower and an investor, and a transaction content including a transaction amount, a transaction date and a transaction account associated with the management number;
Account monitoring means for accessing a bank account system that records the deposit and withdrawal of funds to and from the transaction account, and monitoring whether or not the transaction amount of the account account system has been transferred on the transaction date When,
A database update means for recording the result in the database when the transaction amount is transferred by the account monitoring means.

Images