US20050108151A1 - Order review workflow - Google Patents
Order review workflow Download PDFInfo
- Publication number
- US20050108151A1 US20050108151A1 US10/715,920 US71592003A US2005108151A1 US 20050108151 A1 US20050108151 A1 US 20050108151A1 US 71592003 A US71592003 A US 71592003A US 2005108151 A1 US2005108151 A1 US 2005108151A1
- Authority
- US
- United States
- Prior art keywords
- order
- customer
- fraud
- information
- rule
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q10/00—Administration; Management
- G06Q10/10—Office automation; Time management
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/04—Payment circuits
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/22—Payment schemes or models
- G06Q20/24—Credit schemes, i.e. "pay after"
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
- G06Q20/401—Transaction verification
- G06Q20/4016—Transaction verification involving fraud or risk level assessment in transaction processing
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
- G06Q40/02—Banking, e.g. interest calculation or account maintenance
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
- G06Q40/03—Credit; Loans; Processing thereof
Definitions
- Embodiments of the invention relate generally to the fraud prevention methods. More particularly, embodiments of the invention relate to order review workflows.
- An incoming order (e.g., an order for a particular product or service) may be placed by a customer via an online shopping website or via a call-center.
- an incoming order may be reviewed for potential fraud by having an analyst examine the dollar amount of the incoming order.
- this current method is unable to detect for fraudulent orders that may have lower dollar amounts.
- a fraud analyst would review incoming orders in different manners, by different methodologies, and/or by use of different criteria. As a result, there was no consistency in the fraud review process.
- the current technology is limited in its capabilities and suffers from at least the above constraints and deficiencies.
- a method for an order review workflow includes: receiving an incoming order from a customer; applying fraud shield rules to the order and information of the customer, to determine if the order and customer information have information that matches a negative file; requesting a preauthorization from an issuing bank for funds to pay for the order; performing an address verification system (AVS) check on the customer; checking a card verification number (CVN) of a credit card of the customer; and applying a fraud analysis rule to the order to determine if an automatic-reject rule fires, if an outsort rule fires, or if a positive rule fires.
- AVS address verification system
- an apparatus an order review workflow includes: a server including a transaction processing module configured to process an incoming order that is received from a call center or an online shopping website; the transaction processing module comprising an initial order review module configured to permit the above method steps.
- FIG. 1 is a block diagram of an apparatus, in accordance with an embodiment of the invention.
- FIG. 2A is a high-level flowchart illustrating a method for an initial order review workflow, in accordance with an embodiment of the invention.
- FIG. 2B is a flowchart illustrating additional details of a method for an initial order review workflow, in accordance with an embodiment of the invention.
- Embodiments of the invention advantageously provide an apparatus, system, and method that provide an order initial review workflow for an incoming order for a service or product.
- This order initial review workflow permits the filtering of potentially fraudulent incoming orders that are received from a customer.
- a fraud analyst would review incoming orders in different manners, by different methodologies, and/or by use of different criteria. As a result, in current methods and systems, there was no consistency in the fraud review process.
- FIG. 1 is a block diagram of a system (or apparatus) 100 in accordance with an embodiment of the invention.
- a customer 105 may send an order 110 via an online shopping website 115 or may send the order 110 by calling a call-center 120 .
- the order 110 may be, for example, an order for a particular product(s) and/or service(s).
- the customer 105 will use a computer 116 to access and place the order 110 on the website 115 .
- the customer 105 will use a telecommunication (telecom) device 117 (e.g., telephone or cellular phone) to place the order 110 to the call center 120 .
- a telecommunication (telecom) device 117 e.g., telephone or cellular phone
- the online shopping website 115 may be, for example, an online shopping website provided by HEWLETT-PACKARD COMPANY, Palo Alto, Calif., at ⁇ www.HPShopping.com>, other online shopping websites from other vendors or companies, an internal company shopping website, or another type of online shopping website.
- a server 118 (or other suitable computing device) is used to implement the website 115 and to receive and process the order 110 from the customer 105 .
- the server 118 includes a processor 119 (e.g., a central processing unit) for executing various applications or programs that are accessible by the server 118 .
- the customer's computer 116 will also include a processor (not shown in FIG. 1 ) for executing various applications or programs in the computer 116 .
- Various known components that are used in the server 118 and in the user's computer 116 are not shown in FIG. 1 for purposes of focusing on the functionalities of embodiments of the invention.
- a call center staff 121 in the call center 120 typically has access to a computer 122 for processing an incoming order 110 that is received in the call center 120 .
- each call center staff 121 will have access to a separate computer 122 .
- the computer 122 includes a processor 123 (e.g., a central processing unit) for executing various applications or programs that are accessible by the computer 122 .
- a transaction processing module 125 is typically implemented within the server 118 .
- the transaction processing module 125 may alternatively be implemented in another computer (not shown in FIG. 1 ) that is accessible by the server 118 and by the call center staff computer 122 .
- An order risk evaluator 140 in the transaction processing module 125 can determine if the order 110 is a high risk order (i.e., an order with a high risk related to fraudulent activity), a medium risk order (i.e., an order with a medium risk related to fraudulent activity), or a low risk order (i.e., an order with a low risk related to fraudulent activity).
- an initial order review workflow module 145 first outsorts an order 110 before the order 110 is determined as a high risk order, medium risk order, or low risk order.
- An order 110 is outsorted if the order 110 is selected among various incoming orders and placed in a separate queue (i.e., an outsort queue 233 , 235 , or 237 in FIG. 1 and FIG. 2B ) where the order 110 can then be evaluated for risk related to fraudulent activity.
- these outsort queue 233 , 235 , and 237 are memory areas 126 in a memory 127 . This memory 127 may be, for example, within the server 118 , or within another computing device or memory storage device that can be accessed by the server 118 and call center staff computer 122 .
- the order risk evaluator 140 can categorize an incoming order 110 as a high risk order, medium risk order, or low risk order.
- the order risk evaluator 140 is implemented as code that can be executed by a processor such as processor 119 in the server 118 .
- the order risk evaluator 140 may be implemented as a new code within an eFalcon module (or other fraud analysis module) 155 and executed by the eFalcon module 155 as a filter set to categorize an order 110 as a high risk order, medium risk order, or low risk order.
- the eFalcon module 155 is typically an e-commerce fraud detection product from, for example, FAIR, ISSAC AND COMPANY, San Rafael, Calif., and compares the transaction to general fraud patterns.
- the order risk evaluator 140 may be independent from the eFalcon module 155 and the eFalcon module 155 may be omitted from the transaction processing module 125 .
- the order risk evaluator 140 can be implemented as a web tool that can be accessed by use of a web interface.
- the order risk evaluator 140 can be implemented to function with a database, such as a database available from Oracle Corporation of Redwood Shores, Calif.
- order risk evaluator 140 An example of the order risk evaluator 140 is disclosed in, for example, U.S. patent application Ser. No. ______ by Richard York, entitled “ORDER RISK DETERMINATION”, which is hereby fully incorporated herein by reference.
- the order risk evaluator 140 may be omitted in the transaction processing module 125 , and the incoming order 110 may be manually classified as a high risk order, medium risk order, or low risk order based upon one or more criteria.
- an incoming order 110 may be categorized as a high risk order if the order price amount exceeds a maximum threshold price amount (e.g., $500), may be categorized as a medium risk order if the order price amount is within a defined price range (e.g., between $100 and $500), and may be categorized as a low risk order if the order price amount is below a minimum threshold price amount (e.g., $100). Therefore, if the order 110 has a price amount of, for example, $510, then the order 110 is classified as a high risk order. If the order 110 has a price amount of, for example, $200, then the order 110 is classified as a medium risk order. If the order 110 has a price amount of, for example, $80, then the order 110 is classified as a low risk order.
- a maximum threshold price amount e.g., $500
- a medium risk order if the order 110 has a price amount of, for example, $510
- the order 110 is classified as a high risk order.
- the order 110
- an incoming order 110 may be categorized as a high risk order if the order quantity amount exceeds a maximum threshold quantity amount (e.g., 10 items), may be categorized as a medium risk order if the order quantity amount is within a defined range (e.g., between 5 items to 10 items), and may be categorized as a low risk order if the order quantity amount is below a minimum threshold amount (e.g., 5 items).
- a maximum threshold quantity amount e.g. 10 items
- a medium risk order if the order quantity amount is within a defined range (e.g., between 5 items to 10 items)
- a minimum threshold amount e.g., 5 items.
- Other criteria or a combination of criteria can be used to classify an order as a high risk order, medium risk order, or low risk order.
- an incoming order verification module 150 then provides a set of information to verify based upon the risk factor (i.e., low risk, medium risk, or high risk) associated with the incoming order 110 , and verifies an appropriate set of information to determine if the order 110 is related to a potential fraudulent activity.
- the risk factor i.e., low risk, medium risk, or high risk
- An example of this verification method is disclosed in, for example, U.S. patent application Ser. No. ______ by Richard York, entitled “METHOD, APPARATUS, AND SYSTEM FOR VERIFYING INCOMING ORDERS”, which is hereby fully incorporated herein by reference.
- the order risk evaluator 140 and incoming order verification module 150 may be omitted in the transaction processing module 125 .
- the modules in the transaction processing module 125 described above are typically implemented in software code.
- FIG. 2A is a high-level flowchart illustrating a method 180 for an initial order review workflow, in accordance with an embodiment of the invention. Additional details of the method 180 are shown in method 200 in FIG. 2 B. Particular steps in the method 180 may be executed by the initial order review workflow module 145 of FIG. 1 , or the initial order review workflow module 145 is used to permit the analyst 131 to perform particular steps in the method 180 .
- An incoming order 110 is received ( 182 ) from a customer.
- Fraud shield rules are then applied ( 184 ) to the order 110 and customer 105 information to determine if the order 110 and customer 105 information have information that matches a negative file. In one embodiment, if a fraud shield rule fires, then the order 110 is rejected or not approved.
- the fraud analyst 131 can request ( 186 ) preauthorization from an issuing bank for funds to pay for the order 110 . In one embodiment, if preauthorization is declined, then the order 110 is rejected.
- the fraud analyst 131 can perform ( 188 ) an address verification system (AVS) check on the customer 105 who transmitted the order 110 .
- AVS address verification system
- the analyst 131 can perform further analysis for fraud on the order 110 instead of automatically rejecting the order 110 .
- the fraud analyst 131 can check ( 190 ) the card verification number (CVN) of a credit card of the customer 105 . In an embodiment, if there is a match in the CVN code, then the analyst 131 can approve the order 110 . In an embodiment, if there is not a match in the CVN code, then the analyst 131 can perform further analysis for potential fraud on the order 110 .
- CVN card verification number
- the initial order review module 145 can apply ( 192 ) a fraud analysis rule to the order 110 to determine if an automatic-reject rule fires, if an outsort rule fires, if a positive rule fires, or if none of the automatic-reject rule, the outsort rule, and the positive rule fires. If an automatic-reject rule fires, then the order 110 is rejected.
- the order 110 is accepted ( 194 ) if none of the automatic-reject rule and the outsort rule fires.
- the order 110 is also accepted ( 196 ) if a positive rule fires.
- FIG. 2B is a flowchart illustrating additional details of a method 200 for an initial order review workflow, in accordance with an embodiment of the invention. Particular steps in the method 200 may be executed by the initial order review workflow module 145 of FIG. 1 , or the initial order review workflow module 145 is used to permit the analyst 131 to perform particular steps in the method 200 .
- An incoming order 110 is determined ( 202 ) as an order received via a call center 120 or is determined ( 204 ) as an order received via a web site 115 .
- Fraud shield rules are then applied ( 206 ) to the incoming order 110 .
- One product that implements the fraud shield rules is of the type available from, for example, CLEARCOMMERCE CORPORATION, Austin, Tex.
- a fraud shield rule product stores negative files.
- a negative file has, for example, a particular address and/or phone number associated with a past known fraudulent order.
- a check ( 207 ) is made to determine if a rule in the fraud shield rules fires (triggers).
- a fraud shield rule will fire if the incoming order has information matching information in the negative files. If a fraud rule fires, then the order is automatically rejected ( 208 ). If a fraud shield rule does not fire, then the method 200 proceeds ( 209 ) to block ( 210 ).
- Pre-authorization will be requested ( 210 ) from an issuing bank (participating bank) for funds to pay for the order 110 . If pre-authorization is declined ( 211 ), then the order is automatically rejected ( 212 ). Pre-authorization may be declined ( 211 ) if, for example, the customer for the incoming order does not have enough funds in the issuing bank to pay for the incoming order. On the other hand, if the pre-authorization is received ( 213 ), then the method 200 proceeds ( 214 ) to block ( 215 ).
- An address verification system (AVS) check is then performed ( 215 ).
- the AVS code is a feature to verify the cardholder's address and zip code at the time of the transaction, and to verify if the information that the cardholder (customer 105 ) has entered matches the information that is stored at the issuing bank. If an “N” code is received ( 216 ), then the order is automatically rejected ( 217 ). If the AVS code is equal to “N”, which means that there was no match between the cardholder's address and the information stored at the issuing bank, then the order will be classified as a high risk order. As a result, the order will be automatically rejected ( 217 ).
- the order is automatically rejected ( 219 ). If the AVS code is equal to “G”, which means that the customer 105 is using a foreign credit card, then the order will be classified as a high risk order. As a result, the order will be automatically rejected ( 219 ).
- the order will not be automatically rejected if an N code or G code is received after performing ( 215 ) the AVS check.
- the analyst can perform further analysis for potential fraud, instead of automatically rejecting the order.
- blocks ( 216 ), ( 217 ), ( 218 ), and ( 219 ) may be omitted in other embodiments of the invention.
- the card verification number (CVN) authorization code is checked ( 222 ).
- a CVN authorization code equal to “N” means that there is no match found for the CVN code. In an embodiment, if there is a match in the CVN code, then the analyst 131 can approve the order 110 .
- a CVN authorization code equal to “S” means that a verification system being used by the analyst is unable to verify the CVN code.
- the CVN code is received ( 223 ) after performing ( 222 ) the CVN check. In one embodiment, an order is not automatically cancelled in response to particular CVN codes such as code “N” or code “S”. Instead, in this embodiment, the CVN code is available for an analyst to consider when analyzing the incoming order for potential fraud.
- a fraud analysis by use of the eFalcon product 155 is then performed ( 224 ), in order to determine if an automatic-reject rule fires, an outsort rule fires, or a positive rule fires. It is noted that this function by the efalcon product 155 of performing a fraud analysis may be performed by the initial order review module 145 ; therefore, the efalcon product 155 may be omitted in this alternative embodiment. If one of the automatic-reject rules fires, then the incoming order 110 is automatically rejected ( 226 ). An automatic-reject rule identifies a likelihood of fraudulent activity with the incoming order 110 .
- a “positive rule” fires ( 227 ) after performing the analysis under the eFalcon product 155 , then the order 110 is automatically accepted ( 228 ).
- a positive rule permits an order 110 to be automatically accepted, since the event associated with the triggering of the positive rule makes it very unlikely that a fraudulent activity is associated with the incoming order 110 .
- a positive rule is triggered if the incoming order 110 is made from an internal website of the vendor (e.g., an order 110 for a Hewlett-Packard product is made from a Hewlett-Packard employee internal website).
- a positive rule is triggered, where the customer satisfaction group orders replacement products for the vendor. Activities from these pre-selected groups of the vendor are unlikely related to fraudulent activities. Other events can be associated with the firing of a positive rule(s).
- the risk filter analysis block (typically implemented by the order risk evaluator 140 in FIG. 1 ) analyzes and assigns the level of risk for fraud for an incoming order 110 .
- An order 110 can be selected for outsort by use of any suitable methods, such as, for example, outsorting all incoming orders 110 , outsorting randomly picked incoming orders 110 , outsorting an incoming order 110 based upon one or more criteria that can be predefined by the user of the transaction processing module 125 , and/or outsorting an incoming order 110 based upon other suitable methods.
- step ( 230 ) the risk factor to assign to the incoming order 110 is then determined ( 232 ), by use of a risk filter as described in, for example, the above-referenced patent application entitled “ORDER RISK DETERMINATION” by Richard York. As previously noted above, other methods may be used to determine the particular risk factor that will be assigned to the order 110 . If the incoming order 110 is categorized as a low risk order (i.e., placed in a low risk queue ( 233 ) in FIG. 1 ), then the order is analyzed ( 234 ) for potential fraud by use of a low risk order workflow as described in, for example, the above-mentioned U.S. patent application Ser.
- the incoming order is categorized as a high risk order (i.e., placed in a high risk queue ( 237 ))
- the order is analyzed ( 238 ) for potential fraud by use of the high risk order workflow as described in, for example, the above-mentioned U.S. patent application Ser. No. ______ by Richard York, entitled “METHOD, APPARATUS, AND SYSTEM FOR VERIFYING INCOMING ORDERS”.
- Other suitable methods may be used to analyze a high risk order, medium risk order, or low risk order.
- system of certain embodiments of the invention can be implemented in hardware, software, or a combination thereof.
- the system is implemented in software or firmware that is stored in a memory and that is executed by a suitable instruction execution system. If implemented in hardware, as in an alternative embodiment, the system can be implemented with any suitable technology as known to those skilled in the art.
- the various engines discussed herein may be, for example, software, commands, data files, programs, code, modules, instructions, or the like, and may also include suitable mechanisms.
- At least some of the components of an embodiment of the invention may be implemented by using a programmed general purpose digital computer, by using application specific integrated circuits, programmable logic devices, or field programmable gate arrays, or by using a network of interconnected components and circuits. Connections may be wired, wireless, by modem, and the like.
Landscapes
- Business, Economics & Management (AREA)
- Engineering & Computer Science (AREA)
- Accounting & Taxation (AREA)
- Strategic Management (AREA)
- Physics & Mathematics (AREA)
- Theoretical Computer Science (AREA)
- General Physics & Mathematics (AREA)
- General Business, Economics & Management (AREA)
- Finance (AREA)
- Economics (AREA)
- Marketing (AREA)
- Technology Law (AREA)
- Development Economics (AREA)
- Computer Security & Cryptography (AREA)
- Entrepreneurship & Innovation (AREA)
- Human Resources & Organizations (AREA)
- Data Mining & Analysis (AREA)
- Operations Research (AREA)
- Quality & Reliability (AREA)
- Tourism & Hospitality (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
Abstract
An embodiment of the invention provides a method for an order review workflow, including: receiving an incoming order from a customer; applying fraud shield rules to the order and information of the customer, to determine if the order and customer information have information that matches a negative file; requesting a preauthorization from an issuing bank for funds to pay for the order; performing an address verification system (AVS) check on the customer; checking a card verification number (CVN) of a credit card of the customer; and applying a fraud analysis rule to the order to determine if an automatic-reject rule fires, if an outsort rule fires, or if a positive rule fires.
Description
- Embodiments of the invention relate generally to the fraud prevention methods. More particularly, embodiments of the invention relate to order review workflows.
- An incoming order (e.g., an order for a particular product or service) may be placed by a customer via an online shopping website or via a call-center. Currently, when an incoming order is made by a customer, the incoming order will be reviewed for potential fraud by having an analyst examine the dollar amount of the incoming order. As a result, this current method is unable to detect for fraudulent orders that may have lower dollar amounts.
- Additionally, in current methods and systems, a fraud analyst would review incoming orders in different manners, by different methodologies, and/or by use of different criteria. As a result, there was no consistency in the fraud review process.
- Therefore, the current technology is limited in its capabilities and suffers from at least the above constraints and deficiencies. Thus, it would be desirable to improve the current methods for verifying an incoming order for potential fraud before the order is accepted or rejected.
- In one embodiment of the invention, a method for an order review workflow, includes: receiving an incoming order from a customer; applying fraud shield rules to the order and information of the customer, to determine if the order and customer information have information that matches a negative file; requesting a preauthorization from an issuing bank for funds to pay for the order; performing an address verification system (AVS) check on the customer; checking a card verification number (CVN) of a credit card of the customer; and applying a fraud analysis rule to the order to determine if an automatic-reject rule fires, if an outsort rule fires, or if a positive rule fires.
- In another embodiment, an apparatus an order review workflow, includes: a server including a transaction processing module configured to process an incoming order that is received from a call center or an online shopping website; the transaction processing module comprising an initial order review module configured to permit the above method steps.
- Other embodiments of the invention include, but are not limited to, the various embodiments described below.
- These and other features of an embodiment of the present invention will be readily apparent to persons of ordinary skill in the art upon reading the entirety of this disclosure, which includes the accompanying drawings and claims.
- Non-limiting and non-exhaustive embodiments of the present invention are described with reference to the following figures, wherein like reference numerals refer to like parts throughout the various views unless otherwise specified.
-
FIG. 1 is a block diagram of an apparatus, in accordance with an embodiment of the invention. -
FIG. 2A is a high-level flowchart illustrating a method for an initial order review workflow, in accordance with an embodiment of the invention. -
FIG. 2B is a flowchart illustrating additional details of a method for an initial order review workflow, in accordance with an embodiment of the invention. - In the description herein, numerous specific details are provided, such as examples of components and/or methods, to provide a thorough understanding of embodiments of the invention. One skilled in the relevant art will recognize, however, that an embodiment of the invention can be practiced without one or more of the specific details, or with other apparatus, systems, methods, components, materials, parts, and/or the like. In other instances, well-known structures, materials, or operations are not shown or described in detail to avoid obscuring aspects of embodiments of the invention.
- Embodiments of the invention advantageously provide an apparatus, system, and method that provide an order initial review workflow for an incoming order for a service or product. This order initial review workflow permits the filtering of potentially fraudulent incoming orders that are received from a customer. In contrast, in current methods and systems, a fraud analyst would review incoming orders in different manners, by different methodologies, and/or by use of different criteria. As a result, in current methods and systems, there was no consistency in the fraud review process.
-
FIG. 1 is a block diagram of a system (or apparatus) 100 in accordance with an embodiment of the invention. Acustomer 105 may send anorder 110 via anonline shopping website 115 or may send theorder 110 by calling a call-center 120. Theorder 110 may be, for example, an order for a particular product(s) and/or service(s). Typically, to send anorder 110 to theonline shopping website 115, thecustomer 105 will use acomputer 116 to access and place theorder 110 on thewebsite 115. Typically, to send anorder 110 to thecall center 120, thecustomer 105 will use a telecommunication (telecom) device 117 (e.g., telephone or cellular phone) to place theorder 110 to thecall center 120. - The
online shopping website 115 may be, for example, an online shopping website provided by HEWLETT-PACKARD COMPANY, Palo Alto, Calif., at <www.HPShopping.com>, other online shopping websites from other vendors or companies, an internal company shopping website, or another type of online shopping website. - Typically, a server 118 (or other suitable computing device) is used to implement the
website 115 and to receive and process theorder 110 from thecustomer 105. Theserver 118 includes a processor 119 (e.g., a central processing unit) for executing various applications or programs that are accessible by theserver 118. Similarly, the customer'scomputer 116 will also include a processor (not shown inFIG. 1 ) for executing various applications or programs in thecomputer 116. Various known components that are used in theserver 118 and in the user'scomputer 116 are not shown inFIG. 1 for purposes of focusing on the functionalities of embodiments of the invention. - A
call center staff 121 in thecall center 120 typically has access to acomputer 122 for processing anincoming order 110 that is received in thecall center 120. Typically, eachcall center staff 121 will have access to aseparate computer 122. Thecomputer 122 includes a processor 123 (e.g., a central processing unit) for executing various applications or programs that are accessible by thecomputer 122. - In an embodiment of the invention, a
transaction processing module 125 is typically implemented within theserver 118. However, thetransaction processing module 125 may alternatively be implemented in another computer (not shown inFIG. 1 ) that is accessible by theserver 118 and by the callcenter staff computer 122. Anorder risk evaluator 140 in thetransaction processing module 125 can determine if theorder 110 is a high risk order (i.e., an order with a high risk related to fraudulent activity), a medium risk order (i.e., an order with a medium risk related to fraudulent activity), or a low risk order (i.e., an order with a low risk related to fraudulent activity). - Typically, an initial order
review workflow module 145 first outsorts anorder 110 before theorder 110 is determined as a high risk order, medium risk order, or low risk order. Anorder 110 is outsorted if theorder 110 is selected among various incoming orders and placed in a separate queue (i.e., anoutsort queue FIG. 1 andFIG. 2B ) where theorder 110 can then be evaluated for risk related to fraudulent activity. Typically, theseoutsort queue memory 127. Thismemory 127 may be, for example, within theserver 118, or within another computing device or memory storage device that can be accessed by theserver 118 and callcenter staff computer 122. - The
order risk evaluator 140 can categorize anincoming order 110 as a high risk order, medium risk order, or low risk order. In an embodiment, theorder risk evaluator 140 is implemented as code that can be executed by a processor such asprocessor 119 in theserver 118. In other embodiments, theorder risk evaluator 140 may be implemented as a new code within an eFalcon module (or other fraud analysis module) 155 and executed by the eFalconmodule 155 as a filter set to categorize anorder 110 as a high risk order, medium risk order, or low risk order. The eFalconmodule 155 is typically an e-commerce fraud detection product from, for example, FAIR, ISSAC AND COMPANY, San Rafael, Calif., and compares the transaction to general fraud patterns. In other embodiments, theorder risk evaluator 140 may be independent from the eFalconmodule 155 and the eFalconmodule 155 may be omitted from thetransaction processing module 125. In other embodiments, theorder risk evaluator 140 can be implemented as a web tool that can be accessed by use of a web interface. In other embodiments, theorder risk evaluator 140 can be implemented to function with a database, such as a database available from Oracle Corporation of Redwood Shores, Calif. An example of theorder risk evaluator 140 is disclosed in, for example, U.S. patent application Ser. No. ______ by Richard York, entitled “ORDER RISK DETERMINATION”, which is hereby fully incorporated herein by reference. In other embodiments, theorder risk evaluator 140 may be omitted in thetransaction processing module 125, and theincoming order 110 may be manually classified as a high risk order, medium risk order, or low risk order based upon one or more criteria. For example, anincoming order 110 may be categorized as a high risk order if the order price amount exceeds a maximum threshold price amount (e.g., $500), may be categorized as a medium risk order if the order price amount is within a defined price range (e.g., between $100 and $500), and may be categorized as a low risk order if the order price amount is below a minimum threshold price amount (e.g., $100). Therefore, if theorder 110 has a price amount of, for example, $510, then theorder 110 is classified as a high risk order. If theorder 110 has a price amount of, for example, $200, then theorder 110 is classified as a medium risk order. If theorder 110 has a price amount of, for example, $80, then theorder 110 is classified as a low risk order. - As another example, an
incoming order 110 may be categorized as a high risk order if the order quantity amount exceeds a maximum threshold quantity amount (e.g., 10 items), may be categorized as a medium risk order if the order quantity amount is within a defined range (e.g., between 5 items to 10 items), and may be categorized as a low risk order if the order quantity amount is below a minimum threshold amount (e.g., 5 items). Other criteria or a combination of criteria can be used to classify an order as a high risk order, medium risk order, or low risk order. - In an embodiment of the invention, an incoming
order verification module 150 then provides a set of information to verify based upon the risk factor (i.e., low risk, medium risk, or high risk) associated with theincoming order 110, and verifies an appropriate set of information to determine if theorder 110 is related to a potential fraudulent activity. An example of this verification method is disclosed in, for example, U.S. patent application Ser. No. ______ by Richard York, entitled “METHOD, APPARATUS, AND SYSTEM FOR VERIFYING INCOMING ORDERS”, which is hereby fully incorporated herein by reference. In other embodiments of the invention, theorder risk evaluator 140 and incomingorder verification module 150 may be omitted in thetransaction processing module 125. - The modules in the
transaction processing module 125 described above are typically implemented in software code. -
FIG. 2A is a high-level flowchart illustrating amethod 180 for an initial order review workflow, in accordance with an embodiment of the invention. Additional details of themethod 180 are shown inmethod 200 in FIG. 2B. Particular steps in themethod 180 may be executed by the initial orderreview workflow module 145 ofFIG. 1 , or the initial orderreview workflow module 145 is used to permit theanalyst 131 to perform particular steps in themethod 180. Anincoming order 110 is received (182) from a customer. Fraud shield rules are then applied (184) to theorder 110 andcustomer 105 information to determine if theorder 110 andcustomer 105 information have information that matches a negative file. In one embodiment, if a fraud shield rule fires, then theorder 110 is rejected or not approved. - The
fraud analyst 131 can request (186) preauthorization from an issuing bank for funds to pay for theorder 110. In one embodiment, if preauthorization is declined, then theorder 110 is rejected. - The
fraud analyst 131 can perform (188) an address verification system (AVS) check on thecustomer 105 who transmitted theorder 110. In an embodiment, if the information provided by thecustomer 105 does not match the information in an issuing bank from a result of the AVS check or if thecustomer 105 is using a foreign credit card, then theorder 110 is rejected. In another embodiment, then theanalyst 131 can perform further analysis for fraud on theorder 110 instead of automatically rejecting theorder 110. - The
fraud analyst 131 can check (190) the card verification number (CVN) of a credit card of thecustomer 105. In an embodiment, if there is a match in the CVN code, then theanalyst 131 can approve theorder 110. In an embodiment, if there is not a match in the CVN code, then theanalyst 131 can perform further analysis for potential fraud on theorder 110. - The initial
order review module 145 can apply (192) a fraud analysis rule to theorder 110 to determine if an automatic-reject rule fires, if an outsort rule fires, if a positive rule fires, or if none of the automatic-reject rule, the outsort rule, and the positive rule fires. If an automatic-reject rule fires, then theorder 110 is rejected. - On the other hand, the
order 110 is accepted (194) if none of the automatic-reject rule and the outsort rule fires. - Alternatively, the
order 110 is also accepted (196) if a positive rule fires. - If an outsort rule fires, then a determination is made (198) on a level of risk of fraud for the
order 110. In one embodiment, a determination is made if theorder 110 should be classified as a high risk order, medium risk order, or low risk order, in order to classify a level of risk for fraud for the order. -
FIG. 2B is a flowchart illustrating additional details of amethod 200 for an initial order review workflow, in accordance with an embodiment of the invention. Particular steps in themethod 200 may be executed by the initial orderreview workflow module 145 ofFIG. 1 , or the initial orderreview workflow module 145 is used to permit theanalyst 131 to perform particular steps in themethod 200. - An
incoming order 110 is determined (202) as an order received via acall center 120 or is determined (204) as an order received via aweb site 115. Fraud shield rules are then applied (206) to theincoming order 110. One product that implements the fraud shield rules is of the type available from, for example, CLEARCOMMERCE CORPORATION, Austin, Tex. A fraud shield rule product stores negative files. A negative file has, for example, a particular address and/or phone number associated with a past known fraudulent order. A check (207) is made to determine if a rule in the fraud shield rules fires (triggers). A fraud shield rule will fire if the incoming order has information matching information in the negative files. If a fraud rule fires, then the order is automatically rejected (208). If a fraud shield rule does not fire, then themethod 200 proceeds (209) to block (210). - Pre-authorization will be requested (210) from an issuing bank (participating bank) for funds to pay for the
order 110. If pre-authorization is declined (211), then the order is automatically rejected (212). Pre-authorization may be declined (211) if, for example, the customer for the incoming order does not have enough funds in the issuing bank to pay for the incoming order. On the other hand, if the pre-authorization is received (213), then themethod 200 proceeds (214) to block (215). - An address verification system (AVS) check is then performed (215). The AVS code is a feature to verify the cardholder's address and zip code at the time of the transaction, and to verify if the information that the cardholder (customer 105) has entered matches the information that is stored at the issuing bank. If an “N” code is received (216), then the order is automatically rejected (217). If the AVS code is equal to “N”, which means that there was no match between the cardholder's address and the information stored at the issuing bank, then the order will be classified as a high risk order. As a result, the order will be automatically rejected (217).
- If, after performing (215) the AVS check, a “G” code is received (218), then the order is automatically rejected (219). If the AVS code is equal to “G”, which means that the
customer 105 is using a foreign credit card, then the order will be classified as a high risk order. As a result, the order will be automatically rejected (219). - In another embodiment, the order will not be automatically rejected if an N code or G code is received after performing (215) the AVS check. In this alternative embodiment, the analyst can perform further analysis for potential fraud, instead of automatically rejecting the order. Thus, blocks (216), (217), (218), and (219) may be omitted in other embodiments of the invention.
- If, after performing (215) the AVS check, another code (except “N” or “G) is received (220), then the
method 200 proceeds (221) to block (222). - The card verification number (CVN) authorization code is checked (222). Most credit cards now include a 3 or 4 digit card verification number, which is not part of the regular credit card number. Telephone and Internet merchants can use these numbers to verify that the card is in fact in the customer's hand as the CVN numbers are not embedded in the magnetic stripe of the card. A CVN authorization code equal to “N” means that there is no match found for the CVN code. In an embodiment, if there is a match in the CVN code, then the
analyst 131 can approve theorder 110. A CVN authorization code equal to “S” means that a verification system being used by the analyst is unable to verify the CVN code. The CVN code is received (223) after performing (222) the CVN check. In one embodiment, an order is not automatically cancelled in response to particular CVN codes such as code “N” or code “S”. Instead, in this embodiment, the CVN code is available for an analyst to consider when analyzing the incoming order for potential fraud. - A fraud analysis by use of the eFalcon product 155 (or other similar fraud analysis tool) is then performed (224), in order to determine if an automatic-reject rule fires, an outsort rule fires, or a positive rule fires. It is noted that this function by the
efalcon product 155 of performing a fraud analysis may be performed by the initialorder review module 145; therefore, theefalcon product 155 may be omitted in this alternative embodiment. If one of the automatic-reject rules fires, then theincoming order 110 is automatically rejected (226). An automatic-reject rule identifies a likelihood of fraudulent activity with theincoming order 110. - On the other hand, if a “positive rule” fires (227) after performing the analysis under the
eFalcon product 155, then theorder 110 is automatically accepted (228). A positive rule permits anorder 110 to be automatically accepted, since the event associated with the triggering of the positive rule makes it very unlikely that a fraudulent activity is associated with theincoming order 110. For example, a positive rule is triggered if theincoming order 110 is made from an internal website of the vendor (e.g., anorder 110 for a Hewlett-Packard product is made from a Hewlett-Packard employee internal website). As another example, if the credit card number (that is used for the incoming order 110) belongs to a customer satisfaction group (or other pre-selected group) of the vendor, then a positive rule is triggered, where the customer satisfaction group orders replacement products for the vendor. Activities from these pre-selected groups of the vendor are unlikely related to fraudulent activities. Other events can be associated with the firing of a positive rule(s). - On the other hand, if an outsort rule(s) fires (230), then the
method 200 proceeds (231) to the risk filter analysis block (232). The risk filter analysis block (typically implemented by theorder risk evaluator 140 inFIG. 1 ) analyzes and assigns the level of risk for fraud for anincoming order 110. Anorder 110 can be selected for outsort by use of any suitable methods, such as, for example, outsorting allincoming orders 110, outsorting randomly pickedincoming orders 110, outsorting anincoming order 110 based upon one or more criteria that can be predefined by the user of thetransaction processing module 125, and/or outsorting anincoming order 110 based upon other suitable methods. - Alternatively, if a positive rule or an outsort rule(s) or an automatic-reject rule(s) fails (229) to fire for the incoming order, then the order is automatically accepted or approved (228). In other words, in block (229), the order has gone through without any rules firing.
- If, in step (230) an outsort rule(s) fires for the
order 110, the risk factor to assign to theincoming order 110 is then determined (232), by use of a risk filter as described in, for example, the above-referenced patent application entitled “ORDER RISK DETERMINATION” by Richard York. As previously noted above, other methods may be used to determine the particular risk factor that will be assigned to theorder 110. If theincoming order 110 is categorized as a low risk order (i.e., placed in a low risk queue (233) inFIG. 1 ), then the order is analyzed (234) for potential fraud by use of a low risk order workflow as described in, for example, the above-mentioned U.S. patent application Ser. No. ______ by Richard York, entitled “METHOD, APPARATUS, AND SYSTEM FOR VERIFYING INCOMING ORDERS”. If the incoming order is categorized as a medium risk order (i.e., placed in a medium risk queue (235)), then the order is analyzed (236) for potential fraud by use of the medium risk order workflow as described in, for example, the above-mentioned U.S. patent application Ser. No. ______ by Richard York, entitled “METHOD, APPARATUS, AND SYSTEM FOR VERIFYING INCOMING ORDERS”. If the incoming order is categorized as a high risk order (i.e., placed in a high risk queue (237)), then the order is analyzed (238) for potential fraud by use of the high risk order workflow as described in, for example, the above-mentioned U.S. patent application Ser. No. ______ by Richard York, entitled “METHOD, APPARATUS, AND SYSTEM FOR VERIFYING INCOMING ORDERS”. Other suitable methods may be used to analyze a high risk order, medium risk order, or low risk order. - The system of certain embodiments of the invention can be implemented in hardware, software, or a combination thereof. In at least one embodiment, the system is implemented in software or firmware that is stored in a memory and that is executed by a suitable instruction execution system. If implemented in hardware, as in an alternative embodiment, the system can be implemented with any suitable technology as known to those skilled in the art.
- The various engines discussed herein may be, for example, software, commands, data files, programs, code, modules, instructions, or the like, and may also include suitable mechanisms.
- Reference throughout this specification to “one embodiment”, “an embodiment”, or “a specific embodiment” means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present invention. Thus, the appearances of the phrases “in one embodiment”, “in an embodiment”, or “in a specific embodiment” in various places throughout this specification are not necessarily all referring to the same embodiment. Furthermore, the particular features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.
- Other variations and modifications of the above-described embodiments and methods are possible in light of the foregoing teaching.
- Further, at least some of the components of an embodiment of the invention may be implemented by using a programmed general purpose digital computer, by using application specific integrated circuits, programmable logic devices, or field programmable gate arrays, or by using a network of interconnected components and circuits. Connections may be wired, wireless, by modem, and the like.
- It will also be appreciated that one or more of the elements depicted in the drawings/figures can also be implemented in a more separated or integrated manner, or even removed or rendered as inoperable in certain cases, as is useful in accordance with a particular application.
- It is also within the scope of the present invention to implement a program or code that can be stored in a machine-readable medium to permit a computer to perform any of the methods described above.
- Additionally, the signal arrows in the drawings/Figures are considered as exemplary and are not limiting, unless otherwise specifically noted. Furthermore, the term “or” as used in this disclosure is generally intended to mean “and/or” unless otherwise indicated. Combinations of components or actions will also be considered as being noted, where terminology is foreseen as rendering the ability to separate or combine is unclear.
- As used in the description herein and throughout the claims that follow, “a”, “an”, and “the” includes plural references unless the context clearly dictates otherwise. Also, as used in the description herein and throughout the claims that follow, the meaning of “in” includes “in” and “on” unless the context clearly dictates otherwise.
- The above description of illustrated embodiments of the invention, including what is described in the Abstract, is not intended to be exhaustive or to limit the invention to the precise forms disclosed. While specific embodiments of, and examples for, the invention are described herein for illustrative purposes, various equivalent modifications are possible within the scope of the invention, as those skilled in the relevant art will recognize.
- These modifications can be made to the invention in light of the above detailed description. The terms used in the following claims should not be construed to limit the invention to the specific embodiments disclosed in the specification and the claims. Rather, the scope of the invention is to be determined entirely by the following claims, which are to be construed in accordance with established doctrines of claim interpretation.
Claims (36)
1. A method for an order review workflow, the method comprising:
receiving an incoming order from a customer;
applying fraud shield rules to the order and information of the customer, to determine if the order and customer information have information that matches a negative file;
requesting a preauthorization from an issuing bank for funds to pay for the order;
performing an address verification system (AVS) check on the customer;
checking a card verification number (CVN) of a credit card of the customer; and
applying a fraud analysis rule to the order to determine if an automatic-reject rule fires, if an outsort rule fires, or if a positive rule fires.
2. The method of claim 1 , further comprising:
rejecting the order if one of the fraud shield rules fires.
3. The method of claim 1 , further comprising:
rejecting the order if the preauthorization is declined.
4. The method of claim 1 , further comprising:
rejecting the order if the information provided by the customer does not match the information in the issuing bank from a result of the AVS check.
5. The method of claim 1 , further comprising:
rejecting the order if the customer is using a foreign credit card.
6. The method of claim 1 , further comprising:
performing further analysis for fraud on the order, if the information provided by the customer does not match the information in the issuing bank from a result of the AVS check or if the customer is using a foreign credit card.
7. The method of claim 1 , further comprising:
approving the order if there is a match in the CVN check.
8. The method of claim 1 , further comprising:
performing further analysis for potential fraud on the order if there is not a match in the CVN code during the CVN check.
9. The method of claim 1 , further comprising:
rejecting the order if an automatic-reject rule fires.
10. The method of claim 1 , further comprising:
accepting the order if none of the automatic-reject rule and the outsort rule fires.
11. The method of claim 1 , further comprising:
accepting the order if a positive rule fires.
12. The method of claim 1 , further comprising:
determining a level of risk of fraud for the order, if an outsort rule fires.
13. The method of claim 12 , wherein determining the level of risk of fraud for the order comprises:
determining if the order should be classified as a high risk order, medium risk order, or low risk order.
14. The method of claim 1 , wherein the order is received in a website.
15. The method of claim 1 , wherein the order is received in a call center.
16. The method of claim 1 , wherein the order is an order for a product.
17. The method of claim 1 , wherein the order is an order for a service.
18. An apparatus for an order review workflow, the apparatus comprising:
a server including a transaction processing module configured to process incoming orders received from a call center or an online shopping website, the transaction processing module comprising: an initial order review module configured to permit the steps comprising:
receiving an incoming order from a customer;
applying fraud shield rules to the order and information of the customer, to determine if the order and customer information have information that matches a negative file;
requesting a preauthorization from an issuing bank for funds to pay for the order;
performing an address verification system (AVS) check on the customer;
checking a card verification number (CVN) of a credit card of the customer; and
applying a fraud analysis rule to the order to determine if an automatic-reject rule fires, if an outsort rule fires, or if a positive rule fires.
19. The apparatus of claim 18 , wherein the order is rejected if one of the fraud shield rules fires.
20. The apparatus of claim 18 , wherein the order is rejected if the preauthorization is declined.
21. The apparatus of claim 18 , wherein the order is rejected if the information provided by the customer does not match the information in the issuing bank from a result of the AVS check.
22. The apparatus of claim 18 , wherein the order is rejected if the customer is using a foreign credit card.
23. The apparatus of claim 18 , wherein further analysis for fraud is performed on the order, if the information provided by the customer does not match the information in the issuing bank from a result of the AVS check or if the customer is using a foreign credit card.
24. The apparatus of claim 18 , wherein the order is approved if there is a match in the CVN check.
25. The apparatus of claim 18 , wherein further analysis for potential fraud is performed on the order if there is not a match in the CVN code during the CVN check.
26. The apparatus of claim 18 , wherein the order is rejected if an automatic-reject rule fires.
27. The apparatus of claim 18 , wherein the order is accepted if none of the automatic-reject rule and the outsort rule fires.
28. The apparatus of claim 18 , wherein the order is accepted if a positive rule fires.
29. The apparatus of claim 18 , wherein a level of risk of fraud is determined for the order, if an outsort rule fires.
30. The apparatus of claim 29 , wherein the level of risk of fraud determined for the order comprises a high risk order, medium risk order, or low risk order.
31. The apparatus of claim 18 , wherein the order is received in a website.
32. The apparatus of claim 18 , wherein the order is received in a call center.
33. The apparatus of claim 18 , wherein the order is an order for a product.
34. The apparatus of claim 18 , wherein the order is an order for a service.
35. An apparatus for an order review workflow, the apparatus comprising:
means for receiving an incoming order from a customer;
means for applying fraud shield rules to the order and information of the customer, to determine if the order and customer information have information that matches a negative file;
means for requesting a preauthorization from an issuing bank for funds to pay for the order;
means for performing an address verification system (AVS) check on the customer;
means for checking a card verification number (CVN) of a credit card of the customer; and
means for applying a fraud analysis rule to the order to determine if an automatic-reject rule fires, if an outsort rule fires, or if a positive rule fires.
36. An article of manufacture, comprising:
a machine-readable medium having stored thereon instructions to:
receive an incoming order from a customer;
apply fraud shield rules to the order and information of the customer, to determine if the order and customer information have information that matches a negative file;
request a preauthorization from an issuing bank for funds to pay for the order;
perform an address verification system (AVS) check on the customer;
check a card verification number (CVN) of a credit card of the customer; and
apply a fraud analysis rule to the order to determine if an automatic-reject rule fires, if an outsort rule fires, or if a positive rule fires.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US10/715,920 US20050108151A1 (en) | 2003-11-17 | 2003-11-17 | Order review workflow |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US10/715,920 US20050108151A1 (en) | 2003-11-17 | 2003-11-17 | Order review workflow |
Publications (1)
Publication Number | Publication Date |
---|---|
US20050108151A1 true US20050108151A1 (en) | 2005-05-19 |
Family
ID=34574306
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US10/715,920 Abandoned US20050108151A1 (en) | 2003-11-17 | 2003-11-17 | Order review workflow |
Country Status (1)
Country | Link |
---|---|
US (1) | US20050108151A1 (en) |
Cited By (26)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20080270171A1 (en) * | 2007-04-27 | 2008-10-30 | Bryan Price | Method and system for managing caselog fraud and chargeback |
US20080270296A1 (en) * | 2007-04-27 | 2008-10-30 | Janice Zhou | Method and system for operating a risk management call center |
US20080270303A1 (en) * | 2007-04-27 | 2008-10-30 | Janice Zhou | Method and system for detecting fraud in financial transactions |
US7487183B1 (en) | 2008-04-03 | 2009-02-03 | International Business Machines Corporation | Grouped filter rules for workflow application update notifications |
CN101847228A (en) * | 2010-03-29 | 2010-09-29 | 清华大学 | Workflow static planning method based on process mode |
US7925578B1 (en) | 2005-08-26 | 2011-04-12 | Jpmorgan Chase Bank, N.A. | Systems and methods for performing scoring optimization |
US7945492B1 (en) | 1998-12-23 | 2011-05-17 | Jpmorgan Chase Bank, N.A. | System and method for integrating trading operations including the generation, processing and tracking of and trade documents |
US7987501B2 (en) | 2001-12-04 | 2011-07-26 | Jpmorgan Chase Bank, N.A. | System and method for single session sign-on |
US8020754B2 (en) | 2001-08-13 | 2011-09-20 | Jpmorgan Chase Bank, N.A. | System and method for funding a collective account by use of an electronic tag |
US8145549B2 (en) | 2003-05-30 | 2012-03-27 | Jpmorgan Chase Bank, N.A. | System and method for offering risk-based interest rates in a credit instutment |
US8160960B1 (en) | 2001-06-07 | 2012-04-17 | Jpmorgan Chase Bank, N.A. | System and method for rapid updating of credit information |
US8175908B1 (en) | 2003-09-04 | 2012-05-08 | Jpmorgan Chase Bank, N.A. | Systems and methods for constructing and utilizing a merchant database derived from customer purchase transactions data |
US8185940B2 (en) | 2001-07-12 | 2012-05-22 | Jpmorgan Chase Bank, N.A. | System and method for providing discriminated content to network users |
US8301493B2 (en) | 2002-11-05 | 2012-10-30 | Jpmorgan Chase Bank, N.A. | System and method for providing incentives to consumers to share information |
US8447672B2 (en) | 2005-05-27 | 2013-05-21 | Jp Morgan Chase Bank, N.A. | Universal payment protection |
US8533031B2 (en) | 2000-10-17 | 2013-09-10 | Jpmorgan Chase Bank, N.A. | Method and system for retaining customer loyalty |
US8554631B1 (en) | 2010-07-02 | 2013-10-08 | Jpmorgan Chase Bank, N.A. | Method and system for determining point of sale authorization |
US8622308B1 (en) | 2007-12-31 | 2014-01-07 | Jpmorgan Chase Bank, N.A. | System and method for processing transactions using a multi-account transactions device |
US8793160B2 (en) | 1999-12-07 | 2014-07-29 | Steve Sorem | System and method for processing transactions |
US8849716B1 (en) | 2001-04-20 | 2014-09-30 | Jpmorgan Chase Bank, N.A. | System and method for preventing identity theft or misuse by restricting access |
US9058626B1 (en) | 2013-11-13 | 2015-06-16 | Jpmorgan Chase Bank, N.A. | System and method for financial services device usage |
CN104854605A (en) * | 2012-04-16 | 2015-08-19 | 沃尔玛百货有限公司 | Processing online transactions |
US20160364728A1 (en) * | 2015-06-11 | 2016-12-15 | Early Warning Services, Llc | Card systems and methods |
US20180077227A1 (en) * | 2016-08-24 | 2018-03-15 | Oleg Yeshaya RYABOY | High Volume Traffic Handling for Ordering High Demand Products |
US11074531B2 (en) | 2019-05-01 | 2021-07-27 | EMC IP Holding Company LLC | Machine learning techniques for automated processing of workflow approval requests |
US11144928B2 (en) | 2016-09-19 | 2021-10-12 | Early Warning Services, Llc | Authentication and fraud prevention in provisioning a mobile wallet |
Citations (17)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US4831526A (en) * | 1986-04-22 | 1989-05-16 | The Chubb Corporation | Computerized insurance premium quote request and policy issuance system |
US5732400A (en) * | 1995-01-04 | 1998-03-24 | Citibank N.A. | System and method for a risk-based purchase of goods |
US5808894A (en) * | 1994-10-26 | 1998-09-15 | Optipat, Inc. | Automated ordering method |
US5963625A (en) * | 1996-09-30 | 1999-10-05 | At&T Corp | Method for providing called service provider control of caller access to pay services |
US20010032180A1 (en) * | 2000-03-16 | 2001-10-18 | Katsushi Takami | System for carrying out a commercial transaction with a high security and efficiency |
US20010049636A1 (en) * | 2000-04-17 | 2001-12-06 | Amir Hudda | System and method for wireless purchases of goods and services |
US20020107781A1 (en) * | 2000-06-23 | 2002-08-08 | Electronic Broking Services Limited | Compound order handling in an anonymous trading system |
US20020116314A1 (en) * | 2000-12-19 | 2002-08-22 | Michael Spencer | Method of using a computerised trading system to process trades in financial instruments |
US20020138371A1 (en) * | 2001-03-20 | 2002-09-26 | David Lawrence | Online transaction risk management |
US20020143583A1 (en) * | 2001-03-30 | 2002-10-03 | Reader Robert A. | Online reinsurance renewal method |
US20020156657A1 (en) * | 2000-12-05 | 2002-10-24 | De Grosz Kurt M. | Insurance renewal system and method |
US6526386B1 (en) * | 1999-06-10 | 2003-02-25 | Ace Limited | System and method for automatically generating automobile insurance certificates from a remote computer terminal |
US20030229569A1 (en) * | 2002-06-05 | 2003-12-11 | Nalbandian Carolyn A | Order delivery in a securities market |
US6735497B2 (en) * | 1999-09-22 | 2004-05-11 | Telepharmacy Solutions, Inc. | Systems and methods for dispensing medical products |
US20040103012A1 (en) * | 2002-11-22 | 2004-05-27 | Swiss Reinsurance Company | Method for automated insurance pricing and renewal notification |
US7013001B1 (en) * | 1996-06-05 | 2006-03-14 | David Felger | Method of billing a communication session conducted over a computer network |
US7028304B1 (en) * | 1998-05-26 | 2006-04-11 | Rockwell Collins | Virtual line replaceable unit for a passenger entertainment system, method and article of manufacture |
-
2003
- 2003-11-17 US US10/715,920 patent/US20050108151A1/en not_active Abandoned
Patent Citations (17)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US4831526A (en) * | 1986-04-22 | 1989-05-16 | The Chubb Corporation | Computerized insurance premium quote request and policy issuance system |
US5808894A (en) * | 1994-10-26 | 1998-09-15 | Optipat, Inc. | Automated ordering method |
US5732400A (en) * | 1995-01-04 | 1998-03-24 | Citibank N.A. | System and method for a risk-based purchase of goods |
US7013001B1 (en) * | 1996-06-05 | 2006-03-14 | David Felger | Method of billing a communication session conducted over a computer network |
US5963625A (en) * | 1996-09-30 | 1999-10-05 | At&T Corp | Method for providing called service provider control of caller access to pay services |
US7028304B1 (en) * | 1998-05-26 | 2006-04-11 | Rockwell Collins | Virtual line replaceable unit for a passenger entertainment system, method and article of manufacture |
US6526386B1 (en) * | 1999-06-10 | 2003-02-25 | Ace Limited | System and method for automatically generating automobile insurance certificates from a remote computer terminal |
US6735497B2 (en) * | 1999-09-22 | 2004-05-11 | Telepharmacy Solutions, Inc. | Systems and methods for dispensing medical products |
US20010032180A1 (en) * | 2000-03-16 | 2001-10-18 | Katsushi Takami | System for carrying out a commercial transaction with a high security and efficiency |
US20010049636A1 (en) * | 2000-04-17 | 2001-12-06 | Amir Hudda | System and method for wireless purchases of goods and services |
US20020107781A1 (en) * | 2000-06-23 | 2002-08-08 | Electronic Broking Services Limited | Compound order handling in an anonymous trading system |
US20020156657A1 (en) * | 2000-12-05 | 2002-10-24 | De Grosz Kurt M. | Insurance renewal system and method |
US20020116314A1 (en) * | 2000-12-19 | 2002-08-22 | Michael Spencer | Method of using a computerised trading system to process trades in financial instruments |
US20020138371A1 (en) * | 2001-03-20 | 2002-09-26 | David Lawrence | Online transaction risk management |
US20020143583A1 (en) * | 2001-03-30 | 2002-10-03 | Reader Robert A. | Online reinsurance renewal method |
US20030229569A1 (en) * | 2002-06-05 | 2003-12-11 | Nalbandian Carolyn A | Order delivery in a securities market |
US20040103012A1 (en) * | 2002-11-22 | 2004-05-27 | Swiss Reinsurance Company | Method for automated insurance pricing and renewal notification |
Cited By (39)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7945492B1 (en) | 1998-12-23 | 2011-05-17 | Jpmorgan Chase Bank, N.A. | System and method for integrating trading operations including the generation, processing and tracking of and trade documents |
US8793160B2 (en) | 1999-12-07 | 2014-07-29 | Steve Sorem | System and method for processing transactions |
US8533031B2 (en) | 2000-10-17 | 2013-09-10 | Jpmorgan Chase Bank, N.A. | Method and system for retaining customer loyalty |
US10380374B2 (en) | 2001-04-20 | 2019-08-13 | Jpmorgan Chase Bank, N.A. | System and method for preventing identity theft or misuse by restricting access |
US8849716B1 (en) | 2001-04-20 | 2014-09-30 | Jpmorgan Chase Bank, N.A. | System and method for preventing identity theft or misuse by restricting access |
US8160960B1 (en) | 2001-06-07 | 2012-04-17 | Jpmorgan Chase Bank, N.A. | System and method for rapid updating of credit information |
US8185940B2 (en) | 2001-07-12 | 2012-05-22 | Jpmorgan Chase Bank, N.A. | System and method for providing discriminated content to network users |
US8020754B2 (en) | 2001-08-13 | 2011-09-20 | Jpmorgan Chase Bank, N.A. | System and method for funding a collective account by use of an electronic tag |
US7987501B2 (en) | 2001-12-04 | 2011-07-26 | Jpmorgan Chase Bank, N.A. | System and method for single session sign-on |
US8707410B2 (en) | 2001-12-04 | 2014-04-22 | Jpmorgan Chase Bank, N.A. | System and method for single session sign-on |
US8301493B2 (en) | 2002-11-05 | 2012-10-30 | Jpmorgan Chase Bank, N.A. | System and method for providing incentives to consumers to share information |
US8145549B2 (en) | 2003-05-30 | 2012-03-27 | Jpmorgan Chase Bank, N.A. | System and method for offering risk-based interest rates in a credit instutment |
US8306907B2 (en) | 2003-05-30 | 2012-11-06 | Jpmorgan Chase Bank N.A. | System and method for offering risk-based interest rates in a credit instrument |
US8175908B1 (en) | 2003-09-04 | 2012-05-08 | Jpmorgan Chase Bank, N.A. | Systems and methods for constructing and utilizing a merchant database derived from customer purchase transactions data |
US8473395B1 (en) | 2005-05-27 | 2013-06-25 | Jpmorgan Chase Bank, Na | Universal payment protection |
US8447672B2 (en) | 2005-05-27 | 2013-05-21 | Jp Morgan Chase Bank, N.A. | Universal payment protection |
US8447670B1 (en) | 2005-05-27 | 2013-05-21 | Jp Morgan Chase Bank, N.A. | Universal payment protection |
US10290054B2 (en) | 2005-08-26 | 2019-05-14 | Jpmorgan Chase Bank, N.A. | Systems and methods for performing scoring optimization |
US7925578B1 (en) | 2005-08-26 | 2011-04-12 | Jpmorgan Chase Bank, N.A. | Systems and methods for performing scoring optimization |
US8762260B2 (en) | 2005-08-26 | 2014-06-24 | Jpmorgan Chase Bank, N.A. | Systems and methods for performing scoring optimization |
WO2008134042A1 (en) * | 2007-04-27 | 2008-11-06 | Total System Services, Inc. | Method and system for operating a risk management call center |
US20080270171A1 (en) * | 2007-04-27 | 2008-10-30 | Bryan Price | Method and system for managing caselog fraud and chargeback |
US20080270296A1 (en) * | 2007-04-27 | 2008-10-30 | Janice Zhou | Method and system for operating a risk management call center |
US20080270303A1 (en) * | 2007-04-27 | 2008-10-30 | Janice Zhou | Method and system for detecting fraud in financial transactions |
US8622308B1 (en) | 2007-12-31 | 2014-01-07 | Jpmorgan Chase Bank, N.A. | System and method for processing transactions using a multi-account transactions device |
US7487183B1 (en) | 2008-04-03 | 2009-02-03 | International Business Machines Corporation | Grouped filter rules for workflow application update notifications |
CN101847228A (en) * | 2010-03-29 | 2010-09-29 | 清华大学 | Workflow static planning method based on process mode |
US8554631B1 (en) | 2010-07-02 | 2013-10-08 | Jpmorgan Chase Bank, N.A. | Method and system for determining point of sale authorization |
US9111278B1 (en) | 2010-07-02 | 2015-08-18 | Jpmorgan Chase Bank, N.A. | Method and system for determining point of sale authorization |
CN104854605A (en) * | 2012-04-16 | 2015-08-19 | 沃尔玛百货有限公司 | Processing online transactions |
US9058626B1 (en) | 2013-11-13 | 2015-06-16 | Jpmorgan Chase Bank, N.A. | System and method for financial services device usage |
US9460469B1 (en) | 2013-11-13 | 2016-10-04 | Jpmorgan Chase Bank, N.A. | System and method for financial services device usage |
US11030622B2 (en) * | 2015-06-11 | 2021-06-08 | Early Warning Services, Llc | Card systems and methods |
US20160364728A1 (en) * | 2015-06-11 | 2016-12-15 | Early Warning Services, Llc | Card systems and methods |
US20180077227A1 (en) * | 2016-08-24 | 2018-03-15 | Oleg Yeshaya RYABOY | High Volume Traffic Handling for Ordering High Demand Products |
US11144928B2 (en) | 2016-09-19 | 2021-10-12 | Early Warning Services, Llc | Authentication and fraud prevention in provisioning a mobile wallet |
US11151566B2 (en) | 2016-09-19 | 2021-10-19 | Early Warning Services, Llc | Authentication and fraud prevention in provisioning a mobile wallet |
US11151567B2 (en) | 2016-09-19 | 2021-10-19 | Early Warning Services, Llc | Authentication and fraud prevention in provisioning a mobile wallet |
US11074531B2 (en) | 2019-05-01 | 2021-07-27 | EMC IP Holding Company LLC | Machine learning techniques for automated processing of workflow approval requests |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US20050108151A1 (en) | Order review workflow | |
US20050108178A1 (en) | Order risk determination | |
US20050108102A1 (en) | Method, apparatus, and system for verifying incoming orders | |
US20240202733A1 (en) | Methods and systems for screening electronic money transfer transactions | |
US7539644B2 (en) | Method of processing online payments with fraud analysis and management system | |
US7693789B2 (en) | System and method for detecting fraudulent calls | |
US8055584B2 (en) | Systems and methods for fraud management in relation to stored value cards | |
US8224753B2 (en) | System and method for identity verification and management | |
US20020099648A1 (en) | Method of reducing fraud in credit card and other E-business | |
US20170262852A1 (en) | Database monitoring system | |
US20190295085A1 (en) | Identifying fraudulent transactions | |
US20090094124A1 (en) | Real-time point-of-sale change-of-address processing | |
US20020099649A1 (en) | Identification and management of fraudulent credit/debit card purchases at merchant ecommerce sites | |
US20090248560A1 (en) | Assessment of risk associated with doing business with a party | |
US20090248465A1 (en) | Assessment of risk associated with doing business with a party | |
US8738488B2 (en) | Method for business on-line account opening with early warning system | |
US20210312286A1 (en) | System for designing and validating fine grained fraud detection rules | |
CN1439139A (en) | System and method for detecting fraudulent transactions | |
CA2477937A1 (en) | Credit extension process using a prepaid card | |
US20090248559A1 (en) | Assessment of risk associated with doing business with a party | |
WO2020233070A1 (en) | Payment risk verification method and apparatus, computer device, and storage medium | |
CA2559384A1 (en) | Real-time point-of-sale change-of-address processing | |
US20190295086A1 (en) | Quantifying device risk through association | |
CN109150952B (en) | System and method for asynchronously integrating and transmitting data | |
US20050049927A1 (en) | Apparatus and process for blocking product returns |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: HEWLETT-PACKARD COMPANY, COLORADO Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:YORK, RICHARD;REEL/FRAME:014750/0989 Effective date: 20031122 |
|
AS | Assignment |
Owner name: HEWLETT-PACKARD DEVELOPMENT COMPANY, L.P., TEXAS Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:YORK, RICHARD;REEL/FRAME:015934/0251 Effective date: 20031122 |
|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |