Method and system for providing alert messages related to suspicious transactions

Systems and methods are provided for providing alerts to a user. The systems and methods may include a financial service provider including a memory device storing instructions. The financial service provider may also include at least one processor configured to execute the instructions to perform a plurality of operations. The operations may include receiving data relating to an activity of a user. The operations may also include identifying a merchant based at least on the received data. The operations may also include accessing historical fraud or disputes data associated with at least one of the user and the merchant. The operations may also include determining whether the received data triggers an alert. The operations may further include sending an alert message to a user device associated with the user when the processor determines that the received data triggers the alert.

TECHNICAL FIELD

The disclosed embodiments generally relate to systems and methods for providing alert messages to users, and more particularly, to systems and methods for providing alert messages related to suspicious transactions to users of financial service products and services.

BACKGROUND

Fraudulent transactions and transaction disputes continue to increase in the financial sector, raising ever-growing concerns for financial service providers, consumers, and merchants. In particular, with the wide spread of e-commerce, user identities and financial information are becoming more and more vulnerable to theft, bad faith merchant practices, or other unauthorized use. When a user of a bank card or account notices an unauthorized transaction, or when the user otherwise disputes a transaction made using the bank card or account, the user may report it to the financial institution, which may investigate the transaction and attempt to resolve the dispute between the merchant and the user. Monitoring every transaction, however, can impose a serious burden on the user, particularly when the user has multiple bank cards or accounts. In addition, users that observe a suspicious transaction associated with a product or service purchased from a merchant may not have the time and energy to dispute the transaction, which may not only cause monetary loss to the users, but also encourage continued abusive practices.

Financial institutions that issue or manage bank cards or accounts often have anti-fraud systems for monitoring fraudulent transactions. When a fraudulent transaction is detected, the anti-fraud systems may notify the user. Such anti-fraud systems, however, lack the capability to provide precautionary notifications to users about suspicious transactions that may not be fraudulent but have an increased likelihood of being subject to future disputes. In addition, existing anti-fraud systems typically rely primarily on crowd-sourced feedback, which may not provide an accurate detection of suspicious transactions. Accordingly, there is a need for methods and systems for assisting users in identifying suspicious transactions.

SUMMARY

Disclosed embodiments provide methods and systems for providing alerts to a user, particularly alert messages related to suspicious transactions associated with financial service products and services. Aspects of the disclosed methods and systems may reduce burdens on the individual associated with monitoring such transactions, and may provide a convenient, efficient, and easy-to-use solution for identifying potentially risky or suspicious transactions. For example, the disclosed methods and systems may notify a user that a merchant may have a low rating or poor review before the user completes a transaction with the merchant. This may assist the user in making an informed decision about whether the transaction should be cancelled to avoid potential trouble and future disputes.

Consistent with a disclosed embodiment, a system for providing alerts to a user is provided. The system may include a memory device storing instructions. The system may also include at least one processor configured to execute the instructions to perform a plurality of operations. The operations may include receiving data relating to a transaction activity of the user and identifying a merchant based at least on the received data. The operations may also include accessing historical fraud or disputes data associated with at least one of the user and the merchant. The operations may also include determining whether the received data triggers an alert. The operations may further include sending an alert message to a user device associated with the user when the processor determines that the received data triggers the alert.

Consistent with another disclosed embodiment, a computer-implemented method for providing alerts to a user is provided. The method may include receiving data relating to a transaction activity of the user and identifying a merchant based at least on the received data. The method may also include accessing, via at least one processor, historical fraud or disputes data associated with at least one of the user and the merchant. The method may also include determining whether the received data triggers an alert. The method may further include sending an alert message to a user device associated with the user when the at least one processor determines that the received data triggers the alert.

Consistent with other disclosed embodiments, tangible, non-transitory computer-readable storage media may store program instructions that are executable by one or more processors to implement any of the processes disclosed herein. In one embodiment, a non-transitory computer-readable medium is provided. The non-transitory computer-readable medium may be encoded with instructions that, when executed by at least one processor, cause the at least one processor to perform a plurality of operations. The operations may include receiving data relating to a transaction activity of a user and identifying a merchant based at least on the received data. The operations may also include accessing historical fraud or disputes data associated with at least one of the user and the merchant. The operations may also include determining whether the received data triggers an alert and sending an alert message to a user device associated with the user when the processor determines that the received data triggers the alert.

DESCRIPTION

Reference will now be made in detail to exemplary embodiments, examples of which are illustrated in the accompanying drawings and disclosed herein. Wherever convenient, the same reference numbers will be used throughout the drawings to refer to the same or like parts.

The disclosed embodiments are directed to systems and methods for providing alerts to customers (or users) of financial service providers. A computer-executed software application (“app”), such as an FSP app, may be provided by a financial service provider (“FSP”). The FSP app may identify that a user has made or will make a transaction at a merchant, and may provide an alert message to the user regarding the transaction and/or the merchant. The alert message may take any suitable form, such as, for example, an electronic message, text message, multimedia message, online post, in-app alert, etc. The FSP may be a bank, a credit card company, an investment company, or other entity which handles financial transactions for individuals and/or merchants. Financial transactions may include, for example, payment of a user purchase of products or services from a merchant using a credit card, debit card, bank account, loyalty card, etc. The FSP app may be a standalone software application executed by FSP server processor(s). Additionally or alternatively, the FSP app may be a standalone software application for a personal computing device, such as personal computer software or a mobile device app. The FSP app may be part of another software application provided by the FSP for managing finances related to banking, credit accounts, debit accounts, etc.

