A knowledge graph-based financial business correlation risk identification method and system

Abstract

This invention discloses a method and system for identifying associated risks in financial transactions based on knowledge graphs, relating to the field of financial technology. It includes a business graph construction module for receiving financing application data, basic transaction data, payment confirmation data, historical financing data, basic debt reduction data, and financing occupation release data, and constructing a financial business knowledge graph containing financing application nodes, transaction voucher nodes, payment obligation nodes, and financing occupation nodes. A basic debt unit generation module is used to generate basic debt units based on the payer, payee, purchase order, acceptance batch, and payment due date. This invention projects financing applications from the invoice layer to the underlying basic debt units and determines whether the current financing application results in the duplicate occupation of the same basic debt unit based on the capacity, occupied amount, and remaining available amount of the basic debt unit.

Description

Technical Field

[0001] This invention relates to the field of financial technology, specifically to a method and system for identifying associated risks in financial transactions based on knowledge graphs. Background Technology

[0002] In supply chain finance, accounts receivable financing, and invoice financing, financial institutions typically need to perform correlation analysis on the business relationships between the applicant, payer, transaction documents, and financing records based on financing applications, underlying transaction documents, payment confirmation records, historical loan disbursement records, and repayment records. Knowledge graphs can organize enterprise entities, transaction documents, payment obligations, financing applications, and repayment records into nodes and edge relationships, enabling financial business systems to complete financing application verification, historical business correlation queries, and risk identification result output within a unified data structure.

[0003] Existing knowledge graph-based financial business risk identification methods typically rely on invoice numbers, contract numbers, corporate relationships, document text similarity, and graph adjacency relationships as the main criteria. However, in scenarios where a financing applicant splits the same underlying receivable into multiple invoices, changes document fields, or submits financing applications in batches across different financial institutions, these multiple financing applications appear as different business objects at the document level. This makes it difficult for the system to determine whether these applications collectively consume the underlying payment obligations formed by the same payer in the same performance batch, thus making it difficult to identify the financial business association risk of "non-duplicated documents but duplicated underlying receivables" in a timely manner. Summary of the Invention

[0004] The purpose of this invention is to provide a method and system for identifying financial business-related risks based on knowledge graphs, so as to solve the problems mentioned in the background art.

[0005] To address the aforementioned technical problems, this invention provides the following technical solution: a method and system for identifying financial business association risks based on a knowledge graph, comprising: a business graph construction module, used to receive financing application data, basic transaction data, payment confirmation data, historical financing data, basic debt reduction data, and financing occupation release data, and construct a financial business knowledge graph including financing application nodes, transaction voucher nodes, payment obligation nodes, and financing occupation nodes; a basic debt unit generation module, used to generate basic debt units based on the payer, payee, purchase order, acceptance batch, and payment due date, enabling different transaction vouchers corresponding to the same underlying payment obligation to be aggregated into the same basic debt unit; and a duplicate occupation identification module, used to map the current financing application to the corresponding basic debt unit, and output a duplicate occupation risk identification result including risk identifier, excess occupation amount, and associated historical financing records based on the effective debt capacity, historical financing occupation amount, and current financing application amount of the basic debt unit.

[0006] According to the above technical solution, the business graph construction module includes a data access submodule, a field standardization submodule, and a relationship writing submodule. The data access submodule is used to receive financing application data, basic transaction data, payment confirmation data, historical financing data, basic debt reduction data, and financing occupation release data. The field standardization submodule is used to unify the data format of the payer, payee, purchase order, acceptance batch, payment due date, and amount fields. The relationship writing submodule is used to write the association relationships between financing application nodes and transaction voucher nodes, transaction voucher nodes and payment obligation nodes, and payment obligation nodes and financing occupation nodes in the financial business knowledge graph. The basic debt unit generation module includes an anchor field determination submodule, a unit aggregation submodule, and a capacity generation submodule. The anchor field determination submodule is used to determine the payer, payee, purchase order, acceptance batch, and payment due date as the anchor fields for generating basic debt units. The unit aggregation submodule is used to aggregate payment obligation nodes with consistent anchor fields into the same basic debt unit. The capacity generation submodule is used to generate the effective debt capacity of the basic debt unit based on the order's effective amount, acceptance confirmation amount, payment confirmation amount, and the reduction amount of basic debt. The effective debt capacity is the amount that the basic debt unit can be used by financing applications after deducting the reduction amount of basic debt. The duplicate occupancy identification module includes an application mapping submodule, an occupancy verification submodule, and a result output submodule. The application mapping submodule is used to map the current financing application to the corresponding basic debt unit. The occupancy verification submodule is used to compare the current financing application amount with the remaining available amount of the basic debt unit. The result output submodule is used to output the duplicate occupancy risk identifier, the excess occupancy amount, and the associated historical financing records.

[0007] A knowledge graph-based method for identifying associated risks in financial transactions includes the following steps: S1. Construct a financial business knowledge graph. The system receives financing application data, basic transaction data, payment confirmation data, historical financing data, basic debt reduction data, and financing occupation release data. It standardizes the subject field, voucher field, payment obligation field, and amount field. After processing, the system writes the financing application, transaction voucher, payment obligation, and historical financing occupation into the same financial business knowledge graph, so that business data from different sources can be queried and associated in the same graph structure. S2, Generate basic debt unit. The system does not use invoices as the sole identification object, but determines the underlying payment obligation based on the payer, payee, purchase order, acceptance batch and payment due date. For multiple transaction vouchers pointing to the same underlying payment obligation, the system aggregates them into the same basic debt unit and records the effective debt capacity that the financing application can occupy in the basic debt unit. S3, Mapping the current financing application: The system reads the payer, payee, purchase order, acceptance batch, payment due date standard value and application amount from the current financing application, and maps the current financing application to the corresponding basic debt unit. This mapping process does not use whether the current invoice is the same as the historical invoice as a judgment condition, but rather judges whether the current financing application points to an existing underlying payment obligation. S4. Identify the risk of duplicate occupancy. The system queries the historical financing occupancy records and repayment release records corresponding to the basic debt unit to obtain the remaining available amount of the basic debt unit. The system compares the current financing application amount with the remaining available amount and identifies the risk of duplicate occupancy of the basic debt when the current financing application amount exceeds the remaining available amount. S5, Output Risk Identification Results. The system outputs the underlying debt unit corresponding to the current financing application, historical financing occupancy records, remaining available occupancy amount, excess occupancy amount, and risk indicator. This output result is used to indicate that although the current financing application is not directly duplicated with the historical application at the certificate level, it has caused duplicate occupancy of the same underlying debt at the underlying debt level.

