Description: The present disclosure relates to artificial intelligence-based processing systems and, more particularly, to electronic methods and complex processing systems for categorizing account holders under multiple classes or segments by utilizing distinct machine learning scores.
BACKGROUND
Nowadays, with the ever-increasing number of cashless payments, the categorization or segmentation of account holders (otherwise also referred to as cardholders) is becoming important for banking and/or financial institutions such as issuers. As may be understood, account holder segmentation refers to a process of dividing account holders into groups based on common characteristics. More specifically, segmentation may be done based on historical transaction patterns. For instance, it can entail identifying loyal cardholders, regular buyers, large spenders, cardholders who make sporadic or occasional transactions, and the like. Further, it may be noted that segments can be formed utilizing data such as purchase frequency, transaction amounts, purchase dates, etc. Thus, it should be understood that each of these traits may be utilized to create well-defined clusters with features that are simple to understand for banking institutions. The characteristics of such segments can have a lot of insights and commercial value for different businesses or institutions. For example, businesses may utilize these segments to enhance income through customized promotional messages, client retention efforts, loyalty programs, and the like. Additionally, businesses may use customer categories to do cross-selling or up-selling. For example, they can provide expensive substitutes for often-purchased things or add-ons to already purchased items. These strategies may all be utilized by businesses or financial institutions to increase their revenue and cardholder retention.
To that end, it may be noted that conventionally there exist multiple approaches for segmenting cardholders including expert judgments, mathematical models, big data analysis approaches such as text and sentiment analysis with the goal of grouping customers based on their behavioral similarities, etc. However, one of the drawbacks of such conventional approaches is providing the same segments are used for different goals, resulting in inaccurate results from such implementations which are often disagreeable.
Further, with the evolution of technology, numerous techniques are employed to make the segmentation goal specific to offset the aforementioned limitation. However, one of the drawbacks of such conventional techniques is that they merely consider a particular characteristic at a time when determining similarities between different cardholders. As a result, accuracy in decision-making for accomplishing the goal is compromised since other significant factors are not considered. For instance, one of the traditional profile systems used in the banking industry uses decision tree models to help banks make proper loan offers and reduce loan defaults. In this method, a credit risk score assigned to the relevant cardholder is utilized to determine whether or not the cardholder is eligible for a loan or not.
It should be emphasized, nevertheless, that a credit risk score alone does not provide a full picture of a cardholder’s lending eligibility. For instance, a cardholder with a low-risk score may have limited credit utilization, being an inactive user of their payment cards (such as credit cards, debit cards, etc.), and hence not be a prospective candidate who will accept loans. Yet, based on the aforementioned conventional techniques, these cardholders qualify for loans due to their lower credit risk score. As a consequence, these cardholders receive superfluous calls from customer service providing loan advice and recommendations. Therefore, the conventional techniques are not only ineffective and unreliable but also make cardholders unhappy since they get invasive loan calls, emails, texts, etc.
Thus, there exists a need for technical solutions such as methods and systems for categorizing account holders while overcoming the aforementioned technical drawbacks.
SUMMARY
Various embodiments of the present disclosure provide methods and systems for categorizing account holders under multiple classes or segments utilizing distinct scores.
In an embodiment, a computer-implemented method for categorizing account holders under multiple classes or segments utilizing distinct scores is disclosed. The computer-implemented method performed by a server system includes accessing a plurality of account-related features, a set of Top-of-Wallet (TOW) embeddings, and a TOW score corresponding to each account holder of a plurality of account holders from a database associated with the server system. The computer-implemented method further includes assigning a TOW segment from one or more TOW segments to each account holder based, at least in part, on the TOW score corresponding to each account holder. Herein, each TOW segment corresponds to an individual TOW label. The computer-implemented method further includes generating a combined feature vector for each account holder from one or more TOW segments based, at least in part, on concatenating the plurality of account-related features, the set of TOW embeddings, and the corresponding TOW label of the TOW segment of each account holder.
The computer-implemented method further includes generating, by a credit risk-and-exposure (CRE) categorization Machine Learning (ML) model associated with the server system, a set of CRE embeddings for each account holder based, at least in part, on the combined feature vector. The computer-implemented method further includes determining, by the CRE categorization ML model, a CRE score corresponding to each account holder based, at least in part, on the set of CRE embeddings and a CRE threshold criteria. Herein, the CRE score indicates the likelihood of the corresponding account holder belonging to a particular CRE class. The computer-implemented method further includes assigning a CRE class from one or more CRE classes to each account holder based, at least in part, on the CRE score corresponding to each account holder. Herein, each CRE class corresponds to an individual CRE label.
In another embodiment, a server system is disclosed. The server system includes a communication interface and a memory including executable instructions. The server system also includes a processor communicably coupled to the memory. The processor is configured to execute the instructions to cause the server system, at least in part, to access a plurality of account-related features, a set of Top-of-Wallet (TOW) embeddings, and a TOW score corresponding to each account holder of a plurality of account holders from a database associated with the server system. The server system is further caused to assign a TOW segment from one or more TOW segments to each account holder based, at least in part, on the TOW score corresponding to each account holder. Herein, each TOW segment corresponds to an individual TOW label.
The server system is further caused to generate a combined feature vector for each account holder from the one or more TOW segments based, at least in part, on concatenating the plurality of account-related features, the set of TOW embeddings, and the corresponding TOW label of the TOW segment of each account holder. The server system is further caused to generate, by a credit risk-and-exposure (CRE) categorization Machine Learning (ML) model associated with the server system, a set of CRE embeddings for each account holder based, at least in part, on the combined feature vector. The server system is further caused to determine, by the CRE categorization ML model, a CRE score corresponding to each account holder based, at least in part, on the set of CRE embeddings and CRE threshold criteria. Herein, the CRE score indicates the likelihood of the corresponding account holder belonging to a particular CRE class. The server system is further caused to assign a CRE class from one or more CRE classes to each account holder based, at least in part, on the CRE score corresponding to each account holder, each CRE class corresponding to an individual CRE label.
In yet another embodiment, a non-transitory computer-readable storage medium is disclosed. The non-transitory computer-readable storage medium includes computer-executable instructions that, when executed by at least a processor of a server system, cause the server system to perform a method. The method includes accessing a plurality of account-related features, a set of Top-of-Wallet (TOW) embeddings, and a TOW score corresponding to each account holder of a plurality of account holders from a database associated with the server system. The method further includes assigning a TOW segment from one or more TOW segments to each account holder based, at least in part, on the TOW score corresponding to each account holder. Herein, each TOW segment corresponds to an individual TOW label. The method further includes generating a combined feature vector for each account holder from one or more TOW segments based, at least in part, on concatenating the plurality of account-related features, the set of TOW embeddings, and the corresponding TOW label of the TOW segment of each account holder.
The method further includes generating, by a credit risk-and-exposure (CRE) categorization Machine Learning (ML) model associated with the server system, a set of CRE embeddings for each account holder based, at least in part, on the combined feature vector. The method further includes determining, by the CRE categorization ML model, a CRE score corresponding to each account holder based, at least in part, on the set of CRE embeddings and a CRE threshold criteria. Herein, the CRE score indicates the likelihood of the corresponding account holder belonging to a particular CRE class. The method further includes assigning a CRE class from one or more CRE classes to each account holder based, at least in part, on the CRE score corresponding to each account holder. Herein, each CRE class corresponds to an individual CRE label.
BRIEF DESCRIPTION OF THE FIGURES
For a more complete understanding of example embodiments of the present technology, reference is now made to the following descriptions taken in connection with the accompanying drawings in which:
FIG. 1A illustrates a schematic representation of an environment related to at least some example embodiments of the present disclosure;
FIG. 1B illustrates a block diagram representation illustrating different Top-of-Wallet (TOW) segments and different credit risk-and-exposure (CRE) classes, in accordance with an embodiment of the present disclosure;
FIG. 2 illustrates a simplified block diagram of a server system, in accordance with an embodiment of the present disclosure;
FIG. 3A illustrates a process flow diagram for training and optimizing a TOW segmentation Machine Learning (ML) model to perform a TOW segmentation task, in accordance with an embodiment of the present disclosure;
FIG. 3B illustrates a process flow diagram for training and optimizing a CRE categorization ML model to perform a CRE categorization task, in accordance with an embodiment of the present disclosure;
FIG. 4 illustrates a schematic representation of an architecture of a TOW segmentation ML model, in accordance with an embodiment of the present disclosure;
FIG. 5 illustrates a schematic representation of an architecture of a CRE categorization ML model, in accordance with an embodiment of the present disclosure;
FIG. 6 illustrates a flow diagram depicting a method for categorizing account holders under multiple classes or segments utilizing distinct scores, in accordance with an embodiment of the present disclosure; and
FIG. 7 illustrates a simplified block diagram of a payment server, in accordance with an embodiment of the present disclosure.
The drawings referred to in this description are not to be understood as being drawn to scale except if specifically noted, and such drawings are only exemplary in nature.