The FSP may identify suspicious transactions. Suspicious transactions may include fraudulent transactions or transactions that are not necessarily fraudulent but are likely to be subject to future disputes. The FSP may identify suspicious transactions before, during, or after the FSP customers conduct such transactions. For example, after the FSP identifies a suspicious transaction, the FSP app may send an alert message to the user to caution the user that the transaction may be fraudulent, or that the merchant has poor ratings or reviews, which may mean that the products and/or services purchased from the merchant may have an increased likelihood of being subject to future disputes, as compared to merchants with strong ratings or reviews. Based on a user response received from the user, the FSP may provide, e.g., through the FSP app, further information to the user regarding the merchant, such as ratings and reviews of the merchant, to assist the user to make a decision as to whether the transaction should be avoided or canceled to avoid future trouble or disputes. Thus, disclosed methods and systems may ultimately reduce the likelihood of fraud, dispute, and abuse.

FIG. 1shows a diagram of an exemplary system that may be configured to provide alerts to users, consistent with disclosed embodiments. The components and arrangements shown inFIG. 1are not intended to limit the disclosed embodiments, as the components used to implement the disclosed processes and features may vary.

In accordance with disclosed embodiments, an alert system100may include an FSP110. FSP110may be a bank, a credit card company, a lender, or other type of financial service entity that generates, provides, manages, and/or maintains financial service accounts for one or more users, such as credit cards, debit cards, etc. FSP110may operate at least one server111. Server111may be a computer-based system including computer system components, desktop computers, workstations, tablets, hand held computing devices, memory devices, and/or internal network(s) connecting the components. Server111is discussed in additional detail with respect toFIG. 2, below.

User120may operate a user device120A, which may be a desktop computer, laptop, tablet, smartphone, multifunctional watch, pair of multifunctional glasses, tracking device, or any suitable device with computing capability. User device120A may have the FSP app installed thereon, which may enable user device120A to communicate with FSP110, such as server111through a network130. User device120A is discussed in additional detail with respect toFIG. 3, below.

Network130may comprise any type of computer networking arrangement used to exchange data. For example, network130may be the Internet, a private data network, a virtual private network using a public network, a WiFi network, a LAN or WAN network, and/or other suitable connections that may enable information exchange among various components of alert system100. Network130may also include a public switched telephone network (“PSTN”) and/or a wireless cellular network. Network130may be a secured network or unsecured network.

Merchant140may be a company that sells products and/or services, such as a grocery store, an online retailer, or an auto repair shop, etc. Merchant140may include at least one server141. Server141may be any suitable server known in the art, which may include at least one processor, a storage device, such as a hard drive or a memory, and an input/output interface, such as a network communication interface, which are not shown inFIG. 1. In some aspects, server141may include the same or similar configuration and/or components of server111. Server141may include a computer-based system, which may include hardware and/or software installed therein for performing methods and processes disclosed herein. Server141may also enable merchant140to sell products and/or services through network130to user120. For example, user120may use user device120A to browse a webpage of merchant140that runs on server141, and may make a purchase of products or services offered by merchant140through the webpage. Server141may communicate with server111of FSP110. For example, user120may use a bank card managed by FSP110to purchase products or services from merchant140, and merchant140may report such a transaction to server111in order to, for example, verify authentication information about the bank card used by user120.

Alert system100may also include a third party server150. Third party server150may communicate with at least one of FSP110, merchant140, and user device120A via network130. Third party server150may be associated with a third party. The third party may be, for example, a bank other than FSP110, a credit reporting agency, a social network company, a rating company, a survey company, or any other suitable data reporting source. Third party server150may provide information or data to at least one of FSP110, merchant140, or user device120A. For example, in some embodiments, third party server150may send ratings and reviews data about merchant140to FSP110and/or user device120A. In some embodiments, third party server150may send data relating to a credit rating of user120to FSP110. In some embodiments, third party server150may provide location information about user120to FSP110.

Other components known to one of ordinary skill in the art may be included in alert system100to process, transmit, provide, and receive information consistent with the disclosed embodiments. In addition, although not shown inFIG. 1, components of system100may communicate with each other through direct communications, rather than through network130. Direct communications may use any suitable technologies, including, for example, Bluetooth™, Bluetooth LE™, WiFi, near field communications (NFC), or other suitable communication methods that provide a medium for transmitting data between separate devices.

FIG. 2shows a diagram of an exemplary financial service provider (“FSP”)110, consistent with disclosed embodiments. As shown, FSP110may include at least one server111. Although discussed here in relation to FSP110, it should be understood that variations of server111may be used by other components of alert system100, including server141of merchant140, user device120A, and third party server150. Server111may be a single server or may be configured as a distributed computer system including multiple servers or computers that interoperate to perform one or more of the processes and functionalities associated with the disclosed embodiments.

Server111may include one or more processors220, an input/output (“I/O”) device230, and a memory240. Processor220may be one or more known processing devices, such as a microprocessor from the Pentium™ family manufactured by Intel™ or the Turion™ family manufactured by AMD™. Processor220may constitute a single core or multiple core processor that executes parallel processes simultaneously. For example, processor220may be a single core processor configured with virtual processing technologies. In certain embodiments, processor220may use logical processors to simultaneously execute and control multiple processes. Processor220may implement virtual machine technologies, or other known technologies to provide the ability to execute, control, run, manipulate, store, etc. multiple software processes, applications, programs, etc. In another embodiment, processor220may include a multiple-core processor arrangement (e.g., dual, quad core, etc.) configured to provide parallel processing functionalities to allow server111to execute multiple processes simultaneously. One of ordinary skill in the art would understand that other types of processor arrangements could be implemented that provide for the capabilities disclosed herein.

