JP2011159053A - Method and system for relaying transaction - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To convert the transfer request data of any unique format other than an All-Banks format into the All-Banks format for processing. <P>SOLUTION: A transfer relay system 1 of a financial institute 2 includes: a conversion rule DB for storing a conversion rule for converting transfer request data created by an unique format in association with the identification information of a client 3; a common verification rule DB for storing a common verification rule for verifying whether necessary data are included in a converted data file; a means for receiving transfer request data including client identification information via a SWIFT(Society for Worldwide Interbank Financial Telecommunication); a means for reading the conversion rule relating to the client from the conversion rule DB, and for converting it into a data file; a means for reading the common verification rule from the common verification rule DB, and for verifying the converted data file; a means for extracting necessary data from the data file, and for generating an electronic file for the All-Banks format; and a means for transmitting the electronic file to a basic system 5. <P>COPYRIGHT: (C)2011,JPO&INPIT

Description

  The present invention relates to a relay method and transaction relay system for funds transfer processing such as a transfer, and more specifically, based on request data such as a transfer in a proprietary format transmitted from a foreign financial institution or customer company, The present invention relates to a method and system for relaying a transaction process of funds transfer so that a Zengin format message can be generated.

  For example, when accepting a request for funds transfer such as a transfer from an overseas customer (a foreign corporation, an overseas branch of a domestic corporation, an individual residing overseas or temporarily staying) (hereinafter referred to as an overseas transfer) Then, a transfer request data file is received from a local financial institution requested by the customer through a SWIFT (Society for Worldwide Interbank Financial Telecommunication) network. Here, SWIFT is an international communication network for exchanging messages such as remittance agreements between financial institutions in each country.

  As SWIFT main services, a FIN (Financial Messaging) service for transmitting and receiving a fixed format electronic message and a File Act service for transferring a large capacity electronic file are prepared. The FileAct service is suitable for distributing a large amount of financial transaction data, and has few restrictions on the item name, data attribute, input policy, etc. of the transfer request data file. Therefore, it is highly convenient for large companies that want to easily request a large number of transfers using their own internal data, and for customers and financial institutions that want to add their own transaction conditions when making a transfer request.

  On the other hand, a domestic financial institution that processes a transfer request using the FileAct service needs to extract necessary data from an electronic file in a unique format to create a Zengin format message. Conventionally, this work has been done by printing the transfer request data file received by the financial institution, and the person in charge visually selects and extracts the items necessary for the Zengin format from among them, such as date, numerical value, text, etc. The remittance request message is created / sent manually, taking into account the data format. In addition, the person in charge confirms the arrangements for each customer and the special notes of the transfer request data file, etc. for the transmission time, the handling of errors, and the response (result report) after the remittance processing is completed.

  In addition, when accepting a transfer request from some customers such as large companies that have established a dedicated line (VPN) with a financial institution (hereinafter referred to as “farm banking”), as with the SWIFT FileACT service described above, A financial institution needs to receive a transfer request data file in a unique format created by a customer (client) and create a message in a Zengin format.

  For example, the following Patent Documents 1 and 2 are helpful as measures for reducing the load of remittance processing involving a plurality of network protocols and preventing human error and data falsification due to human intervention. .

  In Patent Document 1, first, transfer request data such as English is transmitted from the terminal 14 of a customer such as an overseas headquarters of a foreign company in Japan to the conversion server 10. The conversion server 10 refers to a customer database, a transfer destination database, and the like to create all silver transfer request data that conforms to the all silver format, and transmits it to the transfer processing computer 18 of the financial institution. Accordingly, the financial institution can receive the transfer request data in the Zengin format even in the case of a transfer request from overseas, as in the case of a normal transfer.

  Moreover, in patent document 2, the web server 12 and the communication control apparatus 14 are installed in the EB (Electronic Banking) center 11, and the data received by the communication protocol between the customer company 4 and the financial institution 1 is based on the Zengin protocol. The data is converted to transmission data. Accordingly, the financial institution can receive the transfer request data in the Zengin format even in the transfer request via the dedicated line with the customer as in the normal transfer. Moreover, there is no need to develop a dedicated communication program for each customer on the financial institution side and distribute it to the customer, and a transfer processing flow that does not depend on the computer environment (computer specifications, OS version upgrade, etc.) of the customer and the financial institution. Can be built.

