GB2397411A

GB2397411A - Managing payment mandates between selected bank accounts and beneficiary accounts

Info

Publication number: GB2397411A
Application number: GB0328951A
Authority: GB
Inventors: Ian Rosser
Original assignee: Individual
Current assignee: Individual
Priority date: 2002-12-14
Filing date: 2003-12-15
Publication date: 2004-07-21
Also published as: GB0328951D0

Abstract

A transaction control system for enabling a customer to set up and manage payment mandates (direct debits or standing orders) between specified bank accounts and specified payment beneficiaries. The mandates can be amended or cancelled easily. The transaction control system comprises a customer information database 24, a bank information database 26 and a database of beneficiary information 28. A customer 12 can mandate payment between a selected bank account and beneficiary account via e.g. a PC and modem or touch tone telephone 19. The transaction control system can communicate appropriate information/instructions to appropriate bank and/or beneficiary devices. Alternatively the system can be used simply to keep an active record of customer payments which is accessible by the customer.

Description

1 239741 1 Independent Transaction System The invention relates to

improvements in transaction systems and in particular, but not exclusively, to a transaction system which enables a user to record and mandate payments between a selected bank account and beneficiary account.

It is known to set up a payment between a specific account of a beneficiary such as a utility company by way of standing order or direct debit. Each of these payment set ups are independent of each other and must be altered or cancelled separately. It is also known to provide a web site allowing access to such payments for a specific account by a user on a PC via the Internet. By such a web site, new standing orders can be added or deleted for the account. However, in order for a payment to be transferred to, or set up for, a new account, whether for the same bank or of a different bank, it is necessary to cancel the payment account, possibly via a web site, and also to set up a payment for I S the new account, by a different web site or by alternative means. Some accounts will not have corresponding web sites, so payments may have to be set up by post or by bank staff, and those that do may be of differing formats and therefore a user must familiarise himself with each of the different formats. It is also difficult for a user with multiple bank accounts to keep track of all their payments since payments from different accounts must be viewed and accessed separately.

In this context a bank is understood to mean any institution involved in originating or receiving monies via some form of money transmission.

Whilst the existing mechanism for payments of standing orders and direct debits between bank accounts and beneficiary accounts are effective, the processes of seeing an overview of an individual's totality of payments and of altering and managing payments and in particular for altering which bank account such payments should be from is both time consuming and potentially prone to error. Consequently, many bank customers who use such payment systems experience confusion, do not feel in control of their payment related relationships and behave sub optimally, and in particular can be deterred from changing bank accounts, and also from managing payments from their existing bank accounts efficiently, by the difficulties of changing these payments.

Accordingly, the invention seeks to provide improvements in transactional systems governing payments, to streamline processes, and to reduce costs for banks and beneficiaries An object of the invention is to enable a customer using an improved system to alter the bank account, from which such payments are made, more easily.

Another object of the invention is to access an overview of which payments they have established and from which accounts.

Beneficially the invention improves user convenience especially where the user is a customer (personal or impersonal, club, company, partnership etc..). The invention also benefits banks and beneficiaries by reducing the need for infrastructure and administration and also by reducing errors in payment set ups, amendments and cancellations. The invention also reduces the need to provide separate systems, interfaceable by a user, for payments for each bank account.

According to a first aspect of the invention there is provided a transactional control system comprising a first database of customer information, a second database of bank information, and a third database of beneficiary information; a controller adapted to address each of the first, second and third databases (any of which may be on the same or separate server and could form subsets of one or more databases); and to communicate instructions to a separate device, such as a bank or beneficiary device; wherein the controller enables a user to mandate payment between a selected bank account and beneficiary account, and communicates the user generated payment mandate to a pre-determined separate device.

Preferably the controller is interfaceable with a customer input device, such as a PC and modem or touch tone telephone. More preferably the controller is interfaceable via an output device with the customer input device, and the output device is adapted to communicate the instructions to the separate device. Preferably still the user is enabled to mandate payment between a selected bank account and beneficiary account controller via the input device. These accounts may be domiciled within more than one country and/or be in more than one currency The output device may be a modem.

Preferably a previously generated payment mandate can be altered in respect of the selected bank or beneficiary account and when the selected bank or beneficiary account is altered, instructions to cancel the payment are preferably sent to a separate device corresponding to the earlier selected account and the payment mandate is preferably sent to a separate device corresponding to the newly selected account.

The second database preferably contains information representative of a plurality of bank accounts more preferably including one or more of bank name, sort code, branch name, account number and account name for each account and preferably still the selected bank account is selected from the plurality of bank accounts represented in the second database.

Preferably the first database contains personal information including one or more of the customer's full name, address and date of birth and more preferably contains information representative of a plurality of customers preferably including one or more of a user name, a password, a memorable number date or place for verification.

In one form of the invention the user is intended to be a customer represented in the first database and must enter one or more items of information for verification, preferably selected, and possibly some or all randomly selected, from the information representative of that customer stored in the first database, such as user name, password and/or memorable number, date or place and will only be allowed to use the system and mandate payments if the entered information corresponds to information stored in the first database.

Preferably the third database contains information representative of a plurality of beneficiary accounts more preferably including one or more of an identification string such as the name of the beneficiary, a bank sort code identifier, an individual account identifier such as a number and a payment identifier such as a reference number and preferably still the beneficiary account from or to which payment is mandated, is selected from the plurality of beneficiary accounts represented in the third database.

When instructed to mandate a payment the system preferably validates the selected bank account before automatically communicating the payment mandate to a separate device. The validation may include checking the sort code against the second database and/or checking the number of digits in the account number and/or checking a check or identification digit in the account number.

When instructed to generate a payment, the system preferably validates the selected beneficiary account before automatically communicating the payment mandate to a separate device. The validation may include requesting the sort code and account number (or similar bank, branch or account verification and identification items as is appropriate for the country in which the invention is used) and checking the entered values against the third database.

After payment has been mandated the system preferably communicates with a separate device corresponding to the selected bank account and mandates the bank to issue payment or payments and/or communicates with a separate device corresponding to the S selected beneficiary account and mandates the beneficiary to request payments and preferably also communicates with a separate device corresponding to the selected bank account and mandates the bank to authorise payments to the beneficiary account.

The input device may comprise a computer and modem connected to a network and preferably the Internet, a telephone preferably with voice and/or touch tone capability, a mobile telephone using WAP or G3 or by SMS text messaging, a voice activated device either used directly by a customer or located remotely and used by a customer via a telephone, or a device owned and operated by a bank or other authorised third party, with information being passed in non-electronic format (such as on paper or by fax) by the customer for input.

The payment mandate will preferably include one or more of the following to be specified by the user: the amount to be paid, the frequency of payments, the first date on which a payment should be made, the last date on which a payment should be made, and whether the amount to be paid is unspecified and to be requested by the beneficiary (direct debit), and more preferably also communicates with a separate device corresponding to the selected beneficiary account to inform the beneficiary of the payment mandate. Preferably a previously generated payment mandate can be altered by a user in respect of one or more of the amount to be paid, the frequency of payments, the first date on which a payment should be made, the last date on which a payment should be made, or whether the amount to be paid is unspecified and to be requested by the beneficiary (direct debit).

Preferably the controller comprises a relational database or some form of system with similar capabilities.

The payment between a selected bank account and beneficiary account may comprise a regular periodic payment such as a standing order, an irregular payment such as a bill payment, a parameter lead payment such as a payment moving money between different types of account initiated when for example a minimum or maximum balance parameter is reached, a payment to be requested by the beneficiary corresponding to the beneficiary account, such as a direct debit, a payment the issuing of which is to be requested by the user such as a bill payment or movement of money between accounts of the user and/or a transfer originated in one currency, and an exchange and credit being in another currency.

Preferably the selected bank account is a current account, a deposit account and/or a credit card account.

Preferably the customer is an individual, business or a not for profit organization.

According to a second aspect of the invention there is provided a transaction system comprising a first database of customer information, a second database of bank information, and a third database of beneficiary information; a controller adapted to address each of the first second and third databases; wherein the controller enables a user to record payment between a selected bank account and beneficiary account.

A user may by able to enter information into the second and third database such as creating details of a new bank account and use it as a central payments record, or if being utilised to instruct Banks to set up, amend or cancel payment records preferably this information is automatically communicated to a separate device corresponding to the new account instructing the bank to accept payment mandating from the system.

