Patent Application
20240232897
Increases in computing technology and availability have led to an increase in use of card-based payment transactions and electronic payment transactions to complete purchase transactions. The prevalence of card/electronic payment transactions has led to many entities providing increased access to payment cards (e.g., credit cards or debit cards) for consumers to use with merchants and other recipient entities. Additionally, in connection with providing access to payment cards to use in card-based payment transactions and electronic payment transactions, some entities provide more options for funding card-based payment transactions or other parameters of accounts associated with the payment cards. Increasing the number of options available for payment card accounts, however, also increases the complexity of managing the payment card accounts or processing transactions involving the payment card accounts.
Conventional systems that provide access to payment card accounts lack flexibility and efficiency in connection with increased complexity. For example, conventional systems are unable to process certain types of transactions based on hardware and software limitations of the conventional systems.
This disclosure describes one or more embodiments of methods, non-transitory computer readable media, and systems that solves one or more of the foregoing problems (in addition to providing other benefits). In one or more embodiments, the disclosed systems dynamically map tokens according to predicted characteristics of the transaction. Specifically, the disclosed systems access information associated with a payment account including characteristics of previous transactions associated with the payment account, which corresponds to a plurality of separate sub-accounts (e.g., a debit account and a credit account). The disclosed systems determine predicted transaction characteristics for the next future transaction based on the information associated with the payment account. Furthermore, the disclosed systems generate a request to a payment network to re-map a token associated with the payment account in connection with a selected sub-account according to the predicted transaction characteristics and a set of rules. The disclosed systems also process a subsequent transaction routed based on the re-mapped token in connection with the selected sub-account. By routing a future transaction based on a re-mapping of a token for the payment account based on predicted transaction characteristics, the disclosed systems provide flexible and efficient processing of transactions.
The detailed description refers to the drawings briefly described below.
This disclosure describes one or more embodiments of a dynamic token mapping system that dynamically remaps tokens of a payment account for future transactions based on predicted transaction characteristics. In particular, the dynamic token mapping system utilizes payment account information and account details to generate predicted transaction characteristics for a future transaction (e.g., a subsequent transaction that has not yet occurred). Additionally, the dynamic token mapping system utilizes the predicted transaction characteristics to generate a token mapping request to send to a payment network in connection with a selected sub-account of the payment account. Furthermore, in response to a subsequent transaction for the payment account, the dynamic token mapping system processes the subsequent transaction routed via the payment network based on the token mapping in connection with the selected sub-account.
As mentioned, in one or more embodiments, the dynamic token mapping system determines payment account information and account details of a payment account. For example, the dynamic token mapping system accesses the payment account information including characteristics of a plurality of previous transactions associated with the payment account. To illustrate, the payment account information includes payment amounts associated with previous transactions of one or more sub-accounts of the payment account (e.g., from an account history) and/or additional account/transaction information associated with the payment account. Additionally, the dynamic token mapping system determines the account details including one or more available balances associated with one or more sub-accounts of the payment account.
According to one or more embodiments, the dynamic token mapping system determines predicted transaction characteristics for a future transaction. In particular, the dynamic token mapping system provides the information associated with a payment account to a third-party system (e.g., a card issuer or card program manager), which utilizes a prediction model to generate predicted transactions characteristics for a future payment transaction. In alternative embodiments, the dynamic token mapping system generates the predicted transaction characteristics for a future payment transaction (e.g., utilizing a machine-learning model).
In one or more embodiments, the dynamic token mapping system utilizes the predicted transaction characteristics to generate a token mapping request to provide to a payment network. Specifically, the dynamic token mapping system utilizes the predicted transaction characteristics to determine whether the future transaction is likely to correspond to a particular sub-account of the payment account. For example, the dynamic token mapping system selects a sub-account of the payment account according to a set of rules and the account details. The dynamic token mapping system sends the request to create the token mapping to the payment network to remap a token associated with the payment account to a particular processing pipeline associated with the selected sub-account.
Furthermore, in some embodiments, the dynamic token mapping system processes a subsequent transaction routed based on a token mapping for the payment account. The dynamic token mapping system processes the subsequent transaction via the payment network to route the subsequent transaction via a processing pipeline corresponding to the remapped token. For example, the dynamic token mapping system processes the subsequent transaction via the processing pipeline of the payment network according to the selected sub-account of the payment account and the remapped token corresponding to the selected sub-account.
As mentioned, conventional systems limit token mapping functions for the creation of new accounts and expired/compromised accounts. Specifically, conventional systems include controls that restrict certain mapping operations from occurring for security purposes to prevent bad actors from gaining access to or changing access to accounts. While limiting certain types of server requests to specific circumstances improves security, such restrictions also limit the flexibility and efficiency of payment transaction processing systems. Indeed, the conventional systems are limited to handling transactions via predefined processing pipelines.
The disclosed dynamic token mapping system provides a number of benefits over conventional systems. For example, the dynamic token mapping system improves the flexibility of computing systems that manage and process payment transactions. In contrast to existing systems that limit token mapping functionality for the creation of new accounts, expired account numbers, or compromised account numbers, the dynamic token mapping system provides dynamic tokenization to process different transactions according to predicted transaction characteristics in connection with transactions with increased complexity. Specifically, the dynamic token mapping system determines predicted characteristics of a future transaction to tokenize a payment account number for dynamically selecting a processing pipeline. More specifically, by predicting the transaction characteristics of the next subsequent transaction, the dynamic token mapping system can tokenize the payment account number for use in a processing pipeline that is most likely to correspond to the next transaction. The dynamic token mapping system is thus able to generate and/or remap tokens on a transaction-by-transaction basis for processing different types of transactions in different ways.
Additionally, the disclosed dynamic token mapping system provides improved efficiency of computing systems that process transactions. In contrast to existing systems with limited token mapping functionality—and consequently rigid processing pipeline utilization—the dynamic token mapping system utilizes dynamic tokenization to optimize a transaction interchange by selecting a processing pipeline ahead of time. In particular, the dynamic token mapping system determines predicted transaction characteristics for a subsequent future transaction to determine the most likely processing pipeline for the next transaction. Accordingly, by intelligently selecting a particular processing pipeline and generating a token mapping in advance of (e.g., asynchronously with) a future transaction according to predicted transaction characteristics, the dynamic token mapping system provides improved processing efficiency for transactions involving payment accounts with separate sub-accounts, which can further improve processing speed associated with certain transactions. Furthermore, by remapping the token for a payment account in advance of a future transaction, the dynamic token mapping system more efficiently processes the future transaction during the real-time processing of the future transaction by performing the token mapping ahead of time. In some embodiments, utilizing and training a machine-learning model to predict the transaction characteristics of a future transaction provides improved accuracy of determining whether a transaction that is yet to occur should be processed via a specific processing pipeline.
Furthermore, in connection with improving the accuracy and flexibility of computing systems involved in processing transactions, the dynamic token mapping system can leverage existing hardware and software of payment network servers/devices to provide dynamic tokenization for a payment account. In particular, the dynamic token mapping system can leverage existing application programming interface protocols of the payment network to cause the payment network to remap a particular payment account to a different processing pipeline (e.g., to swap between processing pipelines for separate sub-accounts). The dynamic token mapping system thus provides additional functionality for the servers of the payment network without requiring the payment network to create add additional protocols or hardware/software.
Turning now to the figures,
As shown in
According to one or more embodiments, a payment account includes a card, such as a physical or digital object corresponding to a card program account for engaging in electronic card transactions. For instance, a card includes a physical debit/credit card and/or a digital debit/credit card (e.g., in a digital wallet) tied to a payment account (e.g., a card program account) via a card number that allows a user to initiate a payment transaction to transfer funds from the payment account to a recipient account (e.g., a merchant account) via the payment network 108. In one or more embodiments, the payment network 108 include one or more payment gateway systems, one or more card networks (e.g., MASTERCARD), and/or one or more card issuer systems (e.g., bank issuers) to process electronic card transactions in connection with the account management system 114. Furthermore, the payment network 108 include one or more servers to generate, store, and transmit data associated with initiating and processing payment transactions via the account management system 114.
As used herein, the term “account program” refers to software and data that determines when and how one or more payment accounts can be used to engage in payment transactions. For example, an account program includes a plurality of parameter configurations that define attributes of an account associated with the account program including, but not limited to, pricing (e.g., annual percentage rate), fees, usage locations, rewards, discounts, or other attributes. Accordingly, different account programs that have different parameter configurations provide different usage, benefits, etc., to users of cards/accounts corresponding to the different account programs. In some embodiments, an account program includes one or more payment accounts associated with one or more users and provides settings for utilizing payment accounts to initiate payment transactions. In additional embodiments, an payment account includes one or more processing parameters with one or more parameter ranges for processing transactions involving the payment account.
In one or more embodiments, the account management system 114 includes the dynamic token mapping system 102 to facilitate processing of electronic payment transactions via one or more processing pipelines. Specifically, the dynamic token mapping system 102 communicates with the payment network 108 (e.g., a payment network associated with the client device 106 or another device) to initiate/process a payment transaction involving a payment account. For example, the dynamic token mapping system 102 receives transaction authorization requests from the payment network 108 for authorizing card-based/electronic payment transactions initiated via client devices (e.g., the client device 106).
Additionally, the dynamic token mapping system 102 communicates with the payment network 108 via an application programming interface (“API”) to dynamically remap tokens associated with payment accounts in connection with selecting from a plurality of processing pipelines to process payment transactions. More specifically, the dynamic token mapping system 102 communicates with the payment network 108 to dynamically map a payment account for use in processing a future transaction via a particular processing pipeline. For example, the dynamic token mapping system 102 utilizes historical data associated with the payment account to intelligently remap the payment account to a particular processing pipeline corresponding to a particular sub-account of the payment account.
As used herein, the term “processing pipeline” refers to a specific set of operations performed by one or more computing devices to process a card-based/electronic payment transaction. For example, a processing pipeline includes a first set of servers/computing devices performing a first set of operations to process transactions for a debit processing pipeline. In another example, a processing pipeline includes a second set of servers/computing devices performing a second set of operations to process transactions routed for a credit processing pipeline. In one or more embodiments, the payment network 108 processes a particular payment transaction via a processing pipeline (e.g., a debit bin or a credit bin) according to a token in connection with the payment transaction.
In some instances, the dynamic token mapping system 102 communicates with the third-party system 110 to authorize payment transactions. In some embodiments, the third-party system 110 includes an external gateway and/or an external funding source. For example, the dynamic token mapping system 102 can request authorization from the third-party system 110 while also providing control over one or more aspects of the processing of a payment transaction, such as by determining processing parameters associated with the payment transaction. Additionally, the third-party system 110 can perform one or more operations associated with dynamically mapping a token for a payment account, such as by generating, utilizing, or providing a tokenizing model. In one or more embodiments, the third-party system 110 includes a separate entity external to the payment network 108 and the server(s) 104 (e.g., separate from the account management system 114 and the dynamic token mapping system 102).
Additionally, as used herein, the term “payment transaction” refers to a transaction in which a payment account funds a payment from a user to a recipient. To illustrate, a payment transaction includes a card-based transaction involving the use of a physical card or a digital card. Alternatively, a payment transaction can include an electronic transaction without a payment card, such as an ACH transaction. For instance, a payment transaction includes a transaction via a point-of-sale device or an electronic transaction via a mobile application or online application between a payment account of a user and a recipient account associated with a recipient (e.g., another user or a merchant system) in a peer-to-peer transaction or a peer-to-business transaction.
In one or more embodiments, in connection with managing cards for payment card accounts and/or processing electronic card transactions involving payment card accounts, the account management system 114 and/or the dynamic token mapping system 102 provides software and/or hardware for interacting with one or more systems or devices (e.g., the third-party system 110, a client device associated with an account program manager) in the system environment 100. For example, the dynamic token mapping system 102 provides one or more APIs for the systems or devices to dynamically map a token for a payment account for a particular payment transaction or to perform downstream operations associated with payment transactions.
In one or more embodiments, the server(s) 104 include a variety of computing devices, including those described below with reference to
In addition, in one or more embodiments, the account management system 114 and/or the dynamic token mapping system 102 are implemented on one or more servers. For example, the account management system 114 and/or the dynamic token mapping system 102 can be partially or fully implemented on a plurality of servers. To illustrate, the account management system 114 and the dynamic token mapping system 102 can be implemented in a distributed environment. In one or more embodiments, each server handles requests for managing accounts or processing payment transactions.
In one or more embodiments, the client device 106 includes a computing device that initiates electronic payment transactions via the payment network 108. For example, the client device 106 includes a user device, such as a smartphone, desktop computer, laptop, or other computing device that enables electronic payment transactions with one or more entities (e.g., via web applications or standalone applications). In some embodiments, the client device 106 includes a recipient device that hosts a web application or standalone applications and communicates with the payment network 108 to initiate electronic payment transactions. In alternative examples, the client device 106 includes a point-of-sale device including a card reader, chip reader, or other device to initiate electronic payment transactions between a sending user and a recipient user.
Additionally, as shown in
As mentioned, the dynamic token mapping system 102 provides dynamic tokenization for a payment account for a future transaction.
In one or more embodiments, as illustrated in
According to one or more embodiments, the dynamic token mapping system 102 determines a token mapping 204 for the payment account based on the predicted transaction characteristics 202. In particular, the dynamic token mapping system 102 determines whether the future transaction is likely to correspond to a particular sub-account of the payment account based on the payment account information 200 for previous transactions and/or additional data associated with the payment account. For example, the dynamic token mapping system 102 communicates with a payment network to generate a token or remap a token to a particular processing pipeline for use in processing a future transaction.
Additionally, in one or more embodiments, each sub-account of a payment account includes different limits and/or available balances. For example, the first sub-account 302a can include a first limit and a first available balance, while the second sub-account 302b can include a second limit and a second available balance. To illustrate, the first sub-account 302a can include a debit account for which the first limit is a specific amount (e.g., $5000) based on what a person has loaded into the first sub-account 302a—the first available balance may be the same as the first limit, as in the case of a debit account. Additionally, the second sub-account 302b can include a credit account for which the second limit is a specific amount (e.g., $500) with the second available balance of a different amount (e.g., $350) based on transactions that have hit the second sub-account 302b.
As illustrated in
As used herein, the term “token” refers to an identifier value representing a payment account. In one or more embodiments, a token includes a plurality of numerical values that the payment network 304 and/or other systems involved in processing transactions identify as representing a payment account. To illustrate, the payment network 304 generates a token as a 16-digit number (or other number of digits) similar to a payment account number for a corresponding payment account (e.g., to obfuscate the payment account number). A token can include a randomly generated number or a number generated according to a specific algorithm. Alternatively, a token includes any identifier that the payment network 304 and/or the dynamic token mapping system 102 utilizes to identify a particular payment account (e.g., a non-obfuscated payment account number).
In one or more embodiments, as illustrated in
In one or more embodiments, as mentioned, the dynamic token mapping system 102 provides dynamic token mapping for a payment account prior to initiation of a future payment transaction. As illustrated in
As illustrated in
According to one or more embodiments, the dynamic token mapping system 102 also performs an act 410 of determining account details for the payment account. For instance, the dynamic token mapping system 102 determines one or more sub-accounts associated with the payment account and/or one or more account types of the one or more sub-accounts. Additionally, the dynamic token mapping system 102 can determine an available balance for each sub-account of the payment account (e.g., an available credit of a credit sub-account). The dynamic token mapping system 102 can also determine historical data associated with the account details (e.g., a historical/average available balance, repayment history).
As illustrated in
In one or more embodiments, in response to receiving the account data from the dynamic token mapping system 102, the third-party system 402 performs an act 414 of generating predicted transaction characteristics for a future transaction involving the payment account. Specifically, the third-party system 402 can utilize a prediction model to predict transaction characteristics of a next subsequent payment transaction to occur for the payment account (e.g., a payment transaction that has not yet occurred). For example, the third-party system 402 generates a predicted payment amount and/or other details of the next subsequent payment transaction based on historical payment amounts/details of previous transactions. To illustrate, the third-party system 402 generates the predicted transaction characteristics based on a model or algorithm that identifies trends or specific statistics in a dataset (e.g., a regression model).
In one or more examples, the dynamic token mapping system 102 or the third-party system 402 determines an average transaction size/amount associated with the payment account based on the account history and generates the predicted transaction characteristics based on the average transaction size. In additional embodiments, the dynamic token mapping system 102 or the third-party system 402 generates a predicted transaction type, predicted transaction location, predicted recipient, or other details associated with a future transaction. To illustrate, the dynamic token mapping system 102 or the third-party system 402 utilizes characteristics of previous transactions including transaction times, recipients, geolocations, etc., to generate the predicted transaction characteristics. Additionally, the dynamic token mapping system 102 can utilize additional details such as a current time, seasonal information, recurring transactions, or other information to generate one or more predicted transaction characteristics for the future transaction.
As illustrated in
In additional embodiments, the third-party system 402 or the dynamic token mapping system 102 generates the predicted transaction characteristics by utilizing a machine-learning model trained on the account history and/or other details associated with the payment account. As used herein, the term “machine-learning model” refers to one or more computer algorithms that can be tuned (e.g., trained) based on inputs to approximate unknown functions. In particular, a machine-learning model utilizes algorithms to learn from, and make determinations on, known data by analyzing the known data to learn to generate outputs that reflect patterns and attributes of the known data. For instance, a machine-learning model can include, but is not limited to, one or more neural network layers, such as a multi-layer perceptron, a convolutional neural network, a recurrent neural network, a feed forward neural network, or any combination thereof. A machine-learning model can learn high-level abstractions in data to generate data-driven determinations, predictions, or decisions from the known input data. To illustrate, the dynamic token mapping system 102 utilizes one or more recurrent neural networks to predict characteristics of a next subsequent transaction based on parameters learned from historical transaction data of previous transactions associated with a payment account.
In one or more embodiments, the dynamic token mapping system 102 approves a prediction model at the third-party system 402. For example, in connection with generating predicted transaction characteristics for dynamically performing token mapping for a payment account, the dynamic token mapping system 102 can obtain a prediction model from the third-party system 402. The dynamic token mapping system 102 can validate the prediction model and/or perform one or more quality checks to determine whether the third-party system 402 can utilize the prediction model or should update the prediction model. To illustrate, the dynamic token mapping system 102 validates the prediction model by verifying that the prediction model generates results that fall within one or more threshold values associated with one or more ground-truth values. As an example, the dynamic token mapping system 102 validates the prediction model in response to determining that differences between predicted transaction characteristics and ground-truth transaction characteristics for a plurality of previous transactions falls within threshold values.
In some embodiments, the dynamic token mapping system 102 utilizes an additional prediction model (e.g., a separate prediction model or a copy of the prediction model from the third-party system 402) to validate the prediction model and/or the predicted transaction characteristics. To illustrate, the third-party system 402 can provide a validation model to the dynamic token mapping system 102 prior to generating predicted transaction characteristics. Additionally, in response to receiving predicted transaction characteristics for a particular future transaction, the dynamic token mapping system 102 can utilize a validation model provided by the third-party system 402 to validate/verify the predicted transaction characteristics. In some embodiments, in response to detecting a discrepancy between the predicted transaction characteristics received from the third-party system 402 and predicted transaction characteristics generated via the validation model, the dynamic token mapping system 102 notifies the third-party system 402 of the discrepancy. Additionally, the dynamic token mapping system 102 can determine not to perform a token remapping operation based on the discrepancy.
According to one or more embodiments, the dynamic token mapping system 102 performs an act 418 of selecting a sub-account of a payment account. In particular, the dynamic token mapping system 102 selects a sub-account from a plurality of sub-accounts connected to the payment account according to one or more rules based on one or more thresholds and/or comparisons. For instance, the dynamic token mapping system 102 utilizes the previously determined account details to select the sub-account. To illustrate, the dynamic token mapping system 102 determines whether the predicted transaction characteristics meet a particular threshold or risk level, such as determining whether a predicted payment amount exceeds an available balance of a particular sub-account or has a risk level below a certain value. In response to determining that the predicted transaction/payment amount of the next subsequent payment transaction does not exceed the available balance of the sub-account, the dynamic token mapping system 102 can select the sub-account. Alternatively, in response to determining that the predicted payment amount does exceed the available balance of the sub-account, the dynamic token mapping system 102 can select another sub-account.
Additionally, in some embodiments, the dynamic token mapping system 102 compares a particular predicted transaction characteristic to a threshold. For example, the dynamic token mapping system 102 can determine whether to select a particular sub-account in response to determining that a predicted transaction size (or other predicted transaction characteristic associated with the next subsequent transaction) meets a threshold multiplier of an available balance of the sub-account. To illustrate, the dynamic token mapping system 102 can select a credit sub-account in response to determining that the predicted transaction size is less than 80% (or other threshold such as 75% or 90%) of the available credit of the credit sub-account.
In additional embodiments, the dynamic token mapping system 102 utilizes additional predicted transaction characteristics (e.g., other than payment amount) to select a sub-account. For example, the dynamic token mapping system 102 can determine whether the subsequent payment transaction is likely to correspond to a particular recipient identifier, geolocation, etc. The dynamic token mapping system 102 can utilize a plurality of thresholds, comparisons, or account values to determine whether to select a particular sub-account.
According to one or more embodiments, the dynamic token mapping system 102 performs an act 420 of generating a remapping request to send to the payment network 400. In particular, the dynamic token mapping system 102 generates the remapping request including an identifier for the sub-account or an identifier of a token associated with the selected sub-account. For example, the dynamic token mapping system 102 generates an API call to the payment network 400 via the API 404 provided by the payment network 400. To illustrate, the dynamic token mapping system 102 utilizes an API corresponding to a token remapping operation provided in connection with changing a token mapping associated with the payment account at the payment network 400. As illustrated in
In one or more embodiments, the payment network 400 performs an act 424 of remapping a token for a payment account. Specifically, in response to receiving the remapping request, the payment network 400 remaps the payment account to a processing pipeline corresponding to the selected sub-account. For instance, the payment network 400 changes a stored value representing the payment account to a particular processing pipeline (e.g., debit) to the selected sub-account. Alternatively, the payment network 400 changes the stored value representing the payment account to a particular processing pipeline (e.g., credit) corresponding to the selected sub-account. In one or more embodiments, the payment network 400 stores the token mapping in advance of the next subsequent transaction. In one or more embodiments, remapping a token for a payment account involves generating/swapping a token associated with a payment account in connection with a particular processing pipeline.
As illustrated in
As illustrated in
In response to receiving the request to initiate the payment transaction, the payment network 502 performs an act 510 of sending a transaction authorization request. In one or more embodiments, the dynamic token mapping system 102 determines a mapped token corresponding to the payment transaction based on the payment transaction (e.g., by parsing the payment transaction). In some embodiments, the payment network 502 generates an additional token representing the mapped token (e.g., to further obfuscate the token) to provide to a device of an account holder. Alternatively, the payment transaction includes a separate payment token corresponding to the mapped token or based on an additional mapping between a payment account number of the payment account and the mapped token. The payment network 502 can send the transaction authorization request including the mapped token and/or a payment account number for identifying the payment account in connection with the payment transaction.
As illustrated in
As illustrated in
In one or more embodiments, as illustrated in
As mentioned, the dynamic token mapping system 102 can generate predicted transaction characteristics based on previous transactions associated with a payment account.
The dynamic token mapping system 102 provides the payment account information 600 and the account details 602 to a machine-learning model 604. For instance, as previously described, the machine-learning model 604 can include a recurrent neural network, convolutional neural network, regression model, or other model. The dynamic token mapping system 102 can train the machine-learning model 604 (e.g., learn parameters for the machine-learning model 604) based on the account details 602 and the machine-learning model 604.
To illustrate, the dynamic token mapping system 102 utilizes the machine-learning model 604 to generate predicted transaction characteristics 606 for a future transaction. For example, during training, the dynamic token mapping system 102 generates the predicted transaction characteristics 606 for a transaction that has not yet occurred. Alternatively, the dynamic token mapping system 102 generates the predicted transaction characteristics for a transaction that occurred chronologically after the account history (e.g., a past transaction that in a testing dataset separate from a training dataset).
In one or more embodiments, as illustrated in
Additionally, in connection with comparing the predicted transaction characteristics 606 to the ground-truth transaction characteristics 608, the dynamic token mapping system 102 determines a loss 610. For example, the dynamic token mapping system 102 determines one or more value differences between the predicted transaction characteristics 606 and the ground-truth transaction characteristics 608. Furthermore, the dynamic token mapping system 102 can utilize one or more loss functions to determine the loss 610 based on the difference, such as, but not limited to, a mean absolute error loss function or a mean squared error loss function. The dynamic token mapping system 102 can utilize the loss to further train the machine-learning model 604 (e.g., by learning/modifying parameters of the machine-learning model 604).
The dynamic token mapping system 102 can thus train the machine-learning model 604 and utilize the machine-learning model 604 to dynamically map tokens for processing payment accounts. By training the machine-learning model 604 based on an account history and/or other details associated with a payment account, the dynamic token mapping system 102 can train the machine-learning model 604 to learn factors such as time of day, seasonality, geolocation, etc., that may indicate what the transaction characteristics of the next subsequent payment transaction are likely to be. The dynamic token mapping system 102 can continue improving the machine-learning model 604 after each new transaction (or after a batch of transactions) to learn new trends for the payment account.
Turning now to
As shown in
Act 702 can involve determining a credit score associated with the payment account, recipient information of the plurality of previous transactions, geographical locations associated with the plurality of previous transactions, payment amounts associated with the plurality of previous payment transactions, or available balances of the plurality of separate sub-accounts.
The series of acts 700 also includes an act 704 of determining predicted transaction characteristics for a future transaction. For example, act 704 involves determining, by the one or more servers of the account management system, predicted transaction characteristics for a future transaction based on the information associated with the payment account.
Act 704 can involve generating, utilizing a prediction model, a predicted transaction amount associated with the future transaction according to a plurality of transaction amounts associated with the plurality of previous transactions. Act 704 can involve generating, utilizing a machine-learning model comprising parameters trained utilizing the information associated with the payment account, the predicted transaction characteristics for the future transaction according to one or more trends in the information associated with the payment account. For example, act 704 can involve determining, utilizing a machine-learning model, a predicted transaction amount for the future transaction according to the transaction amounts of the plurality of previous transactions.
Act 704 can involve determining an average transaction amount of the plurality of previous transactions associated with the payment account. Act 704 can further involve determining the predicted transaction characteristics based on the average transaction amount.
Act 704 can involve providing the information associated with the payment account to a third-party system corresponding to the payment account. Act 704 can also involve receiving the predicted transaction characteristics for the future transaction from the third-party system.
Act 704 can involve validating a prediction model provided by a third-party system corresponding to the payment account via one or more quality checks. Act 704 can also involve determining the predicted transaction characteristics utilizing the prediction model based on validating the prediction model.
Act 704 can involve receiving a validation model from the third-party system in connection with a prediction model that the third-party system utilizes to generate predicted transaction characteristics for future transactions. Act 704 can also involve validating, utilizing the validation model, predicted transaction characteristics received from the third-party system.
Additionally, the series of acts 700 includes an act 706 of generating a request to create a token mapping according to the predicted transaction characteristics. For example, act 706 involves generating, by the one or more servers of the account management system, a request to a payment network to create a token mapping in connection with a selected sub-account of the payment account according to the predicted transaction characteristics for the future transaction and a set of rules.
Act 706 can involve determining that the predicted transaction characteristics correspond to a sub-account of a plurality of sub-accounts of the payment account according to account details of the sub-account of the plurality of sub-accounts. Act 706 can involve selecting the sub-account of the plurality of sub-accounts of the payment account in response to determining that the predicted transaction characteristics correspond to the sub-account of the plurality of sub-accounts. Act 706 can also involve generating, via an application programming interface call to the payment network, the request to create the token mapping in connection with the selected sub-account of the plurality of sub-accounts.
Act 706 can involve determining one or more characteristics of the sub-account of the plurality of sub-accounts based on the information associated with the payment account. Act 706 can also involve comparing the predicted transaction characteristics to the one or more characteristics of the sub-account.
Act 706 can involve determining that the predicted transaction characteristics correspond to a credit sub-account of the payment account. For example, act 706 can involve determining that a predicted payment amount of the future transaction is less than an available balance of the credit sub-account. Act 706 can also involve generating, via an application programming interface call to the payment network, the request to create the token mapping in connection with the credit sub-account of the payment account.
Act 706 can involve detecting a change to one or more account details associated with the payment account. Act 706 can involve accessing the information associated with the payment account to determine the characteristics of the plurality of previous transactions in response to the change to the one or more account details associated with the payment account. For example, act 706 can involve detecting a token remapping event comprising an indication of a completed payment transaction for the payment account, a request to remap a token for the payment account, or an indication of changes to account details associated with the payment account. Act 706 can also involve accessing the information associated with the payment account to determine the characteristics of the plurality of previous transactions in response to the token remapping event.
The series of acts 700 further includes an act 708 of processing a subsequent transaction routed based on the token mapping. For example, act 708 involves processing, by the one or more servers of the account management system, a subsequent transaction routed based on the token mapping in connection with the selected sub-account. Act 708 can also involve sending, in connection with routing the subsequent transaction, the token corresponding to the credit sub-account to the payment network to process via a processing pipeline corresponding to the credit sub-account.
Embodiments of the present disclosure may comprise or utilize a special purpose or general-purpose computer including computer hardware, such as, for example, one or more processors and system memory, as discussed in greater detail below. Embodiments within the scope of the present disclosure also include physical and other computer-readable media for carrying or storing computer-executable instructions and/or data structures. In particular, one or more of the processes described herein may be implemented at least in part as instructions embodied in a non-transitory computer-readable medium and executable by one or more computing devices (e.g., any of the media content access devices described herein). In general, a processor (e.g., a microprocessor) receives instructions, from a non-transitory computer-readable medium, (e.g., a memory, etc.), and executes those instructions, thereby performing one or more processes, including one or more of the processes described herein.
Computer-readable media can be any available media that can be accessed by a general purpose or special purpose computer system. Computer-readable media that store computer-executable instructions are non-transitory computer-readable storage media (devices). Computer-readable media that carry computer-executable instructions are transmission media. Thus, by way of example, and not limitation, embodiments of the disclosure can comprise at least two distinctly different kinds of computer-readable media: non-transitory computer-readable storage media (devices) and transmission media.
Non-transitory computer-readable storage media (devices) includes RAM, ROM, EEPROM, CD-ROM, solid state drives (“SSDs”) (e.g., based on RAM), Flash memory, phase-change memory (“PCM”), other types of memory, other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store desired program code means in the form of computer-executable instructions or data structures and which can be accessed by a general purpose or special purpose computer.
A “network” is defined as one or more data links that enable the transport of electronic data between computer systems and/or modules and/or other electronic devices. When information is transferred or provided over a network or another communications connection (either hardwired, wireless, or a combination of hardwired or wireless) to a computer, the computer properly views the connection as a transmission medium. Transmissions media can include a network and/or data links which can be used to carry desired program code means in the form of computer-executable instructions or data structures and which can be accessed by a general purpose or special purpose computer. Combinations of the above should also be included within the scope of computer-readable media.
Further, upon reaching various computer system components, program code means in the form of computer-executable instructions or data structures can be transferred automatically from transmission media to non-transitory computer-readable storage media (devices) (or vice versa). For example, computer-executable instructions or data structures received over a network or data link can be buffered in RAM within a network interface module (e.g., a “NIC”), and then eventually transferred to computer system RAM and/or to less volatile computer storage media (devices) at a computer system. Thus, it should be understood that non-transitory computer-readable storage media (devices) can be included in computer system components that also (or even primarily) utilize transmission media.
Computer-executable instructions comprise, for example, instructions and data which, when executed at a processor, cause a general-purpose computer, special purpose computer, or special purpose processing device to perform a certain function or group of functions. In some embodiments, computer-executable instructions are executed on a general-purpose computer to turn the general-purpose computer into a special purpose computer implementing elements of the disclosure. The computer executable instructions may be, for example, binaries, intermediate format instructions such as assembly language, or even source code. Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the described features or acts described above. Rather, the described features and acts are disclosed as example forms of implementing the claims.
Those skilled in the art will appreciate that the disclosure may be practiced in network computing environments with many types of computer system configurations, including, personal computers, desktop computers, laptop computers, message processors, hand-held devices, multi-processor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, mobile telephones, PDAs, tablets, pagers, routers, switches, and the like. The disclosure may also be practiced in distributed system environments where local and remote computer systems, which are linked (either by hardwired data links, wireless data links, or by a combination of hardwired and wireless data links) through a network, both perform tasks. In a distributed system environment, program modules may be located in both local and remote memory storage devices.
Embodiments of the present disclosure can also be implemented in cloud computing environments. In this description, “cloud computing” is defined as a model for enabling on-demand network access to a shared pool of configurable computing resources. For example, cloud computing can be employed in the marketplace to offer ubiquitous and convenient on-demand access to the shared pool of configurable computing resources. The shared pool of configurable computing resources can be rapidly provisioned via virtualization and released with low management effort or service provider interaction, and then scaled accordingly.
A cloud-computing model can be composed of various characteristics such as, for example, on-demand self-service, broad network access, resource pooling, rapid elasticity, measured service, and so forth. A cloud-computing model can also expose various service models, such as, for example, Software as a Service (“SaaS”), Platform as a Service (“PaaS”), and Infrastructure as a Service (“IaaS”). A cloud-computing model can also be deployed using different deployment models such as private cloud, community cloud, public cloud, hybrid cloud, and so forth. In this description and in the claims, a “cloud-computing environment” is an environment in which cloud computing is employed.
In one or more embodiments, the processor 802 includes hardware for executing instructions, such as those making up a computer program. As an example, and not by way of limitation, to execute instructions for dynamically modifying workflows, the processor 802 may retrieve (or fetch) the instructions from an internal register, an internal cache, the memory 804, or the storage device 806 and decode and execute them. The memory 804 may be a volatile or non-volatile memory used for storing data, metadata, and programs for execution by the processor(s). The storage device 806 includes storage, such as a hard disk, flash disk drive, or other digital storage device, for storing data or instructions for performing the methods described herein.
The I/O interface 808 allows a user to provide input to, receive output from, and otherwise transfer data to and receive data from computing device 800. The I/O interface 808 may include a mouse, a keypad or a keyboard, a touch screen, a camera, an optical scanner, network interface, modem, other known I/O devices or a combination of such I/O interfaces. The I/O interface 808 may include one or more devices for presenting output to a user, including, but not limited to, a graphics engine, a display (e.g., a display screen), one or more output drivers (e.g., display drivers), one or more audio speakers, and one or more audio drivers. In certain embodiments, the I/O interface 808 is configured to provide graphical data to a display for presentation to a user. The graphical data may be representative of one or more graphical user interfaces and/or any other graphical content as may serve a particular implementation.
The communication interface 810 can include hardware, software, or both. In any event, the communication interface 810 can provide one or more interfaces for communication (such as, for example, packet-based communication) between the computing device 800 and one or more other computing devices or networks. As an example, and not by way of limitation, the communication interface 810 may include a network interface controller (NIC) or network adapter for communicating with an Ethernet or other wire-based network or a wireless NIC (WNIC) or wireless adapter for communicating with a wireless network, such as a WI-FI.
Additionally, the communication interface 810 may facilitate communications with various types of wired or wireless networks. The communication interface 810 may also facilitate communications using various communication protocols. The communication infrastructure 812 may also include hardware, software, or both that couples components of the computing device 800 to each other. For example, the communication interface 810 may use one or more networks and/or protocols to enable a plurality of computing devices connected by a particular infrastructure to communicate with each other to perform one or more aspects of the processes described herein. To illustrate, the digital content campaign management process can allow a plurality of devices (e.g., a client device and server devices) to exchange information using various communication networks and protocols for sharing information such as electronic messages, user interaction information, engagement metrics, or campaign management resources.
In the foregoing specification, the present disclosure has been described with reference to specific exemplary embodiments thereof. Various embodiments and aspects of the present disclosure(s) are described with reference to details discussed herein, and the accompanying drawings illustrate the various embodiments. The description above and drawings are illustrative of the disclosure and are not to be construed as limiting the disclosure. Numerous specific details are described to provide a thorough understanding of various embodiments of the present disclosure.
The present disclosure may be embodied in other specific forms without departing from its spirit or essential characteristics. The described embodiments are to be considered in all respects only as illustrative and not restrictive. For example, the methods described herein may be performed with less or more steps/acts or the steps/acts may be performed in differing orders. Additionally, the steps/acts described herein may be repeated or performed in parallel with one another or in parallel with different instances of the same or similar steps/acts. The scope of the present application is, therefore, indicated by the appended claims rather than by the foregoing description. All changes that come within the meaning and range of equivalency of the claims are to be embraced within their scope.
