WO2015176105A1

WO2015176105A1 - Online payment authentication method & system

Info

Publication number: WO2015176105A1
Application number: PCT/AU2015/000291
Authority: WO
Inventors: Mark Mervyn Chazan; Ian MIRELS; Michael Kontorovich; David KROSER
Original assignee: Eftsure Pty Ltd
Priority date: 2014-05-18
Filing date: 2015-05-18
Publication date: 2015-11-26
Also published as: ZA201607929B; EP3146488A4; AU2015263828A1; EP3146488A1; AU2021201156A1; AU2023202304A1

Abstract

Embodiments of the present invention provide an authentication system and method for use with online electronic transactions to enable authentication of payee data before performing the payment transaction. The authentication system builds an authentication file of validated payee details. In response to receiving a plurality of payment information items for a payee input to the authentication module by a payer, the plurality of payment information items for the payee are compared with the payee's verified data. An alert can be output to the payer in response to identifying any discrepancy between the plurality of payment information items input by the payer and verified details for the payee.

Description

Online Payment Authentication Method & System

Technical field

The present invention generally relates to the security of online payments. Aspects of the invention are applicable in systems for authentication and processing of electronic funds transfers (EFT). Applications of the invention can be of particular use for verification of EFT payment to persons and businesses and can be used in conjunction with accounting systems implemented in a computer networking environment. Background

Online banking is becoming increasingly popular due to its convenience. Online banking essentially involves banks providing web portals comprising online banking facilities to their customers. A typical arrangement will now be described with reference to Fig. 1 , showing a schematic diagram, and Fig. 2, showing a corresponding exemplary interface. In Fig. 1 system 100 is used to make online payments. The system 100 comprises a communication network 1 10 (for example the Internet), a computerised bank account system of the bank 120 of a payer 160, an online banking facility 140 of the payer 160, a

computerised bank account system bank 130 of a payee 170 and an online banking facility 150 of the payee 170. Although the entities in Fig. 1 are shown as independent entities connected by links, one entity could be part of another. For example, the online banking facility 140 may be a web portal provided by the computerised banking system of the bank 120. It should be noted that the description of the online banking facility 140 may apply to the online banking facility 150. Also, the link between any two entities in Fig. 1 may be a physical link or a logical link. The links may also be one or more communication networks.

A customer 160 may choose which of their bank accounts will be accessible via the web portal 140, and those accounts will then be associated with the portal 140. The customers 160 (payers) may use their selected accounts to make payments to third parties 170 (payees). This will typically involve the customer 160 entering the payee's bank account information, which may be stored for future use. The payee's bank account information may include, for example, the payee's name, BSB number and bank account number. The payer may be a natural person or a business, when the payee is a business their Australian Business Number (ABN) or other identification may also be added. The customer 160 may also receive payments into their bank account from other payers 170 . More complex arrangements are also possible, such as scheduling future payments, or recurring payments. Various layers of security may also be applied to payments, such as confirmation via authenticated communications channels. Customers may access Internet banking facilities using computers, mobile phones or even tablets. Generally speaking, the security of online payments is secured by the bank encrypting the communications with the customer at the portal, using public/private keys.

The online banking facility 140/150 is typically implemented as a web-based application operating in an Internet browser application such as Internet Explorer, Google Chrome, Firefox. The online banking facility 140/150 is typically coded by HTML and script languages. Alternatively, the online banking facility 140/150 may be an independent application running on an operating system such as Windows, Unix, OS/iOS, Android, etc. Although the online banking facility 140/150 is described as a software application, in practice, it may also be a physical device or part of a physical device performing the similar functions.

An exemplary interface 200 of the online banking facility 140 is shown in Fig. 2. For the payer 160 to make an online payment to the payee 170, the payer 160 logs in to the online banking facility 140. Then the payer 160 enters payment information of the payee 170. In this example, the payment information includes the payee's name ("Tony Smith"), BSB number (" 144512"), account number (" 1545454545") and the amount ("$ 1 ,000") the payer 160 intends to pay the payee 170. In the case the payee 170 is a business, such as a service provider, the payment information may include the payee's business name, ABN number, bank account name, BSB number and account number. In both scenarios, the payer 160 is responsible for ensuring that the payment information is correct. For instance, the payer 160 may check whether the payee's name matches the BSB number and account number; to be sure the payment will reach the right payee. When they are ready the payer 160 will typically click a "Pay" button on the interface of the online banking facility 140 to send the amount from their bank 120 to the bank 130 of the payee 170 through the network 1 10. The receiving banking system then processes the payment in accordance with the information provided. The situation is more prone to errors when larger numbers of payments are made in the same session, since visually checking of the data can become onerous.

Considering a business context, most business have moved from paying suppliers by cheque to using EFT processes - typically through online banking, which may be facilitated by accounting software packages. I n most aspects, this shift in payment methodology provides a significantly more efficient, reliable and safer alternative to the previous practice. As such the adoption and migration to online payments of suppliers has been swift and almost universal amongst both businesses and consumers. This also applies to consumer - peer to peer - payments.

However, electronic clearing house payment systems (e.g. BECS) used in banking systems were not originally designed with the intent for "self-service" customers to utilise them through online banking as these systems pre-dated the rise in the internet and online banking. Consequently they were designed to process payments from one party to another in a way, that, whilst sufficient for the original purpose, are not fully sufficient for the way that they are currently being used. In particular one such area where an issue arises is the way in which the system determines the destination account for a payment to be successfully completed. The system was designed to only rely on two key pieces of information in order to identify the destination account, the first information to identify the banking organisation and the second information to identify the individual account. These are what are known in Australia as the BSB and the account number. (BSB refers to the Banking organisation, the Australian State the account is held, and the Branch the account is held.) Other countries may refer to "routing" or "sort" codes etc. The systems were not designed to cross check the account number and BSB with the account holder's name. The insufficiency of the solution manifests as a security hole in the process. This is due to the fact that the bank and clearing house does not (and outside of bank's own customer accounts, cannot) cross check that the account number and BSB are in fact the correct account number and BSB for the account name that has been entered. E.g. If a payer enters the following payee name, BSB and account number and amount into their online banking screen:

Account Name BSB Account Number Amount Paid

Bob Smith 032-032 12345678 $500.00

The online banking system and the clearing house payment system ignore the Account name completely and will make the payment of $500 to the specified BSB and

Account Number irrespective of whether those account detail do in fact belong to Bob Smith or not. Some banks warn the user about this on the payment screen - eg below is the text shown on a major Australian Banking screen:

It is important you check that the BSB number and account number you have entered are correct because payments are processed using the BSB number and account number only, without checking the account name. Funds may be credited to the account of an unintended recipient if the BSB number and account number are not correct. It may not be possible to recover funds from an unintended recipient.

