An identity binding, credit risk control and right confirmation closed loop storage system and method for agricultural bulk credit sales
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-05-21
- Publication Date
- 2026-08-11
AI Technical Summary
数据可篡改问题:现有系统的数据存储多支持修改或删除操作,具有管理员权限的用户(如老板、收银员)可后台修改或删除历史订单数据,无法满足司法存证对数据不可篡改的要求
Smart Images

Figure CN122550281A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of digital risk control and electronic data storage technology, specifically to a closed-loop system and method for identity binding, credit risk control and rights confirmation in agricultural wholesale credit sales. Background Technology
[0002] Currently, the digital construction of smart agricultural wholesale markets has become the mainstream development direction in the industry. Existing publicly available solutions generally propose building a full-chain digital platform, microservice architecture, big data analysis, and other common technologies in an attempt to reduce costs and increase efficiency in the industry. However, these solutions only focus on general transaction settlement and basic credit assessment, and completely fail to design a complete risk control system specifically for the high-frequency credit sales transaction scenarios in agricultural wholesale markets, including strong identity binding, transaction confirmation, closed-loop evidence storage throughout the process, and prevention of overdue risks.
[0003] Existing agricultural wholesale management software (such as inventory management systems, point-of-sale systems, and stall management SaaS) mainly focuses on daily operational functions such as order processing, inventory management, and basic reconciliation. Analysis reveals the following common technical problems in existing technologies: Data tampering issue: Existing systems often only support modification or deletion of data storage. Users with administrator privileges (such as owners or cashiers) can modify or delete historical order data in the background, failing to meet the requirement of immutability for judicial evidence preservation. Current technologies lack a closed-loop evidence chain generation mechanism based on trusted timestamps and operation terminal identifiers, making it difficult to achieve traceable operational behavior and tamper-proof data in judicial evidence preservation.
[0004] Issues of delayed and unverified transaction information: In the current model, sales staff first handwrite invoices and complete shipment, only handing over the documents to the cashier for system entry afterwards. This process leads to: 1) delayed information: goods have been shipped but there is no record in the system, making it impossible for the owner to monitor the transaction status in real time; 2) inability to verify authenticity: the buyer's identity, quantity, and amount are all stated unilaterally by the sales staff, lacking real-time verification by a third party or the buyer themselves; 3) lack of buyer confirmation: goods have been shipped but the buyer has never confirmed "I owe this amount" in a verifiable way, making it difficult for the stall to provide legally valid proof of payment in case of disputes. Existing POS software merely converts "handwritten invoices" to "electronic invoices," failing to change the fundamental nature of post-transaction data entry and thus not resolving the above problems.
[0005] The problem of fictitious buyer identities and the lack of preventative measures against debt evasion: The existing system's entry of buyer identity information is extremely arbitrary, often only recording nicknames (such as "Old Wang"), with key information such as contact numbers and ID card numbers missing or unverified. Legally, the buyer is a "fictitious" and untraceable string. This leads to: first, the "debtor" on the debt bill may not be a real legal entity, making it impossible for the stall owner to identify the debtor; second, buyers can easily "re-register" by changing nicknames and phone numbers to evade past debts; and third, even if disputes arise, stall owners find it difficult to pursue legal action because they cannot verify the buyer's true identity. The existing system lacks a real-name verification mechanism for buyers and a mandatory linkage between identity and debt status, failing to fundamentally prevent debt evasion.
[0006] The lack of checks and balances in the existing system: In electronic order processing, no one verifies the authenticity of outstanding payments in real time after a salesperson issues an order. Cashiers simply enter the information based on the order details, making it impossible to verify the buyer's identity or the amount owed before or during shipment. This leads to two problems: First, false outstanding payments may be entered into the system, causing accounting losses. Second, during the subsequent remediation and verification process, there is room for collusion between salespersons and buyers, or for salespersons to manipulate the system themselves, potentially leading to the risk of misappropriation of funds. The existing system lacks a check and balance mechanism that ensures "verification upon order issuance and no effect without confirmation of rights."
[0007] The existing risk control mechanism suffers from several shortcomings, including a lack of proper credit assessment. The current system only allows merchants to manually set fixed limits on the number of days or the amount owed. When a buyer's accumulated debt exceeds the threshold, the system passively blocks the order. This mechanism has several flaws: First, it lacks genuine credit assessment. The system does not analyze dynamic data such as the buyer's historical repayment behavior, overdue records, and transaction stability, making it impossible to create a differentiated credit profile. Second, the blocking relies on data entry; sales staff can bypass the threshold by delaying order entry, rendering the risk control rules ineffective. Third, it cannot predict risk trends; the system only reacts passively when limits are exceeded, failing to proactively warn of risks in their early stages. Essentially, the existing system is a "hard-coded threshold trigger," rather than a dynamic risk control system based on credit assessment.
[0008] The aforementioned technical problems are not recent. The management of credit sales in the agricultural and sideline product wholesale industry has evolved over a period of more than ten to twenty years, from verbal agreements and handwritten paper documents to electronic inventory management software. However, neither the early verbal agreements and handwritten IOUs, nor the more recent inventory management software and POS systems, have fundamentally solved the core issues of credible identity, reliable rights confirmation, tamper-proof evidence, prevention of internal fraud, and prevention of malicious debt evasion in credit sales scenarios. Existing solutions consistently treat "transaction records" and "risk control evidence storage" as separate processes, lacking a complete business loop from identity binding to rights confirmation to evidence storage. The industry has long faced a passive situation of "goods shipped, outstanding payments not confirmed, lack of evidence, and no way to recover debts." This invention is a systematic solution to this long-standing unresolved technical problem in the industry. Summary of the Invention
[0009] Agricultural wholesale markets operate early and are poorly managed. The traditional "take goods first, pay later" model puts merchants in a passive position, leading to high payment risk and difficulties in obtaining evidence for disputes. The core innovation of this invention lies in its deep integration of five key technologies: identity binding and debt evasion prevention, closed-loop rights confirmation, supplementary evidence storage, automatic risk control of credit limits and restricted lists, and unified accounts with multiple identities and access isolation. This forms a complete technical closed loop encompassing pre-event standardization, in-event record keeping, post-event support, and deterrence. This changes the traditional passive situation, allowing merchants to complete payment procedures before taking delivery, thus preemptively addressing risks, solidifying evidence, and achieving standardized, controllable, reliable, and clear ownership of credit sales.
[0010] Specifically, the present invention includes the following technical features: Identity binding and debt evasion prevention: Real-name verification establishes a credit sales qualification binding. When there are outstanding debts, the binding relationship is forcibly locked, prohibiting unbinding, account cancellation or change of identity information, thus forming a debt evasion prevention mechanism.
[0011] Closed-loop rights confirmation: Purchasers must actively confirm their rights. Documents without confirmed rights are not valid and will not be included in subsequent settlement and risk control processes.
[0012] Appendix-based data storage: It adopts an immutable and fixed storage mechanism that only adds data, does not modify it, and does not physically delete it. All business data is timestamped and left a complete trace.
[0013] Automatic risk control based on credit limit and restricted list: Before a transaction, the system automatically checks the outstanding credit limit and restricted list. If the limit is exceeded or the transaction is on the restricted list, the transaction will be blocked directly during the order opening process, thus achieving proactive risk control in advance.
[0014] Unified Account and Segregated Permissions for Multiple Identities: The same account can be bound to multiple identities such as salesperson, purchaser, and business entity. Different identities can log in to an independent workbench, and data is isolated at the row level. The system restricts the repayment interface, and the permissions for repayment marking and fund reconciliation operations are only granted to the business operator, thus controlling the salesperson from a technical perspective.
[0015] In addition, as a preferred embodiment, the system may also include a judicial evidence storage module, which integrates the confirmation records, transaction logs and storage logs to generate an electronic evidence data package that meets the judicial recognition standards. Once generated, the data package is stored in a fixed manner and supports output in at least one of the following ways: download, push, interface call, and printing, for users to use as evidence in dispute resolution.
[0016] The various technical aspects of this invention are not simply an aggregation of independent functions, but rather achieve an overall technical effect that transcends a single module through closed-loop linkage of data flow and control flow. Specifically, this is manifested in: The identity binding module provides the rights confirmation module with a traceable legal entity: by linking real-name verification with the debt status, the rights confirmation process is upgraded from the traditional "anonymous or nickname confirmation" to "real-name and irreversible legal entity confirmation", laying the identity foundation for subsequent rights confirmation; The rights confirmation module provides the evidence storage module with legally valid confirmation records: requiring purchasers to actively confirm their rights (scanning codes, clicking, facial recognition, remote access, etc.), and "no confirmation of rights means no effect," so that the evidence storage module records not just simple transaction records, but legal evidence with the effect of electronic signature law; The evidence storage module provides the risk control module with tamper-proof historical behavior data: through append-only storage (adding only, not modifying, and not physically deleting), it ensures that the data on which credit profiles and credit limit interception are based is true, complete, and traceable, thus upgrading risk control decisions from "relying on human statements" to "relying on objective evidence"; The risk control module and the identity binding module work together to prevent transactions from being blocked in advance: the automatic risk control module verifies the credit limit and restricted list before the transaction occurs. Once the limit is exceeded or the list is hit, the credit purchase request is blocked directly. It also works with the identity binding module to prevent the purchaser from bypassing the restrictions by changing their identity. The access control module provides operational security boundaries for the entire process: unified accounts with multiple identities and access control ensure that key actions such as order placement, confirmation of rights, and reconciliation are performed by different roles, thus technically preventing salespersons from unilaterally creating false debts or privately reconciling and misappropriating funds.
[0017] The data and control flows between the aforementioned modules form a closed loop: identity → rights confirmation → evidence storage → risk control → permissions, each link is interconnected and indispensable. This closed-loop structure enables the present invention to achieve a technological leap from "passive response after the fact" to "proactive prevention before the fact" in the agricultural wholesale credit sales scenario, producing an overall technical effect that cannot be achieved by any single module or simple combination of functions in the prior art, which is not obvious.
[0018] In this invention, all interception thresholds, restricted list entries, and risk control rule types are set independently by merchants through the configuration interface provided by the system. The system does not preset any default thresholds or default rules; it only executes interception, mandatory verification, or tiered alerts according to the rules set by the merchant when they are triggered. The final transaction decision-making power always belongs to the merchant and their employees; the platform does not participate in any risk control decisions.
[0019] The platform does not intervene in the flow of funds at all, and its technical architecture does not include a fund collection and settlement interface. It only acts as a neutral evidence provider to offer services such as transaction confirmation, data storage, and risk control management.
[0020] Definitions To clearly define the scope of protection of this patent, the following terms are defined: Append-only storage: This refers to a system that only allows insert and query operations, prohibiting updates and physical deletions. Visibility of already active data is controlled via logical deletion flags. This mechanism is designed to address the strong data consistency requirements of high-frequency concurrent agricultural wholesale transactions, preventing malicious tampering or deletion of outstanding payment records by internal personnel and ensuring the inviolability of the evidence chain.
[0021] Credit profile: The credit assessment result of the purchaser is calculated based on a combination of data from three tracks: legal obligations, industry consensus, and behavioral performance.
[0022] The restricted list includes at least one of the following: the list of dishonest persons subject to enforcement by the court, the risk list of the credit sharing network, and the risk list marked by merchants themselves. Beneficial effects
[0023] This invention technically blocks debt evasion by linking identity with debt status; it eliminates social pressure and achieves de-socialized, legally-level rights confirmation by replacing traditional face-to-face signatures with closed-loop rights confirmation; it solves the problem of signing is impossible in cross-regional transactions through remote rights confirmation channels; it technically controls salespersons and prevents falsification and misappropriation by unifying accounts and permissions across multiple identities and locking repayment permissions; it allows business owners to monitor transaction status in real time through real-time data synchronization, eliminating information gaps; it enables post-event traceability and probable evidence through supplementary, tamper-proof evidence storage and export of judicial evidence materials; it intercepts risks before transactions occur through pre-event automatic risk control of credit limits and restricted lists; and it breaks down credit information silos through cross-market, cross-slot, and cross-business entity joint prevention, achieving nationwide restrictions for any breach of trust. The system forcibly binds people, money, and goods through technical means, forming a mutual supervision and trust mechanism, effectively reducing the industry's bad debt rate and purifying the transaction environment. Business is risk control, and process is evidence.
[0024] This invention systematically solves common technical problems in agricultural wholesale credit sales scenarios, such as unreliable identities, unreliable rights confirmation, easily tampered data, undocumented operations, internal overreach, and malicious debt evasion, through the aforementioned technical means. It achieves a technological leap from "relying on personal relationships and human judgment" to "relying on rigid system rules". Attached Figure Description
[0025] Figure 1 This is a system module architecture diagram of the present invention.
[0026] Figure 2 A flowchart for identity binding and debt evasion prevention.
[0027] Figure 3 This is a flowchart of the multi-path closed-loop rights confirmation process.
[0028] Figure 4 A decision tree diagram for pre-risk control verification. Detailed Implementation
[0029] The technical solution of the present invention will now be fully described with reference to the accompanying drawings and specific implementation scenarios. The specific parameters in the embodiments are merely illustrative and do not constitute a limitation on the present invention.
[0030] Example 1: Scenarios of linking credit sales eligibility with debt evasion prevention Purchaser Zhang bought fruit from merchant Li. Li initiated a binding request to Zhang through the system, and Zhang confirmed the request, establishing a binding relationship. After Zhang incurred an outstanding debt, the system updated the debt status in real time. During the period the debt was outstanding, any attempts by Zhang to unbind, cancel the account, or change his identity information were technically prohibited by the system. Once Zhang settled all outstanding debts, the system automatically released the unbinding permission.
[0031] Example 2: Multi-path rights confirmation scenario - on-site QR code scanning The salesperson at the stall creates an outstanding payment invoice, and the system generates a one-time dynamic confirmation code. The buyer scans the code on the spot to confirm, and the confirmation code immediately expires. The confirmation record, along with a timestamp, terminal identifier, and operator identity, is written to an append-only storage layer. The buyer does not need to sign in person, eliminating social pressure.
[0032] Example 3: Multi-path rights confirmation scenario - remote push For buyers located in other areas who cannot attend in person, the system pushes the invoice to the buyer's account via a private internal channel, along with an encrypted confirmation token and a set validity period. After logging in, the buyer clicks to confirm, and the confirmation record is finalized. The buyer does not need to be present or mail any paper documents.
[0033] Example 4: Biometric Identity Confirmation Scenario Purchasers can choose facial recognition as the authentication method on terminals equipped with facial or fingerprint recognition capabilities. The system uses the terminal's camera or fingerprint module to collect biometric features, which are then compared with the biometric template provided during the purchaser's real-name authentication. Once the comparison is successful, authentication is automatically completed. This method further strengthens the uniqueness of the authentication process while maintaining equivalence to other authentication methods such as scanning QR codes or clicking. The system can automatically select the available authentication method based on the terminal's capabilities.
[0034] Example 5: Prevention Before the Event – Credit Profiling and Automatic Interception Purchaser Li's credit profile in the system was below the mandatory blocking threshold set by the merchant. When Li attempted to initiate a credit purchase again, the system automatically blocked the request through pre-verification via the interface and displayed a message stating "Insufficient credit score, credit purchase prohibited." After Li settled the outstanding payment, his credit profile improved, and the system automatically released the credit purchase permission.
[0035] Example 6: Prevention – Credit Limit Control and Tiered Reminders Merchant Wang set a credit limit of 50,000 yuan for each buyer in the backend. Buyer Zhao's accumulated debt had reached 48,000 yuan, and the system automatically displayed a weak warning on the order page: "Approaching the credit limit." When Zhao continued to place orders up to 52,000 yuan, the system automatically blocked the order request through a status lock mechanism and popped up a strong warning: "Exceeding the credit limit, unable to issue an order."
[0036] Example 7: Prevention Before Sales – Prohibited Sales on Credit List Merchant Sun discovered that buyer Zhou had multiple overdue payment records and added Zhou to the "prohibited credit sales" list in the system. Subsequently, any credit sales requests made by Zhou to Sun were automatically blocked by the system, which displayed the message "This buyer has been prohibited from credit sales."
[0037] Example 8: In-process control – Salesperson permission isolation After a salesperson named Zhang created an outstanding payment invoice, the buyer did not confirm the payment, rendering the invoice invalid. The buyer then privately transferred the payment to Zhang. Zhang attempted to mark the payment as "paid" in the system, but the system displayed "no permission." The boss's terminal showed the payment as "unpaid" in real time. Upon discovering the anomaly, the boss contacted the buyer to verify the situation, thus exposing Zhang's misappropriation.
[0038] Example 9: In-process control – Real-time data synchronization After the buyer, Mr. Liu, confirmed the debt in a different location, the system synchronized the confirmation status of the debt to the associated merchant's terminal in real time. The merchant owner can then view all outstanding debts, confirmed invoices, overdue days, and other information by opening the system, without relying on verbal reports from sales staff.
[0039] Example 10: Post-event backup – Additional storage and evidence export When a merchant and a buyer have a payment dispute, the merchant exports an evidence package for litigation or rights protection, including identity binding records, rights confirmation records, and repayment records. All data is appended with a timestamp chain to ensure integrity and immutability. The buyer attempted to invalidate the rights confirmation record on the client side; the system only triggered a logical deletion flag, while the physical data was completely preserved.
[0040] Example 11: Unified Entity and Multi-Department Management Scenario A fruit company has branches in multiple locations, all registered under the same legal entity as its head office. The system designates the head office as the primary legal entity, while each branch is configured independently. Each transaction is automatically linked to both the head office and the branch information. Branch accounts can only view their own data, while the head office can access global statistics on all branch transactions and outstanding payments.
[0041] Example 12: Legal Notification Scenario Linked to Billing When the system generates an outstanding payment bill, it automatically includes an inseparable performance risk notification document, clearly displaying the designated repayment account and compliant payment channels pre-registered by the system, and informing the user of the potential legal consequences of failing to pay through the designated channels. The notification document is forcibly linked to the bill and cannot be deleted or removed separately.
[0042] Example 13: Purchaser Self-Entries Ledger Scenario Purchasers can independently enter their cash purchase transaction data from multiple merchants through a separate portal in the system. The system automatically generates a personal purchase ledger for purchasers to query, summarize, and analyze data, while keeping it separate from credit sales data.
[0043] Example 14: Cross-market and cross-slot joint prevention and control scenario Within the same market, buyer Zhou committed serious overdue payments at stall A, which marked him as a defaulter. The system automatically synchronized Zhou's default record (after anonymization) to stalls B and C within the same market, as well as stalls D and E across different markets. When Zhou initiates a credit purchase request at any of the associated stalls, the system automatically intercepts it and displays a message stating "This buyer has been restricted across the entire network." This achieves network-wide blocking across stalls and markets due to a single instance of default.
[0044] Example 15: Rule Self-Configuration Scenario Merchants log in to the system backend and independently set the following risk control configuration options through the risk control configuration interface: credit limit (by customer or department), restricted list items (court defaulters, industry risks, self-blacklisting), and risk control rule types (hard constraints require authorization, soft constraints only require alerts, no alerts, direct approval). The system does not preset any default thresholds; all configuration items are initially empty or disabled, and merchants must enable them one by one according to their own business needs. After configuration, the system automatically executes blocking or tiered alerts according to the rules set by the merchant, and the transaction decision-making power always belongs to the merchant.
[0045] The above are merely preferred embodiments of the present invention and are not intended to limit the present invention. Any simple improvements or equivalent substitutions based on the technical solutions of the present invention shall fall within the protection scope of the present invention.
Claims
1. A closed-loop evidence storage system for identity binding, credit risk control, and rights confirmation in agricultural wholesale credit sales, characterized in that, include: Identity binding and debt evasion prevention module: Verifies the identities of merchants and buyers and establishes a binding relationship for credit sales eligibility; The system monitors the settlement status of outstanding payments by buyers under the corresponding merchants in real time. When an outstanding payment is detected, the system forcibly locks the binding relationship, prohibits unbinding, account cancellation, and changes to the bound identity information, thus forming a debt evasion prevention mechanism. Closed-loop rights confirmation module: Purchasers must confirm the rights of outstanding payment documents. Outstanding payment documents that have not been confirmed will not be marked as effective by the system and will not be included in subsequent settlement and risk control processes. Append-only data storage module: It adopts an immutable and solidified storage mechanism that only adds data, does not modify it, and does not physically delete it. All business data is timestamped and left as a complete trace. Automatic risk control module for credit limit and restricted list: The system provides an interface for configuring the credit limit limit and the restricted list, which are used to configure the credit limit data and the prohibited credit sales list data. Before a transaction occurs, the system reads the configuration data through the interface and automatically checks the outstanding amount and the restricted list before the transaction. If the amount exceeds the limit or the restricted list is matched, the transaction will be blocked directly at the order opening stage, realizing proactive risk control in advance. Multi-identity unified account and permission isolation module: Supports binding multiple identities such as salesperson, purchaser, and business entity to the same account. After logging in with different identities, they enter their own independent workbench, and the data space is isolated from each other. Among them, the system restricts the repayment interface, and the permissions for repayment marking and fund verification are only granted to the merchant operator or its designated authorized role.
2. The system according to claim 1, characterized in that, The restricted list includes at least one of the following: the court's list of dishonest judgment debtors, the credit sharing network risk list, and the risk list self-marked by merchants.
3. The system according to claim 1, characterized in that, The system supports the independent, simultaneous, or arbitrary combination of automatic interception paths and hierarchical decision support paths. Under the hierarchical decision support path, the system generates strong risk warnings, weak risk warnings, or no risk warnings, allowing merchants to decide whether to continue initiating credit sales. Merchants can independently label buyers with risk tags or set up a list of prohibited sales on credit. Once a buyer is labeled or added to the list, the system will automatically block the order request.
4. The system according to claim 1, characterized in that, It also includes a judicial evidence storage module, which integrates ownership confirmation records, transaction logs and storage logs to generate electronic evidence data packages that meet judicial recognition standards. Once generated, the data package is permanently stored and can be output to user terminals or external systems via at least one of the following methods: download, push, API call, or printing.
5. The system according to claim 1, characterized in that, The cross-market, cross-stall, and cross-business entity joint prevention and control mechanism adopts a data anonymization and encryption synchronization mechanism; among which, the cross-stall includes data sharing and risk linkage between different stalls within the same market.
6. The system according to claim 1, characterized in that, The confirmation process includes at least one of the following methods: QR code confirmation, click confirmation, electronic signature confirmation, facial recognition confirmation, and fingerprint recognition confirmation. Once the confirmation is completed, the confirmation code or confirmation token becomes invalid immediately, and the confirmation record synchronously solidifies the timestamp, operation terminal identifier, and operator identity information. When confirming remotely, the system pushes the bill to the buyer's account through a private channel within the system, along with an encrypted confirmation token and a set validity period. If the validity period expires, the process must be restarted, and viewing and confirmation actions are automatically recorded.
7. The system according to claim 2, characterized in that, In the automatic interception path, when a buyer is on the restricted list, the system automatically intercepts the request for credit sales; in the hierarchical decision support path, the system executes soft constraint reminders or hard constraint mandatory authorization according to the merchant's preset rule type.
8. The system according to claim 5, characterized in that, Before synchronizing records of dishonesty to the credit sharing network, the system automatically de-identifies the records and synchronizes them to users on the associated platform through an encrypted transmission channel. After receiving anonymized data, the system automatically performs access control based on the joint prevention rules uniformly configured by the platform, the risk control rules independently set by each platform user, or a combination thereof.
9. The system according to claim 8, characterized in that, The system's underlying layer has a unified legal entity information that is locked and cannot be changed, and the system does not provide a backend modification entry; the backend uniformly pre-files and configures the data of each business division, and each transaction document is automatically bound to the fixed entity and the corresponding configured division information, making the documents a unified and fixed association that cannot be split or tampered with; the account permissions of each division are isolated from each other, and the headquarters has a unified port with full data global statistics and overall management and control permissions.
10. The system according to claim 1, characterized in that, The system automatically calculates a credit profile based on three input tracks: legal obligation data, industry consensus data, and behavioral performance data. The behavioral performance data includes at least one of the following: number of overdue payments, number of overdue days, average delay duration, confirmation response time, confirmation completion rate, and historical transaction stability indicators. The industry consensus data includes anonymized risk warnings synchronized within the credit sharing network after platform verification, violation handling decisions by market management authorities or industry associations, and risk labels self-marked by merchants. The legal obligation data includes publicly available effective court documents, lists of dishonest judgment debtors, or effective legal documents uploaded by users.