Program, bank API connection method, and user terminal

Abstract

To enable a user who uses a plurality of banks to execute a transfer request without being aware of each bank API.SOLUTION: The present disclosure is a program for implementing, in a computer, a transmission unit (51) for transmitting transfer request information including parameters of predetermined items related to a bank API necessary for the processing of the transfer request by a predetermined bank among all items related to the common API, to the bank core system of the predetermined bank based on the input of parameters of items lacking in the transfer request created in a predetermined format among the items related to the common API covering each bank API necessary for the processing of the transfer request by each bank.SELECTED DRAWING: Figure 12

Description

[Technical field]

[0001] The present disclosure relates to a program, a bank API connection method, and a user terminal. [Background technology]

[0002] In recent years, a bank API has been proposed, which applies API (Application Programming Interface), a mechanism for opening up parts of software so that its functions can be linked to other software, to banking operations. By banks providing internet banking functions through bank APIs, companies can use the internet to link their business systems (accounting software) with bank account data. However, various issues arise when companies actually implement a linking system.

[0003] For example, while bank API specifications are often made public, in addition to understanding the complex specifications, company personnel must also understand the characteristics of banking operations, which places a burden on the personnel in charge at the company. In addition, because bank APIs cannot be executed using existing business systems as is, new programs must be developed to link with each bank. Furthermore, many operational considerations must be made, such as the management of authorization information, consideration of how to operate bank accounts, and recovery measures in the event of a failure.

[0004] To address this issue, software has been provided that links a company's business system with a bank API (see Non-Patent Document 1). [Prior art documents] [Non-patent literature]

[0005] [Non-Patent Document 1] Bank API connection software "BankingGate API-X"<https: / / www.nikkei.com / article / DGXLRSP510864_Q9A530C1000000 / > Summary of the Invention [Problem to be solved by the invention]

[0006] However, in the conventional method, when a user (such as a company) makes a transfer request to a bank where the user has a bank account, the user uses the bank API of the bank's core system provided by each bank. Since the specifications of the bank APIs provided by each bank are different, the user must be aware of each bank's API and build a system on the user side that is in line with the specifications of each bank, which requires time and money to build this system.

[0007] The present invention has been made in consideration of the above circumstances, and has an object to enable a user who uses multiple banks to execute a transfer request without being aware of each bank's API. [Means for solving the problem]

[0008] The invention of claim 1 is a program that causes a computer to realize a sending unit that sends transfer request information including parameters of specified items related to bank APIs that are necessary for the specified bank to process the transfer request, out of all items related to a common API that covers each bank API necessary for each bank to process the transfer request, to the bank core system of a specified bank, based on input of parameters of items that are missing in a transfer request case created in a specified format, out of each item related to the common API. Effect of the Invention

[0009] As described above, the present invention has the effect of allowing a user to execute a transfer request without being aware of each bank API. [Brief description of the drawings]

[0010] [Figure 1] 1 is a diagram showing the overall configuration of a transfer system according to an embodiment of the present invention; [Diagram 2]FIG. 2 is a hardware configuration diagram of a user terminal and a bank core system according to the present embodiment. [Diagram 3] FIG. 2 is a functional configuration diagram showing functions of a user terminal. [Figure 4] FIG. 13 is a conceptual diagram of a transfer method management DB. [Diagram 5] FIG. 11 is a sequence diagram showing the process of requesting lump-sum transfer in this embodiment. [Figure 6] (a) is a conceptual diagram of parameters of input items in the all-banks format, (b) is a conceptual diagram of parameters of management items of the common API, (c) is a conceptual diagram of parameters of required items of API specific to Bank X, and (d) is a conceptual diagram of parameters of required items of API specific to Bank Y. [Figure 7] In this embodiment, (a) is a conceptual diagram of a lump-sum transfer details file, and (b) is a conceptual diagram of a full transfer request result file. [Figure 8] 13 is a flowchart showing a process for identifying necessary items of a bank-specific transfer request. [Figure 9] A sequence diagram showing the processing of a transfer registration request and a transfer approval request. [Figure 10] 13 is a flowchart showing the process of storing and reading each transfer result. [Figure 11] FIG. 13 is a sequence diagram showing the process of a transfer execution request. [Figure 12] FIG. 11 is a sequence diagram relating to another embodiment, showing a case where a common API is read out for a transfer request case. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0011] Hereinafter, an embodiment of the present invention will be described with reference to the drawings.

[0012] [System Configuration] First, the overall configuration of a transfer system 1 of this embodiment will be described with reference to Fig. 1. Fig. 1 is a diagram showing the overall configuration of a transfer system according to an embodiment of the present invention.

[0013] 1, the transfer system 1 of this embodiment is constructed by a user terminal 2, a bank core system 7x, and a bank core system 7y. The user terminal 2, the bank core system 7x, and the bank core system 7y can communicate with each other via a communication network 100 such as the Internet. The communication may be wired or wireless.

[0014] In Fig. 1, a user terminal 2 is a user's computer installed at the user requesting a transfer (Company A). Accounting software 3 and bank API (Application Programming Interface) connection software 5 are installed on the user terminal 2. The accounting software 3 and bank API connection software are programs that cause a computer to execute each function.

[0015] Bank core system 7x is a computer installed in Bank X, and processes transfers and the like. Similarly, bank core system 7y is a computer installed in Bank Y, and processes transfers and the like. Although only one user terminal 2 is shown in FIG. 1, multiple terminals may be used. Also, the transfer requester may be multiple companies, not just Company A. Furthermore, the number of banks may be three or more, not just two, and in this case, each bank has its own bank core system.

[0016] In addition, hereinafter, the bank core system 7x and the bank core system 7y will be collectively referred to as the "bank core system 7."

[0017] Company A makes a transfer request to a specified bank via Bank X or Bank Y where Company A has a bank account. At this time, the bank API connection software 5 enables Company A to execute the transfer request without being aware of the bank APIs provided by Bank X and Bank Y. The bank API connection software 5 will be explained in detail later.

[0018] [Hardware configuration of this embodiment] Next, the hardware configuration of the user terminal 2 and the bank core system 7 will be described with reference to Fig. 2. Fig. 2 is a diagram showing the hardware configuration of the user terminal and the bank core system.

[0019] 2, the user terminal 2 includes a processor 201, a memory 202, an auxiliary storage device 203, a connection device 204, a communication device 205, and a drive device 206. The hardware components constituting the user terminal 2 are connected to each other via a bus 207.

[0020] The processor 201 serves as a control unit that controls the entire user terminal 2, and includes various arithmetic devices such as a CPU (Central Processing Unit). The processor 201 reads out various programs related to the accounting software 3 and the bank API connection software 5 onto the memory 202 and executes them. The processor 201 may include a GPGPU (General-purpose computing on graphics processing units).

[0021] The memory 202 has a main storage device such as a Read Only Memory (ROM) and a Random Access Memory (RAM). The processor 201 and the memory 202 form a so-called computer, and the processor 201 executes various programs read onto the memory 202, causing the computer to realize various functions.

[0022] The auxiliary storage device 203 stores various programs and various information used when the processor 201 executes the various programs.

[0023] The connection unit 204 is a connection device that connects an external device (eg, a display device 210, an operation device 211) and the user terminal 2.

[0024] The communication unit 205 is a communication device for transmitting and receiving various types of information to and from other units.

[0025] The drive device 206 is a device for setting the recording medium 230. The recording medium 230 here includes media that record information optically, electrically, or magnetically, such as a CD-ROM (Compact Disc Read-Only Memory), a flexible disk, a magneto-optical disk, etc. The recording medium 230 may also include semiconductor memories that record information electrically, such as a ROM (Read Only Memory), a flash memory, etc.

[0026] The various programs to be installed in the auxiliary storage device 203 are installed, for example, by setting the distributed recording medium 230 in the drive device 206 and reading out the various programs recorded in the recording medium 230 by the drive device 206. Alternatively, the various programs to be installed in the auxiliary storage device 203 may be installed by being downloaded from a network via the communication device 205.