[0008] According to the above technical solution, step S1 includes the following steps: S1-1, to ensure that different invoices, contract attachments, and financing applications can all be traced back to the same underlying payment obligation, the system does not use the invoice number as the sole identification criterion. Instead, it uses the payer's identification code, payee's identification code, purchase order identification code, acceptance batch identification code, and payment due date as common defining fields for each payment obligation confirmation record. Extract the payer's identification code Recipient identification code Purchase order identification code Acceptance batch identification code and payment due date standard value The payment obligation confirmation record is generated using the following formula. Corresponding basic claim identification code ,in, For a payment obligation confirmation record, Confirmation record of the aforementioned payment obligation The payer identification code in the middle, Confirmation record of the aforementioned payment obligation The recipient's identification code in the payment information. Confirmation record of the aforementioned payment obligation Purchase order identification code in Confirmation record of the aforementioned payment obligation The acceptance batch identification code in the middle, Confirmation record of the aforementioned payment obligation Standard value for payment due date in the payment terms. The system uses a pre-defined fixed encoding function. This function concatenates, normalizes, and encodes fields according to a fixed order: payer identification code, payee identification code, purchase order identification code, acceptance batch identification code, and payment due date. This generates a unique basic debt identification code. , This is the basic receivable identification code, jointly determined by the payer identification code, payee identification code, purchase order identification code, acceptance batch identification code, and payment due date standard value. This formula is used to fix payment obligations arising under the same payer, payee, purchase order, acceptance batch, and payment due date standard value as the same identification object. The payment due date standard value is a standardized date value obtained by the system based on the payment due date in the payment confirmation data. When the payment due date in the transaction document is inconsistent with the payment due date in the payment confirmation data, the payment due date in the payment confirmation data is used as the payment due date standard value. S1-2, after obtaining the basic debt identification code Subsequently, the system uses this identification code as the basis for aggregation at the payment obligation level, allowing records that differ at the document level but share the same underlying payment obligation to be grouped into the same basic claim unit, and assigning the basic claim identification code... Records of the same payment obligation are grouped into the same basic debt unit, and a pointing relationship between the basic debt unit and the transaction voucher node is established in the financial business knowledge graph; S1-3 connects the historical financing application node with its corresponding basic debt unit, and writes the loan disbursement status, repayment status and release status of the historical financing application into the financing occupation node, so that subsequent steps can query the historical occupation status based on the same basic debt unit.

[0009] According to the above technical solution, step S2 includes the following steps: S2-1, to prevent any single voucher amount from being artificially inflated and directly creating financing capacity, the system uses the valid amount of the purchase order, the acceptance confirmation amount, and the payment confirmation amount as the three constraint amounts for the same basic debt unit, and uses the smallest of the three constraint amounts as the debt ceiling before deductions; based on this debt ceiling, the system deducts the amount that has already reduced the basic debt amount to obtain the effective debt capacity of the basic debt unit. ,in, This serves as the basic claim identification code for a basic claim unit. The effective amount of the purchase order corresponding to this basic debt unit. This is the acceptance confirmation amount corresponding to the basic debt unit. This is the amount of payment confirmation corresponding to the underlying debt unit. This refers to the amount by which the amount of the underlying claim decreases due to buyer payments, credit adjustments, or write-offs within the underlying claim unit. This represents the effective claim capacity of the basic claim unit; The function is used when the deduction result is less than The effective debt capacity will be determined as follows: , The function is used to select the lowest amount among the valid purchase order amount, the acceptance confirmation amount, and the payment confirmation amount as the upper limit of the receivables capacity; the formula is used to use the lowest amount among the purchase order, acceptance confirmation, and payment confirmation as the upper limit of the financeable receivables, and deduct the amount that has already reduced the amount of the underlying receivables, so as to avoid the amount of a single document being artificially inflated and directly used as the financeable capacity. S2-2, effective debt capacity Write the capacity field of the underlying claim unit and match the capacity field with the underlying claim identification code. Binding ensures that subsequent financing applications can only be verified within the effective claim capacity of the underlying claim unit. S2-3, When multiple transaction certificates point to the same underlying debt identification code At that time, the system will only use the multiple transaction vouchers as sources of evidence to prove the existence of the same underlying debt unit, and will not add the amounts of the multiple transaction vouchers to form a new debt capacity, but will continue to use the effective debt capacity. This serves as a unified upper limit for the use of the underlying debt unit, thereby preventing financing applicants from amplifying the financing amount of the same underlying payment obligation by splitting invoices and issuing vouchers in batches.

[0010] According to the above technical solution, step S3 includes the following steps: S3-1, in the current financing application Upon entering the system, the system processes the current financing application according to the same field order and coding rules as the payment obligation confirmation record, ensuring that the current financing application is mapped to the corresponding underlying debt unit, rather than simply comparing it with historical invoice numbers. The system then processes the current financing application. Extract the payer's identification code Recipient identification code Purchase order identification code Acceptance batch identification code and payment due date standard value The current financing application can be obtained using the following formula. Corresponding basic claim identification code ,in, For the current financing application, For the current financing application The payer identification code in the middle, For the current financing application The recipient's identification code in the payment information. For the current financing application Purchase order identification code in For the current financing application The acceptance batch identification code in the middle, For the current financing application Standard value for payment due date in the payment terms. For the current financing application The underlying debt identification code obtained through mapping; the significance of this formula is to enable the current financing application to enter the corresponding underlying debt unit based on the underlying payment obligation, rather than directly judging whether it is a duplicate based on the invoice number; S3-2, Query the basic debt identification code in the financial business knowledge graph. The basic debt unit, and the current financing application A mapping relationship is established with the basic claim unit for the occupancy verification in step S4. If the basic claim identification code does not exist in the financial business knowledge graph... When identifying the underlying debt unit, the system generates a missing underlying debt identifier and updates the current financing application. The application is sent to the manual verification process, and the subsequent verification of remaining available funds is not performed. The missing basic claim is identified as the current financing application. Mapping result fields , This indicates that the basic debt identification code does not exist in the financial business knowledge graph. The corresponding basic debt unit, This indicates that a basic debt identification code exists in the financial business knowledge graph. The corresponding basic debt unit; S3-3, Read the current financing application The amount of financing applied for and the amount of financing applied for As the current financing application The amount to be used for this underlying debt unit, of which For the current financing application The principal amount of financing requested from a financial institution.