Not all banks display this warning and despite the warning most users of the systems still do not realise nor fully understand the consequences of this. This can be exploited by parties intent on fraud.

One known method of perpetrating fraud takes advantage of the fact that most medium to large business pay their suppliers (and staff) through online banking payment systems. The way this is usually done is by setting up payments inside their accounting package which then creates and exports a special Banking Payment File known as an ABA file in Australia. ABA is an example of an Australian banking file format, other file formats are used in other countries, however these typically suffer from the same problems and limitations as experienced in Australia as described. Typically a com pany employee, usually a bookkeeper logs into the companies online banking account, an imports the ABA file into the online banking system. The ABA file contains an entry for every payment that is to be paid. Each entry contains (amongst other things) the Account Name, BSB and Account Number and amount. Typically the employee has the rights and permissions to upload the file but not the rights to "sign off" the payment. This means the payment will be pending in the online banking system until someone with higher authority logs into the online banking system (e.g. the CFO), reviews and accepts or rejects the payments. They normally do this by reviewing each payment item by reading the account name and the amount and decide if they wish to pay that supplier that amount - does it look like someone they deal with and is the amount reasonable for that supplier. Once they are accepted the ABA payment file is sent by the online banking software to the relevant clearing house for processing. The clearing house then either in real-time (e.g. in the UK) or in a batch (usually after hours) makes the payments.

An example of a fraud process is: an employee generates a false invoice that appears to come from a legitimate known supplier and enters it into the accounting software. The employee creates the ABA file as normal with legitimate supplier payees, accounts and amounts by exporting it from the accounting software. Once they have the ABA file, they change the BSB and Account number to one controlled by them . They then upload the file to the bank as usual. When the CFO reviews the payments, he/she has no way of knowing that the payment to a given supplier will in fact be sent to that supplier's legitimate account rather than a fraudulent account unless he/she manually checks every account number and BSB shown on the banking screen with an independently obtained verified account list of each supplier. Manually doing such checks would be extremely time consum ing to the point of being practically impossible for the typically very busy CFO and very error prone as the weekly payments for medium to large companies could run into the hundreds or thousands a week or month. Even if they did they would have to manually find a way to get the verified supplier account lists and keep it up to date. There is no such list available today.

In this example of a fraud the payments that appear to be made to what appear to be legitimate suppliers, will in fact be paid to the employees own fraudulent account. This is because even though the supplier account name is correct, the actual account number and BSB do not belong to that supplier and since the banking system ignores the account name when effecting payment, the payment will simply be made to the fraudulent account. As the original invoice was fake, the supplier is not expecting a payment so will not follow up on a "missing" payment. This kind of fraud is difficult to catch and usually goes undetected for extended periods of time and sometimes doesn't get detected at all until the business collapses. Auditors sometimes catch this in an audit when they write to suppliers and ask them to confirm the amounts paid to them over the year matches the company's records. This approach helps a little but for companies with large numbers of suppliers, it is not possible to get every supplier to confirm the figures, suppliers may be out of business, may not have accurate or up to date records, or simply do not respond to confirmation requests etc.

There are numerous variations of such frauds that all take advantage of the lack of banks checking that the account number and BSB actually belong to the supplied account name.

Other common problems for EFT payments experienced by businesses include:

Incorrect account details entered - When entering account details into the accounting systems, the employee mistypes the account number or transposes some digits. In this case, when the payment is made, the funds are transferred into the wrong account by mistake. In some cases, if the erroneous account number doesn't exist, the payment will not go through and be returned to the business but if the account number does exist the payment will go through and may be very difficult and many times impossible to recover the funds. In particular, it is standard practice for banks to disclaim all responsibility for user errors in online transactions, for example with the warning provided on banking screens and/or account holder terms and conditions.

Incorrect payment amounts - Often a person mistypes the amount the supplier is to be paid. For example, instead of typing $100.00 they type $1000.00 or the decimal point doesn't register and the amount typed is $10000 - many banks will accept an amount without a decimal, assuming it to be simply zero cents.

Duplication - Many times an invoice is sent to a business both electronically and in the post. This can result in the same invoice erroneously being paid twice. Other causes of duplicate payments can be due to the same ABA file being uploaded and paid twice. There are various other scenarios where the same amounts are incorrectly paid twice.

Summary of the Invention

In accordance with a first aspect, the present invention provides an apparatus for facilitating verification of payment data, comprising a processor, memory and operating system for supporting computer processes, a data base arranged to store payment data for transaction accounts for a plurality of payees, a verification process arranged to receive payment information item(s) and check the payment information item(s) against the payment data stored in the data base to verify the payment data.

In an embodiment, the apparatus further comprises a message process arranged to generate messages to payee systems to prompt payees to provide payment information item(s) to the apparatus in order to verify payment data. For example, if the verification process finds that the payment data for a payee does not exist in the database, or is in error, a message is generated to go to the payee to request clarification of payee payment data. For example, clarification of an account number may be requested. The payee may be a supplier who wishes to be paid by their customers. It is therefore in their interest that the payee payment data on the database be correct.

In an embodiment, the message is generated with details of the payer included in the message, so that the payee knows the customer the payment data is being verified for.

The message may include a device, such as a hyperlink, linking a payee system to the apparatus for ease of response.

In an embodiment, the verification process is arranged to establish a verification rating for the stored payment data. The verification rating may be established in

dependence on the origin of the payment information item(s) used to verify payment data. For example, if the payment information item(s) originates from the payee, it is allocated a higher verification rating than if the payment information item(s) originated from a payer.

As payers and payees interact with the system , a database of payee payment data is built up. I n an embodiment, the apparatus may implement a portal that payers and payees can utilise for verification of payment data of payees.

The apparatus may be implemented by any available computing architecture. It may be implemented as a server (utilising server/client architecture). It may be im plemented as a standalone database.

The computer processes may be implemented as software modules supported by the hardware architecture and operating system . Firmware may be included to implement computer processes. Computer processes may be implemented purely in hardware eg using field programmable gate arrays. Any architecture may be used to implement the computer processes.

In accordance with a second aspect, the present invention provides a method for facilitating verification of payment data in a database storing payment data for transaction accounts of a plurality of payees, the method comprising the steps of receiving payment information item(s) and checking the payment information item(s) against data stored in the database, to verify the payment data.

In an embodiment, the method comprises a further step of sending messages to payee systems to prompt payees to provide payment information item(s) in order to verify payment data.

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

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

