WO2017088020A1

WO2017088020A1 - An apparatus and method for facilitating account management

Info

Publication number: WO2017088020A1
Application number: PCT/AU2016/051149
Authority: WO
Inventors: Andrew Robert CLOUSTON; Jurgen JOARDER
Original assignee: Mogo Holdings Pty Ltd
Current assignee: Mogo Holdings Pty Ltd
Priority date: 2015-11-23
Filing date: 2016-11-23
Publication date: 2017-06-01
Anticipated expiration: 2018-05-23
Also published as: GB201810045D0; CA3005354A1; GB2561114A; AU2016361456A1

Abstract

The present invention relates to an apparatus and method for facilitating account management. An apparatus is provided which facilitates transfer of financial account information between different financial institutions, and enables the efficient analysis of financial account information. If a customer wishes to close an account and transfer account information from one financial institution to another, this can be very cumbersome and difficult to do. For example, they may have a lot of payee and biller information relating to direct debit that they will need to manually transfer from one financial institution to the other. This discourages people from transferring accounts. The present invention utilises automated systems, in the form Agent Systems to automatically navigate the computing system of a financial institution, obtain the requisite information and transfer it to another financial institution system. This results in the efficient processing of account transfers. The apparatus and method also enable the automated analysis of account information. For example, account information can be analysed to determine the credit wordiness of an account holder.

Description

AN APPARATUS AND METHOD FOR FACILITATING ACCOUNT

MANAGEMENT

Field of the Invention

The present invention relates to an apparatus and method for facilitating account management, and particularly, but not exclusively, to an apparatus and method for facilitating transfer of financial accounts between institutions, and analysis of financial account information. Background of the Invention

There are disincentives for customers to open new accounts with financial institutions such as banks. For example, if they wish to close an account with a previous financial institution(s) (Fl), and open an account at a new institution, they may have to manually transfer a significant amount of account processing related information. For example, they may have a number of standing direct debit instructions for regular payments to payees. They may also have account

information stored at their current Fl, for payees that they make other regular payments to that may not be direct debits. For example, they may store BPay™ account information for payees that they regularly transfer funds to. All this information may be stored at a network site of their current Fl.

To open an account with a new Fl, currently this information must be manually re-entered into a computing system of the new Fl to facilitate setting up an account site for the customer. For example, they may need to manually export and enter all payee details, for direct 35 debits, other payee information and any other biller information, into the new Fl system in a repository opened for the new account. In addition, a customer may have direct debit authorities which may have been issued to third parties to deduct funds from their account. Information on these direct debit authorities may not be stored in a place accessible via an Fl system or via online banking.

The requirement for manual input leads to a disincentive to open new accounts with other Fls. Even where a new account is opened, a customer may make mistakes in transferring the payee data and other data that may be required. Also, if there are large amounts of billers, it is extremely time consuming and complex for a user to go through each and every biller.

Another problem relating to account management for customers, relates to credit checking processes, and, particularly to an assessment of whether a customer can afford to be extended credit, for example. A number of jurisdictions (including Australia and the UK), now require financial institutions to undertake an "affordability" assessment before providing a customer with credit.

Current affordability assessments are time consuming and mainly manual.

Summary of Invention

In accordance with a first aspect, the present invention provides an apparatus for facilitating account management, comprising a computing system having a processor, a memory and an operating system supporting computer processes, a data access process arranged to access a first computer system hosting financial data of a customer, to locate customer credit information data, and to extract the customer credit transfer data. In an embodiment, the data access process is arranged to transport the credit information data to a further computing system hosting a financial account of a customer. In an embodiment, the data access process is controlled via a customer computer, so that the customer credit information data is transferred under control of the customer computer. In an embodiment, where the credit information data is transferred to a further computing system, the transfer is controlled via the customer computer and not via any other third party computing system. The computing system or any other computing system (apart from the further computing system hosting the customer financial account) therefore may not have access to the customer credit information data.

