CN112508708A - Block chain technology-based securitized cash flow tracking method and system - Google Patents

Abstract

The invention designs a securitized cash flow tracking method and a securitized cash flow tracking system based on a blockchain technology, which belong to the technical field of blockchain application in financial scenes, fully utilize MSPID query API of a blockchain system to verify and identify the identities of participating institutions, design a series of data objects and algorithms taking bills as the core by referring to endorsement logic of commercial drafts, simulate the process of collecting, forwarding and distributing the mapped cash flow in securitized clearing channels by the endorsement circulation of the data objects bills between the participating institutions in two states of 'on the way' and 'to account', therefore, cross-mechanism, unified, dynamic, real-time and fine tracking and monitoring of the securitized cash flow are achieved, and the technical problems of static information presentation, insufficient fine data, tampering risk, high account checking cost and the like in the securitized business are solved in one-stop mode.

Description

Block chain technology-based securitized cash flow tracking method and system

One, the technical field

The invention relates to a block chain technology-based tracking method and system with a securitized business basic asset repayment cash flow (securitized cash flow or cash flow) as a core object, and belongs to the technical field of block chain application in financial scenes.

Second, background Art

To the best of the applicant's knowledge, no tracking system exists that targets the securitized cash flow exclusively, and has a distributed computing network, distributed database as the technical core. At present, each mechanism participating in securitization business respectively and independently records the recovered fund by using a local area network database or even single-machine edition listing software only in the responsibility range of the mechanism, then the recovered fund is regularly summarized and regularly revealed, relevant information is respectively stored and respectively managed by each mechanism in a data isolated island mode, and a unified, real-time, dynamic and systematic cash flow tracking scheme which is based on a computer network and runs through multiple mechanisms is not realized.

In addition, due to the lack of a tracking system for closely tracking cash flow sources and fund attributes, data granularity related to asset pool credit in reports of securitization participation organizations is generally relatively coarse, one-to-one correspondence between reimbursed funds and basic assets is difficult to achieve, unqualified assets and bad assets are possibly difficult to screen, and trigger events related to asset pool credit settlement, such as accelerated clearing events, default events and the like, are difficult to follow and quickly react in time.

Finally, because the institutions do not perform cash flow payment operation on a unified database platform, once data among the institutions are different, account checking has to be performed in a time-consuming and labor-consuming manner, and originally, mutual supervision and mutual restriction benefit conflict relations preset by a securitization trading framework exist among participating institutions, so that more obstacles and difficulties are added to data checking and verification. The data of which party is taken as the standard, whether the data is artificially tampered or not, and whether the data is the original data formed at the first time or not can be the focus of disputes in the future.

Third, the invention

The invention fully utilizes MSPID inquiry API of a block chain system to check and identify the identity of participating institutions, designs a series of data objects and an internal algorithm taking 'bill' as a core by referring to endorsement logic of commercial draft, continuously endorses and flows the bill between different participating institutions in two states of 'on the way' and 'to account', maps and simulates the clearing and remitting process of cash flow in a securitization clearing channel, and brings source assets and fund attributes into a tracking range, the digital, cross-mechanism, unified, dynamic, real-time and fine tracking and monitoring of the securitized cash flow are further realized, the technical characteristics of block chain decentralization, no tampering, difficulty in damage, account checking preposition and the like are fully exerted, and the problems of static information presentation, insufficient fineness of data, tampering risk, high account checking cost and the like in the securitization service are solved in a one-stop mode.

1. System hardware configuration and network topology

According to the authority and the responsibility of the participating mechanism in the securitization service, the invention divides the securitization service participating mechanism related to cash flow receipt and payment into four roles:

(1) a trusted manager of securitized products ("manager");

(2) an asset service organization ("facilitator") that provides cash flow collection services;

(3) a escrow bank ("escrow bank") responsible for escrowing funds in the name of asset carriers ("SPVs"); and

(4) a securitized product investor ("investor") with full query of informed rights.

Other intermediary organizations related to securitization product recruitment, issuance, period management, clearing termination and the like can participate in the system by using an investor role, namely, only opening inquiry authority to the organizations and not opening any writing authority for creation, modification, deletion and the like, so that the organizations can acquire various service information and data stored in a block chain account book and assist the organizations in completing related tasks such as scheduling, statistics, prediction and the like which need to be completed by the organizations.

In terms of a network framework, the invention depends on a specific deployment scheme of a block chain foundation platform, and different implementation forms such as Solo, Kafka, Raft and the like can be adopted for the network framework according to different consensus mechanisms and deployment schemes adopted by sequencing nodes. In the aspects of decentralization, tamper resistance and the like, a consensus mechanism that the decentralization deployment sequencing node can be realized by adopting Raft and the like is recommended.

FIG. 1 is a simplified diagram of a network architecture of a Raft consensus mechanism. Each organization builds one or more servers which can be directly controlled physically and safely within the protection range of the internet gateway through an internal local area network, and deploys, starts and operates the basic block chain network and related services on the servers.

The server and the client of the hardware system can be classified into:

(1) sequencing nodes: providing "blockchain" out-blocking, sorting services is the core of the system to achieve consensus on blockchain accounts. Each organization can deploy and install one or more sequencing nodes, and a sequencing network is built by a proper algorithm and is managed by other organizations to provide sequencing services in a unified mode. In view of the complex relationship of mutual supervision and mutual weighing among all participating mechanisms in the securitized trading structure, the classification deployment of the sequencing nodes according to the roles is proposed, each role can control the same number of sequencing nodes to participate in consensus operation as much as possible, and the consensus strategy of the system is properly configured, so that the decentralization can be realized in a logic cycle on the level of a topological framework and the consensus strategy.

(2) And the endorsement node provides services such as intelligent contract installation, operation, block chain storage, transaction endorsement verification, state database read-write access and the like. Inside each participating mechanism, a plurality of endorsement nodes can be added into the system, information is distributed and copied among the endorsement nodes through a Gossip protocol, a single leader node submits a transaction message and receives a block message, and all endorsement nodes independently complete endorsement check calculation of alternative transactions. In consideration of system reliability and stability, each participating mechanism is recommended to be provided with at least two endorsement nodes, so that the influence on the stability of system operation caused by single machine faults is avoided.

(3) And the state database node stores the data and information of each service object. According to the internal business requirements of each mechanism, multipoint deployment can be carried out on a physical space, and a state database and endorsement nodes can be considered to be deployed on the same physical or virtual server, so that the information interaction efficiency is improved, and the risk of divulgence is reduced.

(4) The Certificate Authority node (CA node) provides identity authentication services such as Certificate issuing, verification, member role management and the like. The relevant specifications of the basic blockchain platform need to be met in the aspects of issuing and managing the root certificate and the intermediate certificate, various organizations, nodes, administrators, members, encrypted communication and the like.