According to a third aspect of the invention there is provided a transaction control system comprising a first database of customer information, a second database of bank information, and a third database of beneficiary information; a controller interfaceable with a customer input device, such as a computer and modem, and adapted to address each of the first, second and third databases and to communicate instructions to a separate device, such as a bank or beneficiary device; and further wherein the controller enables a user to generate payment instructions between a selected bank account and beneficiary account, and communicates the customer generated payment instructions to a pre-determined separate device.

Embodiments of the invention will now be described, by way of example only, with reference to the accompanying drawings in which: Figure I is a flow diagram of the relationships between a customer's bank accounts and direct debit and standing order payments in a conventional manner; Figure 2 is a flow diagram of the relationship between a customer's bank account and payments according to the invention; Figure 3 is a schematic representation of a transaction control system according to the invention in communication with banks and beneficiaries; Figure 4 is a schematic representation of the manner in which payments are made between a bank account and a beneficiary when set up and run by a transaction control system in accordance with the invention of Figures 2 and 3; Figure 5 is a flow diagram of the process of a customer 12 setting up a new payment mandate using the transaction control system of Figures 2 and 3; Figure 6 is a flow diagram of the process of a customer 12 altering an already established payment mandate using the transaction control system of Figures 2 and 3: and Figure 7 is a schematic representation of a transaction control system according to the invention.

In Figure l a customer A interacts with banks B and accounts C of these banks B to make payments from accounts C to beneficiaries. Each payment is fixed to a particular account C. In this example the customer A has accounts at two banks B and B' each with two accounts. The customer A must communicate with the relevant bank B in order to make or alter payments from the accounts.

The payments consist of direct debits D and standing orders E which are set up with each account C. The standing orders E draw a certain amount from the corresponding account C and pay this amount to an account of a beneficiary at regular customer defined intervals. The direct debit D allow the relevant beneficiary to take a relevant amount of money from the account C and at relative intervals, for example from one particular account C a customer 12 may have a standing order paying a gas company one hundred pounds per month and also have a direct debit D authorising electricity company to request the amount owed by the customer 12 each month directly from the account C, such an amount varying depending on the amount of electricity used that particular month by the customer A. In order for a customer A to change the standing order from one account C' to another account C" with another bank the customer must cancel the first standing order E' with the first account C' and set up an entirely new standing order E" with the second account C". In order to change the direct debit D' from account C' to the account C" the customer must cancel the first direct debit with the bank B. establish a new direct debit D" with bank B' for account C" and inform the beneficiary that a new direct debit is to be set up so that payment is requested from second account C".

Accordingly, whilst payments between bank accounts for the customer A and beneficiary can straightforwardly be processed, for example by electronic transfer such as BACS, SWIFT or CHAPS (Clearing House Automated Payment System) or other suitable national/international payments infrastructure, the procedure for changing the mandate or instructions from the customer are very complex in known systems.

In Figure 2 the customer 12 interacts with a transactional control system 10 in accordance with the invention. The system 10 is positioned between the customer 12 and the banks 14 so that all payments, which may include standing orders and direct debits, are recorded, set up, altered and cancelled via the system 10 and the customer 12 can view and manage all payments together in one place. Beneficially a payment need only be set up once with system 10 for the full life of the payment, only needing to be cancelled at the end of that lifetime.

Payments created or managed by the system include preauthorised payments such as direct- debits and standing orders, payments of unspecific and irregular frequencies (sometimes known as bill payments), parameter lead payments such as those involved with moving or "sweeping" money between accounts (such as between a current and deposit style account), payments involving exchange between international currencies and payments from or to credit and charge card accounts. Payments may be for exchange of value immediately or at a later date.

Referring to Figure 3 the transaction control system 10 can be seen to comprise an input 18 an input verification channel 20 a controller 21, comprising a relational database 22, a customer database 24 a bank database 26 and a beneficiary database 28. The controller 21 and databases 26 and 28 preferably all form part of a computer which has an output device such as a modem.

The input 18 can comprise a computer and modem linked to channel 20 by the Internet, a touch tone telephone linked to the channel 20 by a public switch telephone network, a mobile telephone e.g. using WAP, G3 or by SMS text messaging, a voice activated device either used directly by a customer or located remotely and used by a customer via a telephone, be in paper format sent by post or comprise receiving voice instructions either from the customer or an authorised third party. Alternatively the input 18 could form part of the same computer as the databases 22, 24, 26, 28 such that the customer 12 uses the system 10 in a specific location or has software which incorporates system onto their home computer.

