A framework for generating risk assessment models

Abstract

Methods and systems are presented for providing a framework to generate a computer model to detect fraudulent electronic transactions. The framework selects and retrieves a set of transaction records from an online database system based on one or more indicators. The framework then enriches the set of transaction records with additional data associated with the set of transaction records. The additional data for each transaction record may include transaction data of another transaction record selected based on a common attribute shared with the transaction record. The framework serializes the transaction data and additional data associated with the set of transaction records. A feature set is derived based on analyzing the serialized data. The framework then generates a computer model for detecting fraudulent electronic transactions based on the feature set.

Description

Technical Field

[0001] The present specification relates generally to risk assessment modeling and, more particularly, to a framework for generating computer models for use in assessing electronic transactions. Background Art

[0002] Strategies for conducting fraudulent transactions electronically continue to evolve and become more sophisticated. Electronic service providers need to keep pace with fraudulent users by providing security measures, such as accurately assessing risk in real time (e.g., detecting fraudulent transactions). In this regard, computer models are often used to assist in assessing the risk of electronic transactions in real time. The computer model extracts data related to the transaction, performs analysis on the extracted data, and provides results. The results can then be used to decide whether to authorize or deny the transaction.

[0003] As described above, fraudulent transaction strategies are dynamic and may change from time to time. For example, old strategies that have not been used recently may become new trends again, new strategies may be introduced, and strategies may become periodic trends again periodically. The user base of the service may also change from time to time, which further increases the complexity. For example, a service may be introduced to a new geographic area, and the new geographic area exhibits fraudulent behavior different from the existing user base. Therefore, a computer model that focuses on maximizing performance based on recent fraudulent transaction data may perform poorly in the future (e.g., fail to identify fraudulent transactions). Electronic service providers may have to generate new computer models from time to time (e.g., by using different features) to target new strategies and new fraud trends. However, it may be costly to continuously generate new computer models to assess risks in electronic transactions. Therefore, it is necessary to efficiently generate a system and method for a robust computer model for assessing transaction risks in electronics. BRIEF DESCRIPTION OF THE DRAWINGS

[0004] Figure 1 is a block diagram illustrating an electronic transaction system according to an embodiment of the present disclosure;

[0005] Figure 2 is a block diagram illustrating a risk analysis module according to an embodiment of the present disclosure;

[0006] Figure 3 is a block diagram illustrating a model generation module according to an embodiment of the present disclosure;

[0007] Figure 4 is a flowchart illustrating a process of generating a risk analysis model according to an embodiment of the present disclosure;

[0008] Figure 5 An exemplary implementation of a risk analysis model according to an embodiment of the present disclosure is shown;

[0009] Figure 6 It is shown that a risk analysis model is verified in parallel by multiple devices according to an embodiment of the present disclosure; and

[0010] Figure 7 is a block diagram of a system for implementing a device according to an embodiment of the present disclosure.

[0011] The embodiments of the present disclosure and their advantages can be best understood by referring to the detailed description below. It should be understood that the same reference numerals are used to identify the same elements illustrated in one or more of the accompanying drawings, wherein the illustrations in the accompanying drawings are for the purpose of illustrating the embodiments of the present disclosure, rather than for limiting the embodiments of the present disclosure. DETAILED DESCRIPTION

[0012] The present disclosure describes a method and system for providing a framework for generating a computer model (e.g., a risk analysis model) for assessing risk in electronic transactions for electronic service providers. The computer model generated for assessing risk in electronic transactions can use a data set (also referred to as a "feature") related to the electronic transaction to assess the risk of the electronic transaction (e.g., generate a risk score). The risk score can indicate whether the electronic transaction is a possible, potential, or very likely fraudulent transaction. The feature set for assessing the risk of an electronic transaction may include various information related to or derived from the electronic transaction, such as the transaction type, transaction amount, user account associated with the transaction, browser type of the browser used to initiate the transaction, device type of the device used to initiate the transaction, Internet Protocol (IP) address of the device used to initiate the transaction, the difference between the transaction amount of the electronic transaction and the average transaction amount of previous transactions involved by the payee of the electronic transaction, the difference between the transaction amount of the electronic transaction and the average transaction amount of previous transactions involved by the payee of the electronic transaction, the average transaction frequency of the payee in the past, and other information related to and / or derived from the electronic transaction. Some features may be more relevant (or more indicative) of assessing the risk of electronic transactions than others. Thus, generating a computer model involves determining which available candidate features should be used in assessing the risk of electronic transactions, and possibly determining weights for the selected candidate features.

[0013] Conventionally, to build a new computer model, a model builder (e.g., a data scientist) at an electronic service provider may test one or more candidate features based on available training data to determine the respective relevance of the candidate features in assessing electronic transaction risk. The training data may include offline transaction data stored in a database system. After selecting a set of candidate features, the computer model may be trained using the available training data stored in the database system. When the computer model is ready, a software developer at the electronic service provider may implement the computer model in an online environment, where the computer model is used to assess electronic transaction requests in real time.

[0014] Building a computer model in this way can be expensive in terms of time and computer processing. One reason may be that accessing transaction data from a database system is slow (e.g., as opposed to accessing data in memory). The time to access transaction data may be further affected because certain features may require accessing transaction data from different records, different tables, and / or different databases. An example feature is a feature that corresponds to the difference between the transaction amount of an electronic transaction and the average transaction amount in previous transactions involving a payee in the electronic transaction. A first query is submitted to a database system to access a record associated with the electronic transaction. Based on the record, the transaction amount of the electronic transaction is determined, and the payee of the electronic transaction is identified. Based on the identified payee, a second query is submitted to the database to access records associated with past electronic transactions involving the payee. The average transaction amount can then be calculated based on the transaction data associated with the record retrieved using the second query. As shown, multiple (e.g., possibly tens or hundreds) different records are accessed from the database system to calculate the value of a feature associated with an electronic transaction. Because hundreds or thousands of electronic transactions may be used to test a particular feature, the time taken to test the feature may be very long.

[0015] Second, the transaction data from the offline database may be different from the transaction data from the online database (e.g., the offline database may store outdated records, such as records from 6 months ago, etc.). Therefore, the training data may not reflect the characteristics of the current trend of fraudulent electronic transactions, and therefore the features selected by the data scientist may not be optimal. In addition, since the testing of the computer model may be performed in an environment different from the online environment (in which the computer model will be used to evaluate real-time electronic transactions), the computer model implemented by the data scientist for testing may have to be implemented differently according to the online environment (e.g., the source code is rewritten by the software developer). As a result, the computer model implemented by the software developer may not accurately capture every aspect of the computer model envisioned by the data scientist. Therefore, the computer model may need to be modified multiple times before it can be used in an online environment.

