JP6055050B1 - Bank system, method and program executed by bank system - Google Patents

Abstract

Provided is a bank system for executing correction processing and reimbursement processing at the time of bank transfer failure. A bank system receives a first message from a destination bank system, and identifies and identifies a transfer requester by searching for a transfer message based on the transfer identification information included in the first message. It is determined whether the transfer requester can execute the payment proxy function, and when it is determined that the payment proxy function can be executed, the first is based on the transfer content included in the first message. Identifying one or more entities associated with the telegram, communicating to the identified one or more entities a notification indicating that the first telegram has been received and the first telegram, and identifying the one or more The second message is generated based on the input by the entity, the approval request for the second message is made to a predetermined approver, and the second message that has been approved by all the approvers is served. To send to the banking system. [Selection] Figure 7

Description

  The present invention relates to a bank system, a method executed by the bank system, and a program. More specifically, the present invention is a bank system for executing correction processing and reorganization processing that is performed when a transfer from a destination bank to a destination bank is unsuccessful, and provides a cash management service (CMS). The present invention relates to a bank system used by a destination bank, a method and a program executed by the bank system.

  In settlements in general commercial transactions, the debtor (transfer client) passes the billing bank to the bank through the bank in response to the claim made by the creditor to the debtor. This is done by making a transfer to a certain creditor (transfer) account. Usually, the bank of the borrower (transfer client) often exists at the destination bank.

  In the case of a transfer failure, it is known that correction processing and / or reorganization processing is performed between the destination bank and the destination bank. The correction process is a process of generating a transfer data after correction that eliminates the reason for the transfer failure (for example, account name difference, account number difference, etc.) that has become a transfer failure and performs transfer again. The restructuring process is a process of stopping the transfer to the creditor account and returning the funds to the debtor account when the transfer is not successful.

  In the correction process and the recombination process, first, an inquiry message is transmitted from the destination bank to the destination bank. The inquiry message includes the reference number, information identifying the transfer (transmission number), transfer details (transfer account, transfer amount, transfer person name, transfer date, etc.) and reason for non-transfer (account name difference, account number difference, no account, Etc.). The destination bank notifies the transfer requester of the details of the transfer that was unsuccessful, along with the reason for the inability to transfer, and then the destination bank receives the corrected transfer information from the transfer requester and responds based on the corrected transfer information. A message can be sent to the destination bank (correction processing), or the funds are returned from the destination bank without completing the transfer based on the instructions of the transfer client, and the funds are transferred to the account of the transfer client The processing can be terminated (combination processing). A system that automatically performs such a series of processes has been known (Patent Document 1).

  In recent years, corporate groups that have consolidated subsidiaries use a cash management service (CMS) system to concentrate the financial functions (fund management / procurement) and cash management functions of the entire group at the headquarters to improve fund efficiency and operations More and more companies are trying to streamline. An exemplary CMS system can provide functions as shown in Table 1.

  In a corporate group that has introduced a CMS system, when a group company that is a debtor makes a transfer to a creditor, a payment agency is often performed in which the supervising company makes a transfer in place of the group company. In the payment agency, the actual transfer requester becomes the controlling company, and the controlling company requests the destination bank to transfer to the creditor account of the destination bank. The CMS system can hold transfer request data indicating which group company requested for each transfer. In such a case, if the bank is unsuccessful, the destination bank notifies the controlling company of the details of the unsuccessful transfer along with the reason for the inability to transfer. At the headquarters, the person in charge referred to the transfer request data held in the CMS system, identified the group company that seems to be involved from the transfer details, and the group company person in charge was unsuccessful. Inquire about whether to create correction transfer information for the transfer and transfer again, or to perform reorganization. When making a transfer again, the person in charge at the controlling company generates correction transfer information based on the correction information received from the group company and sends it to the destination bank. The destination bank creates a response message based on the correction transfer information. To the destination bank. On the other hand, in the case of restructuring, the person in charge at the controlling company tells the destination bank that it will return the funds by completing this process without completing the transfer, and have the funds deposited into the controlling company account. . Since the transfer request data requested by the controlling company itself is also stored in the CMS system, the above flow can be applied even when the controlling company itself becomes the requester.

  When identifying the group company, the person in charge of the controlling company can refer to the transfer request data in the CMS system and identify one or more group companies that may be involved in the transfer. Above, the person in charge of the controlling company individually inquired the person in charge of one or a plurality of group companies when the transfer failed.

JP 2010-191923 A (Patent No. 5428059)

  In the event of a bank transfer failure when using the CMS system, the destination bank sends data related to the bank transfer failure by means such as fax or e-mail to the supervising company that is the apparent client. Was. The person in charge of the headquarters company refers to the data in the CMS system, identifies which group company the data related to the transfer that has failed to transfer, and the person in charge of the headquarters company individually contacts the group company. And sent correct bank transfer information or restructuring instructions to the destination bank.

  However, in the conventional method, when the scale of the corporate group that employs CMS is large and the number of transfers is enormous, it is necessary to know which group company is the transfer that failed. It was cumbersome and took a lot of time, and the work was extremely difficult.

  The group company that created the transfer request data must also contact the person in charge at the controlling company after creating correction transfer information or restructuring instructions. Has to be requested, and the work is complicated and time-consuming.

  The present invention has been made in view of such a problem, and is a bank system for executing correction processing and recombination processing performed at the time of a transfer failure from a destination bank to a destination bank, and provides a CMS. The aim is to provide a banking system used by the destination bank.

