JP2012160164A - Application method and application device - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a technology which executes application processing of a document while taking into consideration a state of securities business.SOLUTION: An application screen generation part 104 receives a start instruction of an application of securities business for a client through a reception part 96. An acquisition part 106 acquires information stored in a client information storage part 18 when receiving the start instruction. The application screen generation part 104 generates an application screen of the securities business for the client based on the acquired information and displays the screen on a display part 98. The application screen generation part 104 receives an application instruction of the securities business from an applicant. A transfer part 108 stores the information that has been used for generation of the application screen in an application information storage part 20 when receiving the application instruction.

Description

  The present invention relates to an application technique, and more particularly, to an application method and an application apparatus for executing an application related to securities business.

  In order to clarify the location of business responsibilities in an organization such as a company, documents are generally applied and approved. Conventionally, application and approval procedures for documents have been performed by signing or stamping using paper media. In recent years, with the spread of computers and networks, it has become possible to create application documents by computer, and data of application documents created at the applicant's terminal is transmitted to the approver's terminal through the network. In addition, by inputting approval at the approver's terminal, application and approval of the document can be performed quickly and easily.

  However, once the applicant has submitted the document data to the administrator, even if the document needs to be urgently revised after the application, it cannot be edited again until it is approved or rejected by the approver. . Therefore, it was not efficient. In order to respond to this, the document data is created, applied, approved, and application rejection status is centrally managed, and the status is changed from “Creating” to “Applying” on the applicant's terminal. Application is made by changing. Further, the application is withdrawn by changing from “in application” to “in preparation” (see, for example, Patent Document 1).

JP 2008-71183 A

  A system that performs application and approval in a computer network is also required for securities business. For example, in order to apply for a credit transaction account opening application form, a short-term sale notification form, etc. and receive approval, preparation of an application form and approval processing are required. There is a problem peculiar to securities business when trying to perform such application and approval in the securities business by a system that executes on a computer network. One of the issues is that various information according to the contents of the application is necessary to determine whether or not to approve the application. For example, it is owned by the customer as well as attribute information such as the customer's address, name, and age. Asset information and customer investment policies may be required. Here, information necessary for application / approval needs to be updated at an arbitrary timing, and the frequency and timing of the update differ depending on the information. For example, attribute information such as a customer's address is rarely updated, and the update timing can be freely updated when a customer contacts the customer or when a brokerage company employee contacts the customer to do business. Preferably it can be done. On the other hand, for the asset information of the customer, for example, since the stock price fluctuates daily, the update frequency is high, and the stock price information is normally updated regularly. Therefore, it is preferable that the asset information can be updated periodically to some extent. As described above, various information necessary for application and approval is diverse, and it is necessary to be able to update the information at different frequencies and timings. Hereinafter, this problem will be specifically described.

  Considering that the contents of the application and approval are audited afterwards, the information to be referred to at the time of application and approval is at least fixed at the time of application. Needs to be preserved after. For this reason, in order to apply and approve in the system, make it possible to update the information required for application and approval at any time and to fix the information referenced at the time of application and approval. There is a need.

  The present invention has been made in view of such circumstances, and its main object is to provide a technique for executing document application processing in consideration of the status of securities business.

  In order to solve the above-described problem, an application device according to an aspect of the present invention provides a first reception unit that receives an instruction to start an application for approval relating to securities business from an applicant, and a customer who receives a start instruction from the first reception unit An acquisition unit that acquires customer asset information and customer attribute information from a first storage unit that updates and stores the asset information and customer attribute information at any timing independently of the application device; Based on the customer asset information and customer attribute information acquired in the acquisition unit, a generation unit that generates an approval application screen for securities business, a display unit that displays the application screen generated in the generation unit, and a display unit In the state where the application screen is displayed, the second receiving unit that receives an application instruction from the applicant to apply for approval of securities business, and when the second receiving unit receives the application instruction, the generating unit generates the application screen. Shita The mobile unit that fixes and stores the customer asset information and the customer attribute information used in the second storage unit, and accepts an approval instruction from the approver for the application instruction received in the second reception unit. 3 reception units. The second storage unit executes the writing of the customer asset information and the customer attribute information by receiving the application instruction in the second reception unit, and the mobile unit receives the approval instruction when the third reception unit receives the approval instruction. The customer asset information and customer attribute information stored in the storage unit are stored in a third storage unit provided separately from the second storage unit in a state in which the customer asset information and the customer attribute information cannot be updated.

  It should be noted that any combination of the above-described constituent elements and a representation of the present invention converted between an apparatus, a method, a system, a program, a recording medium storing the program, etc. are also effective as an aspect of the present invention.

  According to the present invention, application processing for documents can be executed in consideration of the status of securities business.

It is a figure which shows the structure of the securities business system which concerns on the Example of this invention. It is a figure which shows the structure of the application server of FIG. It is a figure which shows the structure of the customer information generation part of FIG. It is a figure which shows the data structure of deposit DB of FIG. It is a figure which shows the data structure of asset DB of FIG. It is a figure which shows the data structure of common attribute DB of FIG. 7A to 7C are diagrams showing the data structure of the personal attribute DB of FIG. FIGS. 8A and 8B are diagrams showing the data structure of the corporate attribute DB of FIG. It is a figure which shows the structure of the document registration part of FIG. It is a figure which shows the application document registration screen produced | generated by the document production | generation part of FIG. It is a figure which shows the application document approver definition screen produced | generated by the document production | generation part of FIG. It is a figure which shows the structure of the application registration and inquiry part of FIG. It is a figure which shows the account specification and document selection screen produced | generated by the application screen production | generation part of FIG. It is a figure which shows the application content edit screen produced | generated by the application screen production | generation part of FIG. It is a figure which shows the application content inquiry screen produced | generated by the application screen production | generation part of FIG. It is a figure which shows another application content edit screen produced | generated by the application screen production | generation part of FIG. It is a figure which shows another application content inquiry screen produced | generated by the application screen production | generation part of FIG. 18A to 18F are diagrams showing the data structure of the application customer information DB of FIG. It is a figure which shows the data structure of the application management DB of FIG. It is a figure which shows another data structure of the application management DB of FIG. It is a figure which shows the data structure of application status management DB of FIG. It is a figure which shows the data structure of audit trail management DB of FIG. It is a figure which shows the application status list screen produced | generated by the application status inquiry part of FIG. It is a figure which shows the structure of the approval registration part of FIG. It is a figure which shows the approval status list screen produced | generated by the approval screen production | generation part of FIG. It is a figure which shows the approval content inquiry screen produced | generated by the approval screen production | generation part of FIG. It is a figure which shows the approver entry column edit screen produced | generated by the approval screen production | generation part of FIG. It is a figure which shows the structure of the paperwork registration part of FIG. It is a figure which shows the paperwork status list screen produced | generated by the paperwork registration part of FIG. It is a figure which shows the structure of the application storage part of FIG. It is a figure which shows the application storage list screen produced | generated by the application storage part of FIG. It is a figure which shows the structure of the audit trail management part of FIG. It is a figure which shows the application update log | history inquiry screen produced | generated by the audit trail management part of FIG. It is a sequence diagram which shows the procedure of the application process by the securities business system of FIG. It is a sequence diagram which shows the procedure of the approval process by the securities business system of FIG.

  Before describing the present invention specifically, an outline will be given first. The securities business system according to the embodiment of the present invention creates documents in securities business and applies for the created documents by operation of an applicant who is an employee of a securities company. In addition, the securities business system approves or disapproves the requested documents by the operation of an approver who is another employee of the securities company, and manages documents before and after approval. Here, the documents are, for example, a margin transaction account opening application form and a short-term sale registration form, which require application and approval for the purpose of complying with compliance to prevent fraudulent transactions. It is said. The securities business system for application and approval should be structured taking into account the circumstances specific to securities business.

  In approving, customer assets may be taken into account. Such assets include stocks, bonds, and investment trusts, which are also managed by the securities business system. Their value fluctuates daily, so customer assets fluctuate daily. In addition, attribute information such as a customer's name and address is required for approval, but such information fluctuates at an arbitrary timing. That is, since these pieces of information fluctuate at an arbitrary timing and frequency, it is desirable that the information can be updated at an arbitrary timing when managed by the system. On the other hand, if asset and customer attribute information is not fixed in the document to be approved, the approver cannot approve, and auditing after approval becomes difficult. Note that the customer information required for approval varies depending on whether the customer is an individual or a corporation. Therefore, it is desirable that information necessary for approval can be easily referred to at the time of application and approval when creating a document.

  In order to cope with these, in the securities business system according to the present embodiment, when an applicant creates a document, information required for application and approval can be updated from a database stored in a state that can be updated at an arbitrary timing. Extract the necessary data. Note that the extracted data varies depending on the type of customer. When applying for a document created by the applicant, the securities business system fixes the data extracted at the time of document creation and stores it in a separate database. In the other database, fixed data is stored. When an approver approves a document, a database storing fixed data is referred to. In this way, the data required for application and approval is stored in an updatable storage unit, updated at any time, acquired from this storage unit at the time of application, and fixed upon completion of the application. Fixed data is stored in a separate database.

  In the following, in order to clarify the explanation, the securities business system is divided into a plurality of explanations. First, 1. After explaining the overall configuration, 2. 2. Customer information generation process Document registration process, 4. 4. Application registration process 5. Approval registration process Business process registration process, 7. Application storage processing, 8. Each process of the audit trail management process will be described. Then, 9. The operation will be described.

