Competition margin supervision method and system based on multi-party approval

Abstract

The invention discloses a multi-party approval-based competition deposit supervision method and system, and belongs to the technical field of financial data processing, and the method comprises the steps: obtaining a competition supervision request submitted by a competition organization party, and generating an electronic supervision protocol; the account opening requirement is analyzed, an account opening instruction is generated and sent to a bank party, and the bank party opens a co-management account; receiving a deposit depositing request of a competition organizer, and generating a project ledger; after the competition is completed, receiving a fund transfer request, generating an examination and approval message and sending the examination and approval message to an examination and approval interface of a supervisor; and receiving an approval instruction returned by the supervisor, generating a fund transfer operation instruction, sending the fund transfer operation instruction to the bank, generating transaction detail information and synchronizing the transaction detail information to each party. According to the invention, the technical means of constructing an electronic protocol, opening a bank co-management account, establishing a project ledger and automatically processing approval and payment instructions are adopted by the platform system, so that the full-process automatic, safe and transparent supervision of the cash deposit can be realized.

Description

Technical Field

[0001] This invention relates to the field of financial data processing technology, and in particular to a method and system for supervising event deposits based on multi-party approval. Background Technology

[0002] Event deposits are specific funds paid by event organizers to regulatory agencies or relevant parties to ensure the smooth operation, adherence to rules, and fulfillment of commitments in various sports, esports, and other events. In commercial practice, effectively monitoring these dedicated funds to ensure their intended use and prevent misappropriation or abuse is crucial for maintaining event order, protecting participants' rights, and upholding market credibility. Utilizing data processing technology to manage event deposits has become an industry trend.

[0003] In current technology, the supervision of event deposits typically relies on a combination of traditional banking services and offline processes. For example, the event organizer may open a regular settlement account at a bank and agree with the regulator to control fund payments through the bank's corporate online banking system with dual or multi-person verification. When funds need to be transferred, the organizer submits a paper application and relevant supporting documents offline to the regulator. After the regulator approves the application, its authorized personnel log in to the corporate online banking system to complete the verification and payment.

[0004] The aforementioned existing technical solutions have significant technical flaws. First, the isolation of funds is insufficient. Ordinary settlement accounts cannot strictly restrict non-regulated payment attempts based on account attributes, and fund security relies primarily on human approval processes, creating management loopholes. Second, the process is inefficient and error-prone. The entire process involves multiple interruptions, including offline document submission, manual review, multiple communications among various parties, and manual login to online banking. The process is lengthy, and information transmission is prone to distortion or delays. Finally, information transparency is poor. Apart from the few individuals operating the funds, other relevant parties cannot obtain real-time and accurate information on the custody status and flow details of the margin, lacking a unified and transparent information view. Summary of the Invention

[0005] To address the aforementioned issues, this invention provides a method and system for supervising event deposits based on multi-party approval. It employs technical means such as platform-based system construction of electronic agreements, opening of joint bank accounts, establishment of project ledgers, and automated processing of approval and payment instructions, enabling fully automated, secure, and transparent supervision of the deposit process.

[0006] The above objectives can be achieved through the following approach:

[0007] A method for supervising event deposits based on multi-party approval includes: obtaining an event supervision request submitted by the event organizer; generating an electronic supervision agreement defining the roles and responsibilities of the event organizer, regulator, bank, and platform based on the event supervision request and agreement generation rules; parsing the account opening requirements in the electronic supervision agreement, generating an account opening instruction and sending it to the bank, whereby the bank opens a co-managed account with a deposit-only attribute; receiving a deposit request from the event organizer and depositing the deposit funds into the co-managed account, while simultaneously generating a project ledger associated with the co-managed account based on the event identifier in the deposit request; after the event is completed, receiving a fund transfer request corresponding to the project ledger, generating an approval message pending approval and sending it to the regulator's approval interface; receiving the approval instruction returned by the regulator in response to the approval message, generating a fund transfer operation instruction to operate the co-managed account and sending it to the bank; and generating transaction details including transaction status based on the execution result of the fund transfer operation instruction at the bank, and synchronizing it with the event organizer, regulator, and platform.

[0008] Optionally, generating the electronic regulatory agreement defining the roles and responsibilities of the event organizer, regulator, bank, and platform includes: verifying the compliance of the event materials included in the event regulatory request and generating a verification result; when the verification result is passed, calling the agreement template and filling in the business data of the event materials to generate an agreement text to be signed; digitally signing the agreement text to be signed to generate the electronic regulatory agreement defining the roles and responsibilities of the event organizer, regulator, bank, and platform.

[0009] Optionally, the bank opening a co-managed account with the attribute of receiving but not paying includes: parsing the account opening requirements in the electronic supervision agreement and generating an account opening instruction containing authorization information from the platform and the regulator; the bank receiving and verifying the validity of the account opening instruction and generating an internal account opening certificate; based on the internal account opening certificate, the bank creating a settlement account under the platform's name and configuring control parameters such as limiting fund transfer channels, prohibiting interbank transfers, and prohibiting the sale of payment vouchers, thus forming a co-managed account with the attribute of receiving but not paying.

[0010] Optionally, generating a project ledger associated with the co-managed account based on the event identifier in the deposit request includes: extracting event information and deposit amount from the deposit request to generate basic project data; binding the basic project data with the co-managed account to generate a ledger record to be initialized; and writing the initial funding status and event supervision stage into the ledger record to be initialized to generate a project ledger associated with the co-managed account.

[0011] Optionally, the method further includes: after receiving the payment completion event signal, starting a timer and monitoring the project ledger to receive the remaining full amount of bonus within the timer period, and generating a full payment receipt indicator.

[0012] Optionally, the step of generating an approval message to be approved and sending it to the regulatory authority's approval interface includes: parsing the fund transfer request corresponding to the project ledger, extracting the payee's account information and the transfer amount, and generating transfer details data; binding the transfer details data with the event information in the project ledger to generate a payment instruction data packet; and encapsulating the payment instruction data packet into a message format that conforms to the regulatory authority's corporate online banking or bank-enterprise direct connection system interface specifications to generate an approval message to be approved and send it to the regulatory authority's approval interface.

