Cross-network evaluation of transactions regarding provider reputation

Abstract

A management system for cross-network evaluation of transactions with respect to provider reputation receives a provider string associated with a provider identity and including a provider score. A potential seller identification code is determined from a set of known seller identification codes taking into account the provider identity extracted from the provider string. At least one transaction associated with the potential seller identification code can be identified by analyzing transaction data stored in a structured data resource associated with the management system. A transaction score is assigned to each transaction associated with the potential seller identification code taking into account the provider score. The transaction scores are stored. Seller statistics are determined by analyzing the transactions.

Description

[Technical field]

[0001] The present disclosure relates to cross-network evaluation of transactions with respect to provider reputation.

[0002] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims the benefit of U.S. Patent Application No. 17 / 692,453, filed March 11, 2022, the entire contents of which are incorporated by reference for all purposes. [Background technology]

[0003] Digital currencies, such as cryptocurrencies, are becoming increasingly widely accepted as a form of payment in financial transactions. Traditional payment methods used in financial transactions include credit cards, debit cards, or other types of payments. These traditional payment methods typically use fiat currencies. Fiat currencies are government-issued currencies that are not backed by a physical commodity, such as gold or silver, and are backed by the government that issued them. Digital currencies can also be purchased or otherwise exchanged / traded for fiat currencies in financial transactions.

[0004] Once a purchase is made for digital currency, the transaction with respect to the digital currency is recorded on the blockchain. The digital currency can then be used later for transactions (or other activities) on various blockchain networks. Although it is possible to use digital currency towards the purchase of goods and services, because the transaction is made on the blockchain network, information regarding the digital currency exchange may not be readily available or traceable by traditional means available to financial institutions. In contrast, transactions completed using traditional payment methods (e.g., payments made using credit cards, bank cards, etc.) are usually traceable by financial institutions such as banks or government agencies to prevent fraudulent activity. When an exchange is made on the blockchain (i.e., involving blockchain-to-blockchain activity), multiple networks may be involved. With respect to digital currency transactions, blockchains, banks, and payment rail networks may share no or limited information with each other. Thus, financial parties such as banks or other institutions may not be able to easily determine the risks associated with a digital currency transaction or the reputation of the parties involved in the digital currency transaction, especially for transactions that are deployed across different networks.

[0005] As digital currencies such as cryptocurrencies gain wider acceptance in the financial industry, it becomes more important for merchants and financial entities to support such digital currency exchanges. Also, since most financial services are regulated with guidelines including standards such as Know Your Customer (KYC), it can be important to assess the risks involved in such digital currency exchange transactions. Summary of the Invention

[0006] A cross-network evaluation of transactions with respect to provider reputation is described in this disclosure. Provider reputation is useful to entities or institutions such as acquirers, issuers, and banks. Such entities can use provider reputation to determine which providers offering digital currency exchanges, as well as which cards used to participate in digital currency exchanges, are trustworthy.

[0007] Card issuers, acquirers, and / or financial institutions (e.g., banks) or service companies may want to determine the reputation of providers of digital currency, as well as the reputation of cards and / or customers utilizing cards involved in digital currency transactions. Reputation is important to issuers, acquirers, and / or financial institutions (e.g., banks) because these entities can use reputation to evaluate providers or card users (e.g., to determine whether it is good to do business with a provider offering digital currency). Such evaluations, which may also be referred to as risk evaluations, may be used to determine the amount of digital currency involved in a transaction, to determine who the entities involved in the transaction are, and other information that can be inferred from the evaluations. Providers with good reputations may be good parties to transact with. Provider and card reputations may be determined by management systems on the payment network, which perform operations to rank and weight transactions to determine reputations used for risk evaluation.

[0008] The system relates to a provider string associated with a provider identity and comprising a provider score. The provider string may be provided by an entity that evaluates blockchain risk. The provider identity is extracted from the provider string by the management system. A potential merchant identity code is determined from a set of known merchant identity codes taking into account the provider identity. At least one transaction associated with the potential merchant identity code is identified by analyzing transaction data that may be stored in a structured data resource associated with the management system. A transaction score is assigned to each transaction associated with the potential merchant identity code taking into account the provider score. The transaction score is stored. Merchant statistics are determined by analyzing the at least one transaction. A report including the transaction score is generated taking into account the merchant statistics and the transaction score. The report can then be provided for display via a graphical user interface.

[0009] A number of provider strings can be received by the management system. For example, the management system receives a first provider string associated with a first provider identity and with a first provider score. The management system receives a second provider string associated with a second provider identity and with a second provider score. The first provider identity is extracted from the first provider string. The second provider identity is extracted from the second provider string. A first potential seller identification code is determined from a set of known seller identification codes taking into account the first provider identity. A second potential seller identification code is determined from the set of known seller identification codes taking into account the second provider identity. Transaction data stored in a structured data resource associated with the management system is analyzed to identify at least a first transaction associated with the first potential seller identification code and at least a second transaction associated with the second potential seller identification code. A first transaction score is assigned to each first transaction taking into account the first provider score. A second transaction score is assigned taking into account the second provider score. The first transaction score and the second transaction score are stored. A report can be generated taking into account the first transaction score and the second transaction score. In certain reports, the transaction scores are hierarchically ranked. The report is provided for display via a graphical user interface.

[0010] This Summary is provided to introduce selected concepts, which are further described in the Detailed Description. This Summary is not intended to identify key or essential features of the claims, nor is it intended to be limiting of the scope of the claims. [Brief description of the drawings]

[0011] [Figure 1] FIG. 1 is a schematic diagram illustrating an example of an operating environment for payment processing for digital currency transactions involving a management system. [Diagram 2] FIG. 2 is a high level data flow diagram illustrating a management system that provides a reputation manager. [Diagram 3] FIG. 1 is a schematic diagram illustrating an example of a reputation maintenance environment. [Figure 4] Figure 4A shows an example of a report provided for display in a GUI for an acquirer, and Figure 4B shows an example of a report provided for display in a GUI for an issuer. [Diagram 5] 1 is a flow diagram illustrating an example process for providing reports that are generated taking into account merchant statistics and transaction scores. [Figure 6] 1 is a flow diagram illustrating an example process for providing hierarchically ranked transaction scores. [Figure 7] FIG. 1 is a schematic diagram illustrating components of a computing system that may be used in certain embodiments described in this disclosure. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0012] A cross-network evaluation of transactions with respect to provider reputation is described in this disclosure. Provider reputation is useful to entities or institutions such as acquirers, issuers, and banks. Such entities can use provider reputation to determine the risk associated with providers offering digital currency exchanges and the risk of cards used to conduct digital currency exchanges. Advantageously, the described system for cross-network evaluation of transactions with respect to provider reputation can map blockchain network risk evaluations to appropriate entities known to the payment network and can facilitate risk evaluation reports used by financial parties, such as banks or other institutions, to determine the risk associated with digital currency transactions.

[0013] "Merchant" refers to an entity that provides goods or services in exchange for payment. A merchant can be physically present for a transaction or remote, such as an online retailer.

