A method and device for identifying a concealed repayment clue

Abstract

A transaction data processing method and device based on an object relationship graph, and a storage medium, the method comprising: generating an object relationship graph and obtaining a claim amount and a debt amount from case data, the graph containing first, second and third object nodes in a debt relationship, with data nodes and edge tables representing object and transaction associations; based on the transaction association attributes between the candidate nodes and the first and second object nodes, filtering nodes that meet the preset association conditions as the third object nodes; determining a time constraint based on the case data, retrieving target transaction records from the transaction data of the third object nodes that meet the time constraint and transaction direction constraint; performing amount aggregation calculation on the target transaction records to obtain the actual repayment amount, and in response to the difference between the claim amount and the debt amount and the actual repayment amount, outputting early warning data.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, and specifically to a method, apparatus, and computer-readable storage medium for processing transaction data based on object relationship graphs. Background Technology

[0002] Currently, in areas such as civil procuratorial supervision, financial auditing, and loan dispute resolution, uncovering clues about concealed repayments mainly relies on manual review of case files and transaction records, or focusing solely on direct transaction records between the lender and borrower. However, in actual lending relationships, debtors often repay loans through third parties (such as relatives, friends, or affiliated companies). Existing technologies often struggle to automatically identify these hidden repayment channels within massive amounts of transaction data, making it impossible to fully reconstruct the facts of debt repayment. This lack of identification of third-party repayment activities not only increases the difficulty and workload of discovering clues but also easily leads to deviations in the calculation of actual repayment amounts, thereby affecting the accuracy of judgments regarding inflated litigation amounts and concealed repayments. Therefore, there is an urgent need for a technological solution that can automatically identify hidden repayment channels and improve the comprehensiveness and accuracy of clue discovery. Summary of the Invention

[0003] To address the problems of existing technologies, such as difficulty in automatically identifying hidden repayment paths and low efficiency and accuracy in finding clues, this application proposes a transaction data processing method and apparatus based on object relationship graphs. By utilizing object relationship graphs to mine common transaction objects between debtors and creditors and combining multi-dimensional constraint retrieval of repayment records, it achieves intelligent identification of clues to concealed repayments.

[0004] To achieve the above objectives, the present invention adopts the following technical solution: A transaction data processing method based on an object relationship graph includes: generating an object relationship graph and obtaining the claimed amount and debt amount from case data. The object relationship graph includes a first object node, a second object node, and a third object node in the debt relationship, with data nodes and edges representing the association between objects and transactions; selecting nodes that meet preset association conditions from the candidate nodes as the third object node based on the transaction association attributes between the candidate nodes and the first and second object nodes; determining time constraints based on the case data and retrieving target transaction records that meet the time constraints and transaction direction constraints from the transaction data of the third object node; performing amount aggregation calculation on the target transaction records to obtain the actual repayment amount; and outputting early warning data in response to the claim amount exceeding the difference between the debt amount and the actual repayment amount.

[0005] The above solution breaks the limitation of focusing only on the lending parties by introducing a "third object node" (i.e. a common transaction object) as an intermediate node. By using graph topology attribute filtering and multi-dimensional constraint retrieval, it solves the technical problem of the difficulty in automatically identifying implicit repayment behavior in massive transaction data, and improves the comprehensiveness and accuracy of clue discovery.

[0006] Preferably, generating the object relationship graph includes: generating the object relationship graph based on the case data and transaction data. This preferred solution clarifies the data foundation of the relationship graph and provides data support for subsequent screening.

[0007] Preferably, the transaction association attributes include at least one of the following: the transaction frequency between the candidate node and the first object node and the second object node within a preset statistical period; the cumulative transaction amount between the candidate node and the first object node and the second object node; and the association relationship type between the candidate node and the first object node and the second object node, wherein the association relationship type includes at least one of the transaction relationship type and the social relationship type.

[0008] This preferred solution improves the accuracy of loan repayment path discovery by using multi-dimensional filtering of graph topology attributes to accurately identify third-party nodes that have substantial transactional connections with both debtors from candidate nodes.

[0009] Preferably, the time constraint is determined based on the debt initiation time and the dispute time, and the transaction direction constraint is a transfer to the second object node; the target transaction record is a transaction record that satisfies the transaction direction constraint after the debt initiation time and before the dispute time. This preferred solution clarifies the retrieval dimension of the target transaction record, ensuring the consistency between the retrieved record and the debt facts in terms of time logic.

