Method and system for improving cross-border payment entry efficiency

Abstract

The invention relates to the field of financial science and technology, and provides a method and system for improving cross-border payment entry efficiency, and the method comprises the steps: S1, responding to a transaction file of a bank; s2, pre-analyzing the transaction file, scanning and identifying all transaction nodes in the transaction file, storing path information of the transaction nodes in a database, and performing dynamic configuration analysis rule detection; s3, according to a specified field to be extracted in the transaction record, extracting field information through a corresponding BAI CODE analysis rule, and for the specified field which is not configured with the BAI CODE analysis rule or not covered by the BAI CODE, extracting corresponding field information by using a user-defined condition expression of general analysis; and S4, forming a complete transaction record by the integrated and extracted field information. The problems that the message analysis rule is fixed, the information value is not clear and the format change of the bank CAMT file cannot be dynamically adapted are solved, the CAMT message analysis meeting the international standard of each bank can be supported, and the effect of quickly and accurately completing the posting transaction is achieved.

Description

Technical Field

[0001] The present invention relates to the field of financial technology, and in particular to a method and system for improving the efficiency of cross-border payment entry. Background Art

[0002] In the cross-border payment process, obtaining and processing transaction documents provided by banks is a key link. Transaction information is usually obtained through transaction documents provided by domestic and foreign banks, and then credited to customers. These transaction documents usually follow SWIFT standards and contain rich transaction details.

[0003] The traditional processing method is to parse the entire XML file that complies with the SWIFT standard and load all leaf node information into memory. However, the XML file contains hundreds of node information, and the business actually only needs to pay attention to a small part of it. In addition, some key information needs to be extracted from multiple nodes through hard coding and complex logic. This method is not only difficult to adapt to the file format of all banks, but also prone to abnormal accounting or capital loss due to information recognition errors or inaccurate recognition in special scenarios. With the iterative update of business scenarios in the cross-border payment process, the format of bank transaction files may also change, requiring developers to constantly adjust the code and redeploy the system. Once unrecognizable transaction information is encountered, the entire file processing flow may be interrupted, resulting in a delay in the overall accounting. The existing technical solution is to deserialize XML files into Java objects through JAXB (Java Architecture for XML Binding) technology and extract the required information from Java objects. Although JAXB provides a convenient way to process XML data, it also has obvious limitations:

[0004] (1) The logic of key information is unclear, resulting in failure to enter the account or even financial loss.

[0005] (2) With the rapid development of the payment industry, banks may adjust the layout of information in XML files from time to time. This requires that the value logic of Java objects also needs to be adjusted accordingly. In this case, the system needs to be upgraded to adapt to the new file format.

[0006] (3) All information value logic, regardless of its complexity, must be implemented through hard coding. As business logic changes, hard-coded value logic becomes more and more complex, posing a great challenge to system maintenance. Especially when it comes to financial transactions, the risk of code modification is extremely high, and the maintenance cost also increases accordingly, making it difficult for traditional XML processing methods to meet the needs of modern payment systems. Summary of the invention

[0007] In view of the above problems, the purpose of the present invention is to provide a method and system for improving the efficiency of cross-border payment entry, so as to solve the problems in the prior art of rigid message parsing rules, unclear information values, and inability to dynamically adapt to changes in the bank's CAMT file format, and to provide a method for quickly and accurately accessing banks, quickly entering accounts, and reducing the occurrence of capital losses. The above invention objectives of the present invention are achieved through the following technical solutions. The present invention provides a method for improving the efficiency of cross-border payment entry, including:

[0008] Step S1, responding to the transaction file of the bank;

[0009] Step S2, pre-parse the transaction file, scan and identify all transaction nodes in the transaction file, store the path information of each transaction node in the database, and perform dynamic configuration parsing rule detection; wherein,

[0010] Determine whether the BAI CODE in the transaction node has an associated parsing rule. If there is a parsing rule, use the Aviator expression engine to dynamically adjust and extract field information according to the parsing rule; if there is no BAICODE with the parsing rule, mark the transaction node corresponding to the BAI CODE as pending for subsequent compensation parsing;

[0011] Step S3: according to the specified fields to be extracted from the transaction records, the field information is extracted by using the parsing rules of the BAI CODE corresponding to the specified fields. For the specified fields that are not configured with parsing rules in the BAI CODE or are not covered by the BAI CODE, the corresponding field information is extracted by using the custom conditional expression of the general parsing;

[0012] Step S4, integrating the extracted field information to form a complete transaction record for account entry processing.

[0013] Further, in step S2, pre-parse the transaction file, scan and identify all transaction nodes in the transaction file, store the path information of each transaction node in the database, and perform dynamic configuration parsing rule detection including:

[0014] Initial pre-parsing scans the entire transaction file, identifies and records the path information of each transaction node;

[0015] Store the path information in the database and initially mark each transaction node as pending;

[0016] According to the stored path information, determine whether there is a corresponding parsing rule for the BAI CODE of each transaction node;

[0017] When BAI CODE has configured the corresponding parsing rules, the Aviator expression engine dynamically extracts the corresponding field information according to the parsing rules, and updates the status mark to a successful status according to the parsing results;

[0018] When the BAI CODE of a transaction node is not configured or the parsing rule fails, the transaction node will be marked as pending.

[0019] Furthermore, in step S2, the transaction node corresponding to the BAI CODE is marked as pending, and subsequent compensation analysis includes:

[0020] Check the transaction nodes marked as pending in the database;

[0021] Determine whether the re-parsing is successful after the parsing rules in the BAI CODE in the transaction node are added or updated;

[0022] If the analysis is successful, the transaction node corresponding to the BAI CODE in the database is updated to a successful state;

[0023] If the parsing fails, the BAI CODE will remain in the pending state until the next parsing rule can be successfully parsed.

[0024] Furthermore, in step S3, using a custom conditional expression of general analysis to extract corresponding field information includes:

[0025] One or more general parsing templates are set, and the general parsing includes the specified fields in the transaction file and the corresponding conditional expressions; wherein the conditional expressions are set based on the data type and structure of the specified fields to obtain the corresponding field information.

[0026] Further, in step S3, according to the specified field to be extracted from the transaction record, extracting the field information by using the parsing rule of the BAI CODE corresponding to the specified field includes:

[0027] Initialize data objects to map various transaction nodes in the transaction file and ensure that the data objects are directly associated with the transaction nodes in the transaction file, wherein the data objects include transaction details objects and account statement objects;

[0028] Create an environment variable of type Map to store one or more data objects that need to be referenced when the Aviator expression is executed;

