NZ779404A - Systems and methods for executing and auditing transactions using distributed ledgers - Google Patents

Abstract

The present disclosure provides new and innovative systems and methods for securely executing transactions and generating transaction logs. In an example, a computer implemented transaction system includes a database storing system data including at least user data for a plurality of users, bank account data for one or a plurality of bank accounts, and contract data for contract(s) between the users, a blockchain comprising one or more secure tokens, and at least one processor in communication with the database and the blockchain and configured to determine that funds have been received in a first bank account, create secure tokens representative of the funds, as cryptographic assets in the blockchain, and associated with a first user, apply one or more rules based on the contract data to transfer the funds from the first bank account to at least one second bank account, associated with at least one second user, and cryptographically signing the blockchain to associate the secure tokens with the at least one second user. ount data for one or a plurality of bank accounts, and contract data for contract(s) between the users, a blockchain comprising one or more secure tokens, and at least one processor in communication with the database and the blockchain and configured to determine that funds have been received in a first bank account, create secure tokens representative of the funds, as cryptographic assets in the blockchain, and associated with a first user, apply one or more rules based on the contract data to transfer the funds from the first bank account to at least one second bank account, associated with at least one second user, and cryptographically signing the blockchain to associate the secure tokens with the at least one second user.

Description

S AND METHODS FOR EXECUTING AND AUDITING CTIONS USING DISTRIBUTED LEDGERS Technical Field The present invention relates to a computerised transaction system and more specifically to computer systems that automatically execute secure and traceable ctions.

Background Any discussion of the prior art throughout the specification should in no way be considered as an admission that such prior art is widely known or forms part of the common l knowledge in the field.

In the real estate industry, rental properties are frequently managed by property managers. The managers are typically real estate agents who act on behalf of the property owners (landlords), to relieve the administrative and managerial burdens associated with g out a ty – whether it be a residential property or a cial property.

Among their various duties, property managers typically ensure that tenants pay the rent on the property in a timely fashion, usually into a trust account.

The property manager holds the funds in the trust account before passing them on to the landlord. Licensed real estate agents have important legal and fiduciary responsibilities in on to the management of a trust account. The removal of money from a trust account for reasons other than an authorised purpose is a criminal offence. There are regulations in place in all ictions that require the strict maintenance of a formal set of trust account records to show at any time the state of the real estate agent’s trust account.

Property managers are often managing many properties on behalf of many different property owners. Accordingly, they are ng significant amounts of money, which is being transferred between many renters and many landlords.

This results in a significant administrative burden, to ensure that all received funds are accounted for, that payments are made by tenants and passed on to ty owners, and to identify when payments have been missed or are overdue.

Because of the significant amounts of money that property rs may handle, government regulations (in many jurisdictions) impose obligations regarding record keeping and handling of those funds. Property managers may be subjected to government audits to ensure ance with these regulations – either at regular intervals, or randomly. ing with an audit can be an ive task for property managers, due to the ive record keeping requirements.

Receiving timely notification that a deposit or rent has been ed is critical to both tenants and property managers. With traditional banking processes, funds can take between 1-3 business days to appear in a trust account.

When a tenant applies for a rental property, many property managers require a deposit (advance rent) to be paid before countersigning the tenancy agreement.

The delay caused by movement of funds results in loss of rental income from nonoccupancy during that time.

Overall, current systems are cumbersome and inefficient with a high level of administrative load on real estate businesses. For example, trust documents and records that should be maintained include: a record of money received for or on behalf of any other person; trust receipt books register; ates of every completed trust account deposit form; trust account journals; trust ledgers; trust cheque books’ register; records of trust money payments; bank statements of trust moneys; register of securities; trust account reconciliation statements; requests for the issue of bank cheques; requests for the opening of separate interest bearing trust ts; and any other books, accounts or records otherwise kept by an agent at their discretion relating to trust money.

In on to the administrative burden and delays, existing s have other inherent risks including fraud and theft (case with the highest amount in NSW was in 2019 with $3.6m stolen by an agent), the complexity of a real estate agency closing down (often unveiling issues with the trust monies), unclaimed trust monies, and annual audit of trust accounts epancies are sometimes not ed for years).

There is accordingly a need for systems or methods which address some or all of the above issues, or at least provide an alternative to conventional systems for managing funds for rental properties, or in other situations that involve the need for nt or ad hoc ers of funds between parties.

Summary The t disclosure provides new and tive systems and methods for ly ing transactions and generating transaction logs. In an example, a computer implemented transaction system includes a database storing system data including at least user data for a plurality of users, bank account data for one or a plurality of bank accounts, and contract data for contract(s) between the users, a blockchain including one or more secure tokens, and at least one processor in communication with the database and the blockchain and configured to determine that funds have been received in a first bank account, create secure tokens representative of the funds, as cryptographic assets in the blockchain, and associated with a first user, apply one or more rules based on the contract data to transfer the funds from the first bank account to at least one second bank account, associated with at least one second user, and cryptographically signing the blockchain to ate the secure tokens with the at least one second user.

In another example, the processor may be further configured to burn the secure token in the blockchain when the funds are withdrawn from bank accounts in the database.

In another example, a bank transaction ID is included in the blockchain upon creation of the secure tokens.

In another example, an auditing interface may be provided to y information from the database and the blockchain, whereby an auditor can verify that funds have been processed in accordance with the contract data.

In another example, the contract data may include data defining a rental ent between the first user and the second user, wherein the first user is a tenant and the second user is a landlord.

In a second e, a computer-implemented method for processing a transaction includes determining that funds have been received in a first bank account, creating secure tokens representative of the funds, as cryptographic assets in a blockchain, associated with a first user, applying one or more rules based on contract data stored in a database, to transfer the funds from the first bank account to at least one second bank account, associated with at least one second user, and cryptographically signing the blockchain to associate the secure tokens with the at least one second user.

In another example, the method further includes g the secure token in the blockchain when the funds are withdrawn from all bank accounts referred to in the contract data.

In a third example, a computer implemented transaction system includes at least one processor and a memory in communication with the at least one processor, configured with instructions for directing the processor to perform the method of the second example.

In a fourth e, a computerised rental payment management system for managing rental payments including a database storing system data including at least user data for a plurality of users, including a tenant and a landlord, bank t data for one or a plurality of bank accounts, and contract data for rental contract(s) between the tenant and the landlord, a blockchain ing one or more secure tokens, and at least one processor in communication with the blockchain and configured to determine that funds have been received in a first bank account from the tenant, create secure tokens representative of the funds, as cryptographic assets in the hain, and associated with the tenant, apply one or more rules based on the contract data to transfer the funds from the first bank account to at least one second bank account, associated with the landlord, and cryptographically signing the blockchain to ate the secure tokens with the landlord.

In a fifth example a computer-implemented rental payment management method including determining that funds have been received from a tenant in a first bank account, creating secure tokens entative of the funds, as cryptographic assets in a blockchain, associated with the tenant, applying one or more rules based on contract data stored in a database, to transfer the funds from the first bank account to at least one second bank t, associated with a landlord, and graphically signing the blockchain to associate the secure tokens with the landlord.

Embodiments of the present invention provide a payment rail for rental payments that has advantages in relation to transparency, efficiency, automation, auditability, real-time settlement, and regulation compliance. ments of the present invention leverage blockchain technology to achieve the above advantages, using logic in smart contracts to decide how money moves through the system, and to provide a platform for auditing to minimise manual effort and maximise efficiency.

The computer system may be ented using mobile computing device(s), such as apps on mobile phones or tablets, using internet browsers, or through dedicated applications on other computers. It will be appreciated that, unless ise stated, details and variations described with respect to one aspect of the ion equally apply to other aspects of the invention.

A detailed description of one or more embodiments of the invention is provided below along with accompanying figures that rate by way of example the principles of the invention. While the invention is described in connection with such embodiments, it should be understood that the invention is not limited to any embodiment. On the contrary, the scope of the invention is limited only by the appended claims and the invention encompasses numerous alternatives, cations and equivalents. For the purpose of example, us specific s are set forth in the following description in order to e a thorough understanding of the present invention.

The present invention may be practiced according to the claims without some or all of these specific details. For the purpose of clarity, technical material that is known in the technical fields related to the invention has not been described in detail so that the t invention is not unnecessarily obscured.

Brief Description of the Drawings The description will be more fully understood with reference to the following figures, which are presented as exemplary aspects of the disclosure and should not be ued as a complete recitation of the scope of the disclosure, where: Figure 1 is an overall system diagram ing to an embodiment of the present invention; Figures 2 to 8 sequentially depict examples of a transaction and associated blockchain updates, in accordance with embodiments of the t invention; Figure 9 is a conceptual diagram showing in more detail the features and interactions of a system according to an embodiment of the present ion; Figure 10 illustrates a flowchart of a process for executing transactions according to an embodiment of the present invention.

Detailed Description Turning now to the drawings, new and innovative systems and methods for securely executing transactions and generating transaction logs are disclosed. Figure 1 s a computer system 100 according to an exemplary ment of the present invention. The computer system 100 interacts with a hain 200, an external banking system 300, and one or more users 400. The overall architecture of this system 100 includes multiple sub modules, such as a front end 110 for primary interaction with users 400, a back end 120, and a microservice handler 130 to integrate with the external (or blended) es such as the banking system 300 or hain 200. The system 100 has particular application to "smart contracts" for rental agreements. Transaction protocols for a rental agreement may be implemented using standardised recurring subscriptions on the blockchain, for example using formats compliant with the EIP 1337 interface.

This allows users (e.g., a landlord and a tenant) to agree to a frequency and amount for the rent with a single authorisation.

In operation, the user 400 interacts with the front end 110 to send ts to the system 100. The user 400 may interact with system 100 utilising various devices of their own, ing mobile computing devices (such as a mobile phone, tablet computer, or laptop) and/or desktop computing devices. In a y of embodiments, users may include landlords, s and individual property managers. The database may store details of each user, ing their name and their role within the system (e.g. landlord, property manager, tenant). Users may interact with system 100 using, for example, a dedicated ation on their computing device, a web browser, and/or any other interface. The back end 120 is able to receive requests from the web frontend 110 and respond with the correct action and/or query the se 140 or other services to generate and return the correct result to the user 400. The database 140 can store data regarding users of the system 100, and bank account data specifying s of ts relating to rental transactions. This information may include details of the bank accounts (bank, account names, t numbers), as well as transaction data (e.g. date, amount, description) for relevant transactions that take place through those bank accounts. The database 140 also stores ct data from contracts between users – e.g. an amount and frequency of rental ts. Various other types of data may be stored in the database 140, including contact details for the parties for automating communications such as confirming payments or late-payment notices.

In a variety of embodiments, bank accounts for which bank account data is stored within database 140 include an interface account 310, a working capital account 320 (e.g., for a property manager), a cold storage account 330 (e.g., for a property manager), one or more landlord accounts 340, and a trust account 350 (e.g., for a property manager). In some embodiments, more or fewer bank accounts may be utilised. Contract data is stored within database 140 and may include various terms of a contract, such as the s involved (e.g., users), the address of the rental property, the amount and frequency of payments (potentially ing specific due dates), and/or any contract termination date. Where the parties mutually agree to make amendments to a contract, each of the relevant versions can be recorded and stored such that a history of the different contract variations is preserved. Details of relevant bank accounts ated with the users may be already stored as part of the user and bank account data can be stored in the database. In several embodiments, account ation is stored within database 140 instead of on the blockchain 200 due to privacy erations. Debit card, credit card and other similar banking information can be stored and managed in compliance with PCI-DSS requirements. In many embodiments, users may not have all of their data stored; for example payees who receive money may not have their bank account ation stored.