[0010] Preferably, the retrieval of target transaction records satisfying the time and transaction direction constraints includes: obtaining all transaction data of the third object node after the debt initiation time and before the dispute time; for each obtained transaction data, extracting the transaction type field, the counterparty name field, and the transaction amount field; retrieving transaction data where the transaction type field is a transfer-in type and the counterparty name field matches the name of the second object node; determining the retrieved transaction data as the target transaction record; and performing amount aggregation calculation on the target transaction record to obtain the actual repayment amount, including: summing the amounts of the target transaction records to obtain the actual repayment amount. This preferred solution concretizes the retrieval conditions into executable field extraction and matching logic and clarifies the amount calculation method, enhancing the feasibility of the solution.

[0011] Preferably, the early warning data includes: debt fact information, including the identity information of the first object node, the identity information of the second object node, the debt amount, and the time information related to the debt; processing link information, including the filtering parameters of the third object node, the search conditions and filtering rules for the target transaction records; a list of supporting transaction data, including the transaction time, transaction amount, transaction type, and counterparty name for each target transaction record; and judgment result data, including the numerical comparison results of the claimed amount, the debt amount, and the actual repayment amount, and risk identification data generated based on the comparison results. This preferred scheme limits the core elements of the output content, ensuring the integrity and traceability of the early warning data.

[0012] Preferably, before generating the object relationship graph, the method further includes cleaning and standardizing the acquired multi-source heterogeneous fund transaction data to form a structured transaction database. This preferred solution, through data preprocessing, eliminates the impact of data source heterogeneity on the analysis results and improves data quality.

[0013] As a preferred embodiment, the method further includes: extracting debt information from case documents using an information extraction model. This debt information includes information about the debtor, the debt commencement date, the dispute date, the debt amount, and the claimed amount. This preferred solution enables the automatic extraction of key debt information from unstructured documents, improving the automation level of data processing.

[0014] Furthermore, this invention also provides a transaction data processing device based on an object relationship graph, comprising: a relationship graph construction module, used to generate an object relationship graph and obtain the claimed amount and debt amount from case data, wherein the object relationship graph includes a first object node, a second object node, and a third object node in the debt relationship, using data nodes and edges to represent the association between objects and transactions, and selecting nodes that meet preset association conditions from the candidate nodes as the third object node based on the transaction association attributes between the candidate nodes and the first and second object nodes; a transaction retrieval module, used to determine time constraints based on the case data and retrieve target transaction records that meet the time constraints and transaction direction constraints from the transaction data of the third object node; and an amount comparison module, used to perform amount aggregation calculation on the target transaction records to obtain the actual repayment amount, and output warning data in response to the claim amount exceeding the difference between the debt amount and the actual repayment amount. The above device, through the collaborative work of its modules, achieves the same technical effect as the method-only approach.

[0015] Furthermore, the present invention also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the method as described in any one of claims 1 to 8.

[0016] The present invention provides a transaction data processing method and apparatus based on object relationship graphs, the advantages of which are as follows: 1. Improved the comprehensiveness of identifying implicit repayment clues: By generating a relationship graph that includes the common transaction objects (third object nodes) of the debtor and creditor, and filtering the third object nodes based on the graph's topological attributes, it breaks through the limitation of traditional methods that only focus on the direct lending parties, and can effectively uncover implicit paths of repayment through third parties, avoiding the omission of clues.

[0017] 2. Improved the accuracy and efficiency of clue identification: By combining the time window constraints of the debt initiation time and the dispute time, as well as the transaction direction constraints of the transfer to the creditor, the system can accurately retrieve target transaction records from massive transaction data and automatically calculate the difference between the actual repayment amount and the debt amount. This enables automated and quantitative judgment of concealed repayment situations, significantly reducing the cost of manual review and improving the objectivity and accuracy of the judgment.

[0018] 3. Enhanced data availability and automated processing: By cleaning and standardizing multi-source heterogeneous data, and by using information extraction models to automatically extract key debt information from case documents, the automatic flow from unstructured data to structured analysis data was achieved, laying a solid data foundation for subsequent map construction and clue mining. Attached Figure Description

[0019] Figure 1 This is a flowchart of a transaction data processing method based on object relationship graphs according to an embodiment of the present invention. Detailed Implementation

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

[0021] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains. The terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the scope of the invention.

[0022] Example 1: As Figure 1As shown, this embodiment provides a transaction data processing method based on object relationship graphs. This method aims to solve the problem in existing technologies that only focus on direct transactions between lenders and borrowers while overlooking clues about third-party repayments. By generating a relationship graph containing implicitly related objects, it achieves intelligent identification of concealed repayment behavior.