In order to solve the above-described problem, a bank system according to an aspect of the present invention is a first message receiving unit that receives a first message from a destination bank system, and the first message is a transfer Based on the first message receiving means, which is an inquiry message transmitted from the destination bank system to the bank system in order to make an inquiry to the destination bank at the time of processing failure, and the transfer identification information included in the first message First extraction means for identifying a transfer requester by searching for a transfer message and determining whether the identified transfer requester can execute the payment agent function by referring to the CMS contract category of the customer master And the identified transfer requester is associated with the first message based on the transfer contents included in the first message when it is determined that the payment proxy function can be executed. A second extracting unit for identifying one or a plurality of entities, wherein the transfer message is based on a transfer detail data created by the one or a plurality of entities; Alternatively, a notification indicating that the first electronic message has been received and a notification means for communicating the first electronic message to a plurality of entities, wherein the non-transferable details associated with the first electronic message include the transfer detail data And generating means for generating a second telegram based on an input by the identified one or more entities , wherein the second telegram is included in the first telegram a reply message for transfer malfunction reason that, generating means and, for a predetermined approvers, approval request transmitting means for performing approval request for said second message , And a second message transmitting means for transmitting the second message that is approved by all completed the approver to the receiving bank system.

Further, according to one aspect of the present invention, the method executed by the banking system at the destination bank is to receive the first telegram from the destination bank system, and the first telegram is received when the transfer process is not successful. The inquiry message is sent from the destination bank system to the bank system to make an inquiry to the destination bank , and the transfer message is searched by searching for the transfer message based on the transfer identification information included in the first message. By identifying the requester and referring to the CMS contract category in the customer master, it is determined whether the identified transfer requester can execute the payment proxy function, and the identified transfer requester performs the payment proxy function. When it is determined that execution is possible, one or more entries associated with the first message are based on the transfer contents included in the first message. The transfer message is based on transfer statement data created by the one or more entities, and the first message is sent to the identified one or more entities. Communicating the notification indicating that it has been received and the first telegram, wherein the non-transferable details associated with the first telegram are associated with the transfer detail data and the identified It is predetermined that the second message is generated based on an input by one or a plurality of entities , and the second message is a response message for the reason for the transfer failure included in the first message. Requesting the approved approver for the second message, and sending the second message that has been approved by all of the approver to the target silver And a transmitting system.

  ADVANTAGE OF THE INVENTION According to this invention, the correction process at the time of payment substitution in a company group which has introduce | transduced the CMS system, and a reorganization process can be performed efficiently. More specifically, by sending the inquiry message received from the bank to be sent from the bank system to the CMS system, it is possible to directly notify the company that requested the transfer without making a conventional notification to the controlling company. The company that received the notification will be able to enter correction transfer information or reimbursement instructions on the screen, so that correction processing and reorganization processing at the time of payment agent can be performed efficiently. .