(5) The Web application server provides services such as network communication, reverse proxy, regular operation and the like required by the Web application program. The proposal is arranged in the local area network of each mechanism as much as possible, thereby facilitating the internal security management of each mechanism, improving the access and operation efficiency and avoiding unnecessary data and information leakage.

(6) The Web application client is a workstation computer in a local area network, and a user can conveniently access a Web application program through a client browser, input various parameters, trigger related instructions, inquire, download and print related business certificates, receipts and reports, and realize data and information interaction between the Web application and the user by a friendly graphical interface.

For purposes of this specification and claims, the sequencing node, endorsement node, and state database node may be collectively referred to as a "blockchain service node".

The application scene of the invention has no strict requirement on the transaction time sequence of the block chain, and the basic service requirement of cash flow tracking monitoring can be met as long as all write operations such as adding, deleting and changing the state database can leave an affair log which can not be tampered on the block chain, and all service operations are ensured to be clearly marked and documented. Therefore, "decentralized" is more reflected in the characteristics of distributed storage, distributed computation, tie-up preposition and the like of the blockchain technology than in the problems related to transaction ordering and block ordering, such as "double-flower problem" and the like, for the application scenario of the present invention. Therefore, the hardware network framework of the invention can also adopt the Kafka cluster to organize the sequencing nodes and build the sequencing service, or a certain core mechanism or a third-party mechanism controls and hosts all the sequencing nodes to uniformly provide the sequencing service, and other participating mechanisms only control other nodes such as endorsement nodes, CA nodes and state databases, thereby improving the overall operation stability and throughput efficiency of the block chain system.

2. Logical layering and composition of system software

The software part of the invention is composed of four layers of relatively independent computer programs including a basic block chain system, a series intelligent contract, a Web application server and a Web application client, and specifically comprises the following steps:

(1) the block chain system: the system is a basic operation platform of the whole block chain network and provides basic block chain services such as encryption service, member identity management service, intelligent contract installation and operation service, endorsement verification service, sequencing service and the like for each distributed network node;

(2) intelligent contract: the system is a core component of the business logic, realizes the design function of each business document and business process, realizes the read-write operation of a block chain and a state database by calling a relevant interface of a specific intelligent contract, and is a software hub of the system;

(3) the Web application server is the back end part of the Web application program, the core function is to provide Web service, analyze and route the http request of the front end of the Web application to the interface of the specific intelligent contract, call the specific intelligent contract through SDK, in addition, have also realized the server functions such as user's role identity verification, route interception, encrypted communication, automatic triggering of regular program, etc.;

(4) the Web application client side: the front end part of the Web application program is the Web front end application program which is friendly, visual and graphical based on the interface of a browser, the core function is to transmit the information input by a user and a triggered request instruction to a Web application server, analyze and present the response data fed back by the Web application server on a graphical interactive interface, and integrate the data input and output functions such as Excel file uploading, downloading, page printing and the like.

As shown in fig. 2, the software framework of the invention is composed of four layers of computer programs, the Web application client is responsible for interacting data and operation instructions with users through a graphical interface, the instructions are analyzed into http requests and then transmitted to the Web application server via a reverse proxy, the Web application server routes, analyzes the related instructions and data and then calls a series of intelligent contracts, and the intelligent contracts realize various business logics and read-write operations on a block chain account book according to the preset algorithm; and all information fed back by the block chain account book is reversely ordered through the original path and is fed back to the user through the intelligent contract, the Web application server side and the Web application client side in sequence.

3. Membership management service and MSPID

In the block chain network relied on by the invention, each participating organization signs and verifies the digital certificate for the organization, the built-in department, the administrator, the user, the server node, the client and the tls encryption communication Service by a self-signed digital certificate system through the CA node controlled by the participating organization, and manages the Membership identity through the established cryptographic algorithm, encryption and decryption algorithm, signature and signature verification algorithm, namely, each organization is respectively configured with Membership identity Management Service (MSP). The basic blockchain system determines a unique identification for each participating entity during network configuration, namely 'MSPID', to identify the MSP and entity identity. Therefore, when network communication is carried out between nodes and users of different mechanisms, the block chain system can call different MSP configurations according to different MSPIDs, and signature verification and member identity verification of messages which do not need to be carried out between the mechanisms are further realized. Therefore, the MSPID can be used as an identity identifier which is unique in the blockchain network of the participating institutions and is used for verifying and identifying the identity of the institutions. The invention fully utilizes the characteristic, and realizes the verification and comparison of the identity of the main body of the participating organization by taking the MSPID as the identity of the organization in the aspects of intelligent contract invoking authority verification, bill endorsement, receipt and payment certificate signing and the like.

4. Cash flow and tracking document flow process

Figure 3 schematically illustrates the process of collection, clearing and distribution of cash flow in securitization services, and the process of digitally simulating and automatically tracking cash flow under the control of an intelligent contract by the tracking document (i.e. underlying data object) designed by the present invention. In summary, it can be divided into three stages, six steps:

4.1 clear receiving and repayment

Step one, a service provider receives payment funds from a debtor, inputs an asset number, a collection date and a collection amount and requests to issue a receipt; the system automatically calculates the fund attribute composition (defined below) of the payment for compensation, generates a bill, writes the source asset, the collection date, the collection amount and the fund attribute composition into the bill together, and finally feeds back the initial state of the bill as a receipt to a service provider.

4.2 transfer payment

Step two, the service provider inputs the payment date and requests to sign remittance notice; the system automatically retrieves all bills which are not later than the payment date and are not manually transferred backwards, carries out endorsement on the bills in batches to a support and management line, generates remittance notices of the summary amount taking the bills as accessories, and finally feeds the remittance notices back to a service provider;

step three, after receiving the transfer payment, the custody department requests to sign up (or return) remittance notice according to the actual receiving condition; the system automatically confirms (or returns) all bills under the item of remittance notices in batches, automatically calculates and adjusts (or does not adjust) the SPV account balance and the details thereof according to the detail data transmitted by the bills, and finally feeds back the remittance notices in an 'account-arriving' (or 'returning') state to the hosting line.

4.3 period/end of term Allocation

And in the fourth step or at the end of the period, a manager inputs an allocation accounting reference day (accounting day) through a client and requests to compile an allocation scheme, the system automatically calculates each amount to be paid (specifically, the amount can be adjusted according to needs), then the bill combinations suitable for each amount to be paid are respectively selected (or collected through a change-making algorithm) from the SPV account, the bill combinations are taken as accessories to respectively generate payment instructions, and finally all the payment instructions are gathered together to generate the allocation scheme with complete information and are fed back to the manager (the specific algorithm and the technical path are shown below).

