WO2015066754A1 - Marketplace transaction improvements - Google Patents

Abstract

A system for an exchange traded marketplace comprising: a buyer / borrower portal; a seller / lender portal; and optionally one or more of: a credit assessment module; an administrator portal; a dealer portal; a digital market module; a document management system; a data storage and retrieval module; and a document dispatch centre.

Description

Marketplace transaction improvements

BACKGROUND OF THE INVENTION

The finance industry transacts in financial products and instruments (such as but not limited to consumer loans, home loans, car insurance and home insurance) with the transactions typically conducted either as a bilateral transaction (buyer / borrower and seller / lender interact directly with each other) or via an intermediary (for example, a human home loan broker or online broker platform) who adds value to the transaction and is compensated for this value added by way of a fee or a margin. Despite the emergence of the Internet as a means through which commercial transactions are executed in a more efficient manner, transactions are generally still ultimately either a bilateral or intermediary style transaction.

Bilateral trade theoretically has the advantage of being a cheaper transactional methodology given the lack of intermediaries or middlemen sitting in between the ultimate buyer / borrower and seller / lender of a financial product or instrument. Therefore no margins or fees need to be paid to third parties with this value being given either to the buyer / borrower, seller / lender or shared between them. Despite this obvious advantage, there are a number of disadvantages to the bilateral methodology.

The first disadvantage of bilateral trade is that the needs and/or wants of the buyer / borrower (including but not restricted to volume, price and time expectations) must be matched with the capability and/or willingness of the seller / lender to meet these needs. This is a common issue across all areas of commerce (goods, services, intangibles and loans etc) and gives rise to the requirement for (a) buyers / borrowers to undertake considerable research to find a seller / lender that is capable and willing to meet the buyer / borrower's needs and wants and (b) sellers / lenders to advertise and employ a sales force to actively promote their offering to these buyers / borrowers. Consequently significant costs are incurred by the buyer / borrower and seller / lender in terms of money, time and opportunity costs. From a buyer / borrower's perspective, they need to balance the potential savings associated with obtaining prices for financial products and instruments from multiple sources against the time taken in obtaining these multiple sources. From the seller / lender's perspective, they need to balance the potential market share arising from having a significant presence in the market

(advertising and sales force) against the potential cost associated with this capability.

The second disadvantage of bilateral trade is the existence of asymmetric information. Asymmetric information refers to the situation where one party to a transaction (buyer / borrower or seller / lender) has more information about the market (supply or demand) than the other and may for example use this information for their own personal gain. Given that the market for financial products and instruments (particularly consumer finance) involves a myriad of participants and is highly fragmented in many cases, asymmetric information is prevalent and leads to uninformed pricing decisions made by buyers / borrowers and sellers / lenders which ultimately leads to economic cost.

A third disadvantage of bilateral trade is the lack of any framework providing an independent and readily accessible market price for financial products and instruments (particularly consumer finance and insurances) for buyers / borrowers and sellers / lenders to base decisions upon. For example, a

Substitute Sheet

(Rule 26) RO/AU borrower may enter into a personal loan with one lender and then subsequently discover that they have overpaid for the loan which only becomes apparent when the borrower identifies a cheaper price elsewhere. Due to the relatively fragmented marketplace for almost all items other than those already traded through a centralised marketplace (such as exchange traded equities or bonds) this lack of price discovery has a negative impact on both buyers and sellers as the price is not solely reflective of demand and supply factors for the item in question.

The emergence of intermediaries (such as brokers and wholesalers) has partially addressed some of the identified disadvantages of bilateral transactions however in doing so have given rise to a number of other disadvantages or issues.

By creating a hub through which buyers and sellers can interact (such as a mortgage broker) an intermediary can assist in matching buyer / borrower's needs and/or wants with a seller / lender's capability to meet these needs and/or wants. This enables buyers / borrowers and sellers / lenders to conserve resources (time and money) to identify appropriate trading partners as this work is undertaken by the intermediary. However the arrangements between the intermediary and the buyer / borrower or seller / lender are still bilateral (intermediary to buyer / borrower and intermediary to seller / lender) in many cases and can be inconsistent or biased towards or against certain participants. This consequently may result in the intermediary matching buyers / borrowers and sellers / lenders upon the basis of what is best for the intermediary instead of what is best for the buyer and seller.

Furthermore, the time and monetary savings to buyers / borrowers and sellers / lenders may be offset in part or entirely by the fees or margins charged by the intermediary. On one hand, the intermediary addresses the trading partner selection issues of bilateral trade but introduces a new issue being that of transparency and price discovery.

Another disadvantage of the existing broker or intermediary model is that price discovery is sporadic. The existing model involves intermediaries gathering information from suppliers of financial products and the suppliers periodically update the prices for financial products. These updates may be either manually performed by the intermediary or performed by the supplier via an electronic link into the intermediary price database. One crucial issue with sporadic price discovery is that at any given time the prices being provided by an intermediary may be stale and not a true reflection of the supply and/or demand for a financial product. Consequently prices for financial products via a broker or intermediary may be inaccurate or obsolete giving rise to opportunity or real costs which are borne by the buyer / borrower and/or seller / lender of financial products.

Similarly, intermediaries can reduce the degree to which asymmetric information leads to buyers / borrowers and/or sellers / lenders making decisions based upon incomplete information as the intermediary is interacting with a number of buyers / borrowers and sellers / lenders at any given time and more aware of supply and demand changes than individual participants. The intermediary can provide this information to buyers / borrowers and sellers / lenders to reduce the risk of the buyer / borrower and seller / lender making decisions on incomplete information. However, given the potential existence of inconsistent bilateral relationships there is significant risk that the intermediary may have a vested interest in sharing this information more readily with one party than another. Therefore, asymmetric information, whilst reduced, is not completely eradicated.

2

Substitute Sheet

(Rule 26) RO/AU Intermediaries can use their position in the market for financial products and instruments (including but not restricted to consumer finance and insurances) as the bridge between buyers / borrowers and sellers / lenders to reduce the price making power that sellers / lenders have over buyers / borrowers (for items that are non-discretionary or scarce) by playing sellers / lenders off against one and other to deliver a better price outcome for the buyer / borrowers. However, whilst the price of a financial product or instrument may be negotiated downwards via the intermediary the price making power still rests with the seller / lender.

The unique disadvantages of intermediaries are largely tied to the potential for conflicts of interest. Because intermediaries are remunerated by sellers / lenders (and at times buyers / borrowers) and the compensation terms are not always identical for all relationships there is always the potential for an intermediary to not be completely agnostic as to whom they put forward as the most appropriate partner for a transaction. Factors influencing intermediaries don't always have to be monetary in nature and can be driven by any number of alternative factors such as legacy relationships.

There are a number of disadvantages of both existing bilateral and intermediary styles of transacting in the market for financial products and instruments. One disadvantage is that there is no centralised credit assessment process available for bilateral and intermediary styles of transacting meaning that a buyer / borrower may need to go through multiple credit assessments with various sellers / lenders in order to secure a financial product or instrument. Not only is this process potentially quite time consuming and costly for all parties (buyers / borrowers completing multiple applications, sellers / lenders assessing multiple and potentially erroneous applications and intermediaries facilitating multiple applications that may not proceed and be monetised) it can also have significant consequences for the buyer / borrower in that independent third party credit reporting agencies will record each credit assessment and potentially apply a negative credit weighting due to multiple applications. Therefore, a buyer / borrower may be undertaking multiple applications in order to have choice as to which seller / lender they transact with however in the process they may be adversely impacting their credit rating with a third party credit reporting agency which can ultimately lead to less lenders being willing to lend to the buyer / borrower due to their impaired credit. Ultimately, the buyer / borrower may end up with a worse outcome by 'shopping around' than they would have by engaging one seller / lender in the first place.

A second disadvantage of both existing bilateral and intermediary styles of transacting in the market for financial products and instruments is associated with the structure of the market for financial products and instruments (in particular, but not restricted to, consumer finance products such as home or personal loans). The structure of this market at present is that a buyer / borrower will execute an agreement with a seller / lender and this agreement will be for a certain term, rate and amount. The transaction is executed on the basis of the buyer / borrower credit rating at the time of execution which is a static value. However, if during the life of the agreement, the financial circumstances or behavioural aspects of the buyer / borrower change (improve or deteriorate) then the buyer / borrower nor the seller / lender can monetise any benefits associated with credit rating enhancements or manage any risks associated with credit rating deterioration during the life of the agreement. This situation means that the price executed at the commencement of the agreement is based upon a credit score established historical point in time and not necessarily reflective of the current credit score which may or may not be better or worse. This inevitably leads to the agreement being

3

Substitute Sheet

(Rule 26) RO/AU mispriced at some stage during the life of the agreement. Any remedial actions that are available to buyers / borrowers or sellers / lenders are manual, time consuming and inefficient.

A third disadvantage of both existing bilateral and intermediary styles of transacting in the market for financial products and instruments is the absence of an automated process for buyers / borrowers and sellers / lenders to signal to the market their willingness to enter into a transaction based upon a pre-determined variable (usually but not limited to price). The current process to do this for buyers / borrowers would be for them to engage either bilaterally or via an intermediary financial product and instrument provider and advise them of their willingness to transact at a certain price (or any other variable) and for them to contact the buyer / borrower in the event that an offer is forthcoming that would enable a transaction to take place. This process is highly manual and prone to human error which could lead to the buyer / borrower missing out on any opportunities that may present themselves.

The reference to any prior art in this specification is not, and should not be taken as, an

acknowledgement or any form of suggestion that the prior art forms part of the common general knowledge.

SUMMARY OF THE INVENTION

In a first aspect of the invention, there is provided a system for an exchange traded marketplace comprising: a buyer / borrower portal; a seller / lender portal; and optionally one or more of: a credit assessment module; an administrator portal; and a dealer portal; a digital market module; a document management system; a data storage and retrieval module; a document dispatch centre.

In another aspect of the invention, there is provided a system for an exchange traded marketplace comprising: a credit assessment module; and optionally one or more of: a digital market module; a document management system; a data storage and retrieval module; and a document dispatch centre.

In another aspect of the invention, there is provided a system for an exchange traded marketplace comprising: a buyer / borrower portal; a seller / lender portal; and optionally one or more of: an administrator portal; and a dealer portal.

In some embodiments of these aspects there is further provided a website. The website may optionally comprise one or more of: a general information module; a registration module; a login module and an app download module. The general information module may optionally comprise one or more of a market information module and a broadcast module. The credit assessment module may optionally comprise one or more of a credit assessment engine; a big data module; a psychometric profile model and an ancillary credit source module.

A buyer / borrower portal according to the invention may optionally comprise one or more of a buyer / borrower dashboard; an application module; a buyer / borrower analytics module; a BBYAPCAP module; an Order (Credit Pending) Module; and a buyer / borrower digital market interface. The buyer / borrower dashboard may optionally comprise one or more of a product simulator; an advertising module and a communications module. The BBTAPCAP module may optionally comprise one or more of BBTAP module and a BBCAP module.

Substitute Sheet

(Rule 26) RO/AU A seller / lender portal according to the invention may optionally comprise one or more of an administrator portal; a dealer portal and a SLTAPCAP portal. The administrator portal may comprise one or more of a login module; an administrator dashboard; a risk management module; an administrator analytics module; an administrator communications module and an administrator digital market interface. The dealer portal may comprise one or more of a login module; a dealer dashboard; a transaction module; a dealer analytics module, a dealer communications module and a dealer digital market interface. The SLTPCAP module may comprise one or more of a SLTAP module and a SLCAP module.

A digital market module according to the invention may optionally comprise one or more of a market stacker module; a trade execution module; a market control module; an order management module and a transaction router.

A data storage and retrieval module according to the invention may optionally comprise one or more of a client data module; a market statistics database; a credit database; a document warehouse and an advertiser database. The client data module may optionally comprise one or more of a buyer / borrower database and a seller / lender database.