1. Overall Configuration FIG. 1 shows a configuration of a securities business system 200 according to an embodiment of the present invention. The securities business system 200 includes an application server 10, a first terminal device 12a, a second terminal device 12b, which are collectively referred to as a terminal device 12, an asset information storage unit 14, a customer attribute storage unit 16, a customer information storage unit 18, and an application information storage. Unit 20, approval information storage unit 22, network 24, and customer information generation unit 70. The asset information storage unit 14 includes a deposit DB 30 and an asset DB 32, the customer attribute storage unit 16 includes a common attribute DB 34, a personal attribute DB 36, and a corporate attribute DB 38, and the customer information storage unit 18 includes an existing customer information management DB 40, a customer The card DB 42 is included. The application information storage unit 20 includes a first DB 44, a second DB 46, and an application document management DB 56, the first DB 44 includes an application customer information DB 48, and the second DB 46 includes an application management DB 50, an application status management DB 52, and an audit trail management DB 54. . The approval information storage unit 22 includes an application customer history information DB 58, an application history management DB 60, an application status history management DB 62, and an audit trail history management DB 64.

  The terminal device 12 is a device used when an employee of a securities company creates a document for securities business, and corresponds to a PC, for example. The terminal device 12 has a communication function and is connected to the network 24. In FIG. 1, two terminal apparatuses 12 are shown, but the present invention is not limited to this. The first terminal device 12a is used by an employee who should apply for documents (hereinafter referred to as “applicant”), and the second terminal device 12b is used by an employee who should approve the applied documents (hereinafter referred to as “approver”). ")".

  The application server 10 is a server connected to the terminal device 12 via the network 24. The application server 10 executes processing according to the instruction from the terminal device 12 and returns the result to the terminal device 12.

  The asset information storage unit 14 is a storage medium for storing the deposit DB 30 and the asset DB 32. The asset information storage unit 14 may be connected to the network 24 and accessed by the application server 10 to retrieve necessary information by the application server 10. In the embodiment of FIG. 1, a customer information generation unit 70 (to be described later) captures customer asset information and customer attributes from the asset information storage unit 14 and customer attribute storage unit 16 to obtain information necessary for application and approval for each customer. The information in the asset information storage unit 14 is extracted to the application server 10 via the customer information storage unit 18 that stores the generated information. The contents of the data stored in the deposit DB 30 and the asset DB 32 will be described later, but the contents of these data vary from day to day. The fluctuation cycle is generally shorter than one day, and the fluctuation timing is generally predetermined. As described above, the asset information storage unit 14 is a storage medium (first storage unit) for storing data updated at a predetermined timing in an updatable state.

  The customer attribute storage unit 16 is a storage medium for storing the common attribute DB 34, the personal attribute DB 36, and the corporate attribute DB 38. In the present embodiment, as described above, the information in the customer attribute storage unit 16 is configured to be retrieved by the application server 10 as information generated by the customer information generation unit 70 and stored in the customer information storage unit 18. The storage unit 16 may be connected to the network 24 and accessed from the application server 10 so that the application server 10 directly retrieves necessary information from the customer attribute storage unit 16. The contents of the data stored in the common attribute DB 34, the personal attribute DB 36, and the corporate attribute DB 38 will be described later, but the contents of these data vary at an arbitrary timing. As described above, the customer attribute storage unit 16 is a storage medium (first storage unit) for storing data updated at an arbitrary timing in an updatable state.

  The customer information storage unit 18 takes in customer asset information and customer attributes from the asset information storage unit 14 and the customer attribute storage unit 16, respectively, and applies existing customer information and makes it easy to extract as necessary information for each customer. It is a storage medium for storing information in the DB 40 and the customer card DB 42. The customer information storage unit 18 is connected to the network 24 and accessed from the application server 10. The data stored in the existing customer information management DB 40 and the customer card DB 42 are generated based on the data stored in the deposit DB 30, the asset DB 32, the common attribute DB 34, the personal attribute DB 36, and the corporate attribute DB 38. Therefore, the data in the customer information storage unit 18 is updated as appropriate, and the customer information storage unit 18 is also a storage medium for storing the updated data in an updateable state.

  The application information storage unit 20 is a storage medium for storing the application customer information DB 48, the application management DB 50, the application status management DB 52, the audit trail management DB 54, and the application document management DB 56. The application information storage unit 20 is accessed from the application server 10. The application customer information DB 48, the application management DB 50, the application status management DB 52, the audit trail management DB 54, and the application document management DB 56 store data during the period from application to approval. The data stored in the application customer information DB 48 is fixed in the period from application to approval of the document. In other words, no editing or correction is performed except in the case of deletion.

  Therefore, when the application is completed, data with the same content is stored in the customer information storage unit 18 and the application customer information DB 48. After that, even if the data content of the customer information storage unit 18 is changed, the application information storage unit 20 Are stored in a state where the contents cannot be changed (that is, fixed). In this way, by fixing and storing the customer information acquired at the time of application completion in the application customer information DB 48, it is possible to prevent editing prohibited data from being accidentally edited, and customer information at the time of application in the subsequent approval procedure. Can be referred to. On the other hand, the data stored in the application management DB 50, the application status management DB 52, the audit trail management DB 54, and the application document management DB 56 of the application information storage unit 20 can be edited. As described above, the application information storage unit 20 includes an application customer information DB 48 (first DB 44) in which fixed data is stored, an application management DB 50 in which updateable data is stored from application completion to approval completion, application The storage medium includes a situation management DB 52 and an audit trail management DB 54 (second DB 46).

  The approval information storage unit 22 is a storage medium for storing the application customer history information DB 58, the application history management DB 60, the application status history management DB 62, and the audit trail history management DB 64. The approval information storage unit 22 is connected to the network 24 and accessed from the application server 10. The application customer history information DB 58, the application history management DB 60, the application status history management DB 62, and the audit trail history management DB 64 store data regarding approved applications. The data stored in the application customer history information DB 58, the application history management DB 60, the application status history management DB 62, and the audit trail history management DB 64 are stored in a fixed state without being edited. Thus, it can be said that the approval information storage unit 22 is a storage medium for storing fixed data.

  In the approval information storage unit 22, the application customer history information DB 58 stores the customer information acquired and stored in the application customer information DB 48 when the application is completed, and is approved in the same manner as in the approval procedure. Even after completion, customer information acquired at the time of completion of application can be held and referenced. The data stored in the application history management DB 60, application status history management DB 62, and audit trail history management DB 64 is fixed when the contents of the data stored in the application management DB 50, application status management DB 52, and audit trail management DB 54 are completed. It is a thing. Therefore, during the approval procedure, the application management DB 50, the application status management DB 52, and the audit trail management DB 54 of the application information storage unit 20 are used to check the application content and the status of the application for approval. It is possible to check the application contents etc. by preventing the history etc. from being edited by mistake.

  FIG. 2 shows the configuration of the application server 10. The application server 10 includes a document registration unit 72, an application registration / reference unit 74, an approval registration unit 76, a business process registration unit 78, an application storage unit 80, an audit trail management unit 82, and an IF unit 84. The IF unit 84 is connected to the network 24 (not shown) and executes a communication function. The IF unit 84 communicates with the terminal device 12, the customer information storage unit 18, the application information storage unit 20, and the approval information storage unit 22 (not shown) via the network 24, and connects the customer information storage unit 18 and the customer information generation unit 70. The asset information storage unit 14 and the customer attribute storage unit 16 are accessed.

  The customer information generation unit 70 in FIG. 1 collects customer data necessary for creating a document before the applicant operates the terminal device 12 to create the document, and acquires customer attribute information, customer asset information, and the like for each customer. Create Although details will be described later, the customer information generation unit 70 acquires and processes customer asset information and customer attribute information based on data stored in the asset information storage unit 14 and the customer attribute storage unit 16. And stored in the customer information storage unit 18. As described above, since the data stored in the asset information storage unit 14 and the customer attribute storage unit 16 varies, the customer information generation unit 70 updates the data in accordance with the variation of these data. The customer information generation unit 70 is provided inside the application server 10, the asset information storage unit 14 and the customer attribute storage unit 16 are connected to the application server 10 via the network 24, and the application server 10 stores the asset information storage. Necessary information may be acquired from the unit 14 and the customer attribute storage unit 16.

  The document registration unit 72 registers the document format created by the document format creator by operating the terminal device 12 in the updated document management DB. Specifically, the document registration unit 72 registers the format information of the application document in the application document management DB 56 of the application information storage unit 20. When the application process is started, the application registration / inquiry unit 74 selects a document format corresponding to the type of application from among the application document formats created by the document registration unit 72 and registered in the application document management DB 56. While calling, necessary customer information is extracted according to the type of application from the data stored in the asset information storage unit 14 and the customer attribute storage unit 16 via the customer information storage unit 18, and an application screen is generated. When the applicant inputs an instruction (application instruction) to apply from the application screen, the application registration / inquiry unit 74 receives this instruction, and stores the asset information storage unit 14 and the customer attribute storage via the customer information storage unit 18. The customer information acquired from the unit 16 and displayed on the application screen is stored in the application customer information DB of the application information storage unit 20 in a fixed state. Further, the application registration / inquiry unit 74 stores information related to the application in the second DB 46.

  The approval registration unit 76 receives the result of the approval process performed by the approver according to the operation of the terminal device 12 by the approver after the application registration / inquiry unit 74 receives and registers the approval application instruction from the applicant. Register the contents. When the approval result is accepted and registered, the approval registration unit 76 stores the data stored in the application customer information DB 48 of the application information storage unit 20 fixedly stored in the approval information storage unit 22 in a non-updatable state. . The business process registration unit 78 registers the business process according to the application contents after the application registration / inquiry unit 74 receives and registers the application instruction. The paperwork is, for example, processing for actually opening a credit account when the content of the application is establishment of a credit account. Such paperwork is performed by an employee of a securities company different from the applicant or approver. During the paperwork, the data stored in the application customer information DB 48 of the application information storage unit 20 is referred to.

  The application storage unit 80 displays the approved content in accordance with an instruction from the terminal device 12 after the approval registration unit 76 registers the result of the approval process. At that time, the application storage unit 80 extracts the data stored in the approval information storage unit 22. After the approval registration unit 76 registers the result of the approval process, the audit trail management unit 82 displays a history from application to approval in accordance with an instruction from the terminal device 12. At that time, the audit trail management unit 82 extracts data stored in the audit trail management DB 54 or the audit trail history management DB 64.

  In the following description of each process, only necessary portions are illustrated in the configuration of the application processing unit 100 illustrated in FIG. 1 and the configuration of the application server 10 illustrated in FIG. This configuration can be realized in terms of hardware by a CPU, memory, or other LSI of any computer, and in terms of software, it can be realized by a program loaded in the memory, but here it is realized by their cooperation. Draw functional blocks. Accordingly, those skilled in the art will understand that these functional blocks can be realized in various forms by hardware only, software only, or a combination thereof.

