Systems, methods, and computer program products for real-time change detection

Abstract

A system, method, and computer program product for real-time change detection are described. The system includes at least one processor configured to receive transaction data associated with a transaction associated with an entity, and determine an aggregate value based on a portion of the transaction data for the transaction. The at least one processor is further configured to generate a predicted aggregate value for the entity by inputting historical transaction data associated with a plurality of historical transactions associated with the entity into the machine learning model. The at least one processor is further configured to determine a deviation of the aggregate value from the predicted aggregate value, and compare the deviation to a dynamic threshold associated with the entity. The at least one processor is further configured to, in response to determining that the deviation satisfies the dynamic threshold, trigger a risk mitigation process associated with the entity.

Description

[0001] Cross-reference to related applications

[0002] This application claims priority to U.S. Provisional Patent Application No. 63 / 434,962, filed on December 23, 2022, the disclosure of which is incorporated herein by reference in its entirety. Technical Field

[0003] The present disclosure relates generally to change detection in networked systems and, in some non-limiting embodiments or aspects, to systems, methods, and computer program products for real-time change detection of network activity based on entity-level historical behavior. Background Art

[0004] Systems that detect changes in entity activity (e.g., deviations, outliers, etc.) may suffer from an increased incidence of false positives due to personal entities exhibiting behavior (e.g., activity patterns) in a network that is normal (e.g., typical) for the personal entity but generally abnormal (e.g., atypical) for entities that share one or more characteristics with the personal entity. Consequently, such systems may incorrectly identify normal behavior of the personal entity as abnormal. Similarly, such systems may also suffer from an increased incidence of false positives due to personal entities exhibiting behavior in a network that is abnormal for the personal entity but generally normal for entities that share one or more characteristics with the personal entity. Consequently, such systems may incorrectly identify abnormal behavior of the personal entity as normal.

[0005] Furthermore, what is considered normal for an entity can change over time. For example, network behavior that is normal for an individual entity during one time period may not necessarily be normal for the same entity during a later time period. Consequently, false positives and false negatives resulting from personalized behavior are further exacerbated as personalized behavior changes over time. Furthermore, existing solutions may be unable to adapt to changes in entity activity in a timely manner.

[0006] There is a need in the art for a technical solution to more accurately identify changes in entity-level activity, including dynamically adjusting thresholds to detect changes in activity in real time and over time. Summary of the Invention

[0007] Thus, improved systems, methods, and computer program products are provided for real-time change detection.

[0008] According to some non-limiting embodiments or aspects, a system for real-time change detection is provided. The system includes at least one processor configured to receive transaction data associated with at least one transaction associated with an entity. The at least one processor is further configured to determine at least one aggregate value based on at least a portion of the transaction data of the at least one transaction. The at least one processor is further configured to generate at least one predicted aggregate value for the entity by inputting historical transaction data associated with multiple historical transactions associated with the entity into a machine learning model. The at least one processor is further configured to determine a deviation of the at least one aggregate value from the at least one predicted aggregate value. The at least one processor is further configured to compare the deviation with a dynamic threshold associated with the entity. The at least one processor is further configured to trigger at least one risk mitigation process associated with the entity in response to determining that the deviation meets the dynamic threshold.

[0009] In some non-limiting embodiments or aspects, when receiving the transaction data associated with the at least one transaction, the at least one processor may be configured to receive the transaction data associated with the at least one transaction within a first time period. The at least one processor may also be configured to receive the historical transaction data associated with the plurality of historical transactions within a training time period prior to the first time period. The at least one processor may also be configured to determine at least one historical aggregate value based on at least a portion of the historical transaction data for the plurality of historical transactions, based on a type of entity associated with the plurality of historical transactions. The at least one processor may also be configured to train the machine learning model using the at least one historical aggregate value, wherein the machine learning model is configured to predict at least one future value of the transaction data for future transactions.

[0010] In some non-limiting embodiments or aspects, the type of entity may include at least one of: a transaction account, a merchant, an acquirer, an issuer, or any combination thereof. The at least one risk mitigation process may include at least one of: temporarily denying future transactions associated with the entity, transmitting an alert to the entity, temporarily disabling system access to the entity, or any combination thereof.

[0011] In some non-limiting embodiments or aspects, the at least one processor may be further configured to automatically and periodically update the dynamic threshold based on ongoing transactions associated with the entity. The deviation may be based at least in part on a moving standard deviation. When updating the dynamic threshold based on the ongoing transactions associated with the entity, the at least one processor may be configured to: determine the deviation between the at least one aggregate value and the at least one predicted aggregate value within each sub-period of a time period during which the ongoing transactions are completed, to generate a plurality of deviations; and update the dynamic threshold after each sub-period of the time period based at least in part on a maximum value of the plurality of deviations.

[0012] In some non-limiting embodiments or aspects, the at least one processor may be further configured to retrain the machine learning model based on the ongoing transactions to generate an updated machine learning model. Upon determining the deviation of the at least one aggregated value from the at least one predicted aggregated value within each sub-period of the time period, the at least one processor may be configured to regenerate the at least one predicted aggregated value for the entity based on the updated machine learning model.

[0013] According to some non-limiting embodiments or aspects, a method for real-time change detection is provided. The method may include receiving, using at least one processor, transaction data associated with at least one transaction associated with an entity; the method further includes determining, using at least one processor, at least one aggregate value based on at least a portion of the transaction data for the at least one transaction. The method further includes generating, using at least one processor, at least one predicted aggregate value for the entity by inputting historical transaction data associated with a plurality of historical transactions associated with the entity into a machine learning model. The method further includes determining, using at least one processor, a deviation of the at least one aggregate value from the at least one predicted aggregate value. The method further includes comparing, using at least one processor, the deviation to a dynamic threshold associated with the entity. The method further includes triggering, using at least one processor, at least one risk mitigation process associated with the entity in response to determining that the deviation meets the dynamic threshold.

[0014] In some non-limiting embodiments or aspects, receiving the transaction data associated with the at least one transaction may include receiving the transaction data associated with the at least one transaction within a first time period. The method may further include receiving, using at least one processor, the historical transaction data associated with the plurality of historical transactions within a training time period prior to the first time period. The method may further include determining, using at least one processor, at least one historical aggregate value based on at least a portion of the historical transaction data for the plurality of historical transactions based on a type of entity associated with the plurality of historical transactions. The method may further include training, using at least one processor, the machine learning model with the at least one historical aggregate value, wherein the machine learning model is configured to predict at least one future value of the transaction data for future transactions.

[0015] In some non-limiting embodiments or aspects, the type of entity may include at least one of: a transaction account, a merchant, an acquirer, an issuer, or any combination thereof. The at least one risk mitigation process may include at least one of: temporarily denying future transactions associated with the entity, transmitting an alert to the entity, temporarily disabling system access to the entity, or any combination thereof.

[0016] In some non-limiting embodiments or aspects, the method may further include automatically and periodically updating, using at least one processor, the dynamic threshold value based on ongoing transactions associated with the entity. The deviation may be based at least in part on a moving standard deviation, and updating the dynamic threshold value based on the ongoing transactions associated with the entity may include: determining the deviation of the at least one aggregate value from the at least one predicted aggregate value within each sub-period of a time period during which the ongoing transactions are completed to generate a plurality of deviations; and updating the dynamic threshold value after each sub-period of the time period based at least in part on a maximum value of the plurality of deviations.

[0017] In some non-limiting embodiments or aspects, the method may further include retraining, using at least one processor, the machine learning model based on the ongoing transactions to generate an updated machine learning model. Determining the deviation of the at least one aggregated value from the at least one predicted aggregated value within each sub-period of the time period may further include regenerating the at least one predicted aggregated value for the entity during the time period based on the updated machine learning model.

[0018] In some non-limiting embodiments or aspects, the machine learning model may include a long short-term memory (LSTM) model.

[0019] According to some non-limiting embodiments or aspects, a computer program product for real-time change detection is provided. The computer program product may include at least one non-transitory computer-readable medium, the at least one non-transitory computer-readable medium including program instructions that, when executed by at least one processor, cause the at least one processor to receive transaction data associated with at least one transaction associated with an entity. The program instructions further cause the at least one processor to determine at least one aggregate value based on at least a portion of the transaction data for the at least one transaction. The program instructions further cause the at least one processor to generate at least one predicted aggregate value for the entity by inputting historical transaction data associated with a plurality of historical transactions associated with the entity into a machine learning model. The program instructions further cause the at least one processor to determine a deviation between the at least one aggregate value and the at least one predicted aggregate value. The program instructions further cause the at least one processor to compare the deviation to a dynamic threshold associated with the entity. The program instructions further cause the at least one processor to trigger at least one risk mitigation process associated with the entity in response to determining that the deviation meets the dynamic threshold.

[0020] In some non-limiting embodiments or aspects, the program instructions that cause the at least one processor to receive the transaction data associated with the at least one transaction may cause the at least one processor to receive the transaction data associated with the at least one transaction within a first time period. The program instructions may also cause the at least one processor to receive the historical transaction data associated with the plurality of historical transactions within a training time period prior to the first time period. The program instructions may also cause the at least one processor to determine at least one historical aggregate value based on at least a portion of the historical transaction data for the plurality of historical transactions, based on a type of entity associated with the plurality of historical transactions. The program instructions may also cause the at least one processor to train the machine learning model with the at least one historical aggregate value, wherein the machine learning model is configured to predict at least one future value of the transaction data for future transactions.