FSP110may include one or more storage units configured to store information used by processor220(or other components) to perform certain functions related to the disclosed embodiments. In one embodiment, server111may include memory240. Memory240may store one or more operating systems that perform known operating system functions when executed by processor220. By way of example, the operating systems may include Microsoft Windows™, Unix™, Linux™, Android™, Apple™ Computers type operating systems, or other types of operating systems. Accordingly, embodiments of the disclosed invention may operate and function with computer systems running any type of operating system. Memory240may store instructions to enable processor220to execute one or more applications, such as server applications, an alert application, network communication processes, and any other type of application or software. Alternatively, the instructions, application programs, etc., may be stored in an external storage (not shown) in communication with server111via network130or any other suitable network. Memory240may be a volatile or non-volatile, magnetic, semiconductor, tape, optical, removable, non-removable, or other type of storage device or tangible (i.e., non-transitory) computer-readable medium.

In one embodiment, memory240may be encoded with one or more programs250. Programs250stored in memory240, and executed by processor220, may include an FSP app252. FSP app252may cause processor220to execute one or more processes related to financial services provided to customers including, but not limited to, processing credit and debit card transactions, checking transactions, fund deposits and withdrawals, transferring money between financial accounts, lending loans, processing payments for credit card and loan accounts, identifying potentially suspicious transactions which may be fraudulent or likely to be subject to disputes, sending alerts to user120regarding such transactions, providing ratings and reviews of merchants to user120, and/or processing transaction disputes. In some embodiments, programs250may be stored in an external storage device, such as a cloud server located outside of server111, and processor220may execute programs250remotely.

Server111may further include a storage device260, which may be a volatile or non-volatile, magnetic, semiconductor, tape, optical, removable, non-removable, or other type of storage device or tangible (i.e., non-transitory) computer-readable medium. For example, storage device260may include at least one of a hard drive, a flash drive, a memory, a Compact Disc (CD), a Digital Video Disc (DVD), or a Blu-ray™ disc. Storage device260may store data that may be used by processor220for performing various methods and processes disclosed herein. Data stored at storage device260may include historical fraud or disputes data, transaction data, credit rating of user120and/or merchant140, ratings and reviews of merchant140. Historical fraud or disputes data may include past fraud or disputes involving transactions related to merchant140and/or user120, resolutions of the fraud or disputes, patterns of fraud or disputes associated with merchant140and/or user120, correlations between merchant140, types of products and/or services, and user120involved in such fraud or disputes. Although not shown inFIG. 2, storage device260may store programs250.

Server111may include at least one database270. Database270may store data that may be used by processor220for performing methods and processes associated with disclosed embodiments. Data stored in database270may include any suitable data, such as information relating to user120and/or merchant140, information relating to transactions, and information relating to ratings and reviews of merchant140. Database270may store data that are similar to those stored in storage device260. Although shown as a separate unit inFIG. 2, it is understood that database270may be part of memory240, storage device260, or an external storage device located outside of server111.

At least one of memory240, storage device260, and/or database270may store data and instructions used to perform one or more features of the disclosed embodiments. At least one of memory240, storage device260, and/or database270may also include any combination of one or more databases controlled by memory controller devices (e.g., server(s), etc.) or software, such as document management systems, Microsoft SQL databases, SharePoint databases, Oracle™ databases, Sybase™ databases, or other relational databases. Server111may also be communicatively connected to one or more remote memory devices (e.g., databases (not shown)) through network130or a different network. The remote memory devices may be configured to store information and may be accessed and/or managed by server111. Systems and methods consistent with the disclosed embodiments, however, are not limited to separate databases or even to the use of a database.

Server111may also include at least one I/O device230that may comprise one or more interfaces for receiving signals or input from devices and providing signals or output to one or more devices that allow data to be received and/or transmitted by server111. For example, server111may include interface components, which may provide interfaces to one or more input devices, such as one or more keyboards, mouse devices, and the like, which may enable server111to receive input from an operator of FSP110(not shown).

FIG. 3shows an exemplary configuration of user device120A, consistent with disclosed embodiments. User device120A may allow one or more FSP110customers, such as user120, to receive alerts regarding transactions and/or merchant140. User device120A may be a personal computing device. For example, user device120A may be a general purpose or notebook computer, a mobile device with computing ability, a tablet, a smartphone, or any combination of these computers and/or affiliated components. In one embodiment, user device120A may be a computer system or mobile computer device that is operated by user120who is an FSP110customer.

User device120A may be configured with storage that stores one or more operating systems that perform known operating system functions when executed by one or more processors. By way of example, the operating systems may include Microsoft Windows™, Unix™, Linux™, Android™, Apple™ Computers type operating systems, or other types of operating systems. Accordingly, embodiments of the disclosed invention may operate and function with computer systems running any type of operating system. User device120A may also include communication software that, when executed by a processor, provides communications with network130, such as Web browser software, tablet or smart hand held device networking software, etc.

User device120A may include a display310displaying information. Display310may include, for example, liquid crystal displays (LCD), light emitting diode screens (LED), organic light emitting diode screens (OLED), a touch screen, and other known display devices. Display310may display various information to user120. For example, display310may display an alert message to user120about a transaction associated with a merchant. Display310may display touchable or selectable options for user120to select, and may receive user selection of options through a touch screen or I/O devices320.