In an embodiment, the customer credit information data comprises payee data, relating to payees of the customer. The payee data may comprise identity details of payee financial accounts, for example, enabling payments to be made to them. In an embodiment, the payee data is relocated at a customer account hosted at the further computing system. This advantageously facilitates a customer transferring accounts from one financial institution to another, for example. Where the data access process is under control of the customer computer, this facilitates security of the data being transferred. In some embodiments (see below) access to transaction data may be given (in this embodiment) to another computer system for analysis. No security access details are given to third party computer systems, in order to comply with the requirements of financial institutions. The payee data may be biller data, data about regular payments that the customer makes (e.g. BPay™), or any other payee related data.

In an embodiment, the customer credit information data includes transaction data relating to financial transactions of a customer, and the apparatus comprises a transaction data analysis process arranged to analyse the transaction data to identify payee data. In this embodiment, the transaction date analysis process may analyse outgoing and incoming payment information from a customer account, and identify payees, such as billers, that may need to be notified in the new customer account (at the further computing system). The analysis process may identify data relating to direct debit authorities, which otherwise would not be easily identified. This may enable the new Fl to identify billers and contact them or list them so the customer can contact them. For the analysis of the transaction data, another computing system apart from the customer computing system may be given access to the transaction data to analyse it. For example, a host computing system may host the transaction data analysis process.

In an embodiment, the transaction data analysis process is arranged to analyse the transaction data to determine income data and expense data. This analysis may enable an assessment to be made of a customer's credit worthiness. This could facilitate a determination process, for example, to determine whether a loan should be made to a customer, or other credit be made available to a customer.

In accordance with a second aspect, the present invention provides a method of facilitating account management, comprising the steps of, via a computing system, automatically accessing a first computing system hosting financial data of a customer, locating customer credit information data, and extracting the customer credit information data. In an embodiment, the method comprises the step of downloading a data access process to a customer computing device. The data access process is arranged to implement the automatic accessing of the first computing system and locating and extraction of customer credit transfer data. In an embodiment, the customer computing device is in control of the process of locating the customer credit transfer data via the data access process.

In an embodiment, the method comprises the further step of transporting the credit information data to a further computing system hosting a financial account of the customer. In an embodiment, the step of transporting is automated. In an embodiment, the step of transporting is implemented by the data access process.

In accordance with a third aspect, the present invention provides a computer program, comprising instructions for controlling a computer to implement an apparatus in accordance with the first aspect of the invention.

In accordance with a fourth aspect, the present invention provides a computer readable medium, providing a computer program in accordance with the third aspect of the invention.

In accordance with a fifth aspect, the present invention provides a data signal, comprising a computer program in accordance with the third aspect of the invention. In accordance with a sixth aspect, the present invention provides an apparatus for facilitating account management and credit control, comprising a computing system having a processor, a memory and an operating system supporting computer processes, a transaction data analysis process arranged to receive customer transaction data for a customer account hosted at a financial institution computing system, and being arranged to analyse the transaction data to determine income data and expense data.

In an embodiment, the analysis of income and expense data can facilitate a determination of the credit worthiness of a customer, and whether they can afford to be provided with credit, such as a loan.

In an embodiment, the transaction data analysis may be carried out in accordance with regulations, relating to "affordability verification".

In an embodiment, the transaction data analysis can be used to determine whether a customer is experiencing "hardship" in paying back credit. Many loan providers will allow a customer to defer or reduce payments on an existing loan or credit obligation if they are bona fide experiencing financial hardship. A transaction analysis in accordance with this embodiment can assist in demonstrating financial hardship.

In accordance with a seventh aspect, the present invention provides a method of facilitating account management and credit analysis, comprising the steps of accessing customer transaction data at a computing system hosting a financial account of a customer, and automatically analysing the transaction data to determine income data and expense data. In an embodiment, the step of automatically analysing is implemented by a transaction data analysis process via a computing device.

In accordance with an eighth aspect, the present invention provides a computer program, comprising instructions for controlling a computer to implement an apparatus in accordance with the sixth aspect of the invention.

In accordance with a ninth aspect, the present invention provides a computer readable medium, providing a computer program in accordance with the eighth aspect of the invention.

In accordance with a tenth aspect, the present invention provides a data signal, comprising a computer program in accordance with the eighth aspect of the invention.

Brief description of the Figures

Features and advantages of the present invention will become apparent from the following description of embodiments thereof, by way of example only, with reference to the accompanying drawings, in which:

Figure 1 is a schematic block diagram illustrating an apparatus in accordance with an embodiment of the invention;

Figure 2 is a schematic block diagram of a computing system which may be utilised by an embodiment of the present invention;

Figure 3 is a flow diagram of a process in accordance with an embodiment of the present invention, for transferring payee data from a financial institution computing system to a further financial institution computing system; Figure 4 is a diagram illustrating a transaction data analysis process in accordance with an embodiment of the present invention;

Figures 5 to 10 are representations of displays which may be provided on a customer computing device, in accordance with an embodiment of the present invention; and

Figures 1 1 to 17 are representations of displays which may be utilised by a reviewer in a post-processing process relating to analysis of transaction data, in accordance with an embodiment of the present invention. Detailed Description of embodiments of the invention

Referring to Figure 1 an apparatus in accordance with an embodiment of the present invention is generally designated by reference numeral 1 . In this

embodiment, the apparatus 1 comprises a "host" computing system which supports computer processes. The computer processes include a data access process 2.

Figure 1 also illustrates a number of other computing systems which may communicate with each other via a wide area network (WAN) 3 such as the Internet.

The computing systems include financial institution computing systems 4. These may be computing systems associated with any financial institution, such as a bank.

The computing systems are used to support computer processes and implement databases and customer financial accounts, customer records, and the like. Such systems are known.

Computing systems also comprise other Fl computing systems 5, in this drawing marked "RECIPIENT". These computing systems 5 also may be associated with financial institutions such as banks. They also implement computer processes that facilitate customer's financial accounts, databases and customer account records. They may be similar in functionality to the Fl systems 4. They are marked RECIPIENT as, in this embodiment, they are intended as computing systems to be used to open new accounts for a customer and receive customer credit information data, in accordance with an embodiment of the invention.

Also illustrated in Figure 1 are customer computing devices 6. These may comprise any type of computing apparatus or system, such as mobile devices, PCs, laptops, or any other type of computing device. These are used by customers to access the Fl systems 4 and 5 and also to interact with the computing apparatus 1 and data access process 2.

In this example, the data access process is arranged to access computing systems 4 to locate customer credit information data. The data access process 2 is arranged to transport the credit information data to the recipient Fl system 5. This can facilitate opening of a new customer account in the Fl system 5.

In Figure 1 , three Fl systems 4 and two recipient Fl systems 5 are shown. It will be appreciated that there may be less or more than this. Similarly, although only three customer computing systems are shown, there may be less or more. The host system 1 may be implemented as a separate system or may be incorporated in an Fl system 5.

Figure 2 is an example block diagram of a computing system which may be utilised in implementation of the present invention. For example, it may be utilised in the embodiment of Figure 1 as the host system Fl system and/or customer computer.

The illustrated computing system comprises a computer which includes a processor 12 and memory 13. The processor 12 is arranged to process programme instructions and data in a known manner. Memory 13 is arranged to store programme instructions and data also in a known manner. Processor 12 may constitute one or more processing means, such as integrated circuit processors. The memory 13 may comprise any known memory architecture and may include hard disk, IC memory (ROM, PROM, RAM, etc.), floppy disks and other types of additional memory such as CD ROM, and any other type of memory.

A BUS 14 is provided for communication between the processor 12 and memory 13 and also communication with external components. In this case the external components include a user interface 15. The user interface 15 includes a visual display unit 16 for displaying information to a user. The VDU 16 may display information in graphical format or any other format depending upon the programme instructions being processed by processor 12.