[0014] A Virtual Asset Service Provider (VASP) refers to an organization that provides services related to virtual currency payments. In some embodiments, a merchant can be a VASP or can communicate with a VASP to obtain and provide virtual currency to customers. The described system and method leverages the relationship of purchasing digital / virtual currency with fiat currency to characterize the provider of the digital / virtual currency as a "merchant" (whether or not the provider of the digital / virtual currency is traditionally considered a "merchant" by the system). Traditional transactions involving banks or payment card rails (including the purchase of digital currency with fiat currency) involve standardized message formats that include a merchant field (or a recipient field). Thus, the entity identified as a "merchant" during transaction execution can be the provider of the digital currency, because the standardized message format will identify the entity that provides the digital currency as a merchant. Thus, a VASP or an entity that provides digital currency can be identified as a "merchant" or matched to a "merchant" by the described system. This is because the VASP provides the digital currency and is identified as the “merchant” in the transaction’s standardized message format.

[0015] "Provider" refers to an entity that offers goods or services, and in this disclosure, in particular, an entity that offers digital currency. Thus, in addition to the terms merchant and VASP being used interchangeably (where a VASP is considered a merchant by the system), the terms provider and VASP may be used interchangeably, and the terms merchant and provider may also be used interchangeably in this disclosure. As noted above, a merchant is considered to be a provider of digital currency (which may be a VASP or a merchant itself).

[0016] "Reputation" refers to the trustworthiness associated with a provider, a card, and / or a transaction. Reputation may be expressed in the form of a score or ranking. Additionally, reputation may be used to perform risk assessments.

[0017] An account holding institution (AHI) is a financial institution that directly or indirectly holds an account belonging to a consumer or customer, or that issues an access device (e.g., a bank card or debit card) and provides electronic funds transfer services under an agreement with the consumer. In some cases, an AHI can be an issuer. "Issuer" refers to a banking system or other institution that provides payment cards to cardholders.

[0018] The terms "user," "customer," and "consumer" are used interchangeably in this disclosure. The term "personal account number" refers to a financial account number, including but not limited to: bank account number, primary account number (PAN), and payment card number. The terms "personal account number" and "account number" are used interchangeably in this disclosure. The terms "payment" and "transaction" are used interchangeably in this disclosure.

[0019] Transactions involving digital currency may include transactions in which digital currency is purchased. Payment for the purchase of digital currency may be made using traditional fiat currency payments, including bank transfers and credit cards, or may be made using other types of digital currency. In one example, assume a customer wishes to purchase digital currency. The customer may submit a payment (either directly or through another party or merchant) to a provider, such as a VASP, to purchase the digital currency. The payment may be in the form of fiat currency. Data regarding the purchase of digital currency using fiat currency is considered transaction data, which may be stored or made available or accessible by a payment network. More details regarding transaction data are provided in this disclosure.

[0020] Various parties or entities involved in a payment transaction may wish to obtain information regarding the transaction on both the payment network and the blockchain network to assess risk assessment, including reputation information regarding providers involved in the digital currency exchange transaction. Such entities include acquirers, issuers, and banks. More details regarding these entities are provided in this disclosure.

[0021] FIG. 1 illustrates an example operating environment for payment processing for digital currency transactions with a management system. With reference to FIG. 1, the environment 100 includes a customer device 102, a merchant device 104, a blockchain network 106, an acquirer 108, a payment network 110, an issuer 112, and a VASP platform 120. An example of the payment network 110 may be operated by Mastercard International Incorporated, a nominee of the present disclosure. The environment 100 also includes a network 114 and a management system 118 that provides a reputation manager 116. One or more of the components illustrated in the environment 100 may be interconnected via the network 114.

[0022] In one embodiment, the network 114 may include a public network (e.g., the Internet), a private network (e.g., a LAN or WAN), a wired network (e.g., an Ethernet network), a wireless network (e.g., an 802.11 network or a Wi-Fi network), a cellular network (e.g., an LTE network), a router, a hub, a switch, a server computer, and / or a combination thereof. Communication between components on the network 114 may be based on appropriate protocols and reliability mechanisms. Thus, the network 114 may be considered to involve two or more independent networks where different protocols or reliability mechanisms are used to communicate between the different networks.

[0023] Customer device 102 may include one or more computing devices, such as a PC, a laptop, a mobile phone, a smart phone, a tablet computer, a netbook computer, etc. Customer device 102 may allow a user operating customer device 102 to view multimedia, such as images, videos, web pages, documents, etc. In an embodiment, customer device 102 may include a wallet application.

[0024] The merchant devices 104 may include merchant components similar to the customer devices 102 or more traditional, such as a point of sale (PoS) terminal 122 or components supporting online commerce (e.g., available to an e-commerce platform or payment application 124), including one or more computing devices (e.g., rack mount servers, router computers, server computers, PCs, mainframe computers, laptop computers, tablet computers, desktop computers, etc.), one or more data stores or one or more structured data resources (e.g., hard disks, memory, databases), networks, software components, hardware components, or combinations thereof.

[0025] To consider an exemplary scenario for a digital currency transaction, assume that a customer operating, utilizing, or accessing a customer device 102 initiates a request to purchase goods or services from a merchant device 104 (a "transaction"). The customer can provide payment via any fiat currency and / or digital currency (when made available by the financial institution or issuer). Payment can be provided by credit card, debit card, virtual wallet application, etc.

[0026] In some embodiments, a customer may initiate a transaction using a physical payment card, although references to "payment card" or "card" may extend to non-physical equivalents, such as a virtual wallet application (also referred to as a mobile wallet application) that supports mobile payments via a computing device (e.g., a laptop computer, a mobile device, a wearable computing device (e.g., a watch or glasses), and / or similar computing device). To do this, a customer may initiate a transaction using an app on a mobile device or in other ways.

[0027] A customer, via a customer device 102, provides payment and authorization to a merchant device 104 to initiate a transaction for digital currency. The acquirer 108 receives the transaction from the merchant device 104 via a payment gateway (e.g., a PoS terminal 122 or an online shopping cart or other payment application 124). The acquirer 108 may include a processor that forwards information about the transaction to the appropriate payment network 110. The payment network 110 routes information about the transaction to the appropriate issuer 112, which manages and verifies the payment card information, and the payment network 110 routes authorization from the issuer 112 to the acquirer 108. The payment network 110 may cache the transaction data locally and / or elsewhere. For example, as described herein, the payment network 110 sends a copy of the transaction data to one or more structured data resources. When storing transaction data beyond the time required to fulfill a transaction, it should be understood that any personally identifiable information will be maintained in accordance with applicable privacy policies and laws, and will not include customer personal or financial information other than that permitted (e.g., via an opt-in process).

[0028] The merchant device 104 can complete the transaction through the acquirer 108 to transfer funds to the merchant's financial institution (not shown). In some cases, the same entity can be both the payment network and the issuer.

[0029] The acquirer 108 can manage a portfolio of merchants independent of where the transaction is initiated. The issuer 112 can manage a portfolio of cards. The VASP platform 120 can manage various digital currency exchanges.

