Regulatory document generation method, apparatus, device, storage medium, and program product

Abstract

This application provides a regulatory document generation method, apparatus, device, storage medium, and program product, relating to the big data field and applicable to the fintech field. The method includes: determining target related accounts in a database to be reported based on a threshold for the number of related entries, where the threshold is determined based on historical reporting data; identifying the reporting status of the detail table for the target related account, and determining the redundancy judgment result for each detail in the detail table when the reporting status is "pending supplementation"; updating the reporting status of the detail table based on the redundancy judgment result for each detail in the detail table, and generating a summary detail; and generating a regulatory document for the target related account based on the updated detail table and the summary detail. When generating the regulatory document, related accounts are identified based on an adaptive threshold, thereby performing redundancy identification and merging processing on the data to be reported for related accounts, automatically avoiding situations with a large number of reports from related accounts, and improving the success rate of data reporting.

Description

Technical Field

[0001] This application relates to the field of big data and can be used in the field of financial technology, and in particular to a regulatory document generation method, apparatus, device, storage medium and program product. Background Technology

[0002] In the financial sector, financial institutions are required by regulatory agencies to regularly submit standardized reports or data files, known as regulatory documents, to monitor institutional compliance, risk control, and market transparency. Generating regulatory documents requires acquiring a large amount of financial data, which is then combined with regulatory rules and entity affiliations to create the documents. This financial data includes multi-dimensional data, ranging from atomic transactions to institutional-level aggregations, and may contain related accounts. The detailed account information for related accounts is often extensive, posing a risk of data non-reporting. Summary of the Invention

[0003] This application provides a regulatory document generation method, apparatus, device, storage medium, and program product to solve the technical problem of data reporting failure for associated accounts.

[0004] In a first aspect, embodiments of this application provide a method for generating regulatory documents, the method comprising:

[0005] Based on the threshold for the number of related records, the target related accounts in the database to be reported are determined. The threshold for the number of related records is determined based on historical reporting data.

[0006] Identify the reporting status of the detailed table of the target associated account, and determine the redundancy judgment result of each detail in the detailed table when the reporting status is pending supplementation.

[0007] Based on the redundancy judgment results of each detail in the detail table, update the reporting status of the detail table and generate a summary detail;

[0008] Based on the updated details and summary details, generate regulatory documents for the target associated accounts.

[0009] In one possible implementation, the target associated account to be reported to the database is determined based on a threshold for the number of associated records, including:

[0010] For each master record in the database to be reported, corresponding to the account to be determined, perform a related search on all transaction details of the account to be determined within a preset time period;

[0011] If the total number of all transaction details exceeds the threshold for the number of associated records, the account to be identified is designated as the target associated account.

[0012] In one possible implementation, determining the redundancy judgment result for each detail in the detail table includes:

[0013] Extract the transaction characteristics of each detail in the details table;

[0014] Input the transaction characteristics of each detail into the preset judgment model to obtain redundant judgment results for each detail.

[0015] In one possible implementation, based on the redundancy judgment result of each detail in the detail table, the reporting status of the detail table is updated, and a summary detail is generated, including:

[0016] For each detail in the detail table, if the redundancy judgment result of the corresponding detail is a redundant transaction, change the reporting status of the corresponding detail to non-reporting and update the latest updated data of the corresponding detail.

[0017] After the reporting status of all details in the detail table has been adjusted, a summary detail is generated based on the adjustment status of all details.

[0018] In one possible implementation, based on the updated details table and the summarized details, a regulatory document for the target associated account is generated, including:

[0019] Perform structural, business, and numerical validations on the updated detail tables and summary details.

[0020] If all verifications pass, regulatory documents for the target associated account are generated based on the updated details table and summary details.

[0021] In one possible implementation, the method further includes:

[0022] Based on the updated details table and the summary details, a redundancy distribution map of the target associated accounts is generated.

[0023] In one possible implementation, the associated record threshold is determined based on a correction coefficient determined from historical reporting data and an initial record threshold. The historical reporting data includes at least one of historical reporting success rate, historical penalty threshold, and system processing capacity.

[0024] Secondly, embodiments of this application provide a regulatory document generation apparatus, the apparatus comprising:

[0025] The first determination module is used to determine the target associated accounts in the database to be reported based on the threshold for the number of associated records. The threshold for the number of associated records is determined based on historical reporting data.