The user interface 15 also includes user input means 17 which in this example include a keyboard 18 (which in this example may be a standard QWERTY keyboard) and a mouse 19. The mouse 19 may be used to manipulate a graphical user interface (GUI) if a GUI is provided by software running on the computer. A network connection 1 1 is also provided for connecting to a network which may include a communication network 3 and other computers/computing systems.

The computing system of Figure 2 may be implemented by any known type of computing hardware such as, for example, a PC, by a number of networked PCs if required to implement a system of this embodiment, by a "mainframe architecture" including a remote computer and user workstations connected to the remote computer, by a client-server architecture, including a client computer accessing a server computer over a network, or by any other computing architecture. Parts of the system or the entirety of the system may be housed in the "cloud". This embodiment of the present invention is implemented by appropriate software providing instructions for operation of the computing system hardware to implement the apparatus of the embodiment and implement the method of the embodiment.

Part of the system or the entire computer system may be portable, and may be implemented, for example, by a laptop or tablet computer, smartphone or other portable device.

The computing system is provided with an operating system and various computer processes to implement functionality. The computer processes may be implemented as separate modules, which may share common foundations such as routines and sub-routines. The computer processes may be implemented in any suitable way and are not limited to separate modules. Any software/hardware architecture that implements the functionality may be utilised. The computing system 10 may be implemented as a server computing system, or utilising computer resources in the cloud, or any other computer resources. In this embodiment, the host system 1 is implemented utilising cloud resources.

As discussed above, one of the issues with a customer transferring from one financial institution to the other, is the difficulty in transporting useful transaction data that the user may wish to use with their new account at the new financial institution. For example, the customer's previous financial account at the previous Fl may include data relating to payees, billers and transactions that the customer would wish to transition to any new account at a new Fl. For example, payee or biller account identity data is very useful 5 in enabling a customer to implement payments from their account to another account. Currently, transitioning of such transaction data is mainly carried out manually. This is a disincentive to customers transferring accounts from one Fl to another Fl, for example.

In the current embodiment, as illustrated in Figure 1 , a customer computing device 6 is able to open an account with a new Fl (RECIPIENT) 5. This may be done by using the usual procedures of the Fl. The customer computer comprises an operating system 7 supporting applications 8. One of the applications includes a browser 9 which may access webpages served by Fl system 5. The customer device 6 may navigate the webpages of the Fl system 5 and be guided to enter details to open an account.

Alternatively, an account may already exist at the new Fl, and a customer may wish to add details, such as details of payees. This could be done manually by the customer operating their computing device 6 and filling in fields on webpages served by the recipient Fl system 5. This is very time consuming and error-prone.

In the current embodiment, however, this transfer is carried out by a data access process 2 which is provided by the host system 1 .

In this embodiment, the customer computing device 6 downloads the data access process 2 by accessing the host system 1 .

In order to access the current 5 Fl system 4 of the customer to obtain the payee data, there are a several issues that must be addressed:

• The Fl systems 4 require a customer to be identified for access. A user is usually required to enter a password, which may be any token, biometric or any other type of password.

• Fl systems implement strict security policies, including implementation of firewalls, to prevent unauthorised access by, for example, unauthorised software. In this embodiment, the data access process 2 comprises, or is able to obtain, agent processes 20. These are illustrated as A1 , A2 and A3 in Figure 1 . In this embodiment, the data access process agents include instructions enabling them to navigate the Fl systems to locate credit information data.

A further issue in accessing systems of financial institutions, is that there are strict requirements that the customer data may only be accessed by the customer, and not any third party system. Access by third party systems can lead to

guarantees maintained by the Fl systems being dropped. The customer themselves could then become liable for any breaches of their information or errors in their account.

In order to address these issues, in this embodiment, the data access process 2 and agents 20 are downloaded to the customer device 6 and they are operated via the customer device. No third party system is therefore involved in obtaining the customer credit information data and transporting it to the recipient Fl system 5.

The agents 20 operate on behalf of the customer 6 to implement access to the Fl system 4 (either prompting the user to input their password, 5 biometric or other identifier or doing so on their behalf).

