Data processing methods, apparatus, electronic devices and storage media

Abstract

This invention discloses a data processing method, apparatus, electronic device, and storage medium. The method includes: upon receiving a transaction request, determining a requester identifier corresponding to the transaction request; determining a request verification result for verifying the transaction request based on a standard message format corresponding to the requester identifier; if the request verification result indicates the request is valid, processing the transaction data corresponding to the transaction request based on preset verification rules to determine a data verification result; and based on the data verification result, determining a target processing method for processing the transaction request, and obtaining an execution result corresponding to the transaction request based on the target processing method. This solves the problems of low transaction efficiency and poor accuracy caused by manual transaction review in the prior art, achieving the effect of improving transaction security while simultaneously improving transaction convenience and accuracy.

Description

Technical Field

[0001] This invention relates to the field of computer processing technology, and in particular to a data processing method, apparatus, electronic device, and storage medium. Background Technology

[0002] With the development of the social economy, in order to better meet the transaction needs of merchants or institutions, it is usually necessary to manage the transaction information submitted by users with transaction needs.

[0003] Currently, transaction management typically involves manually verifying the transaction information submitted by the user on the corresponding trading institution's website or in person, obtaining the transaction certificate, and then manually processing the transaction in the settlement system. This method is not only inefficient but also prone to errors due to operator mistakes. Summary of the Invention

[0004] This invention provides a data processing method, apparatus, electronic device, and storage medium to achieve the technical effect of improving transaction security while simultaneously enhancing transaction convenience and accuracy.

[0005] According to one aspect of the present invention, a data processing method is provided, the method comprising:

[0006] Upon receiving a transaction request, determine the requester identifier corresponding to the transaction request;

[0007] Based on the standard message format corresponding to the requester identifier, determine the request verification result for verifying the transaction request;

[0008] If the request verification result is that the request is valid, then the transaction data corresponding to the transaction request is processed based on the preset verification rules to determine the data verification result; wherein, the preset verification rules include transaction validity rules, transaction security rules and user validity rules;

[0009] Based on the data verification results, a target processing method is determined for processing the transaction request, so as to obtain an execution result corresponding to the transaction request based on the target processing method.

[0010] According to another aspect of the present invention, a data processing apparatus is provided, the apparatus comprising:

[0011] The requester identifier determination module is used to determine the requester identifier corresponding to the transaction request when a transaction request is received;

[0012] The request verification result determination module is used to determine the request verification result for verifying the transaction request based on the standard message format corresponding to the requester identifier;

[0013] The data verification result determination module is used to process the transaction data corresponding to the transaction request based on preset verification rules and determine the data verification result if the request verification result is that the request is valid; wherein, the preset verification rules include transaction validity rules, transaction security rules and user validity rules;

[0014] The target processing method determination module is used to determine the target processing method for processing the transaction request based on the data verification result, so as to obtain the execution result corresponding to the transaction request based on the target processing method.

[0015] According to another aspect of the present invention, an electronic device is provided, the electronic device comprising:

[0016] At least one processor; and

[0017] A memory communicatively connected to the at least one processor; wherein,

[0018] The memory stores a computer program that can be executed by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform the data processing method according to any embodiment of the present invention.

[0019] According to another aspect of the present invention, a computer-readable storage medium is provided, the computer-readable storage medium storing computer instructions for causing a processor to execute and implement the data processing method described in any embodiment of the present invention.

[0020] The technical solution of this invention, upon receiving a transaction request, determines the requester identifier corresponding to the transaction request; based on the standard message format corresponding to the requester identifier, determines the request verification result for verifying the transaction request; if the request verification result is valid, the transaction data corresponding to the transaction request is processed based on preset verification rules such as transaction validity rules, transaction security rules, and user validity rules to determine the data verification result; based on the data verification result, the target processing method for processing the transaction request is determined, and the execution result corresponding to the transaction request is obtained based on the target processing method. This solves the problems of low transaction efficiency and poor accuracy caused by manual transaction review, and realizes the verification of transaction requests based on the standard message format corresponding to the requester identifier that initiated the transaction request, thereby strengthening the monitoring of access requests. When the request verification result is valid, the transaction data corresponding to the transaction request is processed based on preset verification rules such as transaction validity rules, transaction security rules, and user validity rules to verify the validity of the user, the validity of the transaction, and the security of the transaction, obtaining the data verification result. Then, based on the data verification result, the target processing method for processing the transaction request is determined, achieving the technical effect of improving the security, convenience, and accuracy of transaction request processing.