[0023] Specifically, the method includes the following steps: Step S100: Generate an object relationship graph and obtain the claimed amount and debt amount from the case data. The object relationship graph includes a first object node, a second object node, and a third object node in the debt relationship, and uses data nodes and edges to represent the association between objects and transactions.

[0024] In this embodiment, the first object node typically corresponds to the debtor in a debt relationship, and the second object node corresponds to the creditor. Unlike traditional analyses that only focus on direct financial transactions between the debtor and creditor, this step creatively introduces a third object node. This third object node refers to an entity that has transactional relationships with both the first and second object nodes, commonly known as a "shared transaction object." For example, in private lending disputes, the debtor may transfer funds to the creditor through the accounts of their relatives, friends, or affiliated companies (i.e., the third object) to repay the loan. If only the direct flow of funds between the debtor and creditor is analyzed, such repayment on behalf of others is easily overlooked. By generating an object relationship graph containing the third object node, this invention can expand the analytical perspective from "point-to-point" direct transactions to an indirect transaction network of "point-intermediate-point," thereby providing a data structure foundation for uncovering implicit repayment paths. It should be understood that this object relationship graph can be stored using a graph database (such as Neo4j) or logically represented using a relational database's association table, as long as it can characterize the relationships between nodes.

[0025] Step S110: Based on the transaction association attributes between the candidate node and the first object node and the second object node, select the node that meets the preset association conditions from the candidate nodes as the third object node.

[0026] After generating the object relationship graph, there may be a large number of candidate nodes that have transactional relationships with both the first and second object nodes. However, not all candidate nodes are valid repayment channels. This step filters candidate nodes based on transaction relationship attributes, identifying nodes that meet preset relationship conditions as third object nodes. Transaction relationship attributes can include dimensions such as transaction frequency, cumulative transaction amount, and relationship type. Through multi-dimensional filtering logic, potential objects with repayment characteristics are accurately identified. The specific types of transaction relationship attributes and filtering logic will be explained in detail in Example 2.

[0027] Step S200: Determine the time constraint based on the case data, and retrieve the target transaction record that satisfies the time constraint and transaction direction constraint from the transaction data of the third object node.

[0028] After identifying potential repayment recipients (third-party nodes), not all transaction records of these recipients are related to repayment. To improve the accuracy of identification, this step introduces multi-dimensional constraints. Time constraints limit the time frame of transactions, typically based on the start time of the debt relationship (e.g., the initial lending date) and the time of dispute (e.g., the filing date of a lawsuit). Transaction direction constraints limit the flow of funds, for example, retrieving records where funds are transferred to the second-party node (creditor). Through these dual constraints, irrelevant noise data (such as transactions between the third-party node and the creditor before the debt occurred, or non-repayment fund transfers) can be eliminated from massive amounts of transaction data, accurately identifying transaction records with repayment characteristics. The specific method for determining the time window and the detailed retrieval process will be explained in detail in Example 2.

[0029] Step S300: Perform amount aggregation calculation on the target transaction record to obtain the actual repayment amount. In response to the claim amount exceeding the difference between the debt amount and the actual repayment amount, output early warning data.

[0030] After retrieving the target transaction records, this step aggregates and calculates the amounts from these records to obtain the actual repayment amount. Subsequently, this actual repayment amount is compared with the claimed amount and debt amount in the case. Specifically, if the claimed amount exceeds the difference between the debt amount and the actual repayment amount, it means the plaintiff may have concealed some repayment facts, resulting in an inflated claim amount. At this point, the system automatically outputs warning data. This warning data not only includes the warning conclusion but can also further include relevant data supporting the conclusion, allowing investigators to quickly verify it. The specific composition of the warning data will be explained in detail in Example 2. Through the above steps, this invention achieves a closed-loop process from uncovering hidden repayment paths to automatically outputting warning data, effectively solving the problem of missed clues caused by the strong concealment of third-party repayment behavior, and improving the efficiency and accuracy of clue discovery in relevant data analysis scenarios.

[0031] Example 2: This example, based on Example 1, provides a detailed explanation of the specific implementation methods for map construction, transaction retrieval, and early warning output. The core processing flow will be elaborated below, with the preliminary data preparation steps to be supplemented in Example 3.

[0032] Regarding the data foundation for graph construction, the generation of the object relationship graph includes generating the object relationship graph based on the case data and transaction data. Specifically, the case data typically originates from unstructured legal documents, which contain key elements such as party information, litigation claims, and factual findings. Transaction data originates from structured data such as bank statements and payment platform records. When generating the graph, the system first uses entity recognition technology to extract the first object (debtor) and the second object (creditor) from the case data as the core nodes of the graph. Subsequently, the system traverses the transaction data to identify the set of accounts with financial transactions with the first object and the set of accounts with financial transactions with the second object. Through set intersection operations, candidate nodes that have transactional relationships with both the first and second objects can be selected. In the graph structure, nodes represent object entities, edges represent transactional relationships, and the attributes of the edges can include dimensions such as total transaction amount, transaction frequency, and transaction time span.

