FRAUD MONITORING SYSTEM

BACKGROUND OF THE INVENTION

People expect payment transactions, such as credit card payments made at a point of sale terminal or through a web interface, to be processed in a matter of seconds. In those few seconds, the payment processor needs to receive the transaction request, perform various checks on the transaction, and send a return message authorizing the transaction. If the duration of any of the steps is increased—even on the order of a few seconds—the payment approval process will seem long and inconvenient to a user that is accustomed to having their transactions processed at near instantaneous speeds. However, the potential for fraudulent and misprocessed transactions forces payment processors to sometimes take more time when handling the approval process. Misprocessed transactions must generally be rectified through the application of costly human capital, and the cost of fraud represents both a direct loss to the processor as well as an indirect cost associated with the erosion of trust between the payment processors and their customers. Payment processors must therefore balance the additional time savings that may be afforded to a user of their payment service against the cost of potentially allowing fraudulent or misprocessed transactions to slip through the system.

A payment processing system 100 for a payment service is display in FIG. 1. System 100 comprises a user 101 conducting a purchase transaction using system 100 via a mobile telephone 102. Payment processing system 100 is enabled through the use of multiple servers. In this sense, payment processing system 100 is exemplary of nearly all modern payment processing systems. Payment systems are generally serviced through the use of geographically disperse datacenters that allow the payment system to be accessed wherever user 101 might be. For example, in payment processing system 100, servers 103 and 104 are located in different datacenters, but either server can be used to process a payment on behalf of user 100. In addition, when a payment processing system is dealing with a high volume of transactions, certain servers in the network can become overloaded. To more evenly distribute the volume of payments processing requests, a load balancer such as load balancer 105 can be employed to evenly divide payment processing services between servers such as servers 104 and 106.

Proper book keeping requires centralized access to every transaction conducted by a given account regardless of what server actually processed the payment request. As a result, the payment processor needs a central location at which all of the accounts can be reconciled. In system 100, accounts are reconciled at central database 107 which receives payment transactions from servers 103, 104, and 106.

SUMMARY

Disclosed herein are systems, methods, and computer-readable media for a fraud monitoring system with a distributed cache. The systems can perform the described methods and can be stored on the computer-readable media. As used herein, the term “locale” refers to the common industry definition of a hardware locale (i.e., a localized set of hardware resources that are close enough to enjoy uniform memory access to the same physical memory).

A system for fraud monitoring with a distributed cache is disclosed. The system comprises a first server being located at a first locale and routing a first series of transaction requests for a payment service. The system also comprises a second server being located at a second locale and routing a second series of transaction requests for the payment service. The system also comprises a distributed cache storing a set of transaction details of the first and second series of transaction requests. The system also comprises a risk service operating at the first locale and having access to the set of transaction details from the distributed cache. The risk service generates a fraud warning based on a result of a comparison of the set of transaction details and a transaction detail of a new transaction request received at the first server.

A computer-implemented process for fraud monitoring is also disclosed. The method comprises processing a first series of transaction requests at a first server. The method also comprises processing a second series of transaction requests at a second server. The method also comprises storing historical transaction information concerning transactions associated with the first and the second series of transaction requests in a distributed cache. The method also comprises receiving a transaction request. The method also comprises conducting a comparison of information regarding the transaction request with the historical transaction information. The method also comprises issuing a fraud warning based on results of the comparison. The first and the second series of transactions are associated with a single user account. The first and second servers are in different locales.

Another system for fraud monitoring is also disclosed. The system comprises a first server being located at a first locale routing a first series of transaction requests for a payment service. The system also comprises a second server being located at a second locale routing a second series of transaction requests for the payment service. The system also comprises a distributed cache storing a set of transaction details of the first and the second series of transaction requests. The system also comprises a risk service having access to the set of transaction details from the distributed cache. The risk service generates a fraud warning based on a result of a comparison of at least one transaction detail of a new transaction request received by the first server. The first and second series of transaction requests are associated with a single payment service user account.

A payment processing system, including fraud monitoring is also disclosed. The system includes a server that processes a purchase transaction request for a transaction between a customer and a merchant. The customer is associated with a customer profile defining a customer security level that is one of a plurality of customer security levels. The merchant is associated with a merchant profile defining a merchant security level that is one of a plurality of merchant security levels. A risk service determines a risk for the purchase transaction request based on transaction data of the purchase transaction request, the customer profile, and the merchant profile. The risk service determines the risk by operating at a risk assessment level that is one of a plurality of risk assessment levels at which the risk service operates depending on the customer security level and the merchant security level defined by the customer profile and the merchant profile, respectively. The risk service generates a fraud warning based on a result of the determination.

A payment processing method is also disclosed. The method includes processing a purchase transaction request for a transaction between a customer and a merchant by a server. The customer is associated with a customer profile defining a customer security level that is one of a plurality of customer security levels. The merchant is associated with a merchant profile defining a merchant security level that is one of a plurality of merchant security levels. A risk service determines a risk for the purchase transaction request based on transaction data of the purchase transaction request, the customer profile, and the merchant profile. The risk service generates a fraud warning based on a result of the determination. The risk service determines the risk by operating at a risk assessment level that is one of a plurality of risk assessment levels at which the risk service operates depending on the customer security level and the merchant security level defined by the customer profile and the merchant profile, respectively.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates a block diagram of a payment processing system in accordance with the related art.

