Computer system and method for managing risk within payment transactions

Abstract

A computer system (10) and method for managing risk within transactions between a payee and a payor, wherein the payor receives a payment request via an electronic messaging communication channel, comprises a payor registration module (14), a communication module (16), a payment information verification module (18) and a database (20). The module (14) captures particulars of the payor and generates a unique payor code which is sent to the payor via a secondary channel. When the payor receives an invoice from the payee via email, the payor sends the invoice to the computer system (10) for verification. The module (18) requests or conducts an analysis of the invoice by comparing the payment particulars with valid payment particulars obtained from a trusted third-party data source (22). If the analysis reveals that the payment particulars in the invoice are correct, the module (18) generates and sends a validation notification including the payor code, confirming the correctness of the particulars, to the payor.

Description

[0001] COMPUTER SYSTEM AND METHOD FOR MANAGING RISK WITHIN PAYMENT TRANSACTIONS

[0002] FIELD OF INVENTION

[0003] This invention relates to a computer system for managing risk within payment transactions. The invention also relates to a method for managing risk within payment transactions. More specifically, the computer system and method relate to managing risk within a payment transaction between a payee and a payor, wherein the payor receives a payment request purportedly from the payee, containing payment particulars including bank details, in an electronic document via an electronic messaging platform such as electronic mail (“email”).

[0004] Any reference herein to an “electronic document” must be interpreted to mean a reference to any electronic file containing payment particulars of a payee, such as a plain text email body or subject line, an invoice in electronic PDF or Microsoft Word format, an electronic scanned document, an electronic image or any file confirming the payee’s bank account particulars, etc.

[0005] Any reference herein to “payment particulars” must be interpreted to mean a reference to bank account particulars which may be included in plain text, a document or represented by or contained in a token or a code such as an alphanumeric code or quick-response code, or the like, which may be used to extract bank account particulars.

[0006] BACKGROUND OF THE INVENTION

[0007] In a typical payment transaction involving a payment between a payee and a payor, the payee may send an electronic document requesting payment and containing payment particulars, to the payor, typically via email.

[0008] The electronic document typically includes the payee’s personal particulars, i.e. , the name, address, registration number of the payee if the payee is a registered legal person, the amount to be paid and the payment particulars. After receiving the email from the payee, the payor typically captures the payee’s banking particulars as reflected in the electronic document attached to the email, on the payors’ banking platform. Once the payee’s banking particulars have been captured, the payor authorises payment of the amount reflected in the electronic document to the payee, via the payor’s banking platform.

[0009] Such payment transactions between a payor and a payee commenced by a payee sending the payor an electronic document for example, via email, have been subjected to high levels of fraud particularly in instances wherein such electronic documents are intercepted by a third-party fraudster. In a typical scenario of this nature, the payee’s or the payor’s email may be compromised by a fraudster, and, as a result, an email communication sent from the payee to the payor is intercepted by a fraudster which then amends the electronic document, replacing the payee’s payment particulars with the fraudster’s own payment particulars. The modified electronic document is then received by the payor, whereafter the payor unwittingly makes payment of the amount reflected in the electronic document into the fraudster’s bank account. This type of fraud is known as Authorised Push Payment (APP) fraud.

[0010] In another scenario, a fraudster may initiate the sending of an electronic document containing payment particulars, impersonating the payee. This type of fraud does not require the fraudster to intercept the email but rather relies upon the fraudster impersonating the payee in order to initiate a payment by the payor to a fraudulent bank account linked to the fraudster.

[0011] It is an object of the present invention to provide a method and computer system for enhancing the security of payment transactions and prevent fraudulent transactions of the abovementioned types from occurring.

[0012] SUMMARY OF THE INVENTION

[0013] According to a first aspect of the invention there is provided a computer system for managing risk within transactions between a payee and a payor wherein the payor receives a payment request containing payment particulars including bank details, purportedly from the payee, in an electronic document via an electronic messaging communication channel, the computer system including: a payor registration module including a data storage medium, which is operable to capture and record particulars of the payor, and to record a unique payor code associated with the payor, once the payor’s particulars are recorded; a communication module which is operable to send messages to the payor via a secondary communication channel which is different from the communication channel used by the payor for receiving the payment request; and a payment particulars verification module which is operable to:

[0014] (a) receive the electronic document issued by the payee, from the payor;

[0015] (b) request or conduct an analysis of the electronic document by comparing the payment particulars in the electronic document with valid payment particulars obtained from a trusted data source; and

[0016] (c) generate a notification of a result of the analysis, the communication module being operable, in response to generation of the notification, to send a message to the payor via the secondary communication channel, accompanied by the unique payor code, notifying the payor of the result of the analysis.