[0033] Regarding the filtering logic for the third object node, the transaction association attributes include at least one of the following: the transaction frequency between the candidate node and the first object node and the second object node within a preset statistical period; the cumulative transaction amount between the candidate node and the first object node and the second object node; and the association relationship type between the candidate node and the first object node and the second object node, wherein the association relationship type includes at least one of the transaction relationship type and the social relationship type.

[0034] The transaction frequency mentioned here refers to the number of times a candidate node transacts with both the first and second target nodes within a preset statistical period. A higher transaction frequency indicates closer economic ties between the candidate node and both debtors, increasing its likelihood of serving as a repayment channel. The cumulative transaction amount reflects the scale of financial transactions between the candidate node and both debtors; a larger amount suggests a higher probability of repayment. The relationship type distinguishes the nature of the relationship between the candidate node and the debtors, such as transactional relationships (pure financial transactions) and social relationships (e.g., relatives, colleagues, affiliated companies). The presence of social relationships further supports the legitimacy of repayment. Through this multi-dimensional graph topology attribute screening, the system can effectively eliminate a large number of irrelevant candidate nodes and accurately identify potential targets with repayment characteristics.

[0035] It should be understood that the selection of the above-mentioned transaction association attributes is not the only implementation method. Depending on the specific case characteristics, those skilled in the art may also introduce other attribute dimensions, such as "transaction time distribution characteristics" or "consistency indicators of fund flow", as long as the attributes can reflect the substantial relationship between the candidate node and the debtor.

[0036] Regarding the specific implementation of time constraints and transaction direction constraints, the time constraints are determined based on the debt start time and the dispute time, and the transaction direction constraint is to transfer to the second object node; the target transaction record is a transaction record that satisfies the transaction direction constraint after the debt start time and before the dispute time.

[0037] Specifically, the system first extracts the debt initiation date (e.g., the date of the first loan) and the dispute date (e.g., the date the lawsuit was filed) from the case data, and sets the time period between these two points as the effective time window. The logic behind this setting is that only financial transactions occurring within this time period have the potential to constitute debt repayment. Transfers occurring before the debt initiation date are usually normal economic transactions prior to the debt's creation; while transfers occurring after the dispute date may involve court enforcement payments or other legal actions. Including these in the repayment calculation would lead to confusion. Therefore, by setting a strict time window, a large amount of irrelevant historical transaction data can be effectively excluded, significantly narrowing the scope of data analysis and improving processing efficiency.

[0038] Regarding the retrieval logic for target transaction records, the retrieval of target transaction records that satisfy the time constraints and transaction direction constraints includes: obtaining all transaction data of the third object node after the debt initiation time and before the dispute time; for each obtained transaction data, extracting the transaction type field, the counterparty name field, and the transaction amount field; retrieving transaction data where the transaction type field is a transfer-in type and the counterparty name field matches the name of the second object node; and determining the retrieved transaction data as the target transaction record.

[0039] During the retrieval process, the system performs dual verification on each transaction record. First, it verifies the transaction type, checking the transaction type field and retaining only records with "transfer in" or "income" as the type. This is because a loan repayment on behalf of another inevitably involves funds flowing from the repayer (the third party) to the creditor (the second party). This embodiment uses the creditor's perspective as the benchmark, retrieving records of "transfers in" to directly reflect the creditor's receipt of funds. Second, it verifies the counterparty match, comparing the "counterparty name" or "counterparty account" in the transaction record with the standard name or account of the second party node (the creditor). Specifically, the matching method can include fuzzy name matching and exact account matching. For example, the counterparty name recorded in the transaction log might be "Zhang San," while the creditor's registered name in the case data is "Zhang San (ID number...)." The system can confirm the consistency between the two through name keyword matching. Similarly, if the counterparty account in the transaction log is exactly the same as the receiving account provided by the creditor, it can be directly confirmed as a successful match. This multi-dimensional matching logic can effectively solve the identification difficulties caused by irregular account names and account changes in transaction records.