[0021] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of the present invention, nor is it intended to limit the scope of the invention. Other features of the invention will become readily apparent from the following description. Attached Figure Description

[0022] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0023] Figure 1 This is a flowchart of a data processing method provided according to Embodiment 1 of the present invention;

[0024] Figure 2 This is a schematic diagram of the data processing method provided in Embodiment 2 of the present invention;

[0025] Figure 3 This is a schematic diagram of the data processing method provided in Embodiment 2 of the present invention;

[0026] Figure 4 This is a schematic diagram of the structure of a data processing device according to Embodiment 3 of the present invention;

[0027] Figure 5This is a schematic diagram of the structure of an electronic device that implements the data processing method of the present invention. Detailed Implementation

[0028] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0029] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0030] Example 1

[0031] Figure 1 This is a flowchart of a data processing method according to Embodiment 1 of the present invention. This embodiment is applicable to transaction processing. The method can be executed by a data processing device, which can be implemented in hardware and / or software and can be configured in a computing device. Figure 1 As shown, the method includes:

[0032] S110. Upon receiving a transaction request, determine the requester identifier corresponding to the transaction request.

[0033] A transaction request can be understood as a program or code that requests a transaction to be conducted. It can be a request for the transfer of rights or interests, or a request for the transfer of rights or interests. The requester identifier can be used to identify the uniqueness of the transaction requester, who can be an individual, enterprise, institution, department, etc.

[0034] In this embodiment, when a transaction request is received, the transaction request can be parsed to obtain the requester identifier of the transaction requester carried on the transaction request.

[0035] S120. Based on the standard message format corresponding to the requester's identifier, determine the request verification result for verifying the transaction request.

[0036] It should be noted that, to enhance risk control, each transaction requester can pre-set and transmit its own defined specifications to the system, such as a standard message format for standardizing messages. For example, this can be in XML, JSON, or a message format that includes pre-defined message type, message version, message length, and message entity information. This allows the system to verify transaction requests sent by the requester based on the standard message format.

[0037] In this embodiment, after determining the requester identifier, the standard message format corresponding to the requester identifier can be retrieved, and the transaction request can be verified according to the standard message format, such as verifying whether the transaction request message matches the standard message format, to obtain the request verification result, and to determine whether the transaction request is a normal transaction based on the request verification result.

[0038] Optionally, the method for determining the request verification result for verifying a transaction request based on the standard message format corresponding to the requester identifier can be as follows: based on a pre-determined mapping relationship, determine the standard message format corresponding to the requester identifier; if the request message format corresponding to the transaction request is inconsistent with the standard message format, then determine the request verification result as invalid; if the request message format corresponding to the transaction request is consistent with the standard message format, then determine the request verification result as valid.

[0039] The mapping relationship includes the requester's identifier and the corresponding standard message format.

[0040] In practical applications, mapping techniques can be used to determine the standard message format associated with the requester's identifier. This standard message format is then compared with the request message format of the transaction request. If the two message formats match, the transaction request is considered normal, and the request verification result is valid. If the message formats do not match, the transaction request is considered abnormal, and the request verification result is invalid. For example, if the request message format of transaction request A is XML, and the corresponding standard message format is JSON, they are inconsistent, and the request verification result for transaction request A is invalid. When the request verification result is determined to be invalid, the transaction request can be marked as a restricted transaction, the transaction can be terminated, and feedback information regarding the restricted transaction can be generated and sent back to the transaction requester so that the transaction requester is promptly informed of the specific details of the transaction.

[0041] For example, newly added enterprises or financial institutions can distinguish messages (i.e., transaction request messages) by using specific points in their message content. Upon receiving a transaction request message, it is compared with a pre-defined standard message format. If the format is different, it indicates that the message is not a normal transaction and the transaction process can be terminated directly. If the format is the same, it indicates that the message is a normal transaction and the request verification result is that the request is valid.

[0042] S130. If the verification result of the request is that the request is valid, then the transaction data corresponding to the transaction request is processed based on the preset verification rules to determine the data verification result.