[0017] The trusted data source may be a third-party database containing bank details of the payee. In one embodiment of the invention, the computer system may be operable to access the trusted third-party database and extract the payee’s bank details in order to conduct the analysis. In another embodiment of the invention, the computer system may be operable to request the analysis of the payee’s bank details from a service provider or a bank, providing a bank account verification service.

[0018] In a particular embodiment of the invention wherein the payment particulars are contained in a token or code or the like, the payment particulars verification module may be operable, as a first step, to extract the payment particulars from the token or code or the like, prior to proceeding with step b) or to verify the token or code or the like, prior to proceeding to step c).

[0019] It will be appreciated that the message to the payor notifying the payor of the result of the analysis, may comprise the correct payment particulars and the unique payor code, without any further notification or information.

[0020] According to the second aspect of the invention there is provided a method for managing risk within payment transactions between a payee and a payor wherein the payor receives a payment request containing payment particulars including bank details, purportedly from the payee, in an electronic document via an electronic messaging communication channel, the method including: capturing and recording particulars of the payor; recording a unique payor code associated with the payor once the payor’s particulars are recorded; receiving the electronic document issued by the payee, from the payor; and requesting or conducting an analysis of the electronic document by comparing the payment particulars in the electronic document with valid payment particulars obtained from a trusted data source; and sending a message to the payor via a secondary communication channel, accompanied by the unique payor code, notifying the payor of the result of the analysis.

[0021] In a particular embodiment of the invention wherein the payment particulars are contained in a token or code or the like, the method may include, as a first step, extracting the payment particulars from the token or code or the like, prior to requesting or conducting the analysis, or verifying the token or code or the like, prior to notifying the payor of the result of the analysis. It will be appreciated that the message to the payor notifying the payor of the result of the analysis may comprise the correct payment particulars and the unique payor code without any further notification or information.

[0022] The trusted data source may be a third-party database containing bank details of the payee. In one embodiment of the invention, the method may include accessing the trusted third-party database and extracting the payee’s bank details in order to conduct the analysis. In another embodiment of the invention, the method may include requesting an analysis of the payee’s bank details from a service provider providing a bank account verification service.

[0023] The method may be computer-implemented. More specifically, the method may include providing the computer system as defined hereinabove in accordance with the first aspect of the invention, for implementing the method.

[0024] BRIEF DESCRIPTION OF THE DRAWINGS

[0025] Further features of the invention are described hereinafter by way of a non-limiting example of the invention with reference to and as illustrated in the accompanying diagrammatic drawings. In the drawings:

[0026] Figure 1 is a diagrammatic representation of a prior art conventional payment transaction between a payee and a payor wherein the payee requests payment from the payor via email;

[0027] Figure 2 is a diagrammatic representation of the prior art conventional payment transaction between the payee and the payor wherein the email is intercepted by a fraudster;

[0028] Figure 3 shows a schematic block diagram illustrating various the modules of a computer system for managing online transactions between a payee and payor, in accordance with the invention; Figure 4 is a diagrammatic representation illustrating the process of capturing and recording the payor’s particulars by the payor registration module of the computer system in accordance with the invention;

[0029] Figure 5 is diagrammatic representation illustrating a typical example wherein the payee sends an email to the payor requesting payment of an invoice;

[0030] Figure 6 is a diagrammatic representation illustrating the process by which the computer system conducts an analysis of payment particulars of the payee and responds with a validation message including the payment particulars;

[0031] Figure 7 is a diagrammatic representation illustrating the manner in which the computer system validates the payment particulars of the payee;

[0032] Figure 8 is a diagrammatic representation illustrating an example wherein an email attaching an invoice from the payee is intercepted by a fraudster;

[0033] Figure 9 is a diagrammatic representation illustrating non-validation of the payment particulars of the payee, and communicating the non-validation to the payor; and

[0034] Figure 10 is a diagrammatic representation providing an overview of the operation of the computer system and the method of managing a transaction between a payee and a payor in accordance with the invention.

[0035] DETAILED DESCRIPTION OF THE INVENTION

[0036] With reference to Figure 1 , a typical conventional prior art payment transaction between a payee and a payor is illustrated wherein the payee requests payment from the payor via email. The payee (Alice) creates an invoice in a digital format and sends the invoice to the payor (Bob) requesting payment, via email, as an attachment to the email. The invoice includes the payee’s personal particulars, i.e., the payee’s name, address, registration number, the amount to be paid and the payment particulars of the payee.

[0037] After receiving the email from the payee, the payor captures the payee’s banking particulars as reflected in the invoice attached to the email, on the payor’s banking platform. Once the payee’s banking particulars have been captured, the payor authorises payment of the invoice amount to the payee, via the payor’s banking platform.

[0038] Figure 2 illustrates the manner in which an email communication sent from the payee to the payor is intercepted by a fraudster which then amends the invoice, replacing the payee’s bank account particulars (account ...6789) with the fraudster’s own bank account particulars (account ...1234). The modified invoice is then sent on to the payor, which unwittingly makes payment of the invoiced amount into the fraudster’s bank account.

[0039] With reference to Figure 3, the present invention relates to a computer system and a computer-implemented method for managing risk within transactions between a payee and payor wherein the payor receives a payment request containing payment particulars including bank details, purportedly from the payee, in an electronic document via an electronic messaging communication channel in the form of an email sent to the payor’s email address. The computer system in accordance with the invention, is designated by the reference numeral 10 and includes, broadly, a payor registration module 14, a communication module 16, a payment particulars verification module 18 and a database 20.

[0040] The payor registration module 14 is operable to capture and record particulars of the payor including particulars of a secondary electronic messaging communication channel which is different from the communication channel used for sending the payment request, and to generate a unique payor code once the payor’s particulars are recorded. In addition to recording particulars of the secondary electronic messaging communication channel, the payor registration module may be operable to capture and record additional particulars of the payor such as the name and address of the payor, and the payor’s identification number in the case of a natural person or registration number in the case of a legal person.

[0041] The payor’s particulars are stored in the database 20.

[0042] With reference to Figure 4, the payor’s (Bob) information is captured and recorded by the payor registration module 14 which then receives and records secure user- selected login particulars for Bob and generates a unique payor code such as “RED BOX”. The communication module 16 sends the unique payor code to Bob via a secondary channel such as a WhatsApp message to a mobile phone number which Bob has chosen as his secondary communication channel (i.e. different from the communication channel used for sending the payment request to Bob) for receiving communications from the communication module 16 of the computer system.

[0043] With reference to Figure 5, the payee (Alice) generates an invoice for services rendered to Bob and sends an email requesting payment and attaching an invoice, to an email address associated with Bob. The invoice includes Alice’s personal particulars, i.e. Alice’s name, physical address, company registration number, and banking details including the name of her bank, bank account number and the amount for which payment is requested. It will be appreciated that Applicant envisages that the payment particulars may also be represented by or contained in a token or a code such as an alphanumeric code or quick-response code, or the like, which may be used to extract bank account particulars, or the code may be verified directly.

[0044] With reference to Figures 6 and 7, Bob receives Alice’s email and the attached invoice and sends the invoice to the computer system 10 via the communication module 16, for verification of the information contained in the invoice. The payment particulars verification module 18 then requests or conducts an analysis of the invoice by comparing payment particulars contained in the invoice with valid payment particulars obtained from a trusted third-party data source 22. If the analysis reveals that the payment particulars in the invoice correspond with the payment particulars obtained from the third-party data source 22, the payment particulars verification module 18 generates a validation notification validating the correctness of the particulars.

[0045] The third-party source 22 may be a third-party database containing bank details of the payee. In one embodiment of the invention, the computer system 10 may be operable to access the trusted third-party database and extract the payee’s bank details in order to conduct the analysis. In another embodiment of the invention, the computer system may be operable to request an analysis of the payee’s bank details from a service provider providing a bank account verification service. Examples of such service providers providing bank account verification services, are Bankserv in South Africa or Yodlee in the United Kingdom, which provides a service which compares banking details provided by a customer to banking details on record in a database in order to determine whether the banking details provided by the customer match those in the records searched; and Account Verification Services which provides the service of conducting an analysis of banking information in order to establish the correctness of the banking information.

[0046] In response to generation of the validation instruction by the payment particulars verification module, the communication module 16 sends a validation message to Bob via WhatsApp (i.e. via the secondary electronic messaging communication channel which is different from the communication channel used for sending the payment request) to his mobile phone number, confirming the payee’s bank particulars, accompanied by the payee’s validated bank particulars and the unique payor code, i.e. RED BOX. As the validation message contains Bob’s unique payor code RED BOX, Bob knows that he can trust the validation message and proceeds to pay Alice’s invoice using the payee’s validated bank particulars reflected on the validation message.