In accordance with a sixth aspect, the present invention provides an apparatus for facilitating payment transactions, comprising a processor, memory and operating system for supporting computer processes, an authentication process arranged to receive payee information item(s), compare the payee information items with stored payee account data, and provide an authentication rating to a payee system, the authentication rating, rating the authenticity of the payee information item(s).

In an embodiment, the authentication rating is provided to the payee system "in real time". A payer can therefore check, as they are paying payees, that the payee details are correct.

In an embodiment, the authentication rating is in the form of an alert to the payee system indicating that the payment information may or may not be authentic. In embodiments, the authentication process may authenticate one or more of the following:

• payment account details of a payee;

• amount of a payment to be made to a payee;

· an incidence of a payment. Is this a duplicate payment, for example?

In an embodiment, additional information may be delivered together with the authentication rating. The additional information may include messages from payees, eg sales messages.

In accordance with a seventh aspect, the invention provides a method of facilitating payment transactions, comprising the steps of receiving payee information item(s), comparing payee information item(s) with stored payee account data, and providing authenticating rating to a payee, the authentication rating validity of the payee information item(s).

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

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

In accordance with a tenth aspect, the present invention provides a data signal, comprising a computer program in accordance with the eighth aspect of the invention. According to a further aspect there is provided a method of authenticating an online payment from a payer to a payee, the method comprising the steps of:

receiving by an authentication module, a plurality of items of payment information relating to the payee, input by the payer;

initiating, by the authentication module in response to receiving the plural items of payment information relating to the payee, an authentication of the payee by

comparing the plural items of payment information of the payee with the contents of a record in an authenticated payment file, the authenticated payment file comprising a plurality of records, each record comprising a plurality of authenticated payment information items for a payee including a bank identifier, an account identifier and an account name;

identifying any discrepancy between the input payment information items and authenticated payment information items based on the comparison;

and,

generating an alert for output to the payer in response to identifying any discrepancy between the plurality of input payment information items and authenticated payment information items for the payee.

In an embodiment the input by the payer is provided via an authentication client operably associated with an online banking facility of the payer, and the method further comprises the steps of:

the authentication client transmitting the plurality of payment information items relating to the payee to the authentication module via a communication network; and

in response to any alert being generated the authentication module transmitting the alert to the authentication client of the payer via the communication network.

A further aspect provides an online payment authentication system comprising: an authenticated payment file stored in data memory the authenticated payment file comprising a plurality of records, each record comprising a plurality of authenticated payment information items for a payee including a bank identifier, an account identifier and an account name; and

an authentication module implemented in a processor configured to access the authentication payment file stored in data memory, the authentication module being configured to, in response to receiving a plurality of payment information items for a payee input by a payer:

compare the input plurality of payment information items for the payee with the authenticated payment information items in a record for the payee in the authenticated payment file;

identify any discrepancy between the input payment information items and authenticated payment information items based on the comparison; and generate an alert for output to the payer in response to identifying any discrepancy between the plurality of input payment information items and authenticated payment information items for the payee.

In an embodiment the authentication module is implemented in a communication network connected an authentication server, and the system further comprises one or more authentication clients configured to communicate with the authentication server via the communication network and provide an interface to enable payers to input payee payment information items for authentication and receive generated alerts. Brief Description of the Drawings

Figure 1 is a schematic diagram of an example of existing (prior art) online payment systems;

Figure 2 is an exemplary interface for the payment system of Figure 1 ;

Figure 3 is a schematic diagram showing an independent security facility that authenticates online payment according to an embodiment of the present invention;

Figure 4 is an exemplary interface of an authentication client of the independent security facility for authenticating online payment according to the embodiment of the present invention;

Figure 5 is an exemplary authenticate payment file generated by the independent security facility according to the embodiment of the present invention;

Figure 6 is a flow chart for verifying payment information of a payee with the payee according to the embodiment of the present invention;

Figure 7 is a flow chart for authenticating online payment according to the embodiment of the present invention;

Figure 8 is a block diagram of an authentication system in according to an embodiment of the invention;

Figure 9 is a flow chart of an example of a customer sign up process;

Figures 10 to 13 are examples of screen shots associated with a customer sign up process; Figure 14 is a flowchart of an example of a customer payment verification method;

Figure 15 shows an example of data displayed during an online payment without employing an embodiment of the invention;

Figure 16 corresponds to the example of figure 15 showing the data displayed during an online payment employing an embodiment of the invention;

Figures 17 and 18 show examples displaying additional information for the example of figure 16. Detailed Description

Embodiments of the present invention provide an authentication module or process configured to, in response to receiving a plurality of payment information items for a payee input to the authentication module by a payer, compare the plurality of payment information items for the payee with a record in an authenticated payment file. Based on this comparison, the authentication module identifies any discrepancy between the contents of the record and the input plurality of information items received form the payer. The authentication module generates an alert for output to the payer in response to identifying any discrepancy between the plurality of payment information items input by the payer and contents of the authenticated payment file record for the payee.

Embodiments of the present invention can reduce errors or potential fraud in online payment transactions by matching supplier (and other) bank account names with the true bank BSB and account number (or equivalent in other countries). Embodiments of the authentication system may be implemented to operate in a stand-alone fashion, for example an authentication module configured to operate on a business server or computer, possibly as part of or adjunct to accounting software, to authenticate payment details before these are processed through a banking portal. Alternatively, the authentication system can be implemented using client server architecture. Using client server architecture can provide significant advantages over a stand-alone implementation. Embodiments of the invention can be implemented as an additional service independent of existing accounting and online banking systems. For example, an embodiment may operate as an independent security facility, configured to verify data to be used for an online transaction, without participation or interference in the actual transaction itself. Thus enabling payers to obtain the advantage of improved security and checking for online transactions executed using existing banking systems. Embodiments of the invention may also be integrated with accounting software packages and online banking facilities.

An example of an embodiment of system structure of an independent security facility 300 is now described with reference to Figures 3 to 5. The independent security facility 300 is designed to authenticate an online payment by checking if payment information of a payee is correct. The independent security facility 300 is comprised of an authentication client 310 and an authentication server 320. In this embodiment the authentication client 310 is implemented using memory 31 1 , a processor 312 and an interface 314. The processor 312 may be for example a general purpose processor (for example of a personal computer or server), or dedicated hardware such as an application-specification integrate circuit (ASIC) or a field-programmable gate array (FPGA), or any other type of processor configuration. The processor 312 fetches and performs instructions stored in the memory 31 1 to authenticate the online payment based on payment information obtained from the online banking facility 140 and payment information stored in an authenticated payment file 313 having payment information that has been verified by payees or payers. Although the authentication client 310 is shown in Fig. 3 as a physical device, it may also be a computer program that includes machine-readable instructions running on a programmable device such as a programmable integrated circuit, a desktop, a laptop, a handset, etc., to perform the same function.