[0016] Therefore, in some aspects of the present disclosure, a framework is provided to efficiently select, adjust and evaluate candidate features based on online transaction data and implementations of computer models for assessing the risks of electronic transactions. In some embodiments, the framework may provide an interface that enables a user (e.g., a data scientist at an electronic service provider) to select transaction records from an online database as training data for developing a new computer model. For example, the interface may enable a user to select one or more indicators (e.g., transaction type, such as an electronic payment transaction, a login transaction, an onboarding transaction, an add source of funds transaction, etc.) to select records from an online database system. Once the indicator is obtained, the framework may retrieve transaction records from an online database system (e.g., by submitting a query).

[0017] The framework can further enrich the transaction record by obtaining additional data associated with the retrieved transaction record from the online database system. The additional data can include data required to derive one or more characteristics of the transaction record, and can include transaction data from another transaction record. For example, for each selected transaction record, the framework can retrieve transaction data (e.g., transaction amount, transaction date, etc.) of other related transaction records (e.g., other transaction records with the same payer and / or payee as the selected transaction record, other transaction records from devices with the same IP address as the selected transaction record, etc.).

[0018] In some embodiments, the framework may serialize (e.g., flatten) the enriched transaction records. For example, the transaction data of the transaction records may be stored according to a specific data structure in an online database system (e.g., a hierarchy of tables, interlinked data objects, etc.). Thus, the framework may serialize the transaction data from each transaction record by extracting the transaction data from the specific data structure and serializing the transaction data into a string (e.g., a text format), wherein each transaction data segment may be separated from another transaction data segment using a special character (e.g., a comma, etc.). In some embodiments, the serialized transaction data may be stored in a data file (e.g., a text file) such that the transaction data of each transaction record may occupy a single line (e.g., a single row) in the data file. Additional data associated with the transaction record may be attached to the transaction data of the transaction record in the data file. An advantage of serializing the transaction data is that the transaction data and its associated additional data may be subsequently accessed (e.g., accessed multiple times) to efficiently create and evaluate feature candidates without accessing the online database system. Accessing transaction data (and additional data) from a flat data structure (e.g., a text file) is faster than accessing the same data from a database system, which requires submitting multiple queries and retrieving data from multiple data structures (e.g., records and / or tables). In addition, because the transaction data and additional data associated with a transaction record are grouped together (e.g., stored in the same row or line), all relevant information that may be needed to create and evaluate candidate features for the transaction record can be accessed simply by reading the data from the same row or line of the data file without further access to the database system (e.g., an online database system).

[0019] The framework can then provide an interface (e.g., an application programming interface (API)) that enables a data scientist to create, adjust, and / or evaluate candidate features based on data associated with transaction records in a data file. For example, the API can enable a data scientist to access different attributes of a selected transaction record by making different function calls in a software code. In one example, a data scientist can create a candidate feature corresponding to the difference between the transaction amount of an electronic transaction and the average transaction amount in previous transactions involving a payee in the electronic transaction by making the following function calls, which access the transaction amount of each selected transaction and the transaction amount of past transactions involving the payee from the data file. Based on the function calls made through the API, the framework can perform calculations based on the transaction data and additional data associated with the selected transaction record stored in the data file to provide a value corresponding to the candidate feature. Since accessing the transaction data and / or additional data from the data file is faster (e.g., relative to accessing a database system), the value can be quickly provided to the data scientist, and the data scientist can manipulate and / or adjust the candidate features more efficiently.

[0020] By using the API provided by the framework, data scientists can manipulate, test and evaluate feature candidates to determine the feature set to be used in the computer model. Once the feature set and logic for assessing the risk of electronic transactions are determined, the framework can generate and / or configure the computer model based on the feature set and logic. The computer model can be a machine learning model that can be trained using a training data set. Advantageously, the computer model can be generated and / or configured to work with an online database to assess the risk of real-time electronic transactions, thereby eliminating the need for other software developers to convert or additionally implement the computer model. In some embodiments, the framework can also verify the computer model (e.g., test the computer model) by running the computer model on the selected transaction records. For example, the framework can use the computer model to generate a risk score for each selected transaction record, and compare the risk score with a known result (e.g., a predetermined risk score) associated with the selected transaction record.

[0021] However, since the generated computer model is configured to work with an online database system, the computer model can extract data based on a specific data structure associated with the online database system, which is different from the serialization format of the transaction data in the data file. Therefore, the framework of some embodiments can deserialize the transaction data and additional data by storing the transaction data and additional data in a database object (e.g., a record table, a data object, etc.) according to the data structure of the online database system to simulate the online database system. The framework then runs the computer model for each transaction record. For example, the framework can retrieve a first transaction record from the data structure, and can derive a set of values ​​corresponding to a feature set based on the transaction data and / or additional data associated with the first transaction record. The framework can then provide the set of values ​​as input data to the computer model, which can then generate a risk score based on the set of values.

[0022] In some cases, the selected transaction records may include a large number of records (e.g., 10 million transaction records). Therefore, in some embodiments, the framework can perform testing of the computer model on a distributed system. Another benefit of serializing the data and generating a data file is that the data stored for each transaction record (e.g., transaction data and additional data) includes all the information required by the computer model to assess the risk of the transaction record, and the data of each record can be easily separated from each other because the data related to each transaction record is stored together (e.g., in a row or row of a data file). Therefore, the framework can easily divide the transaction records into transaction record groups (e.g., based on data rows or rows in a data file). Then, the framework can distribute the transaction record groups to multiple computer servers. Each computer server can deserialize the corresponding transaction record group of the computer server by storing the transaction data and additional data of the transaction records in the group in a database object according to the data structure of the online database system. Then, each computer server can use a computer model for the transaction records in its corresponding group to generate risk scores for these transaction records. The framework may then aggregate risk scores generated by the computer model from different computer servers and may validate the computer model based on the calculated risk scores.

[0023] In some embodiments, at least a portion of the framework can be implemented on the device used by the data scientist so that the operations of generating the computer model can be performed on the local device used by the data scientist. For example, the data file can be stored in the memory of the local device and can be accessed locally by the framework (as opposed to retrieving the data over the network). In addition, when verifying the computer model, the deserialized data can also be stored in the memory of the local machine. Performing the operations of generating and verifying the computer model by the local device (without accessing the remote database system) further improves the performance of the framework.