[0030] When a customer initiates a purchase of digital currency from a merchant using a fiat payment method, the merchant device 104 can obtain the digital currency from the blockchain network 106, either directly (if functioning as the VASP platform 120) or through a separate computing system for the VASP platform 120, and can provide a key / digital signature for the digital currency for the customer. As is apparent, because a payment network transaction occurs to purchase digital currency through the VASP platform 120, the VASP is considered the merchant by systems (e.g., payment network 110, etc.) because traditional transactions involving banks or payment card rails involve standardized message formats that include a merchant field (or recipient / payee field), and therefore the provider of the digital currency is considered the merchant.

[0031] Although not shown in FIG. 1, in some embodiments, instead of using a card, a customer can make a bank transfer, for example by issuing a request to a bank via the customer device 102, or by providing relevant bank details (e.g. account information which may include account number and sort code or routing number) to the merchant device 104, which can then request a wire bank transfer on behalf of the customer. The wire bank transfer can be made according to any suitable payment settlement system. Examples of settlement systems include automated clearing house (ACH), Bacs (formerly known as Bankers' Automated Clearing System), faster payments service (FPS), and society for worldwide interbank financial telecommunications (SWIFT). Information about the wire bank transfer transaction can be stored in association with the appropriate financial institution. Here, the VASP is considered as the recipient / beneficiary of the wire bank transfer. Thus, the bank (not shown) involved in the wire bank transfer can manage a portfolio of bank accounts for the payer and the beneficiary.

[0032] As mentioned above, the operating environment 100 further includes a management system 118 that provides the reputation manager 116. The reputation manager 116 provides a link between the blockchain network 106 and the payment network 110. Through operations performed by the management system 118 that provides the reputation manager 116, entities on the payment network (e.g., the acquirer 108, the issuer 112, and various financial institutions not shown) can obtain information regarding blockchain transactions. The management system 118 that provides the reputation manager 116 can include one or more computing devices (e.g., rack mount servers, router computers, server computers, PCs, mainframe computers, laptop computers, tablet computers, desktop computers, etc.), one or more data stores or one or more structured data resources (e.g., hard disks, memory, databases), networks, software components, hardware components, or combinations thereof suitable for implementing various functions described. For example, the management system 118 can be embodied as described with respect to the computing system 700 of FIG. 7. In some embodiments, the management system 118 that provides the reputation manager 116 can communicate with other components not shown in FIG. 1. For example, the management system 118 providing the reputation manager 116 may communicate with blockchain risk providers as described in Figures 2 and 3, and may also communicate with financial institutions that process wire bank transfers.

[0033] In the illustrated embodiment, the management system 118 that provides the reputation manager 116 is shown as separate from the payment network 110, although the management system 118 that provides the reputation manager 116 may be included in or associated with the payment network 110.

[0034] As noted above, details about the transaction (also referred to as transaction data) may be cached or made available by the payment network 110. The management system 118 providing the reputation manager 116 may access such transaction data from a structured data resource associated with the payment network 110 and / or the management system 118 providing the reputation manager 116. The management system 118 providing the reputation manager 116 may also access information about wire bank transfer transactions from appropriate entities that perform the associated multi-rail payment transactions. In further embodiments, other payment systems may be supported, so long as such systems provide transaction information that is identifiable to the merchant / recipient of the fiat currency.

[0035] In an embodiment, the management system 118 providing the reputation manager 116 may pull or receive transaction data from the payment network 110 (and / or the various alternative rail or bank payment networks described above in connection with FIG. 3) via the network 114. The transaction data received by the management system 118 providing the reputation manager 116 from the payment network 110 may include details about the "merchant" (which is the provider of the digital currency), details about the payment method, and other details about the transaction. The management system 118 providing the reputation manager 116 may store the transaction data in one or more structured data resources (where the transaction data is used) to determine the provider reputation.

[0036] 2 is a high level data flow diagram illustrating a management system providing a reputation manager. Referring to data flow diagram 200 in FIG. 2, a management system 118 providing a reputation manager 116 (described in relation to FIG. 1) can receive a provider risk score 215 from a blockchain risk provider 220 via a communication interface 212.

[0037] The provider risk score may include a provider identity, a score for the provider called the provider score, and a set of associated provider-level data. This information may be in the form of a string or vector, called a "P-string" as described in this disclosure.

[0038] The management system 118 can determine a link between the provider risk score 215, which is considered blockchain activity, and the transaction data, which is considered payment network activity, by identifying (222) a best match (e.g., from the provider risk score 215) for the provider identity received in the provider risk score to a known merchant identity. Card transactions can be analyzed (224) using the identified best match merchant identity (from block 222) and transaction data 225 from the payment network (e.g., payment network 110 of FIG. 1), which can be stored in an appropriate transaction data resource 230. Based on various analyses of the transaction data associated with the merchant identity, reports can be tailored to appropriate entities. For example, interfaces 240 can be provided for communicating the tailored reports to issuers 250, acquirers 260, and banks 270. Thus, a management system providing a reputation manager can use blockchain activity, represented by the provider scores received along with provider risk scores 215, and payment network activity, represented by transaction data 225, to calculate and weight reputation information and can analyze, generate, maintain, and report on reputation or risk ratings associated with merchants, cards, and / or transactions. Further details regarding certain operations that can be performed by management system 118 are described in connection with Figures 5 and 6.

[0039] An exemplary embodiment of a management system 118 providing a reputation manager 116 and reputation maintenance environment is shown in FIG. 3, which is capable of performing the operations illustrated in the high level data flow of FIG.

[0040] An example of a reputation maintenance environment is shown in Figure 3. Referring to Figure 3, the reputation maintenance environment 300 includes a blockchain risk provider 302, a management system 118 including a reputation manager 116, a recipient 328 (of reports), and a network 332. In some cases, the reputation maintenance environment 300 further includes a bank management system 322 and an associated multi-rail payment structured data resource 326 with various distributed multi-rail data centers or networks. One or more of the components illustrated in the environment 300 can be interconnected via the network 332.

[0041] The reputation manager 116 includes a communication interface 308, an extraction engine 310, a merchant matching engine 312, a structured data resource 314, a card analysis engine 316, and a reporting interface 318. The structured data resource 314 can receive, store, and otherwise make available transaction data associated with various transactions. The reputation manager 116 can be embodied as described in connection with the computing system 700 of FIG. 7. For example, aspects of the extraction engine 310, the merchant matching engine 312, the card analysis engine 316, and the reporting interface 318 can be implemented as instructions executed by one or more processors.

[0042] In one embodiment, the network 332 may include a public network (e.g., the Internet), a private network (e.g., a local area network (LAN) or a wide area network (WAN)), a wired network (e.g., an Ethernet network), a wireless network (e.g., an 802.11 network or a Wi-Fi network), a cellular network (e.g., an LTE network), routers, hubs, switches, server computers, and / or combinations thereof. Communication between components on the network 332 may be based on appropriate protocols and reliability mechanisms. Thus, the network 332 may be considered to involve two or more independent networks where different protocols or reliability mechanisms are used to communicate between the different networks.

[0043] The blockchain risk provider 302 receives blockchain activity from the blockchain (not shown in FIG. 3) and generates blockchain risk scores for various providers. As described in more detail below, the blockchain risk provider 302 can generate a tuple of provider scores 304 and can provide a provider risk score (215 in FIG. 2) in the form of a "P-string" 306.

[0044] The P string 306 communicated from the blockchain risk provider 302 is received by the management system 118 via a communication interface 308. The communication interface 308 can communicate data via a server using an API of HTTP (e.g., in a scheduled manner) or can use other protocols: HTTPS, FTP, Secure Shell FTP (SFTP), File Transfer Protocol Secure (FTPS), Applicability Statement 2 (AS2), Managed File Transfer (MFT), or other protocols. Transmissions from the blockchain risk provider 302 can be submitted with encryption or other security measures. In an embodiment, the P string 306 provided by the blockchain risk provider 302 to the management system 118 can involve a one-way outbound communication from the blockchain risk provider 302 to the management system 118 providing the reputation manager 116.

[0045] P string 306 includes a provider ID, a provider score, and optionally a set of provider or provider level data. The provider ID may also be referred to as a VASP ID and represents the provider by name or identifier. Examples of provider or provider level data include, but are not limited to: name, business name, risk score, know your customer (KYC) score, bank account details, and business details (e.g., date of incorporation, address, officers, number of employees, etc.).

[0046] The management system 118 maintains provider reputation by weighting transaction scores taking into account the provider scores of the P-strings 306 received from the blockchain risk providers 302. However, to leverage the provider scores received from the blockchain risk providers 302, the reputation manager 116 uses an extraction engine 310 and a merchant matching engine 312 to create a mapping between providers associated with the provider scores and known merchants.

[0047] For example, the extraction engine 310 of the management system 118 that provides the reputation manager 116 extracts the provider ID from the P string 306 received via the communication interface 308 and transmits (or provides) the provider ID to the seller matching engine 312.

[0048] The merchant matching engine 312 attempts to make potential matches between the provider ID and the merchant ID code. Specifically, the merchant matching engine 312 determines potential merchant ID codes from a set of known merchant ID codes given the provider ID. The set of known merchant ID codes can be obtained from data stored in the structured data resource 314 or from another storage resource that is specifically used to store information about known merchant ID codes. Detailed processing is described in connection with FIG. 5 and FIG. 6.

[0049] The structured data resource 314 shown in Figure 3 can be the same as or similar to the transaction data resource 230 of Figure 2, and can be implemented as multiple data resources. The structured data resource 314 can store transaction data from the payment network 110. In some cases, the resulting match of a provider ID to a potential merchant ID is stored in the structured data resource associated with the appropriate transaction.

[0050] Any transaction data stored (e.g., by structured data resource 314 and / or multi-rail payment structured data resource 326) or accessed by management system 118, bank management system 322, and / or any other entity should be understood to be maintained in accordance with appropriate privacy policies and laws and should be understood not to include personal or financial information of customers other than that permitted (e.g., by an opt-in process). Transaction data can be obtained from systems that process payment transactions, including single message systems, dual message systems, and electronic payment wallet application systems. Some transaction data, such as the goods and / or services sold, can be obtained from the acquirer or issuer if it is not directly available from fields in the transaction data message (the message being the message used in the transaction).

[0051] It should be understood that transaction data may continue to be collected asynchronously with respect to any use of structured data resource 314 .

[0052] As described above, the structured data resource 314 can receive and store transaction data associated with various transactions from the payment network 110, and can include matched provider information (including the provider score from the corresponding P-string 306). The management system 118 analyzes the transaction data stored in the structured data resource 314 associated with the management system 118 via the card analysis engine 316 to identify at least one transaction associated with a potential merchant identification code, assigns a transaction score (wherein the value is based on the provider score) to each identified transaction associated with a potential merchant identification code, and performs merchant statistics (including an analysis of transactions for a particular merchant and an analysis of transactions for a particular payment card in relation to one or more merchants).

[0053] The management system 118 generates reports, for example via the reporting interface 318, taking into account merchant statistics (determined taking into account payment network activity) and transaction scores (determined taking into account blockchain activity from provider scores). Based on the recipient 328, reports can be generated. For example, different customized reports can be generated for the following recipients: acquirer, issuer, and / or bank. Reports for acquirers can include information about inbound transactions (from the acquirer's perspective) and transaction scores of the digital currency provider. Reports for issuers can include outbound payments (from the issuer's perspective) made via card payments (by customers) or bank payments directed to the merchant, and the risk or score associated with the card. Reports for banks can include any type of information that is important to acquirers and issuers.

[0054] The management system 118 provides reports for display via a graphical user interface (GUI). A reporting interface 318 of the management system 118 may provide reports to an acquirer, issuer or bank, and the reports may be displayed via the GUI.

[0055] The reporting interface 318 can provide access to the reports via push or pull type communication. For example, access to the reports (e.g., as a pull type communication) can be made available via an API.

[0056] Multi-rail specific implementation example As mentioned above, payments for digital currency may need to be made outside of the payment network 110, and therefore the transaction data is not available directly from the payment network 110, but rather in an appropriate multi-rail structured data resource (e.g., in the multi-rail structured data resource 326). As shown in FIG. 3, to integrate transaction data (from digital currency transactions) from wire bank transfers, the environment 300 includes a bank management system 322 that includes a bank matching engine 330 and a multi-rail analysis engine 324. The bank management system 322 receives provider information (and other elements of the P-string 306) from the extraction engine 310 of the management system 118, identifies the corresponding provider bank account via the bank matching engine 330, and communicates with various resources on the bank / multi-rail network to obtain information about the multi-rail transaction for analysis by the multi-rail analysis engine 324. The multi-rail payment structured data resource 326 can store and maintain wire bank transfer transaction data, including bank account information for providers of digital currency.

[0057] Thus, referring to a high level data flow specific to a multi-rail embodiment, the management system 118 receives the P string 306 via the communication interface 308; the extraction engine 310 extracts the provider ID from the P string 306. If the provider ID includes bank account information, then the bank management system 322 is used. For example, the extraction engine 310 of the management system 118 extracts the provider ID and sends the provider ID (including bank account information) along with other elements of the P string 306 to the bank matching engine 330.

[0058] The bank matching engine 330 of the bank management system 322 matches the provider ID with bank account information, which may include sorting or routing codes and account numbers for the provider.

[0059] The bank management system 322, via a multi-rail analysis engine 324, analyzes electronic bank transaction data stored in one or more multi-rail payment structured data resources 326 to identify at least one transaction associated with an identified provider's bank account. Various analyses similar to those described in connection with the card analysis engine 316 can be performed (although the fields available for transaction data on the payment network are different from those available for wire bank transfers on the bank network). The results of the analysis can be provided to the reputation manager 116 of the management system 118 for use in generating reports in combination with the results of the card analysis engine 316.

[0060] report As discussed in connection with Figure 3, the recipient 328 can be one or more of an acquirer, an issuer, and / or a bank. The reports provided can be customized for each recipient or type of recipient.

[0061] To an acquirer, a provider (such as a VASP) may or may not be a merchant associated with the acquirer and may be significant. Specifically, an inbound transaction (from the acquirer's perspective) may be significant to the acquirer. As noted above, the acquirer receives payments submitted to a merchant on behalf of a customer, and from the acquirer's perspective, such payments are considered inbound transactions.

[0062] In embodiments, the acquirer's objective may be to weight the transaction scores for providers for which the acquirer processes transactions. Thus, the acquirer may be concerned with the reputation and / or risk for funds received by the merchant for payments made by customers, as well as the reputation of the VASP (if the merchant is considered a VASP offering digital currency). The acquirer may use the reports to determine risk for the merchant and / or VASP.

[0063] Figure 4A shows an example of a report provided for display in a GUI for an acquirer. Report 400 may be provided by reporting interface 318 as described in connection with Figure 3. Report 400 may include various columns, including those shown, and may have more or fewer columns than shown.

[0064] Report 400 includes provider column 402, weighted rank column 404, potential matched merchant ID code column 406, transaction score column 408, average spending variance column 410, sales column 412, and number of different cards accepted column 414. Transaction score column 408, average spending variance column 410, sales column 412, and number of different cards accepted column 414 can be subcolumns within merchant statistics column heading 416.

[0065] The report 400 can be used by an acquirer to view relevant information and determine the risk associated with its various merchants. The weighted rank column 404 can include a calculated ranking of the corresponding merchants. Any weighting scheme can be used to determine the ranking. In the illustrated embodiment, Company A is ranked "A+++", which is a hierarchical more weighted ranking than Company B's "D-" ranking. The ranking can be based on the columns shown or other criteria.

[0066] From an issuer's perspective, the funds (from cards issued by the issuer) sent from the customer to the merchant to complete a transaction can be important, and especially the outbound transaction from the issuer (from the issuer's perspective) can be important.

[0067] In embodiments, an issuer's objective may be to identify and weight transaction data associated with cards issued by the issuer where the merchant is selling digital currency or other digital assets in exchange for fiat currency (such as via payment cards). Thus, the issuer may be concerned about reputation and / or risk affecting funds sent from customers to the merchant. The issuer can use the reports to determine risk associated with cards issued by the issuer and transactions made with those cards. Thus, the issuer may be concerned about relevant card transactions made by cardholders.

[0068] Figure 4B shows an example of a report provided for display by the GUI for a publisher. Report 450 can be provided by reporting interface 318 described in connection with Figure 3. Report 450 can include various columns, including those shown, and can include more or fewer columns than are shown.

[0069] Report 450 includes a card column 452, a weighted rank column 454, a card transaction score column 456, a transaction count column 458, and an average transaction amount column 460. The transaction count column 458 and the average transaction amount column 460 may be subcolumns within a card transaction statistics column heading 462.

[0070] Reports 450 can be used by issuers to view relevant card information and determine the risk associated with various cards. Weighted rank column 454 can include a calculated ranking of the corresponding cards. Any weighting scheme can be used to determine the ranking. In the illustrated embodiment, card A is ranked "A+", which is a hierarchical more weighted ranking than card B's "C+" ranking. Rankings can be based on the columns shown or other criteria.

[0071] In yet another embodiment, a bank may be the recipient 328 in Figure 3. The bank may wish to assess risk for providers that have accounts with the bank. A report similar to Figure 4B may be provided. Of course, more or fewer columns of relevant information may be provided.

[0072] 5 illustrates an example process for providing a report that is generated taking into account merchant statistics and transaction scores. Process 500 may be performed by management system 118. Referring to FIG 5, process 500 includes receiving, at the management system, a provider string that is associated with a provider identity and that comprises a provider score (S502).

[0073] The management system 118 receives a provider string (e.g., P_string 306) associated with the provider identity and comprising a provider score (obtained from blockchain activity) from the blockchain risk provider 302. The provider string can be transmitted from the blockchain risk provider 302 to the management system 118 providing the reputation manager 116 via the network 332 of FIG.

[0074] For example, in an embodiment, assume a provider, such as a VASP, is represented by a variable "P". P can be characterized by a dataset. Examples of the dataset may include: P's name (i.e., the registered name, the legal name recognized by a government entity), P's business name (i.e., the name by which P is identified in the industry, the legal name under which P does business, a "DBA" type alias, etc.), P's bank account details (ACH, SWIFT code, routing number, account number or partial account number), known officers of P, etc. Such information may also be referred to as a provider identity, and may include additional elements as described in this disclosure. All relevant information about P may be represented by a set of provider strings, represented as "x_P": [Number 1] x_P = {x1, x2, … xn} where "x" is a distinct provider string associated with P, and there can be 1, 2, ..., n "x" strings in total.

[0075] The set of provider strings for P, denoted by "x_P", is associated with a provider score, denoted by "y". The provider score can be scored according to any scale. In one embodiment, the provider score "y" can range from 0 to 1, with 0 representing the lowest score and 1 representing the highest score. The provider score "y" can be generated or obtained by the blockchain risk provider 302 using any of a number of methods.

[0076] The blockchain risk provider 302 can use "y" (and other variables) to generate a set of tuples "Z", which is called the tuple provider score 304. The tuple provider score 304 can be ordered as the set of tuples "Z" as follows: [Number 2] Z = [(x,y)_P1 (x,y)_P2 … (x,y)_N] where N is the number of providers (or VASPs) being scored.

[0077] The "Z" can be arranged in any format. In one embodiment, the "Z" can be arranged in a serialized manner as comma separated values ​​(csv) with one tuple per line. A "Z" or tuple provider score 304 can include one or more tuples of "Z". The formatted "Z" for a provider can be converted by the blockchain risk provider 302 into a provider string, vector, or file called a P-string 306.

[0078] 5, process 500 includes extracting a provider identification from the provider string 504. For example, upon receipt of the provider string generated from the Z-tuple as described above, management system 118, via extraction engine 310, extracts the provider ID from the provider string (P_string 306).

[0079] The process 500 then includes determining (506) potential seller identification codes from a set of known seller identification codes given the provider identity. For example, the management system 118 determines potential seller ID codes from a set of known seller identification codes given the provider identity. The codes can be stored in a structured data resource in the form of a seller table. The identification / matching can be performed by a seller matching engine 312 of the management system 118.

[0080] The merchant matching engine 312 may perform the attempted match using any method. For example, the merchant matching engine 312 may attempt to match the provider ID (extracted from blockchain activity) to a set of known merchant ID codes (extracted from payment network activity) stored in a hierarchical table. If an exact match is not possible, the closest match may be sought. In embodiments, string and natural language processing techniques may be implemented to determine the best potential match. For example, the provider ID may be "Company Abcd Corporation." The merchant matching engine 312 may determine that the closest match stored in the set of merchant ID codes corresponds to "Company Abcd Corporation."

[0081] Additionally, error correction techniques can be implemented to determine potential merchant ID codes, such as using machine learning classifiers to handle difficult cases. Mistypes can hinder matching, and therefore these techniques can be leveraged to perform matching. A distance function can be used to match a set of strings (represented by "x_P") to a merchant ID code (represented by "E_d"). Thus, a distance function can be used to determine the distance between x_P and E_d, which is done to perform approximate string matching to find the closest match.

[0082] In an embodiment, a potential match may be made to best match (ie, most likely match) the provider ID with a known merchant ID code.

[0083] In some cases, the transaction data stored in the structured data resource includes one or more fields corresponding to provider risk score information (including one or more of a provider identity and a provider score), and the one or more fields are updated with the results of the matching process such that transactions associated with a particular merchant include provider information.

[0084] A provider ID (and corresponding known merchant ID) may be associated with multiple entities. Using association rules appropriate to the structured data resource 314, the merchant matching engine 312 may expand the merchant ID code, E_d, to a broader set of entities known to be owned by the matched entity associated with the potential merchant ID code. For example, a particular provider may be identified using an International Bank Account Number (IBAN). By utilizing certain resources, other IBANs owned by the same legal entity as the matched entity / merchant associated with a given merchant ID may be identified, and these accounts may be grouped and evaluated together by the card analysis engine 316.

[0085] The process 500 includes analyzing transaction data stored in a structured data resource associated with the management system to identify at least one transaction associated with the potential merchant identification code (508). For example, the management system 118 may identify at least one transaction associated with the potential merchant ID code in the transaction data structured data resource 314.

[0086] The process 500 includes assigning a transaction score to each transaction associated with the potential merchant identification code, taking into account the provider score (510). In some cases, the transaction score is the provider score, although other values ​​representing the provider score can be used.

[0087] The transaction scores may be represented by any scale. In one embodiment, a high risk transaction score may represent that a high risk is associated with the transaction, while a low risk transaction score may represent that a low risk is associated with the transaction. In an embodiment, a high risk transaction score may represent a high risk provider involved in dangerous or illegal activities such as gambling, fraud, money laundering, illegal behavior, terrorism, weapons distribution, drug distribution, etc. A low risk transaction score may represent a low risk provider, such as one that is mandated to provide reports to government authorities.

[0088] Process 500 includes storing (512) a transaction score. The transaction score may be stored in association with each transaction associated with the potential merchant identification code. The transaction score may be stored in a structured data resource. In some cases, the transaction score may be stored in association with / mapped to corresponding transaction data in a structured data resource, such as structured data resource 314 of FIG. 3.

[0089] The process 500 determines (514) merchant statistics by analyzing the at least one transaction. The management system 118 determines the merchant statistics by analyzing the at least one transaction. In particular, the card analysis engine 316 of the management system 118 may perform the analysis.

[0090] Because multiple provider strings may be received by the management system, the extraction of provider identities, identification of potential merchants, identification of transactions associated with the identified potential merchants, and assignment and storage of transaction scores may be performed for each received provider string. Thus, a determination of merchant statistics may be made across multiple transactions having different associated transaction scores based on the received provider scores.

[0091] The transaction data (e.g., stored in structured data resource 314) of at least one transaction may include at least two transaction attributes at a minimum. The transaction attributes of the transaction data may include, but are not limited to, the following: merchant ID (e.g., merchant name or other identifying information), masked user ID (e.g., masked card number or other value or string used to distinguish between users but not reveal actual user information), value (e.g., monetary amount), currency, payment method (e.g., virtual wallet / digital payment, specific card product payment such as Mastercard, Visa, American Express, etc., payment type such as credit, debit, prepaid, etc.), time and date, and goods and / or services sold in exchange for value, and other information. In some cases, the transaction attributes are any transaction attributes made available by one or more standards (e.g., ISO).

[0092] Examples of merchant statistics include: average spending variance associated with a potential merchant ID code (which is the difference between the actual amount of a particular spend and the forecasted (budgeted) amount of spend for a merchant), realized sales, forecasted sales, number of different cards / payment types accepted by a merchant corresponding to a potential merchant ID code, etc. Merchant statistics can be determined based on transaction data. Examples of merchant statistics include, but are not limited to: inbound volume, transaction rates, transaction dynamics, transaction trends, normal value and volume distributions, bank account / PAN counts, and value / volume / ratio / benchmarking for crypto transactions.

[0093] In determining the merchant statistics, the management system 118 may separate transactions to / from / through each merchant ID over a particular set of time windows to generate a set of transactions T_X = [t1, t2, .... tW], where tk (k = 1 to W) are individual transactions associated with the merchant ID code E_d, and W is the number of transactions in that window. The management system 118 may aggregate multiple transactions to generate a set of merchant statistics, which may be represented as θ_E_d.

[0094] Thus, the process 500 may include generating a report taking into account the merchant statistics and the transaction score 516. The management system 118 generates the report taking into account the merchant statistics and the transaction score.

[0095] For example, referring back to the set of provider strings for P(x_P), reports generated for entities (issuers, acquirers and / or banks) may be based on various objectives of the entity. In an embodiment, issuers and acquirers may wish to obtain reports to calculate the distance between the set of supplied strings x_P associated with providers and all entities contained in a merchant table that contains a set of known merchant ID codes. The distance is used to determine the best (closest) match. String and natural language processing can be used to find the best match. Additionally, error correction techniques such as using machine learning classifiers can be used to handle difficult cases where potential matches are not readily available.

[0096] For a bank account, the set of strings x_P may be expected to contain a unique identifier (eg, IBAN).

[0097] When isolating the window for transactions, for issuer aggregation, outbound transactions from the card to the merchant can be reviewed. For acquirer aggregation, the window of interest can span issuers and terminate at a specific set of merchants, and inbound transactions originating from the card that terminate at the merchant can be reviewed. For banks, transaction flows both to and from accounts associated with the provider are reviewed.

[0098] The process 500 includes providing the report for display via a graphical user interface (GUI) (518). The reporting interface 318 can provide the report for display via the GUI (and can be used to tailor the particular report that is generated).

[0099] In providing the report, the management system 118 can provide a merchant ID code (represented by "E_d"), a provider score (represented by "y_P"), and a set of merchant statistics (represented by "θ_E_d"), which can be made available via the report interface 318, indexed by the merchant ID code E_d. The management system 118 can generate a map as follows: E_d: (y_P, θ_E_d), and the map can be made available as a database table or transferred via an interface, such as an application programming interface (API).

[0100] An API is an interface implemented by a program code component or hardware component (referred to in this disclosure as an "API-implementing component") that allows a different program code component or hardware component (referred to in this disclosure as an "API-invoking component") to access and use one or more functions, methods, procedures, data structures, classes, and / or other services provided by the API-implementing component. An API may define one or more parameters that are passed between the API-invoking component and the API-implementing component. An API is generally a set of programming instructions and standards that allow two or more applications to communicate with each other, and is typically implemented on the Internet as a set of specified formats or structures for HTTP request and response messages that follow the Representational State Transfer (REST) ​​or Simple Object Access Protocol (SOAP) architectures.

[0101] In some cases, the reports can be sent via a push service. The management system 118 can identify one or more recipients for a particular type of report; and can send a corresponding report to each identified recipient (i.e., an acquirer, an issuer, or a bank) of the one or more recipients via a push service. In some cases, the recipients are registered subscribers for the reports.

[0102] An identified recipient may wish to receive reports as a web-based GUI. The GUI back-end server may maintain state E_d: (y_P, θ_E_d), where the provider identified in a particular context is represented by E_d, the provider score associated with the provider is represented by y_P, and the statistics relevant to the provider in that context are represented by θ_E_d. The recipient may retrieve this state from the reporting interface 318 on a regular basis, on any on-demand or time-scheduled basis.

[0103] The GUI front end can retrieve the appropriate subset of state for an approved recipient and present this with an appropriate set of multimedia, data visualization and interactive elements.

[0104] Thus, in an embodiment of process 500, a provider string is a vector comprising a provider identity, a provider score, and a set of associated provider-level data, and management system 118 receives a plurality of provider strings. In an embodiment, each of the plurality of provider strings is arranged in a tuple in a comma-separated value format within the structured data resource.

[0105] In an embodiment, process 500 determines (506) potential merchant identification codes from the set of known merchant identification codes using at least one of string and natural language processing techniques or error correction techniques (e.g., using a machine learning classifier).

[0106] In an embodiment, the transaction data comprises at least one of a plurality of merchant identification codes, a plurality of masked card numbers, or a plurality of payment methods.

[0107] In an embodiment, the merchant statistics comprise at least one of an average spending variance associated with a potential merchant identification code, realized sales, forecasted sales, or a number of different cards or payment types accepted by a merchant associated with a potential merchant identification code.

[0108] In an embodiment, the management system 118 receives a provider string from a blockchain risk provider.

[0109] 6 illustrates an exemplary process for providing hierarchically ranked transaction scores. Process 600 may be performed by the management system 118. Multiple provider strings may be received by the management system. Referring to FIG. 6, process 600 includes receiving, at the management system, a first provider string associated with a first provider identity and having a first provider score (S602).

[0110] The management system 118 receives a first provider string (P_string 306) associated with the first provider identity and comprising a first provider score from the blockchain risk provider 302.

[0111] The process 600 includes receiving 604 a second provider string associated with a second provider identity and comprising a second provider score.

[0112] The management system 118 receives a second provider string (P_String 306) associated with the second provider identity and comprising a second provider score from the blockchain risk provider 302. The first provider string and the second provider string can be generated based on two different transactions, one transaction completed by a first merchant and a second transaction completed by a second merchant.

[0113] The process 600 includes extracting 606 a first provider identity from the first provider string. The management system 118 extracts the first provider ID from the first provider string (P_string 306). In particular, the extraction engine 310 of the management system 118 extracts the first provider ID from the first provider string.

[0114] The process 600 includes extracting 608 a second provider identity from the second provider string. The management system 118 extracts the second provider ID from the second provider string (P_string 306). In particular, the extraction engine 310 of the management system 118 extracts the second provider ID from the second provider string.

[0115] The process 600 then includes determining 610 a first potential seller identification code from the set of known seller identification codes given the first provider identification. The management system 118 determines 610 a first potential seller identification code from the set of known seller identification codes given the first provider identification. The codes can be stored in a structured data resource in the form of a seller table.

[0116] The process 600 then includes determining 612 a second potential seller identification code from the set of known seller identification codes given the second provider identification. The management system 118 determines 612 a second potential seller identification code from the set of known seller identification codes given the second provider identification. The codes can be stored in one or more structured data resources in the form of a seller table.

[0117] The process 600 includes analyzing transaction data stored in a structured data resource associated with the management system 118 to identify at least a first transaction associated with a first potential merchant identification code and at least a second transaction associated with a second potential merchant identification code (614). The management system 118 includes analyzing transaction data stored in a structured data resource 314 associated with the management system 118 to identify at least a first transaction associated with the first potential merchant ID code and at least a second transaction associated with the second potential merchant ID code. The identification / matching can be performed by the merchant matching engine 312.

[0118] The process 600 includes assigning 616 a first transaction score taking into account the first provider score, the first transaction score being associated with at least a first transaction associated with the first potential merchant identification code. The management system 118 assigns 616 a first transaction score taking into account the first provider score, the first transaction score being associated with at least a first transaction associated with the first potential merchant identification code.

[0119] The process 600 includes assigning 618 a second transaction score taking into account the second provider score, the second transaction score being associated with at least a second transaction associated with the second potential merchant identification code. The management system 118 assigns 618 a second transaction score taking into account the second provider score, the second transaction score being associated with at least a second transaction associated with the second potential merchant identification code.

[0120] The process 600 includes storing the first transaction score and the second transaction score (620). The transaction scores can be stored in a structured data resource, and the transaction scores are hierarchically ranked.

[0121] The process 600 includes generating a report considering the first transaction score and the second transaction score (622), where the transaction scores are hierarchically ranked. The management system 118 generates the report considering the first transaction score and the second transaction score. For example, as shown in FIG. 4A, company A has a transaction score of 0.8 and company B has a transaction score of 0.3. The weighted rank of company A is hierarchically ranked more favorably than that of company B.

[0122] The process 600 includes providing the report for display via a graphical user interface 624. For example, the reporting interface 318 provides the report for display via a GUI.

[0123] In embodiments, reports are provided via an API. Customized reports can be provided to issuers, acquirers, and / or banks via the API.

[0124] In an embodiment, the first provider string and the second provider string are corresponding vectors, each vector comprising a provider identity, a provider score, and a set of associated provider-level data. The management system 118 receives the plurality of provider strings.

[0125] In an embodiment, multiple provider strings are arranged in a tuple in a comma separated value format within the structured data resource.

[0126] In an embodiment, at least one of the first potential merchant identification code or the second potential merchant identification code is determined from the set of known merchant identification codes using at least one of string and natural language processing techniques or error correction techniques (e.g., using a machine learning classifier).

[0127] In an embodiment, the transaction data comprises at least one of a plurality of merchant identification codes, a plurality of masked card numbers, or a plurality of payment methods.

[0128] In some embodiments, reports can be provided to recipients automatically via push or pull methods or based on time intervals. For example, reports can be provided to acquirers daily. In other embodiments, reports can be provided in a real-time manner (e.g., upon transaction completion). Additionally, transaction data can be provided to various structured data resources in a scheduled manner.

[0129] FIG. 7 illustrates components of a computing system that may be used in certain embodiments described in this disclosure. Referring to FIG. 7, system 700 may be implemented on a single computing device or distributed across multiple computing devices or subsystems that cooperate in executing program instructions. System 700 may include one or more blade server devices, stand-alone server devices, personal computers, routers, hubs, switches, bridges, firewall devices, intrusion detection devices, mainframe computers, network attached storage devices, and other types of computing devices. The system hardware may be configured according to any suitable computer architecture, such as, for example, a Symmetric Multi-Processing (SMP) architecture or a Non-Uniform Memory Access (NUMA) architecture.

[0130] System 700 can include a processing system 710, which can include one or more processors and / or other circuitry that reads and executes software 720 from a storage system 730. Processing system 710 can be implemented on a single processing device or can be distributed across multiple processing devices or subsystems that cooperate in executing program instructions.

[0131] Storage system 730 may include any computer readable storage medium that is readable by processing system 710 and capable of storing software 720. Storage system 730 may be implemented as a single storage device or across multiple storage devices or subsystems that may be co-located or distributed with respect to one another. Storage system 730 may include additional elements, such as a controller that may be in communication with processing system 710. Storage system 730 may also include storage devices and / or subsystems in which data is stored. System 700 may access one or more storage resources to access information and perform any processing directed by software 720.

[0132] Software 720, including routines for performing processes such as process 500 and process 600 for the management system, may be implemented in program instructions that, among other functions, when executed by system 700 generally or system 710 specifically, cause system 700 or processing system 710 to operate as described.

[0133] In implementations where system 700 includes multiple computing devices, the server may include one or more communication networks that facilitate communication between the computing devices. For example, the one or more communication networks may include a local area network or a wide area network that facilitates communication between the computing devices. One or more direct communication links may be included between the computing devices. Also, in some cases, the computing devices may be deployed in geographically distributed locations. In other cases, multiple computing devices may be deployed in a single geographic location, such as a server farm or an office.

[0134] A communications interface 740 can be included, which provides communications connections and devices to enable communication between the system 700 and other computing systems (not shown) over a communications network or collection of networks (not shown) or wirelessly.

[0135] In some embodiments, the system 700 can host one or more virtual machines.

[0136] Alternatively or additionally, the functionality of the methods and processes of the present disclosure may be implemented, at least in part, by one or more hardware modules (or logic components). For example, the hardware modules may include, but are not limited to, application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), system-on-a-chip (SoC) systems, complex programmable logic devices (CPLDs), and other programmable logic devices now known or later developed. When a hardware module is activated, it performs the functions, methods, and processes contained within the hardware module.

[0137] It should be noted that in any case, in this disclosure, the terms "storage medium," "computer-readable storage medium," or "computer-readable storage medium" do not consist of a transitory carrier wave or propagating signal. Instead, "storage" media refers to non-transitory media.

[0138] Any functionality that applies to the reputation manager may equally apply to the management system. Although management system 118 is shown as including reputation manager 116, in other embodiments, management system 118 and reputation manager 116 may be separate and may communicate with each other using network communication methods. Also, any entity represented in a single form may equally be represented in multiple forms, and vice versa. Although example entities are described, other embodiments may achieve the objectives of the disclosure using more or fewer entities than those described.

[0139] Although subject matter will be described in language specific to structural features and / or operations, it should be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or operations described above. Rather, the specific features and operations described above are disclosed as example embodiments of implementing the claims, and other equivalent features and operations are intended to be within the scope of the claims.

Claims

1. receiving, at the management system, a provider string associated with a provider identity and comprising a provider score; extracting the provider identity from the provider string; determining a potential merchant identification code from a set of known merchant identification codes given the provider identity; analyzing transaction data stored in a structured data resource associated with the management system to identify at least one transaction associated with the potential merchant identification code; assigning a transaction score to each transaction associated with said potential merchant identification code taking into account said provider score; storing said transaction score; determining merchant statistics by analyzing the at least one transaction; generating a report that includes the transaction scores taking into account the merchant statistics and the transaction scores; providing the report for display via a graphical user interface.