[0047] It will be appreciated that in other embodiments of the invention, the message to the payor notifying the payor of the result of the analysis, may include the correct payment particulars and the unique payor code without any further notification to the payor. With reference to Figure 8, a scenario is described wherein Alice’s email is intercepted by a fraudster Mallory. Mallory amends Alice’s invoice, replacing the payee’s bank account particulars (account ...6789) with the fraudster’s own bank account particulars (account ...1234). The modified invoice is then sent on to Bob. Upon receipt of the email purportedly from Alice, Bob sends the invoice to the computer system 10 for verification of the information contained in the invoice. The payment particulars verification module 18 requests or conducts an analysis of the invoice, by comparing the banking particulars in the invoice with the banking particulars for Alice obtained from the trusted third-party data source 22. The analysis reveals that the banking particulars in the invoice do not match the banking particulars obtained from the trusted third-party data source and accordingly, the payment particulars verification module 18 generates a non-validation notification. In response to the generation of the non-validation instruction, the communication module 16 sends a WhatsApp message to Bob notifying him that the particulars are not correct and therefore not validated, accompanied by Bob’s unique payor code, i.e. RED BOX (see Figure 9).

[0048] Figure 10, provides a diagrammatic representation of an overview of the operation of the computer system and the computer-implemented method of managing risk within a transaction between a payee and a payor, as described hereinabove in accordance with the invention.

[0049] It will be appreciated that although reference is made in this example to a computer- implemented method, the steps of the method may be implemented without the use of the computer system described herein.

[0050] The Applicant believes that the computer system and method in accordance with the invention, will be effective in enhancing the security of payment transactions and prevent fraudulent transactions of the abovementioned type from occurring.

Claims

CLAIMS1 . A computer system for managing risk within transactions between a payee and a payor wherein the payor receives a payment request containing payment particulars including bank details, purportedly from the payee, in an electronic document via an electronic messaging communication channel, the computer system including: a payor registration module including a data storage medium, which is operable to capture and record particulars of the payor, and to record a unique payor code associated with the payor, once the payor’s particulars are recorded; a communication module which is operable to send messages to the payor via a secondary communication channel which is different from the communication channel used by the payor for receiving the payment request; and a payment particulars verification module which is operable to:(a) receive the electronic document issued by the payee, from the payor;(b) request or conduct an analysis of the electronic document by comparing the payment particulars in the electronic document with valid payment particulars obtained from a trusted data source; and(c) generate a notification of a result of the analysis, the communication module being operable, in response to generation of the notification, to send a message to the payor via the secondary communication channel, accompanied by the unique payor code, notifying the payor of the result of the analysis.

2. The computer system according to claim 1 , wherein the trusted data source is a third-party database containing bank details of the payee.

3. The computer system according to claim 2, wherein the computer system is operable to access the trusted third-party database and extract the payee’s bank details in order to conduct the analysis.

4. The computer system according to claim 1 or claim 2, wherein the computer system is operable to request the analysis of the payee’s bank details from a service provider or a bank, providing a bank account verification service.

5. The computer system according to any one of claims 1 to 3, wherein the payment particulars are contained in a token or code or the like, the payment particulars verification module is operable, as a first step, to extract the payment particulars from the token or code or the like, prior to proceeding with step b) or to verify the token or code or the like, prior to proceeding to step c).

6. The computer system according to any one of claims 1 to 5, wherein the message to the payor notifying the payor of the result of the analysis, comprises the correct payment particulars and the unique payor code, without any further notification or information.

7. A method for managing risk within payment transactions between a payee and a payor wherein the payor receives a payment request containing payment particulars including bank details, purportedly from the payee, in an electronic document via an electronic messaging communication channel, the method including: capturing and recording particulars of the payor; recording a unique payor code associated with the payor once the payor’s particulars are recorded; receiving the electronic document issued by the payee, from the payor; andrequesting or conducting an analysis of the electronic document by comparing the payment particulars in the electronic document with valid payment particulars obtained from a trusted data source; and sending a message to the payor via a secondary communication channel, accompanied by the unique payor code, notifying the payor of the result of the analysis.

8. The method according to claim 7, wherein the payment particulars are contained in a token or code or the like, the method includes, as a first step, extracting the payment particulars from the token or code or the like, prior to requesting or conducting the analysis, or verifying the token or code or the like, prior to notifying the payor of the result of the analysis.

9. The method according to claim 7 or claim 8, wherein the message to the payor notifying the payor of the result of the analysis, comprises the correct payment particulars and the unique payor code without any further notification or information.

10. The method according to any one of claims 7 to 9, wherein the trusted data source is a third-party database containing bank details of the payee.

11. The method according to claim 10, wherein the method includes accessing the trusted third-party database and extracting the payee’s bank details in order to conduct the analysis.

12. The method according to any one of claims 7 to 10, wherein the method includes requesting an analysis of the payee’s bank details from a service provider providing a bank account verification service.

13. The method as claimed in any one of claims 7 to 12, wherein the method is computer-implemented.

14. The method as claimed in any one of claims 7 to 13, wherein the method includes providing the computer system as claimed in any one of claims 1 to 6, for implementing the method.

Images