FIG. 2 illustrates a block diagram of a system for fraud monitoring in a payment system using a distributed cache.

FIG. 3 illustrates a distributed storage architecture of an exemplary payment system.

FIG. 4 illustrates a flow chart of a method for fraud monitoring in a payment system.

FIG. 5 is a block diagram of a payment processing system, including fraud monitoring, in accordance with some embodiments.

FIG. 6 shows a block diagram of a risk service for use in the payment processing system shown in FIG. 5, in accordance with some embodiments.

FIG. 7 is a flowchart for a payment processing method, including fraud monitoring, in accordance with some embodiments.

FIG. 8 is a block diagram of a payment processing system, including fraud monitoring, with a distributed cache, in accordance with some embodiments.

DETAILED DESCRIPTION

Reference now will be made in detail to embodiments of the disclosed invention(s), one or more examples of which are illustrated in the accompanying drawings. Each example is provided by way of explanation of the present technology, not as a limitation of the present technology. In fact, it will be apparent to those skilled in the art that modifications and variations can be made in the present technology without departing from the spirit and scope thereof. For instance, features illustrated or described as part of one embodiment may be used with another embodiment to yield a still further embodiment. Thus, it is intended that the present subject matter covers all such modifications and variations within the scope of the appended claims and their equivalents.

Fraud monitoring generally requires the details of a current transaction to be compared to the details of prior transactions made using a funding source. The analysis focuses on patterns in the data to detect potential fraudulent transactions. For example, if one transaction took place in New York, and then another transaction took place in Los Angeles within a short enough period of time, the fraud monitoring system would detect the potential for fraud because a person using the funding source could not be in both of those places at the same time. Fraud monitoring can also be based on other patterns such as tracking the cumulative amount of money spent using a particular funding source in a given period of time. For example, if more than $500 were spent in a single day, a fraud monitoring system would detect the potential for fraud based on the velocity of funds being drawn from that funding source. The details of prior transactions would need to be accessed in this example in order to calculate the total amount of money spent using the funding source and add it to the amount of money being spent using the current funding source.

Methods for facilitating fraud monitoring can be described with reference to system 100 in FIG. 1. As stated previously, certain fraud monitoring schemes require access to the details of prior transactions conducted on an account in order to function. One approach to providing this information to the fraud monitoring system is to allow the fraud monitoring system to check each transaction against data held in database 107. As a result, each transaction conducted in the payment system requires a call to the central database. In the interest of increasing the speed of the system, servers 103, 104, and 106 could be designed to approve transactions without access to central database 107. However, these approvals would therefore be issued with a potentially incomplete picture of the status of the account.

Embodiments of the present invention provide faster payment system authorization processing, require fewer calls to a central database, and provide the same level of fraud monitoring provided by slower and more resource hungry processing systems. These embodiments utilize a distributed cache to make prior transaction details or information about prior transactions available at each of the disparate servers used by the payment service. As a result, the information necessary for fraud monitoring can be made readily available for payment authorizations without requiring the servers to access—and bog down—a central server with their requests for information. In addition, the distributed cache can be cleared by a reaper process periodically to limit the resource requirements for the distributed cache. Since specific fraud monitoring methods only require access to transaction details from transactions conducted in a set time period in the recent past, the reaper window can be set to that time period, and the resulting savings in resources will not have any detrimental effect on the performance of the fraud monitoring system. As a specific example, monitoring based on the cumulative amount spent in a given time period can be monitored without any detrimental effect on the fraud monitoring system by preserving only the transactions that are within that time period. In certain embodiments, an additional benefit is provided in that the time at which each transaction takes place does not need to be stored in the distributed cache. Since the reaper process can be set to periodically clear transactions from the distributed cache, the reaper process will indirectly provide information to the fraud monitoring system as to the timing of the all transactions stored in the distributed cache.

FIG. 2 displays a payment system 200 for processing payment requests and providing fraud monitoring utilizing a distributed cache. Payment system 200 comprises three servers 201, 202, and 203. All of these servers are located at different locales such that none share uniform access to the same physical memory. Servers 201 and 202 can be located in the same datacenter and receive transaction requests 204 from load balancer 205. Server 203 is located at a different datacenter. Although a single transaction request 204 is illustrated, the system is designed to process a series of transaction requests that are continuously delivered to the system. Each of the three servers process their own individual series of transactions.

Transaction requests, such as transaction request 204, are received by payment system 200 from account holders of the payment service that administrates payment system 200. The requests may include requests to withdraw, deposit, send, or receive money using payment system 200. All of these types of requests can be referred to as transfer requests because funds are being transferred between various accounts in all of these cases. The payment service that administrates payment system 200 may or may not handle the actual transfer of funds between financial accounts that are associated with payment system 200. For example, the payment service may be partnered with an external financial institution that allows the account holders to transfer funds to and from the accounts that the financial institution administrates. The link between the payment system and the financial instruments involved in the underlying transactions is not illustrated in FIG. 2. However, it should be understood that transactions processed using system 200 can directly or indirectly reflect the actual transfer of funds between financial institutions.

Traditional fraud monitoring in system 200 would generally require access to a central database such as central database 206, which results in a detrimental increase in the time it would take payment system 200 to provide an approval for a transaction. In particular fraud monitoring processes, such as those based on calculating a cumulative amount spent by a purchaser in a given time period, the computational intensity of the process would further degrade the responsiveness of the payment system by placing computational demands on the central database in addition to data access demands. However, payment system 200 includes a group of risk services 207-9 located at the same locale as each server 201-3.

