Methods and systems for detecting anomalous entities from trust ratings

Abstract

Methods and server systems for detecting anomalous entities from trust ratings are described herein. Method performed by a server system includes receiving an authentication request message including entity identity information corresponding to an entity whose identity has to be authenticated for a cardholder with whom the entity interacts. Method includes receiving an entity risk insight of the entity from client server based on cardholder Identifier (ID) of cardholder and the entity identity information. Method further includes generating, by a classification model associated with the server system, a risk score for the entity based on the entity risk insight. Method includes generating a trust rating for the entity based on the risk score and a set of thresholds. Further, in response to the authentication request message, the method includes transmitting an authentication response message including the trust rating to the client server. The client server facilitates displaying trust rating to cardholder.

Description

[0001] METHODS AND SYSTEMS FOR DETECTING ANOMALOUS ENTITIES FROM TRUST RATINGS

[0002] CROSS-REFERENCE TO RELATED APPLICATION

[0003] This application claims the benefit of, and priority to, Indian Patent Application No. 202441053940, filed on July 15, 2024. The entire disclosure of the above application is incorporated herein by reference.

[0004] TECHNICAL FIELD

[0005] The present disclosure relates to a field of artificial intelligence-based processing systems and, more particularly, to electronic methods and complex processing systems for detecting anomalous entities from a trust rating.

[0006] BACKGROUND

[0007] In recent times, global technological advancement and the use of the internet have made it feasible for individuals to perform several tasks from the comfort of their homes, making life easier. The tasks can be to make financial transactions, attend meetings, book travel tickets, purchase goods and services, socially network using chat and voice channels, share photos and videos, perform marketing and branding, etc. Nonetheless, the same technological advancement and the use of the internet have made today’s cybercrimes more sophisticated. The term ‘cybercrime’ refers to a criminal activity committed using a computer or computer network as a tool to access, transmit, or manipulate data illegally. It can involve targeting computer devices and harming them or using the computers to commit cybercrimes. Examples of cybercrime include data breaches, malware attacks, phishing, identity theft, hacking, cyberstalking and harassment, financial theft, intellectual property theft, etc. To seek protection from such cybercrimes, traditionally, internet security packages, such as anti-virus, anti-malware, anti-spam, anti-phishing / anti-malicious websites, firewalls, basic intrusion prevention and detection, and other technical-type defenses have been proposed.

[0008] In addition, multiple other techniques that have been implemented to address cybercrime that exploit technical vulnerabilities include multi-factor authentication, network behavioral analysis, threat intelligence and update automation, etc. However, with time, cybercrime has evolved to target the human psyche, exploiting emotions and cognitive biases to achieve malicious goals such as making individuals divulge confidential or personal information. Such a cyber threat is referred to as social engineering. Social engineering differentiates itself from conventional cybercrimes by its ability to bypass advanced technical security measures through human interaction and the exploitation of trust. The attackers manipulate basic human tendencies, such as the desire to be helpful or the fear of authority, to bypass security protocols. Examples of social engineering attacks include digital attacks, phone attacks, in-person attacks, etc.

[0009] Digital attacks use email or text messages to trick people into clicking malicious links or opening an infected attachment, upon doing of which, a viral payload is delivered to the victim’s computer. Once installed, the user’s computer can frequently be made to carry out additional malicious activities, such as accessing data, spam email distribution, attacking other computers, breaching a closed network, downloading other malicious software, and the like. Such attacks are also referred to as phishing. Other digital attacks include spear phishing, whaling attacks, baiting, etc. Phone attacks can instill a sense of urgency in an individual to take action in order to avert a negative consequence. As a result, the individual or the individual’s information is at risk. Such attacks are also referred to as vishing. Attacks similar to vishing are zishing, angular phishing, etc. Pretexting can be an in-person attack and occurs when one party lies to another to gain access to privileged data. Social engineering takes advantage of communication channels, such as social networks, audio channels, video channels, etc. Further, social engineering also includes using Artificial Intelligence (Al) or Machine Learning (ML) techniques to create fake photos, videos, audio calls, video calls, other information, etc., that can convince an individual to divulge their personal information. As a result, the security and privacy of individuals and organizations is compromised. Successful social engineering attacks can also disrupt operations by compromising critical systems, leading to downtime, loss of productivity, and increased recovery costs.

[0010] Thus, a technological need exists for improved methods and systems for detecting anomalous entities from a trust rating.

[0011] SUMMARY

[0012] Various embodiments of the present disclosure provide methods and systems for detecting anomalous entities from a trust rating. In an embodiment, a computer-implemented method for detecting anomalous entities from a trust rating is disclosed. The computer-implemented method performed by a server system includes receiving an entity authentication request message including entity identity information corresponding to an entity whose identity has to be authenticated. Herein, the entity interacts with the cardholder. The computer-implemented method further includes receiving an entity risk insight corresponding to the entity from a client server based, at least in part, on a cardholder Identifier (ID) of the cardholder and the entity identity information. Further, the computer-implemented method includes generating, by a classification model associated with the server system, a risk score for the entity based, at least in part, on the entity risk insight. Furthermore, the computer-implemented method includes generating a trust rating for the entity based, at least in part, on the risk score and a set of thresholds. Moreover, the computer-implemented method includes transmitting an entity authentication response message including the trust rating to the client server. Herein, the client server facilitates a display of the trust rating to the cardholder.

[0013] 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 receive an entity authentication request message including entity identity information corresponding to an entity whose identity has to be authenticated. Herein, the entity interacts with the cardholder. The server system is further caused to receive an entity risk insight corresponding to the entity from a client server based, at least in part, on a cardholder Identifier (ID) of the cardholder and the entity identity information. Further, the server system is caused to generate, by a classification model associated with the server system, a risk score for the entity based, at least in part, on the entity risk insight. Furthermore, the server system is caused to generate a trust rating for the entity based, at least in part, on the risk score and a set of thresholds. Moreover, the server system is caused to transmit an entity authentication response message including the trust rating to the client server. Herein, the client server facilitates a display of the trust rating to the cardholder.

[0014] In yet another embodiment, a computer-implemented method generating an entity risk insight for detecting anomalous entities is disclosed. The computer-implemented method performed by a client server includes generating an entity authentication request message based, at least in part, on a trigger condition. Herein, the entity authentication request message is transmitted to a server system for authenticating an entity that interacts with a cardholder. Further, the entity authentication request message includes an entity identity information corresponding to the entity. The computer-implemented method includes extracting relevant information corresponding to the entity based, at least in part, on the entity identity information and a set of rules. The relevant information includes at least one of audio data, video data, or textual data. The computer-implemented method further includes generating, by a text-based classification model associated with the client server, an entity risk insight corresponding to the entity based, at least in part, on the relevant information. Further, the computer-implemented method includes transmitting the entity risk insight corresponding to the entity to the server system. Herein, the server system is configured to generate a trust rating for the entity based, at least in part, on the entity risk insight. Furthermore, the computer-implemented method includes facilitating a display of the trust rating to the cardholder.

[0015] Further, 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 receiving an entity authentication request message including entity identity information corresponding to an entity whose identity has to be authenticated. Herein, the entity interacts with the cardholder. The method further includes receiving an entity risk insight corresponding to the entity from a client server based, at least in part, on a cardholder Identifier (ID) of the cardholder and the entity identity information. Further, the method includes generating, by a classification model associated with the server system, a risk score for the entity based, at least in part, on the entity risk insight. Furthermore, the method includes generating a trust rating for the entity based, at least in part, on the risk score and a set of thresholds. Moreover, the method includes transmitting an entity authentication response message, including the trust rating, to the client server. Herein, the client server facilitates a display of the trust rating to the cardholder. BRIEF DESCRIPTION OF THE FIGURES

[0016] 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:

[0017] FIG. 1 illustrates an example representation of an environment related to at least some example embodiments of the present disclosure;

[0018] FIG. 2 illustrates a simplified block diagram of a server system, in accordance with an embodiment of the present disclosure;

[0019] FIG. 3 illustrates a simplified block diagram of a client server, in accordance with an embodiment of the present disclosure;

[0020] FIG. 4 illustrates a sequence flow diagram for facilitating a detection of anomalous entities from a trust rating, in accordance with an embodiment of the present disclosure;

[0021] FIG. 5 illustrates a flow diagram showing an overall flow of generating the trust rating, in accordance with an embodiment of the present disclosure;

[0022] FIG. 6A, FIG. 6B, FIG. 6C, FIG. 6D, and FIG. 6E, collectively, illustrate User Interfaces (UIs) depicting a process of generating a trust rating for an entity, in accordance with an embodiment of the present disclosure;

[0023] FIG. 7 illustrates a flow diagram depicting a method for detecting anomalous entities from a trust rating, in accordance with an embodiment of the present disclosure;

[0024] FIG. 8 illustrates a flow diagram depicting a method for generating an entity risk insight via a client server, in accordance with an embodiment of the present disclosure;

[0025] FIG. 9 illustrates a flow diagram depicting a method for detecting anomalous entities from a trust rating, in accordance with another embodiment of the present disclosure; and

[0026] FIG. 10 illustrates a simplified block diagram of a payment server, in accordance with an embodiment of the present disclosure.

[0027] 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 of example in nature. DETAILED DESCRIPTION

[0028] In the following description, for purposes of explanation, numerous specific details are set forth 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 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.

[0029] 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 appearance of the phrase “in an embodiment” in various places in the specification does not necessarily all refer 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.

[0030] 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.

[0031] 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.

[0032] For elucidatory purposes, the terms “cardholder”, “user”, “account holder”, “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.). The payment card may or may not be associated with the payment account and will be used by a merchant or a beneficiary to complete the payment transaction initiated by the cardholder. The payment account may be opened via an issuing bank or an issuer server.

[0033] The term “payment account” used throughout the description refers to a financial account that is used to fund a financial transaction. Examples of financial accounts include, but are not limited to, a savings account, a credit account, a checking account, and a virtual payment account.

[0034] The terms “payment transaction”, “financial transaction”, “e- commerce transactions”, “digital transaction”, and “transaction” are used interchangeably throughout the description and refer to a transaction of payment of a certain amount being initiated by the cardholder.

[0035] 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, a debit card, etc. Further, the issuer may also facilitate online banking services, such as electronic money transfer, bill payment, etc., to the cardholders through a server which is called “issuer server” throughout the description.

[0036] 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 using cash substitutes. Payment networks may use a variety of different protocols and procedures to process the transfer of money for several types of transactions. Payment networks are companies that connect an issuing bank with an acquiring bank or a beneficiary bank to facilitate online payment. It is to be noted that the payment networks are operated by organizations that are called “payment processors” throughout the description. The terms “payment card” and “card” are used interchangeably throughout the description and refer to a physical or virtual card that may or may not be linked with a financial or payment account. It may be presented to a merchant, a beneficiary, 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.

[0037] The term “entity” used throughout the description refers to a distinct unit that can be identified, described, or referred to as an individual, an object, a concept, or a thing. Further, entities are often characterized by a set of properties or attributes that define their unique characteristics. In the present disclosure, the term ‘entity’ refers to an individual that interacts with the cardholder. For example, the entity can be a merchant, a beneficiary, a friend, a relative, an organization, an attacker, a fraudster, or the like. Thus, it may be understood that the entity can be a genuine individual / organization or an anomalous individual / organization that can interact with the cardholder through one or more communication channels and possibly convince the cardholder to reveal personal information or initiate a payment transaction.