A suitable agent may be the type of agent disclosed in Australian Patent No. 2002232973 (eWise Systems Pty Ltd). The disclosure of this document is

incorporated herein by reference.

In Figure 1 , only three agents are shown. It will be appreciated that there may be as many agents as required for as many Fl systems that are to be accessed in accordance with this embodiment of the invention. A customer will use the

appropriate agent configured for their Fl system. The agent is configured with a set of instructions to enable it to navigate the particular Fl system. The agent will also be configured to access the recipient Fl system 5 to load the customer credit transfer data appropriately.

In more detail, referring to Figure 3 and Figures 5 through 10, a process of opening an account at a recipient Fl system 5, or using a currently existing account at a recipient Fl system 5, and obtaining customer credit information data and transporting it to the recipient Fl system 5, will now be described.

At step 1 a customer, via their customer device 6, accesses web pages served by recipient Fl system 5 to open a new account or access an already established account.

Figure 5 shows a representation of a "page" that might be served to a customer computing device 6. In the prior art, as discussed above, a customer wishing to transfer payees, billers and other data to the new account at recipient Fl system would need to do this manually. In this embodiment, the page served by 5 the recipient Fl system 5 gives the option to "transfer payees" 30. See step 2 in Figure 3. The customer, via their customer device 6, selects "transfer payees" 30.

The recipient Fl system may then serve a page (Figure 6) that asks the client to select the Fl from which data is to be obtained. See reference numeral 31 . The customer is given a choice of financial institutions to select.

At step 3, the customer, via their customer device 6 selects an Fl destination. A page is then served (Figure 7) which asks the customer to download the data access process 2. This can be done by way of a GUI button 32 on the screen of a customer device, on the page served by the recipient Fl system 5. The data access process 2 is in the form of a "plug in" in this embodiment that can be obtained by a customer device 6. It may also be in the form of an "App" that can be downloaded to the customer device. For example, it may be in the form of a smartphone App.

At step 4, the customer downloads the data access process by actuating button 32. The customer computer 6 is automatically linked to the host system 1 which maintains the data access process 2 and agents 20. The host system 1 uploads the data access process 2 to the customer device 6. It also uploads the appropriate agent (e.g. A1 , A2 or A3) 20 for the Fl system (1 , 2, 3) selected by the customer.

In this embodiment, the agent automatically accesses the requisite Fl system 4 and establishes a secure connection. See Figure 8.

In this embodiment, fields 35 and 36 are provided for the customer to enter their user name and password. The agent transmits these details to the Fl system 4 to enable access to the customer account data. See step 5, Figure 3. The password may alternatively comprise a second factor, such as a token, SMS, or any other identifier.

Note that the user identifier (password, biometric or some token) will not be seen by the recipient Fl system and will not be stored anywhere.

The agent then navigates the customer account site and locates the customer credit data. Step 6 of Figure 3.

The agent is a piece of encrypted and securely signed code that is specifically tailored and customised for each supported financial institution. If the Agent is incorrectly signed or not signed, it will be rejected by the data access process 2.

The agent has site awareness and knows how a financial institution's site is constructed, such as what does the login page looks like, what fields need to be filled out on the login page, what information needs to be submitted on the page in order to successfully login

With respect to payee & biller data, the Agent therein navigates to the financial institution's address book and retrieves all data related to payees and billers.

Each supported site may organise payees and billers differently such as more modern systems may provide a summary page with all details such as BSB, account number, biller code and biller reference whereas other older sites may only provide a list whereby the Agent then needs to navigate and expand all payee and billers in order to extract these details.

The Agent must be able to extract all required information in order for the payees and billers to be successfully setup within a new system.

The Agent must also take into consideration PCI-DSS compliance whereby a biller reference may be a credit card number therein may need to be additionally encrypted (if required) using an integrator's public key to ensure only the integrator can decrypt with his private key. The agent can effectively mimic what a human user would do in accessing the Fl site and extract information, only it can do it much more efficiently. It also does not need all the information and all the operation that human user might need. For example, it does not need to upload graphical information.

