Fraud detection system automatic rule population engine

CROSS-REFERENCES TO RELATED APPLICATIONS

This application is a continuation application U.S. patent application Ser. No. 13/458,910, filed Apr. 27, 2017, which is a non-provisional application of and claims the benefit of priority of U.S. Provisional Application No. 61/481,139, filed on Apr. 29, 2011, which is herein incorporated by references in its entirety for all purposes.

BACKGROUND

As conducting transactions over the Internet has become increasingly popular, the problems and challenges that arise for merchants have also increased. Online transactions create greater difficulty in determining which transactions are legitimate and which transactions are fraudulent. Stolen payment data may be used by a fraudster to purchase goods or services from a merchant. The use of stolen payment data may not be immediately detected by the merchant and may not be known until a significant time after the goods or services have been provided to the fraudster. Thus, the resulting fraud can cost the merchant significant amounts of money in the form of lost revenue and lost stock.

Some merchants take it upon themselves to manually review each and every order and expend significant time and resources in order to determine whether transactions are legitimate or fraudulent. As transaction volumes increase, this becomes an increasingly unsustainable model for merchants. As a result, merchants may find it necessary to incorporate an automated fraud detection system into their transaction processing system.

Some fraud detection systems can include fraud detection rules that evaluate transactions and assist merchants in deciding whether a specific transaction should be accepted or rejected.

However, even with sophisticated fraud detection systems in place, a merchant can still be compromised and be responsible for the costs of fraudulent transactions (e.g. the loss of goods and/or the loss of consideration for those goods). For example, a fraud detection rule may have been intentionally or accidentally modified so as to accept transactions that would ordinarily not be accepted or to misidentify transactions that should be rejected. A merchant may need to modify its fraud detection rules, modify its merchant profiles, or create new merchant profiles to address these problems. However, if a merchant has established a large number of merchant profiles to meet its business requirements, managing their merchant profiles can become an unwieldy proposition.

Thus, new and enhanced methods of detecting fraudulent transactions while providing more efficient and time-saving merchant services has become increasingly necessary to provide greater security and functionality.

Embodiments of the invention address the above problems, and other problems, individually and collectively.

BRIEF SUMMARY

Embodiments of the present invention are related to systems and methods for generating fraud detection rules and merchant profiles in a fraud detection system configured to automatically populate merchant profiles with a user's set of core fraud detection rules.

One embodiment of the invention is directed to a method comprising providing fraud detection rules, by a server computer, where each fraud detection rule comprises at least one condition. A selection of fraud detection rules for a first merchant profile for a user is received at the server computer from a client computer. The method may further comprise associating, by the server computer, the selected fraud detection rules as a core fraud detection rules set for the user.

Another embodiment of the invention is directed to a server computer comprising a processor and a non-transitory computer-readable storage medium. The computer readable medium comprises code executable by the processor for implementing a method. The method comprises providing fraud detection rules, by a server computer, where each fraud detection rule comprises at least one condition. A selection of fraud detection rules for a first merchant profile for a user is received at the server computer from a client computer. The method may further comprise associating, by the server computer, the selected fraud detection rules as a core fraud detection rules set for the user.

Another embodiment of the invention is directed to a method comprising receiving, at a client computer, a plurality of fraud detection rules. The method may also comprise selecting, by the client computer, from the plurality of fraud detection rules, a set of fraud detection rules. The set of fraud detection rules may be associated with the user as a core fraud detection rules set.

Another embodiment of the invention is directed to a client computer comprising a processor and a non-transitory computer-readable storage medium. The computer readable medium comprises code executable by the processor for implementing a method. The method comprises receiving, at a client computer, a plurality of fraud detection rules. The method may also comprise selecting, by the client computer, from the plurality of fraud detection rules, a set of fraud detection rules. The set of fraud detection rules may be associated with the user as a core fraud detection rules set.

These and other embodiments of the invention are described in further detail below with reference to the Figures and the Detailed Description.

BRIEF DESCRIPTION OF THE DRAWINGS

<figref idref="DRAWINGS">FIG. 1</figref> shows a system diagram of a payment processing system according to an embodiment of the claimed invention.

<figref idref="DRAWINGS">FIG. 2</figref> shows a block diagram of components of a fraud detection system according to an embodiment of the invention.

<figref idref="DRAWINGS">FIG. 3</figref> shows a block diagram of components of a merchant processor computer according to an embodiment of the invention.

<figref idref="DRAWINGS">FIG. 4</figref> shows a block diagram of components of a payment processing network according to an embodiment of the invention.

<figref idref="DRAWINGS">FIG. 5</figref> illustrates a flowchart describing the process of a financial transaction according to an embodiment of the invention.

<figref idref="DRAWINGS">FIG. 6</figref> illustrates a flowchart describing the creation of a new core fraud detection rule according to an embodiment of the invention.

<figref idref="DRAWINGS">FIG. 7</figref> shows a depiction of a user login page according to an embodiment of the invention.

<figref idref="DRAWINGS">FIG. 8</figref> shows a depiction of a custom rules page according to an embodiment of the invention.

<figref idref="DRAWINGS">FIG. 9</figref> shows a depiction of features of a default rules editor page according to an embodiment of the invention.

<figref idref="DRAWINGS">FIG. 10</figref> shows a depiction of features of a rules editor page and the steps of creating a new fraud detection rule condition according to an embodiment of the invention.

<figref idref="DRAWINGS">FIG. 11</figref> shows a depiction of features of a rules editor page and the steps of creating a new fraud detection rule according to an embodiment of the invention.

<figref idref="DRAWINGS">FIG. 12</figref> shows a depiction of features of a rules editor page and the steps of creating a new fraud detection rule and establishing the new rule as a core fraud detection rule according to an embodiment of the invention.

<figref idref="DRAWINGS">FIG. 13</figref> shows a depiction of a custom rules page after the creation of a new core fraud detection rule according to an embodiment of the invention.

<figref idref="DRAWINGS">FIG. 14</figref> illustrates a flowchart describing the creation of a new merchant profile with core fraud detection rules according to an embodiment of the invention.

<figref idref="DRAWINGS">FIG. 15</figref> shows a depiction of a profile page showing profile settings according to an embodiment of the invention.

<figref idref="DRAWINGS">FIG. 16</figref> shows a depiction of features of a default profile editor page according to an embodiment of the invention.

<figref idref="DRAWINGS">FIG. 17</figref> shows a depiction of features of a profile editor page and the steps of creating a new merchant profile according to an embodiment of the invention.

<figref idref="DRAWINGS">FIG. 18</figref> shows a depiction of core fraud detection rules that can be added to a new merchant profile when the merchant profile is created according to an embodiment of the invention.

<figref idref="DRAWINGS">FIG. 19</figref> illustrates a flowchart describing the addition of a new core fraud detection rule to preexisting merchant profiles according to an embodiment of the invention.

<figref idref="DRAWINGS">FIG. 20</figref> shows a depiction of features of a rules editor page according to an embodiment of the invention.

<figref idref="DRAWINGS">FIG. 21</figref> shows a depiction of a pop-up window on a rules editor page for configuring fraud detection rules in preexisting merchant profiles according to an embodiment of the invention.

<figref idref="DRAWINGS">FIG. 22</figref> shows a block diagram of a computer apparatus.

DETAILED DESCRIPTION

Prior to discussing embodiments of the invention, descriptions of some terms may be helpful in understanding embodiments of the invention.

The term “server computer” may include a powerful computer or cluster of computers. For example, the server computer can be a large mainframe, a minicomputer cluster, or a group of servers functioning as a unit. In one example, the server computer may be a database server coupled to a Web server. The server computer may be coupled to a database and may include any hardware, software, other logic, or combination of the preceding for servicing the requests from one or more client computers. The server computer may comprise one or more computational apparatuses and may use any of a variety of computing structures, arrangements, and compilations for servicing the requests from one or more client computers.

The term “client computer” may include any suitable computational apparatus. The client computer may be an apparatus operated by a consumer, a user associated with a merchant, or any other individual. The client computer may use any suitable wired or wireless network, including the Internet, in order to communicate with other systems. For example, a consumer client computer may be used by a consumer to interact with a merchant Internet storefront in order to conduct a transaction. A merchant client computer may be used by a user associated with a merchant to interact with other merchant computer systems and a fraud detection system.

The term “fraud detection system” may include a single computer or a network of suitable processing entities (e.g., computers) that may have the ability to receive, process and evaluate transaction details to provide fraud detection services. The fraud detection system may have or operate at least a server computer and may include a plurality of databases. The fraud detection system may include a selection of fraud detection rules and merchant profiles that can be created, modified, and/or deleted. The fraud detection system may further record an audit log of modifications made to customizable settings, the selection of fraud detection rules, and merchant profiles that reside within the system. The fraud detection system may also create reports and statistical analyses of the performance of transactions through its system.

The term “fraud detection rule” may refer to a rule in the fraud detection system, and may include a customizable rule. Each fraud detection rule may allow customization as to name, description, category, status as a core fraud detection rule, and for further processes or actions to be taken if the fraud detection rule is triggered. In embodiments of the invention, actions that can be designated for each fraud detection rule can include: accept, reject, review, and/or monitor. Each fraud detection rule may further allow for rule conditions to be established based on a number of criteria. The rule conditions are checked against received transaction details and are used to determine whether a fraud detection rule is triggered.