In a variety of embodiments, the microservice handler 130 provides s microservices, including banking ation, blockchain integration and a block explorer. The g integration microservice can connect to the database 140 in order to share state with the rest of the system 100. For outbound operations, the microservice handler 130 can provide a lambda on triggered by a simple queue service (SQS) topic. The lambda function can include instructions to read and process data within the SQS topic, execute application programming interface (API) calls to the bank, and store the results into database 140. For incoming operations, the microservice handler 130 can provide an API (e.g. a web service) that the bank (or any other computing device) can use to notify the system 100 when events happen. Separating the banking integration into its own ervice enables the system 100 to better control portions of the database 140 for only the banking integration microservice. For example, access can be restricted to authorised users. This also allows simpler control over access to the bank ts – forexample, if there is ever any concern around withdrawals made from bank accounts, withdrawal ons can be suspended whilst an investigation occurs.

A blockchain integration microservice is also provided which also connects to the database 140 in order to share state information with the rest of the system 100. The blockchain integration microservice can provide key storage and signature functionality and/or business logic. In a y of embodiments, the key storage is strictly controlled, and may even be secured in its te database (not shown) with strict access controls, rather than in se 140. The business logic is unable to sign transactions on its own, and is never provided with keys. Instead, when a blockchain transaction needs to be signed, the transaction can be sent to the key storage/signature service, which signs the transaction with the correct key, then returns the signed transaction to the ss logic so it can be broadcast to the blockchain network. Key generation for new keys can occur entirely within the key storage/signature service, which uses a cryptographically secure random number generator to generate the keys, which never leave the service. Users are also able to authenticate directly with the signature e, which helps prevent user impersonation. Once the broadcasted ction has been included in a block, the integration can update the record in the se to show the corresponding transaction hash. In this way, the security of the blockchain, the blockchain integration microservice, and the system 100 can be improved. A block explorer service can e a cal interface to the blockchain network 200, for ease of maintenance.

The blockchain 200 may be a private blockchain service and/or a decentralised public blockchain service, n secure tokens are used to track transactions between users of the system 100. The blockchain 200 can maintain a distributed ledger across one or more nodes of the blockchain 200. A node can include one or more computing devices capable of storing some or all of the distributed ledger and/or executing transactions provided to the node. The distributed ledger can store a record of transactions performed on the blockchain 200. A transaction can indicate a particular smart contract, any values associated with the transaction, the node(s) ting the transaction, the node(s) ed in the transaction, the time the transaction was initiated and/or executed, and/or any other data d to the transaction as appropriate. As described in more herein, the blockchain tokens are mintable and burnable. Minting a token can include creating one or more tokens on the blockchain 200, where a token represents a value, such as a corresponding amount of fiat currency. Burning a token can include removing one or more token from circulation (e.g. usage) within the blockchain 200.

Removing a token from circulation can include marking the token as out of circulation, deleting the token from the blockchain 200, and the like. When money enters the working capital account from the interface account, a corresponding number of blockchain tokens can be minted. When the blockchain tokens are burned, a ponding amount of money can be transferred to the interface account. After each transaction settles, the balance of working capital account and the cold e account should correspond to the number of blockchain tokens in existence. The blockchain may e various encryption standards. In a variety of embodiments, the hain may utilise an ERC223 tokens as its cryptographic asset. Keys for access to accounts in the system may be managed within the system and/or managed by the devices associated with users 400.

Rental ts can be initiated within system 100 as a subscription relayer using a scheduled job defined in a smart contract. This can be customised ing on the particular needs of different users. For example, if a weekly rental agreement is d, the rental agreement smart contract could be set up as a daily subscription, but the d payments would only be scheduled to run once a week. One advantage of this arrangement would be that there is some flexibility to, for example, alter the day of the week that payments are executed or other nonessential alterations to the rental arrangement without altering the basis of the agreement between the rd and the . Multi-party rental agreements could also be implemented in various embodiments of the invention. For example, with a multiple signature smart contract behind the rental ent. In a variety of embodiments, smart contracts allow payments from multiple parties with different bank accounts to occur simultaneously or at the times directed by the smart contract.