[0029] Write Aviator expressions to define the extraction logic of data objects, and compile Aviator expressions into executable Java bytecodes for data extraction;

[0030] Based on the created environment variables, the compiled Aviator expression is executed to extract the field information of the specified field and output the corresponding result.

[0031] Furthermore, writing an Aviator expression to define the extraction logic of a data object includes:

[0032] In the Aviator expression, directly access the data object stored in the environment variable to obtain the corresponding field information;

[0033] The status of field information is determined through conditional logic, and string preprocessing and data integration are performed on field information that meets the conditional logic.

[0034] Use regular expressions to process the matched and integrated strings, and extract the corresponding field information based on the matching results.

[0035] If the regular expression matches successfully and the field information is extracted, the field information is returned as the result. If the field information is not successfully matched, the field information extracted by the custom conditional expression of the general analysis is returned as the data.

[0036] Furthermore, based on the created environment variables, the compiled Aviator expression is executed to extract the field information of the specified field, and the corresponding results are output including:

[0037] Use the substring method of the Java String class to extract the expression text that needs to be executed by the Aviator expression engine from the string containing the complete expression;

[0038] Compile the expression text into an executable expression object based on the AviatorEvaluator.compile method in the Aviator library;

[0039] The compiled expression object is executed through the compiledExp.execute(env) method in the Aviator library, where env is an environment variable of type Map, which is used to store the fields that need to be referenced when executing the expression object and output the corresponding results.

[0040] Based on the same inventive concept, the present invention also provides a system for improving the efficiency of cross-border payment entry, including:

[0041] a data receiving module for responding to a transaction file from a bank;

[0042] The data parsing module is used to pre-parse the transaction file, scan and identify all transaction nodes in the transaction file, store the path information of each transaction node in the database, and perform dynamic configuration parsing rule detection; among them, it is determined whether the BAI CODE in the transaction node has an associated parsing rule. If there is a parsing rule, the Aviator expression engine is used to dynamically adjust and extract field information according to the parsing rule; if there is no BAI CODE with a parsing rule, the transaction node corresponding to the BAI CODE is marked as pending for subsequent compensation parsing;

[0043] The data processing module is used to extract the field information according to the specified fields to be extracted from the transaction records through the parsing rules of the BAICODE corresponding to the specified fields. For the specified fields that are not configured with parsing rules or are not covered by the BAICODE, the custom conditional expressions of the general parsing are used to extract the corresponding field information;

[0044] The data output module is used to integrate the extracted field information into a complete transaction record for accounting processing.

[0045] The present invention provides an electronic device, comprising:

[0046] A memory, the memory is used to store the processing program;

[0047] The processor implements the above-mentioned method for improving the efficiency of cross-border payment entry when executing the processing program.

[0048] The present invention provides a readable storage medium, on which a processing program is stored. When the processing program is executed by a processor, the method for improving the efficiency of cross-border payment entry is implemented.

[0049] Compared with the prior art, the present invention has at least one of the following beneficial effects:

[0050] The present invention solves the problems of rigid message parsing rules, unclear information values, and inability to dynamically adapt to changes in bank CAMT file formats. The dynamic configuration of field parsing based on the BAI CODE dimension can support CAMT message parsing of major banks in accordance with international standards more quickly and accurately, thereby achieving the effect of quickly and accurately completing account entry transactions.

[0051] (1) Improve accounting efficiency, clarify information value logic, and quickly respond to bank changes. Through BAI CODE-based classification, clear information value rules are configured for each transaction type to ensure accurate acquisition of key information, reduce accounting errors, and reduce the risk of capital loss; at the same time, the configurable parsing system allows for rapid adaptation to bank message format adjustments without recoding or system upgrades, so that accounting processing can be updated instantly with bank changes to maintain efficient operation.

[0052] (2) Enhance system flexibility and scalability, dynamically configure parsing rules and support diversity of banks and message formats. For different banks and file types, the parsing rules of each BAI CODE can be flexibly configured to adapt to changes in business scenarios and bank rules. At the same time, the system design allows adaptation to a variety of banks and transaction file formats, providing a unified and flexible solution.

[0053] (3) Improve system maintainability, reduce maintenance costs and facilitate rule updates and management. The use of configurable parsing rules avoids frequent program modifications and system releases, reduces code complexity and error probability caused by business logic changes, and all value logic and business rule adjustments are implemented by updating configuration rules, making system management more convenient and responsive. BRIEF DESCRIPTION OF THE DRAWINGS

[0054] Figure 1 A flowchart of the steps of the method for improving the efficiency of cross-border payment entry in the present invention;

[0055] Figure 2 A flowchart of the analysis process in the method for improving the efficiency of cross-border payment entry in the present invention;

[0056] Figure 3 The main interface for setting a general parsing conditional expression in the embodiment of the present invention;

[0057] Figure 4 This is a diagram of an interface setting for setting a general parsing conditional expression in an embodiment of the present invention;

[0058] Figure 5 This is an interface diagram for setting parsing rules for a specified field in an embodiment of the present invention. DETAILED DESCRIPTION

[0059] In order to make the purpose, technical solution and advantages of the embodiments of the present application clearer, the technical solution in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

[0060] Those skilled in the art will appreciate that, unless otherwise stated, the singular forms "a", "an", "said" and "the" used herein may also include plural forms. It should be further understood that the term "comprising" used in the specification of the present invention refers to the presence of the features, integers, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components and / or groups thereof.

[0061] First embodiment

[0062] In the field of cross-border payments, banks and financial institutions usually rely on transaction files provided by domestic and foreign banks to obtain necessary transaction information and then process customer deposit operations. These transaction files usually follow the SWIFT standard XML files (such as CAMT052 and CAMT053) and contain a large amount of transaction data. However, due to the complexity and information density of these files, traditional parsing methods face multiple challenges.

[0063] First, XML files contain hundreds of nodes, but only a small part of them actually need to be paid attention to. When processing these files, the information of all leaf nodes is usually loaded into memory, which not only takes up a lot of system resources, but also increases processing time. In addition, due to the differences in information expression between banks, the extraction of key information often relies on hard coding and complex logical judgments, which not only increases the difficulty of programming, but also makes it difficult for the system to adapt to the changes in file formats of different banks. It is easy for transaction information to fail to be recognized or to be inaccurately recognized in certain special scenarios, resulting in abnormal account entry and even serious financial losses.

[0064] Secondly, as the business scenarios of cross-border payment processes are iteratively updated, the formats of bank transaction files will also change. This ever-changing environment requires payment systems to quickly adapt to new formats, otherwise parsing errors may occur, which in turn may affect the normal entry of transactions. Current systems often lack sufficient flexibility to cope with these changes, and usually require frequent system upgrades and code adjustments to adapt to new requirements, which not only increases maintenance costs, but may also introduce new errors during the update process.