[0013] Optionally, the step of generating a fund transfer operation instruction for operating the co-managed account and sending it to the bank includes: receiving and verifying the user number, password, or identity certificate in the approval instruction, and generating an approval confirmation receipt; based on the approval confirmation receipt, parsing the authorized payee account and amount from the approval instruction, and generating payment core elements; encapsulating the payment core elements into an electronic payment instruction format, generating a fund transfer operation instruction for operating the co-managed account and sending it to the bank.

[0014] Optionally, generating transaction details including transaction status includes: receiving the execution result returned by the bank containing changes in account balance, and generating the original transaction flow; extracting the transaction status, payee information, and account balance from the original transaction flow to generate structured transaction data; and formatting the structured transaction data according to the email synchronization method agreed upon in the electronic supervision agreement to generate transaction details including transaction status.

[0015] Optionally, the method further includes: monitoring funds transferred into the co-managed account; when it is identified that the funds fail to match the project ledger, generating an unsuccessfully cleared fund identifier; for funds with the unsuccessfully cleared fund identifier, the platform generates a return instruction to the original payment method without regulatory approval; and the bank executes the return instruction to return the funds to the payer's account.

[0016] Based on the same inventive concept, this invention also provides a multi-party approval-based event deposit supervision system, including an agreement formulation module for obtaining event supervision requests submitted by the event organizer, and generating an electronic supervision agreement defining the roles and responsibilities of the event organizer, regulator, bank, and platform based on the event supervision request and agreement generation rules; an account management module for parsing the account opening requirements in the electronic supervision agreement, generating an account opening instruction and sending it to the bank, whereby the bank opens a co-managed account with a deposit-only attribute; and a deposit supervision module for receiving deposit requests from the event organizer and depositing the deposit funds into the co-managed account. Simultaneously, a project ledger associated with the co-managed account is generated based on the event identifier in the deposit request; a fund transfer approval module is used to receive fund transfer requests corresponding to the project ledger after the event is completed, generate an approval message to be approved and send it to the regulator's approval interface; an approval instruction execution module is used to receive the approval instruction returned by the regulator for the approval message, generate a fund transfer operation instruction to operate the co-managed account and send it to the bank; a transaction synchronization module is used to generate transaction details including transaction status based on the execution result of the fund transfer operation instruction at the bank, and synchronize it to the event organizer, regulator and platform.

[0017] Compared with the prior art, the present invention has the following advantages:

[0018] This invention ensures the security of the margin deposit by constructing a fund pool that emphasizes both physical and logical isolation. By opening a co-managed account with a bank that only receives funds and does not disburse them, and by configuring strict restrictions on outflow channels, physical isolation between the margin deposit and the parties' own funds is achieved. Simultaneously, establishing an independent project ledger for each event ensures a clear accounting of funds for different projects, reducing the risk of misappropriation or confusion of funds.

[0019] This invention automates and enables highly efficient collaboration throughout the entire margin supervision process. From the automatic generation of electronic supervision agreements to the standardized packaging of fund transfer applications, the automatic parsing and execution of approval instructions, and the real-time synchronization of transaction information, the entire business loop is driven by the system. This reduces manual intervention, avoids delays and errors caused by information transmission and manual operations, and improves the overall operational efficiency of margin management.

[0020] This invention establishes a transparent and traceable multi-party oversight mechanism, enhancing the credibility of the regulatory system. All operations are based on legally binding electronic oversight agreements. Every inflow and outflow of funds undergoes a pre-defined approval process, and complete transaction details are synchronized in real-time to all relevant parties, ensuring information symmetry and transparency. This end-to-end traceability design provides clear audit trails for all parties, strengthens their responsibilities, and builds a trustworthy collaborative working environment.

[0021] Other features and advantages of the invention will be set forth in the description which follows, and will be apparent in part from the description, or may be learned by practicing the invention. The objects and other advantages of the invention may be realized and obtained by means of the structures pointed out in the description, claims and drawings. Attached Figure Description

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

[0023] Figure 1 This is a flowchart illustrating a method for supervising event deposits based on multi-party approval, according to an embodiment of the present invention.

[0024] Figure 2 This is a flowchart illustrating the automated generation process of electronic regulatory protocols according to an embodiment of the present invention.

[0025] Figure 3 This is a schematic diagram of the structure of a competition deposit supervision system based on multi-party approval according to an embodiment of the present invention. Detailed Implementation

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

[0027] Reference Figure 1 One embodiment of the present invention proposes a method and system for supervising event deposits based on multi-party approval. It adopts technical means such as building electronic agreements through the platform system, opening a joint bank account, establishing a project ledger, and automating the processing of approval and payment instructions, which can realize automated, secure and transparent supervision of the entire deposit process.

[0028] The method described in this embodiment specifically includes:

[0029] S1. Obtain the event supervision request submitted by the event organizer, and generate an electronic supervision agreement that defines the roles and responsibilities of the event organizer, regulator, bank and platform based on the event supervision request and the agreement generation rules.

[0030] Optionally, the generation of the electronic regulatory agreement defining the roles and responsibilities of the event organizer, regulator, bank, and platform includes:

[0031] The compliance verification of the event information included in the event supervision request is performed, and a verification result is generated;

[0032] When the verification result is passed, the protocol template is invoked and the business data of the event information is filled in to generate the protocol text to be signed;

[0033] The agreement text to be signed is digitally signed to generate an electronic regulatory agreement that defines the roles and responsibilities of the event organizer, regulator, bank, and platform.

[0034] Specifically, such as Figure 2 As shown, the process first performs compliance verification on the event materials included in the event supervision request. Event materials are a series of documents and data submitted by the event organizer to apply for deposit supervision, such as event approval documents, organizer qualification certificates, event plans, budget details, and deposit amounts. Compliance verification is a set of rules that, based on relevant national laws and regulations, industry regulatory requirements, and the platform's own risk control strategies, verifies the authenticity, completeness, and compliance of the event materials item by item, ultimately generating a verification result. This verification result can be represented by a logical function. express:

[0035] ,

[0036] in, The complete collection of event data submitted on behalf of the event organizers. This represents a pre-defined set of compliance verification rules. Representative verification algorithm, This represents the validation result, with a value of either pass or fail. The validation result is valid only if the validation result is... Upon successful approval, the process automatically enters the agreement text generation stage, invoking a standard agreement template pre-stored in the database. This template is a semi-structured document containing a fixed framework of general legal clauses, business process descriptions, and the rights and obligations of all parties required for regulatory agreements, while reserving placeholders for filling in specific business data. Subsequently, key business data, such as the event name, the full names of the event organizers and regulators, the determined deposit amount, and contact information of all parties, is extracted from the verified event materials and precisely filled into the corresponding placeholders in the agreement template, dynamically generating a draft agreement text for this event. Finally, the draft agreement text is digitally signed to solidify it and give it legal effect. Digital signatures are an electronic signature technology that ensures the integrity of the agreement content and the authenticity of the signatories' identities, preventing repudiation. The draft agreement text is then pushed sequentially or simultaneously to the authorized representatives designated by the event organizers, regulators, banks, and platform through a secure interface or online signing portal. Each party uses its unique digital certificate or key to encrypt the hash value of the agreement text, completing the signing. Once the digital signatures of all signatories are embedded in the agreement text, an electronic regulatory agreement is finally formed that defines the roles and responsibilities of the four parties.

[0037] For example, an event organizer plans to hold a pigeon racing competition. It submits a competition supervision request to an industry regulatory body through a competition deposit supervision platform. The request includes relevant approvals, the organizer's legal entity qualification certificate, a detailed competition plan, and a prize budget of one million units. Upon receiving the request, the platform system first performs a compliance verification of the competition materials. This process is represented by a logical function V. Since all materials meet the requirements in this verification, the verification result V is passed. After successful verification, the system automatically calls a pre-stored agreement template. Next, the system extracts business data from the verified competition materials, such as the competition name "a certain pigeon racing competition," and accurately fills the full names of the organizer, regulator, bank, and platform, as well as the confirmed deposit amount, into the reserved positions in the agreement template, thereby dynamically generating a pre-signed agreement text for this competition. Finally, this pre-signed agreement text is pushed to the authorized representatives of each of the four parties through the platform's online signing portal. Each representative uses their exclusive digital certificate to encrypt the hash value of the agreement text to complete the signature. After all digital signatures from the signatories were successfully embedded in the agreement text, an electronic regulatory agreement defining the roles and responsibilities of the four parties was officially generated. This method automates, standardizes, and ensures compliance in the generation of event deposit regulatory agreements, providing clear, credible, and binding behavioral guidelines for all subsequent processes such as joint deposit management and fund transfer approval, thereby building a secure, transparent, and efficient foundation for multi-party collaborative supervision.

[0038] S2. Parse the account opening requirements in the electronic supervision agreement, generate an account opening instruction and send it to the bank, and the bank opens a co-management account with the attribute of only receiving and not paying.

[0039] Optionally, the co-managed account opened by the bank with the characteristic of only receiving and not paying includes:

[0040] Parse the account opening requirements in the electronic supervision agreement to generate an account opening instruction containing authorization information from both the platform and the regulator;

[0041] The bank receives and verifies the validity of the account opening instruction and generates an internal account opening certificate;

[0042] Based on the aforementioned internal account opening voucher, the bank creates a settlement account under the platform's name and configures control parameters such as restricting fund transfer channels, prohibiting interbank transfers, and prohibiting the sale of payment vouchers, thus forming a co-managed account with the attribute of only receiving but not paying.

[0043] Specifically, the process begins by parsing the electronic supervision agreement and automatically extracting the core requirements for account opening. Subsequently, an account opening instruction is generated, which is a structured data packet whose content strictly adheres to the interface specifications agreed upon with the bank. The core of this instruction is establishing the co-management nature of the account, and its data structure can be represented as follows:

[0044] ,

[0045] in, This represents the final account opening instruction; It is the sole legal entity identifier of the platform registered with the bank; This is the platform's authorization information for this operation, such as its institutional digital certificate or API key, which is used by the bank to verify the legitimacy of the instruction's source; It is the regulatory authority authorization information parsed from the electronic regulatory agreement, which includes the regulatory authority's institutional name, social credit code, and role identifier in the subsequent approval process. This information is the technical prerequisite for realizing the co-management function. These are the specific requirements for opening the account, including the account type (corporate settlement account), currency, etc. After receiving the account opening instruction, the bank's system first conducts a rigorous verification. The verification includes... To verify the validity of the instruction, confirm that it comes from a legitimate platform and check the instruction itself. The overall data format and business logic must conform to the specifications. After verification, the bank's system automatically generates an internal account opening voucher, which serves as the internal basis for its core system to execute the account opening operation. Next, based on this internal account opening voucher, the bank's system creates a new settlement account under the platform's legal entity name. To achieve the aforementioned attributes, the bank needs to configure a series of special control parameters for this account to establish its "receive only, no payout" attribute. These control parameters include, but are not limited to: First, limiting fund transfer channels, i.e., setting that the funds in this account can only be used for external payments through a unique bank-enterprise direct connection or API channel connected to the platform, and must meet subsequent multi-party approval conditions, thereby closing all other conventional transfer paths such as counters, online banking, and ATMs. Second, prohibiting interbank transfers, this setting prevents the funds in this account from being withdrawn as cash at any bank branch or redeemed through other banks' bills, locking in the electronic form of funds. Third, prohibiting the sale of payment vouchers, i.e., prohibiting the use of funds in this account to purchase payment vouchers such as bank drafts and promissory notes, limiting the possibility of funds flowing out in the form of vouchers. By configuring the above control parameters, a co-managed account that functionally only allows funds to be deposited but not freely withdrawn is created. The account is opened in the name of the platform, but the ownership of the funds in the account belongs to the event organizer, while the control of the account is actually jointly held by the platform and the regulator.

