Mobile User Identify And Risk/Fraud Model Service
Transactions using, for example, Near Field Communication (NFC), Bluetooth, online, or other applications, may pose a risk of fraud or identity theft. According to an embodiment, a method of evaluating transaction information in view of potential fraud and/or risk includes receiving transaction information at a remote location. The method also includes correlating the received transaction information with user data maintained at the remote location. The method further includes generating a score and/or risk or fraud data based on the correlating. Such transactions may be facilitated by a payment service provider. Related methods, devices, and systems are also disclosed.
Latest eBay Patents:
This application claims priority to U.S. Provisional Application Ser. No. 61/059,395 filed on Jun. 6, 2008, and U.S. Provisional Application Ser. No. 61/059,907 filed on Jun. 9, 2008, the contents of which are hereby incorporated by reference in their entirety.
BACKGROUND1. Technical Field
Embodiments of the present disclosure generally relate to financial transactions, and more particularly, to methods and systems for financial transactions conducted by a user that may be identified and evaluated in view of potential risk and/or fraud.
2. Related Art
“Contactless technology” refers to short distance communications between two devices that are not physically connected. A wide variety of “contactless technology” exists today. Near Field Communication (NFC) is a specific type of “contactless technology” that is of high importance to Mobile Network Operators (MNOs) and to Service Providers (SP), for example, banks. NFC is a short-range high frequency wireless communication technology that enables the exchange of data between devices typically over about a 10 centimeter (or about 4 inches) distance, thus providing a fast, simple and secure way for a user to experience a range of contactless services with a mobile device.
One example of an NFC technology application is financial transactions. NFC mobile devices and other types of contactless devices such as radio frequency-enabled credit/debit cards, key fobs, etc. are experiencing rapid growth worldwide in various industries including transportation, retail, parking and other industries that will now accept NFC mobile payments and other types of contactless payments.
As an example, wireless mobile devices that include an NFC device and a smart card, which may use an RFID for identification purposes, allow a person to securely make a simple transaction, such as purchasing a retail item. Typically, a consumer waves the wireless mobile NFC device on a reader to effect a monetary transfer, and a price of the item is deducted from a total amount that is available and stored on the smart card of the wireless mobile device. Optionally, the amount of the item may be forwarded to a server that can identify the identification code of the particular RFID and then subsequently charge the person for the purchase of the retail item. Such NFC-based point of sale (POS) transactions provide advantages such as eliminating the need to carry cash and enabling a faster financial transaction.
Because customers are interested in being able to use their mobile device for contactless services, a new mobile NFC ecosystem has been created by the Global System for Mobile communication Association (GSMA), which is a global trade association representing over 700 GSM mobile phone operators throughout the world. See “Mobile NFC Services,” GSMA, Version 1.0, February 2007. Such ecosystem involves different players or entities and new roles including:
Customer—the customer subscribes to a Mobile Network Operator (MNO) and a service provider and is a customer of a merchant.
MNO—the MNO provides a full range of mobile services to the Customer. Also, the MNO may provide UICC and NFC terminals plus Over the Air (OTA) transport mechanisms.
Service Provider (SP)—the SP provides contactless services to the Customer. Examples of SPs include banks, credit card issuers as well as public transport companies, loyalty programs owners, etc.
Retailer/Merchant—the retailer/merchant may operate an NFC capable point of sales terminal.
Trusted Service Manager (TSM)—the TSM securely distributes and manages NFC applications and may have, for example, a direct relation or a relation via clearing houses to SPs.
Handset, NFC Chipset and UICC Manufacturer—the manufacturers produce mobile NFC/communication devices and the associated UICC hardware.
Reader Manufacturer—the reader manufacturer makes NFC reader devices.
Application Developer—the application developer designs and develops mobile NFC applications.
Standardization bodies and industry fora—develop a global standard for NFC, enabling interoperability, backward compatibility and future development of NFC applications and services.
NFC requires cooperation between the different players of the GSMA ecosystem. Each player may have its own expectations, for example, the Customer expects convenient, friendly and secure services within a trusted environment; the SPs want their applications to be housed and used in as many mobile devices as possible; and the MNOs want to provide new mobile contactless services that are secure, high quality and consistent with the existing services experienced by the Customer. But although each player may have its own culture and expectations, they all have the same basic requirement—the need for security and confidentiality.
The Trusted Service Manager (TSM), in particular, brings trust and convenience to the complex, multi-player NFC ecosystem. The TSM role includes providing a single point of contact for the SPs, e.g., banks, to access their customer base through the MNOs, and to secure download and lifecycle management for mobile NFC applications on behalf of the SPs. The TSM does not disrupt the SP's business model as the TSM does not participate in the transaction stage of the service.
In addition to NFC based POS payments, there are several prevalent models of payments in the mobile industry including:
(i) Short Message Service (SMS)—SMS is a communications protocol that allows the interchange of short text messages between mobile devices; and
(ii) Mobile Internet-based payment—Customers routinely search for and purchase products and services through electronic communications with online merchants over electronic networks such as the Internet. In this regard, individual customers may frequently engage in transactions with a variety of merchants through, for example, various merchant websites. A credit card may be used for making payments over the Internet. A disadvantage of credit card usage is that online merchants may be exposed to high fraud costs and “chargeback fees,” bearing liability because there is no credit card signature with an online sale.
The types of payment transaction models described above may provide information that is limited to information on credit card, financial instrument, user name and password that flows through the system. A problem exists in these models because there is no identity, risk, or fraud information that may be obtained by, for example, Service Providers to evaluate the transaction. The Service Providers, for example, may only have visibility into transactions involving their own services, thus limiting meaningful evaluation of potentially risky and/or fraudulent transactions.
SUMMARYAs will be further described herein in relation to various embodiments, a service is provided that may generate a transaction score and/or potential risk or fraud data for online, Near Field Communication (NFC), Bluetooth or other types of transactions.
In accordance with an embodiment of the disclosure, a method of evaluating transaction information in view of potential fraud and/or risk includes receiving transaction information at a remote location. The method also includes correlating the received transaction information with user data maintained at the remote location. The method further includes generating a score and/or risk or fraud data based on the correlating.
In accordance with another embodiment of the disclosure, a client device includes one or more processors and one or more memories adapted to store a plurality of machine-readable instructions. When executed by the one or more processors, the machine-readable instructions are adapted to cause the client device to provide transaction information to a remote location, wherein the transaction information is associated with a user-merchant transaction, a user-user transaction, a merchant-user transaction and/or a merchant-merchant transaction; and provide a user identifier to the remote location wherein the remote location creates user data associated with the client device based on the user identifier so that the user data may be correlated with the transaction information thus allowing generation of potential fraud and/or risk data.
In accordance with another embodiment of the disclosure, a method of providing a fraud engine service includes maintaining a plurality of transaction records, the transaction records comprising transaction information associated with a plurality of transactions by a user. The method also includes receiving new transaction information wherein the new transaction information is associated with a new transaction by the user. The method also includes correlating the new transaction information with the maintained plurality of transaction records. The method further includes generating a score or potential fraud data based on the correlation.
In accordance with another embodiment of the disclosure, a fraud engine system includes a plurality of transaction records associated with users, the transaction records comprising transaction information associated with a plurality of user transactions. The fraud engine system also includes one or more processors and one or more memories adapted to store a plurality of machine-readable instructions. When executed by the one or more processors, the machine-readable instructions are adapted to cause the fraud engine system to: maintain the plurality of transaction records associated with users; receive new transaction information from a client device, wherein the new transaction information is associated with a new user transaction; correlate the new transaction information with the maintained plurality of transaction records; generate a score or potential fraud data based on the correlation; and offer the generated score or potential fraud data to subscribers in view of identifying and preventing fraud.
These and other features and advantages of the embodiments of the present disclosure will be more readily apparent from the detailed description of the embodiments set forth below taken in conjunction with the accompanying drawings.
Like element numbers in different figures represent the same or similar elements.
DETAILED DESCRIPTIONIn accordance with various embodiments described herein, methods and systems are provided that may generate a transaction score and/or data to detect and prevent potential identity theft, transaction risk or fraud when using a payment system with, for example, a Near Field Communication (NFC), blue tooth or infrared enabled client device. Such transaction score or potential risk/fraud data may be generated in real time and may be based on user data that includes a user profile and transaction information that may pertain, for example, to financial transactions performed by a user in relation to various merchants, or other user to user, merchant to merchant, or merchant to user transactions. Such transactions may be facilitated by a payment service provider.
Referring now to the drawings wherein the showings are for purposes of illustrating embodiments of the present disclosure only, and not for purposes of limiting the same,
A financial transaction using, for example, an NFC based Point of Sale (POS) payment system, may be made using a client device 130 such as an NFC enabled mobile device through a retailer or merchant server 110. It should be appreciated that although an NFC application is illustrated in this embodiment, the system is not limited to NFC applications, but may also apply to other types of applications, for example, video game consoles, DVRs, and other appliances.
Client device 130 may be implemented using any appropriate combination of hardware and/or software configured for wired and/or wireless communication over a network. For example, in one embodiment, client device 130 may be implemented as a personal computer of a user 120 (also referred to as a “customer” or “consumer”) in communication with the Internet or another network. In other embodiments, client device 130 may be implemented as a wireless telephone, personal digital assistant (PDA), key fob, smart card, notebook computer and/or other types of computing devices. Furthermore, client device 130 may be enabled for NFC, Bluetooth, online, infrared communications and/or other types of communications.
Client device 130 may include various applications as may be desired in particular embodiments to provide desired features to client device 130. For example, in various embodiments, applications may include security applications for implementing client-side security features, programmatic client applications for interfacing with appropriate application programming interfaces (APIs) over a network, or other types of applications.
Client device 130 may further include one or more user identifiers that may be implemented, for example, as operating system registry entries, cookies associated with a browser application, identifiers associated with hardware of client device 130, or other appropriate identifiers. In one embodiment, a user identifier may be used by a payment service provider 140 to associate client device 130 or user 120 with a particular account maintained by payment service provider 140 as further described herein.
Merchant server 110 may be maintained, for example, by a retailer or by an online merchant offering various products and/or services in exchange for payment to be received over a network such as the Internet. Merchant server 110 may be configured to accept payment information from user 120 via, for example, client device 130 and/or from a payment service provider 140 over a network. It should be appreciated that although a user-merchant transaction is illustrated in this embodiment, the system may also be applicable to user-user, merchant-merchant and/or merchant-user transactions.
Merchant server 110 may use a secure gateway 112 to connect to an acquirer 115. Alternatively, merchant server 110 may connect directly with acquirer 115 or processor 120. Once verified, acquirer 115, which has a relation or subscription with payment service provider 140, processes the transaction through processor 120 or payment service provider 140. Brands 125, for example, payment card issuers, which also have a relation or subscription with payment service provider 140, are then involved in the payment transaction which will enable user 120 to finalize the purchase.
Payment service provider 140 may have data connections 155, 156, 157 and 158 with a subscriber client device 130, a subscriber acquirer 115, a subscriber processor 120 and/or a subscriber brand 125, respectively, to communicate and exchange data. Such data connections 155, 156, 157 and 158 may take place, for example, via SMS or a Wireless Application Protocol (WAP) over a network. In addition, according to one or more embodiments, payment service provider 140 may have a data connection 160 with subscriber Internet companies, Internet mortgage companies, Internet brokers or other Internet companies 150.
In typical payment transactions, acquirers 115 or brands 125, for example, have visibility only to information on transactions in which they are involved. However, one acquirer or one brand may not have visibility into overall transactions that may use different acquirers or brands. For example, a payment card issuer would not have visibility into a user's transactions made with another payment card issuer. In addition, such typical payment transactions may not have any information other than credit card, financial instrument, user name and password that flows through the system. Such typical payment transactions, including for example NFC or online transactions, may pose a risk of fraud and identity theft. As such, a number of online applications have developed solutions to try and minimize the ability for fraud to occur. One such online application is Paypal, Inc., which is an online payment system. To verify that a user has a bank account, the Paypal online banking system requires that a user provide information for a service provider such as a bank account and the Paypal online banking system deposits a small amount of money into the bank account and requires that the customer verify that the money is deposited.
In a payment system according to the present embodiment, a financial transaction using client device 130, for example, an NFC or Bluetooth enabled mobile device, payment service provider 140 may additionally generate certain data as discussed below to protect against fraud and identify theft.
In addition, it is possible that geo-location using for example a Global Positioning Satellite (GPS) may be used to identify the location of a geo-location enabled client device 130 (and correspondingly the customer). The location of customers may be helpful in establishing risk models for transactions. Further to the location of customers, it is desirable to identify and evaluate a financial transaction carried out by a customer in view of potential risk and/or fraud.
Referring now to
Payment service provider 140, which may be an online payment provider, may provide payment on behalf of user 120 to the operator of merchant server 110 via a network 210. In this regard, payment service provider 140 includes one or more payment applications 275 that may be configured to interact with client device 130 and/or merchant server 110 over network 210 to facilitate the purchase of items by user 120 from merchant server 110. In one embodiment, payment service provider 140 may be provided by PayPal, Inc.
Client device 130, merchant server 110, and payment service provider 140 may each include one or more processors, memories, and other appropriate components for executing instructions such as program code and/or data stored on one or more computer readable mediums to implement the various applications, data, and methods described herein. For example, such instructions may be stored in one or more computer readable mediums such as memories or data storage devices internal and/or external to various components of the system, and/or accessible over a network, which may be implemented as a single network or a combination of multiple networks. For example, in various embodiments, a network may include the Internet or one or more intranets, landline networks, wireless networks, and/or other appropriate types of networks.
According to an embodiment, payment service provider 140, for example in its role as a Trusted Service Manager (TSM), may work with a Mobile Network Operator (MNO) to put a certificate issued by the payment service provider in a Secure Element (SE) or Subscriber Identity Module (SIM) card 215 of a client device 130. This SE or SIM card may follow security guidelines such as FIPS 140-2 Level 2/3. Payment service provider issued certificates already installed in client device 130 may be done for personalization purposes. When customers or users activate their payment service provider application 225, such as a PayPal application, which is already built in the client device, the users or customers are asked to select a PIN, which may be optional or mandatory. The PIN protects the private key of the certificate.
When a transaction, for example a financial transaction using NFC service application 217 of an NFC enabled client device 130, is made via payment service provider 140 such as PayPal, payment service provider 140 gets signature information of, for example, a X509 certificate. This X509 signature information is typically maintained for each user. The signature information may be a digital signature and may include a time stamp, dollar amount, transaction type, item, and location, which may be determined from a GPS enabled client device 130. Signature information may also be preloaded in client device 130 in, for example, other applications 230, as EMV (Europay, MasterCard, Visa), or ECC, in addition to X509. Client device 130 may also be enabled for, for example, Bluetooth, infrared or other types of communications and/or transactions in addition to NFC.
Payment service provider 140 maintains a plurality of user accounts 280, each of which may include account information 285 associated with individual users. For example, in one embodiment, account information 285 may include private financial information of user 120 such as account numbers, passwords, credit/debit card information, bank information, or other financial information which may be used to facilitate online, NFC or other types of transactions by user 120. Also, payment application 275 may be configured to interact with merchant server 110 on behalf of user 120 during a transaction with a checkout application of the merchant server 110 without requiring user 120 to provide account information 285 to merchant server 110.
Payment service provider 140 may also provide a transaction record processing application 290 that may be configured to receive transaction information from client device 130 over network 210 and store the transaction information in a plurality of transaction records 295 which are associated with individual user accounts 280. As further described herein, transaction records 295 may be implemented to store transaction information associated with particular financial transactions, for example online, NFC or other types of transactions, between user 120 and merchant server 110 (i.e., user-merchant transactions). Although a user-merchant transaction is illustrated in this embodiment, other transactions are also applicable such as user-user, merchant-merchant and/or merchant-user transactions.
Access to transaction records 295 may be controlled by payment service provider 140 to prevent the storage or retrieval of transaction records 295 by other parties without the permission of user 120. In this regard, payment service provider 140 may require the receipt of a security identifier such as a valid password, a user identifier, a username, and/or other appropriate information before transaction records 295 may be stored, changed, and/or retrieved.
It will be appreciated that by performing a plurality of transactions by user 120 with merchant server 110 and/or other merchants or users, a plurality of transaction records 295 may be stored by payment service provider 140 and associated with an appropriate user account 280 associated with user 120.
In addition, as discussed above, payment service provider 140 may communicate or exchange data with subscribers such as acquirer 315, processor 120, brands 125 and/or Internet companies 150 (as illustrated in
The centralized storage of transaction information or data of payment service provider 140 may be combined and enhanced with data obtained from business partners of the payment service provider 140 including subscriber acquirers, brands, Internet companies, etc. In one embodiment where payment service provider 140 is Paypal, Inc., the centralized stored transaction data may be combined with data obtained from Paypal's business partners such as eBay™, thus resulting in even richer and more extensive data.
Payment service provider 140 has multiple “verified” statuses. Hence, the centralized data storage capabilities of payment service provider 140 facilitate both a rule-based system and behavioral engine that may generate proprietary fraud models based on such rich and extensive data. Payment service provider 140 is able to offer and provide a service that may work in real time to identify information and data associated with client device 130 to detect and prevent identity theft and transaction fraud and without compromising privacy.
Referring now to
In operation, it is assumed that user 120 has previously registered with payment service provider 140 to open a user account 280 (as illustrated in the embodiment of
As a result of such previous registration, client device 130 stores a specific user identifier 220 that may be used to identify the particular user 120 as having a user account 280 maintained by payment service provider 140. The user identifier 220 may be implemented, for example, as one or more cookies, operating system registry entries, hardware identifiers, or other types of identifiers.
Beginning with block 310, when a transaction takes place, for example, a financial transaction at a merchant 110 (POS) using a client device or a payment instrument including a credit card, transaction information such as the last 4 digits of the payment instrument may be sent to a remote location, for example, to payment service provider 140 such as PayPal (using PayPal's mobile application). User 120 may engage in a transaction with merchant server 110 to purchase various selected items. In this regard, user 120 may authorize an operator of payment service provider 140 to provide relevant financial information (e.g., account information 285 from one of user accounts 280 associated with user 120) for executing such transactions on behalf of user 120. In one embodiment, client device 130 may interact with merchant server 110 via, for example, an NFC service application 217. In another embodiment, payment service provider 140 may interact with merchant server 110 on behalf of client device 130 and user 120 over network 210. In one or more embodiments, user 120 may engage in a transaction with another user, or a merchant may engage in a transaction with another merchant.
In block 320, transaction information is received at a remote location, for example, at the payment service provider 140. Transaction information may include purchase amount, product purchased, time, date, place of transaction, etc.
In block 330, the transaction information is correlated with user data, which may include signature information and a user profile already created and centrally stored by, for example, payment service provider 140. Signature information is the way to identify the client device 130. The user profile may be created, for example, based on a user's typical behavior in financial transactions.
In block 340, a transaction score, potential fraud and/or risk data based on the correlation may be generated. According to an embodiment, payment service provider 140 may compare each transaction by a user with user data or centralized stored data maintained by payment service provider 140. If a particular transaction appears to be out of line with the user's typical transaction profile, a fraud alert may be raised. For example, if the user generally only deals with transactions over the telephone in small dollar amounts, a large dollar amount transaction may raise a fraud alert. Other data that may raise fraud alerts include the number of transactions, the time of day or the time of year when the transaction takes place. Finally, transactions made over client device 130 may also provide location information of the client device 130 (and correspondingly user 120) via, for example, GPS. For example, if the user profile indicates that a particular account is based in Northern California, but one or more transactions suddenly appear in Russia, a fraud alert may be issued.
In block 350, the generated transaction score or data may be collated and offered to subscribers, which may include financial institutions or acquirers 115, credit/debit card brands 125, as well as other financial institutions or Internet companies 150, as a fraud engine service while ensuring that privacy information is not leaked. In turn, subscribers obtaining the generated score or data may make a decision on the veracity or authenticity (or lack thereof) of the transaction based on the score or data generated by payment service provider 140. The payment service provider 140 itself is the only entity that may do the correlating or matching and may offer the service as a fraud engine.
Payment service provider 140 may provide a score or potential risk and/or fraud data associated with transactions performed. Such score or data may be provided in various formats such as HTML, XML, other text-based formats, one or more webpages, email messages, graphic files, multimedia files, or other data formats. For example, in one embodiment, payment service provider 140 may provide a webpage including a score or potential fraud and/or risk data which may be viewed through a browser application. In another embodiment, payment service provider 140 may provide an email message identifying such score or data details. In one embodiment, the score or data details provided may include program code, such as JavaScript™ code embedded in a webpage, which is executable by a subscriber.
In view of the present disclosure, it will be appreciated that various methods and systems have been described for receiving, sending, storing, and retrieving transaction records associated with transactions using, for example, NFC, Bluetooth, infrared and/or online applications. Transaction information or data generated by payment service provider 140 may be used to prevent identity theft or fraud transactions and may be used in real time.
Although various components and steps have been described herein as being associated with client device 130, merchant server 110, and payment service provider 140 of
As discussed above, a Trusted Service Manager (TSM) role may be provided by payment service provider 140.
Where applicable, various embodiments provided by the present disclosure may be implemented using hardware, software, or combinations of hardware and software. Also where applicable, the various hardware components and/or software components set forth herein can be combined into composite components comprising software, hardware, and/or both without departing from the spirit of the present disclosure. Where applicable, the various hardware components and/or software components set forth herein may be separated into sub-components comprising software, hardware, or both without departing from the spirit of the present disclosure. In addition, where applicable, it is contemplated that software components may be implemented as hardware components, and vice-versa.
Software in accordance with the present disclosure, such as program code and/or data, may be stored on one or more computer readable mediums. It is also contemplated that software identified herein may be implemented using one or more general purpose or specific purpose computers and/or computer systems, networked and/or otherwise. Where applicable, the ordering of various steps described herein may be changed, combined into composite steps, and/or separated into sub-steps to provide features described herein.
The foregoing disclosure is not intended to limit the present disclosure to the precise forms or particular fields of use disclosed. It is contemplated that various alternate embodiments and/or modifications to the present disclosure, whether explicitly described or implied herein, are possible in light of the disclosure.
Having thus described embodiments of the disclosure, persons of ordinary skill in the art will recognize that changes may be made in form and detail without departing from the scope of the disclosure. Thus the disclosure is limited only by the claims.
Claims
1. A method of evaluating transaction information in view of potential fraud and/or risk, the method comprising:
- receiving transaction information at a remote location;
- correlating the received transaction information with user data maintained at the remote location; and
- generating a score and/or risk or fraud data based on the correlating.
2. The method of claim 1, further comprising offering the score and/or risk or fraud data for detection and prevention of identity theft or fraud.
3. The method of claim 1, wherein the receiving transaction information further comprises receiving transaction information from a client device over a network.
4. The method of claim 1, wherein the user data further comprises signature information associated with a client device and a user profile.
5. The method of claim 4, further comprising generating fraud alerts based on the user profile, wherein the user profile further comprises number of transactions, or time of day or year associated with a user.
6. The method of claim 1, further comprising maintaining the user data in a centralized data storage of the remote location.
7. The method of claim 1, wherein the remote location further comprises a payment service provider.
8. The method of claim 7, further comprising enhancing the user data with data received from business partners of the payment service provider.
9. The method of claim 1, wherein the transaction information further comprises location information of a user.
10. The method of claim 1, wherein the transaction information is associated with a user-merchant transaction, a user-user transaction, a merchant-user transaction and/or a merchant-merchant transaction.
11. The method of claim 10, wherein the user-merchant transaction, the user-user transaction, the merchant-user transaction and/or the merchant-merchant transaction comprises an NFC application, a Bluetooth application, an infrared communications application and/or an online application.
12. The method of claim 1, wherein the generating the score and/or risk or fraud data is done in real time.
13. A machine-readable medium comprising a plurality of machine-readable instructions which when executed by one or more processors of a server are adapted to cause the server to perform the method of claim 1.
14. A client device comprising:
- one or more processors; and
- one or more memories adapted to store a plurality of machine-readable instructions which when executed by the one or more processors are adapted to cause the client device to: provide transaction information to a remote location, wherein the transaction information is associated with a user-merchant transaction, a user-user transaction, a merchant-user transaction and/or a merchant-merchant transaction; and provide a user identifier to the remote location wherein the remote location creates user data associated with the client device based on the user identifier so that the user data may be correlated with the transaction information thus allowing generation of potential fraud and/or risk data.
15. The client device of claim 14, wherein the machine-readable instructions when executed by the one or more processors are adapted to provide location information of the client device.
16. The client device of claim 14, wherein the machine-readable instructions when executed by the one or more processors are adapted to cause the client device to pass the user identifier with the transaction information to the remote location to permit the transaction information to be stored at the remote location.
17. The client device of claim 14, wherein the remote location comprises a server of a payment service provider.
18. The client device of claim 14 further comprising a wireless telephone, a personal computer, a Personal Digital Assistant (PDA) or a keyfob.
19. The client device of claim 14, wherein the client device is enabled for NFC, Bluetooth, online, and/or infrared communications applications.
20. A method of providing a fraud engine service, the method comprising:
- maintaining a plurality of transaction records, the transaction records comprising transaction information associated with a plurality of transactions by a user;
- receiving new transaction information wherein the new transaction information is associated with a new transaction by the user;
- correlating the new transaction information with the maintained plurality of transaction records; and
- generating a score or potential fraud data based on the correlation.
21. The method of claim 20 further comprising offering the generated score or potential fraud data to subscribers in view of identifying and preventing fraud.
22. The method of claim 20, further comprising:
- receiving a user identifier from a client device; and
- maintaining a centralized storage of user data based on the user identifier and the plurality of transaction records.
23. The method of claim 22, further comprising enriching the user data by obtaining transaction information associated with the user from subscribers.
24. The method of claim 20, wherein the plurality of transactions by the user further comprises user-merchant, user-user, merchant-merchant and/or merchant-user transactions.
25. A machine-readable medium comprising a plurality of machine-readable instructions which when executed by one or more processors of a server are adapted to cause the server to perform the method of claim 20.
26. A fraud engine system comprising:
- a plurality of transaction records associated with users, the transaction records comprising transaction information associated with a plurality of user transactions;
- one or more processors; and
- one or more memories adapted to store a plurality of machine-readable instructions which when executed by the one or more processors are adapted to cause the fraud engine system to: maintain the plurality of transaction records associated with the users; receive new transaction information from a client device, wherein the new transaction information is associated with a new user transaction; correlate the new transaction information with the maintained plurality of transaction records; generate a score or potential fraud data based on the correlation; and offer the generated score or potential fraud data to subscribers in view of identifying and preventing fraud.
27. The fraud engine system of claim 26, wherein the machine-readable instructions when executed by the one or more processors are adapted to cause the fraud engine system to:
- receive a user identifier from the client device; and
- maintain a centralized storage of user data based on the user identifier and the plurality of transaction records.
28. The fraud engine system of claim 27, further comprising enriching the user data with transaction data obtained from subscribers.
29. The fraud engine system of claim 26 further comprising a payment service provider service.
30. The fraud engine system of claim 26, wherein the client device comprises a wireless telephone, a personal computer, a Personal Digital Assistant (PDA) or a keyfob.
31. The fraud engine system of claim 26, wherein the client device is enabled for NFC, Bluetooth, online, and/or infrared communications applications.
32. The fraud engine system of claim 26, wherein the plurality of transaction records associated with the users further comprises user-merchant, user-user, merchant-merchant and/or merchant-user transactions.
33. The method of claim 26, wherein the score or potential fraud data is generated in real time.
Type: Application
Filed: Dec 11, 2008
Publication Date: Dec 10, 2009
Applicant: eBay Inc. (San Jose, CA)
Inventor: Upendra Mardikar (San Jose, CA)
Application Number: 12/332,775
International Classification: G06F 21/00 (20060101); H04M 11/00 (20060101); H04W 4/12 (20090101);
