US 8,069,084 B2Grant
Customer controlled account, system, and process
Issue Date:2011-11-29
•18 Claims
•14 Drawing Sheets
Abstract
Enhanced access devices, e.g. credit cards and/or check cards, are issued with enhanced security features and processes that allow a customer to control circumstances under which their account can be accessed. If a fraudster tries to access the account without knowledge of the consumer set controls, the system can take remedial action with reduced instances of false positives. An account is typically established for an account holder through a central entity, e.g. an issuer. At least one access device is established for the account, wherein at least one user is associated with the access devices for one or more transactions. Use of the access devices is defined by a set of rules defined by the central entity and a set of rules that are controllable by the customer, typically comprising any of the account holder and the user of the account. The customer can input, control, and/or update at least one parameter associated with the customer-controllable rules. Subsequent authorization of the access devices is then controlled based on the customer input and other controls.
Metadata
Assignee
- Wells Fargo Bank, N.A.
Inventor
- Jack Mackouse
Application Information
Application Number:US 11/879,048
Filing Date:2007-07-12
Priority Date:2006-07-14
Art Unit:3627
Classifications
IPC:
G06Q20/00G06Q30/00
Patent Drawings (14 sheets)
Description
Cross Reference to Related Applications
[0001] This Application claims priority to U.S. Provisional Application No. 60/807,424, entitled Customer Controlled Account, filed 14 Jul. 2006, which is incorporated herein in its entirety by this reference thereto.
Field of the Invention
[0002] The invention relates to the field of credit card and check card systems between devices operating across a network. More particularly, the invention relates to controllable security structures and processes for credit card accounts and check card accounts operating across a network.
Background of the Invention
[0003] Financial institutions and/or other organizations typically issue consumers or businesses with access “devices”, such as credit cards or debit cards. Authorized users of such access devices can then make purchases and/or obtain financial instruments, e.g. such as at a point of sale, through an ATM, through an internet site, or at another remote location.
[0004] Misuse of access devices for fraudulent purposes has materially negative consequences for users of the devices, for the issuers of the devices, and for any other entity that can be negatively impacted by either actual or perceived security risks. Users are often negatively effected by identify fraud, loss of access to funds, and/or inconvenience. As well, providers of such access devices lose millions of dollars annually to fraudulent device use.
[0005] In an attempt to control misuse, issuers of access devices and related institutions have created numerous processes, materials and techniques to reduce the risks referenced. Such efforts include consumer education and sophisticated authorization systems.
[0006] Authorization systems involve the combined efforts of various organizations in the value chain, such as merchants or entities that accept the device or access methods, issuers who provide accounts and access devices or access methods to consumers and business users, and associations such as MASTERCARD®, AMERICAN EXPRESS®, VISA® and DISCOVER®, that provide rules and guidelines for managing the card payment environment.
[0007] In a typical example, a user applies for and is issued a credit or check card, wherein a credit card accesses a line of credit, while a check card accesses the consumer's available funds. To use the device, the user presents the device and/or account access Is information (account number, CVV number, verification information, etc.) to a merchant to purchase goods, services or funds, such as through a physical, i.e. brick and mortar, store, via telephone, or through an Internet site.
[0008] Before providing the goods, services or funds, the merchant first authorizes the transaction either through a terminal or other means. In the authorization process, the merchant must follow certain guidelines including providing information from the presenter of the device. If the authorization is approved, the merchant provides the goods, services or funds.
[0009] If at a later time it is determined that the receiver of the goods, services or funds was a “fraudster”, the system has been defrauded with various negative consequences such as: the access device can be shut down, the consumer may be materially inconvenienced and/or suffer financial loss, the provider of the device or the merchant suffer financial loss, and/or confidence in the payments system is negatively impacted.
[0010] Some financial companies have started barring all credit and/or debit transactions originating from nations that exhibit high levels of fraud. For example, as reported in “Blocking Entire Nations to Curtail Card Fraud”, by David Breitkopf, American Banker, Jan. 30, 2006, “One of the more extreme examples: First Bank and Trust Co. of Abingdon, Va., which issues Visa debit cards, does not accept transactions originating anywhere outside the United States unless a customer asks for permission to use their cards abroad.”
[0011] Almost all, if not all issuers of these devices set parameters that will result in a declined authorization under certain circumstances, such as but not limited to a number of transactions that exceeds some threshold, or a pattern of transactions that results in a score below a threshold. A key problem is that this approach leads to “false positives”, in that transactions that should or could have been approved are declined, and sometimes approves transactions that turn out to be fraudulent. A transaction that exceeds a credit line is typically treated as a factual factor, which results in either a yes or no decision, but does not lead to a false positive.
[0012] Current systems do include a variety of customer control features such as:
-
- [0013] being required to contact the device issuer to activate their account or access device;
- [0014] being required to use a PIN or personal identification number in some cases; and/or
- [0015] as noted above, in some cases being required to call and request to turn access on, such as if the user plans to use the card internationally.
[0016] It would be advantageous to provide a system, structure and method such that access devices and their use may provide increased security, for users and for financial institutions, as compared to security infrastructures that are currently available. The development of an enhanced customer account system and associated method would constitute a major technological advance.
[0017] As well, it would be advantageous to provide a system, structure and method wherein an account holder may be further involved with defining where and how their credit cards and/or debit cards are used. The development of such a transaction system would constitute a further major technological advance.
[0018] In addition, it would be advantageous to provide a system, structure and method wherein an account holder and other appropriate parties within the network who have a need to know may be notified if and when there is an attempt to access the account holder's credit card and/or debit card account in a manner that is counter to parameters for account access that have been set by the account holder. This would allow the account holders and/or other appropriate parties to take preemptive action to thwart the intentions of fraudsters, not only for the account holder in which fraudulent access has been attempted, but also potentially for others based upon gained information. The development of such a transaction system and process would constitute an additional technological advance.
Summary of the Invention
[0019] Enhanced access devices, such as credit cards and/or check cards, are issued with enhanced security features and processes that allow customer control of the circumstances under which their account can be accessed. If a fraudster tries to access the account without knowledge of the customer set controls, the system can take remedial action. In an exemplary process, an account is established for an account holder or holders, such as through a computer associated with a central entity, e.g. an issuer. At least one access device associated with the account is established, wherein at least one user is associated with at least one of the access devices for one or more transactions. Use of the established access devices is defined by at least one rule defined by the central entity and at least one rule that is controllable by at least a customer of the account, the customer typically comprising any account holder or person that is deemed to be accountable or liable for the actions of account holders or other account users authorized by the account holder to access the account. The customer can then input, such as by any of selection, identification, and entry, at least one parameter associated with the customer-controllable rules. Subsequent authorization of at least one of the established access devices is then controlled based on the customer input and other controls.
Brief Description of the Drawings
[0020] FIG. 1 is a schematic view of typical payment system, wherein fraudulent access is allowed within a payment structure having a centralized rule structure;
[0021] FIG. 2 is a schematic view of one embodiment of an enhanced financial account system, wherein at least a portion of rules associated with account operation are controlled by an authorized customer of the account;
[0022] FIG. 3 is an exemplary schematic diagram of an access device associated with a customer account;
[0023] FIG. 4 is a flowchart of an exemplary process for the establishment of a customer-controlled account;
[0024] FIG. 5 is an exemplary schematic diagram of solicitation and input of user controls implemented across a network;
[0025] FIG. 6 is a schematic diagram of customer controlled account rules;
[0026] FIG. 7 is a flowchart of an exemplary process for response to a transaction request associated with a customer-controlled account;
[0027] FIG. 8 is a flowchart of an exemplary process for actions and/or notifications associated with non-compliance of a transactional request with primary or institutional rules;
[0028] FIG. 9 is a flowchart of an exemplary process for actions and/or notifications associated with non-compliance of a transactional request with secondary or customer controlled rules;
[0029] FIG. 10 is a schematic view of an attempted purchase transaction through a “brick and mortar” location, and a request for authorization for an exemplary customer controlled account by an authorized user of the customer-controlled account;
[0030] FIG. 11 is a schematic view of an attempted purchase transaction through a “brick and mortar” location, and a request for authorization for an exemplary customer controlled account by an unknown user, e.g. a fraudster, of the customer-controlled account;
[0031] FIG. 12 is a schematic view of an attempted purchase transaction through an internet site, a request for authorization for an exemplary customer controlled account by an authorized user of an access device associated with the customer controlled account, and optional system communication with the customer in response to non-adherence to one or more customer-controlled rules; and
[0032] FIG. 13 is a schematic view of an attempted purchase transaction through an Internet site, a request for authorization for an exemplary customer controlled account by an unknown user, e.g. a fraudster, of an access device associated with the customer-controlled account, and optional system communication with the customer in response to non-adherence to one or more customer-controlled rules.
Detailed Description of Preferred Embodiments
[0033] FIG. 1 is a schematic view of typical payment system 10, wherein fraudulent access is allowed within a payment structure having a centralized rule structure.
[0034] In an attempt to control misuse, issuers 12, e.g. Wells Fargo Bank, of access devices 15 and related institutions, e.g. service providers 14, provide numerous processes, materials and techniques to reduce risks associated with identity theft and fraudulent use of access devices. Such efforts include consumer education and sophisticated authorization systems.
[0035] Authorization systems involve the combined efforts of various organizations in the value chain, such as merchants or entities 10 that accept the device or access methods 15, issuers who provide accounts and access devices or access methods to consumers and business users, and associations such as MASTERCARD®, AMERICAN EXPRESS®, VISA® and DISCOVER®, that provide rules and guidelines for managing the card payment environment 10.
[0036] As seen in FIG. 1 , a user USR receives 26 an access device 15, e.g. a credit card or debit card 15, such as by requesting 25 or otherwise applying for the access device 15 though a an institutional issuer 12, e.g. a financial institution (FI)12. The receipt of the access device 15 is typically confirmed 28 by the user to the institutional issuer 12, at which time the access device is activated.
[0037] In a typical example, a customer user USR applies for and is issued a credit or check card 15, wherein a credit card accesses a line of credit, while a check card accesses the consumer's available funds 181 (FIG. 3 ). A customer user USR is authenticated when they apply for and are approved for an account 182. The access device 15 is typically mailed or otherwise provided to the customer user USR, wherein the access device 15 is typically provided with a sticker on it, which typically includes a phone number to call and/or an email address, to contact to activate the access device 15, wherein a customer user USR can activate their account 182 and/or select a PIN number or other access number.
[0038] Instructions 30 associated with the access device 15 are also provided to the customer user USR, such as related to any of personal identification number(s), limits, and/or one or more card codes 194, e.g. 194a, 194b (FIG. 3 ), such as card security codes (CSC) or card validation codes (CVC). For example, typical card validation codes 194 may comprise a CVC 194b that is encoded on a magnetic stripe 192 (FIG. 3 ) located on the access device 15, and/or a CVC 194a printed on the card 15 but not encoded on the magnetic stripe 192.
[0039] Institutions 12, such as financial institutions (FI) 12 and/or other organizations 12 typically issue consumers or businesses USR with access “devices” (credit cards, debit cards etc.). Authorized users USR of such access devices 15 can then make purchases and/or obtain financial instruments remotely, e.g. such as at a merchant, i.e. point of sale 20, through a dedicated terminal 260 (FIG. 5 ), e.g. an ATM 260, through a network site 20i (FIG. 12 ), e.g. an Internet website 20i, or at another remote location.
[0040] To use the device 15, the user USR presents the device 15, and/or other account or customer information to a merchant 20 to purchase or acquire goods, services or funds, such as through a physical, i.e. “brick and mortar” store 20, through an Internet site 20i, or through a dedicated terminal or kiosk.
[0041] The system 10 seen in FIG. 1 comprises authorization controls 16, that are set, i.e. established 32,34 for account use and access, through the institutional issuer 12 and/or an optional service provider 14, such as to manage, i.e. minimize, fraudulent use of access devices 15 and/or related account information, e.g. PIN numbers. The authorization controls 16 are typically established according to rules of networks and/or the service provider 14, and may include predictive methods to approve or decline authorization requests.
[0042] As seen in FIG. 1 , and authorized user USR presents 50a access device information to a merchant entity 20, such as by physically presenting the access device 15 to a store clerk CLK (FIG. 10 ), by physically sliding the access device through a point of sale (POS) terminal 414, or otherwise providing access device information to a merchant entity 20, e.g. communicating over a telephone or entering information through a network connection.
[0043] Before providing the goods, services or funds, the merchant 20 first attempts 52 to authorize 60 the transaction, either through a terminal 414 (FIG. 10 ) or by other means. In the authorization process, the merchant 20 must follow certain guidelines, including providing information from the presenter of the device 15. If the authorization is approved, the merchant 20 provides the goods, services or funds 70, e.g. a bicycle 70.
[0044] The merchant authorization request 52 is performed through interaction with the system 10, such as through communication with the institutional issuer 12, or through one or more intermediate entities in the system 10. For example, as seen in FIG. 1 , the merchant 10 may send an authorization request 52 through a financial entity 22, e.g. a bank, associated with the merchant 20, wherein the authorization request 52 includes information associated with the access device 15, e.g. such as the account number 185, and may preferably also include a CVC number 194. The request also typically includes merchant information and transaction information, e.g. such as the amount of the requested transaction.
[0045] An authorization request 52 may then typically initiate a transmission 57,58 of information between a merchant bank 22 through an association payments network 24, such as to the institutional issuer entity 12, or to a service provider 14 that provides service functions for the institutional issuer entity 12. In response to the transaction authorization request, the service provider 14 or the institutional issuer 12 determines 56 an appropriate response 60, such as to approve or decline the request for funds 181 (FIG. 3 ), wherein the decision 56 is based on the institutionally established set of rules 16, such as comprising the institutional rules, the network rules, and/or rules that are based on the predictive models.
[0046] If the funds are approved, a notification 60 that indicates approval is typically sent to the merchant 20, such that the user USR is able to receive 62a the goods or services 70, while funds 181 associated with the transaction 62a typically flow 58 from the issuer 12, e.g. Wells Fargo Bank, to the financial entity 22, e.g. a bank 22 associated with the merchant 20.
[0047] In the exemplary system 10 seen in FIG. 1 , an authorized user USR may potentially be denied the transaction, based on an authorization decline 56. A decision 56 to decline the transaction request 52 that is based on the institutionally established rules 16 may be an intended result, such as for a transaction 62 that exceeds the available limit of an account 182 (FIG. 3 ) associated with a customer user USR, or for a transaction that falls within a threshold of a predictive model, e.g. such as wherein the transaction appears to be fraudulent based on an institutional rule.
[0048] However, a decision 56d based solely on institutionally established rules 16, may be associated with a false positive, such as for a user USR who appears to be making out of pattern transactions, such as based upon the predictive modeling from the institutional issuer 12, or based upon other authorization system controls that result in the institutional issuer 12 either declining the transaction, or providing some other type of qualifying response such as “Contact Issuer”.
[0049] The latter response may result in the customer user USR selecting and/or using a competing financial institution's product for this and/or subsequent transactions, because of the customer user USR or the merchant's 20 real or perceived inconvenience from the non “approved” response 60. In this case, the transaction would be a false positive for those portions of transactions where it was in fact the customer USR attempting to use the account.
[0050] In other instances, “false positives” can occur where institution issuers 12 have experienced increased fraud for certain types of transactions e.g. for gas purchases greater than a threshold dollar amount, e.g. $100, transactions in certain geographies that have been experiencing increased incidences of fraud or for accounts with account numbers in account number ranges that the institutional issuer 12 may have reason to believe may be compromised due to some type of real or presumed data security breach.
[0051] In recent years many publicized security breaches, either through stolen or lost data, have resulted in reissuance of account numbers by financial institutions 12, and/or declining transactions that would otherwise be approvable, absent concerns that the account identifying and/or access information may have been compromised.
[0052] As also seen in FIG. 1 , a user FRD, e.g. a fraudster FRD, other than an authorized user USR, may also interact 50u,62u with the system 10. For example, access devices 15 and/or information associated with access devices 15, e.g. account numbers 185, user names 186, expiration dates 188, and/or CVC numbers 194, may be compromised, such as due to a lost or stolen card 15 and/or identity theft.
[0053] In the system seen in FIG. 1 , an alternate user FRD may readily use, e.g. submit 50u an access device 15 and/or information associated with the device 15, such as to receive goods and/or services 70, cash advances, or otherwise transfer funds 181 from the customer account 182. Since user interaction with the system 10 is based on institutional rules 16, as long as the proper customer user USR has not discovered an existing problem with the access device and has not taken steps to prevent further account use, e.g. by calling the issuer to report the problem, a fraudster FRD may easily use the device 15, as long as the transaction(s) comply with the institutional rules 16.
[0054] As seen in FIG. 1 , a merchant 20 would typically follow the same procedure to authorize a transaction for an unknown user FRD, such as a suspected fraudster FRD. As long as the fraudster FRD provides 50u all the required information in regard to the access device 15 and/or account 182, the fraudster FRD may easily obtain goods and/or services 70, cash advances, or otherwise transfer funds 181 from the customer account 182, as long as the transaction(s) comply with the institutional rules.
[0055] For example, if an account in good standing has available funds 181 of $5000, and has a cash advance limit per day of $300, a fraudster FRD may readily conduct one or more transactions 50u, 62u equaling less than or equal to the $5000, and/or may make one or more cash advances totaling less than the established $300 per day, without system notification to or approval of the proper customer user USR.
[0056] Such illegitimate transactions can be made through a wide variety of merchants 20 to purchase goods, services or funds 70, such as through a physical, i.e. brick and mortar, store 20, through an Internet site 20, through an ATM 260 (FIG. 10 ), or over the phone to a business or catalog merchant 20.
[0057] Misuse of access devices 15 for fraudulent purposes has materially negative consequences for users USR of the devices, for the issuers 12 of the devices, and for any other entity that can be negatively impacted by either actual or perceived security risks. Users USR are often negatively affected, such as but not limited to any of identify fraud, loss of access to funds 181, and inconvenience. As well, providers of such access devices 15 lose millions of dollars annually to fraudulent device use.
[0058] For example, if at a later time it is determined that a receiver FRD of the goods, services or funds 70 was a “fraudster” FRD, the system 10 has been defrauded, with various negative consequences such as comprising any of:
-
- [0059] the access device 15 can be shut down;
- [0060] the consumer USR may be materially inconvenienced and/or suffer financial loss;
- [0061] the provider of the device 15 or the merchant 20 suffer financial loss; and/or
- [0062] confidence in the payments system 10 is negatively impacted.
[0063] FIG. 2 is a schematic view of one embodiment of an enhanced financial account system 100, wherein at least a portion of rules associated with account operation are controlled by an authorized customer user USR of the account 182. The customer typically comprises an account holder or a person that is deemed to be accountable or liable for the actions of account holders, or other account users authorized by the account holder to access the account 182. Typically, consumer accounts 182 have one or more account holders that are liable for incurred debt. One such account holder is often considered a “primary” account holder, which is primarily a function of limitations on issuer systems 12 that capture social security numbers, etc., from only one of the authorized users.
[0064] In the customer controllable process and system 100, the customer user USR manages additional controls 160, such as via any of online 244 (FIG. 5 ), through an ATM 260 (FIG. 5 ), and through phone communication 256 (FIG. 5 ), to any of the issuer 12, e.g. Wells Fargo Bank, such as though a network interface between a user terminal 250 (FIG. 5 ) and an issuer computer, terminal, server, computing system, electronic system, or network site 12, and/or to an associated service provider 14, e.g. an associated service provider computer, terminal, server, computing system, electronic system, or network site 14, or through an interface associated with the rules 16, 160.
[0065] In some embodiments of the customer controllable process and system 100, any of the liable account holders for an account 182 are able to set authorization parameters and/or may designate other authorized users to do so. For example, authorized users or “additional” account holders are not liable for the account debt, and may be restricted from setting account parameters 160, such as by one or more of the “account holders”, or by an institutional issuer 12 that makes the customer controllable process and system 100 available to its customers USR.
[0066] FIG. 3 is an exemplary schematic diagram 180 of an access device 15 associated with a customer account 182, which can be used in either the basic transaction system 10 or the customer controllable process and system 100. As seen in FIG. 3 , an access device 15 associated with a customer account 182 typically comprises one or more cards 17, such as for one or more intended, i.e. approved customer users USR for the account 182, e.g. for one or more account holders USR, and as allowed, for one or more account users USR that are authorized by the account holder(s) to access the account 182, such as for a spouse, child, or employee.
[0067] Each of a access devices 15 typically includes information that appears on the card 17, such as but not limited to an account number 185, a user name 186, indicia relating to card type 183, indicia 184 relating to the issuer 12, an expiration, i.e. good thru date 188, other information 190, and typically including encoded information, such as within a magnetic region, e.g. a stripe 192.
[0068] While an access device 15 associated with a user account 182 in the customer controllable system 100 may preferably appear to be identical to a conventional credit card or debit card 15 for a basic transaction system 10, an access device 15 in the customer controllable system 100 is issued with enhanced security features and processes that allow customer users USR to control circumstances under which their account 182 can be accessed. Therefore, if a fraudster FRD tries to access the account 182 without knowledge and/or access to the consumer set controls 160, the enhanced system 100 can quickly take remedial action, with reduced instances of false positives.
[0069] In some embodiments, the customer user USR can change the customer controlled rule parameters 160 at any time, and there is no way for a fraudster FRD to know either the current user-controlled parameters, or of updates to the user-controlled parameters.
[0070] An issuer 12 may preferably contact the customer user USR, e.g. as soon as possible, if an authorization attempt 50, e.g. 50u, is outside the customer-controlled parameters 160. For example, if the customer USR is contacted through a real time phone conversation, the customer user USR and/or the issuer administrator ISR (FIG. 5 ) associated with the issuer computer 12 can reset the parameter 282 or rule 160 if desired, such as to resubmit 50 and approve 62 a transaction.
[0071] As seen in FIG. 2 , and authorized customer user USR may present 50a access device information to a merchant entity 20 in a similar manner to the basic system 10 seen in FIG. 1 , such as by physically presenting the access device 15 to a store clerk CLK (FIG. 10 ), by physically sliding the access device 15 through a point of sale (POS) terminal 414, or otherwise providing access device information to a merchant entity 20, e.g. communicating over a telephone, entering information through a network connection, or otherwise presenting account information, e.g. a key fob, a chip in a cell phone, a mini card, a contactless card, or other means or device for conveying account information.
[0072] Before conditionally providing the goods, services or funds, the merchant 20 must first similarly authorize the transaction, either through a terminal 414 (FIG. 10 ) or by other means. In the authorization process, the merchant 20 follows certain guidelines, including providing information from the presenter of the device 15. If the enhanced authorization determination 56 is approved, e.g. through merchant notification 60, controllably based on both the primary rules 16 and the customer-controlled rules 160, the merchant 20 similarly provides the goods, services or funds 70.
[0073] The merchant authorization request 52 is performed through interaction with the enhanced system 100, such as through communication with the institutional issuer 12, or through one or more intermediate entities in the system 100. For example, as seen in FIG. 2 , the merchant 20 may send an authorization request 52 through a financial entity 22, e.g. a bank, associated with the merchant 20, wherein the authorization request 52 includes information associated with the access device 15, e.g. such as the account number 185, expiration date 188, and may preferably also include a CVC number 194. The request also typically includes merchant information and transaction information, e.g. such as the amount, the date and the time of the requested transaction.
[0074] An authorization request 52 may then typically initiate a transmission 57,58 of information between a merchant bank 20 through an association payments network 24, such as to the institutional issuer entity 12, or to a service provider 14 that provides service functions for the institutional issuer entity 12. In response to the transaction authorization request, the service provider 14 or the issuer 12 determines 56 an appropriate response 60, such as to approve or decline the request for funds, wherein the decision 56 is based on both:
-
- [0075] the institutionally established set of rules 16, such as comprising the financial institution rules, the network rules, and/or rules that are based on the predictive models; and
- [0076] customer-controlled rules 160.
[0077] In the enhanced system 100, the institutional issuer 12 works as needed with the optional service provider 14 to overlay additional customer rules 160, e.g. selected decline reasons, on top of existing issuer controls, i.e. rules 16.
[0078] If the funds are approved 56 in the enhanced system 100, an approval notification 60 is typically sent to the merchant 20, such that the user USR is able to receive 62a the goods or services 70, while funds 181 from the customer account 182 associated with the transaction 62a typically flow 58 to the financial entity 22, e.g. bank 22 associated with the merchant 20.
[0079] As also seen in FIG. 2 , a user FRD, e.g. a fraudster FRD, other than an authorized user USR, may also attempt to interact 50u,62u with the enhanced system 100. For example, access devices 15 and/or information associated with access devices 15, e.g. account numbers 185, user names 186, expiration dates 188, and/or CVC numbers 194, may be compromised, such as due to a lost or stolen card 15 and/or identity theft.
[0080] In the system seen in FIG. 2 , an alternate user FRD may attempt to use, e.g. submit 50u an access device 15 and/or information associated with the device 15, such as to attempt to receive goods and/or services 70, cash advances, or otherwise transfer funds 181 from the customer account 182, such as by physically presenting the access device 15 to a store clerk CLK (FIG. 10 ), by physically sliding the access device 15 through a point of sale (POS) terminal 414, or otherwise providing access device information to a merchant entity 20, e.g. communicating over a telephone, entering information through a network connection, or otherwise presenting account information, e.g. a key fob.
[0081] Before conditionally providing the goods, services or funds, the merchant 20 sends an authorization request 52, either through a terminal 414 (FIG. 10 ) or by other means. In the authorization process, the merchant 20 follows certain guidelines, including providing information from the presenter of the device 15. If the enhanced authorization determination 56 is approved, e.g. through merchant notification 60, controllably based on both the primary rules 16 and the customer-controlled rules 160, the merchant 20 similarly provides the goods, services or funds 70.
[0082] However, if the fraudster FRD attempts a transaction 50u, and provides all typically is required account information, the transaction may be prevented 170 if the transaction is not allowed, based on one or more of the customer-controlled rules 160 or associated parameters 282 (FIG. 6 ), even if the requested transaction 50,52 appears to be allowable based solely on the institutional rules and/or guidelines 16.
[0083] Establishment of Enhanced Account and User Controls. FIG. 4 is a flowchart of an exemplary process 200 for the establishment of a customer controlled account 182. FIG. 5 is an exemplary schematic diagram 240 of solicitation and/or alternate input of user controls 160 implemented within the enhanced transaction system 100. FIG. 6 is a schematic diagram 280 of customer-controlled account rules 160 within the enhanced customer-controlled transaction system 100.
[0084] The exemplary process 200 for the establishment of a customer controlled account 182 seen in FIG. 4 typically comprises the establishment of an account 182 and assignment of one or more associated access devices 15. In coordination with the establishment 202 is the establishment or assignment 204 of the primary institutional, rules 16 that govern the proper use of the access device(s) 15.
[0085] As noted above, the customer controlled account 182 is additionally governed by customer-controlled rules 160, which may initially be pre-set 206 before or during card activation 26,28,30. As well, a customer user USR, such as during or subsequent to initial activation 26,28,30, may set or change 208 the customer-controllable parameters 160, which are then stored or updated 210, such as for reference by the issuer 12 and/or service provider 14 for conditional authorization of a transaction request 52.
[0086] For example, cards or access devices 15 may preferably be issued with access to foreign countries turned off. During an activation call 28,30, the customer USR may preferably be asked if they would like to turn such access on, and be provided with instructions as to where and how the customer USR can change and/or modify additional customer-controllable functions 160.
[0087] In some system embodiments 100, one or more customer-controllable rules 160 are preferably available for customers through an online terminal 250 (FIG. 5 ), with an option to phone in 256 (FIG. 5 ) change requests after verifying the identity of the customer user USR. As well, online screens, e.g. 284 (FIG. 6 ) may preferably allow the customer USR to turn on or off more restrictive access controls 16 than what the institutional issuer 12, e.g. Wells Fargo, allows.
[0088] For example, while the institutional issuer 12 may permit a customer to access up to $500 per day under certain circumstances, i.e. based on an issuer rule 16, the enhanced customer-controlled account system 100 may preferably allow the customer USR to set this limit to a lower amount, e.g. $400 per day, but not a higher amount, e.g. $600 per day.
[0089] In some system embodiments 100, the customer user USR may preferably set and/or change a wide variety of parameters 282 or rules 160, such as related to time parameters and/or different limits for different access devices or methods, such as but not limited to:
-
- [0090] a maximum of $500 for one card 17 that accesses the account 182 and a higher amount for another card 17 that accesses the account 182;
- [0091] $0 threshold for jewelry or gambling purchases;
- [0092] no access to be allowed between defined dates, e.g. between 30 Jun. 2007 and 15 Jul. 2007;
- [0093] no access to be allowed between 12 am and 6 am PT; and/or
- [0094] no access to card not present situations (phone orders or internet orders).
[0095] The consumer controls 160,282 may preferably be extended to any variable that the issuer 12 can restrict access on. The customer user USR may therefore become a much more active contributor to protecting their account, funds and identity.
[0096] A customer user USR may interact with the institutional issuer 12, i.e. financial institution 12, such as seen in FIG. 5 , or through an associated service provider 14, in a wide number of ways to enter or update user controls 160 within the enhanced transaction system 100. For example, a customer user USR may input or update rules 160 through any of a phone 256 connected 258 to the enhanced system 100, through a dedicated terminal 260, e.g. an ATM connected to the enhanced system 100, or through an alternate device 250, such as any of a user device, computer, or portable digital assistant (PDA), or other terminal 250 connected to the enhanced system 10. As seen in. FIG. 5 , the connection between a user terminal 250 and the enhanced transaction system 100 may comprise a network 244, e.g. the Internet 244, a client connection 252, an administrative connection 254, and an issuer computer or server 12.
[0097] FIG. 6 is a schematic diagram 280 of customer-controlled account rules 160 within the enhanced transaction system 100. While the customer-controlled rules 160 may be physically entered by an administrative user ISR, the exemplary user interface 284 may comprise any of a user entry screen 284 and/or an administrative entry screen 284. The exemplary customer-controllable rules displayed in the entry screen 284 seen in FIG. 6 comprise one or more user-controlled parameters 282, such as but not limited to parameters associated with any of transactions outside the United States 282a, gaming/gambling transactions 282b, transactions over a specified maximum 282c, e.g. $300.00, transactions through Internet merchants 282d, and/or transactions for cash advances, i.e. withdrawals 282k.
[0098] Online screens 284, such as seen in FIG. 6 , allow the customer user USR to set and modify the access controls that are available to them. In some embodiments 100, the screens 284 may preferably be accessed via secured Internet protocols, such as through a user terminal 250. Customer access to customer-controllable rules 160 may preferably be more limited for selecting additional controls 160, and may preferably be made available via any secure method for interacting with the institutional issuer 12, such as via any of a phone, an ATM, a personal digital assistant device (PDA), and directly with personnel associated with the issuer, e.g. bank personnel.
[0099] As seen in FIG. 6 , one or more of the customer-controllable parameters 282 may be selectably allowed 286a, not allowed 286b, or otherwise controlled 286n. such as through a selection 288, e.g. an affirmative selection 288y, a disallowed selection 288n, or through a detailed selection or entry 290.
[0100] For example, in the exemplary interface shown in FIG. 6 , an authorized user USR has not allowed 286b gaming or gambling transactions 282b. As well, the authorized user USR has selected detailed control 286n to allow transactions only from one or more specified Internet merchants, e.g. for transactions of less than $200 from Amazon.com are controllably allowed by the customer user USR. Similarly, a user USR that plans a vacation to a foreign destination, e.g. Tahiti, may selectably allow transactions from foreign merchants 20 located in their destination within their dates of travel, while disallowing transactions from other countries, and optionally also disallowing transactions in Tahiti for dates other than their dates of travel.
[0101] In some embodiments of the enhanced transaction system, one or more of the customer users USR may preferably control the rules 160 to preferably control, allow, or limit one or more parameters 282 differently between one or more access devices 15 associated with the user account 182. For example, a parent customer user USR may limit one or more parameters 282 for a credit card 15 used by a college-bound son or daughter, such as to limit cash withdrawals, or to disallow certain transactions, such as based on store, product category, service category, location, date, transaction amount, or cumulative cost, e.g. not more than $300 per month.
[0102] Transaction Processing for Enhanced Customer-Controlled Accounts. FIG. 7 is a flowchart of an exemplary process 300 for system response to transaction requests associated with a customer-controlled account 182. FIG. 8 is a flowchart of an exemplary process 310 for actions and/or notifications associated with non-compliance of a transactional request with primary or institutional rules 16. FIG. 9 is a flowchart of an exemplary process 320 for actions and/or notifications associated with non-compliance of a transactional request with secondary or customer-controlled rules 160.
[0103] As seen in FIG. 7 , a transaction request, e.g. 52 is received 302, wherein the transaction request 52 typically comprises account information as well as any of merchant information, transaction amount, date, time, and product or service category. A determination 304 may be made whether the request 52 meets the primary set of rules 16, e.g. such as the centralized rules controlled by the institutional issuer 12, i.e. financial institution (FI) 12, or other service provider 14. If not 308, the enhanced system 100 may perform 310 one or more actions and/or notifications based at least on the primary rules 16, such as to simply deny 352 the transaction request 52 (FIG. 8 ).
[0104] After or concurrently with performing the primary action and/or notification subroutine 310, the process may return 311 to the main process 300, such as to additionally check 312 for adherence to customer controls 160, such as to provide a secondary level of account protection.
[0105] For example, a potential fraudster FRD may have attempted a transaction that does not meet an issuer rule 16, e.g. over a transaction limit, and additionally does not meet a customer-controlled rule 160, e.g. gambling that is disallowed by the user USR. In this example, the transaction request 52 is declined 56 based on the primary, i.e. institutional, set of rules 16, but because of the customer-controlled rule 160 or parameter 282, the institutional issuer 12, customer user USR, or other interested party, e.g. an associated service provider 14 or police, may be alerted that there may be a fraudulent situation going on. The customer controlled account system 100 and process 300 therefore provides significant information in a timely manner, which would not be available if the system only acted upon the primary decline reason 56. The customer-controlled rules 160 and/or parameters 282 may therefore provide additional insights to one or more transactions.
[0106] In some embodiments of the system 100 and associated process 300, a transaction request 52 may be approved based on customer-controlled rules 160 and/or parameters 282, even though the transaction request 52 may not initially be acceptable based upon the institutional rules 16 alone. For example, for a set of centralized rules 16 that currently disallow transactions in a certain region or country, e.g. Tahiti, a user USR may provide information to the institutional issuer 12 or associated provider 14, that confirms legitimacy. In such a situation, a user USR may confirm that they are currently located at the region or country, e.g. Tahiti, and the institutional issuer 12 or provider may determine or otherwise decide that the conditions were sufficient to warrant a reversal of a decision.
[0107] In current system embodiments 100, if the decline is because the consumer USR is over their credit limit, no consumer setting 160,282 can override that. In such as situation, the notification process may alert the customer USR that they would be over limit (OVL), in which case the customer user USR may decide to make an early payment.
[0108] If the determination 304 of whether the request 52 meets the primary set of rules 16 is positive 306, the system 100 may then determine 312 whether the request 52 meets the customer-controlled set of rules 160, e.g. such as the customer-controlled parameters 282 (FIG. 6 ). If the determination 312 is positive 314, the system 100 may then authorize 316 the transaction, and send 318 a confirmation message 60 toward the merchant 20.
[0109] If the determination 312 is negative 315, the system 100 may then perform 320 one or more actions and/or notifications based at least on the secondary, i.e. customer-controlled rules 160, such as to deny 392 (FIG. 9 ) the transaction, based on non-adherence to one or more customer-controlled rules 160.
[0110] As seen in FIG. 8 , an authorization entity, such as the institutional issuer 12 or associated service provider 14, may initiate actions and/or notifications associated with non-compliance of a transactional request with primary or institutional rules 16. While some actions and/or notifications may be similar to those in a basic transaction system 10, some actions and/or notifications may be further enhanced based on customer user input.
[0111] In the exemplary process, i.e. subroutine 310 seen in FIG. 8 , a determination 332 may be made whether a customer user USR is to be notified if a request 52 fails to meet the primary, i.e. centralized rules 16 controlled by the institutional issuer 12, e.g. financial institution (FI) 12 or other service provider 14. If the decision 332 is yes 334, the system 100 may notify 336 the customer user USR, e.g. automatically, such as to a telephone 256 (FIG. 11 ) associated with the account 182.
[0112] For example, in a situation where a the customer USR or store clerk makes a typographical error, or “fat fingers” the entry of the expiration date or CVC value, the transaction request 52 would typically 52 fail to meet the primary, i.e. centralized rules 16 controlled by the institutional issuer 12, e.g. financial institution (FI) 12 or other service provider 14. Upon a notification 336, the customer USR or other person, e.g. clerk, such as over the phone, may confirm the identity of the customer USR. As a result of a notification 336 and subsequent communication, an institutional issuer 12 may allow a transfer of money from another account, e.g. such as possible for a fee, such as in cases where the transaction request 52 is declined because the associated account 182 is over-limit.
[0113] Upon notification 336, the system may determine 338 if a system denial override is possible or not, such as based on the issuer 12 and/or the user USR. If yes 340, the transaction may be authorized 316, and a notification 318 may be sent toward the merchant 20. Such an override 340, 316 may be useful, such as for a customer user USR in otherwise good standing that has a valid and immediate need for a product, service, or funds, that is otherwise allowable by the centralized issuer rules 16 as well as the customer-controlled rules 160, e.g. such as for but not limited to an emergency, travel abroad, or limited card use by a child.
[0114] If the system 100 determines 338 that a user override is not possible or appropriate 342, the system 100 may then proceed to deny 352 the transaction and notify 354 the merchant 20, and may also take other actions, such as but not limited to closing 356 the account 182, attempting to identify 358 a potential fraudster FRD, notifying 360 authorities, e.g. police, and/or organizing 362 associated information, such as for evidence, reporting, or investigation.
[0115] As also seen in FIG. 8 , a determination 344 may be made whether a central override is possible 348, e.g. such as in situations where determination 313 (FIG. 7 ) is made that the transaction request 52 complies 314 with customer-controlled rules 160, and a system decision 313 is made to allow 319 the transaction, even though the transaction request has not complied with all central rules 16. As also seen in FIG. 7 , if a central override decision 313, is negative 317, the system may proceed to deny 352 the transaction, and may take one or more actions, e.g. 354, 356, 358, 360, and/or 362, such as seen in FIG. 8 .
[0116] A central override determination 313 and decision 319 may provide great value for both the system 100 and for customers USR. In one example, an institutional issuer 12 may at one time stop, i.e. disallow, transactions from a designated region or country, e.g. Tahiti, such as due to increased fraud generated from that region or country. While the institutional rules 16 may not 308 be met, the system 100 and process 300 may still check 312 the customer-controlled rules 160 and/or parameters 282. In the above example, if the customer user USR has indicated that they want transactions to be authorized in the region or country, e.g. Tahiti, such as for certain dates, the institutional issuer 12 may preferably override 319 its prior logic 308, either automatically or under manual review, to approve 319 the transaction, such as assuming no other decline reasons take precedence.
[0117] System embodiments 100 and associated processes 300 that incorporate a central override determination 313 may allow an institutional issuer 12 to allow more transactions that it would otherwise, even though a common result of the customer controlled system and process is to decline more transactions, based at least in part on the customer-controlled rules 160 and/or parameters 282.
[0118] As seen in FIG. 9 , an authorization entity, such as the institutional issuer 12 or associated service provider 14, may initiate actions and/or notifications associated with non-compliance of a transaction request with customer-controllable rules 160, which provides significant advantages over prior transaction systems.
[0119] In the exemplary process, i.e. subroutine 320 seen in FIG. 9 , a determination 372 is made whether a customer user USR is to be notified if a request 52 fails to meet the rules 160 controlled by the customer user USR associated with the account 182. If the decision 372 is yes 374, the system 100 may notify 376 the customer user USR, e.g. automatically, such as through a telephonic connection to a telephone 256 associated with the account 182.
[0120] Upon notification 376, the system may determine 378 if a system denial override is possible or not, such as based on the institutional issuer 12 and/or the customer user USR. If yes 380, the transaction may be authorized 316, and a notification 318 may be sent toward the merchant 20. Such an override 380, 316 may be useful for a variety of circumstances, such as:
-
- [0121] for a customer user USR that had previously set a customer-controllable rule 160 or parameter 282 to disallow, i.e. prevent, foreign transaction, who then had forgotten to reset the customer-controllable rule 160 or parameter 282 to allow foreign transactions before traveling; or
- [0122] for a customer user USR that had previously set a customer-controllable rule 160 or parameter 282 to disallow, i.e. prevent, a gambling purchase, who then had changed their mind and had forgotten to reset the customer-controllable rule 160 or parameter 282 to allow such a transaction.
[0123] The customer user USR may be required to update the rules 160, at least temporarily, such that the transaction complies with the updated customer rules 160.
[0124] Such an override 380, 316 may also be useful for a customer user USR in otherwise good standing that has a valid and immediate need for a product, service, or funds, that is otherwise allowable by the centralized issuer rules 16 as well as the customer-controlled rules 160, e.g. such as for but not limited to an emergency, travel abroad, or limited card use by a child. The customer user USR may be required to update the rules 160, at least temporarily, such that the transaction complies with the updated customer rules 160.
[0125] If the system 100 determines 378 that an override is not possible or appropriate 382, or if the customer user USR associated with the account 182 is riot able to be notified, the system 100 may then proceed to deny 392 the transaction and notify 394 the merchant 20, and may also take other actions, such as but not limited to closing 396 the account 182, attempting to identify 398 a potential fraudster FRD, notifying 400 authorities, e.g. police, or other entities, e.g. interested parties, and/or organizing 402 associated information, such as for evidence, reporting, or investigation.
[0126] If the institutional issuer 12 or associated service provider 14 identifies attempts to access the account 182 in a way that the consumer user USR has indicated 160 they wish to prevent, the institutional issuer 12 can be aggressive in restricting such access, because the restriction 160 was customer initiated, and the concern about false positives is greatly reduced.
[0127] If an attempt to access the account is made counter to a security setting that either the institutional issuer 12, e.g. bank or the customer user USR established, the financial institution 12, e.g. Wells Fargo, may preferably decline account access, and may preferably quickly contact the customer user USR, e.g. immediately or as soon as possible, via any and all expeditious means, such as by but not limited to any of paging, phoning or emailing the customer user USR, to ascertain whether the attempt was in fact fraudulent.
[0128] If the authorization request is confirmed to be fraudulent, the institutional issuer 12, e.g. financial institution 12 may preferably shut down all access to the account 182, such as immediately, and may preferably notify the authorities and/or the merchant 20, as to the fraudulent transaction attempt, thereby potentially improving the chance of catching the fraudster FRD, and initiating steps to provide the customer user USR more timely with a new access device 15,17 to replace the one that had been compromised.
[0129] As seen in the exemplary methods shown in FIG. 7 , FIG. 8 , and FIG. 9 , a merchant 20 is able to follow existing rules for authorization, wherein authorization for a fraudster FRD may be declined 60, 392, by the issuer 12 or associated service provider 14 based on the customer-controlled rules 160, and declined 170 (FIG. 2 ) for any of goods, services, and/or funds, even if such a fraudster FRD has provided all typically required information to the merchant/payee 20.
[0130] Therefore, if a fraudster FRD tries to obtain 70 money, merchandise, or services using stolen customer account information, the request may be declined 170 and may preferably investigated if the request 50,52 is outside of the customer set parameters 160,282.
[0131] FIG. 10 is a schematic view 410 of an attempted purchase transaction through a “brick and mortar” location 20, and a request for authorization for an exemplary customer controlled account 182, by an authorized user USR of the customer controlled account 182. FIG. 11 is a schematic view 430 of an attempted purchase transaction through a “brick and mortar” location 20, and a request for authorization for an exemplary customer controlled account 182 by an unknown user, such as a suspected fraudster FRD, of the customer controlled account 182.
[0132] As seen in FIG. 10 , a user USR typically provides a clerk CLK with the access device 15, either directly or by interaction through a point of sale (POS) terminal 414. The user may also enter other related information, such as a personal identification (PIN) number through the POS terminal. As noted above, the authorization request 52 is then sent for processing, e.g. 300, such as to the institutional issuer computer 12 or to a service provider computer 14 associated with the institutional issuer 12. If the request 52 meets both the centralized, i.e. financial issuer rules 16 as well as the customer-controlled rules 160, the transaction is typically authorized. If the transaction request is denied due to non-adherence to one or more customer-controlled rules 160, the clerk may prompt the user USR to communicate with the institutional issuer 12 or service provider 14, such as to confirm user identity and to update the customer-controlled rules 160 to allow the transaction.
[0133] As seen in FIG. 11 , an unknown user FRD may also try to attempt a transaction for products, services, and/or funds through a store 20, such as by presenting a stolen access device 15, or other means to convey information related to the access device 15 and/or account 182. However, if the transaction request is denied due to non-adherence to one or more customer-controlled rules 160, the clerk may prompt the alternate user FRD to communicate with the issuer 12 or service provider 14, such as to confirm user identity, which may not be possible for the unknown user USR. In such a situation, the institutional issuer 12 or service provider 14 may controllably attempt to contact or notify 376 (FIG. 9 ) the customer user USR, such as by telephone 256, by an approved email account listed for the user USR, or directly though a user terminal 250 associated with the proper user USR, through a secure connection. As described above, the fraudster FRD may be thwarted in their attempt to defraud the system 100, due to non-adherence to one or more customer-controlled rules 160, and be denied 170 (FIG. 2 ) goods, services, and/or funds 70.
[0134] FIG. 12 is a schematic view 450 of an attempted purchase transaction through an internet site 20i, and a request for authorization for an exemplary customer controlled account 182 by an authorized customer user USR of an access device 15 associated with the customer controlled account 182. FIG. 13 is a schematic view 470 of an attempted purchase transaction through an internet site 20i, and a request for authorization for an exemplary customer controlled account 182 by an unknown user, e.g. a suspected fraudster FRD, of an access device 15 or related information associated with the customer controlled account 182.
[0135] As seen in FIG. 12 , a user USR typically provides information associated with the access device 15 through a user terminal 250, such as within a secure session established with the Internet site 20i. The user may also enter other related information, such as a personal identification (PIN) number through the user terminal 250.
[0136] As noted above, the authorization request 52 is then sent for processing, e.g. 300, such as to the institutional issuer computer 12 or to a service provider computer 14 associated with the institutional issuer 12. If the request meets both the centralized, i.e. financial issuer rules 16 as well as the customer-controlled rules 160, the transaction is typically authorized. If the transaction request 52 is denied due to non-adherence to one or more customer-controlled rules 160, the internet site 20i or a site administrator ADM may prompt the customer user USR to communicate with the institutional issuer 12 or service provider 14, e.g. using the phone 256, such as to confirm user identity and to update the customer-controlled rules 160 to allow the transaction.
[0137] As seen in FIG. 13 , an unknown user FRD may also try to attempt a transaction for products, services, and/or funds 70 through a an Internet site 20i, such as within a secure session established with the Internet site 20i. The unknown user FRD may also enter other related account information, such as a personal identification (PIN) number through the user terminal 250f.
[0138] However, if the transaction request 52 is denied due to non-adherence to one or more customer-controlled rules 160, the internet site 20i or an associated administrator ADM may prompt the unknown user FRD to communicate with the institutional issuer 12 or service provider 14, such as to confirm user identity, which may not be possible for the unknown user USR. In such a situation, the institutional issuer 12 or service provider 14 may controllably attempt to contact or notify the customer user USR, such as by telephone 256, by an approved email account listed for the user USR, or directly though a user terminal 250 associated with the proper user USR, through a secure connection. If the proper user USR is contacted, and it is determined that the unknown user FRD is indeed a suspected fraudster FRD, the institutional issuer 12 or service provider 14 can then take appropriate actions to at least deny 392 (FIG. 9 ) the transaction and notify 394 (FIG. 9 ) the network merchant 20i, and may close the account 396, attempt to identify 398 the fraudster FRD, notify 400 one or more authorities, and/or further investigate the matter 402.
[0139] The customer-controlled rules 160, associated system 100, and method 300 inherently reduce incidents where fraudulent access to consumer and business financial access devices 15, such as credit and check cards, are either approved in instances where fraud is taking place, or where the use is not approved but could have been.
[0140] As well, the customer-controlled rules 160, associated system 100, and method 300 allow the system 100 to identify fraudulent attempts timely to use the access device 15 more accurately and more timely, so that the remedial action can be taken.
[0141] Furthermore, the customer-controlled rules 160, associated system 100, and method 300 enlist users USR of access devices 15 more actively in efforts to more effectively counter the activities of fraudsters FRD.
[0142] In addition, the customer-controlled rules 160, associated system 100, and method 300 create competitive advantages for an institutional issuer 12, by providing enhanced account security for customer users USR, such as to position the institutional issuer 12 as a trusted financial provider and industry leader.
[0143] In the customer-controlled rules 160, associated system 100, and method 300, access devices 15 are therefore typically issued with enhanced security features and processes that allow customers USR greater control of the circumstances under which their account can be accessed, thereby ensuring that if a fraudster FRD tries to access the account without knowledge the consumer set controls 160, the system 100 can quickly take remedial action, with reduced instances of false positives.
[0144] The customer-controlled rules 160, associated system 100, and method 300 draw the customer USR into the process of controlling access to the user account 182, by allowing the customer to participate in both circumstances under which the access device 15 may be accessed, and in verifying use of the access device 15 at times when the access device 15 and/or associated account 182 is accessed.
[0145] The customer controlled account system 100 therefore provides distributed account security that includes input, e.g. rules 160, from the account holder, i.e. customer user USR of an account, as well as real-time management of account transaction approval, such as comprising customer authorization of transactions. The customer controlled account system 100 gives the customer user USR a wide variety of expanded control options, 160,282, which are difficult for fraudsters FRD to circumvent.
[0146] As well, in the customer-controlled rules 160, associated system 100, and method 300, an account holder, and/or other appropriate parties within the network who have a need to know, may be notified if and when there is an attempt to access the account holder's credit card and/or debit card account in a manner that is counter to parameters for account access that have been set by the account holder. This allows the account holders and/or other appropriate parties to take preemptive action to thwart the intentions of fraudsters FRD, not only for the account holder USR, in which fraudulent access has been attempted, but potentially for others, based upon information gained as a result of implementation and use of the customer-controlled rules 160, associated system 100, and method 300.
[0147] The customer-controlled rules 160, associated system 100, and method 300 may provide significant value for a variety of different transaction scenarios. For example, in one exemplary scenario, a customer user USR may be declined for one or more valid institutional rules 16, such as for an over-limit (OVL) condition or a delinquent account. In such a scenario, a transaction request 52 may also fail a customer-controlled rule 160 or parameter, such as for a transaction that occurs in a foreign country, wherein the customer USR has prohibited out of country transactions. Although the institutional rules 16 clearly determine a decline, the customer settings 160 may preferably be communicated to any or all interested parties, e.g. the customer USR and the issuer 12, and/or the merchant 20, to the hypothesis that fraud might be taking place, whereby one or more actions may be taken, other than simply to decline a transaction. In contrast, a conventional transaction system, e.g. that only uses central rules to “decline” or “approve” a transaction, may overlook such a transaction.
[0148] In another exemplary scenario, a customer user USR may be declined for one or more valid institutional rules 16, such as for an institutional issuer 12 that decides to decline all transactions from a designated region or country, e.g. Tahiti. In such a scenario, the customer-controlled system 100, and method 300 may allow the customer to indicate that they are traveling to the designated region or country, e.g. Tahiti, via the system 100. The institutional issuer may preferably approve such a transaction, based on the customer input, or may call or otherwise contact the customer USR to confirm that the transaction is acceptable to approve.
[0149] In an alternate exemplary scenario, a customer user USR may be declined for one or more valid institutional rules 16, but may meet 314 the customer settings 160,282. As seen in FIG. 7 and FIG. 8 , the institutional issuer 12 or other provider 14 may contact the customer USR via the system 100, such as to contact the customer USR and see if there are extenuating circumstances which may warrant a central override 319.
[0150] Although the customer controlled account system and its methods of use are described herein in connection with credit card and/or check card devices operating across a network, the structure and techniques can be implemented for a wide variety of transactional devices, such as but not limited to credit cards, debit cards, gift cards certificates and/or coupons associated with a central institutional issuer or bank, gift cards certificates and/or coupons associated with a specific store or chain of stores, or any combination thereof, as desired.
[0151] As well, although the customer controlled account system and its methods of use are described herein in connection with client terminals operating across a network, such as computers, ATMs, Point-of-Sale terminals, servers, wireless devices, personal computers and other microprocessor-based devices, such as wireless appliances, the structure and techniques can be implemented for a wide variety of electronic devices and systems, or any combination thereof, as desired.
[0152] Furthermore, while the customer controlled account system and its methods of use are described herein in connection with computing devices and intranets or LAN's, the apparatus and techniques can be implemented for a wide variety of electronic devices and networks or any combination thereof, as desired.
[0153] In addition, while the customer controlled account system and its methods of use are described herein in connection with financial transaction systems implemented across a network, the techniques can be implemented for a wide variety of user accounts, such as but not limited to security systems, media or content storage and/or access, and/or information storage and/or retrieval systems.
[0154] Accordingly, although the invention has been described in detail with reference to a particular preferred embodiment, persons possessing ordinary skill in the art to which this invention pertains will appreciate that various modifications and enhancements may be made without departing from the spirit and scope of the claims that follow.
Claims
The invention claimed is:
1. A process for managing account security implemented across a network, comprising the steps of:
establishing an account for at least one account holder through a network through a computer associated with a central entity;
establishing at least one access device associated with the account, wherein at least one user is associated with at least one of the access devices for one or more transactions, wherein use of the established access devices is defined by at least one rule defined by the central entity and at least one rule that is controllable by at least a customer associated with the account;
defining a first configuration of the customer-controllable rules including:
receiving from the customer, by the computer, via a user interface presented to the customer, a first input specifying a selection of at least one parameter associated with the customer-controllable rules;
storing the at least one parameter in a database to define the first configuration of the customer-controllable rules;
modifying the customer-controllable rules from the first configuration to a second configuration of the customer-controllable rules, including:
receiving from the customer, by the computer, via the user interface presented to the customer, a second input specifying a selection of at least one parameter associated with the customer-controllable rules;
storing the at least one parameter in the database to define the second configuration of the customer-controllable rules;
responding to a request for a transaction associated with at least one of the established access devices, including, by the computer, accessing the at least one parameter from the database, applying the at least one customer-controllable rule, and transmitting the response over the network, wherein the response is based at least in part on the customer-controllable rules.
2. The process of claim 1, wherein the transaction response comprises any of:
an approval of the requested transaction if the transaction request complies with both the first set of rules and the second set of rules; and
a decline of the requested transaction based upon both the first set of rules and the second set of rules.
3. The process of claim 1 wherein the transaction response comprises a decline of the requested transaction based upon both the first set of rules and the second set of rules, and a notification of the decline to any of the customer and another entity.
4. The process of claim 1, wherein the transaction response comprises an approval of the requested transaction and an initiation by the central entity of a notification and a communication with the customer, if the requested transaction complies with each of the second set of rules and does not comply with at least one of the first set of rules.
5. The process of claim 1, wherein the transaction response comprises an approval that is conditionally based upon customer input.
6. The process of claim 1, wherein the access device comprises at least one of a credit card, debit card, a gift card, a gift certificate, and a coupon.
7. The process of claim 1, wherein the access device is configured to access by at least one of an account number, a user name, a CVC value, an expiration date, information associated with the customer, and other account verification information.
8. The process of claim 1, wherein at least one of the customer-controllable rules is preset by at least one of the central entity and a service provider associated with the central entity at the time the access devices are established.
9. The process of claim 1, further comprising the steps of:
receiving a transaction request at least one of a merchant, a store, a service and a payee from at least one of an authorized user of the access device and a user other than an authorized user;
determining whether the request is acceptable based on the rules defined by the central entity and the user-controllable rules; and
authorizing the requested transaction if the requested transaction complies with each of the rules defined by the central entity and each of the rules defined by the customer.
10. The process of claim 9, further comprising the step of:
notifying at least one of the account holders and one of the users of the account if the transaction request is denied based on at least one rule defined by any of the central entity and the customer.
11. The process of claim 10, further comprising the step of:
allowing the customer to update at least one of the customer-controllable rules such that the requested transaction complies with each of the rules defined by the central entity and each of the rules defined by the customer; and
authorizing the requested transaction.
12. The process of claim 1, further comprising the step of:
allowing the customer to update at least one customer-controllable rule.
13. The process of claim 1, wherein the rules defined by the customer allow different levels of control between different established access devices associated with the account.
14. The process of claim 1, wherein the rules defined by the customer comprise at least one transaction based on at least one of a country and region, transactions based on at least one of gaming and gambling, transactions over an amount, online transactions, cash advances, cash withdrawals, transactions based on date, transactions based on day, transactions based on time of day, transactions based on a selectable user of the account, and transactions based on merchant.
15. The process of claim 1, further comprising: sending the customer a notification when a request for a transaction would be declined based on at least one customer-controlled rules; further comprising allowing the customer to override the at least one customer-controlled rules to permit the transaction that would be declined.
16. The process of claim 15, wherein the override by the customer permits no more than one transaction and wherein the override fails to change the at least one customer controlled rule for another transaction that may occur after the transaction.
17. The process of claim 15, wherein allowing the customer to override modifies the at least one customer-controlled rules.
18. The process of claim 1, wherein the customer is the account holder.
Patent Citations (46)
| Patent | Date | Inventor | Cited By |
|---|---|---|---|
| US6175922(B1) | 2001-01-01 | Wang | Applicant |
| US6363488(B1) | 2002-03-01 | Ginter et al. | Applicant |
| US6438594(B1) | 2002-08-01 | Bowman-Amuah | Applicant |
| US6601192(B1) | 2003-07-01 | Bowman-Amuah | Applicant |
| US6607136(B1) | 2003-08-01 | Atsmon et al. | Applicant |
| US6629081(B1) | 2003-09-01 | Cornelius et al. | Applicant |
| US6636242(B2) | 2003-10-01 | Bowman-Amuah | Applicant |
| US6636833(B1) | 2003-10-01 | Flitcroft et al. | Applicant |
| US7043230(B1) | 2006-05-01 | Geddes et al. | Applicant |
| US2001/0032192(A1) | 2001-10-01 | Putta et al. | Applicant |
| US2001/0051920(A1) | 2001-12-01 | Joao et al. | Applicant |
| US2002/0091635(A1) | 2002-07-01 | Dilip et al. | Applicant |
| US2002/0095386(A1) | 2002-07-01 | Maritzen et al. | Applicant |
| US2002/0152160(A1) | 2002-10-01 | Allen-Rouman et al. | Applicant |
| US2003/0028481(A1) | 2003-02-01 | Flitcroft et al. | Examiner |
| US2003/0093367(A1) | 2003-05-01 | Allen-Rouman et al. | Applicant |
| US2003/0208439(A1) | 2003-11-01 | Rast | Applicant |
| US2003/0212904(A1) | 2003-11-01 | Randle et al. | Applicant |
| US2004/0059686(A1) | 2004-03-01 | Levesque | Applicant |
| US2004/0097217(A1) | 2004-05-01 | McClain | Applicant |
| US2004/0185830(A1) | 2004-09-01 | Joao et al. | Applicant |
| US2004/0188519(A1) | 2004-09-01 | Cassone | Applicant |
| US2005/0038715(A1) | 2005-02-01 | Sines et al. | Applicant |
| US2005/0131826(A1) | 2005-06-01 | Cook | Applicant |
| US2005/0182724(A1) | 2005-08-01 | Willard | Applicant |
| US2005/0273431(A1) | 2005-12-01 | Abel et al. | Applicant |
| EP1029311 | 2001-06-01 | Applicant | |
| EP1115095 | 2001-07-01 | Applicant | |
| EP1265200 | 2002-06-01 | Applicant | |
| EP1153375 | 2003-01-01 | Applicant | |
| EP1515216 | 2005-03-01 | Applicant | |
| EP1555591 | 2005-07-01 | Applicant | |
| EP1621960 | 2006-02-01 | Applicant | |
| WO16252 | 2000-03-01 | Applicant | |
| WO49586 | 2000-08-01 | Applicant | |
| WO73958 | 2000-12-01 | Applicant | |
| WO142965 | 2001-06-01 | Applicant | |
| WO123989 | 2001-07-01 | Applicant | |
| WO241236 | 2002-05-01 | Applicant | |
| WO3003704 | 2003-01-01 | Applicant | |
| WO3040869 | 2003-05-01 | Applicant | |
| WO3096252 | 2003-11-01 | Applicant | |
| WO2004017170 | 2004-02-01 | Applicant | |
| WO2004038528 | 2004-05-01 | Applicant | |
| WO2005015485 | 2005-02-01 | Applicant | |
| WO2006004794 | 2006-01-01 | Applicant |
Non-Patent Literature (13)
- Barlow, T. et al; Trust Negotiation in Electronic Markets; Proceedings of the Eighth Research Symposium on Emerging Electronic Markets (RSEEM 01); Maastricht, The Netherlands, Sep. 16-18, 2001; http://www-i5.informatik.rwth-aachen.de/conf/rseem2001/.Applicant
- Brennan, D.; In the Eye of the Cardholder; Banker, 151, 900, 82; Feb. 2001; Copyright 2001 Financial Times Information Ltd.Applicant
- Consumer Card Services: Credit Card Authorization Services; http://www.eds.com/services/consumercard/; © 2006 Electronic Data Systems Corporation.Applicant
- Gifford, D.K. et al.; Payment Switches for Open Networks; Proceedings of the First USENIX Workshop on Electronic Commerce; New York, NY; Jul. 1995.Applicant
- Gillett, M.T. et al; Developments in Cyberbanking; Business Lawyer v59n3 pp. 1335-1345; May 2004.Applicant
- Husemann, D.; The Smart Card: Don't Leave Home Without It; IEEE Concurrency vol. 7, No. 2 p. 24-7; IEEE; Apr.-Jun. 1999; USA.Applicant
- Kay, W.; Banks Eye One-Page Web Wonder; The American System of Profiling All Your Accounts on One Web Page Is Beginning to Gain Acceptance, Says William Kay. But the Big Problem Centres on the Dangers of Fraud; Nov. 2, 2002; Copyright 2002 Independent Newspapers (UK) Limited Source: Financial Times Information Limited-Europe Intelligence Wire.Applicant
- Lepofsky, R.; Preventing Identity Theft; Risk Management vol. 51, No. 10 p. 34-40; Risk Manag. Soc; Oct. 2004; USA.Applicant
- Marlin, S.; Wells Fargo Makes Good on eBay [Online Retail Payments]; Information WEEK No. 992 p. 67; CMP Media Inc; Jun. 7, 2004; USA.Applicant
- Puente, F. et al.; Improving Online Banking Security With Hardware Devices; Proceedings of the IEEE 39th International Carnahan Conference on Security Technology (IEEE Cat. No. 05CH37697) p. 174-7; IEEE, Piscataway, NJ, USA; 2005.Applicant
- Shogase, H.; A Very Intelligent Credit Card Is a True and Private Pocket Bank; Elettrotecnica vol. 76, No. 3 p. 225-30; Mar. 1989; Italy.Applicant
- Smith, A.; Collaboration in Combating Online Fraud; Banking Technology p. XVI-I; IBC Business Publishing; Apr. 2005; UK.Applicant
- VASCO Launches Digipass Host Authentication To Tackle Rapidly Growing Phishing Problem; PR Newswire, p. NA; Aug. 17, 2004.Applicant