[0040] Regarding the amount aggregation calculation, the step of performing amount aggregation calculation on the target transaction records to obtain the actual repayment amount includes: summing the amounts of the target transaction records to obtain the actual repayment amount. When performing this step, the system iterates through all retrieved target transaction records and extracts the transaction amount field from each record. Since target transaction records may involve multiple transfers at different times and may originate from different accounts under a third party's name, the system uses a summation algorithm to accumulate all eligible transaction amounts. For example, if the retrieved target transaction records include three records of transfers from third party A to second party within a time window, with amounts of 50,000 yuan, 30,000 yuan, and 20,000 yuan respectively, then the system calculates the actual repayment amount to be 100,000 yuan. This process transforms discrete transaction data into single-generation values ​​that can be used for comparison, providing a data foundation for subsequent automated judgment.

[0041] Regarding the output of early warning data, the system outputs early warning data in response to the claim amount exceeding the difference between the debt amount and the actual repayment amount. The core logic here is to determine whether the claimed amount is inflated. Specifically, the system first calculates the difference between the debt amount and the actual repayment amount, which represents the theoretically remaining outstanding debt. If the claimed amount (i.e., the amount requested in the lawsuit) exceeds this difference, it means that the party may have concealed some repayment facts, resulting in a claim amount higher than the actual debt. For example, if the total debt is 200,000 yuan and the system calculates the actual repayment amount as 100,000 yuan, then the remaining debt should be 100,000 yuan. If the party claims 150,000 yuan, then the condition "claimed amount > (debt amount - actual repayment amount)" is met, the system determines there is suspicion of concealed repayment, and automatically triggers the early warning mechanism.

[0042] To ensure the traceability and evidentiary validity of the warning data when outputting warning data, the warning data includes: debt fact information, including the identity information of the first object node, the identity information of the second object node, the debt amount, and the time information related to the debt; processing link information, including the filtering parameters of the third object node, the search conditions and filtering rules of the target transaction records; a list of supporting transaction data, including the transaction time, transaction amount, transaction type, and counterparty name of each target transaction record; and judgment result data, including the numerical comparison results of the claimed amount, the debt amount, and the actual repayment amount, and risk identification data generated based on the comparison results.

[0043] The debt fact information is used to display the basic lending relationship of the case, providing background support for the early warning data. The processing link information details the system's screening parameters for third-party object nodes, the search conditions and filtering rules for retrieving target transaction records, and the logical path for calculating the difference, enhancing the persuasiveness of the early warning data. The supporting transaction data list specifically details all target transaction records included in the calculation, allowing investigators to directly verify the original evidence. The judgment result data clearly outputs the claimed amount, debt amount, actual repayment amount, and the numerical comparison results of the three, as well as risk identification data generated based on the comparison results. Through the combination of these four elements, the early warning data is not just a simple prompt, but a complete chain of evidence report, directly assisting investigators in subsequent investigation and verification work.

[0044] It should be understood that the aforementioned "exceeding" judgment can be further refined according to business needs in practical applications. For example, to eliminate the impact of calculation errors or minor omissions, the system can set a certain fault tolerance threshold, only outputting warning data when the difference between the claimed amount and the remaining debt exceeds a certain percentage (such as 10%) or a certain absolute value (such as 10,000 yuan). This flexible configuration can effectively reduce the false alarm rate and improve the accuracy of clues.

[0045] Example 3: This example provides supplementary explanations of the pre-processing steps for the method. In practical applications, the raw data acquired by the system often comes from a wide range of sources and has various formats. Directly using this raw data can lead to errors or inefficiencies in subsequent analysis. Therefore, this example uses data cleaning and information extraction techniques to lay a high-quality data foundation for the map construction and constraint setting steps in Examples 1 and 2.

[0046] Specifically, before generating the object relationship graph, the process also includes cleaning and standardizing the acquired multi-source heterogeneous fund transaction data to form a structured transaction database.

[0047] Multi-source heterogeneous fund transaction data refers to transaction records originating from different financial institutions and systems. For example, the export formats of transaction records from different banks often differ significantly; some banks export files in Excel format, some in CSV format, and some even in PDF format. In terms of field naming, some banks use "counterparty name," some use "trading counterparty," and some use "payee name." There are also various date formats, such as "YYYY-MM-DD" and "YYYY / MM / DD." Without standardized processing, the system will be unable to correctly identify the trading counterparty, leading to failed data graph construction or the omission of key nodes.