[0046] For example, after the electronic supervision agreement generated for a "pigeon racing competition" takes effect, the system immediately parses the requirements for opening a co-managed account in the agreement. Based on this, the system generates an account opening instruction and sends it to the bank through a secure direct bank-enterprise connection. Upon receiving the instruction, the bank's system first verifies the validity of the authorization information, confirming that the instruction comes from a legitimate platform. After successful verification, the bank's system automatically generates an internal account opening voucher. Subsequently, the bank's core system creates a new settlement account under the platform's legal representative's name based on this voucher. The bank system configures a series of special control parameters for this account, establishing its "receive-only, no-payment" attribute. Thus, a co-managed account that functionally only allows fund deposits and not free withdrawals is created. This method ensures the independence and security of the margin funds from the underlying structure of the account, achieving physical and systemic isolation between the race margin and the race organizer's and platform's own operating funds, reducing the risk of fund misappropriation. By embedding the authorization information of the platform and the regulator at the account opening stage and configuring strict payment control parameters, it lays the foundation for subsequent multi-party approval processes.

[0047] S3. Receive the deposit request from the event organizer and deposit the deposit funds into the co-managed account. At the same time, generate a project ledger associated with the co-managed account based on the event identifier in the deposit request.

[0048] Optionally, generating a project ledger associated with the co-managed account based on the event identifier in the deposit request includes:

[0049] Extract the event information and deposit amount from the deposit request to generate basic project data;

[0050] Bind the project's basic data to the co-managed account to generate ledger records to be initialized;

[0051] Write the initial funding status and event supervision stage into the ledger record to be initialized, and generate a project ledger associated with the co-managed account.

[0052] Specifically, the process begins by extracting key information from the deposit request initiated by the event organizer to generate basic project data. Once a deposit is successfully deposited into the escrow account, the bank notifies the platform of a transaction receipt, which typically includes the payer's information, the amount, and a unique event identifier filled in by the event organizer in the transfer remarks. This event identifier is captured and used as an index to query the platform's database for complete event information archived during the agreement signing phase, such as the full event name, organizer details, and the agreed-upon total deposit amount. The extracted deposit amount is combined with the retrieved static event information to form structured basic project data. Subsequently, a binding operation is performed to associate the basic project data with the escrow account opened by the bank, generating a pending ledger record. This "binding" is a logical data-level association process, not an operation on the bank account itself; it creates a new record in the project ledger data table. This new record explicitly links the primary key event identifier of the basic project data to the escrow account number through fields. At this point, this ledger record is merely a framework, establishing "which event" has its funds deposited in "which physical account," but it hasn't yet recorded the specific fund status; therefore, it's called a ledger record to be initialized. The final step is to initialize this uninitialized ledger record to generate the final project ledger. Two core initial status information are written into this record. The first is the initial fund status, which records the amount of the deposited guarantee as the initial balance of the project ledger, along with the deposit time. The second is the event monitoring stage; according to the business process, the monitoring status of the event is updated to the preset initial stage, such as "guarantee deposited" or "monitoring activated." After this step, a complete project ledger is generated. This project ledger can be represented by a data structure L.

[0053] ,

[0054] in, It is the event logo; It contains the project's basic data, including detailed information about the event; It is the account number of the escrow account; This represents the current cash status of the ledger, with its initial value being the amount of margin deposited this time. This indicates the current stage of event supervision.

[0055] For example, a race organizer deposits an initial security deposit of 300,000 units into a newly opened escrow account, noting the unique race identifier "EVENT202501" in the transfer remarks. After the funds arrive, the bank notifies the platform of the transaction receipt. The system captures this race identifier and uses it as an index to query the database for complete race information for the pigeon racing event. It then combines this with the deposited security deposit amount to form the project's basic data. Subsequently, a new record is created in the project ledger data table, logically associating the race identifier "EVENT202501" with the escrow account number through data fields, generating a ledger record to be initialized. This signifies that the race's funds are now legally linked to the physical account. Finally, the system initializes this record, writing core status information. It records the initial fund status as 300,000 units and updates the race supervision stage to "Security deposited." At this point, a complete project ledger L is generated. This method creates a dedicated electronic ledger, or project ledger, for the security deposit of each event, achieving "logical isolation" of funds. This ensures that the security deposits of different events will not be confused in the accounting, and provides an accurate and unique basis for subsequent fund transfers, balance inquiries and audits for specific events.

[0056] Optionally, the method further includes:

[0057] Upon receiving the payment completion event signal, a timer is started and the project ledger is monitored to ensure that the remaining full amount of bonus is received within the timer period, generating a full payment receipt indicator.

[0058] Specifically, this process is triggered by a clearly defined payment completion event signal. This signal is automatically generated based on the pre-set registration deadline in the project ledger, or triggered by an external ticketing system via an interface call after ticket sales have ended, marking the start of the window period for the event organizer to pay the remaining full prize money. Once the platform receives this signal, it will start a timer with a preset period for the project ledger associated with that signal. This timer period, i.e., the grace period for prize money replenishment, is agreed upon in advance by the relevant clauses in the electronic supervision agreement. During the timer's running period, the platform will continuously monitor the fund inflow activities of the co-managed account linked to the project ledger. Newly matched funds to the project ledger will be added to the current balance of the ledger in real time. At the same time, a verification logic will be executed, which can be expressed as:

[0059] C ≥ T,

[0060] Here, C represents the total amount of funds currently received in the project ledger. This value is obtained by the system in real-time summarizing all incoming transaction amounts associated with this ledger. T represents the total amount of full prize money payable for the event as stipulated in the electronic supervision agreement. This value is stored as a fixed parameter when the project ledger is created. If the above condition is met before the timer period ends, i.e., the funds received are greater than or equal to the full prize money payable, the funds are considered to have been fully received. At this time, a full receipt flag is automatically generated and updated in the project ledger record, for example, the ledger status field is updated from "Pending Prize Money" to "Prize Money Fully Received," and the timer stops running. If the condition is not met by the end of the timer period, a corresponding warning flag will be generated, and a notification mechanism may be triggered.