[0011] According to the above technical solution, step S4 includes the following steps: S4-1, in the current financing application It has been mapped to the underlying debt identification code. Afterwards, the system retrieved the underlying debt identification code as follows: The set of historical financing records corresponding to the basic debt unit The historical financing amount of the underlying debt unit is calculated using the principal amount already disbursed in the historical financing records as the source of occupied funds, and the financing repayment amount and financing cancellation amount in the historical financing records as the source of occupied funds release. ,in, For the current financing application The underlying debt identification code obtained by mapping The corresponding set of historical financing records, A collection of historical financing records One of the historical financing records, Historical financing records The amount of principal already disbursed. Historical financing records The amount of financing already released due to loan repayments and loan cancellations. For the current financing application The historical financing amount occupied by the corresponding underlying debt unit; the significance of this formula is to recognize the historical financing amount that has been disbursed but not yet released as the actual occupation of the same underlying debt unit; S4-2, after obtaining the effective debt capacity and historical financing usage The system then calculates the difference between the two to determine the current financing application. The remaining usable claim space within the same basic claim unit is calculated as follows: ,in, For the current financing application Mapped to the underlying debt identification code Afterwards, the remaining portion of the underlying debt unit can be used by the current financing application. The amount used; The function is used to determine the remaining available amount when the historical financing amount exceeds the effective debt capacity. To avoid negative values ​​in the remaining available capacity; this formula is used to calculate the effective debt capacity. Excluding historical financing usage This allows for the acquisition of basic debt reserves that can still be used for current financing applications; S4-3, after obtaining the remaining available quantity Then, the system will process the current financing application. The amount of financing applied for With remaining available quantity The amounts are compared, and the portion exceeding the remaining available space is determined as the excess amount. ,in, For the current financing application Relative to the remaining available amount The resulting excess amount; the significance of this formula lies in when the applied financing amount Exceeding the remaining available space In such cases, the excess amount will be recognized as the amount repeatedly used for the same underlying claim; S4-4, When the excess amount is used Greater than At that time, the system generates a risk indicator for repeated use of the underlying debt and records the amount of excess use. Write into the current financing application The risk field, and the system will include the current financing application. Corresponding risk indicator of repeated use of underlying claims The value is set to 1; when the excess amount is used... equal At that time, the system will not generate a risk indicator for repeated use of underlying debt, and will update the current financing application. The occupancy verification result is written into the financial business knowledge graph, and the system will record the current financing application. Corresponding risk indicator of repeated use of underlying claims The value is determined to be 0. The occupancy verification result includes the current financing application f and the basic debt identification code. Effective debt capacity Historical financing usage Remaining available space Requested financing amount Excess amount Risk markers for repeated use of underlying debt .

[0012] According to the above technical solution, step S5 includes the following steps: S5-1, when At that time, the system output includes the current financing application. Basic debt identification code and the lack of identification of underlying claims The missing verification result will be entered into the financial business knowledge graph and linked to the current financing application. Corresponding risk outcome nodes; S5-2, when To ensure that the risk identification results can be reviewed by business auditors, the system not only outputs a duplicate occupancy risk indicator, but also writes the current financing application, basic debt identification code, historical financing record set, effective debt capacity, historical financing occupancy amount, remaining available occupancy amount, applied financing amount, and excess occupancy amount into the risk result field set. ,in, For the current financing application The corresponding risk outcome field set, For the current financing application, For the current financing application The corresponding basic claim identification code, Basic debt identification code The corresponding set of historical financing records, This represents the effective claim capacity of the basic claim unit. This represents the historical financing amount used by the underlying debt unit. For the current financing application The corresponding remaining available quantity, For the current financing application The amount of financing applied for, For the current financing application The amount of excess occupation; the significance of this formula is that the risk output includes not only the risk conclusion, but also the underlying debt unit, historical occupation records and amount verification results on which the conclusion is based; S5-3, the system bases the risk outcome field set Generate a chain of related evidence, which is based on the current financing application. Basic debt identification code Collection of historical financing records Effective debt capacity Historical financing usage Remaining available space Requested financing amount and excess amount The sequential display allows auditors to review the formation process of the risk of duplicate occupation along the same basic debt unit; S5-4, The system writes the relevant evidence chain into the financial business knowledge graph and links it to the current financing application. The corresponding risk result node is output to the financial business review end to identify the risk of duplicate use, so that the current financing application and its corresponding basic debt unit, historical use record and amount verification result form a traceable graph path.

[0013] Compared with existing technologies, the beneficial effects achieved by this invention are as follows: This invention generates basic debt units based on the payer, payee, purchase order, acceptance batch, and payment due date specifications. It maps historical and current financing applications to the same underlying payment obligation object, and then verifies the basic debt unit based on its effective debt capacity, historical financing usage, and current application usage. Therefore, even if financing applicants circumvent conventional deduplication checks by splitting invoices, adjusting voucher fields, submitting across platforms, or applying in batches, the system can still identify the risk of multiple financing applications jointly occupying the same basic debt and output verifiable results including the current application, basic debt unit, historical usage records, and excess usage amount. This improves the accuracy, interpretability, and business traceability of supply chain finance-related risk identification. Attached Figure Description

[0014] The accompanying drawings are provided to further illustrate the invention and form part of the specification. They are used in conjunction with embodiments of the invention to explain the invention and do not constitute a limitation thereof. In the drawings: Figure 1 This is a flowchart illustrating the present invention; Figure 2 This is a schematic diagram of the overall modular structure of the present invention. Detailed Implementation

[0015] 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, and 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.

