AU2013100866C4 - Computer implemented methods and frameworks for processing transaction data thereby to enable a loan determination process - Google Patents

Abstract

The present invention relates to computer implemented methods and frameworks for processing transaction data thereby to enable a loan determination process. Embodiments of the invention have been particularly developed for enabling automated loan determination based upon electronic banking records. One embodiment provides a computer-implemented for processing transaction data thereby to enable a loan determination process, the method including: obtaining account data, wherein the account data includes a plurality of sets of transaction data; for one or more of the sets of transaction data, identifying a portion of data predicted to be representative of a transaction payee/payer; for each identified portion of data predicted to be representative of a transaction payee/payer, comparing the portion of data to one or more external information directories, thereby to seek to identify a known payee/payer from the one or more external directories; and in the case that a known payee/payer is found for a given set of transaction data, extracting one or more characteristics of that payee/payer, and associating the one or more characteristics with the set of transaction data.

Description

1 COMPUTER IMPLEMENTED METHODS AND FRAMEWORKS FOR PROCESSING TRANSACTION DATA THEREBY TO ENABLE A LOAN DETERMINATION PROCESS FIELD OF THE INVENTION [0001] The present invention relates to computer implemented methods and frameworks for processing transaction data thereby to enable a loan determination process. Embodiments of the invention have been particularly developed for enabling automated loan determination based upon electronic banking records. While some embodiments will be described herein with particular reference to that application, it will be appreciated that the invention is not limited to such a field of use, and is applicable in broader contexts. BACKGROUND [0002] Any discussion of the background art throughout the specification should in no way be considered as an admission that such art is widely known or forms part of common general knowledge in the field. [0003] In the context of the financial services industry, there are various short-term loan products. An example of such a product is a commonly referred to as a "payday loan", being a loan for a relatively small amount which is granted to a customer for a short period, typically on the basis that funds to repay the loan will become available due to expected periodic income SUMMARY OF THE INVENTION [0004] It is an object of the present invention to overcome or ameliorate at least one of the disadvantages of the prior art, or to provide a useful alternative. [0005] One embodiment provides a kiosk terminal configured to dispense loan funds, the terminal including: [0006] a display screen configured to present a user interface; 2 [0007] one or more input modules configured to enable a user of the terminal to interact with the user interface; [0008] a communications module configured to enable communication with at least one remote server device; [0009] a processor configured to execute software instructions, thereby to configure the terminal to: [0010] (i) present the user interface; [0011] (ii) enable a user to input personal information; and [0012] (iii) enable performance of a loan determination and authorisation process; and [0013] (iv) subject to the loan determination and authorisation process, determine a loan value to be dispensed; [0014] an output device configured to output a physical substrate having transactable value corresponding to the loan value. [0015] One embodiment provides a kiosk terminal 1 wherein the output device is configured to dispense a prepaid debit card having a transactable value corresponding to the loan value. [0016] One embodiment provides a kiosk terminal wherein the personal information includes the user's personal electronic banking information, thereby to enable the loan determination and authorisation process to extract and process transactional information in relation to the user's personal bank account. [0017] One embodiment provides a server device configured to interact with a plurality of terminals as described herein, wherein the server device is configured to execute at least a portion of the loan determination and authorisation process. [0018] One embodiment provides a server device wherein the server device is additionally configured to interact with a browser-rendered interface displayed at a client 3 device other than one of the terminals according to any one of claims 1 to 3, thereby to enable a performance of a second loan determination and authorisation process in respect of a user of the browser rendered interface. [0019] One embodiment provides a computer-implemented for processing transaction data thereby to enable a loan determination process, the method including: [0020] obtaining account data, wherein the account data includes a plurality of sets of transaction data; [0021] for one or more of the sets of transaction data, identifying a portion of data predicted to be representative of a transaction payee/payer; [0022] for each identified portion of data predicted to be representative of a transaction payee/payer, comparing the portion of data to one or more external information directories, thereby to seek to identify a known payee/payer from the one or more external directories; and [0023] in the case that a known payee/payer is found for a given set of transaction data, determining from the external information directory in which the known payer/payee is found one or more characteristics of that payee/payer, and associating the one or more characteristics with the set of transaction data. [0024] One embodiment provides a method wherein the portion of data predicted to be representative of a transaction payee/payer is identified from a transaction description by a process of elimination. [0025] One embodiment provides a method wherein the process of elimination includes identifying and extracting one or more of the following from the transaction description: [0026] a location, based on a list of known location names; [0027] a payment type, based on a list of known payment type names; [0028] a date/time, based on a list of known date/time formats.

