A financial product checking method and device based on a process robot

Abstract

The application discloses a financial product checking method and device based on a process robot, relates to the technical field of calculation, and can also be applied to the financial field. The method comprises the following steps: traversing a specified financial product storage address according to a preset configuration file; analyzing an evaluation table of a financial product in the financial product storage address to generate a first data set; analyzing the custody information of a user-specified financial product to generate a second data set; wherein the second data set is stored in the financial product storage address; and checking the key field value extracted from the second data set in the first data set. The method provided by the application realizes the function of automatically matching the management report and the custody evaluation table data, thereby achieving the data connection between the external management report and the internal custody system, improving the work efficiency, reducing the work error rate, timely feeding back the management report data problems, and reducing the risk.

Description

Technical Field

[0001] This application belongs to the field of computer technology, specifically relating to a financial product verification method and apparatus based on a process robot. Background Technology

[0002] Currently, a significant amount of verification work for financial products still relies on manual processing, especially in scenarios such as reviewing information disclosure reports and parsing valuation tables. Custodian banks need to compare reports sent by investment managers via email with data in the valuation system item by item. This model presents three major technical challenges: First, low processing efficiency; during peak reporting periods, operations staff need to work overtime to manually verify data, resulting in a heavy workload and a high risk of fatigue and errors. Second, insufficient coverage; manual verification of all fields and all products is difficult, often requiring sampling and leaving blind spots for risk. Third, the process is untraceable; manually adjusted accounts and manually marked verification results often lack complete online traceability, making it difficult to provide a complete chain of verification evidence in case of regulatory inquiries or investment disputes. While technologies such as Robotic Process Automation (RPA) have begun to be applied, processing unstructured data (such as various custom-formatted account statements and valuation tables) still faces challenges such as difficulty in adapting parsing templates and high maintenance costs. Summary of the Invention

[0003] One object of the present invention is to provide a financial product verification method based on process robots, so as to solve at least a part of the above-mentioned technical problems.

[0004] Another object of the present invention is to provide a financial product verification device based on a process robot. A further object of the present invention is to provide an electronic device including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the aforementioned financial product verification method based on a process robot. A further object of the present invention is to provide a readable medium storing a computer program thereon, wherein the computer program, when executed by a processor, implements the steps of the aforementioned financial product verification method based on a process robot.

[0005] To address the technical problems in the background section of this application, the present invention provides the following technical solutions: In a first aspect, the present invention provides a financial product verification method based on a process robot, comprising: Iterate through the specified financial product storage addresses according to the preset configuration file; Parse the valuation table of the financial products in the storage address of the financial products to generate the first dataset; Parse the custody information of the financial product specified by the user to generate a second dataset; wherein the second dataset is stored at the storage address of the financial product; Verify the key field values ​​extracted from the second dataset in the first dataset.

[0006] In some embodiments of the present invention, if the valuation table is in an unstructured format, parsing the valuation table of the financial product in the storage address of the financial product generates a first dataset, including: The valuation table is segmented to obtain sub-tables of the valuation table; The sub-table is parsed to generate a first dataset; wherein the first dataset includes: the table header of the sub-table and the attribute values ​​of the table header.

[0007] In some embodiments of the present invention, if the valuation table is in a structured format, parsing the valuation table of the financial product in the financial product storage address generates a first dataset, including: Map the valuation table to key-value pairs; The valuation table is parsed based on the key-value pairs to generate the first dataset.

[0008] In some embodiments of the present invention, the custody information of a user-specified financial product is parsed to generate a second dataset, including: The python-docx library is used to identify table objects in the managed information, and the contents of the table objects are parsed into a second data set according to the identification order.

[0009] In some embodiments of the present invention, the configuration file includes: the mapping relationship of the fields to be compared, the matching rule threshold, and the output directory path.

[0010] In some embodiments of the present invention, the key field values ​​include: the product identifier of the financial product, the index number of the custody information, the current line number, the field to be compared, and the matching status.

[0011] Secondly, the present invention provides a financial product verification device based on a process robot, comprising: The storage address traversal module is used to traverse the specified financial product storage addresses according to a preset configuration file. The first dataset generation module is used to parse the valuation table of the financial products in the storage address of the financial products and generate the first dataset. The second dataset generation module is used to parse the custody information of the financial product specified by the user and generate a second dataset; wherein, the second dataset is stored at the storage address of the financial product; The key field value extraction module is used to verify the key field values ​​extracted from the second dataset in the first dataset.

[0012] In some embodiments of the present invention, if the valuation table is in an unstructured format, the first dataset generation module includes: The valuation table segmentation unit is used to segment the valuation table and obtain sub-tables of the valuation table; The first dataset generates a first unit, which is used to parse the sub-table and generate the first dataset; wherein, the first dataset includes: the table header of the sub-table and the attribute values ​​of the table header.

[0013] In some embodiments of the present invention, if the valuation table is in a structured format, the first dataset generation module includes: The valuation table mapping unit is used to map the valuation table into key-value pairs; The second dataset generates the first unit, which is used to parse the valuation table based on the key-value pairs to generate the first dataset.

[0014] In some embodiments of the present invention, the second dataset generation module includes: The second dataset generation unit is used to identify table objects in the managed information using the python-docx library, and parse the contents of the table objects into a second dataset according to the identification order.

[0015] In some embodiments of the present invention, the configuration file includes: the mapping relationship of the fields to be compared, the matching rule threshold, and the output directory path.