[0024] Figure 1 An electronic transaction system 100 according to an embodiment of the present disclosure is shown, in which the framework can be implemented. The electronic transaction system 100 includes a service provider server 130 associated with an electronic service provider, a merchant server 120, and a user device 110, which can be communicatively coupled to each other via a network 160. The service provider server 130 can be communicatively coupled to the device 170 directly or via an internal network associated with the electronic service provider. In one embodiment, the network 160 can be implemented as a single network or a combination of multiple networks. For example, in various embodiments, the network 160 can include the Internet and / or one or more intranets, landline networks, wireless networks, and / or other appropriate types of communication networks. In another example, the network 160 may include a wireless telecommunications network (e.g., a cellular telephone network) suitable for communicating with other communication networks such as the Internet.

[0025] In one embodiment, user 140 may use user device 110 to interact with merchant server 120 and / or service provider server 130 via network 160. For example, user 140 may use user device 110 to log in to a user account opened at an electronic service provider to perform account services or conduct electronic transactions (e.g., electronic payment transactions, add funding source transactions, etc.) with service provider server 130. Similarly, a merchant associated with merchant server 120 may use merchant server 120 to log in to a merchant account opened at an electronic service provider to perform account services or conduct electronic transactions (e.g., electronic payment transactions) with service provider server 130. In various embodiments, user device 110 may be implemented using any suitable combination of hardware and / or software configured for wired and / or wireless communications via network 160. In various implementations, user device 110 may include at least one of a wireless cellular phone, a wearable computing device, a PC, a laptop computer, etc.

[0026] In one embodiment, user device 110 includes user interface application 112 (e.g., web browser, mobile application, etc.) that a user may use to conduct electronic transactions (e.g., sell, shop, purchase, make an offer, perform electronic payments, etc.) with service provider server 130 via network 160. In one aspect, purchases may be debited directly and / or automatically from an account associated with the user via user interface application 112.

[0027] In one implementation, the user interface application 112 includes a software program, such as a graphical user interface (GUI), executable by a processor configured to interface and communicate with the service provider server 130 via the network 160. In another implementation, the user interface application 112 includes a browser module that provides a web interface to browse information available on the network 160. For example, the user interface application 112 may be partially implemented as a web browser for viewing information available on the network 160.

[0028] In various embodiments, the user device 110 may include other applications 116 that may be required in one or more embodiments of the present disclosure to provide additional features that can be used by the user 140. In one example, such other applications 116 may include a security application for implementing client security features, a programming client application for interfacing with an appropriate application programming interface (API) via the network 160, and / or various other types of generally known programs and / or software applications. In other examples, the other applications 116 may interface with the user interface application 112 to improve efficiency and convenience.

[0029] In one embodiment, the user device 110 may include at least one user identifier 114, which may be implemented, for example, as an operating system registry entry, a cookie associated with the user interface application 112, an identifier associated with the hardware of the user device 110 (e.g., a media control access (MAC) address), or various other suitable identifiers. The user identifier 118 may include one or more attributes associated with the user 140 of the user device 110, such as personal information associated with the user (e.g., one or more user names, passwords, photo images, biometric IDs, addresses, phone numbers, social security numbers, etc.) and banking information and / or sources of funds (e.g., one or more banking institutions, credit card issuers, user account numbers, security data and information, etc.). In various implementations, the user identifier 114 may be transmitted to the service provider server 130 via the network 160 along with the user login request, and the user identifier 114 may be used by the service provider server 130 to associate the user with a specific user account maintained by the service provider server 130.

[0030] In various implementations, user 140 can enter data and information into an input component (e.g., a keyboard) of user device 110 to provide user information along with a transaction request, such as a login request, a funds transfer request, a request to add an additional funding source (e.g., a new credit card), or other types of requests. The user information may include user identification information.

[0031] In various embodiments, the user device 110 includes a location component 118, which is configured to determine, track, monitor and / or provide the instantaneous geographic location of the user device 110. In one implementation, the geographic location may include GPS coordinates, zip code information, area code information, street address information, and / or various other generally known types of location information. In one example, the location information may be directly input into the user device 110 by a user through a user input component (e.g., a keyboard, a touch display, and / or a voice recognition microphone). In another example, the location information may be automatically obtained and / or provided by the user device 110 by utilizing an internal or external monitoring component of a global positioning system (GPS) and / or assisted GPS (A-GPS), wherein the global positioning system (GPS) uses satellite-based positioning and assisted GPS (A-GPS) uses cellular tower information to improve the reliability and accuracy of GPS-based positioning. In other embodiments, the location information may be automatically obtained without using GPS. In some cases, a cell signal or a wireless signal is used. For example, location information may be obtained by checking in with a check-in device at a location such as a beacon using user device 110. This helps conserve battery life and allows for better positioning in indoor locations where GPS does not typically work.

[0032] Although in Figure 1 Only one user device 110 is shown in FIG. 1 , but it is contemplated that one or more user devices (each similar to user device 110 ) may be communicatively coupled with service provider server 130 via network 160 within system 100 .

[0033] In various embodiments, the merchant server 120 may be maintained by a business entity (or in some cases, a partner of a business entity that processes transactions on behalf of the business entity). Examples of business entities include merchant websites, resource information websites, utility websites, real estate management websites, social networking websites, etc., which provide various items for purchase and process payments for purchases. The merchant server 120 may include a merchant database 124 that identifies available items that can be provided to the user device 110 for viewing and purchase by the user.

[0034] In one embodiment, the merchant server 122 may include a marketplace application 122 that may be configured to provide information to the user interface application 112 of the user device 110 via the network 160. For example, a user 140 of the user device 110 may interact with the marketplace application 122 via the network 160 through the user interface application 112 to search for and view various items available for purchase in the merchant database 124.

[0035] In one embodiment, the merchant server 120 may include at least one merchant identifier 126, which may be included as part of one or more items available for purchase, such that, for example, a particular item is associated with a particular merchant. In one implementation, the merchant identifier 126 may include one or more attributes and / or parameters associated with the merchant, such as business information and banking information. The merchant identifier 126 may include attributes associated with the merchant server 120, such as identification information (e.g., a serial number, a location address, GPS coordinates, a network identification number, etc.).