[0038] The term “communication channel” used throughout the description refers to a medium through which information is transmitted between individuals or groups. Examples of communication channels include, but are not limited to, verbal channels (e.g., telephone calls, mobile phone calls, audio / video calls, video conferences, etc.), written channels (e.g., email, text messages, social media posts, etc.), digital communication channel (e.g., social media platform, webinars, blogs, and online articles, etc.), visual communication channel (e.g., presentations, videos, webinars, etc.), broadcast communication channels (television, radio, podcasts, etc.), and the like.

[0039] OVERVIEW

[0040] Various embodiments of the present disclosure provide methods, systems, electronic devices, and computer program products for detecting anomalous entities from a trust rating. In an embodiment, the present disclosure describes a server system which may be embodied within a payment server associated with a payment network. In one embodiment, the server system may receive an authentication request message (otherwise, also referred to as ‘entity authentication request message’). In a non-limiting implementation, the entity authentication request message may be received from an electronic device associated with a cardholder. The authentication request message includes entity identity information corresponding to an entity whose identity has to be authenticated for the cardholder. In an embodiment, the entity authentication request message is generated in response to a trigger condition. Herein, the trigger condition may include at least one of: one or more entities interact with the cardholder via one or more communication channels, or the cardholder performs an input operation on a platform associated with the server system.

[0041] Further, the server system is configured to receive an entity risk insight corresponding to the entity from a client server based, at least in part, on a cardholder Identifier (ID) of the cardholder and the entity identity information. In a non-limiting implementation, the client server is implemented in the electronic device of the cardholder. The server system is further configured to generate, by a first Machine Learning (ML) model (otherwise, also referred to as ‘classification model’) associated with the server system, a risk score for the entity based, at least in part, on the entity risk insight.

[0042] For generating the risk score, the classification model has to be trained. Thus, in a non-limiting implementation, for training the classification model, the server system may access a plurality of features (otherwise, also referred to as ‘features’) from a database associated with the server system and generate a training feature set based, at least in part, on the features. Herein, the training feature set is used for training the classification model. The training process includes configuring the server system to access the training feature set from the database. The server system is then configured to initialize the classification model with the training feature set and one or more first model parameters. Thereafter, in an embodiment, the server system is configured to perform a first set of operations for each entity of the one or more entities iteratively until first convergence criteria are met. The first set of operations may include: (i) generating, by the classification model, a first predicted risk score based, at least in part, on the training feature set and the one or more first model parameters, the first predicted risk score indicating a likelihood of the corresponding entity being anomalous; (ii) generating, by the classification model, a first prediction including a first predicted label for the corresponding entity based, at least in part, on the first predicted risk score; (iii) computing a first loss based, at least in part, on the first predicted label, a true label, and a loss function; and (iv) optimizing the one or more first model parameters based, at least in part, on back- propagation of the first loss. Upon training, the server system may compute the risk score based, at least in part, on the entity identity information using the classification model.

[0043] For generating the features, in an embodiment, the server system is configured to access an entity risk insight dataset from the database. The entity risk insight dataset includes historical risk insight information corresponding to one or more entities that interacted with the cardholder during a predefined period. The entity risk insight dataset also includes the entity risk insight of the entity. Herein, the one or more entities include the entity. The server system may further receive a transaction dataset including historical information corresponding to a plurality of payment transactions performed by the cardholder. The server system may also receive a platform analytics dataset corresponding to one or more digital platforms facilitating the exchange of information between a plurality of entities and a plurality of cardholders. In an embodiment, the server system may receive the transaction dataset and the platform analytics dataset from one or more data sources operatively coupled with the server system based, at least in part, on the cardholder ID. Further, the server system may generate the features including a set of risk insight features, a set of transaction features, and a set of platform features based, at least in part, on the entity risk insight dataset, the transaction dataset, and the platform analytics dataset. These features are stored in the database, which is accessible for future use, such as for training the classification model.

[0044] Furthermore, the server system is configured to generate a trust rating for the entity based, at least in part, on the risk score and a set of thresholds. Finally, in an embodiment, in response to the entity authentication request message, the server system is configured to transmit an authentication response message (otherwise, also referred to as ‘entity authentication response message’) including the trust rating to the electronic device. In another embodiment, the server system may transmit the entity authentication response message to the client server. The client server may facilitate a display of the trust rating to the cardholder.

[0045] In various embodiments, the server system may receive a feedback from the cardholder based, at least in part, on the trust rating associated with the entity. Thereafter, the server system may optimize the classification model based, at least in part, on the feedback.

[0046] In an embodiment, the client server is configured to the entity authentication request message based, at least in part, on the trigger condition. Herein, the entity authentication request message is transmitted to the server system for authenticating the entity that interacts with the cardholder. The entity authentication request message may include the entity identity information corresponding to the entity. The client server may further extract relevant information corresponding to the entity based, at least in part, on the entity identity information and a set of rules. The relevant information may include at least one of audio data, video data, or textual data associated with the trigger condition. Further, the client server may generate, by a text-based classification model associated with the client server, an entity risk insight corresponding to the entity based, at least in part, on the relevant information. Thereafter, the client server may transmit the entity risk insight corresponding to the entity to the server system. Herein, the server system is configured to generate a trust rating for the entity based, at least in part, on the entity risk insight. The client server may then facilitate a display of the trust rating to the cardholder.

[0047] Further, for generating the entity risk insight, in an embodiment, the client server is configured to access the relevant information corresponding to the entity from a client database associated with the client server. The client server may generate, by a speech-to-text model associated with the client server, speech-to-text data based, at least in part, on the audio data and the video data of the relevant information. Thereafter, the client server may generate a set of token IDs for the entity based, at least in part, on the speech-to-text data, the textual data, and a tokenizer vocabulary dataset. Herein, the entity risk insight is generated using the text-based classification model based, at least in part, on the set of token IDs.

[0048] Prior to using the text-based classification model, it has to be trained. Thus, in an embodiment, for training the text-based classification model, the client server may access a training token ID set from the client database. Then, the client server may initialize the text-based classification model with the training token ID set and one or more second model parameters. Thereafter, the client server may perform a second set of operations for each entity of the one or more entities iteratively until second convergence criteria are met. In an embodiment, the second set of operations may include: (i) generating, by the text-based classification model, a training embedding set based, at least in part, on the training token ID set; (ii) generating, by the text-based classification model, a second predicted risk score based, at least in part, on the training embedding set and the one or more second model parameters, the second predicted risk score indicating a likelihood of the corresponding entity being anomalous; (iii) generating, by the text-based classification model, a second prediction comprising a second predicted label for the corresponding entity based, at least in part, on the second predicted risk score; (iv) computing a second loss based, at least in part, on the second predicted label, a true label, and a loss function; and (v) optimizing the one or more second model parameters based, at least in part, on back- propagation of the second loss. In response to meeting the second convergence criteria, the client server may generate a final prediction indicating the entity risk insight corresponding to the entity.

[0049] In an embodiment, the client server is configured to store the entity risk insight corresponding to the entity in the client database. Further, the client server may delete the relevant information corresponding to the entity from the client database based, at least in part, on the set of rules. Thereafter, the client server may form the entity risk insight dataset including the historical risk insight information corresponding to the one or more entities that interacted with the cardholder during the predefined period based, at least in part, on the storing step and the deletion step. The historical risk insight information may include one or more entity risk insights corresponding to the one or more entities.

[0050] In a specific embodiment, the client server is configured to access the entity risk insight dataset including the historical risk insight information corresponding to the one or more entities that interacted with the cardholder during the predefined period from the client database. The client server may then generate one or more token ID sets for the corresponding one or more entities based, at least in part, on the entity risk insight dataset and the tokenizer vocabulary dataset. Thereafter, the client server may generate the training token ID set based, at least in part, on the one or more token ID sets. Herein, the training token ID set is used for training the text-based classification model which is then used for generating the entity risk insight.

[0051] Various embodiments of the present disclosure offer multiple advantages and technical effects. For instance, the methods and the systems proposed in the present disclosure provide a solution to the problem of understanding and predicting the authenticity of an individual requesting personal information from another individual. This problem is solved by facilitating the assignment of a rating to a beneficiary or the individual requesting the personal information. Such a rating is assigned prior to the initiation of processing of a payment transaction to the corresponding individual, thereby preventing the user from making a payment transaction to a fraudulent entity. For example, even if a user is convinced over a phone call to make a specific amount of payment transaction i.e., fall prey to social engineering, during the initiation of the payment transaction, the trust rating generated by the approach proposed in the present disclosure provides a second opinion to the user about the beneficiary. As a result, the user is prevented from facing a financial loss due to social engineering.

[0052] Further, the approach proposed in the present disclosure also takes care of latency, data privacy, and data localization as it utilizes the concept of edge computing and federated learning along with advanced Machine Learning technologies. Furthermore, the alerts in the form of the trust rating are provided to the users in real-time as data from different communication channels used by the user is captured continuously in real-time. Further, the latency and privacy of such data are taken care of, as the data is locally utilized for generating risk insights and deleted within a constant period. In addition, the trust rating generated using the approach proposed in the present disclosure provides enhanced scam protection, real-time threat analysis, and better future protection due to the reinforcement learning of the ML models.

[0053] Furthermore, issuers may also face benefits, such as avoiding loss of funds through compromised accounts, partnership with insurance companies for account insurance is advantageous, enhanced user experience for account holders, and the like. The government can also receive benefits, such as enhanced data security for residents, data localization and privacy protection (i.e., on soil compliance), ensuring payment ecosystem security, and the like. Benefits that merchants experience may include preventing fraudulent account takeovers for consumers, avoiding chargeback losses due to fraudulent orders, and the like.

[0054] In other words, the approach proposed in the present disclosure allows a user to have safeguards against social engineering attacks by using the Al or ML models to detect malicious intents in the calls / mail / texts received. It is to be noted that leveraging edge computing framework to ensure data privacy and real-time threat detection using Al at the user end is a unique approach. The reliability of the threat analysis is enhanced via the unique payment network understanding of malicious attackers (MA) provided along with previously compromised or reported incidents sourced from the dark web and other social media and web analytics platforms.

[0055] For instance, an entity being a social engineering attacker impersonating a friend of a cardholder can contact the cardholder by making a phone call from a random contact number. The entity can imitate the voice of one of the friends of the cardholder and narrate a false empathizing story, convincing the cardholder to transfer a specific amount to the entity by providing specific account details. The cardholder may then go ahead and transfer the requested amount with the intent to help a friend in need, thereby falling prey to a social engineering attack. To address this problem, the cardholder having the proposed system as an add-on extension feature on a banking platform can provide permission to capture snippets of the call recording from a mobile phone of the cardholder, whenever the cardholder addresses the call from different individuals. The snippets have voice recordings of both the cardholder and the entity that has the phone called the cardholder. From analyzing the snippets, the intent of the entity can be determined using ML models such as a speech-to-text model and a text-based classification model.

[0056] Once the cardholder is convinced to make the payment to the entity, the cardholder might visit the banking platform to log in to their account by providing a login ID and password on the login page. Then, the cardholder enters the account details of the beneficiary, i.e., the entity that is received from the entity over the call. As the cardholder has the proposed system added to the banking platform, a trust rating is displayed for the corresponding account details of the entity. Upon viewing the trust rating, the cardholder decides whether to proceed with the payment or not. Thus, it may be understood that the trust rating that is assigned to the beneficiary acts as an indication for the cardholder about the authenticity of the entity requesting the cardholder to make the payment of a certain amount.

[0057] Various example embodiments of the present disclosure are described hereinafter with reference to FIG. 1 to FIG. 10.