[0016] In some embodiments of the present invention, the key field values ​​include: the product identifier of the financial product, the index number of the custody information, the current line number, the field to be compared, and the matching status.

[0017] Thirdly, the present invention provides a computer program product, including a computer program / instructions, which, when executed by a processor, implements the steps of a financial product verification method based on a process robot.

[0018] Fourthly, the present invention provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the steps of a financial product verification method based on a process robot.

[0019] Fifthly, the present invention provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of a process robot-based financial product verification method.

[0020] As described above, embodiments of the present invention provide a financial product verification method and apparatus based on a process robot. The corresponding method includes: first, traversing a specified financial product storage address according to a preset configuration file; then, parsing the valuation table of the financial product in the financial product storage address to generate a first dataset; parsing the custody information of the financial product specified by the user to generate a second dataset; wherein the second dataset is stored in the financial product storage address; and finally, verifying the key field values ​​extracted from the second dataset in the first dataset.

[0021] The present invention provides a financial product verification method based on process robots. By using process robot technology, it realizes the function of automatically matching management reports and custody valuation table data, thereby achieving data connection between external management reports and internal custody systems, improving work efficiency, reducing work error rate, timely feedback on management report data problems, and reducing risks. Attached Figure Description

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

[0023] Figure 1 A flowchart illustrating a financial product verification method based on a process robot, as described in an embodiment of the present invention. Figure 2 This is a flowchart illustrating step 200 of a financial product verification method based on a process robot, as described in an embodiment of the present invention. Figure 3 This is another flowchart illustrating step 200 of a financial product verification method based on a process robot in an embodiment of the present invention. Figure 4 This is a flowchart illustrating a financial product verification method based on a process robot, as described in a specific embodiment of the present invention. Figure 5 This is a block diagram of another financial product verification device based on a process robot according to an embodiment of the present invention. Figure 6 This is a block diagram of the first dataset generation module 20 based on the process robot in an embodiment of the present invention; Figure 7 This is another block diagram of the first dataset generation module 20 based on the process robot in an embodiment of the present invention; Figure 8 This is a schematic diagram of the structure of an electronic device in an embodiment of the present invention. Detailed Implementation

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

[0025] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0026] It should be noted that the terms "comprising" and "having," and any variations thereof, in the specification, claims, and accompanying drawings of this application are intended to cover a non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not necessarily limited to those explicitly listed, but may include other steps or units not explicitly listed or inherent to these processes, methods, products, or apparatuses. Without conflict, the embodiments and features in the embodiments of this application can be combined with each other. This application will now be described in detail with reference to the accompanying drawings and embodiments.

[0027] The information collected in the technical solution of this application is information and data authorized by the user or fully authorized by all parties. 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, necessary confidentiality measures have been taken, and they do not violate public order and good morals. Corresponding operation portals are provided for users to choose to authorize or refuse.

[0028] Provide users with corresponding operation entry points, allowing them to choose to agree to or reject the automated decision results; if the user chooses to reject, the process will proceed to the expert decision-making process.

[0029] The acquisition, storage, use, and processing of data in this application all comply with relevant laws and regulations. Specifically: First, the information collected is information and data authorized by the user or fully authorized by all parties. The collection, storage, use, processing, transmission, provision, disclosure and application of the relevant data shall comply with the relevant laws, regulations and standards of the relevant countries and regions, take necessary confidentiality measures, not violate public order and good morals, and provide corresponding operation access points for users to choose to authorize or refuse.

[0030] Second, provide users with corresponding operation entry points for them to choose to agree to or reject the automated decision results; if the user chooses to reject, the process will proceed to the expert decision-making process.

[0031] In banking operations, reconciling custody reports with data from the business system is a highly complex and risk-sensitive task. The accuracy of this process directly impacts asset security and regulatory compliance. However, existing technologies and methods have revealed a series of deep-seated technical problems in practice, primarily in the following aspects: Inconsistent data definitions arise from multi-source, heterogeneous systems: the core systems, investment and trading systems, valuation systems, and external brokerage / custodian bank systems involved in custody business are often developed by different vendors, with varying data structures and interface specifications. The most critical problem caused by this heterogeneous environment is the inherent conflict in data definitions. For example, the "asset balance" in a business report might be calculated based on the settlement price in the core system, while it might be calculated based on market value in the valuation system. Further complicating matters, different systems may record the same business event (such as dividend payments) at different times; some use the record date, while others use the actual payment date, making it impossible for the data to align at any given point in time during reconciliation. This is particularly problematic when dealing with new types of custody assets such as cross-border investments or crypto assets, as the on-chain data format is completely incompatible with traditional account systems. Bank systems may not even be able to recognize basic information such as address balances, let alone perform automated reconciliation.

[0032] Data distortion caused by deficiencies in data integration and data governance: Several technical vulnerabilities exist in the process of data extraction, transformation, and loading into the reporting system. First, in the extraction phase, field mapping often deviates. For example, the source system's "transaction date and time" is in string format, while the target system requires a timestamp format; millisecond-level loss during the conversion process can lead to reconciliation discrepancies. Second, in the conversion phase, changes in business definitions are often not synchronized with the ETL logic. For instance, regulatory requirements may have adjusted the calculation formula for "leverage ratio," but the conversion scripts in the data warehouse may not have been updated in time, resulting in a long-term systematic discrepancy between reported data and underlying business data. Furthermore, broken data lineages make problem tracing extremely difficult: when a summary indicator does not match, technical personnel often find it difficult to quickly pinpoint which source table, which field, or which conversion caused the problem.

[0033] Dynamic Business Process Changes and Lagging Data Governance: The custody business itself is constantly evolving. New product launches, expanded investment scope, and adjustments to trading rules all alter the data generation logic. However, the core contradiction facing the existing technology system is that business changes are rapid while IT response is slow. For example, when wealth management products begin investing in non-standard assets, the valuation system may be unable to parse the valuation tables for these assets, as these are often provided by the investees in PDF or Excel format. The system cannot automatically extract and verify the underlying asset data. This chain of "system inability to process - human intervention - human error" becomes a major source of data inconsistency. Even more problematic is that adjustments to business processes (such as the elimination of transaction approval nodes) can lead to changes in data collection timelines, making historical data incomparable to current data. However, data governance systems often lack dynamic tracking mechanisms for such changes.

[0034] To address at least some of the aforementioned technical problems, embodiments of the present invention provide a specific implementation of a financial product verification method based on a process robot, see [link to relevant documentation]. Figure 1 The method specifically includes the following: Step 100: Traverse the specified financial product storage addresses according to the preset configuration file; Step 200: Parse the valuation table of the financial products in the storage address of the financial products to generate the first dataset; Step 300: Parse the custody information of the financial product specified by the user to generate a second dataset; wherein the second dataset is stored at the storage address of the financial product; Step 400: Verify the key field values ​​extracted from the second dataset in the first dataset.

[0035] As described above, this embodiment of the invention provides a financial product verification method based on a process robot, comprising: first, traversing a specified financial product storage address according to a preset configuration file; then, parsing the valuation table of the financial product in the financial product storage address to generate a first dataset; parsing the custody information of the financial product specified by the user to generate a second dataset; wherein the second dataset is stored in the financial product storage address; and finally, verifying the key field values ​​extracted from the second dataset in the first dataset.

[0036] The present invention provides a financial product verification method based on process robots. By using process robot technology, it realizes the function of automatically matching management reports and custody valuation table data, thereby achieving data connection between external management reports and internal custody systems, improving work efficiency, reducing work error rate, timely feedback on management report data problems, and reducing risks.

[0037] For step 100, a predefined configuration file is first read. The configuration file defines the field mapping relationship to be compared, the matching rule threshold, and the output directory path. The matching rules include, but are not limited to, exact matching of key fields, time offset matching, grouping of adjacent timestamps, absolute amount tolerance, relative proportion tolerance, and status transition matching.

[0038] Time Shift Matching: The rule allows matching of system data on day T with report data on day T+1. For example, fund subscription data is recorded by the system on the trading day, but the custodian bank may not confirm the shares until the next day. The rule needs to set a time window (such as 24 hours or 1 business day).

[0039] Grouping by proximity timestamp: For high-frequency trading, timestamps recorded by different systems may differ by a few milliseconds or seconds. The matching rules will aggregate multiple transactions with similar times (e.g., within 1 second of each other) and the same amount into a single "transaction to be verified" for further matching.

[0040] Due to differences in valuation methods and calculation precision, the amounts are unlikely to be exactly equal. Absolute amount tolerance: Set a fixed minimum error amount (such as 0.01 yuan or 0.01), and within this range it is considered a match.

[0041] Relative Proportional Tolerance: For large assets, a tolerance is set proportionally (e.g., 0.1%). For example, if the valuation system prices based on the model and the trading system prices based on the transaction price, the valuation difference between the two can be automatically recognized as "interpreted" within a certain proportion.

[0042] State transition matching: The rules not only look at the current value, but also track changes in the state of the data. For example, if a transaction is "confirmed" in the report but "pending settlement" in the system data, the rules will first determine whether they are the same transaction, and then indicate a state mismatch, rather than directly determining that the transaction cannot be found.

[0043] Version overwrite matching: Allows report data to be matched with snapshot data at a certain point in history, solving the problem of "the report was generated from yesterday's data, but it has been changed today, so they don't match".

[0044] The valuation table in step 200 is used to characterize the value of the corresponding financial product.

[0045] For step 300, the Word document parser is invoked to load the management report file in the same folder. The Word parser uses the python-docx library to identify all table objects in the document and parses the content of each table into a second data set in sequence.

[0046] In some embodiments of the present invention, if the valuation table is in an unstructured format, see [link to relevant documentation]. Figure 2Step 200 includes: Step 201: Divide the valuation table to obtain sub-tables of the valuation table; Step 202: Parse the sub-table to generate a first dataset; wherein the first dataset includes: the table header of the sub-table and the attribute values ​​of the table header.

[0047] Structured tables refer to tabular data with a clear, predefined data model. Their characteristics are: Fixed rows and columns: Each column represents a specific field (such as "securities code" or "holding quantity"), and each row represents a record.

[0048] The format is well-organized: data types, length, and precision are all clearly constrained.

[0049] Machine-readable: Can be directly read and manipulated by databases, APIs, or data processing programs without complex parsing.

[0050] Presentation formats include: relational database tables, CSV / Excel files (with standard headers), JSON / XML structured data, and reconciliation files exported from internal systems.

[0051] Correspondingly, unstructured tables refer to tabular data embedded in unstructured documents that lack a fixed machine-readable format. Their characteristics are: The format is varied and irregular: it may contain merged cells, diagonal headers, multi-level headers, page breaks, etc.