4 One embodiment provides a method wherein the one or more characteristics assist in identification of similar transactions. [0029] One embodiment provides a computer program product for performing a method as described herein. [0030] One embodiment provides a non-transitive carrier medium for carrying computer executable code that, when executed on a processor, causes the processor to perform a method as described herein. [0031] One embodiment provides a system configured for performing a method as described herein. [0032] Reference throughout this specification to "one embodiment", "some embodiments" or "an embodiment" means that a particular feature, structure or characteristic described in connection with the embodiment is included in at least one embodiment of the present invention. Thus, appearances of the phrases "in one embodiment", "in some embodiments" or "in an embodiment" in various places throughout this specification are not necessarily all referring to the same embodiment, but may. Furthermore, the particular features, structures or characteristics may be combined in any suitable manner, as would be apparent to one of ordinary skill in the art from this disclosure, in one or more embodiments. [0033] As used herein, unless otherwise specified the use of the ordinal adjectives "first", "second", "third", etc., to describe a common object, merely indicate that different instances of like objects are being referred to, and are not intended to imply that the objects so described must be in a given sequence, either temporally, spatially, in ranking, or in any other manner. [0034] In the claims below and the description herein, any one of the terms comprising, comprised of or which comprises is an open term that means including at least the elements/features that follow, but not excluding others. Thus, the term comprising, when used in the claims, should not be interpreted as being limitative to the means or elements or steps listed thereafter. For example, the scope of the expression a device comprising A and B should not be limited to devices consisting only of elements A and B. Any one of the terms including or which includes or that includes as used herein is also an open term 5 that also means including at least the elements/features that follow the term, but not excluding others. Thus, including is synonymous with and means comprising. [0035] As used herein, the term "exemplary" is used in the sense of providing examples, as opposed to indicating quality. That is, an "exemplary embodiment" is an embodiment provided as an example, as opposed to necessarily being an embodiment of exemplary quality. [0036] A used herein, the term "kiosk terminal" is used to describe a self-contained hardware unit including a computing device, and one or more input/output devices coupled to the computing device. The computing device is configured to operate in a "locked-out" state thereby exclusively execute a core software application that provides user interface and access to a predefined set of functionalities (for example an automated teller machine, ticket vending machine, and the like). This is differentiated from a general purpose terminal, such as a personal computer, tablet, smartphone or the like, which operates in an open state whereby multiple software applications may be launched from a core operating system. BRIEF DESCRIPTION OF THE DRAWINGS [0037] Embodiments of the invention will now be described, by way of example only, with reference to the accompanying drawings in which: [0038] FIG. 1A schematically illustrates a framework according to one embodiment. [0039] FIG. 1 B schematically illustrates a framework according to one embodiment. [0040] FIG. 1C schematically illustrates a framework according to one embodiment. [0041] FIG. 2A illustrates a method according to one embodiment. [0042] FIG. 2B illustrates a method according to one embodiment. [0043] FIG. 3 illustrates a client-server framework according to one embodiment.