JP 2003-006443 A JP 2003-223560 A

  However, in each of Patent Documents 1 and 2 described above, a system dedicated to data conversion (the conversion server 10 and the communication control device 14 of the EB center 11) between the transfer requester (foreign financial institution or customer) and the financial institution. And a web server 12). Therefore, the following new problems arise.

  First, the construction and operation costs and load of a data conversion dedicated system, and the cost and load of installing and managing a secure communication line between the financial institution or the transfer requester and the data conversion dedicated system are newly generated. As a result, even if the current manual burden in financial institutions is reduced, transfer requests from overseas and firm banking do not account for a large percentage of the total number of processed financial institutions. Is not feasible. In particular, it is not realistic for a single financial institution to install and operate a data conversion dedicated system.

  Further, since farm banking is based on a contract between a client company and a financial institution, it is necessary to re-contract a contract with a customer in order to intervene a data conversion dedicated system.

  On the other hand, in order to reduce costs and burdens, when multiple financial institutions jointly set up and operate a data conversion dedicated system (server) or outsource the operation to a public third party, In addition to the problem of individual contracts with customers, it is necessary to clarify the legal responsibility and cost burden between financial institutions and operating entities. Furthermore, since it is necessary to reflect in the system all the internal flows of each financial institution and the processing flow with the customer, the system becomes complicated and stable operation is not easy. In particular, in this case, it is difficult to realize individual responses on the financial institution side based on individual instructions from customers regarding the timing of transfer and reporting of processing results, and customer attributes.

  An object of the present invention is to prepare funds transfer request data in a unique format received via a SWIFT network or a dedicated customer line, and then transfer the data to an existing backbone system in a financial institution, thereby reducing the overall processing load of funds transfer. It is an object of the present invention to provide a transaction relay method and a transaction relay system that can be greatly reduced.

  In order to solve the above problem, a transaction relay method according to the first aspect of the present invention is installed in a financial institution (2) and is connected to a backbone system (5) by a transaction relay system (1). Relay the fund transfer process requested from 3).

  The transaction relay system (1) associates a conversion rule for converting funds transfer request data created in a format different from the Zengin format into a data file of a predetermined file format with the identification information of the client (3). Conversion rule database (18) to be stored and a common verification rule for verifying whether the converted data file contains all data necessary for generating a message format (Zengin format) compliant with the Zengin protocol And a common verification rule database (19) for storing.

  In the method, the file receiving means (23) of the transaction relay system (1) receives, from the requester (3), request data for transferring funds including identification information of the requester (3) (S1). And the file conversion means (24) of the transaction relay system (1) converts the requester (3) from the conversion rule database (18) based on the requester identification information included in the received request data. Steps (S2, S3) for reading the rules and converting the request data into a data file in a predetermined file format, and the verification means (25) of the transaction relay system (1) are shared from the common verification rule database (19). A step (S4, S5) of reading a verification rule and verifying the converted data file; and an electronic file of the transaction relay system (1) When the generating means (29) determines that the converted data file contains all the data required for the Zengin format (S5), it extracts the data necessary for the Zengin format from the data file. The electronic file is created in the backbone system (5) in which the electronic file transmitting means (30) of the transaction relay system (1) generates an electronic message in the whole silver format, and the electronic file transmission means (30) of the transaction relay system (1) creates the electronic file. (S17).

The transaction relay system (1) according to the second aspect of the present invention is connected to the backbone system (5) of the financial institution (2), and executes the relay process of the fund transfer requested by the client (3).
This system (1) stores a conversion rule for converting fund transfer request data created in a format different from the Zengin format into a data file of a predetermined file format in association with the identification information of the client (3). Conversion rule database (18) to be stored, and common verification rules for verifying whether the converted data file contains all the data required to generate the message format (Zengin format) compliant with the Zengin protocol The common verification rule database (19), the file receiving means (23) for receiving the request data for transferring funds including the identification information of the requester (3) from the requester (3), and the received request data Based on the client identification information included, the conversion relating to the client (3) from the conversion rule database (18) File conversion means (24) for reading request data and converting the requested data into a data file of a predetermined file format, and verification means (25) for reading the common verification rule from the verification rule database and verifying the converted data file. When the converted data file is determined to contain all data necessary for the Zengin format, the data file is extracted from the data file to generate an electronic file. An electronic file means (29) and an electronic file transmission means (30) for transmitting the generated electronic file to a backbone system (5) for generating a Zengin-format message are provided.

  According to the present invention, request data such as a transfer in a unique format received via a SWIFT network or a dedicated customer line (VPN) can be prepared and transferred to an existing backbone system in a financial institution. Since the electronic file can be created in a format compliant with the Zengin format, the backbone system can easily and surely create a transaction message in the Zengin format based on the received electronic file. Therefore, the burden on the person in charge of the financial institution can be reduced, and there is no need to construct a system dedicated to data conversion outside the financial institution.

  Further, in a preferred embodiment of the present invention, the requester is divided into a plurality of categories in advance, a waiting time until the generation and / or transmission (relay processing) of the electronic file is set for each category, and the transfer of funds from the requester is performed. When a request is accepted, relay processing is executed at a timing according to the waiting time of the requester. Conventionally, when a fund transfer request is received from a client, the backbone system generates a transaction message and transmits it to the Zengin System. For this reason, when a request for correction or cancellation of the request content is requested from the client at a later date, the work efficiency is reduced due to complicated processing such as correction. In addition, there is a problem in terms of customer service, for example, a predetermined fee is generated even if the funds transfer specified by the client is corrected before the due date.

  Therefore, in a preferred embodiment of the present invention, at an optimal timing for each client according to the occurrence rate of correction based on the transaction status of the client and the customer attribute based on the client's transaction volume and the presence / absence of the contract. The relay processing for the core system can be executed. Here, it is preferable that the classification of the client is set with priority applied in the order of transaction status such as presence / absence of contract, transaction volume, and cancellation rate. Further, it is preferable that the requester category is updated at regular intervals such as monthly or irregularly such as when an event occurs.