The input verification channel 20 transmits the information entered by a customer 12 at the input 18 to the database 22 via an output device such as a modem. This also validates personal information entered to identify the customer 12 against the information stored in the customer database 24 via relational database 22.

The customer database 24 contains information representative of multiple customers 12. For each customer 12 there is stored personal information in a series of fields including the customer's full name, address (including the postcode), the date of birth as well as information enabling the verification of the customer's identification such as a user name, a password and memorable items such as a number, date or event likely to be known only by the customer 12. The information is initially entered into the database 24 by the customer 12 themselves but such information is first checked by the system 10 before it is entered into the database 24. The system 10 ensures that each customer 12 user name and password is unique so that the customer 12 is not mistakenly misidentified. The system 10 also ensures that a customer 12 has entered information into the fields such as their full name which are essential for allowing a record of that customer 12 to be stored in the database 24. The system 10 also ensures that the password fits the minimum criteria on the number of characters and/or has the correct mix of alphanumeric characters and may also be able to complete the customer's address from their postcode being supplied.

Bank database 26 contains information representative of several bank accounts, such accounts often being from different bank providers. For each account 16 the bank database 26 has a record containing the bank name, the sort code, the branch name, the account number and the name of the account 16. As with the customer database 24 some of the information on the bank database 26 is initially entered by customers 12.

The bank names that may be entered can be limited to a list already stored in the bank database 26, this list being the complete list of banks that have agreed to the use of the system 10. A pre-entered bank list also saves the customer 12 from entering further details such as the bank's address, etc.. The system 10 will also use a file from a suitable national or international organisation such as APACS to check that the entered sort code and branch name match. The account number entered is also validated by the bank account validation tables 36. This may for example check the number of digits in the account number using bank details, validate any digit identifying the type of account and/or validate a check digit in the account number. The relational database 22 provides a relational link for the bank accounts in the bank database 26 which correspond to which customers 12 in the customer database 24.

Whenever a new bank account 16 is entered by the customer 12 a communication is sent to the relevant bank 14 via security system 38. In one embodiment this communication is in the form of an electronic message, such as an email or a signal containing code, encrypted by security system 38 and sent by a modem (output device).

Alternatively any other suitable form of communication could be used such as voice, paper, fax. If the bank account 16 has already been set up this encryption may be based on an existing user name and password provided by the bank 14 for this account 16.

In an alternative embodiment a bank 14 which has agreed to use the system 10 and has a new bank account 16 set up for a customer 12 who already uses the system 10 will communicate the details of this account 16, encrypted through security system 38, to the system 10 with the bank database 26 being automatically updated. Alternatively before the bank database 26 is updated the customer 12 is sent by the bank 14 or system 10, specific forms or other communications, such as by electronic message or telephone, for the customer 12 to authorise, which may include signature. Once authorised the bank database 26 is updated so that the bank has customer authority to act using the invention.

The beneficiary and payment database 28 contains information representing a number of named beneficiaries such as gas companies, electric companies, insurers etc. which have agreed to use system 10. The database 28 may also contain addresses of each of these beneficiaries and possibly also account details including bank sort codes and account numbers. For accuracy and quality of data input this information is validated before being entered into the database 28. The customer 12 will normally only need to access the beneficiary payment database 28 when payment is set up or changed; and then the relevant beneficiary can be entered at the same time as details of that payment.

However, it is also possible for a customer to add new beneficiaries, which is particularly useful for one off payments. Details of all payments can be retained by the system for an indefinite period, or one specified by the user.

Where a new beneficiary is entered only the account details will be validated, information such as names and addresses, purpose or other identifier such as nickname of the payment, being free for the customer to choose provided the account number does not match any already stored in the beneficiary and payment database 28.

Addresses can be pre-populated in the beneficiary and payment database 28 using a PAP (Postcode Address Files) style system so that a customer need only enter a postcode, from which the rest of the address is provided from the database 28, the customer only then having to add a number or building name if appropriate.

Any payment details that are entered are validated using the originator and payment validation tables 32 before being sent to the relevant beneficiary 30 via security system 34, preferably via an output device such as a modem.