6 DETAILED DESCRIPTION [0044] Described herein is a kiosk terminal configured to dispense loan funds, and methods for operating and supporting such a kiosk terminal. Embodiments of the invention have been particularly developed for providing a kiosk device that is configured to interact with a user thereby to make a determination as to whether or not a loan is to be granted, and to dispense that loan in a transactable form (for example as cash, or in the form of a prepaid debit card). [0045] In overview, a plurality of kiosks are installed and activated in distributed locations. A user interacts with one of these terminals to obtain a short term loan (for example a "payday loan"), or to access other functionalities provided by the terminal. In the context of obtaining a short term loan, the user supplies various aspects of personal information, and the kiosk performs a loan determination and authorisation process (which typically includes interaction with one or more remote server devices). For example, based on analysis of historical banking transaction information for the user, the kiosk offers to the user a loan of a determined quantum based on a set of loan conditions. In the case that the user agrees to those conditions, the kiosk is configured to dispense the loan, for example either in cash form, or in the form of a prepaid debit card. The kiosk may provide additional functionalities, including payment of bills via known payment services (such as BPAY, Paypal, or vendor-specific means), where some or all of the payment us funded via a short-term loan. [0046] As used herein, the term "loan" refers to a loan of monetary value that is granted to a user, based on an agreement whereby the user will repay the loan (with a defined premium) on designated terms. For example, a loan of $X is granted on date A on the basis that the user will pay $(X+Y) to the granter on date B. Preferably the repayment is achieved by way of an automated direct debit using an electronic banking system. [0047] One embodiment provides a kiosk terminal configured to dispense loan funds. The terminal includes a display screen configured to present a user interface, one or more input modules configured to enable a user of the terminal to interact with the user interface (for example buttons, a keyboard, a touchscreen, and so on), and a communications module configured to enable communication with at least one remote server device. The terminal includes a processor configured to execute software instructions, thereby to configure the terminal to present the user interface, enable a user 7 to input personal information, enable performance of a loan determination and authorisation process. Subject to the loan determination and authorisation process, the terminal determines a loan value to be dispensed. An output device is configured to output a physical substrate having transactable value corresponding to the loan value. For example, this may be a prepaid debit card having a transactable value corresponding to the loan value. In other embodiments the terminal is otherwise or additionally to dispense other forms of substrate having transactable values, such as legal tender currency, vouchers, and so on. Exemplary Kiosk Terminal and Framework [0048] FIG. 1A illustrates an exemplary framework including a loan dispensing kiosk 100, and a plurality of further kiosks 100' (which may be either identical of substantially identical to kiosk 100). A kiosk management server 130 communicates with kiosks 100 and 100', for example via the Internet (or other communication means, such as wide area networks or the like). [0049] Kiosk 100 is a freestanding unit, defined by a body (illustrated as a cabinet-style body) that securely contains electrical components. Key components include a microprocessor 101 coupled to a memory module 102 and communications module 103. In this manner, kiosk 100 includes core computing components that enable the execution of software instructions (which may be stored in whole or in part on memory module 102) and functional interaction with server 130. Various computer executed methods performed based on the execution of software instructions (i.e. computer executable code) by kiosk 100 are discussed further below. [0050] Kiosk 100 additionally includes a display screen 110, which is configured to display a user interface with which a human user 120 is able to interact. User input components 112 facilitate such interaction. Components 112 may include the likes of a touch-based interface (optionally overlaid on screen 111), keyboards, trackpads/trackballs, buttons, microphones, and the like. In some embodiments kiosk 115 additionally includes a camera component 115 positioned to capture image data of user 120, and other inputs 114, which may include the likes of card readers (NFC, magnetic, smartcards, etc), biometric inputs, and so on.

8 [0051] Kiosk 100 includes one or more dispensing components 113, being components configured to dispense substrates that provide transactable value (i.e. a form of value that is able to be exchanged for goods and/or services). Preferably, dispensing components 113 include (solely or in combination with other dispensing components) an output configured to dispense a prepaid debit card (for example a card issued by a issuing authority such as Visa). This is a card which carries a defined quantum of value, and in some cases may be recharged with additional value (for example by way of interaction with a system provided by the card issuing authority, or in some embodiments via interaction with kiosk 100 or another device in communication with server 130). [0052] The relationship between kiosk 100 and kiosk 130 varies between embodiments. For example, there are a range of which may be provided by kiosk 100, by server 130, or by a combination of kiosk 100 and server 130. In broad terms, this may depend on a degree of "thin client" relationship that is used. For instance: * At one extreme, kiosk 100 provides a thin user interface that simply receives and presents data, with all substantive computing decisions and processing occurring at server 103. * At another extreme, server 130 is substantially or wholly unnecessary, with all substantive computing decisions and processing occurring at kiosk 100. [0053] It will be appreciated that which of these, or the point of compromise between these two extremes, that is selected for a given embodiment is a subjective issue of implementation. The embodiments of FIG. 1 B and 1C provide additional guidance in that regard. FIG. 1 B illustrates an embodiment where the kiosks operate without a need for management server 130. In the example of FIG. 1C, server 130 is configured to interact with a first form of user interface provided by the kiosks, and also a second form of user interface accessed by a computing device 150 having a web browser, which is also operated by human user 120. [0054] Kiosk 100 and kiosks 100' interact with a plurality of third party servers 140, either via kiosk management server 130 (as shown in FIG. 1A) or directly (as shown in FIG. 1 B). Optionally, the communication is direct for some third party servers, and via server 130 for others. Four exemplary third party servers are illustrated: 9 " An exemplary banking server 141. This is a server that allows for electronic banking at a given financial institution (or, in some cases, for multiple financial institutions). Interaction with server 141 is primarily to enable access to historical banking records for user 120, thereby to assist in a loan determination and authorisation process, as discussed in more detail further below. Additionally, this interaction may additionally be used to facilitate direct funds transfer to user 120's bank account (for example by instructing a payment/banking system associated with kiosk 100 or server 130 to perform an electronic funds transfer), and/or to facilitate direct debit from user 120's bank account to make a payment to a bank account associated with kiosk 100 or server 130 (for example as automated repayment of a loan). * An exemplary data handling server 142. For example in some cases an intermediary server, such as server 142, is used to streamline interaction with a plurality of further servers. For example, in some embodiments a service such as Yodlee is used, this providing a data handling server 142 which provides streamlined with access to data from a plurality of banking servers such as server 141. * An exemplary payment service server 143, for example BPAY, Paypal or the like, which allows configuration of Kiosk 130 to make payments via such a service. For example, in some embodiments Kiosk 100 enables user 120 to pay an invoice via payment service server 130 using a variety of payment means, including direct debit from a banking account, loan funds approved via Kiosk 100, and/or payment cards provided to Kiosk 100. * An exemplary card issuer server 144. For example, interaction with server 144 may be used to provide information of issued prepaid debit cards and/or loading of those cards, card activation, and so on. [0055] It will be appreciated that these are a selection of exemplary servers only, and that in further embodiments other third party servers may be present. [0056] Various functionalities provided via components shown in FIG. 1A, FIG. 1B and/or FIG. 10 are discussed further below.