2. Customer Information Generation Processing FIG. 3 shows the configuration of the customer information generation unit 70. The customer information generation unit 70 includes a first acquisition unit 90 and a second acquisition unit 92. The customer information generation unit 70 is connected to the asset information storage unit 14, the customer attribute storage unit 16, and the customer information storage unit 18. In order to connect to the asset information storage unit 14, the customer attribute storage unit 16, and the customer information storage unit 18, the network 24 in FIG. 1 and the IF unit 84 in FIG. 2 are used. These are omitted for the sake of clarity. As described above, the customer information generation unit 70 may be provided inside the application server 10, but the application server 10 is connected to the asset information storage unit 14 and the customer attribute storage unit 16 via the network at that time, The information in these storage units is taken out and necessary information is generated by the customer information generation unit 70.

  The deposit DB 30 stores deposit information held by the customer. The deposit DB 30 stores each deposit. FIG. 4 shows the data structure of the deposit DB 30. As shown, a user column 300, a department store column 302, an account number column 304, a product column 306, a brand column 308, a quantity column 310, an acquisition unit price column 312, and a market price column 314 are included. The deposit DB 30 stores stocks, bonds, investment trusts, etc., quantities, prices, etc. deposited from each user. The data stored in the deposit DB 30 is updated at the timing when the merchandise is bought and sold and when the market price changes. Returning to FIG.

  The asset DB 32 stores deposit assets held by customers. The asset DB 32 stores information for each account. FIG. 5 shows the data structure of the asset DB 32. As illustrated, a user column 320, a department store column 322, an account number column 324, and a total asset amount column 326 are included. The total asset amount included in the total asset amount column 326 is derived based on data stored in the deposit DB 30 and a stock price information DB (not shown). Therefore, when the data of the stock price information DB or the data stored in the deposit DB 30 is updated, the data stored in the asset DB 32, that is, the total asset amount is also updated. Generally, since the data in the stock price information DB is updated at a predetermined timing (for example, once a day), the data in the asset DB 32 is also updated accordingly. Further, the deposit DB 30 is updated at an arbitrary timing such as when stocks are sold, and the asset DB 32 is not only a predetermined update timing for the stock price information DB, but also data that is updated in accordance with an optional deposit DB update. Is configured to be updatable. Returning to FIG.

  The common attribute DB 34 stores attribute information common to individual customers and corporate customers. In the common attribute DB 34, each account is stored. FIG. 6 shows the data structure of the common attribute DB 34. As shown, the user field 330, the department store field 332, the account number field 334, the customer name field 336, the address field 338, the telephone number field 340, the occupation field 342, the risk explanation unnecessary (stock) field 344, the risk explanation unnecessary (bonds) ) Column 346, risk explanation unnecessary (convertible bond) column 348, risk explanation unnecessary (external certificate) column 350, compra rank column 352, and account opening date column 354. For example, the data stored in the common attribute DB 34 is updated at any irregular timing such as the timing when the address in the address column 338 is changed. Returning to FIG.

  The personal attribute DB 36 stores attribute information related to individual customers. The personal attribute DB 36 also stores information for each account. 7A to 7C show the data structure of the personal attribute DB 36. FIG. Since the number of items of data stored in the personal attribute DB 36 is large, it is divided into FIGS. 7A to 7C here, but is actually configured as one unit. As shown in the figure, a user column 360, a department store column 362, an account number column 364, a customer name column 366, a date of birth column 368, a gender column 370, an office column 372, a job title column 374, a transaction motivation column 376, and a fund personality column. 378, investment policy column 380, asset management period column 382, investment experience presence / absence (stock spot) column 384, investment experience presence / absence (bond) column 386, investment experience presence / absence (convertible bond) column 388, investment experience presence / absence (stock credit) column 390, investment experience (warrant) column 392, investment experience (future / OP) column 394, investment experience (savings investment trust) column 396, investment experience (investment trust) column 398, investment experience (foreign securities) A column 400, an investment experience presence / absence (others) column 402, a main income source column 404, an estimated annual income column 406, and a financial asset column 408 are included. Similarly to the data stored in the common attribute DB 34, the data stored in the personal attribute DB 36 is also updated at any irregular timing. Returning to FIG.

  The corporate attribute DB 38 stores attribute information related to corporate customers. The corporate attribute DB 38 also stores information for each account. 8A to 8B show the data structure of the corporate attribute DB 38. FIG. Since the number of items of data stored in the corporate attribute DB 38 is large, the data is divided into FIGS. 8A and 8B here, but is actually configured as one unit. As shown in the figure, a user column 410, a department store column 412, an account number column 414, a customer name column 416, a transaction motivation column 418, a funding personality column 420, an investment policy column 422, an asset management period column 424, presence / absence of investment (stock in stock) ) Column 426, investment experience (bond) column 428, investment experience (convertible bonds) column 430, investment experience (stock credit) column 432, investment experience (warrant) column 434, investment experience (futures / OP) Column 436, investment experience (savings investment trust) column 438, investment experience (investment trust) column 440, investment experience (foreign securities) column 442, investment experience (others) column 444, capital column 446, representative A name field 448 is included. Similarly to the data stored in the common attribute DB 34, the data stored in the corporate attribute DB 38 is also updated at an arbitrary irregular timing. Returning to FIG.

  Since the data for individual customers is different from the data for corporate customers, a personal attribute DB 36 and a corporate attribute DB 38 are provided separately. Note that the data stored in the personal attribute DB 36 and the data stored in the corporate attribute DB 38 are used at the time of application for approval and approval processing (approval / non-approval determination). In determining the approval application and the approval process, since the necessary information differs between the individual customer and the corporate customer, the personal attribute DB 36 and the corporate attribute DB 38 are provided separately.

  The 1st acquisition part 90 reads the data stored in deposit DB30 and asset DB32 with respect to each customer. The first capture unit 90 outputs the read data to the existing customer information management DB 40. The 2nd acquisition part 92 reads the data stored in common attribute DB34, personal attribute DB36, and corporate attribute DB38 with respect to each customer. The personal attribute DB 36 or the corporate attribute DB 38 is selected according to the type of customer attribute. The 1st acquisition part 90 outputs the read data to existing customer information management DB40 and customer card DB42.

  The existing customer information management DB 40 captures data from the first capture unit 90 and the second capture unit 92 for each customer, and stores part of the customer attribute information and customer asset information. Specifically, if the type of customer attribute information is an individual, the account opening date, address, occupation, date of birth, gender, phone number, place of work, title, assets under management, compliance rank, risk-free products Information is included. On the other hand, when the type of customer attribute information is a corporation, information on the date of opening an account, address, title / representative name, telephone number, type of business, capital, assets under management, compliance rank, and products that do not require a risk explanation are included. . That is, in the existing customer information management DB 40 in the customer information storage unit 18, a plurality of types, specifically, individuals and corporations are defined as types of customer attribute information.

  The customer card DB 42 stores data from the second capture unit 92 and stores customer attribute information for each customer. Specifically, information on investment experience, transaction types, financial characteristics, investment policy, asset management period, main sources of income, financial assets, and annual income are included. The items of data stored in the customer card DB 42 are the same regardless of the type of customer attribute information. The data stored in the existing customer information management DB 40 and the customer card DB 42 are updated in accordance with the update of the data stored in the asset information storage unit 14 and the customer attribute storage unit 16. For this reason, the data stored in the customer information storage unit 18 is configured to be updated at a predetermined or arbitrary timing.

3. Document Registration Processing FIG. 9 shows the configuration of the document registration unit 72. The document registration unit 72 includes a document generation unit 94. The document registration unit 72 is connected to the application information storage unit 20, the reception unit 96, and the display unit 98. The receiving unit 96 and the display unit 98 are included in the terminal device 12 of FIG. In order to be connected to the application information storage unit 20, the reception unit 96, and the display unit 98, the network 24 in FIG. 1 and the IF unit 84 in FIG. 2 are used. These are omitted.

  The reception unit 96 receives input from an applicant for approval application. Input is performed via an input device such as a keyboard or a mouse. The input here corresponds to the input of data for creating the format of the application document. The accepting unit 96 outputs the input data to the document generating unit 94. The document generation unit 94 receives data from the reception unit 96. The document generation unit 94 generates a format of a document (hereinafter referred to as “application document”) used for the approval application based on the received data. The document generation unit 94 causes the display unit 98 to display the format of the application document being created. The application document whose format is determined is stored in the application document management DB.

  The display unit 98 displays the format of the application document in response to an instruction from the document generation unit 94. FIG. 10 shows a registration screen for the format of the application document generated by the document generation unit 94. In the screen, the document code column 600 displays a document code assigned to identify the application document. The document classification field 602 displays the classification of application documents. In the document name column 604, the name of the application document is displayed. When a new application document is registered, the document code column 600, the document classification column 602, and the document name column 604 are newly input. Below these are the items included in the application. The registrant of the document format can edit the item contents. Therefore, a check box or the like displayed in the content portion on the right side can be arbitrarily set.

  FIG. 11 shows an application document approver definition screen generated by the document generation unit 94 for setting an approver. Application documents generally have different approvers depending on the type of document. Returning to FIG. The application document management DB 56 stores the format information of the application document created by the document generation unit 94. The application document format information stored in the application document management DB 56 includes approver information set and registered for each document.

4). Application Registration Processing FIG. 12 shows the configuration of the application registration / inquiry unit 74. The application registration / inquiry unit 74 includes an application processing unit 100 and an application status inquiry unit 102, and the application processing unit 100 includes an application screen generation unit 104, an acquisition unit 106, and a movement unit 108. The application registration / inquiry unit 74 is connected to the customer information storage unit 18, the application information storage unit 20, the reception unit 96, and the display unit 98. The receiving unit 96 and the display unit 98 are included in the terminal device 12 of FIG. In order to connect to the customer information storage unit 18, the application information storage unit 20, the reception unit 96, and the display unit 98, the network 24 in FIG. 1 or the IF unit 84 in FIG. 2 is used. These are omitted for the sake of clarity.

  The application screen generation unit 104 is an instruction received from the reception unit 96 and receives an instruction from the applicant. The application screen generation unit 104 creates a screen for creating an application document based on the instruction received by the reception unit 96, and executes the application process. FIG. 13 shows a document selection screen that is generated by the application screen generation unit 104 and in which the format of the application document is called from the application document management DB according to the type of application. The document code field 610, the document classification field 612, and the document name field 614 correspond to the document code field 600, the document classification field 602, and the document name field 604 in FIG. 10, and the reception unit 96 receives these fields from the applicant. By accepting the input to the account number or the account number associated with the customer, the application document format specified by the input to these fields or the customer specified by the account number is called up. In FIG. 13, by specifying an account number, candidates for a plurality of application document formats necessary for the application for approval related to the customer linked to the account number are displayed under the document code field 610, the document classification field 612, and the document name field 614. A plurality of displayed states are shown. In such a state where the format of the application document is shown, the applicant specifies a document necessary for the application, and inputs an instruction to start creating the application document by depressing the application input button 616. Returning to FIG. Upon receiving an application document creation start instruction, the application screen generation unit 104 acquires the format of the application document specified from the application document management DB 56. In addition, when the application screen generation unit 104 receives an application document creation start instruction, the application screen generation unit 104 notifies the acquisition unit 106 to that effect. At that time, information (for example, customer code) that identifies the customer that is input in the account number field and is uniquely associated with the account number is also notified to the acquisition unit 106.

  Upon receiving the application document creation start instruction from the application screen generation unit 104, the acquisition unit 106 receives the customer attribute information and asset information from the existing customer information management DB 40 and the customer card DB 42 included in the customer information storage unit 18. Get information. In order to acquire these, the acquisition part 106 performs the search by a customer code etc. Here, the customer information in the customer information storage unit 18 is stored in association with the customer code. Accordingly, since individual attribute information or corporate attribute information is acquired from one customer code, it can be said that the customer code received from the application screen generation unit 104 is information for specifying the type of customer.

  As described above, in the customer information storage unit 18 accessed by the acquisition unit 106, the contents of the existing customer information management DB 40 and the contents of the customer card DB 42 are updated at predetermined or arbitrary timing. The acquisition unit 106 is held in the customer information storage unit 18 at the time when the customer information storage unit 18 is accessed, that is, almost the same time as when the reception unit 96 receives an input of an application document creation instruction from the applicant. The customer attribute information and asset information are acquired, and the acquired customer asset information and customer attribute information are output to the application screen generation unit 104.

  The application screen generation unit 104 applies an approval application for securities business to the customer based on the customer asset information and customer attribute information acquired by the acquisition unit 106 in addition to the format information of the application document already acquired. Generate an application content edit screen. The application screen generation unit 104 causes the display unit 98 to display the created screen. The display unit 98 displays a screen in response to an instruction from the application screen generation unit 104. FIG. 14 shows an application content editing screen generated by the application screen generating unit 104. In particular, FIG. 14 shows an application content editing screen when the customer is an individual. In the first customer attribute display column 620 in the figure, customer attribute information acquired from the existing customer information management DB is displayed, and in the second customer attribute display column 622, customer attribute information acquired from the customer card DB 42 is displayed. In the deposit assets column 624 in the middle, customer asset information acquired from the customer card DB 42 is displayed. The application contents are displayed in the lower part of these customer information display fields 620, 622, and 624.

  FIG. 15 shows an application content inquiry screen generated by the application screen generation unit 104 in order to inquire the application content. The application content inquiry screen is generated when the accepting unit 96 accepts that the temporary save button is pressed on the application document creation screen of FIG. 14, and displays the application content displayed in the lower part of the customer information display field of FIG. It is a screen to do. FIG. 16 shows another application content editing screen generated by the application screen generating unit 104. In particular, FIG. 16 is an application content editing screen when the customer is a corporation. In the first customer attribute display column 630 in the figure, customer attribute information acquired from the existing customer information management DB 40 is displayed, and in the second customer attribute display column 632, customer attribute information acquired from the customer card DB 42 is displayed. In the deposit assets column 634, customer asset information acquired from the customer card DB 42 is displayed. The items included in the first customer attribute display column 630 are different from the items included in the first customer attribute display column 620 of FIG. This is because the types of customers are different. On the other hand, the items included in the second customer attribute display column 632 and the deposit asset column 634 are the same as the items included in the second customer attribute display column 622 and the deposit asset column 624 in FIG.

  FIG. 17 shows another application content inquiry screen generated by the application screen generation unit 104. This corresponds to a case where input of necessary items is completed and application is possible. Therefore, an application button 640 is displayed. Returning to FIG. In a state where the application content inquiry screen is displayed on the display unit 98, the application screen generation unit 104 inputs the instruction to start the application for approval by depressing the application button 640. Accept application start instructions. When receiving the application start instruction for the securities business, the application screen generation unit 104 instructs the moving unit 108 to store the data related to the application in the application information storage unit 20.

  When the moving unit 108 receives an instruction from the application screen generating unit 104, the moving unit 108 stores the data used for generating the application screen in the application information storage unit 20. That is, the data related to the application for which the creation of the application document is completed and the application start is instructed is stored in the application information storage unit 20. In particular, the moving unit 108 is in a state where the customer asset information and customer attribute information acquired from the existing customer information management DB 40 and customer card DB 42 cannot be edited in the application customer information DB 48 other than deletion (that is, fixed). Status). Further, the moving unit 108 stores data to be edited such as addition or correction in the application management DB 50, the application status management DB 52, and the audit trail management DB 54 from when the application start instruction is given until the approval is completed. The contents of data stored in the application management DB 50, the application status management DB 52, and the audit trail management DB 54 will be described later.

  As described above, the data stored in the application customer information DB 48 is fixed so that it cannot be edited, such as addition or change, unless it is deleted from application to approval. Therefore, the data stored in the existing customer information management DB 40 and the customer card DB 42 that can be updated and changed at various timings and frequencies is fixed by being stored in the application customer information DB 48 at the timing when the application start instruction is completed. Is done. On the other hand, the original data of the data fixed in the application customer information DB 48 by the application start instruction and stored in the existing customer information management DB 40 and the customer card DB 42 are stored in the application customer information DB 48. Can continue to fluctuate. On the other hand, the data stored in the application management DB 50, the application status management DB 52, and the audit trail management DB 54 can be edited during the period from application to approval.

  The application customer information DB 48 stores customer information at the timing when the preparation of the application document is completed and the application start instruction is completed. In the application customer information DB 48, one line of information is registered for each application. 18A to 18F show the data structure of the application customer information DB 48. FIG. Since the number of items of data stored in the application customer information DB 48 is large, the data is divided into FIGS. 18A to 18F here, but in actuality, they are configured as one unit. As shown, the user field 450, application number field 452, department store field 454, account number field 456, customer name field 458, postal code field 460, address field 462, occupation field 464, date of birth field 466, telephone number field. 468, account opening date column 470, gender column 472, asset column 474, compra rank column 476, title column 478, company column 480, representative name column 482, capital column 484, risk explanation unnecessary (stock) column 486, Risk explanation unnecessary (bonds) column 488, Risk explanation unnecessary (convertible bonds) column 490, Risk explanation unnecessary (external certificate) column 492, Transaction motivation column 494, Investment experience (stock in kind) column 496, Investment experience (bond) Column 498, investment experience presence / absence (convertible bonds) column 500, investment experience presence / absence (stock credit) column 502, investment experience presence / absence (warrant) column 504, investment experience presence / absence (future / OP) column 506, Investment experience (savings-type investment trust) column 508, Investment experience presence (investment trust) column 510, Investment experience presence (foreign securities) column 512, Investment experience presence (others) column 514, Funding property column 516, Investment policy column 518, A main income source column 520, an estimated annual income column 522, a financial asset column 524, and an asset management period column 526 are included. Each application is uniquely identified by the application number indicated in the application number column 452. Other items are similar to the items of data stored in the existing customer information management DB 40 and the customer card DB 42.

  The application management DB 50 stores data relating to application documents for which an instruction to start application has been completed. The application management DB 50 is composed of two parts. One is application management, and the other is application content management. Application management stores basic information (that is, attribute information) of application documents. In application management, one line of information is registered for each application. FIG. 19 shows the data structure of the application management DB 50. As shown, the user field 530, application number field 532, document code field 534, department store field 536, account number field 538, customer name field 540, applicant name field 542, application status field 544, application date and time field 546, application A completion date column 548 is included.

  On the other hand, the application content management stores the application content for each application. That is, the content stored in the application content management corresponds to the substantial content of the application document, and the application management corresponds to an index for identifying the application content management. Therefore, in the application content, information of one or more lines corresponding to the number of items in the application document is registered for each application. FIG. 20 shows another data structure of the application management DB 50. As illustrated, a user field 550, an application number field 552, an application content item number field 554, and a content field 556 are included. The data in the application management DB is updated at a timing such as when the application content changes.

  The application status management DB 52 stores the registration status of the applicant and the approver defined for each application. In the application status management DB 52, multiple lines of information are registered for each application. Multiple lines correspond to the sum of the number of approvers and the number of applicants for the document. The data in the application status DB is updated at the timing when the approval process is performed. FIG. 21 shows the data structure of the application status management DB 52. As shown, a user field 560, an application number field 562, a job title field 564, a registration status field 566, a registration date / time field 568, and a registrant name field 570 are included. In the registration status column 566, the current status is shown.

  The audit trail management DB 54 stores a history of updates to application documents. In the audit trail management DB 54, the updated number of information is stored for each application. The audit trail management DB 54 is also updated when updated. FIG. 22 shows the data structure of the audit trail management DB 54. As shown, a user field 580, an application number field 582, an update time field 584, an updater field 586, an update content field 588, and a job title field 590 are included. The update time column 584 shows the update time. Returning to FIG.

  The application status inquiry unit 102 receives the inquiry instruction from the inquirer, which is an instruction received from the reception unit 96 after the application start instruction is completed. The instruction is an application status inquiry request. When receiving the inquiry instruction, the application status inquiry unit 102 acquires data stored in the application status management DB 52. The application status inquiry unit 102 does not acquire data stored in the application management DB 50 and the audit trail management DB 54. That is, the application information storage unit 20 is configured by being divided into a plurality of parts according to the reference timing. The plurality of portions correspond to the application customer information DB 48, the application management DB 50, the application status management DB 52, and the audit trail management DB 54. Of these, data is stored in the application customer information DB in a fixed state and cannot be edited except for deletion, while the other DBs are configured so that data can be edited. The application status inquiry unit 102 generates an application status list screen based on the acquired data, and displays the generated screen on the display unit 98. FIG. 23 shows an application status list screen generated by the application status inquiry unit 102. As shown, the application status and approval status are displayed for each application. When a plurality of approvers are set, the approval status of each of the plurality of approvers is shown.

5. Approval Registration Processing FIG. 24 shows the configuration of the approval registration unit 76. The approval registration unit 76 includes an approval screen generation unit 110 and a movement unit 112. The approval registration unit 76 is connected to the application information storage unit 20, the approval information storage unit 22, the reception unit 96, and the display unit 98. The receiving unit 96 and the display unit 98 are included in the terminal device 12 of FIG. In order to connect to the application information storage unit 20, the approval information storage unit 22, the reception unit 96, and the display unit 98, the network 24 in FIG. 1 or the IF unit 84 in FIG. These are omitted for the sake of clarity.

  The approval screen generation unit 110 is an instruction received from the reception unit 96 and receives an approval application display instruction from the approver. The instruction is a request for displaying an approval application, and in this example, an approval application item is displayed with approval status information. Therefore, the approval application display request is similar to the above-described application status inquiry request. In the application status inquiry request, the application status and the approval status are displayed on the display unit 98 for each application, whereas in the approval application display request, the approval status is displayed on the display unit 98 for each application. Upon receiving the approval application display instruction, the approval screen generation unit 110 acquires data stored in the application status management DB 52. The approval screen generation unit 110 generates an approval application display screen based on the acquired data, and displays the generated screen on the display unit 98. FIG. 25 shows an approval application display screen generated by the approval screen generation unit 110. As shown, the approval status is displayed for each application. That the approval status is “waiting for approval” corresponds to a status that should be approved or not approved. On the other hand, that the approval status is “unapproved” corresponds to a status that other approvers should approve or not approve. Furthermore, that the approval status is “approved” corresponds to the already approved status. The approval status “non-approved” corresponds to a status of non-approval by any approver. Returning to FIG.

  In the state where the approval application display screen is displayed on the display unit 98, when the approver specifies and pushes down the application number, the approval screen generation unit 110 receives the application document corresponding to the specified application number from the reception unit 96. Accept display instructions. In response to the received instruction, the approval screen generation unit 110 acquires customer information of the corresponding customer from the application customer information DB 48, and acquires attribute information and application content information about the application from the application management DB 50. The approval screen generation unit 110 creates an approval content inquiry screen based on the acquired data, and causes the display unit 98 to display the created approval content inquiry screen.

  FIG. 26 shows an approval content inquiry screen generated by the approval screen generation unit 110. As shown, the same contents as the application document are displayed. The approver confirms the content of the approval content inquiry screen and, when approving, clicks the approval button 650 with the mouse. On the other hand, the approver clicks the non-approval button 652 with a mouse when not approving. When the approver entry button is clicked, the approval screen generation unit 110 causes the display unit 98 to display the approver entry field edit screen. FIG. 27 shows an approver entry column edit screen generated by the approval screen generation unit 110. Items shown in the content part are defined according to customer attributes. Returning to FIG.

  When an approval / non-approval instruction by the approver is input, the approval screen generation unit 110 receives an instruction to complete the approval process by the approver from the reception unit 96. This is an instruction to complete the approval process for the application start instruction. Upon receiving the approval process completion instruction, the approval screen generation unit 110 instructs the moving unit 112 to store the approval target data in an unupdatable state. When a plurality of approvers are set, the approval screen generation unit 110 instructs the moving unit 112 to record data when the last approver instructs completion of the approval process. When the approver remains, the approval screen generation unit 110 updates the data in the application status management DB 52 and the audit trail management DB 54.

  When the moving unit 112 receives an instruction from the approval screen generating unit 110, the moving unit 112 stores the data stored in the application customer information DB 48 in the application customer history information DB 58 in an unupdatable state. As described above, the data here corresponds to customer asset information, customer attribute information, and the like. Further, the moving unit 112 stores the data stored in the application management DB 50, the application status management DB 52, and the audit trail management DB 54 in an unupdateable state in the application history management DB 60, the application status history management DB 62, and the audit trail history management DB 64, respectively. Let These data are application data associated with the data stored in the application customer information DB 48, and the data whose contents can be updated between the application start instruction and the approval completion instruction are used as the original data.

  On the other hand, the application information stored in the application history management DB 60, the application status history management DB 62, and the audit trail history management DB 64 cannot be updated. Since the application customer history information DB 58, the application history management DB 60, the application status history management DB 62, and the audit trail history management DB 64 are stored in the approval information storage unit 22, the approval information storage unit 22 stores data after approval. . The data structures in the application customer history information DB 58, the application history management DB 60, the application status history management DB 62, and the audit trail history management DB 64 are the same as those in the application customer information DB 48, the application management DB 50, the application status management DB 52, and the audit trail management DB 54. Since the data structures are the same as each other, description thereof is omitted here.

6). Business Process Registration Process FIG. 28 shows the configuration of the business process registration unit 78. The business process registration unit 78 is connected to the application information storage unit 20, the reception unit 96, and the display unit 98. The receiving unit 96 and the display unit 98 are included in the terminal device 12 of FIG. In order to be connected to the application information storage unit 20, the reception unit 96, and the display unit 98, the network 24 in FIG. 1 and the IF unit 84 in FIG. 2 are used. These are omitted.

  The business process registration unit 78 receives an instruction received from the reception unit 96 and an instruction from an employee of the securities company. The instruction is an inquiry request for the status of paperwork. Upon receiving the instruction, the business process registration unit 78 acquires data stored in the application management DB 50, the application status management DB 52, and the audit trail management DB 54.

  The business process registration unit 78 generates a business process status list screen based on the acquired data, and displays the generated screen on the display unit 98. FIG. 29 shows a business process status list screen generated by the business process registration unit 78. As shown in the figure, the processing status is displayed for each application. That the processing status is “waiting for processing” corresponds to a status in which paperwork is to be executed. On the other hand, that the processing status is “unprocessed” corresponds to a situation where other employees should execute the paperwork. Furthermore, the fact that the processing status is “processed” corresponds to a status that has already been processed.

7). Application Storage Processing FIG. 30 shows the configuration of the application storage unit 80. The application storage unit 80 is connected to the approval information storage unit 22, the reception unit 96, and the display unit 98. The receiving unit 96 and the display unit 98 are included in the terminal device 12 of FIG. In order to connect to the approval information storage unit 22, the receiving unit 96, and the display unit 98, the network 24 in FIG. 1 or the IF unit 84 in FIG. 2 is used. These are omitted.

  The application storage unit 80 receives an instruction received from the reception unit 96 and an instruction from an employee of the securities company. The instruction is an inquiry request for application documents that have been approved. When receiving the instruction, the application storage unit 80 acquires data stored in the application status history management DB 62. The application storage unit 80 generates a screen for displaying the application stored based on the acquired data, and outputs the generated screen to the display unit 98. FIG. 31 shows a storage application display screen generated by the application storage unit 80. As shown in the figure, the approval status is confirmed. When the application number is selected, the application storage unit 80 may acquire data stored in the application customer history information DB 58 and the application history management DB 60 and display the approved application document on the display unit 98. .

8). Audit Trail Management Processing FIG. 32 shows the configuration of the audit trail management unit 82. The audit trail management unit 82 is connected to the application information storage unit 20, the approval information storage unit 22, the reception unit 96, and the display unit 98. The receiving unit 96 and the display unit 98 are included in the terminal device 12 of FIG. In order to connect to the application information storage unit 20, the approval information storage unit 22, the reception unit 96, and the display unit 98, the network 24 in FIG. 1 or the IF unit 84 in FIG. These are omitted for the sake of clarity.

  The audit trail management unit 82 receives an instruction received from the reception unit 96 and an instruction from an employee of the securities company. The instruction is an audit trail inquiry request for application documents. Here, if the application document to be inquired has been approved in some cases, the approval may not have been completed. The audit trail management unit 82 accepts the application number as well as the instruction, and identifies the one storing the data corresponding to the application number by referring to the audit trail management DB 54 and the audit trail history management DB 64. The fact that the data corresponding to the application number is included in the audit trail management DB 54 is equivalent to inquiring an audit trail for application documents for which approval has not been completed.

  On the other hand, the fact that the data corresponding to the application number is included in the audit trail history management DB 64 corresponds to inquiring the audit trail for the application document for which the approval has been completed. When the data corresponding to the application number is included in the audit trail management DB 54, the audit trail management unit 82 acquires the data stored in the audit trail management DB 54. On the other hand, when the data corresponding to the application number is included in the audit trail history management DB 64, the audit trail management unit 82 acquires the data stored in the audit trail history management DB 64. The audit trail management unit 82 generates an application update history inquiry screen based on the acquired data, and outputs the generated screen to the display unit 98.

  Here, among the second DBs 46 stored in the application information storage unit 20, only the audit trail management DB 54 is used, and the application management DB 50 and the application status management DB 52 are not used. Of the application history management DB 60, the application status history management DB 62, and the audit trail history management DB 64 stored in the approval information storage unit 22, only the audit trail history management DB 64 is used, and the rest is not used. That is, the part used by the audit trail management unit 82 is a corresponding part of the application information storage unit 20 and the approval information storage unit 22. Therefore, the approval information storage unit 22 is divided into a plurality of parts, such as an application history management DB 60, an application status history management DB 62, and an audit trail history management DB 64. Such division is matched with the configuration in the second DB 46. FIG. 33 shows an application update history inquiry screen generated by the audit trail management unit 82. As shown in the figure, a display is provided so that it is possible to confirm who performed what and when.