2. 2. The method of claim 1, wherein the provider string is a vector comprising the provider identity, the provider score, and a set of associated provider-level data, and the management system receives a plurality of provider strings.

3. The method of claim 2 , wherein the multiple provider strings are arranged in a tuple in a comma separated value format within the structured data resource.

4. 10. The method of claim 1, wherein the step of determining the potential merchant identification code includes using at least one of string and natural language processing techniques, or error correction techniques.

5. 10. The method of claim 1, wherein the transaction data comprises at least one of a plurality of merchant identification codes, a plurality of masked card numbers, or a plurality of payment methods.

6. 2. The method of claim 1, wherein the merchant statistics comprise at least one of an average spending variance associated with the potential merchant identification code, realized sales, forecasted sales, or a number of different cards or payment types accepted by the merchant associated with the potential merchant identification code.

7. 2. The method of claim 1, wherein the management system receives the provider string from a blockchain risk provider.

8. One or more computer-readable storage media having instructions stored thereon that, when executed by a processing system, cause the processing system to: receiving, at the management system, a first provider string associated with a first provider identity and comprising a first provider score; receiving a second provider string associated with a second provider identity and comprising a second provider score; extracting the first provider identity from the first provider string; extracting the second provider identity from the second provider string; determining a first potential merchant identification code from a set of known merchant identification codes given the first provider identity; determining a second potential merchant identification code from the set of known merchant identification codes given the second provider identity; analyzing transaction data stored in a structured data resource associated with the management system to identify at least a first transaction associated with the first potential merchant identification code and at least a second transaction associated with the second potential merchant identification code; assigning a first transaction score to each first transaction associated with the first potential merchant identification code, taking into account the first provider score; assigning a second transaction score to each second transaction associated with the second potential merchant identification code, taking into account the second provider score; storing the first transaction score and the second transaction score; generating a report taking into account the first transaction score and the second transaction score, the transaction scores being hierarchically ranked; and providing the report for display via a graphical user interface.