The term “core fraud detection rule set” may refer to one or more fraud detection rules that a merchant (or user) has marked as being a core fraud detection rule. Once a user has designated one or more fraud detection rules as a core fraud detection rule, the core fraud detection rule set can be automatically populated into new merchant profiles.

The term “user” may refer to an individual or entity who can access the fraud detection system using credentials (e.g. merchant ID, user ID and password) that the individual or entity is authorized to use. As used herein, user may also refer to an individual or entity that is not authorized to access the fraud detection system, but has access to authorized credentials allowing them access to the fraud detection system.

The user can access merchant profiles and fraud detection rules and make modifications to merchant profiles and/or fraud detection rules that are then associated with the user ID logged into the fraud detection system and stored in the fraud rules modification database. The user can also create new merchant profiles, create new fraud detection rules, as well as designate new or existing fraud detection rules as core fraud detection rules.

The term “merchant profile” may include a selection of fraud detection rules and settings established by a merchant (or user) with the fraud detection system. A merchant profile may be added, modified or deleted in the fraud detection system. The merchant profile may include customizable settings for name, profile description, and a selection of fraud detection rules. The merchant profile may also indicate queues into which transactions that are rejected or marked for review are placed for further review. The merchant profile may be associated with one or more users who have access to modify the selection of fraud detection rules contained in the merchant profile. A merchant may have one or more merchant profiles, each comprised of different fraud detection rules as required by the merchant's business.

The term “automatically populate” may refer to an action that can be conducted without direct human interaction. In embodiments of the invention, a core fraud detection rule set can be automatically populated into new merchant profiles by the server computer in the fraud detection system, without requiring the user or merchant to manually enter fraud detection rules or manually select fraud detection rules to load into a new merchant profile. In embodiments, the user can command or direct the fraud detection system to automatically generate a new merchant profile containing the core fraud detection rule set. It can refer to the merchant or user being able to create a new merchant profile that is automatically populated with a pre-existing (or pre-established) core fraud detection rule set. The core fraud detection rule set that is automatically populated into the new merchant profile may be a default set of fraud detection rules as prepared by the fraud detection system or it may be a merchant customized set of fraud detection rules.

The term “database” may include any hardware, software, firmware, or combination of the preceding for storing and facilitating retrieval of information. Also, the database may use any of a variety of data structures, arrangements, and compilations to store and facilitate retrieval of information.

The term “storing” may include recording information regarding a new fraud detection rule or merchant profile and/or regarding a modification to an existing fraud detection rule or existing merchant profile into a database. Storing may also include recording information as to the user ID of a user who effected the modification to the fraud detection rule and/or merchant profile. The storing may be accomplished by the server computer in the fraud detection system and may be stored in a fraud rules modification database, a fraud rules database, and/or a merchant profiles database. For example, if a user creates a new merchant profile with a core fraud detection rule set, the core fraud detection rule set can be stored with the merchant profile in the merchant profiles database. In other embodiments, the core fraud detection rule set can be stored in the fraud rules database and associated with a merchant profile in the merchant profiles database by a user association module. In another example, if another user modifies a fraud detection rule, the name of the rule being modified, the details of the modification, the date and time of the modification, the user ID logged into the fraud detection system, as well as other pertinent information can be recorded in the fraud rules modification database for future purposes.

The term “fraud rules database” may refer to a database containing data that may be used by the fraud detection system. The data in the fraud rules database may include a plurality of fraud detection rules. The fraud rules database may contain default rules prepared and stored by the fraud detection system, and it may contain merchant or user-customized rules. In some embodiments of the invention, when a merchant or user creates a customized core fraud detection rule set, the core fraud detection rule set is stored in the fraud rules database.

The term “merchant profiles database” may refer to a database containing data that may be used by the fraud detection system. The data in the merchant profiles database may include a plurality of merchant profiles. In some embodiments of the invention, when a merchant or user creates a customized core fraud detection rule set and associates the core fraud detection rule set with a merchant profile, the core fraud detection rule set is stored in the merchant profiles database associated with the merchant profile.

I. Systems

Example embodiments are typically implemented in the context of a financial transaction. Therefore, prior to further discussing creating new merchant profiles and automatically populating new and existing merchant profiles with fraud detection rules within a fraud detection system, a brief description of transaction processing will be presented.

An exemplary system <b>100</b> for transaction processing can be seen in <figref idref="DRAWINGS">FIG. 1</figref>. The system <b>100</b> includes a consumer <b>102</b>, a consumer payment device <b>104</b>, a consumer client computer <b>106</b>, a merchant computer <b>110</b>, a user <b>112</b>, a merchant client computer <b>114</b>, a fraud detection system <b>118</b>, a merchant processor computer <b>120</b>, an acquirer computer <b>122</b>, a payment processing network <b>124</b>, and an issuer computer <b>126</b>. In a typical transaction, a consumer <b>102</b> may purchase goods or services at a merchant associated with the merchant computer <b>110</b> using a consumer payment device <b>104</b>. The transactions details are then sent to the merchant processor computer <b>120</b> and to the acquirer computer <b>122</b>. The acquirer computer <b>122</b> can communicate with an issuer computer <b>126</b> via a payment processing network <b>124</b> for additional transaction processing. For simplicity of illustration, a certain number of components are shown is shown in <figref idref="DRAWINGS">FIG. 1</figref>. It is understood, however, that embodiments of the invention may include more than one of each component. In addition, some embodiments of the invention may include fewer than all of the components shown in <figref idref="DRAWINGS">FIG. 1</figref>. Also, the components in <figref idref="DRAWINGS">FIG. 1</figref> may communicate via any suitable communication medium (including the internet), using any suitable communication protocol.

The consumer client computer <b>106</b> may communicate with the merchant computer <b>110</b> via a communications medium <b>108</b>, such as a network (e.g. the Internet). Similarly, the merchant client computer <b>114</b> may communicate with the fraud detection system <b>118</b> via a communications medium <b>116</b>, such as a network (e.g. the Internet).

The consumer <b>102</b> may be an individual, or an organization such as a business, that is capable of purchasing goods or services. The user <b>112</b> may be a merchant, an employee of the merchant, or any other individual who has access to the merchant client computer <b>114</b>.

The consumer payment device <b>104</b> may be in any suitable form. For example, suitable consumer payment devices can be hand-held and compact so that it can fit into a consumer's wallet and/or pocket (e.g., pocket-sized). The consumer payment device <b>104</b> can include a processor, and memory, input devices, and output devices, operatively coupled to the processor. Specific examples of consumer payment devices include cellular or wireless phones, personal digital assistants (PDAs), pagers, portable computers, smart cards, and the like. The consumer payment devices can also be debit devices (e.g., a debit card), credit devices (e.g., a credit card), or stored value devices (e.g., a pre-paid or stored value card).

The consumer <b>102</b> can use the consumer client computer <b>106</b>, which is communicatively coupled to the merchant computer <b>110</b> via the communications medium <b>108</b> in order to conduct a transaction with the merchant. The consumer client computer <b>106</b> may be in any suitable form. Example of consumer mobile devices include any device capable of accessing the Internet, such as a personal computer, cellular or wireless phones, personal digital assistants (PDAs), tablet PCs, and handheld specialized readers. The consumer client computer <b>106</b> transmits data through the communications medium <b>108</b> to the merchant computer <b>110</b>. In some embodiments of the invention, the consumer payment device <b>106</b> and the consumer client computer <b>106</b> may be a single device.

As depicted in <figref idref="DRAWINGS">FIG. 2</figref>, the fraud detection system <b>118</b> may comprise a server computer <b>118</b>(A) comprising a user authentication module <b>118</b>(B), a rule modification module <b>118</b>(C), a user association module <b>118</b>(D), a transaction analyzer module <b>118</b>(E), an audit search module <b>118</b>(F), a data output module <b>118</b>(G), a display module <b>118</b>(H), and a reports module <b>118</b>(I). The various modules may be embodied by computer code, residing on computer readable media.

The server computer <b>118</b>(A) may be operatively coupled to one or more databases. The one or more databases may comprise a user database <b>118</b>(J), a fraud rules database <b>118</b>(K), a merchant profiles database <b>118</b>(L) and a fraud rules modification database <b>118</b>(M).

The user authentication module <b>118</b>(B) handles the verification of the authorization credentials for a user (e.g. merchant ID, user name, password). The user authentication module <b>118</b>(B) may access a user database <b>118</b>(J) in determining whether a user <b>112</b> seeking access to the fraud detection system <b>118</b> is an authorized user. For example, when presented with credentials, the user authentication module <b>118</b>(B) may access the user database <b>118</b>(J) to determine whether the provided user name is in the user database <b>118</b>(J) and whether the provided password corresponds to the password linked to the user name.