Risk services 207-9 each store a selection of transaction details regarding transactions processed in their individual series of transactions. The transaction details can include a time at which specific transactions take place, a location of the transaction, and amount involved in the transactions, the counterparties to the transaction, the financial institution associated with the transactions, and any other information that describes the circumstances and details of a transaction. Collectively, these transaction details comprise historical transaction information concerning the series of transactions requests received by the payment system. There may be one or more financial institutions associated with a particular transaction. For example, if the transaction is a purchase transaction transferring money form a buyer to a seller, the buyer and seller may have financial accounts with separate financial institutions, such that both the buyer's financial institution and the seller's financial institutions will be associated with the transaction. Furthermore, the transaction details can include details that are derived from information contained in the transaction requests. For example, the transaction details could include a cumulative amount of money spent on transactions involving a particular financial institution or spent by a specific user. As another example, the transaction details could include a cumulative distance between the locations associated with transactions involving a specific user. As such, the transaction details can include details that are calculated by risk service 207-09.

The transaction details obtained or calculated by risk services 207-9 are synchronized across each risk service in the system through the use of distributed cache 210. In this manner, each risk service has access to the transaction details obtained from the three series of transactions being processed by servers 201, 202 and 203. As a result, the most recently received transaction at server 203 may be analyzed using information obtained from transactions processed at servers 201 and 202 without having to access central database 206. Risk service 207-9 is therefore able to generate a fraud warning based on a comparison of at least one transaction detail in the set of transaction details available to the risk service and at least one transaction detail of a new transaction received by the system 200 regardless of which server processed the prior transactions.

Payment system 200 can be put into service in various implementations. The distributed cache could comprise an open source Java distributed cache such as Ehcache. Distributed cache 210 could also be a proprietary distributed caching system that is unique to the payment service. Servers 201, 202, and 203 may all be located in the same datacenter and they could all be located in different datacenters. Servers 201, 202, 203 could be based on magnetic or flash memory. The network linking each element in payment system 200 can comprise any number of interconnecting physical networks including Tier 1 networks, long-distance telephone networks, cable networks, mobile telephone networks, local wireless networks, or any kind of telecommunications network. Data in payment system 200 can be routed via the Internet, wide area networks, local area networks, or proprietary networks for the payment service.

FIG. 3 shows a distributed storage architecture 300 of an exemplary payment system of a payment service. The payment system utilizes the distributed storage architecture 300 to provide low latency processing and redundancy across any geographic area. The payment system can operate across a geographic area with three locations 301, 302, and 303. At the location 301, a single payment service participant, a financial network 304, can operate (i.e., the financial network 304 can have one or more computing nodes at the location 301). At location 302, a payment processor 305, a financial institution 306, and a merchant 307 can operate (i.e., the payment processor 305, the financial institution 306, and the merchant 307 can each have one or more computing nodes at location 302). At the location 303, two merchants 308 and 309 can operate (i.e., the two merchants can each have one or more computing nodes at the location 303). Any payment service participant can also have operations at more than one location (e.g., a merchant can have operations at location 302 and at the location 303 as illustrated). Each location can also have one or more additional operating nodes (not illustrated) that may be related or unrelated to the payment service.

Each payment service participant can store its own data elements 310, i.e., those data elements that are associated directly with the payment service participant, in a local cache of data elements. The local cache of data elements can be considered a second storage device and can include one or more physical storage devices. For example, the financial institution 306 at location 302 can be a bank that stores all transaction, ledger, account, and other bank information in its corresponding local cache of data elements 311. Thus, the stores of data elements managed by each payment service participant can be siloed from other stores of data elements. Though not illustrated, the data elements can also be stored remote from a payment service participant, for example, the bank can remotely access its data elements. Regardless of where the data elements for a payment service participant are physically stored, it is generally understood that the payment service participant can have a greater degree of control over its data elements than other payment service participants—therefore, the payment service participants may desire to have their data elements stored physically closer to their operations.

Nodes at the locations 301-03 can communicate to each other through a network 312, such as the Internet or a wide area network (WAN). Though not illustrated, the network can connect to a central repository of the payment service. Though not illustrated, it is assumed that each location can have a network infrastructure that allows nodes at the location to communicate with other nodes without having to traverse a potentially higher latency network that spans multiple locations. For example, if location 301 is a metropolitan area, location 301 can utilize a metropolitan area network (MAN), if location 302 is an area with large spatial scope, location 302 can utilize a wide area network (WAN), and if location 303 is a college campus, location 303 can utilize a campus area network (CAN) or other local area network (LAN).

The payment system can reduce latency by caching stored hierarchies storing hierarchy data at the various locations. As illustrated, location 301 has a cached hierarchy 313, location 302 has a cached hierarchy 314, and location 303 has a cached hierarchy 315. Each of the cached hierarchies can be examples of a first storage device, though a storage device can include one or more physical machines. Each of the cached hierarchies can reduce data access latency by serving the cached hierarchy's location. For example, all payment service participants at location 301 can access the cached hierarchy 313, all payment service participants at location 302 can access the cached hierarchy 314, and all payment service participants at location 303 can access the cached hierarchy 315, rather than having to access hierarchy data across the network. The cached hierarchies 313-15 can be stored in any logical storage system such as an in-memory NoSQL database, a memory caching system such as memcached, or any other logical storage system that allows fast data access.