[0016] Please see Figure 1 and Figure 2This invention provides a technical solution: a method and system for identifying financial business association risks based on a knowledge graph, comprising: a business graph construction module, used to receive financing application data, basic transaction data, payment confirmation data, historical financing data, basic debt reduction data, and financing occupation release data, and construct a financial business knowledge graph including financing application nodes, transaction voucher nodes, payment obligation nodes, and financing occupation nodes; a basic debt unit generation module, used to generate basic debt units based on the payer, payee, purchase order, acceptance batch, and payment due date, so that different transaction vouchers corresponding to the same underlying payment obligation can be aggregated into the same basic debt unit; and a duplicate occupation identification module, used to map the current financing application to the corresponding basic debt unit, and output a duplicate occupation risk identification result including risk identifier, excess occupation amount, and associated historical financing records based on the effective debt capacity, historical financing occupation amount, and current financing application amount of the basic debt unit. The business graph construction module includes a data access submodule, a field standardization submodule, and a relationship writing submodule. The data access submodule is used to receive financing application data, basic transaction data, payment confirmation data, historical financing data, basic debt reduction data, and financing occupation release data. The field standardization submodule is used to standardize the data format of the payer, payee, purchase order, acceptance batch, payment due date, and amount fields. The relationship writing submodule is used to write the association relationships between financing application nodes and transaction voucher nodes, transaction voucher nodes and payment obligation nodes, and payment obligation nodes and financing occupation nodes in the financial business knowledge graph. The basic debt unit generation module includes an anchor field determination submodule, a unit aggregation submodule, and a capacity generation submodule. The anchor field determination submodule is used to determine the payer, payee, purchase order, acceptance batch, and payment due date as the anchor fields for generating basic debt units. The unit aggregation submodule is used to aggregate payment obligation nodes with consistent anchor fields into the same basic debt unit. The capacity generation submodule is used to generate the effective debt capacity of the basic debt unit based on the order's effective amount, acceptance confirmation amount, payment confirmation amount, and the reduction amount of the basic debt. The effective debt capacity is the amount that the basic debt unit can be used by the financing application after deducting the reduction amount of the basic debt. The duplicate occupancy identification module includes an application mapping submodule, an occupancy verification submodule, and a result output submodule. The application mapping submodule is used to map the current financing application to the corresponding underlying debt unit. The occupancy verification submodule is used to compare the current financing application amount with the remaining available amount of the underlying debt unit. The result output submodule is used to output the duplicate occupancy risk indicator, the amount of excess occupancy, and the associated historical financing records. A knowledge graph-based method for identifying associated risks in financial transactions includes the following steps: S1. Construct a financial business knowledge graph. The system receives financing application data, basic transaction data, payment confirmation data, historical financing data, basic debt reduction data, and financing occupation release data. It standardizes the subject field, voucher field, payment obligation field, and amount field. After processing, the system writes the financing application, transaction voucher, payment obligation, and historical financing occupation into the same financial business knowledge graph, so that business data from different sources can be queried and associated in the same graph structure. S2, Generate basic debt unit. The system does not use invoices as the sole identification object, but determines the underlying payment obligation based on the payer, payee, purchase order, acceptance batch and payment due date. For multiple transaction vouchers pointing to the same underlying payment obligation, the system aggregates them into the same basic debt unit and records the effective debt capacity that the financing application can occupy in the basic debt unit. S3, Mapping the current financing application: The system reads the payer, payee, purchase order, acceptance batch, payment due date standard value and application amount from the current financing application, and maps the current financing application to the corresponding basic debt unit. This mapping process does not use whether the current invoice is the same as the historical invoice as a judgment condition, but rather judges whether the current financing application points to an existing underlying payment obligation. S4. Identify the risk of duplicate occupancy. The system queries the historical financing occupancy records and repayment release records corresponding to the basic debt unit to obtain the remaining available amount of the basic debt unit. The system compares the current financing application amount with the remaining available amount and identifies the risk of duplicate occupancy of the basic debt when the current financing application amount exceeds the remaining available amount. S5, Output Risk Identification Results. The system outputs the basic debt unit corresponding to the current financing application, historical financing occupancy records, remaining available occupancy amount, excess occupancy amount, and risk indicator. This output result is used to indicate that although the current financing application does not directly duplicate the historical application at the certificate level, it has caused duplicate occupancy of the same basic debt at the underlying debt level. Step S1 includes the following steps: S1-1, to ensure that different invoices, contract attachments, and financing applications can all be traced back to the same underlying payment obligation, the system does not use the invoice number as the sole identification criterion. Instead, it uses the payer's identification code, payee's identification code, purchase order identification code, acceptance batch identification code, and payment due date as common defining fields for each payment obligation confirmation record. Extract the payer's identification code Recipient identification code Purchase order identification code Acceptance batch identification code and payment due date standard value And generate a payment obligation confirmation record using the following formula. Corresponding basic claim identification code ,in, For a payment obligation confirmation record, Confirmation of payment obligations The payer identification code in the middle, Confirmation of payment obligations The recipient's identification code in the payment information. Confirmation of payment obligations Purchase order identification code in Confirmation of payment obligations The acceptance batch identification code in the middle, Confirmation of payment obligations Standard value for payment due date in the payment terms. The system uses a pre-defined fixed encoding function. This function concatenates, normalizes, and encodes fields according to a fixed order: payer identification code, payee identification code, purchase order identification code, acceptance batch identification code, and payment due date. This generates a unique basic debt identification code. , This is the basic receivable identification code, jointly determined by the payer identification code, payee identification code, purchase order identification code, acceptance batch identification code, and payment due date standard value. This formula is used to fix payment obligations arising under the same payer, payee, purchase order, acceptance batch, and payment due date standard value as the same identification object. The payment due date standard value is a standardized date value obtained by the system based on the payment due date in the payment confirmation data. When the payment due date in the transaction document is inconsistent with the payment due date in the payment confirmation data, the payment due date in the payment confirmation data is used as the payment due date standard value. S1-2, after obtaining the basic debt identification code Subsequently, the system uses this identification code as the basis for aggregation at the payment obligation level, allowing records that differ at the document level but share the same underlying payment obligation to be grouped into the same basic claim unit, and assigning the basic claim identification code... Records of the same payment obligation are grouped into the same basic debt unit, and a pointing relationship between the basic debt unit and the transaction voucher node is established in the financial business knowledge graph; S1-3, connect the historical financing application node with its corresponding basic debt unit, and write the loan disbursement status, repayment status and release status of the historical financing application into the financing occupation node, so that subsequent steps can query the historical occupation status based on the same basic debt unit; In this step, the financial business knowledge graph is not simply used to store the superficial relationships between enterprises, invoices, and financing applications, but rather to establish the correspondence between the voucher layer and the payment obligation layer. Conventional risk identification typically prioritizes observing whether invoice numbers, contract numbers, applicant entities, and historical application records are identical. However, in accounts receivable financing scenarios, financing applicants may split invoices, adjust voucher remarks, or change application batches, causing the same underlying payment obligation to appear as multiple different objects at the voucher layer. Therefore, the key role of this step is to first place financing applications, transaction vouchers, payment obligations, and historical financing usage into the same graph structure, enabling subsequent steps to bypass the superficial differences in vouchers and directly track whether these vouchers collectively point to the same underlying payment obligation. Its originality lies not in simply constructing a knowledge graph, but in shifting the graph's association center from invoice objects to payment obligation objects, providing a data foundation for subsequently identifying the risk of duplicate usage of different vouchers but the same underlying receivable.