In another aspect of the invention there is provided a method for operating an exchange traded marketplace comprising: receiving an item of information from a prospective buyer / borrower;

receiving an item of information from a prospective seller / lender; and optionally performing a credit assessment in respect of the prospective buyer / borrower.

The invention also provides a method for operating an exchange traded marketplace comprising performing a credit assessment in relation to a prospective buyer / borrower.

In another aspect of the invention, there is a computer implemented method for calculating a transaction adjusted price for an item in a marketplace comprising adding to the offer price an amount based at least on at least one additional transaction-related amount which optionally comprises or is optionally derived from one or more of brokerage, a value added tax, and / or a fee. In some preferred embodiments, the marketplace is an exchange traded marketplace.

In another aspect, the invention provides a system for calculating a transaction adjusted price for an item in a marketplace comprising: a computer-implemented database; price management logic for storing an offer price and related data in the computer-implemented database; and pricing logic associated with the transaction and configured to determine an adjusted price for the sale of an item on the marketplace; wherein the transaction adjusted price comprises the offer price plus at least one additional transaction-related amount which optionally comprises or is optionally derived from one or more of brokerage, a value added tax and / or a fee. In some preferred embodiments, the marketplace is an exchange traded marketplace.

In another aspect, the invention provides a computer implemented method for calculating a contingency adjusted price for an item in a marketplace comprising adding to the offer price an amount based at least on at least one additional risk-related amount which optionally comprises or is optionally derived from one or more of a late payment fee, additional interest, and / or a break fee. In some preferred embodiments, the marketplace is an exchange traded marketplace.

Substitute Sheet

(Rule 26) RO/AU Another aspect is a system for calculating a contingency adjusted price for an item in a marketplace comprising: a computer-implemented database; price management logic for storing an offer price and related data in the computer-implemented database; and pricing logic associated with the transaction and configured to determine an adjusted price for the sale of an item on the marketplace; wherein the contingency adjusted price comprises the offer price plus at least one additional risk-related amount which optionally comprises or is optionally derived from one or more of a late payment fee, additional interest, and / or a break fee. In some preferred embodiments, the marketplace is an exchange traded marketplace.

I another aspect, there is a computer implemented method for operating an exchange traded marketplace comprising the steps of: presenting to a seller information based on an item of non-price information from a potential purchaser; and providing to the seller the option of selecting a potential purchaser to purchase the item based at least partially on that non-price information.

In another, there is a system for an exchange traded marketplace comprising: at least one computer- implemented database; price management logic for storing an offer price and related data in the computer-implemented database; non-price information logic for storing an item of non-price information in a computer-implemented database; and display logic associated with the non-price information and configured to display to a user information based on an item of non-price information together with the means to select at least one option based on the non-price information; wherein the at least one option comprises an offer of sale to potential purchaser based on at least one item of non-price information.

Another aspect provides a computer implemented method for managing a partial fill in an exchange traded marketplace comprising: receiving an order; receiving an offer; identifying a partial fill in respect of the order and the offer; providing to the offeror at least one option in respect of filling the order wherein the at least one option comprises one or more of: increasing the order to accommodate the order; and removing the offer on reaching a predetermined threshold.

In yet another aspect, there is a system for managing a partial fill in an exchange traded marketplace comprising: at least one computer-implemented database; order logic for storing an order in a computer-implemented database; offer logic for storing an order in a computer-implemented database; partial fill logic associated with the order logic and offer logic and configured to determine the occurrence of a partial fill in respect of the order; and option logic associated with the partial fill logic to provide to the offeror at least one option in respect of filling the order; wherein the at least one option comprises one or more of: increasing the order to accommodate the order; and removing the offer on reaching a predetermined threshold.

In another aspect of the invention, there is provided a computer implemented method for operating an exchange traded marketplace comprising receiving an order and adjusting the order based on a statistical probability.

Another aspect provides a system for an exchange traded marketplace comprising: at least one computer-implemented database; order logic for storing an order in a computer-implemented database; adjustment logic associated with the order logic and configured to adjust the order based on a statistical probability.

Substitute Sheet

(Rule 26) RO/AU BRIEF DESCRIPTION OF DRAWINGS

Figure 1 is a schematic block diagram providing an overview of a system according to an embodiment of the present invention.

Figure 2a is an illustration of the System Website according to an embodiment of the present invention.

Figure 2b is an illustration of a general information module contained within the System Website according to an embodiment of the present invention.

Figure 2c is an illustration of a registration module contained within the System Website according to an embodiment of the present invention.

Figure 3 is an illustration of a credit assessment module according to an embodiment of the present invention.

Figure 4a is an illustration of a buyer / borrower portal according to an embodiment of the present invention.

Figure 4b is an illustration of a buyer / borrower portal contained within the buyer / borrower portal according to an embodiment of the present invention.

Figure 4c is an illustration of a BBTAPCAP module contained within the buyer / borrower portal according to an embodiment of the present invention.

Figure 5a is an illustration of a seller / lender portal according to an embodiment of the present invention.

Figure 5b is an illustration of a SLTAPCAP module contained within the seller / lender portal according to an embodiment of the present invention.

Figure 5c is an illustration of an administrator portal contained within the seller / lender portal according to an embodiment of the present invention.

Figure 5d is an illustration of a dealer portal contained within the seller / lender portal according to an embodiment of the present invention.

Figure 6 is an illustration of a digital market module contained within the seller / lender portal according to an embodiment of the present invention.

Figure 7a is an illustration of a data storage and retrieval module according to an embodiment of the present invention.

Figure lb is an illustration of a client data module contained within the data storage and retrieval module according to an embodiment of the present invention.

Figure 8 is a flowchart demonstrating an example credit assessment process associated with an application for a financial product that has been initiated from the buyer / borrower portal and how various modules within the credit assessment module may extract credit related data to generate a credit score and where the outputs from this process are directed.

^ Substitute Sheet

(Rule 26) RO/AU Figure 9 is an example of the buyer / borrower dashboard display that a buyer / borrower may access via the buyer / borrower portal and the various modules contained within the buyer / borrower dashboard.

Figure 10 is an example of the buyer / borrower digital market interface display that a buyer / borrower may access via the buyer / borrower portal and the various modules contained within the buyer / borrower digital market interface.

Figure 1 1 is an example of a buyer / borrower order pad which is accessible via the buyer / borrower portal.

Figure 12 is an example of where a buyer / borrower selects the 'At Market' radio button contained within the order pad which is accessible via the buyer / borrower portal and how the order pad configuration appears.

Figure 13 is an example of where a buyer / borrower selects the 'Work a Bid' radio button contained within the order pad which is accessible via the buyer / borrower portal and how the order pad configuration appears.

Figure 14 is an example of where a buyer / borrower selects the 'Work a Bid' radio button contained within the order pad and enabled the Bid-Tracker and the impact on the bid parameters and probability values of the bid.

Figure 15 is an example of the re-ordering of offers within a market once BBTAP Module has adjusted the raw prices contained in the Market Stacker Module (710) to include all upfront fees, charges and taxes that are relevant.

Figure 16 is an example of the re-ordering of offers within a market once BBCAP Module has adjusted the raw prices contained in the Market Stacker Module (710) to include all contingency fees, charges and taxes that are relevant based upon the probability of late payment.

Figure 17a is an example of the market display that a buyer / borrower may view in their buyer / borrower digital market interface where they elect to display the periodical repayment amount.

Figure 17Jb is an example of the market display that a buyer / borrower may view in their buyer / borrower digital market interface where they elect to display the total repayment amount.

Figure 18 is an example of the administrator dashboard display that an administrator may access via the seller / lender portal and the various modules contained within the administrator dashboard. Figure 19 is an example of the administrator risk and analytics display that an administrator may access via the seller / lender portal and the various modules contained within the administrator risk and analytics section.

Figure 20 is a flowchart demonstrating the BBTAP Module process within an example system and how an application for a financial product enables the BBTAP Module to calculate the associated fees and charges associated with an offer and embed these costs into raw market prices.

Figure 21 is a flowchart demonstrating the BBCAP Module process within the system and how an application for a financial product in conjunction with the probability of late payment for a buyer / g

Substitute Sheet

(Rule 26) RO/AU borrower enables the BBCAP Module to calculate the potential fees and charges associated with an offer and embed these costs into raw market prices.

Figure 22 is a flowchart demonstrating how an order is stored in the Order (Credit Pending) Module whilst awaiting credit assessment and then once received the alternatives that a buyer / borrower has to amend or execute this transaction.

Figure 23 is a flowchart demonstrating the potential alternatives associated with managing partially filled or non-marketable parcels and the outcomes of these alternatives.

