WO2018009973A1

WO2018009973A1 - System to facilitate profit sharing borrowing and lending

Info

Publication number: WO2018009973A1
Application number: PCT/AU2017/050718
Authority: WO
Inventors: Buddy John WAKIM
Original assignee: Ibuytrader Pty Ltd
Current assignee: Ibuytrader Pty Ltd
Priority date: 2016-07-12
Filing date: 2017-07-12
Publication date: 2018-01-18
Anticipated expiration: 2019-01-12
Also published as: AU2017295311A1

Abstract

Provided is a lending system and computer system implemented method of lending facilitating profit sharing. The system provides a tool for use by lenders and borrowers to 5 enable peer to peer type lending arrangements to be established, monitored, analysed and reconciled. The system is configured to automatically identify compatible borrowers and lenders, establish the borrower/lender relationships, administer agreements, monitor the loan, and facilitate financial reconciliation and profit sharing on conclusion of the loan and/or individual single asset sale or per transaction. In some embodiments loans can be made up 0 of thousands of single assets across multiple borrowers and lenders. Embodiments of the system can also be configured to perform automated performance assessment of borrowers and/or lenders and output risk management data and ratings. Lenders and borrowers can interact with the system via an internet portal to manage their portfolio.

Description

SYSTEM TO FACILITATE PROFIT SHARING BORROWING AND LENDING Technical Field

The technical filed of the present invention is computer systems configured to support administration, monitoring, execution and communication of financial transactions.

Background

In traditional borrowing and lending methods, an entity, such as a financial institution (for example, banks, superannuation funds, investment funds etc.), will lend funds to another entity with the condition that the funds are repaid within a specified term and with interest at a given rate applied. Typically periodic repayments over the term of the loan are required. In accordance with standard principles of compound interest, interest is calculated at a given rate on the outstanding value of the loan, and added to the loan amount at specified intervals, for example, daily, weekly, fortnightly, or monthly. Loans may be secured or unsecured. The lending entity is typically selective of the entities to lend to and decisions regarding lending are based on risk and profit assessment by the lender. Based on the assessed risk the lender may set the values of numerous parameters of a loan agreement, for example, loan amount, interest rate, repayment rate, repayment size, loan term etc. Typically a large lending entity, such as a bank, will have many thousands or millions of loan agreements and use computer systems to automate aspects of setup and administration of such agreements and monitoring of repayments. Such systems are configured to process high volumes of transactions and accommodate large numbers of loans all having the same basic loan agreement framework with variable parameters, such as: loan amount, loan term, interest rate, repayment rate, but the basic loan structure in such systems lacks flexibility and intelligence.

Apart from financial institutions, borrowers may seek to raise capital or borrow from investors or thorough private lending arrangements. Such agreements are typically negotiated on a case by case basis and can be highly flexible. For example, some agreements include exchange of equity, profit sharing, funds transfer/release contingent on specific milestones or outcomes instead of or in addition to traditional loan arrangements. Due to the high variability and flexibility such agreements typically require manual or largely manual setup and administration. The manual nature of such agreements may restrict the number of such agreements an investor can feasibly manage and influence the number of different entities an investor is prepared to work with. This can, in turn, present barriers or reduce options for borrowing entities and investors alike.

There is a need for computer based systems to facilitate setup, administration, monitoring, and maintenance of more flexible lending arrangements.

Summary of the Invention

According to an aspect of the present invention there is provided a lending system implemented using computer system processing and memory resources accessible by borrowers and lenders via a communication network from borrower and lender computer systems, the lending system comprising:

an access management module implemented using processing resources and including a network communication interface configured to enable data transfer between the lending system and the computer systems of borrowers and lenders via the communication network, and memory resources configured to implement one or more databases storing lender data records and borrower data records, the access management module being configured to enable setup of user accounts for borrowers and lenders and control data access input and display by the borrower and lender computer systems;

a lender profiling module configured to, for each lender, receive lender data, analyse lender data to determine risk tolerance profile and lending preference data for each lender; a borrower profiling module configured to, for each borrower, receive borrower data, analyse borrower data to determine risk profile and borrowing requirement data for each borrower;

a matching engine configured to match borrowers with lenders to enable facilitated peer to peer lending with profit sharing; and

a transaction monitoring and reconciliation module configured to formalise loan agreements between borrowers and lenders, monitor progress of loan agreements, and perform reconciliation at the completion of a loan transaction, the transaction monitoring module being configured to interface with a finance interface to effect transfer of funds.

In an embodiment the system further comprises a profit sharing engine configured to apply profit sharing rules to calculate return shares to borrowers and lenders during reconciliation of a loan transaction.

The borrower profiling module can be further configured to receive monitored transaction data from the transaction monitoring and reconciliation module on conclusion of a transaction wherein one or more lenders loan funds to a borrower, analyse the transaction data and adjust the borrower risk profile based on the outcome of the transaction. For example, analysing the transaction data can include comparing the transaction data with previous transaction data for the borrower retrieved from the borrower data record.

Analysing transaction data can include identification of statistical outlier transactions for the borrower.

Analysing the transaction data can include comparing the transaction data with industry transaction data for an industry sector relevant to the transaction. In an embodiment, adjusting the borrower risk profile can include calculating a borrower star score for benchmarking borrowers.

In some embodiments of the lending system the matching engine is configured to match borrowers and lenders for a transaction based on:

a borrower risk profile for the borrower requesting the transaction,

an asset type for the transaction,

asset purchase price for the transaction, and

lender risk tolerance profiles for a plurality of lenders. In an embodiment, the matching is performed by the matching engine:

identifying an initial candidate set of a plurality of lenders based on the asset type and the asset purchase price, and filtering the initial candidate set of lenders based on one or more parameters of the borrower risk profile, to provide a final candidate set of one or more lenders having risk tolerance profiles correlated with the borrower risk profile.

In another embodiment the matching is performed by the matching engine:

identifying an initial candidate set of a plurality of lenders based on the asset type and the asset purchase price, and

applying a clustering algorithm based on parameters of the borrower risk profile and lender risk tolerance profiles to select a final candidate set of one or more lenders having risk tolerance profiles most like the borrower risk profile.

The matching engine can be further configured to control a transaction offer and acceptance process, wherein at least one lender is selected from the final candidate set and transaction data transmitted to the at least one lender via the communication network for output of offer data to the one or more lenders and in response to an input being received indicating acceptance of the transaction by the one or more lenders, cause the transaction monitoring and reconciliation module to formalise the loan.

An embodiment is further configured to facilitate target return in investment (ROI) reward loans, wherein for one or more loans between a lender and borrower an agreement is made for profit sharing to be adjusted in favour of the borrower once a target ROI has been achieved for a defined period, and wherein the transaction monitoring and reconciliation module is configured to monitor the cumulative ROI for the one or more loans between the lender and borrower and automatically adjust profit sharing parameters in accordance with the agreement and applying the adjusted profit sharing parameters for ongoing loan reconciliation for the borrower and lender for the remainder of the defined period.

A further aspect provides a lending method implemented in a lending system using computer system processing and memory resources accessible by borrowers and lenders via a communication network from borrower and lender computer systems, the lending method comprising the steps of:

receiving, via an access management module of the lending system, loan request data from a loan requestor borrower or lender having a profile set up in the lending system; determining by a matching engine of the lending system one or more candidate borrowers or lenders matched for the loan request for peer to peer lending with profit sharing;

facilitating, by the lending system, a loan offer and acceptance process between the loan requestor and one or more of the one or more candidate borrowers or lenders;

formalising, by the lending system, a loan agreement between one or more accepting borrowers or lenders of the one or more candidate borrowers or lenders and the loan requestor;

monitoring, by a transaction monitoring and reconciliation module of the lending system, progress of the loan and performing reconciliation at the completion of the loan transaction; and

interacting, by the a transaction monitoring and reconciliation module of the lending system, with a finance interface to effect transfer of funds. The step of determining one or more candidate borrowers or lenders can include the steps of:

where the loan requestor is a borrower:

retrieving, by the lending system from a borrower database borrower data for the loan requestor including borrower risk profile and preference data;

retrieving by the lending system from a lender database lender data for one or more lenders including lender risk tolerance profile and preference data; and

identifying one or more candidate lenders from the one or more lenders based on loan request data, the borrower risk profile and preference data for the loan requestor, and lender risk tolerance profile and preference data for each of the one or more lenders;

and

where the loan requestor is a lender:

retrieving by the lending system from a lender database lender data for the loan requestor including lender risk tolerance profile and preference data;

retrieving, by the lending system from a borrower database borrower data for one or more borrowers including borrower risk profile and preference data; and

identifying one or more candidate borrowers from the one or more borrowers based on loan request data, the lender risk tolerance profile and preference data for the loan requestor, and borrower risk profile and preference data for each of the one or more borrowers.

The step of identifying one or more candidate lenders can be based on:

a borrower risk profile for the borrower requesting the transaction,

an asset type for the transaction,

asset purchase price for the transaction, and

lender risk tolerance profiles for a plurality of lenders.

In an embodiment the step of identifying one or more candidate lenders performed by the matching engine comprises the steps of:

filtering the initial candidate set of lenders based on one or more parameters of the borrower risk profile, to provide a final candidate set of one or more lenders having risk tolerance profiles correlated with the borrower risk profile.

In another embodiment the step of identifying one or more candidate lenders performed by the matching engine comprises the steps of:

applying a clustering algorithm based on parameters of the borrower risk profile and lender risk tolerance profiles to select a final candidate set of one or more lenders having risk tolerance profiles most like the borrower risk profile. The matching engine can further control a transaction offer and acceptance process comprising the steps of:

selecting at least one lender from the final candidate set; transmitting transaction data to the at least one lender via the communication network for output of offer data to the one or more lenders; and

in response to receiving an input indicating acceptance of the transaction by the one or more lenders, causing the transaction monitoring and reconciliation module to formalise the loan.

The step of identifying one or more candidate borrowers can be based on:

a lender risk tolerance profile for the lender requesting the transaction,

an asset type for the transaction,

loan amount, and

borrower risk profiles for a plurality of borrowers.

In an embodiment the step of identifying one or more candidate borrowers performed by the matching engine comprises the steps of:

identifying an initial candidate set of a plurality of borrowers based on the asset type and the loan amount, and

filtering the initial candidate set of borrowers based on one or more parameters of the borrower risk profile, to provide a final candidate set of one or more borrowers having risk profiles correlated with the lender risk tolerance profile.

In another embodiment the step of identifying one or more candidate borrowers performed by the matching engine comprises the steps of:

applying a clustering algorithm based on parameters of the lender risk tolerance profile and borrower risk profiles to select a final candidate set of one or more borrowers having risk profiles most like the lender risk tolerance profile.

The method can further comprise an initial step for each lender of setting up a lender user account in the lending system, including the steps of:

receiving lender data; and

analysing the lender data, by a lender profiling module of the lending system, to determine risk tolerance profile and lending preference data for the lender.

The method can further comprise an initial step for each borrower of setting up a borrower user account in the lending system, including the steps of:

receiving borrower data; and

analysing the borrower data, by a borrower profiling module of the lending system, to determine risk profile and borrowing preference data for the borrower.

In an embodiment of the method performing reconciliation includes the step of a profit sharing engine of the lending system applying profit sharing rules to calculate return shares to borrowers and lenders. An embodiment of the method further comprises the steps of:

receiving monitored transaction data from the transaction monitoring and reconciliation module on conclusion of a transaction wherein one or more lenders loan funds to a borrower; analysing the transaction data by a borrower profiling module; and adjusting the borrower risk profile based on the outcome of the transaction.

Analysing the transaction data can include comparing the transaction data with previous transaction data for the borrower retrieved from a borrower data record.

Analysing transaction data can include identification of statistical outlier transactions for the borrower. Analysing the transaction data can include comparing the transaction data with industry transaction data for an industry sector relevant to the transaction.

Adjusting the borrower risk profile can include calculating a borrower star score for benchmarking borrowers.

An embodiment of the method further comprises facilitating target return in investment (ROI) reward loans wherein for one or more loans between a lender and borrower an agreement is made for profit sharing to be adjusted in favour of the borrower once a target ROI has been achieved for a defined period, wherein the method further comprises the steps of:

monitoring, by the transaction monitoring and reconciliation module, the cumulative

ROI for the one or more loans between the lender and borrower; and

in response to the borrower achieving the target ROI for the defined period, automatically adjusting profit sharing parameters in accordance with the agreement; and applying the adjusted profit sharing parameters for ongoing loan reconciliation for the borrower and lender for the remainder of the defined period.

Brief Description of the Drawings

Figure 1 is a high level block diagram of a system in accordance with an embodiment of the invention.

Figure 2 is a flow chart showing an example of a process for initialising a lender account and establishing a lender profile.

Figure 3 is a flowchart showing an example of a process for a borrower establishing a borrower account and initial profile.

Figure 4 is a flowchart of an example of a process for establishing an initial risk profile for a borrower account.

Figure 5 is a flowchart of an example of a borrower and lender matching process.

Figure 6 is a flowchart of an example of one method for a matching engine to determine a set of candidate lenders.

Figure 7 is a flowchart of an example of a borrower risk characterisation process based on transaction data stored in the system.

Figure 8a is a flowchart of an example of a process for establishing a co-lending loan. Figure 8b is an flowchart of an example of a process for determining the lenders in the co- lending process example of Figure 8a.

Figure 9 is an example of a computer system that may be utilised to implement an embodiment of the invention.

Figure 10 is an example of a transaction process.

Figure 1 1 is an example of a lender dashboard for enabling lenders to interact with and view information in the system. Figure 12 is an example of a borrower dashboard for enabling borrowers to interact with and view information in the system.

Figure 13 is an example of a system administrator dashboard for the system. Detailed Description

Embodiments of the present invention provide a lending system and computer system implemented method of lending facilitating profit sharing. The invention provides a tool for use by lenders and borrowers to enable peer to peer type lending arrangements to be established, monitored, analysed and reconciled. Embodiments of the invention also facilitate operation of a profit sharing lending model, where borrowers seek funds to purchase trading goods (for example, a car dealership purchasing cars to sell) or disposable assets (for example, shares or bonds, real estate for development/resale, any stock in trade). On sale of the goods purchased using the "loaned" funds, profit from the sale is shared between borrower and lender. The system is configured to automatically identify compatible borrowers and lenders, establish the borrower/lender relationships, administer agreements, monitor the loan, and facilitate financial reconciliation and profit sharing on conclusion of the loan and/or individual single asset sale or per transaction. In some embodiments loans can be made up of thousands of single assets across multiple borrowers and lenders. Embodiments of the system can also be configured to perform automated performance assessment of borrowers and/or lenders and output risk management data and ratings. In some embodiments of the system the risk management data and ratings are fed back into the automated borrower and lender matching process. The system can be configured to learn and report behavioural patterns of lenders and borrowers according to transactional behaviour. Lenders and borrowers can interact with the system via an internet portal to manage their portfolio.