[0017] Step S2 includes the following steps: S2-1, to prevent any single voucher amount from being artificially inflated and directly creating financing capacity, the system uses the valid amount of the purchase order, the acceptance confirmation amount, and the payment confirmation amount as the three constraint amounts for the same basic debt unit, and uses the smallest of the three constraint amounts as the debt ceiling before deductions; based on this debt ceiling, the system deducts the amount that has already reduced the basic debt amount to obtain the effective debt capacity of the basic debt unit. ,in, This serves as the basic claim identification code for a basic claim unit. The effective amount of the purchase order corresponding to this basic debt unit. This is the acceptance confirmation amount corresponding to the basic debt unit. This is the amount of payment confirmation corresponding to the underlying debt unit. This refers to the amount by which the amount of the underlying claim decreases due to buyer payments, credit adjustments, or write-offs within the underlying claim unit. This represents the effective claim capacity of the basic claim unit; The function is used when the deduction result is less than The effective debt capacity will be determined as follows: , The function is used to select the lowest amount among the valid purchase order amount, the acceptance confirmation amount, and the payment confirmation amount as the upper limit of the receivables capacity; the formula is used to use the lowest amount among the purchase order, acceptance confirmation, and payment confirmation as the upper limit of the financeable receivables, and deduct the amount that has already reduced the amount of the underlying receivables, so as to avoid the amount of a single document being artificially inflated and directly used as the financeable capacity. S2-2, effective debt capacity Write the capacity field of the underlying claim unit and match the capacity field with the underlying claim identification code. Binding ensures that subsequent financing applications can only be verified within the effective claim capacity of the underlying claim unit. S2-3, When multiple transaction certificates point to the same underlying debt identification code At that time, the system will only use the multiple transaction vouchers as sources of evidence to prove the existence of the same underlying debt unit, and will not add the amounts of the multiple transaction vouchers to form a new debt capacity, but will continue to use the effective debt capacity. This serves as a unified upper limit for the use of the underlying debt unit, thereby preventing financing applicants from amplifying the financing amount of the same underlying payment obligation by splitting invoices and issuing vouchers in batches. This step is the core step that distinguishes this invention from conventional invoice deduplication schemes. For accounts receivable formed under the same purchase order, the same acceptance batch, and the same payment confirmation relationship, although there may be multiple invoices, multiple attachments, and multiple financing applications in the business system, these documents do not naturally increase the actual payment obligations borne by the buyer. This step aggregates these documents into the same basic debt unit and uses the underlying transaction, acceptance confirmation, and payment confirmation to jointly limit the scope of the basic debt unit that can be used by financing applications. After this processing, the invoice is no longer the sole object for judging duplicate financing, but only a source of evidence proving the existence of the underlying debt; the system is really concerned with whether the same underlying debt has been used by financing applications. Compared with the conventional technology of directly comparing invoice numbers, invoice amounts, or text similarity, this step aggregates from the capacity boundary of the underlying payment obligation, which can prevent applicants from amplifying the financing amount by splitting invoices, issuing invoices in batches, or changing the form of documents.

[0018] Step S3 includes the following steps: S3-1, in the current financing application Upon entering the system, the system processes the current financing application according to the same field order and coding rules as the payment obligation confirmation record, ensuring that the current financing application is mapped to the corresponding underlying debt unit, rather than simply comparing it with historical invoice numbers. The system then processes the current financing application. Extract the payer's identification code Recipient identification code Purchase order identification code Acceptance batch identification code and payment due date standard value The current financing application can be obtained using the following formula. Corresponding basic claim identification code ,in, For the current financing application, For the current financing application The payer identification code in the middle, For the current financing application The recipient's identification code in the payment information. For the current financing application Purchase order identification code in For the current financing application The acceptance batch identification code in the middle, For the current financing application Standard value for payment due date in the payment terms. For the current financing application The underlying debt identification code obtained through mapping; the significance of this formula is to enable the current financing application to enter the corresponding underlying debt unit based on the underlying payment obligation, rather than directly judging whether it is a duplicate based on the invoice number; S3-2, Query the basic debt identification code in the financial business knowledge graph. The basic debt unit, and the current financing application A mapping relationship is established with the basic claim unit for the occupancy verification in step S4. If the basic claim identification code does not exist in the financial business knowledge graph... When identifying the underlying debt unit, the system generates a missing underlying debt identifier and updates the current financing application. The application is sent to the manual verification process, but the remaining available amount is not verified. The application is marked as having missing underlying debt. Mapping result fields , This indicates that the basic debt identification code does not exist in the financial business knowledge graph. The corresponding basic debt unit, This indicates that a basic debt identification code exists in the financial business knowledge graph. The corresponding basic debt unit; S3-3, Read the current financing application The amount of financing applied for and the amount of financing applied for As the current financing application The amount to be used for this underlying debt unit, of which For the current financing application The principal amount of financing requested from a financial institution; This step works by tracing the current financing application from the document level back to the underlying payment obligation level. Conventional methods often compare the invoices in the current financing application with historical invoices for similarity, but this only identifies document-level duplications and struggles to handle situations where invoices are split, have changed attachments, or are submitted across different institutions. This step doesn't focus on whether the current invoice matches historical invoices; instead, it determines whether the current financing application can be placed within an existing underlying debt unit. If it can, it indicates a shared underlying payment obligation between the current application and historical transactions, requiring further capacity verification. If it cannot, it means the current application lacks a supporting underlying debt unit, and the system transfers it to manual verification instead of continuing to calculate remaining available capacity. This branch design avoids two types of misjudgments: mistaking applications with different documents but the same underlying debt for irrelevant applications, and forcibly including applications lacking supporting underlying debt into the normal capacity verification process.