Step five, the custodian requests to execute the allocation scheme; the system automatically executes payment instructions under the distribution scheme item one by one (carries out endorsement of bills under the distribution scheme item to a specific receiver in batches and issues remittance notice), and then feeds back the distribution scheme in a finished state to a management line.

And step six, after each receiver receives cash remittance, triggering an instruction to sign (or return) remittance notice to confirm whether the funds under the remittance notice are sufficient to be paid out, automatically adjusting (or not adjusting) account balance and details of each organization by the system, and uniformly updating the state of the remittance notice and the bills under the remittance notice into 'account arrival' (or 'return').

The above is a general description of the cash flow circulation process, and the definitions and business meanings of the tracking documents (i.e. data objects) are not explained, and the algorithm and technical implementation path of each step is not specifically described, and the related contents are described in the following.

5. Cash flow tracking documents and underlying data objects

5.1 Bill

The method monitors the flow condition of the cash flow in real time, dynamically and in a one-to-one tracking way, and is the most important core function of the method. For this purpose, the invention specially designs a special bottom data object- 'Bill', which records the information of the payment and receipt main body, payment and receipt time, source assets, fund attribute constitution (defined below) and the like of each cash flow, and the information is used as the mapping and simulation of the external cash flow in the system, so that the external cash flow is circulated in the system along with various payment and receipt documents in the form of accessories. It should be noted that the "tickets" mentioned in the present invention are only data objects used for tracking external cash flows inside the system, and do not have any cash exchange or value exchange functions, and thus are not "Bill Law" or money orders, promissory notes or checks in a commercial sense.

According to the business process of the invention, each time a service provider receives a payment for a payment, a receipt is required to be issued, at the moment, a data object generated at the bottom layer of the system is actually a bill, related intelligent dating records the asset number, the collection date and the collection amount of the payment for the payment on the bill, a reimbursement schedule of related assets is inquired in a state database according to the asset number, and the specific amount of principal, interest, fine or default money in the bill amount is calculated according to the principal repayment schedule of the reimbursement schedule ('fund attribute composition'). Then, the system takes the bill as an information carrier, and refers to the endorsement logic of the commercial draft, so that the bill is endorsed to the payee from the payer continuously along with the transfer and payment of the payment, and the digital simulation and tracking of the whole transfer process of the payment are realized.

When the payment is paid again, the bill is automatically endorsed under the control of an intelligent contract and an algorithm function in the system, namely, the payee is set as a bill holder, the circulation direction of the right of the bill is limited, and the state of the bill is changed into the in-transit state (hereinafter referred to as the endorsement and the bill); when the collection side confirms that the remittance is delivered to the account, the bill is automatically confirmed by the related intelligent contract in the system, namely, the state of the bill is changed into the state of the bill, so that the bill holder obtains the complete administration right of the bill (hereinafter, the bill is confirmed).

Under the scene of securitized cash flow tracking, the main body identity verification of a ticket holder needs to be only accurate to the 'mechanism' level, so that the technical scheme of the invention directly calls the MSPID query API reserved for an intelligent contract by a block chain system, obtains the MSPID submitted to a transaction client and takes the MSPID as the identity of a participating mechanism (hereinafter called 'calling mechanism') for calling the intelligent contract.

Every endorsement action or confirmation action is completed in the background of the system under the calculation and control of the intelligent contract, and after the completion, a bill snapshot with different states is formed. In fact, in the clearing and collecting channel of securitized cash flow, the reimbursement funds continuously flow between different payers and payees in an in-transit state and an in-charge state, and the ' bills ' snapshot ' in different states is the identification and tracking of the reimbursement funds in different states. So the receipt is actually the ticket that initially generated the initial state "snapshot" when it was not endorsed backward.

The block chain system reserves an API for inquiring the history of the data object for the intelligent contract, and can inquire and acquire the complete creation, modification and deletion history of the data object according to a specific key when the data object is written into the key value pair state database. By utilizing the special function of the block chain system, the invention specially sets a 'state sequence number' field on the 'bill', and sequentially marks different state snapshots of the 'bill' in the circulation processes of generation, endorsement, confirmation and the like according to time sequence, so that a data object history inquiry API can be used for quickly inquiring and acquiring the complete history record of a specific 'bill' from a block chain account book, and then the 'bill' state snapshot formed after the completion of a specific circulation action is screened out according to the 'state sequence number'. Thus, as long as two items of data, namely the serial number and the state serial number of the bill, are written into receipt and payment voucher data objects, such as remittance notices, payment instructions and the like, the logic binding of the bill and the receipt and payment vouchers can be realized, the bidirectional quick inquiry between the receipt and payment voucher and the bill can be realized, and the subsequent necessary calculation can be carried out on the basis of the bidirectional quick inquiry. Of course, this method can also be used to retrieve the "Ticket" initial state snapshot, i.e. the "receipt" corresponding to a certain repayment.

During the period distribution or at the end of the period distribution, the situation that the sum of the bill has to be split may occur, at this time, the system generates a new 'change' bill which takes the payer as the ticket holder, and the original bill is deducted by the sum of the 'change' bill and then is endorsed to the payee.

The circulation of the bill in the invention needs to follow the following rules:

(1) only the ticket holder who arrives at the account state ticket has the right to endorse the ticket;

(2) only the ticket holder in the 'account arriving' state 'ticket' has the right to 'split' the amount of the ticket to generate 'change giving' ticket;

(3) after the bill is endorsed, the person who is endorsed logically becomes the ticket holder of the bill, and the original ticket holder loses the right of dominating the bill;

(4) the "endorser" needs to confirm the "notes" before the complete "notes" administration is obtained.

With the circulation of endorsements in the system, the bills become a data carrier formed by source assets and fund attributes, the information of specific payment is dynamically transmitted to related intelligent contracts, the related intelligent contracts can search related assets and a money return schedule according to asset numbers, and further directionally adjust asset balance, calculate financial indexes such as asset performance state (normal, overdue and recovery), overdue native interest amount of assets, default rate of an asset pool and the like, or dynamically adjust data such as income details (native deposit, interest, penalty or default fund) of related accounts according to the fund attributes.

5.2 Notification of remittance

Remittance notice is a payment amount calculation tool, a payment behavior tracking document and an underlying data object designed by the invention, and can be regarded as a summary voucher of all bills under the item of the payment behavior. In the scenes of cash flow collection, transfer payment, distribution and the like, the cash flow collection system can assist a payer to automatically collect and calculate the total amount of funds required to be transferred; when a payment behavior occurs, the payment system can trigger an instruction in batches to carry out one-time endorsement on a plurality of bills under the item to a payee, or complete confirmation (or return) actions in batches, and meanwhile, data such as fund attribute composition carried by the bills under the item can be recorded in a gathering manner, so that the information is transmitted to block chain data objects such as cash accounts of the payee, related asset pools and the like.

