Abnormal verification method and device for card-making file and electronic equipment
By parsing the card production files and matching verification rules, the system automatically detects anomalies in the card production data, solving the problems of low efficiency and poor accuracy in existing technologies, and achieving efficient and accurate card production data verification.
Patent Information
- Application Number
- CN202511673865.9
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-11-14
- Publication Date
- 2026-02-27
AI Technical Summary
In existing technologies, the verification of card production data relies on manual spot checks, which is inefficient and inaccurate, making it difficult to meet the needs of producing multiple card types in large quantities.
By parsing the card production file, obtaining the card identification code and matching the verification rules, performing field verification and logical verification, generating verification results, and automatically detecting anomalies in the card production data.
It improves card production efficiency and accuracy, ensures the integrity and compliance of card production data, reduces manual intervention, and achieves efficient anomaly verification.
Smart Images
Figure CN121579536A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of financial technology, and in particular to a method, apparatus and electronic device for anomaly verification of card manufacturing documents. Background Technology
[0002] As financial institutions continue to expand their card issuance scale, the daily processing volume of card production data can reach hundreds of thousands of records. Furthermore, the types of cards are becoming increasingly diverse, including credit cards, debit cards, prepaid cards, and co-branded cards. These various types of cards differ significantly in data structure, field requirements, and business rules. The accuracy of the card production data directly determines whether the card production process can be executed smoothly.
[0003] In existing technologies, manual spot checks are usually required, which involves a high degree of human involvement and results in low efficiency and poor accuracy, making it difficult to meet the demand for multiple card types and large-volume card production. Summary of the Invention
[0004] This application provides a method, apparatus, and electronic device for verifying anomalies in card production documents, which addresses the technical shortcomings of low efficiency and poor accuracy in the prior art when relying on manual spot checks.
[0005] Firstly, this application provides a method for verifying anomalies in card manufacturing documents, including:
[0006] In response to the card production file, the card production file is parsed to obtain multiple card production data and the card identification code corresponding to each card production data;
[0007] For any one of the multiple card production data, based on the card identification code corresponding to the card production data and a preset set of verification rules, the verification rule corresponding to the card production data is determined.
[0008] For multiple card production data entries, anomaly verification is performed using corresponding verification rules to obtain a verification result for each card production data entry. The verification result is used to indicate whether there is an anomaly in the corresponding card production data.
[0009] Optionally, determining the verification rules corresponding to the card production data based on the card identification code corresponding to the card production data and a preset set of verification rules includes:
[0010] Based on the card identification code, determine the card type of the card identification code;
[0011] Based on the card type, the verification rule corresponding to the card identification code is determined from the preset set of verification rules.
[0012] Optionally, the verification rules include: field verification parameters and logical verification parameters. The step of using the corresponding verification rules for anomaly verification processing to obtain the verification result for each card-making data entry includes:
[0013] For any one of the multiple card production data, perform field-by-field verification processing on the card production data according to the field verification parameters to obtain the field verification result;
[0014] Based on the logical verification parameters, the card manufacturing data is subjected to logical rationality verification processing to obtain the logical verification result;
[0015] The verification result is determined based on the field verification result and the logical verification result.
[0016] Optionally, the field validation parameters include: a list of required fields, a field length threshold, and an allowed value range. The step of performing field-by-field validation on the card production data based on the field validation parameters to obtain the field validation results includes:
[0017] Verify that all required fields have been filled with the card production data;
[0018] If all the required fields have been filled with the card production data, verify whether the required fields meet the field length threshold.
[0019] If the required field meets the field length threshold, verify whether the required field meets the allowed value range;
[0020] If the required field meets the allowed value range, the field validation result is determined to be successful.
[0021] Optionally, determining the verification result based on the field verification result and the logical verification result includes:
[0022] Determine whether both the field validation result and the logical validation result indicate successful validation;
[0023] If both the field validation result and the logical validation result indicate successful validation, the validation result is determined to be valid.
[0024] If either the field validation result or the logical validation result indicates a validation failure, the validation result is determined to be a validation failure.
[0025] Optionally, the method further includes:
[0026] If the verification result indicates that the verification is successful, the card production data is pushed to the card production module through a message queue so that the card production module can perform bank card production processing based on the card production data;
[0027] If the verification result indicates that the verification failed, an exception message is generated based on the card production data, and the exception message is sent to the administrator so that the administrator can correct the card production data that failed the verification based on the exception message.
[0028] Optionally, the method further includes:
[0029] Determine the percentage of card production data that fails verification, wherein the percentage is used to indicate the proportion of card production data that fails verification in the total card production data;
[0030] Determine whether the percentage exceeds a preset error rate threshold;
[0031] If the percentage exceeds a preset error rate threshold, the circuit breaker mechanism is triggered, a circuit breaker event log is generated, and the circuit breaker event log is sent to the administrator.
[0032] Secondly, this application provides an anomaly verification device for card manufacturing documents, comprising:
[0033] The processing module is used to parse the card production file in response to the card production file, and obtain multiple card production data and the card identification code corresponding to each card production data;
[0034] The determination module is used to determine the verification rule corresponding to any card production data among multiple card production data, based on the card identification code corresponding to the card production data and a preset set of verification rules.
[0035] The processing module is also used to perform anomaly verification processing on multiple card production data using corresponding verification rules, and obtain the verification result of each card production data. The verification result is used to indicate whether there is an anomaly in the corresponding card production data.
[0036] Optionally, the determining module is further configured to determine the card type of the card identification code based on the card identification code;
[0037] The determining module is further configured to determine the verification rule corresponding to the card identification code from the preset set of verification rules based on the card type.
[0038] Optionally, the processing module is further configured to perform field-by-field verification processing on any one of the multiple card production data according to the field verification parameters, and obtain the field verification result.
[0039] The processing module is further configured to perform logical rationality verification processing on the card manufacturing data according to the logical verification parameters, and obtain the logical verification result;
[0040] The determining module is further configured to determine the verification result based on the field verification result and the logical verification result.
[0041] Optionally, the processing module is also used to verify whether all the required fields have been filled by the card production data;
[0042] The processing module is also used to verify whether the required fields meet the field length threshold when all the required fields have been filled by the card production data;
[0043] The processing module is further configured to, when the required field meets the field length threshold, verify whether the required field meets the allowed value range;
[0044] The determining module is further configured to determine that the field verification result is successful if the required field conforms to the allowed value range.
[0045] Optionally, the anomaly verification device for the card production file further includes: a judgment module;
[0046] The judgment module is used to determine whether both the field verification result and the logical verification result indicate successful verification;
[0047] The determining module is further configured to determine that the verification result is successful when both the field verification result and the logical verification result indicate that the verification is successful.
[0048] The determining module is further configured to determine that the verification result is a verification failure if either the field verification result or the logical verification result indicates a verification failure.
[0049] Optionally, the anomaly verification device for the card production file further includes: a generation module and a sending module;
[0050] The processing module is further configured to push the card production data to the card production module through a message queue when the verification result indicates that the verification is successful, so that the card production module can perform bank card production processing based on the card production data;
[0051] The generation module is used to generate an exception message based on the card manufacturing data when the verification result indicates that the verification failed.
[0052] The sending module is used to send the abnormal message to the administrator, so that the administrator can correct the card production data that failed the verification based on the abnormal message.
[0053] Optionally, the determining module is further configured to determine the proportion of card production data that fails verification, the proportion being used to indicate the proportion of card production data that fails verification in the card production data;
[0054] The judgment module is also used to determine whether the percentage exceeds a preset error rate threshold;
[0055] The generation module is also used to trigger the circuit breaker mechanism and generate a circuit breaker event log when the percentage exceeds a preset error rate threshold.
[0056] The sending module is also used to send the circuit breaker event log to the administrator.
[0057] Thirdly, this application provides an electronic device, including: a processor, and a memory communicatively connected to the processor;
[0058] The memory stores computer-executed instructions;
[0059] The processor executes computer execution instructions stored in the memory to implement the card production file anomaly verification method as described in the first aspect and various possible implementations of the first aspect above.
[0060] Fourthly, this application provides a computer-readable storage medium storing computer-executable instructions thereon, which, when executed by a processor, are used to implement the card manufacturing file anomaly verification method as described in the first aspect and various possible implementations of the first aspect.
[0061] Fifthly, this application provides a program product including a computer program that, when executed by a processor, implements the transaction processing method described above.
[0062] This application provides a method, apparatus, and electronic device for anomaly verification of card manufacturing documents, relating to the field of financial technology. The method parses the card manufacturing document in response to the document, obtaining multiple pieces of card manufacturing data and a corresponding card identification code for each piece. For any one piece of card manufacturing data, based on the corresponding card identification code and a preset set of verification rules, a corresponding verification rule is determined. For all the card manufacturing data, anomaly verification is performed using the corresponding verification rule, yielding a verification result for each piece of card manufacturing data. The verification result indicates whether the corresponding card manufacturing data contains anomalies. This improves card manufacturing efficiency and accuracy. Attached Figure Description
[0063] 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.
[0064] Figure 1 A flowchart illustrating an anomaly verification method for card manufacturing documents provided in this application. Figure 1 ;
[0065] Figure 2 A flowchart illustrating an anomaly verification method for card manufacturing documents provided in this application. Figure 2 ;
[0066] Figure 3 A flowchart illustrating an anomaly verification method for card manufacturing documents provided in this application. Figure 3 ;
[0067] Figure 4 A schematic diagram of an anomaly verification device for card production documents provided in this application;
[0068] Figure 5 A schematic diagram of the structure of an anomaly verification device for card production documents provided in this application.
[0069] 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
[0070] 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.
[0071] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, storage, use, processing, transmission, provision, disclosure, and application of the relevant data all comply with relevant laws, regulations, and standards, necessary confidentiality measures have been taken, they do not violate public order and good morals, and corresponding operation portals are provided for users to choose to authorize or refuse.
[0072] Furthermore, the technical solution involved in this application, which involves big data analysis of user information (including but not limited to personal biometrics, identity data, consumption data, asset data, electronic terminal operation data, etc.) and the use of artificial intelligence technology for automated decision-making, and makes decisions that have a significant impact on personal rights based on the results of automated decision-making, provides users with corresponding operation entry points for users to choose to agree to or reject the results of automated decision-making; if the user chooses to reject, the process will proceed to the expert decision-making process.
[0073] With the continuous growth of card issuance by financial institutions, the daily volume of card production data to be processed has reached hundreds of thousands, and the types of cards are becoming increasingly diverse, covering credit cards, debit cards, prepaid cards, co-branded cards, and more. Different card types have significant differences in data structure, field configuration, and business rules, placing higher demands on the accuracy of data processing. Any deviation in card production data may affect the normal execution of the card production process, leading to card production failure or business interruption.
[0074] In existing technologies, card production data is usually inspected by manual sampling, which relies heavily on human intervention, resulting in low processing efficiency and insufficient verification accuracy. This makes it difficult to meet the high-efficiency and accurate verification requirements in scenarios involving multiple card types and large-volume card production.
[0075] To address the aforementioned issues, this application proposes a method, apparatus, and electronic device for anomaly verification of card manufacturing documents, relating to the field of financial technology. This method, in response to a card manufacturing document, parses the document to obtain multiple card manufacturing data entries and a corresponding card identification code for each entry. For any single entry, based on the card identification code and a preset set of verification rules, a corresponding verification rule is determined. Anomaly verification is then performed on all card manufacturing data entries using the corresponding verification rule, yielding a verification result for each entry. The verification result indicates whether an anomaly exists in the corresponding card manufacturing data. This improves card manufacturing efficiency and accuracy.
[0076] 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 now be described with reference to the accompanying drawings.
[0077] Figure 1 A flowchart illustrating an anomaly verification method for card manufacturing documents provided in this application embodiment. Figure 1 .like Figure 1 As shown, the method for verifying the anomalies of card production files provided in this embodiment includes:
[0078] S101. In response to the card production file, the card production file is parsed and processed to obtain multiple card production data and the card identification code corresponding to each card production data.
[0079] In response to the received card production file, a parsing process is initiated. The card production file is a data file generated during the batch card production task, and its format includes, for example, CSV, TXT, Excel, or JSON. It contains multiple card production data records, each corresponding to a card to be produced, including fields such as card number, cardholder name, expiration date, and currency.
[0080] The system automatically identifies the file type based on the file extension or header information and calls the corresponding parser for line-by-line or block-by-block parsing. During parsing, the card number field is extracted from each card issuance data record, and the first six digits of the card number are extracted as the card identification code, which identifies the issuing institution and card type. For records with card numbers shorter than six digits or containing non-numeric characters, the system marks them as "card identification code extraction abnormal" and records the original data line number for subsequent investigation.
[0081] After parsing, a mapping relationship is established between each card production data entry and its corresponding card identification code, and cached in an in-memory data structure for subsequent verification rule matching based on the card identification code. The parsing process supports large file block reading to avoid memory overflow due to excessively large files, ensuring that the system maintains good performance and stability when processing millions of card production data entries.
[0082] S102. For any card production data among multiple card production data, determine the corresponding verification rule based on the card identification code corresponding to the card production data and the preset verification rule set.
[0083] For each card issuance record, its card identification code (usually the first six digits of the card number) is used as an index to perform a matching search within a pre-defined set of verification rules to determine the applicable verification rule for that card issuance record. The set of verification rules is a pre-configured structured dataset stored in a database, configuration file, or memory cache, containing multiple mapping relationships between card identification codes and corresponding verification rules.
[0084] During the matching process, the card identification code of the current card production data is used as the key value. Based on the card identification code, the card type corresponding to the card production data is determined, i.e., what type of bank card to be produced. Specifically, based on the card identification code, it is determined whether the bank card to be produced is a debit card or a credit card. A search operation is performed in an efficient data structure such as a hash table or search tree based on the card identification code and card type to determine the associated verification rules.
[0085] By determining the verification rules corresponding to the card production data based on the card identification code and the preset set of verification rules, it is possible to adapt the verification rules according to the card type, avoid misjudgment or missed detection caused by using a uniform template, and significantly improve the accuracy and efficiency of card production data verification.
[0086] S103. For multiple card production data, perform anomaly verification processing using the corresponding verification rules to obtain the verification result for each card production data. The verification result is used to indicate whether there is anomaly in the corresponding card production data.
[0087] Specifically, for the multiple card production data obtained after parsing, corresponding verification rules are loaded for each data, and multi-dimensional anomaly verification processing is performed based on the verification rules to determine whether there are any data anomalies in the card production data.
[0088] One possible implementation involves performing basic format checks on key fields in the card issuance data, such as card number, expiration date, and currency, including:
[0089] Validation of required fields;
[0090] Check whether the field length meets the preset threshold, such as a credit card number should be 16 digits;
[0091] Check whether the field value conforms to the allowed value range.
[0092] One possible approach is to perform business logic validation on key fields in the card production data, that is, to further verify the business rationality between data on the basis of compliant field formats.
[0093] A verification result record is generated for each piece of card production data. The verification result indicates whether there are any anomalies in the corresponding card production data. Through rule-driven, hierarchical verification, and parallel processing, efficient and accurate anomaly detection for large-scale card production data is achieved.
[0094] This embodiment provides an anomaly verification method for card manufacturing files. Responding to a card manufacturing file, the method parses the file to obtain multiple card manufacturing data entries and a corresponding card identification code for each entry. For any single entry, based on the card identification code and a preset set of verification rules, a corresponding verification rule is determined. Anomaly verification is then performed on all card manufacturing data entries using the corresponding verification rule, resulting in a verification result for each entry. This result indicates whether an anomaly exists in the corresponding card manufacturing data. This improves card manufacturing efficiency and accuracy.
[0095] Figure 2 A flowchart illustrating an anomaly verification method for card manufacturing documents provided in this application embodiment. Figure 2 .like Figure 2 As shown, in Figure 1Based on the embodiments, the method for anomaly verification of card production documents is described in detail, including:
[0096] S201. In response to the card production file, the card production file is parsed and processed to obtain multiple card production data and the card identification code corresponding to each card production data.
[0097] Step S201 is similar to step S101 above, and will not be repeated here.
[0098] S202. Determine the card type based on the card identification code.
[0099] The card identification code is typically the first 6 digits of the card number. Based on this code, a lookup and match is performed in a pre-defined card identification code mapping table to determine the corresponding card type. Card types include, but are not limited to: credit cards, debit cards, prepaid cards, co-branded cards, and corporate cards. The mapping table is a pre-configured structured data set stored in a database or memory cache, supporting exact matching. Specifically, for example, card identification code "622576" corresponds to a credit card; card identification code "622999" corresponds to a debit card.
[0100] For card identification codes that cannot be matched with any card type, mark them as "unknown card type" and record the original data line number for subsequent manual verification or rule supplementation.
[0101] Each card production data entry is associated with its corresponding card identification code and card type, and cached in an in-memory data structure to provide basic support for subsequent differential verification rule matching.
[0102] Accurate card type determination is achieved based on card identification codes, laying the foundation for subsequent application of differentiated verification rules according to card type.
[0103] S203. Based on the card type, determine the verification rule corresponding to the card identification code from the preset verification rule set. The verification rule includes: field verification parameters and logical verification parameters.
[0104] After determining the card type corresponding to each piece of card issuance data, such as credit card, debit card, or prepaid card, the system searches and determines the applicable verification rules for that card type from a pre-defined set of verification rules. The set of verification rules is a pre-configured rule base stored in a database, configuration file, or memory cache. It contains mappings between multiple card types and their corresponding verification rules, and supports dynamic updates and version management to adapt to new card types being launched or changes in business rules.
[0105] The validation rules include two core types of parameters: field validation parameters and logical validation parameters. Field validation parameters define the format validity requirements for individual fields, including:
[0106] Required fields list: Indicates the fields that must exist for this card type;
[0107] Field length threshold: Specifies the allowed character length range for each field, for example, card number length is 16–19 characters;
[0108] Allowed value range: Defines the set of acceptable values or formats for a field. For example, the allowed values for the currency field are {CNY,USD,EUR}, and the validity period field must conform to the YYYYMM regular expression format.
[0109] Logical validation parameters: These describe the business logic constraints between multiple fields, including:
[0110] Time validity rules: For example, the credit card should be valid for 1–3 years from the current month;
[0111] Mutually exclusive field rules: For example, the expiration date field cannot be filled in on debit cards; otherwise, it will be considered an anomaly.
[0112] Organize the above rules in a structured format, such as JSON, XML, or database tables, to support fast loading by card type. One possible implementation is to automatically load configuration items for validation rules, such as required fields and the field length threshold of "card number length = 16", when the card type is "credit card".
[0113] It implements adaptive matching verification rules based on card type, avoiding the misjudgment or missed detection problems caused by traditional fixed template verification, and significantly improving the accuracy of card production data verification.
[0114] S204. Field validation parameters include: a list of required fields, a field length threshold, and an allowed value range. Validate whether all required fields have been filled with card production data.
[0115] The field validation parameters are used to perform basic format validity checks on each field in the card production data, ensuring the data structure is complete and the format is compliant. The required field list is a pre-configured set of field names that define the data fields that must exist under the current card type. For example, the required fields for credit cards include card number, expiration date, and security code; while debit cards do not include an expiration date field, and their required fields are card number and cardholder name.
[0116] Based on the list of required fields, each card production record is checked item by item to ensure that all required fields are present. Specifically, the field names and corresponding values of the card production data record are parsed to determine whether each required field exists in the data and is not empty, i.e., it has been filled by the card production data. If a required field is missing or its value is an empty string, space, or other invalid placeholder, the field is determined to be unfilled and marked as a "Required Field Missing" error.
[0117] By validating required fields, we can effectively identify issues such as missing key information caused by template errors, program defects, or human oversights, thus ensuring the integrity and availability of card production data.
[0118] S205. If all required fields have been filled with card production data, verify whether the required fields meet the field length threshold.
[0119] After confirming that all required fields exist in the card production data records and that the field values are not empty (i.e., passing the mandatory field validation), a further field length compliance validation is performed. The field length threshold is a preset field length constraint condition, which is part of the field validation parameters, and different length requirements are set for different card types and fields.
[0120] One possible implementation is that the field length threshold could be: 16 digits for credit card numbers, 16-19 digits for debit card numbers, 3-4 digits for the security code field, and no more than 50 characters for the cardholder's name, etc.
[0121] Retrieve the actual value of each required field and calculate its character length or byte length. Then, compare the actual length with a preset length threshold to determine if any of the following conditions are met:
[0122] Credit card numbers are 16 digits long.
[0123] The security code is 3-4 characters long;
[0124] The cardholder's name shall not exceed 50 characters;
[0125] If all required fields meet any of the above conditions, the field length threshold for verification is determined, i.e., the field length verification is successful.
[0126] If the actual length of a required field exceeds a preset threshold, the field length is determined to be non-compliant, a "Field Length Error" log is generated, and the error field name, actual length and expected length are recorded for subsequent anomaly location and report generation.
[0127] S206. If the required field meets the field length threshold, verify whether the required field meets the allowed value range.
[0128] S207. If the required field meets the allowed value range, determine the field validation result as successful.
[0129] In this process, after confirming that all required fields have passed the length compliance check (i.e., the actual length meets the preset field length threshold), a further allowed value range check is performed to determine whether the actual value of each required field falls within its legal value range.
[0130] The allowed value range is based on preset field validity constraints, with different value selection rules set for different fields. Allowed value ranges include, but are not limited to, the following forms:
[0131] Enumerated value set: Specifies that a field can only take a certain number of predefined values. For example, the allowed value range for the currency field is: {CNY,USD,EUR}. One possible implementation is that if the actual currency field value is JPY, it is considered non-compliant.
[0132] Regular expression patterns: used to validate field formats. For example, the cardholder's name must not contain special characters (such as @, #, <);
[0133] Boolean constraints: For example, the "Active or Not" field only allows Y / N or true / false.
[0134] Extract the actual value of each required field and match it against its corresponding allowed value range. For enumeration type fields, perform a set inclusion check; for regular expression fields, call the regular expression engine for pattern matching; for numeric fields, perform range judgment. If the actual value of any field exceeds the allowed value range, generate an error flag of "value range non-compliant" and record the field name, actual value, and expected value range.
[0135] Once all required fields pass the allowed value range validation, the field validation result for this card data is considered successful. This result indicates that the data meets the preset requirements in three dimensions: required fields, field length threshold, and allowed value range, and is eligible for logical validation.
[0136] Through a three-stage progressive field validation mechanism that checks for required fields, length, and value range, comprehensive and accurate detection of card production data format is achieved, effectively preventing card production anomalies caused by illegal values, format errors, or data contamination.
[0137] S208. Based on the logic verification parameters, perform logic rationality verification on the card production data to obtain the logic verification result.
[0138] In addition to validating field formats, the process further performs logical rationality checks on the card-making data based on logical validation parameters to identify business logic conflicts or semantic inconsistencies between fields. This logical validation goes beyond single-field format checks, focusing on the relationships and business rule constraints between multiple fields to ensure that the data semantically conforms to the actual business scenarios of financial card production.
[0139] One possible implementation method is time validity and order verification: verifying whether time-related fields conform to a reasonable time range or sequential logic. For example:
[0140] The credit card must be valid for 1–3 years from the current month, and not earlier than the current date.
[0141] The account opening date must not be later than the card application date.
[0142] The logical verification parameters are loaded one by one, and the above rules are applied to each card data entry. A short-circuit mechanism is supported during the verification process: if a rule is not met, subsequent logical verification of the current data is immediately terminated, the error type is recorded, and a "logical verification failed" flag is generated to improve processing efficiency.
[0143] All logical verification results are aggregated to generate a logical verification result, which indicates whether there are any anomalies in the card issuance data at the business logic level. This result, together with the field verification results, constitutes the basis for comprehensive verification decisions.
[0144] S209. Determine whether both the field validation result and the logical validation result indicate successful validation. If yes, proceed to step S210; otherwise, proceed to step S211.
[0145] S210. If the verification result is confirmed to be successful, push the card production data to the card production module through the message queue so that the card production module can perform bank card production processing based on the card production data.
[0146] After completing the field validation and logical rationality validation of each card production data, a comprehensive judgment process is executed, which involves jointly judging the field validation results and logical validation results to determine whether both indicate "validation successful".
[0147] If both the field validation and logical validation results are successful, then the overall validation result for this card production data is considered passed. At this point, the card production data has been verified as high-quality card production information with complete format, legal content, and reasonable semantics, and is ready to enter the physical or virtual card production process.
[0148] The card production data is encapsulated into a standardized message body and asynchronously pushed to the downstream card production module via a message queue. Upon receiving the message, the card production module parses the data content and invokes card production equipment, such as a physical card issuer or a virtual card generation engine, to perform the actual bank card production process.
[0149] By comprehensively judging the results of field validation and logical validation, dual quality control of card production data is achieved, ensuring that only fully compliant data enters the card production process. This enables seamless integration from data validation to card production execution, improving the processing speed and business continuity of the card production workflow.
[0150] S211. If the verification result is determined to be a verification failure, an exception message is generated based on the card production data, and the exception message is sent to the administrator so that the administrator can correct the card production data that failed the verification based on the exception message.
[0151] After completing the field validation and logical validation for each card production data entry, the system makes a comprehensive judgment on the validation results. If the field validation result is a validation failure, or the logical validation result is a validation failure, or both fail, then the card production data entry is determined to have failed all validation requirements, and its overall validation result is determined to be a validation failure.
[0152] Based on the card manufacturing data and its detailed verification failure records, a structured exception message is generated. This exception message is sent to a pre-defined administrator terminal or maintenance alarm platform via a reliable communication channel. Upon receiving the exception message, the administrator can quickly locate the problematic data based on the error information and correct it in the source file or data entry system.
[0153] This embodiment provides an anomaly verification method for card production files. The method parses the card production file to obtain card production data and its card identification code, determines the card type based on the card identification code, and matches the corresponding verification rules. Then, field verification and logical verification are performed sequentially. If both verifications pass, the data enters the card production process; otherwise, an anomaly message is generated and the administrator is notified to correct it, thereby achieving accurate and automated detection of card production data and improving card production efficiency and accuracy.
[0154] Figure 3 A flowchart illustrating an anomaly verification method for card manufacturing documents provided in this application embodiment. Figure 3 .like Figure 3 As shown, in Figure 1 Based on the embodiments, the method for anomaly verification of card production documents is described in detail, including:
[0155] S301. Determine the percentage of card production data that failed verification. The percentage indicates the proportion of card production data that failed verification in the total card production data.
[0156] After verifying all card production data in the batch card production files, the overall distribution of the verification results is further analyzed to assess the data quality level of this card production task. Specifically, the total number of card production data processed and the number of data records judged as "verification failed" are obtained, and the percentage is calculated according to the following formula:
[0157]
[0158] The percentage is used to quantify the proportion of abnormal data in the current card production files and is an important basis for measuring the overall data quality. For example, when the error rate is below 1%, it indicates that the data quality is high; if the error rate exceeds 10%, it may indicate that there are template errors, abnormal field mappings, or defects in batch data generation in the upstream system. This percentage is used as a dynamic monitoring indicator for subsequent risk identification.
[0159] S302. Determine whether the percentage exceeds the preset error rate threshold. If so, proceed to step S303.
[0160] S303. Trigger the circuit breaker mechanism, generate a circuit breaker event log, and send the circuit breaker event log to the administrator.
[0161] The error rate threshold is a configurable parameter that can be flexibly set according to the business scenario, such as 5%, 10%, or 15%, to distinguish between occasional individual errors and systemic batch problems. After calculating the percentage of card production data that failed verification in this card production task, it is further compared with the preset error rate threshold to identify whether there is a risk of large-scale data anomalies.
[0162] If the percentage does not exceed the error rate threshold, it is considered a normal fluctuation, and subsequent processes can continue, such as pushing the verified data to the card production module for bank card production.
[0163] If this percentage exceeds the preset error rate threshold, the current card production file is considered to have a high probability of a source error. An automatic circuit breaker mechanism is triggered, immediately suspending the current batch of card production data processing to prevent more abnormal data from entering the downstream card production module, thus preventing resource waste, equipment blockage, or batch card invalidation due to continuous processing of invalid data.
[0164] At the same time, a structured circuit breaker event log is generated, which includes key information such as the following:
[0165] Event type: Marked as "Batch verification abnormal circuit breaker";
[0166] Trigger time: timestamp accurate to the second;
[0167] Card production task identifier: includes batch number, file name, submitter, etc.;
[0168] Actual error rate: The percentage of validation failures currently recorded;
[0169] Threshold setting: Preset error rate threshold;
[0170] The first N failure examples: show several typical error data and their error details to assist in root cause analysis.
[0171] Circuit breaker event logs are sent in real-time to pre-defined administrator terminals or operations and maintenance monitoring centers via high-priority channels, ensuring that relevant personnel can be notified of anomalies and intervene immediately. This proactive defense capability against batch data anomalies effectively prevents large-scale card production failures caused by upstream system malfunctions or configuration errors. The generated circuit breaker event logs contain complete contextual information and typical error examples, significantly improving problem localization speed and operational response efficiency.
[0172] This embodiment provides an anomaly verification method for card production files. This method involves real-time statistical analysis of the percentage of data failing verification during batch card production data verification. When this percentage exceeds a preset error rate threshold, it is determined to be a batch anomaly risk, triggering the system's circuit breaker mechanism. Simultaneously, a circuit breaker event log is generated and sent to the administrator to achieve timely alerts and intervention for abnormal situations. This ensures timely alerts and rapid response to abnormal events, guaranteeing business continuity in high-concurrency, large-volume card production scenarios.
[0173] Figure 4 This is a schematic diagram of a device for verifying the anomalies of card production documents provided in this application. Figure 4 As shown, this application provides an anomaly verification device for card production documents. The anomaly verification device 400 for card production documents includes:
[0174] Processing module 401 is used to parse and process the card production file in response to the card production file, and obtain multiple card production data and the card identification code corresponding to each card production data;
[0175] The determination module 402 is used to determine the verification rule corresponding to any card production data among multiple card production data based on the card identification code corresponding to the card production data and a preset set of verification rules.
[0176] The processing module 401 is also used to perform anomaly verification processing on multiple card production data using corresponding verification rules, and obtain the verification result of each card production data. The verification result is used to indicate whether there is anomaly in the corresponding card production data.
[0177] Optionally, the determining module 402 is also used to determine the card type of the card identification code based on the card identification code;
[0178] The determination module 402 is also used to determine the verification rule corresponding to the card identification code from a preset set of verification rules based on the card type.
[0179] Optionally, the processing module 401 is also used to perform field-by-field verification processing on any one of the multiple card production data according to the field verification parameters, and obtain the field verification result.
[0180] The processing module 401 is also used to perform logical rationality verification processing on the card production data according to the logical verification parameters, and obtain the logical verification result;
[0181] The determination module 402 is also used to determine the verification result based on the field verification result and the logical verification result.
[0182] Optionally, the processing module 401 is also used to verify whether all required fields have been filled by card production data;
[0183] The processing module 401 is also used to verify whether the required fields meet the field length threshold when all required fields have been filled by card production data.
[0184] The processing module 401 is also used to verify whether the required field conforms to the allowed value range when the required field meets the field length threshold.
[0185] The determination module 402 is also used to determine that the field validation result is successful if the required field meets the allowed value range.
[0186] Optionally, the anomaly verification device for card production documents also includes: a judgment module 403;
[0187] The judgment module 403 is used to determine whether both the field validation result and the logical validation result indicate that the validation was successful.
[0188] The determination module 402 is also used to determine that the verification result is successful when both the field verification result and the logical verification result indicate that the verification is successful.
[0189] The determination module 402 is also used to determine the verification result as verification failure if either the field verification result or the logical verification result indicates verification failure.
[0190] Optionally, the card production file anomaly verification device also includes: generation module 404 and sending module 405;
[0191] The processing module 401 is also used to push the card production data to the card production module through a message queue when the verification result indicates that the verification is successful, so that the card production module can perform bank card production processing based on the card production data.
[0192] The generation module 404 is used to generate an exception message based on the card manufacturing data when the verification result indicates that the verification has failed.
[0193] The sending module 405 is used to send an error message to the administrator so that the administrator can correct the card production data that failed the verification based on the error message.
[0194] Optionally, the determining module 402 is also used to determine the proportion of card production data that fails verification, and the proportion is used to indicate the proportion of card production data that fails verification in the card production data;
[0195] The judgment module 403 is also used to determine whether the percentage exceeds the preset error rate threshold;
[0196] The generation module 404 is also used to trigger the circuit breaker mechanism and generate a circuit breaker event log when the percentage exceeds a preset error rate threshold.
[0197] The sending module 405 is also used to send the circuit breaker event log to the administrator.
[0198] The card manufacturing file anomaly verification device provided in this application embodiment is similar in principle and technical effect to the implementation of each part of the aforementioned transaction processing method, and will not be described again here.
[0199] Figure 5 This is a schematic diagram of a device for verifying the anomalies of card production documents provided in this application. Figure 5 As shown, this application provides an anomaly verification device for card production documents. The anomaly verification device 500 for card production documents includes: a receiver 501, a transmitter 502, a processor 503, and a memory 504.
[0200] Receiver 501 is used to receive instructions and data;
[0201] Transmitter 502 is used to send commands and data;
[0202] Memory 504 is used to store instructions executed by the computer;
[0203] The processor 503 is used to execute computer execution instructions stored in the memory 504 to implement the various steps of the transaction processing method in the above embodiments. For details, please refer to the relevant descriptions in the foregoing transaction processing method embodiments.
[0204] Optionally, the memory 504 can be either standalone or integrated with the processor 503.
[0205] When the memory 504 is set up independently, the electronic device also includes a bus for connecting the memory 504 and the processor 503.
[0206] The implementation principle and technical effects of the electronic device provided in this embodiment can be found in the foregoing embodiments, and will not be repeated here.
[0207] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the method of any of the foregoing embodiments.
[0208] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the method of any of the foregoing embodiments.
[0209] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are all optional embodiments, and the actions and modules involved are not necessarily essential to this application.
[0210] It should be further noted that although the steps in the flowchart are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowchart may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the sub-steps or stages of other steps.
[0211] It should be understood that the above-described device embodiments are merely illustrative, and the device of this application can also be implemented in other ways. For example, the division of units / modules in the above embodiments is only a logical functional division, and there may be other division methods in actual implementation. For example, multiple units, modules, or components may be combined, or integrated into another system, or some features may be ignored or not executed.
[0212] Furthermore, unless otherwise specified, the functional units / modules in the various embodiments of this application can be integrated into one unit / module, or each unit / module can exist physically separately, or two or more units / modules can be integrated together. The integrated units / modules described above can be implemented in hardware or as software program modules.
[0213] In the above embodiments, the descriptions of each embodiment have their own emphasis. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments. The technical features of the above embodiments can be combined arbitrarily. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as the combination of these technical features does not contradict each other, it should be considered within the scope of this specification.
[0214] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this application are indicated by the following claims.
[0215] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.
Claims
1. A method for verifying anomalies in card production documents, characterized in that, The method includes: In response to the card production file, the card production file is parsed to obtain multiple card production data and the card identification code corresponding to each card production data; For any one of the multiple card production data, based on the card identification code corresponding to the card production data and a preset set of verification rules, the verification rule corresponding to the card production data is determined. For multiple card production data entries, anomaly verification is performed using corresponding verification rules to obtain a verification result for each card production data entry. The verification result is used to indicate whether there is an anomaly in the corresponding card production data.
2. The method according to claim 1, characterized in that, The step of determining the verification rules corresponding to the card production data based on the card identification code corresponding to the card production data and a preset set of verification rules includes: Based on the card identification code, determine the card type of the card identification code; Based on the card type, the verification rule corresponding to the card identification code is determined from the preset set of verification rules.
3. The method according to claim 1, characterized in that, The verification rules include: field verification parameters and logical verification parameters. The corresponding verification rules are used for anomaly verification processing to obtain the verification result for each card production data entry, including: For any one of the multiple card production data, perform field-by-field verification processing on the card production data according to the field verification parameters to obtain the field verification result; Based on the logical verification parameters, the card manufacturing data is subjected to logical rationality verification processing to obtain the logical verification result; The verification result is determined based on the field verification result and the logical verification result.
4. The method according to claim 3, characterized in that, The field validation parameters include: a list of required fields, a field length threshold, and an allowed value range. The process of performing field-by-field validation on the card production data based on these parameters to obtain the field validation results includes: Verify that all required fields have been filled with the card production data; If all the required fields have been filled with the card production data, verify whether the required fields meet the field length threshold. If the required field meets the field length threshold, verify whether the required field meets the allowed value range; If the required field meets the allowed value range, the field validation result is determined to be successful.
5. The method according to claim 3, characterized in that, The step of determining the verification result based on the field verification result and the logical verification result includes: Determine whether both the field validation result and the logical validation result indicate successful validation; If both the field validation result and the logical validation result indicate successful validation, the validation result is determined to be valid. If either the field validation result or the logical validation result indicates a validation failure, the validation result is determined to be a validation failure.
6. The method according to claim 1, characterized in that, The method further includes: If the verification result indicates that the verification is successful, the card production data is pushed to the card production module through a message queue so that the card production module can perform bank card production processing based on the card production data; If the verification result indicates that the verification failed, an error message is generated based on the card production data, and the error message is sent to the administrator so that the administrator can correct the card production data that failed the verification based on the error message.
7. The method according to claim 6, characterized in that, The method further includes: Determine the percentage of card production data that fails verification, wherein the percentage is used to indicate the proportion of card production data that fails verification in the total card production data; Determine whether the percentage exceeds a preset error rate threshold; If the percentage exceeds a preset error rate threshold, the circuit breaker mechanism is triggered, a circuit breaker event log is generated, and the circuit breaker event log is sent to the administrator.
8. An anomaly verification device for card production documents, characterized in that, The device includes: The processing module is used to parse the card production file in response to the card production file, and obtain multiple card production data and the card identification code corresponding to each card production data; The determination module is used to determine the verification rule corresponding to any card production data among multiple card production data, based on the card identification code corresponding to the card production data and a preset set of verification rules. The processing module is also used to perform anomaly verification processing on multiple card production data using corresponding verification rules, and obtain the verification result of each card production data. The verification result is used to indicate whether there is an anomaly in the corresponding card production data.
9. An electronic device, characterized in that, include: A processor, and a memory communicatively connected to the processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory to implement the method as described in any one of claims 1 to 7.
10. 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 to 7.
11. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the method of any one of claims 1 to 7.