Once the payment has been validated and communicated to the beneficiary 30 and bank 14 payment between the bank 14 and beneficiary 30 is set up and continued using conventional payment mechanisms 40 such as BACS or CHAPS.

In an alternative form banks 14, bank database 26, bank account validation tables 36, and security system 38 are part of a separate bank group national or international infrastructure. In this form the rest of system 10 communicates with this infrastructure rather than communicate bilaterally with each bank 14.

In Figure 4 is shown how once a payment mandate has been validated by payment validation tables 32 for a bank account 16, validated by bank validation tables 36, the payment mandate 42 is put in place with the beneficiary 30. In the embodiments shown in Figure 4 communications are sent to beneficiary 30 and the beneficiary relays this information via channel CH to the relevant beneficiary bank account.

The established payments e.g. BACS continue to be made by the beneficiary payment mechanisms 40. Bank payment 44 will continue until instructions have been changed and communicated to the bank account 16 and similarly the beneficiary bank will continue to accept payment or in the case of direct debit request payments, instructions to change have been received from the system 10 via the beneficiary 30.

In Figure 5 is shown the process of a customer 12 setting up a new payment mandate.

The customer 12 enters their identification details via input 18 at step S50. These identification details are then checked against the information in the customer 12 database 24 at step 52 and only if the relevant details correctly correspond to the stored information will a payment mandate be allowed to be established.

Once correctly identified the customer 12 will enter details of the new payment at step 54 into input 18. The customer 12 will be asked for the name of the beneficiary, their customer 12 reference number and possibly also the bank sort code and account number of the beneficiary, though the latter two may be known already in the payment and beneficiary database 28. The customer 12 must also enter details of the payment to be mandated including the amount, the frequency (which could be one off, daily, weekly, monthly, quarterly, annually etc.), the start date of the new payments, the end date of the new payments (optional) and what type of payment is to be made. System 10 also ensures that all of the mandatory fields are complete.

In the case of a direct debit the amount may not be relevant since this may be determined by the beneficiary on any given changeable period but where the payment is a standing order the amount must be specified. The beneficiary name andlor account numbers and reference and codes are validated by validation tables 32 with information from the payment and beneficiary database 28. The payment reference code is also checked against the payment validation tables 32 and any dates that have been entered are checked against the current date to ensure that they are all present or future dates.

At the next step S56 the customer 12 selects a bank account 16 from the bank database 26. Information entered by the customer 12 at steps S52, S54 and S56 is also entered into the relational database 22 which ensures that the identified customer 12, and the selected beneficiary 30 and bank account 16 all correspond with each other. The system 10 then checks that all outstanding details have been entered and validated at step 58 and then sends a confirmation message to the customer 12 at step S60 confirming all the information that the customer 12 just entered into the system 10.

The system 10 then checks which type of payment has been entered and if confirmed to be a standing order at step S62 a communication such as an email is sent via security system 38 to the bank 14 containing all the information of the bank account 16 and the payment instructions the customer 12 entered. The bank 14 has then been mandated to make this standing order payment from the relevant bank account 16 to the specified beneficiary 30 via conventional payment mechanisms 40. Preferably the communication is also sent to the beneficiary 30 advising this beneficiary 30 that a standing order has been set up. Optionally there may be a bank verification and feedback loop before the standing order payment is created. This loop comprises the steps of at S65 the bank 14 sending a communication to the customer 12 asking for verification that the payment should be created and at step S65A the customer 12 sending verification to the bank 14. Preferably the loop also comprises an additional step S65B of communicating to system 10 that the customer has verified the payment,with step S66 not being carried out unless step S65B is successfully completed.

If the payment is confirmed to be a direct debit at step S68 then a communication is sent to the beneficiary 30 at step S70 mandating the beneficiary 30 to set up the direct debit in accordance with the payment instructions entered by the customer 12 at step S54. A communication is also sent to the bank 14 mandating the bank 14 to pay the direct debit as requested by the beneficiary 30 via conventional payment mechanisms 40. The bank verification and feedback loop of steps S65, S65A and S65B can also be added between steps S70 and S72.

In Figure 6 is shown the process of altering an already established payment mandate.

At step S74 the customer 12 enters relevant identification details and makes a request to change an existing payment. The identification details are then verified against the customer 12 database 24 and only if these are verified is a payment allowed to be altered. Next at step S78 the customer 12 select an existing payment which is stored in the payment and beneficiary database 28. The system 10 may also keep a record of historical past payments which have previously been cancelled and may allow the customer 12 to select one of these cancelled payments and therefore to re-establish one of these payments. At step S80 the customer 12 selects which bank account 16 he or she wishes the payments to be changed to, from the bank database 26.

The details at steps S76, S78 and S80 are checked by the relational database 22, the payment database 28 and bank database 26 via the validation tables 32 and 36. Once validated a confirmation message is sent to the customer 12 at step S84 confirming the information entered by the customer 12.

The system 10 then checks which type of payment was set up at step S78 and if the payment was verified to be a standing order at step S86 a first communication is sent to bank 14 corresponding to the bank account 16 which was previously established for the payment, instructing the bank to cancel this payment from this account 16, and a second communication is sent to bank 14 corresponding to the bank account which was selected at step S80 and this communication will contain information to set up a standing order in the same manner as step S64 in Figure 5.

If a payment is confirmed to be a direct debit at S72 a communication is sent to the beneficiary 30 mandating it to cancel the old direct debit details and set up new direct debit details corresponding to the newly selected bank account 16 selected at step S80.

A communication is also sent to the banks 14 corresponding to the previous bank account 16 and the newly selected bank account 16 advising that the old bank account 16 should no longer accept request for payment for this direct debit as instructing the new bank account 16 to begin to accept such payments.

The optional bank verification and feedback loop of steps S65, S65A and S65B can also be added between steps S88 and S90 and/or between steps S94 and step S96.

User U may record into payment database 128 payments which have been set up outside of the system 10. The user U may enable these preset up payments to be altered and changed (such as changing the account from which money is to be taken) by the system 10 in the same way as payments created within it. Alternatively the user U may opt for these preestablished payments to be for record purposes and any changes made not to automatically change the payment through the relevant banks 14 and beneficiaries 30 but allow the changes to be made by the user through conventional methods.

In Figure 7 is shown a second embodiment of transaction control system 110.

Substantially identical components or components with substantially identical function to corresponding components of the first embodiment are labelled with the same number as the corresponding component, but with a prefix of 1.

Control system 110 comprises an input 118 an input verification channel 120 a controller 121, comprising a relational database 122, a customer database 124 a bank database 126, a beneficiary database 128, validation tables 132 and 136.

The system 110 works in substantially the same manner as system 10 except that the system does not communicate with banks or beneficiaries and does not mandate payments or changes in payments. Instead the system 210 works to keep an active record of customer payments which is accessible by the customer so that the customer knows from and to which accounts the customer has payments set up. The actual creating and amending of payment instructions with other parties an be done in parallel in a conventional manner.

In an alternative form system 110 can be provided without validation tables 136 and 132 and without the corresponding validation steps.

In the description and claims the word bank is used for any system, body or organisation which can hold money in an account and make payments from it, including for example credit card issuers and manufacturer credits as well as conventional banks.

Claims

Claims 1. A transaction control system comprising a first database of

customer information, a second database of bank information, and a third database of beneficiary information; a controller adapted to address each of the first second and third databases; and to communicate instructions to a separate device, such as a bank or beneficiary device; wherein the controller enables a user to mandate payment between a selected bank account and beneficiary account, and communicates the user generated payment mandate to a pre-determined separate device.

2. A transaction control system according to claim 1 wherein the controller is interfaceable with a customer input device, such as a computer and modem or touch tone telephone.

3. A transaction control system comprising a first database of customer information, a second database of bank information, and a third database of beneficiary information; a controller interfaceable via an output device with a customer input device, such as a PC and modem, and been adapted to address each of the first second and third databases; wherein the output device is further adapted to communicate instructions to a separate device, such as a bank or beneficiary device; and further wherein the controller via the input device enables a user to mandate payment between a selected bank account and beneficiary account, and communicates the user generated payment mandate to a pre-determined separate device.

4. A transaction control system according to any preceding claim wherein a previously generated payment mandate can be altered in respect of the selected bank or beneficiary account.

5. A transaction control system according to claim 4 wherein when the selected bank or beneficiary account is altered, instructions to cancel the payment are sent to a separate device corresponding to the earlier selected account and the payment mandate is sent to a separate device corresponding to the newly selected account.