[0065] The most serious problem is that if some transaction information in the file cannot be correctly identified, the processing of the entire file may be interrupted. In this case, not only the specific transaction items may be delayed in processing, but the entire file entry operation will also be affected, and in serious cases, it may even cause financial losses.

[0066] The above problems clearly show that traditional message parsing methods can no longer meet the needs of modern cross-border payments. A new solution is urgently needed to improve processing efficiency, ensure the accuracy of information, and flexibly adapt to changes in bank file formats.

[0067] In an embodiment of the present invention, we propose a method for improving the efficiency of cross-border payment entry, which is based on the dynamic configuration of BAI CODE field parsing, and is used to optimize and improve the message processing efficiency in cross-border payments. The following content will explain the relevant industry terms and summarize the core invention points of the present invention, so as to better understand the application background and technical details of the present invention.

[0068] BAI CODE, BAI code is a standardized transaction code used for inter-bank communication, it is used to classify and describe various transaction types in bank account activities. These codes play a vital role in processing and identifying complex banking transactions.

[0069] CAMT messages are cash management message formats that comply with the ISO 20022 international standard and are widely used for electronic data exchange in the cash management field. These messages provide a standardized format for exchanging account information and transaction reports between banks and customers, helping banks and enterprises achieve efficient and automated cash management and reconciliation processes.

[0070] In the existing technical solution, all data can only be obtained from the Java object deserialized by JAXB through hard coding in the program. The steps are as follows:

[0071] (1) Convert the entire XML file into a string format through stream processing.

[0072] (2) Define a general Java object whose internal attribute hierarchy is consistent with the parent-child relationship of XML nodes.

[0073] (3) Use JAXB to deserialize the XML string in (1) into the Java object defined in (2).

[0074] (4) All subsequent information is obtained directly from the Java object obtained in (3).

[0075] Although this method is effective in processing standardized and structured data, it has limitations in scenarios where data formats change frequently or where parsing rules need to be configured highly dynamically, as follows:

[0076] (1) Unclear logic of information value may lead to failure of entry, or even worse, financial loss. The main reasons are as follows:

[0077] ① CAMT052 and CAMT053 files, as XML files that comply with SWIFT standards, usually contain complex data structures and multi-level nodes. These files contain a large amount of bank transaction information and detailed account data, but not all data is required to process transactions. Failure to clearly distinguish which information is critical and which is auxiliary may lead to omission or misinterpretation of key data.

[0078] ② In traditional methods, the parsing rules of information are usually hard-coded in the program. This means that any slight change from the bank's file format may break the existing parsing logic because the fixed rules are not adaptive. For example, if the bank adjusts the position of a transaction information in the XML structure, the fixed parsing code may not be able to correctly locate and extract this information.

[0079] ③ Although tools such as JAXB can automatically convert XML files into Java objects, the premise is that the definitions of these objects must completely match the structure of XML. If the mapping is inaccurate or a new field is added to the XML file that is not defined in the Java object, data parsing errors will occur, which directly affects the accurate entry of transactions.

[0080] Therefore, the unclear logic of information value not only leads to failure or delay in account entry, but also may cause financial loss to customers in more serious cases. Therefore, when processing CAMT052 or CAMT053 files with complex data structures, the key to improving the efficiency of cross-border payment entry is to adopt a dynamic configuration field parsing method that clarifies the value logic of each field.

[0081] Based on in-depth investigation and sorting, our team found a key point, that is, the transaction classification in the standard CAMT052 and CAM053 files is actually based on BAI CODE. Each BAI CODE represents a specific transaction type, and the method of obtaining transaction information of each type has been clearly defined. Therefore, the transaction classification based on the BAI CODE dimension is adopted to ensure the consistency of the field information value logic of each type of BAI CODE. This method not only simplifies the classification and processing of transactions, but also improves the accuracy and efficiency of data analysis, and greatly reduces the delay in entry or capital loss caused by information analysis errors.

[0082] (2) Weak scalability. With the rapid development of the payment industry, banks may adjust the information display position in the XML file as needed. Such frequent changes require us to constantly adjust the data value logic in the Java objects generated by deserialization from the XML file. The current system design requires that adaptation to these changes must be achieved through system upgrades, which is not only time-consuming but may also cause system stability and compatibility issues.

[0083] Based on the discovery that transactions can be classified by BAI CODE, our team found that the implementation of CAMT messages by various banks (such as CITI, JPM) is actually different. With the enrichment and changes of business scenarios, the acquisition methods of certain transaction information will also be adjusted, and the types of BAI CODE may also be added. In order to adapt to this change, a new configuration parsing system has been added. Based on the dimensions of bank and file type, the acquisition method of all transaction information we are concerned about is configured based on BAI CODE. Here, each transaction information field specifies the value rule in the form of an expression (such as the value expression of BAI CODE, ${ntry.bkTxCd.prtry.cd}). The present invention uses Aviator to implement configuration parsing. Since the design goal of Aviator is lightweight and high-performance, compared with the bulky Groovy and JRuby, Aviator is very small, and it is only 450K including the dependent package, and only 70K without the dependent package. Secondly, Aviator's implementation idea is very different from other lightweight evaluators. Other evaluators generally run in an interpreted manner, while Aviator directly compiles expressions into Java bytecode and hands them over to JVM for execution.

[0084] (3) Weak maintainability. All information value logic, no matter how complex it is, can only be obtained through hard coding. Over time, changes in business logic will make these value logics more and more complicated. In addition, when it comes to financial transactions, the cost of modifying the code becomes increasingly high and unacceptable.

[0085] Therefore, after the configuration analysis is performed, all bank access and file format changes are basically separated from code editing, and are ultimately reflected in the adjustment and update of field analysis rules, thus avoiding systemic problems caused by frequent program application releases.

[0086] In summary, the present invention provides a method for improving the efficiency of cross-border payment entry. The main purpose is to overcome the shortcomings of the prior art, such as rigid message parsing rules, unclear information values, and inability to dynamically adapt to changes in the bank's CAMT file format, and to provide a method for quickly and accurately accessing a bank, quickly entering accounts, and reducing the occurrence of capital losses. The specific implementation methods are as follows:

[0087] like Figure 1 As shown, the present invention provides a method for improving the efficiency of cross-border payment entry, comprising:

[0088] Step S1, responding to the transaction file of the bank;

[0089] Step S2, pre-parse the transaction file, scan and identify all transaction nodes in the transaction file, store the path information of each transaction node in the database, and perform dynamic configuration parsing rule detection; wherein,