[0021] In some non-limiting embodiments or aspects, the type of entity may include at least one of: a transaction account, a merchant, an acquirer, an issuer, or any combination thereof. The at least one risk mitigation process may include at least one of: temporarily denying future transactions associated with the entity, transmitting an alert to the entity, temporarily disabling system access to the entity, or any combination thereof.

[0022] In some non-limiting embodiments or aspects, the program instructions may further cause the at least one processor to automatically and periodically update the dynamic threshold based on ongoing transactions associated with the entity. The deviation may be based at least in part on a moving standard deviation. The program instructions causing the at least one processor to update the dynamic threshold based on the ongoing transactions associated with the entity cause the at least one processor to: determine the deviation between the at least one aggregate value and the at least one predicted aggregate value within each sub-period of a time period during which the ongoing transactions are completed, to generate a plurality of deviations; and update the dynamic threshold after each sub-period of the time period based at least in part on a maximum value of the plurality of deviations.

[0023] In some non-limiting embodiments or aspects, the program instructions may further cause the at least one processor to retrain the machine learning model based on the ongoing transactions to generate an updated machine learning model. The program instructions causing the at least one processor to determine the deviation of the at least one aggregated value from the at least one predicted aggregated value within each sub-period of the time period may cause the at least one processor to regenerate the at least one predicted aggregated value for the entity based on the updated machine learning model.

[0024] Other non-limiting embodiments or aspects are set forth in the following numbered clauses:

[0025] Clause 1: A system comprising at least one processor configured to: receive transaction data associated with at least one transaction associated with an entity; determine at least one aggregate value based on at least a portion of the transaction data for the at least one transaction; generate at least one predicted aggregate value for the entity by inputting historical transaction data associated with a plurality of historical transactions associated with the entity into a machine learning model; determine a deviation of the at least one aggregate value from the at least one predicted aggregate value; compare the deviation to a dynamic threshold associated with the entity; and, in response to determining that the deviation satisfies the dynamic threshold, trigger at least one risk mitigation process associated with the entity.

[0026] Clause 2: A system according to clause 1, wherein, when receiving the transaction data associated with the at least one transaction, the at least one processor is configured to: receive the transaction data associated with the at least one transaction within a first time period; and wherein the at least one processor is further configured to: receive the historical transaction data associated with the multiple historical transactions within a training time period prior to the first time period; determine at least one historical aggregate value based on at least a portion of the historical transaction data of the multiple historical transactions based on a type of entity associated with the multiple historical transactions; and train the machine learning model with the at least one historical aggregate value, wherein the machine learning model is configured to predict at least one future value of the transaction data of future transactions.

[0027] Clause 3: A system according to clause 1 or clause 2, wherein the type of entity includes at least one of: a transaction account, a merchant, an acquirer, an issuer, or any combination thereof; and wherein the at least one risk mitigation process includes at least one of: temporarily denying future transactions associated with the entity, transmitting an alert to the entity, temporarily disabling system access to the entity, or any combination thereof.

[0028] Clause 4: The system of any of clauses 1 to 3, wherein the at least one processor is further configured to automatically and periodically update the dynamic threshold based on ongoing transactions associated with the entity.

[0029] Clause 5: A system according to any one of clauses 1 to 4, wherein the deviation is based at least in part on a moving standard deviation, and wherein when the dynamic threshold is updated based on the ongoing transaction associated with the entity, the at least one processor is configured to: determine the deviation of the at least one aggregate value from the at least one predicted aggregate value within each sub-period of the time period in which the ongoing transaction is completed to produce a plurality of deviations; and update the dynamic threshold after each sub-period of the time period at least in part based on a maximum value of the plurality of deviations.

[0030] Clause 6: A system according to any one of clauses 1 to 5, wherein the at least one processor is further configured to retrain the machine learning model based on the ongoing transaction to produce an updated machine learning model, and wherein when determining the deviation of the at least one aggregate value from the at least one predicted aggregate value within each sub-period of the time period, the at least one processor is configured to: regenerate the at least one predicted aggregate value for the entity based on the updated machine learning model.

[0031] Clause 7: A computer-implemented method comprising: receiving, using at least one processor, transaction data associated with at least one transaction associated with an entity; determining, using at least one processor, at least one aggregate value based on at least a portion of the transaction data for the at least one transaction; generating, using at least one processor, at least one predicted aggregate value for the entity by inputting historical transaction data associated with a plurality of historical transactions associated with the entity into a machine learning model; determining, using at least one processor, a deviation of the at least one aggregate value from the at least one predicted aggregate value; comparing, using at least one processor, the deviation to a dynamic threshold associated with the entity; and triggering, using at least one processor, at least one risk mitigation process associated with the entity in response to determining that the deviation satisfies the dynamic threshold.

[0032] Clause 8: A computer-implemented method according to Clause 7, wherein receiving the transaction data associated with the at least one transaction comprises: receiving the transaction data associated with the at least one transaction within a first time period; the method further comprises: receiving the historical transaction data associated with the multiple historical transactions within a training time period prior to the first time period using at least one processor; determining at least one historical aggregate value based on at least a portion of the historical transaction data of the multiple historical transactions based on a type of entity associated with the multiple historical transactions using the at least one processor; and training the machine learning model using the at least one historical aggregate value using the at least one processor, wherein the machine learning model is configured to predict at least one future value of the transaction data of future transactions.

[0033] Clause 9: The computer-implemented method of clause 7 or clause 8, wherein the type of entity comprises at least one of: a transaction account, a merchant, an acquirer, an issuer, or any combination thereof.

[0034] Clause 10: A computer-implemented method according to any one of clauses 7 to 9, wherein the at least one risk mitigation process comprises at least one of: temporarily denying future transactions associated with the entity, transmitting an alert to the entity, temporarily disabling system access to the entity, or any combination thereof.

[0035] Clause 11: The computer-implemented method of any of clauses 7 to 10, further comprising automatically and periodically updating, with at least one processor, the dynamic threshold based on ongoing transactions associated with the entity.

[0036] Clause 12: A computer-implemented method according to any one of clauses 7 to 11, wherein the deviation is based at least in part on a moving standard deviation, and wherein updating the dynamic threshold based on the ongoing transactions associated with the entity comprises: determining the deviation of the at least one aggregate value from the at least one predicted aggregate value within each sub-period of a time period in which the ongoing transactions are completed to produce a plurality of deviations; and updating the dynamic threshold after each sub-period of the time period at least in part based on a maximum value of the plurality of deviations.

[0037] Clause 13: A computer-implemented method according to any one of clauses 7 to 12, further comprising retraining the machine learning model based on the ongoing transaction using at least one processor to generate an updated machine learning model, wherein determining the deviation of the at least one aggregate value from the at least one predicted aggregate value in each sub-period of the time period further comprises: regenerating the at least one predicted aggregate value of the entity based on the updated machine learning model during the time period.

[0038] Clause 14: The computer-implemented method of any one of clauses 7 to 13, wherein the machine learning model is an LSTM model.

[0039] Clause 15: A computer program product comprising at least one non-transitory computer-readable medium, the non-transitory computer-readable medium comprising program instructions that, when executed by at least one processor, cause the at least one processor to: receive transaction data associated with at least one transaction associated with an entity; determine at least one aggregate value based on at least a portion of the transaction data for the at least one transaction; generate at least one predicted aggregate value for the entity by inputting historical transaction data associated with a plurality of historical transactions associated with the entity into a machine learning model; determine a deviation of the at least one aggregate value from the at least one predicted aggregate value; compare the deviation to a dynamic threshold associated with the entity; and in response to determining that the deviation satisfies the dynamic threshold, trigger at least one risk mitigation process associated with the entity.

[0040] Clause 16: A computer program product according to clause 15, wherein the program instructions that cause the at least one processor to receive the transaction data associated with the at least one transaction cause the at least one processor to: receive the transaction data associated with the at least one transaction within a first time period; and wherein the program instructions also cause the at least one processor to: receive the historical transaction data associated with the multiple historical transactions within a training time period prior to the first time period; determine at least one historical aggregate value based on at least a portion of the historical transaction data of the multiple historical transactions based on a type of entity associated with the multiple historical transactions; and train the machine learning model with the at least one historical aggregate value, wherein the machine learning model is configured to predict at least one future value of the transaction data of future transactions.

[0041] Clause 17: A computer program product according to clause 15 or clause 16, wherein the type of entity comprises at least one of: a transaction account, a merchant, an acquirer, an issuer, or any combination thereof; and wherein the at least one risk mitigation process comprises at least one of: temporarily denying future transactions associated with the entity, transmitting an alert to the entity, temporarily disabling system access to the entity, or any combination thereof.

[0042] Clause 18: The computer program product of any of clauses 15 to 17, wherein the program instructions further cause the at least one processor to automatically and periodically update the dynamic threshold based on ongoing transactions associated with the entity.

[0043] Clause 19: A computer program product according to any one of clauses 15 to 18, wherein the deviation is based at least in part on a moving standard deviation, and wherein the program instructions causing the at least one processor to update the dynamic threshold based on the ongoing transactions associated with the entity cause the at least one processor to: determine the deviation of the at least one aggregate value from the at least one predicted aggregate value within each sub-period of a time period in which the ongoing transactions are completed to produce a plurality of deviations; and update the dynamic threshold after each sub-period of the time period at least in part based on a maximum value of the plurality of deviations.

[0044] Clause 20: A computer program product according to any one of clauses 15 to 19, wherein the program instructions further cause the at least one processor to retrain the machine learning model based on the ongoing transactions to produce an updated machine learning model, and wherein the program instructions that cause the at least one processor to determine the deviation of the at least one aggregate value from the at least one predicted aggregate value in each sub-period of the time period cause the at least one processor to: regenerate the at least one predicted aggregate value for the entity based on the updated machine learning model.