In this embodiment, the customer device 6 is presented with a page via the data access process as shown in Figure 9 and can select which "account" the data is to be taken from (reference numeral 40). On selection of the account, the agent navigates the site and obtains the appropriate data. Some analysis of the data may be required to filter the data to obtain the appropriate payee data (step 7). The data is transported to the recipient system 5 (step 8). Note that step 7 and 8 may be done in a different order than shown. Transaction data 30 may be analysed by the host system 50 1 , by analysis process 50 (see later). For example, the host system 1 may analyse transaction data to identify regular direct debits and other regular payments. The transaction may also be analysed for affordability purposes (see later).

In this embodiment, the data access process 2 may obtain an analysis process 50 which can analyse the customer credit transfer data to identify the relevant payee data. This analysis process may be carried out on the host system 1 or the analysis process may be hosted by the Fl system 5 and carried out there.

Figure 10 is a screen showing some payee data displayed on the customer device. The customer can select (reference numeral 45) which data they wish to be entered into the new account at the recipient Fl system 5. The new customer account is loaded with payee data (step 9). The financial institution (recipient) then automatically or through some other process sets up all the relevant payees/billers and notifies the user when ready.

As well as the agent identifying payee data and the customer identifying payee data, the analysis process 50 may involve reviewing transactions that the customer has undertaken to identify any direct debits or any other biller data, set up against the previous account and these may be highlighted to the user. They may also be loaded as payee data into the new account.

Once the process is complete the customer will notify the relevant billers to change any direct debits or other billing processes to the new account. Alternatively, the Recipient Fl may notify the relevant billers on behalf of the customer.

The analysis process 50 may also or alternatively be arranged to implement an analysis to determine income data and expense data of the customer. This can be used to prepare an "affordability report" to see whether the user can be provided with credit, for example. Many jurisdictions nowadays (including the UK and

Australia) require lenders (such as financial institutions) to carry out an affordability analysis before making loans to customers. Should they not comply with these requirements, the Fl can be liable for any loan default, for example.

Analysis may also be used to determine whether a customer is experiencing any financial hardship. This can enable an Fl to provide some relief from payments, for example.

This analysis across a number of customers can be very useful for financial institutions to gauge the health of their credit facilities with various customers, and to ensure that the Fl will be in no danger of receiving a number of defaults.

In this embodiment, the analysis process 50 can carry out an analysis to determine income data and expense data and provide an affordability report.

In this embodiment, the analysis process 50 comprises a categorise engine which automatically categorises transactions based around a group of conditions termed rules.

The analysis process categorises income and expenditure. It supports rules for income and spending and once categorised, recurring transactions are summarised and also grouped by section rules.

The data may be obtained via the agent and the Fl system of a customer's account, as with the embodiment discussed above. The analysis process is not limited to this, however, and the data may be obtained from anywhere. In other embodiments, customer transaction data may be provided (with customer permission) from any Fl system to the host system for analysis in this manner.

The categorisation engine is unique in the way it categorises data specifically designed to identify the key elements required to facilitate legislated "Responsible Lending". It does not require the customer to label and identify transactions.

Categorisation is done independently by the categorisation 5 engine.

Examples of categories that may be used are:

Income

Salary

Government payments (pension, Centrelink, family payment etc.) Spending

Rent

Mortgage

Groceries

Entertainment

Travel

Examples of sections (or buckets) are:

Discretionary spending

Basic living

Red flag

Eating out

Referring to Figure 4, the transactions are obtained from customer accounts (as discussed above) or from any other source. The steps in the process are then:

1 . Transactions are passed from database to Categorisation Engine ("CAT")

100.

2. CAT verifies data and reads in rules.

• 3. Each transaction is then processed using these steps (any match updates categorisation and rule details for transaction)Attempt a match against conditional rules (based around amounts and pattern matching) • Attempt a match against reference lists for "eating out" (e.g. cafes, fast food outlets, restaurants)

• Attempt a match against regular expressions note this check will also attempt match using merchant and transaction codes where available