[0090] Determine whether the BAI CODE in the transaction node has an associated parsing rule. If there is a parsing rule, use the Aviator expression engine to dynamically adjust and extract field information according to the parsing rule; if there is no BAICODE with the parsing rule, mark the transaction node corresponding to the BAI CODE as pending for subsequent compensation parsing;

[0091] It should be noted that the bank BAI CODE needs to be processed before pre-parsing. The specific steps are:

[0092] (1) Collect the BAI CODEs currently appearing in each bank and regularly update the corresponding BAI CODE collection.

[0093] (2) Clarify the meaning of each BAI CODE and the value selection method of the transaction fields we are concerned about in the type of transaction it represents.

[0094] (3) Identify and define the key transaction fields associated with each of the BAI CODEs, and filter out the transaction fields of interest from the transaction file xml provided by the bank, excluding irrelevant fields to optimize processing efficiency and accuracy.

[0095] Step S3: according to the specified fields to be extracted from the transaction records, the field information is extracted by using the parsing rules of the BAI CODE corresponding to the specified fields. For the specified fields that are not configured with parsing rules in the BAI CODE or are not covered by the BAI CODE, the corresponding field information is extracted by using the custom conditional expression of the general parsing;

[0096] Step S4, integrating the extracted field information to form a complete transaction record for account entry processing.

[0097] Further, in step S2, pre-parse the transaction file, scan and identify all transaction nodes in the transaction file, store the path information of each transaction node in the database, and perform dynamic configuration parsing rule detection including:

[0098] Initial pre-parsing scans the entire transaction file, identifies and records the path information of each transaction node;

[0099] Store the path information in the database and initially mark each transaction node as pending;

[0100] According to the stored path information, determine whether there is a corresponding parsing rule for the BAI CODE of each transaction node;

[0101] When BAI CODE has configured the corresponding parsing rules, the Aviator expression engine dynamically extracts the corresponding field information according to the parsing rules, and updates the status mark to a successful status according to the parsing results;

[0102] When the BAI CODE of a transaction node is not configured or the parsing rule fails, the transaction node will be marked as pending.

[0103] Furthermore, in step S2, the transaction node corresponding to the BAI CODE is marked as pending, and subsequent compensation analysis includes:

[0104] Check the transaction nodes marked as pending in the database;

[0105] Determine whether the re-parsing is successful after the parsing rules in the BAI CODE in the transaction node are added or updated;

[0106] If the analysis is successful, the transaction node corresponding to the BAI CODE in the database is updated to a successful state;

[0107] If the parsing fails, the BAI CODE will remain in the pending state until the next parsing rule can be successfully parsed.

[0108] It should be specifically explained that the method based on the BAI CODE is used as the dimension to configure the parsing rules, so there is a situation where the BAI CODE is not configured, such as the bank's BAI CODE is newly added. In order to prevent the entire file from being parsed abnormally due to the unconfigured BAI CODE, the implementation of the subsequent compensation parsing strategy is designed to ensure the system's flexible processing capabilities for incomplete configurations, especially in the complex environment of cross-border payments.

[0109] Due to the continuous expansion of bank transaction types, new BAI CODEs may not be configured with parsing rules immediately. To prevent these new BAI CODEs from causing parsing errors or interrupting the entire transaction file processing, subsequent compensatory parsing, i.e., partial parsing strategy, is implemented to allow the system to identify and mark those unknown or unconfigured BAI CODEs, so that they can be reprocessed after the complete parsing rules are supplemented in the future.

[0110] Before parsing the XML file, a pre-parsing step is performed, including scanning all transaction nodes in the file and storing their path information in the database, such as / / Document[0] / BkToCstmrStmt[0] / Stmt[0] / Ntry[0]. Each node path contains the BAI CODE we mentioned earlier, where Ntry represents the transaction information node. The purpose of storing the node path information is to identify the processing status of each transaction node, especially those nodes that are in a pending state due to the BAI CODE for which the parsing rules are not configured.

[0111] After the node path information and its related BAI CODE are stored, the system dynamically resolves these transactions according to the configured BAI CODE resolution rules. This dynamic resolution support not only improves the flexibility of data processing, but also speeds up the processing speed. Whenever the data of a node is successfully resolved, the corresponding path information will be updated to a successful state. For those nodes that failed to be successfully resolved due to the BAI CODE not being configured, they will remain in a pending state and wait for future resolution rules to be updated and then resolved again. In this way, the purpose of resolving nodes with BAI CODE resolution rules configured is given priority, and resolving nodes without BAI CODE is postponed, thereby improving the efficiency of account entry.

[0112] This subsequent compensation method effectively manages and optimizes the parsing process, especially when faced with frequently changing bank transaction formats. It not only ensures accurate parsing of transaction data, but also greatly reduces the risk of delayed entry and fund processing errors caused by parsing failures. This subsequent compensation parsing method ensures that the system remains stable and responsive even in the face of incomplete configurations.

[0113] Furthermore, in step S3, using a custom conditional expression of general analysis to extract corresponding field information includes:

[0114] One or more general parsing templates are set, and the general parsing includes the specified fields in the transaction file and the corresponding conditional expressions; wherein the conditional expressions are set based on the data type and structure of the specified fields to obtain the corresponding field information.

[0115] It should be noted that in order to ensure the standardized analysis of CAMT message files of various banks, a set of widely applicable standard parsing templates are defined for each file type. For example, for the bank JPM_SG, the following standard templates are assigned to the two types of files CAMT05200102 and CAMT05300102:

[0116] Configuration Number Standard template number Bank Name File Type JPM_SG_052 STD_CAMT052 JPM_SG CAMT05200102 JPM_SG_053 STD_CAMT053 JPM_SG CAMT05300102

[0117] The standard template sets the required field information parsing expression, i.e., the custom conditional expression. Taking the standard template STD_CAMT052 as an example, the following parsing expressions are set for the common standard fields, such as major account number, bank serial number, amount, currency, and payment card number:

[0118]

[0119] The following are the specific meanings of the above analytical expressions:

[0120] Large account: The expression is ${firstNotEmpty(acct.acct.id.othr.id,acct.acct.id.iban)};

[0121] Among them, firstNotEmpty is a custom or predefined function that returns the first non-empty value in its parameter list. acct.acct.id.othr.id and acct.acct.id.iban: are object paths that point to specific data fields in XML or similar structures. acct.acct.id.othr.id refers to an alternate identifier for the account, while acct.acct.id.iban refers to the international bank account number. Bank serial number: The expression is ${txDtl.refs.acctSvcrRef};