The rule modification module <b>118</b>(C) receives modifications from a user <b>112</b> to fraud detection rules or to a merchant profile. The rule modification module <b>118</b>(C) may also receive modifications in the form of the creation of new merchant profiles or new fraud detection rules. For example, when a user <b>112</b> creates a new merchant profile, the rule modification module <b>118</b>(C) may access the merchant profiles database <b>118</b>(L) to store the new merchant profile. The rule modification module <b>118</b>(C) may similarly access the fraud rules database <b>118</b>(L) to store new fraud detection rules. The rule modification module <b>118</b>(C) may further access the merchant profiles database <b>118</b>(L) to store modifications made to a merchant profile. For example, when a user <b>112</b> makes a modification, the rule modification module <b>118</b>(C) may access the merchant profile database <b>118</b>(L) associated with the authorization credentials entered by the user <b>112</b>. The rule modification module <b>118</b>(C) may also access the fraud rules database <b>118</b>(K) to access pre-established fraud detection rules to add to the merchant profile or to store newly created fraud detection rules created by the user for the merchant profile. In some embodiments of the invention, new fraud detection rules created by the user are stored in the merchant profiles database <b>118</b>(L) with the corresponding merchant profile.

The user association module <b>118</b>(D) may associate any modifications made by a user <b>112</b> with the authorization credentials entered by the user <b>112</b>. For example, if the user <b>112</b> logged into the fraud detection system <b>118</b> with the user name “user1,” the user association module <b>118</b>(D) may record all the modifications made by the user <b>112</b>, associate the modifications with the user name “user1,” and store the data in the fraud rules modification database <b>118</b>(M). The user association module <b>118</b>(D) may also associate core fraud detection rule sets with a user and/or merchant profile.

The transaction analyzer module <b>118</b>(E) may evaluate transaction data received by the fraud detection system <b>118</b> from the merchant processor computer <b>120</b>. In embodiments of the invention, the fraud detection system <b>118</b> receives the authorization response message from the merchant processor computer <b>120</b> and the message is analyzed by the transaction analyzer module <b>118</b>(E). If the result from the transaction analyzer module <b>118</b>(E) is an “ACCEPT”, the transaction between the merchant and the consumer <b>102</b> can be completed. If the result from the transaction analyzer module <b>118</b>(E) is a “REJECT”, the fraud detection system <b>118</b> would return a message to be presented to the consumer <b>102</b> that the consumer <b>102</b> may be contacted if there are any issues. For example, the consumer may receive a message stating, “Thank you for your order. We will contact you if there are any issues.” In embodiments of the invention, the message does not indicate that a “REJECT” was determined for the transaction as the consumer <b>102</b> may be attempting to conduct fraudulent transactions. If the result from the transaction analyzer module <b>118</b>(E) is a “REVIEW”, the fraud detection system <b>118</b> would “hold” the transaction until it can be further reviewed, and it is determined whether it should be accepted or rejected. In some embodiments, the fraud detection system <b>118</b> can automatically invoke a settlement upon an accept decision by the transaction analyzer module <b>118</b>(E).

The audit search module <b>118</b>(F) handles the audit log search function of the fraud detection system <b>118</b>. The audit search module <b>118</b>(F) receives input from a user <b>112</b> comprising search parameters to conduct an audit log search. The audit search module <b>118</b>(F) processes the search parameters and conducts a search of the fraud rules modification database <b>118</b>(L).

The data output module <b>118</b>(G) may output data to be displayed to the user <b>112</b>. In some embodiments, the data output module may output a set of fraud detection rules or merchant profiles to the user <b>112</b>. In other embodiments, the data outputted to the user <b>112</b> can include the results of an audit log search conducted by the audit search module <b>118</b>(F)

The display module <b>118</b>(H) displays the layout of the fraud detection system <b>118</b>. In embodiments of the invention, the fraud detection system <b>118</b> is accessed as a website over a communications medium (e.g. the Internet), via an Internet-enabled device capable of displaying HTML. Other embodiments allow the fraud detection system <b>118</b> to be displayed in other suitable manners on other suitable display devices.

The reports module <b>118</b>(I) compiles the data obtained from the fraud detection system <b>118</b> from analyzing transactions. In embodiments of the invention, the reports module <b>118</b>(I) can provide detailed statistics and data for the merchant on the performance of the merchant's profile and selection of fraud detection rules. For example, the reports module <b>118</b>(I) can prepare a report indicating the number of times each fraud detection rule was triggered by a transaction. It can further indicate the results of analyzed transactions (e.g. accepted, rejected, or sent for further review). In embodiments of the invention, the reports module <b>118</b>(I) can present the full transaction details for each transaction received by the fraud detection system <b>118</b>.

The user database <b>118</b>(J) may be used by the server computer <b>118</b>(A) to store authentication elements for users. For example, the user database <b>118</b>(J) may contain a plurality of merchant IDs and associated user names authorized to access the corresponding merchant profile stored in the merchant profiles database <b>118</b>(L) in the fraud detection system <b>118</b>. The user database <b>118</b>(J) may further store passwords associated with each merchant ID and user name authorized to access the fraud detection system <b>118</b>.

The fraud rules database <b>118</b>(K) may be used by the server computer <b>118</b>(A) to store fraud detection rules that can be added to merchant profiles. In embodiments, a merchant profile can be loaded with pre-existing fraud detection rules contained in the fraud rules database <b>118</b>(K). The fraud rules database <b>118</b>(K) may further store new fraud detection rules created by a user <b>112</b>. The fraud rules database <b>118</b>(K) may also store a core fraud detection rule set associated with the user <b>112</b> that can be accessed and presented to the user <b>112</b> when the user <b>112</b> requests a new merchant profile to be generated.

The merchant profiles database <b>118</b>(L) may be used by the server computer <b>118</b>(A) to store merchant profiles that are customized for each merchant that has created a profile with the fraud detection system <b>118</b>. In some embodiments, the merchant profile database <b>118</b>(L) may further store fraud detection rules that have been created for a merchant and associated with a merchant profile.

The fraud rules modification database <b>118</b>(M) may be used by the server computer <b>118</b>(A) to store an audit log containing details regarding merchant profiles, fraud detection rules, modifications made to the merchant profiles and fraud detection rules, the creation of new merchant profiles and fraud detection rules, and the user name of the user <b>112</b> who made the modifications to the fraud detection rules or merchant profiles. The data stored in the fraud rules modification database <b>118</b>(M) may be stored by the rule modification module <b>118</b>(C) and may be searched by the audit search module <b>118</b>(F).

Returning now to <figref idref="DRAWINGS">FIG. 1</figref> the user <b>112</b> can use the merchant client computer <b>114</b>, which is communicatively coupled to the fraud detection system <b>118</b> via the communications medium <b>108</b> in order to access the fraud detection system <b>118</b>. The merchant client computer <b>114</b> may be in any suitable form. Example of merchant client computers include any device capable of accessing the Internet, such as a personal computer, cellular or wireless phones, personal digital assistants (PDAs), tablet PCs, and handheld specialized readers. The merchant client computer <b>114</b> transmits data through the communications medium <b>116</b> to the fraud detection system <b>118</b>. In some embodiments of the invention, the merchant computer <b>110</b> and the merchant client computer <b>114</b> may be a single device.

The merchant computer <b>110</b> may be comprised of various modules that may be embodied by computer code, residing on computer readable media. It may include any suitable computational apparatus operated by a merchant. Examples of merchant computers may include an access device or an internet merchant computer. The merchant computer <b>110</b> may be in any suitable form. Additional examples of merchant computers include any device capable of accessing the Internet, such as a personal computer, cellular or wireless phones, personal digital assistants (PDAs), tablet PCs, and handheld specialized readers. The merchant computer <b>110</b> transmits data through the communications medium <b>108</b> to the consumer client computer <b>106</b>. The merchant computer <b>110</b> may also transmit data to a merchant processor computer <b>120</b>. In embodiments of the invention, the merchant computer <b>110</b> receives transaction data from a consumer client computer <b>106</b> and transmits the transaction data to the merchant processor computer <b>120</b> for fraud evaluation and for further transaction authorization processes. The merchant computer <b>110</b> can further communicate with and/or receive input from a merchant client computer <b>114</b> operated by a user <b>112</b>.

As depicted in <figref idref="DRAWINGS">FIG. 3</figref>, the merchant processor computer <b>120</b> may comprise a server computer <b>120</b>(A) comprising an authorization module <b>120</b>(B), a transaction review module <b>120</b>(C), and a routing module <b>120</b>(D). The various modules may be embodied by computer code, residing on computer readable media.

The authorization module <b>120</b>(B) may generate and process authorization request and response messages. The authorization module <b>120</b>(B) may also determine the appropriate destination for the authorization request and response messages. An authorization request message is a message sent requesting that an issuer computer <b>126</b> authorize a financial transaction. An authorization request message may comply with ISO 8583, which is a standard for systems that exchange electronic transactions made by consumers using payment devices. An authorization request message according to other embodiments may comply with other suitable standards. In embodiments of the invention, an authorization request message may include, among other data, a Primary Account Number (PAN) and expiration date associated with a payment device (e.g. credit/debit card) of the consumer, amount of the transaction (which may be any type and form of a medium of exchange such a money or points), and identification of a merchant (e.g. merchant ID). In embodiments, an authorization request message is generated by a server computer (if the transaction is an e-commerce transaction) or a Point of Sale (POS) device (if the transaction is a brick and mortar type transaction) and is sent to an issuer computer <b>126</b> via a payment processing network <b>124</b> and an acquirer computer <b>122</b>.