Funds will lly be received initially from the tenant into the interface account 310. When the system 100 becomes aware of them through the interface 130 with bank 300, the system validates the incoming payment, ensuring that references and other identifying information matches what is expected within the terms of the smart contract.

If the identifying information does not match the contract data stored in database 140, in some cases a ticket may be queued for an administrator to review the payment. However, if the identifying information is sufficient for the system 100 to determine who the funds should be credited to (generally a landlord user), the system 100 automatically initiates a transfer from the interface account 310 to the working capital account 320. In a variety of embodiments, this transfer coincides with an identical amount of cryptographic asset creation whereby 1 token is equivalent to 1 cent. For example, if $500.00 is received, 50,000 tokens are minted on the blockchain. Identifying information such as the bank’s transaction ID may be nced in the hain when upon on of the secure , for later audit tracing. The tokens can be pegged to a fiat currency, such as Australian Dollars (AUD), US Dollars (USD), Euros (EUR), the price of gold, and/or any other currency as appropriate. When a user wishes to withdraw funds from the system, they initiate the burning of the tokens. When the system 100 obtains the request to burn the , the system 100 can te a transfer from the working l account 320 to the interface account 310. The system 100 can also generate a memo indicating the transfer is complete. This memo can be recorded on the buted ledger maintained by the blockchain.

The system 100 may have rules to determine if the withdrawal can be approved and executed automatically. If the withdrawal is approved automatically, the system 100 can initiate a transfer from the interface account 310 to the user’s bank account 340 using bank data such as BSB /Account Number, BPay details, SWIFT details, Credit Card details, and the like stored in the database 140.

Alternatively, if further review is ed, a notification can be generated and transmitted to an administrator to review the transaction. In many embodiments, to protect against loss, funds can be transferred to and from the cold storage account 330. A business banking UI can be used with multiple ories to move funds from the working capital account 320 to the cold storage account 330 and/or to move funds from the cold storage account 330 to the working capital account 320.

Movement of funds from the g capital account to the cold storage account 330 and vice versa is effectively transparent to the blockchain system 200.

Where a property manager wishes to integrate their trust account into the system 100, transfers n the interface account 310 and the property manager’s trust account 350 can be controlled by a separate ervice, which stores credential separately to the rest of the system 100.

The operation of the blockchain in the context of a "smart contract" transaction protocol system will now be described in more detail, with reference to Figures 2 to 8. Although these processes are described with reference to the illustrations of Figures 2 to 8, it will be iated that many other methods of performing the acts associated with the processes may be used. For example, the order of some of the operations may be changed, certain ions may be combined with other operations, one or more operations may be repeated, and some of the operations described are optional. The operations may be performed by processing logic that may include hardware (circuitry, dedicated logic, etc.), software, or a combination of both.

As shown in Figure 2, money is deposited into the interface account 310. The system 100 validates the incoming payment against contract data stored in the database 140. If there are any issues (e.g. insufficient payment), the system 100 may generate reminder notices or defect notices in accordance with the contract data. Upon validation by the system 100, it moves to the working l account 320 and is credited to the tenant in the blockchain system 200, as shown in Figure 3, with the creation of a corresponding amount of tokens, preferably ncing the bank’s transaction ID for subsequent auditing and traceability. The system then processes the rental t, either automatically in accordance with its smart contract rules, or on initiation by the , as shown in Figure 4. In many ments, the smart contract for the rental agreement forwards the proceeds to the property manager’s trust t 350 as depicted inFigure 5. The system 100 recognises that there is a transfer into a trust account 350 and moves the money in the banking system 300 to match. As shown in Figure 6, the landlord is paid the rent at a time as directed by the smart contract or the agreement between the ty manager and the landlord. As shown in Figure 7, when the landlord wishes to aw the rent, they burn the secure tokens in their account, which transfers the funds to the interface t 310 and schedules a er out of the interface account 310 and to the landlord’s account 340. As shown in Figure 8, the scheduled transfer has occurred.