[0043] The preset verification rules may include, but are not limited to, transaction validity rules, transaction security rules, and user validity rules. Transaction validity rules can refer to rules used to verify whether a transaction is valid, such as serial number verification. Transaction security rules can refer to rules used to verify whether a transaction is secure, such as transaction value verification and transaction frequency verification. User validity rules can refer to rules used to verify whether the transaction requester is valid, such as user permission verification. Optionally, the preset verification rules may also include rules defined by the user according to business needs, such as value verification and date verification. Transaction data includes at least one of the following: transaction identifier, transaction type, transaction value, transaction date, requester identifier, processor identifier, and processing requirement information. The transaction identifier can be a transaction number, such as a serial number.

[0044] In this embodiment, if the request verification result indicates that the request is valid, the transaction data corresponding to the transaction request can be further verified using preset verification rules to obtain a data verification result. For example, this includes verifying whether the transaction frequency is within a preset controllable frequency range, verifying whether the transaction data sent by the requester can be processed, and verifying whether the order number in the transaction data is unique, etc. This ensures that the transaction request continues to be processed when the data verification result indicates successful verification, thus guaranteeing transaction security.

[0045] To facilitate data processing, transaction data corresponding to transaction requests can be processed based on preset verification rules. Before determining the data verification result, the transaction request can be parsed to obtain the transaction data corresponding to the transaction request; the transaction data can then be converted into a recognizable data stream.

[0046] Specifically, before determining the data verification result corresponding to the transaction request, the transaction request can be parsed first to obtain transaction data associated with the transaction request, such as transaction identifier, transaction type, transaction value, transaction date, requester identifier, processor identifier, and processing requirement information. Then, the transaction data can be converted into system-recognizable data as a recognizable data stream. At this time, the recognizable data stream is a unified, valid, and usable data stream within the system, and subsequent verification operations can be performed based on the recognizable data stream to determine the data verification result.

[0047] In this embodiment, the transaction data corresponding to the transaction request can be processed sequentially or in parallel based on the various verification rules in the preset verification rules to determine the data verification result. That is to say, different preset verification rules result in different ways of determining the data verification result.

[0048] Optionally, the preset verification rule is the transaction validity rule. Based on the preset verification rule, the transaction data corresponding to the transaction request is processed to determine the data verification result. The implementation method can be: check the transaction record database corresponding to the requester's identifier; if the transaction record database contains the request record corresponding to the transaction data, the data verification result is determined to be successful; if the transaction record database does not contain the request record, the data verification result is determined to be unsuccessful.

[0049] The transaction record database is used to store record information for transaction requests.

[0050] In this embodiment, after determining that the verification result of the transaction request is valid, a query message corresponding to the transaction requester is generated to query the transaction record database corresponding to the requester's identifier. This database is the transaction record database of the transaction requester. If the transaction record database contains a request record corresponding to the transaction data, the transaction is considered valid, and the data verification result is determined to be successful. If the transaction record database does not contain the request record, i.e., the transaction cannot be found, the data verification result is determined to be unsuccessful. When the data verification result is determined to be unsuccessful, the transaction request can be marked as a restricted transaction, the transaction can be terminated, and feedback information on the restricted transaction can be generated and sent back to the transaction requester so that the transaction requester can be informed of the specific details of the transaction in a timely manner.

[0051] For example, based on different transaction information formats, key information (i.e., transaction data) is extracted, the requester identifier of the transaction requester is determined, and a transaction query message corresponding to the requester identifier is assembled. The validity of the transaction request is checked. If the query cannot be found, it is determined that it is not a valid transaction, and only the transaction information is recorded without executing subsequent transaction operations.

[0052] Optionally, the preset verification rule is a user validity rule, and the transaction data includes a transaction identifier and a processor identifier. The transaction data corresponding to the transaction request is processed based on the preset verification rule to determine the data verification result. This can be achieved by: determining the number of identifiers in the identifier generation library that match the transaction identifier; if the number of identifiers is a preset number, determining whether the permission record library contains the requester identifier and the processor identifier; if they are contained, the data verification result is determined to be successful; if they are not contained, the data verification result is determined to be unsuccessful.

[0053] The identifier generation library stores historical transaction identifiers generated during historical request transactions, which can be represented by transaction numbers. The default quantity is 1. The permission record library stores the identifiers of the requester and the processor who have usage permissions.