An overview of a system embodiment is illustrated in Figure 1 . An embodiment of the invention provides a lending system 100 implemented using computer system processing 1 10 and memory resources accessible by borrowers and lenders via a communication network 125 from borrower computer systems 120a-n and lender computer systems 130a-n. The lending system controller 1 10 comprises an access management module 1 15, a profiling module 1 12 for profiling borrower and lenders, a matching engine 1 14 configured to match borrowers with lenders, and a transaction monitoring and reconciliation module 1 17. The system 100 can also comprise one or more databases storing borrower 145, lender 140 and transaction 150 data. The system may be implemented using fixed hardware processing resources and memory, for example a server or computer, or distributed "cloud based" processing and memory resources. The various processing modules can be implemented using any suitable combination software, firmware and hardware. The access management module 1 15 is implemented using processing resources and including a network communication interface configured to enable data transfer between the lending system and the computer systems of borrowers and lenders via the communication network, and memory resources storing lender data records 140 and borrower data records 145, for example in structured databases. The access management module is configured to enable setup of user accounts for borrowers and lenders and control data access input and display by the borrower and lender computer systems. The access management module enables users (for example, borrower and lenders) to set up accounts in the system to access system services, in particular, pairing of borrowers and lenders for profit sharing type loan transactions. The access management module can provide an Internet portal which enables entities to apply for system access, and once access is established access system services. Entities will nominate as a borrower or lender. Borrowers will undergo a borrower application process facilitated by the system. Lenders will undergo a lender application process facilitated by the system.

Some embodiments of the system allow users to apply for an account with the system to monitor business performance utilising the same criteria as borrowers, however without borrowing funds via the system. It should be appreciated that some users may not want to borrow or lend, they may use the system for assessing their business performance, analytics or financial profiling. For example, a user can use this embodiment to validate their business operation, performance and goodwill. This may also enable a user to develop a monitored profile in the system, equivalent to a borrower profile, for benchmarking and performance feedback, prior to seeking to borrow funds via the system. Such users may be treated as borrowers or allocated a separate category of "performance user" in the system. Such users will undergo an application process facilitated by the system similarly to borrowers. It is envisaged that assessment and allowance of borrowers and lenders can be fully assessed and executed via a computer implemented application process, in which the access module configured to determine allowance of a borrower or lender application without manual intervention. In alternative embodiments part of the allowance my require an approval step by a manual operator, for example a final approval decision step by an assessor, made upon review of output from analysis of the borrower or lender application by the system.

Lender initialisation & profiling

A lender in the system may be any entity prepared to loan funds via the system, for example lenders may be private companies, public companies or individuals. A lender can also be referred to as an investor. Throughout this document the term "lender" is used however this term is considered to encompass lenders, investors, creditor, mortgagee, profit sharer, partner, etc. Lenders access the system via a web portal to apply for a lender account with the system. The lender application process includes receiving information for the lender and lender profiling to build, for each lender, a lender profile which can include specific loan targeting preferences, for example based on industry/sector and risk tolerance. For example the initial lender information may be received via a lender survey or questionnaire. This information can be processed by a profiler 1 12 to categorise the lender.

Lender types can include:

1 . Individual (no previous Lending/Investing)

2. Individual (previous lending/investing)

3. Company (private) (no previous Lending/Investing)

4. Company (private) (previous lending/investing)

5. Company (public) (no previous Lending/Investing)

6. Company (public) (previous lending/investing) 7. Other

Each lender may also be associated with a sub category, for exam

1 . Discretionary Trust

2. Unit Trust

3. Hybrid trust

4. Superannuation

5. Institutional Lender

6. Investor

7. Investment Fund

8. Managed Investment Fund

9. Other

Other lender sub categories may include:

1 . Wholesale Lender

2. Retail Lender

3. Warehouse Lender

4. Mortgage Bankers

5. Portfolio Lender

6. Direct Lender

7. Correspondent Lender

8. Other

A lender may be classified in more than one subcategory.

Embodiments of the system can include a lender profiling module configured to, for each lender, receive lender data, analyse lender data to determine risk tolerance profile and lending preference data for each lender. For example the application process may include a Business Lender Profile Questionnaire, and based on the answers input by the lender the profiler identifies the type of industry that the lender may be more psychologically suited to invest in. An example of the process for initialising a lender account and establishing a lender profile is illustrated in Figure 2. Initial a lender account is initialised and basic identification data received (for example, via a web portal and new account setup form or wizard). A lender account identifier is allocated. The system generates and outputs to the lender computer system a questionnaire 210 for completion by the lender. The lender may choose to input the requested data/answers immediately or upload the completed questionnaire at a later time. However, the lender account setup can not be completed until the answers are received. The lender must also nominate an amount they are prepared to lend 215.

Upon completion of the Questionnaire 210, the system can select the lender classification and any sub categories 220. The profiler may also be configured to verify lender data 225, for example verifying lender identity and optionally verifying other data input in response to the questionnaire.

The system can be configured to verify the lender identification 225. For example for an embodiment implemented in Australia, the System may qualify the Lenders details using some, if not all, of the following checks: 100-point Identification

Australian Bank Statement for Proof of Funds

Funds may only be accepted by Bank Transfer from an Australian Bank

The verification checks may vary between embodiments based on the jurisdiction and local identify validation requirements, regulations or typical financial industry practice.

In some embodiments the profiler may be configured to verify input data from independent sources. For example, the profiler may incorporate a verification module configured to access sources of company or individual data to verify the accuracy of input data. For example, the profiler may be configured to access an on-line corporation register enquiry tool - for example, the ASIC web site and ABN/ACN lookup tool - to verify company registration details. If the company data cannot be found or does not match the input data, then a warning may be flagged to an administrator 235 triggering further investigation and validation. The system may also output an error message to the lender allowing an opportunity for correction of input data 238, for example to replace a trading name with the legal corporate entity name or correct typographical errors. The profiler may also be configured to perform data mining on sources such as the lender company web sites, industry press, board reports, financial reports, prospectus, or corporate data registers to verify data submitted in response to the questionnaire. In an embedment a data mining service may be accessed to retrieve such data. In some embodiments the profiler can be configured to retrieve additional data regarding a lender once identified, for example corporation reports, board reports etc. This additional data may be input to the profiling process. The profiler is configured to determine a risk tolerance profile 240 for the lender based on the data entered in response to the questionnaire. In an embodiment the lender may be allowed to choose a risk tolerance range from a displayed list. Alternatively or additionally the profiler may be configured to analyse the input data from the questionnaire to determine a risk profile in accordance with a risk profiling algorithm. For example, an automated risk profiling process may consider the industry the lender is from and a base industry risk tolerance score modified based on lender specific data, such as financial performance history, lender history and other indicators of resilience, for example company size, credit rating, previous losses or setbacks and recovery therefrom, profit and cash flow from lender's core business, etc.

In an embodiment of the system upon completion of the risk profiling the lender can be allocated 245 a Risk Profile Value, for example numbered from 1 to 100, with 1 indicating the lowest risk tolerance and 100 the highest risk tolerance. It should be appreciated that the risk profile value is reflective of the lender's willingness to accept loss. For example, a low value of 1 in indicative of a very risk-averse lender expecting profit from every loan transaction and can be aligned with low risk industry, such as some property sectors, or borrowers with very strong profit track records. In another example a very high risk lender may be an angel investor prepared to risk 100% in a start-up industry sector, very high risk borrower such as a professional gambler, or an industry where stock in trade is time and or environmentally sensitive. It is anticipated that the majority or borrowers and lenders will have risk profiles of varying medium risk levels. In an embodiment the risk profile value is used to further categorise the lender within a risk type category. For example, in an embodiment there are 20 pre-set risk type categories and lenders can be grouped into risk type categories starting from 1 (Low Risk) to 100(High Risk). Each risk type category is increased by increments of 5%.

1 . 1 to 5 low risk industry type

2. 6 to 1 0 increase risk by 5%

3. 1 1 to 15 increase risk by 10%

4. 16 to 20 increase risk by 15%

5. 21 to 25 increase risk by 20%

6. 26 to 30 increase risk by 25%

7. 31 to 35 increase risk by 30%

8. 36 to 40 increase risk by 35%

9. 41 to 45 increase risk by 40%

10. 46 to 50 increase risk by 45%

1 1 . 51 to 55 increase risk by 50%

12. 56 to 60 increase risk by 55%

13. 61 to 65 increase risk by 60%

14. 66 to 70 increase risk by 65%

15. 71 to 75 increase risk by 70%

16. 76 to 80 increase risk by 75%

17. 81 to 85 increase risk by 80%

18. 86 to 90 increase risk by 85%

19. 91 to 95 increase risk by 90%

20. 96 to 100 increase risk by 95%

In an embodiment a lender may nominate an initial risk profile and the system also perform an automated risk tolerance analysis. In this embodiment the outcome of the automated risk tolerance assessment may be compared with the nominated risk profile. If there is a mismatch between the nominated and calculated risk tolerance values, the system may be configured to output this discrepancy to the lender and request confirmation from the lender of the risk tolerance category. In some embodiments the request for confirmation may be triggered based on the discrepancy falling outside defined tolerance criteria. For example, any nomination of a risk type category higher than the calculated risk tolerance may be judged by the system as requiring confirmation to proceed, whereas only once the calculated risk tolerance is determined to be more than two risk type categories above the nominated risk can enable the system to trigger a request for confirmation. In some embodiments the system may be configured to suspend or inhibit proceeding of an automated loan process if the nominated risk tolerance exceeds a threshold value above the calculated risk tolerance. For example more than 4 risk type categories above the calculate risk tolerance. In such an instance, the system may flag the lender for manual intervention and consultation with a mediator before allowing their application to proceed. Alternatively there may be limitations imposed on the lender by the system, for example limiting loan amounts or imposing a borrower distribution requirement to avoid concentration of loans with only one or very few borrowers.

Other factors may be taken into consideration Additional Risk Profile Values

1 . The Lender chooses the 20th category (96 to 100) 2. The Lender chooses to co-lend (a percentage will be allocated to each lender of the asset(s))

3. The Lender chooses to own a percentage of the asset(s) (say 50%) and co- lend the balance according to co-lend preference

4. The Lender chooses to co-lend across multiple asset(s) and Companies

5. The Lender chooses to lend to one borrower across multiple assets

For example, option 3 above may be utilised when a lender takes an equity stake in the borrower's business or a particular endeavour for which the funds are required. It should be appreciated that more than one of the additional risk factors may apply for each lender. For example, options 1 and 3 may apply to a venture capitalist or angel investor, any one of options 2, 4 and 5 may also be applicable in combination with 1 and/or 3. The additional risk factors may serve to increase or decrease an overall risk profile value. For example, a lender for whom option 4 applies may reduce the overall risk exposure and thus reduce the total risk exposure. In contrast where a lender chooses to lend to only one borrower over multiple assets the risk exposure may be adjusted (up or down) dependent on the risk profile of the specific borrower.

Once a lender's initial risk profile is determined and stored 245 the system determines potential industries or industry sectors 250 for loans that are aligned with the risk type category. This list may be output 255 to the lender to allow input of preferences. For example, the categories of industries including sub-categories can be selected from a list. The input selections are then stored 260 with the lender profile for use during borrower matching.

The lender may also enter additional preference data such as specifying a preferred industry or borrower. Alternatively the lender may indicate a preference to manually select industry and borrower for all loans. In an embodiment the system can set defaults to automatically pair the lender with industries and borrowers based on risk profile in the absence on input of preferences to the contrary.

The lender may also indicate willingness to co-lend and any restrictions on co-lending parameters, for example, minimum co-lend of 50%, maximum number of co-lenders, minimum profit share in co-lending agreement etc. The Co-lending percentage for the total Purchase Price and balance for the asset(s) can be determined based on the amount of Lenders per asset(s).

The lender may also specify a target profit margin split value or range. For example, a lender may specify a profit margin split value of 30% or higher, indicating that they will not enter into a loan agreement where the lender portion of the profit margin split is less than 30%.

In an embodiment of the system, all profit marginal splits will incur a 2% System admin fee per transaction. In this embodiment the system may define a set of margin split categories and lenders nominate one or more categories.

In this example the categories include:

1 . 49%/49% split

2. 32.6% split 3 24.5% split

4 10% split

5 5% split

6 Random (from .10% to 99.9%) Depending on cash balance and amount invested/loaned

Borrower Initialisation & Profiling

A borrower in the system may be any entity seeking to borrow funds. The system is particularly suited for borrowers seeking funds to purchase of trade goods or disposable assets. However, the system may also be utilised in some industry sectors for loans against less tangible purposes. For example, an industry sector may be the arts or events, where loans for funds to hold an event are secured against future ticket sales and profit from the event. Another example may be charity organisations where funds are borrowed to be utilised for a specific purpose, for example purchasing goods or making deposits for a fundraising event, and the borrowed funds are repaid via donations or a percentage of proceeds from the fundraising event. The system can therefore be utilised by charity organisations to assist in managing cash flow via short term borrowing.

Similarly to lenders, borrowers also apply for access the system via a web portal to apply for a borrower account with the system. The borrower application process includes receiving information for the borrower and borrower profiling. An example of this process is shown in Figure 3. The borrower initially requests initialisation of an account and provide identification details 310, this can include selecting an industry type and category 320. Input borrower identification details can include:

a Company Name and evidence of incorporation

b Business name registration data (for example ABN register report) c. Proof of Address

d Applicable Licenses

e Certificate of Registration- f. Other

There are different Borrower categories which include:

1 . Individual

2. Company (private)

3. Company (public)

4. General Partnership or Joint Venture

5. Limited Partnership

6. Trusts

Borrower sub-categories can include

1 . Start-up

2. Established 1 to 3 years

3. Established 4 to 6 years

4. Established 7 years plus

Borrowers are also asked to input data regarding the relevant industry sector 330. This data can be used for industry classification for the borrower and to retrieve relevant industry sector information 335 - for example sales history information and baseline industry turnover and risk information. For example, this data may be retrieved from a third party data mining service or an internal historical data base, or combination of sources. The system can also be configured to accept third party industry benchmarking, such as the Australian tax office (ATO) industry performance benchmarking, or similar benchmarking, performed in relevant jurisdictions and industry sectors. The system can be configured with a machine to machine interface to request and retrieve such data from relevant web sites, government or industry body servers via a communication network. The retrieve data can then be analysed and input to borrower risk profiling 340.