Figure 24 is a flowchart that demonstrates the manner in which a Bid Identification Number (BIN) is matched to an Offer Identification Number (OIN) to generate a Transaction Identification Number (TIN and consequently this TIN is used by the Document Management System to automatically construct bespoke financial product documentation for electronic execution.

Figure 25 is an example of the market display that a dealer may view in their dealer digital market interface and the way in which they can enter into an out of market transaction by clicking on the stories of the buyer / borrower.

DETAILED DESCRIPTION

This application claims priority from the following prior patent applications, the contents of each of which are incorporated by reference herein: PCT publication number WO 2014/071447 and Australian provisional patent application numbers: 2014901690, 2014901620 and 2014900973.

It is convenient to describe the invention herein in relation to particularly preferred embodiments, some of which relate to an implementation using 'Dfinanz.com' as an administrator of a system and / or method of the invention. However, the invention is applicable to a wide range of situations and it is to be appreciated that other constructions and arrangements are also considered as falling within the scope of the invention. Various modifications, alterations, variations and / or additions to the construction and arrangements described herein are also considered as falling within the ambit and scope of the present invention.

Legend

NumberDescription

101 USER

102 COMPUTER/TABLET/SMART PHONE/PC

105 DFINANZ ADMINITRATOR INTERFACE

110 DFINANZ WEBSITE

120 CREDIT ASSESSMENT MODULE

130 BUYER / BORROWER PORTAL

140 SELLER / LENDER PORTAL

Substitute Sheet

(Rule 26) RO/AU 143 SLTAPCAP MODULE

144 SLTAP MODULE

145 SLCAP MODULE

150 DIGITAL MARKET MODULE

160 DOCUMENT MANAGEMENT MODULE

170 DATA STORAGE AND RETRIEVAL MODULE

180 DOCUMENT DISPATCH CENTRE

190 CREDIT BUREAU

195 THIRD PARTY CREDIT DATA SOURCES 201 GENERAL INFORMATION MODULE

202 MARKET INFORMATION MODULE

203 BROADCAST MODULE

210 REGISTRATION MODULE

211 NEW USER FORM

212 TERMS AND CONDITIONS MODULE

220 LOGIN MODULE

230 APP DOWNLOAD MODULE

300 CREDIT ASSESSMENT ENGINE

301 BIG DATA MODULE

302 DFINANZ PSYCHOMETRIC PROFILE MODEL

303 ANCILLARY CREDIT SOURCE MODULE

400 BUYER / BORROWER DASHBOARD

401 PRODUCT SIMULATOR

402 ADVERTISING MODULE

403 COMMUNICATIONS MODULE

410 APPLICATION MODULE

420 BUYER / BORROWER ANALYTICS MODULE

430 BBTAPCAP MODULE

431 BBTAP MODULE

432 BBCAP MODULE

Substitute Sheet (Rule 26) RO/AU 440 ORDER (CREDIT PENDING) MODULE

450 BUYER / BORROWER DIGITAL MARKET INTERFACE

500 ADMINISTRATOR PORTAL

501 LOGIN MODULE

510 ADMINISTRATOR DASHBOARD

520 RISK MANAGEMENT MODULE

530 ADMINISTRATOR ANALYTICS MODULE

540 ADMINISTRATOR COMMUNICATIONS MODULE

550 ADMINISTRATOR DIGITAL MARKET INTERFACE 600 DEALER PORTAL

601 LOGIN MODULE

610 DEALER DASHBOARD

620 TRANSACTION MODULE

630 DEALER ANALYTICS MODULE

640 DEALER COMMUNICATIONS MODULE

650 DEALER DIGITAL MARKET INTERFACE

700 DIGITAL MARKET MODULE

710 MARKET STACKER MODULE

720 TRADE EXECUTION MODULE

730 MARKET CONTROL MODULE

740 ORDER MANAGEMENT MODULE

760 TRANSACTION ROUTER

800 CLIENT DATA MODULE

801 BUYER / BORROWER DATABASE

805 SELLER / LENDER DATABASE

810 MARKET STATISTICS DATABASE

820 CREDIT DATABASE

830 DOCUMENT WAREHOUSE

840 ADVERTISER DATABASE

Substitute Sheet (Rule 26) RO/AU The exchange traded marketplace for financial products and instruments provides an electronic means to buy / borrow and / or sell / lend financial products, instruments and their respective derivative products without the requirement for manual interaction (verbal or electronic

communication).

Users can use any electronic device (including but not limited to computer, tablet, smartphone or PC) to access the Dfinanz Website (1 10) (refer to Figure 2a). Any user can obtain general information regarding Dfinanz and the digital market for consumer finance via the General Information Module (201) in addition to generic market information (such as but not limited to closing prices for specific credit markets, lending volumes, high and low prices for the trading session) via the Market

Information Module (202). Any user may also be able to view public messages from Dfinanz that are being broadcast (for example, system maintenance work schedules) via the Broadcast Module (203) (refer to Figure 2b).

A buyer / borrower can register with Dfinanz via the Registration Module (210). Within this section of the Dfinanz Website (1 10) the borrower can access the New User Form (21 1) and create a profile using a minimum of two pieces of information being their email address and password. The New User Form (21 1) may also enable the user to create a profile by linking another account such as a social media account (such as Facebook or Twitter) or a pre-existing bank account or other account, to the application which may for example prepopulate the relevant fields within the New User Form (21 1). At the bottom of the New User Form (211) are the rights and obligations of the user via the Terms and Conditions Module (212). The content in this module may be text or video (refer to Figure 2c).

When the buyer/ borrower has reviewed the terms and conditions they may acknowledge that they agree to the terms and conditions and then submit the New User Form (21 1). Acknowledgement may be either by the buyer / borrower clicking a button or verbally acknowledging that they understand with a recording taken of the buyer / borrowers verbal acceptance. Upon submitting this form, a specific profile is created in the Buyer / Borrower Database (801) contained in the Client Data Module (800) housed in the Data Storage and Retrieval Module (170). Once this is complete, a Buyer / Borrower Portal (130) is created for the buyer / borrower through which they can access the digital market for consumer finance.

A seller / lender can register with Dfinanz via the same process however their New User Form (211) may contain additional fields unique to sellers / lenders of financial products. Upon submission of their application, Dfinanz may contact the seller / lender to obtain the necessary legal, risk and regulatory information required to create their unique profile in the Seller / Lender Database (805) contained in the Client Data Module (800) housed in the Data Storage and Retrieval Module (170). Once this process is complete a Seller / Lender Portal (140) is created for the entity within which two different styles of portals being the Administrator Portal (500) and Dealer Portal (600) may be housed.

Once the relevant portals have been created (Buyer / Borrower Portal, Seller / Lender Portal, Administrator Portal and Dealer Portal) the authorised users can access their portals via the Dfinanz Website (110) by logging in via the Login Module (220). This may involve entering their unique username and password.

Substitute Sheet

(Rule 26) RO/AU Within the Dfinanz Website (1 10) there is the ability for any registered user to download Dfinanz applications to their relevant portals via the App Download Module (230). The applications may enhance the capabilities of their respective portals in addition to providing access to premium services.

The Dfinanz Administrator Interface (105) provides authorised Dfinanz staff with system administrator access into all aspects of Dfinanz either via the Dfinanz Website (1 10) or directly into the Credit Assessment Module (120). Authorised users may use this interface to monitor behaviour of users in the marketplace, performance of the credit assessment process or perform system maintenance.

Credit Assessment Module (120)

The Credit Assessment Module (120) is the component of the system that enables Dfinanz to generate credit scores for buyers / borrowers and thereby direct the orders to obtain financial products to the correct credit market for that buyer / borrower. Within the Credit Assessment Module (120) there are four modules housed which are the Credit Assessment Engine (300), Big Data Module (301), Dfinanz Psychometric Profile Module (302) and the Ancillary Credit Source Module (303) (refer to Figure 3).

The Credit Assessment Engine (300) is the core credit assessment model which contains a credit scorecard with various weightings ascribed to different variables related to a buyer / borrower and their specific financial product requirement. For example, a borrower with no dependants may receive a score of +10 however a borrower with four dependants receive a score of -2 or a borrower that has previously defaulted on a loan may receive a score of -6 whilst a borrower that has never defaulted on a loan may receive a score of +3. There are many different variables that could determine the credit score produced by the credit engine such as age, number of past employers in the last 2 years, number of vehicles etc. In some embodiments, the inputs into the credit assessment engine are updated from time to time and in some embodiments continually updated.

The values that are used to populate the credit scorecard are obtained from two sources within the system being (1) buyer / borrower declared information captured when a borrower completes an application for a financial product through the Application Module (410) located within the Buyer / Borrower Portal (130) and (2) direct external credit information about the buyer / borrower extracted from a Credit Bureau (190). Once complete, the credit scorecard then calculates a credit score for that particular buyer / borrower.

The Credit Assessment Engine (300) then takes this credit score and applies a series of adjustments to the credit score by complimenting it with information from the Big Data Module (301), Dfinanz Psychometric Profile Module (302) and the Ancillary Credit Source Module (303) to enhance the accuracy of the credit score (Refer Figure 8).

The Big Data Module (301) uses Big Data analysis to populate a scorecard which results in a Big

Data score. The Big Data score may determine the probability of default and late payment. Big Data will involve cross-matching the profile data of a borrower against their activities on the internet to derive a probability of behaviour based upon the websites that a user frequents and the credit score associated with this. In one example implementation, this score is then automatically inserted into a bell curve of all Big Data scores in order to ascertain how many standard deviations the score is away

Substitute Sheet

(Rule 26) RO/AU from the mean. The standard deviation distance from the mean then generates an adjustment value which is obtained by an adjustment table which lists standard deviation values and its corresponding adjustment value. The resultant adjustment value is then added to or subtracted from the credit score obtained from the credit scorecard held in the Credit Assessment Engine (301). For example, a buyer / borrower is assessed to have a credit score of 800 and a Big Data score of 534. The Big Data score mean is 670 and the difference between the 534 and 670 is 1 standard deviation. On this basis a negative adjustment of -7 (extracted from the adjustment tables) is applied to the credit score of 800 to adjust it down to 793. It will be appreciated by the skilled addressee that the Big Data score can be used in other ways as well.

The Dfinanz Psychometric Profile Module (302) performs a psychometric assessment on buyers / borrowers in order to generate a psychometric profile which can then be used by the Credit

Assessment Engine (300) to compliment the core credit score. The psychometric profile generated may provide insights concerning probability of default and late payment. The data used by the Dfinanz Psychometric Profile Module to produce the profile is obtained from (a) tracking the behaviour of the buyer / borrower in the system (for example, did the buyer / borrower undertake any of the voluntary tutorials concerning the operation of the market or did they simply apply for a loan immediately), (b) the behaviour of the buyer / borrower in the loan application process (for example, did the buyer / borrower state a round number for their loan requirement such as $20,000 or did they stipulate a very specific amount such as $20,345) and (c) any other processes associated with the system which assists Dfinanz to construct a psychometric profile (such as games). Psychometric Profiling may include things such as the speed at which the borrower selects products, selects amounts, the accuracy of spelling, formatting and other inputs into the Application Form. The psychometric profile is then scored and bell curved in the same way as the Big Data process and a resultant adjustment (positive or negative) is applied to the credit score obtained from the credit scorecard held in the Credit Assessment Engine (301).

The Ancillary Credit Source Module (303) is the component of the Credit Assessment Module (120) that collects additional credit data from Third Parties Credit Data Sources (195) such as utility providers or real estate agents and provides Dfinanz with further understanding of the behaviour of the buyer / borrower regarding bill payments to better understand the probability of late payment or default. This ancillary credit data is then able to generate another profile for the buyer / borrower and generate a score. This score may then be adjusted, for example it may be bell curved, for example, in the same way as the Big Data process described above and a resultant adjustment (positive or negative) may applied to the credit score obtained from the credit scorecard held in the Credit Assessment Engine (301).

Upon completion of the entire credit assessment process by the Credit Assessment Engine (300) and the generation of an adjusted credit score for the buyer / borrower the respective credit market to which the buyer / borrowers financial product order may be directed is determined. For example, a buyer / borrower may achieve an adjusted credit score of 655 which is automatically compared against a table of credit markets and their upper and lower thresholds housed in the Credit

Assessment Engine (300). Based upon these thresholds the Credit Assessment Engine (300) determines that the financial product order should be sent to Credit Market 5 in which orders from

Substitute Sheet

(Rule 26) RO/AU other buyers / borrowers of comparable credit quality can be matched against sellers / lenders willing to supply liquidity into that market.

Buyer / Borrower Portal (130)

The present invention may also incorporate a Buyer / Borrower Portal (130). An important (however not exclusive) purpose of this portal is to enable buyers / borrowers to apply for a financial product and undergo a credit assessment via the Credit Assessment Engine (300) housed in the Credit Assessment Module (120) for the purposes of having their financial product request directed to the correct credit market and transact.

Upon completing the registration process via the Registration Module (210) a buyer / borrower can log into their portal via the Login Module (220) housed in the Dfinanz Website (1 10). Upon successfully logging in the buyer / borrower is directed to the Buyer / Borrower Dashboard (400) located in their portal. The Buyer / Borrower Dashboard (400) displays a range of markets that the buyer / borrower may be interested in monitoring (Refer Figure 9). Upon first logging into the Buyer / Borrower Dashboard the market prices are predetermined default credit markets as the buyer / borrower at that time has not undergone any credit assessment process. Therefore, the market prices displayed are indicative only based upon an average credit rating.

Once the buyer / borrower has undergone a credit assessment for a specific loan request, the market prices displayed in the Buyer / Borrower Dashboard (400) may change from the default average credit rating to the market prices relating to the specific credit markets corresponding with the buyer / borrowers assessed credit score. Upon each subsequent application for a financial product any changes to the buyer / borrower credit rating may be captured and the market prices in the Buyer / Borrower Dashboard (400) altered in response to any change in the buyer / borrower credit rating. In this way, the market prices displayed in the Buyer / Borrower Dashboard can be a true reflection of the current creditworthiness of the buyer / borrower.

Also contained in the Buyer / Borrower Dashboard (400) may be a Product Simulator (401). This simulator has at least two elements of functionality. The first element is the functionality to enable a buyer / borrower to perform scenario and cost analysis for a financial product (such as an unsecured personal loan). The borrower may be able to adjust the principal amount or the term of the loan to ascertain the periodical repayments or alternatively set the periodical payment amount and solve for the principal amount or the term of the financial product. The Product Simulator (401) may extract live market prices relevant to the financial product to provide the buyer / borrower with an accurate and potentially executable financial product scenario. In the situation where the buyer / borrower has not yet undergone the credit assessment process the market prices sourced by the Product Simulator (401) may be based upon a default credit rating. In the situation where the buyer / borrower has undertaken a credit assessment for a financial product the Product Simulator (401) may extract live market prices from the respective credit market that corresponds with the buyer / borrower credit score.

The second element is the functionality to enable the buyer / borrower to perform scenario analysis on for a hypothetical financial product transaction in order to determine the impact of a change in the structure of the financial product on the buyer / borrower's credit score for that particular transaction.

Substitute Sheet

(Rule 26) RO/AU This may only be available to buyer / borrowers that have undertaken a credit assessment and generated a credit score. For example, a buyer / borrower may undertake a credit assessment process facilitated by the Credit Assessment Engine (300) and achieved a credit score of 800 for a specific financial product request and the Credit Assessment Engine (300) determines that the appropriate credit market for this proposed transaction is Credit Market 5 for which the live market price is 9.50%.

The buyer / borrower is then able to use the Product Simulator (401) to adjust the parameters of the proposed transaction (such as reducing the principal or changing the product for example from an unsecured personal loan to a secured personal loan). Once the scenario adjustment is complete the buyer / borrower can perform a calculation to determine whether there is any change in their credit score and consequently if there is any change in the price of the financial product desired. The Product Simulator performs a calculation on the new proposed transaction structure and determines for example that the impact on the buyer / borrower credit score has now improved from 800 to 900 and that the correct credit market for the transaction is now Credit Market 4 instead of Credit Market 5 and consequently the live market price for the transaction is now 9.01 % instead of 9.50%. The buyer / borrower can then submit their order for a financial product directly from the Product Simulator (401) based upon the optimised financial product structure and have the order directed to Credit Market 4 to avail of the lower rate of interest.

The Buyer / Borrower Dashboard (400) may also have an Advertising Module (402). This module may display direct advertising from potential liquidity providers or other businesses that offer services that are related to the financial product being sought. For example, a buyer / borrower may be performing a simulation for the purposes of refinancing a home loan. The Advertising Module (402) may identify the geographical location of the buyer / borrower from the Buyer / Borrower Database (801) and any other personal information that provides insight into the buying preferences of the buyer / borrower from the Big Data Module (301). The Advertising Module (402) then takes this personal data of the buyer / borrower and combines it with the financial product preferences to determine the optimal service provider to the buyer / borrower for products related to their financial product request. The Advertising Module (402) then extracts an advertisement from the Advertiser Database (840) and display this in the Buyer / Borrower Dashboard (401) with an embedded hyperlink which, when clicked, opens up the advertiser's webpage. Clicking such a link may trigger an advertising payment, or a successful sale of the related product may trigger an affiliate payment back to Dfinanz or another organisation.

Also contained within the Buyer / Borrower Dashboard (400) may be a Communications Module (403). This module may display messages and alerts that are relevant to the buyer / borrower specifically such as status updates regarding a live order that the buyer / borrower may have in the Market Stacker Module (710) or the completion of the credit assessment by the Credit Assessment Engine (300). The Communications Module (403) may also generate general alerts such as in relation to a significant event that has occurred in a particular market of interest or new product offerings from Dfinanz. The buyer / borrower can also initiate communication with Dfinanz via the Communications Module (403) via an instant messaging service. All messages may be displayed in a dedicated section of the Buyer / Borrower Dashboard (400).

Substitute Sheet

(Rule 26) RO/AU Located in the Buyer / Borrower Dashboard (400) may be a button for the buyer / borrower to create a new request for a financial product. When clicked, the buyer / borrower may be directed to the Application Module (410) to complete the application form for a financial product.

The Application Module (410) contains an application form for a financial product that the buyer / borrower can complete. This form may contain a number of mandatory and optional fields that can be populated with information required for the credit assessment process such as name, address, driver's license and financial product specific information such as amount, term and repayment frequency etc. There may also be an optional section in this application form titled for example 'My Story' within which the borrower can provide some personal context concerning the requirement for the financial product request (for example a buyer / borrower can explain that they are borrowing money in order to make modifications to their home due to a family member having a disability). Supporting documentation such as scanned or digital images of passports, driver's licenses, utility bills etc. can be attached to this application form as well for verification purposes.

An additional feature of the application form relates to the refinancing of financial products where the buyer / borrower may incur a fee or break cost associated with early termination of their existing financial product. For example, a buyer / borrower may wish to refinance their home loan before the expiration of the facility. Consequently, the existing lender may seek to charge costs associated with the refinance such as a $2,000 break cost fee. The buyer / borrower can obtain these costs and input them into a field in the application form titled 'Refinancing Costs'. These costs are then captured by the system as an additional cash flow that may need to be paid by the new lender / liquidity provider once the refinance has taken place. These additional costs associated with refinance are then captured by the BBTAPCAP Module (430) and added to the upfront fees, charges and taxes associated with securing a new financial product and consequently the raw market prices that are extracted from the Market Stacker Module (710) are adjusted for upfront and where applicable the refinancing costs to produce an array of adjusted market prices in the Buyer / Borrower Digital Market Interface (450).

Embedded into the Application Module (410) is a psychometric assessment process which analyses the manner in which the buyer / borrower completes the application form. This process may consider the manner in which the buyer / borrower uses correct grammar in the application or uses a rounded or exact amount when stipulating the face value of the financial product they are applying for. Other relevant psychometric data may be collected or generated, for example with a questionnaire relating to saving and spending habits. The data obtained from this psychometric assessment is attached to the application for and upon submission is directed to (a) Dfinanz Psychometric Profile Model (302) and (b) the Buyer / Borrower Database (801).

An application form can be cancelled at any time or when mandatory fields are completed it can be submitted. Upon clicking 'Cancel' the information contained in the form up until that point is sent to the Buyer / Borrower Database (801 ) for retrieval at a later time. Upon clicking 'Submit' a unique order number is generated and the system then communicates the information to (in this example) at least four modules of the system being (1) the Credit Assessment Module (120) for further use by the Credit Assessment Engine (300) and the Dfinanz Psychometric Profile Model (302) for the purposes of assessing the creditworthiness of the be borrower (2) the Buyer / Borrower Database (801) for the

Substitute Sheet

(Rule 26) RO/AU information to be stored under the buyer / borrower profile and (3) the Order (Credit Pending) Module (440) where a unique Bid Identification Number is created (which may be comprised of the unique buyer / borrower Participant ID number or PID and an order number) and the order is held whilst awaiting credit assessment. The unique Bid Identification Number may also be displayed in the Buyer / Borrower Dashboard (400) as a hyperlink that the buyer / borrower can click at a later time for example to retrieve their application form, information relevant to the bid, or a status of the bid, etc.

Also contained in the Buyer / Borrower Portal (130) may be a Buyer / Borrower Analytics Module (420). This section of the Buyer / Borrower Portal (130) provides buyers / borrowers with access to peer benchmarking, useful tips as to how they can potentially improve their credit rating, back testing of their historical buying / borrowing decisions, a detailed history of the buyer / borrower's previous transactions and other analytical information about their behaviour within Dfinanz.

Also contained in the Buyer / Borrower Portal (130) is the BBTAPCAP Module (430). This module adjusts the raw market prices that are extracted from the Market Stacker Module (710) and displayed to the buyer / borrower in the Buyer / Borrower Digital Market Interface (450). This is done by embedding actual and contingency costs associated with the financial product being sought by the buyer / borrower into the interest rate being charged by the liquidity provider. This is done in order to standardise the offers in a specific marketplace as different liquidity providers may have different establishment and default fees for the same financial products and enable offers to be ordered based upon all actual and contingency costs associated with a financial product. IN some implementations, the BBTAPCAP Module (430) has a default setting of Off and is only enabled in the event that a buyer / borrower has submitted an application for a financial product. The BBTAPCAP (or Buyer / Borrower Trade Adjusted Price and Contingency Adjusted Price) Module (430) houses two modules being the BBTAP Module (431) and the BBCAP Module (432).

The BBTAP Module (431) is focused on adjusting an executable offer price or rate of a financial product to include relevant upfront fees, charges and taxes (and where applicable any costs and taxes associated with refinancing an existing facility that are payable to an old financier). For example, a liquidity provider (bank or Loan Company) may be willing to lend money to a borrower at 9.50% however they may also seek to charge an establishment fee for the loan of $100 which may also attract GST or VAT as the establishment fee may be deemed to be a service. Consequently, the true price for the loan will be 9.50% plus $100 plus $10 (assuming that GST or VAT is 10%). Another liquidity provider (bank or Loan Company) may be willing to charge 9.55% to lend money to the borrower however they will not charge an establishment fee and consequently there are no GST or VAT implications for the borrower.

In this situation, the BBTAP Module (431) extracts all upfront and refinancing fees and respective tax adjustment rates for all liquidity providers in a marketplace from the Seller / Lender Database (805). The TAP Module (431) then calculates the Price Value of a Basis Point (PVBP) of the financial product sought by the buyer / borrower based upon the parameters of the financial product that have been stipulated by the buyer / borrower during the application process and captured by the

Application Module (410). The upfront fees for a specific lender are then divided by the PVBP value to convert the upfront fees, charges and taxes into a basis point value. The TAP Module (341) then

Substitute Sheet

(Rule 26) RO/AU adjusts the raw offer price or rate held in the Market Stacker Module (710) by the basis point value to derive a Trade Adjusted Price or executable price (refer Figure 20).

For example, a borrower wishes to establish a new loan to borrow $10,000 for 5 years and the calculated PVBP is determined to be $10. A liquidity provider is willing to lend money to the borrower at a rate of 9.50% plus their fees, charges and establishment costs. The BBTAP Module (431) then takes the upfront fees and associated taxes for a liquidity provider (for example $1 10 being $100 establishment fee and $10 GST or VAT) and then divides this by the PVBP of $10 to obtain a value to 11 or 0.11 %. The TAP Module then adjusts the executable offer price of 9.50% by adding 0.1 1 % to achieve an all-inclusive offer rate of 9.61 % which is displayed in the Buyer / Borrower Digital Market Interface (450). This process is applied to all liquidity providers and their offers are consequently reordered in the Buyer / Borrower Digital Market Interface (450) to ensure that the best available price or rate is sitting at the top of the offer side of the market (refer Figure 15). In this way, all offers for financial products from liquidity providers can be standardised to ensure that the buyer / borrower is selecting the best available price offer inclusive of all fees, charges and taxes.

If the buyer / borrower elects to execute a transaction with a liquidity provider at the best available offer price (herein referred to as 'the market price') then a transaction is generated whereby the buyer / borrower will pay 9.50% interest, $100 establishment fees in advance and taxes of $10 upfront. Alternatively, at the liquidity providers discretion these upfront fees and taxes may be embedded into the interest rate for the life of the financial product and instead of the buyer / borrower may pay 9.61 % for the duration of the financial product.

The BBCAP Module (432) is focused on calculating a contingency adjusted price for a financial product. This is particularly relevant as it relates to transactions with a contract period during which depending on the behaviour of the buyer / borrower a late payment or default fee may be incurred. For example, two liquidity providers may have identical raw offer prices for a financial product and identical upfront costs and associated taxes however they may have significantly different fee structures as they relate to buyers / borrowers that are late in making periodical payments. The BBCAP Module (432) seeks to calculate the hypothetical or contingency costs associated with a financial product for the purposes of splitting the two offers from the liquidity providers in the market in addition to providing buyers / borrowers with another means of deciding which offer is best for them. The BBCAP Module (432) extracts all fees that relate to payment behaviour of a buyer / borrower with respect to the terms of a contract such as (but not limited to) late payment fees and default rates of interest from the Seller / Lender Database (805). The BBCAP Module (432) then extracts a probability value of the buyer / borrower making a late payment which has been determined by the Credit Assessment Engine (300) being held in the Buyer / Borrower Database (801). This probability is then used to determine how many months in one year the borrower will make a late payment. The BBCAP Module (432) then calculates the Price Value of a Basis Point (PVBP) of the financial product sought by the buyer / borrower based upon the parameters of the financial product that have been stipulated by the buyer / borrower during the application process and captured by the Application Module (410). The fees contingent on buyer / borrower behaviour for a specific lender are then divided by the PVBP value to convert the contingency fees, charges and taxes into a basis point value. The BBCAP

Substitute Sheet

(Rule 26) RO/AU Module (342) then adjusts the raw offer price or rate held in the Market Stacker Module (710) by the basis point value to derive a Contingency Adjusted Price or executable price (refer Figure 21).

For example, a borrower wishes to borrow $10,000 for 5 years and the calculated PVBP is determined to be $10. Both Liquidity Provider A and Liquidity Provider B are willing to lend money at a rate of 9.50% with no upfront fees and subsequent tax implications. However Liquidity Provider A will charge $100 each time the buyer / borrower misses the due date for a payment while Liquidity Provider B will only charge $50 per late payment. The GST or VAT associated with these fees is determined to be 10%. The BBCAP Module (432) extracts the probability of late payment value for the specific buyer / borrower (calculated by the Credit Assessment Engine (300)) from the Buyer / Borrower Database (801) which is 25% or 3 months per year. The BBCAP Module (432) then determines that this specific buyer / borrower could potentially pay $300 (3 x $100) in late payment fees to Liquidity Provider A or $150 (3 x $50) to Liquidity Provider B per year. The BBCAP Module (432) then takes these two contingency fee amounts and divides them by the PVBP value of $10 to obtain a value of 30 (0.30%) and 15 (0.15%) respectively. The BBCAP Module (432) then adds these values to the raw offer rate of 9.50% and derives a Contingency Adjusted Price of 9.80% for Liquidity Provider A and 9.65% for Liquidity Provider B. In this situation, Liquidity Provider B would have its offer placed ahead of Liquidity Provider A despite them having identical Trade Adjusted Prices. This process is applied to all liquidity providers in the market and consequently their offers are reordered in the Buyer / Borrower Digital Market Interface (450) (refer Figure 16).

The BBTAPCAP Module (430) therefore provides for raw offers to be adjusted both with reference to upfront and contingency fees and enable offers to be reordered in the Buyer / Borrower Digital Market Interface (450) to account for all additional fees, charges and taxes and ensure that the best all- inclusive offer is available for the buyer / borrower to execute immediately if they wish. The offers displayed in the Buyer / Borrower Digital Market Interface (450) are ordered in the following hierarchy: (1) Best Trade Adjusted Price then (2) where two offers have an identical Trade Adjusted Price they are ordered by best Contingency Adjusted Price then (3) where two offers have an identical Trade Adjusted Price and an identical Contingency Adjusted Price they are ordered by time in which these offers have been received with the first received offer placed at the top of the queue.

Also contained in the Buyer / Borrower Portal (130) is an Order (Credit Pending) Module (440). This module houses any orders for financial products that have been created by the buyer / borrower and the credit assessment process is either yet to commence or in progress. The orders remain in this module in a 'Pending' status until such time as the credit assessment process has been completed by the Credit Assessment Module (120). In the event that the credit assessment determines that the buyer / borrower is not creditworthy the order is automatically cancelled and deleted from the Order (Credit Pending) Module (440) with a record of this action being created in the Buyer / Borrower Database (801) against the profile of the buyer / borrower.

In the event that the event that the credit assessment is successful the destination credit market (determined by the Credit Assessment Engine (300)) is tagged to the order. The status of the order is then updated from 'Pending' to 'Live' and is made available in the Buyer / Borrower Digital Market Interface (450) section of the Buyer / Borrower Portal (130) for the buyer / borrower to either amend or submit into the market.

Substitute Sheet

(Rule 26) RO/AU In the case where the buyer / borrower elects to amend the order (for example, if the buyer / borrower elects to use the Product Simulator (401) to resize the order to obtain a better credit score and thereby direct the order into a different credit market) the status of the order reverts to 'Pending' until such time as the Credit Assessment Engine (300) determines the new destination credit market. Upon a new destination market being achieved, the old destination credit market tag is removed from the order and replaced with a new destination credit market tag. At this point the order status changes from 'Pending' to 'Live' again for the buyer / borrower to execute if they wish.

In the event of execution, the order is released from the Order (Pending Credit) Module (440) and sent to the Transaction Router (760) for onward direction to the relevant credit market contained in the Market Stacker Module (710) to either immediately be matched if it is a 'market' transaction or to be placed in the bid queue if the order is a bid (refer Figure 22)

Also contained within the Buyer / Borrower Portal (130) is the Buyer / Borrower Digital Market Interface (450) which is the face of the digital market for the buyer / borrower. This is where buyers / borrowers can view the credit markets that they are interested in. Where a buyer / borrower has not got either a 'Pending' or 'Live' order housed in the Order (Credit Pending) Module (440) the

BBTAPCAP Module (430) is switched off and consequently the prices shown in the Buyer / Borrower Digital Market Interface (450) are unadjusted and a direct reflection of the prices or rates that are housed in the Market Stacker Module (710).

Where the buyer / borrower does have either a 'Pending' or 'Live' order housed in the Order (Credit Pending) Module (440) the BBTAPCAP Module (430) is switched on and the prices shown in the Buyer / Borrower Digital Market Interface (450) for the markets that the 'Pending' or 'Live' order potentially relates to are switched on. For example, if the order is 'Pending' and relates to an unsecured personal loan then all credit markets relating to unsecured personal loans in the Buyer / Borrower Digital Market Interface (450) displays Trade Adjusted Prices but not the Contingency Adjusted Price because the probability of late payment has not been determined yet (credit assessment is still pending) and as such the Contingency Adjusted Price cannot be calculated.

In the event that the order transitions from 'Pending' to 'Live' then the prices displayed in the Buyer / Borrower Digital Market Interface (450) displays Trade Adjusted Prices and Contingency Adjusted Prices. This is because the credit assessment process is complete and consequently the Credit Assessment Engine (300) now has a probability of late payment determined enabling Contingency Adjusted Prices to be calculated.

The Buyer / Borrower Digital Market Interface (450) also may provide the buyer / borrower the ability to select filters to remove offers from their market based upon preference (refer Figure 10). For example, a buyer / borrower may have had a bad previous experience with ABC Bank Ltd and consequently does not wish to enter into a transaction with this organisation or the buyer / borrower only wishes to transact with liquidity providers with a bricks and mortar presence within 30 kilometres of their residential address. The buyer / borrower can then use the filters to remove these liquidity providers from their market depth and avoid transacting with them. This means that even if ABC Bank Ltd is offering the best Trade Adjusted Price any order submitted by the buyer / borrower are automatically matched to the next best Trade Adjusted Price in the market stacker.

Substitute Sheet

(Rule 26) RO/AU The Buyer / Borrower Digital Market Interface (450) can also customise the market depth to show prices displayed as interest rates, weekly, monthly or total amount payable for the financial product based upon the parameters of the financial product contained in the Order (Pending Credit) Module (440) (refer Figure 17a and 17b).

The Buyer / Borrower Digital Market Interface (450) is also where the buyer / borrower can submit their order into the relevant credit market once (a) the credit assessment is complete and (b) the buyer / borrower has finished using the Product Simulator (401) to confirm that the structure of the financial product is optimised to deliver the best credit score thereby ensuring that the order is directed into the most advantageous credit market to achieve the best possible price.

Any orders that are held in the Order (Credit Pending) Module (440) are displayed in the Buyer /

Borrower Digital Market Interface (450) as a hyperlink with the respective status of 'Pending' or Live' shown to the buyer / borrower. Once the status of the order is 'Live' the buyer / borrower is able to click on the hyperlink and an order pad appears. The order pad (refer Figure 11) contains details of the proposed transaction (for example, the amount, term, repayment frequency). These details may locked and unable to be amended at this stage for risk management purposes. Beneath the details of the proposed there are three radio buttons titled 'At Market', 'Work a Bid' and 'User Specified'.

If the buyer / borrower clicks the 'At Market' radio button the 'Submit' button at the bottom of the order pad is enabled (refer Figure 12). The buyer / borrower is then able to click the 'Submit' button at which time a final message appears stating 'Proceed?' and two radio buttons titled 'Yes' and 'No' with the 'No' radio button set as the default. The buyer / borrower can click the Yes' radio button and then click 'Confirm'.

Upon clicking 'Confirm' the system identifies the offer in the relevant market for which the order relates (for example, unsecured personal loan Credit Market 5) that is at the top of the offer stack displayed in the Buyer / Borrower Digital Market Interface (450) and records the unique Offer Identification Number (which may be comprised of the Participant ID or PID and an order number) relating to that offer. The system then ensures that the buyer / borrowers Bid Identification Number (generated by Order (Credit Pending) Module (440)) is matched to the recorded Offer Identification Number. The order is sent to the transaction router to be directed to the correct market for matching with the correct Offer Identification Number.

Where the buyer / borrower wishes to decline executing at market and would prefer to obtain the financial product at a rate below where the prevailing best offer is placed the buyer / borrower can click the 'Bid' radio button. When this radio button is selected additional fields become available in the order pad. These fields may include a 'Bid Price/Rate' (which is the price or rate at which the buyer / borrower wishes to transact), a 'Limit Price/Rate' (which is the worst case price or rate at which the buyer / borrower is willing to transact) and the 'Bid Period' (which is how long the bid is live for). For example, the best available Trade Adjusted Price for a buyer / borrower may be 9.61 % however the buyer / borrower doesn't need to obtain the financial product immediately. The buyer / borrower may elect to submit a bid and therefore clicks the 'Bid' radio button. The buyer / borrower populates the 'Bid Price/Rate' as 9.01 %, the 'Limit Price/Rate' as 9.77% and the 'Bid Period' as 5 Business Days.

Substitute Sheet

(Rule 26) RO/AU There are three potential outcomes for the buyer / borrower being (1) the market moves lower and within 5 days a Trade Adjusted Price of 9.01 % is achieved at which point the Offer Identification Number associated with the 9.01 % offer is recorded and the bid is matched against this offer (2) the market moves higher and eventually the best available Trade Adjusted Price is 9.77% at which time the Offer Identification Number associated with the 9.77% offer is recorded and the bid is matched against this offer or (3) the market doesn't move to either the 9.01 % or 9.77% at which time an alert is sent to the buyer / borrower advising them that the bid instructions have expired and the buyer / borrower needs to action their order. At this point, the buyer / borrower may elect to submit a new bid or alternatively transact at the prevailing Trade Adjusted Price. During the period that the bid is live, the Buyer / Borrower may manually adjust the bid parameters in response to market movements.

As part of the bidding capability of the system and to assist buyers / borrowers to make informed decisions concerning where to set their bid parameters, a bid positioning assistant is available within the order pad. The bid positioning assistant assesses the current market price for a financial product relative to the 'Bid Price/Rate' and 'Limit Price/Rate'. The bid positioning assistant extracts statistical data for the specific credit market being accessed by the buyer / borrower from the Market Statistics Database (810) and compliments these statistics with relevant resistance and support levels that may exist within the parameters of the order and subsequently calculates the probability of the Bid Price/Rate' and Limit Price/Rate' being transacted within the bid period. For example, where the buyer / borrower has populated the order pad with the 'Bid Price/Rate' as 9.01 %, the 'Limit Price/Rate' as 9.77% and the Bid Period' as 5 Business Days the bid positioning assistant calculates the probability of (a) the bid being successfully filled at 9.01 % within 5 business days (for example 20%) and (b) the bid being filled at the limit price of 9.77% (for example 80%) within 5 business days. The buyer / borrower can adjust the Bid Price/Rate and the Limit Price/Rate values to achieve the desired probability of success that the buyer / borrower seeks (refer Figure 13).

An additional function available to buyers / borrowers in the order pad housed by the Buyer / Borrower Digital Market Interface (450) is an automated bid tracker. When the buyer / borrower elects to submit a bid they can complete the bid parameters and then click a radio button titled 'Bid Tracker'. The Bid Tracker automatically adjusts the bid level periodically to eventually meet the market price thereby removing the need for the buyer / borrower to manually adjust the bid.

For example, if a buyer / borrower elects to submit a bid with 'Bid Price/Rate' as 9.01 %, the 'Limit Price/Rate' as 9.77% and the 'Bid Period' as 5 Business Days and enables the 'Bid Tracker'. 24hrs after the bid is submitted (referred to as B+1) with the Bid Tracker enabled (assuming that the best available Trade Adjusted Price is still 9.61 %) the Bid Tracker automatically increases the probability of the 'Bid Price/Rate' being filled from 20% for 9.01 % to 40% for 9.22% and may increases the probability of the 'Limit Price/Rate' being filled from 80% for 9.77% to 85% for 9.73% (refer Figure 14)

On B+2 the Bid Tracker again assesses the prevailing best available Trade Adjusted Price and adjusts the 'Bid Price/Rate' from 40% fill probability to 60% fill probability and may reduce the 'Limit Price/Rate' to increase the probability of being filled from 85% to 90%. This process continues until such time as either the adjusted 'Bid Price/Rate' or the 'Limit Price/Rate' is filled. Ultimately on B+5 the automatically adjusted 'Bid Price/Rate' and the 'Limit Price/Rate' converge and a transaction is executed at the best available Trade Adjusted Price.

Substitute Sheet

(Rule 26) RO/AU Once a bid is filled the system identifies the offer in the relevant market for which the order relates (for example, unsecured personal loan Credit Market 5) that is at the top of the offer stack displayed in the Buyer / Borrower Digital Market Interface (450) and records the unique Identification Number (which may be comprised of the Participant ID or PID and an order number) relating to that offer. The system then ensures that the buyer / borrowers Bid Identification Number (generated by Order (Credit

Pending) Module (440)) is matched to the recorded Offer Identification Number. The order is sent to the transaction router to be directed to the correct market for matching with the correct Offer Identification Number.

In the situation where the buyer / borrower doesn't wish to execute a transaction at market or work a bid the user can click the 'User Specified' radio button in the order pad to select an offer that is not necessarily the best Trade Adjusted Price. This may occur in the situation where the hierarchy methodology used to order the offers displayed in the Buyer / Borrower Digital Market Interface (450) places an offer at the top of the queue based upon the best Trade Adjusted Price however the Contingency Adjusted Price for the this offer may be substantially higher than the next best offer. For example, Liquidity Provider A may have an offer in the market with a Trade Adjusted Price of 8.50% and a Contingency Adjusted Price of 10.50% whilst Liquidity Provider B may have a Trade Adjusted Price of 8.52% and a Contingency Adjusted Price of 9.44%. Based upon the hierarchical ordering of the offers of (1) best Trade Adjusted Price then (2) best Contingency Adjusted Price and (3) time received Liquidity Provider A will have its offer at the top of the queue. However for the buyer / borrower they may wish to pay slightly more for the Trade Adjusted Price because they perceive that potential saving of using Liquidity Provider A is more than offset by the potential costs should the buyer / borrower not meet their periodical payment obligations.

When the buyer / borrower clicks the 'User Specified' radio button in the order pad the order pad automatically minimises and the buyer / borrower can click on the offer in the market depth displayed in their Buyer / Borrower Digital Market Interface (450). When the buyer / borrower clicks on this offer the order pad automatically maximises and the Offer Identification Number may be displayed in the order pad along with pre-populated fields containing the Trade Adjusted Price, Contingency Adjusted Price and other trade related information such as (but not limited to) periodical payment amounts. The user can then click 'Submit' at which time a final message appears stating 'Proceed?' and two radio buttons titled 'Yes' and 'No' with the 'No' radio button set as the default. The buyer / borrower can click the 'Yes' radio button and then click 'Confirm'.

Upon clicking 'Confirm' the system identifies the offer in the relevant market for which the order relates (for example, unsecured personal loan Credit Market 5) that was selected by the buyer / borrower in the Buyer / Borrower Digital Market Interface (450) and records the unique Offer Identification Number (which may be comprised of the Participant ID or PID and an order number) relating to that offer. The system then ensures that the buyer / borrowers Bid Identification Number (generated by Order (Credit Pending) Module (440)) is matched to the recorded Offer Identification Number. The order is sent to the transaction router to be directed to the correct market for matching with the correct Offer Identification Number.

Seller / Lender Portal (130)

Substitute Sheet

(Rule 26) RO/AU The present invention may also incorporate a Seller / Lender Portal (130). An important (however not exclusive) purpose of this portal is to provide a 'read-only' enterprise view of the distribution of financial products by various business units within a single corporate entity. The Seller / Lender Portal (130) has a dashboard which aggregates information and analytics from two modules contained within this portal being (1) the Administrator Portal (500) and (2) the Dealer Portal (600).

A lender can initiate registration with Dfinanz via the Registration Module (210) in the same way as the buyer / borrower does however their New User Form (21 1) may contain additional fields unique to lenders where they may identify authorised administrators and dealers and have these employees set up with their own Administrator Portal (500) and Dealer Portal (600).

Upon submission of their application, Dfinanz may contact the lender to obtain the necessary legal, risk and regulatory information required to create their unique profile in the Seller / Lender Database (805) contained in the Client Data Module (800) housed in the Data Storage and Retrieval Module (170). As part of this process Dfinanz may also create Administrator Portals (500) and Dealer Portals (600) as per the instructions of the seller / lender. Once this process is complete a Seller / Lender Portal (140) is created for the lending entity within which two different styles of portals being the Administrator Portal (500) and Dealer Portal (600) may be housed.

Administrator Portal (500)

This present invention may also incorporate an Administrator Portal (500). An important (however not exclusive) purpose of this portal is to provide authorised administrators acting on behalf of a sellers / lenders with the ability to manage the credit, market exposures, fees and charges of the seller / lender by establishing and managing appropriate limits within which the authorised dealers entering into financial product agreements with buyers / borrowers must operate.

An administrator can log into their portal via the Login Module (501) housed in the Dfinanz Website (110). Upon successfully logging in, the administrator is directed to the Administrator Dashboard (510). The Administrator Dashboard (510) may display a range of markets that the seller / lender are actively operating within and this display can be customised to the preferences of the administrator. Within the Administrator Dashboard (500) there may also be aggregated transaction information and activity monitors to oversee the transactions that the authorised dealers are either executing or working offers for. Within the Administrator Dashboard (510) may also be an alerts section which captures any situation where an authorised dealer is breaching predetermined trading limits.

The Administrator Portal (500) may also contain a Risk Management Module (520) within which the administrator can establish and amend limits within which authorised dealers may transact in financial products and a series of filters that may be enabled or disabled to include or exclude certain bids from their desired markets. Furthermore the administrator can stipulate minimum values at which dealers can sell / lend financial products or resources at to mitigate the risk of transacting at a loss.

Additionally, administrators may create, amend and delete upfront fees and charges associated with the execution of new financial products (such as establishment fees) in addition to fees and charges that would be applied to buyers / borrowers that do not meet their periodical payment obligations on time. In addition to this, fees and charges associated with early termination of a product may also be captured.

Substitute Sheet

(Rule 26) RO/AU Any information added or amended and then subsequently saved in the Risk Management Module (520) is then sent to the Seller / Lender Database (805) and the seller / lender profile in this database is updated to reflect these new limits or trade parameters.

The Administrator Portal (500) may also contain an Administrator Analytics Module (530) within which an administrator can obtain a detailed analysis of the performance of the authorised dealers such as their profitability, transaction volumes and trading behaviour. This information is also captured by the system with the information being sent to the Seller / Lender Database (805) and market statistical data being sent to the Market Statistics Database (810).

The Administrator Portal (500) may also contain an Administrator Communications Module (540). This module may display messages and alerts that are relevant to the administrator such as potential limit breaches, updates of when credit exposures are approaching predetermined limits and other risk management and control information.

The Administrator Portal (500) may also contain an Administrator Digital Market Interface (550). As opposed to the Buyer / Borrower Digital Market Interface (450), the Administrator Digital Market Interface (550) may not be subject to TAPCAP adjustments and truly reflect the raw market prices. This interface may enable administrators to better understand the trading behaviour of their competitors and an unadjusted insight into the trading behaviour of buyers / borrowers.

Dealer Portal (600)

The present invention may also incorporate a Dealer portal (600). The primary (however) not exclusive purpose of this portal is to enable authorised dealers acting on behalf of a seller / lender to be able to offer financial products into a digital exchange traded market and execute transactions.

A dealer can log into their portal via the Login Module (601 ) housed in the Dfinanz Website (1 10). Upon successfully logging in, the dealer is directed to the Dealer Dashboard (610). The Dealer Dashboard (610) may display a range of markets that the dealer is actively operating within and this display can be customised to the preferences of the dealer. The Dealer Dashboard (610) may also display summary analytics of the dealer's performance over various reporting periods, dealer performance against financial and risk management measurements and a profit and loss position.

The Dealer Portal (600) may also contain a Transaction Module (620) through which dealers can create, amend and cancel offers in financial products that are being (or have been) sent into the digital marketplace. A dealer may create a new offer by clicking 'New Trade' which opens an order pad which the dealer can populate with offer data such as Credit Market, Notional Amount and limit rate (if applicable). Within this order pad, the dealer may have the option of selecting from three radio buttons titled 'At Market', 'Work an Offer' and 'User Specified'.

If the dealer clicks the At Market' radio button the 'Submit' button at the bottom of the order pad is enabled. Furthermore, the dealer has access to a field titled 'Limit Price/Rate' which the dealer can populate with a value so as to be able to execute a transaction to be matched against all available bids down to the bid which is immediately below the limit value that the dealer has specified. The dealer is then able to click the 'Submit' button at which time a final message appears stating

'Proceed?' and two radio buttons titled 'Yes' and 'No' with the 'No' set as the default. The dealer can then click 'Yes' and click confirm.

26

Substitute Sheet

(Rule 26) RO/AU Where a dealer decides not to transact at the prevailing market price but rather state a target price at which they are willing to lend at and this is above the prevailing market price the dealer clicks the 'Work an Offer' radio button. Once this radio button is selected additional fields become available in the order pad. These fields may include an Offer Price/Rate' (which is the price or rate at which the dealer would be willing to transact at), a 'Limit Price/Rate' (which is the worst case price or rate at which the dealer is willing to transact) and an 'Offer Period' (which is how long the offer will be live for). For example, the Trade Adjusted Price viewed by a dealer may be 9.45% (this Trade Adjusted Price may be broken down from a buyer / borrower bid price of 9.61 % less the fees, charges and taxes that the dealer's organisation is seeking to apply to the transaction expressed as a percentage being 0.16%) however the dealer is unwilling to transact at 9.45%. The dealer can therefore elect to submit an offer and therefore click the 'Offer' radio button. The dealer populates the 'Offer Price/Rate' field with 9.63% and a 'Limit Price/Rate' as 9.39% and the Offer Period' as 5 business days.