The systems and methods described herein can provide near real-time access to all blockchain transactions and balances, represented in a block explorer, all bank transactions and es, and/or various other ing functions based on the transaction data, contract data and user data stored in databases and on the secure blockchain. The reporting advantages of the present invention allow auditors to see an overview of the system at a high level and then spot check any number of transactions efficiently by g the various entries side by side, making it much simpler for a property manager to meet their auditing obligations. It allows the collection of audit data to be largely ted: the auditor is able to run their own blockchain node to monitor overall actions on the network and ensure that the blockchain never forks unexpectedly. By using a distributed ledger stored using a blockchain to record the audit data corresponding to the transactions, the system 100 therefore provides a high degree of transparency and traceability on every action.

The code defining the smart contracts can also be audited readily, and ed to ensure all rental agreements in the system use audited code. The se can be audited with database logs; the code can be audited by reviewing git history and deployment logs; the blockchain transactions can be audited by reviewing the code in the smart contracts, and by tracing money through the system, from deposit into the bank account, through the smart contracts, and out the other side to the rd; a blockchain node could even be deployed at the auditor’s premises so they can detect any attempt to fork the blockchain network or otherwise undo the protections ed by the smart contracts; the bank accounts can be d by examining bank access controls and policies and ures around access to the accounts. This can save substantial time and money for property managers in complying with auditing requests and their consequent obligations.

Figure 10 illustrates a flowchart of a process for executing transactions ing to an embodiment of the present invention. gh the example process 1000 is described with reference to the flowchart illustrated in Figure 10, it will be appreciated that many other methods of performing the acts associated with the process 1000 may be used. For example, the order of some of the blocks may be changed, n blocks may be combined with other blocks, one or more blocks may be repeated, and some of the blocks described are optional. The process 1000 may be performed by processing logic that may include hardware (circuitry, dedicated logic, etc.), software, or a combination of both.

Fund deposit data can be obtained (1010). The fund deposit data can be ed by a computing device associated with a user and/or a bank. The fund t data can indicate that funds associated with a first user or a first banking account have been ed to the first banking account. The first user and/or first banking account can be associated with a first account maintained using a blockchain. In a variety of ments, the first user, first banking account, and/or first account are associated with a smart contract.

Tokens can be generated (1012). The tokens can be generated based on the fund deposit data. The tokens can be generated on a blockchain or other distributed computing platform. In many embodiments, generating the tokens includes minting a number of tokens corresponding to the value indicated in the fund deposit data. The tokens can have a fixed value and/or a variable value. For example, if $750 is indicated in the fund t data, 750 tokens, each representing a value of $1, can be minted. If the tokens represent a variable value, a single token having a value of $750 can be minted. In a variety of embodiments, the tokens are ting by executing the smart contract to cause the blockchain to mint the tokens. The generated tokens can be stored using the first account. In many embodiments, minting and/or storing the tokens causes a record of these actions to be stored using an audit log.

Transaction execution data can be obtained (1014). The ction execution data can be provided by a ing device associated with a user and/or a bank. The transaction execution data can indicate that the funds are to be erred from the first banking account to a second banking account. The second banking account can be associated with a second user. In a variety of embodiments, the second user or second banking account are associated with the smart contract. A second account ponding to the second user and/or second banking account can be maintained using the blockchain.

Tokens can be transferred (1016). Tokens can be erred based on the ction execution data. The tokens can be transferred from the first account to the second account. In many embodiments, the tokens are transferred by executing the smart ct to initiate the transfer of the tokens from the first account to the second account. In a variety of ments, transferring the tokens causes a record of the transfer to be created and stored using the audit log.

Fund withdrawal data can be obtained (1018). The fund withdrawal data can be provided by a ing device associated with a user and/or a bank.

The fund awal data can indicate that the funds are to be withdrawn from the second banking account. In many embodiments, withdrawing the funds from the second banking account includes transferring the funds from the second banking account to a third banking account associated with the second user.