• Attempt fuzzy string match which allows more than one categorisation to match. If there are multiple matches then weighting rules apply to determine which category to use. (Fuzzy string match could use one of the following known methods or a newly developed system if required). a. Soundex - a phonetic based algorithm which may not be suited to a textual descriptions

b. Levenshtein distance - measure the difference between two strings

c. Agrep - approximate string matching Weighting process. Where multiple categories match a transaction a weighting system will evaluate which category to use. The weighting system can use details available from the transaction and also from the spending/income patterns of that consumer.

4. Any unmatched items update a word and phrase bank that store

unmatched details. Occurrences of unmatched data are also accumulated.

5. Uncategorised data is categorised with defaults for income and spending.

6. A post-processing process with specific rules that require knowledge on other transaction is implemented. E.g. a car loan should have a recurring regular amount so this cannot just be identified in one transaction. Expert knowledge is utilised in the post-processing process to identify such transactions. 7. All data is now categorised and can be summarised. Descriptions are pattern masked so that reference numbers, dates, etc. are masked to allow for recurring item checks.

8. Occurrences, frequency patterns, monthly averages and monthly totals are calculated.

9. Section rules are applied and categorised data is conditionally checked and allocated to sections such as basic living, discretionary living, review items etc. To create rules, data needs to be constantly analysed to identify patterns with descriptions together with amounts that might indicate a transaction should be allocated to a specific category.

When existing processes and rules are run, a post-processing process (see Figure 4) is implemented. A "review page" forms part of the solution whereby an uncategorised description is displayed on a special page of a dashboard. The page is "smart" in that it goes out to a network e.g. the Internet and search engines, other sources to try and determine what business the description refers to and what the business does. The reviewer can then quickly create a rule once this is known. A background process analyses unmatched data extracting Pty Ltd names, payee names etc. API calls will be made using this data to: ABN web service, Sensis web service (White and Yellow Pages). The information retrieved will be added to the unmatched review data. When the reviewer reviews unmatched this data is displayed. From the review page, the reviewer can then highlight any of the data displayed and do a script based Google lookup to get more details. For example:

1 . Background process extracts ABC Pty Ltd from a transaction description.

2. Web service call to ABN returns trading name of ABC RANDWICK 2034 NSW. 3. Reviewer confirms current trading details with Google lookup to confirm that ABC RANDWICK is a Dry Cleaner.

Figure 1 1 shows unmatched recurring strings sorted by frequency of various stages of review. It has filtering built in.

Referring to Figure 12, a row is selected and the box of Figure 12 is displayed. The transaction is now tagged as being reviewed by me so other reviewers cannot look at it and do not waste time looking at the same transaction as me. It has an automatically found and extracted company name "Devon River Pty Ltd" out of the description field. The system then automatically does an ABN lookup from ASIC as well as Yellow Pages lookup to determine the ANZSIC code and category for that business.

After clicking on the Occurs field the screen of Figure 13 is displayed. This displays the actual transaction details for these recurring strings (the system automatically knows how to work this out). I.e. this shows the amounts which can then be used in the rules logic.

Clicking on the magnifying glass in the Figure 3 screen brings up a direct lookup of the company on the ASIC site automatically (Figure 14).

Figure 15 shows Yellow Pages lookup. Other lookups can be added.

The reviewer can make suggestions based on known reference lists or suggested category. The reviewer can also put a comment in to describe why they made the particular suggestion (Figure 16). The reviewer manager reviews the suggestions and then either accepts or disputes the suggestion. The rule writer, only looks at the accepted suggestions to create or update rules.

There is an ability to then click a test button to test the rules. The Figure 17 test shows that the Rule No. 27 will categorise this transaction as Furniture, Appliances, Computer. The rules are designed to be able to produce different categorisation outputs depending on the Fl requirements.

Data is parsed and reports are generated to show items categorised and also uncategorised so that existing rules can be checked and/or amended.

A dashboard generated by the system will contain word and phrase bank reviews to identify data that is not categorised. Items with high numbers will trigger email alerts to data reviewers who will then analyse uncategorised data so that rules can be created.