[0054] In this embodiment, the transaction identifier in the transaction data can be compared with historical transaction identifiers in the identifier generation library to count the number of identifiers in the identifier generation library that match the transaction identifier. If the identifier count is not 1, it indicates that the transaction is not unique and may be a duplicate transaction. In this case, the transaction request can be marked as a restricted transaction, and the transaction process can be terminated. If the identifier count is 1, it indicates the uniqueness of the transaction. It can then be checked whether the permission record library contains the requester identifier and processor identifier from the transaction data. If they are contained, it indicates that the user is valid, the transaction is allowed, and the data verification result is determined to be successful. If they are not contained, it cannot be matched with a user with permissions in the system, the transaction is temporarily not allowed, and the data verification result is determined to be failed. When the data verification result is determined to be failed, a manual review process can be introduced to manually confirm the user's identity.

[0055] For example, it can be confirmed whether the processed transaction data (i.e., the identifiable data stream) is a duplicate transaction. If a duplicate transaction is found, the transaction process ends. If it is not a duplicate transaction, a user validity check is performed. If no user can be found in the system, the process proceeds to manual review to verify the user information. If the user information cannot be verified, the transaction fails.

[0056] Optionally, the preset verification rule is a transaction security rule. Based on the preset verification rule, the transaction data corresponding to the transaction request is processed to determine the data verification result. The implementation method can be as follows: determine the transaction attributes corresponding to the transaction data. The transaction attributes include at least one of transaction frequency, cumulative transaction data, and continuous non-transaction duration. If the transaction attributes meet the transaction security rule, the data verification result is determined to be successful. If at least one of the transaction attributes does not meet the transaction security rule, the data verification result is determined to be unsuccessful.

[0057] The transaction security rules include rules such as a transaction frequency lower than a preset transaction frequency, cumulative transaction data lower than a preset cumulative transaction value, and continuous non-transaction duration lower than a preset non-transaction duration.

[0058] In this embodiment, transaction attributes can be calculated from transaction data. For example, the current transaction information and the historical transaction information of the transaction requester within a unit time period (such as one month or three months) can be accumulated to obtain the cumulative transaction data as a transaction attribute. Alternatively, the interval between two transactions can be determined based on the transaction request time and the transaction time of the last transaction by the transaction requester, serving as the continuous non-transaction duration, i.e., a transaction attribute. Transaction attributes can be verified using transaction security rules, such as determining whether the transaction frequency is less than a preset transaction frequency, whether the cumulative transaction data is less than a preset cumulative transaction value, or whether the continuous non-transaction duration is less than a preset non-transaction duration. If all are true, the transaction attribute is considered to meet the transaction security rules, and the data verification result is determined to be successful. If not, at least one of the transaction attributes is considered to fail to meet the transaction security rules, and the data verification result is determined to be unsuccessful. This achieves risk monitoring of transaction data and improves transaction security.

[0059] For example, after confirming the data verification result as successful based on user validity rules, transaction security rule verification can be performed. If the security fails, a manual review stage can be initiated. If the manual review fails, the transaction is confirmed as failed, i.e., the verification fails.

[0060] In this embodiment, when the data verification result is verification failure, the process includes: sending the transaction data to the manual review module; receiving the review result from the manual review module based on the transaction data; and if the review result is successful, adjusting the data verification result to successful.

[0061] In this embodiment, when the data verification result is determined to be verification failure, the transaction data can be sent to the manual review module for manual review of the security of the transaction data. If the data is secure, the review result is passed; otherwise, it is rejected. After manual review, the review result can be fed back to the system. After receiving the review result from the manual review module, the system can determine whether the review result is passed. If it is, the data verification result is adjusted to successful; otherwise, the transaction request is marked as a restricted transaction, the transaction is terminated, and restricted transaction feedback information is generated and sent back to the transaction requester so that the transaction requester can be informed of the specific details of the transaction in a timely manner.

[0062] S140. Based on the data verification results, determine the target processing method for processing the transaction request, so as to obtain the execution result corresponding to the transaction request based on the target processing method.

[0063] Specifically, if the data verification result is a failure, the target processing method for the transaction request could be to mark the transaction request as a restricted transaction, terminate the transaction, and generate restricted transaction feedback information to be sent back to the transaction requester. If the data verification result is a successful verification, the transaction operation is automatically performed, such as transferring the rights to the transaction requester's account or transferring the rights to the transaction processor's account. It should be noted that after automatically completing the transaction operation, a scheduled task can also periodically request transaction vouchers from the corresponding transaction processor to prove the authenticity and validity of the transaction.