[0052] The media are complex: they can be found in PDFs (scanned copies or original PDFs), Word documents, email bodies, and images (screenshots, photos).

[0053] Data and layout are mixed together: visual elements such as table lines, font styles, and position coordinates are mixed with data content and can only be separated by visual recognition.

[0054] Presentation formats include: PDF valuation sheets sent by external managers, scanned bank statements from custodian banks, HTML tables embedded in web pages (with non-standard layouts), and tables attached to encrypted emails.

[0055] For step 201, the valuation table is segmented according to its structural characteristics and processing purpose. The segmentation methods are mainly divided into two categories: segmentation by functional blocks (semantic splitting) and segmentation by data content (physical splitting). These two segmentation methods are shown in Table 1.

[0056] Table 1

[0057] Specifically, if the segmentation method is based on functional blocks, step 201 includes the following steps during implementation: First, the title section needs to be identified and extracted. The top of the valuation table contains global information such as product name, valuation date, and currency. This part needs to be separated separately as common metadata for all subsequent sub-tables.

[0058] Next, the detailed section is segmented: this is the core sub-table, displaying specific holdings details (such as stocks, bonds, funds, etc.) in a two-dimensional table format. The key to segmentation lies in accurately identifying the table's column headers (such as "Securities Code," "Securities Name," "Holding Quantity," and "Market Value") and the starting position of the data rows. For complex tables with merged cells or multi-level headers, more sophisticated layout analysis algorithms are needed to correctly restore the meaning of the data in each column.

[0059] Finally, the statistical section is divided: the totals, subtotals, and total assets summarized at the bottom or side of the table form another independent sub-table. Separating this from the detailed data allows it to be used independently to verify whether the sum of the detailed data matches the total, which is an important logical verification process in reconciliation.

[0060] Specifically, if the splitting method is splitting by data content, step 201 includes the following steps: after the valuation table has been converted into structured data (such as a database table or a cleaned CSV file), it needs to be split according to the value of a specific field in order to manage or distribute it more granularly.

[0061] Segmentation by asset class: For example, a single valuation table containing all holdings can be split into multiple independent sub-tables based on the "asset type" field (such as "stocks," "bonds," "futures," and "deposits"). This allows the verification system to compare the stock sub-table with exchange data and the bond sub-table with ChinaBond valuations, achieving specialized division of labor in verification.

[0062] Splitting by portfolio or trader: If a managed product contains multiple portfolios, the valuation table can be split by the "portfolio code" field, making it easier for each portfolio manager to check independently.

[0063] Splitting by Time Period: A large valuation table containing data from multiple months is split into monthly sub-tables based on the "month" field, facilitating monthly archiving and reconciliation. The "Show Report Filter Page" function in PivotTables allows for the generation of multiple sub-tables with a single click based on a filter field (such as month).

[0064] For step 202, for semi-structured / unstructured sub-tables (such as tables in PDFs): table recognition is required, including recognition of the header area, cell parsing, and mapping of the header to the data rows.

[0065] Generate the following content for the first dataset: table headers (e.g., "Security Code", "Holding Quantity") and corresponding attribute values ​​(e.g., "000001", "10000"). It may be necessary to map the original table headers to internal standard fields.

[0066] In some embodiments of the present invention, if the valuation table is in a structured format, see [link to relevant documentation]. Figure 3 Step 200 includes: Step 203: Map the valuation table to key-value pairs; When the valuation table itself is in a structured format (such as an Excel worksheet, CSV file, or database exported table), mapping it to key-value pairs is the core step in generating the standardized first dataset. This process aims to transform two-dimensional tabular data into a key-value structure that can be flexibly processed by machines, laying the foundation for subsequent automated comparison with data from business systems.

[0067] The key-value pairs in step 201 include: Key: Column name (header field), which needs to be standardized.

[0068] Value: The specific data in the corresponding column of this row, which needs to be type-converted and cleaned.

[0069] The final result is an array of key-value pair objects (i.e., the first dataset), where each object represents a detail record.

[0070] The execution steps of step 201 include: Reading the first row (or a combination of multiple rows, for multi-level table headers) of the table as the original field names. Removing leading and trailing spaces and special characters. Consistent naming style (such as camelCase or underscore).

[0071] Mapping to internal standard field names: Using a predefined mapping dictionary, "Securities Code", "Code", "Code", etc. are uniformly mapped to "security_code".

[0072] For multi-level headers, complete semantics are generated by concatenation. For example, "Holdings_Stock_Code" is mapped to "security_code".

[0073] Next, determine the starting row of data (skip the header, possible unit rows, and description rows). Identify the ending row of data (until the end of the table or when encountering markers such as "Total" or "Finals," these non-detail rows need to be removed). Iterate through each row of data, for each cell: Cleaning values: Remove currency symbols and thousands separators; standardize date formats; handle null values ​​(e.g., set to null or default value).

[0074] Type conversion: Convert according to the target field type (numeric, string, date) to ensure consistency.

[0075] Construct key-value pairs: Use the normalized field names as keys and the cleaned and transformed values ​​as values.

[0076] Step 204: Parse the valuation table according to the key-value pairs to generate the first dataset.

[0077] Collect the key-value pairs generated from each row into an array or list. Additionally, metadata (such as valuation date, product ID) can be appended to each object to maintain context.