[0048] The cleaning and standardization process in this step specifically includes: First, the system parses the received raw files, converting unstructured or semi-structured data (such as PDF transaction logs and image-formatted transaction logs) into structured two-dimensional tabular data. Second, the system performs field mapping operations, uniformly mapping heterogeneous field names from different data sources to standard field names according to preset mapping rules. For example, "Counterparty Name," "Trading Partner," and "Payee Name" are uniformly mapped to "Trading Partner Name"; "Transaction Amount," "Transaction Transaction Amount," and "Expenditure / Income Amount" are uniformly mapped to "Transaction Amount." Third, the system performs data cleaning, removing duplicate records, correcting incorrect formats (such as invalid date formats), and filling in missing values ​​(such as inferring transaction types from context). Finally, a structured transaction database with unified fields and standardized formats is formed. This process eliminates the technical barriers caused by differences in data sources, ensuring that subsequent graph construction and transaction screening steps can be performed based on unified data standards, significantly improving the accuracy and robustness of data processing.

[0049] Furthermore, the method in this embodiment also includes: extracting debt information from case documents using an information extraction model, wherein the debt information includes debtor information, debt start time, dispute time, debt amount, and claimed amount.

[0050] Case documents are typically unstructured text data, such as civil judgments, complaints, and answers, which contain a large amount of legal facts described in natural language. Traditional methods rely on manual reading of documents and input of key information, which is inefficient and prone to errors. This step introduces an information extraction model, which can be a Named Entity Recognition (NER) model based on deep learning, or a Natural Language Processing (NLP) model combined with rule templates.

[0051] Specifically, the information extraction model performs semantic analysis and entity extraction on case documents. For example, by identifying keywords such as "plaintiff Zhang San" and "defendant Li Si" and contextual semantics, the model extracts information about the debtor and creditor. By identifying expressions such as "borrowed money on January 1, 2019" and "borrowed RMB 100,000," the model extracts the debt's initiation time and amount. By identifying expressions such as "filed a lawsuit in court on May 1, 2020" and "requested the defendant to repay the principal and interest totaling RMB 120,000," the model extracts the disputed time and claimed amount. It should be understood that the information extraction model can also perform logical verification based on context during the extraction process. For example, when both "borrowed principal" and "owed principal" appear in the document, the model will determine which is the debt amount and which is the current claimed amount based on the context, thereby improving the accuracy of the extraction. Through the above automated extraction process, the system can quickly obtain the key parameters needed to construct the data map and set time constraints from massive amounts of documents, achieving intelligent conversion from unstructured text to structured data, significantly improving the automation level and processing efficiency of clue identification.

[0052] Example 4: This example provides a transaction data processing device based on object relationship graphs. This device corresponds to the transaction data processing method based on object relationship graphs described in Examples 1 to 3 above. It can implement each step in the above method examples and achieve the same technical effect.

[0053] Specifically, the device includes a relationship graph construction module, a transaction retrieval module, and an amount comparison module. The modules interact with each other through a data bus or inter-process communication mechanism.

[0054] The relationship graph construction module is used to generate an object relationship graph and obtain the claimed amount and debt amount from the case data. The object relationship graph includes a first object node, a second object node, and a third object node in the debt relationship. Data nodes and edges represent the association between objects and transactions. Based on the transaction association attributes between candidate nodes and the first object node and the second object node, nodes that meet the preset association conditions are selected from the candidate nodes as the third object node.

[0055] This module serves as the core of the device's data input and preprocessing, with its input end used to acquire external case and transaction data. In its implementation, the relationship graph construction module integrates an entity recognition unit, a graph generation unit, and a node filtering unit. The entity recognition unit uses the Named Entity Recognition (NER) algorithm to extract debtor information from unstructured case documents. The graph generation unit traverses the transaction data, constructing a node-edge relationship structure in adjacency list or graph database format. The output graph structure data includes node IDs, node attributes (such as object name and account information), and edge attributes (such as transaction amount, transaction frequency, and transaction time span). The node filtering unit scores candidate nodes based on transaction relationship attributes (such as transaction frequency, cumulative transaction amount, and relationship type), identifying nodes with scores exceeding a preset threshold as third object nodes. The module's output end transmits the generated object relationship graph data (including the first object node, the second object node, and the filtered third object node) to the transaction retrieval module. It should be understood that this module is not limited to generating static graph structures, but can also be further configured to dynamically update the graph, automatically updating the relationships between nodes when new transaction data is accessed.

[0056] The transaction retrieval module is used to determine time constraints based on the case data and retrieve target transaction records that satisfy the time constraints and transaction direction constraints from the transaction data of the third object node.