[0061] For example, taking a pigeon racing competition as an example, its project ledger has a preset registration deadline, and the electronic supervision agreement clearly stipulates that the competition organizer must replenish the total prize money to one million units within seven working days after the registration deadline. When the platform system detects through background task polling that the current business date has reached the preset registration deadline for the competition, it automatically generates a payment completion event signal. Upon receiving this signal, the system immediately starts a timer for the project ledger with the competition identifier "EVENT202501", with a period set to seven working days. When the timer starts, the system checks that the current total amount of funds received in the project ledger, C, is 300,000 units, while the total prize money T payable under the agreement is one million units. On the third working day of the timer's operation, the platform system monitors an inflow of 700,000 units and successfully matches it with the project ledger through the competition identifier "EVENT202501" in the transaction remarks. The system then performs a fund accumulation operation, updating the total amount C of funds already received in the project ledger to one million units. At this point, the system automatically executes the verification logic C ≥ T, confirming that the funds have been fully received. The system then updates the status field in the project ledger's data record from "Pending Bonus Payment" to "Bonus Payment Fully Received," thereby generating a full fund receipt indicator and sending a command to the timer module to stop the timing task for this project ledger. This method, by introducing time-dimensional monitoring, transforms static fund records into a dynamic compliance management tool, ensuring that the event organizers can fulfill their funding commitments on time. This proactive risk management mechanism can promptly identify and pinpoint potential issues of insufficient funding, providing regulators with a window of opportunity for intervention and handling, thereby protecting the core interests of participants and winners and enhancing the reliability and credibility of the entire event guarantee fund supervision system.

[0062] S4. After the event is completed, receive the fund transfer request corresponding to the project ledger, generate an approval message to be approved and send it to the regulatory authority's approval interface.

[0063] Optionally, the approval interface for generating the approval message to be approved and sending it to the regulator includes:

[0064] Analyze the fund transfer requests corresponding to the project ledger, extract the payee's account information and the transfer amount, and generate transfer details data;

[0065] The transfer details data are linked with the event information in the project ledger to generate a payment instruction data package;

[0066] The payment instruction data packet is encapsulated into a message format that conforms to the interface specifications of the regulator's corporate online banking or bank-enterprise direct connection system, and an approval message pending approval is generated and sent to the regulator's approval interface.

[0067] Specifically, the process begins by parsing the fund transfer request corresponding to the project ledger. This request is initiated by the event organizer after the event concludes, aiming to transfer part or all of the security deposit to a designated recipient, such as a supplier, winner, or return it to the organizer. Through parsing, the core elements of the transfer are extracted: the recipient's account information and the specific transfer amount. These two elements together constitute the transfer details data. Next, this transfer details data is bound to the event information recorded in the project ledger corresponding to the request. This binding operation combines objective payment data with the business context of the payment. Using the event identifier in the fund transfer request, the corresponding project ledger is retrieved from the database, and key event information such as the event name and organizer information is read. Then, the transfer details data and this event information are integrated into a logically complete payment instruction data packet. The structure of this data packet can be represented as follows:

[0068] ,

[0069] in, Represents a payment instruction data packet; It is the transfer details data obtained by parsing fund transfer requests, which includes the recipient's account information and the transfer amount; The event information, obtained from the project ledger, provides the business background for this transfer. This data packet fully answers the three core approval questions: "To whom to pay," "How much to pay," and "Why to pay." The final step is encapsulation and transmission. The internally formatted payment instruction data packet is converted into a message format that the regulatory system can receive and parse. This typically means adhering to the interface specifications of the corporate online banking or bank-enterprise direct connection system used by the regulator, which may require data in XML, JSON, or other specific message formats. The payment instruction data packet P is encapsulated into a message body conforming to this specification, and may include a message header, digital signature, or encryption, ultimately generating an approval message awaiting approval. This message is sent to the approval interface designated by the regulator through a pre-configured secure network channel.

[0070] For example, after a pigeon racing competition concludes, the organizer applies through the platform to award a prize to a winning member. The platform receives this fund transfer request corresponding to project ledger "EVENT202501". The system first parses the request, extracting the recipient's account information and the specific transfer amount, generating detailed transfer data. Next, the system binds this detailed transfer data with the competition information. It uses the competition identifier to read background information such as the competition name from the project ledger, and then integrates the detailed transfer data with this competition information into a payment instruction data packet. This data packet completely answers the three core approval questions: to whom, how much, and why. Finally, the system encapsulates this internally formatted data packet into a JSON message format conforming to the corporate online banking system interface specifications used by regulators, digitally signs it, and ultimately generates an approval message awaiting approval. This message is sent to the regulator's approval interface through a secure network channel and appears as an approval task in their corporate online banking pending items. This method seamlessly integrates the application for the transfer of event security deposits into the existing approval workflow of regulators, acting as a converter between business language and financial system language. It automatically and in a standardized manner transforms payment requests originating from the business side into approval tasks that regulators are familiar with and can directly process, providing regulators with sufficient decision-making basis and ensuring informed and prudent approval.

[0071] S5. Receive the approval instruction returned by the regulator in response to the approval message, generate a fund transfer operation instruction for operating the co-managed account, and send it to the bank.

[0072] Optionally, the step of generating and sending the fund transfer operation instruction for operating the co-managed account to the bank includes:

[0073] Receive and verify the user number, password, or identity credential in the approval instruction, and generate an approval confirmation receipt;

[0074] Based on the approval confirmation receipt, the payee account and amount authorized for payment are parsed from the approval instruction to generate the core elements of payment;

[0075] The core payment elements are encapsulated into an electronic payment instruction format, and a fund transfer operation instruction for operating the co-managed account is generated and sent to the bank.