The transaction review module <b>120</b>(C) conducts a fraud evaluation for transactions. If the transaction review module <b>120</b>(C) determines that the transaction may be fraudulent, the transaction review module <b>120</b>(C) may determine that the transaction should be denied. If the transaction review module <b>120</b>(C) determines that the transaction is not fraudulent, the transaction review module <b>120</b>(C) may determine that the transaction should be allowed. If the transaction review module <b>120</b>(C) is unable to determine whether the transaction is fraudulent, the transaction review module <b>120</b>(C) can send the transaction for further review.

The routing module <b>120</b>(D) can route transactions to the appropriate destination. If a transaction is determined to be not fraudulent, the routing module <b>120</b>(D) can route the message to the acquirer computer <b>122</b> for further processing. If the transaction is determined to be fraudulent, the routing module <b>120</b>(D) can send the transaction back to the merchant. If the fraud evaluation conducted by the transaction review module <b>120</b>(C) is indeterminate, the transaction can be routed to a further review by a person.

An acquirer computer <b>122</b> is typically a system for an entity (e.g. a bank) that has a business relationship with a particular merchant or other entity. An issuer computer <b>126</b> is typically a business entity (e.g. a bank) which maintains financial accounts for the consumer <b>102</b> and often issues a consumer payment device <b>104</b> such as a credit or debit card to the consumer <b>102</b>. Some entities can perform both issuer computer <b>126</b> and acquirer computer <b>122</b> functions. Embodiments of the invention encompass such single entity issuer-acquirers.

As depicted in <figref idref="DRAWINGS">FIG. 4</figref>, the payment processing network <b>124</b> may comprise a server computer <b>124</b>(A) comprising an application programming interface <b>124</b>(B), an authorization module <b>124</b>(C), a clearing and settlement module <b>124</b>(D), and a routing module <b>124</b>(E). The various modules may be embodied by computer code, residing on computer readable media.

As noted above, the payment processing network <b>124</b> may have or operate at least a server computer <b>124</b>(A). In some embodiments, the server computer <b>124</b>(A) may be coupled to a database and may include any hardware, software, other logic, or combination of the preceding for servicing the requests from one or more client computers. The server computer <b>124</b>(A) may comprise one or more computational apparatuses and may use any of a variety of computing structures, arrangements, and compilations for servicing the requests from one or more client computers.

The payment processing network <b>124</b> may include data processing subsystems, networks, and operations used to support and deliver authorization services, exception file services, and clearing and settlement services. An exemplary payment processing network may include VisaNet™. Networks that include VisaNet™ are able to process credit card transactions, debit card transactions, and other types of commercial transactions. VisaNet™, in particular, includes an integrated payments system (Integrated Payments system) which processes authorization requests and a Base II system which performs clearing and settlement services. The payment processing network <b>124</b> may use any suitable wired or wireless network, including the Internet.

The authorization module <b>124</b>(C) processes authorization request messages and determines the appropriate destination for the authorization request messages. The clearing and settlement module <b>124</b>(D) handles the clearing and settlement of transactions. These modules authenticate user information and organize the settlement process of user accounts between the acquirer computer <b>122</b> and the issuer computer <b>126</b>. An example of the clearing and settlement module is Base II, which provides clearing, settlement, and other interchange-related services to VISA members.

The routing module <b>124</b>(E) handles the routing of authorization request messages from the acquirer computer <b>122</b> to the issuer computer <b>126</b>, and the routing the authorization response messages back from the issuer computer <b>126</b> to the acquirer computer <b>122</b>.

II. Methods

Methods according to embodiments of the invention can be described with respect to <figref idref="DRAWINGS">FIGS. 1-21</figref>.

<figref idref="DRAWINGS">FIG. 5</figref> is a flowchart of a method <b>500</b> for processing a transaction through a system <b>100</b> shown in <figref idref="DRAWINGS">FIGS. 1-4</figref>.

In step <b>505</b>, in a typical transaction, the consumer <b>102</b> engages in a transaction for goods or services at a merchant associated with a merchant computer <b>110</b> using a consumer client computer <b>106</b> and a consumer payment device <b>104</b> such as a credit card or mobile phone. For example, the consumer <b>102</b> may use their Internet-enabled mobile phone to access a merchant website to conduct a transaction using their consumer payment device <b>104</b>. In other embodiments, the consumer <b>102</b> may swipe the credit card through a POS terminal or, in another embodiment, may take a wireless phone and may pass it near a contactless reader in a POS terminal.

In step <b>510</b>, a merchant computer <b>110</b> receives the transaction from the consumer client computer <b>106</b> and may then transmit the transaction details to a merchant processor computer <b>120</b>. Transactions details may be comprised of, but is not limited to, the following: consumer name, consumer billing address, consumer shipping address, consumer phone number, consumer account number, items purchased, item prices, etc.

In step <b>515</b>, the merchant processor computer <b>120</b> may conduct a fraud analysis and determine whether the transaction should proceed or whether it should be rejected and returned to the merchant computer <b>110</b>. The merchant processor computer <b>120</b> may use the transaction details in determining whether the transaction may be fraudulent.

In step <b>520</b>, if the merchant processor computer <b>120</b> determines that the transaction details indicate that the transaction may be fraudulent, the merchant processor computer <b>120</b> may return the transaction to the merchant computer <b>110</b> indicating that the transaction is fraudulent and should be declined.

In step <b>525</b>, if the merchant processor computer <b>120</b> determines that the transaction details indicate that the transaction is not fraudulent, an authorization request message may then be generated. The authorization request message may be generated in any suitable format.

In step <b>530</b>, the generated authorization request message may be transmitted by the merchant processor computer <b>120</b> to an acquirer computer <b>122</b>. The authorization request message may be transmitted in any suitable format.

In step <b>535</b>, after receiving the authorization request message, the authorization request message may then be transmitted to a payment processing network <b>124</b>.

In step <b>540</b>, after receiving the authorization request message, the payment processing network <b>124</b> may then transmit the authorization request message to an appropriate issuer computer <b>126</b> associated with the consumer payment device <b>104</b>.

In step <b>545</b>, the issuer computer <b>126</b> receives the authorization request message. The issuer computer <b>126</b> may then determine whether the transaction should be authorized. The issuer computer <b>126</b> transmits an authorization response message back to the payment processing network <b>124</b>. The authorization response message can indicate whether or not the current transaction has been authorized or has been declined.

In step <b>550</b>, the payment processing network <b>124</b> may then transmit the authorization response message back to the acquirer computer <b>122</b>. The acquirer computer <b>122</b> may then transmit the response message back to the merchant processor computer <b>120</b>.

In step <b>555</b>, the merchant processor computer <b>120</b> may then transmit the authorization response message to a fraud detection system <b>118</b>. The fraud detection system <b>118</b> may then undertake a decision process based on the authorization response message. If the result from the fraud detection system <b>118</b> is an “ACCEPT”, the transaction between the merchant and the consumer <b>102</b> can be completed. If the result from the fraud detection system <b>118</b> is a “REJECT”, the fraud detection system <b>118</b> would return a message to be presented to the consumer <b>102</b> that the consumer <b>102</b> may be contacted if there are any issues. For example, the consumer may receive a message stating, “Thank you for your order. We will contact you if there are any issues.” In embodiments of the invention, the message does not indicate that a “REJECT” was determined for the transaction as the consumer <b>102</b> may be attempting to conduct fraudulent transactions. If the result from the fraud detection system <b>118</b> is a “REVIEW”, the fraud detection system <b>118</b> would “hold” the transaction until it can be further reviewed, and it is determined whether it should be accepted or rejected.

In step <b>560</b>, after the merchant computer <b>110</b> receives the authorization response message, the merchant computer <b>110</b> may then provide the authorization response message to the consumer <b>102</b>. For example, the consumer <b>102</b> may be presented with a screen on the consumer client computer <b>106</b> indicating success or failure of authorization. In other embodiments, the authorization response message may be displayed by the POS terminal, or may be printed out on a receipt.

In step <b>565</b>, at the end of the day or at a period determined by the merchant, a normal clearing and settlement process can be conducted. A clearing and settlement process may include a process of reconciling a transaction. A clearing process is a process of exchanging financial details between an acquirer computer <b>122</b> and an issuer computer <b>126</b> to facilitate posting to a party's account and reconciliation of the party's settlement position. Settlement involves the delivery of securities from one party to another. In some embodiments, clearing and settlement can occur simultaneously. In other embodiments, the clearing and settlement process can be conducted by the fraud detection system <b>118</b> once the fraud detection system <b>118</b> has determined that the transaction should be accepted.

In step <b>570</b>, the merchant receives payment for the transaction.

<figref idref="DRAWINGS">FIG. 6</figref> is a flowchart of a method <b>600</b> for generating and storing a new fraud detection rule through a system shown in <figref idref="DRAWINGS">FIGS. 1, 2, and 7-13</figref>.

In step <b>605</b>, a user <b>112</b> logs into the fraud detection system <b>118</b> using authorized credentials associated with a merchant. In embodiments of the invention, the fraud detection system <b>118</b> authenticates the identity of the user <b>112</b> prior to permitting the user <b>112</b> to make modifications to a selection of fraud detection rules by verifying a login ID and password of the user <b>112</b>. In embodiments, the fraud detection system <b>118</b> accesses a user authentication module <b>118</b>(B) in order to authenticate the user <b>112</b>. The user <b>112</b> may be a merchant, the individual who established the merchant profile or an employee of the merchant who has been given access to the fraud detection system <b>118</b>. The user <b>112</b> may be an individual who has fraudulently obtained authorized credentials in order to modify the merchant profile and fraud detection rules associated with the merchant profile in order to facilitate fraudulent activity (e.g. fraudulent transactions).

