Method and system for updating a cross-border payment correspondent bank number

Abstract

The application provides a cross-line payment correspondent bank number supplementing method and system, and relates to the field of computer systems. The application obtains payment data to be supplemented from a payment voucher master table, and puts the obtained data into a thread pool for subsequent supplementing process. For the vouchers to be supplemented, memory bank supplementing is firstly performed. If the memory bank supplementing is successful, the correspondent bank number is written into the payment voucher master table and the detail table, and the payment process is entered. If the memory bank supplementing fails, the cost is sent for supplementing. The application improves the supplementing efficiency of cross-line payment, and further improves the financial payment efficiency, and can quickly respond to the demand of the financial customers during the business peak period. During the process of the financial cross-line payment, the supplementing accuracy and the business success rate of payment can be ensured in the case that the filling of the payee information by the budget unit is not standardized. The application can meet the requirements of the timeliness and success rate of the financial business payment by the financial units in different places, and the financial payment can be quickly and stably completed during the peak period of the financial business.

Description

Interbank payment interbank code supplementation method and system Technical Field

[0001] This invention relates to the field of computer systems, and more specifically, to a method and system for supplementing interbank payment interbank codes. Background Technology

[0002] In recent years, an increasing number of budgetary units have implemented integrated policies. Due to the large number of budgetary units across different regions, commercial banks face the following main problems in fulfilling their role as agents for national fiscal payments:

[0003] (1) As the number of budget units implementing electronic payment increases, the efficiency of interbank payment data entry and payment efficiency are decreasing, making it difficult to respond quickly to the needs of fiscal customers during peak business periods.

[0004] (2) In the process of interbank fiscal payments, some budget units do not fill in the information of the payee in a standardized manner, which reduces the accuracy of supplementary entry and the success rate of payment transactions.

[0005] Currently, based on the above-mentioned needs, the existing technology for supplementing interbank codes in interbank payments for fiscal business includes CN103413215A, a method for matching electronic interbank codes based on matrix similarity algorithm. This patent mainly forms regional codes based on provinces and cities, generates keywords through regional codes and bank names, and matches the generated keywords with the keyword lists of the region and bank in the database. If the similarity is greater than 0.5, the match is successful, and the standard bank name and interbank code corresponding to the record with the highest similarity are selected.

[0006] The patent, published under CN113535822A, describes a method, device, storage medium, and equipment for matching bank interbank codes. This patent establishes a two-layer mapping model with bank interbank codes and bank account numbers as the first mapping relationship and bank interbank codes and bank names as the second mapping relationship. Based on the payee's account number and the first mapping relationship, several bank interbank codes are matched. Then, several interbank codes are matched with the second mapping relationship to obtain several bank names. The obtained bank names are then fuzzily matched with the bank names entered by the customer, and a fuzzy score is calculated. The record with the highest fuzzy score is selected, along with the corresponding standard bank name and interbank code.

[0007] Based on the aforementioned publicly available technologies, these patents generally establish interbank code matching rules using keywords such as the payee's account number, the payee's bank name, and the information filled in by the customer, to achieve the supplementary entry of interbank codes for cross-bank payments. However, they have the following drawbacks:

[0008] Firstly, it relies entirely on the recipient's information. If the recipient's information is not standardized, the accuracy of the automated data entry will be greatly reduced.

[0009] Secondly, the maintenance method of the mapping relationship in the automated data entry is too simplistic and cannot meet the needs of financial operations. Summary of the Invention

[0010] In response to the needs mentioned in the background art, embodiments of the present invention provide a method and system for supplementing interbank payment interbank codes, aiming to significantly improve the efficiency and success rate of fiscal business payments.

[0011] A method for supplementing interbank payment interbank codes, the specific steps of which include:

[0012] Step 1: Retrieve the payment data to be supplemented from the main payment voucher table, and put the obtained data into a thread pool for subsequent supplementation process. Use multiple threads to improve supplementation efficiency.

[0013] Step 2: For vouchers that need to be supplemented, first supplement the memory. If the supplementation is successful, write the interbank code into the main table and details table of payment vouchers and enter the payment process. If it fails, send a cost for supplementation.

[0014] Step 3: For vouchers requiring cost supplementation, if the cost supplementation is successful, the interbank code will be written into the main payment voucher table and the details table, and the payment process will begin. If it fails, the voucher status will be changed to pending manual supplementation, and the teller will supplement the cost.

[0015] Step 4: If the teller successfully manually enters the information, the interbank code will be written into the main payment voucher form and the detailed payment form, and the payment process will begin. If the process fails, the teller will return the voucher to the treasury system.

[0016] Furthermore: the data sources of the memory bank are divided into three parts, including:

[0017] (1) The data after cost is successfully added will be entered into the memory.