I/O devices320may include one or more devices that allow user device120A to send and receive information from user120or another device. I/O devices320may include various input/output devices, such as a keyboard, a mouse-type device, a gesture sensor, an action sensor, a physical button, a camera, oratory input, etc. I/O devices320may also include one or more communication modules (not shown) for sending and receiving information from other components in alert system100by, for example, establishing wired or wireless connectivity between user device120A and network130, by establishing direct wired or wireless connections between user device120A and server111, or between user device120A and merchant server141. In some embodiments, user device120A may also include a Global Positioning System (GPS) unit324. GPS324may enable FSP110to receive location data of user device120A for determining the location of user120.

Other technologies may also be used for locating user120. For example, user device120A may use beacon technology. When user120walks into a store of merchant140, user device120A may communicate with a beacon device provided at merchant140. The beacon device may send information received from user device120A to server111, thereby allowing server111to determine that user120is located at merchant140. For another example, user device120A may scan a bar code at merchant140, and may provide the bar code information to server111. Server111may determine the location of merchant140based on the bar code information, thereby determining the location of user device120A, hence user120. In some embodiments, user device120A (and/or another component of system100) may determine user120's location based on a user “checking in” via a social networking site (i.e., Facebook™, Foursquare™, etc.).

User device120A may include at least one processor330, which may be one or more known computing processors, such as those described with respect to processor220inFIG. 2. Processor330may execute various instructions stored in user device120A to perform various functions, for example, processing an alert message received from server111regarding a suspicious transaction and displaying the alert message on display310.

User device120A may include a memory340, which may be a volatile or non-volatile, magnetic, semiconductor, tape, optical, removable, non-removable, or other type of storage device or tangible (i.e., non-transitory) computer-readable medium. Memory340may store one or more programs350. Programs350may include operating systems (not shown) that perform known operating system functions when executed by one or more processors. Disclosed embodiments may operate and function with computer systems running any type of operating system. User device120A may be a device that executes mobile applications for performing operations consistent with disclosed embodiments, such as a tablet or mobile device.

Programs350may also include an FSP app352. Similar to FSP app252executed by server111, FSP app352may be executed by processor330to perform processes related to financial services including, but not limited to, receiving data from server111regarding suspicious transactions, receiving data from server111regarding ratings and reviews of merchant140, receiving alert messages from server111and displaying the alert messages on display310, providing location data to server111, receiving input from user120in response to the alert messages, and sending user input data to server111.

FIG. 4shows a flowchart of an exemplary method400for providing alerts to user120. For discussion purposes, the exemplary methods are described as performed by server111. In some embodiments, however, user device120A and/or server141of merchant140may perform one or more disclosed method steps. In some embodiments, different components of alert system100(such as server111, server141, and user device processor330) may perform various steps of the methods in a distributed-computing configuration.

In step410, server111may receive data relating to an activity of user120. The data relating to the activity of user120may include, for example, GPS data received from GPS324indicating that user120is near or at merchant140, such as a grocery store, an auto repair shop, an electronic devices retailer, etc. The data relating to the activity of user120may also include, for example, data indicating that user120is about to make or has made a purchase of products and/or services at merchant140. In some aspects, data indicating that user120is about to make or has made a purchase may include data indicating the user has swiped a bank card on a point of sale terminal at merchant140. The data relating to the activity of user120may further include, for example, location data received from a third party indicating that user120has logged into a third party application or has “checked in” using the third party application while user120is at or near merchant140. In some embodiments, when user120logs into the third party application or remains logged in, the third party application may obtain location information about user120and send location information to user device120A and/or server111. The third party application may include, for example, an online chat application, a social network application, a tracking application, etc.

The data relating to an activity of user120may also include data indicating suspicious transactions. The data may include, for example, the type of transaction, the frequency (repetition) of the transaction, the deviation of the amount of transaction from a normal or average transaction, the location of the transaction, etc. For example, server111may detect that a purchase for gasoline was made with a credit card belonging to a user who is known not to own a vehicle, and/or did not recently rent a vehicle. Server111may determine that this type of transaction is out of the scope of a user's120normal purchases, and that server111should trigger an alert. In another example, server111may detect that three transactions for TVs were made within one week involving different merchants, and this frequency may indicate the transaction is suspicious. In another example, server111may detect that a payment of $100 is made to a utility company using a credit card or a checking account of user120. Server111may analyze historical payments made to the utility company, and may detect that the $100 payment is $50 more than a typical payment. Server111may determine that this deviation should trigger an alert to user120asking user120to check the bill. For another example, server111may detect that a charge was made at a merchant located over 250 miles from where user120typically make purchases, and may determine that this activity should trigger an alert to ask user120to confirm whether this charge is legitimate or ask user120to call the financial institute if something is suspicious. Server111may assign a transactional score to each transaction. The transactional score may be based on any one or a combination of the factors discussed above. If the transactional score is higher than a predetermined threshold, the transaction may be legitimate, and an alert may not be triggered. If the transactional score is lower than the predetermined threshold, the transaction may be invalid, and an alert may be triggered.

The data relating to an activity of user120may also include other data indicating, for example, large bill variance (e.g., variance of bill payment larger than a predetermined threshold), and small bill variance (e.g., variance of bill payment smaller than a predetermined threshold). The data may also include data indicating performance related to a budget for a certain category. For example, user120may have allocated a certain budget for particular spending categories, and the data may include information indicating that spending has or has not, or may soon exceed the budget for certain categories, the amount of excessive spending, etc.