The memory 31 1 stores data and instructions used by the processor 312 to authenticate the online payment. The memory 31 1 also includes the authenticate payment file 313 having payment information that have been verified by payees. The authenticate payment file 313 is generated and updated at the authentication server 320 and can be sent to the authentication client 310 upon request of the authentication client 310 or

automatically. An exemplary authenticate payment file 313 is shown in Fig. 5.

The authentication client 310 is associated with the online banking facility 140 of the payer 160 through the interface 314 therebetween. The processor 312 can load the online banking facility 140 into the interface 314. As a result, the authentication client 310 functions as a container of the online banking facility 140. An exemplary interface 314 of the authentication client 310 is shown in Fig. 4. In Fig. 4, the online banking facility 140 is loaded into the authentication client 310 and the payer 160 can make an online payment with the authentication client 310 as he or she would do with the online banking facility 140.

The interface 314 in Fig. 4 also indicates functions performed by the independent security facility 300, i.e., "Authenticate" 41 1 , "Add payees" 412, "Update authenticate payment file" 413 and "Exit 414", which will be described in detail below.

The authentication server 320 includes a processor 321 and memory 322. The processor 321 may be for example a general purpose processor, an application-specification integrate circuit (ASIC) or a field-programmable gate array (FPGA), etc. The processor 321 fetches and performs instructions stored in the memory 322 to form a payee list for each payer that registers with the authentication server 320 and generates the authenticate payment file 313 for the payer without using security mechanism of the online banking facilities 140, 150 and the banks 120, 130. Although the authentication server 320 is shown in Fig. 3 as a physical device, it may also be a computer program that includes machine- readable instructions running on a programmable device such as a programmable integrated circuit, a desktop, a laptop, a handset, etc., to perform the same function. It may be supported in the "cloud".

The authentication server 320 is connected to a payer datastore 323, which may organise data stored therein as a database. The payer datastore 323 has a payer account created for each payer that registers with the authentication server 320. As shown in Fig. 3, for example, the authentication server 320 has a payer account 324 for the payer 160. The payer account 324 includes a payee list 325 that includes payment information of payees received from the payer 160.

The authentication server 320 generates or updates the authenticate payment file 313 with the payment information that has been verified by payees, which can be sent by the authentication server 320 to the authentication client 310 upon request of the authentication client 310 or automatically.

An example of a process for verifying payment information and authenticating an online payment according to the embodiment of the present invention is now described with reference to Figures 6 and 7.

Figure 6 is a flow chart for verifying payment information of a payee with the payee to generate or update the authenticate payment file 313. The payee 160 accesses the authentication server 320 and the authentication server 320 creates 610 the payer account 324 for the payer 160 upon request of the payer 160.

The payer 160 then logs in the payer account 324 through the authentication server 320. Alternatively, the payer 160 may log in the payer account 324 through the

authentication client 310 or a third party application without departing from the scope of the invention.

Once the payer 160 has logged in the payer account 324, the authentication server 320 is ready to receive payment information of payees from the payer 160 to form the payee list 325. The payer 160 enters the payment information of payees into the payer account 324. Alternatively, the payer 160 may import the payment information of the payees into the payer account 324 through a data file that is exported from the payer's accounting software such as MYOB, QUICKEN or QUICKBOOKS, or generated by the payer 160 manually. The data file may be an Excel, CSV or similar file including payment information of the payees.

Upon receipt 620 of the payment information of the payees, the authentication server

320 stores the payment information of the payees in the payee list 325. The processor 321 of the authentication server 320 then runs a verification process that checks the payment information provided for each payee in the payee list 325. First, the processor 321 checks completeness of the payment information 6301 . For example, if the BSB number of the payee 170 is not included in the payment information, the authentication server 320 considers the payment information as incomplete and prompts the payer 160 to complete the payment information of the payee 170 prior to verification (the "YES" branch of step 6301 ). Once the payment information is complete (the "NO" branch of step 6301 ), the processor 321 proceeds to check by for example the name of the payee 170. If the payee 170 is already in the authenticated payment file 313 and the payment information of the payee 170 received from the payer 160 is identical to the payment information of the payee 170 stored in the authenticate payment file 313, which means there is a match between the payment information of the payee 170 received from the payer 160 and the payment information of the payee 170 stored in the authenticate file 313 (the "YES" branch of step 6302), the verification process for the payee 170 ends 690.

If the payee 170 is a new payee or if the payee 170 is already in the authenticate payment file 313 but the payment information of the payee 170 received from the payer 160 does not match the payment information of the payee 170 stored in the authenticate payment file 313 (the "NO" branch of step 6302), the authentication server 320 sends 640 a verification request to the payee 170 for a new payee to verify the payment formation received from the payer 160. Where there is a mismatch between information stored in the authenticate file for the payee and the information supplied by the payer the authentication server 320 can send a notification of the mismatch to the payer advising them to check their file or check directly with the supplier. For example, the payer may respond after checking the payee details to correct a typographical error made by the payer, enabling the authentication for the payee to continue. In an embodiment the system can also optionally send a verification request to the payee, for example to check whether their details have changed or to advise the payee of a potential error by their customer.

The verification request is a web link to an interactive web page that allows the payee 170 to verify the payment information received from the payer 160. Alternatively, the verification request may be a physical mail or phone call to the payee 170 advising the payment information of the payee 170 needs to be verified.

Upon receipt of the verification request, the payee 170 responds to the verification request by verifying or denying the payment information and sends a verification response back to the authentication server 320. The verification response may also be sent from a third part without departing from the scope of the invention.

Upon receipt 650 of the verification response at the authentication server 320, the authentication server 320 determines whether the payee 170 has verified the payment information or not 660.

If the payee 170 has not verified the payment information received from the payer 160, then the payment information is kept in the payee list 325 without updating the authenticate payment file 313, and the verification process of the payee 170 ends 690 (the "NO" branch of step 660).

If the payment information has been verified by the payee 170 (the "Yes" branch of step 660), then the authentication server 320 generates (if there is no the authenticate payment file 313) or updates 670 the authentication payment file 313 with the verified payment information of the payee 170.

The above process is repeated for payment information of each payee in the payee list 325, such that the authentication client 310 has the updated authenticate payment file 313 for authenticating online payment. The authenticate payment file 313 shown in Fig. 5 includes verified payment information of both business payees and person payees.

Once the authenticate payment file 313 is generated or updated with the verified payment information, the authentication server 320 sends authenticate payment file 313 to the authentication client 310 automatically or upon request of the authentication client 310.