[0018] (2) Data successfully entered manually by tellers will be stored in the memory. Since some fiscal transactions have high timeliness requirements, some interbank payment transactions that are not automatically updated in time can be completed by tellers manually updating the data, thereby improving the payment efficiency of fiscal transactions.

[0019] (3) Manually maintained memory data by tellers. Tellers can manually maintain data in the memory based on the historical payment data of the budget unit, which can improve the efficiency of memory data replenishment. Each account opening bank can only maintain the memory data corresponding to the payer accounts opened under its own institution. Therefore, adding payer information to the memory matching rules can greatly improve the accuracy of memory data replenishment.

[0020] Furthermore, the matching rule for the payment memory is "payment account + payee bank name". That is, the payment account and payee bank name filled in by the customer are precisely matched with the payment memory, and the payee bank code corresponding to the matched record is used as the standard bank code to supplement the payment voucher.

[0021] Furthermore: by obtaining the table ID based on the table name of the supplementary data table, and then obtaining the field names, positions, and attributes of the supplementary target table in the mapping table based on the table ID, the supplementary target attributes can be constructed.

[0022] Building the target table attributes involves interacting with the parameter table in the parameter template based on the target table name to obtain the table ID, field name, field position, and field attributes so that the source data can be matched to the correct position when parsing the source data.

[0023] Next, the table ID can be obtained based on the table name of the supplementary data table, and the source dataset of all supplementary data tables can be retrieved from the temporary storage based on the table ID. Then, the source dataset is parsed row by row to obtain the parsing result of the supplementary source data.

[0024] Furthermore: A cross-bank payment interbank code supplementation system, comprising:

[0025] The acquisition module is used to acquire the vouchers to be supplemented and put them into a thread pool for asynchronous processing.

[0026] The memory replenishment module writes the interbank number into the main payment voucher table and the details table when the voucher is successfully replenished, and then proceeds to the payment process.

[0027] The cost supplementation module is used to supplement the cost of the voucher when the cost supplementation in the memory fails. If the cost supplementation is successful, the interbank number is written into the main table and the details table of the payment voucher and the payment process begins.

[0028] The manual data entry module provides a manual data entry channel when cost data entry fails. If manual data entry is successful, the interbank code will be written into the main payment voucher table and the details table, and the payment process will begin. If it fails, the teller will return the voucher to the treasury system.

[0029] Furthermore, the terminal device may include a processor, a storage medium, and a bus. The storage medium stores machine-readable instructions that can be executed by the processor. When the terminal device is running, the processor communicates with the storage medium via the bus, and the processor executes the machine-readable instructions to perform the steps of the deep learning model training method as described in the foregoing embodiments.

[0030] Further: a storage medium storing a computer program, which, when executed by a processor, performs the steps of the method described above.

[0031] Furthermore: a computer program product comprising a computer program that is executed by a processor using the methods described above.

[0032] The beneficial effects of this invention are as follows: This invention improves the efficiency of interbank payment data entry, thereby improving the efficiency of fiscal payments. It can quickly respond to the needs of fiscal clients during peak business periods. During interbank fiscal payments, it ensures the accuracy of data entry and the success rate of payments even when budgetary units have inaccurate information about payees. This invention can meet the timeliness and success rate requirements of fiscal units in various regions for fiscal business payments, and can complete fiscal payments quickly and stably even during peak fiscal business periods. Attached Figure Description

[0033] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of the present invention and should not be regarded as a limitation on the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0034] Figure 1 shows a schematic flowchart of the method of the present invention.

[0035] Figure 2 shows a schematic diagram of the system of the present invention.

[0036] Figure 3 shows a schematic diagram of the composition of the terminal device of the present invention. Detailed Implementation

[0037] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. It should be understood that the accompanying drawings in the present invention are for illustrative and descriptive purposes only and are not intended to limit the scope of protection of the present invention. Furthermore, it should be understood that the schematic drawings are not drawn to scale. The flowcharts used in this invention illustrate operations implemented according to some embodiments of the present invention. It should be understood that the operations in the flowcharts may not be implemented in sequence, and steps without logical contextual relationships may be reversed or implemented simultaneously. In addition, those skilled in the art, guided by the content of this invention, may add one or more other operations to the flowcharts, or remove one or more operations from the flowcharts.

[0038] Furthermore, the embodiments described herein are merely some, not all, of the embodiments of the invention. The components of the embodiments of the invention described and illustrated herein can typically be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of the invention provided in the accompanying drawings is not intended to limit the scope of the claimed invention, but merely to illustrate selected embodiments of the invention. All other embodiments obtained by those skilled in the art based on the embodiments of the invention without inventive effort are within the scope of protection of the invention.

