Techniques for caching processing data with a predictive model

Abstract

Embodiments of the invention relate to systems and methods for utilizing a cache to store historical transaction data. A predictive model can be trained to identify particular identifiers associated with historical data that can be used on a particular date and / or a particular time period. Historical data corresponding to these identifiers can be stored in a cache of a processing computer. Subsequently, an authorization request message can be received that includes an identifier. The processing computer can utilize the identifier to retrieve historical transaction data from the cache. The retrieved data can be used to perform any suitable operation. By predicting the data that will be needed to perform these operations, and proactively storing such data in the cache, latency associated with subsequent processing can be reduced, and the overall performance of the system can be improved.

Description

[0001] This application is a continuation of International Application No. PCT / US2019 / 060954, filed November 12, 2019, entitled “Techniques for Caching Processing Data with Predictive Models,” which entered the U.S. national phase as U.S. Patent Application No. 16 / 981,680, filed November 12, 2019, the disclosure of which is incorporated by reference herein in its entirety for all purposes.

[0002] Cross Reference to Related Applications

[0003] This international application claims priority to U.S. Patent Application No. 16 / 189,565, filed November 13, 2018, the disclosure of which is incorporated by reference herein in its entirety for all purposes. BACKGROUND

[0004] Various systems can utilize multiple portions of large data sets to perform operations. For example, a system that processes data transactions can utilize historical transaction data to perform various operations. This historical data can be scattered among one or more remote systems, requiring the data to first be identified, aggregated, and provided to the system at runtime in order to perform such operations. This can result in increased latency to perform such operations, which can result in excessive delays for the system.

[0005] Embodiments of the present disclosure address these and other problems individually and collectively. SUMMARY

[0006] One embodiment of the present invention relates to a method. The method includes receiving, by a computing device (e.g., a processing network computer), an authorization request message for a transaction associated with an account. The method can further include determining whether historical transaction data associated with the account is stored in a cache accessible to the computing device. When the historical transaction data is stored in the cache, the method can further include retrieving, by the computing device, the historical transaction data associated with the account from the cache and performing, by the computing device, at least one operation in response to receiving the authorization request message, the at least one operation utilizing the retrieved historical transaction data. When the historical transaction data is not stored in the cache, the method can further include obtaining, by the computing device, the historical transaction data associated with the account from a historical transaction database and performing, by the computing device, at least one operation in response to receiving the authorization request message, the at least one operation utilizing the obtained historical transaction data from the historical transaction database.

[0007] In some embodiments, the method can further include identifying, by the computing device, one or more accounts from the plurality of accounts using a predictive model. In some embodiments, the one or more accounts can be identified by the predictive model as likely to be used for one or more transactions within a future time period (e.g., next 24 hours). In some embodiments, the predictive model can be trained based at least in part on historical transaction data associated with the plurality of accounts. The method can further include obtaining, by the computing device, a portion of the historical transaction data from a data repository. For example, the portion of the historical transaction data can correspond to transactions conducted using the one or more accounts within a second time period (e.g., past five years, all known past transactions of the one or more accounts, etc.). The method can further include storing, at the computing device, the portion of the historical transaction data within a cache.

[0008] In some embodiments, the method can further include updating the historical transaction data using transaction data associated with the authorization request message (e.g., transaction data included in the authorization request message). The predictive model can be updated based at least in part on the updated historical transaction data. For example, the predictive model can be updated based on previously stored historical transaction data and transaction data associated with the received transaction.

[0009] In some embodiments, identifying the one or more accounts, obtaining the portion of the historical transaction data, and storing the portion of the historical transaction data can be performed in response to receiving the authorization request message. In some embodiments, identifying the one or more accounts, obtaining the portion of the historical transaction data, and storing the portion of the historical transaction data can be performed periodically.

[0010] In some embodiments, the method can further include updating the historical transaction data using transaction data of the authorization request message, wherein the one or more accounts are identified from the plurality of accounts after the historical transaction data is updated using the transaction data.

[0011] In some embodiments, the at least one operation can include calculating a risk score for the authorization request message. In some embodiments, the computing device can be a processing network computer.

[0012] In some embodiments, the historical transaction data identifies a number of accounts that have been utilized historically within a particular historical time period (e.g., past five years, past ten years, etc.).

[0013] In some embodiments, it is determined that the number of accounts have performed more than a threshold percentage of transactions that occurred within the particular historical time period.

[0014] Another embodiment of the invention relates to a processing network computer comprising a processor and a computer readable medium. The computer readable medium comprises code executable by the processor for implementing the above described method.

[0015] Further details regarding embodiments of the invention are described in the detailed description and drawings. BRIEF DESCRIPTION OF DRAWINGS

[0016] Figure 1 A block diagram of a system for performing transactions with a cache is shown, in accordance with some embodiments.

[0017] Figure 2 A block diagram of an exemplary processing network computer is shown, in accordance with some embodiments.

[0018] Figure 3 A block diagram is shown, illustrating a method for identifying particular data to be cached, in accordance with some embodiments.

[0019] Figure 4 A block diagram is shown, illustrating a method for performing data computations with a cache, in accordance with some embodiments.

[0020] Figure 5 A flow diagram is shown, illustrating a method for performing data operations, in accordance with some embodiments. DETAILED DESCRIPTION

[0021] Embodiments of the invention relate to performing various operations with a cache. In some embodiments, a prediction model can be utilized to identify particular historical data that is likely to be accessed within a particular time period (e.g., within 24 hours, within the next 12 hours, on a given date, etc.). Although examples herein can relate to cases where the prediction model is used in the context of transaction processing, it should be appreciated that similar techniques can be used in various contexts other than transaction processing. The techniques described herein can be applied to any suitable context where historical data is stored and is to be accessed at a future time to perform any suitable operation.

[0022] For example, a transaction processing system can utilize a predictive model trained to identify accounts that are likely to process transactions within a given time period (e.g., the next 24 hours). Historical transaction data for a set of accounts can initially be stored in a database remote from the system. The predictive model can be trained using the historical transaction data for the set of accounts and any suitable supervised and / or unsupervised learning techniques. For example, the predictive model can be trained to identify, from the set, particular accounts that are likely to be used to perform transactions within the next 24 hours. Once these accounts have been identified, the system can be configured to obtain, from the database, a portion of the historical transaction data associated with those accounts (e.g., transactions performed with each account in the past 12 hours, 24 hours, a week, a month, etc.). The obtained historical transaction data can be stored in a cache accessible to the system. The data stored in the cache can be accessed more quickly than the data stored in the database.

[0023] Subsequently, the system can receive a transaction. The transaction can include an account identifier. The system can be configured to determine whether the historical transaction data previously obtained and stored in the cache includes historical transaction data associated with the account identifier of the received transaction. If so, the historical transaction data can be retrieved from the cache and used to perform any suitable operations. For example, the historical transaction data can include transactions associated with the identified account that have occurred within the past 24 hours. This data can be utilized by the system, for example, to calculate a risk score. The risk score can utilize any suitable algorithm to assess the risk of approving the transaction.

[0024] By predicting which accounts are likely to be used, the system can be configured to pre-fetch the historical transaction data needed to perform its operations. By caching this data, the performance of the system is improved because the latency of retrieving this data from a more remote storage is reduced. The cache can be updated periodically or at any suitable time utilizing the predictive model. In some embodiments, newly received transaction data can be added to the database, and receipt of this data can trigger an update of the cache. That is, when new historical transaction data is received, the cache can be updated utilizing the predictive model to include historical transaction data that is likely to be accessed.

[0025] Existing mechanisms for performing operations with historical transaction data (e.g., calculating a risk score) access such data from disk storage. When a transaction is received for which an operation (e.g., calculating a risk score) is to be performed, historical transaction data can be accessed and aggregated at runtime. Such systems can first identify the data and then aggregate the historical transaction data needed to perform their operations, which results in a delay in transaction processing. By utilizing the techniques discussed herein, this delay can be reduced by identifying one or more accounts that can be utilized, pre-fetching historical transaction data prior to receiving a transaction associated with one of those accounts, and storing the obtained historical transaction data in a cache accessible to the system, such that data retrieval time is reduced.

[0026] Prior to discussing specific embodiments of the application, some terminology can be described in detail.

[0027] A "user device" can include any suitable electronic device that a user can carry and operate that also can provide the ability to communicate remotely with a network. Examples of remote communication abilities include using a mobile phone (wireless) network, a wireless data network (e.g., 3G, 4G, or similar network), Wi-Fi, Wi-Max, or any other communication medium that can provide access to a network, such as the Internet or a private network. Examples of user devices include a mobile phone (e.g., a cellular phone), a PDA, a tablet computer, a netbook, a notebook computer, a personal music player, a hand-held specialized reader, and the like. Other examples of user devices include wearable devices, such as a smart watch, a fitness band, an ankle bracelet, a ring, an earring, and the like, as well as a car with remote communication capabilities. A user device can include any suitable hardware and software for performing such functions, and can also include multiple devices or components (e.g., two devices linked together can be considered a single user device when the devices are able to access a network remotely by sharing to another device over a network - i.e., using the other device as a modem).

[0028] A "payment device" can include any suitable device that can be used to conduct a financial transaction, e.g., to provide payment credentials to a merchant. In some embodiments, a payment device can be an example of a user device. A payment device can be a software object, a hardware object, or a physical object. As an example of a physical object, a payment device can include a substrate (e.g., a paper or plastic card), and information printed, embossed, encoded, or otherwise included at or near a surface of the object. A hardware object can involve circuitry (e.g., a permanent voltage value), while a software object can involve non-permanent data stored on the device. A payment device can be used to conduct a payment transaction. Suitable payment devices can be hand-held and compact so that they can fit into a user's wallet and / or pocket (e.g., can be pocket-sized). Examples of payment devices can include smart cards, magnetic stripe cards, keychain devices, etc. If a payment device is in the form of a debit card, credit card, or smart card, the payment device can also optionally have features such as a magnetic stripe. Such devices can operate in a contact or contactless mode. In some embodiments, a user device can function as a payment device (e.g., a mobile device can store and be able to transmit payment credentials for a transaction).

[0029] A "payment credential" can include any suitable information associated with an account (e.g., a payment account and / or a payment device associated with an account). Such information can be directly related to an account or can be derived from information related to an account. Examples of account information can include a PAN (primary account number or "account number"), a user name, an expiration date, a CVV (card verification value), a dCVV (dynamic card verification value), a CVV2 (card verification value 2), a CVC3 card verification value, and the like. A CVV2 is generally understood to be a static verification value associated with a payment device. A CVV2 value is typically visible to a user (e.g., a consumer), while CVV and dCVV values are typically embedded in memory or authorization request messages, not readily known by a user (although they are known to an issuer and payment processor). A payment credential can be any information that identifies a payment account or is associated with a payment account. A payment credential can be provided in order to make a payment from a payment account. A payment credential can also include a user name, an expiration date, a gift card number or code, and any other suitable information.

[0030] A "user" can include an individual. In some embodiments, a user can be associated with one or more personal accounts and / or mobile devices. A user can also be referred to as a cardholder, an account holder, or a consumer.

[0031] A "cache" may include any suitable local memory (e.g., random access memory (RAM)) accessible to a processor. For example, a cache may include RAM directly communicatively coupled to the processor, such as onboard memory. The processor can access cached data more quickly than data stored on a hard drive (e.g., disk storage) or remote storage such as local memory (e.g., RAM) and / or disk storage of another computer and / or system. In some embodiments, a "cache" may be a data repository that stores data (e.g., historical transaction data) predicted to be utilized within a threshold future time period (e.g., the next 24 hours, the next week, etc.). The data in the cache may be deleted and / or updated periodically (e.g., hourly, daily, etc.) so that it can be refreshed based at least in part on newly determined predictions. In some embodiments, a cache may hold historical transaction data for a small number of accounts (e.g., fewer than 100 or fewer than 10). In some embodiments, these accounts may be the largest number of accounts predicted to be utilized within a given future time period. A "cache" may be distinct from a "historical transaction database."

[0032] A "historical transaction database" may include a database of transaction data for many accounts (e.g., more than 1,000, 10,000, 100,000, 1 million, etc.), and the transaction data may be permanently stored in the database. If data is purged from the historical transaction database, it may be purged after a long period of time (e.g., more than 1, 5, 10 years of transactions, etc.). The historical transaction database may utilize disk storage on the same device as the cache, or local and / or disk storage on one or more devices that are remote from the device providing the cache. Typically, the storage utilized by the historical transaction database is not as fast to access as the cache discussed herein.

[0033] A "risk score" may include a value associated with an amount of risk. In some embodiments, a risk score may include an arbitrary designation or ranking representing the risk that a transaction may be fraudulent. A risk score may be represented by a number (and any scale), a probability, or any other relevant way of conveying such information.

[0034] A "resource provider" can be an entity that can provide resources such as goods, services, information, and / or access. Examples of resource providers include merchants, access devices, secure data access points, and the like. A "merchant" can generally be an entity that participates in a transaction and can sell goods or services or provide access to goods or services. A resource provider can operate a computer to perform operations, which can also be generally referred to as a "resource provider computer."

[0035] An "acquirer" can generally be a business entity (e.g., a commercial bank) that has a business relationship with a particular merchant or other entity. Some entities can perform the functions of both an issuer and an acquirer. Some embodiments can encompass such single entity issuer-acquirers. An acquirer can operate an acquirer computer, which can also be generally referred to as a "transport computer."

[0036] An "authorization entity" can be an entity that authorizes a request. Examples of an authorization entity can be an issuer, a government agency, a document repository, an access administrator, etc. An "issuer" can generally refer to a business entity (e.g., a bank) that maintains an account for a user. An issuer can also issue payment credentials to a consumer that are stored on a user device such as a cellular phone, a smart card, a tablet computer, or a laptop computer. An authorization entity can operate a computer to perform operations, which can also be generally referred to as an "authorization entity computer."

[0037] An "access device" can be any suitable device that provides access to a remote system. An access device can also be used to communicate with a merchant computer, a transaction processing computer, an authentication computer, or any other suitable system. An access device can generally be located at any suitable location, such as at a location where a merchant is located. An access device can take any suitable form. Some examples of access devices include a POS or point-of-sale device (e.g., a POS terminal), a cellular phone, a PDA, a personal computer (PC), a tablet PC, a hand-held specialized reader, a set-top box, an electronic cash register (ECR), an automated teller machine (ATM), a virtual cash register (VCR), a kiosk, a security system, an access system, etc. An access device can use any suitable contact or contactless mode of operation to send data to or receive data from a user mobile device or associated with a user mobile device. In some embodiments where an access device can include a POS terminal, any suitable POS terminal can be used and can include a reader, a processor, and a computer- readable medium. The reader can include any suitable contact or contactless mode of operation. For example, an exemplary card reader can include a radio frequency (RF) antenna, an optical scanner, a bar code reader, or a magnetic stripe reader to interact with a payment device and / or a mobile device. In some embodiments, a cellular phone, tablet, or other specialized wireless device used as a POS terminal can be referred to as a mobile point-of-sale or "mPOS" terminal.

[0038] An "authorization request message" can be an electronic message requesting authorization for a transaction. In some embodiments, an authorization request message is sent to a transaction processing computer and / or an issuer of a payment card to request authorization for a transaction. An authorization request message according to some embodiments can comply with ISO 8583, which is a standard for systems that exchange electronic transaction information associated with payments made by users using payment devices or payment accounts. An authorization request message can include an issuer account identifier that can be associated with a payment device or payment account. An authorization request message can also include additional data elements corresponding to "transaction data," including, by way of example only: a service code, a CVV (card verification value), a dCVV (dynamic card verification value), a PAN (primary account number or "account number"), a payment token, a user name, an expiration date, and so forth. An authorization request message can include additional "transaction data," such as any information associated with a current transaction, such as a transaction amount, a merchant identifier, a merchant location, an acquirer bank identification number (BIN), a card acceptor ID, information identifying items purchased, and so forth, as well as any other information that can be used to determine whether to identify and / or authorize a transaction.

[0039] An "authorization response message" can be a message in response to an authorization request. In some cases, an authorization response message can be an electronic message reply generated by an issuing financial institution or a transaction processing computer to an authorization request message. By way of example only, an authorization response message can include one or more of the following status indicators: approved - the transaction was approved; declined - the transaction was not approved; or call center - more information is pending a response, the merchant must call a toll-free authorization phone number. An authorization response message can also include an authorization code, which can be a code returned by a credit card issuing bank to a merchant's access device (e.g., a POS device) in response to an authorization request message in an electronic message (directly or through a transaction processing computer) indicating that a transaction was approved. The code can serve as proof of authorization. As noted above, in some embodiments, a transaction processing computer can generate or forward an authorization response message to a merchant.

[0040] A "server computer" can include a powerful computer or cluster of computers. For example, the server computer can be a large mainframe, a minicomputer cluster, or a group of servers working in concert. In one example, the server computer can be a database server coupled to a Web server. The server computer can be coupled to a database and can include any hardware, software, other logic, or combination of the preceding for servicing the requests from one or more client computers. The server computer can comprise one or more computational apparatuses and can use any of a variety of computer structures, arrangements, and compilations for servicing the requests from one or more client computers.

[0041] Figure 1A block diagram of a system 100 for performing transactions with a cache is shown. The system 100 includes a plurality of components. The system 100 can include a user device 102, which can be associated with a user 103, an access device 110, a resource provider computer 112, a transport computer 114, a processing network computer 116 including a cache 116A, a historical data database 117, and an authorizing entity computer 120. For simplicity of illustration, Figure 1 A certain number of components are shown in the Figure 1 However, it should be appreciated that for each component, embodiments of the application can include more than one. Further, some embodiments of the application can include fewer than all of the components shown in Figure 1 The components in the

[0042] The user device 102, the access device 110, the resource provider computer 112, the transport computer 114, the processing network computer 116, and the authorizing entity computer 120 can all be in operative communication with each other by way of any suitable communication channel or communication network. Suitable communication networks can be any one and / or combination of: a direct interconnection; the Internet; a Local Area Network (LAN); a Metropolitan Area Network (MAN); an Operating Missions as Nodes on the Internet (OMNI); a secured custom connection; a Wide Area Network (WAN); a wireless network (e.g., employing protocols such as, but not limited to, Wi-Fi, Bluetooth, Zigbee, Z-Wave, and / or the like); and / or the like.

[0043] Messages between computers, networks, and devices can be transmitted using a secure communication protocol such as, but not limited to: File Transfer Protocol (FTP); HyperText Transfer Protocol (HTTP); Secure Hypertext Transfer Protocol (HTTPS); Secure Socket Layer (SSL); ISO (e.g., ISO 8583); and / or the like.

[0044] The user 103 can be able to conduct transactions using the user device 102. In some embodiments, the user device 102 can include circuitry to enable certain device functions such as a phone. Functional elements responsible for implementing those functions can include a processor that can execute instructions to implement the functions and operations of the device. The user device 102 can access local memory (or another suitable data storage area or element) to retrieve instructions or data used in executing the instructions. The user device 102 can include data input / output elements such as a keyboard or touch screen that can be used to enable the user to operate the user device 102 and input data. The data input / output elements can also be configured to output data via a speaker and / or display of the user device 102. The user device 102 can also utilize communication elements that can be used to enable data transfer between the user device 102 and a wired or wireless network to facilitate connection to the Internet or other networks and enable data transfer functions.

[0045] In some embodiments, the user device 102 can also include a contactless element interface to enable data transfer between a contactless element (not shown) and other elements of the device, where the contactless element can include a secure memory and a near field communication data transfer element (or another form of short range communication technology). A cellular phone or similar device is an example of a user device 102 that can be used in accordance with embodiments of the present application. However, other forms or types of devices can be used without departing from the essential concepts of the present application. For example, the user device 102 can alternatively be in the form of a payment card, key fob, PDA, tablet computer, netbook, laptop computer, smart watch, etc.

[0046] Access device 110 can include any suitable computing device operated by a resource provider (e.g., a merchant). Access device 110 can include a processor and a computer- readable medium coupled to the processor, the computer-readable medium comprising code, which can be executed by the processor, for performing the functionality described herein. In some embodiments, access device 110 can be used to communicate with user device 102, resource provider computer 112, a processing network computer, or any other suitable device and / or system. In some embodiments, access device 110 can be in any suitable form and can generally be located in any suitable location, such as at a location of a resource provider (e.g., a merchant). Some examples of access devices include POS or point-of-sale devices (e.g., POS terminals), cellular phones, PDAs, personal computers (PCs), tablet PCs, hand-held specialized readers, set-top boxes, electronic cash registers (ECRs), automated teller machines (ATMs), virtual cash registers (VCRs), kiosks, security systems, access systems, and the like. Access device 110 can use any suitable contact or contactless mode of operation to send data to or receive data from user device 102, or to associate with the user device. In some embodiments, access device 110 can include a POS terminal and can include a reader, a processor, and a computer-readable medium. The reader can include any suitable contact or contactless mode of operation. For example, an exemplary card reader can include a radio frequency (RF) antenna, an optical scanner, a bar code reader, or a magnetic stripe reader to interact with payment devices and / or mobile devices. In some embodiments, a cellular phone, tablet, or other specialized wireless device used as a POS terminal can be referred to as a mobile point-of-sale or “mPOS” terminal.

[0047] Resource provider computer 112 can include any suitable computing device operated by or on behalf of a resource provider (e.g., a merchant). Resource provider computer 112 can include a processor and a computer-readable medium coupled to the processor, the computer-readable medium comprising code, which can be executed by the processor, for performing the functionality described below. In some embodiments, resource provider computer 112 can include a web server computer, which can host one or more websites associated with the resource provider. In some embodiments, resource provider computer 112 can be configured to send / receive data (e.g., authorization request messages, authentication response messages, etc.) to / from transport computer 114, processing network computer 116, access device 110, or any suitable component of the system.

[0048] Resource provider computers 112 may be configured to engage in transactions, sell goods or services, or provide access to goods or services to users 103. Resource providers may accept various forms of payment (e.g., payment cards represented by user devices 102) and may use various tools to conduct different types of transactions. For example, a resource provider may operate a brick-and-mortar store and use access devices 110 to conduct in-person transactions. A resource provider may also sell goods and / or services via a website and accept payment over the Internet (e.g., via user devices 102).

[0049] The transport computer 114 may be associated with a business entity (e.g., a commercial bank) that has a business relationship with a particular resource provider (e.g., a merchant) or other entity and may be involved in the transaction process. The transport computer 114 may issue and manage accounts for the resource provider and exchange funds with the authorization entity computer 120 on behalf of the resource provider. Some entities may perform the functions of both the transport computer 114 and the authorization entity computer 120. Embodiments of the present invention encompass such a single entity transport / authorization entity computer. In some embodiments, the transport computer 114 may be configured to send and receive data (e.g., a TAC received in an authorization request message or another message) to and from the processing network computer 116.

[0050] The processing network computer 116 can be configured to process transactions between the user 103 (e.g., utilizing the user device 102) and a resource provider associated with the resource provider computer 112. In some examples, the processing network computer 116 can be configured to perform a settlement process between a transmission computer 114 associated with an acquirer (e.g., a financial institution associated with the resource provider) and an authorization entity computer 120 associated with an authorization entity (e.g., a financial institution associated with the user 103).

[0051] like Figure 1 As shown in FIG, a processing network computer 116 can be positioned between the transmission computer 114 and the authorization entity computer 120. The processing network computer 116 can include data processing subsystems, networks, and operations used to support and deliver authorization services, exception file services, and clearing and settlement services. For example, the processing network computer 116 can include a server coupled to a network interface (e.g., via an external communication interface), and an information database. The processing network computer 116 can represent a transaction processing network. An exemplary transaction processing network can include VisaNet TM For example, VisaNet TM Transaction processing networks such as VisaNet can process credit card transactions, debit card transactions and other types of commercial transactions. TMSpecifically, it includes the VIP system (Visa Integrated Payment System) that processes authorization requests, and the Base II system that performs clearing and settlement services. The processing network computer 116 can use any suitable wired or wireless network, including the Internet.

[0052] In some embodiments, processing network computer 116 may include cache 116A. Cache 116A may include random access memory of any suitable size for processing network computer 116. In some embodiments, processing network computer 116 may be communicatively coupled to a historical data database 117. Historical data database 117 may be configured to store any suitable amount of historical data. In some embodiments, the historical data may include historical transaction data corresponding to any suitable number of user accounts. For example, the historical transaction data may include any portion of past transactions processed by processing network computer 116 over any suitable time period. In some embodiments, historical data database 117 may be operated by a processing network provider, and / or historical data database 117 may be operated on behalf of another entity but accessible to processing network computer 116.

[0053] Authorization entity computer 120 is typically associated with a business entity (e.g., a bank) that issues and maintains user accounts for users (e.g., user 103). The authorization entity may issue payment devices, including credit and debit cards, for user accounts (e.g., consumer accounts) and / or may provide user accounts that are stored and accessible via user device 102. In some embodiments, authorization entity computer 118 may be configured to send and receive data to and from processing network computer 116.

[0054] exist Figure 2 An example of a processing network computer 116 according to an embodiment of the present invention is shown in . The processing network computer 116 may include a cache 116A, a processor 116B, a network interface 116C, and a computer-readable medium 116D.

[0055] The computer readable medium 116D may include several components, such as a processing module 116E, an operation engine 116F, and a prediction engine 116G. More or fewer components are contemplated. It should also be understood that Figure 2 The components depicted in the computer readable medium 116D may be combined to perform the functions described herein. The computer readable medium 116D may also include code that can be executed by the processor 116B to implement the methods discussed herein.

[0056] The processing module 116E can include code that, when executed, causes the processor 116B to send and / or receive authorization request messages and / or authorization response messages from any suitable source to any suitable destination. For example, the processing module 116E can be configured to cause the processor 116B to receive an authorization request message from the transport computer 114. Figure 1 In some embodiments, the processing module 116E can be configured to cause the processor 116B to transmit an authorization request message to any suitable destination, such as the authorization entity computer 120. The processing module 116E can further be configured to receive an authorization response message from any suitable source (e.g., the authorization entity computer 120) and transmit the authorization response message to any suitable destination (e.g., the transport computer 114). Figure 1 In some embodiments, the processing module 116E can be configured to cause the processor 116B to transmit an authorization request message to any suitable destination, such as the authorization entity computer 120. The processing module 116E can further be configured to receive an authorization response message from any suitable source (e.g., the authorization entity computer 120) and transmit the authorization response message to any suitable destination (e.g., the transport computer 114).

[0057] The operations engine 116F can include code that, when executed, causes the processor 116B to perform any suitable operation with at least transaction data included in an authorization request message. In some embodiments, transaction data included in a particular authorization request message (e.g., an account identifier, merchant information such as a merchant and / or location identifier, an amount associated with the transaction, etc.) can be transmitted by the processing module 116E to the operations engine 116F. The operations engine 116F can be configured to perform any suitable operation with such data. For example, the operations engine 116F can be configured to generate a risk score associated with a transaction based at least in part on transaction data provided in an authorization request message.

[0058] In some embodiments, the operations engine 116F can be configured to cause the processor 116B to access the cache 116A to determine whether historical transaction data corresponding to an account used in an authorization request message exists in the cache 116A. If historical transaction data for an account identifier associated with an authorization request message already exists in the cache, the operations engine 116F can be configured to cause the processor 116B to perform additional operations. For example, the operations engine 116F can utilize historical transaction data from the cache 116A and transaction data included in an authorization request message to calculate a risk score for a transaction. The risk score can be calculated utilizing any suitable algorithm for accessing transaction risk. In some embodiments, this risk score can be used along with various other calculated risk scores to ultimately generate a risk analysis for a transaction. The risk score can be included in a reported risk analysis independently (i.e., as a separate, standalone value), or can be merged with other risk scores in an attempt to identify risk based on any suitable combination of transaction data of an authorization request message and / or historical transaction data associated with an account.

[0059] If historical transaction data corresponding to the account identifier of the authorization request message is not included in the cache 116A, the operations engine 116F can be configured to request such data from another source, such as the historical data database 117. The historical data database 117 can be configured to store any suitable amount of historical transaction data associated with any suitable number of account identifiers over any suitable period of time. In some embodiments, the operations engine 116F can request a particular portion of the historical data stored in the historical data database 117. For example, the operations engine 116F can be configured to cause the processor 116B to request historical transaction data corresponding to the account identifier included in the authorization request message over a specified period of time (e.g., the past 24 hours, the past month, the past year, etc.). The operations engine 116F can also be configured to cause the processor 116B to receive the requested historical transaction data from the historical data database 117. The received historical transaction data can then be used to perform any suitable operation, such as calculating a risk score according to any suitable algorithm.

[0060] It should be appreciated that the calculation of the risk score is intended to be illustrative in nature. It is contemplated that the operations engine 116F can perform additional or alternative operations with the historical transaction data. The specific operations performed can vary depending on the type and nature of the historical transaction data and the context in which the operations engine 116F is performing the operations.

[0061] As another non-limiting example, the operations engine 116F can be configured to identify when the received transaction data conflicts with the predicted and indicated data in the cache storage. For instance, the operations engine 116F can be configured to cause the processor 116B to determine that the operations engine 116F has requested data that is not retrievable in the cache 116A (e.g., over a period of time such as the previous hour, the previous day, etc.) more than a threshold number of times. In some embodiments, this determination can cause the operations engine 116F to perform one or more remedial tasks (e.g., provide a notification to the system and / or an administrator, etc.).

[0062] As a non-limiting example, the cache 116A can be configured to store historical transaction data associated with one or more account identifiers determined (e.g., by the prediction engine 116G) to be likely to be accessed in the relatively near future (e.g., within the next 24 hours, within the next 12 hours, etc.). If the operations engine 116F determines that it frequently (e.g., more than a threshold number of times within a given time period) requests data not contained in the cache 116A, the operations engine 116F can be configured with a predetermined set of protocols for identifying one or more remedial actions. In the context of transaction processing, this determination can cause the operations engine 116F to invoke functionality of the prediction engine 116G in order to cause an update of the cache 116A. In some embodiments, the predetermined set of protocols can further identify additional / alternative remedial actions that can cause the operations engine 116F to cause the processor 116B to send a notification (e.g., an email, a text message, or any suitable electronic communication) to any suitable recipient (e.g., an administrator). The notification can indicate, among other things, that data not contained in the cache 116A has been requested from the cache 116A multiple times within a period of time. This notification can enable the recipient to be notified that the system is not accurately predicting the most likely to be used data and / or that a component of the system (e.g., an application programming interface or other communication interface) is malfunctioning.

[0063] In some embodiments, the prediction engine 116G can be configured with code that, when executed, causes the processor 116B to maintain a prediction model. The prediction engine 116G can be configured to cause the processor 116B to train the prediction model at any suitable time with historical transaction data (e.g., at least a portion of the historical transaction data stored in the historical data database 117). Reference will be made to FIG. 2 for a more detailed discussion of the process for training the prediction model. Figure 3 The process for training the prediction model is discussed in more detail. The prediction engine 116G can be configured to cause the processor 116B to identify, at any suitable time, a plurality of account identifiers corresponding to accounts likely to be used in transactions in the relatively near future (e.g., the next 24 hours, the next 12 hours, four days, etc.) with the prediction model. In some embodiments, the prediction engine 116G can cause the processor 116B to input a time period (e.g., the next 24 hours corresponding to a particular date) to the previously trained model. The output of the model can identify a number of account identifiers likely to be utilized (e.g., more than a threshold quantifiable likelihood, such as 95% likelihood) within the given time period. The prediction engine 116G can be configured to cause the processor 116B to obtain a certain portion of historical transaction data corresponding to the identified account identifiers (e.g., the last 24 hours of transaction data for those account identifiers, corresponding transactions in the past year, etc.) once obtained, the prediction engine 116G can be configured to cause the processor 116B to store the obtained data within the cache 116A.

[0064] In some embodiments, the operations engine 116F and / or the prediction engine 116G can be configured to store transaction data corresponding to authorization request messages within the historical data database 117, such that future predictions can be based at least in part on transaction data received in authorization request messages.

[0065] Figure 3 A block diagram 300 is shown illustrating a method for identifying particular data to be cached, according to some embodiments. As described above, the historical data database 117 can be configured to store any suitable amount of historical transaction data associated with any suitable number of account identifiers (e.g., personal account identifiers (PANs) associated with financial accounts). These account identifiers can each be associated with a particular user (e.g., a user 103 of the system 100) on a one-to-one basis. In some embodiments, the historical data database 117 can include the entire account history (e.g., including all transactions) corresponding to each account identifier for which a transaction has previously been processed. In alternative embodiments, the historical data database 117 can be configured to store some portion of the entire account history (e.g., corresponding to transactions made within a particular time period, such as the past six months, the past five years, etc.). In some embodiments, the historical data database 117 can be located remotely from the processing network computers 116 of the system 100, but can be accessible by the prediction engine 116G of the processing network computers 116 at an apparatus via any suitable communication protocol. Figure 1 Figure 1 2

[0066] At step 1, the prediction engine 116G can request training data (e.g., historical transaction data) from the historical data database 117. The request can optionally indicate a time period (e.g., the past five years, the past six months, etc.). If no time period is specified in the request, the request can be considered to apply to all transaction data stored by the historical data database 117.

[0067] At step 2, the historical data database 117 can return the requested historical transaction data to the prediction engine 116G.

[0068] ​​​At step 3, the prediction engine 116G can perform any suitable operations to train the prediction model with historical transaction data received from the historical data database 117. In some embodiments, the prediction model can be trained with any suitable supervised and / or unsupervised machine learning techniques. In supervised learning, the training data (e.g., historical transaction data) can be labeled and / or classified. For example, the historical transaction data can include dates and / or timestamps corresponding to the dates / times that transactions were initiated / processed. Thus, the relationships of the historical transaction data can already be known. In unsupervised learning, the training data (e.g., historical transaction data) can not have been previously labeled, classified, and / or categorized. With unsupervised learning, commonalities in the data can be identified. In unsupervised learning, relationships between elements (e.g., fields of transaction data, such as merchant identifiers, account identifiers, transaction amounts, etc.) can be learned. With supervised or unsupervised learning techniques, the prediction engine 116G can train the prediction model to identify accounts that are likely to be used within a given time period (e.g., the next 24 hours).

[0069] As a specific example, the prediction engine 116G can obtain historical transaction data for the past five years corresponding to all account identifiers associated with any suitable data stored in the historical data database 117. The prediction engine 116G can be preconfigured to train the prediction model to identify accounts that are likely to have transactions occur within a predetermined time period. Additionally or alternatively, the prediction model can be trained to utilize data and / or a time range as input in order to identify accounts that are likely (e.g., above a threshold likelihood, such as a 90% likelihood, a 95% likelihood, etc.) to be used for transactions within a provided date and / or a provided time range. For example, with unsupervised learning techniques, the model can learn that a particular account identifier has historically been used in a given date / time in the past.

[0070] As a non-limiting example, the model can learn that a particular 5% of all account identifiers are attributed to 97% of all transactions performed on a given date in the last year, the previous year, the last five years, etc. In some embodiments, the predictive model can be trained to utilize seasonality, holiday information corresponding to the date of the transaction, demographic information associated with the account holder, or any suitable information associated with the historical transaction data to identify accounts that are likely to be used on a specified date and / or within a specified time period. In some embodiments, the model can be trained to score each account to indicate a likelihood that the account will be used on a specified date and / or within a specified time period. Once scored, a particular number, e.g., the top 50, top 100, top 1000, etc., of the accounts can be identified as the most likely to be used within the given input date and / or time period. In other embodiments, the predictive model can be configured to output any suitable number of accounts that correspond to a likelihood score that equals or exceeds a threshold value. For example, the model can identify any suitable number of accounts that are likely to be used more than a predetermined threshold (e.g., 80% likelihood, 90% likelihood, etc.). In any suitable context, the predictive model can output any suitable number of account identifiers that correspond to accounts that it predicts will be used on a specified date and / or within a specified time period.

[0071] At step 4, the prediction engine 116G can cause the historical transaction data to be stored in the cache 116A. The particular historical transaction data stored in the cache 116A can correspond to the account identifiers identified from the output of the prediction model.

[0072] It will be appreciated that the prediction model can be retrained by the prediction engine 116G at any suitable time. For example, newly received transaction data corresponding to newly received authorization request messages can be added to the historical data database 117 and used to periodically retrain the prediction model as the historical data database 117 is updated or at any suitable time.

[0073] Similarly, it should be appreciated that the prediction engine 116G can be configured to update the cache 116A at any suitable time. For example, the prediction engine 116G can periodically utilize a previously trained prediction model (or a recently retrained prediction model) to ensure that the cache 116A contains historical transaction data corresponding to accounts that are most likely to be used on a given day and / or within a given time period. As a non-limiting example, the prediction engine 116G can be configured to update the cache 116A at 12:01 a.m. each day to include historical transaction data corresponding to accounts that are most likely to be used in transactions that occurred that day (e.g., between 12:01 a.m. and 11:59 p.m. that day). It should be appreciated that the cache 116A can be updated more frequently as needed. Similarly, the cache 116A can be updated less frequently but include historical transaction data over a longer time period (e.g., historical transaction data corresponding to accounts that are likely to be used in the next two days, next week, next month, etc.).

[0074] Figure 4 A block diagram 400 is shown illustrating a method for utilizing a cache (e.g., Figures 1-3 In an embodiment of the present invention, the method of performing data calculations can be performed in sequence or in any suitable order. Figure 4 In some embodiments, one or more steps may be optional.

[0075] In step 1, an authorization request message may be received by the operation engine 116F. In some embodiments, the authorization request message may be received by the operation engine 116F. Figure 2 The authorization request message is received by the processing module 116E or directly by the operation engine 116F. The authorization request message may include any suitable transaction data, such as, but not limited to, an account identifier (e.g., PAN), date, time, merchant identifier (e.g., name, address, merchant-specific alphanumeric identifier, etc.), transaction amount, etc.

[0076] In step 2, the operation engine 116F may determine whether to store historical transaction data corresponding to the account identifier included in the authorization request message in the cache 116A. Figure 3 The described caching process is performed before receiving the authorization request message, and such historical transaction data may exist in cache 116A. If the historical transaction data corresponding to the account identifier included in the authorization request message is stored in cache 116A, the method can proceed to step 4.

[0077] At step 3, if historical transaction data associated with the account identifier included in the authorization request message is not stored in the cache 116A, the operations engine 116F can be configured to request such historical transaction data from the historical data database 117. In some embodiments, the request provided at step 3 can identify the particular account identifier for which historical transaction data is requested. The request can optionally include a time period to which the historical transaction data relates. That is, the request can indicate that historical transaction data for transactions conducted using the account identifier in the past six months, the past five years, etc. is requested. In some embodiments, the request can not specify a particular time period. Thus, the historical data database 117 can be configured to provide all known historical transaction data for the account in response to such a request.

[0078] At step 4, any suitable operation can be performed with the historical transaction data obtained (from the cache 116A or from the historical data database 117, depending on steps 2 and 3 described above). As discussed herein, the historical transaction data can be used to calculate a risk score for the authorization request message. In some embodiments, the operations engine 116F can be configured to cause the authorization request message to be declined when the risk score equals or exceeds a threshold. Any suitable operation can be performed by the operations engine 116F, not necessarily involving a risk score. The particular operation performed with the obtained historical transaction data can vary based on the particular transaction type and the context in which the transaction is performed. Thus, similar caching techniques can be used in a variety of contexts other than transaction processing, and the operations engine 116F can perform any suitable operation using historical transaction data applicable in a given context.

[0079] At step 5, the operations engine 116F can be configured to decline the authorization request message, or forward the authorization request message to another system for further processing, based at least in part on the calculated risk score.

[0080] For example, if the authorization request message is forwarded (e.g., due to the risk score being below a threshold), it can be forwarded to Figure 1 an authorizing entity computer 120 for further processing. Referring back to Figure 1 , the authorization request message can be further processed by the authorizing entity computer 120, which can approve or decline the authorization request based on conventional transaction processing associated with the authorizing entity. An authorization response message can be provided from the authorizing entity computer 120 and forwarded to the transport computer 114 via the processing network computer 116. In turn, the transport computer 114 can forward the authorization response message to the resource provider computer 112 and / or the access device 110 in order to indicate (e.g., to the user 103 via the access device 110 and / or the user device 102) that the transaction was approved or declined. Clearing and settlement processes can be performed at a later time in accordance with conventional clearing and settlement methods.

[0081] Return Figure 4 The transaction data received at step 1 can be provided to the historical data database 117 at any suitable time for use in future operations. For example, at step 6, the transaction data can be provided by the operations engine 116F to the historical data database 117 over any suitable communication protocol, and the transaction data can be stored there for future use. The operations of step 6 can be performed at any suitable time. For example, upon receiving the authorization request message in step 1, after the operations of step 4 are complete, upon forwarding the authorization request message in step 5, or at any suitable time, the transaction data can be forwarded to the historical data database 117.

[0082] As briefly described above, the process for updating the cache 116A can be performed at any suitable time, the same as the process for retraining the prediction model maintained by the prediction engine 116G. For example, the operations engine 116F can incentivize the prediction engine 116G to update the cache 116A and / or retrain the prediction model at step 7. Alternatively, the process for updating the cache 116A and / or the process for retraining the prediction model can occur at any suitable time using the prediction engine 116G. If incentivized by the operations engine 116F, the incentivization can include any suitable request provided from the operations engine 116F to the prediction engine 116G.

[0083] At step 8, in response to a request provided by the operations engine 116F, the prediction engine 116G can periodically request historical transaction data from the historical data database 117 according to a schedule or otherwise. The historical data database 117 can be configured to return some portion of the stored historical transaction data (e.g., all historical transaction data, historical transaction data corresponding to the past six months, five years, etc.). Upon receipt, the prediction engine 116G can optionally retrain the prediction model using the obtained historical transaction data. Using the prediction model, the prediction engine 116G can be configured to identify a plurality of account identifiers corresponding to accounts likely to be used on a given date and / or within a given time period. For example, the prediction engine 116G can provide the historical transaction data, along with a date and / or a time period, as input to the prediction model in order to receive, as output, a plurality of account identifiers corresponding to accounts likely to be used on the provided date or within the provided time period.

[0084] At step 9, the prediction engine 116G can identify, as output, particular historical transaction data associated with the account identifiers identified by the prediction model. Once identified, the particular historical transaction data corresponding to those account identifiers can be stored by the prediction engine 116G within the cache 116A. Thus, upon the operations engine 116F receiving an authorization request message including one of these account identifiers, the operations engine 116F can retrieve the corresponding historical transaction data from the cache 116A much more quickly than from the historical data database 117.

[0085] Figure 5 A flowchart is shown illustrating a method 500 for performing data operations in accordance with some embodiments. The method 500 can be performed in any suitable order. More or fewer operations can be performed within the method 500.

[0086] The method 500 can begin at 502, where an authorization request message can be received (e.g., by the operations engine 116F via the processing module 116E of the processing network computer 116). In some embodiments, the authorization request message can be for a transaction associated with an account. The authorization request message can include an account identifier associated with the account and any suitable transaction data associated with the transaction (e.g., merchant identifier, date, time, transaction amount, etc.). Figure 2

[0087] At 504, it can be determined (e.g., by the operations engine 116F) whether historical transaction data associated with the account is stored in a cache (e.g., the cache 116A) accessible to the computing device (e.g., the processing network computer 116). In some embodiments, the operations engine 116F can be configured to utilize the account identifier of the authorization request message to determine whether historical transaction data for that account identifier is stored within the cache 116A. If the historical transaction data for the account identifier is stored within the cache 116A, the method can proceed to 506. If the historical transaction data for the account identifier is not stored within the cache 116A, the method can proceed to 510.

[0088] At 506, the historical transaction data associated with the account can be retrieved (e.g., by the operations engine 116F) from the cache 116A. As discussed above, this historical transaction data can include any suitable number of transactions associated with the account identifier. For some embodiments, the historical transaction data can correspond to transactions conducted in the past year, the past five years, the past 10 years, etc. While in other embodiments, the historical transaction data can correspond to all known transactions associated with the account.

[0089] ​At 508, at least one operation can be performed (e.g., by the operation engine 116F) in response to receiving the authorization request message. In some embodiments, the at least one operation can utilize the historical transaction data retrieved from the cache 116A.

[0090] However, if the historical transaction data is not stored within the cache 116A, the method 500 can proceed from 504 to 510, where the historical transaction data associated with the account can be retrieved (e.g., by the operation engine 116F) from a historical transaction database (e.g., the historical data database 117 of the above figure). The historical transaction data can again include any suitable amount of transactions associated with the account identifier (e.g., historical transaction data corresponding to transactions made within a certain previous time period, all known historical transaction data, etc.).

[0091] At 512, at least one operation can be performed (e.g., by the operation engine 116F) in response to receiving the authorization request message. In some embodiments, the at least one operation can utilize the historical transaction data retrieved from the historical transaction database.

[0092] Technical Advantages

[0093] Embodiments of the present invention have several advantages. For example, with the techniques discussed above, historical transaction data that can be needed to perform various operations (e.g., calculating a risk score) can be identified, aggregated, and stored within a cache prior to receiving an authorization request message associated with an account. By identifying the historical transaction data (e.g., utilizing a predictive model), the processing time needed to perform these operations and / or process the authorization request message is reduced relative to conventional systems. The cache can provide faster access to the historical transaction data as compared to a historical transaction database that is remote relative to the processing system. As a result, the historical transaction data of the cache can be accessed more quickly, which in turn can result in faster processing times and reduced latency of the system as a whole. Additionally, by utilizing a predictive model to identify particular historical transaction data, the system can maintain a relatively small amount of data within the cache 116A. The predictive model can be used to identify account identifiers that correspond to accounts that are likely to be used on a particular date and / or within a particular time period. The system can selectively store only the historical transaction data corresponding to those identified accounts within the cache. This can enable the system to maintain only the information that is likely to be needed within the cache and avoid unnecessary storage of extraneous information within the cache. This can also improve the performance of the system by increasing the likelihood that the cache does not contain extraneous data that is unlikely to be used within a particular future time period.

[0094] Any computing device described herein can be an example of a computer system that can be used to implement any of the above-mentioned entities or components. The subsystems of such computer systems can be interconnected via a system bus. Additional subsystems include a printer, a keyboard, a storage device, and a monitor that is coupled to a display adapter. Peripheral devices and input / output (I / O) devices are coupled to an I / O controller and can be connected to the computer system by any of many means known in the art (e.g., a serial port). For example, an I / O port or external interface can be used to connect a computer device to a wide area network (e.g., the Internet), a mouse input device, or a scanner. Interconnection via a system bus can allow a central processing unit to communicate with each subsystem and control the execution of instructions from a system memory or storage device, as well as information exchange between subsystems. System memory and / or storage device can embody computer-readable media.

[0095] As described, the services of the present invention may involve implementing one or more functions, processes, operations, or method steps. In some embodiments, the functions, processes, operations, or method steps may be implemented as a result of executing an instruction set or software code by a suitably programmed computing device, microprocessor, data processor, or the like. The instruction set or software code may be stored in a memory or other form of data storage element accessed by the computing device, microprocessor, or the like. In other embodiments, the functions, processes, operations, or method steps may be implemented by firmware, a dedicated processor, an integrated circuit, or the like.

[0096] Any software component or function described in this application can be implemented as a software code executed by a processor using any suitable computer language, such as Java, C++, or Perl using conventional or object-oriented techniques. The software code can be stored as a series of instructions or commands on a computer-readable medium, such as a random access memory (RAM), a read-only memory (ROM), a magnetic medium such as a hard drive or a floppy disk, or an optical medium such as a CD-ROM. Any such computer-readable medium can reside on or inside a single computing device and can be present on or inside different computing devices within a system or network.

[0097] While certain exemplary embodiments have been described in detail and shown in the drawings, it is to be understood that such embodiments are merely illustrative and not restrictive of the invention, and that the invention is not limited to the specific arrangements and constructions shown and described, since various other modifications may occur to those skilled in the art.

[0098] As used herein, the use of "a," "an," or "the" is intended to mean "at least one" unless clearly indicated to the contrary.

Claims

1. A computer-implemented method comprising: sending, by the computing device, an authorization request message for an interaction associated with the account to the server computer; This causes the server computer to: determining whether historical data associated with the account is stored in a cache, wherein the historical data is stored in the cache based on identifying one or more accounts from a plurality of accounts that are predicted to be likely to be used for one or more interactions within a future time period using a prediction model, wherein the server computer periodically updates the cache by: identifying, using a predictive model, one or more accounts from a plurality of accounts, the one or more accounts identified by the predictive model as likely to be used to perform one or more interactions within a future time period, the predictive model being trained at least in part based on historical data associated with the plurality of accounts, the historical data identifying a number of the plurality of accounts that have been historically utilized within a particular historical time period, wherein the number of the plurality of accounts is determined to have performed more than a threshold percentage of the interactions that occurred within the particular historical time period; Retrieving, by the computing device, a portion of the historical data from a data repository, the portion of the historical data corresponding to interactions performed using the identified one or more accounts; as well as storing the portion of the historical data in the cache, When the historical data is stored in the cache, retrieving the historical data associated with the account from the cache, and When the historical data is not stored in the cache, obtaining the historical data associated with the account from a history database; receiving, by the computing device, from the server computer, an authorization response message based on the historical data; as well as The interaction is completed based on the authorization response message.

2. The method according to claim 1, wherein: The predictive model is trained using unsupervised machine learning techniques.

3. The method of claim 1 , wherein the server computer further: The historical data is updated using data associated with the authorization request message, wherein the predictive model is updated based at least in part on the updated historical data.

4. The method according to claim 1, wherein: In response to receiving the authorization request message, the server computer calculates a risk score for the authorization request message using the historical data, and the authorization response message includes the risk score.

5. The method of claim 4, wherein the predictive model is trained based on the historical data to identify the accounts that are likely to be utilized in the future time period using seasons, holiday information corresponding to interaction dates, and demographic information associated with account holders.

6. A computer-implemented method comprising: The computing device periodically updates the cache of the computing device by the following steps: identifying, by the computing device, one or more accounts from a plurality of accounts, the one or more accounts identified by the predictive model as likely to be used to perform one or more interactions within a future time period, the predictive model being trained at least in part based on historical data associated with the plurality of accounts, the historical data identifying a number of the plurality of accounts that have been historically utilized within a particular historical time period, wherein the number of the plurality of accounts is determined to have performed more than a threshold percentage of the interactions that occurred within the particular historical time period; Retrieving, by the computing device, a portion of the historical data from a data repository, the portion of the historical data corresponding to interactions performed using the identified one or more accounts; as well as Storing the portion of the historical data in the cache of the computing device receiving, by the computing device over a communication network, an authorization request message for an interaction associated with an account; determining whether historical data associated with the account is stored in the cache accessible to the computing device; When the historical data is stored in the cache: retrieving, by the computing device, the historical data associated with the account from the cache; as well as performing, by the computing device in response to receiving the authorization request message, at least one operation, the at least one operation utilizing the retrieved history data; as well as When the historical data is not stored in the cache: obtaining, by the computing device, the historical data associated with the account from a database; as well as At least one operation is performed by the computing device in response to receiving the authorization request message, the at least one operation utilizing the historical data obtained from the database.

7. The computer-implemented method of claim 6, further comprising updating the historical data with data associated with an authorization request message, wherein the predictive model is updated based at least in part on the updated historical data.

8. The computer-implemented method of claim 6, further comprising updating the historical data with data from the authorization request message, wherein the one or more accounts are identified from the plurality of accounts after the historical data is updated with the data.

9. The computer-implemented method of claim 6, wherein the at least one operation comprises calculating a risk score for the authorization request message.

10. The computer-implemented method of claim 6, wherein the computing device is a processing network computer.

11. A computer comprising: processor; as well as A computer-readable medium comprising code executable by the processor for implementing the method of any one of claims 1-10.

12. A computer program product comprising code executable to implement the method according to any one of claims 1 to 10.

Images