<figref idref="DRAWINGS">FIG. 7</figref> depicts an exemplary user login screen <b>700</b> according to an embodiment of the invention. A user <b>112</b> is provided the option of accessing a Live Business Center <b>701</b> or accessing a Test Business Center <b>702</b>. Selecting the Live Business Center <b>701</b> allows the user <b>112</b> to log into a real-time run environment where actual transactions are run through the fraud detection system <b>118</b>. Selecting the Test Business Center <b>702</b> allows the user <b>112</b> to log into a test environment that the user <b>112</b> can utilize to run test or simulated transactions through the fraud detection system <b>118</b>.

In order to access the fraud detection system <b>118</b>, the user <b>112</b> must enter authorized credentials when prompted with the login screen <b>700</b>. The authorized credentials are entered in a Merchant ID field <b>703</b>, a User Name field <b>704</b>, and a Password field <b>705</b>. Once the fields have been filled, the user <b>112</b> can select the “Login” button <b>706</b> for the credentials to be authorized. If the user <b>112</b> has forgotten their password, the user <b>112</b> can access a password recovery process by selecting the hyperlink <b>707</b>.

In step <b>610</b>, the user <b>112</b> selects the custom rules option from the Fraud Rule Controls menu option <b>804</b> and is taken to the Custom Rules page. <figref idref="DRAWINGS">FIG. 8</figref> depicts the default Custom Rules screen <b>800</b> when a user <b>112</b> selects the “Custom Rules” option from the menu options. The left-column menu includes a selection of options for using the fraud detection system <b>118</b>. Selecting the “Home” <b>801</b> option takes the user <b>112</b> to the home screen of the fraud detection system <b>118</b>. Selecting the “Support Center” <b>802</b> option takes the user <b>112</b> to the Help and Support Center for the fraud detection system <b>118</b>. Selecting the “Virtual Terminal” <b>803</b> option takes the user <b>112</b> to a page that the user <b>112</b> can use to simulate transactions to test the fraud detection system <b>118</b>. Selecting the “Fraud Rule Controls” <b>804</b> option takes the user <b>112</b> to the fraud detection rules and merchant profile settings and controls. There the user can add, modify, or delete, fraud detection rules and/or merchant profiles. Selecting the “Tools &amp; Settings” <b>805</b> option takes the user <b>112</b> to a variety of tools that the user <b>112</b> can use with the fraud detection system <b>118</b>. Selecting the “Transaction Search” <b>806</b> option takes the user <b>112</b> to a search page that the user <b>112</b> can utilize to conduct searches for specific transactions. Selecting the “Reports” <b>807</b> option takes the user <b>112</b> to the Reports page that allows the user <b>112</b> to review different activity compiled by the fraud detection system <b>118</b> in specialized and customizable reports. Selecting the “Account Management” <b>808</b> option takes the user <b>112</b> to a variety of administrative functions including an “Audit Search” function.

Additional information and options displayed on the Custom Rules screen <b>800</b> include the login information section <b>809</b> containing the user ID, account ID, and merchant ID. The user <b>112</b> can log out of the fraud detection system <b>118</b> by selecting the “Log Out” option <b>810</b>. If the user <b>112</b> wants additional help, the user <b>112</b> can select the “Online Help” option <b>811</b>.

In step <b>615</b>, the fraud detection system <b>118</b> presents the user <b>112</b> with a set of pre-existing (or pre-established) fraud detection rules. In embodiments of the invention, the fraud detection rules are provided by a server computer <b>118</b>(A) in the fraud detection system <b>118</b>. In embodiments, the fraud detection rules are received at a client computer <b>114</b>. In embodiments, the fraud detection rules are retrieved from the fraud rules database <b>118</b>(K) and transmitted to the client computer <b>114</b> from the server computer <b>118</b>(A) by the display module <b>118</b>(H). Each fraud detection rule comprises of at least one condition for triggering the fraud detection rule. The fraud detection rules are presented in categorized form. As shown in <figref idref="DRAWINGS">FIG. 8</figref>, there may be a plurality of fraud detection rule categories <b>820</b>. Each of the fraud detection rule categories <b>820</b> has a title and indicates the number of rules contained in each of the fraud detection rule categories <b>820</b>. Further, each fraud detection rule category box has a core rule indicator <b>821</b> (where a “C” character indicates that the rule is a core fraud detection rule), a fraud detection rule name field <b>822</b>, and a fraud detection rule description field <b>823</b>. For example, in <figref idref="DRAWINGS">FIG. 8</figref>, the default fraud detection rule categories include: Address Verification, Card Verification Number, Consumer Data Validation, Order Data Quality, Other Tests, Payer Authentication, Velocity and Uncategorized. Embodiments of the invention may include these categories, a combination of these categories and other categories, or other categories entirely.

In embodiments of the invention, the user <b>112</b> can use fraud detection rules provided by the fraud detection system <b>118</b> rather than create new fraud detection rules. The selection of fraud detection rules may be fraud detection rules provided by the fraud detection system <b>118</b>, fraud detection rules created by the user <b>112</b>, or a combination of both. The user <b>112</b> can select from the fraud detection rules provided by the fraud detection system <b>118</b>, a set of fraud detection rules, where the selected set of fraud detection rules can be associated with the user <b>112</b> as a core fraud detection rule set for the user <b>112</b>. Once the user <b>112</b> has established a core fraud detection rule set, the user <b>112</b> can make additional merchant profiles and the fraud detection system <b>118</b> can automatically populate the additional merchant profiles with the core fraud detection rule set.

In step <b>620</b>, the user <b>112</b> selects the “Add Rule” option in order to add a new fraud detection rule to the fraud detection system <b>118</b>. As shown in <figref idref="DRAWINGS">FIG. 8</figref>, additional options on the Custom Rules screen <b>800</b> include the option for the user <b>112</b> to “Add Category” <b>824</b>, “Add Rule” <b>825</b>, and “Delete Rule(s)” <b>826</b>. The “Add Category” button <b>824</b> gives the user <b>112</b> the ability to create new fraud detection rule categories. The “Add Rule” button <b>825</b> gives the user <b>112</b> the ability to add new fraud detection rules to the fraud detection system <b>118</b>. The “Delete Rule(s)” button <b>826</b> gives the user <b>112</b> the ability to delete one or more fraud detection rules from the fraud detection system <b>118</b>. In embodiments, deleting a fraud detection rule only deletes it from the user's <b>112</b> merchant profile and not from the entire fraud detection system <b>118</b>.

In step <b>625</b>, the fraud detection system <b>118</b> generates and presents a Rule Editor page to the user <b>112</b>. As shown in <figref idref="DRAWINGS">FIG. 9</figref>, the fraud detection system <b>118</b> displays a Rule Editor screen page <b>900</b> to the user <b>112</b>. The Rule Editor screen page <b>900</b> includes a Rule Definition section <b>910</b> and a Rule Conditions section <b>920</b>. The Rule Editor page <b>900</b> also include an “Edit Rule Configuration in Profiles” button <b>930</b>, a “Save” button <b>931</b>, a “Cancel” button <b>932</b>, an “Apply” button <b>933</b>, a “Copy Rule” button <b>934</b>, and a “Delete Rule” button <b>935</b>.

The Rule Definition section <b>910</b> includes text fields for rule name <b>911</b> and rule description <b>912</b>, a category drop-box <b>913</b>, a core rule selector box <b>914</b>, and an action selector drop-box <b>915</b>. The category drop-box <b>913</b> can include all the fraud detection rule categories <b>820</b> as shown in <figref idref="DRAWINGS">FIG. 8</figref>, and allows the user <b>112</b> to select the fraud detection rule category to place the new fraud detection rule. The core rule selector box <b>914</b> allows the user <b>112</b> to select whether to designate the new fraud detection rule as a core fraud detection rule, and the action drop-box <b>915</b> allows the user to designate an action to be taken when the core fraud detection rule is triggered. As shown in <figref idref="DRAWINGS">FIG. 12</figref>, embodiments of the invention the action selector drop-box <b>915</b> includes the following as possible actions: accept, reject, review, and monitor.

The Rule Conditions section <b>920</b> includes rule triggering radio boxes <b>921</b> allowing the user <b>112</b> to choose whether the fraud detection rule should be triggered as “True” if “all conditions below are true” or “at least one condition below is true.” In embodiments, the user <b>112</b> can set a plurality of conditions and determine whether all or some rules should apply in order to trigger the fraud detection rule. The Rule Conditions section <b>920</b> also includes an order element drop-box <b>922</b> that allows a user <b>112</b> to select an element contained in a received transaction to evaluate for a fraud detection rule.