[0027] FIG. 2 also shows the hardware configuration of the bank core system 7. However, since the components are the same and only the reference numbers have changed from the 200s to the 700s, a description of these components will be omitted.

[0028] [Functional configuration of this embodiment] Next, the functional configuration of the user terminal 2 at company A will be described with reference to Fig. 3. Fig. 3 is a diagram showing the functional configuration of the user terminal.

[0029] As described above, the accounting software 3 and the bank API connection software 5 are installed on the user terminal 2.

[0030] The bank API connection software 5 can realize, as the functions of the user terminal 2, a transmission / reception unit 51, a division unit 52, an identification unit 53, a judgment unit 55, a complementation unit 56, an output unit 58, and a storage / readout unit 59.

[0031] Furthermore, the user terminal 2 has a storage unit 5000. The storage unit 5000 is realized by a memory 502 or an auxiliary storage device 503. The storage unit 5000 stores monitoring folders F1, F2 and an output folder F30, and has a transfer method management DB (Data Base) 5001 and a temporary storage unit 5002 constructed therein. Note that while two monitoring folders are shown in Figure 3, there may be three or more. In the following, the management folders F1, F2 will be collectively referred to as "monitoring folder F".

[0032] The monitoring folder F is a folder for saving a lump-sum transfer detail file (FIG. 7(a)) created by the accounting software 3 in a format established by the Federation of Japanese Bankers Associations for data transmission (hereinafter referred to as the "All-Bank Format"). The monitoring folder F does not have to be stored in the storage unit 5000, and may be stored in a computer other than the user terminal 2 as long as the bank API connection software 5 can access it.

[0033] Furthermore, monitoring folder F is associated with transfer method management DB 5001 (Fig. 4) by a connection code. The Zengin format is indicated by the required items (parameters) for transfer requests defined by the Japanese Bankers Association, as shown in Fig. 6(a). Note that Fig. 6(a) is a conceptual diagram of parameters for input items in the Zengin format format, (b) is a conceptual diagram of parameters for management items in the common API, (c) is a conceptual diagram of parameters for required items in API specific to Bank X, and (d) is a conceptual diagram of parameters for required items in API specific to Bank Y. The common API is an API that covers all the items related to each bank's API that are necessary for processing transfer requests at each bank.

[0034] The output folder F30 is a folder for finally saving all transfer request results (Figure 7(b)).

[0035] The transfer method management DB 5001 is a DB for managing transfer methods. As shown in FIG. 4, the transfer method management DB 5001 manages the connection code, tenant name, the name of the transferring bank on the tenant side, the transfer request method, and parameters of complementary items related to the transferring bank's unique API in an associated manner. Of these, the connection code is a code indicating the combination of the tenant (user Company A, etc.) that is the transfer requester and the specified bank that is the transferring bank on the tenant side. The connection code is an example of specific information for identifying the combination of the tenant (name) and the transferring bank (name) on the tenant side. The connection code may also be indicated as a tenant ID.

[0036] The transfer request method indicates a transfer request method specific to each bank. "Registration and approval" is a method for making a transfer request from user terminal 2 to bank X in Fig. 1, for example, and requires user terminal 2 to make two transfer requests, one for registering the transfer request and the other for approving it.

[0037] 1 from the user terminal 2, and from the user terminal 2's perspective, it is a method in which only one transfer request is required for registering the transfer request and approving the transfer request. In this case, the bank core system 7y of the bank Y registers and approves the transfer request at the same time.

[0038] Furthermore, the supplementary items related to the unique API of the transferring bank indicate the items that are supplemented because the required items in the all-banks format alone are not sufficient to accommodate the unique API of the transferring bank, and the parameters to be supplemented are managed by the supplementation unit 56 described below.

[0039] <Each function configuration> Next, each functional configuration will be described.

[0040] The transmitting / receiving unit 51 transmits data (information) to the bank core system 7 and receives data (information) from the bank core system 7. For example, the transmitting / receiving unit 51 transmits to the bank core system 7 of a predetermined bank transfer request information including parameters of predetermined items related to the bank API necessary for the predetermined bank to process the transfer request, out of all items related to the common API after being complemented by the complementing unit 56.