[0064] The technical solution of this embodiment, upon receiving a transaction request, determines the requester identifier corresponding to the transaction request; based on the standard message format corresponding to the requester identifier, determines the request verification result for verifying the transaction request; if the request verification result is valid, the transaction data corresponding to the transaction request is processed based on preset verification rules such as transaction validity rules, transaction security rules, and user validity rules to determine the data verification result; based on the data verification result, the target processing method for processing the transaction request is determined, and the execution result corresponding to the transaction request is obtained based on the target processing method. This solves the problems of low transaction efficiency and poor accuracy caused by manual transaction review, and realizes the verification of transaction requests based on the standard message format corresponding to the requester identifier that initiated the transaction request, thereby strengthening the monitoring of access requests. When the request verification result is valid, the transaction data corresponding to the transaction request is processed based on preset verification rules such as transaction validity rules, transaction security rules, and user validity rules to verify the validity of the user, the validity of the transaction, and the security of the transaction, obtaining the data verification result. Then, based on the data verification result, the target processing method for processing the transaction request is determined, achieving the technical effect of improving the security, convenience, and accuracy of transaction request processing.

[0065] Example 2

[0066] As an optional embodiment of the above embodiments, Figure 2 This is a schematic diagram of a data processing method provided in Embodiment 3 of the present invention. For details, please refer to the following specific content.

[0067] See Figure 3Upon receiving a transaction request, the system differentiates between different formats (such as XML or JSON) and determines whether the request message format matches the standard message format. If the formats differ, it indicates an invalid transaction, and the transaction process is terminated, resulting in a transaction failure. If the formats match, the system parses the transaction data based on the request message format to extract key information. It then assembles a transaction query message corresponding to the requester and checks the transaction's validity. If the query is unsuccessful, the transaction is deemed invalid, and only the transaction information is recorded without further action, resulting in a transaction failure. If the query is successful, the transaction is considered valid, and the information is organized into a unified and usable data stream (identifiable data stream) for subsequent operations. Further, based on the organized and identifiable data stream, the system checks if the transaction is a duplicate. If it is, the transaction process terminates. If it is not a duplicate, the system checks user validity. If a user cannot be identified within the system, the transaction is considered invalid and enters a manual review process for confirmation of the user information. If the user information cannot be confirmed, the transaction fails. If a user is identified within the system, the transaction is considered valid. Furthermore, after confirming user information, risk control rules are verified to determine transaction security. If risk control fails, a manual review stage is initiated; if the manual review also fails, the transaction fails. Once risk control is successful, the transaction is executed automatically. After automatic execution, a scheduled task can periodically request transaction vouchers from the corresponding transaction processor to prove the authenticity and validity of the transaction.

[0068] It should be noted that if new enterprises or financial institutions join the system, the standard message formats of each party can be saved. For example, see [link to example]. Figure 3 When a transaction requester (e.g., Requester A, Requester B, Requester C, Requester D, Requester E) requests a transaction, the system parses the message content (i.e., the transaction request) by distinguishing specific points in the message content. After parsing, the transaction request is formatted into a unified information format and then undergoes a series of risk control checks. If the checks pass, the transaction is automatically executed in the system. If the checks fail, manual review is conducted, and the transaction is automatically executed if the review is successful. The entire transaction process is processed programmatically. Each transaction message is strictly controlled according to the rules. If risk control or other checks fail, a manual review process is triggered. Different processing procedures are applied based on the reason for the failure, significantly reducing labor costs, improving the accuracy and convenience of transaction processing, effectively verifying transaction risk, and enhancing risk control.

[0069] The technical solution of this embodiment, upon receiving a transaction request, determines the requester identifier corresponding to the transaction request; based on the standard message format corresponding to the requester identifier, determines the request verification result for verifying the transaction request; if the request verification result is valid, the transaction data corresponding to the transaction request is processed based on preset verification rules such as transaction validity rules, transaction security rules, and user validity rules to determine the data verification result; based on the data verification result, the target processing method for processing the transaction request is determined, and the execution result corresponding to the transaction request is obtained based on the target processing method. This solves the problems of low transaction efficiency and poor accuracy caused by manual transaction review, and realizes the verification of transaction requests based on the standard message format corresponding to the requester identifier that initiated the transaction request, thereby strengthening the monitoring of access requests. When the request verification result is valid, the transaction data corresponding to the transaction request is processed based on preset verification rules such as transaction validity rules, transaction security rules, and user validity rules to verify the validity of the user, the validity of the transaction, and the security of the transaction, obtaining the data verification result. Then, based on the data verification result, the target processing method for processing the transaction request is determined, achieving the technical effect of improving the security, convenience, and accuracy of transaction request processing.