9. Operation The operation of the securities business system 200 configured as described above will be described. FIG. 34 is a sequence diagram showing the procedure of application processing by the securities business system 200. The first terminal device 12a transmits a start instruction from the applicant to the application server 10 (S10). The application server 10 acquires data from the customer information storage unit 18 (S12). The application server 10 generates an application screen (S14). The application server 10 transmits a display instruction for the generated application screen to the first terminal device 12a (S16). The first terminal device 12a displays an application screen (S18). The first terminal apparatus 12a outputs an application start instruction from the applicant to the application server 10 (S20). The application server 10 acquires the generated application screen and transmits the input data to the application information storage unit 20 (S22). The application information storage unit 20 stores data (S24).

  FIG. 35 is a sequence diagram showing the procedure of the approval process by the securities business system 200. The application server 10 acquires data from the application information storage unit 20 (S30). The application server 10 generates an approval screen (S32). The application server 10 transmits a display instruction for the generated approval screen to the second terminal device 12b (S34). The second terminal device 12b displays an approval screen (S36). The second terminal device 12b outputs an approval instruction from the approver to the application server 10 (S38). The application server 10 transmits a data movement instruction to the application information storage unit 20 (S40), and the application information storage unit 20 transmits the data to the approval information storage unit 22 (S42). The approval information storage unit 22 stores data (S44).

  According to the embodiment of the present invention, whether the customer is an individual or a corporation even if the attribute information necessary for the compliance check and other approvals differs depending on whether the customer is an individual or a corporation. Accordingly, attribute information is stored separately, so that attribute information can be stored efficiently. In addition, attribute information is acquired and displayed separately depending on whether the customer is an individual or a corporation, so that information necessary for approval determination can be accurately referred to according to the type of customer. In addition, since asset information, attribute information, and the like that fluctuate are stored in the customer information storage unit in advance, customer information necessary for application can be quickly acquired. In addition, when an application instruction is received, the updatable information stored in the customer information storage unit is stored as fixed information in the application information storage unit, so the information necessary for approving the application varies. Can be prevented. Further, it is possible to reduce a risk that information to be fixed is erroneously updated.

  Moreover, since the structure of a memory | storage part is divided according to the property of information, a process can be performed efficiently. In addition, since the customer type corresponding to the start instruction corresponds to the attribute information type, it is possible to acquire attribute information suitable for the received customer type. Moreover, attribute information suitable for the type of customer received is acquired, so that attribute information necessary for approval determination can be accurately acquired. In addition, since the attribute information necessary for the approval determination is accurately acquired, it is possible to realize an accurate process of approval.

  In addition, when the approval instruction is received, the updatable information stored in the application information storage unit is stored in the approval information storage unit as non-updatable information. Can reduce the risk. In addition, since the risk of erroneously updating information that cannot be updated is reduced, information of different properties can be reliably processed. Further, since the second DB is divided into a plurality of parts according to the reference timing, only the necessary information can be accessed. In addition, since only necessary information is accessed, processing efficiency can be improved.

  In the above, this invention was demonstrated based on the Example. This embodiment is an exemplification, and it will be understood by those skilled in the art that various modifications can be made to the combination of each component and each processing process, and such modifications are also within the scope of the present invention. .

  DESCRIPTION OF SYMBOLS 10 Application server, 12 Terminal device, 14 Asset information storage part, 16 Customer attribute storage part, 18 Customer information storage part, 20 Application information storage part, 22 Approval information storage part, 24 Network, 30 Deposit DB, 32 Asset DB, 34 Common attribute DB, 36 Personal attribute DB, 38 Corporate attribute DB, 40 Existing customer information management DB, 42 Customer card DB, 44 1st DB, 46 2nd DB, 48 Application customer information DB, 50 Application management DB, 52 Application status management DB , 54 Audit trail management DB, 56 Application document management DB, 58 Application customer history information DB, 60 Application history management DB, 62 Application status history management DB, 64 Audit trail history management DB, 72 Document registration section, 74 Application registration / inquiry Department, 76 approval registration department, 78 paperwork registration department, 8 Application storage section, 82 Audit trail management section, 84 IF section, 90 First capture section, 92 Second capture section, 94 Document generation section, 96 Reception section, 98 Display section, 100 Application processing section, 102 Application status inquiry Department, 104 application screen generation section, 106 acquisition section, 108 movement section, 110 approval screen generation section, 112 movement section, 200 securities business system.

Claims (5)

A first reception unit for receiving an instruction to start an approval application for securities business from an applicant;
When the first receiving unit accepts the start instruction, the customer asset information and the customer attribute information are updated and stored at an arbitrary timing independently of the application device from the customer storage unit. And an acquisition unit for acquiring customer attribute information,
Based on the customer asset information and customer attribute information acquired in the acquisition unit, a generation unit that generates an approval application screen for securities business,
A display unit for displaying an application screen generated in the generation unit;
In a state where the display unit displays the application screen, a second reception unit that receives an application instruction to apply for approval of securities business from the applicant;
When the second receiving unit accepts the application instruction, the moving unit that fixes the customer asset information and the customer attribute information used by the generating unit to generate the application screen and stores them in the second storage unit;
A third reception unit for receiving an approval instruction from an approver for an application instruction received in the second reception unit;
The second storage unit executes writing of customer asset information and customer attribute information by receiving an application instruction in the second reception unit,
When the third receiving unit receives the approval instruction, the moving unit is in a state in which the customer asset information and the customer attribute information stored in the second storage unit cannot be updated, separately from the second storage unit. An application device characterized by being stored in a third storage unit provided. The second storage unit includes a first DB for storing information stored with fixed contents, and a second DB for storing information capable of editing the contents,
When the second receiving unit receives the application instruction, the moving unit fixes and stores the customer asset information and the customer attribute information used by the generating unit to generate the application screen in the first DB. When the third reception unit receives the approval instruction, the customer asset information and customer attribute information stored in the first DB are stored in the third storage unit in an unupdatable state, and the application instruction is received. 2. The application apparatus according to claim 1, wherein application information generated between the time point and the time point when the approval instruction is received and stored in the second DB is also stored in the third storage unit in a non-updatable state. . Application information stored in the second storage unit accessed by the moving unit is divided into a plurality of parts,
The application information stored in the third storage unit accessed by the moving unit is configured to be divided into a plurality of parts in accordance with the application information stored in the second storage unit. Item 3. The application device according to item 2. Receiving an instruction to start an application related to securities business from the applicant;
When the start instruction is received, the customer asset information and the customer attribute information are obtained from the first storage unit that updates and stores the customer asset information and the customer attribute information at an arbitrary timing independently of the application device. A step to obtain,
Generating an application screen related to securities business based on the acquired customer asset information and customer attribute information;
Displaying the generated application screen,
In the state where the application screen is displayed, a step of receiving an application instruction from the applicant to apply for approval of securities business;
Receiving the application instruction, fixing the customer asset information and customer attribute information used to generate the application screen and storing them in the second storage unit;
A step of receiving an approval instruction from the approver for the received application instruction;
When the approval instruction is received, the customer asset information and the customer attribute information stored in the second storage unit are stored in a third storage unit provided separately from the second storage unit in a non-updatable state. And
The application method, wherein the second storage unit in the step of storing in the second storage unit executes writing of the customer asset information and the customer attribute information by receiving an application instruction. Receiving an instruction to start an application related to securities business from the applicant;
When the start instruction is received, the customer asset information and the customer attribute information are obtained from the first storage unit that updates and stores the customer asset information and the customer attribute information at an arbitrary timing independently of the application device. A step to obtain,
Generating an application screen related to securities business based on the acquired customer asset information and customer attribute information;
Displaying the generated application screen,
In the state where the application screen is displayed, a step of receiving an application instruction from the applicant to apply for approval of securities business;
Receiving the application instruction, fixing the customer asset information and customer attribute information used to generate the application screen and storing them in the second storage unit;
A step of receiving an approval instruction from the approver for the received application instruction;
When the approval instruction is received, the customer asset information and the customer attribute information stored in the second storage unit are stored in a third storage unit provided separately from the second storage unit in a non-updatable state. And
The second storage unit in the step of storing in the second storage unit is a computer program for causing a computer to execute writing of customer asset information and customer attribute information by receiving an application instruction.

Images