6. A transaction control system according to any preceding claim wherein the second database contains information representative of a plurality of bank accounts preferably including one or more of bank name, sort code, branch name, account number and account name for each account.

7. A transaction control system according to claim 6 wherein the selected bank account is selected from the plurality of bank accounts represented in the second database.

8. A transaction control system according to any preceding claim wherein the first database contains personal information preferably including one or more of the customer's full name, address and date of birth.

9. A transaction control system according to any preceding claim wherein the first database contains information representative of a plurality of customers preferably including one or more of a user name, a password and records such as a memorable number, date or place for verification.

10. A transaction control system according to claim 9 wherein the user is intended to be a customer represented in the first database and must enter one or more items of information for verification, preferably selected and possibly some or all randomly selected from the information representative of that customer stored in the first database, such as user name, password and/or memorable number, date, place or other string of alphanumeric characters and will only be allowed to use the system and mandate payments if the entered information corresponds to information stored in the first database.

11. A transaction control system according to any preceding claim wherein the third database contains information representative of a plurality of beneficiary accounts preferably including one or more of an identification string such as the name of the beneficiary, a bank sort code, an account number and a reference number.

12. A transaction control system according to claim 11 wherein the beneficiary account from or to which payment is mandated, is selected from the plurality of beneficiary accounts represented in the third database.

13. A transaction control system according to any preceding claim which when instructed to mandate a payment validates the selected bank account before automatically communicating the payment mandate to a separate device.

14. A transaction control system according to claim 13 which validates by checking the bank identifier or sort code against the second database and/or checks the number of digits in the account number and/or checks a check or identification digit in the account number.

15. A transaction control system according to any preceding claim which when instructed to generate a payment validates the selected beneficiary account before automatically communicating the payment mandate to a separate device.

16. A transaction control system according to claim 15 which validates by requesting the sort code and account number and checking the entered values against the third database.

17. A transaction control system according to any preceding claim which after payment has been mandated communicates with a separate device corresponding to the selected bank account and mandates the bank to issue payment or payments.

18. A transaction control system according to claim 15 which after payment has been mandated also communicates with a separate device corresponding to the selected beneficiary account to inform the beneficiary of the payment mandate.

19. A transaction control system according to any preceding claim which after payment has been mandated communicates with a separate device corresponding to the selected beneficiary account and mandates the beneficiary to request payments and preferably also communicates with a separate device corresponding to the selected bank account and mandates the bank to authorise payments to the beneficiary account.

20. A transaction control system according to any preceding claim wherein the input device comprises a computer and modem connected to a network and preferably the internet, or a telephone preferably with touch tone capability or a mobile telephone using WAP, G3 or SMS text messaging, or a telephony enabled PDA, or voice telephony or a voice activated device either used directly by a customer or located remotely and used by a customer via a telephone.

21. A transaction control system according to any preceding claim wherein the payment mandate will include one or more of the following to be specified by the user: the amount to be paid, the frequency of payments, the first date on which a payment should be made, the last date on which a payment should be made, and whether the amount to be paid is unspecified and to be requested by the beneficiary.

22. A transaction control system according to claim 21 wherein a previously generated payment mandate can be altered by a user preferably in respect of one or more of the amount to be paid, the frequency of payments, the first date on which a payment should be made, the last date on which a payment should be made, or whether the amount to be paid is unspecified and to be requested by the beneficiary (direct debit).

23. A transaction control system according to any preceding claim wherein the controller comprises a relational database.

24. A transaction control system according to any preceding claim wherein a user may enter information into the second and third database such as creating details of a new bank account.

25. A transaction control system according to claim 24 wherein when information representing a new bank account is entered into the second database the controller automatically communicates with a separate device corresponding to the new account and instructs the bank to accept payment mandating from the system.

26. A transaction control system according to any preceding claim wherein the controller is interfaceable with a third party input device, such as a computer and modem or touch tone telephone, the third party input device enabled to be instructed by a customer.

27. A transaction control system according to any preceding claim when dependent on claim 2 wherein the customer input device comprise means for receiving input in the form of voice instructions by a user, for example by telephone, such that the controller via the input device enables a user to mandate payment between a selected bank account and beneficiary account 28. A transaction control system according to any preceding claim wherein payment between a selected bank account and beneficiary account is cleared on the day of payment such as by using CHAPS.

