JP2013228935A - Transfer system and transfer method - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a transfer system and a transfer method capable of processing a large amount of transfer data collectively and improving a transfer success rate.SOLUTION: A transfer system determines a scheduled transfer day based on first comprehensive transfer data received from a user system. When the scheduled transfer day indicates a business day after a predetermined business day, each piece of transfer destination account information included in the first comprehensive transfer information is extracted, a validity inspection of each piece of the extracted transfer destination account information is executed through communication with an integrated ATM, and then resultant data of the validity inspection of each piece of the transfer destination account information is received from the integrated ATM. Each piece of the transfer destination account information is associated with the resultant data of the validity inspection, and only a piece of the transfer destination account information which is determined to have no error on the basis of the associated resultant data of the validity inspection is identified. Then, second comprehensive transfer data including only the identified piece of the transfer destination account information is generated. Transfer processing of the second comprehensive transfer data transmitted to a bank system is executed on the scheduled transfer day by the bank system.

Description

  The present invention relates to a transfer system and a transfer method. More specifically, the present invention relates to a transfer system and a transfer method that can process a large amount of transfer data in a lump and improve the transfer success rate.

  Conventionally, each financial institution can perform a currency exchange transaction such as a transfer with another financial institution connected to the network via the Zengin System. Further, it is known that there are two types of transfer processing from the transfer source account to the transfer destination account, which are roughly divided from the form of data to be created.

  The first type is called “advanced transfer (individual transfer)”, which is used when the number of transfers is relatively small. The data format of the transfer is the transfer source account in one set of data. Includes information and bank account information one by one. The transfer is used, for example, when an individual customer transfers the purchase amount of a product from his / her account to the product seller's account.

  The second type is called “total transfer (collective transfer)” used when the number of transfers is relatively large (see Patent Document 1), and the data format of the total transfer is one set of data. Includes one source account information and one or more destination account information. More specifically, as illustrated in FIG. 7, one set of comprehensive transfer data includes a header (H) record (including transfer source account information), one or more data (D) records (transfer destination details) ), Trailer (T) records (including total count and total amount), and end (E) records. The general transfer is used, for example, when a company wants to perform transfer processing in a large number of transfer destinations.

  FIG. 1 is a diagram for explaining a general-purpose system 100 capable of handling a large amount of transfer, which is a conventional technique. The general-purpose system 100 connects the common center 120 and the enterprise 110 via the first network 140, and connects the common center 120 and each bank 130 via the second network 150, thereby issuing a transfer instruction. A large amount of data processing requests can be made to financial institutions such as the first.

  The enterprise 110 has a business system and a connection system, and the common center 120 has a communication line adapter and an FEP that performs preprocessing of data and the like. Each bank 130 has a host such as a core system.

  The first network 140 is a network that can be shared and used by each bank, and is a network used as a connection path that connects the connection system of the company 110 and the communication line adapter of the common center 120. The second network 150 is a network used as a bank-side connection path that connects the common center 120 and each bank. The first network 140 and the second network 150 can improve the safety and certainty of transactions using a dedicated line or the like.

  The general-purpose system 100 is a system that can handle the transfer every time (the general transfer data is converted into the transfer data each time in the connection system of the company 110), and the data set for the transfer from the company 110 is the common center 120. The data is processed at the common center 120 and transmitted to each bank 130, and then the transfer process to each account is performed at the host of each bank 130. The processing performed in the common center 120 includes, for example, relaying communication so that a predetermined service can be obtained even if a user such as a company or an individual does not go to each financial institution, and receives a transfer instruction each time. In the case of payment, it is possible to check the validity of the transfer account.

  In addition, when transferring money between banks, some data cannot be transferred due to reasons such as account number differences and name differences. In such a case, an inquiry is made from the bank with the bank account (destination bank: receiving side) to the bank with the bank account (destination bank: remittance side). When responding, it is known that the destination bank corrects and processes the deposit.

  In addition, an integrated ATM, which is a relay system for interconnecting CD / ATM (cash dispenser / automated teller machine) owned by each bank, has been known. It is known that the integrated ATM can be used for account confirmation processing such as account existence confirmation and account number confirmation. It is known that a financial institution or the like can transmit information (bank code, branch code, item code, account number, etc.) about a certain account to the integrated ATM and receive the result data of the account confirmation processing from the integrated ATM.