[0045] These and other features and characteristics of the present disclosure, as well as the methods of operation and function of the related structural elements and combinations of parts, and the economies of manufacture, will become more apparent upon consideration of the following description and appended claims with reference to the accompanying drawings, all of which form a part of this specification, wherein like reference numerals designate corresponding parts throughout the several views. It is to be expressly understood, however, that the drawings are for purposes of illustration and description only and are not intended as a definition of the limits of the disclosed subject matter. BRIEF DESCRIPTION OF THE DRAWINGS

[0046] Additional advantages and details of the present disclosure are explained in more detail below with reference to exemplary embodiments or aspects illustrated in the schematic drawings, in which:

[0047] Figure 1 is a schematic diagram of a system for determining real-time change detection according to some non-limiting embodiments or aspects;

[0048] Figure 2 According to some non-limiting embodiments or aspects Figure 1 schematic diagrams of example components of one or more devices;

[0049] Figure 3 is a flow chart of a method for real-time change detection according to some non-limiting embodiments or aspects.

[0050] Figure 4 is a flow chart of a method for real-time change detection according to some non-limiting embodiments or aspects.

[0051] Figure 5 is a flow chart of a method for real-time change detection according to some non-limiting embodiments or aspects; and

[0052] Figure 6 is a data flow diagram of a method and system for real-time change detection according to some non-limiting embodiments or aspects. DETAILED DESCRIPTION

[0053] For purposes of the following description, the terms "end," "upper," "lower," "right," "left," "vertical," "horizontal," "top," "bottom," "lateral," "longitudinal," and their derivatives shall relate to the orientation of the embodiments in the accompanying drawings. However, it shall be understood that the embodiments may employ various alternative variations and step orders, except where expressly specified to the contrary. It shall also be understood that the specific devices and processes illustrated in the accompanying drawings and described in the following specification are merely exemplary embodiments or aspects of the disclosed subject matter. Accordingly, specific dimensions and other physical characteristics related to the embodiments or aspects disclosed herein should not be considered limiting.

[0054] It should be understood that, unless expressly specified to the contrary, the present disclosure may employ various alternative variations and step sequences. It should also be understood that the specific devices and processes shown in the accompanying drawings and described in the following specification are merely exemplary and non-limiting embodiments or aspects. Therefore, specific dimensions and other physical characteristics related to the embodiments or aspects disclosed herein should not be considered limiting.

[0055] Some non-limiting embodiments or aspects are described herein in conjunction with threshold values. As used herein, satisfying a threshold value may refer to a value greater than a threshold value, more than a threshold value, higher than a threshold value, greater than or equal to a threshold value, less than a threshold value, less than a threshold value, lower than a threshold value, less than or equal to a threshold value, equal to a threshold value, etc.

[0056] As used herein, aspects, parts, elements, structures, actions, steps, functions, instructions, etc. should not be understood as being critical or necessary unless explicitly described as such. Furthermore, as used herein, the article "one" is intended to include one or more projects and can be used interchangeably with "one or more" and "at least one". Furthermore, as used herein, the term "set" is intended to include one or more projects (e.g., related projects, unrelated projects, combinations of related projects and unrelated projects, etc.), and can be used interchangeably with "one or more" or "at least one". In the case of wishing only one project, the term "one" or similar language is used. Furthermore, as used herein, the term "having" and / or its analogs are intended to be open terms. Additionally, unless explicitly stated otherwise, the phrase "based on" is intended to mean "at least partially based on". Additionally, reference to an action "based on" a condition may refer to the action being "in response to" the condition. For example, in some non-limiting embodiments or aspects, the phrases "based on" and "in response to" may refer to conditions for automatically triggering an action (e.g., a specific operation of an electronic device such as a computing device, a processor, etc.).

[0057] As used herein, the term "communication" may refer to the reception, acceptance, transmission, transfer, provision, etc. of data (e.g., information, signals, messages, instructions, commands, etc.). When a unit (e.g., a device, a system, a component of a device or system, a combination thereof, and / or the like) communicates with another unit, it means that the unit is able to directly or indirectly receive information from the other unit and / or send information to the other unit. This may refer to a direct or indirect connection (e.g., a direct communication connection, an indirect communication connection, and / or the like) that is wired and / or wireless in nature. In addition, although the information sent may be modified, processed, relayed, and / or routed between a first unit and a second unit, the two units may also communicate with each other. For example, a first unit may communicate with a second unit even if the first unit passively receives information and does not actively send information to the second unit. As another example, a first unit may communicate with a second unit if at least one intermediate unit processes information received from the first unit and transmits the processed information to the second unit. In some non-limiting embodiments or aspects, a message may refer to a network packet (e.g., a data packet, and / or the like) comprising data. It will be appreciated that many other arrangements are possible.

[0058] As used herein, the term "computing device" may refer to one or more electronic devices configured to process data. In some examples, a computing device may include the necessary components to receive, process, and output data, such as a processor, a display, a memory, an input device, a network interface, and / or the like. A computing device may be a mobile device. As an example, a mobile device may include a cellular phone (e.g., a smartphone or a standard cellular phone), a portable computer, a wearable device (e.g., a watch, glasses, lenses, clothing, etc.), a personal digital assistant (PDA), and / or other similar devices. A computing device may also be a desktop computer or other form of non-mobile computer.

[0059] As used herein, the term "server" may refer to or include one or more computing devices operated by or facilitating communications and processing for multiple parties in a network environment such as the Internet, but it should be understood that communications may be facilitated through one or more public or private network environments, and various other arrangements are possible. In addition, multiple computing devices (e.g., servers, point-of-sale (POS) devices, mobile devices, etc.) communicating directly or indirectly in a network environment may constitute a "system."

[0060] As used herein, the term "system" may refer to one or more computing devices or a combination of computing devices (e.g., processors, servers, client devices, software applications, components of such computing devices, etc.). As used herein, references to "device," "server," "processor," etc. may refer to a previously described device, server, or processor that is recited as performing a previous step or function, a different device, server, or processor, and / or a combination of devices, servers, and / or processors. For example, as used in the specification and claims, a first device, first server, or first processor that is recited as performing a first step or a first function may refer to the same or a different device, server, or processor that is recited as performing a second step or a second function.

[0061] As used herein, the term "acquirer" may refer to an entity that is licensed and / or authorized by a transaction service provider to initiate transactions (e.g., payment transactions) using a payment device associated with the transaction service provider. Transactions that an acquirer may initiate may include payment transactions (e.g., purchases, original letter of credit transactions (OCTs), account funding transactions (AFTs), etc.). In some non-limiting embodiments or aspects, the acquirer may be a financial institution, such as a bank. As used herein, the term "acquirer system" may refer to one or more computing devices operated by or on behalf of an acquirer, such as a server computer executing one or more software applications.

[0062] As used herein, the term "account identifier" may include one or more primary account numbers (PANs), tokens, or other identifiers associated with a customer account. The term "token" may refer to an identifier that is used as a replacement or substitute identifier for an original account identifier such as a PAN. An account identifier may be alphanumeric or any combination of characters and / or symbols. A token may be associated with a PAN or other original account identifier in one or more data structures (e.g., one or more databases, etc.) such that the token can be used to conduct transactions without directly using the original account identifier. In some examples, an original account identifier such as a PAN may be associated with multiple tokens used for different individuals or purposes.

[0063] As used herein, the terms "electronic wallet" and "electronic wallet application" refer to one or more electronic devices and / or software applications configured to initiate and / or conduct payment transactions. For example, an electronic wallet may include a mobile device executing an electronic wallet application, and may also include server-side software and / or databases for maintaining and providing transaction data to the mobile device. An "electronic wallet provider" may include an entity that provides and / or maintains an electronic wallet for a customer, such as Google. Android Apple Samsung and / or other similar electronic payment systems. In some non-limiting examples, the issuing bank may be the electronic wallet provider.

[0064] As used herein, the term "issuer institution" may refer to one or more entities, such as a bank, that provide customers with accounts for conducting transactions (e.g., payment transactions), such as initiating credit and / or debit payments. For example, an issuer institution may provide a customer with an account identifier, such as a PAN, that uniquely identifies one or more accounts associated with the customer. The account identifier may be embodied on a portable financial device, such as a physical financial instrument (e.g., a payment card), and / or may be electronic and used for electronic payments. The term "issuer system" refers to one or more computer devices operated by or on behalf of an issuer institution, such as a server computer executing one or more software applications. For example, an issuer system may include one or more authorization servers for authorizing transactions.

[0065] As used herein, the term "merchant" may refer to a person or entity that provides goods and / or services, or access to goods and / or services, to a customer based on a transaction, such as a payment transaction. The terms "merchant" or "merchant system" may also refer to one or more computer systems operated by or on behalf of a merchant, such as a server computer that executes one or more software applications.

[0066] As used herein, a "point of sale (POS) device" may refer to one or more devices that a merchant may use to conduct transactions (e.g., payment transactions) and / or process transactions. For example, a POS device may include one or more client devices. Additionally or alternatively, a POS device may include a peripheral device, a card reader, a scanning device (e.g., a code scanner), Communication receiver, near field communication (NFC) receiver, radio frequency identification (RFID) receiver and / or other contactless transceiver or receiver, contact-based receiver, payment terminal, etc. As used herein, a "point of sale (POS) system" may refer to one or more client devices and / or peripheral devices used by a merchant to conduct transactions. For example, a POS system may include one or more POS devices, and / or other similar devices that can be used to conduct payment transactions. In some non-limiting embodiments or aspects, a POS system (e.g., a merchant POS system) may include one or more server computers configured to process online payment transactions through a web page, mobile application, etc.