DETAILED DESCRIPTION
In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present disclosure. It will be apparent, however, to one skilled in the art that the present disclosure can be practiced without these specific details. Descriptions of well-known components and processing techniques are omitted so as to not unnecessarily obscure the embodiments herein. The examples used herein are intended merely to facilitate an understanding of ways in which the embodiments herein may be practiced and to further enable those of skill in the art to practice the embodiments herein. Accordingly, the examples should not be construed as limiting the scope of the embodiments herein.
Reference in this specification to “one embodiment” or “an embodiment” means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present disclosure. The appearances of the phrase “in an embodiment” in various places in the specification are not necessarily all referring to the same embodiment, nor are separate or alternative embodiments mutually exclusive of other embodiments. Moreover, various features are described which may be exhibited by some embodiments and not by others. Similarly, various requirements are described which may be requirements for some embodiments but not for other embodiments.
Moreover, although the following description contains many specifics for the purposes of illustration, anyone skilled in the art will appreciate that many variations and/or alterations to said details are within the scope of the present disclosure. Similarly, although many of the features of the present disclosure are described in terms of each other, or in conjunction with each other, one skilled in the art will appreciate that many of these features can be provided independently of other features. Accordingly, this description of the present disclosure is set forth without any loss of generality to, and without imposing limitations upon, the present disclosure.
Embodiments of the present disclosure may be embodied as an apparatus, a system, a method, or a computer program product. Accordingly, embodiments of the present disclosure may take the form of an entire hardware embodiment, an entire software embodiment (including firmware, resident software, micro-code, etc.), or an embodiment combining software and hardware aspects that may all generally be referred to herein as a “circuit”, “engine”, “module”, or “system”. Furthermore, aspects of the present disclosure may take the form of a computer program product embodied in one or more computer-readable storage media having computer-readable program code embodied thereon.
The terms “account holder”, “user”, “cardholder”, “consumer”, and “buyer” are used interchangeably throughout the description and refer to a person who has a payment account or at least one payment card (e.g., credit card, debit card, etc.) may or may not be associated with the payment account, that will be used by a merchant to complete the payment transaction that may be initiated by the cardholder. The payment account may be opened via an issuing bank or an issuer server.
The term “merchant”, used throughout the description generally refers to a seller, a retailer, a purchase location, an organization, or any other entity that is in the business of selling goods or providing services, and it can refer to either a single business location or a chain of business locations of the same entity.
The term “payment account” used throughout the description refers to a financial account that is used to fund a financial transaction interchangeably referred to as “payment transaction” or “transaction”). Examples of the financial account include but are not limited to a savings account, a credit account, a checking account, and a virtual payment account. The financial account may be associated with an entity such as an individual person, a family, a commercial entity, a company, a corporation, a governmental entity, a non-profit organization, and the like. In some scenarios, the financial account may be a virtual or temporary payment account that can be mapped or linked to a primary financial account, such as those accounts managed by payment wallet service providers, and the like.
The term “issuer”, used throughout the description, refers to a financial institution normally called an “issuer bank” or “issuing bank” in which an individual or an institution may have an account. The issuer also issues a payment card, such as a credit card or a debit card, etc. Further, the issuer may also facilitate online banking services such as electronic money transfer, bill payment, etc., to the account holders through a server called “issuer server” throughout the description. The terms “issuer”, “issuer bank”, “issuing bank” or “issuer server” will be used interchangeably herein.
Further, the term “acquirer”, is a financial institution (e.g., a bank) that processes financial transactions for merchants. In other words, this can be an institution that facilitates the processing of payment transactions for physical stores, merchants, or institutions that own platforms that make either online purchases or purchases made via software applications possible (e.g., the shopping cart platform providers and the in-app payment processing providers). The terms “acquirer”, “acquirer bank”, “acquiring bank” or “acquirer server” will be used interchangeably herein.
The terms “payment network” and “card network” are used interchangeably throughout the description and refer to a network or collection of systems used for the transfer of funds through the use of cash substitutes. Payment networks may use a variety of different protocols and procedures in order to process the transfer of money for various types of transactions. Payment networks are companies that connect an issuing bank with an acquiring bank to facilitate online payment. Transactions that may be performed via a payment network may include product or service purchases, credit purchases, debit transactions, fund transfers, account withdrawals, etc. Payment networks may be configured to perform transactions via cash substitutes that may include payment cards, letters of credit checks, financial accounts, etc. Examples of networks or systems configured to perform as payment networks include those operated by such as Mastercard®.
The term “payment card”, used throughout the description, refers to a physical or virtual card that may or may not be linked with a financial or payment account that may be presented to a merchant or any such facility to fund a financial transaction via the associated payment account. Examples of payment cards include, but are not limited to, debit cards, credit cards, prepaid cards, virtual payment numbers, virtual card numbers, forex cards, charge cards, e-wallet cards, and stored-value cards. A payment card may be a physical card that may be presented to the merchant for funding the payment. Alternatively, or additionally, the payment card may be embodied in the form of data stored in a user device, where the data is associated with a payment account such that the data can be used to process the financial transaction between the payment account and a merchant’s financial account.
The term “payment transaction” refers to an agreement that is carried out between a buyer and a seller to exchange goods or services in exchange for assets in the form of a payment (e.g., cash, fiat-currency, digital asset, cryptographic currency, coins, tokens, etc.).
The terms “Neural Network” and “Artificial Neural Network” may have been used interchangeably throughout the description and refer to a software solution that leverages Machine Learning (ML) algorithms to mimic the operations of a human brain. Moreover, neural networks process data more efficiently and feature improved pattern recognition and problem-solving capabilities when compared to traditional computers.
The terms “categorization”, “segmentation”, “grouping”, and “classification” may have been used interchangeably throughout the description and refer to an act of sorting and organizing things according to group, class, or category. More specifically, in machine learning, it may be referred to as a technique of splitting customers into separate groups depending on their attributes or behavior.
OVERVIEW
Various embodiments of the present disclosure provide methods, systems electronic devices, and computer program products for categorizing account holders under multiple classes or segments utilizing distinct scores. In a specific embodiment, the server system may be embodied within a payment server associated with a payment network. Further, in an embodiment, the server system is configured to access an account holder-related dataset from a database associated with the server system. Herein, the account holder-related dataset may include historical information corresponding to a plurality of payment transactions performed by the plurality of account holders. Each account holder may have one or more financial accounts at one or more issuers. The server system may be further configured to generate the plurality of account holder-related features corresponding to each account holder based, at least in part, on the account holder-related dataset. In an embodiment, the plurality of account holder-related features may include a plurality of payment transaction-related features and the plurality of account-related features. Finally, the server system may store the plurality of account holder-related features for each account holder in the database.
In a specific embodiment, the plurality of payment transaction-related features may include a card entry mode, card presence status, a merchant category, a transaction amount, a count of total transactions, a count of approved transactions, a count of declined transactions, a count of fraudulent transactions, and the like. Further, the plurality of account-related features may include days past due, balance past due, credit balance, partial payments, product type, age of an account holder, and the like.
It may be noted that, in an embodiment, initially, the server system may be configured to access the plurality of payment transaction-related features corresponding to each account holder from the database. The server system may then generate a set of Top-of-Wallet (TOW) embeddings based, at least in part, on the plurality of payment transaction-related features. In an embodiment, the server system may generate the set of TOW embedding using a TOW segmentation Machine Learning (ML) model associated with the server system.
Further, in an embodiment, the TOW segmentation ML model may determine the TOW score corresponding to each account holder based, at least in part, on the set of TOW embeddings and TOW threshold criteria. Herein, the TOW score may indicate a likelihood of the corresponding account holder belonging to a particular TOW segment. Finally, the server system may store the set of TOW embeddings and the TOW score corresponding to each account holder in the database which can be accessed whenever required.
As may be understood, prior to using the TOW segmentation ML model, the TOW segmentation ML model may have to be trained for performing a TOW segmentation task. Therefore, in an embodiment, the server system is configured to access a training dataset from the database. In an embodiment, the training dataset may include historical information related to the plurality of payment transactions performed by the plurality of account holders within a predefined time period and a true TOW label for each account holder. The server system is further configured to train the TOW segmentation ML model by performing a first set of operations iteratively until the performance of the TOW segmentation ML model converges to first predefined criteria. The first set of operations may include: (1) initializing the TOW segmentation ML model based, at least in part, on one or more first model parameters, (2) generating, by the TOW segmentation ML model, set of training TOW embeddings based, at least in part, on the training dataset, (3) generating, by the TOW segmentation ML model, a TOW segment prediction for each account holder based, at least in part, on the set of training TOW embeddings, the TOW segment prediction indicating a predicted TOW label for each account holder, (4) computing a TOW loss for each account holder based, at least in part, on the predicted TOW label for each account holder and the true TOW label for each account holder. (5) computing, by the TOW segmentation ML model, a TOW gradient component for each account holder based, at least in part, on back-propagating the TOW loss, and (6) optimizing, by the TOW segmentation ML model, the one or more first model parameters based, at least in part, on the TOW loss and the TOW gradient component.
Further, in an embodiment, the server system may access the plurality of account-related features, the set of TOW embeddings, and the TOW score corresponding to each account holder from the database. The server system may further assign a TOW segment from one or more TOW segments to each account holder based, at least in part, on the TOW score corresponding to each account holder. Herein, each TOW segment corresponds to an individual TOW label.
Furthermore, the server system may generate a combined feature vector for each account holder from the one or more TOW segments based, at least in part, on concatenating the plurality of account-related features, the set of TOW embeddings, and the corresponding TOW label of the TOW segment of each account holder. Moreover, the server system may generate a set of credit risk-and-exposure (CRE) embeddings for each account holder based, at least in part, on the combined feature vector. In an embodiment, the server system may generate the set of CRE embeddings using a CRE categorization ML model associated with the server system.
However, it may be noted that prior to using the CRE categorization ML model it may have to be trained for performing a CRE categorization task. Therefore, the server system may be configured to access a training dataset from the database. Herein, the training dataset may include historical information related to a plurality of payment transactions performed by the plurality of account holders within a predefined time period and a true CRE label for each account holder. The server system is further configured to train the CRE categorization ML model by performing a second set of operations iteratively until the performance of the CRE categorization ML model converges to second predefined criteria. Herein, the second set of operations may include (1) initializing, the CRE categorization ML model based, at least in part, on one or more second model parameters, (2) generating, by the CRE categorization ML model, a set of training CRE embeddings based, at least in part, on the training dataset, (3) generating, by the CRE categorization ML model, a CRE class prediction for each account holder based, at least in part, on the set of training CRE embeddings, the CRE class prediction indicating a predicted CRE label for each account holder, (4) computing a CRE loss for each account holder based, at least in part, on the predicted CRE label for each account holder and the true CRE label for each account holder, (5) computing a CRE gradient component for each Account holder based, at least in part, on back-propagating the CRE loss, and (6) optimizing the one or more second model parameters based, at least in part, on the CRE loss and the CRE gradient component.
Later, in an example embodiment, the server system may determine, by the CRE categorization ML model, a CRE score corresponding to each account holder based, at least in part, on the set of CRE embeddings and CRE threshold criteria, Herein, the CRE score may indicate a likelihood of the corresponding account holder belonging to a particular CRE class. Further, the server system may assign a CRE class from one or more CRE classes to each account holder based, at least in part, on the CRE score corresponding to each account holder. Herein, each CRE class corresponds to an individual CRE label. Moreover, it may be noted that the TOW segmentation ML model and the CRE categorization ML model may correspond to a feed-forward neural network-based ML model that can be trained to perform the TOW segmentation task and the CRE categorization task, respectively.
Various embodiments of the present disclosure offer multiple advantages and technical effects. For instance, the present disclosure aims to solve the technical problem of how to classify merchants into different categories or classes efficiently. The present disclosure solves this technical problem by providing an approach for categorizing account holders under multiple classes or segments utilizing distinct scores. Further, the present disclosure provides various technical effects such as generating goal-specific or task-specific segments for achieving the corresponding goals. It is understood that such goal-specific or task-specific segments perform the desired task with higher accuracy. Further, the overall accuracy while performing decision-making based on the task-specific segments is improved as well. In an exemplary implementation, in the financial sector, if loan eligibility criteria are determined using only one factor such as the credit risk associated with different account holders, then the same would not provide accurate results. However, according to the present approach if multiple scores or criteria are used for determining the loan eligibility criteria, such as credit risk, credit exposure, Top-of-Wallet segmentation, etc., and the like, then the overall accuracy of the loan eligibility criteria determined for different account holders would be more accurate. In other words, the account holder that may get categorized to be the most deserving candidate for a loan would actually need the same and will be capable of paying the loan back. Thus, reducing the risk for the issuer of the loan.
Therefore, it may be noted that the proposed approach in the present disclosure when used to perform various classification tasks provides highly accurate, reliable, and efficient results. Upon obtaining accurately categorized lists of cardholders, issuers, and other financial institutions can easily make different strategies for different categories based on what best suits the corresponding category. Considering that, it may be noted that personalization of the experience of cardholders with banks and the services they provide improves significantly. In addition, the present invention provides a joint process to generate at least three different scores in a memory and resource-efficient manner.
Various example embodiments of the present disclosure are described hereinafter with reference to FIGS. 1 to 7.
FIG. 1A illustrates a schematic representation of an environment 100 related to at least some example embodiments of the present disclosure. Although the environment 100 is presented in one arrangement, other embodiments may include the parts of the environment 100 (or other parts) arranged otherwise depending on, for example, generating a set of Top-of-wallet (TOW) embeddings based on payment transaction-related features, determining a TOW score for each account holder, assigning a TOW segment from one or more TOW segments to each account holder, generating a combined feature vector, generating a set of credit risk-and-exposure (CRE) embeddings, determining a CRE score corresponding to each account holder, assigning a CRE class from one or more CRE classes to each account holder, and the like.
The environment 100 generally includes a plurality of entities such as a server system 102, a plurality of account holders 104(1), 104(2), … 104(N) (collectively referred to hereinafter as a ‘plurality of account holders 104’ or simply ‘account holders 104’), a plurality of merchants 106(1), 106(2), … 106(N) (collectively referred to hereinafter as a ‘plurality of merchants 106’ or simply ‘merchants 106’), a plurality of issuer servers 108(1), 108(2), … 108(N) (collectively referred to hereinafter as a ‘plurality of issuer servers 108’ or simply ‘issuer servers 108’), a plurality of acquirer servers 110(1), 110(2), … 110(N) (collectively referred to hereinafter as a ‘plurality of acquirer servers 110’ or simply ‘acquirer servers 110’), a payment network 112 including a payment server 114, and a database 116 each coupled to, and in communication with (and/or with access to) a network 118. Herein, it may be noted that ‘N’ is a non-zero natural number. The network 118 may include, without limitation, a Light Fidelity (Li-Fi) network, a Local Area Network (LAN), a Wide Area Network (WAN), a Metropolitan Area Network (MAN), a satellite network, the Internet, a fiber optic network, a coaxial cable network, an infrared (IR) network, a Radio Frequency (RF) network, a virtual network, and/or another suitable public and/or private network capable of supporting communication among two or more of the parts or users illustrated in FIG. 1A, or any combination thereof.
Various entities in the environment 100 may connect to the network 118 in accordance with various wired and wireless communication protocols, such as Transmission Control Protocol and Internet Protocol (TCP/IP), User Datagram Protocol (UDP), 2nd Generation (2G), 3rd Generation (3G), 4th Generation (4G), 5th Generation (5G) communication protocols, Long Term Evolution (LTE) communication protocols, New Radio (NR) communication protocol, any future communication protocol, or any combination thereof. In some instances, the network 118 may utilize a secure protocol (e.g., Hypertext Transfer Protocol (HTTP), Secure Socket Lock (SSL), and/or any other protocol, or set of protocols for communicating with the various entities depicted in FIG. 1A.
In an embodiment, the account holder (e.g., the account holder 104(1)) may be any individual, representative of a corporate entity, a non-profit organization, or any other person who is presenting payment account details during an electronic payment transaction. The account holder (e.g., the account holder 104(1)) may have a payment account issued by an issuing bank (not shown in figures) associated with an issuer server (e.g., the issuer server 108(1)) and may be provided with a payment card with financial or other account information encoded onto the payment card such that the account holder (i.e., the account holder 104(1)) may use the payment card to initiate and complete a payment transaction using a bank account at the issuing bank.
In another embodiment, the account holders 104 may use their corresponding electronic devices (not shown in figures) to access a mobile application or a website associated with the issuing bank, or any third-party payment application to perform a payment transaction. In various non-limiting examples, the electronic devices may refer to any electronic devices such as, but not limited to, Personal Computers (PCs), tablet devices, smart wearable devices, Personal Digital Assistants (PDAs), voice-activated assistants, Virtual Reality (VR) devices, smartphones, laptops, and the like.
In an embodiment, the merchants 106 may include retail shops, restaurants, supermarkets or establishments, government and/or private agencies, or any such places equipped with POS terminals, where the account holders 104 visit to perform financial transactions in exchange for any goods and/or services or any financial transactions.
In one scenario, the account holders 104 may use their corresponding payment accounts to conduct payment transactions with the merchants 106. Moreover, it may be noted that each of the account holders 104 may use their corresponding payment cards differently or make the payment transaction using different means of payment such as net banking, Unified Payments Interface (UPI) payment, card transaction, cheque transaction, etc. For instance, the account holder 104(1) may enter payment account details on an electronic device (not shown) associated with the account holder 104(1) to perform an online payment transaction. In another instance, the account holder 104(2) may utilize a payment card to perform an offline payment transaction. In yet another instance, the account holder 104(3) may enter details of the payment card to transfer funds in the form of fiat currency on an e-commerce platform to buy goods.
In an embodiment, the merchants 106 are generally associated with financial institutions such as acquiring banks who are associated with the acquirer servers 110. To that end, it is noted that the terms “acquirer”, “acquiring bank”, “acquirer server”, and “acquirer servers” will be used interchangeably hereinafter. Herein, the acquiring bank can be an institution that facilitates the processing of payment transactions for physical stores, merchants, or institutions that own platforms that make either online purchases or purchases made via software applications possible.
As described earlier, the conventional approaches of segmenting or categorizing account holders into different categories have several drawbacks. Typically, it should be noted that the drawbacks of any conventional Artificial Intelligence (AI) or Machine Learning (ML) model are that they provide segments that are not goal-specific or task-specific. Further, when such segments are used by financial institutions such as issuers (e.g., the issuers 108), inaccurate results are generated which is undesirable. In addition, most of the conventional AI or ML models while performing the categorization of the account holders such as the account holders 104, consider a single factor at a time. As a result, accuracy in decision-making for accomplishing the goal is compromised since other significant factors are not considered. For example, in the financial sector, if the loan allocation strategy of banks is based only on credit risk score. In such scenarios, there is a possibility of receiving recommendations of account holders who are least active in using their payment cards such as credit cards, since they have low credit risk scores. However, since they are inactive users, they might not need any loans.
Therefore, there is a need to consider multiple factors while segmenting the account holders 104 under different categories, and hence, a technical solution is required to facilitate the categorization of the account holders 104 under multiple classes or segments utilizing distinct scores. Herein, it may be noted that the distinct scores may provide distinct aspects related to a behavior of the account holders 104, and hence the segments of the account holders 104 that may be generated using the approach disclosed in the present disclosure, may provide accurate results. To that end, the present approach facilitates the generation of accurate recommendations for the issuers 108 regarding the actions to be taken to improve the customer experience using accurate account holder classifications.
The above-mentioned technical problems, among other problems, are addressed by one or more embodiments implemented by the server system 102 and the methods thereof provided in the present disclosure. In an embodiment, it may be noted that the methods and systems proposed in the present disclosure can be used in any domain or industry to perform the classification task with different classes. However, for the sake of explanation, analysis, and performance comparison, the example of using the proposed system in the payment industry is considered in the present disclosure. On that note, it should be understood that the present disclosure is applicable in various other industries such as healthcare, financial technology, hospitality, media, travel, law enforcement, and the like. In one embodiment, the server system 102 is configured to perform one or more of the operations described herein.
In a specific embodiment, the server system 102 is configured to facilitate payment processors (such as Mastercard®) to categorize the account holders 104 while training one or more AI or ML models to perform a specific classification task. As may be understood, for categorizing the account holders 104, data related to the account holders 104 may have to be accessed and processed accordingly using the one or more AI or ML models. Therefore, in an embodiment, the database 116 is configured to store an account holder-related dataset 120. In a non-limiting example, the account holder-related dataset 120 may include historical information corresponding to a plurality of payment transactions performed by the plurality of account holders 104. Herein, each account holder may have one or more financial accounts with one or more issuers 108.
In an example, the historical information may include, but is not limited to, transaction attributes, such as transaction amount, source of funds such as bank accounts, debit cards or credit cards, transaction channel used for loading funds such as POS terminal or ATM, transaction velocity features such as count and transaction amount sent in the past ‘x’ number of days to a particular user, transaction location information, external data sources, merchant country, merchant Identifier (ID), account holder ID, account holder product, account holder Permanent Account Number (PAN), Merchant Category Code (MCC), merchant location data or merchant co-ordinates, merchant industry, merchant super industry, ticket price, and other transaction-related data.
Further, the server system 102, initially, accesses the account holder-related dataset 120 from the database 116, generates a plurality of account holder-related features corresponding to each account holder, and stores the plurality of account holder-related features in the database 116. In an embodiment, the plurality of account holder-related features may include a plurality of payment transaction-related features and the plurality of account-related features.
In various non-limiting examples, the database 116 may include one or more Hard Disk Drives (HDD), Solid-State Drives (SSD), an Advanced Technology Attachment (ATA) adapter, a Serial ATA (SATA) adapter, a Small Computer System Interface (SCSI) adapter, a Redundant Array of Independent Disks (RAID) controller, a Storage Area Network (SAN) adapter, a network adapter, and/or any component providing the server system 102 with access to the database 116. In one implementation, the database 116 may be viewed, accessed, amended, updated, and/or deleted by an administrator (not shown) associated with the server system 102 through a database management system (DBMS) or relational database management system (RDBMS) present within the database 116.
In an embodiment, the database 116 may also store the one or more AI or ML models such as a top-of-wallet (TOW) segmentation ML model 122 and a credit risk-and-exposure (CRE) categorization ML model 124 that are trained to perform a TOW segmentation task and a CRE categorization task, respectively. In a non-limiting embodiment, the TOW segmentation ML model 122 and the CRE categorization ML model 124 can be a feed-forward neural network-based ML model trained to perform the TOW segmentation task and the CRE categorization task, respectively. It should be noted that the training process of the TOW segmentation ML model 122 and the CRE categorization ML model 124 has been explained in detail later in the present disclosure. Moreover, the architecture of the TOW segmentation ML model 122 and the CRE categorization ML model 124 is also explained further in the present disclosure.
In other various examples, the database 116 may also include multifarious data, for example, social media data, Know Your Customer (KYC) data, payment data, trade data, employee data, Anti Money Laundering (AML) data, market abuse data, Foreign Account Tax Compliance Act (FATCA) data, and fraudulent payment transaction data. In addition, the database 116 provides a storage location for data and/or metadata obtained from various operations performed by the server system 102.
Further, it may be noted that, in a specific example, the server system 102 coupled with the database 116 is embodied within a payment server associated with the payment processor, however, in other examples, the server system 102 can be a standalone component (acting as a hub) connected to the issuer servers and the acquirer servers. The database 116 may be incorporated in the server system 102 or maybe an individual entity connected to the server system 102 or maybe a database stored in cloud storage.
As may be understood, the present disclosure intends to categorize the account holders 104 by considering at least three scores such as a top-of-wallet (TOW) segmentation score (otherwise also referred to as ‘TOW score’), a credit exposure, a credit risk, and the like. Now, referring to FIG. 1B that illustrates a block diagram representation 140 for different segments and/or classes for categorizing account holders 104. It may be understood that the approach considered for categorizing the account holders 104 may include initially categorizing the account holders 104 under one or more TOW segments (e.g., the TOW segments 142) using the TOW segmentation ML model 122 trained to perform a classification task such as the TOW segmentation task. Herein, the TOW segmentation task corresponds to classifying the account holders 104 under different TOW segments such as the TOW segments 142. In a non-limiting implementation, the TOW segments 142 may include high usage 142A, specific usage 142B, seasonal usage 142C, low usage 142D, new user 142E, inactive user 142F, primary card 142G, secondary card 142H, and the like as shown in FIG. 1B.
Later, the account holders 104 belonging to each TOW segment such as the TOW segments 142A-142H are further categorized by computing a probability of credit exposure and a probability of credit risk (otherwise also referred to as a probability of default) for each account holder. Thereafter, the account holders 104 may be classified under different CRE classes (e.g., CRE classes 144) using the CRE categorization ML model 124. In a non-limiting implementation, the CRE classes 144 may include at least four classes for each TOW segment 142A-142H of the account holders 104. Herein, it may be noted that the CRE categorization ML model 124 is similar to the TOW segmentation ML model 122 with the variation in the classification task being performed.
To that end, in a non-limiting implementation, the classification task that the CRE categorization ML model 124 is trained with may be referred to as a ‘CRE categorization task’ for categorizing the account holders 104 under the different CRE classes such as the CRE classes 144. The CRE classes 144 may include a high probability of default and high credit exposure 144A, a high probability of default and low credit exposure 144B, a low probability of default and high credit exposure 144C, and a low probability of default and low credit exposure 144D.
As used herein, the term “top-of-wallet segmentation” refers to a type of segmentation or categorization of account holders based on their spending behaviors, payment preferences, and the level of engagement with a particular credit card or payment method. As mentioned earlier, the TOW segments 142 may include high usage 142A, specific usage 142B, seasonal usage 142C, low usage 142D, new user 142E, inactive user 142F, primary card 142G, secondary card 142H, and the like as shown in FIG. 1B. Herein, the ‘high usage’ category refers to a category of account holders who are frequently using their payment cards such as a credit card allocated to the corresponding account holders. Similarly, the ‘specific usage’ category refers to a category of account holders who are involved in using their payment cards only during specific times or occasions such as while purchasing gifts, purchasing costly products, etc. The ‘seasonal usage’ category refers to a category of account holders who use their payment cards seasonally such as during festivals, at the start of every month, etc. The ‘low usage’ category refers to a category of account holders who seldom use their payment cards. The ‘new user’ category refers to a category of account holders who have newly purchased a payment card and have recently started to use it. The ‘inactive used’ category refers to a category of account holders who are highly inactive in using the payment card. Further, the ‘primary card’ category may refer to an account holder who has a relationship with the issuer for less than 12 months. Furthermore, the account holder has made transactions in more than 5 different industries (e.g., clothing, travel, restaurants, etc.,) in the past 12 months. Also, the ‘secondary card’ category may refer to an account holder who has a relationship with the issuer for less than 12 months. Furthermore, the account holder has made transactions in 5 or less different industries (e.g., clothing, travel, restaurants, etc.,) in the past 12 months. The process of categorizing the account holders 104 under the different TOW segments 142 is explained further in the present disclosure.
Further, the term “credit exposure” refers to the potential financial risk or loss that a lender or financial institution faces if the borrower or debtor defaults on their financial obligations. It measures the amount of money at risk. On the other hand, the term “credit utilization” refers to a measure of the percentage of the amount utilized by the account holder from a total credit limit of a payment card such as a credit card associated with the account holder. Herein, it may be noted that the term ‘credit exposure’ is used at the financial institute end and the term ‘credit utilization’ is used at the account holder, however, both are related to each other in being directly proportional to each other. More specifically, it may be noted that the more the credit utilization made by the account holder, the more would be credit exposure. Thus, both these terms may be used interchangeably at the payment processor end as the value corresponding to both terms may be the same as both are measuring the same factor with different perspectives.
For example, if the total limit of a credit card of the account holder 104(1) is 10,000 dollars ($), and if the account holder 104(1) utilized 10% of the total credit limit, then the credit utilization of the corresponding account holder 104(1) is 10% and if 90% is utilized then the credit utilization is 90%. Further, if the credit utilization of the account holder 104(1) is more, then the loss or the risk a lender such as the issuer 108(1) might face in case the account holder 104(1) defaults on their financial obligations, i.e., credit exposure of the issuer 108(1) would also be approximately more. In most embodiments, both these values are the same.
Furthermore, the term “credit risk” also known as ‘default risk’ refers to the risk that a borrower or debtor will fail to meet their financial obligations by not repaying a loan or debt according to the agreed terms. It represents the potential for a lender or an investor to incur a financial loss due to the borrower’s inability or unwillingness to make timely payments. It involves assessing the likelihood or the probability of a borrower defaulting on their obligations. In addition, it may be noted that the credit risk also covers delinquency risk. In other words, for computing the credit risk, computing the delinquency risk may be a pre-requisite. Herein, the term “delinquency risk” refers to the risk of borrowers becoming delinquent on their payments, i.e., borrowers failing to make card payments such as credit card payments on time are delinquent borrowers and may or may not lead to eventual default. Further, borrowers becoming delinquent exhibit early signs of credit risk, indicating that they are struggling to meet their financial obligations.
As may be understood, both the credit exposure and the credit risk are measured as probability values ranging between 0 to 1, the account holders 104 may be grouped into at least four classes based on the probability values for both the credit exposure and the credit risk for each account holder. For example, if the probability values are between 0 and 1 for each of the credit exposures and the credit risk, then the values between 0 to 1 are split into three buckets such as 0-0.33, 0.34-0.66, and 0.66-1 each. Then, the account holders with a credit exposure between 0-0.33 and a credit risk between 0-0.33 may be grouped in a first bucket representing a class of low probability of default and low credit exposure. Similarly, all the account holders may be classed in each bucket accordingly. The process of categorizing the account holders 104 under the different CRE classes is explained further in the present disclosure.
Further, in a specific embodiment, it may be noted that upon categorization, the server system 102 may facilitate the issuers 108 to perform recommended actions (e.g., recommended actions 146). In a non-limiting example, the recommended actions 146 may include, but are not limited to, reducing limit or attrition strategies 146A, providing promotional messages 146B, conducting past dues collection campaigns 146C, increasing credit limit or upgrade tier 146D, or the like as shown in FIG. 1B.
Now referring back to FIG. 1A, in a non-limiting implementation, the server system 102 is configured to access the plurality of payment transaction-related features from the database 116, generate a set of TOW embeddings, determine a TOW score corresponding to each account holder, and store the TOW embeddings and TOW score in the database 116. It is noted that the TOW score corresponding to each account holder indicates a likelihood that the corresponding account holder belongs to a particular TOW segment from the one or more TOW segments. Herein, it may be noted that the server system 102 may generate the set of TOW embeddings using the TOW segmentation ML model 122.
Further, in another embodiment, the server system 102 is configured to access the plurality of account-related features, the set of TOW embeddings, and the TOW score from the database 116. The server system 102 is further configured to generate and assign a TOW segment from one or more TOW segments such as the TOW segments 142 to each account holder based, at least in part, on the TOW score corresponding to each account holder. Herein, each TOW segment corresponds to an individual TOW label. In other words, each TOW segment of the one or more TOW segments 142 may include one or more account holders from the plurality of account holders 104 that are labeled with a particular TOW label. Furthermore, the server system 102 is configured to generate a combined feature vector for each account holder from the one or more TOW segments 142 based, at least in part, on concatenating the plurality of account-related features, the set of TOW embeddings, and the corresponding TOW label of the TOW segment of each account holder.
In addition, the server system 102 is configured to generate a set of CRE embeddings for each account holder based, at least in part, on the combined feature vector. In a non-limiting example, the server system 102 may generate the set of CRE embeddings using the CRE categorization ML model 124. The server system 102 is then configured to determine a CRE score corresponding to each account holder based, at least in part, on the set of CRE embeddings and CRE threshold criteria. Herein, the CRE score may indicate the likelihood of the corresponding account holder belonging to a particular CRE class. In a non-limiting example, the server system 102 may determine the CRE score using the CRE categorization ML model 124.
In an embodiment, the server system 102 may also be configured to assign a CRE class from one or more CRE classes to each account holder based, at least in part, on the CRE score corresponding to each account holder. Herein, each CRE class corresponds to an individual CRE label. More specifically, each CRE class may include a set of CRE-labeled account holders from the one or more account holders of each TOW segment that are further labeled with a particular CRE label.
In one embodiment, the payment network 112 may be used by the payment card issuing authorities as a payment interchange network. Examples of the payment cards include debit cards, credit cards, etc. Similarly, examples of payment interchange networks include but are not limited to, a Mastercard® payment system interchange network. The Mastercard® payment system interchange network is a proprietary communications standard promulgated by Mastercard International Incorporated® for the exchange of electronic payment transaction data between issuers and acquirers that are members of Mastercard International Incorporated®. (Mastercard is a registered trademark of Mastercard International Incorporated located in Purchase, N.Y.).
It should be understood that the server system 102 is a separate part of the environment 100, and may operate apart from (but still in communication with, for example, via the network 118) any third-party external servers (to access data to perform the various operations described herein). However, in other embodiments, the server system 102 may be incorporated, in whole or in part, into one or more parts of the environment 100.
The number and arrangement of systems, devices, and/or networks shown in FIG. 1A is provided as an example. There may be additional systems, devices, and/or networks; fewer systems, devices, and/or networks; different systems, devices, and/or networks; and/or differently arranged systems, devices, and/or networks than those shown in FIG. 1A. Furthermore, two or more systems or devices are shown in FIG. 1A may be implemented within a single system or device, or a single system or device is shown in FIG. 1A may be implemented as multiple, distributed systems or devices. In addition, the server system 102 should be understood to be embodied in at least one computing device in communication with the network 118, which may be specifically configured, via executable instructions, to perform steps as described herein, and/or embodied in at least one non-transitory computer-readable media.
FIG. 2 illustrates a simplified block diagram of a server system 200, in accordance with an embodiment of the present disclosure. The server system 200 is identical to the server system 102 of FIG. 1A. In one embodiment, the server system 200 is a part of the payment network 112 or integrated within the payment server 114. In some embodiments, the server system 200 is embodied as a cloud-based and/or SaaS-based (software as a service) architecture.
The server system 200 includes a computer system 202 and a database 204. The computer system 202 includes at least one processor 206 (herein, referred to interchangeably as ‘processor 206’) for executing instructions, a memory 208, a communication interface 210, a user interface 212, and a storage interface 214. The one or more components of the computer system 202 communicate with each other via a bus 216. The components of the server system 200 provided herein may not be exhaustive and the server system 200 may include more or fewer components than those depicted in FIG. 2. Further, two or more components depicted in FIG. 2 may be embodied in one single component, and/or one component may be configured using multiple sub-components to achieve the desired functionalities.
In some embodiments, the database 204 is integrated into the computer system 202. In one non-limiting example, the database 204 is configured to store an account holder-related dataset such as an account holder-related dataset 218. In a non-limiting example, as mentioned earlier in the present disclosure, the account holder-related dataset 218 may include historical information corresponding to the plurality of payment transactions performed by the plurality of account holders (e.g., the account holders 104). Herein, each account holder may have one or more financial accounts at one or more issuers (e.g., the issuers 108). Further, in an embodiment, since the account holder-related dataset 218 may be used for training the one or more AI or ML models for performing a classification task, the account holder-related dataset 218 may also include a labeled dataset with examples for various labels that can be used for performing various classification tasks, examples of historical classification tasks, and the like.
Further, in an embodiment, the database 204 may also store one or more AI or ML models such as a Top-of-Wallet (TOW) segmentation ML model 220 and a credit risk-and-exposure (CRE) categorization ML model 222 that may be used by the server system 200 for further processing the account-holder related dataset 218. Herein, the TOW segmentation ML model 220 and the CRE categorization ML model 222 are identical to the TOW segmentation ML model 122 and the CRE categorization ML model 124 of FIG. 1A, respectively. In addition, the database 204 provides a storage location for data and/or metadata obtained from various operations performed by the server system 200.
Further, the computer system 202 may include one or more hard disk drives as the database 204. The user interface 212 is an interface such as a Human Machine Interface (HMI) or a software application that allows users such as an administrator to interact with and control the server system 200 or one or more parameters associated with the server system 200. It may be noted that the user interface 212 may be composed of several components that vary based on the complexity and purpose of the application. Examples of components of the user interface 212 may include visual elements, controls, navigation, feedback and alerts, user input and interaction, responsive design, user assistance and help, accessibility features, and the like. More specifically these components may correspond to icons, layout, color schemes, buttons, sliders, dropdown menus, tabs, links, error/success messages, mouse and touch interactions, keyboard shortcuts, tooltips, screen readers, and the like.
The storage interface 214 is any component capable of providing the processor 206 access to the database 204. The storage interface 214 may include, for example, an Advanced Technology Attachment (ATA) adapter, a Serial ATA (SATA) adapter, a Small Computer System Interface (SCSI) adapter, a RAID controller, a SAN adapter, a network adapter, and/or any component providing the processor 206 with access to the database 204.
The processor 206 includes suitable logic, circuitry, and/or interfaces to execute operations for generating a set of TOW embeddings based on a plurality of payment transaction-related features, determining a TOW score for each account holder, assigning a TOW segment of the one or more TOW segments, generating a combined feature vector, generating a set of CRE embeddings, determining a CRE score for each account holder, and assigning a CRE class of the one or more CRE classes, and the like. Examples of the processor 206 include, but are not limited to, an Application-Specific Integrated Circuit (ASIC) processor, a Reduced Instruction Set Computing (RISC) processor, a Graphical Processing Unit (GPU), a Complex Instruction Set Computing (CISC) processor, a Field-Programmable Gate Array (FPGA), and the like.
The memory 208 includes suitable logic, circuitry, and/or interfaces to store a set of computer-readable instructions for performing operations. Examples of the memory 208 include a Random-Access Memory (RAM), a Read-Only Memory (ROM), a removable storage drive, a Hard Disk Drive (HDD), and the like. It will be apparent to a person skilled in the art that the scope of the disclosure is not limited to realizing the memory 208 in the server system 200, as described herein. In another embodiment, the memory 208 may be realized in the form of a database server or a cloud storage working in conjunction with the server system 200, without departing from the scope of the present disclosure.
The processor 206 is operatively coupled to the communication interface 210, such that the processor 206 is capable of communicating with a remote device 224 such as the issuer servers 108, the acquirer servers 110, the payment server 114, or communicating with any entity connected to the network 118 (as shown in FIG. 1A).
It is noted that the server system 200 as illustrated and hereinafter described is merely illustrative of an apparatus that could benefit from embodiments of the present disclosure and, therefore, should not be taken to limit the scope of the present disclosure. It is noted that the server system 200 may include fewer or more components than those depicted in FIG. 2. It should be noted that the server system 200 is identical to the server system 102 described in reference to FIG. 1A.
In one implementation, the processor 206 includes a data pre-processing module 226, a training module 228, a categorization module 230, and a concatenation module 232. It should be noted that components, described herein, such as the data pre-processing module 226, the training module 228, the categorization module 230, and the concatenation module 232 can be configured in a variety of ways, including electronic circuitries, digital arithmetic, and logic blocks, and memory systems in combination with software, firmware, and embedded technologies. Moreover, it may be noted that the data pre-processing module 226, the training module 228, the categorization module 230, and the concatenation module 232 may be communicably coupled with each other to exchange information with each other for performing the one or more operations facilitated by the server system 200.
In an embodiment, the data pre-processing module 226 includes suitable logic and/or interfaces for accessing the account holder-related dataset 218 from the database 204. The data pre-processing module 226 may further be configured to generate the plurality of account holder-related features corresponding to each account holder based, at least in part, on the account holder-related dataset 218. In an embodiment, the plurality of account holder-related features may include a plurality of payment transaction-related features and the plurality of account-related features. Further, the data pre-processing module 226 may be configured to store the plurality of account holder-related features in the database 204. It should be noted that the plurality of account holder-related features may be accessed from the database 204 whenever required. In a specific embodiment, it may be noted that the plurality of payment transaction-related features can also be accessed separately from the database 204 whenever required. In another specific embodiment, the plurality of account-related features may also be accessed separately from the database 204 whenever required.
In an example embodiment, the plurality of payment transaction-related features may include at least: a card entry mode, card presence status, a merchant category, a transaction amount, a count of total transactions, a count of approved transactions, a count of declined transactions, a count of fraudulent transactions, and the like.
In another example, the plurality of account-related features may include days past due date, balance past due date, credit balance data, partial payments data, product type data, age of an account holder data, and the like.
Upon extracting the plurality of account holder-related features from the account holder-related dataset 218, the TOW segmentation ML model 220 and the CRE categorization ML model 222 may have to be trained and validated to perform the TOW segmentation task and the CRE categorization task, respectively. Moreover, in an embodiment, it may be noted that the TOW segmentation ML model 220 and the CRE categorization ML model 222 can be a feed-forward neural network-based ML model trained and validated to perform the TOW segmentation task and the CRE categorization task, respectively.
Further, it should be noted that prior to training any AI or ML models, input data fed to the AI or ML models may have to be prepared for training. Therefore, initially, in an embodiment, for training the TOW segmentation ML model 220, the data pre-processing module 226 may further be configured to perform one or more data pre-processing operations such as data cleaning, feature scaling (e.g., normalization, standardization, etc.), handling missing values, encoding categorical variables if needed, and the like. It is noted that since the data pre-processing operations described earlier are well-known in the art, they are not explained here in detail for the sake of brevity. Herein, it may be noted that the data pre-processing module 226 is configured to perform the one or more data pre-processing operations on the plurality of payment transaction-related features prior to providing the plurality of payment transaction-related features to the training module 228 for training the TOW segmentation ML model 220.
In addition, an architecture for the TOW segmentation ML model 220 may have to be selected from the above-mentioned architectures or algorithms. It should be noted that the architecture of the TOW segmentation ML model 220 and the CRE categorization ML model 222 is explained further in detail in the present disclosure.
Further, the training module 228 includes suitable logic and/or interfaces for training the TOW segmentation ML model 220 and the CRE categorization ML model 222 to perform the TOW segmentation task and the CRE categorization task, respectively.
Considering the training of the TOW segmentation ML model 220, it may be noted that the training module 228 may train the TOW segmentation ML model 220 by performing a first set of operations iteratively until the performance of the TOW segmentation ML model 220 converges to the first predefined criteria. Further, it may be noted that the first set of operations may be performed in accordance with the steps covered in FIG. 3A.
Further, it may be noted that the categorization module 230 includes suitable logic and/or interfaces for categorizing the plurality of account holders 104 under the one or more TOW segments. Thus, in an embodiment, the categorization module 230 may be configured to access the plurality of payment transaction-related features corresponding to each account holder from the database 204. Further, the categorization module 230 is configured to generate, by the TOW segmentation ML model 220, the set of TOW embeddings based, at least in part, on the plurality of payment transaction-related features. As mentioned earlier, the process of generating the set of TOW embeddings is explained in detail with reference to FIG. 3.
Further, the categorization module 230 may be configured to determine, by the TOW segmentation ML model 220, a TOW score corresponding to each account holder based, at least in part, on the set of TOW embeddings and TOW threshold criteria. Herein, the TOW score may indicate a likelihood of the corresponding account holder belonging to a particular TOW segment. Furthermore, the categorization module 230 may store the set of TOW embeddings and the TOW score corresponding to each account holder in the database 204. It may be noted that the set of TOW embeddings and the TOW score may be utilized for further processing whenever required.
In an embodiment, the categorization module 230 may further access the plurality of account-related features, the set of TOW embeddings, and the TOW score corresponding to each account holder from the database 204. Further, the categorization module 230 may assign a TOW segment from one or more TOW segments to each account holder based, at least in part, on the TOW score. Herein, each TOW segment of the one or more TOW segments may include one or more account holders from the plurality of account holders 104 that are labeled with a particular TOW label.
As may be understood, the account holders belonging to each TOW segment can be further categorized under different CRE classes. To that end, the plurality of account-related features, the set of TOW embeddings, and the TOW score accessed by the categorization module 230 may be provided to the concatenation module 232. Herein, the concatenation module 232 suitable logic and/or interfaces for generating a new set of embeddings from the plurality of account-related features, the set of TOW embeddings, and the TOW score that can be used for further categorizing the account holders belonging to each TOW segment under different CRE classes.
To that note, the concatenation module 232 may be configured to generate a combined feature vector for each account holder from the one or more TOW segments based, at least in part, on concatenating the plurality of account-related features, the set of TOW embeddings, and the TOW score. The concatenation process is explained with reference to FIG. 5 by considering a specific example. Further, upon obtaining the combined feature vector, the CRE categorization ML model 222 may have to be trained for performing the CRE categorization task. Thus, in an embodiment, the combined feature vector is provided to the training module 228 and the categorization module 230.
Further, it may be noted that the training module 228 may train the CRE categorization ML model 222 by performing a second set of operations iteratively until the performance of the CRE categorization ML model 222 converges to second predefined criteria. Further, it may be noted that the second set of operations may be performed in accordance with the steps covered in FIG. 3B.
Further, in an embodiment, upon completion of the training of the CRE categorization ML model 222, the training module 228 may provide the CRE categorization ML model 222 to the categorization module 230. Thus, it may be noted that the categorization module 230 may be configured to further categorize the one or more account holders under the one or more CRE classes.
To that end, for further categorizing the one or more account holders, the categorization module 230 may be configured to generate, by the CRE categorization ML model 222, the set of CRE embeddings for each account holder based, at least in part, on the combined feature vector.
Further, the categorization module 230 may be configured to determine a CRE score corresponding to each account holder based, at least in part, on the set of CRE embeddings and CRE threshold criteria. Herein, the CRE score may indicate a likelihood of categorizing the corresponding account holder under a particular CRE class. In an embodiment, the categorization module 230 may be configured to generate the CRE score using the CRE categorization ML model 222.
Furthermore, the categorization module 230 may be configured to assign a CRE class from one or more CRE classes to each account holder based, at least in part, on the CRE score. Herein, each CRE class may correspond to an individual CRE label.
Referring to FIG. 3A, which illustrates a process flow diagram 300 for training and optimizing the TOW segmentation ML model 220 to perform the TOW segmentation task, in accordance with an embodiment of the present disclosure. In an embodiment, it may be noted that for training the TOW segmentation ML model 220 to perform the TOW segmentation task, one or more first ML model parameters (e.g., first model parameters 302) may have to be set. At first, a training dataset is accessed by the training module 228 from the database 204. It is noted that the training dataset may be a portion of the account holder-related dataset 218. In various non-limiting examples, the training dataset includes historical information related to the plurality of payment transactions performed by the plurality of account holders 104 within a predefined time period and a true TOW label for each account holder. In some instances, the predefined time period may be 3 months, 6 months, 12 months, or the like. Then, the training module 228 may be configured to initialize the first model parameters 302 with initial values. For example, the first model parameters 302 may include weights, biases, hyperparameters, and the like. In an embodiment, the hyperparameters may include a number of layers, a number of neurons per layer, an activation function, a loss function, an optimization algorithm, a batch size, epochs, a learning rate, regularization, and the like. Upon initializing the first model parameters 302, the first set of operations may start at operation 304.
At operation 304, the training module 228 may be configured to initialize the TOW segmentation ML model 220 based, at least in part, on the one or more first model parameters 302. Herein, in a non-limiting example, a true TOW label 306 may include information related to labels assigned to items, entities, or users in the past for performing the TOW segmentation task. For example, in fraud detection, the labels may include ‘fraud’ and ‘non-fraud’, in risk identification, the labels may include ‘risky’ and ‘non-risky’, etc.
At operation 308, the training module 228 may be configured to generate a set of training TOW embeddings based, at least in part, on the training dataset.
At operation 310, the training module 228 may be configured to generate a TOW segment prediction for each account holder based, at least in part, on the set of training TOW embeddings. Herein, the TOW segment prediction indicates a predicted TOW label for each account holder. In a non-limiting example, the training module 228 may predict a TOW label, via the TOW segmentation ML model 220, that is most likely to be assigned to the plurality of account holders 104 based on probability distribution values computed for each TOW segment shown in FIG. 4. The flow then moves to operation 312.
At operation 312, the training module 228 may be configured to compute a TOW loss for each account holder based, at least in part, on the predicted TOW label for each account holder and the true TOW label for each account holder (e.g., the account holder 104(1)).
In a non-limiting example, the TOW loss may be a cross-entropy loss to perform the TOW segmentation task. Herein, it may be noted that the training module 228 may compute the cross-entropy loss using a cross-entropy loss function. As used herein, the term “cross-entropy loss function” refers to a log loss function of a logistic loss function used in machine learning and deep learning tasks, especially for the classification task. It measures the dissimilarities between predicted probabilities (or scores) and the true labels of the classification problems.
In a non-limiting example, the cross-entropy loss function may be represented as follows:
L(y_true,y_pred )=-?¦[y_(true_i )*log?(y_(pred_i ) ) ] … Eqn. 1
Herein, it may be noted that Eqn. 1 is used for computing the cross-entropy loss for multi-class classification tasks. Moreover, in an embodiment, since the TOW segmentation task is a multi-class classification task, Eqn. 1 is used in this scenario to compute the cross-entropy loss. Further, referring to Eqn. 1, the term ‘L’ refers to the cross-entropy loss which is a function of ‘y_true’ and ‘y_pred’. Herein, the terms ‘y_true’ refers to a true label and ‘y_pred’ refers to predicted probability values. As mentioned above, the TOW segment prediction indicating the one or more TOW labels, is basically having predicted probability values assigned to each of the one or more TOW labels for each account holder. Therefore, it may be understood that these probability values are compared with their respective true labels. It should be noted that the true label may be predefined and obtained from historical data.
Further, the terms ‘y_(true_i )’ and ‘y_(pr?ed?_i )’ refer to true label for class ‘i’ and predicted probability value for class ‘i’, respectively. As per Eqn. 1, the sum is taken over all classes. The goal during training is to minimize this cross-entropy loss, which encourages the model to produce predicted probabilities that are close to the true class labels. Thus, it may be understood that minimizing the cross-entropy loss leads to better classification performance.
In another embodiment, it may be noted that the TOW loss may be computed using other loss functions such as sparse cross-entropy loss function, weighted cross-entropy loss, center loss, etc., without limiting the scope of the invention.
At operation 314, the training module 228 may be configured to compute, a TOW gradient component for each account holder (e.g., the account holder 104(1)) based, at least in part, on back-propagating the TOW loss. Herein, it may be noted that the term ‘TOW gradient component’ refers to an amount by which the TOW loss is reduced after every iteration. In a non-limiting example, the training module 228 may compute the TOW gradient component by using a concept of gradient descent.
At operation 316, the training module 228 may be configured to optimize the one or more first model parameters 302 based, at least in part, on the TOW gradient component.
At operation 318, the training module 228 may be configured to check whether the performance of the TOW segmentation ML model 220 is converged to the first predefined criteria. In a non-limiting example, the first predefined criteria may include the TOW loss getting saturated. Herein, it may be noted that the TOW loss may get saturated after a plurality of iterations of the first set of operations. In another non-limiting example, the first predefined criteria may include the TOW loss reducing near to zero. Moreover, it may be noted that the TOW loss may get saturated as the TOW gradient component gets saturated. Therefore, in an embodiment, if the performance of the TOW segmentation ML model 220 converges to the first predefined criteria, then the flow moves to operation 320, otherwise, the flow moves to the next iteration as shown in FIG. 3A.
At operation 320, the training of the TOW segmentation ML model 220 stops.
Further, in an embodiment, upon completion of the training of the TOW segmentation ML model 220, the training module 228 may provide the TOW segmentation ML model 220 to the categorization module 230.
Referring to FIG. 3B, which illustrates a process flow diagram 340 for training and optimizing a CRE categorization ML model to perform a CRE categorization task, in accordance with an embodiment of the present disclosure. In an embodiment, it may be noted that for training the CRE categorization ML model 222 to perform the CRE categorization task, one or more second model parameters (e.g., second model parameters 342) may have to be set. At first, the training module 228 is configured to access a training dataset from the database 204. Herein, the training dataset includes historical information related to a plurality of payment transactions performed by the plurality of account holders within a predefined time period and a true CRE label for each account holder. Then, the training module 228 may be configured to initialize the one or more second model parameters 342 with initial values. For example, the second model parameters 342 may include parameters similar to that of the first model parameters 302 with different values for each. Upon initializing the second model parameters 342, the second set of operations may start at operation 344.
At operation 344, the training module 228 may be configured to initialize the CRE categorization ML model 222 based, at least in part, on the one or more second model parameters 342. Herein, in a non-limiting example, the true CRE label 346 may include information related to labels assigned to items, entities, or users in the past for performing the CRE categorization task.
At operation 348, the training module 228 may be configured to generate, by the CRE categorization ML model, a set of training CRE embeddings based, at least in part, on the training dataset.
At operation 350, the training module 228 may be configured to generate a CRE class prediction for each account holder based, at least in part, on the set of training CRE embeddings. Herein, the CRE class prediction may indicate a predicted CRE label for each account holder. In a non-limiting example, the training module 228 may predict a CRE label, via the CRE categorization ML model 222, which is most likely to be assigned to each Account holder, based on probability distribution values computed for each CRE label shown in FIG. 3. The flow then moves to operation 352.
At operation 352, the training module 228 may be configured to a CRE loss for each account holder based, at least in part, on the predicted CRE label for each account holder and the true CRE label for each account holder. In a non-limiting example, the CRE loss may be a cross-entropy loss to perform the CRE categorization task. Herein, it may be noted that the training module 228 may compute the cross-entropy loss using the cross-entropy loss function as per Eqn. 1. In another embodiment, it may be noted that the CRE loss may be computed using other loss functions such as sparse cross-entropy loss function, weighted cross-entropy loss, center loss, etc., without limiting the scope of the invention.
At operation 354, the training module 228 may be configured to compute a CRE gradient component for each account holder based, at least in part, on back-propagating the CRE loss. Herein, it may be noted that the term CRE gradient component refers to an amount by which the CRE loss is reduced after every iteration.
At operation 356, the training module 228 may be configured to optimize the one or more first model parameters based, at least in part, on the CRE gradient component.
At operation 358, the training module 228 may be configured to check whether the performance of the CRE categorization ML model 222 is converged to the second predefined criteria. In a non-limiting example, the second predefined criteria may include the CRE loss getting saturated. Herein, it may be noted that the CRE loss may get saturated after a plurality of iterations of the second set of operations. In another non-limiting example, the second predefined criteria may include the CRE loss reducing to zero. Moreover, it may be noted that the CRE loss may get saturated or reduced to zero as the CRE gradient component gets saturated or reduced to zero. Therefore, in an embodiment, if the performance of the CRE categorization ML model 222 converges to the second predefined criteria, then the flow moves to operation 360, otherwise, the flow moves to the next iteration as shown in FIG. 3B.
At operation 360, the training of the CRE categorization ML model 222 stops.
Referring back to the Losses computed at the time of training the TOW segmentation ML model 220 and the CRE categorization ML model 222, it may be noted that, in a non-limiting example, the overall loss may be represented as follows:
Loss=L(M_TW (x_TW ), y_TW )+L(M_CRE ([M_TW (x_TW )|e_TW |x_CRE ), y_CRE ) … Eqn. 2
Herein, the term ‘Loss’ refers to the overall loss. Further, the term ‘L’ refers to the cross-entropy loss which in the first term in Eqn. 2 is a function of ‘M_TW (x_TW )’ and ‘y_TW’. Herein, the term ‘M_TW’ refers to the model used for top-of-wallet classification (TW) i.e., the TOW segmentation ML model 220. Further, the terms ‘x_TW’ and ‘y_TW’ refer to input i.e., the plurality of payment transaction-related features and target (i.e., a predicted result of the TOW segmentation ML model 220), respectively. Similarly, the term ‘M_CRE’ refers to the model used for credit risk and exposure classification (CRE) i.e., the CRE categorization model 222. This model is applied to a combined feature vector which corresponds to a concatenation of the ‘M_TW (x_TW )’, ‘e_TW’, and ‘x_CRE’ for obtaining the target i.e., ‘y_CRE’ which is a predicted result of the CRE categorization ML model 222. Herein, the terms ‘e_TW’, and ‘x_CRE’ refer to the set of TOW embeddings and an input such as the plurality of account-related features, respectively. Therefore, the overall loss is the sum of the cross-entropy loss of the TOW segmentation ML model 220 and that of the CRE categorization model 222.
FIG. 4 illustrates a schematic representation 400 of an architecture of a TOW segmentation ML model (e.g., the TOW segmentation ML model 220), in accordance with an embodiment of the present disclosure. As may be understood, conventionally, the account holders 104 could be categorized or segmented under different categories using different segmentation techniques based on different criteria. The criteria may include the type of input data available for segmentation, a goal of segmentation, a domain of application, and the like. Further, the different segmentation techniques may include vector-based segmentation, demographic segmentation, geographic segmentation, psychographic segmentation, behavioral segmentation, firmographic segmentation, purchase history segmentation, value-based segmentation, needs-based segmentation, hybrid segmentation, ML-based segmentation, and the like. Herein, the ML-based segmentation can be implemented using different algorithms such as clustering, decision trees, or neural networks to automatically identify patterns and create account holder segments.
More specifically, when neural networks may be chosen for segmentation, a deep learning technique may have to be selected from several deep learning techniques to build a model architecture. In a non-limiting example, the several deep learning techniques include deep autoencoder, feed-forward neural networks, recurrent neural networks (RNN), Long-short term memory (LSTM) networks, self-organizing maps (SOMs), convolutional neural networks (CNNs), hybrid models, customer behavior predictions, and the like. Herein, it may be noted that each deep learning technique has its own pros and cons depending upon the application where it is used. Therefore, the most appropriate deep learning technique may be selected to appropriately segment the account holders 104 into different categories.
In a non-limiting implementation, for categorizing the account holders in different TOW segments such as the TOW segments 142, an architecture and/or a model architecture that may be implemented for the TOW segmentation ML model 220 may correspond to a feed-forward neural network-based ML model. As may be understood, a neural network can include several layers, with each layer containing artificial neurons (otherwise also referred to as ‘nodes’ or ‘units’). Thus, it may be noted that a typical feed-forward neural network may include three types of layers such as an input layer, one or more hidden layers, and an output layer. As used herein, the term ‘input layer’ corresponds to a layer in the neural network that receives raw input data or features as inputs, and each neuron in the input layer represents one feature of the data. Similarly, the term ‘hidden layers’ refers to layers that are located between the input and output layers that perform complex transformations on the input data received from the input layer. It may be noted that the number of hidden layers and neurons in each hidden layer can vary based on the network’s architecture and problem complexity. Further, the term ‘output layer’ refers to a layer that produces a final output of the network, which is typically a classification result. Herein, the number of neurons in the output layer depends on the number of classes or categories in the classification task.
To that end, it is understood that a neuron in the hidden layers of the neural network includes several components. In a non-limiting example, the components may include weighted connections from neurons in the previous layer. Herein, the previous layer may correspond to one or more layers positioned before a current layer from the one or more hidden layers or the input layer. In case the weighted connections are coming from the input layer, inputs coming from each connection may be associated with a respective weight, which determines the strength of the corresponding connection. In an embodiment, a bias value may also be introduced. It should be noted that the weights and the bias value are learned during the training of the network. Further, in an embodiment, each neuron in the hidden layers may be associated with a summation function and an activation function. It should also be noted that the connection between the hidden layers is also associated with weights and optionally a bias value. Herein, the summation function includes performing a summation of the inputs received at each neuron in the hidden layers that are multiplied by their respective weights. Further, the activation function may introduce non-linearity into the model when applied to the summation results. In a non-limiting example, different activation functions may include sigmoid, Rectified Linear Unit (ReLu), softmax, and the like. To that note, outputs from each neuron on the hidden layers are obtained upon the application of the activation function. Further, results obtained from the hidden layers are transmitted to the output layer, where similar computation is performed by each neuron, to produce final classification results.
Further, as the architecture chosen for the TOW segmentation ML model 220 is based on the feed-forward neural network-based ML model, a forward propagation operation may be performed. Herein, forward propagation operation may refer to a flow of input data in a forward direction from an input layer such as an input layer 402 of the TOW segmentation ML model 220, one or more hidden layers such as hidden layers 404, and an output layer such as an output layer 406 to produce the final classification result. Moreover, while training the network to generate the classification results, the weights in each neuron in all the layers are adjusted to minimize the difference between its predictions and actual labels in the training data by using backpropagation and gradient descent.
Furthermore, in a non-limiting implementation, the concept of an encoder neural network may be applied to the feed-forward neural network-based ML model for generating embeddings. Thus, it may be noted that the hidden layers in the feed-forward neural network-based ML model can perform an encoder-like process by learning to extract meaningful representations (embeddings) or features from the input data, even though they are not explicitly called “encoders”. This ability to capture relevant information is a key strength of deep neural networks for performing various tasks, including image recognition, natural language processing, fraud detection, multi-class categorization, and the like.
To that end, for categorizing the account holders 104 under different TOW segments such as the TOW segments 142, the server system 200 may be configured to access the account holder-related dataset 218 from the database 204. As may be understood, the account holder-related dataset 218 may include the historical information corresponding to the plurality of payment transactions performed by the account holders 104. Also, each account holder may have one or more financial accounts at one or more issuers such as the issuers 108. Thus, in a non-limiting implementation, the server system 200 may receive the account holder-related dataset 218 from the corresponding issuers 108 and store it in the database 204. In some embodiments, the server system 200 may receive the account holder-related dataset 218 from other sources such as third-party platforms, the account holders themselves, etc., without limiting the scope of the invention.
In one embodiment, the server system 200 may further be configured to generate the plurality of account holder-related features based, at least in part, on the account holder-related dataset 218. Further, in an embodiment, the plurality of account holder-related features may include the plurality of payment transaction-related features and the plurality of account-related features. In a non-limiting example, the plurality of payment transaction-related features may correspond to transaction-level features associated with a particular account holder. Moreover, in an embodiment, the plurality of payment transaction-related features may be generated using variables such as a card entry mode, card presence status, a merchant category, transaction amount, and the like. Herein, the card entry mode may refer to a payment mode (such as a Point-of-Sale (POS) terminal, contact-less mode, online mode, etc.,) used by the account holders 104 for making payment transactions. Similarly, the card presence may refer to a variable determining whether the payment transaction is a card-present (CP) transaction or a card-not-present (CNP) transaction.
For instance, the plurality of payment transaction-related features associated with an account holder such as the account holder 104(1) may include the card entry mode being a contactless payment, a count of transactions made to an ‘ABC’ merchant in the past two months, a sum of a transaction amount in a CNP space in the past seven days, a count of transactions with a response code indicating approved transactions, a count of transactions with a response code indicating declined transactions, a count of transactions with a response code indicating erroneous transactions, authorization code values, risk and fraud assessment code values, network-specific code values, response handling code values, etc.
Similarly, in an embodiment, the plurality of account-related features may correspond to account-level features associated with a particular account holder. Moreover, in an embodiment, the plurality of account-related features may be generated using variables such as days past due, balance past due, credit balance, partial payments, product type, age of the account holder, etc., associated with the one or more financial accounts corresponding to each account holder. For instance, the plurality of account-related features associated with an account holder such as the account holder 104(1) may include maximum days past due in the last twelve months, average days past due in the last twelve months, maximum days past due in the last three months, maximum balance past due in last twelve months, etc.
Further, referring back to categorizing the account holders 104 in different TOW segments 142 using the TOW segmentation ML model 220 having the model architecture based on the feed-forward neural network-based ML model, the server system 200 may be configured to access the plurality of payment transaction-related features from the database 204. To that note, the server system 200 may provide the plurality of payment transaction-related features to the TOW segmentation ML model 220 for training the TOW segmentation ML model 220 to categorize the plurality of account holders 104 under different TOW segments 142.
Upon receiving the plurality of payment transaction-related features the TOW segmentation ML model 220 may generate a set of TOW embeddings 408 upon passing the plurality of payment transaction-related features through different layers of the TOW segmentation ML model 220. Herein, the set of TOW embeddings 408 may be similar to the set of TOW embeddings of FIG. 3A.
In a non-limiting implementation of the present invention, if 200 payment transaction-related features are considered, then it may be noted that the input layer 402 of the TOW segmentation ML model 220 may have 200 neurons, each neuron corresponding to each payment transaction-related feature. This may be followed by at least three hidden layers 404 with each layer having dimensions in AxB format. Herein, the format AxB may refer to a weight matrix where ‘A’ and ‘B’ can be considered as input dimensions and output dimensions of a layer in a neural network. Herein, the term ‘input dimensions’ of a layer refers to a count of connections (or weights) that a particular neuron in the corresponding layer is receiving from a previous layer in a neural network, each weight being received from each neuron from the previous layer. Similarly, the term ‘output dimensions’ of the layer refers to a count of connections (or weights) the current layer is transmitting to each neuron in a subsequent layer in the neural network. For instance, the at least three hidden layers 404 may include a Layer-1 (L-1) having a dimension of 200x100, a Layer-2 (L-2) having a dimension of 100x50, and a Layer-3 (L-3) having a dimension of 50x20. To that end, it may be noted that for 200 neurons of the input layer 402, the L-1 of the hidden layers 404 has corresponding 200 neurons. Herein, each neuron of L-1 receives connections 410 from 200 neurons of the input layer 402. Upon receiving the 200 connections that are 200 weighted payment transaction-related features, a summation function may be applied on each neuron of L-1, followed by an activation function for generating 100 outputs that may be termed as L-1 results hereinafter.
Similarly, L-2 of the hidden layers 404 has 100 neurons, with each neuron of L-2 receiving 100 connections 412 from L-1. Herein, the 100 connections received from L-1 may correspond to 100 weighted L-1 results, on which a summation function is applied for each neuron of L-2, followed by an activation function for generating 50 L-2 results. Similarly, L-3 of the hidden layers 404 has 50 neurons, with each neuron of L-3 receiving 50 connections 414 from L-2. Herein, the 50 connections received from L-2 may correspond to 50 weighted L-2 results, on which a summation function is applied for each neuron of L-3, followed by an activation function for generating 20 L-3 results.
Thus, it may be noted that inputs to a neuron can be represented as a vector x = {x1, x2, x3, … xn} with connections (or weights) for each element of the vector x being represented as another vector w = {w1j, w2j, w3j, … wnj}, respectively. Then, the results obtained upon applying the summation function may be indicated as follows:
z_j=?_i¦? w_ij x_i+b_j … Eqn. 3
Herein, the term ‘zj’ indicates the results obtained at jth neuron upon the application of the summation function. Similarly, the term ‘bj’ refers to a bias value that is used to fine-tune the behavior of individual neurons, allowing the network to learn and make better predictions. Further, an activation function is applied to the results obtained after the application of the summation function at each neuron in each layer. In a non-limiting implementation, the activation function may be indicated as follows:
y_j=f(z_j ) … Eqn. 4
Herein, the term ‘yj’ indicates a result obtained at the jth neuron upon the application of the activation function on the results obtained from Eqn. 3, i.e., ‘zj’. In a non-limiting example, the activation function that is applied for each neuron of each layer of the hidden layers 404 may introduce non-linearity into the network, allowing the network (i.e., the TOW segmentation ML model 220) to learn complex patterns in the input data i.e., to learn complex transaction behavior patterns from the plurality of payment transaction-related features for each account holder. As mentioned above, several activation functions that can be applied at each neuron may include ReLu, tangent (tanh), sigmoid function, softmax, etc.
To that note, referring back to the example of the hidden layers 404 being L-1, L-2, and L-3 with the above-mentioned dimensions for each layer, from the last layer i.e., L-3 having 50 neurons, the set of TOW embeddings 408 may be obtained with a dimension of 20x1 upon performing similar computation on the 20 results received from the L-3, i.e., applying the summation and activation function on each neuron of L-3. In an embodiment, the server system 200 is configured to generate TOW segments 142 using the TOW segmentation ML model 220 from the set of TOW embeddings 408. In a specific scenario, where the account holders 104 are supposed to be classified under 8 TOW segments such as high usage, specific usage, seasonal usage, low usage, new user, inactive user, primary card, and secondary card, the output layer 406 of the TOW segmentation ML model 220 may have 8 neurons, each neuron corresponding to each segment category or class.
More specifically, a softmax function may be applied on each neuron of the output layer 406 for classifying the account holders 104 in one of the TOW segments 142. It may be noted that in the context of the feed-forward neural network, the 20 embeddings obtained from the last hidden layer correspond to raw scores (otherwise also referred to as logits). Now, since in the output layer 406, there are 8 neurons, the 20 logits from the set of TOW embeddings 408 are reduced to 8 logits by applying the summation function or linear transformation similar to how it was applied on the previous layers. Upon obtaining 8 logits, the softmax function is applied on each neuron to obtain a TOW segment prediction including probability distributions as outputs at each neuron in the output layer 406 such that the sum of all the probabilities is equal to 1. Herein, it may be noted that each value represents a likelihood of the input (i.e., each account holder) belonging to its corresponding class.
For instance, if the 8 TOW segments i.e., high usage, specific usage, seasonal usage, low usage, new user, inactive user, primary card, and secondary card are represented as a vector of probability distributions (i.e., the TOW segment prediction) and if the vector generated upon application of the softmax function is [0.8, 0.12, 0.03, 0.01, 0.01, 0.01, 0.01, 0.01], then a class with highest probability value will be assigned to the corresponding account holder. Herein, the TOW segment prediction has a dimension of 8x1. In the current scenario, since the class ‘high usage’ has the highest probability value, the account holder under consideration may be classified under the ‘high usage’ class. Similarly, all the account holders of the plurality of account holders 104 may be classified under different TOW segments accordingly.
Thus, in other words, it may be stated that the server system 200 is configured to generate the TOW segment prediction corresponding to each account holder based, at least in part, on the set of TOW embeddings 408 and the TOW threshold criteria. Herein, the TOW segment prediction may correspond to a vector of TOW scores such as the probability distributions indicating a likelihood of labeling the plurality of account holders 104 with the corresponding TOW label of the one or more TOW labels. In a non-limiting implementation, it may be noted that the TOW labels have names similar to that of the TOW segments 142. In an embodiment, the TOW threshold criteria correspond to the application of the activation function such as the softmax function. In a non-limiting implementation, the softmax function may be represented as follows:
S(a)_i=exp?(a_i )/(?_(j=1)^n¦? exp?(a_j ) ) … Eqn. 5
Herein, the term ‘a’ represents an input vector i.e., a vector of raw scores (logits) to the softmax function, S. It may include ‘n’ elements for ‘n’ classes. Similarly, the term ‘ai’ refers to ith element of the input vector. Further, ‘exp(ai)’ refers to the standard exponential function applied on ‘ai’. Similarly, ‘?_(j=1)^n¦? exp?(a_j )’ refers to a normalization term. It ensures that the values of output vector ‘S(a)i’ sum to 1 for ith class and each of them is in the range 0 and 1 which makes up a valid probability distribution.
In a non-limiting example, the TOW segmentation ML model 220 is trained to perform the classification task to predict a TOW segment or a TOW class of the above-mentioned TOW segments/classes, to which the plurality of account holders 104 belongs. It may be noted that the server system 200 may be configured to train the TOW segmentation ML model 220 to perform the classification task. The process of training the TOW segmentation ML model 220 is explained with reference to FIG. 3A.
Further, upon generating the TOW segment predictions corresponding to each of the plurality of account holders 104, the server system 200 may further be configured to generate one or more TOW labeled lists based, at least in part, on the TOW segment prediction. Herein, each TOW labeled list may include one or more TOW labeled account holders of the plurality of account holders 104 that are labeled with a particular TOW label of the one or more TOW labels.
Furthermore, in an embodiment, the account holders 104 that are classified under different TOW segments are further categorized by considering other parameters such as a credit exposure, a probability of default, etc. In a non-limiting example, it may be understood that, if the credit exposure and the probability of default parameters are considered, then the present disclosure also involves the computation of a probability of credit exposure and a probability of credit risk (otherwise also referred to as the probability of default) for each account holder. Further, the server system 200 may classify the account holders 104 under at least four classes such as the CRE classes 144 for each TOW segment of the account holders 104 using the CRE categorization ML model 222 based on these values. The architecture of the CRE categorization ML model 222 is explained further with reference to FIG. 5.
FIG. 5 illustrates a schematic representation 500 of an architecture of a CRE categorization ML model (e.g., the CRE categorization ML model 222), in accordance with an embodiment of the present disclosure. As mentioned earlier, the functionality of the CRE categorization ML model 222 is similar to that of the TOW segmentation ML model 220 with a variation of the classification task being performed. Thus, the classification task performed by the CRE categorization ML model 222 may be referred to as the CRE classification task. As mentioned earlier, the at least four classes 144 may include a high probability of default and high credit exposure 144A, high probability of default and low credit exposure 144B, low probability of default and high credit exposure 144C, and low probability of default and low credit exposure 144D.
To that end, it may be understood that the server system 200 is configured to generate a combined probability value indicating a particular account holder falling under one of the at least four classes 144. In order to do that, initially, the server system 200 may be configured to access the plurality of account-related features from the database 200. Further, the server system 200 may also access the set of TOW embeddings 408 and the TOW score (i.e., the result of classifying the account holders under the TOW segments using the TOW segmentation ML model 220). Later, in an embodiment, the server system 200 may be configured to concatenate the plurality of account-related features, the set of TOW embeddings 408, and the TOW score with each other.
However, it may be noted that prior to concatenation, dimensions of the plurality of account-related features, the set of TOW embeddings 408, and the TOW score may have to be matched. For instance, if the set of TOW embeddings 408 is two-dimensional, then it has to be reduced to one-dimensional so that it is feasible to concatenate it with the plurality of account-related features and the TOW score which is one-dimensional. To that note, in an embodiment, several techniques that can be used for reducing the dimensions of embeddings may include, but are not limited to, flattening, averaging, pooling, etc. However, in the current example, the dimension of the set of TOW embeddings 408 is 20x1, the TOW score is 8x1 (see, 502), and that of the plurality of account-related features is 160x1 (see, 504). Herein, the TOW score is the one obtained from the output layer 406 of the TOW segmentation ML model 220. Thus, it may be understood that the adjustment of dimensions is not needed as they are all vectors in a one-dimensional representation.
Further, the server system 200 is configured to concatenate the set of TOW embeddings 408, the corresponding TOW label of the TOW segment of each account holder, and the plurality of account-related features with each other using a predefined concatenation mechanism. In other words, the TOW segment of the account holder is treated as a new account holder feature for the account holder. As used herein, the term “concatenation mechanism” refers to a mechanism of joining vectors together in a new dimension. The server system 200 may further be configured to generate a combined feature vector based, at least in part, on the concatenation process. In accordance with the example considered, the combined feature vector may have a dimension of 188x1 (20x1 || 8x1 || 160x1) which corresponds to an input layer 506 of the CRE categorization ML model 222. Further, the server system 200 may provide the combined feature vector to the CRE categorization ML model 222 for training the CRE categorization ML model 222 to perform the CRE classification task. Upon receiving the combined feature vector, the CRE categorization ML model 222 may generate a set of CRE embeddings 508 upon passing the combined feature vector through different layers of the CRE categorization ML model 222. Herein, it may be noted that the set of CRE embeddings 508 is similar to the set of CRE embeddings of FIG. 3B.
In a non-limiting example, if the combined feature vector with 188x1 dimension is considered, then it may be noted that the input layer 506 of the CRE categorization ML model 222 may have 188 neurons, each neuron corresponding to each element of the combined feature vector. This may be followed by at least two hidden layers 510 with each layer having dimensions in the AxB format. For instance, the at least two hidden layers 510 may include a layer L-1 having a dimension of 188x80 and a Layer L-2 having a dimension of 80x40. To that end, it may be noted that for 188 neurons of the input layer 506, the L-1 of the hidden layers 510 has corresponding 188 neurons. Herein, each neuron of L-1 receives connections 512 from 188 neurons of the input layer 506. Upon receiving the 188 connections that are 188 weighted elements of the combined feature vector, the summation function as shown in Eqn. 3 may be applied on each neuron of L-1, followed by the activation function as shown in Eqn. 4. Thus, L-1 generates 80 outputs that may be termed as L-1 results hereinafter.
Similarly, L-2 of the hidden layers 510 has 80 neurons, with each neuron of L-2 receiving 80 connections 514 from L-1. Herein, the 80 connections received from L-1 may correspond to 80 weighted L-1 results, on which the summation function is applied for each neuron of L-2, followed by the activation function for generating 40 L-2 results. Herein, it may be noted that the application of the activation function on each neuron in the CRE categorization ML model 222, may introduce non-linearity into the CRE categorization ML model 222 to learn complex patterns associated with the combined feature vector.
To that note, it may be understood that from the last layer i.e., L-2 of the CRE categorization ML model 222 having 80 neurons, the set of CRE embeddings 508 may be obtained having a dimension of 40x1 upon performing similar computation on the 40 results received from the L-2, i.e., applying the summation and activation function on each neuron of L-2. In an embodiment, from the set of CRE embeddings 508, the server system 200 is configured to perform the CRE classification task using the CRE categorization ML model 222. In a specific scenario, where the account holders 104 are supposed to be classified under different CRE classes 144 such as a high probability of default and high credit exposure 144A, high probability of default and low credit exposure 144B, low probability of default and high credit exposure 144C, and low probability of default and low credit exposure 144D, the output layer 516 of the CRE categorization ML model 222 may have 4 neurons, each neuron corresponding to each CRE class.
Further, the softmax function may be applied at the output layer 516 in a way similar to the softmax function described earlier with reference to the TOW segmentation ML model 220, for obtaining at least four probability distributions corresponding to the at least four classes i.e., the credit risk-and-exposure classes 144. To that end, it may be noted that the 40 embeddings obtained from the last hidden layer of the CRE categorization ML model 222 correspond to raw scores (otherwise also referred to as logits). Now, since in the output layer 516 there are 4 neurons, the 40 logits from the set of CRE embeddings 508 is reduced to 4 logits by applying the summation function or linear transformation similar to how it was applied on the previous layers. Upon obtaining 4 logits, the softmax function is applied on each neuron to obtain a CRE class prediction including probability distributions as outputs at each neuron in the output layer 516 such that the sum of all the probabilities is equal to 1. Herein, it may be noted that each value represents a likelihood of the input (i.e., each account holder) belonging to its corresponding CRE class.
For instance, if the 4 CRE classes are represented as a vector of probability distributions (i.e., the CRE class prediction) and if the vector generated upon application of the softmax function is [0.8, 0.05, 0.15], then a class with the highest probability value will be assigned to the corresponding account holder. Herein, the CRE class prediction has a dimension of 4x1. In the current scenario, since the class ‘high probability of default and high credit exposure’ has the highest probability value, the account holder under consideration may be classified under the ‘high probability of default and high credit exposure’ class. Similarly, all the account holders of the plurality of account holders 104 may be classified under different CRE classes 144 accordingly.
Thus, in other words, it may be stated that the server system 200 is configured to generate the CRE class prediction corresponding to each account holder based, at least in part, on the set of CRE embeddings 508 and the CRE threshold criteria. Herein, the CRE class prediction may correspond to a vector of CRE scores such as the probability distributions indicating a likelihood of labeling each top-of-wallet labeled account holder of the plurality of account holders 104 with the corresponding CRE label of the one or more CRE labels. In a non-limiting example, the CRE labels may have names that are same as those of the CRE classes 144. In an embodiment, the CRE threshold criteria correspond to the application of the activation function such as the softmax function.
In a non-limiting example, the CRE categorization ML model 222 is trained to perform the CRE classification task. It may be noted that the server system 200 may be configured to train the CRE categorization ML model 222 to perform the CRE classification task. The process of training the CRE categorization ML model 222 is explained in the description with reference to FIG. 3B.
Further, upon generating the CRE class predictions corresponding to each Account holder, the server system 200 may further be configured to generate one or more CRE-labeled lists based, at least in part, on the CRE score. Herein, each CRE-labeled list may include one or more CRE-labeled account holders of the one or more Account holders that are labeled with a particular CRE label of the one or more CRE labels.
FIG. 6 illustrates a flow diagram depicting a method 600 for categorizing account holders (such as the account holders 104) under multiple classes or segments utilizing distinct scores, in accordance with an embodiment of the present disclosure. The method 600 depicted in the flow diagram may be executed by, for example, the server system 200. The sequence of operations of the method 600 may not be necessarily executed in the same order as they are presented. Further, one or more operations may be grouped and performed in the form of a single step, or one operation may have several sub-steps that may be performed in parallel or in a sequential manner. Operations of the method 600, and combinations of operations in the method 600 may be implemented by, for example, hardware, firmware, a processor, circuitry, and/or a different device associated with the execution of software that includes one or more computer program instructions. The plurality of operations is depicted in the process flow of the method 600. The process flow starts at operation 602.
At operation 602, the method 600 includes accessing, by a server system (such as the server system 200), a plurality of account-related features, a set of Top-of-Wallet (TOW) embeddings, and a TOW score corresponding to each account holder of a plurality of account holders 104 from a database such as the database 204 associated with the server system 200.
At operation 604, the method 600 includes assigning, by the server system 200, a TOW segment from one or more TOW segments 142 to each account holder based, at least in part, on the TOW score corresponding to each account holder, each TOW segment corresponding to an individual TOW label.
At operation 606, the method 600 includes generating, by the server system 200, a combined feature vector for each account holder from the one or more TOW segments 142 based, at least in part, on concatenating the plurality of account-related features, the set of TOW embeddings, and the corresponding TOW label of the TOW segment of each account holder.
At operation 608, the method 600 includes generating, by a credit risk-and-exposure (CRE) categorization ML model such as the CRE categorization ML model 222 associated with the server system 200, a set of CRE embeddings such as the set of CRE embeddings for each account holder based, at least in part, on the combined feature vector.
At operation 610, the method 600 includes determining, by the CRE categorization ML model 222, a CRE score corresponding to each account holder based, at least in part, on the set of CRE embeddings and CRE threshold criteria, the CRE score indicating a likelihood of the corresponding account holder belonging to a particular CRE class.
At operation 612, the method 600 includes assigning, by the server system 200, a CRE class from one or more CRE classes to each account holder based, at least in part, on the CRE score corresponding to each account holder, each CRE class corresponding to an individual CRE label.
FIG. 7 illustrates a simplified block diagram of the payment server 700, in accordance with an embodiment of the present disclosure. The payment server 700 is an example of the payment server 114 of FIG. 1A. The payment server 700 and the server system 200 may use the payment network 112 as a payment interchange network. Examples of payment interchange networks include, but are not limited to, Mastercard® payment system interchange network.
The payment server 700 includes a processing module 702 configured to extract programming instructions from a memory 704 to provide various features of the present disclosure. The components of the payment server 700 provided herein may not be exhaustive and the payment server 700 may include more or fewer components than that depicted in FIG. 7. Further, two or more components may be embodied in one single component, and/or one component may be configured using multiple sub-components to achieve the desired functionalities. Some components of the payment server 700 may be configured using hardware elements, software elements, firmware elements, and/or a combination thereof.
Via a communication module 706, the processing module 702 receives a request from a remote device 708, such as the issuer servers 108, the acquirer servers 110, or the server system 102. The request may be a request for conducting the payment transaction. The communication may be achieved through API calls, without loss of generality. The payment server 700 includes a database 710. The database 710 also includes transaction processing data such as issuer ID, country code, acquirer ID, and merchant identifier (MID), among others.
When the payment server 700 receives a payment transaction request from the acquirer servers 110 or a payment terminal (e.g., IoT device), the payment server 700 may route the payment transaction request to the issuer servers 108. The database 710 stores transaction identifiers for identifying transaction details such as transaction amount, IoT device details, acquirer account information, transaction records, merchant account information, and the like.
In one example embodiment, the acquirer servers 110 is configured to send an authorization request message to the payment server 700. The authorization request message includes, but is not limited to, the payment transaction request.
The processing module 702 further sends the payment transaction request to the issuer servers 108 for facilitating the payment transactions from the remote device 708. The processing module 702 is further configured to notify the remote device 708 of the transaction status in the form of an authorization response message via the communication module 706. The authorization response message includes, but is not limited to, a payment transaction response received from the issuer servers 108. Alternatively, in one embodiment, the processing module 702 is configured to send an authorization response message for declining the payment transaction request, via the communication module 706, to the acquirer servers 110. In one embodiment, the processing module 702 executes similar operations performed by the server system 200, however, for the sake of brevity, these operations are not explained herein.
The disclosed method with reference to FIG. 6, or one or more operations of the server system 200 may be implemented using software including computer-executable instructions stored on one or more computer-readable media (e.g., non-transitory computer-readable media, such as one or more optical media discs, volatile memory components (e.g., DRAM or SRAM), or nonvolatile memory or storage components (e.g., hard drives or solid-state nonvolatile memory components, such as Flash memory components) and executed on a computer (e.g., any suitable computer, such as a laptop computer, netbook, Web book, tablet computing device, smartphone, or other mobile computing devices). Such software may be executed, for example, on a single local computer or in a network environment (e.g., via the Internet, a wide-area network, a local-area network, a remote web-based server, a client-server network (such as a cloud computing network), or other such networks) using one or more network computers. Additionally, any of the intermediate or final data created and used during the implementation of the disclosed methods or systems may also be stored on one or more computer-readable media (e.g., non-transitory computer-readable media) and are considered to be within the scope of the disclosed technology. Furthermore, any of the software-based embodiments may be uploaded, downloaded, or remotely accessed through a suitable communication means. Such a suitable communication means includes, for example, the Internet, the World Wide Web, an intranet, software applications, cable (including fiber optic cable), magnetic communications, electromagnetic communications (including RF, microwave, and infrared communications), electronic communications, or other such communication means.
Although the invention has been described with reference to specific exemplary embodiments, it is noted that various modifications and changes may be made to these embodiments without departing from the broad scope of the invention. For example, the various operations, blocks, etc., described herein may be enabled and operated using hardware circuitry (for example, Complementary Metal Oxide Semiconductor (CMOS) based logic circuitry), firmware, software, and/or any combination of hardware, firmware, and/or software (for example, embodied in a machine-readable medium). For example, the apparatuses and methods may be embodied using transistors, logic gates, and electrical circuits (for example, Application-Specific Integrated Circuit (ASIC) circuitry and/or in Digital Signal Processor (DSP) circuitry).
Particularly, the server system 200 and its various components may be enabled using software and/or using transistors, logic gates, and electrical circuits (for example, integrated circuit circuitry such as ASIC circuitry). Various embodiments of the invention may include one or more computer programs stored or otherwise embodied on a computer-readable medium, wherein the computer programs are configured to cause a processor or the computer to perform one or more operations. A computer-readable medium storing, embodying, or encoded with a computer program, or similar language, may be embodied as a tangible data storage device storing one or more software programs that are configured to cause a processor or computer to perform one or more operations. Such operations may be, for example, any of the steps or operations described herein. In some embodiments, the computer programs may be stored and provided to a computer using any type of non-transitory computer-readable media. Non-transitory computer-readable media includes any type of tangible storage media. Examples of non-transitory computer-readable media include magnetic storage media (such as floppy disks, magnetic tapes, hard disk drives, etc.), optical magnetic storage media (e.g. magneto-optical disks), Compact Disc Read-Only Memory (CD-ROM), Compact Disc Recordable CD-R, Compact Disc Rewritable CD-R/W), Digital Versatile Disc (DVD), BLU-RAY® Disc (BD), and semiconductor memories (such as mask ROM, programmable ROM (PROM), Erasable PROM (EPROM), flash memory, Random Access Memory (RAM), etc.). Additionally, a tangible data storage device may be embodied as one or more volatile memory devices, one or more non-volatile memory devices, and/or a combination of one or more volatile memory devices and non-volatile memory devices. In some embodiments, the computer programs may be provided to a computer using any type of transitory computer-readable media. Examples of transitory computer-readable media include electric signals, optical signals, and electromagnetic waves. Transitory computer-readable media can provide the program to a computer via a wired communication line (e.g., electric wires, and optical fibers) or a wireless communication line.
Various embodiments of the invention, as discussed above, may be practiced with steps and/or operations in a different order, and/or with hardware elements in configurations, which are different from those which, are disclosed. Therefore, although the invention has been described based on these exemplary embodiments, it is noted that certain modifications, variations, and alternative constructions may be apparent and well within the scope of the invention.
Although various exemplary embodiments of the invention are described herein in a language specific to structural features and/or methodological acts, the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as exemplary forms of implementing the claims.
, Claims:1. A computer-implemented method, comprising:
accessing, by a server system, a plurality of account-related features, a set of Top-of-Wallet (TOW) embeddings, and a TOW score corresponding to each account holder of a plurality of account holders from a database associated with the server system;
assigning, by the server system, a TOW segment from one or more TOW segments to each account holder based, at least in part, on the TOW score corresponding to each account holder, each TOW segment corresponding to an individual TOW label;
generating, by the server system, a combined feature vector for each account holder from the one or more TOW segments based, at least in part, on concatenating the plurality of account-related features, the set of TOW embeddings, and the corresponding TOW label of the TOW segment of each account holder;
generating, by a credit risk-and-exposure (CRE) categorization Machine Learning (ML) model associated with the server system, a set of CRE embeddings for each account holder based, at least in part, on the combined feature vector;
determining, by the CRE categorization ML model, a CRE score corresponding to each account holder based, at least in part, on the set of CRE embeddings and CRE threshold criteria, the CRE score indicating a likelihood of the corresponding account holder belonging to a particular CRE class; and
assigning, by the server system, a CRE class from one or more CRE classes to each account holder based, at least in part, on the CRE score corresponding to each account holder, each CRE class corresponding to an individual CRE label.
2. The computer-implemented method as claimed in claim 1, wherein the plurality of account-related features comprises days past due date, balance past due date, credit balance data, partial payments data, product type data, and age of an account holder data.
3. The computer-implemented method as claimed in claim 1, further comprising:
accessing, by the server system, an account holder-related dataset from the database, the account holder-related dataset comprising historical information corresponding to a plurality of payment transactions performed by the plurality of account holders with a plurality of merchants;
generating, by the server system, the plurality of account holder-related features corresponding to each account holder based, at least in part, on the account holder-related dataset, the plurality of account holder-related features comprising a plurality of payment transaction-related features, and the plurality of account-related features; and
storing, by the server system, the plurality of account holder-related features for each account holder in the database.
4. The computer-implemented method as claimed in claim 3, wherein the plurality of payment transaction-related features comprises a card entry mode, card presence status, a merchant category, a transaction amount, a count of total transactions, a count of approved transactions, a count of declined transactions, and a count of fraudulent transactions.
5. The computer-implemented method as claimed in claim 4, further comprising:
accessing, by the server system, the plurality of payment transaction-related features corresponding to each account holder from the database;
generating, by a TOW segmentation ML model associated with the server system, the set of TOW embeddings based, at least in part, on the plurality of payment transaction-related features;
determining, by the TOW segmentation ML model, the TOW score corresponding to each account holder based, at least in part, on the set of TOW embeddings and TOW threshold criteria, the TOW score indicating a likelihood of the corresponding account holder belonging to a particular TOW segment; and
storing, by the server system, the set of TOW embeddings and the TOW score corresponding to each account holder in the database.
6. The computer-implemented method as claimed in claim 1, further comprising:
accessing, by the server system, a training dataset from the database, the training dataset comprising historical information related to a plurality of payment transactions performed by the plurality of account holders within a predefined time period and a true TOW label for each account holder; and
training, by the server system, a TOW segmentation ML model by performing a first set of operations iteratively until the performance of the TOW segmentation ML model converges to first predefined criteria, the first set of operations comprising:
initializing, the TOW segmentation ML model based, at least in part, on one or more first model parameters;
generating, by the TOW segmentation ML model, a set of training TOW embeddings based, at least in part, on the training dataset;
generating, by the TOW segmentation ML model, a TOW segment prediction for each account holder based, at least in part, on the set of training TOW embeddings, the TOW segment prediction indicating a predicted TOW label for each account holder;
computing a TOW loss for each account holder based, at least in part, on the predicted TOW label for each account holder and the true TOW label for each account holder;
computing a TOW gradient component for each account holder based, at least in part, on back-propagating the TOW loss; and
optimizing the one or more first model parameters based, at least in part, on the TOW gradient component.
7. The computer-implemented method as claimed in claim 1, further comprising:
accessing, by the server system, a training dataset from the database, the training dataset comprising historical information related to a plurality of payment transactions performed by the plurality of account holders within a predefined time period and a true CRE label for each account holder; and
training, by the server system, the CRE categorization ML model by performing a second set of operations iteratively until the performance of the CRE categorization ML model converges to second predefined criteria, the second set of operations comprising:
initializing, the CRE categorization ML model based, at least in part, on one or more second model parameters;
generating, by the CRE categorization ML model, a set of training CRE embeddings based, at least in part, on the training dataset;
generating, by the CRE categorization ML model, a CRE class prediction for each account holder based, at least in part, on the set of training CRE embeddings, the CRE class prediction indicating a predicted CRE label for each account holder;
computing a CRE loss for each account holder based, at least in part, on the predicted CRE label for each account holder and the true CRE label for each account holder;
computing a CRE gradient component for each account holder based, at least in part, on back-propagating the CRE loss; and
optimizing the one or more first model parameters based, at least in part, on the CRE gradient component.

8. The computer-implemented method as claimed in claim 6, wherein the TOW segmentation ML model is a feed-forward neural network-based ML model for performing a TOW segmentation task.
9. The computer-implemented method as claimed in claim 1, wherein the CRE categorization ML model is a feed-forward neural network-based ML model for performing a CRE categorization task.
10. The computer-implemented method as claimed in claim 1, wherein the server system is a payment server associated with a payment network.
11. A server system, comprising:
a communication interface;
a memory comprising executable instructions; and
a processor communicably coupled to the communication interface and the memory, the processor configured to cause the server system to at least:
access a plurality of account-related features, a set of Top-of-Wallet (TOW) embeddings, and a TOW score corresponding to each account holder of a plurality of account holders from a database associated with the server system;
assign a TOW segment from one or more TOW segments to each account holder based, at least in part, on the TOW score corresponding to each account holder, each TOW segment corresponding to an individual TOW label;
generate a combined feature vector for each account holder from the one or more TOW segments based, at least in part, on concatenating the plurality of account-related features, the set of TOW embeddings, and the corresponding TOW label of the TOW segment of each account holder;
generate, by a credit risk-and-exposure (CRE) categorization Machine Learning (ML) model associated with the server system, a set of CRE embeddings for each account holder based, at least in part, on the combined feature vector;
determine, by the CRE categorization ML model, a CRE score corresponding to each account holder based, at least in part, on the set of CRE embeddings and CRE threshold criteria, the CRE score indicating a likelihood of the corresponding account holder belonging to a particular CRE class; and
assign a CRE class from one or more CRE classes to each account holder based, at least in part, on the CRE score corresponding to each account holder, each CRE class corresponding to an individual CRE label.
12. The server system as claimed in claim 11, wherein the plurality of account-related features comprises days past due date, balance past due date, credit balance data, partial payments data, product type data, and age of an account holder data.
13. The server system as claimed in claim 11, wherein the server system is further caused at least to:
access an account holder-related dataset from the database, the account holder-related dataset comprising historical information corresponding to a plurality of payment transactions performed by the plurality of account holders with a plurality of merchants;
generate the plurality of account holder-related features corresponding to each account holder based, at least in part, on the account holder-related dataset, the plurality of account holder-related features comprising a plurality of payment transaction-related features, and the plurality of account-related features; and
store the plurality of account holder-related features for each account holder in the database.
14. The server system as claimed in claim 13, wherein the plurality of payment transaction-related features comprises a card entry mode, card presence status, a merchant category, a transaction amount, a count of total transactions, a count of approved transactions, a count of declined transactions, and a count of fraudulent transactions.
15. The server system as claimed in claim 14, wherein the server system is further caused at least to:
access the plurality of payment transaction-related features corresponding to each account holder from the database;
generate, by a TOW segmentation ML model associated with the server system, the set of TOW embeddings based, at least in part, on the plurality of payment transaction-related features;
determine, by the TOW segmentation ML model, the TOW score corresponding to each account holder based, at least in part, on the set of TOW embeddings and TOW threshold criteria, the TOW score indicating a likelihood of the corresponding account holder belonging to a particular TOW segment; and
store the set of TOW embeddings and the TOW score corresponding to each account holder in the database.
16. The server system as claimed in claim 1, wherein the server system is further caused at least to:
access a training dataset from the database, the training dataset comprising historical information related to a plurality of payment transactions performed by the plurality of account holders within a predefined time period and a true TOW label for each account holder; and
train a TOW segmentation ML model by performing a first set of operations iteratively until the performance of the TOW segmentation ML model converges to first predefined criteria, the first set of operations comprising:
initializing, the TOW segmentation ML model based, at least in part, on one or more first model parameters;
generating, by the TOW segmentation ML model, a set of training TOW embeddings based, at least in part, on the training dataset;
generating, by the TOW segmentation ML model, a TOW segment prediction for each account holder based, at least in part, on the set of training TOW embeddings, the TOW segment prediction indicating a predicted TOW label for each account holder;
computing a TOW loss for each account holder based, at least in part, on the predicted TOW label for each account holder and the true TOW label for each account holder;
computing a TOW gradient component for each account holder based, at least in part, on back-propagating the TOW loss; and
optimizing the one or more first model parameters based, at least in part, on the TOW gradient component.
17. The server system as claimed in claim 11, wherein the server system is further caused at least to:
access a training dataset from the database, the training dataset comprising historical information related to a plurality of payment transactions performed by the plurality of account holders within a predefined time period and a true CRE label for each account holder; and
train the CRE categorization ML model by performing a second set of operations iteratively until the performance of the CRE categorization ML model converges to second predefined criteria, the second set of operations comprising:
initializing, the CRE categorization ML model based, at least in part, on one or more second model parameters;
generating, by the CRE categorization ML model, a set of training CRE embeddings based, at least in part, on the training dataset;
generating, by the CRE categorization ML model, a CRE class prediction for each account holder based, at least in part, on the set of training CRE embeddings, the CRE class prediction indicating a predicted CRE label for each account holder;
computing a CRE loss for each account holder based, at least in part, on the predicted CRE label for each account holder and the true CRE label for each account holder;
computing a CRE gradient component for each account holder based, at least in part, on back-propagating the CRE loss; and
optimizing the one or more first model parameters based, at least in part, on the CRE gradient component.
18. The server system as claimed in claim 11, wherein the TOW segmentation ML model is a feed-forward neural network-based ML model for performing a TOW segmentation task.
19. The server system as claimed in claim 11, wherein the CRE categorization ML model is a feed-forward neural network-based ML model for performing a CRE categorization task.
20. A non-transitory computer-readable storage medium comprising computer-executable instructions that, when executed by at least a processor of a server system, cause the server system to perform a method comprising:
accessing a plurality of account-related features, a set of Top-of-Wallet (TOW) embeddings, and a TOW score corresponding to each account holder of a plurality of account holders from a database associated with the server system;
assigning a TOW segment from one or more TOW segments to each account holder based, at least in part, on the TOW score corresponding to each account holder, each TOW segment corresponding to an individual TOW label;
generating a combined feature vector for each account holder from the one or more TOW segments based, at least in part, on concatenating the plurality of account-related features, the set of TOW embeddings, and the corresponding TOW label of the TOW segment of each account holder;
generating, by a credit risk-and-exposure (CRE) categorization Machine Learning (ML) model associated with the server system, a set of CRE embeddings for each account holder based, at least in part, on the combined feature vector;
determining, by the CRE categorization ML model, a CRE score corresponding to each account holder based, at least in part, on the set of CRE embeddings and a CRE threshold criteria, the CRE score indicating a likelihood of the corresponding account holder belonging to a particular CRE class; and
assigning a CRE class from one or more CRE classes to each account holder based, at least in part, on the CRE score corresponding to each account holder, each CRE class corresponding to an individual CRE label.