FIG. 4 illustrates a process 400 for fraud monitoring in a payment processing system. Process 400 begins with steps 401 and 402 in which separate servers in the payment system continually process a first and a second series of transaction requests. Steps 401 and 402 may occur in parallel. Process 400 continues with step 403 in which selected information regarding the transactions in the first and second series of transaction requests are pulled from the transaction details as they are being processed, and are then stored in a distributed cache as historical transaction information. The transaction details pulled from the transaction requests could include all of the available information included regarding the transaction. Part of step 403 is server specific, but the step involves both servers as the distributed cache synchronizes the historical transaction information to a risk service located at the same locale in each of the separate servers. In step 404, a transaction request is received at the first server. Alternatively, the method can continue with step 405 in which a transaction request is received at the second server. In step 406, information regarding the current transaction is compared with historical transaction information stored in the distributed cache. The historical transaction information is accessible to the first server at the first server's locale, and is accessible to the second server at the second server's locale. The historical transaction information can be accessible via a risk service located at each of the first and second locales.

The comparison and analysis conducted in step 406 will determine whether or not the most recently received transaction has triggered one of the fraud monitoring rules in the system. If the fraud rules provided by the risk service are not tripped, the process will conclude at this step, and the payment system will return to steps 401 and 402. Optionally, at some point after steps 404 and 405 commence, but before the process concludes, information regarding the transaction requests received in steps 404 and 405 can be pulled from the transaction requests and be stored in the distributed cache. If the fraud rules provided by the risk services are tripped, the method will proceed to step 407 or 408 depending upon which server received the transaction that tripped the risk service and issued the fraud warning. In one embodiment, when the fraud rules provided by the risk services are tripped, the risk service immediately communicates this information to the server to deny, suspend or flag the transaction. In another embodiment, the server continuously queries the risk service for information. In step 407, the first server tripped the rule and issues a fraud warning. In step 408, the second server tripped the rule and issues a fraud warning. The payment system can (i) utilize the fraud warning to deny the latest transaction request, (ii) trigger an automated or live operator call to the account holder associated with the latest transaction request, (iii) store the fraud warning in a central database, and/or (iv) alert a merchant involved with the transaction request that additional verification steps are required before the transaction can be approved.

Various kinds of information regarding the series of transactions received by the payment processor can be selected and stored in step 403. This information can comprise the transaction details that are stored in the distributed cache 210 described above. Expanding on the examples provided above, the historical transaction information and transaction details can be comparative information concerning a set of transactions in the series of transactions such as a cumulative distance between the geographical locations of each transaction in the set of transactions or a cumulative amount of funds involved in the set of transactions. For example, in a series of three transactions: A, B, and C, the distributed cache stores a value corresponding to the geographical distance between the location of transaction A and the location of transaction B added to the geographical distance between the location of transaction C and the location of transaction B. In a further example using the same series of transactions, the distributed cache could store a value corresponding to the sum of all the funds involved with each of transactions A, B, and C. The historical transaction information and transaction details could relate to a single user account, a set of accounts associated with a single financial institution, or all the accounts utilized in the payment service.

The stored information could be compared to details of a new, most recently received, transaction request to assure that the cumulative amount spent by an account holder did not exceed a preset spending limit. This is an advantageous application, because calculating a cumulative spending history for an account holder in the payment system is a procedure that would otherwise require intensive resources from a central database. The cumulative spending history query is resource intensive because numerous lookups are required to find the amounts of each transaction associated with a specific account, and those amounts must be summed with an amount from the current transaction before being compared with the cumulative spending limit. If instead information about a set of transactions is stored on distributed cache 210, both the amount of a most recent request received by a recipient server and a cumulative total of that set of transactions would be available at the recipient server such that there would be no need to access central database 206. The recipient server could then issue the fraud warning immediately if necessary.

Risk services 207-9 can be configurable to set different fraud monitoring rules. They can likewise be configurable to apply different monitoring rules based on an identity of the user requesting a transaction or based on a financial institution that administers the funding source that will be involved in the requested transaction. Financial institutions may modify the properties of risk services 207-9 through an administration portal. The portal may allow them to set what kinds of rules should be used in order to monitor for fraud. Once the rules have been selected, the portal will also allow them to set various variables associated with the selected rule. For example, a financial institution might use the portal to choose to set a rule on cumulative spending, and set a $500 maximum to the amount that may be spent in a single day using any account they administrate. If a transaction request would exceed this limit, the transaction may be flagged, suspended or denied. The portal may also be accessible the payment service itself and allow it to configure different rules for particular financial institutions, or set global rules for use of the payment system as a whole. The rules can be set to only apply to specific financial institutions or to specific users such that the accounts of high risk individuals could be subjected to more stringent fraud monitoring rules. The rules can be stored in the risk service.

In specific embodiments of the present invention, the payment system is able to configure rules in a risk service to be specific to particular financial institutions and users because the payment system will include data in the transaction requests that identify what financial institutions and users are involved in the transaction. For example, each transaction request may be tagged with an identifier indicating that the current transaction involves a specific financial institution or a particular user account. The risk service may then use these identifiers to calculate that user's cumulative spending on past transactions by summing the total funds involved in all transactions stored in the distributed cache that are associated with that user with the amount of the current transaction. The risk service could likewise use the identifier in the most recently received transaction to look up what fraud monitoring rules should be applied based on the identifiers for the user and financial institution that are included with the transaction request. For example, a most recently received transaction could include an identifier for a financial institution that uses a cumulative spending fraud monitoring rule so the risk service would know to apply that rule to the received transaction request. In one embodiment, the risk service may strip the required information from the transaction requests as they are received. In another embodiment, the server may handle this operation separately and pass the identifiers to the risk service.