[0026] The second determination module is used to identify the reporting status of the detailed table of the target associated account. When the reporting status is pending supplementation, it determines the redundancy judgment result of each detail in the detailed table.

[0027] The first generation module is used to update the reporting status of the detail table based on the redundancy judgment results of each detail in the detail table, and generate a summary detail.

[0028] The second generation module is used to generate regulatory documents for the target associated accounts based on the updated details table and summary details.

[0029] Thirdly, embodiments of this application provide a computer device, including: a memory and a processor; the memory stores computer execution instructions; the processor executes the computer execution instructions stored in the memory, causing the processor to perform the first aspect and / or various possible implementations of the first aspect as described above.

[0030] 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.

[0031] 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.

[0032] The regulatory document generation method, apparatus, device, storage medium, and program product provided in this application relate to the big data field and can be used in the fintech field. The method includes: determining target related accounts in the database to be reported based on a threshold for the number of related entries, where the threshold is determined based on historical reporting data; identifying the reporting status of the detail table of the target related account, and determining the redundancy judgment result for each detail in the detail table when the reporting status is "pending supplementation"; updating the reporting status of the detail table based on the redundancy judgment result for each detail in the detail table, and generating a summary detail; and generating a regulatory document for the target related account based on the updated detail table and the summary detail. When generating the regulatory document, related accounts are identified based on an adaptive threshold, thereby performing redundancy identification and merging processing on the data to be reported for related accounts, automatically avoiding situations with a large number of reports from related accounts, and improving the success rate of data reporting. Attached Figure Description

[0033] 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.

[0034] Figure 1 A schematic diagram illustrating the application scenario of the regulatory document generation method provided in this application;

[0035] Figure 2 Flowchart of the regulatory document generation method provided for this application Figure 1 ;

[0036] Figure 3 Flowchart of the regulatory document generation method provided for this application Figure 2 ;

[0037] Figure 4 Flowchart of the regulatory document generation method provided for this application Figure 3 ;

[0038] Figure 5 A schematic diagram of the regulatory document generation device provided for this application;

[0039] Figure 6 A schematic diagram of the structure of the computer device provided in this application.

[0040] 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

[0041] 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.

[0042] In the description of this application, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this application, "multiple" means two or more, unless otherwise explicitly specified.

[0043] 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 the relevant laws, regulations, and standards of the relevant countries and regions, have taken necessary confidentiality measures, do not violate public order and good morals, and provide corresponding operation access points for users to choose to authorize or refuse.

[0044] 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.

[0045] It should be noted that the regulatory document generation method, apparatus, equipment, storage medium, and program products provided in this application can be used in the field of big data, or in any field other than big data, such as the fintech field. The application fields of the regulatory document generation method, apparatus, equipment, storage medium, and program products in this application are not limited.

[0046] In the financial sector, financial institutions are required by regulatory agencies to regularly submit standardized reports or data files, known as regulatory documents, to monitor institutional compliance, risk control, and market transparency. Generating regulatory documents requires acquiring a large amount of financial data, which is then combined with regulatory rules and entity affiliations to create the documents. This financial data includes multi-dimensional data, ranging from atomic transactions to institutional-level aggregations, and may contain related accounts. The detailed account information for related accounts is often extensive, posing a risk of data non-reporting.

[0047] To address the aforementioned technical issues, this application provides a method for generating regulatory documents. This method can be applied to real-time generation and submission of regulatory documents, as well as to scenarios where regulatory documents are generated and then submitted according to instructions. This application does not specifically limit the application to these scenarios. For ease of understanding, this application uses a real-time generation and submission scenario as an example. The method provided in this application can identify related accounts based on an adaptive threshold when generating regulatory documents, thereby performing redundant identification and merging of the data to be submitted from related accounts. This automatically avoids situations where there are many messages from related accounts, improving the success rate of data submission.

[0048] The method provided in the embodiments of this application can be applied to, for example, Figure 1 In the application environment shown, business system 102 stores business data and communicates with reporting system 104. Reporting system 104 can obtain the required data from business system, process the original business data, and generate regulatory documents for reporting.

[0049] The data storage system can store the data that the reporting system 104 needs to process. The data storage system can be integrated into the reporting system 104, or it can be placed in the cloud or on other network servers.