A detailed understanding of the embodiments disclosed herein can be obtained from the following description, illustrated with reference to the accompanying drawings.
It is a schematic diagram of the whole system containing the bank system and CMS system concerning the present invention. It is a system configuration figure of the bank system concerning the present invention. It is a functional block diagram of the bank system concerning the present invention. It is a functional block diagram of the CMS system concerning the present invention. It is a processing flow figure of the transfer detailed data in a CMS system. It is a processing flow figure at the time of inquiry message reception performed with a bank system. It is a flowchart explaining the reply message production | generation process performed with the CMS system which concerns on this invention. It is a figure showing an example of transfer details data. It is an example of the screen which displays a transfer impossible details list | wrist. It is an example of a screen used when creating an answer to the inquiry message. It is an example of a screen for performing the approval act with respect to the created reply message. It is a figure explaining the example of the inquiry message | telegram transmitted to a destination bank from a destination bank. It is a figure explaining an example of the data structure of a customer master. It is a figure explaining an example of the data structure of a transaction statement file. It is a figure which shows an example of the data structure of a person in charge DB.

  Hereinafter, embodiments of the present invention will be described in detail. In the embodiments to be described, an embodiment in which the payment agent function of the CMS system is used will be described. For this reason, in the embodiment to be described, the case where the transfer requester is a group company in a group company will be mainly described, but it should be understood that the transfer requester may be a supervising company. Further, it should be understood that the present invention can be applied to a bank system that provides a payment agent function even if the CMS system itself is not introduced.

  FIG. 1 is a schematic diagram of the entire system including a bank system 100 and a CMS system 110 according to the present invention. In FIG. 1, the bank system 100 is shown to include a CMS system 110, but in other embodiments, the CMS system 110 may be configured to be external to the bank system 100, or CMS. The bank system 100 itself may be configured to provide the functions provided by the system 110.

  The bank system 100 and the CMS system 110 are connected to the managing company terminal 130a and the group company terminal 130b via the first network 120. The first network 120 may be any known network that can communicate with each other, including a dedicated line, the Internet, and the like, and is not particularly limited. The management company terminal 130a is a terminal used by a management company in a group company, and the group company terminal 130b is a terminal used by a group company (that is, a non-controlling company) in the group company.

  The supervising company is a company that transfers funds to creditors of the group company in response to a request from the non-supervising group company in a corporate group that performs payment agency. The actual transfer requester becomes the controlling company, and the controlling company requests the destination bank to transfer to the creditor account of the destination bank. The head office terminal 130a and the group company terminal 130b are terminals that can access the CMS system 110 and use one or more functions (for example, the functions shown in Table 1) provided by the CMS system 110. It may be any type of device such as a personal computer (PC), laptop, personal digital assistant, user equipment (UE), smart phone, etc. operable in a wired and / or wireless environment.

  The bank system 100 is connected to the destination bank system 140 via the second network 150. The second network 150 may be an inter-bank network system (so-called “zengin net”), but may be another network that performs a similar function. As is well known to those skilled in the art, a bank that sends funds during transfer processing is called a “destination bank”, and a bank that receives funds is called a “destination bank”.

  Consider a case where transfer data is transmitted from the bank system 100 in FIG. 1 to the destination bank system 140 via the second network, resulting in a transfer failure.

  In such a case, first, an inquiry message is transmitted from the destination bank system 140 to the bank system 100. The inquiry message contains the reference number, information identifying the transfer (transmission number), transfer details (transfer source account, transfer destination account, transfer amount, transfer person name, transfer date, etc.) and reason for non-transfer (account name difference, account number) Difference, no account, etc.). FIG. 12 is a diagram for explaining an example of the inquiry message 1200 transmitted from the destination bank to the destination bank. In the inquiry message 1200 of FIG. 12, the name of the bank branch (XXXX Bank Toranomon Branch), the name of the bank branch (YYYY Bank Kobe Sales Department), the exchange item (communication inquiry), the reason for the bank transfer failure (transfer account number difference), transfer The contents (transfer account, transfer amount, transfer person name, transfer date), transmission number (identification number assigned by the destination bank: M001) and reference number (S200) are illustrated.

  In response to receiving the inquiry message 1200, the bank system 100 of the destination bank can transmit the data of the unsuccessfully completed transfer to the transfer requester together with the reason why the transfer is impossible. At the time of data transmission, the bank system 100 can transmit the inquiry message 1200 itself, or can generate and transmit a notification message representing the contents of the inquiry message 1200. Thereafter, the bank system 100 of the destination bank can receive the correction transfer information input by the supervising company terminal 130a or the group company terminal 130b, generate a reply message, and send it to the destination bank (correction processing). Alternatively, it is possible to have the funds returned from the destination bank without completing the transfer based on the transfer request from the transfer requester, and the processing can be terminated (reset processing). As another embodiment, the reply message itself is created in the CMS system 110 based on the reorganization instruction input by the supervising company terminal 130a or the group company terminal 130b and transmitted to the bank system 100 of the destination bank. May check the received reply message and then send the reply message to the destination bank system 140.

  FIG. 2 is a system configuration diagram of the bank system 100 according to the present invention. As shown in FIG. 2, the bank system 100 includes a control unit 201, a main storage unit 202, an auxiliary storage unit 203, an interface (IF) unit 204, and the like connected to each other by a bus 210 or the like, like a general computer. An output unit 205 can be provided. The bank system 100 can also include a customer master 206 and a billing system DB 207.

  The control unit 201 is also called a central processing unit (CPU), controls each component in the bank system 100 and calculates data, and stores various programs stored in the auxiliary storage unit 203 into the main storage unit 202. Can be read and executed. The main storage unit 202 is also called a main memory, and can store various received data, computer-executable instructions, data after arithmetic processing by the instructions, and the like. The auxiliary storage unit 203 is a storage device typified by a hard disk (HDD) and is used when data and programs are stored for a long period of time.

  In the embodiment of FIG. 2, the embodiment in which the control unit 201, the main storage unit 202, and the auxiliary storage unit 203 are provided in the same server computer has been described. However, as another embodiment, the bank system 100 includes the control unit 201, By using a plurality of main storage units 202 and auxiliary storage units 203, parallel distributed processing by a plurality of server computers can be realized. As another embodiment, a plurality of servers for the bank system 100 may be installed, and a plurality of servers may share one auxiliary storage unit 203.

  The IF unit 204 serves as an interface for transmitting and receiving data to and from other systems and devices, and provides an interface for receiving various commands and input data (such as various masters and tables) from the system operator. Can do. The output unit 205 can provide a display screen for displaying the processed data, a printing unit for printing the data, and the like.

  The customer master 206 can store master information of a customer who has opened an account in a bank (destination bank) having the bank system 100. FIG. 13 is a diagram for explaining an example of the data structure of the customer master 206. The customer master 206 may include a customer ID 1301, account information 1302, attribute information 1303, and CMS contract category 1304, but is not limited to these data items, and may include other data items.

  The customer ID 1301 is an identifier for identifying a customer who has opened an account with a bank. The account information 1302 is customer account information, and may include information such as a transaction branch (store number), a subject (for example, a savings account, a current account, etc.), and an account number. The attribute information 1303 can include information such as a customer's name, name, address, and contact information. The CMS contract category 1304 indicates whether or not the customer has entered into a contract for using the CMS system 110, and the customer who has entered into the contract can be regarded as performing a management company in the group company. For this reason, a customer indicating that the CMS contract classification 1304 has concluded a CMS contract can make a transfer as a transfer requester on behalf of the group company.

  The account system DB 207 is a generic name for storing database files used in a system that controls connection with a deposit account ledger, exchange, ATM (Automated Teller Machine) network, and external system, and is exemplified in FIG. A transaction statement file 1400 can be included. The transaction details file 1400 is a file that can store transaction details in various accounts such as a customer's savings account and a checking account.

  FIG. 14 is a diagram for explaining an example of the data structure of the transaction details file 1400. The transaction details file 1400 can include a customer ID 1301, account information 1302, transaction date + serial number 1401, deposit / withdrawal classification 1402, transaction store 1403, amount 1404, and summary 1405, but is limited to these data items. Other data items can also be included.

  The customer ID 1301 and the account information 1302 are the same data items as those described above with reference to FIG. The transaction date + serial number 1401 can include information in which a transaction number such as deposit or withdrawal is performed in the customer's account and a sequential number are combined. For the year / month / day, only the year / month / day (YYYYMMDD) may be used, or the hour / minute / second (HHMMMS) information may be used in addition to the year / month / day. Sequential numbers are given because there is a possibility of multiple transactions on the same day. A deposit / withdrawal category 1402 indicates a transaction category such as deposit / withdrawal. The transaction store 1403 can indicate a business store or ATM where transactions such as deposit and withdrawal are performed. The amount 1404 can indicate the transaction amount of a transaction such as deposit or withdrawal. The summary 1405 includes information on deposit / withdrawal, for example, information such as transfer from another bank, salary transfer, automatic withdrawal of utility charges, and the like.

  Similarly to the bank system 100, the CMS system 110 can also include a control unit, a main storage unit, an auxiliary storage unit, an interface (IF) unit, and an output unit that are connected to each other by a bus or the like. These components can perform the same functions as the control unit 201, the main storage unit 202, the auxiliary storage unit 203, the interface (IF) unit 204, and the output unit 205 described with reference to FIG.

  FIG. 3 is a functional block diagram of the bank system 100 according to the present invention. The bank system 100 can include an inquiry message reception unit 301, a management company extraction unit 302, an answer message transmission unit 303, a customer master 206, and an account system DB 207. The customer master 206 and the account system DB 207 are the same as those described above with reference to FIG.

  The inquiry message receiving unit 301 can receive an inquiry message 1200 as illustrated in FIG. 12 from the destination bank system 140 and store it in the main storage unit 202.

  In response to receiving the inquiry message 1200 from the destination bank system 140, the supervising company extraction unit 302 searches for information (transmission number) identifying the transfer included in the inquiry message 1200, and based on the searched transmission number Thus, the transfer message stored in the bank system 100 (the message generated at the time of the first transfer) can be searched to identify the transfer requester. The headquarters company extraction unit 302 searches the customer master 206 based on the information of the identified transfer requester, and reads the information of the CMS contract category 1304 so that the transfer requester can execute the payment agent function. It can be determined whether or not there is. When the read information indicates that the customer is a CMS contractor capable of executing the payment agent function, the managing company extraction unit 302 associates the CMS system 110 with the managing company that is the transfer requester. A notification indicating that the received inquiry message 1200 has been received can be transmitted together with the inquiry message 1200. On the other hand, when the read information indicates that the customer is not a CMS contractor, various controls are performed so that conventional processing is performed. As another embodiment, the managing company extraction unit 302 may be configured to generate a notification message representing the content of the inquiry message 1200 and transmit the notification message to the CMS system 110.

  In response to receiving the response message from the CMS system 110, the response message transmission unit 303 can transmit the response message to the destination bank system 140. The reply message can be transmitted after being checked by the person in charge at the destination bank having the bank system 100.

  In another embodiment of the present invention, the response message transmission unit 303 receives the correction transfer information from the CMS system 110 and generates a response message for transmission to the destination bank system 140 based on the received correction transfer information. be able to. The response message is a message for a correction request (for example, correction to the correct account number) for the reason for the bank transfer failure (for example, account number difference or the like) indicated in the inquiry message. When receiving the recombination instruction from the CMS system 110, the response message sending unit 303 is configured to generate a response message for requesting the destination bank to return funds to the destination bank. it can. The generated response message is transmitted from the bank system 100 to the destination bank system 140 via the second network 150.

  FIG. 4 is a functional block diagram of the CMS system 110 according to the present invention. The CMS system 110 can include a company extraction unit 401, an inquiry message notification unit 402, a response message creation unit 403, an approval request transmission unit 404, a transfer details DB 405, a person in charge DB 406, and a transfer impossible DB 407. In the description of the present embodiment, the bank system 100 and the CMS system 110 are described as separate entities, but the two systems are not separated, and the bank system 100 can be provided including the functions of the CMS system 110 as well. In addition, the bank system 100 may be configured to have the functions shown in FIG.

  In response to receiving a notification and inquiry message 1200 indicating that the inquiry message 1200 associated with the controlling company has been received from the bank system 100, the company extraction unit 401 and the management company associated with the inquiry message 1200 and / or Or group company (s) can be extracted. More specifically, the company extraction unit 401 makes an inquiry to the transfer details DB 405 based on the transfer contents (transfer account, transfer amount, transfer date, etc.) included in the inquiry message 1200, and the headquarters company and the group company. It is possible to identify which created the transfer details data. In addition, when there are a plurality of companies that make transfers to the same bank account on the same day, all of these transfers are unsuccessful, so there may be a plurality of companies that are identified.

  The inquiry message notification unit 402 identifies the person in charge of one or a plurality of companies identified by the company extraction part 401 by inquiring to the person in charge DB 406 and associates the person in charge with the identified person in charge with the controlling company that is the transfer requester. The inquiry message 1200 can be transmitted together with a notification indicating that the received inquiry message 1200 has been received. This process may be performed using the email address of each person in charge stored in the person-in-charge DB 406, or the person in charge of the headquarters company or the person in charge of the group company may be the headquarters company terminal 130a or the group company When accessing the CMS system 110 using the terminal 130b, the CMS system 110 may be configured to clearly indicate that a notification has arrived on the screen.

  The reply message creation unit 403 can generate a reply message based on the correction transfer information or the reorganization instruction received from the supervising company terminal 130a or the group company terminal 130b. The response message is created in conformity with a format that allows communication between the destination bank and the destination bank. The reply message can include correction information for resolving the reason for the inability to transfer notified by the inquiry message among the items of the first transfer information, or a reorganization instruction. The reply message is transmitted to the bank system 100 by the CMS system 110 after the approval process described later is completed. As another embodiment, the CMS system 110 transmits the correction transfer information or the reorganization instruction received from the supervising company terminal 130a or the group company terminal 130b to the bank system 100 after the approval by the approver is completed. The system 100 may be configured to generate an answer message based on the correction transfer information or the reorganization instruction. In such a case, the approval process performed by the approval request transmission unit 404 is performed based on the correction transfer information or the reorganization instruction received from the supervising company terminal 130a or the group company terminal 130b.

  The approval request transmission unit 404 reads the approval route registered in the person-in-charge DB 406, and indicates the approval request for the response message (or correction transfer information or recombination instruction) generated by the response message creation unit 403 in the approval route. To the approvers of the selected headquarters and group companies. The approval route can be determined by the order 1504 in the person-in-charge DB 406. For example, after an approver of a group company first approves, an approver of a supervising company may approve it. The approver of the supervising company and the group company that has received the approval request uses the supervising company terminal 130a or the group company terminal 130b to notify the CMS system 110 whether or not the reply message (or correction transfer information or restructuring instruction) is accepted. You can register via After all the approvals have been made, the CMS system 110 can send an answer message (or correction transfer information or a restructuring instruction) to the bank system 100.

  The transfer details DB 405 is a database that stores transfer details data created by the supervising company or group company. The created transfer details data is transmitted to the bank system 100 of the destination bank, and a transfer process is executed. When an inquiry message is received from the bank at the time of transfer failure, it is possible to identify which group company requested the transfer by referring to the transfer details data stored in the transfer details DB 405.

  In addition, the transfer statement DB 405 can store the contents of the response message for the inquiry message (correction or reorganization, post-correction transfer destination information in the case of correction, approver information, etc.) in association with the corresponding transfer statement data. It is.

  The person-in-charge DB 406 is a database in which one or a plurality of persons in charge corresponding to a bank transfer failure are registered for each company. The person-in-charge DB 406 may register what approval route the reply message (or correction transfer information or reorganization instruction) created using the supervising company terminal 130a or the group company terminal 130b passes through. it can. For example, a person whose order 1504 in the person-in-charge DB 406 indicates “1” creates correction transfer information or a reorganization instruction, and a person whose order 1504 indicates “2” is the first approver, indicating “3”. Can be the next approver.

  The transfer impossible DB 407 is a database that stores non-transferable detailed data indicated by the inquiry message received from the destination bank system 140. The non-transfer details data can be stored in association with the transfer details data in the transfer details DB 405. The non-transferable detailed data can be displayed as a non-transferable detailed list 900 on a screen as shown in FIG.

  FIG. 15 is a diagram illustrating an example of the data structure of the person-in-charge DB 406. The person-in-charge DB 406 can include a company ID 1501, a person-in-charge ID 1502, a name 1503, an order 1504, and an e-mail address 1505 as data items, but is not limited to these data items, and other necessary data items are included. It is also possible to have. The company ID 1501 is an identifier for identifying a supervising company or a group company, and the person in charge ID 1502 is an identifier for identifying each person in charge. The name 1503 can include attribute information of the department, position, role (accounting checker, etc.) in addition to the name of each person in charge. The order 1504 can indicate the order within the supervising company or within the group company. For example, when two persons from the same company are registered, the person with the order “1” creates correction transfer information or the reorganization instruction, and the person with the order “2” is requested to approve. Also good. If the approval request is not approved, it is possible to configure the CMS system 110 to request the person in the next order when a predetermined period has elapsed. An e-mail address 1505 indicates an e-mail address for notifying each person in charge.

  Next, referring to FIG. 5 to FIG. 7, the transfer data is registered by the supervising company or the group company, the transfer based on the transfer data is made from the destination bank to the destination bank, and the transfer is unsuccessful. The processing flow at that time will be described.

  FIG. 5 is a processing flow diagram of transfer details data in the CMS system 110. Referring to FIG. 5, the transfer details data registration for creditors is performed in the CMS system 110 by the supervising company or the group company, and after the approval process for the transfer details data is performed, the transfer is made to the destination bank. A flow in which transfer data based on the detailed data is transmitted will be described.

  In S501, the supervising company terminal 130a or the group company terminal 130b can access the CMS system 110 and register the transfer details data 800 in the transfer details DB 405. An example of the registered transfer details data 800 is shown in FIG. The transfer details data 800 can include at least a client 801, a transfer date 802, transfer destination information 803, and an amount 804. The requester 801 can indicate an actual transfer requester, not a nominal transfer requester. When the payment agent function is used, the nominal transfer requester becomes the supervising company, and the client 801 holds which of the supervising company and the group company is the actual requester. The transfer date 802 can indicate a transfer designated date (a previous date within a predetermined period is possible). The transfer destination information 803 can include bank name, branch name, subject, account number, and account holder information of the transfer destination account. The amount 804 can indicate the transfer amount.