Fig. 7 is a flow chart for authenticating online payment with the authentication client 310. The online banking facility 140 is associated 710 with the authentication client 310 through the interface 140 of the authentication client 310. As described above, the online banking facility 140 is typically implemented as a web-based application operating in an Internet browser application such as Internet Explorer, Google Chrome, Firefox, etc. And the online banking facility 140 is typically coded by HTML and script languages. In this case, the interface 314 may be a software interface implemented by programing tools such as C++/C, Component Object Model (COM), HTML and script languages, etc.

When the payer 160 needs to make an online payment to the payee 170, the payer 160 launches the online banking facility 140 or the authentication client 310. The processor 312 in the authentication client 310 loads 720 the online banking facility 140 of the payer 160 into the interface 314 of the authentication client 310 when either of the online banking facility 140 and the authentication client 310 is launched by the payer 160. As shown in Fig. 4, the interface 314 of the authentication client 310 contains the online banking facility 140 of the payer 160. As a result, interface and functions of the online banking facility 140 is integrated into the authentication client 310 and the authentication client 310 functions as a container of the online banking facility 140.

As the payer 160 enters for example payment information of the payee 170 manually into the online banking facility 140, the authentication client 310 obtains 730 the payment information from the online banking facility 140 by reading its interface such as a web page. Alternatively, the payer 160 may also import the payment information of the payee 170 into the online banking facility 140 through a data file having the payment information of the payee 170. The data file may be an Excel csv or similar file generated from the payer's accounting software or by the payer 160 manually. In this case, the authentication client 310 may obtain 730 the payment information of the payee 170 by reading the data file.

The payer 160 clicks on the "Authenticate" 41 1 before actually paying the payee 170 by clicking on the "Pay" on the interface the online banking facility 140, then the

authentication client 310 compares 740 the payment information obtained from the online banking facility 140 with payment information in the authenticate payment file 313 to check if there is a match 750 between the obtained payment information and the payment information in the authenticate payment file 313. If there is a match, then the authentication client 310 authenticates 770 the online payment to the payee 170, which means the payment information has been verified by the payee 170 and the payer 160 is able to make the online payment to the payee 170 safely.

If there is no match, the authentication client 310 provides an error/alert report allowing the payer to take follow up actions. For instance, it may invoke the process shown in Figure 6 to verify the payment information by clicking on the "Add payees" 412 or simply reports to the payer 160 by sending the payer 160 a message indicating such a mismatch 760.

Where necessary, the payer 160 can click on the "Update authenticate payment file" 413 to request for the updated authenticate payment file 313 with the authentication server 320 to authenticate the online payment.

It will be appreciated by persons skilled in the art that numerous variations and/or modifications may be made to the invention as shown in the specific embodiments without departing from the scope of the invention as broadly described. For example, the authentication client 310 does not necessarily store the authenticate payment file 313; instead, the authentication client 310 may send the obtained payment information to the authentication server 320 for authentication and receive the outcome of the authentication from the authentication server 320. Moreover, the payer 160 does not necessarily need to click on the "Authenticate" 41 1 on the interface 314 of the authentication client 310 to check if the payment information has been verified; instead, the process 312 of the authentication client 310 can automatically perform such a check when it detects that the payer 160 clicks on the "Pay" button on the interface of the online banking facility 140.

An embodiment of the system is further configured to build and maintain one or more authenticated payment files. Different files can be used to store information for payees who's information has been verified to a different degree, and thus different files used to differentiate levels of trust in the information stored therein. An example of a further embodiment of the invention will now be described which provides two authenticate payment files having different degrees of verification, referred to as a whitelist and greylist respectively with the whitelist indicating a higher degree of verification and trust. In the following description the following definitions are used:

Customer - The business making payments that wish to reduce fraud and errors where making payments to Suppliers (payees).

Supplier - individuals or companies that provide goods or services to the Customer (payer) in return for payment.

Authentication Server - A server running software implementing functionality of the invention and storing supplier verified and other data, this embodiment is implemented using "Software as a service" infrastructure. Authentication Client - The software that a customer installs on their device, typically as a "Browser Extension", for example Chrome Browser Extension or "Browser helper object (BHO)".

Whitelist - This is a list of suppliers with their account names, BSB and account numbers that have been checked by the relevant supplier and verified to be correct. For example, the supplier has checked that the BSB and account number represent their account that they receive payments into and that the account name is the exact account name as it appears on their bank statement.

Greylist - This is a list of suppliers with their account names, BSB and account numbers that have not yet been checked by the relevant supplier and confirmed to be correct however the account details have been verified by a verification process by being provided by more than 1 independent customer and been matched against each other. Because 2 or more independent customers have the same details, the level of confidence that they are correct is very high because it would be extremely unlikely for a fraud of this nature to be perpetrated simultaneously to 2 independent organisations and even more so if there are more than 2 matches.

An example of this system 800 embodiment is shown in figure 8, comprising an authentication server 810 in data communication with memory 820 storing authenticated payment files, and in this embodiment the authenticated payee details are differentiated into a whitelist 830 and greylist 840 based on degree of verification. Customers (payers) access the system via the communication network using authentication client 850a-c, for example implemented as a software application running on a customer's server, PC or other network connected device. The application server 810 is also configured to communicate with suppliers (payees) 860a-c via the communication network in this embodiment.

An example of a process for customer sign up and supplier verification is illustrated in the flow chart of figure 9. Typically a Customer signs up by registering 910 on the Web site and providing relevant information (although this can be done in other ways too). The client application 850a may be provided as a web page or an application downloaded as part of the registration step 910.

The customer then provides their supplier information 915 to the application server

810. For example, the customer 850a exports their supplier file 880a from their accounting package (or other lists e.g. spreadsheet) and supplies to the application server 810 (via uploading to the website) or other mechanism e.g. Secure FTP or Secure email etc. The supplier file typically contains, the list of all their suppliers, and payment information items, such as each supplier's Bank Account Name, BSB and Account Number, as well as the relevant supplier's email address, the supplier's accounts person's name, and other relevant fields. (The abovementioned fields are not necessarily all required, nor is it necessarily exhaustive.)

The authentication server 810, can do some processing 920 of the file 850a to check it for anomalies, format errors, duplicate entries, missing entries etc. This processing can also include converting file format or data entries to a common format for use by the application server.

The authentication server 810 then compares 925 the new Supplier data 880a against the already existing "Whitelist" 830. It should be appreciated that if data for a supplier matches that already stored in the whitelist, the authentication server 810 has already verified the payee data for this supplier.

The following steps can be performed to verify payee details for suppliers not on the whitelist. These steps can optionally be performed at the time the supplier list 880a is uploaded or at the time when a customer seeks to make a payment to the supplier.