JP 2010-271859 A

  However, the common center 120, which is the conventional technology, cannot handle the data for comprehensive transfer, and even if the data is checked in the company 110, a certain percentage is required when performing the comprehensive transfer via the transaction financial institution. In some cases, error data occurred.

  Further, the integrated ATM is a system that is assumed to be used by a financial institution, and cannot be used by each user to check the validity of the transfer destination account included in the comprehensive transfer data.

  Furthermore, there has been a need for a transfer system and a transfer method that can process a large amount of transfer data collectively and improve the transfer success rate.

  The present invention has been made in view of such a problem, and an object of the present invention is to provide a transfer system and a transfer method capable of processing a large amount of transfer data in a lump and improving the transfer success rate. And

  In order to solve the above problems, a transfer system according to the present invention includes a receiving means for receiving first comprehensive transfer data from a user system, and a transfer date for determining a scheduled transfer date from the first comprehensive transfer data. When the determination means and the scheduled transfer date indicate a business day after a predetermined business day, each transfer destination account information included in the first general transfer data is extracted, and each extracted transfer destination account Account verification means for performing validation of information by communicating with an integrated ATM, and receiving the result data of the validation for the respective bank account information from the bank ATM, and each bank account information Only the bank account information that is determined to have no error based on the associated validation result data A generating unit that identifies and generates second comprehensive transfer data including only the identified transfer destination account information, and a transmitting unit that transmits the second comprehensive transfer data to a bank system, The transfer process using the general transfer data is provided with a transmission means that is executed by the bank system on the scheduled transfer date.

  In addition, the transfer method according to the present invention includes a step of receiving first comprehensive transfer data from a user system, a step of determining a transfer date from the first comprehensive transfer data, and the transfer date is predetermined. When a business day after the first business day is indicated, the step of extracting each transfer destination account information included in the first comprehensive transfer data and the validity check of each extracted transfer destination account information are integrated. A step executed by communicating with an ATM; a step of receiving validation result data for the respective bank account information from the integrated ATM; and a respective bank account information and a result of the validation Correlating data, and bank account information determined to have no error based on the associated validation result data Generating the second total transfer data including only the identified transfer destination account information, and transmitting the second total transfer data to the bank system, the second The transfer process using the general transfer data is performed by the bank system, and is executed on the scheduled transfer date.

  The present invention can provide a transfer system and a transfer method capable of processing a large amount of transfer data at once and improving the transfer success rate. Further, according to the present invention, it is possible to process more data than before by adopting a configuration capable of executing parallel processing using dummy accounts for some or all of the transfer source accounts. In addition, the present invention validates the transfer details of the comprehensive transfer data one by one, and configures the comprehensive transfer data that includes only data that has no error as a result of the validity check. It is possible to obtain an effect that the probability of occurrence is significantly reduced.