10 Exemplary User Loan Procurement Process [0057] FIG. 2A illustrates an exemplary loan procurement process 200. This method is a computer-implemented, being performed performed based on the execution of software instructions. Each of the various functional blocks illustrated in FIG. 2 may be performed based on execution of software instructions by kiosk 100, server 130, or a combination of kiosk 100 and server 130, depending on client-server implementation decisions for particular embodiments. It will further be appreciated that the ordering of steps may be modified to provide further embodiments, and that not all steps need be present in all embodiments and/or iterations of the method. [0058] Functional block 201 represents a login/registration process. For example, in some embodiments users of the framework register, and have respective user accounts maintained by server 130. This allows a returning user to quickly and conveniently self identify, for example using means such as identification cards, username/password combinations, and/or biometric data. The registration process typically commences with the provision of one or more aspects of personal information, and completes with the assignment of an account ID (which identifies the user account for the purposes of kiosk 100 and server 130). In some cases the registration process commences at functional block 201, and is completed at a later stage. [0059] Functional block 202 represents a process including procuring electronic banking information for user 200 (if that information is not already held by server 130), or identifying that information (for example if the user has previously registered and submitted that information). This information is used to access the user's personal electronic banking records, for example via a communications process between server 130 and a banking server 141, or using a service such as Yodlee. In this regard, there are known and established technologies that enable a computer process to access banking details for a user via electronic banking interfaces based on the user providing login details (such as an Internet banking username and password combination, along with details of the banking institution). [0060] Functional block 203 represents a process including accessing user 120's electronic banking records. This typically provides access to aspects of the user's personal information (such as name, address, date of birth, etc) and to historical transactional details. In terms of the former, various personal details may be extracted at 11 204, thereby to pre-populate various fields in a loan agreement form (see block 207). However, in other embodiments personal information is procured by alternate means (for example by direct user input, or by extracted from a user's identification document that is provided for reading by kiosk 100). [0061] Functional block 205 represents a process including analysing historical transaction data from the user's electronic banking data. This allows for the making of loan determinations at 206. The manner by which tis occurs varies between embodiments, and some examples are provided further below. For instance, in some embodiments transaction data is analysed to identify patterns, for example to determine whether the user receives a regular income, the timing of that income, and the quantum of that income. Expenditure patterns may also be analysed, for example regular payments. This is used to determine whether a short term loan is to be authorised, and if so, determine a quantum (or maximum quantum) of loan to be authorised. [0062] Functional block 207 represents a process including providing a loan agreement for approval. Preferably the loan includes predefined generic text portions, and instance specific fields that are auto-populated based on information inputted by the user and/or details determined from the user's electric banking data, and data defined at functional block 206 (for example a quantum of loan, quantum of repayment, and time of repayment). In some embodiments the loan agreement includes a direct debit authorisation, which permits a direct debit from the user's bank account at a specified time for a defined amount (thereby to repay or partially repay the relevant loan). [0063] Functional block 108 represents a process whereby the loan is approved. This preferably includes an interaction from user 120, for example provision of a signature, checking of various "approve" boxes, and so on. [0064] Once the loan is approved, the user is able to obtain the funds. In some implementations the user is provided with various options in respect of how the funds are to be obtained. One example is the provision of a prepaid debit card, as represented by functional block 209. In this regard, kiosk 100 preferably maintains a repository of prepaid debit cards ready for dispensing. In some cases the cards are pre-associated with defined values. In other cases the cards are associated with values at the time of dispensing by providing a signal to the card issuing authority with a card unique identifier and a desired card value (with that value subsequently being obtained by the card issuing 12 authority from the party responsible for granting loans via the kiosk). In both cases, there may be a step whereby kiosk 100 or server 130 provides a card activation signal to the card issuing authority, thereby to cause activation of the card (so that is can be used for payment as a debit card in the conventional manner). [0065] Functional block 210 represents a process whereby funds are dispensed/used in other ways. Examples include: * Dispensing cash. * Dispensing a voucher that is redeemable for cash, goods and/or services at one or more prescribed locations. * Transferring funds to a designated bank account. * Reloading an existing debit card. * Enabling the payment of a bill. For example, in some embodiments a user is able to input details of a bill, for example a utility bill, that is payable via means identified on the bill (which may include BPAY or the like). Via process 200, or a similar process, a user may request funds to pay (or partially pay) a bill. The bill details may be inputted manually, or in some cases the bill is scanned, a barcode read, or the like. In some cases partial payment is made via other means, including credit/debit card, direct debit from a bank account, and so on. [0066] It will be appreciated that variations may be made to method 200 of FIG. 2 without deviating from the general underlying concepts and functionalities, and that such variations are considered to remain embodiments of the technology disclosed herein. Exemplary Loan Determination and Authorisation Process [0067] As noted above, kiosk 100 is configured to enable performance of a loan determination and authorisation process (for example by providing relevant input data to server 130). Subject to the loan determination and authorisation process, a loan value is determined. In some cases this is a maximum loan value, and the user may select a lesser value.