[0078] In some embodiments of the present invention, step 300 includes: The python-docx library is used to identify table objects in the managed information, and the contents of the table objects are parsed into a second data set according to the identification order. Specifically, this step includes the following: First, open and read the .docx format Word file using the python-docx library, representing it as a Document object. All tables contained in the document can be accessed through the document object's tables attribute. This attribute returns a list of table objects, each encapsulating the table's structure (rows, columns, cells).

[0079] Regarding the recognition order: In most cases, the order of the tables in the list matches the order in which the tables appear in the document (i.e., in document flow order). However, because the underlying implementation relies on WordprocessingML parsing, a very small number of special formats may cause the order to differ slightly from the visual order. If you need to strictly follow the document reading order, you can further traverse the document's XML element tree and extract the tables one by one according to the element type (w:tbl), thus ensuring that the order is completely consistent with the document flow.

[0080] Next, each table object is traversed in a predetermined order, and each table is parsed.

[0081] Each table object contains a `rows` property (a collection of rows) and a `columns` property (a collection of columns). Iterate through each row, then iterate through each cell in that row, and retrieve the text content of the cell using its `text` property.

[0082] For merged cells, the python-docx library automatically handles the cell span. When traversing rows and columns, merged cells will occupy multiple column positions in their respective rows, but when extracting text, they only need to be read once, without the need for manual expansion.

[0083] The extracted text is organized into a two-dimensional list (or matrix) by rows and columns, serving as the data carrier for the table. Meta-information of the table, such as the number of rows and columns, can also be recorded.

[0084] Based on business rules (such as bolding the first row or specifying non-numeric content), specific rows can be identified as headers and stored separately from the data rows for easier semantic understanding later. After parsing, the data from all tables is aggregated into a single set, known as the "second data set." This set is a list, with each element corresponding to a table containing the following information: Table identifiers: such as serial number, position in the document (page number).

[0085] Table structure: number of rows, number of columns.

[0086] Tabular data: A two-dimensional text array that may contain headers and data rows.

[0087] Extended attributes: If needed, table titles can be added (inferred from the context paragraphs) or associated with other business information.

[0088] During the execution of step 300, the following should be noted: Word allows nested tables, but python-docx has limited support for nested tables and requires recursive processing of inner tables.

[0089] Cells containing non-text content may contain images, formulas, etc. python-docx can only extract text; other content requires the use of other libraries or can be ignored.

[0090] If you need to preserve styles (such as font and background color), python-docx can also retrieve them, but it will increase the parsing complexity. Business requirements only need to focus on the text content.

[0091] In some embodiments of the present invention, the configuration file includes: the mapping relationship of the fields to be compared, the matching rule threshold, and the output directory path.

[0092] It is understandable that financial product data from different sources may use different field names; for example, the valuation table may use "Securities Code" while the custody report may use "Code". Furthermore, some information may be distributed across multiple fields, requiring combination mapping (e.g., mapping "Full Name" + "Abbreviation" to "Securities Name"). Therefore, during the verification process of financial products, it is necessary to ensure that the comparison is made based on the same business attribute to avoid misattribution (e.g., incorrectly comparing "Holding Cost" with "Market Value").

[0093] Field mapping refers to establishing a corresponding relationship between fields in source data (such as the first dataset parsed from a valuation table) and fields in target data (such as the second dataset parsed from a Word table), clarifying which fields need to be compared and the correspondence between them.

[0094] Matching rule thresholds are quantitative or qualitative standards for determining whether two records match. Because data may have slight differences (such as entry errors, calculation precision, and time delays), it is not possible to require all fields to be completely identical; therefore, an allowable deviation range needs to be set.

[0095] Regarding the determination of the threshold: Business rules-driven: Set according to regulatory requirements and internal risk control standards. For example, regulations stipulate that valuation errors must not exceed 0.1%.

[0096] Statistical analysis: Calculate the distribution of field differences based on historical data, and set the threshold to mean ± 3σ, or quantile.

[0097] Dynamic adjustment: During system operation, the threshold is automatically or manually adjusted based on feedback from false alarm rate and false negative rate.

[0098] The output directory path refers to the storage location of the result files after the comparison is completed. These results include records of successful / failed matches, difference details, statistical reports, logs, etc.

[0099] In some embodiments of the present invention, the key field values ​​include: the product identifier of the financial product, the index number of the custody information, the current line number, the field to be compared, and the matching status.

[0100] In the data verification process for custody services, recording detailed comparison results is crucial for discrepancy analysis, issue tracing, and compliance auditing. The five fields you mentioned—the product identifier of the financial product, the index number of the custody information, the current bank number, the fields being compared, and the matching status—constitute the core dimensions of the comparison details record. They comprehensively depict the context of each comparison operation from five aspects: business object, data source, record location, comparison content, and result judgment. The following explains their definitions, sources, and functions one by one. Specifically: Product identifier for financial products: A unique code or ID that identifies a financial product, such as the product code of a wealth management product, the fund code of a fund, or the filing number of an asset management plan. It originates from the first dataset (e.g., the results of a valuation table parsing) and may also exist in the second dataset (custodian report). A corresponding relationship needs to be established through field mapping before comparison.

[0101] The product labeling of financial products serves the following functions: Business association: The verification results are linked to specific products, making it easier to calculate the matching rate and filter discrepancy records by product dimension.

[0102] Cross-system traceability: The product identifier is a key value that connects the custody business system, valuation system, and investment trading system, and can be used for further in-depth querying of the product's detailed holdings and transaction history.