The following steps can be performed iteratively for each supplier not already verified and on the white list. The supplier(s) for verification is chosen 930, either in response to a pending payment input by the customer at the client application or automatically by the Authentication server. For example, the Authentication server may sequentially contact each supplier not already on the whitelist to verify their payee data. In this embodiment authentication server 810 generates 935 and sends emails to the customer's supplier's 860a-c asking the supplier to check their bank details that Authentication has on file for them. The form of the email is important so it is not considered as Spam or a scam. In order to reassure suppliers that the email is genuine, there are a number of specific steps that can be taken, for example:

a. Formulate the email in a manner such that the email is sent on behalf of the supplier's customer. This means that the reply to address is that of the usual customer accounts person's email address.

b. Include in the email the last x (usually x would be 3) digits of the supplier's bank account number that the customer has on file.

c. Include in the email the customer and supplier's company names as well as the personnel names of the Customer accounts person the Supplier is used to dealing with together with the name of the Customer CFO (or other senior finance person) as well as the relevant phone numbers of the above personnel.

d. An explanation of the problem & why the supplier is being asked to do this task. e. An incentive to make the supplier wish to perform this task as soon as possible. There are many forms that this can take, from putting the supplier on the "priority" ie "first to be paid" list to referrer fees etc.

f. Instructions on how to complete the process.

The following process occurs for each supplier not already on the white list when the respond to the verification request 940. In response to the verification request email the supplier 860a then either clicks on the link in the email or enters the URL provided into their browser. This takes them to the authentication system website where they are taken through the simple steps required to validate their account details and input verification data to the authentication server via the web site 940. Some examples of supplier verification screen shots are shown in figures 10 to 13. For example, as shown in figure 10, the supplier is asked to enter the reference number that they were provided in their email and to click proceed. Then the supplier is shown, figure 1 1 , the BSB number together with the last 3 digits of the account number that the customer has on file for them . They are asked to fill in the missing digits (if what they have been shown so far is correct) or to click on the checkbox to say that the details are incorrect. Figure 12 shown an example of a screen for incorrect details, if the bank details are not correct 945 they click a button to advise the Authentication server there is an error, in response to this button click the supplier is advised to contact the Customer 950. If the data is incorrect 960 the authentication server may also contact the customer to advise of the error 955.

If the details were correct and the supplier entered the rest of the bank details correctly 960, so they match those supplied by the customer, they will be shown the screen in figure 13. The Supplier is then asked to confirm the Account name 960 is exactly what is shown on their bank statement, correct it if necessary, check the checkbox and click on the Confirm button. If the details are all verified as correct the supplier is added to the white list 970. If the account number details are correct 945 but the account name details are incorrect 960 and the supplier enters a correction the correction is recorded 965 in the supplier details added to the white list 970. This completes the verification process for the supplier. The result of the process on the authentication server is to add the confirmed or corrected entry to the authentication whitelist 970.

A verification notification is prepared 980 for the customer indicating the correct verification and advising of any account name error to enable the customer to correct the date in their records. The notification of the verification outcome is sent to the customer 990. This may be provided in a detailed report or data communication consolidating verification information for a plurality of suppliers. Alternatively, a verification notification may be sent separately for one or more suppliers. Whether verification notifications are consolidated or sent individually may be based on the verification outcome. For example, in an embodiment a verification error notice message may be sent for an individual supplier, and successful verification notifications (with or without corrections) may be consolidated into a single communication.

Further optional verification processes can also be performed periodically by the authentication server or in response to an administrator input. For example, other Customer supplier lists held by authentication server can be compared/matched against the whitelist in order to determine if any common Suppliers have been added to the whitelist because if a Supplier has validated their account for one Customer, they no longer need to be asked to validate for other Customers. Making inclusion on the whitelist desirable for suppliers. Comparing supplier lists against the whitelist may be done for all customer supplier lists.

Customers supplier lists can also be periodically also matched against all other Customer supplier lists to determine if there are any common Suppliers who have not yet validated but due to them being common to more than one Customer supplier list and identical, they can be added to the Grey List.

At the end of this process or on a periodic basis, the Customer is provided with a

Supplier report of the result to date of the verification Process. This report can contain for example information about which Suppliers have verified their accounts, which have reported them as correct, which are on the grey list, which are incorrect and what the correct name should be, which are missing or have invalid emails etc.

An important advantage of this embodiment of the invention is the ultimate production of a White and Grey list that covers all suppliers in the given Country. As this progresses, the lists become similar to the "whitepages" but are a "whitepages" of Supplier bank accounts in the country. Once this is established, it can form the basis for a Country wide Supplier "portal" where ultimately any business taking on a new Supplier, can direct the Supplier to this portal to simplify and dramatically improve the security around onboarding new Suppliers and their bank accounts. Numerous other services can then be offered such as vetting of Suppliers against eg "blacklists" whereby other customers that may have suffered fraud add the Supplier to the "blacklist". A benefit to Suppliers results from them only having to provide their Bank Details to the authentication system and all current and future customers get verified details such that they can be confident any payments made to the Supplier will be made to the correct account. If a supplier then needs to change their bank account they only need to update it on the Portal and this will result in all their Customers being notified and warned when they next try and make a payment to the old account. This is a pragmatic solution to the Reserve Bank's goal of pushing Banks to implement some form of Account Number Portability.

An example of a customer payment process using the system of figure 8 is discussed below. Typically Customers make payments to suppliers periodically eg Weekly, Fortnightly Monthly etc. A process for customer payment is shown in figure 14, this aspect of the invention deals with providing the Customer assurance at the point of Payment that the Account Name they see on the Bank screen are indeed tied to the BSB and Account number of the Supplier into which the Supplier due funds are to be paid. A registered authentication system customer 850a downloads and installs the authentication client software onto their device eg from a Browser store such as the Chrome Store or Apple Store etc. The authentication client can be configured to operate as an extension of the customer's accounting or online payment software. This may be done as part of the registration process discussed above or as a separate action. The customer enters their authentication system Username and Password into the authentication client software 1410. In step 1420 the

Customer follows their normal Supplier Payment process, for example an employee uploads an ABA file to their online banking system and the senior finance person later logs in to check and "sign" the payments for them to be paid.

When the Customer Senior Financial Person navigates into the relevant payment page, the authentication client determines they are on that page and sends the Supplier account payment information such as Account Name, BSB and Account Number for each Supplier (including optionally the amount and description) to the authentication server. This is sent together with the Customer's login credentials or security Tokens that were previously entered into their authentication client running in their browser.