[0057] This module receives graph data output from the relationship graph construction module and extracts the debt start time and dispute time from the case data as the benchmark for time constraints. Internally, the transaction retrieval module is configured with a time window determination unit, a data traversal unit, and a rule matching unit. The time window determination unit parses the debt start time and dispute time from the case data to generate time interval parameters; the data traversal unit retrieves the transaction records of all associated accounts under the third object node within the time window based on the account identifier of that node, supporting unified traversal of multi-source heterogeneous transaction data; the rule matching unit performs transaction type verification and counterparty name matching for each record based on preset transaction direction constraints (such as transfer to the second object node), eliminating records that do not meet the conditions, and finally outputting a list of target transaction records. The module's output transmits the retrieved target transaction records (including fields such as transaction time, transaction amount, transaction type, and counterparty name) to the amount comparison module. Through this modular retrieval design, the device can flexibly adjust retrieval rules to adapt to changes in constraints under different case scenarios.

[0058] The amount comparison module is used to perform amount aggregation calculation on the target transaction record to obtain the actual repayment amount, and outputs warning data in response to the claim amount exceeding the difference between the debt amount and the actual repayment amount.

[0059] This module receives target transaction records output by the transaction retrieval module and performs quantitative calculations and logical judgments. Specifically, the amount comparison module is internally configured with a summation calculation unit, a difference judgment unit, and a report generation unit. The summation calculation unit traverses all target transaction records, extracts the transaction amount field, and sums them to obtain the actual repayment amount. The difference judgment unit obtains the claimed amount and debt amount from the case data, calculates the difference between the debt amount and the actual repayment amount, and compares it with the claimed amount. When the claimed amount exceeds the difference, an alert is triggered. The report generation unit assembles an alert data report containing debt fact information, processing link information, a list of supporting transaction data, and judgment result data based on the alert triggering result. This alert data can be output to the case handlers through the device's output interface (such as a display screen, printer, or data transmission interface).

[0060] At the hardware implementation level, the aforementioned modules can be integrated into the same physical device, such as a server or computer terminal. Considering the data processing characteristics of this solution, the hardware configuration can be specifically designed as follows: the memory uses a graph database (such as Neo4j) or a relational database supporting graph indexes to efficiently store and query object relationship graphs; the processor is configured with multi-core parallel computing capabilities to support concurrent retrieval and amount aggregation calculations of massive transaction data; and the communication interface is used for data interaction with external data sources (such as court databases or banking systems). Furthermore, the device can also adopt a distributed architecture, for example, deploying the relationship graph construction module on a cloud server for large-scale data processing, while the amount comparison module is deployed on the terminal device for real-time judgment, with data transmission between modules via a network. This flexibility of hardware architecture allows the device provided in this embodiment to adapt to data processing needs of different scales, from single-machine small-scale case analysis to cluster-based massive data mining.

[0061] Example 5: This example uses a typical debt dispute case to demonstrate the application effect of the method described in this invention in actual business.

[0062] In this case, the first party (the debtor) was accused by the second party (the creditor) of having an outstanding loan principal of RMB 500,000. The system first performed a data preprocessing step: using an information extraction model to perform semantic analysis on the case documents, automatically extracting the debt start time T1 (January 1, 2022), the dispute time T2 (June 1, 2023), the debt amount (RMB 500,000), and the claimed amount (RMB 500,000); at the same time, it cleaned and standardized the multi-source heterogeneous transaction data to form a structured transaction database.

[0063] Subsequently, the system generates an object relationship graph, identifies the first and second object nodes based on case data, and traverses the transaction database to identify their counterparties. The system discovers an individual account named "Wang," which has frequent financial transactions with the first object and has also transferred funds to the second object's account at specific times. Based on transaction association attributes (transaction frequency, cumulative transaction amount), the system filters candidate nodes and identifies "Wang" as a third object node that meets the preset association conditions.

[0064] Furthermore, the system determines a time window based on the debt initiation time T1 and the dispute time T2, and retrieves records of the third object node within this time window where the transaction type is "transfer in" and the counterparty name matches the second object. Two target transaction records are identified (transfer of 100,000 yuan on May 10, 2022 and transfer of 50,000 yuan on August 15, 2022), with an actual repayment amount of 150,000 yuan.

[0065] The system compared the claimed amount (500,000 yuan) with the debt amount (500,000 yuan) and the actual repayment amount (150,000 yuan). The claimed amount exceeded the difference between the debt amount and the actual repayment amount (350,000 yuan), meeting the warning trigger condition. Based on this, the system output a warning data report, including debt fact information, processing link information, a list of supporting transaction data, and judgment result data. Based on this report, analysts quickly identified key clues and confirmed that the third party was entrusted by the first party to make the repayment.

[0066] Example 6: This example provides a computer-readable storage medium storing a computer program. When the computer program is executed by a processor, it implements the transaction data processing method based on object relationship graphs as described in any one of Examples 1 to 3 above.