As with the buyer / borrower scenario, there are three potential outcomes for the dealer being (1) the market moves higher within the 5 business day period and the desired rate of 9.63% is achieved at which point the Bid Identification Number associated with the 9.63% bid is recorded and the offer is matched against this bid (2) the market moves lower and eventually the best available Trade Adjusted Price is at 9.39% at which time the Bid Identification Number associated with the 9.39% bid is recorded and the offer is matched against this bid or (3) the market doesn't reach either 9.63% or 9.39% during the 5 day period at which time an alert is sent to the dealer advising them their offer instructions have expired and the dealer must action their order. At this point the dealer may elect to submit a new offer or alternatively transact at the prevailing Trade Adjusted Price. During the period that the offer is live the dealer may manually adjust the offer parameters in response to market movements.

As part of the offer capability of the system and to assist dealers to make informed decisions concerning where to establish their offer parameters an offer positioning assistant is available within the order pad. The offer positioning assistant assesses the current market price for a financial product relative to the Offer Price/Rate' and 'Limit Price/Rate'. The offer positioning assistant extracts statistical data for the specific credit market be accessed by the dealer from the Market Statistics Database (801) which is complimented by other market data such as identifiable resistance and support price levels within the market to calculate a probability of the Offer Price/Rate' and 'Limit Price/Rate' being transacted within the offer period. For example, where a dealer has populated the order pad with an Offer Price/Rate' of 9.63%, the 'Limit Price/Rate' at 9.39% and the offer period as 5 business days the offer positioning assistant will calculate the probability of (a) the offer being successfully filled at 9.63% within 5 business days (for example 20%) and (b) the offer being filled at the limit price of 9.39% within 5 business days (for example 80%). The dealer can adjust their offer parameters to achieve the desired probability of success that the dealer seeks.