[0067] As used herein, the terms "client" and "client device" may refer to one or more client-side devices or systems (e.g., remote from a transaction service provider) used to initiate or facilitate a transaction (e.g., a payment transaction). As an example, a "client device" may refer to one or more POS devices used by a merchant, one or more acquirer host computers used by an acquirer, one or more mobile devices used by a user, one or more computing devices used by a payment device provider system, and the like. In some non-limiting embodiments or aspects, a client device may be an electronic device configured to communicate with one or more networks and initiate or facilitate a transaction. For example, a client device may include one or more computers, portable computers, laptop computers, tablet computers, mobile devices, cellular phones, wearable devices (e.g., watches, glasses, lenses, clothing, etc.), PDAs, and the like. In addition, a "client" may also refer to an entity (e.g., a merchant, an acquirer, etc.) that owns, utilizes, and / or operates a client device for initiating a transaction (e.g., for initiating a transaction with a transaction service provider).

[0068] As used herein, the term "payment device" may refer to a payment card (e.g., a credit or debit card), a gift card, a smart card, smart media, a payroll card, a healthcare card, a wristband, a machine-readable medium containing account information, a keychain device or pendant, an RFID transponder, a retailer discount or loyalty card, a cellular phone, an electronic wallet mobile application, a PDA, a pager, a security card, a computing device, an access card, a wireless terminal, a transponder, etc. In some non-limiting embodiments or aspects, a payment device may include volatile or non-volatile memory to store information (e.g., an account identifier, an account holder's name, etc.).

[0069] As used herein, the term "transaction service provider" may refer to an entity that receives transaction authorization requests from merchants or other entities and, in some cases, provides payment assurance through an agreement between the transaction service provider and an issuer institution. For example, a transaction service provider may include, for example, The term "transaction processing system" may refer to one or more computer systems operated by or on behalf of a transaction service provider, such as a transaction processing server that executes one or more software applications. A transaction processing server may include one or more processors and, in some non-limiting embodiments or aspects, may be operated by or on behalf of a transaction service provider.

[0070] Non-limiting embodiments or aspects of the present disclosure provide an improved system for real-time change detection (e.g., detecting changes, such as outlier transaction behavior, based on a dynamic threshold that is periodically updated and related to the time step currently being examined). For illustration, an electronic payment processing network may process millions of transactions per day. Accurately and quickly identifying changes in transaction behavior (e.g., anomalies, fraudulent transactions, new spending patterns, changes in preferences or habits, etc.) is important for the efficient operation of the electronic payment processing network, particularly for transaction service providers and associated communications. False negatives in change detection may allow electronic transactions to continue to be processed, which may require additional computer resources (e.g., memory, bandwidth, communication times) to correct. In addition, changes in activity may be associated with large-scale attacks, resulting in wasted computer resources in processing transactions that should have been prevented by early detection. In addition, the amount of computer resources required to correct (e.g., participate in risk mitigation processes, restore account status, etc.) malicious activity associated with certain types of behavior changes may increase as the change goes undetected for a longer period of time. Therefore, it is important to identify changes in activity as close to the occurrence of the activity as possible.

[0071] Furthermore, false positives in change detection can prevent the normal operation of an electronic payment processing network, where network functionality for a particular entity (e.g., transaction processing, sending / receiving communications) may be disabled or restricted in response to falsely identifying a malicious change in transaction behavior. Similarly, once identified, false positives may require additional computer resources to remediate. Therefore, improvements in the accuracy and response time of monitoring systems for change detection would lead to direct technical improvements in the electronic payment processing network and the allocation of computer resources therein. The described systems and methods improve the accuracy and response time of such systems by generating risk assessments based on entity-level aggregated data (e.g., comparing aggregated values of transaction data for a time period with historical or training time periods) and using machine learning models trained on the entity's historical data. Such processes improve accuracy and response time by dynamically adjusting thresholds used to trigger risk mitigation processes and by customizing risk values based on aggregated values associated with the assessed entity. In this way, if an entity exhibits transaction behavior that is appropriate or consistent with its own historical behavior, false positives that might otherwise be identified when comparing an entity to other entities are reduced. Similarly, if an entity exhibits trading behavior that is unusual or inconsistent with its own historical behavior, this will reduce the number of false negatives that might otherwise be identified when comparing the entity to other entities. Additionally, dynamically adjusting thresholds allows individual entity behavior to change over time when considering risk identification, allowing change detection to adapt to the entity's most recent representative behavior. The described learning model is self-supervised, which provides a further technical improvement, allowing data to be detected and labeled without external supervisory input. In this way, pre-labeled data is not required, saving computer resources and time. Furthermore, self-supervised learning allows performance to be automatically improved over time by automatically learning normal behavior to predict future events and automatically comparing the differences between predicted events and actual events, which saves computer resources and time compared to supervised learning models.

[0072] Now refer to Figure 1 , shows a diagram of an exemplary environment 100 in which the apparatus, systems, and / or methods described herein may be implemented. Figure 1 As shown, environment 100 may include a payment device 102, a merchant system 104, an acquirer system 106, a transaction processing system 108, a monitoring system 112, an issuer system 114, a modeling system 116, a memory 118, and a communication network 110. Each of the aforementioned devices and / or systems may include one or more computing devices configured to communicate with other devices and / or systems in environment 100 (e.g., directly and / or indirectly via communication network 110).

[0073] The merchant system 104 may include one or more computing devices (e.g., servers, point-of-sale (POS) devices, etc.) configured to communicate with the payment device 102, the acquirer system 106, the monitoring system 112, and / or the transaction processing system 108 (e.g., via the communication network 110). The merchant system 104 may include at least one POS device and may communicate with the payment device 102 to initiate a transaction between an account of the merchant (e.g., a financial institution transaction account associated with an acquirer) and an account of a payment device holder (e.g., a financial institution transaction account associated with an issuer). The merchant system 104 may communicate with the acquirer system 106 to generate one or more transaction authorization requests associated with one or more transactions and transmit the one or more transaction authorization requests to the transaction processing system 108.

[0074] The acquirer system 106 can be an acquirer system as described herein. The acquirer system 106 can be configured to communicate with the monitoring system 112, the merchant system 104, and / or the transaction processing system 108 (e.g., via the communication network 110). The acquirer system 106 can receive (and / or communicate with the merchant system 104 to generate) an authorization request, and / or the acquirer system 106 can transmit the authorization request to the transaction processing system 108.

[0075] The transaction processing system 108 may be a transaction processing system as described herein. The transaction processing system 108 may be configured to communicate with the acquirer system 106, the monitoring system 112, the issuer system 114, the memory 118, and / or the modeling system 116 (e.g., via the communication network 110). The transaction processing system 108 may receive a transaction authorization request from the acquirer system 106 and transmit a transaction authorization response to the acquirer system 106 (and / or communicate with the issuer system 114 to generate a transaction authorization response).

[0076] The issuer system 114 may be an issuer system as described herein. The issuer system 114 may be configured to communicate with the monitoring system 112 and / or the transaction processing system 108 (e.g., via the communication network 110). The issuer system 114 may communicate with the transaction processing system 108 to generate a transaction authorization response to the acquirer system 106.

[0077] The monitoring system 112 may include one or more computing devices (e.g., servers, etc.) configured to communicate (e.g., via the communication network 110) with the payment device 102, the merchant system 104, the acquirer system 106, the transaction processing system 108, the issuer system 114, the modeling system 116, and / or the memory 118. The monitoring system 112 may be configured to monitor transactions processed in the transaction processing system 108, aggregate one or more values of parameters of transaction data associated with one or more entities, and trigger one or more risk mitigation processes. The transaction data may include one or more values of one or more parameters of one or more transactions, including but not limited to transaction amount, transaction time, merchant identifier, payment device identifier, account identifier, merchant category (e.g., gas, retail, etc.), transaction type (e.g., online, in-person, etc.), etc. The risk mitigation process may include but is not limited to: transmitting an alert to Figure 1 , denying incoming transactions associated with one or more accounts associated with the entity (e.g., triggering the transaction processing system 108 and / or the issuer system 114 to deny incoming transactions) or transactions being processed associated with the entity, disabling (at least partially) system access to the entity (e.g., removing or disabling permissions to participate in certain network activities), etc. The monitoring system 112 may include a cluster of server nodes (e.g., an entity processing cluster), as described herein (e.g., Figure 6 722 depicted in FIG. ). A cluster of server nodes may be managed (e.g., resource allocation and control) on the same or different servers through a physical allocation process. Monitoring system 112 may include a fraud detection and risk mitigation system. Transaction processing system 108 may include monitoring system 112. Monitoring system 112 may include memory 118.

[0078] The modeling system 116 may include one or more computing devices (e.g., servers, etc.) configured to communicate with the transaction processing system 108 to receive at least a portion of transaction data associated with one or more transactions as input to one or more machine learning models. The modeling system 116 may generate output from the one or more machine learning models based on the input of at least a portion of the transaction data. The modeling system 116 may also be configured to communicate with the memory 118 to store and receive stored model states (e.g., hidden states, cell states, etc.) of the machine learning model (e.g., a long short-term memory (LSTM) model). The modeling system 116 may include a cluster of server nodes (e.g., an entity processing cluster), as described herein (e.g., Figure 6722 depicted in FIG. ). A cluster of server nodes can be managed (e.g., resource allocation and control) on the same or different servers through a physical allocation process. The transaction processing system 108 may include a modeling system 116 and / or a memory 118. The modeling system 116 may include a memory 118.

[0079] The memory 118 may include one or more computing devices (e.g., servers, etc.) configured to store aggregated values of transaction data over one or more time periods, machine learning model states (e.g., hidden states, unit states, etc.) of stateful machine learning models, machine learning models of different entities (e.g., including configurations and classifications), etc. The memory 118 may include a cluster of server nodes, as described herein (e.g., Figure 6 722 depicted in ). Each state can be stored in association with an identifier associated with one or more parameters of an input to the stateful machine learning model. For inputs associated with a transaction, the state can be stored in association with, but not limited to, a payment device identifier, an account identifier, a payment device holder identifier, or any combination thereof. In some non-limiting embodiments or aspects, monitoring system 112, modeling system 116, and / or memory 118 can be the same system and / or included in the same system. In some non-limiting embodiments or aspects, one or more of monitoring system 112, modeling system 116, and / or memory 118 can be the same system and / or included in the transaction processing system 108.

[0080] The communication network 110 may include one or more wired and / or wireless networks. For example, the communication network 110 may include a cellular network (e.g., Long Term Evolution networks, third generation (3G) networks, fourth generation (4G) networks, fifth generation (5G) networks, code division multiple access (CDMA) networks, etc.), public land mobile networks (PLMNs), local area networks (LANs), wide area networks (WANs), metropolitan area networks (MANs), telephone networks (e.g., public switched telephone networks (PSTNs)), private networks, ad hoc networks, mesh networks, beacon networks, intranets, the Internet, fiber-optic-based networks, cloud computing networks, etc., and / or combinations of these or other types of networks.

[0081] supply Figure 1 The number and arrangement of devices and networks shown in the are examples only. Figure 1 Additional devices and / or networks, fewer devices and / or networks, different devices and / or networks, or differently arranged devices and / or networks than those shown in . Figure 1 Two or more of the devices shown in FIG may be implemented in a single device, or Figure 1A single device shown in FIG may be implemented as multiple distributed devices. Additionally or alternatively, one set of devices (eg, one or more devices) of environment 100 may perform one or more functions described as being performed by another set of devices of environment 100.

[0082] In some non-limiting embodiments or aspects, the transaction processing system 108 may receive (e.g., within a first time period) transaction data associated with at least one transaction (e.g., a credit transaction, a debit transaction, a refund transaction, etc.) associated with an entity (e.g., a transaction account, a payment device holder, a merchant, an acquirer, an issuer, etc.) within a first time period (e.g., a day, a week, a month, etc.). The transaction data may include, but is not limited to, a transaction date, a transaction time, a transaction description, a transaction amount, a transaction identifier, a merchant identifier, a payment device identifier, a card present or not present indicator, a transaction type (e.g., online, in-person, retail, gas, periodic payment, etc.), a merchant category, etc.

[0083] The transaction processing system 108 and / or the modeling system 116 may also determine at least one aggregate value based on at least a portion of the transaction data for at least one transaction. The at least one aggregate value may be based on at least a portion of the transaction data (e.g., one or more parameters). In some non-limiting embodiments or aspects, the aggregate value may be associated with (but not limited to) a count of the number of transactions within a time period, a total amount of transactions within a time period (e.g., a total value amount), a count of the number of transactions within a time period for a subset of transactions that meet predetermined parameters (e.g., a count of card-present transactions, a count of online transactions, etc.), a total amount of transactions within a time period for a subset of transactions that meet predetermined parameters, and the like.

[0084] The transaction processing system 108 and / or the modeling system 116 may also generate at least one predicted aggregate value for the entity by inputting historical transaction data associated with a plurality of historical transactions associated with the entity into a machine learning model. The historical transaction data may include transaction data for transactions that occurred within a time period prior to the time period during which the transaction data used to determine the at least one aggregate value was received. In some non-limiting embodiments or aspects, the machine learning model may be an LSTM model. The input to the LSTM model may be a three-dimensional array having dimensions {batch size, time step, sequence length}, which includes the historical transaction data (e.g., including the same parameters used to determine the at least one aggregate value). The output of the LSTM model may be a hidden state and a predicted aggregate value for the last time step.

[0085] The transaction processing system 108 and / or the modeling system 116 may receive historical transaction data associated with a plurality of historical transactions during a training period (e.g., one day, one week, one month, one year, etc.) prior to a first period in which the transaction data is received and used to determine at least one aggregate value. The transaction processing system 108 and / or the modeling system 116 may determine at least one historical aggregate value based on at least a portion of the historical transaction data for the plurality of historical transactions. The at least one historical aggregate value may be based on a type of entity associated with the plurality of historical transactions, and the at least one historical aggregate value may be used to train a machine learning model for use during the first period. The at least one historical aggregate value may further be specific to transactions associated with a subject entity being monitored for changes in transaction behavior. In some non-limiting embodiments or aspects, the transaction processing system 108 and / or the modeling system 116 may train a machine learning model using the at least one historical aggregate value to configure the machine learning model to predict at least one future value of the transaction data for future transactions. After training the machine learning model as described above, the machine learning model may be used to generate at least one predicted aggregate value for the entity.

[0086] The transaction processing system 108 and / or the modeling system 116 may further determine a deviation of the at least one aggregate value from the at least one predicted aggregate value. The deviation may include a subtractive difference between the at least one aggregate value and the at least one predicted aggregate value. The deviation may also include a standard deviation of the aggregate values for a previous time period (e.g., a day, a week, a month, etc.). In some non-limiting embodiments or aspects, the deviation may be associated with a probability that an outlier of the activity has occurred. In some non-limiting embodiments or aspects, the deviation may be determined according to the following formula:

[0087] Formula 1

[0088]

[0089] Where s is the deviation score, x is at least one aggregate value in the current time period, is at least one predicted aggregate value for the current time period, σ is the standard deviation for the previous time period, and the values 4 and 1000 are predetermined (but modifiable) parameters for generating the deviation score that have been found to have good performance.

[0090] The transaction processing system 108, modeling system 116, and / or monitoring system 112 may further compare the deviation to a dynamic threshold associated with the entity. A dynamic threshold may be determined based on the entity's activity and may be specifically assigned to the entity. The transaction processing system 108 and / or modeling system 116 may determine dynamic thresholds for the entity and multiple other entities, where each dynamic threshold is customized for the associated entity based on the associated entity's transaction history and / or previously determined deviations. The dynamic threshold may include a value such that if the determined deviation meets and / or exceeds the dynamic threshold's value, the dynamic threshold is determined to be met. The transaction processing system 108 and / or modeling system 116 may determine whether the entity's dynamic threshold is met based on a comparison of the deviation to the dynamic threshold associated with the entity. The dynamic threshold may be automatically and periodically updated by the transaction processing system 108 and / or modeling system 116 based on ongoing transactions over a moving time period, such that for each time increment (e.g., one day, one week, one month), the dynamic threshold is updated based on the entity's transactions and / or deviations within a given time period (e.g., one day, one week, one month). In some non-limiting embodiments or aspects, the dynamic threshold may be determined according to the following formula:

[0091] Formula 2

[0092] max(0.1,max(s))*1.05),

