JP5758948B2 - Electronic record receivable liquidation management system - Google Patents

Description

  The present invention relates to a liquidation management system for electronic record receivables.

  Accounts receivable arising from product sales and service provisions, in principle, cannot be cashed until the settlement date. Therefore, for the purpose of raising funds for creditors, creditors may transfer accounts receivable to third parties such as financial institutions (hereinafter simply referred to as “financial institutions”) and receive funds as transfer prices instead. There is a mechanism called “liquidation of accounts receivable”. Since transfers in the receivables securitization are made non-recourse (even if the obligor becomes unable to pay), the underlying creditor who is the assigner has no recourse obligation). Make a credit decision. Depending on the credit judgment, whether or not liquidation is possible, the limit of the liquidation and the interest rate, etc. are determined, and if it is judged that liquidation is possible, the accounts receivable generated thereafter are transferred to a financial institution. In addition, when receivables are transferred, it is necessary to obtain a fixed date as a third party countermeasure requirement.

  However, when receivables are circulated and liquidated, a series of actions such as the generation, transfer, and acquisition of a fixed date of receivables are confirmed between each debtor, creditor, and financial institution. It was necessary and the amount of work was enormous. In addition, measures have been taken to conclude a three-party agreement between the debtor, creditor, and financial institution to ease this enormous amount of work.

  On the other hand, for the purpose of facilitating fund procurement, etc., an electronic record receivable system was established in 2007, which is characterized by managing electronic record receivables at an electronic receivable recording organization. In the electronic record receivable system, a new monetary receivable electronic record receivable is recorded in the record base of the electronic receivables record organization when it is generated or transferred, making this a requirement for countering third parties. . Therefore, in the case of electronically recorded receivables, there is no need to obtain a fixed date as in the past, and the generation and transfer of electronically recorded receivables can be confirmed by checking the electronic records. It can be handled with a contract between two persons. Moreover, since the information of the guarantor of the debtor is also present as an electronic record, it can be used when making a credit decision for securitization. Therefore, there is a demand for a system for managing the liquidation of electronic record receivables and this.

In order to achieve such an object, the present invention
Means for receiving bond data;
Means for determining whether or not the received bond data is a liquidation target based on preset liquidation condition data;
And means for recording transfer of the received bond data from a settlement account of the creditor to a specific account when it is determined that the received bond data is a liquidation target.

  In the invention described in the preceding paragraph, the liquidation condition data includes creditor identification data, debtor identification data, guarantor identification data, condition data relating to the amount of receivable, and condition data relating to the due date. Including at least one of them.

  Further, in the invention described in the preceding paragraph, the creditor identification data is creditor financial institution data and settlement account data, and the debtor identification data and the guarantor identification data are the debtor data, respectively. And the user number of the guarantor, and the system further comprises means for obtaining the user numbers of the debtor and the guarantor based on the received bond data, respectively. .

  Further, in the invention described in the preceding paragraph, the means for acquiring the user number is based on the debtor and guarantor financial institution data and settlement account data included in the received bond data. The user numbers of the debtor and the guarantor are respectively acquired.

  In the invention described in the preceding paragraph, acquisition of user numbers of the debtor and the guarantor makes an inquiry request to at least one of external systems including Densai Net (registered trademark). It is characterized by acquiring by this.

  As described above, according to the present invention, it is possible to manage the securitization of electronically recorded receivables, and the securitization of electronically recorded receivables can be handled by a bilateral contract between a creditor and a financial institution. Moreover, since the information of the guarantor of the debtor is also present as an electronic record, it can be used when making a credit decision for securitization.