It should be noted that an advantage of embodiments of the invention is that these credentials are independent of Bank authentication credentials or tokens. Embodiments of the present invention can - and in a preferred embodiment are - implemented independently of the banking systems. For example, this functionality can be implemented entirely in authentication client and does not require the relevant bank to make any changes to their system whatsoever.

The authentication server 810 receives the data sent to it from the authentication client, authenticates the Customer login credentials and checks the Account details sent against the authentication Whitelist and Greylists 1430. The results of this check are returned to the authentication client which can cause an indication of the verification result on the payment page. For example, the authentication client extension can display relevant "Thumb" icons in the browser for the user to see. (Note simple displaying of icons or data in this way is known technology used by many extensions such as "Ad Blocker" however the real time checking of Account Names and Numbers against Supplier validated white lists inside a bank payment screen and warning of possible fraud has never been done before.).

The authentication client extension displays additional information to the person approving the payment. An example of a payment screen (taken from a real major

Australian bank) showing what they would see if they didn't have the authentication client extension is shown in figure 15. Figure 16 is a screen shot of what they would see if they do have an authentication client extension. (Note the use of an ABA file for payment is just one example of a payment process. This invention extends to other non ABA style payments eg one off or recurring "Pay Anyone" type payments to a single supplier or multiple suppliers.) Note that this same approach can also be applied to other Banks or Financial Services that provide payment facilities. Additionally this is not restricted to suppliers, it could include employees or individuals.

As seen in figure 16, the authentication client extension adds in an icon of a "thumbs up" (green) or "thumbs down" (red) to indicate whether the Name shown has been verified to be the correct name for the shown account details or not. "Thumbs up" mean it is verified as correct and "Thumbs Down" means it is not what the Supplier has said it should be. If the user hovers over each "Thumb" more information can be presented to the user, some examples are shown in figures 17 & 18. For example hovering over a green "thumbs up" can show a comment verified. Further information may also be displayed in some embodiments for example the date of latest whitelist verification for the supplier or indicating that the verification is based on the grey list.

For a "Red Thumbs Down" the correct account name is shown in figure 18. In this example the account the Customer had was missing the word "John" from the Account Name.

The number and colours of icons can obviously be more than the ones shown and the messages can also be more than the ones shown depending on the information the authentication server has on each particular supplier. These messages could also be extended in further embodiments to allow Suppliers to provide the authentication server with messages or "special offers" to be shown to the Customer at the point of payment. For example, a supplier may provide an "our banking details have changed" message to be displayed by the authentication client extension where a mismatch occurs due to a customer using obsolete payment data. Alternatively "special offers" may be shown in a message displayed when hovering over a correct verification icon or a different icon may be used to indicate positive verification and special offer availability. This is a unique never before available channel for Suppliers to communicate with their Customers.

The user can then decide whether to proceed with payment or not and any other follow up action he/she may need to take. If a name is similar or simply truncated, the user may choose to tell the authentication client extension that the name is OK and not to warn him/her again. In this case the authentication client extension will send that permission to the authentication server and this will be incorporated as a "permissible alias" for that supplier and Customer. (There can be multiple aliases per supplier and different Customers could have the different aliases for the same Customer.) The next time the Customer does a payment, he/she will not be warned with eg a Red Thumb for that Supplier if the details are not exactly correct but are a valid Alias.

Each Payment run by each authentication system Customer, will initiate such a payment details scan/check on the authentication server.

Embodiments of the authentication server can maintain records of these scans such as the last scan date, the results of the scan etc for later Audit purposes. Additionally the authentication server can store other information such as the last (or all) payment amounts, the average amount, the mean, the range etc. This information can be used to provide additional functionality and further warn Customer's about to make a potentially incorrect payment. The authentication server may compare previous transactions to identify potential errors - for example, that the customer already paid this exact amount to the specified supplier the previous day so it could be a duplicate payment. In another example, the Customer could also be warned that the payment they are about to make is an order of magnitude higher than the normal payments made to that supplier, indicating a possible error in entering the amount eg inadvertently adding an extra zero to a $1 000.00 payment to instead incorrectly make it $10 000.00. Many other such additional checks, warnings and information can be provided to the customer.

Note that Supplier emails can be sent in addition to the initial optional Supplier emails as described above during initial verification, or instead of those emails. For example, when each Customer makes a payment run (which results in an authentication system payment details check), an email can be sent to each Supplier about to be paid. For Suppliers that haven't yet verified their details, this could remind them to do so or warn them that the customer may withhold payment until their details are verified. Sending a verification email such as this at this point, is even more likely to be considered valid by the Supplier (as they are expecting a payment) and consequently more likely to respond to it. For other suppliers, they can be emailed a remittance advice so they immediately know that have been (or are about to be) paid so they do not have to follow up with the Customer to ask for example when they will be paid. By sending emails at this time to Suppliers aids in building the viral nature of the authentication service as Suppliers prefer being notified of payments and reducing the chance of fraud and so may themselves be reminded and encouraged to both sign up their company as an authentication system Customer as well as recommend the authentication system to their other Customers.

Embodiments of the authentication system could also be configured to authenticate person to person payments. In such embodiments individuals sign up for the authentication service and when individuals pay each other the same or similar processes can be followed to check the accounts and payment details. Embodiments may be integrated with online banking facilities provided by banking institutions to enable individuals to benefit from the authentication service in addition to the regular online payment facility features.

The authentication client implementation is not restricted to using Browsers on a computer. The authentication client could be implemented on other devices eg mobile devices, phones, tablets etc and using applications instead of extensions.

A key advantage of some embodiments of the invention is having the Whitelist of Suppliers plus Customer information to minimise fraud and errors in Customer Supplier relationships. Additional Security elements can be added eg Customer's reporting fraud experiences linked to particular Suppliers and Suppliers reporting non-payment or fraud experiences with Customers

A key advantage of embodiments of the invention is that this authentication system for the first time solves the problem of checking bank account names against account BSB and account numbers and does so at the point of payment so allows for no gap in the process. This can significantly reduce or even eliminate frauds perpetrated using this attack vector.

The authentication system in accordance with embodiments of the invention provides a form of technical "insurance" to Financial officers in companies against potential frauds as discussed above and in some sense correlates to the way anti-virus programs protect employee computers from viruses. Up till now there was no way to technically prevent this fraud in this way however once the system is available. It would almost be negligent for a CFO to not employ the authentication system.

Once running, the authentication system can become the Portal for all Suppliers, Consumers, Customers etc. to interact with respect to securely providing and checking account details.

Embodiments of the authentication system can also be extended to checking cross border payments e.g. Telegraphic Transfers etc. For example, by storing additional payment information items in the authentication file defining international banking and/or telegraphic transfer details. Such addition payment information items can be verified using a process as described above.