In step420, server111may determine whether the received data relating to an activity of user120triggers an alert. If the received data does not trigger an alert (No, step420), server111may continue to receive data relating to activity of user120. If the received data triggers an alert (Yes, step420), server111may continue to execute step430. Server111may perform various processes to determine whether the received data relating to user activity triggers an alert. For example, server111may identify a merchant based at least on the received data. Server111may access and analyze historical fraud or disputes data, crowd-sourced feedback, etc., which may be associated with at least one of the user and the merchant. Server111may determine whether the activity involves or will likely involve a suspicious transaction that may be fraudulent, likely fraudulent, or likely to be subject to disputes, thereby determining whether the received data triggers an alert. According to some embodiments, the historical fraud or disputes data may comprise proprietary data collected by FSP110associated with FSP110customer purchase transactions, identified or suspected fraud (perpetrated by unauthorized users of the financial product or service, customers of FSP110, merchant(s)140, etc.), disputed transactions (for example, indicating the number and nature of disputed transactions associated with user120and/or merchant(s)140), etc.

When server111determines that the received data relating to the activity of user120indicates a suspicious transaction, server111may determine that an alert should be triggered. In step430, server111may send an alert message to user120, e.g., to user device120A of user120. The alert message may be displayed on display310of user device120A. The alert message may include options that may be selected by user120to indicate whether user120desires to receive additional information regarding the transaction and/or merchant. The additional information may include, for example, ratings and reviews of merchant140. Additional examples of alert messages will be described below with respect toFIGS. 8-10B. In step440, server111may receive a user response to the alert message, including a user selection of any options presented in the alert message. In step450, server111may determine, based on the received user response, whether user120desires to receive additional information. If server111determines that user120does not wish to receive additional information (No, step450), server111may end method400. If server111determines that user120wishes to receive additional information (Yes, step450), server111may provide user120with additional information in step460.

FIG. 5shows a flowchart of an exemplary method500for providing alerts to user120. Method500may be executed by, for example, server111to provide a pre-purchase alert to user120. In step510, server111may receive data relating to a pre-purchase activity of user120. For example, server111may receive positioning data from GPS324, via user device120A, indicating the location of user120. In another embodiment, server111may receive positioning data from third party server150and determine the location of user120. For example, third party server150may receive user log in or check in information from user device120A through a third party app installed on user device120A, through a website visited by user120from user device120A, etc. The third party app may include a function of acquiring user location through, for example, GPS324, the user inputting a geographic location, etc. Examples of such third party app include a chat app, tracking app, search engine app, and a social network app, such as FourSquare™.

The pre-purchase activity may also include user120swiping a bank card to initiate a purchase, adding items to a virtual shopping cart of an online merchant, etc. In some embodiments, server111may receive, from merchant140, data relating to the swipe of the bank card at a point of sale terminal. For example, merchant140may request authorization to complete a purchase transaction using an account of user120held by FSP110. Server111may determine that user120is located at merchant140and is about to make a purchase there.

In step520, server111may determine whether the pre-purchase activity triggers an alert. Continuing the above example, after determining the location of user120, server111may analyze data relating to merchant140. It is to be understood, however, that server111need not necessarily determine the location of user120to analyze data relating to merchant140or to send pre-purchase alerts. In some embodiments, for example, server111may receive a request from merchant140to authorize a purchase transaction but not know the location of merchant140or user120.

In some embodiments, server111may analyze historical fraud or disputes data related to merchant140. The historical fraud or disputes data related to merchant140may include, for example, how many fraudulent transactions or disputes have involved merchant140in a past predetermined period of time (e.g., years, months, or days). Server111may also analyze crowd-sourced feedback. Crowd-sourced feedback may include ratings and reviews regarding merchant140collected from the general public, rather than only from users of FSP110. In one embodiment, server111may primarily rely on historical fraud or dispute data, rather than crowd-sourced feedback, because historical fraud or dispute data from FSP110may provide a more accurate analysis result.

In addition, server111may determine which products sold by merchant140are more likely to be subject to disputes. Server111may determine a pattern of disputes associated with merchant140based on, for example, the historical fraud or dispute data of FSP110. Server111may also analyze ratings and reviews of merchant140based on, for example, crowd-sourced feedback. Server111may assign a reputation score to merchant140based on a result of at least one of the above analyses. Server111may compare the reputation score of merchant140to a predetermined threshold score and determine whether merchant140has a high reputation score or a low reputation score, as compared to the predetermined threshold, for example. According to some embodiments, the threshold score may be set or based on information provided by FSP110, user120, and/or a third party. Server111may determine that an alert should be triggered, for example, when the comparison indicates that merchant140has a low reputation score.

When server111determines that the pre-purchase activity does not trigger an alert (No, step520), method500repeats step510. When server111determines that the pre-purchase activity triggers an alert (Yes, step520), server111may send, in step530, a pre-purchase alert message to user120(via, e.g. user device120A). The pre-purchase alert message may be displayed on display310of user device120A.

FIG. 6shows an exemplary pre-purchase alert message610that may be displayed on display310, as part of step530. The pre-purchase alert message610may notify user120that user120appears to be located at (and/or initiating a purchase at) the merchant, e.g. Pete's Auto Shop, which has an elevated number of disputes. The pre-purchase alert message610may ask user120whether user120would like to receive additional information, such as ratings and reviews, about this merchant. The pre-purchase alert message610may provide options, e.g., a Yes button620and a No button630, for user120to select to indicate whether user120wishes to receive additional information about this merchant. User120may select the Yes button620to indicate user's desire to receive additional information, or the No button630to indicate user's desire not to receive additional information.

