Patent Application
20120278868
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. The merchant may have no way of determining when a fraud rule was modified or who may have done the modification.
Further, new and enhanced methods of detecting fraud with greater merchant services have become increasingly necessary to provide greater security and functionality.
Embodiments of the invention address the above problems, and other problems, individually and collectively.
Embodiments of the present invention are directed to systems and methods for processing search parameters through a fraud detection system configured to record and provide an audit log containing modifications to a selection of fraud detection rules and users associated with each modification.
One embodiment of the invention is directed to a method comprising receiving a modification to a selection of fraud detection rules from a client computer operated by a user at a server computer. The modification is recorded in a database by the server computer and the user is associated with the modification. The method may also comprise searching the database, by the server computer, for modifications associated with a first fraud detection rule, and returning a search result based on the modifications to the first fraud detection rule.
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 receiving a modification to a selection of fraud detection rules from a client computer operated by a user at the server computer. The modification is recorded in a database by the server computer and the user is associated with the modification. The method may also comprise searching the database, by the server computer, for modifications associated with a first fraud detection rule, and returning a search result based on the modifications to the first fraud detection rule.
Another embodiment of the invention is directed to a method comprising transmitting, by a client computer to a fraud detection system via a communications network, a set of search parameters. The search parameters are transmitted for conducting a search for modifications to a selection of fraud detection rules in a merchant profile in a fraud rules modification database. The method may also comprise receiving, at the client computer, from the fraud detection system, a search result based on the set of search parameters.
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 transmitting, by the client computer to a fraud detection system via a communications network, a set of search parameters. The search parameters are transmitted for conducting a search for modifications to a selection of fraud detection rules in a merchant profile in a fraud rules modification database. The method may also comprise receiving, at the client computer from the fraud detection system, a search result based on the set of search parameters
These and other embodiments of the invention are described in further detail below with reference to the Figures and the Detailed Description.
Prior to discussing embodiments of the invention, some 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 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 rule, and for further processes or actions to be taken if the fraud detection rule is triggered. Each fraud detection rule may further allow for rule conditions to be established based on a number of criteria.
The term “merchant profile” may include a selection of fraud detection rules and settings established by a merchant 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 be associated with one or more users who have access to modify the selection of fraud detection rules contained in the merchant profile.
The term “modification” may include additions, deletions, conversions, or any alterations to a preexisting fraud detection rule. It may also refer to additions, deletions, conversions, or any alternations to a merchant profile. Modification may also refer to the creation of new fraud detection rules or merchant profiles. For example, the modification may be to add or delete a condition within a fraud detection rule, and/or the modification may be to add or delete an entire fraud detection rule within a merchant profile. Modifications may also refer to changes to text fields and setting contained within a fraud detection rule or merchant profile.
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 “fraud rules modification database” may refer to a database in the fraud detection system that stores information regarding modifications made to settings and/or conditions in fraud detection rules and/or merchant profiles. The fraud rules modification database may further store information regarding the user ID of users that effected the modifications to fraud detection rules and/or merchant profiles.
The term “recording” may include storing information regarding a modification to a fraud detection rule or a merchant profile into a database. Recording may also include storing information as to the user ID of a user who effected the modification to the fraud detection rule and/or merchant profile. The recording may be accomplished by the server computer in the fraud detection system and may be stored in a fraud rules modification database. For example, if a given 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 “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 term “search parameters” may refer to constraints for a search. They may include settings and text fields that a user can customize in order to conduct an audit log search of the fraud rules modification database. For example, search parameters may include, but are not limited to, a date range, a category, a subcategory, and user name and keyword fields. The user may conduct a search of the fraud rules modification database once the user has established the search parameters for conducting the search.
The term “search result” may refer to a result of a search for information. It may include information displayed as an output of an audit log search of the fraud rules modification database. The search result may include information as to modifications made to fraud detection rules and/or merchant profiles, as well as the corresponding identification information for the user logged into the system that made the modifications (e.g. merchant ID, organization ID, and user ID). The search result may further include the date of the modification, the subcategory of the fraud detection rule modified, and a keyword, which may indicate the name of the rule or condition modified.
The term “parsing” may refer to any suitable analysis process for analyzing data. In some embodiments, a computer may parse search results presented in an audit log search. For example, the fraud detection system can narrow the outputted search results to include only those modifications made by a specific user. When a user conducts a search, the user may further enter a set of characters (e.g. a user ID, a fraud detection rule, etc.) that is used by the fraud detection system in evaluating the outputted search results. The fraud detection system may then remove any search results that do not include the characters entered.
Example embodiments are typically implemented in the context of a financial transaction. Therefore, prior to further discussing an audit log search capability within a fraud detection system, a brief description of transaction processing will be presented.
An exemplary system 100 for transaction processing can be seen in
The consumer client computer 106 may communicate with the merchant computer 110 via a communications medium 108, such as a network (e.g. the Internet). Similarly, the merchant client computer 114 may communicate with the fraud detection system 118 via a communications medium 116, such as a network (e.g. the Internet).
The consumer 102 may be an individual, or an organization such as a business, that is capable of purchasing goods or services. The user 112 may be a merchant, an employee of the merchant, or any other individual who has access to the merchant client computer 114.
The consumer payment device 104 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 104 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 102 can use the consumer client computer 106, which is communicatively coupled to the merchant computer 110 via the communications medium 108 in order to conduct a transaction with the merchant. The consumer client computer 106 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 106 transmits data through the communications medium 108 to the merchant computer 110. In some embodiments of the invention, the consumer payment device 106 and the consumer client computer 106 may be a single device.
As depicted in
The server computer 118(A) may be operatively coupled to one or more databases. The one or more databases may comprise a user database 118(J), a fraud rules database 118(K), a merchant profiles database 118(L) and a fraud rules modification database 118(M).
The user authentication module 118(B) handles the verification of the authorization credentials for a user (e.g. merchant ID, user name, password). The user authentication module 118(B) may access a user database 118(J) in determining whether a user 112 seeking access to the fraud detection system 118 is an authorized user. For example, when presented with credentials, the user authentication module 118(B) may access the user database 118(J) to determine whether the provided user name is in the user database 118(J) and whether the provided password corresponds to the password linked to the user name.
The rule modification module 118(C) receives modifications from a user 112 to fraud detection rules or to a merchant profile. The rule modification module 118(C) may further access the merchant profiles database 118(L) to store modifications made to a merchant profile. For example, when a user 112 makes a modification, the rule modification module 118(C) may access a merchant profile database 118(L) associated with the authorization credentials entered by the user 112. The rule modification module 118(C) may also access the fraud rules database 118(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 118(L) with the corresponding merchant profile.
The user association module 118(D) may associate any modifications made by a user 112 with the authorization credentials entered by the user 112. For example, if the user 112 logged into the fraud detection system 118 with the user name “user1,” the user association module 118(D) may record all the modifications made by the user 112, associate the modifications with the user name “user1,” and store the data in the fraud rules modification database 118(M).
The transaction analyzer module 118(E) may evaluate transaction data received by the fraud detection system 118 from the merchant processor computer 120. In embodiments of the invention, the fraud detection system 118 receives the authorization response message from the merchant processor computer 120 and the message is analyzed by the transaction analyzer module 118(E). If the result from the transaction analyzer module 118(E) is an “ACCEPT”, the transaction between the merchant and the consumer 102 can be completed. If the result from the transaction analyzer module 118(E) is a “REJECT”, the fraud detection system 118 would return a message to be presented to the consumer 102 that the consumer 102 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 102 may be attempting to conduct fraudulent transactions. If the result from the transaction analyzer module 118(E) is a “REVIEW”, the fraud detection system 118 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 118 can automatically invoke a settlement upon an accept decision by the transaction analyzer module 118(E).
The audit search module 118(F) handles the audit log search function of the fraud detection system 118. The audit search module 118(F) receives input from a user 112 comprising search parameters to conduct an audit log search. The audit search module 118(F) processes the search parameters and conducts a search of the fraud rules modification database 118(L).
The data output module 118(G) outputs the results of the audit log search conducted by the audit search module 118(F) to be displayed to the user 112.
The display module 118(H) displays the layout of the fraud detection system 118. In embodiments of the invention, the fraud detection system 118 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 118 to be displayed in other suitable manners on other suitable display devices.
The reports module 118(I) compiles the data obtained from the fraud detection system 118 from analyzing transactions. In embodiments of the invention, the reports module 118(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 118(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 118(I) can present the full transaction details for each transaction received by the fraud detection system 118.
The user database 118(J) may be used by the server computer 118(A) to store authentication elements for users. For example, the user database 118(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 118(L) in the fraud detection system 118. The user database 118(J) may further store passwords associated with each merchant ID and user name authorized to access the fraud detection system 118.
The fraud rules database 118(K) may be used by the server computer 118(A) to store fraud detection rules that can be added to merchant profiles. In embodiments, a merchant profile can be loaded with pre-existing rules contained in the fraud rules database 118(K). The fraud rules database 118(K) may further store new rules created by a user 112.
The merchant profiles database 118(L) may be used by the server computer 118(A) to store merchant profiles that are customized for each merchant that has created a profile with the fraud detection system 118. The merchant profile database 118(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 118(M) may be used by the server computer 118(A) to store an audit log containing details regarding fraud detection rules, modifications made to the fraud detection rules, and the user name of the user 112 who made the modifications to the fraud detection rules. The data stored in the fraud rules modification database 118(M) may be stored by the rule modification module 118(C) and may be searched by the audit search module 118(F).
Returning now to
The merchant computer 110 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 110 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 110 transmits data through the communications medium 108 to the consumer client computer 106. The merchant computer 110 may also transmit data to a merchant processor computer 120. In embodiments of the invention, the merchant computer 110 receives transaction data from a consumer client computer 106 and transmits the transaction data to the merchant processor computer 120 for fraud evaluation and for further transaction authorization processes. The merchant computer 110 can further communicate with and/or receive input from a merchant client computer 114 operated by a user 112.
As depicted in
The authorization module 120(B) may generate and process authorization request and response messages. The authorization module 120(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 126 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 126 via a payment processing network 124 and an acquirer computer 122.
The transaction review module 120(C) conducts a fraud evaluation for transactions. If the transaction review module 120(C) determines that the transaction may be fraudulent, the transaction review module 120(C) may determine that the transaction should be denied. If the transaction review module 120(C) determines that the transaction is not fraudulent, the transaction review module 120(C) may determine that the transaction should be allowed. If the transaction review module 120(C) is unable to determine whether the transaction is fraudulent, the transaction review module 120(C) can send the transaction for further review.
The routing module 120(D) can route transactions to the appropriate destination. If a transaction is determined to be not fraudulent, the routing module 120(D) can route the message to the acquirer computer 122 for further processing. If the transaction is determined to be fraudulent, the routing module 120(D) can send the transaction back to the merchant. If the fraud evaluation conducted by the transaction review module 120(C) is indeterminate, the transaction can be routed to a further review by a person.
An acquirer computer 122 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 126 is typically a business entity (e.g. a bank) which maintains financial accounts for the consumer 102 and often issues a consumer payment device 104 such as a credit or debit card to the consumer 102. Some entities can perform both issuer computer 126 and acquirer computer 122 functions. Embodiments of the invention encompass such single entity issuer-acquirers.
As depicted in
As noted above, the payment processing network 124 may have or operate at least a server computer 124(A). In some embodiments, the server computer 124(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 124(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 124 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 124 may use any suitable wired or wireless network, including the Internet.
The authorization module 124(C) processes authorization request messages and determines the appropriate destination for the authorization request messages. The clearing and settlement module 124(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 122 and the issuer computer 126. 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 124(E) handles the routing of authorization request messages from the acquirer computer 122 to the issuer computer 126, and the routing the authorization response messages back from the issuer computer 126 to the acquirer computer 122.
Methods according to embodiments of the invention can be described with respect to
In step 505, in a typical transaction, the consumer 102 engages in a transaction for goods or services at a merchant associated with a merchant computer 110 using a consumer client computer 106 and a consumer payment device 104 such as a credit card or mobile phone. For example, the consumer 102 may use their Internet-enabled mobile phone to access a merchant website to conduct a transaction using their consumer payment device 104. In other embodiments, the consumer 102 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 510, a merchant computer 110 receives the transaction from the consumer client computer 106 and may then transmit the transaction details to a merchant processor computer 120. 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 515, the merchant processor computer 120 may conduct a fraud analysis and determine whether the transaction should proceed or whether it should be rejected and returned to the merchant computer 110. The merchant processor computer 120 may use the transaction details in determining whether the transaction may be fraudulent.
In step 520, if the merchant processor computer 120 determines that the transaction details indicate that the transaction may be fraudulent, the merchant processor computer 120 may return the transaction to the merchant computer 110 indicating that the transaction is fraudulent and should be declined.
In step 525, if the merchant processor computer 120 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 530, the generated authorization request message may be transmitted by the merchant processor computer 120 to an acquirer computer 122. The authorization request message may be transmitted in any suitable format.
In step 535, after receiving the authorization request message, the authorization request message may then be transmitted to a payment processing network 124.
In step 540, after receiving the authorization request message, the payment processing network 124 may then transmit the authorization request message to an appropriate issuer computer 126 associated with the consumer payment device 104.
In step 545, the issuer computer 126 receives the authorization request message. The issuer computer 126 may then determine whether the transaction should be authorized. The issuer computer 126 transmits an authorization response message back to the payment processing network 124. The authorization response message can indicate whether or not the current transaction has been authorized or has been declined.
In step 550, the payment processing network 124 may then transmit the authorization response message back to the acquirer computer 122. The acquirer computer 122 may then transmit the response message back to the merchant processor computer 120.
In step 555, the merchant processor computer 120 may then transmit the authorization response message to a fraud detection system 118. The fraud detection system 118 may then undertake a decision process based on the authorization response message. If the result from the fraud detection system 118 is an “ACCEPT”, the transaction between the merchant and the consumer 102 can be completed. If the result from the fraud detection system 118 is a “REJECT”, the fraud detection system 118 would return a message to be presented to the consumer 102 that the consumer 102 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 102 may be attempting to conduct fraudulent transactions. If the result from the fraud detection system 118 is a “REVIEW”, the fraud detection system 118 would “hold” the transaction until it can be further reviewed, and it is determined whether it should be accepted or rejected.
In step 560, after the merchant computer 110 receives the authorization response message, the merchant computer 110 may then provide the authorization response message to the consumer 102. For example, the consumer 102 may be presented with a screen on the consumer client computer 106 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 565, 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 122 and an issuer computer 126 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 118 once the fraud detection system 118 has determined that the transaction should be accepted.
In step 570, the merchant receives payment for the transaction.
In step 605, a merchant accesses the fraud detection system 118 with authorized credentials and establishes a merchant profile with the fraud detection system 118. The merchant profile is stored in a merchant profile database 118(L) and contains customized settings for the merchant profile (e.g. profile name, profile description, selected fraud detection rules, etc.). In embodiments, a merchant may establish a plurality of merchant profiles with a similar or distinct set of fraud detection rules.
In step 610, the merchant populates the merchant profile with a customized set of fraud detection rules. The merchant profile can be populated with fraud detection rules stored in a fraud rules database 118(K). In some embodiments, the merchant may create an empty merchant profile that does not contain any fraud detection rules stores in the fraud rules database 118(K). In such embodiments, the merchant can establish a completely original set of fraud detection rules based on their needs or the needs of their business. In some embodiments, the merchant can create a merchant profile with a combination of fraud detection rules stored in the fraud rules database 118(K) and merchant-created fraud detection rules. In some embodiments, the merchant-created rules may be stored in the merchant profile database 118(L). In other embodiments, the merchant-created rules may be stored in the fraud rules database 118(K). The merchant may also associated one or more users 112 with the merchant profile. The one of more users 112 may be given access to modify the selection of fraud detection rules contained in the merchant profile and/or to modify the merchant profile itself.
In step 615, a user 112 logs into the fraud detection system 118 using authorized credentials associated with the merchant and the merchant profile. In embodiments of the invention, the fraud detection system 118 authenticates the identity of the user 112 prior to permitting the user 112 to make modifications to a selection of fraud detection rules by verifying a login ID and password of the user 112. For example, the user may be the individual who established the merchant profile or an employee of the merchant who has been given access to the fraud detection system 118. The user may also 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).
In step 620, the user 112 makes a modification to the merchant profile or makes a modification to a selection of fraud detection rules in the merchant profile using a client computer 114. For example, the user 112 may modify a fraud detection rule for transactions over $1000 that the fraud detection system 118 marks as “REVIEW”, to “ACCEPT.” In another example, the user 112 may add a rule that orders from a particular credit card number should be marked as “REJECT” by the fraud detection system 118. The rule modification module 118(C) records the modification in the fraud rule database 118(K) and the merchant profile database 118(L).
In step 625, the user association module 118(D) associates the modification with the user 112 by the authorized credentials used to log into the fraud detection system 118. In embodiments of the invention, the user association module 118(D) identifies the user name used to log into the fraud detection system 118 and appends it to data indicating the fraud detection rule modified, the substance of the modification, and the date and time of the modification.
In step 630, the user association module 118(D) records the details regarding the modification to the fraud detection rule or merchant profile in an audit log in the fraud rules modification database 118(M). In embodiments of the invention, recording the details of the modification involves storing the modification and the user ID of the user 112 who made the modifications.
In step 635, the merchant logs into the fraud detection system 118 and conducts an audit log search of its profile. The merchant may conduct an audit log search regularly to monitor its merchant profile or may have been motivated by suspicious transaction activity.
In step 640, the merchant, at a merchant client computer 114, transmits the search parameters over a communications medium 116 to conduct the audit log search for modifications of its merchant profile. The search parameters are received by the fraud detection system 118 over the communications medium 116. Optional search parameters can include, but are not limited to, “Date Range,” “Category,” “Subcategory,” “User Name,” and “Keyword.”
In step 645, the audit search module 118(F) searches the fraud rules modification database 118(M) based on the merchant's search parameters. For example, the merchant can search the fraud rules modification database 118(M) for modifications made to its fraud detection rules by a specific user (e.g. an employee of the merchant with authorized credentials).
In step 650, the data output module 118(G) displays the audit log search results to the merchant showing the modifications made to the fraud detection rules. The search results received by the merchant are based on the set of search parameters.
In order to access the fraud detection system 118, the user 112 must enter authorized credentials when prompted with the login screen 700. The authorized credentials are entered in a Merchant ID field 703, a User Name field 704, and a Password field 705. Once the fields have been filled, the user 112 can select the “Login” button 706 for the credentials to be authorized. If the user 112 has forgotten their password, the user 112 can access a password recovery process by selecting the hyperlink 707.
The search screen in
When the user 112 selects “Custom Range” from the Date Range 831 search parameter, as depicted in
As shown in
Searches conducted with the “Profiles” subcategory selected results in the changes, additions, settings, and deletions made to profiles to be displayed. In embodiments, the setting of a rule in a profile appears in a “Profiles” search, while changes in conditions inside the rule appear in a “Custom Rules” search. This is described in greater detail with reference to
Searches conducted with the “Custom Rules” subcategory selected results in the changes, additions, settings, and deletions made to custom rules and copies made of pre-defined rules to be displayed.
Searches conducted with the “Active Profile Selector” or “Passive Profile Selector” subcategory selected results in the changes, additions, settings, and deletions made to active and passive profile selector rules to be displayed.
Searches conducted with the “Custom Lists” subcategory selected results in the changes, additions, and deletions made to custom lists to be displayed.
Searches conducted with the “Queues” subcategory selected results in the changes, settings, and deletions made to queues to be displayed.
Searches conducted with the “Velocity” subcategory selected results in the changes, additions, settings, and deletions made to product, order, and global velocity rules and settings to be displayed.
Searches conducted with the “Settings” subcategory selected results in the changes made to general Decision Manager settings to be displayed.
Searches conducted with the “Third Party” subcategory selected results in the changes, additions, and deletions made to third-party configuration settings to be displayed.
Searches conducted with the “Reviewer Settings” subcategory selected results in the changes, additions, and deletions made to reviewer settings to be displayed.
Searches conducted with the DMH Group Activation” subcategory selected results in the changes in activation and deactivation of merchants in a group of merchants to be displayed.
Searches conducted with the “DMH Group Management” subcategory selected results in the changes that affect the implementation of merchants in a group of merchants to be displayed.
Searches conducted with the “List Management” subcategory selected results in the changes, additions, conversions, and deletions made to the positive, negative, and review list to be displayed.
Returning to
Additional information and options displayed on the search screen 800 include the login information section 821 containing the user ID, account ID, and merchant ID. The user 112 can log out of the fraud detection system 118 by selecting the “Log Out” option 822. If the user 112 wants additional help, the user 112 can select the “Online Help” option 823. Selecting the triangle-shaped option 837 on the search parameters box 830 allows the user 112 to close or open the search parameters box 830.
Once the user 112 has selected the search parameters for their search, the user 112 selects the “Search” button 836 in order to conduct the search. Exemplary search screen resulting from conducting searches are described with reference to the following examples.
In
Returning to the example described in
Embodiments of the invention provide the technical benefits of efficiency and conserving resources. By establishing a merchant profile comprised of core fraud detection rules and customized fraud detection rules based on an individual merchant's business flow and transaction history, a merchant can efficiently automate a process that would otherwise require significant review by people. Further, the audit log containing modification histories increases efficiency by quickly providing merchants with information as to modifications to fraud detection rules and merchant profiles, as well as the identity of the user who made modifications. 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.
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 or more of the fraud detection rules in the merchant's profile 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.
Another technical benefit with embodiments of the claimed invention is that audit log searches can be conducted to find insider fraud. For example, if an employee with access to a merchant profile and the fraud detection rules within the merchant profile has changed the fraud detection rules in order to allow a co-conspirator to purchase merchandise with stolen credit card numbers, the employee's actions can be tracked.
In other embodiments of the claimed invention, when the fraud detection system processes an authorization response message and determines that the transaction should be marked as “ACCEPT,” the fraud detection system can facilitate the clearing and settlement process on behalf of the merchant.
Embodiments of the claimed invention may further allow additional audit log search result layout customization. The columns as described above may be manipulated in size and order based on user preference. In additional entries within the audit log search result can be sorted in ascending or descending order based on each column. For example, if sorted by the date and time field, the entries will be sorted by date and time. If any other column is sorted, the entries are sorted alphabetically, starting with numbers following by uppercase and lowercase text.
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
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.
This application is a non-provisional application of and claims the benefit of priority of U.S. Provisional Application No. 61/481,141, filed on Apr. 29, 2011, which is herein incorporated by references in its entirety for all purposes.
| Number | Date | Country | |
|---|---|---|---|
| 61481141 | Apr 2011 | US |