[0050] In one embodiment, such as Figure 2 As shown, a method for generating regulatory documents has been provided, which can be applied to... Figure 1 Taking the reporting system 104 in the middle as an example, the following steps are included:

[0051] Step 201: Determine the target associated accounts in the database to be reported based on the threshold for the number of associated records. The threshold for the number of associated records is determined based on historical reporting data.

[0052] Step 202: Identify the reporting status of the detailed table of the target associated account. If the reporting status is pending supplementation, determine the redundancy judgment result of each detail in the detailed table.

[0053] Step 203: Based on the redundancy judgment results of each detail in the detail table, update the reporting status of the detail table and generate a summary detail.

[0054] Step 204: Based on the updated details table and summary details, generate regulatory documents for the target associated account.

[0055] The associated transaction threshold is a threshold set for the transaction details of an account to determine whether an account is associated with another account. The threshold is set based on the characteristics of the transaction details of associated accounts. This threshold can be fixed, such as 2000, or it can be dynamically adjusted according to the data processing capacity of the business system and historical reporting data. It should be noted that the associated transaction threshold applies to a specific time frame of transaction details, such as the number of transaction details within a single day.

[0056] In one embodiment, the associated record threshold is determined based on a correction coefficient determined from historical reporting data and an initial record threshold. The historical reporting data includes at least one of historical reporting success rate, historical penalty threshold, and system processing capacity.

[0057] In this embodiment, the threshold for the number of associated records is dynamically adjusted as the reporting task is carried out, so that the threshold for the number of associated records can be updated in combination with historical reporting information each time a report is submitted, so as to more accurately identify the target associated accounts.

[0058] The threshold for the number of associated records has a corresponding update cycle, which is updated once per cycle. During the update, the threshold for the number of associated records can be calculated based on the following formula. :

[0059] ;

[0060] in, This is the initial threshold; For historical newspaper delivery success rate, To preset the reporting success rate, The regulatory trigger threshold (times / month). This is the initial regulatory trigger threshold; For system processing power (Q TPS). This represents the initial system processing capacity. Characterizes the relationship between the threshold for the number of associated records and the system's processing capacity; , This is the adjustment coefficient.

[0061] In the above formula, , as well as You can get the new value with each update.

[0062] The pending reporting database is an intermediate database existing to generate regulatory documents. It performs functions such as data source integration, data preprocessing, data temporary storage, and data quality detection between business system 102 and reporting system 104. Specifically, it includes extracting, cleaning, and transforming the raw business data required by business system 102; processing, calculating, summarizing, and mapping the raw business data to conform to the requirements of the regulatory data model; storing the processed data ready for generating the final message; and performing preliminary data verification and integrity checks at this layer. The pending reporting database is located between business system 102 and reporting system 104, and can exist within either business system 102 or reporting system 104. It includes all the information that needs to be reported, including account information, transaction details, and reporting status.

[0063] After processing according to the embodiments of this application, a regulatory document (also called a regulatory message) corresponding to the database to be reported is generated. It should be noted that the database to be reported itself does not directly contain the physical table structure of the message master table and the message details table, but it logically maps the data content required to generate these tables. The data to be reported emphasizes the data source and structure, and when data is extracted from the database to be reported to prepare for generating the message, these data tables are logically regarded as message details tables because their structure and content are strictly aligned with regulatory requirements, with only the final step of format serialization remaining.

[0064] An account, managed within business system 102, represents a contractual relationship between a customer and a service provider. It records information such as the quantity of resources owned, borrowed, managed, and their status. During reporting, key information for an account at a specific reporting point (or a summary of information over a period of time) typically forms a record in the report's detailed table. For example, the information for each valid account at the end of the month will generate a record in the account details table for the quantity of resources owned.

[0065] Target related accounts refer to related accounts with excessive transaction details, as determined by the threshold for the number of related transactions. Based on the number of transaction details for each account in the report details table of the database to be reported, the number of related transactions is compared with the threshold for the number of related transactions. When the number of transaction details exceeds the threshold for the number of related transactions, it is considered that an account with a number of related transactions exceeding the threshold has been captured, which is the target related account.

[0066] In this embodiment, the target associated account is considered to have abnormal trading volume. Due to the large number of transaction details for the target associated account, submission failures may occur when generating regulatory documents for submission. Therefore, it is necessary to process the data to be submitted for the target associated account, such as removing redundant records and excluding redundant records from the submission process. That is, a preliminary screening is performed using a threshold for the number of associated records to identify accounts with abnormal trading volume, and then a deeper verification is conducted on these target associated accounts.

