Data processing method and device, storage medium and program product
By constructing a transaction database for multi-dimensional verification and anomaly detection, the problem of low efficiency in verifying massive amounts of data in the financial field has been solved, achieving automated verification and anomaly detection, improving accuracy and reducing costs.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-12-19
- Publication Date
- 2026-04-07
AI Technical Summary
In the financial sector, when faced with the need to verify massive amounts of data, existing technologies rely on manual verification, resulting in low efficiency and high costs.
By building a transaction database, multi-dimensional verification is performed based on multiple mixing transaction records, and a visual view is output to achieve automated verification and anomaly detection.
It improves the processing speed and accuracy of verification and anomaly detection, and reduces data verification costs.
Smart Images
Figure CN121810346A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of computer technology, and in particular to a data processing method, apparatus, storage medium, and program product. Background Technology
[0002] In some scenarios in the financial sector, data verification is required to prevent fraud, such as data verification for merchant subsidy applications or loan applications.
[0003] Taking subsidy applications as an example, a third party can provide users with subsidy coupons, which users can use to transact with merchants at a price lower than the product price (e.g., for certain designated products). Merchants can send subsidy application requests to the third party, which needs to perform various verifications on the application before disbursing the corresponding subsidy funds to the merchant.
[0004] When faced with massive amounts of data that need to be verified, the workload for verification personnel is heavy, efficiency is low, and verification costs are also high. Summary of the Invention
[0005] This application provides data processing methods, devices, storage media, and program products to assist in data verification, improve data verification efficiency, and reduce data verification costs.
[0006] In a first aspect, embodiments of this application provide a data processing method, the method comprising: determining order information to be verified;
[0007] A pre-built transaction database is obtained, and the order information to be verified is verified based on the transaction database; wherein, the transaction database includes multiple matching transaction records, which are obtained by matching the marketing transaction records of the payment clearing network, user information, and transaction records of offline acquiring institutions; the matching transaction records represent the correlation between transaction data, product information, and user information;
[0008] Upon successful verification, anomaly detection is performed on the order information to be verified.
[0009] The output includes a visual view of the verification results and anomaly detection results.
[0010] Secondly, embodiments of this application provide a data processing apparatus, which includes: a determining unit, configured to determine order information to be verified;
[0011] The verification unit is used to acquire a pre-built subsidy transaction database and perform multi-indicator verification on the order information to be verified based on the subsidy transaction database. The subsidy transaction database includes multiple matching transaction records, which are obtained by matching marketing transactions from the payment clearing network, user subsidy coupon redemption information, and transaction transactions from offline acquiring institutions. These matching transaction records represent the correlation between transaction data, product information, and user information.
[0012] An anomaly detection unit is used to perform anomaly detection on the order information to be verified in response to successful verification.
[0013] The output unit is used to output a visual view that includes verification results and anomaly detection results.
[0014] Thirdly, embodiments of this application provide an electronic device, including:
[0015] The memory stores computer-executed instructions;
[0016] The processor executes computer execution instructions stored in the memory, causing the at least one processor to perform the data processing method described in the first aspect and various possible designs of the first aspect.
[0017] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the first aspect and / or various possible implementations of the first aspect.
[0018] Fifthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the first aspect and / or various possible implementations of the first aspect.
[0019] The data processing method, device, storage medium, and program product provided in this application embodiment determine the order information to be verified; obtain a pre-constructed transaction database, and verify the order information to be verified based on the transaction database; wherein, the transaction database includes multiple matching transaction records, which are obtained by matching the marketing transaction records of the payment clearing network, user information, and transaction records of offline acquiring institutions; the matching transaction records represent the correlation between transaction data, product information, and user information; in response to the verification passing, anomaly detection is performed on the order information to be verified; and a visual view including verification results and anomaly detection results is output. This achieves automated verification and anomaly detection of merchant declaration information based on a pre-constructed transaction database using multi-source data, and finally presents the anomaly detection results in a visual view. Compared with the method of relying on manual item-by-item verification, this solution improves the processing speed and accuracy of verification and anomaly detection results, and can also reduce data verification costs. Attached Figure Description
[0020] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.
[0021] Figure 1 Flowchart of the data processing method provided in this application Figure 1 ;
[0022] Figure 2 This is a schematic diagram illustrating the process of constructing a transaction database as provided in this disclosure;
[0023] Figure 3 A schematic diagram of a visual view;
[0024] Figure 4 This is a schematic diagram of the data processing device.
[0025] Figure 5 A schematic diagram of the structure of an electronic device provided in this application.
[0026] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation
[0027] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.
[0028] In the financial sector, massive amounts of data need to be verified. Most of the relevant technologies rely on manual verification, which results in low efficiency and accuracy.
[0029] The solution provided in this application performs multi-dimensional verification of order information based on a pre-built transaction database and presents the verification results in a visual view, thereby helping users improve the efficiency and accuracy of data verification.
[0030] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will be described below with reference to the accompanying drawings.
[0031] Figure 1 Flowchart of the data processing method provided in this application Figure 1 ,like Figure 1 As shown, the method includes:
[0032] S101: Confirm the order information to be verified.
[0033] In this embodiment, the data processing method can be executed by a verification and anomaly detection platform that verifies transaction records and order information provided by merchants. This platform can include servers. These servers can be a single server or a server cluster consisting of multiple servers.
[0034] In one example, the order information to be verified could be entered by the merchant. The merchant can enter this information as a user of the verification and anomaly detection platform. For instance, the merchant can log into the platform and access the information input interface provided for merchants, where they can input the order information to be verified.
[0035] In one example, the order information to be verified includes, but is not limited to, one or more of the following: product identification code, buyer information, price, product unique identifier, and invoice information. Invoice information includes: invoice code, invoice number, buyer's name, seller's taxpayer identification number, total price including tax, and invoice date. Additionally, the order information to be verified also includes: external order number on the sales slip, merchant identifier, and product unique identifier information, such as SN (serial number) and IMEI (International Mobile Equipment Identity).
[0036] By identifying the above-mentioned order information to be verified, including: product identification code, purchaser information, price, product unique identification code, and invoice information, the order information to be verified can be verified from multiple dimensions.
[0037] In some implementations, step S101 may include the following sub-steps:
[0038] First, the system receives the purchase order image, invoice image, and product unique identifier code entered by the user on the data upload page.
[0039] In one example, the verification and anomaly detection platform can provide a user-facing data upload page, which can be for merchants or consumers. On this page, merchants or consumers can upload images of receipts and invoices, and also enter the product's unique identifier. This unique identifier includes the product serial number (SN). In some applications, the unique identifier may also include the International Mobile Equipment Identity (IMEI).
[0040] Secondly, optical character recognition is performed on the purchase order image and the invoice image to obtain the text information of the purchase order image and the invoice image.
[0041] After receiving the above images, the verification and anomaly detection platform can use optical character recognition algorithms to identify these images and obtain the corresponding text information.
[0042] Finally, the order information to be verified is determined based on the text information and the product's unique identifier.
[0043] The data required to extract the order information to be verified can be extracted from the above text information, with key fields extracted in a structured manner:
[0044] From the optical character recognition results of the purchase receipt image, for example through a pre-trained model or template-based localization technology, the following key fields are extracted and assigned explicit semantic labels: external order number (e.g., “202405201234567890”); merchant number (e.g., “898888888880001”); terminal number (e.g., “01009901”); transaction date (e.g., “2024-05-20”); transaction time (e.g., “14:30:25”); transaction amount (e.g., “5288.00”).
[0045] From the optical character recognition results of the invoice image, several key fields can be extracted in the same way, such as invoice code (e.g., "044021900111"); invoice number (e.g., "12345678"); buyer name (e.g., "Zhang Moumou"); total amount including tax (e.g., "5288.00"); and invoice date (e.g., "2024-05-20").
[0046] The verification and anomaly detection platform can clean and standardize the data corresponding to multiple keywords obtained in the above steps, and integrate them with the received product unique identifier code to finally generate a complete and structured record of order information to be verified.
[0047] In these implementations, key text information is extracted from purchase receipts and invoice images using optical character recognition (OCR), avoiding the slowness and error-prone nature of manual order text entry and significantly improving the efficiency and accuracy of data collection. Payment voucher information extracted from purchase receipts and tax voucher information extracted from invoice images are automatically associated and integrated with manually entered product unique identifiers to form a complete and structured order data object to be verified, ensuring consistency of information across different stages of the transaction chain. This structured order information, with its standardized fields and uniform format, can be directly called and compared by subsequent rule verification engines, enhancing the platform's processing capacity and reliability.
[0048] In some implementations, the order information to be verified is determined based on text information and the product's unique identifier, including:
[0049] The order information to be verified, determined based on the text information and the product's unique identifier, will be displayed on the data upload page;
[0050] In response to the user's confirmation of the displayed order information to be verified, the order information to be verified is taken as the final order information to be verified.
[0051] In these implementations, the text information extracted by optical character recognition (OCR) is integrated with the product identification code and displayed back on the submission page for the user to perform final comparison and confirmation. Potential OCR errors and manual entry errors can be intercepted and corrected at the source of data submission, ensuring a high degree of consistency between the order information to be verified and the original documents before entering the subsequent automated verification process.
[0052] In some embodiments, step S101 above further includes the following steps:
[0053] Receive order information to be verified from e-commerce platforms via a pre-defined application programming interface.
[0054] Users can obtain products through e-commerce platforms by placing orders and making payments. For example, they can acquire products participating in third-party subsidies through e-commerce platforms. After users place orders and make payments for these products on the e-commerce platform, the platform can generate structured order information to be verified using local order, payment, and invoice information. This information is then sent to the verification and anomaly detection platform via an application programming interface (API). The order information to be verified may include, for example, one or more of the following: invoice link, invoice code, invoice number, buyer's name, seller's taxpayer identification number, total price including tax, invoice date, etc.; order information (transaction amount, total discount amount, merchant ID, merchant order number, transaction time, etc.); product information (product barcode, category, energy grade, etc.); logistics information (logo tracking number, delivery address, etc.); and unique product identifier.
[0055] In these implementations, for online transactions generated through e-commerce platforms, structured order information to be verified can be extracted from the transaction information through the e-commerce platform and sent to the verification and anomaly detection platform through the interface provided by the verification and anomaly detection platform. This enables the direct use of the digital data of the e-commerce platform to generate high-quality order information to be verified. The order information to be verified is then connected to the verification and anomaly detection platform to provide a data foundation for subsequent verification of order information.
[0056] S102: Obtain a pre-built transaction database and verify the order information to be verified based on the transaction database; wherein, the transaction database includes multiple matching transaction records, which are obtained by matching the marketing transaction records of the payment clearing network, user information and the transaction records of offline acquiring institutions; the matching transaction records represent the relationship between transaction data, product information and user information.
[0057] The transaction database can be a pre-defined database corresponding to a specific activity, such as a subsidy activity transaction database. Alternatively, the transaction database can be pre-built; for example, it can be constructed based on historical transaction data obtained from a dynamic time window.
[0058] For example, a match can be made in the transaction database based on one or more key fields in the order information to be verified. If no match is found, the verification fails. If a match is found, further verification can be performed based on the matched transaction records.
[0059] In some implementations, the verification of order information to be verified is based on a transaction database, including verification of the order information to be verified according to one or more of the following rules:
[0060] The invoice issuance date must not be earlier than the date of the marketing transaction.
[0061] The total price including tax equals the transaction amount;
[0062] Invoice uniqueness verification;
[0063] Verify the uniqueness of the external order number on the purchase order form;
[0064] Did any returns occur?
[0065] Is the taxpayer identification number on the invoice included in the pre-set merchant whitelist?
[0066] In these implementations, the invoice date is compared to ensure that it is not earlier than the transaction timestamp in the payment record, thus eliminating the anomaly of invoicing before the transaction.
[0067] Verify the total amount including tax on the invoice to ensure it is exactly equal to the actual transaction amount in the payment record.
[0068] Based on the invoice code and number, it is determined whether the invoice is being used for subsidy application for the first time across the entire platform, in order to prevent duplicate applications for the same invoice.
[0069] Based on the external order number of the purchase order, it is determined whether the payment transaction is being claimed for the first time across the entire platform, in order to prevent the same transaction from being claimed repeatedly.
[0070] Check whether the order associated with this transaction has been returned in the sales system. If it has been returned, the application is deemed invalid.
[0071] Verify whether the seller's taxpayer identification number on the invoice is on the platform's pre-set whitelist of legitimate merchants.
[0072] In these implementations, the aforementioned verification rules collectively constitute an automated verification filter that can block applications that do not conform to business logic and compliance requirements, thereby improving the accuracy, reliability, and processing efficiency of order information verification.
[0073] S103: In response to successful verification, perform anomaly detection on the order information to be verified based on the transaction database.
[0074] Step S103 above includes one or more of the following: duplicate sales detection; identity consistency detection; product compliance detection; price anomaly detection; invoice authenticity and red-inking detection.
[0075] In some application scenarios, the order information to be verified includes product purchase user information and coupon code usage information. The executing entity can obtain the coupon code user information and match the product purchase user information with the coupon code user information to determine whether the purchase user information belongs to the coupon code user information. Further, it matches the coupon code information used by the user to purchase the product with the coupon code information of the coupon received by the coupon code user information. For example, if the match is successful, the identity verification consistency check is considered passed. The identity verification result information can be displayed in a visual view.
[0076] In some application scenarios, the order information to be verified may also include product identification codes, such as SKU codes. In these scenarios, third parties can specify one or more product identification codes to provide coupons to users. The verification and anomaly detection platform can maintain a product database, which includes information such as product identification codes, categories, brands, and names. Merchants in different locations can store the product identification codes, categories, brands, and names of these specified products into the product database before selling them.
[0077] The order information uploaded by merchants for verification may include product identification codes. The verification and anomaly detection platform can match these product identification codes with one or more of the aforementioned product identification codes from pre-stored third-party coupons. If no match is found, the product compliance detection result indicates that the product is non-compliant. If a match is successful, the product compliance detection result indicates that the product is compliant.
[0078] If any item is abnormal during the testing process, an indication message for that abnormality can be provided.
[0079] S103: Output a visual view that includes verification results and anomaly detection results.
[0080] In some implementations, the visualization view may also include: product identification code, product unique identification code, purchaser information, and transaction records matched from the transaction database.
[0081] In these implementations, by outputting a visual view of the integrated anomaly detection criteria and results, the logic of automated detection, data matching relationships, and anomalies are clearly and centrally presented to the auditors, making the audit decision-making process more transparent and providing complete and intuitive data link support for subsequent auditing and traceability.
[0082] In this embodiment, the following steps are taken: First, the order information to be verified is determined. Then, a pre-built transaction database is obtained, and the order information is verified based on this database. The transaction database includes multiple matching transaction records, obtained by matching marketing transaction data from the payment clearing network, user information, and transaction data from offline acquiring institutions. These matching transaction records represent the relationships between transaction data, product information, and user information. Upon successful verification, anomaly detection is performed on the order information. Finally, a visual view including the verification results and anomaly detection results is output. This achieves automated verification and anomaly detection of merchant-declared information based on a pre-built transaction database using multi-source data. The anomaly detection results are presented in a visual view. Compared to manual item-by-item verification, this solution improves the processing speed and accuracy of verification and anomaly detection, while also reducing data verification costs.
[0083] Please refer to Figure 2 , Figure 2 This is a flowchart illustrating the process of constructing a transaction database for this application. Figure 2 As shown, it includes the following steps:
[0084] S201: From the marketing transaction data provided by the payment clearing network, select historical transaction data for a preset time period carrying a preset identifier as the initial dataset.
[0085] S202: The initial dataset will be linked and matched with the user information of the user who received the coupon based on the coupon code.
[0086] S203: Perform a second association between the data that has undergone the first association and the transaction records of the acquiring institution according to preset fields to complete the external order number and product details of the purchase order and obtain the transaction database.
[0087] In this embodiment, the verification and anomaly detection platform can obtain historical transaction records for a preset time period from the payment clearing network through authorization. This preset time period can be, for example, a specific calendar day, such as the day before the date the transaction database is built or updated. It is understood that the transaction database can be updated periodically. The update cycle can be, for example, one day.
[0088] Understandably, pre-set activities could be subsidy programs offered to consumers by third parties, such as trade-in programs. Consumers (users) participating in these activities can obtain coupon codes from the activity publishing platform. For example, they can enter their user information (identity identifier and user identifier, etc.) on the activity publishing platform to receive subsidy coupon codes. In this way, user information and the coupon codes received by users can be stored in the user coupon database.
[0089] The payment clearing network here can be a bank card switching clearing network, which typically handles transaction messages made through various bank cards.
[0090] The verification and anomaly detection platform can obtain the full marketing transaction history for a preset time period from the payment clearing network. The platform then analyzes this data, filtering out multiple transaction records carrying preset identifiers to form an initial dataset. These preset identifiers could, for example, be unique identifiers for this trade-in program.
[0091] The verification and anomaly detection platform uses the coupon codes in the initial dataset as the association key to query the user coupon redemption database. This database is generated when users redeem coupons online and stores the binding relationship between coupon codes and real-name user information (such as names). Through association, each valid transaction is matched with the corresponding actual user information who redeemed the coupon, forming a user-payment associated data set.
[0092] For offline transaction scenarios, a second association matching process can be performed to complete product information and obtain a unique order identifier on the acquiring side. Specifically, the user-payment associated dataset can be used as input, with a composite association key consisting of five fields: transaction type, transaction date, merchant ID, terminal ID, and acquiring institution transaction reference number. The verification and anomaly detection platform uses this composite key to perform precise queries and matching in POS transaction files obtained from various acquiring institutions, which contain more detailed transaction details (such as the external order number on the sales slip and product barcodes). When all five key fields are completely identical, it is determined to be the same transaction, thus associating the external order number on the sales slip and product details to the user-payment associated dataset.
[0093] The transaction records of the two successful related transactions are stored in the transaction database as a complete transaction record.
[0094] The transaction database built through the above process can provide a data foundation for verifying subsequent orders awaiting verification.
[0095] In some embodiments, duplicate sales detection is performed based on the transaction database and the order information to be verified, including the following steps:
[0096] First, extract the first product serial number and the first order identifier from the order information to be verified, and determine the sales status corresponding to the first product serial number from the product serial number database. The product serial number database stores the product serial numbers and corresponding sales statuses of multiple products. When a transaction occurs for each product, the status of the corresponding product serial number in the database is updated to the sold status, and the corresponding order identifier is recorded in the product serial number database.
[0097] Second, in response to the sales status corresponding to the first product serial number being "sold", determine whether the first order identifier is the same as the order identifier recorded in the product serial number database.
[0098] Third, in response to the determination result being the same, it is determined that the product corresponding to the first product serial number has not been sold repeatedly; otherwise, it is determined that the product corresponding to the first product serial number has been sold repeatedly.
[0099] In these implementations, every product has a product serial number. The verification and anomaly detection platform can obtain information on products currently on sale or already sold through authorization to build a product serial number database. The product serial number database includes, but is not limited to, one or more of the following fields: region code, manufacturer information, brand, category code, product barcode, SN code, IMEI code 1 (computer or communication products), IMEI code 2 (computer or communication products), and sales status, etc.
[0100] When any product transaction occurs, the serial number occupancy interface is called to update the status of the product serial number in the product serial number database to "sold" and associate it with the corresponding transaction order identifier (such as transaction order number or external order number of purchase order).
[0101] When receiving a pending order from a merchant, the system can extract the first product serial number and the first order identifier from the order. Then, it matches the first product serial number against a product serial number database. If no match is found in the database, subsequent requests from the merchant are rejected. If the matched first product serial number is in an unsold state, subsequent requests from the merchant can be rejected, and an error message will be displayed.
[0102] Once the first product serial number is matched in the product sequence database, the sales status corresponding to the first product serial number in the product sequence database is then read.
[0103] If the sales status is "sold" and the order identifier corresponding to the first product serial number in the product serial number database is the first order identifier, it is determined that the product has not been sold twice. If the order identifier corresponding to the first product serial number in the product serial number database is not the first order identifier, it is determined that the product has been sold twice.
[0104] Understandably, the product sequence database is dynamically updated, adding new products and related information in real time based on newly added products for sale. For product sequence numbers in the database, the sales status of the product sequence number will be updated in real time when a transaction occurs.
[0105] In these implementations, by establishing a dynamic product serial number database and strongly associating the sales status of product serial numbers with transaction order numbers, a dual detection mechanism (status + order number matching) is used to ensure that each product serial number corresponds to only one valid sale, thereby effectively detecting the phenomenon of obtaining subsidies by tampering with product serial numbers or repeatedly submitting old orders.
[0106] In some implementations, price anomaly detection is performed on the order information to be verified based on the transaction database, including the following steps:
[0107] First, for each product identification code, determine the historical transaction data of the product identification code in multiple regions and multiple preset time periods;
[0108] Second, based on multiple historical transaction data, calculate the benchmark price of each product's identification code in multiple regions;
[0109] Third, compare the transaction amount in the order information to be verified with the corresponding benchmark price and calculate the fluctuation ratio;
[0110] Fourth, determine whether the price is abnormal based on the fluctuation ratio.
[0111] The aforementioned verification and anomaly detection platform can extract a dataset containing product identifiers (such as unique SKU codes), transaction regions, and transaction amounts from historical transaction records. The data can be grouped using the product identifier and transaction region as a joint primary key, resulting in multiple groupings of {product identifier, transaction region}.
[0112] For each grouping result, the benchmark price of that product's individual identifier code in that region can be calculated. This effectively eliminates interference from occasional abnormally high or low transaction prices. The calculation results, i.e., {product identifier code, transaction region, benchmark price, statistical period, sample size}, are stored in the product benchmark price database.
[0113] When a new order information to be verified is identified, the price anomaly verification process can be triggered. Specifically, key verification fields can be extracted from the order information to be verified: product identification code, the region where the merchant is located, and the order transaction amount.
[0114] Using the product identifier and transaction region as the query keys, the benchmark price database is retrieved. In one example, a monthly backtracking strategy can be used, prioritizing the matching of the benchmark price for the current statistical period (M-1 month); if not found, the query backtracks to the previous period (M-2 month) until found. If no benchmark price is found after the maximum backtracking period (e.g., 6 months), it is determined that there is no benchmark price and the check is skipped.
[0115] If a benchmark price is successfully matched, the floating percentage is calculated using the formula: Float Percentage = (Order Transaction Amount / Benchmark Price) × 100%. The calculated result can be compared with preset abnormal thresholds (e.g., upward floating percentage > 115% or downward floating percentage < 80%).
[0116] If the fluctuation ratio is within the normal threshold, the price detection passes; if it exceeds the upward fluctuation threshold (e.g., >115%), the price detection result is an abnormal price, and the ratio exceeding the regional benchmark price can also be given, along with an abnormal price warning.
[0117] If the transaction amount is significantly lower than the benchmark price (e.g., <80%), it may indicate a risk of fraudulent transactions or arbitrage, and be marked as "Price Abnormality: Below the Regional Benchmark Price [Percentage]" and trigger a medium-level warning.
[0118] If a benchmark price with "low data confidence" is matched, a prompt will be generated: "The reference price is based on a small number of samples, please conduct a thorough manual review."
[0119] The results of price monitoring, the calculation basis (including the benchmark price used, statistical period, and sample size), and early warning information can be integrated into a separate section of the visualization view of the order information to be verified. This allows users (auditors) to clearly see the comparison between the current price and historical market levels, and to make comprehensive decisions based on other verification results (such as invoices and serial numbers).
[0120] In these implementations, an objective benchmark price is established by aggregating historical transaction data into a dynamic benchmark price based on commodity and region. By automatically comparing and analyzing the transaction amounts of new orders against this benchmark price, abnormal price transactions deviating from the normal price range can be identified efficiently and accurately. This provides a key technical means for detecting price anomalies and effectively prevents risks such as fictitious transactions and improper price increases that could lead to fund misappropriation.
[0121] In some implementations, the authenticity and red-ink verification of invoices are performed on the order information to be verified based on the transaction database, including the following steps:
[0122] First, upon receiving order information to be verified, a preset interface is called to verify the authenticity of the invoice.
[0123] Second, if the invoice verification result is true, in response to the fulfillment of preset conditions, the preset interface is called again to verify whether the invoice has been cancelled in red.
[0124] Third, display the results of verifying the authenticity of invoices and the results of red-ink cancellation in a visual view.
[0125] Upon receiving the aforementioned order information to be verified, the verification and anomaly detection platform can verify the authenticity of the invoice corresponding to the order information through a preset interface provided by the relevant institution (invoice issuing institution). The verification result of the invoice authenticity can be displayed in a visual view.
[0126] The preset conditions include one or more of the following: the time remaining since the invoice verification meets a preset duration requirement; and a preset deadline has been reached. In one example, the preset deadline could be the date the subsidy activity ends.
[0127] Under the preset conditions, the preset interface is called again to verify whether the invoice has been cancelled in red.
[0128] The aforementioned verification platform can display the results of invoice authenticity verification and red-ink cancellation verification in a visual view to assist auditors in quickly reviewing orders to be verified.
[0129] Please refer to Figure 3 , Figure 3 This is a schematic diagram of a visual view. For example... Figure 3 As shown, the visual view 30 displays the order information to be verified, which includes: external order number B1, transaction time E1, product identification code F1, merchant identification S1, transaction terminal number S2, whether it belongs to a local merchant S3 and company name S4, discount amount H2, encrypted purchaser information (purchaser name, purchaser identity information, contact information), price (original amount), product unique identification code G2 and invoice information (including invoice amount C1, invoice code B2, invoice type C2, invoice number C3, tax amount C4 and taxpayer identification number K1), and may also include discount amount, etc.
[0130] In addition, the view can also include anomaly detection results, such as identity consistency verification results, like... Figure 3 The detection result for the consumer name and coupon code matching is "Matching". The price warning detection result is: "The transaction amount of this order is 0.7 times the average price of the region last month"; the result for whether the product is being sold repeatedly is: "No". The user consistency verification result is: "Yes". As can be seen in this view, through... Figure 1The data processing method shown allows auditors to view multi-dimensional anomaly detection results and the basis for those results, thereby improving the efficiency of order information verification and anomaly detection.
[0131] Corresponding to the data processing method in the above embodiments, Figure 4 This is a structural block diagram of a data processing apparatus provided according to embodiments of the present disclosure. For ease of explanation, only the parts relevant to embodiments of the present disclosure are shown. (Refer to...) Figure 4 The device includes: a determining unit 401, a verifying unit 402, and an output unit 403. Among them,
[0132] Unit 401 is used to determine the order information to be verified.
[0133] Verification unit 402 is used to obtain a pre-built subsidy transaction database and perform multi-indicator verification on the order information to be verified based on the subsidy transaction database. The subsidy transaction database includes multiple matching transaction records, which are obtained by matching the marketing transaction records of the payment clearing network, user subsidy coupon redemption information, and transaction records of offline acquiring institutions. The matching transaction records represent the relationship between transaction data, product information, and user information.
[0134] Anomaly detection unit 403 is used to perform anomaly detection based on the order information to be verified in the transaction database in response to successful verification.
[0135] Output unit 404 is used to output a visual view including verification results and anomaly detection results.
[0136] In some embodiments, the determining unit 401 is further configured to:
[0137] Receive the purchase order image, invoice image, and product unique identifier code entered by the user on the data upload page;
[0138] Optical character recognition is performed on the purchase order image and the invoice image to obtain the text information of the purchase order image and the invoice image;
[0139] Based on the text information and the product's unique identifier, determine the order information to be verified.
[0140] In some embodiments, the determining unit 401, based on the text information and the product unique identifier, is further configured to:
[0141] The order information to be verified, determined based on the text information and the product's unique identifier, will be displayed on the data upload page;
[0142] In response to the user's confirmation of the displayed order information to be verified, the order information to be verified is taken as the final order information to be verified.
[0143] In some embodiments, the determining unit 401 is further configured to:
[0144] Receive order information to be verified from e-commerce platforms via a pre-defined application programming interface.
[0145] In some embodiments, the order information to be verified includes one or more of the following:
[0146] Product identification code, purchaser information, price, unique product identifier, and invoice information.
[0147] In some embodiments, the device 40 further includes a building unit (not shown), the building unit being used for:
[0148] From the marketing transaction data provided by the payment clearing network, historical transaction data for a preset time period carrying preset identifiers are selected as the initial dataset;
[0149] The initial dataset will be linked and matched with the user information who redeemed the coupons based on the coupon codes; or...
[0150] The data that has undergone the first association and matching is then combined with the acquiring institution's transaction records according to preset fields for the second association and matching, in order to complete the external order number and product details of the purchase order and obtain the transaction database.
[0151] In some embodiments, the anomaly detection unit 402 is further configured to perform one or more of the following:
[0152] Repeat sales detection;
[0153] Identity consistency check;
[0154] Product compliance testing;
[0155] Price anomaly detection;
[0156] Invoice authenticity verification and red-ink verification.
[0157] In some embodiments, the order information to be verified includes a unique product identifier, and the anomaly detection unit 403 is further used for:
[0158] Extract the first product serial number and the first order identifier from the order information to be verified, and determine the sales status corresponding to the first product serial number from the product serial number database; wherein, the product serial number database stores the product serial numbers and corresponding sales statuses of multiple products respectively; when each product is traded, the status of the corresponding product serial number in the database is updated to the sold status, and the corresponding order identifier is recorded in the product serial number database;
[0159] In response to the sales status corresponding to the first product serial number being "sold", determine whether the first order identifier is the same as the order identifier recorded in the product serial number database;
[0160] In response to the determination that the results are the same, it is determined that the product corresponding to the first product serial number has not been sold repeatedly.
[0161] Otherwise, it is determined that the product corresponding to the first product serial number is being sold repeatedly.
[0162] In some embodiments, the anomaly detection unit 403 is further configured to:
[0163] For each product identification code, determine the product identification code in multiple regions and their respective historical transaction data;
[0164] Based on multiple historical transaction data, calculate the benchmark price of each product's identification code in multiple regions;
[0165] Compare the transaction amount in the order information to be verified with the corresponding benchmark price, and calculate the fluctuation ratio;
[0166] Determine whether the price is abnormal based on the fluctuation ratio.
[0167] In some embodiments, the anomaly detection unit 403 is further configured to:
[0168] When the floating ratio exceeds a preset threshold, a prominent warning label is displayed in the visualization view.
[0169] In some embodiments, the anomaly detection unit 403 is further configured to:
[0170] Upon receiving order information to be verified, the preset interface is called to verify the authenticity of the invoice;
[0171] If the invoice verification result is true, in response to the fulfillment of preset conditions, the preset interface is called again to verify whether the invoice has been cancelled in red.
[0172] The results of invoice authenticity verification and red-ink cancellation verification are displayed in the visualization view.
[0173] In some embodiments, the visualization view further includes: the product identification code, purchaser information, price invoice information, and the transaction record matched from the transaction database in the order information to be verified.
[0174] In some embodiments, the verification unit 402 performs one or more of the following verifications based on the transaction database of the order information to be verified:
[0175] The invoice issuance date must not be earlier than the date of the marketing transaction.
[0176] The total price including tax equals the transaction amount;
[0177] Invoice uniqueness verification;
[0178] Verify the uniqueness of the external order number on the purchase order form;
[0179] Did any returns occur?
[0180] Is the taxpayer identification number on the invoice included in the pre-set merchant whitelist?
[0181] The apparatus provided in this embodiment can be used to execute the technical solutions of the above method embodiments. Its implementation principle and technical effects are similar, and will not be described again here.
[0182] To implement the above embodiments, this disclosure also provides an electronic device.
[0183] Figure 5 A schematic diagram of the structure of the electronic device provided in this application. Figure 5 As shown, the electronic device 50 provided in this embodiment includes at least one processor 501 and a memory 502. Optionally, the device 50 further includes a communication component 503. The processor 501, memory 502, and communication component 503 are connected via a bus.
[0184] In a specific implementation, at least one processor 501 executes computer execution instructions stored in memory 502, causing at least one processor 501 to perform the above-described method.
[0185] The specific implementation process of processor 501 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.
[0186] The electronic device can be the terminal device or server in the above method embodiments.
[0187] In the above embodiments, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.
[0188] The memory may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device.
[0189] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.
[0190] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method for a terminal device; or, when executed by a processor, the computer program implements the above-described method.
[0191] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the above-described method for a terminal device; or implement the above-described method.
[0192] The aforementioned readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.
[0193] An exemplary readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside in an Application Specific Integrated Circuit (ASIC). Alternatively, the processor and the readable storage medium can exist as discrete components in the device.
[0194] The division of units is merely a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or units, and may be electrical, mechanical, or other forms.
[0195] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.
[0196] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.
[0197] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.
[0198] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.
[0199] Finally, it should be noted that other embodiments of the invention will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This invention is intended to cover any variations, uses, or adaptations of the invention that follow the general principles of the invention and include common knowledge or customary techniques in the art not disclosed herein, and is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of the invention is limited only by the appended claims.
Claims
1. A data processing method, characterized in that, Confirm the order information to be verified; A pre-built transaction database is obtained, and the order information to be verified is verified based on the transaction database; wherein, the transaction database includes multiple matching transaction records, which are obtained by matching the marketing transaction records of the payment clearing network, user information, and transaction records of offline acquiring institutions; the matching transaction records represent the correlation between transaction data, product information, and user information; In response to successful verification, anomaly detection is performed on the order information to be verified based on the transaction database. The output includes a visual view of the verification results and anomaly detection results.
2. The method according to claim 1, characterized in that, The process of determining the order information to be verified includes: Receive the purchase order image, invoice image, and product unique identifier code entered by the user on the data upload page; Optical character recognition is performed on the purchase order image and the invoice image to obtain the text information of the purchase order image and the invoice image; The order information to be verified is determined based on the text information and the product's unique identifier.
3. The method according to claim 2, characterized in that, The step of determining the order information to be verified based on the text information and the product's unique identifier includes: The order information to be verified, determined based on the text information and the product's unique identifier, will be displayed on the data upload page; In response to the user's confirmation of the displayed order information to be verified, the order information to be verified is taken as the final order information to be verified.
4. The method according to claim 1, characterized in that, The process of determining the order information to be verified includes: Receive the order information to be verified sent by the e-commerce platform through a preset application programming interface.
5. The method according to claim 1, characterized in that, The order information to be verified includes one or more of the following: Product identification code, purchaser information, price, unique product identifier, and invoice information.
6. The method according to claim 1, characterized in that, The method further includes: From the marketing transaction data provided by the payment clearing network, historical transaction data for a preset time period carrying preset identifiers are selected as the initial dataset; The initial dataset will be first linked and matched with the user information who received the coupons based on the coupon code. The data that has undergone the first association and matching is then combined with the transaction records of the acquiring institution according to preset fields for the second association and matching, in order to complete the external order number and product details of the purchase order, thus obtaining the transaction database.
7. The method according to claim 1, characterized in that, The response upon successful verification involves performing anomaly detection on the order information to be verified, including one or more of the following: Repeat sales detection; Identity consistency check; Product compliance testing; Price anomaly detection; Invoice authenticity verification and red-ink verification.
8. The method according to claim 7, characterized in that, The order information to be verified includes a unique product identifier. Based on the transaction database, duplicate sales detection is performed on the order information to be verified, including: The first product serial number and the first order identifier are extracted from the order information to be verified, and the sales status corresponding to the first product serial number is determined from the product serial number database. The product serial number database stores the product serial numbers and corresponding sales statuses of multiple products. When a transaction occurs for each product, the status of the corresponding product serial number in the database is updated to the sold status, and the corresponding order identifier is recorded in the product serial number database. In response to the sales status corresponding to the first product serial number being the sold status, determine whether the first order identifier is the same as the order identifier recorded in the product serial number database; In response to the determination that the results are the same, it is determined that the product corresponding to the first product serial number has not been sold repeatedly. Otherwise, it is determined that the product corresponding to the first product serial number is being sold repeatedly.
9. The method according to claim 7, characterized in that, Based on the transaction database, price anomaly detection is performed on the order information to be verified, including: For each product identification code, determine the historical transaction data of the product identification code in multiple regions; Based on the aforementioned historical transaction data, calculate the benchmark price of the product identification code in multiple regions. The transaction amount in the order information to be verified is compared with the corresponding benchmark price, and the fluctuation ratio is calculated. The price fluctuation ratio is used to determine whether the price is abnormal.
10. The method according to claim 9, characterized in that, The method further includes: When the floating ratio exceeds a preset threshold, a prominent warning sign is displayed in the visualization view.
11. The method according to claim 7, characterized in that, Based on the transaction database, the authenticity and red-ink cancellation checks are performed on the order information to be verified, including: Upon receiving the order information to be verified, a preset interface is invoked to verify the authenticity of the invoice; If the invoice verification result is true, in response to the fulfillment of the preset conditions, the preset interface is called again to verify whether the invoice has been cancelled in red ink; The results of invoice authenticity verification and red-ink cancellation verification are displayed in the visualization view.
12. The method according to claim 1, characterized in that, The visualization view also includes: the product identification code, purchaser information, price invoice information, and the transaction record matched from the transaction database in the order information to be verified.
13. The method according to any one of claims 1-12, characterized in that, The verification of the order information to be verified based on the transaction database includes one or more of the following: The invoice issuance date must not be earlier than the date of the marketing transaction. The total price including tax equals the transaction amount; Invoice uniqueness verification; Verify the uniqueness of the external order number on the purchase order form; Did any returns occur? Is the taxpayer identification number on the invoice included in the pre-set merchant whitelist? 14. A data processing apparatus, characterized in that, The determination unit is used to determine the order information to be verified. The verification unit is used to acquire a pre-built subsidy transaction database and perform multi-indicator verification on the order information to be verified based on the subsidy transaction database. The subsidy transaction database includes multiple matching transaction records, which are obtained by matching marketing transactions from the payment clearing network, user subsidy coupon redemption information, and transaction transactions from offline acquiring institutions. These matching transaction records represent the correlation between transaction data, product information, and user information. An anomaly detection unit is used to perform anomaly detection on the order information to be verified in response to successful verification. The output unit is used to output a visual view that includes verification results and anomaly detection results.
15. An electronic device, characterized in that, include: Processor and memory; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory, causing the processor to perform the method as described in any one of claims 1 to 13.
16. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1-13.
17. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the method described in any one of claims 1-13.