An additional function available to dealers in the order pad housed by the Transaction Module (620) is an automated offer tracker. When a dealer elects to submit an offer they can complete the offer parameters and then click a radio button titled Offer Tracker'. The Offer Tracker automatically adjusts the offer level periodically to eventually meet the market price thereby removing the need for the dealer to manually adjust the offer.

Substitute Sheet

(Rule 26) RO/AU For example, a dealer elects to submit an offer with an 'Offer Price/Rate' of 9.63%, the 'Limit Price/Rate' as 9.39% and the Offer Period' as 5 Business Days and enables the 'Offer Tracker' 24 hours after the offer is submitted (referred to as 0+1) the Offer Tracker automatically increases the probability of the offer being filled from 20% for 9.63% to 40% for 9.55% and may increase the probability of the 'Limit Price/Rate' being filled from 80dio % for 9.39% to 85% for 9.41 %. This process is repeated every 24 hours until such time as either the Offer Price/Rate' or the 'Limit Price/Rate' is filled.

Once an offer is filled the system identifies the bid in the relevant market for which the order relates (for example, unsecured personal loan Credit Market 5) that is at the top of the bid stack displayed in the dealer's Digital Market Interface (650) and records the unique Bid Identification Number (which may be comprised of the Participant ID or PID and an order number) relating to that bid. The system then ensures that the dealer's Offer Identification Number (generated upon offer submission via the Transaction Module (620)) is matched against the recorded Bid Identification Number. The offer is then sent to the Transaction Router (760) to be directed to the correct market for matching with the correct Bid Identification Number.