In step <b>630</b>, the user <b>112</b> completes fields for the new fraud detection rule and establishes one or more rule conditions for the new fraud detection rule. <figref idref="DRAWINGS">FIG. 10</figref> includes more details in the Rule Conditions section <b>1020</b>. Once a user <b>112</b> selects an order element from the Order Element drop-box <b>1022</b>, the Comparison Operator drop-box <b>1023</b>, Comparison Value(s) drop-box <b>1024</b>, and a Custom Value text field <b>1025</b> are presented on the Rule Editor screen page <b>1000</b> displayed to the user <b>112</b>. In the example shown in <figref idref="DRAWINGS">FIG. 10</figref>, the Order Element is “Shipping City”, the Comparison Operator is “contains,” the Comparison Value(s) is “Custom Value”, and the Custom Value is “Cupertino.” When the user <b>112</b> selects the “OK” button <b>1026</b>, the Rule Condition “Shipping city contains ‘Cupertino’” will be created as a condition for the fraud detection rule to be triggered. The Rule Editor screen page <b>1100</b> in <figref idref="DRAWINGS">FIG. 11</figref> shows further details for the new fraud detection rule including a new condition: “Amount (Grand Total) is greater than 500 USD. Applies to orders in all currencies.” As designated by the selected radio box <b>1121</b>, both conditions shown in the example of <figref idref="DRAWINGS">FIG. 11</figref> must be true for the new fraud detection rule to be triggered. In embodiments, the user <b>112</b> transmits conditions for creating a new core fraud detection by the client computer <b>114</b> associated with the user <b>112</b>.

In step <b>635</b>, the user <b>112</b> optionally designates the new fraud detection rule a core fraud detection rule. In the example shown on the Rule Editor page <b>1200</b> in <figref idref="DRAWINGS">FIG. 12</figref>, the Core Rule selector box <b>1214</b> has been checked, indicating that the new fraud detection rule has been designated a core fraud detection rule by the user <b>112</b>. Further, the user <b>112</b> has completed the Name text field <b>1211</b> (naming the rule “Cupertino Order”) and the Description text field <b>1212</b>, and selected “Consumer Data Validation” as the fraud detection rule category.

In step <b>640</b>, the user <b>112</b> designates an action to be taken if the new fraud detection rule is triggered by a received transaction. As described previously, the user <b>112</b> has the option of selecting from accept, reject, review and monitor. Embodiments of the invention may include all these options, fewer than these options, or additional options. In the example shown on the Rule Editor page <b>1200</b> in <figref idref="DRAWINGS">FIG. 12</figref>, the user <b>112</b> has set the action selector drop-box <b>1215</b> to “Monitor.”

In step <b>645</b>, the user <b>112</b> saves the rule to the fraud detection system <b>118</b>. Once the user <b>112</b> has completed all the fields in the Rule Editor screen page <b>1200</b>, the user <b>112</b> can select to save the rule to the fraud detection system <b>118</b> by selecting the “Save” button <b>1231</b>. In embodiments, the server computer <b>118</b>(A) receives a selection of fraud detection rules from a client computer <b>114</b> associated with a user <b>112</b>. The selection of fraud detection rules are received over a communications medium <b>116</b> (e.g. the Internet). As noted previously, the selection of fraud detection rules may be fraud detection rules provided by the fraud detection system <b>118</b>, fraud detection rules created by the user <b>112</b>, or a combination of both.

In step <b>650</b>, the fraud detection system <b>118</b> stores the new fraud detection rule to the fraud rules database <b>118</b>(K). In embodiments, if the new fraud detection rule is a core fraud detection rule, the fraud detection system stores the new fraud detection rule as part of the core fraud detection rule set in the fraud rules database <b>118</b>(K). In other embodiments, the new fraud detection rule may be stored with the associated merchant profile in the merchant profiles database <b>118</b>(L). Once the new fraud detection rule has been stored to the fraud detection system <b>118</b>, the rule is displayed in the appropriate fraud detection rule category <b>1320</b> as shown in <figref idref="DRAWINGS">FIG. 13</figref>. The Custom Rules page <b>1300</b> shown in <figref idref="DRAWINGS">FIG. 13</figref> shows that the “Cupertino Orders” created by the user <b>112</b> is in the Consumer Data Validation fraud detection rule category as designated by the user in <figref idref="DRAWINGS">FIG. 12</figref>. For the fraud detection rules that the user <b>112</b> has designated as core fraud detection rules, the server computer <b>118</b>(A) in the fraud detection system <b>118</b> may associate them as a core fraud detection rule set for the user <b>112</b>. Thus, when the user <b>112</b> wants to create a new merchant profile loaded with the user's core fraud detection rule set, the fraud detection system <b>118</b> can do so.

<figref idref="DRAWINGS">FIG. 14</figref> is a flowchart of a method <b>1400</b> for generating a new merchant profile and loading it with a core fraud detection rule set, through a system shown in <figref idref="DRAWINGS">FIGS. 1, 2, and 15-18</figref>.

In step <b>1405</b>, a user <b>112</b> logs into the fraud detection system <b>118</b> using authorized credentials associated with a merchant. In embodiments of the invention, the fraud detection system <b>118</b> authenticates the identity of the user <b>112</b> prior to permitting the user <b>112</b> to make modifications to a selection of fraud detection rules by verifying a login ID and password of the user <b>112</b>. In embodiments, the fraud detection system <b>118</b> accesses a user authentication module <b>118</b>(B) in order to authenticate the user <b>112</b>. The user <b>112</b> may be a merchant, the individual who established the merchant profile or an employee of the merchant who has been given access to the fraud detection system <b>118</b>. The user <b>112</b> may be an individual who has fraudulently obtained authorized credentials in order to modify the merchant profile and fraud detection rules associated with the merchant profile in order to facilitate fraudulent activity (e.g. fraudulent transactions). An exemplary login screen is described above with respect to <figref idref="DRAWINGS">FIG. 7</figref>.

In step <b>1410</b>, the user <b>112</b> selects the Profiles option from the Fraud Rule Controls menu option <b>804</b> and is taken to the Profiles page. <figref idref="DRAWINGS">FIG. 15</figref> depicts the default Profiles screen <b>1500</b> when a user <b>112</b> selects the “Custom Rules” option from the menu options. In this example, the “Order Profiles” section <b>1510</b> includes a table with a Name column <b>1511</b> and a Description column <b>1512</b>, and select box options <b>1513</b>. The screen also provides the option of creating a new merchant profile pre-filled with core fraud detection rules by selecting the “Add Profile With Core Rules” button <b>1514</b> or creating a new merchant profile without any fraud detection rules by selecting the “Add Empty Profile” button <b>1515</b>. Merchant profiles can be deleted by selecting the corresponding select box option <b>1513</b> and selecting the “Delete” button <b>1516</b>. The merchant profile named “ruleTest profile” is set as default active and passive as denoted by the “A|P” shown in the Description column <b>1512</b> in the “Order Profiles” section of <figref idref="DRAWINGS">FIG. 15</figref>. The “Profile Selectors” section <b>1520</b> includes a table with a Rule Name column <b>1523</b>, a Rule Description column <b>1524</b>, and an Order Profile column <b>1525</b>. The screen also provides the option of creating a new profile selector rule by selecting the “Add Selector Rule” button <b>1527</b>. Profile selector rules can be deleted by selecting the corresponding select box option and selecting the “Delete” button <b>1528</b>. The “Profile Selector” section <b>1520</b> of <figref idref="DRAWINGS">FIG. 15</figref> shows that the “Active Selectors” tab <b>1521</b> has been selected and again shows that the merchant profile named “ruleTest profile” is the default active merchant profile in the drop-box <b>1526</b>. The “Passive Selectors” tab <b>1522</b> would similarly show that the profile named “ruleTest profile” is the default passive merchant profile.

In step <b>1415</b>, the fraud detection system <b>118</b> presents the user <b>112</b> with a set of pre-existing merchant profiles. In the example shown on the Profiles screen <b>1500</b> in <figref idref="DRAWINGS">FIG. 15</figref>, there are three pre-existing merchant profiles: Example, Test profile, and ruleTest profile. In embodiments, a user <b>112</b> may have a plurality of merchant profiles that are directed to different business needs of the merchant. There may also be default profiles created by the fraud detection system <b>118</b> which a user <b>112</b> can select and modify to meet their business needs.

In step <b>1420</b>, the user <b>112</b> selects the “Add Profile With Core Rules” option button <b>1514</b>. In embodiments, the user <b>112</b> transmits, by the client computer <b>114</b> to the fraud detection system <b>118</b> via a communications medium <b>116</b>, a request to generate a second merchant profile for the user. In embodiments, the request can be in the form of selecting options on an Internet-based webpage. In embodiments of the invention, selecting the “Add Profile With Core Rules” option button <b>1514</b> allows the user <b>112</b> to create a new merchant profile that is automatically populated with the fraud detection rules that have been designated as a core fraud detection rules set by the fraud detection system <b>118</b> as well as those designated as core fraud detection rules by the user <b>112</b>. For example, if the user <b>112</b> created a first merchant profile following the steps described with respect to <figref idref="DRAWINGS">FIG. 6</figref>, the user <b>112</b> can direct the fraud detection system <b>118</b> to generate a second merchant profile that is automatically populated with the user's <b>112</b> core fraud detection rule set. In embodiments, the second merchant profile is automatically populated with the user's <b>112</b> core fraud detection rule set by the server computer <b>118</b>(A) in the fraud detection system <b>118</b>.