Referring back toFIG. 5, in step540, server111may receive a user response to the pre-purchase alert message, which may include a user selection of the Yes button620or the No button630. In step550, server111may determine whether user120would like to receive additional information, such as the ratings and reviews of merchant140, based on the user response received from user120. If server111determines that user120does not wish to receive additional information (No, step550), server111may end method500. If server111determines that user120wishes to receive additional information (Yes, step550), server111may provide user120with additional information in step560. For example, server111may send ratings and/or reviews information about merchant140to user device120A, which may be displayed on display310. An example of providing ratings and/or reviews information is discussed below in connection withFIG. 10. After reviewing the ratings and/or reviews about merchant140, user120may determine whether or not to make or cancel the transaction.

FIG. 7shows a flowchart of an exemplary method700for providing alerts to user120. Method700may be executed by, for example, server111to provide a post-purchase alert to user120. In step710, server111may receive data relating to a purchase made by user120. For example, server111may receive an electronic signature of user120or other indication that a transaction has been finalized and approved by user120at merchant140for products or services. In step720, server111may determine whether the data relating to the purchase should trigger an alert. Similar to the above discussion in connection with step520inFIG. 5, server111may analyze historical fraud or disputes data related to merchant140, the crowd-sourced feedback, the ratings and/or reviews of merchant140, the pattern of disputes, and/or the type of products and/or services to determine whether the transaction may be a suspicious transaction. For example, if merchant140has an elevated number of disputes in the past three months involving the same or similar type of products or services, server111may determine that the transaction user120has made could be a suspicious transaction that may either be fraudulent or more likely to be subject to a dispute. Similar to the above discussion with respect to a pre-purchase alert, server111may assign a reputation score to merchant140based on at least one of the above analyses, and may compare the reputation score to a predetermined threshold score to determine whether merchant140has a high or low reputation score, as compared to the predetermined threshold, for example. If server111determines that merchant140has a high reputation score, an alert may not be triggered. If server111determines that merchant140has a low reputation score, an alert may be triggered.

If server111determines that an alert should not be triggered (No, step720), server111may repeat step710. If server111determines that an alert should be triggered (Yes, step720), server111may send a post-purchase alert message to user120, for example, through user device120A. The post-purchase alert message may be displayed on display310.

An exemplary post-purchase alert message810is shown inFIG. 8. Post-purchase alert message810may identify the transaction that user120has made at Pete's Auto Shop for $103.17, for example, and that Pete's Auto Shop is associated with an elevated number of disputes. Post-purchase alert message810may ask user120whether user120would like to receive additional information, such as ratings and reviews, about this merchant. Post-purchase alert message810may provide options, e.g., a Yes button820and a No button830, for user120to select to indicate whether user120wishes to receive additional information about this merchant. User120may select the Yes button820to indicate user's desire to receive additional information, or may select the No button830to indicate user's desire not to receive additional information. If user120takes no action (i.e., does not select the Yes button820or the No button830) within a predetermined period of time (e.g., one hour, one day, etc.) server111may send a reminder message to user device120A for user120to check on the transaction. The reminder message may be similar to post-purchase alert message810.

Referring back toFIG. 7, in step740, server111may receive a user response to the post-purchase alert message, which may include user selection of the Yes button820or the No button830. In step750, server111may determine whether user120wishes to receive additional information about merchant140based on the user response. For example, if user120has selected the No button830, server111may determine that user120does not wish to receive additional information about merchant140(No, step750), and server111may end method700. If user has selected the Yes button820, server111may determine that user120wishes to receive additional information about merchant140(Yes, step750), and server111may continue to execute step760to provide the additional information to user120. For example, server111may send ratings and/or reviews information about merchant140to user device120A, which may be displayed on display310to user120. User120may review the ratings and/or reviews information about this merchant, and may determine whether the transaction should be cancelled to avoid a potential dispute with merchant140in the future. For example, if merchant140has a low rating or poor review, user120may determine that he/she should return or cancel the purchase to avoid any future dispute. According to some embodiments, server111may receive an indication from user120(via, e.g., user device120A) that the transaction should be cancelled, and server111may initiate cancellation of the transaction based on the received indication.

FIG. 9shows another exemplary post-purchase alert message910displayed on display310of user device120A. In this embodiment, the post-purchase alert message910may notify user120that the transaction may be tied to a subscription. In some embodiments, server111may analyze the type of transaction to determine whether the transaction is associated with a subscription or a recurring fee (weekly, monthly, annually, etc.). For example, if user120has made a purchase of a monthly magazine or a journal, or paid an annual membership fee for a club, server111may determine that an annual subscription fee or membership fee is likely due in the next twelve months. The post-purchase alert message910may ask user120whether user120would like to be reminded of the subscription or annual fee due before the next recurring fee is expected. Although twelve months is used as an example, other periods, such as three months or six months, may be determined by server111as a suitable period for reminding user120, based on, for example, historical purchase data associated with user120. The post-purchase alert message910may provide options, e.g., a Yes button920and a No button930, for user120to select to indicate whether user120would like to receive a reminder. If user120selects the Yes button920, server111may set up a reminder that will be sent to user device120A in 12 months about the subscription fee due or the annual fee due. If user120selects the No button930, server111may not set up a reminder.