[0070] Example 3

[0071] Figure 4 This is a schematic diagram of the structure of a data processing device according to Embodiment 3 of the present invention. Figure 4 As shown, the device includes: a requester identifier determination module 310, a request verification result determination module 320, a data verification result determination module 330, and a target processing method determination module 340.

[0072] The system includes: a requester identifier determination module 310, used to determine the requester identifier corresponding to the transaction request upon receiving the transaction request; a request verification result determination module 320, used to determine the request verification result for verifying the transaction request based on the standard message format corresponding to the requester identifier; a data verification result determination module 330, used to process the transaction data corresponding to the transaction request based on preset verification rules if the request verification result indicates that the request is valid, and determine the data verification result; wherein the preset verification rules include transaction validity rules, transaction security rules, and user validity rules; and a target processing method determination module 340, used to determine the target processing method for processing the transaction request based on the data verification result, so as to obtain the execution result corresponding to the transaction request based on the target processing method.

[0073] The technical solution of this embodiment, upon receiving a transaction request, determines the requester identifier corresponding to the transaction request; based on the standard message format corresponding to the requester identifier, determines the request verification result for verifying the transaction request; if the request verification result is valid, the transaction data corresponding to the transaction request is processed based on preset verification rules such as transaction validity rules, transaction security rules, and user validity rules to determine the data verification result; based on the data verification result, the target processing method for processing the transaction request is determined, and the execution result corresponding to the transaction request is obtained based on the target processing method. This solves the problems of low transaction efficiency and poor accuracy caused by manual transaction review, and realizes the verification of transaction requests based on the standard message format corresponding to the requester identifier that initiated the transaction request, thereby strengthening the monitoring of access requests. When the request verification result is valid, the transaction data corresponding to the transaction request is processed based on preset verification rules such as transaction validity rules, transaction security rules, and user validity rules to verify the validity of the user, the validity of the transaction, and the security of the transaction, obtaining the data verification result. Then, based on the data verification result, the target processing method for processing the transaction request is determined, achieving the technical effect of improving the security, convenience, and accuracy of transaction request processing.

[0074] Optionally, based on the above-mentioned device, the requester identifier determination module 310 includes a standard message format determination unit and a request verification result determination unit.

[0075] A standard message format determination unit is used to determine the standard message format corresponding to the requester identifier based on a pre-determined mapping relationship; wherein the mapping relationship includes the requester identifier and the corresponding standard message format;

[0076] The request verification result determination unit is used to determine that the request verification result is invalid if the request message format corresponding to the transaction request is inconsistent with the standard message format.

[0077] The request verification result determination unit is further configured to determine that the request verification result is valid if the request message format corresponding to the transaction request is consistent with the standard message format.

[0078] Optionally, based on the above-mentioned device, the device may further include a data flow determination module, which includes a transaction data determination unit and a data flow determination unit.

[0079] A transaction data determination unit is used to parse the transaction request to obtain transaction data corresponding to the transaction request; wherein the transaction data includes at least one of the following: transaction identifier, transaction type, transaction value, transaction date, requester identifier, processor identifier, and processing requirement information;

[0080] A data stream determination unit is used to convert the transaction data into an identifiable data stream.

[0081] Based on the above-mentioned device, optionally, the preset verification rule is a transaction validity rule, and the data verification result determination module 330 includes a transaction record database lookup unit and a request record determination unit.

[0082] The transaction record database lookup unit is used to look up the transaction record database corresponding to the requester's identifier.

[0083] The request record determination unit is used to determine that the data verification result is successful if the transaction record database contains a request record corresponding to the transaction data.

[0084] The request record determination unit is further configured to determine that the data verification result is a verification failure if the request record is not contained in the transaction record database.

[0085] Based on the above-mentioned device, optionally, the preset verification rule is a user validity rule, and the data verification result determination module 330 includes an identifier quantity determination unit, an identifier judgment unit, and a data verification result determination unit.

[0086] The identifier quantity determination unit is used to determine the number of identifiers in the identifier generation library that match the transaction identifier;

[0087] The identifier determination unit is used to determine whether the permission record database contains the requester identifier and the processor identifier if the number of identifiers is a preset number.

[0088] A data verification result determination unit is used to determine that the data verification result is successful if the data is included.