In S502, in response to registration of transfer statement data 800, CMS system 110 notifies one or more approvers of an approval request for transfer statement data 800 in accordance with a predetermined approval route. Can do. More specifically, the CMS system 110 searches the person-in-charge DB 406 based on the company ID 1501 of the company to which the person who registered the transfer statement data 800 belongs, and the person-in-charge ID 1502 of the approver who should notify the approval request. Name 1503, order 1504, and mail address 1505 are extracted. The CMS system 110 notifies the extracted approver of the approval request. Notification may be by means such as e-mail using the mail address 1505, approver it is displayed that there is data to be approved on the screen when accessing the CMS system 110 Also good. The approver can be, for example, the superior of the person who registered the transfer details data 800, the final approver, a predetermined person in charge of the controlling company, the approver, etc. It can be arbitrarily set in the person-in-charge DB 406. When the transfer details data 800 is registered by a group company, the approval route is first subjected to an approval process in the group company, and then an approval process is performed in the supervising company. On the other hand, when the transfer details data 800 is registered by the supervising company, an approval process is performed according to the order 1504 in the supervising company.

  In S503, the CMS system 110 receives one or more transfer details data 800 from the transfer details DB 405 in response to the completion of approval by all the approvers designated by the predetermined approval route. It is possible to read out, generate transfer data according to a format defined by the Zenginkyo, and transmit it to the bank system 100 of the destination bank. The transfer data transmitted to the bank system 100 is subjected to a transfer process at a predetermined timing in the destination bank, and the transfer data is transmitted to the destination bank system 140. In the destination bank system 140, a well-known transfer process is performed based on the received transfer data, and the transfer process that has been successfully completed is a deposit process to the account. An inquiry message is transmitted to the bank system 100.

  Next, the flow of processing that is performed when the banking system 100 of the destination bank receives an inquiry message will be described in detail. FIG. 6 is a processing flow diagram when the inquiry message is received, which is executed in the bank system 100.

  In S <b> 601, the bank system 100 can receive the inquiry message 1200 based on the transfer described with reference to FIG. 5 from the destination bank system 140. The received inquiry message 1200 can be stored in the main storage unit 202.

  In S602, the supervising company extraction unit 302 of the bank system 100 responds to the reception of the inquiry message 1200 from the destination bank system 140, and identifies the transfer included in the inquiry message 1200 (that is, the transmission number). , And a transfer telegram (a telegram generated at the time of the first transfer) existing in the bank system 100 based on the searched transmission number can be searched to identify the transfer requester.

  In step S <b> 603, the supervising company extraction unit 302 can search the customer master 206 based on the identified transfer requester information and read the information of the CMS contract category 1304. If the read information indicates that the customer is a CMS contractor, the process proceeds to S604. On the other hand, if the read information indicates that the customer is not a CMS contractor, the process proceeds to S605. move on.

  In step S <b> 604, the supervising company extraction unit 302 can transmit a notification indicating that the inquiry telegram 1200 associated with the supervising company that is the transfer requester has been received to the CMS system 110 together with the inquiry telegram 1200. In this embodiment, the notification indicating that it has been received and the inquiry message 1200 are configured to be transmitted separately. However, as another embodiment, in S604, the headquarters company extraction unit 302 includes the contents of the inquiry message 1200. Can be generated and sent to the CMS system 110.

  In S605, the bank system 100 can perform various controls so that conventional processing is performed.

  Next, a process for generating an answer message in the CMS system 110 will be described in detail. FIG. 7 is a flowchart for explaining an answer message generation process executed in the CMS system 110 according to the present invention.

  In S <b> 701, the company extraction unit 401 can receive a notification indicating that the inquiry message 1200 associated with the supervising company has been received and the inquiry message 1200 from the bank system 100.

  In step S <b> 702, in response to receiving the notification message 1200 indicating that the inquiry message 1200 associated with the controlling company has been received and the inquiry message 1200, the company extraction unit 401 transfers the transfer contents (transfer destination) included in the inquiry message 1200. Based on the account, transfer amount, transfer date, etc., it is possible to make an inquiry to the transfer details DB 405 and identify which of the controlling company and the group company has created the transfer details data (matching process). In addition, when there are a plurality of companies that make transfers to the same bank account on the same day, all of these transfers are unsuccessful, so there may be a plurality of companies that are identified.

  In S703, if the company that generated the transfer details data can be identified as a result of the matching process in S702, the process proceeds to S704. On the other hand, if the company cannot be identified, the process proceeds to S705. Processing proceeds.

  In step S <b> 704, the inquiry message notification unit 402 identifies the person in charge of one or a plurality of companies identified by the company extraction unit 401 by inquiring the person in charge DB 406, and is a transfer requester to the identified person in charge. The inquiry message 1200 can be notified together with a notification indicating that the inquiry message 1200 associated with the supervising company has been received. The notification may be performed using the email address of each person in charge stored in the person-in-charge DB 406, or the person in charge of the headquarters company or the person in charge of the group company may respectively have the headquarters company terminal 130a or the group company. When accessing the CMS system 110 using the terminal 130b, the CMS system 110 may be configured to clearly indicate that a notification has arrived on the screen.

  In step S <b> 705, the inquiry message notification unit 402 generates a notification that the transfer statement data corresponding to the inquiry message cannot be identified, and sends the notification to the person in charge of the managing company stored in the person-in-charge DB 406. The notification can be transmitted. This notification may be transmitted using the email address of the person in charge, or may be displayed on the screen when the person in charge accesses the CMS system 110 using the management company terminal 130a. Good.

  In step S706, the reply message creation unit 403 can generate a reply message based on the correction transfer information or the reorganization instruction received from the supervising company terminal 130a or the group company terminal 130b. The response message is created in conformity with a format that allows communication between the destination bank and the destination bank. The reply message can include correction information for resolving the reason for the inability to transfer notified by the inquiry message among the items of the first transfer information, or a reorganization instruction. As another embodiment, the CMS system 110 may be configured to transmit the correction transfer information or the reorganization instruction received from the supervising company terminal 130a or the group company terminal 130b to the bank system 100 as it is. In such a case, the reply message creation unit 403 is configured not to create a reply message, and the bank system 100 is configured to generate a reply message based on the correction transfer information or the reorganization instruction.

  In S707, the CMS system 110 can determine whether the reply message generated by the supervising company terminal 130a or the group company terminal 130b indicates correction transfer information or a reorganization instruction. In another embodiment, the CMS system 110 can determine whether the correction transfer information generated by the supervising company terminal 130a or the group company terminal 130b has been received or whether a recombination instruction has been received. In the case of correction transfer information, the process proceeds to S708. On the other hand, in the case of a reorganization instruction, the process proceeds to S710.

  In S708, the approval request transmission unit 404 reads the name 1503 and the order 1504 of the approver registered in the person-in-charge DB 406, and approves the response message (or correction transfer information) generated by the response message creation unit 403. The request can be made to the approver of the controlling company and / or the group company. The approver of the supervising company and / or the group company that has received the approval request can register approval / disapproval of the received response message (or correction transfer information) in the CMS system 110.

  Here, referring to FIGS. 9 to 11, an example of a screen related to the response message creation process and the approval process provided by the CMS system 110 will be described. FIG. 9 is an example of a screen that displays a transfer impossible statement list 900. As described above, each data of the transfer impossible details list 900 is stored in the transfer impossible DB 407. The non-transfer details list 900 can include a sequence number 901, a selection radio button 902, a status 903, a process number 904, a process category 905, a transfer date 906, a transfer destination information 907, and an amount 908, but these data items are limited. It is possible to add arbitrary data items without being done. In FIG. 9, a detail display button 910 can also be displayed.

  Sequence No. 901 indicates a sequence number assigned to the list displayed on the screen. The selection radio button 902 is checked when selecting one item in the list. Any system configuration capable of selecting one detail may be used, and the number of selected check boxes may be controlled using check boxes in addition to radio buttons.

  The status 903 can indicate the current status of the transfer details that has become non-transferable. For example, “Waiting for inquiry response” (inquiry message received but not answered), “Waiting for approval” (answer for inquiry message is created) However, if the approval of the approver has not been made yet: Waiting for approval at the managing company, waiting for approval at the group company is clearly indicated), “Approved” (approval at the controlling company is completed, and the response message is And the like transmitted to the bank system 100 of the destination bank).

  The process number 904 is an identification number assigned to each data of the non-transferable details, and since there is a possibility of receiving the inquiry message from the bank system 140 for receiving a plurality of times, the branch number (-1, -2, etc.) ) Can be added. The processing category 905 can indicate what kind of response is to be made to the non-transferable details. For example, “correction” (when a response message including correction information is created for the inquiry message), “recorrection” "(Sent once the response message, but the transfer message was lost again and the inquiry message was received again, so a response message containing correction information was created again)," Combination "(if the transfer was stopped and the funds were returned), “Unregistered” (if an answer to the inquiry message has not yet been decided), etc.

  The transfer date 906 is the date when the transfer process was performed. The transfer destination information 907 indicates the bank, branch, subject, account number, and account name of the transfer destination account. A money amount 908 indicates a transfer money amount. When the detail display button 910 is pressed, data of any one item selected by the selection radio button 902 is displayed on a screen as shown in FIG. 10 or FIG. FIG. 10 is an example of a screen used when creating an answer to the inquiry message. On the other hand, FIG. 11 is an example of a screen for performing an approval action for the created answer message.

  In FIG. 10, since the transfer data that cannot be transferred is displayed together with the reason for the transfer failure, the content of the response message (whether it is correction or reorganization), the transfer destination information after correction, and the response message Approvers (can be selected from the person-in-charge DB 406, the options can be controlled by the person in charge at which company is making an input), applicant comments, and the like. When the “Confirm” button is pressed, the contents of the reply message can be stored in association with the transfer details data 800 of the transfer details DB 405.

  FIG. 11 shows a screen where the approver approves the created reply message. The approver is selected in advance from data registered in the person-in-charge DB 406. When the response message is created by the group company, the approval action at the supervising company is performed after the approval action at the group company is completed. When the approval process by all the approvers (ie, pressing the approval button) is completed, the reply message is transmitted to the bank system 100.

  10 and 11, the description has been made on the premise that an answer message is created. However, as another embodiment, a screen for inputting correction transfer information or a reorganization instruction may be provided instead of the answer message itself. .

  After all the approval processes are performed in S709, the CMS system 110 can transmit a reply message (or correction transfer information) to the bank system 100.

  On the other hand, if it is determined in S707 that the recombination instruction has been received, in S710, the approval request transmission unit 404 reads the name 1503 and the order 1504 of the approver registered in the person-in-charge DB 406, and responds. An approval request for the reply message (or the recombination instruction) generated by the message creation unit 403 can be made to the approver of the managing company and the group company. The approver of the supervising company and the group company that has received the approval request can register the approval / disapproval of the received reply message (or the recombination instruction) in the CMS system 110. The reply message creation process and the approval process can be executed as described above using the screens illustrated in FIGS.

  In S711, the reply message is transmitted to the bank system 100 after the approval process as described above is completed.

