AU2015100852A4 - Financial Transaction Management System - Google Patents

Abstract

A method for automated management of multiple payments from member accounts to third party accounts, the method comprising the steps of: providing a transaction management system having a database recording registered member profiles including: (i) pre agreed payment schedules in respect of third party accounts; (ii) member account details including balance; and (iii) member top-up account details; assessing each member's account balance against the pre agreed payment schedule; identifying member account balances with insufficient funds to meet the pre agreed payment schedule; transferring funds from the member top-up account to the member account; and debiting the member account and crediting a third party account according to the pre agreed payment schedule. Calculate recurring If Top Up process is payments due in triggered as a result of a new X daysItem being added, If < 4 days, credit card Is the only option for topup. Compare value against current available funds in is $ available > calculated amount No Limited to X number of re attempts, credit card only o Top up Process etc, up until due date. 34 Yes Pament Hard Reject- SMS, email, report notifications Hold Payment until due date 6 Make Payment / transfer Fic

Description

FINANCIAL TRANSACTION MANAGEMENT SYSTEM FIELD OF INVENTION The present invention relates generally to the field of processing and facilitating financial transactions and in particular, to an automated computer based method 5 and system for managing payments of multiple and recurring transactions between a consumer and a business. BACKGROUND OF THE INVENTION In modern society, there is an ever increasing requirement to provide for environments that support cashless transactions between vendors and consumers 10 in a simple and convenient manner. Such environments seek to provide vendors with a simple means for receiving payments for goods and services without the need to hold large values of cash on premises, and also enables consumers to remotely make payments for goods and services without the need to physically visit the store or outlet where the goods or services are located. 15 In circumstances where customers make regular payments to a vendor for an ongoing service, the ability to employ computer based systems to facilitate the bill presentment and payment process is well established. In this regard, for businesses such as utility providers, schools, insurance agencies, childcare centres, fitness centres, and the like, such businesses issue bills at regular 20 intervals requiring ongoing payment by the customer. As such payments are made at regular intervals for relatively similar amounts, the bill presentment and payment process can lend itself to a degree of automation, especially where an agreed payment process has been entered between the parties. There exist a variety of different systems to facilitate bill presentment and 25 payment. A simple system for achieving this is where the consumer is provided with an interface, typically by way on the consumer's on-line banking system, which enables the consumer to pay a bill that has been presented to them, through the transfer of funds from the consumer's account to the vendor's account. Such a system requires the consumer to oversee and manage the process and the 30 payment is performed by the consumer upon receipt of a bill from the vendor. This is often referred to as a direct pay system. In such a direct pay system, the consumer enters the billing information that they may have received independently of the payment system they are using to make 1 the payment. In this regard, the consumer may have received a bill from a vendor via an email or mail service and upon receipt of the bill the consumer makes the payment directly to the vendor by entering the details into the interface provided by their online bank or financial institution. 5 An alternative system to facilitate such bill presentment and payment is a system that often referred to as a Third Party Payment Processor (TPP) system. Such systems are controlled by a party other than that party issuing the bill to the consumer. In a TPP system, the third party presents the bill to the consumer, collects payment information and forwards payment request to a payment 10 generator for payment. The payment generator is typically an automated computer system that receives payment requests, validates the request information, determines that payment method and instructs a payment processor to retrieve the payment after which the payment is forwarded to the biller. Whilst TTPs are largely successful in coordinating payments between consumers 15 and service/product providers, they typically operate in a largely unregulated market and often charge large and unnecessary fees to consumers as well as the service/product providers to provide such a service. Such TTPs also provide little option to the users in terms of debit providers, which are typically determined by the TPP who require members to sign multiple debit agreements which are costly 20 and difficult to break; especially if a member seeks to move to an alternative TPP service provider. With conventional TPP systems, it is possible that a payment generated by the payment processor is returned due to a failure of the payment to be finalised, such as when the nominated bank account of the consumer has insufficient funds to 25 cover the payment request. In such instances, the returned payment is reported back to the product/service provider as well as the consumer, which may take considerable time, and often includes a considerable fee, which results in the consumer being charged as well as the service/product provider failing to receive payment. This can have significant detrimental impact to the cash flow of the 30 product/service provider as well as being a significant financial drain on the consumer. With many consumers paying multiple bills from a common account which may also be accessible for other purposes, such as day-to-day expenses, it is often difficult to co-ordinate the transfer of funds in a manner which ensures that the 35 account will have sufficient funds to meet the ongoing needs of the consumer 2 over time. Typically, to provide such control over the account, the consumer needs to be aware of ongoing bills that are automatically debited from the account and ensure that the balance is retained at a level sufficient to meet these payments. Where multiple payments are being made from their account, this can 5 be difficult to achieve and manage. Similarly, for a business that provides a service or product to consumers, such businesses rely upon ongoing collection of payments from consumers in a timely manner, typically via TPPs. Any delay by the TPP to transfer funds collected or failure to collect funds can have a significantly detrimental effect on a businesses 10 cash flow and viability. Thus, there is a need to provide for a system of managing financial transactions between a consumer and multiple service/product suppliers that benefits both the consumer and the supplier and which is simple to use and can provide transparency and assurance that funds can be transferred in a timely and efficient 15 manner. Similarly, without control and vision of upcoming transactions it is difficult to manage the amount of money available for discretionary spending, whether that be in the form of a new bill or series of bills, purchase through Point of Sale or ecommerce or the like. 20 The above references to and descriptions of prior proposals or products are not intended to be, and are not to be construed as, statements or admissions of common general knowledge in the art. In particular, the above prior art discussion does not relate to what is commonly or well known by the person skilled in the art, but assists in the understanding of the inventive step of the 25 present invention of which the identification of pertinent prior art proposals is but one part. STATEMENT OF INVENTION The present invention provides a method for automated management of multiple payments from member accounts to third party accounts. The method comprises 30 the steps of: providing a transaction management system having a database recording registered member profiles including: (i) pre agreed payment schedules in respect of third party accounts; (ii) member account details including balance; and (iii) member top-up account details; 3 assessing each member's account balance against the pre agreed payment schedule; identifying member account balances with insufficient funds to meet the pre agreed payment schedule; 5 transferring funds from the member top-up account to the member account; and debiting the member account and crediting a third party account according to the pre agreed payment schedule. In one embodiment the method further includes the step of providing a debit card 10 linked to the member profile, wherein use of the debit card is recorded against the member account balance. Preferably, the member top-up account includes a bank account and a credit card, and wherein the method further includes, after the step of identifying member account balances with insufficient funds, the step of triggering the bank account 15 for a nominated amount of funds and simultaneously seeking pre-authorisation of the credit card for the same nominated amount of funds to ensure collection from either the bank account or the credit card prior to debiting the member account. Still preferably, the method further includes the step of holding funds for a scheduled payment a pre-defined time prior to the scheduled payment to ensure 20 held funds are not withdrawn prior to the scheduled payment. Preferably, the pre-defined time corresponds to lead time to transfer funds from the member top-up account to ensure sufficient funds are available for the scheduled payment. BRIEF DESCRIPTION OF THE DRAWINGS 25 The invention may be better understood from the following non-limiting description of preferred embodiments, in which: Fig. 1 is a simplified block diagram of the transaction management system of the present invention in accordance with a first embodiment; Fig. 2 is a flow diagram depicting a method of creating a member profile 30 for use with the system of Fig. 1; Fig. 3 is a flow diagram depicting a method for managing a user account 4 in accordance with an embodiment of the present invention; Fig. 4 is a flow diagram depicting a method of registering a new payment in accordance with an embodiment of the present invention; and Fig. 5 is a flow diagram depicting a method of managing a user account in 5 accordance with an embodiment of the present invention. DETAILED DESCRIPTION OF THE DRAWINGS Preferred features of the present invention will now be described with particular reference to the accompanying drawings. However, it is to be understood that the features illustrated in and described with reference to the drawings are not to be 10 construed as limiting on the scope of the invention. Referring to Fig. 1, there is shown a simple integrated system referred to as a transaction management system (TMS) 10, in accordance with an embodiment of the present invention. The TMS 10 functions as an interface between a plurality of consumer service providers (CSPs) 12 and a database 14 of registered 15 members 15. Each CSP 12 may compense a business or organisation that functions as a payment requesting source that requests a payment from one or more of the members 15. A CSP 12 could be any business or organisation that sells a product or a service, and may include a utility service provider, school, insurance agency, 20 gym or fitness centre, childcare centre, etc that generates a bill or requires a payment for services or goods provided. Each CSP 12 is typically registered with the TMS 10 in a manner which will be discussed in more detail below. The TMS 10 generally functions to receive a payment request from each CSP and to obtain payment from each registered member 15 in accordance with pre-agreed 25 terms of payment that may have been entered between the CSP 12 and the member 15 as part of the initial transaction. Each member 15 is able to manage or oversee the process of payment of the CSP 12 and the TMS acts to provide a degree of management of each member's funds to ensure that the member 15 is sufficiently resourced to meet their ongoing financial obligations. 30 Referring to Fig.2, the steps showing the manner in which a new member 15 is created with the TMS 10 is shown. Firstly, all new members 15 must create a profile with the TMS 10 in step 20. The step of creating a profile essentially requires the individual completing a number of predetermined fields identifying 5 the individual member for storage on a member database. The predetermined fields may include such information as name and address as well as other information such as date of birth and the like, to assist in identifying the individual member. As the TMS 10 is typically accessed by way of a distributed 5 network, such as the internet, each individual member 15 is able to set-up a password and username to facilitate remote log-in into the TMS 10. Following the establishment of a user profile in step 20, the member 15 must then review and agree to the terms and conditions of use of the TMS 10 in step 21. As the TMS 10 requires the storage and access of individual member's credit cards 10 and bank account details, the terms and conditions of use of the TMS 10 must establish a variety of legal agreements between the member and the provider of the TMS 10. This may include an authorisation of a direct debit authority and a complete indemnity of the funds retained by the TMS 10 on behalf of the member 15. The terms and conditions may also include information pertaining to the fee 15 structure of the TMS 10 and the manner in which the TMS 10 will handle inactive accounts. In this regard, the terms and conditions of use of the TMS 10 by each member 10 may advise each member that any accounts that remain inactive or which have not been active for a specified period of time will be subjected to inactivity fees as well as any other additional information pertaining 20 to monthly fee structures In step 22, the member 15 is required to register their bank and/or credit card details as a mandatory step in establishing an account with the TMS 10. The member 15 may register any number of bank accounts and/or credit cards as required. 25 In step 23, each member is required to deposit funds into their member account to activate the account for use. The amount of funds deposited into the account will be commensurate with the intended usage of the account by the member. The member must also specify a minimum amount that will always be present in the account. A default amount of, for example $50, may be set for this purpose, but 30 the member 15 may select any desired amount they wish. In step 24, the member also nominate a separate account to facilitate a top-up or recharge of the member account when the total amount contained in the member account falls below the default amount, or is insufficient to meet the ongoing payment needs of the member 15. 35 It will be appreciated that for all registered members 15, a part of setting up an 6 account with the TMS 10 is to specify a minimum account balance and also a minimum top-up value. If the value of the member account stored in the TMS 10 falls below account minimum value at any given point in time, the TMS 10 will be required to collect a payment from the member 15 to bring the member's 5 account back above the agreed minimum amount. The manner in which the top up occurs will be discussed in more detail below. Following the creation of the member account as depicted in Fig. 2, the member is then able to register payments that are to be made to nominated CSPs 12. The payments will depict the date upon which the payment is to be made from the 10 member's account, as well as the amount to be paid and any other relevant details. The member may then be provided with a debit card that is linked to the member's account and which may be used from any ATM or store. Use of the debit card by the member will be recorded against the member's balance. 15 It will be appreciated that over time, it will be necessary for the member's account to be topped-up to ensure that there is a sufficient balance present in the member's account to make all the registered payments by the required dates. I some instances, the TMS 10 may identify that the balance is insufficient to meet the payment obligations based on a forecast of present funds against future 20 payments and this will trigger an account top-up. Where the top-up is to be taken from the member's nominated bank account via a pre-authorised direct debit, the member is provided with a minimum time window in which the top-up can occur. This minimum time window may be 5 working days to ensure that there is enough lead time available for the funds to 25 clear before the relevant payment is due. All members that choose a bank account as the primary top-up account may also register a credit card as the primary back up option. As a result, at the same time that the bank debit is triggered for the collection of funds, the TMS 10 may also seek pre-authorisation of the same value over the credit card on file. This is to 30 ensure that the funds will be collected from either source in order to maintain the integrity of the payments that are setup for the member to pay. In the event that a pre-authorisation either 1) expires, or 2) is not approved, the TMS 10 is able to continue to attempt the pre-authorisation function each day up until the bank debit either fails or is approved. 7 Upon registration of new bank account details (following the creation of the account setup referred to in Fig. 2) a debit is to occur (even of only $1) to validate the account details entered. A bank account cannot be made active and valid if a pre-registration debit is not performed. In the case of a pre-debit 5 registration, a credit card pre-authorisation is not performed. For members that select a credit card account as the primary top-up account, the TMS 10 may perform a pre-authorisation on the card up to 5 days in advance of the payment. Where the pre-authorisation may fail due to insufficient funds present in the credit card account, a re-attempt may occur daily up until the day of 10 the payment to the client being due. Alternatively if the member registers a 2"n or 3rd credit card, then those cards are to be attempted as part of the pre authorisation process if the primary card fails the pre-authorisation payment. If a bank account is nominated by the member as the secondary account option after the credit card account, if the pre-authorisation of the credit card fails, the 15 bank debit is to be attempted. The TMS 10 preferably performs this no less than 5 business days prior to the date of payment. The pre-authorisation of the credit card is to continue until the funds are secured. If the funds from the bank account are successful, the credit card pre-authorisation is then released. Where there is another credit card registered by the member as a backup, the pre 20 authorisation is to also occur on the backup credit card in the event that that primary card fails the pre-authorisation process. This pre-authorisation from the credit card is to be actioned 1 day prior to the payment becoming due to ensure that there are adequate funds received and paid before the TMS 10 makes the payment. In this regard, when a member enters a new credit card for future top 25 ups, a pre-authorisation payment is to happen to ensure that the card details are correct and valid. The card cannot be made active until this validation is completed. It will be appreciated that the TMS 10 of the present invention is structured to ensure that no member account is able to be in a negative financial state. The 30 TMS 10 of the present invention functions to assess the present balance of the member account against future scheduled payments so as to advise the member as early as possible of a potential problem or likelihood that the account balance may become exhausted. As the TMS 10 has access to secondary accounts to source the funds to attend to the registered payments, the member can be assured 35 that they will not default on any payments, and the CSP 12 is also assured that 8 payments will be made without the need for debt collection services to be sought. The ability of the TMS 10 to keep each member informed of their account status and ability to meet their future scheduled payments enables each member with an important tool to manage their budget and funds. If the member receives 5 increased amounts of warnings from the TMS 10 that their account is likely to be insufficient in the future if a top-up is not performed, the member is able to review their ongoing commitments to determine whether their expenses are becoming excessive, long before the actual financial burden is realised. This is possible due to the ability of the TMS 10 to forecast the member's payment 10 commitments. Further, the TMS 10 is set up such that, at a pre-defined time before the scheduled payments are due to be made, the TMS 10 will "hold" the funds that are required to make the payment in a TMS 10 account. This is to ensure that the member cannot use their debit card at an ATM and withdraw funds, or make a 15 real time payment from their account and leave no funds available to make the appropriate scheduled payment. The lead time for such a "hold" by the TMS 10 will typically depend upon the method of top-up and also the result of any pre-authorisation of credit cards that are registered for such purposes. It is envisaged that an appropriate "hold" time 20 may be 5 working days in most cases. It will be appreciated that not only will the TMS 10 provide obvious benefits to each member 10 by providing them with a simple means by which to manage their payments and control their budget, but there are also considerable benefits available to CSPs 12 that join the TMS 10. Such benefits include assured 25 payments with low fees and immediate release of funds, thereby obviating the need for businesses to employ debt collection agencies to recover funds through bad debtors. Each registered business will also have access to a suite of information within the business portal which will have the benefit of providing access to the funds on the morning that the payment is due; a visual indication of 30 funds that will clear on the payment date such that the business now knows in advance how much they will get paid; and assurance that members that may have a failed payment in the past, will have the payment managed by the TMS 10 before the payment is due. In this regard, each CSP 12 is required to register their business with the TMS 10. 35 Such a registration will typically require the CSP 12 to enter their business details 9 together with their bank details for enabling the TMS 10 to deposit the funds as required. Once registered with the TMS 10, the members 15 may select the CSP 12 to initiate payments. The TMS 10 will also allow businesses to use the TMS for the management of 5 business recurring and one-off payments. Essentially this is the same type of account as a member account; however, this account will be more geared towards businesses that need to manage recurring payments made to suppliers and other businesses on a regular basis. E.g.: Franchise groups, hospitality etc. The TMS 10 is hosted by a central server which is accessed remotely by a 10 plurality of users via a distributed computing network, such as the internet. It will be appreciated that the following discussion describes one structure of such a system, but variations to the system as would be appreciated by those skilled, are also envisaged. The central server communicates with a distributed computing network via wired 15 or wireless communication channels, as will be appreciated by those skilled in the art. In a preferred embodiment, the distributed computing network is the internet. A plurality of users is connected to the distributed computing network by way of computer devices, such as personal computers, mobile phones and/or tablet devices. In such an arrangement, multiple users are able to access the central 20 server to receive and download information therefrom, as will be discussed in more detail below. As will be appreciated, the central server is configured to house multiple databases necessary for the proper operation of the methods and systems of the present invention. The server may be any of a number of servers known to those 25 skilled in the art and are intended to be operably connected to the network so as to operably link to the plurality of users. The server typically includes a central processing unit or CPU that includes one or more microprocessors and memory operably connected to the CPU. The memory can include any combination of random access memory (RAM), a storage medium such as a magnetic hard disk 30 drive(s) and the like. The memory of the server may be used for storing an operating system, databases, software applications and the like for execution on the CPU. As will be discussed in more detail below, in a preferred embodiment, the database stores one or more computer programs capable of processing information provided by the users to facilitate and manage financial transactions 35 between a variety of registered parties. 10 Generally, once a user is registered with the TMS 10 and becomes a member 15, the member 15 is able to access the TMS 10 via a user interface, through their PC or laptop computer, mobile phone, tablet device or other connected device. The member interface provides an interface that all members will be able to use for 5 the complete management of all their payments. The Member interface is the key portal for the members and will be the most commonly used interface within the entire system. Through the member interface, each member of the TMS 10 will be able to administer and view all recurring payments that are in place, as well as manage other areas such as top up's, 10 discretionary savings, bank and credit card information and alert / communication functions and view transaction history. They will also be able to edit/change their own details, including account details and add new CSPs 12 as desired. Upon entering the member interface, each member will be able to view, at a glance, a snapshot of their status that includes last payment made, current 15 balance, recent messages/alerts, next upcoming top-up and date of next payment due and to whom that payment is to be made. Should a member 15 require more details about their account, the member 15 can select an appropriate icon provided in the member interface for a more detailed display of their settings. This may include all details relating to the member, 20 including Edit Functions. Details will include bank account / credit card details, contact information, etc. From this portal, the member will be able to specify multiple accounts, in priority order for making top-ups. Each member 15 will also be provided with a listing of all CSPs 12 or businesses that they currently have registered with the TMS 10, for payments. The member 25 15 will also be provided with the ability to add new CSPs 12 as required. This could be achieved by the member 15 performing either a simple lookup function for the SCP 12 based on a business code, performing a QR Code scan at the business, or any other similar means. As discussed previously, the TMS 10 functions to assist in managing each 30 member's account to ensure that the account has sufficient funds to meet the member's payment obligations. Fig. 5 depicts a manner in which the TMS 10 achieves this. In step 30 at a predetermined interval the TMS 10 performs a calculation of each member's upcoming payments over a predetermined interval. By way of 11 example, the predetermined interval may be over the next 30 days, although other intervals are also envisaged, depending upon the member's top-up scheme. Typically the calculation in step 30 may be made immediately after a member has made a top-up of their account, added a new one-off or recurring bill, or used 5 their debit card for a purchase. The calculation essentially sums all upcoming payments scheduled for that member and generates a tally referred to as <sum>. In steps 31 and 32, the <sum> generated in step 30 is compared against the member's current account balance. If the <sum> is determined as being greater than the member's account balance, this is indicative that the member has 10 insufficient funds to meet their payment obligations. In step 32, should the comparison show that there is sufficient funds present in the member's account the TMS 10 then moves to step 34 as will be discussed in more detail below. However, if in step 32 the <sum> is determined as being greater than the member's account balance a warning email or message is sent to the member in 15 step 33 and the TMS 10 seeks to obtain an account top-up, in accordance with the member's set preferences, as previously discussed above. The top-up amount will be sufficient to ensure that the member is able to meet their obligations as indicated by <sum>. Once the top-up amount in step 33 has been obtained, or if the account balance is 20 greater than <sum> as determined in step 32, the TMS 10 then makes an assessment in step 34 as to whether the next scheduled payment is within 'n' days. As an example, the 'n days' may be 5 days. If the determination in step 34 indicates that the next payment is greater than 5 days away, the TMS 10 then returns to step 30 where another calculation of <sum> will be determined at the 25 next time interval. However, if the determination in step 34 indicates that a payment is due within the next 5 days, an amount sufficient to cover the payment and any other fees, will be taken from the member's account balance and held by the TMS 10, as described previously. 30 In step 36, payment will be made to the CSP 12 at the scheduled time by releasing the payment amount from the amount held by the TMS 10, thereby completing the transaction. 12 Referring to Fig. 3, there is depicted a method 40 by which a member may register a new recurring payment with the TMS of the present invention, to ensure that the new recurring payment is to be managed by the TMS for future payments. In the method 40, this is achieved by the member accessing the TMS 5 website via the TMS's web page in step 41. This can be achieved over a network, such as the internet, via a member's personal computer or laptop, or any other relevant computer device. In step 41 the user may enter their personal ID details including a password to enable them to enter the TMS site. In step 42 the member is able to enter the Business to which the new payment is 10 to be made by either conducting a search 42a of the TMS records to locate the Business if that Business is already registered with the TMS, or by manually adding and the Business in step 42b. To conduct a search of existing Businesses, registered with the TMS, the member is able to enter details of the Business, such as name, Business ID and the like in 15 an appropriate search field in step 43. The software present in the remote TMS database is then able to conduct a search of their registered Businesses to display a list of Businesses that match the search criteria in step 44. The member is able to select the relevant Business from the listed Business in Step 44, which will result in all payment options offered by that Business being displayed to the 20 member in step 45. The member is then able to select the appropriate payment option in step 46 which depicts the amount/frequency/terms etc of the payment option. In this step the user may be able to select variations of the basic terms offered by the Business, although the amount of variation possible may be limited. 25 If the Business is not registered with the TMS, the member is able to add the Business in step 42b. This is performed by the member manually adding the details of the Business into the TMS database. In step 52 the member manually enters the criteria of the Business to categorise the Business to be entered. This may be performed by the member selecting any of a number of available fields or 30 entering their own field. For example, if the Business is a Gym or Fitness centre that the member has just decided to become a member of, the user may enter the criteria "Gym" or "Fitness" in step 52. In step 53, the member enters the Businesses details and payment information as provided by the Business upon becoming a member with that Business. In step 35 54 the member enters the payment amount and frequency to be managed by the 13 TMS as well as any other information relating to the terms and conditions of membership. In step 55 the member enters the method of payment to be used, which may include such methods as Bpay, Direct Credit and various other forms of payment accepted by the Business. 5 Irrespective of whether the Business is already registered with the TMS or whether the Business has been added to the TMS by the member, the terms and conditions of payment requested by the examiner are accepted by the member in step 47. If, for instance, the member reviews the payment terms and conditions and decides not to accept them, the program is terminated and closed in step 56 10 and the details of the Business will not be recorded and stored on the database of the TMS. Alternatively, if in step 47 the member decides to accept the payment terms, the necessary records will be stored with the TMS and the member's account will be updated to record the new payment details in step 48. The TMS software will 1s automatically perform an assessment of the member's account in step 49 to determine if the existing conditions will be sufficient to cover the member's newly added payment. In essence, this will be a simple calculation that assesses the current balance of the account and the forecast payments and deposits to be made by the member to determine whether there is a likelihood that the member's 20 account balance will be negative, thus requiring a Top-Up process to be triggered. If this assessment considers that there will be sufficient funds in step 49 then TMS software will allow the user to continue and exit the program in step 51. However, if the assessment in step 49 triggers a Top-Up process, the member will then be directed to the Top-Up process window by the TMS software in step 25 50. The Top-Up process will then seek authorisation from the member to obtain top-up funds to cover the newly added payment and to authorise which account the top-up funds will be taken from, and their frequency. In Fig. 4, a method 60 by which a member may register a new payment with the TMS via their mobile phone application is depicted. It will be appreciated that the 30 member may download the TMS software application into their Smart Phone, to automate the process of registering the new payment. In step 60, the member may be present at the Gym that they wish to become a member of. At step 61 the member activates the TMS software application present on their phone which activates a link between the member and the remote 35 TMS server. 14 In steps 62 and 63, the user uses the scanning facility on their mobile phone to scan the QR code of the Business whilst they are present at the Business, which will generate the software application to search the records of the remote TMS database to display the various payment options offered by that Business with the 5 TMS in step 64. The member is then able to review the payment options available. In step 65, if the member does not find any of the payment options to their satisfaction, the user is able to reject the options in step 70 which will close the software application. The user can then discuss other options with the Business 10 or can seek other opportunities with other Businesses. However, if the user selects the payment option in step 65, the payment is then added to the users profile and an update is made in the remote database of the TMS and the members profile stored in the software application on their mobile phone. 15 The remote TMS software and/or the software application on the members smart phone will automatically perform an assessment of the member's account in step 67 to determine if the existing conditions will be sufficient to cover the member's newly added payment. In essence, this will be a simple calculation that assesses the current balance of the account and the forecast payments and deposits to be 20 made by the member to determine whether there is a likelihood that the member's account balance will be negative, thus requiring a Top-Up process to be triggered. If this assessment considers that there will be sufficient funds in step 67 then the software application of the member's smart phone will allow the user to continue and exit the program in step 69. However, if the assessment in step 25 67 triggers a Top-Up process, the member will then be directed to the Top-Up process window by the software application in step 68. The Top-Up process will then seek authorisation from the member to obtain top-up funds to cover the newly added payment and to authorise which account the top-up funds will be taken from, and their frequency. 30 Fig. 5 depicts a manner in which the TMS 10 calculates the payment changes and any Top-Up process required. If a new payment has been added to the members account in the manner as discussed above in relation to Figs. 3 and 4 and the Top-Up process has been triggered by the TMS software, if there are less than 4 days to payment the only 15 means for performing a Top-Up for that member account is via the member's nominated credit card. However, if this is not the case and then the TMS software will perform a check in step 30 to calculate the amount of recurring payments that are due in the 5 upcoming "X" days. By way of example, the predetermined interval may be over the next 30 days, although other intervals are also envisaged, depending upon the member's top-up scheme. Typically the calculation in step 30 may be made immediately after a member has made a top-up of their account or used their debit card for a purchase. The calculation essentially sums all upcoming 10 payments scheduled for that member and generates a tally or combined value. In step 31, this combined value of upcoming payments is compared against the member's current account balance. If, in step 32, the current available funds held in the member's account is greater than the sum of all upcoming payments due in the period 'X', then the TMS will proceed to step 35 where the payment is held 1s until the due date. However if in step 32 the current available funds held in the member's account is less than the sum of all upcoming payments due in the period 'X', this is indicative that the member has insufficient funds to meet their payment obligations. The member will be warned as discussed above and the TMS will 20 initiate an account top-up, in accordance with the members set preferences, as previously discussed above. The top-up amount will be sufficient to ensure that the member is able to meet their obligations as indicated by calculated payment amount. If the Top-Up payment in not successful in step 34, a notification will be sent to 25 the member by way of an SMS or email. The TMS will then continue to perform the Top-Up for a predetermined number of attempts, advising the member each time the Top-Up has failed. If the member's preferred Top-Up continues to file and the due date for payment is immediate, or the number of failed attempts has been exceeded, the TMS will perform a top -up from the member's credit card, 30 as a last resort. If the top-up payment has been successful in step 34, the TMS will hold the payment until the due date, ensuring that the funds have been set aside and are not accessible for other purposes after which the payment will be made by the TMS and the funds transferred in step 36, thereby completing the transaction. 16 It will be appreciated that the method depicted in Fig. 5 provides a simple and convenient means for ensuring that at the time the TMS makes the payment, there are sufficient funds made available for payment by the member 15. By regularly forecasting ahead to determine future payment obligations for each member, the 5 funds can be readily made available to ensure that the CSP 12 is paid on time and that the member 15 meets their financial obligations and avoids any unnecessary penalty fees. It will be appreciated that the transaction management system (TMS) of the present invention provides a unique and powerful system that combines the 10 benefits of a third party payment processor with the benefits of a debit card scheme. The TMS provides an ability to simply and effectively manage ongoing payments as well as one-off payments that enables members t openly manage and have control over their recurring payments and accounts, without fear of missing payments and attracting fees and bad credit ratings. 15 Throughout the specification and claims the word "comprise" and its derivatives are intended to have an inclusive rather than exclusive meaning unless the contrary is expressly stated or the context requires otherwise. That is, the word "comprise" and its derivatives will be taken to indicate the inclusion of not only the listed components, steps or features that it directly references, but also other 20 components, steps or features not specifically listed, unless the contrary is expressly stated or the context requires otherwise. It will be appreciated by those skilled in the art that many modifications and variations may be made to the methods of the invention described herein without departing from the spirit and scope of the invention. 25 The invention can be described in terms of provisional claims that can assist the skilled reader in understanding the various aspects and preferments of the invention. However, these provisional claims are not to be construed as defining statements of the invention. It will be appreciated that other forms, aspects and preferred features of the invention and its embodiments described herein may 30 ultimately be included in the claims defining the invention in the specifications of complete, international or national applications (or their subsequent corresponding patent grants) that may claim priority from the provisional application accompanying this specification. In this context, the following non limiting claims assist to better describe the invention: 35 17