Tokens can be retired (1020). Tokens can be retired based on the fund withdrawal data. Retiring the tokens can include marking the tokens as unused so that they are not used in later ctions on the blockchain. In a variety of embodiments, retiring the tokens includes g the tokens such that they are removed from the blockchain. In many embodiments, retiring and/or burning the tokens causes a record of these actions to be stored using the audit log.

The audit log can be stored (1022). The audit log can be stored using a distributed ledger maintained using the blockchain. In many embodiments, storing the audit log is caused by executing one or more commands defined in the smart contract. The audit log can be stored by causing one or more nodes in the blockchain to process and record the audit log on the distributed ledger.

There are various ages provided by the various embodiments of the invention, including that smart contracts can be coded directly from the physical contract that two or more parties have entered into (general tenancy agreement, agent agreement, sale of land and property). This means the source of truth for the movement of funds is the legally binding agreement between the parties. A y of embodiments of the invention automate transactions through the trust account for the agency, meaning that funds are moved only through the smart contract, reducing the risk of fraud and theft. In a variety of ments, manual transactions inside the fiat environment do not take place, although ad hoc ctions may be d, they preferably also have to be facilitated through a one-time smart contract so that an immutable record and audit trail is still adhered to and maintained. Capturing all of these records digitally inhibits the chances of records being changed, ied, lost or destroyed. This also provides the additional benefit of all transactions being easily audited as they live in the blockchain. In the event a real estate business closes there is no impact on the records of financial transactions.

It should be noted that, in many embodiments, users can continue to trade in fiat currency. In a variety of embodiments, the system tokenises fiat currency in a corresponding cryptocurrency which is then operated as a stable coin for the smart ct to direct the movement of these assets between the parties.

The crypto asset is then burnt when the fiat currency is released to the correct party.

This approach means that advantages of a smart ct and stable coin cryptocurrency solution can be harnessed in a private permissioned blockchain without exposing the parties to the downside risks of publicly traded cryptocurrencies. In a variety of embodiments, the party in transaction maintains ownership of the asset at all times, from fiat to cryptocurrency then back to fiat currency. The platform can y be independently audited to ensure agencies can meet their specific trust obligations, without having to carry the same level of cost and burden of traditional based audits on their business. This results in a step change in ency for their business as it significantly reduces the likelihood that they will need to pay audit fees, employ people to undertake the administrative function of maintaining their trust accounts or be exposed to the risk and cost of fraud and theft.

Although the invention described herein is described primarily with t to rental or properties in the real estate industry, the present invention can be utilized in any environments or applications where a "smart ct" system is desirable. hout this specification and the claims that follow unless the context requires otherwise, the words 'comprise' and 'include' and ions such as 'comprising' and 'including' will be understood to imply the inclusion of a stated integer or group of integers but not the exclusion of any other integer or group of integers.

It will be appreciated that all of the disclosed methods and procedures described herein can be ented using one or more computer programs, components, and/or program modules. These components may be provided as a series of computer instructions on any conventional er readable medium or machine-readable medium, including volatile or non-volatile memory, such as RAM, ROM, flash memory, magnetic or optical disks, optical memory, or other storage media. The ctions may be provided as software or re and/or may be implemented in whole or in part in hardware components such as ASICs, FPGAs, DSPs, or any other similar devices. The instructions may be configured to be executed by one or more processors, which when executing the series of computer instructions, performs or facilitates the performance of all or part of the disclosed methods and procedures. As will be appreciated by one of skill in the art, the functionality of the program modules may be combined or distributed as desired in various aspects of the disclosure.

Although the present disclosure has been described in certain specific aspects, many additional modifications and variations would be apparent to those skilled in the art. In particular, any of the various processes described above can be performed in alternative sequences and/or in parallel (on the same or on ent computing devices) in order to achieve similar results in a manner that is more riate to the requirements of a specific application. It is therefore to be tood that the present disclosure can be practiced otherwise than specifically described t departing from the scope and spirit of the present disclosure.