[0067] Specifically, transaction details are processed based on their reporting status and redundancy status in the detailed transaction table. The reporting status of the detailed table indicates whether the table needs to be reported, i.e., the reporting status of each transaction detail in the table. Each transaction detail in the table has a reporting entry flag, and the reporting status is determined based on this flag. If the reporting entry flag is negative, it means that the reporting status of that transaction detail is pending reporting, i.e., it has not yet been reported.

[0068] "Pending supplementation" refers to a status requiring further processing. Transaction details in this state need manual confirmation or in-depth verification. For example, the redundancy status of transaction details is assessed, and redundant transactions are marked as not to be reported. In one embodiment, by identifying each detail in the target associated account's detail table, all details with redundancy assessment results for the target associated account are determined, and the reporting status of these details is changed to "not to be reported."

[0069] The summary detail is used to record all details that are deemed redundant, essentially compressing all redundant transactions into a single summary record. It is generated after updating the reporting status of all details deemed redundant in the detail table. The summary detail is generated based on preset information rules, including information such as detail number, record date, quantity of resources involved, counterparty account, counterparty name, and transaction nature.

[0070] It should be noted that for each target associated account with redundant transactions, a summary detail will be added to the target associated account's details table. Regulatory documents will then be generated based on the updated details table.

[0071] The method provided in the above embodiments includes: determining the target associated account in the database to be reported based on a threshold for the number of associated records, wherein the threshold for the number of associated records is determined based on historical reporting data; identifying the reporting status of the detail table of the target associated account, and determining the redundancy judgment result of each detail in the detail table when the reporting status is "pending supplementation"; updating the reporting status of the detail table based on the redundancy judgment result of each detail in the detail table, and generating a summary detail; and generating a regulatory document for the target associated account based on the updated detail table and the summary detail. When generating the regulatory document, associated accounts are identified based on an adaptive threshold, thereby performing redundancy identification and merging processing on the data to be reported for associated accounts, automatically avoiding situations with a large number of messages from associated accounts, and improving the success rate of data reporting.

[0072] In one embodiment, such as Figure 3 As shown, based on the threshold for the number of associated records, the target associated accounts to be reported in the database are determined, including:

[0073] Step 301: For each master record in the database to be reported, corresponding to the account to be determined, perform a correlation search on all transaction details of the account to be determined within a preset time period;

[0074] Step 302: If the number of all transaction details is greater than the threshold for the number of associated records, determine the account to be determined as the target associated account.

[0075] A master record refers to each record in the message master table. The message master table stores the core information, control information, and summary information of a message. Typically, each record represents a summary of a "business entity" or "business event" within a specific reporting period (e.g., one day). For example, it might contain summary information for all transactions of account A on a given day, such as the total number of transactions and the total number of transaction resources. Additionally, it may include key elements of a specific large transaction, such as the accounts of both parties, the total number of transaction resources, resource type, and date. Each large transaction has a unique identifier. Key information includes core fields used for identification, routing, summarization, and monitoring, such as message number, reporting agency, receiving agency, business type, account, date, total number of transaction resources, total number of transactions, and status. Compared to the detail table, the message master table contains far fewer records; typically, an account will only have one master record per day.

[0076] The transaction details table stores the specific transaction details that constitute the summary information in the main table. Each record represents a specific, atomic transaction entry that makes up a record in the main table. The detailed information includes complete details of each transaction, such as transaction serial number, counterparty account / name, transaction time, quantity of transaction resources, transaction type, transaction channel, purpose, and remarks. The transaction details table contains a large number of records; a single record in the main table, such as for account A for one day, may correspond to dozens, hundreds, or even thousands of records in the details table.

[0077] A message master table records multiple records associated with the message detail table. The master table and the detail table are linked through one or more key fields. The most common combination of association keys is: (1) Account: identifies which account the transaction is from; (2) Business date / Transaction date: identifies the date the transaction occurred. It may also include: reporting organization number, message type, business batch number, master record unique identifier, etc.

[0078] Determining the target associated account first requires searching all transaction details of the account within a preset time period, such as the daily transaction details of account A. The specific process is as follows:

[0079] (1) Locate the master record: Find a specific record in the message master table. One of the key identifiers of this record is "Account = Account A", and it represents the transaction summary information of Account A on a specific date (e.g., 2023-10-27);

[0080] (2) Query details based on association key: View all specific transactions that make up this main record (the summary of account A on 2023-10-27);

[0081] (3) Perform related searches using the core related keys of this main record. The most important ones are “Account = Account A” and business date / transaction date = 2023-10-27 as query conditions;

[0082] (4) Search in the details table: Search the report details table for all records that meet the following conditions: the account field is equal to "Account A" and the business date / transaction date field is equal to "2023-10-27";

[0083] (5) Obtaining Results: The search results are detailed records of every specific transaction that occurred in account A on October 27, 2023. The total number of transactions and the total transaction amount of these records should be exactly equal to the values ​​of the "Total Number of Transactions" and "Total Amount" fields in the original master record.

[0084] Compare the number of all transaction details with the threshold for the number of associated records. If the number of all transaction details exceeds the threshold for the number of associated records, then identify the account to be identified as the target associated account.

[0085] In the method provided in the above embodiments, the transaction details of each account are initially judged by the threshold of the number of associated records, and the target associated accounts with abnormal number of transaction details are screened out so as to process the data to be reported, and to avoid the situation where the data of the associated account cannot be processed when the regulatory document is generated, resulting in the failure of reporting.

[0086] In one embodiment, determining the redundancy judgment result for each detail in the detail table includes:

[0087] Extract the transaction characteristics of each detail in the details table;

[0088] Input the transaction characteristics of each detail into the preset judgment model to obtain redundant judgment results for each detail.

[0089] The preset judgment model is used to verify whether a transaction is abnormal. By analyzing the transaction characteristics of each detail, it identifies real redundant transactions (such as high-frequency same-name transfers, fractional adjustments, and other non-substantive transactions) and avoids misjudging normal business data.

[0090] In one embodiment, an LSTM (Long Short-Term Memory) time series model can be constructed using LSTM networks, which are adept at analyzing time series patterns, to analyze transaction characteristics and eliminate transactions that appear "abnormal but are reasonable." The specific logic is as follows: input the transaction characteristics corresponding to each detail into the LSTM time series model, and check whether the transaction belongs to a situation of meaningless resource flow, such as: high-frequency transfers between accounts with the same name, such as internal transfers between accounts within an organization; fractional adjustments, such as transferring 100.01 out and then back to 100; if so, the redundancy judgment result is determined as a redundant transaction.

[0091] In the above embodiments, by carefully examining each transaction, fake actions such as "flooding" are eliminated to retain genuine business transactions.

[0092] In one embodiment, such as Figure 4 As shown, based on the redundancy judgment results of each detail in the detail table, the reporting status of the detail table is updated, and a summary detail is generated, including:

[0093] Step 401: For each detail in the detail table, if the redundancy judgment result of the detail is a redundant transaction, change the reporting status of the detail to not report and update the latest updated data of the detail.

[0094] Step 402: After the reporting status of all details in the detail table has been adjusted, a summary detail is generated based on the adjustment status of all details.

[0095] After finding all the transaction records of the target associated account that are determined to be redundant, change the reporting status of all redundant transactions to not report and update the latest data, such as the latest update date and the latest update time.

[0096] It should be noted that when redundancy is invalidated (not reported), for all details of transactions judged as redundant, the following principles or actions must be followed to ensure data consistency. Specifically, when changing the reporting status and updating the latest data, atomic operations should be used to ensure consistency: a two-phase commit protocol (2PC) should be adopted to ensure that the following actions either all succeed or all are rolled back:

[0097] Update the main table, update the detail table, and add new summary details.

[0098] If the system crashes during operation, it will restart and check the data consistency using a CRC32 checksum before resuming execution from the breakpoint.

[0099] Generate summary details: Compress redundancy into a single summary record.

[0100] Objective: To replace the large number of fragmented transactions that were deleted.

[0101] Operation: Add a special record to the details table of the target associated account.

[0102] Key attributes: Based on the nature of the transaction, such as D80002 transfer with the same name (regulatory standard code, representing "internal account resource collection"), the amount = the total net amount of all redundant transactions that have been eliminated (e.g., 10,000 internal resources transferred on the same day, account name: consistent with the target associated account).

[0103] Result: The original 1,000 invalid transaction records were replaced by 1 summary record.