In a situation where the dealer doesn't wish to execute a transaction at market or work an offer the dealer can click the User Specified' radio button in the order pad to select a bid that is not necessarily the best Trade Adjusted Price. This may occur due to the dealer having accessed the story attached to a bid which has been completed by the buyer / borrower when they completed the optional 'My Story' section in their application for a financial product via the Application Module (410) (refer Figure 25).

When a dealer clicks the 'User Specified' radio button in the order pad the order pad automatically minimises and the dealer can click the bid in the displayed in the market depth displayed in their Digital Market Interface (650). When the dealer clicks on this bid the order pad automatically maximises and the Bid Identification Number may be displayed in the order pad along with prepopulated fields containing the Trade Adjusted Price, Contingency Adjusted Price and other trade related information such as (but not limited to) periodical payment amounts. The dealer can then click 'Submit' at which time a final message appears stating 'Proceed' and two radio buttons titled 'Yes' and 'No' with the 'No' radio button set as the default. The dealer can click the 'Yes' radio button and then click 'Confirm'.

Upon clicking 'Confirm' the system identifies the offer in the relevant market for which the order relates (for example unsecured loan Credit Market 5) selected by the dealer in the Transaction Module (620) and records the unique Bid Identification Number (which may be comprised of the Participant ID or PID and an order number) relating to that bid. The system then ensures that the dealer's Offer Identification Number (generated by the Transaction Module (620)) is matched to the recorded Bid Identification Number. The offer is then sent to the Transaction Router (760) to be directed to the correct market for matching with the correct Bid Identification Number.