It is a figure explaining the general purpose system which can handle mass transfer data. It is a whole figure for demonstrating the concept of the transfer system which concerns on this invention. It is a block diagram explaining the system configuration | structure of a transfer process reception server. It is a functional block diagram of a reception server. It is a block diagram explaining the system configuration | structure of an account confirmation server. It is a figure explaining the processing flow about "the same day transfer" performed in the transfer system which concerns on this invention. It is a figure explaining an example of the data format for total transfers. It is a figure explaining an example of the data format for transfer each time. It is a figure explaining an example of the conversion table for converting transfer origin account information. It is a figure explaining the processing flow about "reservation transfer" performed in the transfer system which concerns on this invention. It is a figure explaining the processing flow about "mass transfer" performed in the transfer system concerning the present invention.

  Hereinafter, embodiments of the present invention will be described in detail. FIG. 2 is an overall view for explaining the concept of the transfer system 200 according to the present invention. In the description of the present embodiment, the description will be made with a focus on the above-mentioned “general transfer (collective transfer)”, but it is a mechanism that can also be applied to “every transfer (individual transfer)” and is not limited. Absent.

  The transfer system 200 includes a company 110, a reception server 210, a common center 120, an integrated ATM 220, a bank system 230, and a Zengin network 240. The company 110 includes a transmission server 111 for transmitting various data therein. The transmission server 111 transmits the total transfer data generated in the company 110 to the reception server 210. Regarding data transmission, data transfer can be performed using HULFT (registered trademark). In the description of the present embodiment, an embodiment using HULFT will be described, but other software / means capable of smoothly exchanging a large amount of data may be used.

  The reception server 210 includes a HULFT server 211, a transfer processing reception server 212, a Web server 213, and an account confirmation server 214. The HULFT server 211 receives the general transfer data transmitted from the transmission server 111 of the company 110 via the network (for example, IP-VPN), and transmits the total transfer data to the transfer processing reception server 212. The HULFT server 211 can also be used for file cooperation with other servers and other systems.

  The Web server 213 receives files such as general transfer data uploaded from the transmission server 111 according to a predetermined procedure / standard, and transmits (downloads) various data to the transmission server 111. The Web server 213 can be set as an arbitrary configuration requirement in the transfer system 200 according to the present invention. The Web server 213 transmits the received general transfer data to the transfer processing reception server 212.

  The account confirmation server 214 performs account confirmation by communicating with the integrated ATM 220 for each transfer destination detailed data included in the comprehensive transfer data, and performs processing for associating the account confirmation result with the comprehensive transfer data. Here, the process of associating is to add (set) the account confirmation result to a predetermined byte position of the data record with the total transfer data, or the relationship between the data record with the total transfer data and the reference / referenced To generate another data record with

  The reception server 210 directly transmits the general transfer data for which the account confirmation processing by the account confirmation server 214 has been completed to the bank system 230, while transmitting the transfer data to the common center 120 each time. The transfer data can be generated by data processing inside the receiving server 210 as will be described later.

  Since the data for comprehensive transfer received by the bank system 230 has been subjected to the account confirmation process for each transfer destination detailed data in the receiving server 210, the general transfer process procedure conventionally performed in the bank system 230 is performed. It is processed. Specifically, the EB host 231 transmits the received total transfer data to the account system 232, and the account system 232 transmits the total transfer data to each financial institution via the Zengin Network 240.

  The total transfer DB 234 is a database that stores total transfer data. The general transfer DB 234 is shown in FIG. 2 in a form independent of the EB host 231 and the billing system 232, but may be any database that stores general transfer data stored / processed in the bank system 230. The EB host 231 and the billing system 232 may exist inside each.

  On the other hand, the transfer data is transmitted from the reception server 210 to the common center 120 each time. The common center 120 checks the transfer destination account information indicated in the transfer data each time by communicating with the integrated ATM 220. The contents to be checked are, for example, the presence / absence of a transfer account and the match / mismatch of account numbers. Each time the check is completed, the transfer data is transmitted from the common center 120 to the bank system 230 and stored in the transfer details DB 233. In the bank system 230, a transfer process that has been conventionally performed is performed, and the processed data is transmitted to each financial institution via the Zengin Network 240.

  The transfer details DB 233 is a database that stores transfer data each time. The transfer details DB 233 is shown in FIG. 2 in a form independent of the EB host 231 and the bill system 232, but any database that stores data for transfer that is stored / processed in the bank system 230 every time. The EB host 231 and the billing system 232 may exist inside each.

  The Zengin Network 240 is a well-known network that connects financial institutions, and is used, for example, to exchange transfer data between banks.

  FIG. 3 is a block diagram for explaining the system configuration of the transfer process reception server 212. The transfer processing reception server 212 includes a control unit 301, a main storage unit 302, an auxiliary storage unit 303, an interface (I / F) unit 304, a display unit 305, a general transfer DB 306, a transfer database 307, a data format DB 308, and a conversion A table 309 is provided. These components 301 to 309 are connected to each other via a bus 310, and the components 302 to 309 are collectively controlled by the control unit 301.

  The control unit 301 is also referred to as a central processing unit (CPU), controls the components 302 to 309 and calculates data as described above, and stores various programs stored in the auxiliary storage unit 303 as main memory. The data is read by the unit 302 and executed. The main storage unit 302 is also called a main memory, and stores various received data, computer-executable instructions, data after arithmetic processing by the instructions, and the like.

  The auxiliary storage unit 303 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. Since the main storage unit 302 has a relatively smaller storage capacity than the auxiliary storage unit 303, it is used for temporary data storage, arithmetic processing, and the like, whereas the auxiliary storage unit 303 uses necessary data and information. Used for long-term storage and storage. That is, when the control unit 301 executes a program to perform data calculation, the necessary data and program are read from the auxiliary storage unit 303 to the main storage unit 302 and the calculation result data is stored / saved for a long time. In this case, the control unit 301 writes the calculation result data in the auxiliary storage unit 303.

  An interface (I / F) unit 304 plays a role of an interface when data is transmitted / received to / from other client devices or server devices. Data received from the outside is temporarily stored in the main storage unit 302. The interface unit 304 provides an interface (an application program such as an input screen) that receives various commands and input data (such as various masters and tables) from the system operator. The display unit 305 provides a display screen that displays the processed data.

  The total transfer DB 306 is a database that stores total transfer data received from the outside of the transfer processing reception server 212 (for example, the company 110) and total transfer data as a processing result inside the transfer processing reception server 212.

  Each time transfer DB 307 is a database that stores data for each transfer received from the outside of the transfer processing reception server 212 (for example, the company 110) and data for each transfer as a processing result inside the transfer processing reception server 212.

  The data format DB 308 is a database for storing various data formats, and stores a general transfer data format 700 shown in FIG. 7, a transfer data format 800 shown in FIG.

  The conversion table 309 stores various conversion tables such as the conversion table 900 shown in FIG.

  FIG. 4 is a functional block diagram of the reception server 210. The reception server 210 includes at least a reception unit 401, a transfer date determination unit 402, an account confirmation unit 403, a generation unit 404, and a transmission unit 405.

  The receiving unit 401 receives data for comprehensive transfer from a user such as the company 110 (for example, the HULFT server 211 or the Web server 213).

  The transfer date determination unit 402 accesses the received general transfer data, and determines the scheduled transfer date stored therein. The transfer date determination unit 402 can exist in the transfer process reception server 212. In one embodiment, the account verification server 214 may also exist.

  When the scheduled transfer date indicates a business day after a predetermined business day (for example, after two business days) based on the data reception date, the account confirmation unit 403 displays each bank account information included in the general transfer data. Extract. The account confirmation unit 403 executes validity check of each extracted transfer account information by communicating with the integrated ATM. The validity check is executed using the bank code, branch code, item code, and account number included in each transfer account information. Furthermore, the account confirmation part 403 receives the result data of the validity check about each transfer destination account information from integrated ATM.

  The generation unit 404 associates each transfer destination account information included in the general transfer data with the result data of the validity check. The association may be performed so as to be added to the transfer destination account information of the general transfer data, or may be performed in the form of another file having a reference / referenced relationship with the general transfer data. Further, the generation unit 404 identifies only the transfer destination account information that is determined to have no error based on the associated validity check result data, and includes only the transfer destination account information that has no error. Data can be generated. Further, the generation unit 404 identifies only the transfer destination account information that is determined to have an error based on the associated validity check result data, and the transfer destination account information in which the error exists (if necessary, the error The result reply data including the reason) can be generated.

  The transmission unit 405 transmits the total transfer data generated by the generation unit 404 that does not include an error to the bank system. The transmission unit 405 transmits the result reply data to the company 110 that is a user.

  FIG. 5 is a block diagram illustrating the system configuration of the account confirmation server 214. The account confirmation server 214 includes a control unit 501, a main storage unit 502, an auxiliary storage unit 503, an interface (I / F) unit 504, a display unit 505, a bank transfer details identification unit 506, an account confirmation unit 507, and an association unit 508. Prepare. These components 501 to 508 are connected to each other via a bus 510, and the components 502 to 508 are collectively controlled by the control unit 501. Note that the components 501 to 505 shown in FIG. 5 have functions corresponding to the components 301 to 305 shown in FIG. 3, and thus detailed descriptions of these components 501 to 505 are omitted. .

  The transfer details identification unit 506 reads the general transfer data, and identifies the transfer account information from the transfer details data (D record) of the read general transfer data. The identified bank account information includes at least a bank code, a branch code, a subject code, an account number, and an account name.

  The account confirmation unit 507 inquires to the integrated ATM 220 via the network whether the transfer destination account information identified by the transfer detail identification unit 506 is valid, and confirms the account from the integrated ATM 220. Receive account verification results for validity. The account confirmation result includes information (for example, the existence / non-existence of an account, match / mismatch of account numbers, etc.) identifying whether or not each transfer destination account is valid.

  The associating unit 508 generates general transfer data in which each transfer destination account information of the general transfer data is associated with the account confirmation result received from the integrated ATM 220. Specifically, the bank transfer details A included in the general transfer data indicates that an account exists and the account number matches, and the bank transfer details B does not have an account. , Etc. are generated, and the total transfer data is generated. The generated general transfer data may be a single file or a plurality of files associated with each other. The associating unit 508 transmits the generated general transfer data to the transfer process reception server 212.

  Below, three embodiment of a transfer process is described. The three embodiments are: (1) “Same-day transfer” in which the transfer process is performed on the day when the transfer request is made, (2) “Reservation transfer” in which the transfer process is performed after the next business day after the transfer request is made, and (3) that day. It is a "mass transfer" that combines transfer, reservation transfer and bulk account confirmation processing.