[0093] The dynamic threshold is equal to a value that is 0.1 or 5% (e.g., multiplied by 1.05), whichever is greater, higher than the maximum deviation score s for all s determined over the past time period (e.g., a day, a week, a month). After deviation scores determined to be outliers in a set of s (e.g., satisfying the previous dynamic threshold) are excluded from the set of all s, the above formula can be further based on all s determined over the past time period. The values 0.1 and 1.05 are predetermined (but modifiable) parameters used to determine the dynamic threshold, which have been found to work well.

[0094] The standard deviation determined for the deviation score may be a moving standard deviation such that it is based on the standard deviation for a time period (e.g., one week) prior to the time step at which the deviation score is being calculated. Thus, the standard deviation may be moved by periodically recalculating the deviation score within each subperiod (e.g., one day) of the time period (e.g., one week) during which ongoing transactions for the entity are completed, to generate a plurality of deviations, each calculated based on a slightly different standard deviation determined from the moving time period. The transaction processing system 108 and / or the modeling system 116 may automatically and periodically (e.g., daily, weekly, etc.) update the dynamic threshold based on ongoing transactions associated with the entity, which may include determining the deviation of at least one aggregate value from at least one predicted aggregate value within each subperiod of the time period during which ongoing transactions are completed, to generate a plurality of deviations, and updating the dynamic threshold after each subperiod of the time period based at least in part on a maximum of the plurality of deviations. The transaction processing system 108 and / or the modeling system 116 may also retrain the machine learning model based on ongoing transactions, such that ongoing transaction data is used to determine ongoing aggregate values that can be input into the machine learning model for training purposes (e.g., similar to inputting historical transaction data, but in reality on an ongoing, self-improving basis). Using the periodically retrained machine learning model, the transaction processing system 108 and / or the modeling system 116 may regenerate at least one predicted aggregate value for the entity within each sub-period of the time period based on the latest machine learning model. In this way, not only are entity-level thresholds configured to be dynamic based on the actual historical deviation of the entity, but the most accurate predicted aggregate value determined from the periodically updated machine learning model may also be used to calculate the deviation score used to determine the threshold.

