Description:FORM 2
THE PATENTS ACT 1970
(39 of 1970)
&
The Patent Rules 2003
COMPLETE SPECIFICATION
(refer section 10 & rule 13)

1. TITLE OF THE INVENTION:
ARTIFICIAL INTELLIGENCE BASED METHODS AND SYSTEMS FOR FRAUD DETECTION IN FINANCIAL TRANSACTIONS FOR IoT DEVICES

2. APPLICANT(S):

(a) Name:

(b) Nationality:

(c) Address:

MASTERCARD INTERNATIONAL INCORPORATED

United States of America

2000 Purchase Street, Purchase, NY 10577, United States of America

3. PREAMBLE TO THE DESCRIPTION

The following specification particularly describes the invention and the manner in which it is to be performed.

4. DESCRIPTION
(See next page)

 
ARTIFICIAL INTELLIGENCE BASED METHODS AND SYSTEMS FOR FRAUD DETECTION IN FINANCIAL TRANSACTIONS FOR IoT DEVICES

TECHNICAL FIELD
[0001] The present disclosure relates to artificial intelligence processing systems and, more particularly to, electronic methods and complex processing systems for detecting fraudulent payment transactions performed via the Internet of Things (IoT) devices.

BACKGROUND
[0002] Over the last few years, there has been a rapid increase in the usage of IoT devices. The term "IoT" stands for Internet of Things and in general, describes a network of physical objects or devices embedded with software, sensors, and/or other technologies for connecting and exchanging data with other devices or systems over the internet. For example, IoT technology may enable household appliances including, kitchen appliances, thermostats, baby monitors, etc., to connect to the internet. In general, each IoT device is identified with a unique identifier (UID) and can transmit data over a network without any human-to-human or human-to-computer interaction.
[0003] In one example scenario, IoT technology enables retailers across the globe to connect with businesses and people using smart devices or appliances. In an example, IoT technology can be used in an appliance, such as a smart refrigerator for monitoring the items stored inside the refrigerator. In case the stock of any item stored inside the refrigerator is about to finish, the smart refrigerator can automatically re-order that item. In another example, an IoT-enabled device (e.g., a smart cash register) is used to either purchase a product or pay bills. For example, customers can walk up to the smart cash register and say a phrase (for example, “I’ll pay with IoT device”) to purchase a product at a store. The smart cash register then connects with a camera via the internet to capture a real-time image of the customer and asks for the payment method in a designated application. Further, the smart cash register utilizes communication technology (e.g., Bluetooth, Wi-Fi, etc.) to connect to the store’s cash register to validate the payment transaction. In yet another example, an IoT-enabled device (e.g., smart speaker) may be used to perform a payment transaction for a product or a service that may be required by the customer.
[0004] In this regard, IoT-enabled devices can use e-commerce platforms to place an order, i.e., perform a payment transaction for a purchase. Since the payment transactions are performed using IoT technology, such payment transactions might be performed with minimal human intervention. However, such scenarios pose a risk to the security of the payment transactions performed with the usage of IoT technology. In case the IoT devices are not secure, there is a high risk that the personal information related to the customers can be leaked.
[0005] To deal with the above-stated limitations, technologies such as artificial intelligence, machine learning, or neural networks can be used for training a model to detect fraudulent transactions performed via IoT devices. However, such models need to be trained with a vast amount of training data and in practical application, the huge amount of transaction data associated with IoT devices is not readily available. Additionally, not all devices have high loads in terms of transactional data. For example, the volume of payment transactions performed via a smart television may be very insignificant as compared to the volume of payment transactions performed via a smartphone. Since the distribution of payment transactions in different devices is not uniform, therefore, the devices with more transaction volume may overshadow the fraudulent patterns in devices with low transaction volume.
[0006] Thus, there exists a need for a technical solution to overcome the above-stated disadvantages.

SUMMARY
[0007] Various embodiments of the present disclosure provide methods and systems for detecting fraudulent payment transactions performed via the Internet of things (IoT) devices.
[0008] In an embodiment, a computer-implemented method is disclosed. The method performed by a server system includes accessing a training data including source data samples associated with a source domain and target data samples associated with a target domain. The source data samples include historical payment transactions performed within a set of first payment environments. The target data samples include previous payment transactions performed within a second payment environment. The method includes training a plurality of deep neural networks (DNNs) by running a plurality of training epochs. Each training epoch includes a plurality of operations. The plurality of operations includes generating source feature representations corresponding to the source domain and target feature representations corresponding to the target domain based, at least in part, on a shared neural network encoder and the training data. The plurality of operations further includes training a fraud classifier and a domain classifier concurrently based, at least in part, on the source feature representations and the target feature representations as inputs. The fraud classifier is trained to classify fraudulent patterns associated with the source domain and the target domain. The domain classifier is trained to not distinguish the source domain and the target domain. Furthermore, the plurality of operations includes updating a set of neural network weights associated with the plurality of DNNs based, at least in part, on a fraud classification loss (L1) and a domain classification loss (L2). Moreover, the method includes storing the set of neural network weights associated with the plurality of DNNs in a database.
[0009] Other aspects and example embodiments are provided in the drawings and the detailed description that follows.

BRIEF DESCRIPTION OF THE FIGURES
[0010] 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:
[0011] FIG. 1 illustrates an exemplary representation of an environment related to at least some embodiments of the present disclosure;
[0012] FIG. 2 is a simplified block diagram of a server system, in accordance with an embodiment of the present disclosure;
[0013] FIG. 3 is a schematic arrangement of a plurality of deep neural networks trained based on a domain adversarial adaptation model, in accordance with an embodiment of the present disclosure;
[0014] FIG. 4 is a schematic arrangement of the plurality of deep neural networks trained based on the domain adversarial adaptation model, in accordance with another embodiment of the present disclosure;
[0015] FIG. 5 illustrates a process flow for training a plurality of deep neural networks for predicting fraudulent financial transactions performed via an IoT device, in accordance with an embodiment of the present disclosure;
[0016] FIG. 6 illustrates a process flow for fraud detection in financial transactions for IoT devices, in accordance with an embodiment of the present disclosure;
[0017] FIG. 7 is a process flow chart of a computer-implemented method for training a plurality of deep neural networks for predicting fraudulent financial transactions performed via an IoT device, in accordance with an embodiment of the present disclosure;
[0018] FIG. 8 is a simplified block diagram of an issuer server, in accordance with an embodiment of the present disclosure; and
[0019] FIG. 9 is a simplified block diagram of a payment server, in accordance with an embodiment of the present disclosure.
[0020] The drawings referred to in this description are not to be understood as being drawn to scale except if specifically noted, and such drawings are only exemplary in nature.