In step <b>1425</b>, the fraud detection system <b>118</b> presents the user <b>112</b> with a Profile Editor Page. <figref idref="DRAWINGS">FIG. 16</figref> depicts an exemplary Profile Editor screen <b>1600</b> that the user <b>112</b> can use to create a new merchant profile. A similar page would be displayed if a user <b>112</b> wanted to modify an existing merchant profile. In the embodiment shown in <figref idref="DRAWINGS">FIG. 16</figref>, the Profile Editor screen <b>1600</b> is comprised of four sections: a Profile Definition section <b>1610</b>, a Queue Selection section <b>1620</b>, a Fraud Score section <b>1630</b>, and a Rule section <b>1640</b>. The user can select the save button <b>1601</b>, the cancel button <b>1602</b>, or the apply button <b>1603</b> in order to save the merchant profile, cancel modifications to the merchant profile, or apply modifications to the merchant profile, respectively.

The Profile Definition section <b>1610</b> is composed of a Name text field, a Description text field, and a Priority drop-box.

The Queue Selection section <b>1620</b> is composed of two drop-boxes: one allows the user <b>112</b> to choose which queue to send transactions that have been marked “Review”, and another allows the user <b>112</b> to choose which queue to send transactions that have been marked “Reject”.

The Fraud Score section <b>1630</b> is composed of a drop-box that allows the user <b>112</b> to select a risk model for their business and establish fraud score thresholds. In embodiments of the invention, the selected risk model is used to assess the fraud score for received transactions. In the example shown in <figref idref="DRAWINGS">FIG. 16</figref>, the Risk Model is set to the Customer's billing country, and the fraud score thresholds are at default values (0 to 39=Ignore, 40-70=Review, and 71-99=Reject). The user <b>112</b> can adjust the sliding scale to adjust the fraud score thresholds to desired values.

As shown in <figref idref="DRAWINGS">FIG. 17</figref>, risk model options may include, but are not limited to those shown in the risk model drop-box. They can include the U.S. model, the Canada model, the APAC model, the CEMEA model, the EU model, the LATAM model, the Travel model, and the Digital model. Embodiments of the invention can include these risk models, additional risk models, or fewer risk models.

The Rule section <b>1640</b> is composed of fraud detection rule categories that have been pre-loaded into the new merchant profile. As shown in <figref idref="DRAWINGS">FIG. 16</figref>, there are seven fraud detection rule categories: Address Verification, Card Verification Number, Consumer Data Validation, Order Data Quality, Other Tests, Payer Authentication, and Velocity. Embodiments of the invention may include these categories, a combination of these categories and other categories, or other categories entirely. The Profile Editor screen <b>1600</b> also provides the user <b>112</b> with the option to View All Rule(s) <b>1641</b> and Create Custom Rules <b>1642</b>.

In step <b>1430</b>, the user <b>112</b> completes the required fields and settings for a new merchant profile and establishes profile conditions. The user <b>112</b> may enter a name, profile description, queue selections, and set fraud score settings, as described above. In some embodiments, all these setting must be completed before a user <b>112</b> can be allowed to save the new merchant profile. In other embodiments, only some and not all of the setting must be completed before a user <b>112</b> can be allowed to save the new merchant profile. In the example Profile Editor screen <b>1700</b> in <figref idref="DRAWINGS">FIG. 17</figref>, the “ReviewQueue” and “RejectQueue” have been selected as the queues to send transactions that have been marked for review and reject, respectively.

In step <b>1435</b>, the user <b>112</b> optionally selects which fraud detection rules to include in the merchant profile and an action to be taken when a fraud detection rule is triggered. <figref idref="DRAWINGS">FIG. 18</figref> is an example of the Rule section <b>1640</b> showing fraud detection rule selections by the user <b>112</b>. In some embodiments, fraud detection rules can be set to monitor, accept, review or reject by the user <b>112</b>.

In step <b>1440</b>, the user <b>112</b> saves the new profile to the fraud detection system <b>118</b>. As shown in <figref idref="DRAWINGS">FIG. 17</figref>, the save button <b>1701</b> allows the user <b>112</b> to select to have the new merchant profile saved to the fraud detection system <b>118</b>.

In step <b>1445</b>, the fraud detection system <b>118</b> stores the new merchant profile to the merchant profiles database <b>118</b>(L). Once the new merchant profile has been stored to the fraud detection system <b>118</b>, the new merchant profile can be accessed and modified by selecting the “Profiles” option from the Fraud Rule Controls menu <b>804</b>, as shown in <figref idref="DRAWINGS">FIG. 8</figref>. The merchant profile is stored in the merchant profiles database <b>118</b>(L) as shown in <figref idref="DRAWINGS">FIG. 2</figref>.

<figref idref="DRAWINGS">FIG. 19</figref> is a flowchart of a method <b>1900</b> through a system shown in <figref idref="DRAWINGS">FIGS. 1, 2, 20 and 21</figref> for selecting a fraud detection rule and modifying one or more merchant profiles to either add the selected fraud detection rule or remove the selected fraud detection from a profile,

In step <b>1905</b>, a user <b>112</b> logs into the fraud detection system <b>118</b> using authorized credentials associated with a merchant. In embodiments of the invention, the fraud detection system <b>118</b> authenticates the identity of the user <b>112</b> prior to permitting the user <b>112</b> to make modifications to a selection of fraud detection rules by verifying a login ID and password of the user <b>112</b>. In embodiments, the fraud detection system <b>118</b> accesses a user authentication module <b>118</b>(B) in order to authenticate the user <b>112</b>. The user <b>112</b> may be a merchant, the individual who established the merchant profile or an employee of the merchant who has been given access to the fraud detection system <b>118</b>. The user <b>112</b> may be an individual who has fraudulently obtained authorized credentials in order to modify the merchant profile and fraud detection rules associated with the merchant profile in order to facilitate fraudulent activity (e.g. fraudulent transactions). An exemplary login screen is described above with respect to <figref idref="DRAWINGS">FIG. 7</figref>.

In step <b>1910</b>, the user <b>112</b> selects the custom rules option from the Fraud Rule Controls menu option <b>804</b> and is taken to the Custom Rules page. An exemplary Custom Rules page <b>800</b> is described above with respect to <figref idref="DRAWINGS">FIG. 8</figref>.

In step <b>1915</b>, the fraud detection system <b>118</b> presents the user <b>112</b> with a set of fraud detection rules. The fraud detection rules are presented in categorized form. As shown in <figref idref="DRAWINGS">FIG. 8</figref>, there may be a plurality of fraud detection rule categories <b>820</b>. Each fraud detection rule category has a title and indicates the number of rules contained in the fraud detection rule category. Further, each fraud detection rule category box has a core rule indicator <b>821</b> (where a “C” character indicates that the rule is a core fraud detection rule), a fraud detection rule name field <b>822</b>, and a fraud detection rule description field <b>823</b>. For example, in <figref idref="DRAWINGS">FIG. 8</figref>, the default fraud detection rule categories include: Address Verification, Card Verification Number, Consumer Data Validation, Order Data Quality, Other Tests, Payer Authentication, Velocity and Uncategorized. Embodiments of the invention may include these categories, a combination of these categories and other categories, or other categories entirely.

In step <b>1920</b>, the user <b>112</b> selects one of the core fraud detection rules from the presented set of fraud detection rules. For example, the user may select the fraud detection rule named “CVN not submitted,” as shown in the Custom Rules page <b>800</b> in <figref idref="DRAWINGS">FIG. 8</figref>.

In step <b>1925</b>, the fraud detection system <b>118</b> displays the Rule Editor page for the corresponding fraud detection rule selected by the user <b>112</b>. For example, the Rule Editor page screen <b>2000</b> shown in <figref idref="DRAWINGS">FIG. 20</figref> shows the Rule Editor page for the fraud detection rule named “CVN not submitted.” The features of the Rule Editor page were previously discussed with reference to <figref idref="DRAWINGS">FIGS. 9-12</figref>.

In step <b>1930</b>, the user <b>112</b> selects the “Edit Rule Configuration in Profiles” option. As shown in <figref idref="DRAWINGS">FIG. 20</figref>, the user <b>112</b> can select the “Edit Rule Configuration in Profiles” button <b>2030</b>.

In step <b>1935</b>, the fraud detection system <b>118</b> displays a pop-up box to the user <b>112</b> that lists all of the merchant profiles associated with the user <b>112</b>. In embodiments, the fraud detection system <b>118</b> displays a Rule Configuration in Profiles pop-up box <b>2110</b> as shown in <figref idref="DRAWINGS">FIG. 20</figref>. In other embodiments of the invention, the fraud detection system <b>118</b> may direct the user <b>112</b> to a separate Internet webpage, or may present the data contained in the Rule Configuration in Profiles pop-up box <b>2110</b> in any other appropriate manner.