[0095] The transaction processing system 108 and / or the modeling system 116 may trigger (e.g., effect immediately after or substantially immediately after a triggering event) at least one risk mitigation process associated with the entity in response to determining that the deviation satisfies a dynamic threshold. The at least one risk mitigation process may include, but is not limited to: temporarily denying future transactions associated with the entity (e.g., payment transactions by a transaction account entity, transactions requested by an acquirer entity, etc.); transmitting an alert to the entity (e.g., to a computing device of a payment device holder entity, to a merchant entity's merchant system 104, to an acquirer entity's acquirer system 106, to an issuer entity's issuer system 114, etc.); temporarily disabling system access to the entity (e.g., removing or disabling permissions to participate in certain network activities, such as requesting the entity's payment device information, modifying the entity's preferences or security settings, etc.).

[0096] Reference Figure 2, a diagram illustrating example components of an apparatus 200 according to a non-limiting embodiment is shown. As an example, apparatus 200 may correspond to payment apparatus 102, merchant system 104, acquirer system 106, transaction processing system 108, monitoring system 112, modeling system 116, memory 118, issuer system 114, and / or communication network 110. In some non-limiting embodiments, such a system or apparatus may include at least one apparatus 200 and / or at least one component of apparatus 200. The number and arrangement of components shown are provided as examples. In some non-limiting embodiments, apparatus 200 may include additional components, fewer components, different components, or differently arranged components than those shown. Additionally or alternatively, one or more components of apparatus 200 (e.g., one or more components) may perform one or more functions described as being performed by another group of components of apparatus 200.

[0097] like Figure 2 As shown, the device 200 may include a bus 202, a processor 204, a memory 206, a storage component 208, an input component 210, an output component 212, and a communication interface 214. The bus 202 may include components that permit communication between the components of the device 200. In some non-limiting embodiments, the processor 204 may be implemented in hardware, firmware, or a combination of hardware and software. For example, the processor 204 may include a processor (e.g., a central processing unit (CPU), a graphics processing unit (GPU), an accelerated processing unit (APU), etc.), a microprocessor, a digital signal processor (DSP), and / or any processing component that can be programmed to perform a function (e.g., a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), etc.). The memory 206 may include a random access memory (RAM), a read-only memory (ROM), and / or another type of dynamic or static storage device (e.g., flash memory, magnetic memory, optical memory, etc.) that stores information and / or instructions for use by the processor 204.

[0098] Continue to refer Figure 2Storage component 208 may store information and / or software related to the operation and use of device 200. For example, storage component 208 may include a hard disk (e.g., a magnetic disk, an optical disk, a magneto-optical disk, a solid-state disk, etc.) and / or another type of computer-readable medium. Input component 210 may include components that permit device 200 to receive information, such as via user input (e.g., a touch screen display, a keyboard, a keypad, a mouse, buttons, switches, a microphone, etc.). Additionally or alternatively, input component 210 may include sensors for sensing information (e.g., a global positioning system (GPS) component, an accelerometer, a gyroscope, an actuator, etc.). Output component 212 may include components that provide output information from device 200 (e.g., a display screen, a speaker, one or more light-emitting diodes (LEDs), etc.). Communication interface 214 may include transceiver-type components (e.g., a transceiver, a separate receiver and transmitter, etc.) that enable device 200 to communicate with other devices, such as via a wired connection, a wireless connection, or a combination of wired and wireless connections. The communication interface 214 may permit the device 200 to receive information from another device and / or provide information to another device. For example, the communication interface 214 may include an Ethernet interface, an optical interface, a coaxial interface, an infrared interface, a radio frequency (RF) interface, a universal serial bus (USB) interface, interface, cellular network interface, etc.

[0099] The device 200 can perform one or more processes described herein. The device 200 can perform these processes based on the processor 204 executing software instructions stored by a computer-readable medium such as the memory 206 and / or storage component 208. The computer-readable medium may include any non-transient memory device. The memory device includes a memory space located within a single physical storage device or a memory space extended across multiple physical storage devices. The software instructions can be read from another computer-readable medium or from another device into the memory 206 and / or storage component 208 via the communication interface 214. When executed, the software instructions stored in the memory 206 and / or storage component 208 can cause the processor 204 to perform one or more processes described herein. In addition or alternatively, hard-wired circuitry can replace or be used in conjunction with software instructions to perform one or more processes described herein. Therefore, the embodiments described herein are not limited to any specific combination of hardware circuitry and software. As used herein, the term "configured to" may refer to the arrangement of software, devices, and / or hardware for performing and / or implementing one or more functions (e.g., actions, processes, steps of processes, etc.). For example, a "processor configured to" may refer to a processor executing software instructions (eg, program code) that cause the processor to perform one or more functions.

[0100] Reference Figure 3 , Figure 3 is a flow chart of a non-limiting embodiment or aspect of a process 300 for real-time change detection according to some non-limiting embodiments or aspects. Figure 3 The steps shown in process 300 are for example purposes only. It should be understood that in non-limiting embodiments or aspects, additional, fewer, different, and / or different orders of steps may be used. In some non-limiting embodiments or aspects, one or more of the steps of process 300 may be performed (e.g., completely, partially, etc.) by transaction processing system 108, modeling system 116, and / or monitoring system 112. In some non-limiting embodiments or aspects, one or more of the steps of process 300 may be performed (e.g., completely, partially, etc.) by another system, another device, another group of systems, or another group of devices that is different from or includes transaction processing system 108, modeling system 116, and / or monitoring system 112.

[0101] like Figure 3 As shown, at step 302, process 300 may include receiving transaction data. For example, transaction processing system 108 may receive transaction data associated with at least one transaction associated with an entity (e.g., a transaction account, a merchant, an acquirer, an issuer, or any combination thereof). Transaction processing system 108 may store the transaction data in memory 118.

[0102] like Figure 3 As shown, at step 304, process 300 may include determining at least one aggregate value. For example, transaction processing system 108 and / or modeling system 116 may determine at least one aggregate value based on at least a portion of transaction data for at least one transaction. The aggregate value may be based on transactions associated with a type of entity or may be specific to transactions of the entity itself. In some non-limiting embodiments or aspects, transaction processing system 108 and / or modeling system 116 may determine the aggregate value for the total value of transactions for the entity during a first time period.

[0103] like Figure 3 As shown, at step 306, process 300 may include generating at least one predicted aggregate value by inputting the historical transaction data into a machine learning model. For example, transaction processing system 108 and / or modeling system 116 may generate at least one predicted aggregate value for an entity by inputting historical transaction data associated with a plurality of historical transactions associated with the entity into a machine learning model (e.g., an LSTM model).

[0104] like Figure 3As shown, at step 308, process 300 may include determining a deviation of at least one aggregated value from at least one predicted aggregated value. For example, transaction processing system 108, modeling system 116, and / or monitoring system 112 may determine a deviation of at least one aggregated value from at least one predicted aggregated value. The deviation may be based at least in part on a moving standard deviation. The deviation may be a score calculated based on the moving standard deviation and at least an arithmetic difference between the at least one aggregated value and the at least one predicted value.