[0122] Among them, txDtl.refs.acctSvcrRef is the object path, pointing to the account service reference number in the transaction details, which is usually used to uniquely identify the transaction.

[0123] Amount: The expression is ${txDtl.amtDtls.txAmt.amt.value};

[0124] Among them, txDtl.amtDtls.txAmt.amt.value is the object path, which directly points to the value of the transaction amount.

[0125] Currency: The expression is ${txDtl.amtDtls.txAmt.amt.ccy};

[0126] Among them, txDtl.amtDtls.txAmt.amt.ccy is the object path, pointing to the currency unit of the transaction amount, such as USD, EUR, etc.

[0127] Payment card number: the expression is ${acct.acct.id.othr.id};

[0128] Among them, acct.acct.id.othr.id is the object path, which points to an alternative identifier of the account, usually used to identify the card number or account number of the receiving account.

[0129] Further, in step S3, according to the specified field to be extracted from the transaction record, extracting the field information by using the parsing rule of the BAI CODE corresponding to the specified field includes:

[0130] Initialize data objects to map various transaction nodes in the transaction file and ensure that the data objects are directly associated with the transaction nodes in the transaction file, wherein the data objects include transaction details objects and account statement objects;

[0131] Create an environment variable of type Map to store one or more data objects that need to be referenced when the Aviator expression is executed;

[0132] Write Aviator expressions to define the extraction logic of data objects, and compile Aviator expressions into executable Java bytecodes for data extraction;

[0133] Based on the created environment variables, the compiled Aviator expression is executed, the field information of the specified field is extracted, the exception is processed, and the corresponding result is output.

[0134] Furthermore, writing an Aviator expression to define the extraction logic of a data object includes:

[0135] In the Aviator expression, directly access the data object stored in the environment variable to obtain the corresponding field information;

[0136] The status of field information is determined through conditional logic, and string preprocessing and data integration are performed on field information that meets the conditional logic.

[0137] Use regular expressions to process the matched and integrated strings, and extract the corresponding field information based on the matching results.

[0138] If the regular expression matches successfully and the field information is extracted, the field information is returned as the result. If the field information is not successfully matched, the field information extracted by the custom conditional expression of the general analysis is returned as the data.

[0139] It should be specifically noted that, on the basis of providing standard templates, flexible configuration strategies are implemented to cope with the diversity of BAICODEs and corresponding field value rules that may be customized by various banks. Although most fields can be uniformly processed through parsing expressions in standard templates, some fields may require special processing. This is usually because each BAI CODE may define different transaction types and formats of specific fields. Therefore, standard templates can reduce unnecessary repeated configurations as much as possible and only care about the value logic of special fields. In actual situations, these special field information is often the most important and the most error-prone.

[0140] As shown in the table below, we reconfigure the value rules for the payment card number of JPM_SG_052 when the BAI CODE is 206. The specific configuration is as follows:

[0141]

[0142] Use the regular expression "(?<=VXR / )(.+?)(?= / )" to match the content of "txDtl.rmtInf.ustrd". If no result is matched, the expression acct.acct.id.othr.id is used for value. This expression is designed to identify string fragments after and before a specific format to extract key transaction data. This is the core meaning of configuring parsing based on BAI CODE. For each BAI CODE, a special value-taking method is independently configured to cover the expression in the standard template. If the above regular expression fails to successfully match any result, the system will fall back to using acct.acct.id.othr.id as the value of the payment card number to ensure the integrity and accuracy of data extraction.

[0143] This strategy ensures that data can be extracted accurately even when the field value rules of a specific BAI CODE are different, thereby maintaining the accuracy and reliability of transaction processing. This approach not only optimizes configuration management during the parsing process, but also improves the scalability and maintainability of the system, allowing for rapid adaptation to changes in bank interfaces and transaction standards.

[0144] Furthermore, based on the created environment variables, the compiled Aviator expression is executed to extract the field information of the specified field, and the corresponding results are output including:

[0145] Use the substring method of the Java String class to extract the expression text that needs to be executed by the Aviator expression engine from the string containing the complete expression;

[0146] Compile the expression text into an executable expression object based on the AviatorEvaluator.compile method in the Aviator library;

[0147] The compiled expression object is executed through the compiledExp.execute(env) method in the Aviator library, where env is an environment variable of type Map, which is used to store the fields that need to be referenced when executing the expression object and output the corresponding results.

[0148] This implementation provides a clearly structured, easy-to-maintain and highly scalable solution that effectively addresses the various challenges of traditional methods, especially when processing complex international bank transaction data, ensuring the accuracy and timeliness of data processing, and bringing greater value to banks and customers. Its main advantages include: ① Supporting rapid access to all banks that can provide standard CAMT messages, improving the versatility and flexibility of the system. ② BAI CODE collection and analysis ensures the accuracy of transaction data parsing, and clear parsing rules significantly improve the efficiency of account entry, while significantly reducing the risk of capital loss due to parsing errors. ③ Supporting flexible response to changes in bank message formats, only by adjusting the field parsing rules to adapt, without the need for a comprehensive system upgrade or re-release, greatly reducing operation and maintenance costs. ④ All bank-specific parsing requirements are clearly defined through BAI CODE's parsing rules, making subsequent maintenance and adjustments more intuitive and easy to understand.

[0149] Second embodiment

[0150] Based on the same inventive concept, the present invention also provides a system for improving the efficiency of cross-border payment entry, which is used to implement the above-mentioned method for improving the efficiency of cross-border payment entry, including:

[0151] a data receiving module for responding to a transaction file from a bank;

[0152] The data parsing module is used to pre-parse the transaction file, scan and identify all transaction nodes in the transaction file, store the path information of each transaction node in the database, and perform dynamic configuration parsing rule detection; among them, it is determined whether the BAI CODE in the transaction node has an associated parsing rule. If there is a parsing rule, the Aviator expression engine is used to dynamically adjust and extract field information according to the parsing rule; if there is no BAI CODE with a parsing rule, the transaction node corresponding to the BAI CODE is marked as pending for subsequent compensation parsing;

[0153] The data processing module is used to extract the field information according to the specified fields to be extracted from the transaction records through the parsing rules of the BAICODE corresponding to the specified fields. For the specified fields that are not configured with parsing rules or are not covered by the BAICODE, the custom conditional expressions of the general parsing are used to extract the corresponding field information;

[0154] The data output module is used to integrate the extracted field information into a complete transaction record for accounting processing.

[0155] In this embodiment, the specific details of the system execution are the same as those of the first embodiment, and will not be described in detail in this embodiment.

[0156] Third embodiment