[0039] It should be noted that the term "comprising" will be used in the embodiments of the present invention to indicate the presence of a feature subsequently declared, but does not preclude the addition of other features. It should also be noted that similar reference numerals and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. In the description of the present invention, it should also be noted that the terms "first," "second," "third," etc., are used only for distinguishing descriptions and should not be construed as indicating or implying relative importance.

[0040] Firstly, regarding the definition of the standard data model in this embodiment, the specific standard data mentioned is the technical data for interbank code supplementation. This invention lists the following most commonly used standard data for interbank code supplementation in fiscal interbank payments.

[0041] Regarding the Interbank Code Supplement Form, this form refers to the payer's account information and payee information involved in interbank payment vouchers in fiscal transactions. It includes the payer's account number, account opening institution number, and payee's bank name, as shown in Table 1.

[0042] Table 1

[0043]

[0044]

[0045] Regarding the payment voucher master table, the payment voucher master table corresponds to the payment voucher master order information, and the specific content is shown in Table 2.

[0046] Table 2

[0047]

[0048]

[0049] Regarding the payment voucher details table, the payment voucher details table corresponds to the payment voucher details slip information, and the specific content is shown in Table 3 below:

[0050] Table 3

[0051]

[0052]

[0053] The following is a detailed description of this case, in conjunction with the relevant accompanying drawings in the instruction manual.

[0054] As shown in Figure 1, the specific steps of the interbank payment interbank code supplementation method of the present invention include:

[0055] Step 1: Retrieve the payment data to be supplemented from the main payment voucher table, and put the obtained data into a thread pool for subsequent supplementation process. Multi-threading is used to improve supplementation efficiency.

[0056] Step 2: For vouchers requiring supplementary entry, first, supplement the voucher memory. If the supplementary entry is successful, write the interbank code into the main payment voucher table and the details table, and proceed with the payment process. If it fails, send a cost request for supplementary entry. The data and matching rules in the voucher memory are designed according to the characteristics of fiscal operations, as follows:

[0057] 1) The data sources are mainly divided into three parts:

[0058] (1) The data after cost is successfully added will be entered into the memory.

[0059] (2) Data successfully entered manually by tellers will be stored in the memory. Since some fiscal transactions have high timeliness requirements, some interbank payment transactions that are not automatically updated in time can be completed by tellers manually updating the data, thereby improving the payment efficiency of fiscal transactions.

[0060] (3) Manually maintained memory data by tellers. Tellers can manually maintain data in the memory based on the historical payment data of the budget unit, which can improve the efficiency of memory data replenishment. Each account opening bank can only maintain the memory data corresponding to the payer accounts opened under its own institution. Therefore, adding payer information to the memory matching rules can greatly improve the accuracy of memory data replenishment.

[0061] 2) Based on the characteristics of financial business, the matching rule is designed as: "Payment Account + Receiving Bank Name", that is, the payment account and the name of the receiving bank filled in by the customer are accurately matched with the memory, and the bank code of the receiving bank corresponding to the matched record is used as the standard bank code to supplement the payment voucher.

[0062] In this embodiment, the table ID is obtained based on the table name of the supplementary data table, and the field names, positions, and attributes of the supplementary target table in the mapping table are obtained based on the table ID to construct the supplementary target attributes.

[0063] Understandably, constructing the target table attributes involves interacting with the parameter table in the parameter template based on the target table name to obtain the table ID, field name, field position, and field attributes so that the source data can be matched to the correct position when parsing the source data.

[0064] Next, the table ID can be obtained based on the table name of the supplementary data table, and the source dataset of all supplementary data tables can be retrieved from the temporary storage based on the table ID. Then, the source dataset is parsed row by row to obtain the parsing result of the supplementary source data.

[0065] Step 3: For vouchers requiring cost supplementation, if the cost supplementation is successful, the interbank code will be written into the main payment voucher table and the details table, and the payment process will begin. If it fails, the voucher status will be changed to pending manual supplementation, and the teller will supplement the cost.

[0066] Step 4: If the teller successfully manually enters the information, the interbank code will be written into the main payment voucher form and the detailed payment form, and the payment process will begin. If the process fails, the teller will return the voucher to the treasury system.

[0067] As shown in Figure 2, the interbank payment interbank code supplementation system of the present invention includes:

[0068] The acquisition module is used to acquire the vouchers to be supplemented and put them into a thread pool for asynchronous processing.

[0069] The memory replenishment module writes the interbank number into the main payment voucher table and the details table when the voucher is successfully replenished, and then proceeds to the payment process.

[0070] The cost supplementation module is used to supplement the cost of the voucher when the cost supplementation in the memory fails. If the cost supplementation is successful, the interbank number is written into the main table and the details table of the payment voucher and the payment process begins.

[0071] The manual data entry module provides a manual data entry channel when cost data entry fails. If manual data entry is successful, the interbank code will be written into the main payment voucher table and the details table, and the payment process will begin. If it fails, the teller will return the voucher to the treasury system.