[0076] Specifically, the process begins with receiving and verifying the approval instruction returned from the regulatory approval interface. This instruction is a receipt generated by the regulator after processing a pending message in the company's online banking or bank-enterprise direct connection system. It contains the approver's username, password, or more secure identity credentials, such as the approver's digital certificate signature. These credentials are rigorously verified to confirm that the approval instruction indeed originates from a regulatory personnel with the appropriate permissions as stipulated in the electronic regulatory agreement. Upon successful verification, an approval confirmation receipt is generated. This receipt serves both as a response to the regulatory system and as an internal audit log, recording the confirmation time and validity of the approval operation. After confirming the legality of the approval instruction, the core information of the authorized payment is extracted from the data body of the approval instruction based on this confirmation receipt. Since this approval instruction is a response to the pending message previously sent by the platform, its content is essentially a confirmation of the original payment instruction data packet. Therefore, the core elements of the authorized payment can be accurately extracted from it, namely the clearly defined payee account, payee name, and authorized transfer amount. Finally, these core payment elements are encapsulated into an electronic payment instruction format that can be recognized and executed by the bank's core system. This encapsulation process follows the pre-agreed direct bank-enterprise connection or API interface specifications between the platform and the bank, organizing the core payment elements into a structured message. This message is the instruction used to operate the fund transfer of the co-managed account. The generation process of this instruction can be represented by a function.

[0077] ,

[0078] in, This represents the final generated fund transfer operation instruction; It is a wrapper function that represents the process of formatting according to the bank's interface specifications; It is the payee's account parsed from the approval instruction; It is the name of the payee; This is the amount authorized for transfer; This represents a specific electronic payment instruction format required by the bank. Once generated, this fund transfer instruction is sent to the bank via a secure communication link, triggering the bank's system to execute the actual fund transfer from the designated escrow account.

[0079] For example, the head of an industry regulatory agency logs into their corporate online banking system, verifies the bonus disbursement approval task, and clicks "agree" using their digital certificate. The system immediately receives an approval instruction from the bank's corporate online banking system, which includes the approver's user ID and a signature encrypted with their digital certificate. The platform first verifies the digital signature to confirm that the approval instruction indeed originates from the regulatory personnel agreed upon in the agreement. After successful verification, the system generates an approval confirmation receipt as an internal audit log. Based on this confirmation, the system parses the authorized payment core elements from the approval instruction, namely the clearly defined payee account and the authorized transfer amount. Finally, the system encapsulates these payment core elements into an electronic payment instruction format that can be recognized and executed by the bank's core system. This generated fund transfer operation instruction is sent to the bank via a secure communication link, directly triggering the bank's system to execute the actual fund transfer from the co-managed account. This method reduces the possibility of forged or unauthorized payments by setting up strict identity verification procedures, ensuring the compliance and security of fund transfers. It achieves seamless connection and automatic flow from business application to regulatory approval and then to the execution of financial transactions. This not only improves the efficiency of fund disposal, but more importantly, it solidifies the regulator's final decision-making power through technical means, reflecting the core principle of multi-party co-management.

[0080] S6. Based on the execution result of the fund transfer operation instruction at the bank, generate transaction details information including transaction status and synchronize it to the event organizer, regulator and platform.

[0081] Optionally, generating transaction details information including transaction status includes:

[0082] Receive the execution results from the bank, which include changes in the account balance, and generate the original transaction log.

[0083] Transaction status, payee information, and account balance are extracted from the original transaction logs to generate structured transaction data;

[0084] The structured transaction data is formatted according to the email synchronization method agreed upon in the electronic supervision agreement to generate transaction details information including transaction status.

[0085] Specifically, the process begins by receiving the execution result from the bank. This result is a message containing information about changes in the account balance, recording whether the fund transfer operation was successful or failed, and the exact balance of the co-managed account after the operation. This original message is stored completely and without modification in a log or database to generate the original transaction log, serving as the most direct and auditable evidence. Next, structured transaction data is extracted and generated from this original transaction log. The original transaction log is typically designed for machine readability and may have a complex format. Therefore, a parsing program is used to parse the original transaction log according to the interface protocol agreed upon with the bank, extracting key fields meaningful to all parties, including transaction status, payee information, and the account balance after the transaction. This extracted and standardized data constitutes the structured transaction data. Finally, this structured transaction data is formatted according to the method agreed upon in the electronic supervision agreement to generate the final transaction details. When signing the electronic supervision agreement, all parties agreed on the method of information synchronization, such as notification via email. The agreement specifies the email subject format, body template, and recipient list. By calling this template, the transaction status, recipient information, transfer amount, account balance, and other data from the structured transaction data are filled into the corresponding positions in the template to generate a clear and uniformly formatted email body. This generation process can be represented by the following function:

[0086] ,

[0087] in, This represents the final generated transaction details, including the transaction status. Represents a formatting function; It is structured transaction data; It is a template for a pre-agreed synchronization method obtained from the electronic supervision agreement, such as an email template. Once generated, the transaction details will be automatically sent to all relevant parties specified in the agreement.

[0088] For example, after a bank successfully transfers a prize, the system receives an execution result message from the bank. This message records the success status of the operation and the exact balance of the co-managed account after the operation. The system stores this original message in its entirety in the log, generating the original transaction record. Then, a parsing program starts, extracting the transaction status, payee information, and post-transaction account balance from the original transaction record to generate structured transaction data. Finally, according to the email synchronization method agreed upon in the electronic supervision agreement, the system calls an email template, fills in this structured transaction data, generates a clear and uniformly formatted email body—the final transaction details—and automatically sends it to all relevant parties specified in the agreement, including the event organizer, regulator, and platform. This method not only provides all parties with real-time fund dynamics but also leaves a clear and irrefutable electronic record for subsequent account reconciliation and auditing, further strengthening the security and reliability of the entire event deposit supervision system.

[0089] Optionally, the method further includes:

[0090] The system monitors the funds transferred into the co-managed account and generates a fund unsuccessfully distributed flag when it detects that the funds fail to match the project ledger.