13 [0068] The nature of the loan determination and authorisation process varies between embodiments, and a specific example is illustrated in FIG. 2B (discussed further below). In broad terms, various embodiments of the technology disclosed herein make use of the one or more of following functionalities in the context of loan determination and approval processes: * Accessing a user's personal banking historical transaction data (via an Internet banking portal, optionally via a third party intermediate such as Yodlee). * Processing the historical transaction data thereby to identify income and expenses. * Processing the historical transaction data thereby to identify patterns in income, thereby to identify regular income sources. For example, a regular income course may be categorised by a value (or average value) and a payment timeframe (for example weekly, monthly, etc). * Processing the historical transaction data thereby to identify patterns in expenses. [0069] In some embodiments historical transaction data is processed thereby to determine, for a given identified expense, a category for that expense. For example, in some embodiments this includes identifying a payee name from the transaction data, and cross-checking that name against one or more third party directories which categorise business types, thereby to determine a business type for the payee. For example, a payee identified in the transaction data as "COMPANY X" may be identified as a petrol station in a third party directory, and hence the transaction might be predicatively assigned to a category of "fuel and transportation". [0070] FIG. 2 illustrates an exemplary method 220. It will be appreciated that, n other embodiments, various steps from this method may be re-ordered, modified, replaced, or the like, without affecting the overall purpose and functionality. [0071] Functional block 221 represents a process including obtaining transaction data from a user's bank account, for example using a service such as Yodlee, or another interface configured to obtain such data. This yields a set of data, which is processed thereby to allow loan determination/authorisation.