In some embodiments a borrower category may be set up for charities or "not for profit" organisation. For example, a specific category may be provided for philanthropic lending and borrowing. For example a lender allocating loaned funds in the philanthropic category may nominate a zero profit share, low profit share (i.e. below 5%) or negative profit share (i.e. donating 2% of the profit from the loan principal on conclusion of the loan transaction, rather than taking a profit share). It should be appreciated that this embodiment may allow a lender to aid a charity in a manner other than straight donations, by facilitating a low interest loan. The status of such organisations may require verification, for example a registered charities or officially registered not for profit organisations, before being deemed eligible for philanthropic loans. For example, this may be verified through official business registers, tax/revenue office etc. Charities and "not for profit" organisations may be subject to risk assessment and monitored similarly to other borrowers, for example to monitor rate of repayment or defaults on low interest loans. Some of the borrower industries and industry subcategories include:

New and Used Car Industry

Consumer Goods

Electronics

Manchester

· Fashion

Property & Construction

Shares & Stock

Marine

Applications

· Other

A borrower can also be instructed to input financial performance and history data, such as: a. Copy of Profit and Loss

b. Business Plans and Forecast

c. Company Tax Returns

d. Bank Statements

Other data requested may relate to borrower social attitude, for example the borrower may be asked to input letters of reference from a number (for example 3) unrelated creditors (e.g. Supplier Reference).

The profiler can be configured to verify the borrower identification data via independent third party information, similarly to as described above for lenders. This may include the system obtaining data such as credit history reports, asset checks, and checks of any relevant registers such as the Australian personal properties securities register (PPSR). This may also include the system data mining relevant information for the borrower 345, such as board reports, financial statements, information from the company web site etc. The profiler may also be configured to extract relevant information from the data mined documents to verify the data input by the user.

Borrowers are also asked to input a margin split offer 350 which is stored with the borrower data.

The Borrower can be allocated a Risk Profile Value based on the answers to the required Borrower Registration Form. In an embodiment the borrower risk profile value is an aggregate value taking into account a plurality of different risk parameters. The borrower risk profile can include the risk profile value and a set of parameters characterising different factors contributing to the overall risk profile value (otherwise referred to as a risk score). An example of a borrower risk profiling process 400 is illustrated in the flowchart of Figure 4. In this example the inputs to the risk profiling process include: statistical industry/sector information, historical industry information which may include turnaround times, profit margins, etc. This data can be used to determine industry benchmark information. For example, statistical analysis may provide average sales turnaround times, average profit margins, also the distribution functions (mean, median standard deviation etc.) for sales for the relevant industry the data may include or be used to calculate a baseline industry risk profile. The baseline industry risk profile may also include a plurality of weightings for application to individual risk parameters. It should be appreciated that different industries can perceive risk differently or have greater risk sensitivity to some parameters than others. For example in the car industry or perishable goods industries (such as flowers or fruit and vegetables) rapid turnover time for sale of items is more important than in the property industry. Further, risk profiles for an industry may change over time, particularly in response to greater financial, economic or legal factors. Modelling baseline industry risk profiles using weightings for different parameters allows the system to use a common risk profiling process (subroutine) across different industries, and the individual industry variation accommodated by different parameter weightings. This also allows for intervention by an operator to adjust the baseline risk profile if necessary, for example in response to a legislation change in the relevant industry or event such as a financial crisis or industry disruption. In some embodiments a baseline industry risk profile may be input to the system by a human operator based on industry analysis or received from an industry expert, this initial baseline may be adjusted over time based on feedback gathered from monitoring performance of loans facilitated by the system for the industry. In another embodiment a baseline risk profile may be established over time based on performance statistics for the industry for transactions managed via the system.

The baseline industry risk profile may be based on a plurality of different parameters, which are relevant to the investment risk for a lender. For example, such parameters may include profit margin on sales, stock turnover, defaults etc. Industry baseline data 410 may include statistical data or industry norms for each parameter. Alternatively or additionally for each parameter the industry baseline data may include key statistical data for each parameter - for example mean and standard deviation for profit margins. The industry baseline data may also be adjusted for geographic variation if applicable, for example based on operating state or territory. Borrower data is input to the risk profiling process, this data may include performance history monitored by the system, data input in response to an initial borrower survey, feedback from third parties, and borrower data from various sources obtained via data mining etc. The system may receive borrower historical data and third party data or feedback regarding the borrower as input to risk profiling. Borrower historical data may be input by the borrower via the system, for example sales and other financial records. Third party data may also be provided, for example third party feedback data, survey data, ratings data, media commentary data etc.

The data from various sources is analysed to characterise the borrower performance using a set of performance parameters. For example, the set of performance parameters can include: transaction values, stock turnover values, stock turnover time, return on investment (ROI), borrowing amounts, defaults, satisfaction ratings etc. For each parameter, a plurality of attributes and attribute values are calculated as appropriate for the particular parameter. The individual borrower parameters are compared with the industry baseline values 425. In the embodiment shown this is performed per parameter to allow parameter based adjustment and weighting within the borrower risk profile. For example, in an embodiment for each parameter a value calculated for the borrower is compared, by the system, with the industry benchmark, based on this comparison the borrower score for the parameter may be set or adjusted positively or negatively for contribution to the risk profile score.

For example, a borrower's nominated borrowing amount can be compared with industry average 430 and where the borrowed amount is lower than the industry average a positive adjustment 432 is made to the value for the risk score, and where the borrowed amount is more than the industry average a negative adjustment is made 434. For stock turnover time 436 may be positively adjusted 438 for faster average turnover and negatively adjusted 440 for slower average turnaround times. For return on investment 442, this may be positively adjusted 444 if the borrower percentage value is higher than the industry average, and negatively adjusted 446 if the average value is lower than the industry average. For settlement time delay 448 the parameter value can be positively adjusted 450 if the borrower average delay is lower than the industry average, and negatively adjusted 452 if the average delay is higher than the industry norm. For loan defaults 454 any default may results in a negative adjustment 456 and a positive adjustment 458 or no adjustment made for a borrower history having no defaults. In each instance the quantum of the adjustment may be fixed or variable as a function of the difference between the borrower parameter value and the industry benchmark value. In some embodiments an adjustment may only be made where the defence between the borrower parameter value and exceeds a threshold value, the threshold difference value may be defined in the industry benchmark data.

Once the individual parameters are compared with the industry benchmark and adjusted, if necessary, the borrower risk profile score is calculated in accordance with the industry parameter weightings 460. Then optionally third party data specific to the borrower may be analysed 465, for example reference data or credit check data, and the risk profile score adjusted 470, if necessary. In an embodiment the borrower risk profile score is an integer between 1 and 100.