[0089] The data verification result determination unit is further configured to determine that the data verification result is a verification failure if the data is not included.

[0090] Based on the above-mentioned device, optionally, the preset verification rule is a transaction security rule, and the data verification result determination module 330 includes a transaction attribute determination unit and a transaction attribute verification unit.

[0091] A transaction attribute determination unit is used to determine a transaction attribute corresponding to the transaction data, wherein the transaction attribute includes at least one of transaction frequency, cumulative transaction data, and continuous non-transaction duration;

[0092] A transaction attribute verification unit is used to determine that the data verification result is successfully verified if the transaction attribute satisfies the transaction security rules.

[0093] The transaction attribute verification unit is further configured to determine that the data verification result is a verification failure if at least one of the transaction attributes does not meet the transaction security rules.

[0094] Optionally, based on the above-described device, the device may further include an auditing module, which includes a data sending unit, an auditing result determination unit, and a verification result adjustment unit.

[0095] A data sending unit is used to send the transaction data to the manual review module when the data verification result is a verification failure.

[0096] The audit result determination unit is used to receive the audit result fed back by the manual audit module based on the transaction data;

[0097] The verification result adjustment unit is used to adjust the data verification result to "verification successful" if the audit result is "passed".

[0098] The data processing apparatus provided in the embodiments of the present invention can execute the data processing method provided in any embodiment of the present invention, and has the corresponding functional modules and beneficial effects of executing the method.

[0099] Example 4

[0100] Figure 5 This is a schematic diagram of the structure of an electronic device implementing the data processing method of an embodiment of the present invention. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices (e.g., helmets, glasses, watches, etc.), and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the invention described and / or claimed herein.

[0101] like Figure 5As shown, the electronic device 10 includes at least one processor 11 and a memory, such as a read-only memory (ROM) 12 or a random access memory (RAM) 13, communicatively connected to the at least one processor 11. The memory stores computer programs executable by the at least one processor. The processor 11 can perform various appropriate actions and processes based on the computer program stored in the ROM 12 or loaded from storage unit 18 into the RAM 13. The RAM 13 may also store various programs and data required for the operation of the electronic device 10. The processor 11, ROM 12, and RAM 13 are interconnected via a bus 14. An input / output (I / O) interface 15 is also connected to the bus 14.

[0102] Multiple components in electronic device 10 are connected to I / O interface 15, including: input unit 16, such as keyboard, mouse, etc.; output unit 17, such as various types of displays, speakers, etc.; storage unit 18, such as disk, optical disk, etc.; and communication unit 19, such as network card, modem, wireless transceiver, etc. Communication unit 19 allows electronic device 10 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0103] Processor 11 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 11 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. Processor 11 performs the various methods and processes described above, such as data processing methods.

[0104] In some embodiments, the data processing method may be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 18. In some embodiments, part or all of the computer program may be loaded and / or mounted on electronic device 10 via ROM 12 and / or communication unit 19. When the computer program is loaded into RAM 13 and executed by processor 11, one or more steps of the data processing method described above may be performed. Alternatively, in other embodiments, processor 11 may be configured to perform the data processing method by any other suitable means (e.g., by means of firmware).

[0105] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0106] Computer programs used to implement the methods of the present invention may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when executed by the processor, the computer programs cause the functions / operations specified in the flowcharts and / or block diagrams to be performed. The computer programs may be executed entirely on a machine, partially on a machine, or as a standalone software package, partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0107] In the context of this invention, a computer-readable storage medium can be a tangible medium that may contain or store a computer program for use by or in conjunction with an instruction execution system, apparatus, or device. A computer-readable storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination thereof. Alternatively, a computer-readable storage medium may be a machine-readable signal medium. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0108] To provide interaction with a user, the systems and techniques described herein can be implemented on an electronic device having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the electronic device. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0109] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or computing systems that include middleware components (e.g., application servers), or computing systems that include frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include local area networks (LANs), wide area networks (WANs), blockchain networks, and the Internet.

[0110] A computing system can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a hosting product within the cloud computing service system to address the shortcomings of traditional physical hosts and VPS services, such as high management difficulty and weak business scalability.

[0111] It should be understood that the various forms of processes shown above can be used, with steps reordered, added, or deleted. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this invention can be achieved, and this is not limited herein.