[0019] S4 includes the following steps: S4-1, in the current financing application It has been mapped to the underlying debt identification code. Afterwards, the system retrieved the underlying debt identification code as follows: The set of historical financing records corresponding to the basic debt unit The historical financing amount of the underlying debt unit is calculated using the principal amount already disbursed in the historical financing records as the source of occupied funds, and the financing repayment amount and financing cancellation amount in the historical financing records as the source of occupied funds release. ,in, For the current financing application The underlying debt identification code obtained by mapping The corresponding set of historical financing records, A collection of historical financing records One of the historical financing records, Historical financing records The amount of principal already disbursed. Historical financing records The amount of financing already released due to loan repayments and loan cancellations. For the current financing application The historical financing amount occupied by the corresponding underlying debt unit; the significance of this formula is to recognize the historical financing amount that has been disbursed but not yet released as the actual occupation of the same underlying debt unit; S4-2, after obtaining the effective debt capacity and historical financing usage The system then calculates the difference between the two to determine the current financing application. The remaining usable claim space within the same basic claim unit is calculated as follows: ,in, For the current financing application Mapped to the underlying debt identification code Afterwards, the remaining portion of the underlying debt unit can be used by the current financing application. The amount used; The function is used to determine the remaining available amount when the historical financing amount exceeds the effective debt capacity. To avoid negative values ​​in the remaining available capacity; this formula is used to calculate the effective debt capacity. Excluding historical financing usage This allows for the acquisition of basic debt reserves that can still be used for current financing applications; S4-3, after obtaining the remaining available quantity Then, the system will process the current financing application. The amount of financing applied for With remaining available quantity The amounts are compared, and the portion exceeding the remaining available space is determined as the excess amount. ,in, For the current financing application Relative to the remaining available amount The resulting excess amount; the significance of this formula lies in when the applied financing amount Exceeding the remaining available space In such cases, the excess amount will be recognized as the amount repeatedly used for the same underlying claim; S4-4, When the excess amount is used Greater than At that time, the system generates a risk indicator for repeated use of the underlying debt and records the amount of excess use. Write into the current financing application The risk field, and the system will include the current financing application. Corresponding risk indicator of repeated use of underlying claims The value is set to 1; when the excess amount is used... equal At that time, the system will not generate a risk indicator for repeated use of underlying debt, and will update the current financing application. The occupancy verification result is written into the financial business knowledge graph, and the system will record the current financing application. Corresponding risk indicator of repeated use of underlying claims The value is determined to be 0. The verification result includes the current financing application f and the underlying debt identification code. Effective debt capacity Historical financing usage Remaining available space Requested financing amount Excess amount Risk markers for repeated use of underlying debt ; This step is the direct judgment step for identifying the risk of duplicate occupancy. After identifying the underlying debt unit corresponding to the current financing application, the system no longer judges whether the current document is similar to historical documents, but instead checks how much of the underlying debt unit has been occupied by historical financing and how much remains to support the current application. In other words, this step transforms the problem of duplicate financing into the problem of occupying the same underlying debt space: if the amount required by the current application exceeds the remaining capacity of the underlying debt unit, it means that although the current application may differ from historical applications in terms of invoices, attachments, or application batches, it has already consumed the same payment obligation at the underlying debt level as historical financing. Compared with conventional number deduplication, text similarity judgment, and enterprise relationship expansion query, the originality of this step lies in its reverse occupancy verification approach, directly examining whether the underlying debt still has the capacity to explain the current financing application, rather than examining whether the current financing application looks like a historical application. This approach can more accurately reveal the essential risk of deformed duplicate financing.

[0020] Step S5 includes the following steps: S5-1, when At that time, the system output includes the current financing application. Basic debt identification code and the lack of identification of underlying claims The missing verification result will be entered into the financial business knowledge graph and linked to the current financing application. Corresponding risk outcome nodes; S5-2, when To ensure that the risk identification results can be reviewed by business auditors, the system not only outputs a duplicate occupancy risk indicator, but also writes the current financing application, basic debt identification code, historical financing record set, effective debt capacity, historical financing occupancy amount, remaining available occupancy amount, applied financing amount, and excess occupancy amount into the risk result field set. ,in, For the current financing application The corresponding risk outcome field set, For the current financing application, For the current financing application The corresponding basic claim identification code, Basic debt identification code The corresponding set of historical financing records, This represents the effective claim capacity of the basic claim unit. This represents the historical financing amount used by the underlying debt unit. For the current financing application The corresponding remaining available quantity, For the current financing application The amount of financing applied for, For the current financing application The amount of excess occupation; the significance of this formula is that the risk output includes not only the risk conclusion, but also the underlying debt unit, historical occupation records and amount verification results on which the conclusion is based; S5-3, the system bases the risk outcome field set Generate a chain of related evidence, which is based on the current financing application. Basic debt identification code Collection of historical financing records Effective debt capacity Historical financing usage Remaining available space Requested financing amount and excess amount The sequential display allows auditors to review the formation process of the risk of duplicate occupation along the same basic debt unit; S5-4, The system writes the relevant evidence chain into the financial business knowledge graph and links it to the current financing application. The corresponding risk result node is output to the financial business review end to identify the risk of duplicate use, so that the current financing application and its corresponding basic debt unit, historical use record and amount verification result form a traceable graph path.

[0021] The output of this step is not a single risk warning, but rather a verifiable chain of business evidence surrounding the underlying debt unit corresponding to the current financing application. Reviewers can trace this chain to see which underlying debt unit the current financing application points to, which historical financing records have already occupied that unit, whether the current application exceeds the capacity of that underlying debt unit, and where the excess comes from. Through this output method, the system can not only conclude whether there is a risk of duplicate occupancy, but also explain the business path that led to this conclusion, preventing risk identification results from becoming unexplainable black-box judgments. Compared to conventional techniques that only output risk scores or anomaly labels, this step establishes a traceable relationship between the current application, the underlying debt unit, historical financing occupancy, and the amount verification results, enabling the financial business review end to directly verify the source of risk and take subsequent actions accordingly.

[0022] Through the above implementation methods, this invention can still determine whether multiple seemingly different financing applications are ultimately based on the same underlying payment obligation, even when the financing applicant changes the invoice number, splits the invoice amount, adjusts the supporting documents, or submits applications in batches across different institutions. Its technical effect is not simply to increase the scope of the query graph, but rather to change the benchmark for identifying duplicate financing risk: conventional techniques mainly determine whether the documents are duplicated, while this invention determines whether the underlying debt has been repeatedly used. Since the usable scope of the same underlying debt unit is jointly limited by the underlying transaction, acceptance confirmation, payment confirmation, and the reduction of the debt, even if the document layer changes, the underlying financing capacity will not be repeatedly amplified.