Thus, s of the present disclosure should be considered in all respects as illustrative and not restrictive. It will be evident to the annotator skilled in the art to freely combine several or all of the aspects discussed here as deemed suitable for a ic application of the disclosure. Throughout this disclosure, terms like "advantageous", "exemplary" or "preferred" indicate elements or dimensions which are particularly suitable (but not essential) to the disclosure or an embodiment f, and may be modified wherever deemed le by the d annotator, except where expressly required. Accordingly, the scope of the invention should be determined not by the embodiments illustrated, but by the appended claims and their equivalents.

Claims (13)

1. A computer implemented transaction system comprising: a database storing system data including at least: user data for a plurality of users; bank account data for one or a plurality of bank accounts; and contract data for contract(s) between the users; a blockchain comprising one or more secure tokens; and at least one processor in communication with the se and the blockchain and configured to: determine that funds have been received in a first bank create secure tokens entative of the funds, as cryptographic assets in the blockchain, and associated with a first user; apply one or more rules based on the contract data to transfer the funds from the first bank account to at least one second bank account, associated with at least one second user; and cryptographically signing the blockchain to associate the secure tokens with the at least one second user.

2. The computer implemented transaction system of claim 1, wherein the processor is further configured to burn the secure token in the blockchain when the funds are withdrawn from bank accounts in the database.

3. The er implemented transaction system of any preceding claim, wherein a bank transaction ID is included in the blockchain upon creation of the secure tokens.

4. The computer implemented transaction system of any preceding claim, further comprising an auditing ace to display information from the database and the blockchain, whereby an r can verify that funds have been processed in accordance with the contract data.

5. The computer implemented transaction system of any preceding claim, wherein the contract data ses data defining a rental agreement between the first user and the second user, wherein the first user is a tenant and the second user is a landlord.

6. A computer-implemented method for processing a transaction, the method sing: determining that funds have been received in a first bank account; creating secure tokens representative of the funds, as cryptographic assets in a blockchain, associated with a first user; applying one or more rules based on contract data stored in a database, to er the funds from the first bank account to at least one second bank account, associated with at least one second user; and cryptographically signing the blockchain to associate the secure tokens with the at least one second user.

7. The computer implemented method of claim 6, further comprising burning the secure token in the hain when the funds are withdrawn from all bank accounts referred to in the ct data.

8. The computer implemented method of claim 6 or 7, wherein a bank transaction ID is included in the blockchain upon creation of the secure tokens.

9. The computer implemented method of any one of claims 6 to 8, further comprising displaying information from the database and the blockchain, whereby an auditor can verify that funds have been processed in accordance with the ct data.

10. The computer implemented transaction system of any preceding claim, wherein the contract data comprises data defining a rental agreement between the first user and the second user, n the first user is a tenant and the second user is a landlord.

11. A computer implemented transaction system comprising: at least one processor; a memory in communication with the at least one processor, configured with instructions for directing the processor to perform the method of any one of claims 6 to 10.

12. A computerised rental payment management system for managing rental payments, the system comprising: a database storing system data including at least: user data for a ity of users, ing a tenant and a landlord; bank account data for one or a plurality of bank accounts; and contract data for rental contract(s) between the tenant and the landlord; a blockchain comprising one or more secure tokens; and at least one processor in communication with the database and the blockchain and configured to: determine that funds have been received in a first bank account from the tenant; create secure tokens entative of the funds, as cryptographic assets in the blockchain, and ated with the tenant; apply one or more rules based on the contract data to transfer the funds from the first bank account to at least one second bank account, associated with the landlord; and cryptographically signing the blockchain to associate the secure tokens with the landlord.

13. A er-implemented rental payment management method comprising: determining that funds have been received from a tenant in a first bank account; creating secure tokens representative of the funds, as cryptographic assets in a blockchain, ated with the tenant; applying one or more rules based on contract data stored in a database, to transfer the funds from the first bank account to at least one second bank account, associated with a landlord; and cryptographically signing the blockchain to associate the secure tokens with the landlord.