<Same-day transfer>
FIG. 6 is a diagram for explaining the processing flow of “Same-day transfer” performed in the transfer system 200 according to the present invention.

  In step S <b> 601, the HULFT server 211 receives comprehensive transfer data from the transmission server 111 of the company 110. The received total transfer data is transmitted to the transfer processing reception server 212 and stored in the total transfer DB 306.

  Here, an example of the general transfer data format 700 will be described with reference to FIG. The general transfer data format 700 includes at least a type 701 and data contents 702. As shown in FIG. 7, the total transfer data is configured in accordance with the total transfer data format 700, and includes the header (H) record, the data (D) record, the trailer (T) record, and the total transfer data. An end (E) record is included.

  The H record includes information of a transfer source account that is a withdrawal account (bank code, branch code, item code, account number, account name, etc.). In one embodiment, the H record may be configured to include a company ID that identifies the company 110. When the reception server 210 is configured to be able to communicate with the bank system 230, the transfer source account is validated when the reception server 210 receives the general transfer data. Alternatively, the information of the transfer source account that has been validated before being transmitted from the transmission server 111 of the company 110 can be set in the general transfer data.

  The D record includes one or more bank transfer details (bank code, branch code, item code, account number, account name, transfer amount, etc.). The T record includes the total number of D records and the total transfer amount. The E record can be a Null value or can be data such as a specific identification flag.

  In the case of the “mass transfer” embodiment to be described later, it is possible to cooperate with the processing of step S602 from the flowchart shown in FIG.

  In step S602, the transfer processing reception server 212 reads the total transfer data from the total transfer DB 306, and converts the read total transfer data into the transfer data according to the transfer data format 800 each time (conversion processing). Here, an example of the transfer data format 800 will be described with reference to FIG. Each transfer data format 800 includes at least a transfer source account 801, a transfer destination account 802 and a transfer amount 803. As shown in FIG. 8, the transfer data is configured according to the transfer data format 800 each time.

  In one embodiment, the transfer data format 800 can be configured to include a company ID 804. The company ID 804 may be a code for identifying that the transfer source account 801 is a company account, and the same company ID 902 as shown in FIG. 9 can be used.

  When returning to step S602 and continuing the description, the transfer processing reception server 212 temporarily stores the withdrawal account (transfer source account) information stored in the H record of the read general transfer data on the main storage unit 302. In addition, the transfer destination account information and the transfer amount are acquired from each of the D records. Thereafter, the transfer process reception server 212 uses the transfer source account information, the transfer destination account information, and the transfer amount data, and generates transfer data each time according to the transfer data format 800. The generated transfer data is stored in the transfer DB 307 each time. The transfer process reception server 212 finishes processing all the D records of the read general transfer data, and ends the conversion process after reading the E records. As a result of this process, transfer data is generated from the comprehensive transfer data each time.

  In one embodiment, the transfer process reception server 212 can convert the transfer source account information of the transfer data each time using the conversion table 900 shown in FIG.

  The conversion table 900 includes a withdrawal account 901, a company ID 902, and a conversion account 903. The withdrawal account 901 is an account corresponding to the transfer source account included in the transfer data received from the company 110. The company ID 902 is an ID that uniquely identifies each company. A conversion account 903 indicates a transfer source account after conversion in which the transfer source account included in the transfer data received from the company 110 can be converted.

  As shown in FIG. 9, the conversion table 900 can be configured to include an actual account and a dummy account as the conversion account 903 associated with the withdrawal account 901. In one embodiment, a flag indicating whether the conversion account 903 is an actual account or a dummy account may be provided in the conversion table 900.

  In step S <b> 603, the transfer processing reception server 212 reads the transfer data from the transfer DB 307 every time and transmits it to the common center 120.

  In step S604, the common center 120 confirms the account by inquiring to the integrated ATM 220 whether or not the transfer destination account information stored in the transfer data received is appropriate. As a result of the account confirmation process, the common center 120 can make each data identifiable according to the presence or absence of an error (for example, a flag indicating the confirmation result is added to the transfer data each time). The transfer data is transmitted from the common center 120 to the bank system 230 every time the account confirmation process is completed.

  In step S605, the bank system 230 stores the transfer data received from the common center 120 in the transfer details DB 233 each time.

  In step S <b> 606, the bank system 230 executes the transfer process for the data in which no error has occurred among the transfer data stored in the transfer details DB 233. Specifically, the bank system 230 reads the transfer data from the transfer details DB 233 every time no error occurs, and performs a transfer process within the bank system 230 if the transfer destination account is the bank account. If the account is an account of another bank, the transfer data is transmitted to the corresponding financial institution via the Zengin Network 240 each time.

  In step S <b> 607, the bank system 230 uses the transfer data each time the transfer process is completed successfully and the transfer data each time the transfer process is not performed because an error has occurred. Generate and send to company 110. More specifically, the result reply data generation process is described. The bank system 230 extracts data that can be identified as the data of the company 110 from the information of the transfer source account (or the company ID if it exists). Then, data indicating the data for which the transfer process has been completed and the data for which the error has occurred are generated. The result reply data is not limited to a specific format as long as the above-described contents are indicated.