14 [0072] In terms of processing the obtained data, functional block 222 represents a data separation process. This enables extraction of meaningful data from a transaction description. For example, the description is separated to identify, for each transaction, the date and time, method of payment, description, suburb, description, second party (payee/payor), and so on. The separated values are stored in a local database according to a predefined schema thereby to facilitate the execution of local data processing algorithms. [0073] In some embodiments the separation process includes: * Identifying location data comparing the description to a database of known locations (for example defined in terms of suburbs). If a portion of the description matches a suburb in the database, it is extracted from description, and stored into a "location" field in a local data table for the transaction. * Identifying date and time using a database of date and time formats. For example, if a portion of the description is determined to be in a known date/time format from the database, the portion is extracted and the date/time stored in the local database. Preferably the date/time data is normalised into a local standard format. * Identifying a transaction type such as from a database listing all known transaction payment types (such as credit cards, Eftpos, DirectDebit etc). This is preferably also stored locally. * Identifying one or more other common aspects of data which, like those above, can be identified from a finite list of possibilities. * Determining that the remaining data is indicative of a payee/payer for the transaction. [0074] The remaining data is then used for a payee/payer identification process at 223. For example, in some embodiments the remaining data is cross-checked against one or more third party directories thereby to seek identification of the payee/payer, and where identification is possible, obtain additional information regarding the payee/payer. This additional information is used to determine additional transaction characteristics. For example, the transaction may be allocated a to one of a set of predefined transaction 15 purposes, such as petrol, groceries, food/beverage, gambling, etc (or an "unknown" category). [0075] Functional block 224 represents a transaction grouping process. For example, transactions may be grouped by whether they are income or expenses, by payee/payer, transaction purpose, and so on. From this, similar transactions are identified at 226, for example using a similarity algorithm. Similarity may be assessed by any attribute, for example payee/payer, amount, purpose, etc. [0076] For each set of similar transactions, frequency analysis is performed at functional block 226. For example, a set of similar transactions may be categorised as daily, weekly, fortnightly, and so on. A start date (and in some cases an end date) are also identified. For example, this may be used to identify a regular income (for instance a weekly income of $X which has been occurring for Y months). [0077] Functional block 227 represents an averaging/pattern analysis process. For example, this may be used to determine an averaged relationship between income and expenses. By way of example, FIG. 4 shows an exemplary output from such a process based on a sample set of data (albeit a simplified example). According to this bank statement data, the customer spends average of $400.00 per week. His income is on average $950 per fortnight. Customer has been receiving his income since 01/03/2013 (so he has been employed for a period of approx. 4 month). [0078] Functional block 228 represents a loan risk management algorithm, which is not disclosed in detail for the present purposes. In overview, a given loan provider will have individual preferences and risk policies for granting loans. These are defined in algorithmic form for the purposes functional block 228, with inputs from data defined in previous method steps (for example averaged income/expenses, patterns, etc). A determination (for example defined in terms of a maximum authorised loan amount) is provided at 229. Exemplary Client-Server Framework [0079] In some embodiments, methods and functionalities considered herein are implemented by way of a client-server framework, as illustrated in FIG. 3. In overview, a web server 302 provides a web interface 303. This web interface is accessed by the parties by way of client terminals 304. In overview, users access interface 303 over the 16 Internet by way of client terminals 304, which in various embodiments include the likes of personal computers, PDAs, cellular telephones, gaming consoles, and other Internet enabled devices. [0080] Server 303 includes a processor 305 coupled to a memory module 306 and a communications interface 307, such as an Internet connection, modem, Ethernet port, wireless network card, serial port, or the like. In other embodiments distributed resources are used. For example, in one embodiment server 302 includes a plurality of distributed servers having respective storage, processing and communications resources. Memory module 306 includes software instructions 308, which are executable on processor 305. [0081] Server 302 is coupled to a database 310. In further embodiments the database leverages memory module 306. [0082] In some embodiments web interface 303 includes a website. The term "website" should be read broadly to cover substantially any source of information accessible over the Internet or another communications network (such as WAN, LAN or WLAN) via a browser application running on a client terminal. In some embodiments, a website is a source of information made available by a server and accessible over the Internet by a web-browser application running on a client terminal. The web-browser application downloads code, such as HTML code, from the server. This code is executable through the web-browser on the client terminal for providing a graphical and often interactive representation of the website on the client terminal. By way of the web browser application, a user of the client terminal is able to navigate between and throughout various web pages provided by the website, and access various functionalities that are provided. [0083] Although some embodiments make use of a website/browser-based implementation, in other embodiments proprietary software methods are implemented as an alternative. For example, in such embodiments client terminals 304 maintain software instructions for a computer program product that essentially provides access to a portal via which framework 100 is accessed (for instance via an Phone app or the like). [0084] In general terms, each terminal 304 includes a processor 311 coupled to a memory module 313 and a communications interface 312, such as an internet connection, modem, Ethernet port, serial port, or the like. Memory module 313 includes software 17 instructions 314, which are executable on processor 311. These software instructions allow terminal 304 to execute a software application, such as a proprietary application or web browser application and thereby render on-screen a user interface and allow communication with server 302. This user interface allows for the creation, viewing and administration of profiles, access to the internal communications interface, and various other functionalities. Conclusions and Interpretation [0085] Unless specifically stated otherwise, as apparent from the following discussions, it is appreciated that throughout the specification discussions utilizing terms such as "processing," "computing," "calculating," "determining", analyzing" or the like, refer to the action and/or processes of a computer or computing system, or similar electronic computing device, that manipulate and/or transform data represented as physical, such as electronic, quantities into other data similarly represented as physical quantities. [0086] In a similar manner, the term "processor" may refer to any device or portion of a device that processes electronic data, e.g., from registers and/or memory to transform that electronic data into other electronic data that, e.g., may be stored in registers and/or memory. A "computer" or a "computing machine" or a "computing platform" may include one or more processors. [0087] The methodologies described herein are, in one embodiment, performable by one or more processors that accept computer-readable (also called machine-readable) code containing a set of instructions that when executed by one or more of the processors carry out at least one of the methods described herein. Any processor capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken are included. Thus, one example is a typical processing system that includes one or more processors. Each processor may include one or more of a CPU, a graphics processing unit, and a programmable DSP unit. The processing system further may include a memory subsystem including main RAM and/or a static RAM, and/or ROM. A bus subsystem may be included for communicating between the components. The processing system further may be a distributed processing system with processors coupled by a network. If the processing system requires a display, such a display may be included, e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT) display. If manual data entry is required, the processing system also includes an input device such as one or 18 more of an alphanumeric input unit such as a keyboard, a pointing control device such as a mouse, and so forth. The term memory unit as used herein, if clear from the context and unless explicitly stated otherwise, also encompasses a storage system such as a disk drive unit. The processing system in some configurations may include a sound output device, and a network interface device. The memory subsystem thus includes a computer-readable carrier medium that carries computer-readable code (e.g., software) including a set of instructions to cause performing, when executed by one or more processors, one of more of the methods described herein. Note that when the method includes several elements, e.g., several steps, no ordering of such elements is implied, unless specifically stated. The software may reside in the hard disk, or may also reside, completely or at least partially, within the RAM and/or within the processor during execution thereof by the computer system. Thus, the memory and the processor also constitute computer-readable carrier medium carrying computer-readable code. [0088] Furthermore, a computer-readable carrier medium may form, or be included in a computer program product. [0089] In alternative embodiments, the one or more processors operate as a standalone device or may be connected, e.g., networked to other processor(s), in a networked deployment, the one or more processors may operate in the capacity of a server or a user machine in server-user network environment, or as a peer machine in a peer-to-peer or distributed network environment. The one or more processors may form a personal computer (PC), a tablet PC, a set-top box (STB), a Personal Digital Assistant (PDA), a cellular telephone, a web appliance, a network router, switch or bridge, or any machine capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken by that machine. [0090] Note that while diagrams only show a single processor and a single memory that carries the computer-readable code, those in the art will understand that many of the components described above are included, but not explicitly shown or described in order not to obscure the inventive aspect. For example, while only a single machine is illustrated, the term "machine" shall also be taken to include any collection of machines that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein.