29. A transaction control system according to any preceding claim wherein the pre-determined separate device sometimes requests authorisation from the user to set up payment once the user generated payment mandate has been received.

30. A transaction control system according to claim 29 wherein the predetermined separate device always requests authorisation from the user to set up payment once the user generated payment mandate has been received.

32. A transaction control system according to any preceding claim wherein payments which have been established without using system can be recorded on the payments database 33. A transaction control system according to claim 32 wherein a recorded payment mandate which was not generated by system can be altered in respect of the selected bank or beneficiary account and when the selected bank or beneficiary account is altered, instructions to cancel the payment are sent to a separate device corresponding to the earlier recorded account and the payment mandate is sent to a separate device corresponding to the newly selected account.

34. A transaction control system according to claim 32 or 33 wherein a recorded payment mandate which was not generated by system can be altered in respect of the selected bank or beneficiary account and when the selected bank or beneficiary account is altered, no instructions are sent.

35. A transaction control system comprising a first database of customer information, a second database of bank information, and a third database of beneficiary information; a controller interfaceable with a customer input device, such as a computer and modem, and adapted to address each of the first second and third databases and to communicate instructions to a separate device, such as a bank or beneficiary device; and further wherein the controller enables a user to generate payment instructions between a selected bank account and beneficiary account, and communicates the customer generated payment instructions to a pre-determined separate device.

36. A transaction system comprising a first database of customer information, a second database of bank information, and a third database of beneficiary information; a controller adapted to address each of the first second and third databases; wherein the controller enables a user to record payment between a selected bank account and beneficiary account.

37. A transaction system according to claim 36 wherein a previously generated payment mandate can be altered in respect of the selected bank or beneficiary account.

38. A transaction system according to claim 36 or 37 wherein the second database contains information representative of a plurality of bank accounts preferably including one or more of bank name, sort code, branch name, account number and account name for each account.

39. A transaction system according to claim 38 wherein the selected bank account is selected from the plurality of bank accounts represented in the second database.

40. A transaction system according to any of claims 36 to 39 wherein the first database contains personal information preferably including one or more of the customer's full name, address and date of birth.

41. A transaction system according any of claims 36 to 40 wherein the first database contains information representative of a plurality of customers preferably including one or more of a user name, a password and records such a memorable number, date or place for verification.

42. A transaction system according to claim 41 wherein the user is intended to be a customer represented in the first database and must enter one or more items of information for verification, preferably selected and possibly some or all randomly selected from the information representative of that customer stored in the first database, such as user name, password and/or memorable number, date, place or other string of alphanumeric characters and will only be allowed to use the system and mandate payments if the entered information corresponds to information stored in the first database.

43. A transaction system according any of claims 36 to 42 wherein the third database contains information representative of a plurality of beneficiary accounts preferably including one or more of an identification string such as the name of the beneficiary, a bank sort code, an account number and a reference number.

44. A transaction system according to claim 41 wherein the beneficiary account from or to which payment is recorded, is selected from the plurality of beneficiary accounts represented in the third database.

45. A transaction system according any of claims 36 to 44 wherein the input device comprising a computer and modem connected to a network and preferably the internet, or a telephone preferably with touch tone capability or a mobile telephone using WAP, G3 or SMS text messaging, or a telephony enabled PDA, or a voice activated device either used directly by a customer or located remotely and used by a customer via a telephone.

46. A transaction system according any of claims 36 to 45 wherein the recorded payment will include one or more of the following to be specified by the user: the amount to be paid, the frequency of payments, the first date on which a payment should be made, the last date on which a payment should be made, and whether the amount to be paid is unspecified and to be requested by the beneficiary (direct debit).

47. A transaction system according to claim 46 wherein a previously recorded payment can be altered by a user preferably in respect of one or more of the amount to be paid, the frequency of payments, the first date on which a payment should be made, the last date on which a payment should be made, or whether the amount to be paid is unspecified and to be requested by the beneficiary (direct debit).

48. A transaction system according to any of claims 36 to 47 wherein a user may enter information into the second and third database such as creating details of a new bank account.

49. A transaction system according to any of claims 36 to 48 wherein a user may view information in the second and third database such as details of bank accounts or payments.