In an embodiment of the invention the above borrower risk profiling process can be executed periodically, for example every few months, or on an ad-hoc basis to reassess the borrower risk profile and risk profile score based on recent performance history. In an embodiment of the system borrower performance is monitored and recorded for each loan/stock transaction. This data may be stored in the borrower record for utilisation in a periodic automatic risk profile recalculation (for example weekly, monthly, bimonthly etc.) or dynamic risk score updating after conclusion of each loan/stock transaction. It is envisaged that the system can automatically monitor performance of borrowers and lenders and adjust risk profiles so that risk profiles can change over time based on borrower performance for actual loan/stock transactions executed via the system. In some embodiments of the system risk profiling may be manually audited, for example in response to a request from a borrower who believes the automated assessment does not accurately reflect their actual performance, a request for an audit and adjustment may require payment of an auditing fee. In an embodiment manual risk calculation and adjustment may be limited to a defined proportion of the borrower risk score. Further the system may be configured to reduce the influence of a manual adjustment over time, so that actual borrower performance (rather than an auditor's opinion which may be based on performance in areas other than those transacted via the system) can provide the predominant influence for the risk score utilised for transactions monitored via the system. In an embodiment of the system after transacting with the system for 1 month borrowers' risk can be re-assessed by the system based on their transaction data. The initial manual assessment will have less weight on the borrower's risk level each month thereafter. After 12 months it may no longer have an effect on the risk level.

: Month After Initial Manual Month after : Manual Assessment I System Automated

I Assessment subsequent manual i Weight (%) i Assessment Weight(%) assessments

M 00

; 1 ; 92 ; 8

: 2 : 83 : 17

: 3 : 75 : 25

; 4 ; 67 : 33

; 5 ; 58 : 2

: 6 0 ; 50 ; 50

; 7 1 ; 42 ; 58

: 8 2 : 33 : 67

: 9 3 : 25 : 75

; 10 4 ; 17 : 83

I 11 5 ; 8 : 92

I 12+ 6+ ; 0 ; 100

Table 1 : Example of manual risk assessment weighting adjustment over time

In an embodiment of the system, automated Risk assessment can use the parameters described below to work out the borrower's risk level based on a comparison on the borrower's performance across these parameters with historical data stored by the system across all borrower and lenders, for example utilising statistical analysis of the performance parameters and say determining where a borrower's performance falls compared with the mean and standard deviation across the history of investment data stored in the system. The parameters considered when assessing borrower's risk level can include:

• Base Industry Risk. This may be set by a system administrator and, each industry will have their own base risk level.

• Total amount borrowed across all Lenders. The more the company has borrowed the higher the risk may be.

• Return on Investment (ROI) % compared to industry average.

• Turnover time of assets compared to industry average.

• Time delay between sale of asset and distribution of interest.

• Lender Feedback. Lenders will be able to give positive or negative feedback on a borrower once they have started a lending agreement. This can directly affect the risk of the borrower.

• Defaulted payments within the last 24 months can affect the risk significantly.

After the first 12 months, if a company feels the automated assessment does not reflect their company fairly they can request a subsequent manual assessment from our team of assessors for a fee. This may carry a maximum weight of 50%, with weight decreasing monthly for 6 months.

In an embodiment each borrower record includes a data element storing the initial borrower risk profile score, further data elements store data relevant to each parameter used for the risk profiling process, and other data potentially relevant for utilisation in borrower and lender matching processing, transaction and account management.

Once this has been completed, the Borrower uploads the information ascertaining to the asset(s) to be subject of loan(s).

Borrower & Lender Matching

It is envisioned that the system can support many lenders and borrowers with various profile characteristics and risk profiles.

The system can analyse these profiles and match borrowers and lenders according to their preferences. The borrower profiles are consistently changing according to their performance and rating, which is assessed according to real time data generated by the system as each transaction occurs. A background process can be used to consistently update rating and profile matching in real time.

The System can match the Lender to any one or more of

Borrower type

Stock type

Stock Purchase price

The inputs to the borrower and lender matching process are: borrower data and risk profile, lender data and risk profile, and stock data for the stock subject of the requested loan.

In an embodiment the lender and borrower matching is performed automatically by a matching engine 1 14 based on borrower and lender profiling data. An example of a matching process for a loan is illustrated in the flowchart of Figure 5. Input to the matching processing are: borrower data 505, including the borrower risk profile and preference data, and stock data 510 identifying the stock to be purchased using the loan and the requested loan amount; and lender data 515, including lender risk tolerance profile and preference data, maximum loan amount 520 and other loan preferences, for example, whether the lender is prepared to split the loan, and any split preferences. Lender and borrower preferences can also include profit share preferences. Borrower data can also include whether co-lending would be acceptable to the borrower.

The matching process is performed for each loan transaction, and is triggered by a borrower or lender inputting a loan request. Where a borrower inputs a loan request this can include an identification of stock subject of the loan and required loan amount 510. If a lender inputs the loan request then the loan amount (amount the lender is prepared to lend) and optionally an industry sector or borrower may be nominated.

The example shown in Figure 5 is triggered by a loan request input by a borrower 505. If the borrower is not prepared for the loan to be split across two or more lenders 520, then the match must be made with a lender prepared to provide the full requested loan amount. In this instance a first filtering step 530 may be performed to identify lenders prepared to lend the full requested amount. A further filtering step may be 535 based on lender industry preference, for example to include lenders who have indicated a preference for the relevant industry & sector and those without industry/sector preference restrictions, or exclude lenders without matching industry preferences.

The filtering steps provide an initial set of lenders to match to a loan for input to a matching analysis based on the borrower and lender risk profiles 540. Borrower and lender matching is performed by a matching engine. In an embodiment the matching 540 is performed by iterative filtering of the search set based on barrower risk profile parameters. An example of this process is illustrated in figure 6, in this procedure the input is an initial search set 610 which may comprise records for all lenders prepared to loan the required amount for the borrower industry. The filtering criteria 620 is set for each successive filtering iteration. Each filtering iteration can based on a parameter of the borrower risk profile and a value range determined as filtering criteria for each parameter. For example, one of the borrower risk parameters is average return on investment, this may be expressed as a percentage value, and the matching filter criteria may be set as a percentage range centred on the borrower parameter value. The matching engine applies the filter criteria 630 by comparing the parameter values of each record in the search set with the filter criteria. Based on whether or not the lender profile parameter value falls within the filter criteria the lender is retained within the search set or is discarded. The updated search set can then be input to the next filter iteration, based on the next filter criteria. In an embodiment where the matching is triggered by a lender request, a set of candidate borrowers may be identified, similarly to that described to match borrowers to the lender, based on the lender and borrower risk profiles. It should be appreciated that matching borrowers with lenders is also based on profile values and therefore can be performed similarly to the matching processes described with the lender being fixed and a set of candidate borrowers searched based on borrower profiles.

After a filtering iteration the matching engine compares the filtered search set with end criteria for the search 640. The filtering iterations may be performed until end criteria are satisfied. For example, in an embodiment the end criteria may require filtering based on a predefined set of parameters. In another example, the end criteria may be based on the number of candidate lenders remaining in the search set. For example the end criteria may be satisfied when a defined number of candidate lenders remain, for example one, 5, 10 or 30 lenders. Alternatively the end criteria may be execution of a given number of filtering iterations.

Where the end criteria are not met, the matching engine determines the next filtering step to apply 650 and repeats the filtering steps. For example, the matching engine may have a defined set of filter rules for each industry, each rule may define the parameter of interest and a filtering range or an equation or algorithm to apply based on the given borrowing criteria to determine the filter criteria for the parameter. The filtering rule may allow more than one filtering iteration based on a parameter, with each filtering iteration applying narrower (more targeted) filtering criteria until the end criteria is satisfied. Once the end criteria are satisfied 640, the final search set is stored 660. In an embodiment the filtering may also include ranking of the final set of records based on the "best fit" to the filter criteria. In an alternative embodiment the matching engine comprises a self-learning system such as a neural network which has been trained using a training set of borrower and lender profiles and historical data of multiple loan transactions that have been manually or semi automatically matched. This training step enables configuring of the neural network to make matching decisions based on the decisions previously made by the human operator.

In another embodiment the matching engine applies a clustering algorithm to cluster lenders based on risk profile and preferences, in an embodiment the borrower profile may also be input to the clustering process, such that the borrower will be clustered with the lenders based on the same criteria and the cluster including the borrower is allocated represents the best fit lenders. In an embodiment the matching engine uses a self-ordering maps (SOM) algorithm. This algorithm operates to analyse records of a search set and identify records as more or less similar to each other based on analysing the parameter attribute values. In embodiments of this invention the parameters compared are those of the respective risk profiles. The cluster algorithm compares a plurality of parameter attributes across the search set to identify a cluster of lenders having most similar risk profile to the borrower risk profile. In an embodiment the matching engine may be configured to confine clusters to a given number or range of lenders, for example a set of 3, 5, 10 or 15 lenders, however this number can be arbitrarily set by a system operator. Alternatively the matching engine may be configured to determine the optimal matching lenders based on the clustering processing outcomes and a measure a similarity used to determine the final number of lenders in a search set. In such an embodiment where only a few lenders have risk tolerance profiles compatible with that of a borrower, then the resulting cluster can provide a small number of lenders, whereas for another borrower many lenders may have a risk tolerance profile similar to the risk profile of the borrower and therefore the resulting cluster comprise a larger number of lenders. Although a SOM algorithm is discussed, alterative clustering algorithms may also be used. Use of clustering algorithms can also allow clustering of multiple borrowers and lenders, with borrowers and lenders clustered together based on risk parameter attributes and loan requirements, thus allowing individual borrower and lender matching to follow from cluster membership. Such an embodiment may be advantageous in systems having a very large number of borrowers and lenders. In an embodiment the system may generate a pool of loans that multiple lenders may join according to lender profiles and multiple borrowers may join according to borrower performance. In this embodiment the matching is performed based on a candidate set of criteria, for example a candidate set of risk profile values and set profit margin share for the group, for the pooled lender and borrower group and both borrowers and lenders are matched to the target group criteria using any of the matching processes described above. Where borrower and lender pools are established, each lender and borrower is allocated a share of the loan proportional to the lender or borrower participation respectively. For example, a lender (Joe) contributing $40,000 to a $100,000 loan pool will receive a 40% share of the loan, and a borrower borrowing $50,000 from the loan pool thereby contributes 50% of the profit for the total loan. If the borrower returns a 20% profit and the profit share is 50%, the profit share distributed to lenders if 10% ($5,000) and the 40% share of this profit returned to lender Joe will be $2000, with the remaining $3000 distributed to other lenders of the pool based on loan share. Profit shares from other borrowers will be similarly distributed within the pool.

Once a set of candidate lenders has been identified by the matching engine 540, this candidate lender set is then analysed to identify the best fit options 545 for borrower and lender pairing from within the candidate lender set. For example, this may be based on a ranking of best fit to filter criteria or based on closest match to one or more profile parameters. It is envisaged that in some embodiments of the system a borrower and lender offer and acceptance process is required before formalising a loan transaction. In some jurisdictions such an offer and acceptance phase maybe required to enable a legally binding agreement to be established. In some embodiments user agreements may impose non- disclosure and non-circumvention obligations, including clauses to impose an obligation on users to maintain the confidentiality of information and restrict use of information disclosed by the system in the course of lender and borrower matching and loan agreement execution. Users are not allowed to share distribute or use any information obtained from the system regarding any other users details, business profile, privacy etc. In some embodiments this information may be revealed to users in a manner whereby the user is inhibited from forwarding or further use of such information by the system. For example using digital rights management techniques to restrict access to confidential lender data to the borrower only, encryption of the loan offer data, one time access codes, automatic deletion of loan offer data after a specified period of time (i.e. 5 minutes, 1 hour, 1 day) etc., thereby causing the system to limit the availability of offer data or data regarding lenders to borrowers.

In some embodiments whether an offer and agreement process is executed may be optional, for example this requirement may be imposed by a system operator or on an individual basis by borrowers and lenders. Whether or not an offer and acceptance process is required or preferred may also vary between industry sectors.

In the offer and acceptance process, initially the "best fit" candidate lender is identified 545 and an offer communicated to the lender 550. For example, the offer may be notified to the lender via the lender system access portal (web site or client application). The notification can advise the lender of a potential loan application and enable the lender to view the loan details and accept or deny their participation in the loan 560. For example, a loan offer notification may include a push notification to a lender client application (which may also involve a relay of the push notification to a specified delegate via email or to a delegate user device) and include a mechanism to accept or deny the offer. For example, a hyperlink to the loan offer details in the lender portal of the system and/or a button to indicate acceptance of the offer. In some embodiments the offer information can also include an acceptance window, for example, 5 minutes, an hour or 2 days. Any acceptance window may be set in consideration of the nature of the transaction and industry norms. For example, for loans for property the acceptance window may be 24 hours or more, for the automotive industry the acceptance window may be measured in minutes, for example 5-20 minutes. In response to an offer the lender or lenders input an acceptance or reject the offer via the client application or web portal. In some instances the offer may be extended to more than one lender as a co- lender agreement. In such instances the loan offer may also set out the share allotted for each candidate lender. Where one lender declines an offer 560, the offer can be extended to the next candidate lender 570 and the next candidate lender has the opportunity to take up the loan. Once acceptance from lenders 560 are received to fully fund the loan, the offer may be communicated to the borrower 580 for acceptance or confirmation. For example, in some embodiments of the invention the borrower may be obliged to accept offers for the amount requested and the loan offer is communicated for information purposes only. In other embodiments of the system the loan offer may be communicated to the borrower and the borrower is required to accept the offer 585 before the loan transaction can proceed 590. If the loan offer is rejected 585, the system can look to the next best match 545 for lenders and repeat lender offer and acceptance processing as discussed above before making a further offer to the borrower. A borrower may have a limited number of allowed rejections for a loan, for example one rejection allowed. For example, the borrower may be allowed one rejection for each loan transaction. In some embodiments, the borrower notification may indicate whether or not any further candidate lenders are available. If a borrower rejects a loan offer and no further candidate lenders are available, then the loan is forgone and the borrower must seek alternative funding. In some embodiments, more than one lender offer may be offered and the borrower nominates the preferred offer. In such an embodiment the system can determine loan parameters for each candidate lender (including loan split where co-lending options are enabled) and a set of potential offers are communicated to the lender for approval. For example a set of loan scenarios may be communicated to each lender for respective acceptance. Accepted potential loan scenarios are then communicated to the borrower to allow selection of the preferred scenario by the borrower.

Once a loan offer is accepted 585 the loan is formalised 590 via the system to allow release of funds to the borrower.

It should be appreciated that in some embodiments where fully automated matching is performed the matching step 540 may return only one candidate lender and the loan transaction proceed automatically to formalisation without the offer and acceptance steps discussed above. For example, this embodiment may be used for loans of small amounts where lenders risk is highly distributed over a plurality of small loans.

The system can be configured to enable a borrower to nominate or choose a specific lender, rather than go through the automated borrower and lender process. For example, a borrower may wish to continue to use a lender that they have worked with previously or have a known trusted relationship. Similarly the system can be configured to allow lenders to select a specific borrower. Pooling Multiple Lenders

As discussed briefly above, in some circumstances, it may not be possible to provide a one- to-one matching between borrowers and lenders. For example, a required loan amount may not be able to be funded by a single lender. The system can be utilised by small scale investors and therefore it may be a common scenario for co-lending arrangements to be required. Also the circumstance may exist where a lender has input a first amount of funds to the system and a first current loan transaction may be for less that the total funds provided by the lender, in such circumstances the remainder of the lender's input funds may be utilise for a co-lending arrangement to fully utilise the lenders input funds. In a co-lending arrangement more than one lender loans funds for a single loan by a borrower.

Assets can be distributed to the Lender based on a Day Per Dollar Equation. The Day Per Dollar Equation calculates the age of the Lenders monetary investment. If the Lender does not hold 100% of the investment required for the asset, co-lending is offered OR the next Lender can be offered the 100% of the asset if they hold 100% of the investment and so forth.

If there are no lenders with full amount (100% financed) available, then co-lending with other lenders with a low cash balance is offered according to Lender preference and profile. For example, where an asset has a value of 100x, there may be multiple lenders where each lender has a different loan amount for that asset, such as:

Lender one: 5X

Lender two: 30X

Lender three: 50X

Lender four: 15X

The system can calculate as a percentage of the lender dollar value for each lender. In this example, lender one will hold 5% of the asset, lender two 30% etc. One should appreciate that there is no minimum amount that a co-lender can hold of the asset value as a positive percentage. Upon the sale of the asset, the system can distribute the profit margin according to lender share value and lender profit margin value. The system can be configured to ensure all co-lenders matched have same margin split percentage. For example, If co lenders are on a 30% margin split, then lender one will receive 5% of the 30% margin split.

In an embodiment a Lender can select ONE Borrower and distribute funds against the borrower's multiple assets according to:

Stock Purchase Price

Lender Preference and Profile

Loan Formalisation & Administration

The system can be configured to automatically generate Loan Agreement & Product Disclosure Statements. For example, a database of template loan agreements is provided and the system automatically populates the loan agreement based on the parameters of the loan. In an embodiment loan agreements can be standard for an industry with the only negotiable variable being the profit margin split. It should be appreciated that some embodiments of the system can be configured with a default contract. In some embodiments the system may restrict amendments to the default contract such that it is minimally amendable by borrower and lender users in formalising their loan terms.

The contract between the system and performance user will not be amendable to the performance user. Loan Agreements & Product Disclosure Statements can be drawn up between Lender(s), Borrower(s) and this System utilising template agreements automatically populated with data from the system. In an embodiment the Agreements can be populated with information describing:

Risk Profile Value of the Lender(s) and Borrower(s)

· Industry Category and sub-categories

Margin Split between Lender(s) and Borrower(s)

Asset Security Details

Location of Asset(s)

Time Management of funds

· Trust Account Details

It should be appreciated that in some instances the data for some fields may be populated after the initial agreement phase. For example, where a loan is provided in anticipation of the purchase of asset (for example, in anticipation of purchasing cars at auction) the exact price and location of assets may only be populated after acquisition of the assets. In such circumstances the system may be provided to generate a preliminary loan agreement prior to the acquisition of assets and loan agreement being finalised on actual acquisition of assets. The system can be provided with a set of template loan agreements each tailored for a given industry and loan arrangement (i.e. sole lender, co-lender, loan + equity etc.). Based on loan agreement rules the computer system selects the appropriate agreement and determines data to populate the agreement. Once the agreement is generated the agreement can be output to the lender and borrower for confirmation and/or formal execution. For example, in an embodiment the agreement is appended to lender and borrower account records. When a lender or borrower accesses their account (for example, via a client application or web portal) a list of loans can be displayed, for example in a table form showing key loan transaction details and status, the table may also include a link to the generated loan agreement for the loan. In an embodiment the where the lender and borrower are required to confirm agreement to the transaction, the loan status may be highlighted as "pending agreement" and each of the lender and borrower be required to approve the agreement before the loan transaction can proceed. For example, via a web portal the user may be required to select a hyperlink to view the agreement and then indicate agreement, for example via a button, which can trigger communication of the acceptance to the system controller server.

In some embodiments the system can be further configured to apply a digital signature or other authorisation for the borrower and lender either in response to an offer acceptance action by the borrower and/or lender or automatically based on defined system parameters and user preferences. In an embodiment the digital signature may be uniquely generated for each agreement and encrypted to reduce the risk of the digital signature being fraudulently used. For example, the digital signature may include authentication data (for example a temporary code) and be encrypted using a symmetric or asymmetric encryption algorithm, or one way encryption (for example a cryptographic hash). In such an embodiment the system server can have a means for verifying the authenticity of the digital signature - for example via decryption and utilisation of the authentication data to compare or input top a verification process executed at the server. In another example, a digital signature may be regenerated at the server for comparison with the received digital signature.

In an embodiment of the system borrowers and lenders may pre-accept loan offers made via the system. For example, during initial borrower and lender account setup the borrower or lender may be required to commit to an agreement whereby an obligation of offer acceptance is imposed. In this embodiment the system can be configured to generate loan agreements as accepted and a copy of the agreement communicated to the lender and borrower. For example, the generated agreement may be made accessible via the controller server and a push notification transmitted to the lender and borrower to advise of the loan transaction. The push notification may also include a mechanism enabling the user to access the loan agreement. In alternative embodiments a link to the relevant loan agreement can simply be displayed in a loan table or e otherwise made accessible via a web portal or client application.

Once the agreement is accepted by both the lender and the borrower (or multiple lenders as applicable), then the loan in formalised and ready for action to trigger release of funds to the borrower. The loan process and system monitoring thereof is discussed below.

Profit Sharing

Embodiments of the present invention enable profit sharing of margin as an alternative to set interest rate for loan agreements. Generally, a normal loan would attract a set or floating interest rate of the principal loan amount which is calculated annually and paid in instalments. To calculate a % of the margin as an interest rate over thousands of items and multiple borrowers and a multitude of inventory in real-time would almost be impossible to do manually. Further such a scheme would be practically impractical or near impossible to implement even using a computer system as thousands of calculations would be needed in real time as transactions happen to work out the value of the % split for interest on an ongoing basis. In embodiments of the system a profit sharing system is implemented, again such a system would be impractical to implement manually on a large scale. However, in the profit sharing embodiment funds are loaned for the purchase of trading assets. Once the assets are disposed of a profit share calculation is performed. The computer system is configured to perform such calculations in real time on the conclusion of a loan/asset sale. For example, where a loan applies to a plurality of assets, then an interim profit share calculation may be performed based on asset sale and the proportion of the loan associated with the sold asset (for example 30%) without the full loan being discharged. Further on conclusion of each loan the risk profile and ratings for each borrower and lender can be automatically updated based on the outcome of the loan transaction. It should be appreciated that the system cannot be practically realised manually. Further the computer system implementation brings impartial, artificial intelligence, to the borrower lender matching and rating processing.

In an embodiment the lender and borrower profit margin is split as defined in the loan agreement and a lender/borrower profit share ratio. In some embodiments

a system administration fee is charged for each loan transaction. For example, in an embodiment a 2% System admin fee is taken into account in the profit split. In some embodiments a contingency system is also implemented where a Contingency Fee, for example of x% (to be provided at a later date) may also be nominated. The Contingency Fee may be elected by the Lender and is deducted from the Profit Margin before calculation of profit share. Examples of lender/borrower profit share (where the system takes a 2% administration fee) are:

1 . 9/89

2. 19/79

3. 29/69

4. 34/64

5. 39/59

6. 49/49

7. 59/39

The Profit split can be assessed by:

Lender Profile

Borrower Offering,

Borrower Profile and performance The paid margin profit can be calculated based on the sale price of the item, minus the purchase price of the item and itemised variable costs. Itemised variable costs include cost items such as, advertising costs, cost to repair item, shipping or transportation to Borrower fee (if applicable) etc. For example, a Lender with a 40% margin split will receive 40% of the profit from the sale of all asset.

ROI = Profit * MarginSplit/ 100

The formula for interest calculated is a percentage of the net margin on the sale of each collateral item as follows:

Sale Price - Purchase Price = Gross Margin where:

Profit = Net margin = Gross Margin - Sale associated costs

For example, for a used car, sale associated costs may be:

Sale associated costs = Transport + GST + Advertising + Buyer Premium + Reconditioning Costs (or agreed portion of reconditioning costs) + Registration Costs

The sale associated costs can vary based on the type of goods, nature of the sale etc. For example sale associated costs may also include auctioneer fees, legal fees, commission etc. In the example above the interest payable to the lender is forty percent (40%) of the net margin. The paid profit margin can affect the Borrowers Risk Value and borrower rating (i.e. Star Scoring) discussed below. In a preferred embodiment of the system the Borrower MUST pay the Lender their profit margin once it has been finalised within a specified period, for example 3-5 or 7-14] business days (excluding public holidays etc). Failure to comply can negatively affect the borrower rating. The specified period can be a variable configurable for the system, or in some embodiments, this may be negotiated for each loan agreement.