[0058] FIG. 1 illustrates an example 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 performing one or more operations, for example, generating a risk score for entities that interact with a cardholder, generating a trust rating based on the risk score and a set of thresholds, and the like.

[0059] The environment 100, generally includes a plurality of components, such as a server system 102, a cardholder 104 associated with an electronic device 106, one or more entities 108(1), 108(2), . . . 108(N) (collectively referred to hereinafter as a ‘entities 108’), an issuer server 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, ‘N’ is a non-zero natural number, and the value of ‘N’ may or may not be the same for the plurality of components shown in FIG. 1.

[0060] In an embodiment, the server system 102 may be used by a managing entity (not shown) to train the one or more Machine Learning (ML) models for detecting the anomalous entities from a trust rating to protect individuals from social engineering fraud. As may be understood, the proposed approach is explained with reference to detecting anomalous entities in a financial industry. However, social engineering is fundamentally about manipulating human trust and emotions, not just for immediate money access, but can also be for disruption, sabotage, and stealing of data in a variety of industries. Stolen data can then be used for personal benefit in multiple ways (e.g., selling sensitive data to the dark web, selling data between industry peers, performing credential -based attacks, blackmailing, etc.}. Thus, it is noted that the proposed approach is also applicable to various other application domains. Examples of the application domains where the proposed approach can be applicable can include healthcare, government, energy and utilities, manufacturing, education, and other such application domains without limiting the scope of the present disclosure. For instance, in the healthcare domain, since healthcare organizations hold vast amounts of sensitive personal, medical, and financial data, and since healthcare workers often work under pressure, they can become prime targets for manipulation. This can lead to a breach of protected health information (PHI), legal penalties, patient safety risks (e.g., tampered prescriptions, altered records, etc.}, and the like.

[0061] In a non-limiting implementation, the managing entity may be any individual, representative of a person, an institution, an organization, a corporate entity, a non-profit organization, a financial institution (c.g, issuers, acquirers, etc.}, a bank, medical facilities (e.g., hospitals, laboratories, etc.), educational institutions, government agencies, telecom industries, or the like. In an example, the managing entity may be an administrator of the server system 102.

[0062] In an embodiment, the server system 102 is configured to facilitate the payment processors that control the payment network 112 to perform the above- mentioned operations. In another embodiment, the server system 102 is configured to facilitate issuers to perform the above-mentioned operations. In yet another embodiment, the server system 102 can facilitate a merchant to perform the above- mentioned operations. Further, in yet another embodiment, the server system 102 can facilitate any other third-party platform to perform the above-mentioned operations by being available as an add-on feature on such platforms for enhanced user experience. In a non-limiting example, the third-party platform can be provided by one or more third parties, such as a bank, a government agency, existing cyber security platforms, an insurance agency, and the like. The details of these operations and various other configurations of the server system 102 are explained later in the present disclosure.

[0063] In an embodiment, the cardholder (e.g., the cardholder 104) can 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 cardholder 104 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).

[0064] In a non-limiting implementation, the cardholder 104 may be provided with one or more payment cards (not shown in Figures), to make the payment transactions with financial or other account information encoded onto the payment card. The information may be encoded in the payment card such that the cardholder 104 can use the payment card to initiate and complete payment transactions using a bank account at the issuing bank.

[0065] In another non -limiting implementation, the cardholder 104 may use the electronic device 106 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 device 106 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 cardholder 104 can be associated with the financial institutions such as issuing banks which are associated with the issuer server 110. The terms “issuer bank”, “issuing bank” or simply “issuer”, “issuer server”, and “issuer servers”, hereinafter may be used interchangeably. It may be understood that a cardholder (e.g., the cardholder 104) may have the payment account with the issuing bank, (that may issue a payment card, such as a credit card or a debit card to the cardholder 104). Further, the issuing banks provide microfinance banking services (e.g., payment transactions using credit / debit cards) for processing electronic payment transactions, to the cardholder 104.

[0066] Further, in an embodiment, the entities 108 may include individuals, objects, or concepts that may or may not interact with each other or are related or unrelated to each other in a network (c.g, the network 112). For example, the entity (e.g., the entity 108(1)) may include any individual, representative of a person, an institution, an organization, a corporate entity, a financial institution, a bank, a cardholder, a merchant, medical facilities (e.g., hospitals, laboratories, etc.), educational institutions, government agencies, telecom industries, or the like. It is to be noted that the entities 108 can include anomalous entities or non-anomalous entities. Anomalous entities may be involved in cybercriminal activities, such as phishing, vishing, social engineering, etc.

[0067] In some embodiments, the cardholder 104 can receive a communication request from the entities 108 through one or more communication channels. As described earlier, the communication channels may include verbal channels, written channels, digital channels, visual channels, and the like. Thus, the cardholder 104 may be engaged in communication (otherwise, also referred to as ‘interact’) with any of the entities 108 through any of the communication channels. The engagement may be through an offline phone call, offline video call, an online audio / video call, a conference meeting, a text message, an email, or the like.

[0068] In a specific embodiment, the entity 108(1) can be a merchant who might have contacted the cardholder 104 to advertise their products. The term “merchant”, used throughout the description generally refers to a seller, a retailer, a purchase location, an organization, an insurance company, a financial institution, or any other entity that is in the business of selling goods or providing services. In an embodiment, the merchant can include retail shops, restaurants, supermarkets or establishments, government, and / or private agencies, or any such places equipped with POS terminals, where the cardholder 104 visits to perform financial transactions in exchange for any goods and / or services or any financial transactions. Moreover, it can refer to either a single business location or a chain of business locations of the same entity. Further, the merchant may be associated with an acquirer. Herein, 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). In an embodiment, the merchant is generally associated with a financial institution such as the acquiring bank which is associated with the acquirer server. The terms “acquirer”, “acquirer bank”, “acquiring bank”, “acquirer server”, and “acquirer servers” will be used interchangeably hereinafter.

[0069] In one scenario, the cardholder 104 may use their corresponding payment accounts to conduct payment transactions with the merchant. Moreover, it may be noted that the cardholder 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 cardholder 104 may enter payment account details on the electronic device 106 associated with the cardholder 104 to perform an online payment transaction. In another instance, the cardholder 104 may utilize the payment card to perform an offline payment transaction. In yet another instance, the cardholder 104 may enter details of the payment card to transfer funds in the form of fiat currency on an e-commerce platform to buy goods.

[0070] Due to the complexity of the banking network, in some embodiments, the cardholder 104 and the merchant can be associated with the same banking institution, e.g., ABC Bank. In such a situation, the ABC Bank will act as an issuer for the cardholder 104 and an acquirer for the merchant. Thus, a banking institution may act as both an acquirer and / or an issuer depending on the needs of its clients.

[0071] In an embodiment, the payment network 112 may be used by the payment card issuing authorities such as the issuers, as a payment interchange network. A payment interchange network allows for the exchange of electronic payment transaction data between the issuers and the acquirers. The payment network 112 includes the payment server 114 which is responsible for facilitating the various operations of the payment network 112. In one scenario, the payment server 114 is configured to operate a payment gateway for facilitating the various entities in the payment network 112 to perform digital transactions.