[0112] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. A data processing method, characterized in that, include: Upon receiving a transaction request, determine the requester identifier corresponding to the transaction request; Determining the request verification result for the transaction request based on the standard message format corresponding to the requester identifier includes: determining the standard message format corresponding to the requester identifier based on a pre-determined mapping relationship; wherein the mapping relationship includes the requester identifier and the corresponding standard message format; if the request message format corresponding to the transaction request is inconsistent with the standard message format, the request verification result is determined to be an invalid request; if the request message format corresponding to the transaction request is consistent with the standard message format, the request verification result is determined to be a valid request. If the request verification result is that the request is valid, then the transaction data corresponding to the transaction request is processed based on preset verification rules to determine the data verification result, including: checking the transaction record database corresponding to the requester identifier; if the transaction record database contains a request record corresponding to the transaction data, then the data verification result is determined to be successful; if the transaction record database does not contain the request record, then the data verification result is determined to be unsuccessful; wherein, the preset verification rules include transaction validity rules, transaction security rules, and user validity rules; Based on the data verification results, a target processing method is determined for processing the transaction request, so as to obtain an execution result corresponding to the transaction request based on the target processing method.

2. The method according to claim 1, characterized in that, Before processing the transaction data corresponding to the transaction request based on preset verification rules and determining the data verification result, the method further includes: The transaction request is parsed to obtain transaction data corresponding to the transaction request; wherein the transaction data includes at least one of the following: transaction identifier, transaction type, transaction value, transaction date, requester identifier, processor identifier, and processing requirement information; The transaction data is converted into a recognizable data stream.

3. The method according to claim 1, characterized in that, The preset verification rule is a user validity rule. The transaction data includes a transaction identifier and a processor identifier. The process of processing the transaction data corresponding to the transaction request based on the preset verification rule to determine the data verification result includes: Determine the number of identifiers in the identifier generation library that match the transaction identifier; If the number of identifiers is a preset number, then determine whether the permission record database contains the requester identifier and the processor identifier; If it is included, then the data verification result is determined to be successful; If not included, the data verification result is determined to be a verification failure.

4. The method according to claim 1, characterized in that, The preset verification rule is a transaction security rule. The process of processing the transaction data corresponding to the transaction request based on the preset verification rule to determine the data verification result includes: Determine the transaction attributes corresponding to the transaction data, wherein the transaction attributes include at least one of transaction frequency, cumulative transaction data, and duration of continuous no transaction; If the transaction attributes satisfy the transaction security rules, then the data verification result is determined to be successfully verified. If at least one of the transaction attributes fails to meet the transaction security rules, the data verification result is determined to be a verification failure.

5. The method according to claim 3 or 4, characterized in that, When the data verification result is a verification failure, the following applies: The transaction data is sent to the manual review module; Receive the review results from the manual review module based on the transaction data; If the audit result is "passed", then the data verification result will be adjusted to "verification successful".

6. A data processing apparatus, characterized in that, include: The requester identifier determination module is used to determine the requester identifier corresponding to the transaction request when a transaction request is received. The request verification result determination module is used to determine the request verification result for verifying the transaction request based on the standard message format corresponding to the requester identifier; The request verification result determination module is specifically used to determine the standard message format corresponding to the requester identifier based on a pre-determined mapping relationship; wherein, the mapping relationship includes the requester identifier and the corresponding standard message format; if the request message format corresponding to the transaction request is inconsistent with the standard message format, the request verification result is determined to be an invalid request; if the request message format corresponding to the transaction request is consistent with the standard message format, the request verification result is determined to be a valid request. The data verification result determination module is used to process the transaction data corresponding to the transaction request based on preset verification rules and determine the data verification result if the request verification result is that the request is valid; wherein, the preset verification rules include transaction validity rules, transaction security rules and user validity rules; The data verification result determination module is specifically used to check the transaction record database corresponding to the requester identifier; if the transaction record database contains a request record corresponding to the transaction data, the data verification result is determined to be successful; if the transaction record database does not contain the request record, the data verification result is determined to be unsuccessful. The target processing method determination module is used to determine the target processing method for processing the transaction request based on the data verification result, so as to obtain the execution result corresponding to the transaction request based on the target processing method.

7. An electronic device, characterized in that, The electronic device includes: At least one processor; and a memory communicatively connected to said at least one processor; wherein, The memory stores a computer program that can be executed by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform the data processing method according to any one of claims 1-5.

8. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that cause a processor to execute the data processing method according to any one of claims 1-5.

Images