Borrower performance monitoring & rating

In an embodiment risk profile associated with a specific loan agreement can be calculated and communicated with the loan offer or agreement. Loan risks can be calculated based on a combination of industry risk and specific loan transaction risk. Risk may also be calculated for a particular borrower given the current borrower loan exposure. Similarly current lender risk profile based on current loans may also be calculated.

An example of calculation of borrower risk in light of specific transaction data will now be discussed with reference to tables 2 to 6 and Figure 7. The system can include one or more databases storing industry risk profiles 705, borrower profiles 710 and loan transaction data 715 examples of the type of data looked up from each of these databases is illustrated in tables 2 to 4. In this embodiment initial risk profile values for borrower and the industry baseline risks can be utilised to form a snapshot risk assessment for the borrower at a particular time and can include a risk assessment for a specific loan transaction. This can also include a contrast for a specific borrower with other borrowers in the system.

Table 2: Base Industry Risk Profile Table

Table 3: Borrower Baseline Risk Table

Table 4: Loan Table

In a first step 720, each current loan for a given borrower is looked up the in loan transaction data and the total loan amounts for the borrower summed to give the total current loan exposure for the borrower. This data is then compared with industry baseline data to determine a total amount borrowed risk. The comparison may be based on statistical analysis for the industry and/or borrower. For example, historical industry data can be analysed to determine a distribution function for the industry. In an embodiment the company borrowings may follow or approximate to a normal distribution. In this embodiment the borrower total loans may be compared with the industry mean and the variation from the industry mean compared with the industry standard deviation. The risk score can then be calculated based on the variation from the industry distribution model, based on borrower loan exposure and the percentile above or below the industry mean. A weighting may also be applied based on return on investment for the industry. A pseudo-code example for borrower risk calculation based on amount borrowed is given below.

Calculate Total Amount Borrowed Risk

SELECT TotalAmountBorrowed = Sum(LoanAmount)

FROM Loans

WHERE Lenderld = @LenderlD

AND Current = 1;

SELECT @lndustryTotalAmountBorrowedAverage = AVERAGE(CompanyROI),

@lndustryTotalAmountBorrowedStandard Deviation = ST DEV(CompanyROI)

FROM (

SELECT SUM(LoanAmount) AS CompanyAmountBorrowed

FROM Loan

INNER JOIN Borrower ON Borrower. Borrowerld = Loan.Borrowerld

WHERE Borrower. Industryld = @lndustryld

AND Current = 1

GROUP BY Borrower.Borrowerld

);

SET @StandardDeviationsFromMean = (@TotalAmountBorrowed - @lndustryTotalAmountBorrowedAverage) /

@lndustryTotalAmountBorrowedStandard Deviation

SET @TotalAmoutBorrowed Risk =

MAX(MIN((@StandardDeviationsFromMean+4) *100/8, 100), 0);

The system can also consider historical transaction data 715, an example illustrated in table 5, for the borrower to determine a return on investment (ROI) risk based on past borrower performance compared with an industry baseline 730. For example, the average ROI for the borrower is calculated and compared with an industry baseline, and industry statistical data. The outcome of the comparison may be weighted based on the current loan in question. A pseudo-code example for this calculation is provided below.

Table 5: Transaction Table Calculate ROI Risk

SELECT @BorrowerROI 'Average = SUM(Profit) / SUM(AssetPurchasePrice)

FROM Transaction

INNER JOIN Loan ON Transaction. Loanld = Loan.Loanld

WHERE Loan.Lenderld = @LenderlD;