[0103] Access Control and Filtering: When outputting results, access control can be applied to data based on product identifiers to ensure that different product teams can only access the data they are responsible for.

[0104] The managed information index number is a globally unique identifier for each record in the second dataset (managed report parsing results). It can be an automatically generated sequence number during parsing or a combination of the table ID and row number in the original document (e.g., Table2_Row5). The managed information index number is assigned by the parsing module when generating the second dataset, ensuring that each record extracted from the managed report has an independent index.

[0105] The purpose of the index number for managed information includes: When a record fails to match, the index number can be used to quickly jump to the corresponding table and row in the original Word document for manual review of the context. The index number records the data source, facilitating tracing problems during the parsing process (such as a parsing error in a row leading to missing data). During the comparison process, the index number is used to map records from the first and second datasets one-to-one (or as supplementary information to the matching results).

[0106] Current row number: The row number (or record sequence number) of the current record in the first dataset (the result of parsing the valuation table). It is usually numbered sequentially starting from 1. The current row number is assigned by the parsing module when generating the first dataset.

[0107] The current line number serves the following purposes: Record-level traceability: A unique record is identified along with the product identifier and index number. When manual intervention is required, the specific row in the original valuation table can be directly located.

[0108] Data integrity verification: The row number can be used to check if there are any missing records (e.g., the first dataset has 100 rows, but the output only has 99 records, indicating that a certain row was not included in the comparison).

[0109] Batch processing reference: When outputting difference reports, line numbers can serve as a quick index for operators to view the original files.

[0110] Fields to be compared: A list of fields (field names) actually used in this comparison operation, usually recorded in comma-separated or array form. For example, "Securities Code", "Securities Name", "Market Value". The fields to be compared are determined according to the configured field mapping relationship, or can be dynamically recorded (fields may be excluded due to missing fields).

[0111] The fields used for comparison serve the following purposes: They clearly inform users which fields the comparison is based on, avoiding misunderstandings due to omitted fields. When the matching status is "mismatch," combining the comparison fields allows for quick focusing on the specific fields where the difference occurred (usually, additional details of the differences for each field are recorded, but the "compared fields" themselves provide the scope). During later audits, it can be used to verify whether the comparison was performed according to preset rules and whether any fields were incorrectly excluded.

[0112] Matching status: The result status of the current record after being judged by the matching rules. Possible values ​​include: Exact match: All fields involved in the comparison satisfy the matching rules.

[0113] Partial match: Some fields match, some do not (details of the differences need to be considered).

[0114] Mismatch: Key fields do not match or the rule is not passed overall.

[0115] As described above, this embodiment of the invention provides a financial product verification method based on a process robot, comprising: first, traversing a specified financial product storage address according to a preset configuration file; then, parsing the valuation table of the financial product in the financial product storage address to generate a first dataset; parsing the custody information of the financial product specified by the user to generate a second dataset; wherein the second dataset is stored in the financial product storage address; and finally, verifying the key field values ​​extracted from the second dataset in the first dataset.

[0116] The present invention provides a financial product verification method based on process robots. By using process robot technology, it realizes the function of automatically matching management reports and custody valuation table data, thereby achieving data connection between external management reports and internal custody systems, improving work efficiency, reducing work error rate, timely feedback on management report data problems, and reducing risks.

[0117] For further explanation of the plan, see Figure 4 The present invention also provides a specific implementation of a financial product verification method based on a process robot, which includes the following:

[0118] Step S1: Configure and initialize the configuration file.

[0119] After the module starts, it first reads a predefined configuration file. The configuration file defines the mapping relationships of the fields to be compared, the matching rule thresholds, and the output directory path. The matching rules include, but are not limited to, exact matching of key fields.

[0120] Step S2: Load and parse the data.

[0121] The module iterates through the product folders in the specified input directory. For each product folder, steps S3 to S8 are executed: Step S3: Call the Excel parser to load the valuation table file in the folder. The parser uses the pandas library to read the specified worksheet into a first data set (DataFrame) and performs standardization cleaning on key fields; Step S4: Invoke the Word document parser and load the management report file in the same folder. The parser uses the python-docx library to identify all table objects in the document and sequentially parses the content of each table into a second data set; Step S5: Rule-based automated comparison. Based on the field mapping relationship read in step S1, the module performs a comparison operation on each Word table (i.e., the second dataset) sequentially. For each row of data in the current table, steps S6 to S8 are executed: Step S6: Extract the key field values ​​from the row that will be used as the matching criteria; Step S7: In the first dataset (Excel valuation table data) obtained in step S2, search for records that match the key field values. Matching is performed by a pre-configured rule engine. Step S8: Generate a comparison result record. This record should include at least: product identifier, Word table index number, current row number, compared fields, and matching status; Step S9: Result visualization, annotation, and summarization. Based on the comparison results recorded in step S3, the module executes steps S10 to S15 in parallel. Step S10: For records with a matching status of "failed", the module locates the corresponding table cell in the management report Word document by calling the application interface of python-docx, and modifies its background fill attribute to highlight it in yellow. Step S11: The module creates a structured summary table of verification results. Preferably, this table is in Excel format. The module writes all the comparison result records generated in S300 into this summary table in sequence. The summary table contains the following fields: matching status, data content, position in the Word document (table number, row number, column number), and timestamp; Step S12: Output and Iteration. After comparing and processing all Word tables in the current product folder, proceed to steps S13 to S15; Step S13: Output and Iteration. Save the highlighted Word management report to the specified output path; Step S14: Save the generated verification result summary Excel file to the same output path.