[0104] In the method provided in the above embodiments, by eliminating redundancy and generating summary details, a more accurate and comprehensive regulatory document is generated, so that the regulatory system receives a clear overall ledger instead of a messy list.

[0105] In one embodiment, a regulatory document for the target associated account is generated based on the updated details table and the summary details, including:

[0106] Perform structural, business, and numerical validations on the updated detail tables and summary details.

[0107] If all verifications pass, generate regulatory documents for the target associated account based on the updated details table and summary details;

[0108] Among these, structural validation can be enhanced through XML Schema extended validation. <redundancyflag>Tag verification; business verification can check the compliance of transaction nature based on regulatory rule base; numerical verification: establish a balance verification model on the number of transactions, such as the number of details summarized in the summary details plus the number of details in the updated details table, which equals the number of all details corresponding to the target associated account.

[0109] In addition, in one embodiment, a redundancy distribution map of the target associated accounts is generated based on the updated details table and the summary details.

[0110] After verification, the key elements of the report details table can be correctly associated, the reporting status of both records is updated to "pending reporting", and a heat map is generated simultaneously to show the redundancy distribution of the target associated accounts.

[0111] The method provided in the above embodiments dynamically adjusts the threshold for the number of related entries during the generation of regulatory documents with specific inspection focuses. It identifies target related accounts with a large number of related details and processes them accordingly, automatically avoiding the risk of being unable to report due to a large number of related details. Compared with traditional paginated reporting schemes, this method replaces simple splitting with intelligent summarization, maintaining the integrity of transaction logic and avoiding the risk of transaction chain breaks caused by paginated reporting. Stress testing shows that this solution can improve single-account processing efficiency by 3.8 times (from the original processing time T=15s to 3.9s), maintaining a 98.7% reporting success rate even in scenarios with 10,000+ related details, with a false operation rate of less than 0.03%. Furthermore, it forms a "regulatory reporting knowledge graph," extracting message rule features through NLP (Natural Language Processing) technology, which can be applied to other types of regulatory documents.

[0112] It should be understood that although the steps in the flowcharts of the above embodiments 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 flowcharts of the above embodiments may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0113] Based on the same inventive concept, this application also provides a regulatory document generation device. The solution provided by this device is similar to the solution described in the above method. Therefore, the specific limitations of one or more regulatory document generation device embodiments provided below can be found in the limitations of the regulatory document generation method above, and will not be repeated here.

[0114] In one embodiment, such as Figure 5 The regulatory document generation device shown includes a first determining module 501, a second determining module 502, a first generating module 503, and a second generating module 504, wherein:

[0115] The first determining module 501 is used to determine the target associated account in the database to be reported based on the threshold of the number of associated records. The threshold of the number of associated records is determined based on historical reporting data.

[0116] The second determining module 502 is used to identify the reporting status of the detailed table of the target associated account, and when the reporting status is pending supplementation, to determine the redundancy judgment result of each detail in the detailed table.

[0117] The first generation module 503 is used to update the reporting status of the detail table based on the redundancy judgment result of each detail in the detail table, and generate a summary detail.

[0118] The second generation module 504 is used to generate regulatory documents for the target associated account based on the updated details table and summary details.

[0119] In one possible implementation, the first determining module 501 is specifically used for:

[0120] For each master record in the database to be reported, corresponding to the account to be determined, perform a related search on all transaction details of the account to be determined within a preset time period;

[0121] If the total number of all transaction details exceeds the threshold for the number of associated records, the account to be identified is designated as the target associated account.

[0122] In one possible implementation, the second determining module 502 is specifically used for:

[0123] Extract the transaction characteristics of each detail in the details table;

[0124] Input the transaction characteristics of each detail into the preset judgment model to obtain redundant judgment results for each detail.

[0125] In one possible implementation, the first generation module 503 is specifically used for:

[0126] For each detail in the detail table, if the redundancy judgment result of the corresponding detail is a redundant transaction, change the reporting status of the corresponding detail to non-reporting and update the latest updated data of the corresponding detail.

[0127] After the reporting status of all details in the detail table has been adjusted, a summary detail is generated based on the adjustment status of all details.

[0128] In one possible implementation, the second generation module 504 is specifically used for:

[0129] Perform structural, business, and numerical validations on the updated detail tables and summary details.

[0130] If all verifications pass, generate regulatory documents for the target associated account based on the updated details table and summary details;