SELECT (SilndustryROIAverage = AVERAGE(CompanyROI), IndustryROIStandardDeviation = ST_DEV(CompanyROI)

FROM (SELECT SUM(Profit) / SUM(AssetPurchasePrice) AS CompanyROI

FROM Transaction

INNER JOIN Loan ON Transaction. Loanld = Loan.Loanld

INNER JOIN Borrower ON Borrower. Borrowerld = Loan.Borrowerld

WHERE Borrower. Industryld = (Slndustryld

GROUP BY Loan.Lenderld);

Set (SStandardDeviationsFromMean = (@BorrowerROl 'Average - (SilndustryROIAverage) / @ In dustryROIStan dardDe viation

SET (STotalROIRisk = 100- MAX(MIN((@StandardDeviationsFromMean+4)*100/8,100),0);

Another aspect of the borrower risk profile is turnover time. This is a measure of the time taken from purchase of stock using borrowed funds to the stock being sold. In other words the time the purchased stock is sitting in inventory awaiting sale. This can be determined based on historical performance data for the borrower and compared with industry data 740. It should be appreciated that the turnover time may vary widely between borrowers in some industries. For example, some borrowers may have a rapid stock turnover compared to others. The turnover time risk for a borrower can be utilised to estimate the term of a loan, for example, length of time loaned funds will be committed. Shorter turnover time may be desirable for some lenders. Some lenders may consider return on investment in combination with turnover time. It should be appreciated that the turnover time risk can be calculated independent of any return on investment or borrowed amount, and this parameter may be considered in combination with other parameters during overall risk scoring, and also in borrower and lender matching based on preferences. A pseudo-code example for calculating turnover time risk 740 is given below.

Calculate Turnover Time Risk

SELECT @AverageAssetTurnover= AVERAGE(DayslnStock)

FROM Transaction

INNER JOIN Loan ON Transaction. Loanld = Loan.Loanld

WHERE Loan.Lenderld = @LenderlD;

SELECT (SlndustryAssetTurnoverAverage = AVERAGE(CompanyAssetTurnover),

@lndustryAssetTurnoverStandardDeviation = ST DEV(CompanyAssetTurnover)

FROM (SELECT AVERAGE(DayslnStock) AS CompanyAssetTurnover

FROM Transaction

INNER JOIN Loan ON Transaction. Loanld = Loan.Loanld

INNER JOIN Borrower ON Borrower. Borrowerld = Loan.Borrowerld WHERE Borrower. I ndustryld = @lndustryld

GROUP BY Loan.Lenderld);

Set @StandardDeviationsFromMean = (@AverageAssetTurnover - @lndustryAssetTurnoverAverage) / @lndustryAssetTurnoverStandardDeviation

SET @TotalTurnoverTimeRisk =

MAX(MIN((@StandardDeviationsFromMean+4) *100/8, 100), 0);

Distribution delay is a delay from the time a sale is made to the time the loan transaction process is concluded and profit share paid by the borrower to the lender account. The distribution delay risk is calculated 750 based on the history data for the borrower and industry statistics. A pseudo-code example is given below.

Calculate Distribution Delay Risk

SELECT @AverageDistributionDelay = AVERAGE(DistributionDelayDays)

FROM Transaction

INNER JOIN Loan ON Transaction. Loanld = Loan.Loanld

WHERE Loan.Lenderld = @LenderlD;

SELECT @lndustryAverageDistributionDelay = AVERAGE(CompanyAverageDistributionDelay), @ Industry DistributionDelayStandard Deviation = ST DEV(CompanyAverageDistributionDelay) FROM (SELECT AVERAGE(DistributionDelayDays) AS CompanyAverageDistributionDelay FROM Transaction

INNER JOIN Loan ON Transaction. Loanld = Loan.Loanld

INNER JOIN Borrower ON Borrower. Borrowerld = Loan.Borrowerld

WHERE Borrower. Industryld = @lndustryld

GROUP BY Loan.Lenderld);

Set @StandardDeviationsFromMean = (@AverageDistributionDelay - @lndustryAverageDistributionDelay) / @lndustryDistributionDelayStandardDeviation

SET @TotalDistributionDelay Risk =

MAX(MIN((@StandardDeviationsFromMean+4) *100/8, 100), 0);

In an embodiment of the system lenders have an opportunity to provide feedback on borrowers. For example, the lender may be invited to provide feedback on the conclusion of a loan transaction. In some embodiments the system can be configured to allow lenders to input borrower feedback at any time during a loan transaction, and on conclusion of the loan transaction, via the lender client application or web portal. The borrower feedback data can be stored in a data record and include a rating (for example, based on a score out of ten or "5-star" rating system, however any rating system can be utilised) and optionally feedback comments. In an embodiment the system may be configured to trigger a borrower feedback survey to solicit feedback from lenders. For example, a short survey having one or more questions for which the lenders are asked to enter a rating or select an option for multiple choices. In response to lenders inputting question responses, the system is configured to translate the feedback into a numeric rating. An example of a lender feedback table is provided in table 6. Feedbackld Lenderld Borrowerld Rating Comment

1 1 1 5 Great

2 1 2 1 Poor

Communication

3 2 2 5 Solid Investment

Returns

Table 6: Lender Feedback Table

A borrower feedback score can be calculated 760 based on the ratings in the feedback table. For example, the score may be an average rating. In some embodiments the system may also be configured to perform text analysis on comments and translate comments into a supplementary feedback rating. For example, the text analyser may be configured to identify key words or key work combinations and determine a rating. For example, the rating may be calculated by accumulating one point, for each positive key word or key word combination and removing one point for each negative keyword or key word combination. Alternatively specific word picture combinations (such as "good communication" or "slow turnover") may be associated with a particular score. It should be appreciated that many alternative scoring regimes may be utilised and the scoring and rating system use can vary between system embodiments. Soring and rating systems may also vary based on industry sector within an embodiment of the system. In an embodiment the feedback score is calculated as an average of the rating for a borrower. A pseudo-code example is provided below.

Calculate Feedback Score

SELECT @AverageFeedbackScore = AVERAGE(Rating) FROM LenderFeedback

WHERE Borrowerld = @Borrowerld

SELECT @FeedbackScoreRisk = 100-(@AverageFeedbackScore*20) The outputs of the individual risk parameter calculations are input to a total risk calculation 770 in which a weighting 780 can be applied to each individual risk parameter. The risk weightings can be tailored for specific industries and may vary between system

embodiments. The weightings may be configurable by a system administrator. To calculate Total Risk each risk items can be given a configurable weighting.

Table 7: Risk Weightings

Calculate Total Risk

@TotalRiskWeight = IndustryBaseRiskWeight + TotalAmountBorrowedRiskWeight + ROIRiskWeight + TurnoverTimeRiskWeight + DistrubutionDelayRiskWeight + FeedbackScoreWeight

@TotalRisk = (IndustryBaseRiskWeight * @ Industry BaseRisk

+ TotalAmountBorrowedRiskWeight * @TotalAmountBorrowedRisk

+ ROIRiskWeight * @TotalROIRisk + TurnoverTimeRiskWeight * @TotalTurnoverTimeRisk

+ DistrubutionDelayRiskWeight * @TotalDistributionDelayRisk

+ FeedbackScoreWeight * @FeedbackScoreRisk) / @TotalRiskWeight

IF(EXISTS(SELECT TOP 1 1 FROM Transaction WHERE SaleDate >= DATEADD(yy,-2, GETDATEQ) AND DEFAULTED =1))

SET @Total Risk = MIN(@TotalRisk * DefaultPaymentPenalty, 100)

The above process provides a borrower risk score based on borrower performance and industry data. The system can also be configured to benchmark borrowers against each other and to compare a particular loan transaction against the borrower's own history.

It is envisaged that each borrower may have thousands of inventory items listed on the system and tens of thousands of transactions processed by the system. This quantity of data presents difficulties for a lender assessing whether, for a transaction, the borrower wholesale/retail price is consistent with previous purchases and sales without a team of analytical accountants working in real time in calculating the margins and reporting back to the lender and borrower if there are any variations in percentages (which, in turn, can affect borrower ratings and Lender returns). If, for a transaction, the borrower is inconsistent with historical performance, then their rating can be affected. In an embodiment a computer system algorithm can be used to do the calculation and reporting as each transaction occurs in real time. On the completion of each transaction, the system can look into the history of that borrower's performance and detect if this transaction has significantly higher or lower returns then we expect from that company. A pseudo-code example of such a transaction is provided below.

SELECT @AverageProfitMargin = AVERAGE(ProfitMargin), @StDevProfitMargin =

STDEV(ProfitMargin)

FROM Transactions

INNER JOIN Loan ON Transaction. Loanld = Loan.Loanld

WHERE Loan.Lenderld = @LenderlD;

SELECT @SDFromMean = (LatestSaleProfitMargin - (SiAverageProfitMargin)/ (SiStDevProfitMargin;

In this example, if the return on this sale is more than 2 standard deviations from the mean then the system flags the transaction as being significantly higher or lower than the company's previous performance. This analysis can also be used to highlight transactions outside the borrower's established patterns as higher risk.

Embodiments of the system can be configured to, using the historical sales data, check the asset purchase price against the asset sales price and form a result that may make a recommendation to the Lender. This rating can be updated in real-time as a transaction is completed. It should be appreciated that over time the borrower's loan distribution characteristics can change and the per transaction updating of the risk profile data can result in the calculated risk adjusting with the changes in loan distribution characteristics based on actual performance for the loans. In an embodiment the system is configured to update borrower performance measures and risk profile on the conclusion of each loan transaction. In an embodiment the system may also be configured to allocate a star rating to each borrower based on performance. In an embodiment the system can automatically score the Borrowers Performance Rating based on the following factors:

• Return on Loan Investment

• Lender Feedback

· Creditor References

The Rating System can allow the Lender to gain more insight into the Borrowers businesses. This rating can be updated in real-time as a transaction is completed. The System can also be configured to automatically check the Borrowers Performance every quarter against a system benchmark (for example 1 % per month in margin interest paid to lenders) to generate and periodically updated Star Score. In an example, for every 10 percent margin paid, the system can allocate a star which can be displayed on the

Borrowers public profile. (Half stars for 5 percent) In some embodiments the star rating is updated after each transaction and the quarterly window for transactions is a moving window. This rating can be updated in real-time as a transaction is completed. Alternatively the star rating may be updated periodically, for example monthly or quarterly. The time period for updating the star score can be programmed into the system of configurable by a system administrator.

A borrower rating can also be calculated to provide a straightforward allowance of lenders to gain more insight into a borrower's performance in general. Whereas a borrower risk profile assesses a borrower's business and performance in greater detail and can also be used to generate a borrower "prospectus" for viewing by prospective lenders. For example, the embodiment of the system can populate a template prospectus documents with the following:

• Borrower Basic Business Details

o Business Name

o Business Address

o Business Contact Number

o Business Website

o Business Email

• Borrower Value Rating

• Borrower Star Rating

· Borrower Performance Rating

• Snap Shot of Borrowers assets to invest in (Up to 10 items)

The Borrower Prospectus can be editable for each borrower and can be automatically updated by the system, for example periodically on a monthly basis. The system can also apply a historical deviation conglomeration algorithm for a borrower to determine the following:

• average purchase price per item

• average profit margin per item

• average sale price per item

These averages will aggregate statistics for a borrower and be applied to determine any deviations (outliers), for example in recently concluded transactions. In response to identification of an outlier the system can trigger an alert or notification to the borrower. An alert for an outlier transaction may also be transmitted to the system and administrator and relevant lenders. The system may be configured to trigger the alert to the system administrator and lender if the data shows a below average figure. This can also affect the Borrowers Value Rating and Star Scoring.

Lender preferences & partial loan agreement

Some embodiments of the system may be configured to allow lenders to choose to lend only a proportion of the asset purchase price. For example, a lender according to preferences and matching may choose to only fund certain % of the purchase price on the borrowers' individual inventory, as the borrower may have thousands of inventory items listed for funding. A manual process to select each item and a % of each item to be funded and to spread the loan across a multitude of items would be a large and time consuming process that would require hundreds of hours to perform manually, then assign each loan amount to each individual item, in turn, giving the lender a large spread of the loan across multiple inventory items and even multiple borrowers across multiple industries and item types.

For an example where an asset has a value of 100x and there are multiple lenders where each lender has a different loan amount for that asset

Lender one: 5X

Lender two: 30X

Lender three: 50X

Lender four: 15X The system can calculate as a percentage of the lender dollar value for each lender such as lender one will hold 5% of the asset (there is no minimum amount that a co-lender can hold of the asset value as a positive percentage). Upon the sale of the asset the system can distribute the profit margin according to lender share value and lender profit margin value. The system can match all co-lenders that have same margin split percentage, for example, if co lenders are on a 30% margin split then lender one will receive 5% of the 30% margin split.

Embodiments of the system can be configured to automatically allocate a loan across multiple items, and this can include allocation of only a portion of the item cost. In this embodiment a computer algorithm can calculate % split of the loan to individual items across single or multiple lenders in real time. An example is shown in the flowchart of Figure 8a. In this example, a borrower seeks funds for a number of inventory items and borrower/lender matching 810 is performed, as discussed above, to identify a group of lenders compatible with the borrower risk profile and prepares to lend across multiple industry items 815. The details of the funds input by each lender to the system and available for application to the multiple item loans can be stored in a table or database, for example see Table 8 below.

When an asset is purchased 820 the system can automatically select which of the candidate Lenders to assign the asset to 825. In an embodiment this determination is made using a formula or algorithm which takes into account the amount of money in an account as well as the time the cash has been unused for. An example of a process for determining the lenders is shown in Figure 8b. In this process the system looks up the set of candidate lenders 830 identified from the borrower and lender matching step 810 to identify the lender with the oldest unallocated (unused) deposited funds 832. If the funds are sufficient for the inventory item 834, the lender can be selected and funds allocated 838 for the loan. If the funds are not sufficient, the portion of the transaction that can be satisfied by the first lender's unallocated funds is subtracted from the amount required 836 and the system looks up the lender having the next oldest unallocated funds for the remainder of the loan amount 836. This can be repeated until the loan amount is fully satisfied based on loans from multiple lenders. The funds are then allocated to the borrower from each lender 838 and the lender records updated to reflect the loan arrangement, including the proportional loan split across all lenders 840. The loan transaction can then be formalised/executed 850 and on sale of the asset 850 the system calculates the profit share split across the multiple lenders based on the proportion of the loan 860.

Table 8: Cash Age table

For example, each time a credit is made into the account, whether it be a cash deposit or a sale of an asset, a new record is added to the Cash Age table with date and Amount

Deposited set. Each time a debit is made on the account the system updates the rows and Amount Used column up to the debit amount starting from the earliest deposit date. A pseudo-code example of updating a cash age table is shown below.

WHILE (@DebitAmount > 0)

BEGIN

SELECT TOP 1 @ AmountUsed = M I N(@ Deb it Amount, AmountDeposited - AmountUsed), @CashAgeld = Id

FROM CashAge

WHERE Loanld = @ Loanld

AND AmountDeposited - AmountUsed > 0

ORDER BY DepositDate

UPDATE CashAge

SET AmountUsed = @ AmountUsed

WHERE Id = @CashAgeld

SET @DebitAmount = @DebitAmount - @AmountUsed

END

In an embodiment, when a new asset is purchased, the system determines which lender to assign it to as given below.

SELECT TOP 1 Loanld

FROM CashAge GROU P BY Loanld

ORDER BY (SU M(DATEDIFF(dd, DepositDate, GetDate())*(AmountDeposited-AmountUsed))) A pseudo-code example for programming the matching engine to pool lenders to inventory items is given below.

SET @ DebitAmount = @AssetPurchasePrice

WHILE (@ DebitAmount > 0)

BEG IN SET @AmountToAssign = 0;

SELECT TOP 1 @ Loanld = Loanld, @TotalCash = (AmountDeposited-AmountUsed)

FROM CashAge

G ROU P BY Loan ld

ORDER BY (SU M(DATEDIFF(dd, DepositDate, GetDate())*(AmountDeposited-AmountUsed))) WHILE (@TotalCash > 0 AN D @ DebitAmount > 0)

BEGIN

SELECT TOP 1 @ AmountUsed = M IN(@DebitAmount, AmountDeposited -

AmountUsed),

@CashAgeld = Id

FROM CashAge

WHERE Loanld = @ Loanld

AND AmountDeposited - AmountUsed > 0

ORDER BY DepositDate

U PDATE CashAge

SET AmountUsed = @AmountUsed

WHERE Id = @CashAgeld

SET @ DebitAmount = @DebitAmount - @AmountUsed

SET @TotalCash = @TotalCash - @AmountUsed

SET @AmountToAssign = @AmountToAssign + @ AmountUsed

END

I NSERT I NTO Asset (Loanld, AssetPurchasePrice, PercentFinance)

VALU ES (@Loanld, @AssetPurchasePrice, @AmountToAssign / @AssetPurchasePrice)

END Business performance benchmarking and monitoring

A discussed above some embodiments of the system allow users to utilise the system as an independent performance monitoring tool, providing feedback without having to participate in borrowing. For example a potential borrower may utilise the system for monitoring performance and establishing a rating in the system prior to seeking to utilise the system for borrowing. The system may act as an independent automated industry benchmarking tool. In an embodiment users utilising the system for business performance monitoring are registered in the system as a type of borrower and can be classified in a special category of "performance user". This special type of borrower can undergo the same registration and risk assessment as for a regular borrower. The performance user to upload data regarding trade goods or assets purchased and subsequent sales data, similarly to borrowers utilising funds loaned via the system. The difference in the performance user case is that borrowed funds are not required, therefore the performance user type borrower account need not go thorough borrower/lender matching processing, nor reconciliation and profit sharing.

However, by uploading purchased goods data and subsequent sales data, statistics such as turnover time, gross margin, net margin, ROI, etc. can be recorded for the user to enable the system to perform analytics, risk assessment, rating and benchmarking similarly to other borrowers. In some embodiments of the system a performance user may set up an account as both a lender and a borrower exclusively linked to lend/borrow only between the two accounts. It should be appreciated that in this embodiment the performance user accounts may be set up the same as any standard borrower and lender, with user configurable parameters for the lender account set to lend exclusively to the borrower account, and the borrower to borrow exclusively from the lender account. Thus, the performance user utilisation of the system can be set up without requiring any specific performance user account type. All profiling, monitoring, transaction execution and rating processing for such performance users is performed similarly to any regular borrower or lender.

This embodiment of the system enables the performance user to use the system as a business management tool, assessing their business performance, utilising the business analytics component, accounting and business reporting, financial profiling etc. for business validation, creating goodwill and/or for independent business auditing and rating. This embodiment of the system allows the performance user to use the system to obtain a performance rating as either borrower or lender by utilising the intelligence of the system. The performance user has the option to choose to convert to a regular borrower or lender with an established ranking, for example by updating configurable account parameters. A performance user can use an embodiment of the system to validate their business operation, obtain a performance rating for their business against industry standards, performance reporting, create goodwill and a better risk star rating. An advantage of utilising the system as a performance user is that by validating business operation via the system the user may improve the user risk rating compares with an initial risk profile determined automatically by the system profiling engine. The performance user utilises the system intelligence to create a profile which is then modified automatically by the system based on user performance recorded via the system before the user chooses to utilise the system for borrowing or lending.

The performance user can adapt business practices in response to benchmarking and rating feedback generated for their business transactions, for example aiming to improve their rating. Once higher ratings are achieved the performance user can use the system for further access to make adjustments in their business practice before they are listed to a larger pool of attractive lenders and borrowers.

Embodiments of the system can provide business record keeping and analytics for the performance user wishing to maintain operational tracking, performance and upkeep. The performance user may elect at any stage to utilise the system to become a borrower or lender. In some embodiments of the system a performance user may be allowed to trigger a "dummy" borrower and lender matching process to perform a hypothetical matching and determine the potential lenders the system may select for matching with the performance user as a borrower if they were to seek to borrow funds via the system. This may provide valuable feedback to a performance user regarding the lenders they may attract and potential lending terms.

In some embodiments of the system, performance users undergo an application process facilitated by the system and performance users may be charged a fee for utilising the business intelligence of the system without engaging in borrowing via the system. For example, a fixed monthly administration fee may be charged.

Transaction Process and Reconciliation

The system includes a transaction monitoring, and reconciliation module configured to formalise loan agreements between borrowers and lenders as described above, after matching of the borrowers and lenders. The system then monitors progress of loan in accordance with the agreement. On conclusion of the loan the transaction monitoring and reconciliation module facilitates reconciliation. The transaction monitoring module is configured to interface with a finance interface to effect transfer of funds.

An example of a loan transaction process is shown in Figure 10. Initially borrower and lender pairing is performed as discussed above. The loan agreement is formalised and the lender transfers funds to a transactional account 1010. Alternatively lender funds already held in transactional account can be used, for example returns from previous loans. Where the lender transfers funds into the transactional account, this may be performed using an electronic form (e-form). The e-form can be populated with the following:

a. Borrower Name

b. Assets/Amount to invest with Borrower

On the borrower's side the borrower purchases assets from a supplier 1020 and uploads supplier invoices. The borrower may allocate invoiced from the suppliers to the designated lender(s) 1030. Alternatively the system may automatically allocate the invoiced based on analysis of invoice data and matching to the loans for the borrower. The loaned funds are transferred from the trust to the borrower to settle the supplier invoices 1040. In an embodiment the system may be configured to apply funds from the trust to settle the supplier invoices. The borrower proceeds to sell the assets 1050. Once an asset is sold, the borrower will input settlement data 1060 and transfer the money from the sale (after expenses are deducted) into the system Trust Account. The loan settlement is then processed 1070. The system can match the sold invoice (minus the expenses to show true profit results) to the purchase invoice. This can also be used to calculate the Borrower Score Rating. The transaction result may also be displayed the result on the Borrowers Public Profile. An embodiment of the system can have an API that can receive invoicing and stock information from the borrower inventory and invoicing management systems in real time. In this embodiment the receipt of invoicing and stock information can trigger the asset sale margin calculation.

To settle the transaction the system can calculate the total profit from the sale and calculate the profit share payable to each party to the transaction. An embodiment of the system can split and transfer the profit from the sale of the asset between the Lender(s) and the

Borrower depending on the split percentage, a system administration fee may also be deducted. An embodiment of the system can match the Borrowers Purchase Invoice to the accredited Suppliers Invoice. An average of previous wholesale purchases of similar items can be calculated to ensure legitimacy. An embodiment of the system can check a borrower purchase invoice against accredited suppliers' invoices (as well as check item wholesale purchase against previous purchases + Or - %).

The funds remitted to the lender may remain in the transactional account for application in future loan transactions or the lender may choose to withdraw the funds, including any profit. The borrower and lender profiles can be updated to reflect the transaction performance 1080.

Contingency Fee Option

A Contingency Fee can be elected by the Lender to be deducted from the shared Profit Margin at a rate of x%, the rate being configurable by the lender or a system administrator. The contingency fees paid accumulate in a contingency fund. The objective of the contingency fee option is to offer some protection to borrowers and lenders for poor performing transactions. Where a loan transaction results in a net loss, the amount paid to the Lender from the contingency fund can be calculated as the loss from the cost price paid. For Example: If a Borrower purchases an item for $21 ,000 but sells it at a loss for $20,000, the Contingency Fee will pay the Lender $1 ,000. The Borrowers Value Rating and Star

Scoring can also reflect this loss in a lower, less appealing rating to future potential Lenders.

In an embodiment, the contingency fund can be caped per borrower. Some embodiments may also implement a regime whereby, depending on their performance and rating, borrowers may be entitled to rebates from amounts they have from their margin share. If a lender has to claim on the contingency fund, then the particular borrower's progress towards the contingency cap can be increased by that amount. An algorithm can be used to spread the loss amount across multiple borrower items, and the spread may be limited to a portion of the borrower's inventory, for example with a maximum not to be more than 20% of borrower inventory. The system can be configured to place a limit on the number of losses allowed, for example a borrower may be allowed to have no more than 5 losses. Once the maximum number of losses is reached, then no additional loan amount or inventory invoices will be paid for borrower. A system triggered option can then be offered to the borrower to pay off loss amounts on each inventory item to the contingency fund for the loss. If the borrower elects to repay the contingency fund, then in response the system may reduce the effect of losses on the borrower's rating. For example if the borrower pays per item from loss one, then in that case then borrower ratings can have a lesser effect by 25%.

Lender performance monitoring & rating

Embodiments of the system can also include a lender monitoring and rating function, for example to enable benchmarking of lenders within the system. In this embodiment data for each transaction for a lender is stored and a monitoring engine analyses the transaction data to output lender specific statistics such as:

• total ROI (% and/or absolute value) for a given period, such as quarterly, yearly, since lender account initiation, or a specified data range input by the lender.

• average ROI (% and/or absolute value), this may be an overall figure (i.e. since

lender account initiation) or for a given period for example, monthly quarterly yearly. Overall loan and ROI statistics for lender

Loan and ROI statistics broken down borrower

Performance barometer for the lender, i.e. indicating loan outcome performance improving or declining

Risk statistics - this may provide information regarding the calculated risks for each transaction compared with the actual outcomes. This can also indicate actual transaction risks compared with the lender risk profile, for example a lender risk profile may indicate risk type category 7 whereas the loan transactions being accepted by the lender are risk category type 4. Such a determination may trigger an adjustment of lender risk profile values.

In some embodiments the lender data may be used to generate a graphical output to visually represent the lender data.

In some embodiments the lender monitoring module may also output data from other lenders (aggregated and/or anonymised) or results of comparative analysis. For example, to enable a lender to benchmark their performance compared with other lenders in their risk category or industry sector. This may also include calculation of a lender star rating indicative of lender performance. Targeted ROI and Borrower Performance Rewarding

Traditionally good performing bowers have, and are not rewarded for paying loan traditional interest repayments on time except with offers of loan increase either secured or non- secured. An embodiment of the system is configured to enable pairing of borrowers and lenders where a borrower is rewarded for good performance and a lender is able to set a targeted annual return on the loan. In this embodiment a lender sets within the system the annual targeted ROI for the loan (or loans) with a borrower. Once the target ROI is achieved within a 12 period, then the borrower margin is increased for the margin profit share. For example, if the share split is 30% lender and 70% borrower and lender sets for the loan a targeted ROI per annum is 25% for the loan, then within 7 months there are enough transactions that achieve the targeted ROI for the loan, then the system can reduce the lender share of the margin to 5% thereby rewarding good performing borrowers so that the remaining 5 months of the loan the borrower is receiving a margin share split of 95%. The system resets every 12 months to original share split and targeted ROI. In an embodiment the lender and borrower data records include additional data elements to enable setting of the targeted ROI parameters. For example, the additional data elements can include: enable/disable targeted ROI lending flag, target ROI, margin share, margin share adjusted once ROI achieved, time period to achieve target ROI, reset time period, eligibility flag, etc. The enable/disable targeted ROI lending flag can be used to indicate whether or not a borrower or lender is prepared to participate in targeted ROI lending. This is different from an eligibility flag, which is associated with eligibility criteria or rules for qualifying borrowers or lenders to be able to use the targeted ROI lending option, the eligibility criteria for borrowers and lenders may be different. For example, a borrower may be required to have a borrowing history in the system for a defined period of time (for example, 3 months, 5 months, 1 year, 9 months, 24 months etc.), alternatively or additionally a borrower may be required to show a cumulative ROI above a threshold value, this may also be for a given period (for example, ROI of above 15% for 36 months), eligibility criteria may also be based on rankings. Eligibility criteria for a lender may be based on time as lender in the system, loan amount, cumulative loan amount, average ROI etc. In some embodiments lenders may not be required to meet eligibility criteria for targeted ROI lending. If the target ROI is not achieve profit share adjustment to reduce the margin to the lender and increase the margin to the borrower will not occur - the loans between the lender and borrower proceed as a regular loans if the target ROI is not achieved. In some embodiments borrowers may not be required to meet eligibility criteria. It should be appreciated that the eligibility criteria can be configurable and may vary between embodiments. The eligibility criteria may also vary based on industry type.

In some embodiments of the system the borrowers and lenders are required to enable or disable target ROI lending participation. For example, the borrowers and lenders may manually opt-in or opt-out of target ROI lending. Where the borrower or lender opts-in for target ROI lending any eligibility criteria must also be met before matching to target ROI borrowing can occur. The system is configured to monitor the enable/disable opt-in flag and eligibility criteria for target ROI lending for each borrower and lender.

The borrower and lender matching routines in these embodiments of the system are adapted to include filtering/matching based on preference for target ROI lending. During the borrower and lender matching process, the enablement and eligibility for targeted ROI lending can be part of the criteria utilised to identify compatible borrowers and lenders. For example, enablement of ROI targeted lending may be used as to filter potential matches of lenders and borrowers. In some embodiments enablement of target ROI lending may be utilised by the system during automated selection of "preferable" borrower and lender matches or ranking of matches of borrowers to lenders for making load offers.

In an embodiment borrowers and lenders can also nominate target ROI lending parameters - for example setting a range of target ROI loan parameters such as profit margin, loan value, target ROI term etc. that the lender or borrower is seeking. The matching can include assessment by the matching engine of the system to determine whether there is an overlap in target ROI loan preferences for a potential borrower and lender. Where the system identifies there is an overlap in the target ROI loan preferences such matched may be ranked higher in a list of potential matches for which offers may be made. The system may also be configured to determine parameters for a proposed targeted ROI loan agreement based on the borrower and lender preferences. For example, based on the overlap between lender and borrower preferred range for margin split, the system may determine a margin split or margin split range that is assumed to be a mutually agreeable for both borrower and lender for a proposed loan agreement. Similarly, preferences for target ROI period, margin adjustment etc. may also be compared by the system to automatically determine a proposed loan agreement the can be assumed to be mutually agreeable to both lender and borrower.

In an embodiment the system is configured to include target ROI lending parameters in the loan agreement. Where ROI lending parameter has not been pre-specified, the system may be configured to facilitate setting of these parameters during the loan offer and acceptance steps. For example, by presenting a loan offer with target ROI and a questionnaire or set of check boxes or other input fields to use for specifying target ROI parameters, for example target value, agreed profit share adjustment if the ROI is achieved, termination clauses & reset rates. For example, a set of check boxes may allow the lender to nominate the target ROI assessment term, as 12, 24 or 36 months, (alternatively 3 or 6 months could be reasonable in high/rapid turnover industry sectors), the pre ROI target profit margin split may also be input, along with a post ROI target margin split for example using a set of data entry fields, check boxes or sliders. Similar input tool can also be provided for entry of borrower target ROI loan preferences. These input preferences are utilised in combination with other borrower and lender data during borrower and lender matching and can also be used to automatically determine target ROI loan agreement terms.

It should be appreciated that these loan terms may vary between borrowers and may be ranked (for example based on highest ROI) before offer data is transmitted to the lender for approval of the offer and then to the borrower for borrower acceptance of the offer.

It should be appreciated that a target ROI lending agreement between a borrower and lender may apply across a number of different loans. For example, in the car industry to achieve a target ROI of above 20% for a year may require a cumulative assessment of the ROI over a number of sales, for example 5 to 15 car sales. On the conclusion of each sale the ROI for the transaction is checked and a cumulative borrower lender ROI determined by the transaction monitoring and reconciliation module. The cumulative ROI is monitored to determine when the target ROI has been reached within the set time period. The system then automatically adjusts the lender/borrower margin share to provide a lower proportion to the lender and an higher proportion to the borrower. This may also include a notification step to trigger the system to send a notification message (for example text message) to both the lender and borrower to inform the parties of the margin share adjustment. In an embodiment the system is further configured to positively adjust borrower rankings to compensate for potentially negative impact on ratings as a consequence of adjustment of the profit margin share after the target ROI is achieved. For example, a rating based on borrower ROI to investors may be negatively impacted once the profit share to the lender is reduced. Additional functionality is included in the ratings system to identify and

compensate for profit margin adjustments made in accordance with the target ROI being achieved. For example, an embodiment may apply a positive weighting to ROI based ratings calculations post target ROI achievement for a borrower. The adjustment to profit share could otherwise appear negative or change the overall ROI for the borrower compared to others not participating in the target ROI loans.

An advantage of this arrangement is that good performing borrowers can be rewarded by altering the profit share so the borrower retains more of the margin after the lender ROI goal has been achieved. In some embodiments the system can be configured to identify good performing borrowers, and in response to assessment as a "good performing" borrower notify the borrower of the availability of the target ROI loan option. For example, the system may be configured to periodically assess borrower performance against target ROI loan eligibility criteria. Those borrowers who meet or exceed the eligibility criteria can be informed, for example by sending a notification, of their eligibility to participate in Rewards Loans. Notification of eligibility may also include a prompt (such as a link to a preferences entry page) to enter target ROI loan preference data. Some embodiments of the system can be configured to enable a lender, during the course of a loan, to change normal margin share split to a target ROI Reward System loan. This alteration to the loan agreement is triggered by the lender inputting to the system a selection to convert a loan to a target ROI loan. Once selected the system can generate a report showing current loan ROI, the lender may be offered the option to set the current ROI as the target ROI or change the target ROI figure. This can also trigger the system to generate a loan agreement adjustment offer for acceptance by the borrower. For example, some jurisdictions may require a new or formally amended loan agreement to be offered to and accepted by the borrower before any change to the loan conditions (including margin share) can be effected.

Some embodiments may allow a borrower to request of the lender an alteration of the loan agreement to shift loan to a target ROI Rewards loan, for example after a defined period of normal loan share split. Once a normal loan has been selected by the borrower to request converting to a target ROI Rewards loan, the system can retrieve borrower performance data and send a request for loan type conversion to lender, the request can be sent with a borrower performance report and current borrower ratings. The request can also show current lender ROI for the loans between the lender and borrower. The request can also include proposed target ROI and profit margin adjustment data. For example, within this request can be a link to a loan new agreement or loan agreement amendment for the lender to accept or reject. If the lender accepts then the Rewards Loan, then the lender may be offered an option of a date when to set the Rewards loan to start. Alternatively the changed loan conditions may be applied on acceptance or a date specified in the amended loan agreement. Once acceptance is received form the lender, and processed by the system, the system can send notification to borrower to also confirm the new margin split with lender.

If the lender declines borrower request, then a notification is sent to the borrower that their request to shift to Rewards loan has been declined by current lender. The loan with then continue in accordance with the original agreement.

Where a borrower is eligible to participate in target ROI rewards loans but a request for change in lending terms refused by their current lender, they may also be provided with a notification of lenders prepared to participate in target ROI loans, the lenders in the notification may also be filtered buy the based on the requested target ROI loan terms. For example, the system may perform a lender borrower matching based on the borrower's request. The system can then send notification of to the buyer that there are lenders that match the borrower's request for target ROI rewards loans, and on maturity of current loan the borrower can then switch to lenders that are offering to particulate in target ROI Rewards Loans. For example, by requesting target ROI reward loans as a matching criteria when establishing a new loan. Alternatively, the system may be configured to facilitate direct loan requests to the already matched by the system.

Further details of the system

Embodiments of the controller 1 10 of the present invention are implemented in a computer system 900 such as the one schematised in Figure 9. The computer system 900 may be a high performance machine, such as a supercomputer, a server, a desktop workstation or a personal computer, or may be a portable computer such as a laptop or a notebook or may be a distributed computing array or a computer cluster or a networked cluster of computers. The computer system 900 also comprises a suitable operating system and appropriate software for implementation of embodiments of the present invention. The computer system 900 comprises one or more data processing units (CPUs) 902;

memory 904, which may include volatile or non-volatile memory, such as various types of RAM memories, magnetic discs, optical disks and solid state memories; a user interface 906, which may comprise a monitor, keyboard, mouse and/or touch-screen display; a network or other communication interface 908 for communicating with other computers as well as other devices; and one or more communication busses 910 for interconnecting the different parts of the system 900. The computer system 900 may also be connected directly to data mining server equipment 912 to download data.

The computer system 900 may also access data stored in a remote database 914 via network interface 908. Remote database 914 may be a distributed database.

The computer system 900 is configured to communicate with user (borrower and lender) computer equipment via a communication network. The communication may be implemented using client server architecture where a client application is executable on each user device and is configured for secure communication between the client application and server. In an alternative embodiment the computer 900 is used to implement the system functionality and provide a web portal, to allow users to access the system functionality by accessing the web portal via a convention web browser device.

The web portal or application can provide display tools, for example a dashboard to allow login and viewing of summary data for a user (borrower or lender) and tables of loan transaction data.

An example of a Lender Dashboard is shown in Figure 1 1 . The lender dashboard may be configured to display a navigation menu including links to information such as:

• Dashboard or home page

• Re-sale Center

o Home Page

o Search

o Sell

o Buy Now

o Promotion

o Resources

• System information (About Us)

o Support contact information (Contact Us)

o Terms and Conditions

o Affiliate companies or sponsors

o Flagship borrower companies

o Frequently asked question information (FAQ)

• Lender Profile - the lender profile page may allow a lender to update their details, for example address and contact information. The lender may also be able to manually update some data relevant to their risk profile, for example elect different industry sectors, nominate a higher or lower risk category to lend in, adjust profit share or co- lending parameters used for automatic marching of lenders and borrowers for new loan transactions. For example the lender profile page may display data fields for the modifiable risk profile parameters (populated with the lender data stored in the lender database) and enable lenders to input modified data, which is transmitted to the central system controller for storing in the lender data base and in response to the modification of risk profile information recalculation of the lender risk profile.

Stock

o All Stock - providing both history and current loan transaction data

o Current Stock - providing current active loan transactions. This page enables a lender to view progress of all current loan transactions including details of the actual assets/stock purchased using the loan, status of sale progress (for example: in transit, pending advertisement, advertised, under enquiry, under offer, sold, paid, delivered/received etc.)

o Sold Stock - providing details of past loan transaction

Reports - the system can be configured to generate a plurality of reports and the reports may be configured to comply with regulatory reporting requirements, for example for tax office submissions, board financial reports, shareholder reports etc. Other reports may be for internal information. In an embodiment the system may provide a report generator to enable a lender to configure custom reports. For example the report generator may include or allow creation of template report documents with fields defined by the lender for automatic population with lender data by the report generator. Some standard reports may be preconfigured for example:

o Margin Calculation

o Interest Earned Statement

o Statement

o Invoices

o Receipts

o Contingency Report

Borrowers - the system may output data on all the borrowers the lender has engaged in loan transactions with. The system may also be configured to allow lenders to view or search borrowers in the system, for example each borrower may make public (to system users) some borrower profile data, such as borrower prospectus data. Borrower data can include:

o Borrower Listing

o X Borrower - a listing of borrowers the lender has chosen to cease lending to either because of lower than standard performance or lender has caped loan amount to this particular borrower

o Risk Value Report - per borrower or tabulated to provide borrower

comparison data

o Performance Rating - per borrower or tabulated for borrower comparison o Star Rating - per borrower or tabulated for borrower comparison

Loan Documents - for viewing loan transaction agreement generated by the system.

This may also include a page for loan agreements for approval to enable execution and formalization of loan agreements via the system interface. An example of a Borrower Dashboard is shown in Figure 12. Similarly to the lender dashboard, the borrower dashboard may be configured to display a navigation menu including links to information such as:

• Dashboard or home page

• Re-sale Center

o Home Page

o Search

o Sell

o Buy Now

o Promotion

o Resources

• System information (About Us)

o Support contact information (Contact Us)

o Terms and Conditions

o Affiliate companies or sponsors

o Flagship borrower companies

o Frequently asked question information (FAQ)

• Borrower Profile - the borrower profile page may allow a borrower to update their details, for example address and contact information, branding, trading names etc.

• Stock - this can show details of the actual stock items and loan transaction status o All Stock - this page can show all of the transactions for the borrower funder through the system, inclusive current stock and past transaction stock o Current Stock - providing details for current active transactions. This page shows details of current loan transactions and can be updated by the borrower to add new stock for purchasing using loans. The borrower can also update this page with updates to current stock sales, for example entering or updating an advertised price for the stock item, updating sales status information etc. (for example: pending purchase, in transit, pending advertisement, advertised, under enquiry, under offer, sold, paid, delivered/received etc.).

o Removed Stock - where sock has had to be removed, for example for a car a borrower aims to purchase at auction, the loan transaction may be executed in advance. If at the auction the bidding price exceeds the borrower's limit the borrower can withdraw from bidding without purchasing the stock item, in this instance the stock item will need to be removed from the system as not purchased.

o Sale Pending Stock - this is stock currently in a borrower's inventory awaiting sale.

o Sold Stock - recoding sale information including data such as purchase price, advertised price, sale price, turnover time, profit margin and profit margin split.

o Lender Stock - this allows a breakdown of stock by lenders to allow a borrower to view this distribution of lender investments across to borrower portfolio. This can include historical as well as current data.

• Reports/Documents - similarly to for lenders, borrower reports may be generated to comply with regulatory requirements or business reporting needs, the system may enable generation of configurable reports. Some examples of reports include: o Margin Distribution Grid

o Lender Account Reports

o Pages Tracking

o Statement

o Invoices

o Receipts

o Risk Value Report

o Performance Rating

o Star Rating

· Functions

o Parameters (admin manual adjustments to system benchmarking or borrower rating or any adjustable input)

o Emails (system notifications or notification formats )

• Loan Documents - for viewing loan transaction agreement generated by the system.

This may also include a page for loan agreements for approval to enable execution and formalization of loan agreements via the system interface.

• Financial interface to enable input of invoices and payments to the system. This may integrate with a financial institution system or financial transaction service (such as PayPal) to enable financial transactions.

The system can also include a system administration dashboard, an example is shown in Figure 13. Similarly to the lender and borrower dashboards, the system administrator dashboard may be configured to display a navigation menu including links to information that is also editable by the system administrator such as:

· Dashboard or home page

• Re-sale Center

o Home Page

o Search

o Sell

o Buy Now

o Promotion

o Resources

• System information (About Us)

o Support contact information (Contact Us)

o Terms and Conditions

o Affiliate companies or sponsors

o Flagship borrower companies

o Frequently asked question information (FAQ)

• Users - a number of different user type having varying degrees of access can be defined by the system administrator. This section can allow a system administrator to define use types, including access permissions for user types to restrict the data available to users based on user type. The system administrator may also be required to approve new users before access to system data is enabled.

o Administrator Profile

o Add User

o Dealers

o Private Users o Company / Fleet / Government

o Super Admins

o Staff

o Telemarketers

o Lenders

o Accountants

All borrowers and lenders registered in the system can be viewed by the system

administrator and in some embodiments approval by the system administrator is required, support for borrower approval decisions is provided by the system automatically verifying borrower data and risk profiling. In some embodiments the system may be enabled to automatically approve borrowers based on the outcome of risk profiling and the borrower meeting defied allowance criteria, for example based on assessed risk score falling within a defined range, and verification of authenticity and financial security. Functions performed and data viewed and edited by the system administrator can include:

• Borrowers

o Add Borrower

o Edit Borrower

o Borrower Listing

■ (x) Borrower

^■ Risk Value Report

^■ Performance Rating

^■ Star Rating

• Lender

o Add Lender

o Edit Lender

^■ (x) Lender - indicating lender noncompliance or blacklisting. This may be edited by the administrator

^■ Lender ID Docs

■ Agreement Docs

• Suppliers - in an embodiment all suppliers must be accredited with the system in order to supply goods to borrowers and match supplier invoices with the borrowers purchase invoice. It is envisaged that borrower inventory suppliers can be accredited to access the platform. The supplier page can be used to view supplier details including:

o Supplier profile

o (x)Supplier - indicating suppliers who have been reported via the system for non-compliance or other problems, or blacklisted suppliers. The blacklist may be controlled by the system administrator.

o Supplier Stock - enabling viewing of all stock supplied by the supplier under finance from the system and can include invoicing data.

• Stock

o All Stock

o Current Stock

o Sold Stock

• Reports/Documents

o Margin Distribution Grid o Lender Account Reports

o Pages Tracking

o Statement

o Invoices

o Receipts

o Risk Value Report

o Performance Rating

o Star Rating

Functions

o Parameters

o Emails

Loan Documents

A computer system for implementing embodiments of the invention is not limited to the computer system described in the preceding paragraphs. Any computer system architecture may be utilised, such as standalone computers, networked computers, dedicated computing devices, handheld devices or any device capable of receiving processing information in accordance with embodiments of the present invention. The architecture may comprise client/server architecture, or any other architecture. The software for implementing embodiments of the invention may be processed by "cloud" computing architecture.

In an embodiment the system will be HTML Responsive which can create a user friendly experience for the Borrower and the Lender. As part of the System, a Short Message Service (SMS) or Push Notification can be used to alert the Lender when a transaction occurs. Embodiments of the system can also be implemented using a client application that can be compatible with mobile devices, for example version of the client application can be compatible with IOS/Android/Windows/Blackberry.

Embodiments of the system can be configured to implement system processes in a manner compliant with local legislation. For example a version of the system operating in Australia can take into account legislation such as:

Uniform Consumer Credit Code

ATO Guidelines

The Privacy Act including the National Privacy Principles

· The Financial Transaction Reports Act

The Anti-Money Laundering and Counter Terrorism Financing Act

Various Anti-Discrimination Legislation

Trade Practices Act & Australian Securities and Investments Commission Act Australian Financial Services License

· Australian Registered Scheme

In an embodiment the System can include a Financial Institution Transaction Account that will act as the method of financial transactions between Lenders and Borrowers and the System and Performance Users. This Transactional Account can be held with a traditional financial institution. The system can be implemented with a financial system interaction controller and communication interface configured to enable secure machine to machine (M2M) communication between the system and financial institution. The system may also implement an API (application program interface) to allow third party financial transactions. For example, the API may allow third parties to input payments for asset purchases directly to the system via electronic funds transfer (EFT) or credit/debit card and the API. This API may also allow borrowers and lenders to input funds to the trust via the client application or web portal.

Embodiments of the system may also be configured to facilitate administration of

• Secured loans

• Unsecured loans

• Peer-to-Peer lending

• Demand Loans - Demand loans are short term loans that are typically in that they do not have fixed dates for repayment and carry a floating interest rate which varies according to the prime lending rate. They can be "called" for repayment by the lending institution at any time. Demand loans may be unsecured or secured.

• Prospectus Based Asset Lending (Capital raising)

It will be understood to persons skilled in the art of the invention that many modifications may be made without departing from the spirit and scope of the invention.

In the claims which follow and in the preceding description of the invention, except where the context requires otherwise due to express language or necessary implication, the word "comprise" or variations such as "comprises" or "comprising" is used in an inclusive sense, i.e. to specify the presence of the stated features but not to preclude the presence or addition of further features in various embodiments of the invention.

It is to be understood that, if any prior art publication is referred to herein, such reference does not constitute an admission that the publication forms a part of the common general knowledge in the art, in Australia or any other country.

Claims

1 . A lending system implemented using computer system processing and memory resources accessible by borrowers and lenders via a communication network from borrower and lender computer systems, the lending system comprising:

2. A lending system as claimed in claim 1 further comprising a profit sharing engine configured to apply profit sharing rules to calculate return shares to borrowers and lenders during reconciliation of a loan transaction.

3. A lending system as claimed in claim 1 or claim 2 wherein the borrower profiling module is further configured to receive monitored transaction data from the transaction monitoring and reconciliation module on conclusion of a transaction wherein one or more lenders loan funds to a borrower, analyse the transaction data and adjust the borrower risk profile based on the outcome of the transaction.

4. A lending system as claimed in claim 3 wherein analysing the transaction data includes comparing the transaction data with previous transaction data for the borrower retrieved from the borrower data record.

5. A lending system as claimed in claim 4 wherein analysing transaction data includes identification of statistical outlier transactions for the borrower.

6. A lending system as claimed in any one of claims 3 to 5 wherein analysing the transaction data includes comparing the transaction data with industry transaction data for an industry sector relevant to the transaction.

7. A lending system as claimed in any one of claims 3 to 6 wherein, adjusting the borrower risk profile incudes calculating a borrower star score for benchmarking borrowers.

8. A lending system as claimed in any one of the preceding claims wherein the matching engine is configured to match borrowers and lenders for a transaction based on: a borrower risk profile for the borrower requesting the transaction,

an asset type for the transaction,

asset purchase price for the transaction, and

lender risk tolerance profiles for a plurality of lenders.

9. A lending system as claimed in claim 8 wherein the matching is performed by the matching engine:

10. A lending system as claimed in claim 8 wherein the matching is performed by the matching engine:

1 1 . A lending system as claimed in claim 9 or claim 10 wherein the matching engine is further configured to control a transaction offer and acceptance process, wherein at least one lender is selected from the final candidate set and transaction data transmitted to the at least one lender via the communication network for output of offer data to the one or more lenders and in response to an input being received indicating acceptance of the transaction by the one or more lenders, cause the transaction monitoring and reconciliation module to formalise the loan.

12. A lending system as claimed in any one of the preceding claims, further configured to facilitate target return in investment (ROI) reward loans, wherein for one or more loans between a lender and borrower an agreement is made for profit sharing to be adjusted in favour of the borrower once a target ROI has been achieved for a defined period, and wherein the transaction monitoring and reconciliation module is configured to monitor the cumulative ROI for the one or more loans between the lender and borrower and

automatically adjust profit sharing parameters in accordance with the agreement and applying the adjusted profit sharing parameters for ongoing loan reconciliation for the borrower and lender for the remainder of the defined period.

13. A lending method implemented in a lending system using computer system processing and memory resources accessible by borrowers and lenders via a

communication network from borrower and lender computer systems, the lending method comprising the steps of:

interacting, by the a transaction monitoring and reconciliation module of the lending system, with a finance interface to effect transfer of funds.

14. A lending method as claimed in claim 13 wherein the step of determining one or more candidate borrowers or lenders includes the steps of:

where the loan requestor is a borrower:

and

where the loan requestor is a lender:

15. A lending method as claimed in claim 14 wherein the step of identifying one or more candidate lenders is based on:

a borrower risk profile for the borrower requesting the transaction,

an asset type for the transaction,

asset purchase price for the transaction, and

lender risk tolerance profiles for a plurality of lenders.

16. A lending method as claimed in claim 15 wherein the step of identifying one or more candidate lenders performed by the matching engine comprises the steps of:

17. A lending method as claimed in claim 15 wherein the step of identifying one or more candidate lenders performed by the matching engine comprises the steps of:

18. A lending method as claimed in claim 16 or claim 17 wherein the matching engine further controls a transaction offer and acceptance process comprising the steps of:

selecting at least one lender from the final candidate set;

transmitting transaction data to the at least one lender via the communication network for output of offer data to the one or more lenders; and

19. A lending method as claimed in claim 14 wherein the step of identifying one or more candidate borrowers is based on:

a lender risk tolerance profile for the lender requesting the transaction,

an asset type for the transaction,

loan amount, and

borrower risk profiles for a plurality of borrowers.

20. A lending method as claimed in claim 19 wherein the step of identifying one or more candidate borrowers performed by the matching engine comprises the steps of:

21 . A lending method as claimed in claim 19 wherein the step of identifying one or more candidate borrowers performed by the matching engine comprises the steps of:

22. A lending method as claimed in any one of claims 13 to 21 further comprising an initial step for each lender of setting up a lender user account in the lending system, including the steps of:

receiving lender data; and analysing the lender data, by a lender profiling module of the lending system, to determine risk tolerance profile and lending preference data for the lender.

23. A lending method as claimed in any one of claims 13 to 22 further comprising an initial step for each borrower of setting up a borrower user account in the lending system, including the steps of:

receiving borrower data; and

24. A lending method as claimed in any one of claims 13 to 23 wherein performing reconciliation includes the step of a profit sharing engine of the lending system applying profit sharing rules to calculate return shares to borrowers and lenders.

25. A lending method as claimed in any one of claims 13 to 24 further comprising the steps of:

receiving monitored transaction data from the transaction monitoring and reconciliation module on conclusion of a transaction wherein one or more lenders loan funds to a borrower;

analysing the transaction data by a borrower profiling module; and

adjusting the borrower risk profile based on the outcome of the transaction.

26. A lending method as claimed in claim 25 wherein analysing the transaction data includes comparing the transaction data with previous transaction data for the borrower retrieved from a borrower data record.

27. A lending method as claimed in claim 26 wherein analysing transaction data includes identification of statistical outlier transactions for the borrower.

28. A lending method as claimed in any one of claims 25 to 27 wherein analysing the transaction data includes comparing the transaction data with industry transaction data for an industry sector relevant to the transaction.

29. A lending method as claimed in any one of claims 25 to 28 wherein, adjusting the borrower risk profile incudes calculating a borrower star score for benchmarking borrowers.

30. A lending method as claimed in any one of claims 13 to 29, further comprising facilitating target return in investment (ROI) reward loans wherein for one or more loans between a lender and borrower an agreement is made for profit sharing to be adjusted in favour of the borrower once a target ROI has been achieved for a defined period, wherein the method further comprises the steps of:

monitoring, by the transaction monitoring and reconciliation module, the cumulative ROI for the one or more loans between the lender and borrower; and