The pre-purchase alert message610and the post-purchase alert messages810and910are for illustrative purpose only. Many other alert messages may be used in alert system100. For example, pre-purchase alert messages may include information that notifies user120of offers, promotions, benefits, or discounts provided by various bank cards. User120may review the offers, promotions, benefits, or discounts associated with the bank cards on display310, and may determine which bank card should be used for payment of the transaction. For example, in some embodiments, pre-purchase alert messages may notify user120that a Bank A credit card offers $10 off $50 at merchant140. User120may determine to use Bank A credit card to take advantage of this offer. For another example, pre-purchase alert messages may notify user120that Bank B credit card provides an extended warranty on the type of product user120is about to purchase, if user120uses Bank B credit card to make the purchase. User120may wish to take advantage of the extended warranty by using the Bank B credit card to pay the transaction,

In some embodiments, pre-purchase alert messages may also provide information to user120about offers, promotions, or discounts provided by merchant140, such that user120may take advantage of the offers, promotions, or discounts by meeting certain requirements. For example, when server111determines that user120has swiped a credit card to purchase a TV, server111may retrieve information about offers, promotions, or discounts currently provided by merchant140from server141, analyze such information, and determine that merchant140currently offers a 10% discount for a bundle purchase of a TV and a DVD player. Server111may provide a pre-purchase alert message to user120to notify user120that if user120also purchases a DVD player, user120may receive a 10% discount on the total purchase of a TV and a DVD player. User120may determine to take advantage of this discount by making an additional purchase of a DVD player from merchant140. In another example, server111may collect offers, promotions, or discounts from various merchants, and may provide a comparison of prices, offers, promotions, or discounts offered by various merchants in favor of this particular merchant140to promote sales. Financial service provider110may receive some financial incentive (e.g., 1% of the promoted sales completed, regular payment, etc.) from merchant140for such services.

In some embodiments, post-purchase alert messages may similarly provide information regarding offers, promotions, benefits, or discounts provided by a bank card or a merchant, as discussed above in connection with the exemplary pre-purchase alert messages. User120may determine whether to make an additional purchase or to cancel or return a purchase based on the offers, promotions, benefits, or discounts information included in the post-purchase alert messages.

In some embodiments, post-purchase alert messages may be used for reminding user120of recurring dues of credit card bills, utility bills, mortgage, loans, or tuitions. For example, user120may have used a checking account or a debit card to pay the credit card bills, utility bills, mortgage, loans, or tuitions. Server111may determine the next due dates of various credit cards, utilities, mortgage, loans, or tuitions based on the past due dates, and may provide user120an option to receive reminders for upcoming due dates. This may help user120avoid any late payments.

FIGS. 10A and 10Bshow an exemplary user interface for providing ratings and reviews of merchants to user120. In the embodiment shown inFIGS. 10A and 10B, the user interface may take the form of a web page1010and a web page1060. Other forms of user interface, such as text-based tables, may also be used for providing ratings and reviews of merchants to user120. The user interface may be displayed on display310, for example, after user120selects the Yes button620,820, or920, consistent with the above described embodiments. Web page1010may be related to a financial institution, e.g., Bank A, which offers credit card A. Web page1010may show details about user's account with Bank A. For example, web page1010may show transactions and details related to credit card A. A first section1030of web page1010may show the current balance and the amount due of credit card A. A second section1040of web page1010may show a list of transactions made at different merchants A, B, C, D, E, F, and G. User120may click on one of the merchants to open up another web page1060, for example, to view additional information about the selected merchant. Alternatively or additionally, second section1040may display an alert message1050associated with a merchant, such as merchant B, to alert user120that this merchant has an elevated rate of disputes, and may provide a hyper-link, such as the one named “Click for details” shown inFIG. 10A. User120may click or select the hyper-link to open up web page1060, for example, to view details about this merchant.

Web page1060may display additional information about a merchant, including, for example, the name and address1070of merchant B, a message1080indicating that Bank A has flagged this merchant because of an elevated number of disputes. Web page1060may also display customer ratings and reviews1090. Customer ratings and reviews information may be received by server111from users of FSP110, for example, as part of historical disputes data. Customer ratings and reviews information may also be collected or retrieved by server111from various other sources. For example, server111may collect or retrieve ratings and reviews information from third party websites, such as, for example, online merchants, social network websites, the Better Business Bureau or other business rating entity, and/or any other entity providing a forum for customers to share their ratings and reviews about merchants.

FIG. 11shows a flowchart of an exemplary method1100for providing a differentiated dispute workflow. Method1100may be executed by, for example, server111. Server111may handle a dispute brought by user120in different processes, depending on, e.g., whether the merchant has a low reputation score or whether the user120has a history of disputing transactions and whether those disputed transactions were ultimately determined to be valid transactions. In step1110, server111may receive communication from a user to dispute a transaction made with merchant140. For example, server111may receive an electronic message or indication of a telephone call from user120who wishes to dispute a transaction made with merchant140. User120may claim that the transaction is unauthorized, fraudulent, or that merchant140abused user120by overcharging, sending user120a defective product, refusing to accept a return, etc. Server111may determine whether merchant140has a low reputation score in step1120. Server111may perform similar analyses discussed above in connection withFIGS. 5 and 7, including, for example, analysis of the historical fraud or disputes data associated with merchant140, analysis of the ratings and reviews of merchant140, analysis of the type of products and/or services, analysis of the number of disputes in the past predetermined time period, and analysis of the pattern of disputes. Similar to the above discussion in connection withFIGS. 5 and 7, server111may assign a reputation score to merchant140based on at least one of the above analyses. For example, if merchant140has an elevated number of disputes in the past three months, merchant140may receive a low reputation score. If merchant140has a relatively low number of disputes in the past three months, merchant140may receive a high reputation score. Server111may compare the reputation score of merchant140with a predetermined threshold reputation score to determine whether the reputation score of merchant140is high or low, as compared to the predetermined threshold, for example.