<Reservation transfer>
FIG. 10 is a diagram for explaining a processing flow of “reservation transfer” performed in the transfer system 200 according to the present invention. Reservation transfer is a process of receiving transfer request data at least one business day before and performing a transfer process on a specified date. Therefore, the general transfer data described in the following processing flow will be described as including information on a transfer designated date (transfer reservation date).

  In step S <b> 1001, the HULFT server 211 receives comprehensive transfer data according to the comprehensive transfer data format 700 from the transmission server 111 of the company 110. The received total transfer data is transmitted to the transfer processing reception server 212 and stored in the total transfer DB 306. Similar to the “same-day transfer” embodiment described with reference to FIG. 6, the H record included in the comprehensive transfer data may be configured to include an identification ID for identifying the company 110. When the reception server 210 is configured to be able to communicate with the bank system 230, the transfer source account is validated when the reception server 210 receives the general transfer data. Alternatively, the information of the transfer source account that has been validated before being transmitted from the transmission server 111 of the company 110 can be set in the general transfer data.

  In the case of the “mass transfer” embodiment described later, it is also possible to cooperate with the processing in step S1002 from the flowchart shown in FIG.

  In step S1002, the transfer processing reception server 212 reads the total transfer data from the total transfer DB 306, and converts the read total transfer data into the transfer data according to the transfer data format 800 each time (conversion processing). “Reservation transfer” has relatively more processing time than “Same-day transfer”, so in order to be able to process more transfer data, the conversion process using a dummy account should be performed as described below. Can do.

  The transfer processing reception server 212 acquires the withdrawal account (transfer source account) information stored in the H record of the read general transfer data, and the total number of the total transfer data stored in the T record. Temporarily stored in the main storage unit 302.

  As described above, the conversion table 900 includes a dummy account mainly used for reducing the processing load. Note that dummy accounts can be used when processing large amounts of transfer data, since too many accesses to the same account are undesirable from a parallel processing perspective.

  The transfer process reception server 212 determines the number of dummy accounts to be used from the total number according to a predetermined threshold. In the description of the present embodiment, the actual account used in the conversion process is described as “1” and the number of dummy accounts is “2”. However, the number of dummy accounts to be used can be changed according to the number of transfer data items. It will be understood. Alternatively, in another embodiment, it is possible to use all the dummy accounts without using an actual account.

  The transfer process reception server 212 acquires the transfer destination account information and the transfer amount from each of the D records. Thereafter, the transfer process reception server 212 uses the transfer source account information, the transfer destination account information, and the transfer amount data to generate the transfer data according to the transfer data format 800 each time. In the present embodiment, since three actual accounts and dummy accounts are used in total, the transfer processing acceptance server 212 uses the actual account and the dummy account as the transfer source account for the number of about 1/3 of all D records. Use as information.

  Thereafter, the transfer processing reception server 212 finishes processing all the D records and ends the conversion processing after reading the E records. As a result of this processing, transfer data is generated each time from the comprehensive transfer data, and information on one actual account and two dummy accounts is stored in the transfer source account information of the transfer data each time. The transfer data is stored in the transfer DB 307 by the transfer processing reception server 212 each time.

  In step S <b> 1003, the transfer processing reception server 212 reads the transfer data from the transfer DB 307 every time and transmits it to the common center 120.

  In step S1004, the common center 120 confirms the account by inquiring to the integrated ATM 220 whether or not the transfer destination account information stored in the received transfer data is appropriate. As a result of the account confirmation process, the common center 120 can make each data identifiable according to the presence or absence of an error (for example, a flag indicating the confirmation result is added). The transfer data is transmitted from the common center 120 to the bank system 230 every time the account confirmation process is completed.

  In step S <b> 1005, the bank system 230 stores the transfer data received from the common center 120 in the transfer details DB 233 each time. The transfer details DB 233 may be stored for each transfer source account (in other words, a table is divided for each actual account and dummy account). Further, the transfer details DB 233 may be stored for each designated date (reservation date) of the transfer process.

  In step S <b> 1006, the bank system 230 generates total transfer data using data in which no error has occurred among the transfer data stored in the transfer transfer details DB 233. The generated total transfer data is stored in the total transfer DB 234. In the following process, the company ID 804 and the company ID 902 can be used as necessary.

  More specifically, the bank transfer system 230 reads the transfer data each time an error has not occurred and identifies the transfer source account 801. The bank system 230 makes an inquiry to the conversion table 900 to identify the withdrawal account 901 associated with the identified transfer source account 801 (that is, the conversion account 903). In the example of this embodiment, the same withdrawal account 901 is derived from the transfer data each time using one actual account and two dummy accounts.

  The bank system 230 includes the account information of the identified withdrawal source account 901 in the H record, and information on the transfer destination account 802 and the transfer amount 803 of the transfer data each time associated with the identified withdrawal source account 901. Is used to generate a D record. The bank system 230 calculates the total number and total amount from the generated D record, generates a T record, then generates an E record, and includes data for total transfer including each of the H / D / T / E records. Is generated and stored in the general transfer DB 234.

  In addition, when it is determined that an actual account is used as the transfer source account information of the transfer data each time when an inquiry is made to the conversion table 900, the withdrawal source associated as described above. The information of the account 901 may be included in the H record, or the transfer source account information of the transfer data may be included in the H record as it is each time.

  In step S1007, the bank system 230 performs a transfer process on the generated general transfer data according to the reservation date. More specifically, the bank system 230 reads the general transfer data from the general transfer DB 234 and performs a transfer process in the bank system 230 if the transfer destination account is an own bank account, and the transfer account is an account of another bank. If there is, the comprehensive transfer data is transmitted to the corresponding financial institution via the Zengin Network 240.

  In step S1008, the result transfer data is generated by using the overall transfer data that has been successfully transferred and the transfer data in the transfer details DB 233 that has not been transferred because an error has occurred. To the company 110. The result reply data is not limited to a specific format as long as it is data indicating the data for which the transfer process has been completed and the data for which an error has occurred.

  In another embodiment of “reservation transfer”, a dummy account can be used in common for each company. In such a case, a code (for example, company ID 804) that can identify the company is added to each record of the transfer data generated in step S1002, and when the general transfer data is generated in step S1006. The company ID 804 is read from the transfer details DB 233 together with the dummy account that is the transfer source account, and the conversion table 900 is inquired based on the dummy account and the company ID, and the actual transfer source account (withdrawal account 901) is identified. In addition, if comprehensive transfer data is created for each identified transfer source account, the data can be identified even if the same dummy account is used by a plurality of companies.