[0041] The division unit 52 divides the lump-sum transfer detail file stored in a specified monitoring folder for each transfer request, and creates a file for each transfer request.

[0042] The identification unit 53 refers to the transfer method management DB 5001 (FIG. 4) based on the connection code stored in the monitoring folder F, and identifies the corresponding transfer request method and the complementary items related to the unique API of the transferring bank for each transfer request case. Note that when a file is saved in the monitoring folder F, the connection code associated with the monitoring folder F is specified.

[0043] The judgment unit 55 makes various judgments, such as whether the processing of all transfer requests divided by the division unit 52 has been completed.

[0044] The complementing unit 56 complements parameters of complement items related to the unique API of the remittance source bank identified by the identifying unit 53. For example, the complementing unit 56 complements parameters of items that are missing in a remittance request created in a predetermined format (here, the all-banks format) among items related to a common API that covers each bank API necessary for processing the remittance request in each bank.

[0045] The output unit 58 outputs all data (information) of the transfer request results to the accounting software 3 in response to the saving of the lump-sum transfer detail file from the accounting software 3 to the monitoring folder F.

[0046] The storage / reading unit 59 stores data (information) in the temporary storage unit 5002 and reads data from the temporary storage unit 5002 .

[0047] [Processing or Operation of the Embodiment] Next, the processing or operation of this embodiment will be described with reference to Figures 5 to 11. Figure 5 is a sequence diagram showing the process of requesting lump sum transfer according to this embodiment.

[0048] As shown in Fig. 5, the accounting software 3 saves a lump-sum transfer detail file (Fig. 7(a)) created in the Zengin format (Fig. 6(a)) in a specified monitoring folder F (S11). As a result, the division unit 52 divides the lump-sum transfer detail file saved in the specified monitoring folder for each transfer request case, and creates a file for each transfer request case (S12).

[0049] Next, the transmitting / receiving unit 51 calls the common API (FIG. 6(b)) for each transfer request divided by the dividing unit 52 (S13).

[0050] Next, the bank API connection software 5 performs a process of identifying necessary items of the bank-specific transfer request (S14). Here, the process (S14) will be described in detail with reference to FIG.

[0051] As shown in Fig. 8, the identification unit 53 refers to the transfer method management DB 5001 (Fig. 4) based on the connection code of the stored monitoring folder F, and identifies the corresponding transfer request method and the parameters of the complementary items related to the unique API of the transferring bank for each transfer request case (S101). This determines the allocation destination of the divided transfer request cases. Note that the allocation destination is the same for all transfer request cases related to files stored in the same monitoring folder, even if they are divided.

[0052] Next, the complementing unit 56 complements the parameters of the complement items related to the unique API of the remittance source bank identified in step S101 (S102).

[0053] Here, we will explain the transfer request method separately for "Registration and Approval" and "Execution".

[0054] <In case of registration and approval> First, the processing when the transfer request method is "registration and approval" will be explained using Figures 9 and 10. Figure 9 is a flowchart showing the processing of transfer registration requests and transfer approval requests. Figure 10 is a flowchart showing the processing of storing and reading each transfer result. The processing in Figure 9 is the processing when the accounting software 3 saves a lump-sum transfer detail file in monitoring folder F1 (connection code c1) in the processing in Figure 5 (S11).

[0055] First, the transmitting / receiving unit 51 calls the unique API (registration / approval API) of the transferring bank from the bank API connection software 5 itself (S31). This unique API requires, for example, a "duplicate transfer check" item in addition to each item in the All Banks format (FIG. 6(c)). The duplicate transfer check refers to checking whether there is another transfer with the same transfer destination account and transfer amount in the transfer data for the same transfer date.

[0056] Next, as shown in Fig. 9, the transmitting / receiving unit 51 transmits the transfer request registration information (Fig. 6(c)) to the bank core system 7x (S32). As a result, the bank core system 7x registers the transfer request (S33). Then, the bank core system 7x transmits the registration result to the transmitting / receiving unit 51 (S34). As a result, the transmitting / receiving unit 51 receives the registration result.