The recipient of the remittance advice is distinguished from the beneficiary. The payee represents the principal who can directly hold and control the flow of the "note", while the beneficiary refers to the principal who enjoys the substantial economic benefit of the cash flow mapped by the "note", both sometimes directed to the same principal, and sometimes separated by a third party escrow arrangement of the cash asset. In a securitization scenario, when the recipient of the remittance advice points to the custodian, the beneficiary may be the securitized asset carrier SPV (when the facilitator proceeds to pay the custodian for a payment), may be the investor (when the investor is paid for pre-allocated funds), or may be the custodian itself (when the custody is paid to the custodian). Similarly, the separation between the fund custodian and the actual beneficiary, and even the separation between the fund custodian and the trusted manager, is also embodied in the action of "paying", but in a specific securitization scenario, in the technical scheme of the present invention, the distinction among the payers, paylines, payees, and "payment instruction" issuers is embodied by "payment instruction" (see the following details).

Any one payment action in the system generates a remittance notice, records information of a payer, a payment amount, a payment date, a payee, a beneficiary, an account date, an endorsed bill, a computer operator name and the like related to the payment; each time the payee signs the remittance notice, the state of the related remittance notice is changed, all bills under the remittance notice are traversed, and the remittance is uniformly endorsed to the payee. After the remittance notice is signed, information such as source assets, fund attribute composition and the like carried in the bill under the item is transmitted to data objects such as a beneficiary account, related assets, an asset pool and the like, so that dynamic tracking and real-time updating of related data information are realized.

The remittance notice designed by the invention has two states of 'on the way' and 'account arrival'. The "on the way" state represents that the funds recorded in the remittance notice are remitted by the payer but not received by the payee, and the bill which is the cash flow mapping in the system is endorsed to the payee by the payer, but the payee is not confirmed; the "account" status represents that the money under the remittance notice has been received by the receiver and, accordingly, the related ticket has been confirmed by the receiver, so that the receiver formally obtains the complete control of the ticket.

After confirmation of the account, the remittance advice will not track the subsequent status of the associated note. If the note is endorsed again by the payee to a third party, a snapshot of the state of the relevant note will be taken in charge of the receipt and tracking of the remittance advice generated by the subsequent payment.

5.3 Payment order

Payment order is a written notice, electronic certificate, and data object that the manager issues to the hosting bank instructing it to pay several funds from an SPV account or an investor pre-assigned account to a particular payee. Under securitized escrow arrangements, serial accounts representing asset carrier equity are managed directly by the "escrow" under the "custody agreement", with payment of funds being arranged specifically according to the instructions of the administrator. The payment instruction is an electronic document which is created for simulating and presenting the escrow arrangement and has a notification function and a voucher function, and can be used as a written notice for conveying payment instructions of a manager and a written voucher for an escrow bank to execute remittance instructions.

If the 'double-SPV' structure or other complex structures are adopted in the securitization transaction structure, the main body issuing the 'payment instruction' is not limited to the manager any more, and can also be a trusted consignee (when the bottom-layer SPV adopts a trusted structure) or a fund manager (when the bottom-layer SPV adopts a fund structure) of a bottom-layer asset carrier ('bottom-layer SPV'), and the delivery object of the 'payment instruction' at this moment becomes a storage bank of the cash assets of the bottom-layer SPV, and the related payment account becomes the related account of the bottom-layer SPV.

In summary, the legal meaning of the Payment order is that a principal having administrative authority over cash assets sends to a escrow bank entrusted with custody responsibility and having direct cash receiving capability instructing it to pay funds in a particular cash account to a particular collection principal. Therefore, the applicable scene of the payment instruction can be adjusted according to the securitized transaction structure and the cash flow clearing and collecting mode.

Payment order there are two states, "in execution" and "completed". "executing" represents that the payment instruction has been issued and generated by a manager, but the custody line has not remitted the related money according to the instruction, and the related bill should still be held by the custody line; the term 'finished' represents that the management line has finished executing the payment instruction, and the money with the same value is remitted according to the instruction, at the moment, the state of the related bill should be the 'in-transit' state, and the ticket holder should be the payee of the payment instruction.

When the administrator instructs the management line to pay out the external payment from the SPV account, a payment instruction is generated; the execution result of the payment instruction is embodied as that the custody organization issues remittance notice to the outside and the system automatically carries out bill with equivalent amount to a specific payee. After the bill endorsement action is completed, the payment instruction does not track the subsequent state of the bill.

6. Core flow algorithm and technology implementation path

6.1 Algorithm and technical realization path for 'generating' bill

The generation of the bill in the system needs to go through the following steps (see the attached figure 4):

(1) the service provider accesses a Web application client on a client computer browser in the local area network of the service provider, inputs information such as asset number, payment amount, payment date and the like of payment, triggers an instruction, sends an http request and requests to issue a receipt;

(2) after receiving the http request, the Web server of the service provider transmits the http request to a Web application server through reverse proxy service, the Web application server verifies the user identity and authority according to Session information in a memory of the Web application server, and after the verification is passed, the Web application server calls a specific intelligent contract through analysis, routing and a block chain system Software Development Kit (SDK), and transmits the input information, the user ID stored by the server and the user name (encrypted ciphertext obtained after SM4 encryption) to the specific intelligent contract in the form of input parameters;

(3) an SDK (software development kit) running in a Web server of a service provider packages a transaction channel ID, a specific intelligent contract, an input parameter and a service provider signature into a transaction plan in a block chain system by a client identity, submits the transaction plan to endorsement nodes of various participating institutions and requests to check endorsements;

(4) each organization endorsement node calls a related intelligent contract and carries out simulation calculation according to the following flow:

A. calling a member identity management Service ID (Membership Service Provider ID, MSPID) reserved for an intelligent contract by a block chain system to query an Application Programming Interface (API), acquiring the MSPID of a client submitting a transaction and judging whether the MSPID is equal to the MSPID of a Service Provider or not, if so, continuing the process, otherwise, reporting an error and exiting;

B. calling a state database query API reserved for an intelligent contract by a block chain system according to the asset number, and querying and acquiring three data objects of source assets, a source asset pool and a 'fund collection plan table' of the source assets from the state database;

C. the data recorded by the service provider and the inquired data object are transmitted to a specific tool function, and the tool function calculates the fund attribute according to the repayment history, the future repayment arrangement of the current interest and the collection date and amount of the current repayment recorded in the specific asset and the reimbursement schedule;