[0091] For funds marked with the aforementioned "unsuccessfully cleared funds" identifier, the platform will generate a return instruction to the original payment method without regulatory approval.

[0092] The bank will execute the original return instruction and return the funds to the payer's account.

[0093] Specifically, to ensure the purity of funds in the co-managed account and the accuracy of accounting, this method establishes an automated processing mechanism for abnormal incoming funds. The platform continuously monitors the flow of all funds transferred into the co-managed account. When the bank synchronizes a new incoming transaction via an interface, the platform immediately initiates a matching process. This process parses the remarks or notes of the incoming transaction, attempting to extract a competition identifier corresponding to a certain created project ledger. If a valid competition identifier cannot be found, or if the extracted identifier does not match any existing project ledger, the funds are determined to be unsettled funds. At this time, an unsettled fund identifier is generated on the transaction record of the funds, for example, marking its status as "pending return" in the database. After identifying funds with an unsettled fund identifier, the platform, either automatically or through its operations personnel in the background, generates a return instruction that does not require regulatory approval. The special feature of this instruction is that it bypasses the conventional fund transfer approval module that requires regulatory approval. The generation logic is as follows: it directly references the original deposit information of the unsuccessfully cleared funds, automatically sets the original payer's account information as the payee's account information for this refund, and sets the refund amount to the original deposit amount. This generated instruction is essentially an administrative correction operation, rather than a regulated business fund transfer, thus exempting it from regulatory approval in its process design. Ultimately, the platform sends this special original-path refund instruction to the bank through a direct bank-enterprise connection. Upon receiving the instruction, the bank verifies that the source of the instruction is the legitimate platform and executes the payment. Because this operation is defined as a refund or internal accounting adjustment, the bank system, based on preset account permission configurations, allows the funds to be transferred without regulatory approval. After the bank executes the original-path refund instruction, the unsuccessfully cleared funds will be accurately returned to the original payer's account, thereby completing the clearing of abnormal funds.

[0094] For example, during a business cycle for supplementing prize money for a pigeon racing competition, a participating member mistakenly transferred a registration fee of 5,000 units directly to a co-managed account used to hold the competition's security deposit, incorrectly writing the competition identifier as "EVNET202501" in the transfer remarks. The bank synchronized the electronic receipt of this transaction to the platform via the bank-enterprise direct connection interface. Upon receiving the receipt, the platform's fund clearing service immediately initiated a matching process. This process parsed the transaction remarks field and extracted the string "EVNET202501" as the competition identifier to be matched. The process used this identifier to perform an index query on the project ledger data table. Since the correct competition identifier should be "EVNET202501", the query returned no results. Therefore, the system determined that the 5,000 units of funds were unsettled funds and immediately generated an unsettled fund identifier on the transaction record, updating its status field to "pending return," and simultaneously pushing the record to the abnormal fund queue managed in the backend. The platform's operations staff accessed the operations management interface, viewed this pending record in the queue, verified the situation, and clicked the "Refund to Original Payment Method" button, triggering the refund operation. The system responded by automatically generating a refund instruction that did not require regulatory approval. The instruction's generation logic involved retrieving the payer's account name and number from the original transaction log of the abnormal inflow and filling them into the payee field of the refund instruction, while setting the refund amount to the original inflow amount of 5,000 units. After being signed by the platform's internal signature module, the instruction was sent to the bank via a direct bank-enterprise connection. After verifying the source and signature of the instruction, the bank's system, based on preset account permission configurations, directly executed the transfer operation, returning the 5,000 units of funds from the co-managed account to the payer's original account, thus completing the cleanup of the abnormal funds. This method enhances the robustness and automation of the margin supervision system by introducing an automatic closed-loop system for identifying and clearing abnormal funds. It resolves the issue of funds being unattributable due to user errors, ensuring that every sum in the account clearly corresponds to a specific supervised project and maintaining clear and accurate accounting. Furthermore, by designing a refund path that requires no regulatory approval, it separates business supervision from administrative error handling, improving processing efficiency and reducing unnecessary manual intervention burdens on both the platform and regulators, ensuring a focused and efficient supervision process.

[0095] Based on the same inventive concept, such as Figure 3 As shown, the present invention also provides a competition deposit supervision system based on multi-party approval, the system comprising:

[0096] The agreement formulation module is used to obtain the event supervision request submitted by the event organizer, and generate an electronic supervision agreement that defines the roles and responsibilities of the event organizer, regulator, bank and platform based on the event supervision request and the agreement generation rules.

[0097] The account management module is used to parse the account opening requirements in the electronic supervision agreement, generate an account opening instruction and send it to the bank, and the bank opens a co-managed account with the attribute of only receiving and not paying.

[0098] The deposit supervision module is used to receive deposit requests from the event organizers, deposit the deposit funds into the co-managed account, and generate a project ledger associated with the co-managed account based on the event identifier in the deposit request.

[0099] The fund transfer approval module is used to receive fund transfer requests corresponding to the project ledger after the event is completed, generate approval messages to be approved and send them to the regulatory authority's approval interface.

[0100] The approval instruction execution module is used to receive the approval instruction returned by the regulator in response to the approval message, generate a fund transfer operation instruction for operating the co-managed account, and send it to the bank.

[0101] The transaction synchronization module is used to generate transaction details information including transaction status based on the execution result of the fund transfer operation instruction at the bank, and synchronize it to the event organizer, regulator and platform.

[0102] It should be noted that the electrical connections between the various units described above do not necessarily represent direct or indirect connections. Any indirect connection method can be applied to the embodiments of the present invention as long as it achieves the purpose of the present invention. The above descriptions are merely exemplary embodiments of the present invention and should not be construed as limiting the scope of the present invention.

[0103] All equivalent changes and modifications made in accordance with the teachings of this invention are still within the scope of this invention. Those skilled in the art will readily conceive of other embodiments of this invention upon considering the specification and the disclosure of practical truth. This application is intended to cover any variations, uses, or adaptations of this invention that follow the general principles of this invention and include common knowledge or conventional techniques in the art not described herein.

Claims