In step <b>1940</b>, the user <b>112</b> designates merchant profiles to which the selected fraud detection rules is to be added to. The user <b>112</b> also designates what action to take with respect to the fraud detection rule in each of the merchant profiles. In embodiments, the user <b>112</b> transmits a request to add the selected fraud detection rule to one or more of a plurality of merchant profiles. The data is transmitted from the client computer <b>114</b> to the server computer <b>118</b>(A) in the fraud detection system <b>118</b>. In embodiments, the request can be in the form of selecting options on an Internet-based webpage. The user <b>112</b> also has the option to remove the fraud detection rule from selected merchant profiles by de-selecting the action boxes in the corresponding merchant profile. In the example shown in <figref idref="DRAWINGS">FIG. 20</figref>, there are nine merchant profiles associated with the user <b>112</b>, of which six already include the “CVN not submitted” fraud detection rule. The remaining three merchant profiles (Low Risk, Profile A, and Profile C) do not contain the fraud detection rule. In embodiments, the user <b>112</b>, by the client computer, selects an action for the fraud detection rule for each of the one or more of the plurality of previously generated merchant profiles. As shown in <figref idref="DRAWINGS">FIG. 21</figref>, the user <b>112</b> can select to have a transaction that triggers the fraud detection rule accepted, reviewed, rejected, or monitored. The user <b>112</b> can add the fraud detection rule to none, some or all of the three merchant profiles the fraud detection rule is not in, or the user <b>112</b> can remove the fraud detection rule from none, some, or all of the six merchant profiles the fraud detection rule is currently in. In embodiments of the invention, the user <b>112</b> associates an action with the selected core fraud detection rule for each of the one or more of the plurality of previously generated merchant profiles. The user <b>112</b> has the option of selecting an action from the following: monitor, accept, reject, or review.

In step <b>1945</b>, the user <b>112</b> saves the fraud detection rule to the selected merchant profile or profiles. Once the user <b>112</b> has made the desired modifications to the merchant profiles in the Rule Configuration in Profiles pop-up box <b>2110</b> in <figref idref="DRAWINGS">FIG. 21</figref>, the user <b>112</b> can select to save the modification to the fraud detection rule and the merchant profiles to the fraud detection system <b>118</b> by selecting the “Save” button <b>1231</b>.

In step <b>1950</b>, the fraud detection system <b>118</b> stores the modification to the fraud detection rule to the corresponding merchant profile in the merchant profiles database <b>118</b>(L). In embodiments, the new core fraud detection rule is stored in the fraud rules database <b>118</b>(L) and associated with the one or more of the plurality of previously generated merchant profiles in a merchant profiles database <b>118</b>(L). In this manner, the selected fraud detection rule is associated with one or more of the previously generated merchant profiles without requiring the user <b>112</b> to individually access each merchant profile to make the modification.

III. Technical Benefits

Embodiments of the invention provide the technical benefits of efficiency and conserving resources. By establishing a set of core fraud detection rules that can be automatically populated into new merchant profiles, resources are saved as it is not necessary to access each fraud detection rule and add them one by one into a merchant profile. A merchant may require dozens of different merchant profiles to fit their business needs and it would be inefficient to require a merchant to access the fraud detection system for each fraud detection rule to be added to each merchant profile.

Additional efficiency and conservation of resources are achieved by allowing a merchant to automatically add a new core fraud detection rule to a plurality of existing merchant profiles at once. This allows a merchant to create new fraud detection rules and then be able to add that rule to any or all of the merchant's profiles without requiring the merchant to interact with each merchant profile beyond the Edit Rule Configuration in Profiles pop-up box.

Another technical benefit with embodiments of the claimed invention is a reduction in the chances of transcription errors if a set of core fraud detection rules is automatically populated in a merchant's new merchant profile. For example, a merchant may have several dozen rules that the merchant requires in a plurality of merchant profiles. Being able to generate and save a single set of core fraud detection rules, and then apply that set of core fraud detection rules uniformly across the merchant's profiles, ensures that there is uniformity across profiles.

Another technical benefit with embodiments of the claimed invention is conserving resources for transaction processing. For example, when the number or percentage of transactions that are flagged for review changes drastically (e.g., the number of transactions flagged for review goes from 10 per hour to 500 per hour), the operator of the fraud detection system can determine whether or not a change to one of the fraud detection rules caused the increase for the merchant. Adjustments can then be made to settings and conditions, allowing the merchant to conserve resources that would otherwise be expended processing transactions that do not require review. Also, if a merchant wants to add a new fraud detection rule to one or more of a plurality of merchant profiles, embodiments of the claimed invention allow the merchant to do so quickly by accessing the Edit Rule Configuration in Profiles option, rather than have to manually go into each merchant profile and make the modification.

IV. Additional Embodiments

Embodiments of the invention may include an audit trail capability. An audit trail capability is described in U.S. patent application Ser. No. 13/451,431, filed on Apr. 19, 2012. Embodiments of the invention are directed to a fraud detection system that records an audit log of modifications made by a user to a selection of fraud detection rules in a merchant profile. The audit log contains details of the modifications and the user associated with the modifications. A search can be conducted on the audit log to determine details of modifications made to a merchant profile within the fraud detection system. In this manner, by automating a search of fraud detection rule modifications, the merchant is saved the time and resources it would have to spend going through all its fraud detection rules to determine what changes may or may not have been made to its fraud detection rules and merchant profile.

Embodiments of the claimed invention may further include a profile rule performance report. A fraud detection system comprising a profile rule performance report is described in Provisional U.S. Patent Application No. 61/636,352, filed Apr. 20, 2012. Embodiments of the invention are directed to a method comprising, receiving, at a server computer, one or more transactions from a merchant processor computer, analyzing, by the server computer, the one or more transactions against a plurality of fraud detection rules contained in a merchant profile, determining, by the server computer, an action to be taken based on the analysis of the one or more transactions, receiving, at the server computer, search parameters for conducting a search of the merchant profile in the fraud detection system, generating, by the server computer, a statistical report containing results of the one or more transactions analyzed against the plurality of fraud detection rules for the merchant, and displaying, by the server computer, the statistical report. In this manner, a user can get a statistical analysis of its fraud detection rules in its merchant profiles and determine how each rule acted on the user's system. For example, a user may be able to determine whether a fraud detection rule is effectively being triggered or if a fraud detection rule is slowing the process down by unnecessary marking transaction for review.

V. Exemplary Computer Apparatuses

The various participants and elements may operate one or more computer apparatuses (e.g., a server computer) to facilitate the functions described herein. Any of the elements in the figures may use any suitable number of subsystems to facilitate the functions described herein. Examples of such subsystems or components are shown in <figref idref="DRAWINGS">FIG. 22</figref>. The subsystems shown in <figref idref="DRAWINGS">FIG. 22</figref> are interconnected via a system bus <b>2200</b>. Additional subsystems such as a printer <b>2208</b>, keyboard <b>2216</b>, fixed disk <b>2218</b> (or other memory comprising computer readable media), monitor <b>2212</b>, which is coupled to display adapter <b>2210</b>, and others are shown. Peripherals and input/output (I/O) devices, which couple to I/O controller <b>2202</b>, can be connected to the computer system by any number of means known in the art, such as serial port <b>2214</b>. For example, serial port <b>2214</b> or external interface <b>2220</b> can be used to connect the computer apparatus to a wide area network such as the Internet, a mouse input device, or a scanner. The interconnection via system bus <b>2200</b> allows the central processor <b>2206</b> to communicate with each subsystem and to control the execution of instructions from system memory <b>2204</b> or the fixed disk <b>2218</b>, as well as the exchange of information between subsystems. The system memory <b>2204</b> and/or the fixed disk <b>2218</b> may embody a computer readable medium.

Further, while the present invention has been described using a particular combination of hardware and software in the form of control logic and programming code and instructions, it should be recognized that other combinations of hardware and software are also within the scope of the present invention. The present invention may be implemented only in hardware, or only in software, or using combinations thereof.

The software components or functions described in this application may be implemented as software code to be executed by one or more processors using any suitable computer language such as, for example, Java, C++ or Perl using, for example, conventional or object-oriented techniques. The software code may be stored as a series of instructions, or commands on a computer-readable medium, such as a random access memory (RAM), a read-only memory (ROM), a magnetic medium such as a hard-drive or a floppy disk, or an optical medium such as a CD-ROM. Any such computer-readable medium may also reside on or within a single computational apparatus, and may be present on or within different computational apparatuses within a system or network.

The present invention can be implemented in the form of control logic in software or hardware or a combination of both. The control logic may be stored in an information storage medium as a plurality of instructions adapted to direct an information processing device to perform a set of steps disclosed in embodiments of the present invention. Based on the disclosure and teachings provided herein, a person of ordinary skill in the art will appreciate other ways and/or methods to implement the present invention.

It is understood that the examples and embodiments described herein are for illustrative purposes only and that various modifications or changes in light thereof will be suggested to persons skilled in the art and are to be included within the spirit and purview of this application and scope of the appended claims. All publications, patents, and patent applications cited in this patent are hereby incorporated by reference for all purposes.

One or more features from any embodiment may be combined with one or more features of any other embodiment without departing from the scope of the disclosure.

In embodiments, any of the entities described herein may be embodied by a computer that performs any or all of the functions and steps disclosed.

Any recitation of “a”, “an” or “the” is intended to mean “one or more” unless specifically indicated to the contrary.

The above description is illustrative and is not restrictive. Many variations of the invention will become apparent to those skilled in the art upon review of the disclosure. The scope of the invention should, therefore, be determined not with reference to the above description, but instead should be determined with reference to the pending claims along with their full scope or equivalents.