Claims (5)

1. A method for automated management of multiple payments from member accounts to third party accounts, the method comprising the steps of: providing a transaction management system having a database recording registered member profiles including: (i) pre agreed payment schedules in respect of third party accounts; (ii) member account details including balance; and (iii) member top-up account details; assessing each member's account balance against the pre agreed payment schedule; identifying member account balances with insufficient funds to meet the pre agreed payment schedule; transferring funds from the member top-up account to the member account; and debiting the member account and crediting a third party account according to the pre agreed payment schedule.

2. The method of to claim 1, further including the step of providing a debit card linked to the member profile, wherein use of the debit card is recorded against the member account balance.

3. The method of claim 1, wherein the member top-up account includes a bank account and a credit card, and wherein the method further includes, after the step of identifying member account balances with insufficient funds, the step of triggering the bank account for a nominated amount of funds and simultaneously seeking pre-authorisation of the credit card for the same nominated amount of funds to ensure collection from either the bank account or the credit card prior to debiting the member account.

4. The method of claim 3, further including the step of holding funds for a scheduled payment a pre-defined time prior to the scheduled payment to ensure held funds are not withdrawn prior to the scheduled payment.

5. The method of claim 4, wherein the pre-defined time corresponds to lead time to transfer funds from the member top-up account to ensure sufficient funds are available for the scheduled payment. 18