D. generating a bill with a state of 'account arrival' and a payer as 'debtor' and recording source assets and fund attributes on the bill, and particularly writing a service provider MSPID into an attribute of a bill holder;

E. updating data needing to be recorded, such as asset balance, fund attribute, overdue state, asset pool default rate, weighted average good account age, weighted average remaining period and the like, which are related to the repayment in the assets, the asset pool and the 'repayment schedule';

F. calling a writing operation API of the state database, and writing the newly generated data objects such as ' bills ' and updated assets, asset pools and ' Hui ' money schedule ' into the state database in a simulation way;

(5) each endorsement node endorses the simulation operation result (namely the read-write set of all relevant data objects) and then feeds back the endorsement signature to the SDK running on the Web server of the service provider;

(6) when the simulation operation results of the endorsement nodes of the feedback message are completely consistent and the confirmed number and source of the endorsement signatures meet the preset endorsement strategy, a client (SDK) of a service provider submits transaction information such as intelligent contracts, operation result reading and writing sets, endorsement signatures and the like to the sequencing service node in a transaction formal proposal mode;

(7) after the sequencing service node acquires the submitted transaction, judging consistency according to a consensus mechanism configured by the system, arranging transaction time sequence, generating a new block, writing the transaction related to the intelligent contract execution result into the new block and distributing the new block to leader endorsement nodes of each organization, wherein the leader endorsement nodes of each organization distribute to other endorsement nodes of the organization by a Gossip protocol after receiving the block message;

(8) each endorsement node verifies that endorsement signatures carried on transactions are real, the sources are legal and meet endorsement strategies, updates a block chain after verification passes, executes write operation on a 'state database' according to transaction information, formally writes 'notes' into the data object and updates the data objects such as assets, asset pools, 'reimbursement schedule' and the like;

(9) the intelligent contract feeds back the bill in the initial state to a calling source through an SDK (software development kit) operated on a Web server of a service provider, then feeds back the bill to a browser of a client through a Web application server and a Web application client, and a service provider user sees a newly issued receipt from a browser interface through analysis and calculation of the Web application client, wherein the receipt is the initial state snapshot of a bottom data object bill.

6.2 Algorithm and technical realization path of 'endorsement' & ltBill & gt

As mentioned above, the circulation of the 'bill' in the invention is realized by two steps of 'endorsement' and 'confirmation'. Specifically, the specific algorithm and technical implementation path of the 'endorsement' note action is as follows:

(1) calling an MSPID query operation API reserved for an intelligent contract by a block chain system, acquiring the MSPID of a transaction submission client, judging whether the MSPID is equal to the value of the attribute of a ticket holder in the bill, if so, continuing the process, and otherwise, reporting an error and exiting;

(2) checking whether the state of the bill is 'account arriving', if so, continuing the process, otherwise, reporting an error and exiting;

(3) writing the MSPID (minimum cost integration differentiation) transmitted by the parameter into the attribute of a ticket holder;

(4) accumulating the state serial number of the bill to be 1, modifying the state of the bill to be in the way, and writing the endorsement date transmitted by the parameter into the bill;

(5) and calling a state database write operation API reserved for the intelligent contract by the block chain system, and writing the modified bill into the state database.

In order to improve the operational efficiency of the system and avoid the improper interference of human factors, the algorithm of endorsement bill is recommended to be set as a tool function for intelligent contract calling, so that when cash flow delivery is simulated, the tool functions can be called in batches through algorithms such as circulation, traversal and the like in the intelligent contract to complete batch endorsement or batch confirmation of a plurality of bills at one time without repeatedly calling the intelligent contract, thereby greatly reducing the number of data interaction between all nodes of the whole network and improving the overall operational efficiency and stability of the system.

Of course, the above algorithm may be set as an independent intelligent contract, but the cost is that the intelligent contract needs to be triggered once for each endorsement of "bill", and the operation can be completed through 9 complete steps shown in fig. 4, so that if a plurality of "bills" are endorsed, the 9 endorsement checking and whole network consensus steps need to be repeated for many times.

6.3 Algorithm and technical realization path for 'confirming' bill

As mentioned above, the 'bill' circulation in the invention is realized by two steps of 'endorsement' and 'confirmation', wherein the specific algorithm and technology realization path of the 'confirmation' action is as follows:

(1) calling an MSPID query operation API reserved for an intelligent contract by a block chain system, acquiring the MSPID of a transaction submission client, judging whether the MSPID is equal to the value of the attribute of a ticket holder in the Bill, if so, continuing the process, and if not, returning an error and exiting;

(2) checking whether the state of the bill is in transit, if so, continuing the process, otherwise, returning to an error and exiting;

(3) accumulating the state serial number of the bill to be 1, modifying the state of the bill to be account, and writing the confirmation date transmitted by the parameter into the bill;

(4) the state numbers of the related notes recorded in the remittance advice are accumulated by 1.

(5) And calling a state database write operation API reserved for the intelligent contract by the block chain system, and writing the modified bill into the state database.

Like the endorsement algorithm, the recommendation sets the algorithm for confirming the bill as a tool function for calling the intelligent contract instead of the intelligent contract which can be executed only by independent calling and whole network consensus, thereby facilitating batch operation.

6.4 Algorithm and technique for "Return to" Bill "to implement path

The 'return' bill 'is a special case, and the' return 'bill' operation may be completed only when the actual receipt condition of the receiving party is inconsistent with the condition shown in the remittance notice. Specifically, the algorithm and the technology are implemented by the following paths:

(1) calling an MSPID query operation API reserved for an intelligent contract by a block chain system, acquiring the MSPID of a transaction submission client, judging whether the MSPID is equal to the value of the attribute of a ticket holder in the bill, if so, continuing the process, and otherwise, reporting an error and exiting;

(2) checking whether the state of the bill is 'in transit', if so, continuing the process, otherwise, reporting an error and exiting;

(3) judging whether the state serial number of the bill is 0 or not;

(4) if the attribute represents that the bill is never endorsed, directly writing the value of the attribute of the payer of the bill into the attribute of the ticket holder;

(5) if not, representing that the bill has an endorsement history, calling a historical state query API of a data object of the block chain system, searching a state snapshot of the bill before the endorsement by taking the current state serial number minus 1 as a condition, and then restoring the attribute value of a bill holder of the bill to be the MSPID of a front-hand organization of the bill;

(6) accumulating the state serial number of the bill to be 1, modifying the state of the bill to be account, and writing the confirmation date transmitted by the parameter into the bill;

(7) accumulating the state serial numbers of related bills recorded in remittance notice by 1;