[0157] In order to more fully understand the technical implementation and application effects of the present invention, this section Figure 2 , Figure 3 , Figure 4 and Figure 5 The relevant graphical implementation details are shown. These graphical examples describe in detail the process of parsing and processing and the interface design in the method for improving the efficiency of cross-border payment entry, so as to facilitate users and developers to understand and implement the present invention more intuitively:

[0158] like Figure 2 As shown, Figure 2 This is a flowchart of the analysis process in the method for improving the efficiency of cross-border payment entry in the present invention. The specific operation steps are:

[0159] (1) The system first executes the scheduled task and automatically downloads the CAMT052 and CAMT053 files provided by the bank.

[0160] (2) Scan the file and perform the first analysis on the downloaded file. At this time, the pre-analysis mode is turned on to save all the node path information in the file. The secondary analysis directly queries the pre-analysis results, that is, in the subsequent processing, the system will directly query these pre-analysis results to improve processing efficiency.

[0161] (3) Obtain the corresponding parsing template based on the bank and file type.

[0162] (4) Check whether the required template configuration parsing template exists.

[0163] (5) If it does not exist, trigger an alarm and check the correctness of the template configuration. If it does exist, obtain all BAI CODE configuration parsing rules from the template and store these rules in memory for quick access.

[0164] (6) Poll the pre-parsed results of the current bank, check all unprocessed node paths, and extract the current BAI CODE directly from the node-mapped Java object.

[0165] (7) For each BAI CODE, determine whether the corresponding parsing rules have been configured.

[0166] (8) If there is no configuration rule, the system will trigger an alarm and check the template configuration. If there is a configuration rule, the expression parser is used to parse the data according to the configuration rule. The expression parser is the Aviator expression engine.

[0167] (9) Once all pre-parsed paths have been processed, the parsing process ends.

[0168] This process ensures that large amounts of cross-border payment data can be processed efficiently, while adapting to the data formats of different banks through dynamically configured parsing rules, ensuring the accuracy and flexibility of data processing.

[0169] These flowcharts provide a visual representation of different scenarios of query processing and how the system intelligently responds to each situation to optimize performance and stability.

[0170] like Figure 3 As shown in the figure, a parsing template is configured for each bank. Take one of the standard templates CAMT05300102_20230601 as an example. This template can be used by all banks. The template details are as follows Figure 4 As shown in the figure, a number of general field value rules are set. These general fields are not related to BAI CODE. For some special value methods related to BAI CODE, please refer to the subsequent personalized configuration. Taking the field of payeeCardNo as an example, its value expression is: ${firstNotEmpty(acct.acct.id.othr.id,acct.acct.id.IBAN)}, which means that the first non-empty value of the two nodes acct.acct.id.othr.id and acct.acct.id.IBAN is taken from left to right.

[0171] like Figure 4 As shown, for the configuration parsing rule of CAMT053 of JPM_EU bank, the configuration number is Figure 2 JPM_EU_053_20230606 in the example; the configuration details of its BAI CODE are as follows: Compared with the expression of the payment card number payeeCardNo set in the standard template:

[0172] ${firstNotEmpty(acct.acct.id.othr.id,acct.acct.id.IBAN)}. When BAICODE is 206, the value expression is reset to:

[0173] ${if(txDtl.rmtInf.ustrd==nil||is_empty(txDtl.rmtInf.ustrd)){return"";}letallStr=string.join(txDtl.rmtInf.ustrd,"");letcardNo=inboundCfgFun.match(allStr,"(?<=VXR / )(.+?)(?= / )");ifcardNo!=""{returncard No;}ifacct.acct.id.othr.id!=nil{returnacct.acct.id.othr.id;}return"";}Its meaning is: use the regular expression "(?<=VXR / )(.+?)(?= / )" to match the content of txDtl.rmtInf.ustrd. If no match is found, the expression acct.acct.id.othr.id is used to get the value.

[0174] The following is a detailed explanation of its value expression:

[0175] The purpose of this code is to extract the content that matches the regular expression "(? <= VXR / )(.+?)(? = / )" from the txDtl.rmtInf.ustrd field, which means the string after "VXR / " and before " / " as the card number. If no match is found, the code will try to use the account identifier acct.acct.id.othr.id. If none of these are available, an empty string is returned.

[0176] Regarding if(txDtl.rmtInf.ustrd == nil||is_empty(txDtl.rmtInf.ustrd)){return"";}, the logic is that if the txDtl.rmtInf.ustrd field is nil or empty, an empty string "" is returned, indicating that the field has no content. If is a conditional judgment statement, txDtl.rmtInf.ustrd is the unstructured remark information field rmtInf.ustrd in the transaction details txDtl, and nil indicates an empty value or a non-existent value. is_empty() is a function used to determine whether a given string is empty.

[0177] About let allStr=string.join(txDtl.rmtInf.ustrd,""); let is a variable declaration statement, used to define a new variable. allStr is the name of the newly defined variable, which means that the contents in txDtl.rmtInf.ustrd are combined into a complete string. string.join() is a string concatenation function, which concatenates all elements in the txDtl.rmtInf.ustrd array into a string.

[0178] let cardNo=inboundCfgFun.match(allStr,"(?<=VXR / )(.+?)(?= / )");is used to find the substring that matches the regular expression pattern in allStr and store it in cardNo. , where let is a variable declaration statement, cardNo is the newly defined variable name used to store the card number obtained by regular expression matching, and inboundCfgFun.match() is a function used to perform regular expression matching operations in a string.

[0179] Regarding if (cardNo! = "") {returncardNo;}, if cardNo is not empty, cardNo is returned, that is, the card number extracted by the regular expression.

[0180] Regarding if (acct.acct.id.othr.id != nil) {returnacct.acct.id.othr.id;}, if the account identifier acct.acct.id.othr.id is not nil, the identifier is returned.

[0181] About return ""; if all the above conditions are not met, an empty string "" is returned

[0182] The following is a description of the specific embodiments, taking the bank JPM_SG mentioned above and the message format CAMT05200102 as an example:

[0183] Add a new rule configuration with the configuration number JPM_SG_052, and associate it with the already set standard template STD_CAMT052, which contains the parsing rule configuration for all field information.

[0184] For this rule, the configuration number is JPM_SG_052, and the parsing rules for all special fields of this bank are configured in the BAICODE dimension. The parsing rules set here will overwrite the parsing rules for the same fields in the standard template.

[0185] After the configuration is completed, pre-analysis begins. The pre-analysis results, i.e. the node path information representing the transaction, are stored in the database for persistence. The node information format is as follows:

[0186] / / Document[0] / BkToCstmrStmt[0] / Stmt[0] / Ntry[0],

[0187] / / Document[0] / BkToCstmrStmt[0] / Stmt[0] / Ntry[1],

[0188] The format of the node path information is an XPath expression, which is used to accurately locate a specific element or node in an XML document.

[0189] The initial status of data record is "pending".

[0190] After the pre-analysis is completed, the pre-analyzed transaction path set is polled and formal analysis is started record by record. Check whether the BAICODE corresponding to each transaction path has the configured analysis rules. If yes, start the analysis. After the analysis is completed, the status is set to successful status. If no, keep the pending status and wait for subsequent compensation.

[0191] Expression parsing is supported by the Aviator expression engine. Let’s take the payment card number field mentioned above as an example:

[0192] Map<String,Object> env = new HashMap<>();

[0193] This code is used to create an environment variable of type Map to store one or more data objects that the Aviator expression needs to reference when executing.

[0194] Map<String,Object> In Java, Map is a data structure used to store key-value pairs. In this Map, the key type is String, which is used to identify the name or identifier of each data object, and the value type is Object, which can store any type of data object, such as a string, a number, or a complex object (such as an instance of a Java class).

[0195] In env=newHashMap<>(), HashMap is an implementation of the Map interface, which stores key-value pairs in the form of a hash table. This data structure provides efficient search and storage functions. newHashMap<>() creates a new HashMap object in memory. By env=newHashMap<>(), a HashMap instance named env is created, and this env will be used to store data objects.

[0196] The env variable is used to store data objects that need to be referenced when Aviator expressions are executed. By putting these objects in env, the expression engine can dynamically access and use these data as needed when executing expressions. For example, env.put("txDtl",entryTransaction); in the code will add an object named txDtl (such as entryTransaction) to env for subsequent expression parsing.

[0197]

[0198]

[0199] This expression is defined as a string expression and is contained in ${}, which indicates that it is an Aviator expression that needs to be executed in a specific environment. Among them, txDtl.rmtInf.ustrd is a field in the transaction details object, ==nil checks whether the field is null (that is, it does not exist), and is_empty(txDtl.rmtInf.ustrd) checks whether the field is empty or the content is empty. If this field is null or empty, the expression will return an empty string "", indicating that there is no card number to be extracted.

[0200] Use the string.join function to join all the strings in the txDtl.rmtInf.ustrd field into a single string allStr. This operation is necessary because the ustrd field may contain multiple parts that need to be joined into a complete string.

[0201] Use the inboundCfgFun.match method to find a substring in allStr that matches a specific pattern. The meaning of the regular expression (? <= VXR / )(.+?)(? = / ):

[0202] (?<=VXR / ): indicates matching a string starting with VXR / but not including VXR / itself.

[0203] (.+?): Matches any character after VXR / until the next / is encountered.

[0204] (?= / ): means matching the part ending with / , but not including / itself.

[0205] If a substring matching the regular expression is found, it is stored in the cardNo variable.

[0206] Regarding if cardNo! = \"\"{return cardNo;}, it checks whether the cardNo is successfully extracted, that is, whether the matching result is empty. If the extracted cardNo is not empty, the cardNo is returned as the value of the payment card number.

[0207] The main function of this expression is to extract the value of the "receiving card number" field from the incoming transaction details object and account information object. It first tries to extract the card number from the ustrd field of the transaction details through a regular expression. If it fails, it uses the acct.id.othr.id field of the account information as a fallback. If all methods fail, an empty string is returned.

[0208] String copyExpression=expression.substring(2,expression.length()-1);

[0209] In the above code, expression is a string variable that contains the complete Aviator expression. The expression format is surrounded by ${}, such as ${...}.

[0210] And about substring(2,expression.length()-1):

[0211] substring(int beginIndex, int endIndex) is a method of Java string class, which is used to extract the part of the string starting from beginIndex to before endIndex;

[0212] The beginIndex parameter is set to 2, which means that the content is extracted from the third character of the string (index starts at 0). Since { occupies the first two characters, index 2 skips and { and starts extracting the actual content of the expression.

[0213] The expression.length()-1:endIndex parameter is set to the total length of the expression minus 1, which means it will extract the second to last character of the string. This is done to remove the} symbol at the end of the expression.

[0214] The purpose of this line of code is to remove the part surrounded by ${} and keep only the core content of the expression so that it can be compiled and executed later.

[0215]

[0216]

[0217] System.out.println("Expression parsing result ===>"+execute);

[0218] About compiling expressions:

[0219] Expression compiledExp=AviatorEvaluator.compile(copyExpression,true);

[0220] AviatorEvaluator.compile(String expression, boolean cached), compile is a method of Aviator expression engine, which is used to compile string expression into executable Expression object; copyExpression: This is the actual expression content extracted by substring method; true: It means that the compiled expression will be cached. If the same expression is compiled again, Aviator will directly use the compiled result in cache to improve performance.

[0221] About executing expressions:

[0222]

[0223] Among them, compiledExp.execute(env), the execute method is used to execute the compiled expression; env: is a Map<String,Object> The environment variable of type stores the data objects required when the expression is executed (such as txDtl and account). The execute variable stores the result of the expression execution. The result type is Object, because the return value of the expression may be different types of data.

[0224] At the same time, the code involves exception handling try-catch blocks to capture exceptions that may occur during the expression execution process, GateWayException: If an error occurs when executing an expression (for example, the expression is illegal, the environment variable is missing, etc.), a GateWayException will be thrown with specific information about the expression parsing failure.

[0225] Fourth embodiment

[0226] In some embodiments of the present application, an electronic device is also provided. The electronic device includes a memory and a processor, wherein the memory is used to store a processing program; when the processor executes the processing program, the method for improving the efficiency of cross-border payment entry as described in the embodiment of the present invention is implemented. When the processor executes the processing program, the method for improving the efficiency of cross-border payment entry in the aforementioned embodiment is implemented.

[0227] Fifth embodiment

[0228] The present invention provides a readable storage medium, on which a processing program is stored, and when the processing program is executed by a processor, a method for improving the efficiency of cross-border payment entry as described in an embodiment of the present invention is implemented. A computer-readable storage medium may be a tangible device that can hold and store instructions used by an instruction execution device. The computer-readable storage medium may be, for example, - but not limited to - an electrical storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the above. More specific examples (a non-exhaustive list) of computer-readable storage media include: a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), a static random access memory (SRAM), a portable compact disk read-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk, a mechanical encoding device, such as a punch card or a protruding structure in a groove on which instructions are stored, and any suitable combination of the above. The computer-readable storage medium used herein is not to be construed as a transient signal per se, such as a radio wave or other freely propagating electromagnetic wave, an electromagnetic wave propagating through a waveguide or other transmission medium (e.g., light pulses through a fiber optic cable), or an electrical signal transmitted through wires.