19 [0091] Thus, one embodiment of each of the methods described herein is in the form of a computer-readable carrier medium carrying a set of instructions, e.g., a computer program that is for execution on one or more processors, e.g., one or more processors that are part of web server arrangement. Thus, as will be appreciated by those skilled in the art, embodiments of the present invention may be embodied as a method, an apparatus such as a special purpose apparatus, an apparatus such as a data processing system, or a computer-readable carrier medium, e.g., a computer program product. The computer-readable carrier medium carries computer readable code including a set of instructions that when executed on one or more processors cause the processor or processors to implement a method. Accordingly, aspects of the present invention may take the form of a method, an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present invention may take the form of carrier medium (e.g., a computer program product on a computer-readable storage medium) carrying computer-readable program code embodied in the medium. [0092] The software may further be transmitted or received over a network via a network interface device. While the carrier medium is shown in an exemplary embodiment to be a single medium, the term "carrier medium" should be taken to include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) that store the one or more sets of instructions. The term "carrier medium" shall also be taken to include any medium that is capable of storing, encoding or carrying a set of instructions for execution by one or more of the processors and that cause the one or more processors to perform any one or more of the methodologies of the present invention. A carrier medium may take many forms, including but not limited to, non-volatile media, volatile media, and transmission media. Non-volatile media includes, for example, optical, magnetic disks, and magneto-optical disks. Volatile media includes dynamic memory, such as main memory. Transmission media includes coaxial cables, copper wire and fiber optics, including the wires that comprise a bus subsystem. Transmission media also may also take the form of acoustic or light waves, such as those generated during radio wave and infrared data communications. For example, the term "carrier medium" shall accordingly be taken to included, but not be limited to, solid-state memories, a computer product embodied in optical and magnetic media; a medium bearing a propagated signal detectable by at least one processor of one or more processors and representing a set of instructions that, when executed, implement a method; and a transmission medium in a network bearing a 20 propagated signal detectable by at least one processor of the one or more processors and representing the set of instructions. [0093] It will be understood that the steps of methods discussed are performed in one embodiment by an appropriate processor (or processors) of a processing (i.e., computer) system executing instructions (computer-readable code) stored in storage. It will also be understood that the invention is not limited to any particular implementation or programming technique and that the invention may be implemented using any appropriate techniques for implementing the functionality described herein. The invention is not limited to any particular programming language or operating system. [0094] It should be appreciated that in the above description of exemplary embodiments of the invention, various features of the invention are sometimes grouped together in a single embodiment, FIG., or description thereof for the purpose of streamlining the disclosure and aiding in the understanding of one or more of the various inventive aspects. This method of disclosure, however, is not to be interpreted as reflecting an intention that the claimed invention requires more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive aspects lie in less than all features of a single foregoing disclosed embodiment. Thus, the claims following the Detailed Description are hereby expressly incorporated into this Detailed Description, with each claim standing on its own as a separate embodiment of this invention. [0095] Furthermore, while some embodiments described herein include some but not other features included in other embodiments, combinations of features of different embodiments are meant to be within the scope of the invention, and form different embodiments, as would be understood by those skilled in the art. For example, in the following claims, any of the claimed embodiments can be used in any combination. [0096] Furthermore, some of the embodiments are described herein as a method or combination of elements of a method that can be implemented by a processor of a computer system or by other means of carrying out the function. Thus, a processor with the necessary instructions for carrying out such a method or element of a method forms a means for carrying out the method or element of a method. Furthermore, an element described herein of an apparatus embodiment is an example of a means for carrying out the function performed by the element for the purpose of carrying out the invention.