[0122] Step S15: Determine if all product folders have been processed. If yes, end the process; otherwise, return to step S2 and process the next product folder.

[0123] As described above, this embodiment of the invention provides a financial product verification method based on a process robot, comprising: first, traversing a specified financial product storage address according to a preset configuration file; then, parsing the valuation table of the financial product in the financial product storage address to generate a first dataset; parsing the custody information of the financial product specified by the user to generate a second dataset; wherein the second dataset is stored in the financial product storage address; and finally, verifying the key field values ​​extracted from the second dataset in the first dataset.

[0124] The present invention provides a financial product verification method based on a process robot. By utilizing process robot technology, it enables banking departments to automatically verify custody business reports and business system data. It features uninterrupted operation, rapid comparison, anomaly handling, flexible matching rules, and matching result labeling, which can significantly improve work efficiency, accuracy, and timeliness of comparison. Business personnel only need to place the custody business reports and custody system data to be verified in a folder, set the matching logic, and start the robot program. The robot can then automatically compare the data according to the matching logic and send the selected results to the business personnel.

[0125] Based on the same inventive concept, this application also provides a process robot-based financial product verification device, which can be used to implement the method described in the above embodiments, as shown in the following embodiments. Since the principle of the process robot-based financial product verification device in solving the problem is similar to that of the process robot-based financial product verification method, the implementation of the process robot-based financial product verification device can refer to the implementation of the process robot-based financial product verification method, and repeated details will not be elaborated further. As used below, the terms "unit" or "module" can refer to a combination of software and / or hardware that implements a predetermined function. Although the system described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0126] Embodiments of the present invention provide a specific implementation of a process robot-based financial product verification device capable of implementing a process robot-based financial product verification method. See [link to specific implementation details]. Figure 5 A financial product verification device based on a process robot specifically includes the following components: The storage address traversal module 10 is used to traverse the specified financial product storage addresses according to a preset configuration file. The first dataset generation module 20 is used to parse the valuation table of the financial products in the financial product storage address and generate the first dataset. The second dataset generation module 30 is used to parse the custody information of the financial product specified by the user and generate a second dataset; wherein, the second dataset is stored at the storage address of the financial product; The key field value extraction module 40 is used to verify the key field values ​​extracted from the second dataset in the first dataset.

[0127] In some embodiments of the present invention, see Figure 6 If the valuation table is in an unstructured format, the first dataset generation module 20 includes: Valuation table segmentation unit 20a is used to segment the valuation table and obtain sub-tables of the valuation table; The first dataset generates a first unit 20b, which is used to parse the sub-table and generate the first dataset; wherein, the first dataset includes: the table header of the sub-table and the attribute values ​​of the table header.

[0128] In some embodiments of the present invention, see Figure 7 If the valuation table is in a structured format, the first dataset generation module 20 includes: Valuation table mapping unit 20c is used to map the valuation table into key-value pairs; The second dataset generates the first unit 20d, which is used to parse the valuation table according to the key-value pairs to generate the first dataset.

[0129] In some embodiments of the present invention, the second dataset generation module includes: The second dataset generation unit is used to identify table objects in the managed information using the python-docx library, and parse the contents of the table objects into a second dataset according to the identification order.

[0130] In some embodiments of the present invention, the configuration file includes: the mapping relationship of the fields to be compared, the matching rule threshold, and the output directory path.

[0131] In some embodiments of the present invention, the key field values ​​include: the product identifier of the financial product, the index number of the custody information, the current line number, the field to be compared, and the matching status.

[0132] As described above, embodiments of the present invention provide a financial product verification device based on a process robot, comprising: a storage address traversal module, used to traverse a specified financial product storage address according to a preset configuration file; a first dataset generation module, used to parse the valuation table of the financial product in the financial product storage address and generate a first dataset; a second dataset generation module, used to parse the custody information of the financial product specified by the user and generate a second dataset; wherein the second dataset is stored in the financial product storage address; and a key field value extraction module, used to verify the key field values ​​extracted from the second dataset in the first dataset.

[0133] The present invention provides a financial product verification device based on a process robot. By using process robot technology, it realizes the function of automatically matching management reports and custody valuation table data, thereby achieving data connection between external management reports and internal custody systems, improving work efficiency, reducing work error rate, timely feedback on management report data problems, and reducing risks.

[0134] It should be noted that the financial product verification method and apparatus based on process robots provided in this embodiment of the invention can be used in the financial field, or in any technical field other than the financial field. This embodiment of the invention does not limit the application field of the financial product verification method and apparatus based on process robots.

[0135] The embodiments of this application also provide a specific implementation of an electronic device capable of implementing all steps in the process robot-based financial product verification method described in the above embodiments. See [link to implementation details]. Figure 8 The electronic devices specifically include the following: Processor 1201, memory 1202, communications interface 1203, and bus 1204; The processor 1201, memory 1202, and communication interface 1203 communicate with each other via bus 1204; the communication interface 1203 is used to realize information transmission between server-side devices and user-side devices and other related devices. The processor 1201 is used to call the computer program in the memory 1202. When the processor executes the computer program, it implements all the steps in the financial product verification method based on the process robot in the above embodiment. For example, when the processor executes the computer program, it implements the following steps: Iterate through the specified financial product storage addresses according to the preset configuration file; Parse the valuation table of the financial products in the storage address of the financial products to generate the first dataset; Parse the custody information of the financial product specified by the user to generate a second dataset; wherein the second dataset is stored at the storage address of the financial product; Verify the key field values ​​extracted from the second dataset in the first dataset.