At S712, CMS system 110 can generate account data associated with the CMS transaction. When the reorganization is performed, the transfer of funds as shown in the following example occurs, so that the account data associated therewith is generated in the CMS system 110.
(1) At the time of transfer request 150,000 yen is withdrawn from the supervising company account, and the transfer is made to the transfer destination account of the bank 140 to which it is sent. In addition, 150,000 yen will be transferred from the account of the group company requesting the transfer to the account of the controlling company.
(2) At the time of reorganization At the stage where reorganization is approved, 150,000 yen will be transferred from the controlling company account to the account of the group company that requested the transfer.
(3) At the time of depositing the reorganization funds The reorganization funds are deposited into the controlling company account in the bank system 100. The CMS system 110 can grasp from the deposit details that the deposit has been made to the supervising company account, and can perform the revocation process by associating the funds transfer generated in the above (2) with the current deposit. .

  Although the principle of the present invention has been described above with reference to exemplary embodiments, those skilled in the art will recognize that various embodiments that can be corrected in configuration and details can be realized without departing from the spirit of the present invention. Will understand. That is, the present invention can adopt an embodiment as, for example, a system, apparatus, method, program, or storage medium.

DESCRIPTION OF SYMBOLS 100 Bank system 110 CMS system 120 1st network 130a Supervising company terminal 130b Group company terminal 140 Target bank system 150 2nd network 201 Control part 202 Main memory part 203 Auxiliary memory part 204 Interface (IF) part 205 Output part 206 Customer master 207 Account DB
301 inquiry message reception unit 302 supervising company extraction unit 303 response message transmission unit 401 company extraction unit 402 inquiry message notification unit 403 response message creation unit 404 approval request transmission unit 405 transfer details DB
406 Person in charge DB
407 Untransferable DB
800 Transfer details data 900 Non-transferable details list 1200 Inquiry message 1400 Transaction details file