<Mass transfer>
FIG. 11 is a diagram for explaining a processing flow of “mass transfer” performed in the transfer system 200 according to the present invention. Mass transfer is a mechanism that enables transfer of much more data (for example, tens of thousands or more) than transfer on the day or reservation transfer. Therefore, the general transfer data described in the following processing flow will be described as including information on a transfer designated date (transfer reservation date). In the embodiment of the present invention, an embodiment is described in which two business days before the designated transfer date are received, but the present invention is not limited to this.

  In step S <b> 1101, the HULFT server 211 receives comprehensive transfer data according to the comprehensive transfer data format 700 from the transmission server 111 of the company 110. The received total transfer data is transmitted to the transfer processing reception server 212 and stored in the total transfer DB 306. Similar to the “same-day transfer” embodiment described with reference to FIG. 6, the H record included in the comprehensive transfer data may include a company ID that identifies the company 110. When the reception server 210 is configured to be able to communicate with the bank system 230, the transfer source account is validated when the reception server 210 receives the general transfer data. Alternatively, the information of the transfer source account that has been validated before being transmitted from the transmission server 111 of the company 110 can be set in the general transfer data.

  In step S1102, the transfer processing reception server 212 identifies the transfer designated date of the received general transfer data. As a result of the identification, if the data for general transfer is a request for a transfer on the reception day, the process proceeds to the process of FIG. 6, and if the transfer is requested for the next business day (that is, received one business day before) ), The process proceeds to the process of FIG. 10, and if it is a request for a transfer after two business days (that is, received before two business days or more), the process proceeds to step S1103. The business day refers to the day on which the financial institution operates.

  In step S <b> 1103, the transfer processing reception server 212 transmits the general transfer data to the account confirmation server 214. The account confirmation server 214 reads the received general transfer data on the main storage unit 502 and identifies account information from the D record (transfer details) of the read general transfer data. The identified account information includes at least a bank code, a branch code, a course code, and an account number.

  The account confirmation server 214 makes an account confirmation by inquiring to the integrated ATM 220 whether each of the identified account information is valid. The account confirmation server 214 receives an account confirmation result as to whether or not each account is valid from the integrated ATM 220. The account confirmation result only needs to be able to identify whether each account is valid. For example, it may be message data such as “account information A = OK, account information B = no corresponding account”, or identified. It may be something like an identification flag (data) that can be added to the account information.

  In step S <b> 1104, the account confirmation server 214 generates general transfer data that associates the account information of each D record of the general transfer data with the account confirmation result received from the integrated ATM 220, and transfers the generated general transfer data. It transmits to the process reception server 212. Here, the above-described processing has been described on the assumption that it is executed on the main storage unit 502 of the account confirmation server 214. However, if necessary, a database conforming to the general transfer data format 700 is prepared inside the account confirmation server 214. It may be used.

  The transfer processing reception server 212 reads the general transfer data received from the account confirmation server 214, extracts the normal account confirmation result and generates the general transfer data (normal), and the account confirmation result is an error. Extract some data and generate result reply data. More specifically, the transfer processing reception server 212 generates each T record from the information on the number of transfer destination details and the transfer amount of the extracted D record, and for general transfer data (normal) and result return Generate new data. The result reply data is not limited to a specific format as long as it includes the transfer destination information (if necessary, the reason for the error) resulting in a processing error.

  In step S1105, the transfer processing reception server 212 directly transmits the general transfer data (normal) to the bank system 230 as shown in FIG. The bank system 230 stores the received general transfer data (normal) in the general transfer DB 234.

  In step S <b> 1106, the bank system 230 performs transfer processing on the total transfer data stored in the total transfer DB 234 according to the specified transfer date. As is clear from the processing contents described above, the general transfer data stored in the general transfer DB 234 is data for which the validity of the transfer source account and the transfer destination account has been verified. For this reason, since the occurrence of a transfer process error is very rare, the transfer success rate is improved as compared with the conventional case.

  On the other hand, in step S <b> 1107, the transfer process reception server 212 transmits the result reply data to the company 110.

  In step S <b> 1108, the HULFT server 211 receives comprehensive transfer data including correction data based on the result return data from the transmission server 111 of the company 110. Thereafter, the process returns to step S1101.

  If it is determined in step S1102 that the total transfer data is a request for transfer on the reception day, the process proceeds to the process of FIG. In such a case, the transfer process is performed in accordance with the above-mentioned “Same-day transfer” process flow. That is, the comprehensive transfer data is converted to transfer data each time and transmitted to the common center 120, and after the validity of the transfer destination account is confirmed by the common center 120, the data is transmitted to the bank system 230. It will be processed as a transfer to the bank of the transfer data or to another bank.

  If it is determined in step S1102 that the general transfer data is a request for transfer on the next business day, the process proceeds to FIG. In such a case, the transfer process is performed according to the above-described “reservation transfer” flow. That is, the comprehensive transfer data is converted into transfer data each time and transmitted to the common center 120. After the transfer center account is validated by the common center 120, the data is transmitted to the bank system 230. The bank system 230 converts the received transfer data into comprehensive transfer data each time and then processes the transfer data as a transfer to the own bank or another bank according to the designated transfer date.

  Although the principle of the present invention has been described above with reference to exemplary embodiments, those skilled in the art will appreciate that various embodiments that change in configuration and details can be realized without departing from the spirit of the present invention. Will understand. That is, the present invention can take an embodiment as, for example, a system, apparatus, method, program, or storage medium. In the above description, for the sake of convenience of explanation, the processing executed in each of the plurality of servers has been described. However, the transfer system and the transfer method of the present invention may be executed in one computer device.