21 [0097] In the description provided herein, numerous specific details are set forth. However, it is understood that embodiments of the invention may be practiced without these specific details. In other instances, well-known methods, structures and techniques have not been shown in detail in order not to obscure an understanding of this description. [0098] Similarly, it is to be noticed that the term coupled, when used in the claims, should not be interpreted as being limited to direct connections only. The terms "coupled" and "connected," along with their derivatives, may be used. It should be understood that these terms are not intended as synonyms for each other. Thus, the scope of the expression a device A coupled to a device B should not be limited to devices or systems wherein an output of device A is directly connected to an input of device B. It means that there exists a path between an output of A and an input of B which may be a path including other devices or means. "Coupled" may mean that two or more elements are either in direct physical or electrical contact, or that two or more elements are not in direct contact with each other but yet still co-operate or interact with each other. [0099] Thus, while there has been described what are believed to be the preferred embodiments of the invention, those skilled in the art will recognize that other and further modifications may be made thereto without departing from the spirit of the invention, and it is intended to claim all such changes and modifications as falling within the scope of the invention. For example, any formulas given above are merely representative of procedures that may be used. Functionality may be added or deleted from the block diagrams and operations may be interchanged among functional blocks. Steps may be added or deleted to methods described within the scope of the present invention.

Claims (5)

1. A computer-implemented method for processing transaction data thereby to enable a loan determination process, the method including: obtaining account data, wherein the account data includes a plurality of sets of transaction data; for one or more of the sets of transaction data, identifying a portion of data predicted to be representative of a transaction payee/payer; for each identified portion of data predicted to be representative of a transaction payee/payer, comparing the portion of data to one or more external information directories, thereby to seek to identify a known payee/payer from the one or more external directories: and in the case that a known payee/payer is found for a given set of transaction data, determining from the external information directory in which the known payer/payee is found one or more characteristics of that payee/payer, and associating the one or more characteristics with the set of transaction data.

2. A method according to claim 1 wherein the portion of data predicted to be representative of a transaction payee/payer is identified from a transaction description by a process of elimination.

3. A method according to claim 2 wherein the process of elimination includes identifying and extracting one or more of the following from the transaction description: a location, based on a list of known location names; a payment type, based on a list of known payment type names; a date/time, based on a list of known date/time formats.

4. A method according to any preceding claim wherein the one or more characteristics assist in identification of similar transactions.

5. A method according to claim 1 including identifying similar transactions, determining frequency information for the similar transactions, and performing 23 averaging analysis thereby to determine average periodic income/expenditure information.