[0136] Embodiments of this application also provide a computer-readable storage medium capable of implementing all steps of the process robot-based financial product verification method in the above embodiments. The computer-readable storage medium stores a computer program, which, when executed by a processor, implements all steps of the process robot-based financial product verification method in the above embodiments. Iterate through the specified financial product storage addresses according to the preset configuration file; Parse the valuation table of the financial products in the storage address of the financial products to generate the first dataset; Parse the custody information of the financial product specified by the user to generate a second dataset; wherein the second dataset is stored at the storage address of the financial product; Verify the key field values ​​extracted from the second dataset in the first dataset.

[0137] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to interchangeably. Each embodiment focuses on its differences from other embodiments. In particular, hardware + program embodiments are relatively simple in description because they are fundamentally similar to method embodiments; relevant parts can be referred to the descriptions in the method embodiments.

[0138] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0139] While this application provides method operation steps as shown in the embodiments or flowcharts, more or fewer operation steps may be included based on conventional or non-inventive labor. The order of steps listed in the embodiments is merely one possible execution order among many and does not represent the only execution order. In actual device or user terminal product execution, the method can be executed in the order shown in the embodiments or drawings or in parallel (e.g., in a parallel processor or multi-threaded processing environment).

[0140] For ease of description, the above devices are described in terms of function, divided into various modules. Of course, in implementing the embodiments of this specification, the functions of each module can be implemented in one or more software and / or hardware components, or a module that performs the same function can be implemented by a combination of multiple sub-modules or sub-units. The device embodiments described above are merely illustrative. For example, the division of units is only 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 through some interfaces, or indirect coupling or communication connection between devices or units, and may be electrical, mechanical, or other forms.

[0141] Those skilled in the art will also know that, besides implementing the controller using purely computer-readable program code, the same functions can be achieved by logically programming the method steps, making the controller function as logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers (PLCs), and embedded microcontrollers. Therefore, such a controller can be considered a hardware component, and the devices within it used to implement various functions can also be considered structures within that hardware component. Alternatively, the devices used to implement various functions can be considered as both software modules implementing the method and structures within a hardware component.

[0142] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0143] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0144] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, system embodiments are basically similar to method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments. In the description of this specification, the terms "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., refer to specific features, structures, materials, or characteristics described in connection with that embodiment or example, which are included in at least one embodiment or example of the embodiments in this specification. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described can be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification and the features of different embodiments or examples.

[0145] The above description is merely an embodiment of the present specification and is not intended to limit the embodiments of the present specification. For those skilled in the art, various modifications and variations can be made to the embodiments of the present specification. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principle of the embodiments of the present specification should be included within the scope of the claims of the embodiments of the present specification.

Claims

1. A method for verifying financial products based on process robots, characterized in that, include: Iterate through the specified financial product storage addresses according to the preset configuration file; Parse the valuation table of the financial products in the storage address of the financial products to generate the first dataset; Parse the custody information of the financial product specified by the user to generate a second dataset; wherein the second dataset is stored at the storage address of the financial product; Verify the key field values ​​extracted from the second dataset in the first dataset.

2. The financial product verification method according to claim 1, characterized in that, If the valuation table is in an unstructured format, parse the valuation table of the financial product in the storage address of the financial product to generate a first dataset, including: The valuation table is segmented to obtain sub-tables of the valuation table; The sub-table is parsed to generate a first dataset; wherein the first dataset includes: the table header of the sub-table and the attribute values ​​of the table header.

3. The financial product verification method according to claim 1, characterized in that, If the valuation table is in a structured format, parse the valuation table of the financial product in the storage address of the financial product to generate a first dataset, including: Map the valuation table to key-value pairs; The valuation table is parsed based on the key-value pairs to generate the first dataset.

4. The financial product verification method according to claim 3, characterized in that, Parse the custody information of the financial products specified by the user to generate a second dataset, including: The python-docx library is used to identify table objects in the managed information, and the contents of the table objects are parsed into a second data set according to the identification order.

5. The financial product verification method according to claim 1, characterized in that, The configuration file includes: the mapping relationship of the fields to be compared, the threshold of the matching rules, and the output directory path.

6. The financial product verification method according to claim 1, characterized in that, The key field values ​​include: the product identifier of the financial product, the index number of the custody information, the current line number, the fields to be compared, and the matching status.

7. A financial product verification device based on a process robot, characterized in that, include: The storage address traversal module is used to traverse the specified financial product storage addresses according to a preset configuration file. The first dataset generation module is used to parse the valuation table of the financial products in the storage address of the financial products and generate the first dataset. The second dataset generation module is used to parse the custody information of the financial product specified by the user and generate a second dataset; wherein, the second dataset is stored at the storage address of the financial product; The key field value extraction module is used to verify the key field values ​​extracted from the second dataset in the first dataset.

8. A computer program product comprising a computer program / instructions, characterized in that, When the computer program / instructions are executed by the processor, they implement the steps of the financial product verification method based on a process robot as described in any one of claims 1 to 6.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the steps of the financial product verification method based on a process robot as described in any one of claims 1 to 6.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When executed by a processor, the computer program implements the steps of the financial product verification method based on a process robot as described in any one of claims 1 to 6.

Images