[0229] The embodiments of the present disclosure have been described above, and the above description is exemplary, not exhaustive, and is not limited to the disclosed embodiments. Many modifications and changes will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the described embodiments. The selection of terms used herein is intended to best explain the principles of the embodiments, practical applications, or technical improvements in the market, or to enable other persons of ordinary skill in the art to understand the embodiments disclosed herein.

Claims

1. A method for improving the efficiency of cross-border payment entry, characterized in that: include: Step S1, responding to the transaction file of the bank; Step S2, pre-parse the transaction file, scan and identify all transaction nodes in the transaction file, store the path information of each transaction node in the database, and perform dynamic configuration parsing rule detection; wherein, Determine whether the BAI CODE in the transaction node has an associated parsing rule. If the parsing rule exists, use the Aviator expression engine to dynamically adjust and extract field information according to the parsing rule; if the BAI CODE with the parsing rule does not exist, mark the transaction node corresponding to the BAI CODE as pending for subsequent compensation parsing; Step S3, according to the designated field to be extracted from the transaction record, extract the field information by using the parsing rule of the BAI CODE corresponding to the designated field, and for the designated field that the BAI CODE does not configure the parsing rule or is not covered by the BAI CODE, use the custom conditional expression of the general parsing to extract the corresponding field information; Step S4, integrating the extracted field information to form a complete transaction record for account entry processing.

2. The method for improving the efficiency of cross-border payment entry according to claim 1, characterized in that: In step S2, pre-parsing the transaction file, scanning and identifying all transaction nodes in the transaction file, storing the path information of each transaction node in a database, and performing dynamic configuration parsing rule detection include: Pre-initial pre-parsing scans the entire transaction file, identifies and records the path information of each transaction node; storing the path information in the database, and initially marking each of the transaction nodes as being in the pending state; According to the stored path information, determining whether the BAI CODE of each transaction node has a corresponding parsing rule; When the BAI CODE has been configured with the corresponding parsing rule, the Aviator expression engine dynamically extracts the corresponding field information according to the parsing rule, and updates the status mark to a successful status according to the parsing result; When the BAI CODE of the transaction node is not configured or the parsing rule fails to parse, the transaction node is marked as the pending state.

3. The method for improving the efficiency of cross-border payment entry according to claim 1, characterized in that: In step S2, the transaction node corresponding to the BAI CODE is marked as pending, and subsequent compensation analysis includes: Checking the transaction nodes in the database marked as the pending state; Determine whether the re-parsing is successful after the parsing rule in the BAI CODE in the transaction node is added or updated; If the parsing is successful, the transaction node corresponding to the BAI CODE in the database is updated to the success state; If the parsing fails, the pending state of the BAI CODE is maintained until the next parsing rule can be successfully parsed.

4. The method for improving the efficiency of cross-border payment entry according to claim 1, characterized in that: In step S3, using a custom conditional expression of general analysis to extract the corresponding field information includes: One or more general parsing templates are set, and the general parsing includes the specified fields in the transaction file and the corresponding conditional expressions; wherein the conditional expressions are set based on the data type and structure of the specified fields to obtain the corresponding field information.

5. The method for improving cross-border payment efficiency according to claim 1, characterized in that: In step S3, according to the specified field to be extracted from the transaction record, extracting the field information by using the parsing rule of the BAI CODE corresponding to the specified field includes: Initializing data objects to map each of the transaction nodes in the transaction file and ensuring that the data objects are directly associated with the transaction nodes in the transaction file, wherein the data objects include a transaction detail object and an account statement object; Create an environment variable of type Map to store one or more data objects that need to be referenced when the Aviator expression is executed; Writing the Aviator expression to define the extraction logic of the data object, and compiling the Aviator expression into executable Java bytecode to perform data extraction; Based on the created environment variable, the compiled Aviator expression is executed, the field information of the specified field is extracted, and the corresponding result is output.

6. The method for improving the efficiency of cross-border payment entry according to claim 5, characterized in that: Writing the Aviator expression to define the extraction logic of the data object includes: Directly access the data object stored in the environment variable in the Aviator expression to obtain the corresponding field information; The state of the field information is determined by conditional logic, and string preprocessing and data integration are performed on the field information that meets the conditional logic; Processing the matched and integrated character string through a regular expression, and extracting the corresponding field information according to the matching result; If the regular expression matches successfully and the field information is extracted, the field information is used as the return result. If the field information is not matched successfully, the field information extracted by the custom conditional expression of the general analysis is used as the return data.

7. The method for improving the efficiency of cross-border payment entry according to claim 6, characterized in that: Based on the created environment variable, the compiled Aviator expression is executed, the field information of the specified field is extracted, and the corresponding results are outputted, including: Extracting the expression text to be executed by the Aviator expression engine from the string containing the complete expression through the substring method of the Java String class; Compile the expression text into an executable expression object based on the AviatorEvaluator.compile method in the Aviator library; The compiled expression object is executed through the compiledExp.execute(env) method in the Aviator library, wherein the env is the environment variable of the Map type, which is used to store the fields that need to be referenced when executing the expression object, and output the corresponding result.

8. A system for improving the efficiency of cross-border payment entry, characterized in that: include: a data receiving module for responding to a transaction file from a bank; A data parsing module is used to pre-parse the transaction file, scan and identify all transaction nodes in the transaction file, store the path information of each transaction node in the database, and perform dynamic configuration parsing rule detection; wherein, it is determined whether the BAI CODE in the transaction node has an associated parsing rule. If the parsing rule exists, the Aviator expression engine is used to dynamically adjust and extract field information according to the parsing rule; if the BAI CODE of the parsing rule does not exist, the transaction node corresponding to the BAI CODE is marked as pending for subsequent compensation parsing; A data processing module is used to extract the field information of the specified field to be extracted from the transaction record by using the parsing rule of the BAI CODE corresponding to the specified field, and to extract the corresponding field information by using the custom conditional expression of the general parsing for the specified field that is not configured with the parsing rule or is not covered by the BAI CODE; The data output module is used to integrate and extract the field information to form a complete transaction record for account entry processing.

9. An electronic device, characterized in that: include: A memory, the memory being used to store a processing program; A processor, wherein when executing the processing program, the processor implements the method for improving the efficiency of cross-border payment entry as described in any one of claims 1 to 7.

10. A readable storage medium, characterized in that: The readable storage medium stores a processing program, and when the processing program is executed by the processor, the method for improving the efficiency of cross-border payment entry as described in any one of claims 1 to 7 is implemented.

Images