The payment system described with reference to FIG. 2 may include a reaper process used to minimize the resource requirements of distributed cache 210. The reaper process could have access to the distributed cache. The reaper could be configured with a predetermine reaper period and reaper window. The reaper period would set how often the reaper process was initiated and the reaper window would determine which transactions the reaper process removed every time it was executed. For example, a reaper period of one day and a reaper window of five hours would set the reaper process to run once a day, and only preserve transaction details for transactions that occurred in the last five hours. Therefore, the maximum space required of the distributed cache would be twenty-nine hours of transaction history, and at least five hours of transaction details would be preserved to maintain security.

The reaper process could be configured to tradeoff resource consumption and security. These tradeoffs could be set independently on a user-specific basis or on a financial institution basis. For example, the configurable reaper period could be set to zero such that the reaper process would be continuously running to manage resources on the distributed cache. The reaper window could also be set to zero such that all transactions were purged from distributed cache 210 on a periodic basis. As mentioned, the reaper process could also remove transaction details based on an identity of a user or a financial institution and purge the distributed cache in a staggered fashion such that subgroups of users and financial institutions had their data purged at different times. The financial institution and payment service could configure the reaper period and reaper window through the use of an administration portal to achieve the tradeoffs mentioned above. The payment service could also configure the reaper period and window on behalf of a specific financial institutions in order to provide a level of risk limiting that was requested by a financial institution. For example, the payment service could enter into an agreement with a financial institution to always maintain at least a day's worth of transaction details in the distributed cache, and to run the reaper process at the close of business local time each day. To implement this policy, the payment service would set both the reaper window and reaper period to one day. The length of the reaper window and frequency of the reaper period could be linked to a fee charged to the financial institution such that the fee charged would increase in direct proportion to the amount of data to be stored on the distributed cache for a given policy.

The process of minimizing the resources necessary to facilitate a particular fraud monitoring program selected by a financial institution, or by the payment service generally, could be selected in various ways. The process will depend on the amount of historical information the fraud monitoring program is interested in analyzing. For example, a financial institution may want to monitor one day's worth of transactions for each of its users, and assure that the cumulative amount spent during each day was less than $500. In this situation, the minimum resources in terms of storage space would be obtained by having the reaper process run continuously (i.e., with the reaper period equal to zero), and the reaper window set to one day. However, running the reaper process consumes processing resources, so the optimum selection of the reaper period and reaper window requires an additional tradeoff based on the efficiency of the reaper process. Therefore, a more practical approach might be to have the reaper period set to half a day, and the reaper period set to one day.

Another example of implementing a fraud monitoring policy involves setting the reaper window to zero to thereby purge the distributed cache every reaper period. Under this approach, the distributed cache could avoid having to store time stamps among the other transaction details in the distributed cache. One downside to this approach is that the fraud monitoring capabilities of the system would be diminished immediately after the purge because there would be no historical data to frame an analysis of the most recently received data. In addition, in the absence of a staggered purge, storage resources would be left unused by this approach as the minimum storage resources allocated to the distributed cache would be empty and useless following the purge. However, using a reaper window of zero in combination with staggered purging in which the reaper process was run for different users or financial institutions at different times could act against this inefficiency by always maintaining data in the distributed cache.

Returning to the example of risk services 207-9 monitoring the cumulative spending of a particular user, the reaper window could be set in combination with the amount of cumulative spending in order to monitor the velocity of funds exiting the account. For example, the cumulative spending limit could be set to $100 and the reaper period could be set to one day with the reaper process running continuously. In this case, the reaper process would be eliminating any transaction not necessary to implement a fraud monitoring rule that implemented a $100 per day limit on an account with the payment service.

In another example, while risk services 207-9 are active, the reaper process could be initiated every time a certain number of transactions took place. In this way, after a larger amount of transactions, all transactions are purged from distributed cache 210 thus freeing up resources. This may be beneficial during periods in which large numbers of transactions were taking place such as during peak holiday shopping days. Another fraud monitoring rule that would benefit from being combined with a reaper process is one that placed a limit on the cumulative geographical distance between transaction locations in a given time period. Risk service 207-9 could monitor the cumulative distance between transactions in combination with a reaper window set to the expected distance an account holder could travel in a given period of time. Financial institutions that served people known to have limited mobility could set the reaper window to an hour and the cumulative distance that could be traveled by foot in an urban area. In this situation, the number of transactions that would need to be monitored would be limited by a tight window and the resource constraints placed on the distributed cache would likewise be limited. This would be a cost effective solution for financial institutions that could not afford the fees associated with heavy use of the distributed cache.