[0023] Furthermore, the risk results output by this invention include the current financing application, the underlying debt unit, historical financing usage, remaining available usage range, and the risk formation process. This allows reviewers to directly understand the source of the risk without relying on internal model features, similarity thresholds, or human experience to deduce the cause. Therefore, this invention can improve the ability to identify associated risks in modified recurring financing scenarios, and also enhance the interpretability and review efficiency of the risk identification results. It is particularly suitable for business scenarios where the underlying debt is split, packaged, and reused in accounts receivable financing, invoice financing, and factoring financing.

[0024] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus.

[0025] Finally, it should be noted that the above descriptions are merely preferred embodiments of the present invention and are not intended to limit the present invention. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art can still modify the technical solutions described in the foregoing embodiments or make equivalent substitutions for some of the technical features. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A knowledge graph-based financial business association risk identification system, characterized in that: include: The business graph construction module receives financing application data, basic transaction data, payment confirmation data, historical financing data, basic debt reduction data, and financing occupation and release data, and constructs a financial business knowledge graph containing financing application nodes, transaction voucher nodes, payment obligation nodes, and financing occupation nodes. The basic debt unit generation module generates basic debt units based on the payer, payee, purchase order, acceptance batch, and payment due date, enabling different transaction vouchers corresponding to the same underlying payment obligation to be aggregated into the same basic debt unit. The duplicate occupancy identification module is used to map the current financing application to the corresponding basic debt unit, and output the duplicate occupancy risk identification result, which includes risk flags, excess occupancy amount and associated historical financing records, based on the effective debt capacity, historical financing occupancy amount and current financing application amount of the basic debt unit.

2. The knowledge graph-based financial business association risk identification system according to claim 1, characterized in that: The business graph construction module includes a data access submodule, a field standardization submodule, and a relationship writing submodule. The data access submodule is used to receive financing application data, basic transaction data, payment confirmation data, historical financing data, basic debt reduction data, and financing occupation release data. The field standardization submodule is used to standardize the data format of the payer, payee, purchase order, acceptance batch, payment due date, and amount fields. The relationship writing submodule is used to write the association relationships between financing application nodes and transaction voucher nodes, transaction voucher nodes and payment obligation nodes, and payment obligation nodes and financing occupation nodes in the financial business knowledge graph. The basic receivables unit generation module includes an anchor field determination submodule, a unit aggregation submodule, and a capacity generation submodule. The anchor field determination submodule is used to determine the payer, payee, purchase order, acceptance batch, and payment due date as the anchor fields for generating basic receivables units. The unit aggregation submodule is used to aggregate payment obligation nodes with consistent anchor fields into the same basic receivables unit. The capacity generation submodule is used to generate the effective receivables capacity of the basic receivables unit based on the effective order amount, acceptance confirmation amount, payment confirmation amount, and basic receivables reduction amount. The duplicate occupancy identification module includes an application mapping submodule, an occupancy verification submodule, and a result output submodule; The application mapping submodule is used to map the current financing application to the corresponding basic debt unit. The occupancy verification submodule is used to compare the current financing application amount with the remaining available occupancy of the basic debt unit. The result output submodule is used to output the duplicate occupancy risk indicator, the excess occupancy amount, and the associated historical financing records.

3. A method for identifying associated risks in financial transactions based on knowledge graphs, characterized in that: The method operates according to the system described in claim 2, including the following steps: S1. Construct a financial business knowledge graph. The system receives financing application data, basic transaction data, payment confirmation data, historical financing data, basic debt reduction data, and financing occupation release data. It standardizes the subject field, voucher field, payment obligation field, and amount field. After processing, the system writes the financing application, transaction voucher, payment obligation, and historical financing occupation into the same financial business knowledge graph, so that business data from different sources can be queried and associated in the same graph structure. S2, Generate basic debt unit. The system does not use invoices as the sole identification object, but determines the underlying payment obligation based on the payer, payee, purchase order, acceptance batch and payment due date. For multiple transaction vouchers pointing to the same underlying payment obligation, the system aggregates them into the same basic debt unit and records the effective debt capacity that the financing application can occupy in the basic debt unit. S3, Mapping the current financing application: The system reads the payer, payee, purchase order, acceptance batch, payment due date standard value and application amount from the current financing application, and maps the current financing application to the corresponding basic debt unit to determine whether the current financing application points to an existing underlying payment obligation; S4. Identify the risk of duplicate occupancy. The system queries the historical financing occupancy records and repayment release records corresponding to the basic debt unit to obtain the remaining available amount of the basic debt unit. The system compares the current financing application amount with the remaining available amount and identifies the risk of duplicate occupancy of the basic debt when the current financing application amount exceeds the remaining available amount. S5, Output Risk Identification Results. The system outputs the underlying debt unit corresponding to the current financing application, historical financing occupancy records, remaining available occupancy amount, excess occupancy amount, and risk indicator. This output result is used to indicate that although the current financing application is not directly duplicated with the historical application at the certificate level, it has caused duplicate occupancy of the same underlying debt at the underlying debt level.

4. The method for identifying financial business association risks based on knowledge graphs according to claim 3, characterized in that: Step S1 includes the following steps: S1-1, Confirmation record for each payment obligation Extract the payer's identification code Recipient identification code Purchase order identification code Acceptance batch identification code and payment due date standard value The payment obligation confirmation record is generated using the following formula. Corresponding basic claim identification code ,in, For a payment obligation confirmation record, Confirmation record of the aforementioned payment obligation The payer identification code in the middle, Confirmation record of the aforementioned payment obligation The recipient's identification code in the payment information. Confirmation record of the aforementioned payment obligation Purchase order identification code in Confirmation record of the aforementioned payment obligation The acceptance batch identification code in the middle, Confirmation record of the aforementioned payment obligation The standard value for the payment due date in the document. The system uses a pre-defined fixed encoding function. This function concatenates, normalizes, and encodes fields according to a fixed order: payer identification code, payee identification code, purchase order identification code, acceptance batch identification code, and payment due date. This generates a unique basic debt identification code. , It is the basic receivable identification code jointly determined by the payer identification code, payee identification code, purchase order identification code, acceptance batch identification code, and payment due date standard value; S1-2, after obtaining the basic debt identification code Subsequently, the system uses this identification code as the basis for aggregation at the payment obligation level, allowing records that differ at the document level but share the same underlying payment obligation to be grouped into the same basic claim unit, and assigning the basic claim identification code... Records of the same payment obligation are grouped into the same basic debt unit, and a pointing relationship between the basic debt unit and the transaction voucher node is established in the financial business knowledge graph; S1-3 connects the historical financing application node with its corresponding basic debt unit, and writes the loan disbursement status, repayment status and release status of the historical financing application into the financing occupation node.