It is a network block diagram of the 1st Embodiment of this invention. It is a block diagram which shows schematic structure of the transfer relay system which concerns on the 1st Embodiment of this invention. It is a figure which shows the determination criterion and determination rule of the relay processing execution time for every customer. It is a flowchart which shows the whole process process of the transfer relay method. It is a network block diagram of the 2nd Embodiment of this invention.

  Hereinafter, a system and method according to the present invention will be described in detail with reference to the drawings. In the following, transfer of funds from a domestic account to another account will be described as an example of funds transfer. However, the present invention is not limited to the transfer of funds from a domestic account to a foreign currency account of a foreign financial institution (foreign country). Remittance) etc. are also applicable.

(First embodiment)
FIG. 1 is a network configuration diagram according to the first embodiment of this invention. In this figure, a transfer relay system (transaction relay system) indicated by reference numeral 1 is installed in a domestic financial institution 2 that is a member of SWIFT and conforms to a network (SWIFT Net) that conforms to the SWIFT protocol and the Zengin protocol. Foreign customers 3 that can be connected to SWIFT Net (SWIFT system) and other domestic financial institutions 4 that can be connected to Zengin Net (Zen system) via the network (Zen Bank Net) ) And each can be connected. In this embodiment, it is assumed that a transfer request is received using the SWIFT File Act service.

  The foreign customers 3 include a foreign financial institution 3A and some companies 3B that are members of SWIFT. The transfer request data from any foreign customer 3 is still transmitted through the SWIFT Net. In the following, the foreign financial institution 3A is referred to as a foreign customer 3 or a client 3. In addition, the foreign customer 3 and the other financial institution 4 are actually a transaction request system of the foreign customer 3 (internal dedicated / general purpose computer system) and a transaction processing system of the other financial institution 4, but for convenience of explanation, It is described as foreign customer 3 and other financial institution (financial institution) 4. The client requesting the transfer to the foreign financial institution 3A is a corporation or business individual, and the transfer request is a large number of lump-sum transfers (in general, instructing multiple transfers from the client's account to one or more other accounts) (Transfer) request.

  The transfer relay system 1 is composed of one or a plurality of computers, and an existing core system (a transaction processing system such as an account system or an information system) 5 of a financial institution 2, a gateway server 6, and other related systems. In conjunction with this, the relay processing of the transfer requested by the foreign customer 3 is executed. The transfer relay system 1 may share a part of the function with the backbone system 5 or may be configured as a part of the backbone system 5.

  All the transfer request data created by the foreign customer 3 is temporarily stored in the dedicated queue 8A of the financial institution 2 of the SWIFT Net server 7 installed on the SWIFT Net. The transfer relay system 1 receives the transfer request data via the gateway server 6. The gateway server 6 is installed with a dedicated software (SAG: SWIFT alliance gateway) 9 that is distributed to all SWIFT members from SWIFT administrators (headquarters, domestic branches, etc.) and processes transactions via SWIFT. is doing. The SAG 9 periodically accesses the dedicated queue 8A of the financial institution 2 of the SWIFT Net server 7 and acquires transfer request data addressed to the bank. On the other hand, the result of the transfer process from the financial institution 2 to the foreign customer 3 and the report of the check result of the transfer request data described later are stored in the dedicated queue 8B of the foreign customer 3 by the SAG 9. The foreign customer 3 also receives a result report of the transfer process using the SAG 9 of the own system.

  Here, in the File Act service of SWIFT, a Store & Forward method and a real-time method are prepared as methods for transmitting / receiving transfer request data between a requester (foreign customer 3) and a receiver (financial institution 2). In the Store & Forward system, transaction request data sent to the SWIFT Net by the requesting financial institution is temporarily stored in a queue dedicated to the receiving financial institution, and the receiving financial institution periodically accesses its own queue. The request data is received. The real-time system is a system in which financial institutions on the client side and the receiver side are simultaneously connected to SWIFT Net, and transfer request data is transmitted and received without a time lag. Which method is adopted is left to the requester to select. However, even in the Store & Forward method, since the SAG accesses the dedicated queue in a short cycle of several minutes to several tens of minutes, the transmission side of the transfer request data on the requester side and storage in the queue (Store), the receiver side The time lag until the reception of (Forward) is hardly a problem.

  The transfer relay system 1 of the present embodiment functions as a GCMS (Global Cash Management Service) relay server that relays the backbone system 5 in the financial institution 2 and the SWIFT Net (Gateway server 6). Specifically, the transfer relay system 1 includes a function for converting the transfer request data received via SWIFT into a predetermined format such as CSV, and a necessary item for creating a Zengin format message in the converted data file. A function to check whether or not an error such as data deficiency is found, a function to report to the foreign customer 3 when an error is found, a report of the result of change / cancellation / transfer completion of transfer request data, for creating a transfer message For example, a function for creating and transmitting the electronic file to the backbone system 5 and a function for managing the relay processing execution time for each customer.

  In order to exhibit the various functions described above, the transfer relay system 1 according to the embodiment of the present invention is configured as shown in FIG. In FIG. 2, only a necessary functional configuration is shown assuming a single computer system. However, the transfer relay system 1 may be configured as a part of a multi-function distributed system including a plurality of computer systems. it can.

  In the transfer relay system 1, a RAM 13, an input device 14, an output device 15, a communication control device 16, and a storage device 17 including a nonvolatile storage medium (ROM, HDD, etc.) are connected to a CPU 11 via a system bus 12. Have a configuration. The storage device 17 includes a program storage area for storing a software program for performing the above-described functions, and a data storage area for storing acquired data, data as a processing result, and the like. Each means of the program storage area described below is actually an independent software program, its routine, component, etc., which is called from the storage device 17 by the CPU 11 and expanded in the work area of the RAM 13 while appropriately referring to the database and the like. Each function is performed by being executed sequentially.

  The data storage area includes a conversion rule database (DB) 18, a common verification rule database (DB) 19, a specific verification rule database (DB) 20, and a relay process execution time database (DB) 21. Both are fixed storage areas secured in the storage medium 17.

  The conversion rule DB 18 associates a conversion rule for converting transfer request data in a client data format different from the Zengin format into a data file of a predetermined file format preset by the financial institution 2 with the identification information of the client. Store. The predetermined file format is a format that can verify, extract, and process data items, such as CSV, fixed length, and XML. This file format includes both the software and hardware environment of the computer system of the financial institution 2 functioning as the transfer relay system 1 and the format of the SWIFT transfer request data (requester data format) that differs for each client (customer). Is set in consideration of

  The requester data format is not suitable for automatic processing as it is because the requester has a high degree of freedom. For example, if it is a transfer request data, the requester's bibliographic information and account identification information, the transferee's bibliographic information and account Information necessary for a series of transfers such as specific information, transfer amount, transfer designated date, bibliographic information of the financial institution in charge is always included. For this reason, the required information is included in which item name of the transfer request data, in what data format (text, number, date, etc.) is entered, and what policy is used to enter the data. By sharing a rule such as whether or not such information with the foreign customer 3 in advance, it becomes possible to identify and extract essential information easily and reliably. The conversion rule can be set in a different file format for each client or country, and conversely, it can be unified for all clients based only on the environment of the financial institution 2. In the latter case, it is not necessary to associate the conversion rule with the requester's identification information.

  The common verification rule DB 19 uses all the requesters (request data) for verifying whether the converted data file includes all data necessary for generating a message format (Zengin format) conforming to the Zengin protocol. ) To store common verification rules. For example, the bibliographic information and account information of the transfer requester, the transfer amount and the designated transfer date, the bibliographic information and account information of the recipient, and the like.

  The unique verification rule DB 20 stores a format verification rule unique to the client, which is determined in advance between the client 3 and the financial institution 2 and is different from the common verification rule, in association with the identification information of the client 3. For example, in the case of requester 3 requesting (processing) a plurality of items in a lump sum, the total amount of transfer and the total amount for each of multiple payees must be clearly indicated in a specific field, and the requester and the recipient negotiate. It is assumed that the client 3 has previously instructed the financial institution 2 to include the transaction number, membership number, country code, etc. in the client's column (JP111 YAMADA TARO, etc.). In such a case, whether the instruction field itself is included in the transfer request data or whether the instruction field includes instruction information (not blank) is set as a specific verification rule. Since such a unique verification rule is closely related to the client data format for each client as described above, it is preferable that the verification rule is determined and stored in advance as a set with the client data format.

  In this embodiment, the notification format of the verification result of the common verification rule and the specific verification rule (multiple batch report, report by transfer destination, report for each report, report form, etc.) and notification timing (weekly, monthly, The instruction information of the client 3 including “immediately” is also acquired from the client 3 in advance and stored in the unique verification rule DB 20. If errors such as missing or incomplete data are found as a result of verifying the common verification rules and specific verification rules, even if the minimum required transfer data such as bibliographic items is available None), cannot transfer as requested. Therefore, whenever an error is found, the client 3 is notified of the error. That is, the instruction information of the requester 3 does not include the necessity of error reporting (instruction not to report). As a result of the verification, if the data is complete, the requester can specify whether to report separately from the transfer completion report. The error report preferably includes items such as missing data, incomplete data, and the reason for the error.

  When receiving the transfer request data, the relay processing execution time DB 21 immediately executes generation of an electronic file for generating a message and / or transmission of the electronic file to the backbone system 5 (relay processing), or a predetermined process. Information on the execution timing of the relay process regarding whether to execute after the standby time has elapsed is stored in association with the identification information of the requester.

  Specifically, the relay process execution time information includes the date when the electronic file is generated from the receipt of the transfer request data, or the date when the generated and stored electronic file is transmitted to the core system 5 , Information. Waiting time or relay processing execution time is what kind of viewpoint the financial institution uses from the receipt of the transfer request data to the transfer instruction date set by the requester (several hours to a few weeks) It is an internal problem. From the viewpoint of ensuring the certainty and safety of the transaction, it is preferable that when the transfer request data is received from the requester 3, an electronic file is promptly created and transmitted to the backbone system 5. When the backbone system 5 receives data for generating a message (conventional transfer request data, the electronic file of the present embodiment, etc.), it quickly generates a transaction message and transmits it to Zengin Net.

  On the other hand, if an electronic file is immediately generated and transmitted to the backbone system 5, if the requester (foreign customer 3) is notified of a change in transfer request data or cancellation of the request, the financial institution 2 In this case, complicated processing such as transaction change or cancellation occurs, and the requester 3 may incur a cancellation fee. It is not preferable to set a uniformly long standby time (a period during which cancellation or the like can be easily performed) for all customers and transfer requests from the viewpoint of the certainty and safety of the transaction described above.

  Therefore, in this embodiment, by setting a standby time (electronic file creation / transmission time) for each customer based on objective statistical data, customer attributes, requests, etc., both customer service and business efficiency are achieved. It was to be.

  Specifically, the financial institution 2 classifies the requester (foreign customer) 3 into a plurality of requester categories according to predetermined conditions, and stores the relay processing execution time set based on this category in the relay processing execution time DB 21. Decided to do. The predetermined conditions for classifying the client 3 are, for example, the amount of transactions with the financial institution 2 within a certain period in the past (number, total amount, average amount, presence / absence or amount of a specific type of transaction), and a certain period in the past The number or rate of inability to process funds transfer requests within the company, the number or rate of change of request data after receiving a transfer request within a certain period in the past, and the request after accepting a transfer request within a certain period in the past It is preferable to include a criterion based on statistical data of at least one of the number of cancellations or the cancellation rate.

  For example, in the present embodiment, as shown in FIG. 3A, whether there is a special provision regarding the execution timing of the relay process in the contract with the customer who is the transfer requester (standard 1), All customers are classified into four stages A to D according to the customer classification (standard 2) set based on the transaction volume with the financial institution 2 and the cancellation rate of transfer requests within a certain period (standard 3). ing. The cancellation rate includes a change (rate) of the request contents.

  In this embodiment, priorities are set in the order of standards 1 to 3, and it is determined whether or not the order is satisfied in the order of standards 1 to 3 when categorizing customers. For each classification, the time (waiting time) from receiving the transfer request (receiving transfer request data) to executing the relay process (sending the electronic file to the core system) is 1 business day before that day, 2 business days ago, set immediately. On that day, on the day of the designated transfer date, 1 (2) business days before, 1 (2) business days before the designated transfer date, and immediately, on that day (or the next business day) the electronic file is created Then, it is transmitted to the basic system 5. That is, the waiting time is the longest on the day, and the waiting time is substantially zero immediately. As will be described later, the customer data and the cancellation rate are updated monthly by collecting the statistical data based on them.

  FIG. 3B shows the result of determining each customer based on such criteria. The customer of W000 in FIG. 3B is an excellent customer although there is no special contract, so it is determined as category A (process on the day of the designated transfer date) regardless of the statistical data. Note that “−” in the statistical data column indicates that data has not been acquired (updated). The customers of X111 to Y222 are determined as the sections B to D according to the statistical data. On the other hand, the customer of Z333 is classified as Category C based on the statistical data, but is determined as Category D (immediate processing) because the existence of the special provisions has priority.

  Returning to FIG. 2, the software programs stored in the program storage area enumerate only those related to the present invention, and transfer request data reception means (file reception means) 23, file conversion means 24, verification means 25, A report output unit (verification result notification unit) 26, a standby time search unit 27, a relay process execution time monitoring unit 28, an electronic file generation unit 29, an electronic file transmission unit 30, and a customer category update unit 31 are provided.

  The transfer request data receiving means 23 generates transfer request data from the requester 3 (foreign customer) in a requester data format different from the Zengin format and including identification information (SWIFT code, customer ID, etc.) of the requester 3. It has a function of receiving from the gateway server 6. The transfer request data includes the bibliographic information and account information of the transfer requester, the bibliographic information and account information of the recipient, information required for the transfer process, such as the transfer amount and designated transfer date, the total transfer amount, and the total amount for each transfer destination. , Handling of transfer fees, and information specific to the client such as a report form after completion. Further, in the comprehensive transfer of the present embodiment, the information on the transfer requester is common, and the recipient information and the like are included for the number of transfers.

  Based on the identification information of the requester 3 included in the received transfer request data, the file conversion unit 24 reads the conversion rule relating to the requester 3 from the conversion rule database 18 and converts the transfer request data into a predetermined file format such as CSV. It has a function to convert to a data file. Since the requester data format has a high degree of freedom for the creator (requester), it is difficult to verify the data and create a message in the Zengin format as it is. Therefore, as a premise for automating these processes, it is necessary to convert the file format so that the received transfer request data can be automatically verified and edited (processed) by the computer system.

  The verification unit 25 has a function of verifying the converted data file in accordance with a common verification rule common to all clients and a specific verification rule specified in advance by a specific client. The former common rule verification function is a function that reads a common verification rule from the common verification rule DB 19 and verifies whether the converted data file is complete with information necessary for a transfer message in the Zengin format. The latter specific verification rule verification function determines whether or not a requester specific verification rule is registered in the specific verification rule DB 20 based on the client identification information, and if the specific verification rule is registered, the specific verification rule Is a function for verifying whether the data file has a complete format designated by the client 3. The specific format to be instructed includes the above-described transaction number, member number, country code, etc. included in the requester column.

  The report output means 26 is a function for notifying the requester of the verification result of the common verification rule and the specific verification rule according to the instruction information of the requester 3 stored in the specific verification rule DB 20. For any of the verification rules, if a deficiency is found, transfer as instructed cannot be performed, so the deficient data found without performing the transfer process is clearly reported.

  The waiting time search means 27 is a function for searching the requester's relay processing execution time (waiting time) from the relay processing execution time DB 21 based on the requester identification information included in the received transfer request data. As described above, the waiting time of the client is set according to customer categories A to D.

  The relay processing execution time monitoring means 28 is a function for setting the searched relay processing execution time in a memory or the like and monitoring whether the relay processing execution time has arrived using functions such as a real time clock and a CPU clock of the computer. is there. When the arrival of the relay processing execution time is detected, the CPU 11 is notified.

  The electronic file generation unit 29 extracts data necessary for the Zengin format from the data file when it is determined that the converted data file is complete in both the common verification rule and the specific verification rule. This is a function for generating an electronic file for generating a message. When the standby time is searched by the standby time search unit 27, the electronic file generation unit 29 holds the generated electronic file in an unprocessed queue (not shown) or the like, and the relay process execution timing monitoring unit 28 waits. When the end of time (the arrival of the relay processing execution time) is detected, the electronic file is taken out from the unprocessed queue and transferred to the electronic file transmission means 30. Note that only data extraction may be executed immediately and held in an unprocessed queue, and an electronic file may be generated when the relay processing execution time comes.

  The electronic file transmission unit 30 has a function of receiving the electronic file generated from the electronic file generation unit 29 and transmitting it to the backbone system 5. When the standby time is set and the electronic file generation unit 29 immediately generates and transmits an electronic file, the electronic file transmission unit 30 stores the electronic file in an unprocessed queue and performs relay processing. When the execution time comes, the electronic file is taken out and transmitted to the backbone system 5.

  The customer category update means 31 performs relay processing according to the above-mentioned conditions at a predetermined cycle (monthly, semi-annual, etc.) or when a specific event occurs (requester's settlement period, every transaction number break, contract renewal, etc.) This is a function for updating the customer classification in the execution time DB 21. As described above, the client 3 whose relay processing execution time is set by the contract (special agreement) between the financial institution 2 and the client 3 is excluded from the update target based on the statistical data such as the cancellation rate. Is preferred. In addition, when an event occurs, it is preferable to update the customer category only for the relevant requester.

  Next, processing steps of the transfer relay method according to the present embodiment will be described with reference to the flowchart of FIG. Note that the update of the customer category is omitted.

  First, the transfer request data receiving means 23 of the transfer relay system 1 receives transfer request data from the requester (foreign customer) 3 via the SWIFT Net server 7 and the Gateway server 6 (S1). When the data is received, the file conversion means 24 is activated, and the conversion rule of the requester 3 is specified from the conversion rule DB 18 based on the requester identification information such as the SWIFT code and customer ID included in the transfer request data. (S2), the transfer request data is converted into a predetermined format such as CSV (S3). As a result, processing such as subsequent verification (error check) and data extraction becomes possible.

  Next, the verification means 25 first verifies the converted data file with verification rules common to all customers (S4). Specifically, in order to create a transfer message in the Zengin format, it is checked whether all necessary data is included.

  If the essential data is complete (Yes in S5), the verification unit 25 continues to search the specific verification rule DB 20 for whether the specific verification rule of the client 3 is registered (S6). When the unique verification rule is registered (Yes in S6), the unique verification rule is read to verify the converted data file (S7). At this stage, the transfer format instructed in advance by the client and the input policy for each data item are checked. If the unique verification rule is complete (Yes in S8), the electronic file generation means 29 is instructed to generate an electronic file (S9).

  On the other hand, in step S5 and S8, when a deficiency of data is detected with respect to any of the verification rules (No in S5, No in S8), the report output means 26 receives the request from the client 3 from the specific verification rule DB20. A notification format of the verification result is specified (S10), and an error report according to the instruction is executed (S11).

  When the electronic file is generated in step S9, the standby time search unit 27 searches the relay process execution time DB 21 for the relay process execution time of the client 3 (S12). If the relay process execution time is “immediately”, that is, if the waiting time is 0 (Yes in S13), the electronic file transmitting means 30 immediately transmits the generated electronic file to the backbone system 5 (S17).

  On the other hand, when the relay process execution time is set to something other than immediate (No in S13), the standby time search unit 27 sets the registered relay process execution time in the monitoring target field such as a memory (S14). ), The relay process execution time monitoring means 28 starts monitoring (S15). At this time, the electronic file generated by the electronic file generation unit 29 is temporarily stored in an unprocessed queue (not shown). When the relay process execution time monitoring unit 28 detects the arrival of the relay process execution time (end of the standby time) (Yes in S16), the CPU 11 instructs the electronic file transmission unit 30 to transmit an electronic file. The electronic file transmission means 30 takes out the electronic file from the unprocessed queue and transmits it to the backbone system 5 (S17). As described above, the electronic file for generating a message is held in the transfer relay system 1 different from the core system 5 until the relay processing execution time comes. Therefore, even if a change or cancellation is instructed by the client 3 during that time, it can be easily dealt with by erasing data. In addition, since the relay processing execution time is set in a plurality of stages according to the requester's attributes and contracts, the request of the requester can be satisfied while maintaining the safety and certainty of the transaction.

  When the backbone system 5 that has received the electronic file creates a message and receives a notice of Zengin Net reception from the backbone system 5, the report output means 26 is activated and the report of the client 3 stored in the unique verification rule DB 20. The format is searched (S18). When the completion report is required (Yes in S19), the report output means 26 creates a processing result report file in the registered report format and transmits it to the Gateway server 6 (S20). The gateway server 6 uses the SAG 9 to store the report file in the foreign customer dedicated queue 8b of the SWIFT Net server 7.

  If the requester 3 instructs that the completion report is not required (No in S19), a request is made by creating a standard report in the default cycle of the financial institution 2 in a format common to all customers of the financial institution 2. To the third party.

  Thus, the transfer relay process is completed.