[0036] Merchants may also use merchant server 120 to communicate with service provider server 130 over network 160. For example, merchants may use merchant server 120 to communicate with service provider server 130 in the process of the service provider providing various services to merchants (e.g., payment intermediary between the merchant's consumers and the merchant itself). For example, merchant server 120 may use an application programming interface (API) that allows merchant server 120 to offer item sales, where consumers are allowed to pay through service provider server 130, and user 140 may have an account opened at service provider server 130 that allows user 140 to use service provider server 130 to make payments to merchants that are allowed to use the service provider's authentication, authorization, and payment services as a payment intermediary. Merchants may also have accounts opened at service provider server 130. Although in Figure 1 Only one merchant server 120 is shown in FIG. 1 , but it is contemplated that one or more merchant servers (each similar to merchant server 120 ) may be communicatively coupled with service provider server 130 and user device 110 via network 160 in system 100 .

[0037] In one embodiment, the service provider server 130 may be maintained by a transaction processing entity or an electronic service provider that can provide electronic services (e.g., sales product processing, purchase of products, execution of electronic transactions, etc.). Therefore, the service provider server 130 may include a service application 138, which may be adapted to interact with the user device 110 and / or the merchant server 120 via the network 160 to facilitate the execution of searching, selecting, purchasing, paying for items, and / or other services provided by the service provider server 130. In one example, the service provider server 130 may be provided by a San Jose, California, USA The point-of-sale devices may be provided by the Company and / or one or more financial institutions or corresponding intermediaries, which may provide multiple point-of-sale devices in various locations to facilitate transaction routing between merchants and, for example, financial institutions.

[0038] In some embodiments, the service applications 138 may include a payment processing application (not shown) for processing purchases and / or payments for financial transactions between users and merchants. In one implementation, the payment processing application assists in resolving financial transactions through verification, delivery, and settlement. Thus, the payment processing application settles debts between users and merchants, where accounts can be debited and / or credited with monetary funds directly and / or automatically in a manner accepted by the banking industry.

[0039] The service provider server 130 may also include a web server 134 that is configured to interact with the web browser of the user device 110 by providing web content to the user in response to HTTP requests. Thus, the web server 134 may include pre-generated web content that is ready to be provided to the user. For example, the web server 134 may store a login page, and the web server 134 is configured to provide the login page to the user for logging into the user's user account to access the various services provided by the service provider server 130. The web server 134 may also include other web pages associated with different electronic services provided by the service provider server 130. Thus, by generating an HTTP request directed to the service provider server 130, the user can access the user account associated with the user and access the various services provided by the service provider server 130.

[0040] In one embodiment, the service provider server 130 may be configured to maintain one or more user accounts, merchant accounts, and transaction records in an account database 136. Thus, the account database may store account information associated with one or more individual users (e.g., user 140 associated with user device 110) and merchant and transaction data associated with a transaction. For example, the account information may include private financial information of the user and the merchant, such as one or more account numbers, passwords, credit card information, bank information, digital wallets used, or other types of financial information. The transaction record may include an Internet Protocol (IP) address, device information associated with the transaction, transaction date, transaction amount, payer identity, payee identity, and the like. In some embodiments, the account information also includes user purchase profile information, such as account funding options and payment options associated with the user, payment information, receipts, and other information collected in response to completed funding and / or payment transactions.

[0041] In one implementation, a user may have identity attributes stored by the service provider server 130, and the user may have credentials for authenticating or verifying identity at the service provider server 130. User attributes may include personal information, bank information, and / or a source of funds. In various aspects, the user attributes may be passed to the service provider server 130 as part of a login, search, selection, purchase, and / or payment request, and the service provider server 130 may utilize the user attributes to associate the user with one or more specific user accounts maintained by the service provider server 130.

[0042] In various embodiments, the service provider server 130 includes a risk analysis module 132 that is configured to determine whether to authorize or deny an incoming request from the user device 110 or from the merchant server 120. The request may be a login request, an electronic payment request, a request to add an additional source of funds, a boot request, or other types of requests associated with various electronic services provided by the service provider server 130. Thus, when a new request is received at the service provider server 130 (e.g., received by the network server 134), the risk analysis module 132 may analyze the request (e.g., based on information stored in the account database 136) and determine whether to authorize or deny the request. The risk analysis module 132 may send an indication of whether to authorize or deny the request to the network server 134 and / or the service application 138 so that the network server 134 and / or the service application 138 may process the request based on the indication.

[0043] Figure 2A block diagram of a risk analysis module 132 according to an embodiment of the present disclosure is shown. The risk analysis module 132 includes a model generation module 204 for generating a risk analysis model 202. The risk analysis model 202 is a computer model that performs the following operations: receives data related to an electronic transaction request, such as a login request, an electronic funds transfer (e.g., a payment) request, or a request to add an additional source of funds to a user account; analyzes the data; and generates a result (e.g., a risk score) for the request based on a determination of whether the request is likely to be a fraudulent request. The data received by the risk analysis model 202 may correspond to a set of features (e.g., features F1, F2, F3, etc.) determined to be used by the risk analysis model 202.

[0044] As described above, malicious users often use different fraudulent strategies to perform unauthorized transactions (e.g., using another user's account to perform electronic transactions without authorization, etc.). For example, a malicious user may use phishing techniques or man-in-the-middle attacks to obtain user credentials associated with a user account. Typically, a transaction request initiated by a malicious user (unauthorized user) may provide a clue that the request was not generated by an authorized user. For example, a transaction request initiated by an unauthorized user often has characteristics that are different from past transaction requests generated by legitimate users. These characteristics may include the location where the request was generated (e.g., indicated by the IP address of the device that initiated the request), the type of device used to initiate the request, the type of browser used to initiate the request, etc. In addition, because a malicious user may not have access to all user credentials, the malicious user may make multiple failed login attempts before "guessing" the correct user credentials. Therefore, the number of failed login attempts over a period of time may indicate that the request is a fraudulent request. The behavior of a malicious user may also be different from that of a legitimate user. Therefore, any deviation from the "normal" behavior of an account (e.g., a transaction amount that differs from the average transaction amount by a threshold amount, etc.) may also indicate that the transaction request may correspond to a fraudulent transaction request.

[0045] Thus, the risk analysis model 202 may obtain data (e.g., features) associated with the electronic transaction request, which may include the IP address of the source device, the device type of the source device, the number of successful transactions performed for the user account over a period of time, the number of failed transactions attempted using the user account over a period of time, the current time, the browser type of the browser used to generate the request, the amount associated with the request, the transaction type of the request, the average transaction amount associated with the payer / payee over a predetermined time period, and other information associated with the request. In some embodiments, the risk analysis model 202 is trained or configured to predict whether the request is a possible fraudulent request based on the received data. Thus, the result generated by the risk analysis model 202 may be a binary result, which is a possible fraudulent request or a legitimate request. In some embodiments, the result may be a score (e.g., a risk score) indicating the likelihood that the transaction request is a fraudulent request. The risk analysis module 132 may then provide an indication of the result generated by the risk analysis model 202 to other modules or servers within the service provider server 130, such as the network server 134 and / or the service application 138, so that these other modules can process the transaction request accordingly.

[0046] Figure 3 A block diagram of the model generation module 204 according to an embodiment of the present disclosure is shown. The model generation module 204 includes: a model generation manager 302, configured to retrieve transaction records from an online database (e.g., the account database 136); a data enrichment module 304, configured to enrich the transaction data in each retrieved transaction record with additional data obtained from at least one other transaction record in the account database 136; an application programming interface (API) 306, provided to enable a user (e.g., a data scientist) to create, adjust, and evaluate candidate features based on the retrieved transaction data and additional data; and a feature export module 306, configured to export a feature set from the candidate features for use in a risk analysis model (e.g., the risk analysis model 202).

[0047] Figure 4A process 400 for generating a risk analysis model according to an embodiment of the present disclosure is shown. In some embodiments, the process 400 may be performed by the model generation module 204. The process 400 begins by obtaining (step 405) a set of transaction records associated with a set of transactions from a database. For example, the model generation manager 302 may determine a set of indicators for selecting transaction records from the account database 136. In some embodiments, the model generation manager 302 may provide an interface to a user of the device 170 to enable the user to select one or more indicators (e.g., transaction types). For example, the user may indicate one or more transaction types to the model generation manager 302, such as an electronic payment transaction type, a login transaction type, a guide transaction type, an add funding source transaction type, etc. Once the model generation manager 302 determines the indicator set, the model generation manager 302 may retrieve transaction records (e.g., transaction records 322-328) that meet the indicator set from the account database 136. In some embodiments, the model generation manager 302 may generate a database query (e.g., a structured query language (SQL) query) based on the indicator set, and may execute the query against the account database 136. In response to executing the query, the account database 136 may provide transaction records that satisfy the set of indicators to the model generation manager 302. For example, if the set of indicators indicates an electronic payment transaction type, each retrieved transaction record may include transaction data associated with the electronic payment transaction (e.g., transaction date, transaction amount, payer identifier, payee identifier, transaction location, etc.).

[0048] Then, the process 400 serializes (step 410) the transaction data from the set of transaction records. As discussed herein, the transaction data of the transaction records may be stored in an account database according to a predetermined data structure. For example, the transaction data of each transaction record may be stored in a different table, in a different database (e.g., in a relational database system), in different interlinked data objects, etc. In some embodiments, upon receiving the transaction records (e.g., transaction records 322-328), the model generation manager 302 may serialize (e.g., flatten) the transaction records by extracting the transaction data from a specific data structure and serializing the transaction data into a string (e.g., text format), wherein each transaction data segment may be separated from another transaction data segment using a special character (e.g., a comma, etc.). In some embodiments, the serialized transaction data may be stored in a data file (e.g., a text file) such that the transaction data of each transaction record may occupy a single line (e.g., a single row) in the data file. Different transaction records may be separated in the data file 330 by another special character (e.g., a carriage return). The flattened (eg, serialized) transaction data enables the model generation module 204 to access the transaction data in the data file 330 faster than accessing the transaction data from the account database 136 .

[0049] The process 400 enriches (step 415) a collection of transaction records. For example, the data enrichment module 304 may enrich the transaction data of each transaction record with additional data obtained from one or more other transaction records of the account database 136. The additional data may include data required to derive one or more characteristics of the transaction record, and may include transaction data from another transaction record. In some embodiments, for each transaction record, the data enrichment module 304 may extract one or more attributes from the transaction data associated with the transaction record, and may obtain additional data from one or more other transaction records based on the extracted attributes. For example, when the transaction record corresponds to an electronic payment transaction, the data enrichment module 304 may extract a payer identifier and a payee identifier from each transaction record. The data enrichment module 304 may then retrieve transaction data for past transactions involving the same payer and / or payee. Thus, the data enrichment module 304 may generate a query (e.g., an SQL query) to retrieve transaction data (e.g., transaction amount, transaction date, etc.) of the transaction record based on the payer identifier and / or payee identifier extracted from the transaction record as additional data for the transaction record. The data enrichment module 304 can perform the same process of extracting attributes and retrieving additional data for each transaction record in the data file. When the transaction data (e.g., additional data) of other transaction records is obtained from the account database 136, the data enrichment module 304 can add the additional data to the transaction data of the transaction records stored in the data file 330. For example, the data enrichment module 304 can append the additional data associated with each transaction record at the end of the transaction data of the transaction records in the data file 330. Therefore, each line (or each row) in the data file 330 can include transaction data associated with the transaction record and additional data. Different additional data can also be separated by special characters (e.g., commas). In this way, all the information required for calculating the input value (corresponding to the feature) of the risk analysis model for the transaction record can be obtained in the same line (or the same row) of the data file 330.

[0050] After enriching the transaction records, the process 400 derives (step 420) one or more features based on analyzing the enriched set of transaction records. In some embodiments, the model generation module 204 may provide an API 306 that enables a user of the device 170 to access various data in the data file 330 to create, adjust, and / or evaluate various candidate features. For example, the API 306 may enable a user of the device 170 to access different data based on data types (e.g., transaction date, transaction amount, payee identifier, etc.) so that the user of the device 170 does not need to know the data structure of the data file 330. In addition, based on a request submitted through the API 306, the model generation module 204 may also calculate one or more values ​​corresponding to a specific feature based on the transaction data and / or additional data associated with the transaction record. For example, a user of the device 170 may submit a request to generate a feature (e.g., a feature candidate) through the API 306, which corresponds to the difference between the transaction amount of the electronic transaction and the average transaction amount in previous transactions involving the payer and / or payee in the electronic transaction. Based on the request, the feature derivation module 308 can access different transaction data associated with each transaction record (e.g., the transaction amount of the transaction record and the transaction amount of previous transactions associated with the payer and / or the payee). Then, for each transaction record, the feature derivation module 308 can calculate a value corresponding to the feature candidate by performing calculations on some of the transaction data associated with the transaction record. Then, the model generation module 204 can provide the calculated value to the user through the device 170.

[0051] By using the API 306, the user of the device 170 can create different candidate features, adjust the candidate features, and evaluate the candidate features (e.g., by reviewing the calculated values ​​corresponding to the features and determining the degree to which the features indicate the risk of the transaction record). Once the user determines the final set of features to be used in the risk analysis model 202 (e.g., the IP address of the device initiating the transaction, the transaction amount, the type of browser used to initiate the transaction, the difference between the transaction amount of the electronic transaction and the average transaction amount in previous transactions involving the payer in the electronic transaction, etc.), the model generation manager 302 can generate or configure the risk analysis model 202 based on the feature set. For example, the model generation manager 302 can generate or configure the risk analysis model 202 so that the risk analysis model 202 extracts input data corresponding to the feature set associated with the transaction request and generates a result (e.g., a risk score) indicating the risk of the transaction request.

[0052] Figure 5An example implementation of the risk analysis model 202 is shown. In this example, the risk analysis model 202 is implemented as an artificial neural network 500 for assessing the risk of an electronic transaction request. As shown, the artificial neural network 500 includes three layers: an input layer 502, a hidden layer 504, and an output layer 506. Each layer in the layers 502, 504, and 506 may include one or more nodes. For example, the input layer 502 includes nodes 508-514, the hidden layer 504 includes nodes 516-518, and the output layer 506 includes a node 522. In this example, each node in a layer is connected to each node in an adjacent layer. For example, the node 508 in the input layer 502 is connected to both nodes 516 and 518 in the hidden layer 504. Similarly, the node 516 in the hidden layer is connected to all nodes 508-514 in the input layer 502 and the node 522 in the output layer 506. Although only one hidden layer is shown for the artificial neural network 500, it is contemplated that the artificial neural network 500 generated or configured by the model generation module 204 may include a desired number of hidden layers.

[0053] In this example, the artificial neural network 500 is configured to receive a set of input values ​​corresponding to a feature set (e.g., I1, I2, I3, I4, etc.) and generate an output value. Each node in the input layer 502 may correspond to a different input value. Therefore, the model generation module 204 may configure the nodes 508-514 in the input layer 502 of the artificial neural network 500 to correspond to a feature set derived by the feature export module 308. For example, node 508 may correspond to a feature of the IP address of the device initiating the transaction, node 710 may correspond to a feature of the transaction amount, node 712 may correspond to a feature of the browser type used to initiate the transaction, and node 714 may correspond to a feature of the difference between the transaction amount of the electronic transaction and the average transaction amount in previous transactions involving the payer in the electronic transaction.

[0054] Although only four input nodes are shown to be included in the artificial neural network 500, the model generation module 204 can generate or configure the risk analysis model 202 to include more (or fewer) input nodes based on the number of features determined by the feature derivation module 308. In some embodiments, each node 516-518 in the hidden layer 504 generates a representation, which can include a mathematical calculation (or algorithm) that generates a value based on the input value received from the node 508-514. The mathematical calculation can include assigning different weights to each data value received from the node 508-514. Nodes 516 and 518 can include different algorithms and / or weights assigned to data variables from nodes 508-514, so that nodes 516-518 can generate different values ​​based on the same input value received from the node 508-514. In some embodiments, the weights initially assigned to each of the nodes 516 and 518 can be randomly generated (e.g., using a computer randomizer). The values ​​generated by nodes 516 and 518 may be used by node 522 in output layer 506 to generate an output value for artificial neural network 500. In some embodiments, the output value generated by artificial neural network 500 may indicate a likelihood that the electronic transaction request corresponds to a fraudulent transaction request.

[0055] The artificial neural network 700 can be trained by using historical electronic transaction data (training data). The historical electronic transaction data may include transaction records of different time periods in the past (e.g., July 2016 to March 2017, July 2015 to March 2016, July 2014 to March 2015, etc.). By providing the training data to the artificial neural network 500, the nodes 516 and 518 in the hidden layer 504 can be trained (adjusted) so that the best output (the likelihood that the electronic transaction request corresponds to a fraudulent transaction request) is generated in the output layer 506 based on the training data. By continuously providing different training data sets and penalizing the artificial neural network 500 when the output is incorrect, the artificial neural network 500 (specifically, the representation of the nodes in the hidden layer 504) can be trained (adjusted) to improve its performance in detecting fraudulent electronic transaction requests over time. Adjusting the artificial neural network 500 may include adjusting the weights associated with each node in the hidden layer 504.

[0056] Return to reference Figure 4, the process 400 then deserializes (step 425) the enriched set of transaction records and uses (step 430) the deserialized enriched set of transaction records to evaluate one or more features. For example, the model generation module 204 can use the transaction records retrieved from the account database 136 to verify (e.g., test) the risk analysis model 202 to determine that the performance (e.g., accuracy in detecting fraudulent transaction requests) is above a predetermined threshold. As discussed herein, one benefit of using the framework to generate a risk analysis model is that the generated model can be seamlessly incorporated into an online system without converting from one implementation to another (e.g., changing software code). In this way, the generated risk analysis model 202 can be configured to extract input data according to a specific data structure associated with the online system (e.g., the same data structure as the data structure in the account database 136), which is different from the data structure of the data file 330 (which can be a flat data structure or no data structure). Thus, in order for the risk analysis model 202 to extract the transaction data associated with the transaction record, the model generation manager 302 may deserialize the transaction data in the data file 330 by: generating a data structure (e.g., in a random access memory (RAM) of the device) that simulates a specific data structure of the account database 136; and inserting the transaction data from the data file 330 into the generated data structure. In some embodiments, even if the transaction data is formatted (e.g., arranged) according to the specific data structure, the transaction data remains in the RAM of the device (as opposed to being stored in an actual database system), and the transaction data can be accessed relatively quickly. In this way, the risk analysis model 202 can access the transaction data from the data structure as if it were accessing the account database 136, but without accessing the actual database system. Thus, the risk analysis model 202 may be used to evaluate the transaction record by: accessing the transaction data in a deserialized format; calculating input values ​​corresponding to the features determined at step 420 based on the transaction data; and generating output based on the input values ​​without accessing the database system. The generated output (eg, a risk score, an indication of whether a transaction request corresponds to a fraudulent request, etc.) may be compared to known results of whether transactions correspond to fraudulent transactions to validate the risk analysis model 202 .

[0057] At step 435, the process 400 configures the machine learning model to evaluate future transactions based on the derived one or more features. For example, after validating the risk analysis module 202, the model generation module 204 can send the risk analysis model 202 to the service provider server 130 for use by the risk analysis module 132 to evaluate incoming transaction requests (e.g., requests from the user device 110 and / or the merchant server 120) based on the set of features determined by the model generation module 204.

[0058] In some embodiments, the model generation module 204 may be implemented within the service provider server 130, and the user of the device 170 may access the functionality of the model generation module 204 (e.g., to create / evaluate features, generate / configure risk analysis models) by connecting to the service provider server 130, such that most operations of the model generation module 204 are performed at the service provider server 130. Alternatively, at least a portion of the model generation module 204 may be implemented within the device 170, such that operations of generating a computer model may be performed on a local device used by a data scientist. Advantageously, after retrieving the transaction data and additional data from the account database 136, the transaction data and additional data (e.g., stored in a serialized format in a data file 330) may be stored in a local device (e.g., device 170) and accessed locally by the model generation module 204 (without accessing data from a remote device). In addition, when validating the computer model, the deserialized data may also be stored in the memory of the local machine. The performance of the framework is further improved by performing the operations of generating and validating the computer model on a local device without requiring access to a remote database system.

[0059] In addition, since the transaction data and additional data of each transaction record are stored in a serialized format, the information required to evaluate different transaction records can be easily separated from each other. Therefore, the model generation manager 302 can divide the data associated with the transaction records in the data file 330 into multiple transaction record groups. One of the benefits of dividing the data associated with the transaction records into multiple groups is that the validation of the risk analysis model 202 can be accelerated by using multiple devices (e.g., multiple servers) to validate the risk analysis model 202 in parallel. For example, Figure 6As shown, the model generation module 204 can divide the data associated with the transaction records in the data file 330 into multiple data files (e.g., data files 622-626), each of which includes a different transaction record group (e.g., transaction data and additional data associated with the transaction record group). Then, the model generation module 204 can send the data files 622-626 to the devices 602-606 respectively. For example, the model generation module 204 can send the data file 622 storing the transaction data and additional data associated with the first transaction record group to the device 602. The model generation module 204 can send the data file 624 storing the transaction data and additional data associated with the second transaction record group to the device 604. The model generation module 204 can send the data file 626 storing the transaction data and additional data associated with the third transaction record group to the device 606. The model generation module 204 can also send the risk analysis module 202 to each of the devices 602-606, so that each of the devices 602-606 can use the corresponding data file to verify the risk analysis model 202. Since the validation of the risk analysis model 202 can be performed in parallel across multiple devices, the validation can be completed much faster than if it were performed by a single device. In some embodiments, each of the devices 602-606 can compare the output generated by the risk analysis model 202 with known results and then return a summary (e.g., a comparison report) to the model generation module 204. In some embodiments, the devices 602-606 can simply send the output of the risk analysis model 202 back to the model generation module 204, and the model generation module 204 can validate the risk analysis model 202 by comparing the output with the known results.

[0060] Therefore, by using the framework disclosed herein, risk analysis models can be generated faster than using traditional methods, so that updated risk analysis models can be implemented in online systems with shorter turnaround time, thereby providing better performance when assessing the risk of transaction requests.

[0061] Figure 7 7 is a block diagram of a computer system 700 suitable for implementing one or more embodiments of the present disclosure, including a service provider server 130, a merchant server 120, a user device 110, and a device 170. In various implementations, each of the user device 110 and the device 170 may include a mobile cellular phone suitable for wireless communication, a personal computer (PC), a laptop computer, a wearable computing device, etc., and each of the service provider server 130 and the merchant server 120 may include a network computing device (e.g., a server). Therefore, it should be understood that the devices 110, 120, 130, and 170 may be implemented as the computer system 700 in the following manner.

[0062] The computer system 700 includes a bus 712 or other communication mechanism for transmitting information data, signals and information between the various components of the computer system 700. These components include an input / output (I / O) component 704, which processes user (i.e., sender, receiver, service provider) actions (e.g., selecting a key on a keypad / keyboard, selecting one or more buttons or links, etc.) and sends corresponding signals to the bus 712. The I / O component 704 may also include output components, such as a display 702 and a cursor control 708 (e.g., keyboard, keypad, mouse, etc.). The display 702 may be configured to present a login page for logging into a user account or a checkout page for purchasing items from a merchant. An optional audio input / output component 706 may also be included to allow a user to use voice input information by converting an audio signal. The audio I / O component 706 may allow a user to hear audio. The transceiver or network interface 720 transmits and receives signals between the computer system 700 and other devices such as another user device, a merchant server, or a service provider server via a network 722. In one embodiment, the transmission is wireless, but other transmission media and methods may also be suitable. The processor 714, which may be a microcontroller, digital signal processor (DSP), or other processing component, processes these various signals, such as for display on the computer system 900 or for transmission to other devices via the communication link 724. The processor 914 may also control the transmission of information (e.g., cookies or IP addresses) to other devices.

[0063] Components of computer system 700 also include system memory component 710 (e.g., RAM), static storage component 716 (e.g., ROM), and / or disk drive 718 (e.g., solid state drive, hard disk drive). Computer system 700 performs specific operations of processor 714 and other components by executing one or more instruction sequences contained in system memory component 710. For example, processor 714 can perform the risk analysis model generation function described herein according to process 400.

[0064] The logic may be encoded in a computer readable medium, which may refer to any medium that participates in providing instructions to the processor 714 for execution. Such media may take a variety of forms, including, but not limited to, non-volatile media, volatile media, and transmission media. In various implementations, non-volatile media include optical or magnetic disks, volatile media include dynamic memory (e.g., system memory component 710), and transmission media include coaxial cables, copper wires, and optical fibers (including the wires that make up bus 712). In one embodiment, the logic is encoded in a non-transitory computer readable medium. In one example, the transmission medium may take the form of sound waves or light waves, such as those generated during radio wave, optical, and infrared data communications.

[0065] Some common forms of computer readable media include, for example, floppy disks, diskettes, hard disks, magnetic tape, any other magnetic medium, CD-ROMs, any other optical medium, punch cards, paper tape, any other physical medium with patterns of holes, RAM, PROM, EPROM, FLASH-EPROM, any other memory chip or cartridge, or any other medium suitable for reading by a computer.

[0066] In various embodiments of the present disclosure, the execution of the instruction sequences implementing the present disclosure may be performed by a computer system 700. In various other embodiments of the present disclosure, multiple computer systems 700 coupled to a network (e.g., a LAN, WLAN, PTSN, and / or various other wired or wireless networks (including telecommunications, mobile and cellular telephone networks)) via a communication link 724 may coordinately execute instruction sequences to implement the present disclosure.

[0067] In appropriate cases, the various embodiments provided by the present disclosure can be implemented using hardware, software, or a combination of hardware and software. In addition, in appropriate cases, the various hardware components and / or software components described herein can be combined into a composite component including software, hardware, and / or both, without departing from the spirit of the present disclosure. In appropriate cases, the various hardware components and / or software components described herein can be separated into subcomponents including software, hardware, or both, without departing from the scope of the present disclosure. In addition, in appropriate cases, it is envisioned that software components can be implemented as hardware components, and vice versa.

[0068] Software (e.g., program code and / or data) according to the present disclosure may be stored on one or more computer-readable media. It is also contemplated that the software identified herein may be implemented using one or more general or special-purpose computers and / or computer systems, in a networked manner, and / or in other ways. Where appropriate, the order of the various steps described herein may be changed, combined into composite steps, and / or separated into sub-steps to provide the features described herein.

[0069] The various features and steps described herein may be implemented as a system, including one or more memories storing various information described herein, one or more processors coupled to the one or more memories, and a network, wherein the one or more processors may be used to perform the steps described herein, and a non-transitory machine-readable medium includes a plurality of machine-readable instructions that, when executed by the one or more processors, are adapted to cause the one or more processors to perform methods including the steps described herein, as well as methods performed by one or more devices (e.g., hardware processors, user devices, servers, and other devices described herein).

Claims

1. A device for risk assessment, comprising: non-transitory memory; as well as one or more hardware processors coupled to the non-transitory memory and configured to read instructions from the non-transitory memory to cause the device to perform operations including: Obtaining a transaction record set associated with the transaction set from a remote database system; Generating an enriched transaction record set for each specific transaction record in the transaction record set by: (i) retrieving additional transaction data from at least one other transaction record from the remote database system based on an attribute of the specific transaction record, and (ii) appending the additional transaction data to the specific transaction record; serializing the enriched transaction record set to separate transaction records in the transaction record set from each other; The following steps are performed without further access to the remote database system: deriving one or more features for evaluating a transaction by analyzing the serialized enriched set of transaction records, wherein the one or more features include a first feature derived based on at least a portion of the additional transaction data; deserializing the serialized enriched transaction record set to generate a deserialized transaction record set; evaluating the derived one or more features using the deserialized set of transaction records; and A machine learning model is configured to evaluate a transaction request based on the derived one or more features.

2. The device according to claim 1, wherein: The operations also include: receiving a selection from a user of a first transaction type from among a plurality of transaction types; and The transaction set is determined from a plurality of transactions based on the first transaction type.

3. The device according to claim 1, wherein: The transaction record set is stored in the remote database system according to the first data structure, wherein the operation further comprises: The enriched set of transaction records is serialized by storing the transaction data in the enriched set of transaction records in a data file according to a second data structure, wherein the enriched set of transaction records is generated by inserting the additional transaction data into the data file.

4. The device according to claim 3, wherein: The machine learning model is configured to extract transaction data based on the first data structure, and wherein the operations further include: Deserializing the transaction data in the data file according to the first data structure; and The machine learning model is validated based on the deserialized transaction data.

5. The device according to claim 4, wherein: The transaction data is deserialized in the local memory of the device without accessing the remote database system.

6. The device according to claim 1, wherein: Exporting the one or more features includes providing an interface for a user to manipulate transaction data in the enriched set of transaction records.

7. The device according to claim 1, wherein: Deriving the one or more features includes: calculating values ​​corresponding to the one or more features based on at least a portion of transaction data associated with transaction records in the enriched set of transaction records; and Determining the value is indicative for evaluating a transaction associated with the transaction record.

8. The device according to claim 1, wherein: The set of transaction records includes a first transaction record associated with a first transaction, wherein the first transaction record includes information associated with a first user, the first user is a payee in the first transaction, and wherein generating the enriched set of transaction records includes retrieving transaction data associated with a second transaction record for the first transaction record, the second transaction record being associated with a second transaction in which the first user is also a payee.

9. The device according to claim 1, wherein: The operations also include evaluating the set of transaction records using the derived one or more features.

10. The device according to claim 9, wherein: Using the derived one or more features to evaluate the transaction record set includes: Dividing the serialized enriched transaction record set into a plurality of transaction record groups; sending the plurality of transaction record groups to a plurality of servers respectively; and Cause each of the plurality of servers to evaluate the one or more features by running the machine learning model on a corresponding set of transaction records.

11. A method for risk assessment, comprising: Obtaining a transaction record set associated with the transaction set from a remote database system; Generating an enriched transaction record set for each specific transaction record in the transaction record set by: (i) retrieving additional transaction data from at least one other transaction record from the remote database system based on an attribute of the specific transaction record, and (ii) appending the additional transaction data to the specific transaction record; serializing the enriched transaction record set to generate serialized transaction records to separate transaction records in the transaction record set from each other; providing an application programming interface (API) to derive a feature set based on analyzing the serialized transaction records; deserializing the serialized enriched transaction record set to generate a deserialized transaction record set; Using the deserialized set of transaction records to evaluate the derived set of features; as well as Configure a machine learning model to evaluate transaction requests based on the derived set of features.

12. The method according to claim 11, further comprising: Validating the machine learning model.

13. The method according to claim 12, wherein: Validating the machine learning model includes: dividing the serialized transaction records into a plurality of serialized transaction record groups, wherein each serialized transaction record group includes transaction data and additional data associated with a subset of the set of transaction records; sending the plurality of serialized transaction record groups to a plurality of servers respectively; and Cause each of the plurality of servers to use the machine learning model to evaluate a corresponding subset of the set of transaction records based on the derived set of features.

14. The method according to claim 11, further comprising: receiving a selection of a first transaction type from a plurality of transaction types from a user; as well as The transaction set is determined from a plurality of transactions based on the first transaction type.

15. The method according to claim 11, further comprising: receiving a feature definition via the API; retrieving transaction data and additional data associated with a first transaction record from the serialized transaction record; calculating a value corresponding to the feature based on at least a portion of the transaction data and the additional data associated with the first transaction record; as well as Renders the value on the device.

16. The method according to claim 11, wherein: Exporting the feature set and configuring the machine learning model are performed without further accessing the remote database system.

17. A non-transitory machine-readable medium having machine-readable instructions stored thereon, the machine-readable instructions being executable to cause a machine to perform operations comprising: Obtaining a transaction record set associated with the transaction set from a remote database system; Generating an enriched transaction record set for each specific transaction record in the transaction record set by: (i) retrieving additional transaction data from at least one other transaction record from the remote database system based on an attribute of the specific transaction record, and (ii) appending the additional transaction data to the specific transaction record; serializing the enriched transaction record set to separate transaction records in the transaction record set from each other; The following steps are performed without further access to the remote database system: deriving one or more features for evaluating a transaction by analyzing the serialized enriched set of transaction records, wherein the one or more features include a first feature derived based on at least a portion of the additional transaction data; deserializing the serialized enriched transaction record set to generate a deserialized transaction record set; evaluating the derived one or more features using the deserialized set of transaction records; and A machine learning model is configured to evaluate a transaction request based on the derived one or more features.

18. The non-transitory machine-readable medium of claim 17, wherein: The operations also include: receiving a selection from a user of a first transaction type from among a plurality of transaction types; and The transaction set is determined from a plurality of transactions based on the first transaction type.

19. The non-transitory machine-readable medium of claim 17, wherein: The transaction record set is stored in the remote database system according to the first data structure, wherein the operation further comprises: The enriched set of transaction records is serialized by storing the transaction data in the enriched set of transaction records in a data file according to a second data structure, wherein the enriched set of transaction records is generated by inserting the additional transaction data into the data file.

20. The non-transitory machine-readable medium of claim 19, wherein: The machine learning model is configured to extract transaction data based on the first data structure, and wherein the operations further include: Deserializing the transaction data in the data file according to the first data structure; and The machine learning model is validated based on the deserialized transaction data.

Images