Claims (8)

A first message receiving means for receiving a first message from a destination bank system, wherein the first message is sent from the destination bank system to the bank system in order to make an inquiry to the destination bank when a transfer process is unsuccessful. A first message receiving means which is a transmitted inquiry message;
The transfer requester is identified by searching for the transfer message based on the transfer identification information included in the first message, and the identified transfer requester performs the payment proxy function by referring to the CMS contract category of the customer master. First extraction means for determining whether or not execution is possible;
One or more entities associated with the first message based on the transfer contents included in the first message when it is determined that the identified transfer requester can execute the payment proxy function A second extracting means for identifying the transfer message, wherein the transfer message is based on transfer detail data created by the one or more entities;
A notification indicating that the first electronic message has been received and the notification means for communicating the first electronic message to the identified one or a plurality of entities, the non-transferable details associated with the first electronic message being: A notification means associated with the transfer statement data;
Generation means for generating a second message based on an input by the identified one or more entities , wherein the second message is a reply message for the reason for the transfer failure included in the first message; Generating means ;
An approval request sending means for making an approval request for the second message to a predetermined approver;
A bank system comprising: a second message transmission means for transmitting the second message, which has been approved by all of the approvers, to the bank system to be sent.   Identifying one or more entities associated with the first message based on the transfer contents included in the first message indicates that any data item of the transfer contents included in the first message is the The banking system according to claim 1, wherein the banking system is performed based on whether or not a corresponding data item included in the transfer details data created by one or more entities is matched.   Identifying the transfer requester by searching for a transfer message based on the transfer identification information included in the first message includes the transfer identification number included in the transfer message and the transfer identification included in the first message. The banking system of claim 1, wherein the banking system is based on whether the number matches. The banking system according to claim 1, wherein in response to completion of approval of the second message, account data relating to the second message is generated. The banking system according to claim 1 , wherein the second electronic message is based on one of correction transfer information and a reorganization instruction. If the second electronic message is based on reorganization, the first funds transfer data generated in response to the completion of the approval of the second electronic message, and the reorganization funds for the account associated with the transfer requester The banking system according to claim 5, wherein a banking process is executed for associating with the second fund transfer data indicating that the deposit has occurred. A method carried out by the banking system at the destination bank,
A first telegram received from the destination bank system, wherein the first telegram is transmitted from the destination bank system to the bank system in order to make an inquiry to the destination bank when the transfer process is unsuccessful; And that
The transfer requester is identified by searching for the transfer message based on the transfer identification information included in the first message, and the identified transfer requester performs the payment proxy function by referring to the CMS contract category of the customer master. Determining whether it is feasible,
One or more entities associated with the first message based on the transfer contents included in the first message when it is determined that the identified transfer requester can execute the payment proxy function The transfer message is based on transfer statement data created by the one or more entities;
A notification indicating that the first electronic message has been received and the first electronic message are communicated to the identified one or more entities, and the non-transferable item associated with the first electronic message is: Associated with the transfer statement data;
Generating a second telegram based on an input by the identified one or more entities , wherein the second telegram is a reply telegram for a transfer failure reason included in the first telegram. When,
Making an approval request for the second message to a predetermined approver;
Transmitting the second message, which has been approved by all of the approvers, to the destination bank system.   A program for causing a computer to execute the method according to claim 7.