[0072] In various embodiments, 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. 1, 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), 2ndGeneration (2G), 3rdGeneration (3G), 4thGeneration (4G), 5thGeneration (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. 1.

[0073] In a non-limiting scenario, the entity (e.g., the entity 108(1)) including a merchant can be an anomalous entity impersonating a genuine merchant with whom the cardholder 104 has a good relationship. Herein, the merchant can be an entity that is a social engineering attacker who can manipulate the cardholder 104 into believing, for example, that a discount deal is exclusively being provided for the cardholder 104 based on their past purchase rate. The merchant can appreciate the cardholder 104 for their past purchase rate and their courtesy to provide positive reviews for the merchant, along with offering them an enticing deal. The merchant can then convince the cardholder 104 to make the payment of a specific account (mostly a malicious account) for their next purchase to receive the benefits of the deal offered to the cardholder 104. As a result, the cardholder 104 can end up making the payment to the merchant who is the anomalous entity, and receive neither the product nor any benefits in return, facing financial losses. Further, if the cardholder 104 tries to contact the same merchant, might fail to do so as such merchants (i.e., the anomalous entities) are generally not reachable. The cardholder 104 may then contact the genuine merchant that the anomalous entity was impersonating by visiting their website or application, only to discover that they were the victims of social engineering.

[0074] In another scenario, the entity (e.g., the entity 108(2)) can be a social engineering attacker impersonating a friend of the cardholder 104. In a specific example, the entity 108(2) can contact the cardholder 104 by making a phone call to the cardholder 104 from a random contact number. Further, the entity 108(2) can imitate the voice of one of the friends of the cardholder 104 and narrate a false empathizing story, convincing the cardholder 104 to transfer a specific amount to the entity 108(2) by providing specific account details. The cardholder 104 may then go ahead and transfer the requested amount with the intent to help a friend in need, thereby falling prey to a social engineering attack.

[0075] In some other scenarios, social engineering attacks can also happen to the cardholder 104 in the form of a convincing text message or email related to, for example, a course from a reputed organization for which the cardholder 104 is willing to take admission. In such a scenario, the sender of the text message or the email might appear genuine as they copy the appearance of emails and text messages of the genuine organizations, with minor changes (which generally go unnoticeable). Possibly, the cardholder 104, in the past, might have contacted the genuine organization asking for admissions and eagerly waiting for their response. The anomalous entity takes advantage of such a scenario and asks the cardholder 104 to transfer the admission fees or a portion of the admission fee to lock their seat. As a result, the cardholder 104 can fall prey to such a social engineering attack.

[0076] As described earlier, conventionally, technical vulnerabilities of computer systems and networks are attacked by attackers, to which there exist conventional solutions, such as anti-virus, anti-malware, firewall, etc., products. However, the social engineering attacks being reliant on human interactions and sentiments rather than technical vulnerabilities of the computer systems, have remained partially addressed. Further, with technical advancement, Artificial Intelligence (Al) or ML technologies have been utilized to seek protection from cybercrimes and social engineering attacks. However, cybercriminals and social engineering attackers have also advanced their tactics by utilizing the Al or ML technologies. They can use strategies, such as making fake audio / video calls impersonating a genuine entity, generating fake audio / videos personating the genuine entity by utilizing the Large Language Model (LLM), using the concept of Generative Al, and the like. Further, conventionally, it is very challenging to identify such actions as fraudulent. Therefore, there is a need for a technical solution for detecting anomalous entities that are involved in making social engineering attacks.

[0077] 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. It should be noted that the objective of the server system 102 is to understand and predict the authenticity of an entity requesting personal information from the cardholder. In an embodiment, another objective of the server system 102 is to perform this operation without hampering the privacy of the cardholder.

[0078] In a specific embodiment, the server system 102 can be used by the payment processors by embedding the server system 102 in the payment server 114. In another specific embodiment, the server system 102 can be embedded in the issuer server 110. As a result, features of the server system 102 may appear as an add-on extension on a website or application provided by the issuer to the cardholder 104 to manage their payment transactions. In yet another specific embodiment, the server system 102 can be embedded in the acquirer server (not shown in Figures). As a result, features of the server system 102 may appear as an add-on extension on a website or application provided by the acquirer to the merchant to receive payment transactions from the cardholders (e.g., the cardholder 104). In some embodiments, the server system 102 may be embedded in any third-party website or application provided by the third parties (as described earlier).

[0079] It is to be noted that for the cardholder 104 to be able to access the different features and services provided by the server system 102, the cardholder 104 may have to agree to a set of rules. In a non-limiting example, the set of rules may include permission to access a contact list of the cardholder 104, fetch call recording snippets, access text messages and emails, access to audio, access to a video camera, and the like. As the cardholder 104 accesses any of the websites or applications accessible on the electronic device 106, the features and services facilitated by the server system 102 may be available for the cardholder 104 as an add-on extension on the corresponding websites or applications. In some embodiments, the features, and services of the server system 102 may be available for the cardholder 104 as a standalone application that the cardholder 104 can install on the electronic device 106 and use.

[0080] In a specific embodiment, the server system 102 is configured to receive an authentication request message (otherwise, also referred to as ‘entity authentication request message’) including entity identity information corresponding to an entity (e.g., the entity 108(1)) whose identity has to be authenticated for the cardholder 104. Herein, the entity 108(1) may interact with the cardholder 104. In a non-limiting example, the entity identity information may include entity payment account details, an entity identifier (ID), such as an entity name, an entity contact number, an entity email ID, etc., and the like. Herein, the entity 108(1) may be one of the one or more entities 108 that may interact with the cardholder 104 through the one or more communication channels. It is to be noted that the communication channels may be a part of the network 118.

[0081] In an embodiment, the authentication request message is generated in response to a trigger condition. Herein, the trigger condition may include at least one of the one or more entities 108 interact with the cardholder 104 via the one or more communication channels, or the cardholder 104 performs an input operation on a platform associated with the server system 102. More specifically, in an embodiment, the authentication request message may be triggered upon receiving calls or text messages from the one or more entities 108 on the electronic device 106. In another embodiment, the authentication request message is triggered upon receiving an email from the one or more entities 108 on the electronic device 106. In yet another embodiment, the authentication request message is triggered when the cardholder 104 provides the entity identity information corresponding to the entity 108(1) on a platform (c.g, a banking platform) for adding the corresponding entity 108(1) as a beneficiary. Further, in yet another embodiment, the authentication request message is triggered by the cardholder 104 by providing the entity identity information corresponding to the entity 108(1) on a platform (c.g, a banking platform). In some embodiments, the entity 108(1) may have interacted with the cardholder 104 at least once in past through the one or more communication channels. In some other embodiments, the cardholder 104 may have received the entity identity information corresponding to the entity 108(1) from other entities.

[0082] The server system 102 may further be configured to receive an entity risk insight corresponding to the entity 108(1) from a client server (c.g, the client server 122) based, at least in part, on a cardholder ID of the cardholder 104 and the entity identity information. In a non-limiting implementation, the client server 122 is implemented in the electronic device 106 of the cardholder 104. In an embodiment, the client server 122 may be associated with a client database 124. Moreover, in a specific embodiment, the client server 122 generates the entity risk insight using a second ML model 126 (hereinafter, interchangeably referred to as a ‘text-based classification model 126’). It is to be noted that the client server 122 may be configured to train the second ML model 126. Upon generating the entity risk insight, the client server 122 may be configured to store the entity risk insight in the client database 124 which is accessible for future use such as by the server system 102 for authenticating the entity 108(1). In an embodiment, the client server 122 may indicate a server that may be positioned in proximity to an end-user device such as the electronic device 106. In another embodiment, the client server 122 may be embedded or implemented in the electronic device 106. In some embodiments, the client server 122 may be a local server or a cloud server. The process of generating the entity risk insight by the client server 122 is explained later in the present disclosure.

[0083] Further, the server system 102 may be configured to generate a risk score for the entity 108(1) based, at least in part, on the entity risk insight. In an embodiment, the server system 102 generates the risk score using a first ML model 120 (hereinafter, interchangeably referred to as a ‘classification model 120’) associated with the server system 102.

[0084] It may be understood that the database 116 may be configured to store the entity risk insight associated with the corresponding entity 108(1). The first ML model 120 may also be stored in the database 116 along with the entity risk insight. Further, the database 116 may provide a storage location for data and / or metadata obtained from various operations performed by the server system 102.

[0085] 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 operator or 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.

[0086] Further, it may be noted that, in a specific example, the server system 102 coupled with the database 116 is embodied within an issuer server (e.g., the issuer server 110) or any other third-party platforms, however, in other examples, the server system 102 can be a standalone component (acting as a hub) connected to the payment server 114, the issuer server 110, the acquirer server, and the like. 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.

[0087] Further, it may be noted that the features may be generated by the server system 102 using a concept of feature engineering. As used herein, the term ‘feature engineering’ refers to the process of using domain knowledge to create new features from raw data to improve the performance of ML models. Moreover, in a non-limiting implementation, for generating the features, the server system 102 is also configured to access data not only from the client server 122, but also from the issuer server 110, the payment server 114, and a plurality of data sources 128(1), 128(2), . . . 128(N) (collectively referred to hereinafter as a ‘data sources 128’). Herein, ‘N’ is a non-zero natural number. It is to be noted that the data sources 128 may gather data from the third-party platforms. In some scenarios, some of the third-party platforms may be involved in cybercrime analytics and can provide data related to cybercriminal activities that have occurred in the past.

[0088] As mentioned earlier, the server system 102 may utilize the first ML model 120 for generating the risk score for the entity 108(1). The server system 102 may be configured to train the first ML model for generating the risk score. The process of generating the features, training the first ML model using the same, and using the first ML model for generating the risk score is explained in detail further in the present disclosure.

[0089] Upon obtaining the risk score, the server system 102 may be configured to generate a trust rating for the entity 108(1) based, at least in part, on the risk score and a set of thresholds. The trust rating may indicate a likelihood of the entity 108(1) being an anomalous entity. In other words, the trust rating may indicate the likelihood of the entity 108(1) being anomalous. Herein, the set of thresholds may indicate a range of values between which the risk score appears, then a particular trust rating is assigned to the corresponding entity 108(1). In a non-limiting example, the trust rating can be in the form of a star rating. For example, if the risk score is in the range of 20 to 40, then the trust rating assigned to the corresponding entity 108(1) can be a two-stars rating. A label that can be assigned to the entity 108(1) for the two stars rating can be ‘more likely anomalous entity’. Any other form for representing the trust rating can also be used without limiting the scope of the invention disclosed in the present disclosure. In an embodiment, the set of thresholds may be based on defining metrics, such as a false positive rate and recall of the first ML model 120 on the social engineering attack labeled calls / mail / texts.

[0090] Further, in an embodiment, in response to the authentication request message, the server system 102 may be configured to transmit an authentication response message (hereinafter, interchangeably referred to as ‘entity authentication response message’) including the trust rating to the electronic device 106. In another embodiment, the server system 102 may transmit the entity authentication response message to the client server 122. The client server 122 may facilitate a display of the trust rating to the cardholder 104. Based on the trust rating, the cardholder 104 may decide whether to proceed to trust the entity 108(1) for any future interactions and / or payment transactions or not.

[0091] The number and arrangement of systems, devices, and / or networks shown in FIG. 1 are 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. 1. Furthermore, two or more systems or devices shown in FIG. 1 may be implemented within a single system or device, or a single system or device is shown in FIG. 1 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. More specifically, it should be noted that the number of the cardholder 104, the entities 106, the issuer server 110, the payment network 112, the database 116, and the data sources 128 described herein are only used for exemplary purposes and do not limit the scope of the invention proposed in the present disclosure.

[0092] FIG. 2 illustrates a simplified block diagram of a server system 200, in accordance with an embodiment of the present disclosure. For example, the server system 200 is similar to the server system 102 as described in FIG. 1. In some embodiments, the server system 200 is embodied as a standalone physical server and / or has a cloud-based and / or SaaS-based (software as a service) architecture.

[0093] The server system 200 includes a computer system 202 and a database 204. The computer system 202 includes at least one processor such as a 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. The database 204 is an example of the database 116 of FIG. 1.

[0094] In some embodiments, the database 204 is integrated into the computer system 202. For example, the computer system 202 may include one or more hard disk drives as the database 204. In one non-limiting example, the database 204 is configured to store a transaction dataset 218, an entity risk insight dataset 220, a platform analytics dataset 222, a first ML model 224 (hereinafter, interchangeably referred to as ‘classification model 224’), and the like. Herein, the first ML model 224 is similar to the first ML model 120 explained in the description of FIG. 1.

[0095] In a non-limiting example, the transaction dataset 218 may include historical information corresponding to a plurality of payment transactions performed by the cardholder 104. In a specific embodiment, the payment transactions are performed using the payment cards associated with the cardholder 104. In an embodiment, 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 Automated Teller Machine (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, beneficiary country, beneficiary Identifier (ID), cardholder ID, cardholder product, cardholder Permanent Account Number (PAN), beneficiary location data or beneficiary co-ordinates, ticket price, etc., among other transaction-related attributes. Further, in some example implementations, the transaction dataset 218 may also include transactional information, such as, but not limited to, account compromise information, merchant fraud monitoring information, high-risk channels information, chargeback risk information, card behavioral pattern information, and the like.

[0096] In other various examples, the transaction dataset 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, open banking-related data, and fraudulent payment transaction data. In a specific embodiment, the transaction dataset may be used for profiling historical transactions by the cardholder 104 as well as the destination account (or payment link) that can be used to flag suspicious-looking transactions.

[0097] In another non-limiting example, the entity risk insight dataset 220 may include information corresponding to one or more insights that may be obtained from relevant information that may be linked to a cardholder ID of the cardholder 104. The one or more insights may be related to one or more entities (e.g., the entities 108) that may have interacted with the cardholder 104 through the one or more communication channels. In an embodiment, the one or more insights may include a risk score, a sentiment score, and the like indicating a likelihood that an entity (e.g., the entity 108(1)) is trying to exhort the cardholder 104 towards some specific agenda, any type of urgency, extortion, etc. It is to be noted that along with the scores, one or more comments, and descriptions indicating the insights about the entities 108 may also be included in the entity risk insight dataset 220. In other words, the entity risk insight dataset 220 can include historical risk insight information corresponding to the one or more entities 108 that interacted with the cardholder 104 during a predefined period. Herein, by way of an example, and not by limitation, the predefined period can be past three months, past one year, past two years, or any period in the past defined by the managing entity of the server system 102. In some embodiments, the entity risk insight dataset 220 may be used for caller profiling which includes collaborating with the telcos to provide caller / sender profiles such as historical call data (number, duration, etc.), and the like.

[0098] In yet another non-limiting example, the platform analytics dataset 222 may include historical behavioral information corresponding to one or more digital platforms facilitating the exchange of information between a plurality of entities such as the entities 108 and a plurality of cardholders. In a specific embodiment, the historical behavioral information includes a set of scores that may be accessed from various data sources such as the data sources 128. In an embodiment, the data sources 128 can be internal to the payment processors and / or the issuers. In another embodiment, the data sources 128 can be external to them. In some embodiments, the data sources 128 can correspond to various products that are part of conventional systems that can provide predictions, scores, etc., related to risk, spending patterns, fraud, etc. Examples of the scores may include the re-issuance score, the high-risk channel, the chargeback risk score, the decision-making score, and the like. It is to be noted that, in some embodiments, these scores may have been generated by the conventional systems, using ML models. Examples of the ML models can include classifiers, an XGBoost model, ensemble models, Neural Networks (NNs), anomaly score learners, etc. In some other embodiments, these scores may have been generated by the conventional systems using a rule-based approach. In a non-limiting example, the platform analytics dataset 222 includes web analytics data related to social media websites, the dark web, and the like. More specifically, the platform analytics dataset 222 obtained from the dark web may include information related to the latest modus operand! of scams / frauds, user cohorts (gender, age group, income group, occupation, etc.) most likely being targeted, regions / countries / financial institutions reporting a spurt in frauds, etc.

[0099] 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 with 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.

[0100] It is to be noted that although the computer system 202 is depicted to include only one processor, the computer system 202 may include a greater number of processors therein. The processor 206 includes a suitable logic, circuitry, and / or interfaces to execute computer-readable instructions for performing one or more operations for detecting anomalous entities. 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 Complex Instruction Set Computing (CISC) processor, a Field-Programmable Gate Array (FPGA), and the like.

[0101] In an embodiment, the memory 208 is capable of storing the computer- readable instructions. 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 cloud storage working in conjunction with the server system 200, without departing from the scope of the present disclosure.

[0102] The processor 206 is operatively coupled to the communication interface 210 such that the computer system 202 is capable of communicating with a remote device 226, such as the electronic device 106, the issuer server 110, the payment server 114, the data sources 128, or with any component connected to the network 118 (as shown in FIG. 1).

[0103] It is to be 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. The processor 206 is depicted to include a data aggregation module 228, a data pre-processing module 230, a training module 232, and a riskiness measurement module 234. It should be noted that components described herein can be configured in a variety of ways, including electronic circuitry, digital arithmetic, logic blocks, and memory systems in combination with software, firmware, and embedded technologies. Moreover, it should also be noted that these components 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.

[0104] In an embodiment, the riskiness measurement module 234 includes suitable logic and / or interfaces for receiving an entity authentication request message including entity identity information corresponding to an entity (e.g., the entity 108(1)) whose identity has to be authenticated for the cardholder 104. In a nonlimiting example, the cardholder 104 has interacted with the entity 108(1). In other words, the entity 108(1) may interact with the cardholder 104. Since the cardholder 104 may have registered for the services of the server system 200, the authenticity of the entity 108(1) may be checked. Thus, the entity authentication request message may be triggered or generated, and received by the riskiness measurement module 234 of the server system 200. Upon receiving the entity authentication request message, the riskiness measurement module 234 may utilize the data aggregation module 228 for aggregating data required for processing the entity authentication request message.

[0105] In an embodiment, the data aggregation module 228 includes suitable logic and / or interfaces for receiving an entity risk insight corresponding to the entity 108(1) from a client server (e.g., the client server 122) based, at least in part, on a cardholder Identifier (ID) of the cardholder 104 and the entity identity information. As may be understood that the client server 122 is configured to generate the entity risk insight, the process of generating the entity risk insight is explained later in the present disclosure with reference to FIG. 3.

[0106] In an embodiment, the data aggregation module 228 is configured to access the entity risk insight dataset 220 from the database 204. As mentioned earlier, the entity risk insight dataset 220 may include historical risk insight information corresponding to one or more entities (e.g., the entities 108) that interacted with the cardholder 104 during the predefined period. The entity risk insight dataset 220 may also include the entity risk insight of the entity 108(1). In other words, the received entity risk insight is stored in the database 204 as a part of the entity risk insight dataset 220. Herein, the entities 108 include the entity 108(1).

[0107] Further, the data aggregation module 228 may be configured to receive the transaction dataset 218, including the historical information corresponding to the plurality of payment transactions performed by a cardholder (e.g., the cardholder 104). The data aggregation module 228 may further receive the platform analytics dataset 222. It is noted that the transaction dataset 218 and the platform analytics dataset 222 may be received from the data sources 128. In an embodiment, the data sources 128 may be operatively coupled with the server system 102. In a specific embodiment, it is to be noted that the transaction dataset 218 is received periodically from transaction monitoring entities, such as the payment server 114, the issuer server 110, and the like based at least on a certain period, such as every day, every two hours, every week, or the like. Similarly, in another specific embodiment, the entity risk insight is received from the client server 122 whenever the entity authentication request message is triggered. Herein, the transaction dataset 218 corresponds to information related to historical payment transactions performed by the cardholder 104, however, the entity risk insight dataset 220 corresponds to real-time information that may be generated at the client server 122 based at least on entity information that is captured in real-time as explained further in the present disclosure. Further, in yet another specific embodiment, the platform analytics dataset 222 is also received periodically from the data sources 128 at a certain period, such as every day, every two hours, every week, or the like.

[0108] In another embodiment, the data aggregation module 228 is configured to store the transaction dataset 218, the entity risk insight as a part of the entity risk insight dataset 220, and the platform analytics dataset 222 in the database 204, which are accessible for future use. Upon gathering the data, it may have to be prepared for training a model such as the classification model 224 utilized for processing the entity authentication request message. The data aggregation module 228 may provide the transaction dataset 218, the entity risk insight, and the platform analytics dataset 222 to the data pre-processing module 230.

[0109] In an embodiment, the data pre-processing module 230 includes suitable logic and / or interfaces for accessing the transaction dataset 218, the entity risk insight dataset 220, and the platform analytics dataset 222 from the database 204. In another embodiment, the data pre-processing module 230 is configured to generate a plurality of features (hereinafter, interchangeably referred to as ‘features’) corresponding to each entity such as the entities 108 based, at least in part, on the transaction dataset 218, the entity risk insight dataset 220, and the platform analytics dataset 222. The plurality of features may include a set of transaction features, a set of risk insight features, and a set of platform features for the transaction dataset 218, the entity risk insight dataset 220, and the platform analytics dataset 222, respectively. These features may be stored in the database 204 and provided to the riskiness measurement module 234 for further processing.

[0110] In an embodiment, the riskiness measurement module 234 is configured to generate a risk score for the entity 108(1) based, at least in part, on the entity risk insight using the classification model 224. Examples of the classification model 224 may include an ensemble model, a boosted tree-based classification model, an XGBoost model, an NN-based model, a Large Language Model (LLM), a generative Al-based model, or the like. For using the classification model 224 to generate the risk score, the classification model 224 may have to be trained. Thus, the features generated upon receiving the entity risk insight are provided to the training module 232. In other words, the features along with the transaction dataset 218, the entity risk insight dataset 220, and the platform analytics dataset 222 may be provided to the training module 232 for training the first ML model 224. Herein, the transaction dataset 218, the entity risk insight dataset 220, and the platform analytics dataset 222 can be collectively referred to as an input dataset. In some embodiments, during the training process, embeddings may be generated from the features to improve the performance of the first ML model 224. The performance of the first ML model 224 is improved as the generation of the embeddings facilitates dimensionality reduction, captures semantic relationships, provides improved generalization, enables transfer learning, reduces overfitting, and the like. In some other embodiments, the embeddings may not be generated.

[0111] In a non-limiting implementation, for training the first ML model 224, a training dataset may be obtained from the input dataset. Basically, the input dataset may be split into the training dataset, a testing dataset, and a validation dataset based on a timeline. For example, the input dataset is captured across a year, then the initial four months' data can be considered for the training dataset, the next four months' data can be considered for the testing dataset, and the last four months' data can be considered for the validation dataset. Thus, the features that are generated from the input dataset may also be split into a training feature set, a testing feature set, and a validation feature set based, at least on the training dataset, the testing dataset, and the validation dataset, respectively. In other words, the training module 232 may access the features from the database 204 and generate the training feature set based on the features. Thereafter, the training module 232 may store the training feature set in the database 204 and use the same for training the first ML model 224. Further, while training, the training module 232 may access the training feature set from the database 204. The training module 232 may initialize the classification model 224 with the training feature set and one or more first model parameters.

[0112] In a specific embodiment, a first set of operations may be performed for each entity of the entities 108, iteratively, for training the first ML model 224 until first convergence criteria are met. The first set of operations may include: (i) generating, by the classification model 224, a first predicted risk score based, at least in part, on the training feature set and the one or more first model parameters, the first predicted risk score indicating a likelihood of the corresponding entity 108 (1) being anomalous; (ii) generating, by the classification model 224, a first prediction including a first predicted label for the corresponding entity based, at least in part, on the first predicted risk score; (iii) computing a first loss using a loss function based, at least on the first predicted label, a true label, and a loss function; and (iv) optimizing the one or more first model parameters based, at least on back-propagation of the first loss. Herein, the first model parameters may be chosen based on the type of the first ML model 224. For example, the first model parameters can include a batch size, epoch, number of layers in a NN, weights, biases, and the like. The first convergence criteria may include either saturation of the loss or reaching a predefined count of iterations.

[0113] After the completion of the training process, the trained classification model, i.e., the classification model 224 is provided to the riskiness measurement module 234 for further processing. In an embodiment, the riskiness measurement module 234 is configured to generate a risk score for the entity 108(1) based, at least in part, on the entity risk insight and the features using the first ML model 224. Furthermore, the riskiness measurement module 234 may be configured to generate a trust rating for the entity 108(1) based, at least in part, on the risk score and a set of thresholds (explained later in the present disclosure). The trust rating indicates a likelihood of the entity 108(1) being an anomalous entity. Finally, in an embodiment, in response to the authentication request message, the riskiness measurement module 234 may transmit an authentication response message (hereinafter, interchangeably referred to as an ‘entity authentication response message’) including the trust rating to the electronic device 106. In another embodiment, the riskiness measurement module 234 may transmit the entity authentication response message to client server 122. The client server 122 may facilitate a display of the trust rating to the cardholder 104.

[0114] In some embodiments, the riskiness measurement module 234 may receive a feedback from the cardholder 104 based, at least in part, on the trust rating associated with the entity 108(1). The riskiness measurement module 234 may optimize the classification model 224 based, at least in part, on the feedback.

[0115] FIG. 3 illustrates a simplified block diagram of a client server 300, in accordance with an embodiment of the present disclosure. It should be noted that the client server 300 is similar to the client server 122 of FIG. 1. In some embodiments, the client server 300 is embodied as a standalone physical server and / or has a cloudbased and / or SaaS-based (software as a service) architecture.

[0116] The client server 300 includes a computer system 302 and a client database 304. The computer system 302 includes at least one processor, such as a processor 306 for executing instructions, a memory module 308, an input / output module 310, a storage module 312, and a communication module 314. It is to be noted that the computer system 302, the processor 306, and the memory module 308 are similar to the computer system 202, the processor 206, and the memory 208 of FIG. 2 and have similar internal components and configurations, hence are not repeated herein for the sake of brevity.

[0117] The one or more components of the computer system 302 communicate with each other via a bus 316. The components of the client server 300 provided herein may not be exhaustive, and the client server 300 may include more or fewer components than those depicted in FIG. 3. Further, two or more components are depicted in FIG. 3 may be embodied in one single component, and / or one component may be configured using multiple sub-components to achieve the desired functionalities. The client database 304 is an example of the client database 124 of FIG. 1. In some embodiments, the client database 304 is integrated into the computer system 302. In a non-limiting example, the client database 304 is configured to store relevant information 318, a second ML model 320 (hereinafter, interchangeably referred to as a ‘text-based classification model 320’), and an entity risk insight dataset 322. In an embodiment, the entity risk insight dataset 322 is similar to the entity risk insight dataset 220 of FIG. 2, as the entity risk insight dataset 322 generated in the client server 300 is transmitted to the server system 200 as explained earlier.

[0118] Further, the processor 306 is depicted to include a data management engine 324 and a risk insight generation engine 326. It should be noted that the processor 306 may include other modules for its operation as well.

[0119] In at least some embodiments, the memory module 308 stores logic and / or instructions, which may be used by modules of the processor 306, such as the data management engine 324 and the risk insight generation engine 326, for managing data received from the cardholder 104 to generate the entity risk insight dataset 322.

[0120] In an embodiment, the I / O module 310 may include mechanisms configured to receive inputs from and provide outputs to an operator(s) of the client server 300. To that effect, the VO module 310 may include at least one input interface and / or at least one output interface. The communication module 314 may include communication circuitry such as, for example, a transceiver circuitry including an antenna and other communication media interfaces to connect to a communication network, such as the network 118 shown in FIG. 1. The communication module 314 may, at least some example embodiments, enable generating the entity authentication request message based, at least in part, on a trigger condition. Herein, the entity authentication request message may be transmitted to a server system (e.g., the server system 200) for authenticating the entity 108(1) that interacts with the cardholder 104. The entity authentication request message may include an entity identity information corresponding to the entity 108(1).

[0121] In an embodiment, the communication module 314 may also enable periodical reception or extraction of the relevant information 318 linked to a cardholder identifier (ID) associated with the cardholder 104 based at least on a set of rules. In another embodiment, the relevant information 318 corresponding to the entity 108(1) may be extracted based, at least in part, on an entity identity information associated with the entity 108(1) and the set of rules. The relevant information 318 may include freshly collected data, such as audio data, video data, textual data, and the like linked to the cardholder ID. In an embodiment, the set of rules includes checking whether the cardholder 104 has permitted the client server 300 to fetch the relevant information 318 from the cardholder ID or not. Further, the storage module 312 is any computer-operated hardware suitable for storing and / or retrieving data. In an embodiment, the storage module 312 includes a repository such as the client database 304 for storing the relevant information 318, any other intermediate data that may be generated, and the like. In some embodiments, the processor 306 and / or other components of the processor 306 may access the storage module 312 using a storage interface (e.g., the storage interface 214 shown in FIG. 2). The communication module 314 may further be configured to enable processing of the relevant information 318 by the engines of the processor 306. Thus, In an embodiment, the data management engine 324 is configured to store the relevant information in the client database 304 upon reception.

[0122] Further, the risk insight generation engine 326 may be configured to generate the entity risk insight corresponding to the entityl08(l) based, at least in part, on the relevant information 318. In an embodiment, the risk insight generation engine 326 may generate the entity risk insight using the text-based classification model 320. Upon generation of the entity risk insight, it may be stored in the client database 304 as a part of the entity risk insight dataset 322.

[0123] More specifically, to generate the entity risk insight dataset 322, the risk insight generation engine 326 may access the relevant information 318 from the client database 304. Further, the risk insight generation engine 326 may generate speech-to-text data based, at least in part, on the audio data and the video data of the relevant information 318. In a non-limiting implementation, the risk insight generation engine 326 may generate the speech-to-text data using another model such as a speech-to-text model. Further, the insight generation engine 326 may further generate a set of token IDs for the entity 108(1) based, at least in part, on the speech- to-text data, the textual data, and a tokenizer vocabulary dataset. The entity risk insight may be generated using the text-based classification model 320 based, at least in part, on the set of token IDs. Examples of the second ML model 320 may include an ensemble model, a transformer-based model, an NN-based model, an LLM, a boosted-tree-based classification model, a convolutional NN (CNN)-based model, a Recurrent NN (RNN)-based model, or the like. Prior to using the second ML model 320, it may have to be trained. Thus, in another embodiment, the risk insight generation engine 326 is configured to train the second ML model 320.

[0124] For training the text-based classification model 320, the risk insight generation engine 326 may access a training token ID set from the client database 304. In an embodiment, for generating the training token ID set, the risk insight generation engine 326 may be configured to access the entity risk insight dataset including the historical risk insight information corresponding to the entities 108 that interacted with the cardholder 104 during the predefined period from the client database 304. Further, the risk insight generation engine 326 may generate the one or more token ID sets for the corresponding one or more entities 108 based, at least in part, on the entity risk insight dataset 322 and the tokenizer vocabulary dataset. Thereafter, the risk insight generation engine 326 may generate the training token ID set based, at least in part, on the one or more token ID sets. Herein, the training token ID set is used for training the text-based classification model 320.

[0125] Thereafter, in an embodiment, the risk insight generation engine 326 may initialize the text-based classification model 320 with the training token ID set and one or more second model parameters. The risk insight generation engine 326 may be configured to perform a second set of operations for each entity of the entities 108, iteratively, until second convergence criteria are met. The second set of operations may include: (i) generating, by the text-based classification model 320, a training embedding set based, at least in part, on the training token ID set; (ii) generating, by the text-based classification model 320, a second predicted risk score based, at least in part, on the training embedding set and the one or more second model parameters, the second predicted risk score indicating a likelihood of the corresponding entity being anomalous; (iii) generating, by the text-based classification model 320, a second prediction including a second predicted label for the corresponding entity based, at least in part, on the second predicted risk score; (iv) computing a second loss based, at least in part, on the second predicted label, a true label, and a loss function; and (v) optimizing the one or more second model parameters based, at least in part, on back-propagation of the second loss. In response to meeting the second convergence criteria, the risk insight generation engine 326 may generate a final prediction indicating the entity risk insight corresponding to the entity 108(1).

[0126] In an embodiment, the data management module 324 may store the entity risk insight corresponding to the entity 108(1) in the client database 304. Further, the data management module 324 may delete the relevant information 318 corresponding to the entity 108(1) from the client database 304 based, at least in part, on the set of rules. Thereafter, the data management module 324 may form the entity risk insight dataset 322, including the historical risk insight information corresponding to the one or more entities 108 that interacted with the cardholder 104 during the predefined period based, at least in part, on the storing step and the deletion step. Herein, the historical risk insight information may include one or more entity risk insights corresponding to the one or more entities 108.

[0127] In a specific embodiment, the second ML model 320 can include various models working together to generate the entity risk insight. By way of an example, and not by limitation, the second ML model 320 includes at least two ML models, such as a speech-to-text model and a Natural Language Processing (NLP) model. More specifically, in general, the relevant information 318 is textual data and to process and understand the textual data, the NLP model may be used. However, in some scenarios, the relevant information 318 can also include audio data, and hence text data may have to be extracted from audio data. In order to do so, the speech-to- text model may be used. In an embodiment, the risk insight generation engine 326 may train each of the speech-to-text model and the NLP model based at least on the relevant information 318. Herein, the training process is well known to a person skilled in the art, and hence not explained herein for the sake of brevity. An example of the speech-to-text model can be an ensemble model of the RNN-based model and the CNN-based model. Further, the NLP model is trained to understand the textual data and generate a risk score indicating one or more insights corresponding to the relevant information 318. In a non-limiting example, the risk score may correspond to a value between 0 and 1. Examples of the NLP model can include an ensemble model of the LLM and the boosted tree-based classification model. Thus, the predictions made by the second ML model 320 for various entities associated with the cardholder 104 are taken as the entity risk insight dataset 322 and stored in the client database 304.

[0128] Further, the communication module 314 may be configured to transmit the entity risk insight corresponding to the entity 108(1) to the server system 200. In an embodiment, the server system 200 is configured to generate the trust rating for the entity 108(1) based, at least in part, on the entity risk insight. The communication module 314 may also facilitate the display of the trust rating to the cardholder 104. In addition, the data management engine 324 may be configured to periodically delete the relevant information 318 from the client database 304 based at least on the set of rules. Herein, deleting the relevant information 318 upon generation of the entity risk insight dataset 322 facilitates maintaining the data privacy of the cardholder 104.

[0129] In a non-limiting example, the client server 300 is linked to the cardholder ID associated with the cardholder 104. In some embodiments, the client server 300 and the server system 200 may be implemented in a federated learning framework. Federate learning is a machine learning approach that allows a model to be trained across multiple decentralized edge devices or servers holding local data samples, without exchanging them. Thus, the second ML model 320 is trained in the client server 300, and insights (i.e., the entity risk insights) generated are shared with the server system 200. At the server system 200, the first ML model 224 is trained based on the insights received from the client server 300. Further, it is to be noted that the federated learning framework can be implemented in a client-server environment or an edge computing environment as well. As a result, the data privacy of the cardholder 104 is maintained.

[0130] In some embodiments, the client server 300 may be implemented using the electronic device 106. For instance, the client server 300 can be embedded into the electronic device 106. In some other embodiments, the client server 300 may be embedded in a cloud server. Similarly, in some embodiments, the server system 200 may also be embedded into the electronic device 106. In some other embodiments, the server system 200 may be embedded in a cloud server. However, data that is locally accessible for the corresponding servers is exchanged between the servers, rather only insights are shared.

[0131] FIG. 4 illustrates a sequence flow diagram 400 for facilitating the detection of anomalous entities from a trust rating, in accordance with an embodiment of the present disclosure. It is to be noted that the steps shown in FIG. 4 may not have to be performed in the order shown, rather the order can be modified as per the requirement, thereby not limiting the scope of the present invention. As may be understood, the components required for the execution of the approach proposed in the present invention may include, but are not limited to, the electronic device 106, the client server 300, the server system 200, the payment server 114, the issuer server 110, and the data sources 128. Thus, the exchange of signals and data between these components is depicted in FIG. 4. The sequence of operations starts from step 402.

[0132] At step 402, the client server 300 may transmit a request to the electronic device 106 to access the relevant information 318. At step 404, upon receiving the request from the client server 300, the cardholder 104 using the electronic device 106 may grant the request and provide access to the relevant information 318.

[0133] At step 406, since the request is granted, the relevant information 318 may then be transmitted to the client server 300. In other words, the client server 300 may receive the relevant information 318 from the electronic device 106.

[0134] At step 408, the client server 300 is configured to generate the entity risk insight.

[0135] At step 410, the client server 300 is configured to transmit the entity risk insight to the server system 200. In other words, the server system 200 is configured to receive the entity risk insight from the client server 300 and store it as the entity risk insight dataset 220 in the database 204.

[0136] At step 412, the server system 200 is configured to receive network data from the payment server 114. In an embodiment, the network data includes data focused on processing and routing the payment transactions. For instance, the network data may include a transaction ID, a timestamp of transaction initiation and completion, amount and currency, a payment method, beneficiary ID and details, authorization details, payment gateway information, fraud and risk-related information, and the like.

[0137] At step 414, the server system 200 is configured to receive transaction data from the issuer server 110. In an embodiment, the transaction data includes data corresponding to cardholder’s transactions and account activities. For instance, the transaction data may include cardholder name, card number (z.e., PAN), account details, transaction ID, amount, transaction date and time, beneficiary details, authorization information, available balance, credit limit, reward points, security and fraud information, and the like. Herein, it is to be noted that the network data and the transaction data can be collectively referred to as the transaction dataset 218, which is explained earlier in the present disclosure.

[0138] At step 416, the server system 200 is configured to receive the platform analytics dataset 222 from the various data sources such as the data sources 128.

[0139] At step 418, the server system 200 is configured to receive the entity authentication request message from the electronic device 106. The entity authentication request message may be triggered and received either upon receiving calls or text messages on the electronic device 106, receiving an email, adding an entity as beneficiary, or the like.

[0140] At step 420, the server system 200 is configured to generate the trust rating upon receiving the entity authentication request message. The process of generating the trust rating is explained earlier in the present disclosure.

[0141] At step 422, the server system 200 is configured to transmit the entity authentication response message to the electronic device 106 upon generation of the trust rating. Herein, the entity authentication response message may include the trust rating. Upon receiving the entity authentication response message, the cardholder 104 may make the decision of whether to proceed with trusting the entity 108(1) or flagging the entity 108(1) to be an anomalous entity or a fraudulent entity.

[0142] FIG. 5 illustrates a flow diagram showing an overall flow 500 of generating the trust rating, in accordance with an embodiment of the present disclosure. The overall flow 500 shows that at a user endpoint 502, an entity risk insight 504 may be generated. Herein, the user endpoint 502 corresponds to the electronic device 106. Thus, for generating the entity risk insight 504, the client server 300 (as explained earlier) may be employed. The client server 300 may be employed either within the electronic device 106 or external to the electronic device 106 on a cloud server.

[0143] Further, the entity risk insight 504 is stored as a part of the entity risk insight dataset 322. The client server 300 may provide a framework for the generation of the entity risk insight 504. Thus, in a specific implementation, an end user voice recording 506 and an end-user email / text 508 from the electronic device 106 may be captured as the relevant information 318. Herein, the end user is an example of the cardholder 104. Snippets of the end user voice recording 506 may be provided to a speech-to-text model 510 for obtaining a voice transcript 512 and provided to an NLP model 514. Technical dependencies that may be required at this stage may include, technical capabilities of the electronic device 106, a network connection to share the relevant information 318 to the network 118 and / or the client server 300, and the like.

[0144] The speech-to-text model 510 and the NLP model 514 form an example ensemble model for the second ML model 320. Along with the voice transcript 512, the user email / text 508 is provided to the NLP model 514. It is to be noted that the NLP model 514 is provided with a classification layer for generating the entity risk insight 504. Further, the entity risk insight 504 may be fetched by the first ML model 224 for generating a trust rating 516. The first ML model 224 may also receive the transaction dataset 218 and the platform analytics dataset 222. The first ML model 224 is associated with the server system 200 and generates the trust rating 516 based on the entity risk insight 504, the transaction dataset 218, and the platform analytics dataset 222.

[0145] Upon generating the trust rating 516, it may be transmitted to the end user such as the cardholder 104. Upon receiving the trust rating 516, the end user may take a decision (see, 518). The user decision 518 may be provided to the first ML model 224 as the feedback for facilitating reinforcement learning (see, 520). Reinforcement learning refers to learning that a model gains from actions performed in the environment based on the prediction made by the model. Thus, it may be understood that the first ML model 224 may update its learning from the feedback received from the end user. In other words, the first ML model 224 may be optimized based on the feedback received from the end user.

[0146] FIG. 6A, FIG. 6B, FIG. 6C, FIG. 6D, and FIG. 6E, collectively, illustrate User Interfaces (UIs) 600, 620, 640, 660, and 680 depicting a process of generating a trust rating for an entity (e.g., the entity 108(1)), in accordance with an embodiment of the present disclosure. In a non-limiting example, a cardholder such as the cardholder 104 has registered to receive the services of the server system 200 which is available in an online payment platform as an add-on extension feature. Upon registration, the cardholder 104 may provide permission to the add-on extension feature to have access to the relevant information 318 on the electronic device 106 or the cardholder ID of the cardholder 104. It is to be noted that the add-on extension feature provides protection to the cardholder 104 from social engineering attacks.

[0147] FIG. 6A depicts UI 600, FIG. 6B depicts UI 620, FIG. 6C depicts UI 640, FIG. 6D depicts UI 660, FIG.6E depicts UI 680 that may appear on the electronic device 106 used by the cardholder 104, at different stages when the services of the add-on extension feature are provided to the cardholder 104.

[0148] As shown in UI 600 of FIG. 6 A, a call from an entity such as the entity 108(1) is received by the cardholder 104 on the electronic device 104. Upon receiving the call, the add-on extension feature may capture snippets of the call recording from the electronic device 106. The snippets have voice recordings of both the cardholder 104 and the entity 108(1). From analyzing the snippets, the intent of the entity 108(1) can be determined. As per the approach proposed in the present disclosure, the snippets are analyzed for determining the intent of the entity 108(1) using the second ML model 320.

[0149] As shown in UI 620 of FIG. 6B, a login page of the online payment platform is used by the cardholder 104 for making payments to beneficiaries. It shows that the cardholder 104 has an account in an ABC bank and logs in to their account by providing a login ID and password on the login page. When the cardholder 104 clicks on the ‘SUBMIT’ button, if the login ID and password entered by the cardholder 104 are correct, then the cardholder 104 is successfully logged in to their account of the ABC bank. Upon successfully logging in, UI 640 appears on the electronic device 104.

[0150] As shown in UI 640 of FIG. 6C, multiple options such as the ‘ADD BENEFICIARY’, ‘ADD ACCOUNT’, ‘REPORT FRAUD’, etc., for the cardholder 104 to choose from can appear once the cardholder 104 has successfully logged in to their account. When the cardholder 104 selects the option to ‘ADD BENEFICIARY’, UI 660 appears on the electronic device 104.

[0151] As shown in UI 660 of FIG. 6D, fields to enter the account details of the beneficiary such as the entity 108(1) may appear. The account details can be an account number, beneficiary name, etc. The cardholder 104 may have received these details from the entity 108(1) through one or more of the communication channels. Further, the cardholder 104 may fill in the account details in the displayed fields and click on the ‘SUBMIT’ button. Upon submitting the account details, UI 680 may appear on the electronic device 104.

[0152] As shown in UI 680 of FIG. 6E a trust rating that may have been generated for the beneficiary (i.e., the entity 108(1)) by the add-on extension feature may appear. Upon viewing the trust rating, the cardholder 104 may select from options ‘YES’ or ‘NO’ to decide whether to proceed with adding the beneficiary and making the payment of not adding the beneficiary. Upon selection of the ‘NO’ option, the cardholder 104 may be redirected to UI 640. Thus, it may be understood that the trust rating that is assigned to the beneficiary acts as an indication for the cardholder 104 about the authenticity of the entity 108(1) requesting the cardholder 104 to make the payment of a certain amount.

[0153] FIG. 7 illustrates a flow diagram depicting a method 700 for detecting anomalous entities from a trust rating, in accordance with an embodiment of the present disclosure. The method 700 depicted in the flow diagram may be executed by, for example, the server system 200. The sequence of operations of the method 700 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 700, and combinations of operations in the method 700 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 700. The process flow starts at operation 702.

[0154] At step 702, the method 700 includes receiving, by a server system (e.g., the server system 200), an authentication request message from an electronic device (e.g., the electronic device 106) associated with a cardholder (e.g., the cardholder 104). The authentication request message may include entity identity information corresponding to an entity (e.g., the entity 108(1)) whose identity is to be authenticated for the cardholder 104.

[0155] At step 704, the method 700 includes accessing, by the server system 200, an entity risk insight dataset (e.g., the entity risk insight dataset 220) and a plurality of features associated with the corresponding entity 108(1) from a database (e.g., the database 204) associated with the server system 200, based at least on the entity identity information.

[0156] At step 706, the method 700 includes generating, by a first Machine Learning (ML) model (e.g., the first ML model 224) associated with the server system 200, a risk score for the entity 108(1) based, at least in part, on the entity risk insight dataset 220 and the plurality of features.

[0157] At step 708, the method 700 includes generating, by the server system 200, a trust rating for the entity 108(1) based, at least in part, on the risk score and a set of thresholds.

[0158] At step 710, the method 700 includes in response to the authentication request message, transmitting, by the server system 200, an authentication response message including the trust rating to the electronic device 106.

[0159] FIG. 8 illustrates a flow diagram depicting a method 800 for generating an entity risk insight via a client server (e.g., the client server 300), in accordance with an embodiment of the present disclosure. The method 800 depicted in the flow diagram may be executed by, for example, the client server 300. The sequence of operations of the method 800 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 800, and combinations of operations in the method 800 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 800. The process flow starts at operation 802.

[0160] At step 802, the method 800 includes generating, by a client server (e.g., the client server 300), an entity authentication request message based, at least in part, on a trigger condition. Herein, the entity authentication request message is transmitted to a server system (e.g., the server system 200) for authenticating an entity (e.g., the entity 108(1)) that interacts with a cardholder (e.g., the cardholder 104). The entity authentication request message includes an entity identity information corresponding to the entity 108(1).

[0161] At step 804, the method 800 includes extracting, by the client server 300, relevant information (e.g., the relevant information 318) corresponding to the entity 108(1) based, at least in part, on the entity identity information and a set of rules. The relevant information includes at least one of audio data, video data, or textual data associated with the trigger condition.

[0162] At step 806, the method 800 includes generating, by a text-based classification model (e.g., the text-based classification model 320) associated with the client server 300, an entity risk insight (e.g., the entity risk insight 504) corresponding to the entity 108(1) based, at least in part, on the relevant information 318.

[0163] At step 808, the method 800 includes transmitting, by the client server 300, the entity risk insight 504 corresponding to the entity 108(1) to the server system 200. Herein, the server system 200 is configured to generate a trust rating (e.g., the trust rating 516) for the entity 108(1) based, at least in part, on the entity risk insight 504.

[0164] At step 810, the method 800 includes facilitating, by the client server 300, a display of the trust rating to the cardholder 104. FIG. 9 illustrates a flow diagram depicting a method 900 for detecting anomalous entities from a trust rating, in accordance with another embodiment of the present disclosure. The method 900 depicted in the flow diagram may be executed by, for example, the server system 200. The sequence of operations of the method 900 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 900, and combinations of operations in the method 900 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 900. The process flow starts at operation 902.

[0165] At step 902, the method 900 includes receiving, by a server system (e.g., the server system 200), an entity authentication request message including entity identity information corresponding to an entity (e.g., the entity 108(1)) whose identity has to be authenticated. Herein, the entity 108(1) interacts with a cardholder (e.g., the cardholder 104).

[0166] At 904, the method 900 includes receiving, by the server system 200, an entity risk insight (e.g., entity risk insight 504) corresponding to the entity 108(1) from a client server (e.g., the client server 300) based, at least in part, on a cardholder Identifier (ID) of the cardholder 104 and the entity identity information.

[0167] At 906, the method 900 includes generating, by a classification model (e.g., the classification model 224) associated with the server system 200, a risk score for the entity 108(1) based, at least in part, on the entity risk insight 504.

[0168] At 908, the method 900 includes generating, by the server system 200, a trust rating for the entity 108(1) based, at least in part, on the risk score and a set of thresholds.

[0169] At 910, the method 900 includes transmitting, by the server system 200, an entity authentication response message including the trust rating (e.g., the trust rating 516) to the client server 300. Herein, the client server 300 facilitates a display of the trust rating to the cardholder 104.

[0170] FIG. 10 illustrates a simplified block diagram of a payment server 1000, in accordance with an embodiment of the present disclosure. The payment server 1000 is an example of the payment server 114 of FIG. 1. The payment server 1000 and the server system 200 may use the payment network 112 as a payment interchange network.

[0171] The payment server 1000 includes a processing module 1002 configured to extract programming instructions from a memory 1004 to provide various features of the present disclosure. The components of the payment server 1000 provided herein may not be exhaustive, and the payment server 1000 may include more or fewer components than that depicted in FIG. 10. 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 1000 may be configured using hardware elements, software elements, firmware elements, and / or a combination thereof.

[0172] Via a communication module 1006, the processing module 1002 receives a request from a remote device 1008, such as the issuer server 110, the electronic device 106, or the server system 102. The request may be a request for conducting the payment transaction. Communication may be achieved through API calls, without loss of generality. The payment server 1000 includes a database 1010. The database 1010 also includes transaction processing data such as issuer ID, country code, acquirer ID, and merchant identifier (MID), among others.

[0173] When the payment server 1000 receives a payment transaction request from the acquirer servers or a payment terminal (e.g., loT device), the payment server 1000 may route the payment transaction request to the issuer server 110. The database 1010 stores transaction identifiers for identifying transaction details such as transaction amount, loT device details, acquirer account information, transaction records, merchant account information, and the like.

[0174] In one example embodiment, the acquirer server is configured to send an authorization request message to the payment server 1000. The authorization request message includes, but is not limited to, the payment transaction request.

[0175] The processing module 1002 further sends the payment transaction request to the issuer server 110 for facilitating the payment transactions from the remote device 1008. The processing module 1002 is further configured to notify the remote device 1008 of the transaction status in the form of an authorization response message via the communication module 1006. The authorization response message includes, but is not limited to, a payment transaction response received from the issuer server 110. Alternatively, In an embodiment, the processing module 1002 is configured to send an authorization response message for declining the payment transaction request, via the communication module 1006, to the acquirer servers associated with merchants to whom the cardholder 104 may be transacting. In an embodiment, the processing module 1002 executes similar operations performed by the server system 200, however, for the sake of brevity, these operations are not explained herein.

[0176] The disclosed methods with reference to FIGS. 7, 8, and 9, or one or more operations of the server system 200 and / or client server 300 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 (c.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.

[0177] Although the disclosure 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 disclosure. 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).

[0178] 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 disclosure 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), 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.

[0179] Various embodiments of the disclosure, 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 disclosure 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 disclosure.

[0180] Although various exemplary embodiments of the disclosure 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

CLAIMSWhat is claimed is:

1. A computer-implemented method, comprising: receiving, by a server system, an entity authentication request message comprising entity identity information corresponding to an entity whose identity has to be authenticated, wherein the entity interacts with a cardholder; receiving, by the server system, an entity risk insight corresponding to the entity from a client server based, at least in part, on a cardholder Identifier (ID) of the cardholder and the entity identity information; generating, by a classification model associated with the server system, a risk score for the entity based, at least in part, on the entity risk insight; generating, by the server system, a trust rating for the entity based, at least in part, on the risk score and a set of thresholds; and transmitting, by the server system, an entity authentication response message comprising the trust rating to the client server, wherein the client server facilitates a display of the trust rating to the cardholder.

2. The computer-implemented method as claimed in claim 1, further comprising: accessing, by the server system, an entity risk insight dataset comprising historical risk insight information corresponding to one or more entities that interacted with the cardholder during a predefined period and the entity risk insight of the entity from a database associated with the server system, wherein the one or more entities comprise the entity; receiving, by the server system, from one or more data sources operatively coupled with the server system based, at least in part, on the cardholder ID: a transaction dataset comprising historical information corresponding to a plurality of payment transactions performed by the cardholder; and a platform analytics dataset corresponding to one or more digital platforms facilitating exchange of information between a plurality of entities and a plurality of cardholders; generating, by the server system, a plurality of features comprising a set for risk insight features, a set of transaction features, and a set of platform features based, at least in part, on the entity risk insight dataset, the transaction dataset,and the platform analytics dataset; and storing, by the server system, the plurality of features in the database.

3. The computer-implemented method as claimed in claim 1, wherein generating the risk score comprises: accessing, by the server system, a plurality of features from the database; generating, by the server system, a training feature set based, at least in part, on the plurality of features, wherein the training feature set is used for training the classification model; and computing, by the classification model, the risk score for the entity based, at least in part, on the entity identity information.

4. The computer-implemented method as claimed in claim 3, wherein training the classification model comprises: accessing, by the server system, the training feature set from the database; initializing, by the server system, the classification model with the training feature set and one or more first model parameters; and performing iteratively, by the server system, for each entity of the one or more entities, until first convergence criteria are met, a first set of operations comprising: generating, by the classification model, a first predicted risk score based, at least in part, on the training feature set and the one or more first model parameters, the first predicted risk score indicating a likelihood of the corresponding entity being anomalous; generating, by the classification model, a first prediction comprising a first predicted label for the corresponding entity based, at least in part, on the first predicted risk score; computing a first loss based, at least in part, on the first predicted label, a true label, and a loss function; and optimizing the one or more first model parameters based, at least in part, on back-propagation of the first loss.

5. The computer-implemented method as claimed in claim 1, wherein the entity authentication request message is generated in response to a trigger condition, wherein the trigger condition comprises at least one of: one or more entities interactwith the cardholder via one or more communication channels, or the cardholder performs an input operation on a platform associated with the server system.

6. The computer-implemented method as claimed in claim 1, further comprising: receiving, by the server system, a feedback from the cardholder based, at least in part, on the trust rating associated with the entity; and optimizing, by the server system, the classification model based, at least in part, on the feedback.

7. The computer-implemented method as claimed in claim 1, wherein the server system is a payment server associated with a payment network.

8. The computer-implemented method as claimed in claim 1, wherein the client server is implemented in an electronic device of the cardholder.

9. A computer-implemented method, comprising: generating, by a client server, an entity authentication request message based, at least in part, on a trigger condition, wherein the entity authentication request message is transmitted to a server system for authenticating an entity that interacts with a cardholder, and wherein the entity authentication request message comprises an entity identity information corresponding to the entity; extracting, by the client server, relevant information corresponding to the entity based, at least in part, on the entity identity information and a set of rules, the relevant information comprising at least one of audio data, video data, or textual data associated with the trigger condition; generating, by a text-based classification model associated with the client server, an entity risk insight corresponding to the entity based, at least in part, on the relevant information; and transmitting, by the client server, the entity risk insight corresponding to the entity to the server system, wherein the server system is configured to generate a trust rating for the entity based, at least in part, on the entity risk insight; and facilitating, by the client server, a display of the trust rating to the cardholder.

10. The computer-implemented method as claimed in claim 9, wherein generating the entity risk insight comprises: accessing, by the client server, the relevant information corresponding to the entityfrom a client database associated with the client server; generating, by a speech-to-text model associated with the client server, speech-to- text data based, at least in part, on the audio data and the video data of the relevant information; and generating, by the client server, a set of token IDs for the entity based, at least in part, on the speech-to-text data, the textual data, and a tokenizer vocabulary dataset, wherein the entity risk insight is generated using the text-based classification model based, at least in part, on the set of token IDs.

11. The computer-implemented method as claimed in claim 9, further comprising: accessing, by the client server, an entity risk insight dataset comprising historical risk insight information corresponding to one or more entities that interacted with the cardholder during a predefined period from a client database associated with the client server; generating, by the client server, one or more token ID sets for the corresponding one or more entities based, at least in part, on the entity risk insight dataset and the tokenizer vocabulary dataset; and generating, by the client server, a training token ID set based, at least in part, on the one or more token ID sets, wherein the training token ID set is used for training the text-based classification model.

12. The computer-implemented method as claimed in claim 11, wherein training the text-based classification model comprises: accessing, by the client server, the training token ID set from the client database; initializing, by the client server, the text-based classification model with the training token ID set and one or more second model parameters; performing iteratively, by the client server, for each entity of the one or more entities, until second convergence criteria are met, a set of operations comprising: generating, by the text-based classification model, a training embedding set based, at least in part, on the training token ID set; generating, by the text-based classification model, a second predicted risk score based, at least in part, on the training embedding set and the one or more second model parameters, the second predicted risk score indicatinga likelihood of the corresponding entity being anomalous; generating, by the text-based classification model, a second prediction comprising a second predicted label for the corresponding entity based, at least in part, on the second predicted risk score; computing a second loss based, at least in part, on the second predicted label, a true label, and a loss function; and optimizing the one or more second model parameters based, at least in part, on back-propagation of the second loss; and in response to meeting the second convergence criteria, generating, by the client server, a final prediction indicating the entity risk insight corresponding to the entity.

13. The computer-implemented method as claimed in claim 9, further comprising: storing, by the client server, the entity risk insight corresponding to the entity in a client database associated with the client server; deleting, by the client server, the relevant information corresponding to the entity from the client database based, at least in part, on the set of rules; and forming, by the client server, an entity risk insight dataset comprising historical risk insight information corresponding to one or more entities that interacted with the cardholder during a predefined period based, at least in part, on the storing step and the deletion step, the historical risk insight information comprising one or more entity risk insights corresponding to the one or more entities.

14. 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: receive an entity authentication request message comprising entity identity information corresponding to an entity whose identity has to be authenticated, wherein the entity interacts with the cardholder; receive an entity risk insight corresponding to the entity from a client server based, at least in part, on a cardholder Identifier (ID) of the cardholder andthe entity identity information; generate, by a classification model associated with the server system, a risk score for the entity based, at least in part, on the entity risk insight; generate a trust rating for the entity based, at least in part, on the risk score and a set of thresholds; and transmit an entity authentication response message comprising the trust rating to the client server, wherein the client server facilitates a display of the trust rating to the cardholder.

15. The server system as claimed in claim 14, wherein the server system is further caused at least to: access an entity risk insight dataset comprising historical risk insight information corresponding to one or more entities that interacted with the cardholder during a predefined period and the entity risk insight of the entity from a database associated with the server system, wherein the one or more entities comprise the entity; receive from one or more data sources operatively coupled with the server system based, at least in part, on the cardholder ID: a transaction dataset comprising historical information corresponding to a plurality of payment transactions performed by the cardholder; and a platform analytics dataset corresponding to one or more digital platforms facilitating exchange of information between a plurality of entities and a plurality of cardholders; generate a plurality of features comprising a set for risk insight features, a set of transaction features, and a set of platform features based, at least in part, on the entity risk insight dataset, the transaction dataset, and the platform analytics dataset; and store the plurality of features in the database.

16. The server system as claimed in claim 14, wherein to generate the risk score for the entity, the server system is further caused at least to: access the plurality of features from the database; generate a training feature set based, at least in part, on the plurality of features, wherein the training feature set is used for training the classification model; andcompute the risk score for the entity using the classification model based, at least in part, on the entity identity information.

17. The server system as claimed in claim 16, wherein to train the classification model, the server system is further caused at least to: access the training feature set from the database; initialize the classification model with the training feature set and one or more first model parameters; and perform iteratively for each entity of the one or more entities, until convergence criteria are met, a set of operations comprising: generating, by the classification model, a predicted risk score based, at least in part, on the training feature set and the one or more first model parameters, the predicted risk score indicating a likelihood of the corresponding entity being anomalous; generating, by the classification model, a prediction comprising a predicted label for the corresponding entity based, at least in part, on the predicted risk score; computing a loss based, at least in part, on the predicted label, a true label, and a loss function; and optimising the one or more first model parameters based, at least in part, on back-propagation of the loss.

18. The server system as claimed in claim 14, wherein the entity authentication request message is generated in response to a trigger condition, wherein the trigger condition comprises at least one of: one or more entities interact with the cardholder via one or more communication channels, or the cardholder performs an input operation on a platform associated with the server system.

19. The server system as claimed in claim 14, wherein the server system is further caused at least to: receive a feedback from the cardholder based, at least in part, on the trust rating associated with the entity; and optimize the classification model based, at least in part, on the feedback.

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: receiving an entity authentication request message comprising entity identity information corresponding to an entity whose identity has to be authenticated, wherein the entity interacts with the cardholder; receiving an entity risk insight corresponding to the entity from a client server based, at least in part, on a cardholder Identifier (ID) of the cardholder and the entity identity information; generating, by a classification model associated with the server system, a risk score for the entity based, at least in part, on the entity risk insight; generating a trust rating for the entity based, at least in part, on the risk score and a set of thresholds; and transmitting an entity authentication response message comprising the trust rating to the client server, wherein the client server facilitates a display of the trust rating to the cardholder.

Images