Although embodiments of the invention have been discussed primarily with respect to specific embodiments thereof, other variations are possible. Various configurations of the described system may be used in place of, or in addition to, the configurations presented herein. Those skilled in the art will appreciate that the foregoing description is by way of example only, and is not intended to limit the invention. For example, nothing in the disclosure should be read to limit the payment processor to one that processes transactions using any specific kind of payment instrument, such as credit cards, as any form of electronic payments could potentially benefit from the teachings of this disclosure. In particular, the servers that process the payment transactions could be similar to the MOBI account server, described in U.S. Patent Publication No. 2009/0024533 A1 for “Payment Systems and Methods” filed Aug. 29, 2007, or U.S. patent application Ser. No. 13/755,421 for “Self-authenticating peer-to-peer transaction” filed Jan. 31, 2013, both of which are owned by the assignee of the present invention, and both are incorporated by reference herein in their entirety. Furthermore, nothing in the disclosure should indicate that the invention is limited to systems and methods that involve a payment system that processes payments for the same user at different datacenters, as the present invention can facilitate fraud monitoring for payment systems that process payments for the same user on servers at different locales even if all of the servers are located in the same datacenter.

The payment processing system includes a server that processes a purchase transaction request for a transaction between a customer and a merchant. The customer is associated with a customer profile that defines a customer security level that is one of a plurality of customer security levels. The merchant is associated with a merchant profile that defines a merchant security level that is one of a plurality of merchant security levels. A risk service determines a risk for the purchase transaction request based on transaction data of the purchase transaction request, the customer profile, and the merchant profile. The risk service determines the risk by operating at a risk assessment level that is one of a plurality of risk assessment levels at which the risk service operates depending on the customer security level and the merchant security level defined by the customer profile and the merchant profile, respectively. The risk service generates a fraud warning based on a result of the determination.

In another embodiment, FIG. 5 is a block diagram of a payment processing system for fraud monitoring in accordance with some embodiments. Payment processing system 500 includes a server 501 and a risk service 507. A purchase transaction request 504 is shown. In other embodiments, the payment processing system 500 is designed to process a plurality of transaction requests that are continuously delivered to the payment processing system 500. Similar to the description of FIG. 2, transaction requests, such as the purchase transaction request 504, are received by the payment processing system 500 from account holders of the payment service that administrates the payment processing system 500. The requests may include requests to withdraw, deposit, send, or receive money using the payment processing system 500, and as already described, the transactions processed using the payment processing system 500 can directly or indirectly reflect the actual transfer of funds between financial institutions. The risk service 507 may be located at the same locale or a different locale as the server 501.

An account holder may have a user account and be a customer or merchant. The user account may be referred to as a customer account or a merchant account, respectively. A customer profile or a merchant profile is associated with the user account. In some embodiments, these accounts and profiles may be configured as described in U.S. patent application Ser. No. 14/031,381, which is incorporated herein by reference as if fully set forth herein. The customer is associated with the customer profile which defines a customer security level that is one of a plurality of customer security levels. The merchant is associated with the merchant profile which defines a merchant security level that is one of a plurality of merchant security levels. Each profile is associated with a single account holder and has different amounts or types of data, depending on the customer or merchant security level. The profiles may be classified into two or more tiers, corresponding to the customer or merchant security levels, based on the different amounts or types of data. In various embodiments, there may be any number of tiers, such as 3, 5, 8 or 10, depending on the application.

The customer and merchant profiles may contain a varied amount of information. In some embodiments, the customer and merchant profiles are classified in three tiers, e.g., basic, enhanced and premium, based on the amount or type of data. The different amounts or types of data provide different levels of certainty that the customer or merchant is legitimate. For example, the plurality of customer security levels includes a first customer security level in which the customer profile contains a first set of customer data, a second customer security level in which the customer profile contains a second set of customer data that includes more information than the first set of customer data, and a third customer security level in which the customer profile contains a third set of customer data that includes more information than the second set of customer data.

Likewise, the plurality of merchant security levels includes a first merchant security level in which the merchant profile contains a first set of merchant data, a second merchant security level in which the merchant profile contains a second set of merchant data that includes more information than the first set of merchant data, and a third merchant security level in which the merchant profile contains a third set of merchant data that includes more information than the second set of merchant data.

FIG. 6 shows a block diagram of a risk service for use in the payment processing system shown in FIG. 5, in accordance with some embodiments. Illustrated are different example customers, A, B and C, with varying amounts of data in their profiles, and different example merchants, D, E and F, with varying amounts of data in their profiles. In this example, the first customer/merchant security level, such as A and D respectively, are classified as the “basic” profile tier. The second customer/merchant security level, such as B and E respectively, are classified as the “enhanced” profile tier. The third customer/merchant security level, such as C and F respectively, are classified as the “premium” profile tier. In some embodiments, based on the tier of the customer or merchant profile, for example, basic, enhanced or premium, the customer or merchant may qualify for different features of the system. For example, the higher profile tiers may be permitted a greater amount of transactions, a higher amount of transactions in a particular time frame, a higher cumulative value of transactions, faster transactions or other benefits or features. On the other hand, the lower profile tiers may be permitted fewer such benefits.

The risk service 507 is an example of a feature that may be faster or slower or more or less robust, depending on the profile levels of the customer and merchant involved in a purchase transaction request. The risk service 507 determines a risk for the purchase transaction request 504 based on transaction data of the purchase transaction request, the customer profile, and the merchant profile. The transaction data includes a time, a location, an amount, the counterparties, and the financial institution associated with the purchase transaction request 504. The risk service 507 determines the risk by operating at a risk assessment level that is one of a plurality of risk assessment levels at which the risk service operates depending on the customer security level and the merchant security level defined by the customer profile and the merchant profile, respectively. The risk service generates a fraud warning based on a result of the determination.