DETAILED DESCRIPTION
[0021] In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present disclosure. It will be apparent, however, to one skilled in the art that the present disclosure can be practiced without these specific details.
[0022] 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 is not necessarily all referring to the same embodiment, nor are separate or alternative embodiments mutually exclusive of other embodiments. Moreover, various features are described which may be exhibited by some embodiments and not by others. Similarly, various requirements are described which may be requirements for some embodiments but not for other embodiments.
[0023] 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.
[0024] Embodiments of the present disclosure may be embodied as an apparatus, system, method, or computer program product. Accordingly, embodiments of the present disclosure may take the form of an entirely hardware embodiment, an entirely 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.
[0025] The term "payment account" used throughout the description refers to a financial account that is used to fund a financial transaction. Examples of the financial account include, but are not limited to a savings account, a credit account, a checking account, and a virtual payment account. The financial account may be associated with an entity such as an individual person, a family, a commercial entity, a company, a corporation, a governmental entity, a non-profit organization, and the like. In some scenarios, the financial account may be a virtual or temporary payment account that can be mapped or linked to a primary financial account, such as those accounts managed by payment wallet service providers, and the like.
[0026] The term "payment card", used throughout the description, refers to a physical or virtual card linked with a financial or payment account that may be presented to a merchant or any such facility to fund a financial transaction via the associated payment account. Examples of the payment card include, but are not limited to, debit cards, credit cards, prepaid cards, virtual payment numbers, virtual card numbers, forex cards, charge cards, e-wallet cards, and stored-value cards. A payment card may be a physical card that may be presented to the merchant for funding the payment. Alternatively, or additionally, the payment card may be embodied in form of data stored in a user device, where the data is associated with a payment account such that the data can be used to process the financial transaction between the payment account and a merchant's financial account.
[0027] The term "payment network", used herein, refers to a network or collection of systems used for the transfer of funds through the use of cash substitutes. Payment networks may use a variety of different protocols and procedures to process the transfer of money for various types of transactions. Transactions that may be performed via a payment network may include product or service purchases, credit purchases, debit transactions, fund transfers, account withdrawals, etc. Payment networks may be configured to perform transactions via cash substitutes, which may include payment cards, letters of credit, checks, financial accounts, etc. Examples of networks or systems configured to perform as payment networks include those operated by such as, Mastercard®.
[0028] The term "merchant", used throughout the description generally refers to a seller, a retailer, a purchase location, an organization, or any other entity that is in the business of selling goods or providing services, and it can refer to either a single business location or a chain of business locations of the same entity.
[0029] The terms "account holder", "user", “cardholder”, and "customer" are used interchangeably throughout the description and refer to a person who has a payment account or a payment card (e.g., credit card, debit card, etc.) associated with the payment account, that will be used by a merchant to perform a payment transaction. The payment account may be opened via an issuing bank or an issuer server.
[0030] The terms "payment transaction", or "financial transaction" are used interchangeably throughout the description and may refer to electronic financial transactions including, for example, online payment, payment at a terminal (e.g., point of sale (POS) terminal), and the like. Generally, a payment transaction is performed between two entities, such as a buyer and a seller. It is to be noted that a payment transaction is followed by a payment transfer of a transaction amount (i.e., monetary value) from one entity (e.g., issuing bank associated with the buyer) to another entity (e.g., acquiring bank associated with the seller), in exchange of any goods or services.
[0031] The term "deep neural network (DNN)", used throughout the description, refers to an artificial neural network (ANN) that consists of various hidden layers between an input layer and an output layer. In general, DNN consists of various components including, for example, neurons, synapses, weights, biases, functions, and the like.
[0032] The term "Internet of Things (IoT)", used throughout the description, refers to a network of physical objects or devices connected to the internet and capable of collecting and sharing data with each other. Such physical objects (i.e., IoT devices), may be embedded with sensors, software, and/or other technologies for the purpose of connecting and exchanging data with other devices and/or systems over the internet. For example, the IoT devices may include computing devices, mechanical and digital machines, or any object provided with unique identifiers (UIDs) and the ability to transfer data over a network without requiring human-to-human or human-to-object interaction. Examples of IoT devices may range from simple household objects to sophisticated industrial tools.
[0033] In an example, an IoT device may be connected within an IoT ecosystem. The IoT ecosystem may include web-enabled smart devices that use embedded systems, such as processors, sensors, and/or communication hardware, to collect, send and act on data they acquire from their environments. The IoT device may collect sensor data by connecting to an IoT gateway or other edge device. The IoT device may then send the collected data to a cloud server for analysis or may even analyze the data locally. In certain cases, the IoT device may communicate with other related devices and act on the information they get from one another. The IoT device may do most of the work without human intervention, although people may interact with the IoT device, for example, for setting up the device, provide instructions to the device, or access data from the device.
OVERVIEW
[0034] Various embodiments of the present disclosure provide methods and systems for detecting fraudulent payment transactions performed via the Internet of Things (IoT) devices. More specifically, the present disclosure provides methods and systems for training deep neural networks (DNN) for detecting fraudulent payment transactions performed via IoT devices.
[0035] As stated above, with increased automation of processes and tasks, various technologies are developed to provide opportunities for monitoring, tracking, or controlling devices and/or items. In some implementations, various smart devices (e.g., IoT devices) are configured to perform payment transactions to enhance the shopping experience for customers. For example, a customer (e.g., cardholder) is allowed to pay bills and/or place orders for required products and/or services via an IoT device. In another example, an IoT device (e.g., a refrigerator) may monitor a set of items stored inside, to detect required items that are about to go out of stock, and then automatically place a purchase order for the required items. In yet another example, an IoT device (e.g., a smart speaker) may use its memory to store payment card information associated with a cardholder, and then use the payment card information to place a purchase order for an item represented on an e-commerce website. In this manner, smart devices, i.e., IoT devices, can perform payment transactions to automatically place purchase orders for purchasing goods or services from a merchant.
[0036] However, an increase in usage of such smart devices (i.e., IoT devices) may pose a risk to security while performing payment transactions. This is because the payment transactions performed via IoT devices may be performed automatically or without any human intervention; thus, increasing the risk of fraud at a device level. In addition, different IoT devices may be prone to a different level of risk. Further, IoT devices may be prone to security threats and attacks due to various reasons including, for example, lack of physical hardening, insecure data storage and transfer, insecure IoT ecosystem interfaces, weak passcodes, lack of device management, artificial intelligence (AI) based attacks, and the like.
[0037] To add to these limitations, the distribution of payment transactions performed via different IoT devices is also not uniform. For example, the volume of payment transactions performed via a smart television may be very insignificant as compared to the volume of payment transactions performed via a mobile phone; therefore, IoT devices with high transaction volumes may overshadow the fraudulent patterns in IoT devices with low transaction volume. In one example, a payment transaction of $1500 performed via a mobile phone might be common for a cardholder, whereas the same payment transaction of $1500 performed via a smart television configured with payment card information of the cardholder might be an alert that needs to be captured.
[0038] Thus, at least one of the technical problems addressed by the present disclosure includes (a) training of a deep neural network (DNN) model using transfer learning to detect fraudulent payment transactions performed via IoT devices, (b) training the DNN model with already available transaction data of other payment environments (e.g., credit card transaction data), (c) faster and accurate training of the DNN model, and (d) performing fraud detection for various IoT devices at a device level.
[0039] The present disclosure utilizes transfer learning strategies in the adaptation of fraud detection models for existing payment environments to new payment environments or domains. In particular, the present disclosure describes the heterogeneous nature of payment transaction means, related to a set of payment transaction environments (e.g., card-present, card-not-present, etc.) where cardholders are involved actively during payment transactions versus a payment transaction environment where IoT devices associated with the cardholders initiate the payment transactions. It is to be noted that there are already fully-developed fraud detection models for the set of payment transaction environments compared to the IoT device-initiated payment transaction related environment and at the same time, the fraud detection process is similar for all the payment transaction environments. Therefore, modeling and design effort done in setting up the fully-developed fraud detection models of the set of payment transaction environments (e.g., source domain) can be reused and transferred to fraudulent transaction detection at the IoT device level.
[0040] To overcome such technical problems or limitations, the present disclosure describes a server system for training a plurality of deep neural networks according to domain adversarial adaptation manner. More specifically, the server system is configured to train the plurality of deep neural networks using single-shot transfer learning based on domain feedback. In one embodiment, the server system includes a processor and a memory. In one non-limiting example, the server system is a payment server associated with a payment network.
[0041] The server system is configured to access training data from a database. The training data includes source data samples associated with a source domain and target data samples associated with a target domain. In an example, the target domain is different and independent from the source domain. The source data samples include historical payment transactions performed within a set of first payment environments. In addition, the target data samples include previous payment transactions performed within a second payment environment. It is to be noted that the second payment environment does not belong to the set of first payment environments. The second payment environment corresponds to payment transactions performed via an Internet of Things (IoT) device.
[0042] The server system is then configured to train a plurality of deep neural networks (DNNs) by running a plurality of training epochs. In addition, each training epoch includes a plurality of operations. The plurality of deep neural networks (DNNs) is trained based, at least in part, on a single-shot transfer learning method. The term “single-shot transfer learning” herein refers to the training of the plurality of DNNs concurrently with the source data samples and the target data samples. The plurality of DNNs includes the shared neural network encoder, the target private neural network, the fraud classifier, and the domain classifier.
[0043] The plurality of operations includes generating source feature representations corresponding to the source domain and target feature representations corresponding to the target domain based, at least in part, on the shared neural network encoder and the training data and modifying the target feature representations corresponding to the target domain based, at least in part, on an output of the target private neural network that is associated with a device profile of the IoT device. To modify the target feature representations, the server system is configured to concatenate the target feature representations with device-specific risk features and IoT-specific features associated with the IoT device.
[0044] Further, the plurality of operations includes training the fraud classifier and the domain classifier concurrently based, at least in part, on the source feature representations and the target feature representations as inputs and updating a set of neural network weights associated with the plurality of DNNs based, at least in part, on a fraud classification loss and a domain classification loss. The fraud classifier is trained to classify fraudulent patterns associated with the source domain and the target domain while the domain classifier is trained to not distinguish the source domain and the target domain. The server system is configured to store the set of neural network weights associated with the plurality of DNNs in the database.
[0045] The set of neural network weights includes at least one of: a first set of weights (W0) associated with the shared neural network encoder, a second set of weights (W1) associated with the fraud classifier, a third set of weights (W2) associated with the domain classifier, and a fourth set of weights (W3) associated with the target private neural network. The server system is configured to calculate a first gradient descent value associated with the fraud classifier based, at least in part, on the fraud classification loss and the second set of weights associated with the fraud classifier. In addition, the server system is configured to back propagate the first gradient descent value to the fraud classifier to update the second set of weights.
[0046] The server system is configured to calculate a second gradient descent value associated with the fraud classifier based, at least in part, on the fraud classification loss and the fourth set of weights associated with the target private neural network. The server system is then configured to back propagate the second gradient descent value to the target private neural network to update the fourth set of weights. The server system is also configured to calculate a third gradient descent value associated with the domain classifier based, at least in part, on the domain classification loss and the third set of weights associated with the domain classifier. The server system is then configured to back propagate the third gradient descent value to the domain classifier to update the third set of weights.
[0047] Moreover, the server system is configured to calculate a fourth gradient descent value associated with the domain classifier based, at least in part, on the domain classification loss and the first set of weights associated with the shared neural network encoder. The server system is then configured to back propagate a negative value of the fourth gradient descent value to the shared neural network encoder to update the first set of weights. The server system is also configured to calculate a fifth gradient descent value associated with the domain classifier based, at least in part, on the domain classification loss and the fourth set of weights associated with the target private neural network. The server system is then configured to back propagate a negative value of the fifth gradient descent value to the target private neural network to update the fourth set of weights. In some embodiments, the server system is configured to determine a risk score corresponding to the IoT device of the plurality of IoT devices based, at least in part, on the target data samples.
[0048] Various embodiments of the present disclosure offer multiple advantages and technical effects. For instance, the present disclosure discloses training of a plurality of deep neural networks (DNNs) concurrently based on source domain data samples and target domain data samples using a single shot transfer learning method. The single-shot transfer learning method also attempts to train a fraud classifier and a domain classifier for a target domain by leveraging large amounts of data available in the source domain. The domain classifier enables the plurality of DNNs to learn domain invariant features. In addition, a target private neural network is configured to incorporate device-specific risk features associated with an IoT device into target feature representations. Owing to the single-shot transfer learning method, the training is faster, more accurate, and needs less training data.
[0049] Various example embodiments of the present disclosure are described hereinafter with reference to FIGS. 1 to 9.
[0050] FIG. 1 illustrates an exemplary representation of an environment 100 related to at least some embodiments of the present disclosure. Although the environment 100 is presented in one arrangement, other embodiments may include the parts of the environment 100 (or other parts) arranged otherwise depending on, for example, training various deep neural networks (DNNs) for detecting fraudulent payment transactions performed via IoT devices. The environment 100 generally includes a plurality of entities, such as a server system 102, a plurality of users 104a, 104b, and 104c, a payment card 106 associated with the user 104a, a user device 108 associated with the user 104b, a plurality of IoT devices 110a, 110b, and 110c associated with the user 104c, a payment network 112 including a payment server 114, an IoT backend server 116, an issuer server 124, an acquirer server 126, each coupled to, and in communication with (and/or with access to) a network 130.
[0051] The network 130 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 the entities illustrated in FIG. 1, or any combination thereof. Various entities in the environment 100 may connect to the network 130 in accordance with various wired and wireless communication protocols, such as Transmission Control Protocol and Internet Protocol (TCP/IP), User Datagram Protocol (UDP), 2nd Generation (2G), 3rd Generation (3G), 4th Generation (4G), 5th Generation (5G) communication protocols, Long Term Evolution (LTE) communication protocols, future communication protocols or any combinations thereof. For example, the network 130 may include multiple different networks, such as a private network made accessible by the payment network 112 to the issuer server 124, the acquirer server 126, separately, and a public network (e.g., the Internet, etc.).
[0052] In one example, the user 104a utilizes the payment card 106 to perform a payment transaction (i.e., financial transaction). The payment card 106 is a physical card that may be presented to the merchant for funding the payment transaction. In addition, the payment card 106 is electronically linked with a payment account of the user 104a. The user 104a may use the payment card 106 to perform a card-present transaction at a point-of-sale (POS) terminal installed at a merchant facility. In some examples, the payment card 106 may include a debit card, a credit card, a prepaid card, a forex card, a charge card, and the like. In one embodiment, the payment card 106 may be issued by the issuer server 124.
[0053] In another example, the user 104b utilizes the user device 108 to perform a card not present (CNP) payment transaction at an ecommerce website through payment card details already stored in the user device 108. For example, the user 104b may open an application (e.g., merchant application, web browser to access merchant website, etc.) on the user device 108 to purchase goods or products offered by a merchant in exchange of payment (i.e., monetary value).
[0054] Both the above examples refer to a set of first payment environments (for example, CP/CNP payment environments) or a conventional payment system which is based on four-party model. The set of first payment environments belongs to types of payment transactions that have a plurality of prior-evolved fraud detection models for detecting fraudulent payment transactions.
[0055] With continued reference to the FIG. 1, the user 104c is generally located inside premises. The premises may include, but are not limited to, a residence, a house, an apartment, a condominium, a place of business, an office, or a combination thereof, etc. The premises may include the plurality of IoT devices 110a-110c. Examples of the plurality of IoT devices 110a-110c may include, but are not limited to, a washing machine, smart refrigerator, a television, smart security system, smart door lock, and the like. Additionally, the plurality of IoT devices 110a-110c may include sensors to determine sensory data for triggering an event.
[0056] The plurality of IoT devices 110a-110c at the premises, then, is in communication with other devices (e.g., an IoT backend server 116) via a network that may be specific to the premises and/or incorporated with the network 130, to enable controlling, and/or monitoring of the plurality of IoT devices 110a-110c, etc.
[0057] In some implementations, the IoT backend server 116 offers IT infrastructure services (e.g., computing power, storage, etc.), micro-services, and platform services to support the operation and management of the plurality of IoT devices 110a-110c. The IoT backend server 116 enables operation of the plurality of IoT devices 110a-110c within appropriate IoT ecosystems and applications. The IoT backend server 116 may facilitate interconnection of the plurality of IoT devices 110a-110c with each other. In an example, the IoT backend server 116 is configured to enable the plurality of IoT devices 110a-110c to perform payment transactions via a payment account of the user 104c.
[0058] Further, the IoT backend server 116 includes an IoT device management module 118, a cloud wallet 120, and a merchant connectivity module 122. The IoT device management module 118 may be configured to manage operations associated with the plurality of IoT devices 110a-110c, such as receiving payment requests, analyzing data, providing instructions, and the like. The cloud wallet 120 may store payment account details (e.g., credit card details, debit card details, wallet details, etc.) of the user 104c. In particular, the IoT device management module 118 is configured to initially register the plurality of IoT devices 110a-110c and discover and connect to the payment server 114. The payment server 114 may receive and store various device related data such as, name and device IDs of the plurality of IoT devices 110a-110c, type of the plurality of IoT devices 110a-110c, sensor data, etc. The various device related data may be used in determining transaction controls for the plurality of IoT devices 110a-110c based on stored IoT device payment control rules.
[0059] In one embodiment, the merchant connectivity module 122 may be configured to facilitate connection with a merchant to place a purchase order, i.e., to initiate a payment transaction, in response to certain instructions received from either an IoT device (e.g., the plurality of IoT devices 110a-110c) and/or the IoT device management module 118.
[0060] The payment accounts of the plurality of users 104a-104c may be managed by the issuer server 124. The issuer server 124 is a computing server that is associated with the issuer bank or issuing bank. The issuer bank is a financial institution that manages accounts of various cardholders. Account details of the payment accounts established with the issuer bank are stored in cardholder profiles of the cardholders in a memory of the issuer server 124, on a cloud server associated with the issuer server 124, and/or in the IoT backend server 116. In general, the issuer server 124 approves or denies an authorization request, and then routes, via the payment network 112, an authorization response back to the acquirer server 126. The acquirer server then sends the approval to the merchant.
[0061] The acquirer server 126 is associated with the merchant (not shown in figure). The acquirer server 126 is associated with a financial institution (e.g., a bank) that processes financial transactions. This can be an institution that facilitates the processing of payment transactions for physical stores, ATM terminals, merchants, or an institution that owns platforms that make online purchases or purchases made via software applications possible (e.g., shopping cart platform providers and in-app payment processing providers). The terms “acquirer”, “acquirer bank”, “acquiring bank”, or “acquirer server” will be used interchangeably herein in the description.
[0062] In one example, suppose, the IoT device 110a is a smart refrigerator. The IoT device 110a is configured to continuously monitor the food items stored inside. Upon detecting that stock of any food item stored inside the IoT device 110a (i.e., the smart refrigerator) is running low, the IoT device 110a is configured to automatically place a purchase order i.e., perform a payment transaction for the food item. Subsequently, using the cloud wallet 120 associated with the user 104c and the merchant connectivity module 122, the food item (whose stock is running low) may be ordered from a merchant. In this example, the merchant may correspond to an e-commerce website.
[0063] It is noted that the payment transactions performed via the plurality of IoT devices 110a-110c need to be highly secure. Otherwise, the fraudsters may easily break into the plurality of IoT devices 110a-110c to steal payment account information associated with the owner of the plurality of IoT devices 110a-110c (e.g., the user 104c) and then use the payment account information to perform fraudulent transactions. For an example (not in accordance with embodiments of the present disclosure), when one IoT device (e.g., the IoT device 110b) gets compromised for an individual e.g., the user 104c, the fraudsters can try using the information gathered from the IoT device 110b to break into other connected devices (e.g., the IoT devices 110a and 110c) of the individual. In another example (not in accordance with embodiments of the present disclosure), when a Wi-Fi connection is compromised at any location, any devices that had connected to the Wi-Fi have a risk of getting compromised.
[0064] Thus, there is a need to detect fraudulent transactions at the IoT device level. Since existing fraud detection models are applicable to the set of first payment environments (i.e., conventional payment system), therefore, fraud detection task using existing fraud detection models for the IoT devices is not very accurate. Further, it can be observed that fraudulent patterns in the set of first payment environments are quite different from fraudulent patterns at the IoT device level. Further, labeled data i.e., fraudulent data for the IoT devices is not sufficient to train new fraud risk models.
[0065] To overcome the above-mentioned limitations, the present disclosure proposes a server system 102 that is configured to adapt or fine-tune the existing fraud risk models of conventional payment environments for predicting fraudulent transactions at the IoT device level. The server system 102 is configured to utilize domain adaptation methods to learn fraudulent transaction patterns at the IoT device level. Generally, “Domain adaptation” refers to a goal of using data from a source domain to train models for a target domain. The domain adaptation methods explicitly relate fraudulent transaction patterns of a source domain i.e., set of first payment environments to a target domain i.e., second payment environment (e.g., IoT device initiated transactions) and then use this relation to adapt fraud risk models from the source domain to the target domain.
[0066] In one embodiment, the server system 102 is configured to build fraud detection models corresponding to different types of IoT devices since each device type may have different fraudulent patterns or behaviors. In one non-limiting example, the server system 102 is the payment server 114 associated with the payment network 112.
[0067] The server system 102 is configured to train a plurality of deep neural networks according to domain adversarial adaptation model 132. In particular, the server system 102 is configured to fine-tune or train the plurality of deep neural networks, where the plurality of deep neural networks may include, but is not limited to, a shared neural network encoder, a target private neural network, a fraud classifier, and a domain classifier. The server system 102 is configured to perform various operations to train the plurality of deep neural networks such that the prediction output of the fraud classifier is reliable in detecting whether a payment transaction performed via an IoT device (e.g., the IoT device 110a) associated with a user (e.g., the user 104c) is fraudulent or not. In an embodiment, the database 128 stores the training data. In one non-limiting example, the database 128 stores the domain adversarial adaptation model 132.
[0068] In one embodiment, the domain adversarial adaptation model 132 defines an end-to-end learning algorithm where three processes are performed at the same time. The domain adversarial adaptation model 132 enables learning features associated with both the source domain and the target domain at the same time. Further, a domain classifier helps in learning domain invariant features, and the domain adversarial adaptation model 132 also uses IoT-specific features and device-specific risk features to augment the feature representations of the target domain with learnable weights.
[0069] The server system 102 is a separate part of the environment 100 and may operate apart from (but still in communication with, for example, via the network 130) the payment server 114, and any third-party external servers (to access data to perform the various operations described herein). However, in other embodiments, the server system 102 may be incorporated, in whole or in part, into one or more parts of the environment 100, for example, the payment server 114. In addition, the server system 102 should be understood to be embodied in at least one computing device in communication with the network 130, 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.
[0070] In one embodiment, the payment network 112 may be used by the payment card issuing authorities as a payment interchange network. The payment network 112 may include a plurality of payment servers such as the payment server 114. Examples of payment interchange networks include, but are not limited to, Mastercard® payment system interchange network. The Mastercard® payment system interchange network is a proprietary communications standard promulgated by Mastercard International Incorporated® for the exchange of financial transactions among a plurality of financial activities that are members of Mastercard International Incorporated®. (Mastercard is a registered trademark of Mastercard International Incorporated located in Purchase, N.Y.).
[0071] 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 shown in FIG. 1 may be implemented as multiple, distributed systems or devices. Additionally, or alternatively, a set of systems (e.g., one or more systems) or a set of devices (e.g., one or more devices) of the environment 100 may perform one or more functions described as being performed by another set of systems or another set of devices of the environment 100.
[0072] Referring now to FIG. 2, a simplified block diagram of a server system 200 is shown, in accordance with an embodiment of the present disclosure. The server system 200 is similar to the server system 102. In some embodiments, the server system 200 is embodied as a cloud-based and/or SaaS-based (software as a service) architecture. In one embodiment, the server system 200 is a part of the payment network 112 or is integrated within the payment server 114. Although the present disclosure explains the concept of fraud or anomaly detection for financial transactions performed via IoT devices, however, a similar concept of fraud detection for financial transactions through new payment environments can also be formulated.
[0073] The server system 200 includes a computer system 202 and a database 204. The computer system 202 includes at least one processor 206 for executing instructions, a memory 208, a communication interface 210, and a storage interface 214 that communicate with each other via a bus 212. In some embodiments, the database 204 is integrated within the computer system 202. For example, the computer system 202 may include one or more hard disk drives as the database 204. 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.
[0074] The processor 206 includes suitable logic, circuitry, and/or interfaces to execute computer-readable instructions for implementing domain adaptation methods to transfer the knowledge learned during fraud detection associated with the set of first payment environments (i.e., source domain) to enhance the fraud detection of IoT device level fraudulent transactions (i.e., target domain). Domain adaptation refers to the goal of using data from a source domain to train models for a target domain.
[0075] In general, a domain having relatively high amount of high-quality training data may be referred to as a source domain. On the other hand, high-quality training data may be relatively scarce for the same fraud detection task in another domain. For purposes of this disclosure, a domain that has relatively little high-quality training data may be referred to as a target domain. High-quality training data for a source domain may be highly valuable if it could be used in a target domain for the same fraud detection task. Since, for fraud prediction tasks, there may be sufficient labeled data (e.g., fraudulent/non-fraudulent transactions) for the set of first payment environments i.e., source domain, but not enough fraudulent transactions for the second payment environment (e.g., IoT device initiated payment transactions) (i.e., target domain), therefore it would be desirable to use the general fraud detection data of the set of first payment transactions as the source domain to help in building a fraud detection model for the IoT device-initiated payment transactions.
[0076] In one embodiment, the processor 206 is configured to utilize existing fraud risk models for the set of first payment environments and adapt the existing fraud risk models for detecting fraudulent transactions from IoT devices.
[0077] 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 graphical processing unit (GPU), a field-programmable gate array (FPGA), and the like. The memory 208 includes suitable logic, circuitry, and/or interfaces to store a set of computer-readable instructions for performing operations.
[0078] 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. The processor 206 is operatively coupled to the communication interface 210 such that the processor 206 is capable of communicating with a remote device 216 such as, the payment server 114, or communicating with any entity connected to the network 130 (as shown in FIG. 1).
[0079] 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 to be noted that the server system 200 may include fewer or more components than those depicted in FIG. 2.
[0080] In one embodiment, the processor 206 includes a data pre-processing engine 218, a shared neural network encoder 220, a fraud classifier 222, and a domain classifier 224. It should be noted that components, described herein, such as the data pre-processing engine 218, the shared neural network encoder 220, the fraud classifier 222, and the domain classifier 224 can be configured in a variety of ways, including electronic circuitries, digital arithmetic and logic blocks, and memory systems in combination with software, firmware, and embedded technologies.
[0081] During the training phase, the data pre-processing engine 218 includes suitable logic and/or interfaces for accessing historical payment transaction data associated with past payment transactions of a set of first payment environments i.e., source domain (e.g., card-present, card-not-present transactions, etc.) from a transaction database for a period of time (e.g., 1 month, 6 months, 1 year, 2 years, etc.). The historical payment transaction data may include transaction-level data of past payment transactions e.g., merchant name identifier, unique merchant identifier, a timestamp, geo-location data, information on the payment instrument involved in the historical payment transaction, a fraud indicator flag, and the like. The past payment transactions associated with the set of first payment environments may be referred to as "source data samples." Each source data sample may include a source training input and a respective ground-truth source output.
[0082] For example, when a cardholder purchases an item from a merchant, a purchase transaction is labeled as fraudulent or non-fraudulent. Thus, the historical payment transactions can be leveraged to expose a variety of different attributes of the accounts, such as account activity, customer preferences, similarity to other accounts, and the like.
[0083] In a similar manner, the data pre-processing engine 218 is configured to access payment transaction data associated with previous payment transactions of a second payment environment (i.e., target domain). An example of the second payment environment may include IoT device initiated payment transactions. The data pre-processing engine 218 is also configured to obtain IoT device related data of the IoT devices which are involved in the previous payment transactions.
[0084] In one example, the payment transaction data may include at least one similar attribute (for example, transaction type (credit or debit, cross-border or domestic, recurring, or one-time, etc.), transaction amount, fraud report raised, payment account information of the sender, user information relating to a sender, user information relating to the receiver, etc.). Similarly, the device-related data of the IoT devices may include at least one similar attribute (for example, device type (smartphone, desktop, smart TV, smart fridge, POS device, etc.), device network, device security features, device unique identifier, etc.).
[0085] The previous payment transactions associated with the second payment environment may be referred to as "target data samples". The previous payment transactions may include very less number of payment transactions that are labeled as fraudulent or non-fraudulent. As noted, the source data samples are much larger than the target data samples.
[0086] The data pre-processing engine 218 may generate source and target transaction datasets corresponding to the source data samples and the target data samples, respectively. Each transaction dataset may include attributes such as transaction date, type of transaction, transaction amount, sender information, recipient information, merchant name, merchant country code, cross-border/domestic transaction flag, e-commerce/ recurring transaction indicator, etc. The source transaction dataset has a similar dimension to the target transaction dataset. In particular, the source transaction dataset is a collection of n vectors xi of size m, where m is a number of attributes. The attributes are identical in the source domain and the target domain.
[0087] The shared neural network encoder 220 includes suitable logic and/or interfaces for generating source and target feature representations corresponding to source and target domains, respectively. In particular, the shared neural network encoder 220 takes the source transaction dataset and the target transaction dataset as inputs and generates the corresponding source and target feature representations. The shared neural network encoder 220 is trained on labeled data from the source domain and unlabeled data from the target domain. As the training progresses, the shared neural network encoder 220 generates the source and target feature representations that are indiscriminative with respect to shift between the domains. The shared neural network encoder 220 is configured to embed domain adaptation into the process of learning representation so that the fraud classification task is made based on features that are both discriminative and invariant to the change of domains, i.e., have the same or very similar distributions in the source and the target domains. In this way, the obtained shared neural network encoder 220 can be applicable to the target domain without being hindered by the shift between the two domains. In one example, the shared neural network encoder 220 is a D-dimensional feed-forward neural network. The unsupervised domain adaptation is achieved by implementing the domain classifier 224 connected to the shared neural network encoder 220 via a gradient reversal layer that multiplies the gradient by a negative constant during the back-propagation training.
[0088] In particular, during training, the shared neural network encoder 220 is trained to learn domain invariant features associated with source data samples and target data samples to further generate domain invariant representations of the source data samples (i.e., the source hidden representations) and the target data samples (i.e., the target hidden representations).
[0089] In one embodiment, the shared neural network encoder 220 is pre-trained based on source data samples before introducing target data samples in the training data. By pre-training the shared neural network encoder 220 on the source domain dataset that has a much larger size than the target domain dataset, the entire process for training the shared neural network encoder 220 and the fraud classifier 222 can be more stable, quicker to converge, and computationally efficient.
[0090] In another embodiment, the shared neural network encoder 220 is trained based on source data samples and target data samples, without pre-training.
[0091] The fraud classifier 222 includes suitable logic and/or interfaces for predicting labels (i.e., fraudulent or non-fraudulent) corresponding to target data samples and the source data samples. In other words, the fraud classifier 222 is configured to classify payment transactions performed via IoT devices as fraudulent or non-fraudulent. Based on the domain adversarial training process, the fraud classifier 222 is fine-tuned for predicting fraudulent patterns in the source domain as well as in the target domain. In some examples, the fraud classifier 222 is a supervised classification model and a neural network-based classification model.
[0092] During training, the fraud classifier 222 is trained in such a way so that a fraud classification loss is minimized for the source data samples and the target data samples.
[0093] The fraud classifier 222 takes the source feature representations, or the target features representations as an input and provides a label corresponding to the source feature representations, or the target feature representations.
[0094] The domain classifier 224 includes suitable logic and/or interfaces for discriminating source and target data samples during the training phase so that the shared neural network encoder 220 and the fraud classifier 222 become domain invariant. In one embodiment, the shared neural network encoder 220, the fraud classifier 222, and the domain classifier 224 jointly learn domain invariant features by optimizing the shared neural network encoder 220 based on fraud classification loss and domain classification loss. The domain classifier 224 uses a gradient reversal layer so that all domain-related gradients from the domain classifier 224 can be multiplied by a negative constant during back-propagation. Thus, during the training, the shared neural network encoder 220 is optimized to both minimize the fraud classification loss and maximize the domain classification loss. This approach helps in learning domain invariant features for fraud prediction tasks for the source domain and the target domain.
[0095] Thus, the processor 206 is configured to perform transfer learning in a single shot where the plurality of deep neural networks is trained with the source data samples and the target data samples together and learns domain invariant features. The domain classifier 224 ensures that the shared neural network encoder 220 and the fraud classifier 222 learn domain invariant representations. In some implementations, the fraud classifier 222 learns neural network parameters (i.e., weights and biases) that degrade the performance of the domain classifier 224. The output of the fraud classifier 222 results in low accuracy or degradation of the domain classifier 224, thereby implying that the fraud classifier 222 is learning domain invariant features. In this manner, the fraud classifier 222 is optimized to detect fraudulent payment transactions irrespective of the domain of the payment transactions.
[0096] In one embodiment, additional IoT-specific features and device risk features are used to augment or modify the target feature representations corresponding to the target data samples that are generated by the shared neural network encoder 220. The additional IoT-specific features are combined with the target feature representations with their own learnable weight parameters associated with a target private neural network. The target private neural network corresponds to a device profile of the IoT device associated with the target data samples.
[0097] FIG. 3 is a schematic arrangement 300 of a plurality of deep neural networks trained based on a domain adversarial adaptation model 132, in accordance with an embodiment of the present disclosure. The schematic arrangement 300 describes data flow among a shared neural network encoder 302, a target private neural network 304, and a fraud classifier 306 during the training process.
[0098] With reference to FIG. 3, the processor 206 is initially configured to train the shared neural network encoder 302 with the source data samples only. In particular, the processor 206 is configured to train the shared neural network encoder 302 based on the source data samples associated with the source domain. In addition, the shared neural network encoder 302 is independent of the fraud classifier 306. In some implementations, the shared neural network encoder 302 and the fraud classifier 306 collectively, may act as a feed-forward neural network.
[0099] The shared neural network encoder 302 is configured to generate the source feature representations based on the source data samples. The source feature representations are then fed as an input to the fraud classifier 306. In one non-limiting example, the fraud classifier 306 is a classification model used to classify whether a payment transaction is a fraudulent payment transaction or not. In one example, the objective of the training of the shared neural network encoder 302 and the fraud classifier 306 is to minimize the fraud classification loss.
[00100] The schematic arrangement 300 also includes a pre-trained fraud detection model 308. In one non-limiting example, the pre-trained fraud detection model 308 is a neural network model. In one implementation, the pre-trained fraud detection model 308 is configured to detect whether a payment transaction (belonging to the set of first payment environments) is fraudulent or not. In an example, the pre-trained fraud detection model 308 is trained to perform fraud detection for payment transactions performed through payment cards. In another example, the pre-trained fraud detection model 308 is trained to perform fraud detection for payment transactions performed through mobile devices.
[00101] In an example, transaction features corresponding to a payment transaction are passed as an input to the pre-trained fraud detection model 308 (see, 310). Based on the transaction features corresponding to the payment transaction, the pre-trained fraud detection model 308 is configured to detect whether a payment transaction is fraudulent or not.
[00102] In one implementation, trained weights associated with the pre-trained fraud detection model 308 are transferred to the shared neural network encoder 302 (see, 312). The trained weights of the shared neural network encoder 302 are then frozen. Further, the fraud classifier 306 has trainable parameters (e.g., weights and biases) that get updated based on the already trained weights. In particular, the neural network parameters (e.g., weights and biases) of the fraud classifier 306 are back propagated to complete the training of the shared neural network encoder 302 and the fraud classifier 306.
[00103] It is to be noted that the source domain includes transaction-level fraud data without IoT device-level information (i.e., device-specific risk features). For an example, the source data samples indicate information about fraudulent as well as non-fraudulent payment transactions performed only at the set of first payment environments and do not include device-specific risk features (i.e., features of second payment environment) associated with IoT devices or information about payment transactions performed via IoT devices.
[00104] In one implementation, the pre-trained fraud detection model 308 is initially trained with only the source data samples and not with the target data samples. In an example, the shared neural network encoder 302 is also initially trained on the source data samples only. The shared neural network encoder 302 then generates the source feature representations based on the source data samples. Further, the shared neural network encoder 302 feeds the source feature representations to the fraud classifier 306 to facilitate learning of fraudulent patterns in payment transactions indicated in the source domain.
[00105] In another example, data samples (e.g., target data samples) are fed as an input to the shared neural network encoder 302 (see, 314). The shared neural network encoder 302 is configured to generate feature representations corresponding to the data samples. The weights corresponding to the shared neural network encoder 302 are frozen and the parameters (e.g., weights, biases, etc.) corresponding to the fraud classifier 306 are back propagated for the training.
[00106] It is noted that the fraud classifier 306 may be trained based on the source data samples only for a few epochs. After that, the fraud classifier 306 is also trained based on the device-specific risk features and IoT-specific features associated with an IoT device (e.g., the IoT device 110a) of the plurality of IoT devices 110a-110c. In particular, before the fraud classifier 306 is trained, the feature representations generated by the shared neural network encoder 302 are modified (i.e., concatenated along with the device-specific risk features and the IoT-specific features). The feature representations generated by the shared neural network encoder 302 are modified based on the concatenation of the device-specific risk features and the IoT-specific features with the feature representations (see, 316). The modified feature representations are further fed as an input to the fraud classifier 306.
[00107] The trainable weights may be transferred from the pre-trained fraud detection model 308. The trainable weights are frozen and the fraud classifier 306 then updates its weights based on the learnable parameters. In an example, weights of the shared neural network encoder 302 may be denoted as the first set of weights “W0”, the weights of the fraud classifier 306 may be denoted as the second set of weights “W1”, and the weights of the target private neural network 304 may be denoted as the fourth set of weights “W3”.
[00108] It is to be noted that training the shared neural network encoder 302 and the fraud classifier 306 based on the source domain only for a few epochs does not mean that the training is equivalent to conventional transfer learning (in which a pre-trained model is fine tuned based on source data). The training is performed in this manner to ensure that back propagation of the domain classifier results in meaningful weight updates. This may also lead to a stable training process.
[00109] FIG. 4 is a schematic representation 400 of the plurality of deep neural networks trained based on domain adversarial adaptation model 132, in accordance with another embodiment of the present disclosure. In particular, the schematic representation 400 discloses the training of the plurality of DNNs with the source data samples and the target data samples concurrently. The schematic representation 400 includes a shared neural network encoder 402, a target private neural network 404, a fraud classifier 406, and a domain classifier 408.
[00110] The shared neural network encoder 402 is identical to the shared neural network encoder 302. Similarly, the target private neural network 404 is identical to the target private neural network 304. Similarly, the fraud classifier 406 is identical to the fraud classifier 306.
[00111] From the first epoch of the training process, the processor 206 is configured to train the shared neural network encoder 402 using the source data samples and the target data samples concurrently. In particular, the source data samples are fed as an input to the shared neural network encoder 402 (see, 410). In addition, the target data samples are fed as an input to the shared neural network encoder 402 (see, 412). The shared neural network encoder 402 is then configured to generate the source feature representations based on the source data samples and the target feature representations based on the target data samples. In one implementation, weights associated with the shared neural network encoder 402 may be denoted as the first set of weights “W0”. The shared neural network encoder 402 is trained based on the training data (i.e., the source data samples, and the target data samples).
[00112] In some implementations, the target private neural network 404 is trained based on the device-specific risk features (i.e., risk score) and the IoT-specific risk features (see, 414). In one example, the server system 102 is configured to generate a risk score corresponding to an IoT device (e.g., the IoT device 110a). In some examples, the server system 102 is configured to generate the risk score based on fraud-reported data of the corresponding IoT device. In an example, neural network parameters (e.g., weights, biases, etc.) of the target private neural network 404 may be initialized based on learning from the device-specific risk features. To initialize weights for the target private neural network 404, the device-specific risk features corresponding to an IoT device (e.g., the IoT device 110a) is concatenated with the target feature representations. In addition, the device-specific risk features have their learnable weight parameters. The target private neural network 404 is configured to modify the target feature representations based, at least in part, on the device-specific risk features and the IoT-specific risk features of the IoT device. More specifically, the target private neural network 304 is configured to concatenate the target feature representations with the device-specific risk features and the IoT-specific risk features to generate the modified target feature representations (see, 416).
[00113] In one implementation, weights associated with the target private neural network 404 may be denoted as the fourth set of weights “W3”. The fourth set of weights associated with the target private neural network 404 may be based on IoT ecosystems and specific to cardholders (e.g., the user 104c) associated with IoT devices (e.g., the IoT device 110a). Subsequently, the fourth set of weights “W3” of the target private neural network 404 may indicate a risk score specific to an IoT device (e.g., the IoT device 110a). For example, each IoT device (e.g., the IoT device 110a) has a risk score calculated based on fraud-reported data that may be available on a timely basis (e.g., monthly, weekly, bi-weekly, annually, etc.).
[00114] Further, the target private neural network 404 is configured to concatenate the device-specific risk features (related to the IoT devices) with the target feature representations to generate the modified target feature representations. In other words, the target feature representations are concatenated with the device-specific risk features corresponding to the IoT device (e.g., the IoT device 110a) based, at least in part, on the target private neural network 404.
[00115] The source feature representations and the modified target feature representations are then fed to the fraud classifier 406 (see, 418) and the domain classifier 408 (see, 420). The domain classifier 408 is trained to identify the domain (i.e., source domain or target domain) of the payment transaction in the training data. In addition, the fraud classifier 406 is trained to identify fraudulent patterns associated with both the source domain and the target domain, i.e., identify whether a payment transaction is fraudulent or not.
[00116] After the first epoch of training, neural network parameters (e.g., the set of neural network weights, losses, gradients, biases, etc.) of the plurality of DNNs (i.e., the shared neural network encoder 402, the target private neural network 404, the fraud classifier 406, and the domain classifier 408) are updated.
[00117] In some implementations, the processor 206 is configured to calculate a first gradient descent value (G1) and a second gradient descent value (G2) associated with the fraud classifier 406. In addition, the processor 206 is configured to calculate a fraud classification loss (L1) associated with the fraud classifier 406. In some implementations, the processor 206 is configured to calculate a third gradient descent value (G3), a fourth gradient descent value (G4), and a fifth gradient descent value (G5) associated with the domain classifier 408. In addition, the processor 206 is configured to calculate a domain classification loss (L2) associated with the domain classifier 408.
[00118] Let us consider that the fraud classification loss (L1) associated with the fraud classifier 406 is represented as “L1”. Further, the first gradient of loss (i.e., the first gradient descent value) may be represented as “G1”. The processor 206 is configured to calculate the first gradient descent value “G1” based on the fraud classification loss “L1” and the second set of weights “W1” associated with the fraud classifier 406. Mathematically, the first gradient descent value (G1) may be calculated as:
G1 = δ L1 / δ W1 … Eqn. (1)
[00119] Thereafter, the first gradient descent value “G1” is back propagated as feedback to the fraud classifier 406 to update the existing second set of weights “W1”. For example, the first gradient descent value “G1” is back propagated as a feedback to the initial layers of the fraud classifier 406.
[00120] In addition, a second gradient of loss (i.e., the second gradient descent value) may be represented as “G2”. The processor 206 is configured to calculate the second gradient descent value (G2) based on the fraud classification loss “L1” and the fourth set of weights “W3” associated with the target private neural network 404. Mathematically, the second gradient descent value (G2) may be calculated as:
G2 = δ L1 / δ W3 … Eqn. (2)
[00121] Thereafter, the second gradient descent value “G2” is back propagated as feedback to the target private neural network 404 to update the existing fourth set of weights “W3” associated with the target private neural network 404. For example, the second gradient descent value “G2” is back propagated as feedback to the initial layers of the target private neural network 404.
[00122] Let us consider that the domain classification loss (L2) associated with the domain classifier 408 is represented as “L2”. Further, the third gradient of loss (i.e., the third gradient descent value) is represented as “G3”. The processor 206 is configured to calculate the third gradient descent value (G3) based on the domain classification loss “L2” and the third set of weights “W2” associated with the domain classifier 408. Mathematically, the third gradient descent value (G3) may be calculated as:
G3 = δ L2 / δ W2 … Eqn. (3)
[00123] Thereafter, the third gradient descent value “G3” is back propagated as feedback to the domain classifier 408 to update the existing third set of weights “W2” associated with the domain classifier 408. For example, the third gradient descent value “G3” is back propagated as feedback to the initial layers of the domain classifier 408.
[00124] Furthermore, a fourth gradient of loss (i.e., fourth gradient descent value) is represented as “G4”. The processor 206 is configured to calculate the fourth gradient descent value (G4) based on the domain classification loss “L2” and the first set of weights “W0” associated with the shared neural network encoder 402. Mathematically, the fourth gradient descent value (G4) may be calculated as:
G4 = δ L2 / δ W0 … Eqn. (4)
[00125] Thereafter, a negative value of the fourth gradient descent value “-G4” is back propagated as feedback to the shared neural network encoder 402 to update the existing first set of weights “W0” associated with the shared neural network encoder 402. For example, the fourth gradient descent value “G4” is back propagated as feedback to the initial layers of the shared neural network encoder 402.
[00126] Moreover, a fifth gradient of loss (i.e., the fifth gradient descent value) is represented as “G5”. The processor 206 is configured to calculate the fifth gradient descent value (G5) based on the domain classification loss “L2” and the fourth set of weights “W3” associated with the target private neural network 404. Mathematically, the fifth gradient descent value (G5) may be calculated as:
G5 = δ L2 / δ W3 … Eqn. (5)
[00127] Thereafter, a negative value of the fifth gradient descent “-G5” is back propagated as a feedback to the target private neural network 404 to update the existing fourth set of weights “W3” associated with the target private neural network 404. For example, the fifth gradient descent “G5” is back propagated as a feedback to the initial layers of the target private neural network 404.
[00128] In some implementations, a combination of the second gradient descent value (G2) and a negative value of the fifth gradient descent value (G5) is back propagated to update the fourth set of weights (W3).
[00129] It is to be noted that the negative value of the fourth gradient descent “-G4” is used to update the first set of weights “W0”. This enables the fraud classifier 406 to learn weights that degrade the performance of the domain classifier 408. In this manner, an initial part of the fraud classifier 406 is forced to learn domain invariant features for classification of the payment transactions performed via IoT devices (e.g., the IoT devices 110a-110c) as fraudulent or not.
[00130] In addition, by providing the negative value of the fourth gradient descent “-G4” and the fifth gradient descent “-G5” of the domain classifier 408 to the shared neural network encoder 402 and the target private neural network 404 respectively, the performance of the domain classifier 408 is degraded. As a result, the domain classifier 408 is trained to not distinguish between the domain of the source feature representations (i.e., the source domain) and the target feature representations (i.e., the target domain).
[00131] Subsequently, the set of neural network weights “W0-W3” of the plurality of DNNs is updated after the first epoch, based on the fraud classification loss “L1” and the domain classification loss “L2”.
[00132] FIG. 5 illustrates a process flow for training a plurality of deep neural networks for predicting fraudulent financial transactions performed via an IoT device, in accordance with an embodiment of the present disclosure. The sequence of operations of the process flow 500 may not be necessarily executed in the same order as they are presented. Further, one or more operations may be grouped and performed in form of a single step, or one operation may have several sub-steps that may be performed in parallel or in a sequential manner.
[00133] At 502, the server system 200 accesses training data. In some implementations, the training data includes the source data samples corresponding to the source domain and the target data samples corresponding to the target domain. The source data samples are indicative of transaction-level fraud data related to payment transactions performed at the set of first payment environments, while the target data samples are indicative of transaction-level fraud data related to payment transactions performed at the second payment environment (i.e., payment transactions performed via the IoT devices110a-110c).
[00134] At 504, the server system 200 trains the plurality of DNNs iteratively based on the training data. In some implementations, the plurality of DNNs is trained on the source data samples and the target data samples concurrently, using a single shot transfer learning method. The “single-shot transfer learning method” herein refers to the training of the plurality of DNNs based on knowledge or information from both the source domain and the target domain concurrently.
[00135] At 506, the server system 200 generates the source feature representations and the target feature representations based, at least in part, on the shared neural network encoder and the training data. The server system 200 generates the source feature representations corresponding to the source data samples of the source domain. In addition, the server system 200 generates the target feature representations corresponding to the target data samples of the target domain.
[00136] At 508, the server system 200 modifies the target feature representations corresponding to the target domain based on the device-specific risk features. In particular, the server system 200 concatenates the device-specific risk features with the target feature representations to generate modified target feature representations. In an example, the device-specific risk features include a risk score corresponding to an IoT device (e.g., the IoT device 110a) of the plurality of IoT devices.
[00137] In an example, the server system 200 calculates the risk score associated with an IoT device (e.g., the IoT device 110a) of the plurality of IoT devices 110a-110c based on fraud reported data of the plurality of IoT devices 110a-110c available on a timely basis (e.g., monthly, weekly, quarterly, annually). The risk score may be indicative of individual-level risk and/or geo-specific risk.
[00138] In an example scenario, if an IoT device (e.g., the IoT device 110a) associated with a cardholder (e.g., the user 104c) gets compromised or hacked, then, the fraudsters can utilize this information to break into or hack other connected devices (e.g., user devices, IoT devices, etc.) associated with the cardholder. This is termed as individual-level risk. In another example scenario, if a wireless connection (for example, wi-fi connection) at a specific geo-location gets compromised or hacked, then all the devices (e.g., user devices, IoT devices) connected to the wireless connection are at risk of getting compromised. This is termed a geo-specific risk.
[00139] At 510, the server system 200 trains the fraud classifier and the domain classifier concurrently based, at least in part, on the source feature representations and the target feature representations (e.g., modified with the device-specific risk features) as inputs. The fraud classifier is trained to classify fraudulent patterns associated with the source domain and the target domain. In addition, the domain classifier is trained to not distinguish the source domain and the target domain.
[00140] At 512, the server system 200 updates the set of neural network weights associated with the plurality of DNNs based, at least in part, on the fraud classification loss and the domain classification loss. The fraud classification loss is associated with the fraud classifier and the domain classification loss is associated with the domain classifier.
[00141] At 514, the server system 200 stores the set of neural network weights in the database 128 or the database 204.
[00142] FIG. 6 illustrates a process flow 600 for fraud detection in financial transactions for IoT devices, in accordance with an embodiment of the present disclosure. The sequence of operations of the process flow 600 may not be necessarily executed in the same order as they are presented. Further, one or more operations may be grouped together and performed in form of a single step, or one operation may have several sub-steps that may be performed in parallel or in a sequential manner.
[00143] At 602, the server system 200 receives payment transaction information associated with an IoT device (e.g., the IoT device 110a). In an example, the IoT device 110a associated with the user 104c performs a payment transaction. In particular, the IoT device 110a may send a request to the IoT backend server 116 to perform the payment transaction. The IoT backend server 116 may facilitate the IoT device 110a to perform the payment transaction and can also share the payment transaction information associated with the payment transaction to the server system 200.
[00144] At 604, the server system 200 generates payment transaction features based, at least in part, on the payment transaction information. For example, the server system 200 may perform data pre-processing steps to generate the payment transaction features.
[00145] At 606, the server system 200 accesses the device-specific risk features associated with the IoT device 110a. For example, the server system 200 may access the device-specific risk features from the database 128. In one example, the device-specific risk features may include the risk score associated with the IoT device 110a.
[00146] At 608, the server system 200 runs a set of trained DNNs including, for example, the shared neural network encoder, the target private neural network, and the fraud classifier based, at least in part, on the payment transaction features and device-specific risk features. It is to be noted that the domain classifier is not implemented during the execution phase.
[00147] At 610, the server system 200 inputs the payment transaction features to the shared neural network encoder. The shared neural network encoder is configured to generate a feature representation based on the payment transaction features.
[00148] At 612, the server system 200 concatenates the device-specific risk features associated with the IoT device 110a with the feature representation to generate a modified feature representation. In particular, the target private neural network modifies the feature representations based on the device-specific risk features associated with the IoT device 110a.
[00149] At 614, the server system 200 provides the modified feature representations as an input to the fraud classifier.
[00150] At 616, the server system 200 classifies the payment transaction as either fraudulent or non-fraudulent based on the output of the fraud classifier. In an example, the fraud classifier may analyze the modified feature representations associated with the payment transaction, and then classify the payment transaction as either fraudulent or non-fraudulent. In one example, the fraud classifier provides binary output in the form of 0 (for non-fraudulent payment transaction) and 1 (for fraudulent payment transaction).
[00151] At 618, the server system 200 transmits the output of the fraud classifier (i.e., 0 or 1) to the IoT backend server 116. In some implementations, the server system 200 transmits the output of the fraud classifier (i.e., 0 or 1) to the issuer server 124 associated with a payment account of the user 104c.
[00152] FIG. 7 is a process flow chart of a computer-implemented method for training a plurality of deep neural networks for predicting fraudulent financial transactions performed via an IoT device, in accordance with an embodiment of the present disclosure. The method 700 depicted in the flow chart may be executed by, for example, a computer system. The computer system is identical to the server system 200. Operations of the flow chart of the method 700, and combinations of operations in the flow chart of 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. It is noted that the operations of the method 700 can be described and/or practiced by using a system other than these computer systems. The method 700 starts at operation 702.
[00153] At the operation 702, the method 700 includes accessing, by the server system 200, the training data including the source data samples associated with the source domain and the target data samples associated with the target domain. The source data samples include historical payment transactions performed within the set of first payment environments. The target data samples include previous payment transactions performed within the second payment environment.
[00154] At operation 704, the method 700 includes training, by the server system 200, the plurality of deep neural networks (DNNs) by running a plurality of training epochs. Each training epoch may include execution of a plurality of operations 704a-704c. The training of the plurality of DNNs is performed based, at least in part, on the single-shot transfer learning using domain feedback. The plurality of training epochs is run till a particular count. In one embodiment, the plurality of training epochs is run till at a stage when the fraud classification loss is less than or equal to a first threshold value and the domain classification loss is greater than or equal to a second threshold value.
[00155] At operation 704a, the method 700 includes generating, by the server system 200, the source feature representations corresponding to the source domain and the target feature representations corresponding to the target domain based, at least in part, on the shared neural network encoder and the training data.
[00156] At operation 704b, the method 700 includes training, by the server system 200, the fraud classifier, and the domain classifier concurrently based, at least in part, on the source feature representations and the target feature representations as inputs. The fraud classifier is trained to classify fraudulent patterns associated with the source domain and the target domain and the domain classifier is trained to not distinguish the source domain and the target domain.
[00157] At operation 704c, the method 700 includes updating, by the server system 200, the set of neural network weights associated with the plurality of DNNs based, at least in part, on the fraud classification loss and the domain classification loss.
[00158] At operation 706, the method 700 includes storing, by the server system 200, the set of neural network weights associated with the plurality of DNNs in the database 128 or the database 204.
[00159] The sequence of operations of the method 700 need not be necessarily executed in the same order as they are presented. Further, one or more operations may be grouped together and performed in form of a single step, or one operation may have several sub-steps that may be performed in parallel or in a sequential manner.
[00160] FIG. 8 is a simplified block diagram of an issuer server 800, in accordance with an embodiment of the present disclosure. The issuer server 800 is an example of the issuer server 124 of FIG. 1. The issuer server 800 is associated with an issuer bank/issuer, in which an account holder (e.g., the plurality of users 104a-104c) may have an account, which provides a payment card (e.g., the payment card 106). The issuer server 800 includes a processing module 805 operatively coupled to a storage module 810 and a communication module 815. The components of the issuer server 800 provided herein may not be exhaustive and the issuer server 800 may include more or fewer components than those depicted in FIG. 8. 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 issuer server 800 may be configured using hardware elements, software elements, firmware elements, and/or a combination thereof.
[00161] The storage module 810 is configured to store machine-executable instructions to be accessed by the processing module 805. Additionally, the storage module 810 stores information related to, contact information of the cardholders (e.g., the plurality of users 104a-104c), bank account number, availability of funds in the account, payment card details, transaction details, payment account details, and/or the like. Further, the storage module 810 is configured to store payment transactions.
[00162] In one embodiment, the issuer server 800 is configured to store profile data (e.g., an account balance, a credit line, details of the cardholders, account identification information, payment card number, etc.) in a database. The details of the cardholders may include, but are not limited to, name, age, gender, physical attributes, location, registered contact number, family information, alternate contact number, registered e-mail address, or the like of the cardholders, etc.
[00163] The processing module 805 is configured to communicate with one or more remote devices such as a remote device 820 using the communication module 815 over a network such as the network 130 of FIG. 1. Examples of the remote device 820 include the server system 200, the payment server 114, the database or other computing systems of the issuer server 800. The communication module 815 is capable of facilitating such operative communication with the remote devices and cloud servers using API (Application Program Interface) calls. The communication module 815 is configured to receive a payment transaction request performed by an account holder (e.g., the user 104a) via the network 130. The processing module 805 receives payment card information, a payment transaction amount, customer information, and merchant information from the remote device 820 (e.g., the payment server 114). The issuer server 800 includes a transaction database 830 for storing transaction data. The transaction data may include, but is not limited to, transaction attributes, such as transaction amount, source of funds such as bank or credit cards, transaction channel used for loading funds such as POS terminal or ATM machine, transaction velocity features such as count and transaction amount sent in the past x days to a particular account holder, transaction location information, external data sources and other internal data to evaluate each transaction. The issuer server 800 includes a user profile database 825 storing user profile associated with the plurality of account holders.
[00164] In one embodiment, the issuer server 800 is also configured to store historical fraudulent chargeback activities associated with the account holders (e.g., the plurality of users 104a-104c) in a fraud and chargeback database 835. The user profile data may include an account balance, a credit line, details of the account holders, account identification information, payment card number, or the like. The details of the account holders (e.g., the plurality of users 104a-104c) may include, but are not limited to, name, age, gender, physical attributes, location, registered contact number, family information, alternate contact number, registered e-mail address, or the like of the account holders.
[00165] FIG. 9 is a simplified block diagram of a payment server 900, in accordance with an embodiment of the present disclosure. The payment server 900 is an example of the payment server 114 of FIG. 1. The payment server 900 and the server system 200 may use the payment network 112 as a payment interchange network. Examples of payment interchange networks include, but are not limited to, Mastercard® payment system interchange network.
[00166] The payment server 900 includes a processing system 905 configured to extract programming instructions from a memory 910 to provide various features of the present disclosure. The components of the payment server 900 provided herein may not be exhaustive and the payment server 900 may include more or fewer components than that depicted in FIG. 9. 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 900 may be configured using hardware elements, software elements, firmware elements, and/or a combination thereof.
[00167] Via a communication interface 915, the processing system 905 receives a request from a remote device 920, such as the issuer server 124 or the acquirer server 126. The request may be a request for conducting the payment transaction. The communication may be achieved through API calls, without loss of generality. The payment server 900 includes a database 925. The database 925 also includes transaction processing data such as issuer ID, country code, acquirer ID, and merchant identifier (MID), among others.
[00168] When the payment server 900 receives a payment transaction request from the acquirer server 126 or a payment terminal (e.g., IoT device), the payment server 900 may route the payment transaction request to an issuer server (e.g., the issuer server 124). The database 925 stores transaction identifiers for identifying transaction details such as transaction amount, IoT device details, acquirer account information, transaction records, merchant account information, and the like.
[00169] In one example embodiment, the acquirer server 126 is configured to send an authorization request message to the payment server 900. The authorization request message includes, but is not limited to, the payment transaction request.
[00170] The processing system 905 further sends the payment transaction request to the issuer server 124 for facilitating the payment transactions from the remote device 920. The processing system 905 is further configured to notify the remote device 920 of the transaction status in form of an authorization response message via the communication interface 915. The authorization response message includes, but is not limited to, a payment transaction response received from the issuer server 124. Alternatively, in one embodiment, the processing system 905 is configured to send an authorization response message for declining the payment transaction request, via the communication interface 915, to the acquirer server 126. In one embodiment, the processing system 905 executes similar operations performed by the server system 200, however, for the sake of brevity, these operations are not explained herein.
[00171] The disclosed methods with reference to FIGS. 1 to 9, or one or more operations of the methods 500, 600, and 700 may be implemented using software including computer-executable instructions stored on one or more computer-readable media (e.g., non-transitory computer-readable media, such as one or more optical media discs, volatile memory components (e.g., DRAM or SRAM), or nonvolatile memory or storage components (e.g., hard drives or solid-state nonvolatile memory components, such as Flash memory components) and executed on a computer (e.g., any suitable computer, such as a laptop computer, netbook, Web book, tablet computing device, smartphone, or other mobile computing devices)). Such software may be executed, for example, on a single local computer or in a network environment (e.g., via the Internet, a wide-area network, a local-area network, a remote web-based server, a client-server network (such as a cloud computing network), or other such networks) using one or more network computers. Additionally, any of the intermediate or final data created and used during 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.
[00172] 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 spirit and 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 Digital Signal Processor (DSP) circuitry).
[00173] Particularly, the server system 200 (e.g., the server system 102) and its various components such as the computer system 202 and the database 204 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 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 include 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), CD-ROM (compact disc read only memory), CD-R (compact disc recordable), CD-R/W (compact disc rewritable), DVD (Digital Versatile Disc), BD (BLU-RAY® Disc), and semiconductor memories (such as mask ROM, PROM (programmable ROM), EPROM (erasable PROM), flash memory, RAM (random access memory), 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.
[00174] Various embodiments of the invention, as discussed above, may be practiced with steps and/or operations in a different order, and/or with hardware elements in configurations, which are different than those which are disclosed. Therefore, although the invention has been described based upon these exemplary embodiments, it is noted that certain modifications, variations, and alternative constructions may be apparent and well within the spirit and scope of the invention.
[00175] Although various exemplary embodiments of the invention are described herein in a language specific to structural features and/or methodological acts, the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as exemplary forms of implementing the claims. , Claims:CLAIMS
We claim:

1. A computer-implemented method, comprising:
accessing, by a server system, a training data comprising source data samples associated with a source domain and target data samples associated with a target domain, the source data samples comprising historical payment transactions performed within a set of first payment environments, and the target data samples comprising previous payment transactions performed within a second payment environment;
training, by the server system, a plurality of deep neural networks (DNNs) by running a plurality of training epochs, each training epoch comprising a plurality of operations, the plurality of operations comprising:
generating, by the server system, source feature representations corresponding to the source domain and target feature representations corresponding to the target domain based, at least in part, on a shared neural network encoder and the training data;
training, by the server system, a fraud classifier and a domain classifier concurrently based, at least in part, on the source feature representations and the target feature representations as inputs, the fraud classifier trained to classify fraudulent patterns associated with the source domain and the target domain, the domain classifier trained to not distinguish the source domain and the target domain; and
updating, by the server system, a set of neural network weights associated with the plurality of DNNs based, at least in part, on a fraud classification loss (L1) and a domain classification loss (L2); and
storing, by the server system, the set of neural network weights associated with the plurality of DNNs in a database.

2. The computer-implemented method as claimed in claim 1, wherein the second payment environment corresponds to payment transactions performed via an Internet of Things (IoT) device.

3. The computer-implemented method as claimed in claim 2, wherein training the plurality of DNNs is performed based, at least in part, on a single-shot transfer learning using domain feedback, and wherein the plurality of DNNs comprises the shared neural network encoder, the fraud classifier, the domain classifier, and a target private neural network associated with the target domain.

4. The computer-implemented method as claimed in claim 3, wherein the plurality of operations further comprises:
modifying, by the server system, the target feature representations corresponding to the target domain based, at least in part, on an output of the target private neural network that is associated with a device profile of the IoT device.

5. The computer-implemented method as claimed in claim 4, wherein modifying the target feature representations further comprises:
concatenating, via the target private neural network, the target feature representations with device-specific risk features and IoT-specific features associated with the IoT device.

6. The computer-implemented method as claimed in claim 3, wherein the set of neural network weights comprises at least one of:
a first set of weights (W0) associated with the shared neural network encoder,
a second set of weights (W1) associated with the fraud classifier,
a third set of weights (W2) associated with the domain classifier, and
a fourth set of weights (W3) associated with the target private neural network.

7. The computer-implemented method as claimed in claim 6, further comprising:
calculating, by the server system, a first gradient descent value (G1) associated with the fraud classifier based, at least in part, on the fraud classification loss (L1) and the second set of weights (W1); and
back propagating, by the server system, the first gradient descent value (G1) to the fraud classifier to update the second set of weights (W1).

8. The computer-implemented method as claimed in claim 6, further comprising:
calculating, by the server system, a third gradient descent value (G3) associated with the domain classifier based, at least in part, on the domain classification loss (L2) and the third set of weights (W2); and
back propagating, by the server system, the third gradient descent value (G3) to the domain classifier to update the third set of weights (W2).

9. The computer-implemented method as claimed in claim 6, further comprising:
calculating, by the server system, a fourth gradient descent value (G4) associated with the domain classifier based, at least in part, on the domain classification loss (L2) and the first set of weights (W0); and
back propagating, by the server system, a negative value of the fourth gradient descent value (G4) to the shared neural network encoder to update the first set of weights (W0).

10. The computer-implemented method as claimed in claim 6, further comprising:
calculating, by the server system, a second gradient descent value (G2) associated with the fraud classifier based, at least in part, on the fraud classification loss (L1) and the fourth set of weights (W3);
calculating, by the server system, a fifth gradient descent value (G5) associated with the domain classifier based, at least in part, on the domain classification loss (L2) and the fourth set of weights (W3); and
back propagating, by the server system, a combination of the second gradient descent value (G2) and a negative value of the fifth gradient descent value (G5) to update the fourth set of weights (W3).

11. A server system configured to perform the computer-implemented method as claimed in any of the claims 1-10.