It is a figure which shows the system configuration | structure which concerns on one Embodiment of this invention. It is a figure which shows the data stored in the supplier data storage part which concerns on one Embodiment of this invention. It is a figure which shows the data stored in the fluidization condition data storage part which concerns on one Embodiment of this invention. It is a figure which shows the data stored in the bond data storage part which concerns on one Embodiment of this invention. It is a figure which shows the data stored in the fluidization object data storage part which concerns on one Embodiment of this invention. It is a flowchart which shows the electronic record loan fluidization process which concerns on one Embodiment of this invention.

  Hereinafter, with reference to the accompanying drawings, a detailed description will be given of an electronically recorded bond liquidation system according to an embodiment of the present invention.

  First, the outline of the electronic record receivable liquidation system will be explained. FIG. 1 is a diagram showing a system configuration according to an embodiment of the present invention. In FIG. 1, a Densai net server 100 is a server installed in an all-bank electronic bond network of an electronic bond recording organization of the National Bank Association. The electronically recorded bond securitization server 101 installed in a data center or the like is configured to communicate with the Densai net server 100 via a network 102 (for example, the Internet). The electronic record receivables mobilization server 101 is connected to one or a plurality of administrator terminals 104a,..., 104n (hereinafter collectively referred to as “manager terminal 104”) via a network 103 (for example, an intranet or an extranet). Communication). In FIG. 1, the electronic record receivables mobilization server 101 is shown as a single server, but it can also be configured as a distributed system with a plurality of servers.

  The electronically recorded bond securitization server 101 receives the bond data from the Densai net server 100 and determines whether or not the creditor related to the received bond data uses liquidation. When the creditor uses securitization, it is determined whether or not the received credit data is subject to securitization based on the securitization condition data registered in advance via the manager terminal 104. When it is determined that it is a liquidation target, the electronically-recorded bond liquidation server 101 performs transfer recording on the target bond data in an SPC (specific purpose company) account that is a liquidation target account.

  Next, the configuration of the electronic record bond securitization server 101 will be described in detail. In FIG. 1, only a necessary functional configuration is shown assuming a single computer system.

  The electronic record receivables mobilization server 101 includes a CPU 110, a storage device including a RAM 111, an input device 112, an output device 113, a communication control device 114, and a nonvolatile storage medium (ROM, HDD, etc.) via a system bus 115. 116 is connected. The storage device 116 includes a program storage area for storing a software program for performing each function of the electronic record bond securitization system, and a data storage area for storing data handled by the software program. Each means in the program storage area described below is actually an independent software program, its routines, components, and the like, which are called from the storage device 116 by the CPU 110 and expanded in the work area of the RAM 111, with reference to the database and the like as appropriate. Each function is performed by being executed sequentially.

  If only the data storage areas in the storage device 116 related to the present invention are listed, the supplier data storage unit 131, the securitization condition data storage unit 132, the bond data storage unit 133, and the liquidation target data storage unit 134 are listed. Prepare. Both are fixed storage areas secured in the storage device 116.

  The supplier data storage unit 131 stores customer customer data. FIG. 2 is a diagram showing data stored in the supplier data storage unit 131 according to an embodiment of the present invention. The customer data in FIG. 2 indicates “user number” that uniquely identifies the customer, the financial institution data and the settlement account data of the customer, and whether or not the customer uses the electronic record receivable liquidation. "Fluidization use flag" is included. A character string such as “Normal” is set in “Account Type”, but a numerical value (for example, 1: normal deposit, 2: current account, 3:...) That uniquely identifies the account type is set. You can also In addition, the “liquidation use flag” stores, for example, “0” when not using electronic record bond liquidation and “1” when using it. In the supplier data in FIG. 2, the “liquidation use flag” is set for each creditor settlement account. However, as another embodiment, it can be set for each supplier (creditor).

  The liquidation condition data storage unit 132 stores data for determining whether the bond data is a liquidation target. FIG. 3 is a diagram showing data stored in the fluidization condition data storage unit 132 according to an embodiment of the present invention. The liquidation condition data in FIG. 3 indicates the creditor's financial institution data and settlement account data, the obligor user number that uniquely identifies the debtor, or the guarantor user number that uniquely identifies the guarantor. “Number”, “amount to be securitized” indicating the condition of the amount of receivables to be securitized, and “target date range” indicating the range of payment dates to be securitized. The “user number” is stored with a mixture of debtor or guarantor user numbers. In other words, if either the obligor or the guarantor meets the liquidation conditions for the settlement account of the creditor, it can be determined as the liquidation target (by having other requirements). Further, the liquidation condition data in FIG. 3 is set for each creditor settlement account, but as another embodiment, it can be set for each creditor.

  As a general rule, when each item included in the liquidation condition data is each condition to be liquidated and the contents of the bond data match all the conditions for one record, it is determined that the item is to be liquidated. In addition, the upper limit and lower limit of the amount of receivables to be securitized are specified in “amount of liquidation target”. The lower limit value is specified in “Money to be liquidated” in FIG. 3, and taking the first record as an example indicates that a loan with a bond amount of 100,000 yen or more is to be liquidated. On the other hand, in the “target date range”, a range of payment dates to be liquidated is designated. The “target date range” in FIG. 3 specifies a monthly range, and taking the first record as an example indicates that a claim whose payment date is within three months is to be liquidated. As the “target date range”, not only a monthly unit but also other units such as a daily unit can be used. In addition, “Liquidation Amount” and “Target Date Range” in FIG. 3 specify the lower limit value and monthly range of the amount of receivables, respectively. / Detailed conditions can also be set by adding an item (not shown) for identifying the monthly unit.

  The bond data storage unit 133 stores bond data. FIG. 4 is a diagram showing data stored in the bond data storage unit 133 according to an embodiment of the present invention. The credit data in FIG. 4 includes a “record number” that uniquely identifies the claim, an “date of occurrence” that indicates the date of occurrence of the claim, a “date of payment” that indicates the due date of the amount of the claim, a “credit amount” that indicates the amount of the claim, Includes creditor financial institution data and settlement account data, debtor financial institution data and settlement account data, and guarantor financial institution data and settlement account data.

  The liquidation target data storage unit 134 stores bond data determined to be liquidation targets. FIG. 5 is a diagram showing data stored in the fluidization target data storage unit 134 according to an embodiment of the present invention. The liquidation target data in FIG. 5 includes a “record number” corresponding to the bond data in FIG.

  Next, only the software programs stored in the program storage area in the storage device 116 that are related to the present invention are listed, the bond data receiving means 120, the liquidation target determining means 121, the user number obtaining means 122, And a transfer recording means 123. These means 120-123 are executed by the CPU 110.

  The bond data receiving means 120 receives bond data from an external system such as the Densai net server 100 and stores it in the bond data storage unit 133.

  Based on the data stored in the supplier data storage unit 131, the liquidation target determination unit 121 determines whether or not the creditor related to the received bond data uses liquidation. When a creditor uses liquidation, it is determined whether or not the received bond data is a liquidation target based on the data stored in the liquidation condition data storage unit 132. The target bond data is stored in the liquidation target data storage unit 134.

  The user number acquisition unit 122, when the liquidation target determination unit 121 determines that the creditor uses the liquidation, the user number of the debtor and the guarantor related to the bond data received by the bond data reception unit 120. In order to obtain it, a user number inquiry request is made to an external system such as Densai Net Server 100.

  The transfer recording unit 123 performs transfer recording on the SPC account in order to perform the liquidation on the bond data determined to be the liquidation target by the liquidation target determination unit 121.

  Next, with reference to the flowchart of FIG. 6 and the table of FIGS. 2-5, the electronic record bond fluidization process according to an embodiment of the present invention will be described along the flow.

  FIG. 6 is a flowchart showing the electronic record bond liquidation process according to the embodiment of the present invention. First, in step 601, the electronically recorded bond liquidation server 101 receives bond data (FIG. 4) from the Densai net server 100. Receivable data can be received every time it is generated, or the receivable data accumulated for a certain period can be received together. It should be understood that when bond data is received collectively, the following processing is executed for each bond data.

  Next, in step 602, the electronically recorded bond securitization server 101 determines whether or not the creditor associated with the received bond data uses liquidation. Specifically, using FIG. 4 as an example, the creditor's financial institution code, branch code, settlement account type, and settlement account number included in the received bond data are used as search keys for the customer data (FIG. 2). And then make a determination based on the value of the fluidization use flag. For example, when the liquidation use flag is “1” indicating that the liquidation is used, it is determined that the creditor related to the received bond data uses the liquidation.

  If it is determined in step 602 that the creditor associated with the received bond data does not use liquidation, the process proceeds to the No route in step 603, and the process ends.

  On the other hand, if it is determined in step 602 that the creditor related to the received bond data uses liquidation, the process proceeds to a Yes route in step 603, and in step 604, the electronically recorded bond liquidation server 101 has received Based on the bond data, the borrower and guarantor user numbers are acquired from the Densai net server 100. Specifically, using FIG. 4 as an example, the search is made using the financial institution code, branch code, settlement account type, and settlement account number of the debtor and guarantor included in the received bond data as a search key. An inquiry request for each user number is made to the net server 100. In response to the inquiry request, the densai net server 100 searches and returns the user numbers of the debtor and the guarantor, so that the electronically recorded bond liquidation server 101 can receive (acquire) each user number. it can. Of course, when there is no guarantor, it is not necessary to obtain the user number of the guarantor.

  Next, in step 605, the electronically-recorded bond liquidation server 101 determines whether the received bond data is a liquidation target based on the liquidation condition data. Specifically, the borrower and guarantor user numbers acquired in step 604, the creditor's financial institution code, branch code, settlement account type, settlement account number, and claims included in the received bond data The liquidation condition data (FIG. 3) is searched using the amount and payment date as search keys. The search is based on the creditor's financial institution code, branch code, settlement account type, settlement account number, and obligor or guarantor user number, and the amount of the loan is subject to liquidation. If the payment date is within the target date range, the amount of payment is within the target date range, the corresponding record exists in the securitization condition data, and therefore it can be determined that the received bond data is the liquidation target. Note that the “user number” in FIG. 3 includes a mixture of debtor and guarantor user numbers. Therefore, when searching, the user numbers of the debtor and guarantor are individually set. Or a search using an OR condition is required. In addition, after obtaining a record with fewer search keys (for example, creditor's financial institution code, branch code, settlement account type, and settlement account number), each item of the securitization condition data may be individually judged. it can. Further, whether the payment due date is within the target date range may be determined based on whether the payment date is within the target date range from the date of occurrence included in the claim data, or the date of execution of this processing ( For example, it may be determined whether or not the payment due date is within the target due date range starting from the system date of the electronically-recorded bond securitization server 101. Which is the date of calculation is within the scope of mere design changes. In addition, it is also within the scope of mere design changes to set the amount to be fluidized as an upper limit value or a lower limit value, and to set the target date range within the range or after.

  If it is determined in step 605 that the received bond data is not a liquidation target, the process proceeds to No route in step 606, and this process ends.

  On the other hand, when it is determined in step 605 that the received bond data is the liquidation target, the electronically recorded bond liquidation server 101 stores the received bond data as the liquidation target data (FIG. 5), and the step Proceed to 606 Yes route and record transfer to SPC account. Specifically, the electronically recorded receivables securitization server 101 transfers the refinancing target receivable data from the creditor's settlement account to the SPC account based on the liquidation target data. The transfer record can be performed for each target receivable data, or receivable data accumulated for a certain period can be collectively performed.

Claims (7)

A system for managing the liquidation of electronically recorded receivables, the system comprising:
Means for receiving bond data;
In response to receiving the bond data, the condition data relating to only the received bond data is acquired from preset liquidation condition data including at least guarantor identification data, and the acquired condition data Based on the above, the means for determining whether the received bond data is a liquidation target, the determination whether the received bond data is a liquidation target is a liquidation use flag, Executed when indicating to use the liquidation, the liquidation use flag is associated with the bond data and set for each creditor who is a user of the liquidation ;
And a means for recording transfer of the received bond data from a settlement account of the creditor to a specific account when it is determined that the received bond data is a liquidation target. . Claim wherein the fluidizing condition data, characterized in that it further comprises at least one of the condition data relating to the creditor's identification data, debtor's identification data, condition data relating to amount of receivables, and due date The system according to 1.   The creditor identification data is creditor financial institution data and settlement account data, and the debtor identification data and guarantor identification data are the debtor and guarantor user numbers, respectively. The system according to claim 2, further comprising means for acquiring user numbers of the debtor and the guarantor based on the received bond data.   The means for obtaining the user number is based on financial data and settlement account data of the debtor and the guarantor included in the received bond data, and obtains the user numbers of the debtor and the guarantor. The system according to claim 3, wherein each system is acquired.   5. The user numbers of the debtor and the guarantor are acquired by making an inquiry request to at least one of external systems including Densai Net. System. A method for managing the liquidation of electronically recorded receivables, the method comprising:
A server computer receiving bond data;
In response to receiving the bond data, the server computer acquires condition data relating to only the received bond data from preset liquidation condition data including at least guarantor identification data , The step of determining whether or not the received bond data is a liquidation target based on the acquired condition data, wherein the determination of whether or not the received bond data is a liquidation target is a flow Executed when the securitization use flag indicates that the securitization is used, and the securitization use flag is associated with the bond data and is set for each creditor who is the liquidation user. When,
When it is determined that the received bond data is subject to liquidation, the server computer includes a step of recording transfer from the settlement account of the creditor to a specific account for the previously received bond data. A method characterized by that. A computer program having computer-executable instructions for executing a method for managing the liquidation of electronic record receivables, the method comprising:
Receiving the bond data;
In response to receiving the bond data, the condition data relating to only the received bond data is acquired from preset liquidation condition data including at least guarantor identification data, and the acquired condition data And determining whether or not the received bond data is a liquidation target, and determining whether or not the received bond data is a liquidation target is a liquidation use flag, Executed when indicating to use the liquidation, the liquidation use flag is associated with the bond data and set for each creditor who is a user of the liquidation ;
And a step of recording transfer of the received bond data from a settlement account of the creditor to a specific account when it is determined that the received bond data is a liquidation target. program.

Images