5. The method for identifying financial business association risks based on knowledge graphs according to claim 4, characterized in that: Step S2 includes the following steps: S2-1, Based on the debt ceiling, the system deducts the amount that has already reduced the basic debt amount to obtain the effective debt capacity of the basic debt unit. ,in, This serves as the basic claim identification code for a basic claim unit. The effective amount of the purchase order corresponding to this basic debt unit. This is the acceptance confirmation amount corresponding to the basic debt unit. This is the amount of payment confirmation corresponding to the underlying debt unit. This refers to the amount by which the amount of the underlying claim decreases due to buyer payments, credit adjustments, or write-offs within the underlying claim unit. This represents the effective claim capacity of the basic claim unit; The function is used when the deduction result is less than The effective debt capacity will be determined as follows: , The function is used to select the lowest amount from the valid purchase order amount, the acceptance confirmation amount, and the payment confirmation amount as the upper limit of the receivables capacity; S2-2, effective debt capacity Write the capacity field of the underlying claim unit and match the capacity field with the underlying claim identification code. Binding ensures that subsequent financing applications can only be verified within the effective claim capacity of the underlying claim unit. S2-3, When multiple transaction certificates point to the same underlying debt identification code At that time, the system will only use these multiple transaction certificates as sources of evidence to prove the existence of the same underlying debt unit, and will continue to use the effective debt capacity. This serves as the unified upper limit for the occupancy of the basic debt unit.

6. The method for identifying financial business association risks based on knowledge graphs according to claim 5, characterized in that: Step S3 includes the following steps: S3-1, The system processes the current financing application. Extract the payer's identification code Recipient identification code Purchase order identification code Acceptance batch identification code and payment due date standard value The current financing application can be obtained using the following formula. Corresponding basic claim identification code ,in, For the current financing application, For the current financing application The payer identification code in the middle, For the current financing application The recipient's identification code in the payment information. For the current financing application Purchase order identification code in For the current financing application The acceptance batch identification code in the middle, For the current financing application The standard value for the payment due date in the document. For the current financing application The underlying debt identification code obtained through mapping; S3-2, Query the basic debt identification code in the financial business knowledge graph. The basic debt unit, and the current financing application A mapping relationship is established with the basic claim unit for the occupancy verification in step S4. If the basic claim identification code does not exist in the financial business knowledge graph... When identifying the underlying debt unit, the system generates a missing underlying debt identifier and updates the current financing application. The application is sent to the manual verification process, and the subsequent verification of remaining available funds is not performed. The missing basic claim is identified as the current financing application. Mapping result fields , This indicates that the basic debt identification code does not exist in the financial business knowledge graph. The corresponding basic debt unit, This indicates that a basic debt identification code exists in the financial business knowledge graph. The corresponding basic debt unit; S3-3, Read the current financing application The amount of financing applied for and the amount of financing applied for As the current financing application The amount to be used for this underlying debt unit, of which For the current financing application The principal amount of financing requested from a financial institution.

7. The method for identifying financial business association risks based on knowledge graphs according to claim 6, characterized in that: S4 includes the following steps: S4-1, in the current financing application It has been mapped to the underlying debt identification code. Afterwards, the system retrieved the underlying debt identification code as follows: The set of historical financing records corresponding to the basic debt unit The historical financing amount of the underlying debt unit is calculated using the principal amount already disbursed in the historical financing records as the source of occupied funds, and the financing repayment amount and financing cancellation amount in the historical financing records as the source of occupied funds release. ,in, For the current financing application The underlying debt identification code obtained by mapping The corresponding set of historical financing records, A collection of historical financing records One of the historical financing records, Historical financing records The amount of principal already disbursed. Historical financing records The amount of financing already released due to loan repayments and loan cancellations. For the current financing application The corresponding historical financing amount of the underlying debt unit; S4-2, after obtaining the effective debt capacity and historical financing usage The system then calculates the difference between the two to determine the current financing application. The remaining usable claim space within the same basic claim unit is calculated as follows: ,in, For the current financing application Mapped to the underlying debt identification code Afterwards, the remaining portion of the underlying debt unit can be used by the current financing application. The amount used; The function is used to determine the remaining available amount when the historical financing amount exceeds the effective debt capacity. To avoid negative values ​​for the remaining available space; S4-3, after obtaining the remaining available quantity Then, the system will process the current financing application. The amount of financing applied for With remaining available quantity The amounts are compared, and the portion exceeding the remaining available space is determined as the excess amount. ,in, For the current financing application Relative to remaining available quantity The amount of excess funds used; S4-4, When the excess amount is used Greater than At that time, the system generates a risk indicator for repeated use of the underlying debt and records the amount of excess use. Write into the current financing application The risk field, and the system will include the current financing application. Corresponding risk indicator of repeated use of underlying debt The value is set to 1; when the excess amount is used... equal At that time, the system will not generate a risk indicator for repeated use of underlying debt, and will update the current financing application. The occupancy verification result is written into the financial business knowledge graph, and the system will record the current financing application. Corresponding risk indicator of repeated use of underlying debt The value is determined to be 0.

8. The method for identifying financial business association risks based on knowledge graphs according to claim 7, characterized in that: Step S5 includes the following steps: S5-1, when At that time, the system output includes the current financing application. Basic debt identification code and the lack of identification of underlying claims The missing verification result will be entered into the financial business knowledge graph and linked to the current financing application. The corresponding risk outcome node; S5-2, when At that time, the current financing application, the underlying debt identification code, the set of historical financing records, the effective debt capacity, the historical financing usage, the remaining available usage, the applied financing amount, and the excess usage amount will be jointly written into the risk result field set. ,in, For the current financing application The corresponding risk outcome field set, For the current financing application, For the current financing application The corresponding basic claim identification code, Basic debt identification code The corresponding set of historical financing records, This represents the effective claim capacity of the basic claim unit. This represents the historical financing amount used by the underlying debt unit. For the current financing application The corresponding remaining available quantity, For the current financing application The amount of financing applied for, For the current financing application The amount of excess funds used; S5-3, the system bases the risk outcome field set Generate a chain of related evidence, which is based on the current financing application. Basic debt identification code Collection of historical financing records Effective debt capacity Historical financing usage Remaining available space , amount of financing applied and excess amount The order of presentation; S5-4, The system writes the relevant evidence chain into the financial business knowledge graph and links it to the current financing application. The corresponding risk result node is then output to the financial business review end to identify the risk of duplicate occupation.

Images