FIG. 6 illustrates an example of some embodiments in which three levels of risk assessment are used, such as basic, enhanced and premium risk assessment levels, corresponding to the previously mentioned example profile tiers of the customer and merchant. Since the premium profiles include more data for the customer and merchant, the certainty that the customer and merchant are legitimate or a safe security risk is greater. Therefore, the premium risk assessment level can be performed with less data. For example, the premium risk assessment level may consider only data for the current transaction, along with the customer and merchant profile data. On the other hand, since the enhanced customer and merchant profiles include less data than the premium profiles, the certainty that the customer and merchant are legitimate is lesser. Therefore, the enhanced risk assessment is performed with more information. For example, the enhanced risk assessment may consider, not only the current transaction, but also a number of prior transactions conducted by either the customer or the merchant, along with the customer and merchant profile data. By examining the prior transactions, behavior patterns may be determined for either the customer or the merchant or both, and these patterns can be used in the risk assessment to approve or deny the transaction as a potential fraudulent transaction. Additionally, since the basic customer and merchant profiles include less data than the enhanced and premium profiles, the certainty that the customer and merchant are legitimate is lowest. Therefore, the basic risk assessment is performed with even more information than is the enhanced risk assessment. For example, the basic risk assessment may consider, not only the current transaction, but also a larger number of prior transactions conducted by either the customer or the merchant, along with the customer and merchant profile data.

In some embodiments, the higher level tiers may be made available as value added services to the customer, the merchant, and/or the financial institution. For example, an extra amount to the cost per transaction or a flat monthly fee may be charged for the service.

Customers or merchants may be identified in their accounts or profiles as high risk based on history, location or type of business. For example, the merchant may be identified as high risk if many transactions are performed in a small amount of time, or if the merchant is located in a high crime rate area, or if the merchant is a particular type of business such as a convenience store. If a transaction originates from a high risk merchant, additional risk parameters may be assessed before the transaction is approved thus qualifying as the enhanced or premium level of risk assessment. The risk service may utilize the history of transactions for the merchant and determine ‘normal activity’ for a particular day and time frame. If many more transactions are requested at this merchant than what has been defined as normal activity, the risk service 507 may only approve a certain amount of transactions in that time frame and deny others by generating a fraud warning. This ties the potential risk of the transaction to additional parameters.

Another example may use geographical information to assess risk. For example, when using the enhanced or premium level risk assessment, the zip code and time of an incoming transaction associated with the account or profile of the customer may be compared to the zip code and time of a previous transaction. In this way, it may be determined if it's physically possible for the same customer to have made the purchase transaction requests based on the distance between the merchants and time between purchase transaction requests.

Furthermore, various identity verification information options may be presented for the different user profile levels. Thus, the level of identity verification provided by the user during an account registration procedure can be used to generate the user profiles and determine the user profile level for each user. For example, a mobile phone number, biometric information, fingerprints, and retinal scans, among other types of information may be provided for the different user profile levels. Additionally, different combinations of options may be available for different user profile levels—for example, both photo ID's and biometric information may be required for the higher levels. Other verification information, e.g., information consistent with know-your-customer (KYC) regulations—may be included in some of the user profile levels. Furthermore, non-public identification information can be used to determine the user profile level. Such non-public information generally has a trait that can be referred to as its level of sensitivity. The level of sensitivity reflects a degree of privacy associated with the information, because a private fact about an individual (such as a finger print pattern, a social security number, or a code provided by the financial institution to the individual) would have a high level of sensitivity. On the other hand, a driver's license number would have a medium level of sensitivity, and a user's home address would have a low level of sensitivity, since this information is more readily publicly available.

In addition, various factors can be used to generate the merchant profiles and determine the merchant profile level for each merchant. For example, the merchant may use a specific type of known point of sale (POS) terminal, the merchant may use its POS terminal only at a specific physical location, and/or the merchant may have certain levels of surveillance equipment at its physical location, among other factors or considerations that provide a greater level of security. In some cases, for example, the payment service can establish a special relationship with the owner or operator of known POS terminals. In fact, the owner or operator of the known POS terminal could be an authorized agent of the payment service, or be prescreened by the payment service. Also, the use of a known POS terminal by the merchant decreases the risk of fraudulent registrations. Therefore, a higher merchant profile level may be allowed for a merchant that uses such a known POS terminal. Additionally, if the merchant uses its POS terminal only at a specific physical location (which the payment service may require), fraudulent usage of the terminal may be easier to track down, so a higher merchant profile level may be allowed in this situation. Furthermore, if the merchant installs certain levels of surveillance equipment at the location in which its POS terminal is being operated (which the payment service could also mandate as a precondition for offering the payment service to people that bank or shop at that location), then a higher merchant profile level may also be allowed.

FIG. 7 is a flowchart for a payment processing method, including fraud monitoring. At step 702, a payment processing method 700 includes processing a purchase transaction request for a transaction between a customer and a merchant by a server. The customer is associated with a customer profile defining a customer security level that is one of a plurality of customer security levels. The merchant is associated with a merchant profile defining a merchant security level that is one of a plurality of merchant security levels. In step 704, a risk service determines a risk for the purchase transaction request based on transaction data of the purchase transaction request, the customer profile, the merchant profile, and any additional information that depends on the risk assessment level and the customer and merchant profile tiers. In step 706, the risk service generates a fraud warning based on a result of the determination. The risk service, thus, determines the risk by operating at a risk assessment level that is one of a plurality of risk assessment levels at which the risk service operates depending on the customer security level and the merchant security level defined by the customer profile and the merchant profile, respectively. In some embodiments, if the customer and merchant do not have the same profile tier, then the risk assessment level depends on the lower profile tier of the customer and merchant. In other embodiments, the risk assessment level depends on the higher profile tier of the customer and merchant.

Embodiments of the present invention provide faster payment processing system authorization processing while using fewer resources. For example, by having the customer and merchant profiles classified into tiers and having the risk service 507 perform at different risk assessment levels, it is possible for the risk service 507 to bypass some processes or verification steps thus streamlining the process and yielding a faster authorization. In one embodiment, the purchase transaction request 504 is associated with a merchant or a customer with a premium profile. The risk service 507 recognizes the premium profile status and therefore, skips some of the risk functions and approves the purchase transaction request 504. In this case, the premium profile status acts as a preapproval or preauthorization.

FIG. 8 is a block diagram of a payment processing system 800 that includes fraud monitoring with a distributed cache in accordance with some embodiments. Payment processing system 800 includes a server 801, a risk service 807, a central database 806 and a distributed cache 810. A purchase transaction request 804 is illustrated, and the payment processing system 800 operates in the manner described herein with respect to the distributed cache 810. In some embodiments, the payment processing system 800 further includes the central database 806 being located remotely from the server 801 and configured to store information. The information includes the customer profile, the merchant profile and transaction data. The distributed cache 810 is connected to the central database 806 and configured to store and synchronize a set of the information, rather than all of the information which is located at the central database 806. The risk service 807, located at the server 801 in this embodiment, determines the risk of the purchase transaction request 804 based on the set of the information without accessing the central database 806.

The customer and merchant security levels and profile tiers for the embodiment described with respect to FIG. 8 are the same as, or similar to, the above description. The information such as the customer profile, the merchant profile and transaction data are stored at the central database 806. A set of this information is also stored on the distributed cache 810. In this way, prior transaction details or information about prior transactions are readily available at the server used by the payment service without requiring the server to access or bog down the central server with their requests for information. A reaper process as described herein may also be utilized.

The risk service 807 determines a risk for the purchase transaction request 804 based on the set of the information of transaction data of the purchase transaction request, the customer profile, and the merchant profile without accessing the central database 806. The risk service 807 determines the risk by operating at a risk assessment level that is one of a plurality of risk assessment levels, as described above. A fraud warning based on a result of the determination is generated.

The set of information is available on the distributed cache 810 instead of accessing the central database 806. Additionally, the risk service 807 determines the risk by operating at different risk assessment levels. In some embodiments, this combination allows the risk assessment analysis to be performed more quickly than other payment processing systems because a simpler set of information is available on the distributed cache 810, so that the risk service 807 may bypass some processes. For example, in one embodiment, the customer profile is an enhanced tier and this classification is available on the distributed cache 810 in the set of the information. When a purchase transaction request 804 is received, the risk service 807 communicates with the distributed cache 810 accessing the set of information. The set of information may be extremely simple such as that the customer has an enhanced profile. This may serve as an automatic authorization up to a particular dollar amount of the purchase transaction request 804 for the risk service 807. Thus, if the purchase transaction request 804 is within this dollar amount, no further risk assessment needs to be performed.

This specific fraud monitoring and payment processing system uses distributive synchronization of select information to create a more efficient fraud monitoring system. It's directed to this specific distributive synchronization approach to fraud monitoring by using the distributed cache 806 of the risk service 807. The distributed cache 806 synchronizes transaction details at a locale, rather than at or in a remote central database, so that the risk service has access to transaction details without accessing the central database in order to quickly generate a fraud warning based on a comparison with a new purchase transaction request. It enables the functions performed by the payment processing system 800 to be faster than a conventional system while using less resources because some processes are skipped, such as accessing the central database 806. In conventional payment processing systems, the procedure would typically require intensive resources from a central database due to the numerous lookups that would be required to obtain the needed information.

Moreover, the payment processing system 800 is faster than other systems because of the classifications of the profiles into tiers allowing automatic authorization based on the tier of the profile. Furthermore, less memory is used because only a set of the information is available on the distributed cache 810. The full information is stored on the central database 806.

In general, any diagrams presented are only intended to indicate one possible configuration, and many variations are possible. Those skilled in the art will also appreciate that methods and systems consistent with the present invention are suitable for use in a wide range of applications encompassing any related to transaction processing and fraud detection.

While the specification has been described in detail with respect to specific embodiments of the invention, it will be appreciated that those skilled in the art, upon attaining an understanding of the foregoing, may readily conceive of alterations to, variations of, and equivalents to these embodiments. These and other modifications and variations to the present invention may be practiced by those skilled in the art, without departing from the spirit and scope of the present invention, which is more particularly set forth in the appended claims.

	Number	Date	Country
Parent	14162316	Jan 2014	US
Child	15376478		US
Parent	14031381	Sep 2013	US
Child	14162316		US
Parent	13957246	Aug 2013	US
Child	14031381		US
Parent	13786408	Mar 2013	US
Child	13957246		US

FRAUD MONITORING SYSTEM

Information

Publication Number

Date Filed

Date Published

Inventors

Original Assignees

CPC

International Classifications

Abstract

Description

Claims

CROSS-REFERENCE TO RELATED APPLICATIONS

Provisional Applications (1)

Continuation in Parts (4)