1. A method for supervising event deposits based on multi-party approval, characterized in that, The method includes: Obtain the event supervision request submitted by the event organizer, and generate an electronic supervision agreement that defines the roles and responsibilities of the event organizer, regulator, bank and platform based on the event supervision request and the agreement generation rules; The account opening requirements in the electronic supervision agreement are parsed, an account opening instruction is generated and sent to the bank, and the bank opens a co-managed account with the attribute of only receiving and not paying. Receive the deposit request from the event organizer and deposit the deposit funds into the co-managed account. At the same time, generate a project ledger associated with the co-managed account based on the event identifier in the deposit request. After the event is completed, a fund transfer request corresponding to the project ledger is received, and an approval message pending approval is generated and sent to the regulatory authority's approval interface. Upon receiving the approval instruction returned by the regulator in response to the approval message, generate a fund transfer operation instruction for operating the co-managed account and send it to the bank; Based on the execution result of the fund transfer operation instruction at the bank, transaction details including transaction status are generated and synchronized to the event organizer, regulator, and platform.

2. The method for supervising event deposits based on multi-party approval as described in claim 1, characterized in that, The electronic regulatory agreement that defines the roles and responsibilities of the event organizers, regulators, banks, and platform includes: The compliance verification of the event information included in the event supervision request is performed, and a verification result is generated; When the verification result is passed, the protocol template is invoked and the business data of the event information is filled in to generate the protocol text to be signed; The agreement text to be signed is digitally signed to generate an electronic regulatory agreement that defines the roles and responsibilities of the event organizer, regulator, bank, and platform.

3. The method for supervising event deposits based on multi-party approval as described in claim 1, characterized in that, The co-managed accounts opened by the bank that have the characteristic of only receiving but not paying include: Parse the account opening requirements in the electronic supervision agreement to generate an account opening instruction containing authorization information from both the platform and the regulator; The bank receives and verifies the validity of the account opening instruction and generates an internal account opening certificate; Based on the aforementioned internal account opening voucher, the bank creates a settlement account under the platform's name and configures control parameters such as restricting fund transfer channels, prohibiting interbank transfers, and prohibiting the sale of payment vouchers, thus forming a co-managed account with the attribute of only receiving but not paying.

4. The method for supervising event deposits based on multi-party approval as described in claim 1, characterized in that, The process of generating a project ledger associated with the co-managed account based on the event identifier in the deposit request includes: Extract the event information and deposit amount from the deposit request to generate basic project data; Bind the project's basic data to the co-managed account to generate ledger records to be initialized; Write the initial funding status and event supervision stage into the ledger record to be initialized, and generate a project ledger associated with the co-managed account.

5. A method for supervising event deposits based on multi-party approval as described in claim 4, characterized in that, The method further includes: Upon receiving the payment completion event signal, a timer is started and the project ledger is monitored to ensure that the remaining full amount of bonus is received within the timer period, generating a full payment receipt indicator.

6. The method for supervising event deposits based on multi-party approval as described in claim 1, characterized in that, The interface for generating approval messages to be approved and sending them to the regulator includes: Analyze the fund transfer requests corresponding to the project ledger, extract the payee's account information and the transfer amount, and generate transfer details data; The transfer details data are linked with the event information in the project ledger to generate a payment instruction data package; The payment instruction data packet is encapsulated into a message format that conforms to the interface specifications of the regulator's corporate online banking or bank-enterprise direct connection system, and an approval message pending approval is generated and sent to the regulator's approval interface.

7. The method for supervising event deposits based on multi-party approval as described in claim 1, characterized in that, The process of generating and sending fund transfer instructions to the bank for operating the co-managed account includes: Receive and verify the user number, password, or identity credential in the approval instruction, and generate an approval confirmation receipt; Based on the approval confirmation receipt, the payee account and amount authorized for payment are parsed from the approval instruction to generate the core elements of payment; The core payment elements are encapsulated into an electronic payment instruction format, and a fund transfer operation instruction for operating the co-managed account is generated and sent to the bank.

8. The method for supervising event deposits based on multi-party approval as described in claim 1, characterized in that, The generation of transaction details information including transaction status includes: Receive the execution results from the bank, which include changes in the account balance, and generate the original transaction log. Transaction status, payee information, and account balance are extracted from the original transaction logs to generate structured transaction data; The structured transaction data is formatted according to the email synchronization method agreed upon in the electronic supervision agreement to generate transaction details information including transaction status.

9. A method for supervising event deposits based on multi-party approval as described in claim 1, characterized in that, The method further includes: The system monitors the funds transferred into the co-managed account and generates a fund unsuccessfully distributed flag when it detects that the funds fail to match the project ledger. For funds marked with the aforementioned "unsuccessfully cleared funds" identifier, the platform will generate a return instruction to the original payment method without regulatory approval. The bank will execute the original return instruction and return the funds to the payer's account.

10. A sports event deposit supervision system based on multi-party approval, characterized in that, The system includes: The agreement formulation module is used to obtain the event supervision request submitted by the event organizer, and generate an electronic supervision agreement that defines the roles and responsibilities of the event organizer, regulator, bank and platform based on the event supervision request and the agreement generation rules. The account management module is used to parse the account opening requirements in the electronic supervision agreement, generate an account opening instruction and send it to the bank, and the bank opens a co-managed account with the attribute of only receiving and not paying. The deposit supervision module is used to receive deposit requests from the event organizers, deposit the deposit funds into the co-managed account, and generate a project ledger associated with the co-managed account based on the event identifier in the deposit request. The fund transfer approval module is used to receive fund transfer requests corresponding to the project ledger after the event is completed, generate approval messages to be approved and send them to the regulatory authority's approval interface. The approval instruction execution module is used to receive the approval instruction returned by the regulator in response to the approval message, generate a fund transfer operation instruction for operating the co-managed account, and send it to the bank. The transaction synchronization module is used to generate transaction details information including transaction status based on the execution result of the fund transfer operation instruction at the bank, and synchronize it to the event organizer, regulator and platform.

Images