(8) and calling a state database write operation API reserved for the intelligent contract by the block chain system, and writing the modified bill into the state database.

As previously mentioned, it is recommended that the return to Bill algorithm be set as a tool function for intelligent contract invocations, rather than a separate intelligent contract.

6.5 Algorithm and technique for "issuing" remittance Notification "to implement path

In the invention, the remittance notice is issued by actually carrying out batch endorsement on one or more specific bills to the payee after verification and summarization, and filling information such as remittance date, beneficiary, accompanying bill combination, identity of computer operator of payment side and the like into the remittance notice.

Specifically, the algorithm and the technology realize the following paths:

(1) calling an MSPID query API to obtain an MSPID of a transaction submission client and judging whether the MSPID is equal to a value of an attribute of a remittance notice payer, if so, continuing the process, and otherwise, reporting an error and quitting;

(2) traversing the bill combination transmitted by the parameters, judging whether the attribute value of the bill holder is equal to the attribute value of the remittance notice payer, if so, continuing the process, otherwise, reporting a mistake and quitting;

(3) writing the MSPID of the cash flow receiving mechanism into the attribute of remittance notice, payee;

(4) traversing the bill combination, calling 6.2 description bill tool functions in batches, and completing batch endorsement of the marked bill combination;

(5) writing the serial number and the state serial number of the bill into remittance notice, and binding the bill combination as an attachment of the remittance notice with the remittance notice;

(6) calling a status database writing operation API and writing remittance notice into the status database.

The algorithm for "issuing" remittance advice "described above in this invention is set up as a tool function for intelligent contract invocations, rather than as a separate intelligent contract. Therefore, before remittance notice is issued, marked bill combinations can be selected in advance to complete identity verification of a calling organization, endorsement verification of a more complex algorithm and a whole network consensus process can be completed under the control and scheduling of the same intelligent contract, and atomicity and account checking preposition of block chain database writing operation are guaranteed.

6.6 Algorithm and technique for "sign-in" remittance Notification "Path

The receipt of the remittance notice refers to that the bill combination of the label under the remittance notice item is subjected to traversal verification, the account is confirmed in batch, and the balance of the account of the beneficiary and the secondary detailed account (if any) is adjusted correspondingly.

Specifically, the algorithm and the technology realize the following paths:

(1) calling an MSPID query API to obtain an MSPID of a transaction submission client and judging whether the MSPID is equal to a value of a remittance notice payee attribute, if so, continuing the process, and otherwise, reporting an error and quitting;

(2) judging whether the remittance notice is in the way, if so, continuing the process, otherwise, reporting an error and quitting;

(3) calling a state database query API of the block chain system, and querying and obtaining a beneficiary account data object of remittance notice from the state database;

(4) according to the bill combination information under the item of remittance notice, traversing each bill and completing the following steps:

A. calling a state database query API of the block chain system, and querying and acquiring a specific 'bill' from the state database;

B. judging whether the attribute value of the 'ticket holder' of the 'bill' is equal to the attribute value of the 'receiver' of the 'remittance notice', if so, continuing the process, otherwise, reporting an error and quitting;

C. judging whether the state of the bill is 'in transit', if so, continuing the process, otherwise, reporting an error and exiting;

D. the Bill is "validated" for receipt according to the algorithm and flow described in 6.3.

(5) Adjusting account balance and details of the beneficiary according to capital attribute composition of note records under item of remittance notice;

(6) change the status of remittance advice to "to account";

(7) calling a writing operation API of the status database, and writing the updated beneficiary account and remittance notice back to the status database.

The algorithm for "sign-up" remittance advice "described above in this invention is set up as a tool function for intelligent contract invocations, rather than as a separate intelligent contract. Thus, as an independently operable program module, the intelligent contract can combine the program module with other modules to realize more complex algorithm logic on the basis of endorsement check and whole network consensus. It can of course also be set as a separate intelligent contract at the cost of sacrificing some system efficiency.

6.7 Algorithm and technique for "Return to remittance Notification" Path

The "remittance notice" of withdrawal means that the bills under the item of the "remittance notice" are combined and returned in batches.

Specifically, the algorithm and the technology realize the following paths:

(1) calling an MSPID query API reserved for an intelligent contract by a block chain system to obtain an MSPID of a transaction submission client and judging whether the MSPID is equal to a value of a remittance notice payee attribute, if so, continuing the process, and otherwise, reporting an error and quitting;

(2) judging whether the remittance notice is in the way, if so, continuing the process, otherwise, reporting an error and quitting;

(3) according to the bill combination information under the item of remittance notice, traversing each bill and completing the following steps:

A. calling a state database query API of the block chain system, and querying and acquiring a specific 'bill' from the state database;

B. "Return" Ticket by the algorithm and procedure described in 6.4;

(4) change the status of remittance advice to return;

(5) calling a status database write operation API, and writing the updated remittance notice back to the status database.

The "return" remittance advice algorithm described above in this invention is set up as a tool function for intelligent contract invocations, rather than a separate intelligent contract. Thus, as an independently operable program module, the intelligent contract can combine the program module with other modules to realize more complex algorithm logic on the basis of endorsement check and whole network consensus. It can of course also be set as a separate intelligent contract at the cost of sacrificing some system efficiency.

6.8 Algorithm and technology for issuing payment instruction

The core of issuing the payment instruction is to select the bill combination suitable for a specific amount from the account of the payer (or to make a change by the change algorithm), write the serial number and the state serial number into the payment instruction, and write the state of the payee and the state in execution into the payment instruction.

Specifically, the method comprises the following steps:

(1) calling an MSPID query API to obtain the MSPID of the transaction submitting client and judging whether the MSPID is equal to the administrator MSPID or not, if so, continuing the process, and if not, reporting an error and exiting;

(2) calling a state database query API of the block chain system, and querying and acquiring data objects such as an asset pool, an SPV cash account, all custody lines, bills and the like which are actually received before an accounting date and are not distributed;

(3) calling a tool function, selecting the most suitable combination (or combining the combination of the bills through a change making algorithm) from the bills under all SPV cash account items according to the target amount, and writing the serial numbers and the state serial numbers of the bills under the combination item of the bills into a payment instruction;

(4) and calling a status database writing operation API, and writing the generated payment instruction and change ticket (if any) and data objects such as the SPV cash account into the status database.

6.9 Algorithm and technique for executing Payment order

Executing Payment order refers to the process of endorsing bills under the item to the payee in batch, issuing remittance notice of the summary amount, correspondingly reducing account balance and detail of the payer, and finally modifying the state of the payer into finished state.

Specifically, the method comprises the following steps:

(1) calling an MSPID query API to obtain an MSPID of a transaction submission client and judging whether the MSPID is equal to a value of a payment instruction payment line attribute, if so, continuing the process, and otherwise, reporting an error and exiting;

(2) judging whether the state of the payment instruction is 'executing', if so, continuing the process, otherwise, reporting an error and exiting;

(3) calling a state database of the block chain system to inquire an API, traversing and inquiring and acquiring all bills under the payment instruction item, calling a tool function of ' signing and issuing ' remittance notice ' described in part 6.5, and giving a endorsement of the related bills to a payee specified by the payment instruction in batch;

(4) adjusting and subtracting the account balance and the details of 'payer' in 'Payment order';

(5) updating the Payment order status to "completed";

(6) calling a status database to write an operation API, and writing a plurality of data objects of payment instruction with the status of 'completed', remittance notice with the status of 'on the way', bills endorsed to a specific receiver under the item of remittance notice and updated cash account of the payer into the status database.

Description of the drawings

FIG. 1: participating organization network architecture topology structure chart

FIG. 2 is a drawing: software architecture schematic

FIG. 3: cash flow and tracking document flow schematic diagram

FIG. 4 is a drawing: algorithm and technology for generating 'bill' to realize path diagram

FIG. 5: securitized cash flow tracking method and system logic flow chart

Fifth, detailed description of the invention

FIG. 5 is a general logic flow diagram of the present invention embodying the method of securitized cash flow tracking, operational flow and algorithmic logic of the intelligent contract architecture. Specifically, the invention can be organized as follows:

(1) each participating mechanism deploys and starts a block chain network and completes initialization of data objects such as assets and asset pools; the system automatically creates data objects such as SPV cash accounts, reserved tax accounts, service provider accounts, custody bank accounts, manager accounts, investor pre-allocation accounts and the like according to configuration files and series intelligent contracts, and completes initialization setting of an intelligent contract system and basic data objects in a large-scale automatic operation and whole-network consensus mode.

(2) After receiving the repayment of the basic asset debtor, the service provider records an asset number, a collection amount and a collection date (supporting Excel batch import) through the client, and triggers a system instruction to request for issuing a receipt; after the identity of a service provider is verified by using MSPID, a related intelligent contract automatically calculates the overdue condition of the related asset, calculates and compensates the capital attributes of penalty (or default fund), principal and interest in payment according to the 'payback schedule' of the related asset and the input information of the service provider, then adjusts the balance of the asset, updates the 'payback schedule', then generates a 'bill' data object, records the asset number and the capital attribute information on the 'bill', sets the service provider as a ticket holder of the 'bill', and finally feeds back and presents the initial state snapshot (namely 'receipt') of the 'bill'.

(3) The service provider inputs the payment date, and triggers a system instruction request to generate remittance notice of payment for payment through the client; after the MSPID is used for verifying the identity of the service provider, related intelligent contracts gather the bills which are not later than the transfer date and are not endorsed, endorse the bills to a management bank in batches, calculate the summarized amount to be transferred, and finally sign a remittance notice on the name of the service provider to the management bank and attach all the bills.

(4) The custody department triggers an instruction to request to sign (or return) remittance notice through the client according to the actual receiving condition; after the identity of the custody department is verified by the MSPID, the related intelligent contracts confirm (or return) the related bills under the item of remittance notice in batches, and form and adjust (or not move) the SPV account balance and the details thereof, the capital balance of the asset pool and the actual payment amount according to the recorded capital attributes.

(5) A manager inputs an allocation accounting reference day and a triggering instruction request through a client to compile an allocation scheme; after the identity of a manager is verified by using MSPID, the corresponding intelligent contract automatically calculates each payable amount such as reserved tax, service fee, escrow fee, management fee, pre-allocated money of investors and the like according to the reference day and the SPV account details, automatically selects (or obtains through a 'change-making' algorithm) the bill combination with the corresponding amount in the SPV account, issues a series of 'payment instructions' on the name of the manager, and finally generates an 'allocation scheme' with all payable amounts and the 'payment instructions'.

(6) The custody bank requests to execute the distribution scheme through the client and triggers an instruction to request to execute the distribution scheme; after the identity of the custody department is verified by the MSPID, the related intelligent contracts automatically execute payment instructions attached under the custody department one by one according to the distribution scheme (uniformly and automatically endorse a specific bill combination to a payee, automatically sign remittance notices after collection), uniformly reduce the SPV account balance and the detail thereof and the real collection amount of the asset pool, and finally change the distribution scheme state to be completed.

(7) According to the actual receiving condition, each organization triggers an instruction to request to sign out (or return) remittance notice through the client; after the identity of the receiver is verified by the MSPID, the related intelligent contracts sign (or return) remittance notices, confirm (or return) related bills under the remittance notices in batches, and correspondingly adjust (or not move) account balance and details of the beneficiary in the remittance notices.

In summary, the invention utilizes series embedded algorithms to simulate, summarize, account and track each key data information of the securitized cash flow one-to-one under the control of series intelligent contracts and tool functions through tracking documents and bottom layer digital objects arranged in three systems of 'bills', 'remittance notices' and 'payment instructions', simultaneously dispatches various nodes of multi-party participating mechanisms in a block chain distributed network to carry out real-time interaction of data and information, and synchronously updates block chain accounts respectively controlled by each mechanism on the basis of total network consensus, thereby realizing the total flow tracking and dynamic monitoring of clearing, collecting, transferring and distributing of the securitized cash flow.

Claims (9)

1. A securitized cash flow tracking method and system based on blockchain technology is composed of blockchain service nodes, CA nodes, application program servers and clients which are respectively controlled by four organizations including a service provider, a management bank, a manager and an investor, wherein each organization respectively provides certificate issuing and verification services through a self-signed digital certificate system through the CA nodes which are respectively controlled by the organizations and respectively configures MSPs, so that the organization has a unique MSPID respectively in the blockchain network configuration to identify the MSP and the organization identity, and the method is characterized by comprising the following steps:

step one, after receiving payment, a service provider inputs an asset number, a collection date and a collection amount through a client and requests to open a receipt; after the MSPID is used for verifying the identity of a facilitator, related intelligent contracts automatically calculate and compensate capital attributes of penalty (or default money), interest and principal in payment, record the capital attributes together with asset number, collection date and collection amount on newly generated bills, write the MSPID of the facilitator into attributes of a bill bearer, and feed the initial state of the bill as a receipt back to the facilitator;

step two, when paying for payment, the service provider inputs the payment date and requests to sign remittance notice through the client; after the MSPID is used for verifying the identity of the service provider, the related intelligent contract carries out batch endorsement on all bills with the collection date which is not later than the pay-through date and is generated by the step one to a management bank, and the remittance notice of the summary amount is generated by taking the bills as an accessory and is fed back to the service provider;