[0067] The computer-readable storage medium can be a tangible storage medium, including but not limited to disks, optical discs, and semiconductor memories. The computer program stored in this storage medium can be executed by various types of processors. Through the computer-readable storage medium provided in this embodiment, the computer program in the above method embodiments can be stored and distributed in the form of a software product, facilitating deployment and execution on different computing devices, thereby realizing the transaction data processing function based on object relationship graphs.

[0068] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the present invention, such as equivalent adjustments to the map construction algorithm, additions or subtractions of retrieval constraints, or replacements of the hardware implementation of the device module, should be covered within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A transaction data processing method based on object relationship graphs, characterized in that, include: Generate an object relationship graph and obtain the claimed amount and debt amount from the case data. The object relationship graph includes the first object node, the second object node and the third object node in the debt relationship, and uses data nodes and edges to represent the association between objects and transactions. Based on the transaction association attributes between the candidate node and the first object node and the second object node, nodes that meet preset association conditions are selected from the candidate nodes as the third object node. The transaction association attributes include at least one of the following: the transaction frequency between the candidate node and the first object node and the second object node within a preset statistical period; the cumulative transaction amount between the candidate node and the first object node and the second object node. Based on the case data, the debt start time and dispute time are determined as time constraints. Target transaction records that satisfy the time constraints and the transaction direction constraints of transferring to the second object node are retrieved from the transaction data of the third object node. The actual repayment amount is obtained by aggregating and calculating the amount of the target transaction record. In response to the difference between the claimed amount and the difference between the debt amount and the actual repayment amount exceeding a preset fault tolerance threshold, early warning data is output.

2. The method according to claim 1, characterized in that, The generation of the object relationship graph includes: generating the object relationship graph based on the case data and transaction data.

3. The method according to claim 1, characterized in that, The transaction association attribute further includes: the association relationship type between the candidate node and the first object node and the second object node, wherein the association relationship type includes at least one of the transaction relationship type and the social relationship type.

4. The method according to claim 1, characterized in that, The target transaction records that satisfy the time constraint and transaction direction constraint include: Obtain all transaction data of the third object node after the debt initiation time and before the dispute time; for each obtained transaction data, extract the transaction type field, counterparty name field, and transaction amount field; retrieve transaction data where the transaction type field is "transfer-in" and the counterparty name field matches the name of the second object node; determine the retrieved transaction data as the target transaction record; perform amount aggregation calculation on the target transaction record to obtain the actual repayment amount, including: summing the amounts of the target transaction records to obtain the actual repayment amount.

5. The method according to claim 1, characterized in that, The early warning data includes: debt fact information, including the identity information of the first object node, the identity information of the second object node, the debt amount, and the time information related to the debt; processing link information, including the filtering parameters of the third object node, the search conditions and filtering rules of the target transaction records; a list of supporting transaction data, including the transaction time, transaction amount, transaction type, and counterparty name of each target transaction record; and judgment result data, including the numerical comparison results of the claimed amount, the debt amount, and the actual repayment amount, and risk identification data generated based on the comparison results.

6. The method according to claim 1, characterized in that, Before generating the object relationship graph, the process also includes cleaning and standardizing the acquired multi-source heterogeneous fund transaction data to form a structured transaction database.

7. The method according to claim 1, characterized in that, Also includes: The information extraction model is used to extract debt information from case documents. The debt information includes information about the debtor, the debt start time, the time of the dispute, the amount of the debt, and the amount claimed.

8. A transaction data processing device based on object relationship graphs, characterized in that, include: A relationship graph construction module is used to generate an object relationship graph and obtain the claimed amount and debt amount from case data. The object relationship graph includes a first object node, a second object node, and a third object node in the debt relationship. Data nodes and edges represent the association between objects and transactions. Based on the transaction association attributes between candidate nodes and the first and second object nodes, nodes that meet preset association conditions are selected from the candidate nodes as the third object node. The transaction association attributes include at least one of the following: the transaction frequency of the candidate node with the first object node and the second object node within a preset statistical period; the cumulative transaction amount between the candidate node and the first and second object nodes. The transaction retrieval module is used to determine the debt start time and dispute time as time constraints based on the case data, and to retrieve target transaction records from the transaction data of the third object node that satisfy the time constraints and the transaction direction constraints of transferring to the second object node. The amount comparison module is used to perform amount aggregation calculation on the target transaction record to obtain the actual repayment amount. In response to the difference between the claimed amount and the difference between the debt amount and the actual repayment amount exceeding a preset fault tolerance threshold, the module outputs warning data.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the method as described in any one of claims 1 to 7.

Images