[0072] As shown in Figure 3, the terminal device 6 may include a processor 601, a storage medium 602, and a bus 603. The storage medium 602 stores machine-readable instructions executable by the processor 601. When the terminal device is running, the processor 601 and the storage medium 602 communicate via the bus 603. The processor 601 executes the machine-readable instructions to perform the steps of the deep learning model training method described in the foregoing embodiments. The specific implementation and technical effects are similar and will not be repeated here.

[0073] For ease of explanation, only one processor is described in the terminal device described above. However, it should be noted that in some embodiments, the terminal device of the present invention may also include multiple processors, and therefore the steps performed by one processor described in the present invention may also be performed jointly by multiple processors or individually.

[0074] The above are merely specific embodiments of the present invention, but the scope of protection of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the present invention should be included within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A method for supplementing interbank codes in interbank payments, characterized in that, The specific steps include: Step 1: Retrieve the payment data to be supplemented from the payment voucher master table and put the obtained data into a thread pool for subsequent supplementation processes; Step 2: For vouchers that need to be supplemented, first perform supplementation in the payment memory. If the supplementation in the payment memory is successful, write the interbank code into the payment voucher master table and the details table, and enter the payment process. If it fails, issue a cost for supplementation; Step 3: For vouchers supplemented by issuing a cost, if the cost supplementation is successful, write the interbank code into the payment voucher master table and the details table, and enter the payment process. If it fails, change the voucher status to pending. The manual supplementation is carried out by the teller; Step 4: After the manual supplementation is successful, the interbank number is written into the main table and details table of the payment voucher and the payment process is initiated. If it fails, the teller will return the voucher to the financial system. The data sources of the memory bank are divided into three parts, including: (1) data after the cost is successfully supplemented; (2) data successfully supplemented by manual means. For interbank payment transactions that are not automatically supplemented in time, the payment is completed by manual supplementation; (3) memory bank data maintained by manual means. The data is manually maintained in the memory bank based on the historical payment data of the budget unit.

2. The method according to claim 1, characterized in that, The matching rule for the payment memory is "payment account + payee bank name". That is, the payment account and payee bank name filled in by the customer are matched with the payment memory, and the payee bank code corresponding to the matched record is used as the standard bank code to be added to the payment voucher.

3. The method according to claim 1, characterized in that, In step two, the table ID is obtained based on the table name of the supplementary data table, and the field names, positions, and attributes of the supplementary target table in the mapping table are obtained based on the table ID to construct the supplementary target attributes.

4. The method according to claim 3, characterized in that, Building the target table attributes involves interacting with the parameter table in the parameter template based on the target table name to obtain the table ID, field name, field position, and field attributes so that the source data can be matched to the correct position when parsing the source data.

5. The method according to claim 4, characterized in that, Obtain the table ID based on the table name of the supplementary data table, and retrieve the source dataset of all supplementary data tables from the temporary storage based on the table ID. Then, parse the source dataset row by row to obtain the parsing result of the supplementary source data.

6. A system for supplementing interbank code in cross-bank payment, characterized in that, include: The system comprises four modules: **Acquisition Module:** This module retrieves the vouchers to be supplemented and places them in a thread pool for asynchronous processing. **Cost Supplementation Module:** When voucher supplementation is successful, this module writes the interbank code to the main payment voucher table and the details table, initiating the payment process. **Cost Supplementation Module:** This module supplements the cost of the voucher when supplementation in the voucher memory fails. If cost supplementation is successful, the interbank code is written to the main payment voucher table and the details table, initiating the payment process. **Manual Supplementation Module:** This module provides a manual supplementation channel when cost supplementation fails. If manual supplementation is successful, the interbank code is written to the main payment voucher table and the details table, initiating the payment process. If manual supplementation fails, the teller returns the voucher to the financial system. The data sources of the memory bank are divided into three parts, including: (1) data after cost is successfully added; (2) Data that was successfully entered manually. For cross-bank payment transactions that were not entered automatically in time, the payment was completed by manual entry. (3) Data in the memory bank that was manually maintained. Data was manually maintained in the memory bank based on the historical payment data of the budget unit.

7. A terminal device, characterized in that, include: The device includes a processor, a storage medium, and a bus, wherein the storage medium stores machine-readable instructions executable by the processor, and when the terminal device is running, the processor communicates with the storage medium via the bus, and the processor executes the machine-readable instructions to perform the steps of the method as described in any one of claims 1 to 5.

8. A storage medium, characterized in that, The storage medium stores a computer program, which, when executed by a processor, performs the steps of the method as described in any one of claims 1 to 5.

9. A computer program product, comprising a computer program, characterized in that, The computer program, when executed by a processor, implements the method as described in any one of claims 1-5.

Images