In the above embodiment, the apparatus comprises computer devices (which may be virtual servers in the cloud) and various software modules running on the servers to implement the processes described above. Embodiments of the invention are not limited to servers and in other embodiments may be implemented by a variety of hardware and software architecture. General purpose computers may be programmed to implement the apparatus and method. Any architecture could be implemented, including client server architecture, central processing unit/terminal architecture, or any other architecture. The system may be implemented utilising mobile devices, such as tablet computers and laptop computers, or dedicated bespoke architecture. Software may be used to program processors to implement embodiments to the invention. Programmable hardware may be used to implement embodiments, such as field programmable gate arrays, programmable gate arrays and other hardware.

Where software is used to implement the invention, the software can be provided on computer readable media, such as discs, or as data signals over networks, such as the internet, or in any other way. It will be appreciated by persons skilled in the art that numerous variations and/or modifications may be made to the invention as shown in the specific embodiments without departing from the spirit or scope of the invention as broadly described. The present embodiments are, therefore, to be considered in all respects as illustrative and not restrictive.

Claims

1 . An apparatus for facilitating account management, comprising a computing system having a processor, a memory and an operating system supporting computer processes, a data access process arranged to access a first computer system hosting financial data of a customer, to locate customer credit information data, and to extract the customer credit information data.

2. An apparatus in accordance with claim 1 , wherein the data access process is arranged to transport the credit information data to a further computing system hosting financial data of the customer.

3. An apparatus in accordance with claim 1 or claim 2, wherein the credit information data comprises payee data, relating to payees of a customer, whereby payee data can be relocated at a customer account hosted at the further computing system.

4. An apparatus in accordance with claim 3, wherein the customer credit information data comprises transaction data relating to financial transactions of the customer, and the apparatus comprises a transaction data analysis process arranged to analyse the transaction data to locate and identify payee data.

5. An apparatus in accordance with claim 3 or claim 4, wherein the payee data is located at a payee data location(s) and the data access process comprises a navigation process arranged to navigate the first computing system to this location(s).

6. An apparatus in accordance with any one of the preceding claims, comprising an agent process arranged to implement the data access process, and able to navigate to the first computing system and further computing system.

7. An apparatus in accordance with claim 6, wherein the agent process comprises security access means, enabling it to access the first computing system.

8. An apparatus in accordance with claim 1 , wherein the customer credit information data is transaction data, and the apparatus comprises a transaction data analysis process arranged to analyse the transaction data to determine income data and expense data.

9. An apparatus in accordance with any one of the preceding claims, wherein the first computing system is a computing system associated with a financial services provider of the customer.

10. A computer program comprising instructions for controlling a computer to implement an apparatus in accordance with any one of the proceeding Claims.

1 1 . A computer readable medium providing a computer program in accordance with Claim 10.

12. A data signal, comprising a computer program in accordance with Claim 10.

13. A method of facilitating account management, comprising the steps of, via a computing system, automatically accessing a first computing system hosting financial data of a customer, locating customer credit information data, and extracting the customer credit information data.

14. A method in accordance with Claim 12 or Claim 13, comprising the further step of transporting the credit information data to a further computing system hosting a financial account of the customer.

15. An apparatus for facilitating account management and credit control, comprising a computing system having a processor, a memory and an operating system supporting computer processes, a transaction data analysis process arranged to receive customer transaction data for a customer account hosted at a financial institution computing system, and being arranged to analyse the transaction data to determine income data and expense data.

16. A method of facilitating account management and credit analysis, comprising the steps of obtaining customer transaction data from a computing system hosting a financial account of a customer, implementing, via a processor, a transaction data analysis process which is arranged to analyse the transaction data to determine income data and expense data.

17. A computer program, comprising instructions for controlling a computer to implement an apparatus in accordance with Claim 15.

18. A computer readable medium, providing a computer program in accordance with Claim 17.

19. A data signal, comprising a computer program in accordance with Claim 17.