[0057] Next, the transmitting / receiving unit 51 transmits the transfer request approval information (FIG. 6(c)) to the bank core system 7x for approval (S35). As a result, the bank core system 7x approves the transfer request (S36). Then, the bank core system 7x transmits the approval result to the transmitting / receiving unit 51 (S37). As a result, the transmitting / receiving unit 51 receives the approval result.

[0058] Next, the bank API connection software 5 performs processing to store and read each transfer result (S38).

[0059] Here, the process of storing and reading each transfer result will be described with reference to Fig. 10. As shown in Fig. 10, the storage and reading unit 59 temporarily stores (saves) the transfer request result received in process S37 in the temporary storage unit 5002 (S121).

[0060] Next, the judgment unit 55 judges whether the processing of all the transfer requests divided by the division unit 52 has been completed (S122). Then, if the processing of all the transfer requests has been completed (S122; YES), the storage / reading unit 59 reads out all the transfer request results from the temporary storage unit 5002 (S123). On the other hand, if the processing of all the transfer requests has not been completed (S122; NO), the process returns to S13, the common API is called for the next transfer request, and the subsequent processing continues. This ends the explanation of FIG. 10.

[0061] Returning to FIG. 9, the memory / read unit 59 then reads out all the transfer request results from the temporary memory unit 5002, and outputs (saves) all the transfer request results (FIG. 7(b)) to the output folder F30 (S39). As shown in FIG. 7(b), all the transfer request results are added to the lump-sum transfer detail file of FIG. 7(a) with the transfer request result (here, "OK" or "NG") added for each transfer request case. In this way, the accounting software 3 can output all the transfer request results in a lump sum in response to the lump-sum transfer detail file being saved in the monitoring folder F1 in process S11. This completes the process when the transfer request method is "Register / Approve".

[0062] <In case of execution> Next, the process when the transfer request method is "execute" will be described with reference to Fig. 11. Fig. 11 is a flow chart showing the process of a transfer execution request. The process in Fig. 11 is the process when the accounting software 3 saves a lump-sum transfer detail file in the monitoring folder F2 (connection code c2) in process S11 in Fig. 5.

[0063] First, the transmitting / receiving unit 51 calls the unique API (execution API) of the transferring bank from the bank API connection software 5 itself (S51). In this unique API, for example, in addition to each item of the all-banks format, a "transfer cancellation flag" item is required (FIG. 6(d)). The transfer cancellation flag is a flag that is set when it is desired to cancel a transfer.

[0064] Next, as shown in Fig. 11, the transmitting / receiving unit 51 transmits the transfer request information (Fig. 6(d)) to the bank core system 7y (S52). As a result, the bank core system 7y performs registration and approval together as the execution of the transfer request (S53). Then, the bank core system 7y transmits the execution result to the transmitting / receiving unit 51 (S54). As a result, the transmitting / receiving unit 51 receives the execution result.

[0065] Next, the bank API connection software 5 performs a process of storing and reading out each transfer result (55). This process S55 is similar to the above-mentioned process S38, and has been explained in FIG. 10, so its explanation is omitted.

[0066] Next, the memory / read unit 59 reads out all the transfer request results from the temporary memory unit 5002, and then the output unit 58 outputs (saves) all the transfer request results (FIG. 7(b)) to the output folder F30 (S56). In this way, all the transfer request results can be output together in response to the accounting software 3 saving the lump-sum transfer detail file in the monitoring folder F2 in step S11. This completes the processing when the transfer request method is "execute".

[0067] [Main Effects of the Embodiments] As described above, according to this embodiment, the accounting software 3 simply saves a lump sum transfer statement file in the All Banks format in the monitoring folder F, and the complementing unit 56 of the bank API connection software 5 performs processing to complement the parameters of each item of the common API. As a result, after making it possible to respond to the bank API of any bank core system 7 (see S103), the sending and receiving unit 51 sends transfer request information including information of items required by the unique API of the transfer origin bank to the specified bank core system 7 (see S32, S52). Therefore, the user (company) can perform transfer request processing to each bank without being aware of the API of each bank, so there is no need to build a company-side system according to the specifications of each bank used by each company, which makes it possible to reduce the cost of building a system and to save the trouble of changing the transfer request for each bank.