[0105] like Figure 3 As shown, at step 310, process 300 may include comparing the deviation to a dynamic threshold associated with the entity. For example, transaction processing system 108, modeling system 116, and / or monitoring system 112 may compare the deviation determined in step 308 to a dynamic threshold associated with the entity (e.g., determined specifically based on the entity's transaction history). If the deviation does not meet the dynamic threshold, process 300 may continue to monitor for changes by looping back to step 302. If the deviation does meet the dynamic threshold, process 300 may continue to step 312 to first perform other steps.

[0106] like Figure 3 As shown, at step 312, process 300 may include triggering at least one risk mitigation process. For example, transaction processing system 108, modeling system 116, and / or monitoring system 112 may trigger at least one risk mitigation process associated with the entity in response to determining that the deviation satisfies the dynamic threshold (in step 310). The at least one risk mitigation process may include, but is not limited to, temporarily denying future transactions associated with the entity, transmitting an alert to the entity, temporarily disabling system access to the entity, or any combination thereof.

[0107] Reference Figure 4 , Figure 4 is a flow chart of a non-limiting embodiment or aspect of a process 400 for real-time change detection according to some non-limiting embodiments or aspects. Figure 4 The steps shown are for example purposes only. It should be understood that in non-limiting embodiments or aspects, additional, fewer, different, and / or different orders of steps may be used. In some non-limiting embodiments or aspects, one or more of the steps of process 400 may be performed (e.g., completely, partially, etc.) by transaction processing system 108, modeling system 116, and / or monitoring system 112. In some non-limiting embodiments or aspects, one or more of the steps of process 400 may be performed (e.g., completely, partially, etc.) by another system, another device, another group of systems, or another group of devices that is different from or includes transaction processing system 108, modeling system 116, and / or monitoring system 112.

[0108] like Figure 4As shown, at step 402, process 400 may include receiving historical transaction data. For example, transaction processing system 108 and / or modeling system 116 may receive ( Figure 3 ) historical transaction data of step 306 in the process 300 shown.

[0109] like Figure 4 As shown, at step 404, process 400 may include determining at least one historical aggregate value. For example, transaction processing system 108 and / or modeling system 116 may determine the at least one historical aggregate value based on at least a portion of the historical transaction data for the plurality of historical transactions based on a type of entity associated with the plurality of historical transactions. In some non-limiting embodiments or aspects, the portion of the historical transaction data used may be based on the type of entity, such that transaction data for entities of the same type as the entity being evaluated is used during the training of the machine learning model.

[0110] like Figure 4 As shown, at step 406, process 400 may include training a machine learning model with at least one historical aggregate value. For example, transaction processing system 108 and / or modeling system 116 may train the machine learning model with at least one historical aggregate value (e.g., as a training input) such that the machine learning model is configured to predict at least one future value of transaction data for future transactions. In some non-limiting embodiments or aspects, when at least one historical aggregate value is a total transaction value for an entity, the future value may be a total transaction value predicted at a future time step. In some non-limiting embodiments or aspects, when at least one historical aggregate value is a total transaction count for an entity, the future value may be a transaction count for transactions predicted at a future time step.

[0111] Now refer to Figure 5 , Figure 5 is a flow chart of a non-limiting embodiment or aspect of a process 500 for real-time change detection, according to some non-limiting embodiments or aspects. Figure 5The steps shown in process 500 are for example purposes only. It should be understood that in non-limiting embodiments or aspects, additional, fewer, different, and / or different orders of steps may be used. In some non-limiting embodiments or aspects, one or more of the steps of process 500 may be performed (e.g., completely, partially, etc.) by transaction processing system 108, modeling system 116, and / or monitoring system 112. In some non-limiting embodiments or aspects, one or more of the steps of process 500 may be performed (e.g., completely, partially, etc.) by another system, another device, another group of systems, or another group of devices that is different from or includes transaction processing system 108, modeling system 116, and / or monitoring system 112.

[0112] like Figure 5 As shown, at step 502, process 500 may include retraining the machine learning model based on ongoing transactions associated with the entity to generate an updated machine learning model. For example, the transaction processing system 108 and / or the modeling system 116 may retrain the machine learning model based on ongoing transactions to generate an updated machine learning model. Ongoing transactions may be used to calculate ongoing aggregate values that may be fed into the machine learning model as new training input to periodically update the machine learning model for future predictions.

[0113] like Figure 5 As shown, at step 504, process 500 may include updating a dynamic threshold based on ongoing transactions associated with the entity. For example, the transaction processing system 108 and / or the modeling system 116 may automatically and periodically update the dynamic threshold based on ongoing transactions associated with the entity. In some non-limiting embodiments or aspects, the dynamic threshold may be updated at each new time step (e.g., one day) within a time period (e.g., one week) based at least on a maximum value of the deviation score for the entity occurring over increasing time periods. By way of further example, when updating the dynamic threshold based on ongoing transactions, the transaction processing system 108 and / or the modeling system 116 may determine a deviation between at least one aggregated value and at least one predicted aggregated value for each sub-period (e.g., time step) of the time period during which the ongoing transactions were completed, to generate a plurality of deviations. When updating the dynamic threshold based on ongoing transactions, the transaction processing system 108 and / or the modeling system 116 may further update the dynamic threshold after each sub-period of the time period based at least in part on a maximum value of the plurality of deviations.

[0114] Reference Figure 6 , depicts a data flow diagram of communications in a system and method for real-time change detection according to a non-limiting embodiment or aspect. The depicted data flow diagram may be at least partially Figure 1The data flow diagram includes a first process flow 602, which may include processes for training and using a machine learning model and periodically updating dynamic thresholds for an entity. The first process flow 602 may be performed in parallel with a second process flow 604, which may include processes for monitoring and acting on the real-time flow of transactions being processed by the transaction processing system 108.

[0115] like Figure 6 As shown, at step 1, a first process flow 602 may include storing transaction data for each of a plurality of entities in a memory 118 (e.g., a data lake), where the transaction data may be used to create entity-level aggregates. The first process flow 602 may include a sub-process 606 in which the transaction processing system 108 and / or the modeling system 116 may generate entity-level aggregates for each of the plurality of entities. The generated entity-level aggregates may be stored in the memory 118.

[0116] like Figure 6 As shown, at step 2, the first process flow 602 may include training a machine learning model 708 (e.g., an LSTM model) based on entity-level aggregation to learn normal entity behavior for predicting future entity behavior.

[0117] like Figure 6 As shown, at step 3, the first process flow 602 may include evaluating the deviation of observed entity behavior from predicted entity behavior using an outlier probability calculator 710 (eg, executed by the transaction processing system 108 and / or the modeling system 116).

[0118] like Figure 6 As shown, at step 4, the first process flow 602 may include generating and / or adjusting an entity-level dynamic threshold 712 to trigger a risk mitigation action (e.g., transmitting an alert) when observed entity behavior is sufficiently different from expected entity behavior (e.g., the deviation satisfies the dynamic threshold 712). The dynamic threshold 712 may be configured to self-adjust (e.g., through automatic and periodic updates by the transaction processing system 108 and / or the modeling system 116) to account for changing entity behavior and use the latest data to keep the false positive rate (e.g., caused by acceptable behavior changes) low.

[0119] like Figure 6 As shown, at step 5, the acquirer system 106 and the issuer system 114 may transmit authorization requests and / or authorization responses to complete transactions for multiple entities via the transaction processing system 108. For example, transactions for all entities may be monitored (e.g., by the transaction processing system 108 and / or the monitoring system 112) to detect changes in entity-level behavior.

[0120] like Figure 6As shown, at step 6, the second process flow 604 may include a sub-process 620 that may include streaming transaction data from an ongoing pipeline of processed transactions for all entities. For example, the transaction processing system 108 and / or the modeling system 116 may identify entities being monitored for behavioral changes and, in the case of processed transactions, may direct transaction data for transactions associated with those entities to perform additional actions in the second process flow 604 in real time. In this way, transaction data for entities being monitored may be filtered from the pipeline to further aggregate and evaluate changes in entity-level behavior.

[0121] like Figure 6 As shown, at step 7, the second process flow 604 may include a sub-process 622, which may include generating an aggregate value for each of the monitored entities in real time. For example, the transaction processing system 108, the monitoring system 112, and / or the modeling system 116 may generate at least one aggregate value from the transaction data of each of the plurality of monitored entities. In some non-limiting embodiments or aspects, the entity may be a transaction account, and the aggregate may be the total value (e.g., volume) of the entity's transactions during the evaluated time period. As additional transactions for the entity are processed during the evaluated time period, the entity's aggregate value may continue to change (e.g., increase) with each processed transaction.

[0122] like Figure 6 As shown, at step 8, the second process flow 604 may include storing at least one aggregate value for each monitored entity in the memory 118 (e.g., which may be the same data store as used in step 1 of the first process flow 602 or a different data store). For example, the transaction processing system 108, the monitoring system 112, and / or the modeling system 116 may store the at least one aggregate value for each entity in the memory 118 as the at least one aggregate value is generated or updated in real time.

[0123] like Figure 6As shown, at step 9, the second process flow 604 may include a sub-process 624, which may include distributing aggregate values for monitored entities to different nodes 724a, 724b, and 724n of the server cluster 722 for parallel processing. For example, the monitoring system 112 may distribute one or more aggregate values for a subset of one or more entities to each node 724a, 724b, and 724n of the server cluster 722. In some non-limiting embodiments or aspects, the monitoring system 112 may include the server cluster 722. The distribution of sub-process 624 may be enhanced to ensure that each node 724a, 724b, and 724n of the server cluster 722 has a sufficient (e.g., reasonable) workload (e.g., not too much or too little transaction volume for the entity). Therefore, and in non-limiting embodiments or aspects, the sub-process 624 may include a volume monitoring process that monitors the real-time transaction volume of different entities as data is sent to each node 724a, 724b, and 724n. The sub-process 624 may further include a shuffling process that shuffles the workload of the cluster 722 to redistribute the workload of each node 724a, 724b, 724n when the workload becomes unbalanced.

[0124] In some non-limiting embodiments or aspects, sub-process 624 may further include a resource-based adaptive algorithm, which may be a load balancing algorithm that uses an agent installed on each node 724a, 724b, 724n of the server cluster 722, which reports its current load to the load balancer. The installed agent monitors the availability status and resources of the nodes 724a, 724b, 724n, and the load balancer queries the output from the agent to assist in making load balancing decisions. Sub-process 624 may further include an agent listener that listens to the monitoring agent installed on each node 724a, 724b, 724n of the server cluster.

[0125] like Figure 6As shown, at step 10, the second process flow 604 may include a prediction sub-process 630a, 630b, 630n and a monitoring sub-process 632a, 632b, 632n that monitors each node 724a, 724b, 724n of the server cluster 722. In the server cluster 722, for each entity, the prediction sub-process 630a, 630b, 630n generates a predicted aggregate value for the entity using the (trained) machine learning model 708, and the predicted aggregate value may be compared with the entity's observed aggregate value in the monitoring sub-process 632a, 632b, 632n, which is updated after each of the entity's ongoing transactions. The monitoring sub-process 632a, 632b, 632n may include a multi-threaded process to compare the actual aggregate value with the predicted aggregate value in real time to identify a change in behavior based on a deviation meeting the dynamic threshold 712. Memory 118 may further act as a model store to store and manage different machine learning models of different entities, configurations, and classifications that may be used by server cluster 722 .

[0126] like Figure 6 As shown, at step 11, the first process flow 602 may include periodically updating the machine learning model 708 based on the monitored transactions from the second process flow 604. For example, the transaction processing system 108 and / or the modeling system 116 may automatically and periodically update (e.g., retrain) the machine learning model 708 based on the monitored transactions from the second process flow 604.

[0127] like Figure 6 As shown, at step 12, the first process flow 602 may include updating a dynamic threshold 712 for the entity based on monitored transactions from the second process flow 604. For example, because entity deviations are periodically determined in the second process flow 604, the transaction processing system 108 and / or the modeling system 116 may use such ongoing deviation determinations to update (e.g., adjust and / or generate new) the dynamic threshold 712, which may be used to determine what constitutes normal or typical behavior for the entity.

[0128] like Figure 6As shown, at step 13, the second process flow 604 may include a sub-process 640 that includes providing an entity-oriented service (e.g., a risk mitigation process) based on the monitoring sub-processes 632a, 632b, and 632n of the server cluster 722. For example, the transaction processing system 108, the modeling system 116, and / or the monitoring system 112 may perform or cause to be performed at least one action based on a determination that the behavior of the entity has changed (e.g., the deviation of the entity satisfies the dynamic threshold 712 of the entity). In some non-limiting embodiments or aspects, the alert sub-processes 634a, 634b, and 634n of the server cluster 722 may trigger the transmission of an alert from the monitoring system 112 to the entity in response to a determination that the behavior of the entity has changed. Additionally or alternatively, the alert sub-processes 634a, 634b, 634n of the server cluster 722 may trigger an alert to the transaction processing system 108 (and / or the issuer system 114, the acquirer system 106 and / or the merchant system 104), which may cause the transaction processing system 108 (and / or the issuer system 114, the acquirer system 106 and / or the merchant system 104) to further evaluate the entity's behavior before performing additional actions (e.g., additional risk mitigation processes).

[0129] Although the embodiments have been described in detail for purposes of illustration, it should be understood that such detail is provided for that purpose only, and that the present disclosure is not limited to the disclosed embodiments or aspects, but, on the contrary, is intended to cover modifications and equivalent arrangements within the spirit and scope of the appended claims. For example, it should be understood that the present disclosure contemplates that, to the extent possible, one or more features of any embodiment or aspect can be combined with one or more features of any other embodiment or aspect.

Claims

1. A system comprising: At least one processor configured to: receiving transaction data associated with at least one transaction associated with an entity; determining at least one aggregate value based on at least a portion of the transaction data for the at least one transaction; generating at least one predicted aggregated value for the entity by inputting historical transaction data associated with a plurality of historical transactions associated with the entity into a machine learning model; determining a deviation of the at least one aggregated value from the at least one predicted aggregated value; comparing the deviation to a dynamic threshold associated with the entity; as well as In response to determining that the deviation satisfies the dynamic threshold, at least one risk mitigation process associated with the entity is triggered.

2. The system of claim 1 , wherein upon receiving the transaction data associated with the at least one transaction, the at least one processor is configured to: receiving said transaction data associated with said at least one transaction within a first time period; and wherein the at least one processor is further configured to: receiving the historical transaction data associated with the plurality of historical transactions during a training period prior to the first period; determining at least one historical aggregate value based on at least a portion of the historical transaction data for the plurality of historical transactions based on a type of entity associated with the plurality of historical transactions; and The machine learning model is trained with the at least one historical aggregate value, wherein the machine learning model is configured to predict at least one future value of the transaction data for future transactions.

3. A system according to claim 1, wherein the type of entity includes at least one of the following: a transaction account, a merchant, an acquirer, an issuer, or any combination thereof; and wherein the at least one risk mitigation process includes at least one of the following: temporarily denying future transactions associated with the entity, transmitting an alert to the entity, temporarily disabling system access to the entity, or any combination thereof. 4 . The system of claim 1 , wherein the at least one processor is further configured to automatically and periodically update the dynamic threshold based on ongoing transactions associated with the entity.

5. The system of claim 4, wherein the deviation is based at least in part on a moving standard deviation, and wherein when updating the dynamic threshold based on the ongoing transactions associated with the entity, the at least one processor is configured to: determining the deviation of the at least one aggregate value from the at least one predicted aggregate value within each sub-period of a time period during which the ongoing transaction is completed to generate a plurality of deviations; and The dynamic threshold is updated after each sub-period of the time period based at least in part on a maximum of the plurality of deviations.

6. The system of claim 5 , wherein the at least one processor is further configured to retrain the machine learning model based on the ongoing transactions to generate an updated machine learning model, and wherein when determining the deviation of the at least one aggregated value from the at least one predicted aggregated value within each sub-period of the time period, the at least one processor is configured to: The at least one predicted aggregate value for the entity is regenerated based on the updated machine learning model.

7. A computer-implemented method comprising: receiving, with at least one processor, transaction data associated with at least one transaction associated with an entity; determining, with at least one processor, at least one aggregate value based on at least a portion of the transaction data for the at least one transaction; generating, with at least one processor, at least one predicted aggregate value for the entity by inputting historical transaction data associated with a plurality of historical transactions associated with the entity into a machine learning model; determining, with at least one processor, a deviation of the at least one aggregated value from the at least one predicted aggregated value; comparing, using at least one processor, the deviation to a dynamic threshold associated with the entity; as well as In response to determining that the deviation satisfies the dynamic threshold, at least one risk mitigation process associated with the entity is triggered, using at least one processor.

8. The computer-implemented method of claim 7 , wherein receiving the transaction data associated with the at least one transaction comprises: receiving said transaction data associated with said at least one transaction during a first time period; The method further comprises: receiving, with at least one processor, the historical transaction data associated with the plurality of historical transactions during a training time period prior to the first time period; The at least one processor determines at least one historical aggregate value based on at least a portion of the historical transaction data for the plurality of historical transactions based on a type of entity associated with the plurality of historical transactions; and The machine learning model is trained, using at least one processor, with the at least one historical aggregate value, wherein the machine learning model is configured to predict at least one future value of transaction data for future transactions.

9. The computer-implemented method of claim 7, wherein the type of entity comprises at least one of: a transaction account, a merchant, an acquirer, an issuer, or any combination thereof.

10. The computer-implemented method of claim 9, wherein the at least one risk mitigation process comprises at least one of temporarily denying future transactions associated with the entity, transmitting an alert to the entity, temporarily disabling system access to the entity, or any combination thereof.

11. The computer-implemented method of claim 7, further comprising automatically and periodically updating, utilizing at least one processor, the dynamic threshold based on ongoing transactions associated with the entity.

12. The computer-implemented method of claim 11 , wherein the deviation is based at least in part on a moving standard deviation, and wherein updating the dynamic threshold based on the ongoing transactions associated with the entity comprises: determining the deviation of the at least one aggregate value from the at least one predicted aggregate value during each sub-period of a time period during which the ongoing transaction is completed to generate a plurality of deviations; as well as The dynamic threshold is updated after each sub-period of the time period based at least in part on a maximum of the plurality of deviations.

13. The computer-implemented method of claim 12, further comprising, utilizing at least one processor, retraining the machine learning model based on the ongoing transactions to generate an updated machine learning model, wherein determining the deviation of the at least one aggregated value from the at least one predicted aggregated value within each sub-period of the time period further comprises: The at least one predicted aggregated value for the entity is regenerated based on the updated machine learning model during the time period.

14. The computer-implemented method of claim 7, wherein the machine learning model is a Long Short-Term Memory (LSTM) model.

15. A computer program product comprising at least one non-transitory computer-readable medium comprising program instructions that, when executed by at least one processor, cause the at least one processor to: receiving transaction data associated with at least one transaction associated with an entity; determining at least one aggregate value based on at least a portion of the transaction data for the at least one transaction; generating at least one predicted aggregated value for the entity by inputting historical transaction data associated with a plurality of historical transactions associated with the entity into a machine learning model; determining a deviation of the at least one aggregated value from the at least one predicted aggregated value; comparing the deviation to a dynamic threshold associated with the entity; as well as In response to determining that the deviation satisfies the dynamic threshold, at least one risk mitigation process associated with the entity is triggered.

16. The computer program product of claim 15, wherein the program instructions that cause the at least one processor to receive the transaction data associated with the at least one transaction cause the at least one processor to: receiving said transaction data associated with said at least one transaction within a first time period; and wherein the program instructions further cause the at least one processor to: receiving the historical transaction data associated with the plurality of historical transactions during a training period prior to the first period; determining at least one historical aggregate value based on at least a portion of the historical transaction data for the plurality of historical transactions based on a type of entity associated with the plurality of historical transactions; and The machine learning model is trained with the at least one historical aggregate value, wherein the machine learning model is configured to predict at least one future value of the transaction data for future transactions.

17. A computer program product according to claim 15, wherein the type of entity includes at least one of the following: a transaction account, a merchant, an acquirer, an issuer, or any combination thereof; and wherein the at least one risk mitigation process includes at least one of the following: temporarily denying future transactions associated with the entity, transmitting an alert to the entity, temporarily disabling system access to the entity, or any combination thereof.

18. The computer program product of claim 15, wherein the program instructions further cause the at least one processor to automatically and periodically update the dynamic threshold based on ongoing transactions associated with the entity.

19. The computer program product of claim 18, wherein the deviation is based at least in part on a moving standard deviation, and wherein the program instructions that cause the at least one processor to update the dynamic threshold based on the ongoing transactions associated with the entity cause the at least one processor to: determining the deviation of the at least one aggregate value from the at least one predicted aggregate value within each sub-period of a time period during which the ongoing transaction is completed to generate a plurality of deviations; and The dynamic threshold is updated after each sub-period of the time period based at least in part on a maximum of the plurality of deviations.

20. The computer program product of claim 19, wherein the program instructions further cause the at least one processor to retrain the machine learning model based on the ongoing transactions to produce an updated machine learning model, and wherein the program instructions causing the at least one processor to determine the deviation of the at least one aggregated value from the at least one predicted aggregated value within each sub-period of the time period cause the at least one processor to: The at least one predicted aggregate value for the entity is regenerated based on the updated machine learning model.

Images