If server111determines that merchant140has a low reputation score (Yes, step1120), server111may initiate an expedited dispute resolution process1130to resolve the dispute. The expedited dispute resolution process1130may resolve the dispute in an expedited manner. For example, because merchant140has a low reputation score, server111may determine that the dispute brought by user120is more likely legitimate, and a favorable solution should be given to user120. According to some embodiments, expedited dispute resolution process1130may include removing the transaction from the customer's account immediately (before investigating the dispute), and FSP110may absorb the risk/cost of the transaction if the disputed transaction is ultimately resolved in merchant140's favor. If server111determines that merchant140does not have a low reputation score (No, step1120), server111may initiate a standard dispute resolution process1130to resolve the dispute. For example, because merchant140has a high reputation score, which may mean merchant140is not often involved in disputes, a standard dispute resolution process1140should be taken to resolve the dispute. The standard dispute resolution process1140may perform a more thorough investigation about the transaction, the merchant, and the user to resolve the dispute. Thus, the standard dispute resolution process1140may take longer time to resolve the dispute than the expedited dispute resolution process1130.

Although not shown inFIG. 11, it is understood that the differentiated dispute workflow may also be based on a reputation score of user120or a transactional score of the transaction, instead of a reputation score of merchant140. Additionally, the differentiated dispute workflow may be based on a combined score with at least one of the reputation score of user120, the reputation score of merchant140, and the transactional score. In other words, server111may decide whether the dispute should be processed with the expedited dispute resolution process1130or the standard dispute resolution process1140based on the reputation score of user120, the reputation score of merchant140, or the transactional score, or any combination of these scores. In some embodiments, a user reputation score may identify whether the user has a history of disputing transactions, whether those disputes were resolved in favor of user120or merchant140, whether the user is considered by FSP110to be in good standing, or whether the user is a participant in program(s) that include expedited dispute resolution as a benefit, etc. For example, in one embodiment, server111may process the dispute with the expedited dispute resolution process1130when it determines that user120has a high reputation score, or when it determines that the combined reputation score is low (indicating, for example, user120has a high reputation score and merchant140has a low merchant score). Server111may process the dispute with the standard dispute resolution process1140when it determines that user120has a low reputation score, or when it determines that the combined reputation score of user120and merchant140is high (indicating, for example, user120has a low reputation score and merchant140has a high merchant score).

In some embodiments, server111may determine whether the transactional score is higher than a predetermined threshold score. If the transactional score is higher than the predetermined threshold score, which may indicate that the transaction is more likely valid, server111may process the dispute with the standard dispute resolution process1140. If the transactional score is lower than the predetermined threshold score, which may indicate that the transaction is more likely invalid, server111may process the dispute with the expedited dispute resolution process1130.

In some embodiments, server111may determine whether a combined score, which may combine at least one of the reputation score of user120, the reputation score of merchant140, or the transactional score, is higher or lower than a predetermined threshold score. The combination may assign different weights (e.g., 20%, 50%, 30%) to the reputation score of user120, the reputation score of merchant140, and/or the transactional score. If the combined score is higher than the predetermined threshold score, which may indicate that the transaction is more likely valid, server111may process the dispute with the standard dispute resolution process1140. If the combined score is lower than the predetermined threshold score, which may indicate that the transaction is more likely invalid, server111may process the dispute with the expedited dispute resolution process1130.

The foregoing description has been presented for purposes of illustration. It is not exhaustive and is not limited to the precise forms or embodiments disclosed. Modifications and adaptations of the embodiments will be apparent from consideration of the specification and practice of the disclosed embodiments. For example, the described implementations include hardware and software, but systems and methods consistent with the present disclosure can be implemented as hardware or software alone.

While the above embodiments describe providing alerts to user120, it is understood that alert system100may also provide alerts to merchant140. For example, when user120swipes a bank card at a point of sale terminal at merchant140, server111may analyze the historical fraud or disputes data associated with user120, and may determine that user120has a low reputation score. Server111may provide a pre-purchase alert message to merchant140to notify merchant140that user120may have a low credit rating, a high risk for fraud, or a high likelihood to bring a dispute about the purchase in near future. Merchant140may take appropriate measures (decline the purchase, require cash, etc.) to prevent potential loss based on information included in the pre-purchase alert message about user120, or any additional information about user120that server111may provide via options included in the pre-purchase alert message. For example, merchant140may be a car dealer, who may decline to sell a car to user120after receiving a pre-purchase alert message from server111indicating that user120has a history of bringing disputes or lawsuits against various car dealers. Pre-purchase alert messages may also include offers, promotions, discounts, or benefits information that server111collects from various sources of merchant140, such that merchant140may relay such information to user120to promote sales, or such that merchant140may match a competitor's offer in order to persuade user120to make the same purchase at merchant140rather than at the competitor's store.

Computer programs based on the written description and methods of this specification are within the skill of a software developer. The various programs or program modules can be created using a variety of programming techniques. For example, program sections or program modules can be designed in or by means of Java, C, C++, HTML, assembly language, or any such programming languages. One or more of such software sections or modules can be integrated into a computer system, non-transitory computer-readable media, or existing communications software.