The Dealer Portal (600) may also contain a Dealer Analytics Module (530) within which a dealer can obtain a detailed analysis of their performance such as their profitability, transaction volumes and trading behaviour. This information is also captured by the system with the information being sent to

Substitute Sheet

(Rule 26) RO/AU the Seller / Lender Database (805) and market statistical data being sent to the Market Statistics Database (810).

The Dealer Portal (600) may also contain a Dealer Communications Module (540). This module may display messages and alerts that are relevant to the dealer such as potential limit breaches, updates of when credit exposures are approaching predetermined limits and other risk management and control information.

The Dealer Portal (600) may also contain a Dealer Digital Market Interface (650). As with the Buyer / Borrower Digital Market Interface (450), the Dealer Digital Market Interface (650) may be subject to TAPCAP adjustments to ensure that transaction decisions are made with reference to any associated fees, charges and taxes. The TAPCAP adjustments are calculated in an almost identical way to the process applied for buyers / borrowers except for at least one key difference. Rather than adding relevant fees, charges and taxes to the offers in the market by using information extracted from the Seller / Lender Database (805) and using the Price Value of a Basis Point (PVBP) the TAPCAP Adjustments for dealers extracts the relevant fees, charges and taxes from the Seller / Lender Database (805) and deducts them from the bids in the marketplace. For example, a dealer may view a bid within a marketplace with a TAP of 9.41 % which will represent a rate at which a buyer / borrower is willing to borrow at 9.55% and the fees, charges and taxes associated with the bid may be equal to 0.14%. The dealer can therefore transact at the rate of 9.41 % knowing that all relevant adjustments have been made to the price.

Also contained in the Dealer Portal (600) is the SLTAPCAP Module (660). This module adjusts the raw market prices that are extracted from the Market Stacker Module (710) and are displayed to the dealer in the Dealer Digital Market Interface (650). As with the BBTAPCAP Module (430) this is done by embedding actual and contingency costs that a seller / lender is seeking to charge for a financial product using the same PVBP methodology. The only difference in the SLTAPCAP Module (660) and the BBTAPCAP Module (430) methodology is that while BBTAPCAP Module (430) embeds the fees, charges and taxes by adding them to the raw price, the SLTAPCAP Module (660) deducts them so that the price shown to the dealer is exclusive of all associated costs for the transaction.

Digital Market Module (700)

The Digital Market Module (700) is the component of the system that captures all bids from buyers / borrowers and offers from sellers / lenders, directing these orders into the relevant markets, match the orders generating Transaction Identification Numbers (TIN) and maintaining an orderly marketplace. Within the Digital Market Module (700) are five sub-modules which are the Market Stacker Module (710), Trade Execution Module (720), Market Control Module (730), Order Management Module (740) and the Transaction Router (760).

The Market Stacker Module (710) is the section of the Digital Market Module (700) that houses individual credit markets. The markets housed in the Market Stacker Module (710) may first be categorised by financial product. For example (but not limited to) Unsecured Personal Loans, Secured Personal Loans, Home Loans and Credit Cards. Beneath these categories are a number of individual market stackers which are classified by credit rating. For example, under Unsecured Personal Loans

Substitute Sheet

(Rule 26) RO/AU there may be ten individual market stackers that capture and house bids and offers for loans where the buyer / borrower has been assessed as a specific credit score (such as 876) and this credit score fits between a predetermined upper (899) and lower (800) credit score thresholds.

The Trade Execution Module (720) works in conjunction with the Market Stacker Model (710) by receiving an incoming bid or offer from the Transaction Router (760), matching the bid or offer against the predetermined matching order and reducing the amount of, or removing the order from, the relevant market accordingly.

For example, a buyer / borrower have completed their credit assessment and have been classified to Credit Market 5 for an unsecured personal loan of $10,000. The buyer / borrower elect to execute an 'At Market' order to obtain the best available price at that time. The buyer / borrower submit their transaction via their order pad at which time a Bid Identification Number is generated (for example JSMITH001).

The system identifies at that instant the best available price is an offer from ABC Bank for

$10,000,000 with a Trade Adjusted Price (TAP) of 8.71 % of which 8.61 % is the interest rate and 0.10% is comprised of an establishment fee of $90 and taxes of $9. The Offer Identification Number for this offer is ABC007 and it is currently held in Credit Market 5 for Unsecured Personal Loans housed in the Market Stacker Module (710). The system tags ABC007 to JSMITH001 and directs the bid to the Transaction Router (760). The Transaction Router (760) identifies that the bid belongs to Credit Market 5 located under the Unsecured Personal Loan category and therefore directs the bid to the Trade Execution Module (720) attached to the Market Stacker Module (710). The Trade Execution Module (720) then reduces the amount of ABC007 held in Unsecured Personal Loan Credit Market 5 from $10,000,000 to $9,990,000 to reflect the transaction. The Trade Execution Module (720) then takes the BIN (JSMITH001) and the OIN (ABC007) and generates a Transaction Identification Number relating specifically to this transaction (for example, JSMITHABCUPL001). This TIN and the associated information relating to the transaction is then (a) sent to the Data Storage and Retrieval Module (170) for the trade information to be stored in the Buyer / Borrower Database (801), Seller / Lender Database (802) and the Market Statistics Database (810) and (b) the TIN is also sent to the Document Management System (160) for the purposes of automatically generating financial product documentation.

A confirmation of the transaction is also sent by the Trade Execution Module (720) directly to the buyer / borrower and the seller / lender for verification. The buyer / borrower can confirm the transaction details are correct and then confirm this verbally or via email (or other written form). A copy of the confirmation is then directed to the Buyer / Borrower Database (801) inclusive of voice recording if available.

This same process is applicable for where a seller / lender initiates a transaction and executes at market (thereby matching against buyer / borrower bids) or where a buyer / borrower or seller / lender executes a 'User Specified' transaction.

The Market Control Module (730) is responsible for identifying any disorderly or unusual behaviour housed within the individual markets housed within the Market Stacker Module (710). It performs this function by constantly running analysis on the traded market price and using statistical measures (the

Substitute Sheet

(Rule 26) RO/AU data for which is extracted from the Market Statistics Database (810)) to identify market manipulation or dislocation. In the event that the market trades outside of the predefined limits held in the Market Control Module (730) the Market Control Module has the ability to shut down the affected marketplace and identify the trade(s) that have affected the market and track these trades back to the offending party.

The Order Management Module (740) facilitates an orderly market by ensuring that there are no non- marketable parcels (or residual bids or offers) in the market. At the point of registering to use Dfinanz a seller / lender can choose to either have non-marketable parcels automatically removed from the market stacker or alternatively allow their non-marketable parcel to be matched against a larger bid by Dfinanz permitting the trade to proceed despite the offer having insufficient volume to complete the trade. When the seller / lender selects the methodology it would like to apply to their non-marketable parcels this decision is recorded in the Seller / Lender Database (805) and the Order Management Module (740) facilitates transactions based upon this predefined rule.

For example, ABC Bank has selected that any non-marketable parcels are to be removed from the market depth upon the point of falling below the maximum amount for a financial product for a specific market. In this case, Unsecured Personal Loans have a maximum amount of $50,000 that can be sourced by a buyer / borrower. ABC may have originally submitted an offer into Credit Market 5 for Unsecured Personal Loans of $10,000,000 and the last transaction reduced their offer from $65,000 to $45,000. The Order Management Module (740) identifies that ABC Bank has selected the option to have non-marketable parcels removed from the market stacker (as per the records held in the Seller / Lender Database (805)). The Order Management Module (740) therefore removes the residual offer amount of $45,000 from the market depth and notification of this is sent to the seller / lender administrator via the Administrator Communications Module (540) and to the responsible dealer via the Dealer Communications Module (640). In this way, if the next buyer / borrower wishes to borrow $50,000 at market the next best offer price may be filled in an orderly fashion.

Alternatively, XYZ Bank has selected that any non-marketable parcels are to remain in the market and that XYZ Bank will fully meet the bid amount. XYZ may have originally submitted an offer for Unsecured Personal Loans of $10,000,000 and the last transaction reduced their offer from $65,000 to $45,000. The Order Management Module (740) identifies that XYZ Bank has selected the option to have non-marketable parcels topped up and filled in the market (as per the records held in the Seller / Lender Database (805)). When a buyer / borrower executes an 'At Market' trade for $50,000 (greater than the available offer amount of $45,000) the Order Management Module (740) automatically increases XYZ's offer amount by $5,000 to $50,000 and matches the offer with the bid. XYZ Bank is then no longer in the marketplace.

The Transaction Router (760) is the component of the Digital Market Module (700) that directs incoming bids and offers to the correct markets housed in the Market Stacker Module (710). It does this by assessing the incoming Bid Identification Number or Offer Identification Number and identifies (a) the correct financial product that the order relates to and (b) the correct credit market that the order relates to. It then directs the bid or offer to the relevant market.

Document Management System (160)

Substitute Sheet

(Rule 26) RO/AU The Document Management System (160) is the component of the system that automatically constructs the financial product documentation that relates to an executed transaction. This system receives the Transaction Identification Number or TIN (for example, JSMITHABC001) and extracts information based upon the code contained within the TIN. For example, JSMITH denotes the buyer / borrower and the information relevant to the financial product document such as name, address, date of birth etc. is extracted from the Buyer / Borrower Database (801) by the Document Management System (160).

ABCUPL denotes the seller / lender and the specific financial product documentation that relates to the transaction. The Document Management System (160) extracts the relevant Unsecured Personal Loan documentation for ABC Bank from the Document Warehouse (830). 001 denotes the transaction just executed and contains the specific transaction information such as amount, term, rate, fees, charges and taxes etc.

The Document Management System (160) then inserts the transaction and buyer / borrower information into the financial product documentation and generates a unique document number and status (for example JSMITHABCUPL001002P) with 002 being the document number and P' being a 'Pending' status. A copy of this document number is then sent to the Data Storage and Retrieval Module (170) and recorded under the Buyer / Borrower Database (801) and the Document

Warehouse (830). The document is then sent to the Document Dispatch Centre (180) for communication to the buyer / borrower and the seller / lender via their respective portals.

The buyer / borrower can access this document via the Buyer / Borrower Portal (130) and execute the documentation either (a) manually or (b) digitally. If done manually the document may then be scanned by the buyer / borrower, uploaded into their portal and sent to Dfinanz via the

Communications Module (403). If done digitally the document is automatically sent to Dfinanz via the Communications Module (403). Upon receipt of the executed document, the document is saved in the Document Warehouse (830) and is made available to the seller / lender via their portal. At this point the status of the document number changes from pending or 'P' to executed or Έ' and the transaction is deemed to be complete.

Data Storage and Retrieval Module (170)

The Data Storage and Retrieval Module (170) is the component of the system that houses one or more of a number of databases that contain data related to participants in Dfinanz and their respective transactions. There are six specific databases to be housed optionally in the Data Storage and Retrieval Module being (1) Buyer / Borrower Database (801), (2) Seller / Lender Database (805), (3) Market Statistics Database (810), Credit Database (820), Document Warehouse (830) and Advertiser Database (840).

The Buyer / Borrower Database (801) contains all personal, credit and transactional data relating to a buyer / borrower. There are two sets of data contained in this database being (a) the data provided by the buyer / borrower at the point of registration and (b) data that is acquired via the credit assessment process and the activity of the user in the marketplace.

The Seller / Lender Database (805) contains all company, administrator, dealer, limits, fees and charges associated with financial products and transactional data relating to a seller / lender. There

Substitute Sheet

(Rule 26) RO/AU are two sets of data contained in this database being (a) the data provided by the seller / lender at the point of registration and (b) data that is acquired via the credit assessment process and the activity of the administrators and dealers in the marketplace.

The Market Statistics Database (810) contains all market data such as traded prices, participant behaviour, volatility values, volumes etc. that has been observed in the marketplace. This database provides source data for operational aspects of the system.

The Credit Database (820) contains any data relating to psychometric profile templates, credit market thresholds and any other data that is to enable Dfinanz to perform credit assessments and categorise participants and direct them to the correct areas of the system.

The Document Warehouse (830) contains all relevant templates for financial product documentation for seller / lenders and may also house executed documentation for future use.

The Advertiser Database (840) contains all profiles for non-market participants that with to advertise their services in the Buyer / Borrower Portal (130) under the Advertising Module (402).

Document Dispatch Centre (180)

The Document Dispatch Centre (180) is the component of the system that receives recently constructed financial product documentation from the Document Management System (160) and dispatches these documents to the buyer / borrower for execution via the Buyer / Borrower Portal (130) and copies of the executed documentation to the seller / lender via the Seller / Lender Portal (140).

Substitute Sheet

(Rule 26) RO/AU

Claims

Claims

1. A system for an exchange traded marketplace comprising: a buyer / borrower portal; a seller / lender portal; and optionally one or more of: a credit assessment module; an administrator portal; a dealer portal; a digital market module; a document management system; a data storage and retrieval module; and a document dispatch centre.

2. A system for an exchange traded marketplace comprising: a credit assessment module; and optionally one or more of: a digital market module; a document management system; a data storage and retrieval module; and a document dispatch centre.

3. A system for an exchange traded marketplace comprising: a buyer / borrower portal; a seller / lender portal; and optionally one or more of: an administrator portal; and a dealer portal.

4. A system according to any one of claims 1 to 3 further comprising a website.

5. A system according to any one of claims 1 to 4 wherein the website optionally comprises one or more of: a general information module; a registration module; a login module and an app download module.

6. A system according to claim 5 wherein the general information module optionally comprises one or more of a market information module and a broadcast module.

7. A system according to either claim 1 or claim 2 wherein the credit assessment module optionally comprises one or more of a credit assessment engine; a big data module; a psychometric profile model and an ancillary credit source module.

8. A system according to either claim 1 or claim 3 wherein the buyer / borrower portal optionally comprises one or more of a buyer / borrower dashboard; an application module; a buyer / borrower analytics module; a BBYAPCAP module; an Order (Credit Pending) Module; and a buyer / borrower digital market interface.

9. A system according to claim 8 wherein the buyer / borrower dashboard optionally comprises one or more of a product simulator; an advertising module and a communications module.

10. A system according to claim 8 wherein the BBTAPCAP module optionally comprises one or more of BBTAP module and a BBCAP module.

11. A system according to either claim 1 or claim 3 wherein the seller / lender portal optionally

comprises one or more of an administrator portal; a dealer portal and a SLTAPCAP portal.

12. A system according to claim 1 1 wherein the administrator portal optionally comprises one or more of a login module; an administrator dashboard; a risk management module; an administrator analytics module; an administrator communications module and an administrator digital market interface.

13. A system according to claim 1 1 wherein the dealer portal optionally comprises one or more of a login module; a dealer dashboard; a transaction module; a dealer analytics module, a dealer communications module and a dealer digital market interface.

34

Substitute Sheet

(Rule 26) RO/AU

14. A system according to claim 1 1 wherein the SLTPCAP module optionally comprises one or more of a SLTAP module and a SLCAP module.

15. A system according to either claim 1 or claim 2 wherein the digital market module optionally comprises one or more of a market stacker module; a trade execution module; a market control module; an order management module and a transaction router.

16. A system according to either claim 1 or claim 2 wherein the data storage and retrieval module optionally comprises one or more of a client data module; a market statistics database; a credit database; a document warehouse and an advertiser database.

17. A system according to claim 16 wherein the client data module optionally comprises one or more of a buyer / borrower database and a seller / lender database.

18. A method for operating an exchange traded marketplace comprising:

receiving an item of information from a prospective buyer / borrower;

receiving an item of information from a prospective seller / lender

and optionally performing a credit assessment in respect of the prospective buyer / borrower.

19. A method for operating an exchange traded marketplace comprising performing a credit

assessment in relation to a prospective buyer / borrower.

20. A computer implemented method for calculating a transaction adjusted price for an item in a marketplace comprising adding to the offer price an amount based at least on at least one additional transaction-related amount which optionally comprises or is optionally derived from one or more of brokerage, a value added tax, and / or a fee.

21. A method according to claim 18 wherein the marketplace is an exchange traded marketplace.

22. A system for calculating a transaction adjusted price for an item in a marketplace comprising: a computer-implemented database;

price management logic for storing an offer price and related data in the computer-implemented database; and

pricing logic associated with the transaction and configured to determine an adjusted price for the sale of an item on the marketplace;

wherein the transaction adjusted price comprises the offer price plus at least one additional transaction-related amount which optionally comprises or is optionally derived from one or more of brokerage, a value added tax and / or a fee.

23. A method according to claim 22 wherein the marketplace is an exchange traded marketplace.

24. A computer implemented method for calculating a contingency adjusted price for an item in a marketplace comprising adding to the offer price an amount based at least on at least one additional risk-related amount which optionally comprises or is optionally derived from one or more of a late payment fee, additional interest, and / or a break fee.

25. A method according to claim 24 wherein the marketplace is an exchange traded marketplace.

26. A system for calculating a contingency adjusted price for an item in a marketplace comprising:

Substitute Sheet

(Rule 26) RO/AU a computer-implemented database;

price management logic for storing an offer price and related data in the computer-implemented database; and

pricing logic associated with the transaction and configured to determine an adjusted price for the sale of an item on the marketplace;

wherein the contingency adjusted price comprises the offer price plus at least one additional risk- related amount which optionally comprises or is optionally derived from one or more of a late payment fee, additional interest, and / or a break fee.

27. A method according to claim 26 wherein the marketplace is an exchange traded marketplace.

28. A computer implemented method for operating an exchange traded marketplace comprising the steps of:

presenting to a seller information based on an item of non-price information from a potential purchaser; and

providing to the seller the option of selecting a potential purchaser to purchase the item based at least partially on that non-price information.

29. A system for an exchange traded marketplace comprising:

at least one computer-implemented database;

price management logic for storing an offer price and related data in the computer-implemented database;

non-price information logic for storing an item of non-price information in a computer-implemented database; and

display logic associated with the non-price information and configured to display to a user information based on an item of non-price information together with the means to select at least one option based on the non-price information;

wherein the at least one option comprises an offer of sale to potential purchaser based on at least one item of non-price information.

30. A computer implemented method for managing a partial fill in an exchange traded marketplace comprising:

receiving an order;

receiving an offer;

identifying a partial fill in respect of the order and the offer;

providing to the offeror at least one option in respect of filling the order wherein the at least one option comprises one or more of:

(a) increasing the order to accommodate the order; and

(b) removing the offer on reaching a predetermined threshold.

31. A system for managing a partial fill in an exchange traded marketplace comprising:

at least one computer-implemented database;

order logic for storing an order in a computer-implemented database;

36

Substitute Sheet

(Rule 26) RO/AU offer logic for storing an order in a computer-implemented database;

partial fill logic associated with the order logic and offer logic and configured to determine the occurrence of a partial fill in respect of the order; and

option logic associated with the partial fill logic to provide to the offeror at least one option in respect of filling the order;

wherein the at least one option comprises one or more of: increasing the order to accommodate the order; and removing the offer on reaching a predetermined threshold.

32. A computer implemented method for operating an exchange traded marketplace comprising receiving an order and adjusting the order based on a statistical probability.

33. A system for an exchange traded marketplace comprising:

at least one computer-implemented database;

order logic for storing an order in a computer-implemented database;

adjustment logic associated with the order logic and configured to adjust the order based on a statistical probability.

Substitute Sheet

(Rule 26) RO/AU