9. 10. The medium of claim 8, wherein the reporting is provided via an application programming interface (API).

10. 9. The medium of claim 8, wherein the first provider string and the second provider string are corresponding vectors, each vector comprising the provider identity, the provider score, and a set of associated provider-level data, and the management system receives a plurality of provider strings.

11. 11. The medium of claim 10, wherein each of the plurality of provider strings is arranged in a tuple in a comma separated value format.

12. 9. The medium of claim 8, wherein the processing system further determines at least one of the first potential merchant identification code or the second potential merchant identification code from the set of known merchant identification codes using at least one of string and natural language processing techniques or error correction techniques.

13. 10. The medium of claim 8, wherein the transaction data comprises at least one of a plurality of merchant identification codes, a plurality of masked card numbers, or a plurality of payment methods.

14. 1. A computing device comprising: A processor; A storage device; and a reputation manager having instructions stored in the storage device and executed by the processor to cause the computing device to: receiving, at the management system, a provider string associated with a provider identity and comprising a provider score; extracting the provider identity from the provider string; determining a potential merchant identification code from a set of known merchant identification codes given the provider identity; analyzing transaction data stored in a structured data resource associated with the management system to identify at least one transaction associated with the potential merchant identification code; assigning a transaction score to each transaction associated with said potential merchant identification code taking into account said provider score; storing said transaction score; determining merchant statistics by analyzing the at least one transaction; generating a report taking into account the merchant statistics and the transaction scores; and providing said report for display via a graphical user interface.

15. 15. The computing device of claim 14, wherein the provider string is a vector comprising the provider identity, the provider score, and a set of associated provider-level data.

16. 15. The computing device of claim 14, wherein a plurality of provider strings are arranged in a tuple in a comma separated value format within the structured data resource.

17. 17. The computing device of claim 16, further comprising instructions that cause the computing device to: determine the potential merchant identification code from the set of known merchant identification codes using at least one of string and natural language processing techniques or error correction techniques.

18. 15. The computing device of claim 14, wherein the transaction data comprises at least one of a plurality of merchant identification codes, a plurality of masked card numbers, or a plurality of payment methods.

19. 15. The computing device of claim 14, wherein the merchant statistics comprise at least one of an average spending variance associated with the potential merchant identification code, realized sales, forecasted sales, or a number of different cards and / or payment types accepted by the merchant associated with the potential merchant identification code.

20. 17. The computing device of claim 16, wherein the provider string is received from a blockchain risk provider.

Images