[0131] In one possible implementation, the second generation module 504 is specifically used for:

[0132] Based on the updated details table and the summary details, a redundancy distribution map of the target associated accounts is generated.

[0133] In one possible implementation, the first determining module 501 is specifically used to determine the threshold for the number of associated entries based on a correction coefficient determined by historical reporting data and an initial threshold for the number of entries. The historical reporting data includes at least one of historical reporting success rate, historical penalty threshold, and system processing capacity.

[0134] Each module in the aforementioned regulatory document generation device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device, or stored in the memory of a computer device as software, so that the processor can call and execute the operations corresponding to each module.

[0135] Figure 6 A schematic diagram of the structure of the computer device provided in this application. Figure 6 As shown, the computer device 60 provided in this embodiment includes at least one processor 601 and a memory 602. Optionally, the device 60 further includes a communication component 603. The processor 601, memory 602, and communication component 603 are connected via a bus 604.

[0136] In a specific implementation, at least one processor 601 executes computer execution instructions stored in memory 602, causing at least one processor 601 to perform the above-described method.

[0137] The specific implementation process of processor 601 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0138] 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.

[0139] The memory may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device.

[0140] 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.

[0141] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0142] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the above-described method.

[0143] 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.

[0144] 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.

[0145] 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.

[0146] 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.

[0147] 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.

[0148] 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.

[0149] 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.

[0150] 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.< / redundancyflag>

Claims

1. A method for generating regulatory documents, characterized in that, The method includes: Based on the threshold for the number of associated records, the target associated accounts in the database to be reported are determined, and the threshold for the number of associated records is determined based on historical reporting data; Identify the reporting status of the detailed table of the target associated account, and if the reporting status is pending supplementation, determine the redundancy judgment result of each detail in the detailed table; Based on the redundancy judgment result of each detail in the detail table, update the reporting status of the detail table and generate a summary detail; Based on the updated details table and summary details, regulatory documents for the target associated account are generated.

2. The method according to claim 1, characterized in that, The step of determining the target associated account to be reported to the database based on the threshold of the number of associated records includes: For each master record in the database to be reported, the account to be determined is searched for all transaction details of the account to be determined within a preset time period. If the total number of all transaction details is greater than the threshold for the number of associated records, the account to be determined is identified as the target associated account.

3. The method according to claim 2, characterized in that, The determination of redundancy for each detail in the detail table includes: Extract the transaction characteristics of each detail in the detailed table; Input the transaction characteristics of each detail into the preset judgment model to obtain redundant judgment results for each detail.

4. The method according to claim 1, characterized in that, The step of updating the reporting status of the detail table based on the redundancy judgment result of each detail in the detail table and generating a summary detail includes: For each detail in the detailed table, if the redundancy judgment result of the target detail is a redundant transaction, the reporting status of the target detail is changed to not reporting, and the latest updated data of the target detail is updated. After the reporting status of all details in the detailed table has been adjusted, a summary detail is generated based on the adjustment status of all details.

5. The method according to claim 1, characterized in that, The process of generating regulatory documents for the target associated account based on the updated detailed table and summarized details includes: Perform structural, business, and numerical validations on the updated detail tables and summary details. If all verifications pass, a regulatory document for the target associated account is generated based on the updated details table and the summary details.

6. The method according to claim 5, characterized in that, The method further includes: Based on the updated details table and the summarized details, a redundancy distribution map of the target associated accounts is generated.

7. The method according to any one of claims 1-6, characterized in that, The threshold for the number of associated entries is determined based on a correction coefficient and an initial threshold for the number of entries, which are based on historical reporting data. The historical reporting data includes at least one of historical reporting success rate, historical penalty threshold, and system processing capacity.

8. A regulatory document generation device, characterized in that, The device includes: The first determining module is used to determine the target associated account in the database to be reported based on the number of associated records threshold, wherein the number of associated records threshold is determined based on historical reporting data; The second determining module is used to identify the reporting status of the detailed table of the target associated account, and when the reporting status is pending supplementation, to determine the redundancy judgment result of each detail in the detailed table. The first generation module is used to update the reporting status of the detail table based on the redundancy judgment result of each detail in the detail table, and generate a summary detail. The second generation module is used to generate regulatory documents for the target associated account based on the updated details table and the summary details.

9. A computer 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.

Images