[0068] In addition, because the division unit 52 divides the lump-sum transfer detail file for each transfer request (see S12), it has the effect of being able to handle both banks that can accept lump-sum transfer requests that include multiple transfer requests, and banks that can only accept transfer requests one at a time. This division makes it possible to handle both banks, which can be said to contribute to the above-mentioned effect of the common API.

[0069] Other embodiments Next, another embodiment (common API direct calling method) will be described with reference to Fig. 12. Fig. 12 is a sequence diagram of another embodiment in which a common API is read for a transfer request. The other embodiment is a modified example of the process in Fig. 5.

[0070] First, as shown in Fig. 12, the accounting software 3 calls the common API for each transfer request to the bank API connection software 5 (S21). Unlike the process S11 in Fig. 5, this is processed for each transfer request.

[0071] Next, the user inputs parameters into the items required for the specific bank in the common API from the accounting software 3 (S22). In this case, the user may operate the user terminal 2 to input the parameters into a screen displaying the API items, or may input the parameters in the program code.

[0072] Next, the bank API connection software 5 refers to the transfer method management DB 5001 (FIG. 4) based on the connection code, and identifies the corresponding transfer request method for each transfer request (S23). Note that the connection code in this case is specified by the user in the API request URL.

[0073] The subsequent processing is similar to that shown in Figure 9 or Figure 11, and therefore a description thereof will be omitted. However, in other embodiments, since a transfer request is originally made for each transfer request case, the transfer results are not returned to the accounting software 3 all at once, as in the processing in Figure 9 (S38, S39) and the processing in Figure 11 (S55, S56), but are returned for each transfer request case.

[0074] As described above, according to the other embodiments, the work of inputting data into the common API items is time-consuming, but since there is no need for processes such as division (see S12) or completion (S103) as in the above-mentioned embodiment, the effect is that transfer requests can be made more quickly.

[0075] 〔supplement〕 The present invention is not limited to the above-described embodiment, and may have the following configurations or processes (operations).

[0076] The program related to the bank API connection software 5 can be provided by recording it on a (non-temporary) recording medium, or can be provided via a network such as the Internet. [Explanation of symbols]

[0077] 1. Transfer System 2. User terminal 3. Accounting Software 5. Bank API connection software 7x Bank Core Systems 7y Bank core system 51 Transmitting / receiving unit (an example of a transmitting unit, an example of a receiving unit) 52 Division 53 Specific part 55 Judgment Department 56 Complementary Section 59 Memory / readout section 100 Communication Network 5000 storage section 5001 Transfer method management DB (an example of the transfer method management section) 5002 Temporary storage

Claims

1. On the computer, A program that realizes a sending unit that sends transfer request information including parameters of specified items related to bank APIs that are necessary for the specified bank to process the transfer request, out of all items related to the common API that covers each bank API necessary for each bank to process the transfer request, to the bank core system of a specified bank, based on the input of parameters of items that are missing in a transfer request case created in a specified format, out of each item related to the common API that covers each bank API necessary for the specified bank to process the transfer request.

2. The computer A bank API connection method which executes a transmission process to transmit transfer request information including parameters of specified items related to bank APIs that are necessary for the specified bank to process the transfer request, out of all items related to a common API that covers each bank API that is necessary for each bank to process the transfer request, to the bank core system of a specified bank, based on input of parameters of items that are missing in a transfer request case created in a specified format among the items related to the common API that covers each bank API that is necessary for the specified bank to process the transfer request.

3. A user terminal that communicates with a bank core system of a bank via a communication network, a transmission unit that transmits transfer request information including parameters of predetermined items related to bank APIs that are necessary for the processing of the transfer request by the predetermined bank to a bank core system of a predetermined bank based on input of parameters of items that are missing in a transfer request case created in a predetermined format among items related to a common API that covers each bank API that is necessary for the processing of the transfer request at each bank; A user terminal having:

Images