(Second Embodiment)
Next, a second embodiment of the present invention will be described with reference to FIG. FIG. 5 is a network configuration diagram showing the second embodiment. The same components as those in the first embodiment are denoted by the same reference numerals, and redundant description is omitted.

  In this embodiment, the transfer relay system 40 receives transfer request data created in a unique format of the customer 41 from a customer 41 such as a specific company connected to the financial institution 2 via a dedicated line (VPN: Virtual Private Network). It has the feature in the point of receiving. The basic function of the transfer relay system 40 is the same as that of the first embodiment.

  Also in this embodiment, a file conversion rule based on the unique format of the customer 41 is registered in the conversion rule DB 18 in association with the identification information of the customer 41, and the transfer request data received from the customer 41 through the dedicated line is converted into the conversion rule. Convert according to the rules. Subsequent functions of verification of the converted data file (common verification rule and), error report, setting and specification of relay processing execution time (waiting time), creation and transmission of the electronic file for telegrams are the first functions described above. This is the same as the embodiment.

  The present invention is not limited to the above-described embodiment, and various modifications and changes can be made without departing from the spirit of the present invention.

  For example, in each of the above-described embodiments, the transfer request data from the client is received via a SWIFT Net or a dedicated line (VPN), but is received via another network or via a plurality of networks. In this case, the present invention can be suitably implemented.

  Further, the electronic message may be transmitted to the Zengin network via a bank ANSWER (Automatic answer Network System for Electrical Request), without being limited to the case where the electronic message is directly transmitted from the basic system to the Zengin network. Here, the bank ANSWER is a computer communication service specialized for financial transactions provided by NTT DATA Corporation. A customer (requester) can directly request financial transaction procedures such as transfer and balance inquiry from an exclusive terminal of the company to an ANSWER center connected to a core system of a financial institution by using a bank ANSWER.

  The present invention can also be applied to funds transfer processing other than transfer. However, those skilled in the art will recognize that specific examples such as a common verification rule, a specific verification rule, and a report form differ depending on the type of processing. Can be easily understood.

  Further, when the transfer destination is another account in the bank, the destination financial institution 2 and the destination financial institution 5 are the same, and it is possible to respond more flexibly than the transfer to the other bank.

  Also, even if the customer has a relay processing execution time (standby time), if the number of days until the designated transfer date is shorter than the standby time, the transfer may be executed without waiting for the waiting time to elapse. preferable. For this purpose, when the transfer request is received, the transfer request data receiving means or the waiting time search means determines the expiration date of the relay processing execution time (such as 2 business days before) of the customer (requester) and the designated date of transfer. It is preferable to store the earlier date in the relay process execution time DB as the relay process execution time (yyyy year mm month dd day).