Payment data can also be analysed and the analysis provided back to Customer's or

Suppliers etc

It should be understood that the techniques of the present disclosure might be implemented using a variety of technologies. For example, the methods described herein may be implemented by a series of computer executable instructions residing on a suitable computer readable medium. Suitable computer readable media may include volatile (e.g. RAM) and/or non-volatile (e.g. ROM, disk) memory, carrier waves and transmission media. Exemplary carrier waves may take the form of electrical, electromagnetic or optical signals conveying digital data steams along a local network or a publically accessible network such as the internet.

It should also be understood that, unless specifically stated otherwise as apparent from the following discussion, it is appreciated that throughout the description, discussions utilizing terms such as "sending" or "authenticating" or "obtaining" or "determining" or "storing" or "receiving" or "paying" or "transferring" or the like, refer to the action and processes of a computer system, or similar electronic computing device, that processes and transforms data represented as physical (electronic) quantities within the computer system's registers and memories into other data similarly represented as physical quantities within the computer system memories or registers or other such information storage, transmission or display devices.

Claims

1. A method of authenticating an online payment from a payer to a payee, the method comprising the steps of:

and,

2. A method according to claim 1 , wherein input by the payer is provided via an authentication client operably associated with an online banking facility of the payer, and the method further comprises the steps of:

3. The method according to claim 1 or 2, further comprising loading the authentication client automatically in response to the payer accessing the online banking facility.

4. The method according to any preceding claim, wherein the authenticated payment file is assembled and checked by a trusted third party.

5. The method according to any one of claim 4, wherein the trusted third party is the provider of the authentication module.

6. The method according to any preceding claim, wherein the authenticated payment file includes items of payment information regarding a payee that have been verified by either the payer or the payee.

7. The method according to claim 6, wherein the authenticated payment file includes details of the payee that are still pending verification, and in this case the details are flagged as 'verification pending'.

8. The method according to any one of claims 4 to 7, further comprising the initial steps of:

receiving by the authentication module for each one of one or more payees, a plurality of items of payment information relating to the payee; and

for one or more payees:

sending a verification request to the payee to verify the payment information; and in response to receiving a verification response from the payee to verify the payment information, updating verification status in the authenticated payment file for the payee.

9. The method according to any one of the preceding claims wherein the payment information of the payee in the authenticated payment file comprises the payee's BSB number, bank account number and the payee's name.

10. The method according to claim 9, wherein the payment information of the payee further comprises the date of birth of the payee.

1 1 . The method according to claim 8 or 9, wherein the payment information of the payee also comprises an ABN (Australian Business Number).

12. The method according to any one of the preceding claims, wherein the step of automatically alerting the payer before the payment is made, involves the presentation of an online report.

13. A computer software program, including machine-readable instructions, when executed by a processor, causes the processor to perform the method of any one of the preceding claims.

14. An online payment authentication system comprising:

an authenticated payment file stored in data memory the authenticated payment file comprising a plurality of records, each record comprising a plurality of authenticated payment information items for a payee including a bank identifier, an account identifier and an account name; and

identify any discrepancy between the input payment information items and authenticated payment information items based on the comparison; and

generate an alert for output to the payer in response to identifying any discrepancy between the plurality of input payment information items and authenticated payment information items for the payee.

15. A system as claimed in claim 14, wherein the authentication module is implemented in a communication network connected an authentication server, and the system further comprises one or more authentication clients configured to communicate with the authentication server via the communication network and provide an interface to enable payers to input payee payment information items for authentication and receive generated alerts.

16. A system as claimed in claim 15, wherein the one or more authentication clients are further configured to launch automatically in response to access of an online banking facility by a payer.

17. An apparatus for facilitating verification of payment data, comprising a processor, memory and operating system for supporting computer processes, a data base arranged to store payment data for transaction accounts for a plurality of payees, a verification process arranged to receive payment information item(s) and check the payment information item(s) against the payment data stored in the data base to verify the payment data.

18. An apparatus in accordance with claim 17, further comprising a message process arranged to generate messages to payee systems to prompt payees to provide payment information item(s) to the apparatus in order to verify the payment data.

19. An apparatus in accordance with claim 18, wherein the message comprises a device automatically linking the payee system back to the apparatus to provide the payment information item(s).

20. An apparatus in accordance with the claim 18 or 19, wherein the message is formulated such that it appears to be sent on behalf of a payer associated with the payee.

21 . An apparatus in accordance with any one of claims 17 to 20, wherein the verification process is arranged to establish a verification rating for the stored payment data.

22. An apparatus in accordance with claim 21 , wherein the verification process establishes the verification rating in dependence on the origin of payment information item(s) used to verify payment data.

23. An apparatus in accordance with claim 22, wherein the verification process is arranged to establish a higher verification rating if the payment information item(s) used to verify payment data is received from a payee, than if it is received from a payer.

24. An apparatus in accordance with any one of claims 18 to 23, comprising

communication process enabling the apparatus to operate as a portal enabling access via remote systems to verify and obtain payee payment data.

25. A database, arranged to store payment data for transaction accounts of a plurality of payees, verified in accordance with the apparatus of any one of claims 17 to 24.

26. A method for facilitating verification of payment data in a database storing payment data for transaction accounts of a plurality of payees, the method comprising the steps of receiving payment information item(s) and checking the payment information item(s) against data stored in the database, to verify the payment data.

27. A computer program, comprising instructions for controlling a computer to implement an apparatus in accordance with any one of claims 17 to 25.

28. A computer readable medium, comprising a computer program in accordance with claim 27.

29. A data signal, comprising a computer program in accordance with claim 27.

30. An apparatus for facilitating payment transactions, comprising a processor, memory and operating system for supporting computer processes, an authentication process arranged to receive payee information item(s), compare the payee information items with stored payee account data, and provide an authentication rating to a payee system, the authentication rating, rating the authenticity of the payee information item(s).

31 . An apparatus in accordance with claim 30, wherein the authentication rating is in the form of an alert to the payee system, to indicate that the payee information item(s) may or may not be authentic.

32. An apparatus in accordance with claim 30 or 31 , wherein the authentication rating is arranged to relate to one or more of the following:

payment account details of a payee;

an amount of a payment to be made to a payee;

an incidence of a payment.

33. An apparatus in accordance with any one of claims 30 to 32 comprising a communications process arranged to enable communication of payee messages to a payer system.

34. A computer program, comprising instructions for controlling a computer to implement an apparatus in accordance with any one of claims 30 to 33.

35. A computer readable medium, providing a computer program in accordance with claim 34.

36. A data signal, comprising a computer program in accordance with claim 34.