DESCRIPTION OF SYMBOLS 110 Enterprise 111 Transmission server 120 Common center 210 Reception server 211 HULFT server 212 Transfer processing reception server 213 Web server 214 Account confirmation server 220 Integrated ATM
230 Bank System 231 EB System 232 Account System 233 Transfer Transfer Details DB
234 general transfer DB
240 Zengin Network 306 General Transfer DB
307 DB for each transfer
308 Data format DB
309 Conversion table 401 Receiving unit 402 Transfer date determination unit 403 Account confirmation unit 404 Generation unit 405 Transmission unit 506 Transfer destination details identification unit 507 Account confirmation unit 508 Association unit

Claims (8)

A transfer system,
Receiving means for receiving the first total transfer data from the user system;
A transfer date determination means for determining a scheduled transfer date from the first comprehensive transfer data;
When the scheduled transfer date indicates a business day after a predetermined business day, each transfer destination account information included in the first general transfer data is extracted, and the validity of each extracted transfer destination account information An account confirmation means for performing inspection by communicating with an integrated ATM, and receiving the result data of the validity check for the respective bank account information from the integrated ATM;
Associating the respective bank account information with the validation result data, identifying only the bank account information determined to have no error based on the associated validation result data, Generating means for generating second comprehensive transfer data including only the transfer destination account information;
Transmitting means for transmitting the second comprehensive transfer data to the bank system, wherein the transfer process using the second comprehensive transfer data is executed by the bank system on the scheduled transfer date. A transfer system characterized by comprising: Only the transfer destination account information determined to have an error based on the result data of the validity check is identified, and the result reply data including only the identified transfer destination account information and indicating the error reason is generated. , Further comprising means for transmitting to the user system,
The transfer system according to claim 1, wherein the third comprehensive transfer data in which the error indicated by the result reply data is corrected by the user system is received again by the receiving unit.   The first and second comprehensive transfer data include at least a header record including transfer source account information and one or more data records including transfer destination account information and transfer amount information. The transfer system described in. The validity check is performed based on the bank code, branch code, item code, and account number of each bank account information,
2. The transfer system according to claim 1, wherein the result data of the validity check indicates any of the presence / absence of an account and a match / mismatch of account numbers for each transfer account information. If the scheduled transfer date does not indicate a business day after the predetermined business day,
A means for generating one or more transfer data from the first general transfer data, the transfer data depending on the number of bank account information included in the first general transfer data The number of transfer source accounts to be used when generating is determined, and the generated data for each transfer further includes means for including real account or dummy account information as transfer source account information,
The transfer data is sent to an external center server,
The center server communicates with the integrated ATM to check the validity of the bank account information,
The transfer system according to claim 1, wherein the transfer data is transmitted to the bank system and stored each time the validity check is executed. The data for each transfer stored in the bank system is converted into data for general transfer, and then transfer processing is executed as data for general transfer.
6. The transfer system according to claim 5, wherein the dummy account is converted into a real account when converted into the general transfer data. A conversion table indicating a conversion account associated with the transfer source account indicated by the first general transfer data;
The transfer system according to claim 5, wherein the dummy account is identified by accessing the conversion table. A transfer method,
Receiving first comprehensive transfer data from a user system;
Determining a scheduled transfer date from the first comprehensive transfer data;
When the transfer date indicates a business day after a predetermined business day, extracting each transfer destination account information included in the first general transfer data;
Performing validation of each extracted payee account information by communicating with an integrated ATM;
Receiving validation result data from the integrated ATM for the respective bank account information;
Associating the respective bank account information with the validation result data;
Based on the result data of the associated validity check, only the transfer destination account information determined to have no error is identified, and second comprehensive transfer data including only the identified transfer destination account information is generated. Steps,
A step of transmitting the second comprehensive transfer data to a bank system, wherein the transfer process using the second comprehensive transfer data is executed by the bank system on the scheduled transfer date; and A transfer method characterized by comprising.

Images