1 Transfer relay system (transaction relay system)
2 Financial institutions (for destination)
3. Client (foreign customer)
4 Financial institution for customer 5 Core system 6 Gateway server 7 SWIFT Net server 8a, 8b Dedicated queue 11 CPU
12 System bus 13 RAM
14 input device 15 output device 16 communication control device 17 storage device 18 conversion rule DB
19 Common verification rule DB
20 Specific verification rule DB
21 Relay processing execution time DB
23. Transfer request data receiving means (file receiving means)
24 File conversion means 25 Verification means 26 Report output means 27 Standby time search means 28 Relay processing execution time monitoring means 29 Electronic file generation means 30 Electronic file transmission means 31 Customer category update means 40 Transfer relay system 41 Company (customer)

Claims (11)

A method of relaying a process of transferring funds requested by a client by a transaction relay system installed in a financial institution and connected to a core system,
The transaction relay system stores a conversion rule for converting fund transfer request data created in a format different from the Zengin format into a data file of a predetermined file format in association with the client's identification information And a common verification rule database for storing a common verification rule for verifying whether the converted data file includes all data necessary for generating a message format (Zengin format) compliant with the Zengin protocol. Prepared,
The method
The file receiving means of the transaction relay system receives, from the requester, fund transfer request data including identification information of the requester;
Based on the requester identification information included in the received request data, the file conversion means of the transaction relay system reads the conversion rule relating to the requester from the conversion rule database and converts the request data into a data file in a predetermined file format. Converting to
A verification unit of the transaction relay system reads a common verification rule from the common verification rule database and verifies the converted data file;
If the electronic file generation means of the transaction relay system determines that the converted data file contains all the data necessary for the Zengin format, the data necessary for the Zengin format is extracted from the data file. Extracting and generating an electronic file for generating a transaction message in Zengin format;
The electronic file transmission means of the transaction relay system includes the step of transmitting the generated electronic file to a transaction processing system that generates a transaction message in a Zengin format. The client is a customer who requests the transfer of funds from his / her Japanese yen account to another account, or a foreign financial institution that has received a request for transfer of funds from this customer, and is a SWIFT (Society for Worldwide Interbank Financial). Telecommunication) client who can use the line (hereinafter collectively referred to as “foreign customers”)
The method according to claim 1, wherein the receiving step receives fund transfer request data from the foreign customer via a SWIFT line. The requester is a specific customer laying a dedicated line individually with a financial institution,
The method according to claim 1, wherein the receiving step receives fund transfer request data via a dedicated line with the customer. The transaction relay system further includes a unique verification rule database for storing a requester-specific verification rule different from the common verification rule with respect to a format of request data for funds transfer in association with identification information of the requester,
The method of claim 1, wherein the verifying step verifies the converted data file according to the common verification rule and the unique verification rule. The unique verification rule database further stores the requester's instruction information including the necessity of notification of the verification result and the notification time in association with the identification information of the requester
In this method, the verification result notifying means of the transaction relay system notifies the requester of the verification result of the common verification rule and / or the specific verification rule according to the instruction information of the requester stored in the specific verification rule database. The method of claim 4, further comprising a step. Whether the transaction relay system further executes generation and / or transmission of electronic files (hereinafter referred to as “relay processing”) upon receipt of fund transfer request data, or after a predetermined waiting time has elapsed. A relay process execution time database for storing the relay process execution time related to the identification information of the requester,
The method according to claim 1, wherein the electronic file generation step and / or the electronic file transmission step execute the relay processing when the relay processing execution time comes. The relay processing execution time database stores relay processing execution times set based on a plurality of requester categories in which the financial institutions classify requesters according to predetermined conditions,
This method
A standby time search means of the transaction relay system, based on requester identification information included in the received fund transfer request data, identifying the requester's relay processing execution time from the relay processing execution time database; ,
The method according to claim 6, further comprising: a step of monitoring whether the specified relay processing execution time has arrived. The requester category update means of the transaction relay system further comprises a step of updating the requester category of the relay processing execution time database for at least some of the requesters according to a predetermined condition when a predetermined event or a specific event occurs. The method according to claim 7, wherein:   The predetermined conditions for classifying the requester include the amount of transactions with a financial institution within a fixed period in the past, the number of unprocessable cases or unprocessable rates regarding requests for funds transfer within a fixed period in the past, Based on statistical data of at least one of the number or rate of change of request data after accepting requests for funds transfer within the period and the number or rate of request cancellations after accepting requests for funds transfer within a certain period in the past The method of claim 7 including a criterion.   The method according to claim 9, wherein the updating step excludes a requester whose relay processing execution time is set by a contract with a financial institution from being updated based on a standard based on the statistical data. A transaction relay system that is connected to a core system of a financial institution and relays a process of transferring funds requested by a client.
A conversion rule database for storing a conversion rule for converting funds transfer request data created in a format different from the Zengin format into a data file of a predetermined file format in association with the identification information of the requester;
A common verification rule database for storing a common verification rule for verifying whether the converted data file includes all data necessary for generating a message format (Zengin format) compliant with the Zengin protocol;
File receiving means for receiving fund transfer request data including identification information of the requester from the requester;
Based on the client identification information included in the received request data, a file conversion unit that reads a conversion rule related to the client from the conversion rule database and converts the request data into a data file of a predetermined file format;
Verification means for reading the common verification rule from the common verification rule database and verifying the converted data file;
If it is determined that the converted data file contains all the data necessary for the Zengin format, data necessary for the Zengin format is extracted from the data file, and a transaction message in the Zengin format is extracted. Electronic file generation means for generating an electronic file for generation;
An electronic file transmission means for transmitting the generated electronic file to a transaction processing system for generating a transaction message.

Images