step three, according to the real receiving situation, the custody bank requests to sign (or return) remittance notice through the client; after the identity of a custody department is verified by using the MSPID, all bills under the item of remittance notice are confirmed (or returned) in batches by related intelligent contracts, and the balance of the SPV account, the details of the SPV account, the balance of capital of an asset pool and the actual payment amount are adjusted (or not changed) according to the capital attributes recorded by the bills;

step four, during period or end-of-period distribution, a manager inputs a reference day through a client and requests to compile an allocation scheme; after the identity of a manager is verified by using MSPID, the related intelligent contracts automatically calculate each payable amount according to the reference day and the specification of the SPV account, select (or change) bill combinations from the SPV account by taking the payable amounts as target amounts, respectively issue payment instructions by taking the bill combinations as accessories, and finally generate allocation schemes by taking all the payment instructions as accessories and feed back the allocation schemes to the manager;

step five, the custodian requests to execute the distribution scheme through the client; after the identity of the custody line is verified by using the MSPID, the related intelligent contracts execute payment instructions under the distribution scheme item one by one (the bills under the distribution scheme item are endorsed to the payee in batch and a remittance notice is issued, the SPV account balance and the detail thereof and the asset pool real-time payment amount are correspondingly reduced), and then the distribution scheme state is changed into finished state;

step six, according to the actual receiving situation, each organization requests to sign (or return) remittance notice through the client; after the identity of the receiver is verified by the MSPID, all bills under the item of remittance notice are confirmed (or returned) in batches by related intelligent contracts, and account balance and details of the beneficiary are adjusted (or not changed) according to the recorded fund attributes.

2. The method of claim 1, further comprising:

when remittance notice is issued, calling MSPID inquiry API to obtain MSPID of a transaction submission client and judging whether the MSPID is equal to the attribute value of a payer in remittance notice, if so, continuing the process, otherwise, reporting an error and quitting;

traversing the bill combination transmitted by the parameters, judging whether the attribute value of the bill holder is equal to the attribute value of the remittance notice payer, if so, continuing the process, otherwise, reporting a mistake and quitting;

writing the MSPID of the cash flow receiving mechanism into the attribute of remittance notice, payee;

carrying out batch endorsement on the imported bills to remittance notices to a receiver;

the serial number and the state serial number of the bill are written into the remittance notice, so that the remittance notice is bound with the remittance notice as an attachment of the remittance notice.

3. The method of claim 2, further comprising:

when the bill is endorsed, calling an MSPID query API to acquire the MSPID of the transaction submission client and judging whether the MSPID is equal to the value of the attribute of the bill holder, if so, continuing the process, otherwise, reporting an error and exiting;

judging whether the state of the bill is 'account arriving', if so, continuing the process, otherwise, reporting an error and exiting;

the state serial number of the bill is accumulated to be 1, the state is modified to be in the way, the MSPID of the endorsee transmitted by the parameter is written into the attribute of the ticket holder, and the endorsement date is updated.

4. The method of claim 1, further comprising:

when receiving remittance notice, calling MSPID inquiry API to obtain MSPID of a transaction submission client and judging whether the MSPID is equal to the attribute value of a receiver of remittance notice, if so, continuing the process, otherwise, reporting an error and quitting;

judging whether the remittance notice is in the way, if so, continuing the process, otherwise, reporting an error and quitting;

confirming all bills in the item in batches according to the record of remittance notice;

adjusting account balance and details of remittance notices beneficiaries according to fund attributes recorded in the bills;

the remittance advice state is changed to "to account".

5. The method of claim 4, further comprising:

when the bill is confirmed, calling an MSPID query API to obtain the MSPID of the transaction submitting client and judging whether the MSPID is equal to the value of the attribute of a bill bearer, if so, continuing the process, otherwise, reporting an error and exiting;

judging whether the state of the bill is 'in transit', if so, continuing the process, otherwise, reporting an error and exiting;

accumulating the state serial number of the bill to be 1, modifying the state of the bill to be account and updating the confirmation date;

the state numbers of the related notes recorded in the remittance advice are accumulated by 1.

6. The method of claim 1, further comprising:

when returning remittance notice, calling MSPID inquiry API to obtain MSPID of a transaction submitting client and judging whether the MSPID is equal to the attribute value of a receiver of remittance notice, if so, continuing the process, otherwise, reporting an error and exiting;

judging whether the remittance notice is in the way, if so, continuing the process, otherwise, reporting an error and quitting;

returning all bills under the item in batches according to the record of remittance notice;

the remittance advice state is changed to return.

7. The method of claim 6, further comprising:

when returning back the bill, calling the MSPID query API to obtain the MSPID of the transaction submitting client and judging whether the MSPID is equal to the value of the attribute of the bill holder, if so, continuing the process, otherwise, reporting an error and exiting;

judging whether the state of the bill is 'in transit', if so, continuing the process, otherwise, reporting an error and exiting;

judging whether the state serial number of the bill is 0 or not;

if yes, writing the attribute value of 'payer' in 'Ticket holder' into the attribute of 'payer';

if not, calling a historical state query API of the block chain data object, searching a 'bill' state snapshot before endorsement by taking the current state serial number minus 1 as a condition, and then restoring the 'ticket holder' attribute value of the 'bill' to the MSPID of the front-hand organization;

accumulating the state serial number of the ' bill ' by 1 ', modifying the state of the ' bill ' into ' return ', and updating ' confirmation date ';

the state number of the note recorded in remittance advice is accumulated by "1".

8. The method of claim 1, further comprising:

when issuing a payment instruction, calling an MSPID query API to acquire the MSPID of the transaction submitting client and judging whether the MSPID is equal to the MSPID of the administrator, if so, continuing the process, otherwise, reporting an error and exiting;

writing the incoming 'payer' and 'Payment line' into 'Payment order', and setting the state thereof to 'executing';

the most suitable combination is selected according to the payment amount in the bills under the cash account item of the payer (or the combination of the bills is put together through a change making algorithm), and the serial numbers and the state serial numbers of the bills under the combination item of the bills are written into the payment instruction.

9. The method of claim 1, further comprising:

when executing the Payment instruction, calling an MSPID query API to obtain the MSPID of the transaction submitting client and judging whether the MSPID is equal to the value of the attribute of 'Payment line' in the Payment instruction, if so, continuing the process, otherwise, reporting an error and exiting;

judging whether the state of the payment instruction is 'executing', if so, continuing the process, otherwise, reporting an error and exiting;

according to the record of the payment instruction, the remittance notice is issued to the payee by taking the bill combination under the item as an accessory;

change the Payment order status to "completed".

Images